tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 6940

 Errata 
Proposed STD
Pages: 176
Top     in Index     Prev     Next
in Group Index     No Prev: Lowest Number in Group     Next in Group     Group: P2PSIP

REsource LOcation And Discovery (RELOAD) Base Protocol

Part 1 of 7, p. 1 to 18
None       Next RFC Part

 


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                       C. Jennings
Request for Comments: 6940                                         Cisco
Category: Standards Track                               B. Lowekamp, Ed.
ISSN: 2070-1721                                                    Skype
                                                             E. Rescorla
                                                              RTFM, Inc.
                                                                S. Baset
                                                          H. Schulzrinne
                                                     Columbia University
                                                            January 2014


         REsource LOcation And Discovery (RELOAD) Base Protocol

Abstract

   This specification defines REsource LOcation And Discovery (RELOAD),
   a peer-to-peer (P2P) signaling protocol for use on the Internet.  A
   P2P signaling protocol provides its clients with an abstract storage
   and messaging service between a set of cooperating peers that form
   the overlay network.  RELOAD is designed to support a P2P Session
   Initiation Protocol (P2PSIP) network, but can be utilized by other
   applications with similar requirements by defining new usages that
   specify the Kinds of data that need to be stored for a particular
   application.  RELOAD defines a security model based on a certificate
   enrollment service that provides unique identities.  NAT traversal is
   a fundamental service of the protocol.  RELOAD also allows access
   from "client" nodes that do not need to route traffic or store data
   for others.

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 5741.

   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/rfc6940.

Page 2 
Copyright Notice

   Copyright (c) 2014 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.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   7
     1.1.  Basic Setting . . . . . . . . . . . . . . . . . . . . . .   8
     1.2.  Architecture  . . . . . . . . . . . . . . . . . . . . . .  10
       1.2.1.  Usage Layer . . . . . . . . . . . . . . . . . . . . .  13
       1.2.2.  Message Transport . . . . . . . . . . . . . . . . . .  13
       1.2.3.  Storage . . . . . . . . . . . . . . . . . . . . . . .  14
       1.2.4.  Topology Plug-in  . . . . . . . . . . . . . . . . . .  15
       1.2.5.  Forwarding and Link Management Layer  . . . . . . . .  16
     1.3.  Security  . . . . . . . . . . . . . . . . . . . . . . . .  16
     1.4.  Structure of This Document  . . . . . . . . . . . . . . .  17
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .  18
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .  18
   4.  Overlay Management Overview . . . . . . . . . . . . . . . . .  21
     4.1.  Security and Identification . . . . . . . . . . . . . . .  21
       4.1.1.  Shared-Key Security . . . . . . . . . . . . . . . . .  23
     4.2.  Clients . . . . . . . . . . . . . . . . . . . . . . . . .  23
       4.2.1.  Client Routing  . . . . . . . . . . . . . . . . . . .  24
       4.2.2.  Minimum Functionality Requirements for Clients  . . .  25
     4.3.  Routing . . . . . . . . . . . . . . . . . . . . . . . . .  25

