[svn-commits] russell: branch russell/ais r80961 - /team/russell/ais/doc/dundi.txt

SVN commits to the Digium repositories svn-commits at lists.digium.com
Sun Aug 26 19:59:40 CDT 2007


Author: russell
Date: Sun Aug 26 19:59:40 2007
New Revision: 80961

URL: http://svn.digium.com/view/asterisk?view=rev&rev=80961
Log:
add the dundi protocol spec for convenience

Added:
    team/russell/ais/doc/dundi.txt   (with props)

Added: team/russell/ais/doc/dundi.txt
URL: http://svn.digium.com/view/asterisk/team/russell/ais/doc/dundi.txt?view=auto&rev=80961
==============================================================================
--- team/russell/ais/doc/dundi.txt (added)
+++ team/russell/ais/doc/dundi.txt Sun Aug 26 19:59:40 2007
@@ -1,0 +1,2464 @@
+
+
+Network Working Group                                         M. Spencer
+Internet-Draft                                              Digium, Inc.
+Expires: April 13, 2005                                 October 13, 2004
+
+
+             Distributed Universal Number Discovery (DUNDi)
+                        draft-mspencer-dundi-01
+
+Status of this Memo
+
+   This document is an Internet-Draft and is NOT offered in accordance
+   with Section 10 of RFC2026, and the author does not provide the IETF
+   with any rights other than to publish as an Internet-Draft.
+
+   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.
+
+   This Internet-Draft will expire on April 13, 2005.
+
+Abstract
+
+   This memo describes the DUNDi protocol for resolving protocol and
+   destination descriptions for locating Internet resources for
+   contacting a phone number of any dialplan through a peer to peer,
+   trusted system.
+
+   This memo is Copyright (C) 2004, Digium, Inc.  with the goal of
+   eventually being presented to the IETF in accordance with Section 10
+   of RFC2026.
+
+
+
+
+
+
+
+
+
+
+Spencer                  Expires April 13, 2005                 [Page 1]
+
+Internet-Draft                   DUNDi                      October 2004
+
+
+Table of Contents
+
+   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   4
+     1.1  DUNDi Terminology  . . . . . . . . . . . . . . . . . . . .   4
+     1.2  Applicability  . . . . . . . . . . . . . . . . . . . . . .   5
+     1.3  Protocol Overview  . . . . . . . . . . . . . . . . . . . .   5
+   2.   Protocol Functioning . . . . . . . . . . . . . . . . . . . .   7
+     2.1  DUNDi Transactions . . . . . . . . . . . . . . . . . . . .   8
+     2.2  Retransmissions  . . . . . . . . . . . . . . . . . . . . .   9
+     2.3  Registration . . . . . . . . . . . . . . . . . . . . . . .   9
+     2.4  Dialplan Discovery . . . . . . . . . . . . . . . . . . . .   9
+     2.5  EID Query  . . . . . . . . . . . . . . . . . . . . . . . .  10
+     2.6  Example Transaction Flows  . . . . . . . . . . . . . . . .  10
+   3.   Packet Format and Forwarding . . . . . . . . . . . . . . . .  12
+     3.1  Protocol and Port Number . . . . . . . . . . . . . . . . .  12
+     3.2  Endpoint Identifiers . . . . . . . . . . . . . . . . . . .  12
+     3.3  Packet Format  . . . . . . . . . . . . . . . . . . . . . .  12
+   4.   DUNDi Commands and Responses . . . . . . . . . . . . . . . .  14
+     4.1  ACK Response . . . . . . . . . . . . . . . . . . . . . . .  15
+     4.2  DPDISCOVER Command . . . . . . . . . . . . . . . . . . . .  15
+     4.3  DPRESPONSE Response  . . . . . . . . . . . . . . . . . . .  16
+     4.4  EIDQUERY Command . . . . . . . . . . . . . . . . . . . . .  17
+     4.5  EIDRESPONSE Response . . . . . . . . . . . . . . . . . . .  18
+     4.6  INVALID Response . . . . . . . . . . . . . . . . . . . . .  19
+     4.7  UNKNOWN Response . . . . . . . . . . . . . . . . . . . . .  20
+     4.8  NULL Command . . . . . . . . . . . . . . . . . . . . . . .  21
+     4.9  REGREQ Command . . . . . . . . . . . . . . . . . . . . . .  21
+     4.10   REGRESPONSE Response . . . . . . . . . . . . . . . . . .  22
+     4.11   CANCEL Command . . . . . . . . . . . . . . . . . . . . .  23
+     4.12   ENCRYPT Command  . . . . . . . . . . . . . . . . . . . .  24
+     4.13   ENCREJ Response  . . . . . . . . . . . . . . . . . . . .  25
+   5.   DUNDi Information Elements . . . . . . . . . . . . . . . . .  26
+     5.1  EID Information Element  . . . . . . . . . . . . . . . . .  26
+     5.2  CALLED CONTEXT Information Element . . . . . . . . . . . .  27
+     5.3  CALLED NUMBER Information Element  . . . . . . . . . . . .  27
+     5.4  EID DIRECT Information Element . . . . . . . . . . . . . .  28
+     5.5  ANSWER Information Element . . . . . . . . . . . . . . . .  29
+     5.6  TTL Information Element  . . . . . . . . . . . . . . . . .  30
+     5.7  VERSION Information Element  . . . . . . . . . . . . . . .  31
+     5.8  EXPIRATION Information Element . . . . . . . . . . . . . .  31
+     5.9  UNKNOWN Information Element  . . . . . . . . . . . . . . .  32
+     5.10   CAUSE Information Element  . . . . . . . . . . . . . . .  32
+     5.11   REQEID Information Element . . . . . . . . . . . . . . .  33
+     5.12   ENCDATA Information Element  . . . . . . . . . . . . . .  34
+     5.13   SHAREDKEY Information Element  . . . . . . . . . . . . .  34
+     5.14   SIGNATURE Information Element  . . . . . . . . . . . . .  35
+     5.15   KEYCRC32 Information Element . . . . . . . . . . . . . .  35
+     5.16   HINT Information Element . . . . . . . . . . . . . . . .  36
+
+
+
+Spencer                  Expires April 13, 2005                 [Page 2]
+
+Internet-Draft                   DUNDi                      October 2004
+
+
+     5.17   DEPARTMENT Information Element . . . . . . . . . . . . .  37
+     5.18   ORGANIZATION Information Element . . . . . . . . . . . .  37
+     5.19   LOCALITY Information Element . . . . . . . . . . . . . .  38
+     5.20   STATEPROV Information Element  . . . . . . . . . . . . .  38
+     5.21   COUNTRY Information Element  . . . . . . . . . . . . . .  39
+     5.22   EMAIL Information Element  . . . . . . . . . . . . . . .  39
+     5.23   PHONE Information Element  . . . . . . . . . . . . . . .  40
+     5.24   IPADDR Information Element . . . . . . . . . . . . . . .  40
+   6.   DUNDi Best Practices . . . . . . . . . . . . . . . . . . . .  41
+     6.1  Network Architecture . . . . . . . . . . . . . . . . . . .  41
+   7.   Security Considerations  . . . . . . . . . . . . . . . . . .  43
+   8.   References . . . . . . . . . . . . . . . . . . . . . . . . .  43
+        Author's Address . . . . . . . . . . . . . . . . . . . . . .  43
+   A.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  44
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Spencer                  Expires April 13, 2005                 [Page 3]
+
+Internet-Draft                   DUNDi                      October 2004
+
+
+1.  Introduction
+
+   This memo describes the Distributed Universal Number Discovery
+   (DUNDi) protocol for resolving phone numbers into Internet resources
+   for contacting those phone numbers, through a peer to peer, trusted
+   system.
+
+   Unlike centralized systems like ENUM, DUNDi is designed to facilitate
+   the sharing of resources that can be used to terminate phone numbers
+   by using a peer to peer system, requiring no centralized controlling
+   authority, no single point of failure, and no enforced heirarchy.  In
+   this way, systems sharing a dialplan across an enterprise or across
+   the globe can be assembled in an ad-hoc manor, while retaining
+   confidence in the accuracy of the routes that are supplied and the
+   security of both the queries and the answers within the trust group.
+
+1.1  DUNDi Terminology
+
+   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC2119[1].
+
+   Additionally, this document uses the following terminology:
+
+      node
+         A system which implements the DUNDi protocol.
+
+      peer
+         As a verb, to exchange information via the DUNDi protocol in a
+         particular context.  As a noun, a node with which one peers.
+
+      context
+         A logical collection of numbers, composing a virtual numbering
+         plan.
+
+      entity identifier (EID)
+         A unique 6-byte identifier for a node, typically the Ethernet
+         MAC address of one of its interfaces.
+
+      transaction
+         A complete dialog between two ends, uniquely identified at each
+         end.
+
+      time to live (TTL)
+         A numerical representation of the number of hops through the
+         DUNDi system and amount of time for which a query is valid.
+
+
+
+
+
+Spencer                  Expires April 13, 2005                 [Page 4]
+
+Internet-Draft                   DUNDi                      October 2004
+
+
+      weight
+         A value indicating the relative cost or indirection of a
+         particular answer.  A lower weight represents a route which is
+         more direct to the intended location.  The lowest weight value
+         is 0.
+
+      General Peering Agreement (GPA)
+         A special peering agreement executed by members of the Dundi
+         E.164 trust group to protect the integrity of the entries in
+         that context.
+
+1.2  Applicability
+
+   DUNDi is specifically targeted at the problem of locating routes for
+   telephone numbers over the Internet.  While DUNDi has applications
+   for finding routes for other kinds of information (e.g.  e-mail
+   addresses), implementations MAY perform certain optimizations based
+   on the assumption that the query is, in fact, for a telephone number
+   and relying on certain heuristics thereof.
+
+   DUNDi is especially valuable in networks in which robustness to the
+   loss of a node is valuable.
+
+   DUNDi is also useful for building trust relationships between
+   independent organizations who wish to communicate with one another,
+   but for whom centralizing or delegating the required information
+   would be impractical or impossible.
+
+   DUNDi is valuable for networks in which more than one method exists,
+   possibly with different priorities, for attempting to reach a phone
+   number.  For example, it may be possible to reach a phone number both
+   directly over the Internet or via an Internet to PSTN gateway, in
+   which the former is preferred, but the latter is an acceptable
+   alternative.
+
+   DUNDi is valuable for networks in which a phone number may move from
+   one service provider to another (e.g.  implementation of local number
+   portability).
+
+1.3  Protocol Overview
+
+   DUNDi is a lightweight, low bandwidth, secure, binary encoded
+   protocol for sharing and discovering routes to numbers in arbitrary
+   dialplans.  DUNDi provides messages and information elements designed
+   to allow implementors the maximum flexibility in developing creative
+   ways to minimize the amount of traffic and maximize the number of
+   results that can be obtained through the system.  DUNDi itself is not
+   used for the actual call setup and voice control, only for locating
+
+
+
+Spencer                  Expires April 13, 2005                 [Page 5]
+
+Internet-Draft                   DUNDi                      October 2004
+
+
+   the resource for delivering the call.  Typically the call setup and
+   voice control will be handled by another appropriate protocol (for
+   example IAX, SIP, or H.323).
+
+   Each node in DUNDi is identified by a globally unique six byte entity
+   identifier, whose value typically is an Ethernet MAC address for one
+   of the interfaces in the system.
+
+   DUNDi supports overlaying multiple dialplans by the use of a
+   "context", permitting, for example, an enterprise for using DUNDi for
+   the management of local four digit dialing under a private context
+   (e.g.  "private"), while permitting them to share in the global
+   "e164" context for true E.164 numbers.  Any context name may be used,
+   but the context "e164" is reserved for members of the DUNDi E.164
+   trust group who have executed the General Peering Agreement (GPA).
+
+   DUNDi uses a simple, consistant binary encoded message frame with
+   information elements to provide the necessary additional attributes
+   for those messages.
+
+   DUNDi does not enforce or require a particular topology although in
+   pratice certain topologies will lend to better scaling of the
+   resulting conglomberation of nodes by taking advantage of caching and
+   hints.  Generally speaking, m-ary trees can provide good architecture
+   for large numbers of nodes, while strongly connected networks can
+   work well in enterprise applications.
+
+   To provide security and privacy, DUNDi uses RSA and AES for
+   encryption and RSA for authenticating information.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Spencer                  Expires April 13, 2005                 [Page 6]
+
+Internet-Draft                   DUNDi                      October 2004
+
+
+2.  Protocol Functioning
+
+   This section outlines the overall operation of the protocol.
+
+   The fundamental construction of a DUNDi trust group is a collection
+   of nodes in which each node is connected to at least one other node
+   in the group (although in practice, often each node should be
+   connected to two other nodes in order to provide redundancy).
+
+   An example trust group might look like this:
+
+
+       +----------+                        +----------+
+   	|          |              Trust     |          |
+   	|   Node   |<---------------------->|   Node   |
+   	|    A     |<------+                |    D     |
+   	|          |       | T              |          |
+   	+----------+       | r              +----------+
+   	                   | u
+   	+----------+       | s              +----------+
+   	|          |       | t              |          |
+   	|   Node   |<------+      Trust     |   Node   |
+   	|    B     |<---------------------->|    C     |
+   	|          |                        |          |
+   	+----------+                        +----------+
+
+
+   In this model, node A has a trust relationship with nodes D and B,
+   while node B has a trust relationship with nodes A and C
+
+   Suppose, for example, that A wants to call the number 1234.  First, A
+   would verify that 1234 was not in its local routing table or cache.
+   Assuming it wasn't, A would then send queries to both B and D to
+   request information on the number.  If B or D had the number in its
+   local table or cache, they would return the answer to A.  B would
+   also enquire from node C an answer which could then be returned to
+   node A in response to its query.  Note that more than one node MAY
+   supply an answer for a query, even if those answers have the same
+   weight.
+
+   Each implementation MUST attempt to minimize the number of queries
+   throughout the trust system, without sacrificing the accuracy of the
+   answers provided.  Some queries can be reduced by caching, others can
+   be reduced by cleverly pruning trees through good architecture and
+   the use of "hints".
+
+
+
+
+
+
+Spencer                  Expires April 13, 2005                 [Page 7]
+
+Internet-Draft                   DUNDi                      October 2004
+
+
+2.1  DUNDi Transactions
+
+   A dundi transaction is a complete dialog within the DUNDi protocol
+   from one node to another.  A transaction is uniquely identified at
+   each end by an arbitrary 16-bit transaction identifier from 1 to
+   65535 which SHOULD be selected as a random number for increased
+   security.  Each message contains both a source and destination
+   transaction number so that a received message can be uniquely
+   identified by the transaction number alone.  The transaction
+   identifier "0" is reserved for the destination transaction for the
+   opening message of a dialog, since the destination transaction is not
+   known at that time.
+
+   A transaction MUST be started by the transmission of a command and
+   MUST NOT be started by the transmission of a response.  A transaction
+   may be terminated at any time by either node participating by
+   transmitting a message, other than ACK, with the "F" or "final" bit
+   set, the receipt of which message MUST still be acknowledged by an
+   ACK message.  A node MUST NOT send any message after the receipt of a
+   message with the "F" bit set to 1, except ACK.  That ACK MUST have
+   the F bit set to 1.
+
+   Each message includes an 8-bit incoming and 8-bit outgoing sequence
+   number.  Each node independently holds an outgoing sequence number
+   which is set to 0 for the first message of a transaction sent by that
+   node.  The outgoing sequence number is then incremented after the
+   transmission of each new message, except ACK.  The 8-bit incoming
+   sequence number represents the next value for the outgoing sequence
+   number that would be sent by the other party.
+
+   DUNDi has a window size of exactly 1, meaning that a node SHOULD NOT
+   transmit a new message until it has received a message from the other
+   node with the incoming sequence number set to the value of the
+   outgoing sequence number that node wishes to send in its next
+   message.
+
+   Upon receipt of a message other than ACK or INVALID with the outgoing
+   sequence number set to the next expected incoming sequence number,
+   the receiver MUST increment its next expected incoming sequence
+   number and send a message with the updated next incoming sequence
+   number.  If there is no other message to be sent when the message is
+   received, an ACK MUST be sent.
+
+   Upon receipt of a message other than ACK or INVALID with the outgoing
+   sequence number set to the next expected incoming sequence number,
+   the receiver MUST immediately respond with an ACK command, with the
+   next expected incoming sequence number set to the currently expected
+   incoming sequence number (without being incremented) and the outgoing
+
+
+
+Spencer                  Expires April 13, 2005                 [Page 8]
+
+Internet-Draft                   DUNDi                      October 2004
+
+
+   sequence number set to the value of the incoming sequence number in
+   the received packet.
+
+   Any message received in which the outgoing sequence number is neither
+   the last expected incoming sequence number nor the currently expected
+   next received sequence number MUST be ignored.
+
+2.2  Retransmissions
+
+   A DUNDi request may be retransmitted up to 10 times at time intervals
+   to be decided by the implementor, but not greater than 1 second.  If
+   a message is not acknowledged after 10 retransmissions or 10 seconds,
+   the transaction MUST be considered closed with no further messages
+   being transmitted or expected.
+
+2.3  Registration
+
+   The REGREQ and REGRESPONSE are used to for one DUNDi peer, typically
+   with a dynamic or address translated location, to register its
+   presence to another, fixed DUNDi peer.  The registering peer sends a
+   REGREQ to the fixed peer (typically as a new transaction), which
+   responds with REGRESPONSE regardless of whether the request was
+   accepted or not.  If the registration is successful, it must expire
+   and be removed after time in the EXPIRATION information element of
+   the REGRESPONSE has passed, and the registering entity MUST
+   re-register before that timer expires if it wishes to retain its
+   registration.
+
+2.4  Dialplan Discovery
+
+   The DPDISCOVER and DPRESPONSE commands are used to discover a number.
+   A DPDISCOVER typically opens a new transaction to perform a query
+   and, if authorized, is typically responded to with an ACK and then
+   eventually with a DPRESPONSE with the F bit set to 1.
+
+   Upon receipt of a DPDISCOVER, an entity MUST respond with a
+   DPRESPONSE within T milliseconds where T is the value of the TTL
+   information element multiplied by 200 and added to 2000.  An entity
+   which makes a DPDISCOVER SHOULD terminate its request with CANCEL if
+   it does not receive a DPRESPONSE within T + 200 milliseconds of
+   making its request.  The peer making the DPDISCOVER request and
+   receiving the DPRESPONSE should process and cache the response and
+   immediately create its own DPRESPONSE to any DPDISCOVER request which
+   had the source of its DPDISCOVER.
+
+   If a DPDISCOVER is sent in conjunction with a DPDISCOVER that was
+   received from another entity:
+
+
+
+
+Spencer                  Expires April 13, 2005                 [Page 9]
+
+Internet-Draft                   DUNDi                      October 2004
+
+
+   1.  It MUST have a TTL which is one less than the TTL in the received
+       DPDISCOVER command.  If the received TTL is 0, the request MUST
+       NOT be forwarded to any other entities.
+   2.  It MUST NOT be sent to any entities whose identities are listed
+       in the originating DPDISCOVER.
+   3.  The last EID information element in the new DPDISCOVER MUST be
+       the same as the last EID information element in the originating
+       DPDISCOVER.  The first EID information element must be the EID of
+       the entity sending the new DPDISCOVER.  All other EID's listed in
+       the original DPDISCOVER MUST be included in any new DPDISCOVER.
+
+   Regardless of the source of a DPDISCOVER, the following MUST always
+   hold true for the DPRESPONSE:
+   1.  A DPRESPONSE being sent MAY include one or more answers but MUST
+       NOT include answers with the same Technology and Destination.  If
+       the DPRESPONSE is combining answers from sources which share the
+       same Technology and Destination, it MUST only include the answer
+       with the lowest Weight.
+   2.  If there were any entities which would have been queried had the
+       TTL been greater than 1, then the response MUST have the hint
+       flag TTLEXPIRED present.
+   3.  The UNAFFECTED hint bit MUST be set if and only if no entities
+       listed in the DPDISCOVER with the EID information element (as
+       opposed to the EID_DIRECT information element) would have been
+       queried anyway, had they not been present in the request.
+   4.  The DONTASK hint bit SHOULD be set, and the shortest substring of
+       the number for which no number beginning with that substring
+       could possibly have been a match.
+
+2.5  EID Query
+
+   The EIDQUERY and EIDRESPONSE commands are used to obtain information
+   about a speific EID in the network.  An EIDQUERY typically opens a
+   new transaction to perform a query and, if authorized, is typically
+   responded to with an ACK and then eventually with a EIDRESPONSE with
+   the F bit set to 1.
+
+   The rules for forwarding EID queries generally follow those of the
+   DPDISCOVER/DPRESPONSE described in Section 2.4.
+
+2.6  Example Transaction Flows
+
+
+
+
+
+
+
+
+
+
+Spencer                  Expires April 13, 2005                [Page 10]
+
+Internet-Draft                   DUNDi                      October 2004
+
+
+   An example transaction sequence might look something like this
+   (assume Si is next expected incoming sequence number and So is the
+   next outgoing sequence number, Ts is the source transaction number,
+   Td is the destination transaction number and F is the final bit:
+
+
+   Example 1: Register request /response
+
+      Node A                                            Node B
+
+        REGREQ (So=0,Si=0,Ts=1234,Td=0,F=0) ===============>
+
+        <======= REGRESPONSE (So=0,Si=1,Ts=5678,Td=1234,F=1)
+
+        ACK (So=1,Si=1,Ts=1234,Td=5678,F=1) ===============>
+
+
+   Example 2: Dialplan discovery
+
+      Node A                                            Node B
+
+        DPDISCOVER (So=0,Si=0,Ts=2345,Td=0) ===============>
+
+        <=============== ACK (So=0,Si=1,Ts=6789,Td=2345,F=0)
+
+        <======== DPRESPONSE (So=0,Si=1,Ts=6789,Td=2345,F=1)
+
+        ACK (So=1,Si=1,Ts=2345,Td=6789,F=1) ===============>
+
+   Example 3: Entity Identifier Query
+
+      Node A                                            Node B
+
+        EIDQUERY (So=0,Si=0,Ts=3456,Td=0) =================>
+
+        <=============== ACK (So=0,Si=1,Ts=6789,Td=3456,F=0)
+
+        <======= EIDRESPONSE (So=0,Si=1,Ts=6789,Td=3456,F=1)
+
+        ACK (So=1,Si=1,Ts=3456,Td=6789,F=1) ===============>
+
+
+   (Note that these examples do not use encryption, but the flow would
+   be essentially identical with encryption.)
+
+
+
+
+
+
+
+Spencer                  Expires April 13, 2005                [Page 11]
+
+Internet-Draft                   DUNDi                      October 2004
+
+
+3.  Packet Format and Forwarding
+
+3.1  Protocol and Port Number
+
+   Packets in DUNDi are communicated using UDP on "well known" port 4520
+   (not yet assigned by IANA)
+
+3.2  Endpoint Identifiers
+
+   The endpoint identifier is a 6 byte globally unique identifier.  In
+   order that global uniqueness be guaranteed, an implementation SHOULD
+   use the MAC address of an ethernet, bluetooth, or similar interface
+   within the system.
+
+3.3  Packet Format
+
+   The basic layout of any packet in DUNDi (omitting IP and UDP
+   headers):
+
+        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
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |       Source Transaction      |    Destination Transaction    |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |    ISeqno     |     OSeqno    |F|R|  CmdResp  |   CmdFlags    |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |                                                               |
+       :                      Information Elements                     :
+       |                                                               |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      Source Transaction
+         The local unique identifier for the transaction.
+
+      Destination Transaction
+         The remote unique identifier for the transaction.
+
+      ISeqno
+         The next expected incoming sequence number.
+
+      OSeqno
+         The outgoing sequence number.
+
+      F
+         The Final bit, '1' if this is the last command of a transaction
+         (or its acknowledging ACK).
+
+
+
+
+
+Spencer                  Expires April 13, 2005                [Page 12]
+
+Internet-Draft                   DUNDi                      October 2004
+
+
+      R
+         The Response bit, '0' if this is a command or '1' if this is a
+         response.  Only commands may open a dialog, but commands or
+         responses may close a dialog.
+
+      CommandResp
+         The command being requested, or the response to a command (see
+         Section 4)
+
+      CmdFlags
+         Command specific flags.
+
+      Information Elements
+         Zero or more DUNDi information elements (see Section 5).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Spencer                  Expires April 13, 2005                [Page 13]
+
+Internet-Draft                   DUNDi                      October 2004
+
+
+4.  DUNDi Commands and Responses
+
+   DUNDi commands are eight bits in length including the R ("Response")
+   and F ("Final") bits.  This section documents the encodings and
+   information elements for each frame.  For each section, the encoding
+   of the message is provided as well as a table of information elements
+   which are applicable for the message, along with their meanings.  Any
+   information elements which are received that are NOT listed within
+   the specification MUST be ignored unless their meaning is defined by
+   a later version of this standard.  A DUNDi peer MUST NOT append
+   additional information elements which are not listed for a message
+   unless they are defined by a later version of this standard.  A DUNDi
+   peer SHOULD refuse to process a command or response for which
+   mandatory information elements are missing.
+
+   The order of different kinds of information elements within a message
+   is irrelevent except that the ENCDATA information element MUST be
+   last if it is present at all.
+
+   The folowing table describes the meaning of the "Type" field of the
+   tables for information elements:
+
+   +------+------------+-------------------------------------------------+
+   + Type | Name       | Meaning with relation to message                |
+   +------+------------+-------------------------------------------------+
+   |  M   | Mandatory  | exactly one MUST be present                     |
+   +-------------------+-------------------------------------------------+
+   |  O   | Optional   | exactly one MAY be present                      |
+   +-------------------+-------------------------------------------------+
+   |  M+  | Mandatory  | at least one MUST be present, more permitted    |
+   +-------------------+-------------------------------------------------+
+   |  O+  | Optional   | one or more MAY be present                      |
+   +---------------------------------------------------------------------+
+
+   The F bit MUST be set to a 1 when the ACK is in response to the final
+   message of a transaction and MUST be set to 0 in all other cases.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Spencer                  Expires April 13, 2005                [Page 14]
+
+Internet-Draft                   DUNDi                      October 2004
+
+
+4.1  ACK Response
+
+   The ACK CmdResp and CmdFlags values shall be encoded as follows:
+
+        0                   1
+        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |F|1|   0x00    |     0x00      |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The F bit MUST be set to a 1 when the ACK is in response to the final
+   message of a transaction and MUST be set to 0 in all other cases.
+   Any received CmdFlags MUST be ignored unless they are defined by a
+   later version of this standard.  CmdFlags MUST be encoded as 0 unless
+   flags are defined by a later version of this standard.
+
+   The following information elements are used with ACK:
+
+   +---------------------+------+------------------------------------+
+   + Information Element | Type | Notes                              |
+   +---------------------+------+------------------------------------+
+   |     No Information Elements are included with this message      |
+   +---------------------+------+------------------------------------+
+
+   No Information Element Notes.
+
+   The purpose of the ACK command is to acknowledge receipt of a message
+   when there is no other message immediately available to be sent.
+   Note that the outgoing sequence number is NOT incremented after
+   transmission of ACK, unlike all other messages.  ACK MUST NOT be sent
+   in response to another ACK or INVALID message.
+
+4.2  DPDISCOVER Command
+
+   The DPDISCOVER CmdResp and CmdFlags values shall be encoded as
+   follows:
+
+        0                   1
+        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |0|0|   0x01    |     0x00      |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Any received CmdFlags MUST be ignored unless they are defined by a
+   later version of this standard.  CmdFlags MUST be encoded as 0 unless
+   flags are defined by a later version of this standard.  A node MUST
+   NOT set the F bit on a DPDISCOVER since it would preclude an answer
+   from coming back.  Handling of a DPDISCOVER with the F bit set to 1
+
+
+
+Spencer                  Expires April 13, 2005                [Page 15]
+
+Internet-Draft                   DUNDi                      October 2004
+
+
+   MUST remain in accordance with Section 2.1.
+
+   The following information elements are used with DPDISCOVER:
+
+   +---------------------+------+------------------------------------+
+   + Information Element | Type | Notes                              |
+   +---------------------+------+------------------------------------+
+   | VERSION             |  M   | MUST be the value "1" for this     |
+   |                     |      | version of the standard.           |
+   +---------------------+------+------------------------------------+
+   | EID / EID_DIRECT    |  M+  | First listed EID MUST be that of   |
+   |                     |      | the entity making the request.     |
+   |                     |      | Last listed EID MUST be the        |
+   |                     |      | original source of the request.    |
+   +---------------------+------+------------------------------------+
+   | CALLED NUMBER       |  M   | The number being discovered.       |
+   +---------------------+------+------------------------------------+
+   | CALLED CONTEXT      |  M   | The context in which to discover.  |
+   +---------------------+------+------------------------------------+
+   | TTL                 |  M   | The TTL of this request.           |
+   +---------------------+------+------------------------------------+
+
+   The purpose of the DPDISCOVER command is to initiate discovery of a
+   number within the DUNDi system.  The DPDISCOVER typically begins a
+   transaction and is typically responded to initially with an ACK and
+   then with a DPRESPONSE once the DPDISCOVER has been processed by the
+   remote node.  Upon receiving a DPDISCOVER, a peer MUST respond within
+   200ms of the TTL plus 2000ms.
+
+4.3  DPRESPONSE Response
+
+   The DPRESPONSE CmdResp and CmdFlags values shall be encoded as
+   follows:
+
+        0                   1
+        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |F|1|   0x02    |     0x00      |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Any received CmdFlags MUST be ignored unless they are defined by a
+   later version of this standard.  CmdFlags MUST be encoded as 0 unless
+   flags are defined by a later version of this standard.  A node MAY
+   set the F bit on a DPRESPONSE.
+
+
+
+
+
+
+
+Spencer                  Expires April 13, 2005                [Page 16]
+
+Internet-Draft                   DUNDi                      October 2004
+
+
+   The following information elements are used with DPRESPONSE:
+
+   +---------------------+------+------------------------------------+
+   + Information Element | Type | Notes                              |
+   +---------------------+------+------------------------------------+
+   | CAUSE               |  O   | May indicate cause of lack of      |
+   |                     |      | an answer, SHOULD be included if   |
+   |                     |      | lack of answer is authentication   |
+   |                     |      | error.                             |
+   +---------------------+------+------------------------------------+
+   | ANSWER              |  O+  | Any discovered answers from the    |
+   |                     |      | system.                            |
+   +---------------------+------+------------------------------------+
+   | HINT                |  M   | Hints about answers or lack        |
+   |                     |      | thereof.                           |
+   +---------------------+------+------------------------------------+
+   | EXPIRATION          |  M   | Expiration of this answer, hint or |
+   |                     |      | lack of information.               |
+   +---------------------+------+------------------------------------+
+
+   The purpose of the DPRESPONSE is to communicate the answer to a
+   DPDISCOVERY back to the requesting source.
+
+4.4  EIDQUERY Command
+
+   The EIDQUERY CmdResp and CmdFlags values shall be encoded as follows:
+
+        0                   1
+        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |0|0|   0x03    |     0x00      |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Any received CmdFlags MUST be ignored unless they are defined by a
+   later version of this standard.  CmdFlags MUST be encoded as 0 unless
+   flags are defined by a later version of this standard.  A node MUST
+   NOT set the F bit on a EIDQUERY since it would preclude an answer
+   from coming back.  Handling of a EIDQUERY with the F bit set to 1
+   MUST remain in accordance with Section 2.1.
+
+
+
+
+
+
+
+
+
+
+
+
+Spencer                  Expires April 13, 2005                [Page 17]
+
+Internet-Draft                   DUNDi                      October 2004
+
+
+   The following information elements are used with EIDQUERY:
+
+   +---------------------+------+------------------------------------+
+   + Information Element | Type | Notes                              |
+   +---------------------+------+------------------------------------+
+   | VERSION             |  M   | MUST be the value "1" for this     |
+   |                     |      | version of the standard.           |
+   +---------------------+------+------------------------------------+
+   | EID / EID_DIRECT    |  M+  | First listed EID MUST be that of   |
+   |                     |      | the entity making the request.     |
+   |                     |      | Last listed EID MUST be the        |
+   |                     |      | original source of the request.    |
+   +---------------------+------+------------------------------------+
+   | REQUESTED EID       |  M   | The EID being queried.             |
+   +---------------------+------+------------------------------------+
+   | CALLED CONTEXT      |  M   | The context in which to discover.  |
+   +---------------------+------+------------------------------------+
+   | TTL                 |  M   | The TTL of this request.           |
+   +---------------------+------+------------------------------------+
+
+   The purpose of the EIDQUERY command is to initiate a query for
+   information about a specific EID within the DUNDi system.  The
+   EIDQUERY typically begins a transaction and is typically responded to
+   initially with an ACK and then with an EIDRESPONSE once the EIDQUERY
+   has been processed by the remote node.  Upon receiving a EIDQUERY, a
+   peer MUST respond within 200ms of the TTL plus 2000ms.
+
+4.5  EIDRESPONSE Response
+
+   The EIDRESPONSE CmdResp and CmdFlags values shall be encoded as
+   follows:
+
+        0                   1
+        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |F|1|   0x04    |     0x00      |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Any received CmdFlags MUST be ignored unless they are defined by a
+   later version of this standard.  CmdFlags MUST be encoded as 0 unless
+   flags are defined by a later version of this standard.  A node MAY
+   set the F bit on a EIDRESPONSE.
+
+
+
+
+
+
+
+
+
+Spencer                  Expires April 13, 2005                [Page 18]
+
+Internet-Draft                   DUNDi                      October 2004
+
+
+   The following information elements are used with EIDRESPONSE:
+
+   +---------------------+------+------------------------------------+
+   + Information Element | Type | Notes                              |

[... 1462 lines stripped ...]



More information about the svn-commits mailing list