< draft-sambo-netmod-yang-fsm-04.txt   draft-sambo-netmod-yang-fsm-05.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: April 25, 2019 G. Fioccola Expires: November 22, 2019 G. Fioccola
Huawei Technologies Huawei Technologies
F. Cugini F. Cugini
CNIT CNIT
H. Song H. Song
T. Zhou T. Zhou
Huawei Huawei
October 22, 2018 May 21, 2019
YANG model for finite state machine YANG model for finite state machine
draft-sambo-netmod-yang-fsm-04 draft-sambo-netmod-yang-fsm-05
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 1, line 39 skipping to change at page 1, line 39
operational needs emerging from heterogeneous use cases. This operational needs emerging from heterogeneous use cases. This
document proposes YANG models to describe events, operations, and document proposes YANG models to describe events, operations, and
finite state machine of YANG-defined network elements. The proposed finite state machine of YANG-defined network elements. The proposed
models can be applied in several use cases: i) in the context of models can be applied in several use cases: i) in the context of
optical networks to pre-instruct data plane devices (e.g., an optical optical networks to pre-instruct data plane devices (e.g., an optical
transponder) on the actions to be performed (e.g., code adaptation) transponder) on the actions to be performed (e.g., code adaptation)
in case some events, such as physical layer degradations, occur; ii) in case some events, such as physical layer degradations, occur; ii)
in general data networks, network telemetry applications can define in general data networks, network telemetry applications can define
and embed custom data probes into data plane devices. A probe in and embed custom data probes into data plane devices. A probe in
many cases can be modeled as an FSM; iii) the monitoring of packet many cases can be modeled as an FSM; iii) the monitoring of packet
loss and delay through a network clustering approach. loss and delay through a network clustering approach; iv) for re-
routing in optical networks.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 April 25, 2019. This Internet-Draft will expire on November 22, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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 . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . . . . . . . . . 8 Telemetry . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. IP Performance Measurements on multipoint-to-multipoint 4.3. IP Performance Measurements on multipoint-to-multipoint
large Networks . . . . . . . . . . . . . . . . . . . . . 10 large Networks . . . . . . . . . . . . . . . . . . . . . 10
5. YANG for finite state machine (FSM) . . . . . . . . . . . . . 11 4.4. Re-routing in optical networks . . . . . . . . . . . . . 11
5. YANG for finite state machine (FSM) . . . . . . . . . . . . . 12
6. Implementation of the pre-programming resiliency schemes in 6. Implementation of the pre-programming resiliency schemes in
EONs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 EONs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. YANG model for FSM - Tree . . . . . . . . . . . . . . . . 15 7.1. YANG model for FSM - Tree . . . . . . . . . . . . . . . . 16
7.2. YANG model for FSM - Code . . . . . . . . . . . . . . . . 16 7.2. YANG model for FSM - Code . . . . . . . . . . . . . . . . 16
7.3. Example of values for the YANG model . . . . . . . . . . 28 7.3. Example of values for the YANG model . . . . . . . . . . 29
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
9. Other Contributors . . . . . . . . . . . . . . . . . . . . . 29 9. Other Contributors . . . . . . . . . . . . . . . . . . . . . 30
10. Security Considerations . . . . . . . . . . . . . . . . . . . 30 10. Security Considerations . . . . . . . . . . . . . . . . . . . 31
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
12.1. Normative References . . . . . . . . . . . . . . . . . . 30 12.1. Normative References . . . . . . . . . . . . . . . . . . 31
12.2. Informative References . . . . . . . . . . . . . . . . . 30 12.2. Informative References . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
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 3, line 43 skipping to change at page 3, line 47
which can help applications gain unprecedented visibility to network which can help applications gain unprecedented visibility to network
data plane. Instead of providing raw data, network devices can be data plane. Instead of providing raw data, network devices can be
configured to filter and process data directly on the data plane and configured to filter and process data directly on the data plane and
only hand preprocessed data to the collector, in order to save data only hand preprocessed data to the collector, in order to save data
bandwidth and reduce reaction delay ([I-D.song-opsawg-dnp4iq]) . Such bandwidth and reduce reaction delay ([I-D.song-opsawg-dnp4iq]) . Such
configurations can be programed as custom probes and dynamically configurations can be programed as custom probes and dynamically
deployed into data plane devices. A probe in many cases can be deployed into data plane devices. A probe in many cases can be
modeled as an FSM. Another use case is the monitoring of packet loss modeled as an FSM. Another use case is the monitoring of packet loss
and delay through a network clustering approach: in this case, each and delay through a network clustering approach: in this case, each
FSM state is determined by a specific subdivision of the network in FSM state is determined by a specific subdivision of the network in
Clusters ([I-D.fioccola-ippm-multipoint-alt-mark]). Clusters ([I-D.ietf-ippm-multipoint-alt-mark]). Finally, a use case
is related to enable automatic local reconfiguration of a backup
route in optical networks.
2. Conventions used in this document 2. Conventions used in this document
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 [RFC2119]. document are to be interpreted as described in RFC2119 [RFC2119].
3. Terminology 3. Terminology
ABNO: Application-Based Network Operations ABNO: Application-Based Network Operations
skipping to change at page 11, line 7 skipping to change at page 11, line 7
| | | v v v | | | v v v
+--------------------------------------+ +--------------------------------------+
| Multipoint Network | | Multipoint Network |
+--------------------------------------+ +--------------------------------------+
Figure 5: Feedback mechanism on multipoint-to-multipoint large Figure 5: Feedback mechanism on multipoint-to-multipoint large
Networks Networks
One of the most efficient methodology to perform packet, loss delay One of the most efficient methodology to perform packet, loss delay
and jitter measurements both in an IP and Overlay Networks is the and jitter measurements both in an IP and Overlay Networks is the
Alternate Marking method, as presented in [I-D.ietf-ippm-alt-mark] Alternate Marking method, as presented in RFC8321 [RFC8321] and
and [I-D.fioccola-ippm-multipoint-alt-mark]. [I-D.ietf-ippm-multipoint-alt-mark].
This technique can be applied to point-to-point flows but also to This technique can be applied to point-to-point flows but also to
multipoint.to-multipoint flows (see [I-D.ietf-ippm-alt-mark] and multipoint.to-multipoint flows (see RFC8321 [RFC8321] and
[I-D.fioccola-ippm-multipoint-alt-mark]). The Alternate Marking [I-D.ietf-ippm-multipoint-alt-mark]). The Alternate Marking method
method creates batches of packets by alternating the value of 1 or 2 creates batches of packets by alternating the value of 1 or 2 bits of
bits of the packet header. These batches of packets are the packet header. These batches of packets are unambiguously
unambiguously recognized over the network and the comparison of recognized over the network and the comparison of packet counters
packet counters permits the packet loss calculation. The same idea permits the packet loss calculation. The same idea can be applied
can be applied for delay measurement by selecting special packets for delay measurement by selecting special packets with a marking bit
with a marking bit dedicated for delay measurements. This method dedicated for delay measurements. This method needs two counters
needs two counters each marking period for each flow under monitor. each marking period for each flow under monitor. For this reason by
For this reason by considering n measurement points and n monitored considering n measurement points and n monitored flows, the order of
flows, the order of magnitude of the packet counters for each time magnitude of the packet counters for each time interval is n*n*2 (1
interval is n*n*2 (1 per color). per color).
Multipoint Alternate Marking, described in Multipoint Alternate Marking, described in
[I-D.fioccola-ippm-multipoint-alt-mark], aims to reduce this value [I-D.ietf-ippm-multipoint-alt-mark], aims to reduce this value and
and makes the performance monitoring more flexible in case a detailed makes the performance monitoring more flexible in case a detailed
analysis is not needed. analysis is not needed.
It is possible to monitor a Multipoint Network without examining in It is possible to monitor a Multipoint Network without examining in
depth by using the Network Clustering (subnetworks that are portions depth by using the Network Clustering (subnetworks that are portions
of the entire network that preserve the same property of the entire of the entire network that preserve the same property of the entire
network). So in case there is packet loss or the delay is too high network). So in case there is packet loss or the delay is too high
the filtering criteria could be specified more in order to perform a the filtering criteria could be specified more in order to perform a
per flow detailed analysis, as described in [I-D.ietf-ippm-alt-mark]. per flow detailed analysis, as described in RFC8321 [RFC8321].
An application of the multipoint performance monitoring can be done An application of the multipoint performance monitoring can be done
by using FSM (each state is a composition of clusters) and feedback by using FSM (each state is a composition of clusters) and feedback
mechanism where the SDN Controller is the brain of the network and mechanism where the SDN Controller is the brain of the network and
can manage flow control to the switches and routers and, in the same can manage flow control to the switches and routers and, in the same
way, can calibrate the performance measurements depending on the way, can calibrate the performance measurements depending on the
necessity. necessity.
4.4. Re-routing in optical networks
FSM can be also applied for rerouting purposes as dynamic restoration
in optical networks. In such a use case all the nodes along the
backup route of a media channel should hold a FSM indicating the
reconfigurations to be performed in case that media channel is
rerouted along the backup path. Note that resources along the backup
route are not reserved neither configured during a normal operation
of the network as instead it happens for protection.
The proposed approach aims at achieving a sort of hybrid centralized/
distributed rerouting solution applicable to all the networks
controlled with NETCONF. More specifically, the decision of the
backup route is taken centrally by the SDN controller, but it is
acted in a distributed way through FSM when a problem appears.
In particular, the transmitter, the receiver, and the ROADMs along
the backup route have installed in their agent a FSM including a "re-
routing" state, associated to a specific media channel. For the
transmitter and receiver, this state is associated to the
transmission parameters of the backup media channel: e.g., modulation
format, central frequency, FEC, and so on. Regarding the ROADMs, the
"re-routing" state is associated to the cross connections of the
backup route.
When a link failure occurs (e.g., fiber cut), the receiver reveals a
loss of light, which triggers the transition to the "re-routing"
state. Thus, the receiver can set itself to the new transmission
parameters. Moreover, similarly to the message sent over a control
channel to the transmitter in Sec. 4.1, the receiver sends a message
to the transmitter and the backup Reconfigurable Add-Drop Multiplexer
(ROADMs). The task of this message is to simply trigger a state
transition to the "re-routing" state so that each backup ROADM and
the transmitter can apply the proper reconfigurations. This way, the
SDN controller is not interrogated during the failure and the
recovery can be speeded up. After reconfigurations, the SDN
controller can be notified and the SDN controller can tear down the
primary path. Backup routes can be reprogrammed based on the network
states evolutions (e.g., link and spectrum occupancy).
5. YANG for finite state machine (FSM) 5. YANG for finite state machine (FSM)
This model defines a list of states and transitions to describe a This model defines a list of states and transitions to describe a
generic finite state machine (FSM). The related code and tree are generic finite state machine (FSM). The related code and tree are
shown in the Appendix. shown in the Appendix.
<current-state>: it defines the current state of the FSM. <current-state>: it defines the current state of the FSM.
<states>: this element defines the FSM as follows. <states>: this element defines the FSM as follows.
<state>: this list defines all the FSM states. <state>: this list defines all the FSM states.
<id>: this leaf attribute of <state> defines the <id>: this leaf attribute of <state> defines the
skipping to change at page 30, line 42 skipping to change at page 31, line 42
[RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for
Application-Based Network Operations", RFC 7491, Application-Based Network Operations", RFC 7491,
DOI 10.17487/RFC7491, March 2015, DOI 10.17487/RFC7491, March 2015,
<https://www.rfc-editor.org/info/rfc7491>. <https://www.rfc-editor.org/info/rfc7491>.
12.2. Informative References 12.2. Informative References
[I-D.brockners-inband-oam-requirements] [I-D.brockners-inband-oam-requirements]
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., Lapukhov, 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]
Fioccola, G., Cociglio, M., Sapio, A., and R. Sisto,
"Multipoint Alternate Marking method for passive and
hybrid performance monitoring", draft-fioccola-ippm-
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-multipoint-alt-mark]
Fioccola, G., Capello, A., Cociglio, M., Castaldelli, L., Fioccola, G., Cociglio, M., Sapio, A., and R. Sisto,
Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, "Multipoint Alternate Marking method for passive and
"Alternate Marking method for passive and hybrid hybrid performance monitoring", draft-ietf-ippm-
performance monitoring", draft-ietf-ippm-alt-mark-14 (work multipoint-alt-mark-01 (work in progress), March 2019.
in progress), December 2017.
[I-D.song-opsawg-dnp4iq] [I-D.song-opsawg-dnp4iq]
Song, H. and J. Gong, "Requirements for Interactive Query Song, H. and J. Gong, "Requirements for Interactive Query
with Dynamic Network Probes", draft-song-opsawg-dnp4iq-01 with Dynamic Network Probes", draft-song-opsawg-dnp4iq-01
(work in progress), June 2017. (work in progress), June 2017.
[I-D.vergara-ccamp-flexigrid-yang] [I-D.vergara-ccamp-flexigrid-yang]
Madrid, U., Perdices, D., Lopezalvarez, V., Dios, O., Madrid, U., Perdices, D., Lopezalvarez, V., Dios, O.,
King, D., Lee, Y., and G. Galimberti, "YANG data model for King, D., Lee, Y., and G. Galimberti, "YANG data model for
Flexi-Grid Optical Networks", draft-vergara-ccamp- Flexi-Grid Optical Networks", draft-vergara-ccamp-
flexigrid-yang-06 (work in progress), January 2018. flexigrid-yang-06 (work in progress), January 2018.
[I-D.zhang-ccamp-l1-topo-yang] [I-D.zhang-ccamp-l1-topo-yang]
zhenghaomian@huawei.com, z., Fan, Z., Sharma, A., and X. zhenghaomian@huawei.com, z., Fan, Z., Sharma, A., and X.
Liu, "A YANG Data Model for Optical Transport Network Liu, "A YANG Data Model for Optical Transport Network
Topology", draft-zhang-ccamp-l1-topo-yang-07 (work in Topology", draft-zhang-ccamp-l1-topo-yang-07 (work in
progress), April 2017. progress), April 2017.
[RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli,
L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi,
"Alternate-Marking Method for Passive and Hybrid
Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321,
January 2018, <https://www.rfc-editor.org/info/rfc8321>.
Authors' Addresses Authors' Addresses
Nicola Sambo Nicola Sambo
Scuola Superiore Sant'Anna Scuola Superiore Sant'Anna
Via Moruzzi 1 Via Moruzzi 1
Pisa 56124 Pisa 56124
Italy Italy
Email: nicola.sambo@sssup.it Email: nicola.sambo@sssup.it
 End of changes. 20 change blocks. 
51 lines changed or deleted 94 lines changed or added

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