nokia sgsn intergace

8/12/2019 nokia sgsn intergace

http://slidepdf.com/reader/full/nokia-sgsn-intergace 1/28

Nokia GGSN Release 5.0

Go Interface Description

dn0534287Issue 1

© Nokia Oyj 1 (28)




The information in this document is subject to change without notice and describes only theproduct defined in the introduction of this documentation. This document is intended for theuse of Nokia's customers only for the purposes of the agreement under which the document issubmitted, and no part of it may be reproduced or transmitted in any form or means withoutthe prior written permission of Nokia. The document has been prepared to be used by

professional and properly trained personnel, and the customer assumes full responsibilitywhen using it. Nokia welcomes customer comments as part of the process of continuousdevelopment and improvement of the documentation.

The information or statements given in this document concerning the suitability, capacity, orperformance of the mentioned hardware or software products cannot be considered bindingbut shall be defined in the agreement made between Nokia and the customer. However,Nokia has made all reasonable efforts to ensure that the instructions contained in thedocument are adequate and free of material errors and omissions. Nokia will, if necessary,explain issues which may not be covered by the document.

Nokia's liability for any errors in the document is limited to the documentary correction oferrors. NOKIA WILL NOT BE RESPONSIBLE IN ANY EVENT FOR ERRORS IN THISDOCUMENT OR FOR ANY DAMAGES, INCIDENTAL OR CONSEQUENTIAL (INCLUDINGMONETARY LOSSES), that might arise from the use of this document or the information in it.

This document and the product it describes are considered protected by copyright accordingto the applicable laws.

NOKIA logo is a registered trademark of Nokia Oyj.

Other product names mentioned in this document may be trademarks of their respectivecompanies, and they are mentioned for identification purposes only.

Copyright © Nokia Oyj 2005. All rights reserved.

2 (28) © Nokia Oyj dn0534287Issue 1



Contents

Contents

1 Introduct ion ............................................................................................7

2 Interface descript ion ..............................................................................9

3 Notes about 3GPP 29.207 ....................................................................11 3.1 Scope .......................... ............................ ............................ ...................11 3.2 References.............................................................................................11 3.3 Definitions and abbreviations .......................... ........................... ............11 3.4 Go interface............................................................................................11 3.4.1 Overview ............................. ............................ ............................ ...........11 3.4.2 Go reference model................................................................................12 3.4.3 Functional elements and capabilities .......................... .......................... .12 3.5 Policy control procedures.......................................................................14 3.5.1 GGSN.....................................................................................................14 3.5.2 PDF ........................... ............................ ............................ .....................15 3.6 Go protocol.............................................................................................18 3.6.1 Protocol support .......................... ............................. ............................ ..18 3.6.2 Basic COPS events/messages .......................... ............................ ........19 3.6.3 Go events/messages .......................... ............................. ......................20 3.6.4 Go data .......................... ............................. ............................ ...............22 3.6.5 Security Considerations ........................ ............................ .....................22 3.7 Annex A: (Void) .......................... ............................ ............................ ....22 3.8 Annex B (normative): 3GPP Go PIB ........................... ...........................22 3.9 Annex C (normative): Flow identifiers: Format definition and

examples................................................................................................22 3.10 Annex D (normative): Go interface related error code values forthe PDP context handling.......................................................................22

4 Notes about RFC 2748, The COPS (Common Open Polic yService) Prot ocol ..................................................................................23

4.1 Introduction ............................ ............................ ............................. .......23 4.1.1 Basic Model............................................................................................23 4.2 The Protocol...........................................................................................23 4.2.1 Common Header....................................................................................23 4.2.2 COPS Specific Object Formats..............................................................23 4.2.3 Communication ........................... ............................ ............................. ..23 4.2.4 Client Handle Usage ........................ ............................. .........................23 4.2.5 Synchronization Behavior.......................................................................23 4.3 Message Content ............................ ............................. ..........................23 4.3.1 Request (REQ) PEP -> PDP............................. ............................. .......24 4.3.2 Decision (DEC) PDP -> PEP.................... ............................ .................24 4.3.3 Report State (RPT) PEP -> PDP.................. .............................. ...........24 4.3.4 Delete Request State (DRQ) PEP -> PDP.......................... ..................24 4.3.5 Synchronize State Request (SSQ) PDP -> PEP.......................... .........25 4.3.6 Client-Open (OPN) PEP -> PDP ............................. ..............................25 4.3.7 Client-Accept (CAT) PDP -> PEP .......................... ............................ ...25