Top      ToC       Page 3 
     4.4.  Connectivity Management . . . . . . . . . . . . . . . . .  29
     4.5.  Overlay Algorithm Support . . . . . . . . . . . . . . . .  30
       4.5.1.  Support for Pluggable Overlay Algorithms  . . . . . .  30
       4.5.2.  Joining, Leaving, and Maintenance Overview  . . . . .  30
     4.6.  First-Time Setup  . . . . . . . . . . . . . . . . . . . .  32
       4.6.1.  Initial Configuration . . . . . . . . . . . . . . . .  32
       4.6.2.  Enrollment  . . . . . . . . . . . . . . . . . . . . .  32
       4.6.3.  Diagnostics . . . . . . . . . . . . . . . . . . . . .  33
   5.  Application Support Overview  . . . . . . . . . . . . . . . .  33
     5.1.  Data Storage  . . . . . . . . . . . . . . . . . . . . . .  33
       5.1.1.  Storage Permissions . . . . . . . . . . . . . . . . .  34
       5.1.2.  Replication . . . . . . . . . . . . . . . . . . . . .  35
     5.2.  Usages  . . . . . . . . . . . . . . . . . . . . . . . . .  36
     5.3.  Service Discovery . . . . . . . . . . . . . . . . . . . .  36
     5.4.  Application Connectivity  . . . . . . . . . . . . . . . .  36
   6.  Overlay Management Protocol . . . . . . . . . . . . . . . . .  37
     6.1.  Message Receipt and Forwarding  . . . . . . . . . . . . .  37
       6.1.1.  Responsible ID  . . . . . . . . . . . . . . . . . . .  38
       6.1.2.  Other ID  . . . . . . . . . . . . . . . . . . . . . .  38
       6.1.3.  Opaque ID . . . . . . . . . . . . . . . . . . . . . .  40
     6.2.  Symmetric Recursive Routing . . . . . . . . . . . . . . .  41
       6.2.1.  Request Origination . . . . . . . . . . . . . . . . .  41
       6.2.2.  Response Origination  . . . . . . . . . . . . . . . .  42
     6.3.  Message Structure . . . . . . . . . . . . . . . . . . . .  42
       6.3.1.  Presentation Language . . . . . . . . . . . . . . . .  43
         6.3.1.1.  Common Definitions  . . . . . . . . . . . . . . .  44
       6.3.2.  Forwarding Header . . . . . . . . . . . . . . . . . .  46
         6.3.2.1.  Processing Configuration Sequence Numbers . . . .  49
         6.3.2.2.  Destination and Via Lists . . . . . . . . . . . .  50
         6.3.2.3.  Forwarding Option . . . . . . . . . . . . . . . .  52
       6.3.3.  Message Contents Format . . . . . . . . . . . . . . .  53
         6.3.3.1.  Response Codes and Response Errors  . . . . . . .  54
       6.3.4.  Security Block  . . . . . . . . . . . . . . . . . . .  57
     6.4.  Overlay Topology  . . . . . . . . . . . . . . . . . . . .  60
       6.4.1.  Topology Plug-in Requirements . . . . . . . . . . . .  60
       6.4.2.  Methods and Types for Use by Topology Plug-ins  . . .  61
         6.4.2.1.  Join  . . . . . . . . . . . . . . . . . . . . . .  61
         6.4.2.2.  Leave . . . . . . . . . . . . . . . . . . . . . .  62
         6.4.2.3.  Update  . . . . . . . . . . . . . . . . . . . . .  63
         6.4.2.4.  RouteQuery  . . . . . . . . . . . . . . . . . . .  63
         6.4.2.5.  Probe . . . . . . . . . . . . . . . . . . . . . .  65
     6.5.  Forwarding and Link Management Layer  . . . . . . . . . .  67
       6.5.1.  Attach  . . . . . . . . . . . . . . . . . . . . . . .  67
         6.5.1.1.  Request Definition  . . . . . . . . . . . . . . .  68
         6.5.1.2.  Response Definition . . . . . . . . . . . . . . .  70
         6.5.1.3.  Using ICE with RELOAD . . . . . . . . . . . . . .  71
         6.5.1.4.  Collecting STUN Servers . . . . . . . . . . . . .  71
         6.5.1.5.  Gathering Candidates  . . . . . . . . . . . . . .  72

Top      ToC       Page 4 
         6.5.1.6.  Prioritizing Candidates . . . . . . . . . . . . .  72
         6.5.1.7.  Encoding the Attach Message . . . . . . . . . . .  73
         6.5.1.8.  Verifying ICE Support . . . . . . . . . . . . . .  74
         6.5.1.9.  Role Determination  . . . . . . . . . . . . . . .  74
         6.5.1.10. Full ICE  . . . . . . . . . . . . . . . . . . . .  74
         6.5.1.11. No-ICE  . . . . . . . . . . . . . . . . . . . . .  75
         6.5.1.12. Subsequent Offers and Answers . . . . . . . . . .  75
         6.5.1.13. Sending Media . . . . . . . . . . . . . . . . . .  75
         6.5.1.14. Receiving Media . . . . . . . . . . . . . . . . .  75
       6.5.2.  AppAttach . . . . . . . . . . . . . . . . . . . . . .  75
         6.5.2.1.  Request Definition  . . . . . . . . . . . . . . .  76
         6.5.2.2.  Response Definition . . . . . . . . . . . . . . .  77
       6.5.3.  Ping  . . . . . . . . . . . . . . . . . . . . . . . .  77
         6.5.3.1.  Request Definition  . . . . . . . . . . . . . . .  77
         6.5.3.2.  Response Definition . . . . . . . . . . . . . . .  77
       6.5.4.  ConfigUpdate  . . . . . . . . . . . . . . . . . . . .  78
         6.5.4.1.  Request Definition  . . . . . . . . . . . . . . .  78
         6.5.4.2.  Response Definition . . . . . . . . . . . . . . .  79
     6.6.  Overlay Link Layer  . . . . . . . . . . . . . . . . . . .  80
       6.6.1.  Future Overlay Link Protocols . . . . . . . . . . . .  81
         6.6.1.1.  HIP . . . . . . . . . . . . . . . . . . . . . . .  82
         6.6.1.2.  ICE-TCP . . . . . . . . . . . . . . . . . . . . .  82
         6.6.1.3.  Message-Oriented Transports . . . . . . . . . . .  82
         6.6.1.4.  Tunneled Transports . . . . . . . . . . . . . . .  82
       6.6.2.  Framing Header  . . . . . . . . . . . . . . . . . . .  83
       6.6.3.  Simple Reliability  . . . . . . . . . . . . . . . . .  84
         6.6.3.1.  Stop and Wait Sender Algorithm  . . . . . . . . .  85
       6.6.4.  DTLS/UDP with SR  . . . . . . . . . . . . . . . . . .  86
       6.6.5.  TLS/TCP with FH, No-ICE . . . . . . . . . . . . . . .  86
       6.6.6.  DTLS/UDP with SR, No-ICE  . . . . . . . . . . . . . .  87
     6.7.  Fragmentation and Reassembly  . . . . . . . . . . . . . .  87
   7.  Data Storage Protocol . . . . . . . . . . . . . . . . . . . .  88
     7.1.  Data Signature Computation  . . . . . . . . . . . . . . .  90
     7.2.  Data Models . . . . . . . . . . . . . . . . . . . . . . .  91
       7.2.1.  Single Value  . . . . . . . . . . . . . . . . . . . .  91
       7.2.2.  Array . . . . . . . . . . . . . . . . . . . . . . . .  92
       7.2.3.  Dictionary  . . . . . . . . . . . . . . . . . . . . .  92
     7.3.  Access Control Policies . . . . . . . . . . . . . . . . .  93
       7.3.1.  USER-MATCH  . . . . . . . . . . . . . . . . . . . . .  93
       7.3.2.  NODE-MATCH  . . . . . . . . . . . . . . . . . . . . .  93
       7.3.3.  USER-NODE-MATCH . . . . . . . . . . . . . . . . . . .  93
       7.3.4.  NODE-MULTIPLE . . . . . . . . . . . . . . . . . . . .  94
     7.4.  Data Storage Methods  . . . . . . . . . . . . . . . . . .  94
       7.4.1.  Store . . . . . . . . . . . . . . . . . . . . . . . .  94
         7.4.1.1.  Request Definition  . . . . . . . . . . . . . . .  94
         7.4.1.2.  Response Definition . . . . . . . . . . . . . . . 100
         7.4.1.3.  Removing Values . . . . . . . . . . . . . . . . . 101

