A P2P Framework For Distributed And Cooperative ... - Springer Link

A P2P Framework For Distributed And Cooperative Laboratories Luca Caviglionel, Luca Veltri2 'University of Genoa - Department of Communications, Computer and Systems Science (DIST), Via Opera Pia 13, 16145 Genova (Italy) Phone: +39-010-3532202, Fax: +39-010-3532154 e-mail: [email protected] 2University of Parma - Dipartimento di Ingegneria dell'Informazione Parco Area delle Scienze 181/A, 43 100 Parma (Italy) Phone: +39-0521-905768, Fax: +39-0521-905758 e-mail: [email protected]

Abstract. In this paper we propose a p2p framework in order to organize the cooperation and the set-up phase of interconnected laboratories for didactical purposes through the Internet. Even if the application of standard p2p algorithms to distributed cooperative laboratories is a quite new methodology, we will base our approach on a solid foundation, such as the one provided by the Session Initiation Protocol (SIP). The proposed architecture solves some general problems such as the discovering of entities, and also provides, a general framework for devices accounting. In addition, our framework offers mechanisms in order to provide an abstract namespace for adding - removing facilities on the fly and invoking them.

Keywords: p2p systems, SIP, Overlay Networks, Distributed Laboratories.

1 Introduction Nowadays, many devices are connected through the Internet. As a matter of fact, there is an increasing trend in producing network-ready devices in order to make them remotely available. One of the oldest concepts that ignited the network technology is the one devoted to share and aggregate resources. In fact, the first network infrastructures were developed in order to share precious and expensive mainframes. With the awesome advancement of hardware technologies, this scenario is now also applicable to devices and instrumentations. The sharing of resources brings to cost reduction, and allows to set-up experiments previously unfeasible by creating chains of interconnected devices. In another respect, also a topic under debate is how to integrate instrumentation with a Grid infrastructure. Actually, access to sind control of instrumentation was fundamentally part of the original Grid vision, but it has been neglected in favor of

310

Distributed Cooperative Laboratories

middleware development. Recently, many projects are devoted to develop solutions to access instruments as well as reserving resource through the network [1,2,3,4]. The proposed work is aimed at introducing a framework allowing an effective cooperation among different instruments and devices in a networked environment. The basic assumption is that we will consider each laboratory as a peer and then we will build a p2p system that cooperates, in order to allow distributed experimentations with devices and resources located in different laboratories. For instance, concerning a measurement experiment, the device under test and the end user could be remotely located. In this perspective, the system is then distributed, because the resources used are not circumscribed to a local laboratory, and cooperative because different resources will be chained together in order to produce an experiment. This framework will allow to aggregate and superpose different instruments for building laboratory experiences or for providing instrument-oriented services as a Grid infrastructure. The paper is structured as follows: Section 2 investigates the state of the art within IETF for using SIP [5] as the signaling technology to build and maintain p2p overlays, and also envisages some possible architectural blueprints, in order to exploit SIP for building a distributed and cooperative laboratory environment. Section 3 briefly analyzes the state-of-art distributed technologies and then proposes some ideas for integrating JXTA with SIP, in order to provide a "lightweight JXTA" that can be used to develop further services for distributed laboratories. Section 4 depicts how to use SIP to remotely interact with devices, and Section 5 concludes the paper.

2 On using SIP to develop p2p systems In p2p networking all the hosts have the same capabilities and the same responsibilities. To emphasize the aspect, all the entities involved in this kind of network are named peers. However, the p2p paradigm introduces some problems: the topology is quite trivial, and the lack of a hierarchical organization brings to major difficulties in developing any kind of algorithms. There are no "well-known" nodes (in a client-server scenario, the server is the known service provider node) and the functionalities are shared across the network. This description perfectly fits for the unstructured p2p networks, such as Gnutella [6]. In this kind of network all peers interact by self-organizing themselves in order to form a network. Studies have shown that this kind of systems follow a "power-law" rule, where few nodes have a high number of connections and many nodes have a small number of connections. The main problem with this organization is due to the complete delocalization of the information and, in order to locate, content a controlled broadcast mechanism is mandatory. To cope with this, many proposals have been made in order to achieve better performance in the look-up phase both for peers and

A P2P Framework For Distributed And Cooperative Laboratories

311

