RFC 5866
Diameter Quality-of-Service Application
Pages: 51
Proposed Standard
Proposed Standard
Part 2 of 3 – Pages 17 to 34
4. QoS Application Session Establishment and Management
4.1. Parties Involved
Authorization models supported by this application include three parties: o Resource Requesting Entity o Network Elements (Diameter QoS application (DQA) client) o Authorizing Entity (Diameter QoS application (DQA) server) Note that the QoS RRE is only indirectly involved in the message exchange. This entity provides the trigger to initiate the Diameter QoS protocol interaction by transmitting QoS signaling messages. The Diameter QoS application is only executed between the Network Element (i.e., DQA client) and the Authorizing Entity (i.e., DQA server).
The QoS RRE may communicate with the AE using application-layer signaling for the negotiation of service parameters. As part of this application-layer protocol interaction, for example using SIP, authentication and authorization might take place. This message exchange is, however, outside the scope of this document. The protocol communication between the QoS resource requesting entity and the QoS NE might be accomplished using the NSIS protocol suite, RSVP, or a link-layer signaling protocol. A description of these protocols is also outside the scope of this document.4.2. Session Establishment
Pull and Push modes use a different set of command codes for session establishment. For other operations, such as session modification and termination, they use the same set of command codes. The selection of Pull mode or Push mode operation is based on the trigger of the QoS authorization session. When a QoS-Authorization- Request (QAR, see Section 5.1) message with a new Session-Id is received, the AE operates in Pull mode; when other triggers are received, the AE operates in Push mode. Similarly, when a QoS- Install-Request (QIR, see Section 5.3} with a new Session-Id is received, the NE operates in Push mode; when other triggers are received, the NE operates in Pull mode. The QoS authorization session is typically established per subscriber base (i.e., all requests with the same User-ID), but it is also possible to be established on a per node or per request base. The concurrent sessions between an NE and an AE are identified by different Session-Ids.4.2.1. Session Establishment for Pull Mode
A request for a QoS reservation or local events received by an NE can trigger the initiation of a Diameter QoS authorization session. The NE converts the required objects from the QoS signaling message to Diameter AVPs and generates a QAR message. Figure 6 shows the protocol interaction between a Resource Requesting Entity, a Network Element, and the Authorizing Entity. The AE's identity, information about the application session and/or identity and credentials of the QoS RRE, requested QoS parameters, and the signaling session identifier and/or QoS-enabled data flows identifiers MAY be encapsulated into respective Diameter AVPs and included in the Diameter message sent to the AE. The QAR is sent to a Diameter server that can be either the home server of the QoS requesting entity or an AppS.
+------------------------------------------+------------------------+ | QoS-Specific Input Data | Diameter AVPs | +------------------------------------------+------------------------+ | Authorizing Entity ID (e.g., | Destination-Host | | Destination-Host taken from | Destination-Realm | | authorization token, Destination-Realm, | | | or derived from the Network Access | | | Identifier (NAI) of the QoS requesting | | | entity) | | | Authorization Token Credentials of the | QoS-Authorization-Data | | QoS requesting entity | User-Name | | QoS-Resources (including QoS parameters) | | +------------------------------------------+------------------------+ Table 1: Mapping Input Data to QoS AVPs -- Pull Mode Authorization processing starts at the Diameter QoS server when it receives the QAR. Based on the information in the QoS- Authentication-Data, User-Name, and QoS-Resources AVPs, the server determines the authorized QoS resources and flow state (enabled/ disabled) from locally available information (e.g., policy information that may be previously established as part of an application-layer signaling exchange or the user's subscription profile). The QoS-Resources AVP is defined in [RFC5777]. The authorization decision is then reflected in the response returned to the Diameter client with the QoS-Authorization-Answer (QAA) message.
Authorizing End-Host Network Element Entity requesting QoS (Diameter (Diameter QoS Client) QoS Server) | | | +---QoS-Reserve---->| | | +- - - - - QAR - - - - - >| | |(QoS-Resources, | | | QoS-Auth-Data,User-ID)| | | +--------+--------------+ | | | Authorize request | | | | Keep session data | | | |/Authz-time,Session-Id/| | | +--------+--------------+ | |< - - - - QAA - - - - - -+ | |(Result-Code, | | |QoS-Resources,Authz-time)| | +-------+---------+ | |Install QoS state| | | + | | | Authz session | | | /Authz-time/ | QoS Responder | | | Node | +-------+---------+ | | +----------QoS-Reserve---....--->| | | | | |<---------QoS-Response--....----| |<--QoS-Response----+ | | | | |=====================Data Flow==============....===>| Figure 6: Initial QoS Request Authorization for Pull Mode The Authorizing Entity keeps authorization session state and SHOULD save additional information for management of the session (e.g., Signaling-Session-Id, authentication data) as part of the session state information. The final result of the authorization request is provided in the Result-Code AVP of the QAA message sent by the Authorizing Entity. In the case of successful authorization (i.e., Result-Code = DIAMETER_LIMITED_SUCCESS (see Section 7.1)), information about the authorized QoS resources and the status of the authorized flow (enabled/disabled) is provided in the QoS-Resources AVP of the QAA message. The QoS information provided via the QAA is installed by the QoS Traffic Control function of the NE. The value
DIAMETER_LIMITED_SUCCESS indicates that the AE expects confirmation via another QAR message for successful QoS resource reservation and for final reserved QoS resources (see below). One important piece of information returned from the Authorizing Entity is the authorization lifetime (carried inside the QAA). The authorization lifetime allows the NE to determine how long the authorization decision is valid for this particular QoS reservation. A number of factors may influence the authorized session duration, such as the user's subscription plan or the currently available credits at the user's account (see Section 8). The authorization duration is time-based, as specified in [RFC3588]. For an extension of the authorization period, a new QoS-Authorization-Request/Answer message exchange SHOULD be initiated. Further aspects of QoS authorization session maintenance are discussed in Sections 4.3, 4.4, and 8. The indication of a successful QoS reservation and activation of the data flow is provided by the transmission of a QAR message, which reports the parameters of the established QoS state: reserved resources, duration of the reservation, and identification of the QoS enabled flow/QoS signaling session. The Diameter QoS server acknowledges the reserved QoS resources with the QA Answer (QAA) message where the Result-Code is set to 'DIAMETER_SUCCESS'. Note that the reserved QoS resources reported in this QAR message MAY be different than those authorized with the initial QAA message, due to the QoS-signaling-specific behavior (e.g., receiver-initiated reservations with One-Path-With-Advertisements) or specific process of QoS negotiation along the data path.4.2.2. Session Establishment for Push Mode
The Diameter QoS server in the AE initiates a Diameter QoS authorization session upon the request for a QoS reservation triggered by application-layer signaling or by local events, and generates a QoS-Install-Request (QIR) message to the Diameter QoS client in the NE in which it maps required objects to Diameter payload objects. Figure 7 shows the protocol interaction between the AE, a Network Element, and an RRE. The NE's identity, information about the application session and/or identity and credentials of the QoS resource requesting entity, requested QoS parameters, and signaling session identifier and/or QoS enabled data flows identifiers MAY be encapsulated into respective Diameter AVPs and included in the Diameter message sent from a Diameter QoS server in the Authorizing Entity to a Diameter QoS
client in the NE. This requires that the AE has knowledge of specific information for allocating and identifying the NE that should be contacted and the data flow for which the QoS reservation should be established. This information can be statically configured or dynamically discovered, see Section 4.2.3 for details. +-----------------------------------------+-------------------------+ | QoS-Specific Input Data | Diameter AVPs | +-----------------------------------------+-------------------------+ | Network Element ID | Destination-Host | | | Destination-Realm | | Authorization Token Credentials of the | QoS-Authorization-Data | | QoS requesting entity | User-Name | | QoS-Resources (including QoS | | | parameters) | | +-----------------------------------------+-------------------------+ Table 2: Mapping Input Data to QoS AVPs -- Push Mode Authorization processing starts at the Diameter QoS server when it receives a request from an RRE through an AppS (e.g., SIP Invite) or is triggered by a local event (e.g., a pre-configured timer). Based on the received information, the server determines the authorized QoS resources and flow state (enabled/disabled) from locally available information (e.g., policy information that may be previously established as part of an application-layer signaling exchange, or the user's subscription profile). The authorization decision is then reflected in the QoS-Install-Request (QIR) message to the Diameter QoS client.
Authorizing End-Host Network Element Entity requesting QoS (Diameter (Diameter QoS Client) QoS Server) | | | | | |<-- Trigger -- | | +--------+--------------+ | | | Authorize request | | | | Keep session data | | | |/Authz-time,Session-Id/| | | +--------+--------------+ | | | | |<-- - -- - QIR - - - - - -+ | |(Initial Request,Decision | | |(QoS-Resources,Authz-time)| | +-------+---------+ | |Install QoS state| | | + | | | Authz session | | | /Authz-time/ | | | | | +-------+---------+ | + - - - - QIA - - - - - ->| | | (Result-Code, | | | QoS-Resources) | | | +--------+--------------+ | | | Report for successful | | | | QoS reservation | | | |Update of reserved QoS | | | | resources | | | +--------+--------------+ | | QoS Responder | | Node | | | |=====================Data Flow==============....===>| Figure 7: Initial QoS Request Authorization for Push Mode The AE keeps authorization session state and SHOULD save additional information for management of the session (e.g., Signaling-Session-Id, authentication data) as part of the session state information. The final result of the authorization decision is provided in the QoS-Resources AVP of the QIR message sent by the AE. The QoS information provided via the QIR is installed by the QoS Traffic Control function of the NE.
One important piece of information from the AE is the authorization lifetime (carried inside the QIR). The authorization lifetime allows the NE to determine how long the authorization decision is valid for this particular QoS reservation. A number of factors may influence the authorized session duration, such as the user's subscription plan or the currently available credits at the user's account (see Section 8). The authorization duration is time-based as specified in [RFC3588]. For an extension of the authorization period, a new QoS- Install-Request/Answer message or QoS-Authorization-Request/Answer message exchange SHOULD be initiated. Further aspects of QoS authorization session maintenance are discussed in Sections 4.3, 4.4, and 8. The indication of QoS reservation and activation of the data flow can be provided by the QoS-Install-Answer message immediately. In the case of successful enforcement, the Result-Code (= DIAMETER_SUCCESS, (see Section 7.1)) information is provided in the QIA message. Note that the reserved QoS resources reported in the QIA message may be different than those initially authorized with the QIR message, due to the QoS signaling-specific behavior (e.g., receiver-initiated reservations with One-Path-With-Advertisements) or specific process of QoS negotiation along the data path. In the case that Multiple AEs control the same NE, the NE should make the selection on the authorization decision to be enforced based on the priority of the request.4.2.3. Discovery and Selection of Peer Diameter QoS Application Node
The Diameter QoS application node may obtain information of its peer nodes (e.g., Fully-Qualified Domain Name (FQDN), IP address) through static configuration or dynamic discovery as described in Section 5.2 of [RFC3588]. In particular, the NE shall perform the relevant operation for Pull mode; the AE shall perform the relevant operations for Push mode. Upon receipt of a trigger to initiate a new Diameter QoS authorization session, the Diameter QoS application node selects and retrieves the location information of the peer node that is associated with the affected user based on some index information provided by the RRE. For instance, it can be the Authorization Entity's ID stored in the authorization token, the end-user identity (e.g., NAI [RFC4282]), or a globally routable IP address.4.3. Session Re-Authorization
Client- and server-side initiated re-authorizations are considered in the design of the Diameter QoS application. Whether the re-authorization events are transparent for the resource requesting
entity or result in specific actions in the QoS signaling protocol is
outside the scope of the Diameter QoS application. It is directly
dependent on the capabilities of the QoS signaling protocol.
There are a number of options for policy rules according to which the
NE (AAA client) contacts the AE for re-authorization. These rules
depend on the semantics and contents of the QAA message sent by the
AE:
a. The QAA message contains the authorized parameters of the flow
and its QoS and sets their limits (presumably upper). With these
parameters, the AE specifies the services that the NE can provide
and for which it will be financially compensated. Therefore, any
change or request for change of the parameters of the flow and
its QoS that do not conform to the authorized limits requires
contacting the AE for authorization.
b. The QAA message contains authorized parameters of the flow and
its QoS. The rules that determine whether parameters' changes
require re-authorization are agreed out of band, based on a
Service Level Agreement (SLA) between the domains of the NE and
the AE.
c. The QAA message contains the authorized parameters of the flow
and its QoS. Any change or request for change of these
parameters requires contacting the AE for re-authorization.
d. In addition to the authorized parameters of the flow and its QoS,
the QAA message contains policy rules that determine the NEs
actions in case of a change or a request for change in authorized
parameters.
Provided options are not exhaustive. Elaborating on any of the
listed approaches is deployment/solution specific and is not
considered in the current document.
In addition, the AE may use an RAR (Re-Authorization-Request) to
perform re-authorization with the authorized parameters directly when
the re-authorization is triggered by service request or local events/
policy rules.
4.3.1. Client-Side Initiated Re-Authorization
The AE provides the duration of the authorization session as part of
the QoS-Authorization-Answer (QAA) message. At any time before the
expiration of this period, a new QoS-Authorization-Request (QAR)
message MAY be sent to the AE. The transmission of the QAR MAY be
triggered when the NE receives a QoS signaling message that requires
modification of the authorized parameters of an ongoing QoS session, or authorization lifetime expires. Authorizing End-Host Network Element Entity requesting QoS (Diameter (Diameter QoS Client) QoS Server) | | | |=====================Data Flow==========================> | | | | +-------+----------+ | | |Authz-time/CC-Time| | | | expires | | | +-------+----------+ | | +- - - - - QAR - - - - - >| | |(QoS-Resources, | | | QoS-Authorization-Data,User-ID) | | +--------+--------------+ NOTE: | | Authorize request | Re-authorization | | Update session data | is transparent to | |/Authz-time,Session-Id/| the End-Host | +--------+--------------+ |< - - - - QAA - - - - - -+ | |(Result-Code, | | |QoS-Resources,Authz-time)| | +-------+---------+ | | |Update QoS state | | | | + | | | | Authz session | | | | /Authz-time/ | | | | | | | +-------+---------+ | | | | |=====================Data Flow==========================> | | Figure 8: Client-side Initiated QoS Re-Authorization4.3.2. Server-Side Initiated Re-Authorization
The AE MAY initiate a QoS re-authorization by issuing a Re-Authorization-Request (RAR) message as defined in the Diameter base protocol [RFC3588], which may include the parameters of the re-authorized QoS state: reserved resources, duration of the reservation, identification of the QoS-enabled flow/QoS signaling session for re-installation of the resource state by the QoS Traffic Control function of the NE.
An NE that receives such an RAR message with Session-Id matching a currently active QoS session acknowledges the request by sending the Re-Auth-Answer (RAA) message towards the AE. If the RAR does not include any parameters of the re-authorized QoS state, the NE MUST initiate a QoS re-authorization by sending a QoS-Authorization-Request (QAR) message towards the AE. Authorizing End-Host Network Element Entity requesting QoS (Diameter (Diameter QoS Client) QoS Server) | | | | | |<-- Trigger -- | | +--------+--------------+ | | | Authorize request | | | | Keep session data | | | |/Authz-time,Session-Id/| | | +--------+--------------+ | | | | |<-- - -- - RAR - - - - - -+ | |(Request,Decision | | |(QoS-Resources,Authz-time)| | +-------+---------+ | |Install QoS state| | | + | | | Authz session | | | /Authz-time/ | | | | | +-------+---------+ | + - - - - RAA - - - - - ->| | | (Result-Code, | | | QoS-Resources) | | | +--------+--------------+ | | | Report for successful | | | | QoS reservation | | | |Update of reserved QoS | | | | resources | | | +--------+--------------+ | | | Figure 9: Server-Side Initiated QoS Re-Authorization
4.4. Session Termination
4.4.1. Client-Side Initiated Session Termination
The authorization session for an installed QoS reservation state MAY be terminated by the Diameter client by sending a Session- Termination-Request (STR) message to the Diameter server with a response Session-Termination-Acknowledgement (STA) message. This is a Diameter base protocol function and it is defined in [RFC3588]. Session termination can be caused by a QoS signaling message requesting deletion of the existing QoS reservation state, or it can be caused as a result of a soft-state expiration of the QoS reservation state. Authorizing End-Host Network Element Entity requesting QoS (Diameter (Diameter QoS Client) QoS Server) | | | |==Data Flow==>X /Stop of the data flow/ | | | | +---QoS-Reserve---->| | | (Delete QoS +- - - - - STR - - - - - >| | reservation) | +--------+--------------+ | | | Remove authorization | | | | session state | | | +--------+--------------+ | |< - - - - STA - - - - - -+ | +-------+--------+ | | |Delete QoS state| | +-------+--------+ QoS Responder | | Node | +----------QoS-Reserve-----....--->| | | (Delete QoS | | | reservation) | | |<---------QoS-Response----....----+ |<--QoS-Response----+ | Figure 10: Client-Side Initiated Session Termination4.4.2. Server-Side Initiated Session Termination
At any time during a session, the AE MAY send an Abort-Session- Request (ASR) message to the NE. This is a Diameter base protocol function and it is defined in [RFC3588]. Possible reasons for initiating the ASR message to the NE are insufficient credits or session termination at the application layer. The ASR message results in termination of the authorized session, release of the
reserved resources at the NE, and transmission of an appropriate QoS signaling message indicating a notification to other Network Elements aware of the signaling session. Authorizing End-Host Network Element Entity requesting QoS (Diameter (Diameter QoS Client) QoS Server) | | | |=====================Data Flow==========================> | | | |< - - - - ASR - - - - - -+ | | | |====Data Flow=====>X | QoS Responder | | | Node |<--QoS-Notify------+----------QoS-Reserve-----....--->| | | (Delete QoS | | | reservation) | +-------+--------+ | |Delete QoS state| | +-------+--------+ | +- - - - - ASA - - - - - >| | +--------+--------------+ | | Remove authorization | | | session state | | +--------+--------------+ | QoS Responder | Node |<---------QoS-Response----....----+ | | Figure 11: Server-Side Initiated Session Termination5. QoS Application Messages
The Diameter QoS application requires the definition of new mandatory AVPs and Command-Codes (see Section 3 of [RFC3588]). Four new Diameter messages are defined along with Command-Codes whose values MUST be supported by all Diameter implementations that conform to this specification.
+---------------------------+---------+------+-------------+ | Command Name | Abbrev. | Code | Reference | +---------------------------+---------+------+-------------+ | QoS-Authorization-Request | QAR | 326 | Section 5.1 | | QoS-Authorization-Answer | QAA | 326 | Section 5.2 | | QoS-Install-Request | QIR | 327 | Section 5.3 | | QoS-Install-Answer | QIA | 327 | Section 5.4 | +---------------------------+---------+------+-------------+ Table 3: Diameter QoS Commands In addition, the following Diameter base protocol messages are used in the Diameter QoS application: +-----------------------+---------+------+-----------+ | Command-Name | Abbrev. | Code | Reference | +-----------------------+---------+------+-----------+ | Re-Auth-Request | RAR | 258 | [RFC3588] | | Re-Auth-Answer | RAA | 258 | [RFC3588] | | Abort-Session-Request | ASR | 274 | [RFC3588] | | Abort-Session-Answer | ASA | 274 | [RFC3588] | | Session-Term-Request | STR | 275 | [RFC3588] | | Session-Term-Answer | STA | 275 | [RFC3588] | +-----------------------+---------+------+-----------+ Table 4: Diameter Base Commands Diameter nodes conforming to this specification MAY advertise support for the Diameter QoS application by including the value of 9 in the Auth-Application-Id or the Acct-Application-Id AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands, see [RFC3588]. The value of 9 MUST be used as the Application-Id in all QAR/QAA and QIR/QIA commands. The value of zero (0) SHOULD be used as the Application-Id in all STR/STA, ASR/ASA, and RAR/RAA commands.5.1. QoS-Authorization Request (QAR)
The QoS-Authorization-Request (QAR) message, indicated by the Command-Code field (see Section 3 of [RFC3588]) being set to 326 and the 'R' bit being set in the Command Flags field, is used by NEs to request quality of service related resource authorization for a given flow.
The QAR message MUST carry information for signaling session
identification, AE identification, information about the requested
QoS, and the identity of the QoS requesting entity. In addition,
depending on the deployment scenario, an authorization token and
credentials of the QoS requesting entity SHOULD be included.
The message format is defined as follows:
<QoS-Authorization-Request> ::= < Diameter Header: 326, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Auth-Request-Type }
[ Destination-Host ]
[ User-Name ]
* [ QoS-Resources ]
[ QoS-Authorization-Data ]
[ Bound-Auth-Session-Id ]
* [ AVP ]
5.2. QoS-Authorization-Answer (QAA)
The QoS-Authorization-Answer (QAA) message, indicated by the Command-
Code field being set to 326 and the 'R' bit being cleared in the
Command Flags field, is sent in response to the QoS-Authorization-
Request (QAR) message. If the QoS authorization request is
successfully authorized, the response will include the AVPs to allow
authorization of the QoS resources and transport plane gating
information.
The message format is defined as follows:
<QoS-Authorization-Answer> ::= < Diameter Header: 326, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Request-Type }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
* [ QoS-Resources ]
[ Acct-Multisession-Id ]
[ Session-Timeout ]
[ Authorization-Session-Lifetime ]
[ Authorization-Grace-Period ]
* [ AVP ]
5.3. QoS-Install Request (QIR)
The QoS-Install Request (QIR) message, indicated by the Command-Code field being set to 327 and the 'R' bit being set in the Command Flags field, is used by the AE to install or update the QoS parameters and the flow state of an authorized flow at the transport plane element. The message MUST carry information for signaling-session identification or identification of the flow to which the provided QoS rules apply, identity of the transport plane element, description of provided QoS parameters, flow state, and duration of the provided authorization. The message format is defined as follows: <QoS-Install-Request> ::= < Diameter Header: 327, REQ, PXY > < Session-Id > { Auth-Application-Id } { Origin-Host } { Origin-Realm } { Destination-Realm } { Auth-Request-Type } [ Destination-Host ] * [ QoS-Resources ] [ Session-Timeout ] [ Authorization-Session-Lifetime ] [ Authorization-Grace-Period ] [ Authorization-Session-Volume ] * [ AVP ]5.4. QoS-Install Answer (QIA)
The QoS-Install Answer (QIA) message, indicated by the Command-Code field being set to 327 and the 'R' bit being cleared in the Command Flags, field is sent in response to the QoS-Install Request (QIR) message for confirmation of the result of the installation of the provided QoS reservation instructions. The message format is defined as follows: <QoS-Install-Answer> ::= < Diameter Header: 327, PXY > < Session-Id > { Auth-Application-Id } { Origin-Host } { Origin-Realm } { Result-Code } * [ QoS-Resources ] * [ AVP ]
5.5. Re-Auth-Request (RAR)
The Re-Auth-Request (RAR) message, indicated by the Command-Code field being set to 258 and the 'R' bit being set in the Command Flags field, is sent by the AE to the NE in order to initiate the QoS re-authorization from the DQA server side. If the RAR command is received by the NE without any parameters of the re-authorized QoS state, the NE MUST initiate a QoS re-authorization by sending a QoS-Authorization-Request (QAR) message towards the AE. The message format is defined as follows: <RAR> ::= < Diameter Header: 258, REQ, PXY > < Session-Id > { Origin-Host } { Origin-Realm } { Destination-Realm } { Destination-Host } { Auth-Application-Id } { Re-Auth-Request-Type } [ User-Name ] [ Origin-State-Id ] * [ Proxy-Info ] * [ Route-Record ] * [ QoS-Resources ] [ Session-Timeout ] [ Authorization-Session-Lifetime ] [ Authorization-Grace-Period ] [ Authorization-Session-Volume ] * [ AVP ]
5.6. Re-Auth-Answer (RAA)
The Re-Auth-Answer (RAA) message, indicated by the Command-Code field being set to 258 and the 'R' bit being cleared in the Command Flags field, is sent by the NE to the AE in response to the RAR command. The message format is defined as follows: <RAA> ::= < Diameter Header: 258, PXY > < Session-Id > { Result-Code } { Origin-Host } { Origin-Realm } [ User-Name ] [ Origin-State-Id ] [ Error-Message ] [ Error-Reporting-Host ] * [ Failed-AVP ] * [ Redirect-Host ] [ Redirect-Host-Usage ] [ Redirect-Host-Max-Cache-Time ] * [ Proxy-Info ] * [ QoS-Resources ] * [ AVP ]
(page 34 continued on part 3)