1<?xml version="1.0" encoding="utf-8" ?> 2<!DOCTYPE fileref SYSTEM "fileref.dtd" [ 3 <!ENTITY format 4 '<seealso marker="#FILE_FORMAT">FILE FORMAT</seealso>'> 5 <!ENTITY records 6 '<seealso marker="#MESSAGE_RECORDS">MESSAGE RECORDS</seealso>'> 7 <!ENTITY types 8 '<seealso marker="#DATA_TYPES">DATA TYPES</seealso>'> 9 <!ENTITY % also SYSTEM "seealso.ent" > 10 <!ENTITY % here SYSTEM "seehere.ent" > 11 %also; 12 %here; 13]> 14 15<fileref> 16<header> 17 18<copyright> 19<year>2011</year> 20<year>2017</year> 21<holder>Ericsson AB. All Rights Reserved.</holder> 22</copyright> 23<legalnotice> 24Licensed under the Apache License, Version 2.0 (the "License"); 25you may not use this file except in compliance with the License. 26You may obtain a copy of the License at 27 28 http://www.apache.org/licenses/LICENSE-2.0 29 30Unless required by applicable law or agreed to in writing, software 31distributed under the License is distributed on an "AS IS" BASIS, 32WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 33See the License for the specific language governing permissions and 34limitations under the License. 35 36</legalnotice> 37 38<title>diameter_dict(4)</title> 39<prepared>Anders Svensson</prepared> 40<responsible></responsible> 41<docno></docno> 42<approved></approved> 43<checked></checked> 44<date></date> 45<rev>%VSN%</rev> 46<file>diameter_dict.xml</file> 47</header> 48 49<!-- ===================================================================== --> 50 51<file>diameter_dict</file> 52<filesummary>Dictionary interface of the diameter application.</filesummary> 53 54<description> 55<p> 56A diameter service, as configured with &mod_start_service;, 57specifies one or more supported Diameter applications. 58Each Diameter application specifies a dictionary module that knows how 59to encode and decode its messages and AVPs. 60The dictionary module is in turn generated from a file that defines 61these messages and AVPs. 62The format of such a file is defined in &format; below. 63Users add support for their specific applications by creating 64dictionary files, compiling them to Erlang modules using 65either &man_compile; or &man_make; and configuring the 66resulting dictionaries modules on a service.</p> 67 68<p> 69Dictionary module generation also results in a hrl file that defines 70records for the messages and Grouped AVPs defined by the 71dictionary, these records being what a user of the diameter 72application sends and receives, modulo other possible formats as 73discussed in &man_app;. 74These records and the underlying Erlang data types corresponding to 75Diameter data formats are discussed in &records; and &types; 76respectively. 77The generated hrl also contains macro definitions for the possible values of 78AVPs of type Enumerated.</p> 79 80<p> 81The diameter application includes five dictionary modules 82corresponding to applications defined in section 2.4 of &the_rfc;: 83<c>diameter_gen_base_rfc3588</c> and <c>diameter_gen_base_rfc6733</c> 84for the Diameter Common Messages application with application 85identifier 0, 86<c>diameter_gen_accounting</c> (for RFC 3588) and 87<c>diameter_gen_acct_rfc6733</c> for the Diameter Base Accounting 88application with application identifier 3 and 89<c>diameter_gen_relay</c> the Relay application with application 90identifier 0xFFFFFFFF.</p> 91 92<p> 93The Common Message and Relay applications are the only applications 94that diameter itself has any specific knowledge of. 95The Common Message application is used for messages that diameter 96itself handles: CER/CEA, DWR/DWA and DPR/DPA. 97The Relay application is given special treatment with regard to 98encode/decode since the messages and AVPs it handles are not specifically 99defined.</p> 100 101<marker id="FILE_FORMAT"/> 102</description> 103 104<!-- ===================================================================== --> 105 106<section> 107<title>FILE FORMAT</title> 108 109<p> 110A dictionary file consists of distinct sections. 111Each section starts with a tag followed by zero or more arguments 112and ends at the the start of the next section or end of file. 113Tags consist of an ampersand character followed by a keyword and are 114separated from their arguments by whitespace. 115Whitespace separates individual tokens but is otherwise insignificant.</p> 116 117<p> 118The tags, their arguments and the contents of each corresponding 119section are as follows. 120Each section can occur multiple times unless otherwise specified. 121The order in which sections are specified is unimportant.</p> 122 123<taglist> 124 125<tag> 126<marker id="id"/><c>@id Number</c></tag> 127<item> 128<p> 129Defines the integer Number as the Diameter Application Id of the 130application in question. 131Can occur at most once and is required if the dictionary defines 132<c>@messages</c>. 133The section has empty content.</p> 134 135<p> 136The Application Id is set in the Diameter Header of outgoing messages 137of the application, and the value in the header of an incoming message 138is used to identify the relevant dictionary module.</p> 139 140<p> 141Example:</p> 142 143<pre> 144@id 16777231 145</pre> 146 147</item> 148 149<tag> 150<marker id="name"/><c>@name Mod</c></tag> 151<item> 152<p> 153Defines the name of the generated dictionary module. 154Can occur at most once and defaults to the name of the dictionary file 155minus any extension. 156The section has empty content.</p> 157 158<p> 159Note that a dictionary module should have a unique name so as not collide 160with existing modules in the system.</p> 161 162<p> 163Example:</p> 164 165<pre> 166@name etsi_e2 167</pre> 168 169</item> 170 171<tag> 172<marker id="prefix"/><c>@prefix Name</c></tag> 173<item> 174<p> 175Defines Name as the prefix to be added to record and constant names 176(followed by a <c>'_'</c> character) in the generated dictionary 177module and hrl. 178Can occur at most once. 179The section has empty content.</p> 180 181<p> 182A prefix is optional but can be be used to disambiguate between record 183and constant names resulting from similarly named messages and AVPs in 184different Diameter applications.</p> 185 186<p> 187Example:</p> 188 189<pre> 190@prefix etsi_e2 191</pre> 192 193</item> 194 195<tag> 196<marker id="vendor"/><c>@vendor Number Name</c></tag> 197<item> 198<p> 199Defines the integer Number as the the default Vendor-Id of AVPs for 200which the V flag is set. 201Name documents the owner of the application 202but is otherwise unused. 203Can occur at most once and is required if an AVP sets the V flag and 204is not otherwise assigned a Vendor-Id. 205The section has empty content.</p> 206 207<p> 208Example:</p> 209 210<pre> 211@vendor 13019 ETSI 212</pre> 213 214</item> 215 216<tag> 217<marker id="avp_vendor_id"/><c>@avp_vendor_id Number</c></tag> 218<item> 219<p> 220Defines the integer Number as the Vendor-Id of the AVPs listed in the 221section content, overriding the <c>@vendor</c> default. 222The section content consists of AVP names.</p> 223 224<p> 225Example:</p> 226 227<pre> 228@avp_vendor_id 2937 229 230WWW-Auth 231Domain-Index 232Region-Set 233</pre> 234 235</item> 236 237<tag> 238<marker id="inherits"/><c>@inherits Mod</c></tag> 239<item> 240<p> 241Defines the name of a dictionary module containing AVP 242definitions that should be imported into the current dictionary. 243The section content consists of the names of those AVPs whose 244definitions should be imported from the dictionary, an empty list 245causing all to be imported. 246Any listed AVPs must not be defined in the current dictionary and 247it is an error to inherit the same AVP from more than one 248dictionary.</p> 249 250<p> 251Note that an inherited AVP that sets the V flag takes its Vendor-Id 252from either <c>@avp_vendor_id</c> in the inheriting dictionary or 253<c>@vendor</c> in the inherited dictionary. 254In particular, <c>@avp_vendor_id</c> in the inherited dictionary is 255ignored. 256Inheriting from a dictionary that specifies the required <c>@vendor</c> 257is equivalent to using <c>@avp_vendor_id</c> with a copy of the 258dictionary's definitions but the former makes for easier reuse.</p> 259 260<p> 261All dictionaries should typically inherit &the_rfc; AVPs from 262<c>diameter_gen_base_rfc6733</c>.</p> 263 264<p> 265Example:</p> 266 267<pre> 268@inherits diameter_gen_base_rfc6733 269</pre> 270</item> 271 272<tag> 273<marker id="avp_types"/><c>@avp_types</c></tag> 274<item> 275<p> 276Defines the name, code, type and flags of individual AVPs. 277The section consists of definitions of the form</p> 278 279<p><c>Name Code Type Flags</c></p> 280 281<p> 282where Code is the integer AVP code, Type identifies an AVP Data Format 283as defined in section &types; below, 284and Flags is a string of V, M and P characters indicating the flags to be 285set on an outgoing AVP or a single <c>'-'</c> (minus) character if 286none are to be set.</p> 287 288<p> 289Example:</p> 290 291<pre> 292@avp_types 293 294Location-Information 350 Grouped MV 295Requested-Information 353 Enumerated V 296</pre> 297 298<warning> 299<p> 300The P flag has been deprecated by &the_rfc;.</p> 301</warning> 302 303</item> 304 305<tag> 306<marker id="custom_types"/><c>@custom_types Mod</c></tag> 307<item> 308<p> 309Specifies AVPs for which module Mod provides encode/decode functions. 310The section contents consists of AVP names. 311For each such name, <c>Mod:Name(encode|decode, Type, Data, Opts)</c> is 312expected to provide encode/decode for values of the AVP, where Name is 313the name of the AVP, Type is it's type as declared in the 314<c>@avp_types</c> section of the dictionary, Data is the value to 315encode/decode, and Opts is a term that is passed through encode/decode.</p> 316 317<p> 318Example:</p> 319 320<pre> 321@custom_types rfc4005_avps 322 323Framed-IP-Address 324</pre> 325</item> 326 327<tag> 328<marker id="codecs"/><c>@codecs Mod</c></tag> 329<item> 330<p> 331Like <c>@custom_types</c> but requires the specified module to export 332<c>Mod:Type(encode|decode, Name, Data, Opts)</c> rather than 333<c>Mod:Name(encode|decode, Type, Data, Opts)</c>.</p> 334 335<p> 336Example:</p> 337 338<pre> 339@codecs rfc4005_avps 340 341Framed-IP-Address 342</pre> 343</item> 344 345<tag> 346<marker id="messages"/><c>@messages</c></tag> 347<item> 348<p> 349Defines the messages of the application. 350The section content consists of definitions of the form specified in 351section 3.2 of &the_rfc;, "Command Code Format Specification".</p> 352 353<!-- RFC 4740 RTR/RTA --> 354<pre> 355@messages 356 357RTR ::= < Diameter Header: 287, REQ, PXY > 358 < Session-Id > 359 { Auth-Application-Id } 360 { Auth-Session-State } 361 { Origin-Host } 362 { Origin-Realm } 363 { Destination-Host } 364 { SIP-Deregistration-Reason } 365 [ Destination-Realm ] 366 [ User-Name ] 367 * [ SIP-AOR ] 368 * [ Proxy-Info ] 369 * [ Route-Record ] 370 * [ AVP ] 371 372RTA ::= < Diameter Header: 287, PXY > 373 < Session-Id > 374 { Auth-Application-Id } 375 { Result-Code } 376 { Auth-Session-State } 377 { Origin-Host } 378 { Origin-Realm } 379 [ Authorization-Lifetime ] 380 [ Auth-Grace-Period ] 381 [ Redirect-Host ] 382 [ Redirect-Host-Usage ] 383 [ Redirect-Max-Cache-Time ] 384 * [ Proxy-Info ] 385 * [ Route-Record ] 386 * [ AVP ] 387</pre> 388 389</item> 390 391<tag> 392<marker id="grouped"/><c>@grouped</c></tag> 393<item> 394<p> 395Defines the contents of the AVPs of the application having type 396Grouped. 397The section content consists of definitions of the form specified in 398section 4.4 of &the_rfc;, "Grouped AVP Values".</p> 399 400<p> 401Example:</p> 402 403<pre> 404@grouped 405 406SIP-Deregistration-Reason ::= < AVP Header: 383 > 407 { SIP-Reason-Code } 408 [ SIP-Reason-Info ] 409 * [ AVP ] 410</pre> 411 412<p> 413Specifying a Vendor-Id in the definition of a grouped AVP is 414equivalent to specifying it with <c>@avp_vendor_id</c>.</p> 415</item> 416 417<tag> 418<marker id="enum"/><c>@enum Name</c></tag> 419<item> 420<p> 421Defines values of AVP Name having type Enumerated. 422Section content consists of names and corresponding integer values. 423Integer values can be prefixed with 0x to be interpreted as 424hexadecimal.</p> 425 426<p> 427Note that the AVP in question can be defined in an inherited 428dictionary in order to introduce additional values to an enumeration 429otherwise defined in another dictionary.</p> 430 431<p> 432Example:</p> 433 434<pre> 435@enum SIP-Reason-Code 436 437PERMANENT_TERMINATION 0 438NEW_SIP_SERVER_ASSIGNED 1 439SIP_SERVER_CHANGE 2 440REMOVE_SIP_SERVER 3 441</pre> 442</item> 443 444<tag> 445<marker id="end"/><c>@end</c></tag> 446<item> 447<p> 448Causes parsing of the dictionary to terminate: 449any remaining content is ignored.</p> 450</item> 451 452</taglist> 453 454<p> 455Comments can be included in a dictionary file using semicolon: 456characters from a semicolon to end of line are ignored.</p> 457 458<marker id="MESSAGE_RECORDS"/> 459</section> 460 461<!-- ===================================================================== --> 462 463<section> 464<title>MESSAGE RECORDS</title> 465 466<p> 467The hrl generated from a dictionary specification defines records for the 468messages and grouped AVPs defined in <c>@messages</c> and 469<c>@grouped</c> sections. 470For each message or grouped AVP definition, a record is defined whose 471name is the message or AVP name, prefixed with any dictionary prefix 472defined with <c>@prefix</c>, and whose fields are the names of the AVPs 473contained in the message or grouped AVP in the order specified in the 474definition in question. 475For example, the grouped AVP</p> 476 477<pre> 478SIP-Deregistration-Reason ::= < AVP Header: 383 > 479 { SIP-Reason-Code } 480 [ SIP-Reason-Info ] 481 * [ AVP ] 482</pre> 483 484<p> 485will result in the following record definition given an empty 486prefix.</p> 487 488<pre> 489-record('SIP-Deregistration-Reason', {'SIP-Reason-Code', 490 'SIP-Reason-Info', 491 'AVP'}). 492</pre> 493 494<p> 495The values encoded in the fields of generated records depends on the 496type and number of times the AVP can occur. 497In particular, an AVP which is specified as occurring exactly once is 498encoded as a value of the AVP's type while an AVP with any other 499specification is encoded as a list of values of the AVP's type. 500The AVP's type is as specified in the AVP definition, the &the_rfc; 501types being described below.</p> 502 503<marker id="DATA_TYPES"/> 504</section> 505 506<!-- ===================================================================== --> 507 508<section> 509<title>DATA TYPES</title> 510 511<p> 512The data formats defined in sections 4.2 ("Basic AVP Data 513Formats") and 4.3 ("Derived AVP Data Formats") of &the_rfc; are encoded 514as values of the types defined here. 515Values are passed to &mod_call; 516in a request record when sending a request, returned in a resulting 517answer record and passed to a &app_handle_request; 518callback upon reception of an incoming request.</p> 519 520<p> 521In cases in which there is a choice between string() and binary() types 522for OctetString() and derived types, the representation is determined 523by the value of &mod_string_decode;.</p> 524 525<p> 526<em>Basic AVP Data Formats</em></p> 527 528<marker id="OctetString"/> 529<marker id="Integer32"/> 530<marker id="Integer64"/> 531<marker id="Unsigned32"/> 532<marker id="Unsigned64"/> 533<marker id="Float32"/> 534<marker id="Float64"/> 535<marker id="Grouped"/> 536 537<pre> 538OctetString() = string() | binary() 539Integer32() = -2147483647..2147483647 540Integer64() = -9223372036854775807..9223372036854775807 541Unsigned32() = 0..4294967295 542Unsigned64() = 0..18446744073709551615 543Float32() = '-infinity' | float() | infinity 544Float64() = '-infinity' | float() | infinity 545Grouped() = record() 546</pre> 547 548<p> 549On encode, an OctetString() can be specified as an iolist(), 550excessively large floats (in absolute value) are equivalent to 551<c>infinity</c> or <c>'-infinity'</c> and excessively large integers 552result in encode failure. 553The records for grouped AVPs are as discussed in the previous 554section.</p> 555 556<p> 557<em>Derived AVP Data Formats</em></p> 558 559<marker id="Address"/> 560<pre> 561Address() = OctetString() 562 | tuple() 563</pre> 564 565<p> 566On encode, an OctetString() IPv4 address is parsed in the usual 567x.x.x.x format while an IPv6 address is parsed in any of the formats 568specified by section 2.2 of RFC 2373, "Text Representation of 569Addresses". 570An IPv4 tuple() has length 4 and contains values of type 0..255. 571An IPv6 tuple() has length 8 and contains values of type 0..65535. 572The tuple representation is used on decode.</p> 573 574<marker id="Time"/> 575<pre> 576Time() = {date(), time()} 577 578where 579 580 date() = {Year, Month, Day} 581 time() = {Hour, Minute, Second} 582 583 Year = integer() 584 Month = 1..12 585 Day = 1..31 586 Hour = 0..23 587 Minute = 0..59 588 Second = 0..59 589</pre> 590 591<p> 592Additionally, values that can be encoded are 593limited by way of their encoding as four octets as required by 594&the_rfc; with the required extension from RFC 2030. 595In particular, only values between <c>{{1968,1,20},{3,14,8}}</c> 596and <c>{{2104,2,26},{9,42,23}}</c> (both inclusive) can be encoded.</p> 597 598<marker id="UTF8String"/> 599<pre> 600UTF8String() = [integer()] | binary() 601</pre> 602 603<p> 604List elements are the UTF-8 encodings of the individual characters 605in the string. 606Invalid codepoints will result in encode/decode failure. 607On encode, a UTF8String() can be specified as a binary, or as a nested 608list of binaries and codepoints.</p> 609 610<marker id="DiameterIdentity"/> 611<pre> 612DiameterIdentity() = OctetString() 613</pre> 614 615<p> 616A value must have length at least 1.</p> 617 618<marker id="DiameterURI"/> 619<pre> 620DiameterURI() = OctetString() 621 | #diameter_URI{type = Type, 622 fqdn = FQDN, 623 port = Port, 624 transport = Transport, 625 protocol = Protocol} 626 627where 628 629 Type = aaa | aaas 630 FQDN = OctetString() 631 Port = integer() 632 Transport = sctp | tcp 633 Protocol = diameter | radius | 'tacacs+' 634</pre> 635 636<p> 637On encode, fields port, transport and protocol default to 3868, sctp 638and diameter respectively. 639The grammar of an OctetString-valued DiameterURI() is as specified in 640section 4.3 of &the_rfc;. 641The record representation is used on decode.</p> 642 643<marker id="Enumerated"/> 644<pre> 645Enumerated() = Integer32() 646</pre> 647 648<p> 649On encode, values can be specified using the macros defined in a 650dictionary's hrl file.</p> 651 652<marker id="IPFilterRule"/> 653<marker id="QoSFilterRule"/> 654<pre> 655IPFilterRule() = OctetString() 656QoSFilterRule() = OctetString() 657</pre> 658 659<p> 660Values of these types are not currently parsed by diameter.</p> 661 662</section> 663 664<!-- ===================================================================== --> 665<!-- ===================================================================== --> 666 667<section> 668<title>SEE ALSO</title> 669 670<p> 671&man_compile;, &man_main;, &man_app;, &man_codec;, &man_make;</p> 672 673</section> 674 675</fileref> 676