INTERNET DRAFT                                        Nancy Greene
Category:                                Nortel (Northern Telecom)
Title:<draft-greene-diameter-ss7-session-00.txt>   Fernando Cuervo
Date: July 1998                          Nortel (Northern Telecom)
Expires: January 1998

          Bi-Directional Session Setup Extension to Diameter
      <draft-greene-diameter-ss7-session-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 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 ::= <DIAMETER Header>
   <Session-Id>
   <Host-IP-Address> (IP address for NAS)
   [<Host-Name>]
   <Extension-Id>
   <Resource-Token>
      [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 ::= <DIAMETER Header>
   <Session-Id>
   <Extension-Id>
   <Result-Code>
   <Resource-Token>
      [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 ::= <DIAMETER Header>
   <Session-Id>
   <Extension-Id>
   <Resource-Token>
   [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 ::= <Resource-Number>
                  <Channel-Number>
                  <Action>

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 ::= <DIAMETER Header>
   <Session-Id>
   <Extension-Id>
   <Result-Code>
   <Resource-Token>
       [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