Top      ToC       Page 5 
       7.4.2.  Fetch . . . . . . . . . . . . . . . . . . . . . . . . 102
         7.4.2.1.  Request Definition  . . . . . . . . . . . . . . . 102
         7.4.2.2.  Response Definition . . . . . . . . . . . . . . . 104
       7.4.3.  Stat  . . . . . . . . . . . . . . . . . . . . . . . . 105
         7.4.3.1.  Request Definition  . . . . . . . . . . . . . . . 105
         7.4.3.2.  Response Definition . . . . . . . . . . . . . . . 106
       7.4.4.  Find  . . . . . . . . . . . . . . . . . . . . . . . . 107
         7.4.4.1.  Request Definition  . . . . . . . . . . . . . . . 108
         7.4.4.2.  Response Definition . . . . . . . . . . . . . . . 108
       7.4.5.  Defining New Kinds  . . . . . . . . . . . . . . . . . 109
   8.  Certificate Store Usage . . . . . . . . . . . . . . . . . . . 110
   9.  TURN Server Usage . . . . . . . . . . . . . . . . . . . . . . 110
   10. Chord Algorithm . . . . . . . . . . . . . . . . . . . . . . . 112
     10.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . 113
     10.2.  Hash Function  . . . . . . . . . . . . . . . . . . . . . 114
     10.3.  Routing  . . . . . . . . . . . . . . . . . . . . . . . . 114
     10.4.  Redundancy . . . . . . . . . . . . . . . . . . . . . . . 114
     10.5.  Joining  . . . . . . . . . . . . . . . . . . . . . . . . 115
     10.6.  Routing Attaches . . . . . . . . . . . . . . . . . . . . 116
     10.7.  Updates  . . . . . . . . . . . . . . . . . . . . . . . . 117
       10.7.1.  Handling Neighbor Failures . . . . . . . . . . . . . 118
       10.7.2.  Handling Finger Table Entry Failure  . . . . . . . . 119
       10.7.3.  Receiving Updates  . . . . . . . . . . . . . . . . . 119
       10.7.4.  Stabilization  . . . . . . . . . . . . . . . . . . . 120
         10.7.4.1.  Updating the Neighbor Table  . . . . . . . . . . 120
         10.7.4.2.  Refreshing the Finger Table  . . . . . . . . . . 121
         10.7.4.3.  Adjusting Finger Table Size  . . . . . . . . . . 122
         10.7.4.4.  Detecting Partitioning . . . . . . . . . . . . . 122
     10.8.  Route Query  . . . . . . . . . . . . . . . . . . . . . . 123
     10.9.  Leaving  . . . . . . . . . . . . . . . . . . . . . . . . 123
   11. Enrollment and Bootstrap  . . . . . . . . . . . . . . . . . . 124
     11.1.  Overlay Configuration  . . . . . . . . . . . . . . . . . 124
       11.1.1.  RELAX NG Grammar . . . . . . . . . . . . . . . . . . 132
     11.2.  Discovery through Configuration Server . . . . . . . . . 134
     11.3.  Credentials  . . . . . . . . . . . . . . . . . . . . . . 135
       11.3.1.  Self-Generated Credentials . . . . . . . . . . . . . 137
     11.4.  Contacting a Bootstrap Node  . . . . . . . . . . . . . . 138
   12. Message Flow Example  . . . . . . . . . . . . . . . . . . . . 138
   13. Security Considerations . . . . . . . . . . . . . . . . . . . 144
     13.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . 144
     13.2.  Attacks on P2P Overlays  . . . . . . . . . . . . . . . . 145
     13.3.  Certificate-Based Security . . . . . . . . . . . . . . . 145
     13.4.  Shared-Secret Security . . . . . . . . . . . . . . . . . 147
     13.5.  Storage Security . . . . . . . . . . . . . . . . . . . . 147
       13.5.1.  Authorization  . . . . . . . . . . . . . . . . . . . 147
       13.5.2.  Distributed Quota  . . . . . . . . . . . . . . . . . 148
       13.5.3.  Correctness  . . . . . . . . . . . . . . . . . . . . 148
       13.5.4.  Residual Attacks . . . . . . . . . . . . . . . . . . 149

Top      ToC       Page 6 
     13.6.  Routing Security . . . . . . . . . . . . . . . . . . . . 149
       13.6.1.  Background . . . . . . . . . . . . . . . . . . . . . 150
       13.6.2.  Admissions Control . . . . . . . . . . . . . . . . . 150
       13.6.3.  Peer Identification and Authentication . . . . . . . 151
       13.6.4.  Protecting the Signaling . . . . . . . . . . . . . . 151
       13.6.5.  Routing Loops and DoS Attacks  . . . . . . . . . . . 152
       13.6.6.  Residual Attacks . . . . . . . . . . . . . . . . . . 152
   14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 153
     14.1.  Well-Known URI Registration  . . . . . . . . . . . . . . 153
     14.2.  Port Registrations . . . . . . . . . . . . . . . . . . . 153
     14.3.  Overlay Algorithm Types  . . . . . . . . . . . . . . . . 154
     14.4.  Access Control Policies  . . . . . . . . . . . . . . . . 154
     14.5.  Application-ID . . . . . . . . . . . . . . . . . . . . . 155
     14.6.  Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . 155
     14.7.  Data Model . . . . . . . . . . . . . . . . . . . . . . . 156
     14.8.  Message Codes  . . . . . . . . . . . . . . . . . . . . . 156
     14.9.  Error Codes  . . . . . . . . . . . . . . . . . . . . . . 158
     14.10. Overlay Link Types . . . . . . . . . . . . . . . . . . . 159
     14.11. Overlay Link Protocols . . . . . . . . . . . . . . . . . 159
     14.12. Forwarding Options . . . . . . . . . . . . . . . . . . . 160
     14.13. Probe Information Types  . . . . . . . . . . . . . . . . 160
     14.14. Message Extensions . . . . . . . . . . . . . . . . . . . 161
     14.15. Reload URI Scheme  . . . . . . . . . . . . . . . . . . . 161
       14.15.1.  URI Registration  . . . . . . . . . . . . . . . . . 162
     14.16. Media Type Registration  . . . . . . . . . . . . . . . . 162
     14.17. XML Namespace Registration . . . . . . . . . . . . . . . 163
       14.17.1.  Config URL  . . . . . . . . . . . . . . . . . . . . 164
       14.17.2.  Config Chord URL  . . . . . . . . . . . . . . . . . 164
   15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 164
   16. References  . . . . . . . . . . . . . . . . . . . . . . . . . 165
     16.1.  Normative References . . . . . . . . . . . . . . . . . . 165
     16.2.  Informative References . . . . . . . . . . . . . . . . . 167
   Appendix A.  Routing Alternatives . . . . . . . . . . . . . . . . 171
     A.1.  Iterative vs. Recursive . . . . . . . . . . . . . . . . . 171
     A.2.  Symmetric vs. Forward Response  . . . . . . . . . . . . . 171
     A.3.  Direct Response . . . . . . . . . . . . . . . . . . . . . 172
     A.4.  Relay Peers . . . . . . . . . . . . . . . . . . . . . . . 173
     A.5.  Symmetric Route Stability . . . . . . . . . . . . . . . . 173
   Appendix B.  Why Clients? . . . . . . . . . . . . . . . . . . . . 174
     B.1.  Why Not Only Peers? . . . . . . . . . . . . . . . . . . . 174
     B.2.  Clients as Application-Level Agents . . . . . . . . . . . 175

