idnits 2.17.1 draft-taylor-ipdc-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: 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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 78 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 833 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** The abstract seems to contain references ([3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 147: '... mandate, IPDC MAY be used to contro...' RFC 2119 keyword, line 167: '...not complete and MUST be used with one...' RFC 2119 keyword, line 176: '... MUST This word, or the adjec...' RFC 2119 keyword, line 179: '... MUST NOT This phrase means that ...' RFC 2119 keyword, line 182: '... SHOULD This word, or the adjecti...' (195 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 15 has weird spacing: '...ment is an I...' == Line 16 has weird spacing: '...cuments of t...' == Line 17 has weird spacing: '...ups may also ...' == Line 21 has weird spacing: '... and may be...' == Line 22 has weird spacing: '...me. It is i...' == (828 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '10' is defined on line 3302, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 3317, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-greene-ss7-arch-frame-00 -- Possible downref: Normative reference to a draft: ref. '1' == Outdated reference: A later version (-18) exists of draft-calhoun-diameter-04 -- Possible downref: Normative reference to a draft: ref. '2' -- No information found for draft-skran-IPDC-frame - is the name correct? -- Possible downref: Normative reference to a draft: ref. '3' -- No information found for draft-dugan-IPDC-conn - is the name correct? -- Possible downref: Normative reference to a draft: ref. '4' -- No information found for draft-elliott-IPDC-media - is the name correct? -- Possible downref: Normative reference to a draft: ref. '5' -- No information found for draft-bell-IPDC-sig - is the name correct? -- Possible downref: Normative reference to a draft: ref. '6' -- No information found for draft-pickett-IPDC-mgmt - is the name correct? -- Possible downref: Normative reference to a draft: ref. '7' ** Obsolete normative reference: RFC 1700 (ref. '8') (Obsoleted by RFC 3232) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '9') -- Possible downref: Non-RFC (?) normative reference: ref. '10' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '11') == Outdated reference: A later version (-12) exists of draft-ietf-roamops-nai-11 ** Obsolete normative reference: RFC 2313 (ref. '13') (Obsoleted by RFC 2437) ** Obsolete normative reference: RFC 2138 (ref. '14') (Obsoleted by RFC 2865) -- No information found for draft-calhoun-DIAMETER-framework - is the name correct? -- Possible downref: Normative reference to a draft: ref. '15' Summary: 17 errors (**), 0 flaws (~~), 14 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT P. Tom Taylor 3 Nortel (Northern Telecom) 4 Title: draft-taylor-ipdc-00.txt Pat R. Calhoun 5 Date: July 1998 Sun Microsystems, Inc. 6 Allan C. Rubens 7 Ascend Communications 9 IPDC 10 Base Protocol 11 13 Status of this Memo 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as ``work in progress.'' 25 To learn the current status of any Internet-Draft, please check the 26 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 27 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 28 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 29 ftp.isi.edu (US West Coast). 31 Abstract 33 The protocol described in this document provides the basis for the IP 34 Device Control (IPDC) family of protocols. The IPDC protocols are 35 proposed as a protocol suite, components of which can be used 36 individually or together to perform connection control, media 37 control, and signaling transport for environments where the service 38 control logic is separated from the network access server. Please see 39 the references section for other IPDC documents. 41 According to the framework provided by Cuervo et al [1], the IPDC 42 protocol suite operates between the Media Gateway Controller and the 43 Media Gateway. In terms of previous contributions to the experts of 44 Questions 13-14/16, the corresponding entities are the Call Control 45 and Media Control portions of the H.323 Gateway. The operation of 46 IPDC in the service of H.323 is clarified in a companion contribution 47 entitled "IPDC Architectural Framework" [3]. 49 Table of Contents 51 1.0 Introduction 52 1.1 Definitions 53 1.2 Terminology 54 2.0 Transport 55 2.1 Protocol Overview 56 3.0 Message Format 57 3.1 Transaction Identification 58 4.0 AVP Format 59 5.0 AVP Definitions 60 5.1 Command AVP 61 5.1.1 DIAMETER Base Commands 62 5.1.1.1 Command-Unrecognized-Ind 63 5.1.1.2 Device-Reboot-Ind 64 5.1.1.3 Device-Watchdog-Ind 65 5.1.1.4 Device-Feature-Query 66 5.1.1.5 Device-Feature-Reply 67 5.1.1.6 Device-Config-Req 68 5.1.1.7 Device-Config-Answer 69 5.1.2 Additional IPDC Commands 70 5.1.2.1 Command-Ack 71 5.1.2.2 Message-Reject 72 5.2 Other AVPs 73 5.2.1 DIAMETER Base AVPs 74 5.2.1.1 Host-IP-Address 75 5.2.1.2 Host-Name 76 5.2.1.3 Version-Number 77 5.2.1.4 Extension-Id 78 5.2.1.5 Integrity-Check-Vector 79 5.2.1.6 Digital-Signature 80 5.2.1.7 Initialization-Vector 81 5.2.1.8 Timestamp 82 5.2.1.9 Session-Id 83 5.2.1.10 X509-Certificate 84 5.2.1.11 X509-Certificate-URL 85 5.2.1.12 Vendor-Name 86 5.2.1.13 Firmware-Revision 87 5.2.1.14 Result-Code 88 5.2.1.15 Error-Code 89 5.2.1.16 Unknown-Command-Code 90 5.2.1.17 Reboot-Type 91 5.2.1.18 Reboot-Timer 92 5.2.1.19 Message-Timer 93 5.2.1.20 Message-In-Progress-Timer 94 5.2.1.21 Message-Retry-Count 95 5.2.1.22 Message-Forward-Count 96 5.2.1.23 Receive-Window 97 5.2.2 Additional IPDC AVPs 98 5.2.2.1 Transaction-Originator 99 5.2.2.2 Failed-AVP-Code 100 5.3 IPDC AVP Templates 101 5.3.1 IPDC Reference 102 6.0 Protocol Definition 103 6.1 Bootstrap Message 104 6.2 Keepalive Exchange 105 6.3 Unrecognized Command Support 106 6.4 The art of AVP Tagging 107 6.5 Device Configuration 108 6.6 Data Integrity 109 6.6.1 Using the Integrity-Check-Vector 110 6.6.2 Using Digital Signatures 111 6.6.3 Using Mixed Data Integrity AVPs 112 6.7 AVP Data Encryption 113 6.7.1 AVP Encryption with Shared Secrets 114 6.7.2 AVP Encryption with Public Keys 115 6.8 Public Key Cryptography Support 116 6.8.1 X509-Certificate 117 6.8.2 X509-Certificate-URL 118 6.8.3 Static Public Key Configuration 119 7.0 References 120 8.0 Rights and Permissions 121 9.0 Acknowledgements 122 10.0 Authors' Addresses 123 Appendix A: Acknowledgement Timeouts 124 Appendix B: Examples Of Sequence Numbering 126 1.0 Introduction 128 A need has been identified for one or more protocols to control 129 gateway devices which sit at the boundary between the circuit- 130 switched telephone network and the internet and terminate circuit- 131 switched trunks. Examples of such devices include network access 132 servers and voice-over-IP gateways. The need for a control protocol 133 separate from call signalling arises when the service control logic 134 needed to process calls lies partly or wholly outside the gateway 135 devices. 137 Cuervo et al [1] and Skran [3] describe the architectural context 138 within which the gateway control protocols must operate. Using the 139 terminology established by [1], the protocols implement the interface 140 between the Media Gateway Controller and the Media Gateway. The 141 present document along with documents listed in the references [4], 142 [5], [6], and [7] describe the IP Device Control (IPDC) protocol 143 suite, which is proposed for that purpose. 145 Note that IPDC views the Media Gateway as an application which may 146 control one or more physical devices. In addition to its primary 147 mandate, IPDC MAY be used to control devices which do not meet the 148 strict definition of Media Gateway such as digital cross-connects and 149 announcement servers. 151 IPDC builds on the base already provided by DIAMETER [2]. DIAMETER 152 has a number of advantages as a starting point: 153 * built-in provision for control security 154 * facilities for starting up the control relation 155 * ready extensibility both in modular increments and at the atomic 156 (individual command and attribute) level. 158 Because DIAMETER is specifically written for the AAA (authentication, 159 authorization, accounting) application, the authors of the IPDC 160 proposal have chosen to use DIAMETER 's syntactical framework rather 161 than DIAMETER itself. The present document looks very much like the 162 current DIAMETER Base document [2], but various changes to suit the 163 IPDC application environment have created a protocol which is 164 interoperable with but not identical with DIAMETER. 166 This document describes the base IPDC protocol. This document in 167 itself is not complete and MUST be used with one or more accompanying 168 task-specific extension documents such as those provided by [4], [5], 169 [6], and [7]. 171 1.1 Definitions 173 In this document, several words are used to signify the requirements 174 of the specification. These words are often capitalized. 176 MUST This word, or the adjective "required", means that the 177 definition is an absolute requirement of the specification. 179 MUST NOT This phrase means that the definition is an absolute 180 prohibition of the specification. 182 SHOULD This word, or the adjective "recommended", means that there 183 may exist valid reasons in particular circumstances to ignore this 184 item, but the full implications must be understood and carefully 185 weighed before choosing a different course. 187 MAY This word, or the adjective "optional", means that this 188 item is one of an allowed set of alternatives. An implementation 189 which does not include this option MUST be prepared to interoperate 190 with another implementation which does include the option. 192 1.2 Terminology 194 AVP 195 The IPDC protocol consists of a message header followed by 196 Attribute-Value-Pairs (AVPs). An AVP is a data object 197 encapsulated in a header. 199 Command 200 An IPDC command is a specialized data object which indicates the 201 purpose and structure of the message containing it. Because of 202 this identification between command type and message format, the 203 command name may be used denote the message format, as, for 204 example, "IPDC-Alive Message". 206 DIAMETER Device 207 A Diameter device is a client or server system that supports the 208 Diameter Base protocol and 0 or more extensions. 210 Integrity Check Vector 211 An Integrity Check Vector is a hash of the packet with a shared 212 secret. 214 IPDC Entity 215 An IPDC entity is any object, logical or physical, which is 216 subject to control through IPDC or whose status IPDC must report. 217 Every IPDC entity has a type. The complete list of IPDC entity 218 types is provided as part of the definition of the IPDC Reference 219 AVP template in section 5.3.1. 221 IPDC Protocol Endpoint 222 The term IPDC protocol endpoint is used to refer to either of the 223 two parties to an IPDC control session: the Media Gateway 224 Controller or the Media Gateway. To the extent that IPDC may be 225 viewed as providing extensions to DIAMETER, an IPDC protocol 226 endpoint is also a Diameter device. 228 Transaction 229 A transaction is sequence of messages pre-defined as part of the 230 definition of the IPDC commands which constitute that sequence. 231 Every message in the sequence carries the same Identifier value in 232 the header and same Transaction-Originator value identifying the 233 originator of the transaction, as described in Section 3.1. 235 2.0 Transport 237 DIAMETER packets MAY be transmitted over UDP or TCP. Each DIAMETER 238 Service Extensions draft SHOULD specify the transport layer. The 239 destination port field for DIAMETER is 1812. For UDP, when a reply 240 is generated the source and destination ports are reversed. 242 IPDC requires a reliable, order-preserving transport protocol with 243 minimal latency so that IPDC control is responsive to the demands of 244 call processing. UDP combined with the protocol description in the 245 next section satisfies these requirements, and is therefore the 246 default transport protocol for IPDC. Network operators MAY choose to 247 implement TCP instead for greater security or other reasons. 249 2.1 Protocol Overview 251 There are two different types of IPDC/DIAMETER messages: header-only 252 messages and messages containing Attribute-Value Pairs (AVPs) in 253 addition to headers. Header-only messages are used for explicitly 254 acknowledging packets to the peer. 256 The Identifier field in the DIAMETER header is a monotonically 257 increasing four octet value that is used to aid in matching requests 258 with replies. When sending a message to a peer, the sender must 259 include a value that is unique to itself at that time. The response 260 to the message from the peer MUST include the same identifier value. 261 It is imperative that no two outstanding requests from an 262 IPDC/DIAMETER node have the same identifier value. Given the current 263 size of the identifier (2^32), it is highly unlikely that this could 264 occur. 266 It is not necessary to ensure that Identifier values are unique 267 across reboots, as long as the IPDC/DIAMETER node issues a Device- 268 Reboot-Ind message after reboot completion. 270 A IPDC/ DIAMETER implementation SHOULD keep transmitted requests in a 271 queue until a response with the same Identifier value is received in 272 order to ensure that it can match the request with the response 273 received. 275 Two additional fields in the IPDC/ DIAMETER header are important to 276 the operation of the protocol: the Nr (Next Received) and Ns (Next 277 Send) values. A single sequence number state is maintained for all 278 IPDC/ DIAMETER messages to a given peer. The Sequence number starts 279 at 0 upon startup of the control session. Each subsequent packet is 280 sent with the next increment of the sequence number. 282 The sequence number is thus a free running counter represented modulo 283 65536. For purposes of detecting duplication, a received sequence 284 value is considered less than or equal to the last received value if 285 its value lies in the range of the last value and its 32767 successor 286 values. For example, if the last received sequence number was 15, 287 then packets with sequence numbers 0 through 15, as well as 32753 288 through 65536, would be considered less than or equal to, and would 289 be silently discarded. Otherwise it would be accepted. 291 In this document, the sequence number state for each peer is 292 represented for clarity in the following discussions by distinct 293 pairs of state variables, Sr and Ss. Sr represents the value of the 294 next in-sequence messages expected to be received for a given session 295 by a peer. Ss represents the sequence number to be placed in the Ns 296 field of the next message sent to a given peer. Each state is 297 initialized such that the first message sent and the first message 298 expected to be received for to/from each peer has an Ns value of 0. 299 This corresponds to initializing the Ss and Sr to 0 for each peer. 301 As messages are sent to a given peer, Nr is set in these messages to 302 reflect one more than the Ns value of the highest (modulo 2^16) in- 303 order message received by that peer. In a message sent before any 304 message is received Nr will be 0, indicating that the peer expects 305 the next new Ns value to be 0. 307 When an AVP-containing message is received with an Ns value that 308 matches the peer's current Sr value, Sr is incremented by 1 (modulo 309 2^16). It is important to note that Sr is not modified if a message 310 is received with a value if Ns greater than the current Sr value. 311 Retransmission of lost packets should eventually provide the 312 receiving peer with the expected message. 314 Every time a peer sends an AVP-containing message it increments its 315 corresponding Ss value for that session by 1 (modulo 2^16). This 316 increment takes place after the current Ss value is copied to Ns in 317 the message to be sent. Outgoing messages always include the current 318 value of Sr for the corresponding peer in their Nr field. 320 A header-only message indicates that the message is only used to 321 communicate Nr and Ns fields. The Nr and the Ns fields are filled in 322 as above, but the sequence number state, Ss, is not incremented. Thus 323 a header-only message sent after an AVP-containing message will 324 contain the new Ns value while the AVP-containing message sent after 325 a header-only message with contain the same value of Ns as the 326 preceding header-only message. 328 Upon receipt of an in-order AVP-containing message, the receiving 329 peer MUST acknowledge the message by sending back the updated value 330 of Sr in the Nr field of the next outgoing message. This updated Sr 331 value can be piggybacked in the Nr field of any AVP-containing 332 ougoing messages that the peer may happen to send back. 334 If the peer does not have a message to transmit for a short period of 335 time after receiving an AVP-containing message then it should send a 336 header-only message containing the latest values of Sr and Ss, as 337 described above. The suggested value for this time interval is 1/4 338 the receiving peer's value of Round-Trip-Time (RTT - see Appendix A), 339 if it computes RTT, or a maximum of 1/2 of its fixed timeout interval 340 otherwise. This timeout should provide a reasonable opportunity for 341 the receiving peer to obtain a payload message destined for its peer, 342 upon which the ACK of the received message can be piggybacked. 344 This timeout value should be treated as suggested maximum; an 345 implementation could make this timeout quite small without adversely 346 affecting the protocol. To provide for better throughput, the 347 receiving peer should skip this timeout entirely and send a header- 348 only message immediately in the case where its receive window fills 349 and it has no queued data to send for this connection or it can't 350 send queued data because the transmit window is closed. 352 A suggested implementation of this timer is as follows: Upon 353 receiving an AVP-containing message, the receiver starts a timer that 354 will expire in the recommended time interval. A variable, Lr (Last Nr 355 value sent), is used by the transmitter to store the last value sent 356 in the Nr field of a transmitted payload message for this connection. 357 Upon expiration of this timer, Sr is compared to Lr and, if they are 358 not equal, a header-only ACK is issued. If they are equal, then no 359 ACK's are outstanding and no action needs to be taken. 361 This timer should not be reinitialized if a new message is received 362 while it is active since such messages will be acknowledged when the 363 timer expires. This ensures that periodic ACK's are issued with a 364 maximum period equal to the recommended timeout interval. This 365 interval should be short enough to not cause false acknowledgement 366 timeouts at the transmitter when payload messages are being sent in 367 one direction only. Since such ACK's are being sent on what would 368 otherwise be an idle data path, their affect on performance should be 369 small, of not negligible. 371 See Appendix B for some examples of how sequence numbers progress. 373 3.0 Header Format 375 A summary of the IPDC message format is shown below. The fields are 376 transmitted from left to right. This format is identical to that 377 proposed for DIAMETER [2]. 379 0 1 2 3 380 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | RADIUS PCC |PKT Flags| Ver | Packet Length | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | Identifier | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Next Send (Ns) | Next Received (Nr) | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Attributes ... 389 +-+-+-+-+-+-+-+-+-+-+-+-+- 391 RADIUS PCC (Packet Compatibility Code) 392 The RADIUS PCC field is a one octet field which is used for 393 RADIUS backward compatibility. In order to easily distinguish 394 DIAMETER/IPDC messages from RADIUS a special value has been 395 reserved and allows an implementation to support both protocols 396 concurrently using the first octet in the header. The RADIUS PCC 397 field MUST be set as follows: 399 254 DIAMETER/IPDC message 401 PKT Flags 402 The Packet Flags field is five bits, and is used in order to 403 identify any options. This field MUST be initialized to zero. The 404 following flag MAY be set: 405 Window-Present 0x1 406 When set, the Next Send and Next Received fields are present. This 407 MUST be set unless the underlying layer provides reliability (i.e. 408 TCP). 410 Version 411 The Version field is three bits, and indicates the version number 412 which is associated with the packet received. This field MUST be 413 set to 1 to indicate IPDC Version 1. 415 Packet Length 416 The Packet Length field is two octets. It indicates the length of 417 the message including the header fields; thus message AVP content 418 MUST NOT exceed 65,528 octets. For messages received via UDP, 419 octets outside the range of the Length field should be treated as 420 padding and should be ignored upon receipt. 422 Identifier 423 The Identifier field is four octets, and aids in matching requests 424 and replies. The sender MUST ensure that the identifier in a 425 message is locally unique (to the sender) at any given time, and 426 MAY attempt to ensure that the number is unique across reboots. 428 The identifier is normally a monotonically increasing number, but 429 using a random value is also permitted. Given the size of the 430 Identifier field it is unlikely that 2^32 requests could be 431 outstanding at any given time. 433 Next Send 434 This field is present when the Window-Present bit is set in the 435 header flags. The Next Send (Ns) is copied from the send sequence 436 number state variable, Ss, at the time the message is transmitted. 437 Ss is incremented after copying if the message contains any AVPs. 439 Next Received 440 This field is present when the Window-Present bit is set in the 441 header flags. Nr is copied from the receive sequence number state 442 variable, Sr, and indicates the sequence number, Ns, +1 of the 443 highest (modulo 2^16) in-sequence message received. See section 444 2.0 for more information. 446 Attributes 447 See section 4.0 for more information on attribute formats. The 448 end of the list of attributes is defined by the length of the 449 message minus the length of the header. 451 3.1 Transaction Identification 453 In addition to the use of the transaction Identifier field of the 454 message header described above, all implementations of IPDC MUST 455 include an instance of Transaction-Originator AVP in each message. 456 This AVP MUST identify the originator of the transaction to which the 457 current message belongs. In other words, as well as assigning the 458 value of the Identifier, the IPDC protocol endpoint initiating a 459 transaction records its identity by means of a Transaction-Originator 460 AVP. All subsequent messages in that transaction MUST copy the 461 original Identifier and Transaction-Originator values. 463 The intent is that the combination of Identifier and Transaction- 464 Originator provides a unique transaction identifier over the set of 465 all such identifiers outstanding at a given moment of time over the 466 complete network. This is necessary because IPDC is designed to 467 allow transactions to survive the specific control sessions in which 468 they originated. It is possible, for example, that when a Media 469 Gateway Controller fails a new Media Gateway Controller acting as a 470 hot stand-by to the failed unit takes over the outstanding 471 transactions from the IPDC control session which was terminated by 472 the failure. The new Media Gateway Controller may have other 473 outstanding transactions, whose identifiers must not be duplicated by 474 those of the transactions from the failed unit. 476 4.0 AVP Format 478 IPDC Attributes carry the specific commands and parameters which must 479 be exchanged between IPDC protocol endpoints to perform the tasks 480 associated with Media Gateway control. IPDC attributes may be viewed 481 as a class of DIAMETER attributes, since the AVPs have the same 482 header format. 484 Some DIAMETER Attributes MAY be listed more than once. The effect of 485 this is command specific, and is specified by each such attribute 486 description. IPDC avoids this condition as a matter of design 487 philosophy. 489 Each AVP MUST be padded to align on a 32 bit boundary. Although this 490 is not problematic for most attribute types, it does require that 491 AVPs of string and data type be padded accordingly. The padding size 492 can be deduced using the following formula: 494 padding_size = (4 - (Length modulo 4)) modulo 4 496 A summary of the attribute format is shown below. The fields are 497 transmitted from left to right. 499 0 1 2 3 500 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | AVP Code | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | AVP Length | Reserved |P|T|V|E|H|M| 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | Vendor ID (opt) | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Tag (opt) | Value ... 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 AVP Code 512 The AVP Code field is four octets. The first 256 AVP numbers are 513 reserved for backward RADIUS compatibility. Up-to-date values of 514 the RADIUS Type field are specified in the most recent "Assigned 515 Numbers" RFC [8]. Each extension MUST allocate AVP numbers 516 through the IANA. AVP numbers between 1000 and 1999 are used for 517 IPDC. 519 If the Vendor-Specific-AVP flag is set, the AVP Code is allocated 520 from the vendor's private address space, with one exception. The 521 AVP Code 256 is reserved for commands in all address spaces. See 522 the documentation of the Command AVP in section 5.1 for 523 interpretation of that AVP when the Vendor-Specific-AVP flag is 524 set. 526 AVP Length 527 The AVP Length field is two octets, and indicates the length of 528 this Attribute including the AVP Code, AVP Length, Reserved, AVP 529 Flags, Vendor ID if present and the attribute value field. If a 530 message is received with an invalid attribute length, the message 531 SHOULD be rejected. 533 In AVP descriptions, the indicated length corresponds to the AVP 534 format as illustrated, which in general excludes the length of the 535 Tag field, the Vendor ID in the header, and other vendor-specific 536 information. 538 Reserved 539 The Reserved field MUST be set to zero (0) in all AVPs. 541 AVP Flags 542 The AVP Flags field informs the DIAMETER host how each attribute 543 must be handled. 545 The 'M' Bit, known as the Mandatory bit, indicates whether 546 support of the AVP is required. If an AVP is received with the 547 'M' bit enabled and the receiver does not support the AVP, the 548 request MUST be rejected. AVPs without the 'M' bit enabled are 549 informational only and a receiver that receives a message with 550 such an AVP that is not supported MAY simply ignore the AVP. 552 When the 'H' bit is enabled it indicates that the AVP data is 553 encrypted using hop-by-hop encryption. See section 6.6 for more 554 information. 556 When the 'E' bit is enabled it indicates that the AVP data is 557 encrypted using end-to-end encryption. See section 6.6 for more 558 information. 560 The 'V' bit, known as the Vendor-Specific bit, indicates 561 whether the optional Vendor ID field is present in the AVP 562 header. When set, the AVP Code belongs to the specific vendor 563 code address space, with the sole exception of AVP Code 256 - 564 Command AVP. This AVP Code code is reserved in all address 565 spaces. See the description of the Command AVP in section 5.1 566 for more details. 568 The 'T' bit, known as the Tag bit, is used to group sets of 569 AVPs together. Grouping of AVPs is necessary when more than one 570 AVP is needed to express a condition. 572 The 'P' bit, known as the protected AVP bit, is used to 573 indicate whether the AVP is protected by a Digital Signature 574 AVP. When set, the AVP is protected and the contents cannot be 575 changed by a DIAMETER proxy server. 577 Unless otherwise specified in the description of specific AVPs, 578 IPDC imposes the following constraints on the values of the AVP 579 Flags: 580 * the 'M' bit MUST be set 581 * the 'H', 'E', and 'P' bits MAY be set 582 * the 'V' bit MAY be set 583 * the 'T' bit MUST NOT be set. 585 Vendor ID 586 The optional four octet Vendor ID field contains the the IANA 587 assigned "SMI Network Management Private Enterprise Codes" value, 588 encoded in network byte order. Vendors wishing to implement IPDC 589 extensions can use their own Vendor IDs along with private 590 Attribute values, guaranteeing that they will not collide with any 591 other vendor's extensions, nor with future IETF extensions. 593 The value zero, reserved in this protocol, corresponds to IETF 594 adopted Attribute values, defined within this document and MUST 595 NOT be used in an AVP since it is implied with the absence of the 596 Vendor-Specific-AVP bit. 598 Tag 599 The Tag field is optional; its presence is signalled by setting 600 the 'T' AVP Flag bit. It contains a 16-bit value which is the 601 same for all AVPs in the same tag group. Tag groups are used to 602 distinguish sets of related AVPs within a single message, where 603 otherwise these relationships would be ambiguous. Thus the value 604 of the tag for a given tag group must be unique over all tags used 605 within the same message. See section 6.4 for more information on 606 the use of tags. The use of tagging is command dependent and must 607 be specified as part of the description of any command that 608 requires such use. 610 Value 611 The Value field is zero or more octets and contains information 612 specific to the Attribute. The format and length of the Value 613 field is determined by the AVP Code and AVP Length fields. 615 The format of the Value field MAY be one of six primitive data 616 types. It is also possible for the Value field to have a 617 structure, which MUST be defined along with the attribute. The 618 type of the Value field is implicit in the AVP description, not 619 coded explicitly. The primitive types are: 621 Data 622 0-65520 octets of arbitrary data. 624 String 625 0-65520 octets of string data using the UTF-8 character set. 627 Address 628 32 bit network address, most significant octet first, or 48 bit 629 transport address, network address part first, most significant 630 octet first for each of the network address and port 631 respectively. The choice between network and transport 632 address is indicated by the AVP length. This specification of 633 the address data type amplifies that given in the DIAMETER 634 specification [2], but is believed to capture its intent. 636 Integer32 637 32 bit value, most significant octet first. 639 Integer64 640 64 bit value, most significant octet first. 642 Time 643 32 bit value, most significant octet first-seconds since 644 00:00:00 GMT, January 1, 1970. 646 5.0 AVP Definitions 648 IPDC Base attributes include those inherited from DIAMETER [2] and 649 those added specifically for IPDC. Because of its special role in 650 defining message purpose and format, the Command AVP and the commands 651 contained in DIAMETER/IPDC Base are documented separately from other 652 attributes. Section 5.1 describes the Command AVP, while subsections 653 of section 5.1 describe the individual commands. Section 5.2 654 describes the other attributes contained in DIAMETER/IPDC Base. 656 5.1 Command AVP 658 Description 660 The Command AVP MUST be the first AVP following the message header. 661 This AVP is used to communicate the purpose and structure of the 662 message. There MUST only be a single Command AVP within a given 663 message. The format of the AVP is as follows: 665 0 1 2 3 666 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 | AVP Code | 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 | AVP Length | Reserved |P|T|V|E|H|M| 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 | Command Code | 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 | Additional data depending on the specific command | 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 AVP Code 678 256 Command. The AVP Code value 256 is reserved to denote an 679 Command AVP even if the Vendor-Specific-AVP bit is set. However, 680 in that case the interpretation of the Command Code and any 681 additional content in the value field is vendor-specific. 683 AVP Length 684 The length of this attribute MUST be at least 12. The exact length 685 of the AVP is determined by the actual Command and is defined with 686 each command. 688 AVP Flags 689 The Vendor-Specific-AVP bit MUST be set if and only if the command 690 is vendor-specific. 692 Command Code 693 The Command Code field contains the command number. IPDC command 694 numbers are taken from the range 1000-1999. 696 5.1.1 DIAMETER Base Commands 698 Definitions for the following commands are copied from [2] and MUST 699 be supported by all DIAMETER implementations in order to conform to 700 the DIAMETER base protocol specification. IPDC requires, in 701 contradiction to DIAMETER, that IPDC implementations use the IPDC 702 command Message-Reject instead of the DIAMETER command Command- 703 Unrecognized-Ind. Note that Message-Reject has greater scope than 704 Command-Unrecognized-Ind. 706 Command Name Command Code 708 Command-Unrecognized-Ind 256 709 Device-Reboot-Ind 257 710 Device-Watchdog-Ind 258 711 Device-Feature-Query 259 712 Device-Feature-Reply 260 713 Device-Config-Request 304 714 Device-Config-Answer 305 716 5.1.1.1 Command-Unrecognized-Ind (CUI) 718 Description 720 This description appears as a matter of record only: it applies to 721 DIAMETER devices other than IPDC protocol endpoints. IPDC protocol 722 endpoints MUST use the Message-Reject command with appropriate return 723 code instead of the Command-Unrecognized-Ind command. 725 Messages with the Command-Unrecognized-Ind AVP MUST be sent by a 726 DIAMETER device to inform its peer that a message was received with 727 an unsupported Command AVP value. 729 Since there certainly will exist a case where an existing device does 730 not support a new extension to the DIAMETER protocol, a device which 731 receives a packet with an unrecognized Command code MUST return a 732 Command-Unrecognized-Ind message. 734 Message Format 736 ::= 737 738 739 740 [] 741 742 743 { || 744 ::= 820 821 822 823 [] 824 825 [] 826 827 828 [] 829 [] 830 831 832 { || 833 ::= 884 885 886 887 [] 888 889 890 { || 891 ::= 927 928 929 [] 930 [] 931 [] 932 933 934 { || 935 ::= 973 974 975 [] 976 [] 977 978 979 980 { || 981 ::= 1028 1029 1030 1031 [] 1032 [] 1033 [] 1034 [] 1035 [] 1036 [] 1037 [] 1038 [] 1039 1040 1041 { || 1042 ::= 1089 1090 1091 1092 1093 [] 1094 [] 1095 [] 1096 [] 1097 [] 1098 [] 1099 [] 1100 [] 1101 1102 1103 { || 1104 ::= 1152 1153 1154 1156 where the Identifier value in the message header and the 1157 Transaction-Originator AVP are copied from the message being 1158 acknowledged and the Command AVP has the following format: 1160 0 1 2 3 1161 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1163 | AVP Code | 1164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1165 | AVP Length | Reserved |P|T|V|E|H|M| 1166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1167 | Command Code | 1168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1170 AVP Code 1171 256 Command 1173 AVP Length 1174 The length of this attribute MUST be at exactly 12. 1176 AVP Flags 1177 As per IPDC defaults. 1179 Command Code 1180 1100 Command-Ack 1182 5.1.2.3 Message-Reject (MRJ) 1184 Description 1186 The Message-Reject command provides a generic means of completing 1187 transactions by indicating errors in the messages which initiated 1188 them. The Message-Reject command is a possible response to any IPDC 1189 command, but some IPDC commands MAY expect more specialized error 1190 messages, depending on the error type. 1192 The Message-Reject message MUST contain the same transaction 1193 identification (header Identifier field, Transaction-Originator 1194 value) as the message it is responding to, even if that 1195 identification is erroneous. The receiver of a Message-Reject SHOULD 1196 examine the Result-Code value it provides before processing the 1197 transaction identification, in order to handle the latter 1198 appropriately. 1200 The structure of the Message-Reject message is defined as follows: 1202 ::= 1203 1204 1205 1206 1207 [ ] 1208 [ ] 1209 [ ] 1211 where the Identifier value in the message header and the 1212 Transaction-Originator AVP are copied from the message being rejected 1213 and the Command AVP has the format described below. The Result-Code 1214 and conditionally-present Error-Code AVPs indicate the nature of the 1215 error causing rejection, and the conditionally-present Failed-AVP- 1216 Code AVP provides some minimal debugging data by indicating a 1217 specific AVP type which caused the problem. See the description of 1218 the Result-Code AVP in section 5.2.1.14 for indication of when the 1219 Error-Code and/or Failed-AVP-Code AVPs will be present in the 1220 message. The Unknown-Command-Code AVP is present only when the 1221 reason for message rejection is an unrecognized or unsupported 1222 command code. 1224 The documentation of individual IPDC commands MAY also include 1225 documentation of the expected contents of an ensuing Message-Reject 1226 message, beyond the information given in section 5.2.1.14. 1228 The format of the Command AVP for Message-Reject is as follows: 1230 0 1 2 3 1231 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1233 | AVP Code | 1234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1235 | AVP Length | Reserved |P|T|V|E|H|M| 1236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1237 | Command Code | 1238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1240 AVP Code 1241 256 Command 1243 AVP Length 1244 The length of this attribute MUST be at exactly 12. 1246 AVP Flags 1247 As per IPDC defaults. 1249 Command Code 1250 1101 Message-Reject 1252 5.2 Other AVPs 1254 This section defines the IPDC Base attributes other than the Command 1255 AVP. A number of these attributes are inherited from DIAMETER Base 1256 [2]; these are documented in section 5.2.1. IPDC adds some 1257 additional attributes, documented in section 5.2.2. 1259 5.2.1 DIAMETER Base AVPs 1261 Aside from the Command AVP, DIAMETER Base [2] defines the following 1262 AVPs: 1264 Attribute Name Attribute Code 1266 Host-IP-Address 4 1267 Host-Name 32 1268 Version-Number 257 1269 Extension-Id 258 1270 Integrity-Check-Vector 259 1271 Digital-Signature 260 1272 Initialization-Vector 261 1273 Timestamp 262 1274 Session-Id 263 1275 X509-Certificate 264 1276 X509-Certificate-URL 265 1277 Vendor-Name 266 1278 Firmware-Revision 267 1279 Result-Code 268 1280 Error-Code 269 1281 Unknown-Command-Code 270 1282 Reboot-Type 271 1283 Reboot-Timer 272 1284 Message-Timer 273 1285 Message-In-Progress-Timer 274 1286 Message-Retry-Count 275 1287 Message-Forward-Count 276 1288 Receive-Window 277 1290 5.2.1.1 Host-IP-Address 1292 Description 1294 The Host-IP-Address attribute is used to inform a DIAMETER peer of 1295 the sender's identity. 1297 0 1 2 3 1298 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1300 | AVP Code | 1301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1302 | AVP Length | Reserved |P|T|V|E|H|M| 1303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1304 | Address | 1305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1307 AVP Code 1308 4 Host-IP-Address 1310 AVP Length 1311 The length of this attribute MUST be at least 12. 1313 AVP Flags 1314 As per IPDC defaults. 1316 Address 1317 The Address field is of type Address and contains the sender's IP 1318 address. 1320 5.2.1.2 Host-Name 1322 Description 1324 The Host-Name attribute is used to inform a DIAMETER peer of the 1325 sender's identity. 1327 0 1 2 3 1328 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1330 | AVP Code | 1331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1332 | AVP Length | Reserved |P|T|V|E|H|M| 1333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1334 | Name ... 1335 +-+-+-+-+-+-+-+-+ 1337 AVP Code 1338 32 Host-Name 1340 AVP Length 1341 The length of this attribute MUST be at least 9. 1343 AVP Flags 1344 As per IPDC defaults. 1346 Name 1347 The Name field is of type String. It consists of one or more 1348 octets, and should be unique to the DIAMETER host. The Host Name 1349 MUST follow the NAI [12] naming conventions. 1351 5.2.1.3 Version-Number 1353 Description 1355 [Whether IPDC has its own version numbering independently of DIAMETER 1356 is for future determination.] The Version-Number AVP is used in 1357 order to indicate the current DIAMETER system version number to a 1358 peer. It has the following format: 1360 0 1 2 3 1361 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1363 | AVP Code | 1364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1365 | AVP Length | Reserved |P|T|V|E|H|M| 1366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1367 | Version | 1368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1370 AVP Code 1371 257 Version-Number 1373 AVP Length 1374 The length of this attribute MUST be 12. 1376 AVP Flags 1377 As per IPDC defaults. 1379 Version 1380 Version is of type Integer32, and contains the system's DIAMETER 1381 version number. 1383 5.2.1.4 Extension-Id 1385 Description 1387 The Extension-Id AVP is used in order to identify a specific DIAMETER 1388 extension. This AVP MAY be used in the Device-Reboot-Ind and the 1389 Device-Feature-Response command in order to inform the peer what 1390 extensions are locally supported. 1392 Each DIAMETER extensions draft MUST have a Extension-Id assigned to 1393 it by the IANA. The base protocol does not require an Extension-Id 1394 since its support is mandatory. [Whether IPDC Base and the IPDC 1395 extensions described in [4], [5], [6], and [7] are registered as 1396 DIAMETER extensions or establish an extension system of their own is 1397 for future determination.] 1399 There MAY be more than one Extension-Id AVP within a DIAMETER 1400 message. 1402 0 1 2 3 1403 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1405 | AVP Code | 1406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1407 | AVP Length | Reserved |P|T|V|E|H|M| 1408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1409 | Extension Number | 1410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1412 AVP Code 1413 258 Extension-Id 1415 AVP Length 1416 The length of this attribute MUST be 12. 1418 AVP Flags 1419 As per IPDC defaults. 1421 Extension Number 1422 The Extension Number is of type Integer32, and contains the 1423 extension identifier as defined in the extension's document. 1425 5.2.1.5 Integrity-Check-Vector 1427 Description 1429 The Integrity-Check-Vector AVP is used for hop-by-hop authentication 1430 and integrity, and is not recommended for use with untrusted proxy 1431 servers. The message header as well as all AVPs up to and including 1432 the AVP Code field of this AVP is protected by the Integrity-Check- 1433 Vector. The Timestamp AVP MUST be present to provide replay 1434 protection and the Initialization-Vector AVP must be present to add 1435 randomness to the packet. The Integrity-Check-Vector is generated by 1436 the method described in section 6.6.1. 1438 All DIAMETER/IPDC implementations MUST support this AVP. 1440 0 1 2 3 1441 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1443 | AVP Code | 1444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1445 | AVP Length | Reserved |P|T|V|E|H|M| 1446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1447 | Transform ID | 1448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1449 | Check Value ... 1450 +-+-+-+-+-+-+-+-+ 1452 AVP Code 1453 259 Integrity-Check-Vector 1455 AVP Length 1456 The length of this attribute MUST be at least 13. 1458 AVP Flags 1459 The 'M' bit MUST be set. The 'E', 'H', and 'P' bits MUST NOT be 1460 set. 1462 Transform ID 1463 The Transform ID field is of type Integer32 and identifies the 1464 algorithm used to generate the check value. The following values 1465 are defined in this document: 1467 1 HMAC-MD5-96 [6] 1469 Check Value 1470 The Check Value field is of type Data and contains an integrity 1471 check value for the message up to this AVP. 1473 5.2.1.6 Digital-Signature 1475 Description 1477 The Digital-Signature AVP is used for authentication and integrity as 1478 well as non-repudiation. A DIAMETER entity adding AVPs to a message 1479 MUST ensure that all AVPs appear prior to the Digital-Signature AVP 1480 (with the exception of the Integrity-Check-Vector AVP, which MUST 1481 appear after the Digital-Signature AVP). The Timestamp AVP MUST be 1482 present to provide replay protection and the Initialization-Vector 1483 AVP MUST be present to add randomness to the packet. 1485 The DIAMETER header as well as all AVPs with the 'P' bit disabled are 1486 protected by the Digital-Signature. 1488 Note that for services which use the concept of a proxy server which 1489 forwards the request to a next hop server, the proxy server MUST NOT 1490 modify any attributes found prior to the Digital- Signature AVP. This 1491 ensures that end-to-end security is maintained even through proxy 1492 arrangements. 1494 The Digital-Signature is generated by the method described in section 1495 6.6.2. 1497 All DIAMETER implementations SHOULD support this AVP. [Requirements 1498 for IPDC implementations are for future determination.] 1500 0 1 2 3 1501 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1503 | AVP Code | 1504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1505 | AVP Length | Reserved |P|T|V|E|H|M| 1506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1507 | Address | 1508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1509 | Transform ID | 1510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1511 | Signature ... 1512 +-+-+-+-+-+-+-+-+ 1514 AVP Code 1515 260 Digital-Signature 1517 AVP Length 1518 The length of this attribute MUST be at least 9. 1520 AVP Flags 1521 The 'M' bit MUST be set. The 'H' MAY be set if the request is 1522 protected with an ICV AVP. The 'E'and 'P' bits MUST NOT be set. 1524 Address 1525 The Address field is of type Address and contains the IP address 1526 of the IPDC host which generated the Digital-Signature. 1528 Transform ID 1529 The Transform ID field is of type Integer32 and identifies the 1530 algorithm used to generate the Signature value. The following 1531 values are defined in this document: 1533 1 RSA [9] 1535 Signature 1536 The Signature field is of type Data and contains the digital 1537 signature of the packet up to this AVP. 1539 5.2.1.7 Initialization-Vector 1541 Description 1543 The Initialization-Vector AVP MUST be present prior to the Digital- 1544 Signature and Integrity-Check-Vector AVPs within a message and is 1545 used to ensure randomness within a message. The content of this AVP 1546 MUST be a random 128 bit value. 1548 0 1 2 3 1549 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1551 | AVP Code | 1552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1553 | AVP Length | Reserved |P|T|V|E|H|M| 1554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1555 | | 1556 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 1557 | | 1558 +-+-+-+-+-+-+-+-+ Random +-+-+-+-+-+-+-+-+ 1559 | | 1560 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 1561 | | 1562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1563 AVP Code 1564 261 Initialization-Vector 1566 AVP Length 1567 The length of this attribute MUST be 24. 1569 AVP Flags 1570 As per IPDC defaults. 1572 Random 1573 The Random field is of type Data and contains a random 128-bit 1574 value. 1576 5.2.1.8 Timestamp 1578 Description 1580 The Timestamp field is used in order to enable protection against 1581 replay of previous messages. The value of time is the most 1582 significant four octets returned from an NTP server which indicates 1583 the number of seconds expired since Jan. 1, 1970. 1585 This document does not specify the window within which an 1586 implementation will accept packets; however, it is strongly 1587 encouraged that this value be made user configurable with a 1588 reasonable default value (e.g. 4 seconds). 1590 0 1 2 3 1591 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1593 | AVP Code | 1594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1595 | AVP Length | Reserved |P|T|V|E|H|M| 1596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1597 | Timestamp | 1598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1600 AVP Code 1601 262 Timestamp 1603 AVP Length 1604 The length of this attribute MUST be 12. 1606 AVP Flags 1607 As per IPDC defaults. 1609 Timestamp 1610 The Timestamp field is of type Time and contains the time at which 1611 the message was created. 1613 5.2.1.9 Session-Id 1615 Description 1617 The Session-Id field is used in order to identify a specific session. 1618 All messages pertaining to a specific session MUST include this AVP 1619 and the same value MUST be used throughout the life of a session. 1620 When present, the Session-Id SHOULD appear immediately following the 1621 Command- AVP. 1623 Note that in some applications there is no concept of a session (i.e. 1624 data flow) and this field MAY be used to identify objects other than 1625 a session. 1627 The Session-Id MUST be globally unique at any given time since it is 1628 used by the server to identify the session (or flow). It is 1629 recommended that the format of the AVP be as follows: 1631 1632 1634 It is suggested that the monotonically increasing 32 bit value NOT 1635 start at zero upon reboot, but rather start at a random value. This 1636 will minimize the possibility of overlapping Session-Ids after a 1637 reboot. The optional value is implementation specific but may include 1638 a modem's device Id, a random value, etc. 1640 The session Id is created by the DIAMETER device initiating the 1641 session. In most cases this is the client. 1643 0 1 2 3 1644 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1646 | AVP Code | 1647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1648 | AVP Length | Reserved |P|T|V|E|H|M| 1649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1650 | SessionId ... 1651 +-+-+-+-+-+-+-+-+ 1653 AVP Code 1654 263 Session-Id 1656 AVP Length 1657 The length of this attribute MUST be at least 12. 1659 AVP Flags 1660 As per IPDC defaults. 1662 SessionId 1663 The SessionId field is of type Data and contains the session 1664 identifier assigned to the session. 1666 5.2.1.10 X509-Certificate 1668 Description 1670 The X509-Certificate is used to send a DIAMETER peer the local 1671 system's X.509 certificate chain, which is used to validate the 1672 Digital-Signature attribute. 1674 Section 6.8 contains more information about the use of certificates. 1676 0 1 2 3 1677 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1679 | AVP Code | 1680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1681 | AVP Length | Reserved |P|T|V|E|H|M| 1682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1683 | Chain ... 1684 +-+-+-+-+-+-+-+-+ 1686 AVP Code 1687 264 X509-Certificate 1689 AVP Length 1690 The length of this attribute MUST be at least 9. 1692 AVP Flags 1693 As per IPDC defaults. 1695 Chain 1696 The Chain field is of type Data and contains the X.509 Certificate 1697 Chain. 1699 5.2.1.11 X509-Certificate-URL 1701 Description 1702 The X509-Certificate-URL is used to send a DIAMETER peer a URL 1703 pointing to the local system's X.509 certificate chain, which is used 1704 in order to validate the Digital-Signature attribute. 1706 Section 6.8 contains more information about the use of certificates. 1708 0 1 2 3 1709 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1711 | AVP Code | 1712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1713 | AVP Length | Reserved |P|T|V|E|H|M| 1714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1715 | URL ... 1716 +-+-+-+-+-+-+-+-+ 1718 AVP Code 1719 265 X509-Certificate-URL 1721 AVP Length 1722 The length of this attribute MUST be at least 9. 1724 AVP Flags 1725 As per IPDC defaults. 1727 URL 1728 The URL field is of type String and contains the X.509 Certificate 1729 Chain URL. 1731 5.2.1.12 Vendor-Name 1733 Description 1735 The Vendor-Name attribute is used to tell a DIAMETER peer the Vendor 1736 Name of the DIAMETER device. This MAY be used by the peer to decide 1737 which vendor specific attributes may be sent to this DIAMETER device. 1738 It is also envisioned that the combination of the Vendor-Name and the 1739 Firmware-Revision AVPs can provide very useful debugging information. 1741 0 1 2 3 1742 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1744 | AVP Code | 1745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1746 | AVP Length | Reserved |P|T|V|E|H|M| 1747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1748 | Name ... 1750 +-+-+-+-+-+-+-+-+ 1752 AVP Code 1753 266 Vendor-Name 1755 AVP Length 1756 The length of this attribute MUST be at least 9. 1758 AVP Flags 1759 As per IPDC defaults. 1761 Name 1762 The Name field is of type String and contains the vendor name. 1764 5.2.1.13 Firmware-Revision 1766 Description 1768 The Firmware-Revision AVP is used to inform a DIAMETER peer of the 1769 firmware revision of the issuing device. 1771 For devices which do not have a firmware revision (general purpose 1772 computers running DIAMETER software modules, for instance), the 1773 revision of the DIAMETER software module may be reported instead. 1775 0 1 2 3 1776 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1778 | AVP Code | 1779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1780 | AVP Length | Reserved |P|T|V|E|H|M| 1781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1782 | Revision Code | 1783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1785 AVP Code 1786 267 Firmware-Revision 1788 AVP Length 1789 The length of this attribute MUST be 12. 1791 AVP Flags 1792 As per IPDC defaults. 1794 Revision Code 1795 The Revision Code field is of type Integer32 and contains the 1796 firmware revision number of the issuing device. 1798 5.2.1.14 Result-Code 1800 Description 1802 The Result-Code AVP is used to indicate whether a particular command 1803 was completed successfully or whether an error occurred. All 1804 DIAMETER/IPDC commands MUST specify whether the Result-Code AVP MUST 1805 be present. 1807 0 1 2 3 1808 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1810 | AVP Code | 1811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1812 | AVP Length | Reserved |P|T|V|E|H|M| 1813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1814 | Result Code | 1815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1817 AVP Code 1818 268 Result-Code 1820 AVP Length 1821 The length of this attribute MUST be 12. 1823 AVP Flags 1824 As per IPDC defaults. 1826 Result Code 1827 The Result Code field is of type Integer32 and contains the result 1828 code associated with the DIAMETER or IPDC command. The following 1829 codes have been defined: 1831 DIAMETER_SUCCESS 0 1832 The Request was successfully completed. IPDC responses MAY 1833 contain this Result Code value, but typically positive IPDC 1834 responses will be conveyed by the Command-Ack message. 1836 DIAMETER_FAILURE 1 1837 The Request was not successfully completed for an unspecified 1838 reason. An IPDC Message-Reject message returning this result 1839 SHOULD whenever possible also contain one or more Failed-AVP- 1840 Code AVPs indicating the attributes which caused the failure. 1842 DIAMETER_POOR_REQUEST 2 1843 The Request was poorly constructed. An IPDC Message-Reject 1844 message returning this result SHOULD whenever possible also 1845 contain one or more Failed-AVP-Code AVPs indicating the 1846 attributes which caused the failure. 1848 DIAMETER_INVALID_MAC 3 1849 The Request did not contain a valid Integrity-Check-Vector or 1850 Digital- Signature. 1852 DIAMETER_UNKNOWN_SESSION_ID 4 1853 The Request contained an unknown Session-Id. 1855 DIAMETER_SEE_ERROR_CODE 5 1856 The Request failed. The message MUST also contain an Error-Code 1857 AVP which provides command-specific information on the failure. 1858 An IPDC Message-Reject message returning this result SHOULD 1859 whenever possible also contain one or more Failed-AVP-Code AVPs 1860 indicating the attributes which caused the failure. 1862 IPDC_COMMAND_UNSUPPORTED 6 1863 The Request contained a command code which the IPDC 1864 implementation does not recognize or does not support. IPDC 1865 implementations MUST return a Message-Reject message containing 1866 this Result Code value rather than use the DIAMETER Command- 1867 Unrecognized message. The Message-Reject message MUST also 1868 contain an Unknown-Command-Code AVP which contains the Command 1869 Code value which was rejected. 1871 IPDC_BAD_TRANSACTION_ID 7 1872 The Request contained invalid transaction identification. 1873 Possible errors include a missing Transaction-Originator AVP, 1874 an unrecognized IPDC protocol endpoint identifier in the 1875 Transaction-Originator AVP or an Identifier value in the 1876 message header of a response which is not recognized as 1877 pertaining to a currently outstanding transaction at the 1878 receiving IPDC protocol endpoint. 1880 IPDC_ATTRIBUTE_UNSUPPORTED 8 1881 The Request contained an AVP with an AVP Code which the IPDC 1882 implementation does not recognize or does not support. An IPDC 1883 Message-Reject message returning this result MUST also contain 1884 one or more Failed-AVP-Code AVPs indicating the AVP Codes which 1885 caused the failure. 1887 5.2.1.15 Error-Code 1889 Description 1891 The Error-Code AVP contains the message-specific error code, if any. 1892 This AVP MUST be present if and only if the Result-Code AVP is 1893 present containing the value DIAMETER_SEE_ERROR_CODE. IPDC error 1894 responses, particularly Message-Reject, MAY contain more than one 1895 Error-Code AVP, each possibly paired with a Failed-AVP-Code AVP. 1897 Error-Code values and corresponding semantics are specific to the 1898 command to which the Error-Code is a response, and MUST therefore be 1899 documented as part of the description of that command. 1901 0 1 2 3 1902 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1904 | AVP Code | 1905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1906 | AVP Length | Reserved |P|T|V|E|H|M| 1907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1908 | Error Code | 1909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1911 AVP Code 1912 268 Error-Code 1914 AVP Length 1915 The length of this attribute MUST be 12. 1917 AVP Flags 1918 As per IPDC defaults. 1920 Error Code 1921 The Error Code field is of type Integer32 and contains the error 1922 code value. 1924 5.2.1.16 Unknown-Command-Code 1926 Description 1928 The Unknown-Command-Code AVP contains the offending Command Code that 1929 resulted in sending the Unrecognized-Command-Code message. 1931 AVP Format 1933 0 1 2 3 1934 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1936 | AVP Code | 1937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1938 | AVP Length | Reserved |P|T|V|E|H|M| 1939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1940 | Command Code | 1941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1943 AVP Code 1944 270 Unknown-Command-Code 1946 AVP Length 1947 The length of this attribute MUST be 12. 1949 AVP Flags 1950 As per IPDC defaults. 1952 Command Code 1953 The Command Code field is of type Integer32 field and contains the 1954 unrecognized command code that resulted 1956 5.2.1.17 Reboot-Type 1958 Description 1960 The Reboot-Type AVP MUST be present in the Device-Reboot-Indication 1961 message and contains an indication of the type of reboot. 1963 AVP Format 1965 0 1 2 3 1966 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1968 | AVP Code | 1969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1970 | AVP Length | Reserved |P|T|V|E|H|M| 1971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1972 | Reboot Type | 1973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1975 AVP Code 1976 271 Reboot-Type 1978 AVP Length 1979 The length of this attribute MUST be 12. 1981 AVP Flags 1982 As per IPDC defaults. 1984 Reboot Type 1985 The Reboot Type field is of type Integer32 and contains the reboot 1986 type associated with the DRI command. The following values are 1987 currently defined: 1989 REBOOT_IMMINENT 1 1990 When the Reboot-Type AVP is set to this value it is an 1991 indication that the DIAMETER peer is about to reboot and should 1992 not be sent any additional DIAMETER messages besides the 1993 acknowledgement. 1995 REBOOTED 2 1996 When the Reboot-Type AVP is set to this value it is an 1997 indication that the DIAMETER peer has recently rebooted and is 1998 ready to accept new DIAMETER messages. 2000 CLEAN_REBOOT 3 2001 When the Reboot-Type AVP is set to this value the server is in 2002 the process of shutting down and MAY be available at some time 2003 in the future. 2005 5.2.1.18 Reboot-Time 2007 Description 2009 The Reboot-Time AVP MAY be present in the DRI and indicates the 2010 number of seconds before the issuer expects to be ready to receive 2011 new DIAMETER messages. This AVP MUST only be present when the 2012 Reboot-Type AVP is set to REBOOT_IMMINENT. The value indicated by 2013 this AVP should be used as an estimate and is not a hard rule. 2015 AVP Format 2017 0 1 2 3 2018 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2020 | AVP Code | 2021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2022 | AVP Length | Reserved |P|T|V|E|H|M| 2023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2024 | Estimated Outage | 2025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2027 AVP Code 2028 272 Reboot-Time 2030 AVP Length 2031 The length of this attribute MUST be 12. 2033 AVP Flags 2034 As per IPDC defaults. 2036 Estimated Outage 2037 The Estimated Outage field is of type Integer32 and contains the 2038 expected amount of seconds before the issuer of the DRI expects to 2039 be able to receive new DIAMETER messages. 2041 5.2.1.19 Message-Timer 2043 Description 2045 This AVP is used by a device to determine how long to wait before 2046 trying again to send a message expecting a response or 2047 acknowledgement. This timer value overrides any default value a 2048 device may have. 2050 Note that a DIAMETER extensions AVP could define another timer that 2051 would override this one for a specific message type. 2053 AVP Format 2055 0 1 2 3 2056 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2058 | AVP Code | 2059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2060 | AVP Length | Reserved |P|T|V|E|H|M| 2061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2062 | Retry Time | 2063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2065 AVP Code 2066 273 Message-Timer 2068 AVP Length 2069 The length of this attribute MUST be 12. 2071 AVP Flags 2072 As per IPDC defaults. 2074 Retry Time 2075 The Retry Time field is of type Integer32 and contains the value 2076 of the retry timer in milliseconds. A value of 0 for this timer 2077 means that the device's default value for this timer is to be 2078 used. 2080 5.2.1.20 Message-In-Progress-Timer 2082 Description 2084 This AVP is used by a device's state machine to deterimine how long 2085 to wait before sending a Message-In-Progress message that tells the 2086 peer device that the message for which it is expecting a response or 2087 acknowledgment is still in progress. 2089 AVP Format 2091 0 1 2 3 2092 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2094 | AVP Code | 2095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2096 | AVP Length | Reserved |P|T|V|E|H|M| 2097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2098 | Wait time | 2099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2101 AVP Code 2102 274 Message-In-Progress-Timer 2104 AVP Length 2105 The length of this attribute MUST be 12. 2107 AVP Flags 2108 As per IPDC defaults. 2110 Wait Time 2111 The Wait Time field is of type Integer32 and contains the value of 2112 the timer in milliseconds. A value of 0 indicates that the 2113 MessageInProgress-Indication message is not being used. 2115 5.2.1.21 Message-Retry-Count 2117 Description 2119 This AVP is used by a device's state machine to determine how many 2120 times it is allowed to resend a message that is expecting a response 2121 or acknowledgement. 2123 AVP Format 2125 0 1 2 3 2126 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2128 | AVP Code | 2129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2130 | AVP Length | Reserved |P|T|V|E|H|M| 2131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2132 | Max Resends | 2133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2135 AVP Code 2136 275 Message-Retry-Count 2138 AVP Length 2139 The length of this attribute MUST be 12. 2141 AVP Flags 2142 As per IPDC defaults. 2144 Max Resends 2145 The Max Resends field is of type Integer32 and contains the 2146 maximum allowed retry count for a given message. 2148 5.2.1.22 Maximum-Forward-Count 2150 Description 2152 This AVP is used by a device to determine if a message shouldcontinue 2153 to be forwarded. A use for this count would be to limit the number 2154 of proxies used to satisfy a request. 2156 AVP Format 2158 0 1 2 3 2159 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2161 | AVP Code | 2162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2163 | AVP Length | Reserved |P|T|V|E|H|M| 2164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2165 | Max Forwards | 2166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2168 AVP Code 2169 276 Maximum-Forward-Count 2171 AVP Length 2172 The length of this attribute MUST be 12. 2174 AVP Flags 2175 As per IPDC defaults. 2177 Max Forwards 2178 This field is of type Integer32 and contains the limit on the 2179 number of times the message should be forwarded beyond the current 2180 node. 2182 5.2.1.23 Receive-Window 2184 Description 2186 This AVP is used by a device to inform a peer of the local receive 2187 window size. The size indicated is the number of messages that it is 2188 willing to accept before the window is full. 2190 AVP Format 2192 0 1 2 3 2193 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2195 | AVP Code | 2196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2197 | AVP Length | Reserved |P|T|V|E|H|M| 2198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2199 | Window | 2200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2202 AVP Code 2203 277 Receive-Window 2205 AVP Length 2206 The length of this attribute MUST be 12. 2208 AVP Flags 2209 As per IPDC defaults. 2211 Window 2212 This field is of type Integer32 and contains the receive window 2213 size. 2215 5.2.2 Additional IPDC AVPs 2217 The attributes defined in this section MUST be supported by all IPDC 2218 implementations. 2220 5.2.2.1 Transaction-Originator 2222 Description 2224 As described in section 3.1, every IPDC message must contain an 2225 instance of the Transaction-Originator AVP. The Transaction- 2226 Originator AVP contains information which uniquely identifies the 2227 IPDC protocol endpoint which originated a transaction. The 2228 uniqueness MUST be broad enough in scope to permit transactions 2229 originated in one control session to be continued in another control 2230 session where one of the endpoints has been replaced after failure. 2231 In particular, it is required in order to support takeover of the 2232 transaction by an alternate Media Gateway Controller. 2234 The Transaction-Originator AVP has the following format: 2236 0 1 2 3 2237 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2239 | AVP Code | 2240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2241 | AVP Length | Reserved |P|T|V|E|H|M| 2242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2243 | Originator Id ... 2244 +-+-+-+-+-+-+-+-+-+-+-+ 2246 AVP Code 2247 1000 Transaction-Originator 2249 AVP Length 2250 The length of this attribute MUST be at least 9. 2252 AVP Flags 2253 As per IPDC defaults. 2255 Originator Id 2256 The Originator Id field is of type Data and contains information 2257 of arbitrary format which uniquely identifies an IPDC protocol 2258 endpoint within the network. Typically this information, combined 2259 with the value of the Identifier field in the message header, 2260 provides an index into the list of outstanding transactions at the 2261 originating IPDC protocol endpoint. 2263 5.2.2.2 Failed-AVP-Code 2265 Description 2266 The Failed-AVP-Code AVP provides debugging information in cases where 2267 a request is rejected or not fully processed due to erroneous 2268 information in a specific AVP. The documentation of the Return-Code 2269 AVP in section 5.2.1.14 and of the Message-Reject command in section 2270 provide information on the use of the Failed-AVP-Code AVP. This AVP 2271 has the following format: 2273 0 1 2 3 2274 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2276 | AVP Code | 2277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2278 | AVP Length | Reserved |P|T|V|E|H|M| 2279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2280 | Failed AVP Code | 2281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2283 AVP Code 2284 1001 Failed-AVP-Code 2286 AVP Length 2287 The length of this attribute MUST be 12. 2289 AVP Flags 2290 As per IPDC defaults. 2292 Failed AVP Code 2293 The Failed AVP Code field is of type Integer32 and contains the 2294 AVP Code value of an AVP which could not be processed 2295 successfully. Possible reasons for this are an improperly- 2296 constructed AVP, an unsupported or unrecognized AVP Code, or an 2297 invalid value. 2299 Note that where more than one instance of the same AVP Code was 2300 present in the message to which the one containing the Failed- 2301 AVP-Code AVP is a response, the value of the AVP Code is 2302 insufficient to uniquely identify the actual AVP causing the 2303 problem. 2305 5.3 IPDC AVP Templates 2307 The IPDC design philosophy values semantic precision over re- 2308 usability of AVP types. Thus the same AVP structure may appear 2309 repeatedly, but associated with different AVP Codes. IPDC avoids 2310 dependence on AVP sequence within a message to convey meaning. 2312 This design approach has the advantage that it promotes stateless 2313 decoding of IPDC messages, although it requires the IPDC 2314 encoder/decoder to have a broader repertoire of AVP Codes than the 2315 alternative. From the documentation point of view, its main 2316 disadvantage is the extra space taken up in documentation of AVP 2317 structures. To minimize that disadvantage, IPDC introduces the 2318 concept of AVP templates. These are descriptions of frequently- 2319 occuring AVP structures to which other IPDC protocol documentation 2320 may refer. This draft defines one such template: the IPDC Reference. 2322 5.3.1 IPDC Reference 2323 5.3.1.1 Description 2325 The IPDC-Reference attribute provides a generic means of referring to 2326 the objects of IPDC control. The format of the IPDC-Reference AVP is 2327 as follows: 2329 0 1 2 3 2330 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2332 | AVP Code | 2333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2334 | AVP Length | Reserved |P|T|V|E|H|M| 2335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2336 | Entity Type Code | 2337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2338 | Entity Name ... 2339 +-+-+-+-+-+-+-+-+-+-+- 2341 AVP Code 2342 Assigned in the specific AVP definition which refers to this 2343 template. 2345 AVP Length 2346 The length of this attribute MUST be at least 12. 2348 AVP Flags 2349 As per IPDC defaults. 2351 Entity Type Code 2352 The Entity Type Code field is of type Integer32 and indicates the 2353 entity type denoted by this AVP. The following Entity Type Codes 2354 have been defined: 2356 MEDIA_GATEWAY 0 2357 The Media Gateway application which forms one endpoint of an 2358 IPDC control session. 2360 PHYSICAL_GATEWAY 1 2361 A physical gateway unit. 2363 STATION 2 2364 A degenerate case of a physical gateway unit serving only a 2365 single access termination. 2367 EQUIPMENT_HOLDER 3 2368 A physical container of other gateway resources such as a shelf 2369 or card. 2371 TRANSPORT_TERMINATION 4 2372 The physical termination at a gateway of an analogue or digital 2373 transmission link such as a DS-1, either from the circuit- 2374 switched network or from the packet network. 2376 ACCESS_TERMINATION 5 2377 The logical termination at a gateway of a bearer connection 2378 (and associated signalling if not on a separate channel) from 2379 an user device. 2381 TRUNK_TERMINATION 6 2382 The logical termination at a gateway of a bearer connection 2383 (and associated signalling if not on a separate channel) from a 2384 circuit switch. 2386 SIGNALLING_TERMINATION 7 2387 The logical termination at a gateway of a call signalling 2388 channel (e.g. ISDN D-channel) from a circuit switch or user 2389 device. 2391 DEVICE 8 2392 An internal physical unit of a type not otherwise covered by 2393 this list of entity types. 2395 MODEM 9 2396 A modem internal to a gateway. 2398 CONFERENCE_PORT 10 2399 A port on a conference bridge internal to a gateway. 2401 FAX_PORT 11 2402 An internal endpoint capable of accepting and forwarding bearer 2403 content consisting of encoded facsimile. 2405 STREAM_SOURCE 12 2406 An internal source of bearer content such as an announcement or 2407 tone, meant to be transmitted to an user. 2409 STREAM_RECORDER 13 2410 An internal recording destination for bearer content coming 2411 from an user, such as a voice mailbox. 2413 RTP_PORT 14 2414 A pair of transport addresses respectively defining the remote 2415 and local termination points of a bi-directional RTP- 2416 encapsulated media stream. See the naming rules for this 2417 entity in the next section for the means by which uni- 2418 directional streams are represented. 2420 ATM_SPEC 15 2421 An address specification suitable for establishing an ATM 2422 connection. Details for further study. 2424 H323_SPEC 16 2425 A call signalling transport address specification or equivalent 2426 such as an H.323 alias, suitable for establishing an outgoing 2427 H.323 signalling connection. 2429 SIP_SPEC 17 2430 An address specification suitable for establishing a SIP 2431 signalling connection. 2433 Entity Name 2434 The Entity Name field is of type String and specifies the 2435 particular entity or set of entities to which the command applies. 2436 The next section specifies and gives examples of the possible form 2437 of the naming string for each of the entity types listed above. 2438 Provision is made for wild-carding operations on a given set of 2439 entities. The Entity Name field MAY be present for the 2440 MEDIA_GATEWAY entity, but MUST be present for all other types. 2442 5.3.1.2 Naming of IPDC Entities 2444 Resource Names 2446 For all gateway resource entity types (that is, PHYSICAL_GATEWAY 2447 through STREAM_RECORDER in the above list), naming is essentially a 2448 matter of local convention. However, the entity name for each of 2449 these types is naturally hierarchical, beginning with a term which 2450 identifies the physical gateway containing the given resource and 2451 ending in a term which specifies the individual resource concerned. 2452 With this in mind, the following rules for construction and 2453 interpretation of the Entity Name field for these entity types MUST 2454 be supported: 2456 1. The individual terms of the naming path MUST be separated by 2457 a single slash ("/", ASCII 2F hex). 2459 2. Optionally, the first term MAY be of the form: 2461 FORM: 2463 where is a string defined by local agreement which implies 2464 a specific form and semantic interpretation of the remaining terms of 2465 the naming path. This is necessary to support multiple 2466 representations of a single reference type. For example, a reference 2467 that specifies a trunk termination may take multiple vendor dependent 2468 formats. The substring "FORM:" is reserved for this purpose at the 2469 start of the naming string. 2471 3. Wild-carding is represented either by an asterisk ("*") or a 2472 dollar sign ("$") for the terms of the naming path which are to be 2473 wild-carded. Thus, if the full naming path looks like 2475 term1/term2/term3 2477 then the Entity Name field looks like this depending on which terms 2478 are wild-carded: 2480 */term2/term3 if term1 is wild-carded 2481 term1/*/term3 if term2 is wild-carded 2482 term1/term2/* if term3 is wild-carded 2483 term1/*/* if term2 and term3 are wild-carded, 2484 etc. 2486 In each of these examples a dollar sign could have appeared instead 2487 of an asterisk. 2489 4. A term represented by an asterisk is to be interpreted as: 2490 "use ALL values of this term known within the scope of the Media 2491 Gateway". A term represented by a dollar sign is to be interpreted 2492 as: "use ANY ONE value of this term known within the scope of the 2493 Media Gateway". The description of a specific command or AVP may add 2494 further criteria for selection within the general rules given here. 2496 5. If the Media Gateway controls multiple physical gateways, the 2497 first term of the naming string beyond the optional FORM: term MUST 2498 identify the physical gateway containing the desired entity. If the 2499 Media Gateway controls only a single physical gateway, the first term 2500 of the naming string MAY identify that physical gateway, depending on 2501 local practice. 2503 RTP Ports 2505 The basic format of the RTP entity name consists of three terms 2506 separated by slashes ("/", ASCII 2F hex) which together define a 2507 two-way RTP connection from the point of view of one physical 2508 endpoint. The first term identifies a physical gateway, the second 2509 is the transport address to which an RTP-encapsulated media stream is 2510 transmitted from that gateway, and the third is the transport address 2511 at which the gateway receives an RTP-encapsulated media stream. 2513 The first term MUST be present if the Media Gateway application 2514 controls more than one physical gateway. However, this term and the 2515 slash which separates it from the first transport address are 2516 optional if the Media Gateway application controls only a single 2517 physical gateway. 2519 The two transport addresses each have the form: 2521 : 2523 The representation of each address is in ASCII text rather than 2524 binary, to facilitate the representation of uni-directional flows. 2526 If one of the flows is not required/not present, the term 2527 representing that flow MUST consist of the minus ("-") character 2528 alone. 2530 Wildcarding of the network address and/or port number for either 2531 term is permitted, using the wildcard characters and their meanings 2532 as defined above. Typically the $ wild-card will be used, as when 2533 the Media Gateway Controller leaves it up to the Media Gateway itself 2534 to select an available port for an RTP connection (and report it back 2535 to the Media Gateway Controller). Examples of wildcarded RTP entity 2536 names are shown in the next section. 2538 Other Address Types 2540 The formats for representing the ATM, H323_SPEC, and SIP_SPEC types 2541 follow from already-defined standards. 2543 ATM 2545 For further study. 2547 H.323 2549 As defined in ITU-T Recommendation H.225.0, the far end call 2550 signalling address which an H.323 endpoint uses to start up a new 2551 H.323 call can have the following forms: 2552 * E.164 number 2553 * H.323 ID - an arbitrary Unicode string (maximum 256 characters) 2554 * a URL (maximum 512 ASCII characters) 2555 * an explicit transport address 2556 * an RFC822-compliant E-mail address (maximum 512 ASCII 2557 characters) 2558 * a {number type, number} structure (the PartyNumber structure), 2559 where the number type is private or public with several 2560 subdivisions within each of these broad categories. 2562 H.323 actually allows for multiple addresses which could be used as 2563 alternatives to start the call or to set up n x 64 kbit/s 2564 connections, but these possibilities are beyond the scope of the IPDC 2565 Reference for the H323-SPEC entity type. 2567 An IPDC implementation MUST represent the above possibilities within 2568 the Entity Name as follows: 2570 1. An E.164 number, a URL, and an RFC822-compliant E-mail 2571 address MUST be represented in their native format, as ASCII strings. 2573 2. A transport address MUST be represented in ASCII text in the 2574 form: 2575 : 2577 3. An H.323 ID MUST be represented according to the Unicode 2578 specification (ISO/IEC 10646-1). 2580 4. The {number type, number} structure MUST be represented by a 2581 combination of three ASCII strings separated by slashes ("/"). The 2582 first two strings convey the type of number, while the third consists 2583 of the digits of the actual number. The mapping between type of 2584 number and the representation in the IPDC Reference is as follows: 2585 * the first term consists of one of the two non-case-sensitive 2586 keywords PUBLIC or PRIVATE, as applicable. 2588 * for PUBLIC numbers, the second term consists of one of the 2589 following non-case-sensitive keywords as applicable: 2590 - UNKNOWN 2591 If used, number digits carry prefix indicating type of 2592 number according to national recommendations. 2593 - INTERNATIONAL 2594 - NATIONAL 2595 - SUBSCRIBER 2596 - ABBREVIATED 2597 Valid only for called party number at the outgoing access, 2598 switched circuit network substitutes appropriate number. 2600 * for PRIVATE numbers, the second term consists of one of these 2601 non-case-sensitive keywords as applicable: 2602 - UNKNOWN 2603 - Level2Regional 2604 - Level1Regional 2605 - pISNSpecific 2606 - LocalNumber 2607 - AbbreviatedNumber. 2609 SIP-SPEC 2611 The contents of the Entity Name field for a SIP_SPEC entity consist 2612 of the address specification required to start up a SIP session. 2614 5.3.1.3 Example Entity Name values for each reference type 2616 MEDIA_GATEWAY 2618 The optional entity name could be descriptive (e.g. "OtwaNASCtl") 2619 or simply a serial number (e.g. "061452"). 2621 PHYSICAL_GATEWAY 2623 As for the MEDIA_GATEWAY, except that the entity name MUST be 2624 present if the Media Gateway application controls more than one 2625 physical gateway. Examples: "OtwaNAS1", "061452-1". 2627 STATION 2629 As for the MEDIA_GATEWAY, except that the entity name MUST be 2630 present if the Media Gateway application controls more than one 2631 physical gateway/station. It is likely that STATION naming will 2632 be numeric because of the large potential number of stations 2633 within the span of control of a single Media Gateway application. 2635 EQUIPMENT_HOLDER 2637 Here the FORM: specification might come into play. For example, 2638 consider a card on a shelf within a physical gateway bay, and 2639 suppose that the card terminates multiple transmission facilities. 2640 Then the card is an entity of type EQUIPMENT_HOLDER, as is the 2641 shelf which contains it. 2643 One natural naming scheme would identify the shelf and card as 2644 individual terms of the naming string: 2646 "OtwaNAS1/3/17", 2647 meaning shelf 3, card 17 in physical gateway OtwaNAS1. 2649 On the other hand, in accordance with the BMLC form specification 2650 described below, the same entity might be named 2651 "FORM:BMLC/OtwaNAS1/3-17", 2652 since the "M" part of "BMLC" allows for one EQUIPMENT_HOLDER term 2653 only. 2655 In both of the examples, the gateway identifier term could be 2656 absent if the Media Gateway controls only one physical gateway. 2657 The examples then become: 2658 "3/17" 2659 and 2660 "FORM:BMLC/3-17" 2661 respectively. 2663 Finally, individual terms MAY be wild-carded. For example, using 2664 the first naming convention, one could refer to all cards on shelf 2665 3 using the Entity Name 2666 "3/*" 2667 with the EQUIPMENT_HOLDER type. In the BMLC form, this is not 2668 possible, but one could refer to all EQUIPMENT_HOLDER entities in 2669 the physical gateway using the string 2670 "FORM:BMLC/*" 2671 with the EQUIPMENT_HOLDER type. 2673 TRANSPORT_TERMINATION 2675 The naming of an entity of type Transport-Termination is a natural 2676 extension of the naming of the EQUIPMENT_HOLDER entity which 2677 supports it. Using the above example, DS-1 port 1 on card 17 of 2678 shelf 3 could have the following names: 2679 "OtwaNAS1/3/17/1" 2680 "3/17/1" 2682 The BMLC form convention has an explicit term (the "L" part) for 2683 the transmission facility name, so, using the previous example, 2684 the same facility could have the names: 2685 "FORM:BMLC/OtwaNAS1/3-17/1" 2686 "FORM:BMLC/3-17/1" 2688 Again, wild-carding is possible. For example, the Entity Name 2689 values 2690 "OtwaNAS1/*/*/*" 2691 or 2692 "*/*/*/*" 2693 in the first instance, or 2694 "FORM:BMLC/OtwaNAS1/*/*" 2695 or 2696 "FORM:BMLC/*/*" 2697 in the second instance refer along with the TRANSPORT_TERMINATION 2698 type code to all transmission terminations on the gateway. 2700 ACCESS_TERMINATION 2702 The ACCESS_TERMINATION name will be similar to that for the 2703 TRANSPORT_TERMINATION. 2705 TRUNK_TERMINATION 2707 The TRUNK_TERMINATION entity type specifies a single GSTN channel 2708 or a grouping of GSTN channels. Depending upon the type of 2709 circuit that is connected into the gateway and the physical 2710 architecture of the gateway, this entity type might have many 2711 vendor defined representations. To provide one possibility for 2712 common use, this draft suggests the "BMLC" format specification 2713 for trunk identification. The general form of a BMLC trunk 2714 identifier is given by: 2716 FORM:BMLC/[]/// 2719 Within this format, the FORM: part of the reference specifies the 2720 "BMLC" format. This form type indicates that the channels within 2721 a media gateway may be identified using a hierarchical structure 2722 of bay, module, line and channel. This hierarchical structure 2723 defines the following components: 2725 * "channel" is a single GSTN channel. In most trunk types this 2726 refers to a 64kb channel. 2728 * "line" identifies the TRANSPORT_TERMINATION over which the 2729 channel is being delivered. In most pieces of equipment this 2730 will represent the physical interface that terminates a T1 or 2731 T3. 2733 * "module" identifies a logical grouping of lines, an entity of 2734 type EQUIPMENT_HOLDER. In some pieces of equipment this may 2735 represent a circuit board that is plugged into the backplane 2736 and terminates multiple physical interfaces. In other pieces 2737 of equipment it may represent a shelf of line cards. 2739 * "bay" identifies the physical gateway that is being 2740 controlled by the control channel over which this message is 2741 being transmitted. The PHYSICAL_GATEWAY term MUST be omitted 2742 if the Media Gateway application controls only one physical 2743 gateway. 2745 Example uses of the trunk-term reference type using the BMLC 2746 format would be: 2748 "FORM:BMLC/module2/line4/channel21" 2749 "FORM:BMLC/2/4/21" 2750 "FORM:BMLC/2/4/$", indicating any one channel on module 2, 2751 line 4 2752 "FORM:BMLC/2/*/*", indicating all channels on all facilities 2753 supported by module 2 2754 "FORM:BMLC/*/*/*", indicating all channels on the gateway 2755 "FORM:BMLC/OtwaNAS01/*/*/*", indicating all channels on the 2756 specific physical gateway OtwaNAS01, where the Media Gateway 2757 handles more than one physical gateway. 2759 SIGNALLING_TERMINATION 2761 Naming of a SIGNALLING_TERMINATION entity is similar to that for a 2762 TRUNK_TERMINATION. 2764 DEVICE 2765 MODEM 2766 CONFERENCE_PORT 2767 FAX_PORT 2768 STREAM_SOURCE 2769 STREAM_RECORDER 2771 Naming conventions for these entities may be similar to those for 2772 the TRANSPORT_TERMINATION, or may omit the EQUIPMENT_HOLDER term. 2773 Examples of such conventions: 2775 [ /] / 2777 e.g " OtwaNAS01/21/6" for modem group 21, unit 6 on OtwaNAS01. 2779 [ /] / 2781 e.g. "4/$" refers to any one port on bridge 4 on the single 2782 physical gateway handled by the Media Gateway application. 2784 [ /] 2786 e.g. "AnnSrv1/MailPrompt" refers to the MailPrompt announcement on 2787 Announcement Server AnnSrv1, which is a physical gateway from the 2788 point of view of the IPDC control session. 2790 RTP_PORT 2792 Examples of RTP_PORT entity names would be: 2794 "OtwaVGW01/134.37.42.2:3003/134.37.32.5:3006" 2795 which denotes a bi-directional media stream transmitted from 2796 physical gateway OtwaVGW01 to port 134.37.42.2:3003, and 2797 transmitted from the far end to port 134.37.32.5:3006 on 2798 OtwaVGW01. 2800 "134.37.42.2:3003/134.37.32.5:$" 2801 which demonstrates wildcarding of the port number for the incoming 2802 media stream. 2804 "134.37.42.2:3003/-" 2805 which denotes a one-way outgoing media stream. 2807 ATM_SPEC 2809 For further study. 2811 H323_SPEC 2813 Examples of H323_SPEC entity names would be: 2815 "134.37.42.2:" 2816 which denotes the well-known call signalling port for H.323 at the 2817 given remote address. 2819 "Tom Taylor" 2820 which denotes an H.323 alias 2822 "16137654167" 2823 which denotes an E.164 address. 2825 SIP_SPEC 2827 Examples to come. 2829 6.0 Protocol Definition 2831 This section will describe how the base protocol works (or is at 2832 least an attempt to do so). 2834 6.1 DIAMETER Bootstrap Message 2835 DIAMETER provides a message that is used to indicate either an 2836 imminent reboot, or that a reboot has occurred. The DRI message MUST 2837 be sent to all known DIAMETER peers both previous to a reboot when 2838 possible as well as following a reboot. 2840 The Reboot-Type AVP is used to indicate the type of reboot associated 2841 with the DRI. When set to REBOOT_IMMINENT, all peers should be warned 2842 that any new DIAMETER requests sent to the issuer will probably not 2843 be received or processed. If a request MUST be sent it would be 2844 preferable to issue the request to an alternate peer if available. 2845 The message includes an optional Reboot-Time AVP that specifies an 2846 estimate of how long before the issuer is available to receive new 2847 DIAMETER messages. 2849 Upon reboot, the host MUST issue a DRI message with the Reboot-Type 2850 AVP set to REBOOTED. This is an indication that new DIAMETER messages 2851 may be sent to the transmitter of the DRI. 2853 Note that the Reboot-Time AVP is not required, and when present 2854 provides an estimate and should not be used as a hard value. In the 2855 case of a software implementation (server) running on a general 2856 purpose operating system, the Reboot-Time AVP will probably not be 2857 present since it is possible that the DIAMETER server has been 2858 stopped and it is not possible to know how long before (and if) it 2859 will be restarted. 2861 The DIAMETER Reboot-Ind message does not require a reply. The message 2862 is acknowledged using DIAMETER's reliable transport. 2864 6.2 Keepalive Exchange 2866 DIAMETER uses the Device-Watchdog-Ind message as a keepalive 2867 mechanism. DIAMETER entities that need to ensure that connectivity 2868 with a peer is not lost MAY use this mechanism. 2870 An IPDC/DIAMETER Client can use this mechanism to ensure that 2871 failover to an alternate server occurs even without any control 2872 traffic. Redundant DIAMETER Servers use this mechanism to identify 2873 when the primary server is no longer available. 2875 The DIAMETER Device-Watchdog-Ind message does not require a reply. 2876 The message is acknowledged using DIAMETER's reliable transport. 2878 6.3 Unrecognized Command Support 2880 The DIAMETER protocol provides a message that is used to inform a 2881 peer that a DIAMETER message was received with an unrecognized 2882 command. Suppose the following message is sent to a peer: 2884 ::= 2885 2886 2887 [] 2888 2889 2890 { || 2891 ::= 2898 2899 2900 2901 [] 2902 2903 2904 { || 2905 ::= 2910 2911 2912 2913 2914 2915 2916 2917 { || 2918 ::= 3001 3002 [] 3003 3004 3005 3007 6.6.2 Using Digital Signatures 3009 In the case of a simple peer to peer relationship the use of IPSEC is 3010 sufficient for data integrity and non-repudiation. However, there are 3011 instances where a peer must communicate with another peer through the 3012 use of a proxy server. IPSEC does not provide a mechanism to protect 3013 traffic when two peers must use an intermediary node to communicate 3014 at the application layer, therefore the Digital-Signature AVP MUST be 3015 used. 3017 The following diagram shows an example of a router initiating a 3018 DIAMETER message to DIA1. Once DIA1 has finished processing the 3019 message it adds its signature and forwards the message to the non- 3020 trusted DIA2 proxy server. If DIA2 needs to add or change any mutable 3021 AVPs it SHOULD add its digital signature before forwarding the 3022 message to DIA3. 3024 +------+ -----> +------+ -----> +------+ -----> +------+ 3025 | | | | | non- | | | 3026 |router+----------+ DIA1 +----------+trustd+----------+ DIA3 | 3027 | | | | | DIA2 | | | 3028 +------+ <----- +------+ <----- +------+ <----- +------+ 3030 Since some fields within the DIAMETER header will change "en route" 3031 towards the final DIAMETER destination, it is necessary to set the 3032 mutable fields to zero (0) for purposes of calculating the signature. 3033 The two mutable fields are the identifier and the length in the 3034 DIAMETER header. 3036 The following is an example of a message that includes end-to-end 3037 security: 3039 ::= 3040 3041 [] 3042 3043 3044 3046 Note that Digital Signatures only protect the DIAMETER header and the 3047 AVPs found prior to the digital signature. It is therefore possible 3048 to have AVPs which are unprotected because they follow the digital 3049 signature. 3051 The Data field of the Digital-Signature AVP contains the RSA/MD5 3052 signature algorithm as defined in [13]. 3054 6.6.3 Using Mixed Data Integrity AVPs 3056 The previous sections described the Integrity-Check-Vector and the 3057 Digital-Signature AVP. Since the ICV offers hop-by-hop integrity and 3058 the digital signature offers end to end integrity, it is possible to 3059 use both AVPs within a single DIAMETER message. 3061 The following diagram provides an example where DIAMETER Server 1 3062 (DIA1) communicates with DIA3 using Digital-Signatures through DIA2. 3063 In this example ICVs are used between DIA1 and DIA2 as well as 3064 between DIA2 and DIA3. 3066 3068 -----------------------------> 3069 3070 +------+ -----> +------+ -----> +------+ 3071 | | | | | | 3072 | DIA1 +----------+ DIA2 +----------+ DIA3 | 3073 | | | | | | 3074 +------+ +------+ +------+ 3076 Using the previous diagram, the following message would be sent 3077 between DIA1 and DIA2: 3079 ::= 3080 3081 [] 3082 3083 3084 3085 DIA2)> 3087 The following message would be sent between DIA2 and DIA3: 3089 ::= 3090 3091 [] 3092 3093 3094 3095 3096 3097 DIA3)> 3099 Note that in the above example messages the ICV AVP appears after the 3100 Digital-Signature AVP. This is necessary since DIA2 above removes the 3101 ICV AVP (DIA1->DIA2) and adds its own ICV AVP (DIA2->DIA3). The ICVs 3102 provide hop-by-hop security while the Digital-Signature provides 3103 integrity of the message between DIA1 and DIA3. 3105 3107 +------+ -----> +------+ -----> +------+ 3108 | | | | | | 3109 |router+----------+ DIA1 +----------+ DIA2 | 3110 | | | | | | 3111 +------+ <----- +------+ <----- +------+ 3113 There are cases, such as in remote access, where the device 3114 initiating the DIAMETER request does not have the processing power to 3115 generate Digital-Signatures as required by the protocol. In such an 3116 arrangement, there normally exists a first hop DIAMETER Server (DIA1) 3117 which acts as a proxy to relay the request to the final 3118 authenticating DIAMETER server (DIA2). It is valid for the first hop 3119 server to remove the Integrity-Check-Vector AVP inserted by the 3120 router and replace it with a Digital-Signature AVP. 3122 6.7 AVP Data Encryption 3124 DIAMETER supports two methods of encrypting AVP data. One is using a 3125 shared secret and the other is used with public keys. This feature 3126 can be used to encrypt sensitive data such as user ID's and 3127 passwords. The Encryption bits MUST NOT be set in the Command Type or 3128 Initialization-Vector AVPs. 3130 6.7.1 AVP Encryption with Shared Secrets 3132 This method of encrypting AVP data is the simplest to use and MUST be 3133 supported by all DIAMETER implementations. However, local policy MAY 3134 determine that the use of this mechanism is not permitted. 3136 The SS-Encrypted-Data bit MUST only be set if a shared secret exists 3137 between both DIAMETER peers. If the SS-Encrypted-Data bit is set in 3138 any DIAMETER AVP, the Initialization-Vector AVP MUST be present prior 3139 to the first encrypted AVP. 3141 The length of the AVP value to be encrypted is first encoded in the 3142 following Subformat: 3144 0 1 2 3 3145 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3147 | Length of ClearText Data | ClearText Data ... 3148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3149 | Padding ... 3150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3152 Length 3153 The Length field contains the length of the decrypted data. 3155 ClearText Data 3156 Data of AVP that is to be obscured. 3158 Padding 3159 Random additional octets used to obscure length of the ClearText 3160 Data. 3162 The resulting subformat MAY be padded to a multiple of 16 octets in 3163 length. For example, if the ClearText Data to be obscured is a string 3164 containing 6 characters (e.g. password 'foobar'), then 8 + n * 16 3165 octets of padding would be applied. Padding does NOT alter the value 3166 placed in the Length of the ClearText Data, only the length of the 3167 AVP itself. 3169 Next, An MD5 hash is performed on the concatenation of: 3170 * the two octet Command Code of the AVP 3171 * the shared authentication secret 3172 * an arbitrary length random vector. 3174 The value of the random vector used in this hash is passed in the 3175 Data field of a Initialization-Vector AVP. This Initialization- 3176 Vector AVP MUST be placed in the message by the sender before any 3177 hidden AVPs. The same Initialization-Vector may be used for more than 3178 one hidden AVP in the same message. If a different Initialization- 3179 Vector is used for the hiding of subsequent AVPs then a new 3180 Initialization-Vector AVP MUST be placed before the first AVP to 3181 which it applies. 3183 The MD5 hash value is then XORed with the first 16 octet or less 3184 segment of the AVP Subformat and placed in the Data field of the AVP. 3185 If the AVP Subformat is less than 16 octets, the Subformat is 3186 transformed as if the Value field had been padded to 16 octets before 3187 the XOR, but only the actual octets present in the Subformat are 3188 modified, and the length of the AVP is not altered. 3190 If the Subformat is longer than 16 octets, a second one-way MD5 hash 3191 is calculated over a stream of octets consisting of the shared secret 3192 followed by the result of the first XOR. That hash is XORed with the 3193 second 16 octet or less segment of the Subformat and placed in the 3194 corresponding octets of the Data field of the AVP. 3196 If necessary, this operation is repeated, with each XOR result being 3197 used along with the shared secret to generate the next hash to XOR 3198 the next segment of the value with. This technique results in the 3199 content of the AVP being obscured, although the length of the AVP is 3200 still known. 3202 On receipt, the Initialization-Vector is taken from the last 3203 Initialization-Vector AVP encountered in the message prior to the AVP 3204 to be decrypted. The above process is then reversed to yield the 3205 original value. For more details on this hiding method, consult 3206 RFC2138 [14]. 3208 Please note that in the case where the DIAMETER message needs to be 3209 processed by an intermediate non-trusted DIAMETER server (also known 3210 as a proxy server, depicted as DIA2 in the figure below) the AVP 3211 needs to be decrypted using Shared-Secret-1 and re-encrypted by DIA2 3212 using Shared-Secret-2. 3214 (Shared-Secret-1) (Shared-Secret-2) 3215 +------+ -----> +------+ ------> +------+ 3216 | | | | | | 3217 | DIA1 +-------------------+ DIA2 +-------------------+ DIA3 | 3218 | | | | | | 3219 +------+ +------+ +------+ 3221 Unfortunately in this case the non-trusted server DIA2 has access to 3222 sensitive information (such as a password). 3224 6.7.2 AVP Encryption with Public Keys 3226 AVP encryption using public keys is much more complex than the 3227 previously decribed method, yet it is desirable to use it in cases 3228 where the DIAMETER message will be processed by an untrusted 3229 intermediate node (proxy). 3231 Public Key encryption SHOULD be supported, however it is permissible 3232 or a low powered device initiating the DIAMETER message to use shared 3233 secret encryption with the first hop (proxy) DIAMETER server, which 3234 would decrypt and encrypt using the Public Key method. 3236 The PK-Encrypted-Data bit MUST only be set if the final DIAMETER host 3237 is aware of the sender's public key. This information can be relayed 3238 in three different methods as described in section 6.8. 3240 The AVP is encrypted in the method described in [13]. 3242 6.8 Public Key Cryptography Support 3244 A DIAMETER peer's public key is required in order to validate a 3245 message which includes the the Digital-Signature AVP. There are three 3246 possibilities on retrieving public keys: transmission of the X.509 3247 certificate itself,transmission of a URL pointing to the actual X.509 3248 certificate, and static public key configuration. These 3249 possibilities are discussed in the next two sections. 3251 6.8.1 X509-Certificate 3253 A message which includes a Digital-Signature MAY include the X509- 3254 Certificate AVP. Given the size of a typical certificate, this is 3255 very wasteful and in most cases DIAMETER peers would cache such 3256 information in order to minimize per packet processing overhead. 3258 It is however valid for a DIAMETER host to provide a message that 3259 includes the X509-Certificate-URL to provide a pointer to its 3260 certificate. Upon receiving such a message a DIAMETER host MAY 3261 choose to retrieve the certificate if it is not locally cached. Of 3262 course the process of retrieving and validating a certificate is 3263 lengthy and will require the initiator of the message to retransmit 3264 the request. However once cached the certificate can be used until it 3265 expires. 3267 6.8.2 Static Public Key Configuration 3269 Given that using certificates requires a PKI infrastructure which is 3270 very costly, it is also possible to use this technology by locally 3271 configuring DIAMETER peers' public keys. Note that in a network 3272 involving many DIAMETER proxies this may not scale well. 3274 7.0 References 3276 [1] Cuervo et alia, "SS7-Internet Interworking - Architectural 3277 Framework", draft-greene-ss7-arch-frame-00.txt, July 1998. 3279 [2] Calhoun, Rubens, "DIAMETER Base Protocol", draft-calhoun- 3280 diameter-04.txt, July 1998. 3282 [3] Skran, "IPDC Architectural Framework", draft-skran-IPDC- 3283 frame-00.txt, August 1998. 3285 [4] Dugan, "IPDC Connection Control", draft-dugan-IPDC-conn- 3286 00.txt, August 1998. 3288 [5] Elliott, "IPDC Media Control", draft-elliott-IPDC-media- 3289 00.txt, August 1998. 3291 [6] Bell, "IPDC Signaling Support", draft-bell-IPDC-sig-00.txt, 3292 August 1998. 3294 [7] Pickett, "IPDC Device Management", draft-pickett-IPDC-mgmt- 3295 00.txt, August 1998. 3297 [8] Reynolds, Postel, "Assigned Numbers", RFC 1700, October 1995. 3299 [9] Rivest, Dusse, "The MD5 Message-Digest Algorithm", RFC 1321, 3300 April 1992. 3302 [10] Kaufman, Perlman, Speciner, "Network Security: Private 3303 Communications in a Public World", Prentice Hall, March 1995, ISBN 3304 0-13-061466-1. 3306 [11] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for Message 3307 Authentication", RFC 2104, January 1997. 3309 [12] Aboba, Beadles, "Network Address Identifier", Internet-Draft, 3310 draft-ietf-roamops-nai-11.txt, July 1998. 3312 [13] Kaliski, "PKCS #1: RSA Encryption Version 1.5", RFC 2313, March 3313 1998. 3315 [14] Rigney, et alia, "RADIUS", RFC 2138, April 1997 3317 [15] Calhoun, Zorn, Pan, "DIAMETER Framework", Internet-Draft, 3318 draft-calhoun-DIAMETER-framework-00.txt, May 1998 3320 8.0 Rights and Permissions 3322 The contributors to this document are listed in the acknowledgement 3323 section of this document. All contributors to this document and the 3324 organizations we represent grant an unlimited perpetual, non- 3325 exclusive, royalty-free, world-wide right and license to any party 3326 under the copyrights in the contribution. This license includes the 3327 right to copy, publish and distribute the contribution in any way, 3328 and to prepare derivative works that are based on or incorporate all 3329 or part of the contribution, the license to such derivative works to 3330 be of the same scope as the license of the original contribution. 3331 The contributors grant permission to reference the names of the 3332 contributors and of the organizations we represent. We agree that no 3333 information in the contribution is confidential and that the any 3334 party may freely disclose any information in the contribution. 3336 The contributors to this document represent that the organizations we 3337 represent jointly own any intellectual property associated with this 3338 document. The contributors to this document will grant any party a 3339 perpetual, non-exclusive, royalty-free, world-wide right to 3340 implement, use and distribute the technology or works when 3341 implementing, using or distributing technology based upon the 3342 specific specification. 3344 The contributors represent that we have disclosed the existence of 3345 any proprietary or intellectual property rights in the contribution 3346 that are reasonably and personally known to the contributors. The 3347 contributors do not represent that we personally know of all 3348 potentially pertinent proprietary and intellectual property rights 3349 owned or claimed by the organizations we represent (if any) or third 3350 parties. 3352 The contributors represent that there are no limits to the 3353 contributors' ability to make the grants, acknowledgments and 3354 agreements above that are reasonably and personally known to the 3355 contributors. 3357 9.0 Acknowledgements 3359 The DIAMETER base protocol specification [2] was authored by Pat 3360 Calhoun of Sun Microsystems, Inc. and Allan C. Rubens of Ascend 3361 Communications. [2] acknowledges the following people for their 3362 contribution in the development of the DIAMETER protocol: 3363 Bernard Aboba, Jari Arkko, William Bulley, Daniel C. Fox, Lol 3364 Grant, Nancy Greene, Peter Heitman, Ryan Moats, Victor Muslin, 3365 Kenneth Peirce, Sumit Vakil, John R. Vollbrecht, Jeff Weisberg and 3366 Glen Zorn. 3368 [2] also acknowledges a major debt to L2TP for details of the 3369 DIAMETER protocol. 3371 The following people contributed to the development of the IPDC 3372 proposal and are signatories to the declaration regarding 3373 intellectual property rights in the previous section: 3375 Ilya Akramovich, Bob Bell, Dan Brendes, Peter Chung, John Clark, 3376 Russ Dehlinger, Andrew Dugan, Ike Elliott, Cary Fitzgerald, Jan 3377 Gronski, Tom Hess, Geoff Jordan, Tony Lam, Shawn Lewis, Dave 3378 Mazik, Alan Mikhak, Pete O'Connell, Scott Pickett, Shyamal Prasad, 3379 Eric Presworsky, Paul Richards, Dale Skran, Louise Spergel, David 3380 Sprague, Raj Srinivasan, Tom Taylor, and Michael Thomas. 3382 Special acknowledgement is due to Ike Elliott for the long hours he 3383 spent moderating the meetings of the IPDC Technical Advisory 3384 Committee. 3386 10.0 Authors' Addresses 3388 Questions about this memo can be directed to: 3390 P. Tom Taylor 3391 Nortel (Northern Telecom) 3392 M/S 097, SKY, 3393 P.O. Box 3511, Station C, 3394 Ottawa, Ontario, 3395 Canada 3397 Phone: 1-613-765-4167 3398 Fax: 1-613-765-7236 3399 E-mail: taylor@nortel.ca 3401 Pat R. Calhoun 3402 Technology Development 3403 Sun Microsystems, Inc. 3404 15 Network Circle 3405 Menlo Park, California, 94025 3406 USA 3408 Phone: 1-650-786-7733 3409 Fax: 1-650-786-6445 3410 E-mail: pcalhoun@eng.sun.com 3412 Allan C. Rubens 3413 Ascend Communications 3414 1678 Broadway 3415 Ann Arbor, MI 48105-1812 3416 USA 3418 Phone: 1-734-761-6025 3419 E-Mail: acr@del.com 3421 Appendix A: Acknowledgment Timeouts 3423 DIAMETER uses sliding windows and timeouts to provide flow-control 3424 across the underlying medium and to perform efficient data buffering 3425 to keep two DIAMETER peers' receive window full without causing 3426 receive buffer overflow. DIAMETER requires that a timeout be used to 3427 recover from dropped messages. 3429 When the timeout for a peer expires, the previously transmitted 3430 message with Ns value equal to the highest in-sequence value of Nr 3431 received from the peer is retransmitted. The receiving peer does not 3432 advance its value for the receive sequence number state, Sr, until it 3433 receives a message with Ns equal to its current value of Sr. 3435 This rule assues that all subsequent acknowledgements to this peer 3436 will contain an Nr value equal to the Ns value of the first missing 3437 message until a message with the missing Ns value is received. 3439 The exact implementation of the acknowledgment timeout is vendor- 3440 specific. It is suggested that an adaptive timeout be implemented 3441 with backoff for flow control. The timeout mechanism proposed here 3442 has the following properties: 3444 * Independent timeouts for each peer. A device will have to 3445 maintain and calculate timeouts for every active peer. 3447 * An administrator-adjustable maximum timeout, MaxTimeOut, unique 3448 to each device. 3450 * An adaptive timeout mechanism that compensates for changing 3451 throughput. To reduce packet processing overhead, vendors may 3452 choose not to recompute the adaptive timeout for every received 3453 acknowledgment. The result of this overhead reduction is that the 3454 timeout will not respond as quickly to rapid network changes. 3456 * Timer backoff on timeout to reduce congestion. The backed-off 3457 timer value is limited by the configurable maximum timeout value. 3458 Timer backoff is done every time an acknowledgment timeout occurs. 3460 In general, this mechanism has the desirable behavior of quickly 3461 backing off upon a timeout and of slowly decreasing the timeout value 3462 as packets are delivered without timeouts. 3464 A.1 Calculating Adaptive Acknowledgment Timeout 3466 We still must decide how much time to allow for acknowledgments to 3467 return. If the timeout is set too high, we may wait an unnecessarily 3468 long time for dropped packets. If the timeout is too short, we may 3469 time out just before the acknowledgment arrives. The acknowledgment 3470 timeout should also be reasonable and responsive to changing network 3471 conditions. 3473 The suggested adaptive algorithm detailed below is based on the TCP 3474 1989 implementation and is explained in Richard Steven's book TCP/IP 3475 Illustrated, Volume 1 (page 300). 'n' means this iteration of the 3476 calculation, and 'n-1' refers to values from the last calculation. 3478 DIFF[n] = SAMPLE[n] - RTT[n-1] DEV[n] 3479 = DEV[n-1] + (beta * (|DIFF[n]| - DEV[n-1])) RTT[n] 3480 = RTT[n-1] + (alpha * DIFF[n]) ATO[n] 3481 = MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut) 3483 DIFF represents the error between the last estimated round-trip time 3484 and the measured time. DIFF is calculated on each iteration. 3486 DEV is the estimated mean deviation. This approximates the standard 3487 deviation. DEV is calculated on each iteration and stored for use in 3488 the next iteration. Initially, it is set to 0. 3490 RTT is the estimated round-trip time of an average packet. RTT is 3491 calculated on each iteration and stored for use in the next 3492 iteration. Initially, it is set to PPD. 3494 ATO is the adaptive timeout for the next transmitted packet. ATO is 3495 calculated on each iteration. Its value is limited, by the MIN 3496 function, to be a maximum of the configured MaxTimeOut value. 3498 Alpha is the gain for the round trip estimate error and is typically 3499 1/8 (0.125). 3501 Beta is the gain for the deviation and is typically 1/4 (0.250). 3503 Chi is the gain for the timeout and is typically set to 4. 3505 To eliminate division operations for fractional gain elements, the 3506 entire set of equations can be scaled. With the suggested gain 3507 constants, they should be scaled by 8 to eliminate all division. To 3508 simplify calculations, all gain values are kept to powers of two so 3509 that shift operations can be used in place of multiplication or 3510 division. 3512 The above calculations are carried out each time an acknowledgment is 3513 received for a packet that was not retransmitted (no timeout occurs). 3515 A.2 Flow Control: Adjusting for Timeout 3517 This section describes how the calculation of ATO is modified in the 3518 case where a timeout does occur. When a timeout occurs, the timeout 3519 value should be adjusted rapidly upward. Although DIAMETER messages 3520 are not retransmitted when a timeout occurs, the timeout should be 3521 adjusted up toward a maximum limit. To compensate for shifting 3522 internetwork time delays, a strategy must be employed to increase the 3523 timeout when it expires. A simple formula called Karn's Algorithm is 3524 used in TCP implementations and may be used in implementing the 3525 backoff timers for the LNS or the LAC. Notice that in addition to 3526 increasing the timeout, we also shrink the size of the window as 3527 described in the next section. Karn's timer backoff algorithm, as 3528 used in TCP, is: 3530 NewTIMEOUT = delta * TIMEOUT 3532 Adapted to our timeout calculations, for an interval in which a 3533 timeout occurs, the new timeout interval ATO is calculated as: 3535 RTT[n] = delta * RTT[n-1] DEV[n] 3536 = DEV[n-1] ATO[n] 3537 = MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut) 3539 In this modified calculation of ATO, only the two values that 3540 contribute to ATO and that are stored for the next iteration are 3541 calculated. RTT is scaled by delta, and DEV is unmodified. DIFF is 3542 not carried forward and is not used in this scenario. A value of 2 3543 for Delta, the timeout gain factor for RTT, is suggested. 3545 Appendix B: Examples of sequence numbering 3547 Although sequence numbers serve distinct purposes for control and 3548 data messages, both types of messages use identical techniques for 3549 assigning sequence numbers. This appendix shows several common 3550 scenarios, and illustrates how sequence number state progresses and 3551 is interpreted. 3553 B.1: Lock-step session establishment 3555 In this example, a DIAMETER device establishes communication with a 3556 peer, with the exchange involving each side alternating in sending 3557 messages. This example is contrived, in that the final 3558 acknowledgement in the example is typically the acknowledgement which 3559 would have been included in the processing of the Device-Watchdog- 3560 Ind. 3562 DIAMETER Host A DIAMETER Host B 3563 -> Device-Reboot-Ind 3564 Nr: 0, Ns: 0 3566 (Header-only) <- 3567 Nr: 1, Ns: 0 3569 -> Device-Watchdog-Ind 3570 Nr: 1, Ns: 1 3572 (delay) 3574 (Header-only) <- 3575 Nr: 2, Ns: 1 3577 B.2: Multiple packets acknowledged 3579 This example shows a flow of packets from DIAMETER Host B to Host A, 3580 with Host A having no traffic of its own. Host B is waiting 1/4 of 3581 its timeout interval, and then acknowledging all packets seen since 3582 the last interval. 3584 DIAMETER Host A DIAMETER Host B 3585 (previous packet flow precedes this) 3587 -> (Header-only) 3588 Nr: 7000, Ns: 1000 3589 (Message with AVPs) <- 3590 Nr: 1000, Ns: 7000 3591 (Message with AVPs) <- 3592 Nr: 1000, Ns: 7001 3593 (Message with AVPs) <- 3594 Nr: 1000, Ns: 7002 3596 (Host A's timer indicates it should acknowledge pending traffic) 3598 -> (Header-only) 3599 Nr: 7003, Ns: 1000 3601 B.3: Lost packet with retransmission 3603 Host A attempts to communicate with Host B. The Device-Reboot-Ind is 3604 lost and must be retransmitted by Host B. 3606 DIAMETER Host A DIAMETER Host B 3607 -> Device-Reboot-Ind 3608 Nr: 0, Ns: 0 3610 (packet lost) Device-Reboot-Ind <- 3611 Nr: 1, Ns: 0 3613 (pause; Host A's timer started first, so fires first) 3615 -> Device-Reboot-Ind 3616 Nr: 0, Ns: 0 3618 (Host B realizes it has already seen this packet) 3619 (Host B might use this as a cue to retransmit, as in this example) 3621 Device-Reboot-Ind <- 3622 Nr: 1, Ns: 0 3624 -> Device-Watchdog-Ind 3625 Nr: 1, Ns: 1 3627 (delay) 3629 (Header-only) <- 3630 Nr: 2, Ns: 0 3632 ____________________