A Batch Notification Extension for the Session Initiation Protocol (SIP)
draft-johnston-sipping-batch-notify-00

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

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.”

The list of current Internet-Drafts can be accessed at 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 September 3, 2009.

Copyright Notice

Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Abstract

This memo specifies the requirements and mechanism for a SIP events extension where bulk SIP event information can be shared between two peers both with the ability and authority to act as notifiers for this information. An example application use case is the transition of event state information during a backup/recovery sequence between event state servers. This document is targeted at addressing server overflow conditions that include the possibilities of the size of individual notification messages getting excessive and the processing of state information by both the subscriber and notifier also becoming excessive.

Table of Contents

1.  Overview
2.  Terminology
3.  Requirements
4.  Use Cases
5.  Possible Mechanism
6.  Appendix - Syntax for batch parameter
7.  IANA Considerations
    7.1.  Registration of Header Field Parameter
8.  Security Considerations
9.  Acknowledgements
10.  Informative References
§  Authors' Addresses

1.  Overview

The SIP [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) event framework [RFC3265] (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.) was developed as a way for SIP UAs to request and exchange various information. It has proven to be very useful, with many event packages being defined. Some of these event packages result in notifiers which have large databases of information which is provided to subscribers. For example, the conferencing event package defines a mechanism for a focus to share state information about a conference. The registration event package allows a registrar to share information about current registrations. And presence allows a presence server to store and share presence information.

The SIP event framework includes the ability to combine event state from multiple contacts associated with the same AOR and provide this information in a single subscription, through an event state compositor (ESC). Besides this mechanism, one subscription generally only provides event state information about one AOR. The resource list and resource list server (RLS) extensions [RFC4662] (Roach, A., Campbell, B., and J. Rosenberg, “A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists,” August 2006.) were developed to allow a single subscription to a RLS to be used to convey event state about all the AORs in a resource list to be delivered over a single subscription. The mechanism assumes that resource list of URIs is stored on a RLS and represented by a single resource list URI. When a UA subscribes to the resource list URI, the RLS initiates "back-end" subscriptions, and subscribes to the individual state of each URI, then combines this information into the single subscription. The Resource List Meta Information (RLMI) data format [RFC4662] (Roach, A., Campbell, B., and J. Rosenberg, “A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists,” August 2006.) was defined as a way to map the event state from these backend subscriptions to the list subscription.

The SIP event filter extension [RFC4660] (Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-Requena, “Functional Description of Event Notification Filtering,” September 2006.) provides a mechanism where a UA can control the content of event notifications. For example, a filter can be created to control what exact types of events will generate notifications or generate notifications only for certain resources.

This draft discusses the requirements and mechanism for another SIP events extension where bulk SIP event information can be shared between two peers both with the ability and authority to act as notifiers for this information. We call requests for this transfer a "batch" subscription, and the notifications generated during this transfer as "batch" notifications where this full state information is transferred for a particular event package in a managed way. An example application use case is the transition of event state information during a backup/recovery sequence between event state servers. It is desirable that this transfer occurs in a timely way without overloading either server.

The way in which these batch notifications are generated and delivered needs to be managed carefully, otherwise:

1. The rate of notifications could become excessive.
2. The size of individual notification messages could become excessive.
3. The processing of state information by both the subscriber and notifier could become excessive.

The first could be solved by [I‑D.niemi‑sipping‑event‑throttle] (Niemi, A., Kiss, K., and S. Loreto, “Session Initiation Protocol (SIP) Event Notification Extension for Notification Throttling,” February 2009.) which provides a throttling mechanism where the subscriber can choose the maximum and average rate of notifications. The second and third represent the requirements that will be discussed in this draft. Note that the SIP event filter extension [RFC4660] (Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-Requena, “Functional Description of Event Notification Filtering,” September 2006.) does not help in this case as it is assumed that all events by all users are of interest for the batch notification.

2.  Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

3.  Requirements

This section discusses the requirements for the batch notification mechanism.

REQ-1: The mechanism will allow a subscriber to set the maximum number of bodies in a batch notification.

REQ-2: The mechanism must work together with other throttling mechanisms and filtering mechanisms.