resources. The root technology is the one based on Distributed Hash Tables (DHTs), allowing to organize the overlay by mapping the peers via a hashing function. This brings to structured p2p systems, such as CHORD [7] and Kademlia [8]. On the other hand, the current IP Telephony service has been built as a phone-to-phone (peer-topeer) system with very centric characteristics, based on serverlproxy nodes (in both H.323 and SIP architectures). Of course this approach may suffer from scalability problems, and some proposals to overcome this issue and to develop p2p Internet Telephony are arising. Particularly, in [9] the authors present an architecture based on SIP. The basic idea is to view the overall Internet telephony infrastructure as a p2p architecture, where all the participants are organized in a p2p overlay network. Consequently, the overlay could be exploited to locate users for initiating a telephone call. This architectural blueprint resembles Skype, but tries to overcome some of its limitations. In fact, Skype has been developed in a closed way, it does not appear as extensible for future services and it still relies on a central server for authentication procedures. Besides, IETF has long investigated protocols and techniques for deploying Internet telephony. The most appealing candidate is the SIP architecture, and with some adjustments it could be organized as a p2p system. In another respect, there are also some security issues that could be solved by using SIP in a p2p fashion. For instance, the architecture depicted in Figure 1 reduces the potential of failure due to a single node, resulting in increased robustness, and allows providing a preliminary protection against Denial-of-Service (DOS) attacks. This is possible, owing to the intrinsic resistance of DHT-based systems against churn, which is the continuous process of node arrival and departure.

3 Applying p2p principles on Distributed - Cooperative Laboratories During the years, many different architectural blueprints and protocols have been developed for p2p systems, especially for file-sharing. Each developer promoted his brainchild and implemented the required protocol functionalities: from the Napster protocol to sophisticated mechanisms such as eMule, they are basically built from scratch. This fact has also produced a waste of resources, since some protocols are overlapped in functionalities. Moreover, the lack of a coordinated and standardized approach results in a variety of p2p systems that cannot interact.


Fig. 1. SIP-based Laboratories arranged in a DHT overlay: each laboratory exports device(s).

In this perspective, even if not explicitly written for p2p, SIP could be used for different signalling purposes and, of course, also for building and managing p2p overlay systems. In addition, SIP can straightforwardly handle p2p traffic. This to demonstrate that albeit a big standardization campaign in p2p has not been undertaken, it must not be said that p2p architectures or supporting technologies are not available in existing technological pools. For instance "all servers in SIP are optional, allowing User Agents (UAs) to directly communicate" [lo]. Its server-less capabilities allow SIP to be one of the fundamental building blocks for p2p technologies. To prove the maturity of the SIP technology to carry out all the signal procedures mandatory for exploiting a full featured p2p application, reference [ l l ] tries to find out the required SIP messages in order to build a full featured Chord-based architecture. Particularly, the draft provides examples for the following operations: node registration, user .registration, session establishment, node leaving the system, successful user search and unsuccessful user search. This work looks promising allowing SIP to become a killer application, raising its popularity and, at the same time, exploiting the p2p paradigm to enhance the SIP technology itself. Also [12] proposes some ideas in order to fully exploit SIP as a p2p technology.

3.1 Integrating JXTA with SIP to build services on top of distributed laboratories Currently there is an important open project named JXTA [13], originally sponsored by SUN Microsystems, that aims to define a standard architecture and its protocols for building up p2p applications and services. JXTA comes also with a reference open-source Java implementation of its complete suite of protocols, in order

A P2P Framework For DistributedAnd Cooperative Laboratories

3 13

to shorten the time required to develop new p2p applications. JXTA defines a series of XML-based protocols for specific p2p basic functions, such as those for selforganizing peers to into peergroups, publishing and discovering peer resources, communicating, and monitoring other peers. One of the main characteristics of JXTA is that it is independent of any particular hardware platform, operating system, or programming languages, and does not require the use of any particular network transport or topology; the JXTA protocols can be implemented on top of TCPIIP, HTTP, Bluetooth, or other protocols and technologies. The approach followed by JXTA designers was to completely re-define a new network architecture and protocols, with poor reuse of already existing ones, and this led on one hand to some duplication of network protocols and functionality, and on the other hand to a scarce interoperability with already existing p2p-like services, such as real-time multimedia communications (also known as "IP Telephony"), building up with SIP. JXTA has been used for a variety of purposes, especially for communicating, conferencing and information sharing. JXTA could also be used to provide the remote laboratories a way to communicate, in order to: allow laboratory staff and researchers to carry out lectures or guided seminars and to help students in completing experiment and exercises; allow students to interact, and then, to cooperate remotely as if they populated a distributed classroom; allow using application layer techniques, such as "Application Layer Multicast", in order to exploit p2p techniques for multimedia transmission. In addition, JXTA could be used to offer virtual immersive functionalities for the interaction among involved parties as they participate in a synchronous e-learning session. We then describe an architecture based on JXTAISIP that tries to integrate the JXTA architecture with the SIP platform and functionality. The basic idea is to place the JXTA architecture on top of SIP, replacing all JXTA protocols and services that are already provided by the SIP architecture. The SIP infrastructure is already present, since it is a fundamental building block of our architecture. The mix of SIP and JXTA will provide a simple and efficient mechanism, allowing communication among different laboratories-devices. It will also provide an "architecture independent" layer, in order to build services on top of the networked laboratory facility. The JXTA specification originally defines six main protocols, which we recall below:

