Network Working Group B. Linowski
Internet-Draft TCS/Nokia Siemens Networks
Intended status: Standards Track M. Ersue
Expires: January 7, 2010 Nokia Siemens Networks
July 6, 2009
Extending YANG with Language Abstractions
draft-linowski-netmod-yang-abstract-00
Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 7, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
YANG - the NETCONF Data Modeling Language - supports modeling of a
tree of data elements that represent the configuration and runtime
Linowski & Ersue Expires January 7, 2010 [Page 1]
Internet-Draft YANG Language Abstractions July 2009
status of a particular network element managed via NETCONF. This
memo suggests to enhance YANG with supplementary modeling features
and language abstractions with the aim to improve the model
extensibility and reuse.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Design Approach . . . . . . . . . . . . . . . . . . . . . 5
2. Complex Types . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. complex-type statement . . . . . . . . . . . . . . . . . . 6
2.3. element statement . . . . . . . . . . . . . . . . . . . . 7
2.4. element-list statement . . . . . . . . . . . . . . . . . . 8
2.5. extends statement . . . . . . . . . . . . . . . . . . . . 9
2.6. abstract statement . . . . . . . . . . . . . . . . . . . . 10
2.7. XML Encoding Rules . . . . . . . . . . . . . . . . . . . . 10
2.8. Type Encoding Rules . . . . . . . . . . . . . . . . . . . 10
2.9. Model Example . . . . . . . . . . . . . . . . . . . . . . 11
2.10. NETCONF Payload Example . . . . . . . . . . . . . . . . . 12
3. Typed Instance Identifier . . . . . . . . . . . . . . . . . . 13
3.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2. Usage of Type Statement . . . . . . . . . . . . . . . . . 14
3.3. Typed Instance Identifier Example . . . . . . . . . . . . 14
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Normative References . . . . . . . . . . . . . . . . . . . 16
7.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 16
Appendix B. Example Model . . . . . . . . . . . . . . . . . . . . 17
B.1. Modeling Improvements with Language Abstractions . . . . . 17
B.2. IPFIX/PSAMP Model with Complex Types and Typed
Instance Identifiers . . . . . . . . . . . . . . . . . . . 18
Linowski & Ersue Expires January 7, 2010 [Page 2]
Internet-Draft YANG Language Abstractions July 2009
1. Introduction
YANG - the NETCONF Data Modeling Language - supports modeling of a
tree of data elements that represent the configuration and runtime
status of a particular network element managed via NETCONF. While
this is well suited for describing the structure of the data tree of
particular manageable network resources, there are modeling
challenges, which suggest to extend existing modeling features in
their expressiveness and enhance YANG with supplementary modeling
features and language abstractions with the aim to improve the model
extensibility and reuse.
1.1. Key Words
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14, [RFC2119].
1.2. Motivation
o A system that is managing network elements is concerned with
managed objects of type "software image" that have a name, a
version and an activation state. In this context, it is useful to
define the "software image" as a concept that is supposed to be
further detailed and extended by additional concrete software
artifacts. In order to realize such a system, it is worth to
model abstract entities to be able to define concrete refinements
of that abstract entity (e.g. OS kernel).
o An agent scanning the network in order to update the state of an
inventory management system might be only interested in data
structures that represent a specific type of network elements.
Such an agent would then look for entities that are of this
specific type. It becomes beneficial that reusable named types
indicate the type of the concept the particular data structure
represents.
o In case network interfaces are distributed to different places in
the data tree (e.g. one list for bit-oriented interfaces, other
lists for character- and packet-oriented interfaces), describing
the stacking of sub-layers requires references between interfaces
that are not tied to one particular location in the model tree. A
packet-oriented interface might have a bit-oriented or character-
oriented interface as the lower layer interface. Refering to
entities regardless of their place in a containment hierarchy by
using location independent instance references becomes valuable.
Linowski & Ersue Expires January 7, 2010 [Page 3]
Internet-Draft YANG Language Abstractions July 2009
o Many systems today have a management information base that in
effect is organized as a tree build of recursively nested
container nodes. For example, the physical resources in the
ENTITY-MIB conceptually form a containment tree. The index
entPhysicalContainedIn points to the containing entity in a flat
list. The ability to represent nested, recursive data structures
of arbitrary depth would enable the representation of the primary
containment hierarchy of physical entities as a real tree in the
agent MIB and in the NETCONF payload.
o As particular network elements have specific type of software
images or equipment that need to be managed (OS images, plug-in
modules, equipment, etc.), it should be possible to define
concrete types, which describe the managed object precisely. By
using type-safe extensions of basic concepts a system in the
manager role can safely and explicitely determine that e.g. the
"equipment" is actually of type "network card".
o Having the possibility to tie behavioral aspects like remote
procedure calls, (operation) invocations, creation of
notifications to certain types of entities helps to properly
describe the scope of such behavioral features. It becomes clear
e.g. which kind of elements could generate "link-down"
notifications when the notification definition is placed inside
the "network interface" type. In case it is defined in the scope
of a module, this semantic connection is lost for generic tools as
it can only be read from the documentation.
o Today's network management solutions are often build on element
mediation functions that provide a unified and aggregated view of
a network sub-domain. In order to provide this functionality
mediation functions typically use network resource models that
abstract from details of particular network elements and provide
an abstract view of the model to the higher level management
system. Typically object oriented models provided by
organizations like TM Forum or 3GPP are used in this scope.
Enhancing YANG with modeling language abstractions would allow
lossless mapping with models containing classes and associations.
NETCONF and YANG would then provide an attractive solution for the
integration of mediation functions and higher level element
management systems, as both the protocol and the modeling language
are designed for management of network resources.
o Furthermore different SDOs are working on the harmonization of
their management information models currently. Often a model
mapping or transformation between systems becomes necessary. The
harmonization of the models is done e.g. by mapping of the two
models on object level or integrating an object hierarchy into an
Linowski & Ersue Expires January 7, 2010 [Page 4]
Internet-Draft YANG Language Abstractions July 2009
existing information model. Extending YANG with modeling language
abstractions will simplify the adoption of IETF resource models by
other SDOs and facilitate the alignment with other SDO's resource
models (e.g. TMF-MTOSI).
The challenges listed above mainly address issues, where it is
beneficial to use language abstractions for modeling. This memo
proposes additional modeling features for the YANG language in the
area of resource typing, referring to typed entities as well as
typed, structured model extensions and discusses how these new
features can improve the modeling capabilities of YANG.
Appendix B lists reasoning and technical improvements for modeling
with language abstractions and exemplifies the usage of the proposed
standard YANG extensions based on the IPFIX/PSAMP configuration model
in [IPFIXCONF].
Editor's note: The motivation chapter appears to be too long and will
be reduced in subsequent versions of the document.
1.3. Design Approach
The proposed additional features for YANG in this memo are designed
to reuse existing YANG statements whenever possible. To support new
concepts existing YANG statements are enhanced.
Only in cases where the semantics of the new concept differs
substantially from the semantics of existing language features, a new
YANG statement is introduced.
The proposed features don't change the semantics of models that are
valid with respect to the YANG specification [YANG].
2. Complex Types
2.1. Definition
YANG type concept is currently restricted to define simple types,
e.g. restrictions of primitive types, enumerations or union of simple
types.
Complex types are types with a rich internal structure, which may be
composed of lists, leafs, containers, choices, etc.. A new complex
type may extend an existing complex type. This allows to provide
type-safe extensions to existing YANG models as instances of the new
type, to be used wherever an instance of the base type may appear.
YANG supports the concept of groupings to facilitate reuse of data
Linowski & Ersue Expires January 7, 2010 [Page 5]
Internet-Draft YANG Language Abstractions July 2009
tree structure definitions. In contrast complex types have the
following characteristics:
o Introduction of new types, as a named, formal description of a
concrete manageable resource as well as abstract concepts.
o Types can be extended, i.e. new types can be defined by
specializing existing types adding new features. Instances of
such an extended type can be used wherever instances of the base
type can appear.
o The type information is made part of the NETCONF payload in case a
derived type substitutes a base type. This enables easy and
efficient consumption of payload elements representing complex
type instances.
2.2. complex-type statement
The statement "complex-type" is introduced that accepts an arbitrary
number of node tree defining statements among other common YANG
statements ("YANG Statements", [YANG] section 7.).
Linowski & Ersue Expires January 7, 2010 [Page 6]
Internet-Draft YANG Language Abstractions July 2009
+------------------+-------------+
| substatement | cardinality |
+------------------+-------------+
| abstract | 0..1 |
| anyxml | 0..n |
| choice | 0..n |
| config | 0..1 |
| container | 0..n |
| description | 0..1 |
| element | 0..n |
| element-list | 0..n |
| extends | 0..1 |
| grouping | 0..n |
| if-feature | 0..n |
| key | 0..1 |
| leaf | 0..n |
| leaf-list | 0..n |
| list | 0..n |
| must | 0..n |
| optional-feature | 0..n |
| order-by | 0..n |
| reference | 0..1 |
| status | 0..1 |
| typedef | 0..n |
| uses | 0..n |
+------------------+-------------+
Table 1: complex-type's substatements
All complex type names defined within a parent node or at the top-
level of the module or its submodules share the same type identifier
namespace. This namespace is scoped to the parent node or module.
A complex type MAY have an element key. An element key is either
defined with the "key" statement as part of the complex type or is
inherited from the base complex type.
Complex-type definitions do not create nodes in the management
information tree.
2.3. element statement
The new "element" statement is used to instantiate a complex type by
creating an element in the management information node tree. The
element statement takes one argument that is the identifier of the
complex type instance. It is followed by a block of substatements.
The type of the element is specified with the mandatory "type" sub-
Linowski & Ersue Expires January 7, 2010 [Page 7]
Internet-Draft YANG Language Abstractions July 2009
statement. The type of an element MUST be a complex type. Common
YANG statements may be used as substatements of the "element"
statement. An element is by default optional. To make an element
mandatory, "mandatory true" has to be applied as substatement.
+--------------+-------------+
| substatement | cardinality |
+--------------+-------------+
| description | 0..1 |
| config | 0..1 |
| if-feature | 0..1 |
| mandatory | 0..1 |
| max-elements | 0..1 |
| min-elements | 0..1 |
| must | 0..n |
| reference | 0..1 |
| status | 0..1 |
| type | 1 |
| when | 0..1 |
+--------------+-------------+
Table 2: element's substatements
The "element" and "element-list" statements (see chapter below) are
similar to the existing "leaf" and "leaf-list" statements, with the
exception that the content is composed of subordinate elements
according to the instantiated complex type.
2.4. element-list statement
The "element-list" statement is used to instantiate a complex type by
defining a sequence of element in the management information node
tree. Also the "element-list" statement takes one argument that is
the identifier of the complex type instances. It is followed by a
block of substatements.
The type of the element is specified with the mandatory "type" sub-
statement. In addition it can be stated how often an element may
appear in the management information tree by using the min-elements
and max-elements sub-statements. Common YANG statements may be used
as substatements of the "element" statement.
Linowski & Ersue Expires January 7, 2010 [Page 8]
Internet-Draft YANG Language Abstractions July 2009
+---------------+-------------+
| substatementc | cardinality |
+---------------+-------------+
| description | 0..1 |
| config | 0..1 |
| if-feature | 0..1 |
| max-elements | 0..1 |
| min-elements | 0..1 |
| must | 0..n |
| reference | 0..1 |
| status | 0..1 |
| type | 1 |
| when | 0..1 |
+---------------+-------------+
Table 3: element-list's substatements
In case the element list represents configuration, the used complex
type of an element MUST have an element key.
In case the configuration data status is specified in the complex
type, it MUST NOT differ from the effective configuration status of
the element or element-list. Elements as well as element list may
appear as arguments of the "deviate" statement.
2.5. extends statement
A complex type MAY extend exactly one existing base complex type by
using the "extends" statement. The keyword "extends" statement MAY
occur as substatement of the "complex-type" statement. The base
complex type is referred to in the single argument via its scoped
name. In case a complex type represents configuration data (the
default), it MUST have a key, otherwise it MAY have a key. A key is
either defined with the key statement as part of the complex type or
is inherited from the base complex type.
+--------------+-------------+
| substatement | cardinality |
+--------------+-------------+
| description | 0..1 |
| reference | 0..1 |
| status | 0..1 |
+--------------+-------------+
Table 4: extends' substatements
Linowski & Ersue Expires January 7, 2010 [Page 9]
Internet-Draft YANG Language Abstractions July 2009
2.6. abstract statement
Complex types may be declared to be abstract by using the "abstract"
statement. An abstract complex type cannot be instantiated, meaning
it cannot appear as most specific type of an element in NETCONF
payload. In case an abstract type extends a base type, the base
complex type MUST also be abstract. By default, complex types are
not abstract.
The complex type serve only as base types for derived concrete
complex types and cannot be used as type for an instance in NETCONF
payload.
The "abstract" statement takes a single string argument which is
either "true" or "false". In case a "complex-type" statement does
not contain an "abstract" statement as substatement, the default is
"false". The "abstract" statement does not support any
substatements.
2.7. XML Encoding Rules
An "element" node is encoded as an XML element where "element-list"
nodes are encoded as a series of XML elements. The XML element name
is the "element" respectively "element-list" identifier, and its XML
namespace is the module's XML namespace. The element's key nodes are
encoded as subelements to the element's identifier XML element, in
the same order as they are defined within the "key" statement of the
elements complex type. The rest of the element's child nodes are
encoded as subelements to the element XML element, after the keys, in
the same order as they are defined within the complex type statement.
Child nodes of an extending complex type precede the child nodes of
the extended complex type. As such, the XML encoding of lists is
very similar to the encoding of containers and lists. The only
exception is the encoding of the type of actual complex type
instance, described in the following section.
2.8. Type Encoding Rules
In order to encode the type of an element in NETCONF payload, XML
elements named "type" belonging to the XML namespace
"urn:ietf:params:xml:ns:yang-module-instance:1" are added to the
serialized form of element and element-list instances. The suggested
namespace prefix is "ymi". This "ymi:type" XML elements are inserted
before the serialized form of all (non-key) members declared the
according complex type. The "ymi:type" element is inserted for each
type in the extension chain from the type specified in the "element"
or "element-list" statement to the actual type of the instance in
reverse order (most specific first). Each type name includes the
Linowski & Ersue Expires January 7, 2010 [Page 10]
Internet-Draft YANG Language Abstractions July 2009
namespace.
The type of a complex type instance MUST be encoded in the reply to
NETCONF <get> and <get-config> operations, in the payload of NETCONF
<edit-config> operation if the operation is "create" or "replace".
The type MUST also be specified in case <copy-config> is used to
export a configuration to a resource addressed with an URI. Also the
type has to be specified in user defined RPC's.
The type MAY be specified in case the operation is "merge" (either
because this is explicitly specified or no operation attribute is
provided).
In case the node already exists in the target configuration and the
type is specified but differs from the data in the target, an <rpc-
error> element is returned with an <error-tag> value of "wrong-type".
In case no such element is present in the target configuration but
the type attribute is missing in the configuration data, an <rpc-
error> element is returned with an <error-tag> value of "missing-
type".
The type MUST NOT be specified in case the operation is "delete".
2.9. Model Example
The example below shows how complex types can be used to represent
physical equipment in a vendor independent, abstract way.
module hw {
prefix hw;
complex-type ManagedHardware {
abstract true;
key object-id;
leaf objectId { type string { max-length 32; } }
leaf serialNumber { type string; config false; }
leaf commonName { type string; }
}
complex-type Equipment {
extends ManagedHardware;
abstract true;
leaf installed {type boolean; config false; }
leaf version { type string; }
leaf redundancy {type uint16; }
}
Linowski & Ersue Expires January 7, 2010 [Page 11]
Internet-Draft YANG Language Abstractions July 2009
complex-type EquipmentHolder {
extends ManagedHardware;
abstract true;
element-list equipment { type Equipment; }
element-list holder { type EquipmentHolder; }
}
// Holder types
complex-type Slot {
extends EquipmentHolder;
leaf slotNumber { type unit16; config false; }
}
complex-type Chassis {
extends EquipmentHolder;
leaf numberOfSlots { type unit16; config false; }
}
// ...
// Equipment types
complex-type Card {
extends Equipment;
leaf usedSlots { type unit16; mandatory true; }
}
// Root Element
element hardware { type ManagedHardware; }
} // hw module
2.10. NETCONF Payload Example
Following example shows the payload of a reply to a NETCONF <get>
command. The actual type of managed hardware elements is indicated
with the "ymi:type" elements as required by the type encoding rules.
The containment hierarchy in the NETCONF XML payload reflects the
containment hierarchy of hardware elements. This makes filtering
based on the containment hierarchy possible without having to deal
with values of key-ref leafs that represent the tree structure in a
flattened hierarchy.
Linowski & Ersue Expires January 7, 2010 [Page 12]
Internet-Draft YANG Language Abstractions July 2009
<hardware>
<objectId>R31r1</objectId>
<ymi:type>hw:Chassis</ymi:type>
<numberOfSlots>6</numberOfSlots>
<ymi:type>hw:EquipmentHolder</ymi:type>
<holder>
<objectId>R31s2</objectId>
<ymi:type>hw:Slot</ymi:type>
<slotNumber>1</slotNumber>
<ymi:type>hw:EquipmentHolder</ymi:type>
<equipment>
<objectId>ATM-45252</objectId>
<ymi:type>hw:Card</ymi:type>
<usedSlots>1</usedSlots>
<ymi:type>hw:Equipment</ymi:type>
<installed>true</installed>
<version>A2</version>
<redundancy>1</redundancy>
<serialNumber>A-778911-b</serialNumber>
<commonName>ATM-ADM 2</commonName>
</equipment>
<serialNumeber>T-K4733890x45</serialNumber>
<commonName>CU-Slot</commonName>
</holder>
<ymi:type>hw:ManagedHardware</ymi:type>
<serialNumber>R-US-3276279a</serialNumber>
<commonName>Rack R322-1</commonName>
// ...
</hardware>
3. Typed Instance Identifier
3.1. Definition
Typed instance identifier relationships are an addition to the
relationship types already defined in YANG, where the leaf-ref
relationship is location dependent, and the instance-identifier is
not type-safe.
Typed instance identifiers represent references to instances of a
complex type without being restricted to a particular location in the
containment tree. This is done by using the existing "type"
statement as a sub-statement of the "type instance identifier"
statement. Typed instance identifiers ensure that the target of an
instance reference is of a particular complex type or of a type
derived from the specified target type. In effect such an instance
Linowski & Ersue Expires January 7, 2010 [Page 13]
Internet-Draft YANG Language Abstractions July 2009
identifier provides a type-safe yet location agnostic reference.
Typed instance identifiers allow referring to instances of complex
types that may be located anywhere in the management information
tree. The "type" statement plays the role of a restriction that must
be fulfilled by the node that is referred to with the instance
identifier. The restriction is that it must be of a particular
complex type, either the type itself or any type that extends this
complex type.
3.2. Usage of Type Statement
To realize typed instance identifiers the substatement "type" is
introduced as substatement of "instance-identifier":
o When using the already existing "instance-identifier" type, it is
allowed to use the "type" statement as substatement, which in this
case determines the type of the referred instances.
o In case the "type" statement is used under the "instance-
identifier" statement, its argument must refer to a complex type
with one or more keys.
3.3. Typed Instance Identifier Example
In the example below, a physical link connects an arbitrary number of
physical ports. Here typed instance identifiers are used to denote
which "PhysicalPort" instances (anywhere in the data tree) are
connected by a "PhysicalLink".
Linowski & Ersue Expires January 7, 2010 [Page 14]
Internet-Draft YANG Language Abstractions July 2009
// Extended version of type Card
complex-type Card {
extends Equipment;
leaf usedSlot { type unit16; mandatory true; }
element-list port {
type PhysicalPort;
}
}
complex-type PhysicalPort {
extends ManagedHardware;
leaf portNumber { type int32; mandatory true; }
}
complex-type PhysicalLink {
extends ManagedHardware;
media { type string; }
leaf-list connectedPort {
type instance-identifier {
type PhysicalPort;
}
min-elements 2;
}
}
The XML encoding of an element named "link" of type "PhysicalLink"
appears as below:
<link>
<objectId>FTCL-771</objectId>
<media>Fiber</media>
<connectedPort>/hw:hardware[objectId='R-11']
/hw:equipment[objectId='AT22']/hw:port[objectId='P12']
</connectedPort>
<connectedPort>/hw:hardware[objectId='R-42]
/hw:equipment[objectId='AT30']/hw:port[objectId='P3']
</connectedPort>
<serialNumeber>F-7786828</serialNumber>
<commonName>FibCon 7</commonName>
</link>
4. IANA Considerations
This document does not request any IANA entries.
Linowski & Ersue Expires January 7, 2010 [Page 15]
Internet-Draft YANG Language Abstractions July 2009
5. Security Considerations
Complex-types and Typed Instance Identifiers themselves do not have
any security impact on the Internet.
The security considerations described throughout [YANG] apply here as
well.
6. Acknowledgements
The authors would like to thank to Martin Bjorklund, Balazs Lengyel,
Gerhard Muenz and Martin Storch for their valuable comments and
hints.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
[YANG] Bjorklund, M., "YANG - A data modeling language for
NETCONF", draft-ietf-netmod-yang-06 (work in progress),
June 2009.
7.2. Informative References
[IPFIXCONF] Muenz, G., "Configuration Data Model for IPFIX and
PSAMP", draft-ietf-ipfix-configuration-model-02 (work in
progress), March 2009.
Appendix A. Open Issues
o Module update support. How do we handle changes to complex types
and element (list) nodes during a module update?
o Do we want to support augmenting a complex type?
o Are features and deviations good enough to control the use of
derived (extended) types when changing a configuration in a
particular agent?
o Remote procedure calls, (operation) invocations, creation of
notifications to certain types of entities need to be specified.
Linowski & Ersue Expires January 7, 2010 [Page 16]
Internet-Draft YANG Language Abstractions July 2009
Appendix B. Example Model
B.1. Modeling Improvements with Language Abstractions
The module below is a variation of the IPFIX/PSAMP configuration
model, which uses complex types and typed instance identifiers to
model the concept outlined in [IPFIXCONF].
When looking at the YANG module with complex types and typed instance
identifiers, various technical improvements on modeling level become
apparent.
o There is almost a one-to-one mapping between the domain concepts
introduced in IPFIX and the complex types in the YANG module
o All associations between the concepts (which are not containment)
are represented with typed identifiers. That avoids having to
refer to a particular location in the tree which is not mandated
by the original model.
o It is no longer needed to represent concept refinement (class
inheritance in the original model) with containment in form of
quite big choice-statements with complex branches. Instead,
concept refinement is realized by complex types extending a base
complex type.
o There is no need to make an artificial distinction between IP- and
file destinations (see list "exportingProcess" in [IPFIXCONF]).
Instead an abstract base class is used to capture the
commonalities of all destinations.
o There is no need to introduce metadata types and leafs (e.g.
"typedef ipfixTransportProtocol" and "leaf transportProtocol" in
"grouping destinationParamters") that just serve the purpose of
indicating which concrete sub-type type of a generic type (modeled
as grouping which contains the union of all features of all
subtypes) is actually represented in the MIB.
o There is no need to rule out illegal use of sub-type specific
properties (like "leaf templateRefreshTimeout by using "must"
statements that refer to a sub-type discriminator (must
"../transportProtocol=udp")
o There is no need to define properties like the configuration
status wherever a so called "parameter grouping" is used. Instead
those definitions can be put inside the complex-type definition
itself (e.g. "config false" statements).
Linowski & Ersue Expires January 7, 2010 [Page 17]
Internet-Draft YANG Language Abstractions July 2009
o There is no need to repeatedly declare the key of a type at every
place where a grouping is used (see use of "grouping
optionTemplate")
o Complex types may be declared as optional features. If the type
is indicated with an enumeration which has a literal per type
(e.g. "typedef ipfixTransportProtocol"), this is not possible,
because "if-feature" is not allowed as a substatement of "enum".
B.2. IPFIX/PSAMP Model with Complex Types and Typed Instance
Identifiers
module ipfix-psamp {
namespace "urn:ietf:params:xml:ns:ipfix-psamp-config";
prefix ipfix;
import yang-types { prefix yang; }
import inet-types { prefix inet; }
description "IPFIX/PSAMP Configuration Data Model";
revision 2009-03-02 {
description "Version of draft-ietf-ipfix-configuration-model-02
modeled with complex types and typed instance
identifiers."
feature exporter {
description "If supported, the device can be used as an Exporter.
Exporting Processes can be configured.";
}
feature collector {
description "If supported, the device can be used as a Collector.
Collecting Processes can be configured.";
}
feature meter {
description "If supported, Observation Points, Selection
Processes, and Caches can be configured.";
}
feature psampSampCountBased {
description "If supported, the device supports count-based Sampling.
The Selector method sampCountBased can be configured.";
Linowski & Ersue Expires January 7, 2010 [Page 18]
Internet-Draft YANG Language Abstractions July 2009
}
feature psampSampTimeBased {
description "If supported, the device supports time-based Sampling.
The Selector method sampTimeBased can be configured.";
}
feature psampSampRandOutOfN {
description "If supported, the device supports random n-out-of-N
Sampling. The Selector method sampRandOutOfN can be configured.";
}
feature psampSampUniProb {
description "If supported, the device supports uniform probabilistic
Sampling. The Selector method sampUniProb can be configured.";
}
feature psampSampNonUniProb {
description "If supported, the device supports non-uniform
probabilistic Sampling. The Selector method sampNonUniProb can be
configured.";
}
feature psampSampFlowState {
description "If supported, the device supports flow state dependent
Sampling. The Selector method sampFlowState can be configured.";
}
feature psampFilterMatch {
description "If supported, the device supports property match
Filtering. The Selector method filterMatch can be configured.";
}
feature psampFilterHash {
description "If supported, the device supports hash-based Filtering.
The Selector method filterHash can be configured.";
}
feature psampFilterRState {
description "If supported, the device supports router state
Filtering. The Selector method filterRState can be configured.";
}
feature udpTransport {
description "If supported, the device supports UDP as transport
protocol.";
}
Linowski & Ersue Expires January 7, 2010 [Page 19]
Internet-Draft YANG Language Abstractions July 2009
feature tcpTransport {
description "If supported, the device supports TCP as transport
protocol.";
}
feature fileReader {
description "If supported, the device supports the configuration
of Collecting Processes as File Readers.";
}
feature fileWriter {
description "If supported, the device supports the configuration
of Exporting Processes as File Writers.";
}
typedef direction {
type enumeration {
enum ingress;
enum egress;
enum both;
}
description "Direction of packets going through an interface or
linecard.";
}
typedef optionType {
type enumeration {
enum meteringStatistics {
description "Metering Process Statistics.";
reference "RFC 5101, section 4.1.";
}
enum meteringReliability {
description "Metering Process Reliability Statistics.";
reference "RFC 5101, section 4.2.";
}
enum exportingReliability {
description "Exporting Process Reliability
Statistics.";
reference "RFC 5101, section 4.3.";
}
enum flowKeys {
description "Flow Keys.";
reference "RFC 5101, section 4.4.";
}
enum selectionSequence {
description "Selection Sequence and Selector Reports.";
reference "draft-ietf-psamp-protocol-09, section 6.5.1
Linowski & Ersue Expires January 7, 2010 [Page 20]
Internet-Draft YANG Language Abstractions July 2009
and 6.5.2.";
}
enum selectionStatistics {
description "Selection Sequence Statistics Report.";
reference "draft-ietf-psamp-protocol-09, section
6.5.3.";
}
enum accuracy {
description "Accuracy Report.";
reference "draft-ietf-psamp-protocol-09, section
6.5.4.";
}
enum reducingRedundancy {
description "Application of ipfix-reducing-redundancy.";
reference "draft-ietf-ipfix-reducing-redundancy-04";
}
}
description "Options Templates specified by IPFIX and PSAMP.";
}
typedef templateFieldFlags {
type bits {
bit scope {
position 0;
}
bit flowKey {
position 1;
}
}
description "Attributes of a field in a Template.";
reference "draft-ietf-ipfix-mib-05, section 7
(ipfixTemplateDefinitionFlags)";
}
typedef transportSessionStatus {
type enumeration {
enum inactive;
enum active;
enum unknown;
}
description "Status of a Transport Session.";
reference "draft-ietf-ipfix-mib-05, section 7
(ipfixTransportSessionStatus).";
}
typedef filterRStateFunction {
type enumeration {
enum other;
Linowski & Ersue Expires January 7, 2010 [Page 21]
Internet-Draft YANG Language Abstractions July 2009
enum ingressIf;
enum egressIf;
enum aclViolation;
enum rpfFailure;
enum noResources;
enum noRoute;
enum originAS;
enum destAS;
}
description "Filter function applied to router state.";
reference "draft-ietf-psamp-mib-06, section 5.2.3.";
}
typedef exportMemberType {
type enumeration {
enum primary;
enum secondary;
enum duplicate;
enum loadBalancing;
enum unused;
}
description "This type defines different usages of an export
destination among all destinations of an Exporting Process.
It corresponds to ipfixExportMemberType in IPFIX-MIB.";
reference "draft-ietf-ipfix-mib-05.";
}
grouping informationElement {
description "Parameters of an Information Element.";
choice nameOrId {
mandatory true;
description "Name or ID of the Information Element.";
reference "RFC5102";
leaf ieName { type string; }
leaf ieId { type uint16; }
}
leaf ieLength {
type uint16;
description "Length can be omitted if a default length exists
for the specified Information Element. A value of 65535
specifies a variable-length Information Element.";
reference "RFC5102";
}
leaf ieEnterpriseNumber {
type uint32;
description "If present, this is an enterprise-specific
Information Element.";
reference "RFC5101, RFC5102";
Linowski & Ersue Expires January 7, 2010 [Page 22]
Internet-Draft YANG Language Abstractions July 2009
}
}
grouping cacheLayoutParameters {
description "Fields of a Cache Layout.";
list cacheField {
key name;
min-elements 1;
leaf name { type string; }
uses informationElement;
leaf isFlowKey {
type empty;
description "If present, this is a flow key.";
}
}
}
complex-type Receiver {
description "Receiver of a Collecting Process";
abstract true;
key name;
leaf name { type string; }
}
complex-type IpReceiver {
extends Receiver;
abstract true;
leaf destinationIpAddress {
type inet:ip-address;
mandatory true;
}
leaf destinationPort {
type inet:port-number;
default 4739;
}
leaf sendBufferSize {
type uint32;
units bytes;
description "Size of the socket send buffer.
If not configured, this parameter is set by the monitoring
device";
}
leaf rateLimit {
type uint32;
units "bytes per second";
description "Maximum number of bytes per second the Exporting
Process may export to the given destination. The number of
Linowski & Ersue Expires January 7, 2010 [Page 23]
Internet-Draft YANG Language Abstractions July 2009
bytes is calculated from the lengths of the IPFIX Messages
exported. If not configured, no rate limiting is
performed.";
reference "draft-ietf-psamp-protocol-09, section 6.3.";
}
}
complex-type SctpReceiver {
extends IpReceiver;
description "SCTP receiver";
reference "RFC 4960.";
leaf-list localIpAddress {
type inet:ip-address;
description "List of eligible local IP addresses to be
used by the SCTP endpoint. If not configured, all locally
assigned IP addresses are used by the local endpoint.";
reference "RFC 3758, RFC 4960.";
}
leaf timedReliability {
type yang:timeticks;
default 0;
description "PR-SCTP lifetime for IPFIX Messages
containing Data Sets only. Zero means reliable transport.";
reference "RFC 3758, RFC 4960.";
}
leaf numberOfStreams {
type uint16;
description "Number of outbound streams requested for the
SCTP association.
If not configured, this parameter is set by the monitoring
device.";
reference "RFC 3758, RFC 4960.";
}
leaf orderedDelivery {
type boolean;
default true;
description "Ordered delivery of IPFIX Messages
containing Data Sets.";
reference "RFC 3758, RFC 4960.";
}
}
complex-type UdpReceiver {
if-feature udpTransport;
extends IpReceiver;
description "UDP receiver.";
leaf sourceIpAddress {
type inet:ip-address;
Linowski & Ersue Expires January 7, 2010 [Page 24]
Internet-Draft YANG Language Abstractions July 2009
description "Sets source IP address if UDP is transport
protocol. If not configured, the IP address assigned to the
outgoing interface is used.";
}
leaf templateRefreshTimeout {
type uint32;
units seconds;
default 600;
description "Sets time after which Templates are resent if
UDP is transport protocol.";
reference "RFC5101.";
}
leaf optionTemplateRefreshTimeout {
type uint32;
units seconds;
default 600;
description "Sets time after which Options Templates are
resent if UDP is transport protocol.";
reference "RFC5101.";
}
leaf templateRefreshPacket {
type uint32;
units "IPFIX Messages";
description "Sets number of IPFIX Messages after which
Templates are resent if UDP is transport protocol.
If omitted, Templates are only resent after timeout.";
reference "RFC5101.";
}
leaf optionTemplateRefreshPacket {
type uint32;
units "IPFIX Messages";
description "Sets number of IPFIX Messages after which
Options Templates are resent if UDP is transport protocol.
If omitted, Templates are only resent after timeout.";
reference "RFC5101.";
}
}
complex-type TcpReceiver {
if-feature tcpTransport;
extends IpReceiver;
description "TCP receiver.";
}
complex-type FileReader {
if-feature fileReader;
extends Receiver;
description "File Reader parameters.";
Linowski & Ersue Expires January 7, 2010 [Page 25]
Internet-Draft YANG Language Abstractions July 2009
leaf uri {
mandatory true;
type yang:uri;
}
}
complex-type CollectingProcess {
description "A Collecting Process.";
key name;
leaf name {
description "Arbitrary but unique name of the Collecting
Process.";
type string;
}
element-list receiver {
description "Receivers of the collection process.";
type Receiver;
min-elements 1;
}
leaf-list exportingProcess {
description "Export of received records without any
modifications. Records are processed by all Exporting
Processes in the list.";
type instance-identifier { type ExportingProcess; }
}
element-list Template {
type Template;
}
element-list transportSession {
type TransportSession;
}
}
complex-type ObservationPoint {
description "Base Observation Point.";
abstract true;
key name;
leaf name {
description "Arbitrary but unique name of the Observation
Point.";
type string;
}
leaf observationPointId {
description "If omitted, the Observation Point ID is assigned
by the monitoring device.";
type uint32;
Linowski & Ersue Expires January 7, 2010 [Page 26]
Internet-Draft YANG Language Abstractions July 2009
}
leaf observationDomainId {
description "The Observation Domain ID associates the
Observation Point to an Observation Domain. Observation
Points with identical Observation Domain ID belong to the
same Observation Domain.";
mandatory true;
type uint32;
}
leaf-list selectionProcess {
description "Selection Processes in this list process packets
in parallel.";
type instance-identifier { type SelectionProcess; }
}
}
complex-type LinecardObservationPoint {
extends ObservationPoint;
description "Linecard Observation Point.";
leaf physicalEntity {
description "Instance identifier of the observed linecard";
type instance-identifer {type PhysicalEntity}
}
// Note: This modeling assumes that also physical entities are
// modeled with complex types. Otherwise a choice
// with an index or name needs to be used.
leaf direction {
description "Direction of packets. If not applicable (e.g.,
in the case of a sniffing interface in promiscuous mode),
this parameter is omitted";
type Direction;
default both;
}
}
complex-type InterfaceObservationPoint {
extends ObservationPoint;
description "Interface Observation Point.";
leaf interface {
description "Instance identifier of the observed interface";
type instance-identifer {type Interface;}
}
// Note: this modeling assumes that also interfaces
// are modeled with complex types. Otherwise a choice
// with an index or name as to be used.
leaf direction {
description "Direction of packets. If not applicable (e.g.,
in the case of a sniffing interface in promiscuous mode),
Linowski & Ersue Expires January 7, 2010 [Page 27]
Internet-Draft YANG Language Abstractions July 2009
this parameter is omitted";
type Direction;
default both;
}
}
complex-type Selector {
abstract true;
description "Abstract Selector.";
key name;
leaf name {
description "Arbitrary but unique name of the Selector.";
type string;
}
leaf selectorId {
type uint16;
description "The Selector ID must be unique within the
Observation Domain.
If not configured, this parameter is set by the monitoring
device.";
reference "draft-ietf-psamp-info-11";
}
leaf packetsObserved {
type yang:counter64;
config false;
description "Corresponds to ipfixSelectorStatsPacketsObserved
in IPFIX-MIB.";
reference "draft-ietf-ipfix-mib-05, section 7
(ipfixSelectorStatsPacketsObserved).";
}
leaf packetsDropped {
type yang:counter64;
config false;
description "Corresponds to ipfixSelectorStatsPacketsDropped
in IPFIX-MIB.";
reference "draft-ietf-ipfix-mib-05, section 7
(ipfixSelectorStatsPacketsDropped).";
}
}
complex-type SelectAll {
extends Selector;
}
complex-type SampCountBased {
if-feature psampSampCountBased;
extends Selector;
Linowski & Ersue Expires January 7, 2010 [Page 28]
Internet-Draft YANG Language Abstractions July 2009
leaf interval {
type uint32;
mandatory true;
}
leaf spacing {
type uint32;
mandatory true;
}
}
complex-type SampTimeBased {
if-feature psampSampTimeBased;
extends Selector;
leaf interval {
type uint32;
mandatory true;
}
leaf spacing {
type uint32;
mandatory true;
}
}
complex-type SampRandOutOfN {
if-feature psampSampRandOutOfN;
extends Selector;
leaf population {
type uint32;
mandatory true;
}
leaf sample {
type uint32;
mandatory true;
}
}
complex-type SampUniProb {
if-feature psampSampUniProb;
extends Selector;
leaf probability {
type uint32;
mandatory true;
description "The given value must be divided by
4294967295.";
}
}
complex-type SampNonUniProb {
Linowski & Ersue Expires January 7, 2010 [Page 29]
Internet-Draft YANG Language Abstractions July 2009
if-feature psampSampNonUniProb;
extends Selector;
leaf function {
type yang:object-identifier;
mandatory true;
}
leaf funcParam {
type yang:object-identifier;
mandatory true;
}
}
complex-type SampFlowState {
if-feature psampSampFlowState;
extends Selector;
leaf function {
type yang:object-identifier;
mandatory true;
}
leaf funcParam {
type yang:object-identifier;
mandatory true;
}
}
complex-type FilterMatch {
if-feature psampFilterMatch;
extends Selector;
choice nameOrId {
mandatory true;
description "Deviating from the PSAMP MIB, the field is
specified by either the name or the ID of the
Information Element.";
leaf ieName {
type string;
}
leaf ieId {
type uint16;
}
}
leaf ieEnterpriseNumber {
type uint32;
description "Deviating from the PSAMP MIB, an enterprise
number may be specified to refer to an
enterprise-specific Information Element.";
}
leaf startValue {
type string;
Linowski & Ersue Expires January 7, 2010 [Page 30]
Internet-Draft YANG Language Abstractions July 2009
mandatory true;
}
leaf stopValue {
type string;
mandatory true;
}
leaf mask {
type string;
description "If not configured, no mask is applied.";
}
}
complex-type FilterHash {
if-feature psampFilterHash;
extends Selector;
leaf addrType {
type inet:ip-version;
mandatory true;
}
leaf headerBits {
type string {
length 40;
}
mandatory true;
description "If addrType is 'ipv4', only the first 20 bytes
are used.";
}
leaf payloadBytes {
type uint32;
default 0;
}
leaf payloadBits {
type string;
description "If not configured, all bits included in the
payload section defined by payloadBytes are used.";
}
leaf function {
type yang:object-identifier;
mandatory true;
}
leaf funcParam {
type yang:object-identifier;
mandatory true;
}
leaf inputBits {
type uint32;
mandatory true;
}
Linowski & Ersue Expires January 7, 2010 [Page 31]
Internet-Draft YANG Language Abstractions July 2009
leaf outputBits {
type uint32;
mandatory true;
}
leaf outputMask {
type string;
mandatory true;
}
leaf selection {
type string;
mandatory true;
}
}
complex-type FilterRState {
if-feature psampFilterRState;
extends Selector;
leaf function {
type filterRStateFunction;
mandatory true;
}
leaf negate {
type boolean;
default false;
}
leaf ifIndex {
type uint32;
mandatory true;
description "Index of the interface as stored in the
ifTable of IF-MIB.";
reference "RFC 2863.";
}
leaf startAS {
type inet:autonomous-system-number;
must "../function=originAS or ../function=destAS";
}
leaf stopAS {
type inet:autonomous-system-number;
must "../function=originAS or ../function=destAS";
}
leaf vendorFunc {
type yang:object-identifier;
must "../function=other";
}
}
complex-type SelectionProcess {
Linowski & Ersue Expires January 7, 2010 [Page 32]
Internet-Draft YANG Language Abstractions July 2009
description "A Selection Process.";
key name;
leaf name {
description "Arbitrary but unique name of the Selection
Process.";
type string;
}
leaf selectionSequenceId {
description "The Selection Sequence ID must be unique within
the Observation Domain. If not configured, this parameter
is set by the monitoring device.";
reference "draft-ietf-psamp-info-11";
type uint64;
}
element-list selector {
description "List of Selectors that define the action of the
Selection Process on a single packet. The Selectors are
serially invoked in the same order as they appear in this
list.";
min-elements 1;
ordered-by user;
type Selector;
}
leaf-list selectionProcess {
description "A Selection Process may pass selected packets
to further Selection Processes.";
type instance-identifier { type SelectionProcess; }
}
leaf-list cache {
description "Caches in this list receive the selected packets
in parallel.";
type instance-identifier { type Cache; }
}
}
typedef cacheType {
type enumeration {
enum immediate {
description "Flow expiration after the first packet,
generation of Packet Records.";
}
enum timeout {
description "Flow expiration after active and inactive
timeout, generation of Flow Records.";
}
enum permanent {
description "No flow expiration, periodical export after
Linowski & Ersue Expires January 7, 2010 [Page 33]
Internet-Draft YANG Language Abstractions July 2009
active timeout, generation of Flow Records.";
}
}
description "Cache Type specifies the Flow expiration policy of
a Cache.";
}
compley-type cache {
if-feature meter;
description "A Cache";
key name;
leaf name { type string; }
leaf cacheType {
description "Actual cache type. May be changed at run time."
type cacheType;
mandatory true;
}
leaf maxRecords {
type uint32;
description "If not configured, this parameter is set by the
Monitoring Device.";
}
leaf activeTimeout {
type uint32;
units seconds;
must "../cacheType!=immediate";
description "If not configured, this parameter is set by the
Monitoring Device.";
}
leaf inactiveTimeout {
type uint32;
units seconds;
must "../cacheType!=permanent";
description "If not configured, this parameter is set by the
Monitoring Device.";
}
container cacheLayout { uses cacheLayoutParameters; }
leaf-list exportingProcess {
type keyref { path "/ipfix/exportingProcess/name"; }
description "Records are exported by all Exporting Processes in
the list.";
}
leaf activeFlows {
type uint32;
units flows;
config false;
description "Corresponds to
ipfixMeteringProcessCacheActiveFlows in IPFIX-MIB.";
Linowski & Ersue Expires January 7, 2010 [Page 34]
Internet-Draft YANG Language Abstractions July 2009
reference "ietf-draft-ipfix-mib-05, section 7
(ipfixMeteringProcessCacheActiveFlows)";
}
leaf inactiveFlows {
type uint32;
units flows;
config false;
description "Corresponds to
ipfixMeteringProcessCacheInactiveFlows in IPFIX-MIB.";
reference "ietf-draft-ipfix-mib-0, section 7
(ipfixMeteringProcessCacheInactiveFlows)";
}
leaf dataRecords {
type yang:counter64;
units "Data Records";
config false;
description "Corresponds to
ipfixMeteringProcessDataRecords in IPFIX-MIB.";
reference "ietf-draft-ipfix-mib-0, section 7
(ipfixMeteringProcessDataRecords)";
}
}
complex-type Destination {
abract true;
key name;
leaf name { type string; }
leaf type {
type exportMemberType;
}
element-list option {
type Option;
}
}
complex-type IpDestination {
extends Destination;
abstract true;
leaf destinationIpAddress {
type inet:ip-address;
mandatory true;
}
leaf destinationPort {
type inet:port-number;
default 4739;
}
leaf sendBufferSize { type uint32; }
Linowski & Ersue Expires January 7, 2010 [Page 35]
Internet-Draft YANG Language Abstractions July 2009
leaf rateLimit {
description "Maximum number of bytes per second the Exporting
Process may export to the given destination. The number of
bytes is calculated from the lengths of the IPFIX Messages
exported.";
reference "draft-ietf-psamp-protocol-09, section 6.3.";
type uint32;
}
}
complex-type SctpExport {
extends IpDestination;
description "SCTP export parameters.";
reference "RFC 3758, RFC 4960.";
leaf-list sourceIpAddress {
description "List of eligible local IP addresses to be
used by the SCTP endpoint. If omitted, all locally
assigned IP addresses are used by the local endpoint.";
type inet:ip-address;
}
leaf timedReliability {
description "PR-SCTP lifetime for IPFIX Messages
containing Data Sets only.";
type yang:timeticks;
default 0;
}
leaf numberOfStreams {
description "Number of outbound streams requested for the
SCTP association.";
type uint16;
}
leaf orderedDelivery {
description "Ordered delivery of IPFIX Messages
containing Data Sets.";
type boolean;
default "true";
}
}
complex-type UdpExport {
if-feature udpTransport;
extends IpDestination;
description "UDP export parameters.";
leaf sourceIpAddress {
description "Source IP address. If omitted, the address
assigned to the outgoing interface is used.";
Linowski & Ersue Expires January 7, 2010 [Page 36]
Internet-Draft YANG Language Abstractions July 2009
type inet:ip-address;
}
leaf templateRefreshTimeout {
type uint32;
units seconds;
default 600;
description "Sets time after which Templates are resent if
UDP is transport protocol.";
reference "RFC5101.";
}
leaf optionTemplateRefreshTimeout {
type uint32;
units seconds;
default 600;
description "Sets time after which Options Templates are
resent if UDP is transport protocol.";
reference "RFC5101.";
}
leaf templateRefreshPacket {
type uint32;
units "IPFIX Messages";
description "Sets number of IPFIX Messages after which
Templates are resent if UDP is transport protocol.
If omitted, Templates are only resent after timeout.";
reference "RFC5101.";
}
leaf optionTemplateRefreshPacket {
type uint32;
units "IPFIX Messages";
description "Sets number of IPFIX Messages after which
Options Templates are resent if UDP is transport protocol.
If omitted, Templates are only resent after timeout.";
reference "RFC5101.";
}
}
complex-type TcpExport {
if-feature tcpTransport;
description "TCP export parameters.";
extends IpDestination;
}
complex-type FileWriter {
if-feature fileWriter;
extends Destination;
description "File Writer.";
leaf uri {
type inet:uri;
Linowski & Ersue Expires January 7, 2010 [Page 37]
Internet-Draft YANG Language Abstractions July 2009
mandatory true;
description "URI specifying the location of the file.";
}
must "current().type!=loadBalancing";
}
complex-type Option {
description "Specification of the data to export using an
Options Template.";
key name;
leaf name { type string; }
leaf type {
type optionType;
mandatory true;
}
leaf timeout {
type yang:timeticks;
default 0;
description "Time interval for exporting options data.
If set to zero, the options data is sent once.";
}
container optionTemplate {
description "If no Options Template is specified, the
Exporter defines a template according to options type and
available options data.";
list optionField {
key name;
ordered-by user;
leaf name { type string; }
uses informationElement;
leaf isScope {
type empty;
description "If present, this is a scope field.";
}
}
}
}
complex-type Template {
description "A Template used by an Exporting
Process or received by a Collecting Process. Parameter names
and semantics correspond to the managed objects in IPFIX-
MIB";
reference "draft-ietf-ipfix-mib-05, section 7
(ipfixTemplateEntry, ipfixTemplateDefinitionEntry,
ipfixTemplateStatsEntry)";
Linowski & Ersue Expires January 7, 2010 [Page 38]
Internet-Draft YANG Language Abstractions July 2009
config false;
leaf observationDomainId { type uint32; }
leaf templateId { type uint16; }
leaf setId { type uint16; }
leaf accessTime { type yang:date-and-time; }
leaf dataRecords { type yang:counter64; }
list field {
leaf ieId { type uint16; }
leaf ieLength { type uint16; }
leaf enterprise { type uint32; }
leaf flags { type templateFieldFlags; }
}
}
complex-type TransportSession {
description "State of a Transport Session originating
from an Exporting or terminating at a Collecting Process.
Parameter names and semantics correspond to the managed
objects in IPFIX-MIB";";
reference "draft-ietf-ipfix-mib-05, section 7
(ipfixTransportSessionEntry, ipfixTransportSessionStatsEntry)";
config false;
leaf index { type int32; }
leaf sourceAddress { type inet:ip-address; }
leaf destinationAddress { type inet:ip-address; }
leaf sourcePort { type inet:port-number; }
leaf destinationPort { type inet:port-number; }
leaf sctpAssocId { type uint32; }
leaf templateRefreshTimeout {
type uint32;
units seconds;
}
leaf optionTemplateRefreshTimeout {
type uint32;
units seconds;
}
leaf templateRefreshPacket {
type uint32;
units "IPFIX Messages";
}
leaf optionTemplateRefreshPacket {
type uint32;
units "IPFIX Messages";
}
leaf status { type transportSessionStatus; }
leaf rate {
type int32;
Linowski & Ersue Expires January 7, 2010 [Page 39]
Internet-Draft YANG Language Abstractions July 2009
units "bytes per second";
}
leaf packets {
type yang:counter64;
units packets;
}
leaf bytes {
type yang:counter64;
units bytes;
}
leaf messages {
type yang:counter64;
units "IPFIX Messages";
}
leaf discardedMessages {
type yang:counter64;
units "IPFIX Messages";
}
leaf records {
type yang:counter64;
units "Data Records";
}
leaf templates {
type yang:counter32;
units "Templates";
}
leaf optionTemplates {
type yang:counter32;
units "Options Templates";
}
}
complex-type ExportingProcess {
description "An Exporting Process.";
key name;
leaf name {
description "Arbitrary but unique name of the Exporting
Process.";
type string;
}
leaf exportingProcessId {
description "If omitted, the Exporting Process ID
is assigned by the monitoring device.";
type uint32;
}
element-list destination {
type Destination;
Linowski & Ersue Expires January 7, 2010 [Page 40]
Internet-Draft YANG Language Abstractions July 2009
}
element-list options {
type Option;
}
element-list Template {
type Template;
}
element-list transportSession {
type TransportSession;
}
}
container ipfix {
element-list collectingProcess {
if-feature collector;
type CollectingProcess;
}
element-list observationPoint {
if-feature meter;
type ObservationPoint
}
element-list selectionProcess {
if-feature meter;
type SelectionProcess;
}
element-list cache {
if-feature meter;
type Cache;
}
element-list exportingProcess {
if-feature exporter;
type ExportingProcess;
}
}
}
Linowski & Ersue Expires January 7, 2010 [Page 41]
Internet-Draft YANG Language Abstractions July 2009
Authors' Addresses
Bernd Linowski
TCS/Nokia Siemens Networks
Heltorfer Strasse 1
Duesseldorf 40472
Germany
EMail: bernd.linowski@ext.nsn.com
Mehmet Ersue
Nokia Siemens Networks
St.-Martin-Strasse 53
Munich 81541
Germany
EMail: mehmet.ersue@nsn.com
Linowski & Ersue Expires January 7, 2010 [Page 42]
