draft-ietf-p2psip-base-15.txt   draft-ietf-p2psip-base-16.txt 
P2PSIP C. Jennings P2PSIP C. Jennings
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track B. Lowekamp, Ed. Intended status: Standards Track B. Lowekamp, Ed.
Expires: November 28, 2011 Skype Expires: January 8, 2012 Skype
E. Rescorla E. Rescorla
RTFM, Inc. RTFM, Inc.
S. Baset S. Baset
H. Schulzrinne H. Schulzrinne
Columbia University Columbia University
May 27, 2011 July 7, 2011
REsource LOcation And Discovery (RELOAD) Base Protocol REsource LOcation And Discovery (RELOAD) Base Protocol
draft-ietf-p2psip-base-15 draft-ietf-p2psip-base-16
Abstract Abstract
This specification defines REsource LOcation And Discovery (RELOAD), This specification defines REsource LOcation And Discovery (RELOAD),
a peer-to-peer (P2P) signaling protocol for use on the Internet. A a peer-to-peer (P2P) signaling protocol for use on the Internet. A
P2P signaling protocol provides its clients with an abstract storage P2P signaling protocol provides its clients with an abstract storage
and messaging service between a set of cooperating peers that form and messaging service between a set of cooperating peers that form
the overlay network. RELOAD is designed to support a P2P Session the overlay network. RELOAD is designed to support a P2P Session
Initiation Protocol (P2PSIP) network, but can be utilized by other Initiation Protocol (P2PSIP) network, but can be utilized by other
applications with similar requirements by defining new usages that applications with similar requirements by defining new usages that
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 28, 2011. This Internet-Draft will expire on January 8, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 42 skipping to change at page 3, line 42
4. Application Support Overview . . . . . . . . . . . . . . . . 29 4. Application Support Overview . . . . . . . . . . . . . . . . 29
4.1. Data Storage . . . . . . . . . . . . . . . . . . . . . . 29 4.1. Data Storage . . . . . . . . . . . . . . . . . . . . . . 29
4.1.1. Storage Permissions . . . . . . . . . . . . . . . . 31 4.1.1. Storage Permissions . . . . . . . . . . . . . . . . 31
4.1.2. Replication . . . . . . . . . . . . . . . . . . . . 31 4.1.2. Replication . . . . . . . . . . . . . . . . . . . . 31
4.2. Usages . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.2. Usages . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3. Service Discovery . . . . . . . . . . . . . . . . . . . 33 4.3. Service Discovery . . . . . . . . . . . . . . . . . . . 33
4.4. Application Connectivity . . . . . . . . . . . . . . . . 33 4.4. Application Connectivity . . . . . . . . . . . . . . . . 33
5. Overlay Management Protocol . . . . . . . . . . . . . . . . . 33 5. Overlay Management Protocol . . . . . . . . . . . . . . . . . 33
5.1. Message Receipt and Forwarding . . . . . . . . . . . . . 33 5.1. Message Receipt and Forwarding . . . . . . . . . . . . . 33
5.1.1. Responsible ID . . . . . . . . . . . . . . . . . . . 34 5.1.1. Responsible ID . . . . . . . . . . . . . . . . . . . 34
5.1.2. Other ID . . . . . . . . . . . . . . . . . . . . . . 34 5.1.2. Other ID . . . . . . . . . . . . . . . . . . . . . . 35
5.1.3. Private ID . . . . . . . . . . . . . . . . . . . . . 36 5.1.3. Private ID . . . . . . . . . . . . . . . . . . . . . 36
5.2. Symmetric Recursive Routing . . . . . . . . . . . . . . 36 5.2. Symmetric Recursive Routing . . . . . . . . . . . . . . 37
5.2.1. Request Origination . . . . . . . . . . . . . . . . 37 5.2.1. Request Origination . . . . . . . . . . . . . . . . 37
5.2.2. Response Origination . . . . . . . . . . . . . . . . 37 5.2.2. Response Origination . . . . . . . . . . . . . . . . 38
5.3. Message Structure . . . . . . . . . . . . . . . . . . . 38 5.3. Message Structure . . . . . . . . . . . . . . . . . . . 38
5.3.1. Presentation Language . . . . . . . . . . . . . . . 39 5.3.1. Presentation Language . . . . . . . . . . . . . . . 39
5.3.1.1. Common Definitions . . . . . . . . . . . . . . . 39 5.3.1.1. Common Definitions . . . . . . . . . . . . . . . 39
5.3.2. Forwarding Header . . . . . . . . . . . . . . . . . 42 5.3.2. Forwarding Header . . . . . . . . . . . . . . . . . 42
5.3.2.1. Processing Configuration Sequence Numbers . . . . 44 5.3.2.1. Processing Configuration Sequence Numbers . . . . 44
5.3.2.2. Destination and Via Lists . . . . . . . . . . . . 45 5.3.2.2. Destination and Via Lists . . . . . . . . . . . . 45
5.3.2.3. Forwarding Options . . . . . . . . . . . . . . . 47 5.3.2.3. Forwarding Options . . . . . . . . . . . . . . . 47
5.3.3. Message Contents Format . . . . . . . . . . . . . . 48 5.3.3. Message Contents Format . . . . . . . . . . . . . . 48
5.3.3.1. Response Codes and Response Errors . . . . . . . 49 5.3.3.1. Response Codes and Response Errors . . . . . . . 49
5.3.4. Security Block . . . . . . . . . . . . . . . . . . . 51 5.3.4. Security Block . . . . . . . . . . . . . . . . . . . 51
skipping to change at page 8, line 48 skipping to change at page 8, line 48
network route requests on behalf of other peers in the network. network route requests on behalf of other peers in the network.
This introduces a load on those other peers, in the form of This introduces a load on those other peers, in the form of
bandwidth and processing power. RELOAD has been defined with a bandwidth and processing power. RELOAD has been defined with a
simple, lightweight forwarding header, thus minimizing the amount simple, lightweight forwarding header, thus minimizing the amount
of effort required by intermediate peers. of effort required by intermediate peers.
Pluggable Overlay Algorithms: RELOAD has been designed with an Pluggable Overlay Algorithms: RELOAD has been designed with an
abstract interface to the overlay layer to simplify implementing a abstract interface to the overlay layer to simplify implementing a
variety of structured (e.g., distributed hash tables) and variety of structured (e.g., distributed hash tables) and
unstructured overlay algorithms. This specification also defines unstructured overlay algorithms. This specification also defines
how RELOAD is used with the Chord DHT algorithm, which is how RELOAD is used with the Chord based DHT algorithm, which is
mandatory to implement. Specifying a default "must implement" mandatory to implement. Specifying a default "must implement"
overlay algorithm promotes interoperability, while extensibility overlay algorithm promotes interoperability, while extensibility
allows selection of overlay algorithms optimized for a particular allows selection of overlay algorithms optimized for a particular
application. application.
These properties were designed specifically to meet the requirements These properties were designed specifically to meet the requirements
for a P2P protocol to support SIP. This document defines the base for a P2P protocol to support SIP. This document defines the base
protocol for the distributed storage and location service, as well as protocol for the distributed storage and location service, as well as
critical usages for NAT traversal and security. The SIP Usage itself critical usages for NAT traversal and security. The SIP Usage itself
is described separately in [I-D.ietf-p2psip-sip]. RELOAD is not is described separately in [I-D.ietf-p2psip-sip]. RELOAD is not
skipping to change at page 12, line 25 skipping to change at page 12, line 25
Forwarding and Link Management Layer: Stores and implements the Forwarding and Link Management Layer: Stores and implements the
routing table by providing packet forwarding services between routing table by providing packet forwarding services between
nodes. It also handles establishing new links between nodes, nodes. It also handles establishing new links between nodes,
including setting up connections across NATs using ICE. including setting up connections across NATs using ICE.
Overlay Link Layer: Responsible for actually transporting traffic Overlay Link Layer: Responsible for actually transporting traffic
directly between nodes. Each such protocol includes the directly between nodes. Each such protocol includes the
appropriate provisions for per-hop framing or hop-by-hop ACKs appropriate provisions for per-hop framing or hop-by-hop ACKs
required by unreliable transports. TLS [RFC5246] and DTLS required by unreliable transports. TLS [RFC5246] and DTLS
[RFC4347] are the currently defined "link layer" protocols used by [RFC4347] are the currently defined "link layer" protocols used by
RELOAD for hop-by-hop communication. New protocols MAY be RELOAD for hop-by-hop communication. New protocols can be
defined, as described in Section 5.6.1 and Section 10.1. As this defined, as described in Section 5.6.1 and Section 10.1. As this
document defines only TLS and DTLS, we use those terms throughout document defines only TLS and DTLS, we use those terms throughout
the remainder of the document with the understanding that some the remainder of the document with the understanding that some
future specification may add new overlay link layers. future specification may add new overlay link layers.
To further clarify the roles of the various layers, this figure To further clarify the roles of the various layers, this figure
parallels the architecture with each layer's role from an overlay parallels the architecture with each layer's role from an overlay
perspective and implementation layer in the internet: perspective and implementation layer in the internet:
| Internet Model | | Internet Model |
skipping to change at page 13, line 52 skipping to change at page 13, line 52
as the SIP Registration Usage [I-D.ietf-p2psip-sip], that use the as the SIP Registration Usage [I-D.ietf-p2psip-sip], that use the
abstract Message Transport Service provided by RELOAD. The goal of abstract Message Transport Service provided by RELOAD. The goal of
this layer is to implement application-specific usages of the generic this layer is to implement application-specific usages of the generic
overlay services provided by RELOAD. The usage defines how a overlay services provided by RELOAD. The usage defines how a
specific application maps its data into something that can be stored 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 in the overlay, where to store the data, how to secure the data, and
finally how applications can retrieve and use the data. finally how applications can retrieve and use the data.
The architecture diagram shows both a SIP usage and an XMPP usage. A The architecture diagram shows both a SIP usage and an XMPP usage. A
single application may require multiple usages; for example a single application may require multiple usages; for example a
softphone application may also require a voicemail usage. An usage softphone application may also require a voicemail usage. A usage
may define multiple kinds of data that are stored in the overlay and may define multiple kinds of data that are stored in the overlay and
may also rely on kinds originally defined by other usages. may also rely on kinds originally defined by other usages.
Because the security and storage policies for each kind are dictated Because the security and storage policies for each kind are dictated
by the usage defining the kind, the usages may be coupled with the by the usage defining the kind, the usages may be coupled with the
Storage component to provide security policy enforcement and to Storage component to provide security policy enforcement and to
implement appropriate storage strategies according to the needs of implement appropriate storage strategies according to the needs of
the usage. The exact implementation of such an interface is outside the usage. The exact implementation of such an interface is outside
the scope of this specification. the scope of this specification.
skipping to change at page 17, line 31 skipping to change at page 17, line 31
o Section 4 provides an overview of the mechanism RELOAD provides to o Section 4 provides an overview of the mechanism RELOAD provides to
support other applications. support other applications.
o Section 5 defines the protocol messages that RELOAD uses to o Section 5 defines the protocol messages that RELOAD uses to
establish and maintain the overlay. establish and maintain the overlay.
o Section 6 defines the protocol messages that are used to store and o Section 6 defines the protocol messages that are used to store and
retrieve data using RELOAD. retrieve data using RELOAD.
o Section 7 defines the Certificate Store Usage that is fundamental o Section 7 defines the Certificate Store Usage that is fundamental
to RELOAD security. to RELOAD security.
o Section 8 defines the TURN Server Usage needed to locate TURN o Section 8 defines the TURN Server Usage needed to locate TURN
servers for NAT traversal. servers for NAT traversal.
o Section 9 defines a specific Topology Plugin using Chord. o Section 9 defines a specific Topology Plugin using Chord based
algorithm.
o Section 10 defines the mechanisms that new RELOAD nodes use to o Section 10 defines the mechanisms that new RELOAD nodes use to
join the overlay for the first time. join the overlay for the first time.
o Section 11 provides an extended example. o Section 11 provides an extended example.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
skipping to change at page 18, line 29 skipping to change at page 18, line 29
Peer: A host that is participating in the overlay. Peers are Peer: A host that is participating in the overlay. Peers are
responsible for holding some portion of the data that has been responsible for holding some portion of the data that has been
stored in the overlay and also route messages on behalf of other stored in the overlay and also route messages on behalf of other
hosts as required by the Overlay Algorithm. hosts as required by the Overlay Algorithm.
Client: A host that is able to store data in and retrieve data from Client: A host that is able to store data in and retrieve data from
the overlay but which is not participating in routing or data the overlay but which is not participating in routing or data
storage for the overlay. storage for the overlay.
Kind: A kind defines a particular type of data that can be stored in Kind: A kind defines a particular type of data that can be stored in
the overlay. Applications define new Kinds to story the data they the overlay. Applications define new Kinds to store the data they
use. Each Kind is identified with a unique integer called a use. Each Kind is identified with a unique integer called a
Kind-ID. Kind-ID.
Node: We use the term "Node" to refer to a host that may be either a Node: We use the term "Node" to refer to a host that may be either a
Peer or a Client. Because RELOAD uses the same protocol for both Peer or a Client. Because RELOAD uses the same protocol for both
clients and peers, much of the text applies equally to both. clients and peers, much of the text applies equally to both.
Therefore we use "Node" when the text applies to both Clients and Therefore we use "Node" when the text applies to both Clients and
Peers and the more specific term (i.e. client or peer) when the Peers and the more specific term (i.e. client or peer) when the
text applies only to Clients or only to Peers. text applies only to Clients or only to Peers.
skipping to change at page 19, line 10 skipping to change at page 19, line 10
Node-ID of all 1s is used on the wire protocol as a wildcard. Node-ID of all 1s is used on the wire protocol as a wildcard.
Resource: An object or group of objects associated with a string Resource: An object or group of objects associated with a string
identifier. See "Resource Name" below. identifier. See "Resource Name" below.
Resource Name: The potentially human readable name by which a Resource Name: The potentially human readable name by which a
resource is identified. In unstructured P2P networks, the resource is identified. In unstructured P2P networks, the
resource name is sometimes used directly as a Resource-ID. In resource name is sometimes used directly as a Resource-ID. In
structured P2P networks the resource name is typically mapped into structured P2P networks the resource name is typically mapped into
a Resource-ID by using the string as the input to hash function. a Resource-ID by using the string as the input to hash function.
A SIP resource, for example, is often identified by its AOR which Structured and unstructured P2P networks are described in
is an example of a Resource Name. [RFC5694]. A SIP resource, for example, is often identified by
its AOR which is an example of a Resource Name.
Resource-ID: A value that identifies some resources and which is Resource-ID: A value that identifies some resources and which is
used as a key for storing and retrieving the resource. Often this used as a key for storing and retrieving the resource. Often this
is not human friendly/readable. One way to generate a Resource-ID is not human friendly/readable. One way to generate a Resource-ID
is by applying a mapping function to some other unique name (e.g., is by applying a mapping function to some other unique name (e.g.,
user name or service name) for the resource. The Resource-ID is user name or service name) for the resource. The Resource-ID is
used by the distributed database algorithm to determine the peer used by the distributed database algorithm to determine the peer
or peers that are responsible for storing the data for the or peers that are responsible for storing the data for the
overlay. In structured P2P networks, Resource-IDs are generally overlay. In structured P2P networks, Resource-IDs are generally
fixed length and are formed by hashing the resource name. In fixed length and are formed by hashing the resource name. In
skipping to change at page 22, line 29 skipping to change at page 22, line 29
Clients may insert themselves in the overlay in two ways: Clients may insert themselves in the overlay in two ways:
o Establish a connection to the peer responsible for the client's o Establish a connection to the peer responsible for the client's
Node-ID in the overlay. Then requests may be sent from/to the Node-ID in the overlay. Then requests may be sent from/to the
client using its Node-ID in the same manner as if it were a peer, client using its Node-ID in the same manner as if it were a peer,
because the responsible peer in the overlay will handle the final because the responsible peer in the overlay will handle the final
step of routing to the client. This may require a TURN relay in step of routing to the client. This may require a TURN relay in
cases where NATs or firewalls prevent a client from forming a cases where NATs or firewalls prevent a client from forming a
direct connections with its responsible peer. Note that clients direct connections with its responsible peer. Note that clients
that choose this option MUST process Update messages from the that choose this option need to process Update messages from the
peer. Those updates can indicate that the peer no longer is peer. Those updates can indicate that the peer no longer is
responsible for the Client's Node-ID. The client then MUST form a responsible for the Client's Node-ID. The client would then need
connection to the appropriate peer. Failure to do so will result to form a connection to the appropriate peer. Failure to do so
in the client no longer receiving messages. will result in the client no longer receiving messages.
o Establish a connection with an arbitrary peer in the overlay o Establish a connection with an arbitrary peer in the overlay
(perhaps based on network proximity or an inability to establish a (perhaps based on network proximity or an inability to establish a
direct connection with the responsible peer). In this case, the direct connection with the responsible peer). In this case, the
client will rely on RELOAD's Destination List feature to ensure client will rely on RELOAD's Destination List feature to ensure
reachability. The client can initiate requests, and any node in reachability. The client can initiate requests, and any node in
the overlay that knows the Destination List to its current the overlay that knows the Destination List to its current
location can reach it, but the client is not directly reachable location can reach it, but the client is not directly reachable
using only its Node-ID. If the client is to receive incoming using only its Node-ID. If the client is to receive incoming
requests from other members of the overlay, the Destination List requests from other members of the overlay, the Destination List
required to reach it must be learnable via other mechanisms, such required to reach it must be learnable via other mechanisms, such
skipping to change at page 23, line 31 skipping to change at page 23, line 31
A client speaks the same protocol as the peers, knows how to A client speaks the same protocol as the peers, knows how to
calculate Resource-IDs, and signs its requests in the same manner as calculate Resource-IDs, and signs its requests in the same manner as
peers. While a client does not necessarily require a full peers. While a client does not necessarily require a full
implementation of the overlay algorithm, calculating the Resource-ID implementation of the overlay algorithm, calculating the Resource-ID
requires an implementation of the appropriate algorithm for the requires an implementation of the appropriate algorithm for the
overlay. overlay.
3.3. Routing 3.3. Routing
This section will discuss the requirements RELOAD's routing This section will discuss the requirements RELOAD's routing
capabilities must meet, then describe the routing features in the capabilities were designed to meet, then describe the routing
protocol, and then provide a brief overview of how they are used. features in the protocol, and then provide a brief overview of how
Appendix A discusses some alternative designs and the tradeoffs that they are used. Appendix A discusses some alternative designs and the
would be necessary to support them. tradeoffs that would be necessary to support them.
RELOAD's routing capabilities must meet the following requirements: RELOAD's routing capabilities must meet the following requirements:
NAT Traversal: RELOAD must support establishing and using NAT Traversal: RELOAD must support establishing and using
connections between nodes separated by one or more NATs, including connections between nodes separated by one or more NATs, including
locating peers behind NATs for those overlays allowing/requiring locating peers behind NATs for those overlays allowing/requiring
it. it.
Clients: RELOAD must support requests from and to clients that do Clients: RELOAD must support requests from and to clients that do
not participate in overlay routing. not participate in overlay routing.
Client promotion: RELOAD must support clients that become peers at a Client promotion: RELOAD must support clients that become peers at a
skipping to change at page 24, line 25 skipping to change at page 24, line 25
to by each node a message traverses. This via list can then be to by each node a message traverses. This via list can then be
inverted and used as a destination list for the response. inverted and used as a destination list for the response.
RouteQuery: The RouteQuery method allows a node to query a peer RouteQuery: The RouteQuery method allows a node to query a peer
for the next hop it will use to route a message. This method is for the next hop it will use to route a message. This method is
useful for diagnostics and for iterative routing. useful for diagnostics and for iterative routing.
The basic routing mechanism used by RELOAD is Symmetric Recursive. The basic routing mechanism used by RELOAD is Symmetric Recursive.
We will first describe symmetric recursive routing and then discuss We will first describe symmetric recursive routing and then discuss
its advantages in terms of the requirements discussed above. its advantages in terms of the requirements discussed above.
Symmetric recursive routing requires that a message follow a path Symmetric recursive routing requires that a request message follow a
through the overlay to the destination without returning to the path through the overlay to the destination: each peer forwards the
originating node: each peer forwards the message closer to its message closer to its destination. The return path of the response
destination. The return path of the response is then the same path is then the same path followed in reverse. For example, a message
followed in reverse. For example, a message following a route from A following a route from A to Z through B and X:
to Z through B and X:
A B X Z A B X Z
------------------------------- -------------------------------
----------> ---------->
Dest=Z Dest=Z
----------> ---------->
Via=A Via=A
Dest=Z Dest=Z
----------> ---------->
skipping to change at page 33, line 12 skipping to change at page 33, line 12
However, a need for different parameters, such as different size However, a need for different parameters, such as different size
limits, would imply the need to create a new kind. limits, would imply the need to create a new kind.
4.3. Service Discovery 4.3. Service Discovery
RELOAD does not currently define a generic service discovery RELOAD does not currently define a generic service discovery
algorithm as part of the base protocol, although a simplistic TURN- algorithm as part of the base protocol, although a simplistic TURN-
specific discovery mechanism is provided. A variety of service specific discovery mechanism is provided. A variety of service
discovery algorithms can be implemented as extensions to the base discovery algorithms can be implemented as extensions to the base
protocol, such as the service discovery algorithm ReDIR protocol, such as the service discovery algorithm ReDIR
[opendht-sigcomm05] or [I-D.maenpaa-p2psip-service-discovery]. [opendht-sigcomm05] or [I-D.ietf-p2psip-service-discovery].
4.4. Application Connectivity 4.4. Application Connectivity
There is no requirement that a RELOAD usage must use RELOAD's There is no requirement that a RELOAD usage must use RELOAD's
primitives for establishing its own communication if it already primitives for establishing its own communication if it already
possesses its own means of establishing connections. For example, possesses its own means of establishing connections. For example,
one could design a RELOAD-based resource discovery protocol which one could design a RELOAD-based resource discovery protocol which
used HTTP to retrieve the actual data. used HTTP to retrieve the actual data.
For more common situations, however, it is the overlay itself - For more common situations, however, it is the overlay itself -
skipping to change at page 34, line 9 skipping to change at page 34, line 9
error. The peer SHOULD generate an appropriate error but local error. The peer SHOULD generate an appropriate error but local
policy can override this and cause the messages to be silently policy can override this and cause the messages to be silently
dropped. dropped.
Once the peer has determined that the message is correctly formatted, Once the peer has determined that the message is correctly formatted,
it examines the first entry on the destination list. There are three it examines the first entry on the destination list. There are three
possible cases here: possible cases here:
o The first entry on the destination list is an ID for which the o The first entry on the destination list is an ID for which the
peer is responsible. A peer is always responsible for the peer is responsible. A peer is always responsible for the
wildcard Node-ID. wildcard Node-ID. Handling of this case is described in
Section 5.1.1.
o The first entry on the destination list is an ID for which another o The first entry on the destination list is an ID for which another
peer is responsible. peer is responsible. Handling of this case is described in
Section 5.1.2.
o The first entry on the destination list is a private ID that is o The first entry on the destination list is a private ID that is
being used for destination list compression. This is described being used for destination list compression. Handling of this
later (note that private IDs can be distinguished from Node-IDs case is described in Section 5.1.3. Note that private IDs can be
and Resource-IDs on the wire; see Section 5.3.2.2). distinguished from Node-IDs and Resource-IDs on the wire as
described in Section 5.3.2.2).
These cases are handled as discussed below. These cases are handled as discussed below.
5.1.1. Responsible ID 5.1.1. Responsible ID
If the first entry on the destination list is an ID for which the If the first entry on the destination list is an ID for which the
node is responsible, there are several sub-cases to consider. peer is responsible, there are several sub-cases to consider.
o If the entry is a Resource-ID, then it MUST be the only entry on o If the entry is a Resource-ID, then it MUST be the only entry on
the destination list. If there are other entries, the message the destination list. If there are other entries, the message
MUST be silently dropped. Otherwise, the message is destined for MUST be silently dropped. Otherwise, the message is destined for
this node and it passes it up to the upper layers. this node and it passes it up to the upper layers.
o If the entry is a Node-ID which equals this node's Node-ID, then o If the entry is a Node-ID which equals this node's Node-ID, then
the message is destined for this node. If this is the only entry the message is destined for this node. If this is the only entry
on the destination list, the message is destined for this node and on the destination list, the message is destined for this node and
is passed up to the upper layers. Otherwise the entry is removed is passed up to the upper layers. Otherwise the entry is removed
from the destination list and the message is passed to the Message from the destination list and the message is passed to the Message
skipping to change at page 36, line 42 skipping to change at page 36, line 46
performing an Attach, the receiving node MUST reject the request with performing an Attach, the receiving node MUST reject the request with
an Error_Forbidden error. The node MUST implement support for an Error_Forbidden error. The node MUST implement support for
returning responses to a Ping or Attach request made by a joining returning responses to a Ping or Attach request made by a joining
node Attaching to its responsible peer. node Attaching to its responsible peer.
5.1.3. Private ID 5.1.3. Private ID
If the first entry in the destination list is a private id (e.g., a If the first entry in the destination list is a private id (e.g., a
compressed via list), the peer MUST replace that entry with the compressed via list), the peer MUST replace that entry with the
original via list that it replaced and then re-examine the original via list that it replaced and then re-examine the
destination list to determine which of the above cases now applies. destination list to determine which of the three cases in Section 5.1
now applies.
5.2. Symmetric Recursive Routing 5.2. Symmetric Recursive Routing
This Section defines RELOAD's symmetric recursive routing algorithm, This Section defines RELOAD's symmetric recursive routing algorithm,
which is the default algorithm used by nodes to route messages which is the default algorithm used by nodes to route messages
through the overlay. All implementations MUST implement this routing through the overlay. All implementations MUST implement this routing
algorithm. An overlay may be configured to use alternative routing algorithm. An overlay may be configured to use alternative routing
algorithms, and alternative routing algorithms may be selected on a algorithms, and alternative routing algorithms may be selected on a
per-message basis. per-message basis.
skipping to change at page 39, line 8 skipping to change at page 39, line 16
digital signature over the "Message Contents" section. Note that digital signature over the "Message Contents" section. Note that
this signature can be computed without parsing the message this signature can be computed without parsing the message
contents. All messages MUST be signed by their originator. contents. All messages MUST be signed by their originator.
The following sections describe the format of each part of the The following sections describe the format of each part of the
message. message.
5.3.1. Presentation Language 5.3.1. Presentation Language
The structures defined in this document are defined using a C-like The structures defined in this document are defined using a C-like
syntax based on the presentation language used to define TLS. syntax based on the presentation language used to define
[RFC5246] Advantages of this style include: TLS[RFC5246]. Advantages of this style include:
o It familiar enough looking that most readers can grasp it quickly. o It familiar enough looking that most readers can grasp it quickly.
o The ability to define nested structures allows a separation o The ability to define nested structures allows a separation
between high-level and low-level message structures. between high-level and low-level message structures.
o It has a straightforward wire encoding that allows quick o It has a straightforward wire encoding that allows quick
implementation, but the structures can be comprehended without implementation, but the structures can be comprehended without
knowing the encoding. knowing the encoding.
o The ability to mechanically compile encoders and decoders. o The ability to mechanically compile encoders and decoders.
Several idiosyncrasies of this language are worth noting. Several idiosyncrasies of this language are worth noting.
o All lengths are denoted in bytes, not objects. o All lengths are denoted in bytes, not objects.
o Variable length values are denoted like arrays with angle o Variable length values are denoted like arrays with angle
brackets. brackets.
o "select" is used to indicate variant structures. o "select" is used to indicate variant structures.
For instance, "uint16 array<0..2^8-2>;" represents up to 254 bytes For instance, "uint16 array<0..2^8-2>;" represents up to 254 bytes
but only up to 127 values of two bytes (16 bits) each. which corresponds to up to 127 values of two bytes (16 bits) each.
5.3.1.1. Common Definitions 5.3.1.1. Common Definitions
The following definitions are used throughout RELOAD and so are The following definitions are used throughout RELOAD and so are
defined here. They also provide a convenient introduction to how to defined here. They also provide a convenient introduction to how to
read the presentation language. read the presentation language.
An enum represents an enumerated type. The values associated with An enum represents an enumerated type. The values associated with
each possibility are represented in parentheses and the maximum value each possibility are represented in parentheses and the maximum value
is represented as a nameless value, for purposes of describing the is represented as a nameless value, for purposes of describing the
skipping to change at page 42, line 42 skipping to change at page 42, line 42
Destination via_list[via_list_length]; Destination via_list[via_list_length];
Destination destination_list Destination destination_list
[destination_list_length]; [destination_list_length];
ForwardingOptions options[options_length]; ForwardingOptions options[options_length];
} ForwardingHeader; } ForwardingHeader;
The contents of the structure are: The contents of the structure are:
relo_token: The first four bytes identify this message as a RELOAD relo_token: The first four bytes identify this message as a RELOAD
message. This field MUST contain the value 0xd2454c4f (the string message. This field MUST contain the value 0xd2454c4f (the string
'RELO' with the high bit of the first byte set.). 'RELO' with the high bit of the first byte set).
overlay: The 32 bit checksum/hash of the overlay being used. The overlay: The 32 bit checksum/hash of the overlay being used. The
variable length string representing the overlay name is hashed variable length string representing the overlay name is hashed
with SHA-1 [RFC3174] and the low order 32 bits are used. The with SHA-1 [RFC3174] and the low order 32 bits are used. The
purpose of this field is to allow nodes to participate in multiple purpose of this field is to allow nodes to participate in multiple
overlays and to detect accidental misconfiguration. This is not a overlays and to detect accidental misconfiguration. This is not a
security critical function. security critical function.
configuration_sequence: The sequence number of the configuration configuration_sequence: The sequence number of the configuration
file. file.
skipping to change at page 65, line 17 skipping to change at page 65, line 17
This section describes the profile of ICE that is used with RELOAD. This section describes the profile of ICE that is used with RELOAD.
RELOAD implementations MUST implement full ICE. RELOAD implementations MUST implement full ICE.
In ICE as defined by [RFC5245], SDP is used to carry the ICE In ICE as defined by [RFC5245], SDP is used to carry the ICE
parameters. In RELOAD, this function is performed by a binary parameters. In RELOAD, this function is performed by a binary
encoding in the Attach method. This encoding is more restricted than encoding in the Attach method. This encoding is more restricted than
the SDP encoding because the RELOAD environment is simpler: the SDP encoding because the RELOAD environment is simpler:
o Only a single media stream is supported. o Only a single media stream is supported.
o In this case, the "stream" refers not to RTP or other types of o In this case, the "stream" refers not to RTP or other types of
media, but rather to a connection for RELOAD itself or for SIP media, but rather to a connection for RELOAD itself or other
signaling. application-layer protocols such as SIP.
o RELOAD only allows for a single offer/answer exchange. Unlike the o RELOAD only allows for a single offer/answer exchange. Unlike the
usage of ICE within SIP, there is never a need to send a usage of ICE within SIP, there is never a need to send a
subsequent offer to update the default candidates to match the subsequent offer to update the default candidates to match the
ones selected by ICE. ones selected by ICE.
An agent follows the ICE specification as described in [RFC5245] with An agent follows the ICE specification as described in [RFC5245] with
the changes and additional procedures described in the subsections the changes and additional procedures described in the subsections
below. below.
5.5.1.4. Collecting STUN Servers 5.5.1.4. Collecting STUN Servers
skipping to change at page 66, line 40 skipping to change at page 66, line 40
ignored; defaults are not signaled or utilized by RELOAD. ignored; defaults are not signaled or utilized by RELOAD.
An alternative to using the full ICE supported by the Attach request An alternative to using the full ICE supported by the Attach request
is to use No-ICE mechanism by providing candidates with "No-ICE" is to use No-ICE mechanism by providing candidates with "No-ICE"
Overlay Link protocols. Configuration for the overlay indicates Overlay Link protocols. Configuration for the overlay indicates
whether or not these Overlay Link protocols can be used. An overlay whether or not these Overlay Link protocols can be used. An overlay
MUST be either all ICE or all No-ICE. MUST be either all ICE or all No-ICE.
No-ICE will not work in all of the scenarios where ICE would work, No-ICE will not work in all of the scenarios where ICE would work,
but in some cases, particularly those with no NATs or firewalls, it but in some cases, particularly those with no NATs or firewalls, it
will work. Therefore it is RECOMMENDED that full ICE be used even will work.
for a node that has a public, unfiltered IP address, to take
advantage of STUN connectivity checks, etc.
5.5.1.6. Prioritizing Candidates 5.5.1.6. Prioritizing Candidates
At the time of writing, UDP is the only transport protocol specified However, standardization of additional protocols for use with ICE is
to work with ICE. However, standardization of additional protocols expected, including TCP[I-D.ietf-mmusic-ice-tcp] and protocols such
for use with ICE is expected, including TCP and datagram-oriented as SCTP and DCCP. UDP encapsulations for SCTP and DCCP would expand
protocols such as SCTP and DCCP. In particular, UDP encapsulations the available Overlay Link protocols available for RELOAD. When
for SCTP and DCCP are expected to be standardized in the near future, additional protocols are available, the following prioritization is
greatly expanding the available Overlay Link protocols available for RECOMMENDED:
RELOAD. When additional protocols are available, the following
prioritization is RECOMMENDED:
o Highest priority is assigned to message-oriented protocols that o Highest priority is assigned to protocols that offer well-
offer well-understood congestion and flow control without head of understood congestion and flow control without head of line
line blocking. For example, SCTP without message ordering, DCCP, blocking. For example, SCTP without message ordering, DCCP, or
or those protocols encapsulated using UDP. those protocols encapsulated using UDP.
o Second highest priority is assigned to stream-oriented protocols, o Second highest priority is assigned to protocols that offer well-
e.g. TCP. understood congestion and flow control but have head of line
blocking such as TCP.
o Lowest priority is assigned to protocols encapsulated over UDP o Lowest priority is assigned to protocols encapsulated over UDP
that do not implement well-established congestion control that do not implement well-established congestion control
algorithms. The DTLS/UDP with SR overlay link protocol is an algorithms. The DTLS/UDP with SR overlay link protocol is an
example of such a protocol. example of such a protocol.
5.5.1.7. Encoding the Attach Message 5.5.1.7. Encoding the Attach Message
Section 4.3 of ICE describes procedures for encoding the SDP for Section 4.3 of ICE describes procedures for encoding the SDP for
conveying RELOAD candidates. Instead of actually encoding an SDP, conveying RELOAD candidates. Instead of actually encoding an SDP,
the candidate information (IP address and port and transport the candidate information (IP address and port and transport
skipping to change at page 68, line 10 skipping to change at page 68, line 8
entity sending the Attach request) will always be controlling, and entity sending the Attach request) will always be controlling, and
the answerer (the entity sending the Attach response) will always be the answerer (the entity sending the Attach response) will always be
controlled. The connectivity checks MUST still contain the ICE- controlled. The connectivity checks MUST still contain the ICE-
CONTROLLED and ICE-CONTROLLING attributes, however, even though the CONTROLLED and ICE-CONTROLLING attributes, however, even though the
role reversal capability for which they are defined will never be role reversal capability for which they are defined will never be
needed with RELOAD. This is to allow for a common codebase between needed with RELOAD. This is to allow for a common codebase between
ICE for RELOAD and ICE for SDP. ICE for RELOAD and ICE for SDP.
5.5.1.10. Full ICE 5.5.1.10. Full ICE
When neither side has provided an No-ICE candidate, connectivity When the overlay uses ICE , connectivity checks and nominations are
checks and nominations are used as in regular ICE. used as in regular ICE.
5.5.1.10.1. Connectivity Checks 5.5.1.10.1. Connectivity Checks
The processes of forming check lists in Section 5.7 of ICE, The processes of forming check lists in Section 5.7 of ICE,
scheduling checks in Section 5.8, and checking connectivity checks in scheduling checks in Section 5.8, and checking connectivity checks in
Section 7 are used with RELOAD without change. Section 7 are used with RELOAD without change.
5.5.1.10.2. Concluding ICE 5.5.1.10.2. Concluding ICE
The procedures in Section 8 of ICE are followed to conclude ICE, with The procedures in Section 8 of ICE are followed to conclude ICE, with
skipping to change at page 69, line 9 skipping to change at page 69, line 9
5.5.1.12. Subsequent Offers and Answers 5.5.1.12. Subsequent Offers and Answers
An agent MUST NOT send a subsequent offer or answer. Thus, the An agent MUST NOT send a subsequent offer or answer. Thus, the
procedures in Section 9 of ICE MUST be ignored. procedures in Section 9 of ICE MUST be ignored.
5.5.1.13. Sending Media 5.5.1.13. Sending Media
The procedures of Section 11 of ICE apply to RELOAD as well. The procedures of Section 11 of ICE apply to RELOAD as well.
However, in this case, the "media" takes the form of application However, in this case, the "media" takes the form of application
layer protocols (RELOAD) over TLS or DTLS. Consequently, once ICE layer protocols (e.g. RELOAD) over TLS or DTLS. Consequently, once
processing completes, the agent will begin TLS or DTLS procedures to ICE processing completes, the agent will begin TLS or DTLS procedures
establish a secure connection. The node which sent the Attach to establish a secure connection. The node which sent the Attach
request MUST be the TLS server. The other node MUST be the TLS request MUST be the TLS server. The other node MUST be the TLS
client. The server MUST request TLS client authentication. The client. The server MUST request TLS client authentication. The
nodes MUST verify that the certificate presented in the handshake nodes MUST verify that the certificate presented in the handshake
matches the identity of the other peer as found in the Attach matches the identity of the other peer as found in the Attach
message. Once the TLS or DTLS signaling is complete, the application message. Once the TLS or DTLS signaling is complete, the application
protocol is free to use the connection. protocol is free to use the connection.
The concept of a previous selected pair for a component does not The concept of a previous selected pair for a component does not
apply to RELOAD, since ICE restarts are not possible with RELOAD. apply to RELOAD, since ICE restarts are not possible with RELOAD.
skipping to change at page 74, line 24 skipping to change at page 74, line 24
Note: We expect future Overlay Link protocols to define replacements Note: We expect future Overlay Link protocols to define replacements
for all components of these protocols, including the framing header. for all components of these protocols, including the framing header.
These protocols have been chosen for simplicity of implementation and These protocols have been chosen for simplicity of implementation and
reasonable performance. reasonable performance.
Note to implementers: There are inherent tradeoffs in utilizing Note to implementers: There are inherent tradeoffs in utilizing
short timeouts to determine when a link has failed. To balance the short timeouts to determine when a link has failed. To balance the
tradeoffs, an implementation should be able to quickly act to remove tradeoffs, an implementation should be able to quickly act to remove
entries from the routing table when there is reason to suspect the entries from the routing table when there is reason to suspect the
link has failed. For example, in a Chord-derived overlay algorithm, link has failed. For example, in a Chord derived overlay algorithm,
a closer finger table entry could be substituted for an entry in the a closer finger table entry could be substituted for an entry in the
finger table that has experienced a timeout. That entry can be finger table that has experienced a timeout. That entry can be
restored if it proves to resume functioning, or replaced at some restored if it proves to resume functioning, or replaced at some
point in the future if necessary. End-to-end retransmissions will point in the future if necessary. End-to-end retransmissions will
handle any lost messages, but only if the failing entries do not handle any lost messages, but only if the failing entries do not
remain in the finger table for subsequent retransmissions. remain in the finger table for subsequent retransmissions.
5.6.1. Future Overlay Link Protocols 5.6.1. Future Overlay Link Protocols
The only currently defined overlay link protocols are TLS and DTLS.
It is possible to define new link-layer protocols and apply them to a It is possible to define new link-layer protocols and apply them to a
new overlay using the "overlay-link-protocol" configuration directive new overlay using the "overlay-link-protocol" configuration directive
(see Section 10.1.). However, any new protocols MUST meet the (see Section 10.1.). However, any new protocols MUST meet the
following requirements. following requirements.
Endpoint authentication When a node forms an association with Endpoint authentication When a node forms an association with
another endpoint, it MUST be possible to cryptographically verify another endpoint, it MUST be possible to cryptographically verify
that the endpoint has a given Node-Id. that the endpoint has a given Node-Id.
Traffic origin authentication and integrity When a node receives Traffic origin authentication and integrity When a node receives
skipping to change at page 75, line 32 skipping to change at page 75, line 32
the HIP base exchange. We anticipate that this would require a the HIP base exchange. We anticipate that this would require a
mapping between ORCHIDs and NodeIds. mapping between ORCHIDs and NodeIds.
o How to carry the HIP I1 and I2 messages. o How to carry the HIP I1 and I2 messages.
o How to carry RELOAD messages over HIP. o How to carry RELOAD messages over HIP.
[I-D.ietf-hip-reload-instance] documents work in progress on using [I-D.ietf-hip-reload-instance] documents work in progress on using
RELOAD with the HIP BONE. RELOAD with the HIP BONE.
5.6.1.2. ICE-TCP 5.6.1.2. ICE-TCP
The ICE-TCP draft [I-D.ietf-mmusic-ice-tcp] should allow TCP to be The ICE-TCP draft [I-D.ietf-mmusic-ice-tcp] allows TCP to be
supported as an Overlay Link protocol that can be added using ICE. supported as an Overlay Link protocol that can be added using ICE.
5.6.1.3. Message-oriented Transports 5.6.1.3. Message-oriented Transports
Modern message-oriented transports offer high performance, good Modern message-oriented transports offer high performance, good
congestion control, and avoid head of line blocking in case of lost congestion control, and avoid head of line blocking in case of lost
data. These characteristics make them preferable as underlying data. These characteristics make them preferable as underlying
transport protocols for RELOAD links. SCTP without message ordering transport protocols for RELOAD links. SCTP without message ordering
and DCCP are two examples of such protocols. However, currently they and DCCP are two examples of such protocols. However, currently they
are not well-supported by commonly available NATs, and specifications are not well-supported by commonly available NATs, and specifications
for ICE session establishment are not available. for ICE session establishment are not available.
5.6.1.4. Tunneled Transports 5.6.1.4. Tunneled Transports
As of the time of this writing, there is significant interest in the As of the time of this writing, there is significant interest in the
IETF community in tunneling other transports over UDP, motivated by IETF community in tunneling other transports over UDP, motivated by
the situation that UDP is well-supported by modern NAT hardware, and the situation that UDP is well-supported by modern NAT hardware, and
similar performance can be achieved to native implementation. similar performance can be achieved to native implementation.
Currently SCTP, DCCP, and a generic tunneling extension are being Currently SCTP, DCCP, and a generic tunneling extension are being
proposed for message-oriented protocols. Baset et al. have proposed proposed for message-oriented protocols. Once ICE traversal has been
tunneling TCP over UDP for similar reasons
[I-D.baset-tsvwg-tcp-over-udp]. Once ICE traversal has been
specified for these tunneled protocols, they should be specified for these tunneled protocols, they should be
straightforward to support as overlay link protocols. straightforward to support as overlay link protocols.
5.6.2. Framing Header 5.6.2. Framing Header
In order to support unreliable links and to allow for quick detection In order to support unreliable links and to allow for quick detection
of link failures when using reliable end-to-end transports, each of link failures when using reliable end-to-end transports, each
message is wrapped in a very simple framing layer (FramedMessage) message is wrapped in a very simple framing layer (FramedMessage)
which is only used for each hop. This layer contains a sequence which is only used for each hop. This layer contains a sequence
number which can then be used for ACKs. The same header is used for number which can then be used for ACKs. The same header is used for
skipping to change at page 78, line 18 skipping to change at page 78, line 16
5.6.3.1. Retransmission and Flow Control 5.6.3.1. Retransmission and Flow Control
Because the receiver's role is limited to providing packet Because the receiver's role is limited to providing packet
acknowledgements, a wide variety of congestion control algorithms can acknowledgements, a wide variety of congestion control algorithms can
be implemented on the sender side while using the same basic wire be implemented on the sender side while using the same basic wire
protocol. In general, senders MAY implement any rate control scheme protocol. In general, senders MAY implement any rate control scheme
of their choice, provided that it is REQUIRED to be no more of their choice, provided that it is REQUIRED to be no more
aggressive then TFRC[RFC5348]. aggressive then TFRC[RFC5348].
The following section describes a simple, inefficient, scheme that The following section describes a simple, inefficient scheme that
complies with this requirement. Another alternative would be TFRC-SP complies with this requirement. Another alternative would be TFRC-SP
[RFC4828] and use the received bitmask to allow the sender to compute [RFC4828] and use the received bitmask to allow the sender to compute
packet loss event rates. packet loss event rates.
5.6.3.1.1. Trivial Retransmission 5.6.3.1.1. Trivial Retransmission
A node SHOULD retransmit a message if it has not received an ACK A node SHOULD retransmit a message if it has not received an ACK
after an interval of RTO ("Retransmission TimeOut"). The node MUST after an interval of RTO ("Retransmission TimeOut"). The node MUST
double the time to wait after each retransmission. In each double the time to wait after each retransmission. In each
retransmission, the sequence number is incremented. retransmission, the sequence number is incremented.
skipping to change at page 78, line 40 skipping to change at page 78, line 38
The RTO is an estimate of the round-trip time (RTT). Implementations The RTO is an estimate of the round-trip time (RTT). Implementations
can use a static value for RTO or a dynamic estimate which will can use a static value for RTO or a dynamic estimate which will
result in better performance. For implementations that use a static result in better performance. For implementations that use a static
value, the default value for RTO is 500 ms. Nodes MAY use smaller value, the default value for RTO is 500 ms. Nodes MAY use smaller
values of RTO if it is known that all nodes are within the local values of RTO if it is known that all nodes are within the local
network. The default RTO MAY be chosen larger, and this is network. The default RTO MAY be chosen larger, and this is
RECOMMENDED if it is known in advance (such as on high latency access RECOMMENDED if it is known in advance (such as on high latency access
links) that the round-trip time is larger. links) that the round-trip time is larger.
Implementations that use a dynamic estimate to compute the RTO MUST Implementations that use a dynamic estimate to compute the RTO MUST
use the algorithm described in RFC 2988[RFC2988], with the exception use the algorithm described in RFC 6298[RFC6298], with the exception
that the value of RTO SHOULD NOT be rounded up to the nearest second that the value of RTO SHOULD NOT be rounded up to the nearest second
but instead rounded up to the nearest millisecond. The RTT of a but instead rounded up to the nearest millisecond. The RTT of a
successful STUN transaction from the ICE stage is used as the initial successful STUN transaction from the ICE stage is used as the initial
measurement for formula 2.2 of RFC 2988. The sender keeps track of measurement for formula 2.2 of RFC 6298. The sender keeps track of
the time each message was sent for all recently sent messages. Any the time each message was sent for all recently sent messages. Any
time an ACK is received, the sender can compute the RTT for that time an ACK is received, the sender can compute the RTT for that
message by looking at the time the ACK was received and the time when message by looking at the time the ACK was received and the time when
the message was sent. This is used as a subsequent RTT measurement the message was sent. This is used as a subsequent RTT measurement
for formula 2.3 of RFC 2988 to update the RTO estimate. (Note that for formula 2.3 of RFC 6298 to update the RTO estimate. (Note that
because retransmissions receive new sequence numbers, all received because retransmissions receive new sequence numbers, all received
ACKs are used.) ACKs are used.)
The value for RTO is calculated separately for each DTLS session. The value for RTO is calculated separately for each DTLS session.
Retransmissions continue until a response is received, or until a Retransmissions continue until a response is received, or until a
total of 5 requests have been sent or there has been a hard ICMP total of 5 requests have been sent or there has been a hard ICMP
error [RFC1122] or a TLS alert. The sender knows a response was error [RFC1122] or a TLS alert. The sender knows a response was
received when it receives an ACK with a sequence number that received when it receives an ACK with a sequence number that
indicates it is a response to one of the transmissions of this indicates it is a response to one of the transmissions of this
messages. For example, assuming an RTO of 500 ms, requests would be messages. For example, assuming an RTO of 500 ms, requests would be
sent at times 0 ms, 500 ms, 1500 ms, 3500 ms, and 7500 ms. If all sent at times 0 ms, 500 ms, 1500 ms, 3500 ms, and 7500 ms. If all
retransmissions for a message fail, then the sending node SHOULD retransmissions for a message fail, then the sending node SHOULD
skipping to change at page 79, line 47 skipping to change at page 79, line 46
5.6.5. TLS/TCP with FH, No-ICE 5.6.5. TLS/TCP with FH, No-ICE
This overlay link protocol consists of TLS over TCP with the framing This overlay link protocol consists of TLS over TCP with the framing
header. Because ICE is not used, STUN connectivity checks are not header. Because ICE is not used, STUN connectivity checks are not
used upon establishing the TCP connection, nor are they used for used upon establishing the TCP connection, nor are they used for
keepalives. keepalives.
Because the TCP layer's application-level timeout is too slow to be Because the TCP layer's application-level timeout is too slow to be
useful for overlay routing, the Overlay Link implementation MUST use useful for overlay routing, the Overlay Link implementation MUST use
the framing header to measure the RTT of the connection and calculate the framing header to measure the RTT of the connection and calculate
an RTO as specified in Section 2 of [RFC2988]. The resulting RTO is an RTO as specified in Section 2 of [RFC6298]. The resulting RTO is
not used for retransmissions, but as a timeout to indicate when the not used for retransmissions, but as a timeout to indicate when the
link SHOULD be removed from the routing table. It is RECOMMENDED link SHOULD be removed from the routing table. It is RECOMMENDED
that such a connection be retained for 30s to determine if the that such a connection be retained for 30s to determine if the
failure was transient before concluding the link has failed failure was transient before concluding the link has failed
permanently. permanently.
When sending candidates for TLS/TCP with FH, No-ICE, a passive When sending candidates for TLS/TCP with FH, No-ICE, a passive
candidate MUST be provided. candidate MUST be provided.
5.6.6. DTLS/UDP with SR, No-ICE 5.6.6. DTLS/UDP with SR, No-ICE
skipping to change at page 89, line 12 skipping to change at page 89, line 12
write this kind at this Resource-ID. If this check fails, the write this kind at this Resource-ID. If this check fails, the
request MUST be rejected with an Error_Forbidden error. request MUST be rejected with an Error_Forbidden error.
o For original (non-replica) stores, the StoreReq is signed by a o For original (non-replica) stores, the StoreReq is signed by a
credential which is authorized to write this kind at this credential which is authorized to write this kind at this
Resource-Id. If this check fails, the request MUST be rejected Resource-Id. If this check fails, the request MUST be rejected
with an Error_Forbidden error. with an Error_Forbidden error.
o For replica stores, the StoreReq is signed by a Node-Id which is a o For replica stores, the StoreReq is signed by a Node-Id which is a
plausible node to either have originally stored the value or in plausible node to either have originally stored the value or in
the replica set. What this means is overlay specific, but in the the replica set. What this means is overlay specific, but in the
case of Chord replica StoreReqs MUST come from nodes which are case of the Chord based DHT defined in this specification, replica
either in the known replica set for a given resource or which are StoreReqs MUST come from nodes which are either in the known
closer than some node in the replica set. If this check fails, replica set for a given resource or which are closer than some
the request MUST be rejected with an Error_Forbidden error. node in the replica set. If this check fails, the request MUST be
rejected with an Error_Forbidden error.
o For original (non-replica) stores, the peer MUST check that if the o For original (non-replica) stores, the peer MUST check that if the
generation counter is non-zero, it equals the current value of the generation counter is non-zero, it equals the current value of the
generation counter for this kind. This feature allows the generation counter for this kind. This feature allows the
generation counter to be used in a way similar to the HTTP Etag generation counter to be used in a way similar to the HTTP Etag
feature. feature.
o For replica Stores, the peer MUST set the generation counter to o For replica Stores, the peer MUST set the generation counter to
match the generation counter in the message, and MUST NOT check match the generation counter in the message, and MUST NOT check
the generation counter against the current value. Replica Stores the generation counter against the current value. Replica Stores
MUST NOT use a generation counter of 0. MUST NOT use a generation counter of 0.
o The storage time values are greater than that of any value which o The storage time values are greater than that of any value which
skipping to change at page 92, line 18 skipping to change at page 92, line 18
The Kind-ID being represented. The Kind-ID being represented.
generation_counter generation_counter
The current value of the generation counter for that Kind-ID. The current value of the generation counter for that Kind-ID.
replicas replicas
The list of other peers at which the data was/will be replicated. The list of other peers at which the data was/will be replicated.
In overlays and applications where the responsible peer is In overlays and applications where the responsible peer is
intended to store redundant copies, this allows the storing peer intended to store redundant copies, this allows the storing peer
to independently verify that the replicas have in fact been to independently verify that the replicas have in fact been
stored. It does this verification by using the Stat method. Note stored. It does this verification by using the Stat method (see
that the storing peer is not required to perform this Section 6.4.3). Note that the storing peer is not required to
verification. perform this verification.
The response itself is just StoreKindResponse values packed end-to- The response itself is just StoreKindResponse values packed end-to-
end. end.
If any of the generation counters in the request precede the If any of the generation counters in the request precede the
corresponding stored generation counter, then the peer MUST fail the corresponding stored generation counter, then the peer MUST fail the
entire request and respond with an Error_Generation_Counter_Too_Low entire request and respond with an Error_Generation_Counter_Too_Low
error. The error_info in the ErrorResponse MUST be a StoreAns error. The error_info in the ErrorResponse MUST be a StoreAns
response containing the correct generation counter for each kind and response containing the correct generation counter for each kind and
the replica list, which will be empty. For original (non-replica) the replica list, which will be empty. For original (non-replica)
skipping to change at page 104, line 9 skipping to change at page 104, line 9
the Resource-ID. If that peer knows of any servers, they will be the Resource-ID. If that peer knows of any servers, they will be
returned. The returned response may be empty if the peer does not returned. The returned response may be empty if the peer does not
know of any servers, in which case the process gets repeated with know of any servers, in which case the process gets repeated with
some other random Resource-ID. As long as the ratio of servers some other random Resource-ID. As long as the ratio of servers
relative to peers is not too low, this approach will result in relative to peers is not too low, this approach will result in
finding a server relatively quickly. finding a server relatively quickly.
9. Chord Algorithm 9. Chord Algorithm
This algorithm is assigned the name chord-reload to indicate it is an This algorithm is assigned the name chord-reload to indicate it is an
adaptation of the basic Chord DHT algorithm. adaptation of the basic Chord based DHT algorithm.
This algorithm differs from the originally presented Chord algorithm This algorithm differs from the originally presented Chord algorithm
[Chord]. It has been updated based on more recent research results [Chord]. It has been updated based on more recent research results
and implementation experiences, and to adapt it to the RELOAD and implementation experiences, and to adapt it to the RELOAD
protocol. A short list of differences: protocol. A short list of differences:
o The original Chord algorithm specified that a single predecessor o The original Chord algorithm specified that a single predecessor
and a successor list be stored. The chord-reload algorithm and a successor list be stored. The chord-reload algorithm
attempts to have more than one predecessor and successor. The attempts to have more than one predecessor and successor. The
predecessor sets help other neighbors learn their successor list. predecessor sets help other neighbors learn their successor list.
skipping to change at page 105, line 35 skipping to change at page 105, line 35
time instead of the typical O(N) time that a linked list would time instead of the typical O(N) time that a linked list would
provide. provide.
A peer, n, is responsible for a particular Resource-ID k if k is less A peer, n, is responsible for a particular Resource-ID k if k is less
than or equal to n and k is greater than p, where p is the Node-ID of than or equal to n and k is greater than p, where p is the Node-ID of
the previous peer in the neighbor table. Care must be taken when the previous peer in the neighbor table. Care must be taken when
computing to note that all math is modulo 2^128. computing to note that all math is modulo 2^128.
9.2. Hash Function 9.2. Hash Function
For this Chord topology plugin, the size of the Resource-ID is 128 For this Chord based topology plugin, the size of the Resource-ID is
bits. The hash of a Resource-ID is computed using SHA-1 128 bits. The hash of a Resource-ID is computed using SHA-1
[RFC3174]then truncating the SHA-1 result to the most significant 128 [RFC3174]then truncating the SHA-1 result to the most significant 128
bits. bits.
9.3. Routing 9.3. Routing
The routing table is the union of the neighbor table and the finger The routing table is the union of the neighbor table and the finger
table. table.
If a peer is not responsible for a Resource-ID k, but is directly If a peer is not responsible for a Resource-ID k, but is directly
connected to a node with Node-ID k, then it routes the message to connected to a node with Node-ID k, then it routes the message to
skipping to change at page 107, line 45 skipping to change at page 107, line 45
When a peer needs to Attach to a new peer in its neighbor table, it When a peer needs to Attach to a new peer in its neighbor table, it
MUST source-route the Attach request through the peer from which it MUST source-route the Attach request through the peer from which it
learned the new peer's Node-ID. Source-routing these requests allows learned the new peer's Node-ID. Source-routing these requests allows
the overlay to recover from instability. the overlay to recover from instability.
All other Attach requests, such as those for new finger table All other Attach requests, such as those for new finger table
entries, are routed conventionally through the overlay. entries, are routed conventionally through the overlay.
9.7. Updates 9.7. Updates
A chord Update is defined as An Update for this DHT is defined as
enum { reserved (0), enum { reserved (0),
peer_ready(1), neighbors(2), full(3), (255) } peer_ready(1), neighbors(2), full(3), (255) }
ChordUpdateType; ChordUpdateType;
struct { struct {
uint32 uptime; uint32 uptime;
ChordUpdateType type; ChordUpdateType type;
select(type){ select(type){
case peer_ready: /* Empty */ case peer_ready: /* Empty */
; ;
skipping to change at page 114, line 7 skipping to change at page 114, line 7
next_peer next_peer
The peer to which the responding peer would route the message in The peer to which the responding peer would route the message in
order to deliver it to the destination listed in the request. order to deliver it to the destination listed in the request.
If the requester has set the send_update flag, the responder SHOULD If the requester has set the send_update flag, the responder SHOULD
initiate an Update immediately after sending the RouteQueryAns. initiate an Update immediately after sending the RouteQueryAns.
9.9. Leaving 9.9. Leaving
To support extensions, such as [I-D.maenpaa-p2psip-self-tuning], To support extensions, such as [I-D.ietf-p2psip-self-tuning], Peers
Peers SHOULD send a Leave request to all members of their neighbor SHOULD send a Leave request to all members of their neighbor table
table prior to exiting the Overlay Instance. The prior to exiting the Overlay Instance. The overlay_specific_data
overlay_specific_data field MUST contain the ChordLeaveData structure field MUST contain the ChordLeaveData structure defined below:
defined below:
enum { reserved (0), enum { reserved (0),
from_succ(1), from_pred(2), (255) } from_succ(1), from_pred(2), (255) }
ChordLeaveType; ChordLeaveType;
struct { struct {
ChordLeaveType type; ChordLeaveType type;
select(type) { select(type) {
case from_succ: case from_succ:
skipping to change at page 123, line 45 skipping to change at page 123, line 45
topology-plugin-type |= "CHORD-RELOAD" topology-plugin-type |= "CHORD-RELOAD"
parameter &= element chord:chord-ping-interval { xsd:int }? parameter &= element chord:chord-ping-interval { xsd:int }?
parameter &= element chord:chord-update-interval { xsd:int }? parameter &= element chord:chord-update-interval { xsd:int }?
parameter &= element chord:chord-reactive { xsd:boolean }? parameter &= element chord:chord-reactive { xsd:boolean }?
10.2. Discovery Through Configuration Server 10.2. Discovery Through Configuration Server
When a node first enrolls in a new overlay, it starts with a When a node first enrolls in a new overlay, it starts with a
discovery process to find a configuration server. discovery process to find a configuration server.
The node first determines the overlay name. This value is provided The node MAY start by determines the overlay name. This value is
by the user or some other out of band provisioning mechanism. The provided by the user or some other out of band provisioning
out of band mechanisms may also provide an optional URL for the mechanism. The out of band mechanisms MAY also provide an optional
configuration server. If a URL for the configuration server is not URL for the configuration server. If a URL for the configuration
provided, the node MUST do a DNS SRV query using a Service name of server is not provided, the node MUST do a DNS SRV query using a
"p2psip-enroll" and a protocol of TCP to find a configuration server Service name of "p2psip-enroll" and a protocol of TCP to find a
and form the URL by appending a path of "/.well-known/p2psip-enroll" configuration server and form the URL by appending a path of "/.well-
to the overlay name. This uses the "well known URI" framework known/p2psip-enroll" to the overlay name. This uses the "well known
defined in [RFC5785]. For example, if the overlay name was URI" framework defined in [RFC5785]. For example, if the overlay
example.com, the URL would be name was example.com, the URL would be
"https://example.com//.well-known/p2psip-enroll". "https://example.com//.well-known/p2psip-enroll".
Once an address and URL for the configuration server is determined, Once an address and URL for the configuration server is determined,
the peer forms an HTTPS connection to that IP address. The the peer forms an HTTPS connection to that IP address. The
certificate MUST match the overlay name as described in [RFC2818]. certificate MUST match the overlay name as described in [RFC2818].
Then the node MUST fetch a new copy of the configuration file. To do Then the node MUST fetch a new copy of the configuration file. To do
this, the peer performs a GET to the URL. The result of the HTTP GET this, the peer performs a GET to the URL. The result of the HTTP GET
is an XML configuration file described above, which replaces any is an XML configuration file described above, which replaces any
previously learned configuration file for this overlay. previously learned configuration file for this overlay.
skipping to change at page 129, line 36 skipping to change at page 129, line 36
|-------------------------------------->| | | |-------------------------------------->| | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
|TLS | | | | | | |TLS | | | | | |
|.......................................| | | |.......................................| | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
JP also needs to populate its finger table (for Chord). It issues an JP also needs to populate its finger table (for the Chord based DHT).
Attach to a variety of locations around the overlay. The diagram It issues an Attach to a variety of locations around the overlay.
below shows it sending an Attach halfway around the Chord ring to the The diagram below shows it sending an Attach halfway around the Chord
JP + 2^127. ring to the JP + 2^127.
JP NP XX TP JP NP XX TP
| | | | | | | |
| | | | | | | |
| | | | | | | |
|Attach JP+2<<126 | | |Attach JP+2<<126 | |
|-------->| | | |-------->| | |
| | | | | | | |
| | | | | | | |
| |Attach JP+2<<126 | | |Attach JP+2<<126 |
skipping to change at page 148, line 26 skipping to change at page 148, line 26
Contact: Cullen Jennings <fluffy@cisco.com> Contact: Cullen Jennings <fluffy@cisco.com>
Author/Change controller: IESG Author/Change controller: IESG
References: RFC-AAAA References: RFC-AAAA
13.16. Media Type Registration 13.16. Media Type Registration
[[ Note to RFC Editor - please remove this paragraph before [[ Note to RFC Editor - please remove this paragraph before
publication. ]] A review request was sent to ietf-types@iana.org on publication. ]] A review request was sent to ietf-types@iana.org on
May 27, 2011. May 27, 2011.
To: ietf-types@iana.org
Subject: Registration of media type application/p2p-overlay+xml
Type name: application Type name: application
Subtype name: p2p-overlay+xml Subtype name: p2p-overlay+xml
Required parameters: none Required parameters: none
Optional parameters: none Optional parameters: none
Encoding considerations: Must be binary encoded. The contents MUST Encoding considerations: Must be binary encoded.
be valid XML compliant with the relax NG grammar specified in RFC-
AAAA and use the UTF-8[RFC3629] character encoding.
Security considerations: This media type is typically not used to Security considerations: This media type is typically not used to
transport information that typically needs to be kept confidential transport information that typically needs to be kept confidential
however there are cases where it is integrity of the information is however there are cases where it is integrity of the information is
important. For these cases using a digital signature is RECOMMENDED. important. For these cases using a digital signature is RECOMMENDED.
One way of doing this is specified in RFC-AAAA. In the case when the One way of doing this is specified in RFC-AAAA. In the case when the
media includes a "shared-secret" element, then the contents of the media includes a "shared-secret" element, then the contents of the
file need to be kept confidential or else anyone that can see the file need to be kept confidential or else anyone that can see the
shared-secret and effect the RELOAD overlay network. shared-secret and effect the RELOAD overlay network.
Interoperability considerations: Same as application/xml as defined Interoperability considerations: No knows interoperability
in [RFC3023]. consideration beyond those identified for application/xml in
[RFC3023].
Published specification: RFC-AAAA Published specification: RFC-AAAA
Applications that use this media type: The type is used to configure Applications that use this media type: The type is used to configure
the peer to peer overlay networks defined in RFC-AAAA. the peer to peer overlay networks defined in RFC-AAAA.
Additional information: The syntax for this media type is specified Additional information: The syntax for this media type is specified
in Section 10.1 of RFC-AAAA. in Section 10.1 of RFC-AAAA. The contents MUST be valid XML
compliant with the relax NG grammar specified in RFC-AAAA and use the
UTF-8[RFC3629] character encoding.
Magic number(s): none Magic number(s): none
File extension(s): relo File extension(s): relo
Macintosh file type code(s): none Macintosh file type code(s): none
Person & email address to contact for further information: Cullen Person & email address to contact for further information: Cullen
Jennings <c.jennings@ieee.org> Jennings <c.jennings@ieee.org>
skipping to change at page 149, line 44 skipping to change at page 149, line 41
Lowekamp, the "Address Settlement by Peer to Peer" draft by Cullen Lowekamp, the "Address Settlement by Peer to Peer" draft by Cullen
Jennings, Jonathan Rosenberg, and Eric Rescorla, the "Security Jennings, Jonathan Rosenberg, and Eric Rescorla, the "Security
Extensions for RELOAD" draft by Bruce B. Lowekamp and James Deverick, Extensions for RELOAD" draft by Bruce B. Lowekamp and James Deverick,
the "A Chord-based DHT for Resource Lookup in P2PSIP" by Marcia the "A Chord-based DHT for Resource Lookup in P2PSIP" by Marcia
Zangrilli and David A. Bryan, and the Peer-to-Peer Protocol (P2PP) Zangrilli and David A. Bryan, and the Peer-to-Peer Protocol (P2PP)
draft by Salman A. Baset, Henning Schulzrinne, and Marcin draft by Salman A. Baset, Henning Schulzrinne, and Marcin
Matuszewski. Thanks to the authors of RFC 5389 for text included Matuszewski. Thanks to the authors of RFC 5389 for text included
from that. Vidya Narayanan provided many comments and improvements. from that. Vidya Narayanan provided many comments and improvements.
The ideas and text for the Chord specific extension data to the Leave The ideas and text for the Chord specific extension data to the Leave
mechanisms was provided by J. Maenpaa, G. Camarillo, and J. mechanisms was provided by Jouni Maenpaa, Gonzalo Camarillo, and Jani
Hautakorpi. Hautakorpi.
Thanks to the many people who contributed including Ted Hardie, Thanks to the many people who contributed including Ted Hardie,
Michael Chen, Dan York, Das Saumitra, Lyndsay Campbell, Brian Rosen, Michael Chen, Dan York, Das Saumitra, Lyndsay Campbell, Brian Rosen,
David Bryan, Dave Craig, and Julian Cain. Extensive working last David Bryan, Dave Craig, and Julian Cain. Extensive working last
call comments were provided by: Jouni Maenpaa, Roni Even, Ari call comments were provided by: Jouni Maenpaa, Roni Even, Gonzalo
Keranen, John Buford, Michael Chen, Frederic-Philippe Met, and David Camarillo, Ari Keranen, John Buford, Michael Chen, Frederic-Philippe
Bryan. Special thanks to Marc Petit-Huguenin who provied an amazing Met, and David Bryan. Special thanks to Marc Petit-Huguenin who
amount to detailed review. provied an amazing amount to detailed review.
15. References 15. References
15.1. Normative References 15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key
Infrastructure Operational Protocols: FTP and HTTP", Infrastructure Operational Protocols: FTP and HTTP",
RFC 2585, May 1999. RFC 2585, May 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
Timer", RFC 2988, November 2000.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001. Types", RFC 3023, January 2001.
[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
(SHA1)", RFC 3174, September 2001. (SHA1)", RFC 3174, September 2001.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003. Version 2.1", RFC 3447, February 2003.
skipping to change at page 151, line 44 skipping to change at page 151, line 36
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952, August 2010. Address Text Representation", RFC 5952, August 2010.
[RFC6091] Mavrogiannopoulos, N. and D. Gillmor, "Using OpenPGP Keys [RFC6091] Mavrogiannopoulos, N. and D. Gillmor, "Using OpenPGP Keys
for Transport Layer Security (TLS) Authentication", for Transport Layer Security (TLS) Authentication",
RFC 6091, February 2011. RFC 6091, February 2011.
[RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011.
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent,
"Computing TCP's Retransmission Timer", RFC 6298,
June 2011.
[w3c-xml-namespaces] [w3c-xml-namespaces]
Bray, T., Hollander, D., Layman, A., Tobin, R., and Henry Bray, T., Hollander, D., Layman, A., Tobin, R., and Henry
S. , "Namespaces in XML 1.0 (Third Edition)". S. , "Namespaces in XML 1.0 (Third Edition)".
15.2. Informative References 15.2. Informative References
[Chord] Stoica, I., Morris, R., Liben-Nowell, D., Karger, D., [Chord] Stoica, I., Morris, R., Liben-Nowell, D., Karger, D.,
Kaashoek, M., Dabek, F., and H. Balakrishnan, "Chord: A Kaashoek, M., Dabek, F., and H. Balakrishnan, "Chord: A
Scalable Peer-to-peer Lookup Protocol for Internet Scalable Peer-to-peer Lookup Protocol for Internet
Applications", IEEE/ACM Transactions on Networking Volume Applications", IEEE/ACM Transactions on Networking Volume
11, Issue 1, 17-32, Feb 2003. 11, Issue 1, 17-32, Feb 2003.
[Eclipse] Singh, A., Ngan, T., Druschel, T., and D. Wallach, [Eclipse] Singh, A., Ngan, T., Druschel, T., and D. Wallach,
"Eclipse Attacks on Overlay Networks: Threats and "Eclipse Attacks on Overlay Networks: Threats and
Defenses", INFOCOM 2006, April 2006. Defenses", INFOCOM 2006, April 2006.
[I-D.baset-tsvwg-tcp-over-udp]
Baset, S. and H. Schulzrinne, "TCP-over-UDP",
draft-baset-tsvwg-tcp-over-udp-01 (work in progress),
June 2009.
[I-D.ietf-hip-reload-instance] [I-D.ietf-hip-reload-instance]
Keranen, A., Camarillo, G., and J. Maenpaa, "Host Identity Keranen, A., Camarillo, G., and J. Maenpaa, "Host Identity
Protocol-Based Overlay Networking Environment (HIP BONE) Protocol-Based Overlay Networking Environment (HIP BONE)
Instance Specification for REsource LOcation And Discovery Instance Specification for REsource LOcation And Discovery
(RELOAD)", draft-ietf-hip-reload-instance-03 (work in (RELOAD)", draft-ietf-hip-reload-instance-03 (work in
progress), January 2011. progress), January 2011.
[I-D.ietf-mmusic-ice-tcp] [I-D.ietf-mmusic-ice-tcp]
Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach,
"TCP Candidates with Interactive Connectivity "TCP Candidates with Interactive Connectivity
Establishment (ICE)", draft-ietf-mmusic-ice-tcp-13 (work Establishment (ICE)", draft-ietf-mmusic-ice-tcp-13 (work
in progress), April 2011. in progress), April 2011.
[I-D.ietf-p2psip-concepts] [I-D.ietf-p2psip-concepts]
Bryan, D., Matthews, P., Shim, E., Willis, D., and S. Bryan, D., Matthews, P., Shim, E., Willis, D., and S.
Dawkins, "Concepts and Terminology for Peer to Peer SIP", Dawkins, "Concepts and Terminology for Peer to Peer SIP",
draft-ietf-p2psip-concepts-03 (work in progress), draft-ietf-p2psip-concepts-03 (work in progress),
October 2010. October 2010.
[I-D.ietf-p2psip-self-tuning]
Maenpaa, J., Camarillo, G., and J. Hautakorpi, "A Self-
tuning Distributed Hash Table (DHT) for REsource LOcation
And Discovery (RELOAD)", draft-ietf-p2psip-self-tuning-04
(work in progress), July 2011.
[I-D.ietf-p2psip-service-discovery]
Maenpaa, J. and G. Camarillo, "Service Discovery Usage for
REsource LOcation And Discovery (RELOAD)",
draft-ietf-p2psip-service-discovery-03 (work in progress),
July 2011.
[I-D.ietf-p2psip-sip] [I-D.ietf-p2psip-sip]
Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
H. Schulzrinne, "A SIP Usage for RELOAD", H. Schulzrinne, "A SIP Usage for RELOAD",
draft-ietf-p2psip-sip-05 (work in progress), July 2010. draft-ietf-p2psip-sip-05 (work in progress), July 2010.
[I-D.jiang-p2psip-relay] [I-D.jiang-p2psip-relay]
Jiang, X., Zong, N., Even, R., and Y. Zhang, "An extension Jiang, X., Zong, N., Even, R., and Y. Zhang, "An extension
to RELOAD to support Direct Response and Relay Peer to RELOAD to support Direct Response and Relay Peer
routing", draft-jiang-p2psip-relay-05 (work in progress), routing", draft-jiang-p2psip-relay-05 (work in progress),
March 2011. March 2011.
[I-D.maenpaa-p2psip-self-tuning]
Maenpaa, J., Camarillo, G., and J. Hautakorpi, "A Self-
tuning Distributed Hash Table (DHT) for REsource LOcation
And Discovery (RELOAD)",
draft-maenpaa-p2psip-self-tuning-01 (work in progress),
October 2009.
[I-D.maenpaa-p2psip-service-discovery]
Maenpaa, J. and G. Camarillo, "Service Discovery Usage for
REsource LOcation And Discovery (RELOAD)",
draft-maenpaa-p2psip-service-discovery-00 (work in
progress), October 2009.
[I-D.pascual-p2psip-clients] [I-D.pascual-p2psip-clients]
Pascual, V., Matuszewski, M., Shim, E., Zhang, H., and S. Pascual, V., Matuszewski, M., Shim, E., Zhang, H., and S.
Yongchao, "P2PSIP Clients", Yongchao, "P2PSIP Clients",
draft-pascual-p2psip-clients-01 (work in progress), draft-pascual-p2psip-clients-01 (work in progress),
February 2008. February 2008.
[RFC1122] Braden, R., "Requirements for Internet Hosts - [RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122, October 1989.
[RFC2311] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and [RFC2311] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and
skipping to change at page 153, line 51 skipping to change at page 153, line 41
Authentication", RFC 5054, November 2007. Authentication", RFC 5054, November 2007.
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
"Host Identity Protocol", RFC 5201, April 2008. "Host Identity Protocol", RFC 5201, April 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
[RFC5694] Camarillo, G. and IAB, "Peer-to-Peer (P2P) Architecture:
Definition, Taxonomies, Examples, and Applicability",
RFC 5694, November 2009.
[RFC5765] Schulzrinne, H., Marocco, E., and E. Ivov, "Security [RFC5765] Schulzrinne, H., Marocco, E., and E. Ivov, "Security
Issues and Solutions in Peer-to-Peer Systems for Realtime Issues and Solutions in Peer-to-Peer Systems for Realtime
Communications", RFC 5765, February 2010. Communications", RFC 5765, February 2010.
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
Uniform Resource Identifiers (URIs)", RFC 5785, Uniform Resource Identifiers (URIs)", RFC 5785,
April 2010. April 2010.
[RFC6079] Camarillo, G., Nikander, P., Hautakorpi, J., Keranen, A., [RFC6079] Camarillo, G., Nikander, P., Hautakorpi, J., Keranen, A.,
and A. Johnston, "HIP BONE: Host Identity Protocol (HIP) and A. Johnston, "HIP BONE: Host Identity Protocol (HIP)
 End of changes. 62 change blocks. 
141 lines changed or deleted 137 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/