p2psip Jun Wang Zhifeng Chen Internet Draft ZTE Corporation Intended status: Standards Track March 2, 2009 Expires: September 2009 P2PSIP Event Notification Extension draft-wang-p2psip-event-notification-extension-00.txt 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 2, 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 (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. Abstract Wang Expires September 2, 2009 [Page 1] Internet-Draft P2PSIP Event Notification Extension March 2009 The p2p technology is data centric, where the data objects are distributed in the p2p overlay according to the routing algorithm. Applications access the data objects via peer/client protocol or gateways, and some of them require data replicas to be synchronized in real time, such as a data object stored in overlay and its cache copy in client memory. This can be achieved by introducing an event notification extension to p2p protocol. This document describes the subscribe/notify mechanism for p2psip and define several new methods to implement such extension. Table of Contents 1. Introduction................................................4 2. Conventions used in this document............................5 3. Overview of the Subscriber/Notifier behavior.................6 3.1. Subscription model in p2psip............................6 3.1.1. Explicit subscription..............................6 3.1.2. Implicit subscription..............................7 3.2. Subscriber Behavior.....................................8 3.2.1. Subscription Duration..............................8 3.2.2. Subscription Event.................................8 3.2.3. Creating a Subscription............................9 3.2.4. Refreshing a Subscription..........................9 3.2.5. Canceling a Subscription...........................9 3.2.6. Processing notify messages.........................9 3.3. Notifier Behavior......................................10 3.3.1. Processing a subscribe request....................10 3.3.2. Processing Refreshing request.....................10 3.3.3. Generating a Notify request.......................10 3.3.4. Storage and replication...........................11 3.4. SubscribeGateway Behavior..............................11 4. Protocol details...........................................12 4.1. Subscribe method.......................................12 4.1.1. Request Definition................................12 4.1.2. Response Definition...............................14 4.2. Notify method.........................................15 4.2.1. Request Definition................................15 4.2.2. Response Definition...............................16 4.3. Modification of data storage method....................17 4.3.1. Store request.....................................17 5. Security Considerations.....................................18 6. IANA Considerations........................................18 7. References.................................................19 7.1. Normative References...................................19 Wang Expires September 2, 2009 [Page 2] Internet-Draft P2PSIP Event Notification Extension March 2009 7.2. Informative References.................................19 8. Acknowledgments............................................19 Wang Expires September 2, 2009 [Page 3] Internet-Draft P2PSIP Event Notification Extension March 2009 1. Introduction Some applications, such as push mail, telecom call server, require the real-time data synchronization between service logic function and data storage function. If the latter is built by p2p technology, some real time data access mechanism must be implemented in the p2p overlay so that any data modification can be conveyed to the application immediately. The subscribe/notify mechanism is the best solution for doing this. In the p2psip architecture, considering following scenarios: 1. indirect connected client subscribes to the data The subscriber is not a p2p peer node. It connects the p2p overlay via a peer while the target data object stored in another peer. The protocol used to access the overlay may be a p2p client protocol or other overlay agnostic one, such as diameter, LDAP etc. See Figure 1. 2. direct connected client subscribes to the data The subscriber is not a p2p peer node. It connects the p2p overlay via a peer which is just the one data object stored. 3. peer subscribes to the data The subscriber is a normal peer lies in the same overlay as the one storing target data object. +------------------+ |Data-Storage Peer | +--------+---------+ | | +--------+---------+ | Access Peer | +--------+---------+ | | +--------+---------+ | Subscriber Client| +------------------+ Figure 1 Scenario 1 Wang Expires September 2, 2009 [Page 4] Internet-Draft P2PSIP Event Notification Extension March 2009 +------------------+ |Data-Storage Peer | +--------+---------+ | | +--------+---------+ | Subscriber Client| +------------------+ Figure 2 Scenario 2 +------------------+ |Data-Storage Peer | +--------+---------+ | | +--------+---------+ | Subscriber Peer | +------------------+ Figure 3 Scenario 3 2. Conventions used in this document 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 RFC-2119 0. In the document we use the terminology and definitions from the drafts as followed: the Concepts and Terminology for Peer to Peer SIP [I-D.ietf-p2psip-concepts]; REsource LOcation And Discovery (RELOAD)[I-D. ietf-p2psip-base]. Other terms used in this document are defined inline when used and are also defined below for reference. SUBSCRIBE: The subscribe message is used to request current state and state updates for a resource from a remote node. NOTIFY: The notify message is used to inform subscribers of changes in state to which the subscriber has a subscription. Wang Expires September 2, 2009 [Page 5] Internet-Draft P2PSIP Event Notification Extension March 2009 Subscription: The Subscription is the act of a Subscriber sending a SUBSCRIBE message to a notifier to request current state and state updates for a resource. By definition, subscriptions exist in both a subscriber and a notifier. Notification: The Notification is the act of a notifier sending a NOTIFY message to a subscriber to inform the subscriber of the state of a resource. Notifier: A Notifier is a peer who generates Notify requests for the purpose of notifying subscribers of the state of a resource. Notifier typically also accepts Subscribe requests to create subscriptions. Subscriber: A Subscriber is a client or peer who receives Notify requests from Notifiers. These Notify requests contain information about the state of a resource in which the subscriber is interested. Subscribers typically also generate SUBSCRIBE requests and send them to Notifiers to create subscriptions. SubscribeGateway: A SubscribeGateway is a peer which is adjacent to the non-peer subscriber and do protocol translation between p2p peer protocol and other one. Accordingly, the SubscribeGateway forwards the SUBSCRIBE/Notifier messages between Notifiers and Subscribers. 3. Overview of the Subscriber/Notifier behavior 3.1. Subscription model in p2psip There are two p2psip subscription models: one model is explicit subscription, another is implicit subscription. 3.1.1. Explicit subscription The explicit subscription is created by a subscribe request and a successful SUBSCRIBE answer. A client or peer in the p2psip overlay subscribe to a resource from the notifier by sending subscribe request and receiving subscribe answer. The explicit subscription's flow of messages as followed: Wang Expires September 2, 2009 [Page 6] Internet-Draft P2PSIP Event Notification Extension March 2009 +------------+ +------------+ | Subscriber | | Notifier | +-----+------+ +------+-----+ | | |----- F01.Subscribe Request ---->| |<----- F02.Subscribe Answer -----| | | |<------ F03.Notify Request ------| |------- F04.Notify Answer ------>| | | |<------ F05.Notify Request ------| |------- F06.Notify Answer ------>| | | | | Figure 4 A flow of explicit subscription In figure4, F01 and F02, explicit Subscribe request and a Subscribe answer message create a Subscription, so called the explicit subscription. 3.1.2. Implicit subscription The implicit subscription is typically established by a non-Subscribe message. Assuming a kind of shared resource exists, one application put a resource into the overlay, the other applications make changes, each application need to know the real time state of the data. Additional explicit subscribe requests can meet above requirements, but for performance optimization purpose, the subscriptions should better be carried out by the data manipulation operations in case of excess traffic. The figure 5 shows a flow of implicit subscription: Wang Expires September 2, 2009 [Page 7] Internet-Draft P2PSIP Event Notification Extension March 2009 +------------+ +------------+ | Subscriber | | Notifier | +-----+------+ +------+-----+ | | |--- F01.non-Subscribe Request -->| |<--- F02.non-Subscribe Answer ---| | | |<------ F03.Notify Request ------| |------- F04.Notify Answer ------>| | | |<------ F05.Notify Request ------| |------- F06.Notify Answer ------>| | | | | Figure 5 A flow of implicit subscription In the above figure, F01 and F02 build an implicit subscription. 3.2. Subscriber Behavior 3.2.1. Subscription Duration The "Expires" parameter in a SUBSCRIBE request indicates the lifetime of the subscription. The value set to 0xffffffff indicates that the subscription always exist until the resource deleted or an explicit subscription cancel operation accepted. In order to keep subscriptions effective beyond the duration suggested by the "Expires" value, subscribers need to refresh subscriptions periodically using new SUBSCRIBE message. The Notifier can override the subscription period by putting a new Expires value in the answer. The "Expires" value in the subscribe answer be less than or equal to that specified in the request, but MUST NOT be longer. 3.2.2. Subscription Event A subscribe message MUST contain at least one event indicates the events the subscriber concerning. Once one of these events happens, the notifier MUST immediately construct a notify request and send it to the subscriber. The notify request SHOULD include the event list triggering itself. After a subscription is established, the subscriber MAY add or remove partial events of the subscription by an update request. Wang Expires September 2, 2009 [Page 8] Internet-Draft P2PSIP Event Notification Extension March 2009 3.2.3. Creating a Subscription When a subscriber wishes to subscribe to a particular event for a resource, it generates a Subscribe request. The request MUST contain the following information: a resource id, a subscription id , an "Expires" value, and an event set. The notifier acknowledges the request by a SUBSCRIBE answer. A SUBSCRIBE answer indicates that the subscription has been accepted, and that a Notify message will be sent immediately. An answer with the message code 0xffff indicates that the subscribe request has been rejected, and no Notify message will be sent. Otherwise, the Notifier accepts the request, and stores the resource id, subscription id and event list for further processing. 3.2.4. Refreshing a Subscription Before a subscription expires, the subscriber MAY refresh the subscription duration by sending another SUBSCRIBE request which has the same resource id and subscription id with the original one. The handling for such a request is the same as for the initial one. 3.2.5. Canceling a Subscription Before a subscription expires, the subscriber MAY cancel the subscription. The cancel request is same as the normal subscribe one, except the "Expires" value MUST be set to 0. 3.2.6. Processing notify messages When receiving a notify request, the subscriber SHOULD check that: a) If the resource id in the request matches at least one of its own subscriptions. If not, the subscriber MUST stop checking and return an ERROR answer to notifier. b) If the subscription id in the request matches at least one of its own subscriptions. If not, the subscriber MUST stop checking and return an ERROR answer to notifier. c) If the events of the notify request are not supported, the subscriber SHOULD respond with an ERROR answer to notifier. Once all checks passed, the notification is deemed acceptable to the subscriber; and the subscriber SHOULD return a notify answer. Wang Expires September 2, 2009 [Page 9] Internet-Draft P2PSIP Event Notification Extension March 2009 The "Expires" values present in SUBSCRIBE answer behavior is: the Notifier MAY shorten the interval, but MUST NOT lengthen it. 3.3. Notifier Behavior 3.3.1. Processing a subscribe request When receiving a subscribe request, the notifier SHOULD check that: a) If the resource specified in the request is belong to the notifier. If not, the notifier MUST return an ERROR answer to indicate that the resource can not be found. b) If the events specified in the request is understood. If not, the notifier MUST return an ERROR answer to indicate that the specified event is not understood. c) If the duration in the "Expires" value is not too small. If the expiration interval is greater than zero AND smaller than the minimum that notifier has configured, the notifier MAY return an ERROR response which contains a recommended "min-expires" value. Once all checks passed, the subscription is deemed acceptable to the notifier; and the notifier SHOULD return subscribe answer to the subscriber. If the notifier do not support the permanent subscription expected by a subscriber, it SHOULD set the expiration interval within the subscribe answer as the maximum value. Upon successfully subscription creating or refreshing operation, a notifier MUST send a NOTIFY message with the current resource state immediately to the subscriber . If the resource has no meaningful state at the time that the SUBSCRIBE message is processed, this NOTIFY message MAY contain an empty or neutral body. 3.3.2. Processing Refreshing request The handling for such a request is the same as for the initial creation of a subscription. 3.3.3. Generating a Notify request When a subscribe request is answered by a subscribe answer, the notifier MUST immediately construct and send a notify request to the subscriber. Wang Expires September 2, 2009 [Page 10] Internet-Draft P2PSIP Event Notification Extension March 2009 When an event subscribed by subscription occurs, the notifier MUST immediately construct and send a notify request to the subscriber. 3.3.4. Storage and replication The Notifier MUST store the subscription state as part of resource data object and enforce the same replication strategy. In case a node fails, the other node where the replica stored can process any request towards the replicated resource. 3.4. SubscribeGateway Behavior A client which can not communicate with the notifier directly SHOULD subscribe to the resource state through a SubscribeGateway. If the subscriber acts as a p2psip client, the SubscribeGateway MAY not store the subscription state, it forwards the subscribe requests and notify answers from Subscribers to Notifiers, the subscribe answers and notify requests from Notifiers to Subscribers according to the p2p routing rules. If the subscriber accesses the overlay via a protocol other than p2psip , the subscribegateway does protocol translation between the protocol used by subscriber to p2psip. When receiving a subscribe request from the subscriber, the SubscribeGateway translates non- p2psip protocol used by subscriber to p2psip protocol. Similarly, the SubscribeGateway translates notify request from p2psip to other protocol. The typical flow of messages as followed: Wang Expires September 2, 2009 [Page 11] Internet-Draft P2PSIP Event Notification Extension March 2009 +------------+ +------------------+ +------------+ | Subscriber | | SubscribeGateway | | Notifier | +-----+------+ +---------+--------+ +------+-----+ | | | |- F01.Subscribe Request -->| | | |- F02.Subscribe Request ->| | |<-- F03.Subscribe Answer -| |<-- F04.Subscribe Answer --| | | |<-- F05.Notify Request ---| |<--- F06.Notify Request ---| | |--- F07.Notify Answer ---->| | | |--- F08.Notify Answer---->| | | | | | | Figure 6 A flow of SubscribeGateway 4. Protocol details 4.1. Subscribe method The Subscribe method is used to create a Subscription which used to request current state and state updates for a resource from a remote node. 4.1.1. Request Definition The Subscribe request message is defined by the SubscribeReq structure as following: struct { Uint32 EventNumber; Uint32 EventId<0..2^8-1>; } EventList; enum EventId { evCreated=1, evModify, Wang Expires September 2, 2009 [Page 12] Internet-Draft P2PSIP Event Notification Extension March 2009 evDeleted, evAppSpecificStart=0x8000 } This document only define three basic event types, other document may introduce more values for EventId. Furthermore, applications can define new value beyond evAppSpecificStart without standardization. struct { ResourceId Resource_id; Unit64 Subscription_id ; Uint32 Expires; EventList Event; Opaque Specific_data<0..2^32-1>; } SubscribeReq; The contents of the structure are: Resource_id The ID of the resource which is subscribed to. Expires The Expires value of the subscription. Subscription_id The ID of the subscription. Event This parameter list the events that will be subscribed to. Specific_data Wang Expires September 2, 2009 [Page 13] Internet-Draft P2PSIP Event Notification Extension March 2009 Other opaque data used for the subscription. 4.1.2. Response Definition The Subscribe response message is defined by the SubscribeAns structure as followed: struct { ResourceId Resource_id; Uint32 Expires; Unit64 Subscription_id ; EventList Event; Opaque Specific_data<0..2^32-1>; } SubscribeAns; The contents of the SubscribeAns structure are: Resource_id The ID of the resource which is subscribed. Expires The Expires value of the subscription. Subscription_id The ID of the subscription. Event The event list which is subscribed. Specific_data Other opaque data used for the subscription. Wang Expires September 2, 2009 [Page 14] Internet-Draft P2PSIP Event Notification Extension March 2009 4.2. Notify method The Notify method is used to send current state and state updates for a resource which has been subscribed to the corresponding subscriber. 4.2.1. Request Definition The Notify request message is defined by the NotifyReq structure as followed: enum { Reserved (0), Active (1), Pending (2), Terminated (3), (255) } SubsrcriptionState; struct { ResourceId Resource_id; Unit64 Subscription_id ; SubsrcriptionState State; ReasonCode Reason; EventList Event; Opaque Specific_data<0..2^32-1>; } NotifyReq; The NotifyReq contents of the structure are: Wang Expires September 2, 2009 [Page 15] Internet-Draft P2PSIP Event Notification Extension March 2009 Resource_id The ID of the resource which is subscribed. State The state of the subscription. If the value is "Active (1)", it means that the subscription has been accepted by notifier. If the value is "Pending (2)", it means that the subscription has been received by the notifier, but has not enough information to accept or reject the subscription. If the value is "Terminated (3)", it informs that the subscription is being removed. Reason Used to describe the reason of non-active state. Expires The Expires value of the subscription. Subscription_id The ID of the subscription. Event The event list which is subscribed. Specific_data Other opaque data used for the subscription. 4.2.2. Response Definition The Notify response message is defined by the NotifyAns structure as followed: struct { Wang Expires September 2, 2009 [Page 16] Internet-Draft P2PSIP Event Notification Extension March 2009 ResourceId Resource_id; Unit64 Subscription_id ; EventList Event; Opaque Specific_data<0..2^32-1>; } NotifyAns; The contents of the structure are: Resource_id The ID of the resource which is subscribed. Subscription_id The ID of the subscription. Event The event list which is subscribed. Specific_data Other opaque data used for the subscription. 4.3. Modification of data storage method 4.3.1. Store request struct { ResourceId resource; uint8 replica_number; bool SubscribeAction; case of SubscribeAction { case true: Unit64 Subscription_id ; Wang Expires September 2, 2009 [Page 17] Internet-Draft P2PSIP Event Notification Extension March 2009 Uint32 Expires; EventList Event; case false: NULL; }; StoreKindData kind_data<0..2^32-1>; } StoreReq; 5. Security Considerations Subscribe operations introduce some extra states be stored in p2p overlay and trigger significant traffic when data modification happens. Malicious nodes can use this extension for DoS attack.To alleviate such risk, the overlay SHOULD reject any unauthorized subscribe request. 6. IANA Considerations +-------------------+----------------+----------+ | Message Code Name | Code Value | RFC | +-------------------+----------------+----------+ | subscribe_req | 29 | RFC-AAAA | | subscribe_ans | 30 | RFC-AAAA | | notify_req | 31 | RFC-AAAA | | notify_ans | 32 | RFC-AAAA | +-------------------+----------------+----------+ Wang Expires September 2, 2009 [Page 18] Internet-Draft P2PSIP Event Notification Extension March 2009 7. References 7.1. Normative References [RFC3265] A. B. Roach, "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. [RFC4981] Risson, J., "Survey of Research towards Robust Peer-to- Peer Networks: Search Methods", September 2007. [I-D.ietf-p2psip-base] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) Base Protocol", draft-ietf-p2psip-base- 01 (work in progress), December 2008. 7.2. Informative References 8. Acknowledgments Wang Expires September 2, 2009 [Page 19] Internet-Draft P2PSIP Event Notification Extension March 2009 Authors' Addresses Jun Wang ZTE Corporation No.68, Zijinghua Road, Nanjing, Jiangsu province China Email: wang.jun17@zte.com.cn Zhifeng Chen ZTE Corporation No.68, Zijinghua Road, Nanjing, Jiangsu province China Email: chen.zhifeng@zte.com.cn Wang Expires September 2, 2009 [Page 20]