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 $