GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:ien:ien119
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
                                IEN 119
   
   
               ST - A Proposed Internet Stream Protocol
   
                                  by
   
                            James W. Forgie
   
   
                      M. I. T. Lincoln Laboratory
   
                           7 September 1979
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   IEN 119                      ST.DOC              7 September 1979
   
   
   
   
   1.0  INTRODUCTION
   
           The internet stream protocol (ST) described in this
   document has been developed to support efficient delivery of
   streams of packets to either single or multiple destinations in
   applications requiring guaranteed data rates and controlled delay
   characteristics.  The principal applications with these
   requirements are point-to-point speech communication and voice
   conferencing.  While ST has been developed as a part of the ARPA
   Internet Program and has been formulated as an extension to the
   presently defined Internet Protocol (IP), it is not likely to
   find useful application in the current ARPA internet environment
   where the networks and gateways lack the capacity to handle
   significant speech communication.  Instead, ST is aimed at
   application in wideband networks, in particular those intended to
   carry a large fraction of packet voice in their traffic mixes.
   Work is currently underway on such networks both for local access
   and long haul use. These networks will serve as vehicles for
   research on techniques for flow and traffic control and as
   testbeds for evaluating the potential of packet technology for
   providing economical speech communication.  The design of the ST
   protocol represents a compromise among the sometimes conflicting
   requirements of compatibility with the existing IP and the
   gateways which handle it, the need for flexibility in supporting
   flow and traffic control research, and transmission efficiency.
   
           The concepts in this protocol originated in the
   deliberations of a working group consisting of Danny Cohen, Estil
   Hoversten, and the author.  They have been influenced by
   interactions with many other people.  In order to examine the
   cost and feasibility of the protocol, the author has fleshed out
   some aspects of the protocol in detail.  The other working group
   participants have not had an opportunity to approve or modify
   these detailed aspects of the protocol, and consequently all
   responsibility for them lies with the author.
   
           The state of the protocol is such that, while there are
   still details to be worked out, implementation could begin if the
   protocol were acceptable to those interested.
   
   
   
   
   
   
   
   
                                  -2-
   
   
   IEN 119                      ST.DOC              7 September 1979
   
   
   2.0  MOTIVATION AND GENERAL DESCRIPTION
   
           It is reasonable to ask why a new protocol is required to
   handle applications such as point-to-point speech and voice
   conferencing.  This section addresses that question and begins
   with a brief statement of the requirements for packet speech
   communication.  They are:
   
         1.  The network must be able to keep up with the data rate
             requirements of the speech terminal.  Because no bits
             need be transmitted during silent intervals, the
             average data rate for conversational speech can be
             expected to be between 40 and 50% of the peak data rate
             for commonly used constant-rate encoding techniques.
             Experimental variable-rate encoding techniques have
             exhibited higher peak-to-average ratios.  The network
             must be able to sustain the peak rate for the duration
             of talkspurt that can be as long as 20 seconds.
   
         2.  The stream of packets containing a talkspurt (a
             continuous segment of speech between silent intervals)
             must be delivered with a delay dispersion whose spread
             does not exceed some value that can be estimated with a
             high probability of success prior to the start of the
             talkspurt.  Since the individual packets of the spurt
             will experience different delays as they pass through
             the net, delay must be added at the receiver to allow
             continuous speech to be played out for the listener.
             It is necessary to predict the value of this smoothing
             delay before starting to play out the talkspurt.
             Packets that are delayed more than the predicted
             worst-case value will arrive too late to be used, and
             gaps will occur in the output speech.
   
         3.  Overall delay should be kept low.  If the overall
             round-trip delay is less than about l/4 second,
             conversations are carried out in a "normal" fashion
             with considerable feedback from "listener" to "talker"
             taking place.  When greater delay is experienced,
             people switch to a more formal mode in which feedback
             utterances are mostly suppressed, and the listener
             generally waits until the talker indicates that he has
             finished before saying anything.  User satisfaction
             declines with increasing delay, but systems remain
             usable for delays as long as several seconds.
   
         4.  The amount of speech for any one talker contained in a
             packet (the basic unit subject to transmission loss)
             should be kept small.  The loss of small (50 msec or
             less) chunks of speech produces a degradation of
             quality, but sentence intelligibility tends to be
   
   
                                  -3-
   
   
   IEN 119                      ST.DOC              7 September 1979
   
   
             preserved up to fairly high percentage losses.  Larger
             chunks of speech represent whole syllables or words,
             and their loss can change the meaning of sentences.
   
         5.  Listeners will tolerate some packet loss without
             downgrading the acceptability of the system, but the
             probability of loss due to either failed or late
             delivery must be kept in the order of 1% or less to be
             considered acceptable for everyday (non-crisis) use.
   
         6.  As a network approaches its load limit it should reject
             (or hold off) new offered load on a call basis not on
             an individual packet basis.  Continuing to accept new
             calls beyond capacity can result in unsatisfactory
             communication for many users.
   
         7.  If packet-switched speech transmission is to become
             economically competitive with circuit-switched
             transmission, a further requirement must be met.  The
             product of packet efficiency and average link
             utilization must equal or exceed the efficiency of
             circuit switching. That efficiency is defined as one
             minus the fraction of the time that silence occurs in
             conversational situations.  Estimates of this fraction
             for real-world conversations give values for efficiency
             between 40 and 50%.  We will use 45% as a convenient
             figure for comparative purposes.  Packet switching can
             easily take advantage of the silent intervals in a
             conversation by not transmitting packets, but that
             advantage may be lost through the combination of
             overhead bits in packet headers (packet efficiency) and
             the difficulty of operating communication links at high
             average utilization while keeping queueing delays
             within reasonable bounds.
   
           Conventional datagram networks are unsatisfactory for
   speech communication except under conditions of light overall
   load or where speech constitutes a small fraction of the overall
   load and can be given priority service.  The difficulty with
   datagram nets comes from their inability to provide the
   controlled delay and guaranteed data rate required for speech.
   Delay increases with offered load, slowly at light load, but
   dramatically as average load approaches capacity. Flow control
   strategies tend to be aimed at buffer management and fairness
   goals, both of which will operate to restrict the effective data
   rate available to an individual user as load increases.  Traffic
   control strategies are mainly concerned with congestion control
   and are primarily defensive, resulting in offered datagrams being
   held off or refused when difficulties are detected.
   Unfortunately for the speech user, by the time congestion is
   detected, it is already too late.  For satisfactory speech
   
   
                                  -4-
   
   
   IEN 119                      ST.DOC              7 September 1979
   
   
   service, congestion due to overload must be prevented.  Since a
   datagram net has no knowledge of the a priori requirements of
   users, it cannot develop traffic control strategies to meet these
   requirements.
   
           Another disadvantage of datagrams for speech is their
   packet efficiency.  The speech content of an individual user
   packet can be anything from 50 or so bits up to 1200 or 1300 bits
   depending upon the speech digitization technique in use.  The
   need to carry full source and destination addresses as well as
   other packet-handling information in each packet penalizes
   datagrams relative to other packet and circuit switching
   techniques.  In the internet case the penalty is worse since two
   sets of header information have to be carried.
   
           For example, IP datagrams on SATNET carrying 40-msec
   chunks of 16-kbps speech (a reasonaable chunk size and popular
   data rate) would have a packet efficiency of about 56% and would
   require utilization factors of about 80% to break even with
   respect to circuit switching. It is unlikely that delay
   characteristics would be satisfactory at this level of load.
   
           The goal of the ST design effort has been to attempt to
   overcome both of the difficulties associated with datagrams.  ST
   uses abbreviated internet headers and also allows speech from
   many talkers to be aggregated into single packets for
   transmission on wide-band networks where such aggregation is
   possible.  For the case of ST messages on a wide-band SATNET each
   carrying ten 40-msec chunks of 16-kbps speech for ten different
   talkers, packet efficiency would be about 86% allowing break-even
   link utilization to occur at 52%, a much more comfortable level
   for assuring desirable delay characteristics.
   
           Overcoming the inability of datagram nets to maintain
   data rates and delay characteristics as offered load increases is
   more difficult to achieve than improving packet efficiency.
   Circuit switching solves the problem by dedicating communication
   capacity to individual streams.  The goal of ST is to support
   traffic control policies that match stated user requirements to
   available resources taking into account the statistical
   properties of these requirements rather than the peak
   requirements used in circuit switching.  ST does not itself
   specify the traffic control algorithms to be used.  The
   development of such algorithms is an area of research that the
   protocol is intended to support.  Some algorithms may need only
   rough statistical knowledge of user requirements and network
   behavior.  Others may want more detailed knowledge and need to
   monitor the behavior of individual streams.  The protocol is
   intended to be general enough to support both extremes.  A
   successful traffic control algorithm would retain much of the
   statistical multiplexing advantages of datagram nets while at the
   
   
                                  -5-
   
   
   IEN 119                      ST.DOC              7 September 1979
   
   
   same time gaining much of the guaranteed data rate and controlled
   delay capabilities of circuit switched nets.  A packet net using
   ST also has the ability of a circuit switched network to deny
   access to, or negotiate lower rates with, users whose demands
   would exceed capability.
   
           The ST protocol requires users to state the data rate and
   delay requirements for a data stream before accepting any stream
   data.  These requirements are used by ST agents (host processes
   and gateways) to determine whether or not resources are available
   in the catenet to support the offered stream load.  The
   determination is based on knowledge of the stated requirements of
   other users, negotiation with networks such as SATNET which have
   built-in resource allocation mechanisms, and statistical load
   estimates of traffic on networks that lack such mechanisms. In
   order to accept the offered stream load, the cooperating agents
   must find a route through networks with sufficient uncommitted
   capacity to handle the new stream.  In the process of routing the
   stream, intermediate agents retain information about the stream.
   The existence of this information allows the use of abbreviated
   headers on stream data packets and the efficient distribution of
   the multi-addressed packets required for conferencing.
   
           The process used by ST agents in finding a route with
   sufficient capacity between source and destination is assumed to
   use a distributed routing algorithm to take advantage of the
   robustness and flexibility characteristic of distributed packet
   routing techniques.  In the simplest case, the result would be a
   fixed-path internet route (a fixed set of intermediate agents
   (gateways)) for the stream packets.  In the event of gateway or
   network failure, rerouting would be required.  This can be
   undertaken automatically, but success is not guaranteed, since
   loss of the failed element or elements is likely to result in
   inadequate capacity to carry the original load.  Fixed-path
   routing is not required by the protocol.  If desired, dynamic
   alternate routing of stream packets can be used at the discretion
   of individual agents, but gateway implementation and the routing
   process will be more complex if that option is chosen.  The
   protocol described in this document assumes fixed-path routing.
   
           The goal toward which the cooperating ST agents in a
   catenet work is the maintenance of a controlled delay, guaranteed
   data rate environment in which packet speech communications can
   take place in a satisfactory fashion.  Obviously, other non-
   cooperating users of the networks involved in the catenet can
   make it impossible to achieve that goal. Some independence of
   other users can be obtained in some networks such as SATNET by
   the use of dedicated resources.  Gateways can be programmed to
   throttle non-cooperating internet traffic.  To some extent,
   networks with poor delay characteristics can be avoided in the
   routing process.  Priority service can be used in some nets to
   
   
                                  -6-
   
   
   IEN 119                      ST.DOC              7 September 1979
   
   
   allow small quantities (proportionately) of ST traffic to be
   handled satisfactorily in spite of the activities of other users.
   However, the success of ST or any other approach to handling
   packet speech will require either the cooperation of all network
   users or the involvement of the networks themselves in providing
   the required controlled delay, guaranteed data rate services.
   
   3.0  RELATIONSHIP TO IP
   
           ST is intended to operate as an extension of the
   presently defined internet protocol (IP).  ST provides a
   different kind of service than the datagram service offered by
   IP.  ST must operate on the same level as IP in order to access
   local net resources such as SATNET streams and to be able to take
   advantage of any available local net multi-address delivery
   capabilities to support conferencing applications.  If an ST
   agent shares a local net port with an IP datagram handler, the
   two must cooperate in the use of the port to regulate traffic
   flow through the port.
   
           In order to get the advantage of abbreviated headers on
   stream packets, ST uses a different header format than that used
   for IP datagrams.  Packets with this format (see Section 5.0 for
   details) are called ST packets in this document.  They pass from
   one ST agent to another, and the abbreviated header information
   changes on a hop-to-hop basis.  However, ST packets cannot be
   transmitted until a route for the stream has been found and
   intermediate agents have built routing tables to translate the
   abbreviated headers.  Since end-to-end negotiation between ST
   users is often desirable before stream routing takes place, for
   example to agree on vocoder type and data rate, and it is
   convenient for a user to interface to only one protocol handler,
   ST provides a second type of service.  This service uses IP
   datagrams with an "ST" value in the IP Protocol Field.  These
   packets are called "IP.ST" packets.  They pass through datagram
   handlers in gateways and reach ST agents only at their
   destination hosts.
   
           A third type of packet is allowed by the protocol.  This
   type is realized by embedding an ST packet in an IP.ST packet.
   This method of sending an ST packet allows it to pass through
   gateways that do not support the ST protocol but do support IP
   datagrams.  Of course, the packet efficiency and traffic control
   benefits of ST are lost in such a case, but the use of this
   artifice could be justified on the grounds that any communication
   is better than none.
   
   
   
   
   
   
   
                                  -7-
   
   
   IEN 119                      ST.DOC              7 September 1979
   
   
   4.0  CONCEPTS
   
           The key concept in ST is that of a connection.
   Connections are supported by entities called agents which are
   made aware of the connection during a setup process that precedes
   use of the connection for data transfer.
   
   4.1  Agents
   
           There are four types of agents that may be involved in
   supporting ST connections.  They are:
   
   4.1.1  ST Hosts
   
           The users of connections are processes that run in host
   computers and communicate over connections through other
   processes or software modules that adhere to the ST protocol.
   Hosts having these processes or modules are called "ST hosts" (or
   "hosts," when the context permits).  ST hosts perform the
   functions of gateway halves in interacting with gateways for
   internet traffic.  ST hosts share the management of local net ST
   resources with the other agents on the local net and are capable
   of routing connections to other agents as may be required.  In
   networks with local multi-addressing capability, ST hosts make
   use of this capability in routing conference connections.  In
   networks lacking such capability, ST hosts may need to replicate
   messages for conference connections unless a special agent called
   a "replicator" is available in the local net.  In some local nets
   it may be desirable for hosts to forward traffic for conference
   connections.  The protocol allows but does not require the latter
   capability.
   
   4.1.2  ST Gateways
   
           ST gateways perform routing and forwarding functions very
   similar to those performed by IP gateways.  Unlike IP gateways,
   they store information about the connections they support and
   share the management of resources in the nets to which they are
   connected with the other agents in those nets. Like hosts, ST
   gateways may have to replicate packets for conference
   connections.
   
   4.1.3  Replicators
   
           In networks that lack multi-addressing or broadcast
   capability it may be desirable to provide special server hosts to
   handle the replication required for conferences.  Replicators are
   needed in situations where the load caused by replication would
   produce congestion at a gateway port.  Use of a replicator adds
   delay and is probably not warranted unless the number of copies
   needed in a particular net exceeds some threshold that depends
   
   
                                  -8-
   
   
   IEN 119                      ST.DOC              7 September 1979
   
   
   upon network port capacity. In worst-case situations a daisy-
   chain type of replication might be required because the peak rate
   could not be sustained at any network site.  The existence of a
   replicator does not eliminate the need for replication in hosts
   and gateways.  For example, a host in a conference with some
   participants on the same net but others on other nets may need to
   send packets to one or more gateways for speedy internet delivery
   as well as to a replicator for automatic distribution to other
   local net participants.
   
   4.1.4  Access Controllers
   
           The management of ST conference connections involves the
   services of an access controller.  The functions of an access
   controller are to control conference participation and provide a
   central source for information about the data rate requirements
   of a conference connection. Ideally, access control services
   would be provided by a set of hosts distributed throughout the
   catenet that shared information about the connections being
   controlled.  The addresses of these public access controllers
   would be known to all other agents, and a query to any one
   controller would provide information about any connection.  In
   the absence of public access controllers, the protocol allows any
   host to serve as a private access controller.  It is proposed to
   use a bit in the conference connection name to allow agents to
   determine whether a public or private access controller is
   responsible for a particular conference.  The name identifies the
   "owner" of the conference.  The owner is also the access
   controller in the private case.
   
   4.2  Connections
   
           Most applications for ST connections require full-duplex
   (bi-directional) communication between the parties in a point-
   to-point connection and omni-directional communication among the
   participants in a conference connection.  In the design of the
   protocol two different approaches to realizing the desired
   capability have been considered. The first, called the simplex
   approach, uses a combination of simplex (one-way) connections.
   For example, in the simplex approach the caller requests a
   simplex connection to the called party, who, after accepting the
   connection, requests another simplex connection for the return
   path to the caller.  In the second, called the full-duplex
   approach, the caller requests a full-duplex connection at the
   outset, and as soon as the called party has accepted the
   connection, data can flow in both directions.
   
           For conference connections, the simplex approach requires
   each participant to request a simplex connection to all the
   others.  The full-duplex approach requires that a participant
   request connection only to those that have not already requested
   
   
                                  -9-
   
   
   IEN 119                      ST.DOC              7 September 1979
   
   
   connection to him.
   
           Both approaches can provide workable bases for the
   required capabilities.  The pros and cons for both may be
   summarized as follows:
   
         1.  Simplex connections can take maximum advantage of
             available resources by using different routes for the
             forward and return paths.  The routing of a full-duplex
             connection is more likely to fail since a path with the
             desired capacity in both directions must be found.
             This advantage for simplex connections is most
             pronounced in networks where load is assymetrical, a
             situation to be expected in nets carrying relatively
             heavy data loads.
   
         2.  Full-duplex connections can, except perhaps under
             conditions of heavy load, be set up more rapidly and
             with less control message traffic. The difference is
             most pronounced for conference connections.  With
             full-duplex components of a conference connection, m-l
             connection requests are required for an m-participant
             conference, since each new participant must connect to
             all those already in the conference.  In the case of
             simplex components each new participant must also
             connect to all those already in the conference; but, in
             addition, those already in must connect to each
             newcomer.  This activity adds sigma (m-l) connection
             requests (and responses) to the setup procedure.
   
         3.  Simplex connections have an advantage in situations in
             which two parties attempt to call each other at the
             same time.  The two simplex connections can easily be
             combined into the required full-duplex connection. If
             the two parties start out with full-duplex connections,
             one of them must be refused or disconnected, a somewhat
             more complex task for the higher level protocol
             requesting the connection.
   
           This document proposes a full-duplex basis for ST
   connections because the author believes that the advantage of
   relative simplicity and efficiency in setting up conference
   connections outweighs the advantages of the simplex basis.  To
   allow connections with assymetrical flow requirements, the
   protocol allows users to specify different data rates in the two
   directions.
   
           Even though traffic can flow in both directions on an ST
   connection, the connection has an orientation, and packets are
   said to move in either the "forward" or "backward" direction
   depending on whether they are moving away from or toward the
   
   
                                 -10-
   
   
   IEN 119                      ST.DOC              7 September 1979
   
   
   originator of the connection.
   
           ST provides two types of connections:  Point-to-Point
   (PTP) and Conference (CONF).  PTP connections use different
   packet header formats and setup procedures to reduce overhead and
   allow faster setup for that more frequently used type.
   
   
   4.2.1  Point-to-Point (PTP) Connections
   
           PTP connections are set up in response to a CONNECT
   command from an originating process to an ST agent.  The CONNECT
   specifies the following:
   
         1.  The NAME of the connection.  The NAME is obtained by
             concatenating the ST address of the originating process
             (ORIGIN) with an arbitrary number.  The ST address is
             the internet host address (ala IP) concatenated with an
             "extension" field (32 bits) to specify a process in the
             host (a telephone for NVP applications).  It is the
             responsibility of the originating process to provide
             arbitrary numbers that keep the names of all
             outstanding connections unique.
   
         2.  The internet address of the process to which the
             connection is desired.  This address is called the
             "TARGET." The terms "ORIGIN" and "TARGET" are used
             instead of "SOURCE" and "DESTINATION" because the
             latter terms will be used to refer to the senders and
             receivers of packets travelling on the connection.
             Thus the ORIGIN process can be both SOURCE and a
             DESTINATION for packets on the full-duplex connection.
   
         3.  A flow specification (FLOW-SPEC) that tells ST agents
             about the desired characteristics of the connection.
             In addition to information about the data rate
             requirements for both directions of the full-duplex
             connection, the FLOW-SPEC has a PRECEDENCE value that
             agents can use as a basis for the preemption of this or
             other connections as part of the traffic control
             strategy.  The FLOW-SPEC is discussed in more detail in
             Section 4.5.
   
         4.  An arbitrary 16-bit number that the agent is to use to
             identify all ST packets that it will send to the
             originator on the connection (the backward direction).
             This identifier is called the "CID.B."  If the
             connection request is accepted, the originator will be
             given a CID.F to be used to identify all packets it
             sends in the forward direction on the connection.
             These CID's allow abbreviated headers to be used on ST
   
   
                                 -11-
   
   
   IEN 119                      ST.DOC              7 September 1979
   
   
             packets and provide a means for agents to rapidly
             locate the stored forwarding table involved in handling
             a received packet.  CID's are assigned by the agents
             receiving packets and need be only locally unique since
             they are reassigned on a hop-by-hop basis.  The CID to
             be used on the next hop is stored in the agent's
             forwarding table.
   
           During the setup procedure the CONNECT command propagates
   from agent to agent until it reaches the TARGET process.  This
   propagation differs from ordinary packet forwarding in that the
   intermediate agents inspect the command, take appropriate action,
   and retain information about the requested connection.  If the
   TARGET process agrees to the connection, it sends an ACCEPT
   command that is propagated back through the same intermediate
   agents that handled the CONNECT.  The agents take appropriate
   action as they process the ACCEPT.  If the TARGET process is not
   willing to accept the connection, it issues a REFUSE command
   which propagates back in the same fashion as the ACCEPT.
   REFUSE's are generated by intermediate agents if they find
   themselves unable to support a requested connection. An agent
   receiving such a REFUSE tries alternate routes and passes the
   REFUSE back another hop only when it has exhausted its routing
   alternatives. Appropriate REASON codes are included in the REFUSE
   commands.
   
           After a connection has become established (an ACCEPT has
   reached the ORIGIN), changes to the FLOW-SPEC can be accomplished
   by the ORIGIN issuing a new CONNECT or the TARGET issuing a new
   ACCEPT command.  (Actually, the TARGET can issue a new ACCEPT at
   any time after issuing the first ACCEPT, and it can also at that
   time begin sending packets on the connection although there is
   some hazard in doing so since they may pass the ACCEPT enroute
   and be discarded.)  For the case where the FLOW-SPEC calls for a
   connection whose rate can be varied at the discretion of the
   catenet, intermediate agents issue CONNECT's and ACCEPT's to
   inform other agents and the end users about rate changes.  These
   commands are marked to distinguish them from end user commands.
   
           The ACCEPT command contains the same kinds of information
   as the CONNECT except that the backward connection identifier
   (CID.B) is replaced by a forward identifier (CID.F).  In
   addition, the FLOW-SPEC will generally be different and will
   indicate the data rates and delay characteristics accepted by the
   agents.  The CONNECT that arrives at the TARGET will be similarly
   modified from the CONNECT that was issued by the ORIGIN and will
   match the ACCEPT received by the ORIGIN.  See Section 4.5 for a
   discussion of the changes that can occur to the FLOW-SPEC.
   
   
   
   
   
                                 -12-
   
   
   IEN 119                      ST.DOC              7 September 1979
   
   
   4.2.2  Conference (CONF) Connections
   
           The type of connection required for voice conferencing is
   one in which any participant can send messages to all the others.
   Connections of this type have been called "omniplex" connections.
   ST realizes a conference connection by means of a superposition
   of tree-like components that start from an origin process (the
   root) and extend to a set of targets (the leaves).  The set of
   participants in a conference is represented by a bit map.  Each
   participant has a location in the conference bit map that is
   assigned by the access controller (AC).  When a conference
   CONNECT command is given, a TARGET-BIT-MAP (TBM) is used to
   specify the set of targets to which connection is requested.  The
   TBM is supplied by the AC when a participant joins a conference.
   The tree-like components all have the same NAME, and intermediate
   agents combine branches from the components whenever possible to
   minimize resources committed to the conference.  Because of this
   combining, an ORIGIN-BIT-MAP (OBM) is needed to represent the set
   of originators that have requested connection to a particular
   participant.
   
           The list of participating processes in a CONF connection
   is not carried in the CONNECT request but is is maintained by the
   AC and provided to agents and participants when needed.  Another
   function of the AC is to provide the FLOW-SPEC for the connection
   to any agent on request.  The reason for assigning these tasks to
   an access controller is to prevent unauthorized connection to a
   conference and to assure that all components of the connection
   use the same FLOW-SPEC.
   
           The first step in establishing a conference is to install
   a list of participants and a FLOW-SPEC in an AC.  The list of
   participants may be fixed at the outset or be allowed to grow
   during the course of the conference.  A participant may depart
   from a conference, but his position in the list and the bit maps
   is not reused.  The method by which the list of participants is
   made known to the AC is not of concern to ST itself and is not
   specified in this document.  Higher level protocols such as a
   network voice protocol (NVP) engage in communications between
   participant processes and the AC in the process of setting up a
   conference.  For example, an NVP issues a JOIN  command to
   request access to a conference.  If the NVP process is on the
   participant list or is otherwise acceptable, the AC responds with
   a WELCOME command that among other things tells the participating
   NVP its location in the CONF bit map.  The NVP then sends TELL-ME
   messages to the AC to obtain the participant list and FLOW-SPEC
   for the CONF connection.  This information is provided in INFO
   messages from the AC.  Several of these messages may be required
   to transmit all the information about a large conference.  The
   messages exchanged between participants and the AC are IP.ST
   datagrams.  They cannot be ST packets because no ST connection
   
   
                                 -13-
   
   
   IEN 119                      ST.DOC              7 September 1979
   
   
   exists between the participants and the AC.
   
           Once a participant has received a WELCOME message from
   the AC, it can issue a CONNECT.CONF command to its ST host agent.
   It uses a TARGET-BIT-MAP (TBM) that it received as part of the
   data in the WELCOME message.  This TBM has bits set for all the
   previous joiners of the conference.  The CONNECT.CONF will thus
   attempt to establish a full-duplex path to each of the previous
   joiners.  These paths will make use of common links where
   possible and will result in a connection resembling a tree rooted
   at the site of the process originating the connection.  When the
   CONNECT.CONF is issued by the originator it contains an ORIGIN-
   BIT-MAP (OBM) with a single bit set corresponding to the
   originating participant.  If the CONNECT.CONF is successful
   (i.e., some subset of the targets are reached), an ACCEPT.CONF
   will be returned with bits set in the TBM indicating the
   participants to which connection has been achieved.  In a CONF
   connection attempt, success may not be achieved with the entire
   set of targets specified by TBM.  Some may be unreachable for any
   of a number of reasons.  REFUSE.CONF messages will be returned
   for all such failures with bits in the TBM identifying the
   unreachable participants.  If the failures in a particular
   attempt are due to more than one REASON, at least one REFUSE.CONF
   will be returned for each reason.
   
   
           The technique for setting up conference connections
   proposed for ST results in each participant actively connecting
   to some subset of the others while accepting connections from the
   rest.  The first participant does not issue a CONNECT and accepts
   all the others.  The last connects to all the others and accepts
   none.  Each participant can maintain up-to-date information about
   participation in the conference by utilizing the information in
   the CONNECT and ACCEPT messages it receives.
   
   
           The CONNECT.CONF messages received by agents during the
   setup procedure do not contain information about the identity of
   the participants.  In order to route the connection, the agents
   must acquire this information, and they do so by sending TELL-ME
   messages to the AC and getting INFO messages in response.  They
   need to retain this information only during the routing phase of
   connection setup.  Once the connection is established, bit map
   information in forwarding tables combined with a FORWARDING-BIT-
   MAP (FBM) in the ST packet is sufficient to handle the forwarding
   of packets on the connection.  The FBM is used to specify the set
   of destinations for the packet.  Thus a packet can be sent to all
   or any subset of the connection participants. The source of the
   packet is identified by a number representing the position of the
   source participant in the conference bit map.
   
   
   
                                 -14-
   
   
   IEN 119                      ST.DOC              7 September 1979
   
   
           In the case of a voice conference, no useful purpose is
   accomplished when many people speak at the same time.  It is
   expected that a higher level protocol (part of NVP) would
   regulate the activity of the conference and would normally allow
   one or perhaps two persons to transmit speech at the same time.
   ST is not involved in this aspect of conference control except to
   the extent that if there are too many simultaneous talkers, the
   traffic-handling capability of the connection could be exceeded,
   and ST might discard some of the packets.  The higher level
   control protocol should set the FLOW-SPEC for the connection to
   accommodate the expected traffic flow.  Thus, for a simple one-
   at-a-time conference, ST would be asked for a data rate
   corresponding to a single speech stream.
   
           The above discussion has described a connection
   arrangement suitable for supporting voice conferences in which
   any participant can transmit and be heard by all others.  ST also
   provides another kind of multi-address message delivery
   capability.  If only one participant issues a CONNECT.CONF
   command with a TBM specifying connection to all the others, a
   tree-like connection will be set up that allows the ORIGIN to
   send packets to all the others and receive from any of the
   others, but packets sent by the others will be received only by
   the ORIGIN.
   
   4.2.3  Taking Connections Down
   
           The process of taking a connection down is initiated
   either by an ORIGIN issuing a DISCONNECT message or a TARGET
   issuing a REFUSE. These messages propagate from agent to agent
   along the connection path so that intermediate agents can take
   appropriate action to clean up their stored information about the
   connection.
   
           Connections can also be taken down as a result of
   intermediate agents detecting a faulty link or gateway or
   deciding to preempt the connection.  In this case the agent or
   agents involved issue a DISCONNECT/ REFUSE pair that propagate in
   the appropriate directions.  A REASON code in the messages
   informs the users as to the cause of the disconnection.
   
           In the case of conference connections, bit maps allow
   selective disconnection and refusal.
   
   4.3  Types of Service
   
           ST offers two types of service for packets travelling on
   connections.  Neither type has any delivery guarantees, i.e.,
   there are no acknowledgements or retransmissions on either a
   hop-by-hop or an end-to-end basis.  Neither type guarantees
   packet integrity; i.e., if local nets offer a type of service
   
   
                                 -15-
   
   
   IEN 119                      ST.DOC              7 September 1979
   
   
   that can deliver packets with bits in error, ST may use that type
   of service.  The headers of ST packets are sum-checked by ST
   agents, but the data portions are not.
   
           The two types of service differ in whether or not they
   use the channel capacity nominally allocated to the connection
   and also in the strategy used by intermediate agents in buffering
   them.  The two types are:
   
         1.  Stream Packets (called ST.ST packets).  These packets
             use the allocated resources and are buffered for a
             short time only, since they are intended for
             applications such as speech communication where a late
             packet is not worth delivering.  They are discarded by
             intermediate agents if queue conditions indicate that
             they cannot be delivered in a timely fashion.
   
         2.  Datagrams (called ST.DG packets).  These packets have
             the same form as ST.ST packets except for a flag bit in
             the header and travel over the same connection path.
             They use allocated resources only when spare capacity
             exists, e.g., when the ST.ST flow drops below the
             allocated value.  Otherwise they share local net
             resources with other IP datagram traffic.  They are
             buffered with a queueing strategy appropriate for
             datagram traffic and are discarded only when agent
             buffer resources approach exhaustion.  They are
             intended for use by higher level protocols such as NVP
             in applications such as dynamic control of the "floor"
             in a conference.  They are also used by ST itself for
             connection management.
   
   4.4  Packet Aggregation
   
           ST allows any ST packets, stream or datagram, to be
   aggregated together that have the same next-agent local-net
   destination.  "Aggregation" is a form of multiplexing, but is
   given a different name to distinguish it from the multiplexing
   done in the IP Multiplexing protocol that allows multiplexing
   only for packets with the same end-to-end source and destination.
   The term "envelope" is used to refer to any ST message sent from
   one agent to another.  An envelope may contain one or more ST
   packets and is limited in size by the maximum size of packet that
   the local net can carry.  The envelope has a short header in
   addition to the header of the individual aggregated packets.  See
   Section 5.0 for a description of header formats.
   
           The ST aggregation technique requires agents to look
   inside of received envelopes and handle the packets as individual
   entities.  This procedure adds to the computing load of gateways,
   but can achieve significant communication savings in networks
   
   
                                 -16-
   
   
   IEN 119                      ST.DOC              7 September 1979
   
   
   with high per-packet overhead such as SATNET, particularly when
   many short packets must be handled.
   
   4.5  Flow Specifications
   
           The FLOW-SPEC that is carried by CONNECT and ACCEPT
   messages contains several fields.  Some are specified by the
   originator of the CONNECT.  Others are produced either during the
   process of setting up the connection or changing its allowed flow
   characteristics.  Some apply in common to both directions of the
   full-duplex connection.  Others apply individually to allow
   different flows in the two directions and appear in pairs in the
   control messages.
   
           Data rate, the basic quantity used in traffic control
   computations, is specified by means of three parameters; a stream
   interval (SI), a packet length (PL), and a duty factor (DF).  The
   average expected data rate can be computed by taking the product
   of PL, DF, and the reciprocol of SI.  The FLOW SPEC allows for
   one value each for SI and DF for each direction.  However, as
   many as four values of PL can be provided as options, allowing
   the ST agents flexibility in allocating resources for some types
   of traffic flow.
   
           The flow type (TYPE) parameter is intended to allow ST to
   take into account a variety of different user load
   characteristics.  The set of possible types can be expected to
   grow with experience, but a relatively few types seem to be
   adequate to deal with presently contemplated voice encoding
   techniques.  These are:
   
         1.  Fixed Rate.  The data rate is held fixed for the life
             of the connection.  A simple speech encoder that can
             run at only one rate would use this type value with all
             four PL's set to the same value.  A somewhat more
             complex encoder that could run at more than one rate
             but could not change rates on the fly would use the
             fixed-rate type but could offer a choice of up to four
             values for PL.  A variable-rate vocoder such as the
             LPC2 vocoder used in the ARPANET that has a rate that
             varies depending on the short time behavior of the
             speech signal would also use the fixed-rate type but
             would set the duty factor to a lower value than the 0.5
             or so used by a simple encoder.
   
         2.  Multiple Rate.  The data rate allowed can be of any of
             the four specified by the four PL's and the agents are
             free to change rates at any time to accommodate to
             network load changes.  Whenever an agent changes the
             rate, it sends appropriate CONNECT and ACCEPT messages
             to tell other agents and the users about the change.
   
   
                                 -17-
   
   
   IEN 119                      ST.DOC              7 September 1979
   
   
             Since such rate changes require extra communication and
             processing in the catenet, agents would have to avoid
             frequent changes.  This flow type would be used by
             enoders that run at a variety of rates and can switch
             rates rapidly but need to do so explicitly either
             because packet formats must change with rate changes or
             because some parameter such as sampling rate must be
             changed at sender and receiver.  This flow type could
             also be useful for sending data rather than voice over
             ST connections.
   
         3.  Prioritized Variable Rate.  This flow type is intended
             for use by certain advanced encoders of a kind called
             "embedded" where subsets of the coded bit stream can be
             stripped en route without loss of intelligibility.
             There is, of course, some loss of quality and/or
             ability to withstand acoustical background noise when
             stripping occurs.  For this flow type each of the four
             PL's corresponds to one of the four packet priorities
             that can be attached to ST.ST packets.  The encoder
             would place the bits needed for its lowest rate in the
             highest priority packet, the next lowest in the second
             highest, etc.  When pressed for channel capacity,
             agents would be free to discard the lower priority
             packets for this flow type.  The overall precedence of
             the connection would also affect the probability of
             packet discard.  It is not anticipated that agents
             would send explicit messages to announce that
             discarding was taking place.
   
           Another set of parameters in the FLOW-SPEC is concerned
   with transmission delay.  ST does not allow the user to specify a
   delay requirement, but it does allow some control over the
   tradeoff between delay and data rate options during the routing
   process.  A ROUTING-STRATEGY parameter is provided for this
   purpose.  Currently, two strategy options for PTP connections are
   envisioned, but others could be added if desired.  One gives
   preference to minimizing delay at the expense of data rate.  The
   other gives preference to data rate over delay.  The ROUTING-
   STRATEGY options are meaningful only when data rate options are
   available.  Otherwise data rate is as absolute requirement in
   routing.
   
           While a user cannot specify a delay requirement to ST, ST
   does provide the user with an estimate of both minimum delay and
   delay dispersion in fields of the FLOW-SPEC.  The estimates are
   based on a priori statistics relating delays to average network
   loads.  When an agent propagates a CONNECT packet, it adds values
   from tables indexed on the current load estimate to the MIN-DELAY
   and DISPERSION fields of the FLOW-SPEC for the forward direction.
   It performs the same function for the backward direction as it
   
   
                                 -18-
   
   
   IEN 119                      ST.DOC              7 September 1979
   
   
   propagates the ACCEPT.  The MIN-DELAY is the simple sum of the
   hop-to-hop contributions, but the DISPERSION is a sum of squares.
   The receiver can compute an estimate of overall delay by adding
   the MIN-DELAY to the square root of the DISPERSION.  The
   DISPERSION estimate by itself can be useful in setting the
   reconstitution delay value needed to play out satisfactory speech
   for listeners.  The proper value can vary over a wide range
   depending on the path through a catenet of networks with very
   different delay characteristics.
   
           Another parameter set by agents during the routing
   process is the ACCEPTED-RATE field.  This field informs the users
   as to which of the four possible data rate options (PL's) have
   been accepted for each of the two directions of the connection.
   Of course, if none were acceptable, a REFUSE would be returned
   with a REASON code indicating unavailability of resources at the
   requested precedence level.  Another flow-related reason for
   refusal could be an inability of the networks to handle a too-
   short stream interval.
   
           All FLOW-SPEC parameters except PRECEDENCE and ROUTING-
   STRATEGY can be independently specified or are reported
   separately for each of the two directions of the full-duplex
   connection.  The exceptions are required to apply to the entire
   connection to simplify the task of gateways in handling
   connections.
   
           The ROUTING-STRATEGY field has other control functions in
   addition to weighting the tradeoff between data rate and delay.
   For CONF connections it indicates whether or not data rate
   options must match in both directions (a requirement for voice
   conferencing) or can be negotiated independently.  If ST agents
   support split routing, (a capability to divide the traffic on a
   connection among two or more paths) the ROUTING-STRATEGY field
   will indicate whether or not this technique is to be applied to
   the connection. Split routing also requires additional fields to
   indicate the fraction of the nominal traffic that has been
   accepted or is requested to be handled. This document does not
   propose the implementations of split routing in the first version
   of ST.
   
   
   
   
   
   
   
   
   
   
   
   
   
                                 -19-
   
   
   IEN 119                      ST.DOC              7 September 1979
   
   
   5.0  PACKET FORMATS
   
           The messages sent between ST agents on connections are
   envelopes containing one or more ST packets.  The envelope
   consists of an envelope header (EH) followed by one or more
   packet headers (PH's) followed by the data portions of the
   packets in the same order.  The envelope thus has the form:
   
           EH, PH1, PH2, . . .PHn, DATA1, DATA2, . . . DATAn
   
   The reason for aggregating the headers separately from the data
   is that doing so allows the header region to be checksummed
   easily as a unit before attempting to parse the envelope.  It is
   expected that ST will be used in networks that can deliver
   messages with bits in error and that some non-negligible fraction
   of the messages will have such errors.  To require the entire
   envelope to be error-free in order to use any of it would result
   in an excessive rate of lost packets.
   
           Since ST operates as an extension of IP, the envelope
   arrives at the same network port that IP uses to receive IP
   datagrams.  It is proposed to use a unique code in the first
   field of the message to identify it as an ST envelope.  The first
   four bits of an IP datagram are defined to be the Version Number
   field.  It is therefore proposed to use one of the 16 possible IP
   versions to distinguish ST envelopes from IP datagrams.  With
   this convention an envelope header will have the following
   format:
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
                                 -20-
   
   
   IEN 119                      ST.DOC              7 September 1979
   
   
                          ENVELOPE HEADER
   
                    0                   1
                    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   !  ST   !VERSION! HEADER-LENGTH !
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   !          TOTAL-LENGTH         !
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   !             CKSUM             !
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
             ST is the particular IP Version Number assigned to
             identify ST envelopes.
   
             VERSION is the ST version number.  This document is a
             proposal for VERSION 1.
   
             HEADER-LENGTH* is the length in words of the envelope
             header (3) plus the sum of the header lengths of the
             aggregated packets.
   
             TOTAL-LENGTH is the length of the entire envelope.  It
             does not include any local net headers or trailers.
   
             CKSUM covers the envelope header and all packet
             headers.
   
   ++++++++++++++
   *All ST communications use the 16-bit word as a basic unit.  All
   lengths are in word units.
   ++++++++++++++
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
                                 -21-
   
   
   IEN 119                      ST.DOC              7 September 1979
   
   
           The individual packet headers have one of two formats
   depending on whether they are for PTP or CONF connections.  These
   formats are:
   
                         PTP PACKET HEADER
   
                    0                   1
                    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   !              CID              !
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   !0!     BITS    !  DATA-LENGTH  !
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
                         CONF PACKET HEADER
   
                    0                   1
                    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   !              CID              !
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   !1!     BITS    !  DATA-LENGTH  !
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   !  Spare  ! FBML! !    SID      !
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   !        FBM - 1st word         !
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                  .
                                  .
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   !        FBM - nth word         !
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
             CID is an arbitrary identifier assigned by the agent
             receiving the packet for the purpose of identifying the
             connection on which the packet is travelling.  Since
             the CID is unique only to the agent that assigned it,
             it will generally have a different value on each hop of
             the connection path.
   
             BITS are defined as follows:
               Bit 1 distinguishes stream packets (ST.ST) from
               datagrams (ST.DG) (1 = DG).
   
               Bits 2 and 3 define the packet priority (00 = highest
               priority).
   
               Bits 4 and 5 are spares.
   
               Bits 6 and 7 are unused (may be used by higher level
               protocols if desired).
   
   
                                 -22-
   
   
   IEN 119                      ST.DOC              7 September 1979
   
   
             DATA-LENGTH is the length of the data field in words.
   
             FBML (3 bits) is one less than the length of the
             Forwarding Bit Map (FBM) in words.
   
             SID (7 bits) identifies the source of the packet on a
             CONF connection (the source is implicit for a PTP
             connection packet).  The value of SID corresponds to
             the bit position of the source in the conference bit
             map.  Bit numbers start with zero, and positions start
             with the left-most (most significant) bit of the first
             word of the bit map.
   
             FBM is the Forwarding Bit Map.  It can be at most 128
             bits (8 words) long, and thus it limits conferences to
             128 participants (a generous number).  Ones in the FBM
             indicate that the packet is to be delivered to the
             corresponding participants.  The FBM is allowed to
             increase in one word increments to allow new
             participants to enter during the course of a
             conference, but it does not shrink when participants
             leave, and bit positions are not reused.
   
           As pointed out in Section 3.0, ST supports a second type
   of communication called IP.ST datagrams.  These are ordinary IP
   datagrams with an "ST" value in the protocol field.  They are
   used to allow higher level protocols to communicate prior to the
   setting up of an ST connection, and they are also used for
   communication between access controllers and other ST agents
   during the setup of CONF connections.  They are strictly point-
   to-point communications since they are IP datagrams.  According
   to the conventions for IP datagrams, these messages would have
   the form:
   
           IP Header, IP.ST Header, Data
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
                                 -23-
   
   
   IEN 119                      ST.DOC              7 September 1979
   
   
           The IP.ST Header has the following form:
   
                        IP.ST PACKET HEADER
   
                    0                   1
                    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   ! IP.ST !VERSION!    LENGTH     !
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   !            SOURCE-            !
                   +-+-+                       +-+-+
                   !           EXTENSION           !
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   !          DESTINATION-         !
                   +-+-+                       +-+-+
                   !           EXTENSION           !
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
   
             IP.ST is a value chosen to be different from the "ST"
             value used in the first four bits of the ST envelope.
             This field allows IP.ST datagrams to be distinguished
             from ST envelopes embedded in IP.ST packets, a
             technique that can be used to get ST envelopes through
             gateways that do not support ST.
   
             VERSION is the ST version number.
   
             LENGTH is the total length of the IP.ST packet
             excluding IP and local net headers, etc.
   
             SOURCE- and DESTINATION-EXTENSION's are 32-bit fields
             used to identify the source and destination processes.
             Like ARPANET NCP process identifiers, they are not
             specified by the protocol.  The source and destination
             host addresses are carried in the IP header.
   
   
   6.0  CONTROL MESSAGES
   
           With the exception of communications with access
   controllers, ST control messages are sent from agent to agent as
   ST.DG packets with the CID set to zero.  This convention is
   similar to the ARPANET NCP use of Link 0 for control.
   Communication with AC's uses IP.ST packets.  The form is
   otherwise the same.  The control protocol follows a request-
   response model with all requests expecting responses and all
   responses expecting acknowledgements.  Retransmission after
   timeout is used to allow for lost or ignored messages.  A packet
   may contain more than one control message.  Control messages do
   not extend across packet boundaries.
   
   
                                 -24-
   
   
   IEN 119                      ST.DOC              7 September 1979
   
   
           Control message headers have the following format:
   
                       CONTROL MESSAGE FORMAT
   
                    0                   1
                    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   !    OP-CODE    !    LENGTH     !
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   !             CKSUM             !
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   !           REFERENCE           !
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
             OP-CODE specifies the request or response.
   
             LENGTH is the length of the control message in words.
   
             CKSUM is the checksum of the control message.  Because
             the control messages travel in envelopes that may be
             delivered with bits in error, each control message must
             be checked before it is acted upon.
   
             REFERENCE is an arbitrary reference number used to
             associate requests with responses and acknowledgements.
   
           The header is followed by parameters as required for the
   particular OP-CODE.  Each parameter is identified with a P-CODE
   byte that is followed by a P-LENGTH byte indicating the length of
   the parameter (including the P-CODE, P-LENGTH word) in words.
   Parameters can be sent in any order. The format of individual
   parameters is specified in the following sections in connection
   with the OP-CODE's with which they are used.
   
           Control messages fall into two categories according to
   whether they deal with PTP or CONF connections.  There are four
   messages that are independent of connection type.  These are:
   
   6.0.1  [ACK]
   
           ACK (OP-CODE = 1) has no parameters.  The REFERENCE in
   the header is the REFERENCE number of the message being
   acknowledged.  ACK's are used to acknowledge responses to
   requests and in some cases constitute responses or partial
   responses themselves.
   
   
   
   
   
   
   
   
                                 -25-
   
   
   IEN 119                      ST.DOC              7 September 1979
   
   
   6.0.2  [HELLO]
   
           HELLO (OP-CODE = 2) is used to determine whether or not
   another agent is alive and well.  It has no parameters and
   expects an ACK in response.
   
   6.0.3  [ERROR-IN-REQUEST] <REF> <ERROR-TYPE>
   
           ERROR-IN-REQUEST (OP-CODE = 3) is sent in response to a
   request in which an error is detected.  An ACK is expected.  No
   action is taken on the erroneous request.
   
             REF (P-CODE = 7, P-LENGTH = 2) is the REFERENCE number
             of the erroneous request.
   
             ERROR-TYPE is not yet specified.
   
   6.0.4  [ERROR-IN-RESPONSE] <REF> <ERROR-TYPE>
   
           This message (OP-CODE = 4) is sent in lieu of an ACK for
   a response in which an error is detected.  No ACK is expected.
   Action taken by the requester and responder will vary with the
   nature of the request.
   
             REF identifies the erroneous response.
   
             ERROR-TYPE is not yet specified.
   
   
   6.1  Control Messages for PTP Connections
   
           PTP connections are set up and taken down with the
   following messages:
   
   6.1.1  [CONNECT.PTP] <NAME> <TARGET> <FLOW-SPEC> <CID.B>
   
           CONNECT.PTP (OP-CODE = 5) requests the set up (routing)
   of a PTP connection or asks for a change in the flow
   specification of a connection already routed.  Its parameters
   are:
   
             NAME (P-CODE = 1, P-LENGTH = 6) is the ST address of
             the process that originated the CONNECT.PTP (the
             ORIGIN) concatenated with a 16-bit number chosen to
             make the name unique.  An ST address is a 32-bit IP
             host address concatenated with a 32-bit EXTENSION
             identifier chosen to identify a particular process in
             the host.  The EXTENSION is provided by some higher-
             level protocol and is assumed by ST to be unique to the
             host.  For NVP use the EXTENSION identifies a
             particular telephone and is presumably a well-known
   
   
                                 -26-
   
   
   IEN 119                      ST.DOC              7 September 1979
   
   
             quantity.
   
             TARGET (P-CODE = 2, P-LENGTH = 5) is the ST address of
             the target process.
   
             FLOW-SPEC (P-CODE = 3, P-LENGTH = 18) is a complex
             parameter that both specifies and reports on the flow
             requirements and expected delay characteristics of the
             full-duplex connection.  See Section 4.5 for further
             information.
   
             CID.B (P-CODE = 4, P-LENGTH = 2) is the connection
             identifier to be used on packets moving in the backward
             direction on the connection.
   
           CONNECT.PTP expects a response.  There are four response
   possibilities: ACCEPT.PTP, REFUSE.PTP, ACK, and ERROR-IN-REQUEST.
   Receipt of an ACK means that the agent receiving the request is
   working on it, and the requester should wait for a future ACCEPT
   or REFUSE.  ERROR-IN-REQUEST will be returned only when a format
   error is detected in the CONNECT.PTP.  Other errors, if detected,
   will elicit REFUSE messages.
   
           The processing of CONNECT messages requires care to avoid
   routing loops that could result from delays in propagating
   routing information among gateways. The example in Section 7.0
   describes in some detail the actions of agents in handling
   CONNECT requests while routing a connection.
   
   6.1.2  [ACCEPT.PTP] <NAME> <TARGET> <FLOW-SPEC> <CID.F)
   
   ACCEPT.PTP (OP-CODE = 6) is returned to indicate that the
   requirements of a CONNECT.PTP have been met or that a change in
   flow specifications has occured.  Parameters are the same as for
   CONNECT.PTP except that a CID.F (P-CODE = 5, P-LENGTH = 2) is
   returned for use on packets travelling in the forward direction.
   The FLOW-SPEC will be modified to show the accepted rate and
   accumulated delay information (See Section 4.5).
   
           ACCEPT messages expect ACK's or ERROR-IN-RESPONSE's.
   ERROR-IN-RESPONSE will be returned if an ACCEPT is sent to an
   agent that has no knowledge of the connection.  This may occur if
   an ACCEPT is generated at the same time that a DISCONNECT is
   being propagated.
   
   6.1.3  [REFUSE.PTP] <NAME> <REASON>
   
   REFUSE.PTP (OP-CODE = 7) is returned to indicate that agents have
   failed to set up a requested connection or that a previously
   established connection has been lost. REFUSE's are also returned
   to indicate routing failure, and in such a case may not end up
   
   
                                 -27-
   
   
   IEN 119                      ST.DOC              7 September 1979
   
   
   propagating back to the origin.  TARGET's also issue REFUSE's to
   take down connections intentionally.
   
   REASON (P-CODE = 6, P-LENGTH = 2) indicates the reason for
   connection refusal.  REASON codes apply also to DISCONNECT
   messages and include the following:
   
              CODE            EXPLANATION
   
               0       No explanation
               1       Target refuses connection
               2       Target does not respond
               3       Target cannot be reached
               4       Connection preempted
               5       STREAM INTERVAL too short
               6       Requested data rate cannot be handled
               7       Connection broken due to network fault
               8       Connection broken by ORIGIN
               9       Conflicting FLOW-SPECs in CONF connections
   
           REFUSE's are ACK'ed and are propagated by intermediate
   agents if meaningful (i.e., the agents had tables for the
   connection).  The backward propagation of a refuse may be halted
   at an intermediate agent if an alternate route exists that has
   not been tried, and the REASON indicates that it is reasonable to
   try the alternate route.  (I.e., it does not indicate that the
   target refuses or does not respond).
   
   6.1.4  [DISCONNECT.PTP] <NAME> <REASON>
   
           DISCONNECT.PTP (OP-CODE = 8) is sent to request that a
   previously requested connection be taken down.  It can be
   generated either by the originator of the CONNECT or by an
   intermediate agent that executes a preemption or detects a fault.
   
           REASON uses the same codes as REFUSE although not all
   codes apply.
   
           DISCONNECT expects an ACK and is propagated in the
   forward direction so long as agents are encountered that know
   about the connection.
   
           A connection can be taken down either by a REFUSE or a
   DISCONNECT (or both) depending upon which end first decides to
   initiate the process. If both start within a propagation time of
   each other, neither message will reach the opposite end.
   
   
   
   
   
   
   
                                 -28-
   
   
   IEN 119                      ST.DOC              7 September 1979
   
   
   6.2  Control Messages for CONF Connections
   
   
           CONF connections are set up and taken down with CONNECT,
   ACCEPT, REFUSE, and DISCONNECT messages, but the CONF versions of
   these messages have somewhat different parameters.  In addition,
   CONF connection setup requires that agents communicate with
   access controllers by means of TELL-ME and INFO messages.  These
   latter messages are sent as IP.ST datagrams.  The former are sent
   as ST.DG packets with CID = 0.
   
   6.2.1  [CONNECT.CONF] <NAME> <OBM> <TBM> <CID.B>
   
           CONNECT.CONF (OP-CODE = 9) requests the setup (routing)
   of a CONF connection or asks for a change in flow specifications
   of a connection already routed.  The parameters NAME and CID.B
   have the same form and interpretation as they do for CONNECT.PTP
   except that NAME is the name of the owner of the conference, not
   the originator of the CONNECT message.  The new parameters OBM
   and TBM allow the message to deal with multiple ORIGIN and TARGET
   processes.  The FLOW-SPEC for the connection is obtained from the
   access controller.
   
           OBM (P-CODE = 8, P-LENGTH = 2-9) is the ORIGIN-BIT-MAP.
   Bits set in the map identify originating processes.  When a
   CONNECT.CONF is first issued by a user process only one bit is
   set in OBM identifying the issuer.  However, as the message
   propagates, intermediate agents may find that they have other
   CONNECT.CONF messages for the same connection on hand at the same
   time.  In that case, they can merge the requests so that more
   bits become set as the message approaches its targets.
   
           TBM (P-CODE = 9, P-LENGTH = 2-9) is the TARGET-BIT-MAP.
   Bits set in the map identify the target processes.  In general,
   the user process will have set many bits in TBM when it first
   issues a CONNECT.CONF.  As the message propagates it will split
   many times, each split reducing the number of bits left set in
   TBM.  When the CONNECT.CONF's reach their targets only one bit
   will be left set in each.
   
           Since the CONNECT.CONF message does not tell its receiver
   anything about the actual identities of the target processes,
   intermediate agents must get this information, as well as the
   FLOW-SPEC, from the access controller by sending TELL-ME messages
   and receiving INFO messages in response.  The agents use the NAME
   to locate the AC, using a bit in the name to distinguish between
   a public or private AC.  The NAME is the ST address of a process
   concatenated with a 16-bit number to make the NAME unique.  It is
   proposed that the most significant bit of that 16-bit number be
   used to distinguish public from private ACs.  A zero in that bit
   would indicate a private AC and in that case, agents would send
   
   
                                 -29-
   
   
   IEN 119                      ST.DOC              7 September 1979
   
   
   TELL-ME messages to the process address in the NAME.  In the
   public case, the agent would communicate with an AC whose address
   was known a priori to the agent.
   
   6.2.2  [ACCEPT.CONF] <NAME> <OBM> <TBM> <FLOW-SPEC> <CID.F>
   
           ACCEPT.CONF (OP-CODE = 10) is similar in function to
   ACCEPT.PTP.  NAME, FLOW-SPEC, and CID.F have the same form and
   interpretation.  OBM specifies the set of originators to which
   the ACCEPT is to be propagated.  TBM specifies the set of targets
   that have accepted the connection.  This set may be a sub-set of
   the targets requested in the CONNECT to which an ACCEPT responds.
   The FLOW-SPEC is included in the ACCEPT because it reflects the
   actual resources granted to the connection.
   
   6.2.3  [REFUSE.CONF] <NAME> <OBM> <TBM> <REASON>
   
           REFUSE.CONF (OP-CODE = 11) is similar in function to
   REFUSE.PTP.  As for ACCEPT.CONF, OBM specifies the set of
   originators to which the REFUSE is to be propagated.  TBM
   specifies the set of targets that cannot be reached, have
   refused, etc.  A single REASON applies to all the targets in the
   TBM.  If more than one REASON applies to a set of targets, as
   many REFUSE's as REASON's will be sent.
   
   6.2.4  [DISCONNECT.CONF] <NAME> <OBM> <TBM> <REASON>
   
           DISCONNECT.CONF (OP-CODE = 12) is similar in function to
   DISCONNECT.PTP.  As for REFUSE.CONF, OBM and TBM specify the sets
   of originators and targets to which the DISCONNECT applies.
   
   6.2.5  [TELL-ME] <NAME> <PART-NUM> <FLOW-SPEC-REQ>
   
           TELL-ME (OP-CODE = 13) is sent from an agent or a
   participant process to an access controller .  The AC is expected
   to return an INFO message with the requested information.  Either
   of the latter two parameters may be omitted.
   
           PART-NUM (P-CODE = 10, P-LENGTH = 2) specifies the number
   of the first participant about which information is requested.
   The response will be a participant list starting with the
   specified participant and continuing until the maximum packet
   size is reached or the list is exhausted.
   
           FLOW-SPEC-REQ (P-CODE = 11, P-LENGTH = 2) requests the AC
   to send the FLOW-SPEC for the connection.
   
   
   
   
   
   
   
                                 -30-
   
   
   IEN 119                      ST.DOC              7 September 1979
   
   
   6.2.6  [INFO] <NAME> <STATUS> <PART-LIST> <FLOW-SPEC>
   
           INFO (OP-CODE = 14) is sent from an AC to an agent or
   participant process in response to a TELL-ME.  It provides the
   requested information.  STATUS is always present.  PART-LIST and
   FLOW-SPEC are present only when requested by the TELL-ME.
   
           STATUS (P-CODE = 12, P-LENGTH = 2) carries 2 bytes of
   information.  Byte 1 is the CONF-TYPE.  Byte 2 gives the length
   of the participant list.  The following values for CONF-TYPE are
   defined:
            Type                  Meaning
   
             0         No conference defined with this NAME
   
             1         Conference with closed participant list
   
             2         Conference with open list and password
   
             3         Conference with completely open list (no
                       password needed).
   
   
           PART-LIST (P-CODE = 13, P-LENGTH = (4m + 2)) provides a
   section of the participant list starting at the location (PART-
   NUM) requested in the TELL-ME and continuing until either the end
   of the list or packet capacity is reached.  The items in the
   PART-LIST are the ST addresses (64 bits) of the participating
   processes.  The addresses are present whether or not the
   participants are active.  The addresses are preceded by a word
   giving the number of the first participant on the list.
   
           FLOW-SPEC is the nominal FLOW-SPEC for the conference.
   
   
   7.0  AN EXAMPLE OF CONF CONNECTION SETUP
   
   
           This section is a rather detailed example of the actions
   called for by ST in setting up a connection for a conference with
   four participants. In addition to showing the control message
   flow, it also indicates the information used and retained by
   gateways in supporting the connection. For the sake of
   simplicity, it is assumed that the flow requirements are always
   met.  The ".CONF" suffix is omitted from OP-CODE's, and
   parameters such as NAME and FLOW-SPEC that are always the same
   are also omitted.  In addition, ACK's are not shown but are
   assumed to occur where required.
   
   
   
   
   
                                 -31-
   
   
   IEN 119                      ST.DOC              7 September 1979
   
   
   
           The example uses the following network configuration:
   
   
   
            +---+                +---+                +---+
            !P3 !                !P2 !                !P1 !
            +---+                +---+                +---+
            !ST3!                !ST2!                !ST1!
            +---+                +---+                +---+
              !                    !                    !
              !                    !                    !
          +-------+  +------+  +-------+  +------+  +-------+
          ! Net A !--! G.AB !--! Net B !--! G.BC !--! Net C !
          +-------+  +------+  +-------+  +------+  +-------+
              !                                         !
              !                                         !
            +---+                                     +---+
            !ST4!                                     !AC !
            +---+                                     +---+
            !P4 !
            +---+
   
   
           Each participant (Pi) communicates through a host agent
   called "STi." The communications between the P's and their local
   ST's are written out as control messages to show the logical flow
   even though in actual implementations they might be handled very
   differently.
   
           The actions involving ST start after the participants
   have joined the conference by communicating with the access
   controller (AC) and have received TARGET-BIT-MAPs (TBMs) telling
   each Pi to which other Pi's connections are to be set up.  The
   notation "{ A, B, C }" is used to indicate a bit map with bits
   set for A, B, and C.  The participants are assumed to have joined
   in the order of their numbers.  Thus P1 got an empty TBM ({ }),
   and P4 got TBM = { P1, P2, P3 }.  According to the rules, P1
   issues no CONNECT messages, but waits for the others to connect
   to it.  The action thus begins with P2 sending:
   
   P2->ST2: [CONNECT] <OBM = { P2 }> <TBM = { P1 }> <CID.B = 3>
   
   ST2->AC: [TELL-ME] <PART-NUM = 1> <FLOW-SPEC-REQ>
   
   AC->ST2: [INFO] <PART-LIST = ADDR.P1, ADDR.P2, ADDR.P3, ADDR.P4>
              <FLOW-SPEC> <STATUS>
   
           These last two commands are executed independently by all
   agents when they first receive a CONNECT.  They will be replaced
   by the phrase "X gets info" in the following.
   
   
                                 -32-
   
   
   IEN 119                      ST.DOC              7 September 1979
   
   
           ST2 observes that ADDR.P1 is not in its local net and
   lacking routing knowledge decides to try G.AB (the wrong
   direction).
   
   ST2->G.AB: [CONNECT] <OBM = { P2 }> <TBM = { P1 }> <CID.B = 17>
   
           G.AB gets info and decides that net C is unreachable
   except through net B from whence the CONNECT came.
   
   G.AB->ST2: [REFUSE] <OBM = { P2 }> <TBM = { P1 }>
                <REASON = 3 (Target cannot be reached)>
   
           ST2 decides to try another gateway.
   
   ST2->G.BC: [CONNECT] <OBM = { P2 }> <TBM = { P1 }> <CID.B = 17>
   
           G.BC gets info, builds a connection entry, and sends:
   
   G.BC->ST1: [CONNECT] <OBM = { P2 }> <TBM = { P1 }> <CID.B = 100l>
   
           ST1 gets info and sends:
   
   ST1->P1: [CONNECT] <OBM = { P2 }> <TBM = { P1 }> <CID.B = 1>
   
           Since P1 has already joined the conference and recognizes
   P2 as another participant, it sends:
   
   P1->ST1: [ACCEPT] <OBM = { P2 }> <TBM = { P1 }> <CID.F = 1>
   
   ST1->G.BC: [ACCEPT] <OBM = { P2 }> <TBM = { P1 }> <CID.F = 32>
   
           At this point G.BC would have the following stored
   information (neglecting bookkeeping items such as pointers).
   
         1.  A connection block with NAME, FLOW-SPEC, and CID.IN =
             1001 (the same CID can be used for all inputs for the
             connection).  This information is retained for the life
             of the connection.  The PART-LIST used in processing
             may be discarded once an ACCEPT (or REFUSE) has been
             received and the forwarding tables have been created.
             However, since there are likely to be other CONNECT's
             to be processed, it would be efficient to keep the
             PART-LIST for a time (say several minutes).
   
   
   
   
   
   
   
   
   
   
                                 -33-
   
   
   IEN 119                      ST.DOC              7 September 1979
   
   
         2.  Two forwarding tables, one for each packet that might
             be sent in response to an input.
   
              ITEMS                   #1              #2
   
             NET-PORT                  B               C
   
             ADDRESS                  ST2             ST1
   
             MASK.OBM                { P2 }           { }
   
             MASK.TBM                 { }            { P1 }
   
             CID.OUT                   17              32
   
   
           The principal function of the masks is to facilitate
   packet forwarding.  When a packet arrives, the following
   computation is made for each forwarding table to compute the
   output FORWARDING-BIT-MAP (FBM):
   
           FBM.OUT = FBM.IN & (MASK.OBM U MASK.TBM)
   
   If FBM.OUT has no bits set, it is not necessary to send a packet
   to the address in the table.  Otherwise a packet is sent using
   the NET-PORT, ADDRESS, and CID.OUT from the table.
   
           Having built its tables, G.BC sends:
   
   G.BC->ST2: [ACCEPT] <OBM = { P2 }> <TBM = { P1 }> <CID.F = 1001>
   
   ST2->P2: [ACCEPT] <OBM = { P2 }> <TBM = { P1 }> <CID.F = 10>
   
           At this point P2 and P1 are connected and could begin
   talking, if permitted by the higher level protocol.
   
           In connecting P3 and P4 we will assume that both initiate
   requests at essentially the same time so that they propagate
   concurrently.
   
   P3->ST3: [CONNECT] <OBM = { P3 }> <TBM = { P1, P2 }> <CID.B = 5>
   
   P4->ST4: [CONNECT] <OBM = { P4 }> <TBM = { P1, P2, P3 }>
             <CID.B = 1>
   
           ST3 and ST4 get info.  ST3 notices that P1, P2 both are
   outside the local net, but ST4 notices as well that P3 is on the
   same net as P4.
   
   They send:
   
   
   
                                 -34-
   
   
   IEN 119                      ST.DOC              7 September 1979
   
   
   ST3->G.AB: [CONNECT] <OBM = { P3 }> <TBM = { P1, P2 }>
               <CID.B = 135>
   
   ST4->ST3: [CONNECT] <OBM = { P4 }> <TBM = { P3 }> <CID.B = 27>
   
   ST4->G.AB: [CONNECT] <OBM = { P4 }> <TBM = { P1, P2 }>
               <CID.B = 27>
   
           ST3 forwards the CONNECT to P3, which accepts, and ST3
   responds to ST4 with:
   
   ST3->ST4: [ACCEPT] <OBM = { P4 }> <TBM = { P3 }> <CID.F = 135>
   
           Meanwhile G.AB gets info and notices that it has two
   CONNECT's for the same NAME.  It decides to merge them and sends:
   
   G.AB->ST2: [CONNECT] <OBM = { P3, P4 }> <TBM = { P2 }>
               <CID.B = 2356>
   
   and
   
   G.AB->G.BC: [CONNECT] <OBM = { P3, P4 }> <TBM = { P1 }>
                <CID.B = 2356>
   
           ST2 forwards the CONNECT to P2, which accepts, and ST2
   sends:
   
   ST2->G.AB: [ACCEPT] <OBM = { P3, P4 }> <TBM = { P2 }>
               <CID.F = 17>
   
           Now G.AB will not continue to propagate the ACCEPT
   because the CONNECT on which it is working asked for connection
   to P1 as well as P2.  It will wait for an ACCEPT or REFUSE from
   P1.
   
           G.BC  already knows about the connection to P1, but it
   does not assume that P1 will accept P3 and P4, so it propagates
   the CONNECT.
   
   G.BC->ST1: [CONNECT] <OBM = { P3, P4 }> <TBM = { P1 }>
               <CID.B = 1001>
   
           ST1 forwards to P1, which accepts, and ST1 responds:
   
   ST1->G.BC: [ACCEPT] <OBM = { P3, P4 }> <TBM = { P1 }> <CID.F =
   32>
   
           In the latter exchange G.BC and ST1 used the same CID's
   they had used before for this connection.  If either had chosen
   to use a different CID, the newer value would supercede the
   earlier one in the forwarding table.
   
   
                                 -35-
   
   
   IEN 119                      ST.DOC              7 September 1979
   
   
           It should be noted that the protocol could allow G.BC to
   accept the connection from P3 and P4 without forwarding the
   CONNECT to ST1 because G.BC already knows it has a connection to
   P1.  This shortcut is not taken because it denies P1 the
   information about the connection requests from P3 and P4 and the
   opportunity to refuse those connections if desired.
   
   
           To finish the setup we have:
   
   G.BC->G.AB: [ACCEPT] <OBM = { P3, P4 }> <TBM = { P1 }>
                <CID.F = 1001>
   
           G.AB will now accept for P1 and P2.
   
   G.AB->ST3: [ACCEPT] <OBM = { P3 }> <TBM = { P1, P2 }>
               <CID.F = 2356>
   
   G.AB->ST4: [ACCEPT] <OBM = { P4 }> <TBM = { P1, P2 }>
               <CID.F = 2356>
   
           When ST3 and ST4 propagate the ACCEPT's to P3 and P4 the
   conference connection is complete.
   
           At this point the forwarding tables in G.BC are the
   following:
   
         ITEM               #1              #2              #3
   
       NET-PORT              B               C               B
   
       ADDRESS              ST2             ST1             G.AB
   
       MASK.OBM           { P2 }            { }          { P3, P4 }
   
       MASK.TBM             { }            { P1 }           { }
   
       CID.OUT              17              32              2356
   
   
           If at some later time G.BC should decide to preempt the
   connection, it would issue one message for each forwarding table
   entry:
   
   G.BC->ST2: [REFUSE] <OBM = { P2 }> <TBM = { P1 }>
               <REASON = 4 (Connection preempted)>
   
   G.BC->ST1: [DISCONNECT] <OBM = { P2, P3, P4 }> <TBM = { P1 }>
               <REASON = 4 (Connection preempted)>
   
   
   
   
                                 -36-
   
   
   IEN 119                      ST.DOC              7 September 1979
   
   
   G.BC->G.AB: [REFUSE] <OBM = { P3, P4 }> <TBM = { P1 }>
               <REASON = 4 (Connection preempted)>
   
           Having issued these messages and received ACKs in
   response (or timed out in the absence of an ACK), the gateway can
   delete the table entries and reclaim the CID for future use.  The
   REFUSE sent to G.AB would, of course, be propogated to ST3 and
   ST4.
   
   
   8.0  AREAS NEEDING FURTHER WORK
   
           This document does not completely specify the protocol.
   Further work is needed to specify error conditions and their
   handling.  The FLOW-SPEC parameter is not yet laid out in detail.
   Rerouting has not been thought through sufficiently.  The whole
   area of routing strategies and the information to be exchanged
   among gateways has not been given much consideration.  There is
   also a need for agents to exchange information (not yet
   specified) about local net resources.  For example, if agents are
   to make use of local net multi-addressing capability, the
   selection of a CID for a connection is no longer at the
   discretion of an individual agent.  A convention is needed to
   avoid conflicting use of CID's as well as requesting duplicate
   resources to serve a CONF connection.  The CONNECT control
   message needs to be extended to allow agents to indicate local
   net resources that are already committed to a CONF connection.
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
                                 -37-
   
   
   
/data/webs/external/dokuwiki/data/pages/rfc/ien/ien119.txt · Last modified: 2001/06/25 18:59 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki