GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6095

Internet Engineering Task Force (IETF) B. Linowski Request for Comments: 6095 TCS/Nokia Siemens Networks Category: Experimental M. Ersue ISSN: 2070-1721 Nokia Siemens Networks

                                                             S. Kuryla
                                                  360 Treasury Systems
                                                            March 2011
             Extending YANG with Language Abstractions

Abstract

 YANG -- the Network Configuration Protocol (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.  This memo suggests enhancing
 YANG with supplementary modeling features and language abstractions
 with the aim to improve the model extensibility and reuse.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for examination, experimental implementation, and
 evaluation.
 This document defines an Experimental Protocol for the Internet
 community.  This document is a product of the Internet Engineering
 Task Force (IETF).  It represents the consensus of the IETF
 community.  It has received public review and has been approved for
 publication by the Internet Engineering Steering Group (IESG).  Not
 all documents approved by the IESG are a candidate for any level of
 Internet Standard; see Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc6095.

Linowski, et al. Experimental [Page 1] RFC 6095 YANG Language Abstractions March 2011

Copyright Notice

 Copyright (c) 2011 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
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Table of Contents

 1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.1.  Key Words  . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.2.  Motivation . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.3.  Modeling Improvements with Language Abstractions . . . . .  5
   1.4.  Design Approach  . . . . . . . . . . . . . . . . . . . . .  6
   1.5.  Modeling Resource Models with YANG . . . . . . . . . . . .  6
     1.5.1.  Example of a Physical Network Resource Model . . . . .  6
     1.5.2.  Modeling Entity MIB Entries as Physical Resources  . . 12
 2.  Complex Types  . . . . . . . . . . . . . . . . . . . . . . . . 15
   2.1.  Definition . . . . . . . . . . . . . . . . . . . . . . . . 15
   2.2.  complex-type Extension Statement . . . . . . . . . . . . . 15
   2.3.  instance Extension Statement . . . . . . . . . . . . . . . 17
   2.4.  instance-list Extension Statement  . . . . . . . . . . . . 18
   2.5.  extends Extension Statement  . . . . . . . . . . . . . . . 19
   2.6.  abstract Extension Statement . . . . . . . . . . . . . . . 19
   2.7.  XML Encoding Rules . . . . . . . . . . . . . . . . . . . . 20
   2.8.  Type Encoding Rules  . . . . . . . . . . . . . . . . . . . 20
   2.9.  Extension and Feature Definition Module  . . . . . . . . . 21
   2.10. Example Model for Complex Types  . . . . . . . . . . . . . 24
   2.11. NETCONF Payload Example  . . . . . . . . . . . . . . . . . 25
   2.12. Update Rules for Modules Using Complex Types . . . . . . . 26
   2.13. Using Complex Types  . . . . . . . . . . . . . . . . . . . 26
     2.13.1. Overriding Complex Type Data Nodes . . . . . . . . . . 26
     2.13.2. Augmenting Complex Types . . . . . . . . . . . . . . . 27
     2.13.3. Controlling the Use of Complex Types . . . . . . . . . 28
 3.  Typed Instance Identifier  . . . . . . . . . . . . . . . . . . 29
   3.1.  Definition . . . . . . . . . . . . . . . . . . . . . . . . 29
   3.2.  instance-type Extension Statement  . . . . . . . . . . . . 29
   3.3.  Typed Instance Identifier Example  . . . . . . . . . . . . 30
 4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 31
 5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 31

Linowski, et al. Experimental [Page 2] RFC 6095 YANG Language Abstractions March 2011

 6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
 7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
   7.1.  Normative References . . . . . . . . . . . . . . . . . . . 32
   7.2.  Informative References . . . . . . . . . . . . . . . . . . 32
 Appendix A.  YANG Modules for Physical Network Resource Model
              and Hardware Entities Model . . . . . . . . . . . . . 34
 Appendix B.  Example YANG Module for the IPFIX/PSAMP Model . . . . 40
   B.1.  Modeling Improvements for the IPFIX/PSAMP Model with
         Complex Types and Typed Instance Identifiers . . . . . . . 40
   B.2.  IPFIX/PSAMP Model with Complex Types and Typed
         Instance Identifiers . . . . . . . . . . . . . . . . . . . 41

1. Introduction

 YANG -- the NETCONF Data Modeling Language [RFC6020] -- supports
 modeling of a tree of data elements that represent the configuration
 and runtime status of a particular network element managed via
 NETCONF.  This document defines extensions for the modeling language
 YANG as new language statements, which introduce language
 abstractions to improve the model extensibility and reuse.  The
 document reports from modeling experience in the telecommunication
 industry and gives model examples from an actual network management
 system to highlight the value of proposed language extensions,
 especially class inheritance and recursiveness.  The language
 extensions defined in this document have been implemented with two
 open source tools.  These tools have been used to validate the model
 examples through the document.  If this experimental specification
 results in successful usage, it is possible that the language
 extensions defined herein could be updated to incorporate
 implementation and deployment experience, then pursued on the
 Standards Track, possibly as part of a future version of YANG.

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

 Following are non-exhaustive motivation examples highlighting usage
 scenarios for language abstractions.
 o  Many systems today have a Management Information Base (MIB) 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

Linowski, et al. Experimental [Page 3] RFC 6095 YANG Language Abstractions March 2011

    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 node tree in the
    server MIB and in the NETCONF payload.
 o  A manager 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 hardware.  Such a
    manager would then look for entities that are of this specific
    type, including those that are an extension or specialization of
    this type.  To support this use case, it is helpful to bear the
    corresponding type information within the data structures, which
    describe the network element hardware.
 o  A system that is managing network elements is concerned, e.g.,
    with managed objects of type "plug-in modules" that have a name, a
    version, and an activation state.  In this context, it is useful
    to define the "plug-in module" as a concept that is supposed to be
    further detailed and extended by additional concrete model
    elements.  In order to realize such a system, it is worthwhile to
    model abstract entities, which enable reuse and ease concrete
    refinements of that abstract entity in a second step.
 o  As particular network elements have specific types of components
    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 explicitly determine that e.g., the "equipment" is
    actually of type "network card".
 o  Currently, different SDOs are working on the harmonization of
    their management information models.  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 the object level or integrating an object hierarchy into
    an existing information model.  On the one hand, extending YANG
    with language abstractions can simplify the adoption of IETF
    resource models by other SDOs and facilitate the alignment with
    other SDOs' resource models (e.g., TM Forum SID [SID_V8]).  On the
    other hand, the proposed YANG extensions can enable the
    utilization of the YANG modeling language in other SDOs, which
    usually model complex management systems in a top-down manner and
    use high-level language features frequently.

Linowski, et al. Experimental [Page 4] RFC 6095 YANG Language Abstractions March 2011

 This memo specifies additional modeling features for the YANG
 language in the area of structured model abstractions, typed
 references, as well as recursive data structures, and it discusses
 how these new features can improve the modeling capabilities of YANG.
 Section 1.5.1 contains a physical resource model that deals with some
 of the modeling challenges illustrated above.  Section 1.5.2 gives an
 example that uses the base classes defined in the physical resource
 model and derives a model for physical entities defined in the Entity
 MIB.

1.3. Modeling Improvements with Language Abstractions

 As an enhancement to YANG 1.0, complex types and typed instance
 identifiers provide different technical improvements on the modeling
 level:
 o  In case the model of a system that should be managed with NETCONF
    makes use of inheritance, complex types enable an almost one-to-
    one mapping between the classes in the original model and the YANG
    module.
 o  Typed instance identifiers allow representing associations between
    the concepts in a type-safe way to prevent type errors caused by
    referring to data nodes of incompatible types.  This avoids
    referring to a particular location in the MIB.  Referring to a
    particular location in the MIB is not mandated by the domain
    model.
 o  Complex types allow defining complete, self-contained type
    definitions.  It is not necessary to explicitly add a key
    statement to lists, which use a grouping that defines the data
    nodes.
 o  Complex types simplify concept refinement by extending a base
    complex type and make it superfluous to represent concept
    refinements with workarounds such as huge choice-statements with
    complex branches.
 o  Abstract complex types ensure correct usage of abstract concepts
    by enforcing the refinement of a common set of properties before
    instantiation.
 o  Complex types allow defining recursive structures.  This enables
    representing complex structures of arbitrary depth by nesting
    instances of basic complex types that may contain themselves.

Linowski, et al. Experimental [Page 5] RFC 6095 YANG Language Abstractions March 2011

 o  Complex types avoid introducing metadata types (e.g., type code
    enumerations) and metadata leafs (e.g., leafs containing a type
    code) to indicate which concrete type of object is actually
    represented by a generic container in the MIB.  This also avoids
    explicitly ruling out illegal use of subtype-specific properties
    in generic containers.
 o  Complex type instances include the type information in the NETCONF
    payload.  This allows determining the actual type of an instance
    during the NETCONF payload parsing and avoids the use in the model
    of additional leafs, which provide the type information as
    content.
 o  Complex types may be declared explicitly as optional features,
    which is not possible when the actual type of an entity
    represented by a generic container is indicated with a type code
    enumeration.
 Appendix B, "Example YANG Module for the IPFIX/PSAMP Model", lists
 technical improvements for modeling with complex types and typed
 instance identifiers and exemplifies the usage of the proposed YANG
 extensions based on the IP Flow Information Export (IPFIX) / Packet
 Sampling (PSAMP) configuration model in [IPFIXCONF].

1.4. Design Approach

 The proposed additional features for YANG in this memo are designed
 to reuse existing YANG statements whenever possible.  Additional
 semantics is expressed by an extension that is supposed to be used as
 a substatement of an existing statement.
 The proposed features don't change the semantics of models that is
 valid with respect to the YANG specification [RFC6020].

1.5. Modeling Resource Models with YANG

1.5.1. Example of a Physical Network Resource Model

 The diagram below depicts a portion of an information model for
 manageable network resources used in an actual network management
 system.
 Note: The referenced model (UDM, Unified Data Model) is based on key
 resource modeling concepts from [SID_V8] and is compliant with
 selected parts of SID Resource Abstract Business Entities domain
 [UDM].

Linowski, et al. Experimental [Page 6] RFC 6095 YANG Language Abstractions March 2011

 The class diagram in Figure 1 and the corresponding YANG module
 excerpt focus on basic resource ("Resource" and the distinction
 between logical and physical resources) and hardware abstractions
 ("Hardware", "Equipment", and "EquipmentHolder").  Class attributes
 were omitted to achieve decent readability.

Linowski, et al. Experimental [Page 7] RFC 6095 YANG Language Abstractions March 2011

+——–+

Resource

+——–+ /\ /\ – – | | | +—————+ | |LogicalResource| | +—————+ | | +——–+ | |Physical| +———–+ '-|Resource|<|-+-|PhysicalLink|

 +---- ---+   | +------------+
              |     |0..* physicalLink
              |     |                                       equipment
              |     |                                       Holder
              |     |                                       0..*
              |     |                                       +-------+
              |     |0..* hardware                          |       |
              | +--------+     +---------------+     +---------+    |
              '-|Hardware|<|-+-|ManagedHardware|<|-+-|Equipment|<>--+
                +--------+   | +---------------+   | | Holder  |0..1
                    <>       |                     | +---------+
                0..1|        |                     |   <>
                    |        |                     |   |0..* equipment
                    |        |                     |   |     Holder
                    |        |                     |   |
                    |        |                     |   |0..* equipment
                    |        |                     |   |
                    |        |                     |   |    equipment
                    |        |                     |   |    0..*
                    |        |                     |   |    +-------+
                    |        |                     |   |    |       |
                    |        |                     | +---------+    |
                    |        |                     '-|Equipment|<>--+
                    |        |                       +---------+0..1
                    |        |                    compositeEquipment
                    |        |
                    |        | +-----------------+
                    |        '-|PhysicalConnector|----+0..* source
                    '----------+-----------------+    |     Physical
         physicalConnector 0..*           |           |     Connector
                                          |           |
                                          +-----------+
                                          0..* targetPhysicalConnector
               Figure 1: Physical Network Resource Model

Linowski, et al. Experimental [Page 8] RFC 6095 YANG Language Abstractions March 2011

 Since this model is an abstraction of network-element-specific MIB
 topologies, modeling it with YANG creates some challenges.  Some of
 these challenges and how they can be addressed with complex types are
 explained below:
 o  Modeling of abstract concepts: Classes like "Resource" represent
    concepts that primarily serve as a base class for derived classes.
    With complex types, such an abstract concept could be represented
    by an abstract complex type (see "complex-type extension
    statement" and "abstract extension statement").
 o  Class Inheritance: Information models for complex management
    domains often use class inheritance to create specialized classes
    like "PhysicalConnector" from a more generic base class (here,
    "Hardware"), which itself might inherit from another base class
    ("PhysicalResource"), etc.  Complex types allow creating enhanced
    versions of an existing (abstract or concrete) base type via an
    extension (see "extends extension statement").
 o  Recursive containment: In order to specify containment
    hierarchies, models frequently contain different aggregation
    associations, in which the target (contained element) is either
    the containing class itself or a base class of the containing
    class.  In the model above, the recursive containment of
    "EquipmentHolder" is an example of such a relationship (see the
    description for the "complex-type EquipmentHolder" in the example
    model "udmcore" below).
 o  Complex types support such a containment by using a complex type
    (or one of its ancestor types) as the type of an instance or
    instance list that is part of its definition (see "instance(-list)
    extension statement").
 o  Reference relationships: A key requirement on large models for
    network domains with many related managed objects is the ability
    to define inter-class associations that represent essential
    relationships between instances of such a class.  For example, the
    relationship between "PhysicalLink" and "Hardware" tells which
    physical link is connecting which hardware resources.  It is
    important to notice that this kind of relationship does not
    mandate any particular location of the two connected hardware
    instances in any MIB module.  Such containment-agnostic
    relationships can be represented by a typed instance identifier
    that embodies one direction of such an association (see Section 3,
    "Typed Instance Identifier").

Linowski, et al. Experimental [Page 9] RFC 6095 YANG Language Abstractions March 2011

 The YANG module excerpt below shows how the challenges listed above
 can be addressed by the Complex Types extension (module import prefix
 "ct:").  The complete YANG module for the physical resource model in
 Figure 1 can be found in Appendix A, "YANG Modules for Physical
 Network Resource Model and Hardware Entities Model".
 Note: The YANG extensions proposed in this document have been
 implemented as the open source tools "Pyang Extension for Complex
 Types" [Pyang-ct], [Pyang], and "Libsmi Extension for Complex Types"
 [Libsmi].  All model examples in the document have been validated
 with the tools Pyang-ct and Libsmi.

<CODE BEGINS>

module udmcore {

 namespace "http://example.com/udmcore";
 prefix "udm";
 import ietf-complex-types {prefix "ct"; }
      // Basic complex types...
 ct:complex-type PhysicalResource {
    ct:extends Resource;
      ct:abstract true;
      // ...
      leaf serialNumber {
       type string;
       description "'Manufacturer-allocated part number' as
         defined in SID, e.g., the part number of a fiber link
         cable.";
    }
 }
 ct:complex-type Hardware {
    ct:extends PhysicalResource;
      ct:abstract true;
      // ...
     leaf-list physicalLink {
        type instance-identifier {ct:instance-type PhysicalLink;}
     }
     ct:instance-list containedHardware {
     ct:instance-type Hardware;

}

     ct:instance-list physicalConnector {
     ct:instance-type PhysicalConnector;

Linowski, et al. Experimental [Page 10] RFC 6095 YANG Language Abstractions March 2011

}

 }
 ct:complex-type PhysicalLink {
     ct:extends PhysicalResource;
     // ...
     leaf-list hardware {
        type instance-identifier {ct:instance-type Hardware;}
     }
 }
 ct:complex-type ManagedHardware {
    ct:extends Hardware;
      ct:abstract true;
      // ...
 }
 ct:complex-type PhysicalConnector {
    ct:extends Hardware;
      leaf location {type string;}
      // ...
    leaf-list sourcePhysicalConnector {
       type instance-identifier {ct:instance-type PhysicalConnector;}
    }
    leaf-list targetPhysicalConnector {
       type instance-identifier {ct:instance-type PhysicalConnector;}
    }
 }
 ct:complex-type Equipment {
    ct:extends ManagedHardware;
      // ...
    ct:instance-list equipment {
  ct:instance-type Equipment;

}

 }
 ct:complex-type EquipmentHolder {
    ct:extends ManagedHardware;
    description "In the SID V8 definition, this is a class based on
      the M.3100 specification.  A base class that represents physical
      objects that are both manageable as well as able to host,
      hold, or contain other physical objects.  Examples of physical

Linowski, et al. Experimental [Page 11] RFC 6095 YANG Language Abstractions March 2011

      objects that can be represented by instances of this object
      class are Racks, Chassis, Cards, and Slots.
      A piece of equipment with the primary purpose of containing
      other equipment.";
      leaf vendorName {type string;}
      // ...
    ct:instance-list equipment {
     ct:instance-type Equipment;
      }
    ct:instance-list equipmentHolder {
     ct:instance-type EquipmentHolder;
     }
 }
 // ...

}

<CODE ENDS>

1.5.2. Modeling Entity MIB Entries as Physical Resources

 The physical resource module described above can now be used to model
 physical entities as defined in the Entity MIB [RFC4133].  For each
 physical entity class listed in the "PhysicalClass" enumeration, a
 complex type is defined.  Each of these complex types extends the
 most specific complex type already available in the physical resource
 module.  For example, the type "HWModule" extends the complex type
 "Equipment" as a hardware module.  Physical entity properties that
 should be included in a physical entity complex type are combined in
 a grouping, which is then used in each complex type definition of an
 entity.
 This approach has following benefits:
 o  The definition of the complex types for hardware entities becomes
    compact as many of the features can be reused from the basic
    complex type definition.
 o  Physical entities are modeled in a consistent manner as predefined
    concepts are extended.
 o  Entity-MIB-specific attributes as well as vendor-specific
    attributes can be added without having to define separate
    extension data nodes.

Linowski, et al. Experimental [Page 12] RFC 6095 YANG Language Abstractions March 2011

                          Module udmcore  :  Module hardware-entities
                                          :
                              equipment   :
                              Holder      :
                              0..*        :
                              +-------+   :
                              |       |   :
 +---------------+     +---------+    |   :
 |ManagedHardware|<|-+-|Equipment|<>--+   :
 +---------------+   | | Holder  |0..1    :     +-------+
                     | |         |<|---------+--|Chassis|
                     | +---------+        :  |  +-------+
                     |   <>               :  |
                     |   |0..* equipment  :  |  +---------+
                     |   |     Holder     :  '--|Container|
                     |   |                :     +---------+
                     |   |0..* equipment  :
                     |   |                :
                     |   |    equipment   :
                     |   |    0..*        :
                     |   |    +-------+   :
                     |   |    |       |   :
                     | +---------+    |   :
                     '-|Equipment|<>--+   :     +--------+
                       |         |<|---------+--|HWModule|
                       +---------+        :  |  +--------+
                    compositeEquipment    :  |
                                          :  |  +---------+
                                          :  |--|Backplane|
                                          :     +---------+
                   Figure 2: Hardware Entities Model
 Below is an excerpt of the corresponding YANG module using complex
 types to model hardware entities.  The complete YANG module for the
 Hardware Entities model in Figure 2 can be found in Appendix A, "YANG
 Modules for Physical Network Resource Model and Hardware Entities
 Model".

Linowski, et al. Experimental [Page 13] RFC 6095 YANG Language Abstractions March 2011

<CODE BEGINS>

module hardware-entities {

 namespace "http://example.com/hardware-entities";
 prefix "hwe";
 import ietf-yang-types {prefix "yt";}
 import ietf-complex-types {prefix "ct";}
 import udmcore {prefix "uc";}
 grouping PhysicalEntityProperties {
    // ...
    leaf mfgDate {type yang:date-and-time; }
    leaf-list uris {type string; }
 }
 // Physical entities representing equipment
 ct:complex-type HWModule {
    ct:extends uc:Equipment;
    description "Complex type representing module entries
                 (entPhysicalClass = module(9)) in entPhysicalTable";
    uses PhysicalEntityProperties;
 }
 // ...
 // Physical entities representing equipment holders
 ct:complex-type Chassis {
    ct:extends uc:EquipmentHolder;
    description "Complex type representing chassis entries
                 (entPhysicalClass = chassis(3)) in entPhysicalTable";
    uses PhysicalEntityProperties;
 }
 // ...

}

<CODE ENDS>

Linowski, et al. Experimental [Page 14] RFC 6095 YANG Language Abstractions March 2011

2. Complex Types

2.1. Definition

 YANG type concept is currently restricted to 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 substatements defined in Table 1 (e.g., lists, leafs,
 containers, choices).  A new complex type may extend an existing
 complex type.  This allows providing type-safe extensions to existing
 YANG models as instances of the new type.
 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 and adding new features.  Instances of
    such an extended type can be used wherever instances of the base
    type may 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 Extension Statement

 The extension statement "complex-type" is introduced; it accepts an
 arbitrary number of statements that define node trees, among other
 common YANG statements ("YANG Statements", Section 7 of [RFC6020]).

Linowski, et al. Experimental [Page 15] RFC 6095 YANG Language Abstractions March 2011

                  +------------------+-------------+
                  |   substatement   | cardinality |
                  +------------------+-------------+
                  |     abstract     |     0..1    |
                  |      anyxml      |     0..n    |
                  |      choice      |     0..n    |
                  |     container    |     0..n    |
                  |    description   |     0..1    |
                  |    ct:instance   |     0..n    |
                  | ct:instance-list |     0..n    |
                  |    ct: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    |
                  |    ordered-by    |     0..n    |
                  |     reference    |     0..1    |
                  |      refine      |     0..n    |
                  |      status      |     0..1    |
                  |      typedef     |     0..n    |
                  |       uses       |     0..n    |
                  +------------------+-------------+
                 Table 1: complex-type's Substatements
 Complex type definitions may appear at every place where a grouping
 may be defined.  That includes the module, submodule, rpc, input,
 output, notification, container, and list statements.
 Complex type names populate a distinct namespace.  As with YANG
 groupings, it is possible to define a complex type and a data node
 (e.g., leaf, list, instance statements) with the same name in the
 same scope.  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 instance key.  An instance key is either
 defined with the "key" statement as part of the complex type or is
 inherited from the base complex type.  It is not allowed to define an
 additional key if the base complex type or one of its ancestors
 already defines a key.
 Complex type definitions do not create nodes in the schema tree.

Linowski, et al. Experimental [Page 16] RFC 6095 YANG Language Abstractions March 2011

2.3. instance Extension Statement

 The "instance" extension statement is used to instantiate a complex
 type by creating a subtree in the management information node tree.
 The instance 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 instance is specified with the mandatory "ct:
 instance-type" substatement.  The type of an instance MUST be a
 complex type.  Common YANG statements may be used as substatements of
 the "instance" statement.  An instance is optional by default.  To
 make an instance mandatory, "mandatory true" has to be applied as a
 substatement.
                  +------------------+-------------+
                  |   substatement   | cardinality |
                  +------------------+-------------+
                  |    description   |     0..1    |
                  |      config      |     0..1    |
                  | ct:instance-type |      1      |
                  |    if-feature    |     0..n    |
                  |     mandatory    |     0..1    |
                  |       must       |     0..n    |
                  |     reference    |     0..1    |
                  |      status      |     0..1    |
                  |       when       |     0..1    |
                  |      anyxml      |     0..n    |
                  |      choice      |     0..n    |
                  |     container    |     0..n    |
                  |    ct:instance   |     0..n    |
                  | ct:instance-list |     0..n    |
                  |       leaf       |     0..n    |
                  |     leaf-list    |     0..n    |
                  |       list       |     0..n    |
                  +------------------+-------------+
                   Table 2: instance's Substatements
 The "instance" and "instance-list" extension statements (see
 Section 2.4, "instance-list Extension Statement") 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.
 It is also possible to add additional data nodes by using the
 corresponding leaf, leaf-list, list, and choice-statements, etc., as
 substatements of the instance declaration.  This is an in-place

Linowski, et al. Experimental [Page 17] RFC 6095 YANG Language Abstractions March 2011

 augmentation of the used complex type confined to a complex type
 instantiation (see also Section 2.13, "Using Complex Types", for
 details on augmenting complex types).

2.4. instance-list Extension Statement

 The "instance-list" extension statement is used to instantiate a
 complex type by defining a sequence of subtrees in the management
 information node tree.  In addition, the "instance-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 instance is specified with the mandatory "ct:
 instance-type" substatement.  In addition, it can be defined how
 often an instance may appear in the schema tree by using the "min-
 elements" and "max-elements" substatements.  Common YANG statements
 may be used as substatements of the "instance-list" statement.
 In analogy to the "instance" statement, YANG substatements like
 "list", "choice", "leaf", etc., MAY be used to augment the "instance-
 list" elements at the root level with additional data nodes.
                  +------------------+-------------+
                  |   substatementc  | cardinality |
                  +------------------+-------------+
                  |    description   |     0..1    |
                  |      config      |     0..1    |
                  | ct:instance-type |      1      |
                  |    if-feature    |     0..n    |
                  |   max-elements   |     0..1    |
                  |   min-elements   |     0..1    |
                  |       must       |     0..n    |
                  |    ordered-by    |     0..1    |
                  |     reference    |     0..1    |
                  |      status      |     0..1    |
                  |       when       |     0..1    |
                  |      anyxml      |     0..n    |
                  |      choice      |     0..n    |
                  |     container    |     0..n    |
                  |    ct:instance   |     0..n    |
                  | ct:instance-list |     0..n    |
                  |       leaf       |     0..n    |
                  |     leaf-list    |     0..n    |
                  |       list       |     0..n    |
                  +------------------+-------------+
                Table 3: instance-list's Substatements

Linowski, et al. Experimental [Page 18] RFC 6095 YANG Language Abstractions March 2011

 In case the instance list represents configuration data, the used
 complex type of an instance MUST have an instance key.
 Instances as well as instance lists may appear as arguments of the
 "deviate" statement.

2.5. extends Extension Statement

 A complex type MAY extend exactly one existing base complex type by
 using the "extends" extension statement.  The keyword "extends" MAY
 occur as a substatement of the "complex-type" extension statement.
 The argument of the "complex-type" extension statement refers to the
 base complex type via its 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

2.6. abstract Extension Statement

 Complex types may be declared to be abstract by using the "abstract"
 extension statement.  An abstract complex type cannot be
 instantiated, meaning it cannot appear as the most specific type of
 an instance in the NETCONF payload.  In case an abstract type extends
 a base type, the base complex type MUST be also abstract.  By
 default, complex types are not abstract.
 The abstract complex type serves only as a base type for derived
 concrete complex types and cannot be used as a type for an instance
 in the NETCONF payload.
 The "abstract" extension 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 a substatement,
 the default is "false".  The "abstract" statement does not support
 any substatements.

Linowski, et al. Experimental [Page 19] RFC 6095 YANG Language Abstractions March 2011

2.7. XML Encoding Rules

 An "instance" node is encoded as an XML element, where an "instance-
 list" node is encoded as a series of XML elements.  The corresponding
 XML element names are the "instance" and "instance-list" identifiers,
 respectively, and they use the same XML namespace as the module.
 Instance child nodes are encoded as subelements of the instance XML
 element.  Subelements representing child nodes defined in the same
 complex type may appear in any order.  However, child nodes of an
 extending complex type follow the child nodes of the extended complex
 type.  As such, the XML encoding of lists is similar to the encoding
 of containers and lists in YANG.
 Instance key nodes are encoded as subelements of the instance XML
 element.  Instance key nodes must appear in the same order as they
 are defined within the "key" statement of the corresponding complex
 type definition and precede all other nodes defined in the same
 complex type.  That is, if key nodes are defined in an extending
 complex type, XML elements representing key data precede all other
 XML elements representing child nodes.  On the other hand, XML
 elements representing key data follow the XML elements representing
 data nodes of the base type.
 The type of the actual complex type instance is encoded in a type
 element, which is put in front of all instance child elements,
 including key nodes, as described in Section 2.8 ("Type Encoding
 Rules").
 The proposed XML encoding rules conform to the YANG XML encoding
 rules in [RFC6020].  Compared to YANG, enabling key definitions in
 derived hierarchies is a new feature introduced with the complex
 types extension.  As a new language feature, complex types also
 introduce a new payload entry for the instance type identifier.
 Based on our implementation experience, the proposed XML encoding
 rules support consistent mapping of YANG models with complex types to
 an XML schema using XML complex types.

2.8. Type Encoding Rules

 In order to encode the type of an instance in the NETCONF payload,
 XML elements named "type" belonging to the XML namespace
 "urn:ietf:params:xml:ns:yang:ietf-complex-type-instance" are added to
 the serialized form of instance and instance-list nodes in the
 payload.  The suggested namespace prefix is "cti".  The "cti:type"
 XML elements are inserted before the serialized form of all members
 that have been declared in the corresponding complex type definition.

Linowski, et al. Experimental [Page 20] RFC 6095 YANG Language Abstractions March 2011

 The "cti:type" element is inserted for each type in the extension
 chain to the actual type of the instance (most specific last).  Each
 type name includes its corresponding namespace.
 The type of a complex type instance MUST be encoded in the reply to
 NETCONF <get> and <get-config> operations, and in the payload of a
 NETCONF <edit-config> operation if the operation is "create" or
 "replace".  The type of the instance MUST also be specified in case
 <copy-config> is used to export a configuration to a resource
 addressed with an URI.  The type of the instance has to be specified
 in user-defined remote procedure calls (RPCs).
 The type of the instance 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 attribute (type of a complex type instance) is specified but
 differs from the data in the target, an <rpc-error> element is
 returned with an <error-app-tag> value of "wrong-complex-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-attribute".
 The type MUST NOT be specified in case the operation is "delete".

2.9. Extension and Feature Definition Module

 The module below contains all YANG extension definitions for complex
 types and typed instance identifiers.  In addition, a "complex-type"
 feature is defined, which may be used to provide conditional or
 alternative modeling, depending on the support status of complex
 types in a NETCONF server.  A NETCONF server that supports the
 modeling features for complex types and the XML encoding for complex
 types as defined in this document MUST advertise this as a feature.
 This is done by including the feature name "complex-types" in the
 feature parameter list as part of the NETCONF <hello> message as
 described in Section 5.6.4 in [RFC6020].

<CODE BEGINS> file "ietf-complex-types@2011-03-15.yang"

module ietf-complex-types {

  namespace "urn:ietf:params:xml:ns:yang:ietf-complex-types";
  prefix "ct";
  organization

Linowski, et al. Experimental [Page 21] RFC 6095 YANG Language Abstractions March 2011

    "NETMOD WG";
  contact
    "Editor:  Bernd Linowski
              <bernd.linowski.ext@nsn.com>
     Editor:  Mehmet Ersue
              <mehmet.ersue@nsn.com>
     Editor:  Siarhei Kuryla
              <s.kuryla@gmail.com>";
  description
     "YANG extensions for complex types and typed instance
     identifiers.
     Copyright (c) 2011 IETF Trust and the persons identified as
     authors of the code.  All rights reserved.
     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject
     to the license terms contained in, the Simplified BSD License
     set forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (http://trustee.ietf.org/license-info).
     This version of this YANG module is part of RFC 6095; see
     the RFC itself for full legal notices.";
      revision 2011-03-15 {
          description "Initial revision.";
      }
       extension complex-type {
           description "Defines a complex-type.";
           reference "Section 2.2, complex-type Extension Statement";
           argument type-identifier {
               yin-element true;
           }
       }
       extension extends {
           description "Defines the base type of a complex-type.";
           reference "Section 2.5, extends Extension Statement";
           argument base-type-identifier {
               yin-element true;
           }
       }

Linowski, et al. Experimental [Page 22] RFC 6095 YANG Language Abstractions March 2011

       extension abstract {
           description "Makes the complex-type abstract.";
           reference "Section 2.6, abstract Extension Statement";
           argument status;
       }
       extension instance {
           description "Declares an instance of the given
                complex type.";
           reference "Section 2.3, instance Extension Statement";
           argument ct-instance-identifier {
               yin-element true;
           }
       }
       extension instance-list {
           description "Declares a list of instances of the given
                complex type";
           reference "Section 2.4, instance-list Extension Statement";
           argument ct-instance-identifier {
               yin-element true;
           }
       }
       extension instance-type {
           description "Tells to which type instance the instance
                        identifier refers.";
           reference "Section 3.2, instance-type Extension Statement";
           argument target-type-identifier {
               yin-element true;
           }
       }
       feature complex-types {
           description "Indicates that the server supports
                        complex types and instance identifiers.";
       }
  }

<CODE ENDS>

Linowski, et al. Experimental [Page 23] RFC 6095 YANG Language Abstractions March 2011

2.10. Example Model for Complex Types

 The example model below shows how complex types can be used to
 represent physical equipment in a vendor-independent, abstract way.
 It reuses the complex types defined in the physical resource model in
 Section 1.5.1.
 <CODE BEGINS>
 module hw {
    namespace "http://example.com/hw";
    prefix "hw";
    import ietf-complex-types {prefix "ct"; }
    import udmcore {prefix "uc"; }
    // Holder types
    ct:complex-type Slot {
            ct:extends uc:EquipmentHolder;
            leaf slotNumber { type uint16; config false; }
              // ...
    }
    ct:complex-type Chassis {
            ct:extends uc:EquipmentHolder;
            leaf numberOfChassisSlots { type uint32; config false; }
              // ..
    }
    // Equipment types
    ct:complex-type Card {
            ct:extends uc:Equipment;
            leaf position { type uint32; mandatory true; }
              leaf slotsRequired {type unit32; }
    }
    // Root Element
     ct:instance hardware { type uc:ManagedHardware; }
 } // hw module
 <CODE ENDS>

Linowski, et al. Experimental [Page 24] RFC 6095 YANG Language Abstractions March 2011

2.11. NETCONF Payload Example

 Following example shows the payload of a reply to a NETCONF <get>
 command.  The actual type of managed hardware instances is indicated
 with the "cti:type" elements as required by the type encoding rules.
 The containment hierarchy in the NETCONF XML payload reflects the
 containment hierarchy of hardware instances.  This makes filtering
 based on the containment hierarchy possible without having to deal
 with values of leafs of type leafref that represent the tree
 structure in a flattened hierarchy.

<hardware>

   <cti:type>uc:BasicObject</cti:type>
   <distinguishedName>/R-T31/CH-2</distinguishedName>
   <globalId>6278279001</globalId>
   <cti:type>uc:Resource</cti:type>
   <cti:type>uc:PhysicalResource</cti:type>
   <otherIdentifier>Rack R322-1</otherIdentifier>
   <serialNumber>R-US-3276279a</serialNumber>
   <cti:type>uc:Hardware</cti:type>
   <cti:type>uc:ManagedHardware</cti:type>
   <cti:type>hw:EquipmentHolder</cti:type>
   <equipmentHolder>
       <cti:type>uc:BasicObject</cti:type>
       <distinguishedName>/R-T31/CH-2/SL-1</distinguishedName>
       <globalId>548872003</globalId>
       <cti:type>uc:Resource</cti:type>
       <cti:type>uc:PhysicalResource</cti:type>
       <otherIdentifier>CU-Slot</otherIdentifier>
       <serialNumber>T-K4733890x45</serialNumber>
       <cti:type>uc:Hardware</cti:type>
       <cti:type>uc:ManagedHardware</cti:type>
       <cti:type>uc:EquipmentHolder</cti:type>
       <equipment>
           <cti:type>uc:BasicObject</cti:type>
           <distinguishedName>/R-T31/CH-2/SL-1/C-3</distinguishedName>
           <globalId>89772001</globalId>
           <cti:type>uc:Resource</cti:type>
           <cti:type>uc:PhysicalResource</cti:type>
           <otherIdentifier>ATM-45252</otherIdentifier>
           <serialNumber>A-778911-b</serialNumber>
           <cti:type>uc:Hardware</cti:type>
           <cti:type>uc:ManagedHardware</cti:type>
           <cti:type>uc:Equipment</cti:type>
           <installed>true</installed>
           <version>A2</version>
           <redundancy>1</redundancy>
           <cti:type>hw:Card</cti:type>

Linowski, et al. Experimental [Page 25] RFC 6095 YANG Language Abstractions March 2011

           <usedSlots>1</usedSlots>
       </equipment>
       <cti:type>hw:Slot</cti:type>
       <slotNumber>1</slotNumber>
   </equipmentHolder>
   <cti:type>hw:Chassis</cti:type>
   <numberOfChassisSlots>6</numberOfChassisSlots>
   // ...

</hardware>

2.12. Update Rules for Modules Using Complex Types

 In addition to the module update rules specified in Section 10 in
 [RFC6020], modules that define complex types, instances of complex
 types, and typed instance identifiers must obey following rules:
 o  New complex types MAY be added.
 o  A new complex type MAY extend an existing complex type.
 o  New data definition statements MAY be added to a complex type only
    if:
  • they are not mandatory or
  • they are not conditionally dependent on a new feature (i.e.,

they do not have an "if-feature" statement that refers to a new

       feature).
 o  The type referred to by the instance-type statement may be changed
    to a type that derives from the original type only if the original
    type does not represent configuration data.

2.13. Using Complex Types

 All data nodes defined inside a complex type reside in the complex
 type namespace, which is their parent node namespace.

2.13.1. Overriding Complex Type Data Nodes

 It is not allowed to override a data node inherited from a base type.
 That is, it is an error if a type "base" with a leaf named "foo" is
 extended by another complex type ("derived") with a leaf named "foo"
 in the same module.  In case they are derived in different modules,
 there are two distinct "foo" nodes that are mapped to the XML
 namespaces of the module, where the complex types are specified.

Linowski, et al. Experimental [Page 26] RFC 6095 YANG Language Abstractions March 2011

 A complex type that extends a basic complex type may use the "refine"
 statement in order to improve an inherited data node.  The target
 node identifier must be qualified by the module prefix to indicate
 clearly which inherited node is refined.
 The following refinements can be done:
 o  A leaf or choice node may have a default value, or a new default
    value if it already had one.
 o  Any node may have a different "description" or "reference" string.
 o  A leaf, anyxml, or choice node may have a "mandatory true"
    statement.  However, it is not allowed to change from "mandatory
    true" to "mandatory false".
 o  A leaf, leaf-list, list, container, or anyxml node may have
    additional "must" expressions.
 o  A list, leaf-list, instance, or instance-list node may have a
    "min-elements" statement, if the base type does not have one or
    does not have one with a value that is greater than the minimum
    value of the base type.
 o  A list, leaf-list, instance, or instance-list node may have a
    "max-elements" statement, if the base type does not have one or
    does not have one with a value that is smaller than the maximum
    value of the base type.
 It is not allowed to refine complex-type nodes inside "instance" or
 "instance-list" statements.

2.13.2. Augmenting Complex Types

 Augmenting complex types is only allowed if a complex type is
 instantiated in an "instance" or "instance-list" statement.  This
 confines the effect of the augmentation to the location in the schema
 tree where the augmentation is done.  The argument of the "augment"
 statement MUST be in the descendant form (as defined by the rule
 "descendant-schema-nodeid" in Section 12 in [RFC6020]).

Linowski, et al. Experimental [Page 27] RFC 6095 YANG Language Abstractions March 2011

    ct:complex-type Chassis {
            ct:extends EquipmentHolder;
            container chassisInfo {
                   config false;
                   leaf numberOfSlots { type uint16; }
                   leaf occupiedSlots { type uint16; }
                   leaf height {type unit16;}
                   leaf width {type unit16;}
              }
    }
    ct:instance-list chassis {
            type Chassis;
            augment "chassisInfo" {
                   leaf modelId { type string; }
            }
    }
 When augmenting a complex type, only the "container", "leaf", "list",
 "leaf-list", "choice", "instance", "instance-list", and "if-feature"
 statements may be used within the "augment" statement.  The nodes
 added by the augmentation MUST NOT be mandatory nodes.  One or many
 "augment" statements may not cause the creation of multiple nodes
 with the same name from the same namespace in the target node.
 To achieve less-complex modeling, this document proposes the
 augmentation of complex type instances without recursion.

2.13.3. Controlling the Use of Complex Types

 A server might not want to support all complex types defined in a
 supported module.  This issue can be addressed with YANG features as
 follows:
 o  Features are defined that are used inside complex type definitions
    (by using "if-feature" as a substatement) to make them optional.
    In this case, such complex types may only be instantiated if the
    feature is supported (advertised as a capability in the NETCONF
    <hello> message).
 o  The "deviation" statement may be applied to node trees, which are
    created by "instance" and "instance-list" statements.  In this
    case, only the substatement "deviate not-supported" is allowed.

Linowski, et al. Experimental [Page 28] RFC 6095 YANG Language Abstractions March 2011

 o  It is not allowed to apply the "deviation" statement to node tree
    elements that may occur because of the recursive use of a complex
    type.  Other forms of deviations ("deviate add", "deviate
    replace", "deviate delete") are NOT supported inside node trees
    spanned by "instance" or "instance-list".
 As complex type definitions do not contribute by themselves to the
 data node tree, data node declarations inside complex types cannot be
 the target of deviations.
 In the example below, client applications are informed that the leaf
 "occupiedSlots" is not supported in the top-level chassis.  However,
 if a chassis contains another chassis, the contained chassis may
 support the leaf that reports the number of occupied slots.
   deviation "/chassis/chassisSpec/occupiedSlots" {
      deviate not-supported;
   }

3. Typed Instance Identifier

3.1. Definition

 Typed instance identifier relationships are an addition to the
 relationship types already defined in YANG, where the leafref
 relationship is location dependent, and the instance-identifier does
 not specify to which type of instances the identifier points.
 A typed instance identifier represents a reference to an instance of
 a complex type without being restricted to a particular location in
 the containment tree.  This is done by using the extension statement
 "instance-type" as a substatement of the existing "type instance
 identifier" statement.
 Typed instance identifiers allow referring to instances of complex
 types that may be located anywhere in the schema tree.  The "type"
 statement plays the role of a restriction that must be fulfilled by
 the target node, which is referred to with the instance identifier.
 The target node MUST be of a particular complex type, either the type
 itself or any type that extends this complex type.

3.2. instance-type Extension Statement

 The "instance-type" extension statement specifies the complex type of
 the instance to which the instance-identifier refers.  The referred
 instance may also instantiate any complex type that extends the
 specified complex type.

Linowski, et al. Experimental [Page 29] RFC 6095 YANG Language Abstractions March 2011

 The instance complex type is identified by the single name argument.
 The referred complex type MUST have a key.  This extension statement
 MUST be used as a substatement of the "type instance-identifier"
 statement.  The "instance-type" extension statement does not support
 any substatements.

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".
      // Extended version of type Card
      ct:complex-type Card {
         ct:extends Equipment;
         leaf usedSlot { type uint16; mandatory true; }
         ct:instance-list port {
             type PhysicalPort;
         }
      }
      ct:complex-type PhysicalPort {
         ct:extends ManagedHardware;
         leaf portNumber { type int32; mandatory true; }
      }
      ct:complex-type PhysicalLink {
         ct:extends ManagedHardware;
         leaf media { type string; }
         leaf-list connectedPort {
            type instance-identifier {
              ct:instance-type PhysicalPort;
            }
            min-elements 2;
         }
      }
 Below is the XML encoding of an element named "link" of type
 "PhysicalLink":

Linowski, et al. Experimental [Page 30] RFC 6095 YANG Language Abstractions March 2011

     <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>
         <serialNumber>F-7786828</serialNumber>
         <commonName>FibCon 7</commonName>
     </link>

4. IANA Considerations

 This document registers two URIs in the IETF XML registry.  IANA
 registered the following URIs, according to [RFC3688]:
 URI: urn:ietf:params:xml:ns:yang:ietf-complex-types
 URI: urn:ietf:params:xml:ns:yang:ietf-complex-type-instance
 Registrant Contact:
 Bernd Linowski (bernd.linowski.ext@nsn.com)
 Mehmet Ersue (mehmet.ersue@nsn.com)
 Siarhei Kuryla (s.kuryla@gmail.com)
 XML: N/A, the requested URIs are XML namespaces.
 This document registers one module name in the "YANG Module Names"
 registry, defined in [RFC6020].
    name: ietf-complex-types
    namespace: urn:ietf:params:xml:ns:yang:ietf-complex-types
    prefix: ct
    RFC: 6095

5. Security Considerations

 The YANG module "complex-types" in this memo defines YANG extensions
 for complex types and typed instance identifiers as new language
 statements.
 Complex types and typed instance identifiers themselves do not have
 any security impact on the Internet.

Linowski, et al. Experimental [Page 31] RFC 6095 YANG Language Abstractions March 2011

 The security considerations described throughout [RFC6020] apply here
 as well.

6. Acknowledgements

 The authors would like to thank to Martin Bjorklund, Balazs Lengyel,
 Gerhard Muenz, Dan Romascanu, Juergen Schoenwaelder, and Martin
 Storch for their valuable review and comments on different versions
 of the document.

7. References

7.1. Normative References

 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
            January 2004.
 [RFC6020]  Bjorklund, M., "YANG - A Data Modeling Language for the
            Network Configuration Protocol (NETCONF)", RFC 6020,
            October 2010.

7.2. Informative References

 [IPFIXCONF]
            Muenz, G., Claise, B., and P. Aitken, "Configuration Data
            Model for IPFIX and PSAMP", Work in Progress, March 2011.
 [Libsmi]   Kuryla, S., "Libsmi Extension for Complex Types",
            April 2010, <http://www.ibr.cs.tu-bs.de/svn/libsmi>.
 [Pyang]    Bjorklund, M., "An extensible YANG validator and converter
            in python", October 2010,
            <http://code.google.com/p/pyang/>.
 [Pyang-ct]
            Kuryla, S., "Complex type extension for an extensible YANG
            validator and converter in python", April 2010,
            <http://code.google.com/p/pyang-ct/>.
 [RFC4133]  Bierman, A. and K. McCloghrie, "Entity MIB (Version 3)",
            RFC 4133, August 2005.

Linowski, et al. Experimental [Page 32] RFC 6095 YANG Language Abstractions March 2011

 [SID_V8]   TeleManagement Forum, "GB922, Information Framework (SID)
            Solution Suite, Release 8.0", July 2008, <http://
            www.tmforum.org/DocumentsInformation/
            GB922InformationFramework/35499/article.html>.
 [UDM]      NSN, "Unified Data Model SID Compliance Statement",
            May 2010, <http://www.tmforum.org/InformationFramework/
            NokiaSiemensNetworks/8815/home.html>.

Linowski, et al. Experimental [Page 33] RFC 6095 YANG Language Abstractions March 2011

Appendix A. YANG Modules for Physical Network Resource Model and

           Hardware Entities Model
 YANG module for the 'Physical Network Resource Model':
 <CODE BEGINS>
 module udmcore {
    namespace "http://example.com/udmcore";
    prefix "udm";
    import ietf-yang-types {prefix "yang";}
    import ietf-complex-types {prefix "ct";}
    ct:complex-type BasicObject {
       ct:abstract true;
       key "distinguishedName";
         leaf globalId {type int64;}
         leaf distinguishedName {type string; mandatory true;}
    }
    ct:complex-type ManagedObject {
       ct:extends BasicObject;
       ct:abstract true;
       leaf instance {type string;}
       leaf objectState {type int32;}
       leaf release {type string;}
    }
    ct:complex-type Resource {
             ct:extends ManagedObject;
             ct:abstract true;
       leaf usageState {type int16;}
       leaf managementMethodSupported {type string;}
       leaf managementMethodCurrent {type string;}
       leaf managementInfo {type string;}
       leaf managementDomain {type string;}
       leaf version {type string;}
       leaf entityIdentification {type string;}
       leaf description {type string;}
       leaf rootEntityType {type string;}
    }

Linowski, et al. Experimental [Page 34] RFC 6095 YANG Language Abstractions March 2011

    ct:complex-type LogicalResource {
       ct:extends Resource;
       ct:abstract true;
       leaf lrStatus {type int32;}
       leaf serviceState {type int32;}
       leaf isOperational {type boolean;}
    }
    ct:complex-type PhysicalResource {
       ct:extends Resource;
       ct:abstract true;
       leaf manufactureDate {type string;}
       leaf otherIdentifier {type string;}
       leaf powerState {type int32;}
       leaf serialNumber {type string;}
       leaf versionNumber {type string;}
    }
    ct:complex-type Hardware {
       ct:extends PhysicalResource;
       ct:abstract true;
       leaf width {type string;}
       leaf height {type string;}
       leaf depth {type string;}
       leaf measurementUnits {type int32;}
       leaf weight {type string;}
       leaf weightUnits {type int32;}
       leaf-list physicalLink {
          type instance-identifier {
             ct:instance-type PhysicalLink;
          }
       }
       ct:instance-list containedHardware {
          ct:instance-type Hardware;
       }
       ct:instance-list physicalConnector {
          ct:instance-type PhysicalConnector;
       }
    }
    ct:complex-type PhysicalLink {
       ct:extends PhysicalResource;
       leaf isWireless {type boolean;}
       leaf currentLength {type string;}
       leaf maximumLength {type string;}

Linowski, et al. Experimental [Page 35] RFC 6095 YANG Language Abstractions March 2011

       leaf mediaType {type int32;}
       leaf-list hardware {
          type instance-identifier {
             ct:instance-type Hardware;
          }
       }
    }
    ct:complex-type ManagedHardware {
       ct:extends Hardware;
       leaf additionalinfo {type string;}
       leaf physicalAlarmReportingEnabled {type boolean;}
       leaf pyhsicalAlarmStatus {type int32;}
       leaf coolingRequirements {type string;}
       leaf hardwarePurpose {type string;}
       leaf isPhysicalContainer {type boolean;}
    }
    ct:complex-type AuxiliaryComponent {
       ct:extends ManagedHardware;
       ct:abstract true;
    }
    ct:complex-type PhysicalPort {
       ct:extends ManagedHardware;
       leaf portNumber {type int32;}
       leaf duplexMode {type int32;}
       leaf ifType {type int32;}
       leaf vendorPortName {type string;}
    }
    ct:complex-type PhysicalConnector {
       ct:extends Hardware;
       leaf location {type string;}
       leaf cableType {type int32;}
       leaf gender {type int32;}
       leaf inUse {type boolean;}
       leaf pinDescription {type string;}
       leaf typeOfConnector {type int32;}
       leaf-list sourcePhysicalConnector {
          type instance-identifier {
             ct:instance-type PhysicalConnector;
          }
       }

Linowski, et al. Experimental [Page 36] RFC 6095 YANG Language Abstractions March 2011

       leaf-list targetPhysicalConnector {
          type instance-identifier {
             ct:instance-type PhysicalConnector;
          }
       }
    }
    ct:complex-type Equipment {
       ct:extends ManagedHardware;
       leaf installStatus {type int32;}
       leaf expectedEquipmentType {type string;}
       leaf installedEquipmentType {type string;}
       leaf installedVersion {type string;}
       leaf redundancy {type int32;}
       leaf vendorName {type string;}
       leaf dateOfLastService {type yang:date-and-time;}
       leaf interchangeability {type string;}
       leaf identificationCode {type string;}
       ct:instance-list equipment {
          ct:instance-type Equipment;
       }
    }
    ct:complex-type EquipmentHolder {
       ct:extends ManagedHardware;
       leaf vendorName {type string;}
       leaf locationName {type string;}
       leaf dateOfLastService {type yang:date-and-time;}
       leaf partNumber {type string;}
       leaf availabilityStatus {type int16;}
       leaf nameFromPlanningSystem {type string;}
       leaf modelNumber {type string;}
       leaf acceptableEquipmentList {type string;}
       leaf isSolitaryHolder {type boolean;}
       leaf holderStatus {type int16;}
       leaf interchangeability {type string;}
       leaf equipmentHolderSpecificType {type string; }
       leaf position {type string;}
       leaf atomicCompositeType {type int16;}
       leaf uniquePhysical {type boolean;}
       leaf physicalDescription {type string;}
       leaf serviceApproach {type string;}
       leaf mountingOptions {type int32;}
       leaf cableManagementStrategy {type string;}
       leaf isSecureHolder {type boolean;}
       ct:instance-list equipment {

Linowski, et al. Experimental [Page 37] RFC 6095 YANG Language Abstractions March 2011

          ct:instance-type Equipment;
             }
       ct:instance-list equipmentHolder {
          ct:instance-type EquipmentHolder;
       }
    }
    // ... other resource complex types ...
 }
 <CODE ENDS>
 YANG module for the 'Hardware Entities Model':
 <CODE BEGINS>
 module hardware-entities {
    namespace "http://example.com/:hardware-entities";
    prefix "hwe";
    import ietf-yang-types {prefix "yang";}
    import ietf-complex-types {prefix "ct";}
    import udmcore {prefix "uc";}
    grouping PhysicalEntityProperties {
       leaf hardwareRev {type string; }
       leaf firmwareRev {type string; }
       leaf softwareRev {type string; }
       leaf serialNum {type string; }
       leaf mfgName {type string; }
       leaf modelName {type string; }
       leaf alias {type string; }
       leaf ssetID{type string; }
       leaf isFRU {type boolean; }
       leaf mfgDate {type yang:date-and-time; }
       leaf-list uris {type string; }
    }
    // Physical entities representing equipment
    ct:complex-type Module {
       ct:extends uc:Equipment;
       description "Complex type representing module entries

Linowski, et al. Experimental [Page 38] RFC 6095 YANG Language Abstractions March 2011

          (entPhysicalClass = module(9)) in entPhysicalTable";
       uses PhysicalEntityProperties;
    }
    ct:complex-type Backplane {
       ct:extends uc:Equipment;
       description "Complex type representing backplane entries
          (entPhysicalClass = backplane(4)) in entPhysicalTable";
       uses PhysicalEntityProperties;
    }
    // Physical entities representing auxiliary hardware components
    ct:complex-type PowerSupply {
       ct:extends uc:AuxiliaryComponent;
       description "Complex type representing power supply entries
          (entPhysicalClass = powerSupply(6)) in entPhysicalTable";
       uses PhysicalEntityProperties;
    }
    ct:complex-type Fan {
       ct:extends uc:AuxiliaryComponent;
       description "Complex type representing fan entries
          (entPhysicalClass = fan(7)) in entPhysicalTable";
       uses PhysicalEntityProperties;
    }
    ct:complex-type Sensor {
       ct:extends uc:AuxiliaryComponent;
       description "Complex type representing sensor entries
          (entPhysicalClass = sensor(8)) in entPhysicalTable";
       uses PhysicalEntityProperties;
    }
    // Physical entities representing equipment holders
    ct:complex-type Chassis {
       ct:extends uc:EquipmentHolder;
       description "Complex type representing chassis entries
          (entPhysicalClass = chassis(3)) in entPhysicalTable";
       uses PhysicalEntityProperties;
    }
    ct:complex-type Container {
       ct:extends uc:EquipmentHolder;
       description "Complex type representing container entries

Linowski, et al. Experimental [Page 39] RFC 6095 YANG Language Abstractions March 2011

          (entPhysicalClass = container(5)) in entPhysicalTable";
       uses PhysicalEntityProperties;
    }
    ct:complex-type Stack {
       ct:extends uc:EquipmentHolder;
       description "Complex type representing stack entries
          (entPhysicalClass = stack(11)) in entPhysicalTable";
       uses PhysicalEntityProperties;
    }
    // Other kinds of physical entities
    ct:complex-type Port {
       ct:extends uc:PhysicalPort;
       description "Complex type representing port entries
          (entPhysicalClass = port(10)) in entPhysicalTable";
       uses PhysicalEntityProperties;
    }
    ct:complex-type CPU {
       ct:extends uc:Hardware;
       description "Complex type representing cpu entries
          (entPhysicalClass = cpu(12)) in entPhysicalTable";
       uses PhysicalEntityProperties;
    }
 }
 <CODE ENDS>

Appendix B. Example YANG Module for the IPFIX/PSAMP Model

B.1. Modeling Improvements for the IPFIX/PSAMP Model with Complex Types

    and Typed Instance Identifiers
 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 the 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.

Linowski, et al. Experimental [Page 40] RFC 6095 YANG Language Abstractions March 2011

 o  All associations between the concepts (besides containment) are
    represented with typed identifiers.  That avoids having to refer
    to a particular location in the tree.  Referring to a particular
    in the tree is not mandated by the original model.
 o  It is superfluous to represent concept refinement (class
    inheritance in the original model) with containment in the form of
    quite big choice-statements with complex branches.  Instead,
    concept refinement is realized by complex types extending a base
    complex type.
 o  It is unnecessary to introduce metadata identities and leafs
    (e.g., "identity cacheMode" and "leaf cacheMode" in "grouping
    cacheParameters") that just serve the purpose of indicating which
    concrete subtype of a generic type (modeled as grouping, which
    contains the union of all features of all subtypes) is actually
    represented in the MIB.
 o  Ruling out illegal use of subtype-specific properties (e.g., "leaf
    maxFlows") by using "when" statements that refer to a subtype
    discriminator is not necessary (e.g., when "../cacheMode !=
    'immediate'").
 o  Defining properties like the configuration status wherever a so
    called "parameter grouping" is used is not necessary.  Instead,
    those definitions can be put inside the complex type definition
    itself.
 o  Separating the declaration of the key from the related data nodes
    definitions in a grouping (see use of "grouping
    selectorParameters") can be avoided.
 o  Complex types may be declared as optional features.  If the type
    is indicated with an identity (e.g., "identity immediate"), this
    is not possible, since "if-feature" is not allowed as a
    substatement of "identity".

B.2. IPFIX/PSAMP Model with Complex Types and Typed Instance

    Identifiers

<CODE BEGINS> module ct-ipfix-psamp-example {

   namespace "http://example.com/ns/ct-ipfix-psamp-example";
   prefix ipfix;
   import ietf-yang-types { prefix yang; }
   import ietf-inet-types { prefix inet; }
   import ietf-complex-types {prefix "ct"; }

Linowski, et al. Experimental [Page 41] RFC 6095 YANG Language Abstractions March 2011

   description "Example IPFIX/PSAMP Configuration Data Model
     with complex types and typed instance identifiers";
   revision 2011-03-15 {
      description "The YANG Module ('YANG Module of the IPFIX/PSAMP
        Configuration Data Model') in [IPFIXCONF] modeled with
        complex types and typed instance identifiers.
        Disclaimer: This example model illustrates the use of the
        language extensions defined in this document and does not
        claim to be an exact reproduction of the original YANG
        model referred above. The original description texts have
        been shortened to increase the readability of the model
        example.";
  }
   /*****************************************************************
   * Features
   *****************************************************************/
   feature exporter {
     description "If supported, the Monitoring Device can be used as
       an Exporter.  Exporting Processes can be configured.";
   }
   feature collector {
     description "If supported, the Monitoring 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 Monitoring Device supports
       count-based Sampling...";
   }
   feature psampSampTimeBased {
     description "If supported, the Monitoring Device supports
       time-based Sampling...";
   }
   feature psampSampRandOutOfN {
     description "If supported, the Monitoring Device supports
       random n-out-of-N Sampling...";
   }

Linowski, et al. Experimental [Page 42] RFC 6095 YANG Language Abstractions March 2011

   feature psampSampUniProb {
     description "If supported, the Monitoring Device supports
       uniform probabilistic Sampling...";
   }
   feature psampFilterMatch {
     description "If supported, the Monitoring Device supports
       property match Filtering...";
   }
   feature psampFilterHash {
     description "If supported, the Monitoring Device supports
       hash-based Filtering...";
   }
   feature cacheModeImmediate {
     description "If supported, the Monitoring Device supports
       Cache Mode 'immediate'.";
   }
   feature cacheModeTimeout {
     description "If supported, the Monitoring Device supports
       Cache Mode 'timeout'.";
   }
   feature cacheModeNatural {
     description "If supported, the Monitoring Device supports
       Cache Mode 'natural'.";
   }
   feature cacheModePermanent {
     description "If supported, the Monitoring Device supports
       Cache Mode 'permanent'.";
   }
   feature udpTransport {
     description "If supported, the Monitoring Device supports UDP
       as transport protocol.";
   }
   feature tcpTransport {
     description "If supported, the Monitoring Device supports TCP
       as transport protocol.";
   }
   feature fileReader {
     description "If supported, the Monitoring Device supports the
       configuration of Collecting Processes as File Readers.";

Linowski, et al. Experimental [Page 43] RFC 6095 YANG Language Abstractions March 2011

   }
   feature fileWriter {
     description "If supported, the Monitoring Device supports the
       configuration of Exporting Processes as File Writers.";
   }
   /*****************************************************************
   * Identities
   *****************************************************************/
   /*** Hash function identities ***/
   identity hashFunction {
     description "Base identity for all hash functions...";
   }
   identity BOB {
     base "hashFunction";
     description "BOB hash function";
     reference "RFC 5475, Section 6.2.4.1.";
   }
   identity IPSX {
     base "hashFunction";
     description "IPSX hash function";
     reference "RFC 5475, Section 6.2.4.1.";
   }
   identity CRC {
     base "hashFunction";
     description "CRC hash function";
     reference "RFC 5475, Section 6.2.4.1.";
   }
   /*** Export mode identities ***/
   identity exportMode {
     description "Base identity for different usages of export
       destinations configured for an Exporting Process...";
   }
   identity parallel {
     base "exportMode";
     description "Parallel export of Data Records to all
       destinations configured for the Exporting Process.";
   }
   identity loadBalancing {
     base "exportMode";
     description "Load-balancing between the different
       destinations...";
   }
   identity fallback {
     base "exportMode";

Linowski, et al. Experimental [Page 44] RFC 6095 YANG Language Abstractions March 2011

     description "Export to the primary destination...";
   }
   /*** Options type identities ***/
   identity optionsType {
     description "Base identity for report types exported
        with options...";
   }
   identity meteringStatistics {
     base "optionsType";
     description "Metering Process Statistics.";
     reference "RFC 5101, Section 4.1.";
   }
   identity meteringReliability {
     base "optionsType";
     description "Metering Process Reliability Statistics.";
     reference "RFC 5101, Section 4.2.";
   }
   identity exportingReliability {
     base "optionsType";
     description "Exporting Process Reliability
       Statistics.";
     reference "RFC 5101, Section 4.3.";
   }
   identity flowKeys {
     base "optionsType";
     description "Flow Keys.";
     reference "RFC 5101, Section 4.4.";
   }
   identity selectionSequence {
     base "optionsType";
     description "Selection Sequence and Selector Reports.";
     reference "RFC 5476, Sections 6.5.1 and 6.5.2.";
   }
   identity selectionStatistics {
     base "optionsType";
     description "Selection Sequence Statistics Report.";
     reference "RFC 5476, Sections 6.5.3.";
   }
   identity accuracy {
     base "optionsType";
     description "Accuracy Report.";
     reference "RFC 5476, Section 6.5.4.";
   }
   identity reducingRedundancy {
     base "optionsType";
     description "Enables the utilization of Options Templates to
       reduce redundancy in the exported Data Records.";

Linowski, et al. Experimental [Page 45] RFC 6095 YANG Language Abstractions March 2011

     reference "RFC 5473.";
   }
   identity extendedTypeInformation {
     base "optionsType";
     description "Export of extended type information for
       enterprise-specific Information Elements used in the
       exported Templates.";
     reference "RFC 5610.";
   }
   /*****************************************************************
   * Type definitions
   *****************************************************************/
   typedef nameType {
     type string {
       length "1..max";
       pattern "\S(.*\S)?";
     }
     description "Type for 'name' leafs...";
   }
   typedef direction {
     type enumeration {
       enum ingress {
         description "This value is used for monitoring incoming
           packets.";
       }
       enum egress {
         description "This value is used for monitoring outgoing
           packets.";
       }
       enum both {
         description "This value is used for monitoring incoming and
           outgoing packets.";
       }
     }
     description "Direction of packets going through an interface or
       linecard.";
   }
   typedef transportSessionStatus {
     type enumeration {
       enum inactive {
         description "This value MUST be used for...";
       }
       enum active {
         description "This value MUST be used for...";

Linowski, et al. Experimental [Page 46] RFC 6095 YANG Language Abstractions March 2011

       }
       enum unknown {
         description "This value MUST be used if the status...";
       }
     }
     description "Status of a Transport Session.";
     reference "RFC 5815, Section 8 (ipfixTransportSessionStatus).";
   }
   /*****************************************************************
   * Complex types
   *****************************************************************/
   ct:complex-type ObservationPoint {
     description "Observation Point";
     key name;
     leaf name {
       type nameType;
       description "Key of an observation point.";
     }
     leaf observationPointId {
       type uint32;
       config false;
       description "Observation Point ID...";
       reference "RFC 5102, Section 5.1.10.";
     }
     leaf observationDomainId {
       type uint32;
       mandatory true;
       description "The Observation Domain ID associates...";
       reference "RFC 5101.";
     }
     choice OPLocation {
       mandatory true;
       description "Location of the Observation Point.";
       leaf ifIndex {
         type uint32;
         description "Index of an interface...";
         reference "RFC 2863.";
       }
       leaf ifName {
         type string;
         description "Name of an interface...";
         reference "RFC 2863.";
       }
       leaf entPhysicalIndex {
         type uint32;
         description "Index of a linecard...";

Linowski, et al. Experimental [Page 47] RFC 6095 YANG Language Abstractions March 2011

         reference "RFC 4133.";
       }
       leaf entPhysicalName {
         type string;
         description "Name of a linecard...";
         reference "RFC 4133.";
       }
     }
     leaf direction {
       type direction;
       default both;
       description "Direction of packets....";
     }
     leaf-list selectionProcess {
       type instance-identifier { ct:instance-type SelectionProcess; }
       description "Selection Processes in this list process packets
         in parallel.";
     }
   }
   ct:complex-type Selector {
     ct:abstract true;
     description "Abstract selector";
     key name;
     leaf name {
         type nameType;
         description "Key of a selector";
     }
     leaf packetsObserved {
       type yang:counter64;
       config false;
       description "The number of packets observed ...";
       reference "RFC 5815, Section 8
         (ipfixSelectionProcessStatsPacketsObserved).";
     }
     leaf packetsDropped {
       type yang:counter64;
       config false;
       description "The total number of packets discarded ...";
       reference "RFC 5815, Section 8
         (ipfixSelectionProcessStatsPacketsDropped).";
     }
     leaf selectorDiscontinuityTime {
       type yang:date-and-time;
       config false;
       description "Timestamp of the most recent occasion at which
         one or more of the Selector counters suffered a
         discontinuity...";

Linowski, et al. Experimental [Page 48] RFC 6095 YANG Language Abstractions March 2011

       reference "RFC 5815, Section 8
         (ipfixSelectionProcessStatsDiscontinuityTime).";
     }
   }
   ct:complex-type SelectAllSelector {
     ct:extends Selector;
     description "Method that selects all packets.";
   }
   ct:complex-type SampCountBasedSelector {
         if-feature psampSampCountBased;
         ct:extends Selector;
         description "Selector applying systematic count-based
           packet sampling to the packet stream.";
         reference "RFC 5475, Section 5.1;
           RFC 5476, Section 6.5.2.1.";
         leaf packetInterval {
           type uint32;
           units packets;
           mandatory true;
           description "The number of packets that are consecutively
             sampled between gaps of length packetSpace.
             This parameter corresponds to the Information Element
             samplingPacketInterval.";
           reference "RFC 5477, Section 8.2.2.";
         }
         leaf packetSpace {
           type uint32;
           units packets;
           mandatory true;
           description "The number of unsampled packets between two
             sampling intervals.
             This parameter corresponds to the Information Element
             samplingPacketSpace.";
           reference "RFC 5477, Section 8.2.3.";
         }
   }
   ct:complex-type SampTimeBasedSelector {
         if-feature psampSampTimeBased;
         ct:extends Selector;
         description "Selector applying systematic time-based
           packet sampling to the packet stream.";
         reference "RFC 5475, Section 5.1;
           RFC 5476, Section 6.5.2.2.";
         leaf timeInterval {
           type uint32;

Linowski, et al. Experimental [Page 49] RFC 6095 YANG Language Abstractions March 2011

           units microseconds;
           mandatory true;
           description "The time interval in microseconds during
             which all arriving packets are sampled between gaps
             of length timeSpace.
             This parameter corresponds to the Information Element
             samplingTimeInterval.";
           reference "RFC 5477, Section 8.2.4.";
         }
         leaf timeSpace {
           type uint32;
           units microseconds;
           mandatory true;
           description "The time interval in microseconds during
             which no packets are sampled between two sampling
             intervals specified by timeInterval.
             This parameter corresponds to the Information Element
             samplingTimeInterval.";
           reference "RFC 5477, Section 8.2.5.";
         }
   }
   ct:complex-type SampRandOutOfNSelector {
         if-feature psampSampRandOutOfN;
         ct:extends Selector;
         description "This container contains the configuration
           parameters of a Selector applying n-out-of-N packet
           sampling to the packet stream.";
         reference "RFC 5475, Section 5.2.1;
           RFC 5476, Section 6.5.2.3.";
         leaf size {
           type uint32;
           units packets;
           mandatory true;
           description "The number of elements taken from the parent
             population.
             This parameter corresponds to the Information Element
             samplingSize.";
           reference "RFC 5477, Section 8.2.6.";
         }
         leaf population {
           type uint32;
           units packets;
           mandatory true;
           description "The number of elements in the parent
             population.
             This parameter corresponds to the Information Element
             samplingPopulation.";

Linowski, et al. Experimental [Page 50] RFC 6095 YANG Language Abstractions March 2011

           reference "RFC 5477, Section 8.2.7.";
         }
   }
   ct:complex-type SampUniProbSelector {
         if-feature psampSampUniProb;
         ct:extends Selector;
         description "Selector applying uniform probabilistic
           packet sampling (with equal probability per packet) to the
           packet stream.";
         reference "RFC 5475, Section 5.2.2.1;
           RFC 5476, Section 6.5.2.4.";
         leaf probability {
           type decimal64 {
             fraction-digits 18;
             range "0..1";
           }
           mandatory true;
           description "Probability that a packet is sampled,
             expressed as a value between 0 and 1.  The probability
             is equal for every packet.
             This parameter corresponds to the Information Element
             samplingProbability.";
           reference "RFC 5477, Section 8.2.8.";
         }
   }
   ct:complex-type FilterMatchSelector {
         if-feature psampFilterMatch;
         ct:extends Selector;
         description "This container contains the configuration
           parameters of a Selector applying property match filtering
           to the packet stream.";
         reference "RFC 5475, Section 6.1;
           RFC 5476, Section 6.5.2.5.";
         choice nameOrId {
           mandatory true;
           description "The field to be matched is specified by
             either the name or the ID of the Information
             Element.";
           leaf ieName {
             type string;
             description "Name of the Information Element.";
           }
           leaf ieId {
             type uint16 {
               range "1..32767" {
                 description "Valid range of Information Element

Linowski, et al. Experimental [Page 51] RFC 6095 YANG Language Abstractions March 2011

                     identifiers.";
                 reference "RFC 5102, Section 4.";
               }
             }
             description "ID of the Information Element.";
           }
         }
         leaf ieEnterpriseNumber {
           type uint32;
           description "If present, ... ";
         }
         leaf value {
           type string;
           mandatory true;
           description "Matching value of the Information Element.";
         }
   }
   ct:complex-type FilterHashSelector {
         if-feature psampFilterHash;
         ct:extends Selector;
         description "This container contains the configuration
           parameters of a Selector applying hash-based filtering
           to the packet stream.";
         reference "RFC 5475, Section 6.2;
           RFC 5476, Section 6.5.2.6.";
         leaf hashFunction {
           type identityref {
             base "hashFunction";
           }
           default BOB;
           description "Hash function to be applied.  According to
             RFC 5475, Section 6.2.4.1, BOB hash function must be
             used in order to be compliant with PSAMP.";
         }
         leaf ipPayloadOffset {
           type uint64;
           units octets;
           default 0;
           description "IP payload offset ... ";
           reference "RFC 5477, Section 8.3.2.";
         }
         leaf ipPayloadSize {
           type uint64;
           units octets;
           default 8;
           description "Number of IP payload bytes ... ";
           reference "RFC 5477, Section 8.3.3.";

Linowski, et al. Experimental [Page 52] RFC 6095 YANG Language Abstractions March 2011

         }
         leaf digestOutput {
           type boolean;
           default false;
           description "If true, the output ... ";
           reference "RFC 5477, Section 8.3.8.";
         }
         leaf initializerValue {
           type uint64;
           description "Initializer value to the hash function.
             If not configured by the user, the Monitoring Device
             arbitrarily chooses an initializer value.";
           reference "RFC 5477, Section 8.3.9.";
         }
         list selectedRange {
           key name;
           min-elements 1;
           description "List of hash function return ranges for
             which packets are selected.";
           leaf name {
             type nameType;
             description "Key of this list.";
           }
           leaf min {
             type uint64;
             description "Beginning of the hash function's selected
               range.
               This parameter corresponds to the Information Element
               hashSelectedRangeMin.";
             reference "RFC 5477, Section 8.3.6.";
           }
           leaf max {
             type uint64;
             description "End of the hash function's selected range.
               This parameter corresponds to the Information Element
               hashSelectedRangeMax.";
             reference "RFC 5477, Section 8.3.7.";
           }
         }
   }
   ct:complex-type Cache {
     ct:abstract true;
     description "Cache of a Monitoring Device.";
     key name;
     leaf name {
       type nameType;
       description "Key of a cache";

Linowski, et al. Experimental [Page 53] RFC 6095 YANG Language Abstractions March 2011

     }
     leaf-list exportingProcess {
       type leafref { path "/ipfix/exportingProcess/name"; }
       description "Records are exported by all Exporting Processes
         in the list.";
     }
     description "Configuration and state parameters of a Cache.";
     container cacheLayout {
       description "Cache Layout.";
       list cacheField {
         key name;
         min-elements 1;
         description "List of fields in the Cache Layout.";
         leaf name {
           type nameType;
           description "Key of this list.";
         }
         choice nameOrId {
           mandatory true;
           description "Name or ID of the Information Element.";
           reference "RFC 5102.";
           leaf ieName {
             type string;
             description "Name of the Information Element.";
           }
           leaf ieId {
             type uint16 {
               range "1..32767" {
                 description "Valid range of Information Element
                     identifiers.";
                 reference "RFC 5102, Section 4.";
               }
             }
             description "ID of the Information Element.";
           }
         }
         leaf ieLength {
           type uint16;
           units octets;
           description "Length of the field ... ";
           reference "RFC 5101, Section 6.2; RFC 5102.";
         }
         leaf ieEnterpriseNumber {
           type uint32;
           description "If present, the Information Element is
             enterprise-specific. ... ";
           reference "RFC 5101; RFC 5102.";
         }

Linowski, et al. Experimental [Page 54] RFC 6095 YANG Language Abstractions March 2011

         leaf isFlowKey {
           when "(../../../cacheMode != 'immediate')
             and
             ((count(../ieEnterpriseNumber) = 0)
             or
             (../ieEnterpriseNumber != 29305))" {
             description "This parameter is not available
               for Reverse Information Elements (which have
               enterprise number 29305) or if the Cache Mode
               is 'immediate'.";
           }
           type empty;
           description "If present, this is a flow key.";
         }
       }
     }
     leaf dataRecords {
       type yang:counter64;
       units "Data Records";
       config false;
       description "The number of Data Records generated ... ";
       reference "RFC 5815, Section 8
         (ipfixMeteringProcessCacheDataRecords).";
     }
     leaf cacheDiscontinuityTime {
       type yang:date-and-time;
       config false;
       description "Timestamp of the ... ";
       reference "RFC 5815, Section 8
         (ipfixMeteringProcessCacheDiscontinuityTime).";
     }
   }
   ct:complex-type ImmediateCache {
     if-feature cacheModeImmediate;
     ct:extends Cache;
   }
   ct:complex-type NonImmediateCache {
     ct:abstract true;
     ct:extends Cache;
     leaf maxFlows {
       type uint32;
       units flows;
       description "This parameter configures the maximum number of
         Flows in the Cache ... ";
     }

Linowski, et al. Experimental [Page 55] RFC 6095 YANG Language Abstractions March 2011

     leaf activeFlows {
       type yang:gauge32;
       units flows;
       config false;
       description "The number of Flows currently active in this
         Cache.";
       reference "RFC 5815, Section 8
         (ipfixMeteringProcessCacheActiveFlows).";
     }
     leaf unusedCacheEntries {
       type yang:gauge32;
       units flows;
       config false;
       description "The number of unused Cache entries in this
         Cache.";
       reference "RFC 5815, Section 8
         (ipfixMeteringProcessCacheUnusedCacheEntries).";
     }
  }
  ct:complex-type NonPermanentCache {
    ct:abstract true;
    ct:extends NonImmediateCache;
    leaf activeTimeout {
      type uint32;
      units milliseconds;
      description "This parameter configures the time in
        milliseconds after which ... ";
    }
    leaf inactiveTimeout {
      type uint32;
      units milliseconds;
      description "This parameter configures the time in
        milliseconds after which ... ";
    }
  }
  ct:complex-type NaturalCache {
    if-feature cacheModeNatural;
    ct:extends NonPermanentCache;
  }
  ct:complex-type TimeoutCache {
    if-feature cacheModeTimeout;
    ct:extends NonPermanentCache;
  }
  ct:complex-type PermanentCache {

Linowski, et al. Experimental [Page 56] RFC 6095 YANG Language Abstractions March 2011

    if-feature cacheModePermanent;
    ct:extends NonImmediateCache;
    leaf exportInterval {
      type uint32;
      units milliseconds;
      description "This parameter configures the interval for
        periodical export of Flow Records in milliseconds.
        If not configured by the user, the Monitoring Device sets
        this parameter.";
     }
  }
  ct:complex-type ExportDestination {
    ct:abstract true;
    description "Abstract export destination.";
    key name;
    leaf name {
      type nameType;
      description "Key of an export destination.";
    }
  }
  ct:complex-type IpDestination {
    ct:abstract true;
    ct:extends ExportDestination;
    description "IP export destination.";
    leaf ipfixVersion {
       type uint16;
       default 10;
       description "IPFIX version number.";
     }
     leaf destinationPort {
       type inet:port-number;
       description "If not configured by the user, the Monitoring
         Device uses the default port number for IPFIX, which is
         4739 without Transport Layer Security, and 4740 if Transport
         Layer Security is activated.";
     }
     choice indexOrName {
       description "Index or name of the interface ... ";
       reference "RFC 2863.";
       leaf ifIndex {
         type uint32;
         description "Index of an interface as stored in the ifTable
           of IF-MIB.";
         reference "RFC 2863.";
       }
       leaf ifName {

Linowski, et al. Experimental [Page 57] RFC 6095 YANG Language Abstractions March 2011

         type string;
         description "Name of an interface as stored in the ifTable
           of IF-MIB.";
         reference "RFC 2863.";
       }
     }
     leaf sendBufferSize {
       type uint32;
       units bytes;
       description "Size of the socket send buffer.
         If not configured by the user, this parameter is set by
         the Monitoring Device.";
     }
     leaf rateLimit {
       type uint32;
       units "bytes per second";
       description "Maximum number of bytes per second ... ";
       reference "RFC 5476, Section 6.3";
     }
     container transportLayerSecurity {
       presence "If transportLayerSecurity is present, DTLS is
         enabled if the transport protocol is SCTP or UDP, and TLS
         is enabled if the transport protocol is TCP.";
       description "Transport Layer Security configuration.";
       uses transportLayerSecurityParameters;
     }
     container transportSession {
       config false;
       description "State parameters of the Transport Session
         directed to the given destination.";
       uses transportSessionParameters;
     }
  }
   ct:complex-type SctpExporter {
     ct:extends IpDestination;
     description "SCTP exporter.";
     leaf-list sourceIPAddress {
       type inet:ip-address;
       description "List of source IP addresses used ... ";
       reference "RFC 4960, Section 6.4
         (Multi-Homed SCTP Endpoints).";
     }
     leaf-list destinationIPAddress {
       type inet:ip-address;
       min-elements 1;
       description "One or multiple IP addresses ... ";
       reference "RFC 4960, Section 6.4

Linowski, et al. Experimental [Page 58] RFC 6095 YANG Language Abstractions March 2011

         (Multi-Homed SCTP Endpoints).";
     }
     leaf timedReliability {
       type uint32;
       units milliseconds;
       default 0;
       description "Lifetime in milliseconds ... ";
       reference "RFC 3758; RFC 4960.";
     }
   }
   ct:complex-type UdpExporter {
     ct:extends IpDestination;
     if-feature udpTransport;
     description "UDP parameters.";
     leaf sourceIPAddress {
       type inet:ip-address;
       description "Source IP address used by the Exporting
          Process ...";
     }
     leaf destinationIPAddress {
       type inet:ip-address;
       mandatory true;
       description "IP address of the Collection Process to which
         IPFIX Messages are sent.";
     }
     leaf maxPacketSize {
       type uint16;
       units octets;
       description "This parameter specifies the maximum size of
         IP packets ... ";
     }
     leaf templateRefreshTimeout {
       type uint32;
       units seconds;
       default 600;
       description "Sets time after which Templates are resent in the
         UDP Transport Session. ... ";
       reference "RFC 5101, Section 10.3.6; RFC 5815, Section 8
         (ipfixTransportSessionTemplateRefreshTimeout).";
     }
     leaf optionsTemplateRefreshTimeout {
       type uint32;
       units seconds;
       default 600;
       description "Sets time after which Options Templates are
         resent in the UDP Transport Session. ... ";
       reference "RFC 5101, Section 10.3.6; RFC 5815, Section 8

Linowski, et al. Experimental [Page 59] RFC 6095 YANG Language Abstractions March 2011

         (ipfixTransportSessionOptionsTemplateRefreshTimeout).";
     }
     leaf templateRefreshPacket {
       type uint32;
       units "IPFIX Messages";
       description "Sets number of IPFIX Messages after which
         Templates are resent in the UDP Transport Session. ... ";
       reference "RFC 5101, Section 10.3.6; RFC 5815, Section 8
         (ipfixTransportSessionTemplateRefreshPacket).";
     }
     leaf optionsTemplateRefreshPacket {
       type uint32;
       units "IPFIX Messages";
       description "Sets number of IPFIX Messages after which
         Options Templates are resent in the UDP Transport Session
         protocol. ... ";
       reference "RFC 5101, Section 10.3.6; RFC 5815, Section 8
         (ipfixTransportSessionOptionsTemplateRefreshPacket).";
     }
  }
   ct:complex-type TcpExporter {
     ct:extends IpDestination;
     if-feature tcpTransport;
     description "TCP exporter";
     leaf sourceIPAddress {
       type inet:ip-address;
       description "Source IP address used by the Exporting
         Process...";
     }
     leaf destinationIPAddress {
       type inet:ip-address;
       mandatory true;
       description "IP address of the Collection Process to which
         IPFIX Messages are sent.";
     }
   }
   ct:complex-type FileWriter {
     ct:extends ExportDestination;
     if-feature fileWriter;
     description "File Writer.";
     leaf ipfixVersion {
       type uint16;
       default 10;
       description "IPFIX version number.";
     }
     leaf file {

Linowski, et al. Experimental [Page 60] RFC 6095 YANG Language Abstractions March 2011

       type inet:uri;
       mandatory true;
       description "URI specifying the location of the file.";
     }
     leaf bytes {
       type yang:counter64;
       units octets;
       config false;
       description "The number of bytes written by the File
         Writer...";
     }
     leaf messages {
       type yang:counter64;
       units "IPFIX Messages";
       config false;
       description "The number of IPFIX Messages written by the File
         Writer. ... ";
     }
     leaf discardedMessages {
       type yang:counter64;
       units "IPFIX Messages";
       config false;
       description "The number of IPFIX Messages that could not be
         written by the File Writer ... ";
     }
     leaf records {
       type yang:counter64;
       units "Data Records";
       config false;
       description "The number of Data Records written by the File
         Writer. ... ";
     }
     leaf templates {
       type yang:counter32;
       units "Templates";
       config false;
       description "The number of Template Records (excluding
         Options Template Records) written by the File Writer.
         ... ";
     }
     leaf optionsTemplates {
       type yang:counter32;
       units "Options Templates";
       config false;
       description "The number of Options Template Records written
         by the File Writer. ... ";
     }
     leaf fileWriterDiscontinuityTime {

Linowski, et al. Experimental [Page 61] RFC 6095 YANG Language Abstractions March 2011

       type yang:date-and-time;
       config false;
       description "Timestamp of the most recent occasion at which
         one or more File Writer counters suffered a discontinuity.
         ... ";
     }
     list template {
       config false;
       description "This list contains the Templates and Options
         Templates that have been written by the File Reader. ... ";
       uses templateParameters;
     }
   }
   ct:complex-type ExportingProcess {
     if-feature exporter;
     description "Exporting Process of the Monitoring Device.";
     key name;
     leaf name {
       type nameType;
       description "Key of this list.";
     }
     leaf exportMode {
       type identityref {
         base "exportMode";
       }
       default parallel;
       description "This parameter determines to which configured
         destination(s) the incoming Data Records are exported.";
     }
     ct:instance-list destination {
       ct:instance-type ExportDestination;
       min-elements 1;
       description "Export destinations.";
     }
     list options {
       key name;
       description "List of options reported by the Exporting
         Process.";
       leaf name {
         type nameType;
         description "Key of this list.";
       }
       leaf optionsType {
         type identityref {
           base "optionsType";
         }
         mandatory true;

Linowski, et al. Experimental [Page 62] RFC 6095 YANG Language Abstractions March 2011

         description "Type of the exported options data.";
       }
       leaf optionsTimeout {
         type uint32;
         units milliseconds;
         description "Time interval for periodic export of the options
           data. ... ";
       }
     }
   }
   ct:complex-type CollectingProcess {
     description "A Collecting Process.";
     key name;
     leaf name {
       type nameType;
       description "Key of a collecing process.";
     }
     ct:instance-list sctpCollector {
       ct:instance-type SctpCollector;
       description "List of SCTP receivers (sockets) on which the
         Collecting Process receives IPFIX Messages.";
     }
     ct:instance-list udpCollector {
       if-feature udpTransport;
       ct:instance-type UdpCollector;
       description "List of UDP receivers (sockets) on which the
         Collecting Process receives IPFIX Messages.";
     }
     ct:instance-list tcpCollector {
       if-feature tcpTransport;
       ct:instance-type TcpCollector;
       description "List of TCP receivers (sockets) on which the
         Collecting Process receives IPFIX Messages.";
     }
     ct:instance-list fileReader {
       if-feature fileReader;
       ct:instance-type FileReader;
       description "List of File Readers from which the Collecting
         Process reads IPFIX Messages.";
     }
     leaf-list exportingProcess {
       type instance-identifier { ct:instance-type ExportingProcess; }
       description "Export of received records without any
         modifications.  Records are processed by all Exporting
         Processes in the list.";
     }
   }

Linowski, et al. Experimental [Page 63] RFC 6095 YANG Language Abstractions March 2011

   ct:complex-type Collector {
       ct:abstract true;
       description "Abstract collector.";
       key name;
       leaf name {
         type nameType;
         description "Key of collectors";
       }
   }
   ct:complex-type IpCollector {
     ct:abstract true;
     ct:extends Collector;
     description "Collector for IP transport protocols.";
     leaf localPort {
       type inet:port-number;
       description "If not configured, the Monitoring Device uses the
         default port number for IPFIX, which is 4739 without
         Transport Layer Security, and 4740 if Transport Layer
         Security is activated.";
     }
     container transportLayerSecurity {
       presence "If transportLayerSecurity is present, DTLS is enabled
         if the transport protocol is SCTP or UDP, and TLS is enabled
         if the transport protocol is TCP.";
       description "Transport Layer Security configuration.";
       uses transportLayerSecurityParameters;
     }
     list transportSession {
       config false;
       description "This list contains the currently established
         Transport Sessions terminating at the given socket.";
       uses transportSessionParameters;
     }
   }
   ct:complex-type SctpCollector {
     ct:extends IpCollector;
     description "Collector listening on an SCTP socket";
     leaf-list localIPAddress {
       type inet:ip-address;
       description "List of local IP addresses ... ";
       reference "RFC 4960, Section 6.4
         (Multi-Homed SCTP Endpoints).";
     }
   }
   ct:complex-type UdpCollector {

Linowski, et al. Experimental [Page 64] RFC 6095 YANG Language Abstractions March 2011

     ct:extends IpCollector;
     description "Parameters of a listening UDP socket at a
       Collecting Process.";
     leaf-list localIPAddress {
       type inet:ip-address;
       description "List of local IP addresses on which the Collecting
         Process listens for IPFIX Messages.";
     }
     leaf templateLifeTime {
       type uint32;
       units seconds;
       default 1800;
       description "Sets the lifetime of Templates for all UDP
         Transport Sessions ... ";
       reference "RFC 5101, Section 10.3.7; RFC 5815, Section 8
         (ipfixTransportSessionTemplateRefreshTimeout).";
     }
     leaf optionsTemplateLifeTime {
       type uint32;
       units seconds;
       default 1800;
       description "Sets the lifetime of Options Templates for all
         UDP Transport Sessions terminating at this UDP socket.
         ... ";
       reference "RFC 5101, Section 10.3.7; RFC 5815, Section 8
         (ipfixTransportSessionOptionsTemplateRefreshTimeout).";
     }
     leaf templateLifePacket {
       type uint32;
       units "IPFIX Messages";
       description "If this parameter is configured, Templates
         defined in a UDP Transport Session become invalid if ...";
       reference "RFC 5101, Section 10.3.7; RFC 5815, Section 8
         (ipfixTransportSessionTemplateRefreshPacket).";
     }
     leaf optionsTemplateLifePacket {
       type uint32;
       units "IPFIX Messages";
       description "If this parameter is configured, Options
         Templates defined in a UDP Transport Session become
         invalid if ...";
       reference "RFC 5101, Section 10.3.7; RFC 5815, Section 8
         (ipfixTransportSessionOptionsTemplateRefreshPacket).";
     }
   }
   ct:complex-type TcpCollector {
     ct:extends IpCollector;

Linowski, et al. Experimental [Page 65] RFC 6095 YANG Language Abstractions March 2011

     description "Collector listening on a TCP socket.";
     leaf-list localIPAddress {
       type inet:ip-address;
       description "List of local IP addresses on which the Collecting
         Process listens for IPFIX Messages.";
     }
   }
   ct:complex-type FileReader {
     ct:extends Collector;
     description "File Reading collector.";
     leaf file {
       type inet:uri;
       mandatory true;
       description "URI specifying the location of the file.";
     }
     leaf bytes {
       type yang:counter64;
       units octets;
       config false;
       description "The number of bytes read by the File Reader.
         ... ";
     }
     leaf messages {
       type yang:counter64;
       units "IPFIX Messages";
       config false;
       description "The number of IPFIX Messages read by the File
         Reader. ... ";
     }
     leaf records {
       type yang:counter64;
       units "Data Records";
       config false;
       description "The number of Data Records read by the File
         Reader. ... ";
     }
     leaf templates {
       type yang:counter32;
       units "Templates";
       config false;
       description "The number of Template Records (excluding
         Options Template Records) read by the File Reader. ...";
     }
     leaf optionsTemplates {
       type yang:counter32;
       units "Options Templates";
       config false;

Linowski, et al. Experimental [Page 66] RFC 6095 YANG Language Abstractions March 2011

       description "The number of Options Template Records read by
         the File Reader. ... ";
     }
     leaf fileReaderDiscontinuityTime {
       type yang:date-and-time;
       config false;
       description "Timestamp of the most recent occasion ... ";
     }
     list template {
       config false;
       description "This list contains the Templates and Options
         Templates that have been read by the File Reader.
         Withdrawn or invalidated (Options) Templates MUST be removed
         from this list.";
       uses templateParameters;
     }
   }
   ct:complex-type SelectionProcess {
       description "Selection Process";
       key name;
       leaf name {
         type nameType;
         description "Key of a selection process.";
       }
       ct:instance-list selector {
         ct:instance-type Selector;
         min-elements 1;
         ordered-by user;
         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.";
       }
       list selectionSequence {
         config false;
         description "This list contains the Selection Sequence IDs
           which are assigned by the Monitoring Device ... ";
         reference "RFC 5476.";
         leaf observationDomainId {
           type uint32;
           description "Observation Domain ID for which the
             Selection Sequence ID is assigned.";
         }
         leaf selectionSequenceId {
           type uint64;
           description "Selection Sequence ID used in the Selection
             Sequence (Statistics) Report Interpretation.";

Linowski, et al. Experimental [Page 67] RFC 6095 YANG Language Abstractions March 2011

         }
       }
       leaf cache {
         type instance-identifier { ct:instance-type Cache; }
         description "Cache which receives the output of the
           Selection Process.";
       }
     }
   /*****************************************************************
   * Groupings
   *****************************************************************/
   grouping transportLayerSecurityParameters {
     description "Transport layer security parameters.";
     leaf-list localCertificationAuthorityDN {
       type string;
       description "Distinguished names of certification authorities
         whose certificates may be used to identify the local
         endpoint.";
     }
     leaf-list localSubjectDN {
       type string;
       description "Distinguished names that may be used in the
         certificates to identify the local endpoint.";
     }
     leaf-list localSubjectFQDN {
       type inet:domain-name;
       description "Fully qualified domain names that may be used to
         in the certificates to identify the local endpoint.";
     }
     leaf-list remoteCertificationAuthorityDN {
       type string;
       description "Distinguished names of certification authorities
         whose certificates are accepted to authorize remote
         endpoints.";
     }
     leaf-list remoteSubjectDN {
       type string;
       description "Distinguished names that are accepted in
         certificates to authorize remote endpoints.";
     }
     leaf-list remoteSubjectFQDN {
       type inet:domain-name;
       description "Fully qualified domain names that are accepted in
         certificates to authorize remote endpoints.";
     }
   }

Linowski, et al. Experimental [Page 68] RFC 6095 YANG Language Abstractions March 2011

   grouping templateParameters {
     description "State parameters of a Template used by an Exporting
       Process or received by a Collecting Process ... ";
     reference "RFC 5101; RFC 5815, Section 8 (ipfixTemplateEntry,
       ipfixTemplateDefinitionEntry, ipfixTemplateStatsEntry)";
     leaf observationDomainId {
       type uint32;
       description "The ID of the Observation Domain for which this
         Template is defined.";
       reference "RFC 5815, Section 8
         (ipfixTemplateObservationDomainId).";
     }
     leaf templateId {
       type uint16 {
         range "256..65535" {
           description "Valid range of Template Ids.";
           reference "RFC 5101";
         }
       }
       description "This number indicates the Template Id in the IPFIX
         message.";
       reference "RFC 5815, Section 8 (ipfixTemplateId).";
     }
     leaf setId {
       type uint16;
       description "This number indicates the Set Id of the Template.
         ... ";
       reference "RFC 5815, Section 8 (ipfixTemplateSetId).";
     }
     leaf accessTime {
       type yang:date-and-time;
       description "Used for Exporting Processes, ... ";
       reference "RFC 5815, Section 8 (ipfixTemplateAccessTime).";
     }
     leaf templateDataRecords {
       type yang:counter64;
       description "The number of transmitted or received Data
         Records ... ";
       reference "RFC 5815, Section 8 (ipfixTemplateDataRecords).";
     }
     leaf templateDiscontinuityTime {
       type yang:date-and-time;
       description "Timestamp of the most recent occasion at which
         the counter templateDataRecords suffered a discontinuity.
         ... ";
       reference "RFC 5815, Section 8
         (ipfixTemplateDiscontinuityTime).";
     }

Linowski, et al. Experimental [Page 69] RFC 6095 YANG Language Abstractions March 2011

     list field {
       description "This list contains the (Options) Template
         fields of which the (Options) Template is defined.
         ... ";
       leaf ieId {
         type uint16 {
           range "1..32767" {
             description "Valid range of Information Element
                 identifiers.";
             reference "RFC 5102, Section 4.";
           }
         }
         description "This parameter indicates the Information
           Element Id of the field.";
         reference "RFC 5815, Section 8 (ipfixTemplateDefinitionIeId);
           RFC 5102.";
       }
       leaf ieLength {
         type uint16;
         units octets;
         description "This parameter indicates the length of the
           Information Element of the field.";
         reference "RFC 5815, Section 8
           (ipfixTemplateDefinitionIeLength); RFC 5102.";
       }
       leaf ieEnterpriseNumber {
         type uint32;
         description "This parameter indicates the IANA enterprise
           number of the authority ... ";
         reference "RFC 5815, Section 8
           (ipfixTemplateDefinitionEnterpriseNumber).";
       }
       leaf isFlowKey {
         when "../../setId = 2" {
           description "This parameter is available for non-Options
             Templates (Set Id is 2).";
         }
         type empty;
         description "If present, this is a Flow Key field.";
         reference "RFC 5815, Section 8
           (ipfixTemplateDefinitionFlags).";
       }
       leaf isScope {
         when "../../setId = 3" {
           description "This parameter is available for Options
             Templates (Set Id is 3).";
         }
         type empty;

Linowski, et al. Experimental [Page 70] RFC 6095 YANG Language Abstractions March 2011

         description "If present, this is a scope field.";
         reference "RFC 5815, Section 8
           (ipfixTemplateDefinitionFlags).";
       }
     }
   }
   grouping transportSessionParameters {
     description "State parameters of a Transport Session ... ";
     reference "RFC 5101; RFC 5815, Section 8
       (ipfixTransportSessionEntry,
        ipfixTransportSessionStatsEntry)";
     leaf ipfixVersion {
       type uint16;
       description "Used for Exporting Processes, this parameter
         contains the version number of the IPFIX protocol ... ";
       reference "RFC 5815, Section 8
         (ipfixTransportSessionIpfixVersion).";
     }
     leaf sourceAddress {
       type inet:ip-address;
       description "The source address of the Exporter of the
         IPFIX Transport Session... ";
       reference "RFC 5815, Section 8
         (ipfixTransportSessionSourceAddressType,
         ipfixTransportSessionSourceAddress).";
     }
     leaf destinationAddress {
       type inet:ip-address;
       description "The destination address of the Collector of
         the IPFIX Transport Session... ";
       reference "RFC 5815, Section 8
         (ipfixTransportSessionDestinationAddressType,
         ipfixTransportSessionDestinationAddress).";
     }
     leaf sourcePort {
       type inet:port-number;
       description "The transport protocol port number of the
         Exporter of the IPFIX Transport Session.";
       reference "RFC 5815, Section 8
         (ipfixTransportSessionSourcePort).";
     }
     leaf destinationPort {
       type inet:port-number;
       description "The transport protocol port number of the
         Collector of the IPFIX Transport Session... ";
       reference "RFC 5815, Section 8
         (ipfixTransportSessionDestinationPort).";

Linowski, et al. Experimental [Page 71] RFC 6095 YANG Language Abstractions March 2011

     }
     leaf sctpAssocId {
       type uint32;
       description "The association id used for the SCTP session
         between the Exporter and the Collector ... ";
       reference "RFC 5815, Section 8
         (ipfixTransportSessionSctpAssocId),
         RFC 3871";
     }
     leaf status {
       type transportSessionStatus;
       description "Status of the Transport Session.";
       reference "RFC 5815, Section 8 (ipfixTransportSessionStatus).";
     }
     leaf rate {
       type yang:gauge32;
       units "bytes per second";
       description "The number of bytes per second transmitted by the
         Exporting Process or received by the Collecting Process.
         This parameter is updated every second.";
       reference "RFC 5815, Section 8 (ipfixTransportSessionRate).";
     }
     leaf bytes {
       type yang:counter64;
       units bytes;
       description "The number of bytes transmitted by the
         Exporting Process or received by the Collecting
         Process ... ";
       reference "RFC 5815, Section 8 (ipfixTransportSessionBytes).";
     }
     leaf messages {
       type yang:counter64;
       units "IPFIX Messages";
       description "The number of messages transmitted by the
         Exporting Process or received by the Collecting Process... ";
       reference "RFC 5815, Section 8
         (ipfixTransportSessionMessages).";
     }
     leaf discardedMessages {
       type yang:counter64;
       units "IPFIX Messages";
       description "Used for Exporting Processes, this parameter
         indicates the number of messages that could not be
         sent ...";
       reference "RFC 5815, Section 8
         (ipfixTransportSessionDiscardedMessages).";
     }
     leaf records {

Linowski, et al. Experimental [Page 72] RFC 6095 YANG Language Abstractions March 2011

       type yang:counter64;
       units "Data Records";
       description "The number of Data Records transmitted ... ";
       reference "RFC 5815, Section 8
         (ipfixTransportSessionRecords).";
     }
     leaf templates {
       type yang:counter32;
       units "Templates";
       description "The number of Templates transmitted by the
         Exporting Process or received by the Collecting Process.
         ... ";
       reference "RFC 5815, Section 8
         (ipfixTransportSessionTemplates).";
     }
     leaf optionsTemplates {
       type yang:counter32;
       units "Options Templates";
       description "The number of Option Templates transmitted by the
         Exporting Process or received by the Collecting Process...";
       reference "RFC 5815, Section 8
         (ipfixTransportSessionOptionsTemplates).";
     }
     leaf transportSessionStartTime {
       type yang:date-and-time;
       description "Timestamp of the start of the given Transport
         Session... ";
     }
     leaf transportSessionDiscontinuityTime {
       type yang:date-and-time;
       description "Timestamp of the most recent occasion at which
         one or more of the Transport Session counters suffered a
         discontinuity... ";
       reference "RFC 5815, Section 8
         (ipfixTransportSessionDiscontinuityTime).";
     }
     list template {
       description "This list contains the Templates and Options
         Templates that are transmitted by the Exporting Process
         or received by the Collecting Process.
         Withdrawn or invalidated (Options) Templates MUST be removed
         from this list.";
       uses templateParameters;
     }
   }
   /*****************************************************************
   * Main container

Linowski, et al. Experimental [Page 73] RFC 6095 YANG Language Abstractions March 2011

  • /
   container ipfix {
     description "Top-level node of the IPFIX/PSAMP configuration
       data model.";
     ct:instance-list collectingProcess {
       if-feature collector;
       ct:instance-type CollectingProcess;
     }
     ct:instance-list observationPoint {
       if-feature meter;
       ct:instance-type ObservationPoint;
     }
     ct:instance-list selectionProcess {
       if-feature meter;
       ct:instance-type SelectionProcess;
     }
     ct:instance-list cache {
       if-feature meter;
       description "Cache of the Monitoring Device.";
       ct:instance-type Cache;
     }
     ct:instance-list exportingProcess {
       if-feature exporter;
       description "Exporting Process of the Monitoring Device.";
       ct:instance-type ExportingProcess;
     }
   }

} <CODE ENDS>

Linowski, et al. Experimental [Page 74] RFC 6095 YANG Language Abstractions March 2011

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 76
 Munich  81541
 Germany
 EMail: mehmet.ersue@nsn.com
 Siarhei Kuryla
 360 Treasury Systems
 Grueneburgweg 16-18
 Frankfurt am Main  60322
 Germany
 EMail: s.kuryla@gmail.com

Linowski, et al. Experimental [Page 75]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6095.txt · Last modified: 2011/03/29 08:31 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki