One document matched: draft-pentikousis-nmrg-andr-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC7426 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7426.xml">
<!ENTITY RFC7491 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7491.xml">
<!ENTITY RFC7498 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7498.xml">
<!ENTITY ANDG SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.irtf-nmrg-autonomic-network-definitions.xml">
<!ENTITY ANGaps SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.irtf-nmrg-an-gap-analysis.xml">
<!ENTITY ANCP SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.behringer-autonomic-control-plane.xml">
<!ENTITY I2RSProb SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-problem-statement.xml">
<!ENTITY SUPA SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.pentikousis-supa-mapping.xml">
<!ENTITY RFC5812 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5812.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-pentikousis-nmrg-andr-02">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="Autonomic Networking Definitions">Autonomic Networking Definitions Revisited</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<author fullname="Kostas Pentikousis" initials="K.P." surname="Pentikousis">
<organization abbrev="EICT">EICT GmbH</organization>
<address>
<postal>
<street>EUREF-Campus Haus 13</street>
<street>Torgauer Strasse 12-15</street>
<city>10829 Berlin</city>
<country>Germany</country>
</postal>
<email>k.pentikousis@eict.de</email>
</address>
</author>
<author fullname="Manolis Sifalakis" initials="M.S." surname="Sifalakis">
<organization>University of Basel</organization>
<address>
<postal>
<street>Bernoullistrasse 16</street>
<city>4056 Basel</city>
<country>Switzerland</country>
</postal>
<email>sifalakis.manos@unibas.ch</email>
</address>
</author>
<author fullname="Jeferson Campos Nobre" initials="J.C." surname="Nobre">
<organization>Federal University of Rio Grande do Sul</organization>
<address>
<postal>
<street>Institute of Informatics</street>
<city>Porto Alegre</city>
<country>Brazil</country>
</postal>
<email>jcnobre@inf.ufrgs.br</email>
</address>
</author>
<date year="2015" />
<area>IRTF</area>
<workgroup>NMRG</workgroup>
<keyword>Autonomic networking</keyword>
<abstract>
<t>This document revisits the autonomic networking terminology established in peer-reviewed literature, aiming to contribute to the ongoing discussion in the IRTF NMRG about how to move forward with standardizing various autonomic networking aspects.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The IRTF Network Management Research Group (NMRG) has been working on a set of definitions for autonomic networking. Defining and agreeing on autonomic networking terminology is not an easy task as discussed in <xref target="TAN" />. In general, autonomic operation is associated with a range of properties, such as self-configuration, self-healing, self-optimization, and self-protection <xref target="ACDawn" />. It is worth pointing out that although there is some implicit consensus within the autonomic computing community on the key properties/attributes of an autonomic system, in the autonomic networking community this is not necessarily the case. In the past, the common ground between different projects and different contexts of operation was the presence of self-* properties, without converging to a minimum set or different levels of autonomic behavior, or where this behavior needs to be manifested.</t>
<section title="Motivation">
<t>Behringer et al. <xref target="I-D.irtf-nmrg-autonomic-network-definitions" /> describe a set of design goals and non-goals for autonomic networking and introduce a model reference architecture in the context of future IETF standardization <xref target="I-D.behringer-autonomic-control-plane" />.</t>
<t>Prior to this effort at NMRG, autonomic networking has been the focus of several research projects. For example, Bouabene et al. <xref target="ANA" /> detail an autonomic network architecture (ANA). Nguengang et al. <xref target="UMFSpec" /> propose a unified management framework (UMF) which has autonomic properties and functions at its core. Chaparadza et al. <xref target="SelfFI" /> introduce an elegant and "standardizable" [sic] generic autonomic networking architecture (GANA) which they propose to be adopted as a reference model. GANA was indeed further elaborated under the auspices of ETSI as a group specification <xref target="GANA" />.</t>
<t>Jennings et al. <xref target="TAM07" /> discuss the challenges one must deal with when applying autonomic principles to network management. This includes translation from business rules to resources/services to be provided, contextual changes in the network, adaptation of the management control loops, and verification of dynamic models for machine learning purposes. Samaan and Karmouch <xref target="SK09" /> analyze the requirements and the main contributions for the building blocks of autonomic network management systems, describe a classification methodology which compares previously proposed architectures, suggest a reference framework, and point to a set of research challenges.</t>
<t>This list of earlier work in only indicative of the breadth of research in this area over the last decade. However, standardization remains an open question and deployment has been limited to specific mechanisms only <xref target="I-D.irtf-nmrg-an-gap-analysis" />.</t>
</section>
<section title="Scope">
<t>We concur with Behringer et al. <xref target="I-D.irtf-nmrg-autonomic-network-definitions" /> that for most of the work in IETF it suffices to define autonomic behaviour at the node level. However, recent standardization efforts in the IETF, such as, for example, I2RS <xref target="I-D.ietf-i2rs-problem-statement" />, SFC <xref target="RFC7498" />, ABNO <xref target="RFC7491" />, SUPA <xref target="I-D.pentikousis-supa-mapping" />, and LIME to name a few, and new IRTF research groups such as SDNRG and NFVRG, indicate that NMRG should perhaps dig a bit deeper into the definitions for autonomic networking that will be of tangible benefit to the researcher and practitioner communities alike. In particular, one could reconsider the aspects of defining node-level autonomicity only.</t>
<t>This document revisits the autonomic networking definitions proposed earlier in the peer-reviewed literature <xref target="defs" />, and relates them with recent developments aiming to assist in the definition of a coherent terminology in this emerging area of standardization at the IETF.</t>
</section>
</section>
<section title="Definitions" anchor="defs">
<t>After some thorough analysis and discussion, Schmid et al. <xref target="TAN" /> put forward the following definition, which captures in a concrete and concise manner the essence of autonomicity:
<list style="hanging">
<t>An Autonomic System is a system that operates and serves its purpose by managing its own self without external intervention even in case of environmental changes.</t>
</list>
Note that the authors explicitly define autonomicity at the system level, not at the node level. They go on to list the minimum set of properties that an autonomic system should possess. Namely, an autonomic system is
<list style="symbols">
<t>automatic, i.e. it can "self-control its internal functions and operations"</t>
<t>adaptive, i.e. it can change its "configuration, state and functions", and</t>
<t>aware, i.e. it can "monitor its operational context".</t>
</list></t>
<t>In principle, an autonomic system could wholly replaces a non-autonomic one. In practice, however, real-world deployments will include legacy network elements and services as well as new autonomic ones.</t>
<t>A salient paper in the autonomic networking area is <xref target="FOCALE" />, in which Strassner et al. lay the foundation for an autonomic network architecture. We will not delve into the details of FOCALE, but we do note that the authors define three types of managed components according to their autonomic capabilities. In the remainder of this document we consider that FOCALE "components" equate to network resources as defined in <xref target="RFC7426" />, i.e. each network resource is a "physical or virtual component available within a system", and expand these definitions further.</t>
<t>In this sense, legacy equipment can be seen as autonomically unaware resources, and can only be managed using traditional mechanisms. In practice, field equipment could be upgraded to support certain autonomic features, thus becoming autonomically-aware managed network resources. This type of network element would typically require a mediation layer as suggested in <xref target="FOCALE" /> or at the very least certain system software updates. Finally, a deployment could include fully autonomically-enabled network resources. FOCALE explicitly aims to "accommodate legacy components" and foresees the deployment of an autonomic manager "that orchestrates the behaviour of other autonomic components in the system."</t>
<t><xref target="ANCL" /> illustrates a simple sketch of an autonomic networking control loop, based on Fig. 2 of <xref target="FOCALE" />. In short, an autonomic manager gathers data from the managed resource(s), evaluates the current state, compares it with the desired one, and configures the managed resource as necessary. As illustrated, this simple system possess the minimum set of properties introduced above.</t>
<t><figure title="Simple sketch of an autonomic networking control loop" anchor="ANCL"> <artwork align="center"><![CDATA[
+---------------------+
(Maintenance Loop) | Actual vs. desired | Autonomic manager
+-------------->| state evaluation |
| | and decision making |
| +---------o-----------+
v |
+----------------+ | New configuration
| Data gathering | | (Adjustment Loop)
+----------------+ |
^ v
| +------------------+
+----------------o Managed resource |
+------------------+
]]></artwork></figure></t>
<t>All three types of network resources (i.e. autonomically-unaware, autonomically-aware, and autonomically-enabled) need to be managed. One viable approach is proposed by Nguengang et al. <xref target="UMFSpec" /> who describe an architecture based on the definition of two types of management systems depending on the capacity of the underlying nodes, namely an Enhanced Legacy Management System (ELMS) or a future management system. In this context, it is worth considering the approaches taken in other disciplines. For example, in aviation, auto-navigation systems solve this challenge by means of distributed consensus among an odd-number of controllers/managers that independently carry out the tasks of data gathering and state evaluation, and then make an election for each decision. On the other hand, biologically-inspired systems have emergent coordination (of managers) following principles such as entropy or mass action.</t>
<t>Finally, autonomic properties are highly desirable in the context of new mobile architectures. For example, Barth and Kuehn <xref target="SON4G" /> discuss the need for self-* properties in the context of small cell deployments in 3GPP 4G/LTE, while Hamalainen et al. <xref target="LTESON" /> provide a comprehensive guide and handy references to the efforts in 3GPP along these lines.</t>
</section>
<section title="Operational Considerations and Outlook">
<t>This section briefly describes emerging operational considerations that in the authors' view should be taken into account as we move forward with autonomic networking standardization in the IETF and IRTF context.</t>
<section title="New Deployment Models">
<t>Strassner et al. <xref target="FOCALE" /> highlight that an important goal of autonomics is "making the life of the user easier by changing the focus from a computer-centric to a task-centric model". Deployment of new network technologies is typically a time-consuming, labour-intensive and cumbersome task. In the past, we have seen that if the newly designed infrastructure cannot be managed satisfactorily, adverse results such as service launch delays may be inevitable. As we move forward with new deployment models which are oriented towards softwarized and cloudified network functions, autonomic networking principles may prove invaluable.</t>
<t>As per <xref target="TAN" />, autonomic systems are by design programmable, which bodes well with the emerging deployment models which emphasize agility and shorter technology introduction cycles. We argue that autonomic networking definitions, goals and gap analysis within the context of IETF standardization should take this more into consideration. Further, recent initiatives such as SUPA <xref target="I-D.pentikousis-supa-mapping" /> point towards infrastructures which are managed through intent (generic policies), for instance, as opposed to network element specific configuration.</t>
</section>
<section title="Programmable Network Elements and Functions">
<t>Although the development of models such as FoRCES <xref target="RFC5812"/> coincided with the core of the above-mentioned autonomic networking research literature, by and large, the two areas did not cross-pollinate. It appears that as SDN and NFV principles reach a wider audience of researchers and practitioners, fully programmable network elements and functions could be further introduced in autonomic networking architectures. Indeed, moving towards a "task-centric model" relates well with other efforts in IETF such as SFC <xref target="RFC7498" /></t>
</section>
<section title="Autonomic Planes">
<t>Recent work at the SDNRG <xref target="RFC7426" /> highlighted the need for the wider SDN community to think in terms of control, management, and operational planes comprehensiveness and complementarity. As we have seen above, earlier work in autonomic networking has been primarily focusing on management aspects (cf. <xref target="UMFSpec" />), while recent work in NMRG is focusing on standardizing an autonomic networking control plane <xref target="I-D.behringer-autonomic-control-plane" />.</t>
<t>For an autonomic plane, there is the challenge on "which functionality to place where". For example, one could consider an architecture in which all three planes have autonomic features. Alternatively, one could adopt a knowledge plane approach <xref target="KP2003" /> establishing a separate, virtual/logical plane. A way forward could be to consider autonomics in NMRG in the context of programmable networks and through a more comprehensive manner.</t>
</section>
<section title="DevOps">
<t>John et al. <xref target="NSC" /> elaborate on the concept of continuous network service delivery. In this context, the authors argue for the need of programmable observation points which could be inserted in a dynamic service chain on demand. They expect that future service provider DevOps would require new management technologies "based on the experience from data centers" thus "addressing the challenges of dynamic service chaining". This bodes well with the model illustrated in <xref target="ANCL" /> and we could expect more results in this direction in the future.</t>
</section>
<section anchor="monitoring" title="Autonomic Monitoring">
<t>Network monitoring is related to the mechanisms employed to perform measurements and collect the respective results. These mechanisms are some of the most important tools employed by network administrators. Monitoring results encompass metrics such as delay (one-way or round-trip), jitter, throughput, packet loss, protocol/application usage, among others. Results can be used in different contexts, such as pre-deployment validation and measurement of in-band live network performance characteristics, and by several applications, such as intrusion detection and lawful interception.</t>
<t>Traditional (i.e., non-autonomic) monitoring mechanisms usually rely on the predetermined production of measurements results. Thus, such mechanisms are not able to dynamically adapt to different operational conditions during runtime. On the other hand, autonomic monitoring mechanisms are able to adjust themselves in order to optimize their operation. This can be done using several techniques, such as reinforcement learning and neural networks.</t>
<t>Several classifications have been proposed regarding autonomic monitoring. Samaan and Karmouch <xref target="SK09" /> discuss a classification methodology for autonomic monitoring methods in the context of an analysis of current and future research directions of autonomic network management. The authors provide a classification of autonomic monitoring approaches considering the following classes: active versus passive monitoring and distributed versus centralized monitoring. The authors also comment on monitoring granularity (measurements can be performed at the byte-, packet-, flow- or aggregated-traffic levels); monitoring timing (fixed time, event-based, and on-demand); and monitoring programmability (levels on what the monitoring mechanism itself can dynamically modify with respect to its operation).</t>
<t>In the following we provide a set of literature pointers to monitoring systems which exhibit autonomic features. Note that such mechanisms exhibit different levels of autonomic monitoring functionality and employ different techniques to support this functionality.</t>
<t>Massie et al. <xref target="MCC04" /> proposed Ganglia, a scalable, distributed system monitor tool for high-performance computing systems such as clusters and grids. This system is based on a hierarchical design targeted at federations of clusters and it relies on a multicast-based listen/announce protocol to monitor state within network nodes. Using a set of programmable interfaces, Ganglia follows a passive distributed monitoring approach where monitoring programmability is left to the applications.</t>
<t>Song et al. <xref target="SQZ06" /> proposed NetQuest, a centralized monitoring control of active measurement mechanisms with self-programmability features. NetQuest models the selection of monitoring functionalities and uses Bayesian experimental design concepts to define the solution parameters.</t>
<t>Duarte et al. <xref target="DNGT11" /> proposed ManP2P-ng, a system focused in materializing distributed self-healing features through the use of P2P management overlays and high-level descriptions called workplans. Workplans are used to set up the self-healing parameters regarding managed devices and management peers. The self-healing service is composed of independent monitoring and healing services.</t>
<t>Sekar et al. <xref target="SRWZKA08" /> proposed CSAMP, a centralized optimization engine for system-wide flow monitoring. The main features of CSAMP are the use of traffic information to steer flow sampling and hash-based packet selection through a centralized engine for the distribution of measurement responsibilities across routers.</t>
<t>Pietro et al. <xref target="PHCN10" /> proposed DECON, a decentralized coordination system aimed at assigning passive monitoring probes. DECON uses traffic information from probes seeing a particular ow to decide which one shoud do the actual monitoring. After that, messages are sent back to probes communicating the decision.</t>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>This document would not have been possible without the stimulating discussion during the NMRG meeting at IETF 90 in Toronto. Many thanks to all participants.</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This document does not propose a new network architecture or protocol and as such does not have any impact on the security of the Internet.</t>
<t>Autonomic networking introduces a range of opportunities for formal verification techniques which could increase trustworthiness, although this is clearly beyond the scope of this first version of this document. Interested readers should consult <xref target="ACSec" /> for an early exploration of the issues at hand in the context of autonomic computing.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Informative References">
<reference anchor="TAN">
<front>
<title>Towards autonomic networks</title>
<author><organization>Schmid, S., Sifalakis, M., and D. Hutchison</organization></author>
<date year="2006" />
</front>
<seriesInfo name="Proc. Autonomic Networking, LNCS 4195, pp. 1-11" value="Springer"></seriesInfo>
</reference>
<reference anchor="ANA">
<front>
<title>The autonomic network architecture (ANA)</title>
<author><organization>Bouabene, G., Jelger, C., Tschudin, C., Schmid, S., Keller, A., and M. May</organization></author>
<date year="2003" />
</front>
<seriesInfo name="Journal on Selected Areas in Communications, 28(1), 4-14" value="IEEE"></seriesInfo>
</reference>
<reference anchor="ACDawn">
<front>
<title>The dawning of the autonomic computing era</title>
<author><organization>Ganek, A. G., and T. A. Corbi</organization></author>
<date year="2003" />
</front>
<seriesInfo name="IBM systems Journal, 42(1), 5-18" value=""></seriesInfo>
</reference>
<reference anchor="ACSec">
<front>
<title>Security in an autonomic computing environment</title>
<author><organization>Chess, D. M., Palmer, C. C., and S. R. White</organization></author>
<date year="2003" />
</front>
<seriesInfo name="IBM systems Journal, 42(1), 107-118" value=""></seriesInfo>
</reference>
<reference anchor="FOCALE">
<front>
<title>FOCALE: A novel autonomic networking architecture</title>
<author><organization>Strassner, J., Agoulmine, N., and E. Lehtihet</organization></author>
<date month="July" year="2006" />
</front>
<seriesInfo name="Proc. Latin American Autonomic Computing Symposium (LAACS)," value="Campo Grande, Brazil"></seriesInfo>
</reference>
<reference anchor="UMFSpec">
<front>
<title>UMF Specifications, Release 1</title>
<author><organization>Nguengang, G. (ed.), et al.</organization> </author>
<date month="July" year="2011" />
</front>
<seriesInfo name="FP7-UNIVERSELF-Deliverable D2.1" value=""></seriesInfo>
</reference>
<reference anchor="SelfFI">
<front>
<title>Creating a viable Evolution Path towards Self-Managing Future Internet via a Standardizable Reference Model for Autonomic Network Engineering</title>
<author><organization>Chaparadza, R., Papavassiliou, S., et al.</organization> </author>
<date year="2009" />
</front>
<seriesInfo name="Future Internet Assembly (pp. 136-147)" value="IOS Press"></seriesInfo>
</reference>
<reference anchor="GANA">
<front>
<title>Autonomic network engineering for the self-managing Future Internet (AFI): GANA Architectural Reference Model for Autonomic Networking, Cognitive Networking and Self-Management. </title>
<author surname="ETSI GS AFI 002"/>
<date month="April" year="2013"/>
</front>
</reference>
<reference anchor="SON4G">
<front>
<title>Self-organization in 4G mobile networks: Motivation and vision</title>
<author><organization>Barth, U., and E. Kuehn</organization></author>
<date month="September" year="2010" />
</front>
<seriesInfo name="Proc. 7th International Symposium on Wireless Communication Systems (ISWCS), York, UK, pp. 731-735, " value="IEEE"></seriesInfo>
</reference>
<reference anchor="LTESON">
<front>
<title>LTE Self-Organising Networks (SON): Network Management Automation for Operational Efficiency</title>
<author><organization>Hamalainen, S., Sanneck, H., and C. Sartori</organization></author>
<date year="2012" />
</front>
<seriesInfo name="John Wiley & Sons " value=""></seriesInfo>
</reference>
<reference anchor="NSC">
<front>
<title>Research directions in network service chaining</title>
<author><organization>John, W., Pentikousis, K., et al.</organization></author>
<date month="November" year="2013" />
</front>
<seriesInfo name="Proc. SDN for Future Networks and Services (SDN4FNS), Trento, Italy" value="IEEE"></seriesInfo>
</reference>
<reference anchor="KP2003">
<front>
<title>A Knowledge Plane for the Internet</title>
<author><organization>Clark, D. D., Partridge, C. , et al.</organization></author>
<date month="August" year="2003" />
</front>
<seriesInfo name="Proc. SIGCOMM, Karlsruhe, Germany" value="ACM"></seriesInfo>
</reference>
<reference anchor="SK09">
<front>
<title>Towards Autonomic Network Management: an Analysis of Current and Future Research Directions</title>
<author><organization>Samaan, N. and A. Karmouch</organization></author>
<date year="2009" />
</front>
<seriesInfo name="Communications Surveys & Tutorials, vol. 11, no. 3, pp. 22-36" value="IEEE"></seriesInfo>
</reference>
<reference anchor="TAM07">
<front>
<title>Towards autonomic management of communications networks</title>
<author><organization>Jennings, B., van der Meer, s. et al.</organization></author>
<date year="2007" />
</front>
<seriesInfo name="Communications Magazine, vol. 45, no. 10, pp. 112-121" value="IEEE"></seriesInfo>
</reference>
<reference anchor="MCC04">
<front>
<title>The ganglia distributed monitoring system: design, implementation, and experience</title>
<author><organization>Massie, M.L. and Chun, B.N. and Culler, D.E.</organization></author>
<date year="2004" />
</front>
<seriesInfo name="Parallel Computing, vol. 30, no. 7, pp. 817-840" value="Elsevier"></seriesInfo>
</reference>
<reference anchor="PHCN10">
<front>
<title>DECON: Decentralized Coordination for Large-Scale Flow Monitoring</title>
<author><organization>di Pietro, A. and Huici, F. and Costantini, D. and Niccolini, S.</organization></author>
<date year="2010" />
</front>
<seriesInfo name="Proceedings of the IEEE Conference on Computer Communications (INFOCOM) Workshops" value="IEEE"></seriesInfo>
</reference>
<reference anchor="DNGT11">
<front>
<title>A P2P-Based Self-Healing Service for Network Maintenance</title>
<author><organization>Duarte, P. A. P. R., Nobre, J. C., Granville, L. Z., Tarouco, L. M. R.</organization></author>
<date year="2011" />
</front>
<seriesInfo name="Proceedings of the 12th IFIP/IEEE International Symposium on Integrated Network Management (IM)" value="IEEE"></seriesInfo>
</reference>
<reference anchor="SRWZKA08">
<front>
<title>CSAMP: a system for network-wide flow monitoring</title>
<author><organization>Sekar, V. and Reiter, M.K. and Willinger, W. and Zhang, H. and Kompella, R.R. and Andersen, D. G.</organization></author>
<date year="2008" />
</front>
<seriesInfo name="Proceedings of the 5th USENIX Symposium on Networked Systems Design and Implementation (NSDI)" value="USENIX"></seriesInfo>
</reference>
<reference anchor="SQZ06">
<front>
<title>NetQuest: a flexible framework for large-scale network measurement</title>
<author><organization>Song, H. H., Qiu, L., Zhang, Y. </organization></author>
<date year="2006" />
</front>
<seriesInfo name="ACM SIGMETRICS Performance Evaluation Review, Vol. 34. No. 1." value="ACM"></seriesInfo>
</reference>
<!-- Here we use entities that we defined at the beginning. -->
&RFC7426;
&RFC7491;
&RFC7498;
&RFC5812;
&ANDG;
&ANGaps;
&ANCP;
&I2RSProb;
&SUPA;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:43:34 |