APEX: An Application Datagram Service

TOC

	M. Rose
	Invisible Worlds, Inc.
	March 17, 2001

APEX: An Application Datagram Service

TOC

1. Helpful Reading

2. Operational Taxonomies

3. An Application Datagram Service

4. The Stack

5. Entities

6. Modes

7. Operations

8. Enveloping

9. An Example

10. Another Example

11. Options

12. Attach Operation

13. Bind Operation

14. Data Operation (relay-specific)

15. Security

16. BEEP and per-hop Security

17. Services

18. The Report Service

19. The Access Service

20. The Presence Service

21. Status

TOC

1. Helpful Reading

APEX I-Ds:

draft-mrose-apex-core
draft-mrose-apex-access
draft-mrose-apex-presence

BEEP RFCs 3080, 3081

Instant Messaging memos:

draft-klyne-apex-impp
RFCs 2778, 2779

TOC

2. Operational Taxonomies

Five distinguishing characteristics:

server push or client pull
synchronous (interactive) or asynchronous (batch)
time-assured or time-insensitive
best-effort or reliable
stateful or stateless

For example:

web: pull, synchronous, time-insensitive, reliable, stateless
email push, asynchronous, time-insensitive, best-effort (without DSN), stateless

Messaging applications vary considerably in their operational requirements, e.g., timeliness, reliability, determinism, etc.

These features come at a cost, in terms of both infrastructure and configuration complexity

The underlying service must be extensible to support different requirements in a consistent manner

TOC

3. An Application Datagram Service

APEX is about "application-layer relaying"

Looks like the email model:

well-understood
universally-accepted
highly-scalable

The APEX model is:

lightweight by nature
soft real-time

The APEX model is option-driven, allowing:

flexible control structures
extensible services

APEX provides:

a application-datagram relaying mesh
access control, presence, and reporting services
support for a range of applications, not just IM

The default mode:

immediate delivery
best-effort relaying

The mesh's behavior is modified by self-contained options,

e.g., for reliable delivery, time-sensitive delivery, etc

TOC

4. The Stack

+-------------+
| APEX        |    an APEX process is either:
|     process |
+-------------+        - an application attached
|             |          as an APEX endpoint; or,
|    APEX     |
|             |        - an APEX relay
+-------------+
|             |    APEX services are realized as
|    BEEP     |    applications having a special
|             |    relationship with the APEX
+-------------+    relays in their administrative
|   TCP/IP    |    domain
+-------------+
|     ...     |
+-------------+

TOC

5. Entities

  administrative domain #1        administrative domain #2
+--------------------------+    +--------------------------+
|   +------+               |    |               +------+   |
|   |      |               |    |               |      |   |
|   | appl |               |    |               | appl |   |
|   |      |               |    |               |      |   |
|   +......+     +------+  |    |  +------+     +......+   |
|   |      |     |      |  |    |  |      |     |      |   |
|   |end-  |     |relay |  |    |  |relay |     |end-  |   |
|   | point|     |      |  |    |  |      |     | point|   |
|   +------+     +------+  |    |  +------+     +------+   |
|   |      |     |      |  |    |  |      |     |      |   |
|   | APEX |     | APEX |  |    |  | APEX |     | APEX |   |
|   |      |     |      |  |    |  |      |     |      |   |
|   +------+     +------+  |    |  +------+     +------+   |
|        ||       ||  ||   |    |   ||  ||       ||        |
|        ===========  ================  ===========        |
+--------------------------+    +--------------------------+

             | <-- APEX relaying mesh --> |

TOC

6. Modes

Two modes of operation: endpoint-relay and relay-relay

Both modes are peer-to-peer:

either side can initiate a protocol exchange

Endpoints have names, i.e., "local@domain"

The local-part prefix "apex=" is reserved for APEX services

Relays aren't named, per se

Relays are located using the SRV algorithm:

apex-edge (for the endpoint-relay mode)
apex-mesh (for the relay-relay mode)

TOC

7. Operations

Applications attach as endpoints, 1:N by default

Relays bind on behalf of administrative domains (FQDNs)

Both exchange datagrams (termed "data")

APEX access policies are used for:

authenticating peers
application attachment as an endpoint
endpoint origination of data
relay binding on behalf of a domain

The APEX access service is used for:

controlling access for endpoint reception of data
controlling access to other APEX services

TOC

8. Enveloping

Envelope contains:

an originator
one or more recipients
a URI to the content

The content is a MIME object, with optimization for XML objects

The URI is usually internal, but can be external

TOC

9. An Example

C: MSG 1 1 . 42 1234
C: Content-Type: multipart/related; boundary="boundary";
C:               start="<1@example.com>";
C:               type="application/beep+xml"
C:
C: --boundary
C: Content-Type: application/beep+xml
C: Content-ID: <1@example.com>
C:
C: <data content='cid:2@example.com'>
C:     <originator identity='fred@example.com' />
C:     <recipient identity='barney@example.com' />
C: </data>
C: --boundary
C: Content-Type: image/gif
C: Content-Transfer-Encoding: binary
C: Content-ID: <2@example.com>
C:
C: ...
C: --boundary--
C: END

