Internet DRAFT - draft-bertz-dime-diamimpr
draft-bertz-dime-diamimpr
Diameter Maintenance and Extensions L. Bertz
Internet-Draft Sprint
Intended status: Standards Track December 29, 2017
Expires: July 2, 2018
Diameter Specification Recommendations
draft-bertz-dime-diamimpr-01
Abstract
This document reports on formatting errors, uses cases, and
inconsistencies found in various standards specifications related to
the Diameter interface requirements. Recommendations are made to
reduce errors, support common use cases and build specifications in
such a way that programmatic verification of Diameter specifications
can be done with minimal to no errors.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 2, 2018.
Copyright Notice
Copyright (c) 2017 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
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Bertz Expires July 2, 2018 [Page 1]
Internet-Draft Diameter Specification Recommendations December 2017
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Survey of Existing Specifications . . . . . . . . . . . . . . 4
3.1. Summary of Challenges and Errors . . . . . . . . . . . . 6
3.2. Summary of Indirect Use Cases . . . . . . . . . . . . . . 7
3.2.1. Refinements . . . . . . . . . . . . . . . . . . . . . 7
3.2.2. Enumerations . . . . . . . . . . . . . . . . . . . . 8
3.3. Summary of Ingestion Barriers . . . . . . . . . . . . . . 8
4. Specification Survey . . . . . . . . . . . . . . . . . . . . 10
4.1. Survey Process . . . . . . . . . . . . . . . . . . . . . 10
4.2. Summary of Errors And Use Cases . . . . . . . . . . . . . 11
4.2.1. RFC 4004 . . . . . . . . . . . . . . . . . . . . . . 11
4.2.2. RFC 4006 bis (draft 03) . . . . . . . . . . . . . . . 11
4.2.3. RFC 4950 . . . . . . . . . . . . . . . . . . . . . . 12
4.2.4. RFC 5447 . . . . . . . . . . . . . . . . . . . . . . 12
4.2.5. RFC 5777 . . . . . . . . . . . . . . . . . . . . . . 12
4.2.6. RFC 5778 . . . . . . . . . . . . . . . . . . . . . . 13
4.2.7. Draft Diameter Load . . . . . . . . . . . . . . . . . 13
4.2.8. RFC 6733 . . . . . . . . . . . . . . . . . . . . . . 13
4.2.9. RFC 7155 . . . . . . . . . . . . . . . . . . . . . . 13
4.2.10. RFC 7683 . . . . . . . . . . . . . . . . . . . . . . 14
4.2.11. RFC 7944 . . . . . . . . . . . . . . . . . . . . . . 14
4.2.12. 3GPP TS 29.214 . . . . . . . . . . . . . . . . . . . 14
4.2.13. 3GPP TS 29.229 . . . . . . . . . . . . . . . . . . . 14
4.2.14. 3GPP TS 29.468 . . . . . . . . . . . . . . . . . . . 15
4.2.15. 3GPP TS 29.345 . . . . . . . . . . . . . . . . . . . 15
4.2.16. 3GPP TS 29.344 . . . . . . . . . . . . . . . . . . . 15
4.2.17. 3GPP TS 29.343 . . . . . . . . . . . . . . . . . . . 16
4.2.18. 3GPP TS 29.338 . . . . . . . . . . . . . . . . . . . 16
4.2.19. 3GPP TS 29.337 . . . . . . . . . . . . . . . . . . . 16
4.2.20. 3GPP TS 29.336 . . . . . . . . . . . . . . . . . . . 17
Bertz Expires July 2, 2018 [Page 2]
Internet-Draft Diameter Specification Recommendations December 2017
4.2.21. 3GPP TS 29.329 . . . . . . . . . . . . . . . . . . . 17
4.2.22. 3GPP TS 32.299 . . . . . . . . . . . . . . . . . . . 17
4.2.23. 3GPP TS 29.154 . . . . . . . . . . . . . . . . . . . 19
4.2.24. 3GPP TS 29.215 . . . . . . . . . . . . . . . . . . . 19
4.2.25. 3GPP TS 29.368 . . . . . . . . . . . . . . . . . . . 20
4.2.26. 3GPP TS 29.128 . . . . . . . . . . . . . . . . . . . 20
4.2.27. 3GPP TS 29.173 . . . . . . . . . . . . . . . . . . . 20
4.2.28. 3GPP TS 29.217 . . . . . . . . . . . . . . . . . . . 20
4.2.29. 3GPP TS 29.273 . . . . . . . . . . . . . . . . . . . 20
4.2.30. 3GPP TS 29.272 . . . . . . . . . . . . . . . . . . . 21
4.2.31. 3GPP TS 29.061 . . . . . . . . . . . . . . . . . . . 21
4.2.32. 3GPP TS 29.212 . . . . . . . . . . . . . . . . . . . 22
5. Recommendations for Specification Improvement and Automation 23
5.1. Error Reduction . . . . . . . . . . . . . . . . . . . . . 23
5.1.1. Defined AVPs . . . . . . . . . . . . . . . . . . . . 23
5.1.2. Imported AVPs . . . . . . . . . . . . . . . . . . . . 25
5.1.3. Grouped AVPs . . . . . . . . . . . . . . . . . . . . 25
5.1.4. Command Errors . . . . . . . . . . . . . . . . . . . 26
5.1.5. Enumeration Errors . . . . . . . . . . . . . . . . . 27
5.2. Formats for automated validation . . . . . . . . . . . . 27
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
7. Security Considerations . . . . . . . . . . . . . . . . . . . 29
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.1. Normative References . . . . . . . . . . . . . . . . . . 29
8.2. Informative References . . . . . . . . . . . . . . . . . 29
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction
This document identifies common errors and uses of Diameter in order
to document requirements and possible extensions to the Diameter
Command Code Format (CCF) and other formats, e.g. Grouped Attribute
Value Pair (AVP) format defined in [RFC6733]. It is by no means an
exhaustive analysis of all Diameter specifications but provides a
survey of a few dozen RFCs and 3GPP Technical Specifications to
determine what improvements can be made in Diameter specifications.
There are no issues with respect to over the wire communication of
Diameter as evidenced by the successful implementation of Diameter
applications based upon the specifications surveyed in this document.
However, the development and implementation time of Diameter
applications can be significantly improved when errors and
inconsistencies of the message format as documented in the
specifications are minimized or non-existent. An automated tool was
developed and used to perform the survey analysis of the technical
specifications. The tool would perform automated checking, syntax
validation, and language generation and was ran against the various
specifications to set a benchmark on the current state and quality of
Bertz Expires July 2, 2018 [Page 3]
Internet-Draft Diameter Specification Recommendations December 2017
the Diameter specifications. The '.dia' format of a fork of the
diafuzzer project (https://github.com/Orange-OpenSource/diafuzzer)
was used. It is a simple, deterministic format that provides
semantic cross checks of Diameter specifications.
With the goal of automated '.dia' format in mind a survey of various
Diameter related RFCs and 3GPP Technical Specifications was executed.
During the process several issues, errors, omissions and usage
patterns were discovered, and they are outlined in section 4
(Specification Survey) of this document.
Diameter Applications Design Guidelines [RFC7423] does an excellent
job of noting common diameter desing use cases but it does not
describe how the CCF or related grammers may represent some of these
scenarios. To do this the '.dia' format was extended. A few new use
cases were also identified that were not covered in [RFC7423].
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. Survey of Existing Specifications
The tool was ran against the following standards specifications for
diameter applications:
RFC 4004 [RFC4004]
RFC 4006 bis [I-D.bertz-dime-rfc4006bis]
RFC 4950 [RFC4950]
RFC 5447 [RFC5447]
RFC 5777 [RFC5777]
RFC 5778 [RFC5778]
Diameter Load (draft) [I-D.ietf-dime-load]
RFC 6733 [RFC6733]
RFC 7155 [RFC7155]
RFC 7683 [RFC7683]
Bertz Expires July 2, 2018 [Page 4]
Internet-Draft Diameter Specification Recommendations December 2017
RFC 7944 [RFC7944]
3GPP TS 29.214 [TGPP.29.214]
3GPP TS 29.345 [TGPP.29.345]
3GPP TS 29.344 [TGPP.29.344]
3GPP TS 29.343 [TGPP.29.343]
3GPP TS 29.338 [TGPP.29.338]
3GPP TS 29.337 [TGPP.29.337]
3GPP TS 29.336 [TGPP.29.336]
3GPP TS 29.329 [TGPP.29.329]
3GPP TS 32.299 [TGPP.32.299]
3GPP TS 29.154 [TGPP.29.154]
3GPP TS 29.215 [TGPP.29.215]
3GPP TS 29.368 [TGPP.29.368]
3GPP TS 29.128 [TGPP.29.128]
3GPP TS 29.173 [TGPP.29.173]
3GPP TS 29.217 [TGPP.29.217]
3GPP TS 29.273 [TGPP.29.273]
3GPP TS 29.272 [TGPP.29.272]
3GPP TS 29.061 [TGPP.29.061]
3GPP TS 29.212 [TGPP.29.212]
3GPP TS 32.299 [TGPP.32.299]
3GPP TS 29.229 [TGPP.29.229]
3GPP TS 29.468 [TGPP.29.468]
Bertz Expires July 2, 2018 [Page 5]
Internet-Draft Diameter Specification Recommendations December 2017
3.1. Summary of Challenges and Errors
Enumeration issues have their own section below. General issues
include but are not limited to:
Spelling and spacing errors.
Inconsistent Table formats over time. Arguably this reflects the
changes in Diameter but these inconsistencies occur with documents
released in close time frames. There are also too many formats to
claim it is a 'change over time' and not just an inconsistency
issue.
Missing AVPs and/or AVP Code values.
Case Sensitive inconsistencies.
The wrong name for AVPs in Tables, referenced across specs, etc.
that have the same AVP Code.
Claiming an AVP is defined in a spec when in fact it is
referenced.
Incorrect references.
Not noting an AVP is referenced at all but including it in a
Grouped AVP or Command.
Some AVPs mentioned in Grouped AVPs and not defined anywhere.
This happened a few times in accounting related 3GPP
specifications.
Enumerations do not have a specific format in the base specificaton
[RFC6733]. Over the wire the labels themselves are not used as the
value is transported in integer formats. When received by a Client
or Server the value is checked against a list of valid values. The
label only appears in displayed information for errors, logging, etc.
However, many of the specifications used varying case, spaces and
formats such as parenthesis around numbers, tables, numbers then
labels, labels then numbers, etc.
An algorithm keying off of the expression 'is of type Enumerated' was
used to figure out the text between enumerations. A function was
then used to attempt to parse various label patterns, generate a
label that may be acceptable to a coding language and capture the
value assigned to the label. This yielded partial success. In some
cases, especially billing in 3GPP, hand edits were required to fix
Bertz Expires July 2, 2018 [Page 6]
Internet-Draft Diameter Specification Recommendations December 2017
duplicate labels and formats that were inconsistent with the rest of
the document's enumerations.
A few cases even referenced their values as coming from other enums
or registries associated with the IETF or other standards
organizations. These were removed in some cases due to their size
while others were copied from the existing enumeration file in the
diafuzzer project if it had already been generated.
Although enumerations are now available in the intermediate '.dia'
format, many of the labels will not be valid in specific programming
languages. More work is required regarding enumerations to
accommodate these situations.
3.2. Summary of Indirect Use Cases
Several Use Cases appeared that where the dia format was extended to
capture them.
3.2.1. Refinements
Refinement (Extension) of Commands and Grouped AVPs. This is a case
where the same AVP/Command is referenced, i.e. same code or vendor/
code combination but the underlying members of the structure are
different. Two variants of this were found:
The base (original definition) of the structure was refined. In
this case, the 'Refines' Statement in the header may not include
the application.
A refinement of a refinement. In this case the specific
refinement (AVP + App ID it was specified in) was the part of the
refinement clause.
Note: this is not inheritance. In inheritance the children also
inherit the attributes (AVPs) of the parent. In many cases the new
definition removed some of the parents AVPs or further limited the
occurrence amount of the AVPs.
Refinements can only occur if the Command/Grouped AVP is extensible,
i.e. it includes *[AVP] in its definition.
The rationale for this can be shown by example. A value of 2[AVP]
would not be considered extensible and its behavior is undefined.
Can someone limit the number of AVPs present in a Command/Grouped AVP
when that value is less than the total sum of the upper bounds of all
member AVPs. For example, if a Grouped AVP permits at most 2
Bertz Expires July 2, 2018 [Page 7]
Internet-Draft Diameter Specification Recommendations December 2017
occurrences of AVP member "X" and 2 of AVP member "Y", how/why could/
would one limit the Grouped AVP to no more than 3 AVPs?
In the dia format Refinement is captured by adding 'Refines
[application id]' at the end of the header/Grouped AVP definition.
3.2.2. Enumerations
Enumeration use cases included definitions that referenced
other Enumerations
registries found on the web
In the second case the Enumeration was typically removed.
In a few cases Enumerations referenced other enumerations and then,
in Notes, limited the values (was a proper subset). The opposite
case (a proper superset) never presented itself.
Later specifications assigned Unsigned32 as a value in what appears
to be an attempt to avoid registries or provide some pseudo
extensibility. The exact purpose is actually unclear.
3.3. Summary of Ingestion Barriers
Errors, inconsistencies and Use Cases that could not be easily
fulfilled aside. Format differences hampered our ability to quickly
ingest Diameter strcutures from specifications. The following is a
list of patterns for just AVP header tables:
Pattern 1: Parses the original table format for AVPs defined in an
IETF spec.
The header for an RFC is
AVP Section | | |SHLD|MUST| |
Attribute Name Code Defined Data Type |MUST| MAY | NOT|NOT |Encr|
Pattern 2: Parses the original table format for AVPs defined in a
3GPP spec
Attribute Name|AVP Code|Section defined|Value Type|Must|May|Should -
not| Must not | May Encr. |
Pattern 3: Parses the original table format for AVPs defined for
freediameter is BUT some rows define a spec boundary
such as the row below the header in this example
Bertz Expires July 2, 2018 [Page 8]
Internet-Draft Diameter Specification Recommendations December 2017
|Attribute Name|Code|Section|Data|MUST|MAY|SHLD NOT|MUST NOT|Encr|
Pattern 4: Parses the original table format for AVPs defined in
later IETF specs.
The header for an RFC is
| | AVP | Section | | |MUST |
| Attribute Name | Code | Defined | Data Type |MUST| NOT |
An AVP can be 2-line
Accounting- 483 9.8.7 Enumerated | M | V |
Realtime-Required | | |
Pattern 5: Parses the original table format for AVPs defined in
some IETF specs like RFC 7155.
The header for an RFC is
| | Section | |MUST |
| Attribute Name | Defined |MUST| NOT |
Pattern 6: Parses the original table format for AVPs defined in some
IETF specs that don't define applications..
The header for an RFC is
| | AVP | Section | |
| Attribute Name | Code | Defined | Data Type |
Pattern 7: Parses the original table format for AVPs defined in
an IETF spec.
The header for an RFC is
AVP Section | |MUST|
Attribute Name Code Defined Data Type |MUST| NOT|
Pattern 8: Parses the original table format for AVPs defined in
later IETF specs.
The header for an RFC is
| | AVP | Section | | | MAY |MUST |
| Attribute Name | Code | Defined | Data Type |MUST| | NOT |
An AVP can be 2-line
Accounting- 483 9.8.7 Enumerated | M | V |
Realtime-Required | | |
Pattern 9: Parses the original table format for AVPs defined in a
3GPP spec
Attribute Name|AVP Code|Clause defined|Value Type|Must|May|Should -
Bertz Expires July 2, 2018 [Page 9]
Internet-Draft Diameter Specification Recommendations December 2017
not|Must not|
Pattern 10: Parses the original table format for AVPs defined in a
3GPP spec
Attribute Name|AVP Code|Value Type|Must|May|Should not|Must not|
Figure 1: Table Patterns
Even with the patterns present some cleanup for "Notes..." was
required to get the headers parsable.
Not all specifications used an import table. In fact some inter-
mixed the tables used to note AVPs defined in the spec and those that
were referenced. Some columns were removed to ensure that they fit
within known formats as well. In other words, there are more formats
in the specifications than shown here but with some manipulation they
can be reduced to this core set.
For AVP imports a 3-column and 4-column format were common. Further
they often had references that needed to be removed (an enhancement
is planned to overcome this in the test code.
Multiple application specific AVP tables that occurred in a single
spec and unified. This was for research convenience but will hamper
the generation of small dictionaries.
Command codes have a long name and three letter acronym typically in
a table. However, neither of those were used in the definition. For
example, it is quite common to see Re-Authorization-Request and RAR
but Re-Auth-Request in the command code definition.
There is no easy, programmatic way to identify an application and
relations to command codes or result codes.
4. Specification Survey
4.1. Survey Process
The current process for performing validation is to perform the
following tasks:
Separate AVP and AVP import tables. The primary goal of this was
to study the table formats to develop code to process them.
Bertz Expires July 2, 2018 [Page 10]
Internet-Draft Diameter Specification Recommendations December 2017
Save the file in a text format. This document is then modified to
correct the errors.
'Repair' enumerations as required through the use of a separate
enum file that is modified as issues are discovered.
Create a filter format file that captured data that was hard to
find in the specifcation related to Diameter Applications.
The time spent for each document is the total amount of time from
start to finish where the various files were split as described above
and the software was then ran. As errors were discovered they were
documented and then, as required, repaired. In some cases new
software was developed to accommodate new use cases or formats. That
was added to the total processing time for the document unless
otherwise noted.
4.2. Summary of Errors And Use Cases
4.2.1. RFC 4004
For RFC 4004 [RFC4004], processing took approximately 20 minutes.
Defect corrections were approximately an hour.
The AVP Table is a unique format. Line continuations of the table
are not consistent.
Enumerations are backwards - # Label
Some issues were noted but not resolved in 4004. See
https://www.ietf.org/mail-archive/web/dime/current/msg02053.html
Note that MIP-MN-FA-SPI, MIP-MN-HA-SPI and MIP-HA-to-MN-SPI are
missing in the specification. They were removed from their
respective Grouped AVPs.
MIP-Nonce is in the AVP definition but MIP-nonce (lowercase 'n'
for nonce) in Grouped definitions
4.2.2. RFC 4006 bis (draft 03)
For RFC 4006 bis [I-D.bertz-dime-rfc4006bis], processing took
approximately 25 minutes.
The AVP table contains inconsistent continuation lines.
No import tables have been provided and had to be constructed.
Bertz Expires July 2, 2018 [Page 11]
Internet-Draft Diameter Specification Recommendations December 2017
Had to change the User-Equipment-Info-Type AVP to the format of
'AVP (AVP Code XXX) is of type Enumerated' to keep the pattern to
one type.
Had to stub in TBD values.
Misspelling of IPFiltrRule in table.
Many enums referenced to registry values in the spec.
Section 8.6 removes dashes for Check Balance Result
Redirect-Address-Type Enumerations have spacing so appear as
duplicates.
CC-Session-Failover was phrased as 'is type of Enumerated' instead
of 'is of type Enumerated'
4.2.3. RFC 4950
For RFC 4950 [RFC4950], processing took approximately 15 minutes. No
major issues were found.
4.2.4. RFC 5447
For RFC 5447 [RFC5447], processing took approximately 10 minutes. No
major issues were found.
4.2.5. RFC 5777
For RFC 5777 [RFC5777], processing took approximately 3 hours.
A unique AVP table format.
Had to hand enter ALL Enum formats.
The approach taken for enum processing is not correct for this
document.
Treatment-Action listed as Grouped in AVP table
IP-Bit-Mask-Width not present in table
4.1.7.7 and table are inconsistent with AVP definition used in
groups 'IP-Bit-Mask-Width' vs. 'IP-Mask-Bit-Mask-Width'
Filter-Rule's use of ';' for comment is unconventional in parsing
Bertz Expires July 2, 2018 [Page 12]
Internet-Draft Diameter Specification Recommendations December 2017
4.2.6. RFC 5778
For RFC 5778 [RFC5778], processing took 24 minutes.
Continuations in AVP tables are inconsistent which required hand
editing. The continuation '-' sometimes appears on the first line
or not until the second which will require more complex code to
deal with the situation.
Imports of AVPs were mixed in with the table definitions
specification. This took the most time work out.
Subtype field of the MN-HA and MN-AAA authentication mobility
options are not defined in spec and needed to be stitched in
(corrected) later.
Although noted properly in text, MIP-Session-Key, MIP-Algorithm-
Type, MIP-Replay-Mode was not listed as being imported from an RFC
in the AVP table.
4.2.7. Draft Diameter Load
For Diameter Load [I-D.ietf-dime-load], processing completed by hand
in 10 minutes. IANA allocations have occurred but the document has
not left editors queue which means scripts would not work anyway
4.2.8. RFC 6733
For RFC 6733 [RFC6733], processing took approximately 15 minutes.
Continuations were inconsistent.
The spec does not follow its own CCF.
4.2.9. RFC 7155
For RFC 7155 [RFC7155], processing took several hours. The original
RFC was used to fill in many of the gaps in the AVP table code.
AVPs only used for compatibility are in the messages but not
mentioned in the document, e.g. NAS-Identifier is still present.
RA-XXX to Re-Auth but Command acronyms, names and custom names are
inter-mixed which is a bit confusing and makes it problematic to
automate.
Hand stitched the enum values which often pointed to entire
registries
Bertz Expires July 2, 2018 [Page 13]
Internet-Draft Diameter Specification Recommendations December 2017
4.2.10. RFC 7683
For RFC 7683 [RFC7683], processing took approximately 40 minutes.
The AVP table has a unique format.
Continuations were on the second line requiring look ahead logic.
4.2.11. RFC 7944
For RFC 7944 [RFC7944], processing took approximately 10 minutes. No
major issues were found.
4.2.12. 3GPP TS 29.214
For TS 29.214 [TGPP.29.214], processing took approximately 45
minutes.
In the AVP tables a dot is used as a separator instead of a comma.
In the Specific-Action AVP, the Label 'Void' occurs twice. A hand
modification was made.
The Service-Info-Status AVP has spaces between the names in the
labels. This was corrected.
4.2.13. 3GPP TS 29.229
For TS 29.229 [TGPP.29.229], processing this took 2 hours; 20
minutes.
Many AVPs are listed as being DEFINED in the specification but
they are references.
It does not import RFC 4005, 7155 or 4006 despite using their
AVPs.
Although restored in Dec 2011 in a change request, Wildcarded-IMPU
was not added back to the AVP table Table 6.3.1: Diameter
Multimedia Application AVPs
Line-Identifier also does not appear in the Table and this AVP has
Vendor Id ETSI (13019)
Bertz Expires July 2, 2018 [Page 14]
Internet-Draft Diameter Specification Recommendations December 2017
4.2.14. 3GPP TS 29.468
For TS 29.468 [TGPP.29.468], processing took approximately 60 minutes
Another AVP Table format.
The Commands were abbreviated in a manner not seen elsewhere in
the document, e.g. GA-Request is only used in the command
definition.
AVP Definitions table removes dashes of the Grouped AVPs.
Duplicate AVP names with different codes for MBMS-GW-SSM-IP-
Address and MBMS-GW-SSM-Ipv6-Address.
TMGI-Number in the Grouped AVP but it is defined in the table as
TMGINumber.
4.2.15. 3GPP TS 29.345
For TS 29.345 [TGPP.29.345], processing took approximately 70 minutes
AVP Table inter-mixes '.' and ',' separation in the flags fields.
Code was finally written to overcome this.
In the AVP Table, App-Identifier was typed as 'Group' and not
'Grouped'.
In the AVP Table, 'Assistance-info' was incorrect case for 'Info'.
Section 6.3.31, WiFi-P2P-Assistance-Iinfo has an extra 'i' in it
User-Identity's, ProSe-Response-Code's and ProSe-Query-Code's
origin are unclear. They is not in a reference section but in
several groups.
Discovery-Auth-Request and Match-Report-Info use incorrect case -
ProSe-App-ID.
ProSe-Query-Code and ProSe-Response-Code are noted in Grouped AVPs
but do not exist elsewhere in the spec.
4.2.16. 3GPP TS 29.344
For TS 29.344 [TGPP.29.344], processing took approximately 50 minutes
ProSe-Subscriber-Information-Request is the name for ProSe-
Initial-Location-Information-Request.
Bertz Expires July 2, 2018 [Page 15]
Internet-Draft Diameter Specification Recommendations December 2017
Authorized-Discovery-Range was not listed as a defined AVP and has
no values assigned. Filled in as 3708 but these sections are not
present in 29.230 at all
4.2.17. 3GPP TS 29.343
For TS 29.343 [TGPP.29.343], processing took approximately 10 minutes
No issues.
4.2.18. 3GPP TS 29.338
For TS 29.338 [TGPP.29.338], processing took approximately 55 minutes
Table 6.3.2.2/1: Command-Code values for SGd/Gdd has spaces in the
command names.
Send-Routing-info-for-SM-Answer in the command definition is
lowercase and can't be linked to the command table.
Not an issue but an observation. There is no Load Control draft
reference.
SGSN-Absent-User-Diagnostic SM has a space in it in the AVP table
SM-Delivery- Failure-Cause has spacing issue in table.
SMSMI-Correlation-ID has dash issues in its definition..
SM-Delivery-Not-Intended has values as a list with ending of ','
and period. Similar issues for SM-RP-MTI
MME-SM-Delivery-Outcome- There is an extra > at the end of the
header definition
SM-Enumerated-Delivery-Failure-Cause used ',' and '.' for the
list. Also the data type 'Enumerated' was not capitalized causing
a miss in the system.
MSISDN import is from 29.329 and not 23.329
4.2.19. 3GPP TS 29.337
For TS 29.337 [TGPP.29.337], processing took approximately 20 minutes
No issues.
Bertz Expires July 2, 2018 [Page 16]
Internet-Draft Diameter Specification Recommendations December 2017
4.2.20. 3GPP TS 29.336
For TS 29.336 [TGPP.29.336], processing took approximately 9 hours as
it was used for testing.
Spacing issues in AVP tables for Maximum Latency, Maximum Response
Time
Scheduled-communication-time definition is lower case.
Periodic-Time is lowercase in the AVP Table.
Found a '/' in the Flags portion of the AVP Table.
eNodeB-ID and Extended-eNodeB-ID in this spec but 'Id' in defining
spec .217
4.2.21. 3GPP TS 29.329
For TS 29.329 [TGPP.29.329], processing took approximately a billion
minutes
Spacing issues in AVP User-Data-Request command.
Does not specify the Supported-Features, Feature-List, Feature-
List-ID, Supported-Applications, Server-Name, Public-Identity from
another app in the AVP table.
4.2.22. 3GPP TS 32.299
For TS 32.399 [TGPP.32.299], processing took approximately 9 hours
Unique Table format.
Required to remove imported AVPs and create a new table.
UTF8string case incorrect in AVP table for a number of entries.
ProSe-Direct-Communication- Transmission-Data-Container and
Status- AS-Code have spaces.
LCS-Client-ID changed to LCS-Client-Id.
ProSe-Direct-Communication- Transmission-Data-Container
Related- Change-Condition- Information
Trunk-Group-ID was Trunk-Group-Id in AVP table.
Bertz Expires July 2, 2018 [Page 17]
Internet-Draft Diameter Specification Recommendations December 2017
Wrote more software to deal with the values flipped in enums (int
first then label)
Enums were a large issue so hand editing had to take place to
clean up the values.
'is of type of Enumerated' and 'is of type enumerated' were
present in the document
AoC-Service-Type had to be repaired by hand as the algorithm
picked up the overloaded Change-Condition values
MBMS-User-Service-Type
Node-Functionality needs fixing
Online-Charging-Flag had to be corrected
Originator had missing elements
Void numbers get caught in enums
PoC-Event-Type used semicolons
ProSe-Direst-Discovery-Mode spelling issue
ProSe- Role-Of-UE spacing issue
Participant-Access-Priority uses colons in enum labels and mixed
descriptions
Changed Type-Number Unsigned32 as the registry is too difficult to
code
Submission-Timestamp not defined
PoC-User-Role-Ids instead of PoC-User-Role-IDs
Removed [ Monitored-HPLMN-Identifier ] as it made no sense and was
not defined
[ Prose-Function-PLMN-Identifier ] removed
[ VASP-Id ] & [ VAS-Id ] removed from MMS-Information
Service-Generic-Information removed from Service-Information
defined in OMA-DDS-Charging_Data [223].
Bertz Expires July 2, 2018 [Page 18]
Internet-Draft Diameter Specification Recommendations December 2017
[ 3GPP-Session-Stop-Indicator ] removed
IM-Information DCD-Information removed from Service-Information
defined in OMA-DDS-Charging_Data [223]
ePDG-Address vs EPDG-Address
M2M-Information removed from Service-Information as it was missing
SM-Device-Trigger-Information's Reference-Number removed since it
was missing
Incoming-Trunk-Group-ID removed
4.2.23. 3GPP TS 29.154
For TS 29.154 [TGPP.29.154], processing took approximately 10 minutes
Variance of a later Table format.
Command Codes were abbreviated in such a way that they had to be
changed so the software could match them up properly
Time-window grouped AVP definition corrected to Time-Window
4.2.24. 3GPP TS 29.215
For TS 29.215 [TGPP.29.215], processing took approximately 60 minutes
S9a* reference table has a TS reference instead of 3GPP TS.
UE-Local-IPv6-Prefix type in AVP table is all lower case.
Note that ' is of type of Enumerated" was corrected to allow the
software to catch the Subsession-Operation and DRA-Binding.
Imports are missing.
Change Framed-Ipv6-Prefix to Framed-IPv6-Prefix.
Logical-Access-ID to Logical-Access-Id
Physical-Access-ID to Physical-Access-Id
Bertz Expires July 2, 2018 [Page 19]
Internet-Draft Diameter Specification Recommendations December 2017
4.2.25. 3GPP TS 29.368
For TS 29.368 [TGPP.29.368], processing took approximately 20 minutes
TS used in imported AVP tables.
Command Codes were abbreviated in such a way that they had to be
changed so the software could match them up properly.
'Feature-Supported-In-Final-Target AVP' in the AVP definitions
table.
External-Id used instead of External-Identifier.
4.2.26. 3GPP TS 29.128
For TS 29.128 [TGPP.29.128], processing took approximately 30 minutes
Result Codes were not found
DRMP definitions are not handled.
Non-IP-Data had type of OctetString
4.2.27. 3GPP TS 29.173
For TS 29.173 [TGPP.29.173], processing took approximately 25 minutes
4.2.28. 3GPP TS 29.217
Processing took approximately 43 minutes.
The Modify-Uecontext-Request / Answer command definitions did not
match anything in the Command Table.
4.2.29. 3GPP TS 29.273
For TS 29.273 [TGPP.29.273], processing took 60 minutes.
The AN-Trusted enum wasn't picked up by the code.
Transport-Acess-Type - misspelling resulting in loss in the
document.
Case issue - Subscription-ID vs Subscription-Id
MIP6-Feature-Vector shows as 64 bit in the document but 32 in RFC
5447.
Bertz Expires July 2, 2018 [Page 20]
Internet-Draft Diameter Specification Recommendations December 2017
4.2.30. 3GPP TS 29.272
For TS 29.272 [TGPP.29.272], processing took approximately 3 hours.
Multiple issues were found but this document was used as a reference
for development and not considered in processing efficiencies
calculations.
Table 7.3.1/1: S6a/S6d, S7a/S7d and S13/S13' specific Diameter
AVPs Alert-Reason has type of 'Enumerate'
ProSe-Subscription-Data Grouped AVP has a type ID of 'xxx'
Supported-Services AVP has a type of 'zzzz'
'Subscriber Status' AVP needs a dash
'Notification- To-UE-User' has a space.
'IDR- Flags' has a space.
'Monitoring Event Report' has multiple spaces.
'eNodeB-ID' and 'Extended-eNodeB-ID' in this spec but 'Id' in
defining spec .217
Claims QoS-Capability as a defined AVP but it is part of RFC 5777
Trace-Depth is an enum in 32.422 and had to be manually added.
Job-Type reference vague. From the specification, 'The possible
values are those defined in 3GPP TS 32.422 [23] for Job-Type.'
'Report Interval' has a space.
Preferred-Data-Mode was listed as a Grouped type but is
Unsigned32.
4.2.31. 3GPP TS 29.061
For TS 29.2061 [TGPP.29.061], processing took approximately 2 hours.
Enums use 'AVP code' vs. 'AVP Code'
3 AVP tables created for 4 of the apps
Enums have to be added by hand as they are not tied by application
ID
Bertz Expires July 2, 2018 [Page 21]
Internet-Draft Diameter Specification Recommendations December 2017
Messages did not have App IDs in the CCF headers as they are
extensions
MBMS-Session-Repetition-Number has 'M.V' ('.' instead of comma)
MBMS-User-Data-Mode-Indication Enumeration uses spaces for its
label values
3BPP-PDP-Type - Enum defined as RADIUS; not available to parser in
Diameter
4.2.32. 3GPP TS 29.212
For TS 29.212 [TGPP.29.212], processing took approximately 7 hours.
Logical-Access-ID and Physical-Access-ID have case inconsistencies
with other specifications.
Acronyms in the command code lines but they do not correlate to
previously described acronyms in the document.
Table 5c.6.1.1 is incomplete.
Periods, '.', were used as separators in AVP tables, e.g.'M.V'.
Sd and St use TS-Request and TS-Answer but they are don't have
application assigned codes.
'Enumerated' appears in a type definition
Incorrect reference of 7863 vs 7683
Manual correction was required in the document. Somehow PCC-Rule-
Status did not got the enums it needed. It appears no spacing
created an error. Hopefully software can be updated to overcome
this.
Pre-emption Vulnerability (in the Section's first line) spacing
kills the correct name identification.
In many Enumerations there is an extra space between 'of type' and
'Enumerated'
PCC-Rule-Status has a label of 'TEMPORARILY INACTIVE'
Bearer-Control-Mode 'is of type of Enumerated' issue
Network-Request-Support Label spaces
Bertz Expires July 2, 2018 [Page 22]
Internet-Draft Diameter Specification Recommendations December 2017
For the Default-Access AVP - 'The values defined in the Default-
Access AVP are the same as the ones defined in IP-CAN-Type AVP.'
Also, mentions '3GPP-EPS IP-CAN' as an option but it is not an
option in the referenced type.
CS-Service-QoS-Request-Operation 'is type of Enumerated,
CS-Service-Resource-Failure-Cause AVP (AVP code2814) has a spacing
issue
'Logical-Access-ID to 'Logical-Access-Id'
CS-Service-QoS-Request-Identifier is in table as CS-Service-Qos-
Request-Identifier
Some enumerations with duplicate labels, e.g. Specific-Action
5. Recommendations for Specification Improvement and Automation
5.1. Error Reduction
The overall recommendations are as follows:
The name of all AVPs, Commands and Grouped AVPs appear
consistently throughout the document.
The letter case MUST be consistent for all names.
No spaces should appear in the names.
Use of underscores is discouraged except for line continuations in
tables.
5.1.1. Defined AVPs
This section addresses AVPs defined in the specification. The
following recommendations are made:
Tables MUST include the following columns:
Attribute Name
AVP Code
Section Defined
Data Type
Bertz Expires July 2, 2018 [Page 23]
Internet-Draft Diameter Specification Recommendations December 2017
AVP Flag Rules for MUST and MUST NOT
Tables MAY include Notes and other notations in the column headers
but MUST NOT exceed more than 8 lines of text to describe the
header.
The columns may be separated by space, '|' or both when in text
format that follows one of the following styles.
All columns except AVP Flags are separated by whitespace and
Flag column boundaries are pipe delimited.
Pipe delimited columns with the exception of the first column.
AVP Names MUST NOT have spaces or underscores.
Use '.' or ',' as Flag separators. Although no space is also
acceptable.
Use of two lines for an AVP is permitted. The following
conditions apply.
An underscore MUST be used at the end of the first line or at
the beginning of the second (not both).
An underscore is not a part of the AVP name
All other columns except the Name MUST appear on the same line.
All Defined AVP Tables in the specification MUST use the same
header format.
Imported or Re-used AVPs MUST NOT be present in defined AVP
tables.
Bertz Expires July 2, 2018 [Page 24]
Internet-Draft Diameter Specification Recommendations December 2017
Example One
AVP Section | |MUST |
Attribute Name Code Defined Data Type |MUST| NOT |
-----------------------------------------|----+-----|
AVP-Name 85 9.8.2 Unsigned32 | M | V |
Example Two
| AVP | Section | | |MUST |
Attribute Name | Code | Defined | Data Type |MUST| NOT |
---------------|------+---------+------------+----+-----|
AVP-Name | 85 | 9.8.2 | Unsigned32 | M | V |
Figure 2: Accepted Table Patterns
An open question exists when multiple AVPs tables are present and
associated with a specific application within the specification. How
the application can be associated to the table is an open question.
5.1.2. Imported AVPs
Imported or Re-used AVPs MUST be included in the specification. A
table MUST be present if AVPs are re-used/imported.
The table MUST include the AVP and Source document columns.
The table MAY include a Comment column.
An M-bit column MAY be present as required.
The table MUST be pipe delimited when in text format.
5.1.3. Grouped AVPs
When a Grouped AVP is refined a Refine keyword is appended to the end
of the header. It MUST include an application identifier of the
Grouped AVP it refines if that application was not the original
specification or 'version' of the Grouped AVP. When the Grouped AVP
refines the original definition of the Gropued AVP it SHOULD include
the referenced application identifier.
The refined Grouped AVP MUST be included in the AVP Import table and
NOT in the defined AVPs table.
Open question, should the vendor and application identifiers of the
application that created be in the Grouped AVP header?
Bertz Expires July 2, 2018 [Page 25]
Internet-Draft Diameter Specification Recommendations December 2017
When refining a Grouped AVP the following conditions apply:
The original AVP MUST be extensible, i.e. it MUST have the
'*[AVP]' member.
Any refinement of an AVP present in the refined Group MUST adhere
to the restrictions, if any, that were defined by inherited
Groups. For example, if a Grouped AVP refines an attribute 'Foo'
to the range X*Y and 'Foo'x is defined in the original AVP with a
range of A*B then X >= A and Y <= B.
AVPs retained without further restriction of the number of
occurrences MUST be kept in the Refining AVP's definition
otherwise they are assumed to be dropped from the new AVP
definition. Otherwise, it is impossible to determine the Author's
intent.
Open question, can a Grouped AVP have a range limited [AVP] member,
e.g. *5[AVP]?
Figure Figure 3 shows an example refinement. In it all but the User-
Name AVP are dropped in the new definition.
From TS 29.336
User-Identifier ::= <AVP-Header: 3102, 10415>
[User-Name]
[MSISDN]
[External-Identifier]
[LMSI]
*[AVP]
From TS 29.128
User-Identifier ::= <AVP-Header: 3102, 10415, Refines>
[User-Name]
*[AVP]
Figure 3: Refined AVP from TS 29.128 and TS 29.336
5.1.4. Command Errors
The largest issue with Commands is the inconsistent values between
the name, three letter acronym defined in the table and the actual
name used in the command definition. Maintaining consistency will
resolve this issue.
Like Grouped AVP refinement, a Refine keyword is appended to the end
of the header. It MUST include an application identifier of the
Command it refines if that application was not the original
Bertz Expires July 2, 2018 [Page 26]
Internet-Draft Diameter Specification Recommendations December 2017
specification or 'version' of the Command. When the Command refines
the original definition of the Command it SHOULD include its
application identifier.
When refining a Command the following conditions apply:
The original Command MUST be extensible, i.e. it MUST have the
'*[AVP]' member.
Any refinement of an AVP present in the refined Command MUST
adhere to the restrictions, if any, that were defined by inherited
Commands. For example, if a Command refines an attribute 'Foo' to
the range X*Y and 'Foo' is defined in the original Command with a
range of A*B then X >= A and Y <= B.
Commands retained without further restriction of the number of
occurrences MUST be kept in the Refining Command's definition
otherwise they are assumed to be dropped from the new Commands
definition. Otherwise, it is impossible to determine the Author's
intent.
5.1.5. Enumeration Errors
Enumeration Value Names MUST adhere to alphanumeric and underscore
characters.
Enumeration Value Names MUST not begin with an underscore.
When being defined the format MUST include the label and the value
assigned with the label enclosed in parenthesis on a single.
Otherwise, this will confusion when the label values end in integers
and are close to the numeric value. For example, 'speed_10 10' is
okay, 'speed_1010' is a error. This can be avoided by requiring the
enclosure of the values in parenthesis, e.g. 'speed_10 (10)' and
'speed_10(10)'. The last example may not be as readable as desired
but it can be understood.
5.2. Formats for automated validation
This section discusses ways by which further clarity can be defined
in a specification and automated validation can occur for a diameter
application.
Following the recommendations in the previous section will reduce
errors but there are still many pieces of information that cannot be
programmatically validated. This includes the following:
GAP 1: The application identifier and name of an application.
Bertz Expires July 2, 2018 [Page 27]
Internet-Draft Diameter Specification Recommendations December 2017
GAP 2: The application and vendor identifiers associated with a
defined AVP table.
GAP 3: The application and vendor identifiers associated with
Commands.
GAP 4: Reused and newly defined result codes for an application.
GAP 5: Easily parsed enumerations that cover all use cases.
The following formats show an example of how information could be
added to an Appendix to close these gaps.
1: AppFoo ::= <Diameter Application: 10415 101010>
2: Command1-Name-Request C1R
3: Command1-Name-Answer C1A
4:
5: Result-Codes ::= <Diameter Result-Codes: 101010>
6: NEW_RESULT (4999)
7: IMPORTED_RESULT IMPORT (4010)
Figure 4: Example Application and Result Code Formats
GAP 1 is closed in line 1. GAP 3 is closed in lines 1 through 3
while GAP 4 is closed by lines 5 through 7.
GAP 2 can be closed by using a common discernable Table Name format,
e.g. AppFoo defined AVPs. In this case the Application Name can be
looked up and associated to the defined AVP table.
Gap 5 can be partially closed by following a pattern similar to
Result-Codes but this does not resolve all uses cases.
Result-Codes ::= <Diameter Enumeration: 123, 45678>
Label_1 (0)
LABEL_Two (2)
Figure 5: Example Enumeration AVP
Further work is required to comprehensively cover all Enumeration Use
Cases.
6. IANA Considerations
Bertz Expires July 2, 2018 [Page 28]
Internet-Draft Diameter Specification Recommendations December 2017
7. Security Considerations
This document is informational and provides some guidance on issues
related to formatting and possible extensions of the Diameter CCF to
improve understanding and code generation capabilities. It has no
impact to the Security of Diameter or Diameter applications.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
Ed., "Diameter Base Protocol", RFC 6733,
DOI 10.17487/RFC6733, October 2012,
<https://www.rfc-editor.org/info/rfc6733>.
8.2. Informative References
[I-D.bertz-dime-rfc4006bis]
Bertz, L., Dolson, D., ylifshitz@sandvine.com, y., Hakala,
H., Mattila, L., Koskinen, J., Stura, M., and J. Loughney,
"Diameter Credit-Control Application", draft-bertz-dime-
rfc4006bis-01 (work in progress), July 2016.
[I-D.ietf-dime-load]
Campbell, B., Donovan, S., and J. Trottin, "Diameter Load
Information Conveyance", draft-ietf-dime-load-09 (work in
progress), March 2017.
[RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., Ed.,
and P. McCann, "Diameter Mobile IPv4 Application",
RFC 4004, DOI 10.17487/RFC4004, August 2005,
<https://www.rfc-editor.org/info/rfc4004>.
[RFC4950] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "ICMP
Extensions for Multiprotocol Label Switching", RFC 4950,
DOI 10.17487/RFC4950, August 2007,
<https://www.rfc-editor.org/info/rfc4950>.
Bertz Expires July 2, 2018 [Page 29]
Internet-Draft Diameter Specification Recommendations December 2017
[RFC5447] Korhonen, J., Ed., Bournelle, J., Tschofenig, H., Perkins,
C., and K. Chowdhury, "Diameter Mobile IPv6: Support for
Network Access Server to Diameter Server Interaction",
RFC 5447, DOI 10.17487/RFC5447, February 2009,
<https://www.rfc-editor.org/info/rfc5447>.
[RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M.,
Ed., and A. Lior, "Traffic Classification and Quality of
Service (QoS) Attributes for Diameter", RFC 5777,
DOI 10.17487/RFC5777, February 2010,
<https://www.rfc-editor.org/info/rfc5777>.
[RFC5778] Korhonen, J., Ed., Tschofenig, H., Bournelle, J.,
Giaretta, G., and M. Nakhjiri, "Diameter Mobile IPv6:
Support for Home Agent to Diameter Server Interaction",
RFC 5778, DOI 10.17487/RFC5778, February 2010,
<https://www.rfc-editor.org/info/rfc5778>.
[RFC7155] Zorn, G., Ed., "Diameter Network Access Server
Application", RFC 7155, DOI 10.17487/RFC7155, April 2014,
<https://www.rfc-editor.org/info/rfc7155>.
[RFC7423] Morand, L., Ed., Fajardo, V., and H. Tschofenig, "Diameter
Applications Design Guidelines", BCP 193, RFC 7423,
DOI 10.17487/RFC7423, November 2014,
<https://www.rfc-editor.org/info/rfc7423>.
[RFC7683] Korhonen, J., Ed., Donovan, S., Ed., Campbell, B., and L.
Morand, "Diameter Overload Indication Conveyance",
RFC 7683, DOI 10.17487/RFC7683, October 2015,
<https://www.rfc-editor.org/info/rfc7683>.
[RFC7944] Donovan, S., "Diameter Routing Message Priority",
RFC 7944, DOI 10.17487/RFC7944, August 2016,
<https://www.rfc-editor.org/info/rfc7944>.
[TGPP.29.061]
3GPP, "Policy and Charging Control (PCC); Reference
points", 3GPP TS 29.061 14.3.0, March 2017.
[TGPP.29.128]
3GPP, "Mobility Management Entity (MME) and Serving GPRS
Support Node (SGSN) interfaces for interworking with
packet data networks and applications", 3GPP TS 29.128
14.2.0, March 2017.
Bertz Expires July 2, 2018 [Page 30]
Internet-Draft Diameter Specification Recommendations December 2017
[TGPP.29.154]
3GPP, "Service capability exposure functionality over Nt
reference point", 3GPP TS 29.154 14.1.0, March 2017.
[TGPP.29.173]
3GPP, "Location Services (LCS); Diameter-based SLh
interface for Control Plane LCS", 3GPP TS 29.173 14.0.0,
March 2017.
[TGPP.29.212]
3GPP, "Policy and Charging Control (PCC); Reference
points", 3GPP TS 29.212 14.3.0, March 2017.
[TGPP.29.214]
3GPP, "Policy and charging control over Rx reference
point", 3GPP TS 29.214 14.3.0, March 2017.
[TGPP.29.215]
3GPP, "Policy and Charging Control (PCC) over S9 reference
point; Stage 3", 3GPP TS 29.215 14.1.0, March 2017.
[TGPP.29.217]
3GPP, "Policy and Charging Control (PCC); Congestion
reporting over Np reference point", 3GPP TS 29.217 14.1.0,
March 2017.
[TGPP.29.229]
3GPP, "Cx and Dx interfaces based on the Diameter
protocol; Protocol details", 3GPP TS 29.229 14.1.0, March
2017.
[TGPP.29.272]
3GPP, "Evolved Packet System (EPS); Mobility Management
Entity (MME) and Serving GPRS Support Node (SGSN) related
interfaces based on Diameter protocol", 3GPP TS 29.272
14.3.0, March 2017.
[TGPP.29.273]
3GPP, "Evolved Packet System (EPS); 3GPP EPS AAA
interfaces", 3GPP TS 29.273 14.2.0, March 2017.
[TGPP.29.329]
3GPP, "Sh interface based on the Diameter protocol;
Protocol details", 3GPP TS 29.329 14.2.0, March 2017.
Bertz Expires July 2, 2018 [Page 31]
Internet-Draft Diameter Specification Recommendations December 2017
[TGPP.29.336]
3GPP, "Home Subscriber Server (HSS) diameter interfaces
for interworking with packet data networks and
applications", 3GPP TS 29.336 14.1.0, March 2017.
[TGPP.29.337]
3GPP, "Diameter-based T4 Interface for communications with
packet data networks and applications", 3GPP TS 29.337
14.0.0, March 2017.
[TGPP.29.338]
3GPP, "Diameter based protocols to support Short Message
Service (SMS) capable Mobile Management Entities (MMEs)",
3GPP TS 29.338 14.1.0, March 2017.
[TGPP.29.343]
3GPP, "Proximity-services (ProSe) function to ProSe
application server aspects (PC2); Stage 3", 3GPP TS 29.343
14.1.0, March 2017.
[TGPP.29.344]
3GPP, "Proximity-services (ProSe) function to Home
Subscriber Server (HSS) aspects; Stage 3", 3GPP TS 29.344
14.1.0, March 2017.
[TGPP.29.345]
3GPP, "Inter-Proximity-services (Prose) function
signalling aspects; Stage 3", 3GPP TS 29.345 14.1.0, March
2017.
[TGPP.29.368]
3GPP, "Tsp interface protocol between the MTC Interworking
Function (MTC-IWF) and Service Capability Server (SCS)",
3GPP TS 29.368 14.1.0, March 2017.
[TGPP.29.468]
3GPP, "Group Communication System Enablers for LTE
(GCSE_LTE); MB2 reference point; Stage 3", 3GPP TS 29.468
14.1.0, March 2017.
[TGPP.32.299]
3GPP, "Telecommunication management; Charging management;
Diameter charging applications", 3GPP TS 32.299 14.3.0,
March 2017.
Bertz Expires July 2, 2018 [Page 32]
Internet-Draft Diameter Specification Recommendations December 2017
Author's Address
Lyle Bertz
Sprint
6220 Sprint Parkway
Overland Park, KS 66251
United States
Email: lylebe551144@gmail.com
Bertz Expires July 2, 2018 [Page 33]
