[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
INTERNET DRAFT                                             P. Tom Taylor
                                               Nortel (Northern Telecom)
Title: draft-taylor-ipdc-00.txt                           Pat R. Calhoun
Date: July 1998                                   Sun Microsystems, Inc.
                                                         Allan C. Rubens
                                                   Ascend Communications



                                  IPDC
                             Base Protocol
                       <draft-taylor-ipdc-00.txt>


Status of this Memo

   This document is  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.''

   To learn the current status of any Internet-Draft, please  check  the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories  on  ftp.is.co.za   (Africa),   nic.nordu.net   (Europe),
   munnari.oz.au   (Pacific  Rim),  ftp.ietf.org  (US  East  Coast),  or
   ftp.isi.edu (US West Coast).

Abstract

   The protocol described in this document provides the basis for the IP
   Device  Control  (IPDC)  family of protocols.  The IPDC protocols are
   proposed as a  protocol  suite,  components  of  which  can  be  used
   individually   or  together  to  perform  connection  control,  media
   control, and signaling transport for environments where  the  service
   control logic is separated from the network access server. Please see
   the references section for other IPDC documents.

   According to the framework provided by Cuervo et  al  [1],  the  IPDC
   protocol  suite operates between the Media Gateway Controller and the
   Media Gateway.  In terms of previous contributions to the experts  of
   Questions  13-14/16,  the corresponding entities are the Call Control
   and Media Control portions of the H.323 Gateway.   The  operation  of
   IPDC in the service of H.323 is clarified in a companion contribution



Taylor, Calhoun, Rubens   expires January 1999                  [Page 1]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


   entitled "IPDC Architectural Framework" [3].


Table of Contents

  1.0   Introduction
    1.1 Definitions
    1.2 Terminology
  2.0   Transport
    2.1 Protocol Overview
  3.0   Message Format
    3.1 Transaction Identification
  4.0   AVP Format
  5.0   AVP Definitions
    5.1 Command AVP
      5.1.1     DIAMETER Base Commands
        5.1.1.1 Command-Unrecognized-Ind
        5.1.1.2 Device-Reboot-Ind
        5.1.1.3 Device-Watchdog-Ind
        5.1.1.4 Device-Feature-Query
        5.1.1.5 Device-Feature-Reply
        5.1.1.6 Device-Config-Req
        5.1.1.7 Device-Config-Answer
      5.1.2     Additional IPDC Commands
        5.1.2.1 Command-Ack
        5.1.2.2 Message-Reject
    5.2 Other AVPs
      5.2.1     DIAMETER Base AVPs
        5.2.1.1 Host-IP-Address
        5.2.1.2 Host-Name
        5.2.1.3 Version-Number
        5.2.1.4 Extension-Id
        5.2.1.5 Integrity-Check-Vector
        5.2.1.6 Digital-Signature
        5.2.1.7 Initialization-Vector
        5.2.1.8 Timestamp
        5.2.1.9 Session-Id
        5.2.1.10        X509-Certificate
        5.2.1.11        X509-Certificate-URL
        5.2.1.12        Vendor-Name
        5.2.1.13        Firmware-Revision
        5.2.1.14        Result-Code
        5.2.1.15        Error-Code
        5.2.1.16        Unknown-Command-Code
        5.2.1.17        Reboot-Type
        5.2.1.18        Reboot-Timer
        5.2.1.19        Message-Timer
        5.2.1.20        Message-In-Progress-Timer



Taylor, Calhoun, Rubens   expires January 1999                  [Page 2]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


        5.2.1.21        Message-Retry-Count
        5.2.1.22        Message-Forward-Count
        5.2.1.23        Receive-Window
      5.2.2     Additional IPDC AVPs
        5.2.2.1 Transaction-Originator
        5.2.2.2 Failed-AVP-Code
    5.3 IPDC AVP Templates
      5.3.1     IPDC Reference
  6.0   Protocol Definition
    6.1   Bootstrap Message
    6.2    Keepalive Exchange
    6.3    Unrecognized Command Support
    6.4    The art of AVP Tagging
    6.5    Device Configuration
    6.6 Data Integrity
      6.6.1     Using the Integrity-Check-Vector
      6.6.2     Using Digital Signatures
      6.6.3     Using Mixed Data Integrity AVPs
    6.7 AVP Data Encryption
      6.7.1     AVP Encryption with Shared Secrets
      6.7.2     AVP Encryption with Public Keys
    6.8 Public Key Cryptography Support
      6.8.1     X509-Certificate
      6.8.2     X509-Certificate-URL
      6.8.3     Static Public Key Configuration
  7.0   References
  8.0   Rights and Permissions
  9.0   Acknowledgements
 10.0   Authors' Addresses
  Appendix A: Acknowledgement Timeouts
  Appendix B: Examples Of Sequence Numbering




1.0  Introduction

   A need has been identified for  one  or  more  protocols  to  control
   gateway  devices  which  sit  at  the  boundary  between the circuit-
   switched telephone network and the internet  and  terminate  circuit-
   switched  trunks.   Examples  of  such devices include network access
   servers and voice-over-IP gateways.  The need for a control  protocol
   separate  from  call signalling arises when the service control logic
   needed to process calls lies partly or  wholly  outside  the  gateway
   devices.

   Cuervo et al [1] and Skran [3]  describe  the  architectural  context
   within  which  the gateway control protocols must operate.  Using the



Taylor, Calhoun, Rubens   expires January 1999                  [Page 3]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


   terminology established by [1], the protocols implement the interface
   between  the  Media  Gateway  Controller  and the Media Gateway.  The
   present document along with documents listed in the  references  [4],
   [5],  [6],  and  [7]  describe  the IP Device Control (IPDC) protocol
   suite, which is proposed for that purpose.

   Note that IPDC views the Media Gateway as an  application  which  may
   control  one  or  more  physical devices.  In addition to its primary
   mandate, IPDC MAY be used to control devices which do  not  meet  the
   strict definition of Media Gateway such as digital cross-connects and
   announcement servers.

   IPDC builds on the base already provided by  DIAMETER  [2].  DIAMETER
   has a number of advantages as a starting point:
      * built-in provision for control security
      * facilities for starting up the control relation
      * ready extensibility both in modular increments and at the atomic
      (individual command and attribute) level.

   Because DIAMETER is specifically written for the AAA (authentication,
   authorization,  accounting)  application,  the  authors  of  the IPDC
   proposal have chosen to use DIAMETER 's syntactical framework  rather
   than  DIAMETER itself.  The present document looks very much like the
   current DIAMETER Base document [2], but various changes to  suit  the
   IPDC  application  environment  have  created  a  protocol  which  is
   interoperable with but not identical with DIAMETER.

   This document describes the base  IPDC  protocol.  This  document  in
   itself is not complete and MUST be used with one or more accompanying
   task-specific extension documents such as those provided by [4], [5],
   [6], and [7].


1.1     Definitions

   In this document, several words are used to signify the  requirements
   of the specification.  These words are often capitalized.

   MUST        This word, or the adjective "required",  means  that  the
   definition is an absolute requirement of the specification.

   MUST NOT  This phrase  means  that  the  definition  is  an  absolute
   prohibition of the specification.

   SHOULD    This word, or the adjective "recommended", means that there
   may  exist  valid  reasons in particular circumstances to ignore this
   item, but the full implications  must  be  understood  and  carefully
   weighed before choosing a different course.



Taylor, Calhoun, Rubens   expires January 1999                  [Page 4]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


   MAY       This word, or the adjective  "optional",  means  that  this
   item  is  one  of  an allowed set of alternatives.  An implementation
   which does not include this option MUST be prepared  to  interoperate
   with another implementation which does include the option.


1.2     Terminology

   AVP
      The IPDC  protocol  consists  of  a  message  header  followed  by
      Attribute-Value-Pairs   (AVPs).    An   AVP   is   a  data  object
      encapsulated in a header.

   Command
      An IPDC command is a specialized data object which  indicates  the
      purpose  and  structure  of the message containing it.  Because of
      this identification between command type and message  format,  the
      command  name  may  be  used  denote  the  message format, as, for
      example, "IPDC-Alive Message".

   DIAMETER Device
      A Diameter device is a client or server system that  supports  the
      Diameter Base protocol and 0 or more extensions.

   Integrity Check Vector
      An Integrity Check Vector is a hash of the packet  with  a  shared
      secret.

   IPDC Entity
      An IPDC entity is  any  object,  logical  or  physical,  which  is
      subject  to control through IPDC or whose status IPDC must report.
      Every IPDC entity has a type.  The complete list  of  IPDC  entity
      types  is provided as part of the definition of the IPDC Reference
      AVP template in section 5.3.1.

   IPDC Protocol Endpoint
      The term IPDC protocol endpoint is used to refer to either of  the
      two  parties  to  an  IPDC  control  session:  the  Media  Gateway
      Controller or the Media Gateway.  To the extent that IPDC  may  be
      viewed  as  providing  extensions  to  DIAMETER,  an IPDC protocol
      endpoint is also a Diameter device.

   Transaction
      A transaction is sequence of messages pre-defined as part  of  the
      definition  of  the  IPDC commands which constitute that sequence.
      Every message in the sequence carries the same Identifier value in
      the  header  and same Transaction-Originator value identifying the
      originator of the transaction, as described in Section 3.1.



Taylor, Calhoun, Rubens   expires January 1999                  [Page 5]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


2.0     Transport

   DIAMETER packets MAY be transmitted over UDP or  TCP.  Each  DIAMETER
   Service  Extensions  draft  SHOULD  specify  the transport layer. The
   destination port field for DIAMETER is 1812.  For UDP, when  a  reply
   is generated the source and destination ports are reversed.

   IPDC requires a reliable, order-preserving  transport  protocol  with
   minimal  latency so that IPDC control is responsive to the demands of
   call processing.  UDP combined with the protocol description  in  the
   next  section  satisfies  these  requirements,  and  is therefore the
   default transport protocol for IPDC.  Network operators MAY choose to
   implement TCP instead for greater security or other reasons.

2.1  Protocol Overview

   There are two different types of IPDC/DIAMETER messages:  header-only
   messages  and  messages  containing  Attribute-Value  Pairs (AVPs) in
   addition to headers.  Header-only messages are  used  for  explicitly
   acknowledging packets to the peer.

   The Identifier field  in  the  DIAMETER  header  is  a  monotonically
   increasing  four octet value that is used to aid in matching requests
   with replies. When sending a message  to  a  peer,  the  sender  must
   include  a  value that is unique to itself at that time. The response
   to the message from the peer MUST include the same identifier  value.
   It   is   imperative   that  no  two  outstanding  requests  from  an
   IPDC/DIAMETER node have the same identifier value. Given the  current
   size  of the identifier (2^32), it is highly unlikely that this could
   occur.

   It is not necessary to  ensure  that  Identifier  values  are  unique
   across  reboots,  as  long as the IPDC/DIAMETER node issues a Device-
   Reboot-Ind message after reboot completion.

   A IPDC/ DIAMETER implementation SHOULD keep transmitted requests in a
   queue  until a response with the same Identifier value is received in
   order to ensure that it can  match  the  request  with  the  response
   received.

   Two additional fields in the IPDC/ DIAMETER header are  important  to
   the  operation  of  the protocol: the Nr (Next Received) and Ns (Next
   Send) values. A single sequence number state is  maintained  for  all
   IPDC/  DIAMETER  messages to a given peer. The Sequence number starts
   at 0 upon startup of the control session.  Each subsequent packet  is
   sent with the next increment of the sequence number.

   The sequence number is thus a free running counter represented modulo



Taylor, Calhoun, Rubens   expires January 1999                  [Page 6]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


   65536.  For  purposes  of  detecting duplication, a received sequence
   value is considered less than or equal to the last received value  if
   its value lies in the range of the last value and its 32767 successor
   values. For example, if the last received  sequence  number  was  15,
   then  packets  with  sequence  numbers 0 through 15, as well as 32753
   through 65536, would be considered less than or equal to,  and  would
   be silently discarded. Otherwise it would be accepted.

   In this  document,  the  sequence  number  state  for  each  peer  is
   represented  for  clarity  in  the  following discussions by distinct
   pairs of state variables, Sr and Ss. Sr represents the value  of  the
   next in-sequence messages expected to be received for a given session
   by a peer. Ss represents the sequence number to be placed in  the  Ns
   field  of  the  next  message  sent  to  a  given peer. Each state is
   initialized such that the first message sent and  the  first  message
   expected  to  be received for to/from each peer has an Ns value of 0.
   This corresponds to initializing the Ss and Sr to 0 for each peer.

   As messages are sent to a given peer, Nr is set in these messages  to
   reflect  one  more than the Ns value of the highest (modulo 2^16) in-
   order message received by that peer.  In a message  sent  before  any
   message  is  received  Nr will be 0, indicating that the peer expects
   the next new Ns value to be 0.

   When an AVP-containing message is received  with  an  Ns  value  that
   matches  the  peer's current Sr value, Sr is incremented by 1 (modulo
   2^16). It is important to note that Sr is not modified if  a  message
   is  received  with  a  value if Ns greater than the current Sr value.
   Retransmission  of  lost  packets  should  eventually   provide   the
   receiving peer with the expected message.

   Every time a peer sends an AVP-containing message it  increments  its
   corresponding  Ss  value  for  that  session by 1 (modulo 2^16). This
   increment takes place after the current Ss value is copied to  Ns  in
   the message to be sent.  Outgoing messages always include the current
   value of Sr for the corresponding peer in their Nr field.

   A header-only message indicates that the  message  is  only  used  to
   communicate  Nr and Ns fields. The Nr and the Ns fields are filled in
   as above, but the sequence number state, Ss, is not incremented. Thus
   a  header-only  message  sent  after  an  AVP-containing message will
   contain the new Ns value while the AVP-containing message sent  after
   a  header-only  message  with  contain  the  same  value of Ns as the
   preceding header-only message.

   Upon receipt of an in-order  AVP-containing  message,  the  receiving
   peer  MUST  acknowledge the message by sending back the updated value
   of Sr in the Nr field of the next outgoing message. This  updated  Sr



Taylor, Calhoun, Rubens   expires January 1999                  [Page 7]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


   value  can  be  piggybacked  in  the  Nr  field of any AVP-containing
   ougoing messages that the peer may happen to send back.

   If the peer does not have a message to transmit for a short period of
   time  after receiving an AVP-containing message then it should send a
   header-only message containing the latest values of  Sr  and  Ss,  as
   described  above.  The  suggested value for this time interval is 1/4
   the receiving peer's value of Round-Trip-Time (RTT - see Appendix A),
   if it computes RTT, or a maximum of 1/2 of its fixed timeout interval
   otherwise. This timeout should provide a reasonable  opportunity  for
   the receiving peer to obtain a payload message destined for its peer,
   upon which the ACK of the received message can be piggybacked.

   This timeout  value  should  be  treated  as  suggested  maximum;  an
   implementation  could make this timeout quite small without adversely
   affecting  the  protocol.  To  provide  for  better  throughput,  the
   receiving  peer  should skip this timeout entirely and send a header-
   only message immediately in the case where its receive  window  fills
   and  it  has  no  queued data to send for this connection or it can't
   send queued data because the transmit window is closed.

   A  suggested  implementation  of  this  timer  is  as  follows:  Upon
   receiving an AVP-containing message, the receiver starts a timer that
   will expire in the recommended time interval. A variable, Lr (Last Nr
   value  sent), is used by the transmitter to store the last value sent
   in the Nr field of a transmitted payload message for this connection.
   Upon  expiration of this timer, Sr is compared to Lr and, if they are
   not equal, a header-only ACK is issued. If they are  equal,  then  no
   ACK's are outstanding and no action needs to be taken.

   This timer should not be reinitialized if a new message  is  received
   while  it is active since such messages will be acknowledged when the
   timer expires. This ensures that periodic ACK's  are  issued  with  a
   maximum  period  equal  to  the  recommended  timeout  interval. This
   interval should be short enough to not  cause  false  acknowledgement
   timeouts  at  the transmitter when payload messages are being sent in
   one direction only. Since such ACK's are being  sent  on  what  would
   otherwise be an idle data path, their affect on performance should be
   small, of not negligible.

   See Appendix B for some examples of how sequence numbers progress.


