< draft-mm-netconf-time-capability-08.txt   draft-mm-netconf-time-capability-09.txt >
Network Working Group T. Mizrahi Network Working Group T. Mizrahi
Internet Draft Y. Moses Internet Draft Y. Moses
Intended status: Experimental Technion, Israel Institute of Technology Intended status: Experimental Technion, Israel Institute of Technology
Expires: March 2016 September 1, 2015 Expires: April 2016 October 15, 2015
Time Capability in NETCONF Time Capability in NETCONF
draft-mm-netconf-time-capability-08.txt draft-mm-netconf-time-capability-09.txt
Abstract Abstract
This document defines a capability-based extension to the Network This document defines a capability-based extension to the Network
Configuration Protocol (NETCONF) that allows time-triggered Configuration Protocol (NETCONF) that allows time-triggered
configuration and management operations. This extension allows configuration and management operations. This extension allows
NETCONF clients to invoke configuration updates according to NETCONF clients to invoke configuration updates according to
scheduled times, and allows NETCONF servers to attach timestamps to scheduled times, and allows NETCONF servers to attach timestamps to
the data they send to NETCONF clients. the data they send to NETCONF clients.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 1, 2016. This Internet-Draft will expire on April 15, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 17 skipping to change at page 2, line 17
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
2. Conventions used in this document..............................3 2. Conventions used in this document..............................3
2.1. Key words.................................................3 2.1. Key words.................................................3
2.2. Abbreviations.............................................3 2.2. Abbreviations.............................................4
2.3. Terminology...............................................4 2.3. Terminology...............................................4
3. Using Time in NETCONF..........................................4 3. Using Time in NETCONF..........................................4
3.1. The Time Capability in a Nutshell.........................4 3.1. The Time Capability in a Nutshell.........................4
3.2. Notifications and Cancellation Messages...................6 3.2. Notifications and Cancellation Messages...................6
3.3. Synchronization Aspects...................................8 3.3. Synchronization Aspects...................................8
3.4. Scheduled Time Format.....................................9 3.4. Scheduled Time Format.....................................9
3.5. Scheduling Tolerance......................................9 3.5. Scheduling Tolerance......................................9
3.6. Near Future Scheduling vs. Far Future Scheduling.........10 3.6. Near Future Scheduling vs. Far Future Scheduling.........10
3.7. Time Interval Format.....................................12 3.7. Time Interval Format.....................................12
4. Time Capability...............................................12 4. Time Capability...............................................13
4.1. Overview.................................................12 4.1. Overview.................................................13
4.2. Dependencies.............................................13 4.2. Dependencies.............................................13
4.3. Capability Identifier....................................13 4.3. Capability Identifier....................................13
4.4. New Operations...........................................13 4.4. New Operations...........................................13
4.5. Modifications to Existing Operations.....................13 4.5. Modifications to Existing Operations.....................14
4.5.1. Affected Operations.................................13 4.5.1. Affected Operations.................................14
4.5.2. Processing Scheduled Operations.....................14 4.5.2. Processing Scheduled Operations.....................15
4.6. Interactions with Other Capabilities.....................15 4.6. Interactions with Other Capabilities.....................15
5. Examples......................................................15 5. sched-max-futures.............................................16
5.1. <scheduled-time> Example.................................15 5.1. <scheduled-time> Example.................................16
5.2. <get-time> Example.......................................16 5.2. <get-time> Example.......................................17
5.3. Error Example............................................17 5.3. Error Example............................................17
6. Security Considerations.......................................18 6. Security Considerations.......................................18
6.1. General Security Considerations..........................18 6.1. General Security Considerations..........................18
6.2. YANG Module Security Considerations......................19 6.2. YANG Module Security Considerations......................19
7. IANA Considerations...........................................19 7. IANA Considerations...........................................20
8. Acknowledgments...............................................20 8. Acknowledgments...............................................20
9. References....................................................20 9. References....................................................21
9.1. Normative References.....................................20 9.1. Normative References.....................................21
9.2. Informative References...................................21 9.2. Informative References...................................21
Appendix A. YANG Module for the Time Capability..................22 Appendix A. YANG Module for the Time Capability..................22
1. Introduction 1. Introduction
The Network Configuration Protocol (NETCONF) defined in [RFC6241] The Network Configuration Protocol (NETCONF) defined in [RFC6241]
provides mechanisms to install, manipulate, and delete the provides mechanisms to install, manipulate, and delete the
configuration of network devices. NETCONF allows clients to configure configuration of network devices. NETCONF allows clients to configure
and monitor NETCONF servers using remote procedure calls (RPC). and monitor NETCONF servers using remote procedure calls (RPC).
skipping to change at page 3, line 38 skipping to change at page 3, line 38
allows clients to determine the scheduled execution time of RPCs they allows clients to determine the scheduled execution time of RPCs they
send. It also allows a server that receives an RPC to report its send. It also allows a server that receives an RPC to report its
actual execution time to the client. actual execution time to the client.
The NETCONF time capability is intended for scheduling RPCs that The NETCONF time capability is intended for scheduling RPCs that
should be performed in the near future, allowing to coordinate should be performed in the near future, allowing to coordinate
simultaneous configuration changes, or to specify an order of simultaneous configuration changes, or to specify an order of
configuration updates. Time-of-day-based policies and far-future configuration updates. Time-of-day-based policies and far-future
scheduling, e.g., [Cond], are outside the scope of this memo. scheduling, e.g., [Cond], are outside the scope of this memo.
This memo is defined for experimental purposes, and will allow the
community to experiment with the NETCONF time capability. It is
expected that based on the lessons learned from this experience the
NETCONF working group will be able to consider whether to adopt the
time capability.
2. Conventions used in this document 2. Conventions used in this document
2.1. Key words 2.1. Key words
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2.2. Abbreviations 2.2. Abbreviations
skipping to change at page 8, line 49 skipping to change at page 8, line 49
are implemented by a combination of hardware and software. While the are implemented by a combination of hardware and software. While the
execution time of a hardware module can typically be predicted with a execution time of a hardware module can typically be predicted with a
high level of accuracy, the execution time of a software module may high level of accuracy, the execution time of a software module may
be variable and hard to predict. A configuration update would be variable and hard to predict. A configuration update would
typically require the server's software to be involved, thus typically require the server's software to be involved, thus
affecting how accurately the RPC can be scheduled. affecting how accurately the RPC can be scheduled.
Another important aspect of synchronization, is monitoring; a client Another important aspect of synchronization, is monitoring; a client
should be able to check whether a server is synchronized to a should be able to check whether a server is synchronized to a
reference time source. Typical synchronization protocols, such as the reference time source. Typical synchronization protocols, such as the
Network Time Protocol ([NTP], [RFC5907]) provide the means to verify Network Time Protocol [NTP] provide the means ([RFC5907], [RFC7317])
that a clock is synchronized to a time reference by querying its to verify that a clock is synchronized to a time reference by
Management Information Base (MIB). The get-time feature defined in querying its Management Information Base (MIB). The get-time feature
this document (see Figure 2) allows a client to obtain a rough defined in this document (see Figure 2) allows a client to obtain a
estimate of the time offset between the client's clock and the rough estimate of the time offset between the client's clock and the
server's clock. server's clock.
Since servers do not perform configuration changes instantaneously, Since servers do not perform configuration changes instantaneously,
the processing time of an RPC should not be overlooked. The scheduled the processing time of an RPC should not be overlooked. The scheduled
time always refers to the start time of the RPC, and the execution time always refers to the start time of the RPC, and the execution
time always refers to its completion time. time always refers to its completion time.
3.4. Scheduled Time Format 3.4. Scheduled Time Format
The scheduled time and execution time fields in RPC messages use a The scheduled time and execution time fields in RPC messages use a
skipping to change at page 12, line 31 skipping to change at page 12, line 31
While the date-and-time type uniquely represents a specific point in While the date-and-time type uniquely represents a specific point in
time, the time-interval type defined below can be used to represent time, the time-interval type defined below can be used to represent
the length of a time interval without specifying a specific date. the length of a time interval without specifying a specific date.
The time-interval type is defined as follows: The time-interval type is defined as follows:
typedef time-interval { typedef time-interval {
type string { type string {
pattern '\d{2}:\d{2}:\d{2}(\.\d+)?'; pattern '\d{2}:\d{2}:\d{2}(\.\d+)?';
} }
description
"Defines a time interval, up to 24 hours.
The format is specified as HH:mm:ss.f,
consisting of two digits for hours,
two digits for minutes, two digits
for seconds, and zero or more digits
representing second fractions.";
} }
Example
The sched-max-future parameter is defined (Appendix A) as a
time-interval, as follows:
leaf sched-max-future {
type time-interval;
default 00:00:15.0;
}
The default value specified for sched-max-future is 0 hours, 0
minutes, and 15 seconds.
4. Time Capability 4. Time Capability
The structure of this section is as defined in Appendix D of The structure of this section is as defined in Appendix D of
[RFC6241]. [RFC6241].
4.1. Overview 4.1. Overview
A server that supports the time capability can perform time-triggered A server that supports the time capability can perform time-triggered
operations as defined in this document. operations as defined in this document.
skipping to change at page 21, line 28 skipping to change at page 22, line 5
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, June 2011. Shell (SSH)", RFC 6242, June 2011.
[RFC6243] Bierman, A., Lengyel, B., "With-defaults Capability [RFC6243] Bierman, A., Lengyel, B., "With-defaults Capability
for NETCONF", RFC 6243, June 2011. for NETCONF", RFC 6243, June 2011.
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
Protocol (NETCONF) Access Control Model", RFC 6536, Protocol (NETCONF) Access Control Model", RFC 6536,
March 2012. March 2012.
[RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for
System Management", RFC 7317, August 2014.
[Cond] Watsen, K., "Conditional Enablement of Configuration [Cond] Watsen, K., "Conditional Enablement of Configuration
Nodes", draft-kwatsen-conditional-enablement-00 Nodes", draft-kwatsen-conditional-enablement-00
(expired), 2013. (expired), 2013.
[HotSDN] Mizrahi, T., Moses, Y., "Time-based Updates in [HotSDN] Mizrahi, T., Moses, Y., "Time-based Updates in
Software Defined Networks", the second workshop on hot Software Defined Networks", the second workshop on hot
topics in software defined networks (HotSDN), 2013. topics in software defined networks (HotSDN), 2013.
[IEEE1588] IEEE TC 9 Instrumentation and Measurement Society, [IEEE1588] IEEE TC 9 Instrumentation and Measurement Society,
"1588 IEEE Standard for a Precision Clock "1588 IEEE Standard for a Precision Clock
skipping to change at page 23, line 25 skipping to change at page 24, line 7
reference reference
"draft-mm-netconf-time-capability: "draft-mm-netconf-time-capability:
Time Capability in NETCONF"; Time Capability in NETCONF";
} }
typedef time-interval { typedef time-interval {
type string { type string {
pattern '\d{2}:\d{2}:\d{2}(\.\d+)?'; pattern '\d{2}:\d{2}:\d{2}(\.\d+)?';
} }
description description
"Defines a time interval, up to 24 hours."; "Defines a time interval, up to 24 hours.
The format is specified as HH:mm:ss.f,
consisting of two digits for hours,
two digits for minutes, two digits
for seconds, and zero or more digits
representing second fractions.";
} }
grouping scheduling-tolerance-parameters { grouping scheduling-tolerance-parameters {
leaf sched-max-future { leaf sched-max-future {
type time-interval; type time-interval;
default 00:00:15.0; default 00:00:15.0;
description description
"When the scheduled time is in the future, i.e., greater "When the scheduled time is in the future, i.e., greater
than the present time, this leaf defines the maximal than the present time, this leaf defines the maximal
difference between the scheduled time difference between the scheduled time
 End of changes. 15 change blocks. 
21 lines changed or deleted 56 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/