Network Working Group                                   J. Schoenwaelder
Internet-Draft                                           TU Braunschweig
Expires: May 31, 2001                                  November 30, 2000


                       SMIng Mappings to DIAMETER
                    draft-schoenw-sming-diameter-00

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   To view the entire list of Internet-Draft Shadow Directories, see
   http://www.ietf.org/shadow.html.

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/iid-abstracts.txt

   This Internet-Draft will expire on May 31, 2001.

Copyright Notice

   Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract

   This memo presents an SMIng language extension that supports the
   mapping of SMIng definitions of classes and their attributes to
   DIAMETER AVPs and messages.












Schoenwaelder             Expires May 31, 2001                  [Page 1]


Internet-Draft         SMIng Mappings to DIAMETER          November 2000


Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.    DIAMETER Base Types  . . . . . . . . . . . . . . . . . . . .  3
   3.    SMIng Data Type Mappings . . . . . . . . . . . . . . . . . .  4
   4.    The diameter Extension Statement . . . . . . . . . . . . . .  4
   4.1   The vendor Statement . . . . . . . . . . . . . . . . . . . .  4
   4.2   The avp Statement  . . . . . . . . . . . . . . . . . . . . .  4
   4.2.1 The avp's code Statement . . . . . . . . . . . . . . . . . .  5
   4.2.2 The avp's implements Statement . . . . . . . . . . . . . . .  5
   4.3   The msg Statement  . . . . . . . . . . . . . . . . . . . . .  5
   4.3.1 The msg's code Statement . . . . . . . . . . . . . . . . . .  5
   4.3.2 The msg's includes Statement . . . . . . . . . . . . . . . .  5
   4.3.3 The msg's status Statement . . . . . . . . . . . . . . . . .  5
   4.3.4 The msg's description Statement  . . . . . . . . . . . . . .  5
   5.    TUBS-IBR-SMING-DIAMETER-EXT  . . . . . . . . . . . . . . . .  6
   6.    Example  . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   7.    Security Considerations  . . . . . . . . . . . . . . . . . . 14
   8.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
         References . . . . . . . . . . . . . . . . . . . . . . . . . 14
         Author's Address . . . . . . . . . . . . . . . . . . . . . . 14
         Full Copyright Statement . . . . . . . . . . . . . . . . . . 15





























Schoenwaelder             Expires May 31, 2001                  [Page 2]


Internet-Draft         SMIng Mappings to DIAMETER          November 2000


1. Introduction

   This memo presents an SMIng [1] language extension that supports the
   mapping of SMIng definitions of classes and their attributes to
   DIAMETER [2] AVPs and messages.

   SMIng is an object-oriented data definition language which builds on
   concepts that have been successfully used over the last decade
   within the SNMP management framework. The SMIng language is
   independent of management protocols and applications. Protocol
   mappings to additional protocols can be defined as SMIng language
   extensions.

   There are several advantages in adopting SMIng as the data
   definition language for DIAMETER:
   1.  Using SMIng allows to reuse data definitions from other areas.
       For example, it is possible to import definitions for common
       data types such as dates, times, IP addresses, IP filter etc.
       from common modules.
   2.  Using common data definitions across several management
       protocols simplifies the development of applications or network
       elements that have to interface with equipment supporting
       multiple protocols.
   3.  A common data definition language encourages consistency across
       technology domains which reduces software complexity for
       products that need to operate on data definitions which may be
       manipulated with different protocols.
   4.  Adopting SMIng enables authors to reuse authoring tools to e.g.
       verify the correctness of their data definitions.
   5.  SMIng features a versioning mechanism (via status assignments),
       a naming and import mechanism, and a precise language definition
       which puts well-defined bounds on syntactic constructs such as
       identifiers or value notations.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [3].

2. DIAMETER Base Types

   The DIAMETER protocol should be modified to support AVPs that encode
   the following primitive base types: Integer32, Unsigned32,
   Integer64, Unsigned64, Float32, Float64, Float128, and OctetString
   as specified in [1]. In addition, the DIAMETER protocol should
   support a compound type which contains an ordered list of AVPs. The
   AVPs in the compound type are ordered.





Schoenwaelder             Expires May 31, 2001                  [Page 3]


Internet-Draft         SMIng Mappings to DIAMETER          November 2000


