< draft-ietf-simple-intradomain-federation-04.txt   draft-ietf-simple-intradomain-federation-05.txt >
SIMPLE J. Rosenberg SIMPLE J. Rosenberg
Internet-Draft Cisco Internet-Draft jdrosen.net
Intended status: Informational A. Houri Intended status: Informational A. Houri
Expires: January 14, 2010 IBM Expires: November 13, 2010 IBM
C. Smyth C. Smyth
Avaya Avaya
F. Audet F. Audet
Nortel Skype
July 13, 2009 May 12, 2010
Models for Intra-Domain Presence and Instant Messaging (IM) Bridging Models for Intra-Domain Presence and Instant Messaging (IM) Bridging
draft-ietf-simple-intradomain-federation-04 draft-ietf-simple-intradomain-federation-05
Abstract
Presence and Instant Messaging (IM) bridging involves the sharing of
presence information and exchange of IM across multiple systems
within a single domain. As such, it is a close cousin to presence
and IM federation, which involves the sharing of presence and IM
across differing domains. Presence and IM bridging 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 bridging. It is
meant to provide a framework for defining requirements and
specifications for presence and IM bridging. The document assumes
SIP as the underlying protocl but many of the modles can fit other
protocols as well.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79.
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on November 13, 2010.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 14, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Presence and Instant Messaging (IM) bridging involves the sharing of This document may contain material from IETF Documents or IETF
presence information and exchange of IM across multiple systems Contributions published or made publicly available before November
within a single domain. As such, it is a close cousin to presence 10, 2008. The person(s) controlling the copyright in some of this
and IM federation, which involves the sharing of presence and IM material may not have granted the IETF Trust the right to allow
across differing domains. Presence and IM bridging can be the result modifications of such material outside the IETF Standards Process.
of a multi-vendor network, or a consequence of a large organization Without obtaining an adequate license from the person(s) controlling
that requires partitioning. This document examines different use the copyright in such materials, this document may not be modified
cases and models for intra-domain presence and IM bridging. It is outside the IETF Standards Process, and derivative works of it may
meant to provide a framework for defining requirements and not be created outside the IETF Standards Process, except to format
specifications for presence and IM bridging. it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Intra-Domain Bridging vs. Clustering . . . . . . . . . . . . . 8 2. Intra-Domain Bridging vs. Clustering . . . . . . . . . . . . . 8
3. Use Cases for Intra-Domain Bridging . . . . . . . . . . . . . 9 3. Use Cases for Intra-Domain Bridging . . . . . . . . . . . . . 9
3.1. Scale . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Scale . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Organizational Structures . . . . . . . . . . . . . . . . 9 3.2. Organizational Structures . . . . . . . . . . . . . . . . 9
3.3. Multi-Vendor Requirements . . . . . . . . . . . . . . . . 10 3.3. Multi-Vendor Requirements . . . . . . . . . . . . . . . . 9
3.4. Specialization . . . . . . . . . . . . . . . . . . . . . . 10 3.4. Specialization . . . . . . . . . . . . . . . . . . . . . . 10
4. Considerations for Bridging Models . . . . . . . . . . . . . . 11 4. Considerations for Bridging Models . . . . . . . . . . . . . . 11
5. Overview of the Models . . . . . . . . . . . . . . . . . . . . 11 5. Overview of the Models . . . . . . . . . . . . . . . . . . . . 11
6. Partitioned . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Partitioned . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 14 6.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 14
6.2. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.2. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.2.1. Centralized Database . . . . . . . . . . . . . . . . . 15 6.2.1. Centralized Database . . . . . . . . . . . . . . . . . 15
6.2.2. Routing Proxy . . . . . . . . . . . . . . . . . . . . 16 6.2.2. Routing Proxy . . . . . . . . . . . . . . . . . . . . 16
6.2.3. Subdomaining . . . . . . . . . . . . . . . . . . . . . 17 6.2.3. Subdomaining . . . . . . . . . . . . . . . . . . . . . 17
6.2.4. Peer-to-Peer . . . . . . . . . . . . . . . . . . . . . 19 6.2.4. Peer-to-Peer . . . . . . . . . . . . . . . . . . . . . 19
skipping to change at page 3, line 48 skipping to change at page 3, line 48
8. Unioned . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 8. Unioned . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
8.1. Hierarchical Model . . . . . . . . . . . . . . . . . . . . 29 8.1. Hierarchical Model . . . . . . . . . . . . . . . . . . . . 29
8.1.1. Routing . . . . . . . . . . . . . . . . . . . . . . . 31 8.1.1. Routing . . . . . . . . . . . . . . . . . . . . . . . 31
8.1.2. Policy and Identity . . . . . . . . . . . . . . . . . 32 8.1.2. Policy and Identity . . . . . . . . . . . . . . . . . 32
8.1.2.1. Root Only . . . . . . . . . . . . . . . . . . . . 33 8.1.2.1. Root Only . . . . . . . . . . . . . . . . . . . . 33
8.1.2.2. Distributed Provisioning . . . . . . . . . . . . . 34 8.1.2.2. Distributed Provisioning . . . . . . . . . . . . . 34
8.1.2.3. Central Provisioning . . . . . . . . . . . . . . . 36 8.1.2.3. Central Provisioning . . . . . . . . . . . . . . . 36
8.1.2.4. Centralized PDP . . . . . . . . . . . . . . . . . 38 8.1.2.4. Centralized PDP . . . . . . . . . . . . . . . . . 38
8.1.3. Presence Data . . . . . . . . . . . . . . . . . . . . 40 8.1.3. Presence Data . . . . . . . . . . . . . . . . . . . . 40
8.1.4. Conversation Consistency . . . . . . . . . . . . . . . 41 8.1.4. Conversation Consistency . . . . . . . . . . . . . . . 41
8.2. Peer Model . . . . . . . . . . . . . . . . . . . . . . . . 41 8.2. Peer Model . . . . . . . . . . . . . . . . . . . . . . . . 42
8.2.1. Routing . . . . . . . . . . . . . . . . . . . . . . . 43 8.2.1. Routing . . . . . . . . . . . . . . . . . . . . . . . 44
8.2.2. Policy . . . . . . . . . . . . . . . . . . . . . . . . 44 8.2.2. Policy . . . . . . . . . . . . . . . . . . . . . . . . 44
8.2.3. Presence Data . . . . . . . . . . . . . . . . . . . . 44 8.2.3. Presence Data . . . . . . . . . . . . . . . . . . . . 45
8.2.4. Conversation Consistency . . . . . . . . . . . . . . . 45 8.2.4. Conversation Consistency . . . . . . . . . . . . . . . 45
9. More about Policy . . . . . . . . . . . . . . . . . . . . . . 45 9. More about Policy . . . . . . . . . . . . . . . . . . . . . . 45
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 46 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 46
11. Security Considerations . . . . . . . . . . . . . . . . . . . 46 11. Security Considerations . . . . . . . . . . . . . . . . . . . 46
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
13. Informative References . . . . . . . . . . . . . . . . . . . . 46 13. Informative References . . . . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48
1. Introduction 1. Introduction
Presence refers to the ability, willingness and desire to communicate Presence refers to the ability, willingness and desire to communicate
across differing devices, mediums and services [RFC2778]. Presence across differing devices, mediums and services [RFC2778]. Presence
is described using presence documents [RFC3863] [RFC4479], exchanged is described using presence documents [RFC3863] [RFC4479], exchanged
using a Session Initiation Protocol (SIP) [RFC3261] based event using a Session Initiation Protocol (SIP) [RFC3261] based event
package [RFC3856]. Similarly, instant messaging refers to the package [RFC3856]. Similarly, instant messaging refers to the
exchange of real-time text-oriented messaging between users. SIP exchange of real-time text-oriented messaging between users. SIP
defines two mechanisms for IM - pager mode [RFC3428] and session mode defines two mechanisms for IM - pager mode [RFC3428] and session mode
skipping to change at page 7, line 36 skipping to change at page 7, line 36
. | | . . | | . . | | . . | | .
. +-------+ . . +-------+ . . +-------+ . . +-------+ .
. . . . . . . .
. Alice's . . Bob's . . Alice's . . Bob's .
. PC . . PC . . PC . . PC .
. . . . . . . .
............................. .............................. ............................. ..............................
example.org example.com example.org example.com
Figure 2: Inter-Domain IM Model Figure 2: Inter-Domain SIP based IM Model
In this model, example.org and example.com both have an "IM server". 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 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 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 case of session mode). The IM server would handle routing of the IM
along with application of IM policy. along with application of IM policy.
Though both of these pictures show federation between domains, a Though both of these pictures show federation between domains, a
similar interconnection - presence and IM bridging - can happen similar interconnection - presence and IM bridging - can happen
within a domain as well. We define intra-domain bridging as the within a domain as well. We define intra-domain bridging as the
skipping to change at page 8, line 24 skipping to change at page 8, line 24
best. Each model has different areas of applicability and are best. Each model has different areas of applicability and are
appropriate in a particular deployment. The intent is to provide appropriate in a particular deployment. The intent is to provide
informative material and ideas on how this can be done. informative material and ideas on how this can be done.
2. Intra-Domain Bridging vs. Clustering 2. Intra-Domain Bridging vs. Clustering
Intra-domain bridging is the interconnection of servers within a Intra-domain bridging is the interconnection of servers within a
single domain. This is very similar to clustering, which is the single domain. This is very similar to clustering, which is the
tight coupling of a multiplicity of physical servers to realize scale tight coupling of a multiplicity of physical servers to realize scale
and/or high availability. Consequently, it is important to clarify and/or high availability. Consequently, it is important to clarify
the differences. the differences. Note that clustering is out of scope for this
document.
Firstly, clustering implies a tight coupling of components. Firstly, clustering implies a tight coupling of components.
Clustering usually involves proprietary information sharing, such as Clustering usually involves proprietary information sharing, such as
database replication and state sharing, which in turn are tightly state sharing, which in turn are tightly bound with the internal
bound with the internal implementation of the product. Intra-domain implementation of the product. Intra-domain bridging, on the other
bridging, on the other hand, is a loose coupling. Database hand, is a loose coupling. Although database replication may be used
replication or state replication across federated systems are across bridged systems, it is not in the same level of stats
extremely rare (though a database and DB replication might be used replication that usually occurs in clusters.
within a component providing routing functions to facilitate
bridging).
Secondly, clustering most usually occurs amongst components from the Secondly, clustering most usually occurs amongst components from the
same vendor. This is due to the tight coupling described above. same vendor. This is due to the tight coupling described above.
Intra-domain bridging, on the other hand, can occur between servers Intra-domain bridging, on the other hand, can occur between servers
from different vendors. As described below, this is one of the chief from different vendors. As described below, this is one of the chief
use cases for intra-domain bridging. use cases for intra-domain bridging.
Thirdly, clustering is almost always invisible to users. Thirdly, clustering is almost always invisible to users.
Communications between users within the same cluster almost always Communications between users within the same cluster almost always
have identical functionality to communications between users on the have identical functionality to communications between users on the
skipping to change at page 9, line 16 skipping to change at page 9, line 15
Fourthly, connections between federated and bridged systems almost Fourthly, connections between federated and bridged systems almost
always involve standards, whereas communications within a cluster always involve standards, whereas communications within a cluster
often involves proprietary mechanisms. Standards are needed for often involves proprietary mechanisms. Standards are needed for
bridging because the systems can be from different vendors, and thus bridging because the systems can be from different vendors, and thus
agreement is needed to enable interoperation. agreement is needed to enable interoperation.
Finally, a cluster will often have an upper bound on its size and Finally, a cluster will often have an upper bound on its size and
capacity, due to some kind of constraint on the coupling between capacity, due to some kind of constraint on the coupling between
nodes in the cluster. However, there is typically no limit, or a nodes in the cluster. However, there is typically no limit, or a
much larger limit, on the number of bridged systems that can be put much larger limit, on the number of bridged systems that can be put
into a domain. This is a consequence to their loose coupling. into a domain. This is a consequence of their loose coupling.
Though these rules are not hard and fast, they give general Though these rules are not hard and fast, they give general
guidelines on the differences between clustering and intra-domain guidelines on the differences between clustering and intra-domain
bridging. bridging.
3. Use Cases for Intra-Domain Bridging 3. Use Cases for Intra-Domain Bridging
There are several use cases that drive intra-domain bridging. There are several use cases that drive intra-domain bridging.
3.1. Scale 3.1. Scale
skipping to change at page 12, line 37 skipping to change at page 12, line 37
V V
UNIONED UNIONED
Figure 3: Decision Tree Figure 3: Decision Tree
The first question is whether any particular user is 'managed' by The first question is whether any particular user is 'managed' by
just one system, or more than one? Here, 'managed' means that the just one system, or more than one? Here, 'managed' means that the
user is provisioned on the system, and can use it for some kind of user is provisioned on the system, and can use it for some kind of
presence and IM services. In the partitioned model, the answer is no presence and IM services. In the partitioned model, the answer is no
- a user is on only one system. In that way, partitioned federation - a user is on only one system. In that way, partitioned bridging is
is analagous to an inter-domain model where a user is handled by a analagous to an inter-domain model where a user is handled by a
single domain. single domain.
If a user is 'managed' by more than one system, is it more than one If a user is 'managed' by more than one system, is it more than one
at the same time, or only one at a time? In the exclusive model, its at the same time, or only one at a time? In the exclusive model, it
one at a time. The user can log into one system, log out, and then is one at a time. The user can log into one system, log out, and
log into the other. For example, a user might have a PC client then log into the other. For example, a user might have a PC client
connected to system one, and a different PC client connected to connected to system one, and a different PC client connected to
system two. They can use one or the other, but not both. In unioned system two. They can use one or the other, but not both. In unioned
federation, they can be connected to more than one at the same time. bridging, they can be connected to more than one at the same time.
For example, a user might have a mobile client connected to one For example, a user might have a mobile client connected to one
system, and a PC client connected to another. system, and a PC client connected to another.
6. Partitioned 6. Partitioned
In the partitioned model, a single domain has a multiplicity of In the partitioned model, a single domain has a multiplicity of
servers, each of which manages a non-overlapping set of users. That 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 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 handling reside on a single server. Each "single server" may in fact
be a cluster. be a cluster.
skipping to change at page 14, line 32 skipping to change at page 14, line 32
Figure 4: Partitioned Model Figure 4: Partitioned Model
6.1. Applicability 6.1. Applicability
The partitioned model arises naturally in larger domains, such as an The partitioned model arises naturally in larger domains, such as an
enterprise or service provider, where issues of scale, organizational enterprise or service provider, where issues of scale, organizational
structure, or multi-vendor requirements cause the domain to be structure, or multi-vendor requirements cause the domain to be
managed by a multiplicity of independent servers. managed by a multiplicity of independent servers.
In cases where each user has an AoR that directly points to its In cases where each user has an AoR (Address of Record) that directly
partition (for example, us.example.com), that model becomes identical points to its partition (for example, us.example.com), that model
to the inter-domain federated model and is not treated here further. becomes identical to the inter-domain federated model and is not
treated here further.
6.2. Routing 6.2. Routing
The partitioned intra-domain model works almost identically to an The partitioned intra-domain model works almost identically to an
inter-domain federated model, with the primary difference being inter-domain federated model, with the primary difference being
routing. In inter-domain federation, the domain part of the URI can routing. In inter-domain federation, the domain part of the URI can
be used to route presence subscriptions and IM messages from one 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 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, model. Consider the case where Joe subscribes to his buddy list,
which is served by his presence server (server 1 in Figure 4). Alice which is served by his presence server (server 1 in Figure 4). Alice
skipping to change at page 19, line 25 skipping to change at page 19, line 25
proxies can be implemented. A client would send the SIP request to proxies can be implemented. A client would send the SIP request to
one of the redirect proxies and the redirect proxy will reply with one of the redirect proxies and the redirect proxy will reply with
the right domain after consulting the database in whatever protocol the right domain after consulting the database in whatever protocol
the databases exposes. the databases exposes.
6.2.4. Peer-to-Peer 6.2.4. Peer-to-Peer
Another model is to utilize a peer-to-peer network amongst all of the 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 servers, and store URI to server mappings in the distributed hash
table it creates. This has some nice properties but does require a table it creates. This has some nice properties but does require a
standardized and common p2p protocol across vendors, which is being standardized and common peer-to-peer protocol across vendors.
worked on in the P2PSIP IETF working gorup but still does not exist
today.
6.2.5. Forking 6.2.5. Forking
Yet another solution is to utilize forking. Each server is Yet another solution is to utilize forking. Each server is
provisioned with the domain names or IP addresses of the other provisioned with the domain names or IP addresses of the other
servers, but not with the mapping of users to each of those servers. 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, 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 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, 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 and accepted on the one that does. The approach assumes that servers
skipping to change at page 22, line 22 skipping to change at page 22, line 18
Fortunately, most of the routing approaches described for partitioned Fortunately, most of the routing approaches described for partitioned
bridging, excepting provisioned routing, can be adapted for exclusive bridging, excepting provisioned routing, can be adapted for exclusive
bridging. bridging.
7.1.1. Centralized Database 7.1.1. Centralized Database
A centralized database can be used, but will need to support a test- 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 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 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 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 server, a redirect (or some other error message) will be sent to that
user. user.
When a client sends a subscription request for some target user, and When a client sends a subscription request for some target user, and
the target user is not associated with a server yet, the subscription 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 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 connects and becomes bound to a server, the database needs to send a
change notification to the watching server, so that the 'held' change notification to the watching server, so that the 'held'
subscription can be extended to the server which is now handling subscription can be extended to the server which is now handling
presence for the user. presence for the user.
skipping to change at page 23, line 31 skipping to change at page 23, line 28
to all clients which have ongoing sessions (presence and IM) with to all clients which have ongoing sessions (presence and IM) with
that user. This requires a large-scale change notification mechanism that user. This requires a large-scale change notification mechanism
- to each client in the network. - to each client in the network.
7.1.4. Peer-to-Peer 7.1.4. Peer-to-Peer
Peer-to-peer routing can be used for routing in exclusive bridging. Peer-to-peer routing can be used for routing in exclusive bridging.
Essentially, it provides a distributed registrar function that maps Essentially, it provides a distributed registrar function that maps
each AoR to the particular server that they are currently registered each AoR to the particular server that they are currently registered
against. When a UA registers to a particular server, that against. When a UA registers to a particular server, that
registration is written into the P2P network, such that queries for registration is written into the P2P (Peer to Peer) network, such
that user are directed to that presence server. that queries for that user are directed to that presence server.
However, change notifications can be troublesome. When a user However, change notifications can be troublesome. When a user
registered on server 1 now registers on server 2, server 2 needs to 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, 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 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. to terminate its ongoing subscriptions and send the to server 2.
Furthermore, P2P networks do not inherently provide a test-and-set Furthermore, P2P networks do not inherently provide a test-and-set
primitive, and consequently, it is possible for race conditions to primitive, and consequently, it is possible for race conditions to
occur where there is an inconsistent view on where the user is occur where there is an inconsistent view on where the user is
currently registered. currently registered.
7.1.5. Forking 7.1.5. Forking
skipping to change at page 24, line 19 skipping to change at page 24, line 15
to all other servers. If the user is currently registered somewhere, 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 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 is registered nowhere, all others generate a 404. If the request is
a subscription, the server that received it would 'hold' the a subscription, the server that received it would 'hold' the
subscription, and then subscribe for the reg-event package on every subscription, and then subscribe for the reg-event package on every
other server for the target user. Once the target user registers other server for the target user. Once the target user registers
somewhere, the server holding the subscription gets a notification somewhere, the server holding the subscription gets a notification
and can propagate it to the new target server. and can propagate it to the new target server.
Like the P2P solution, the forking solution lacks an effective test- Like the P2P solution, the forking solution lacks an effective test-
and- set mechanism, and it is therefore possible that there could be and-set mechanism, and it is therefore possible that there could be
inconsistent views on which server is handling a user. One possible inconsistent views on which server is handling a user. One possible
scenario where multiple servers will think that thy are serving the scenario where multiple servers will think that thy are serving the
user would be when a subscription request is forked and reaches to user would be when a subscription request is forked and reaches to
multiple servers, each of them thinks that it serves the user. multiple servers, each of them thinks that it serves the user.
7.2. Policy 7.2. Policy
Unless policy is somehow managed in the same database and is accessed Unless policy is somehow managed in the same database and is accessed
by the servers in the exclusive bridging model, policy becomes more by the servers in the exclusive bridging model, policy becomes more
complicated in the exclusive bridging model. In the partitioned complicated in the exclusive bridging model. In the partitioned
skipping to change at page 32, line 21 skipping to change at page 32, line 21
algorithm of Section 6.2.5. This points to the forking algorithm as algorithm of Section 6.2.5. This points to the forking algorithm as
a good choice since it can be used for both partitioned and unioned. a good choice since it can be used for both partitioned and unioned.
An important property of the routing in the hierarchical model is An important property of the routing in the hierarchical model is
that the sequence of composition and policy operations for any IM or that the sequence of composition and policy operations for any IM or
presence session is identical, regardless of the watcher or sender of presence session is identical, regardless of the watcher or sender of
the IM. The result is that the overall presence state provided to a the IM. The result is that the overall presence state provided to a
watcher, and overall IM behavior, is always consistent and watcher, and overall IM behavior, is always consistent and
independent of the server the client is connected to. We call this independent of the server the client is connected to. We call this
property the *consistency property*, and it is an important metric in property the *consistency property*, and it is an important metric in
assessing the correctness of a federated presence and IM system. assessing the correctness of a bridged presence and IM system.
8.1.2. Policy and Identity 8.1.2. Policy and Identity
Policy and identity are a clear challenge in the unioned model. Policy and identity are a clear challenge in the unioned model.
Firstly, since a user is provisioned on many servers, it is possible Firstly, since a user is provisioned on many servers, it is possible
that the identifier they utilize could be different on each server. that the identifier they utilize could be different on each server.
For example, on server 1, they could be joe@example.com, whereas on 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 server 2, they are joe.smith@example.com. In cases where the
identifiers are not equivalent, a mapping function needs to be identifiers are not equivalent, a mapping function needs to be
provisioned. This ideally happens on root server. provisioned. This ideally happens on root server.
Secondly, the unioned model will result in back-end subscriptions Secondly, the unioned model will result in back-end subscriptions
extending from one presence server to another presence server. These extending from one presence server to another presence server. These
subscriptions, though made by the presence server, need to be made subscriptions, though made by the presence server, need to be made
on- behalf-of the user that originally requested the presence state on-behalf-of the user that originally requested the presence state of
of the presentity. Since the presence server extending the back-end the presentity. Since the presence server extending the back-end
subscription will not often have credentials to claim identity of the subscription will not often have credentials to claim identity of the
watcher, asserted identity using techniques like P-Asserted-ID watcher, asserted identity using techniques like P-Asserted-ID
[RFC3325] or authenticated identity [RFC4474] are required, along [RFC3325] or authenticated identity [RFC4474] are required, along
with the associated trust relationships between servers. with the associated trust relationships between servers.
Optimizations, such as view sharing [I-D.ietf-simple-view-sharing] Optimizations, such as view sharing [I-D.ietf-simple-view-sharing]
can help improve performance. The same considerations apply for IM. can help improve performance. The same considerations apply for IM.
The principle challenge in a unioned model is policy, including both The principle challenge in a unioned model is policy, including both
authorization and composition policies. There are three potential authorization and composition policies. There are three potential
solutions to the administration of policy in the hierarchical model solutions to the administration of policy in the hierarchical model
skipping to change at page 35, line 36 skipping to change at page 35, line 36
o If a presence server does not understand a piece of presence data o If a presence server does not understand a piece of presence data
provided by its child, it should not attempt to apply its own provided by its child, it should not attempt to apply its own
authorization policies to access of that information. authorization policies to access of that information.
o A presence server should not add information to a presence o A presence server should not add information to a presence
document that overlaps with information that can be added by its document that overlaps with information that can be added by its
parent. Of course, it is very hard for a presence server to know parent. Of course, it is very hard for a presence server to know
whether this information overlaps. Consequently, provisioned whether this information overlaps. Consequently, provisioned
composition rules will be required to realize this. composition rules will be required to realize this.
if these rules are followed, the overall system provides privacy If these rules are followed, the overall system provides privacy
safety and the overall policy applied is reasonable. This is because safety and the overall policy applied is reasonable. This is because
these rules effectively segment the application of policy based on these rules effectively segment the application of policy based on
specific data, to the servers that own the corresponding data. For specific data, to the servers that own the corresponding data. For
example, consider once more the geolocation use case described above, example, consider once more the geolocation use case described above,
and assume server 2 is the root. If server 1 has access to, and and assume server 2 is the root. If server 1 has access to, and
provides geolocation information in presence documents it produces, provides geolocation information in presence documents it produces,
then server 1 would be the only one to provide authorization policies then server 1 would be the only one to provide authorization policies
governing geolocation. Server 2 would receive presence documents governing geolocation. Server 2 would receive presence documents
from server 1 containing (or not) geolocation, but since it doesn't from server 1 containing (or not) geolocation, but since it doesn't
provide or control geolocation, it lets that information pass provide or control geolocation, it lets that information pass
skipping to change at page 39, line 29 skipping to change at page 39, line 48
# V --V # # V --V #
# +-----------+ +-----------+ # # +-----------+ +-----------+ #
# | | | | # # | | | | #
#######| | | | # #######| | | | #
| Server | | Server |### | Server | | Server |###
| | | | | | | |
| | | | | | | |
+-----------+ +-----------+ +-----------+ +-----------+
===== Provisioning Protocol ===== Provisioning Protocol
##### Policy Protocol ##### Policy Protocol
----- SIP ----- SIP
Figure 13: Central PDP Figure 13: Central PDP
The centralized PDP has the benefits of central provisioning, and The centralized PDP has the benefits of central provisioning, and
consistent policy operation, and decouples policy decision making consistent policy operation, and decouples policy decision making
from presence and IM processing. This decoupling allows for multiple from presence and IM processing. This decoupling allows for multiple
presence and IM servers, but still allows for a single policy presence and IM servers, but still allows for a single policy
function overall. The individual presence and IM servers don't need function overall. The individual presence and IM servers don't need
to know about the policies themselves, or even know when they change. 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, Of course, if a server is caching the results of a policy decision,
change notifications are required from the PDP to the server, change notifications are required from the PDP to the server,
informing it of the change (alternatively, traditional TTL-based informing it of the change (alternatively, traditional TTL-based
expirations can be used if delay in updates are acceptable). expirations can be used if delay in updates are acceptable).
It is also possible to move the decisionmaking process into each It is also possible to move the decision making process into each
server. In that case, there is still a centralized policy portal and server. In that case, there is still a centralized policy portal and
centralized repository of the policy data. The interface between the centralized repository of the policy data. The interface between the
servers and the repository then becomes some kind of standardized servers and the repository then becomes some kind of standardized
database interface. database interface.
For the centralized and distributed provisioning approaches, and the For the centralized and distributed provisioning approaches, and the
centralized decision approach, the hierarchical model suffers overall centralized decision approach, the hierarchical model suffers overall
from the fact that the root of the policy processing may not be tuned 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 to the specific policy needs of the device that has subscribed. For
example, in the use case of Figure 8, presence server 1 may be example, in the use case of Figure 8, presence server 1 may be
skipping to change at page 41, line 30 skipping to change at page 41, line 37
either from Alice or from Bob. Indeed, the IM window on Bob's either from Alice or from Bob. Indeed, the IM window on Bob's
unanswered device may even disappear to emphasize this fact. unanswered device may even disappear to emphasize this fact.
This mode of operation, which we'll call uni-device IM, is only This mode of operation, which we'll call uni-device IM, is only
feasible with session mode IM, and its realization using traditional feasible with session mode IM, and its realization using traditional
SIP signaling is described in [RFC4975]. SIP signaling is described in [RFC4975].
The second mode of operation, called multi-device IM, is more of a The second mode of operation, called multi-device IM, is more of a
conferencing experience. The initial IM from Alice is delivered to conferencing experience. The initial IM from Alice is delivered to
both Bob's devices. When Bob answers on one, that response is shown 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 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 have set up an IM conference where each of Bob's devices is an
independent participant in the conference. This model is feasible independent participant in the conference. This model is feasible
with both session and pager mode IM; however conferencing works much with both session and pager mode IM; however conferencing works much
better overall with session mode. better overall with session mode.
A related challenge is conversation history. In the uni-device IM A related challenge is conversation history. In the uni-device IM
mode, this past history for a user's conversation may be distributed mode, this past history for a user's conversation may be distributed
amongst the different servers, depending on which clients and servers amongst the different servers, depending on which clients and servers
were involved in the conversation. As with the exclusive model, IM were involved in the conversation. As with the exclusive model, IM
search and retrieval services may need to access all of the servers search and retrieval services may need to access all of the servers
skipping to change at page 44, line 5 skipping to change at page 44, line 36
proceeds without that back-end input. proceeds without that back-end input.
The algorithm for IM routing works almost identically. The algorithm for IM routing works almost identically.
For example, consider Bob subscribing to Alice. Bob's client is For example, consider Bob subscribing to Alice. Bob's client is
supported by server 1. Server 1 has not seen this subscription 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 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), 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 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 has already seen the subscription, so it rejects it. Now server 2
basically knows its the child, and so it generates documents with basically knows it is the child, and so it generates documents with
just its own data. just its own data.
As in the hierarchical case, it is possible to intermix partitioned As in the hierarchical case, it is possible to intermix partitioned
and peer models for different users. In the partitioned case, the and peer models for different users. In the partitioned case, the
routing for hierarchical devolves into the forking routing described routing for hierarchical devolves into the forking routing described
in Section 6.2.5. However, intermixing peer and exclusive bridging in Section 6.2.5. However, intermixing peer and exclusive bridging
for different users is challenging. [[OPEN ISSUE: need to think for different users is challenging and is out of scope.
about this more.]]
8.2.2. Policy 8.2.2. Policy
The policy considerations for the peer model are very similar to The policy considerations for the peer model are very similar to
those of the hierarchical model. However, the root-only policy those of the hierarchical model. However, the root-only policy
approach is non-sensical in the peer model, and cannot be utilized. approach is non-sensical in the peer model, and cannot be utilized.
The distributed and centralized provisioning approaches apply, and The distributed and centralized provisioning approaches apply, and
the rules described above for generating correct results provide the rules described above for generating correct results provide
correct results in the peer model as well. correct results in the peer model as well.
skipping to change at page 45, line 26 skipping to change at page 46, line 7
9. More about Policy 9. More about Policy
There are several models that are described in this document that may There are several models that are described in this document that may
create some ambiguity regarding what the subscribing user will see create some ambiguity regarding what the subscribing user will see
when the policy is not managed in a centralized way (Section 8.1.2.3, when the policy is not managed in a centralized way (Section 8.1.2.3,
Section 8.1.2.4). Section 8.1.2.4).
o Exclusive model - In this case one server may have a certain o Exclusive model - In this case one server may have a certain
policy and the other server may have a different policy. Bob policy and the other server may have a different policy. Bob
subscribing one day to server A will not be able to see Alice's subscribing one day to server 1 will not be able to see Alice's
presence while he will be able to see her presence when he presence while he will be able to see her presence when he
subscribes to server B. subscribes to server 2.
o Hierarchical unioned model - Since only the root will provide the o Hierarchical unioned model - Since only the root will provide the
presence information all the users will see the same presence presence information all the users will see the same presence
information. However, if there are some contradicting rules in information. However, if there are some contradicting rules in
the servers, what the subscriber will see will in most cases be the servers, what the subscriber will see will in most cases be
the strictest and most minimal view and will be dependent on the the strictest and most minimal view and will be dependent on the
hierarchy of the servers in the hierarchical model. hierarchy of the servers in the hierarchical model.
o Peer unioned model - In this case one peer server may have a o Peer unioned model - In this case one peer server may have a
certain policy and the other server may have a different policy. certain policy and the other server may have a different policy.
Bob subscribing one day to peer server A will not be able to see Bob subscribing one day to peer server 1 will not be able to see
Alice's presence while he will be able to see her presence when he Alice's presence while he will be able to see her presence when he
subscribes to peer server B. subscribes to peer server 2.
There are several reasons why distributed policy model may needed: There are several reasons why distributed policy model may needed:
o Adapting policy to the presence server type - The particular o Adapting policy to the presence server type - The particular
presence server may be adapted to specific type of presence presence server may be adapted to specific type of presence
information and devices. It will be hard or not feasible to information and devices. It will be hard or not feasible to
provide a centralized policy for all the types of presence provide a centralized policy for all the types of presence
servers/devices servers/devices
o A presence server that is part of the intradomain bridging may not o A presence server that is part of the intradomain bridging may not
skipping to change at page 46, line 18 skipping to change at page 46, line 45
It is probable that although confusing for users, distributed It is probable that although confusing for users, distributed
provisioning will be used at least in the initial deployments of the provisioning will be used at least in the initial deployments of the
intradomain bridging until standards for central policy provisioning intradomain bridging until standards for central policy provisioning
will be developed and implemented by various presence servers. will be developed and implemented by various presence servers.
10. Acknowledgements 10. Acknowledgements
The authors would like to thank Paul Fullarton, David Williams, The authors would like to thank Paul Fullarton, David Williams,
Sanjay Sinha, and Paul Kyzivat for their comments. Thanks to Adam Sanjay Sinha, and Paul Kyzivat for their comments. Thanks to Adam
Roach and Ben Campbell for their dedicated review. Roach, Ben Campbell Michael Froman, Alan Johanston and Christer
Holmberg for their dedicated review.
11. Security Considerations 11. Security Considerations
The principle issue in intra-domain bridging is that of privacy. It While the normal presence and IM protocol (as SIP) mechanisms for
is important that the system meets user expectations, and even in securing presecne and IM should be used, The principle issue in
cases of user provisioning errors or inconsistencies, it provides intra-domain bridging is that of privacy. It is important that the
appropriate levels of privacy. This is an issue in the unioned system meets user expectations, and even in cases of user
models, where user privacy policies can exist on multiple servers at provisioning errors or inconsistencies, it provides appropriate
the same time. The guidelines described here for authorization levels of privacy. This is an issue in the unioned models, where
policies help ensure that privacy properties are maintained. 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.
12. IANA Considerations 12. IANA Considerations
There are no IANA considerations associated with this specification. There are no IANA considerations associated with this specification.
13. Informative References 13. Informative References
[RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for [RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for
Presence and Instant Messaging", RFC 2778, February 2000. Presence and Instant Messaging", RFC 2778, February 2000.
[RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
W., and J. Peterson, "Presence Information Data Format A., Peterson, J., Sparks, R., Handley, M., and E.
(PIDF)", RFC 3863, August 2004. Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
July 2006. Event Notification", RFC 3265, June 2002.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325,
November 2002.
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.,
and D. Gurle, "Session Initiation Protocol (SIP) Extension
for Instant Messaging", RFC 3428, December 2002.
[RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Registrations", RFC 3680, March 2004.
[RFC3856] Rosenberg, J., "A Presence Event Package for the Session [RFC3856] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004. Initiation Protocol (SIP)", RFC 3856, August 2004.
[RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session [RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr,
Initiation Protocol (SIP) Event Notification Extension for W., and J. Peterson, "Presence Information Data Format
Resource Lists", RFC 4662, August 2006. (PIDF)", RFC 3863, August 2004.
[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension
for Event State Publication", RFC 3903, October 2004.
[RFC3944] Johnson, T., Okubo, S., and S. Campos, "H.350 Directory [RFC3944] Johnson, T., Okubo, S., and S. Campos, "H.350 Directory
Services", RFC 3944, December 2004. Services", RFC 3944, December 2004.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325,
November 2002.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006. Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event [RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479,
Package for Registrations", RFC 3680, March 2004. July 2006.
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., [RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session
and D. Gurle, "Session Initiation Protocol (SIP) Extension Initiation Protocol (SIP) Event Notification Extension for
for Instant Messaging", RFC 3428, December 2002. Resource Lists", RFC 4662, August 2006.
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message
Session Relay Protocol (MSRP)", RFC 4975, September 2007. Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC5344] Houri, A., Aoki, E., and S. Parameswar, "Presence and [RFC5344] Houri, A., Aoki, E., and S. Parameswar, "Presence and
Instant Messaging Peering Use Cases", RFC 5344, Instant Messaging Peering Use Cases", RFC 5344,
October 2008. October 2008.
[I-D.ietf-simple-view-sharing] [I-D.ietf-simple-view-sharing]
Rosenberg, J., Donovan, S., and K. McMurry, "Optimizing Rosenberg, J., Donovan, S., and K. McMurry, "Optimizing
Federated Presence with View Sharing", Federated Presence with View Sharing",
draft-ietf-simple-view-sharing-02 (work in progress), draft-ietf-simple-view-sharing-02 (work in progress),
November 2008. November 2008.
Authors' Addresses Authors' Addresses
Jonathan Rosenberg Jonathan Rosenberg
Cisco jdrosen.net
Iselin, NJ Monmouth, NJ
US US
Email: jdrosen@cisco.com Email: jdrosen@jdrosen.net
URI: http://www.jdrosen.net URI: http://www.jdrosen.net
Avshalom Houri Avshalom Houri
IBM IBM
Science Park, Rehovot Science Park, Rehovot
Israel Israel
Email: avshalom@il.ibm.com Email: avshalom@il.ibm.com
Colm Smyth Colm Smyth
Avaya Avaya
Dublin 18, Sandyford Business Park Dublin 18, Sandyford Business Park
Ireland Ireland
Email: smythc@avaya.com Email: smythc@avaya.com
Francois Audet Francois Audet
Nortel Skype
4655 Great America Parkway
Santa Clara, CA 95054
USA
Email: audet@nortel.com Email: francois.audet@skype.net
 End of changes. 54 change blocks. 
132 lines changed or deleted 134 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/