RACF living list - Kobe, Japan, 22-27 April 2006.doc

INTERNATIONAL TELECOMMUNICATION UNION STUDY GROUP 13TELECOMMUNICATIONSTANDARDIZATION SECTOR

STUDY PERIOD 2005-2008

TD 87 Rev.1 (WP 4/13)English only

Original: English

Question(s): 4/13 Geneva, 17-28 July 2006

TEMPORARY DOCUMENT

Source: Editor

Title: RACF living list - Kobe, Japan, 22-27 April 2006

This document contains open issues concerning the Resource and Admission Control Functions.

Contact: Takashi HaradaOki Electric Industry Co., Ltd.Japan

Tel: +81-3-5445-6294Fax: +81-3-3798-7620Email: [email protected]

Attention: This is not a publication made available to the public, but an internal ITU-T Document intended only for use by the Member States of ITU, by ITU-T Sector Members and Associates, and their respective staff and collaborators in their ITU related work. It shall not be made available to, and used by, any other persons or entities without the prior written consent of ITU-T.

- 2 -TD 87 Rev.1 (WP 4/13)

Table 1: Open issues concerning RACF

No. Issue R1 Post R1

1The draft needs to be clear on what are optional or mandatory in terms of functional requirements and information elements?

Done

2Review if each of the high-level requirements is indeed met.

Done

3

Should there be a distinction between the access PDF and core PDF? (Related to access and core network definitions)? Rt->intra-domain

*Now, one PDF is defined and where Rt is intra-domain or inter-domain needs further study (same as No.13)

Done

4 Need requirements for Rd and RiDone

(partially)

5

Need clarity on the distinction between Gq and Rs; Go and Ro

*same as No.17, 18 (can be deleted)

Done --

6Allocation of the current material in Annexes to R1 and post R1

Done

7

Clarify packet filtering and the different variants; where the policy rules are from; what is the role of the PDF in pushing the rules; if activation of policy rules provisioned via the management plane is another option; and whether gating is a distinct function

X

8Need an Re-like reference point in the core?

RACF architecture is not truly functional?Done

9 Add an FE for non-session based service control resolved Done

10Add technology-dependent control for shaping, policing etc. to A-TRCF?

Done

11Network selection beyond core networks needs further study

X

- 3 -TD 87 Rev.1 (WP 4/13)

12

Alignment with TISPAN RACS, no one-to-one mapping between functional entities (or reference points). Even when references have the same name, there may be slight mis-matches between them.

Done

(Partial alignment

archieved – no further alignment envisaged

for R1)

X

13Where Rt is inter-provider or intra-provider needs further study.

Done

(Intra-Domain

only for R1)

X?

14 Resource mediation as defined below needs further study X

15 Distinction between ENF and ANF needs further study. Done

16

The RACF architecture supports end-to-end quality of service based on inter-RACF communication across provider domains through inter-PDF communication. Additional examples for instantiations (such as Appendix 1 and 2 in TR-RACF) to show end-to-end QoS and scenarios where the access/aggregation network is split in different domains (e.g., local loop unbundling), and verify that inter-PDF communication can be used to provide an end-to-end solution.

Done

(Incomplete Support in

R1)

X

17Appendix 1 in this document captures an initial comparison between Gq and Rs, which will be further studied.

For Information

18Appendix 2 in this document captures an initial comparison between Go and R w , which will be further studied.

For Information

19Appendix 3 in this document captures configuration examples for further study.

Done X

20 IPv4-IPv6 translation X

21

Add a new section in the end of the document on “R1 scope and future work” based on the agreements herein, including

Reference points considerations

TEF

Reference point between CPE and RACF

Relationship between management functions and RACF (e.g., pre-provisioned resources)

Overload control of RACF entities

Deleted

- 4 -TD 87 Rev.1 (WP 4/13)

22Appendix 4 and 5 in this document captures Intra /Inter - network RACF interaction approaches , which will be further studied.

X

23Appendix 6 in this document captures Static RACF approach and interworking with legacy network environment, which will be further studied.

X

24Need further study for application specifications and requirements, which are captured on Appendix 7 in this document.

X

25Need further study for end-to-end information flow, which is captured on Appendix 7 in this document.

X

26Appendix 8 in this document captures an initial comparison between TISPAN RACS and ITU-T RACF, which will be further studied.

X

- 5 -TD 87 Rev.1 (WP 4/13)

Table 2: Editor’s Notes in Y.RACF

No. Section Issue R1 Post R1

1 2The final version of references must be released documents.

Deleted

1.1 2The reference [5][6] should quote equivalent ETSI recommendations.

Done

1.2 2Separate normative and informative references. All non-ITU normative references require A5 justifications.

X

1.3 2Need to add RFC 3520 on authorization tokens.

Done

2 3The definition of NAPT control and NAT traversal is required (done)

Done

3 4

The SCF used in the context represents the abstract view of service control stratum. Further alignment is needed with WG2.

*already covered

Done

6 7

How the functional entities are called should be aligned with WG2. The term “subsystem” in the draft needs to be replaced with the one agreed by WG 2. (done)

Done

6.1 7.1contributions are invited to improve the PD-FE and TRC-FE descriptions in section 7.1 to reflect the new architecture.

Done

7 7.2.3.1

Further contributions are invited to clarify the following items:

1. IPGC, TDGC

2. IPMC

3. ERC

In addition, contributions are invited to define the terms “technology dependent” and “technology independent.”

Done

8 7.2.3.3.2

Further study is needed if Re should be added to C-TRCF

*same as open issue No.8

Done

- 6 -TD 87 Rev.1 (WP 4/13)

9 7.2.3.3.2

The following paragraphs are about the internal implementation of TRCF entities. It’s proposed to remove them into an Appendix. (addressed)

Done

10 7.2.4.2

The further study is needed for the descriptions and functionality of ANF and ENF.


Done

11 7.2.4.3

contributions are invited to further clarify packet filtering and the different variants; where the policy rules are from; what is the role of the PDF in pushing the rules; if activation of policy rules provisioned via the management plane is another option; and whether gating is a distinct function.


Deleted

12 8

In order to avoid the iteration on the description of reference points, suggest consolidating the common part of reference points. The edited Rs and Ro can be used as the baseline for the consolidation. (addressed)

Done

14.1

8.2.4.1

Justification for the information elements: Application ID, Global IP Address Information, Transport Subscriber Identifier, Resource Request Client Information

Done

15 8.3.1This section needs much further work. The current description is largely Layer 3.

Done

16 8.10

The text still needs to be checked to make sure that the description of Rt is consistently intra-provider.


Done

16.1

9The procedures need to be aligned with information messages and information elements defined by Clause 8.

Done

17 9.1.1.1Whether installation and allocation have the same meaning and can be replaced with commitment needs further checking.

Done

19.1

10The section 10 can be moved to section 7 as 7.3.

Done

- 7 -TD 87 Rev.1 (WP 4/13)

19.2

13

The text will be drafted based on the agreed scope and future work as indicated in the meeting report and living list.


Deleted

20Appendix

2further alignment is needed. X

21 A.1At the previous SG13 and JRG-NGN meetings, some contributions and comments aim at this case.

Deleted

22 A.2Section10 of the previous Y.e2eqos.2 version mainly aim at this case.

Deleted

23 A.3The ARCF in TR-123.qos aims at the Ethernet aggregation network.

Deleted

24 A.4 For further study. Deleted

25 A.5

In this description, The QoS classes in broadband wireless network are defined in IEEE 802.16. It needs to align with ITU-T recommendation Y.1541.

Deleted

26Appendix

2 and 3

The appendix II and III are obsolete. Further action is needed.

Done

- 8 -TD 87 Rev.1 (WP 4/13)

Resource Mediation

The Resource Mediation (RM) provides mediation between one or many Service Providers and one or many Network Resource Providers. The RM provides an abstract view of the transport functions to the content or application services.

The RM makes the Resource Processing independent from the Service Processing and therefore is particularly relevant in NGN architectures. Its main advantage is to simplify and fasten the development of services by Service Providers.

The RM acts as intermediary between service execution and resource processing. It first ensures the adaptation between service instance and resources by translating service parameters into resource parameters. This mediation is then in charge of resource positioning in order to support the customer's service.

The RM is in charge of determining which Network Resource Providers should be involved in the support of a given service. It will then interact with each of them to obtain the necessary resources for the service.

In the NGN architecture, multiple instances of RACFs exist. As the core network could involve different domains and different core network providers, each core network should have its own RACF called "Core RACF". The NGN takes into account different types of access networks (Mobile network, DSL network …). Each of these networks has it own characteristics and could also be managed by a specific provider. So, each of these providers should have his own RACF called "Access RACF".

The Service Control Functions in the Service stratum should access the transport through a unique reference point. So, if different networks should be taken into account, a Resource Mediation (RM) is needed to choose the Access and Core RACF able to offer the required QoS.

- 9 -TD 87 Rev.1 (WP 4/13)

Appendix 1: Comparison between Gq’ and 3GPP Gq

The Gq’ reference point allows QoS resource request information needed for QoS authorization to be exchanged between PDF and Service Control Functions. The Gq’ reference point should be compatible with the Gq interface as defined by 3GPP Release 6 in [3GPP TS 29.209], and should support the NAPT/firewall control and NAT traversal at A-BGF/I-BGF as needed. The Gq’ supports the resource control push or pull mode defined in TR-RACF.

The Gq interface is used for the service-based policy set-up information exchange between the PDF and the AF, e.g. the P-CSCF. This information is used by the PDF for the Service Based Local Policy (SBLP) decisions. The Gq only supports the resource control pull mode defined in TR-RACF.

1. Detailed Comparison and Analysis

1.1. Functional requirements aspect

Functional requirements of Gq’

The Gq’ reference point provides the ability for the SCF to make requests:

For resource allocation and authorization for a media flow,

For QoS handling,

For priority handling,

For gating (enable/disable) control of a media flow,

To insert a NAPT function and request address mapping information.

For dynamic firewall working mode selection

For resource usage information

In addition, the SCF can request notification of events.

Functional requirements of 3GPP Gq

Initial authorization of QoS resources

When receiving an AF session signalling message initiating a new AF session, the AF shall request an authorization for the session from the PDF. When receiving an initial authorization request from the AF, the PDF allocates Authorization-Token. The PDF shall store the Diameter base protocol Session-Id received in the authorization request message for the Authorization-Token.

Resource reservation

The PDF may contact the AF at the UE resource reservation by sending the Re-Auth-Request message with a request for the service information. The AF shall respond with the Re-Auth-Answer message containing the Media-Component-Description AVP(s).

Gate function

- 10 -TD 87 Rev.1 (WP 4/13)

The AF shall indicate to the PDF as part of the Media-Component-Description whether the media IP flow(s) should be enabled or disabled at the bearer authorization.

Session modification

During the AF session modification, the AF shall send an update for the session description information to the PDF based on the new SDI exchanged within the AF session signalling. The PDF shall store the SBLP for the session based on the new service information. The PDF shall acknowledge the session modification by issuing an AA-Answer back to the AF.

Revoke authorization

When AF session is terminated the AF shall revoke the corresponding bearer authorization by the sending Session-Termination-Request message to the PDF.

Bearer modification

If the AF has requested a notification at the recovery of a bearer and the PDF receives a notification that a PDP context is modified from the bandwidth of 0 kbit to a higher value via the Go interface, the PDF shall send a Re-Auth_Request.

Indication of bearer release

If the AF has requested a notification at the release of a bearer and the PDF receives a notification that a PDP context is released via the Go interface, the PDF shall inform the AF about this event.

The distinction

Functional requirements Gq’ 3GPP Gq

For resource allocation and authorization for a media flow

Y

Note: support the resource control push or pull mode defined in TR-RACF

Y

Note: only support the resource control pull mode defined in TR-RACF

For QoS handling Y Y

For priority handling Y Y

For gating (enable/disable) control of a media flow

Y Y

To insert a NAPT function and request address mapping information

Y N

For dynamic firewall working mode selection

Y N

For resource usage information Y N

- 11 -TD 87 Rev.1 (WP 4/13)

Note: only token usage information

Session modification Y

Note: not mentioned in section 10.1.1, but contained in section 10.1.2

Y

Revoke authorization Y Y

Bearer modification Y


Y

Indication of bearer release Y


Y

1.2. Protocol requirements aspect

Protocol requirements of Gq’

Request-Response Transactions: The protocol must allow the SCF to request a transaction to be performed by the PDF and get a response (that can be correlated with the request) in return.

Notifications: The protocol must allow the notification of asynchronous events (from the PDF to the SCF).

Reliable Delivery: The protocol should provide reliable delivery of messages.

Extension Mechanisms: The protocol should including extension mechanisms such as versioning or other means to allow changes while ensuring backwards compatibility.

Capabilities: The SCF must be able to determine capabilities when requesting resources and other transport plane functions via the PDF.

Security: All messages between SCF and PDF must be authenticated such that requests to the PDF from unauthenticated sources will not be performed and such that notifications sent from the PDF to SCF can be ensured to come from the authenticated PDF source

One to Many: Multiple Service Control Functions must be able to make requests to a given PDF. An SCF may also communicate with multiple PDFs. However, only a single SCF will make a request to a given PDF for a particular session.

- 12 -TD 87 Rev.1 (WP 4/13)

Protocol requirements of 3GPP Gq

The Diameter Base Protocol as specified in RFC 3588 [6] shall apply except as modified by the defined Gq application specific procedures and AVPs.

support of Diameter agents: The support of Diameter agents between the PDF and the AF is optional for the IMS, where the Gq is intra operator i.e. GGSN, PDF and P-CSCF are all in the same network.

Advertising application support: The AF and the PDF shall advertise the support of the Gq specific Application by including the value 16777222 of the application identifier in the Auth-Application-Id AVP and the value of the 3GPP (10415) in the Vendor-Id AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands as specified in RFC 3588 [4], i.e. as part of the Vendor-Specific-Application-Id AVP.

Securing Diameter messages.

One to Many: One PDF shall be able to serve more than one AF and one given AF may interact with a number of PDFs, although on an AF session basis, it shall interact with only a single PDF

intra- or inter-domain interface: The Gq interface may be an intra- or inter-domain interface.

The distinction

Protocol requirements Gq’ 3GPP Gq

Request-Response Transactions Y Y

Notifications Y Y

Reliable Delivery Y Y