3. SMIng Data Type Mappings

   The SMIng base types are mapped to the DIAMETER base types according
   to the following table:


           SMIng Data Type    DIAMETER Base Type
           ---------------    ------------------
           OctetString        OctetString
           Integer32          Integer32
           Integer64          Integer64
           Unsigned32         Unsigned32
           Unsigned64         Unsigned64
           Float32            Float32
           Float64            Float64
           Float128           Float128
           Enumeration        Integer32
           Bits               OctetString


    Note that the SMIng base type Pointer is not mapped to any DIAMETER
   base type.

   Classes are mapped to the compound DIAMETER base type. Each
   primitive attribute of a given class is represented according to the
   mapping table above and is encapsulated in the compound base type.

4. The diameter Extension Statement

   The `diameter' statement is the main statement of the DIAMETER
   mapping specification. It gets one arguments: a statement block that
   contains all details of the DIAMETER mapping.  A single SMIng module
   must not contain more than one 'diameter' statement.

4.1 The vendor Statement

   The `vendor' statement, which must be present if the definition is
   not part of an IETF standard, gets one argument which identifies the
   enterprise responsible for this definition. The value MUST be an
   IANA assigned enterprise number.

4.2 The avp Statement

   The `avp' statement is used to define an AVP. The avp statement gets
   two arguents: an upper-case AVP identifier and a statement block
   that holds detailed information about the AVP.

   See the `avpStatement' rule of the SMIng grammar (Section 5) for the
   formal syntax of the 'avp' statement.


Schoenwaelder             Expires May 31, 2001                  [Page 4]


Internet-Draft         SMIng Mappings to DIAMETER          November 2000


4.2.1 The avp's code Statement

   The avp's `code' statement, which must be present, gets one argument
   which specifies the code used to identify the AVP.

4.2.2 The avp's implements Statement

   The avp's `implements' statement, which must be present exactly
   once, gets one argument: the identifier of an SMIng class which is
   implemented by this AVP.

4.3 The msg Statement

   The `msg' statement is used to define a DIAMETER message. The msg
   statement gets two arguents: an upper-case message identifier and a
   statement block that holds detailed information about the message.

   See the `msgStatement' rule of the SMIng grammar (Section 5) for the
   formal syntax of the 'msg' statement.

4.3.1 The msg's code Statement

   The msg's `code' statement, which must be present, gets one argument
   which specifies the code used to identify the message.

4.3.2 The msg's includes Statement

   The msg's `includes' statement, which may be present zero, one or
   multiple times, gets one argument which specifies an AVP which must
   be included in the message.

4.3.3 The msg's status Statement

   The msg's `status' statement, which need not be present, gets one
   argument which is used to specify whether this message definition is
   current or historic. The value `current' means that the definition
   is current and valid. The value `obsolete' means the definition is
   obsolete and should not be implemented and/or can be removed if
   previously implemented.  While the value `deprecated' also indicates
   an obsolete definition, it permits new/continued implementation in
   order to foster interoperability with older/existing
   implementations.

   If the `status' statement is omitted, the status value `current' is
   implied.

4.3.4 The msg's description Statement

   The msg's `description' statement, which must be present, gets one


Schoenwaelder             Expires May 31, 2001                  [Page 5]


Internet-Draft         SMIng Mappings to DIAMETER          November 2000


   argument which is used to specify a high-level textual description
   of this message.

   It is RECOMMENDED to include all semantics and purposes of this
   message.