Top      ToC       Page 7 
1.  Introduction

   This document defines REsource LOcation And Discovery (RELOAD), a
   peer-to-peer (P2P) signaling protocol for use on the Internet.
   RELOAD provides a generic, self-organizing overlay network service,
   allowing nodes to route messages to other nodes and to store and
   retrieve data in the overlay.  RELOAD provides several features that
   are critical for a successful P2P protocol for the Internet:

   Security Framework:  A P2P network will often be established among a
      set of peers that do not trust each other.  RELOAD leverages a
      central enrollment server to provide credentials for each peer,
      which can then be used to authenticate each operation.  This
      greatly reduces the possible attack surface.

   Usage Model:  RELOAD is designed to support a variety of
      applications, including P2P multimedia communications with the
      Session Initiation Protocol (SIP) [SIP-RELOAD].  RELOAD allows the
      definition of new application usages, each of which can define its
      own data types, along with the rules for their use.  This allows
      RELOAD to be used with new applications through a simple
      documentation process that supplies the details for each
      application.

   NAT Traversal:  RELOAD is designed to function in environments where
      many, if not most, of the nodes are behind NATs or firewalls.
      Operations for NAT traversal are part of the base design,
      including using Interactive Connectivity Establishment (ICE)
      [RFC5245] to establish new RELOAD or application protocol
      connections.

   Optimized Routing:  The very nature of overlay algorithms introduces
      a requirement that peers participating in the P2P network route
      requests on behalf of other peers in the network.  This introduces
      a load on those other peers in the form of bandwidth and
      processing power.  RELOAD has been defined with a simple,
      lightweight forwarding header, thus minimizing the amount of
      effort for intermediate peers.

   Pluggable Overlay Algorithms:  RELOAD has been designed with an
      abstract interface to the overlay layer to simplify implementing a
      variety of structured (e.g., distributed hash tables (DHTs)) and
      unstructured overlay algorithms.  The idea here is that RELOAD
      provides a generic structure that can fit most types of overlay
      topologies (ring, hyperspace, etc.).  To instantiate an actual
      network, you combine RELOAD with a specific overlay algorithm,
      which defines how to construct the overlay topology and route
      messages efficiently within it.  This specification also defines

Top      ToC       Page 8 
      how RELOAD is used with the Chord-based [Chord] DHT algorithm,
      which is mandatory to implement.  Specifying a default "mandatory-
      to-implement" overlay algorithm promotes interoperability, while
      extensibility allows selection of overlay algorithms optimized for
      a particular application.

   Support for Clients:  RELOAD clients differ from RELOAD peers
      primarily in that they do not store information on behalf of other
      nodes in the overlay.  Rather, they use the overlay only to locate
      users and resources, as well as to store information and to
      contact other nodes.

   These properties were designed specifically to meet the requirements
   for a P2P protocol to support SIP.  This document defines the base
   protocol for the distributed storage and location service, as well as
   critical usage for NAT traversal.  The SIP Usage itself is described
   separately in [SIP-RELOAD].  RELOAD is not limited to usage by SIP
   and could serve as a tool for supporting other P2P applications with
   similar needs.

1.1.  Basic Setting

   In this section, we provide a brief overview of the operational
   setting for RELOAD.  A RELOAD Overlay Instance consists of a set of
   nodes arranged in a partly connected graph.  Each node in the overlay
   is assigned a numeric Node-ID for the lifetime of the node, which,
   together with the specific overlay algorithm in use, determines its
   position in the graph and the set of nodes it connects to.  The
   Node-ID is also tightly coupled to the certificate (see
   Section 13.3).  The figure below shows a trivial example which isn't
   drawn from any particular overlay algorithm, but was chosen for
   convenience of representation.

Top      ToC       Page 9 
      +--------+              +--------+              +--------+
      | Node 10|--------------| Node 20|--------------| Node 30|
      +--------+              +--------+              +--------+
          |                       |                       |
          |                       |                       |
      +--------+              +--------+              +--------+
      | Node 40|--------------| Node 50|--------------| Node 60|
      +--------+              +--------+              +--------+
          |                       |                       |
          |                       |                       |
      +--------+              +--------+              +--------+
      | Node 70|--------------| Node 80|--------------| Node 90|
      +--------+              +--------+              +--------+
                                  |
                                  |
                              +--------+
                              | Node 85|
                              |(Client)|
                              +--------+

   Because the graph is not fully connected, when a node wants to send a
   message to another node, it may need to route it through the network.
   For instance, Node 10 can talk directly to nodes 20 and 40, but not
   to Node 70.  In order to send a message to Node 70, it would first
   send it to Node 40, with instructions to pass it along to Node 70.
   Different overlay algorithms will have different connectivity graphs,
   but the general idea behind all of them is to allow any node in the
   graph to efficiently reach every other node within a small number of
   hops.

   The RELOAD network is not only a messaging network.  It is also a
   storage network, albeit one designed for small-scale transient
   storage rather than for bulk storage of large objects.  Records are
   stored under numeric addresses, called Resource-IDs, which occupy the
   same space as node identifiers.  Peers are responsible for storing
   the data associated with some set of addresses, as determined by
   their Node-ID.  For instance, we might say that every peer is
   responsible for storing any data value which has an address less than
   or equal to its own Node-ID, but greater than the next lowest
   Node-ID.  Thus, Node 20 would be responsible for storing values
   11-20.

   RELOAD also supports clients.  These are nodes which have Node-IDs
   but do not participate in routing or storage.  For instance, in the
   figure above, Node 85 is a client.  It can route to the rest of the
   RELOAD network via Node 80, but no other node will route through it,
   and Node 90 is still responsible for addresses in the range [81..90].
   We refer to non-client nodes as peers.

Top      ToC       Page 10 
   Other applications (for instance, SIP) can be defined on top of
   RELOAD and can use these two basic RELOAD services to provide their
   own services.

