Internet DRAFT - draft-ilan-dispatch-subscription-diff-list
draft-ilan-dispatch-subscription-diff-list
Network Working Group N.Ilankumaran
Internet-Draft R.Gopalakrishnan
Intended status: Standards Track
Expires: March 16, 2014 Infosys
Sept 23, 2013
Subscription to Differntial Resource lists in SIP Presence
Event Notification model
draft-ilan-dispatch-subscription-diff-list-01
Abstract
SIP SIMPLE work group has defined several improvements to SIP
Presence event notification model, such as subscription to a list of
resources in the body of single SUBSCRIBE request, and Resource List
Server (RLS) to create subscription to resource list identified by a
URI. This document presents an extension to incrementally update
resource list contained in the body of subscription requests for SIP
presence. The document defines semantics for creating incremental
changes to resource list that are carried in requests for
subscription refreshes. This enables reduction in the number of
messages exchanged for subscriptions in large network of inter-
connected SIP based presence servers.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 16, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
Ilan, et al. Expires March 16, 2014 [Page 1]
Internet-Draft Subscription to Diff Resource list September 2013
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
3. Overview of Operation . . . . . . . . . . . . . . . . . . 3
3.1. Overview . . . . . . . . . . . . . . . . . . . 3
3.2. Differential resource-list document format . . . . . . . 4
4. Tracking changes to resource-list document. . . . . . . . . . 6
5. RLS and PS processing . . . . . . . . . . . . . . . . . . . 6
5.1. RLS operations . . . . . . . . . . . . . . . . . . . . . 6
5.1.1 Initial Subscribe Request from RLS . . . . . . . . . 6
5.1.2 Updating Subscriptions . . . . . . . . . 7
5.1.3 RLS processing of responses to Subscribe Request. . . . . 8
5.1.4 RLS processing of responses to Re-subscribe Requests . . 8
5.2. PS processing . . . . . . . . . . . . . . . . . . . . . 9
5.2.1 PS processing of initial requests . . . . . . . . . 9
5.2.2 PS processing of subsequent requests . . . . . . . . . 9
5.3 Failure processing at RLS and PS . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7.1. diff-list-update Option-Tag . . . . . . . . . . . . . . . 10
7.2. Update-If-Match Header Field . . . . . . . . . . . . . . 11
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
[RFC 4662] introduced Resource List Server(RLS), a logical node, to
accept single subscription request for list of resources, to
maintain virtual subscriptions and to send notifications to
convey the compounded state information of resource list. This model
reduced the traffic of multiple subscriptions and notifications for
individual resources in [RFC 3265]. However RLS left the creation
and maintenance of resource lists outside its scope.
While the RLS and virtual subscription has proved successful,
it still suffers from the requirement to have back-end subscriptions/
notifications for inter-domain presentities in list. Further in
practical applications where a large resource-list that requires
update, it is beneficial for RLS to employ differential list in
subscriptions to inter-domain Presence Server.
Ilan, et al. Expires March 16, 2014 [Page 2]
Internet-Draft Subscription to Diff Resource list September 2013
[RFC 5367] specified a way to create a resource list during subscri-
ption, by including it in the body of a single subscribe request.
This document expands on that approach to include differntial
resource-list in SIP SUBSCRIBE requests for changing subscriptions
created in the initial SUBSCRIBE request dialog.
2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
3. Overview of Operation
3.1. Overview
The following figure depicts a typical SIP network. In this network,
the UACs use RLS and virtual subscription as defined in [RFC 4662]
as well as the XCAP protocol to store and update the resource
lists.
---------
| XCAP |
|Server |
---------
^
|
|
v
List ------------- Subs/Notify -----------
Subs/ | | <-----------------> | Intra |
[]_ Notify | | <-----------------> | Domain |
|U | <-----> | | <-----------------> | PS |
|A | | | -----------
|C | | |
---- | |
| R | Subs/Notify -----------
[]_ | L | <-----------------> | Inter |
|U | <-----> | S | <-----------------> | Domain 1|
|A | | | <-----------------> | PS |
|C | | | -----------
---- | |
| |
[]_ | | Subs/Notify -----------
|U | <-----> | | <-----------------> | Inter |
|A | | | <-----------------> | Domain 2|
|C | | | <-----------------> | PS |
---- | | -----------
-------------
Figure 1: SIP Presence Network
Ilan, et al. Expires March 16, 2014 [Page 3]
Internet-Draft Subscription to Diff Resource list September 2013
In this scenario, the RLS server has to create a list of subscription
targets and maintain individual subscriptions for each of the targets
especially for inter-domain targets. [draft-ietf-simple-interdomain-
scaling-analysis-08] analyzed ways of optimizing the inter domain
subscription-notification traffic and made several optimization tech-
niques that can be employed.
Later [RFC 5367] specified a way to create a resource
list during subscription, by including it in the body of a single
SUBSCRIBE request. This document proposes to leverage the mechanism
defined in [RFC 5367] to extend RLS further such that the
initial subscription can be established with a partial list and
update the subscription using subsequent SUBSCRIBE requests. The
subsequent SUBSCRIBE requests shall include in the body an XML
document containing "differential-resource-list". The proposed method
defines ways to inform the type of change, actual entities to be
changed and a mechanism to maintain the version of the subscription
list using SIP Etag. All subsequent modifications will be done
within the single dialog created at the start with the initial
SUBSCRIBE message. The life-time of virtual-subscription at PS is
derived based on the expiry-time of initial/subsequent refresh
SUBSCRIBEs.
Given below is a typical message flow for the method proposed.
UAC(s) RLS XCAP PS UAC(s)
Server
| | | | |
| -- M1: SUBSCRIBE --> | | | |
| | | | |
| <--- M2: 200 OK ----- | | | |
| | --GET-> | | |
| <--- M3: NOTIFY ----- | | | |
| | <-200-- | | |
| ---- M4: 200 OK ----> | | | |
| | | |
| | | |
| | -- M5: SUBSCRIBE ----> | |
| | (full-list) | |
| | <--- M6: 200 OK ------- | |
| | (SIP-ETag:1) | |
| | <---- M7: NOTIFY ------ | |
| | | |
| | ----- M8: 200 OK -----> | |
Ilan, et al. Expires March 16, 2014 [Page 4]
Internet-Draft Subscription to Diff Resource list September 2013
| | | |
| ---- HTTP PUT -------|-------> | | |
| | | | |
| <--- HTTP 200 OK -----|-------- | | |
| |<-Ext -- | | |
| | Trig | |
| | | |
| | -- M9: SUBSCRIBE ----> | |
| | (Sip-If-Match:1) | |
| | (diff-list) | |
| | <---M10: 200 OK ------- | |
| | (SIP-ETag:2) | |
| | <---- M11: NOTIFY ----- | |
| | | |
| | ----- M12: 200 OK ----> | |
| | |<-M13:PUB---|
| | |-M14:200OK->|
| | <---- M15: NOTIFY ----- | |
| | | |
| | ----- M16: 200 OK ----> | |
Figure 2: Example Message Flow
The URI for the intitial SUBSCRIBE is outside the scope of the
document and left to the implementors. Potential ways could be to
provision list URIs in both PS and RLS, or for PS implements a way
to correlate a virtual subscription dialog, resource-list
and the Etag generated.
Benefits of differential subscriptions are:
o Reduction of SIP Subscribe/Notify traffic between
RLS and PS through list subscription instead of individual
subscriptions
o Subscription refresh is achieved along with differential-
list SUBSCRIBE
o Subscription optimization, through grouping of resources
per domain
3.2. Differential resource-list document format
[RFC 5367] uses a flat "resource-list" document format provided by
XCAP resource list schema defined in [RFC 4826]. The same document
format is proposed to be used here for initial SUBSCRIBE request,
but subsequent SUBSCRIBE requests will use "resource-lists-diff"
document defined in [RFC 5362]. The IANA XML schema registry entry
URI is urn:ietf:params:xml:schema:resource-lists-diff.
A sample XML document is below:
Ilan, et al. Expires March 16, 2014 [Page 5]
Internet-Draft Subscription to Diff Resource list September 2013
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists-diff xmlns="urn:ietf:params:xml:ns:
resource-lists-diff">
<add sel="*/list[@name='sip:externaldomainlist@rls.example.com'/
entry[@uri='sip:bill@externaldomain.com']"
pos="before">
<entry uri="sip:foo@externaldomain.com" />
</add>
</resource-lists-diff>
above example adds a resource "sip:foo@externaldomain.com" into an
existing resource-list before "sip:bill@externaldomain.com".
4. Tracking changes to resource-list document
RLS and PS need to have a tracking mechanism to keep the resource-
list in sync, further event-state composition at PS depends on the
latest resource-list to arrive at the optimal content for
event state information xml in NOTIFY.
This memo proposes to use entity-tag mechanism in SIP requests
and responses, to synchronize the resource-list document between RLS
and PS. Inter-domain PS MUST return "SIP-ETag" header in success
response to back-end subscriptions and updates from RLS. Whereas
RLS while modifying subscriptions, MUST include in a "Update-If-
Match" header the entity-tag of such resource-list document. PS MUST
maintain the scope and uniqueness of entity-tag for the lifetime of
the dialog created by back-end subscription.
5. RLS and PS processing
5.1. RLS operations
5.1.1 Initial Subscribe Request from RLS
RLS that wants to establish a new subscription at PS for a group
of resources MUST use the mechanism in [RFC 5367] prior to adopting
the enhancements proposed in this document. Additionally RLS MUST
must include 'diff-list-update' SIP options tag (as defined in
section 7. IANA considerations). A sample SUBSCRIBE message is
given below
SUBSCRIBE sip:ps.externaldomain.com SIP/2.0
Via: SIP/2.0/TCP rls.example.com;branch=z9hG4bKwYb6QREiCL
Max-Forwards: 70
To: PS <sip:ps.externaldomain.com>
Ilan, et al. Expires March 16, 2014 [Page 6]
Internet-Draft Subscription to Diff Resource list September 2013
From: <sip:rls@example.com>;tag=ie4hbb8t
Call-ID: cdB34qLToC@rls.example.com
CSeq: 1 SUBSCRIBE
Contact: <sip:rls.example.com>
Event: presence
Expires: 7200
Require: recipient-list-subscribe,diff-list-update
Supported: eventlist
Accept: application/cpim-pidf+xml
Accept: application/rlmi+xml
Accept: multipart/related
Accept: multipart/signed
Accept: multipart/encrypted
Content-Type: application/resource-lists+xml
Content-Disposition: recipient-list
Content-Length: 337
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<list name="sip:externaldomainlist@rls.example.com">
<entry uri="sip:bill@externaldomain.com" />
<entry uri="sip:joe@externaldomain.com" />
<entry uri="sip:ted@externaldomain.com" />
</list>
</resource-lists>
5.1.2 Updating Subscriptions
After successful establishment of a new subscription as per
section 5.1.1 RLS MAY modify the subscriptions by a subsequent
SUBSCRIBE request with "resource-lists-diff+xml" in the body.
Also RLS MUST include "Require:" header with "diff-list-update"
option-tag as introduced by this document.
Further when modifying the resource-lists through a subsequent
SUBSCRIBE request in the same dialog, RLS MUST include in the body
"resource-lists-diff+xml", formatted as per the schema defined in
urn:ietf:params:xml:schema:resource-lists-diff.
Sample subsequent SUBSCRIBE request:
SUBSCRIBE sip:ps.externaldomain.com SIP/2.0
Via: SIP/2.0/TCP rls.example.com;branch=z9hG4bKwYb6QREiCL
....
Max-Forwards: 70
To: PS <sip:ps.externaldomain.com>;tag=infb1111
From: <sip:rls@rls.example.com>;tag=ie4hbb8t
Call-ID: cdB34qLToC@rls.example.com
CSeq: 2 SUBSCRIBE
Contact: <sip:rls.example.com>
Event: presence
Expires: 7200
Ilan, et al. Expires March 16, 2014 [Page 7]
Internet-Draft Subscription to Diff Resource list September 2013
Require: diff-list-update
Supported: eventlist
Update-If-Match: dd200inf
Accept: application/cpim-pidf+xml
Accept: application/rlmi+xml
Accept: multipart/related
Accept: multipart/signed
Accept: multipart/encrypted
Content-Type: application/resource-lists-diff+xml
Content-Disposition: recipient-list
Content-Length:
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists-diff xmlns="urn:ietf:params:xml:ns:
resource-lists-diff">
<add sel="*/list[@name='sip:externaldomainlist@rls.example.com'/
entry[@uri='sip:bill@externaldomain.com']"
pos="before">
<entry uri="sip:bar@externaldomain.com" />
</add>
</resource-lists-diff>
While this document defines a model for subscriptions with
differential resource lists by RLS to inter-domain PS, the actual
creation of the list and any other optimization of grouping
common entries in different resource-lists such as
based on unique domain names are left as implementation specific.
5.1.3 RLS processing of responses to Subscribe Request
On receiving 2xx response to initial subscribe/update requests RLS
would store the entity-tag locally. When RLS needs to modify the
resource-list,sends an SUBSCRIBE request with locally stored entity-
tag in the "Update-If-Match" header along with the XML body of
changes to the resource-list.
When a 420 response is received for initial subscribe request
RLS MAY choose to fallback to full-list subscription model of
[RFC 5367], or subscription to individual resources [RFC 6665],based
on "Unsupported" header in the response.
5.1.4 RLS processing of responses to SUBSCRIBE Requests
2xx response processing follows section 5.1.3.
When RLS receives 412 ((Conditional Request Failed) response, it
MUST terminate the subscription and MAY recreate a new subscription
based on its policy settings.
Ilan, et al. Expires March 16, 2014 [Page 8]
Internet-Draft Subscription to Diff Resource list September 2013
5.2. PS processing
Presence Servers that are capable of receiving SUBSCRIBE request
with differential-resource-list in the body SHOULD indicate the same
with "diff-list-update" option-tag in "Supported:" header
in response to OPTIONS requests.
PS servers supporting subscriptions containing differential
list, will indicate acceptance of MIME type application/resource-
lists-diff+xml by Accept: header in their responses. PS servers
not supporting such a MIME type, will return an error response,
without terminating the dialog created by the initial subscribe
with full resource-list. RLS receiving such error response will
fall-back to subscription through full resource-list.
5.2.1 PS processing initial Subscribe Request
On receiving the initial SUBSCRIBE request with a resource-list
PS MUST create unique entity-tag [RFC 3903] identifying the virtual-
subscription and return entity-tag in "SIP-ETag" header in success
response. Further processing of SUBSCRIBE request SHALL follow
[RFC 4662].
PS that chooses to accept differential resource list, MUST include
"Accept:" header supporting MIME type "application/resource-lists-
diff+xml".
PS that does not support differential resource-list, respond as per
normal SIP processing rules to send 4xx response.
5.2.2 PS processing of subsequent SUBSCRIBE Requests
PS servers capable of handling "resource-lists-diff+xml" document
MUST examine the "Update-If-Match" header in SUBSCRIBE request as
pre-condition for processing:
* If no "Update-If-Match" header is found it is rejected with
400 (Invalid Request) response
* Else entity-tag is extracted from "Update-If-Match" header, and it
is matched against locally stored entity-tags. If no match is
found, a 412 (Conditional Request Failed) response is returned.
If a match is found, PS applies the differential resource-list
into the virtual susbscription, and returns 200 OK response
with a new entity-tag in "SIP-ETag" header
Ilan, et al. Expires March 16, 2014 [Page 9]
Internet-Draft Subscription to Diff Resource list September 2013
* If the PS does not support to this specification, it MUST send a
420 (Bad Extension) but MUST maintain the subscription already
created to maintain backward compatibility of [RFC 5367]
5.3 Failure processing at RLS and PS
It is likely that either of RLS or PS nodes fail and restart with
out any knowledge of the subscriptions they were handling. This
document recommends the following approaches to handle these
situations
* If the number of peers to subscribe to are limited, a connection
oriented transport protocol such as TCP SHALL be used which can
help detect the transport failure and clean up the subscriptions.
Besides, it helps in sending large number of entities in one
message using TCP fragmentation
* The nodes MAY use non-volatile storage of subscription
information to be able to reconstruct them on restart
* In case of PS failure without any of the above methods, PS MUST
deny any incoming SUBSCRIBE for an old dialog possibly with an
update for the list with a (481 Transaction Does Not Exist)
error. Upon receiving this the RLS MUST terminate the
subscription and initiate a new one for the list
* In case of RLS failure without any of the above methods, RLS will
initiate a new subscription for the same list. PS MUST be able to
identify this and destroy the existing subscription for the list
and proceed with accepting the new subscription. For this, PS
SHALL use the list named defined in the document. PS SHALL
consider the subscriber identity as in From header and the list
name defined in the document. To make this feasible RLS MUST
create unique names for each list that it is subscribing to the
same PS. The mechanism to generate unique list names is left to
the implementor.
6. Security Considerations
"Framework and Security Considerations for SIP URI-List services"
[RFC 5363] applies to the resource-list service discussed in this
document. Implementors of RLS must adhere to the guidelines presented
in [RFC 5363].
7. IANA Considerations
This document defines a new SIP option tag "diff-list-update".
7.1. diff-list-update Option-Tag
Following is the proposed addition to the SIP Parameter Registry:
Ilan, et al. Expires March 16, 2014 [Page 10]
Internet-Draft Subscription to Diff Resource list September 2013
+--------------------------+----------------------------+-----------+
| Name | Description | Reference |
+--------------------------+----------------------------+-----------+
| diff-list-update | This option tag is used to | <ref> |
| | ensure that a server can | |
| | process differential | |
| | list document in the | |
| | SUBSCRIBE request body. | |
+-------------------------------------------------------+-----------+
7.2. Update-If-Match Header Field
This document registers a new SIP header field called Update-If-
Match. The usage of this header is defined in section 4. IANA header
field definition is as follows
+--------------------------+----------------------------+-----------+
| Header Name | Compact | Reference |
+--------------------------+----------------------------+-----------+
| Update-If-Match | | <ref> |
+-------------------------------------------------------+-----------+
8. Acknowledgments
The authors would like to thank Senthil Kumar and Krishnananda R
Shenoy, Infosys for their valuable inputs and suggestions.
9. References
9.1. Normative References
[RFC 4662] Roach, A.B., Campbell, B., and J. Rosenberg, "A Session
Initiation Protocol (SIP) Event Notification Extension
for Resource Lists", RFC 4662, August 2006.
[RFC 5367] G. Camarillo, "Subscriptions to Request-Contained
Resource Lists in SIP", RFC 5367, October 2008.
[RFC 5362] G. Camarillio, "SIP Pending Additions Event Package",
RFC 5362, October 2008.
[RFC 4826] J.Rosenberg, "Extensible Markup Language (XML) Formats
for representing Resource Lists", RFC 4826, May 2007.
[RFC 5363] G. Camarillio, "Framework and Security Considerations
for SIP URI-list services", RFC 5363, October 2008.
[RFC 3903] A. Niemi "Session Initiation Protocol (SIP) Extension
for Event State Publication", RFC 3903, October 2004.
Ilan, et al. Expires March 16, 2014 [Page 11]
Internet-Draft Subscription to Diff Resource list September 2013
[draft-ietf-simple-interdomain-scaling-analysis-08] A. Houri,
Presence Interdomain Scaling Analysis for SIP/SIMPLE,
draft-ietf-simple-interdomain-scaling-analysis-08,
Aug 2009.
9.2. Informative References
[RFC 5874] J.Rosenberg, "XML Document format for Indicating a
change in XCAP resources", RFC 5874, May 2010.
[RFC 5261] J.Urpalainen, "An XML patch Operations Framework
Utilizing XPath Selectors", RFC 5261, Sep 2008.
[RFC 5839] A. Niemi, "An Extension to SIP events for conditional
Event Notification", RFC 5839, May 2010.
Authors' Addresses
N Ilankumaran
Infosys
44, Electronic City
Bangalore, 560 100
India
Email: ilankumaran@infosys.com
R Gopalakrishnan
Infosys
44, Electronic City
Bangalore 560 100
India
Email: gopalakr@infosys.com
Ilan, et al. Expires March 16, 2014 [Page 12]
