| Internet-Draft | TVR Schedule YANG | October 2023 |
| Qu, et al. | Expires 13 April 2024 | [Page] |
The YANG model in this document includes three modules, and can be used to manage network resources and topologies with scheduled attributes, such as predictable link loss and link connectivity as a function of time. The intent is to have this information be utilized by Time-Variant Routing systems.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 13 April 2024.¶
Copyright (c) 2023 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 (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
YANG [RFC7950] is a data definition language used to define the contents of a conceptual data store that allows networked devices to be managed using NETCONF [RFC6241]. YANG is proving relevant beyond its initial confines, as bindings to other interfaces (e.g., ReST) and encodings other than XML (e.g., JSON) are being defined. Furthermore, YANG data models can be used as the basis for implementation of other interfaces, such as CLI and programmatic APIs.¶
In some network scenarios, it's possible to predict the times at which one router will be able to establish a link with another router. Links can be predictably lost and re-established, and neighbors may change as a function of time. For examples of such networks and scenarios, please reference TVR (Time-Variant Routing) Use Cases [I-D.ietf-tvr-use-cases].¶
The YANG model in this document can be used to manage network resources and topologies with scheduled attributes. There are three YANG modules in this document.¶
Module ietf-tvr-schedule.yang contains the schedule YANG definitions. Module ietf-tvr-topology.yang defines a network topology with time-variant availability. Module ietf-tvr-node.yang is to be used to manage scheduled attributes of a single node.¶
The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA) [RFC8342].¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] [RFC8174].¶
This document uses the graphical representation of data models defined in [RFC8340].¶
Module ietf-tvr-schedule.yang contains schedule definitions that can be used by other modules.¶
The grouping "schedule" is defined in this module, which can be used by other models to define time variant attributes.¶
The grouping "schedule-lifetime" is to define the lifetime of a "schedule". It has a "schedule-start-time" using "date-and-time", and the "schedule-end-time" can be an option of infinite, duration or date time. If the "schedule-start-time" is set to a time in the past when a configuration is done, the schedule is effective right away.¶
A schedule may have a repetition pattern and the leaf "recurrence" defines the duration of the repetition pattern of in the "base-schedule", such as daily or weekly. The "base-schedule", which is the basic unit of this schedule, consists a list of "intervals". These intervals specify the attribute values during the "base-schedule". The "recurrence" defines the duration of each "base-schedule", so the configured "intervals" should be within this duration. For example, if the "recurrence" is configured as daily, the last "end-time" in the list should not be larger than 24 hours, which is 8640000 in timeticks. Also each "end-time" must be greater than the "start-time" in the same interval. The "timeticks" defined in [RFC6991] is used to specify the relative "start-time" and "end-time" in each recurrence.¶
No leaf is provided for values in the schedule. The base-schedule can, if necessary, be augmented in the YANG "uses" clause to fill in the empty value container with whatever is required to represent the affected data.¶
When a schedule starts in the middle of an recurrence, for example, the recurrence is set to "daily", and the "schedule-start-time" is 8:00AM, when the schedule starts, the "value" should be the 8:00AM value defined by the "base-schedule".¶
When an attribute's schedule ends, the "value-default" SHOULD be used, if present.¶
The following figure provides an illustration of two attributes and their scheduled value changes. The attributes A1 and A2 take on different values at different times. The attribute A1 will take on the value v1 from the time t0 until t1, the value v2 from t1 until t2, and v3 from t2 until t3. The attribute A2 will take on the value vv1 from time t0 until t1 and vv2 from v1 until v3.¶
Attributes
+-------------------+----------+------+
A1 | v1 | v2 | v3 |
+-------------------+----------+------+
A2 | vv1 | vv2 |
+-------------------+-----------------+
t0 t1 t2 t3
Time
The following is the tree diagram of the groupings in ietf-tvr-schedule.yang.¶
module: ietf-tvr-schedule
grouping schedule-lifetime:
+-- start-date-time? yang:date-and-time
+-- (end-time)?
+--:(infinite)
| +-- no-end-time? empty
+--:(duration)
| +-- duration? uint32
+--:(end-date-time)
+-- end-date-time? yang:date-and-time
grouping base-schedule:
+-- recurrence? recurrence-type
+-- value-default
+-- base-schedule
+-- intervals* [start-time]
+-- start-time? yang:timeticks
+-- end-time? yang:timeticks
+-- value
grouping schedule:
+-- start-date-time? yang:date-and-time
+-- (end-time)?
| +--:(infinite)
| | +-- no-end-time? empty
| +--:(duration)
| | +-- duration? uint32
| +--:(end-date-time)
| +-- end-date-time? yang:date-and-time
+-- recurrence? recurrence-type
+-- value-default
+-- base-schedule
+-- intervals* [start-time]
+-- start-time? yang:timeticks
+-- end-time? yang:timeticks
+-- value
Module ietf-tvr-node.yang is a device model and designed to manage a single node with scheduled attributes.¶
Each node has list of interfaces, and each interface has a list of power up and down schedules.¶
Module ietf-tvr-topology.yang describes a network topology with a time-variant availability schedule.¶
The module has a list of nodes, identified by a unique "node-id". Each node has a list of links. Links are modeled as unidirectional. Link availability is described from the viewpoint of a particular source node (the transmitting node) and beginning at a particular time. Each link in the list contains the range of times during which it is available.¶
The "source-link-id" is a string and used to identify a link as viewed from the source-node. Bandwidth and delay are predicted link attributes. Delay is the link propagation time and does not include any queuing delays.¶
The following figure shows the tree diagram of the TVR Node scheduling.¶
module: ietf-tvr-node
+--rw node-schedule
+--rw router-id? yang:dotted-quad
+--rw power-schedule* [start-date-time]
| +--rw start-date-time yang:date-and-time
| +--rw (end-time)?
| | +--:(infinite)
| | | +--rw no-end-time? empty
| | +--:(duration)
| | | +--rw duration? uint32
| | +--:(end-date-time)
| | +--rw end-date-time? yang:date-and-time
| +--rw recurrence? recurrence-type
| +--rw value-default
| | +--rw default-power? boolean
| +--rw base-schedule
| +--rw intervals* [start-time]
| +--rw start-time yang:timeticks
| +--rw end-time? yang:timeticks
| +--rw value
| +--rw power? boolean
+--rw interface-schedule
+--rw interfaces* [name]
+--rw name string
+--rw up-down-schedule* [start-date-time]
+--rw start-date-time yang:date-and-time
+--rw (end-time)?
| +--:(infinite)
| | +--rw no-end-time? empty
| +--:(duration)
| | +--rw duration? uint32
| +--:(end-date-time)
| +--rw end-date-time? yang:date-and-time
+--rw recurrence? recurrence-type
+--rw value-default
| +--rw default-available? boolean
+--rw base-schedule
+--rw intervals* [start-time]
+--rw start-time yang:timeticks
+--rw end-time? yang:timeticks
+--rw value
+--rw available? boolean
¶
The following figure shows the tree diagram of the TVR Topology scheduling.¶
module: ietf-tvr-topology
+--rw topology-schedule
+--rw nodes* [node-id]
| +--rw node-id inet:uri
| +--rw available* [start-date-time]
| +--rw start-date-time yang:date-and-time
| +--rw (end-time)?
| | +--:(infinite)
| | | +--rw no-end-time? empty
| | +--:(duration)
| | | +--rw duration? uint32
| | +--:(end-date-time)
| | +--rw end-date-time? yang:date-and-time
| +--rw recurrence? recurrence-type
| +--rw value-default
| | +--rw default-node-available? boolean
| +--rw base-schedule
| +--rw intervals* [start-time]
| +--rw start-time yang:timeticks
| +--rw end-time? yang:timeticks
| +--rw value
| +--rw node-available? boolean
+--rw links* [source-node source-link-id]
+--rw source-node inet:uri
+--rw destination-node? inet:uri
+--rw source-link-id string
+--rw available* [start-date-time]
+--rw start-date-time yang:date-and-time
+--rw (end-time)?
| +--:(infinite)
| | +--rw no-end-time? empty
| +--:(duration)
| | +--rw duration? uint32
| +--:(end-date-time)
| +--rw end-date-time? yang:date-and-time
+--rw recurrence? recurrence-type
+--rw value-default
+--rw base-schedule
| +--rw intervals* [start-time]
| +--rw start-time yang:timeticks
| +--rw end-time? yang:timeticks
| +--rw value
+--rw bandwidth
| +--rw recurrence? recurrence-type
| +--rw value-default
| | +--rw default-bandwidth? te-types:te-bandwidth
| +--rw base-schedule
| +--rw intervals* [start-time]
| +--rw start-time yang:timeticks
| +--rw end-time? yang:timeticks
| +--rw value
| +--rw bandwidth? te-types:te-bandwidth
+--rw delay
+--rw recurrence? recurrence-type
+--rw value-default
| +--rw default-delay? uint32
+--rw base-schedule
+--rw intervals* [start-time]
+--rw start-time yang:timeticks
+--rw end-time? yang:timeticks
+--rw value
+--rw delay? uint32
¶
<CODE BEGINS> file "ietf-tvr-schedule@2023-10-11.yang"
module ietf-tvr-schedule {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-tvr-schedule";
prefix tvr-schd;
import ietf-yang-types {
prefix "yang";
reference
"RFC 6991: Common YANG Data Types";
}
organization
"IETF TVR - Time Variant Routing Working Group";
contact
"WG Web: <http://datatracker.ietf.org/wg/tvr>
WG List: <mailto:tvr@ietf.org>
Author: Yingzhen Qu
<mailto:yingzhen.ietf@gmail.com>
Author: Acee Lindem
<mailto:acee.ietf@gmail.com>
Author: Marc Blanchet
<mailto:marc.blanchet@viagenie.ca>
Author: Eric Kinzie
<mailto:ekinzie@labn.net>
Author: Don Fedyk
<mailto:dfedyk@labn.net>";
description
"The YANG module contains common YANG definitions for
time-variant schedule.
This YANG model conforms to the Network Management
Datastore Architecture (NMDA) as described in RFC 8342.
Copyright (c) 2023 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 Revised 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 XXXX
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
for full legal notices.
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 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.";
reference
"RFC XXXX: YANG Data Model for Scheduled Attributes";
revision 2023-10-11 {
description
"Initial Version";
reference
"RFC XXXX: YANG Data Model for Scheduled Attributes.";
}
typedef recurrence-type {
type enumeration {
enum once {
description
"Repeat the scheduled action or attribute modificaton
only once";
}
enum hourly {
description
"Repeat the scheduled action or attribute modificaiton
once per hour.";
}
enum daily {
description
"Repeat the scheduled action or attribute modificaiton
once per day.";
}
enum weekly {
description
"Repeat the scheduled action or attribute modificaiton
once per week.";
}
enum monthly {
description
"Repeat the scheduled action or attribute modificaiton
once per week.";
}
enum yearly {
description
"Repeat the scheduled action or attribute modificaiton
once per year.";
}
}
description
"Types of recurrence";
}
grouping schedule-lifetime {
description
"Schedule lifetime specification.";
leaf start-date-time {
type yang:date-and-time;
description
"Start time of the schedule.";
}
choice end-time {
default "infinite";
description
"End-time setting.";
case infinite {
leaf no-end-time {
type empty;
description
"Indicates schedule lifetime end-time is infinite.";
}
}
case duration {
leaf duration {
type uint32 {
range "1..2147483646";
}
units "seconds";
description
"Schedule lifetime duration, in seconds";
}
}
case end-date-time {
leaf end-date-time {
type yang:date-and-time;
description
"End time.";
}
}
}
}
grouping base-schedule {
leaf recurrence {
type recurrence-type;
default "once";
description
"Type of recurrence";
}
container value-default {
description
"Attributes default values. This container should be
augmented with one or more leafs, each of which is used
when the value is not covered by a base-schedule interval,
as well as when the schedule ends.";
}
container base-schedule {
list intervals {
key "start-time";
leaf start-time {
type yang:timeticks;
must "((../../../recurrence != 'hourly') or "
+ "(current() < 360000)) and "
+ "((../../../recurrence != 'daily') or "
+ "(current() < 8640000)) and "
+ "((../../../recurrence != 'monthly') or "
+ "(current() < 267840000)) and "
+ "((../../../recurrence != 'yearly') or "
+ "(current() < 3162240000))" {
error-message
"The start-time must not exceed the recurrence
interval";
description
"The start-time must not exceed the recurrrence
interval. For example, for a 'monthy' recurrence, the
start-time must not exceed 31 days.";
}
description
"Start time of the scheduled value within one recurrence.
The calculation of the real start time is to use
the basestarting time defined by schedule-lifetime,
recurrence, and the timeticks. For example, if a
schedule starts at 2001/1/1 8:00AM with an hourly
recurrence, and the timeticks is 180,000 (30 mins),
the start-time will be every 30 mins pass an hour
after 2001/1/1.";
}
leaf end-time {
type yang:timeticks;
must "(current() > ../start-time) and "
+ "((../../../recurrence != 'hourly') or "
+ "(current() < (../start-time + 360000))) and "
+ "((../../../recurrence != 'daily') or "
+ "(current() < (../start-time + 8640000))) and "
+ "((../../../recurrence != 'monthly') or "
+ "(current() < (../start-time + 267840000))) and "
+ "((../../../recurrence != 'yearly') or "
+ "(current() < (../start-time + 3162240000)))" {
error-message
"The end-time must be greater than the end time and
must not exceed the recurrrence interval.";
description
"The end-time must be greater than the end time and
must not exceed the recurrrence interval. For example,
for a 'daily' recurrence, the time-tick offset must
not exceed the start-time + 24 hours.";
}
description
"End time of the scheduled change. The calculation of the
end-time is the same as the start-time.";
}
container value {
description
"Attribute value(s). This container should be augmented
with attributes that apply to the current interval.";
}
description
"List of intervals for action or attribute modification.
The intervals should be contained within each recurrence.
For example, when the recurrence is set to daily, the list
of intervals should be within this daily range, e.g., the
last end-time can't be larger than 8640000 (24hours).";
}
description
"The recurring base-schedule of the action or attribute
modification";
}
description
"Grouping definition of base-schedule.";
}
grouping schedule {
uses schedule-lifetime;
uses base-schedule;
description
"Complete schedule for a action or attribute modification.";
}
}
<CODE ENDS>
¶
<CODE BEGINS> file "ietf-tvr-node@2023-10-11.yang"
module ietf-tvr-node {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-tvr-node";
prefix tvr-node;
import ietf-yang-types {
prefix "yang";
}
import ietf-tvr-schedule {
prefix "tvr-schd";
}
organization
"IETF TVR - Time Variant Routing Working Group";
contact
"WG Web: <http://datatracker.ietf.org/wg/tvr>
WG List: <mailto:tvr@ietf.org>
Author: Yingzhen Qu
<mailto:yingzhen.ietf@gmail.com>
Author: Acee Lindem
<mailto:acee.ietf@gmail.com>
Author: Marc Blanchet
<mailto:marc.blanchet@viagenie.ca>
Author: Eric Kinzie
<mailto:ekinzie@labn.net>
Author: Don Fedyk
<mailto:dfedyk@labn.net>";
description
"The YANG module defines a schedule for changing
attributes of a single node.
This YANG model conforms to the Network Management
Datastore Architecture (NMDA) as described in RFC 8342.
Copyright (c) 2023 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 Revised 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 XXXX
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
for full legal notices.
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 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.";
reference
"RFC XXXX: YANG Data Model for Scheduled Attributes";
revision 2023-10-11 {
description
"Initial Version";
reference
"RFC XXXX: YANG Data Model for Scheduled Attributes.";
}
container node-schedule {
description
"This container defined time variant attributes
for node's schedule.";
leaf router-id {
type yang:dotted-quad;
description
"A 32-bit number used to identify a router.";
}
list power-schedule {
key "start-date-time";
description
"Power schedule for the node. The node's power is
represented by a boolean value with 'true' indicating
the node is powered on and 'false' indicating the node
is powered off.";
uses tvr-schd:schedule {
augment value-default {
description
"Augment the default power state.";
leaf default-power {
type boolean;
default false;
description
"This indicates the default node power when for
time periods when no interval is defined. If
unspecified, the node is powered down by default.";
}
}
augment base-schedule/intervals/value {
description
"Augmment the scheduled power state.";
leaf power {
type boolean;
description
"Indicates whether the node is powered on.";
}
}
}
}
container interface-schedule {
description
"Container for TVR node interface attributes.";
list interfaces {
key "name";
description
"List of interface with schedules.";
leaf name {
type string;
description
"Name of the interface.
If used with the ietf-interfaces module, the name should
match the name of the interface.";
}
list up-down-schedule {
key "start-date-time";
description
"Scheduled times that the interface is up. This is to
work with the leaf 'enabled' for the configured state
of the interface.";
uses tvr-schd:schedule {
augment value-default {
description
"Augment default interface state.";
leaf default-available {
type boolean;
default false;
description
"By default, the link is not available.";
}
}
augment base-schedule/intervals/value {
description
"Augment scheduled interface state.";
leaf availble {
type boolean;
description
"Link availability.";
}
}
}
}
}
}
}
}
<CODE ENDS>
¶
<CODE BEGINS> file "ietf-tvr-topology@2023-10-11.yang"
module ietf-tvr-topology {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-tvr-topology";
prefix tvr-topo;
import ietf-inet-types {
prefix inet;
reference
"RFC 6991: Common YANG Data Types";
}
import ietf-te-types {
prefix te-types;
}
import ietf-tvr-schedule {
prefix "tvr-schd";
}
organization
"IETF Time-Variant Routing Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/tvr/>
WG List: <mailto:tvr@ietf.org>
Author: Eric Kinzie
<mailto:ekinzie@labn.net>
Author: Don Fedyk
<mailto:dfedyk@labn.net>
Author: Yingzhen Qu
<mailto:yingzhen.ietf@gmail.com>
Author: Acee Lindem
<mailto:acee.ietf@gmail.com>
Author: Marc Blanchet
<mailto:marc.blanchet@viagenie.ca>";
description
"This YANG module contains YANG definitions for describing
network topology with an time-variant availability schedule.
Copyright (c) 2023 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 Revised 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 XXXX
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
for full legal notices.
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 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.";
revision 2023-10-11 {
description
"Initial revision";
reference
"RFC XXXX: YANG Data Model for Scheduled Attributes";
}
container topology-schedule {
description
"Network topology schedules.";
list nodes {
key "node-id";
description
"List of nodes with schedules.";
leaf node-id {
type inet:uri;
description
"Identifier for a node, uniquely identifies a node. This
may be the same as the node-id defined in the ietf-network
module defined in RFC 8345.";
}
list available {
key "start-date-time";
description
"The time at which this node becomes available.";
uses tvr-schd:schedule {
augment value-default {
description
"Augment default node availability.";
leaf default-node-available {
type boolean;
default false;
description
"By default, the node is powered off.";
}
}
augment base-schedule/intervals/value {
description
"Augment scheduled node availability.";
leaf node-available {
type boolean;
description
"Node availability.";
}
}
}
}
}
list links {
key "source-node source-link-id";
description
"List of links.";
leaf source-node {
type inet:uri;
description
"A name refers to the source node of the link.";
}
leaf destination-node {
type inet:uri;
description
"A name refers to the destination node of the link.";
}
leaf source-link-id {
type string;
description
"A name refers to the link of the source node.";
}
list available {
key "start-date-time";
description
"The time at which this link becomes available.";
uses tvr-schd:schedule;
container bandwidth {
description
"Scheduled link bandwidth.
If the value measured by the system is less than this
value, the system value is used. If the value measured
by the system is greater than this value the predicted
value SHOULD be used.";
uses tvr-schd:base-schedule {
augment value-default {
description
"Augment default interface bandwidth.";
leaf default-bandwidth {
type te-types:te-bandwidth;
default "0";
description
"The default link capacity specified in a
generic format.";
}
}
augment base-schedule/intervals/value {
description
"Augment scheduled interface bandwidth.";
leaf bandwidth {
type te-types:te-bandwidth;
description
"The predicted link capacity specified in a
generic format.";
}
}
}
}
container delay {
description
"The one-way delay or latency in microseconds. If the
value measured by the system is less than this value
the predicted value SHOULD be used.";
uses tvr-schd:base-schedule {
augment value-default {
description
"Augment default delay.";
leaf default-delay {
type uint32 {
range "0..16777215";
}
description
"The default link capacity specified in a
generic format.";
}
}
augment base-schedule/intervals/value {
description
"Augment scheduled delay.";
leaf delay {
type uint32 {
range "0..16777215";
}
description
"The predicted link delay specified in a
generic format.";
}
}
}
}
}
}
}
}
<CODE ENDS>
¶
The YANG modules specified in this document define a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446].¶
The NETCONF access control model [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a pre-configured subset of all available NETCONF or RESTCONF protocol operations and content.¶
There are a number of data nodes defined in ietf-tvr-node.yang module and ietf-tvr-topology.yang that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. There are the subtrees and data nodes and their sensitivity/vulnerability:¶
Some of the readable data nodes in the ietf-tvr-node.yang module and ietf-tvr-topolgy.yang module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes.¶
This document registers a URI in the IETF XML registry [RFC3688]. Following the format in [RFC3688], the following registration is requested to be made:¶
URI: urn:ietf:params:xml:ns:yang:ietf-tvr-schedule Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace.¶
URI: urn:ietf:params:xml:ns:yang:ietf-tvr-node Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace.¶
URI: urn:ietf:params:xml:ns:yang:ietf-tvr-topology Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace.¶
This document registers a YANG module in the YANG Module Names registry [RFC6020].¶
name: ietf-tvr-schedule namespace: urn:ietf:params:xml:ns:yang:ietf-tvr-schedule prefix: tvr-schd reference: RFC XXXX¶
name: ietf-tvr-node namespace: urn:ietf:params:xml:ns:yang:ietf-tvr-node prefix: tvr-node reference: RFC XXXX¶
name: ietf-tvr-topology namespace: urn:ietf:params:xml:ns:yang:ietf-tvr-topology prefix: tvr-topo reference: RFC XXXX¶
The YANG model was developed using the suite of YANG tools written and maintained by numerous authors.¶
In OSPF (Open Shortest Path First), the interface cost is a metric used to determine the preference or desirability of a particular link or interface. By default, the OSPF interface cost is calculated based on the bandwidth of the interface, and it is also configurable.¶
This example demonstrates how an OSPF interface can be extended with a cost that changes with a schedule.¶
module example-tvr-ospf-schedule {
yang-version 1.1;
namespace "http://example.com/ns/:example-tvr-ospf-schedule";
prefix example-ospf-schedule;
import ietf-routing {
prefix "rt";
reference
"RFC 8349: A YANG Data Model for Routing
Management (NMDA Version)";
}
import ietf-ospf {
prefix "ospf";
reference
"RFC 9129: A YANG Data Model for OSPF Protocol";
}
import ietf-tvr-schedule {
prefix "tvr-schd";
}
augment "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol/ospf:ospf/ospf:areas/ospf:area/"
+ "ospf:interfaces/ospf:interface" {
list scheduled-cost {
key "start-date-time";
description
"Augment OSPF interface with a scheduled interface cost.";
uses tvr-schd:schedule {
augment base-schedule/intervals/value {
leaf cost {
type uint32;
description
"interface cost";
}
}
}
}
}
}
¶
In this configuration example, a node's power is scheduled between 2023/8/12 0:00 UTC to the end of 2023/08/13 with a daily schedule. In each day, the node is scheduled to be off between 1:00 to 5:00 and 20:00 to 23:00. The two intervals and the corresponding value are defined, the "value-default" is to define the value that's not covered by the intervals.¶
THe following figure shows the intended power schedule.¶
1 0 1 0 1 0 1 0 1 +-|----|---------------|---|-+-|----|---------------|---|-+ 0 1 5 20 23 0 1 5 20 23 24 | 2023/08/12 | 2023/08/13 |¶
The following XML demonstrate the configuration.¶
<?xml version='1.0' encoding='UTF-8'?>
<node-schedule xmlns="urn:ietf:params:xml:ns:yang:ietf-tvr-node">
<router-id>192.168.0.1</router-id>
<power-schedule xmlns="urn:ietf:params:xml:ns:yang:
ietf-tvr-node">
<start-date-time>2023-08-12T00:00:00.00Z</start-date-time>
<end-date-time>2023-08-13T24:00:00.00Z</end-date-time>
<recurrence>daily</recurrence>
<value-default>
<default-power>false</default-power>
</value-default>
<base-schedule>
<intervals>
<start-time>360000</start-time>
<end-time>1800000</end-time>
<value>
<power>true</power>
</value>
</intervals>
<intervals>
<start-time>7200000</start-time>
<end-time>8280000</end-time>
<value>
<power>true</power>
</value>
</intervals>
</base-schedule>
</power-schedule>
</node-schedule>
¶