< draft-sambo-netmod-yang-fsm-02.txt   draft-sambo-netmod-yang-fsm-03.txt >
NETMOD Working Group N. Sambo NETMOD Working Group N. Sambo
Internet-Draft P. Castoldi Internet-Draft P. Castoldi
Intended status: Standards Track Scuola Superiore Sant'Anna Intended status: Standards Track Scuola Superiore Sant'Anna
Expires: September 3, 2018 G. Fioccola Expires: January 3, 2019 G. Fioccola
Telecom Italia Telecom Italia
F. Cugini F. Cugini
CNIT CNIT
H. Song H. Song
T. Zhou T. Zhou
Huawei Huawei
March 2, 2018 July 2, 2018
YANG model for finite state machine YANG model for finite state machine
draft-sambo-netmod-yang-fsm-02 draft-sambo-netmod-yang-fsm-03
Abstract Abstract
Network operators and service providers are facing the challenge of Network operators and service providers are facing the challenge of
deploying systems from different vendors while looking for a trade- deploying systems from different vendors while looking for a trade-
off among transmission performance, network device reuse, and capital off among transmission performance, network device reuse, and capital
expenditure without the need of being tied to single vendor expenditure without the need of being tied to single vendor
equipment. The deployment and operation of more dynamic and equipment. The deployment and operation of more dynamic and
programmable network infrastructures can be driven by adopting model- programmable network infrastructures can be driven by adopting model-
driven and software-defined control and management paradigms. In driven and software-defined control and management paradigms. In
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on September 3, 2018. This Internet-Draft will expire on January 3, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 35 skipping to change at page 2, line 35
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
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Example of application . . . . . . . . . . . . . . . . . . . 4 4. Example of application . . . . . . . . . . . . . . . . . . . 4
4.1. Pre-programming resiliency schemes in EONs . . . . . . . 4 4.1. Pre-programming resiliency schemes in EONs . . . . . . . 4
4.2. Deploying Dynamic Probes for Programmable Network 4.2. Deploying Dynamic Probes for Programmable Network
Telemetry . . . . . . . . . . . . . . . . . . . . . . . . 7 Telemetry . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. IP Performance Measurements on multipoint-to-multipoint 4.3. IP Performance Measurements on multipoint-to-multipoint
large Networks . . . . . . . . . . . . . . . . . . . . . 9 large Networks . . . . . . . . . . . . . . . . . . . . . 10
5. YANG for finite state machine (FSM) . . . . . . . . . . . . . 10 5. YANG for finite state machine (FSM) . . . . . . . . . . . . . 11
6. Implementation of the pre-programming resiliency schemes in 6. Implementation of the pre-programming resiliency schemes in
EONs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 EONs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. YANG model for FSM - Tree . . . . . . . . . . . . . . . . 14 7.1. YANG model for FSM - Tree . . . . . . . . . . . . . . . . 15
7.2. YANG model for FSM - Code . . . . . . . . . . . . . . . . 15 7.2. YANG model for FSM - Code . . . . . . . . . . . . . . . . 16
7.3. Example of values for the YANG model . . . . . . . . . . 27 7.3. Example of values for the YANG model . . . . . . . . . . 28
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
9. Other Contributors . . . . . . . . . . . . . . . . . . . . . 28 9. Other Contributors . . . . . . . . . . . . . . . . . . . . . 29
10. Security Considerations . . . . . . . . . . . . . . . . . . . 29 10. Security Considerations . . . . . . . . . . . . . . . . . . . 30
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
12.1. Normative References . . . . . . . . . . . . . . . . . . 29 12.1. Normative References . . . . . . . . . . . . . . . . . . 30
12.2. Informative References . . . . . . . . . . . . . . . . . 29 12.2. Informative References . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
Networks are evolving toward more programmability, flexibility, and Networks are evolving toward more programmability, flexibility, and
multi-vendor interoperability. Multi-vendor interoperability can be multi-vendor interoperability. Multi-vendor interoperability can be
applied in the context of nodes, i.e. a node composed of components applied in the context of nodes, i.e. a node composed of components
provided by different vendors (named fully disaggregated white box) provided by different vendors (named fully disaggregated white box)
is assembled under the same control system. This way, operators can is assembled under the same control system. This way, operators can
optimize costs and network performance without the need of being tied optimize costs and network performance without the need of being tied
to single vendor equipment. NETCONF protocol RFC6241 [RFC6241] based to single vendor equipment. NETCONF protocol RFC6241 [RFC6241] based
skipping to change at page 5, line 18 skipping to change at page 5, line 18
connections impacted by the soft failure are generated, this connections impacted by the soft failure are generated, this
procedure may be particularly time consuming. The related workflow procedure may be particularly time consuming. The related workflow
for transponder reconfiguration is shown in Fig. 2. The proposed for transponder reconfiguration is shown in Fig. 2. The proposed
model enables an SDN controller to instruct the transponder about model enables an SDN controller to instruct the transponder about
reconfiguration of new transmission parameters values if a soft reconfiguration of new transmission parameters values if a soft
failure occurs. This can be done before the failure occurs (e.g., failure occurs. This can be done before the failure occurs (e.g.,
during the connection instantiation phase or during the connection during the connection instantiation phase or during the connection
service), so that data plane devices can promptly reconfigure service), so that data plane devices can promptly reconfigure
themselves without querying the SDN controller to trigger an on- themselves without querying the SDN controller to trigger an on-
demand recovery. This is expected to speed up the recovery process demand recovery. This is expected to speed up the recovery process
from soft failures. The related flow chart is shown in Fig. 3. from soft failures. The related flow chart is shown in Fig. 3. The
whole mechanism is based on a finite state machine where each state
is associated to a specific configuration of transmission parameters
(e.g., modulation format). The transition from a state to another
state is triggered by specific events at the physical layer such as
the bit error rate above a threshold. The transition from a state to
another state implies a set of actions, including the change of
transmission parameters (e.g., modulation format), which are actually
suitable for the current condition at the physical layer. Moreover,
since transmission and receiver must be synchronized about the
transmission settings (modulation format and so no) for a proper
transmission, another action consists of this synchronization. Thus,
when the transponder at the receiver side decides to change its
transmission parameters based on the monitored BER, the remote
transponder at the transmitter side has to do the same state
transition. In particular, the transponder at the receiver side
sends a message to the transmitter to synchronize about the
transmission parameters to be adopted. This message can be sent over
a control channel. This way both the transmitter and receiver
operates with the same transmission parameters: e.g. the format, FEC,
and so on. No central controller is involved at this stage, only a
notification can be sent to the central controller to inform it about
the successful reconfiguration.
___________ ___________ ___________ ___________
| ABNO | | OAM | | ABNO | | OAM |
|controller | ------ | Handler | |controller | ------ | Handler |
|___________| |___________| |___________| |___________|
| | | |
| | | |
| | | |
____________ | ____________ |
skipping to change at page 16, line 20 skipping to change at page 17, line 20
description "it defines the id of the transition (event)"; description "it defines the id of the transition (event)";
type uint32; type uint32;
} }
// grouping statements // grouping statements
grouping action-block { grouping action-block {
description "it defines the action to perform when a transition occurs"; description "it defines the action to perform when a transition
occurs";
leaf id { leaf id {
description "it refers to the id of the transition"; description "it refers to the id of the transition";
type transition-id-type; type transition-id-type;
} }
leaf type { leaf type {
description "it defines if the action has to be simply executed or if a conditional statement has to be checked before execution"; description "it defines if the action has to be simply executed or if
a conditional statement has to be checked before execution";
type enumeration { type enumeration {
enum "CONDITIONAL_OP" { enum "CONDITIONAL_OP" {
description "it defines the type CONDITIONAL OPERATION to check a statement before execution"; description "it defines the type CONDITIONAL OPERATION to check a
statement before execution";
} }
enum "SIMPLE_OP" { enum "SIMPLE_OP" {
description "it defines the type SIMPLE OPERATION: i.e., an operation to be directly executed; description "it defines the type SIMPLE OPERATION: i.e., an operation
to be directly executed;
} }
} }
mandatory true; mandatory true;
} }
grouping execution-top { grouping execution-top {
skipping to change at page 18, line 5 skipping to change at page 19, line 9
description description
"The statement to be evaluated before execution. "The statement to be evaluated before execution.
E.g. if a=b"; E.g. if a=b";
} }
container true { container true {
description "it is referred to the result TRUE of a conditional statement "; description "it is referred to the result TRUE of a conditional
statement";
uses execution-top; uses execution-top;
} }
container false { container false {
description "it is referred to the result FALSE of a conditional statement "; description "it is referred to the result FALSE of a conditional
statement ";
uses execution-top; uses execution-top;
} }
} }
container simple { container simple {
description "Simple execution of an action without checking any condition"; description "Simple execution of an action without checking any
condition";
when "../type = 'SIMPLE_OP'"; when "../type = 'SIMPLE_OP'";
uses execution-top; uses execution-top;
} }
} }
grouping action-top { grouping action-top {
skipping to change at page 29, line 50 skipping to change at page 30, line 50
Brockners, F., Bhandari, S., Dara, S., Pignataro, C., Brockners, F., Bhandari, S., Dara, S., Pignataro, C.,
Gredler, H., Leddy, J., Youell, S., Mozes, D., Mizrahi, Gredler, H., Leddy, J., Youell, S., Mozes, D., Mizrahi,
T., <>, P., and r. remy@barefootnetworks.com, T., <>, P., and r. remy@barefootnetworks.com,
"Requirements for In-situ OAM", draft-brockners-inband- "Requirements for In-situ OAM", draft-brockners-inband-
oam-requirements-03 (work in progress), March 2017. oam-requirements-03 (work in progress), March 2017.
[I-D.fioccola-ippm-multipoint-alt-mark] [I-D.fioccola-ippm-multipoint-alt-mark]
Fioccola, G., Cociglio, M., Sapio, A., and R. Sisto, Fioccola, G., Cociglio, M., Sapio, A., and R. Sisto,
"Multipoint Alternate Marking method for passive and "Multipoint Alternate Marking method for passive and
hybrid performance monitoring", draft-fioccola-ippm- hybrid performance monitoring", draft-fioccola-ippm-
multipoint-alt-mark-02 (work in progress), March 2018. multipoint-alt-mark-04 (work in progress), June 2018.
[I-D.ietf-i2rs-yang-network-topo] [I-D.ietf-i2rs-yang-network-topo]
Clemm, A., Medved, J., Varga, R., Bahadur, N., Clemm, A., Medved, J., Varga, R., Bahadur, N.,
Ananthakrishnan, H., and X. Liu, "A Data Model for Network Ananthakrishnan, H., and X. Liu, "A Data Model for Network
Topologies", draft-ietf-i2rs-yang-network-topo-20 (work in Topologies", draft-ietf-i2rs-yang-network-topo-20 (work in
progress), December 2017. progress), December 2017.
[I-D.ietf-ippm-alt-mark] [I-D.ietf-ippm-alt-mark]
Fioccola, G., Capello, A., Cociglio, M., Castaldelli, L., Fioccola, G., Capello, A., Cociglio, M., Castaldelli, L.,
Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi,
 End of changes. 16 change blocks. 
29 lines changed or deleted 58 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/