Internet Engineering Task Force H. Sinnreich Internet Draft D. Rawlins Document: A. Johnston draft-sinnreich-aaa-interdomain-sip-qos-osp-00.txt WorldCom July 2000 S. Donovan Expires: January 2001 dynamicsoft AAAarch WG S. Thomas TransNexus AAA Usage for IP Telephony with QoS Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026[1]. 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." 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. Abstract This draft specifies the AAA functions and message exchanges for interdomain SIP telephony call setup with QoS. Usage accounting is provided with clearing house support using the Open Settlement Protocol. Interdomain message exchanges use existing IETF protocols. The use of existing protocols is however modeled in the proposed AAA Architecture of the IETF AAAArch RG [1]. Though the approach has been developed specifically for IP telephony, using the AAA Architecture may allow a future AAA protocol to go beyond IP telephony to serve alike for other applications. Sinnreich, et al. [Page 1] Internet Draft AAA Usage for IP Telephony with QoS July 2000 Table of Contents 1. Introduction 2 2. Model 2 3. AAA Functions 3 3.1. Authorization for the Application 5 3.2. Authorization for Network Quality of Service 5 Policy Push Model 6 Policy Pull Model 6 4. Protocols 6 5. Conditional and Unconditional QoS Setup 6 QoS Assured Calls 6 QoS Enabled Calls 6 6. Network Elements 7 7. Interdomain AAA Functions 7 8. SIP-OSP-RSVP Messages 9 9. Acknowledgements 15 10. References 15 Authors' Addresses 16 1. Introduction Interdomain IP telephony is accomplished today using clearinghouse services and a mix of proprietary and standard AAA protocols. Making calls with AAA support between service providers that are affiliated to different clearinghouses is a difficult problem. Beyond IP telephony it is also desirable to have a consistent AAA approach for all applications on the Internet. Work on a general architecture for AAA is proceeding in the IETF AAAarch research group. A framework [2] and examples [3] have been developed for various Internet applications. At the same time, Internet telephone calls can be set up with QoS and security [5], [6]. Since QoS is a valuable network resource, it requires AAA and possibly payments. This has been discussed in [7] and detailed message exchanges showing the coupling between call setup with QoS setup and AAA have been developed in [8]. We propose to use existing IETF protocols and proposals in Internet Drafts for interdomain IP telephony calls with QoS as a first step toward a uniform AAA approach. The approach outlined here may be useful later for developing a uniform AAA architecture and protocols for other application layer services. 2. Model Figure 1 shows the model for an interdomain phone call across the Internet with the various entities having business relationships, but not necessarily trust relationships with their correspondents: Sinnreich, et al. Informational [Page 2] Internet Draft AAA Usage for IP Telephony with QoS July 2000 Clearinghouse +------+------+ +------+ +------+------+ |Policy| OSP | SIP | OSP | SIP | OSP |Policy| |Server|Client|<--->|Server|<--->|Server|Server| +------+------+ +------+ +------+------+ | | | | Domain 1 | +-----+ +----+ | Domain 2 | | | | +-----+ | | +-----+ | PEP | | | | PEP | +-----+ +-----+ | | +-----+ +-----+ | SIP |SIP | SIP | | | | SIP |SIP | SIP | | UAC |<-->|Proxy| | | |Proxy|<-->| GC | +-----+ +-----+ | | +-----+ +--+--+ | | | | | | SIP | | | Phone +------+ +------+ +--+--+ +------+ | Edge | RSVP | Edge | | | | RSVP | RSVP |Router| tunnel |Router| RSVP | MG | | Host |<-------->| |<---------------->| |<---------->| | +------+ +------+ Transit Nets +------+ +-----+ Figure 1: Model for interdomain phone call - IP endpoints, SIP phone and IP telephony gateway, - Service providers, for SIP and QoS in this context. The domains can belong to service providers or enterprise networks, - Clearinghouse acting as trust broker between domains, - Internet transit networks providing bulk QoS transport between domains that service IP communications endpoints. 3. AAA Functions We will review here the AAA functions required for end-to-end QoS for the phone call. Authentication has to be provided between the following: - Devices such as SIP phones, to service provider, - End user to service provider, - Service providers to clearinghouse. Interdomain authorization relies on a clearinghouse service. The Open Settlement Protocol (OSP) can be used by IP telephony service providers for both authorization and accounting. Long term business relationships such as between - IP telephony gateway operators and service providers, and between - service providers and transit networks Sinnreich, et al. Informational [Page 3] Internet Draft AAA Usage for IP Telephony with QoS July 2000 are secured by other means. Such means can be physical links and Service Level Specifications (SLS), monitored at the network interfaces. Domain level security such as between SIP servers and between policy servers and routers are shown in Figure 1 for exemplification but are not considered here any further. Random phone calls between domains are however micro-events to which the present AAA discussion applies. Note that authentication for endpoints, such as IP phones and computers has to happen separately at the application level, SIP signaling in this case, and at the transport level for QoS. By proper design of the telephony applications in the endpoints however, the RSVP host can benefit from authentication at the SIP level, so as to make RSVP setup transparent to the user. We have assumed here the use of RSVP for microflows of individual phone calls. RSVP may however be aggregated to Differentiated Services QoS in the transit network. This aggregation is performed in the edge router. Authorization for interdomain calls is a multistage process, across multiple servers, and using different protocols in the flow for authorization. Figure 2 shows the authorization chain for an interdomain phone call. We assume distinctive AAA processes for - Network access, not shown in Fig. 2 - Application service - call setup - 1a to 6a, - Policy - 1p to 2 p, - Network service (QoS) - 1q to 4q. - The Directory is shown for completeness Note that local authorization depends on servers outside the domain of the calling party: The OSP server authorizes SIP call setup, while the RSVP guaranteed reservation for the media stream depends on the RSVP admission policy per each domain. While the near term approach used here with existing protocols can work well, requirements for a next generation AAA protocol [4] requires these distinctions to be hidden from the end user, so for example, only one single log-on should be required, and one AAA protocol to be applicable for all services. Notice in Figure 2 the authorization process involves various types of servers with multiple protocols deployed: SIP, OSP, COPS and RSVP. Sinnreich, et al. Informational [Page 4] Internet Draft AAA Usage for IP Telephony with QoS July 2000 +-------------------------+ | | +-----+ 1a +-----+ 2a +-------+ | 3a +--------+ | SIP |------->| SIP |------>| AAA |------>| Inter- | | UAC |<-------| UAS |<------| and |<------| Domain | +-----+ 6a +-----+ 5a | Policy| | 4a | AAA | | +-------+ | +--------+ | | ^ | IP | Domain of | | | Communication |Service Provider | | | Client | | | | | 1p| |2p | | | | | +------+ | 1q +------+ | 2q | RSVP |-------------------->| RSVP |----------------> | Host |<--------------------|Router|<---------------- +------+ | 4q +------+ | 3q | | +-------------------------+ Figure 2: Authorization links for a phone call with QoS 3.1. Authorization for the Application The IP communications client, that is the User Agent Client (UAC) requests the telephony session with QoS from the SIP User Agent Server (UAS). The SIP UAS may check the user credentials referring to a user directory. The UAS forwards the request to the AAA and policy server. The AAA and policy server may check a policy database, and possibly also a bandwidth manager for the domain, to make sure bandwidth is still available to support the call. If all the local checks produce affirmative results, the request is now forwarded to the interdomain AAA server belonging to a clearinghouse service provider. 3.2. Authorization for Network Quality of Service The RSVP Host function in the IP communication endpoints will request RSVP service by exchanging RSVP PATH and RESV messages under control of the communication applications. The PATH message propagates through the local routers and eventually has to pass via the edge router that enforces policy for QoS admission for the flow requested by the IP communication endpoint. Local policy in this domain is communicated to the edge router from the policy server. Likewise, the RESV message which guarantees and reserves the QoS resources, returns via the same path and passes through the same edge router that enforces QoS admission policy for the flow. Policy can be implemented in two ways: Sinnreich, et al. Informational [Page 5] Internet Draft AAA Usage for IP Telephony with QoS July 2000 Policy Push Model The policy server first installs QoS policy in the router for that particular IP endpoint as shown by the sequence of arrows 1p and 2p. Policy Pull Model The edge router queries the policy server after receiving the PATH message from the IP endpoint. There are complex design tradeoffs when to use the push model or the pull model that go beyond the scope of this memo. 4. Protocols The example shown in Fig. 2 for interdomain IP telephony shows the deployment of five existing protocols: 1. SIP - Session Initiation Protocol for the application. 2. OSP - Open Settlement Protocol for authorization of individual users 3. IPSec - IP Security for IP telephony gateway authorization. 4. COPS - Common Outsourcing Protocol Service for policy administration 5. RSVP - Resource Reservation Protocol for per flow QoS establishment 6. DiffServ _ Differentiated Services Protocol for class based QoS in transit networks. 5. Conditional and Unconditional QoS Setup Completion of the telephone call setup can be made dependent of prior QoS setup or, call setup may proceed in parallel and independently from QoS setup. Various scenarios for coupling the application for SIP call setup with network QoS setup are discussed in [5]. QoS can be made a precondition for the SDP call description, as shown in [6]. We chose here only two scenarios, covering what we believe to be important service models. QoS Assured Calls The caller will not hear ringing tone unless QoS has been successfully setup. If QoS cannot be setup, the caller will get a fast busy tone or similar indication. This type service is equivalent to present circuit switched telephony. Call setup time is longer due to dependency on QoS setup time. A system design based on QoS assured calls is given in [9]. QoS Enabled Calls Sinnreich, et al. Informational [Page 6] Internet Draft AAA Usage for IP Telephony with QoS July 2000 SIP call setup and RSVP QoS setup proceed concurrently. In case of RSVP setup failure, the caller can be notified and given the option of continuing the call with best effort service only. Call setup is shorter and the best effort call may still be useful to the end user. We believe both models of service fulfillment have commercial value, depending on the type of service and user preferences. Examples and detailed call flows for both QoS assured and QoS enabled calls are given in [8]. 6. Network Elements Notice that some network elements in Fig 2 may host more than one protocol function for end-to-end AAA: - SIP UA in SIP phone, computer or gateway, - SIP UA in SIP server, - SIP proxy in SIP servers, - RSVP Host in IP phone, computer or gateway, - RSVP Routers, - Policy Server - Policy Decision Point (PDP) - Policy Enforcement Point (PDP) in Router - OSP client - OSP server. Other placements of the above functions are also possible. What matters for interdomain AAA is only the external behavior, for the messages between domains. There are other network elements, such a layer two 802.3 LANs under SBM (Subnet Bandwidth Manager) control, but they are not seen in the interdomain model. Network elements in the transit networks are also not seen, since we assume the policy manager will accept only as many sessions with QoS as are covered by the SLS with the transit network. If one of the domains or transit networks cannot insure QoS delivery, an RSVP failure message may be made available to the call originating endpoint. 7. Interdomain AAA Functions We believe that end-to-end IP telephony with QoS across the Internet requires a standard way for interdomain AAA interactions to occur. Given the complexity of such interactions, the best way to describe them are call flows showing the external behavior across the Internet. Figure 3 shows the external behavior between domains for a QoS enabled SIP phone call. Figure 3 also does not show how QoS is set up internally in the respective domains. Reference [8] shows the complete call flows in both domains, where these functions are visible. Sinnreich, et al. Informational [Page 7] Internet Draft AAA Usage for IP Telephony with QoS July 2000 The initial INVITE from the UAC in Domain 1 is not seen in this diagram. The SIP and policy servers in Domain 1 will first query the OSP server for call authorization before proceeding with SIP call setup. For this reason, the OSP messages 1 and 2 are the first to be seen outside the domain. The SIP server in Domain 1 will forward the INVITE message 3 only after the OSP server has authorized the call. Domain 1 OSP Server Domain 2 | | | | 1 | | Domain 1 |--------------------->| | is authorized | 2 | | |<---------------------| | | 3 INVITE | |-------------------------------------------->| SIP setup | 4 183 Session Progress | D1 to D2 |<--------------------------------------------| | 5 180 Ringing | |<--------------------------------------------| | 6 200 OK | |<--------------------------------------------| | 7 ACK | |-------------------------------------------->| RSVP setup | 8 PATH | D1 to D2 |-------------------------------------------->| | 9 RESV | |<--------------------------------------------| | 10 RSV-CONF | |-------------------------------------------->| RSVP setup | 11 PATH | D2 to D1 |<--------------------------------------------| | 12 RESV | |-------------------------------------------->| | 13 RSV-CONF | |<--------------------------------------------| | RTP Flows Are Established | Call is setup |<===========================================>| SIP BYE D1-D2 | 15 BYE | |-------------------------------------------->| | 16 200 OK | |<--------------------------------------------| RSVP PATHTEAR | 17 PATHTEAR | |-------------------------------------------->| | 18 PATHTEAR | |<--------------------------------------------| OSP | 19 | | Usage |--------------------->| 21 | Reporting | 20 |<---------------------| |<---------------------| 22 | | |--------------------->| Sinnreich, et al. Informational [Page 8] Internet Draft AAA Usage for IP Telephony with QoS July 2000 Figure 3 QoS enabled interdomain SIP call setup with AAA functions The complete call flows, including the call flows within the domains are given in [8]. The call flow messages for Figure 3 are shown in the following paragraph. 8. SIP-OSP-RSVP Messages We will illustrate here the message exchange in a narrative form. When the caller in Domain 1 specifies the called party in Domain 2, a call authorization is send from Domain 1 to the clearing house, using the Open Settlement Protocol [10]: 1. OSP AuthReq 2000-07-01 T17:03:00Z YT64VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756t 1-972-555-5555 5 The clearinghouse checks the credentials and credit status of Domain 1 and returns the authorization. 2. OSP AuthRsp 2000-07-01T17:03:01Z Sinnreich, et al. Informational [Page 9] Internet Draft AAA Usage for IP Telephony with QoS July 2000 200 success 67890987 [172.16.1.2]:112 YT64VqpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756t HGTrfvbnjn8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfH 6ghyHhHUujpfyF47GhIGfHfYT64VQbnj 2000-07-01T17:03:01Z 2000-7-04T17:00:00Z YT64VqpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756t 24 3600 s The token from the authorization will be used in the SIP INVITE coming from the SIP proxy server in Domain 1 to the SIP proxy server in Domain 2.The token will also be used by the endpoint in Domain 2, the gateway to accept the SIP INVITE request and also the associated RSVP request. The IP gateway in Domain 2 will also issue and PATH Sinnreich, et al. Informational [Page 10] Internet Draft AAA Usage for IP Telephony with QoS July 2000 signal to the SIP calling SIP phone, so as to establish RSVP in the other direction. 3. SIP INVITE INVITE sip:+1-972-555-5555@sip.domain2.com;user=phone SIP/2.0 Via: SIP/2.0/UDP sip.domain1.com:5060;branch=3a56d3.1 Via: SIP/2.0/UDP phone1.domain1.com:5060 From: Henry Sinnreich To: Call-ID: 123456@domain1.com CSeq: 1 INVITE Contact: sip:henry.sinnreich@phone1.domain1.com Record-Route: OSP-Authorization-Token: _YT64VqpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756t HGTrfvbnjn8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfH 6ghyHhHUujpfyF47GhIGfHfYT64VQbnj_ Content-Type: application/sdp Content-Length: 184 v=0 o=hsinnreich 9735285123 9721273312 IN IP4 122.32.11.6 s=Discussion of SIP QoS OSP for AAAArch c=IN IP4 122.32.11.6 t=0 0 m=audio 9876 RTP/AVP 0 a=qos:mandatory recv confirm The OSP-Authorization-Token SIP header is defined in [11]. 4. SIP 183 Session Progress SIP/2.0 183 Session Progress Via: SIP/2.0/UDP sip.domain1.com:5060;branch=3a56d3.1 Via: SIP/2.0/UDP phone1.domain1.com:5060 From: Henry Sinnreich To: ;tag=54321 Call-ID: 123456@domain1.com CSeq: 1 INVITE Session: Media Content-Type: application/sdp Content-Length: 185 v=0 o=gateway 9735285165 9735285165 IN IP4 111.22.110.5 s= Discussion of SIP QoS OSP for AAAArch c=IN IP4 111.22.110.5 Sinnreich, et al. Informational [Page 11] Internet Draft AAA Usage for IP Telephony with QoS July 2000 t=0 0 m=audio 49170 RTP/AVP 0 a=qos:mandatory recv confirm RTP Media flow is established from Gateway to Caller so that Caller hears in-band alerting from PSTN such as ringtone, bustone, or recorded announcements. 5. SIP 180 Ringing SIP/2.0 180 Ringing Via: SIP/2.0/UDP sip.domain1.com:5060;branch=3a56d3.1 Via: SIP/2.0/UDP phone1.domain1.com:5060 From: Henry Sinnreich To: ;tag=54321 Call-ID: 123456@domain1.com CSeq: 1 INVITE 6. SIP 200 OK SIP/2.0 200 OK Via: SIP/2.0/UDP sip.domain1.com:5060;branch=3a56d3.1 Via: SIP/2.0/UDP phone1.domain1.com:5060 From: Henry Sinnreich To: ;tag=54321 Call-ID: 123456@domain1.com CSeq: 1 INVITE Contact: sip:+1-972-555-5555@gw1.domain2.com;user=phone Record-Route: Content-Type: application/sdp Content-Length: 185 v=0 o=gateway 9735285165 9735285165 IN IP4 111.22.110.5 s= Discussion of SIP QoS OSP for AAAArch c=IN IP4 111.22.110.5 t=0 0 m=audio 49170 RTP/AVP 0 a=qos:mandatory recv confirm Called Party answers call, so Gateway sends 200 OK to Caller to confirm call completion. 7. SIP ACK ACK sip:+1-972-555-5555@gateway.domain2.com;user=phone SIP/2.0 Via: SIP/2.0/UDP sip.domain1.com:5060;branch=3a56d3.1 Via: SIP/2.0/UDP phone1.domain1.com:5060 From: Henry Sinnreich To: ;tag=54321 Sinnreich, et al. Informational [Page 12] Internet Draft AAA Usage for IP Telephony with QoS July 2000 Call-ID: 123456@domain1.com CSeq: 1 ACK Content-Length: 0 ACK from Caller is received by Gateway to complete call setup. 15. SIP BYE BYE sip:+1-972-555-5555@gateway.domain2.com;user=phone SIP/2.0 Via: SIP/2.0/UDP sip.domain1.com:5060;branch=3a56d3.1 Via: SIP/2.0/UDP phone1.domain1.com:5060 From: Henry Sinnreich To: ;tag=54321 Call-ID: 123456@domain1.com CSeq: 2 BYE Content-Length: 0 Caller begins call teardown sequence by sending BYE to Gateway. 16. 200 OK SIP/2.0 200 OK Via: SIP/2.0/UDP sip.domain1.com:5060;branch=3a56d3.1 Via: SIP/2.0/UDP phone1.domain1.com:5060 From: Henry Sinnreich To: ;tag=54321 Call-ID: 123456@domain1.com CSeq: 2 BYE Content-Length: 0 Gateway responds to BYE with 200 OK to confirm call teardown. Media path is now terminated. After the BYE message and the completion of the call, both domains will send "call records" in the form of OSP Usage Indications and the clearinghouse will confirm the receipt in the form of Usage Confirmation. 19. UsageInd 2000-07-01T22:03:00Z source Sinnreich, et al. Informational [Page 13] Internet Draft AAA Usage for IP Telephony with QoS July 2000 67890987 YT64VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756t 81458811202 4766841360 [10.0.1.2]:112 10 60 s 20. UsageCnf 2000-07-01T22:44:00Z 201 new usage information created Sinnreich, et al. Informational [Page 14] Internet Draft AAA Usage for IP Telephony with QoS July 2000 9. Acknowledgements J. Vollbrecht and C. de Laat have pointed out the applicability of the telephony call setup model with QoS to the AAA work and have kindly encouraged us to submit this memo. 10. References [1] The home page of the IRTF AAAarch research group: http://www.phys.uu.nl/~wwwfi/aaaarch/ [2] J. Volbrecht et al.: AAA Authorization Framework. Internet Draft, March 2000. [3] J. Volbrecht et al.: AAA Authorization Examples. Internet Draft, March 2000. [4] S. Farrell et al.: AAA Authorization Requirements. Internet Draft, March 2000. [5] H. Schulzrinne, J. Rosenberg, J. Lennox: Interaction of Call Setup and Resource Reservation Protocols in Internet Telephony, Technical Report, June 15, 1999. http://www.cs.columbia.edu/~hgs/sip/papers.html [6] J. Rosenberg, H. Schulzrinne, S. Donovan: Establishing QoS and Security Preconditions for SDP Sessions. Internet Draft, June 1999, [7] H. Sinnreich, S. Donovan, D. Rawlins, S. Thomas: Quality of Service, Authorization and Accounting for Internet Telephony. Unpublished Paper, January 2000. [8] H. Sinnreich, S. Donovan, D. Rawlins, S. Thomas: "Interdomain IP Communications with QoS, Authorization and Usage Reporting", Internet Draft, February 2000, [9] W. Marshall et. al: "SIP Extensions for Media Authorization", Internet Draft, March 2000, [10] European Telecommunications Standards Institute. "Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON); Inter-domain pricing, authorization, and usage exchange". Technical Specification 101 321 version 1.4.2, December 1998. [11] A. Johnston, D. Rawlins, and H. Sinnreich, "OSP-Authorization- Token Header for SIP", Internet Draft, July 2000, Sinnreich, et al. Informational [Page 15] Internet Draft AAA Usage for IP Telephony with QoS July 2000 Sinnreich, et al. Informational [Page 16] Internet Draft AAA Usage for IP Telephony with QoS July 2000 Authors' Addresses Henry Sinnreich WorldCom 400 International Parkway Richardson, Texas 75081 USA henry.sinnreich@wcom.com Diana Rawlins WorldCom 901 International Parkway Richardson, Texas 75081 USA diana.rawlins@wcom.com Alan Johnston WorldCom 100 S. 4th Street St. Louis, Missouri 63104 USA alan.johnston@wcom.com Steve Donovan dynamicsoft 200 Executive Drive Suite 120 West Orange, NJ 07052 USA sdonovan@dynamicsoft.com Stephen Thomas TransNexus, LLC 430 Tenth Street NW Suite N-204 Atlanta, GA 30318 USA stephen.thomas@transnexus.com Copyright Notice "Copyright (C) The Internet Society 2000. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing Sinnreich, et al. Informational [Page 17] Internet Draft AAA Usage for IP Telephony with QoS July 2000 the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Sinnreich, et al. Informational [Page 18]