REQ-3: The mechanism will not be event package specific.

REQ-4: The mechanism will permit the notifier to indicate to the subscriber that the full event state has been transferred.

REQ-5: The mechanism will minimize the processing of the event state data by both the batch subscriber and batch notifier.

4.  Use Cases

This section discusses a number of use cases for the batch notification mechanism.

For example, consider a SIP conferencing service. A key part is the conference notification service [RFC4575] (Rosenberg, J., Schulzrinne, H., and O. Levin, “A Session Initiation Protocol (SIP) Event Package for Conference State,” August 2006.) which provides notifications on conference participants and states. A single conference service may have multiple concurrent SIP conferences, each identified by a conference URI. However, all or a set of these URIs may resolve to a single server which has access to the state of multiple conferences and provides the notification service. If this conference service is being taken out of service and replaced by another instance of the conferencing service, the first step is for the new instance to learn the state of all active conferences. Once this information is known, the process of using SIP call control techniques to move the focus to the new server can begin. This could be done by individual subscriptions to each of the active conferences on the server. However, for a large conferencing system, this is inefficient and slow, and would use up resources on both systems. A batch notification mechanism would allow the efficient transfer of conference information.

Another example is a registrar which implements the registration information event package [RFC3680] (Rosenberg, J., “A Session Initiation Protocol (SIP) Event Package for Registrations,” March 2004.). A new location service or proxy implementing a location service might need to obtain the current registration data for a domain. While it is possible to do with outside of SIP, there are valid reasons why this might sometimes be done inside SIP such as:

• Reuse of authentication, routing, and NAT and firewall traversal
• Mobility and distribution
• Simplicity

A related example is that of a failure case. While a server may retain previously provisioned and/or computed information within its internal data store, a planned or unplanned outage creates the need to re-synchronize components within a network infrastructure. The batch mechanism provides the capability for a server to request the list of current registrations from a registrar or other component within the network architecture.

Again, the three issues associated with the bulk notification scheme would be critical to the performance of such a system.

Presence [RFC3856] (Rosenberg, J., “A Presence Event Package for the Session Initiation Protocol (SIP),” August 2004.) is another example where this mechanism could be utilized. Aggregated presence servers within a domain could use an approach such as this to share presence information between them and to synchronize and transfer event state compositor information.

All these use cases would use a call flow similar to Figure 1 below. The subscription is created by the SUBSCRIBE in F1, which utilizes the mechanism to set the maximum batch size for notifications, meeting REQ-1. The notifier has a large volume of state information to send, but it is broken up into three batches (F3, F5, and F7) based on the settings in the SUBSCRIBE. Future notifications of state occur later in the subscription and may or may not be batch NOTIFYs.

           Subscriber                 Notifier
                |                        |
                |  SUBSCRIBE (batch) F1  |
                |----------------------->|
                |     202 Accepted F2    |
                |<-----------------------|
                |    NOTIFY (batch) F3   |
                |<-----------------------|
                |        200 OK F4       |
                |----------------------->|
                |    NOTIFY (batch) F5   |
                |<-----------------------|
                |        200 OK F6       |
                |----------------------->|
                |    NOTIFY (batch) F7   |
                |<-----------------------|
                |        200 OK F8       |
                |----------------------->|
                |                        |
                |                        |
                |  NOTIFY Subscription-State:terminated F9
                |<-----------------------|
                |       200 OK F10       |
                |----------------------->|
                |                        |

Figure 1. Batch Notification Call Flow.

If the notifier wants to indicate to the subscriber that the full event state has been transferred, the notifier can terminate the subscription with a NOTIFY with Subscription-State: terminated as shown in F9. This meets REQ-4.

OPEN ISSUE: What reason parameter should be used in this case? Perhaps a new one needs to be defined.

5.  Possible Mechanism

This document proposes a possible mechanism for the batch notification. The proposed mechanism is similar to that used in [I‑D.niemi‑sipping‑event‑throttle] (Niemi, A., Kiss, K., and S. Loreto, “Session Initiation Protocol (SIP) Event Notification Extension for Notification Throttling,” February 2009.) where a new Event header field parameter, "batch" is defined and used as in Figure 1. Other filtering and throttling mechanisms could still be used for this subscription, as other header field parameters and bodies could be included in the SUBSCRIBE, meeting REQ-2.

