Internet Engineering Task Force Ping Pan (Columbia U) INTERNET DRAFT Henning Schulzrinne (Columbia U) Pat Calhoun (Sun) 31 July 1998 DIAMETER: Policy and Accounting Extension for SIP draft-pan-diameter-sip-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 not appropriate to use Internet Drafts as reference material, or to cite them other than as a ``working draft'' or ``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.ietf.org (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Abstract This document describes a policy and accounting information exchange mechanism between a DIAMETER policy server and a SIP proxy server. A DIAMETER server is responsible for maintaining a user policy and accounting database and a means to update it. A SIP proxy server needs to be able to contact a DIAMETER server during multimedia session setup and tear-down time to perform admission control and accounting tasks. To provide proper service guarantees to the sessions that are established with SIP, DIAMETER servers are also responsible for providing an interface to the network resource management database. However, this is beyond the scope of this document. Calhoun, Schulzrinne, Pan Expires 31 December 1998 [Page i] Internet Draft DIAMETER-SIP 31 July 1998 The objective of the mechanism is 1) accuracy, 2) flexibility, and 3) simplicity. The protocol does not make any assumptions about policy algorithms at DIAMETER servers and implementation details at SIP servers. Calhoun, Schulzrinne, Pan Expires 31 December 1998 [Page ii] Internet Draft DIAMETER-SIP 31 July 1998 Contents Status of This Memo i Abstract i 1. Introduction 1 2. Terminology 3 3. Description of Operation 3 3.1. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. Initialization Operation . . . . . . . . . . . . . . . . 4 3.3. Caller Detailed Operation . . . . . . . . . . . . . . . . 4 3.4. Callee Detailed Operation . . . . . . . . . . . . . . . . 5 3.5. Server Considerations . . . . . . . . . . . . . . . . . . 5 4. AVP Formats 5 4.1. Device-Reboot-Indication AVP extension . . . . . . . . . 6 4.2. DIAMETER-Command AVP extension . . . . . . . . . . . . . 7 4.3. DIAMETER Error-Code AVP extension . . . . . . . . . . . . 7 4.4. SIP Specific AVP's . . . . . . . . . . . . . . . . . . . 7 4.4.1. SIP-Sequence AVP . . . . . . . . . . . . . . . . 8 4.4.2. SIP-Call-ID AVP . . . . . . . . . . . . . . . . . 9 4.4.3. SIP-To AVP . . . . . . . . . . . . . . . . . . . 10 4.4.4. SIP-From AVP . . . . . . . . . . . . . . . . . . 11 4.4.5. SIP-Entire-Msg AVP . . . . . . . . . . . . . . . 11 5. Command Format 12 5.1. SIP Admission Control Commands . . . . . . . . . . . . . 12 5.2. SIP Accounting Commands . . . . . . . . . . . . . . . . . 13 5.3. SIP Termination Commands . . . . . . . . . . . . . . . . 14 Calhoun, Schulzrinne, Pan Expires 31 December 1998 [Page iii] Internet Draft DIAMETER-SIP 31 July 1998 1. Introduction DIAMETER [ZPC98] is a proposed successor to RADIUS [RRSW97]. It defines a base protocol [RC98] for policy information to be exchanged among policy-enable entities. It is designed as a common platform for several Internet services, such as AAA (Authentication, Authorization i and Accounting), network-edge resource management and VPN (Virtual Private Network). SIP [HSS98] (Session Initiation Protocol) is designed to allow network users to establish and control multimedia sessions over the Internet. A SIP session can be an IP telephone call. However, user accounting, policy and billing systems are beyond scope of SIP, and must be in place in order to provide telephony service in commercial networks. This document describes a policy/accounting mechanism that can interface between SIP proxy servers and policy servers to provide admission control and to update and maintain user data for accounting purposes. Figure-1 illustrates the proposed model. +------------+ | Policy | | Server | +------------+ /|\ | | DIAMETER messages | \|/ +-----------------+ | Diameter Client | +--------+ SIP messages | | SIP Messages | SIP | ================> | (SIP Proxy) | ====================> | client | | | +--------+ | | +-----------------+ Figure-1: A model for SIP/DIAMETER interface. The proposal is designed based on the following assumptions: 1. A policy server is the central decision entity. The clients (that is, SIP proxy servers) should always forward the information to the server. However this does not preclude Calhoun, Schulzrinne, Pan Expires 31 December 1998 [Page 1] Internet Draft DIAMETER-SIP 31 July 1998 a client from maintaining a policy information cache for performance optimization purposes. 2. A policy server maintains a policy and accounting database for all users within an administrative domain, and a means to update it. 3. The extension relies on the base protocol to provide massaging reliability. A DIAMETER server and a DIAMETER client, therefore, have no need to implement other reliable message delivery mechanisms. SIP is a out-band signaling protocol, and the actual voice data may use a different route than the path that SIP messages traverse. For IP telephony, voice data is transmitted in the form of RTP [SCFJ96]. To ensure voice data being delivered properly, users can make the use of end-to-end resource reservation protocols to set up reserved "flows". Another alternative is to mark the packet header as "premium service" [ZJN97] so that they can be delivered with low delay and rate guarantees inside the network. Both approaches imply that the network-edge routers may need to interface with policy servers to manage link resources. However, the detailed mapping and management between IP telephone sessions and link resource management requires further investigation, and are beyond the scope of this document at this point. In addition, the proposed extension does not perform policy and accounting processing itself. It is therefore important to remember: 1. The protocol does NOT make any assumptions about the algorithm of the policy server, but is based on the server returning a "decision" in response to a policy request. 2. The protocol does NOT make any assumptions about the implementation details of the SIP proxy server. However, when a policy event takes place, a SIP proxy must send all relevant information to a server for policy evaluation. 3. The communication mechanism among policy servers is NOT in the scope of this document. 4. To provide IP telephone service, it may require some level interaction between the policy server at the caller-side and the one at the callee-side. However, such interaction requires further investigation and is not included in this document. Calhoun, Schulzrinne, Pan Expires 31 December 1998 [Page 2] Internet Draft DIAMETER-SIP 31 July 1998 2. Terminology - Caller: The device that initiating a session invitation. Through out the draft, we assume a caller is a SIP proxy server that sets up sessions for telephone users at a source network. - Callee: The device that a caller is trying to invite to a session. We assume a callee is a SIP proxy server that manage sessions for telephone users at a remote network. - Policy Server: A host or router that stores policy rules, and is capable to communicate with its clients via DIAMETER protocol. - Client: A SIP proxy server that interface with a "trusted" policy server to perform policy and accounting checking, and some level of admission control. A client is a SIP caller, or a SIP callee, or both. - Policy Event: The event that takes place at a client and requires policy checking. Such event could be the reception of a SIP INVITE, ACK, CANCEL, or BYE message. - Policy Event Message: The message that triggers a policy event at a client. - AVP: The DIAMETER protocol consists of a header followed by objects. Each object is encapsulated in a header known as an Attribute-Value-Pair. 3. Description of Operation 3.1. Outline DIAMETER client (in this case, SIP Proxy Server) and policy server exchange DIAMETER messages to open and confirm a client-server connection at boot-up time. The initial data between a policy server and a client are device availability, client/server identification and the level of supported features. The information is encoded in standard DIAMETER Device-Reboot-Indication and Host-IP-Address AVP's. Both client and policy servers must support DIAMETER SIP extension. In case a client going down, the server must download known client configuration to the client after reboot. A client queries its policy server when a SIP policy event occurs. A policy event could be due to the arrival of a SIP INVITE, ACK, CANCEL Calhoun, Schulzrinne, Pan Expires 31 December 1998 [Page 3] Internet Draft DIAMETER-SIP 31 July 1998 or BYE message. SIP OPTION and REGISTER messages will not trigger policy events. When the server receives a query, it performs policy checking, admission control and accounting. If the server needs to inform the results of the policy checking to a client, it can send a reply message to the client. A client, by default, has one primary and several alternative servers. In case of primary server failure, the client can try to open a new DIAMETER connection with one of its alternative servers. After the new connection is established, the client must notify the server of all its pending policy requests. A policy server can asynchronously download policy decisions to a client. In turn, the policy decisions may trigger SIP messages to be generated at the client to re-direct or cease existing sessions. Optionally, a client can cache all or a part of the policy decisions locally. In this case, a server must asynchronously download the decision information to the client. However, the server must be responsible for updating any decision change to the client. 3.2. Initialization Operation At the boot-up time, servers and clients inform each other about the features that need to be supported. As a part of the feature discovery process, the DIAMETER Device-Reboot-Indication AVP must contain the feature number that has been assigned to the SIP/DIAMETER extension. For a client that has multiple servers, it must exchange feature information with all its servers at initialization time. 3.3. Caller Detailed Operation When a caller (a SIP proxy server) is being notified to set up a call for a user, it first initiates a DIAMETER request command to its policy server with all the information about the user. The server, in turn, checks the request against the admission control policy database, and returns the findings in a DIAMETER response message. If the response is OK, the caller will sends a SIP INVITE message to the callee. If the callee accepts the call, it replies a SIP 200 (SUCCESS) signal to the caller. Upon reception, the caller confirms the call by sending back a SIP ACK message. At the same time, the call must also Calhoun, Schulzrinne, Pan Expires 31 December 1998 [Page 4] Internet Draft DIAMETER-SIP 31 July 1998 send a notification to the server to start the accounting process. The notification is in DIAMETER request message format. When a caller receives a call termination notification from the user, or a SIP BYE message from the callee, it informs the policy server to stop the accounting. When a caller sends a SIP CANCEL message to cancel a pending request, it must also inform the policy server. 3.4. Callee Detailed Operation After a callee receives a INVITE message, it initiates a SIP request command to the server for policy checking. If the server replies a denial response, the callee will reject the session invitation by sending a SIP 4XX (Error) signal to the caller. The original INIVITE message MUST be dropped at the callee. If the server permits the invitation, the callee needs to relay the INIVITE message to the destination user, or (as a proxy) to directly reply a SIP 200 signal to the caller. A SIP caller always sends a SIP ACK message to the callee to confirm the establishment of a session. When an ACK message being received, the callee MUST send a SIP request message to the policy server to start the accounting process. When the callee decides to terminate the call, or a BYE message is sent by the caller, the callee MUST send a SIP request message to the server to stop the accounting process. After the callee receives a SIP CANCEL, it needs to inform the policy server to remove the pending requests. 3.5. Server Considerations DIAMETER/SIP policy servers may or may not support SIP protocol. As a result, clients have the option to either 1) send the entire SIP message to the servers, or 2) parse the SIP message first and send pre-defined SIP AVP's to the servers. 4. AVP Formats Each DIAMETER message consists of multiple AVP's, that are 32-bit aligned, with the following format: Calhoun, Schulzrinne, Pan Expires 31 December 1998 [Page 5] Internet Draft DIAMETER-SIP 31 July 1998 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (AVP contents) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code Identifies the AVP; values of this field are defined below. AVP Length A 16-bit field containing the total object length in bytes. Must always be a multiple of 4, and at least 8. AVP Flags 0x01: Mandatory-Support 0x02: SS-Encrypted-Data 0x03: PK-Encrypted-Data 0x04: Vendor-Specific-AVP Readers can refer [RC98] for detailed DIAMETER base protocol information. 4.1. Device-Reboot-Indication AVP extension Clients and servers send the Device-Reboot-Indication messages at initialization or reboot time. The message originator must include all supported extensions within the message. The responder must include all supported extensions as long as they were present within the request message. The DIAMETER SIP extension uses Extension Id 6. The Extension Id may also be used in Device-Feature-Request, Device-Feature-Response and Extension-Id AVP's. Calhoun, Schulzrinne, Pan Expires 31 December 1998 [Page 6] Internet Draft DIAMETER-SIP 31 July 1998 4.2. DIAMETER-Command AVP extension The Command AVP must be the first AVP following the DIAMETER header. There must only be one Command AVP per message. The command information is in the AVP's Command Code field. The message format can be found in [RC98]. This document defines the following DIAMETER Command Codes. All DIAMETER implementations supporting this extension MUST support all of the following: Command Name Command Code -------------------------------------------- SIP-Admission-Request 600 SIP-Admission-Response 601 SIP-Accounting-Request 602 SIP-Accounting-Response 603 SIP-Termination-Request 604 SIP-Termination-Response 605 4.3. DIAMETER Error-Code AVP extension The Error-Code AVP contains the explicit message error code. Note: the Error-Code AVP must be coupled with the Result-Code AVP which consists of DIAMETER_SEE_ERROR_CODE information. The extension defines the following additional error code for SIP operation: 0x6001: Missing Call-ID in the request 0x6002: Missing To in the request message 0x6003: Missing From in the request message 0x6010: Prohibited Caller 0x6011: Prohibited Callee 4.4. SIP Specific AVP's This section defines the extension specific AVP's. Calhoun, Schulzrinne, Pan Expires 31 December 1998 [Page 7] Internet Draft DIAMETER-SIP 31 July 1998 The following are the mandatory AVP's which must be recognized by all DIAMETER implementations supporting this extension. Attribute Name AVP Code ----------------------------------- SIP-Sequence 600 SIP-Call-ID 601 SIP-To 602 SIP-From 603 The following is an optional AVP. Attribute Name AVP Code ----------------------------------- SIP-Entire-Msg 604 4.4.1. SIP-Sequence AVP Each SIP-Request or SIP-Response MUST accompany with a sequence number. When a DIAMETER device receives a request, it checks the received sequence number against the sequence number in the last transmitted SIP-Request of the same SIP session. If they are not equal, the response is ignored. The AVP may be replaced by a DIAMETER global sequence number AVP in the future. 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 | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code Calhoun, Schulzrinne, Pan Expires 31 December 1998 [Page 8] Internet Draft DIAMETER-SIP 31 July 1998 SIP-Sequence: 600 AVP Length: The length of this attribute MUST be 12. AVP Flags The AVP Flags field MUST have bit one (Mandatory Support) set. Sequence Number: A number between 0xff to 0xffffffff 4.4.2. SIP-Call-ID AVP SIP uses Call-ID to identify a particular call session between two users. DIAMETER servers can use Call-ID's to keep track of all on-going calls for billing and accounting purposes. The SIP-Call-ID AVP has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // SIP Call-ID // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code SIP-Call-ID: 601 AVP Length: The length of this attribute depends on the size of SIP Call-ID. AVP Flags Calhoun, Schulzrinne, Pan Expires 31 December 1998 [Page 9] Internet Draft DIAMETER-SIP 31 July 1998 The AVP Flags field MUST have bit one (Mandatory Support) set. SIP Call-ID: A copy of the original SIP Call-ID data. 4.4.3. SIP-To AVP This identifies the invited user of the session. 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 | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // SIP TO URL // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code SIP-TO-ID: 602 AVP Length: The length of this attribute depends on the size of SIP TO URL. AVP Flags The AVP Flags field MUST have bit one (Mandatory Support) set. SIP Call-ID: A copy of the original SIP URL for the invited user. Calhoun, Schulzrinne, Pan Expires 31 December 1998 [Page 10] Internet Draft DIAMETER-SIP 31 July 1998 4.4.4. SIP-From AVP This AVP identifies the invitation initiator ID in SIP URL format. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // SIP FROM URL // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code SIP-FROM-ID: 603 AVP Length: The length of this attribute depends on the size of SIP FROM URL. AVP Flags The AVP Flags field MUST have bit one (Mandatory Support) set. SIP Call-ID: A copy of the invitation initiator's SIP URL. 4.4.5. SIP-Entire-Msg AVP The AVP encapsulates an entire SIP message. In order to ease the processing overhead at clients, and to provide adequate information, a SIP request message may send the entire SIP message to the server for parsing and processing. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Calhoun, Schulzrinne, Pan Expires 31 December 1998 [Page 11] Internet Draft DIAMETER-SIP 31 July 1998 | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // SIP Message // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code SIP-Entire-Msg: 604 AVP Length: The length of this attribute depends on the size of SIP message. AVP Flags The AVP Flags field MUST not have bit one (Mandatory Support) set. SIP Message: A copy of the original SIP message. 5. Command Format 5.1. SIP Admission Control Commands During SIP call setup time, a SIP caller sends an admission control request to the DIAMETER server before sending a SIP INVITE message. At callee's side, it sends an admission control request to the DIAMETER server after receiving a SIP INVITE message. The format of the request message is the following: ::= Calhoun, Schulzrinne, Pan Expires 31 December 1998 [Page 12] Internet Draft DIAMETER-SIP 31 July 1998 [] { || } The Host-IP-Address AVP contains the client's IP address. The server bases on the request to conduct admission control for the session, and reply a response back to the client in the following format: ::= [] [] [] { || } The Host-IP-Address AVP contains the server's identification. If the server does not admit the call session, it must reply an Error-Code AVP to identify the rejection reason. SIP client and server, by default, use SIP Call-ID to represent a call session. However an implementation may use SIP To and From to manage call sessions in their database, so the response may need to consist of SIP-To and SIP-From AVP's. 5.2. SIP Accounting Commands After a SIP call session being established, the clients need to send an account request command to the servers to start up the accounting process. The message format is: Calhoun, Schulzrinne, Pan Expires 31 December 1998 [Page 13] Internet Draft DIAMETER-SIP 31 July 1998 ::= [] { || } The Timestamp AVP contains the timing information at client. Servers must base on this information to keep the duration of call sessions. The servers must reply an accounting response back to the clients. ::= [] [] [] { || } If the server cannot process an accounting request, it must reply an Error-Code AVP to identify the error condition. 5.3. SIP Termination Commands A SIP Termination request may come from either client-side or server-side. At a client, when it receives a hang-up signal from end users, or a SIP BYE message, or a SIP CANCEL message (for callee Calhoun, Schulzrinne, Pan Expires 31 December 1998 [Page 14] Internet Draft DIAMETER-SIP 31 July 1998 only), it must inform the server to stop the accounting process. Due to user policy, the server can send a termination request to the client to stop an on-going call. In turn, the client must send a SIP BYE to the other party to cease a call. A termination request has the following format: ::= { || } When a DIAMETER receives a termination request, it must reply: ::= [] [] [] { || } References [HSS98] M. Handley, H. Schulzrinne, and E. Schooler. SIP: session initiation protocol. Internet Draft, Internet Engineering Task Force, May 1998. Work in progress. Calhoun, Schulzrinne, Pan Expires 31 December 1998 [Page 15] Internet Draft DIAMETER-SIP 31 July 1998 [RC98] A. Rubens and P. Calhoun. DIAMETER base protocol. Internet Draft, Internet Engineering Task Force, July 1998. Work in progress. [RRSW97] C. Rigney, A. Rubens, W. Simpson, and S. Willens. Remote authentication dial in user service (RADIUS). RFC 2138, Internet Engineering Task Force, April 1997. [SCFJ96] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson. RTP: a transport protocol for real-time applications. RFC 1889, Internet Engineering Task Force, January 1996. [ZJN97] L. Zhang, V. Jacobson, and K. Nichols. A two-bit differentiated services architecture for the internet. Internet Draft, Internet Engineering Task Force, December 1997. Work in progress. [ZPC98] G. Zorn, P. Pan, and P. Calhoun. DIAMETER framework document. Internet Draft, Internet Engineering Task Force, August 1998. Work in progress. Authors' Address Ping Pan Dept. of Electrical Engineering Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA Email: pan@ctr.columbia.edu Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA Phone: 1-212-939-7042 Email: schulzrinne@cs.columbia.edu Pat Calhoun Technology Development Sun Microsystems, Inc. Calhoun, Schulzrinne, Pan Expires 31 December 1998 [Page 16] Internet Draft DIAMETER-SIP 31 July 1998 15 Network Circle Menlo Park, California, 94025 USA Phone: 1-650-786-7733 Email: pcalhoun@eng.sun.com Calhoun, Schulzrinne, Pan Expires 31 December 1998 [Page 17]