p2psip Jun Wang Zhifeng Chen Yu Meng Jiong Shen Internet Draft ZTE Corporation Intended status: Informational July 2, 2009 Expires: January 2010 P2PSIP Event Notification Extension draft-wang-p2psip-event-notification-extension-01.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 January 2, 2010. 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. Wang Expires January 2, 2010 [Page 1] Internet-Draft P2PSIP Event Notification Extension July 2009 Abstract The p2p technology is data centric. Data objects are distributed in the p2p overlay according to routing algorithm.Applications access the data objects via peer/client protocol or gateways, some of which need data replicas to be synchronized in real time. This can be achieved by introducing a Subscribe/Notify mechanism to p2psip. This document describes the Subscribe/Notify mechanism extension for p2psip, and also defines several new methods as needed. Table of Contents 1. Introduction................................................3 2. Conventions used in this document............................4 3. Overview of the Subscriber/Notifier behavior.................5 3.1. Subscription model in p2psip............................5 3.1.1. Explicit subscription..............................5 3.1.2. Implicit subscription..............................6 3.2. Subscriber Behavior.....................................7 3.2.1. Subscription Duration..............................7 3.2.2. Subscription Event.................................7 3.2.3. Creating a Subscription............................8 3.2.4. Refreshing a Subscription..........................8 3.2.5. Canceling a Subscription...........................8 3.2.6. Processing Notify messages.........................8 3.3. Notifier Behavior.......................................9 3.3.1. Processing a Subscribe request.....................9 3.3.2. Processing Refreshing request......................9 3.3.3. Generating a Notify request........................9 3.4. SubscribeGateway Behavior..............................10 4. Protocol details...........................................11 4.1. Subscribe method.......................................11 4.1.1. Request Definition................................11 4.1.2. Response Definition...............................12 4.2. Notify method.........................................13 4.2.1. Request Definition................................13 4.2.2. Response Definition...............................15 4.3. Implicit subscription extension........................16 5. Security Considerations.....................................16 6. IANA Considerations........................................16 7. References.................................................17 7.1. Normative References...................................17 7.2. Informative References.................................17 8. Acknowledgments............................................17 Wang Expires January 2, 2010 [Page 2] Internet-Draft P2PSIP Event Notification Extension July 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, the 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. client subscribes the data through indirect conection The subscriber is not a p2p peer node. It connects the p2p overlay via a peer while the target data object is 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. client subscribes the data through direct connection 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 the data The subscriber is a normal peer locating in the same overlay with the target data object storing peer. +------------------+ |Data-Storage Peer | +------------------+ | | +------------------+ | Access Peer | +------------------+ | | +------------------+ | Subscriber Client| +------------------+ Figure 1 Scenario 1 Wang Expires January 2, 2010 [Page 3] Internet-Draft P2PSIP Event Notification Extension July 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 following drafts: the Concepts and Terminology for Peer to Peer SIP [I-D.ietf-p2psip-concepts]; REsource LOcation And Discovery (RELOAD) Base Protocol [I-D. draft-ietf-p2psip-base-02]. Other terms used in this document are defined inline when used and are also defined below for reference. Subscribe request: The Subscribe request message is used to request current state and state update of a resource from a remote node. Subscribe response: The Subscribe response message is used to inform the subscriber the result of the Subscribe request. Wang Expires January 2, 2010 [Page 4] Internet-Draft P2PSIP Event Notification Extension July 2009 Notify request: The Notify request message is used to inform the subscriber of the resource state changes to which has a subscription. Notify response: The Notify response message is used to inform the notifier of the result of the Notify request. Subscription: The Subscription is the action of a Subscriber sending a Subscribe message to a notifier to request current state and state update of a resource. By definition, subscription data exists in both the subscriber and the notifier. Notification: The Notification is the action of a notifier sending a Notify message to a subscriber to inform the subscriber of the state or state update of a resource. Notifier: A Notifier is a peer who generates Notify request for the purpose of notifying subscriber of the state of a resource. Notifier typically also accepts Subscribe request to create a subscription. Typically, notifier is the data-storage peer of the resource. Subscriber: A Subscriber is a node 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 protocols. Accordingly, the SubscribeGateway forwards the Subscribe/Notify 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, the other is implicit subscription. 3.1.1. Explicit subscription The explicit subscription is created by a Subscribe request and a successful Subscribe response. The subscriber create an explicit subscription by sending Subscribe request to notifier and receiving successful Subscribe response. Wang Expires January 2, 2010 [Page 5] Internet-Draft P2PSIP Event Notification Extension July 2009 The explicit subscription's flow of messages as followed: +------------+ +------------+ | Subscriber | | Notifier | +-----+------+ +------+-----+ | | |----- F01.Subscribe Request ---->| |<---- F02.Subscribe Response ----| | | |<------ F03.Notify Request ------| |------ F04.Notify Response ----->| | | |<------ F05.Notify Request ------| |------ F06.Notify Response ----->| | | | | Figure 4 A flow of explicit subscription In figure4, F01 and F02, explicit Subscribe request and a Subscribe response 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 while the other applications make changes. Each application needs to know the real time state of the resource. Additional explicit Subscribe requests can meet above requirements, but for the performance optimization purpose, the subscriptions should better be carried out by the data manipulation itself in case of excess subscription operations. The figure 5 shows a flow of implicit subscription: Wang Expires January 2, 2010 [Page 6] Internet-Draft P2PSIP Event Notification Extension July 2009 +------------+ +------------+ | Subscriber | | Notifier | +-----+------+ +------+-----+ | | |--- F01.non-Subscribe Request -->| |<-- F02.non-Subscribe Response --| | | |<------ F03.Notify Request ------| |------ F04.Notify Response ----->| | | |<------ F05.Notify Request ------| |------ F06.Notify Response ----->| | | | | 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 is always available 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, subscriber needs to refresh the subscription periodically using a new Subscribe request message. The notifier can override the subscription period by putting a new Expires value in the response. The "Expires" value in the Subscribe response could 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 concerns. 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 January 2, 2010 [Page 7] Internet-Draft P2PSIP Event Notification Extension July 2009 3.2.3. Creating a Subscription When a subscriber wishes to Subscribe a particular event of 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 response. A Subscribe response indicates that the subscription whether has been accepted, and that a Notify message will be sent immediately. An response 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 the original one. 3.2.5. Canceling a Subscription Before a subscription expires, the subscriber MAY cancel the subscription. The cancel request is same with the normal Subscribe request, 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) Whether the resource id in the request matches at least one of its own subscriptions or not. If not, the subscriber MUST stop checking and return an ERROR response to notifier. b) Whether the subscription id in the request matches at least one of its own subscriptions or not. If not, the subscriber MUST stop checking and return an ERROR response to notifier. c) If the events of the Notify request are not supported, the subscriber SHOULD respond with an ERROR response to notifier. Once all checks passed, the notification is deemed acceptable to the subscriber and the subscriber SHOULD return a successful Notify response. Wang Expires January 2, 2010 [Page 8] Internet-Draft P2PSIP Event Notification Extension July 2009 The "Expires" values presented in Subscribe response behavior is: the Notifier MAY shorten the lifetime of the subscription, 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) Whether the resource specified in the request is belong to the notifier or not. If not, the notifier MUST return an ERROR response to indicate that the resource can not be found. b) Whether the events specified in the request is understood or not. If not, the notifier MUST return an ERROR response to indicate that the specified event can not be understood. c) Whether the duration in the "Expires" value is too small small or not. If the expires parameteris larger 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 response to the subscriber. If the notifier do not support the permanent subscription expected by a subscriber, it SHOULD set the expires parameter within the Subscribe response 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 when 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 with the original creation of a subscription. 3.3.3. Generating a Notify request After a Subscribe request is accepted and answered by a Subscribe response, the notifier MUST immediately construct and send a Notify request to the subscriber. Wang Expires January 2, 2010 [Page 9] Internet-Draft P2PSIP Event Notification Extension July 2009 Once a subscribed event occurs, the notifier MUST immediately construct and send a Notify request to the subscriber. 3.4. SubscribeGateway Behavior A subscriber 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 and it forwards the Subscribe request and Notify response from Subscriber to Notifier, the Subscribe response and Notify request from Notifier to Subscriber 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: +------------+ +------------------+ +------------+ | Subscriber | | SubscribeGateway | | Notifier | +-----+------+ +---------+--------+ +------+-----+ | | | |- F01.Subscribe Request -->| | | |- F02.Subscribe Request ->| | |<-F03.Subscribe Response -| |<-F04.Subscribe Response --| | | |<-- F05.Notify Request ---| |<--- F06.Notify Request ---| | |-- F07.Notify Response --->| | | |-- F08.Notify Response -->| | | | | | | Figure 6 A flow of SubscribeGateway Wang Expires January 2, 2010 [Page 10] Internet-Draft P2PSIP Event Notification Extension July 2009 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 of a resource from a remote node. 4.1.1. Request Definition The Subscribe request message is defined by the SubscribeReq structure as followed: struct { Uint32 EventNumber; Uint32 EventId<0...2^8-1>; } EventList; enum EventId { evCreated=1, evModify, evDeleted, evAppSpecificStart=0x8000 } This document only defines three basic event type, other documents may introduce more values for EventId. Furthermore, applications can define new value beyond evAppSpecificStart without standardization. struct { ResourceId Resource_id; Unit64 Subscription_id; Wang Expires January 2, 2010 [Page 11] Internet-Draft P2PSIP Event Notification Extension July 2009 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. Expires The Expiration duration value of the subscription. Expires set to 0xffffffff indicates the subscription always be available. Expires set to 0 indicates the subscription is to be canceled. Subscription_id The ID of the subscription. Event The event list which is subscribed. Specific_data 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; Wang Expires January 2, 2010 [Page 12] Internet-Draft P2PSIP Event Notification Extension July 2009 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 Expiration duration 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. 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), Wang Expires January 2, 2010 [Page 13] Internet-Draft P2PSIP Event Notification Extension July 2009 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: 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. Wang Expires January 2, 2010 [Page 14] Internet-Draft P2PSIP Event Notification Extension July 2009 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 Expiration duration 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 { ResourceId Resource_id; Unit64 Subscription_id; EventList Event; Opaque Specific_data<0...2^32-1>; } NotifyAns; The contents of the structure are: Resource_id Wang Expires January 2, 2010 [Page 15] Internet-Draft P2PSIP Event Notification Extension July 2009 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. Implicit subscription extension [notes]TBD 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 January 2, 2010 [Page 16] Internet-Draft P2PSIP Event Notification Extension July 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- 02 (work in progress), March 2009. 7.2. Informative References 8. Acknowledgments Wang Expires January 2, 2010 [Page 17] Internet-Draft P2PSIP Event Notification Extension July 2009 Authors' Addresses Jun Wang ZTE Corporation No.68, Zijinghua Road Nanjing, Jiangsu province 210012 China Email: wang.jun17@zte.com.cn Zhifeng Chen ZTE Corporation No.68, Zijinghua Road Nanjing, Jiangsu province 210012 China Email: chen.zhifeng@zte.com.cn Yu Meng ZTE Corpoporation C1-04,RD Building 1,Zijinghua Road Yuhuatai District,Nanjing 210012 P.R.China Phone: +86-025-5287-2045 Email: meng.yu@zte.com.cn Jiong Shen ZTE Corpoporation 4F,RD Building 2,Zijinghua Road Yuhuatai District,Nanjing 210012 P.R.China Phone: +86-025-5287-7648 Email: shen.jiong@zte.com.cn Wang Expires January 2, 2010 [Page 18]