3.0     Header Format

   A summary of the IPDC message format is shown below. The  fields  are
   transmitted  from  left  to  right.  This format is identical to that
   proposed for DIAMETER [2].



Taylor, Calhoun, Rubens   expires January 1999                  [Page 8]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  RADIUS PCC   |PKT Flags| Ver |         Packet Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Identifier                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Next Send (Ns)        |       Next Received (Nr)      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Attributes ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-

   RADIUS PCC (Packet Compatibility Code)
      The RADIUS PCC  field is a one  octet  field  which  is  used  for
      RADIUS  backward  compatibility.  In  order  to easily distinguish
      DIAMETER/IPDC messages  from  RADIUS  a  special  value  has  been
      reserved  and  allows  an implementation to support both protocols
      concurrently using the first octet in the header. The  RADIUS  PCC
      field MUST be set as follows:

            254       DIAMETER/IPDC message

   PKT Flags
      The Packet Flags field is five bits,  and  is  used  in  order  to
      identify  any options. This field MUST be initialized to zero. The
      following flag MAY be set:
            Window-Present             0x1
      When set, the Next Send and Next Received fields are present. This
      MUST be set unless the underlying layer provides reliability (i.e.
      TCP).

   Version
      The Version field is three bits, and indicates the version  number
      which  is associated with the packet received.  This field MUST be
      set to 1 to indicate IPDC Version 1.

   Packet Length
      The Packet Length field is two octets.  It indicates the length of
      the  message including the header fields; thus message AVP content
      MUST NOT exceed 65,528 octets.  For  messages  received  via  UDP,
      octets  outside the range of the Length field should be treated as
      padding and should be ignored upon receipt.

   Identifier
      The Identifier field is four octets, and aids in matching requests
      and  replies.  The  sender  MUST  ensure  that the identifier in a
      message is locally unique (to the sender) at any given  time,  and
      MAY  attempt  to  ensure that the number is unique across reboots.



Taylor, Calhoun, Rubens   expires January 1999                  [Page 9]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


      The identifier is normally a monotonically increasing number,  but
      using  a  random  value  is  also permitted. Given the size of the
      Identifier field it  is  unlikely  that  2^32  requests  could  be
      outstanding at any given time.

   Next Send
      This field is present when the Window-Present bit is  set  in  the
      header  flags. The Next Send (Ns) is copied from the send sequence
      number state variable, Ss, at the time the message is transmitted.
      Ss is incremented after copying if the message contains any AVPs.

   Next Received
      This field is present when the Window-Present bit is  set  in  the
      header  flags. Nr is copied from the receive sequence number state
      variable, Sr, and indicates the sequence number,  Ns,  +1  of  the
      highest  (modulo  2^16)  in-sequence message received. See section
      2.0 for more information.

   Attributes
      See section 4.0 for more information on  attribute  formats.   The
      end  of  the  list  of  attributes is defined by the length of the
      message minus the length of the header.


3.1     Transaction Identification

   In addition to the use of the transaction  Identifier  field  of  the
   message  header  described  above,  all  implementations of IPDC MUST
   include an instance of Transaction-Originator AVP  in  each  message.
   This AVP MUST identify the originator of the transaction to which the
   current message belongs.   In other words, as well as  assigning  the
   value  of  the  Identifier,  the  IPDC protocol endpoint initiating a
   transaction records its identity by means of a Transaction-Originator
   AVP.   All  subsequent  messages  in  that  transaction MUST copy the
   original Identifier and Transaction-Originator values.

   The intent is that the combination  of  Identifier  and  Transaction-
   Originator  provides  a unique transaction identifier over the set of
   all such identifiers outstanding at a given moment of time  over  the
   complete  network.   This  is  necessary  because IPDC is designed to
   allow transactions to survive the specific control sessions in  which
   they  originated.   It  is  possible,  for example, that when a Media
   Gateway Controller fails a new Media Gateway Controller acting  as  a
   hot   stand-by   to  the  failed  unit  takes  over  the  outstanding
   transactions from the IPDC control session which  was  terminated  by
   the  failure.   The  new  Media  Gateway  Controller  may  have other
   outstanding transactions, whose identifiers must not be duplicated by
   those of the transactions from the failed unit.



Taylor, Calhoun, Rubens   expires January 1999                 [Page 10]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


4.0     AVP Format

   IPDC Attributes carry the specific commands and parameters which must
   be  exchanged  between  IPDC  protocol endpoints to perform the tasks
   associated with Media Gateway control.  IPDC attributes may be viewed
   as  a  class  of  DIAMETER  attributes,  since the AVPs have the same
   header format.

   Some DIAMETER Attributes MAY be listed more than once.  The effect of
   this  is  command  specific,  and is specified by each such attribute
   description.  IPDC avoids  this  condition  as  a  matter  of  design
   philosophy.

   Each AVP MUST be padded to align on a 32 bit boundary.  Although this
   is  not  problematic  for  most attribute types, it does require that
   AVPs of string and data type be padded accordingly.  The padding size
   can be deduced using the following formula:

         padding_size = (4 - (Length modulo 4)) modulo 4

   A summary of the attribute format is shown  below.   The  fields  are
   transmitted from left to right.

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           AVP Code                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          AVP Length           |     Reserved      |P|T|V|E|H|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Vendor ID (opt)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Tag (opt)           |    Value ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code
      The AVP Code field is four octets. The first 256 AVP  numbers  are
      reserved  for backward RADIUS compatibility.  Up-to-date values of
      the RADIUS Type field are specified in the most  recent  "Assigned
      Numbers"  RFC  [8].   Each  extension  MUST  allocate  AVP numbers
      through the IANA.  AVP numbers between 1000 and 1999 are used  for
      IPDC.

      If the Vendor-Specific-AVP flag is set, the AVP Code is  allocated
      from  the vendor's private address space, with one exception.  The
      AVP Code 256 is reserved for commands in all address spaces.   See
      the   documentation   of  the  Command  AVP  in  section  5.1  for
      interpretation of that AVP when the  Vendor-Specific-AVP  flag  is



Taylor, Calhoun, Rubens   expires January 1999                 [Page 11]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


      set.

   AVP Length
      The AVP Length field is two octets, and indicates  the  length  of
      this  Attribute  including the AVP Code, AVP Length, Reserved, AVP
      Flags, Vendor ID if present and the attribute value  field.  If  a
      message  is received with an invalid attribute length, the message
      SHOULD be rejected.

      In AVP descriptions, the indicated length corresponds to  the  AVP
      format as illustrated, which in general excludes the length of the
      Tag field, the Vendor ID in the header, and other  vendor-specific
      information.

   Reserved
      The Reserved field MUST be set to zero (0) in all AVPs.

   AVP Flags
      The AVP Flags field informs the DIAMETER host how  each  attribute
      must be handled.

         The 'M' Bit, known as  the  Mandatory  bit,  indicates  whether
         support  of the AVP is required. If an AVP is received with the
         'M' bit enabled and the receiver does not support the AVP,  the
         request MUST be rejected.  AVPs without the 'M' bit enabled are
         informational only and a receiver that receives a message  with
         such an AVP that is not supported MAY simply ignore the AVP.

         When the 'H' bit is enabled it indicates that the AVP  data  is
         encrypted using hop-by-hop encryption. See section 6.6 for more
         information.

         When the 'E' bit is enabled it indicates that the AVP  data  is
         encrypted using end-to-end encryption. See section 6.6 for more
         information.

         The 'V'  bit,  known  as  the  Vendor-Specific  bit,  indicates
         whether  the  optional  Vendor  ID  field is present in the AVP
         header. When set, the AVP Code belongs to the  specific  vendor
         code  address  space, with the sole exception of AVP Code 256 -
         Command AVP.  This AVP Code code is  reserved  in  all  address
         spaces.   See the description of the Command AVP in section 5.1
         for more details.

         The 'T' bit, known as the Tag bit, is used  to  group  sets  of
         AVPs together. Grouping of AVPs is necessary when more than one
         AVP is needed to express a condition.




Taylor, Calhoun, Rubens   expires January 1999                 [Page 12]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


         The 'P' bit, known  as  the  protected  AVP  bit,  is  used  to
         indicate  whether  the  AVP is protected by a Digital Signature
         AVP. When set, the AVP is protected and the contents cannot  be
         changed by a DIAMETER proxy server.

      Unless otherwise specified in the description  of  specific  AVPs,
      IPDC  imposes  the  following constraints on the values of the AVP
      Flags:
         * the 'M' bit MUST be set
         * the 'H', 'E', and 'P' bits MAY be set
         * the 'V' bit MAY be set
         * the 'T' bit MUST NOT be set.

   Vendor ID
      The optional four octet Vendor ID  field  contains  the  the  IANA
      assigned  "SMI Network Management Private Enterprise Codes" value,
      encoded in network byte order.  Vendors wishing to implement  IPDC
      extensions  can  use  their  own  Vendor  IDs  along  with private
      Attribute values, guaranteeing that they will not collide with any
      other vendor's extensions, nor with future IETF extensions.

      The value zero, reserved in this  protocol,  corresponds  to  IETF
      adopted  Attribute  values,  defined within this document and MUST
      NOT be used in an AVP since it is implied with the absence of  the
      Vendor-Specific-AVP bit.

   Tag
      The Tag field is optional; its presence is  signalled  by  setting
      the  'T'  AVP  Flag  bit.  It contains a 16-bit value which is the
      same for all AVPs in the same tag group.  Tag groups are  used  to
      distinguish  sets  of  related AVPs within a single message, where
      otherwise these relationships would be ambiguous.  Thus the  value
      of the tag for a given tag group must be unique over all tags used
      within the same message.  See section 6.4 for more information  on
      the use of tags.  The use of tagging is command dependent and must
      be specified as part  of  the  description  of  any  command  that
      requires such use.

   Value
      The Value field is zero or more octets  and  contains  information
      specific  to  the  Attribute.  The  format and length of the Value
      field is determined by the AVP Code and AVP Length fields.

      The format of the Value field MAY be one  of  six  primitive  data
      types.  It  is  also  possible  for  the  Value  field  to  have a
      structure, which MUST be defined along with  the  attribute.   The
      type  of  the  Value field is implicit in the AVP description, not
      coded explicitly.  The primitive types are:



Taylor, Calhoun, Rubens   expires January 1999                 [Page 13]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


      Data
         0-65520 octets of arbitrary data.

      String
         0-65520 octets of string data using the UTF-8 character set.

      Address
         32 bit network address, most significant octet first, or 48 bit
         transport address, network address part first, most significant
         octet  first  for  each  of  the  network  address   and   port
         respectively.     The  choice  between  network  and  transport
         address is indicated by the AVP length.  This specification  of
         the  address  data  type  amplifies  that given in the DIAMETER
         specification [2], but is believed to capture its intent.

      Integer32
         32 bit value, most significant octet first.

      Integer64
         64 bit value, most significant octet first.

      Time
         32  bit  value,  most  significant  octet  first-seconds  since
         00:00:00 GMT, January 1, 1970.


5.0     AVP Definitions

   IPDC Base attributes include those inherited from  DIAMETER  [2]  and
   those  added  specifically  for IPDC.  Because of its special role in
   defining message purpose and format, the Command AVP and the commands
   contained  in DIAMETER/IPDC Base are documented separately from other
   attributes.  Section 5.1 describes the Command AVP, while subsections
   of  section  5.1  describe  the  individual  commands.   Section  5.2
   describes the other attributes contained in DIAMETER/IPDC Base.

5.1     Command AVP

   Description

   The Command AVP MUST be the first AVP following the  message  header.
   This  AVP  is  used  to  communicate the purpose and structure of the
   message.  There MUST only be a single  Command  AVP  within  a  given
   message. The format of the AVP is as follows:

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Taylor, Calhoun, Rubens   expires January 1999                 [Page 14]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


   |                           AVP Code                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          AVP Length           |     Reserved      |P|T|V|E|H|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Command Code                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Additional data depending on the specific command      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code
      256     Command.  The AVP Code value 256 is reserved to denote  an
      Command  AVP even if the Vendor-Specific-AVP bit is set.  However,
      in that case the  interpretation  of  the  Command  Code  and  any
      additional content in the value field is vendor-specific.

   AVP Length
      The length of this attribute MUST be at least 12. The exact length
      of the AVP is determined by the actual Command and is defined with
      each command.

   AVP Flags
      The Vendor-Specific-AVP bit MUST be set if and only if the command
      is vendor-specific.

   Command Code
      The Command Code field contains the command number.  IPDC  command
      numbers are taken from the range 1000-1999.


5.1.1   DIAMETER Base Commands

   Definitions for the following  commands are copied from [2] and  MUST
   be  supported  by all DIAMETER implementations in order to conform to
   the  DIAMETER  base  protocol  specification.   IPDC   requires,   in
   contradiction  to  DIAMETER,  that  IPDC implementations use the IPDC
   command Message-Reject  instead  of  the  DIAMETER  command  Command-
   Unrecognized-Ind.   Note  that  Message-Reject has greater scope than
   Command-Unrecognized-Ind.


            Command Name          Command Code

         Command-Unrecognized-Ind      256
         Device-Reboot-Ind             257
         Device-Watchdog-Ind           258
         Device-Feature-Query          259
         Device-Feature-Reply          260
         Device-Config-Request         304



Taylor, Calhoun, Rubens   expires January 1999                 [Page 15]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


         Device-Config-Answer          305

5.1.1.1 Command-Unrecognized-Ind (CUI)

   Description

   This description appears as a matter of record only:  it  applies  to
   DIAMETER  devices  other than IPDC protocol endpoints.  IPDC protocol
   endpoints MUST use the Message-Reject command with appropriate return
   code instead of the Command-Unrecognized-Ind command.

   Messages with the Command-Unrecognized-Ind AVP  MUST  be  sent  by  a
   DIAMETER  device  to inform its peer that a message was received with
   an unsupported Command AVP value.

   Since there certainly will exist a case where an existing device does
   not  support a new extension to the DIAMETER protocol, a device which
   receives a packet with an unrecognized Command  code  MUST  return  a
   Command-Unrecognized-Ind message.

   Message Format

      <Unrecognized-Command-Ind> ::= <DIAMETER Header>
                               <Unrecognized-Command-Ind Command AVP>
                               <Unrecognized-Command-Code AVP>
                               <Host-IP-Address AVP>
                               [<Host-Name AVP>]
                               <Timestamp AVP>
                               <Initialization-Vector AVP>
                               {<Integrity-Check-Vector AVP> ||
                                <Digital-Signature AVP }

   A summary of the  Command-Unrecognized-Ind  packet  format  is  shown
   below.  The fields are transmitted from left to right.

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           AVP Code                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          AVP Length           |     Reserved      |P|T|V|E|H|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Command Code                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code
      256     DIAMETER Command




Taylor, Calhoun, Rubens   expires January 1999                 [Page 16]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


   AVP Length
      The length of this attribute MUST be 12.

   AVP Flags
      The flag field MUST have bit one (Mandatory Support) set.

   Command Code
      The Command Code field MUST be set to  256  (Command-Unrecognized-
      Ind).