This mechanism could be used with resource lists and RLMI body types. In this case, the batch count would refer to the number of resource bodies, not RLMI bodies. However, to better meet REQ-5, this mechanism could be used with an alternative body type. For applications that meet the following requirements, an optimization could be used. They are:

1. There is no back-end subscription as is the case with a RLS.
2. Each individual body is self-contained and does not need any meta information for processing.
3. Only full state event information is included.

For example, any of the three use cases mentioned above meet these requirements. In all of these cases, there is no back-end subscription. As such, there is no meta information, such as that included in RLMI bodies. For these cases, the RLMI body can be omitted and each event state body included as multipart/mixed. For example,

   NOTIFY sip:app.example.com SIP/2.0
   Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaij
   From: sip:joe@example.com;tag=xyzygg
   To: sip:app.example.com;tag=123aa9
   Call-ID: 9987@app.example.com
   CSeq: 1289 NOTIFY
   Contact: sip:server19.example.com
   Event: reg
   Max-Forwards: 70
   Content-Type: multipart/mixed;boundary="boundary1"
   Content-Length: ...

      --boundary1
   Content-Type: application/reginfo+xml

   <?xml version="1.0"?>
   <reginfo xmlns="urn:ietf:params:xml:ns:reginfo"
             version="1" state="partial">
     <registration aor="sip:joe@example.com" id="a7" state="active">
       <contact id="1976" state="active" event="registered"
             duration-registered="3210">
          <uri>sip:joe@pc34.example.com</uri>
       </contact>
     </registration>
   </reginfo>

   --boundary1
   Content-Type: application/reginfo+xml

   <?xml version="1.0"?>
   <reginfo xmlns="urn:ietf:params:xml:ns:reginfo"
             version="1" state="partial">
     <registration aor="sip:fred@example.com" id="54a7" state="active">
       <contact id="7446" state="active" event="registered"
             duration-registered="190">
          <uri>sip:fred@pc.example.com</uri>
       </contact>
     </registration>
   </reginfo>

   --boundary1
   Content-Type: application/reginfo+xml

   <?xml version="1.0"?>
   <reginfo xmlns="urn:ietf:params:xml:ns:reginfo"
             version="1" state="partial">
     <registration aor="sip:bob@example.com" id="4a6437" state="active">
       <contact id="176" state="active" event="registered"
             duration-registered="282">
          <uri>sip:bob@lab.example.com</uri>
       </contact>
     </registration>
   </reginfo>
   --boundary1--

The considerations [I‑D.ietf‑sip‑body‑handling] (Camarillo, G., “Message Body Handling in the Session Initiation Protocol (SIP),” March 2009.) apply to this usage.

6.  Appendix - Syntax for batch parameter

Editor's Note: Eventually this text will move to a SIP Working Group document to define the new Event header field parameters.

This parameter is defined as:

event-param =/ batch-param

batch-param = "batch" EQUAL 1*DIGIT

7.  IANA Considerations

7.1.  Registration of Header Field Parameter

This document defines a new parameter, "batch", for the Event header field defined in RFC 3265.

The following rows shall be added to the "Header Field Parameters and Parameter Values" section of the SIP parameter registry:

   +------------------+----------------+-------------------+-----------+
   | Header Field     | Parameter Name | Predefined Values | Reference |
   +------------------+----------------+-------------------+-----------+
   | Event            | batch          | No                | [RFCXXXX] |
   +------------------+----------------+-------------------+-----------+

Editor's Note: [RFCXXXX] should be replaced with the designation of the eventual SIP Working Group document.

8.  Security Considerations

The security considerations for the SIP Events framework [RFC3265] (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.) apply to this extension. As such, both the subscriber and notifier should use normal SIP methods for authentication and message integrity for subscriptions generated for this extension.

9.  Acknowledgements

Thanks to Brian Schwarz and Dan Romascanu for their contributions.

10. Informative References

Authors' Addresses