Extension Mechanisms Y N

Capabilities Y Y

Security Y Y

One to Many Y Y

Diameter Base Protocol Not required Y

support of Diameter agents Note: not limit specific protocol

Y

Advertising application support Y

Note: implemented in capabilities function

Y

Intra- or inter-domain interface Note: may consult similar mechanism

Y

- 13 -TD 87 Rev.1 (WP 4/13)

1.3. Information exchanged aspect

Information exchanged of Gq’

Policy Request for media flows: The SCF may request that policy be applied for one or more media flows. The SCF provides the following information to the PDF when requesting authorization and allocation for a media flow or flows:

Application Identifier: uniquely identifying the application instance that has established the resource reservations.

Session Identifier: representing a session that may be composed of multiple media flows requesting the resource reservation to RACF.

Media Flow Description: consisting of a set of parameters for an individual media flow

o Type of Service Information: voice bearer, video telephony bearer, streaming video etc.

o Classifier:

Mandatory classification parameters

o Address realm identification

o Flow Identification: consists of the following parameters

Source and destination unicast network address and protocol version [ IPv4, IPv6]

Protocol [ UDP, TCP … ]

Source and destination port

Port ranges shall be supported (e.g. two consecutive ports for RTP, RTCP).

Other Service QoS parameters (e.g., bandwidth or codec)

o Direction (in->out, out->in, bi-directional), where "in" refers to inside the core network so that "out->in" refers to the direction towards the core network.

o Service Priority Information: Service information for priority handling (e.g., TDR/ETS), if available.

o Service information for dynamic firewall working mode selection (e.g., security level.)

Editor’s note: Whether the above bullet should be moved up a level (so it is not specific to a media flow) is for further study.

o Bandwidth to be Committed: This value is specified when a "push" type allocation is done. A value of 0 indicates that no bandwidth should be committed.

- 14 -TD 87 Rev.1 (WP 4/13)

o Bandwidth to be Authorized: This is an upper limit on the amount of bandwidth that may be committed. Note that the authorized amount may be specified during initial setup, while allocation may be done either using a "push" or path-coupled mechanism. A later path-coupled reservation request that remains within the authorized limits will be accepted as long as resources are available.

Notifications Required (that do not have to be requested):

o A persistent notification is provided to the SCF in the case that the PDF determines that the bearer is lost or resources de-committed for some reason.

o Notifications associated with path-coupled mechanisms (e.g. RSVP): reservation committed; reservation modified; reservation released.

o Resource Usage information when resource allocation for the media flow is released...

Gate Control Policy: Indication of whether the gate should be automatically opened when the resources are committed or whether the SCF will supply a separate "enable" message.

Revoke Policy: An indication as to whether or not the PDF has the authority to revoke the authorization and de-commit resources at some future point in time (e.g. pre-emption).

Authorisation tokens: The PDF may generate one or more authorisation tokens on request from the SCF. Authorization tokens contain an identifier that identifies the PDF and a session identifier which allows the PDF to uniquely identify the application session (e.g. AUTH_ENT_ID and SESSION_ID).

Charging correlation information: The SCF and PDF may exchange charging correlation information, including resource usage information.

Gate control commands: The SCF must be able to enable the gate (open the gate) or disable the gate (close the gate) for a given media flow during the application session. Note that closing the gate does not de-commit bandwidth resources.

Request to Modify: The SCF must be able to request the PDF to modify the resource authorization and allocation for a media flow.

Request to Release: The SCF must be able to request the PDF to release the resource authorization and allocation for a media flow. It is to de-commit all resources associated with that media flow.

Notifications: The PDF must be able to notify the required information to the SCF that do not have to be requested by the SCF.

Responses: The PDF must be able to respond to a request or confirm a command from the SCF.

Transaction State Index: Index to the record of the transaction state of the resource control process for an ongoing application session. This is used for retrieving the session state when a stateless PDF is deployed. The session state record can be kept in the SCFs, BGF or TRCF and sent to PDF with a request/response command. The TSI only has a local significance between the PDF and pertinent parties.

- 15 -TD 87 Rev.1 (WP 4/13)

NAPT Control and NAT Traversal Description:

o Address Binding Information Request: The SCFs may request the RACF for the network address and port translation information in support of far-end NAT Traversal

o Address Binding Information Response: The PDF shall obtain the NAPT information, generate the address binding information and send it to the relevant SCFs. The SCFs shall modify the relevant message body of application signalling packet.

o Address Translation Command: The PDF may perform the NAPT control, obtain the address binding information, and request the SCFs to modify signalling messages accordingly based on network address hiding policy decision.

Information exchanged of 3GPP Gq

AA-Request (AAR) command: The AAR command is sent by an AF to the PDF in order to request the authorization for the bearer usage for the AF session.

AA-Answer (AAA) command: The AAA command is sent by the PDF to the AF in response to the AAR command.

Re-Auth-Request (RAR) command: The RAR command is sent by the PDF to the AF in order to indicate a specific action. As an option, the AF may send an AAR command to the PDF to update the service information when receiving an RAA command. However, application-specific authentication and/or authorization messages are not mandated for the Gq application in response to an RAR command.

Re-Auth-Answer (RAA) command: The RAA command is sent by the AF to the PDF in response to the RAR command.

Session-Termination-Request (STR) command: The STR command is sent by the AF to inform the PDF that an authorized session shall be terminated.

Session-Termination-Answer (STA) command: The STA command is sent by the PDF to the AF in response to the STR command.

Abort-Session-Request (ASR) command: The ASR command is sent by the PDF to inform the AF that all bearer resources for the authorized session have become unavailable.

Abort-Session-Answer (ASA) command: The ASA command is sent by the AF to the PDF in response to the ASR command.

The distinction

Information exchanged Gq’ 3GPP Gq

Policy Request for media flows Y Y

Notifications Required Y

Note: not have to be

Y

- 16 -TD 87 Rev.1 (WP 4/13)

requested

Gate Control Policy Y N

Note: not specified

Revoke Policy Y Y

Authorization tokens Y

Note: The PDF may generate one or more authorization tokens on request from the SCF

Y

Note: an session have one token ,and one token may contains a flow group

Charging correlation information Y Y

Gate control commands Y Y

Request to Modify Y N

Request to Release Y Y

Notifications Y Y

Responses Y Y

Transaction State Index Y N

NAPT Control and NAT Traversal Description

Y N

Re-Auth-Request (RAR) command Y

Note: can be implemented by Notifications message.

Y(PDF->AF)

Abort-Session-Request (ASR) command

Y

Note: can be implemented by Notifications message.

Y(PDF->AF)

Note: triggered as all bearer resources for the authorized session have become unavailable

- 17 -TD 87 Rev.1 (WP 4/13)

Appendix 2: Comparison between Go’ and 3GPP Go

The Go’ reference point allows the final admission decisions to be “pushed” or “pulled” to A-BGF/I-BGF from PDF. This reference point should be compatible as defined by 3GPP Release 6 in [3GPP TS 29.207], and should support the NAPT/Firewall Control and NAT traversal at A-BGF/I-BGF as needed.

The Go interface allows service-based local policy information to be "pulled" to or requested by the Policy Enforcement Point (PEP) in the GGSN from a Policy Decision Function (PDF). The Go interface uses IP flow based policies.

1. Detailed Comparison and Analysis

1.1. Functional requirements

Functional requirements of Go’

The PDF may specify:

1) Resources to be committed for a media flow,

2) QoS handling such as DSCP marking to use,

3) Gate (enable/disable) control for a media flow,

4) The insertion of a NAPT function, requesting the necessary address mapping information.

5) Resource Usage information request and report for a media flow.

6) Dynamic firewall working mode selection (e.g. selection of the working mode of packet-filter-based firewall) for a media flow,

7) Technology independent core network ingress path information for a media flow,

In addition, the PDF can request notification of events and may receive a request from the A-BGF/I-BGF to verify an authorization token that has been obtained via a path-coupled resource signalling mechanism. The Go’ reference point allows the PDF to push the final admission decisions to the A-BGF/I-BGF and also allows for path-coupled resource allocation mechanisms where the admission decision is requested from the A-BGF/I-BGF ("pull" mechanism).

Functional requirements of 3GPP Go

1) Authorization function:

The PDF shall be able to provide an authorization decision upon receiving a bearer authorization request from the GGSN. The PDF shall authorize the request according to the stored session and media related information received from the AF.

2) Revoke function:

The PDF may revoke the authorisation of resources at any time. Revoke Authorisation for GPRS and IP resources is communicated by the PDF to the GGSN.

3) Approval of QoS Commit / Removal of QoS Commit

- 18 -TD 87 Rev.1 (WP 4/13)

The PDF may allow or deny the usage of the PDP context for the selected IP flow(s) by controlling the correlated gate(s).

4) Actions due to Indication of bearer release:

When the GGSN informs the PDF of bearer deactivation, the PDF shall remove the corresponding authorisation request state. Additionally, the PDF shall inform the AF about this deletion event.

5) Actions due to Indication of bearer modification:

When the PDF receives an indication of bearer modification of the maximum bit rate to or from 0 kbits/s, the PDF shall inform the AF about this modification event.

6) Charging Correlation

To ensure charging correlation, the PEP shall send the GCID and the GGSN address to the PDF. The PDF shall also send the AF charging identifier, if available, to the GGSN.

The distinction

Functional requirements Go’ 3GPP Go

Resources to be committed for a media flow

Y Y

QoS handling such as DSCP marking to use

Y N

Note: The GGSN shall perform the proper mapping between the IP QoS information and the UMTS QoS information.

Gate control for a media flow Y Y

The insertion of a NAPT function, requesting the necessary address mapping information.

Y N

Resource Usage information request and report for a media flow.

Y N

Dynamic firewall working mode selection for a media flow

Y N

Technology independent core network ingress path information for a media flow

Y N

Revoke function Note: Not specified

Y

- 19 -TD 87 Rev.1 (WP 4/13)

Actions due to Indication of bearer release

Note: not specified

Y

Actions due to Indication of bearer modification

Note: not specified

Y

Charging Correlation Y Y

1.2. Protocol Requirements

Protocol Requirements of Go’

1) Request-Response Transactions: The protocol must allow the PDF to request a transaction to be performed by the A-BGF/I-BGF and get a response in return.

2) Notifications: The protocol must allow the notification of asynchronous events.

3) Reliable Delivery: The protocol should provide reliable delivery of messages.

4) Extension Mechanisms: The protocol should including extension mechanisms such as versioning or other means to allow changes while ensuring backwards compatibility.

5) Capabilities: The PDF must be able to determine capabilities when requesting resources and other transport plane functions from the A-BGF/I-BGF.

6) Security: All messages between PDF and A-BGF/I-BGF must be authenticated such that requests to the A-BGF/I-BGF from unauthenticated sources will not be performed and such that notifications sent from the A-BGF/I-BGF to PDF can be ensured to come from an authenticated A-BGF/I-BGF source.

Protocol Requirements of 3GPP Go

1) TCP connection for COPS protocol: If there is no existing TCP connection to the PDF, the GGSN shall establish a TCP connection for COPS interactions to the PDF. The GGSN shall use an existing TCP connection to the PDF, whenever present.

2) COPS protocol: The Go interface shall conform to the IETF COPS (RFC 2748 [7]) and the extensions of COPS-PR (RFC 3084 [8]). The COPS protocol supports a client/server interface between the GGSN and the PDF.

3) Security Considerations: The security mechanisms described in COPS (RFC 2748 [7]) and COPS-PR (RFC 3084 [8]) should be re-used in 3GPP.

The distinction

Protocol Requirements Go’ 3GPP Go

Request-Response Transactions Y Y

Note: shall conform to the IETF COPS framework as a requirement and guideline.

- 20 -TD 87 Rev.1 (WP 4/13)

Notifications Y Y

Reliable Delivery Y Y

Note: The GGSN shall establish a TCP connection for COPS interactions to the PDF.

Extension Mechanisms Y Y

Capabilities Y Not be specified

Security Y Y

1.3. Information Exchanged

Information exchanged of Go’

1) Request to Commit for a Media Flow: The PDF provides information to the A-BGF/I-BGF when requesting resource allocation and flow handling for a given media flow:

2) Authorization tokens: In the case of a path-coupled mechanism, an authorization token for the media session may be passed from the A-BGF/I-BGF to the PDF for authentication check. The token may contain policy data that was previously authorized and authenticated by the PDF.

3) Charging correlation information: The PDF and A-BGF/I-BGF may exchange charging correlation information, including resource usage information.

4) Gate control commands.

5) Request for NAPT binding information: In the case where network address and port translation is required, the PDF must be able to act as an intermediary and respond with the NAPT mapping information obtained from the A-BGF/I-BGF to the SCF. The SCF use the NAPT mapping information to modify the related application signalling message body.

6) Request to Modify: The PDF must be able to request the A-BGF/I-BGF to modify the resource allocation and flow handling for a media flow.

7) Request to Release: The PDF must be able to request the A-BGF/I-BGF to release the resource allocation and flow handling for a media flow. It is to de-commit all resources associated with that media flow.

8) Notifications: The A-BGF/I-BGF must be able to notify the required information to the PDF that do not have to be requested by the PDF.

9) Responses: The A-BGF/I-BGF must be able to respond to a request or confirm a command from the PDF.

Information exchanged of 3GPP Go

1) Authorisation_Request (REQ) (GGSNPDF): This event allows the GGSN to request authorisation data from the PDF.

- 21 -TD 87 Rev.1 (WP 4/13)

2) Authorisation_Decision (DEC) (PDFGGSN), contains an INSTALL decision: This event provides the GGSN with the relevant authorisation data. The event contains the following information.

- Client Handle;

- ICID(s) (only in the initial Authorisation_Decision). Only one ICID is transferred in this Release. The form of the ICID is defined in 3GPP TS 32.225 [21];

- Unidirectional set (this parameter shall appear once for each direction (uplink and downlink)):

- Direction indicator;

- "Authorised QoS";

- Gate description (this parameter shall appear once for each required gate for this direction):

- Filter Specification

- Gate status (opened/closed)

3) Authorisation_Failure (DEC) (PDFGGSN), contains an INSTALL and a REMOVE decision. This event provides the GGSN with an indication of an authorisation failure, and may carry additional reason details.