dn0534287Issue 1

© Nokia Oyj 3 (28)




4.3.8 Client-Close (CC) PEP -> PDP, PDP -> PEP.............. ......................... 25 4.3.9 Keep-Alive (KA) PEP -> PDP, PDP -> PEP ............................. ............ 25 4.3.10 Synchronize State Complete (SSC) PEP -> PDP .............................. ... 25 4.4 Common Operation ......................... ............................ .......................... 25 4.4.1 Security and Sequence Number Negotiation .......................... .............. 25 4.4.2 Key Maintenance............................ .............................. ......................... 25 4.4.3 PEP Initialization.......................................... ............................ .............. 25 4.4.4 Outsourcing Operations...................................... ............................ ....... 25 4.4.5 Configuration Operations......................................... ............................ .. 25 4.4.6 Keep-Alive Operations...................................... ............................ ......... 25 4.4.7 PEP/PDP Close......... ............................. ............................ ................... 25 4.5 Security Considerations........................ ............................ ..................... 25 4.6 IANA Considerations .......................... ............................. ...................... 26




Summary of changes

Summary of changes

This is the first issue of this document.

This document version applies to Nokia GGSN Release 5.0 and Nokia PolicyDecision Function (PDF) in IMC Release 2.

dn0534287Issue 1

© Nokia Oyj 5 (28)



Introduction

1 Introduction In the 3GPP Release 5 network architecture a new entity, Policy DecisionFunction (PDF), has been defined. The purpose of the PDF is to apply policy tothe bearer usage in the GGSN with an IP Multimedia Subsystem (IMS) session.In Release 5 the PDF is co-located with the Proxy Call State Control Function(P-CSCF). The PDF interfaces with the GGSN via the standardized Gointerface.

With Go interface the PDF can tell to GGSN, what kind of user plane packets(“flows”) are forwarded through GGSN and what kind of quality of service isallowed. Identifiers for charging correlation are exchanged via Go interface,too.

The subchapters under Chapters "Notes about 3GPP 29.207" and "Notes aboutRFC 2748, The COPS (Common Open Policy Service) Protocol" are organisedaccording to the corresponding standards. An empty chapter means that thechapter in the standard describes the interface sufficiently and no exceptions orclarifications are needed in this document.

P-CSCF

PDF (Policy Decision Function)

IP BS Manager

PEP (Policy Enforcement Point)

IP BS Manager

SIP Client

Translation/mapping function

Translation/mappingfunction

UMTS BS Manager UMTS BS Manager

Go

Signalling path

GGSN UE

dn0534287Issue 1

© Nokia Oyj 7 (28)



Interface description

2 Interface description Go interface complies with [3GPP29.207], Policy Control over Go Interface,unless otherwise stated in this document.

Next chapter follows the structure of that technical specification, but it is notcomplete table of contents. Following chapters describe clarifications,deviations from standards and partial or missing implementation compared tostandards.

GGSN implements Framework Policy Information Base IETF draft 07, even ifthere is an RFC already [RFC3318]. PDF implements RFC3318.

The Go protocol is run over TCP and Ipv6 [RFC2460] , though PDF supportsIPv4 including IPSec for lower layer security as well.

This document does not describe interoperability between TCP and Ipv6implementations, but it concentrates on issues specific to policy control.

dn0534287Issue 1

© Nokia Oyj 9 (28)



Notes about 3GPP 29.207

3 Notes about 3GPP 29.207 3.1 Scope

3.2 References

3.3 Definit ions and abbreviations

3.4 Go interface

3.4.1 Overview

29.207: “It is assumed that only one set of binding information is carried withina PDP context in this Release.”

GGSN supports multiple sets of binding information. For session multiplexing purposes PDF also supports multiple sets of binding information. 29.207: “Toauthorise the PDP context modification, the GGSN shall send a mediaauthorisation request to the PDF when the requested QoS exceeds the

authorised QoS or new binding information is received.”GGSN implements this condition. It means that GGSN does not always sendrequest to PDF, when user entity initiates PDP context modifications.

dn0534287Issue 1

© Nokia Oyj 11 (28)




3.4.2 Go reference model

3.4.3 Functional elements and capabilit ies

3.4.3.1 GGSN

5.4.3.1.1 Service-based local poli cy enforcement poin t

Clarification:

29.207: “The GGSN may cache the policy decision data of the PDF decisions.This cached information may be used later for a local policy decision allowingthe GGSN to make policy control decision about the QoS authorization for PDPcontext modifications without requiring additional interaction with the PDF in

case the modification request does not exceed the previously authorized QoS.”GGSN implements this. GGSN does not contact PDF, if mobile station modifiesthe QoS to lower value than granted earlier by PDF.

QoS Information processing

GGSN implementation decision:

GGSN does not police uplink traffic based on Quality of service limit.

Rationale: It is assumed that the policing or limitation is in the radio network.

5.4.3.1.2 Initi alisation and maintenance

5.4.3.1.3 Gate funct ion

5.4.3.1.4 Void

5.4.3.1.5 Bind ing mechanism handling

Contradiction in standards:

“If no IMS session can be found for an authorisation token, or if the PDF isotherwise unable to authorise the binding information, the PDF shall send aCOPS decision message carrying both an INSTALL and REMOVE decision.The INSTALL decision shall identify an authorisation failure to the GGSN, andmay include further details identifying the cause. The REMOVE decision shallsubsequently remove this state from the GGSN. For an initial authorisation, thePDF shall then initiate a remove for the authorisation request."





COPS RFC says that remove decisions should be first and install decisions afterthat. GGSN will accept the message described in Go specification.

Design decision:

29.207: “When the GGSN receives a secondary PDP context activation requestto an APN for which the Go interface is enabled and no binding information isreceived, the GGSN may either reject the secondary PDP context activationrequest, or accept it within the limit imposed by a locally stored QoS policy.This local QoS policy shall be operator configurable within the GGSN. If therequest is rejected, the reason for the rejection is indicated to the UE with theerror code value "Missing binding information" (see annex D).”

GGSN compares the traffic class value proposed by mobile station andcompares that to the configured limit. If the traffic class is lower, GGSN acceptsthe PDP context activation request.

3.4.3.2 PDF

3.4.3.2.1 Service-based local poli cy decisi on poin t

3.4.3.2.2 Initi alisation and maintenance

Switchoff

PDF is an optional feature, and can be switched on and off anytime. If PDF isswitched off, all COPS connections to GGSNs are closed, and new connections

are rejected.If the Call Processing Server (CPS) is shut down in a graceful manner, the SIPdialogues are expected to finish normally, so the PDP contexts regarding tothose sessions should also disappear due to the normal PDP context deactivation

procedure.

If the Call Processing Server is shut down in an ungraceful manner, nomessages will be sent by PDF on the Go interface. GGSN should be able tohandle that situation and close the COPS connection using the keep-alive timer.

3.4.3.2.3 Bind ing mechanism handling

PDF is able to use multiple sets of binding information. This functionality can be used if multiple sessions are multiplexed in one PDP context (such as inPush-to-talk over Cellular cases). To avoid incompatibilities, PDF willannounce the support for the same number of binding information that GGSNannounces during initial capability negotiation.

FQDN in binding information

dn0534287Issue 1





The Call Processing Server is a cluster of signalling nodes that appears as asingle PDF entity towards the GGSN. Therefore the Fully Qualified Domain

Name (FQDN) in the authorization token will resolve to a virtual IP address that points to the PDF part of the Call Processing Server. The message will then bedistributed to the corresponding signalling node by internal load balancing

procedures.

3.5 Policy control procedures

3.5.1 GGSN

3.5.1.1 Initi al authori zation at PDP cont ext activation

If Go interface is in use, and a REQ was sent, GGSN always expects the QoS parameters from PDF, so there is no way that the PDF could delegate the policydecision to GGSN. If no DEC is received, or the DEC was erroneous, the PDPcontext activation will be rejected.

3.5.1.2 Modification of previously author ized PDP cont ext

3.5.1.3 Session modif ication init iated decis ion

“When the GGSN receives an unsolicited authorisation decision from the PDF,the GGSN shall also install the new set of packet classifiers, removing anyexisting packet classifiers that are not included in the new set.”

Deviation from the standard: The specification mentions only unsoliciteddecision. If GGSN receives solicited decision, it behaves in the same way asspecified for the unsolicited case: GGSN installs the new set of packetclassifiers, removing any existing packet classifiers that are not included in thenew set.

3.5.1.4 PDP cont ext deactivation

3.5.1.5 Gate cont rol operation

Clarification: If DEC message contains a go3gppGateDecEntry object and

remove operation, the DEC message is rejected and GGSN sends an error codein the RPT message to PDF.

Rationale: The text part does not specify any useful purpose of removing gateswith a “gate decision” message. The text says that gate decision contains aninstall decision.





3.5.1.6 User plane operat ion

3.5.2 PDF

3.5.2.1 SBLP decisi ons

3.5.2.1.1 SBLP authori sation decision

Clarification of ambiguous statement in the standard:

29.207: “Upon receiving the modified SDP information from the P-CSCF, thePDF shall update the media authorization information for the session. The PDFmay push this updated authorisation information to the GGSN. Under certaincondition e.g. revoke of authorization, the PDF shall push the updated policy

decision to the GGSN.”When the GGSN receives an unsolicited authorisation decision from the PDF,the GGSN shall install the new set of packet classifiers according to receiveddecision and removes any existing packet classifiers that are not included in thenew set.

On the other hand, gate decisions, are additive in nature, meaning that a specificcommand (open or close) will be applied to existing gates. The status ofexisting gates will not change unless explicitly mentioned in a COPS DECmessage either part of an authorization decision or a separate gatedecision.Algorithms for the authorized QoS

The algorithms defined in 29.207 chapter 7 are implemented in a slightlydifferent manner in PDF. Specifically there are cases in the described algorithmwhere the traffic would be treated as uplink instead of downlink or vice versa.PDF’s direction calculation is based on whether the sender of the SDP offer wassent by the served party or not.

3.5.2.1.2 Session modi fic ation init iated decisi on

PDF supports unsolicited decision, if the media parameters change. We have tomake a distinction though for different cases based on the nature of the change.

1. If there is a change in the IP filters, but not in the authorized QoS (e.g. port change), no PDP context modification is needed, so the new parameters are sent in a COPS decision right away.

2. If the QoS is decreased, the PDP context has to be modified. This canhappen if the bandwidth or traffic class is lowered, a media line is deletedfrom the SDP, or a but last session is terminated in case of sessionmultiplexing. PDF will send unsolicited decision immediately in case theQoS decrease is committed on SIP signalling. Committing means that thecorresponding SIP transaction (INVITE or UPDATE) was finishedsuccessfuly. In case the QoS decrease is not committed, PDF will not

dn0534287Issue 1





send unsolicited decision, but waits for authentication request fromGGSN or sends unsolicited decision when the corresponding SIPtransaction is finished .

1. If QoS is increased, no decision is sent, because the user must initiate aPDP context modification to make use of the extra resources. In that casethe GGSN will contact the PDF, and the increased QoS will be given in asolicited decision

If a new media line is added, no decision is sent, because the PDF does notknow in advance which PDP context will contain this new media flow until the

binding information is received from the GGSN. GGSN behaviour in case ofconcurrency:

DEC(solicited)

RPT (success)

GGSN PDF

DEC(unsolicited)

RPT (fail)

REQ

Figure 1. Collision of REQ and DEC

In case when mobile station initiates update PDP context and the PDF initiatesunsolicited decision, the message sequences in figure 1 can take place.

Note: PDF will not send the solicited DEC until the failure RPT has beenreceived, so the figure would look slightly different between Nokia GGSN and

Nokia PDF described in this document.

3.5.2.1.3 SBLP revoke decisi on

PDF will send a revoke decision if all sessions inside that PDP context have been terminated. Revoke decisions will also be sent in the error cases defined in29.207. Revoke decision will be sent in case of a bearer-loss indication after anoperator-given time (unless a bearer regained indication was received).





Possible Collision Sequences in GGSN

GGSN PDF

DEC(revoke)

RPT (success)

REQ

DRQ

Figure 2. Collision of REQ and DEC(revoke) messages

If UE wants to upgrade the context and PDF wants to revoke, message sequencein figure 2 can take place.

DRQ

GGSN PDF

DEC(revoke)

Figure 3. Collision of DRQ and DEC(revoke) messages

When UE and PDF want to deactivate the PDP context, the message sequencein Figure 3 can take place.

3.5.2.1.4 SBLP gate decision

PDF implements the gating functionality, but its behaviour is configurablethrough the gate open policy parameter.

• If the gate open policy is set to “immediate”, the gate open commandsappear in the first authorization decision applicable.

• If the gate open policy is set to “open at 200 OK”, the initial authorizationdecision will only contain QoS parameters, but will not open the gates. A

dn0534287Issue 1





separate gate decision will be sent when the session setup has finished(triggered by the 200OK SIP message for the initial INVITE). This willensure that the user cannot use the media until the session is successfullyset up, but will also increase the traffic on the Go interface.In case of session modification the old gates will be closed and the newgates will be opened by the first solicited or unsolicited decisionapplicable, just as in the “immediate apply” case.

Note: There might be a separate QoS commit in case of modification, butthis is for further study. Main rationale is to avoid media clipping caused

by the prematurely closed gates for the original media.

Gate close commands are used in media-on-hold cases. The trigger is thechange in the media direction: sendr ecv- >sendonl y , sendr ecv->r ecvonl y and the i nact i ve attribute (regardless of the previousdirection). In those cases the gates corresponding to the closed direction(s) areclosed but the QoS is not decreased to allow a quick resume without PDP

context modification.

3.5.2.2 Support for forking

SIP forking is not supported in IMC release 2.

3.6 Go protocol

3.6.1 Protocol support3.6.1.1 TCP connection for COPS protocol

Clarification to GGSN behaviour:

29.207: “The GGSN receives the PDF identifier received as part of theAuthorization Token, during the secondary PDP context activation or PDPcontext modification procedure. The GGSN resolves the PDF IP address fromthe PDF identifier, which is in the form of a fully qualified domain name.”

GGSN uses the domain name received in the PDP context activation GTPmessage. GGSN does not use the domain name received in PDP contextmodification GTP message, but GGSN contacts the same PDF as during theoriginal activation.

Deviation from standard:

29.207: “If there is no existing TCP connection to the PDF, the GGSN shallestablish a TCP connection for COPS interactions to the PDF.”

A list of PDF domain names is pre-configured in the GGSN, and GGSN createsTCP connection to those as soon as possible. GGSN does not create connectionsto any other PDF instances.





3.6.1.2 COPS pro tocol

RFC 2748, chapter 3. Message Content: “The Integrity object, if included,MUST always be the last object in a message.”

GGSN does not send or check integrity object.PDF does not send or check integrity object.

29.207: “Protocol stack: IP, TCP and COPS.”

GGSN supports only IPv6. [RFC2460].

3.6.2 Basic COPS events/messages

3.6.2.1 Type of messages

3.6.2.1.1 GGSN

When GGSN receives DEC, it always responds by sending RPT. This was a bitunclear in some 3gpp message diagrams.

GGSN does not implement synchronisation procedure.

3.6.2.1.2 PDF

PDF does not implement the synchronisation procedure, because a possiblerestart or state loss generally affects the whole Call Processing Server, not justthe PDF part, so state synchronization would not provide any benefits.

3.6.2.2 COPS Transact ion State

PDF is not allowed to send concurrent DEC messages with the same clienthandle, before it receives RPT for the first DEC.

The PDF will not process concurrent requests for the same Client Handle. Laterrequests will only be served when the report has been received for the previousdecisions.

The maximum time to wait for RPT message is configured in the PDF (currentdefault is 30 seconds).If PDF does not receive the RPT during that time, it will

just continue. PDF will keep the client handle.

dn0534287Issue 1





3.6.3 Go events/messages

3.6.3.1 Event descriptions

3.6.3.1.1 Common Header, Client Type

3.6.3.1.2 Context Object

3.6.3.1.3 Client Specific Information (ClientSI) for outsourcing Operation

3.6.3.1.4 Conformance Secti on

3.6.3.1.5 Reporting of Device Capabil iti es and Device Limi tations

GGSN

29.207:

“The following GGSN capabilities and limitations may be provided in theconfiguration request message:

• Indication of the maximum number of binding information:

The GGSN may notify the PDF how many binding information the GGSN isable to send with an Authorization_Request.

• Indication of the maximum number of Flow identifiers:

The GGSN may notify the PDF how many Flow identifiers the GGSN is able tosend with an Authorization_Request.

• Indication of the maximum number of ICIDs:

The GGSN may notify the PDF how many ICIDs the GGSN is able to receivewith an Authorization_Decision.”

GGSN will send all these. The maximum values are:Indication of the maximum number of binding information == 1

This is limitation in the logical behaviour inside GGSN, and it is based on thestatement that in according to 3GPP release 5 specifications there is only one

binding information.

Indication of the maximum number of Flow identifiers == 10

Indication of the maximum number of ICIDs == 1.





These values are now only some arbitrary small integers, just to get rid ofinfinite memory requirements.

PDF

PDF will accept any values from GGSN during initial capability negotiation.The received parameters have no effect on PDF behaviour.

PDF is able to support multiple sets of binding information (no practical limit isdefined). To avoid incompatibilities, PDF will announce the support for thesame number of binding information that GGSN has announced during initialcapability negotiation.

3.6.3.1.6 Initi al Go Policy Provis ion ing

3.6.3.2 Message description

“GATE Decision (DEC) (PDF GGSN), contains an INSTALL decision”

“Filter Specification”

This chapter says that the filter specification must be part of the gate decisionmessage. GGSN implementation requires that the filter specification must beidentical to existing filter specification, which has been created earlier withAuthorisation_Decision message. If there is new or modified filter descriptionin a gate, GGSN ignores the open or close operation for that gate silently and

performs the open or close operation for all the valid gates.

“Report of state changes:”

The report type in “report of state changes” this message is “accounting”. The“solicited” flag is not set in the message.

The Accounting timer value is not used in limiting the reporting of statechanges.

“-Delete Request State (DRQ) (GGSN PDF):”

“-Reason code: Tear, Sub-code: deactivation of the PDP context.”

There is a fault in Go specification: The sub code value is not definedanywhere. GGSN initializes the value to 0.

dn0534287Issue 1





3.6.4 Go data

3.6.5 Securi ty Considerations

3.7 Annex A: (Void)

3.8 Annex B (normative): 3GPP Go PIB

go3gppGateFilter

“Wildcarding of the source ports is achieved as follows:

• frwkIpFilterSrcL4PortMin shall be set to 0,

• and frwkIpFilterSrcL4PortMax shall be set to 65535”

Clarification: The wildcard notation in port numbers in filters are interpreted asfollows.

frwkIpFilterSrcL4PortMin = 0, frwkIpFilterSrcL4PortMax = 0 ; No packetmatches this filter. Filter is useless and GGSN writes an error message to log.

frwkIpFilterSrcL4PortMin = 0, frwkIpFilterSrcL4PortMax = 65535 ; Means

the same asfrwkIpFilterSrcL4PortMin = 1, frwkIpFilterSrcL4PortMax = 65535 ; All portnumbers match the filter.

frwkIpFilterSrcL4PortMin 0 frwkIpFilterSrcL4PortMax 2 ; Ports 1 and 2match the filter.

3.9 Annex C (normative): Flow identifiers: Formatdefinition and examples

3.10 Annex D (normative): Go interface related errorcode values for the PDP context handling




Notes about RFC 2748, The COPS (Common Open Policy Service) Protocol

4 Notes about RFC 2748, The COPS(Common Open Policy Service)Protocol

4.1 Introduction

4.1.1 Basic Model

4.2 The Protocol

4.2.1 Common Header

4.2.2 COPS Specific Object Formats

4.2.3 Communication

4.2.4 Client Handle Usage

4.2.5 Synchronization Behavior

4.3 Message Content

dn0534287Issue 1





4.3.1 Request (REQ) PEP -> PDP

4.3.2 Decis ion (DEC) PDP -> PEP

4.3.3 Repor t State (RPT) PEP -> PDP

4.3.4 Delete Request State (DRQ) PEP -> PDP

The RFC says: “Malformed Decision messages MUST trigger a DRQspecifying the appropriate erroneous reason code (Bad Message Format) andany associated state on the PEP SHOULD either be removed or re-requested.”

GGSN violates this statement. There are many errors, which do not cause DRQor which do not cause deletion of the associated state.




Notes about RFC 2748, The COPS (Common Open Policy Service) Protocol

4.3.5 Synchronize State Request (SSQ) PDP -> PEP

4.3.6 Client-Open (OPN) PEP -> PDP

4.3.7 Client-Accept (CAT) PDP -> PEP

4.3.8 Client-Close (CC) PEP -> PDP, PDP -> PEP

4.3.9 Keep-Alive (KA) PEP -> PDP, PDP -> PEP

4.3.10 Synchronize State Complete (SSC) PEP -> PDP

4.4 Common Operation

4.4.1 Securi ty and Sequence Number Negoti ation

4.4.2 Key Maintenance

4.4.3 PEP Init iali zation

4.4.4 Outsour cing Operations

4.4.5 Configuration Operations

4.4.6 Keep-Alive Operations

4.4.7 PEP/PDP Close

4.5 Security Considerations

dn0534287Issue 1




References

References

1. 3GPP TS 29.207 Policy Control over Go Interface.ftp://ftp.3gpp.org/Specs/2003-09/Rel-5/29_series/29207-551.zip

2. 3GPP TS 29.208 End-to-end QoS Signaling Flows.ftp://ftp.3gpp.org/Specs/2003-09/Rel-5/29_series/29208-551.zip

3. 3GPP TS 24.229, IP Multimedia Call Control Protocol based on SessionInitiation Protocol (SIP) and Session Description Protocol (SDP)ftp://ftp.3gpp.org/Specs/latest/Rel-5/24_series/24229-580.zip

4. IETF RFC 2578 Structure of Management Information Version 2 (SMIv2).http://www.ietf.org/rfc/rfc2578.txt

5. IETF RFC 2748 The COPS Protocol http://www.ietf.org/rfc/rfc2748.txt

6. IETF RFC 3048 COPS Usage for Policy Provisioninghttp://www.ietf.org/rfc/rfc3084.txt

7. IETF RFC 3159 Structure of Policy Provisioning Information (SPPI).http://www.ietf.org/rfc/rfc3159.txt

8. IETF RFC 3291 Textual Conventions for Internet Network Addresses.http://www.ietf.org/rfc/rfc3291.txt

9. IETF RFC 3318 Framework Policy Information Base,http://www.ietf.org/rfc/rfc3318.txt

10. draft-ietf-rap-frameworkpib-07.txt IETF draft: Framework PolicyInformation Base. Does not exist any more in IETF web pages.

11. Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6)Specification”, RFC 2460, December 1998,http://www.ietf.org/rfc/rfc2460.txt

12. M. Handley , V. Jacobson , “SDP: Session Description Protocol”, RFC2327,April 1998, http://www.ietf.org/rfc/rfc2327.txt

13. J. Rosenberg , H. Schulzrinne, “An Offer/Answer Model with the SessionDescription Protocol (SDP)”, RFC3264, June 2002,http://www.ietf.org/rfc/rfc3264.txt

dn0534287Issue 1


ftp://ftp.3gpp.org/Specs/2003-09/Rel-5/29_series/29207-551.zip


ftp://ftp.3gpp.org/Specs/latest/Rel-5/24_series/24229-580.zip

http://www.ietf.org/rfc/rfc2578.txt


















ftp://ftp.3gpp.org/Specs/latest/Rel-5/24_series/24229-580.zip



nokia sgsn intergace

Documents