1.2.  Architecture

   RELOAD is fundamentally an overlay network.  The following figure
   shows the layered RELOAD architecture.

            Application

        +-------+  +-------+
        | SIP   |  | XMPP  |  ...
        | Usage |  | Usage |
        +-------+  +-------+
    ------------------------------------ Messaging Service Boundary
    +------------------+     +---------+
    |     Message      |<--->| Storage |
    |    Transport     |     +---------+
    +------------------+           ^
           ^       ^               |
           |       v               v
           |     +-------------------+
           |     |    Topology       |
           |     |    Plug-in        |
           |     +-------------------+
           |         ^
           v         v
        +------------------+
        |  Forwarding &    |
        | Link Management  |
        +------------------+
    ------------------------------------ Overlay Link Service Boundary
         +-------+  +-------+
         |TLS    |  |DTLS   |  ...
         |Overlay|  |Overlay|
         |Link   |  |Link   |
         +-------+  +-------+

   The major components of RELOAD are:

   Usage Layer:  Each application defines a RELOAD Usage, which is a set
      of data Kinds and behaviors which describe how to use the services
      provided by RELOAD.  These usages all talk to RELOAD through a
      common Message Transport Service.

Top      ToC       Page 11 
   Message Transport:  Handles end-to-end reliability, manages request
      state for the usages, and forwards Store and Fetch operations to
      the Storage component.  It delivers message responses to the
      component initiating the request.

   Storage:  The Storage component is responsible for processing
      messages relating to the storage and retrieval of data.  It talks
      directly to the Topology Plug-in to manage data replication and
      migration, and it talks to the Message Transport component to send
      and receive messages.

   Topology Plug-in:  The Topology Plug-in is responsible for
      implementing the specific overlay algorithm being used.  It uses
      the Message Transport component to send and receive overlay
      management messages, the Storage component to manage data
      replication, and the Forwarding Layer to control hop-by-hop
      message forwarding.  This component superficially parallels
      conventional routing algorithms, but is more tightly coupled to
      the Forwarding Layer, because there is no single "Routing Table"
      equivalent used by all overlay algorithms.  The Topology Plug-in
      has two functions: constructing the local forwarding instructions
      and selecting the operational topology (i.e., creating links by
      sending overlay management messages).

   Forwarding and Link Management Layer:  Stores and implements the
      Routing Table by providing packet forwarding services between
      nodes.  It also handles establishing new links between nodes,
      including setting up connections for overlay links across NATs
      using ICE.

   Overlay Link Layer:  Responsible for actually transporting traffic
      directly between nodes.  Transport Layer Security (TLS) [RFC5246]
      and Datagram Transport Layer Security (DTLS) [RFC6347] are the
      currently defined "overlay link layer" protocols used by RELOAD
      for hop-by-hop communication.  Each such protocol includes the
      appropriate provisions for per-hop framing and hop-by-hop ACKs
      needed by unreliable underlying transports.  New protocols can be
      defined, as described in Sections 6.6.1 and 11.1.  As this
      document defines only TLS and DTLS, we use those terms throughout
      the remainder of the document with the understanding that some
      future specification may add new overlay link layers.

Top      ToC       Page 12 
   To further clarify the roles of the various layers, the following
   figure parallels the architecture with each layer's role from an
   overlay perspective and implementation layer in the Internet:

    Internet    | Internet Model  |
    Model       |   Equivalent    |          Reload
                |   in Overlay    |       Architecture
   -------------+-----------------+------------------------------------
                |                 |    +-------+  +-------+
                |  Application    |    | SIP   |  | XMPP  |  ...
                |                 |    | Usage |  | Usage |
                |                 |    +-------+  +-------+
                |                 |  ----------------------------------
                |                 |+------------------+     +---------+
                |   Transport     ||     Message      |<--->| Storage |
                |                 ||    Transport     |     +---------+
                |                 |+------------------+           ^
                |                 |       ^       ^               |
                |                 |       |       v               v
   Application  |                 |       |     +-------------------+
                |   (Routing)     |       |     |     Topology      |
                |                 |       |     |     Plug-in       |
                |                 |       |     +-------------------+
                |                 |       |         ^
                |                 |       v         v
                |    Network      |    +------------------+
                |                 |    |  Forwarding &    |
                |                 |    | Link Management  |
                |                 |    +------------------+
                |                 |  ----------------------------------
   Transport    |      Link       |     +-------+  +------+
                |                 |     |TLS    |  |DTLS  |  ...
                |                 |     +-------+  +------+
   -------------+-----------------+------------------------------------
     Network    |
                |
       Link     |

   In addition to the above components, nodes may communicate with a
   central provisioning infrastructure (not shown) to get configuration
   information, authentication credentials, and the initial set of nodes
   to communicate with to join the overlay.

Top      ToC       Page 13 
1.2.1.  Usage Layer

   The top layer, called the Usage Layer, has application usages, such
   as the SIP Registration Usage [SIP-RELOAD], that use the abstract
   Message Transport Service provided by RELOAD.  The goal of this layer
   is to implement application-specific usages of the generic overlay
   services provided by RELOAD.  The Usage defines how a specific
   application maps its data into something that can be stored in the
   overlay, where to store the data, how to secure the data, and finally
   how applications can retrieve and use the data.

   The architecture diagram shows both a SIP Usage and an XMPP Usage.  A
   single application may require multiple usages; for example, a
   voicemail feature in a softphone application that stores links to the
   messages in the overlay would require a different usage than the type
   of rendezvous service of XMPP or SIP.  A usage may define multiple
   Kinds of data that are stored in the overlay and may also rely on
   Kinds originally defined by other usages.

   Because the security and storage policies for each Kind are dictated
   by the usage defining the Kind, the usages may be coupled with the
   Storage component to provide security policy enforcement and to
   implement appropriate storage strategies according to the needs of
   the usage.  The exact implementation of such an interface is outside
   the scope of this specification.

1.2.2.  Message Transport

   The Message Transport component provides a generic message routing
   service for the overlay.  The Message Transport layer is responsible
   for end-to-end message transactions.  Each peer is identified by its
   location in the overlay, as determined by its Node-ID.  A component
   that is a client of the Message Transport can perform two basic
   functions:

   o  Send a message to a given peer specified by Node-ID or to the peer
      responsible for a particular Resource-ID.

   o  Receive messages that other peers sent to a Node-ID or Resource-ID
      for which the receiving peer is responsible.

   All usages rely on the Message Transport component to send and
   receive messages from peers.  For instance, when a usage wants to
   store data, it does so by sending Store requests.  Note that the
   Storage component and the Topology Plug-in are themselves clients of
   the Message Transport, because they need to send and receive messages
   from other peers.

Top      ToC       Page 14 
   The Message Transport Service is responsible for end-to-end
   reliability, which is accomplished by timer-based retransmissions.
   Unlike the Internet transport layer, however, this layer does not
   provide congestion control.  RELOAD is a request-response protocol,
   with no more than two pairs of request-response messages used in
   typical transactions between pairs of nodes; therefore, there are no
   opportunities to observe and react to end-to-end congestion.  As with
   all Internet applications, implementers are strongly discouraged from
   writing applications that react to loss by immediately retrying the
   transaction.

   The Message Transport Service is similar to those described as
   providing "key-based routing" (KBR) [wikiKBR], although as RELOAD
   supports different overlay algorithms (including non-DHT overlay
   algorithms) that calculate keys (storage indices, not encryption
   keys) in different ways, the actual interface needs to accept
   Resource Names rather than actual keys.

   The Forwarding and Link Management layers are responsible for
   maintaining the overlay in the face of changes in the available nodes
   and underlying network supporting the overlay (the Internet).  They
   also handle congestion control between overlay neighbors, and
   exchange routing updates and data replicas in addition to forwarding
   end-to-end messages.

   Real-world experience has shown that a fixed timeout for the end-to-
   end retransmission timer is sufficient for practical overlay
   networks.  This timer is adjustable via the overlay configuration.
   As the overlay configuration can be rapidly updated, this value could
   be dynamically adjusted at coarse time scales, although algorithms
   for determining how to accomplish this are beyond the scope of this
   specification.  In many cases, however, other means of improving
   network performance, such as having the Topology Plug-in remove lossy
   links from use in overlay routing or reducing the overall hop count
   of end-to-end paths, will be more effective than simply increasing
   the retransmission timer.

1.2.3.  Storage

   One of the major functions of RELOAD is storage of data, that is,
   allowing nodes to store data in the overlay and to retrieve data
   stored by other nodes or by themselves.  The Storage component is
   responsible for processing data storage and retrieval messages.  For
   instance, the Storage component might receive a Store request for a
   given resource from the Message Transport.  It would then query the
   appropriate usage before storing the data value(s) in its local data
   store and sending a response to the Message Transport for delivery to
   the requesting node.  Typically, these messages will come from other

Top      ToC       Page 15 
   nodes, but depending on the overlay topology, a node might be
   responsible for storing data for itself as well, especially if the
   overlay is small.

   A peer's Node-ID determines the set of resources that it will be
   responsible for storing.  However, the exact mapping between these is
   determined by the overlay algorithm in use.  The Storage component
   will only receive a Store request from the Message Transport if this
   peer is responsible for that Resource-ID.  The Storage component is
   notified by the Topology Plug-in when the Resource-IDs for which it
   is responsible change, and the Storage component is then responsible
   for migrating resources to other peers.