5.1.1.2 Device-Reboot-Indication (DRI)

   Description

   The Device-Reboot-Indication message is sent by a DIAMETER device  to
   inform  all  of its peers either of an upcoming reboot or that it has
   just rebooted.

   The Reboot-Type AVP MUST be present and indicates the type of  reboot
   associated  with  this  command. The peer MUST respond to the message
   with a successful acknowledgement. Note that a DIAMETER device should
   only send this message once it is able to receive network traffic.

   This message is also used by a DIAMETER device in order  to  exchange
   the  supported  protocol  version  number  as  well  as all supported
   extensions. The originator of this message MUST  insert  its  highest
   supported  version  number  within the DIAMETER header.  The response
   message  MUST  include  the  highest  supported  version  up  to  and
   including the version number within the request.

   Similarly the originator of this message MUST include  all  supported
   extensions  within  the  message.  The  responder  MUST  include  all
   supported extensions as long as they were present within the  request
   message.  In  the  case where the receiver of this message is a proxy
   device, it is responsible for inserting the  highest  version  number
   which  it  supports  in  the  version  field before sending the proxy
   request to the remote DIAMETER peer. The proxy device may then retain
   the  version  number  of the remote peers as received in the message,
   and must insert its highest  version  number  (with  the  limitations
   described above) in the response to the initiator.

   It is desirable  for  a  DIAMETER  device  to  retain  the  supported
   extensions  as well as the version number to ensure that any requests
   issued to a peer will be processed.

   This message MUST contain the Receive-Window AVP and MAY contain  the
   Version-Number, Vendor-Name and Extension-Id AVPs.



Taylor, Calhoun, Rubens   expires January 1999                 [Page 17]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


   In the case where a IPDC/DIAMETER device such as  the  Media  Gateway
   Controller is configured to communicate with many peers, this message
   MUST be issued to each peer.

   No explicit DIAMETER message is necessary to acknowledge this message
   since it is handled by DIAMETER's reliable transport.

   Message Format

      <Device-Reboot-Ind> ::= <DIAMETER Header>
                              <Device-Reboot-Ind Command AVP>
                              <Transaction-Originator AVP>
                              <Reboot-Type AVP>
                              [<Reboot-Time AVP>]
                              <Host-IP-Address AVP>
                              [<Host-Name AVP>]
                              <Vendor-Name AVP>
                              <Firmware-Revision AVP>
                              [<X509-Certificate AVP>]
                              [<X509-Certificate-URL AVP>]
                              <Timestamp AVP>
                              <Initialization-Vector AVP>
                              {<Integrity-Check-Vector AVP> ||
                               <Digital-Signature AVP }

   In the case where a DIAMETER device is configured to communicate with
   many peers, this message MUST be issued to each peer.  For IPDC, this
   applies in particular to a recovering Media Gateway Controller.

   AVP Format

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           AVP Code                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          AVP Length           |     Reserved      |P|T|V|E|H|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Command Code                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code
      256     DIAMETER Command

   AVP Length
      The length of this attribute MUST be 12.

   AVP Flags



Taylor, Calhoun, Rubens   expires January 1999                 [Page 18]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


      As per IPDC defaults.

   Command Code
      The  Command  Code  field  MUST  be  set  to  257  (Device-Reboot-
      Indication).


5.1.1.3          Device-Watchdog-Ind (WDI)

   Description

   Device-Watchdog-Ind is used as  a  keepalive  mechanism  between  two
   DIAMETER peers. When UDP is used as the transport layer, this message
   alone is not  sufficient  to  detect  loss  of  connectivity  at  the
   application  level;  it  must  be  supplemented  with  the use of the
   message sequence number mechanisms described  in  section  2.1.   See
   examples of the use of Device-Watchdog-Ind  in Appendix B.

   This message MUST contain the Host-IP-Address  or  Host-Name  AVP  as
   well as any security related AVPs.

   No explicit DIAMETER message is necessary to acknowledge this message
   since it is handled by DIAMETER's reliable transport.

   Message Format

      <Device-Watchdog-Ind> ::= <DIAMETER Header>
                                <Device-Watchdog-Ind Command AVP>
                                <Transaction-Originator AVP>
                                <Host-IP-Address AVP>
                                [<Host-Name AVP>]
                                <Timestamp AVP>
                                <Initialization-Vector AVP>
                                {<Integrity-Check-Vector AVP> ||
                                 <Digital-Signature AVP }

   AVP Format

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           AVP Code                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          AVP Length           |     Reserved      |P|T|V|E|H|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Command Code                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Taylor, Calhoun, Rubens   expires January 1999                 [Page 19]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


   AVP Code
      256     Command

   AVP Length
      The length of this attribute MUST be 12.

   AVP Flags
      As per IPDC defaults.

   Command Code
      The Command Code field MUST be set to 258 (Device-Watchdog-Ind).


5.1.1.4 Device-Feature-Query (DFQ)

   Description

   The Device-Feature-Query message is used in order  to  query  a  peer
   about   its  supported  extensions.  This  message  MAY  contain  the
   Version-Number, Vendor-Name and Extension-Id AVPs.

   Message Format

      <Device-Feature-Query> ::= <DIAMETER Header>
                                 <Device-Feature-Query Command AVP>
                                 <Transaction-Originator AVP>
                                 [<Version-Number>]
                                 [<Vendor-Name>]
                                 [<Extension-Id>]
                                 <Timestamp AVP>
                                 <Initialization-Vector AVP>
                                 {<Integrity-Check-Vector AVP> ||
                                  <Digital-Signature AVP }

   AVP Format

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           AVP Code                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          AVP Length           |     Reserved      |P|T|V|E|H|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Command Code                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code
      256     Command



Taylor, Calhoun, Rubens   expires January 1999                 [Page 20]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


   AVP Length
      The length of this attribute MUST be 12.

   AVP Flags
      As per IPDC defaults.

   Command Code
      The Command Code field MUST be set to 259 (Device-Feature-Query).


5.1.1.5  Device-Feature-Reply (DFR)

   Description

   The Device-Feature-Reply message is sent in response to  the  Device-
   Feature-Query message. This message includes all extensions supported
   by the responder and MAY contain the Version-Number, Vendor-Name  and
   Extension-Id AVPs.

   Message Format

      <Device-Feature-Reply> ::= <DIAMETER Header>
                                 <Device-Feature-Reply Command AVP>
                                 <Transaction-Originator AVP>
                                 [<Version-Number>]
                                 [<Vendor-Name>]
                                 <Extension-Id>
                                 <Timestamp AVP>
                                 <Initialization-Vector AVP>
                                 {<Integrity-Check-Vector AVP> ||
                                  <Digital-Signature AVP }

   AVP Format

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           AVP Code                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          AVP Length           |     Reserved      |P|T|V|E|H|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Command Code                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code
      256     Command

   AVP Length



Taylor, Calhoun, Rubens   expires January 1999                 [Page 21]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


      The length of this attribute MUST be 12.

   AVP Flags
      As per IPDC defaults.

   Command Code
      The Command  Code  field  MUST  be  set  to  260  (Device-Feature-
      Response).


5.1.1.6  Device-Config-Request (DCR)

   Description

   The Device-Config-Request message is sent by  a  DIAMETER  device  to
   provide  configuration  information  to  peers  under  administrative
   control of the sender. Peers receiving this information SHOULD use it
   when communicating with the originator of this message. The peer MUST
   respond to the message with a Device-Config-Answer.

   This message MAY contain vendor specific AVPs which MAY be ignored by
   the receiver.

   IPDC implementations MUST include the Transaction-Originator  AVP  as
   specified  in  section  3.1.   IPDC  implementations  MAY include the
   Session-ID AVP.

   Message Format

      <Device-Config-Request> ::= <DIAMETER Header>
                                  <Device-Config-Request Command AVP>
                                  <Transaction-Originator AVP>
                                  <Session-Id AVP>
                                  [<Message-Timer>]
                                  [<MessageInProgress-Timer>]
                                  [<Message-Retry-Count>]
                                  [<Maximum-Forward-Count>]
                                  [<Extension-Id>]
                                  [<Version-Number>]
                                  [<Vendor-Name>]
                                  [<Vendor-Specific AVPs>]
                                  <Timestamp AVP>
                                  <Initialization-Vector AVP>
                                  {<Integrity-Check-Vector AVP> ||
                                   <Digital-Signature AVP }

   AVP Format




Taylor, Calhoun, Rubens   expires January 1999                 [Page 22]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           AVP Code                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          AVP Length           |     Reserved      |P|T|V|E|H|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Command Code                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code
      256     DIAMETER Command

   AVP Length
      The length of this attribute MUST be 12.

   AVP Flags
      As per IPDC defaults.

   Command Code
      The Command Code field MUST be set to 304 (Device-Config-Request).


5.1.1.7  Device-Config-Answer (DCA)

   Description

   The Device-Config-Answer message is sent  by  a  DIAMETER  device  to
   acknowledge receipt of the Device-Config-Request message.

   The Device-Config-Answer message MUST contain the Result-Code AVP  to
   indicate  whether the configuration was accepted. The Result-Code MAY
   be used to indicate refusal of any of the AVPs in the request.

   The Device-Config-Answer message MAY contain configuration  AVPs  and
   if  they are present it is understood that the receiver has no way to
   refuse them.

   IPDC implementations MUST include the Transaction-Originator  AVP  as
   specified  in  section  3.1.   IPDC  implementations  MAY include the
   Session-ID AVP.

   Message Format

     <Device-Config-Answer> ::= <DIAMETER Header>
                                 <Device-Config-Answer Command AVP>
                                 <Transaction-Originator AVP>
                                 <Session-Id AVP>



Taylor, Calhoun, Rubens   expires January 1999                 [Page 23]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


                                 <Result-Code AVP>
                                 [<Message-Timer AVP>]
                                 [<MessageInProgress-Timer AVP>]
                                 [<Message-Retry-Count AVP>]
                                 [<Maximum-Forward-Count AVP>]
                                 [<Extension-Id AVP>]
                                 [<Version-Number AVP>]
                                 [<Vendor-Name AVP>]
                                 [<Vendor-Specific AVPs>]
                                 <Timestamp AVP>
                                 <Initialization-Vector AVP>
                                 {<Integrity-Check-Vector AVP> ||
                                  <Digital-Signature AVP }

   AVP Format

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           AVP Code                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          AVP Length           |     Reserved      |P|T|V|E|H|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Command Code                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code
      256     DIAMETER Command

   AVP Length
      The length of this attribute MUST be 12.

   AVP Flags
      As per IPDC defaults.

   Command Code
      The Command Code field MUST be set to 305 (Device-Config-Answer).


5.1.2   Additional IPDC Commands

   The following  commands  are  defined  in  this  draft  and  MUST  be
   supported by all IPDC implementations:

         Command Name       Command Code

         Command-Ack            1100
         Message-Reject         1101



Taylor, Calhoun, Rubens   expires January 1999                 [Page 24]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


5.1.2.1 Command-Ack (ACK)

   Description

   The Command-Ack  command  provides  a  generic  means  of  completing
   transactions  by  acknowledging   the  messages which initiated them.
   The documentation for each transaction-initiating IPDC  command  MUST
   indicate  if  the expected response to that command is Command-Ack or
   some more specialized command type. The structure of the  Command-Ack
   message is defined as follows:

   <Command-Ack message> ::=
       <Message Header>
       <Command AVP>
       <Transaction-Originator AVP>

   where  the  Identifier  value  in  the   message   header   and   the
   Transaction-Originator   AVP   are  copied  from  the  message  being
   acknowledged and the Command AVP has the following format:

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           AVP Code                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          AVP Length           |     Reserved      |P|T|V|E|H|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Command Code                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code
      256     Command

   AVP Length
      The length of this attribute MUST be at exactly 12.

   AVP Flags
      As per IPDC defaults.

   Command Code
      1100     Command-Ack


5.1.2.3 Message-Reject (MRJ)

   Description

   The Message-Reject command provides a  generic  means  of  completing



Taylor, Calhoun, Rubens   expires January 1999                 [Page 25]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


   transactions  by  indicating  errors  in the messages which initiated
   them.  The Message-Reject command is a possible response to any  IPDC
   command,  but  some  IPDC  commands MAY expect more specialized error
   messages, depending on the error type.

   The  Message-Reject  message  MUST  contain  the   same   transaction
   identification   (header   Identifier  field,  Transaction-Originator
   value)  as  the  message  it  is  responding   to,   even   if   that
   identification is erroneous.  The receiver of a Message-Reject SHOULD
   examine the Result-Code  value  it  provides  before  processing  the
   transaction   identification,   in   order   to   handle  the  latter
   appropriately.

   The structure of the Message-Reject message is defined as follows:

      <Message-Reject message> ::=
          <Message Header>
          <Command AVP>
          <Transaction-Originator AVP>
          <Result-Code AVP>
          [ <Error-Code AVP> ]
          [ <Failed-AVP-Code AVP> ]
          [ <Unknown-Command-Code AVP> ]

   where  the  Identifier  value  in  the   message   header   and   the
   Transaction-Originator AVP are copied from the message being rejected
   and the Command AVP has the format described below.  The  Result-Code
   and  conditionally-present Error-Code AVPs indicate the nature of the
   error causing rejection, and  the  conditionally-present  Failed-AVP-
   Code  AVP  provides  some  minimal  debugging  data  by  indicating a
   specific AVP type which caused the problem.  See the  description  of
   the  Result-Code  AVP  in section 5.2.1.14 for indication of when the
   Error-Code  and/or  Failed-AVP-Code  AVPs  will  be  present  in  the
   message.   The  Unknown-Command-Code  AVP  is  present  only when the
   reason for  message  rejection  is  an  unrecognized  or  unsupported
   command code.

   The documentation  of  individual  IPDC  commands  MAY  also  include
   documentation  of  the expected contents of an ensuing Message-Reject
   message, beyond the information given in section 5.2.1.14.

   The format of the Command AVP for Message-Reject is as follows:

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           AVP Code                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Taylor, Calhoun, Rubens   expires January 1999                 [Page 26]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


   |          AVP Length           |     Reserved      |P|T|V|E|H|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Command Code                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code
      256     Command

   AVP Length
      The length of this attribute MUST be at exactly 12.

   AVP Flags
      As per IPDC defaults.

   Command Code
      1101     Message-Reject



5.2     Other AVPs

   This section defines the IPDC Base attributes other than the  Command
   AVP.   A  number of these attributes are inherited from DIAMETER Base
   [2];  these  are  documented  in  section  5.2.1.   IPDC  adds   some
   additional attributes, documented in section 5.2.2.


5.2.1   DIAMETER Base AVPs

   Aside from the Command AVP, DIAMETER Base [2] defines  the  following
   AVPs:

      Attribute Name      Attribute Code

      Host-IP-Address               4
      Host-Name                    32
      Version-Number              257
      Extension-Id                258
      Integrity-Check-Vector      259
      Digital-Signature           260
      Initialization-Vector       261
      Timestamp                   262
      Session-Id                  263
      X509-Certificate            264
      X509-Certificate-URL        265
      Vendor-Name                 266
      Firmware-Revision           267
      Result-Code                 268



Taylor, Calhoun, Rubens   expires January 1999                 [Page 27]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


      Error-Code                  269
      Unknown-Command-Code        270
      Reboot-Type                 271
      Reboot-Timer                272
      Message-Timer               273
      Message-In-Progress-Timer   274
      Message-Retry-Count         275
      Message-Forward-Count       276
      Receive-Window              277


5.2.1.1 Host-IP-Address

   Description

   The Host-IP-Address attribute is used to inform a  DIAMETER  peer  of
   the sender's identity.

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           AVP Code                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          AVP Length           |     Reserved      |P|T|V|E|H|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Address                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code
      4     Host-IP-Address

   AVP Length
      The length of this attribute MUST be at least 12.

   AVP Flags
      As per IPDC defaults.

   Address
      The Address field is of type Address and contains the sender's  IP
      address.


5.2.1.2 Host-Name

   Description

   The Host-Name attribute is used to inform  a  DIAMETER  peer  of  the
   sender's identity.



