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