[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

INTERNET DRAFT       IPDC Connection Control Protocol     August 1998
INTERNET  DRAFT                                             Andrew Dugan
                                                  Level 3 Communications
Title: draft-dugan-ipdc-connection-00.txt Date: August 1998




                                  IPDC
                      Connection Control Protocol
                  <draft-dugan-ipdc-connection-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 is a member of 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.

   The protocol specification presented here is intended for use between
   a  media  gateway  controller and a media gateway.  The media gateway
   may be capable of acting as a voice over IP gateway, voice  over  ATM
   gateway,  dialup  modem  media  gateway,  circuit  switch,  or cross-
   connect.   Using  the  IP Connection Control protocol presented here,
   the  media   gateway   controller  can  setup,  modify  and  teardown
   connections within or between media gateways.


Dugan                   Expires February 1999                   [Page 1]

INTERNET DRAFT          IPDC Device Management Protocol         August 1998



Table of Contents

  1.0      INTRODUCTION
    1.1    BACKGROUND
    1.2      SPECIFICATION OF REQUIREMENTS
  2.0    MESSAGES
    2.1      RCON - REQUEST CONNECTION
    2.2      ACON - ACCEPT CONNECTION
    2.3      MCON - MODIFY CONNECTION
    2.4    AMCN - ACCEPT MODIFY CONNECTION
    2.5    RCR - RELEASE CONNECTION REQUEST
    2.6      ACR - RELEASE CONNECTION COMPLETED
  3.0    AVP VALUES
    3.1    BEARER CAPABILITY AVP
    3.2    CAUSE CODE AVP
    3.3    CONNECTION DIRECTION AVP
    3.4    CONNECTION ID AVP
    3.5    DYNAMIC PAYLOAD TYPE AVP
    3.6    ENDPOINT 1 IPDC-RESOURCE
    3.7    ENDPOINT 2 IPDC-RESOURCE
    3.8    QOS AVP
    3.9    RADIUS - CALLED PHONE NUMBER
    3.10   RADIUS - CALLING PARTY NUMBER AVP
    3.11   REQUESTED PRIORITY AVP
    3.12   SESSION KEY AVP
    3.13   STATISTICS REQUEST AVP
    3.14   STATISTICS REPORT AVP
  4.0        PROTOCOL DEFINITION
    4.1      LOOPBACK CONNECTION
  5.0        SECURITY CONSIDERATIONS
  6.0        RIGHTS AND PERMISSIONS
  7.0        ACKNOWLEDGMENTS
  8.0      REFERENCES
  9.0      AUTHOR'S ADDRESS

1.0 Introduction

   The protocol specification presented here is intended for use between
   a media gateway and a media gateway controller.   The  media  gateway
   may  be  capable  of  acting as a voice over IP gateway, dialup modem
   access server, or circuit switch.  Using the  IP  Connection  Control
   protocol  within  this  document,  the  controller  entity  can  send
   messages to the media  gateway  to  setup  and  teardown  connections
   within an media gateway or between media gateways.

1.1 Background

   This  protocol  is  part  of  the  IP Device Control (IPDC) family of

Dugan                           Expires February 1999                   [Page 2]

INTERNET DRAFT          IPDC Device Management Protocol         August 1998


   protocols.  The IPDC protocols have been proposed as a protocol suite
   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  .
   Please see the references section for other IPDC documents.

   This document describes the commands and attribute value  pairs  that
   are  necessary  within  the  IPDC protocol to allow the media gateway
   controller to perform call and media control on  the  media  gateway.
   This  control  provides  the ability for the service control logic to
   setup, modify and teardown connections within the media gateway.

   A  media gateway may support multiple  types  of  connections  within
   itself  and to other media gateways. These connections are based upon
   the specification of two media gateway entities or endpoints for each
   connection  request. The IPDC base specification describes the format
   for the specification of these endpoints.  This format may be seen in
   the  definition  of  the  IPDC-Reference  AVP.    The  base  document
   describes a set of  References for device based endpoints as well  as
   other  entity  types   for  packet  based   endpoints.  The following
   endpoint types and corresponding reference types are supported within
   the  IPCC command set.


      GSTN: This endpoint specifies a  channel  that  interconnects  the
      media  gateway  with  a channel on the GSTN.  Entity type: access-
      termintion or trunk-termination

      RTP: This endpoint specifies IP addresses and ports to support  an
      RTP  connection between the media gateway and RTP ports on another
      device. Entity type: RTP-port

      H.323: This endpoint specifies the H.323 address of another device
      that  is  capable  of receiving an H.323 connection from the media
      gateway. Entitiy type:  H.323-spec

      SIP: This endpoint specifies the SIP  address  of  another  device
      that  is  capable of receiving using SIP to establish a connection
      from the media gateway: Entity type:  SIP-spec

      ATM: (for further study). Entity type:  type ATM-spec

      Modem: The modem endpoint  specifies  an  internal  media  gateway
      resource  that  may  be  used for terminating modem calls.  Entity
      type: modem

      Playback:  The  playback  endpoint  specifies  an  internal  media
      gateway  resource  that may be used for streaming audio out on the
      other endpoint involved in the  connection. Entity  type:  stream-

Dugan                           Expires February 1999                   [Page 3]

INTERNET DRAFT          IPDC Device Management Protocol         August 1998


      source

      Record:  The  record  endpoint specifies an internal media gateway
      resource that may be used for  collecting  and  storing  streaming
      audio   coming   from   the   other   endpoint   involved  in  the
      connection.    Entity type: stream-recorder

      Conference: The conference endpoint specifies  an  internal  media
      gateway  resource  that may be used for terminating the call to an
      audio bridge.     Entity type:  conf-port

      Fax: The fax endpoint specifies an internal media gateway resource
      that may be used for collecting or forwarding faxes.  Entity type:
      Fax-port

      Other Internal Device: Media gateways will  have  other  resources
      that  do  not  have  currently assigned reference types. This port
      type is a generic placeholder for these types of devices.   Entity
      type:  Device


   It   is   important   to   note  that  the  IPDC  Connection  Control
   specification is limited to the establishment of connections  between
   endpoints and is not a protocol for controlling the services on those
   endpoints. For example, if  the  protocol  is  used  to  establish  a
   connection  between  a  GSTN  port  and  a  conference  resource, the
   protocol does not provide any mechanisms for controlling such  things
   as  authentication  and admission of callers to a conference, control
   of  which  media  streams  are  played  out  on  which  ports,   etc.
   Similarly,  if the connection is to a fax endpoint, the protocol does
   not provide the commands to instruct the device to collect a fax  and
   store  it  in  a particular mailbox or to transmit a specific fax out
   the other  port  in  the  connection.   The  control  interfaces  for
   instructing  the  server  to  perform  its  application  function are
   expected to be provided by an interface that is outside the scope  of
   IPDC.

   Using  the  endpoint types allowed in the call control commands it is
   possible to establish connections between any two types of endpoints.
   It  is  also  to  establish connections between endpoints of the same
   type.

1.2 Specification of Requirements

   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

Dugan                           Expires February 1999                   [Page 4]

INTERNET DRAFT          IPDC Device Management Protocol         August 1998


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

   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  inter-operate
   with another implementation which does include the option.

2.0 Messages

   This  section  describes  the IPCC commands that are described within
   this document. All IPCC implementations that support  the  connection
   control extension MUST support all of the following commands:

      Command      Command Code    DESCRIPTION
      -------------------------------------------------------------------------
      RCON         1200            Request Connection between two
                                   endpoints
      ACON         1201            Accept Connection
      MCON         1202            Modify Connection
      AMCN         1203            Accept modify connection
      RCR          1204            Release channel request
      ACR          1205            Release channel complete

2.1 RCON - Request Connection

   The RCON command is sent from the controller to the media gateway  to
   request a connection between two endpoints.

   The  table  below  identifies the AVPs that may be used with the RCON
   command.  Because there are a number of different types of  endpoints
   types  that may be used within the RCON command, and some of the AVPs
   may be used with some types of connections and not others, the  table
   includes  an  indication of which endpoints may use each of the AVPs.
   This indication includes a definition of whether the AVP is  required
   with  the  use  of that endpoint or whether the AVP may be optionally
   included under some circumstances. Generally, if the parameter may be
   optionally  included,  the  Notes  column  of the table describes the
   conditions under which it may be used.

   AVP Type                  R/O       Notes
   -----------------------------------------------------------------

Dugan                           Expires February 1999                   [Page 5]

INTERNET DRAFT          IPDC Device Management Protocol         August 1998


   Command                   R-All     Required on all IPDC commands.
   Host-IP-Address           R-All     Required on  all  IPDC  commands.
   Endpoint1 IPDC-Reference  R-All     Specifies the first endpoint
                                       in this connection.
   Endpoint2 IPDC-Reference  R-All     Specifies the second endpoint
                                       in this connection.
   Connection Direction      R-All     Specifies whether this
                                       connection should be
                                       established as bi-directional
                                       or uni-directional.
   Dynamic Payload Type      R-RTP     Specifies the payload type for
                                       RTP connections as defined in
                                       H.235.

   Session Key               O-RTP     Specifies the session key for
                                       RTP connections as defined in
                                       H.235.
   Bearer Capability         R-All     Identifies whether this is a
                                       voice of the Channel (BCC)
                                       or data call.
   Radius - Called           R-Modem   Used only for authentication
   Phone number                        on modem termination calls.
                                       This information must be passed
                                       from the access device to any
                                       authentication servers being
                                       used for modem terminations.
   Radius - Calling          R-Modem
   Party number
   Requested Priority        O-All     Required only for priority
                                       calls. If set to forced, the
                                       media gateway will attempt to
                                       connect the call even if it
                                       requires the tear-down of an
                                       existing non-priority call.
   Statistics Request        O-All     Indicates whether statistics
                                       should be collected on this
                                       call and identifies the
                                       statistics group(s) to be
                                       collected.
   QoS                       O-H.323   Used for networks where
                             O-RTP     Quality of Service controls
                             O-SIP     are available.
   Event Script              O-All     The script is an ASCII text
                                       string of variable length,
                                       formatted according to the
                                       scripting language defined by
                                       the script type parameter.
   Script Type               O-All     This parameter specifies the
                                       script type used in the event

Dugan                           Expires February 1999                   [Page 6]

INTERNET DRAFT          IPDC Device Management Protocol         August 1998


                                       script.  The script type
                                       presented in this document
                                       is script type 1, and is the
                                       default if this parameter
                                       is not specified
   Symbol Set                O-All     The symbol set used in the
                                       script may be specified as
                                       well.  The symbol set defined
                                       in this document is symbol set
                                       1, and is the default if this
                                       parameter is not specified.
   Maximum Buffer Size       O-All     If parameter is not specified,
                                       default buffer size is 512
                                       bytes.

                            Table 1 - RCON AVPs

2.2 ACON - Accept Connection

   The  media  gateway as a successful response to an RCON message sends
   the ACON message.  If the RCON message fails, the media gateway would
   have   sent   a  message  reject  (MRJ)  response.   The  source  and
   destination endpoints are optional to handle the case where the media
   gateway  manages  and  allocates  its  own  endpoints.   If the media
   gateway selects the endpoint for a connection the media gateway  MUST
   return the endpoint address in the ACON.  The media gateway allocates
   its own endpoints in cases where the RCON message uses a wildcard  or
   group designator as a source or destination endpoint.


   AVP Type                  R/O       Notes
   -------------------------------------------------------------------
   Command                   R-All     Required on all IPDC commands.
   Host-IP-Address           R-All     Required on all IPDC commands.
   Connection ID             R-All     Required for all call control
                                       messages.
   Endpoint 1 IPDC-Reference O-All     See the IPDC base specification
                                       for a description of this AVP.
   Endpoint 2 IPDC-Reference O-All     See the IPDC base specification
                                       for a description of this AVP.

                            Table - 2 ACON AVPS

2.3 MCON - Modify Connection

   The  MCON  command  allows  the  media  gateway  controller to change
   parameters or endpoints for a connection. With the use of an existing
   connection  ID,  any  AVP  specified  within the MCON message will be
   interpreted as a request to change the setting for  that  AVP  within

Dugan                           Expires February 1999                   [Page 7]

INTERNET DRAFT          IPDC Device Management Protocol         August 1998


   the call.

   AVP Type                  R/O       Notes
   ---------------------------------------------------------------------
   Command                   R-All     Required on all IPDC commands
   Host-IP-Address           R-All     Required on all IPDC commands
   Connection ID             R-All     Required for all call control
                                       messages
   Endpoint 1 IPDC-Reference O-All     See the IPDC base specification
                                       for a description of this AVP.
   Endpoint 2 IPDC-Reference O-All     See the IPDC base specification
                                       for a description of this AVP.
   Connection Direction      O-All     Specifies whether this
                                       connection
                                       should be established as
                                       bi-directional or uni-directional
   Dynamic Payload Type      O-RTP     Specifies the payload type for
                                       RTP connections as defined in
                                       H.235.
   Session Key               O-RTP     Specifies the session key for RTP
                                       connections as defined in  H.235.
   QOS                       O-H.323   Used for packet networks where
                             O-RTP     Quality of Service controls are
                             O-SIP     available.
   Statistics Request        O-All     Indicates whether statistics
                                       should be collected on this
                                       call and identifies the
                                       statistics group(s) to be
                                       collected.
   Event Script              O-All     ASCII text string formatted
                                       according to the scripting
                                       language defined by the script
                                       type parameter.
   Script Type               O-All     This parameter specifies the
                                       script type used in the event
                                       script.  The script type
                                       presented in this document is
                                       script type 1, and is the default
                                       if this parameter is not
                                       specified.
   Symbol Set                O-All     The symbol set used in the script
                                       may be specified as well.  The
                                       symbol set defined in this
                                       document is symbol set 1, and is
                                       the default if this parameter
                                       is not specified.
   Maximum Buffer Size       O-All     If parameter is not specified,
                                       default buffer size is 512 bytes.


Dugan                           Expires February 1999                   [Page 8]

INTERNET DRAFT          IPDC Device Management Protocol         August 1998


                            Table 3 - MCON AVPs

2.4 AMCN - Accept Modify Connection

   This command is sent in response to an MCON.  Since the MCON  command
   is also a request to query the state of a connection, all AVPs within
   the response are required if they are applicable  to  the  connection
   type.

   AVP Type                  R/O       Notes
   ------------------------------------------------------------------
   Command                   R-All     Required  on  all IPDC commands
   Host-IP-Address           R-All     Required  on  all  IPDC  commands
   Connection ID             R-All     Required for all call control
                                       messages
   Endpoint 1 IPDC-Reference O-All     See the IPDC base specification
                                       for a description of this AVP.
                                       This AVP as well as the
                                       endpoint 2  are optional because
                                       they MUST only be returned when
                                       the MCON request contained
                                       wildcards or groups identifiers
                                       and the ACON responds with the
                                       allocated references.
   Endpoint 2 IPDC-Reference O-All     See the IPDC base specification
                                       for a description of this AVP

                            Table 4 - AMCN AVPs

2.5 RCR - Release Connection request

   This command is sent from the media gateway controller to request the
   media gateway to  tear-down  a  connection  and  free  any  allocated
   resources for that connection.

   AVP Type                  R/O      Notes
   ----------------------------------------------------------------
   Command                   R-All   Required  on  all IPDC commands.
   Host-IP-Address           R-All    Required  on  all  IPDC  commands
   Connection ID             R-All    Required for all call control
                                      messages
   Cause code                R-All

                            Table 5 - RCR AVPs

2.6 ACR - Release Connection completed

   This  command  is  sent  in  response  to  a  request  to  release  a
   connection.  The message contains a number of statistical  AVPs  that

Dugan                           Expires February 1999                   [Page 9]

INTERNET DRAFT          IPDC Device Management Protocol         August 1998


   are required in for packet connections.

   AVP Type                  R/O      Notes
   -----------------------------------------------------------------
   Command                   R-All    Required  on  all IPDC commands.
   Host-IP-Address           R-All    Required  on  all  IPDC  commands
   Connection ID             R-All    Required on all call control
                                      messages
   Packet Statistics         O-H.323  This AVP contains RTP
                             O-RTP    statistics for packet based
                             O-SIP    connections.


                            Table 6 - ACR AVPs

3.0 AVP Values

   This  section  will  define  the  new AVPs that are applicable to the
   commands described within this document.  Some of the base AVPs  such
   as   command  and  host-IP-address  are  defined  in  the  IPDC  base
   specification document, others  such  as  event  type,  script  type,
   symbol  set  and  buffer  size  are defined in the IPMC specification
   document [4].

3.1 Bearer Capability 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|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Bearer Capability                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   AVP Code

      1301      Bearer Capability

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flags

      The flag field MUST have bit one (Mandatory Support) set.
      The flag field MUST not have bit four (Vendor Specific AVP) set.

Dugan                           Expires February 1999                   [Page 10]

INTERNET DRAFT          IPDC Device Management Protocol         August 1998



   Bearer Capability

      The Bearer Capability is used for data connections to specify  the
      type of connection expected on the GSTN side of the media gateway.
      The encoding is  the  same  as  the  octet  "Information  Transfer
      Capability"  from the User Service Information parameter from ANSI
      T1.113.3.  The following bearer types have been defied:

          Voice Call                    0
          64K Data Call                 8
          56K Data Call                 9
          Modem Call (3.1K audio)       16

      The bearer capability field is of type Interger32

3.2 Cause Code 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|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Cause Code Type                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Cause Code                                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code

      1302       Cause Code

   AVP Length

      The  length of this attribute MUST be at least 16 to accommodate 8
      bytes of AVP header information plus a 4 byte cause code type  and
      a 4 byte cause code

   AVP Flags

      The flag field MUST have bit one (Mandatory Support) set.
      The flag field MUST not have bit four (Vendor Specific AVP) set.

   Cause Code Type

      The  cause  code  is  used  for release of connections in order to
      indicate the reason why a connection is being torn down.  The  AVP

Dugan                           Expires February 1999                   [Page 11]

INTERNET DRAFT          IPDC Device Management Protocol         August 1998


      is  made  up  of  two  values. The first value is contained in the
      first 4 bytes and indicates the type of cause  code  contained  in
      the next field. Values for this attribute may be:

          1     ISDN
          Other values reserved for future use

      The  cause  code  values  indicates the reason why a connection is
      being torn down.  Values for this attribute may be:

      A one byte value. For ISDN cause codes, the encoding is defined in
      ANSI T1.113.3, using the CCITT coding standard. The following is a
      list of ISDN cause codes values is for reference only:

          1     Unassigned (unallocated) number
          2     No route to specified transit network
          3     No route to destination
          6     Channel unacceptable
          7     Call awarded and being delivered in
                an established channel
          16    Normal call clearing
          17    User busy
          18    No user responding
          19    No answer from user (user alerted)
          21    Call rejected
          22    Number changed
          26    Non-selected user clearing
          27    Destination out of order
          28    Invalid number format (incomplete number)
          29    Facility rejected
          30    Response to status enquiry
          31    Normal, unspecified
          34    No circuit/channel available
          38    Network out of order
          41    Temporary failure
          42    Switching system congestion (gateway controller,
                media gateway, IP network)
          43    Access information discarded
          44    Requested circuit/channel not available
          47    Resource unavailable, unspecified
          50    Requested facility not subscribed
          57    Bearer capability not authorized
          58    Bearer capability not presently available
          63    Service or option not available
          65    Bearer capability not implemented
          66    Channel type not implemented
          69    Requested facility not implemented
          70    Only restricted digital information bearer
                capability is available

Dugan                           Expires February 1999                   [Page 12]

INTERNET DRAFT          IPDC Device Management Protocol         August 1998


          79    Service or option not implemented, unspecified
          81    Invalid call reference value
          82    Identified channel does not exist
          83    A suspended call identity exists but this call
                identity does not
          84    Call identity in use
          85    No call suspended
          86    Call having the requested call identity has been cleared
          88    Incompatible destination
          91    Invalid transit network selection
          95    Invalid message, unspecified
          96    Mandatory information element is missing
          97    Message type non-existent or not implemented
          98    Message not compatible with call state,  message type
                non-existent/implemented
          99    Information element non-existent or not implemented
          100   Invalid information element contents
          101   Message not compatible with call state
          102   Recovery on time expiry
          111   Protocol error, unspecified
          127   Interworking, unspecified


3.3 Connection Direction 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|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Connection Direction                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   AVP Code

      1303      Connection Direction

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flags

      The flag field MUST have bit one (Mandatory Support) set.
      The flag field MUST not have bit four (Vendor Specific AVP) set.

   Connection Direction


Dugan                           Expires February 1999                   [Page 13]

INTERNET DRAFT          IPDC Device Management Protocol         August 1998


      The  Connection Direction AVP supports the capability to establish
      a one-way or two way connection with the RCON  or  MCON  commands.
      The values for this attribute may be

          1 = Uni-directional connection from endpoint 1 to endpoint 2
          2 = Uni-directional connection from endpoint 2 to endpoint 1
          3 = Bi-directional connection


3.4 Connection ID 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|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Connection ID                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code

      1304      Connection ID

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flags

      The flag field MUST have bit one (Mandatory Support) set.
      The flag field MUST not have bit four (Vendor Specific AVP) set.

   Connection ID

      The  connection  ID  is  used  for all connection related messages
      within IPDC. It must remain the same for  all  messages  exchanged
      for  the  same  connection.  The  data  is  a 4 byte value that is
      assigned by the media gateway for each connection  established  by
      the  gateway.  The  connection ID is returned to the media gateway
      controller in the ACON response to each RCON request.

      The value of the Connection ID attribute should be assigned by the
      media  gateway such that it is guaranteed to be unique within that
      media gateway for a long period of time. The recommended method of
      assigning  Connection  Ids  is  to  use  monotonically  increasing
      numbers that are continuous across reboot. If it is  not  possible
      to  maintain consistency across reboot, the media gateway may also

Dugan                           Expires February 1999                   [Page 14]

INTERNET DRAFT          IPDC Device Management Protocol         August 1998


      generate a random number to begin the sequence again.

      The Connection ID field is of type integer32

3.5 Dynamic Payload Type 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|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Payload Type    . . .
   +-+-+-+-+-+-+-+-+-+-+-+-

   AVP Code

      1305      Dynamic Payload Type

   AVP Length

      The length of this is variable.

   AVP Flags

      The flag field MUST have bit one (Mandatory Support) set.
      The flag field MUST not have bit four (Vendor Specific AVP) set.

   Payload Type

      The  Dynamic  Payload  Type  is  an  optional  attribute  for  all
      connections  that  used  the RTP endpoint type.  The value of this
      field takes on a value as defined in H.235.

      The Dynamic Payload Type field is of type data.

3.6 Endpoint 1 IPDC-Resource

   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                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Endpoint 1 Entity name   . . .

Dugan                           Expires February 1999                   [Page 15]

INTERNET DRAFT          IPDC Device Management Protocol         August 1998


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


   AVP Code

      1306      Endpoint 1 IPDC-Resource

   AVP Length

      This is a variable length field.

   AVP Flags

      The flag field MUST have bit one (Mandatory Support) set.
      The flag field MUST not have bit four (Vendor Specific AVP) set.

   Entity Type Code

      This field identifies the type of endpoint  address  specified  in
      the Endpoint 1 field of this AVP. The allowable values are:

          ACCESS_TERMINATION      5
          TRUNK_TERMINATION       6
          DEVICE                  8
          MODEM                   9
          CONFERENCE_PORT         10
          FAX_PORT                11
          STREAM_SOURCE           12
          STREAM_RECORDER         13
          RTP_PORT                14
          ATM_SPEC                15
          H323_SPEC               16
          SIP_SPEC                17

   Endpoint 1 Entity Name

      The  Endpoint  1  IPDC-Resource AVP is used to identify the source
      endpoint for a connection. The value of  this  field  is  of  type
      IPDC_Resource  and the definition of this type may be found in the
      IPDC base document.  For each of the allowable Entity  Code  Types
      for  this  AVP, the base document provides a description of how to
      populate the entity name field.

      This AVP is of data type data.

3.7 Endpoint 2 IPDC-Resource

   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

Dugan                           Expires February 1999                   [Page 16]

INTERNET DRAFT          IPDC Device Management Protocol         August 1998


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           AVP Code                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          AVP Length           |     Reserved      |P|T|V|E|H|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Entity Type Code                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Endpoint 2 Entity name   . . .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code

      1307      Endpoint 2 IPDC-Resource

   AVP Length

      The length of this attribute MUST be at least  12 to accommodate 8
      bytes  of AVP header information plus a minimum 4 byte data field.
      The character coding of this attribute  is  likely  to  make  this
      field considerably longer than 12.

   AVP Flags

      The flag field MUST have bit one (Mandatory Support) set.
      The flag field MUST not have bit four (Vendor Specific AVP) set.

   Entity Type Code

   in  6 This field identifies the type of endpoint address specified in
   the Endpoint 2 field of this AVP. The allowable values are:

          ACCESS_TERMINATION      5
          TRUNK_TERMINATION       6
          DEVICE                  8
          MODEM                   9
          CONFERENCE_PORT         10
          FAX_PORT                11
          STREAM_SOURCE           12
          STREAM_RECORDER         13
          RTP_PORT                14
          ATM_SPEC                15
          H323_SPEC               16
          SIP_SPEC                17


   Endpoint 2 IPDC-Resource

      The  Endpoint  2  IPDC-Resource  AVP  is  used  to  identify   the
      Destination endpoint for a connection.. The value of this field is

Dugan                           Expires February 1999                   [Page 17]

INTERNET DRAFT          IPDC Device Management Protocol         August 1998


      of type IPDC_Resource and the definition of this type may be found
      in  the IPDC base document.  For each of the allowable Entity Code
      Types for this AVP, the base document provides  a  description  of
      how to populate the entity name field.

3.8 QOS 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|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         QOS Type                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         QOS value                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   AVP Code

      1308            QOS

   AVP Length

      The  length of this attribute is variable, but it must be at least
      12.

   AVP Flags

      The flag field MUST have bit one (Mandatory Support) set.
      The flag field MUST not have bit four (Vendor Specific AVP) set.

   QOS

      The QOS AVP is used on packet based  connections  to  specify  the
      Quality  of  Service  type   and  value  that  should be used when
      establishing the connection. This attribute may only be used  when
      the  packet  network  supports  the  specified  Quality of Service
      Mechanism.

      The AVP is made up of two fields. The first is  a  type  indicator
      which may have the following values:

          0x00000001    MPLS
          0x00000002    ToS bits
          0x00000003    ATM


Dugan                           Expires February 1999                   [Page 18]

INTERNET DRAFT          IPDC Device Management Protocol         August 1998


      The  second is QOS and specifies the Quality of Service value that
      should be used when establishing the  connection.  This  attribute
      coupled  with  the  QOS  Type  completes the definition of how the
      media gateway should setup the connection. This attribute may only
      be  used when the packet network supports the specified Quality of
      Service Mechanism.
      The following QOS values may be specified with this attribute.
          For MPLS 4 byte, network defined, MPLS tag

          For ToS 1 byte (4 bits used, big-Endian)  as  defined  in  RFC
          1349

               0x00000008 Minimize delay
               0x00000004 Maximize throughput
               0x00000002 Maximize reliability
               0x00000001 Minimize monetary cost
               0x00000000 Normal service

          For ATM

               0x00000001 Constant bit rate
               0x00000002 Real-Time variable bit rate
               0x00000003 Non-Real-Time variable bit rate
               0x00000004 Available bit rate
               0x00000005 Unspecified bit rate

3.9 Radius - Called Phone Number

   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|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Called Phone number  . . .
   +-+-+-+-+-+-+-+-+-+-+-+-+-

   AVP Code

      1309      Radius - Called Phone Number

   AVP Length

      The length of this attribute is variable.

   AVP Flags

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

Dugan                           Expires February 1999                   [Page 19]

INTERNET DRAFT          IPDC Device Management Protocol         August 1998


      The flag field MUST not have bit four (Vendor Specific AVP) set.

   Called Phone Number

      The  Radius  - Called Phone Number is used for data connections to
      provide some of the  information  necessary  to  authenticate  the
      caller.   This  information  may  be  used  in a query to a RADUIS
      server to provide additional information about the  service  being
      accessed.  It  is  important  to  note  that this attribute is not
      intended for use for anything other  than  passing  the  value  to
      Radius for user authentication.

      The  Radius  -  Called Phone Number field is of type String with a
      minimum length of 1.

3.10 Radius - Calling Party Number 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|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Calling Party Number  . . .
   +-+-+-+-+-+-+-+-+-+-+-+-+-

   AVP Code

      1301           Radius - Calling Party Number

   AVP Length

      The length of this attribute MUST be at least 9  to accommodate  8
      bytes  of  AVP  header  and  at  least one digit for calling party
      number

   AVP Flags

      The flag field MUST have bit one (Mandatory Support) set.
      The flag field MUST not have bit four (Vendor Specific AVP) set.

   Calling party Number

      The Radius - Calling Party Number is used for data connections  to
      provide  some  of  the  information  necessary to authenticate the
      caller.  This information may be used  in  a  query  to  a  RADUIS
      server  to  provide  additional verification of the calling party.


Dugan                           Expires February 1999                   [Page 20]

INTERNET DRAFT          IPDC Device Management Protocol         August 1998



      The Radius - Calling Party Number field is of type String and  may
      have a variable length including a zero length (not present).


3.11 Requested Priority 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|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Requested Priority                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code

      1311     Request Priority

   AVP Length

      The  length of this attribute MUST be at exactly 12 to accommodate
      8 bytes of AVP header information plus  a  4  byte  indication  of
      whether this is a priority call.

   AVP Flags

      The flag field MUST have bit one (Mandatory Support) set.
      The flag field MUST not have bit four (Vendor Specific AVP) set.

   Requested Priority

      The  Requested  Priority  AVP  is  used  to  indicate to the media
      gateway that this is a priority.  This  requires  that  the  media
      gateway   allocate   any  necessary  internal  resources  for  the
      establishment of the connection even if it requires  the  teardown
      of  an  existing  non-priority  connection.  This implies that the
      media gateway must know  which  of  its  current  connections  are
      priority  connections  and  which  connections  are candidates for
      arbitrary selection as one that may be torn down.
      The Request Priority field is of type Interger32.


3.12 Session Key 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

Dugan                           Expires February 1999                   [Page 21]

INTERNET DRAFT          IPDC Device Management Protocol         August 1998


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           AVP Code                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          AVP Length           |     Reserved      |P|T|V|E|H|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Session Key      . . .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code

      1312            Session Key

   AVP Length

      The length of this attribute is variable.

   AVP Flags

      The flag field MUST have bit one (Mandatory Support) set.
      The flag field MUST not have bit four (Vendor Specific AVP) set.

   Session Key

      The Session Key is an optional attribute for all connections  that
      use  the  RTP  endpoint  type.   This  field  is  used  to specify
      encryption information and takes on a value as defined in H.235.

      The Session Key field is of type integer 32.


3.13 Statistics Request 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|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Statistics Group ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        o  o  o

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Statistics Group ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code

Dugan                           Expires February 1999                   [Page 22]

INTERNET DRAFT          IPDC Device Management Protocol         August 1998



      1313      Statistics Request

   AVP Length

      The length of this attribute MUST be at least  12 to accommodate 8
      bytes   of  AVP  header  information  plus  at  minimum  a  single
      statistics group ID.

   AVP Flags

      The flag field MUST have bit one (Mandatory Support) set.
      The flag field MUST not have bit four (Vendor Specific AVP) set.

   Statistics Group ID

      The Statistics request AVP is used to request the  collection  and
      reporting  of statistics for a call. The data field(s) of this AVP
      contain one or more group IDs  that  represent  statistics  groups
      that  should be collected. Currently only one statistics group has
      been identified. This group  collects  statistics  for  RTP  based
      connections.

      1 Packet statistics group ID

      Other  values may be used for extensions to the protocol or vendor
      specific statistics groups.

      Statistics collected based upon this  request  are  generated  and
      sent  to  the  media gateway controller at the end of the call for
      which they were collected.


3.14 Statistics Report 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|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Statistics Group ID                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Number of audio packets received                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Number of audio packets dropped                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Number of audio packets sent and received       |

Dugan                           Expires February 1999                   [Page 23]

INTERNET DRAFT          IPDC Device Management Protocol         August 1998


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Number of audio bytes sent and received         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Number of audio bytes received                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Number of audio bytes dropped                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Number of signaling packets sent and received   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Number of signaling packets received            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Number of signaling packets dropped             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Number of signaling bytes sent and received     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Number of signaling bytes received              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Number of signaling bytes dropped               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Estimated Average Latency                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   AVP Code

      1314           Statistics Report

   AVP Length

      The length of this attribute MUST be at least 16 to accommodate  8
      bytes of header, a group ID and at least one statistic.

   AVP Flags

      The flag field MUST have bit one (Mandatory Support) set.
      The flag field MUST not have bit four (Vendor Specific AVP) set.

   Connection Packet Statistics

      This  AVP  is  used  to  report  statistics about the a particular
      statistics group  that  was  associated  with  a  connection.  The
      example  AVP  format  shown  above  is  the  only statistics group
      currently defined. This group collects statistics about   the  RTP
      session  associated with a connection. The packet statistics group
      contains 13 four byte values that hold the  following  information
      elements

      Number  of  audio  packets  sent  and received:The total number of
      packets of audio data sent and received on the RTP connection

Dugan                           Expires February 1999                   [Page 24]

INTERNET DRAFT          IPDC Device Management Protocol         August 1998



      Number of audio packets received:  The number of packets of  audio
      data  that  were  received  by the media gateway during on the RTP
      connection.

      Number of audio packets dropped: The number of  packets  of  audio
      data that were lost during the RTP connection

      Number of audio bytes sent and received: The total number of bytes
      of audio data sent and received on the RTP connection

      Number of audio bytes received: The number of bytes of audio  data
      received during on the RTP connection.

      Number  of audio bytes dropped: The number of bytes of  audio data
      that was lost during the RTP connection

      Number of signaling packets sent and received: The number of  RTCP
      packets  sent  and  received  by  an media gateway during and RTCP
      connection

      Number of signaling packets received: The number of  RTCP  packets
      received by the access server during a connection

      Number of signaling packets dropped     The number of RTCP packets
      lost during an RTCP connection

      Number of signaling bytes sent and received: The  number  of  RTCP
      bytes sent and received during an RTCP connection

      Number  of  signaling  bytes  received:  The  number of RTCP bytes
      received during by an media gateway  during a connection

      Number of signaling  bytes  dropped:  The  number  of  RTCP  bytes
      dropped during an RTCP connection

      Estimated  average  latency:  Estimated  latency  between  the two
      endpoints in an RTP connection. RFP 1889 for a description on  how
      to measure estimated average latency.

      Inter-arrival  jitter:  Estimated  measurement of the variation in
      packet latency between two endpoints in an RTP connection. See RFP
      1889 for a description on how to measure inter-arrival jitter.


4.0  Protocol Definition

   This  section  describes  how  to  establish any unusual or confusing
   connection types within the IPCC protocol. The only  connection  type

Dugan                           Expires February 1999                   [Page 25]

INTERNET DRAFT          IPDC Device Management Protocol         August 1998


   currently  described  within this section is the loopback. Others may
   be described as they are identified as being difficult to understand.

4.1 Loopback Connection

   The  IPCC  message  set  may  be  used  to  establish  may  types  of
   connections, one such connection that may not  be  obvious  from  the
   message  definitions  above  is  the  ability to establish a loopback
   connection.  Two types of loopbacks may be established in the context
   of this protocol.

   The  first type of loopback may be used to perform continuity testing
   on the GSTN network.  This is  the  traditional  loopback  connection
   that  would  be used to perform a continuity test as required for SS7
   ISUP.  This may be established by simply  specifying  the  same  GSTN
   reference  channel  value  for  both  Endpoint 1 and Endpoint 2.  The
   media gateway will establish a loopback connection on that channel.

   The second type of loopback exists within the IP network and  may  be
   used  to  verify  connectivity or measure performance statistics. The
   mechanisms to perform these types of tests are outside the  scope  of
   the is protocol, but the ability to establish this type of connection
   is not.   This type of connection may be established by taking an RTP
   connection  and  looping it back on itself. To do this, the following
   types of values may be specified for Endpoint 1 and Endpoint 2 for  a
   connection.

         Endpoint 1 reference:   /rtp-term/134.37.41.2:3056/-
         Endpoint 2 reference:   /rtp-term/-/134.37.45.4/

   In this example, the receive RTP port is specified for Endpoint 1 and
   the transmit port is  specified  for  Endpoint  2.   This  in  effect
   establishes  a  one-way  connection  that  takes  RTP  packets  in on
   endpoint 1 and  transmits  them  out  on  endpoint  2.   The  address
   specification  for  the  transmit side of Endpoint 2 should be set to
   the IP address and port of the far-end device that will be performing
   the loopback tests.


5.0 Security Considerations

   Security  issues  are  not  discussed  in  this  memo.   The security
   mechanisms recommended are those specified in [3].


6.0 Rights and Permissions

   The contributors to this document are listed in the author's  address
   and  acknowledgement  sections  of the document.  All contributors to

Dugan                           Expires February 1999                   [Page 26]

INTERNET DRAFT          IPDC Device Management Protocol         August 1998


   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 and addresses 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
   potentially  pertinent  proprietary  and intellectual property rights
   owned or claimed by the organization he represents (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.


7.0 Acknowledgments

   The author wishes to acknowledge the following individuals for  their
   contribution to the IP Call Control  protocol:

          Ascend Communications Inc.    Ilya  Akramovich
          Selsius Systems               Bob Bell
          Tekelec                       Dan Brendes
          3Com Corporation              Peter Chung
          3Com Corporation              Russ Dehlinger
          Level 3 Communications        Isaac Elliott
          Cisco Systems, Inc.           Cary Fitzgerald
          Cisco Systems, Inc.           Jan Gronski
          Stratus Computer, Inc.        Tom Hess

Dugan                           Expires February 1999                   [Page 27]

INTERNET DRAFT          IPDC Device Management Protocol         August 1998


          Level 3 Communications        Geoff Jordan
          Ascend Communications, Inc.   Tony Lam
          Xcom Technologies               Shawn Lewis
          Ascend Communications, Inc.   Dave Mazik
          Vertical Networks               Alan Mikhak
          Alcatel Telecom               Pete O'Connell
          Vertical Networks             Scott Pickett
          Ericsson                      Shyamal Prasad
          3Com Corporation              Paul Richards
          Ascend Communications, Inc.   Dale Skran
          Lucent Technologies           Louise Spergel
          Lucent Technologies           Raj Srinivasan
          Nortel                        Tom Taylor
          Nortel                        Michael Thomas



8 References

   [1] Calhoun, Rubens, "DIAMETER Base Protocol", Internet-Draft, draft-
   calhoun-diameter-03.txt, May 1998
   [2] Calhoun, Zorn, Pan, "DIAMETER  Framework",  Internet-Draft,draft-
   calhoun-diameter-framework-00.txt, May 1998
   [3] Taylor, "IP Device Control Base Protocol",
   [4] Elliott, "IP Media Control Protocol",
   [5] Skran, "IP Device Control Framework"
   [6] Pickett,Mikhak, "IP Device Management Protocol"
   [7] Bell, "IP Signaling Protocol"



9 Author's Address
   Questions about this memo can be directed to:

   Andrew Dugan
   Level 3 Communications
   1450 Infinite Drive
   Louisville, CO 80027

   Phone:     1-303-926-3429
   Fax:       1-303-926-3406
   Email:     andrew.dugan@L3.com








Dugan                           Expires February 1999                   [Page 28]
INTERNET DRAFT          IPDC Device Management Protocol         August 1998


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/