Taylor, Calhoun, Rubens   expires January 1999                 [Page 28]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           AVP Code                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          AVP Length           |     Reserved      |P|T|V|E|H|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Name ...
   +-+-+-+-+-+-+-+-+

   AVP Code
      32     Host-Name

   AVP Length
      The length of this attribute MUST be at least 9.

   AVP Flags
      As per IPDC defaults.

   Name
      The Name field is of type String.  It  consists  of  one  or  more
      octets,  and should be unique to the DIAMETER host.  The Host Name
      MUST follow the NAI [12] naming conventions.


5.2.1.3 Version-Number

   Description

   [Whether IPDC has its own version numbering independently of DIAMETER
   is  for  future  determination.]   The  Version-Number AVP is used in
   order to indicate the current DIAMETER system  version  number  to  a
   peer.  It has the following format:

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           AVP Code                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          AVP Length           |     Reserved      |P|T|V|E|H|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Version                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code
      257     Version-Number

   AVP Length



Taylor, Calhoun, Rubens   expires January 1999                 [Page 29]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


      The length of this attribute MUST be 12.

   AVP Flags
      As per IPDC defaults.

   Version
      Version is of type Integer32, and contains the  system's  DIAMETER
      version number.


5.2.1.4 Extension-Id

   Description

   The Extension-Id AVP is used in order to identify a specific DIAMETER
   extension.  This  AVP  MAY  be  used in the Device-Reboot-Ind and the
   Device-Feature-Response command in order  to  inform  the  peer  what
   extensions are locally supported.

   Each DIAMETER extensions draft MUST have a Extension-Id  assigned  to
   it  by  the  IANA. The base protocol does not require an Extension-Id
   since its support is mandatory.  [Whether  IPDC  Base  and  the  IPDC
   extensions  described  in  [4],  [5],  [6], and [7] are registered as
   DIAMETER extensions or establish  an extension system of their own is
   for future determination.]

   There MAY be  more  than  one  Extension-Id  AVP  within  a  DIAMETER
   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           AVP Code                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          AVP Length           |     Reserved      |P|T|V|E|H|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Extension Number                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code
      258     Extension-Id

   AVP Length
      The length of this attribute MUST be 12.

   AVP Flags
      As per IPDC defaults.




Taylor, Calhoun, Rubens   expires January 1999                 [Page 30]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


   Extension Number
      The Extension Number  is  of  type  Integer32,  and  contains  the
      extension identifier as defined in the extension's document.


5.2.1.5 Integrity-Check-Vector

   Description

   The Integrity-Check-Vector AVP is used for hop-by-hop  authentication
   and  integrity,  and  is not recommended for use with untrusted proxy
   servers.  The message header as well as all AVPs up to and  including
   the  AVP  Code field of this AVP is protected by the Integrity-Check-
   Vector.   The  Timestamp  AVP  MUST  be  present  to  provide  replay
   protection  and  the Initialization-Vector AVP must be present to add
   randomness to the packet. The Integrity-Check-Vector is generated  by
   the method described in section 6.6.1.

   All DIAMETER/IPDC implementations MUST support this AVP.

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           AVP Code                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          AVP Length           |     Reserved      |P|T|V|E|H|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Transform ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Check Value ...
   +-+-+-+-+-+-+-+-+

   AVP Code
      259       Integrity-Check-Vector

   AVP Length
      The length of this attribute MUST be at least 13.

   AVP Flags
      The 'M' bit MUST be set. The 'E', 'H', and 'P' bits  MUST  NOT  be
      set.

   Transform ID
      The Transform ID field is of type  Integer32  and  identifies  the
      algorithm  used to generate the check value.  The following values
      are defined in this document:

         1       HMAC-MD5-96 [6]



Taylor, Calhoun, Rubens   expires January 1999                 [Page 31]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


   Check Value
      The Check Value field is of type Data and  contains  an  integrity
      check value for the message up to this AVP.


5.2.1.6 Digital-Signature

   Description

   The Digital-Signature AVP is used for authentication and integrity as
   well  as non-repudiation.  A DIAMETER entity adding AVPs to a message
   MUST ensure that all AVPs appear prior to the  Digital-Signature  AVP
   (with  the  exception  of  the Integrity-Check-Vector AVP, which MUST
   appear after the Digital-Signature AVP). The Timestamp  AVP  MUST  be
   present  to  provide  replay protection and the Initialization-Vector
   AVP MUST be present to add randomness to the packet.

   The DIAMETER header as well as all AVPs with the 'P' bit disabled are
   protected by the Digital-Signature.

   Note that for services which use the concept of a proxy server  which
   forwards  the request to a next hop server, the proxy server MUST NOT
   modify any attributes found prior to the Digital- Signature AVP. This
   ensures  that  end-to-end  security  is maintained even through proxy
   arrangements.

   The Digital-Signature is generated by the method described in section
   6.6.2.

   All DIAMETER implementations SHOULD support this AVP.   [Requirements
   for IPDC implementations are for future determination.]

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           AVP Code                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          AVP Length           |     Reserved      |P|T|V|E|H|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Address                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Transform ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Signature ...
   +-+-+-+-+-+-+-+-+

   AVP Code
      260       Digital-Signature



Taylor, Calhoun, Rubens   expires January 1999                 [Page 32]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


   AVP Length
      The length of this attribute MUST be at least 9.

   AVP Flags
      The 'M' bit MUST be set. The 'H' MAY be  set  if  the  request  is
      protected with an ICV AVP. The 'E'and 'P' bits MUST NOT be set.

   Address
      The Address field is of type Address and contains the  IP  address
      of the IPDC host which generated the Digital-Signature.

   Transform ID
      The Transform ID field is of type  Integer32  and  identifies  the
      algorithm  used  to  generate  the Signature value.  The following
      values are defined in this document:

         1       RSA [9]

   Signature
      The Signature field is of  type  Data  and  contains  the  digital
      signature of the packet up to this AVP.


5.2.1.7 Initialization-Vector

   Description

   The Initialization-Vector AVP MUST be present prior to  the  Digital-
   Signature  and  Integrity-Check-Vector  AVPs  within a message and is
   used to ensure randomness within a message. The content of  this  AVP
   MUST be a random 128 bit value.

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           AVP Code                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          AVP Length           |     Reserved      |P|T|V|E|H|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-+-+-+-+-+-+-+-+                               +-+-+-+-+-+-+-+-+
   |                                                               |
   +-+-+-+-+-+-+-+-+          Random               +-+-+-+-+-+-+-+-+
   |                                                               |
   +-+-+-+-+-+-+-+-+                               +-+-+-+-+-+-+-+-+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Taylor, Calhoun, Rubens   expires January 1999                 [Page 33]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


   AVP Code
      261       Initialization-Vector

   AVP Length
      The length of this attribute MUST be 24.

   AVP Flags
      As per IPDC defaults.

   Random
      The Random field is of type Data and  contains  a  random  128-bit
      value.


5.2.1.8 Timestamp

   Description

   The Timestamp field is used in order  to  enable  protection  against
   replay   of  previous  messages.  The  value  of  time  is  the  most
   significant four octets returned from an NTP server  which  indicates
   the number of seconds expired since Jan. 1, 1970.

   This  document  does  not  specify  the  window   within   which   an
   implementation   will   accept   packets;  however,  it  is  strongly
   encouraged  that  this  value  be  made  user  configurable  with   a
   reasonable default value (e.g. 4 seconds).

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           AVP Code                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          AVP Length           |     Reserved      |P|T|V|E|H|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Timestamp                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code
      262       Timestamp

   AVP Length
      The length of this attribute MUST be 12.

   AVP Flags
      As per IPDC defaults.

   Timestamp



Taylor, Calhoun, Rubens   expires January 1999                 [Page 34]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


      The Timestamp field is of type Time and contains the time at which
      the message was created.


5.2.1.9 Session-Id

   Description

   The Session-Id field is used in order to identify a specific session.
   All  messages pertaining to a specific session MUST  include this AVP
   and the same value MUST be used throughout the  life  of  a  session.
   When  present, the Session-Id SHOULD appear immediately following the
   Command- AVP.

   Note that in some applications there is no concept of a session (i.e.
   data  flow) and this field MAY be used to identify objects other than
   a session.

   The Session-Id MUST be globally unique at any given time since it  is
   used  by  the  server  to  identify  the  session  (or  flow).  It is
   recommended that the format of the AVP be as follows:

         <Sender's IP Address><monotonically increasing 32 bit value>
         <optional value>

   It is suggested that the monotonically increasing 32  bit  value  NOT
   start  at zero upon reboot, but rather start at a random value.  This
   will minimize the possibility  of  overlapping  Session-Ids  after  a
   reboot. The optional value is implementation specific but may include
   a modem's device Id, a random value, etc.

   The session Id is created  by  the  DIAMETER  device  initiating  the
   session.  In most cases this is the client.

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           AVP Code                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          AVP Length           |     Reserved      |P|T|V|E|H|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    SessionId ...
   +-+-+-+-+-+-+-+-+

   AVP Code
      263       Session-Id

   AVP Length



Taylor, Calhoun, Rubens   expires January 1999                 [Page 35]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


      The length of this attribute MUST be at least 12.

   AVP Flags
      As per IPDC defaults.

   SessionId
      The SessionId field is of  type  Data  and  contains  the  session
      identifier assigned to the session.


5.2.1.10        X509-Certificate

   Description

   The X509-Certificate is used  to  send  a  DIAMETER  peer  the  local
   system's  X.509  certificate  chain,  which  is  used to validate the
   Digital-Signature attribute.

   Section 6.8 contains more information about the use of certificates.

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           AVP Code                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          AVP Length           |     Reserved      |P|T|V|E|H|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Chain ...
   +-+-+-+-+-+-+-+-+

   AVP Code
      264       X509-Certificate

   AVP Length
      The length of this attribute MUST be at least 9.

   AVP Flags
      As per IPDC defaults.

   Chain
      The Chain field is of type Data and contains the X.509 Certificate
      Chain.


5.2.1.11        X509-Certificate-URL

   Description




Taylor, Calhoun, Rubens   expires January 1999                 [Page 36]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


   The X509-Certificate-URL is used  to  send  a  DIAMETER  peer  a  URL
   pointing to the local system's X.509 certificate chain, which is used
   in order to validate the Digital-Signature attribute.

   Section 6.8 contains more information about the use of certificates.

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           AVP Code                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          AVP Length           |     Reserved      |P|T|V|E|H|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   URL ...
   +-+-+-+-+-+-+-+-+

   AVP Code
      265       X509-Certificate-URL

   AVP Length
      The length of this attribute MUST be at least 9.

   AVP Flags
      As per IPDC defaults.

   URL
      The URL field is of type String and contains the X.509 Certificate
      Chain URL.


5.2.1.12        Vendor-Name

   Description

   The Vendor-Name attribute is used to tell a DIAMETER peer the  Vendor
   Name  of the DIAMETER device.  This MAY be used by the peer to decide
   which vendor specific attributes may be sent to this DIAMETER device.
   It is also envisioned that the combination of the Vendor-Name and the
   Firmware-Revision AVPs can provide very useful debugging 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           AVP Code                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          AVP Length           |     Reserved      |P|T|V|E|H|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Name ...



Taylor, Calhoun, Rubens   expires January 1999                 [Page 37]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


   +-+-+-+-+-+-+-+-+

   AVP Code
      266       Vendor-Name

   AVP Length
      The length of this attribute MUST be at least 9.

   AVP Flags
      As per IPDC defaults.

   Name
      The Name field is of type String and contains the vendor name.


5.2.1.13        Firmware-Revision

   Description

   The Firmware-Revision AVP is used to inform a DIAMETER  peer  of  the
   firmware revision of the issuing device.

   For devices which do not have a firmware  revision  (general  purpose
   computers  running  DIAMETER  software  modules,  for  instance), the
   revision of the DIAMETER software module may be reported instead.

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           AVP Code                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          AVP Length           |     Reserved      |P|T|V|E|H|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Revision Code                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code
      267       Firmware-Revision

   AVP Length
      The length of this attribute MUST be 12.

   AVP Flags
      As per IPDC defaults.

   Revision Code
      The Revision Code field is of  type  Integer32  and  contains  the
      firmware revision number of the issuing device.



Taylor, Calhoun, Rubens   expires January 1999                 [Page 38]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


5.2.1.14        Result-Code

   Description

   The Result-Code AVP is used to indicate whether a particular  command
   was   completed  successfully  or  whether  an  error  occurred.  All
   DIAMETER/IPDC commands MUST specify whether the Result-Code AVP  MUST
   be present.

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           AVP Code                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          AVP Length           |     Reserved      |P|T|V|E|H|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Result Code                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code
      268       Result-Code

   AVP Length
      The length of this attribute MUST be 12.

   AVP Flags
      As per IPDC defaults.

   Result Code
      The Result Code field is of type Integer32 and contains the result
      code  associated  with the DIAMETER or IPDC command. The following
      codes have been defined:

      DIAMETER_SUCCESS                0
         The Request was successfully  completed.   IPDC  responses  MAY
         contain  this  Result  Code  value, but typically positive IPDC
         responses will be conveyed by the Command-Ack message.

      DIAMETER_FAILURE                1
         The Request was not successfully completed for  an  unspecified
         reason.   An  IPDC Message-Reject message returning this result
         SHOULD whenever possible also contain one or  more  Failed-AVP-
         Code AVPs indicating the attributes which caused the failure.

      DIAMETER_POOR_REQUEST           2
         The Request was poorly  constructed.   An  IPDC  Message-Reject
         message  returning  this  result  SHOULD whenever possible also
         contain  one  or  more  Failed-AVP-Code  AVPs  indicating   the



Taylor, Calhoun, Rubens   expires January 1999                 [Page 39]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


         attributes which caused the failure.

      DIAMETER_INVALID_MAC            3
         The Request did not contain a valid  Integrity-Check-Vector  or
         Digital- Signature.

      DIAMETER_UNKNOWN_SESSION_ID     4
         The Request contained an unknown Session-Id.

      DIAMETER_SEE_ERROR_CODE         5
         The Request failed. The message MUST also contain an Error-Code
         AVP which provides command-specific information on the failure.
         An IPDC Message-Reject message  returning  this  result  SHOULD
         whenever possible also contain one or more Failed-AVP-Code AVPs
         indicating the attributes which caused the failure.

      IPDC_COMMAND_UNSUPPORTED     6
         The  Request  contained  a  command   code   which   the   IPDC
         implementation  does  not  recognize or does not support.  IPDC
         implementations MUST return a Message-Reject message containing
         this  Result  Code  value rather than use the DIAMETER Command-
         Unrecognized message.  The  Message-Reject  message  MUST  also
         contain  an Unknown-Command-Code AVP which contains the Command
         Code value which was rejected.

      IPDC_BAD_TRANSACTION_ID     7
         The  Request  contained  invalid  transaction   identification.
         Possible  errors  include a missing Transaction-Originator AVP,
         an  unrecognized  IPDC  protocol  endpoint  identifier  in  the
         Transaction-Originator  AVP  or  an  Identifier  value  in  the
         message header  of  a  response  which  is  not  recognized  as
         pertaining  to  a  currently  outstanding  transaction  at  the
         receiving IPDC protocol endpoint.

      IPDC_ATTRIBUTE_UNSUPPORTED     8
         The Request contained an AVP with an AVP Code  which  the  IPDC
         implementation does not recognize or does not support.  An IPDC
         Message-Reject message returning this result MUST also  contain
         one or more Failed-AVP-Code AVPs indicating the AVP Codes which
         caused the failure.


5.2.1.15        Error-Code

   Description

   The Error-Code AVP contains the message-specific error code, if  any.
   This  AVP  MUST  be  present  if  and  only if the Result-Code AVP is



Taylor, Calhoun, Rubens   expires January 1999                 [Page 40]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


   present containing the  value  DIAMETER_SEE_ERROR_CODE.   IPDC  error
   responses,  particularly  Message-Reject,  MAY  contain more than one
   Error-Code AVP, each possibly paired with a Failed-AVP-Code AVP.

   Error-Code values and corresponding semantics  are  specific  to  the
   command to which the Error-Code is a response, and  MUST therefore be
   documented as part of the description of that command.

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           AVP Code                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          AVP Length           |     Reserved      |P|T|V|E|H|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Error Code                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code
      268       Error-Code

   AVP Length
      The length of this attribute MUST be 12.

   AVP Flags
      As per IPDC defaults.

   Error Code
      The Error Code field is of type Integer32 and contains  the  error
      code value.


5.2.1.16  Unknown-Command-Code

   Description

   The Unknown-Command-Code AVP contains the offending Command Code that
   resulted in sending the Unrecognized-Command-Code message.

   AVP Format

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           AVP Code                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          AVP Length           |     Reserved      |P|T|V|E|H|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Taylor, Calhoun, Rubens   expires January 1999                 [Page 41]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


   |                         Command Code                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code
      270     Unknown-Command-Code

   AVP Length
      The length of this attribute MUST be 12.

   AVP Flags
      As per IPDC defaults.

   Command Code
      The Command Code field is of type Integer32 field and contains the
      unrecognized command code that resulted


5.2.1.17  Reboot-Type

   Description

   The Reboot-Type AVP MUST be present in  the  Device-Reboot-Indication
   message and contains an indication of the type of reboot.

   AVP Format

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           AVP Code                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          AVP Length           |     Reserved      |P|T|V|E|H|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Reboot Type                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code
      271     Reboot-Type

   AVP Length
      The length of this attribute MUST be 12.

   AVP Flags
      As per IPDC defaults.

   Reboot Type
      The Reboot Type field is of type Integer32 and contains the reboot
      type  associated  with  the  DRI command. The following values are



Taylor, Calhoun, Rubens   expires January 1999                 [Page 42]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


      currently defined:

      REBOOT_IMMINENT                 1
         When the Reboot-Type  AVP  is  set  to  this  value  it  is  an
         indication that the DIAMETER peer is about to reboot and should
         not be  sent  any  additional  DIAMETER  messages  besides  the
         acknowledgement.

      REBOOTED                        2
         When the Reboot-Type  AVP  is  set  to  this  value  it  is  an
         indication  that the DIAMETER peer has recently rebooted and is
         ready to accept new DIAMETER messages.

      CLEAN_REBOOT                    3
         When the Reboot-Type AVP is set to this value the server is  in
         the  process of shutting down and MAY be available at some time
         in the future.


5.2.1.18  Reboot-Time

   Description

   The Reboot-Time AVP MAY be present  in  the  DRI  and  indicates  the
   number  of  seconds  before the issuer expects to be ready to receive
   new DIAMETER messages.  This  AVP  MUST  only  be  present  when  the
   Reboot-Type  AVP  is  set  to REBOOT_IMMINENT. The value indicated by
   this AVP should be used as an estimate and is not a hard rule.

   AVP Format

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           AVP Code                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          AVP Length           |     Reserved      |P|T|V|E|H|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Estimated Outage                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code
      272     Reboot-Time

   AVP Length
      The length of this attribute MUST be 12.

   AVP Flags



Taylor, Calhoun, Rubens   expires January 1999                 [Page 43]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


      As per IPDC defaults.

   Estimated Outage
      The Estimated Outage field is of type Integer32 and  contains  the
      expected amount of seconds before the issuer of the DRI expects to
      be able to receive new DIAMETER messages.


5.2.1.19  Message-Timer

   Description

   This AVP is used by a device to determine how  long  to  wait  before
   trying   again   to   send   a   message   expecting  a  response  or
   acknowledgement. This timer  value  overrides  any  default  value  a
   device may have.

   Note that a DIAMETER extensions AVP could define another  timer  that
   would override this one for a specific message type.

   AVP Format

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           AVP Code                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          AVP Length           |     Reserved      |P|T|V|E|H|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Retry Time                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code
      273     Message-Timer

   AVP Length
      The length of this attribute MUST be 12.

   AVP Flags
      As per IPDC defaults.

   Retry Time
      The Retry Time field is of type Integer32 and contains  the  value
      of  the  retry  timer in milliseconds. A value of 0 for this timer
      means that the device's default value for  this  timer  is  to  be
      used.





Taylor, Calhoun, Rubens   expires January 1999                 [Page 44]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


5.2.1.20  Message-In-Progress-Timer

   Description

   This AVP is used by a device's state machine to deterimine  how  long
   to  wait  before sending a Message-In-Progress message that tells the
   peer device that the message for which it is expecting a response  or
   acknowledgment is still in progress.

   AVP Format

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           AVP Code                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          AVP Length           |     Reserved      |P|T|V|E|H|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Wait time                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code
      274     Message-In-Progress-Timer

   AVP Length
      The length of this attribute MUST be 12.

   AVP Flags
      As per IPDC defaults.

   Wait Time
      The Wait Time field is of type Integer32 and contains the value of
      the  timer  in  milliseconds.  A  value  of  0  indicates that the
      MessageInProgress-Indication message is not being used.


5.2.1.21  Message-Retry-Count

   Description

   This AVP is used by a device's state machine to  determine  how  many
   times it is allowed to resend a message that  is expecting a response
   or acknowledgement.

   AVP Format

   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



Taylor, Calhoun, Rubens   expires January 1999                 [Page 45]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           AVP Code                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          AVP Length           |     Reserved      |P|T|V|E|H|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Max Resends                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code
      275     Message-Retry-Count

   AVP Length
      The length of this attribute MUST be 12.

   AVP Flags
      As per IPDC defaults.

   Max Resends
      The Max Resends field  is  of  type  Integer32  and  contains  the
      maximum allowed retry count for a given message.


5.2.1.22  Maximum-Forward-Count

   Description

   This AVP is used by a device to determine if a message shouldcontinue
   to  be  forwarded.  A use for this count would be to limit the number
   of proxies used to satisfy a request.

   AVP Format

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           AVP Code                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          AVP Length           |     Reserved      |P|T|V|E|H|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Max Forwards                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code
      276     Maximum-Forward-Count

   AVP Length
      The length of this attribute MUST be 12.




Taylor, Calhoun, Rubens   expires January 1999                 [Page 46]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


   AVP Flags
      As per IPDC defaults.

   Max Forwards
      This field is of type Integer32 and  contains  the  limit  on  the
      number of times the message should be forwarded beyond the current
      node.


5.2.1.23  Receive-Window

   Description

   This AVP is used by a device to inform a peer of  the  local  receive
   window  size. The size indicated is the number of messages that it is
   willing to accept before the window is full.

   AVP Format

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           AVP Code                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          AVP Length           |     Reserved      |P|T|V|E|H|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Window                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code
      277     Receive-Window

   AVP Length
      The length of this attribute MUST be 12.

   AVP Flags
      As per IPDC defaults.

   Window
      This field is of type Integer32 and contains  the  receive  window
      size.


5.2.2   Additional IPDC AVPs

   The attributes defined in this section MUST be supported by all  IPDC
   implementations.




Taylor, Calhoun, Rubens   expires January 1999                 [Page 47]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


5.2.2.1 Transaction-Originator

   Description

   As described in section 3.1,  every  IPDC  message  must  contain  an
   instance   of   the  Transaction-Originator  AVP.   The  Transaction-
   Originator AVP contains information  which  uniquely  identifies  the
   IPDC   protocol   endpoint   which  originated  a  transaction.   The
   uniqueness MUST be broad  enough  in  scope  to  permit  transactions
   originated  in one control session to be continued in another control
   session where one of the endpoints has been replaced  after  failure.
   In  particular,  it  is  required in order to support takeover of the
   transaction by an alternate Media Gateway Controller.

   The Transaction-Originator AVP has the following format:

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           AVP Code                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          AVP Length           |     Reserved      |P|T|V|E|H|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Originator Id ...
   +-+-+-+-+-+-+-+-+-+-+-+

   AVP Code
      1000      Transaction-Originator

   AVP Length
      The length of this attribute MUST be at least 9.

   AVP Flags
      As per IPDC defaults.

   Originator Id
      The Originator Id field is of type Data and  contains  information
      of  arbitrary  format  which  uniquely identifies an IPDC protocol
      endpoint within the network.  Typically this information, combined
      with  the  value  of  the  Identifier field in the message header,
      provides an index into the list of outstanding transactions at the
      originating IPDC protocol endpoint.


5.2.2.2 Failed-AVP-Code

   Description




Taylor, Calhoun, Rubens   expires January 1999                 [Page 48]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


   The Failed-AVP-Code AVP provides debugging information in cases where
   a  request  is  rejected  or  not  fully  processed  due to erroneous
   information in a specific AVP.  The documentation of the  Return-Code
   AVP  in section 5.2.1.14 and of the Message-Reject command in section
   provide information on the use of the Failed-AVP-Code AVP.  This  AVP
   has the following format:

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           AVP Code                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          AVP Length           |     Reserved      |P|T|V|E|H|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Failed AVP Code                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code
      1001      Failed-AVP-Code

   AVP Length
      The length of this attribute MUST be 12.

   AVP Flags
      As per IPDC defaults.

   Failed AVP Code
      The Failed AVP Code field is of type Integer32  and  contains  the
      AVP   Code   value   of  an  AVP  which  could  not  be  processed
      successfully.   Possible  reasons  for  this  are  an  improperly-
      constructed  AVP,  an  unsupported or unrecognized AVP Code, or an
      invalid value.

      Note that where more than one instance of the same  AVP  Code  was
      present  in  the  message  to which the one containing the Failed-
      AVP-Code AVP  is  a  response,  the  value  of  the  AVP  Code  is
      insufficient  to  uniquely   identify  the  actual AVP causing the
      problem.



5.3     IPDC AVP Templates

   The  IPDC  design  philosophy  values  semantic  precision  over  re-
   usability  of  AVP  types.   Thus  the  same AVP structure may appear
   repeatedly, but associated with different  AVP  Codes.   IPDC  avoids
   dependence on AVP sequence within a message to convey meaning.




Taylor, Calhoun, Rubens   expires January 1999                 [Page 49]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


   This design approach has the advantage  that  it  promotes  stateless
   decoding   of   IPDC   messages,   although   it  requires  the  IPDC
   encoder/decoder to have a broader repertoire of AVP  Codes  than  the
   alternative.    From  the  documentation  point  of  view,  its  main
   disadvantage is the extra space taken  up  in  documentation  of  AVP
   structures.   To  minimize  that  disadvantage,  IPDC  introduces the
   concept of AVP templates.   These  are  descriptions  of  frequently-
   occuring  AVP  structures  to which other IPDC protocol documentation
   may refer.  This draft defines one such template: the IPDC Reference.


5.3.1   IPDC Reference
5.3.1.1 Description

   The IPDC-Reference attribute provides a generic means of referring to
   the objects of IPDC control.  The format of the IPDC-Reference AVP is
   as follows:

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           AVP Code                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          AVP Length           |     Reserved      |P|T|V|E|H|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Entity Type Code                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Entity Name ...
   +-+-+-+-+-+-+-+-+-+-+-

   AVP Code
      Assigned in the specific  AVP  definition  which  refers  to  this
      template.

   AVP Length
      The length of this attribute MUST be at least 12.

   AVP Flags
      As per IPDC defaults.

   Entity Type Code
      The Entity Type Code field is of type Integer32 and indicates  the
      entity  type denoted by this AVP.  The following Entity Type Codes
      have been defined:

      MEDIA_GATEWAY           0
         The Media Gateway application which forms one  endpoint  of  an
         IPDC control session.



Taylor, Calhoun, Rubens   expires January 1999                 [Page 50]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


      PHYSICAL_GATEWAY                1
         A physical gateway unit.

      STATION                 2
         A degenerate case of a physical gateway  unit  serving  only  a
         single access termination.

      EQUIPMENT_HOLDER                3
         A physical container of other gateway resources such as a shelf
         or card.

      TRANSPORT_TERMINATION                4
         The physical termination at a gateway of an analogue or digital
         transmission  link  such  as  a  DS-1, either from the circuit-
         switched network or from the packet network.

      ACCESS_TERMINATION      5
         The logical termination at a gateway  of  a  bearer  connection
         (and  associated  signalling if not on a separate channel) from
         an user device.

      TRUNK_TERMINATION       6
         The logical termination at a gateway  of  a  bearer  connection
         (and associated signalling if not on a separate channel) from a
         circuit switch.

      SIGNALLING_TERMINATION             7
         The logical termination at  a  gateway  of  a  call  signalling
         channel  (e.g.  ISDN  D-channel)  from a circuit switch or user
         device.

      DEVICE                  8
         An internal physical unit of a type not  otherwise  covered  by
         this list of entity types.

      MODEM                   9
         A modem internal to a gateway.

      CONFERENCE_PORT         10
         A port on a conference bridge internal to a gateway.

      FAX_PORT                        11
         An internal endpoint capable of accepting and forwarding bearer
         content consisting of encoded facsimile.

      STREAM_SOURCE           12
         An internal source of bearer content such as an announcement or
         tone, meant to be transmitted to an user.



Taylor, Calhoun, Rubens   expires January 1999                 [Page 51]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


      STREAM_RECORDER         13
         An internal recording destination  for  bearer  content  coming
         from an user, such as a voice mailbox.

      RTP_PORT                        14
         A pair of transport addresses respectively defining the  remote
         and   local   termination   points  of  a  bi-directional  RTP-
         encapsulated media stream.   See  the  naming  rules  for  this
         entity  in  the  next  section  for  the  means  by  which uni-
         directional streams are represented.

      ATM_SPEC                        15
         An address  specification  suitable  for  establishing  an  ATM
         connection.  Details for further study.

      H323_SPEC                       16
         A call signalling transport address specification or equivalent
         such  as  an H.323 alias, suitable for establishing an outgoing
         H.323 signalling connection.

      SIP_SPEC                        17
         An  address  specification  suitable  for  establishing  a  SIP
         signalling connection.

   Entity Name
      The Entity  Name  field  is  of  type  String  and  specifies  the
      particular entity or set of entities to which the command applies.
      The next section specifies and gives examples of the possible form
      of  the  naming  string for each of the entity types listed above.
      Provision is made for wild-carding operations on a  given  set  of
      entities.    The   Entity  Name  field  MAY  be  present  for  the
      MEDIA_GATEWAY entity, but MUST be present for all other types.


5.3.1.2 Naming of IPDC Entities

Resource Names

   For all gateway resource  entity  types  (that  is,  PHYSICAL_GATEWAY
   through  STREAM_RECORDER  in the above list), naming is essentially a
   matter of local convention.  However, the entity  name  for  each  of
   these  types  is  naturally hierarchical, beginning with a term which
   identifies the physical gateway containing  the  given  resource  and
   ending  in  a term which specifies the individual resource concerned.
   With  this  in  mind,   the  following  rules  for  construction  and
   interpretation  of  the Entity Name field for these entity types MUST
   be supported:




Taylor, Calhoun, Rubens   expires January 1999                 [Page 52]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


   1.      The individual terms of the naming path MUST be separated  by
   a single slash ("/", ASCII 2F hex).

   2.      Optionally, the first term MAY be of the form:

       FORM:<formname>

   where <formname> is a string defined by local agreement which implies
   a specific form and semantic interpretation of the remaining terms of
   the  naming   path.   This   is   necessary   to   support   multiple
   representations of a single reference type.  For example, a reference
   that specifies a trunk termination may take multiple vendor dependent
   formats.   The  substring "FORM:" is reserved for this purpose at the
   start of the naming string.

   3.      Wild-carding is represented either by an asterisk ("*") or  a
   dollar  sign  ("$")  for the terms of the naming path which are to be
   wild-carded.  Thus, if the full naming path looks like

         term1/term2/term3

   then the Entity Name field looks like this depending on  which  terms
   are wild-carded:

         */term2/term3 if term1 is wild-carded
         term1/*/term3 if term2 is wild-carded
         term1/term2/* if term3 is wild-carded
         term1/*/* if term2 and term3 are wild-carded,
         etc.

   In each of these examples a dollar sign could have  appeared  instead
   of an asterisk.

   4.      A term represented by an asterisk is to  be  interpreted  as:
   "use  ALL  values  of  this  term known within the scope of the Media
   Gateway".  A term represented by a dollar sign is to  be  interpreted
   as:  "use  ANY  ONE  value of this term known within the scope of the
   Media Gateway".  The description of a specific command or AVP may add
   further criteria for selection within the general rules given here.

   5.      If the Media Gateway controls multiple physical gateways, the
   first  term  of the naming string beyond the optional FORM: term MUST
   identify the physical gateway containing the desired entity.  If  the
   Media Gateway controls only a single physical gateway, the first term
   of the naming string MAY identify that physical gateway, depending on
   local practice.





