SIP Working Group H.Sinnreich, S.Donovan, D.Rawlins, S.Thomas Internet Draft MCI WorldCom, TransNexus Document: draft-sinnreich-interdomain-sip-qos-osp-00.txt October 1999 Category: Informational Interdomain IP Communications with QoS, Authorization and Usage Reporting Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except that the right to pro- duce derivative works is not granted. 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 mate- rial or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract IP communications such as telephony may require quality of service equal or better than available on digital circuit switched networks. Service providers will ensure QoS only if authorization and payments are supported across the domains where the communication is taking place. The message exchange for session initiation, authorization, policy support, QoS and usage reporting is more complex than the mes- sage exchange for each of the protocols in part for these functions, since session parameters have to be passed between messages. The inter-process dependencies require interleaving of messages from the different protocols in a certain sequence to pass on the required parameters. Policy based QoS is provided by RSVP enabled routers and mapped to 802 style LANs. RSVP aggregation is used for Differentiated Services QoS across the backbone. The present document provides the framework and examples of the mes- sage exchange between clients and servers on networks of Internet service providers or corporate networks across a common IP backbone. Outsourcing to a clearinghouse of inter-domain authorization and usage reporting is also shown. Sinnreich, et al. draft-interdomain-sip-qos-osp-00.txt Page 1 Internet Draft Interdomain IP Communications October 1999 2. Content 1. Abstract.........................................................1 2. Content..........................................................1 3. Introduction.....................................................2 3.1. Background.....................................................2 3.2. Purpose........................................................3 3.3. Discussion of the Purpose......................................3 4. Outline..........................................................3 4.1. Reference Model................................................3 4.2. Network Elements...............................................5 4.3.1. SIP, Policy, RSVP and COPS Interworking......................5 4.3.2 SIP and OSP Interworking......................................6 5. Message Exchange and Inter-Process Overview......................7 5.1 Overview........................................................7 5.1.1 Call Setup Request, Authorization and Policy..................7 5.1.2 QoS setup, call progress reports and acknowledgement..........7 5.1.3 RSVP Initiated QoS Teardown...................................9 5.1.4 Generic QoS Usage Reporting to Clearing House................10 5.1.5 Call Teardown with Background Usage Update...................11 5.1.6. Call Teardown with Real-Time Usage Update...................12 5.2. Detailed Call Flows...........................................13 5.2.1 Call Setup Messages..........................................13 5.2.3 OSP Messages for Usage Recording.............................21 6. Acknowledgements................................................22 7. References......................................................22 8. AuthorsĘ Addresses..............................................23 Sinnreich, et al. draft-interdomain-sip-qos-osp-00.txt Page 2 Internet Draft Interdomain IP Communications October 1999 3. Introduction There is a widespread belief that commercial IP telephony and other IP communication services have to provide equal quality of service (QoS) or better, when compared to digital circuit switched telephony. This requires end-to-end QoS in corporate IP networks, by Internet service providers (ISPs) and across the IP backbone that carries traffic between the networks. QoS requires the usage of network resources. Network administrators and service providers will make resources available only if they can be assured that they will be paid for the usage of resources. Payment is based on the authoriza- tion of the parties participating in the communication and on report- ing the usage of network and computing resources. QoS delivery is based on policy for network usage. SIP servers act as policy enforce- ment points. SIP call parameters such as end point addresses, call ID, time, authorization requests and tokens have to be exchanged with policy servers and trusted AAA servers to install and tear down QoS policy in RSVP enabled routers and 802 style LANs. Aggregation of RSVP into Differentiated Services by edge routers will insure QoS across the backbone. 3.1. Background Providing IP communications with QoS across the Internet, between various network operators, requires a common way of usage for call setup, authorization, and QoS. Though the individual protocols have been developed in detail, there is at present no reported work on how to use them together in a consistent way across the Internet. 3.2. Purpose This document describes the framework for linkage and provides exam- ples of the sequence of the individual messages of the various proto- cols for IP communications with QoS and accounting. The interchange of parameters between session setup, authorization, policy, QoS and usage reporting will support quality IP communications across the Internet, between ISPs, enterprise networks, and individual clients. 3.3. Discussion of the Purpose There is a range of trade-offs between complexity, bandwidth and QoS: a. Bandwidth is over-provisioned end-to-end, best effort gives satisfactory QoS, b. Provide QoS in the access networks only, where it is usually most critical, c. Provide QoS end-to-end for QoS ensured communications. The last option is the hardest problem to solve and will be Sinnreich, et al. draft-interdomain-sip-qos-osp-00.txt Page 3 Internet Draft Interdomain IP Communications October 1999 considered in this document. Options a. and b. for partial QoS are in our opinion also valid alternatives, and can simplify the message exchange. When only partial or no QoS is available, the caller could receive messages, such as: "Sorry, we cannot guarantee complete quality for this call, , would you like to continue anyway?" Reasons to inform the cus- tomer could be: "Access, backbone or remote network do not guarantee quality of service", or "Temporary high traffic in access, backbone or remote network". 4. Outline 4.1. Reference Model The reference model has been chosen so as to represent many instances found in IP telephony or other types of IP communications. It is not an exhaustive model, but serves the purpose of defining the message exchange between network domains and network elements. The reference model has two types of clients: a. Analog or digital phones that connect to the IP network via the circuit switched network and IP telephony gateways, b. IP clients, such as IP phones or various types of computers. IP telephony gateways, IP phones and other computers are considered here clients for SIP call setup and RSVP signaling for network resources. The SIP server acts as an Enforcement Point (PEP) to authorize calls requested by SIP clients. Sinnreich, et al. draft-interdomain-sip-qos-osp-00.txt Page 4 Internet Draft Interdomain IP Communications October 1999 +--------------+ +--|Clearing House|--+ | +--------------+ | | | | | +--+---+ +------+ +---+--+ |Policy| | | |Policy| |Server| | | |Server| +-----+ | | | | | | +------+ | SIP |--| SIP |--| |--| SIP |--| Iptel| |Phone| |Proxy | | | |Proxy | | GWY | +-----+ | | | | | | +------+ | Edge | | | | Edge | |Router| | | |Router| +------+ +------+ +------+ ISP-1 Backbone ISP-2 Fig. 1. Reference diagram for telephony-style IP communication SBM is responsible for controlling access to 802.1p networks. End/edge devices are responsible for tagging traffic with the appro- priate priority value as specified by the SBM. Traffic must also abide by its TSpec in order to be given priority. Nonconforming traf- fic must be policed/shaped by the end hosts or edge devices in the LAN. There are various types of routers in the access networks and in the backbone. For our purpose, we will only elaborate the function of the edge router in the access network connecting to the backbone. The edge router aggregates all RSVP requests in the adjacent ISP network into DiffServ traffic classes that can be understood by the border router in the backbone to which it is attached. The backbone provides scalable QoS for the aggregate DiffServ flows and does not partici- pate in any way in RSVP signaling. The backbone is transparent to RSVP. End-to-end QoS is provided by RSVP signaling between the IP communication clients, the edge routers, across the backbone as shown is the message exchanges that follow. An assembly of several mechanisms provides QoS in the access net- works: 1. Clients communicate QoS requirements to the network using RSVP, 2. Network elements enforce QoS by querying the policy server and by being provisioned by the policy server with policy control decisions. 3. RSVP mapping to 802 style LANs is provided under policy control. Authorization for QoS in the access networks is outsourced to a clearinghouse server. The clearinghouse server has several functions pertinent to call setup with QoS: Sinnreich, et al. draft-interdomain-sip-qos-osp-00.txt Page 5 Internet Draft Interdomain IP Communications October 1999 a. Trust broker between a large number of network providers, b. Optional gateway location service for IP telephony, not detailed in this document, c. Authorization for QoS, similar to VISA authorization in commerce, d. Collection of usage reports, e. Settlements between service providers, not detailed in this docu- ment. 4.2. Network Elements Terminology ISP: Internet service provider LEC: Local exchange carrier for circuit switched telephony GWY: IP telephony gateway PBX: Private branch exchange (circuit switched) Policy: Policy server using COPS R: COPS RSVP capable Router SPS: SIP Proxy Server 5.3 Protocols and Interworking Between Processes The basic components required for QoS enabled or QoS assured IP com- munications have been defined in the IETF by a series of protocols: a. Session Initiation Protocol (SIP) for call setup [2], b. Open Settlement Protocol (OSP) for authorization and usage report- ing [3], c. Common Open Policy Service (COPS) for policy deployment in network elements [4], d. Resource Reservation Protocol (RSVP) for setting up QoS in end networks [5], e. Subnet Bandwidth Manager (SBM) for setting up RSVP initiated QoS in 802.x style LANs [6]. f. Differentiated services (DiffServ) for setting up QoS traffic classes in IP backbones [7]. COPS specifically barters RSVP/SBM bandwidth requests between the enforcement points and the policy server (decision point). In the DiffServ role, COPS can be used to configure edge routers/switches to classify, meter, and mark the DiffServ traffic. Differentiated services in the backbone are presumed here for QoS assured end-to-end communications. The interworking of RSVP and dif- ferentiated services is explained in [8]. Since DiffServ in the back- bone deals only with flow aggregates and not with individual flows, Sinnreich, et al. draft-interdomain-sip-qos-osp-00.txt Page 6 Internet Draft Interdomain IP Communications October 1999 it will be assumed as existing, but will not be part in the setting up of an individual flow [9], or "call" as used in telephony termi- nology. 4.3.1. SIP, Policy, RSVP and COPS Interworking QoS can be indicated in the Session Description Protocol (SDP) part of the SIP message as described in [11]. As for policy, a new client type, Call Control, is used to support the policy requirements of the Inter-domain AAA, SIP and QoS policy. The Call Control client is the Policy Enforcement Point (PEP) on the SIP server. This client type performs both outsourcing and configura- tion operations. The Policy Decision Point (PDP) supports two differ- ent type of PEP for the Call Control client type. It administers both a SIP server PEP and a RSVP PEP. The SIP PEP outsources two different types of policy. First, the SIP PEP outsources AAA policy which the Call Services PDP resolves using a clearinghouse. Secondly, the SIP server PEP outsources configuration operations to the Call Services PDP. In the second scenario the PDP determines appropriate local decision policy for the request and provisions the RSVP PEP. The PDP formats the policy into binding based on a PIB module for the Call Control client type. Likewise the RSVP PEP installs the local deci- sion policy bindings for local policy control processing. Two events invoke the removal of local decision policy state at the RSVP PEP. The first is upon receipt of the DECISION REMOVE from the PDP. The second is when the router receives a PATHTEAR or RESVTEAR message. The local decision policy state associated with the affected Path State Block (PSB) and/or Resv State Block (RSB) is removed and the PEP reports the removal to the PDP using the RPT accounting oper- ation. The removal of local decision policy state results in the removal of the related PSB and RSB. 4.3.2 SIP and OSP Interworking A SIP server can outsource an AAA request REQ AAA to a policy server, which in turn can outsource it to another server, such as a clearing- house server using OSP. The parameters passed between the processes are illustrated here. Calling party requests authorization: From SIP to OSP to authorize a call, REQ AAA to - SIP Call ID - Called Number - Calling Number Decision from OSP to SIP, to DEC - Called Number (in case there is a number translation in the OSP server) - Authorization Token Sinnreich, et al. draft-interdomain-sip-qos-osp-00.txt Page 7 Internet Draft Interdomain IP Communications October 1999 Called party requests authorization: The called party has received an INVITE message that contains an authorization token from a server with which it has a trust relation- ship. This token will be used for usage reporting to the trusted server, to prove that it was an authorized call. From SIP to OSP to authorize an incoming call, REQ AAA to OSP - SIP Call ID - Called Number - Calling Number - Authorization Token Usage reporting: Calling and called parties request de-installation of QoS policy from the respective local policy servers. This event triggers usage reporting to the OSP server and receipt of usage report. The SIP parameters passed to the policy server in the REQ noLDP and the OSP message are: - Duration of Call - Called Number (if not cached from REQ) - Calling Number (if not cached from REQ) - SIP Call ID (if not cached from REQ) - Authorization Token. 5. Message Exchange and Inter-Process Overview The message exchanges for the protocols listed above are well docu- mented and understood when each is used in isolation. This is not the case when using them all together. We will exemplify here the inter- process dependencies when these protocols are used together for inter-domain IP communications. The sequence in the message exchanges is not arbitrary. The parame- ters communicated in a previous message are used in the follow-up message. For example the origination and destination URLs in the ini- tial INVITE message are used for authorizing the call. The authoriza- tion token is then used to establish/install policy in the network, etc. We will assume that before initiating a call, both the SIP client and the user have been authenticated. Client and user authentication for SIP initiated IP communications are described in [9] and will not be repeated here. 5.1 Overview The rough sequence of messages required to set up an inter-domain communication involves the following: Sinnreich, et al. draft-interdomain-sip-qos-osp-00.txt Page 8 Internet Draft Interdomain IP Communications October 1999 5.1.1 Call Setup Request, Authorization and Policy a. SIP client (phone) requests call setup from SIP1 proxy server, b. SIP1 checks local policy server POL1, c. Local policy server checks with clearing house server CH, d. SIP1 requests call setup from remote SIP2, same events (2-3) at remote end, e. Remote policy server POL2 provisions policy for use by local policy control in edge router R2 and SIP2, f. If OK, local SIP1 gets positive call progress report from remote SIP2, g. Local policy is provisioned by POL1 in edge router R1 and proxy server SIP1, h. SIP1 informs phone of call progress. The sequence of messages belongs to several protocols: SIP, OSP, COPS, RSVP and SBM. The exact sequence is better shown in graphic format, as in Fig.2 5.1.2 QoS setup, call progress reports and acknowledgement See Fig. 3. a. SIP client requests network resources for QoS using RSVP. At the edge router, QoS for the flow is enforced per the local policy control. The specific policy for the flow was provisioned previously by the SIP outsourced request. b. Remote edge router R2 installs QoS in LAN using SBM and informs R1, c. R1 installs QoS in LAN using SBM, d. LAN QoS reservation is confirmed end-to-end in one direction, e. Same is repeated in opposite direction, f. Call progress is confirmed as "Ringing" and acknowledged back, g. Both-way RTP streaming is established, h. The parties can say "hello" and have a phone conversation. RSVP based QoS can be established independently and at the same time for both directions. Sinnreich, et al. draft-interdomain-sip-qos-osp-00.txt Page 9 Internet Draft Interdomain IP Communications October 1999 +-----+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ | SIP | |SIP| |POL| | R | |CH | | R | |POL| |SIP| |GWY| |Phone| | 1 | | 1 | | 1 | | | | 2 | | 2 | | 2 | | | +-----+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ | 1 | | | | | | | | |INVITE | 2 | | | | | | | |------>|REQ A | 3 | | | | | | |----->| | | | | | | | |------------>| | | | | | | | 4 | | | | | | | | | | | | | | | 5 |<------------| | | | | | | DEC | | 6 | | | | | |<-----| | INVITE | | | | | |---------------------------------------->| | | | | | | | 7 | | | | | | | 8 |REQ A | | | | | | | |<-----| | | | | | |<------------| | | | | | | | 9 | | | | | | | |------------>| | | | | | | | | |10 DEC| | | | | | | | |----->| 11 | | | | | | | | |INVITE| | | | | | | | |----->| | | | | | | | |12 180| | | | | | | | 13 |<-----| | | | | | | 14 |REQ LDP | | | | | | | DEC |<-----| | | | | | | |<-----| | | | | | | | | 15 | | | | | | | | | RPT | 16 | | | | | | | |----->| DEC | | | | | | 17 180 | |----->| | | |<----------------------------------------| | - continue call setup - Fig.2 Call setup, authorization and policy installation - call setup continued - Sinnreich, et al. draft-interdomain-sip-qos-osp-00.txt Page 10 Internet Draft Interdomain IP Communications October 1999 +-----+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ | SIP | |SIP| |POL| | R | |CH | | R | |POL| |SIP| |GWY| |Phone| | 1 | | 1 | | 1 | | | | 2 | | 2 | | 2 | | | +-----+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ | | | | | | | | | | 23 PATH/SBM | 24 PATH | 25 PATH/SBM | |====================>|------------>|===================>| | | | | | | | | | | 28 RESV/SBM | 27 RESV | 26 RESV/SBM | |<====================|<------------|<===================| | | | | | | | | | | 29 RESV-CONF/SBM |30 RESV-CONF | 31 RESV-CONF/SBM | |====================>|------------>|===================>| | | | | | | | | | | 34 PATH/SBM | 33 PATH | 32 PATH/SBM | |<====================|<------------|<===================| | | | | | | | | | | 35 RESV/SBM | 36 RESV | RESV/SBM | | |====================>|------------>|===================>| | | | | | | | | | | 40 RESV-CONF/SBM |39 RESV-CONF | 38 RESV-CONF/SBM | |<====================|<------------|<===================| | | | | | | | | 41 | | | | | | | | |200 OK| | 43 | | 42 200 OK | | |<-----| | 200 OK|<----------------------------------------| | |<------| | | | | | | | | | | | | | | | | |44 ACK | | | | | | | | |------>| | | 45 ACK | | | | | |---------------------------------------->|46 ACK| | |----->| | Hello! (RTP established both way) | | |<======================================================>| Figure 3 QoS setup and completing the call 5.1.3 RSVP Initiated QoS Teardown See Fig. 4. a. Client sends PATHTEAR message. PATHTEAR is propagated to remote gateway, b. QoS is de-installed by router R1 in local LAN, c. Local accounting report for removal of policy (if real-time usage reporting is needed that can be used for usage as well) is pro- vided by router R1 to server POL1, d. RSVP path teardown is signaled to remote gateway, e. Remote accounting report is provided by router R2 to server POL2, f. QoS resources are released in remote LAN, g. Router R2 provides remote accounting report to server POL2. Sinnreich, et al. draft-interdomain-sip-qos-osp-00.txt Page 11 Internet Draft Interdomain IP Communications October 1999 Note: The teardown of RSVP state may be initiated outside of the SIP signaling mechanism. In this scenario the media traffic can continue to traverse the network but it no longer has a guaranteed reservation for QoS. +-----+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ | SIP | |SIP| |POL| | R | |CH | | R | |POL| |SIP| |GWY| |Phone| | 1 | | 1 | | 1 | | | | 2 | | 2 | | 2 | | | +-----+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ | | | | | | | | | | | Established Call | | | |<======================================================>| | | | | | | | | | | 1 PATHTEAR/SBM | | | | | | |====================>| 2 PATHTEAR | | | | | | | |------------>| 3 PATHTEAR/SBM | | | |4 RTP | | |===================>| | | |<-----| | | | | | | 5 PATHTEAR SBM | | | | | | |<====================| 6 RESTEAR | | | | | | | |------------>|7 RPT | | | | | | | | |----->| | | | | | | 8 PATHTEAR | | | | | | | |<------------| 9 RESVTEAR/SBM | | | | | | |===================>| Figure 4. RSVP teardown signaling and release of QoS resources 5.1.4 Generic QoS Usage Reporting to Clearing House a. Usage is reported by POL1 server to clearing house server, b. Usage report is confirmed to POL1, c. Usage is reported by POL2 server to clearing house server, d. Usage report is confirmed to POL2. +---+ +---+ +---+ +---+ +---+ |POL| | R | |CH | | R | |POL| | 1 | | 1 | | | | 2 | | 2 | +---+ +---+ +---+ +---+ +---+ | | | | | | | | | | |1 | | | |------------>|3 | | | |<------------| |2 | | | |<------------| | | | | |4 | | | |------------>| Figure 5 QoS Usage Reporting to clearing house Sinnreich, et al. draft-interdomain-sip-qos-osp-00.txt Page 12 Internet Draft Interdomain IP Communications October 1999 The generic teardown of resources for QoS and usage reporting shown in the previous paragraphs has to be linked to the termination of the call. The more complex message exchanges are shown in the following paragraphs. 5.1.5 Call Teardown with Background Usage Update The call and QoS teardown can be accomplished independent of usage reporting. After the call has been finished, usage reporting to the clearinghouse can be accomplished, not necessarily in real time. Fig. 6 shows the complete message sequence. Sinnreich, et al. draft-interdomain-sip-qos-osp-00.txt Page 13 Internet Draft Interdomain IP Communications October 1999 +-----+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ | SIP | |SIP| |POL| | R | |CH | | R | |POL| |SIP| |GWY| |Phone| | 1 | | 1 | | 1 | | | | 2 | | 2 | | 2 | | | +-----+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ | | | | | | | | | | | | | Good Bye! | | | | |<======================================================>| | | | | | | | | | |1 BYE | | | | | | | | |------>| | | 2 BYE | | | | | 4 |---------------------------------------->|3 BYE | |400 OK | 5 | | | | | |----->| |<------|REQ noLDP | | | | | | | |----->|6 DEC Rem | | | | | | | |----->| | | | | | | | | | | | | | | | | |7 RPT | | | | | | | |8 DEC |<-----| | | | | | | |<-----| | 9 PATHTTEAR | | | | | | | |------------>| | | | | 10 RESVTEAR/SBM | | | | | | |<====================| | | | | | | | | | | | | | | | 11 PATHTEAR/SBM | | | | | | |<====================| 12 RESVTEAR | | | 13 | | | | |------------>| | |400 OK| | | | | | | | |<-----| | | | | 14 400 OK | | | | | |<----------------------------------------| | | | | | | | | 15 | | | | | | | | 16 |REQ noLDP | | | | | | DEC Rem |<-----| | | | | | | |<-----| | | | | | | | | 17 | | | | | | | | | RPT | 18 | | | | | | | |----->| DEC | | | | | | | | |----->| | | | | 20 RESVTEAR | | | | | | |<-------------------| | | | | | | | | | 22 RESVTEAR/SBM | | 23 | | 21 PATHTEAR |===================>| |400 OK | |<-------------------| 22 RESVTEAR/SBM | |<------| | | | |===================>| Fig. 6 Call teardown with background usage update Sinnreich, et al. draft-interdomain-sip-qos-osp-00.txt Page 14 Internet Draft Interdomain IP Communications October 1999 5.1.6. Call Teardown with Real-Time Usage Update Real-time usage reporting can support instant settlement of charges, but adds OSP usage reporting messages to the teardown message exchange as shown in Fig. 7. Sinnreich, et al. draft-interdomain-sip-qos-osp-00.txt Page 15 Internet Draft Interdomain IP Communications October 1999 +-----+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ | SIP | |SIP| |POL| | R | |CH | | R | |POL| |SIP| |GWY| |Phone| | 1 | | 1 | | 1 | | | | 2 | | 2 | | 2 | | | +-----+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ | | | | | | | | | | | | | Good Bye! | | | | |<======================================================>| | | | | | | | | | |1 BYE | | | | | | | | |------>| | | 2 BYE | | | | 4 400 OK|---------------------------------------->|3 BYE | |<------| | | | | | |----->| | |5 REQ noLPD | | | | | | | |----->|6 DEC Rem | | | | | | | |----->| | | | | | | | |7 RTP | | | | | | | |8 DEC |<-----| | | | | | | |<-----|9 | | | | | | | |------------>| | | | | | | |10 | | | | | | | |<------------| | | | | | | | | 11 PATHTEAR | | | | | 12 RESVTEAR/SBM |------------>| | | | |<====================| | | | | | | 13 PATHTEAR/SBM | | | | | | |<====================| 14 RESVTEAR | | | 15 | | | |------------>| | |400 OK| | | | 16 400 OK | | |<-----| | |<----------------------------------------| | | | | | | |17 REQ noLDP | | | | | 18 DEC Rem |<-----| | | | | | |<-----| | | | | | | |19 RPT| | | | | | | |----->| | | | | | | | |20 DEC| | | | | | | |----->| | | | | | 21 | | | | | |<-------------------| | | | | | 22 | | | | | |------------------->| | | | | | 23 PATHTEAR/SBM | | | | 24 RESVTEAR |===================>| | | |<------------| | | 27 | | 25 PATHTEAR | | | 400 OK| |<------------| 26 RESVTEAR/SBM | |<------| |===================>| Figure 7. Call teardown with real-time usage update Sinnreich, et al. draft-interdomain-sip-qos-osp-00.txt Page 16 Internet Draft Interdomain IP Communications October 1999 5.2. Detailed Call Flows We provide here examples of messages by using the same numbers as in the call flow diagrams for call setup. A number of optional messages are shown here that are not shown in the diagrams. The optional mes- sages are of the type "Trying" and serve to report call progress to the client of the caller. 5.2.1 Call Setup Messages STEP 1 SIP INVITE sip:+1-972-555-5555@sip.domain2.com;user=phone SIP/2.0 Via: SIP/2.0/UDP phone1.domain1.com:5060 From: Henry Sinnreich To: Callid: 123456@domain1.com Cseq: 1 INVITE Contact: phone1.domain1.com SDP QOS required STEP 2 COPS REQ OSP = (Common Header, Client Handle, Context, ClientSI: OSP) Client Handle = "123456@domain1.com" Context = "Incoming & Outgoing", "OSP" ClientSI: OSP = (Called Number, Calling Number) Called Number = "To: " Calling Number = "From: Henry Sinnreich henry.sinnreich@phone1.domain1.com" STEP 3 OSP 1999-10-24T17:03:00Z YT64VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756t henry.sinnreich@phone1.domain1.com 19725555555 Sinnreich, et al. draft-interdomain-sip-qos-osp-00.txt Page 17 Internet Draft Interdomain IP Communications October 1999 5 STEP 4 OSP 1999-10-24T17:03:01Z 200 success 67890987 [172.16.1.2]:112 YT64VqpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756t HGTrfvbnjn8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfH 6ghyHhHUujpfyF47GhIGfHfYT64VQbnj 1999-04-24T17:01:01Z 1998-04-24T17:11:01Z YT64VqpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756t 24 3600 Sinnreich, et al. draft-interdomain-sip-qos-osp-00.txt Page 18 Internet Draft Interdomain IP Communications October 1999 s STEP 5 COPS DEC = (Common Header, Client Handle, Context, Decision Flag,Decision: ClientSI Data: OSP) Client Handle = "123456@domain1.com" Context = "Incoming & Outgoing" Decision Flag = "Install" Decision: ClientSI Data: OSP = (Called Number, Authorization Token) Called Number = "To: " Authorization Token = " YT64VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756t HGTrfvbnjn8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfH 6ghyHhHUujpfyF47GhIGfHfYT64VQbnj " Optional SIP SIP/2.0 100 Trying Via: SIP/2.0/UDP phone1.domain1.com:5060 From: Henry Sinnreich To: Callid: 123456@domain1.com Cseq: 1 INVITE STEP 6 SIP INVITE sip:+1-972-555-5555@sip.domain2.com;user=phone SIP/2.0 Via: SIP/2.0/UDP sip.domain1.com:5060 Via: SIP/2.0/UDP phone1.domain1.com:5060 From: Henry Sinnreich To: Callid: 123456@domain1.com Cseq: 1 INVITE Contact: phone1.domain1.com Record-Route: sip.domain1.com SDP QOS required STEP 7 COPS Sinnreich, et al. draft-interdomain-sip-qos-osp-00.txt Page 19 Internet Draft Interdomain IP Communications October 1999 REQ OSP = (Common Header, Client Handle, Context, ClientSI: OSP) Client Handle = "123456@domain1.com" Context = "Incoming & Outgoing", "OSP" ClientSI: OSP = (Called Number, Calling Number, Authorization Token) Called Number = "To: " Calling Number = "From: Henry Sinnreich henry.sinnreich@phone1.domain1.com" Authorization Token = " YT64VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756t HGTrfvbnjn8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfH 6ghyHhHUujpfyF47GhIGfHfYT64VQbnj " STEP 8 OSP See Message 3 STEP 9 OSP See Message 4 STEP 10 COPS See Message 5 Optional SIP SIP/2.0 100 Trying Via: SIP/2.0/UDP sip.domain1.com:5060 Via: SIP/2.0/UDP phone1.domain1.com:5060 From: Henry Sinnreich To: Callid: 123456@domain1.com Cseq: 1 INVITE SIP/2.0 100 Trying STEP 11 SIP INVITE sip:+1-972-555-5555@gw972.domain2.com;user=phone SIP/2.0 Via: SIP/2.0/UDP sip.domain2.com:5060 Via: SIP/2.0/UDP sip.domain1.com:5060 Via: SIP/2.0/UDP phone1.domain1.com:5060 From: Henry Sinnreich To: Callid: 123456@domain1.com Cseq: 1 INVITE Contact: phone1.domain1.com Record-Route: sip.domain1.com, sip.domain2.com SDP QOS required Optional SIP Sinnreich, et al. draft-interdomain-sip-qos-osp-00.txt Page 20 Internet Draft Interdomain IP Communications October 1999 SIP/2.0 100 Trying Via: SIP/2.0/UDP sip.domain2.com:5060 Via: SIP/2.0/UDP sip.domain1.com:5060 Via: SIP/2.0/UDP phone1.domain1.com:5060 From: Henry Sinnreich To: Callid: 123456@domain1.com Cseq: 1 INVITE STEP 12 SIP SIP/2.0 183 Session Progress Via: SIP/2.0/UDP sip.domain2.com:5060 Via: SIP/2.0/UDP sip.domain1.com:5060 Via: SIP/2.0/UDP phone1.domain1.com:5060 From: Henry Sinnreich To: ;tag=134159 Callid: 123456@domain1.com Cseq: 1 INVITE SDP QOS required STEP 13 COPS REQ LDP= (Common Header, Client Handle, Context, ClientSI: ConfigLocalPolicy) Client Handle = "123456@domain1.com" Context = "Configuration Request" ,"ConfigLocalDecisionPolicy" ClientSI: ConfigLocalDecisionPolicy = ( Caller Media Address, Caller Media Port, Caller SDP info, Callee Media Address, Callee Media Port, Callee SDP info) STEP 14 COPS DEC = (Common Header, Client Handle) (Decision) | (Error) Client Handle = "R1001" Decision = (Context, Decision Flag, Named Decision Data: Config Local DecisionPolicy) Context = "Configuration Request", "ConfigLocalDecisionPolicy" Decision Flag = "Install" Named Decision Data: (Binding Count, PRID, BPD) Binding Count = 1 PRID = "1.2.3.4" BPD = (Ace of Caller flow, Caller Token rate, Caller Peak rate, Caller Token Bucket Size, Caller Min Policed Unit, Caller Max Packet Size, Caller Reservation Style, Caller DSCLASS, Caller POLICY) | (Ace of Callee flow, Callee Token rate, Callee Peak rate, Callee Token Bucket Size, Callee Min Policed Unit, Callee Max Packet Size, Callee Reservation Style, Callee DSCLASS, Callee POLICY) Sinnreich, et al. draft-interdomain-sip-qos-osp-00.txt Page 21 Internet Draft Interdomain IP Communications October 1999 STEP 15 COPS RPT = (Common Header, Client Handle, Report-Type, ClientSI: ConfigRPT) Client Handle = "PEP1001 Report-Type = "Installed" ClientSI = (PRID) PRID = "1.2.3.4" STEP 16 COPS DEC = (Common Header, Client Handle, Context, Decision Flags) Client Handle = "123456@domain1.com" Context = "Incoming&Outgoing","ConfigLocalDecisionPolicy" Decision Flag = "Install" STEP 17 SIP SIP/2.0 183 Session Progress Via: SIP/2.0/UDP sip.domain1.com:5060 Via: SIP/2.0/UDP phone1.domain1.com:5060 From: Henry Sinnreich To: ;tag=134159 Callid: 123456@domain1.com Cseq: 1 INVITE SDP QOS required STEP 18 COPS See Message 13. STEP 19 COPS See Message 14. STEP 20 COPS See Message 15. STEP 21 COPS See Message 16. STEP 22 SIP Sinnreich, et al. draft-interdomain-sip-qos-osp-00.txt Page 22 Internet Draft Interdomain IP Communications October 1999 SIP/2.0 183 Session Progress Via: SIP/2.0/UDP phone1.domain1.com:5060 From: Henry Sinnreich To: ;tag=134159 Callid: 123456@domain1.com Cseq: 1 INVITE SDP QOS required STEP 23 RSVP PATH = (Common Header, [INTEGRITY], SESSION, RSVP_HOP, TIME_VALUES, [ (POLICY_DATA) +], [sender descriptor] sender descriptor = (SENDER_TEMPLATE,SENDER_TSPEC, [ADSPEC] ) Note: Messages 23 - 31 are for Caller to Callee flow. STEP 24 RSVP See Message 23. STEP 25 RSVP See Message 23. STEP 26 RSVP RESV = ( Common Header, [INTEGRITY], SESSION, RSVP_HOP, TIME_VALUES, [RESV_CONFIRM], [SCOPE] , [(POLICY_DATA) + ] STYLE, flow descriptor list) STEP 27 RSVP See Message 26. STEP 28 RSVP See Message 27. STEP 29 RSVP RESV-CONF = (Common Header, [INTEGRITY], SESSION, ERROR_SPEC, RESV_CONFIRM, STYLE, flow descriptor list ) STEP 30 RSVP See Message 29. STEP 31 RSVP Sinnreich, et al. draft-interdomain-sip-qos-osp-00.txt Page 23 Internet Draft Interdomain IP Communications October 1999 See Message 29. STEP 32 RSVP See Message 23. Note: Messages 32 - 40 are for the Callee to Caller Flow. STEP 33 RSVP See Message 23. STEP 34 RSVP See Message 23. STEP 35 RSVP See Message 26. STEP 36 RSVP See Message 26. STEP 37 RSVP See Message 26. STEP 38 RSVP See Message 29. STEP 39 RSVP See Message 29. STEP 40 RSVP See Message 29. STEP 41 SIP Sinnreich, et al. draft-interdomain-sip-qos-osp-00.txt Page 24 Internet Draft Interdomain IP Communications October 1999 SIP/2.0 200 OK Via: SIP/2.0/UDP sip.domain2.com:5060 Via: SIP/2.0/UDP sip.domain1.com:5060 Via: SIP/2.0/UDP phone1.domain1.com:5060 From: Henry Sinnreich To: ;tag=134159 Callid: 123456@domain1.com Cseq: 1 INVITE Contact: 972gw.domain2.com Record-Route: sip.domain1.com, sip.domain2.com SDP (Optional) STEP 42 SIP SIP/2.0 200 OK Via: SIP/2.0/UDP sip.domain1.com:5060 Via: SIP/2.0/UDP phone1.domain1.com:5060 From: Henry Sinnreich To: ;tag=134159 Callid: 123456@domain1.com Cseq: 1 INVITE Contact: 972gw.domain2.com Record-Route: sip.domain1.com, sip.domain2.com SDP (Optional) STEP 43 SIP SIP/2.0 200 OK Via: SIP/2.0/UDP phone1.domain1.com:5060 From: Henry Sinnreich To: ;tag=134159 Callid: 123456@domain1.com Cseq: 1 INVITE Contact: 972gw.domain2.com Record-Route: sip.domain1.com, sip.domain2.com SDP (Optional) STEP 44 SIP ACK sip.domain1.com SIP/2.0 Via: SIP/2.0/UDP phone1.domain1.com:5060 From: Henry Sinnreich To: ;tag=134159 Callid: 123456@domain1.com Cseq: 1 INVITE Route: sip.domain2.com, gw972.domain2.com SDP (Optional) STEP 45 SIP Sinnreich, et al. draft-interdomain-sip-qos-osp-00.txt Page 25 Internet Draft Interdomain IP Communications October 1999 ACK sip.domain2.com SIP/2.0 Via: SIP/2.0/UDP sip.domain1.com:5060 Via: SIP/2.0/UDP phone1.domain1.com:5060 From: Henry Sinnreich To: ;tag=134159 Callid: 123456@domain1.com Cseq: 1 INVITE Route: gw972.domain2.com SDP (Optional) STEP 46 SIP ACK gw972.domain2.com SIP/2.0 Via: SIP/2.0/UDP sip.domain2.com:5060 Via: SIP/2.0/UDP sip.domain1.com:5060 Via: SIP/2.0/UDP phone1.domain1.com:5060 From: Henry Sinnreich To: ;tag=134159 Callid: 123456@domain1.com Cseq: 1 INVITE SDP (Optional) 5.2.2 Call Teardown Messages with Background Usage Update The message numbers correspond to those in the call flow diagrams for teardown in Figure 6. STEP 1 SIP BYE sip.domain1.com SIP/2.0 Via: SIP/2.0/UDP phone1.domain1.com:5060 From: Henry Sinnreich To: ;tag=134159 Callid: 123456@domain1.com Cseq: 1 INVITE Route: sip.domain2.com, gw972.domain2.com STEP 2 SIP BYE sip.domain2.com SIP/2.0 Via: SIP/2.0/UDP sip.domain1.com:5060 Via: SIP/2.0/UDP phone1.domain1.com:5060 From: Henry Sinnreich To: ;tag=134159 Callid: 123456@domain1.com Cseq: 1 INVITE Route: gw972.domain2.com Sinnreich, et al. draft-interdomain-sip-qos-osp-00.txt Page 26 Internet Draft Interdomain IP Communications October 1999 STEP 3 SIP BYE gw972.domain2.com SIP/2.0 Via: SIP/2.0/UDP sip.domain2.com:5060 Via: SIP/2.0/UDP sip.domain1.com:5060 Via: SIP/2.0/UDP phone1.domain1.com:5060 From: Henry Sinnreich To: ;tag=134159 Callid: 123456@domain1.com Cseq: 1 INVITE STEP 4 COPS REQ noLDP= (Common Header, Client Handle, Context ) Client Handle = "123456@domain1.com" Context = "Incoming&Outgoing", "RemoveLocalDecisionPolicy" STEP 5 COPS DEC = (Common Header, Client Handle, Decision) | (Error) Client Handle = "R1001" Decision = (Context, Decision Flag, Named Decision Data: Remove Local DecisionPolicy) Context = "Configuration Request" Decision Flag = "Remove" Named Decision Data: (Binding Count, PRID) Binding Count = 1 PRID = 1.2.3.4 STEP 6 COPS RPT = (Common Header, Client Handle, Report-Type, ClientSI: UsageRPT) Client Handle = "PEP1001 Report-Type = "Installed" ClientSI = (PRID, Usage) PRID = "1.2.3.4" Usage = Timestamp, Packet Count, QoS Usage Level STEP 7 COPS DEC = (Common Header, Client Handle, Context, Decision Flags) Client Handle = "123456@domain1.com" Context = "Incoming&Outgoing","RemoveLocalDecisionPolicy" Decision Flag = "Install" STEP 8 RSVP Sinnreich, et al. draft-interdomain-sip-qos-osp-00.txt Page 27 Internet Draft Interdomain IP Communications October 1999 PATHTEAR = (Common Header, [INTEGRITY], SESSION, RSVP_HOP, [sender descriptor] Note: Message 8 - 9 are for the caller to callee flow. STEP 9 RSVP RESVTEAR = ( Common Header, [INTEGRITY], SESSION, RSVP_HOP, [SCOPE] STYLE, flow descriptor list) STEP 10 RSVP See Message 8. Note: Message 10 - 11 are for the callee to caller flow. STEP 11 RSVP See Message 9. STEP 12 SIP SIP/2.0 200 OK Via: SIP/2.0/UDP sip.domain1.com:5060 Via: SIP/2.0/UDP phone1.domain1.com:5060 From: Henry Sinnreich To: ;tag=134159 Callid: 123456@domain1.com Cseq: 1 INVITE STEP 13 SIP SIP/2.0 200 OK Via: SIP/2.0/UDP phone1.domain1.com:5060 From: Henry Sinnreich To: ;tag=134159 Callid: 123456@domain1.com Cseq: 1 INVITE STEP 14 COPS See Message 4. STEP 15 COPS See Message 5. STEP 16 COPS Sinnreich, et al. draft-interdomain-sip-qos-osp-00.txt Page 28 Internet Draft Interdomain IP Communications October 1999 See Message 6. STEP 17 COPS See Message 7. STEP 18 RSVP See Message 8. STEP 19 RSVP See Message 9. STEP 20 RSVP See Message 10. STEP 21 RSVP See Message 11. STEP 22 SIP SIP/2.0 200 OK Via: SIP/2.0/UDP sip.domain2.com:5060 Via: SIP/2.0/UDP sip.domain1.com:5060 Via: SIP/2.0/UDP phone1.domain1.com:5060 From: Henry Sinnreich To: ;tag=134159 Callid: 123456@domain1.com Cseq: 1 INVITE 5.2.3 OSP Messages for Usage Recording The OSP message numbers correspond to those in Figure 7. STEP 9 OSP 1999-10-24T22:03:00Z source 67890987 Sinnreich, et al. draft-interdomain-sip-qos-osp-00.txt Page 29 Internet Draft Interdomain IP Communications October 1999 YT64VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756t 81458811202 4766841360 [10.0.1.2]:112 10 60 s STEP 10 OSP 1999-10-24T22:44:00Z 201 new usage information created 6. Acknowledgements Sinnreich, et al. draft-interdomain-sip-qos-osp-00.txt Page 30 Internet Draft Interdomain IP Communications October 1999 We would like to thank Richard Wilder from MCI WorldCom for the insight into the relationship between end-to-end RSVP signaling between clients in the access networks, RSVP aggregation by the edge router and Differentiated Services in the backbone network. David Durham from Intel has made valuable suggestions regarding COPS and SBM. 7. References [1] RFC 2543 , SIP: Session Initiation Protocol by M. Handley, H. Schulzrinne, E. Schooler and J. Rosenberg. ftp://ftp.isi.edu/in-notes/rfc2543.txt [2] European Telecommunications Standards Institute. "Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON); Inter- domain pricing, authorization, and usage exchange". Technical Speci- fication 101 321 version 1.4.2, December 1998. [3] The COPS (Common Open Policy Service) Protocol by Jim Boyle, Ron Cohen, David Durham, Shai Herzog, Raju Rajan and Arun Sastry. Inter- net-Draft, work in progress, August 1999 http://ietf.org/internet-drafts/draft-ietf-rap-cops-07.txt [4] RFC 2210, The Use of RSVP with IETF Integrated Services by J. Wro- clawski, September 1997. ftp://ftp.isi.edu/in-notes/rfc2210.txt [5] SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission Control over IEEE 802-style networks by Raj Yavatkar, Don Hoffman, Yoram Bernet, Fred Baker and Michael Speer. Internet-Draft, work in progress, May 1999. http://ietf.org/internet-drafts/draft-ietf-issll-is802-sbm-08.txt [6] RFC 2474: Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers by K. Nichols, S. Blake, F. Baker, abd D. Black, December 1998. ftp://ftp.isi.edu/in-notes/rfc2474.txt [7] A Framework For Integrated Services Operation Over Diffserv Networks by Y. Bernet, R. Yavatkar, P. Ford, F. Baker, L. Zhang, M. Speer, R. Braden, B. Davie, J. Wroclawski, and E. Felstaine. Internet-Draft, work in progress, September 1999. http://ietf.org/internet-drafts/draft-ietf-issll-diffserv-rsvp-03.txt [8] SIP Telephony Service Examples With Call Flows by Robert Sparks, Steve Donovan, Chris Cunningham, Alan Johnston and Kevin Summers. Sinnreich, et al. draft-interdomain-sip-qos-osp-00.txt Page 31 Internet Draft Interdomain IP Communications October 1999 Internet-Draft, work in progress, October 1999. [9] Aggregation of RSVP for Ipv4 and Opv6 Reservations by Fred baker, Carol Iturralde, Fancois Le Faucheur, Bruce Davis. Internet-Draft, work in progress, September 1999. http://www.ietf.org/internet-drafts/draft-ietf-issll-rsvp-aggr-00.txt [10] Establishing QoS and Security Preconditions for SDP Sessions by J. Rosenberg, H. Schulzrinne, S. Donovan. Internet-Draft, work in progress, January 1999. http://ietf.org/internet-drafts/draft-ietf-mmusic-sdp-qos-00.txt 8. Authors' Addresses Henry Sinnreich MCI WorldCom 400 International Parkway Richardson, Texas 75081 e-mail: henry.sinnreich@wcom.com Steve Donovan MCI WorldCom 901 International Parkway Richardson, Texas 75081 e-mail: steve.donovan@wcom.com Diana Rawlins MCI WorldCom 901 International Parkway Richardson, Texas 75081 e-mail: diana.rawlins@wcom.com Stephen Thomas TransNexus 430 Tenth Street NW Suite N-204 Atlanta, Georgia e-mail: stephen.thomas@transnexus.com Sinnreich, et al. draft-interdomain-sip-qos-osp-00.txt Page 31