5. TUBS-IBR-SMING-DIAMETER-EXT

   The grammar of the DIAMETER mapping SMIng extension conforms to the
   Augmented Backus-Naur Form (ABNF)[4]. It is included in the abnf
   statement of the `diameter' SMIng extension definition in the
   TUBS-IBR-SMING-DIAMETER-EXT module below.

         module TUBS-SMING-DIAMETER-EXT {

       organization    "Technical University of Braunschweig";

       contact         "Juergen Schoenwaelder

                        TU Braunschweig
                        Bueltenweg 74/75
                        38106 Braunschweig
                        Germany

                        Phone: +49 531 391-3289
                        EMail: schoenw@ibr.cs.tu-bs.de";

       description     "SMIng extension for DIAMETER.";

       revision {
           date        "2000-11-24";
           description "Initial version, published as RFC XXXX.";
       };

       extension snmp {

           description
              "The diameter statement maps SMIng definitions to
               DIAMETER AVPs and messages.";
           abnf
              ";;
   ;; sming-diameter.abnf -- Grammar of DIAMETER mappings in ABNF
   ;;                        notation (RFC 2234).
   ;;
   ;; @(#) $Id$
   ;;
   ;; Copyright (C) The Internet Society (2000). All Rights Reserved.
   ;;



Schoenwaelder             Expires May 31, 2001                  [Page 6]


Internet-Draft         SMIng Mappings to DIAMETER          November 2000


   ;;
   ;; Statement rules.
   ;;

   diameterStatement       = diameterKeyword optsep
                                 "{" stmtsep
                                 *1(vendorStatement stmtsep)
                                 *(avpStatement stmtsep)
                                 *(msgStatement stmtsep)
                             "}" optsep ";"



   vendorStatement         = vendorKeyword sep decimalNumber optsep ";"

   avpStatement            = avpKeyword sep ucIdentifier optsep
                                 "{" stmtsep
                                 codeStatement stmtsep
                                 implementsStatement stmtsep
                                 *1(statusStatement stmtsep)
                             "}" optsep ";"

   msgStatement            = msgKeyword sep ucIdentifier optsep
                                 "{" stmtsep
                                 codeStatement stmtsep
                                 *(includesStatement stmtsep)
                                 *1(statusStatement stmtsep)
                                 descriptionStatement stmtsep
                             "}" optsep ";"

   codeStatement           = codeKeyword sep decimalNumber optsep ";"

   implementsStatement     = implementsKeyword sep qucIdentifier optsep ";"

   includesStatement       = includesKeyword sep qucIdentifier optsep ";"

   ;;
   ;; Statement keywords.
   ;;

   diameterKeyword     =   %x64 %x69 %x61 %x6D %x65 %x74 %x65 %x72
   vendorKeyword       =   %x76 %x65 %x6E %x64 %x6F %x72
   avpKeyword          =   %x61 %x76 %x70
   msgKeyword          =   %x6D %x73 %x67
   codeKeyword         =   %x63 %x6F %x64 %x65
   implementsKeyword   =   %x69 %x6D %x70 %x6C %x65 %x6D %x65 %x6E %x74 %x73
   includesKeyword     =   %x69 %x6E %x63 %x6C %x75 %x64 %x65 %x73

   ;;


Schoenwaelder             Expires May 31, 2001                  [Page 7]


Internet-Draft         SMIng Mappings to DIAMETER          November 2000


   ;; EOF
   ;;
   ";

       };

   };


6. Example

   The following example demonstrates how the DIAMETER AVPs and
   messages defined in [2] can be defined using the SMIng and the SMIng
   `diameter' extension presented in this memo.

               module TUBS-SMING-DIAMETER {

       import IRTF-NMRG-SMING              (Utf8String);
       import IRTF-NMRG-SMING-INET         (InetNetworkEndpoint);
       import TUBS-DIAMETER-EXT            (diameter);

       organization    "Technical University of Braunschweig";

       contact         "Juergen Schoenwaelder

                        TU Braunschweig
                        Bueltenweg 74/75
                        38106 Braunschweig
                        Germany

                        Phone: +49 531 391-3289
                        EMail: schoenw@ibr.cs.tu-bs.de";

       description     "SMIng core definitions for DIAMETER.";

       revision {
           date        "2000-11-24";
           description "Initial version, published as RFC XXXX.";
       };

       // international domain names (?)
       typedef NetworkAccessIdentifier {
           type    Utf8String;
           description
               "A Network Address Identifier as specified in RFC 2486.";
           reference
               "RFC 2486";
       };



Schoenwaelder             Expires May 31, 2001                  [Page 8]


Internet-Draft         SMIng Mappings to DIAMETER          November 2000


       // this really belongs into an IANA module
       typedef DiameterExtension {
           type Enumeration (none(0),
                             nasreq(1),
                             security(2),
                             resmgmt(3),
                             mobileip(4),
                             accouting(5));
           description
               "This type identifies an extension of the DIAMETER base
                protocol. Assignments are made by IANA.";
       };

       typedef RandomString {
           type OctetString (16..65535);
           description
               "This type contains a random value of at least 128 bits.";
       };

       typedef SecondsSince2000 {
           type Unsigned32;
           description
               "The number of seconds since 1st January 2000, 00:00 UTC.";
       };

       // this really belongs into an IANA module
       typedef HashAlgorithm {
           type Enumeration (none(0), md5(1));
           description
               "Identifies a hash algorithm.";
       };

       typedef KeyId {
           type Unsigned32;
           description
               "This type represents a generic key identifier, which is
                used to identify the keying information for a security
                mechanism.";
       };

       typedef MessageAuthenticationCode {
           type OctetString;
           description
               "The message authentication code (MAC) for a
                given message.";
       };

       //
       // AVP classes


Schoenwaelder             Expires May 31, 2001                  [Page 9]


Internet-Draft         SMIng Mappings to DIAMETER          November 2000


       //

       class IntegrityCheck {
           attribute HashAlgorithm alg {
               description "Identifies the crypto algorithm.";
           };
           attribute KeyId key {
               description "Identifies the security key.";
           };
           attribute MessageAuthenticationCode mac {
               description "The fingerprint of the message.";
           };
           description
               "This class contains the information needed to
                authenticate a message and to check its integrity
                on a hop-by-hop basis.";
       };

       class Nonce {
           attribute RandomString nonce {
               description "A random byte string used as a nonce.";
           };
           description
               "The Nonce class MUST be present prior to the
                IntegrityCheck class within a message and is used
                to ensure randomness within a message. Some crypto
                algorithms are known to have weaknesses if a random
                value is not found early within the plaintext,
                therefore it is recommended that the Nonce class be
                added early in a message if possible.";
       };

       class HostName {
           attribute NetworkAccessIdentifier name {
               description "A network access identifier which identifies
               a sender's identity.";
           };
           description
               "The HostName class is used to inform a DIAMETER peer of
                the sender's identity. All DIAMETER messages MUST
                include the HostName class. Note that the HostName
                class may resolve to more than one address as the
                DIAMETER peer may support more than one address.";
           };
       };

       class VendorName {
           attribute Utf8String name {
               description "The name of the vendor.";


Schoenwaelder             Expires May 31, 2001                 [Page 10]


Internet-Draft         SMIng Mappings to DIAMETER          November 2000


           };
           description
               "The VendorName class is used to inform a DIAMETER peer
                of the vendor name of the DIAMETER device.  This MAY
                be used in order to know which vendor specific
                attributes may be sent to the peer. It is also
                envisioned that the combination of the VendorName
                and the FirmwareRevision classes MAY provide very
                useful debugging information.";
       };

       class FirmwareRevision {
           attribute Unsigned32 revision {
               description "A revision number.";
           };
           description
              "The FirmwareRevision class is used to inform a DIAMETER
               peer of the firmware revision of the issuing device.

               For devices that do not have a firmware revision (general
               purpose computers running DIAMETER software modules,
               for instance), the revision of the DIAMETER software
               module may be reported instead.";
       };

       class ExtensionId {
           attribute DiameterExtension extension {
               description "Identifies a Diameter extension.";
           };
           description
               "The ExtensionId AVP identifies a specific DIAMETER
                extension. This AVP is used in the DeviceRebootInd
                message in order to inform the peer what extensions
                are locally supported.

                Each DIAMETER extension draft MUST have an IANA
                assigned extension Idenfier. The base protocol does
                not require an ExtensionId since its support is
                mandatory.

                There MAY be more than one ExtensionId AVP within a
                DIAMETER DeviceRebootInd message.";
       };

       // The description should be more generic.
       class HostIPAddress {
           attribute InetNetworkEndpoint endpoint {
               description "Denotes the sender's IP address.";
           };


Schoenwaelder             Expires May 31, 2001                 [Page 11]


Internet-Draft         SMIng Mappings to DIAMETER          November 2000


           description
               "The HostIPAddress class is used to inform a DIAMETER
                peer of the sender's IP address.  All source
                addresses that a DIAMETER node expects to use with
                SCTP MUST be advertised in the DeviceRebootInd
                message by including a HostIPAddress class for each
                address. This class MUST ONLY be used in the
                DeviceRebootInd message.";
       };

       //
       // DIAMETER specific mappings
       //

       diameter {
           avp HostNameAVP {
               code 264; implements HostName;
           };

           avp VendorNameAVP {
               code 266; implements VendorName;
           };

           avp FirmwareRevisionAVP {
               code 267; implements FirmwareRevision;
           };

           avp ExtensionIdAVP {
               code 258; implements ExtensionId;
           };

           avp HostIPAddressAVP {
               // really? conflicts with RADIUS assignement
               code 4; implements HostIPAddress;
           };

           avp NonceAVP {
               code 261; implements Nonce;
           };

           avp IntegrityCheckAVP {
               code 259; implements IntegrityCheck;
           };

           msg DeviceRebootInd {
               code 257;
               includes NonceAVP;
               includes HostNameAVP;
               includes HostIPAddressAVP;


Schoenwaelder             Expires May 31, 2001                 [Page 12]


Internet-Draft         SMIng Mappings to DIAMETER          November 2000


               includes VendorNameAVP;
               includes ExtensionIdAVP;
               includes FirmwareRevisionAVP;
               includes IntegrityCheckAVP;
               description
                   "A DIAMETER device sends the DeviceRebootInd message
                    to inform a peer that a reboot has just occured.
                    Since SCTP allows for connections to span multiple
                    interfaces, the DeviceRebootInd message MUST contain
                    one HostIPAddress AVP for each potential IP address
                    that MAY be locally used when transmitting DIAMETER
                    messages.

                    The DeviceRebootInd message is also used for
                    capabilities negotiation, such as the supported
                    protocol version number, and the locally supported
                    extensions. The receiver uses the extensions
                    advertised in order to determine whether it SHOULD
                    send certain application-specific DIAMETER
                    commands. A DIAMETER node MUST retain the supported
                    extensions in order to ensure that unrecognized
                    commands and/or AVPs are not sent to a peer. Note
                    that in a proxy environment, it is still possible
                    that a downstream proxy has no available peer that
                    have advertised the extension that corresponds to the
                    Command-Code, and therefore the request cannot be
                    forwarded any further. The DIAMETER base protocol
                    provides this error reporting, via the Result-Code
                    AVP.

                    Once the transport layer connection has been
                    established, a DIAMETER entity MUST issue a
                    DeviceRebootInd message, regardless of whether the
                    peer was statically configured, or dynamically
                    discovered.

                    If a peer is no longer reachable, a DIAMETER device
                    SHOULD periodically attempt to establish a transport
                    level connection with the peer and send a DRI
                    message. This message does not require a reply. If a
                    DIAMETER node receives a DeviceRebootInd message that
                    results in an error, a MessageRejectInd message MUST
                    be returned.";
           };

       };
   };




Schoenwaelder             Expires May 31, 2001                 [Page 13]


Internet-Draft         SMIng Mappings to DIAMETER          November 2000


7. Security Considerations

   This document presents an extension of the SMIng data definition
   langauge which supports the mapping of SMIng data definitions so
   that they can be used with the DIAMETER protocol. The language
   extension and the mapping itself has no security impact on the
   Internet.

8. Acknowledgements

   The author would like to thank Frank Strauss for his valuable
   comments on this document.

References

   [1]  Strauss, F., Schoenwaelder, J. and K. McCloghrie, "SMIng - Next
        Generation Structure of Management Information",
        draft-irtf-nmrg-sming-04.txt, November 2000.

   [2]  Calhoun, P.R., Rubens, A.C., Akhtar, H. and E. Guttman,
        "DIAMETER Base Protocol", draft-calhoun-diameter-17.txt,
        September 2000.

   [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", RFC 2119, BCP 14, March 1997.

   [4]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 2234, November 1997.

Author's Address

   Juergen Schoenwaelder
   TU Braunschweig
   Bueltenweg 74/75
   38106 Braunschweig
   Germany

   Phone: +49 531 391-3266
   EMail: schoenw@ibr.cs.tu-bs.de












Schoenwaelder             Expires May 31, 2001                 [Page 14]


Internet-Draft         SMIng Mappings to DIAMETER          November 2000


Full Copyright Statement

   Copyright (C) The Internet Society (2000). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Schoenwaelder             Expires May 31, 2001                 [Page 15]