Taylor, Calhoun, Rubens   expires January 1999                 [Page 53]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


RTP Ports

   The basic format of the RTP  entity  name  consists  of  three  terms
   separated  by  slashes  ("/",  ASCII  2F hex) which together define a
   two-way RTP connection  from  the  point  of  view  of  one  physical
   endpoint.   The  first term identifies a physical gateway, the second
   is the transport address to which an RTP-encapsulated media stream is
   transmitted from that gateway, and the third is the transport address
   at which the gateway receives an RTP-encapsulated media stream.

   The first term MUST be  present  if  the  Media  Gateway  application
   controls  more than one physical gateway.  However, this term and the
   slash which  separates  it  from  the  first  transport  address  are
   optional  if  the  Media  Gateway  application controls only a single
   physical gateway.

   The two transport addresses each have the form:

         <network address> : <port number>

   The representation of each address  is  in  ASCII  text  rather  than
   binary, to facilitate the representation of uni-directional flows.

   If  one  of  the  flows  is  not  required/not  present,   the   term
   representing  that  flow  MUST  consist  of the minus ("-") character
   alone.

   Wildcarding of  the network address and/or  port  number  for  either
   term  is  permitted, using the wildcard characters and their meanings
   as defined above.  Typically the $ wild-card will be  used,  as  when
   the Media Gateway Controller leaves it up to the Media Gateway itself
   to select an available port for an RTP connection (and report it back
   to  the Media Gateway Controller).  Examples of wildcarded RTP entity
   names are shown in the next section.


Other Address Types

   The formats for representing the ATM, H323_SPEC, and  SIP_SPEC  types
   follow from already-defined standards.

   ATM

   For further study.

   H.323

   As  defined  in  ITU-T  Recommendation  H.225.0,  the  far  end  call



Taylor, Calhoun, Rubens   expires January 1999                 [Page 54]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


   signalling  address  which  an  H.323 endpoint uses to start up a new
   H.323 call can have the following forms:
      * E.164 number
      * H.323 ID - an arbitrary Unicode string (maximum 256 characters)
      * a URL (maximum 512 ASCII characters)
      * an explicit transport address
      *  an  RFC822-compliant  E-mail   address   (maximum   512   ASCII
      characters)
      * a {number type, number} structure (the  PartyNumber  structure),
      where   the   number  type  is  private  or  public  with  several
      subdivisions within each of these broad categories.

   H.323 actually allows for multiple addresses which could be  used  as
   alternatives  to  start  the  call  or  to  set  up  n  x  64  kbit/s
   connections, but these possibilities are beyond the scope of the IPDC
   Reference for the H323-SPEC entity type.

   An IPDC implementation MUST represent the above possibilities  within
   the Entity Name as follows:

   1.      An E.164  number,  a  URL,  and  an  RFC822-compliant  E-mail
   address MUST be represented in their native format, as ASCII strings.

   2.      A transport address MUST be represented in ASCII text in  the
   form:
         <network address> : <port number>

   3.      An H.323 ID MUST be  represented  according  to  the  Unicode
   specification (ISO/IEC 10646-1).

   4.      The {number type, number} structure MUST be represented by  a
   combination  of  three ASCII strings separated by slashes ("/").  The
   first two strings convey the type of number, while the third consists
   of  the  digits  of  the  actual number.  The mapping between type of
   number and the representation in the IPDC Reference is as follows:
      * the first term consists of one  of  the  two  non-case-sensitive
      keywords PUBLIC or PRIVATE, as applicable.

      * for PUBLIC numbers, the second  term  consists  of  one  of  the
      following non-case-sensitive keywords as applicable:
         -       UNKNOWN
             If used, number digits  carry  prefix  indicating  type  of
             number according to national recommendations.
         -       INTERNATIONAL
         -       NATIONAL
         -       SUBSCRIBER
         -       ABBREVIATED
             Valid only for called party number at the outgoing  access,



Taylor, Calhoun, Rubens   expires January 1999                 [Page 55]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


             switched circuit network substitutes appropriate number.

      * for PRIVATE numbers, the second term consists of  one  of  these
      non-case-sensitive keywords as applicable:
         -       UNKNOWN
         -       Level2Regional
         -       Level1Regional
         -       pISNSpecific
         -       LocalNumber
         -       AbbreviatedNumber.

   SIP-SPEC

   The contents of the Entity Name field for a SIP_SPEC  entity  consist
   of the address specification required to start up a SIP session.


5.3.1.3 Example Entity Name values for each reference type

   MEDIA_GATEWAY

      The optional entity name could be descriptive (e.g.  "OtwaNASCtl")
      or simply a serial number (e.g. "061452").

   PHYSICAL_GATEWAY

      As for the MEDIA_GATEWAY, except that  the  entity  name  MUST  be
      present  if  the  Media Gateway application controls more than one
      physical gateway.  Examples: "OtwaNAS1",  "061452-1".

   STATION

      As for the MEDIA_GATEWAY, except that  the  entity  name  MUST  be
      present  if  the  Media Gateway application controls more than one
      physical gateway/station.   It is likely that STATION naming  will
      be  numeric  because  of  the  large  potential number of stations
      within the span of control of a single Media Gateway application.

   EQUIPMENT_HOLDER

      Here the FORM: specification might come into play.   For  example,
      consider  a  card  on  a  shelf within a physical gateway bay, and
      suppose that the card terminates multiple transmission facilities.
      Then  the  card  is  an entity of type EQUIPMENT_HOLDER, as is the
      shelf which contains it.

      One natural naming scheme would identify the  shelf  and  card  as
      individual terms of the naming string:



Taylor, Calhoun, Rubens   expires January 1999                 [Page 56]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


            "OtwaNAS1/3/17",
      meaning shelf 3, card 17 in physical gateway OtwaNAS1.

      On the other hand, in accordance with the BMLC form  specification
      described below, the same entity might be named
            "FORM:BMLC/OtwaNAS1/3-17",
      since the "M" part of "BMLC" allows for one EQUIPMENT_HOLDER  term
      only.

      In both of the examples, the  gateway  identifier  term  could  be
      absent  if  the  Media Gateway controls only one physical gateway.
      The examples then become:
            "3/17"
      and
            "FORM:BMLC/3-17"
      respectively.

      Finally, individual terms MAY be wild-carded.  For example,  using
      the first naming convention, one could refer to all cards on shelf
      3 using the Entity Name
            "3/*"
      with the EQUIPMENT_HOLDER type.  In the BMLC  form,  this  is  not
      possible,  but one could refer to all EQUIPMENT_HOLDER entities in
      the physical gateway using the string
            "FORM:BMLC/*"
      with the EQUIPMENT_HOLDER type.

   TRANSPORT_TERMINATION

      The naming of an entity of type Transport-Termination is a natural
      extension  of  the  naming  of  the  EQUIPMENT_HOLDER entity which
      supports it.  Using the above example, DS-1 port 1 on card  17  of
      shelf 3 could have the following names:
            "OtwaNAS1/3/17/1"
            "3/17/1"

      The BMLC form convention has an explicit term (the "L"  part)  for
      the  transmission  facility  name, so, using the previous example,
      the same facility could have the names:
            "FORM:BMLC/OtwaNAS1/3-17/1"
            "FORM:BMLC/3-17/1"

      Again, wild-carding is possible.  For  example,  the  Entity  Name
      values
            "OtwaNAS1/*/*/*"
      or
            "*/*/*/*"
      in the first instance, or



Taylor, Calhoun, Rubens   expires January 1999                 [Page 57]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


            "FORM:BMLC/OtwaNAS1/*/*"
      or
            "FORM:BMLC/*/*"
      in the second instance refer along with the  TRANSPORT_TERMINATION
      type code to all transmission terminations on the gateway.

   ACCESS_TERMINATION

      The ACCESS_TERMINATION name  will  be  similar  to  that  for  the
      TRANSPORT_TERMINATION.

   TRUNK_TERMINATION

      The TRUNK_TERMINATION entity type specifies a single GSTN  channel
      or  a  grouping  of  GSTN  channels.   Depending  upon the type of
      circuit that is  connected  into  the  gateway  and  the  physical
      architecture  of  the  gateway,  this  entity type might have many
      vendor defined representations.  To provide  one  possibility  for
      common  use,  this  draft suggests the "BMLC" format specification
      for trunk identification.   The  general  form  of  a  BMLC  trunk
      identifier is given by:

            FORM:BMLC/[<Bay    identifier>]/<Module    identifier>/<Line
            identifier>/<Channel identifier>

      Within this format, the FORM: part of the reference specifies  the
      "BMLC"  format.  This form type indicates that the channels within
      a media gateway may be identified using a  hierarchical  structure
      of  bay,  module,  line  and  channel. This hierarchical structure
      defines the following components:

         * "channel" is a single GSTN channel. In most trunk types  this
         refers to a 64kb channel.

         * "line" identifies the TRANSPORT_TERMINATION  over  which  the
         channel  is  being  delivered. In most pieces of equipment this
         will represent the physical interface that terminates a  T1  or
         T3.

         * "module" identifies a logical grouping of lines, an entity of
         type  EQUIPMENT_HOLDER.   In  some pieces of equipment this may
         represent a circuit board that is plugged  into  the  backplane
         and  terminates  multiple  physical interfaces. In other pieces
         of equipment it may represent a shelf of line cards.

         *  "bay"  identifies  the  physical  gateway  that   is   being
         controlled  by  the  control channel over which this message is
         being transmitted.  The PHYSICAL_GATEWAY term MUST  be  omitted



Taylor, Calhoun, Rubens   expires January 1999                 [Page 58]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


         if  the  Media  Gateway  application controls only one physical
         gateway.

      Example uses of the  trunk-term  reference  type  using  the  BMLC
      format would be:

            "FORM:BMLC/module2/line4/channel21"
            "FORM:BMLC/2/4/21"
            "FORM:BMLC/2/4/$", indicating any one channel on  module  2,
            line 4
            "FORM:BMLC/2/*/*", indicating all channels on all facilities
            supported by module 2
            "FORM:BMLC/*/*/*", indicating all channels on the gateway
            "FORM:BMLC/OtwaNAS01/*/*/*", indicating all channels on  the
            specific physical gateway OtwaNAS01, where the Media Gateway
            handles more than one physical gateway.

   SIGNALLING_TERMINATION

      Naming of a SIGNALLING_TERMINATION entity is similar to that for a
      TRUNK_TERMINATION.

   DEVICE
   MODEM
   CONFERENCE_PORT
   FAX_PORT
   STREAM_SOURCE
   STREAM_RECORDER

      Naming conventions for these entities may be similar to those  for
      the  TRANSPORT_TERMINATION, or may omit the EQUIPMENT_HOLDER term.
      Examples of such conventions:

            [<gateway name> /] <Modem group> / <Modem number>

      e.g " OtwaNAS01/21/6" for modem group 21, unit 6 on OtwaNAS01.

            [<gateway name> /] <Conference bridge> / <Conference port>

      e.g. "4/$" refers to any one  port  on  bridge  4  on  the  single
      physical gateway handled by the Media Gateway application.

            [<gateway name> /] <Announcement name>

      e.g. "AnnSrv1/MailPrompt" refers to the MailPrompt announcement on
      Announcement  Server AnnSrv1, which is a physical gateway from the
      point of view of the IPDC control session.




Taylor, Calhoun, Rubens   expires January 1999                 [Page 59]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


   RTP_PORT

      Examples of RTP_PORT entity names would be:

         "OtwaVGW01/134.37.42.2:3003/134.37.32.5:3006"
      which denotes  a  bi-directional  media  stream  transmitted  from
      physical   gateway   OtwaVGW01   to   port  134.37.42.2:3003,  and
      transmitted  from  the  far  end  to  port   134.37.32.5:3006   on
      OtwaVGW01.

         "134.37.42.2:3003/134.37.32.5:$"
      which demonstrates wildcarding of the port number for the incoming
      media stream.

         "134.37.42.2:3003/-"
      which denotes a one-way outgoing media stream.

   ATM_SPEC

      For further study.

   H323_SPEC

      Examples of H323_SPEC entity names would be:

         "134.37.42.2:"
      which denotes the well-known call signalling port for H.323 at the
      given remote address.

         "Tom Taylor"
      which denotes an H.323 alias

         "16137654167"
      which denotes an E.164 address.

   SIP_SPEC

      Examples to come.



6.0     Protocol Definition

   This section will describe how the base  protocol  works  (or  is  at
   least an attempt to do so).

6.1     DIAMETER Bootstrap Message




Taylor, Calhoun, Rubens   expires January 1999                 [Page 60]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


   DIAMETER provides a message  that  is  used  to  indicate  either  an
   imminent  reboot, or that a reboot has occurred. The DRI message MUST
   be sent to all known DIAMETER peers both previous to  a  reboot  when
   possible as well as following a reboot.

   The Reboot-Type AVP is used to indicate the type of reboot associated
   with the DRI. When set to REBOOT_IMMINENT, all peers should be warned
   that any new DIAMETER requests sent to the issuer will  probably  not
   be  received  or  processed.  If  a  request MUST be sent it would be
   preferable to issue the request to an alternate  peer  if  available.
   The  message  includes  an optional Reboot-Time AVP that specifies an
   estimate of how long before the issuer is available  to  receive  new
   DIAMETER messages.

   Upon reboot, the host MUST issue a DRI message with  the  Reboot-Type
   AVP set to REBOOTED. This is an indication that new DIAMETER messages
   may be sent to the transmitter of the DRI.

   Note that the Reboot-Time AVP  is  not  required,  and  when  present
   provides  an  estimate and should not be used as a hard value. In the
   case of a software  implementation  (server)  running  on  a  general
   purpose  operating  system,  the Reboot-Time AVP will probably not be
   present since it is  possible  that  the  DIAMETER  server  has  been
   stopped  and  it  is not possible to know how long before (and if) it
   will be restarted.

   The DIAMETER Reboot-Ind message does not require a reply. The message
   is acknowledged using DIAMETER's reliable transport.


6.2  Keepalive Exchange

   DIAMETER  uses  the  Device-Watchdog-Ind  message  as   a   keepalive
   mechanism.  DIAMETER  entities  that need to ensure that connectivity
   with a peer is not lost MAY use this mechanism.

   An IPDC/DIAMETER  Client  can  use  this  mechanism  to  ensure  that
   failover  to  an  alternate  server  occurs  even without any control
   traffic. Redundant DIAMETER Servers use this  mechanism  to  identify
   when the primary server is no longer available.

   The DIAMETER Device-Watchdog-Ind message does not  require  a  reply.
   The message is acknowledged using DIAMETER's reliable transport.


6.3  Unrecognized Command Support

   The DIAMETER protocol provides a message that is  used  to  inform  a



