Architectures and Supporting Protocols for VOIP/3G

Architectures and Supporting Protocols for VOIP/3G

Architectures and Supporting

Protocols for VOIP/3G

IETF at work

NGN and 3G Network Elements

Numbering and Naming (ENUM)

Session Description Protocol (SDP)

NAT traversal

Diameter

Media Gateway Control (Megaco/MGCP)

Common Open Policy Service (COPS)

Raimo Kantola –S- 2005 Signaling Protocols 12 - 1

Agenda

• IETF

• Networking framework – 3G, wireline

• 3G terminal

• ENUM – naming and addressing

Raimo Kantola –S- 2005 Signaling Protocols 12 - 2

1

IETF

• IETF toolkit

– bottom-up approach

(“one problem – one protocol”)

– Protocols should be simple, reusable, scalable, robust

Application

Area

… simple

General

Area

¾ over 100 active WGs

¾ here are some of them

Raimo Kantola –S- 2005

Internet

Area

IESG

Internet Engineering

Steering Group

O&M

Area aaa dnsop

Routing

Area bgmp idmr idr manet mpls ospf

Signaling Protocols

Security

Area ipsec smime tls

Sub-IP

Area

Transport avt

Area enum iptel mmusic sip sipping sigtran

12 - 3

IETF specifications

•Every standard follows the route Proposed standard-> Draft Standard-> Standard

Raimo Kantola –S- 2005 Signaling Protocols 12 - 4

2

ETSI, etc have delegated the 3G standardisation work to 3GPP

• 3GPP – is the 3G Partnership Project

• this gives a key role to vendors

• site: www.3gpp.org

has all their documents!

• The idea is that ETSI etc will rubberstamp

3G documents as standards.

Raimo Kantola –S- 2005 Signaling Protocols 12 - 5

3G is composed of many Subsystems

UTRAN

Circuit Switched

Domain

UE

Other IP

Connectivity

Access

Network

Packet Switched

Domain

Raimo Kantola –S- 2005 Signaling Protocols

IMS

IP Multimedia

Subsystem

12 - 6

3

3G IP Multimedia core network

Subsystem (3G IMS)

Sh

AS AS

SCIM

SIP Application

Server

ISC

AS – Application Server

CAP - Camel Application Part

IM-SSF – IP Multimedia Service Switching

Function

ISC – IP Multimedia Service Control

MAP

Si

Cx

ISC

CAP

Camel Service

Environment

ISC

OSA service capability server

Mr

OSA API

OSA application server

MAP - Mobile Application Part

MRFC - Media Resource Function

Controller

OSA – Open Service Access

SCIM – Service Capability Interaction

Manager

SCS – Service Capability Server

Raimo Kantola –S- 2005 Signaling Protocols 12 - 7

Alternative to IMS?

• With a 3G device a user can access the open

Internet and use any services that are available on the Internet: www, e-mail, conferencing, VOIP etc.

– QoS is the Best Effort QoS of regular Internet

• Charging can be either volume based or flat rate.

• Flat rate can lead to overuse of the cellular capacity and poor QoS

Raimo Kantola –S- 2005 Signaling Protocols 12 - 8

4

Motivation for IMS

• IMS = Integration of cellular and Internet worlds.

Why, when a user already can take an Internet connection from a cellular device and use all

Internet Services?

– Controlled QoS for Interactive voice and video

– Proper Charging for QoS and Freedom of charging based on any business model for the services

– Integration of services on a single packet platform: access to all aspects of sessions from any service.

– Ease of interworking with Internet Services(?)

Q: Is this enough?

Q: Why should operators switch from circuit based voice services to IMS based voice services in 3G?

Raimo Kantola –S- 2005 Signaling Protocols 12 - 9

IMS Objectives

Support for the following:

1. establishing IP Multimedia Sessions

2. negotiation of QoS

3. interworking with the Internet and the CSN

4. roaming

5. strong conrol by the operator with respect to the services delivered to the end user

6. rapid service creation without requiring strandardization

7. access independence (from release 6)

Raimo Kantola –S- 2005 Signaling Protocols 12 - 10

5

3G Application Triggering

Application Server

Service Logic

HSS

SIP Interface iFC sFC

SIP

S - CSCF

S

P

T

Filter Criteria iFC – Initial Filter Criteria sFC – Subsequent Filter Criteria

SPT – Service Point Trigger

SIP

SIP

Service processing can be delegated to

Application Servers with a fine grained control sFC is considered historical (obsolete)

Raimo Kantola –S- 2005 Signaling Protocols 12 - 11

Media processing in 3G

AS

ISC

Mr

MRFC - Media Resource Function

Controller

MRFP – Media Resource Function

Processor

S-CSCF

MRFC

Mp

MRFP

MRFC likely to have a general purpose processor,

MRFP has many DSPs – digital signal processors.

Raimo Kantola –S- 2005 Signaling Protocols

All this takes place in the IP domain.

Examples:

- transcoding Wideband AMR/

Narrowband AMR codec

- Multiparty conference media processing

In practice it is convenient to implement

MRFP in the same device as the Media

Gateway between CS/PS domains

12 - 12

6

The role of HSS

Identification handling

Service authorization support

HSS

Mobility Management

User security info. generation

User security support

Access authorization

Service Provisioning support

Call / Session establishment support

Application Services Support

CAMEL Services Support

C D

GMSC MSC / VLR gsmSCF

CS Domain

Gr

Gc

Sh Si Cx

SGSN GGSN

PS Domain

SIP Application

Server

IM-SSF

OSA-SCS

IM CN subsystem

CSCF

source: www.3gpp.org/specs/archive/23002-580

Signaling Protocols 12 - 13 Raimo Kantola –S- 2005

PSTN PSTN

PSTN

Go

Gi Gp

Basic Configuration

CS-

MGW

Mc

GMSC server

GGSN

Nc

C

HSS

(

HLR,AuC)

PSTN

Nb

D

VLR

B

MSC server

G

E

Nc

VLR

B

MSC server

Mc

Mc

CS-MGW

Nb

CS-MGW

A

IuCS

BSS

Gb

IuPS

BTS

BSC

Abis

BTS

F

EIR

Gs

Gc

Gf

Gr

Gn

SGSN

IuCS IuPS

RNS

Iur

RNC

Node B cell

Iub

Node B

CN

Um

Uu

RNC

of a PLMN

GGSN – Gateway GPRS Support Node

SGSN – Serving GPRS Support Node

HSS – Home Subscriber Server

RNC – Radio Network Controller

Node B = 3G base station

USIM – UMTS Subscriber Identity Module

On CS side breakdown of MSC to

Media Gateway and MSC server.

3G and GSM/GPRS are based on the same packet core elements.

Raimo Kantola –S- 2005

ME

SIM-ME i/f or

SIM

Cu

USIM

MS source: www.3gpp.org/specs/archive/23002-580

Signaling Protocols 12 - 14

7

The IP Multimedia Subsystem

Mb

Mb sits on top of the Packet Core

IP Multimedia Networks

PSTN

Mb PSTN

BGCF

CSCF

PSTN

Mk Mk

Mw

Mj BGCF

Mi

Mm

Cx

IMS-

MGW

Mn

MGCF

Mg

CSCF

Mb

Mr

Mw

Dx

Legacy mobile signalling Networks

BGCF – Breakout Gateway

Control Function

PCF – Policy Control Function

HSS

C, D,

Gc, Gr

SLF – Service Location Function

CSCF – Call Session Control

Function

P-CSCF – Proxy CSCF

HSS – Home Subscriber Server

SLF

MRFP

Mb

M p

Mb

Raimo Kantola –S- 2005

MRFC

P-CSCF

PCF

Go

UE

Gm

IM Subsystem

source: www.3gpp.org/specs/archive/23002-580

Signaling Protocols 12 - 15

Signaling Gateway maps SS7

MTP to SCTP/IP transport

IP

Signalling transport

NW

SCTP/IP

SGW

MTP

SS7

Signalling transport

NW

This allows to transfer signaling and service processing responsibility to IP based environment.

Raimo Kantola –S- 2005 Signaling Protocols 12 - 16

8

IMS Interworking with the PSTN

• IMS terminals must support CSN services due to Emergency Call requirements, so

PSTN interworking can occur thru the CS domain. However, IMS Interworking with PSTN is also possible.

SGW

ISUP/IP

SIP

BGCF

SIP

MGCF

H.248

RTP

MGW

ISUP/MTP

Switching

System

PCM

Raimo Kantola –S- 2005 Signaling Protocols 12 - 17

UE has a tunnel to visited IMS

UE

SGSN

Virtual presence of UE in visited network IM subsystem

(UE’s IP-address is here)

Visited Network

PDP Context

GGSN

Gi

Home Network

IM Subsystem

BG

Inter-Network

IM Backbone

BG

Visited Network

IM Subsystem

Internet

Intranets

Raimo Kantola –S- 2005 Signaling Protocols 12 - 18

9

3G UE can use several services at the same time

Gi

Internet/

Intranet

UE

SGSN

Home Network

Gp

BG

GGSN

PDP Context

SGSN

Gp

BG

Visited Network

GGSN

PDP Context

Raimo Kantola –S- 2005 Signaling Protocols

Visited Network

IM Subsystem

PDP context = virtual connection between the terminal and an access point to an IP network thru

GGSN

12 - 19

ETSI SoftSwitch Architecture for NGN

This is the wireline networking framework

Service

Control

Point (SCP)

INAP

Service

Switching

Point(SSP)

ISUP or other

Voice

API

Integrated

Service

Node

Circuit Switched Network

Application

Service

Application

Parlay

Interface

Adapter

API

API

Signaling

Gateway

API

Media

Gateway

Controller

SS7 over IP

SIP

MEGACO or MGCP

Media

Gateway

SIP Server

SIP

Voice over RTP

Raimo Kantola –S- 2005 Signaling Protocols 12 - 20

10

The UMTS terminal functional model

Browser Streaming

Point-to-Point data

Messaging

FTP LDAP DNS HTTP SLP SIP IMAP SMTP X.509 Radius H.323

QoS extension

QoS

Management

DiffServ RSVP TCP

IP

Packet Classifier

Socket API

DHCP RTP/RTCP

WAP

UDP

PPP

UMTS

Raimo Kantola –S- 2005 Signaling Protocols 12 - 21

The GPRS and 3G networks implement the Multimedia Messaging Service

MMS User Agent

HLR

MMS

Server

SMSC

Wireless

Network

MMS

Relay

e-mail

Server

Foreign

MMS

Relay

Wireless

Network

MMS

Server

Uses MMS over WAP

HTTP and WAP push

MMS User Agent

Raimo Kantola –S- 2005 Signaling Protocols 12 - 22

11

Supporting protocols for IP telephony – wired and wireless

• ENUM – addressing and naming

• Gateway control - Megaco

• Policy Control – COPS

• Session description – SDP

• AAA - Diameter

Raimo Kantola –S- 2005 Signaling Protocols 12 - 23

Naming and Addressing in NGN and 3G

IMS vs. Telephone numbering

• A Name identifies a domain, a user or a service. An address

points to a user or to an interface or to an inlet/outlet in a network.

• Internet heavily relies on the Domain Name System (DNS) to translate names to addresses. The specs of using DNS for

Telephony names and addresses is called ENUM – tElephone-NUmber-Mapping.

• ENUM was originally meant for mapping IP telehone numbers (e.g. 3G IMS phonenumbers) to logical names (and

IP addresses).

• With Naming and Addressing, at the same time we need to solve the problem of Gateway (CSN/IP) location and

Number Portability across the technology boundary.

Raimo Kantola –S- 2005 Signaling Protocols 12 - 24

12

ENUM uses DNS to store telephone numbers

”.” the root

.arpa

.com

.net

.fi

.e164.arpa

in-addr second-level node second-level node second-level node

Most likely ”.e164.arpa” –server is the root of the ENUM hierarchy.

Countries are starting to reserve names under it and establishing

ENUM services/country. Enum pilot in Finland until May –04.

8.5.3.e164.arpa

Telephone numbers are presented in the inverted order with dots in between!

An ENUM server may cover any subtree.

1.1.5.4.9.8.5.3.e164.arpa

A node may carry any digit string with dots

(not just one digit) – this is up to operators.

Raimo Kantola –S- 2005 Signaling Protocols 12 - 25

ENUM introduces NAPTR records

RFC 2915 - The Naming Authority Pointer (NAPTR) DNS Resource Record (Sep 2000)

NAPTR – Naming Authority PoinTeR = Record in DNS containing an URI.

E.g. IN NAPTR 10 10 ”u” ”sip+E2U” ”!^.*$!sip:[email protected]!”.

Internet expect uri

Record type

Order and Pref

SIP, E.164 to

URI

The URI itself!

Can be modified by Regular expression

NAPTR format is: Domain TTL Class Type Order Preference Flags Service Regexp Replacement

Domain=first well known key e.g. <something>.uri.arpa

TTL=Time-To-Live – validity time of the record (time to cache)

Class=IN=Internet

Type=NAPTR=35

Order=low nrs are processed before high, once target found, stop (excepting flags)

Pref=if same order value, all with diff pref can be processed, take lowest first.

Flags=“S”-next lookup for SRV record, “A”-next lookup for A, AAAA or A6 record, “U” – the reminder has an URI+this is the last record, P –protocol specific processing

Service=protocol-name + resolver, resolver is used to resolve the result of regexp

Regexp=replacement-rule for whatever querier is holding.

Replacement=a fully qualified domain name to query next for NAPTR, SRV or address records (“S”, “A”)

Raimo Kantola –S- 2005 Signaling Protocols 12 - 26

13

Example from RFC 2915

In order to convert the phone number to a domain name for the first iteration all characters other than digits are removed from the telephone number, the entire number is inverted, periods are put between each digit and the string ".e164.arpa" is put on the left-hand side. For example, the

E.164 phone number "+1-770-555-1212" converted to a domain-name it would be

"2.1.2.1.5.5.5.0.7.7.1.e164.arpa."