4) Gate Decision (DEC) (PDFGGSN), contains an INSTALL decision: The Gate Decision indicates to the GGSN the new status of the gate(s) established for a client handle (PDP context). The gate status indicates to the GGSN that the gate shall be opened or closed. Only the gate(s) for which the status is changed are indicated by this event.

5) Report (RPT) (GGSNPDF): The GGSN sends a COPS RPT message as a response to a decision (DEC) message back to the PDF reporting that it enforced or not the Authorisation_Decision or the Authorization_Failure_Decision (Authorization_Report) or the Gate_Decision (Gate_Report).

6) Report of state changes (GGSNPDF): The GGSN sends the report of state change message to the PDF reporting that the maximum bit rate for the PDP context is modified to 0 kbps or that the maximum bit rate for the PDP context is changed from 0 kbps.

7) Delete Request State (DRQ) (GGSNPDF): The GGSN informs the PDF via the delete request state message, that the PDP context is deactivated and the request state identified by the client handle is no longer available/relevant at the GGSN, so the corresponding state shall also be removed at the PDF.

8) Remove_Decision (DEC) (PDFGGSN): The PDF uses the Remove_Decision to inform the GGSN that the PDF revokes the authorized resources for the client handle (PDP context). The Remove_Decision is a specific Decision message with the COPS Decision Flags object set to 0x02 ("Request-State" flag) and the Command-Code set to "REMOVE"; see IETF RFC 3084 [8].

- 22 -TD 87 Rev.1 (WP 4/13)

The distinction

Information Exchanged Go’ 3GPP Go

Request to Commit for a Media Flow(PDF -> A-BGF/I-BGF)

Y Y

Note: the same function is achieved by Authorisation_Decision

Authorization tokens Y Y

Charging correlation information(between PDF and A-BGF/I-BGF)

Y Y

Gate control commands(PDF->A-BGF/I-BGF)

Y Y

Request for NAPT binding information(PDF->A-BGF/I-BGF)

Y N

Note: don’t detail in Go

Request to Modify(PDF->A-BGF/I-BGF)

Y Note: the similar function is achieved by Authorisation_Request, Authorisation_Decision in sequence.

Request to Release(PDF -> A-BGF/I-BGF)

Y Note: the similar function is achieved by Delete Request State, Remove_Decision in sequence.

Notifications(A-BGF/I-BGF -> PDF) Y Y

Responses(A-BGF/I-BGF->PDF) Y Y

Authorisation_Request (GGSNPDF)

Note: support, but don’t specified explicitly

Y

Authorisation_Failure (PDFGGSN) Note: support, but don’t specified explicitly

Y

Delete Request State (GGSNPDF) Note: not specified Y

Note: the main differences between the Go’ and the 3GPP Go is as follows:

In Gq’, for the purpose of the initial authorization of Qos resource the push or pull operation is used. However, in 3GPP Go, for the initial authorizations only the pull operation is used.

- 23 -TD 87 Rev.1 (WP 4/13)

Appendix 3: Example deployment configuration of RACF: Service Providers and Network Operators Independent

The configuration is needed to clarify the usage of RACF in NGN scenarios. An example configuration is agreed in the meeting to identify the functions, interfaces and interactions between different functional entities in a complex Service Providers and Network Operators independent NGN scenario.

In the example configuration, Service Providers #1 and #2 are independent of Network Operators #1 and #2. The Service Provider #1 and #2 interconnect with network operator #1 and #2 respectively to support per application session based resource control, e.g. QoS control, and Network Address Hiding at the border of network operator #1 and #2.

Notes:

1. Service Provider represents a provider offering per subscriber/session based services and pertinent service/session control functionality.

2. Network Operator represents a carrier providing session aware transport network functionality (i.e. per application/session based QoS/resource control/processing).

3. Transit Network is a special form of the network that only provides the wholesale trunking (“pipe”) transit based on the transport SLA (i.e. aggregate level QoS/resource processing for the entire pipe).

4. The administrative domain can be demarcated by the ownership, e.g. services and service control functions are owned by a service provider and transport networks are owned by a network operator; or by the authority of administration within the same ownership, e.g. access networks and core networks can be segmented due to the administrative policy in the same operator.

Further contributions are requested to clarify open issues in this area, for example:

1. Is Network operator #1 an access network provider or more?

2. The configuration of functional entities in generic RACF functional architecture in other NGN scenarios, e.g.

Service Provider #1

RACF

SCFs

Access/Core Transport CPN

Network Access Attachment Functions

PDF

ENF

A-BGF

A-TRCF

Gq’

Go’

Ub

SCPF

Re

R-BGF

ANF

Re Rc

Rq

Service Stratum

Transport Stratum

Core Transport

Service Provider #2

RACF

SCFs

PDF

A-BGF

Gq’

Go’

SCPF

I-BGF

I-TRCFC-TRCF

RcRc

RqRqRp

Go’

Network Operator #1

Network Operator #2

Iq

- 24 -TD 87 Rev.1 (WP 4/13)

1) Wholesale transit network in the access side and session-aware transport control in the core side.

2) Session aware transport control in the access side and wholesale transit networks between session-aware transport networks.

3) Mobility scenarios

- 25 -TD 87 Rev.1 (WP 4/13)

Appendix 4: Intra-network RACF interaction approaches

This section is to describe the implementation examples of the intra-network RACF interaction approaches.

From the viewpoint of the end-to-end association between functional entities of RACF, there are two approaches for the QoS control from one end to another end. One is the approach in which the RACF performs the QoS control in parts and achieves the entire end-to-end control with the intermediation of the service stratum functions (Approach A). Another is the approach in which the RACF performs the QoS control within the transport stratum without the intermediation of the service stratum functions (Approach B).

Note: This consideration is about the QoS control. Approach B is not applied to NAPT/Firewall control, NAT Traversal Firewall.

The typical cases for the application of Approach A are, for example;

- The case that there is a part, in which the admission control is not required per flow, through the entire end-to-end route of the media,

- The case that the approach meets the requirement of the network control.

The typical cases for the application of Approach B are, for example;

- The case that there is a single SCPF related the service requesting QoS control

- The case that it is required for the interaction between functional entities in RACF to be independent from the intermediation of functional entities in the service stratum. This may be required for the consideration on the business model, the immediacy of the coordination between functional entities of the transport stratum, etc.

- 26 -TD 87 Rev.1 (WP 4/13)

Figure I-1: Approaches for intra-network RACF interaction

Note:

- These figures describe the case that the leftmost PD-FE is invoked initially by SCPF.

- The bold lines show the route of the end-to-end QoS control.

- The PD-FE interacting with TRC-FE may be the same as the neighbouring PD-FE interacting with TRC-FE.

- 27 -TD 87 Rev.1 (WP 4/13)

Appendix 5: Inter-network RACF interaction approaches

In the general case that the data stream is transferred through the transit transport network(s), the resource and admission control in the transit network(s) as well as the both end networks is required for the end-to-end QoS. The RACF in the transit network should communicate with both ends for the control of the end-to-end resource control. For the inter-working of the transit RACF with the RACF invoked with resource request, there are two example approaches as followed;

Approach 1: The direct communication between RACSs other than the communication between the last RACF and the previous RACF

Approach 2: The direct communication through all the RACF along the data transmission route (without the interaction between the rightmost SCF and the rightmost RACF as the resource and admission control) Approach 2 is not applied to NAPT/Firewall control and NAT TraversalFirewall.

