idnits 2.17.1 draft-schoenw-sming-diameter-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 7 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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.) -- The document date (November 30, 2000) is 8548 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-07) exists of draft-irtf-nmrg-sming-04 ** Downref: Normative reference to an Experimental draft: draft-irtf-nmrg-sming (ref. '1') == Outdated reference: A later version (-18) exists of draft-calhoun-diameter-17 -- Possible downref: Normative reference to a draft: ref. '2' ** Obsolete normative reference: RFC 2234 (ref. '4') (Obsoleted by RFC 4234) Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Schoenwaelder 3 Internet-Draft TU Braunschweig 4 Expires: May 31, 2001 November 30, 2000 6 SMIng Mappings to DIAMETER 7 draft-schoenw-sming-diameter-00 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 To view the entire list of Internet-Draft Shadow Directories, see 25 http://www.ietf.org/shadow.html. 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/iid-abstracts.txt 30 This Internet-Draft will expire on May 31, 2001. 32 Copyright Notice 34 Copyright (C) The Internet Society (2000). All Rights Reserved. 36 Abstract 38 This memo presents an SMIng language extension that supports the 39 mapping of SMIng definitions of classes and their attributes to 40 DIAMETER AVPs and messages. 42 Table of Contents 44 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 45 2. DIAMETER Base Types . . . . . . . . . . . . . . . . . . . . 3 46 3. SMIng Data Type Mappings . . . . . . . . . . . . . . . . . . 4 47 4. The diameter Extension Statement . . . . . . . . . . . . . . 4 48 4.1 The vendor Statement . . . . . . . . . . . . . . . . . . . . 4 49 4.2 The avp Statement . . . . . . . . . . . . . . . . . . . . . 4 50 4.2.1 The avp's code Statement . . . . . . . . . . . . . . . . . . 5 51 4.2.2 The avp's implements Statement . . . . . . . . . . . . . . . 5 52 4.3 The msg Statement . . . . . . . . . . . . . . . . . . . . . 5 53 4.3.1 The msg's code Statement . . . . . . . . . . . . . . . . . . 5 54 4.3.2 The msg's includes Statement . . . . . . . . . . . . . . . . 5 55 4.3.3 The msg's status Statement . . . . . . . . . . . . . . . . . 5 56 4.3.4 The msg's description Statement . . . . . . . . . . . . . . 5 57 5. TUBS-IBR-SMING-DIAMETER-EXT . . . . . . . . . . . . . . . . 6 58 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 8 59 7. Security Considerations . . . . . . . . . . . . . . . . . . 14 60 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 61 References . . . . . . . . . . . . . . . . . . . . . . . . . 14 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . 14 63 Full Copyright Statement . . . . . . . . . . . . . . . . . . 15 65 1. Introduction 67 This memo presents an SMIng [1] language extension that supports the 68 mapping of SMIng definitions of classes and their attributes to 69 DIAMETER [2] AVPs and messages. 71 SMIng is an object-oriented data definition language which builds on 72 concepts that have been successfully used over the last decade 73 within the SNMP management framework. The SMIng language is 74 independent of management protocols and applications. Protocol 75 mappings to additional protocols can be defined as SMIng language 76 extensions. 78 There are several advantages in adopting SMIng as the data 79 definition language for DIAMETER: 80 1. Using SMIng allows to reuse data definitions from other areas. 81 For example, it is possible to import definitions for common 82 data types such as dates, times, IP addresses, IP filter etc. 83 from common modules. 84 2. Using common data definitions across several management 85 protocols simplifies the development of applications or network 86 elements that have to interface with equipment supporting 87 multiple protocols. 88 3. A common data definition language encourages consistency across 89 technology domains which reduces software complexity for 90 products that need to operate on data definitions which may be 91 manipulated with different protocols. 92 4. Adopting SMIng enables authors to reuse authoring tools to e.g. 93 verify the correctness of their data definitions. 94 5. SMIng features a versioning mechanism (via status assignments), 95 a naming and import mechanism, and a precise language definition 96 which puts well-defined bounds on syntactic constructs such as 97 identifiers or value notations. 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [3]. 103 2. DIAMETER Base Types 105 The DIAMETER protocol should be modified to support AVPs that encode 106 the following primitive base types: Integer32, Unsigned32, 107 Integer64, Unsigned64, Float32, Float64, Float128, and OctetString 108 as specified in [1]. In addition, the DIAMETER protocol should 109 support a compound type which contains an ordered list of AVPs. The 110 AVPs in the compound type are ordered. 112 3. SMIng Data Type Mappings 114 The SMIng base types are mapped to the DIAMETER base types according 115 to the following table: 117 SMIng Data Type DIAMETER Base Type 118 --------------- ------------------ 119 OctetString OctetString 120 Integer32 Integer32 121 Integer64 Integer64 122 Unsigned32 Unsigned32 123 Unsigned64 Unsigned64 124 Float32 Float32 125 Float64 Float64 126 Float128 Float128 127 Enumeration Integer32 128 Bits OctetString 130 Note that the SMIng base type Pointer is not mapped to any DIAMETER 131 base type. 133 Classes are mapped to the compound DIAMETER base type. Each 134 primitive attribute of a given class is represented according to the 135 mapping table above and is encapsulated in the compound base type. 137 4. The diameter Extension Statement 139 The `diameter' statement is the main statement of the DIAMETER 140 mapping specification. It gets one arguments: a statement block that 141 contains all details of the DIAMETER mapping. A single SMIng module 142 must not contain more than one 'diameter' statement. 144 4.1 The vendor Statement 146 The `vendor' statement, which must be present if the definition is 147 not part of an IETF standard, gets one argument which identifies the 148 enterprise responsible for this definition. The value MUST be an 149 IANA assigned enterprise number. 151 4.2 The avp Statement 153 The `avp' statement is used to define an AVP. The avp statement gets 154 two arguents: an upper-case AVP identifier and a statement block 155 that holds detailed information about the AVP. 157 See the `avpStatement' rule of the SMIng grammar (Section 5) for the 158 formal syntax of the 'avp' statement. 160 4.2.1 The avp's code Statement 162 The avp's `code' statement, which must be present, gets one argument 163 which specifies the code used to identify the AVP. 165 4.2.2 The avp's implements Statement 167 The avp's `implements' statement, which must be present exactly 168 once, gets one argument: the identifier of an SMIng class which is 169 implemented by this AVP. 171 4.3 The msg Statement 173 The `msg' statement is used to define a DIAMETER message. The msg 174 statement gets two arguents: an upper-case message identifier and a 175 statement block that holds detailed information about the message. 177 See the `msgStatement' rule of the SMIng grammar (Section 5) for the 178 formal syntax of the 'msg' statement. 180 4.3.1 The msg's code Statement 182 The msg's `code' statement, which must be present, gets one argument 183 which specifies the code used to identify the message. 185 4.3.2 The msg's includes Statement 187 The msg's `includes' statement, which may be present zero, one or 188 multiple times, gets one argument which specifies an AVP which must 189 be included in the message. 191 4.3.3 The msg's status Statement 193 The msg's `status' statement, which need not be present, gets one 194 argument which is used to specify whether this message definition is 195 current or historic. The value `current' means that the definition 196 is current and valid. The value `obsolete' means the definition is 197 obsolete and should not be implemented and/or can be removed if 198 previously implemented. While the value `deprecated' also indicates 199 an obsolete definition, it permits new/continued implementation in 200 order to foster interoperability with older/existing 201 implementations. 203 If the `status' statement is omitted, the status value `current' is 204 implied. 206 4.3.4 The msg's description Statement 208 The msg's `description' statement, which must be present, gets one 209 argument which is used to specify a high-level textual description 210 of this message. 212 It is RECOMMENDED to include all semantics and purposes of this 213 message. 215 5. TUBS-IBR-SMING-DIAMETER-EXT 217 The grammar of the DIAMETER mapping SMIng extension conforms to the 218 Augmented Backus-Naur Form (ABNF)[4]. It is included in the abnf 219 statement of the `diameter' SMIng extension definition in the 220 TUBS-IBR-SMING-DIAMETER-EXT module below. 222 module TUBS-SMING-DIAMETER-EXT { 224 organization "Technical University of Braunschweig"; 226 contact "Juergen Schoenwaelder 228 TU Braunschweig 229 Bueltenweg 74/75 230 38106 Braunschweig 231 Germany 233 Phone: +49 531 391-3289 234 EMail: schoenw@ibr.cs.tu-bs.de"; 236 description "SMIng extension for DIAMETER."; 238 revision { 239 date "2000-11-24"; 240 description "Initial version, published as RFC XXXX."; 241 }; 243 extension snmp { 245 description 246 "The diameter statement maps SMIng definitions to 247 DIAMETER AVPs and messages."; 248 abnf 249 ";; 250 ;; sming-diameter.abnf -- Grammar of DIAMETER mappings in ABNF 251 ;; notation (RFC 2234). 252 ;; 253 ;; @(#) $Id$ 254 ;; 255 ;; Copyright (C) The Internet Society (2000). All Rights Reserved. 256 ;; 257 ;; 258 ;; Statement rules. 259 ;; 261 diameterStatement = diameterKeyword optsep 262 "{" stmtsep 263 *1(vendorStatement stmtsep) 264 *(avpStatement stmtsep) 265 *(msgStatement stmtsep) 266 "}" optsep ";" 268 vendorStatement = vendorKeyword sep decimalNumber optsep ";" 270 avpStatement = avpKeyword sep ucIdentifier optsep 271 "{" stmtsep 272 codeStatement stmtsep 273 implementsStatement stmtsep 274 *1(statusStatement stmtsep) 275 "}" optsep ";" 277 msgStatement = msgKeyword sep ucIdentifier optsep 278 "{" stmtsep 279 codeStatement stmtsep 280 *(includesStatement stmtsep) 281 *1(statusStatement stmtsep) 282 descriptionStatement stmtsep 283 "}" optsep ";" 285 codeStatement = codeKeyword sep decimalNumber optsep ";" 287 implementsStatement = implementsKeyword sep qucIdentifier optsep ";" 289 includesStatement = includesKeyword sep qucIdentifier optsep ";" 291 ;; 292 ;; Statement keywords. 293 ;; 295 diameterKeyword = %x64 %x69 %x61 %x6D %x65 %x74 %x65 %x72 296 vendorKeyword = %x76 %x65 %x6E %x64 %x6F %x72 297 avpKeyword = %x61 %x76 %x70 298 msgKeyword = %x6D %x73 %x67 299 codeKeyword = %x63 %x6F %x64 %x65 300 implementsKeyword = %x69 %x6D %x70 %x6C %x65 %x6D %x65 %x6E %x74 %x73 301 includesKeyword = %x69 %x6E %x63 %x6C %x75 %x64 %x65 %x73 303 ;; 304 ;; EOF 305 ;; 306 "; 308 }; 310 }; 312 6. Example 314 The following example demonstrates how the DIAMETER AVPs and 315 messages defined in [2] can be defined using the SMIng and the SMIng 316 `diameter' extension presented in this memo. 318 module TUBS-SMING-DIAMETER { 320 import IRTF-NMRG-SMING (Utf8String); 321 import IRTF-NMRG-SMING-INET (InetNetworkEndpoint); 322 import TUBS-DIAMETER-EXT (diameter); 324 organization "Technical University of Braunschweig"; 326 contact "Juergen Schoenwaelder 328 TU Braunschweig 329 Bueltenweg 74/75 330 38106 Braunschweig 331 Germany 333 Phone: +49 531 391-3289 334 EMail: schoenw@ibr.cs.tu-bs.de"; 336 description "SMIng core definitions for DIAMETER."; 338 revision { 339 date "2000-11-24"; 340 description "Initial version, published as RFC XXXX."; 341 }; 343 // international domain names (?) 344 typedef NetworkAccessIdentifier { 345 type Utf8String; 346 description 347 "A Network Address Identifier as specified in RFC 2486."; 348 reference 349 "RFC 2486"; 350 }; 351 // this really belongs into an IANA module 352 typedef DiameterExtension { 353 type Enumeration (none(0), 354 nasreq(1), 355 security(2), 356 resmgmt(3), 357 mobileip(4), 358 accouting(5)); 359 description 360 "This type identifies an extension of the DIAMETER base 361 protocol. Assignments are made by IANA."; 362 }; 364 typedef RandomString { 365 type OctetString (16..65535); 366 description 367 "This type contains a random value of at least 128 bits."; 368 }; 370 typedef SecondsSince2000 { 371 type Unsigned32; 372 description 373 "The number of seconds since 1st January 2000, 00:00 UTC."; 374 }; 376 // this really belongs into an IANA module 377 typedef HashAlgorithm { 378 type Enumeration (none(0), md5(1)); 379 description 380 "Identifies a hash algorithm."; 381 }; 383 typedef KeyId { 384 type Unsigned32; 385 description 386 "This type represents a generic key identifier, which is 387 used to identify the keying information for a security 388 mechanism."; 389 }; 391 typedef MessageAuthenticationCode { 392 type OctetString; 393 description 394 "The message authentication code (MAC) for a 395 given message."; 396 }; 398 // 399 // AVP classes 400 // 402 class IntegrityCheck { 403 attribute HashAlgorithm alg { 404 description "Identifies the crypto algorithm."; 405 }; 406 attribute KeyId key { 407 description "Identifies the security key."; 408 }; 409 attribute MessageAuthenticationCode mac { 410 description "The fingerprint of the message."; 411 }; 412 description 413 "This class contains the information needed to 414 authenticate a message and to check its integrity 415 on a hop-by-hop basis."; 416 }; 418 class Nonce { 419 attribute RandomString nonce { 420 description "A random byte string used as a nonce."; 421 }; 422 description 423 "The Nonce class MUST be present prior to the 424 IntegrityCheck class within a message and is used 425 to ensure randomness within a message. Some crypto 426 algorithms are known to have weaknesses if a random 427 value is not found early within the plaintext, 428 therefore it is recommended that the Nonce class be 429 added early in a message if possible."; 430 }; 432 class HostName { 433 attribute NetworkAccessIdentifier name { 434 description "A network access identifier which identifies 435 a sender's identity."; 436 }; 437 description 438 "The HostName class is used to inform a DIAMETER peer of 439 the sender's identity. All DIAMETER messages MUST 440 include the HostName class. Note that the HostName 441 class may resolve to more than one address as the 442 DIAMETER peer may support more than one address."; 443 }; 444 }; 446 class VendorName { 447 attribute Utf8String name { 448 description "The name of the vendor."; 450 }; 451 description 452 "The VendorName class is used to inform a DIAMETER peer 453 of the vendor name of the DIAMETER device. This MAY 454 be used in order to know which vendor specific 455 attributes may be sent to the peer. It is also 456 envisioned that the combination of the VendorName 457 and the FirmwareRevision classes MAY provide very 458 useful debugging information."; 459 }; 461 class FirmwareRevision { 462 attribute Unsigned32 revision { 463 description "A revision number."; 464 }; 465 description 466 "The FirmwareRevision class is used to inform a DIAMETER 467 peer of the firmware revision of the issuing device. 469 For devices that do not have a firmware revision (general 470 purpose computers running DIAMETER software modules, 471 for instance), the revision of the DIAMETER software 472 module may be reported instead."; 473 }; 475 class ExtensionId { 476 attribute DiameterExtension extension { 477 description "Identifies a Diameter extension."; 478 }; 479 description 480 "The ExtensionId AVP identifies a specific DIAMETER 481 extension. This AVP is used in the DeviceRebootInd 482 message in order to inform the peer what extensions 483 are locally supported. 485 Each DIAMETER extension draft MUST have an IANA 486 assigned extension Idenfier. The base protocol does 487 not require an ExtensionId since its support is 488 mandatory. 490 There MAY be more than one ExtensionId AVP within a 491 DIAMETER DeviceRebootInd message."; 492 }; 494 // The description should be more generic. 495 class HostIPAddress { 496 attribute InetNetworkEndpoint endpoint { 497 description "Denotes the sender's IP address."; 498 }; 499 description 500 "The HostIPAddress class is used to inform a DIAMETER 501 peer of the sender's IP address. All source 502 addresses that a DIAMETER node expects to use with 503 SCTP MUST be advertised in the DeviceRebootInd 504 message by including a HostIPAddress class for each 505 address. This class MUST ONLY be used in the 506 DeviceRebootInd message."; 507 }; 509 // 510 // DIAMETER specific mappings 511 // 513 diameter { 514 avp HostNameAVP { 515 code 264; implements HostName; 516 }; 518 avp VendorNameAVP { 519 code 266; implements VendorName; 520 }; 522 avp FirmwareRevisionAVP { 523 code 267; implements FirmwareRevision; 524 }; 526 avp ExtensionIdAVP { 527 code 258; implements ExtensionId; 528 }; 530 avp HostIPAddressAVP { 531 // really? conflicts with RADIUS assignement 532 code 4; implements HostIPAddress; 533 }; 535 avp NonceAVP { 536 code 261; implements Nonce; 537 }; 539 avp IntegrityCheckAVP { 540 code 259; implements IntegrityCheck; 541 }; 543 msg DeviceRebootInd { 544 code 257; 545 includes NonceAVP; 546 includes HostNameAVP; 547 includes HostIPAddressAVP; 548 includes VendorNameAVP; 549 includes ExtensionIdAVP; 550 includes FirmwareRevisionAVP; 551 includes IntegrityCheckAVP; 552 description 553 "A DIAMETER device sends the DeviceRebootInd message 554 to inform a peer that a reboot has just occured. 555 Since SCTP allows for connections to span multiple 556 interfaces, the DeviceRebootInd message MUST contain 557 one HostIPAddress AVP for each potential IP address 558 that MAY be locally used when transmitting DIAMETER 559 messages. 561 The DeviceRebootInd message is also used for 562 capabilities negotiation, such as the supported 563 protocol version number, and the locally supported 564 extensions. The receiver uses the extensions 565 advertised in order to determine whether it SHOULD 566 send certain application-specific DIAMETER 567 commands. A DIAMETER node MUST retain the supported 568 extensions in order to ensure that unrecognized 569 commands and/or AVPs are not sent to a peer. Note 570 that in a proxy environment, it is still possible 571 that a downstream proxy has no available peer that 572 have advertised the extension that corresponds to the 573 Command-Code, and therefore the request cannot be 574 forwarded any further. The DIAMETER base protocol 575 provides this error reporting, via the Result-Code 576 AVP. 578 Once the transport layer connection has been 579 established, a DIAMETER entity MUST issue a 580 DeviceRebootInd message, regardless of whether the 581 peer was statically configured, or dynamically 582 discovered. 584 If a peer is no longer reachable, a DIAMETER device 585 SHOULD periodically attempt to establish a transport 586 level connection with the peer and send a DRI 587 message. This message does not require a reply. If a 588 DIAMETER node receives a DeviceRebootInd message that 589 results in an error, a MessageRejectInd message MUST 590 be returned."; 591 }; 593 }; 594 }; 596 7. Security Considerations 598 This document presents an extension of the SMIng data definition 599 langauge which supports the mapping of SMIng data definitions so 600 that they can be used with the DIAMETER protocol. The language 601 extension and the mapping itself has no security impact on the 602 Internet. 604 8. Acknowledgements 606 The author would like to thank Frank Strauss for his valuable 607 comments on this document. 609 References 611 [1] Strauss, F., Schoenwaelder, J. and K. McCloghrie, "SMIng - Next 612 Generation Structure of Management Information", 613 draft-irtf-nmrg-sming-04.txt, November 2000. 615 [2] Calhoun, P.R., Rubens, A.C., Akhtar, H. and E. Guttman, 616 "DIAMETER Base Protocol", draft-calhoun-diameter-17.txt, 617 September 2000. 619 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 620 Levels", RFC 2119, BCP 14, March 1997. 622 [4] Crocker, D. and P. Overell, "Augmented BNF for Syntax 623 Specifications: ABNF", RFC 2234, November 1997. 625 Author's Address 627 Juergen Schoenwaelder 628 TU Braunschweig 629 Bueltenweg 74/75 630 38106 Braunschweig 631 Germany 633 Phone: +49 531 391-3266 634 EMail: schoenw@ibr.cs.tu-bs.de 636 Full Copyright Statement 638 Copyright (C) The Internet Society (2000). All Rights Reserved. 640 This document and translations of it may be copied and furnished to 641 others, and derivative works that comment on or otherwise explain it 642 or assist in its implementation may be prepared, copied, published 643 and distributed, in whole or in part, without restriction of any 644 kind, provided that the above copyright notice and this paragraph 645 are included on all such copies and derivative works. However, this 646 document itself may not be modified in any way, such as by removing 647 the copyright notice or references to the Internet Society or other 648 Internet organizations, except as needed for the purpose of 649 developing Internet standards in which case the procedures for 650 copyrights defined in the Internet Standards process must be 651 followed, or as required to translate it into languages other than 652 English. 654 The limited permissions granted above are perpetual and will not be 655 revoked by the Internet Society or its successors or assigns. 657 This document and the information contained herein is provided on an 658 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 659 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 660 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 661 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 662 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 664 Acknowledgement 666 Funding for the RFC Editor function is currently provided by the 667 Internet Society.