- The Peer Resolver Protocol (PRP) is the mechanism by which a peer can send a query to one or more peers, and receive responses to the query. - The Peer Discovery Protocol (PDP) is the mechanism by which a peer can advertise its own resources, and discover the resources from other peers. Every peer resource is described and published using an advertisement.

3 14


- The Peer Information Protocol (PIP) is the mechanism by means of which a peer may obtain status information about other peers (such as state, uptime, traffic load, capabilities, and other information). - The Pipe Binding Protocol (PBP) is the mechanism by which a peer can establish a virtual communication channel or b'pipe7'between one or more peers. The PBP is used by a peer to bind two or more end points of the connection. - The Endpoint Routing Protocol (ERP) is the mechanism by which a peer can discover a route (sequence of hops) used to send a message to another peer. - The Rendezvous Protocol (RVP) is the mechanism by which peers can subscribe or be a'subscriber to a propagation service. The RVP is used by the Peer Resolver Protocol and by the Pipe Binding Protocol in order to propagate messages. These protocols relay on a common transport layer named "Endpoint Service", which is responsible of end-to-end messaging between two JXTA peers, using one of the underlying transport protocols, such as the JXTA TCP, TLS, or HTTP. The Endpoint Service, together with the PRP, ERP, and PBP protocols are the building blocks that a JXTA application uses to communicate with other peers. They act as signalling and messaging infrastructure allowing communications between remote peers based on peer IDS. However SIP protocol also provides a signalling platform for communicating and establishing sessions between end-systemslpeers (referred as UAs). For this reason, the integration of the two technologies in the JXTAISIP architecture seems to be very promising, providing twofold benefit: i) reuse of well-known and tested signalling platform without replicating functionality, and ii) integration with existing multimedia/IPTel infrastructure and devices. Particularly, in the proposed JXTAISIP architecture the upper JXTA protocols PDP and PIP, and the resolver functionality of PRP and RVP are mapped directly upon the SIP protocol and its signalling platform. In such way, all the transport and messaging infrastructure offered by the Endpoint Service, by PRP, ERP, and PBP is no longer required and is replaced by SIP. The SIP protocol provides all addressing, messaging and routing functionality, reusing different types of underly transport protocols (e.g. UDP, TCP, TLS, and SCTP). The addressing scheme of SIP allows the unique identification of UAs and SIP users. However, in a p2p environment, it can be also useful to be able to generically address single resources, or services. For this reason JXTAISIP extends the traditional SIP URI scheme, by providing a simple and flexible mechanism to address any kind of resource owned by or associated to a generic SIP user. The SIP URI scheme sip: [user@]nameaddress[:port][;uri-parameters] is still used, and the new parameter resource is introduced, obtaining the following resource address

'


where the value of the parameter resource (i.e. the resouce-name) is the peer URN (Uniform Resource Name), used in JXTA to identi@ peer entities. SIP provides JXTA also the method for delivering XML-based JXTA messages, encapsulated within the body filed of SIP messages, with Content-Type applicationlxml-jxta. SIP methods used to deliver JXTA messages can vary according to the implemented upper layer service. However, the most common SIP methods used with JXTA are: MESSAGE, SUBSCRIBE and NOTIFY. Here is an example of SIP message used for sending a JXTA Discovery Query: MESSAGE SIP: [email protected];resource=jxta://abdcf23 SIP/2.0 Via: SIP/2.O/TCP 192.168.5.2;branch=z9hG4bK776sgdkse Max-Forwards: 70 From: SIP:[email protected];resource=jxta://678ffr;ta~49583 To: SIP: rdzv@ zoolu.org;resource=jxta://abdcf23 Call-ID: asd88asd77ae1.2.3.4 CSeq: 1 MESSAGE Content-Type: application/d-jxta Content-Length: 340

Resolver query Discovery query

Upon SIP, there is the PRPIRVP layer that comprises the various JXTA resolver and propagation related protocols, such as PRP and RVP. PRP is a simple querylresponse protocol that provides a simple addressing resolution mechanism for upper layer protocols. It can be used in point-to-point, multicast, and propagation mode. It uses the SIP MESSAGE methods for message delivery. Although SIP provides direct peer addressing and routing, message propagation within a peer group is also required in a p2p scenario. For this scope the RVP (Rendezvous Protocol) is used within the PRP/RVP layer. The RVP provides mechanisms which enable propagation of messages to be performed in a controlled way. To most efficiently propagate messages some peers acts as Rendezvous Peer cooperating with other Rendezvous Peers and with client peers to propagate messages amongst the peers of a peer group. The PRPRVP layer will propagate a message unless one of the following conditions is detected: i) Loop detected: if a propagated message has already been processed on a peer, it is discarded; ii) Time To Live (TTL) exceeded: propagated messages are associated with a TTL that is decreased each time a propagated message is received by a peer; when the TTL of a message drops to zero, the message is discarded; iii) Message duplication: a peer discards copies of an already received message. Upon the PRPIRVP layer there are the JXTA upper level protocols, mainly the PDP (Peer Discovery Protocol) and the PIP (Peer Information Protocol). PDP is used to discover any published peer resource. Resources are represented as advertisements.

3 16


A resource can be a peer, a peer-group, a pipe, a module, or any resource that has an advertisement. Each resource must be represented by an advertisement. The PDP enables a peer to find advertisements in its group. Custom discovery services may choose to leverage PDP. Once a peer is located, its capabilities and status may be queried. PIP provides a set of messages to obtain a peer status information. PIP is an optional protocol. Peers are not required to respond to PIP requests.

4

Direct device-to-device communications

In the previous section we showed how it is possible to build a complete p2p architecture based on SIP. Such architecture in turn can be used to realize a distributed, self-organized network of laboratories and end-devices. In this section we describe how SIP can provide also methods for direct device-to-device communications in the form of simple client-server commands or more sophisticated communication schemes. The SIP protocol has been originally defined as a mechanism for establishing sessions between two or more peers. However, the SIP architecture is very flexible and can be easily extended for building a wide spectrum of services. For example, SIP can be used to establish one-to may or many-to-many communication, to realize a presence service, as well to implement an instant messaging system. In our scenario some mechanisms are required in order to implement direct deviceto-device communications. For this goal, two main mechanisms are needed: 1) an addressing scheme able to address specific laboratories, instruments, their components and functions;

2) a set of basic methods that can be used to handle the direct interaction among these end-systems. Regarding the first aspect, in the previous section we presented an extension of the basic SIP URI scheme that can provide the required addressing functionality to cover a distributed laboratory environment. Particularly, when the SIP URI refers to a laboratory or an instrument, the 'resource' parameter can be used to address a specific sub-component or functionality. Here is an example of how the URL of an oscilloscope within a laboratory can be

Concerning the second aspect, either standard SIP methods or new ad-hoc methods could be used. SIP natively defines a number of methods for initiating a session (INVITE, ACK, CANCEL, BYE), for querying for user-agentlserver capabilities (OPTIONS), and for registering with a location service (REGISTER). In addition, SIP provides means to facilitate protocol extension through the introduction of new methods and the definition of new header fields. As matter of fact, currently a number of methods


3 17

have been already defined, addressing several different functions. In our scenario, two kinds of basic interactions between parties are required: i) a direct clientlserver method that can be used to issue commands or to send outof-band data, ii) a method for receiving asynchronous information and for being notified of specific events by a peer entity. As far as the first kind of communication is concerned, the MESSAGE method can be used. The MESSAGE method has been defined as SIP extension for Instant Messaging (IM) [14]. This method does not establish a session and can be used to transfer single instant messages (like pager messages) carried in the form of MIME body parts within the message. In our context, the MESSAGE method can be used to send single commands or data to a peer device. The form of the transferred information is application dependent; however a common XML representation could be used. For example, here is the message that can be sent to switch on a device: MESSAGE sip: [email protected];resourcegenerator SIP/2.0 Via: SIP/2.0/UDP 10.10.0.5;branch=z9hG4bKdf334 Max-Forwards: 70 To: From: Alice ;tag=1166ccae Call-ID: [email protected] CSeq: 1 MESSAGE Content-Type: application/xml Content-Length:

...