Figure II-1: Approaches for the inter-network RACF interaction

Notes:

- This figure describes the case that the left PD-FE in RACF#1 is invoked initially by SCPF.

- 28 -TD 87 Rev.1 (WP 4/13)

- The policy decision on the interworking across the network boundary is assumed to be performed by PD-FE. I-BCF is omitted for simplicity. The bold lines show the route of the end-to-end QoS control.

- In the case of approach 1, there is discontinuity of the inter-RACF communication. In the case with such the indirect interaction (i.e. the intermediation of SCPFs), it should be examined whether the information/notification for the resource and admission control can be performed, whether the allocated routes is continuous across the discontinuity point, and so on.

There may be a problem in an immediacy of the interaction from one end through another end in the case that the route changes due to the link failure. The link failure may result in the route change without the termination of active data streams and this may cause the route change in the succeeding domain or network. In such the cases, in preparation to the succeeding resource requests, it is necessary for RACFs to immediately notify the change of the resource assignment with each other due to this route change. In approach 1, the interaction for the notification between RACF#2 and RACF#3 is performed through the SCPF-SCPF interaction and this results in the procedural delay. From the viewpoint of the immediate notification through end-to-end RACFs, approach 2 is applied.

Approach 2 means not only that the inter-RACF communication is performed from one end to another end without discontinuity but also RACFs receive the QoS request at a single point.

- 29 -TD 87 Rev.1 (WP 4/13)

Appendix 6: Static Resource Admission Control at Heterogeneous Transport Environment

Abstract

It needs to develop the relevant recommendation for static resource admission control at heterogeneous transport network environments as an extension of RACF. It should be aware of the existing transport network elements (such as OXC, OADM, and legacy L2/L3 switches, etc.) which are not implemented to support dynamic flow-based traffic control.

Introduction

Many of current transport network equipments cannot be implemented to support QoS control dynamically, which are mainly configured or controlled by operator. The most current transport networks are designed to provide aggregate flow QoS control. To converge all transport network elements like OXC/OADM, layer 2/3 switches, and legacy routers within NGN, the static resource admission control function is essential to support end-to-end QoS in heterogeneous transport environment.

Then, a study on static resource admission control functions is needed in alignment with RACF. It looks a part of extensions of RACF document in order to support static provisioning scenario of NGN resources.

The static RACF can utilize the existing control and management interfaces (e.g., SNMP and vendor specific graphic user interface, etc.) if possible. It also considers an interface with NMS. The static resource admission control functions may include connection admission control, congestion control, re-routing, re-allocation of network capacity as well as aggregate QoS provisioning.

Study items:

It is proposed that the work items of static resource admission control functions within Q.4/13 to be studied.

- Consider heterogeneous transport network elements including optical XC, optical ADM, legacy L2/L3 switches, and other transport network elements which could not designed to support dynamic flow-based control

- Provisioning-based resource reservations according to per channel, per link, per fiber-based network resources to provide aggregate QoS

- Utilize the existing control and management interfaces (e.g., SNMP)

- Interworking of RACF-supported and non-RACF supported domain

It requests some collaboration with other SDOs to develop specific control and management protocols for static resource admission control within the NGN environments.

List of documents addressing the issue

- kobe-q04-13-27, Kobe 22-27 April, 2006

- kobe-q04-13-31, Kobe 22-27 April, 2006

Relevant Recommendation(s)

- as companion Recommendation with RACF (as a part of extension of RACF)

- 30 -TD 87 Rev.1 (WP 4/13)

In collaboration with

- ITU-T SG4

- pce WG, gmpls WG (IETF)

Status: Under study (April 2006, Kobe)

____________________

The following structure of document is requested to consider.

Title: Functional Requirements and Architecture for Static Resource and Admission Control Functions in heterogeneous transport networks of Next Generation Networks

Table of Contents

1. Scope of Static Resource Admission Control Function

2. References

3. Definitions and Terms

4. Abbreviations and Acronyms

5. Overview and requirements of Static Resource Admission Control Function

5.1 Overview

5.2 High-level requirements

6. Static Resource Admission Control Function Mechanism and Scenarios

7. Functional Architecture of Static Resource Admission Control Function

8. Procedures of Static Resource Admission Control Function

9. Mechanisms of Static Resource Admission Control Function

1. Scope of Static Resource Admission Control Function

This proposal provides the requirements, scenarios, functional architecture and decomposition, and mechanisms for the Static Resource and Admission Control Functions in support of end-to-end QoS and resource control where transport network can support only aggregate flow QoS control in Next Generation Networks (NGNs) or no specific QoS mechanism(Best effort).

2. References

3. Definitions and Terms

4. Abbreviations and Acronyms

5. Overview and requirements of Static Resource Admission Control Function

(Editor’s note: the reference architecture is based on RACF with Network Management System. co-work with NMS is key point to support QoS in Static Resource Admission Control Function. The relation between RACF and NMS should be considered.)

- 31 -TD 87 Rev.1 (WP 4/13)

Figure 1: Static Resource Admission Control Function within the NGN architecture

6. Static Resource Admission Control Function Mechanism and Scenarios

Scenario 1: QoS resource control scenario

Figure 2: The flow diagram for Scenario 1

The CPE requests an application-specific service by sending a “Service Request” (e.g. SIP Invite, HTTP Get, etc.) to the Service Control Functions and may also send a dedicated application layer QoS signalling request. The Service Request may or may not contain any explicit service QoS requirement parameters.

(1) The Service Control Functions extract or derive the service QoS requirement parameters (e.g. bandwidth etc.) of the requested service, and then request QoS resource authorization and reservation from the RACF by sending a ‘Resource Reservation Request’ which contains the explicit QoS requirement parameters.

(2) The RACF performs authorization and admission control based on operator policy rules, resource availability and user profile in the NACF.

Scenario 2 : QoS sustainment scenario

Figure 3: The flow diagram for Scenario 2

(1) The RACF gets states of Transport Function by QoS measurement which mechanism can be polling or reporting of the Transport Network. The RACF uses the information for admission control.

(2) The RACF reports the required QoS will not be satisfied. When the NMS recognizes that the QoS of network will become worse than or fail to sustain, it has actions such as rerouting traffic, changing congestion policy and increasing network capacity based on its policy.

(3) The NMS controls Transport Functions as its mechanisms from network planning to traffic engineering.

(4) The NMS informs the RACF what the network topology and configuration change and their effects. The RACF updates the information to use its admission control policy.

7. Functional Architecture of Static Resource Admission Control Function

(Editor’s note: following item will be considered

- OAM initiating capability in SRACF

- aggregate resource control

- inter-working in NMS

- else.

Service Control Functions

SRACF

Transport FunctionsCPE

NACF(1)

(2) (3)


Static Resource and Admission

Control Functions


NACF

Other N

GN

sService Stratum

Transport Stratum


SRACF


NACF

(1)

(2)

(4)

(3)

NMF

NMF

NMF

- 32 -TD 87 Rev.1 (WP 4/13)

)

8. Procedures of Static Resource Admission Control Function

________________

(extracted from kobe-q04-13-31, Kobe 22-27 April, 2006)

(The following texts are needed to consider the legacy management interface)

NGN RACF functions in heterogeneous environments is partially operated only at RACF-controllable equipments. But intermediate phase before coming entire RACF-controllable phase will contain various types of RACF-uncontrollable legacy equipments, and end-to-end QoS will not be provisioned well as we’ve requested.

In the layered architecture of Figure 1, the QoS control information can be extracted using the management functions of RACF-uncontrollable legacy equipments. Under these environments The proposed approach to provide end-to-end QoS as shown in Figure 2.

Figure 2. Proposed Approach to Provide QoS and Resource Control for RACF-uncontrollable Legacy Equipment

In order to adopt the RACF functional capabilities in the heterogeneous network environments efficiently, MA (Management Agent) is necessary to provide interface functions with RACF-uncontrolled equipments. As depicted in Figure 3, the additional standard interfaces, Rm1 and Rm2

will be necessary to provide flexibility in NGN RACF. And the interaction between P-MA/T-MA and legacy transport equipment will be performed by existing protocol in described at Table 1. As an example, SNMP will be one of strong candidate to exchange some management information with RACF-uncontrollable devices. MA (Management Agent) takes role to collect the required management informations related with resource management, topology information, and QoS control, and needs standard MIB or extended MIB to interoperate with heterogeneous equipments. For example:

- MIB for Network Resource

- MIB for Network Topology

- MIB for Device Capability of Uncontrollable Legacy Network Equipments with MA

- 33 -TD 87 Rev.1 (WP 4/13)

Figure Resource admission control functions to consider legacy network environments

- 34 -TD 87 Rev.1 (WP 4/13)

Appendix 7: Rationale for Additional Work in Support of RACF Element

1 Application Specifications and Requirements

A representative set of applications and services (e.g., Emergency VoIP, multimedia, IPTV, etc) needs to be identified for applicability with the RACF functionality. For each service type a complete set of QoS, priority, and security requirements – and how these can be met – needs to be specified. Attention needs to be paid to the following issues for each application/service:

Mapping application performance requirements into network performance classes as specified by ITU-T Recommendation Y.1541.

Mapping application priority requirements into Layer 3 priority classes currently under development in Q4/13.

Handling codec negotiation with differing bandwidth requirements.

Handling header compression when used.

Bandwidth allocation and accounting of utilized bandwidth.

2 End to End Information Flow

Detailed call/session flows need to be developed for all applications and service types. The purpose of such flows is to:

Enable better understanding of how specific actions will be implemented at various reference points.

Determine whether currently defined functionality is adequate.

Ensure architectural efficiency for delivery of timely actions (e.g., setup delays should not be excessive).

Determine whether multiple reference points can be “collapsed together” for better efficiencies.

A good example of such a call/session flow is provided in [RSVP/DSTE-Proxy] Appendix A (“Example Usage of RSVP Aggregation over DSTE Tunnels for VoIP Call Admission Control (CAC))”.

- 35 -TD 87 Rev.1 (WP 4/13)

Appendix 8: Comparison of TISPAN RACS and ITU-T RACF

1 Introduction

The Resource and Admission Control has been defined in TISPAN and in ITU-T:

- ETSI ES 282 003 v1.1.1: TISPAN Resource and Admission Control Subsystem (RACS) Functional Architecture (March 2006).

- SG13 - WP 4/13 - TD 81 Rev.2: Draft Recommendation Y.RACF version 8.1 (January 2006). This Recommendation is planned to be finalize in NGN GSI meeting in April and to be approved in SG13 meeting in July.

The both architectures have different scopes. The terminologies are different because they are in line with different general architectures. It is possible to identify common aspects, but also some differences. This contribution proposes to compare these architectures to identify the common parts and the differences.

The further step could be to try to converge in Release 2 to a common architecture.

2 ETSI TISPAN RACS

- ETSI ES 282 003 v1.6.8: TISPAN Resource and Admission Control Subsystem (RACS) Functional Architecture (December 2005).

Figure 2 provides an overview of the ETSI TISPAN RACS (Resource and Admission Control Subsystem) architecture.

Di

Transport Layer

Rq

Di

A-RACF

Ia

e4

Re

Gq’

Ra

NASS

AF

SPDF

CoreBorder Node

BGF

Ip Edge

RCEF

L2TPointAccess

Node

RACS

UEDs

Di

Transport Layer

Rq

Di

A-RACF

Ia

e4

Re

Gq’

Ra

NASS

AF

SPDF

CoreBorder Node

BGF

Ip Edge

RCEF

L2TPointAccess

Node

RACS

UEDs

Figure 2: RACS Functional Architecture

Functions:

- 36 -TD 87 Rev.1 (WP 4/13)

- AF: Application Function

- A-RACF: Access-Resource and Admission Control Function

- BGF: Border Gateway Function

- L2T: Layer 2 Termination Function

- NASS: Network Attachment Sub-system

- RCEF: Resource Control Enforcement Function

- SPDF: Service-based Policy Decision Function

- UE: User Equipment

3 ITU-T RACF

- SG13 - WP 4/13 - TD 81 Rev.2: Draft Recommendation Y.RACF version 8.1 (January 2006).

Figure 1 provides an overview of the ITU-T RACF (Resource and Admission Control Functions) architecture.

RACF


Transport Functions

Network Attachment

Control Functions

Other N

GN

s

TRC-FE

Rs

Rw

Ru

Rn Rc

Rp Rt

Service Stratum

Transport Stratum Rd

Ri

PE-FE

PD-FE

TE-FE Interconnection

Functions

Figure 1: Generic Resource and Admission Control Functional Architecture in NGN

Functional entities:

- PD-FE: Policy Decision Functional Entity

- PE-FE: Policy Enforcement Functional Entit

- TE-FE: Transport Enforcement Functional Entity

- TRC-FE: Transport Resource Control Functional entity

4 General Scopes

This section summarizes the general scopes of the both recommendation.

- 37 -TD 87 Rev.1 (WP 4/13)

ITU RACF TISPAN RACS

Networks Fixe and Mobile (but no compatible with 3GPP)

Fixe

Access, Core Access, Core (only border, no admission control)

QoS mechanisms Push, Pull Push

Topology aspect Covered, but not detailed Not covered

NACF/NASS interaction NACF not defined in details

Interface Ru at TRC-FE level not detailed

Interface e4

Stage 3 On going work on Rs, Rw, Rc, Rp, Rt.

Rn, Rd, Ri, Ru not covered

Rq, Gq', Ia, e4 covered

Ra, Re not covered

Usage metering Covered Covered

Charging Off-line charging identified Off-line charging identified

HomeGateway interaction Not covered (R2) Not covered (R2)

Table 1: General Scopes

5 Elementary functions

The functionalities of RACF in ITU-T are defined by elementary functions, when TISPAN describes textual functionalities.

The following table is based on ITU-T elementary functions and identifies the functions covered by TISPAN RACS.

ITU-T RACF Elementaty Function TISPAN RACS

Comments

Final Decision Point

(FDP)

+

QoS and Priority Mapping - Technology Independent(QMTI)

+

Gate Control(GC)

+

IP Packet Marking Control(IPMC)

+

- 38 -TD 87 Rev.1 (WP 4/13)

NAPT Control(NAPTC)

+

Rate Limiting Control(RLC)

+

Firewall Working Mode Selection(FWMS)

Single or double NAT

covered

The firewall working mode selection is intended

