Subject: [p2p-sip] Revised Draft for possible WG charter

From: bryan at ethernot.org (David A. Bryan)
Date: Mon, 30 Jan 2006 18:06:47 -0500

I've inlined a newer version of the charter draft (minor changes)

Changes are adding the wording below about evaluating NAT
solutions/forwarding to other groups,  changing slightly some wording
in the very last sentence of the first paragraph of the description
(the part about this being an alternative to the conventional
approach), and re-wording the first bullet in what is excluded (used
to say locating users for SIP, now says locating users for SIP-based
communications, since some folks were worried that didn't cover doing
presence/IM with the located resources, which we will likely want as
well as media calls).

No other changes.

I hope this incorporated many (most?) of the suggestions we seemed to
have reached consensus on.

--David Bryan

------

Peer-to-Peer Session Initiation Protocol (P2PSIP)

Chairs:
TBD

RAI Area Director(s):
TBD

RAI Area Advisor:
Allison Mankin

Mailing Lists:
General Discussion: p2p-sip at cs.columbia.edu
Subscribe at: http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip
Archive at: http://lists.cs.columbia.edu/pipermail/p2p-sip/

Description of the Working Group

The purpose of the Peer-to-Peer (P2P) Session Initiation Protocol
working group (P2PSIP WG) is to develop guidelines and mechanisms for
the use of the Session Initiation Protocol (SIP) in settings where
establishing and managing sessions is either partially or entirely
handled by a collection of endpoints (peers) rather than centralized
servers. This is an alternative to the conventional SIP approach which
relies on service provider hosted proxies to which users get assigned
by out-of-band means, usually based on geography, association, or
business reasons.

This is motivated by scenarios where a reduction in cost of equipment
and operation for non-end users is desired, and in situations where
such servers are not available. Some of the scenarios identified
include:

1. Self-organizing and highly available proxy farms, as opposed to the
    fixed hierarchy of IMS-like systems.

2. Disconnected or partly-connected topologies with ephemeral
    relationships such as small office systems (with little or no
    central equipment), mesh networks, emergency response, and
    battlelfield environments.

3. Recovery functions to allow endpoints to communicate in the event a
    central server fails or the endpoints are isolated by a network
    partitioning event.

The working group starts with the following general assumptions:

1. Peer associations groups, which may be called "P2P networks". 'P2P
    overlays", or "P2P federations" will provide namespaces within
    which P2P-SIP resources are identified. These namespaces are
    bounded by the identifier(s) of the peer association group, which
    generally map to domain-level identifiers in the DNS.

2. Session establishment, capabilities negotiation, session
    termination, subscription, notification, messaging, and related
    functions traditionally performed using SIP will continue to be
    performed using SIP. This working group is interested only in the
    mechanisms for locating resources within peer association
    groups. We generally refer to this as the "rendezvous problem".

3. Some elements of each peer association group MAY be rooted in the
    DNS such that they can be used for bootstrapping operations.
    However, a peer association group that is operating entirely in an
    isolated (or disconnected, or autonomous) mode will rely on
    alternate means of bootstrapping the peer association group based
    on the "zeroconf" work.

4. Interactions between peer association groups (or members thereof)
    and other peer association groups or conventional SIP installations
    will be resolved using the resource location model of RFC 3263:
    "Locating SIP Servers".

5. The level of authenticity of identity will vary by the peer
    association group. However, the working group will define at least
    one mechanism that will provide assertion of identity having
    strength equivalent to that provided by the "SIP Identity
    Mechanism" RFC, perhaps by reusing some or all of the mechanism of
    that RFC.

Specifically, the working group will:

1. Document scenarios in which a P2P architecture is appropriate for
    SIP based solutions ("use-cases" document).

2. Develop a general architecture or framework for P2P-based SIP
    applications. This will require evaluating the existing deployed
    and proposed P2P-based SIP solutions for possible incorporation
    into this work.

3. Define a distributed location mechanism for locating users in the
    absence of a central server, including the protocols and algorithms
    needed do establish, maintain, and query the distributed
    information.

4. If SIP extensions are needed to support the peer-to-peer model,
    define requirements for those extensions to be acted on by the SIP
    working group.

5. Select firewall/NAT traversal technique(s) for P2P SIP and integrate
    them into the P2P SIP architecture or framework.  If necessary,
    define requirements for enhancements of existing techniques to be
    acted on by other working groups.

While ensuring:

1. Security is addressed in these systems.

2. Interoperability with existing client-server (CS) SIP and the PSTN.

3. The solutions proposed will function even with some or many nodes
    located behind NATs or firewalls.

4. Existing protocols are reused whenever possible.

The following topics are initially out of the Working Group's scope,
but may be considered in possible future charters:

1. Using P2P mechanisms to manage groups of distributed media relays.

2. Using distributed relays to enable anonymous communications.

3. Creating distributed voice mail systems.

4. Performing distributed search for users based on something other
    than user id.

The following topics are explicitly excluded from the Working Group's
scope:

1. Issues specific to applications other than locating users and
    resources for the full range of SIP-based communications offered
    in a conventional client-server SIP system, including but not
    limited to real-time media, messaging, and presence.

2. Discussion of this technology as a replacement for conventional
    (client-server) SIP.

3. Solving "research" type open questions related to P2P SIP. The
    working group will instead forward such work to the IRTF. A few
    such topics include:
    o Fully distributed schemes for assuring unique user identities.
    o Development of new structured P2P algorithms, such as DHTs.
    o Developing a P2P-based replacements for DNS.

The working group will operate in close cooperation with the SIP,
SIPPING, SIMPLE, MMUSIC and BEHAVE working groups, as well as the
IRTF. Respecting the IETF specification change policy, the working
group will refer any possible changes or extensions as suggestions to
the appropriate WGs as needed. A guiding principal of the WG will be
to avoid extensions or change wherever possible.

Goals and Milestones
Aug 2006        Submit use-cases document to the IESG (Informational)
Jan 2007        Submit architecture document to the IESG (Informational)
Jul 2007        Submit protocol and/or protocol extension documents to
                 the IESG (Standards-track)

---

From: enrico.marocco at TILAB.COM (Enrico Marocco)
Date: Tue, 31 Jan 2006 09:20:01 +0100

> presence/IM with the located resources, which we will likely want as

My worries were about being unable to integrate something like the "reg"
event package, which would be essential for implementing a presence
service without central servers. Now it's ok: thanks.

Enrico

Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please send an e_mail to
MailAdmin at tilab.com. Thank you
====================================================================

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Tue, 31 Jan 2006 07:05:53 -0500

See comments on the draft charter inline.
- Philip

>     battlelfield environments.

"Disconnected or partly-connected topologies"  --- I don't understand
what the above is saying. Do you mean that these nodes are connected
to each other by a private network, but not connected to the Internet?

How can something be only partly connected to the Internet (or partly
connected to another node)?

>     central server fails or the endpoints are isolated by a network

I would like to see a fourth scenario added:

4. Systems of (potentially many) phones or other communications  
equipment,
     interconnected by the Internet or a private network,
     where there is little or no central equipment for cost or other  
reasons.

I think this covers both the Enterprise PBX application that I am  
interested in,
as well as the Consumer Telephony application that I believe others are
interested in.

>     generally map to domain-level identifiers in the DNS.

I want to second Aki Niemi's question about what the second sentence
in the above item is supposed to mean.

Perhaps we could just delete the second sentence?

>     located behind NATs or firewalls.

In the above sentence, I would like to see the phrase ""some or many  
nodes"
replaced by "some to (nearly) all nodes".

> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip