draft-corujo-icn-mgmt-01.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 RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
<!ENTITY RFC1157 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1157.xml">
<!ENTITY RFC6733 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6733.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-corujo-icn-mgmt-01" ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
        or pre5378Trust200902
     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="ICN Management Considerations">ICN Management Considerations</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->

      <author fullname="Daniel Corujo" initials="D.C." surname="Corujo">
          <organization>Instituto de Telecomunicacoes</organization>
          
          <address>
              <postal>
                  <street>Campus Universitario de Santiago</street>
                  
                  <!-- Reorder these if your country does things differently -->
                  
                  <city>Aveiro</city>
                  
                  <region></region>
                  
                  <code>P-3810-193 Aveiro</code>
                  
                  <country>Portugal</country>
              </postal>
              
              <phone>+351 234 377 900</phone>
              
              <email>dcorujo@av.it.pt</email>
              
              <!-- uri and facsimile elements may also be added -->
          </address>
      </author>
      
      <author fullname="Kostas Pentikousis" initials="K.P." surname="Pentikousis">
          <organization>Huawei Technologies</organization>
          <address>
              <postal>
                  <street>Carnotstrasse 4</street>
                  <city>10587 Berlin</city>
                  <country>Germany</country>
              </postal>
              <email>k.pentikousis@huawei.com</email>
          </address>
      </author>
      
      <author fullname="Ivan Vidal" initials="I.V." surname="Vidal">
              <organization>UC3M</organization>
              <address>
                  <postal>
                      <street>Av de la Universidad, 30</street>
                      <city>28911 Leganes, Madrid</city>
                      <country>Spain</country>
                  </postal>
                  <email>ividal@it.uc3m.es</email>
              </address>
          </author>
          

    <date year="2013" />

    <!-- 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>ICNRG</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>ICN; Network Management</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>This document aims to draw the attention of the ICNRG community to network management, an important but hitherto underdeveloped area of research in information-centric networking.  We consider that the availability of modern  management mechanisms for information-centric networks will foster their deployment in real-world environments. For example, we argue that there is a need for creating basic network management tools early on while ICN is still in the design and experimentation phases that can evolve over time. Perhaps ICN can borrow successful mechanisms from the host-centric paradigm and adapt them to the new network primitives. Alternatively, novel network management schemes can be designed based on ICN primitives. As a discussion starter, this document summarizes recently published approaches for ICN network management. In particular, this first version presents a management framework for named data networking and reviews previous work on NetInf management.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
		<t>Information-centric networking (ICN) enables new ideas for naming and addressing, privacy, security, and trust, and should also lead us to think new ways for deploying, operating and managing networks in the future. By default, users, programs, information objects and hosts are in general untrustworthy and mobile in an information-centric network. This means that many of the assumptions in traditional network management, including all aspects of FCAPS (Fault, Configuration, Accounting, Performance, and Security) need to be rethought. However, despite the different instantiations of ICN architectures, and the plethora of novel research work built on top of them, little attention has been paid to management aspects so far. This includes both enabling "traditional" network management operations (which work well from small networks to large infrastructure networks), and supporting and optimizing intrinsic procedures of the ICN fabric.</t>
		
		<t>This document aims to draw the attention of ICNRG to the importance of network management for real-world deployments. Today, network management is practically an add-on to host-centric deployments. We can do better as we move forward in ICN research considering the full range of deployments from home-office environments to challenged networks to tier-1 networks. To this end, we draft some first management considerations that, on the one hand, capitalize on ICN concepts for defining management procedures and, on the other, explore the possibilities for defining a common management framework irrespective of the ICN approach taken. We reckon that the later is a much more formidable task and we are looking forward to tackling it together with other members of ICNRG. We start this exercise in this first version based on published literature and in particular with a NDN approach.</t>

		<t>We argue that addressing management at an early stage is not only important for real-world adoption and the successful future deployment of ICN, but also to deal with scenarios where management can simplify, enhance or optimize ICN network utilization and performance. The subject becomes particularly challenging, as disparate characteristics from different ICN approaches (e.g., in terms of namespace, granularity, routing, and so on) impact the definition and design of these management mechanisms. <xref target="sec-ndn-mgmt"/> below provides an initial assessment, proposal and evaluation of management mechanisms leveraging NDN intrinsic capabilities based on <xref target="NDN-MGMT"></xref>, while <xref target="sec-netinf-mgmt"/> briefly summarizes earlier work on self-management for NetInf.</t>
		
		<t>We plan to incrementally develop the draft and incorporate other ICN approaches (e.g., [PURSUIT] and [NetInf]) as well as address other pertinent aspects as we receive feedback from the research group members.</t>
    </section>


	<section title="NDN Management Considerations" anchor="sec-ndn-mgmt">

		<t>The Named Data Networking <xref target="NDN"></xref> ICN architecture provides a new communication framework built on named data. Like other ICN counterparts, such as <xref target="NetInf"></xref>, <xref target="PURSUIT"></xref> and <xref target="DONA"></xref>, NDN intrinsically supports security, routing/forwarding, reliability, caching and even mobility, aiming at scalable and more efficient content-distribution than today's IP-based approaches. Fostered by an open-source implementation <xref target="CCNx"></xref>, NDN has been at the heart of an active topic with several research contributions evaluating its deployment feasibility and performance in a number of scenarios <xref target="ICN-Scenarios"></xref>.</t>

		<t>NDN relies on a hierarchical, human-readable namespace to address named data objects, where the naming scheme is simultaneously used to both name information and to route it. It relies on content requesters sending an Interest packet with a Content Name, where the prefix can provide information for global and organizational routing, while the suffix indicates versioning and segmentation details. When a node receives an Interest packet asking for content which  matches what is already available at the node, it responds with a matching Data packet carrying back the content.</t>	

		<t>Each NDN node comes with a set of supporting data structures which enable the coordination between the transmission of Interest packets with the reception of the corresponding Data packets. These structures include:</t>

		<t>
		<list style="numbers">
        <t>Content Store: maintains an indication of locally available content, according to name, and is used for Interest packet matching. If the content is available at the node, the Interest packet is consumed, and a Data packet with the respective content is sent towards the request origin.</t>

        <t>Pending Interest Table (PIT): keeps track of Interest packets seen previously by the node, on their way to locate matching content. Interest packets in the PIT were not matched to content available in the node. Basically, PIT maintains a degree of state regarding Interest packets, mapping them to a corresponding egress network interface.</t>
		
		<t>Forward Information Base (FIB): associates named data to potential holders of the content. A routing protocol can populate the FIB (although this is outside the scope of NDN) or it can be populated through registration in a local NDN store.</t>
        </list>
		</t>

		<t>NDN introduces the concept of a Strategy Layer, which can control Interest packet forwarding behavior. It basically determines which is the best interface (or set of interfaces) to send an Interest packet. The "strategy" component establishes a pre-configured algorithm for tackling Interest packet decisions, ranging from sending it sequentially on each interface until a Data packet is received, to evaluating which interfaces provide better performance (i.e., lower average RTT) in retrieving certain content (as discussed in <xref target="NDN"></xref>).</t>
		
		<t>It is important to keep in mind that NDN replaces the commonly used term "interface" with the term "face", since packets can be forwarded over hardware network interfaces  as well as between application interfaces, further acknowledging the information dissemination capabilities of ICN. This aspect is considered in <xref target="NDN"></xref> and <xref target="NDN-R"></xref>, where programs can be associated to the NDN governing structures (like the FIB), defining configurations such as "sendToAll" and "sendToBest" with respect to managing the content reaching process. Corujo et al. <xref target="NDN-MGMT"></xref> exploit these concepts enabling management mechanisms to be deployed, and steer network operations and NDN operation, as described in the following section.</t>

		
	<section title="Towards a Management Framework for NDN">

		<t>An important aspect supporting network management procedures is the interaction of network information residing at the network side with information about the network from the perspective of clients connected to it. The former includes, for instance, information stored in the network operator core about user profiles, associated policies, or data collected by the access network equipment, such as current and past traffic load levels, active flows, and maintenance information. Today, such information can be retrieved for management and operation support through dedicated signaling protocols (e.g., <xref target="RFC1157"></xref>, <xref target="RFC6733"></xref>), or Operation Support Services (OSS) web services. The client point of view of the network includes information that, for example, a wireless terminal can provide, indicating wireless link quality, average return-trip times (RTT) or perceived Quality of Experience (QoE).</t>

		<t>Both types of information can be capitalized upon allowing, for example, the network to coordinate network management procedures, considering as input information obtained from other network elements as well as from user nodes. One way to generate management information in network entities and at client nodes, as well as to consume and act upon it (i.e., using the management information exchange as a control channel) is to couple NDN nodes with Management Agent (MA) entities.</t>
		
		
		<t>Fig. 1 (redrawn here from <xref target="NDN-MGMT"></xref> for convenience) illustrates how a MA can be deployed in both network and client entities, interfacing with different operational aspects and protocol layers of an NDN node. By using NDN content reaching and disseminating mechanisms, management information can be consumed by the MA to steer not only the behavior of application processes and network interfaces, but also to interface with NDN supporting structures (i.e. Content Store, FIB, PIT). Effectively, different kinds of information can be conveyed to a network node responsible for managing the network (under different perspectives and processes), and resubmitted back towards client nodes, affecting the way applications interface with network interfaces and the NDN fabric.</t>


		<figure align="center">
		<artwork align="left"><![CDATA[
 NDN Fabric
   +------------------------------------------+
   |                                   Face 0 |
   | +--------------+                   +---+ |  +------+
   | |Content Store |      ptr/type     |  <---->|WLAN  |
   | +------------^-+      +-+----+     +---+ |  +------+
   |              +---------+|    |    Face 1 |
   | +--------------+      +------+     +---+ |  +------+
   | |Pending      <--------+|    |     |  <---->|LTE   |
   | |Interest Table|      +------+     +---+ |  +------+
   | +--------------+      | |    |    Face i |
   |                       +------+     +---+ |  +------+
   | +--------------+      | |    |     |  <---->| MA   |
   | |Forward       |      +------+     +---+ |  +------+
   | |Information <---------+|    |    Face j |
   | |Base          |      +-+----+     +---+ |  +------+
   | +--------------+                   |  <---->|VoIP  |
   |                                    +---+ |  |Video |
   +------------------------------------------+  +------+            
]]>
   Figure 1.  NDN Management Framework
		</artwork>
		</figure>

		<t>MA can interface with the PIT and FIB structures, acting as a dynamic, application- and/or network-controlled interface to the strategy layer. This could also be used to direct how to forward NDN Interest and Data packets, in a configurable manner. Regarding  network interfaces, the MA can interface with them not only to control (i.e., initiate wireless access scanning procedures), but also to collect information (i.e., an informational event regarding detected access points). Finally, the MA can also interface with application processes, drawing out information about the perceived QoS/QoE (e.g., lost packets or delay from a real-time video feed) and also to execute commands, such as selecting a better video codec when the network commands the video flow to be accessed from a different wireless access interface.</t>

		<t>Conversely, MA entities residing in network equipment can provide informational events as well, but related to network-side link layer characteristics (such as number of attached nodes or load), as well as accepting commands from the network (i.e., activate maintenance procedures). Management processes residing in the network core can leverage information collected from applications, client terminals and network equipment, to drive optimization procedures. Such optimization procedures can also tap into other entities, containing complementary information such as policies and subscription information, and use it to produce an overall network decision, which can then be forwarded to multiple client nodes, in a policy enforcing way.</t>

		<t>An important consideration from the NDN architecture, is the hierarchical namespace, allowing nodes to request and convey management data, by simply using an appropriate prefix (e.g., ccn://domain/management/ME).</t>

		<t>By leveraging the NDN information-centric dissemination mechanisms to convey management information and commands as content, these management extensions inherit the intrinsic capabilities of the NDN architecture, including security and reliability, which are fundamental for management procedures.</t>
	</section>

	<section title="NDN Management Operations">

		<t>In order to implement management operations, besides the interfacing capabilities of the MA entity mentioned in the previous section, a management framework needs other supporting mechanisms in order to provide the envisioned management capabilities, while maintaining the inherent NDN capabilities. Concretely, when nodes connect to the network, the management entities need to become aware of the management capabilities of the newly-connected node. In addition, an asynchronous information exchange capability needs to be provided, allowing not only the request of management information, but also the ability to push information towards a remote node (i.e., sending a command or an informational event).</t>

		<section title="Discovery Procedure">

			<t>The discovery procedure is illustrated in Fig. 2 (redrawn from <xref target="NDN-MGMT"></xref>), and borrows for the procedures described in <xref target="NDN-VOIP"></xref>. The procedure starts with the newly connected User Equipment (UE) broadcasting an Interest packet (Fig. 2:1) perhaps with a well-known content name (e.g., ccn://domain/management/mgmt-case/ME) to its local network.</t>

			<figure align="center">
			<artwork align="left"><![CDATA[
  +-------+                                     +------------+
  |+--+   |                                     |       +---+| 
  ||MA| UE|                                     |Network|ME ||
  |+--+   |                                     |       +---+|
  +-|-----+                                     +------------+
    |(1) INTEREST                                        |
    |-/domain/management/mgmt-case/ME ------------------>|
    |                                                    |
    |(2) DATA                                            |
    |<-/domain/management/mgmtm-case/ME------------------|
    |(Signature, ME-publisher-id, key locator            |
    | DATA:supported security mechanisms)                |
    |                                                    |
    |(3) INTEREST                                        |
    |-/domain/management/mgmt-case/ME/MA-published-id/ ->|
    |(encrypted with ME's PK:security-mechanism, SKey)   |
    |                                                    |
    |(4) DATA                                            |
    |<-/domain/management/mgmt-case/ME/MA-publisher-id/--|
    |(encrypted with ME's PK:security-mechanism, SKey)   |
    | DATA: Session Key received                         |
    |                                                    |
    |(5) INTEREST                                        |
    |<-/domain/management/mgmt-case/MA-publisher-id/-----|
    |  /nonce (encrypted)                                |
    |                                                    |
    |(6) DATA                                            |
    |-/domain/management/mgmt-case/MA-publisher-id/----->|
    |  /nonce (encrypted)                                |
    | DATA: Encrypted nonce received                     |

	]]>
	Figure 2. Secure Management Session Establishment
			</artwork>
			</figure>

			<t>The "mgmt-case" part of the name can be used to select different aspects of management capabilities allowed by a Management Entity (ME) (i.e., a management decision point in the network). The ME then replies to this Interest with a Data packet (Fig. 2:2), providing its shorthand identifier (i.e., ME-publisher-key) and a key locator, indicating how to retrieve its public key (assuming it is authorized by another key trusted by the UE). In this way, the MA at the UE recognizes the ME as a valid signer (and provider) of management content.</t>

			<t>A session key, Ks, is generated by the MA, considering an encryption algorithm from the ones indicated by the ME in the Data packet. The MA then expresses its desire to receive (and reply to) Interests matching a specific NDN name associated with the management service (e.g., ccn://domain/management/mgmt-case/ME/MA-publisher-id), where MA-publisher-id uniquely and globally identifies the MA, through a cryptographic digest of its public key. After this, the MA sends an Interest packet (Fig. 2:3) to retrieve management Data from the ME containing the short-hand identifier of the MA (MA-publisher-id), the chosen encryption algorithm and session key (Ks), both encrypted with the public key of the ME. In this way, the confidentiality of the content exchanged between the ME and the MA is guaranteed. The ME responds with a Data packet (Fig. 2:4) signaling the reception of the session Key.</t>

			<t>Before the actual exchange of management data begins, the ME generates a challenge (i.e., a nonce) which is sent via an Interest packet (Fig. 2:5) to the MA, indicating through a named data name that it requests the reception of the response to this challenge, sent by the MA using a Data packet (Fig. 2:6). This allows the ME, after verifying the signature of the Data packet, to verify that the encryption algorithm and the session key are valid for the MA, making it ready to exchange information for coordinating management procedures in the network.</t>
		</section>

		
		<section title="Management Data Exchange">

			<t>After the discovery and security establishment procedures have been finalized, the framework provides the capability for both the MA and the ME to securely obtain management content from one another.</t>

			<t>In order to push unsolicited content, a dual Interest/Data procedure can maintain compatibility with the Interest and Data exchange/consumption of the NDN architecture. Fig. 3 (redrawn from Fig.2 of <xref target="NDN-MGMT"></xref>) illustrates  the procedure which is initiated by the MA. In this case, the MA intends to push management information to the ME. It does so via an Interest packet manifesting its interest in receiving management content with a local sequence number. This sequencing allows the recovery of new content over cached content. If the ME is interested in retrieving content from the MA, it answers back with a Data packet, where it indicates that it is willing to receive management content. Then, the ME sends an Interest packet to retrieve the management data with the sequence number provided by the MA, which responds with a Data packet containing the information it wanted to push into the ME.</t>
			
			<figure align="center">
			<artwork align="left"><![CDATA[
  +-------+                                     +------------+
  |+--+   |                                     |       +---+|
  ||MA| UE|                                     |Network|ME ||
  |+--+   |                                     |       +---+|
  +-|-----+                                     +------------+
    |(1) INTEREST                                        |
    |-/domain/management/faces/MA-publisher-id/seq_num-->|
    |                                                    |
    |(2) DATA                                            |
    |<-/domain/management/faces/MA-publisher-id/seq_num--|
    |(Signature)                                         |
    | DATA:content seq_num accepted                      |
    |                                                    |
    |(3) INTEREST                                        |
    |<-/domain/management/faces/MA-publisher-id/seq_num--|
    |                                                    |
    |(4) DATA                                            |
    |-/domain/management/mgmt-case/ME/MA-publisher-id/-->|
    |(Signature)                                         |
    | DATA: management data (encrypted with Ks)          |
    |                                                    |
]]>
  Figure 3. Content Management Push
			</artwork>
			</figure>
		</section>
	</section>
	
	<section title="Implementation Experience" anchor="sec-ndn-mgmt-impl">
		
		<t>As a proof-of-concept, a software prototype of the management framework, <xref target="NDNFlexManager"></xref> was developed for <xref target="NDN-MGMT"></xref>, using the CCNx Java API <xref target="CCNx"></xref>. At this early stage, it includes the implementation of an ME and an MA as NDN applications, supporting the NDN management operations outlined in Fig. 3. Thus, the ME and the MA can push unsolicited content to each other, related with management operations.</t>
            
            
        <t>To validate this basic prototype, <xref target="NDN-MGMT"></xref> considered a specific use case supported by the framework, i.e., face management. This entails configuring and selecting an appropriate face in a UE to retrieve a given content. Based on the CCNx, an evaluation test-bed was deployed including an NDN UE (featuring an MA and a set of network interfaces), a content server and a network node (featuring an ME). These entities are interconnected by a set of NDN routers. The purpose of the evaluation scenario is to demonstrate feasibility for the protocol exchanges mentioned earlier. Note that the code has been tested in a small-scale environment where the ME is topology-aware and keeps track of conditions of the access networks that are available to the UE. Thus, the ME can provide the MA with management information reporting the appropriate face for content retrieval, or an alternative point of access that could be used to improve the performance. The MA uses the management information to reconfigure the FIB (and possibly the network interfaces) in the UE, setting the appropriate face to forward subsequent Interests.</t>
            
        <t>For validation purposes, a local application was also implemented at the NDN UE that works similarly to a ping utility, generating periodic Interests that match a given prefix (served by the content server), and computing the Round Trip Time of each Interest/Data exchange. The RTT values obtained by this application in <xref target="NDN-MGMT"></xref>, indicate that the performance of the NDN management framework in the considered evaluation scenario is satisfactory, given the early stage of this work. Further development and testing is ongoing.</t>
		
		
	</section>
	</section>


	<section title="NetInf Management Considerations" anchor="sec-netinf-mgmt">
	
		<t>Early-phase work in NetInf management <xref target="NetInfSelfX"></xref> discussed a two-fold problem. The first question that arises is whether it is possible by adopting a new set of network primitives and in-network storage to usher a new type of network management. In other words, can network management become information-centric while handling often host-centric data? The second question is whether an information-centric network is more suitable for self-management mechanisms than IP-based networks are.  In particular with respect to the later, <xref target="NetInfSelfX"></xref> introduced some design considerations for adding self-management mechanisms in NetInf.</t>
		
		<t>Of interest from this early work are two examples where network management can play a new role. First, network management can get involved in decisions about caching and (re)distribution of content, and not only whether an (inter)face is on or off, or what traffic limits should be enforced.  Moreover, network policies can be distributed securely in the same way as other content in the network, removing the need for centralized management, and enabling improved recovery procedures. Second, network management can get involved in more intricate processes such as controlling multiaccess support, intermediating for content adaptation when deemed appropriate, and enabling richer tools for traffic engineering.</t> 
		
	</section>

    <section anchor="Acknowledgements" title="Acknowledgements">
		<t>This document has benefited from comments and/or text provided by the following members of ICNRG:</t>
		
		<t>Jaime Garcia-Reinoso (UC3M); <xref target="sec-ndn-mgmt-impl"/> </t>
    </section>


    <section anchor="IANA" title="IANA Considerations">

	<t>This memo includes no request to IANA.</t>

	</section>

	
    <section anchor="Security" title="Security Considerations">
	
    <t>TBD</t>
	
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

    <!-- 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/... ).-->

    <references title="Informative References">
      <!-- Here we use entities that we defined at the beginning. -->


      &RFC3552;

      &RFC5226;
        
        &RFC1157;
        
        &RFC6733;

      <!-- A reference written by by an organization not a person. -->

        <reference anchor="NDN-MGMT">
            <front>
                <title>A named data networking flexible framework for management communications</title>
                <author initials="D." surname="Corujo" fullname="D. Corujo">
                    <organization/>
                </author>
                <author initials="I." surname="Vidal" fullname="I. Vidal">
                    <organization/>
                </author>
                <author initials="J." surname="Garcia-Reinoso" fullname="J. Garcia-Reinoso">
                    <organization/>
                </author>
                <author initials="R." surname="Aguiar" fullname="R. Aguiar">
                    <organization/>
                </author>
                <date year="2012" month="Dec"/>
            </front>
            <seriesInfo name="Communications Magazine, IEEE , vol.50, no.12, pp.36-43" value=""/>
        </reference>

        <reference anchor="NDN">
            <front>
                <title>Networking Named Content</title>
                <author initials="V." surname="Jacobson" fullname="V. Jacobson">
                    <organization/>
                </author>
                <author initials="D.K." surname="Smetters" fullname="D.K. Smetters">
                    <organization/>
                </author>
                <author initials="J.D." surname="Thornton" fullname="J.D. Thornton">
                    <organization/>
                </author>
                <author initials="M.F." surname="Plass" fullname="M.F. Plass">
                    <organization/>
                </author>
                <author initials="N.H." surname="Briggss" fullname="N.H. Briggs">
                    <organization/>
                </author>
                <author initials="R.L." surname="Braynard" fullname="R.L. Braynard">
                    <organization/>
                </author>
                <date year="2009" month="Dec"/>
            </front>
            <seriesInfo name="CoNEXT 2009, Rome" value=""/>
        </reference>

        <reference anchor="NDN-VOIP">
            <front>
                <title>VoCCN: Voice Over Content-Centric Networks</title>
                <author initials="V." surname="Jacobson" fullname="V. Jacobson">
                    <organization/>
                </author>
                <author initials="D.K." surname="Smetters" fullname="D.K. Smetters">
                    <organization/>
                </author>
                <author initials="N.H." surname="Briggss" fullname="N.H. Briggs">
                    <organization/>
                </author>
                <author initials="M.F." surname="Plass" fullname="M.F. Plass">
                    <organization/>
                </author>
                <author initials="P." surname="Steward" fullname="P. Steward">
                    <organization/>
		</author>
                    <author initials="J.D." surname="Thornton" fullname="J.D. Thornton">
                        <organization/>
                    </author>
                <date year="2009" month="Dec"/>
            </front>
            <seriesInfo name="ReARCH 2009, Rome" value=""/>
        </reference>
        
        <reference anchor="NetInf">
            <front>
                <title>Design considerations for a network of information</title>
                <author>
                    <organization>Ahlgren, B. et al.</organization>
                </author>

                <date year="2008" month=""/>
            </front>
            <seriesInfo name="CoNEXT, Re-Arch Workshop, ACM" value=""/>
        </reference>
        
        <reference anchor="PURSUIT">
            <front>
                <title>Developing Information Networking Further: From PSIRP to PURSUIT</title>
                
                <author>
                    <organization>Fotiou, N. et al.</organization>
                </author>

                
                <date year="2010" month=""/>
            </front>
            <seriesInfo name="BROADNETS, ICST" value=""/>
        </reference>
        
        <reference anchor="DONA">
            <front>
                <title>A Data-Oriented (and Beyond) Network Architecture</title>
                <author>
                    <organization> Koponen, T. et al.</organization>
                </author>
                
                <date year="2007" month=""/>
            </front>
            <seriesInfo name="SIGCOMM, ACM" value=""/>
        </reference>
       
 
        <reference anchor="NDNFlexManager"
            target="https://github.com/ndnflexmanager/framework">
            <front>
                <title>Framework for Flexible NDN Management</title>
                
                <author>
                    <organization>UC3M and ITAV</organization>
                </author>
                
                <date year="2013" />
            </front>
        </reference>
      

 
        <reference anchor="CCNx"
            target="http://www.ccnx.org">
            <front>
                <title>CCNx Project</title>
                
                <author>
                    <organization>PARC</organization>
                </author>
                
                <date year="2013" />
            </front>
        </reference>
      
        <reference anchor="NDN-R" target="http://www.named-data.net/techreport/TR001ndn-proj.pdf">
            <front>
                <title>Named Data Networking (NDN) Project</title>
                <author>
                    <organization>Zhang, L. et al.</organization>
                </author>
                
                <date year="2010" month=""/>
            </front>
            <seriesInfo name="NDN Report ndn-0001, Tech Report, PARC" value=""/>
        </reference>
        
        <reference anchor="NetInfSelfX">
            <front>
                <title>Self-Management for a Network of Information</title>
                <author>
                    <organization>Pentikousis, K. et al.</organization>
                </author>
                
                <date year="2009" month="June"/>
            </front>
            <seriesInfo name="IEEE ICC Workshops 2009" value=""/>
        </reference>
        
      <reference anchor="ICN-Scenarios">
        <front>
          <title>ICN Baseline Scenarios</title>

            <author initials="K." surname="Pentikousis" fullname="K. Pentikousis">
                <organization/>
            </author>
            <author initials="B." surname="Ohlman" fullname="B. Ohlman">
                <organization/>
            </author>
            <author initials="D." surname="Corujo" fullname="D. Corujo">
                <organization/>
            </author>
            <author initials="G." surname="Boggia" fullname="G. Boggia">
                <organization/>
            </author>

          <date month="February" year="2013" />
        </front>
		<seriesInfo name="draft-pentikousis-icn-scenarios" value=" (work in progress)"/>
      </reference>
        
        

    </references>



    <!-- Change Log

v00 2006-03-15  EBD   Initial version

v01 2006-04-03  EBD   Moved PI location back to position 1 -
                      v3.1 of XMLmind is better with them at this location.
v02 2007-03-07  AH    removed extraneous nested_list attribute,
                      other minor corrections
v03 2007-03-09  EBD   Added comments on null IANA sections and fixed heading capitalization.
                      Modified comments around figure to reflect non-implementation of
                      figure indent control.  Put in reference using anchor="DOMINATION".
                      Fixed up the date specification comments to reflect current truth.
v04 2007-03-09 AH     Major changes: shortened discussion of PIs,
                      added discussion of rfc include.
v05 2007-03-10 EBD    Added preamble to C program example to tell about ABNF and alternative 
                      images. Removed meta-characters from comments (causes problems).

v06 2010-04-01 TT     Changed ipr attribute values to latest ones. Changed date to
                      year only, to be consistent with the comments. Updated the 
                      IANA guidelines reference from the I-D to the finished RFC.  -->
  </back>
</rfc>