Taylor, Calhoun, Rubens   expires January 1999                 [Page 61]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


   peer  that  a  DIAMETER  message  was  received  with an unrecognized
   command. Suppose the following message is sent to a peer:

      <Take-A-Hike-Req> ::= <DIAMETER Header>
                            <Take-A-Hike-Req Command AVP>
                            <Host-IP-Address AVP>
                            [<Host-Name AVP>]
                            <Timestamp AVP>
                            <Initialization-Vector AVP>
                            {<Integrity-Check-Vector AVP> ||
                             <Digital-Signature AVP }

   Upon receipt of the above message, the receiver notices that it  does
   not  support  the command.  A non-IPDC application will then send the
   following message:

      <Unrecognized-Command-Ind> ::= <DIAMETER Header>
                                  <Unrecognized-Command-Ind Command AVP>
                                  <Unrecognized-Command-Code AVP>
                                  <Host-IP-Address AVP>
                                  [<Host-Name AVP>]
                                  <Timestamp AVP>
                                  <Initialization-Vector AVP>
                                  {<Integrity-Check-Vector AVP> ||
                                   <Digital-Signature AVP }

   An IPDC application will instead send the response:

            <Message-Reject> ::= <DIAMETER Header>
                                  <Message-Reject Command AVP>
                                  <Unrecognized-Command-Code AVP>
                                  <Transaction-Originator AVP>
                                  <Result-Code AVP>
                                  <Unrecognized-Command-Code AVP>
                                  <Timestamp AVP>
                                  <Initialization-Vector AVP>
                                  {<Integrity-Check-Vector AVP> ||
                                   <Digital-Signature AVP }

   where  the  Result-Code  AVP  contains  the  Result  Code  value   6,
   IPDC_COMMAND_UNSUPPORTED.


6.4  The art of AVP Tagging

   The AVP Header provides the 'T' bit which is used for  grouping  AVPs
   together.  Although  the  base protocol does not define any AVPs that
   need to be grouped, it is envisioned that  DIAMETER  extensions  will



Taylor, Calhoun, Rubens   expires January 1999                 [Page 62]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


   require tag support.

   In the case where multiple AVPs are needed  to  indicate  a  specific
   authorization "rule" tagging is appropriate. Such an example is taken
   from [14] that discusses Tunneling attributes. In this case  multiple
   AVPs are required in order to specify tunnel parameter, and more than
   one set of AVPs MAY be present in the message. This is  necessary  in
   order to support redundant tunnel servers.

   In this case, the AVPs that need to be grouped together would have  a
   specific tag value, and each group would use a different tag value.


6.5  Device Configuration

   DIAMETER provides two messages that can be used by DIAMETER peers  in
   order   to   exchange  certain  configuration  information,  such  as
   retransmission timer values. This message MAY be sent at any time and
   is not restricted to being sent at boot-up time only.

   Upon receipt of the Device-Config-Request, the receiver  SHOULD  make
   use of the configuration information provided when communicating with
   the initiator of the message.

   The receiver MUST acknowledge receipt of the message with  a  Device-
   Config-Answer  which may also contain some configuration information.
   Note that if such configuration  AVPs  are  present  in  the  Device-
   Config-Answer  the  peer  cannot  reply  with  a  success  or failure
   Result-Code.

   A preferable  method  for  two  nodes  to  "negotiate"  configuration
   information  would  be  for  both  of  them  to  issue Device-Config-
   Requests. However in some applications minimizing  packets  over  the
   wire  at  startup  time  requires that the Device-Config-Answer carry
   such information.

   Note that both messages have a high probability of containing  vendor
   specific  AVP  which MAY be ignored. Implementations MUST assume that
   that receiver does NOT support vendor specific AVPs sent.


6.6     Data Integrity

   This section will describe how data integrity is achieved  using  the
   Data  Integrity  AVPs.   Note  that the Timestamp and Initialization-
   Vector AVPs MUST be present in the message PRIOR to any of  the  Data
   Integrity  AVPs discussed in this section. The Timestamp AVP provides
   replay  protection  and  the   Initialization-Vector   AVP   provides



Taylor, Calhoun, Rubens   expires January 1999                 [Page 63]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


   randomness.


6.6.1   Using the Integrity-Check-Vector

   The use of the  Integrity-Check-Vector  (ICV)  AVP  requires  a  pre-
   configured  shared  secret. Although this mechanism does not scale as
   well as the Digital Signature,  it  may  be  desirable  to  use  this
   mechanism  in the case where asymmetric technology is not required or
   available.

   Note that in the case where two DIAMETER nodes  need  to  communicate
   through  an intermediate node (i.e. Proxy) it does not offer any end-
   to-end data integrity or encryption as each node must re-compute  the
   Integrity-Check-Vector AVP.

   The Data field of the AVP contains an HMAC-MD5-96 hash  [11]  of  the
   message  up  to the ICV AVP. Using the example code provided in [11],
   the following call would be used  to  generate  the  Integrity-Check-
   Vector:

         hmac_md5(DIAMETERMessage, MessageLength, Secret, Secretlength,
         Output)

   The following is an example of a  message  that  includes  hop-by-hop
   security:

      <DIAMETER Message> ::= <DIAMETER Header>
                              <Command AVP>
                              [<Additional AVPs>]
                              <Timestamp AVP>
                              <Initialization-Vector AVP>
                              <Integrity-Check-Vector AVP>


6.6.2   Using Digital Signatures

   In the case of a simple peer to peer relationship the use of IPSEC is
   sufficient for data integrity and non-repudiation. However, there are
   instances where a peer must communicate with another peer through the
   use  of a proxy server. IPSEC does not provide a mechanism to protect
   traffic when two peers must use an intermediary node  to  communicate
   at the application layer, therefore the Digital-Signature AVP MUST be
   used.

   The following diagram shows an  example  of  a  router  initiating  a
   DIAMETER  message  to  DIA1.  Once  DIA1  has finished processing the
   message it adds its signature and forwards the message  to  the  non-



Taylor, Calhoun, Rubens   expires January 1999                 [Page 64]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


   trusted DIA2 proxy server. If DIA2 needs to add or change any mutable
   AVPs it SHOULD  add  its  digital  signature  before  forwarding  the
   message to DIA3.

      +------+  ----->  +------+  ----->  +------+  ----->  +------+
      |      |          |      |          | non- |          |      |
      |router+----------+ DIA1 +----------+trustd+----------+ DIA3 |
      |      |          |      |          | DIA2 |          |      |
      +------+  <-----  +------+  <-----  +------+  <-----  +------+

   Since some fields within the DIAMETER header will change  "en  route"
   towards  the  final  DIAMETER destination, it is necessary to set the
   mutable fields to zero (0) for purposes of calculating the signature.
   The  two  mutable  fields  are  the  identifier and the length in the
   DIAMETER header.

   The following is an example of a  message  that  includes  end-to-end
   security:

      <DIAMETER Message> ::= <DIAMETER Header>
                              <Command AVP>
                              [<Additional AVPs>]
                              <Timestamp AVP>
                              <Initialization-Vector AVP>
                              <Digital-Signature AVP>

   Note that Digital Signatures only protect the DIAMETER header and the
   AVPs  found  prior to the digital signature. It is therefore possible
   to have AVPs which are unprotected because they  follow  the  digital
   signature.

   The Data field of the  Digital-Signature  AVP  contains  the  RSA/MD5
   signature algorithm as defined in [13].


6.6.3   Using Mixed Data Integrity AVPs

   The previous sections described the  Integrity-Check-Vector  and  the
   Digital-Signature  AVP. Since the ICV offers hop-by-hop integrity and
   the digital signature offers end to end integrity, it is possible  to
   use both AVPs within a single DIAMETER message.

   The following diagram provides an example  where  DIAMETER  Server  1
   (DIA1)  communicates with DIA3 using Digital-Signatures through DIA2.
   In this example ICVs are used  between  DIA1  and  DIA2  as  well  as
   between DIA2 and DIA3.

         <Public-Key>



Taylor, Calhoun, Rubens   expires January 1999                 [Page 65]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


      ----------------------------->
      <Shared-Secret>   <Shared-Secret>
      +------+  ----->  +------+  ----->  +------+
      |      |          |      |          |      |
      | DIA1 +----------+ DIA2 +----------+ DIA3 |
      |      |          |      |          |      |
      +------+          +------+          +------+

   Using the previous diagram,  the  following  message  would  be  sent
   between DIA1 and DIA2:

      <DIAMETER Message> ::= <DIAMETER Header>
                              <Command AVP>
                              [<Additional AVPs>]
                              <Timestamp AVP>
                              <Initialization-Vector AVP>
                              <Digital-Signature AVP>
                              <Integrity-Check-Vector AVP (DIA1->DIA2)>

   The following message would be sent between DIA2 and DIA3:

      <DIAMETER Message> ::= <DIAMETER Header>
                              <Command AVP>
                              [<Additional AVPs>]
                              <Timestamp AVP>
                              <Initialization-Vector AVP>
                              <Digital-Signature AVP>
                              <Timestamp AVP>
                              <Initialization-Vector AVP>
                              <Integrity-Check-Vector AVP (DIA2->DIA3)>

   Note that in the above example messages the ICV AVP appears after the
   Digital-Signature AVP. This is necessary since DIA2 above removes the
   ICV AVP (DIA1->DIA2) and adds its own ICV AVP (DIA2->DIA3). The  ICVs
   provide  hop-by-hop  security  while  the  Digital-Signature provides
   integrity of the message between DIA1 and DIA3.

            <Shared-Secret>    <Public-Key>

      +------+  ----->  +------+  ----->  +------+
      |      |          |      |          |      |
      |router+----------+ DIA1 +----------+ DIA2 |
      |      |          |      |          |      |
      +------+  <-----  +------+  <-----  +------+

   There  are  cases,  such  as  in  remote  access,  where  the  device
   initiating the DIAMETER request does not have the processing power to
   generate Digital-Signatures as required by the protocol.  In such  an



Taylor, Calhoun, Rubens   expires January 1999                 [Page 66]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


   arrangement, there normally exists a first hop DIAMETER Server (DIA1)
   which  acts  as  a  proxy  to  relay  the  request   to   the   final
   authenticating DIAMETER server (DIA2).  It is valid for the first hop
   server to remove  the  Integrity-Check-Vector  AVP  inserted  by  the
   router and replace it with a Digital-Signature AVP.


6.7     AVP Data Encryption

   DIAMETER supports two methods of encrypting AVP data. One is using  a
   shared  secret  and the other is used with public keys.  This feature
   can be  used  to  encrypt  sensitive  data  such  as  user  ID's  and
   passwords. The Encryption bits MUST NOT be set in the Command Type or
   Initialization-Vector AVPs.


6.7.1   AVP Encryption with Shared Secrets

   This method of encrypting AVP data is the simplest to use and MUST be
   supported  by all DIAMETER implementations. However, local policy MAY
   determine that the use of this mechanism is not permitted.

   The SS-Encrypted-Data bit MUST only be set if a shared secret  exists
   between  both  DIAMETER peers. If the SS-Encrypted-Data bit is set in
   any DIAMETER AVP, the Initialization-Vector AVP MUST be present prior
   to the first encrypted AVP.

   The length of the AVP value to be encrypted is first encoded  in  the
   following Subformat:

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Length of ClearText Data    |       ClearText Data ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Padding ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length
      The Length field contains the length of the decrypted data.

   ClearText Data
      Data of AVP that is to be obscured.

   Padding
      Random additional octets used to obscure length of  the  ClearText
      Data.




Taylor, Calhoun, Rubens   expires January 1999                 [Page 67]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


   The resulting subformat MAY be padded to a multiple of 16  octets  in
   length. For example, if the ClearText Data to be obscured is a string
   containing 6 characters (e.g. password 'foobar'), then 8  +  n  *  16
   octets  of padding would be applied. Padding does NOT alter the value
   placed in the Length of the ClearText Data, only the  length  of  the
   AVP itself.

   Next, An MD5 hash is performed on the concatenation of:
         * the two octet Command Code of the AVP
         * the shared authentication secret
         * an arbitrary length random vector.

   The value of the random vector used in this hash  is  passed  in  the
   Data  field  of  a  Initialization-Vector  AVP.  This Initialization-
   Vector AVP MUST be placed in the message by  the  sender  before  any
   hidden AVPs. The same Initialization-Vector may be used for more than
   one hidden AVP in the same message.  If a  different  Initialization-
   Vector  is  used  for  the  hiding  of  subsequent  AVPs  then  a new
   Initialization-Vector AVP MUST be placed  before  the  first  AVP  to
   which it applies.

   The MD5 hash value is then XORed with the  first  16  octet  or  less
   segment of the AVP Subformat and placed in the Data field of the AVP.
   If the AVP Subformat  is  less  than  16  octets,  the  Subformat  is
   transformed as if the Value field had been padded to 16 octets before
   the XOR, but only the actual octets  present  in  the  Subformat  are
   modified, and the length of the AVP is not altered.

   If the Subformat is longer than 16 octets, a second one-way MD5  hash
   is calculated over a stream of octets consisting of the shared secret
   followed by the result of the first XOR.  That hash is XORed with the
   second  16  octet  or less segment of the Subformat and placed in the
   corresponding octets of the Data field of the AVP.

   If necessary, this operation is repeated, with each XOR result  being
   used  along  with  the shared secret to generate the next hash to XOR
   the next segment of the value with.  This technique  results  in  the
   content  of the AVP being obscured, although the length of the AVP is
   still known.

   On  receipt,  the  Initialization-Vector  is  taken  from  the   last
   Initialization-Vector AVP encountered in the message prior to the AVP
   to be decrypted. The above process is  then  reversed  to  yield  the
   original  value.   For  more  details  on this hiding method, consult
   RFC2138 [14].

   Please note that in the case where the DIAMETER message needs  to  be
   processed  by an intermediate non-trusted DIAMETER server (also known



Taylor, Calhoun, Rubens   expires January 1999                 [Page 68]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


   as a proxy server, depicted as DIA2 in  the  figure  below)  the  AVP
   needs  to be decrypted using Shared-Secret-1 and re-encrypted by DIA2
   using Shared-Secret-2.

               (Shared-Secret-1)          (Shared-Secret-2)
      +------+       ----->      +------+      ------>      +------+
      |      |                   |      |                   |      |
      | DIA1 +-------------------+ DIA2 +-------------------+ DIA3 |
      |      |                   |      |                   |      |
      +------+                   +------+                   +------+

   Unfortunately in this case the non-trusted server DIA2 has access  to
   sensitive information (such as a password).


6.7.2   AVP Encryption with Public Keys

   AVP encryption using public  keys  is  much  more  complex  than  the
   previously  decribed  method,  yet it is desirable to use it in cases
   where  the  DIAMETER  message  will  be  processed  by  an  untrusted
   intermediate node (proxy).

   Public Key encryption SHOULD be supported, however it is  permissible
   or a low powered device initiating the DIAMETER message to use shared
   secret encryption with the first hop (proxy) DIAMETER  server,  which
   would decrypt and encrypt using the Public Key method.

   The PK-Encrypted-Data bit MUST only be set if the final DIAMETER host
   is  aware of the sender's public key. This information can be relayed
   in three different methods as described in section 6.8.

   The AVP is encrypted in the method described in [13].


6.8     Public Key Cryptography Support

   A DIAMETER peer's public key is  required  in  order  to  validate  a
   message which includes the the Digital-Signature AVP. There are three
   possibilities on retrieving public keys: transmission  of  the  X.509
   certificate itself,transmission of a URL pointing to the actual X.509
   certificate,   and   static   public   key   configuration.     These
   possibilities are discussed in the next two sections.


6.8.1   X509-Certificate

   A message which includes a Digital-Signature MAY  include  the  X509-
   Certificate  AVP.  Given  the  size of a typical certificate, this is



Taylor, Calhoun, Rubens   expires January 1999                 [Page 69]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


   very wasteful and in most  cases  DIAMETER  peers  would  cache  such
   information in order to minimize per packet processing overhead.

   It is however valid for a DIAMETER host to  provide  a  message  that
   includes  the  X509-Certificate-URL  to  provide  a  pointer  to  its
   certificate.  Upon receiving such  a  message  a  DIAMETER  host  MAY
   choose  to  retrieve  the certificate if it is not locally cached. Of
   course the process of retrieving  and  validating  a  certificate  is
   lengthy  and  will require the initiator of the message to retransmit
   the request. However once cached the certificate can be used until it
   expires.


6.8.2   Static Public Key Configuration

   Given that using certificates requires a PKI infrastructure which  is
   very  costly,  it  is also possible to use this technology by locally
   configuring DIAMETER peers' public keys.   Note  that  in  a  network
   involving many DIAMETER proxies this may not scale well.


7.0     References

   [1]     Cuervo et alia, "SS7-Internet  Interworking  -  Architectural
   Framework", draft-greene-ss7-arch-frame-00.txt, July 1998.

   [2]     Calhoun, Rubens,  "DIAMETER  Base  Protocol",  draft-calhoun-
   diameter-04.txt, July 1998.

   [3]      Skran,  "IPDC  Architectural  Framework",  draft-skran-IPDC-
   frame-00.txt, August 1998.

   [4]      Dugan,  "IPDC  Connection  Control",  draft-dugan-IPDC-conn-
   00.txt, August 1998.

   [5]      Elliott,  "IPDC  Media  Control",  draft-elliott-IPDC-media-
   00.txt, August 1998.

   [6]     Bell, "IPDC Signaling  Support",  draft-bell-IPDC-sig-00.txt,
   August 1998.

   [7]     Pickett, "IPDC Device  Management",  draft-pickett-IPDC-mgmt-
   00.txt, August 1998.

   [8]     Reynolds, Postel, "Assigned Numbers", RFC 1700, October 1995.

   [9]     Rivest, Dusse, "The MD5 Message-Digest Algorithm", RFC  1321,
   April 1992.



Taylor, Calhoun, Rubens   expires January 1999                 [Page 70]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


   [10]  Kaufman,  Perlman,   Speciner,   "Network   Security:   Private
   Communications  in  a  Public World", Prentice Hall, March 1995, ISBN
   0-13-061466-1.

   [11] Krawczyk, Bellare, Canetti,  "HMAC:  Keyed-Hashing  for  Message
   Authentication", RFC 2104, January 1997.

   [12] Aboba, Beadles, "Network  Address  Identifier",  Internet-Draft,
   draft-ietf-roamops-nai-11.txt, July 1998.

   [13] Kaliski, "PKCS #1: RSA Encryption Version 1.5", RFC 2313,  March
   1998.

   [14] Rigney, et alia, "RADIUS", RFC 2138, April 1997

   [15]  Calhoun,  Zorn,  Pan,  "DIAMETER  Framework",   Internet-Draft,
   draft-calhoun-DIAMETER-framework-00.txt, May 1998



8.0     Rights and Permissions

   The contributors to this document are listed in  the  acknowledgement
   section  of this document.  All contributors to this document and the
   organizations  we  represent  grant  an  unlimited  perpetual,   non-
   exclusive,  royalty-free,  world-wide  right and license to any party
   under the copyrights in the contribution.  This license includes  the
   right  to  copy,  publish and distribute the contribution in any way,
   and to prepare derivative works that are based on or incorporate  all
   or  part of the contribution, the license to such derivative works to
   be of the same scope as the license  of  the  original  contribution.
   The  contributors  grant  permission  to  reference  the names of the
   contributors and of the organizations we represent. We agree that  no
   information  in  the  contribution  is  confidential and that the any
   party may freely disclose any information in the contribution.

   The contributors to this document represent that the organizations we
   represent  jointly own any intellectual property associated with this
   document.  The contributors to this document will grant any  party  a
   perpetual,   non-exclusive,   royalty-free,   world-wide   right   to
   implement,  use  and  distribute  the  technology   or   works   when
   implementing,   using  or  distributing  technology  based  upon  the
   specific specification.

   The contributors represent that we have disclosed  the  existence  of
   any  proprietary  or intellectual property rights in the contribution
   that are reasonably and personally known to  the  contributors.   The
   contributors  do  not  represent  that  we  personally  know  of  all



Taylor, Calhoun, Rubens   expires January 1999                 [Page 71]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


   potentially pertinent proprietary and  intellectual  property  rights
   owned  or claimed by the organizations we represent (if any) or third
   parties.

   The  contributors  represent  that  there  are  no  limits   to   the
   contributors'   ability  to  make  the  grants,  acknowledgments  and
   agreements above that are reasonably  and  personally  known  to  the
   contributors.


9.0     Acknowledgements

   The DIAMETER base protocol specification  [2]  was  authored  by  Pat
   Calhoun  of  Sun  Microsystems,  Inc.  and  Allan C. Rubens of Ascend
   Communications.  [2] acknowledges  the  following  people  for  their
   contribution in the development of the DIAMETER protocol:
      Bernard Aboba, Jari Arkko, William  Bulley,  Daniel  C.  Fox,  Lol
      Grant,  Nancy  Greene,  Peter  Heitman, Ryan Moats, Victor Muslin,
      Kenneth Peirce, Sumit Vakil, John R. Vollbrecht, Jeff Weisberg and
      Glen Zorn.

   [2] also acknowledges a  major  debt  to  L2TP  for  details  of  the
   DIAMETER protocol.

   The following people contributed  to  the  development  of  the  IPDC
   proposal   and   are   signatories   to   the  declaration  regarding
   intellectual property rights in the previous section:

      Ilya  Akramovich, Bob Bell, Dan Brendes, Peter Chung, John  Clark,
      Russ  Dehlinger,  Andrew  Dugan, Ike Elliott, Cary Fitzgerald, Jan
      Gronski, Tom Hess, Geoff  Jordan,  Tony  Lam,  Shawn  Lewis,  Dave
      Mazik, Alan Mikhak, Pete O'Connell, Scott Pickett, Shyamal Prasad,
      Eric Presworsky, Paul Richards, Dale Skran, Louise Spergel,  David
      Sprague, Raj Srinivasan, Tom Taylor, and Michael Thomas.

   Special acknowledgement is due to Ike Elliott for the long  hours  he
   spent   moderating  the  meetings  of  the  IPDC  Technical  Advisory
   Committee.


10.0    Authors' Addresses


      Questions about this memo can be directed to:

         P. Tom Taylor
         Nortel (Northern Telecom)
         M/S 097, SKY,



Taylor, Calhoun, Rubens   expires January 1999                 [Page 72]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


         P.O. Box 3511, Station C,
         Ottawa, Ontario,
         Canada

          Phone:  1-613-765-4167
            Fax:  1-613-765-7236
         E-mail:  taylor@nortel.ca


         Pat R. Calhoun
         Technology Development
         Sun Microsystems, Inc.
         15 Network Circle
         Menlo Park, California, 94025
         USA

          Phone:  1-650-786-7733
            Fax:  1-650-786-6445
         E-mail:  pcalhoun@eng.sun.com


         Allan C. Rubens
         Ascend Communications
         1678 Broadway
         Ann Arbor, MI 48105-1812
         USA

          Phone:  1-734-761-6025
         E-Mail:  acr@del.com


Appendix A: Acknowledgment Timeouts

   DIAMETER uses sliding windows and timeouts  to  provide  flow-control
   across  the underlying medium and to perform efficient data buffering
   to keep two DIAMETER  peers'  receive  window  full  without  causing
   receive  buffer overflow. DIAMETER requires that a timeout be used to
   recover from dropped messages.

   When the timeout for  a  peer  expires,  the  previously  transmitted
   message  with  Ns  value equal to the highest in-sequence value of Nr
   received from the peer is retransmitted. The receiving peer does  not
   advance its value for the receive sequence number state, Sr, until it
   receives a message with Ns equal to its current value of Sr.

   This rule assues that all subsequent acknowledgements  to  this  peer
   will  contain  an Nr value equal to the Ns value of the first missing
   message until a message with the missing Ns value is received.



Taylor, Calhoun, Rubens   expires January 1999                 [Page 73]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


   The exact implementation of the  acknowledgment  timeout  is  vendor-
   specific.   It  is  suggested that an adaptive timeout be implemented
   with backoff for flow control.  The timeout mechanism  proposed  here
   has the following properties:

      * Independent timeouts for each  peer.   A  device  will  have  to
      maintain and calculate timeouts for every active peer.

      * An administrator-adjustable maximum timeout, MaxTimeOut,  unique
      to each device.

      * An adaptive timeout  mechanism  that  compensates  for  changing
      throughput.   To  reduce  packet  processing overhead, vendors may
      choose not to recompute the adaptive timeout  for  every  received
      acknowledgment.  The result of this overhead reduction is that the
      timeout will not respond as quickly to rapid network changes.

      * Timer backoff on timeout to reduce congestion.   The  backed-off
      timer  value is limited by the configurable maximum timeout value.
      Timer backoff is done every time an acknowledgment timeout occurs.

   In general, this mechanism has  the  desirable  behavior  of  quickly
   backing off upon a timeout and of slowly decreasing the timeout value
   as packets are delivered without timeouts.


A.1  Calculating Adaptive Acknowledgment Timeout

   We still must decide how much time to allow  for  acknowledgments  to
   return.  If the timeout is set too high, we may wait an unnecessarily
   long time for dropped packets.  If the timeout is too short,  we  may
   time  out just before the acknowledgment arrives.  The acknowledgment
   timeout should also be reasonable and responsive to changing  network
   conditions.

   The suggested adaptive algorithm detailed below is based on  the  TCP
   1989  implementation and is explained in Richard Steven's book TCP/IP
   Illustrated, Volume 1 (page 300).  'n' means this  iteration  of  the
   calculation, and 'n-1' refers to values from the last calculation.

         DIFF[n] = SAMPLE[n] - RTT[n-1] DEV[n]
                 = DEV[n-1] + (beta * (|DIFF[n]| - DEV[n-1])) RTT[n]
                 = RTT[n-1] + (alpha * DIFF[n]) ATO[n]
                 = MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut)

   DIFF represents the error between the last estimated round-trip  time
   and the measured time.  DIFF is calculated on each iteration.




Taylor, Calhoun, Rubens   expires January 1999                 [Page 74]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


   DEV is the estimated mean deviation.  This approximates the  standard
   deviation.  DEV is calculated on each iteration and stored for use in
   the next iteration.  Initially, it is set to 0.

   RTT is the estimated round-trip time of an average  packet.   RTT  is
   calculated  on  each  iteration  and  stored  for  use  in  the  next
   iteration.  Initially, it is set to PPD.

   ATO is the adaptive timeout for the next transmitted packet.  ATO  is
   calculated  on  each  iteration.   Its  value  is limited, by the MIN
   function, to be a maximum of the configured MaxTimeOut value.

   Alpha is the gain for the round trip estimate error and is  typically
   1/8 (0.125).

   Beta is the gain for the deviation and is typically 1/4 (0.250).

   Chi is the gain for the timeout and is typically set to 4.

   To eliminate division operations for fractional  gain  elements,  the
   entire  set  of  equations  can  be  scaled.  With the suggested gain
   constants, they should be scaled by 8 to eliminate all division.   To
   simplify  calculations,  all gain values are kept to powers of two so
   that shift operations can be  used  in  place  of  multiplication  or
   division.

   The above calculations are carried out each time an acknowledgment is
   received for a packet that was not retransmitted (no timeout occurs).


A.2 Flow Control: Adjusting for Timeout

   This section describes how the calculation of ATO is modified in  the
   case  where a timeout does occur.  When a timeout occurs, the timeout
   value should be adjusted rapidly upward.  Although DIAMETER  messages
   are  not  retransmitted  when a timeout occurs, the timeout should be
   adjusted up toward a  maximum  limit.   To  compensate  for  shifting
   internetwork time delays, a strategy must be employed to increase the
   timeout when it expires.  A simple formula called Karn's Algorithm is
   used  in  TCP  implementations  and  may  be used in implementing the
   backoff timers for the LNS or the LAC.  Notice that  in  addition  to
   increasing  the  timeout,  we  also  shrink the size of the window as
   described in the next section.  Karn's timer  backoff  algorithm,  as
   used in TCP, is:

         NewTIMEOUT = delta * TIMEOUT

   Adapted to our timeout calculations,  for  an  interval  in  which  a



Taylor, Calhoun, Rubens   expires January 1999                 [Page 75]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


   timeout occurs, the new timeout interval ATO is calculated as:

         RTT[n] = delta * RTT[n-1] DEV[n]
                = DEV[n-1] ATO[n]
                = MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut)

   In this modified  calculation  of  ATO,  only  the  two  values  that
   contribute  to  ATO  and  that  are stored for the next iteration are
   calculated.  RTT is scaled by delta, and DEV is unmodified.  DIFF  is
   not  carried  forward and is not used in this scenario.  A value of 2
   for Delta, the timeout gain factor for RTT, is suggested.



Appendix B: Examples of sequence numbering

   Although sequence numbers serve distinct  purposes  for  control  and
   data  messages,  both  types of messages use identical techniques for
   assigning sequence  numbers.   This  appendix  shows  several  common
   scenarios,  and  illustrates how sequence number state progresses and
   is interpreted.


B.1: Lock-step session establishment

   In this example, a DIAMETER device establishes communication  with  a
   peer,  with  the  exchange involving each side alternating in sending
   messages.   This  example   is   contrived,   in   that   the   final
   acknowledgement in the example is typically the acknowledgement which
   would have been included in the processing  of  the  Device-Watchdog-
   Ind.

        DIAMETER Host A                             DIAMETER Host B
             ->    Device-Reboot-Ind
                   Nr: 0, Ns: 0

                                                 (Header-only)   <-
                                                  Nr: 1, Ns: 0

             ->    Device-Watchdog-Ind
                   Nr: 1, Ns: 1

             (delay)

                                                 (Header-only)   <-
                                                  Nr: 2, Ns: 1





Taylor, Calhoun, Rubens   expires January 1999                 [Page 76]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


B.2: Multiple packets acknowledged

   This example shows a flow of packets from DIAMETER Host B to Host  A,
   with  Host  A  having no traffic of its own. Host B is waiting 1/4 of
   its timeout interval, and then acknowledging all packets  seen  since
   the last interval.

        DIAMETER Host A                             DIAMETER Host B
               (previous packet flow precedes this)

              ->    (Header-only)
                    Nr: 7000, Ns: 1000
                                 (Message with AVPs)    <-
                                    Nr: 1000, Ns: 7000
                                 (Message with AVPs)    <-
                                    Nr: 1000, Ns: 7001
                                 (Message with AVPs)    <-
                                    Nr: 1000, Ns: 7002

        (Host A's timer indicates it should acknowledge pending traffic)

              ->    (Header-only)
                    Nr: 7003, Ns: 1000


B.3: Lost packet with retransmission

   Host A attempts to communicate with Host B. The Device-Reboot-Ind  is
   lost and must be retransmitted by Host B.

        DIAMETER Host A                             DIAMETER Host B
             ->    Device-Reboot-Ind
                   Nr: 0, Ns: 0

                       (packet lost) Device-Reboot-Ind    <-
                                          Nr: 1, Ns: 0


         (pause; Host A's timer started first, so fires first)

             ->    Device-Reboot-Ind
                   Nr: 0, Ns: 0

        (Host B realizes it has already seen this packet)
   (Host B might use this as a cue to retransmit, as in this example)

                                     Device-Reboot-Ind    <-
                                          Nr: 1, Ns: 0



Taylor, Calhoun, Rubens   expires January 1999                 [Page 77]


INTERNET DRAFT             IPDC Base Protocol                  July 1998


             ->    Device-Watchdog-Ind
                   Nr: 1, Ns: 1

             (delay)

                                         (Header-only)    <-
                                          Nr: 2, Ns: 0

                          ____________________










































Taylor, Calhoun, Rubens   expires January 1999                 [Page 78]