TOC

10. Another Example

C: MSG 1 1 . 42 295
C: Content-Type: application/beep+xml
C:
C: <data content='#Content'>
C:     <originator identity='fred@example.com' />
C:     <recipient identity='barney@example.com' />
C:     <data-content Name='Content'>
C:         <statusResponse transID='86'>
C:             <destination identity='barney@example.com'>
C:                 <reply code='250' />
C:             </destination>
C:         <statusResponse>
C:     </data-content>
C: </data>
C: END

TOC

11. Options

Options may be present on any operation:

    <!ELEMENT option      ANY>
    <!ATTLIST option
              internal    NMTOKEN           ""
              external    %URI;             ""
              targetHop   (this|final|all)  "final"
              seeNoEvil   (true|false)      "true"
              transID     %UNIQID;          #REQUIRED
              localize    %LOCS;            "i-default">

One option defined: statusRequest

TOC

12. Attach Operation

Applications attach as endpoints

Access policy maps peer identities to allowed endpoints

Options modify behavior, e.g., FCFS by default

TOC

13. Bind Operation

Relays bind on behalf of domains

Reponding peer does SRV lookup/comparison

Access policy maps peer identities to allowed domains

Options modify behavior

TOC

14. Data Operation (relay-specific)

Access policy maps APEX role to allowed originators

Data-specific options are processed

Fast OK returned

Originator-specific options are processed

Each recipient processed:

Options modify behavior
Inter-domain recipient handled via SRV lookup
APEX access service consulted for intra-domain recipient

Relays may optimize "like" recipients by bundling

TOC

15. Security

APEX distinguishes between hop-by-hop and end-to-end

Hop-by-hop:

intra-domain: peerwise
inter-domain: bilateral

End-to-End: endpoints chose standards for:

authentication
integrity
confidentiality

TOC

16. BEEP and per-hop Security

Sufficient for authentication, integrity, and confidentiality

Sufficient to support authorization (APEX access policies)

Necessary, but not sufficient, for relaying integrity

Insufficient for some forms of traffic analysis,

e.g., volume, timing, etc

TOC

17. Services

   +----------+     +----------+    +----------+
   |   APEX   |     |   APEX   |    |          |
   |  report  |     |   access |    |   ...    |
   | service  |     |  service |    |          |
   +----------+     +----------+    +----------+
        |                |               |      
        |                |               |      
+----------------------------------------------+
|                                              |
|                   APEX core                  |
|                                              |
+----------------------------------------------+

Identified by an endpoint starting with "apex="

TOC

18. The Report Service

Triggered by a relaying seeing a "statusRequest" option,

either as a data-specific or per-recipient option

"targetHop" attribute can be used for traceroute-like functionality

<data content='#Content'>
    <originator identity='apex=report@example.com' />
    <recipient identity='fred@example.com' />
    <data-content Name='Content'>
        <statusResponse transID='86'>
            <destination identity='barney@example.com'>
                <reply code='250' />
            </destination>
        </statusResponse>
    </data-content>
</data>

TOC

19. The Access Service

Controls access for endpoint reception of data

Controls access to other APEX services

<access owner='fred@example.com'
        lastUpdate='14 May 2000 13:02:00 -0800'>
    <entry actor='wilma@example.com'
           actions='all:all' />
    <entry actor='mr.slate@example.com'
           actions='core:data' />
    <entry actor='*@example.com'
         actions='core:data presence:subscribe
                            presence:watch' />
    <entry actor='*@*' actions='core:data' />
</access>

Two operations:

    get -> access entry or error
    set -> reply (confirmation or error)

Simple spin-lock to avoid write-write conflicts

TOC

20. The Presence Service

Repository for rendezvous information

<presence publisher='fred@example.com'
          lastUpdate='14 May 2000 13:02:00 -0800'
          publisherInfo='http://www.example.com/fred/'>
    <tuple destination='apex:fred/appl=im@example.com'
           availableUntil='14 May 2000 14:02:00 -0800' />
    <tuple destination='mailto:fred@flintstone.com'
           availableUntil='31 Dec 2525 23:59:59 -0800' />
</presence>

Four operations:

    subscribe -> event-driven notifications or error

      publish -> reply (confirmation or error)

        watch -> reply,
                 followed by event-driven notifications

    terminate -> reply

Subscribe and watch are duration-based services:

for a one-shot, use zero seconds

Simple spin-lock to avoid write-write conflicts

TOC

21. Status

The Working Group: apexwg@invisible.net

To subscribe: apexwg-request@invisible.net

Archives: http://lists.invisible.net/pipermail/apexwg/

Table of Contents

1. Helpful Reading

2. Operational Taxonomies

3. An Application Datagram Service

4. The Stack

5. Entities

6. Modes

7. Operations

8. Enveloping

9. An Example

10. Another Example

11. Options

12. Attach Operation

13. Bind Operation

14. Data Operation (relay-specific)

15. Security

16. BEEP and per-hop Security

17. Services

18. The Report Service

19. The Access Service

20. The Presence Service

21. Status