Internet DRAFT - draft-hessing-p2p-messaging
draft-hessing-p2p-messaging
Steven Hessing
April 2002
Internet-Draft
Document: draft-hessing-p2p-messaging-00.txt
Expires: October 2002
Peer to Peer Messaging Protocol (PPMP)
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as 'work in progress.'
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
draft-hessing-p2p-messaging-00.txt April 2002
Abstract
The Peer to Peer Messaging Protocol supports the creation of
scalable, extensible and secure Peer to Peer networks leveraging
current practices and introducing new concepts to P2P networking
such as the support of multiple communities, security and
multicasting. The protocol is highly extensible to allow for the
development of additional features and applications for p2p
networks.
Table of Contents
1. Overview.....................................................3
2. Conventions used in this document............................4
3. Introduction.................................................4
4. Messages.....................................................5
4.1. PPMP header................................................9
4.2. Checksum header...........................................11
4.3. Message Length header.....................................12
4.4. Cease header..............................................12
4.5. Path header...............................................13
4.6. Path Record header........................................14
4.7. Connection header.........................................15
4.8. Authentication header.....................................16
4.9. Encryption header.........................................16
4.10. Error header.............................................17
5. Message forwarding..........................................18
5.1. Broadcasting..............................................19
5.2. Routed....................................................20
5.3. Fully Specified Path......................................21
5.4. Multicasting..............................................21
6. Security profiles...........................................22
6.1. Requirements for joining a community......................22
6.2. Security for the transport of messages....................23
6.2.1. Segment security.....................................23
6.2.2. Path security........................................24
6.3. Data security.............................................25
7. Connection setup and maintenance............................25
7.1. Bidirectional Connections.................................27
7.1.1. Establishing a bi-directional transport connection...27
7.1.2. Negotiate bi-directional connection parameters.......28
7.1.3. Negotiate supported forwarding mechanisms for bi-
directional connections.....................................29
7.1.4. Breaking bi-directional connection collision.........30
7.1.5. Keepalive messages for bi-directional connections....31
7.2. Multicast, unidirectional connections.....................32
Hessing Individual submission - Expires October 2002 2
draft-hessing-p2p-messaging-00.txt April 2002
7.2.1. Multicast Session Announcement header................32
7.2.2. Multicast Session Report header......................33
7.2.3. Sequence header......................................34
7.2.4. Forwarding messages over multicast transport.........34
8. Communities.................................................35
8.1. Community Announcements...................................36
8.2. Community Description header..............................37
8.3. Community Authorization header............................40
9. Out-of-band Data Transport..................................40
10. Capabilities................................................41
10.1. Ping capability..........................................42
10.2. Pong capability..........................................42
10.3. Servent Discovery capability.............................42
10.4. Hello capability.........................................42
10.5. Connection Advise capability.............................43
10.6. Community Discovery capability...........................44
10.7. Community Invitation capability..........................45
10.8. XML Query capability.....................................46
10.9. XML Response capability..................................46
10.10. Resource Push Request capability........................47
10.11. Algorithm Request capability............................48
10.12. Algorithm Response capability...........................48
10.13. Dataset Request capability..............................49
10.14. Dataset Response capability.............................49
10.15. Dataset Result capability...............................50
10.16. Chat capability.........................................51
11. Network management..........................................51
12. Security considerations.....................................52
13. IANA Considerations.........................................53
14. References..................................................55
15. Author's Address............................................56
16. Full Copyright Statement....................................56
1. Overview
This document describes a protocol for the exchange of messages
between systems participating in a peer to peer (P2P) network. A
system participating in such a network is called a servent. The
protocol introduces the concepts of the addressing of servents and
the forwarding of messages in the P2P network between servents using
either unicast or multicast transport.
The protocol supports the membership of servents of one or more
communities with each community supporting one or more applications.
Hessing Individual submission - Expires October 2002 3
draft-hessing-p2p-messaging-00.txt April 2002
Each application consists of a set of capabilities and a number of
services provided from outside the P2P network.
The protocol supports the specification of requirements for a
servent to join a community and supports for authentication and
encryption of messages on the P2P network both on a hop-by-hop and
on an end-to-end basis.
Finally the protocol references a number of unicast and multicast
protocols to be used to exchange bulk data between servents without
making use of the p2p network.
2. Conventions used in this document
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT',
'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in
this document are to be interpreted as described in RFC 2119 [2].
3. Introduction
In a P2P network, the key elements are servents and messages.
Servents send each other messages to perform functions. This
protocol introduces three separate layers in such a message. The
first layer provides for the addressing of servents and the
forwarding of messages, the second layer provides for the security
of messages while they are being transported through the p2p network
and the third layer supports application functionality.
Servents can only exchange messages with each other if there is a
direct connection between the two servents or they have connections
to other servents that can forward the message between the source
and destination servent. Two servents that have a direct connection
to each other are called peers.
This protocol introduces to P2P technology the concept of multiple
communities. A community is a group of systems that have a common
goal for using P2P technology. A community is defined by its
security profile and its supported applications. The security
profile describes how systems can join the community and what
requirements exist for the transport of messages and data between
the systems in the community. Applications are a combination of a
set of capabilities and zero or more services. A capability is a
functionality to be performed by one or more servents. A service is
some functionality that is provided by a system outside of a p2p
network, without using this p2p protocol.
Communities can be either well-known or dynamically created. Well-
known communities are registered with IANA. Dynamically created
Hessing Individual submission - Expires October 2002 4
draft-hessing-p2p-messaging-00.txt April 2002
communities are announced by servents to each other using connection
management messages. There are two well-known communities defined in
this document. There is the special-purpose connection management
community and the network management community. Implementations of
this document MUST support the former and SHOULD support the latter
community, next to any other community that the implementation
supports. Having servents that are members of different communities
share one network management community will allow for community
interaction, greater network interconnectivity and more
opportunities for optimalisation of the P2P network.
This protocol introduces a number of specifications for each of the
three message layers. It only describes a basic set of
functionalities for each of the three layers. It is anticipated that
other documents will provide additional specifications and build
upon the protocol foundation provided in this document.
4. Messages
Messages are used when one servent (the source servent) sends
information, a request or a response to another servent (the
destination servent) using one of the capabilities that are
supported by a community that both servents are a member of.
Servents establish connections to each other using a connection
setup mechanism described in the section 'Connection setup'. Two
directly connected servents are called peers. When a servent sends a
message to a destination servent that is not directly connected to
it via intermediate servents then these other servents SHOULD
forward the message until it reaches the destination servent.
Sourcing or forwarding a message to a servent is only allowed if the
servent that the message is being sent or forwarded to (the next-hop
servent) is member of the same community as specified in the
message. Messages thus belong to a community. Messages belonging to
a community MUST only be send, received, forwarded and processed by
servents that are member of the same community. A servent that is
not a member of a community MUST never receive, send, forward or
process messages from that community. A servent receiving a message
belonging to a community it is not a member of MUST discard the
message immediately and MUST cease the connection to the peer from
which it has received the message with the cease code for
'Connection error' with the cease sub-code for 'Invalid community'.
More information about cease messages can be found in the section
'Cease header'.
A servent is NOT REQUIRED to forward a message it receives. If the
time to live of the message is zero then the message MUST be
discarded. If there is a shortage of local system resources or there
is another local reason not to forward the message then the servent
Hessing Individual submission - Expires October 2002 5
draft-hessing-p2p-messaging-00.txt April 2002
MAY discard the message. A servent sending a message to its
destination via one or more intermediate servents MUST NOT assume
that the message will be delivered to its destination.
Two servents establishing a direct connection negotiate the version
of the P2P protocol. Messages MUST be sent over a connection using
the protocol version negotiated for that connection. If a message is
received over a connection with a mismatch in the protocol version
then the connection MUST be ceased with the cease code 'Connection
error' and the sub-code of 'Invalid protocol version'. Messages
coming in over a connection with one protocol version MAY be sent
out over another connection with another protocol version. A servent
performing this protocol conversion for a message which contains a
checksum MUST verify and recalculate this checksum before forwarding
the message.
A servent SHOULD ensure that all connection management messages are
sent in a timely manner to its peers.
Messages MUST be sent using only the headers supported by the
community and its capabilities. Messages using a capability that is
not supported by the community MUST be discarded by a servent
receiving the message whether that message is destined for that
servent or not. The servent MUST either withdraw the community
announcement to this peer with a Community Description message or
cease the connection to the peer it received the message from. A
cease message SHOULD in the latter case be sent to the peer with the
cease code for 'Message error' and the error sub-code for 'Invalid
capability'.
A message is defined by the community it belongs to, the servent
that has sourced it and its Message-ID. This tuple SHOULD be used to
uniquely identify messages. If and when a Connection header is
defined then this header SHOULD also be used to determine whether
the message is a duplicate of another message it has previously
received or not. Whenever a servent receives a duplicate message it
SHOULD silently discard the duplicate.
A servent MUST never forward a message it has received from a peer
with its own Source Servent ID.
A servent MAY analyze the contents of a message even it is not the
destination of the message. The servent MAY use the information for
network discovery, data caching or any other purpose it sees fit.
There is thus no inherent or assumed privacy in a P2P network.
Communities wishing to have privacy features should use the
available security provisions in this P2P protocol as described in
the section 'Path Security'.
Hessing Individual submission - Expires October 2002 6
draft-hessing-p2p-messaging-00.txt April 2002
A message can either be directed to a single servent or broadcasted
to all servents that are member of the community.
A message consists of:
- Required Protocol headers
- Optional Protocol headers
- Security headers
- Capability headers
- Payload
Message headers MUST follow this order. A message must start with
the PPMP header. This header, together with the Checksum header MUST
be supported by every servent. Communities specify the requirements
for any other capabilities that a servent MUST support. As support
of the Connection Management community is REQUIRED for each servent,
support for the capabilities defined by the Connection Management
community is also REQUIRED for each servent. See the section on
'Community Announcements' on the capability support requirements for
the Connection Management community.
Some protocol headers are required in each message, other protocol
headers can be optionally included.
Whenever the description of a value of a header field is depicted as
(Reserved) then this value is not available for use. All values in
headers are in network byte order also known as big-endian order
such that for any value consisting of n bytes this value can be
collected from the byte stream by taking:
value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) | ... |
byte[n-1];
The values for Message and Header length depict the length in bytes.
Header Header Header type Included Header name
code length in
checksum?
0x0000 N/A N/A N/A (Reserved)
0x0001 0x0024 Required Partial PPMP
(2)
0x0002 0x0008 Required(1) No Checksum
0x0003 0x000C Optional Yes Message Length
0x0004 0x0006 Optional Yes Cease
0x0005 Optional Yes Community Description
Hessing Individual submission - Expires October 2002 7
draft-hessing-p2p-messaging-00.txt April 2002
0x0006 Optional Yes Community Authorization
0x0007 0x000C Optional Yes Path header
0x0008 0x000C Optional Yes Path Record header
0x0009 undef Undef Undef Connection header
0x000A 0x000C Optional Yes Multicast Session
Announcement
0x000B 0x0006 Optional Yes Error
0x000C 0x0004 Optional Yes Multicast Session Report
0x000D >= Optional Yes Authentication
0x0004
0x000E 0x001C Optional Yes Encryption
0x000F 0x0008 Optional Yes Sequence header
0xFF00 N/A N/A (Experimental use)
-
0xFFFF
(1): Optional if the connection over which the message is being sent
is detects transmission errors.
(2): The 'Time to Live' and 'Hop count' fields are not included in
the checksum of the PPMP header.
If at any time there is a message processing error for which there
is no known cause then the message MUST be discarded and an error
message SHOULD be sent with the error code for 'Message error' and
the error sub-code for 'Unspecified error'.
A message with a header that has an invalid length MUST be
discarded. An error message SHOULD be sent with the error code for
'Message error' and the error sub-code 'Invalid header length'
Hessing Individual submission - Expires October 2002 8
draft-hessing-p2p-messaging-00.txt April 2002
4.1. PPMP header
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header type (0x0001) | Header length (0x0024) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol v. | Forw. Mech. | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID | Flags |SegmentSecurity|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Community ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Servent ID (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Servent ID (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Servent ID (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Servent ID (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Hop count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Source/Destination Servent ID: Randomly-chosen 64 bit ID. For now
the first eight bits MUST have the value 0x00. A servent MAY have
multiple IDs. A community MAY define a requirement that a servent is
only to use one ID for both joining the community and for sending
and forwarding messages. A servent SHOULD use only one Servent ID
for all its connections and messages unless there are privacy
reasons in a supported community not to use a single Servent ID. A
servent ID is not guaranteed to be unique as there is no
coordination between servents in selecting servent IDs.
- A message with a Source Servent ID of all zeros is an anonymous
message.
- A message with a Destination Servent ID of all ones is a broadcast
message, to be received and processed by all servents.
- Protocol version: as negotiated during the setup of the connection
over which the message has been received or is to be send.
- Forwarding mechanism: see the section 'Message forwarding'.
- Message Length: 16 bit value. If the message length field contains
the value 0x0000 then the message MUST include the Message Length
header to indicate the length of the message. This method is used
when messages are longer then 2 ^ 16 û 1 bytes. If the message
length value in the PPMP header is 0x0000 and the message does not
include the Message Length header then the message MUST be discarded
Hessing Individual submission - Expires October 2002 9
draft-hessing-p2p-messaging-00.txt April 2002
and an error message SHOULD be sent with the error code for 'Message
Error' and the Error sub-code 'Message length unknown'. See the
section on the 'Message Length header' for more details.
- Message ID: 16 bit value unique to the servent sourcing the
message.
- Flags: 8 bits
Bit Value
0 Reliable transport between peers required. The
connection MUST ensure that the message is received
and is error-free.
1 Multicast transport allowed
2 Record route requested
3 Source Servent does not receive incoming connections
4-7 (Reserved)
A servent sending a message MUST set the value of bits 4 to 7 to 0.
If the flags are inconsistent with the community attributes then the
message MUST be discarded. An error message SHOULD be sent with the
error code for 'Message error' with the error sub-code for 'Invalid
flags'.
A message that has bit 0 of the flags set MUST NOT be send over a
connection that does not validate whether the message was
transported without errors.
A servent which suspects it is behind a firewall and/or may not be
able to accept incoming connections from other servents SHOULD set
bit 3.
- Segment Security: The Segment Security Code that is required for
the transport of the message between two peers.
- Time to live: 8 bits, number of hops that this message can be
forwarded to before it should be discarded. The Source servent
should set this value to the preferred time to live. Each servent
that sends the message (including the Source servent) SHOULD reduce
this time to live with one when sending the message. Messages
received with a time to live of 0 MUST NOT be forwarded to other
servents but SHOULD be processed locally.
Hop count: 8 bits, number of times the message has been sent from
one servent to another, when a servent receives a message it
increases the hop count. The source servent thus sends the message
with a hop count of 0. After the servent has received the message
and incremented the hop count, the hop count plus the time to live
SHOULD always match the original time to live as specified by the
source servent.
Hessing Individual submission - Expires October 2002 10
draft-hessing-p2p-messaging-00.txt April 2002
4.2. Checksum header
The Checksum header allows errors to be detected by servents
receiving a message. The checksum is calculated using the SHA1
algorithm as described in [3].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header type (0x0002) | Header length (0x0008) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When the checksum of a message does not match the locally calculated
checksum then the message MUST be discarded. An error message SHOULD
be sent with the error code for 'Message error' with the error sub-
code for 'Checksum error'.
Whenever a servent sends a message over a connection that does not
validate the correct transmission of a message then the checksum
header MUST be included even if that servent received the message
without a checksum header.
When a servent receives a message over a connection that does not
validate the correct transmission of a message then the servent MUST
verify the checksum. It MUST NOT remove the header when forwarding
the header, even if this forwarding occurs over a connection that
validates the correct transmission of a message. If a servent
receives a message that does not have a checksum header over a
connection that does not validate the correct transmission of a
message then the message MUST be discarded.
When a community defines capability specific headers it MUST specify
whether these MUST be included in the checksum. Headers that have
values that do not change per hop SHOULD be included in the
checksum. Values that may change per hop MUST NOT be included in the
checksum.
The payload of a message is always used for computing the checksum
unless the capability in the message that has provided the
specification of the payload has defined that the payload should not
be included in the checksum.
The verification of a checksum is OPTIONAL if the message has been
received over a connection that validates the error-free transport
of the message.
Hessing Individual submission - Expires October 2002 11
draft-hessing-p2p-messaging-00.txt April 2002
4.3. Message Length header
The Message Length header is used to indicate the length of the
message when this message exceeds 2 ^ 16 - 1 bytes.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header type (0x0003) | Header length (0x0008) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Message Length value is a 64 bit value.
If the message length is less then 0x30 (the length of the PPMP
header plus the message length header) then the message MUST be
discarded and an error message SHOULD be sent with the error code
for 'Message error' and the error sub-code for 'Invalid header
length'.
4.4. Cease header
Whenever a critical error occurs in the connection between peers
then this connection MUST be terminated by the peer that noticed the
error. This peer SHOULD send a message with only the PPMP header,
the CEASE header described in this section and a Checksum header if
the connection over which the message is to be sent does not
validate that the message is transported error-free. A message which
contains a Cease header is called a Cease message. After sending the
Cease message, the peer SHALL immediately close the connection to
the peer causing the critical error and SHALL NOT process any
messages forwarded by that peer which were still waiting to be
processed.
An error message MUST NOT be generated in response to a message that
includes the Cease header.
The Cease message MUST always use the Connection Management
Community and MUST use the header values as specified for this
community in the 'Connection setup and maintenance' section.
Hessing Individual submission - Expires October 2002 12
draft-hessing-p2p-messaging-00.txt April 2002
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header type (0x0004) | Header length (0x0006) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cease code | Cease Subcode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following Cease Codes and Sub-codes are defined:
Cease Cease Message code Message sub-code
Code Sub-
code
1 0 Unknown error
2 0 Connection denied Unspecified error
2 1 Connection denied Administratively prohibited
2 1 Connection denied Servent ID unacceptable
2 2 Connection denied Protocol Version not supported
2 3 Connection denied Time out value unacceptable
2 4 Connection denied Connection collision detected
3 0 Connection error Unknown error
3 1 Connection error Invalid Source Servent ID
3 2 Connection error Invalid Destination Servent ID
3 3 Connection error Invalid Forwarding mechanism
3 4 Connection error Invalid Time-to-Live
3 5 Connection error Invalid Protocol Version
3 6 Connection error Invalid community
3 7 Connection error Time out timer expired
4 0 Connection info Unknown information
4 1 Connection info Better connection available
5 0 Message error Unspecified error
5 1 Message error Invalid capability
5 2 Message error Invalid checksum
4.5. Path header
The Path header is used to specify the route which a message should
take through a P2P network
Hessing Individual submission - Expires October 2002 13
draft-hessing-p2p-messaging-00.txt April 2002
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header type (0x0007) | Header length (0x0008) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Servent ID (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Servent ID (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Path headers can OPTIONALLY be used with all forwarding mechanisms.
See the section on 'Fully Defined Path' on how to process this
header when using this forwarding mechanism. The chapter on
Forwarding Mechanisms defines how message forwarding should be
performed for messages with one or more Path headers for the other
forwarding mechanisms.
The Path headers in the message are in the order of the servents the
message should be sent past. A servent MUST remove the first Path
header of a message if the Servent ID in that Path header matches
one of its own Servent IDs. Whenever a servent removes a Path header
from a message that has a checksum header, it MUST always verify the
original checksum before removing the Path header and discard the
message of the checksum is not correct. If the checksum does match
the servent MUST remove the Path header and recalculate the
checksum.
When a Path header is present in a message it SHOULD NOT be
considered to determine whether a message is a duplicate of another
message.
The normal rules for increasing the hop count and decreasing the
time to live apply. The message SHOULD be not be forwarded when the
time to live is 0 even if there are additional Path headers present
in the message.
4.6. Path Record header
The Path Record header is used to record the route a message takes
through a P2P network
Hessing Individual submission - Expires October 2002 14
draft-hessing-p2p-messaging-00.txt April 2002
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header type (0x0008) | Header length (0x0008) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Servent ID (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Servent ID (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Path Record headers MAY be used with all Forwarding Mechanisms. A
servent receiving a message with the Path Record flag set SHOULD
append a Path Record header to the list of already present Path
Record headers. If no Path Record headers are present then it should
put in the header directly after the PPMP header.
The servent MUST put in the Path Record header the Servent ID it
used during the establishment of the connection over which it is
forwarding the message. This implies that for each connection it may
need to add a different Path Record header if it has used different
Servent Ids for setting up these connections.
If the message also has a checksum header then the checksum MUST
always be verified. Before forwarding the message over a connection
but after adding the Path Record header the servent MUST recalculate
the checksum and add it to the message.
Path Record headers are only sent by servents forwarding a message.
The servent sourcing the message MUST NOT include a Path Record
header.
The last servent processing a message with one or more Path Record
headers present SHOULD send a message back to the Source Servent ID
belonging to the same community, without the Record Route flag set
but with the Path Record headers that are present in the message.
This last servent can either be the destination servent or one or
more servents that receive the message with a Time-To-Live of zero.
4.7. Connection header
The p2p protocol is in itself connectionless. Although TCP [4] is
one of the transport mechanisms specified as a means for the
transport messages between two peers, servents can exchange messages
by using the forwarding services of other servents and these
intermediate servents do not guarantee the delivery of the message.
At this time the need for a connection mechanism on top of the
message transport facilities is unclear. Whenever such a mechanism
would be implemented, servents would need to take into account that
when one or more Connection headers are present in a message that
Hessing Individual submission - Expires October 2002 15
draft-hessing-p2p-messaging-00.txt April 2002
these headers should also be used to determine whether or not a
message is a duplicate message.
It is anticipated that a messages sent over an end-to-end connection
between servents would be using two Connection headers, one for
indicating which information is being sent in the message and one
header to indicate which information has already been received by
the other servent.
4.8. Authentication header
The Authentication header MUST be included in a message when:
. A message is sent that uses the Authentication for Path
Security (see the section on Path security for more
information)
. A message contains a Community Description header for a
community with a Community Join Requirement of AUTHENTICATED
(see the sections on Community announcements and Joining a
Community for more information)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header type (0x000D) | Header length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fingerprint (0 .. 19) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| String (0 .. n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fingerprint is the 20 byte SHA1 hash of the public key packet-
tag followed by the 2 byte value of the length of the public key
followed by the entire public key packet.
The string contains the result of the authentication algorithm over
the public key SHA1 hash of the message contents. All message
content that is used to compute the Checksum header is also used to
calculate the SHA1 hash.
4.9. Encryption header
A message using encryption for Path Security (see the section on
Path security for more information) MUST include the Encryption
header in the message.
Hessing Individual submission - Expires October 2002 16
draft-hessing-p2p-messaging-00.txt April 2002
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header type (0x000E) | Header length (0x1C) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fingerprint (0 .. 19) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All the capability headers and the message payload MUST be
encrypted. The protocol headers MUST NOT be encrypted. The
fingerprint allows the destination servent to select the right
public key to decrypt the message.
The fingerprint is the 20 byte SHA1 hash of the public key packet-
tag followed by the 2 byte value of the length of the public key
followed by the entire public key packet.
4.10. Error header
A servent SHOULD send an error message, that is, a message with an
Error header, in response to a message that has generated an error.
It should send this Error message only if the error has not caused
the connection over which the message was received to be ceased. The
servent uses the Source Servent ID of the message that has caused
the error as the Destination Servent ID in the Error message. The
Error message is send via the community to which the original
message belonged.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header type (0x000B) | Header length (0x0006) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error code | Error Subcode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An Error message MUST NOT be send if the Source Servent ID of the
original message used the anonymous Servent ID of 0x0000.
An error message MUST consist of the PPMP header, the Error header
and a Checksum header if the message is send over a transported
mechanism which does not validate the correct transmission of the
message. An error message SHOULD include in its payload the headers
of the message that generated the error. No other headers SHOULD be
included in the message. The total length of the Error message
SHOULD NOT exceed 1000 bytes.
The following Error Codes and Sub-codes are defined:
Error Error Message code Message sub-code
Code Sub-
code
Hessing Individual submission - Expires October 2002 17
draft-hessing-p2p-messaging-00.txt April 2002
1 0 Unknown error N/A
2 0 Message error Unspecified reason
2 1 Message error Checksum error
2 2 Message error Malformed PPMP header
2 3 Message error Undefined header type
2 4 Message error Invalid header length
2 5 Message error Message length unknown
2 6 Message error Invalid flags
2 7 Message error Invalid header type
2 8 Message error 'Source Servent does not receive
incoming connections' flag should
not be set
5. Message forwarding
Each community MUST define a set of supported message forwarding
mechanisms out of a list of forwarding mechanisms that are defined
in this protocol and possible future extensions to this protocol.
The source servent selects the forwarding mechanism for a message
from the list supported by the community to which the message will
belong. It encodes the forwarding mechanism to be used in the
Forwarding Mechanism field in the PPMP header of the message. The
rules for forwarding the message for that forwarding mechanism MUST
then be followed by each servent forwarding the message.
A servent that receives a message with a forwarding mechanism that
is not listed in the set of forwarding mechanisms supported by the
community MUST discard the message. A servent MAY NOT change the
forwarding mechanism of a message it has received.
The currently defined forwarding mechanism codes (FMC) are:
FMC Name
0x00 (Reserved)
0x01 Direct connected only
0x02 Broadcast
0x03 Routed
0x04 Fully Defined Path
0x05 Multicast
0xF8-0xFF (Experimental use)
Messages received with a time-to-live of zero MUST NOT be forwarded
to other peers regardless of the forwarding mechanism. When a
message has a time-to-live greater then zero then a servent MUST
decrease the time-to-live in the message before it sends the message
to one or more of its peers.
A servent receiving a message with one of its own Servent IDs as
Destination Servent ID and one or more Path headers MUST ignore the
Hessing Individual submission - Expires October 2002 18
draft-hessing-p2p-messaging-00.txt April 2002
Path headers and process the message as it would have done if the
Path headers are not present.
Messages that do not use the 'Fully Defined Path' forwarding
mechanism but do have one or more Path headers SHOULD be forwarded
based on the value of the first Path header. A servent that receives
one of these messages with the Servent ID in the first Path header
matching one of its own Servent IDs MUST strip this Path header from
the message before forwarding it. The servent SHOULD forward the
message based on the Servent ID value of the next Path header or, if
there are no more Path headers, the value of the Destination Servent
ID.
A message that uses the 'Direct connected only' forwarding mechanism
MUST NOT be forwarded, even if it has a time to live greater than
one or one or more Path headers exist in the message. Servents in
communities that specify 'Direct connected only' as only forwarding
mechanism will have to learn about other servents using services,
capabilities of other communities or out-of-band means. 'Direct
connected only' forwarding mechanism MUST be supported in all
servent implementations as it is used during connection
establishment.
5.1. Broadcasting
Broadcasting is the traditional forwarding mechanism in p2p
networks. A servent receiving a message from peer A for community X
SHOULD forward that message to all of its peers that have announced
community X to it except peer A if the message upon receipt has a
time to live greater then 0. For more information on community
announcements see the section 'Communities'.
It is obvious that this forwarding mechanism leads to great scaling
problems in any p2p network with a large number of servents. If we
take into account however that servents are not required to forward
messages to all its peers but should provide a best effort service
to deliver the message to its destination then there are several
optimalisations possible that reduce the amount of messages on a p2p
network.
A servent is SHOULD optimize its broadcasting algorithm. There are a
number of ways to perform this optimalisation:
- Maintaining a message cache to avoid duplicate messages and to
match 'request' and 'response' messages. As discussed in the section
'Messages' it is possible that a servent receives a message
belonging to the same Community, from the same Source Servent ID
with the same Message-ID and without a Connection header multiple
times. In that case it MUST silently discard all duplicates. This
avoids duplication of messages on the network. The second
Hessing Individual submission - Expires October 2002 19
draft-hessing-p2p-messaging-00.txt April 2002
application of a message cache is to match request and response
messages as will be discussed in the section 'Capabilities'. A
servent receiving a response message for which it earlier received
the corresponding request message from the same Community, with the
same Message ID and where the Source Servent ID of the request
message equals the Destination Servent ID of the response message
SHOULD forward the message only to the peer from which it received
the request message the first time, if there is no Path header
present in the response message. If the servent has never seen the
corresponding request message then it SHOULD forward the message
using the normal broadcasting algorithm.
- Maintaining a servent cache by monitoring messages that it
receives from other peers, whether these messages are destined for
it or not. Each time a servent receives a message it should examine
the Source Servent ID and the hop-count. If a message sourced by
servent A has a lower hop-count then any other message sourced by
servent A then it should note the peer B from which it has received
the message as having the shortest path to servent A. It should then
forward messages destined for servent A only to peer B. Care should
be taken that messages that have one or more Path headers should not
be used to build up the servent cache as their specified routing may
be different then the optimal routing of messages on the p2p
network.
Other message forwarding optimalisations MAY include hierarchical
servent relationships or proxying response messages. Hierarchical
servent relations introduce a client-server relationship into the
p2p model. This can reduce the burden of message forwarding on the
servents acting as a client. Message proxying allows a servent to
provide a response for another servent. This other servent will then
see less messages and this would reduce load on that servent.
Message proxying depends on the capability that is used in the
message. Message proxying techniques are thus defined in the
definition of the capability.
5.2. Routed
It may be possible to develop a routing protocol for p2p networks
although making it scalable will be a complex task. It may be
possible to flood peer information of only a limited number of hops
between peers. Assuming that p2p networks will automatically select
communication between peers that are in close network proximity then
this limited depth flooding may provide sufficient information to
provide significant performance benefits but this is for further
study.
A routing table would need to be maintained for each community as
different community memberships may cause the routing of messages
Hessing Individual submission - Expires October 2002 20
draft-hessing-p2p-messaging-00.txt April 2002
belonging to different communities between two peers may take
different path.
5.3. Fully Specified Path
The Fully Specified Path forwarding Mechanism uses Path headers to
specify every hop in the path between the source and the destination
servents.
A servent receiving a message using the Fully Specified Path
forwarding mechanism MUST first verify that there are one or more
Path headers in the message. If there are no Path headers then the
message MUST be discarded. Otherwise if there are one or more Path
headers in the message then the servent MUST compare the servent ID
of the first Path header of the message with its own Servent IDs. If
the servent ID in the Path header does not match one of its own
Servent IDs then it MUST discard the message. Otherwise it MUST
strip the first Path header from the message and base its message
forwarding on the next Path header.
If there are no more Path headers and the Destination Servent ID
matches one of the Servent Ids of the servent then the servent
SHOULD process the message locally.
If there are more Path headers then it SHOULD forward the message
based on the next Path header. It MUST only forward the message to a
peer if the Servent ID in the Path header matches the Servent ID
announced by the peer during the establishment of the connection to
the peer.
5.4. Multicasting
Messages using the multicast forwarding mechanism MUST be sent using
technologies that allow one to many communication. One such
technology is IP multicast but other technologies are being
researched as well.
There is a difference between multicast forwarding and multicast
transport connections. Multicast forwarding can use IP multicast to
transport messages but other techniques could also be introduced.
Multicast transport can be performed for any message that is
eligible for forwarding and that has the Multicast transport allowed
flag set in the PPMP header.
See the section 'Uni-directional IP multicast connections' on how
messages can be transported using a multicast transport connection.
Hessing Individual submission - Expires October 2002 21
draft-hessing-p2p-messaging-00.txt April 2002
6. Security profiles
Every community has a security profile. This profile defines the
requirements for servents to join a community and the requirements
for the transport of messages and bulk data.
6.1. Requirements for joining a community
A servent can join a community by making a connection to one of more
other servents that are already member of the community and by
negotiating with these peers the use of the community. The initial
list of servents to connect to can be obtained by a service, a
cached list of servents or by manual configuration. Once a servent
has established a connection to a peer that is a member of a
community and has successfully negotiated the use of the community
through exchanging Community Description and Community Authorization
and/or Authentication headers with the peer then he has virtually
complete access to the community.
The community a servent is a member of defines how that servent MUST
validate an incoming request to join the community by another
servent. See the section on Communities on how communities are
negotiated between two peers using Community Description, Community
Authorization and/or Authentication headers.
If the Community Join Requirement is OPEN (CJR code 0x01) then it
SHOULD always accept incoming connections unless there are reasons
for the servent to deny the request, such as an internal blacklist
or resource constraints on the local system.
If the Community Join Requirement is AUTHORIZED (CJR code 0x02) then
the servent requesting to join the community MUST present in the
message with Community Description header a certificate in a
Community Authorization header that is signed by a Certificate
Authority known by both peers.
If the community join requirement is AUTHENTICATED (community join
requirement code 0x03) then the requesting peer MUST include an
Authentication header with a signature created using its own secret
key in the message with the Community Description header. The
receiving peer MUST use the public key it has for the requesting
peer to verify the signature.
The Authentication header does not include its own Community ID
field. For this reason only one community with the AUTHENTICATED
community join requirement can be announced per message.
Only one validation requirement can be supported within a community.
The following Community Join Requirement (CJR) codes are defined:
Hessing Individual submission - Expires October 2002 22
draft-hessing-p2p-messaging-00.txt April 2002
CJR code Description
0x00 (Reserved)
0x01 OPEN
0x02 AUTHORIZED
0x03 AUTHENTICATED
0xF8-0xFF (Experimental use)
Communities that are announced with a reserved or undefined CJR MUST
be ignored.
6.2. Security for the transport of messages
The community can define what set of levels of security is required
for the transport of messages between two servents. There are two
security scopes defined:
- Segment security: The security of sending a message between two
peers. The sending peer can either be sourcing the message or
forwarding a message it has received from another peer.
- Path security: The security of sending the message from the source
servent to the destination servent.
6.2.1. Segment security
Messages can be transported over a connection between two peers only
if a connection is available between the two peers with a security
level that is supported by the community. It is thus possible that
there are multiple connections between two peers to satisfy the
security requirements of multiple communities. This is called
connection duplication between two peers. The connection between two
peers is called a segment in the context of the end-to-end path
between a source servent and a destination servent.
Establishing segment security is not part of this p2p protocol
framework. Segment security MUST be provided by the connection
mechanism used to establish a direct connection between two peers
such as TLS [5] or another mechanism able to provide such security.
When a servent is sending (sourcing or forwarding) a message and it
has multiple connections to a peer, all supported by the community
then it SHOULD use the connection with the least security in order
to optimize performance of the community.
The following Segment Security Codes (SSC) are currently defined for
the connection between two peers:
CLEAR (SSC 0x01): the messages are sent between peers in clear text
Hessing Individual submission - Expires October 2002 23
draft-hessing-p2p-messaging-00.txt April 2002
AUTHENTICATED (SSC 0x02): the connection between two peers MUST
provide authentication of all data that is being send over this
connection.
ENCRYPTED (SSC 0x03): the connection between two peers MUST encrypt
all data that is being sent over this connection.
The overview of Segment Security Codes (SSC):
SSC Description
0x00 (Reserved)
0x01 CLEAR
0x02 AUTHENTICATED
0x03 ENCRYPTED
0xF8-0xFF (Experimental use)
Communities that are announced with a reserved or undefined SSC MUST
be ignored.
6.2.2. Path security
Path security defines the security parameters for the transport of a
message between the source and the destination servent.
The following Path Security Codes (PSC) are defined:
CLEAR (PSC 0x01): the messages are send in clear text
AUTHENTICATED (PSC 0x02): the message MUST include an Authentication
header.
ENCRYPTED (PSC 0x03): the message MUST be encrypted and MUST include
an Encryption header.
It is possible that there are multiple servents for which the
message is destined when multi- or broadcasting is used for the
transport of the message. Path security must always use the option
CLEAR when a message is destined to multiple servents. The options
AUTHENTICATED or ENCRYPTED can only selected when unicast forwarding
is used. This is expected to change in future revisions of this
specification.
The overview of Path Security Codes:
PSC Description
0x00 (Reserved)
0x01 CLEAR
0x02 AUTHENTICATED
0x03 ENCRYPTED
0xF8-0xFF (Experimental use)
Hessing Individual submission - Expires October 2002 24
draft-hessing-p2p-messaging-00.txt April 2002
Messages that are received with a Path Security Code that is either
reserved or undefined SHOULD be discarded by the servent that
receives such a message.
6.3. Data security
The transport of bulk data within messages (in-band bulk data
transfer) can use the security provisions that are available to the
transport of messages. The transport of bulk data between two
servents directly where the connection is made specifically for this
data transport and where the use of the PPMP protocol is not
required (out-of-band data transfer) can use the transport protocol
defined in the section 'Out of band data transport' or any other
transport protocol that a community wishes to define. This transport
protocol will then provide the security for the data transport.
7. Connection setup and maintenance
Connections between servents are used to transport messages from one
servent to another. Servents that have a direct connection to each
other are called peers. Connections can be made between two or more
peers. The servent initiating the connection is called the
requesting peer. The servents to which the connection is made are
called the receiving peers.
A single connection can be used for passing messages belonging to
different communities. This is called connection sharing. A
connection does thus not belong to a community. A connection is an
available resource that can be used by a community if it meets the
security requirements of the community.
Different technologies are supported through which the connection
can be established. A small number of connection mechanisms are
described in this document but future revisions of this document or
other standards can specify additional technologies. The mechanism
is not required to be reliable, nor are there real-time
requirements. It is thus possible that a message send by a peer over
a connection is not received by the other peer nor is it guaranteed
that the message will be received within a specific time frame. A
connection mechanism will also not need to guarantee that messages
are transmitted in the order they were sent.
A transport mechanism MUST define the maximum size of a message
which can be transported over the connection without the use of the
Connection header. It MUST also specify whether the connection will
be reliable and whether the connection validates that messages have
been transported without errors.
Hessing Individual submission - Expires October 2002 25
draft-hessing-p2p-messaging-00.txt April 2002
Communities requiring reliable message transport MUST specify this
in their definition.
Communities MAY NOT specify which technology is used for the
transport of messages. They MUST specify the security requirements,
whether messages MUST use reliable transport between peers and
whether multicast forwarding is permitted. Messages belonging to a
community that has not required the use of reliable connections can
still be transported over reliable connections.
Connection Transport Codes (CTC) are 8 bit values and are amongst
others used in Ping messages (see the section on the Ping
capability). The following Connection Transport Codes are defined:
CTC Description
0x00 (Reserved)
0x01 TCP
0x02 TLS
0x03 UDP [6]
0x04 UDP/Multicast
0xF8-0xFF (Experimental use)
CTC 0x01 uses TCP to provide reliable, error-free transport of
messages of unlimited length. It provides bi-directional
communication between two peers and connections and communities MUST
be negotiated.
CTC 0x02 uses TLS to provide reliable, error-free transport of
messages of unlimited length. It provides bi-directional
communication between two peers and connections and communities MUST
be negotiated. Connections over TLS work conceptually the same as
over TCP. The requesting peer connects to the receiving peer on the
appropriate port, acts like a TLS client and sends a TLS ClientHello
to begin the TLS handshake. When the TLS handshake is finished it
starts negotiating the connection. All messages MUST be sent as TLS
'application data'. Connections made using TLS MUST initiate an
exchange of closure alerts before closing a connection.
CTC 0x03 uses UDP to provide unreliable, error-free transport of
messages of up to 1400 bytes. A servent MUST ensure that UDP
checksums are enabled on the host it is running. CTC 0x03 provides
bi-directional communication between two peers and connections and
communities MUST be negotiated.
CTC 0x04 uses UDP to provide unreliable, error-free transport of
messages of up to 1400 bytes. A servent MUST ensure that UDP
checksums are enabled on the host it is running. CTC 0x04 provides
uni-directional community from a servent to a set of peers.
Connections and communities MAY NOT be negotiated.
Hessing Individual submission - Expires October 2002 26
draft-hessing-p2p-messaging-00.txt April 2002
A special community is defined for messages used for connection
setup and maintenance: the Connection Management Community
(Community ID 0x0000). Messages send to this Community MUST have an
initial Time to Live of 1 and the forwarding mechanism MUST be
Direct Connected Only (see the section on forwarding mechanism
negotiation for the single exception to this rule). The Source
Servent ID MUST be the Servent ID that was used during the
connection setup and the Destination Servent ID MUST be the Servent
ID that the peer announced during the connection setup.
7.1. Bidirectional Connections
The establishment of bi-directional connections consists of:
. Establishing the transport connection
. Negotiation the connection parameters
. Negotiation of supported forwarding mechanisms
. Breaking the connection if a connection collision has occurred
When peers attempt to establish a bi-directional connection they
exchange a sequence of connection establishment messages. The
connection will be in 'handshake' state during this sequence. If one
of the messages during the handshake is not received within a
specified time interval or a message is received out of sequence
then the connection establishment has failed and the peer
determining the failure MUST send a CEASE message to the other peer,
MUST cease the connection and SHOULD release any resources reserved
to establish the connection.
Two peers MUST agree on the following parameters before starting to
transmit messages over the connection:
. Connection mechanism
. Servent ID of both the requesting and the receiving peer
. P2P protocol version
. Time out value
. Forwarding mechanisms supported
When the two peers have agreed on these parameters then the
connection becomes operational. The peers will then start also
exchanging messages belonging to communities other then the
Connection Management Community.
7.1.1. Establishing a bi-directional transport connection
This document defines UDP, TCP and TLS as bi-directional connection
mechanisms. They provide error-free transport of messages between
two peers. By accepting an incoming UDP, TCP or TLS connection the
receiving peer agrees to use it as connection mechanism. When a
requesting peer supports multiple connection mechanisms, it can
cycle through the different mechanisms in the order it prefers until
a connection has been successfully negotiated. It can also establish
Hessing Individual submission - Expires October 2002 27
draft-hessing-p2p-messaging-00.txt April 2002
multiple connections using different connection mechanisms to
optimize message delivery.
Even though UDP is a connection-less protocol, in a P2P network it
is used for negotiating a bi-directional connection between two
servents.
The receiving peer MAY send a CEASE message after accepting the
incoming connection with the cease code for 'Connection Denied',
with the sub-code for 'Administratively prohibited'.
While the connection is in 'handshaking' state, all messages MUST
only consist of the following headers:
. Basic header.
. Checksum header if the connection mechanism is not error-free.
. CEASE header if an error occurred
These messages MUST use the Connection Management Community.
7.1.2. Negotiate bi-directional connection parameters
After establishing the communication path and thus agree on the
transport mechanism, the peers first MUST have to agree on the
Servent IDs. The requesting peer MUST send a message with the
parameters:
. Source Servent ID: the servent IDs it wishes to use to
communicate with the receiving peer for Connection Management
messages.
. Destination Servent ID: because the requesting peer does not
know the Servent ID of the receiving peer, the requesting peer
MUST use a Destination Servent ID of all ones.
. Protocol Version: protocol version that the requesting servent
prefers to use. The only protocol version defined in this
document is version 1.
. Message-ID: This MUST be set to the proposed connection time-
out value in seconds. A time out value of zero means that no
time out timer will be maintained. Only during connection
establishment time is this field to be allowed to be used for
this purpose.
The receiving peer MAY send one the following CEASE messages:
. A CEASE message with the cease code for 'Message errorÆ with
the cease sub-code for 'Invalid checksum' if the checksum does
not match the contents of the message.
. a CEASE message with the cease code for 'Connection Denied'
with the sub-code for 'Servent ID unacceptable'
. a CEASE message with the cease code for 'Connection Denied'
with the sub-code for 'Protocol version not supported' if the
protocol version is not acceptable and it does not support or
Hessing Individual submission - Expires October 2002 28
draft-hessing-p2p-messaging-00.txt April 2002
does not wish to announce the support of another protocol
version.
. a CEASE message with the cease code for 'Connection Denied'
with the sub-code for 'Time out value unacceptable'
If no error occurred the receiving peer SHOULD send a message
consisting of the parameters:
. Source Servent ID: the Server ID it wishes to use to
communicate with the requesting peer for connection management
messages.
. the Destination Servent ID it has just received as Source
Servent ID from the requesting peer.
. Protocol Version: either the protocol version proposed by the
requesting peer or the protocol version that it prefers itself.
. Message-ID: either the time out value proposed by the
requesting peer or the time out value that it is proposing
itself. A time out value of zero means that no time out timer
will be maintained.
On receiving the message, the requesting peer MUST validate:
. The checksum and send a CEASE message with the cease code for
'Message error' and the sub-code for 'Invalid checksum' if the
checksum does not match the contents of the message.
. The Destination Servent ID, if it does not matches its own
announced Servent ID it MUST send a CEASE message with the
cease code for 'Connection Denied' and the sub-code for
'Servent ID unacceptable'
. The Protocol Version, it does not match its own announced
Protocol Version then it MUST evaluate whether the Protocol
Version announced by the receiving peer is acceptable. If not
then it MUST send a CEASE message with the cease code for
'Connection Denied' with the sub-code for 'Protocol version not
supported'. If the proposed Protocol Version is acceptable then
this protocol version MUST be used for all further
communication over this connection.
. The time-out value specified in the Message-ID. If it does not
match its own announced time-out value then it MUST either
accept the received time-out value or send a CEASE message with
the cease code 'Connection Denied' with the sub-code for 'Time
out value unacceptable'.
7.1.3. Negotiate supported forwarding mechanisms for bi-
directional connections
If the two peers agree on the values for the Source and Destination
Servent IDs, Protocol Version and Time out value then they start
announcing which forwarding mechanisms they support. For each
forwarding mechanism a peer supports it will send a message
belonging to the Connection Management Community. The PPMP header
MUST be used to indicate which forwarding mechanism is supported.
Hessing Individual submission - Expires October 2002 29
draft-hessing-p2p-messaging-00.txt April 2002
This behavior is only allowed during the connection handshake, all
other messages belonging to the Connection Management Community MUST
use the Direct Connected Only forwarding mechanism as described in
the beginning of this chapter.
Each peer MUST compute the subset of its own supported forwarding
mechanisms and the supported forwarding mechanisms as announced by
the other peer. This is the set of forwarding mechanisms supported
by this connection. Only messages using one of these forwarding
messages are eligible to be sent over this connection.
The Direct Connected Only forwarding mechanism must be announced as
the last forwarding mechanism. Servents MUST always announce this
forwarding mechanism because it is required to be implemented. This
message will indicate the end of the negotiation of forwarding
mechanisms.
7.1.4. Breaking bi-directional connection collision
At this time connection collision can be detected. There are three
possibilities:
. There is no connection collision.
. There are two or more connections between two identical
servents with the same IP address pair, and the same Servent
IDs but either the connection transport or the Protocol Version
does not match. In this case there is no connection collision
but care SHOULD be taken that messages are only sent over one
of the two connections.
. There are two connections between two identical servents, both
with the same IP address pair, the same Servent IDs, the same
connection transport, the same Protocol Version and where the
set of supported forwarding mechanisms of one connection is
equal to or a subset of the set of supported forwarding
mechanisms of the other connection. In this case a connection
collision has occurred. When this occurs the requesting peer
MUST select the connection with the smallest set of supported
forwarding mechanisms and send a CEASE message with the cease
code 'Connection Denied' with the cease sub-code for
'Connection collision detected' and CEASE the connection. If
the two sets of supported forwarding mechanisms are equal then
the servent MUST cease the connection that has been established
the shortest time.
If there is no connection collision then the connection becomes
operational and is available for general use.
When a new bi-directional connection is established that has the
same IP address pair, the same Servent IDs, the same connection
transport, the same Protocol Version and where the set of supported
forwarding mechanisms is a superset of an existing connection then
Hessing Individual submission - Expires October 2002 30
draft-hessing-p2p-messaging-00.txt April 2002
this existing connection SHOULD be ceased with the cease code for
'Connection info' with the cease sub-code for 'Better connection
available'.
7.1.5. Keepalive messages for bi-directional connections
If peers have negotiated a time-out value larger then 0 for a bi-
directional connection then they MUST maintain a timer that SHOULD
be reset every time a message is received over the connection. A
peer SHOULD cease the connection if no messages have been received
over the connection from the other peers during the duration of the
time-out value. The CEASE message MUST use the cease code for
'Connection error' with the sub-code for 'Time out timer expired'.
When a message is received over a connection, it is not relevant
whether it is a duplicate or whether its checksum is valid for
resetting the timer.
A servent MUST also maintain a timer per bi-directional connection
to ensure that it sends at least one message over the connection
during the time-out interval. If no regular messages are available
for sending over the connection then a peer SHOULD generate a
Keepalive message. A Keepalive message MUST belong to the Connection
Management community and MUST only include the PPMP header and the
Checksum header if the connection over which the message is send is
does not validate the error-free transport of a message.
Keepalive messages are also used to monitor the performance of the
connection. They are used to measure the amount of packet loss and
delay between two peers. A servent MAY send a Keepalive to the other
peer for performance management. This message MUST belong to the
Connection Management community and use a unique Message-ID. The
peer recognizes that the message was not initiated by itself through
the Message-ID and MUST respond immediately with a Keepalive message
with the same Message-ID. The servent that originated the Keepalive
recognizes the Message-ID of the Keepalive message as one that it
has generated itself and calculates the delay between sending the
original Keepalive and receiving the response.
The servent MAY use the message delay and message loss values to
trim its set of peers to the best performing and cease the
connections to the worst performing peers.
A servent MUST of course take into account that connections using a
reliable transport mechanism will not experience message loss.
Keepalive messages with a Message-ID of 0x00 are not intended for
performance management. Servents SHOULD NOT respond to these
Keepalives with a Keepalive message with the same Message ID.
Hessing Individual submission - Expires October 2002 31
draft-hessing-p2p-messaging-00.txt April 2002
7.2. Multicast, unidirectional connections
The establishment of a multicast uni-directional connection by a
servent consists of the following steps:
. Determining whether the servent should start forwarding
messages using multicast for a community
. Announcing that the servent is forwarding messages to a
multicast group
. Receiving feedback that there are listeners on the multicast
group
A servent MAY forward messages for a community using multicast if:
. It is a member of the community.
. The community has not specified that reliable transport is
required
. The community has specified that multicast forwarding is
permitted.
. The community join requirement code is OPEN (0x0001).
. The community does not have asymmetric key encryption as only
option for segment or path security.
. It is not already receiving messages for that community using
multicast even though it has attempted to do so.
. It has sufficient bandwidth available to forward messages.
. If does not have reasons to believe that its messages send via
multicast are not received by a significant group of servents.
The last requirement is kept vague intentionally. As IP multicast
groups may become a scarce resource the number of IP multicast
groups should remain limited. A servent should thus be confident
that its use of IP multicast adds significant value to the
community.
7.2.1. Multicast Session Announcement header
The servent using multicast to forward messages for a community MUST
periodically announce this forwarding channel to the community using
the Multicast Session Announcement header in a message sent to the
community for which it is using multicast:
Hessing Individual submission - Expires October 2002 32
draft-hessing-p2p-messaging-00.txt April 2002
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header type (0x000A) | Header length (0x000C) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CTC | Port | Interval (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interval(1) | Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Multicast IP address: class D address.
CTC: Connection Transport used for this session.
Port: port used for the connection transport.
Bandwidth: Maximum bandwidth in Kbit/s that the servent will forward
messages using this multicast transport session.
Interval: a servent receiving messages using multicast from this
servent SHOULD send a Multicast Session report once during every
interval.
A servent does not negotiate a community over a multicast uni-
directional connection as it would over a bi-directional connection.
The originating servent can assume that servents listening to the
multicast connection already are a member of the community because
the originating servent MUST only announce the multicast session
using a message belonging to the community it will multicast. The
servents listening to the multicast session thus know about the
specification of the community and can validate the messages against
this specification.
Servents MUST consider the expected bandwidth requirements before
joining a multicast session.
7.2.2. Multicast Session Report header
Servents receiving messages belonging to a community using a
multicast connection SHOULD send a report back to the servent
transmitting the community once during every interval specified in
the Interval field in the Multicast Session Announcement header.
These servents MUST use the Multicast Session Report header in a
message belonging to the community and MUST send that message to the
originator of the multicast session. The originator of the multicast
session can be determined by the received Multicast Session
Announcement messages.
Hessing Individual submission - Expires October 2002 33
draft-hessing-p2p-messaging-00.txt April 2002
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header type (0x000C) | Header length (0x0004) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Servents receiving a Multicast Session Report destined for another
servent SHOULD check whether they already have sent or forwarded a
Multicast Session Report message to this destination servent for the
same multicast session during the last reporting interval. If that
is the case then the servent SHOULD drop or delay the message to
ensure that it only sends or forwards one Multicast Session Report
per interval towards the servent originating the multicast
connection. If a servent receives a Multicast Session Report for a
multicast session it has not previously received a Multicast Session
Announcement then it SHOULD forward the message to the destination
servent without using the inverse proxying algorithm described
above.
7.2.3. Sequence header
Every message that is send using multicast transport MUST include
the Sequence header. The Sequence header is included in the Checksum
header and the servent sending a message over a multicast transport
MUST calculate the checksum if a checksum header is included in the
message and/or the message is using a transport mechanism that does
not support error detection. The Sequence header length is 8 bytes.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header type (0x000F) | Header length (0x0008) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Every time a servent forwards a message using multicast transport
for a certain community it MUST increment the sequence number for
that community by one. This increment allows receiving servents to
notice when message loss occurs. A servent noticing significant loss
of messages MUST leave the multicast session.
7.2.4. Forwarding messages over multicast transport
Messages using the forwarding mechanism 'MulticastingÆ can be send
over multicast connections. Messages using other forwarding
mechanisms that have the 'Multicast transport allowedÆ flag set in
the PPMP header SHOULD be forwarded according to the rules of the
forwarding mechanism and MAY be forwarded using a multicast
connection. If a servent forwards such a message using a multicast
connection then it MUST NOT change the forwarding mechanism value in
the PPMP header.
Hessing Individual submission - Expires October 2002 34
draft-hessing-p2p-messaging-00.txt April 2002
A servent receiving a message using multicast transport MUST NOT
further forward that message even if that message would otherwise be
eligible for forwarding.
8. Communities
In the context of p2p networks, communities are defined by:
. Their membership requirements, i.e. open, authorized by well-
known entity, authenticated by direct peers
. Security requirements for the transport of messages and data
. Capabilities: supported message headers
. Services: key servers, network management servers
. Message forwarding mechanisms: directly connected only,
broadcast, routed, multicast, specified path
. Connection types: uni- or bi-directional, reliable, error-free,
real-time, multicast
Peers MAY exchange messages belonging to a community only if the
peers sharing the connection agree on the attributes of the
community.
The Community ID values are grouped as follows:
Community ID Community Remarks
0x00000000 Connection
Management Community
0x00000001 Network Management
Community
0x00000002 - (reserved) Well-known communities
0x01FFFFFF MUST be registered with
IANA before use
0x02000000 - Dynamically assigned,
0x09FFFFFF globally unique
0x0A000000 - Dynamically assigned,
0x0A999999 locally scoped
0x0B000000 - (reserved) Applications to be defined
0xFFFEFFFF
0xFFFF0000 - (Experimental use)
0xFFFFFFFF
Well-known communities MUST be registered with IANA before they can
be used. Dynamically assigned, globally unique communities MAY be
initiated by a servent that wishes to start a (semi-) permanent
community available to all servents using this protocol. Dynamically
assigned, locally scoped communities MAY be created by servents
wishing to initiate a community with a limited time of existence and
a limited number of communities.
Hessing Individual submission - Expires October 2002 35
draft-hessing-p2p-messaging-00.txt April 2002
8.1. Community Announcements
After a connection that supports community negotiation has become
operational, peers MAY exchange messages to announce that they are
willing to accept messages for a community, as long the peers agree
on the attributes of the community and the community join
requirements are met. These messages use the Community Description
and the Community Authorization headers, as discussed in the next
two sections.
A servent MAY create a community with a specific Community ID if
that Community ID is in the range of dynamically assigned Community
IDs and the servent has no knowledge of communities using the same
Community ID. When the servent creates the community, it also
defines the community attributes. It SHOULD then send a message with
a Community Description header and possibly a Community
Authorization header or an Authentication header for the newly
created community over each of its operational connections. The
servent may then receive announcements for the community back from
one or more of its peers if a peer has accepted the community. The
servent MAY then start sending messages to each peer that has
accepted the community.
Each servent MUST support the Community Description capability. The
support for the Community Authorization- and the Authentication
capabilities is optional. A servent that does not support either of
these capabilities but receives a message with such a capability
MUST ignore the capability and the Community Description header to
which the unsupported capability references.
When a servent finds that the attributes of a community it receives
through a Community Description message do not match the attributes
it has stored itself for that community then this is called a 'split
community'. The servent MUST reject the Community Announcement
message for such a community from its peer. The peers MUST NOT
exchange messages belonging to the community over that connection.
This should never happen with well-known communities. It can happen
with dynamically assigned Community IDs and it can be expected to
happen with dynamically assigned locally scoped Community IDs.
Upon receipt of a Community Announcement message for a community of
which it had no prior information a servent MAY accept this
announcement. If the servent accepts the community then it MUST send
a message with a Community Description header matching the original
announcement to the peer from which it received the announcement.
The servent MAY also send Community Announcement messages for the
community over some or all of its operational connections to
propagate the information about the community to its other peers.
Hessing Individual submission - Expires October 2002 36
draft-hessing-p2p-messaging-00.txt April 2002
Starting communities which have a Community Join Requirement other
then OPEN will require some external means of establishing
authentication. For communities that use the AUTHORIZED join
requirement the HTTP URL in the Community Description header could
point to a web site where users can establish an identity and have
the certificate authority used by that community validate that
identify.
The Connection Management community MUST never be announced over a
connection.
A servent MAY indicate that it no longer wants to receive messages
belonging to a community by sending a Community Description header
to its peers withdrawing that community. A servent receiving a
message over a connection from a peer with a Community Description
header withdrawing a community MUST stop sending messages belonging
to that community to that peer over that connection.
Communities with a Community ID out of the dynamically assigned
range SHOULD be removed by a servent when the community is not
statically configured in the servent, it has not created the
community itself and it does not have any operational connections
over which it has received announcements for the community. This can
occur when:
. Its peers have not announced the community (back) to it
. Its peers have sent it a message with a Community Description
header withdrawing the community.
. All the connections over which it has received an announcement
for the community have been terminated
A peer SHOULD keep a timer on when it has last received a message
belonging to a community that uses a dynamically assigned Community
ID. This timer SHOULD also be reset whenever it receives a Community
Description message for that community. The peer SHOULD send a
message with a Community Description header withdrawing the
community over all its connections which it has previously announced
the community if it has not received any messages for that community
for twenty-four hours.
A servent MAY send duplicate announcements for a community to a peer
to avoid that the community will time-out on that peer.
8.2. Community Description header
A Servent MAY send a message with one or more Community Description
headers for one or more communities over an operational connection
that supports community negotiation. By sending a Community
Description header, the servent announces that it is willing to
accept messages for the community specified in the header, as long
as the attributes of the community matches with the information
Hessing Individual submission - Expires October 2002 37
draft-hessing-p2p-messaging-00.txt April 2002
about the community of the peer that is receiving the Community
Description header and the Community Join Requirements are met. A
Community Description header can only be used together with the PPMP
header, the Checksum header, the Authentication header, other
Community Description headers and Community Authorization headers.
The message containing the Community Description header(s) MUST
belong to the Connection Management Community (0x00000000).
A Community Description message for a community that has a Community
Join Requirement of AUTHORIZED MUST include a Community
Authorization header. A Community Description message for a
community that has a Community Join Requirement of AUTHENTICATED
MUST include an Authentication header.
The Community Description header is a variable length header and has
the following lay-out:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header type (0x0005) | Header length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Community ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status| Flags | Join Req. | Attributes(0)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes (1 .. n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| URI (0 .. n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
There are currently three different community status values defined:
(Reserved) (0x00), Active (0x01) and Withdrawn (0x02). The Values
0x06 and 0x07 are for experimental use.
The bits in the Community Description flags field have the following
meaning:
Bit Value
0 0 = Messages can be send both over reliable and unreliable
connections
1 = Reliable transport between peers is required for any
message belonging to this community
1 0 = Real-time transport is allowed
1 = Real-time transport is required
2 0 = Multicast transport is not allowed
1 = Multicast transport is allowed
3 0 = Record route requests are not allowed
1 = Record route requests are allowed
4 0 = Payload is not included in the checksum
1 = Payload is included in the checksum
5 0 = A servent MUST use only one Servent ID for both
Hessing Individual submission - Expires October 2002 38
draft-hessing-p2p-messaging-00.txt April 2002
joining the community and sending messages to it
1 = A servent MAY use different Servent IDs for joining
and sending messages to the community.
6 0 = Messages with the anonymous (0x00) Source Servent ID
are not allowed.
1 = Anonymous messages are allowed
7-11 (reserved)
The Join Requirement field specifies the Join Requirement Code for
the community.
The attributes supported by the community are announced sequentially
in the header. Attribute sequences thus have a variable length. Each
sequence of attributes is terminated by a null value. This null
value has the same bit length as the attribute which sequence it
terminates. Attribute sequences are sent in a specific order so that
the receiving servent can parse the header.
Attribute Representation
Supported Forwarding mechanisms 8 bits
Supported Segment security codes 8 bits
Supported Path security codes 8 bits
Supported out-of-band data transport mechanisms 8 bits
Capability 24 bits
The Capability attribute is a tuple consisting of a 16 bit
Capability value followed by an 8 bit Capability Support Requirement
(CSR). A 16 bit Capability value of null terminates the list of
capabilities that are supported by the community. The Capability
Support Requirement values are defined to:
. (Reserved) 0x00
. Processing Required (0x01): A servent that can't process and
forward this capability MUST reject the Community
. Forwarding Required (0x02): A servent that doesn't support the
forwarding of messages with this capability according to the
forwarding rules for this Capability MUST reject this
community.
. Optional (0x03): A servent does not need to support this
capability, the capability is optional
. 0xF8-0xFF: (Experimental use)
A servent receiving a Community Description message that lists
attributes that it considers undefined MUST reject the community.
A servent receiving a Community Description message that doesn't
list a forwarding mechanism it supports MUST reject the community.
A servent receiving a Community Description message that doesn't
list a segment security code it supports MUST reject the community.
Hessing Individual submission - Expires October 2002 39
draft-hessing-p2p-messaging-00.txt April 2002
A servent receiving a Community Description message that doesn't
list an out-of-band data transport mechanism it supports MAY accept
the community.
An optional URI describing the community can be appended to the
header after the last community attribute is terminated with a null
value. The length of the URI can be determined by taking the header
length value and decrementing that by the number of bytes read up to
the start of the URI. The use of the URI information is not formally
defined but could be used to direct the servent to an out-of-band
authentication service or other resource. A community may specify
the exact use of the URI.
8.3. Community Authorization header
If the community has a community join requirement of AUTHORIZED
(0x02) then a Community Authorization header MUST accompany the
Community Description header in the message.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header type (0x0006) | Header length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Community ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| String (0 .. n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The string is a DER encoded X509 [7] certificate which includes the
public key of the requesting peer signed by a Certificate Authority
known by both peers. The digital signature is over the PPMP header
excluding the hop-count and time-to-live fields and the Community
Description header for the community.
If the signed certificate is not valid then Community Description
header and the Community Authorization header for the community MUST
be discarded.
9. Out-of-band Data Transport
Servents wishing to exchange resources that require a significant
amount of bandwidth MAY chose to do so using Out-of-band Data
Transport (ODT). This section lists a number of available ODT
mechanisms with references to their protocol definitions. Each
community MUST define which ODT mechanisms it supports.
ODT code Protocol
0x00 (reserved)
0x01 HTTP [8] GET
0x02 HTTP PUT
Hessing Individual submission - Expires October 2002 40
draft-hessing-p2p-messaging-00.txt April 2002
0x03 HTTP over TLS [9] GET
0x04 HTTP over TLS PUT
0x05 IP MULTICAST
0xF8-0xFF (Experimental use)
Currently Reliable Multicast Transport (RMT) is being defined the
RMT working group in the Transport Area of the IETF. This working
group is in the process of defining the building blocks of RMT.
These building blocks can be used to specify multicast transport
suitable for p2p networks. This specification can either occur in
this work in progress or in a separate document.
10. Capabilities
A capability is some functionality that is supported by a community.
A capability consists of a capability-specific header and optionally
an interpretation of the message payload.
Each capability MUST define:
. Capability header, its header code, its header length (fixed or
variable), is the header included in the checksum and
authentication or encryption headers?
. Does the capability have to be fully supported by a servent
joining the community?
. Does the header provide a specification for the message
payload, and if so, is the payload included in the checksum and
authentication or encryption headers?
. Is this a Request message, and if so what are the Response
capabilities?
. Is this a Response message, and if so, to what Request
capabilities
Messages that are a response to another message MUST use the same
Community and the same Message-ID as used in the corresponding
Request message. The Response message MUST use as Destination
Servent ID the Source Servent ID of the corresponding Request
message. A Capability can be a combination of both a Response to
another message and a Request to one or more Servents. A capability
can be Response message but can also be send without a corresponding
Request message.
Headers defined by capabilities MUST come after any headers as
defined in the previous chapters. Multiple capability headers can be
grouped in one message as long as at most one capability header
provides a specification for the message payload.
Hessing Individual submission - Expires October 2002 41
draft-hessing-p2p-messaging-00.txt April 2002
10.1. Ping capability
The Ping header MUST be included in the checksum and any
authentication or encryption headers. The message length is fixed at
0x0004 bytes. The header does not specify the message payload.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header type (0x0100) | Header length (0x0004) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Pings can either be sent to a specific Servent ID or to the
broadcast address. A ping message MAY NOT use the anonymous servent
ID as source servent ID. A Ping message is a request for a Pong
message.
10.2. Pong capability
The Pong header MUST be included in the checksum and any
authentication or encryption headers. The message length is fixed at
0x0004 bytes. The header does not specify the message payload.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header type (0x0101) | Header length (0x0004) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Pong message is a response to a Ping message. The Pong message
MAY be send anonymously but this is not advisable as it will then
only provide limited information to the requesting Servent.
10.3. Servent Discovery capability
The Servent Discovery header MUST be included in the checksum and
any authentication or encryption headers. The message length is
fixed at 0x0004 bytes. The header does not specify the message
payload.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header type (0x0102) | Header length (0x0004) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Pong message is a request for a Hello message.
10.4. Hello capability
The Hello header MUST be included in the checksum and any
authentication or encryption headers. The message length is variable
Hessing Individual submission - Expires October 2002 42
draft-hessing-p2p-messaging-00.txt April 2002
with a minimum length of 0x000C. The header does not specify the
message payload.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header type (0x0103) | Header length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Uptime | Phy. If. speed|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CTC (0) | Port (0) | .. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .. | CTC (n) | Port (n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The uptime value SHOULD contain a 24-bit number of seconds that have
elapsed since the host started providing services using this p2p
protocol specification. The physical interface speed value MUST use
the class value of the following 'interface speed' table that
matches closest the physical interface with the highest capacity
over which it accepts incoming P2P connections. A physical interface
speed value of '0' indicates that the servent sending the hello does
not want to announce this information.
Class 0 1 2 3 4
Speed N/A 56.1Kbit 256Kbit/s 512Kbit/s 1.5/2Mbit/s
Class 5 6 7 8 9
Speed 10Mbit/s 45Mbit/s 100Mbit/s 155Mbit/s 620Mbit/s
Class 10 11 12 13 14
Speed 1Gbit/s 2.4Gbit/s 10Gbit/s 40Gbit/s 160Gbit/s
A servent SHOULD use the IP address of the interface over which it
accepts incoming p2p connection supporting the highest bandwidth in
the IP address field. A servent MAY use 0.0.0.0 as IP address to
indicate it wants to keep its IP address private.
Each CTC/Port pair specifies which connection transport mechanisms
are supported on which ports.
Hellos can either be sent to a specific Servent ID or to the
broadcast address. By including information about its uptime and
physical interface speed it allows the other servents in the p2p
network that receive the message to learn about it. The Hello
message is a response to a Servent Discovery message.
10.5. Connection Advise capability
The Connection Advice header MUST be included in the checksum and
any authentication or encryption headers. The message length is
variable with a minimum length of 0x000C bytes. The header does not
Hessing Individual submission - Expires October 2002 43
draft-hessing-p2p-messaging-00.txt April 2002
specify the message payload. It is neither a Request nor a Response
header.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header type (0x0104) | Header length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Uptime | Phy. If. speed|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CTC (0) | Port (0) | .. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CTC (n) | Port (n) | Pref. Len (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP prefix (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .. | Pref. Len (m) | IP prefix (m) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Connection Advise message MAY be send with an anonymous Source
Servent ID. The servent sending out the request MUST use its own IP
address in the IP address field. The uptime, phy. if. speed, CTC and
Port fields use the same encoding as in the Hello header. The
CTC/Port sequence is terminated by two bytes with a null value.
The servent sending a Connection Advice message does so to optimize
connectivity on a transport network level. It advices other servents
that it is providing good p2p connectivity to servents with an IP
address in one of the IP address prefixes included in the header.
A Connection Advice header MUST NOT be included in a message with
the 'Source Servent does not receive incoming connections' bit set
in the PPMP header
10.6. Community Discovery capability
The Community Discovery header MUST be included in the checksum and
any authentication or encryption headers. The message length is
fixed at eighth bytes. The header does not specify the message
payload. It is a Request for a Community Invitation message.
Hessing Individual submission - Expires October 2002 44
draft-hessing-p2p-messaging-00.txt April 2002
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header type (0x010F) | Header length (0x0008) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Community ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A servent can send the Community Discovery capability to a community
like the Network Management community to find out servents that
support a certain community. This can be used to establish
connections to servents that carry a certain community that is not
supported by the current peers of a servent.
10.7. Community Invitation capability
The Community Invitation header MUST be included in the checksum and
any authentication or encryption headers. The message length is
variable with a minimum length of 0x0010 bytes. The header does not
specify the message payload. It is neither a Request nor a Response
header.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header type (0x0105) | Header length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Community ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Uptime | Phy. If. speed|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CTC (0) | Port (0) | .. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .. | CTC (n) | Port (n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The encoding of the Uptime, Phy. If. speed, IP address, CTC and Port
fields is the same as in the Hello capability.
The Community Invite capability is used to invite another servent to
join a community by making a connection to the servent using the IP
address of the IP address field using one of the Connection
Transport mechanisms listed in CTC/Port pairs.
The Community Invite capability can be used stand-alone or as a
Response to a Community Discovery message.
Only servents that can receive incoming connections MAY send the
Community Invite header. A Community Invite header MUST NOT be
Hessing Individual submission - Expires October 2002 45
draft-hessing-p2p-messaging-00.txt April 2002
included in a message with the 'Source Servent does not receive
incoming connections' bit set in the PPMP header.
10.8. XML Query capability
The XML Query header MUST be included in the checksum and any
authentication or encryption headers. The message length is variable
with a minimum length of 0x0004 bytes. The header does not specify
the message payload.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header type (0x0106) | Header length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| XML string (0 .. n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The XML string is the XML compliant [10] ASCII string representing a
query. A community supporting this capability MUST define which
Docbooks may be used in these queries.
The XML Query message is a Request message and the XML Response
message is its response message.
10.9. XML Response capability
The XML Response header MUST be included in the checksum and any
authentication or encryption headers. The message length is variable
with a minimum length of 0x0004 bytes. The header does not specify
the message payload.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header type (0x0107) | Header length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ODTC (0) | Port (0) | .. | ODTC (n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port (n) | URI (0..m) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| XML string (0 .. n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The ODTC/Port tuple fields are a list of Out-of-band Data Transport
mechanisms that can be used to retrieve a resource. This list is
terminated by two bytes with the null value.
The URI field is a null-terminated ASCII string providing the
location where the resource is available for retrieval.
Hessing Individual submission - Expires October 2002 46
draft-hessing-p2p-messaging-00.txt April 2002
The XML string is the XML compliant ASCII string representing a
response to an XML Query header. A community supporting this
capability MUST define which Docbooks may be used in these
responses.
The XML Response header is a response to the XML Request header.
10.10. Resource Push Request capability
The Resource Push Request header MUS
