Transit Rider Protocols Working Group    J. Kaufman
Request for Comments                      June 2015
Category: Standards Track


     Subway Synchronization Protocol -- SSP 1.0
     ------------------------------------------

Status of this Memo

   This document specifies a standards track
   protocol for the Transit Rider community, and
   requests discussion and suggestions for
   improvements.  Please refer to the current
   edition of the "Transit Rider Official Protocol
   Standards" for the standardization state and
   status of this protocol.  Distribution of this
   memo is unlimited.

Abstract

   The Subway Synchronization Protocol (SSP) is a
   single-purpose stateful user-level protocol for
   distributed coordination among convergent
   parties of subway riders.

   SSP has been in daily use since 2014.  This
   specification defines the protocol referred to
   as "SSP 1.0".

Table of Contents

   1   Introduction ..............................2
   1.1    Purpose ................................2
   1.2    Requirements ...........................2
   1.3    Terminology ............................2
   1.4    Notation ...............................3
   1.5    Overall Operation ......................3
   2   Structure .................................4
   2.1    Notification ...........................4
   2.2    Acknowledgement ........................4
   2.3    Resending ..............................4
   2.4    Exceptions .............................4
   3   Notifications .............................4
   3.1    Carriage Designation ...................4
   3.2    Stop Arrival ...........................5
   4   Handling Notifications ....................5
   5   Merging ...................................5







J. Kaufman         Standards Track         [Page 1]
---------------------------------------------------

RFC    Subway Synchronization Protocol    June 2015


1 Introduction

1.1 Purpose

   The Subway Synchronization Protocol (SSP) is a
   single-purpose stateful user-level protocol for
   distributed coordination among parties
   attempting to converge on the same subway
   carriage.

1.2 Requirements

   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.

1.3 Terminology

   This specification uses a number of terms to
   refer to the roles played by participants in,
   and objects of, the SSP communication.

   party
      A group of one or more people traveling as a
      unit.

   communicator
      The member of a party responsible for
      inter-party communication.  The method of
      selection is left unspecified by SSP, but
      each party MUST have exactly one
      communicator.

   carriage
      A vehicle for the transportation of parties.

   station
      A place where parties may enter or exit a
      carriage.

   train
      An ordered series of carriages moving as a
      unit between stations.

   message
      A sequence of human-readable characters
      composed by a communicator.



J. Kaufman         Standards Track         [Page 2]
---------------------------------------------------

RFC    Subway Synchronization Protocol    June 2015


   initiator
      The communicator of the party that boards the
      train first.

   joiner
      The communicator of the party that attempts
      to, at a subsequent station, board the same
      train and carriage as the initiator.

   notification
      A message sent from the initiator to the
      joiner to assist the joiner in their task.

   acknowledgement
      A message sent from the joiner to the
      initiator confirming receipt.

1.4 Notation

   When referring to a message, the message
   contents are set off in square brackets.  For
   example, [example message].  The square brackets
   are notation only, and not part of the message.

1.5 Overall Operation

   The SSP protocol is a stateful protocol with a
   request-acknowledgement structure.  By sending a
   series of notifications an initiator can provide
   a joiner with sufficient information that the
   joiner can arrange for the parties to merge.

   Prior to use of SSP the communicators MUST have
   agreed through some out-of-band method on which
   stations the initiator and joiner will board the
   train.  These stations SHOULD have at least two
   other stations between them for reliable
   operation, and MUST have at least one.

   SSP communication usually takes place over Short
   Message Service (SMS), but other transports can
   be used.  The transport is not required to be
   reliable, but the correct operation of this
   protocol depends on low message loss and latency.








J. Kaufman         Standards Track         [Page 3]
---------------------------------------------------

RFC    Subway Synchronization Protocol    June 2015


2 Structure

2.1 Notification

   At several points described below, the initiator
   sends a message to the joiner indicating which
   point they have reached.  This message MUST be
   one of the standard statements described in
   Section 3.

2.2 Acknowledgement

   When the joiner receives a message from the
   initiator they MUST send back the message [OK]
   to indicate that they have received the message
   and are taking appropriate action.

2.3 Resending

   If the joiner sends a notification and does not
   receive an acknowledgement within 20 seconds,
   and has not already sent this notification three
   times, they MUST retransmit the notification.

2.4 Exceptions

   Failure to receive an acknowledgement after
   three transmissions of a notification, or
   receipt of any message that is invalid under SSP
   indicates an abort.  After an abort the
   communicator SHOULD interpret the triggering
   message and future messages, if any, using
   whatever protocol they would otherwise use for
   the underlying transport.

3 Notifications

3.1 Carriage Designation

   When boarding the train the initiator MUST
   choose either the initial or final carriage.
   Other carriages offer a risk of confusion that
   we consider excessive.  An initiator who has
   boarded the initial carriage SHALL transmit
   [First car], while one boarding the final
   carriage SHALL transmit [Last car].

   Note that this notification also serves to
   indicate departure from the initial station.



J. Kaufman         Standards Track         [Page 4]
---------------------------------------------------

RFC    Subway Synchronization Protocol    June 2015


3.2 Station Arrival

   Upon arriving at a station, the initiator MAY
   transmit the name of the station.  If the
   station immediately preceeds the agreed-on
   merger station they MUST send such notification.
   Sending notifications for the last two stations
   is RECOMMENDED.

   The station name MAY be abbreviated to a single
   letter in cases where this is not ambiguous.
   For example, upon arriving at Harvard station an
   initiator could send either [Harvard] or [H].

4 Handling Notifications

   On receieving each notification the joiner
   knows the position of the train and SHOULD
   estimate:

      - the time required for their party to travel
        to the agreed-on station

      - the time the train will take to travel from
        the next station at which notification is
        mandatory to the agreed-on station.

   If the second time is less than the first, the
   joiner SHOULD begin travel to the station.

4 Merging

   After the joiner and their party arrive at the
   agreed on station they SHOULD wait opposite
   either the initial or final carriage, as
   communicated in the carriage designation
   notification.  When each train arrives they
   SHOULD visually examine it for the initiator
   party, and board if and only if visual
   identification is successful.

   If the initiator arrives at the station and
   does not see the joiner, they SHOULD exit their
   carriage and wait opposite it until the joiner
   arrives.

   When the two parties have converged they merge
   to become a single party, the communicators lose
   their designated roles, and any future messages
   on the underlying transport SHOULD NOT be
   interpreted under SSP.




J. Kaufman         Standards Track         [Page 5]