1.  
2. Network Working Group                                    FX of Phenoelit
3. Request for Comments: XXXX                                     Phenoelit
4. Category: Informational                                     January 2002
5.  
6.                       Joint Routing Protocol
7.  
8. Status of this Memo
9.  
10.    This memo provides information for the Internet community.  This memo
11.    does not specify an Internet standard of any kind.  Distribution of
12.    this memo is unlimited.
13.  
14. Copyright Notice
15.  
16.    Copyright (C) Phenoelit Group - as long as someone still understands
17.    the meaning of copyrights at all after implementation and more or
18.    less extensive testing of this protocol and it's features.
19.  
20. Management Summary
21.    
22.    The Joint Routing Protocol is designed to make any given number of
23.    people look equally stupid using only one joint. It is basically
24.    an improved version of having any given number of people sit in
25.    a management meeting for approximately eight hours.
26.  
27. Application
28.  
29.    Although the protocol itself is not strictly limited to digital
30.    machines in general and the Internet in particular, it can be
31.    implemented for both. The main application of this protocol
32.    comes from the fact that the Internet community at large has a
33.    great need for this protocol to be standardized.
34.  
35. Introduction
36.  
37.    The Joint Routing Protocol (JRP) is designed to overcome problems
38.    arising during gatherings of more than one entity participating in
39.    the application of certain gifts of nature. These includes (but are
40.    not limited to) smoking of any kind of cigarette (better known as
41.    joint) that contains the substance known as THC.
42.  
43.    The goal is, for any given amount of entities to distribute the
44.    effects of the substance THC equally between all of them. Since
45.    physiological and technical conditions may vary significantly between
46.    different participating entities, a protocol for distribution is
47.    required.
48.  
49. Terms used
50.  
51.    The following terms are used throughout the protocol definition:
52.  
53.    Element of Interest (EoI)
54.       The device that contains the substance THC. It is assumed that
55.       every PARTICIPANT (see below) is able to apply this device to
56.       himself more or less effectively.
57.  
58.    CURRENT HOLDER (CH)
59.       The participating entity that currently possesses the element of
60.       interest.
61.  
62.    REQUESTOR (REQ)
63.       One or more participating entities that would like to become the
64.       CURRENT HOLDER.
65.  
66.    PARTICIPANT (PA)
67.       Any entity participating in the protocol communication and willing
68.       to become at least once a CH or REQ.
69.  
70.    AREA
71.       The AREA describes the protocol space of the underlying transport
72.       mechanism. This might be any media driven by electricity, light or
73.       sound. The default media is a gas consisting mainly of Oxygen,
74.       carbon dioxide and other parts that uses sonic transmission.
75.       The AREA MAY contain entities that are not PAs - these are ignored
76.       and will be automatically ignored if the JRP protocol run is
77.       successful.
78.  
79.    The terms MAY, SHOULD, SHOULD NOT, MUST and MUST NOT are used
80.    according to RFC 2119. The rest is pure bullshit.
81.  
82. States of processing - general overview
83.  
84.    The protocol's execution begins at the point where the Element of
85.    Interest (probably a joint) is engaged. This is usually the case if
86.    the element of interest is lit or set on fire in some other way that
87.    facilitates the effective application. Throwing the Element of
88.    Interest into a larger fire (such as a fireplace or tendril) is not
89.    considered a protocol execution start point but rather a protocol
90.    violation and a good reason to beat the shit out of the entity
91.    doing this.
92.    
93.    The protocols execution MAY end at various stages of processing.
94.  
95.    A complete JRP run is marked by the lifetime of the Element of
96.    Interest. If this lifetime ends (due to whatever reason), the
97.    protocol run is considered finished.
98.  
99.    During a protocol run, the general procedure is executed in a loop:
100.    The CURRENT HOLDER announces the availability of the Element of
101.    Interest using a broadcast message to the AREA. Any interested
102.    REQUESTOR then reacts to this announcement using a request
103.    message. The CURRENT HOLDER passes the Element of Interest to the
104.    first REQUESTOR who's message reached the central processing unit of
105.    the CURRENT HOLDER. This may be different from the REQUESTOR who
106.    actually send the request message first but is not considered a
107.    protocol violation itself - unless the ignored REQUESTOR is ignored
108.    several times (see Implementation below).
109.  
110.    In case the end of life for the Element of Interest is reached, the
111.    CURRENT HOLDER announces this using another broadcast message to the
112.    AREA.
113.  
114.    The ultimate goal is to reach JRP convergence. Convergence is reached
115.    if no PARTICIPANT is interested in becoming a REQUESTOR. This is the
116.    final state of the AREA and there should be no more JRP runs in this
117.    AREA after this state.
118.    An AREA (including all PARTICIPANTS) reaches convergence, if the
119.    last protocol run has come to a state where no JRP messages are
120.    transmitted anymore for a considerable long period of time. This can
121.    be the result of no messages of any kind transmitted or just no more
122.    potential REQUESTORS available. In case the Element of Interest is
123.    still available and has not yet reached it's end of life, the end of
124.    life is forced by the CURRENT HOLDER at this point. An optional JRP
125.    finish request can be used to validate this state (see
126.    Implementation).
127.  
128.    Various protocol features are defined to handle situations where the
129.    CURRENT HOLDER violates protocol timers or PARTICIPANTS violate the
130.    protocol. See the Implementation section for details.
131.  
132. General Implementation Notes
133.  
134.    Timing in this protocol is not very critical and does not require
135.    time synchronization of any kind between the PARTICIPANTS. This would
136.    be counterproductive anyway. Every entity is allowed to have it's own
137.    understanding of the time-space environment and scale. This is a
138.    desired effect of JRP. In case of huge discrepancies between the time
139.    scale of several PARTICIPANTS, a general friendly attitude towards
140.    the point of view of REQUESTORS SHOULD BE taken.
141.  
142.    Although the protocol is based on broadcast, the strength of the
143.    signal should be adjusted so that only the PARTICIPANTS in the AREA
144.    can receive the message. There is no need to waste bandwidth of a
145.    shared medium. The signal strength is not considered an element of
146.    decision for the CURRENT HOLDER while deciding which REQUESTOR will
147.    receive the Element of Interest next.
148.  
149.    Implementation messages highly depend on the medium the protocol is
150.    run over. This document assumes a clear text protocol - but the
151.    messages can be replaced by next to anything - as long as they stay
152.    unique. As long as a clear text protocol implementation seems
153.    feasible, it SHOULD BE implemented. The messages in this paper SHOULD
154.    be used unless there is a requirement for internationalization or
155.    numeric representation.
156.  
157. Implementation
158.  
159. I) Start Phase
160.  
161.    When starting a protocol run, the CURRENT HOLDER SHOULD take care
162.    that the Element of Interest is started in a way that makes it's life
163.    time as long as possible. The CURRENT HOLDER MAY choose to announce
164.    the protocol start by the JRP start message:
165.         "HERE WE GO"
166.  
167. II) Joining
168.  
169.    To become a PARTICIPANT, the entity is required to discover the
170.    availability of an Element of Interest. This is easily done if there
171.    is already a JRP run in progress. Joining an AREA as a PARTICIPANT is
172.    always possible. The newly joined PARTICIPANT SHOULD try to discover
173.    the state of the other PARTICIPANTS and the JRP run state. If the
174.    Element of Interest has nearly reached the end of life state, the new
175.    PARTICIPANT could as well look for the required requisites to create
176.    a new one rather then trying to join the current run. This makes
177.    everyone more happy.
178.    It is not required to announce the transition from an external entity
179.    to PARTICIPANT in any way.
180.  
181. III) Normal routing
182.  
183.    Normal routing occurs if the CURRENT HOLDER used the Element of
184.    Interest and wants to forward it to another PARTICIPANT. The CURRENT
185.    HOLDER SHOULD perform this step after one or two applications of the
186.    Element of Interest. In this case, the CURRENT HOLDER announces the
187.    availability using the JRP available message:
188.         "PING"
189.  
190.    Any PARTICIPANT that wants to become a REQUESTOR will then respond to
191.    this message by the appropriate JRP request message:
192.         "PONG"
193.  
194.    Note: Although it might appear as a valid response, the message "BONG"
195.          is not considered valid . It could be misinterpreted and is
196.          therefore a clear protocol violation. The CURRENT HOLDER
197.          MUST ignore REQUESTORS using different messages.
198.  
199.    After the REQUESTORS send their message one or more times to the
200.    AREA, the CURRENT HOLDER passes the Element of Interest to the
201.    REQUESTOR who's message first reached the central processing unit of
202.    the CURRENT HOLDER. This REQUESTOR becomes the CURRENT HOLDER.
203.  
204.    In case of no REQUESTORS answering to the JRP availability message,
205.    the CURRENT HOLDER MUST repeat the availability message at least
206.    three times. Then he MAY continue to apply the Element of Interest
207.    to himself. If he chooses to not proceed, the CURRENT HOLDER MUST
208.    transit the protocol into the forced end of life state.
209.  
210. IV) End of Life
211.  
212.    If the end of life for the Element of Interest is reached, the
213.    CURRENT HOLDER announces this with the JRE end of life message:
214.         "Eeergh"
215.    An alternative implementation of this message is supported:
216.         "That's it"
217.  
218. V) Forced End of Life
219.  
220.    If the CURRENT HOLDER did not receive any request messages following
221.    the availability message (see Normal Routing), he MAY choose to
222.    announce the forced end of life for the Element of Interest using the
223.    informal message:
224.         "OK, end"
225.  
226.    Following this optional message, the CURRENT HOLDER will force an end
227.    of life state to the Element of Interest and finish the JRP run.
228.  
229. VI) Status Messages
230.  
231.    Any CURRENT HOLDER MAY issue status messages to the AREA. These can
232.    be used to inform other PARTICIPANTS of the effectiveness of the
233.    current JRP run and therefore shorten the time to convergence. The
234.    supported status messages are listed below.
235.  
236.         "Oh my god"
237.            This message indicates that the Element of Interest is highly
238.            effective.
239.  
240.         "Oh well"
241.            This message indicates that the Element of Interest is not
242.            very effective.
243.  
244.         "Who build this?"
245.            This status message is a feedback provided to the entity that
246.            initially built the Element of Interest. The entity that
247.            builds the next one should consider doing it better since
248.            this status message normally hints at a bad implementation of
249.            the current one.
250.  
251.         "Shit"
252.            This message indicates that the CURRENT HOLDER will probably
253.            announce the availability of the Element of Interest shortly.
254.  
255.         "Where is the beer?"
256.            This request is a special message indicating that the CURRENT
257.            HOLDER will need an additional device containing some liquid
258.            (preferable beer) to complete his application. The
259.            PARTICIPANTS can now decide to offer such device to the
260.            CURRENT HOLDER and delay the next availability message a
261.            little or refuse to support him and hereby force an
262.            earlier availability.
263.  
264. VII) Failover Mechanism
265.  
266.    Since the protocol is designed to come to a halt in case of
267.    convergence, the PARTICIPANTS that did not reach convergence so far
268.    have to take care that the CURRENT HOLDER did not already reach it. If
269.    this is the case, the CURRENT HOLDER will not announce the
270.    availability of the Element of Interest to the AREA and therefore
271.    would break the JRP run.
272.    This condition does not require that the CURRENT HOLDER stopped to
273.    communicate completely. It might happen frequently that the CURRENT
274.    HOLDER has reached convergence and his JRP protocol stack simply does
275.    not require any more JRP communication.
276.  
277.    In the case of a not announcing CURRENT HOLDER, a forced passing of
278.    the Element of Interest is supported. A PARTICIPANT becomes a forcing
279.    REQUESTOR by issuing the JRP request message several times as unicast
280.    to the CURRENT HOLDER:
281.         "PONG,PONG,PONG"
282.  
283.    If the CURRENT HOLDER is for some reason unable to understand the
284.    request correctly or does no longer react to protocol messages at all
285.    (because of a faulty protocol stack implementation), the REQUESTOR is
286.    allowed to obtain the Element of Interest directly.
287.  
288.    This method SHOULD NOT be used unless the CURRENT HOLDER is not
289.    reacting in a timely fashion (see notes about timing).
290.  
291. VIII) Unsolicited Request
292.  
293.    During any time in the protocol run, a PARTICIPANT is allowed to
294.    advance his state to REQUESTOR. This can be done by issuing an
295.    informal message to the CURRENT HOLDER:
296.         "Here"
297.  
298.    The CURRENT HOLDER SHOULD cache this information and pass the Element
299.    of Interest to the early REQUESTOR in case of availability. The
300.    CURRENT HOLDER MAY run a normal routing step (JRP availability
301.    message) to validate that the early REQUESTOR has still interest in
302.    the Element of Interest.
303.  
304.    The unsolicited request SHOULD be used by PARTICIPANTS that got
305.    ignored several times during protocol steps although they reacted
306.    in a proper way.
307.  
308. IX) Leaving and Rejoining the AREA
309.  
310.    In case a PARTICIPANT needs to leave the AREA for some time, he
311.    SHOULD announce this using the JRP away message:
312.         "Back in a few"
313.    
314.    The PARTICIPANT MUST NOT expect to be part of the next routing steps.
315.    Rejoining the AREA is always possible due to the fact that there is
316.    no announcement message needed to inform other PARTICIPANTS.
317.  
318. X) Preventive Request for a new JRP run
319.  
320.    In case the Element of Interest might reach the end of life state
321.    frequently until convergence is reached, PARTICIPANTS MAY inform the
322.    AREA that a new Element of Interest is required shortly. Any
323.    PARTICIPANT MAY choose to send a message to the AREA or another
324.    PARTICIPANT:
325.         "Make one"
326.  
327.    The PARTICIPANT MUST NOT send this message as unicast to the CURRENT
328.    HOLDER, since he is probably busy performing the application of the
329.    currently used Element of Interest.
330.  
331. XI) Handling protocol violations
332.  
333.    If any PARTICIPANT violates the protocol, another PARTICIPANT MAY
334.    choose to inform the violator by sending the JRP protocol violation
335.    message:
336.         "Hey!"
337.    An alternative implementation is supported:
338.         "Protocol violation"
339.  
340.    This message might SHOULD include an extensive explanation of the
341.    violation spotted but has no effect on the state of the entity
342.    violating the protocol. In case there is a loop where multiple
343.    parties cannot agree on the correct implementation, one side can
344.    decide to dump core and leave the others the fuck alone. The
345.    PARTICIPANTS MAY as well choose to split the AREA in two AREAs and
346.    handling the protocol slightly differently for the sake of
347.    functionality until one party can prove their claim using this
348.    document. If none of this can be achieved, all PARTICIPANTS SHOULD
349.    accept the ruling of the entity who provided the current Element of
350.    Interest to the AREA.
351.  
352. Security Considerations
353.  
354.    The protocol is totally insecure. It does not provide security for
355.    the PARTICIPANTS in any way. PARTICIPANTS should try to avoid
356.    security violations by handling the Element of Interest carefully and
357.    not misusing the failover mechanism. Also, PARTICIPANTS MAY implement
358.    sanity checks to make sure the Element of Interest stays the same
359.    during the protocol run.
360.    It is especially insecure to drive or operate heavy machinery during of
361.    after one or more JRP runs - even if a PARTICIPANT comes to the
362.    (wrong) conclusion it is perfectly OK to do so.
363.  
364. Extensions
365.  
366.    In general, extensions to JRP are supported as long as all
367.    PARTICIPANTS would understand them. PARTICIPANTS MUST NOT use
368.    protocol extensions unknown to one or more PARTICIPANTS in this AREA.
369.    All PARTICIPANTS SHOULD announce the use of extensions (and their
370.    respective version number) to the AREA prior to using them.
371.  
372.    Although the protocol is designed to work via broadcast, special
373.    implementations may allow the use of underlying multicast protocols.
374.    The protocol itself does not support multicast since joining the AREA
375.    does not require any special action. If the underlying medium is a
376.    MCNB (Multicast capable/ non-broadcast) medium, any message MUST BE
377.    directed to all known PARTICIPANTS and MAY be directed to other
378.    entities not explicitly known as PARTICIPANTS so far.
379.  
380. Multiple Elements of Interest
381.  
382.    Multiple Elements of Interest at a given time are supported. The only
383.    exception to a normal JRP run is the limitation that a CURRENT
384.    HOLDER (of which we now have more than one) MUST NOT issue request
385.    messages to another CURRENT HOLDER who just announced the
386.    availability of an Element of Interest.
387.  
388.    If there are as many Elements of Interest as there are PARTICIPANTS
389.    in the current AREA, JRP should not be used for the sake of
390.    effectiveness.
391.  
392. Internationalization example
393.  
394.    To give an example of internationalization of JRP protocol messages,
395.    this section provides an official translation to German:
396.  
397.         English Message                 German Message
398.         "HERE WE GO"                    "Ich mach ma an"
399.         "PING"                          "PING"
400.         "PONG"                          "PONG"
401.         "Eeergh"                        "�hhrg"
402.         "That's it"                     "Is tot"
403.         "OK, end"                       "OK, ich machs tot"
404.         "Oh my god"                     "Heilige Scheisse"
405.         "Oh well"                       "Na ja"
406.         "Who build this?"               "Wer hat den scheiss gebaut?"
407.         "Shit"                          "Oh Scheisse"
408.         "Where is the beer?"            "Hat's noch Bier?"
409.         "PONG,PONG,PONG"                "PONG,PONG,PONG"
410.         "Here"                          "Heute!"
411.         "Back in a few"                 "Bin gleich wieder da"
412.         "Make one"                      "Bau ma"
413.         "Hey!"                          "Hey!"
414.         "Protocol violation"            "Neee - falsch"
415.  
416. Credits
417.    There are many people to thank here. As far as the author knows was
418.    the idea for this protocol first developed during the Chaos Camp in
419.    Germany organized by the Chaos Computer Club.
420.  
421.    For implementation ideas, features and especially extensive testing
422.    go special thanks to DirkB (who still refuses to choose a handle),
423.    Zet (for providing plenty of Elements of Interest for test purposes)
424.    and Marie-Luise, Nico, Brain and Voltage for general testing.
425.  
426. $Id: jrp.txt,v 1.5 2002/01/30 11:44:31 fx Exp fx $