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]