<?xml version="0.1"?>
<!-- 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 RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.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-tavernier-irtf-lccn-problem-statement-01" ipr='trust200902'>
  <!-- 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="LCCN problem statement">Learning Capable Communication Network (LCCN) problem statement</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->

    <author fullname="Wouter Tavernier" initials="W.T." role="editor"
            surname="Tavernier">
      <organization>Ghent University - IBBT</organization>

      <address>
        <postal>
          <street>Gaston Crommenlaan 8 bus 201</street>

          <!-- Reorder these if your country does things differently -->

          <city>Gent</city>

          <region></region>

          <code>9050</code>

          <country>Belgium</country>
        </postal>

        <phone>+32(0)9 331 49 81</phone>

        <email>wouter.tavernier@intec.ugent.be</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>
	
    <author fullname="Dimitri Papadimitriou" initials="D.P." 
            surname="Papadimitriou">
      <organization>Alcatel-Lucent Bell</organization>

      <address>
        <postal>
          <street>Copernicuslaan 50</street>

          <!-- Reorder these if your country does things differently -->

          <city>Antwerpen </city>

          <region></region>

          <code>2018</code>

          <country>Belgium</country>
        </postal>

        <phone></phone>

        <email>dimitri.papadimitriou@alcatel-lucent.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>	
	
	<author fullname="Didier Colle" initials="D.C." 
            surname="Colle">
      <organization>Ghent University - IBBT</organization>

      <address>
        <postal>
          <street>Gaston Crommenlaan 8 bus 201</street>

          <!-- Reorder these if your country does things differently -->

          <city>Gent</city>

          <region></region>

          <code>9050</code>

          <country>Belgium</country>
        </postal>

        <phone>+32(0)9 331 49 70</phone>

        <email>didier.colle@intec.ugent.be</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <date month="January" year="2011" />

    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill 
         in the current day for you. If only the current year is specified, xml2rfc will fill 
	 in the current day and month for you. If the year is not the current one, it is 
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the 
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to 
	 specify just the year. -->

    <!-- Meta-data Declarations -->

    <area>General</area>

    <workgroup>Internet Research Task Force</workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.  
	 If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

    <keyword>template</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
      <t>Operational procedures and protocols of today's communication networks typically use explicitly defined mechanisms and representations to reach the goals associated to their design. This practice results into numerous protocols having a restricted space for (self-)adaptability, flexibility, and sensitivity respective to their network context (e.g. network traffic conditions, failure conditions, etc). On the other hand, a wide spectrum of learning and optimization techniques is available such that networks could learn and optimize their behavior in the running context. This document describes the opportunities and challenges for a Learning Capable Communication Network (LCCN). </t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>As currently instantiated, the Internet hour-glass model drives a top-down approach. Current communication networks typically operate with an explicit internal representation of themselves, their network knowledge, and their global goals. Routers follow explicitly (pre-)defined behavior, persistently decide and uniformly execute. Global Internet behavior is evaluated and configuration is when the evaluation indicates that the networking systems are not accomplishing what they were intended to, or when better functionality or performance is expected.</t>
	  
	  <t>In several Internet areas, this operational model shows its limits. Inter-domain routing protocols such as BGP are increasingly impacted by topology and policy dynamics, delaying their convergence due to inherent exploration properties. Network management becomes more and more complex, as networks do not automatically take into account network traffic statistics and other dynamic properties. Several efforts have been undertaken to overcome the increasing number of issues. However, improvement of the routing system to accommodate various scales of challenges in network efficiency, further complicates its operation (<xref target='I-D.ietf-idr-bgp-issues'/>). Further patching the inter-domain routing system and equipment will result into more operational complexity. </t>
	  
	  <t>In this document, we suggest an alternative (bottom-up) approach to the Internet routing and forwarding system operation. Compared to current routed networks requiring explicit specification of expected behavior, self-adaptive systems could dynamically modify or adjust their behavior to varying network conditions in order to tune their operation, optimize their overall performance and even add functionalities through closed-loop adaptive control.</t>
	  
	  <t>We see three main drivers for the development of Learning Capable Communicatino Networks (LCCN): i) the availability of network-related data, ii) the wide range of possible learning paradigms that can be borrowed from domains such as Artificial Intelligence (AI), machine learning, and bio-inspired learning, and iii) the increased CPU capacity available at both forwarding and control plane level, allowing for background monitoring, learning and optimization in routers.</t>
	  
	  <t>The structure of this document is as follows. In <xref target="learning-opportunities"/>, we describe the opportunities for communication networks to learn how to improve their performance. The next section (<xref target="learning"/>) gives a more formal but broad definition of the concept of learning. <xref target="architecture"/> provides a first set of architectural implications of adding learning capability to communication networks. The applicability domain of LCCNs is covered in <xref target="applicability"/>, and possible research directions are described in <xref target="research"/>. Concluding remarks and future work are indicated in <xref target="conclusion"/>.</t>
    </section>
	
	<section anchor="learning-opportunities" title="Learning opportunities">
		<section anchor="traffic data" title="Availability of network data and statistics">
			<t>Hosts communicate by sending packets between each other via transit network nodes. As such, a communication network is loaded with packets corresponding to network traffic flows between given network source and destination nodes. Many techniques exist to gather statistics about the resulting traffic flows crossing routers. </t>
			
			<t><list style="symbols">
				<t>Online statistical counters measure properties of transiting traffic in a router using counters, for example the number of packets per destination prefix or used packet size distribution curves</t>
				<t>Traffic sampling: instead of counting certain traffic characteristics, unmodified traffic is captured for some time interval.  This sample is then used to derive certain characteristics, using e.g. the setting proposed in <xref target="Estan04"/>) by means of sample-and-hold technique.</t>
			</list></t>
			
			<t>Unfortunately, the resulting statistical data is rarely used to directly improve the routing and/or forwarding decision of network nodes (referring to the active self-adaptive closed control loop in <xref target="control loop"/>). However, it is clear that network operation could benefit from taking these statistics automatically into account to allow for traffic spreading and network load balancing, ordering of prefix updates in traffic-informed re-routing decisions, and so on. To a lesser extend (since the routing system is deterministically adaptive to topological and/or policy changes), this observation also applies to routing information exchanges. </t>
			
			<t>Not only the statistics of network traffic are valuable but also the behavioral aspects of the network itself possibly contain usable information for increasing the performance of the network. Statistics about node or link failures can help network recovery mechanisms to fine tune their operation based on the specific statistical context of the running network. Convergence behavior of routing protocols in the specific running context can be monitored such as to reduce the time of transient loops. In brief, the specific running conditions of communication networks possibly hide (statistical) information, which are currently (largely) unused by current Internet protocols; nevertheless, providing an opportunity to better analyze the behavior of the network behavior depending on the context it is running within. </t>
		</section>
		
		<section anchor="cpu power" title="Availability of processing capacity">
			<t>The possibility of maintaining network statistics is not only dependent on the network conditions and environment themselves, but also on the physical feasibility of monitoring and storing them over longer periods. </t>
			
			<t>Supported by Moore's law, we observe that processing power is increasing over last years, either in pure clock frequency of CPU, or in the occurrence of combinations of multiple CPU's on one chip. In combination with the high increase in line card speeds (up to 100 Gbps), the possibility of capturing useful network statistics in background seems within reach. </t>
		</section>
	</section>
	
	<section anchor="learning" title="The learning process">
		<t>Many research fields study the concept of learning from various view points. In the context of LCCNs, learning algorithms correspond to the (broad) class of algorithms that discover the relationship between system variables (i.e. input, output and hidden variables) from data samples of its environment (obtained by means of measurement/monitoring). More formally, the learning process consists of the following steps (see <xref target="learning-process" />). </t>

		<figure anchor="learning-process"> 
			<artwork><![CDATA[
                           ,--.
                          +    +
                          |`--'|
                          |KIB |<------------------+
                          +    +                   |
                           `--'                    |
                             |                     |
                             v                     |
                      +----------------+           |
             ,--.     |    Learner     |        +------+
 E          +    +    |                |       /        \
 v          |`--'|    | +------------+ |      / Hypothe- \
 e -------->|    |------> Learning   | |----->\  sis h   /
 n      |   +    +    | |  algorithm | |       \        /
 t      |    `--'     | +------------+ |        +------+
        |  Training   +----------------+          | ^
        |  data set                               | |
        |                    +--------------------+ |
        |                    v                      +
        |    ,--.     +----------------+           /  \
        |   +    +    |   Performer    |          /    \
        |   |`--'|    | +------------+ |         / test \     target
        +-->|    |------> Learned    | |-------->\      /---> function
            +    +    | |  hypothesis| |          \    /
             `--'     | +------------+ |           \  /
             Test     +----------------+            +
           data set                                 ^
              |                                     |
              +-------------------------------------+
		]]></artwork>
	 </figure>
				
			<t><list style="symbols">
				<t>Step 0: Choose training and test data sets associated to a given (sequence of) event(s) observed in the system's running environment</t>
				<t>Step 1: Training (learner): learn an hypothesis h (model), function of the input (training data set) that approximates at best output y (symbolic = classification, numeric = regression). Knowledge: use prior "knowledge" stored in Knowledge Information Base (KIB) to learn h </t>
				<t>Step 2: Testing (performer): evaluate learned model using test data set </t>
			</list></t>
				
	</section>

	<section anchor="architecture" title="Architectural implications">
			<t>The control of dynamic systems such as communications networks and routers in particular, can be explained as an interative cycle referred to as the control loop. The coming sections explain the difference of existing communications networks and routers, with the control loop of LCCNs. </t>
	
		<section anchor="control loop" title="From a pre-defined open-loop control towards a self-adaptive closed-loop control">
			<t>The configuration and operation of existing communication networks typically consist of a set of components and algorithms acting in a relatively small space of states, transitions and optimization steps. Let's take as example routers: they distribute topology and/or distance information from which they compute (e.g. shortest) routing paths. Using this information, they derive entries looked up to forward packets based on incoming packets' destination address. When a topological or distance change occurs, routing updates are timely disseminated in the network such that each router achieves a coherent full view of the new network topology and/or distances and can re-compute new routing paths taking into account this new state of the network. While these procedures might seem effective at first sight, they are mostly pre-determined and inflexible with respect to the environment they are running in.</t>
			
			<t>Indeed, routers are agnostic to traffic characteristics and to statistics of network failures. This situation occurs because these techniques have been developed in the early days of packet communication networks. At that time, computational and memory resources were scarce, and the resulting techniques needed to act sparingly with the available resources. Moreover, most of these techniques aim to automate manual procedures used to configure or operate communication networks. As such, routers forward packets based on their destination address by applying pre-determined decision rules and execution procedures. </t>
			
			<t>While many engineering disciplines, such as the automotive or bio-industry, have adopted learning techniques to improve the performance of their operational control loops, in computer networking, their application has been restricted mainly to passive applications leading to open-loop control procedures. Examples of such applications are: time series models to analyze and predict network traffic data, anomaly detection techniques to check networks for strange events, or statistical models which try to detect Shared Risk Link Groups (SRLG). Most of the applications of learning techniques are used as interesting side information in the context of network operation. They help network managers to understand and predict the behavior of their network; however few existing network operation models include this learning capability into their direct control loop. </t>
			
			<t>In this context, the overall objective is to bring the application of data mining and learning techniques one step further: towards the active integration of these techniques into the operational and control processes of communication networks. For instance, we could augment the above control paradigm with a machine learning component enabling the system and network to learn about their own behavior and environment over time, to detect and analyze problems, adapt their decision, and tune their execution using output of models in order to increase their functionality and performance. Systems with such an adaptive closed-loop control have network elements autonomously interrelated and controlled, dynamically adapting to changing environments, and learning desired behavior. These fully distributed and technology-independent systems allow: i) self-configuration and self-organization, ii) self-protection and self-healing, and iii) self-optimization. The objective is to improve the Internet control/routing and forwarding process by enabling, automating, and distributing the decision making processes involved in their operation. </t>

		<figure anchor="lccn"> 
			<artwork><![CDATA[
               +-----------+            +-----------+
 system   ==>  |  analyze  |----------->+  decide   | <==  rules
 knowledge     +-----------+            +-----------+
                     ^                        |
                     |                        v
    self-      +-----+-----+            +-----------+    
  monitoring   |  detect   |<-----------+  execute  |      self-
               +-----------+            +-----------+  configuration
                     ^                        |
                     |                        v
                  +------------------------------+
                  |      Controlled Element      |
                  +------------------------------+
			]]></artwork>
	 </figure>			
			
			<t> Using a more advanced control loop, the routing systems locally learn from network traffic, failure patterns and other context-related data observed in the network, and locally adapt their procedures to optimize their decisions depending on the running context and their internal state. The resulting self-adaptive closed-loop control is a four step cyclic process consisting of: i) a detection phase (e.g., monitor network traffic) which is about monitoring data, ii) an analysis or learning phase (e.g., build traffic models for prediction) in which the data obtained during the detection phase is analyzed and upon which models can be learned, iii) infer rules/decisions from the performed/learned analysis such that the learned model can influence the operation of the network and iv) an execution phase.  </t>
		</section>
		
		<section anchor="integration" title="The integration of learning capability">
			<t>While it is premature (and part of the research work) to detail the implications on the Internet architecture, the design of a control system incorporating learning capability would benefit from the following design principles.			
			<list style="symbols">
				<t>Adaptability: modular instead of relying on unified and monolythic approach in order to ensure gradual development (e.g. access vs core router) </t>
				<t>Segmentability: rely on relative local view rather than a network global view in order to ensure scalability, robustness, and resiliency</t>			
				<t>Sizeability: inherits distributed properties and capabilities of routing system (e.g. intra- vs inter-domain) in order to ensure organic deployment --instead of a uniform and ubiquitous plane construction</t>
			</list></t>
			
			<t>Taking these principles into account, the resulting architecture should specify: i) expected behavior of the self-adaptive closed-loop process, ii) its components, and iii) the interfaces with existing routers' components and between learning-capable routers of a network (both intra- and inter-domain). The resulting closed-loop adaptive control includes a learning component that is either an upfront step or an online process, a feedback phase, and interactions with router/network control. </t>
			
			<figure anchor="router-evolution"> 
			<artwork>
      Today                  Step 1                    Step 2
 +--------------+      +----------------+       +------------------+
 |              |      | +------------+ |       | +--------------+ |
 | +----------+ |      | |  Learning  | |       | |   Routing    | |
 | | Routing  | |      | +------------+ |       | |  + learning  | |
 | +----------+ |      |  weak coupling |       | +--------------+ |
 |              | ==>  | +------------+ |  ==>  |    integrated    |
 |              |      | |   Routing  | |       |  strong coupling |
 | +----------+ |      | +------------+ |       | +--------------+ |
 | |Forwarding| |      | +------------+ |       | |  Forwarding  | |
 | +----------+ |      | | Forwarding | |       | |  + learning  | |
 |              |      | +------------+ |       | +--------------+ |
 +--------------+      +----------------+       +------------------+
			</artwork>
	 </figure>			
			
			<t>Including learning capabilities into current Internet router architectures can follow a phased approach. Internet routers typically consist of two functional components: i) a forwarding component which takes care of processing and forwarding packets according to pre-configured forwarding tables, and ii) a routing component which takes care of distributing topology/distance information, computing (shortest) routing paths using this information, and storing resulting entries into routing tables. Forwarding table entries are subsequently derived from routing table entries. As a first integration step, a new functional component comprising learning capability could be included. The new component would then be weakly coupled to the existing forwarding and routing components. This implies that the routing and/or forwarding component can be enhanced by of the learning component. These functionalities could be called via pre-defined interfaces between the components. While this is an overlaid but modular build-up of a router, integration of learning capability can go one step further. Indeed, in a next phase, instead of a separate learning component, the learning functionality could be tightly integrated into the routing and forwarding components themselves. This implies that the routing and forwarding processes themselves comprise a learning cycle (a self-adaptive closed-loop control). It is clear that both the phasing and the detailed specification of the architecture is an important challenge in the design of LCCNs.</t>
		</section>
		
		<section anchor="coexistance" title="Coexistance with current networking protocols, mechanisms and practices">		
			<t>The roll-out of learning capability into communication networks preferrably allows to coexist with well-functioning existing network protocols and mechanisms. This means that LCCNs should not enforce the networking environment to use them or adapt to them, even though they could improve the resulting network performance or solve a number of issues. As such, a transition path towards communication networks including more learning-capability becomes possible without introducing abrupt transition paths. </t>
		</section>
		
		<section anchor="tradeoff" title="Complexity/control vs. performance/labour trade-off measurability">
			<t>The implications of using LCCNs should be addressed by determining the relative complexity and understandability they introduce. This does not mean that complex (or black box) LCCN approaches are out of scope, it implies that the additional complexity and understandability resulting from the introduction of this control component should be measurable or can be at least characterized. Measurability (and associated metrics) is an integral part of the investigation work. The assesment should allow users of LCCNs to decide on the level of control vs. performance they are willing to give up/gain. In this context, the analogy can be made with manual configuration of static routing tables vs. running automated shortest path protocols. It is clear that a certain level of control is given up by allowing automated routing protocols to configure routing tables. However, the resulting configuration is verifyable (by routing table inspection), the used algorithm (e.g. Dijkstra shortest path calculation) is known, and the resulting reduction in manual intervention is clear. On the other hand, the more laborous manual configuration allows for setups that are sometimes more tuned to specific traffic patterns (e.g. avoiding bottlenecks) than shortest path-protocols. In most scenario's, the trade-off is clear for network operators: larger networks typically use automated routing protocols for the population of routing tables, whereas smaller, specialised network setups sometimes result into manually configured routing tables. A similar type of trade-off is desired for LCCNs.</t>
		</section>
		
	</section>

	<section anchor="applicability" title="Applicability">
		<section anchor="domains" title="Functional domains">
			<t>The incorporation of learning component within the router architecture aims to i) enhance Internet functionality in order to cope with known operational challenges such as manageability, and diagnosability, ii) address new challenges such as security and accountability, and iii) improve its performance (in terms of e.g. scalability and availability) by adapting forwarding and routing system decisions. In this context of network quality, we can think of the automated inclusion of network traffic knowledge into the configuration of routes and resulting forwarding tables. </t>
		</section>

		<section anchor="scope" title="Scope with respect to the hourglass model">
			<t>Even if learning paradigms can be applied at all levels of the hour-glass model, LCCN-related research focuses on the (largest) lower half of the hourglass model ("everything over IP, and IP over everything"). As depicted in <xref target="hourglass"/>, the goal of LCCN research is to apply learning capabilities from the transport layer up to the physical layer (including thus also the network and datalink layers). </t>

			<t>Whereas learning capability is typically being used at the application layer already, for example by banking applications, large-scale websites such as Amazon or Google, except for TCP, the real networking machinery that is running below is still relying on low-information processes with very limited learning capabilities. The incorporation of a learning component within wired and wireless communication network systems aims to improve both their operation and performance from the physical network layer up to the TCP/IP layer. TCP can be qualified as an exception in the sense that it incorporates some of the procedures involved in learning processes. Indeed, its transmission window size is adaptively changed during the communication between network end points such as to maximize throughput while keeping the resulting congestion as low as possible. However, it mainly concerns end-to-end learning while learning within the network itself provides additional value (as shown by the work performed e.g. in <xref target="Tavernier10"/>).</t>
		
			<figure anchor="hourglass"> 
				<artwork>
            +---------------------+
             \  email, WWW,      /
              \    TV, ...      /
               \---------------/
                \SMTP,HTTP,RTP/     
         ---     \-----------/     ---
          ^       \ TCP,    /       ^
          |        \   UDP /        |
          |         \-----/         |
   LCCN   |         / IP  \         |
   scope  |        /-------\        |
          |       /Ethernet,\       |
          |      /  PPP,...  \      |
          |     /-------------\     |
          v    / CSMA, Sonet   \    v
         ---  /-----------------\  ---
             /copper,fiber,radio \  
            +---------------------+ 

				</artwork>
		 </figure>		 
		</section>
		
		<section anchor="existing" title="Existing work">
			<t>Although the penetration of learning capability in current network protocols is rather low, in several domains some studies have been conducted on the possible value of introducing learning capability or intelligence into the networking mechanisms.</t>
			
			<t>Learning systems have been succesful applied for example in cognitive radio networks and optical networks. Using such systems, wireless network nodes adaptively change their transmission and/or reception parameters to communicate efficiently avoiding interference with other networks and nodes. The adaptive change of these parameters is based on the active monitoring of several factors in the external and internal radio environment, such as radio frequency spectrum, user behavior and network state. More information about cognitive radio networks can be found in <xref target="Haykin2007"/>.</t>
			
			<t> <xref target="Riziotis07"/> made a survey on the succesful application of computational intelligence techniques in the domain of photonics and optical networks. Tens of studies are cited on the succesfull application of optimization and learning techniques in the design and operation of optical networks. For example in <xref target="Goncalves04"/>, agents make use of Artificial Neural Networks for monitoring an optical link of a network and predicting anomalous situations so that pro-active measures can be taken before faults occur. This technique showed to be significantly less costly compared to providing 1+1 protection on DWDM links. </t>
		
			<t>The insight resulting of bringing together conducted research on learning capability in networked environments can result into a common base of and architecture to further investigate and deploy learning capability into new networked contexts. Such a bottom-up approach can be valuable as it can give us lessons in common challenges, and ways to tackle them in order to reach a higher level of adoption of LCCNs. </t>
		</section>
	</section>
	
	<section anchor="research" title="Research directions">
		<section anchor="relation" title="Relation to existing research domains">
			<t>Learning opportunities in communication networks have characteristics that are typical well-suited for research techniques borrowing from (machine) learning, robotics, AI, computational biology, etc. </t>
			
			<t><list style="symbols">
				<t>Difficult to explicitly characterize: events cannot be well characterized even when examples are available (inherent complexity in characterizing an event) </t>
				<t>Correlation: hidden correlations and trends between events within large amounts of associated data </t>
				<t>Dynamicity: changing conditions over time (in particular, for routing system but also variability of traffic, user expectations and behaviors) </t>
				<t>Quantity: amount of available data is too large for handling by manual intervention </t>
				<t>Evolutive: new events are constantly detected/discovered </t>
			</list></t>
		</section>
		
		<section anchor="experimental" title="Experimental research objectives">
			<t> Experimental research is a primary goal of the activities to be conducted. The following objectives would be targeted: </t>
			
				<t><list style="symbols">
					<t>The production of various studies is stimulated and should enable evaluation of performance and functional improvement resulting from the exploitation of various learning paradigms. A common understanding of these paradigms and their associated capabilities could complement this first step. The resulting bottom-up approach allows to combine insights of several use cases involving learning in networks to find the common base and best architecture/practices in the development of LCCNs.</t>
					<t>As different distribution models can be considered for what concerns the distribution of the learning processes (taking into account the various objectives but also constraints resulting from network partition), determining which model best fit Internet evolution is a specific target of this research activity.</t>
					<t>Iterative cycles of experimentation shall allow to determine suitability of the resulting architecture as well as to determine practical feasibility, applicability and deployability of the concept on a large scale. Documentation of appropriate use cases/scenarios would complement this work item.</t>
				</list></t>
		</section>
	</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>It is desirable that LCCNs provide visibility on the possible mis-use of their learning capability. As such, the assesment of their attractiveness for deployability becomes easier. </t>

      <t>Beside the research objectives detailed here above, security mechanisms for "communication channels" between learning components and "learning components" themselves shall be considered comprising among others message authentication but also means to prevent e.g. man-in-the-middle and DDoS attacks. In the LCCN context, the question becomes what is sufficient for protecting the Internet against such attacks. Is it sufficient to provide secure communication channels as well as adequate authentication and verification/validation mechanisms for the information exchanged over these channels, or can we rely on learning to determine protecting decisions systems should take to ensure their own defense against such attacks ? These are security topics that can be further investigated in the context of LCCN research.
	  </t>	  
    </section>
	
	<section anchor="conclusion" title="Conclusions">
		<t>Current communication networks fail to use network-related statistics which could be valuable to improve their performance. In addition, current networks fail to provide solutions to challenging issues, because they become too complex to operate and manage by manual/open loop procedures. A learning-capable communication network (LCCN) includes a learning component which learns based on the network environment statistics and adapts and optimizes its behavior upon this. This gives new possibilities to improve network efficiency in several domains including network recoverability, accountability, security, scalability, and so on. The challenge (and next steps) of LCCNs lies into: i) developing self-adaptive closed)loop control system relying on learning capability, ii) building and applying it to various network mechanisms and iii) verifying the resulting prototypes in experimental environments. </t>
	</section>	
	
	<section anchor="Acknowledgements" title="Acknowledgements">
      <t> This work is supported by the European Commission (EC) Seventh Framework Programme (FP7) ECODE project (Grant No.223936). </t>
    </section>
	
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->
	
	<references title="Informative references">
		<reference anchor="AI-modern">
			<front>
				<title>Artificial Intelligence: A Modern Approach</title>
				<author initials="S.J." surname="Russell"
						fullname="S.J. Russell">
				</author>
				<date year="2003" />
			</front>
		</reference>
		
		<reference anchor="PRML">
			<front>
				<title>Pattern Recognition and Machine Learning</title>
				<author initials="C.M." surname="Bishop"
						fullname="C.M. Bishop">
				</author>
				<date month="october" year="2003" />
			</front>
		</reference>
 
 		<reference anchor="Estan04">
			<front>
				<title>Building a better NetFlow</title>
				<author initials="C." surname="Estan"
						fullname="Cristian Estan">
				</author>

				<date month="october" year="2004" />
			</front>
		</reference>
 
		 <reference anchor="Riziotis07">
			<front>
				<title>Computational intelligence in photonics technology and optical networks: A survey and future perspectives</title>
				<author initials="C." surname="Riziotis"
						fullname="Christos Riziotis">
				</author>

				<date month="december" year="2007" />
			</front>
		</reference>
		
		<reference anchor="Goncalves04">
			<front>
				<title>Applying artificial neural networks for fault prediction in optical network links</title>
				<author initials="C.H." surname="Goncalves"
						fullname="Carlos Hairon R. Goncalves">
				</author>

				<date month="december" year="2007" />
			</front>
		</reference>
		
		<reference anchor="Tavernier10">
			<front>
				<title>Using AR(I)MA-GARCH models for improving the IP routing table update</title>
				<author initials="W." surname="Tavernier"
						fullname="W. Tavernier">
				</author>

				<date month="october" year="2010" />
			</front>
		</reference>
		
		<reference anchor="Haykin2007">
			<front>
				<title>Cognitive radio: brain-empowered wireless communications</title>
				<author initials="S." surname="Haykin"
						fullname="S. Haykin">
				</author>

				<date month="february" year="2007" />
			</front>
		</reference>
		
		<reference anchor='I-D.ietf-idr-bgp-issues'>
		<front>
		<title>Issues in Revising BGP-4 (RFC1771 to RFC4271)</title>

		<author initials='A' surname='Lange' fullname='Andrew Lange'>
			<organization />
		</author>

		<date month='August' day='16' year='2010' />

		<abstract><t>This document records the issues discussed and the consensus reached in the Interdomain Routing (IDR) Working Group during its efforts to revise and bring up to date the base specification for the BGP-4 protocol as documented in RFC1771.  The results of these efforts are encoded in RFC4271.</t></abstract>

		</front>

		<seriesInfo name='Internet-Draft' value='draft-ietf-idr-bgp-issues-03' />
		<format type='TXT'
				target='http://www.ietf.org/Internet-drafts/draft-ietf-idr-bgp-issues-03.txt' />
		</reference>
				
			</references>
	
    <!-- There are 2 ways to insert reference entries from the citation libraries:
     1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
        (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

     Both are cited textually in the same manner: by using xref elements.
     If you use the PI option, xml2rfc will, by default, try to find included files in the same
     directory as the including file. You can also define the XML_LIBRARY environment variable
     with a value containing a set of directories to search.  These can be either in the local
     filing system or remote ones accessed by http (http://domain/dir/... ).-->


    <!-- Change Log

v00 2010-08-15  WT   Initial version
	-->
  </back>
</rfc>
