RFC 5431

Diameter ITU-T Rw Policy Enforcement Interface Application

πŸ“… published March 2009, from ietf

RFC 5431: Diameter ITU-T Rw Policy Enforcement Interface Application ✨

Network Working Group πŸŽ€ Request for Comments: 5431 Author: D. Sun, who is Dong Sun at Alcatel-Lucent πŸ’… Category: Informational 🌸 Date: March 2009 πŸ“… Obsoletes: Nothing listed in the header πŸ™ˆ Updates: Nothing listed in the header πŸ™ˆ


Status of This Memo

okay so this memo is just giving information to the Internet community 🧚 It does not specify an Internet standard of any kind, so it's not a protocol spec you're required to follow. Distribution of this memo is unlimited, so share the tea πŸ“

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. πŸ’œ

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. πŸ“œ

Abstract

okay bestie, so this doc is about needing a brand new pair of IANA Diameter Command Codes πŸ”₯ They're for a vendor-specific new application, the ITU-T Rec. Q.3303.3 Rw interface. That interface sends a request and gets a response for authorizing network Quality of Service (QoS) resources and policy enforcement in a network element. It's one of the recommendations from the International Telecommunication Union - Telecommunication Standardization Sector (ITU-T) πŸ‘‘

Table of Contents

1. Introduction ....................................................2
2. Terminology .....................................................2
3. Diameter ITU-T Rw Policy Enforcement Interface ..................3
4. IANA Considerations .............................................3
   4.1. Application Identifier .....................................3
   4.2. Command Codes ..............................................4
   4.3. AVP Codes ..................................................4
5. Security Considerations .........................................4
6. Acknowledgements ................................................4
7. References ......................................................5
   7.1. Normative References .......................................5
   7.2. Informative References .....................................5

1. Introduction ✨

so this doc sums up how Diameter codes get used in a newly defined version of a spec for authorizing network QoS resources and policy enforcement [Q.3303.3] πŸ’– IANA assigned a new pair of Command Codes for it. The doc goes over the new Diameter codes (Command Codes, AVPs, and the vendor-specific application id). When you combine it with the Diameter Base protocol, this application's spec [Q.3303.3] meets the requirements of [Y.2111] from the ITU-T. That means it can send a request and receive a response for controlling policy enforcement πŸ¦‹

The Diameter version of this app assumes you're using the Diameter Base protocol, as per RFC 3588. It extends that base only for this specific application. It uses a vendor-id (ITU-T), a vendor-specific application ID (16777256), a new Command Code (315), and new attribute-value pairs (AVPs), which all live in the vendor-specific namespace πŸŽ€

This application is used to authorize network QoS resources and policy enforcement, including the amount of bandwidth, the QoS class, and traffic flow processing. It's an extension of the Diameter application [RFC4006] πŸ’… The approach comes from the Diameter extensibility talks in the DIME WG. Those talks concluded that it's better to define new Command Codes whenever the ABNF of a command changes by adding, removing, or semantically changing a required AVP, so you avoid interoperability problems 🫢 The doc uses authorization and accounting functionality, and the whole exchange is about users running apps that need QoS treatment. This matches the practice and experience gained since [RFC3588] came out (see for example [RFC5224]). That base spec is now being revised by the DIME Working Group, who will provide a revised set of recommendations and procedures for IANA considerations [DIME] 🌈

2. Terminology ⭐

In the base Diameter spec [RFC3588], Section 1.4 defines most of the terminology used in this document. On top of that, the terms and acronyms defined in Section 3 and Section 4 of [Q.3303.3] are used here too πŸ“š

3. Diameter ITU-T Rw Policy Enforcement Interface πŸ¦‹

the Rw interface is for exchanging information to apply policy decisions between the Policy Decision Point (PDP, which in ITU-T terms is the Policy Decision Functional Entity (PD-FE)) and the Policy Enforcement Point (PEP, which in ITU-T terms is the Policy Enforcement Functional Entity (PE-FE)) πŸ’–

