One document matched: draft-ietf-simple-intradomain-federation-01.xml
<?xml version="1.0" encoding="utf-8"?>
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc='yes'?>
<?rfc tocdepth='5'?>
<?rfc symrefs="yes"?>
<?rfc compact='yes'?>
<?rfc subcompact='no'?>
<rfc ipr="full3978" category="info">
<front>
<title abbrev="Intra-Domain Presence and IM Federation">
Models for Intra-Domain Presence and Instant Messaging (IM) Federation</title>
<author initials="J.R." surname="Rosenberg"
fullname="Jonathan Rosenberg">
<organization>Cisco</organization>
<address>
<postal>
<city>Edison</city> <region>NJ</region>
<country>US</country>
</postal>
<phone>+1 973 952-5000</phone>
<email>jdrosen@cisco.com</email>
<uri>http://www.jdrosen.net</uri>
</address>
</author>
<author initials="A.H" surname="Houri"
fullname="Avshalom Houri">
<organization>IBM</organization>
<address>
<postal>
<city>Science Park</city> <region>Rehovot</region>
<country>Israel</country>
</postal>
<email>avshalom@il.ibm.com</email>
</address>
</author>
<author initials="C.S" surname="Smyth"
fullname="Colm Smyth">
<organization>Avaya</organization>
<address>
<postal>
<city>Dublin 18</city> <region>Sandyford Business Park</region>
<country>Ireland</country>
</postal>
<email>smythc@avaya.com</email>
</address>
</author>
<date month="July" year="2008" />
<area>RAI</area>
<workgroup>SIMPLE</workgroup>
<keyword>SIP</keyword>
<keyword>SIMPLE</keyword>
<keyword>presence</keyword>
<keyword>IM</keyword>
<keyword>federation</keyword>
<abstract>
<t>Presence and Instant Messaging (IM) federation involves
the sharing of presence information and exchange of IM
across multiple systems. Most often, presence and IM
federation is assumed to be between different
organizations, such as between two enterprises or between
and enterprise and a service provider. However, federation
can occur within a single organization or domain. This can
be the result of a multi-vendor network, or a consequence
of a large organization that requires partitioning. This
document examines different use cases and models for
intra-domain presence and IM federation. </t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
Presence refers to the ability, willingness and desire to communicate
across differing devices, mediums and services
<xref target="RFC2778"/>. Presence is described using presence
documents <xref target="RFC3863"/> <xref target="RFC4479"/>, exchanged
using a Session Initiation Protocol (SIP) <xref target="RFC3261"/>
based event package <xref target="RFC3856"/>
</t>
<t>
Presence federation refers to the sharing of presence information
across multiple presence systems. This interconnection involves
passing of subscriptions from one system to another, and then the
passing of notifications in the opposite direction.
</t>
<t>
Similarly, instant messaging refers to the exchange of real-time
text-oriented messaging between users. SIP defines two mechanisms for
IM - pager mode <xref target="RFC3428"/> and session mode
<xref target="RFC4975"/>. IM federation refers to the exchange of
IM between users in different IM systems.
</t>
<t>
Most often, presence and IM federation is considered in the context of
interconnection between different domains, also known as inter-domain
federation
<xref target="I-D.ietf-speermint-consolidated-presence-im-usecases"/>. For
example, consider the network of <xref target="fig-pres-model"/>,
which shows one model for inter-domain presence federation. In
this network, Alice belongs to the example.org domain, and Bob belongs
to the example.com domain. Alice subscribes to her buddy list on her
presence server (which is also acting as her Resource List Server
(RLS) <xref target="RFC4662"/>), and that list includes
bob@example.com. Alice's presence server generates a back-end
subscription on the federated link between example.org
and example.com. The example.com presence server authorizes the
subscription, and if permitted, generates notifications back to
Alice's presence server, which are in turn passed to Alice.
</t>
<figure title="Inter-Domain Presence Model" anchor="fig-pres-model"><artwork>
<![CDATA[
............................. ..............................
. . . .
. . . .
. alice@example.org . . bob@example.com .
. +------------+ SUB . . +------------+ .
. | | Bob . . | | .
. | Presence |------------------->| Presence | .
. | Server | . . | Server | .
. | | . . | | .
. | |<-------------------| | .
. | | NOTIFY . | | .
. +------------+ . . +------------+ .
. ^ | . . ^ .
. SUB | | . . |PUB .
. Buddy | |NOTIFY . . | .
. List | | . . | .
. | | . . | .
. | V . . | .
. +-------+ . . +-------+ .
. | | . . | | .
. | | . . | | .
. | | . . | | .
. +-------+ . . +-------+ .
. . . .
. Alice's . . Bob's .
. PC . . PC .
. . . .
............................. ..............................
example.org example.com
]]></artwork></figure>
<t>
Similarly, inter-domain IM federation would look like the model shown
in <xref target="fig-im-model"/>:
</t>
<figure title="Inter-Domain IM Model" anchor="fig-im-model"><artwork>
<![CDATA[
............................. ..............................
. . . .
. . . .
. alice@example.org . . bob@example.com .
. +------------+ INV . . +------------+ .
. | | Bob . . | | .
. | |------------------->| | .
. | IM | . . | IM | .
. | Server | . . | Server | .
. | |<------------------>| | .
. | | IM | | .
. +------------+ Content +------------+ .
. ^ ^ . . ^ | .
. INVITE | | . . IM | |INV .
. Bob | | IM . . Content| |Bob .
. | | Content . . | | .
. | | . . | | .
. | V . . V V .
. +-------+ . . +-------+ .
. | | . . | | .
. | | . . | | .
. | | . . | | .
. +-------+ . . +-------+ .
. . . .
. Alice's . . Bob's .
. PC . . PC .
. . . .
............................. ..............................
example.org example.com
]]></artwork></figure>
<t>
In this model, example.org and example.com both have an "IM
server". This would typically be a SIP proxy or B2BUA responsible for
handling both the signaling and the IM content (as these are separate
in the case of session mode). The IM server would handle routing of
the IM along with application of IM policy.
</t>
<t>
Though both of these pictures show federation as being between
domains, it can happen within a domain as well. We define
intra-domain federation as the interconnection of presence and IM servers
within a single domain, where domain refers explicity to the right
hand side of the @-sign in the SIP URI.
</t>
<t>
This document considers the architectural models and different
problems that arise when performing intra-domain presence and IM
federation. Though presence and IM are quite distinct functions, this
document considers both since the architectural models and issues are
common between the two. The document first clarifies the distinction
between intra-domain federation and clustering. It defines the primary
issues that arise in intra-domain presence and IM federation, and then
goes on to define the three primary models for it - partitioned,
unioned and exclusive.
</t>
</section>
<section title="Intra-Domain Federation vs. Clustering">
<t>
Intra-domain federation is the interconnection of servers
within a single domain. This is very similar to clustering, which is
the tight coupling of a multiplicity of physical servers to realize
scale and/or high availability. Consequently, it is important to
clarify the differences.
</t>
<t>
Firstly, clustering implies a tight coupling of components. Clustering
usually involves proprietary
information sharing, such as database replication and state sharing,
which in turn are tightly bound with the internal implementation of
the product. Intra-domain federation, on the other hand, is a loose
coupling. There is never database replication or state replication
across federated systems (though a database and DB replication might
be used within a component providing routing functions to facilitate
federation).
</t>
<t>
Secondly, clustering always occurs amongst components from the same
vendor. This is due to the tight coupling described
above. Intra-domain federation, on the other hand, can occur between
servers from different vendors. As described below, this is one of the
chief use cases for intra-domain federation.
</t>
<t>
Thirdly, clustering is almost always invisible to
users. Communications between users within the same cluster almost
always have identical functionality to communications between users on
the same server within the cluster. The cluster boundaries are
invisible; indeed the purpose of a cluster is to build a system which
behaves as if it were a single monolithic entity, even though it is
not. Federation, on the other hand, is often visible to users. There
will frequently be loss of functionality when crossing a
cluster. Though this is not a hard and fast rule, it is a common
differentiator.
</t>
<t>
Fourthly, connections between federated systems almost always involve
standards, whereas communications within a cluster often involves
proprietary mechanisms. Standards are needed for federation because
the federated systems can be from different vendors, and thus
agreement is needed to enable interoperation.
</t>
<t>
Finally, a cluster will often have an upper bound on its size and
capacity, due to some kind of constraint on the coupling between nodes
in the cluster. However, there is typically no limit, or a much larger
limit, on the number of federated systems that can be put into a
domain. This is a consequence to their loose coupling.
</t>
<t>
Though these rules are not hard and fast, they give general guidelines
on the differences between clustering and intra-domain federation.
</t>
</section>
<section title="Use Cases for Intra-Domain Federation">
<t>
There are several use cases that drive intra-domain federation.
</t>
<section title="Scale">
<t>
One common use case for federation is an organization that is just
very large, and
their size exceeds the capacity that a single server or cluster can
provide. So, instead, the domain breaks its users into partitions
(perhaps arbitrarily) and then uses intra-domain federation to allow
the overall system to scale up to arbitrary sizes. This is common
practice today for service providers and large enterprises.
</t>
</section>
<section title="Organizational Structures">
<t>
Another use case for intra-domain federation is a multi-national
organization with regional IT departments, each of which supports a
particular set of nationalities. It is very common for each regional
IT department to deploy and run its own servers for its own
population. In that case, the domain would end up being composed of
the presence servers deployed by each regional IT department. Indeed,
in many organizations, each regional IT department might end up using
different vendors. This can be a consequence of differing regional
requirements for features (such as compliance or localization
support), differing sales channels and markets in which vendors sell,
and so on.
</t>
</section>
<section title="Multi-Vendor Requirements">
<t>
Another use case for intra-domain federation is an organization that
requires multiple vendors for each service, in order to avoid vendor
lock in and drive competition between its vendors. Since the servers
will come from different vendors, a natural way to deploy them is to
partition the users across them. Such multi-vendor networks are
extremely common in large service provider networks, many of which
have hard requirements for multiple vendors.
</t>
<t>
Typically, the vendors are split along geographies, often run by
different local IT departments. As such, this case is similar to the
organizational division above.
</t>
</section>
<section title="Specialization">
<t>
Another use case is where certain vendors might specialize in
specific types of clients. For
example, one vendor might provide a mobile client (but no desktop
client), while another provides a desktop client but no mobile
client. It is often the case that specific client applications and
devices are designed to only work with their corresponding servers. In
an ideal world, clients would all implement to standards and this
would not happen, but in practice, the vast majority of presence and
IM endpoints work only (or only work well) with the server from the same
vendor. A domain might want each user to have both a mobile client and
a desktop client, which will require servers from each vendor, leading
to intra-domain federation.
</t>
<t>
Similarly, presence can contain rich information, including activities
of the user (such as whether they are in a meeting or on the phone),
their geographic location, and their mood. This presence state can be
determined manually (where the user enters and updates the
information), or automatically. Automatic determination of these
states is far preferable, since it puts less burden on the
user. Determination of these presence states is done by taking "raw"
data about the user, and using it to generate corresponding presence
states. This raw data can come from any source that has information
about the user, including their calendaring server, their VoIP
infrastructure, their VPN server, their laptop operating system, and
so on. Each of these components is typically made by different
vendors, each of which is likely to integrate that data with their
presence servers. Consequently, presence servers from different
vendors are likely to specialize in particular pieces of presence
data, based on the other infrastructure they provide. The overall
network will need to contain servers from those vendors, composing
together the various sources of information, in order to combine their
benefits. This use case is specified to presence, and results
in intra-domain federation. </t>
</section>
<!-- end use cases -->
</section>
<section title="Considerations for Federation Models">
<t>
When considering architectures for intra-domain presence and IM federation,
several issues need to be considered. The first two of these apply to
both IM and presence (and indeed to any intra-domain communications,
including voice). The latter two are specific to presence and IM
respectively:
<list style="hanging">
<t hangText="Routing:"> How are subscriptions and IMs routed to the right
presence and IM server(s)? This issue is more complex in intra-domain
models, since the right hand side of the @-sign cannot be used to
perform this routing.
</t>
<t hangText="Policy and Identity:"> Where do user policies reside, and
what presence and IM server(s) are responsible for executing that policy?
What identities does the user have in each system and how do they
relate?
</t>
<t hangText="Presence Data Ownership:">Which presence servers are
responsible for
which pieces of presence information, and how are those pieces
composed to form a coherent and consistent view of user presence?
</t>
<t hangText="Conversation Consistency:">When considering instant
messaging, if IM can be delivered to multiple servers, how do we
make sure that the overall conversation is coherent to the user?
</t>
</list>
</t>
<t>
The sections below describe several different models for intra-domain
federation. Each model is driven by a set of use cases, which are
described in an applicability subsection for each model. Each model
description also discusses how routing, policy, presence data
ownership and conversation consistency work.
</t>
</section>
<section title="Partitioned">
<t>
In the partitioned model, a single domain has a multiplicity of
servers, each of which manages a non-overlapping set of users. That
is, for each user in the domain, their presence data, policy and IM
handling reside on a single server. Each "single server" may in fact
be a cluster.
</t>
<t>
Another important facet of the partitioned model is that, even though
users are partitioned across different servers, they each share the
same domain name in the right hand side of their URI, and this URI is
what those users use when communicating with other users both inside
and outside of the domain. There are many reasons why a domain would
want all of its users to share the same right-hand side of the @-sign
even though it is partitioned internally:
</t>
<list style="symbols">
<t>The partitioning may reflect organizational or geographical
structures that a domain admistrator does not want to reflect
externally.
</t>
<t>If each partition had a separate domain name (i.e.,
engineering.example.com and sales.example.com), if a user changed
organizations, this would necessitate a change in their URI.
</t>
<t>
For reasons of vanity, users often like to have their URI (which
appear on business cards, email, and so on), to be brief and short.
</t>
<t>
If a watcher wants to add a
presentity based on username and does not want to know, or does not know,
which subdomain or internal department the presentity belongs to, a single
domain is needed.
</t>
</list>
<t>
This model is illustrated in <xref target="fig-partitioned"/>. As the
model shows, the domain example.com has six users across three
servers, each of which is handling two of the users.
</t>
<figure title="Partitioned Model" anchor="fig-partitioned"><artwork>
<![CDATA[
.....................................................................
. .
. .
. .
. joe@example.com alice@example.com padma@example.com .
. bob@example.com zeke@example.com hannes@example.com .
. +-----------+ +-----------+ +-----------+ .
. | | | | | | .
. | Server | | Server | | Server | .
. | 1 | | 2 | | 3 | .
. | | | | | | .
. +-----------+ +-----------+ +-----------+ .
. .
. .
. .
. example.com .
.....................................................................
]]></artwork></figure>
<section title="Applicability">
<t>
The partitioned model arises naturally in larger domains, such as an
enterprise or service provider, where issues of scale, organizational
structure, or multi-vendor requirements cause the domain
to be managed by a multiplicity of independent servers.
</t>
<t>
In cases where each user has an AoR that directly points to its
partition (for example, us.example.com), that model becomes identical
to the inter-domain federated model and is not treated here
further.
</t>
</section>
<section title="Routing">
<t>
The partitioned intra-domain model works almost identically to an
inter-domain federated model, with the primary difference being
routing. In inter-domain federation, the domain part of the URI can be
used to route presence subscriptions and IM messages from one domain
to the other. This is no longer
the case in an intra-domain model. Consider the case where Joe
subscribes to his buddy list, which is served by his presence server
(server 1 in <xref target="fig-partitioned"/>). Alice is a member of
Joe's buddy list. How does server 1 know that the back-end
subscription to Alice needs to get routed to server 2?
</t>
<t>
There are several techniques that can be used to solve this problem,
which are outlined in the subsections below.
</t>
<section title="Centralized Database">
<figure title="Centralized DB" anchor="fig-routing-db"><artwork>
<![CDATA[
.....................................................................
. +-----------+ .
. alice? | | .
. +---------------> | Database | .
. | server 2 | | .
. | +-------------| | .
. | | +-----------+ .
. | | .
. | | .
. | | .
. | | .
. | | .
. | | .
. | V .
. joe@example.com alice@example.com padma@example.com .
. bob@example.com zeke@example.com hannes@example.com .
. +-----------+ +-----------+ +-----------+ .
. | | | | | | .
. | Server | | Server | | Server | .
. | 1 | | 2 | | 3 | .
. | | | | | | .
. +-----------+ +-----------+ +-----------+ .
. .
. .
. .
. example.com .
.....................................................................
]]></artwork></figure>
<t>
One solution is to rely on a common, centralized database that
maintains mappings of users to specific servers, shown in
<xref target="fig-routing-db"/>. When Joe subscribes to his buddy list
that contains Alice, server 1 would query this database, asking it
which server is responsible for alice@example.com. The database would
indicate server 2, and then server 1 would generate the backend
SUBSCRIBE request towards server 2. Similarly, when Joe sends an
INVITE to establish an IM session with Padma, he would send the IM to
his IM server, an it would query the database to find out that Padma
is supported on server 3. This is a common technique in
large email systems. It is often implemented using internal
sub-domains; so that the database would return
alice@central.example.com to the query, and server 1 would modify the
Request-URI in the request to reflect this.
</t>
<t>
Routing database solutions have the problem that they require
standardization on a common schema and database protocol in order to
work in multi-vendor environments. For example, LDAP and SQL are both
possibilities. There is variety in LDAP schema; one possibility is
H.350.4, which could be adapted for usage here
<xref target="RFC3944"/>.
</t>
</section>
<section title="Routing Proxy">
<figure title="Routing Proxy" anchor="fig-routing-proxy"><artwork>
<![CDATA[
.....................................................................
. +-----------+ .
. SUB/INV alice | | .
. +---------------> | Routing | .
. | | Proxy | .
. | | | .
. | +-----------+ .
. | | .
. | | .
. | | .
. | |SUB/INV alice .
. | | .
. | | .
. | V .
. joe@example.com alice@example.com padma@example.com .
. bob@example.com zeke@example.com hannes@example.com .
. +-----------+ +-----------+ +-----------+ .
. | | | | | | .
. | Server | | Server | | Server | .
. | 1 | | 2 | | 3 | .
. | | | | | | .
. +-----------+ +-----------+ +-----------+ .
. .
. .
. .
. example.com .
.....................................................................
]]></artwork></figure>
<t>
A similar solution is to rely on a routing proxy or B2BUA. Instead of a
centralized database, there would be a centralized SIP proxy
farm. Server 1 would send requests (SUBSCRIBE, INVITE, etc.) for users
it doesn't serve to this server farm, and the servers would lookup the
user in a database (which is now accessed only by the routing proxy),
and the resulting requests are sent to the correct server. A
redirect server can be used as well, in which case the flow is very
much like that of a centralized database, but uses SIP.
</t>
<t>
Routing proxies have the benefit that they do not require a common
database schema and protocol, but they do require a centralized server
function that sees all subscriptions and IM requests, which can be a
scale challenge. For IM, a centralized proxy is very challenging when
using pager mode, since each and every IM is processed by the central
proxy. For session mode, the scale is better, since the proxy handles
only the initial INVITE.
</t>
</section>
<section title="Subdomaining">
<t>
In this solution, each user is associated with a subdomain, and is
provisioned as part of their respective server using that
subdomain. Consequently, each server thinks it is its own,
separate domain. However, when a user adds a presentity to their buddy list
without the subdomain, they first consult a shared database which
returns the subdomained URI to subscribe or IM to. This sub-domained URI can
be returned because the user provided a search criteria, such as "Find
Alice Chang", or provided the non-subdomained URI
(alice@example.com). This is shown in <xref target="fig-subdomain"/>
</t>
<figure title="Subdomaining" anchor="fig-subdomain"><artwork>
<![CDATA[
.....................................................................
. +-----------+ .
. who is Alice? | | .
. +---------------------->| Database | .
. | alice@b.example.com | | .
. | +---------------------| | .
. | | +-----------+ .
. | | .
. | | .
. | | .
. | | .
. | | .
. | | .
. | | .
. | | joe@a.example.com alice@b.example.com padma@c.example.com .
. | | bob@a.example.com zeke@b.example.com hannes@c.example.com .
. | | +-----------+ +-----------+ +-----------+ .
. | | | | | | | | .
. | | | Server | | Server | | Server | .
. | | | 1 | | 2 | | 3 | .
. | | | | | | | | .
. | | +-----------+ +-----------+ +-----------+ .
. | | ^ .
. | | | .
. | | | .
. | | | .
. | | | .
. | | | .
. | | +-----------+ .
. | +-------------------->| | .
. | | Client | .
. | | | .
. +-----------------------| | .
. +-----------+ .
. .
. .
. .
. example.com .
.....................................................................
]]></artwork></figure>
<t>
Subdomaining puts the burden of routing within the client. The servers
can be completely unaware that they are actually part of the same
domain, and integrate with each other exactly as they would in an
inter-domain model. However, the client is given the burden of
determining the subdomained URI from the original URI or buddy name,
and then subscribing or IMing directly to that server, or including
the subdomained URI in their buddylist. The client is also responsible
for hiding the subdomain structure from the user and storing the
mapping information locally for extended periods of time. In cases
where users have buddy list subscriptions, the client will need to
resolve the buddy name into the sub-domained version before adding to
their buddy list.
</t>
</section>
<section title="Peer-to-Peer">
<t>
Another model is to utilize a peer-to-peer network amongst all of the
servers, and store URI to server mappings in the distributed hash
table it creates. This has some nice properties but does require a
standardized and common p2p protocol across vendors, which does not
exist today.
</t>
</section>
<section anchor="sec-forking" title="Forking">
<t>
Yet another solution is to utilize forking. Each server is provisioned
with the domain names or IP addresses of the other servers, but not
with the mapping of users to each of those servers. When a server
needs to handle a request for a user it doesn't have, it forks
the request to all of the other servers. This request will
be rejected with a 404 on the servers which do not handle that user,
and accepted on the one that does. The approach assumes that
servers can differentiate inbound requests from end users
(which need to get passed on to other servers - for example via a
back-end subscription) and from other
servers (which do not get passed on). This approach
works very well in organizations with a relatively small number of
servers (say, two or three), and becomes increasingly ineffective with
more and more servers.
</t>
</section>
<section title="Provisioned Routing">
<t>
Yet another solution is to provision each server with each user, but
for servers that don't actually serve the user, the provisioning
merely tells the server where to proxy the request. This solution has
extremely poor operational properties, requiring multiple points of
provisioning across disparate systems.
</t>
</section>
</section>
<section title="Policy">
<t>
A fundamental characteristic of the partitioned model is that there is
a single point of policy enforcement (authorization rules and
composition policy) for each user.
</t>
</section>
<section title="Presence Data">
<t>
Another fundamental characteristic of the partitioned model is that
the presence data for a user is managed authoritatively on a single
server. In the example of <xref target="fig-partitioned"/>, the
presence data for Alice lives on server 2 alone (recall that server
two may be physically implemented as a multiplicity of boxes from a
single vendor, each of which might have a portion of the presence
data, but externally it appears to behave as if it were a single
server). A subscription from Bob to Alice may cause a transfer of
presence information from server 2 to server 1, but server 2 remains
authoritative and is the single root source of all data for Alice.
</t>
</section>
<section title="Conversation Consistency">
<t>
Since the IM for a particular user are always delivered through a
particular server that handles the user, it is relatively easy to
achieve conversation consistency. That server receives all of the
messages and readily pass them onto the user for
rendering. Furthermore, a coherent view of message history can be
assembled by the server, since it sees all messages. If a user has
multiple devices, there are challenges in constructing a consistent
view of the conversation with page mode IM. However, those issues
exist in general with page mode and are not worsened by intra-domain
federation.
</t>
</section>
<!-- end partitioned -->
</section>
<section title="Exclusive">
<t>
In the former (static) partitioned model, the mapping of a user to a
specific server is done by some off-line configuration means. The
configuration assigns a user to a specific server and in order to use a
different server, the user needs to change (or request the administrator
to do so) the configuration.
</t>
<t>
In some environments, this restriction of a user to use a particular
server may be a limitation. Instead, it is desirable to allow users to
freely move back and forth between systems, though using only a single
one at a time. This is called Exclusive Federation.
</t>
<t>
Some use cases where this can happen are:
</t>
<list style="symbols">
<t>The organization is using multiple systems where each system has its own
characteristics. For example one server is tailored to work with some CAD
(Computer Aided Design) system and provide presence and IM functionality
along with the CAD system. The other server is the default presence and IM
server of the organization. Users wish to be able to work with either
system when they wish to, they also wish to be able to see the presence
and IM with their buddies no matter which system their buddies are
currently using.
</t>
<t>An enterprise wishes to test presence servers from two different
vendors. In order to do so they wish to install a server from each vendor
and see which of the servers is better. In the static partitioned model, a
user will have to be statically assigned to a particular server and could
not compare the features of the two servers. In the dynamic partitioned
model, a user may choose on whim which of the servers that are being
tested to use. They can move back and forth in case of problems.
</t>
<t>
An enterprise is currently using servers from one vendor, but has
decided to add a second. They would like to gradually migrate users
from one to the other. In order to make a smooth transition, users can
move back and forth over a period of a few weeks until they are
finally required to stop going back, and get deleted from their old
system.
</t>
<t>
A domain is using multiple clusters from the same vendor. To simplify
administration, users can connect to any of the clusters, perhaps one
local to their site. To accomplish this, the clusters are connected
using exclusive federation.
</t>
</list>
<section title="Routing">
<t>Due to its nature, routing in the Exclusive federation model is
more complex than the routing in the partitioned model.
</t>
<t>
Association of a user to a server can not be known until the user
publishes a presence document to a specific server or registers to
that server. Therefore, when Alice subscribes to Bob's presence
information, or sends him an IM, Alice's server will not easily know
the server that has Bob's presence and is handling his IM.
</t>
<t>In addition, a server may get a subscription to a user, or an IM
targeted at a user, but the user may not be connected to any server
yet. In the case of presence, once the user appears in one
of the servers, the subscription should be sent to that
server.
</t>
<t>A user may use two servers at the same time and have
hers/his presence information on two servers. This should be regarded as a
conflict and one of the presence clients should be terminated or
redirected to the other server.
</t>
<t>
Fortunately, most of the routing approaches described for partitioned
federation, excepting provisioned routing, can be adapted for
exclusive federation.
</t>
<section title="Centralized Database">
<t>
A centralized database can be used, but will need to support a
test-and-set functionality. With it,
servers can check if a user is already in a specific server and set the
user to the server if the user is not on another server. If the user is
already on another server a redirect (or some other error message) will be
sent to that user.
</t>
<t>
When a client sends a subscription request for some target user, and
the target user is not associated with a server yet, the subscription
must be 'held' on the server of the watcher. Once the target user
connects and becomes bound to a server, the database needs to send a
change notification to the watching server, so that the 'held'
subscription can be extended to the server which is now handling
presence for the user.
</t>
</section>
<section title="Routing Proxy">
<t>
The routing proxy mechanism can be used for exclusive federation as
well. However, it requires signaling from each server to the routing
proxy to indicate that the user is now located on that server. This
can be done by having each server send a REGISTER request to the
routing proxy, for that user, and setting the contact to itself. The
routing proxy would have a rule which allows only a single registered
contact per user. Using the registration event package
<xref target="RFC3680"/>, each server subscribes to the registration
state at the routing proxy for each user it is managing. If the
routing proxy sees a duplicate registration, it allows it, and then
uses a reg-event notification to the other server to
de-register the user. Once the user is de-registered from that server,
it would terminate any subscriptions in place for that user, causing
the watching server to reconnect the subscription to the new
server. Something similar can be done for in-progress IM sessions;
however this may have the effect of causing a disruption in ongoing
sessions.
</t>
</section>
<section title="Subdomaining">
<t>
Subdomaining is just a variation on the centralized database. Assuming
the database supports a test-and-set mechanism, it can be used for
exclusive federation.
</t>
<t>
However, the principle challenge in applying subdomaining to exclusive
federation is database change notifications. When a user moves from
one server to another, that change needs to be propagated to all
clients which have ongoing sessions (presence and IM) with that
user. This requires a large-scale change notification mechanism - to
each client in the network.
</t>
</section>
<section title="Peer-to-Peer">
<t>
Peer-to-peer routing can be used for routing in exclusive
federation. Essentially, it provides a distributed registrar function
that maps each AoR to the particular server that they are currently
registered against. When a UA registers to a particular server, that
registration is written into the P2P network, such that queries for
that user are directed to that presence server.
</t>
<t>
However, change notifications can be troublesome. When a user
registered on server 1 now registers on server 2, server 2 needs to query
the p2p network, discover that server 1 is handling the user, and then
tell server 1 that the user has moved. Server 1 then needs to
terminate its ongoing subscriptions and send the to server 2.
</t>
<t>
Furthermore, P2P networks do not inherently provide a test-and-set
primitive, and consequently, it is possible for race conditions to
occur where there is an inconsistent view on where the user is
currently registered.
</t>
</section>
<section title="Forking">
<t>
The forking model can be applied to exclusive federation. When a user
registers with a server or publishes a presence document to a server,
and that server is not serving the user yet, that server begins
serving the user. Furthermore, it needs to propagate a change
notification to all of the other servers. This can be done using a
registration event package; basically each server would subscribe to
every other server for reg-event notifications for users they serve.
</t>
<t>
When subscription or IM request is received at a server, and that
server doesn't serve the target user, it forks the subscription or IM
to all other servers. If the user is currently registered somewhere,
one will accept, and the others will reject with a 404. If the user is
registered nowhere, all others generate a 404. If the request is a
subscription, the server that received it would 'hold' the
subscription, and then subscribe for the reg-event package on every
other server for the target user. Once the target user registers
somewhere, the server holding the subscription gets a notification and
can propagate it to the new target server.
</t>
<t>
Like the P2P solution, the forking solution lacks an effective
test-and-set mechanism, and it is therefore possible that there could
be inconsistent views on which server is handling a user.
</t>
</section>
<!-- end routing -->
</section>
<section title="Policy">
<t>
In the exclusive federation model, policy becomes more complicated. In
the partitioned model, a user had their presence and IM managed by the same
server all of the time. Thus, their policy can be provisioned and
excecuted there. With exclusive federation, a user can freely move
back and forth between servers. Consequently, the policy for a
particular user may need to execute on multiple different servers over
time.
</t>
<t>
The simplest solution is just to require the user to separately
provision and manage policies on each server. In many of the use cases
above, exclusive federation is a transient situation that eventually
settles into partitioned federation. Thus, it may not be unreasonable
to require the user to manage both policies during the transition. It
is also possible that each server provides different capabilities, and
thus a user will receive different service depending on which server
they are connected to. Again, this may be an acceptable limitation for
the use cases it supports.
</t>
[[TODO - reference appropriate unioned models]]
</section>
<section title="Presence Data">
<t>
As with the partitioned model, in the exclusive model, the presence
data for a user resides on a single server at any given time. This
server owns all composition policies and procedures for collecting and
distributing presence data.
</t>
</section>
<section title="Conversation Consistency">
<t>
Because a user receives all of their IM on a single server at a time,
there aren't issues with seeing a coherent conversation for the
duration that a user is associated with that server.
</t>
<t>
However, if a user has sessions in progress while they move from one
server to another, it is possible that IM's can be misrouted or
dropped, or delivered out of order. Fortunately, this is a transient
event, and given that its unlikely that a user would actually have
in-progress IM sessions when they change servers, this may be an
acceptable limitation.
</t>
<t>
However, conversation history may be more troubling. IM message
history is often stored both in clients (for context of past
conversations, search, etc.) and in servers (for the same reasons, in
addition to legal requirements for data retention). If a user changes
servers, some of their past conversations will be stored on one
server, and some on another. Any kind of search or query facility provided
amongst the server-stored messages would need to search amongst all of
the servers to find the data.
</t>
</section>
<!-- end exclusive -->
</section>
<section title="Unioned">
<t>
In the unioned model, each user is actually served by more than one
presence server at a time. In this case, "served" implies two properties:
</t>
<list style="symbols">
<t>A user is served by a server when that user is provisioned on that
server, and</t>
<t>That server is authoritative for some piece of presence state
associated with that user or responsible for some piece of
registration state associated with that user, for the purposes of IM
delivery
</t>
</list>
<t>
In essence, in the unioned model, a user's presence and registration
data is distributed across many presence servers, while in the
partitioned and exclusive models, its centralized in a single
server. Furthermore, it is possible that the user is provisioned with
different identifiers on each server.
</t>
<t>
This definition speaks specifically to ownership of dynamic data -
presence and registration state - as the key property. This rules out
several cases which involve a mix of servers within the enterprise,
but do not constitute intra-domain unioned federation:
<list style="symbols">
<t>A user utilizes an outbound SIP proxy from one vendor, which
connects to a presence server from another vendor. Even though this
will result in presence subscriptions, notifications, and IM
requests flowing between servers, and the user is potentially
provisioned on both, there is no authoritative presence or
registration state in the
outbound proxy, and so this is not intra-domain federation.
</t>
<t>A user utilizes a Resource List Server (RLS) from one vendor, which
holds their buddy list, and accesses presence data from a presence
server from another vendor. This case is actually the partitioned
case, not the unioned case. Effectively, the buddy list itself is
another "user", and it exists entirely on one server (the RLS),
while the actual users on the buddy list exist entirely within
another. Consequently, this case does not have the property that a
single presence resource exists on multiple servers at the same
time.
</t>
<t>
A user subscribes to the presence of a presentity. This subscription
is first passed to their presence server, which acts as a proxy, and
instead sends the subscription to the UA of the user, which acts as
a presence edge server. In this model, it may appear as if there are
two presence servers for the user (the actual server and their
UA). However, the server is acting as a proxy in this case - there
is only one source of presence information. For IM, there is only
one source of registration state - the server. Thus, this model is
partitioned, but with different servers owning IM and presence.
</t>
</list>
</t>
<t>
The unioned models arise naturally when a user is using devices from
different vendors, each of which has their own respective servers, or
when a user is using different servers for different parts of their
presence state. For example, <xref target="fig-unioned-1"/> shows the
case where a single user has a mobile client connected to
server one and a desktop client connected to server two.
</t>
<figure title="Unioned Case 1" anchor="fig-unioned-1"><artwork>
<![CDATA[
alice@example.com alice@example.com
+------------+ +------------+
| | | |
| | | |
| Server |--------------| Server |
| 1 | | 2 |
| | | |
| | | |
+------------+ +------------+
\ /
\ /
\ /
\ /
\ /
\ /
\...................../.......
\ / .
.\ / .
. \ | +--------+ .
. | |+------+| .
. +---+ || || .
. |+-+| || || .
. |+-+| |+------+| .
. | | +--------+ .
. | | /------ / .
. +---+ /------ / .
. --------/ .
. .
.............................
Alice
]]></artwork></figure>
<t>
As another example, a user may have two devices from the same vendor,
both of which are asociated with a single presence server, but that presence
server has incomplete presence state about the user. Another
presence server in the enterprise, due to its access to state for
that user, has additional data which needs to be accessed by the
first presence server in order to provide a comprehensive view of
presence data. This is shown in <xref target="fig-unioned-2"/>. This
use case tends to be specific to presence.
</t>
<figure title="Unioned Case 2" anchor="fig-unioned-2"><artwork>
<![CDATA[
alice@example.com alice@example.com
+------------+ +------------+
| | | |
| Presence | | Presence |
| Server |--------------| Server |
| 1 | | 2 |
| | | |
| | | |
+------------+ +------------+
^ | |
| | |
| | |
///-------\\\ | |
||| specialized ||| | |
|| state || | |
\\\-------/// | |
.............................
. | | .
. | | +--------+ .
. | |+------+| .
. +---+ || || .
. |+-+| || || .
. |+-+| |+------+| .
. | | +--------+ .
. | | /------ / .
. +---+ /------ / .
. --------/ .
. .
. .
.............................
Alice
]]></artwork></figure>
<t>
Another use case for unioned federation are subscriber moves. Consider
a domain which uses multiple servers, typically running in a
partitioned configuration. The servers are organized regionally so
that each user is served by a server handling their region. A
user is moving from one region to a new job in another, while
retaining their SIP URI. In order to provide a smooth transition,
ideally the system would provide a "make before break" functionality,
allowing the user to be added onto the new server prior to being
removed from the old. During the transition period, especially if the
user had multiple clients to be moved, they can end up with
state existing on both servers at the same time.
</t>
<t>
Another use case for unioned federation is multiple
providers. Consider a user in an enterprise,
alice@example.com. Example.com has a presence server deployed for all
of its users. In addition, Alice uses a public IM and presence
provider. Alice would like that users who connect to the public
provider see presence state that comes from example.com, and
vice-a-versa. Interestingly, this use case isn't intra-domain
federation at all, but rather, unioned inter-domain federation.
</t>
<section title="Hierarchical Model">
<t>
The unioned intra-federation model can be realized in one of two ways
- using a hierarchical structure or a peer structure.
</t>
<t>
In the hierarchical model, presence subscriptions and IM requests for
the target are always routed first to one of the servers - the
root. In the case of presence, the root has the final say on the
structure of the presence document delivered to watchers. It collects
presence data from its child presence servers (through notifications
or publishes received from them) and composes them into the final
presence document. In the case of IM, the root applies IM policy and
then passes the IM onto the children for delivery. There can be
multiple layers in the hierarchical model. This is shown in
<xref target="fig-hierarchical"/> for presence.
</t>
<figure title="Hierarchical Model" anchor="fig-hierarchical"><artwork>
<![CDATA[
+-----------+
*-----------* | |
|Auth and |---->| Presence | <--- root
|Composition| | Server |
*-----------* | |
| |
+-----------+
/ ---
/ ----
/ ----
/ ----
V -V
+-----------+ +-----------+
| | | |
*-----------* | Presence | *-----------* | Presence |
|Auth and |-->| Server | |Auth and |-->| Server |
|Composition| | | |Composition| | |
*-----------* | | *-----------* | |
+-----------+ +-----------+
| ---
| -----
| -----
| -----
| -----
| -----
V --V
+-----------+ +-----------+
| | | |
*-----------* | Presence | *-----------* | Presence |
|Auth and |-->| Server | |Auth and |-->| Server |
|Composition| | | |Composition| | |
*-----------* | | *-----------* | |
+-----------+ +-----------+
]]></artwork></figure>
<t>
Its important to note that this hierarchy defines the sequence of
presence composition and policy application, and does
not imply a literal message flow. As an example, consider once more
the use case of <xref target="fig-unioned-1"/>. Assume that presence
server 1 is the root, and presence server 2 is its child. When Bob's
PC subscribes to Bob's buddy list (on presence server 2),
that subscription will first go to presence server 2. However, that
presence server knows that it is not the root in the hierarchy, and
despite the fact that it has presence state for Alice (who is on Bob's
buddy list), it creates a back-end
subscription to presence server 1. Presence server 1, as the root,
subscribes to Alice's state at presence server 2. Now, since this
subscription came from presence server 1 and not Bob directly,
presence server 2 provides the presence state. This is received at
presence server 1, which composes the data with its own state for
Alice, and then provides the results back to presence server 2, which,
having acted as an RLS, forwards the results back to
Bob. Consequently, this flow, as a message sequence diagram, involves
notifications passing from presence server 2, to server 1, back to
server 2. However, in terms of composition and policy, it was done
first at the child node (presence server 2), and then those results
used at the parent node (presence server 1).
</t>
<section title="Routing">
<t>
In the hierarchical model, each server needs to be
provisioned with the root, its parent and its children servers for each
user it handles. These relationships could in fact be different
on a user-by-user basis; however, this is complex to
manage. In all likelihood, the parent and child relationships are
identical for each user. The overall routing algorithm can be
described thusly:
</t>
<t>
<list style="symbols">
<t>
If a SUBCRIBE is received from the parent node for this presentity,
perform subscriptions to each child node for this presentity, and then
take the results, apply composition and authorization policies, and
propagate to the parent. If a node is the root, the logic here applies
regardless of where the request came from.
</t>
<t>If an IM request is received from the parent node for a user,
perform IM processing and then proxy the request to each child IM
server for this user. If a node is the root, the logic here applies
regardless of where the request came from.
</t>
<t>
If a request is received from a node that is not the parent node for
this presentity, proxy the request to the parent node. This includes
cases where the node that sent the request is a child node.
</t>
</list>
</t>
<t>
This routing rule is relatively simple, and in a two-server system is
almost trivial to provision. Interestingly, it works in cases where
some users are partitioned and some are unioned. When the users are
partitioned, this routing algorithm devolves into the forking
algorithm of <xref target="sec-forking"/>. This points to the forking
algorithm as a good choice since it can be used for both
partitioned and unioned.
</t>
<t>
An important property of the routing in the hierarchical model is that
the sequence of composition and policy operations for any IM or
presence session is identical, regardless of the watcher or sender of
the IM. The result is that the overall presence state provided to a
watcher, and overall IM behavior, is always consistent and independent
of the server the client is connected to. We call this property the
*consistency property*, and it is an important metric in assessing the
correctness of a federated presence and IM system.
</t>
</section>
<section title="Policy and Identity">
<t>
Policy and identity are a clear challenge in the unioned model.
</t>
<t>
Firstly, since a user is provisioned on many servers, it is possible
that the identifier they utilize could be different on each server. For
example, on server 1, they could be joe@example.com, whereas on server
2, they are joe.smith@example.com. In cases where the identifiers are
not equivalent, a mapping function needs to be provisioned. This
ideally happens on root server.
</t>
<t>
Secondly, the unioned model will result in back-end subscriptions
extending from one presence server to another presence server. These
subscriptions, though made by the presence server, need to be made
on-behalf-of the user that originally requested the presence state of
the presentity. Since the presence server extending the back-end
subscription will not often have credentials to claim identity of the
watcher, asserted identity using techniques like P-Asserted-ID
<xref target="RFC3325"/> are required, along with the associated trust
relationships between servers. Optimizations, such as view sharing
<xref target="I-D.ietf-simple-view-sharing"/> can help improve
performance. The same considerations apply for IM.
</t>
<t>
The principle challenge in a unioned model is policy,
including both authorization and composition policies. There are three
potential solutions to the administration of policy in the
hierarchical model (only two of which apply in the peer model, as
we'll discuss below). These are root-only, distributed provisioned, and
central provisioned.
</t>
<section title="Root Only">
<t>
In the root-only policy model, authorization policy, IM policy, and composition
policy are applied only at the root of the tree. This is shown in
<xref target="fig-root-only"/>.
</t>
<figure title="Root Only" anchor="fig-root-only"><artwork>
<![CDATA[
+-----------+
*-----------* | |
| |---->| | <--- root
| Policy | | Server |
*-----------* | |
| |
+-----------+
/ ---
/ ----
/ ----
/ ----
V -V
+-----------+ +-----------+
| | | |
| | | |
| Server | | Server |
| | | |
| | | |
+-----------+ +-----------+
| ---
| -----
| -----
| -----
| -----
| -----
V --V
+-----------+ +-----------+
| | | |
| | | |
| Server | | Server |
| | | |
| | | |
+-----------+ +-----------+
]]></artwork></figure>
<t>
As long as a subscription request came from its parent, every child
presence server would automatically accept the subscription, and
provide notifications containing the full presence state it is aware
of. Similarly, any IM received from a parent would be simply
propagated onwards towards children. Any composition performed by a
child presence server would need to be lossless, in that it fully
combines the source data without loss of information, and also be done
without any per-user provisioning or configuration, operating in a
default or administrator-provisioned mode of operation.
</t>
<t>
The root-only model has the benefit that it requires the user to
provision policy in a single place (the root). However, it has the
drawback that the composition and policy processing may be performed
very poorly. Presumably, there are multiple presence servers in the
first place because each of them has a particular speciality. That
speciality may be lost in the root-only model. For example, if a child
server provides geolocation information, the root presence server may
not have sufficient authorization policy capabilities to allow the
user to manage how that geolocation information is provided to
watchers.
</t>
</section>
<section title="Distributed Provisioning">
<t>
The distributed provisioned model looks exactly like the diagram of
<xref target="fig-hierarchical"/>. Each server is separately
provisioned with its own policies, including what users are allowed to
watch, what presence data they will get, how it will be composed, what
IMs get blocked, and so on.
</t>
<t>
One immediate concern is whether the overall policy processing, when
performed independently at each server, is consistent, sane, and
provides reasonable degrees of privacy. It turns out that it can, if
some guidelines are followed.
</t>
<t>
For presence, consider basic "yes/no" authorization policies. Lets say a
presentity, Alice, provides an authorization policy in server 1 where
Bob can see her presence, but on server 2, provides a policy where Bob
cannot. If presence server 1 is the root, the subscription is accepted
there, but the back-end subscription to presence server 2 would be
rejected. As long as presence server 1 then rejects the subscription,
the system provides the correct behavior. This can be turned into a
more general rule:
<list style="symbols">
<t>To guarantee privacy safety, if the back-end subscription generated
by a presence server is denied, that server must deny the triggering
subscription in turn, regardless of its own authorization
policies. This means that a presence server cannot send
notifications on its own until it has confirmed subscriptions from
downstream servers.
</t>
</list>
</t>
<t>
For IM, basic yes/no authorization policies work in a similar way. If any
one of the servers has a policy that says to block an IM, the IM is
not propagated further down the chain. Whether the overall system
blocks IMs from a sender depends on the topology. If there is no
forking in the hierarchy, the system has the property that, if a
sender is blocked at any server, the user is blocked overall. However,
in tree structures where there are multiple children, it is possible
that an IM could be delivered to some downstream clients, and not
others.
</t>
<t>
Things get more complicated when one considers presence authorization
policies whose job is to block access to specific pieces of
information, as opposed to blocking a user completely. For example,
lets say Alice wants to allow Bob to see her presence, but not her
geolocation information. She provisions a rule on server 1 that blocks
geolocation information, but grants it on server 2. The correct mode
of operation in this case is that the overall system will block
geolocation from Bob. But will it? In fact, it will, if a few
additional guidelines are followed:
<list style="symbols">
<t>If a presence server adds any information to a presence document
beyond the information received from its children, it must provide
authorization policies that govern the access to that information.
</t>
<t>If a presence server does not understand a piece of presence data
provided by its child, it should not attempt to apply its own
authorization policies to access of that information.
</t>
<t>
A presence server should not add information to a presence document
that overlaps with information that can be added by its parent. Of
course, it is very hard for a presence server to know whether this
information overlaps. Consequently, provisioned composition rules
will be required to realize this.
</t>
</list>
</t>
<t>
If these rules are followed, the overall system provides privacy
safety and the overall policy applied is reasonable. This is because
these rules effectively segment the application of policy based on
specific data, to the servers that own the corresponding data. For
example, consider once more the geolocation use case described above,
and assume server 2 is the root. If server 1 has access to, and
provides geolocation information in presence documents it produces,
then server 1 would be the only one to provide authorization policies
governing geolocation. Server 2 would receive presence documents from
server 1 containing (or not) geolocation, but since it doesn't provide
or control geolocation, it lets that information pass through. Thus,
the overall presence document provided to the watcher will contain
gelocation if Alice wanted it to, and not otherwise, and the controls
for access to geolocation would exist only on server 1.
</t>
<t>
The second major concern on distributed provisioning is that it is
confusing for users. However, in the model that is described here,
each server would necessarily be providing distinct rules, governing
the information it uniquely provides. Thus, server 2 would have rules
about who is allowed to see geolocation, and server 1 would have rules
about who is allowed to subscribe overall. Though not ideal, there is
certainly precedent for users configuring policies on different
servers based on the differing services provided by those
servers. Users today provision block and allow lists in email for
access to email servers, and separately in IM and presence
applications for access to IM.
</t>
</section>
<section anchor="sec-central" title="Central Provisioning">
<t>
The central provisioning model is a hybrid between root-only and
distributed provisioning. Each server does in fact execute its
own authorization and composition policies. However, rather than the
user provisioning them independently in each place, there is some kind
of central portal where the user provisions the rules, and that portal
generates policies for each specific server based on the data that the
corresponding server provides. This is shown in
<xref target="fig-central-prov"/>.
</t>
<figure title="Central Provisioning" anchor="fig-central-prov"><artwork>
<![CDATA[
+---------------------+
|provisioning portal |
+---------------------+
. . . . .
. . . . .
. . . . .......................
........................... . . . .
. . . . .
. . . . .
. ........................... . ............. .
. . . . .
. . ...................... . .
. . V +-----------+ . .
. . *-----------* | | . .
. . |Auth and |---->| Presence | <--- root . .
. . |Composition| | Server | . .
. . *-----------* | | . .
. . | | . .
. . +-----------+ . .
. . | ---- . .
. . | ------- . .
. . | ------- .
. . | .------- .
. . V . ---V V
. . +-----------+ . +-----------+
. . | | V | |
. . *-----------* | Presence | *-----------* | Presence |
. ....>|Auth and |-->| Server | |Auth and |-->| Server |
. |Composition| | | |Composition| | |
. *-----------* | | *-----------* | |
. +-----------+ +-----------+
. / --
. / ----
. / ---
. / ----
. / ---
. / ----
. V -V
. +-----------+ +-----------+
V | | | |
*-----------* | Presence | *-----------* | Presence |
|Auth and |-->| Server | |Auth and |-->| Server |
|Composition| | | |Composition| | |
*-----------* | | *-----------* | |
+-----------+ +-----------+
]]></artwork></figure>
<t>
Centralized provisioning brings the benefits of root-only (single
point of user provisioning) with those of distributed provisioning
(utilize full capabilities of all servers). Its principle drawback is
that it requires another component - the portal - which can represent
the union of the authorization policies supported by each server, and
then delegate those policies to each corresponding server.
</t>
<t>
The other drawback of centralized provisioning is that it assumes
completely consistent policy decision making on each server. There is
a rich set of possible policy decisions that can be taken by servers,
and this is often an area of differentiation.
</t>
</section>
<section title="Centralized PDP">
<t>
The centralized provisioning model assumes that there is a single
point of policy administration, but that there is independent decision
making at each presence and IM server. This only works in cases where
the decision function - the policy decision point - is identical in
each server.
</t>
<t>
An alternative model is to utilize a single point of policy
administration and a single point of policy decisionmaking. Each
presence server acts solely as an enforcement point, asking the policy
server (through a policy protocol of some sort) how to handle the
presence or IM. The policy server then comes back with a policy
decision - whether to proceed with the subscription or IM, and how to
filter and process it. This is shown in <xref target="fig-central-pdp"/>.
</t>
<figure title="Central PDP" anchor="fig-central-pdp"><artwork>
<![CDATA[
+------------+ +---------------+
|Provisioning|=====>|Policy Decision|
| Portal | | Point (PDP) |
+------------+ +---------------+
# # # # #
################### # # # ###########################
# # # # #
# ######## # #################### #
# # +-----------+ # #
# # | | # #
# # | | .... root # #
# # | Server | # #
# # | | # #
# # | | # #
# # +-----------+ # #
# # / --- # #
# # / ---- # #
# # / ---- # #
# # / ---- # #
# # V -V# #
# +-----------+ +-----------+ #
# | | | | #
# | | | | #
# | Server | | Server | #
# | | | | #
# | | | | #
# +-----------+ +-----------+ #
# | --- #
# | ----- #
# | ----- #
# | ----- #
# | ----- #
# | ----- #
# V --V #
# +-----------+ +-----------+ #
# | | | | #
#######| | | | #
| Server | | Server |###
| | | |
| | | |
+-----------+ +-----------+
===== Provisioning Protocol
##### Policy Protocol
----- SIP
]]></artwork></figure>
<t>
The centralized PDP has the benefits of central provisioning,
and consistent policy operation, and decouples policy decision making
from presence and IM processing. This decoupling allows for multiple
presence and IM servers, but still allows for a single policy function
overall. The individual presence and IM servers don't need to know
about the policies themselves, or even know when they change. Of
course, if a server is caching the results of a policy decision,
change notifications are required from the PDP to the server,
informing it of the change (alternatively, traditional TTL-based
expirations can be used if delay in updates are acceptable).
</t>
<t>
For the centralized and distributed provisioning approaches, and the
centralized decision approach, the
hierarchical model suffers overall from the fact that the root of the
policy processing may not be tuned to the specific policy needs of the
device that has subscribed. For example, in the use case of
<xref target="fig-unioned-1"/>, presence server 1 may be providing
composition policies tuned to the fact that the device is wireless
with limited display. Consequently, when Bob subscribes from his
mobile device, is presence server 2 is the root, presence server 2 may
add additional data and provide an overall presence document to the
client which is not optimized for that device. This problem is one of
the principal motivations for the peer model, described below.
</t>
</section>
</section>
<section title="Presence Data">
<t>
The hierarhical model is based on the idea that each presence server
in the chain contributes some unique piece of presence information,
composing it with what it receives from its child, and passing it
on. For the overall presence document to be reasonable, several
guidelines need to be followed:
</t>
<list style="symbols">
<t>A presence server must be prepared to receive documents from its
peer containing information that it does not understand, and to
apply unioned composition policies that retain this information,
adding to it the unique information it wishes to contribute.
</t>
<t>
A user interface rendering some presence document provided by its
presence server must be prepared for any kind of presence document
compliant to the presence data model, and must not assume a specific
structure based on the limitations and implementation choices of the
server to which it is paired.
</t>
</list>
<t>
If these basic rules are followed, the overall system provides
functionality equivalent to the combination of the presence
capabilities of the servers contained within it, which is highly
desirable.
</t>
</section>
<section title="Conversation Consistency">
<t>
Unioned federation introduces a particular challenge for conversation
consistency. A user with multiple devices attached to multiple servers
could potentially try to participate in the conversation on multiple
devices at once. This would clearly pose a challenge. There are really
two approaches that produce a sensible user experience.
</t>
<t>
The first approach simulates the "phone experience" with IM. When a
user (say Alice) sends an IM to Bob, and Bob is a unioned user with
two devices on two servers, Bob receives that IM on both
devices. However, when he "answers" by typing a reply from one of
those devices, the conversation continues only on that device. The
other device on the other server receives no further IMs for this
session - either from Alice or from Bob. Indeed, the IM window on
Bob's unanswered device may even disappear to emphasize this fact.
</t>
<t>
This mode of operation, which we'll call uni-device IM, is only
feasible with session mode IM, and its realization using traditional
SIP signaling is described in <xref target="RFC4975"/>.
</t>
<t>
The second mode of operation, called multi-device IM, is more of a
conferencing experience. The initial IM from Alice is delivered to
both Bob's devices. When Bob answers on one, that response is shown to
ALice but is also rendered on Bob's other device. Effectively, we have
set up an IM conference where each of Bob's devices is an independent
participant in the conference. This model is feasible with both
session and pager mode IM; however conferencing works much better
overall with session mode.
</t>
<t>
A related challenge is conversation history. In the uni-device IM
mode, this past history for a user's conversation may be distributed
amongst the different servers, depending on which clients and servers
were involved in the conversation. As with the exclusive model, IM
search and retrieval services may need to access all of the servers on
which a user might be located. This is easier for the unioned case
than the exclusive one, since in the unioned case, the user's location
is on a fixed number of servers based on provisioning. This problem is
even more complicated in IM page mode when multiple devices are
present, due to the limitation of page mode in these configurations.
</t>
<!-- end consistency -->
</section>
<!-- end hierarchical -->
</section>
<section title="Peer Model">
<t>
In the peer model, there is no one root. When a watcher
subscribes to a presentity, that subscription is processed first by
the server to which the watcher is connected (effectively acting as
the root), and then the
subscription is passed to other child presence servers. The same goes
for IM; when a client sends an IM, the IM is processed first by the
server associated with the sender (effectively acting as the root),
and then the IM is passed to the child IM servers. In essence, in
the peer model, there is a per-client hierarchy, with the root being
a function of the client. Consider the
use case in <xref target="fig-unioned-1"/> If Bob has his buddy list
on presence server 1, and it contains Alice, presence server 1 acts as
the root, and then
performs a back-end subscription to presence server 2. However, if
Joe has his buddy list on presence server 2, and his buddy list
contains Alice, presence server 2 acts as the root, and performs a back-end
subscription to presence server 1. Similarly, if Bob sends an IM to
Alice, it is processed first by server 1 and then server 2. If Joe
sends an IM to Alice, it is first processed by server 2 and then
server 1. This is shown in
<xref target="fig-peer"/>.
</t>
<figure title="Peer Model" anchor="fig-peer"><artwork>
<![CDATA[
alice@example.com alice@example.com
+------------+ +------------+
| |<-------------| |<--------+
| | | | |
Connect | Server | | Server | |
Alice | 1 | | 2 | Connect |
+---->| |------------->| | Alice |
| | | | | |
| +------------+ +------------+ |
| \ / |
| \ / |
| \ / |
| \ / |
| \ / |
| \ / |
...|........ \...................../....... .........|........
. . \ / . . .
. . .\ / . . +--------+ .
. | . . \ | +--------+ . . |+------+| .
. | . . | |+------+| . . || || .
. +---+ . . +---+ || || . . || || .
. |+-+| . . |+-+| || || . . |+------+| .
. |+-+| . . |+-+| |+------+| . . +--------+ .
. | | . . | | +--------+ . . /------ / .
. | | . . | | /------ / . . /------ / .
. +---+ . . +---+ /------ / . . --------/ .
. . . --------/ . . .
. . . . . .
............ ............................. ..................
Bob Alice Joe
]]></artwork></figure>
<t>
Whereas the hierarchical model clearly provides the consistency
property, it is not obvious whether a particular deployment of the
peer model provides the consistency property. When policy decision
making is distributed amongst the servers, it ends up being a
function of the composition policies of the individual servers. If Pi()
represents the composition and authorization policies of server i, and
takes as input one or more presence documents provided by its
children, and outputs a presence document, the overall system provides
consistency when:
</t>
<figure><artwork>
<![CDATA[
Pi(Pj()) = Pj(Pi())
]]></artwork></figure>
<t>
which is effectively the commutativity property.
</t>
<section title="Routing">
<t>
Routing in the peer model works similarly to the hierarchical
model. Each server would be configured with the children it
has when it acts as the root. The overall presence routing algorithm then works
as follows:
<list style="symbols">
<t>If a presence server receives a subscription for a presentity from
a particular watcher, and it already has a different subscription
(as identified by dialog identifiers) for that presentity from that
watcher, it rejects the second subscription with an indication of a
loop. This algorithm does rule out the possibility of two instances
of the same watcher subscribing to the same presentity.
</t>
<t>If a presence server receives a subscription for a presentity from
a watcher and it doesn't have one yet for that pair, it processes it
and generates back end subscriptions to each configured child. If a
back-end subscription generates an error due to loop, it proceeds
without that back-end input.
</t>
</list>
</t>
<t>
The algorithm for IM routing works almost identically.
</t>
<t>
For example, consider Bob subscribing to Alice. Bob's client is
supported by server 1. Server 1 has not seen this subscription before,
so it acts as the root and passes it to server 2. Server 2 hasn't seen
it before, so it accepts it (now acting as the child), and sends the
subscription to its child, which is server 1. Server 1 has already
seen the subscription, so it rejects it. Now server 2 basically knows
its the child, and so it generates documents with just its own data.
</t>
<t>
As in the hierarchical case, it is possible to intermix partitioned
and peer models for different users. In the partitioned case, the
routing for hierarchical devolves into the forking routing described
in <xref target="sec-forking"/>. However, intermixing peer and
exclusive federation for different users is challenging. [[OPEN ISSUE:
need to think about this more.]]
</t>
</section>
<section title="Policy">
<t>
The policy considerations for the peer model are very similar to those
of the hierarchical model. However, the root-only policy approach is
non-sensical in the peer model, and cannot be utilized. The
distributed and centralized provisioning approaches apply, and the rules
described above for generating correct results provide correct results
in the peer model as well.
</t>
<t>
However, the centralized PDP model works particularly well in concert
with the peer model. It allows for consistent policy processing
regardless of the type of rules, and has the benefit of having a single point
of provisioning. At the same time, it avoids the need for defining and
having a single root; indeed there is little benefit for utilizing the
hierarchical model when a centralized PDP is used.
</t>
<t>
However, the distributed processing model in the peer model eliminates the
problem described in <xref target="sec-central"/>. The problem is that
composition and authorization policies may be tuned to the needs of
the specific device that is connected. In the hierarchical model, the
wrong server for a particular device may be at the root, and the
resulting presence document poorly suited to the consuming
device. This problem is alleviated in the peer model. The server that
is paired or tuned for that particular user or device is always at the
root of the tree, and its composition policies have the final say in
how presence data is presented to the watcher on that device.
</t>
</section>
<section title="Presence Data">
<t>
The considerations for presence data and composition in the
hierarchical model apply in the peer model as well. The principle
issue is consistency, and whether the overall presence document for a
watcher is the same regardless of which server the watcher connects
from. As mentioned above, consistency is a property of commutativity
of composition, which may or may not be true depending on the
implementation.
</t>
<t>
Interestingly, in the use case of <xref target="fig-unioned-2"/>, a
particular user only ever has devices on a single server, and thus the
peer and hierarchical models end up being the same, and consistency is
provided.
</t>
</section>
<section title="Conversation Consistency">
<t>
The hierarchical and peer models have no impact on the issue of
conversation consistency; the problem exists identically for both
approaches.
</t>
</section>
<!-- end peer model -->
</section>
<!-- end unioned -->
</section>
<section title="Summary">
<t>
This document doesn't make any recommendation as to which models is
best. Each model has different areas of applicability and are
appropriate in a particular deployment.
</t>
</section>
<section title="Future Considerations">
<t>
There are some additional concepts that can be considered, which have
not yet been explored. One of them is routing of PUBLISH requests
between systems. This can be used as part of the unioned models and
requires further discussion.
</t>
<t>
Another big issue is data federation. For the unioned models in
particular, there is typically a desire to be able to add a buddy on
one system and have it appear on another, or to add a user to a
whitelist on one system and have that reflect in the other. This
requires some kind of standardized data interfaces and is for further
consideration.
</t>
</section>
<section title="Acknowledgements">
<t>
The author would like to thank Paul Fullarton, David Williams, Sanjay
Sinha, and Paul Kyzivat for their comments.
</t>
</section>
<section title="Security Considerations">
<t>
The principle issue in intra-domain federation is that of privacy. It
is important that the system meets user expectations, and even in
cases of user provisioning errors or inconsistencies, it provides
appropriate levels of privacy. This is an issue in the unioned models,
where user privacy policies can exist on multiple servers at the same
time. The guidelines described here for authorization policies help
ensure that privacy properties are maintained.
</t>
</section>
<section title="IANA Considerations">
<t>
There are no IANA considerations associated with this specification.
</t>
</section>
</middle>
<back>
<references title="Informative References">
<?rfc include="reference.RFC.2778"?>
<?rfc include="reference.RFC.3863"?>
<?rfc include="reference.RFC.4479"?>
<?rfc include="reference.RFC.3856"?>
<?rfc include="reference.RFC.4662"?>
<?rfc include="reference.RFC.3944"?>
<?rfc include="reference.RFC.3325"?>
<?rfc include="reference.RFC.3680"?>
<?rfc include="reference.RFC.3428"?>
<?rfc include="reference.RFC.4975"?>
<?rfc include="reference.RFC.3261"?>
<?rfc include="reference.I-D.ietf-speermint-consolidated-presence-im-usecases"?>
<?rfc include="reference.I-D.ietf-simple-view-sharing"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 01:03:37 |