tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7846

Proposed STD
Pages: 55
Top     in Index     Prev     Next
in Group Index     Prev in Group     No Next: Highest Number in Group     Group: PPSP

Peer-to-Peer Streaming Tracker Protocol (PPSTP)

Part 1 of 3, p. 1 to 16
None       Next RFC Part

 


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                           R. Cruz
Request for Comments: 7846                                      M. Nunes
Category: Standards Track                              IST/INESC-ID/INOV
ISSN: 2070-1721                                                   J. Xia
                                                           R. Huang, Ed.
                                                                  Huawei
                                                              J. Taveira
                                                                IST/INOV
                                                               D. Lingli
                                                            China Mobile
                                                                May 2016


            Peer-to-Peer Streaming Tracker Protocol (PPSTP)

Abstract

   This document specifies the base Peer-to-Peer Streaming Tracker
   Protocol (PPSTP) version 1, an application-layer control (signaling)
   protocol for the exchange of meta information between trackers and
   peers.  The specification outlines the architecture of the protocol
   and its functionality; it also describes message flows, message
   processing instructions, message formats, formal syntax, and
   semantics.  The PPSTP enables cooperating peers to form content-
   streaming overlay networks to support near real-time delivery of
   structured media content (audio, video, and associated timed text and
   metadata), such as adaptive multi-rate, layered (scalable), and
   multi-view (3D) videos in live, time-shifted, and on-demand modes.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc7846.

Page 2 
Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1. Introduction ....................................................4
      1.1. Terminology ................................................4
      1.2. Design Overview ............................................6
           1.2.1. Typical PPSP Session ................................7
           1.2.2. Example of a PPSP Session ...........................7
   2. Protocol Architecture and Functional View ......................10
      2.1. Messaging Model ...........................................10
      2.2. Request/Response Model ....................................10
      2.3. State Machines and Flows of the Protocol ..................12
           2.3.1. Normal Operation ...................................14
           2.3.2. Error Conditions ...................................15
   3. Protocol Specification .........................................16
      3.1. Presentation Language .....................................16
      3.2. Resource Element Types ....................................16
           3.2.1. Version ............................................16
           3.2.2. Peer Number Element ................................17
           3.2.3. Swarm Action Element ...............................18
           3.2.4. Peer Information Elements ..........................18
           3.2.5. Statistics and Status Information Element ..........20
      3.3. Requests and Responses ....................................21
           3.3.1. Request Types ......................................21
           3.3.2. Response Types .....................................21
           3.3.3. Request Element ....................................22
           3.3.4. Response Element ...................................23
      3.4. PPSTP Message Element .....................................24
   4. Protocol Specification: Encoding and Operation .................24
      4.1. Requests and Responses ....................................25
           4.1.1. CONNECT Request ....................................25
                  4.1.1.1. Example ...................................28
           4.1.2. FIND Request .......................................32
                  4.1.2.1. Example ...................................33

Top      ToC       Page 3 
           4.1.3. STAT_REPORT Request ................................34
                  4.1.3.1. Example ...................................35
      4.2. Response Element in Response Messages .....................36
      4.3. Error and Recovery Conditions .............................37
      4.4. Parsing of Unknown Fields in message-body .................38
   5. Operations and Manageability ...................................38
      5.1. Operational Considerations ................................38
           5.1.1. Installation and Initial Setup .....................38
           5.1.2. Migration Path .....................................39
           5.1.3. Requirements on Other Protocols and
                  Functional Components ..............................39
           5.1.4. Impact on Network Operation ........................39
           5.1.5. Verifying Correct Operation ........................40
      5.2. Management Considerations .................................40
           5.2.1. Interoperability ...................................40
           5.2.2. Management Information .............................40
           5.2.3. Fault Management ...................................41
           5.2.4. Configuration Management ...........................41
           5.2.5. Accounting Management ..............................41
           5.2.6. Performance Management .............................41
           5.2.7. Security Management ................................41
   6. Security Considerations ........................................42
      6.1. Authentication between Tracker and Peers ..................42
      6.2. Content Integrity Protection against Polluting
           Peers/Trackers ............................................43
      6.3. Residual Attacks and Mitigation ...........................43
      6.4. Pro-incentive Parameter Trustfulness ......................44
      6.5. Privacy for Peers .........................................44
   7. Guidelines for Extending PPSTP .................................45
      7.1. Forms of PPSTP Extension ..................................45
      7.2. Issues to Be Addressed in PPSTP Extensions ................47
   8. IANA Considerations ............................................48
      8.1. MIME Type Registry ........................................48
      8.2. PPSTP Version Number Registry .............................49
      8.3. PPSTP Request Type Registry ...............................49
      8.4. PPSTP Error Code Registry .................................50
   9. References .....................................................51
      9.1. Normative References ......................................51
      9.2. Informative References ....................................53
   Acknowledgments ...................................................54
   Authors' Addresses ................................................55

Top      ToC       Page 4 
1.  Introduction

   The Peer-to-Peer Streaming Protocol (PPSP) is composed of two
   protocols: the Tracker Protocol (defined in this document) and the
   Peer Protocol (defined in [RFC7574]).  [RFC6972] specifies that the
   Tracker Protocol should standardize the messages between PPSP peers
   and PPSP trackers and also defines the requirements.

   The Peer-to-Peer Streaming Tracker Protocol (PPSTP) provides
   communication between trackers and peers by which peers send meta
   information to trackers, report streaming status, and obtain peer
   lists from trackers.

   The PPSP architecture requires PPSP peers to be able to communicate
   with a tracker in order to participate in a particular streaming
   content swarm.  This centralized tracker service is used by PPSP
   peers for acquisition of peer lists.

   The signaling and the media data transfer between PPSP peers is not
   in the scope of this specification.

   This document introduces a base Peer-to-Peer Streaming Tracker
   Protocol (PPSTP) that satisfies the requirements in [RFC6972].

1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   absolute time: Expressed as ISO 8601 timestamps, using zero UTC
      offset.  Fractions of a second may be indicated, for example,
      December 25, 2010 at 14h56 and 20.25 seconds in basic format is
      20101225T145620.25Z and in extended format is
      2010-12-25T14:56:20.25Z.

   chunk: An uniformly atomic subset of the resource that constitutes
      the basic unit of data organized in P2P streaming for storage,
      scheduling, advertisement, and exchange among peers.

   chunk ID: A unique resource identifier for a chunk.  The identifier
      type depends on the addressing scheme used, i.e., an integer, an
      HTTP-URL, and possibly a byte-range.  The identifier type is
      described in the Media Presentation Description (MPD).

   LEECH: The peers in a swarm that download content from other peers as
      well as contribute downloaded content with others.  A LEECH should
      join the swarm with uncompleted media content.

Top      ToC       Page 5 
   MPD (Media Presentation Description): Formalized description for a
      media presentation, i.e., describes the structure of the media,
      namely, the representations, the codecs used, the chunks, and the
      corresponding addressing scheme.

   peer: A participant in a P2P streaming system that not only receives
      streaming content, but also caches and streams streaming content
      to other participants.

   peer ID: The identifier of a peer such that other peers, or the
      Tracker, can refer to the peer using its ID.  The peer ID is
      mandatory, can take the form of a universally unique identifier
      (UUID), defined in [RFC4122], and can be bound to a network
      address of the peer, i.e., an IP address or a uniform resource
      identifier/locator (URI/URL) that uniquely identifies the
      corresponding peer in the network.  The peer ID and any required
      security certificates are obtained from an offline enrollment
      server.

   peer list: A list of peers that are in the same swarm maintained by
      the tracker.  A peer can fetch the peer list of a swarm from the
      tracker.

   PPSP: The abbreviation of Peer-to-Peer Streaming Protocol.

   PPSTP: The abbreviation of Peer-to-Peer Streaming Tracker Protocol.

   SEEDER: The peers in a swarm that only contribute the content they
      have to others.  A SEEDER should join the swarm with complete
      media content.

   service portal: A logical entity typically used for client enrollment
      and for publishing, searching, and retrieving content information.
      It is usually located in a server of a content provider.

   swarm: A group of peers that exchange data to distribute chunks of
      the same content (e.g., video/audio program, digital file, etc.)
      at a given time.

   swarm ID: The identifier of a swarm containing a group of peers
      sharing common streaming content.  The swarm ID may use a
      universally unique identifier (UUID), e.g., a 64- or 128-bit datum
      to refer to the content resource being shared among peers.

   tracker: A directory service that maintains a list of peers
      participating in a specific audio/video channel or in the
      distribution of a streaming file.  It is a logical component that
      can be deployed in a centralized or distributed way.

Top      ToC       Page 6 
   transaction ID: The identifier of a request from the peer to the
      tracker.  It is used to disambiguate responses that may arrive in
      a different order than the corresponding requests.

