summaryrefslogtreecommitdiffstats
path: root/cps-service/src/test/resources/ietf
diff options
context:
space:
mode:
Diffstat (limited to 'cps-service/src/test/resources/ietf')
-rw-r--r--cps-service/src/test/resources/ietf/data/ietf-network-topology-sample-rfc8345.json120
-rw-r--r--cps-service/src/test/resources/ietf/ietf-inet-types@2013-07-15.yang458
-rw-r--r--cps-service/src/test/resources/ietf/ietf-network-state@2018-02-26.yang176
-rw-r--r--cps-service/src/test/resources/ietf/ietf-network-topology-state@2018-02-26.yang273
-rw-r--r--cps-service/src/test/resources/ietf/ietf-network-topology@2018-02-26.yang294
-rw-r--r--cps-service/src/test/resources/ietf/ietf-network@2018-02-26.yang192
-rw-r--r--cps-service/src/test/resources/ietf/ietf-yang-types@2013-07-15.yang474
7 files changed, 1987 insertions, 0 deletions
diff --git a/cps-service/src/test/resources/ietf/data/ietf-network-topology-sample-rfc8345.json b/cps-service/src/test/resources/ietf/data/ietf-network-topology-sample-rfc8345.json
new file mode 100644
index 0000000000..8f2ee022cb
--- /dev/null
+++ b/cps-service/src/test/resources/ietf/data/ietf-network-topology-sample-rfc8345.json
@@ -0,0 +1,120 @@
+{
+ "ietf-network:networks": {
+ "network": [
+ {
+ "network-types": {
+ },
+ "network-id": "otn-hc",
+ "node": [
+ {
+ "node-id": "D1",
+ "termination-point": [
+ {
+ "tp-id": "1-0-1"
+ },
+ {
+ "tp-id": "1-2-1"
+ },
+ {
+ "tp-id": "1-3-1"
+ }
+ ]
+ },
+ {
+ "node-id": "D2",
+ "termination-point": [
+ {
+ "tp-id": "2-0-1"
+ },
+ {
+ "tp-id": "2-1-1"
+ },
+ {
+ "tp-id": "2-3-1"
+ }
+ ]
+ },
+ {
+ "node-id": "D3",
+ "termination-point": [
+ {
+ "tp-id": "3-1-1"
+ },
+ {
+ "tp-id": "3-2-1"
+ }
+ ]
+ }
+ ],
+ "ietf-network-topology:link": [
+ {
+ "link-id": "D1,1-2-1,D2,2-1-1",
+ "source": {
+ "source-node": "D1",
+ "source-tp": "1-2-1"
+ },
+ "destination": {
+ "dest-node": "D2",
+ "dest-tp": "2-1-1"
+ }
+ },
+ {
+ "link-id": "D2,2-1-1,D1,1-2-1",
+ "source": {
+ "source-node": "D2",
+ "source-tp": "2-1-1"
+ },
+ "destination": {
+ "dest-node": "D1",
+ "dest-tp": "1-2-1"
+ }
+ },
+ {
+ "link-id": "D1,1-3-1,D3,3-1-1",
+ "source": {
+ "source-node": "D1",
+ "source-tp": "1-3-1"
+ },
+ "destination": {
+ "dest-node": "D3",
+ "dest-tp": "3-1-1"
+ }
+ },
+ {
+ "link-id": "D3,3-1-1,D1,1-3-1",
+ "source": {
+ "source-node": "D3",
+ "source-tp": "3-1-1"
+ },
+ "destination": {
+ "dest-node": "D1",
+ "dest-tp": "1-3-1"
+ }
+ },
+ {
+ "link-id": "D2,2-3-1,D3,3-2-1",
+ "source": {
+ "source-node": "D2",
+ "source-tp": "2-3-1"
+ },
+ "destination": {
+ "dest-node": "D3",
+ "dest-tp": "3-2-1"
+ }
+ },
+ {
+ "link-id": "D3,3-2-1,D2,2-3-1",
+ "source": {
+ "source-node": "D3",
+ "source-tp": "3-2-1"
+ },
+ "destination": {
+ "dest-node": "D2",
+ "dest-tp": "2-3-1"
+ }
+ }
+ ]
+ }
+ ]
+ }
+ }
diff --git a/cps-service/src/test/resources/ietf/ietf-inet-types@2013-07-15.yang b/cps-service/src/test/resources/ietf/ietf-inet-types@2013-07-15.yang
new file mode 100644
index 0000000000..eacefb6363
--- /dev/null
+++ b/cps-service/src/test/resources/ietf/ietf-inet-types@2013-07-15.yang
@@ -0,0 +1,458 @@
+module ietf-inet-types {
+
+ namespace "urn:ietf:params:xml:ns:yang:ietf-inet-types";
+ prefix "inet";
+
+ organization
+ "IETF NETMOD (NETCONF Data Modeling Language) Working Group";
+
+ contact
+ "WG Web: <http://tools.ietf.org/wg/netmod/>
+ WG List: <mailto:netmod@ietf.org>
+
+ WG Chair: David Kessens
+ <mailto:david.kessens@nsn.com>
+
+ WG Chair: Juergen Schoenwaelder
+ <mailto:j.schoenwaelder@jacobs-university.de>
+
+ Editor: Juergen Schoenwaelder
+ <mailto:j.schoenwaelder@jacobs-university.de>";
+
+ description
+ "This module contains a collection of generally useful derived
+ YANG data types for Internet addresses and related things.
+
+ Copyright (c) 2013 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 6991; see
+ the RFC itself for full legal notices.";
+
+ revision 2013-07-15 {
+ description
+ "This revision adds the following new data types:
+ - ip-address-no-zone
+ - ipv4-address-no-zone
+ - ipv6-address-no-zone";
+ reference
+ "RFC 6991: Common YANG Data Types";
+ }
+
+ revision 2010-09-24 {
+ description
+ "Initial revision.";
+ reference
+ "RFC 6021: Common YANG Data Types";
+ }
+
+ /*** collection of types related to protocol fields ***/
+
+ typedef ip-version {
+ type enumeration {
+ enum unknown {
+ value "0";
+ description
+ "An unknown or unspecified version of the Internet
+ protocol.";
+ }
+ enum ipv4 {
+ value "1";
+ description
+ "The IPv4 protocol as defined in RFC 791.";
+ }
+ enum ipv6 {
+ value "2";
+ description
+ "The IPv6 protocol as defined in RFC 2460.";
+ }
+ }
+ description
+ "This value represents the version of the IP protocol.
+
+ In the value set and its semantics, this type is equivalent
+ to the InetVersion textual convention of the SMIv2.";
+ reference
+ "RFC 791: Internet Protocol
+ RFC 2460: Internet Protocol, Version 6 (IPv6) Specification
+ RFC 4001: Textual Conventions for Internet Network Addresses";
+ }
+
+ typedef dscp {
+ type uint8 {
+ range "0..63";
+ }
+ description
+ "The dscp type represents a Differentiated Services Code Point
+ that may be used for marking packets in a traffic stream.
+ In the value set and its semantics, this type is equivalent
+ to the Dscp textual convention of the SMIv2.";
+ reference
+ "RFC 3289: Management Information Base for the Differentiated
+ Services Architecture
+ RFC 2474: Definition of the Differentiated Services Field
+ (DS Field) in the IPv4 and IPv6 Headers
+ RFC 2780: IANA Allocation Guidelines For Values In
+ the Internet Protocol and Related Headers";
+ }
+
+ typedef ipv6-flow-label {
+ type uint32 {
+ range "0..1048575";
+ }
+ description
+ "The ipv6-flow-label type represents the flow identifier or Flow
+ Label in an IPv6 packet header that may be used to
+ discriminate traffic flows.
+
+ In the value set and its semantics, this type is equivalent
+ to the IPv6FlowLabel textual convention of the SMIv2.";
+ reference
+ "RFC 3595: Textual Conventions for IPv6 Flow Label
+ RFC 2460: Internet Protocol, Version 6 (IPv6) Specification";
+ }
+
+ typedef port-number {
+ type uint16 {
+ range "0..65535";
+ }
+ description
+ "The port-number type represents a 16-bit port number of an
+ Internet transport-layer protocol such as UDP, TCP, DCCP, or
+ SCTP. Port numbers are assigned by IANA. A current list of
+ all assignments is available from <http://www.iana.org/>.
+
+ Note that the port number value zero is reserved by IANA. In
+ situations where the value zero does not make sense, it can
+ be excluded by subtyping the port-number type.
+ In the value set and its semantics, this type is equivalent
+ to the InetPortNumber textual convention of the SMIv2.";
+ reference
+ "RFC 768: User Datagram Protocol
+ RFC 793: Transmission Control Protocol
+ RFC 4960: Stream Control Transmission Protocol
+ RFC 4340: Datagram Congestion Control Protocol (DCCP)
+ RFC 4001: Textual Conventions for Internet Network Addresses";
+ }
+
+ /*** collection of types related to autonomous systems ***/
+
+ typedef as-number {
+ type uint32;
+ description
+ "The as-number type represents autonomous system numbers
+ which identify an Autonomous System (AS). An AS is a set
+ of routers under a single technical administration, using
+ an interior gateway protocol and common metrics to route
+ packets within the AS, and using an exterior gateway
+ protocol to route packets to other ASes. IANA maintains
+ the AS number space and has delegated large parts to the
+ regional registries.
+
+ Autonomous system numbers were originally limited to 16
+ bits. BGP extensions have enlarged the autonomous system
+ number space to 32 bits. This type therefore uses an uint32
+ base type without a range restriction in order to support
+ a larger autonomous system number space.
+
+ In the value set and its semantics, this type is equivalent
+ to the InetAutonomousSystemNumber textual convention of
+ the SMIv2.";
+ reference
+ "RFC 1930: Guidelines for creation, selection, and registration
+ of an Autonomous System (AS)
+ RFC 4271: A Border Gateway Protocol 4 (BGP-4)
+ RFC 4001: Textual Conventions for Internet Network Addresses
+ RFC 6793: BGP Support for Four-Octet Autonomous System (AS)
+ Number Space";
+ }
+
+ /*** collection of types related to IP addresses and hostnames ***/
+
+ typedef ip-address {
+ type union {
+ type inet:ipv4-address;
+ type inet:ipv6-address;
+ }
+ description
+ "The ip-address type represents an IP address and is IP
+ version neutral. The format of the textual representation
+ implies the IP version. This type supports scoped addresses
+ by allowing zone identifiers in the address format.";
+ reference
+ "RFC 4007: IPv6 Scoped Address Architecture";
+ }
+
+ typedef ipv4-address {
+ type string {
+ pattern
+ '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'
+ + '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])'
+ + '(%[\p{N}\p{L}]+)?';
+ }
+ description
+ "The ipv4-address type represents an IPv4 address in
+ dotted-quad notation. The IPv4 address may include a zone
+ index, separated by a % sign.
+
+ The zone index is used to disambiguate identical address
+ values. For link-local addresses, the zone index will
+ typically be the interface index number or the name of an
+ interface. If the zone index is not present, the default
+ zone of the device will be used.
+
+ The canonical format for the zone index is the numerical
+ format";
+ }
+
+ typedef ipv6-address {
+ type string {
+ pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}'
+ + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|'
+ + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}'
+ + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))'
+ + '(%[\p{N}\p{L}]+)?';
+ pattern '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|'
+ + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)'
+ + '(%.+)?';
+ }
+ description
+ "The ipv6-address type represents an IPv6 address in full,
+ mixed, shortened, and shortened-mixed notation. The IPv6
+ address may include a zone index, separated by a % sign.
+
+ The zone index is used to disambiguate identical address
+ values. For link-local addresses, the zone index will
+ typically be the interface index number or the name of an
+ interface. If the zone index is not present, the default
+ zone of the device will be used.
+
+ The canonical format of IPv6 addresses uses the textual
+ representation defined in Section 4 of RFC 5952. The
+ canonical format for the zone index is the numerical
+ format as described in Section 11.2 of RFC 4007.";
+ reference
+ "RFC 4291: IP Version 6 Addressing Architecture
+ RFC 4007: IPv6 Scoped Address Architecture
+ RFC 5952: A Recommendation for IPv6 Address Text
+ Representation";
+ }
+
+ typedef ip-address-no-zone {
+ type union {
+ type inet:ipv4-address-no-zone;
+ type inet:ipv6-address-no-zone;
+ }
+ description
+ "The ip-address-no-zone type represents an IP address and is
+ IP version neutral. The format of the textual representation
+ implies the IP version. This type does not support scoped
+ addresses since it does not allow zone identifiers in the
+ address format.";
+ reference
+ "RFC 4007: IPv6 Scoped Address Architecture";
+ }
+
+ typedef ipv4-address-no-zone {
+ type inet:ipv4-address {
+ pattern '[0-9\.]*';
+ }
+ description
+ "An IPv4 address without a zone index. This type, derived from
+ ipv4-address, may be used in situations where the zone is
+ known from the context and hence no zone index is needed.";
+ }
+
+ typedef ipv6-address-no-zone {
+ type inet:ipv6-address {
+ pattern '[0-9a-fA-F:\.]*';
+ }
+ description
+ "An IPv6 address without a zone index. This type, derived from
+ ipv6-address, may be used in situations where the zone is
+ known from the context and hence no zone index is needed.";
+ reference
+ "RFC 4291: IP Version 6 Addressing Architecture
+ RFC 4007: IPv6 Scoped Address Architecture
+ RFC 5952: A Recommendation for IPv6 Address Text
+ Representation";
+ }
+
+ typedef ip-prefix {
+ type union {
+ type inet:ipv4-prefix;
+ type inet:ipv6-prefix;
+ }
+ description
+ "The ip-prefix type represents an IP prefix and is IP
+ version neutral. The format of the textual representations
+ implies the IP version.";
+ }
+
+ typedef ipv4-prefix {
+ type string {
+ pattern
+ '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'
+ + '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])'
+ + '/(([0-9])|([1-2][0-9])|(3[0-2]))';
+ }
+ description
+ "The ipv4-prefix type represents an IPv4 address prefix.
+ The prefix length is given by the number following the
+ slash character and must be less than or equal to 32.
+
+ A prefix length value of n corresponds to an IP address
+ mask that has n contiguous 1-bits from the most
+ significant bit (MSB) and all other bits set to 0.
+
+ The canonical format of an IPv4 prefix has all bits of
+ the IPv4 address set to zero that are not part of the
+ IPv4 prefix.";
+ }
+
+ typedef ipv6-prefix {
+ type string {
+ pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}'
+ + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|'
+ + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}'
+ + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))'
+ + '(/(([0-9])|([0-9]{2})|(1[0-1][0-9])|(12[0-8])))';
+ pattern '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|'
+ + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)'
+ + '(/.+)';
+ }
+
+ description
+ "The ipv6-prefix type represents an IPv6 address prefix.
+ The prefix length is given by the number following the
+ slash character and must be less than or equal to 128.
+
+ A prefix length value of n corresponds to an IP address
+ mask that has n contiguous 1-bits from the most
+ significant bit (MSB) and all other bits set to 0.
+
+ The IPv6 address should have all bits that do not belong
+ to the prefix set to zero.
+
+ The canonical format of an IPv6 prefix has all bits of
+ the IPv6 address set to zero that are not part of the
+ IPv6 prefix. Furthermore, the IPv6 address is represented
+ as defined in Section 4 of RFC 5952.";
+ reference
+ "RFC 5952: A Recommendation for IPv6 Address Text
+ Representation";
+ }
+
+ /*** collection of domain name and URI types ***/
+
+ typedef domain-name {
+ type string {
+ pattern
+ '((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.)*'
+ + '([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.?)'
+ + '|\.';
+ length "1..253";
+ }
+ description
+ "The domain-name type represents a DNS domain name. The
+ name SHOULD be fully qualified whenever possible.
+
+ Internet domain names are only loosely specified. Section
+ 3.5 of RFC 1034 recommends a syntax (modified in Section
+ 2.1 of RFC 1123). The pattern above is intended to allow
+ for current practice in domain name use, and some possible
+ future expansion. It is designed to hold various types of
+ domain names, including names used for A or AAAA records
+ (host names) and other records, such as SRV records. Note
+ that Internet host names have a stricter syntax (described
+ in RFC 952) than the DNS recommendations in RFCs 1034 and
+ 1123, and that systems that want to store host names in
+ schema nodes using the domain-name type are recommended to
+ adhere to this stricter standard to ensure interoperability.
+
+ The encoding of DNS names in the DNS protocol is limited
+ to 255 characters. Since the encoding consists of labels
+ prefixed by a length bytes and there is a trailing NULL
+ byte, only 253 characters can appear in the textual dotted
+ notation.
+
+ The description clause of schema nodes using the domain-name
+ type MUST describe when and how these names are resolved to
+ IP addresses. Note that the resolution of a domain-name value
+ may require to query multiple DNS records (e.g., A for IPv4
+ and AAAA for IPv6). The order of the resolution process and
+ which DNS record takes precedence can either be defined
+ explicitly or may depend on the configuration of the
+ resolver.
+
+ Domain-name values use the US-ASCII encoding. Their canonical
+ format uses lowercase US-ASCII characters. Internationalized
+ domain names MUST be A-labels as per RFC 5890.";
+ reference
+ "RFC 952: DoD Internet Host Table Specification
+ RFC 1034: Domain Names - Concepts and Facilities
+ RFC 1123: Requirements for Internet Hosts -- Application
+ and Support
+ RFC 2782: A DNS RR for specifying the location of services
+ (DNS SRV)
+ RFC 5890: Internationalized Domain Names in Applications
+ (IDNA): Definitions and Document Framework";
+ }
+
+ typedef host {
+ type union {
+ type inet:ip-address;
+ type inet:domain-name;
+ }
+ description
+ "The host type represents either an IP address or a DNS
+ domain name.";
+ }
+
+ typedef uri {
+ type string;
+ description
+ "The uri type represents a Uniform Resource Identifier
+ (URI) as defined by STD 66.
+
+ Objects using the uri type MUST be in US-ASCII encoding,
+ and MUST be normalized as described by RFC 3986 Sections
+ 6.2.1, 6.2.2.1, and 6.2.2.2. All unnecessary
+ percent-encoding is removed, and all case-insensitive
+ characters are set to lowercase except for hexadecimal
+ digits, which are normalized to uppercase as described in
+ Section 6.2.2.1.
+
+ The purpose of this normalization is to help provide
+ unique URIs. Note that this normalization is not
+ sufficient to provide uniqueness. Two URIs that are
+ textually distinct after this normalization may still be
+ equivalent.
+
+ Objects using the uri type may restrict the schemes that
+ they permit. For example, 'data:' and 'urn:' schemes
+ might not be appropriate.
+
+ A zero-length URI is not a valid URI. This can be used to
+ express 'URI absent' where required.
+
+ In the value set and its semantics, this type is equivalent
+ to the Uri SMIv2 textual convention defined in RFC 5017.";
+ reference
+ "RFC 3986: Uniform Resource Identifier (URI): Generic Syntax
+ RFC 3305: Report from the Joint W3C/IETF URI Planning Interest
+ Group: Uniform Resource Identifiers (URIs), URLs,
+ and Uniform Resource Names (URNs): Clarifications
+ and Recommendations
+ RFC 5017: MIB Textual Conventions for Uniform Resource
+ Identifiers (URIs)";
+ }
+
+}
diff --git a/cps-service/src/test/resources/ietf/ietf-network-state@2018-02-26.yang b/cps-service/src/test/resources/ietf/ietf-network-state@2018-02-26.yang
new file mode 100644
index 0000000000..9a6893da20
--- /dev/null
+++ b/cps-service/src/test/resources/ietf/ietf-network-state@2018-02-26.yang
@@ -0,0 +1,176 @@
+module ietf-network-state {
+ yang-version 1.1;
+ namespace "urn:ietf:params:xml:ns:yang:ietf-network-state";
+ prefix nw-s;
+
+ import ietf-network {
+ prefix nw;
+ reference
+ "RFC 8345: A YANG Data Model for Network Topologies";
+ }
+
+ organization
+ "IETF I2RS (Interface to the Routing System) Working Group";
+
+ contact
+ "WG Web: <https://datatracker.ietf.org/wg/i2rs/>
+ WG List: <mailto:i2rs@ietf.org>
+
+ Editor: Alexander Clemm
+ <mailto:ludwig@clemm.org>
+
+ Editor: Jan Medved
+ <mailto:jmedved@cisco.com>
+
+ Editor: Robert Varga
+ <mailto:robert.varga@pantheon.tech>
+
+ Editor: Nitin Bahadur
+ <mailto:nitin_bahadur@yahoo.com>
+ Editor: Hariharan Ananthakrishnan
+ <mailto:hari@packetdesign.com>
+
+ Editor: Xufeng Liu
+ <mailto:xufeng.liu.ietf@gmail.com>";
+
+ description
+ "This module defines a common base data model for a collection
+ of nodes in a network. Node definitions are further used
+ in network topologies and inventories. It represents
+ information that either (1) is learned and automatically
+ populated or (2) results from applying network information
+ that has been configured per the 'ietf-network' data model,
+ mirroring the corresponding data nodes in this data model.
+
+ The data model mirrors 'ietf-network' but contains only
+ read-only state data. The data model is not needed when the
+ underlying implementation infrastructure supports the Network
+ Management Datastore Architecture (NMDA).
+
+ Copyright (c) 2018 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
+ (https://trustee.ietf.org/license-info).
+
+ This version of this YANG module is part of RFC 8345;
+ see the RFC itself for full legal notices.";
+
+ revision 2018-02-26 {
+ description
+ "Initial revision.";
+ reference
+ "RFC 8345: A YANG Data Model for Network Topologies";
+ }
+
+ grouping network-ref {
+ description
+ "Contains the information necessary to reference a network --
+ for example, an underlay network.";
+ leaf network-ref {
+ type leafref {
+ path "/nw-s:networks/nw-s:network/nw-s:network-id";
+ require-instance false;
+ }
+ description
+ "Used to reference a network -- for example, an underlay
+ network.";
+ }
+ }
+
+ grouping node-ref {
+ description
+ "Contains the information necessary to reference a node.";
+ leaf node-ref {
+ type leafref {
+ path "/nw-s:networks/nw-s:network[nw-s:network-id=current()"+
+ "/../network-ref]/nw-s:node/nw-s:node-id";
+ require-instance false;
+ }
+ description
+ "Used to reference a node.
+ Nodes are identified relative to the network that
+ contains them.";
+ }
+ uses network-ref;
+ }
+
+ container networks {
+ config false;
+ description
+ "Serves as a top-level container for a list of networks.";
+ list network {
+ key "network-id";
+ description
+ "Describes a network.
+ A network typically contains an inventory of nodes,
+ topological information (augmented through the
+ network-topology data model), and layering information.";
+ container network-types {
+ description
+ "Serves as an augmentation target.
+ The network type is indicated through corresponding
+ presence containers augmented into this container.";
+ }
+ leaf network-id {
+ type nw:network-id;
+ description
+ "Identifies a network.";
+ }
+ list supporting-network {
+ key "network-ref";
+ description
+ "An underlay network, used to represent layered network
+ topologies.";
+ leaf network-ref {
+ type leafref {
+ path "/nw-s:networks/nw-s:network/nw-s:network-id";
+ require-instance false;
+ }
+ description
+ "References the underlay network.";
+ }
+ }
+
+ list node {
+ key "node-id";
+ description
+ "The inventory of nodes of this network.";
+ leaf node-id {
+ type nw:node-id;
+ description
+ "Uniquely identifies a node within the containing
+ network.";
+ }
+ list supporting-node {
+ key "network-ref node-ref";
+ description
+ "Represents another node that is in an underlay network
+ and that supports this node. Used to represent layering
+ structure.";
+ leaf network-ref {
+ type leafref {
+ path "../../../nw-s:supporting-network/nw-s:network-ref";
+ require-instance false;
+ }
+ description
+ "References the underlay network of which the
+ underlay node is a part.";
+ }
+ leaf node-ref {
+ type leafref {
+ path "/nw-s:networks/nw-s:network/nw-s:node/nw-s:node-id";
+ require-instance false;
+ }
+ description
+ "References the underlay node itself.";
+ }
+ }
+ }
+ }
+ }
+}
diff --git a/cps-service/src/test/resources/ietf/ietf-network-topology-state@2018-02-26.yang b/cps-service/src/test/resources/ietf/ietf-network-topology-state@2018-02-26.yang
new file mode 100644
index 0000000000..1c1ba1b2e5
--- /dev/null
+++ b/cps-service/src/test/resources/ietf/ietf-network-topology-state@2018-02-26.yang
@@ -0,0 +1,273 @@
+module ietf-network-topology-state {
+ yang-version 1.1;
+ namespace "urn:ietf:params:xml:ns:yang:ietf-network-topology-state";
+ prefix nt-s;
+
+ import ietf-network-state {
+ prefix nw-s;
+ reference
+ "RFC 8345: A YANG Data Model for Network Topologies";
+ }
+ import ietf-network-topology {
+ prefix nt;
+ reference
+ "RFC 8345: A YANG Data Model for Network Topologies";
+ }
+
+ organization
+ "IETF I2RS (Interface to the Routing System) Working Group";
+
+ contact
+ "WG Web: <https://datatracker.ietf.org/wg/i2rs/>
+ WG List: <mailto:i2rs@ietf.org>
+
+ Editor: Alexander Clemm
+ <mailto:ludwig@clemm.org>
+
+ Editor: Jan Medved
+ <mailto:jmedved@cisco.com>
+
+ Editor: Robert Varga
+ <mailto:robert.varga@pantheon.tech>
+
+ Editor: Nitin Bahadur
+ <mailto:nitin_bahadur@yahoo.com>
+
+ Editor: Hariharan Ananthakrishnan
+ <mailto:hari@packetdesign.com>
+
+ Editor: Xufeng Liu
+ <mailto:xufeng.liu.ietf@gmail.com>";
+
+ description
+ "This module defines a common base data model for network
+ topology state, representing topology that either (1) is learned
+ or (2) results from applying topology that has been configured
+ per the 'ietf-network-topology' data model, mirroring the
+ corresponding data nodes in this data model. It augments the
+ base network state data model with links to connect nodes, as
+ well as termination points to terminate links on nodes.
+
+ The data model mirrors 'ietf-network-topology' but contains only
+ read-only state data. The data model is not needed when the
+ underlying implementation infrastructure supports the Network
+ Management Datastore Architecture (NMDA).
+
+ Copyright (c) 2018 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
+ (https://trustee.ietf.org/license-info).
+
+ This version of this YANG module is part of RFC 8345;
+ see the RFC itself for full legal notices.";
+
+ revision 2018-02-26 {
+ description
+ "Initial revision.";
+ reference
+ "RFC 8345: A YANG Data Model for Network Topologies";
+ }
+
+ grouping link-ref {
+ description
+ "References a link in a specific network. Although this
+ grouping is not used in this module, it is defined here for
+ the convenience of augmenting modules.";
+ leaf link-ref {
+ type leafref {
+ path "/nw-s:networks/nw-s:network[nw-s:network-id=current()"+
+ "/../network-ref]/nt-s:link/nt-s:link-id";
+ require-instance false;
+ }
+ description
+ "A type for an absolute reference to a link instance.
+ (This type should not be used for relative references.
+ In such a case, a relative path should be used instead.)";
+ }
+ uses nw-s:network-ref;
+ }
+
+ grouping tp-ref {
+ description
+ "References a termination point in a specific node. Although
+ this grouping is not used in this module, it is defined here
+ for the convenience of augmenting modules.";
+ leaf tp-ref {
+ type leafref {
+ path "/nw-s:networks/nw-s:network[nw-s:network-id=current()"+
+ "/../network-ref]/nw-s:node[nw-s:node-id=current()/../"+
+ "node-ref]/nt-s:termination-point/nt-s:tp-id";
+ require-instance false;
+ }
+ description
+ "A type for an absolute reference to a termination point.
+ (This type should not be used for relative references.
+ In such a case, a relative path should be used instead.)";
+ }
+ uses nw-s:node-ref;
+ }
+
+ augment "/nw-s:networks/nw-s:network" {
+ description
+ "Add links to the network data model.";
+ list link {
+ key "link-id";
+ description
+ "A network link connects a local (source) node and
+ a remote (destination) node via a set of the respective
+ node's termination points. It is possible to have several
+ links between the same source and destination nodes.
+ Likewise, a link could potentially be re-homed between
+ termination points. Therefore, in order to ensure that we
+ would always know to distinguish between links, every link
+ is identified by a dedicated link identifier. Note that a
+ link models a point-to-point link, not a multipoint link.";
+ container source {
+ description
+ "This container holds the logical source of a particular
+ link.";
+ leaf source-node {
+ type leafref {
+ path "../../../nw-s:node/nw-s:node-id";
+ require-instance false;
+ }
+ description
+ "Source node identifier. Must be in the same topology.";
+ }
+ leaf source-tp {
+ type leafref {
+ path "../../../nw-s:node[nw-s:node-id=current()/../"+
+ "source-node]/termination-point/tp-id";
+ require-instance false;
+ }
+ description
+ "This termination point is located within the source node
+ and terminates the link.";
+ }
+ }
+ container destination {
+ description
+ "This container holds the logical destination of a
+ particular link.";
+ leaf dest-node {
+ type leafref {
+ path "../../../nw-s:node/nw-s:node-id";
+ require-instance false;
+ }
+ description
+ "Destination node identifier. Must be in the same
+ network.";
+ }
+
+ leaf dest-tp {
+ type leafref {
+ path "../../../nw-s:node[nw-s:node-id=current()/../"+
+ "dest-node]/termination-point/tp-id";
+ require-instance false;
+ }
+ description
+ "This termination point is located within the
+ destination node and terminates the link.";
+ }
+ }
+ leaf link-id {
+ type nt:link-id;
+ description
+ "The identifier of a link in the topology.
+ A link is specific to a topology to which it belongs.";
+ }
+ list supporting-link {
+ key "network-ref link-ref";
+ description
+ "Identifies the link or links on which this link depends.";
+ leaf network-ref {
+ type leafref {
+ path "../../../nw-s:supporting-network/nw-s:network-ref";
+ require-instance false;
+ }
+ description
+ "This leaf identifies in which underlay topology
+ the supporting link is present.";
+ }
+ leaf link-ref {
+ type leafref {
+ path "/nw-s:networks/nw-s:network[nw-s:network-id="+
+ "current()/../network-ref]/link/link-id";
+ require-instance false;
+ }
+ description
+ "This leaf identifies a link that is a part
+ of this link's underlay. Reference loops in which
+ a link identifies itself as its underlay, either
+ directly or transitively, are not allowed.";
+ }
+ }
+ }
+ }
+
+ augment "/nw-s:networks/nw-s:network/nw-s:node" {
+ description
+ "Augments termination points that terminate links.
+ Termination points can ultimately be mapped to interfaces.";
+ list termination-point {
+ key "tp-id";
+ description
+ "A termination point can terminate a link.
+ Depending on the type of topology, a termination point
+ could, for example, refer to a port or an interface.";
+ leaf tp-id {
+ type nt:tp-id;
+ description
+ "Termination point identifier.";
+ }
+ list supporting-termination-point {
+ key "network-ref node-ref tp-ref";
+ description
+ "This list identifies any termination points on which a
+ given termination point depends or onto which it maps.
+ Those termination points will themselves be contained
+ in a supporting node. This dependency information can be
+ inferred from the dependencies between links. Therefore,
+ this item is not separately configurable. Hence, no
+ corresponding constraint needs to be articulated.
+ The corresponding information is simply provided by the
+ implementing system.";
+ leaf network-ref {
+ type leafref {
+ path "../../../nw-s:supporting-node/nw-s:network-ref";
+ require-instance false;
+ }
+ description
+ "This leaf identifies in which topology the
+ supporting termination point is present.";
+ }
+ leaf node-ref {
+ type leafref {
+ path "../../../nw-s:supporting-node/nw-s:node-ref";
+ require-instance false;
+ }
+ description
+ "This leaf identifies in which node the supporting
+ termination point is present.";
+ }
+
+ leaf tp-ref {
+ type leafref {
+ path "/nw-s:networks/nw-s:network[nw-s:network-id="+
+ "current()/../network-ref]/nw-s:node[nw-s:node-id="+
+ "current()/../node-ref]/termination-point/tp-id";
+ require-instance false;
+ }
+ description
+ "Reference to the underlay node (the underlay node must
+ be in a different topology).";
+ }
+ }
+ }
+ }
+}
diff --git a/cps-service/src/test/resources/ietf/ietf-network-topology@2018-02-26.yang b/cps-service/src/test/resources/ietf/ietf-network-topology@2018-02-26.yang
new file mode 100644
index 0000000000..1ec944d791
--- /dev/null
+++ b/cps-service/src/test/resources/ietf/ietf-network-topology@2018-02-26.yang
@@ -0,0 +1,294 @@
+module ietf-network-topology {
+ yang-version 1.1;
+ namespace "urn:ietf:params:xml:ns:yang:ietf-network-topology";
+ prefix nt;
+
+ import ietf-inet-types {
+ prefix inet;
+ reference
+ "RFC 6991: Common YANG Data Types";
+ }
+ import ietf-network {
+ prefix nw;
+ reference
+ "RFC 8345: A YANG Data Model for Network Topologies";
+ }
+
+ organization
+ "IETF I2RS (Interface to the Routing System) Working Group";
+
+ contact
+ "WG Web: <https://datatracker.ietf.org/wg/i2rs/>
+ WG List: <mailto:i2rs@ietf.org>
+
+ Editor: Alexander Clemm
+ <mailto:ludwig@clemm.org>
+
+ Editor: Jan Medved
+ <mailto:jmedved@cisco.com>
+
+ Editor: Robert Varga
+ <mailto:robert.varga@pantheon.tech>
+
+ Editor: Nitin Bahadur
+ <mailto:nitin_bahadur@yahoo.com>
+
+ Editor: Hariharan Ananthakrishnan
+ <mailto:hari@packetdesign.com>
+
+ Editor: Xufeng Liu
+ <mailto:xufeng.liu.ietf@gmail.com>";
+
+ description
+ "This module defines a common base model for a network topology,
+ augmenting the base network data model with links to connect
+ nodes, as well as termination points to terminate links
+ on nodes.
+
+ Copyright (c) 2018 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
+ (https://trustee.ietf.org/license-info).
+
+ This version of this YANG module is part of RFC 8345;
+ see the RFC itself for full legal notices.";
+
+ revision 2018-02-26 {
+ description
+ "Initial revision.";
+ reference
+ "RFC 8345: A YANG Data Model for Network Topologies";
+ }
+
+ typedef link-id {
+ type inet:uri;
+ description
+ "An identifier for a link in a topology. The precise
+ structure of the link-id will be up to the implementation.
+ The identifier SHOULD be chosen such that the same link in a
+ real network topology will always be identified through the
+ same identifier, even if the data model is instantiated in
+ separate datastores. An implementation MAY choose to capture
+ semantics in the identifier -- for example, to indicate the
+ type of link and/or the type of topology of which the link is
+ a part.";
+ }
+
+ typedef tp-id {
+ type inet:uri;
+ description
+ "An identifier for termination points on a node. The precise
+ structure of the tp-id will be up to the implementation.
+ The identifier SHOULD be chosen such that the same termination
+ point in a real network topology will always be identified
+ through the same identifier, even if the data model is
+ instantiated in separate datastores. An implementation MAY
+ choose to capture semantics in the identifier -- for example,
+ to indicate the type of termination point and/or the type of
+ node that contains the termination point.";
+ }
+
+ grouping link-ref {
+ description
+ "This grouping can be used to reference a link in a specific
+ network. Although it is not used in this module, it is
+ defined here for the convenience of augmenting modules.";
+ leaf link-ref {
+ type leafref {
+ path "/nw:networks/nw:network[nw:network-id=current()/../"+
+ "network-ref]/nt:link/nt:link-id";
+ require-instance false;
+ }
+ description
+ "A type for an absolute reference to a link instance.
+ (This type should not be used for relative references.
+ In such a case, a relative path should be used instead.)";
+ }
+ uses nw:network-ref;
+ }
+
+ grouping tp-ref {
+ description
+ "This grouping can be used to reference a termination point
+ in a specific node. Although it is not used in this module,
+ it is defined here for the convenience of augmenting
+ modules.";
+ leaf tp-ref {
+ type leafref {
+ path "/nw:networks/nw:network[nw:network-id=current()/../"+
+ "network-ref]/nw:node[nw:node-id=current()/../"+
+ "node-ref]/nt:termination-point/nt:tp-id";
+ require-instance false;
+ }
+ description
+ "A type for an absolute reference to a termination point.
+ (This type should not be used for relative references.
+ In such a case, a relative path should be used instead.)";
+ }
+ uses nw:node-ref;
+ }
+
+ augment "/nw:networks/nw:network" {
+ description
+ "Add links to the network data model.";
+ list link {
+ key "link-id";
+ description
+ "A network link connects a local (source) node and
+ a remote (destination) node via a set of the respective
+ node's termination points. It is possible to have several
+ links between the same source and destination nodes.
+ Likewise, a link could potentially be re-homed between
+ termination points. Therefore, in order to ensure that we
+ would always know to distinguish between links, every link
+ is identified by a dedicated link identifier. Note that a
+ link models a point-to-point link, not a multipoint link.";
+ leaf link-id {
+ type link-id;
+ description
+ "The identifier of a link in the topology.
+ A link is specific to a topology to which it belongs.";
+ }
+ container source {
+ description
+ "This container holds the logical source of a particular
+ link.";
+ leaf source-node {
+ type leafref {
+ path "../../../nw:node/nw:node-id";
+ require-instance false;
+ }
+ description
+ "Source node identifier. Must be in the same topology.";
+ }
+ leaf source-tp {
+ type leafref {
+ path "../../../nw:node[nw:node-id=current()/../"+
+ "source-node]/termination-point/tp-id";
+ require-instance false;
+ }
+ description
+ "This termination point is located within the source node
+ and terminates the link.";
+ }
+ }
+
+ container destination {
+ description
+ "This container holds the logical destination of a
+ particular link.";
+ leaf dest-node {
+ type leafref {
+ path "../../../nw:node/nw:node-id";
+ require-instance false;
+ }
+ description
+ "Destination node identifier. Must be in the same
+ network.";
+ }
+ leaf dest-tp {
+ type leafref {
+ path "../../../nw:node[nw:node-id=current()/../"+
+ "dest-node]/termination-point/tp-id";
+ require-instance false;
+ }
+ description
+ "This termination point is located within the
+ destination node and terminates the link.";
+ }
+ }
+ list supporting-link {
+ key "network-ref link-ref";
+ description
+ "Identifies the link or links on which this link depends.";
+ leaf network-ref {
+ type leafref {
+ path "../../../nw:supporting-network/nw:network-ref";
+ require-instance false;
+ }
+ description
+ "This leaf identifies in which underlay topology
+ the supporting link is present.";
+ }
+
+ leaf link-ref {
+ type leafref {
+ path "/nw:networks/nw:network[nw:network-id=current()/"+
+ "../network-ref]/link/link-id";
+ require-instance false;
+ }
+ description
+ "This leaf identifies a link that is a part
+ of this link's underlay. Reference loops in which
+ a link identifies itself as its underlay, either
+ directly or transitively, are not allowed.";
+ }
+ }
+ }
+ }
+ augment "/nw:networks/nw:network/nw:node" {
+ description
+ "Augments termination points that terminate links.
+ Termination points can ultimately be mapped to interfaces.";
+ list termination-point {
+ key "tp-id";
+ description
+ "A termination point can terminate a link.
+ Depending on the type of topology, a termination point
+ could, for example, refer to a port or an interface.";
+ leaf tp-id {
+ type tp-id;
+ description
+ "Termination point identifier.";
+ }
+ list supporting-termination-point {
+ key "network-ref node-ref tp-ref";
+ description
+ "This list identifies any termination points on which a
+ given termination point depends or onto which it maps.
+ Those termination points will themselves be contained
+ in a supporting node. This dependency information can be
+ inferred from the dependencies between links. Therefore,
+ this item is not separately configurable. Hence, no
+ corresponding constraint needs to be articulated.
+ The corresponding information is simply provided by the
+ implementing system.";
+
+ leaf network-ref {
+ type leafref {
+ path "../../../nw:supporting-node/nw:network-ref";
+ require-instance false;
+ }
+ description
+ "This leaf identifies in which topology the
+ supporting termination point is present.";
+ }
+ leaf node-ref {
+ type leafref {
+ path "../../../nw:supporting-node/nw:node-ref";
+ require-instance false;
+ }
+ description
+ "This leaf identifies in which node the supporting
+ termination point is present.";
+ }
+ leaf tp-ref {
+ type leafref {
+ path "/nw:networks/nw:network[nw:network-id=current()/"+
+ "../network-ref]/nw:node[nw:node-id=current()/../"+
+ "node-ref]/termination-point/tp-id";
+ require-instance false;
+ }
+ description
+ "Reference to the underlay node (the underlay node must
+ be in a different topology).";
+ }
+ }
+ }
+ }
+}
diff --git a/cps-service/src/test/resources/ietf/ietf-network@2018-02-26.yang b/cps-service/src/test/resources/ietf/ietf-network@2018-02-26.yang
new file mode 100644
index 0000000000..6a03d7e416
--- /dev/null
+++ b/cps-service/src/test/resources/ietf/ietf-network@2018-02-26.yang
@@ -0,0 +1,192 @@
+module ietf-network {
+ yang-version 1.1;
+ namespace "urn:ietf:params:xml:ns:yang:ietf-network";
+ prefix nw;
+
+ import ietf-inet-types {
+ prefix inet;
+ reference
+ "RFC 6991: Common YANG Data Types";
+ }
+
+ organization
+ "IETF I2RS (Interface to the Routing System) Working Group";
+
+ contact
+ "WG Web: <https://datatracker.ietf.org/wg/i2rs/>
+ WG List: <mailto:i2rs@ietf.org>
+
+ Editor: Alexander Clemm
+ <mailto:ludwig@clemm.org>
+
+ Editor: Jan Medved
+ <mailto:jmedved@cisco.com>
+
+ Editor: Robert Varga
+ <mailto:robert.varga@pantheon.tech>
+
+ Editor: Nitin Bahadur
+ <mailto:nitin_bahadur@yahoo.com>
+
+ Editor: Hariharan Ananthakrishnan
+ <mailto:hari@packetdesign.com>
+
+ Editor: Xufeng Liu
+ <mailto:xufeng.liu.ietf@gmail.com>";
+ description
+ "This module defines a common base data model for a collection
+ of nodes in a network. Node definitions are further used
+ in network topologies and inventories.
+
+ Copyright (c) 2018 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
+ (https://trustee.ietf.org/license-info).
+
+ This version of this YANG module is part of RFC 8345;
+ see the RFC itself for full legal notices.";
+
+ revision 2018-02-26 {
+ description
+ "Initial revision.";
+ reference
+ "RFC 8345: A YANG Data Model for Network Topologies";
+ }
+
+ typedef node-id {
+ type inet:uri;
+ description
+ "Identifier for a node. The precise structure of the node-id
+ will be up to the implementation. For example, some
+ implementations MAY pick a URI that includes the network-id
+ as part of the path. The identifier SHOULD be chosen
+ such that the same node in a real network topology will
+ always be identified through the same identifier, even if
+ the data model is instantiated in separate datastores. An
+ implementation MAY choose to capture semantics in the
+ identifier -- for example, to indicate the type of node.";
+ }
+
+ typedef network-id {
+ type inet:uri;
+ description
+ "Identifier for a network. The precise structure of the
+ network-id will be up to the implementation. The identifier
+ SHOULD be chosen such that the same network will always be
+ identified through the same identifier, even if the data model
+ is instantiated in separate datastores. An implementation MAY
+ choose to capture semantics in the identifier -- for example,
+ to indicate the type of network.";
+ }
+
+ grouping network-ref {
+ description
+ "Contains the information necessary to reference a network --
+ for example, an underlay network.";
+ leaf network-ref {
+ type leafref {
+ path "/nw:networks/nw:network/nw:network-id";
+ require-instance false;
+ }
+ description
+ "Used to reference a network -- for example, an underlay
+ network.";
+ }
+ }
+
+ grouping node-ref {
+ description
+ "Contains the information necessary to reference a node.";
+ leaf node-ref {
+ type leafref {
+ path "/nw:networks/nw:network[nw:network-id=current()/../"+
+ "network-ref]/nw:node/nw:node-id";
+ require-instance false;
+ }
+ description
+ "Used to reference a node.
+ Nodes are identified relative to the network that
+ contains them.";
+ }
+ uses network-ref;
+ }
+
+ container networks {
+ description
+ "Serves as a top-level container for a list of networks.";
+ list network {
+ key "network-id";
+ description
+ "Describes a network.
+ A network typically contains an inventory of nodes,
+ topological information (augmented through the
+ network-topology data model), and layering information.";
+ leaf network-id {
+ type network-id;
+ description
+ "Identifies a network.";
+ }
+ container network-types {
+ description
+ "Serves as an augmentation target.
+ The network type is indicated through corresponding
+ presence containers augmented into this container.";
+ }
+ list supporting-network {
+ key "network-ref";
+ description
+ "An underlay network, used to represent layered network
+ topologies.";
+ leaf network-ref {
+ type leafref {
+ path "/nw:networks/nw:network/nw:network-id";
+ require-instance false;
+ }
+ description
+ "References the underlay network.";
+ }
+ }
+
+ list node {
+ key "node-id";
+ description
+ "The inventory of nodes of this network.";
+ leaf node-id {
+ type node-id;
+ description
+ "Uniquely identifies a node within the containing
+ network.";
+ }
+ list supporting-node {
+ key "network-ref node-ref";
+ description
+ "Represents another node that is in an underlay network
+ and that supports this node. Used to represent layering
+ structure.";
+ leaf network-ref {
+ type leafref {
+ path "../../../nw:supporting-network/nw:network-ref";
+ require-instance false;
+ }
+ description
+ "References the underlay network of which the
+ underlay node is a part.";
+ }
+ leaf node-ref {
+ type leafref {
+ path "/nw:networks/nw:network/nw:node/nw:node-id";
+ require-instance false;
+ }
+ description
+ "References the underlay node itself.";
+ }
+ }
+ }
+ }
+ }
+}
diff --git a/cps-service/src/test/resources/ietf/ietf-yang-types@2013-07-15.yang b/cps-service/src/test/resources/ietf/ietf-yang-types@2013-07-15.yang
new file mode 100644
index 0000000000..ee58fa3ab0
--- /dev/null
+++ b/cps-service/src/test/resources/ietf/ietf-yang-types@2013-07-15.yang
@@ -0,0 +1,474 @@
+module ietf-yang-types {
+
+ namespace "urn:ietf:params:xml:ns:yang:ietf-yang-types";
+ prefix "yang";
+
+ organization
+ "IETF NETMOD (NETCONF Data Modeling Language) Working Group";
+
+ contact
+ "WG Web: <http://tools.ietf.org/wg/netmod/>
+ WG List: <mailto:netmod@ietf.org>
+
+ WG Chair: David Kessens
+ <mailto:david.kessens@nsn.com>
+
+ WG Chair: Juergen Schoenwaelder
+ <mailto:j.schoenwaelder@jacobs-university.de>
+
+ Editor: Juergen Schoenwaelder
+ <mailto:j.schoenwaelder@jacobs-university.de>";
+
+ description
+ "This module contains a collection of generally useful derived
+ YANG data types.
+
+ Copyright (c) 2013 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 6991; see
+ the RFC itself for full legal notices.";
+
+ revision 2013-07-15 {
+ description
+ "This revision adds the following new data types:
+ - yang-identifier
+ - hex-string
+ - uuid
+ - dotted-quad";
+ reference
+ "RFC 6991: Common YANG Data Types";
+ }
+
+ revision 2010-09-24 {
+ description
+ "Initial revision.";
+ reference
+ "RFC 6021: Common YANG Data Types";
+ }
+
+ /*** collection of counter and gauge types ***/
+
+ typedef counter32 {
+ type uint32;
+ description
+ "The counter32 type represents a non-negative integer
+ that monotonically increases until it reaches a
+ maximum value of 2^32-1 (4294967295 decimal), when it
+ wraps around and starts increasing again from zero.
+
+ Counters have no defined 'initial' value, and thus, a
+ single value of a counter has (in general) no information
+ content. Discontinuities in the monotonically increasing
+ value normally occur at re-initialization of the
+ management system, and at other times as specified in the
+ description of a schema node using this type. If such
+ other times can occur, for example, the creation of
+ a schema node of type counter32 at times other than
+ re-initialization, then a corresponding schema node
+ should be defined, with an appropriate type, to indicate
+ the last discontinuity.
+
+ The counter32 type should not be used for configuration
+ schema nodes. A default statement SHOULD NOT be used in
+ combination with the type counter32.
+
+ In the value set and its semantics, this type is equivalent
+ to the Counter32 type of the SMIv2.";
+ reference
+ "RFC 2578: Structure of Management Information Version 2
+ (SMIv2)";
+ }
+
+ typedef zero-based-counter32 {
+ type yang:counter32;
+ default "0";
+ description
+ "The zero-based-counter32 type represents a counter32
+ that has the defined 'initial' value zero.
+
+ A schema node of this type will be set to zero (0) on creation
+ and will thereafter increase monotonically until it reaches
+ a maximum value of 2^32-1 (4294967295 decimal), when it
+ wraps around and starts increasing again from zero.
+
+ Provided that an application discovers a new schema node
+ of this type within the minimum time to wrap, it can use the
+ 'initial' value as a delta. It is important for a management
+ station to be aware of this minimum time and the actual time
+ between polls, and to discard data if the actual time is too
+ long or there is no defined minimum time.
+
+ In the value set and its semantics, this type is equivalent
+ to the ZeroBasedCounter32 textual convention of the SMIv2.";
+ reference
+ "RFC 4502: Remote Network Monitoring Management Information
+ Base Version 2";
+ }
+
+ typedef counter64 {
+ type uint64;
+ description
+ "The counter64 type represents a non-negative integer
+ that monotonically increases until it reaches a
+ maximum value of 2^64-1 (18446744073709551615 decimal),
+ when it wraps around and starts increasing again from zero.
+
+ Counters have no defined 'initial' value, and thus, a
+ single value of a counter has (in general) no information
+ content. Discontinuities in the monotonically increasing
+ value normally occur at re-initialization of the
+ management system, and at other times as specified in the
+ description of a schema node using this type. If such
+ other times can occur, for example, the creation of
+ a schema node of type counter64 at times other than
+ re-initialization, then a corresponding schema node
+ should be defined, with an appropriate type, to indicate
+ the last discontinuity.
+
+ The counter64 type should not be used for configuration
+ schema nodes. A default statement SHOULD NOT be used in
+ combination with the type counter64.
+
+ In the value set and its semantics, this type is equivalent
+ to the Counter64 type of the SMIv2.";
+ reference
+ "RFC 2578: Structure of Management Information Version 2
+ (SMIv2)";
+ }
+
+ typedef zero-based-counter64 {
+ type yang:counter64;
+ default "0";
+ description
+ "The zero-based-counter64 type represents a counter64 that
+ has the defined 'initial' value zero.
+
+ A schema node of this type will be set to zero (0) on creation
+ and will thereafter increase monotonically until it reaches
+ a maximum value of 2^64-1 (18446744073709551615 decimal),
+ when it wraps around and starts increasing again from zero.
+
+ Provided that an application discovers a new schema node
+ of this type within the minimum time to wrap, it can use the
+ 'initial' value as a delta. It is important for a management
+ station to be aware of this minimum time and the actual time
+ between polls, and to discard data if the actual time is too
+ long or there is no defined minimum time.
+
+ In the value set and its semantics, this type is equivalent
+ to the ZeroBasedCounter64 textual convention of the SMIv2.";
+ reference
+ "RFC 2856: Textual Conventions for Additional High Capacity
+ Data Types";
+ }
+
+ typedef gauge32 {
+ type uint32;
+ description
+ "The gauge32 type represents a non-negative integer, which
+ may increase or decrease, but shall never exceed a maximum
+ value, nor fall below a minimum value. The maximum value
+ cannot be greater than 2^32-1 (4294967295 decimal), and
+ the minimum value cannot be smaller than 0. The value of
+ a gauge32 has its maximum value whenever the information
+ being modeled is greater than or equal to its maximum
+ value, and has its minimum value whenever the information
+ being modeled is smaller than or equal to its minimum value.
+ If the information being modeled subsequently decreases
+ below (increases above) the maximum (minimum) value, the
+ gauge32 also decreases (increases).
+
+ In the value set and its semantics, this type is equivalent
+ to the Gauge32 type of the SMIv2.";
+ reference
+ "RFC 2578: Structure of Management Information Version 2
+ (SMIv2)";
+ }
+
+ typedef gauge64 {
+ type uint64;
+ description
+ "The gauge64 type represents a non-negative integer, which
+ may increase or decrease, but shall never exceed a maximum
+ value, nor fall below a minimum value. The maximum value
+ cannot be greater than 2^64-1 (18446744073709551615), and
+ the minimum value cannot be smaller than 0. The value of
+ a gauge64 has its maximum value whenever the information
+ being modeled is greater than or equal to its maximum
+ value, and has its minimum value whenever the information
+ being modeled is smaller than or equal to its minimum value.
+ If the information being modeled subsequently decreases
+ below (increases above) the maximum (minimum) value, the
+ gauge64 also decreases (increases).
+
+ In the value set and its semantics, this type is equivalent
+ to the CounterBasedGauge64 SMIv2 textual convention defined
+ in RFC 2856";
+ reference
+ "RFC 2856: Textual Conventions for Additional High Capacity
+ Data Types";
+ }
+
+ /*** collection of identifier-related types ***/
+
+ typedef object-identifier {
+ type string {
+ pattern '(([0-1](\.[1-3]?[0-9]))|(2\.(0|([1-9]\d*))))'
+ + '(\.(0|([1-9]\d*)))*';
+ }
+ description
+ "The object-identifier type represents administratively
+ assigned names in a registration-hierarchical-name tree.
+
+ Values of this type are denoted as a sequence of numerical
+ non-negative sub-identifier values. Each sub-identifier
+ value MUST NOT exceed 2^32-1 (4294967295). Sub-identifiers
+ are separated by single dots and without any intermediate
+ whitespace.
+
+ The ASN.1 standard restricts the value space of the first
+ sub-identifier to 0, 1, or 2. Furthermore, the value space
+ of the second sub-identifier is restricted to the range
+ 0 to 39 if the first sub-identifier is 0 or 1. Finally,
+ the ASN.1 standard requires that an object identifier
+ has always at least two sub-identifiers. The pattern
+ captures these restrictions.
+
+ Although the number of sub-identifiers is not limited,
+ module designers should realize that there may be
+ implementations that stick with the SMIv2 limit of 128
+ sub-identifiers.
+
+ This type is a superset of the SMIv2 OBJECT IDENTIFIER type
+ since it is not restricted to 128 sub-identifiers. Hence,
+ this type SHOULD NOT be used to represent the SMIv2 OBJECT
+ IDENTIFIER type; the object-identifier-128 type SHOULD be
+ used instead.";
+ reference
+ "ISO9834-1: Information technology -- Open Systems
+ Interconnection -- Procedures for the operation of OSI
+ Registration Authorities: General procedures and top
+ arcs of the ASN.1 Object Identifier tree";
+ }
+
+ typedef object-identifier-128 {
+ type object-identifier {
+ pattern '\d*(\.\d*){1,127}';
+ }
+ description
+ "This type represents object-identifiers restricted to 128
+ sub-identifiers.
+
+ In the value set and its semantics, this type is equivalent
+ to the OBJECT IDENTIFIER type of the SMIv2.";
+ reference
+ "RFC 2578: Structure of Management Information Version 2
+ (SMIv2)";
+ }
+
+ typedef yang-identifier {
+ type string {
+ length "1..max";
+ pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*';
+ pattern '.|..|[^xX].*|.[^mM].*|..[^lL].*';
+ }
+ description
+ "A YANG identifier string as defined by the 'identifier'
+ rule in Section 12 of RFC 6020. An identifier must
+ start with an alphabetic character or an underscore
+ followed by an arbitrary sequence of alphabetic or
+ numeric characters, underscores, hyphens, or dots.
+
+ A YANG identifier MUST NOT start with any possible
+ combination of the lowercase or uppercase character
+ sequence 'xml'.";
+ reference
+ "RFC 6020: YANG - A Data Modeling Language for the Network
+ Configuration Protocol (NETCONF)";
+ }
+
+ /*** collection of types related to date and time***/
+
+ typedef date-and-time {
+ type string {
+ pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?'
+ + '(Z|[\+\-]\d{2}:\d{2})';
+ }
+ description
+ "The date-and-time type is a profile of the ISO 8601
+ standard for representation of dates and times using the
+ Gregorian calendar. The profile is defined by the
+ date-time production in Section 5.6 of RFC 3339.
+
+ The date-and-time type is compatible with the dateTime XML
+ schema type with the following notable exceptions:
+
+ (a) The date-and-time type does not allow negative years.
+
+ (b) The date-and-time time-offset -00:00 indicates an unknown
+ time zone (see RFC 3339) while -00:00 and +00:00 and Z
+ all represent the same time zone in dateTime.
+
+ (c) The canonical format (see below) of data-and-time values
+ differs from the canonical format used by the dateTime XML
+ schema type, which requires all times to be in UTC using
+ the time-offset 'Z'.
+
+ This type is not equivalent to the DateAndTime textual
+ convention of the SMIv2 since RFC 3339 uses a different
+ separator between full-date and full-time and provides
+ higher resolution of time-secfrac.
+
+ The canonical format for date-and-time values with a known time
+ zone uses a numeric time zone offset that is calculated using
+ the device's configured known offset to UTC time. A change of
+ the device's offset to UTC time will cause date-and-time values
+ to change accordingly. Such changes might happen periodically
+ in case a server follows automatically daylight saving time
+ (DST) time zone offset changes. The canonical format for
+ date-and-time values with an unknown time zone (usually
+ referring to the notion of local time) uses the time-offset
+ -00:00.";
+ reference
+ "RFC 3339: Date and Time on the Internet: Timestamps
+ RFC 2579: Textual Conventions for SMIv2
+ XSD-TYPES: XML Schema Part 2: Datatypes Second Edition";
+ }
+
+ typedef timeticks {
+ type uint32;
+ description
+ "The timeticks type represents a non-negative integer that
+ represents the time, modulo 2^32 (4294967296 decimal), in
+ hundredths of a second between two epochs. When a schema
+ node is defined that uses this type, the description of
+ the schema node identifies both of the reference epochs.
+
+ In the value set and its semantics, this type is equivalent
+ to the TimeTicks type of the SMIv2.";
+ reference
+ "RFC 2578: Structure of Management Information Version 2
+ (SMIv2)";
+ }
+
+ typedef timestamp {
+ type yang:timeticks;
+ description
+ "The timestamp type represents the value of an associated
+ timeticks schema node at which a specific occurrence
+ happened. The specific occurrence must be defined in the
+ description of any schema node defined using this type. When
+ the specific occurrence occurred prior to the last time the
+ associated timeticks attribute was zero, then the timestamp
+ value is zero. Note that this requires all timestamp values
+ to be reset to zero when the value of the associated timeticks
+ attribute reaches 497+ days and wraps around to zero.
+
+ The associated timeticks schema node must be specified
+ in the description of any schema node using this type.
+
+ In the value set and its semantics, this type is equivalent
+ to the TimeStamp textual convention of the SMIv2.";
+ reference
+ "RFC 2579: Textual Conventions for SMIv2";
+ }
+
+ /*** collection of generic address types ***/
+
+ typedef phys-address {
+ type string {
+ pattern '([0-9a-fA-F]{2}(:[0-9a-fA-F]{2})*)?';
+ }
+
+ description
+ "Represents media- or physical-level addresses represented
+ as a sequence octets, each octet represented by two hexadecimal
+ numbers. Octets are separated by colons. The canonical
+ representation uses lowercase characters.
+
+ In the value set and its semantics, this type is equivalent
+ to the PhysAddress textual convention of the SMIv2.";
+ reference
+ "RFC 2579: Textual Conventions for SMIv2";
+ }
+
+ typedef mac-address {
+ type string {
+ pattern '[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}';
+ }
+ description
+ "The mac-address type represents an IEEE 802 MAC address.
+ The canonical representation uses lowercase characters.
+
+ In the value set and its semantics, this type is equivalent
+ to the MacAddress textual convention of the SMIv2.";
+ reference
+ "IEEE 802: IEEE Standard for Local and Metropolitan Area
+ Networks: Overview and Architecture
+ RFC 2579: Textual Conventions for SMIv2";
+ }
+
+ /*** collection of XML-specific types ***/
+
+ typedef xpath1.0 {
+ type string;
+ description
+ "This type represents an XPATH 1.0 expression.
+
+ When a schema node is defined that uses this type, the
+ description of the schema node MUST specify the XPath
+ context in which the XPath expression is evaluated.";
+ reference
+ "XPATH: XML Path Language (XPath) Version 1.0";
+ }
+
+ /*** collection of string types ***/
+
+ typedef hex-string {
+ type string {
+ pattern '([0-9a-fA-F]{2}(:[0-9a-fA-F]{2})*)?';
+ }
+ description
+ "A hexadecimal string with octets represented as hex digits
+ separated by colons. The canonical representation uses
+ lowercase characters.";
+ }
+
+ typedef uuid {
+ type string {
+ pattern '[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-'
+ + '[0-9a-fA-F]{4}-[0-9a-fA-F]{12}';
+ }
+ description
+ "A Universally Unique IDentifier in the string representation
+ defined in RFC 4122. The canonical representation uses
+ lowercase characters.
+
+ The following is an example of a UUID in string representation:
+ f81d4fae-7dec-11d0-a765-00a0c91e6bf6
+ ";
+ reference
+ "RFC 4122: A Universally Unique IDentifier (UUID) URN
+ Namespace";
+ }
+
+ typedef dotted-quad {
+ type string {
+ pattern
+ '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'
+ + '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])';
+ }
+ description
+ "An unsigned 32-bit number expressed in the dotted-quad
+ notation, i.e., four octets written as decimal numbers
+ and separated with the '.' (full stop) character.";
+ }
+}