to specify the packet filtering operation (some

high level descriptions are in section 7.2.4.1). The

NAT control is a separate function.

Core Network Path Selection(CNPS)

+ Partially covered : MPLS Label Stack or VLAN in

Core

Networks Selection(NS)

- Not covered

Technology Dependent Marking Control(TDMC)

Note 1 Support of TDMC is not explicitly described.

Conceptually the TDMC function is assumed to be supported through a local mapping between Layer 3

marking add Layer 2 marking performed at the RCEF to L2TF interface.

QoS Mapping - Technology Dependent(QMTD)

Note 1 Support of QMTD is not explicitly described.

Conceptually the QMTD function is assumed to be supported through a local mapping between Layer 3 QoS parameters and Layer

2 QoS parameters at the RCEF to L2TF interface.

Technology Dependent Decision Point(TDDP)

Note 1 The A-RACF decisions are based on user profiles and available bandwidth over L2 resources in the access and aggregation

networks. The technology as such (e.g GE or ATM) does not influence these

decisions.

- 39 -TD 87 Rev.1 (WP 4/13)

Network Topology Maintenance(NTM)

- § 5.2.3.2.3:The Physical Access ID, Logical Access

ID and Access Network Type allows A-RACF to

bind the Subscriber Id and/or its IP address to the

topology information of the access and aggregation

networks hosted in A-RACF.

Network Resource Maintenance(NRM)

- Not covered

Element Resource Control(ERC)

? Outside the scope of ITU-T R 1

Table 2: Elementary functions

Note 1: The “Technology dependent “definition is not clear.“Technology dependent” might refer to for example; ATM and Ethernet have different detailed processing regarding the same function here.

6 Functional Entities

ITU RACF ETSI RACF

PD-FE FDP, QMTI, GC, IPMC, NAPTC, RLC, FWMS, CNPS, NS, TDMC

SPDF

A-RACF (partial)

FDP, QMTI, GC, IPMC, NAPTC, RLC, FWMS, CNPS, TDMC

?

TRC-FE QMTD, TDDP, NTM, NRM, ERC

A-RACF (partial)

The A-RACF performs admission control decisions based on user profiles and available bandwidth over a set of L2 dedicated and/or shared resources.

Note 2.

TE-FE TE-FE = Access Node in Access? or L2T Point ?

Access Node / L2T Point

The L2TF provides a subset of the TE-FE functions. Although not explicitly modelled is it likely that TE-FE functions exist in physical nodes hosting a BGF and in the Access Node

PE-FE - Opening and closing gate

- Traffic classification and marking

C-BGF - Open / close gates

- Packet marking

- 40 -TD 87 Rev.1 (WP 4/13)

- Rate limiting and bandwidth allocation

- Network address and port translation

- Collecting and reporting resource Usage information

- Traffic policing and shaping

- Mapping of layer 3 QoS information onto link-layer QoS information

- Media Relay (i.e. address latching) for NAT Traversal

- Packet filtering based firewall

- Resource allocation (per flow)

- NAT

- Usage metering

- Policing of down/uplink traffic

- Hosted NAT traversal

PE-FE RCEF = PE-FE with a limited set of functionalities.

RCEF RCEF = C-BGF excluding NAPT-related functions. The RCEF also incorporates the functions required to interact with the L2TF

PE-FE I-BGF Same as C-BGF except Hosted NAT traversal

Table 3: Functional Entities

Note 2:

What actually happens is that the A-RACF performs admission control for L3 sessions that use L2 transport resources (i.e. determines whether there is enough bandwidth for an L3 session to be admitted in a particular L2 pipe).

Shared / Dedicated Resources:

Per subscriber sharing

When performing admission control the A-RACF checks that the amount of requested bandwidth is compatible with the subscribed bandwidth (received over the e4 reference point) and the amount of bandwidth remaining in this envelope.

TISPAN R1 does not place any restriction on whether L2 transport resources are dedicated to a subscriber or shared between subscribers.

If the L2 transport resources are dedicated (e.g. ATM VC) to the subscriber the above step is sufficient unless the actual capacity of the dedicated layer 2 pipe is less than the subscribed bandwidth.

- 41 -TD 87 Rev.1 (WP 4/13)

If the L2 transport resources are shared between subscribers (this includes the case where only the aggregation segment ressources are shared which is quite common in the case of GE aggregation), the A-RACF shall also check that the amount of bandwidth requested is compatible with the amount of bandwidth remaining on the shared resource. This check may fail e.g. due to overbooking.

Per service sharing

TISPAN R1 does not place any restriction on whether L2 transport resources are dedicated to a specific service set (e.g. one ATM VC supporting IMS traffic, one ATM VC supporting VOD) or shared between all services. However, there is an implicit assumption that signalling messages are intercepted by the network so that the A-RACF can be made aware of the resources used by such services (i.e. otherwise the A-RACF can't figure out how much bandwidth is actually available). This assumption may not be valid for Internet Access traffic.

From the previous comparison, it appears that

- PD-FE and SPDF are quite similar. Some functionality of TRC-FE could be included in SPDF.

- TRC-FE and A-RACF are not exactly the same functional entity.

- PE-FE could be similar to C-BGF, I-BGF, RCEF depending of the localization, if the PE-FE functionalities are optional.

- TE-FE is not clearly defined, but seems to be similar to L2T Point. Perhaps some part of RCEF could be also in TE-FE.

This analysis should be confirmed.

7 Reference Points / Interfaces

This section gives only a first approach of the comparison between Reference Points / Interfaces. Further studies are needed to detail the differences.

ITU RACF TISPAN RACS

Service - PD-FE Rs Stage 3 on-going Gq’ Stage 3

PD-FE - PE-FE Rw Stage 3on-going Ia?

Re?

The mapping between this reference point and the TISPAN Ia and Re reference points requires further studies

TRC-FE - Transport Rc Partially defined.

Stage 3 on-going

-

TRC-FE - TE-PE Rn Post R1 -

PD-FE - TRC-FE Rt Stage 3 on-going ? Stage 3

Inter PD-FE (intra-domain)

Rd Stage 2 Rq? Not covered

- 42 -TD 87 Rev.1 (WP 4/13)

Inter PD-FE (inter-domain)

Ri Post R1 Rq? Not covered

Inter TRC-FE Rp Stage 3 on-going - Not covered

NACF - RACF Ru Ru partially defined (NASS not defined in details)

e4 Stage 3

Table 4: ITU-T Reference Points

TISPAN RACS ITU RACF

AF- SPDF Gq’ Stage 3 Rs Stage 3

SPDF - BGF Ia Stage 3 Rw? To be confirmed

A-RACF - RCEF Re Stage 2 Rw?

Rn?

The mapping between this reference point and the ITU-T Rw andr Rn reference points requires further studies.

SPDF - A-RACF Rq Stage 3 Rt Stage 2

NASS - A-RACF e4 Stage 3 Ru Ru partially defined (NASS not defined in details)

RACS - Access Node Ra Stage 2 Rw?

Rn?

The mapping between this reference point and the ITU-T Rw and Rn reference points requires further studies.

Table 5: TISPAN Reference Points

RACF living list - Kobe, Japan, 22-27 April 2006.doc

Documents

Transcript of RACF living list - Kobe, Japan, 22-27 April 2006.doc