1.2.  Design Overview

   The functional entities related to peer-to-peer streaming protocols
   are the Client Media Player, the service portal, the tracker, and the
   peers.  The complete description of Client Media Player and service
   portal is not discussed here, as they are not in the scope of the
   specification.  The functional entities directly involved in PPSTP
   are trackers and peers (which may support different capabilities).

   The Client Media Player is a logical entity providing direct
   interface to the end user at the client device and includes the
   functions to select, request, decode, and render content.  The Client
   Media Player may interface with the local peer application using the
   standard format for HTTP request and response messages [RFC7230].

   The service portal is a logical entity typically used for client
   enrollment and for publishing, searching, and retrieving content
   information.

   A peer corresponds to a logical entity (typically in a user device)
   that actually participates in sharing media content.  Peers are
   organized in various swarms; each swarm corresponds to the group of
   peers streaming certain content at any given time.

   A tracker is a logical entity that maintains the lists of peers
   storing chunks for a specific live media channel or on-demand media
   streaming content, answers queries from peers, and collects
   information on the activity of peers.  While a tracker may have an
   underlying implementation consisting of more than one physical node,
   logically, the tracker can most simply be thought of as a single
   element; in this document, it will be treated as a single logical
   entity.  Communication between these physical nodes to present them
   as a single tracker to peers is not considered in PPSTP, which is a
   protocol between a tracker and a peer.

   PPSTP is not used to exchange actual content data (either on demand
   or live streaming) with peers, but information about which peers can
   provide the content.  PPSTP is not designed for applications for
   which in-sync reception is needed.

Top      ToC       Page 7 
1.2.1.  Typical PPSP Session

   When a peer wants to receive streaming of selected content (LEECH
   mode):

   1. Peer connects to a tracker and joins a swarm.

   2. Peer acquires a list of other peers in the swarm from the tracker.

   3. Peer exchanges its content availability with the peers on the
      obtained peer list.

   4. Peer identifies the peers with desired content.

   5. Peer requests content from the identified peers.

   When a peer wants to share streaming content (SEEDER mode) with other
   peers:

   1. Peer connects to a tracker.

   2. Peer sends information to the tracker about the swarms it belongs
      to (joined swarms).

   3. Peer waits for other peers in LEECH mode to connect with it (see
      steps 3-5 in the previous list).

   After having been disconnected due to some termination conditions or
   user controls, a peer can resume previous activity by connecting and
   re-joining the corresponding swarm(s).

1.2.2.  Example of a PPSP Session

   In order to be able to bootstrap in the P2P network, a peer must
   first obtain a peer ID and any required security certificates or
   authorization tokens from an enrollment service (end-user
   registration).  The peer ID MUST be unique (see the definition of
   "peer ID" in Section 1.1); however, the representation of the peer ID
   is not considered in this document.

Top      ToC       Page 8 
   +--------+      +--------+     +--------+    +---------+  +--------+
   | Player |      | Peer_1 |     | Portal |    | Tracker |  | Peer_2 |
   +--------+      +--------+     +--------+    +---------+  +--------+
       |                |               |              |           |
   (a) |--Page request----------------->|              |           |
       |<--------------Page with links--|              |           |
       |--Select stream (MPD request)-->|              |           |
       |<--------------------OK+MPD(x)--|              |           |
   (b) |--Start/Resume->|--CONNECT(join x)------------>|           |
       |<-----------OK--|<----------------OK+Peerlist--|           |
       |                |                              |           |
       |--Get(chunk)--->|<---------- (Peer protocol) ------------->|
       |<--------chunk--|<---------------------------------chunks--|
       :                :               :              :           :
       |                |--STAT_REPORT---------------->|           |
       |                |<-------------------------OK--|           |
       :                :               :              :           :
       |                |--FIND----------------------->|           |
       |                |<----------------OK+Peerlist--|           |
       :                :               :              :           :
       |--Get(chunk)--->|<---------- (Peer protocol) ------------->|
       |<--------chunk--|<---------------------------------chunks--|
       :                :               :              :           :

        Figure 1: A Typical PPSP Session for Streaming Content

   To join an existing P2P streaming service and to participate in
   content sharing, a peer must first locate a tracker.

   As illustrated in Figure 1, a P2P streaming session may be initiated
   starting at point (a), with the Client Media Player browsing for the
   desired content in order to request it (to the local Peer_1 in the
   figure), or resume a previously initiated stream, but starting at
   point (b).  For this example, the Peer_1 is in mode LEECH.

   At point (a) in Figure 1, the Client Media Player accesses the portal
   and selects the content of interest.  The portal returns the Media
   Presentation Description (MPD) file that includes information about
   the address of one or more trackers (which can be grouped by tiers of
   priority) that control the swarm x for that media content (e.g.,
   content x).

   With the information from the MPD, the Client Media Player is able to
   trigger the start of the streaming session, requesting to the local
   Peer_1 the chunks of interest.

