INTERNET DRAFT Nancy Greene Category: Nortel (Northern Telecom) Title: Fernando Cuervo Date: July 1998 Nortel (Northern Telecom) Expires: January 1998 Bi-Directional Session Setup Extension to Diameter Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract The document [1] describes an architectural framework for protocol standardization for telephony interworking with the internet. Interworking deals with both signalling and bearer connections (i.e., media stream), which can either be carried together (e.g., in-band, BRI, PRI) or separately (e.g., SS7). When signalling is carried together with the bearer connections, it arrives directly at the NAS. When signalling is carried separately, it passes through a Signalling Gateway and/or a NAS Controller before arriving at a Network Access Server (NAS). This document describes extensions to Diameter to allow session setup to occur from the NAS to the Signalling Gateway/NAS Controller, and from the Signalling Gateway/NAS Controller to a NAS. The Diameter base protocol, and other extensions to Diameter provide other aspects of the protocol required between a NAS and a Signalling Gateway/NAS Controller (for example, NAS initialization, configuration, reboot indication, session and resource management, session release)[2,3,4]. Another Diameter extension is used when user authentication and/or authorization is required [5]. Device Management and Maintenance functions such as channel blocking, continuity test and other device control functions pertinent to particular signalling gateways, e.g. SS7 signalling gateways, can be implemented using the messages described in this Diameter extension. The AVPs necessary for this will be defined in another Diameter extension. Table of Contents 1.0 Introduction 2.0 Terminology 3.0 Relationship with Diameter Base Protocol and other extensions 4.0 Session setup messages Signalling Gateway/NAS Controller (SGNC) <-> NAS interaction 4.1 Session-Setup-Request 4.2 Session-Setup-Response 4.3 Resource-Add-Request 4.4 Resource-Add-Response 5.0 Attribute AVPs 6.0 Security Considerations 7.0 Example message exchanges for SS7 session setup 7.1 SS7 Session Setup originating from SGNC 7.2 SS7 Session Setup originating from NAS 7.3 SS7 Session Setup from SGNC to NAS, with successful Continuity test 7.4 SS7 Session Setup from SGNC to NAS, with failed Continuity test 7.5 SS7 Session Setup from NAS to SGNC, with successful Continuity test 7.6 SS7 Session Setup from NAS to SGNC, with failed Continuity test 7.7 Manual Continuity Check with success 7.8 Manual Continuity Check with failure 8.0 Acknowledgements 9.0 References 10.0 Authors 1.0 Introduction Presently, dial-up connections over the public telephone network are used for on-demand connection to the Internet or corporate networks. As well, new services such as Voice over IP are being introduced. The document [1] describes an architectural framework for protocol standardization for telephony interworking with the internet. Interworking deals with both signalling and bearer connections (i.e., media stream), which can either be carried together (e.g., in-band, BRI, PRI) or separately (e.g., SS7). When signalling is carried together with the bearer connections, it arrives directly at the NAS. When signalling is carried separately, it passes through a Signalling Gateway and NAS Controller before arriving at a Network Access Server (NAS). This document describes extensions to Diameter to allow session setup to occur from the NAS to the Signalling Gateway/NAS Controller, and from the Signalling Gateway/NAS Controller to a NAS. 2.0 Terminology Some of the terminology used in this draft is explained in [1]. 3.0 Relationship with the Diameter Base Protocol and other extensions The Diameter base protocol, and other extensions to Diameter provide other aspects of the protocol required between a NAS and a Signalling Gateway/NAS Controller (for example, NAS initialization, configuration, reboot indication, session and resource management, session release)[2,3,4]. Another Diameter extension is used for session setup when user authentication and/or authorization is required [5]. Device Management and Maintenance functions such as channel blocking, continuity test and other device control functions pertinent to particular signalling gateways, e.g. SS7 signalling gateways, can be implemented using the messages described in this Diameter extension. The AVPs necessary for this will be defined in another Diameter extension. 4.0 Session setup messages Signalling Gateway/NAS Controller (SGNC) <-> NAS interaction 4.1 Session-Setup-Request A Session-Setup-Request is issued from a NAS to an SGNC, or from an SGNC to a NAS. This command may be used from the NAS to the SGNC when the signalling for the call is colocated with the NAS. This is the case with PRI signalling. If authentication of the user is required, then the AA-Request/Response messages defined in [5] should be used instead. This command is issued from an SGNC to a NAS, when the signalling for the call is colocated with the SGNC. This is the case with SS7 signalling. For incoming calls that require end-user authentication see [5]. In this case, the AA- Request/Response message exchange initiated from the NAS to the SGNC would be bracketed with a Session-Setup-Request/Response exchange initiated from the SGNC. Note that the Session-Id used for all messages would be the same. For the incoming part of a VoIP call, the Session-Setup-Request goes from the SGNC to the NAS or VoIP gateway, or vice versa depending on the signalling termination location. For the outgoing part, the message always flows from the SGNC to the VoIP gateway, if there is PRI signalling then the Session-Setup- Response is issued as the call is completed. If it is SS7 signalling, the Session-Setup-Request is issued after the outgoing leg has been set through the SS7 signalling). Policy could be enforced in the SGNC, or in the NAS, for completion of VoIP calls. The Resource-Token AVP contains all resources currently assigned to the user for this session. For example, it may include information describing the trunk that a particular SS7 call is assigned to. Actual resources for particular signalling and VoIP gateways are described as AVPs in another Diameter extension. The Extension-Id indicates to which Diameter extension this message, and the AVPs it uses, belongs. If it belongs to more than one, then more than one will be listed. Session-Setup-Request ::= (IP address for NAS) [] [resource descriptors for this particular session] Code AVP Length AVP Flags Command Type The Command Type field MUST be set to xxx (Session-Setup-Request). 4.2 Session-Setup-Response Description A Session-Setup-Response contains the same Session-Id as that in the Session- Setup-Request. The Result-Code MUST be present. This indicates whether the session was set up successfully or not. Session-Setup-Response ::= [resource descriptors for this particular session] Code AVP Length AVP Flags Command Type The Command Type field MUST be set to xxx (Session-Setup-Response). 4.3 Resource-Add-Request Description A Resource-Add-Request is issued from an SGNC to a NAS, or from a NAS to an SGNC. When it is issued from the SGNC to a NAS, it is assumed that authorization to use the resources required has already been granted. If Resource-Add-Request contains a Session-Id already in use, then the requested resource(s) is(are) added to that session. If the resource is engaged in a session the Resource-Add-Request message is interpreted as "Resource Modify". For example, for a tunnel resource, an application may request that the tunnel parameters be changed so that all future data sent over the tunnel is encrypted. It is possible for a resource to belong to more than one session. For example, a tunnel could support more than one session simultaneously. The Resource-Add-Request may contain the Session-Id for the maintenance session (described in [3 - next version of Diameter Base]). Resource messages sent using the maintenance session apply to resources outside any session, or to resources shared by more than one session. If two Resource-Add-Request messages arrive for the same resource, but one with a maintenance Session-Id and the other with a regular Session-Id, it is up to the application that controls resources to decide which one takes precedence. For example, a user may wish to put encryption on the tunnel it is using for its session, but this may not be allowed since it affects all other sessions using the tunnel. The following example shows how the Resource-Add-Request/Response messages can be used to implement an SS7 maintenance function. The Resource-Add-Request could be asking for an SS7 continuity loopback to be set up on a particular channel, or for a continuity test to be performed on a particular channel. If a Session- Setup-Request follows, using the same channel number, loopback is removed from that channel by the application. If the continuity test or loopback fails, then another Resource-Add-Request would mark that channel as in service. AVPs to implement this are described in another Diameter extension. See section 7 for more scenarios. Resource-Add-Request ::= [SS7-Cont-Test> | other kinds of resource descriptors…] An example of a description for an SS7 Continuity Test (will actually be defined in another Diameter extension): SS7-Cont-Test ::= Action ::= [Set up Loopback | Perform Continuity Test | Loopback failed so mark channel as in maintenance | … ] Code AVP Length AVP Flags Command Type The Command Type field MUST be set to xxx (Resource-Add-Request). 4.4 Resource-Add-Response Description The Resource-Add-Response is sent in response to a Resource-Add-Request. The Resource-Token AVP is only present if the session has resources to be managed. Resource-Add-Response ::= [SS7-Cont-Check> | other kinds of resource descriptors…] Code AVP Length AVP Flags Command Type The Command Type field MUST be set to xxx (Resource-Add-Response). 5.0 Attribute AVPs AVPs for SS7 sessions and resources for SS7 Signalling Gateways are defined in another Diameter extension. In particular, this would include AVPs for channel blocking, continuity test and other device control functions pertinent to particular signalling gateways. 6.0 Security Considerations Security is provided using the mechanisms available in the Diameter Base protocol and extensions [3,6]. 7.0 Example message exchanges for SS7 session setup 7.1 SS7 Session Setup originating from SGNC PSTN SGNC NAS | IAM | | |-------------------->| | | | Session-Setup-Request | | |---------------------------->| | | | | | Session-Setup-Response | | |<----------------------------| | ACM | | |<--------------------| | | ANM | | |<--------------------| | Note: When ACM is sent, and whether both ACM and ANM are sent, or just ANM, depends on the SS7 network being used. 7.2 SS7 Session Setup originating from NAS PSTN SGNC NAS | | Session-Setup-Request | | |<----------------------------| | IAM | | |<--------------------| | | ACM | | |-------------------->| | | ANM | | |-------------------->| | | | Session-Setup-Response | | |---------------------------->| Note: 1. When ACM is sent, and whether both ACM and ANM are sent, or just ANM, depends on the SS7 network being used. 2. The Session-Setup-Response could be issued before the ANM is received. If this were the case, we would need to use a Connect or Accounting message that would be sent once the session is up end to end. This is for further study. 7.3 SS7 Session Setup from SGNC to NAS, with successful Continuity test The following is an example of how the Session and Resource messages can be used when a continuity test should be performed on the channel prior to the call establishment. PSTN SGNC NAS | IAM (cont check bits set) | |-------------------->| | | | Resource-Add-Request( cont test on channel x) | |------------------------------>| | | Resource-Add-Response | | |<------------------------------| | COT (cont success) | | |-------------------->| | | | Session-Setup-Request | | |------------------------------>| | | Session-Setup-Response | | |<------------------------------| | ACM | | |<--------------------| | | ANM | | |<--------------------| | The Resource-Add-Request message from the SGNC to the NAS is used to initiate the continuity test loopback. If the remote end-point indicates to the SGNC that the continuity test succeeded, the SGNC proceeds with Session-Setup-Request. 7.4 SS7 Session Setup from SGNC to NAS, with failed Continuity test If the remote end indicates failure, the SGNC will send a Resource-Add-Request message to the NAS requesting that the channel be placed into the in maintenance state. Session setup is initiated by the SGNC. PSTN SGNC NAS | IAM (cont check bits set) | |-------------------->| | | | Resource-Add-Request (cont test on channel x) | |------------------------------>| | | Resource-Add-Response | | |<------------------------------| | COT (cont failed) | | |-------------------->| | | CCR | | |-------------------->| | | LPA | | |<--------------------| | | | Resource-Add-Request (cont test on channel x) | |------------------------------>| | | Resource-Add-Response | | |<------------------------------| | COT (cont test failed) | |-------------------->| | | | | | RLC or BLO | | |<--------------------| | | | Resource-Add-Request (put channel x in maintenance) | |------------------------------>| | | Resource-Add-Response | | |<------------------------------| Note: 1. CCR, LPA, Resource-Add-Request/Response, COT message sequence continues until the RLC/BLO is received, or until COT passes. 7.5 SS7 Session Setup from NAS to SGNC, with successful Continuity test The following is an example of how the Session and Resource messages can be used when a continuity test should be performed on the channel prior to the call establishment. Session setup is initiated by the NAS. PSTN SGNC NAS | | Session-Setup-Request | | |<------------------------------| | | | |IAM (cont check on) | Resource-Add-Request (cont test on channel x) |<--------------------|------------------------------>| | | | | | Resource-Add-Response (cont test passed) | |<------------------------------| | COT (cont test passed) | |<--------------------| | | | | | ANM | | |-------------------->| | | | Session-Setup-Response | | |------------------------------>| Note that all messages use the same Session-Id. The Session-Setup-Request message from the NAS to the SGNC is used to initiate the session. The Resource-Add-Request initiates continuity test loopback. The NAS decides whether the continuity test has succeeded, and tells the SGNC in the Resource-Add-Response. If successful, the SGNC proceeds with Session-Setup- Response. 7.6 SS7 Session Setup from NAS to SGNC, with failed Continuity test If the NAS indicates failure, the SGNC will send a Resource-Add-Request message to the NAS requesting that the channel be placed into the in maintenance state. PSTN SGNC NAS | | Session-Setup-Request | | |<------------------------------| | IAM (cont check bits set) | |<--------------------| | | | Resource-Add-Request (cont test on channel x) | |------------------------------>| | | Resource-Add-Response (cont test failed) | |<------------------------------| | | | | COT (cont test failed) | |<--------------------| | | CCR | | |<--------------------| | | LPA | | |-------------------->| | | | Resource-Add-Request (cont test on channel x) | |------------------------------>| | | Resource-Add-Response (cont test failed) | |<------------------------------| | COT (cont test failed) | |<--------------------| | | | | | RLC or BLO | | |-------------------->| | | | Session-Setup-Response (session setup failed) | |------------------------------>| | | | | | Resource-Add-Request (put channel x in maintenance) | |------------------------------>| | | Resource-Add-Response | | |<------------------------------| Note: 1. all messages, except the last Resource-Add-Request/Response pair, use the same Session-Id. 2. CCR, LPA, Resource-Add-Request/Response, COT message sequence continues until the RLC/BLO is received, or until COT passes. 7.7 Manual Continuity Check with success PSTN SGNC NAS | | | | CCR | | |-------------------->| Resource-Add-Request (cont test on channel x) | |------------------------------>| | | Resource-Add-Response | | |<------------------------------| | LPA | | |<--------------------| | | COT (cont test passed) | |-------------------->| | 7.8 Manual Continuity Check with failure PSTN SGNC NAS | | | | CCR | | |-------------------->| Resource-Add-Request (cont test on channel x) | |------------------------------>| | | Resource-Add-Response | | |<------------------------------| | LPA | | |<--------------------| | | COT (cont test failed) | |-------------------->| | | CCR | | |-------------------->| | | LPA | | |<--------------------| | | | Resource-Add-Request (cont test on channel x) | |------------------------------>| | | Resource-Add-Response (cont test failed) | |<------------------------------| | COT (cont test failed) | |-------------------->| | | | | | RLC or BLO | | |<--------------------| | | | Resource-Add-Request (put channel x in maintenance) | |------------------------------>| | | Resource-Add-Response | | |<------------------------------| Note: 2. CCR, LPA, Resource-Add-Request/Response, COT message sequence continues until the RLC/BLO is received, or until COT passes. 8.0 Acknowledgements The authors would like to thank Alan Whitton for his comments on previous versions of this document. 9.0 References [1] F. Cuervo, N. Greene, M. Holdrege, L. Ong, C. Huitema, "SS7 and Internet Interworking - Architectural Framework", draft-greene-ss7-arch-frame-00.txt, July 1998, work in progress [2] P. R. Calhoun, G. Zorn, P. Pan, "Diameter Framework Document", draft-calhoun-diameter-framework-00.txt, May 1998, work in progress [3] P. R. Calhoun, A. Rubens, "Diameter Base Protocol", draft-calhoun-diameter-03.txt, April 1998, work in progress [4] P. R. Calhoun, N. Greene, "Diameter Resource Management Extensions", draft-calhoun-diameter-res-mgmt-01.txt, May 1998, work in progress [5] P. R. Calhoun, W. Bulley, "Diameter User Authentication Extensions", draft-calhoun-diameter-authent-03.txt, April 1998, work in progress [6] S. A. Vakil, P. R. Calhoun, "Diameter IP Security Policy extensions", draft-calhoun-diameter-ipsec-policy-00.txt, March 1998, work in progress 10.0 Authors Fernando Cuervo Nortel (Northern Telecom) P.O. Box 3511 Station C Ottawa, Ontario K1Y 4H7, Canada Tel: 613-763-4628 EMail: cuervo@nortel.com Nancy Greene Nortel (Northern Telecom) P.O. Box 3511 Station C Ottawa, Ontario K1Y 4H7, Canada Tel: 613-763-9789 Email: ngreene@nortel.com