1.2.4.  Topology Plug-in

   RELOAD is explicitly designed to work with a variety of overlay
   algorithms.  In order to facilitate this, the overlay algorithm
   implementation is provided by a Topology Plug-in so that each overlay
   can select an appropriate overlay algorithm that relies on the common
   RELOAD core protocols and code.

   The Topology Plug-in is responsible for maintaining the overlay
   algorithm Routing Table, which is consulted by the Forwarding and
   Link Management Layer before routing a message.  When connections are
   made or broken, the Forwarding and Link Management Layer notifies the
   Topology Plug-in, which adjusts the Routing Table as appropriate.
   The Topology Plug-in will also instruct the Forwarding and Link
   Management Layer to form new connections as dictated by the
   requirements of the overlay algorithm Topology.  The Topology Plug-in
   issues periodic update requests through Message Transport to maintain
   and update its Routing Table.

   As peers enter and leave, resources may be stored on different peers,
   so the Topology Plug-in also keeps track of which peers are
   responsible for which resources.  As peers join and leave, the
   Topology Plug-in instructs the Storage component to issue resource
   migration requests as appropriate, in order to ensure that other
   peers have whatever resources they are now responsible for.  The
   Topology Plug-in is also responsible for providing for redundant data
   storage to protect against loss of information in the event of a peer
   failure and to protect against compromised or subversive peers.

Top      ToC       Page 16 
1.2.5.  Forwarding and Link Management Layer

   The Forwarding and Link Management Layer is responsible for getting a
   message to the next peer, as determined by the Topology Plug-in.
   This layer establishes and maintains the network connections as
   needed by the Topology Plug-in.  This layer is also responsible for
   setting up connections to other peers through NATs and firewalls
   using ICE, and it can elect to forward traffic using relays for NAT
   and firewall traversal.

   Congestion control is implemented at this layer to protect the
   Internet paths used to form the link in the overlay.  Additionally,
   retransmission is performed to improve the reliability of end-to-end
   transactions.  The relation of this layer to the Message Transport
   Layer can be likened to the relation of the link-level congestion
   control and retransmission in modern wireless networks ` to Internet
   transport protocols.

   This layer provides a generic interface that allows the Topology
   Plug-in to control the overlay and resource operations and messages.
   Because each overlay algorithm is defined and functions differently,
   we generically refer to the table of other peers that the overlay
   algorithm maintains and uses to route requests as a Routing Table.
   The Topology Plug-in actually owns the Routing Table, and forwarding
   decisions are made by querying the Topology Plug-in for the next hop
   for a particular Node-ID or Resource-ID.  If this node is the
   destination of the message, the message is delivered to the Message
   Transport.

   This layer also utilizes a framing header to encapsulate messages as
   they are forwarded along each hop.  This header aids reliability
   congestion control, flow control, etc.  It has meaning only in the
   context of that individual link.

   The Forwarding and Link Management Layer sits on top of the Overlay
   Link Layer protocols that carry the actual traffic.  This
   specification defines how to use DTLS and TLS protocols to carry
   RELOAD messages.

1.3.  Security

   RELOAD's security model is based on each node having one or more
   public key certificates.  In general, these certificates will be
   assigned by a central server, which also assigns Node-IDs, although
   self-signed certificates can be used in closed networks.  These
   credentials can be leveraged to provide communications security for
   RELOAD messages.  RELOAD provides communications security at three
   levels:

Top      ToC       Page 17 
   Connection level:  Connections between nodes are secured with TLS,
      DTLS, or potentially some to-be-defined future protocol.

   Message level:  Each RELOAD message is signed.

   Object Level:  Stored objects are signed by the creating node.

   These three levels of security work together to allow nodes to verify
   the origin and correctness of data they receive from other nodes,
   even in the face of malicious activity by other nodes in the overlay.
   RELOAD also provides access control built on top of these
   communications security features.  Because the peer responsible for
   storing a piece of data can validate the signature on the data being
   stored, it can determine whether or not a given operation is
   permitted.

   RELOAD also provides an optional shared-secret-based admission
   control feature using shared secrets and TLS pre-shared keys (PSK) or
   TLS Secure Remote Password (SRP).  In order to form a TLS connection
   to any node in the overlay, a new node needs to know the shared
   overlay key, thus restricting access to authorized users only.  This
   feature is used together with certificate-based access control, not
   as a replacement for it.  It is typically used when self-signed
   certificates are being used but would generally not be used when the
   certificates were all signed by an enrollment server.

1.4.  Structure of This Document

   The remainder of this document is structured as follows.

   o  Section 3 provides definitions of terms used in this document.

   o  Section 4 provides an overview of the mechanisms used to establish
      and maintain the overlay.

   o  Section 5 provides an overview of the mechanism RELOAD provides to
      support other applications.

   o  Section 6 defines the protocol messages that RELOAD uses to
      establish and maintain the overlay.

   o  Section 7 defines the protocol messages that are used to store and
      retrieve data using RELOAD.

   o  Section 8 defines the Certificate Store Usages.

   o  Section 9 defines the TURN Server Usage needed to locate TURN
      (Traversal Using Relays around NAT) servers for NAT traversal.

Top      ToC       Page 18 
   o  Section 10 defines a specific Topology Plug-in using a Chord-based
      algorithm.

   o  Section 11 defines the mechanisms that new RELOAD nodes use to
      join the overlay for the first time.

   o  Section 12 provides an extended example.

2.  Requirements Language

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



(page 18 continued on part 2)

Next RFC Part