One document matched: draft-rosenberg-simple-intradomain-federation-00.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 Federation">
Models for Intra-Domain Presence 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>
<date month="November" year="2007" />
<area>RAI</area>
<workgroup>SIMPLE</workgroup>
<keyword>SIP</keyword>
<keyword>SIMPLE</keyword>
<keyword>presence</keyword>
<keyword>federation</keyword>
<abstract>
<t>Presence federation involves the sharing of presence
information across multiple presence systems. Most often,
presence 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 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 SIP-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>
Most often, presence federation is considered in the context of
interconnection between different domains, also known as inter-domain
presence 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 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 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>
However, federation can happen within a domain as well. We define
intra-domain federation as the interconnection of presence servers
within a single domain, where domain refers explicity to the right
hand side of the @-sign in the SIP URI. A single domain can have
multiple presence systems for several reasons:
<list style="symbols">
<t>The domain may
be very large, and for purposes of scale, requires several different
presence servers. However, intra-domain federation is not the same as
clustering, which is also done for scale. Clustering involves a
tight synchronization and coordination across servers, always of
the same vendor. Intra-domain federation involves much looser
coupling and can be between vendors.</t>
<t>The domain may be divided up organizationally in such a way that
different users are served by different parts of organization, and
each part of the organization manages its own presence servers.
</t>
<t>A domain has chosen multiple vendors for its presence
infrastructure, each having their own servers.
</t>
</list>
</t>
<t>
When considering architectures for intra-domain presence federation,
several issues need to be considered:
<list style="hanging">
<t hangText="Routing:"> How are subscriptions routed to the right
presence 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 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="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>
</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, and composition work.
</t>
</section>
<section title="Partitioned">
<t>
In the partitioned model, a single domain has a multiplicity of
presence servers, each of which manages a non-overlapping set of
users. That is, for each user in the domain, their presence data and
policy reside on a single server. Each "single server" may in fact be
physically implemented on more than one box, for the purposes of
scale or high availability. However, the key
definition of "single server" here is that it represents an isolated
presence functionality that operates independently of any of the
others.
</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>
</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 cause the domain
to be managed by a multiplicity of independent servers.
</t>
<t>
One common use case 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>
<t>
Another common use case is an organization that is just very large, and
their size exceeds the capacity that a single "server" 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. The word "server"
is used in quotes above because, in fact, each such "server" might be
a clustered set of servers from a particular vendor. Clustering is not
the same as intra-domain federation; clustering involves a tightly
coupled coordination between servers of the same vendor. Intra-domain
federation involves a looser coupling - only using standards-based
protocols and possibly involving multiple vendors.
</t>
<t>
Yet another common use case 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>
Another use case is one where certain vendors might specialize in
specific types of clients, or
provide features or presence data that are unique, such that a domain
might wish to use clients from a multiplicity of vendors, depending on
the needs of its users. For example, one vendor might
provide a mobile client (but no desktop client), while another
provides a desktop client but no mobile client. A domain might want
some users to have a mobile client, while others have the desktop
client. This leads to the partitioned model.
</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 from the watcher's domain to the
domain of the presentity. 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>
<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. 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 SUBSCRIBE 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 alice | | .
. +---------------> | Routing | .
. | | Proxy | .
. | | | .
. | +-----------+ .
. | | .
. | | .
. | | .
. | |SUB 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. Instead of a
centralized database, there would be a centralized SIP proxy
farm. Server 1 would send subscriptions 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
subscriptions 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.
</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, which can be a scale challenge.
</t>
</section>
<section title="Subdomaining">
<t>
In this solution, each user is associated with a subdomain, and is
provisioned as part of their respective presence server using that
subdomain. Consequently, each presence 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 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 | .
. | | | | | | | | .
. | | +-----------+ +-----------+ +-----------+ .
. | | ^ .
. | | | .
. | | | .
. | | | .
. | | | .
. | | | .
. | | +-----------+ .
. | +-------------------->| | .
. | | Watcher | .
. | | | .
. +-----------------------| | .
. +-----------+ .
. .
. .
. .
. 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 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.
</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 create a back-end subscription for a user it doesn't have, it forks
the SUBSCRIBE 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 presence
servers can differentiate inbound SUBSCRIBE requests from end users
(which cause back-end subscriptions to get forked) and from other
servers (which do not cause back-end subscriptions). 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>
<section title="Unioned">
<t>
In the unioned model, each user is actually served by more than one
presence server. 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 </t>
</list>
<t>
In essence, in the unioned model, a user's presence data is
distributed across many presence servers. In the partitioned model,
its centralized in a single presence server.
</t>
<t>
This definition speaks specifically to ownership of presence data 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 and notifications flowing
between servers, and the user is potentially provisioned on both,
there is no authoritative presence 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.
</t>
</list>
</t>
<section title="Applicability">
<t>
The unioned models arise naturally for several reasons.
</t>
<t>
Firstly, 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
endpoints work only (or only work well) with the server from the same
vendor. In addition, certain vendors might specialize in specific
types of clients, or provide features that are unique, such that a
domain might wish to use clients from a multiplicity of vendors. For
example, one vendor might provide a mobile client (but no desktop
client), while another provides a desktop client but no mobile
client. 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 the unioned case. This is shown in
<xref target="fig-unioned-1"/>. Another example is where one vendor
that provides a business telephone with presence, but no desktop
client, while another provides a deskop client but no business
telephone.
</t>
<figure title="Unioned Case 1" anchor="fig-unioned-1"><artwork>
<![CDATA[
alice@example.com alice@example.com
+------------+ +------------+
| | | |
| Presence | | Presence |
| Server |--------------| Server |
| 1 | | 2 |
| | | |
| | | |
+------------+ +------------+
\ /
\ /
\ /
\ /
\ /
\ /
\...................../.......
\ / .
.\ / .
. \ | +--------+ .
. | |+------+| .
. +---+ || || .
. |+-+| || || .
. |+-+| |+------+| .
. | | +--------+ .
. | | /------ / .
. +---+ /------ / .
. --------/ .
. .
.............................
Alice
]]></artwork></figure>
<t>
Secondly, 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 is
can be determined manually (where the user enters and updates the
information), or automatically. Automatic determination of these
states is far preferable, since it put 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.</t>
<t>Consequently, though a user may have all of their devices connected
to and associated with a single presence server, that presence
server may have 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"/>.
</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 presence servers, typically running in a
partitioned configuration. The servers are organized regionally so
that each user is served by a presence 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 presence
state existing on both servers at the same time.
</t>
</section>
<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 for the presentity
in question are always routed first to one of the servers - the root -
and then the root presence server subscribes to the next layer of
presence servers (which may, in turn, subscribe to the presence state
in other presence servers). Each presence server composes the presence
information it receives from its children, applying local
authorization and composition policies, and then passes the results up
to the higher layer. This is shown in
<xref target="fig-hierarchical"/>.
</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 presence server needs to be
provisioned with the root, its parent and its children presence servers for each
presentity it handles. These relationships could in fact be different
on a presentity-by-presentity basis; however, this is complex to
manage. In all likelihood, the parent and child relationships are
identical for each presentities. 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.
</t>
<t>
If a SUBSCRIBE is received from a node that is not the parent node for
this presentity, proxy the SUBSCRIBE to the parent node. This includes
cases where the node that sent the SUBSCRIBE 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 the "natural" routing algorithm for partitioned models.
</t>
<t>
An important property of the routing in the hierarchical model is that
the sequence of composition and policy operations are identical for
all watchers to that presentity, regardless of which presence server
they are associated with. The result is that the overall presence
state provided to a watcher is always consistent and independent of
the server the watcher is connected to. We call this property the
*consistency property*, and it is an important metric in assessing the
correctness of a federated presence 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 the server performing the back-end subscription.
</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.
</t>
<t>
The principle challenge in a unioned presence 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 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[
+-----------+
*-----------* | |
|Auth and |---->| Presence | <--- root
|Composition| | Server |
*-----------* | |
| |
+-----------+
/ ---
/ ----
/ ----
/ ----
V -V
+-----------+ +-----------+
| | | |
| Presence | | Presence |
| Server | | Server |
| | | |
| | | |
+-----------+ +-----------+
| ---
| -----
| -----
| -----
| -----
| -----
V --V
+-----------+ +-----------+
| | | |
| Presence | | Presence |
| Server | | Server |
| | | |
| | | |
+-----------+ +-----------+
]]></artwork></figure>
<t>
As long as the 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. 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, the purpose of the multiplicity of presence
servers is because each has access to and specializes in manipulation
of certain pieces of presence state. 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 presence server is separately
provisioned with its own policies, including what users are allowed to
watch, what presence data they will get, and how it will be composed.
</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>
Firstly, 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.
</t>
</list>
</t>
<t>
Things get more complicated when one considers 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.
</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 containg
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>
For both the centralized and distributed provisioning approaches, 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>
<!-- 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. In essence, in
the peer model, there is a per-watcher hierarchy, with the root being
a function of the watcher. 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. This is shown in
<xref target="fig-peer"/>.
</t>
<figure title="Peer Model" anchor="fig-peer"><artwork>
<![CDATA[
alice@example.com alice@example.com
+------------+ +------------+
| |<-------------| |<--------+
SUB | Presence | | Presence | |
List w/| Server | | Server | SUB |
Alice | 1 | | 2 | List w/|
+---->| |------------->| | 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. 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 presence server would be configured with the children it
has when it acts as the root. The overall 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 watchers
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>
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"/>.
</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>
In addition, the policy processing 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>
<!-- 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>
</section>
<section title="Acknowledgements">
<t>
The author would like to thank Paul Fullarton, David Williams 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.I-D.ietf-speermint-consolidated-presence-im-usecases"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 05:41:28 |