The interface lets the PDP push the authorized admission decisions down to the PEP. It also lets the PEP ask the PDP to authorize admission decisions when path-coupled resource reservation mechanisms are in use πŸ”₯ The main info the Rw interface carries is:

  • Resource reservation and/or allocation requests for media flows πŸŽ€
  • QoS handling requests, such as packet marking and policing πŸ’…
  • Gate control (opening/closing) requests for a media flow πŸšͺ
  • NAPT and NAT traversal requests for the necessary address mapping information πŸ—ΊοΈ
  • Resource usage information requests and reports for media flows πŸ“Š

The detailed descriptions of the Diameter Policy Enforcement interface ITU-T Rw can be found in Section 5 of [Q.3303.3] 🧚

4. IANA Considerations πŸ‘‘

This section gives guidance to the Internet Assigned Numbers Authority (IANA) about registering values related to the Diameter protocol, following BCP 26 [RFC5226] 🌸

This document defines values in the namespaces created and defined in [RFC3588]. The IANA Considerations section of that document details the assignment criteria. Values assigned in this document, or by future IANA action, must be coordinated within this shared namespace. bestie, this is a big one 😭

4.1. Application Identifier πŸ“

A vendor-specific application ID (16777256) for the application of [Q.3303.3] has been assigned by IANA ✨

Registry:
ID values            Name          Reference
----------------------------------------------------------
16777256           ITU-T Rw       7.2.1 of ITU-T Q.3303.3

4.2. Command Codes πŸ¦‹

IANA has allocated Command Code values for the following commands. They're defined in Section 7.4 of [Q.3303.3], and they come from the Command Code namespace defined in [RFC3588] πŸ’œ

Registry:
Code Value     Name                        Reference
------------------------------------------------------------------
315            Policy-Install-Request(PIR) 7.4.1 of ITU-T Q.3303.3
315            Policy-Install-Answer (PIA) 7.4.2 of ITU-T Q.3303.3

4.3. AVP Codes πŸŽ€

The values 1010~1018 are assigned by the ITU-T to the following AVPs inside the ITU-T vendor-ID 11502 namespace: PI-Request-Type AVP, PI-Request-Number AVP, Traffic-Descriptor-UL AVP, Traffic-Descriptor-DL AVP, Maximum-Burst-Size AVP, Committed-Data-Rate AVP, Committed-Burst-Size AVP, Excess-Burst-Size, Removal-Cause AVP 🌈

See Table 1/Q.3303.3 in Section 7.3.1 of [Q.3303.3] for detailed info on AVP codes, value types, and flag rules 🫢

5. Security Considerations πŸ’€

⚠️ Security note, don't skip this one! ⚠️

This document describes the Diameter Policy Enforcement Application. It builds on top of the Diameter Base protocol, and the same security considerations described in [RFC3588] apply to this document. No further extensions are required beyond the security mechanisms offered by [RFC3588] πŸ”

6. Acknowledgements 🫢

The author would like to thank Dan Romascanu, Hannes Tschofenig, and Tina Tsou for their help and support πŸ’– Finally, the author would like to thank Alcatel-Lucent, since most of the effort put into this document was done while he was in their employ πŸ‘‘

7. References πŸ“š

7.1. Normative References πŸ”₯

[Q.3303.3] ITU-T Recommendation Q.3303.3, "Resource control protocol no. 3 (rcp3): Protocol at the Rw interface between the Policy Decision Physical Entity (PD-PE) and the Policy Enforcement Physical Entity (PE-PE): Diameter", 2008.

[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.

7.2. Informative References 🌸

[DIME] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, "Diameter Base Protocol", Work in Progress, November 2008.

[RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. Loughney, "Diameter Credit-Control Application", RFC 4006, August 2005.

[RFC5224] Brenner, M., "Diameter Policy Processing Application", RFC 5224, March 2008.

[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

[Y.2111] ITU-T Recommedation Y.2111, "Resource and admission control functions in Next Generation Networks", September 2006.

Author's Address 🧚

Dong Sun Alcatel-Lucent 600 Mountain Ave Murray Hill, NJ 07974 USA

Phone: +1 908 582 2617 EMail: dongsun@alcatel-lucent.com


That's the whole RFC, bestie! You're literally a networking legend now πŸŒˆπŸ‘‘πŸ’–

πŸ“¦ where this page comes from