Network Working Group FX of Phenoelit Request for Comments: XXXX Phenoelit Category: Informational January 2002 Joint Routing Protocol Status of this Memo This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) Phenoelit Group - as long as someone still understands the meaning of copyrights at all after implementation and more or less extensive testing of this protocol and it's features. Management Summary The Joint Routing Protocol is designed to make any given number of people look equally stupid using only one joint. It is basically an improved version of having any given number of people sit in a management meeting for approximately eight hours. Application Although the protocol itself is not strictly limited to digital machines in general and the Internet in particular, it can be implemented for both. The main application of this protocol comes from the fact that the Internet community at large has a great need for this protocol to be standardized. Introduction The Joint Routing Protocol (JRP) is designed to overcome problems arising during gatherings of more than one entity participating in the application of certain gifts of nature. These includes (but are not limited to) smoking of any kind of cigarette (better known as joint) that contains the substance known as THC. The goal is, for any given amount of entities to distribute the effects of the substance THC equally between all of them. Since physiological and technical conditions may vary significantly between different participating entities, a protocol for distribution is required. Terms used The following terms are used throughout the protocol definition: Element of Interest (EoI) The device that contains the substance THC. It is assumed that every PARTICIPANT (see below) is able to apply this device to himself more or less effectively. CURRENT HOLDER (CH) The participating entity that currently possesses the element of interest. REQUESTOR (REQ) One or more participating entities that would like to become the CURRENT HOLDER. PARTICIPANT (PA) Any entity participating in the protocol communication and willing to become at least once a CH or REQ. AREA The AREA describes the protocol space of the underlying transport mechanism. This might be any media driven by electricity, light or sound. The default media is a gas consisting mainly of Oxygen, carbon dioxide and other parts that uses sonic transmission. The AREA MAY contain entities that are not PAs - these are ignored and will be automatically ignored if the JRP protocol run is successful. The terms MAY, SHOULD, SHOULD NOT, MUST and MUST NOT are used according to RFC 2119. The rest is pure bullshit. States of processing - general overview The protocol's execution begins at the point where the Element of Interest (probably a joint) is engaged. This is usually the case if the element of interest is lit or set on fire in some other way that facilitates the effective application. Throwing the Element of Interest into a larger fire (such as a fireplace or tendril) is not considered a protocol execution start point but rather a protocol violation and a good reason to beat the shit out of the entity doing this. The protocols execution MAY end at various stages of processing. A complete JRP run is marked by the lifetime of the Element of Interest. If this lifetime ends (due to whatever reason), the protocol run is considered finished. During a protocol run, the general procedure is executed in a loop: The CURRENT HOLDER announces the availability of the Element of Interest using a broadcast message to the AREA. Any interested REQUESTOR then reacts to this announcement using a request message. The CURRENT HOLDER passes the Element of Interest to the first REQUESTOR who's message reached the central processing unit of the CURRENT HOLDER. This may be different from the REQUESTOR who actually send the request message first but is not considered a protocol violation itself - unless the ignored REQUESTOR is ignored several times (see Implementation below). In case the end of life for the Element of Interest is reached, the CURRENT HOLDER announces this using another broadcast message to the AREA. The ultimate goal is to reach JRP convergence. Convergence is reached if no PARTICIPANT is interested in becoming a REQUESTOR. This is the final state of the AREA and there should be no more JRP runs in this AREA after this state. An AREA (including all PARTICIPANTS) reaches convergence, if the last protocol run has come to a state where no JRP messages are transmitted anymore for a considerable long period of time. This can be the result of no messages of any kind transmitted or just no more potential REQUESTORS available. In case the Element of Interest is still available and has not yet reached it's end of life, the end of life is forced by the CURRENT HOLDER at this point. An optional JRP finish request can be used to validate this state (see Implementation). Various protocol features are defined to handle situations where the CURRENT HOLDER violates protocol timers or PARTICIPANTS violate the protocol. See the Implementation section for details. General Implementation Notes Timing in this protocol is not very critical and does not require time synchronization of any kind between the PARTICIPANTS. This would be counterproductive anyway. Every entity is allowed to have it's own understanding of the time-space environment and scale. This is a desired effect of JRP. In case of huge discrepancies between the time scale of several PARTICIPANTS, a general friendly attitude towards the point of view of REQUESTORS SHOULD BE taken. Although the protocol is based on broadcast, the strength of the signal should be adjusted so that only the PARTICIPANTS in the AREA can receive the message. There is no need to waste bandwidth of a shared medium. The signal strength is not considered an element of decision for the CURRENT HOLDER while deciding which REQUESTOR will receive the Element of Interest next. Implementation messages highly depend on the medium the protocol is run over. This document assumes a clear text protocol - but the messages can be replaced by next to anything - as long as they stay unique. As long as a clear text protocol implementation seems feasible, it SHOULD BE implemented. The messages in this paper SHOULD be used unless there is a requirement for internationalization or numeric representation. Implementation I) Start Phase When starting a protocol run, the CURRENT HOLDER SHOULD take care that the Element of Interest is started in a way that makes it's life time as long as possible. The CURRENT HOLDER MAY choose to announce the protocol start by the JRP start message: "HERE WE GO" II) Joining To become a PARTICIPANT, the entity is required to discover the availability of an Element of Interest. This is easily done if there is already a JRP run in progress. Joining an AREA as a PARTICIPANT is always possible. The newly joined PARTICIPANT SHOULD try to discover the state of the other PARTICIPANTS and the JRP run state. If the Element of Interest has nearly reached the end of life state, the new PARTICIPANT could as well look for the required requisites to create a new one rather then trying to join the current run. This makes everyone more happy. It is not required to announce the transition from an external entity to PARTICIPANT in any way. III) Normal routing Normal routing occurs if the CURRENT HOLDER used the Element of Interest and wants to forward it to another PARTICIPANT. The CURRENT HOLDER SHOULD perform this step after one or two applications of the Element of Interest. In this case, the CURRENT HOLDER announces the availability using the JRP available message: "PING" Any PARTICIPANT that wants to become a REQUESTOR will then respond to this message by the appropriate JRP request message: "PONG" Note: Although it might appear as a valid response, the message "BONG" is not considered valid . It could be misinterpreted and is therefore a clear protocol violation. The CURRENT HOLDER MUST ignore REQUESTORS using different messages. After the REQUESTORS send their message one or more times to the AREA, the CURRENT HOLDER passes the Element of Interest to the REQUESTOR who's message first reached the central processing unit of the CURRENT HOLDER. This REQUESTOR becomes the CURRENT HOLDER. In case of no REQUESTORS answering to the JRP availability message, the CURRENT HOLDER MUST repeat the availability message at least three times. Then he MAY continue to apply the Element of Interest to himself. If he chooses to not proceed, the CURRENT HOLDER MUST transit the protocol into the forced end of life state. IV) End of Life If the end of life for the Element of Interest is reached, the CURRENT HOLDER announces this with the JRE end of life message: "Eeergh" An alternative implementation of this message is supported: "That's it" V) Forced End of Life If the CURRENT HOLDER did not receive any request messages following the availability message (see Normal Routing), he MAY choose to announce the forced end of life for the Element of Interest using the informal message: "OK, end" Following this optional message, the CURRENT HOLDER will force an end of life state to the Element of Interest and finish the JRP run. VI) Status Messages Any CURRENT HOLDER MAY issue status messages to the AREA. These can be used to inform other PARTICIPANTS of the effectiveness of the current JRP run and therefore shorten the time to convergence. The supported status messages are listed below. "Oh my god" This message indicates that the Element of Interest is highly effective. "Oh well" This message indicates that the Element of Interest is not very effective. "Who build this?" This status message is a feedback provided to the entity that initially built the Element of Interest. The entity that builds the next one should consider doing it better since this status message normally hints at a bad implementation of the current one. "Shit" This message indicates that the CURRENT HOLDER will probably announce the availability of the Element of Interest shortly. "Where is the beer?" This request is a special message indicating that the CURRENT HOLDER will need an additional device containing some liquid (preferable beer) to complete his application. The PARTICIPANTS can now decide to offer such device to the CURRENT HOLDER and delay the next availability message a little or refuse to support him and hereby force an earlier availability. VII) Failover Mechanism Since the protocol is designed to come to a halt in case of convergence, the PARTICIPANTS that did not reach convergence so far have to take care that the CURRENT HOLDER did not already reach it. If this is the case, the CURRENT HOLDER will not announce the availability of the Element of Interest to the AREA and therefore would break the JRP run. This condition does not require that the CURRENT HOLDER stopped to communicate completely. It might happen frequently that the CURRENT HOLDER has reached convergence and his JRP protocol stack simply does not require any more JRP communication. In the case of a not announcing CURRENT HOLDER, a forced passing of the Element of Interest is supported. A PARTICIPANT becomes a forcing REQUESTOR by issuing the JRP request message several times as unicast to the CURRENT HOLDER: "PONG,PONG,PONG" If the CURRENT HOLDER is for some reason unable to understand the request correctly or does no longer react to protocol messages at all (because of a faulty protocol stack implementation), the REQUESTOR is allowed to obtain the Element of Interest directly. This method SHOULD NOT be used unless the CURRENT HOLDER is not reacting in a timely fashion (see notes about timing). VIII) Unsolicited Request During any time in the protocol run, a PARTICIPANT is allowed to advance his state to REQUESTOR. This can be done by issuing an informal message to the CURRENT HOLDER: "Here" The CURRENT HOLDER SHOULD cache this information and pass the Element of Interest to the early REQUESTOR in case of availability. The CURRENT HOLDER MAY run a normal routing step (JRP availability message) to validate that the early REQUESTOR has still interest in the Element of Interest. The unsolicited request SHOULD be used by PARTICIPANTS that got ignored several times during protocol steps although they reacted in a proper way. IX) Leaving and Rejoining the AREA In case a PARTICIPANT needs to leave the AREA for some time, he SHOULD announce this using the JRP away message: "Back in a few" The PARTICIPANT MUST NOT expect to be part of the next routing steps. Rejoining the AREA is always possible due to the fact that there is no announcement message needed to inform other PARTICIPANTS. X) Preventive Request for a new JRP run In case the Element of Interest might reach the end of life state frequently until convergence is reached, PARTICIPANTS MAY inform the AREA that a new Element of Interest is required shortly. Any PARTICIPANT MAY choose to send a message to the AREA or another PARTICIPANT: "Make one" The PARTICIPANT MUST NOT send this message as unicast to the CURRENT HOLDER, since he is probably busy performing the application of the currently used Element of Interest. XI) Handling protocol violations If any PARTICIPANT violates the protocol, another PARTICIPANT MAY choose to inform the violator by sending the JRP protocol violation message: "Hey!" An alternative implementation is supported: "Protocol violation" This message might SHOULD include an extensive explanation of the violation spotted but has no effect on the state of the entity violating the protocol. In case there is a loop where multiple parties cannot agree on the correct implementation, one side can decide to dump core and leave the others the fuck alone. The PARTICIPANTS MAY as well choose to split the AREA in two AREAs and handling the protocol slightly differently for the sake of functionality until one party can prove their claim using this document. If none of this can be achieved, all PARTICIPANTS SHOULD accept the ruling of the entity who provided the current Element of Interest to the AREA. Security Considerations The protocol is totally insecure. It does not provide security for the PARTICIPANTS in any way. PARTICIPANTS should try to avoid security violations by handling the Element of Interest carefully and not misusing the failover mechanism. Also, PARTICIPANTS MAY implement sanity checks to make sure the Element of Interest stays the same during the protocol run. It is especially insecure to drive or operate heavy machinery during of after one or more JRP runs - even if a PARTICIPANT comes to the (wrong) conclusion it is perfectly OK to do so. Extensions In general, extensions to JRP are supported as long as all PARTICIPANTS would understand them. PARTICIPANTS MUST NOT use protocol extensions unknown to one or more PARTICIPANTS in this AREA. All PARTICIPANTS SHOULD announce the use of extensions (and their respective version number) to the AREA prior to using them. Although the protocol is designed to work via broadcast, special implementations may allow the use of underlying multicast protocols. The protocol itself does not support multicast since joining the AREA does not require any special action. If the underlying medium is a MCNB (Multicast capable/ non-broadcast) medium, any message MUST BE directed to all known PARTICIPANTS and MAY be directed to other entities not explicitly known as PARTICIPANTS so far. Multiple Elements of Interest Multiple Elements of Interest at a given time are supported. The only exception to a normal JRP run is the limitation that a CURRENT HOLDER (of which we now have more than one) MUST NOT issue request messages to another CURRENT HOLDER who just announced the availability of an Element of Interest. If there are as many Elements of Interest as there are PARTICIPANTS in the current AREA, JRP should not be used for the sake of effectiveness. Internationalization example To give an example of internationalization of JRP protocol messages, this section provides an official translation to German: English Message German Message "HERE WE GO" "Ich mach ma an" "PING" "PING" "PONG" "PONG" "Eeergh" "Ähhrg" "That's it" "Is tot" "OK, end" "OK, ich machs tot" "Oh my god" "Heilige Scheisse" "Oh well" "Na ja" "Who build this?" "Wer hat den scheiss gebaut?" "Shit" "Oh Scheisse" "Where is the beer?" "Hat's noch Bier?" "PONG,PONG,PONG" "PONG,PONG,PONG" "Here" "Heute!" "Back in a few" "Bin gleich wieder da" "Make one" "Bau ma" "Hey!" "Hey!" "Protocol violation" "Neee - falsch" Credits There are many people to thank here. As far as the author knows was the idea for this protocol first developed during the Chaos Camp in Germany organized by the Chaos Computer Club. For implementation ideas, features and especially extensive testing go special thanks to DirkB (who still refuses to choose a handle), Zet (for providing plenty of Elements of Interest for test purposes) and Marie-Luise, Nico, Brain and Voltage for general testing. $Id: jrp.txt,v 1.5 2002/01/30 11:44:31 fx Exp fx $