For this example telephone number we might get back the following

NAPTR records:

$ORIGIN 2.1.2.1.5.5.5.0.7.7.1.e164.arpa.

IN NAPTR 100 10 "u" "sip+E2U" "!^.*$!sip:[email protected]!" .

IN NAPTR 102 10 "u" "mailto+E2U" "!^.*$!mailto:[email protected]!" .

This application uses the same 'u' flag as the URI Resolution application. This flag states that the

Rule is terminal and that the output is a URI which contains the information needed to contact that telephone service. ENUM uses the Service field by defining the 'E2U' service. The example above states that the available protocols used to access that telephone's service are either the Session Initiation Protocol or SMTP mail.

Raimo Kantola –S- 2005 Signaling Protocols 12 - 27

A possible ENUM hierarchy

This follows the ”US model” suggested by Tuomo Rostela for Finland.

Tier 0 ficora_enum.fi

8.5.3.e164.arpa

Tier 1 enum.elisa.fi

$ORIGIN e164.arpa.

1 IN NS att_enum.com.

6.4 IN NS sweden_enum.se.

8.5.3 IN NS ficora_enum.fi.

$ORIGIN 4.9.8.5.3.e164.arpa.

5 IN NS enum.elisa.fi.

6 IN NS enum.elisa.fi.

358 is delegated to ficora_enum

Elisa is chosen as the ENUM operator for HUT numbers 09-45….,

Tier 2

$ORIGIN 1.7.4.2.1.5.4.9.8.5.3.e164.arpa.

IN NAPTR 10 10 ”u” ”sip+E2U” ”!^.*$sip:[email protected]!”.

My office phone number is mapped to a (non-existing at the moment)

SIP server operated by the NETLAB

Tier 3

Corporate numbering schemas…

In Finnish ENUM pilot until 31.5.2004 only Tier 1 and Tier 2 present!

Raimo Kantola –S- 2005 Signaling Protocols 12 - 28

14

ENUM use and future

• Since DNS is used by everybody, ENUM is a likely surviver, policy routing etc additions may emerge

• Due to Number Portability Provision of ENUM service and provision of VOIP service to endcustomers are two independent services.

• User may need to select the Numbering service provider separately from the VOIP service provider.

Raimo Kantola –S- 2005 Signaling Protocols 12 - 29

Use of ENUM in 3G IMS

• If the callee is identified by tel URL (tel: +358-59-

345-897), the originating S-CSCF tries to map this to a SIP URI using a NAPTR query to ENUM

• if no mapping is found, it is assumed that the target is a PSTN or any other CSN number and the call signaling is routed to a BGCF (Breakout

Gateway Control Function) that is specialised at routing based on telephone numbers.

Raimo Kantola –S- 2005 Signaling Protocols 12 - 30

15

Call from PSTN to a SIP phone

2. Query

1.7.4.2.1.5.4.9.8.5.3.e164.arpa

ENUM

3. Response sip:[email protected]

1. Caller dials 4512471

Gateway

4

5. INVITE SIP

Proxy

IP Network

4 - sip:[email protected]

is translated to an IP address of the SIP proxy serving the number by another DNS query that returns an address record.

6. INVITE

SIP phone

192.151.79.187

or

+358-9-451 2471

Raimo Kantola –S- 2005 Signaling Protocols 12 - 31

ENUM issues and problems

• Long chain of DNS servers results low reliability

• Secret telephone numbers seem to require two ENUM systems: the

”Operator ENUM” with no direct access by users and ”user ENUM”.

• Result is always the same for a number irrespective of from where the call is originating in a domain ÆNon-optimal routing.

• Number Portability accross technology boundary would require changes in PSTN (link between IN and ENUM)

• Using ENUM for calls from PSTN is difficult because of overlap sending: non-complete numbers are not described in ENUM records.

• Management of numbering data.

• Security (DNSSec under development…?)

• Nicklas Beijar of Netlab suggests solutions to some of the above problems in his Lic thesis 2004.

• ENUM pilot in Finland until 31.5.2004, after that commercial operation?

Raimo Kantola –S- 2005 Signaling Protocols 12 - 32

16

IP Telephony Research in the

Networking Laboratory

• Technology evaluation

– Delay measurements breakdown (1997…)

– SIP call waiting

• Numbering and Routing Information

Interoperability with ISDN

– TRIP (Telephony Routing over IP) and ENUM protocols

– CTRIP (Circuit TRIP) protocol proposed

– Database (mySQL) solution to Number Portability

(Antti Paju)

– Nicklas Beijar’s Lic thesis (Spring 2004) on alternative solutions for NP

Raimo Kantola –S- 2005 Signaling Protocols 12 - 33

Agenda (??.3.2004)

• Megaco

• SDP – session descriptions

• COPS – policy based networking

• STUN and TURN – NAT traversal

Raimo Kantola –S- 2005 Signaling Protocols 12 - 34

17

Megaco - Media Gateway Control protocol controls Media Gateways and Media Processing

• MGCP was promoted by Cablelabs = US CATV

R&D body as the CATV Telephony standard

• ITU-T has its own variant called Megaco=H.248

• Megaco, MGCP are master-slave protocols by which media gateways can be configured e.g to services - in case of residential media gateway,

MGCP becomes a subscriber signalling system

Raimo Kantola –S- 2005 Signaling Protocols 12 - 35

Gateway decomposition

SG

DSS1 or ISUP

(e.g. ISUP over IP)

Media Gateway

Control

IP based signaling

(H.323 or SIP)

H.248 = Megaco or MGCP

PCM voice Media

Gateway

RTP + RTCP flow

MG - Trunk gateway, residential gateway etc.

Many MGs can be controlled by one MGC, MGCs can be a mated pair --> higher availability performance.

Raimo Kantola –S- 2005 Signaling Protocols 12 - 36

18

Megaco functions

• Establishment of connections between terminations

– PCM –timeslots for voice

– ephemeral packet stream terminations: IPaddress + source + dest UDP-port number

• Release of connections

• separation of signaling from voice band in case of CAS and analogue subsc signaling

Raimo Kantola –S- 2005 Signaling Protocols 12 - 37

SCN

LS

IP

LS

SG

MGC

Megaco

SS

ISU

P/H

.323

/SIP

SS

LS

MG

SG - Signalling Gateway, MGC - Media Gateway Controller

MG - Media Gateway, SS = Signaling Server, LS = Location Server

Raimo Kantola –S- 2005 Signaling Protocols 12 - 38

19

Gateway decomposed

SCN

SCN - SIG

(CCS)

Call Control

MGC

Megaco

IP - SIG

= SIP

= H.323

= ISUP/IP

SCN-SIG

- CAS

MG

IP

Raimo Kantola –S- 2005 Signaling Protocols 12 - 39

Megaco for Residential Gateways

• Residential MG processes analogue subscriber signaling – inband, can not be separated from media plane

• Controller gives a dialling pattern for MG to look for. When detected, report to MGC. MGC gives a new pattern to look for. Etc.