Top      ToC       Page 9 
   The PPSP streaming session is then started (or resumed) at Peer_1 by
   sending a PPSTP CONNECT message to the tracker in order to join swarm
   x.  The tracker will then return the OK response message containing a
   peer list, if the CONNECT message is successfully accepted.  From
   that point, every chunk request is addressed by Peer_1 to its
   neighbors (Peer_2 in Figure 1) using a peer protocol, e.g.,
   [RFC7574], returning the received chunks to the Client Media Player.

   Once connected, Peer_1 needs to periodically report its status and
   statistics data to the tracker using a STAT_REPORT message.

   If Peer_1 needs to refresh its neighborhood (for example, due to
   churn), it will send a PPSTP FIND message (with the desired scope) to
   the tracker.

   Peers that are only SEEDERs (i.e., serving content to other peers),
   as are the typical cases of service provider P2P edge caches and/or
   media servers, trigger their P2P streaming sessions for content x, y,
   z...  (Figure 2), not from Media Player signals, but from some
   "Start" activation signal received from the service provider
   provisioning mechanism.  In this particular case, the peer starts or
   resumes all its streaming sessions just by sending a PPSTP CONNECT
   message to the tracker (Figure 2), in order to "join" all the
   requested swarms.

   Periodically, the peer also reports its status and statistics data to
   the tracker using a PPSTP STAT_REPORT message.

              +---------+                     +---------+
              |  SEEDER |                     | Tracker |
              +---------+                     +---------+
                   |                               |
            Start->|--CONNECT (join x,y,z)-------->|
                   |<--------------------------OK--|
                   :                               :
                   |                               |
                   |--STAT_REPORT----------------->|
                   |<--------------------------Ok--|
                   :                               :
                   |                               |
                   |--STAT_REPORT----------------->|
                   |<--------------------------Ok--|
                   :                               :

     Figure 2: A Typical PPSP Session for a Streaming SEEDER

Top      ToC       Page 10 
   The specification of the mechanisms used by the Client Media Player
   (or provisioning process) and the peer to signal start/resume of
   streams, request media chunks, and obtain a peer ID, security
   certificates, or tokens is not in the scope of this document.

2.  Protocol Architecture and Functional View

   PPSTP is designed with a layered approach i.e., a PPSTP
   Request/Response layer, a Message layer, and a Transport layer (see
   Figure 3).

                 +------------------------+
                 |      Application       |
                 +------------------------+
                 |(PPSTP) Request/Response|
                 |------------------------|
                 |   (HTTP) Message       |
                 +------------------------+
                 |       Transport        |
                 +------------------------+

             Figure 3: Abstract Layering of PPSTP

   The PPSTP Request/Response layer deals with the interactions between
   tracker and peers using request and response messages.

   The Message layer deals with the framing format for encoding and
   transmitting data through the underlying transport protocol, as well
   as the asynchronous nature of the interactions between tracker and
   peers.

   The Transport layer is responsible for the actual transmission of
   requests and responses over network transports, including the
   determination of the connection to use for a request or response
   message when using TCP or Transport Layer Security (TLS) [RFC5246]
   over it.

2.1.  Messaging Model

   The messaging model of PPSTP aligns with HTTP, which is currently in
   version 1.1 [RFC7230], and the semantics of its messages.  PPSTP is
   intended to also support future versions of HTTP.

2.2.  Request/Response Model

   PPSTP uses a design like REST (Representational State Transfer) with
   the goal of leveraging current HTTP implementations and
   infrastructure, as well as familiarity with existing REST-like

Top      ToC       Page 11 
   services in popular use.  PPSTP messages use the UTF-8 character set
   [RFC3629] and are either requests from peers to a tracker service or
   responses from a tracker service to peers.  The request and response
   semantics are carried as entities (header and body) in messages that
   correspond to either HTTP request methods or HTTP response codes,
   respectively.

   PPSTP uses the HTTP POST method to send parameters in requests.
   PPSTP messages use JavaScript Object Notation (JSON) [RFC7159] to
   encode message bodies.

   Peers send requests to trackers.  Trackers send a single response for
   each request though both requests and responses can be subject to
   fragmentation of messages in transport.

   The request messages of the base protocol are listed in Table 1:

             +------------------------------+
             | PPSTP Request Messages       |
             +------------------------------+
             | CONNECT                      |
             | FIND                         |
             | STAT_REPORT                  |
             +------------------------------+

                Table 1: Request Messages

   CONNECT:
      This request message is used when a peer registers in the tracker
      to notify it about participation in the named swarm(s).  If the
      peer is already registered in the tracker, this request message
      simply notifies the tracker about participation in the named
      swarm(s).  The tracker records the peer ID, connect-time
      (referenced to the absolute time), peer IP addresses (and
      associated location information), link status, and peer mode for
      the named swarm(s).  The tracker also changes the content
      availability of the valid named swarm(s), i.e., changes the peer's
      lists of the corresponding swarm(s) for the requesting peer ID.
      On receiving a CONNECT message, the tracker first checks the peer
      mode type (SEEDER/LEECH) for the specified swarm(s) and then
      decides the next steps (see Section 4.1 for more details).

   FIND:
      This request message is used by peers to request a list of peers
      active in the named swarm from the tracker whenever needed.  On
      receiving a FIND message, the tracker finds the peers listed in
      the content status of the specified swarm that can satisfy the
      requesting peer's requirements and returns the list to the

Top      ToC       Page 12 
      requesting peer.  To create the peer list, the tracker may take
      peer status, capabilities, and peer priority into consideration.
      Peer priority may be determined by network topology preference,
      operator policy preference, etc.

   STAT_REPORT:
      This request message is used to allow an active peer to send
      status (and optionally statistic data) to the tracker to signal
      continuing activity.  This request message MUST be sent
      periodically to the tracker while the peer is active in the
      system.

2.3.  State Machines and Flows of the Protocol

   The state machine for the tracker is very simple, as shown in Figure
   4.  Peer ID registrations represent a dynamic piece of state
   maintained by the network.

            --------------------------------------------
           /                                            \
          |  +------------+    +=========+    +======+   |
           \-| TERMINATED |<---| STARTED |<---| INIT |<-/
             +------------+    +=========+    +======+
              (Transient)                         \- (start tracker)

                Figure 4:  Tracker State Machine

   When there are no peers connected in the tracker, the state machine
   is in INIT state.

   When the first peer connects to register with its peer ID, the state
   machine moves from INIT to STARTED.  As long as there is at least one
   active registration of a peer ID, the state machine remains in
   STARTED state.  When the last peer ID is removed, the state machine
   transitions to TERMINATED.  From there, it immediately transitions
   back to INIT state.  Because of this, TERMINATED state is transient.

   Once in STARTED state, each peer is instantiated (per peer ID) in the
   tracker state machine with a dedicated transaction state machine
   (Figure 5), which is deleted when the peer ID is removed.

Top      ToC       Page 13 
                --------------------------------------------
               /                                            \
              |  +------------+    +=========+    +======+   |
               \-| TERMINATED |<---| STARTED |<---| INIT |<-/
                 +------------+    +=========+    +======+
                  (Transient)           | (1)        \- (start tracker)
                                        V
                      +-----------+   +-------+  rcv CONNECT
          (Transient) | TERMINATE |   | START |  --------------- (1)
                      +-----------+   +-------+  strt init timer
    rcv FIND        (B)      ^            |
    rcv STAT_REPORT (B)      |            |
    on registration error (B)|            v
    on action error (A)      |   +------------+
    ----------------         +<--| PEER       | (Transient)
    stop init timer          |   | REGISTERED |
    snd error                |   +------------+
                             |         |
    on timeout       (D)     |         |   process swarm actions
    ----------------         |         |   --------------------- (2)
    stop track timer         |         |   snd OK (PeerList)
    clean peer info          |        /    stop init timer
    del registration         |       /     strt track timer
                             |      /
                             |     |
                             |     |             rcv FIND
    STAT_REPORT ERR(C)        \    |     ----    --------------- (3)
    FIND ERR(C)      ----      \   |   /      \  snd OK (PeerList)
    CONNECT ERR(C) /      \     |  |  |        | rst track timer
    rcv CONNECT   |  (4)   |    |  |  |        |
    -----------   |        v    |  v  v        | rcv STAT_REPORT
    snd OK         \     +==============+     /  --------------- (3)
    rst track timer  ----|   TRACKING   |----    snd OK response
    snd error (C)        +==============+        rst track timer

    Figure 5:  "Per-Peer-ID" State Machine and Flow Diagram

   Unlike the tracker state machine, which exists even when no peer IDs
   are registered, the "per-Peer-ID" State Machine is instantiated only
   when the peer ID starts registration in the tracker and is deleted
   when the peer ID is de-registered/removed.  This allows for an
   implementation optimization whereby the tracker can destroy the
   objects associated with the "per-Peer-ID" State Machine once it
   enters the TERMINATE state (Figure 5).

   When a new peer ID is added, the corresponding "per-Peer-ID" State
   Machine is instantiated, and it moves into the PEER REGISTERED state.
   Because of that, the START state here is transient.

Top      ToC       Page 14 
   When the peer ID is no longer bound to a registration, the "per-Peer-
   ID" State Machine moves to the TERMINATE state, and the state machine
   is destroyed.

   During the lifetime of streaming activity of a peer, the instantiated
   "per-Peer-ID" State Machine progresses from one state to another in
   response to various events.  The events that may potentially advance
   the state include:

   o  Reception of CONNECT, FIND, and STAT_REPORT messages

   o  Timeout events

   The state diagram in Figure 5 illustrates state changes, together
   with the causing events and resulting actions.  Specific error
   conditions are not shown in the state diagram.

2.3.1.  Normal Operation

   For normal operation, the process consists of the following steps:

   1) When a peer wants to access the system, it needs to register with
      a tracker by sending a CONNECT message asking for the swarm(s) it
      wants to join.  This request from a new peer ID triggers the
      instantiation in the tracker of a "per-Peer-ID" State Machine.  In
      the START state of the new "per-Peer-ID" State Machine, the
      tracker registers the peer ID and associated information (IP
      addresses), starts the "init timer", and moves to PEER REGISTERED
      state.

   2) In PEER REGISTERED state, if the peer ID is valid, the tracker
      either:

      a) processes the requested action(s) for the valid swarm
         information contained in the CONNECT requests, and if
         successful, the tracker stops the "init timer", starts the
         "track timer", and sends the response to the peer (the response
         may contain the appropriate list of peers for the joining
         swarm(s), as detailed in Section 4.1), or

      b) moves the valid FIND request to TRACKING state.

   3) In TRACKING state, STAT_REPORT or FIND messages received from that
      peer ID will reset the "track timer", and the tracker responds to
      the requests with the following, respectively:

Top      ToC       Page 15 
      a) a successful condition, or

      b) a successful condition containing the appropriate list of peers
         for the named swarm (Section 4.2).

   4) While in TRACKING state, a CONNECT message received from that peer
      ID with valid swarm action information (Section 4.1.1) resets the
      "track timer", and the tracker responds to the request with a
      successful condition.

2.3.2.  Error Conditions

   Peers are required not to generate protocol elements that are
   invalid.  However, several situations may lead to abnormal conditions
   in the interaction with the tracker.  These situations may be related
   to peer malfunction or communication errors.  The tracker reacts to
   these abnormal situations depending on its current state related to a
   peer ID, as follows:

   A) In PEER REGISTERED state, when a CONNECT request only contains
      invalid swarm actions (Section 4.1.1), the tracker responds with a
      PPSTP error code as specified in Section 4.3, deletes the
      registration, and transitions to TERMINATE state for that peer ID.
      The state machine is destroyed.

   B) In PEER REGISTERED state, if the peer ID is considered invalid (in
      the case of a CONNECT request or in the case of FIND or
      STAT_REPORT requests received from an unregistered peer ID), the
      tracker responds with either a 06 (Authentication Required)
      error_code or a 03 (Forbidden Action) error_code as described in
      Section 4.3 and transitions to TERMINATE state for that peer ID.
      The state machine is destroyed.

   C) In TRACKING state (while the "track timer" has not expired),
      receiving a CONNECT message from a peer ID with invalid swarm
      actions (Section 4.1.1) or receiving a FIND/STAT_REPORT message
      from a peer ID with an invalid swarm ID is considered an error
      condition.  The tracker responds with the corresponding error code
      (described in Section 4.3).

   D) In TRACKING state, without receiving messages from the peer on
      timeout (the "track timer" has expired), the tracker cleans all
      the information associated with the peer ID in all swarms it was
      joined, deletes the registration, and transitions to TERMINATE
      state for that peer ID.  The state machine is destroyed.

Top      ToC       Page 16 
   NOTE:  These situations may correspond to malfunctions at the peer or
   to malicious conditions.  As a preventive measure, the tracker
   proceeds to TERMINATE state for that peer ID.



(page 16 continued on part 2)

Next RFC Part