In order to handle the second kind of communications, in which a device asynchronously receives requested data from a remote peer when a certain event occurs, the SIP event notification framework can be used [15]. The event notification framework has been properly defined as SIP extension to provide means by which SIP nodes can request notification from remote nodes, indicating that certain events have occurred. This framework uses two main methods: SUBSCRIBE and NOTIFY. Particularly, the SUBSCRIBE method should be used to request current state and state updates from a remote node, while NOTIFY messages are sent to inform subscribers of changes in state to which the subscriber has a subscription. Here is an example of how these methods can be applied for receiving asynchronous reports from a protocol analyzer in a context of distributed laboratories: SUBSCRIBE sip:net-lab2@~us.net;resource=proto-analyzerSIP/2.0 Via: SIP/2.0/UDP 10.10.0.5;branch=z9hG4bK85~2f Max-Forwards: 70 To: From: Alice ;tag=3758f5U3 Call-ID: [email protected] CSeq: 22 SUBSCRIBE Contact: Event: trace Content-Type: application/xml Content-Length: ... host 192.168.1.88 and udp and port 4444

318


NOTIFY sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP 192.168.0.2;branch=z9hG4bKb1454 Max-Forwards: 70 To: Alice ;tag=3758f51b fiom: ;tag=763287060 Call-ID: [email protected] CSeq: 34321 NOTIFY Event: trace Content-Type: application/d Content-Length: ...

Alice

Protocol Analyzer

SUBSCRIBE slp:[email protected];r~~ource=~oto-analyzw b 200 OK

packet

packet

Get trace

NOTIFY slp:[email protected]

NOTIFY slp:[email protected]

Fig. 2. Example of asynchronous event notification. Lastly, the devices must be exported by using a proper "manager" if needed. For instance, many instruments could be managed by a standard computer without third party hardware or software. Besides, other instruments may be connected to a SIP manager running in a personal computer via a GPIBIEthernet adapter. The rule of thumb is that the instrument data must be properly converted in order to assure the correct communication fromlto the instrument.

5

Conclusions and Future Work

In this paper we proposed a p2p-based system in order to provide a framework for distributed and cooperative laboratories. We used SIP as the technological base for effectively building such a framework and, in addition, we also presented how to use JXTA to enrich the framework with valuable features. Lastly, we presented some instances of the use SIP to effectively interact with devices, providing an idea for a simple and cost-effective interoperation of instrumentation that avoids more complex systems such as one present in the Grid world. Future work will be aimed at refining

A P2P Framework For DistributedAnd Cooperative Laboratories

319

this architecture and at using the SIP protocol also to issue QoS requirements to the network, in order to carry out industrial and mission critical experimentations.

References I. L. Benetazzo, M. Bertocco, F. Ferraris, A. Ferrero, C. Offelli, M. Parvis, V. Piuri, "A Web based, distributed virtual educational laboratory", IEEE Trans. on Instrum. and Meas., vo1.49, No. 2, April 2000, pp.349-356. 2. A. Bagnasco, M. Chirico, A.M. Scapolla, "XML technologies to design didactical distributed measurement laboratories", Proc. of 19th IEEE IMTC, Anchorage, AK, USA, vol. 1,2002, pp. 65 1-655. 3. P. Daponte, C. De Capua, A. Liccardo, "A technique for remote management of instrumentation based on web services", Proc. of IMEKO-TC4 13th Internat. Symposium on Measurement for Research and Industry Applications, Athens, Greece, 2004, pp. 687692. 4. The Grid Enabled Remote Instrumentation with Distributed Control and Computation (GRIDCC) Project, http://www.gridcc.org. 5. Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", IETF RFC 3261, June 2002. 6. Gnutella Protocol Specification, http://www.gnutella.com. 7. Stoica, I., Morris, R., Karger, D., Kaashoek, M. and H. Balakrishnan, "Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications", SIGCOMM '01, August 2001. 8. Kademlia: A Peer-to-peer Information System Based on the XOR Metric, http://kademlia.scs.cs.nyu.edu/. 9. The p2p-SIP project at Columbia University, http://wwwl .cs.columbia.edu/-kns lO/research/p2p-sip/ 10.A. Johnston, "SIP, P2P, and Internet Communications", IETF Internet Draft , January 2005. ll.D. Bryan, C. Jennings, "A P2P Approach to SIP Registration", IETF , January 2005. 12.L. Caviglione, L. Veltri, "Using SIP as P2P Technology", Invited Paper at 12th International Conference on Telecommunications (ICT 2005), Capetown, South Africa, 3-6 May 2005. 13."JXTA v2.0 Protocols Specification", http://www.jxta.org 14.B. Campbell, J. Rosenberg, H. Schulzrinne, C. Huitema, "Session Initiation Protocol (SIP) Extension for Instant Messaging", IETF RFC 3428, December 2002. 15.A. B. Roach, "Session Initiation Protocol (SIP)-Specific Event Notification", IETF RFC 3265, June 2002.