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]