• Real time processing of signals is delegated to the residential gateway, while MGC retains overall control over what is happening and what is the interpretation of the patterns.

Raimo Kantola –S- 2005 Signaling Protocols 12 - 40

20

QoS – Integrated Serv. and DiffServ help resolving the QoS issue in VOIP and 3G IMS

• Integrated Services

– Different treatment to different flows

– State info stored in network, routers examine packets!!!(not good)

– Reservation merging

– RSVP protocol – for reservation of resources

• DiffServ

– Defines a small nrof traffic classes with different priority levels

– Packets tagged with level tags at the beginning(ingress)

– Routers just examine tags

– Better scaling

– Requires policy management: e.g. which packets to assign to which class.

Raimo Kantola –S- 2005 Signaling Protocols 12 - 41

SIP Sessions require policy control

• Parties can release the “call session” but since they have obtained each others IP-addresses, they can continue sending media streams to each other!!

• How to push INVITE to B-party, if

B-party does not have a permanent

IP address which is most often the case!

Integration of

Proxy with

Firewall and

NAT

Raimo Kantola –S- 2005 Signaling Protocols 12 - 42

21

Common Open Policy Service Protocol

(COPS) can be used to exchange policy info

Policy Enforcement

Point (PEP)

Query

Response

Policy Decision

Point (PDP)

• Examples of PEPs are Network Address Translators

(NAT), Firewalls, RSVP Routers, GGSN in 3G

• PEP sends requests, updates, deletes to PDP

• PDP returns decisions to PEP (can also overwrite its decision at any time)

• Uses TCP for transport, Extensible for different PEPs

• PEP and PDP share state

• In case of PDP failure, PEP can make local policy decisions

RFC 2748

Raimo Kantola –S- 2005 Signaling Protocols 12 - 43

=1

0x1= solicited msg flag

COPS Common Header

0 1 2

Version Flags Op Code Client-type

RFC 2748 of Jan 2000

3

Message Length

1 = Request (REQ)

2 = Decisions (DEC)

3 = Report State (RPT)

4 = Delete Request State (DRQ)

5 = Synchronize State Req (SSQ)

6 = Client-Open (OPN)

7 = Client Accept (CAT)

8 = Client Close (CC)

9 = Keep-Alive (KA)

10 = Synchronize Complete SSC

-Identifies Policy Client

- Separate specs/client type

- interpretation of objects is per client type

In addition msg has

- generic object formats

Raimo Kantola –S- 2005 Signaling Protocols 12 - 44

22

COPS maintains a TCP session

PEP

Client Open (OPN)

Client Accept (CAT)

KA

PDP

Opening a session establises a context

Keep-alive messages must be sent on regular intervals

KA

KA

Client Close (CC)

Closing the session removes all state

Raimo Kantola –S- 2005 Signaling Protocols 12 - 45

PDP makes policy decisions on request or at any time

PEP

REQ

DEC

RPT

DEC

(unsolicited)

RPT

PDP

DRQ

E.g. PEP may need to allocate some resourse – PDP makes the decision

RPT – reports the state change at PEP

PDP may at any time change its previous decision: e.g. default policy is overridden for a time. PEP must abide always!

There may be a need to remove state for a object: PDP needs to know.

Raimo Kantola –S- 2005 Signaling Protocols 12 - 46

23

PDP may need to synchronize its state with PEP

PEP PDP

SSQ

SSC

E.g. PDP has failed and after recovery it needs to restore the state of policy objects from the network (i.e. from PEPs)

NB: PEP does not change its state in this procedure!

SSQ – Synchronize State reQuest

SSC – SynchroniSe Complete

Raimo Kantola –S- 2005 Signaling Protocols 12 - 47

Use examples for COPS

• Wireline VOIP: COPS can be used to control a

NAT+Firewall (PEP) from a Proxy Server (PDP).

– Default policy is: all TCP/IP ports for media streams are closed (deny policy)

– Per SIP session Proxy sends a DEC message to “open the gate” for bi-directional media flow.

– When BYE is received, gate is again closed

• 3G IMS: to authorize resources for PDP contexts of media flows.

Raimo Kantola –S- 2005 Signaling Protocols 12 - 48

24

COPS can be used in two modes

• Outsourcing mode

– PEP contacts the PDP every time a decision needs to be made

• Provisioning mode (COPS-PR)

– RFC 3084

– PEPs make local policy decision based on what the PDP has downloaded to the PEP

– SPPI – Stucture of Policy Provisioning Information (RFC

3159) describes the PIB - Policy Information Base

• IMS uses both modes of COPS!

• Initial implementations of COPS are poor and buggy…

Raimo Kantola –S- 2005 Signaling Protocols 12 - 49

SDP: Session Description Protocol

• SDP was initially designed for Mbone. Mbone was/is a multicast overlay network on the Internet

• Used to describe sessions (to link the session with media tools)

• Describes conference/session addresses and ports

+ other parameters needed by RTP, RTSP and other media tools

• SDP is carried by SIP, SAP: Session

Announcement Protocol etc.

Raimo Kantola –S- 2005 Signaling Protocols 12 - 50

25

Multicast

• Several parties involved

– IPv4 Multicast from 224.0.0.0 – 239.255.255.255

• Saves bandwidth cmp to n times p2p connection

• Entity that is sending does not have to know all the participants

• Multicast Routing protocols

– Dense Mode (shortest-path tree per sender)

– Sparse Mode (shared tree used by all sources)

• IGMP (Internet Group Management Protocol)

– For hosts that want to become part of multicast group

• Mbone – part of Internet that supports multicast

• RTP – transport of real-time data such as voice or video

– Sequence number, timestamps

• RTCP – controls RTP transport (every RTP session has a parallel

RTCP session.)

Raimo Kantola –S- 2005 Signaling Protocols 12 - 51

SDP can describe

• Session name and purpose

• Time(s) the session is active

– start, stop time, repetition

• The media comprising the session

– video, audio, etc

– transport protocol: RTP, UDP, IP, H.320 etc

• Parameters to receive media: addresses, ports, formats etc.

– H.261 video, MPEG video, PCMU law audio, AMR audio

• Approximate bandwidth needed for the session

• Contact info for person responsible

Raimo Kantola –S- 2005 Signaling Protocols 12 - 52

26

SDP info is <type>=<value> in strict order

<type> is a single, case sensitive character.

<value> is a text string or a nrof fields delimited by a single white space char.

SDP has one session level description and optionally n media descriptions.

Session description v= (protocol version) o= (owner/creator and session identifier).

s= (session name)

* = optional i=* (session information) u=* (URI of description) e=* (email address) p=* (phone number) c=* (connection information - not required if included in all media) b=* (bandwidth information)

One or more time descriptions (see below) z=* (time zone adjustments) k=* (encryption key) a=* (zero or more session attribute lines)

Zero or more media descriptions (see below)

Raimo Kantola –S- 2005 Signaling Protocols 12 - 53

SDP items continued

Time description t= (time the session is active) r=* (zero or more repeat times)

Media description m= (media name and transport address) i=* (media title) c=* (connection information - optional if included at session-level) b=* (bandwidth information) k=* (encryption key) a=* (zero or more media attribute lines)

3G document refer to a newer SDP- draft from may 2002.

Some SDP documents:

RFC 2327: SDP Session Description Protocol (dated 1998), now Proposed Std

RFC 3407: SDP Simple Capability Declaration

RFC 3264 - An Offer/Answer Model with Session Description Protocol (SDP)

RFC 3266 - Support for IPv6 in Session Description Protocol (SDP)

RFC 3556 SDP Bandwidth modifiers for RTCP

Raimo Kantola –S- 2005 Signaling Protocols 12 - 54

27

NAT Traversal

RFC 3489 Title: STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network

Address Translators (NATs)

Author(s): J. Rosenberg, J. Weinberger, C. Huitema, R. Mahy

Status: Standards Track Date: March 2003

See also: http://corp.deltathree.com/technology/nattraversalinsip.pdf

Traversal Using Relay NAT (TURN) draft-rosenberg-midcom-turn-03

• For the purpose of IPv4 address saving, many users sit behind Network Address Translators.

• NATs are of 4 types: Full Cone, Restricted Cone,

Port Restricted Cone and Symmetric.

• NAT address/port mappings will be dropped after some time of not seeing packets thru the mapping

Internet is an A-subscriber’s Network! B-subscribers are not connected!

Raimo Kantola –S- 2005 Signaling Protocols 12 - 55

Full Cone:

Client

IP: 10.0.0.2

Port: 8000

NAT Types 1, 2, 3

NAT

Computer A

222.111.109.21

Port: 20202

1. Client sends a msg to A

2. A responds to NAT address and port

3. Also B can send msgs to client

202.231.11.12

Port: 12123

Computer B

222.111.129.17

Port: 10101

Restricted Cone: NAT will block messages from B until Client has sent a msg to B,

After that both A and B will see the same mapping in NAT

Port Restricted Cone: NAT will block packets from all ports but the one to which

Client has previously sent packets.

Raimo Kantola –S- 2005 Signaling Protocols 12 - 56

28

NAT type: Symmetric

Symmetric:

NAT

202.231.11.12

Port: 43211

Computer A

222.111.109.21

Port: 20202

Client

IP: 10.0.0.2

Port: 8000

Computer B

222.111.129.17

Port: 10101

202.231.11.12

Port: 12123

NAT provides a different mapping for different destinations. Messages from

Computer B to Cient will be blocked thru the mapping established for Computer A.

STUN does not allow incoming TCP connections to traverse thru NATs,

STUN does not allow incoming UDP packet thru Symmetric NATs.

Symmetric NATs are common in large Enterprises.

STUN does not allow communication between two parties behind the same NAT using public Internet addresses.

Raimo Kantola –S- 2005 Signaling Protocols 12 - 57

Alternative approaches of NAT traversal

• Application Gateway: Application functions are embedded in the NAT. These functions rewrite parameters in

Application protocol fields, e.g. in SIP messages.

• MIDCOM (RFC 3303) – a protocol is used to control the

NAT by an Application proxy server. Requires changes to existing NATs. Requires a control relationship between the

NAT and the proxy.

• STUN - allows entities behind a NAT to first discover the presence of a NAT and the type of NAT, and then to learn the addresses bindings allocated by the NAT. STUN requires no changes to NATs, and works with an arbitrary number of NATs in tandem between the application entity and the public Internet.

Raimo Kantola –S- 2005 Signaling Protocols 12 - 58

29

STUN model assumes nested NATs

Two IP addresses and two ports

STUN

Server

Client

IP/TCP/TLS/Shared Secret Rq

Server

IP 1 IP 2

Public Internet IP/TCP/TLS/Shared Secret Rq:[usern; passw]

NAT 2

IP/UDP/Binding Req[]

Private NET 2

NAT 1

Private NET 1

IP/UDP/Binding Response:[MappedAddr;Changed Addr]

.

.

.

IP/UDP/Binding Req[ResponseAddress; ChangeReq]

IP/UDP/Binding Response:[...; SourceAddr]

STUN Client

At least two ports needed

Raimo Kantola –S- 2005 Signaling Protocols 12 - 59

Types of NAT are discovered by sending responses from different source address and port

none Da

Change IP

Change port

Ca

Da

Change IP and

Change port Ca

Dp

Dp

Cp

Cp

CHANGED-ADDRESS

Ca:Cp

Ca:Cp

Ca:Cp

Ca:Cp

Table 1: Impact of Flags on Packet Source and CHANGED-ADDRESS in Binding Response

The full procedure of discovering the type of NAT and Firewall is in the RFC

STUN plays with the identity of the user: opens a door for inpersonation. Therefore, security, excluding man-in-the-middle attacks is crucial!

When a SIP application fills in SDP fields and some SIP fields, NAT traversal needs to be taken into account!

Raimo Kantola –S- 2005 Signaling Protocols 12 - 60

30

Traversal Using Relay NAT(TURN) helps with Symmetric NATs

TURN allows for an element behind a NAT or firewall to receive incoming dat over TCP or UDP connections from a single Peer.

TURN does not allow for users to run servers on well known ports if they are behind a NAT

Based on draft: draft-rosenberg-midcom-turn-03.

Technically TURN is an extension to STUN (protocol formats and attributes),

TURN can be co-implemented with STUN. TURN-server+STUN-server and

TURN-cliet + STUN-client

a TURN server allocates a Public Internet IP-address/port pair (PA) to the Clie

Relays messages sent to PA to the Client wrapped in TURN headers.

Raimo Kantola –S- 2005 Signaling Protocols 12 - 61

TURN model is similar to STUN

IP-addr/port pairs for allocation

Client

PA

IP/TCP/TLS/Shared Secret Rq

TURN

Server

IP/TCP/TLS/Shared Secret Rq:[usern; passw]

IP 1

Public Internet

Server

IP/UDP or TCP/Allocate Req[]

NAT 2

IP/UDP or TCP/Allocate Response:[PA, Lifetime]

Private NET 2

NAT 1

Send Request

Send Response

Private NET 1

¾ of Lifetime

TURN Client

Allocate Req[PA....]

Allocate Response:[PA, Lifetime]

The whole thing of STUN and TURN becomes ICE = Interactive Connectivity Establishment.

Raimo Kantola –S- 2005 Signaling Protocols 12 - 62

31

NAT for Interworking IPv6/IPv4

NAT

RTP over IPv6 RTP over IPv4

Alternative approaches:

1.

Find a suitable NAT using ICE = STUN and TURN (slow)

2.

Use ANAT SDP (alternative network address type semantics) to place both IPv4 and

IPv6 addresses in an SDP offer (or an answer). As a result, if both endpoints happen to have IPv6 addresses, NAT is not used (complementary to approach 1)

3.

Session Policies (”draft: Supporting Intermediary session policies in SIP): This essentially means that one of the CSCF proxies controls a NAT and provides the translation service for IMS terminals (seems like an efficient solution).

NB: for signaling interworking a proxy with a double IPv6/IPv4 stack is needed on the boundary.

It needs to Record-Route to stay on the signaling path for all subsequent messages so that it can translate the underlaying transport protocol (IPv6/IPv4).

Raimo Kantola –S- 2005 Signaling Protocols 12 - 63

Diameter is the emerging AAA protocol for the Internet and 3G

• Applications include:

– Network Access Servers for dial-up with PPP/SLIP,

– Mobile IPv4 Foreign Agents,

– Roaming 3G and Internet users (SIP Application).

– Credit Control

• Provides Authentication of users, Authorization and Accounting of use

• Carried over TCP or SCTP

Client

REQ

NAS: Network Access

Server

Mobile IPv4 FA

S-CSCF

Answer

Agent

Relay

Proxy

Redirect Agent

Request

Answer

Server Msg e.g. stop service now

Server e.g.

-Policy server

- HSS

Raimo Kantola –S- 2005 Signaling Protocols 12 - 64

32

Overall Diameter Architecture

Credit Control

Application

Network Access

Server

Application

Mobile IPv4

Application

SIP

Application

Diameter Base Protocol (RFC 3588)

Raimo Kantola –S- 2005 Signaling Protocols 12 - 65

Diameter documents

Internet-Drafts:

Diameter Mobile IPv4 Application (134692 bytes)

Diameter Network Access Server Application (197153 bytes)

Diameter Extensible Authentication Protocol (EAP) Application (89596 bytes)

GSMPv3 Base Specification (264992 bytes)

Diameter Credit-control Application (303309 bytes)

Diameter Session Initiation Protocol (SIP) Application (170592 bytes)

Request For Comments:

Accounting Attributes and Record Formats (RFC 2924) (75561 bytes)

Introduction to Accounting Management (RFC 2975) (129771 bytes)

Criteria for Evaluating AAA Protocols for Network Access (RFC 2989) (53197 bytes)

Authentication, Authorization, and Accounting:Protocol Evaluation (RFC 3127) (170579 bytes)

Authentication, Authorization and Accounting (AAA) Transport Profile (RFC 3539) (93110 bytes)

Diameter Base Protocol (RFC 3588) (341261 bytes)

Date: 29.12.2004, source: http://www.ietf.org/html.charters/aaa-charter.html

Raimo Kantola –S- 2005 Signaling Protocols 12 - 66

33

Diameter features include

- Delivery of attribute value pairs: AVPs

- Capability negotiation

- Error Notification

- Extensibility

- Sessions and Accounting

User Authentication

Service specific authentication info -> grant service or not

Resource usage information

- accounting and capacity planning is supported

Relay, proxy and redirect of requests thru a server hierarchy

Raimo Kantola –S- 2005 Signaling Protocols 12 - 67

Diameter operation model

User NAI

Local Realm

Client

Relay

Routing

Security Association

TCP/SCTP SCTP/TCP

Proxy

Policy

Roaming Relationship

Home Realm

SCTP/TCP

Home

Server

User Session

Accounting Relationship

NAI – Network Access Identifier = user’s-identity + realm

Raimo Kantola –S- 2005 Signaling Protocols 12 - 68

34

Diameter terms and definitions

Accounting

The act of collecting information on resource usage for the purpose of capacity planning, auditing, billing or cost allocation.

Authentication

The act of verifying the identity of an entity (subject).

Authorization

The act of determining whether a requesting entity (subject) will be allowed access to a resource (object).

AVP

The Diameter protocol consists of a header followed by one or more Attribute-Value-Pairs (AVPs).

AVP = header encapsulating protocol-specific data (e.g. routing information) + AAA information.

Broker

A broker is a business term commonly used in AAA infrastructures. A broker is either a relay, proxy or redirect agent, and MAY be operated by roaming consortiums. Depending on the business model, a broker may either choose to deploy relay agents or proxy agents.

Diameter Agent = Diameter node that provides either relay, proxy, redirect or translation services.

Diameter Client = a device at the edge of the network that performs access control. Examples are a Network Access

Server (NAS) or a Foreign Agent (FA).

Diameter Node = a host process that implements the Diameter protocol, and acts either as a Client, Agent or Server.

Raimo Kantola –S- 2005 Signaling Protocols 12 - 69

More Diameter terms

Diameter Security Exchange = a process through which two Diameter nodes establish end-to-end security.

Diameter Server = one that handles AAA requests for a particular realm. By its very nature, a Diameter Server

MUST support Diameter applications in addition to the base protocol.

End-to-End Security

TLS and IPsec provide hop-by-hop security, or security across a transport connection. When relays or proxy are involved, this hop-by-hop security does not protect the entire Diameter user session. End-to-end security is security between two Diameter nodes, possibly communicating through Diameter Agents. This security protects the entire Diameter communications path from the originating Diameter node to the terminating Diameter node.

Home Realm = the administrative domain with which the user maintains an account relationship.

Interim accounting

An interim accounting message provides a snapshot of usage during a user's session. It is typically implemented in order to provide for partial accounting of a user's session in the case of a device reboot or other network problem prevents the reception of a session summary message or session record.

Local Realm

A local realm is the administrative domain providing services to a user. An administrative domain MAY act as a local realm for certain users, while being a home realm for others.

Raimo Kantola –S- 2005 Signaling Protocols 12 - 70

35

Still more terms

Network Access Identifier or NAI [NAI] = a user's identity + realm.

The identity is used to identify the user during authentication and/or authorization, the realm is used for message routing purposes.

Proxy Agent or Proxy

- forward requests and responses,

- proxies make policy decisions relating to resource usage and provisioning. This is typically accomplished by tracking the state of NAS devices.

- proxies typically do not respond to client Requests prior to receiving a Response from the server,

- they may originate Reject messages in cases where policies are violated.

- proxies need to understand the semantics of the messages passing through them, and

- may not support all Diameter applications.

Real-time Accounting

Real-time accounting involves the processing of information on resource usage within a defined time window.

Time constraints are typically imposed in order to limit financial risk.

Relay Agent or Relay

- Relays forward requests and responses based on routing-related AVPs and realm routing table entries.

- do not make policy decisions, they do not examine or alter non-routing AVPs.

- relays never originate messages, do not need to understand the semantics of messages or non-routing AVPs,

- are capable of handling any Diameter application or message type.

- do not keep state on NAS resource usage or sessions in progress.

Raimo Kantola –S- 2005 Signaling Protocols 12 - 71

The last terms

Redirect Agent

- refer clients to servers and allow them to communicate directly.

- do not sit in the forwarding path Æ they do not alter any AVPs transiting between client and server.

- do not originate messages and

- are capable of handling any message type, although they may be configured only to redirect messages of certain types, while acting as relay or proxy agents for other types.

- do not keep state with respect to sessions or NAS resources.

Roaming Relationships

Roaming relationships include relationships between companies and ISPs, relationships among peer ISPs within a roaming consortium, and relationships between an ISP and a roaming consortium.

Security Association

A security association is an association between two endpoints in a Diameter session which allows the endpoints to communicate with integrity and confidentially, even in the presence of relays and/or proxies.

Session = a related progression of events devoted to a particular activity. Each application SHOULD provide guidelines as to when a session begins and ends. All Diameter packets with the same Session-Identifier are part of the same session.

Sub-session represents a distinct service (e.g. QoS or data characteristics) provided to a given session. These services may happen concurrently (e.g. simultaneous voice and data transfer during the same session) or serially. These changes in sessions are tracked with the Accounting-Sub-Session-Id.

Translation Agent performs protocol translation between Diameter and another AAA protocol, such as RADIUS.

Raimo Kantola –S- 2005 Signaling Protocols 12 - 72

36

Access is broken into sessions:

Diameter authorizes sessions

Client

Initial Request for Autentication/authorization: IRA

[Session-id] whatever

[Session-id]

Server

Session Termination Request: STR [Session-id]

Session Termination Answer: STA [Session-id]

Raimo Kantola –S- 2005 Signaling Protocols 12 - 73

A diameter node has a peer table

Host identity Status Stat/ Dyn Expiration time TLS enabled Additional Security info origin host

-from capability exchange:

CER/CEA

- Closed

- Wait-conn-ack

- wait-I-CEA

- wait-I-CEA/Elect

- wait-returns

- R-Open

- I- Open

- ….

- …

- Stop

- = state of the “dialog” with the peer

The peer table is referenced by

Realm Routing Table.

The peer relationship may be dynamically established – will have an expiration time.

Raimo Kantola –S- 2005 Signaling Protocols 12 - 74

37

Diameter peer discovery helps scalability: order is as follows

• Search manually configured peer agent list

• Use SLPv2 (service location protocol)

• NAPTR query to DNS (”AAA+D2x where x=T|S, T=tcp, S=sctp) – gives the preferred SRV record, a new query gives the IP address

• query `_diameter._sctp´.realm and

`_diameter._tcp´.realm, where realm is the destination realm

Raimo Kantola –S- 2005 Signaling Protocols 12 - 75

Realm Routing Table describes the actions of a Diameter Node

Primary Key Secondary key

Realm-name Application-id Local Action Next-Hop

- vendor-id

- application-id

Local

Relay

[Transaction State]

Server Failover

Proxy

Redirect

Local Policy

Processing

[Session state]

Breaks end-to-end security

Home Diameter Server identity

Default Entry for Non-matching Requests

A node can act as proxy for some user connections and as a relay for others.

The Routing Table is configuration information.

Raimo Kantola –S- 2005 Signaling Protocols 12 - 76

38

Redirect server helps to centralize Diameter request routing in a roaming consortium

NAS example.net

1. Request

6. Answer

2. Request

Redirect

Server

Use Example:

Service Location Function:

SLF in 3G to locate HSS

3. Redirect Notification

Relay example.net

4. Request

5. Answer

Home

Server example.com

Raimo Kantola –S- 2005 Signaling Protocols 12 - 77

A node must watch over its peers to achieve security

Authorized user session

Check Record-Route AVP

Client

Route-Record AVP

Authorized connection Authorized connection

Replay&integrity protection&Confidentiality/packet

Capability Request

Advertize Applications

Credit-limit

HMS

- Capability negotiation tells a node what to expect of a peer

- Authorization means taking a business risk, limited by Credit limit agreed by the peer realms.

Raimo Kantola –S- 2005 Signaling Protocols 12 - 78

39

Diameter header is designed for max flexibility

Version=1

Command Flags

Message Length

Command-Code

Application-ID

Hop-by-Hop Identifier

End-to-End Identifier

AVPs

R(equest) – if 0 = Answer

P(roxiable) – if 0 msg must be locally processed

E(rror) – only set in Answer msgs.

T(potentially re-transmitted message

- set after failover to help remove duplicate messages

Raimo Kantola –S- 2005 Signaling Protocols

Application-ID: e.g. 3GPP application

Normally +1 increasing number on a connection

Same for Request and the corresponding Answer

Client sets to locally unique value (4 min) even over Reboots

Server copies from Request to Answer

12 - 79

Base Diameter protocol Requests and Answers

Diameter node Diameter node

Abort-Session-Request: ASR

Abort-Session-Answer: ASA

Accounting-Request: ACR

Accounting-Answer: ACA

Capabilities-Exchange-Request: CER

Capabilities-Exchange-Answer: CEA

Device-Watchdog-Request: DWR

For each Command-code

Spec contains exact possible flags, required and optional

AVPs and their nr.

Applications introduce additional command-codes and their exact syntax.

Device-Watchdog-Answer: DWA

Disconnect-Peer-Request: DPR

Disconnect-Peer-Answer: DPA

Re-Auth-Request: RAR

Re-Auth-Answer: RAA

Session-Termination-Request: STR

Session-Termination-Answer: STA

Raimo Kantola –S- 2005 Signaling Protocols 12 - 80

40

Base protocol AVPs

AVPs have a common header

VMPrrrrr

AVP Code

AVP Length

Vendor-ID (opt)

Data…

V-vendor-id present

M-Mandatory AVP

P-encryption for e-2-e sec

In AVPs e.g. the following items may appear:

- IPaddress

- Time

- UTF8String

- Diameter Identity = FQDN

(fully qualified domain name)

- Diameter URI such as

”aaa://” FQDN [port] [transport] [protocol] aaa://host.example.com:1813;transport=sctp; protocol=radius

- IPFilterRule such as action dir proto from src to dst [options], where action =permit|deny dir=in|out (in = from the terminal) src/dst = <address/mask> [ports]

You can specify firewall rules in Diameter.

Raimo Kantola –S- 2005 Signaling Protocols 12 - 81

A diameter node operation is described as a set of state machines

• Peer state machine

• Authorization Session State Machines (4)

– Server maintains session state: client FSM and server

FSM

– Server does not maintain session state: client FSM and server FSM

• Accounting Session State Machines

– Client state machine

– Server state machines: stateless and stateful

– may be overridden by applications

Raimo Kantola –S- 2005 Signaling Protocols 12 - 82

41

Summary of Diameter scalability cmp.

Radius

Radius is the current standard for AAA in the Internet. E.g. when an ISP uses accesses the Internet thru a modem line, the POP uses Radius to contact a DB in order to check access rights.

Radius problems are: vulnerability to certain attacks, limited set of attributes are supported and the architecture was designed based on the Client-Server Model.

Add mobile roaming users: Users can roam in many networks owned by hundreds or even thousands of Operators all over the world. The set of offered services is extended – a lot of attributes are needed to describe authorization. The visited network should know about the visitor as little as possible but still be able to route AAA –requests to the home network.

The solution is DIAMETER: introduces proxies, relays, redirect servers + a very flexible protocol message coding + base protocol and extensions architecture. Also Diameter is reliable, runs over TCP or SCTP rather than UDP, less vulnerable to attacks and fraud than Radius.

Challenge is to introduce Diameter when the existing infra is based on Radius. Interoperability of the two protocols becomes key to deployment of Diameter.

Raimo Kantola –S- 2005 Signaling Protocols 12 - 83

Server may require

Re-authentication/authorization

Client Server

Re-Auth-Request: RAR

Re-Auth-Answer: RAA

A successful RAA must be followed by application specific

Authentication/authorization message

Use example: enforcing a credit limit on a user during a long telephone call.

Raimo Kantola –S- 2005 Signaling Protocols 12 - 84

42

NASREQ defines an authentication and authorization application

draft-ietf-aaa-diameter-nasreq-10.txt of Nov 2002.

Capabilities-Exchange-Request: CER

[Application-ID=1 (=NASREQ)]

Capabilities-Exchange-Answer: CEA

[Application-ID=1 (=NASREQ)]

In Capabilities exchange peers agree to understand NASREQ commands.

Client Server

NAS (PoP) initiates a new session.

AA-Request: AAR

<session-id> …

AA-Answer: AAA

[Diameter_multi_round_Auth]

AA-Request: AAR

AA-Answer: AAA

HMS may challenge the user.

User has to respond to challenge additional rounds|Accounting, Re-Auth… Accounting is defined in BASE.

AAR and AAA have loads of AVPs!

Raimo Kantola –S- 2005 Signaling Protocols 12 - 85

Diameter SIP Application

Command Name | Abbr.

Registration-Termination-Request | RTR

Source: http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-sip-app-05.txt

Raimo Kantola –S- 2005 Signaling Protocols 12 - 86

43

Diameter Credit Control Application

• The Diameter CC Application provides

– support for prepaid services

– real time credit control for the service

• Two mandatory messages

– CCR – Credit Control Request

– CCA – Credit Control Answer

• The CC Server can be different from the rest of Diameter AAA servers

Raimo Kantola –S- 2005 draft-ietf-aaa-diameter-cc-06.txt

Signaling Protocols 12 - 87

3G IMS Diameter migrating to SIP Application

I-CSCF

Cx

Cx-Query+CX-Select-Pull

=User-Authorization-Req: UAR

HSS

Cx-Query Resp+Cx-Sel-Pull Resp

=User-Authorization-Ans: UAA

Cx-Location-Query

Location-Info-Req: LIR

Cx-Location-Query Resp

Location-Info-Ans: LIA

Cx interface runs over SCTP

S-CSCF

Cx

HSS

Cx-Put + Cx-Pull

Server-Assignment-Req: SAR

Cx-Put Resp+ Cx-Pull Resp

Server-Assignment-Ans: SAA

Cx-AuthDataReq

Multimedia-Auth-Req: MAR

Cx-AuthDataResp

Multimedia-Auth-Ans: MAA

Cx-Deregister

Registration-Termination-Req:RTR

Cx-Deregister Resp

Registration-Termination-Ans:RTA

Dx

Raimo Kantola –S- 2005

SLF

Dx

Signaling Protocols

Cx-Update_Subscr-Data

Push-Profile-Request: PPR

Cx-Update_Subscr-Data Resp

Push-Profile-Answer: PPA

12 - 88

44

Use of Diameter in 3G IMS

• 3GPP has a Vendor-ID, 3GPP Multi Media Application is defined as a vendor specific application. Is expected to migrate to the future

Diameter SIP Application when that becomes RFC.

• Cx and Dx interfaces are the same. The difference is that Dx points to a Diameter Redirect Agent and Cx to a Diameter Server (HSS)

• ”Cellular” Location management maps into MAP operations in

SGSN+GGSN+ Registration/De-Registration in SIP terms maps to

Authorization-Request/-Answer in Diameter + S-CSCF obtaining

Subcr data = Diameter SAR/SAA etc.

– User-Location-Query is used to obtain S-CSCF identity

– I-CSCF can use Diameter Redirect capability in SLF (Dx interface):

Server-Location-Function to select S-CSCF/user-identity

– I-CSCF is stateless, so SLF has to be used for every query

– S-CSCF is stateful and will cash HSS address for the session.

• There is also a Diameter Application for AS to HSS interface (Sh

Interface). This is vendor specific where 3GPP is the vendor.

Raimo Kantola –S- 2005 Signaling Protocols 12 - 89

Registration – user not registered

UA

Visited Network

P-CSCF

1.Register

2.Register

10. 401 Unauthorised

11.Register, RES

I-CSCF

Home Network

HSS

S-CSCF

S-CSCF selection

9. 401 Unauthorised

5.Register

6.MAR

Authe Vector Selection

7.MAA

RAND||AUTN||XRES||CK||IK

8. 401 Unauthorised,

RAND||AUTN

12.Register

3.UAR

4.UAA

13.UAR

14.UUA

15.Register

16.SAR

17.SAA

Authentication

20. OK

19. OK

18. OK,

CK||IK

Raimo Kantola –S- 2005 Signaling Protocols 12 - 90

45

Registration – user currently registered

UA

Visited Network

P-CSCF

1.Register

2.Register

I-CSCF

3.UAR

4.UUA

S-CSCF selection

Home Network

HSS

5.Register

S-CSCF

6.SAR

7.SAA

Authentication

10. OK

9. OK

8. OK

• Registration may need to be refreshed from time to time.

• Location changes may require re-registration.

• Mobile Initiated de-registration looks exactly the same!

Raimo Kantola –S- 2005 Signaling Protocols 12 - 91

UA

Many ways/reasons to de-register

Visited Network

P-CSCF

1. Timer Expires

HSS

Home Network

S-CSCF

2.SAR

3.SAA

1. Timer Expires Registration timeout

Remove S-CSCF addess from HSS

6. Notify (reg)

1. RTR

2. RTA

3. Notify (reg)

4. 200 OK

5. Notify (reg)

8. 200 OK

Administrative de-registration

Both P-CSCF and the terminal have subscribed to the reg state!

3. UE Inform

5. 200 OK

2. De-register

1. Service Control

4. 200 OK

6. SAR

7. SAA

De-registration initiated by Service Platform

Raimo Kantola –S- 2005 Signaling Protocols 12 - 92

46

Mobile Terminated SIP Session Set-up is similar to MAP MT call

I-CSCF

1. INVITE

2. LIR

Home Network

HSS

S-CSCF

3. LIA

4. INVITE cmp: SendRoutingInformation of MAP

HSS knows the name (and address) of

S-CSCF – no RoutingNumber is needed from ”VLR”. So there is a difference in how routing and addressing operates in GSM and in 3G IMS.

1. INVITE

4. S-CSCF Selection

2. LIR

3. LIA

5. INVITE

Initiation of a session to a non-registered user.

6. SAR

7. SAA

8. Service Control further actions

When there is a change in the user profile HSS issues

Push-Profile-Request: PPR and

S-CSCF answers by PPA.

This transaction is unrelated to any SIP signaling.

Raimo Kantola –S- 2005 Signaling Protocols 12 - 93

Summary

• IP telephony requires many supporting protocols.

• Many IETF protocols overlap with GSM protocols (e.g.

Diameter with MAP) in terms of functionality

• IETF development model is one protocol for one problem.

• Client-Server model is used whenever possible.

• The drive is towards providing PSTN like control over services and over what a user can do in the IP environment.

• Through access to the Internet, the open Internet model lives on.

Raimo Kantola –S- 2005 Signaling Protocols 12 - 94

47

Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement