<?xml version="1.0"encoding="US-ASCII"?>encoding="UTF-8"?> <!DOCTYPE rfcSYSTEM "rfc2629.dtd"[ <!ENTITYrfc1498 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1498.xml">nbsp " "> <!ENTITYrfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">zwsp "​"> <!ENTITYrfc2460 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2460.xml">nbhy "‑"> <!ENTITYrfc4919 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4919.xml"> <!ENTITY rfc4944 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4944.xml"> <!ENTITY rfc5826 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5826.xml"> <!ENTITY rfc6282 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6282.xml"> <!ENTITY rfc6568 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6568.xml"> <!ENTITY rfc6775 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6775.xml"> <!ENTITY rfc6830 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6830.xml"> <!ENTITY rfc6833 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6833.xml"> <!ENTITY rfc7252 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7252.xml"> <!ENTITY rfc7228 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7228.xml"> <!ENTITY rfc7428 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7428.xml"> <!ENTITY rfc7668 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7668.xml"> <!ENTITY rfc7927 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7927.xml">wj "⁠"> ]> <rfccategory="info"xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-irtf-icnrg-nrsarch-considerations-07"ipr="trust200902"> <?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="no" ?> <!-- sort the reference entries alphabetically --> <!-- control vertical white space (using these PIs as follows is recommended by the RFC Editor) --> <?rfc compact="no" ?> <!-- do not start each<ul><li></li></ul><ul><li></li></ul> 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 --> <!-- ***** FRONT MATTER ***** -->number="9236" ipr="trust200902" obsoletes="" updates="" submissionType="IRTF" category="info" consensus="true" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3"> <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="Arch Considerations of ICNusingUsing NRS">Architectural Considerations ofICN usingInformation-Centric Networking (ICN) Using a Name Resolution Service</title><!-- add 'role="editor"' below for the editors if appropriate --> <!-- Another author who claims to be an editor --><seriesInfo name="RFC" value="9236"/> <author fullname="Jungha Hong" initials="J." surname="Hong"> <organization>ETRI</organization> <address> <postal> <street>218Gajeong-ro, Yuseung-Gu</street> <!-- Reorder these if your country does things differently -->Gajeong-ro</street> <extaddr>Yuseung-Gu</extaddr> <city>Daejeon</city><region></region><region/> <code>34129</code><country>Korea</country><country>Republic of Korea</country> </postal><phone></phone><phone/> <email>jhong@etri.re.kr</email><!-- uri and facsimile elements may also be added --></address> </author> <author fullname="Tae-Wan You" initials="T." surname="You"> <organization>ETRI</organization> <address> <postal> <street>218Gajeong-ro, Yuseung-Gu</street> <!-- Reorder these if your country does things differently -->Gajeong-ro</street> <extaddr>Yuseung-Gu</extaddr> <city>Daejeon</city><region></region><region/> <code>34129</code><country>Korea</country><country>Republic of Korea</country> </postal><phone></phone><phone/> <email>twyou@etri.re.kr</email><!-- uri and facsimile elements may also be added --></address> </author> <author fullname="Ved Kafle" initials="V." surname="Kafle"> <organization>NICT</organization> <address> <postal> <street>4-2-1 Nukui-Kitamachi</street><!-- Reorder these if your country does things differently --> <city>Koganei</city><extaddr>Koganei</extaddr> <region>Tokyo</region> <code>184-8795</code> <country>Japan</country> </postal><phone></phone><phone/> <email>kafle@nict.go.jp</email><!-- uri and facsimile elements may also be added --></address> </author> <dateday="15" month="December" year="2021" /> <!-- 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>ICNRG</area> <workgroup>ICN Research Group</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>Internet Draft</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 draftmonth="April" year="2022"/> <workgroup>Information-Centric Networking</workgroup> <keyword>Information-Centric Networking </keyword> <keyword>Name Resolution Service </keyword> <keyword>Name tothe RFC Editor, the keywords will be used for the search engine. -->location mapping </keyword> <abstract> <t> This document describes architectural considerations and implications related to the use of a Name Resolution Service (NRS) in Information-Centric Networking (ICN). It explains how the ICN architecture can change when an NRS is utilized and how its use influences the ICN routing system. This document is a product of the Information-Centric Networking Research Group (ICNRG). </t> </abstract> </front> <middle> <sectiontitle="Introduction">numbered="true" toc="default"> <name>Introduction</name> <t> Information-Centric Networking (ICN) is an approach to evolving the Internet infrastructure to provide direct access to Named Data Objects (NDOs) by names. In two common ICN architectures,NDNNamed Data Networking (NDN) <xreftarget="NDN"></xref>target="NDN" format="default"/> andCCNxContent-Centric Networking (CCNx) <xreftarget="CCNx"></xref>,target="CCNx" format="default"/>, the name of an NDO is used directly to route a request to retrieve the data object. Such direct name-based routing has inherent challenges in enabling a globally scalable routing system, accommodating producer mobility, and supporting off-path caching. These specific issues are discussed in detail inSection 3.<xref target="background"/>. In order to address these challenges, a Name Resolution Service (NRS) has been utilized in the literature as well as the proposals of several ICN projects <xreftarget="Afanasyev"></xref>target="Afanasyev" format="default"/> <xreftarget="Zhang2"></xref>target="Zhang2" format="default"/> <xreftarget="Ravindran"></xref>target="I-D.ravi-icnrg-ccn-forwarding-label" format="default"/> <xreftarget="SAIL"></xref>target="SAIL" format="default"/> <xreftarget="MF"></xref>target="MF" format="default"/> <xreftarget="Bayhan"></xref>.target="Bayhan" format="default"/>. </t> <t> This document describes the potential changes in the ICN architecture caused by the introduction of an NRS and the corresponding implication to the ICN routing system. It also describes ICN architectural considerations for the integration of an NRS. The scope of this document includes considerations from the perspective of an ICN architecture and routing system when using an NRS in ICN. A description of the NRS itself is provided in the companion NRS design considerations document <xreftarget="RFC9138"></xref>,target="RFC9138" format="default"/>, which provides the NRS approaches,functionsfunctions, and design considerations. </t> <t> This document represents the consensus of the Information-Centric Networking Research Group (ICNRG). It has been reviewed extensively by the Research Group (RG) members who are actively involved in the research and development of the technology covered by this document. It is not an IETF product and is not a standard. </t><!-- <t> <list style="symbols"> <t> global scalability of routing </t> <t> Producer mobility </t> <t> Finding off-path cached objects </t> <t> Security of routing information injected from outside the routing system.</t> </list> </t> --></section> <sectiontitle="Terminology"> <!-- <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC2119"></xref>.</t> --> <t> <list style="symbols"> <t> Namenumbered="true" toc="default"> <name>Terminology</name> <dl> <dt>Name Resolution Service (NRS):An</dt> <dd>An NRS in ICN is defined as a service that provides the function of translating a content name or a data object name into some other information such as a routable prefix, a locator, an off-path-cache pointer, or an alias name that is more amenable than the input name to forwarding the object request toward the target destination storing the NDO <xreftarget="RFC9138"></xref>.target="RFC9138" format="default"/>. An NRS is most likely implemented through the use of a distributed mapping database system. The Domain Name System (DNS) may be used as an NRS. However, in this case, the requirements of frequent updates of NRS records due to the creations of a lot of new NDOs and changes in their locations in the network need to be considered.</t> <t> NRS</dd> <dt>NRS server:An</dt> <dd>An NRS comprises the distributed NRS servers storing the mapping records in their databases. NRS servers store and maintain the mapping records that keep the mappings of content or object name to some other information that is used for forwarding the content request or the content itself.</t> <t> NRS</dd> <dt>NRS resolver:The client side</dt> <dd>The client-side function of an NRS is called an NRS resolver. The NRS resolver is responsible for initiating name resolution request queries that ultimately lead to a name resolution of the target data objects. NRS resolvers can be located in the consumer (or client) nodes and/or ICN routers. An NRS resolver may also cache the mapping records obtained through the name resolution for later usage.</t> <t> Name</dd> <dt>Name registration:In</dt> <dd>In order to populate the NRS, the content names and their mapping records must be registered in the NRS system by a publisher who has accessrightrights to at least one authoritative NRS server or by a producer who generates named data objects. The records contain the mapping of an object name to some information such as other alias names, routableprefixesprefixes, and locators, which are used for forwarding the content request. Thus, a publisher or producer ofcontentscontent creates an NRS registration request and sends it to an NRS server. On registration, the NRS server stores (or updates) the name mapping record in the database and sends an acknowledgement back to the producer or publisher that made the registration request.</t> <t> Name</dd> <dt>Name resolution:Name</dt> <dd>Name resolution is the main function of the NRS system. It is performed by an NRSresolverresolver, which can be deployed on a consumer node or an ICN router. Resolvers are responsible for either returning a cached mapping record (whose lifetime has notexpiredexpired) or alternatively sending a name resolution request toward an NRS server. The NRS server searches for the content name in its mapping recorddatabase, anddatabase and, if found, retrieves the mapping record and returns it in a name resolution response message to the NRS resolver.</t> <t> NRS</dd> <dt>NRS node:NRS</dt> <dd>NRS servers are also referred to as NRS nodes that maintain the name records. The terms are used interchangeably.</t> <t> NRS</dd> <dt>NRS client:A</dt> <dd>A node that uses the NRS is called an NRS client. Any node that initiates a name registration, resolution, or update procedure is an NRSclient. Thatclient; that is, NRS resolvers, ICN client nodes, ICN routers, or producers can be NRS clients.</t> </list> </t></dd> </dl> </section> <sectiontitle="Background">numbered="true" toc="default" anchor="background"> <name>Background</name> <t> A pure name-based routing approach in ICN has inherent challenges in enabling a globally scalable routing system, accommodating producer mobility, and supporting off-path caching. In order to address these challenges, an NRS has been utilized in proposals and literature of several ICN projects as follows: </t><t> <list style="symbols"> <t> Routing<dl> <dt>Routing scalability:In</dt> <dd>In ICN, application names identifyingcontentscontent are intended to be used directly for packet delivery, so ICN routers run a name-based routing protocol to build name-based routing and forwarding tables. Similar to the scalability challenge of IP routing, if non-aggregatable name prefixes are injected into the Default Route Free Zone (DFZ) of ICN routers, they would be driving the uncontrolled growth of the DFZ routing table size. Thus, providing the level of indirection enabled by an NRS in ICN can be an approach to keeping the routing table size under control. The NRS system resolves name prefixeswhichthat do not exist in the DFZ forwarding table into globally routable prefixes such as the one proposed in NDN <xreftarget="Afanasyev"></xref>.target="Afanasyev" format="default"/>. Another approach dealing with routing scalability is the Multi-level Distributed Hash Table (MDHT) used in NetInf <xreftarget="Dannewitz"></xref>.target="Dannewitz" format="default"/>. It provides name-based anycast routing that can support a non-hierarchical namespace and can be adopted on a global scale <xreftarget="Dannewitz2"></xref>. </t> <t> Producertarget="Dannewitz2" format="default"/>. </dd> <dt>Producer mobility:In</dt> <dd>In ICN, if a producer moves into a different name domain that uses a different name prefix, the request for a content produced by the moving producer with the origin content name must be forwarded to the moving producer's new location. Especially in a hierarchical naming scheme, producer mobility support is much harder than in a flat naming scheme since the routing tables in a broader area need to be updated to track the producer movement. Therefore, various ICN architectures such as NetInf <xreftarget="Dannewitz"></xref>target="Dannewitz" format="default"/> and MobilityFirst <xreftarget="MF"></xref>target="MF" format="default"/> have adopted NRS systems to tackle the issues of producers whose location changes.</t> <t> Off-path</dd> <dt>Off-path caching:In-network</dt> <dd>In-network caching is a common feature of an ICN architecture. Caching approaches can be categorized into on-path caching and off-path caching, according to the location of caches in relation to the forwarding path from the original content store to a consumer. Off-path caching, sometimes also referred to as content replication or content storing, aims to replicate a Named Data Object in various locations within a network in order to increase the availability ofcontents,content, reduce access latency, or both. These caching locations may not be lying along the content forwarding path. Thus, finding off-path cachedcontentscontent requires more complex forwarding procedures if a pure name-based routing is employed. In order to support access to off-path caches, the locations of replicas are usually advertised into a name-based routing system or into an NRS as described in <xreftarget="Bayhan"></xref>. </t> </list> </t>target="Bayhan" format="default"/>. </dd> </dl> <t> This document discusses architectural considerations and implications of ICN when an NRS is utilized to solve such challenges facing a name-based routing in ICN. </t> </section> <sectiontitle="Implicationsnumbered="true" toc="default"> <name>Implications of an NRS inICN">ICN</name> <t> An NRS is not a mandatory part of an ICN architecture, as the majority of ICN architectures uses name-based routing that avoids the need for a name resolution procedure. Therefore, the utilization of an NRS in an ICN architecture changes some architectural aspects at least with respect to forwarding procedures, latency, and security, as discussed below: </t><t> <list style="symbols"> <t>Forwarding<dl> <dt>Forwarding procedure:When</dt> <dd>When an NRS is included in an ICN architecture, the name resolution procedure has to be included in the ICN overall routing and forwarding architectural procedures. To integrate an NRS into an ICN architecture, there are certain things that have to be decided and specified such as where,whenwhen, and how the name resolution task is performed.</t> <t>Latency: When</dd> <dt>Latency: </dt> <dd>When an NRS is included in an ICN architecture, additional latency introduced by the name resolution process is incurred by the routing and forwarding system. Although the latency due to the name resolution is added, the total latency of individual requests being served could be lower if the nearest copies or off-path caches can be located by the NRS lookup procedure. Additionally, there might be a favorable trade-off between the name resolution latency and inter-domain traffic reduction by finding the nearest off-path cached copy of the content. Finding the nearest cache holding the content might significantly reduce the content discovery as well as delivery latency.</t> <t>Security: When</dd> <dt>Security: </dt> <dd>When any new component such as an NRS is introduced in the ICN architecture, the attack surface may increase. Protection of the NRS system itself against attacks such as Distributed Denial of Service (DDoS) and spoofing or alteration of name mapping records and related signaling messages may be challenging.</t> </list> </t></dd> </dl> </section> <sectiontitle="ICNnumbered="true" toc="default"> <name>ICN Architectural Considerations forNRS">NRS</name> <t> This section discusses the various items that can be considered from the perspective of ICN architecture when employing an NRS system. These items are related to the registration, resolution, and update of name mapping records, protocols and messages, and integration with the routing system. </t> <sectiontitle="Name mapping records registration, resolution,numbered="true" toc="default"> <name>Name Mapping Records Registration, Resolution, andupdate">Update</name> <t> When an NRS is integrated in ICN architecture, the functions related to the registration,resolutionresolution, and update of name mapping records have to be considered. The NRS nodes maintain the name mapping records and may exist as an overlay network over the ICN routers, that is, they communicate to each other through ICN routers.Figure 1<xref target="rl-fig1"/> shows the NRS nodes and NRS clients connected through an underlying network. The NRS nodes should be deployed in such a manner that an NRS node is always available at a short distance from an NRS client so that communication latency for the name registration and resolution requested by the NRS client remains very low. The name registration, nameresolutionresolution, and name record update procedures are briefly discussed below. </t> <figureanchor="rl-fig1" title="NRS nodesanchor="rl-fig1"> <name>NRS Nodes and NRSclients connectedClients Connected through anunderlying network">Underlying Network</name> <artworkalign="center">align="center" name="" type="" alt=""><![CDATA[ +------------+ +------------+ | NRS Node | | NRS Node | +------------+ +------------+ | | | | +------------+ | | +------------+ | NRS Client |--------------------------------------| NRS Client | +------------+ underlying network +------------+</artwork> <postamble> </postamble>]]></artwork> </figure><t> <list style="symbols"> <t> Name<t keepWithPrevious="true"/> <dl> <dt>Name registration:Name</dt> <dd>Name registration is performed by the producer (as an NRS client) when it creates a new content. When a producer creates content and assigns a name from its name prefix space to the content, the producer performs the name registration in an NRS node. Name registration may be performed by an ICN router when the ICN architecture supports off-path caching or cooperative caching since involving an NRS may be a good idea for off-path caching. The ICN routers with forwarder caches do not require name registration for their cached content because they lie on the path toward an upstream content store or producer. They will be hit when a future request is forwarded to the content producer by an ICN router lying downstream toward the ICN client node. However, ICN routers performing off-path caching of content must invoke the name registration procedure so that other ICN routers can depend on name resolutions to know about the off-path cache locations. If a content gets cached in many off-path ICN routers, all of them may register the same content names in the same NRS node, resulting in multiple registration actions. In this case, the NRS node adds the new location of the content to the name record together with the previous locations. In this way, each of the name records stored in the NRS node may contain multiple locations of the content. Assigning validity time or a lifetime of each mapping record may be considered especially for the off-path cachingcontentscontent and managing mobility.</t> <t> Name</dd> <dt>Name resolution:Name</dt> <dd>Name resolution is performed by an NRS client to obtain the name record from an NRS node by sending a name resolution request message and getting a response containing the record. In the name-based ICN routing context, the name resolution is needed by any ICN router whose forwarding information base (FIB) does not contain the requested name prefix. Name resolution may also be performed by the consumer (especially in the case where the consumer is multihomed) to forward the content request in a better direction so that it obtains the content from the nearest cache. If the consumer is single homed, it may not bother to perform name resolution, instead depending on either straightforward name-based routing or name resolution by an upstream ICN router.OnIn this case, the consumer creates the content request packet containing the content name and forwards to the nearest ICN router. The ICN router checks its FIB table to see where to forward the content request. If the ICN router fails toknowidentify whether the requested content is reachable, it performs name resolution to obtain the name mapping record and adds this information to its FIB. The ICN router may also perform name resolution even before the arrival of a content request to use the name mapping record to configure its FIB.</t> <t> Name</dd> <dt>Name record update:Name</dt> <dd>Name record update is carried out when a content name mapping record changes,e.g.e.g., the content is not available in one or more of the previous locations. The name record update includes the substitution and deletion of the name mapping records. The name record update may take place explicitly by the exchange of name record update messages or implicitly when a timeout occurs and a name record is deemed to be invalid. The implicit update is possible when each record is accompanied by a lifetime value. The lifetime can be renewed only by the authoritative producer or node. The cached mapping records get erased after the lifetime expires unless a lifetime extension indication is obtained from the authoritative producer.</t> </list> </t> <!-- <t> The name resolution in ICN can be performed by consumer, routers, or both. Once it is decided where the name resolution will take place, it has to be considered how the name resolution will be performed. The name provided by a consumer might be always resolved to identifiers in a differnet namespace just like a DNS lookup. Conversely, an NRS is always needed to map names to a different namespace. </t> --></dd> </dl> </section> <sectiontitle="Protocolsnumbered="true" toc="default"> <name>Protocols andSemantics">Semantics</name> <t> In order to develop an NRS system within a local ICN network domain or global ICN network domain, new protocols and semantics must be designed and implemented to manage and resolve names among differentname spaces.namespaces. </t> <t> One way of implementing an NRS for CCNx is by extending the basic TLV format and semantics <xreftarget="RFC8569"></xref>target="RFC8569" format="default"/> <xreftarget="RFC8609"></xref>.target="RFC8609" format="default"/>. For instance, name resolution and response messages can be implemented by defining new type fields in the Interest and Content Object messages <xreftarget="CCNxNRS"></xref>.target="I-D.hong-icnrg-ccnx-nrs" format="default"/>. By leveraging the existing CCNx Interest and Content Object packets for name resolution and registration, the NRS system can be deployed with a few ICN protocol changes. However, because of confining the changes to the basic ICN protocol and semantics, the NRS system may not be able to exploit more flexible and scalable designs. </t> <t> On the other hand, an NRS system can be designed independently with its own protocol and semantics like the NRS system described in <xreftarget="Hong"></xref>.target="Hong" format="default"/>. For instance, the NRS protocol and messages can be implemented by using a RESTfulAPIAPI, and the NRS can be operated as an application protocol independent of the rest of the ICN protocol. </t> </section> <sectiontitle="Routing System">numbered="true" toc="default"> <name>Routing System</name> <t> An NRS reduces the routing complexity of ICN architecture compared to pure name-based routing. It does so by permitting the routing system to update the routing table on demandthroughwith the help of name records obtained from NRS. The routing system therefore needs to make name resolution requests and process the information returned, such as a prefix, a locator, an off-path-cache pointer, or an alias name, obtained from the name resolution. </t> <t> No matter what kind of information is obtained from the name resolution, as long as it is in the form of a name, the content request message in the routing system may be reformatted with the obtained information. In this case, the content name requested originally by a consumer needs to be involved in the reformatted content request to check the integrity of the binding between the name and the requested content. In other words, the information obtained from the name resolution is used to forward the contentrequestrequest, and the original content name requested by a consumer is used to identify the content. Alternatively, the resolved information may be used to build the routing table. </t> <t> The information obtained from name resolution may not be in the form of a name. For example, it may identify tunnel endpoints by IP address and instead be used to construct an IP protocol tunnel through which to forward the content request. </t> </section> </section> <sectiontitle="Conclusion">numbered="true" toc="default"> <name>Conclusion</name> <t> A Name Resolution Service (NRS) is not a mandatory part in an ICN architecture, as the majority of ICN architectures use name-based routingwhichthat does not employ a name resolution procedure. However, such name-based routing in ICN has inherent challenges in enabling a globally scalable routing system, accommodating producer mobility, and supporting off-path caching. In order to address these challenges, an NRS system has been introduced in several ICN projects. Therefore, this document describes how the ICN architecture changes when an NRS is utilized and how this affects the ICN routing system. </t> <t> The document defines a few terminologies related to an NRS and explains some inherent challenges of pure name-based routing in ICN such as routing scalability, producer mobility, and off-path caching. This document describes how the ICN architecture would change with respect to procedures, latency, and security when an NRS is utilized. According to the ICN architectural changes, this document describes ICN architectural considerations for NRS such as the functions related to the registration, resolution and update of name mapping records, protocols and semantics to implement an NRS system, and the routing system involving the name resolution. </t> </section> <section anchor="IANA"title="IANA Considerations"> <t>There arenumbered="true" toc="default"> <name>IANA Considerations</name> <t>This document has no IANAactions required by this document.</t>actions.</t> </section> <sectiontitle="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <t> When any new component such as an NRS is introduced in the ICN architecture, the attack surface increases. The related security vulnerability issues are discussed below: </t><t> <list style="symbols"> <t> Name space<dl> <dt>Namespace security:In</dt> <dd>In order to deploy an NRS system in ICN architecture, ICNname spaces,namespaces, which may be assigned by authoritative entities, must be securely mapped to the content publishers and securely managed by them. According to the ICN research challenges[RFC7927],<xref target="RFC7927" format="default"/>, a newname spacenamespace can also provide an integrity verification function to authenticate its publisher. The issues of namespace authentication and the mapping among differentname spacesnamespaces require further investigation.</t> <t> NRS</dd> <dt>NRS system security:An</dt> <dd>An NRS requires the deployment of new entities(e.g.(e.g., NRS servers) to build distributed and scalable NRS systems. Thus, the entities, e.g., an NRS server maintaining a mapping database, could be the focus of attacks by receiving malicious requests from innumerable adversaries comprisinga DenialofServiceDenial-of-Service orDistributed Denial of serviceDistributed-Denial-of-Service attacks. In addition, NRS clients in general must trust the NRS nodes in other network domains to somedegreedegree, and communication among them must also be protected securely to prevent malicious entities from participating in this communication. The history of name resolution data requires to be stored and analyzed as in passive DNS to uncover potential security incidents or discover malicious infrastructures.</t> <t> NRS</dd> <dt>NRS protocol and message security:In</dt> <dd>In an NRS system, the protocols to generate,transmittransmit, and receive NRS messages related to the name registration, resolution, and record update should be protected by proper security mechanisms. Proper security measures must be provided so that only legitimate nodes can initiate and read NRS messages. These messages musthavebe secured by integrity protection and authenticationmechanismmechanisms so that unauthorized parties cannot manipulate them when being forwarded through the network. Security measures to encrypt these messages should also be developed to thwart all threats to both security and privacy. Numerous problems similar to the security issues of an IP network and DNS can affect the overall ICN architecture. The DNS QNAME minimization type of approach would be suitable for preserving privacy in the name resolution process. Therefore, security mechanisms such as accessibility, authentication, etc., for the NRS system <xreftarget="RFC9138"></xref>target="RFC9138" format="default"/> should be considered to protect not only the NRSsystem,system but also the ICN architecture overall.</t> </list> </t></dd> </dl> </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="Normative References"> &rfc2119; &rfc7927; <reference anchor='RFC8569'> <front> <title>Content-Centric Networking (CCNx) Semantics</title> <author initials='M.' surname='Mosko' fullname='M. Mosko'></author> <author initials='I.' surname='Solis' fullname='I. Solis'></author> <author initials='C.' surname='Wood' fullname='C. Wood'></author> <date month='July' year='2019' /> </front> <seriesInfo name='https://www.rfc-editor.org/info/rfc8569' value='' /> </reference> <reference anchor='RFC8609'> <front> <title>CCNx Messages in TLV Format </title> <author initials='M.' surname='Mosko' fullname='M. Mosko'></author> <author initials='I.' surname='Solis' fullname='I. Solis'></author> <author initials='C.' surname='Wood' fullname='C. Wood'></author> <date month='July' year='2019' /> </front> <seriesInfo name='https://www.rfc-editor.org/info/rfc8609' value='' /> </reference> <reference anchor='RFC9138'> <front> <title>Design Considerations for Name Resolution Service in Information-Centric Networking (ICN)</title> <author initials='' surname='Hong, J. et al.' fullname='J. Hong et al' ></author> <date month='November' year='2021' /> </front> <seriesInfo name='https://www.rfc-editor.org/info/rfc9138' value='' /> </reference><displayreference target="I-D.ravi-icnrg-ccn-forwarding-label" to="Ravindran"/> <displayreference target="I-D.hong-icnrg-ccnx-nrs" to="CCNxNRS"/> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7927.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8569.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8609.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9138.xml"/> </references><references title="Informative References"><references> <name>Informative References</name> <referenceanchor='NDN'>anchor="NDN" target="https://www.named-data.net"> <front><title>NSF Named<title>Named DataNetworking project.</title> <author initials='' surname='' fullname=''></author>Networking</title> <author> <organization>NDN</organization> </author> <datemonth='' year='' />month="September" year="2010"/> </front><seriesInfo name='http://www.named-data.net' value='' /></reference> <referenceanchor='CCNx'>anchor="CCNx" target="https://wiki.fd.io/view/Cicn"> <front><title>Content Centric Networking project.</title> <author initials='' surname='' fullname=''></author> <date month='' year='' /><title>Cicn</title> <author> <organization/> </author> <date/> </front><seriesInfo name='https://wiki.fd.io/view/Cicn' value='' /></reference> <referenceanchor='Afanasyev'>anchor="Afanasyev"> <front> <title>SNAMP: SecureNamespace Mappingnamespace mapping toScalescale NDNForwarding </title>forwarding</title> <authorinitials='' surname='Afanasyev, A. et al.' fullname='A. Afanasyev et al' ></author>initials="A." surname="Afanasyev" fullname="Alexander Afanasyev"/> <author initials="C." surname="Yi" fullname="Cheng Yi"/> <author initials="L." surname="Wang" fullname="Lan Wang"/> <author initials="B." surname="Zhang" fullname="Beichuan Zhang"/> <author initials="L." surname="Zhang" fullname="Lixia Zhang"/> <datemonth='April' year='2015' />month="April" year="2015"/> </front> <refcontent>2015 IEEE Conference on Computer Communications Workshops (INFOCOM WKSHPS)</refcontent> <seriesInfoname='IEEE Global Internet Symposium' value='' />name="DOI" value="10.1109/INFCOMW.2015.7179398"/> </reference> <referenceanchor='Zhang2'>anchor="Zhang2"> <front> <title>A Survey of Mobility Support in Named Data Networking</title> <authorinitials='Y.' surname='Zhang' fullname='Y. Zhang et al.'></author> <date month='' year='2016' /> </front> <seriesInfo name='NAMED-ORIENTED MOBILITY: ARCHITECTURES, ALGORITHMS, AND APPLICATIONS(NOM)' value='' /> </reference> <reference anchor='Ravindran'> <front> <title>Forwarding-Label support in CCN Protocol </title>initials="Y." surname="Zhang" fullname="Yu Zhang"/> <author initials="A." surname="Afanasyev" fullname="Alexander Afanasyev"/> <authorinitials='' surname='Ravindran, R. et al.' fullname='R. Ravindran et al' ></author>initials="J." surname="Burke" fullname="Jeff Burke"/> <author initials="L." surname="Zhang" fullname="Lixia Zhang"/> <datemonth='July' year='2017' />month="April" year="2016"/> </front><seriesInfo name='draft-ravi-icnrg-ccn-forwarding-label-01' value='' /><refcontent>Named Data Networking</refcontent> <refcontent>Workshop on Name-Oriented Mobility: Architecture, Algorithms and Applications (NOM)</refcontent> </reference> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ravi-icnrg-ccn-forwarding-label.xml"/> <referenceanchor='SAIL'>anchor="SAIL" target="https://www.sail-project.eu/"> <front><title>FP7 SAIL project.</title> <author initials='' surname='' fullname=''></author> <date month='' year='' /><title>Scalable and Adaptive Internet Solutions (SAIL)</title> <author/> </front><seriesInfo name='http://www.sail-project.eu/' value='' /></reference> <referenceanchor='MF'>anchor="MF" target="http://mobilityfirst.cs.umass.edu/"> <front><title>NSF Mobility First project.</title> <author initials='' surname='' fullname=''></author> <date month='' year='' /><title>MobilityFirst</title> <author> <organization>Future Internet Architecture (FIA)</organization> </author> <date/> </front><seriesInfo name='http://mobilityfirst.winlab.rutgers.edu/' value='' /></reference> <referenceanchor='Bayhan'>anchor="Bayhan"> <front> <title>On Content Indexing for Off-Path Caching in Information-Centric Networks </title> <authorinitials='' surname='Bayhan, S. et al.' fullname='S. Bayhan et al' ></author> <date month='September' year='2016' /> </front> <seriesInfo name='ACM ICN' value='' /> </reference> <reference anchor='CCNxNRS'> <front> <title>CCNx Extension for Name Resolution Service</title>initials="S." surname="Bayhan" fullname="Suzan Bayhan"/> <author initials="" surname="" fullname="Liang Wang"/> <authorinitials='' surname='Hong, J. et al.' fullname='J. Hong et al.' ></author>initials="J." surname="Ott" fullname="Jörg Ott"/> <author initials="J." surname="Kangasharju" fullname="Jussi Kangasharju"/> <author initials="A." surname="Sathiaseelan" fullname="Arjuna Sathiaseelan"/> <author initials="J." surname="Crowcroft" fullname="Jon Crowcroft"/> <datemonth='July' year='2018' />month="September" year="2016"/> </front> <refcontent>ACM ICN</refcontent> <seriesInfoname='draft-hong-icnrg-ccnx-nrs-02' value='' />name="DOI" value="10.1145/2984356.2984372"/> </reference> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.hong-icnrg-ccnx-nrs.xml"/> <referenceanchor='Hong'>anchor="Hong"> <front> <title>Demonstrating a Scalable Name Resolution System for Information-Centric Networking </title> <authorinitials='J.' surname='Hong' fullname='J. Hong' ></author> <author initials='W.' surname='Chun' fullname='W. Chun' ></author> <author initials='H.' surname='Jung' fullname='H. Jung' ></author> <date month='September' year='2015' /> </front> <seriesInfo name='ACM ICN' value='' /> </reference> <!-- <reference anchor='Jung'> <front> <title>IDNet: Beyond All-IP Network</title> <author initials='' surname='Jung, H. et al.' fullname='H. Jung et al.' ></author> <date month='October' year='2015' /> </front> <seriesInfo name='ETRI Jouranl' value='vol. 37, no. 5' /> </reference> <reference anchor='Jacobson'> <front> <title>Networking Named Content</title> <author initials='V.' surname='Jacobson' fullname='V. Jacobson'></author> <author initials='D. K.' surname='Smetters' fullname='D. K. Smetters'></author> <author initials='J. D.' surname='Thornton' fullname='J. D. Thornton'></author> <author initials='M. F.' surname='Plass' fullname='M. F. Plass'></author> <author initials='N. H.' surname='Briggs' fullname='N. H. Briggs'></author> <author initials='R. L.' surname='Braynard' fullname='R. L. Braynard'></author> <date month='' year='2009' /> </front> <seriesInfo name='ACM CoNEXT' value='' /> </reference> <reference anchor='Baid'> <front> <title>Comparing Alternative Approaches for Networking of Named Objects in the Future Internet</title> <author initials='A.' surname='Baid' fullname='A. Baid'></author> <author initials='T.' surname='Vu' fullname='T. Vu'></author> <author initials='D.' surname='Raychaudhuri' fullname='D. Raychaudhuri'></author> <date month='' year='2012' /> </front> <seriesInfo name='IEEE Workshop on Emerging Design Choices in Name-Oriented Networking (NOMEN)' value='' /> </reference> <reference anchor='Bari'> <front> <title>A Survey of Naming and Routing in Information-Centric Networks</title> <author initials='M. F.' surname='Bari' fullname='M. F. Bari'></author> <author initials='S. R.' surname='Chowdhury' fullname='S. R. Chowdhury'></author> <author initials='R.' surname='Ahmed' fullname='R. Ahmed'></author> <author initials='R.' surname='Boutaba' fullname='R. Boutaba'></author> <author initials='B.' surname='Mathieu' fullname='B. Mathieu'></author> <date month='' year='2012' /> </front> <seriesInfo name='IEEE Communications Magazine' value='Vol. 50, No. 12, P.44-53' /> </reference> <reference anchor='Rajahalme'> <front> <title>On Name-based Inter-domain Routing</title> <author initials='J.' surname='Rajahalme' fullname='J. Rajahalme'></author> <author initials='M.' surname='Sarela' fullname='M. Sarela'></author> <author initials='K.' surname='Visala' fullname='K. Visala'></author> <author initials='J.' surname='Riihijarvi' fullname='J. Riihijarvi'></author> <date month='March' year='2011' /> </front> <seriesInfo name='Computer Networks' value='Vol. 55, No. 4, P. 975-986' /> </reference> <reference anchor='Katsaros'> <front> <title>On Inter-Domain Name Resolution for Information-Centric Networks</title> <author initials='K. V.' surname='Katsaros' fullname='K. V. Katsaros'></author> <author initials='N.' surname='Fotiou' fullname='N. Fotiou'></author> <author initials='X.' surname='Vasilakos' fullname='X. Vasilakos'></author> <author initials='C. N.' surname='Ververidis' fullname='C. N. Ververidis'></author> <author initials='C.' surname='Tsilopoulos' fullname='C. Tsilopoulos'></author> <author initials='G.' surname='Xylomenos' fullname='G. Xylomenos'></author> <author initials='G. C.' surname='Polyzos' fullname='G. C. Polyzos'></author> <date month='' year='2012' /> </front> <seriesInfo name='Proc.IFIP-TC6 Networking Conference' value='' /> </reference> <reference anchor='ID.Wang'> <front> <title>Namespace Resolution in Future Internet Architectures</title> <author initials='J.' surname='Wang' fullname='J. Wang'></author> <author initials='S.' surname='Li' fullname='S. Li'></author> <author initials='C.' surname='Wetphal' fullname='C. Wetphal'></author> <date month='October' year='2015' /> </front> <seriesInfo name='draft-wang-fia-namespace-01' value='' /> </reference> <reference anchor='ID.Zhang'> <front> <title>PID: A Generic Naming Schema for Information-centric Network</title> <author initials='X.' surname='Zhang' fullname='X. Zhang'></author> <author initials='R.' surname='Ravindran' fullname='R. Ravindran'></author> <author initials='H.' surname='Xie' fullname='H. Xie'></author> <author initials='G.' surname='Wang' fullname='G. Wang'></author> <date month='August' year='2013' /> </front> <seriesInfo name='draft-zhang-icnrg-pid-naming-scheme-03' value='' /> </reference> <reference anchor='D.Zhang'> <front> <title>Routing and Name Resolution in Information-Centric Networks</title> <author initials='D.' surname='Zhang' fullname='D. Zhang'></author> <author initials='H.' surname='Liu' fullname='H. Liu'></author> <date month='' year='2013' /> </front> <seriesInfo name='22nd International Conference on Computer Communications and Networks (ICCCN)' value='' /> </reference> <reference anchor='Sevilla'> <front> <title>iDNS: Enabling Information Centric Networking Through The DNS</title> <author initials='S.' surname='Sevilla' fullname='S. Sevilla'></author> <author initials='P.' surname='Mahadevan' fullname='P. Mahadevan'></author> <author initials='J.' surname='Garcia-Luna-Aceves' fullname='J. Garcia-Luna-Aceves'></author> <date month='' year='2014' /> </front> <seriesInfo name='Name Oriented Mobility (workshop co-located with Infocom 2014)' value='' /> </reference> &rfc1498; <reference anchor='oneM2M'> <front> <title>oneM2M Functional Architecture TS 0001.</title> <author initials='' surname='' fullname=''></author> <date month='' year='' /> </front> <seriesInfo name='http://www.onem2m.org/technical/published-documents.' value='' /> </reference> &rfc7252; <reference anchor='ID.Shelby'> <front> <title>CoRE Resource Directory</title> <author initials='Z.' surname='Shelby' fullname='Z. Shelby'></author> <date month='March' year='2017' /> </front> <seriesInfo name='draft-ietf-core-resource-directory-10' value='' /> </reference> <reference anchor='CoRE'> <front> <title>Constrained RESTful Environments, CoRE</title> <author initials='' surname='' fullname=''></author> <date month='March' year='2013' /> </front> <seriesInfo name='https://datatracker.ietf.org/wg/core/charter/' value='' /> </reference> <reference anchor='Westphal'> <front> <title>An IP-based Manifest Architecture for ICN</title> <author initials='C.' surname='Westphal' fullname='C. Westphal'></author> <author initials='E.' surname='Demirors' fullname='E. Demirors'></author> <date month='' year='2015' /> </front> <seriesInfo name='ACM ICN' value='' /> </reference> <reference anchor='Mosko'> <front> <title>CCNx Manifest Specification</title> <author initials='M.' surname='Mosko' fullname='M. Mosko'></author> <author initials='G.' surname='Scott' fullname='G. Scott'></author> <author initials='I.' surname='Solis' fullname='I. Solis'></author>initials="J." surname="Hong" fullname="J. Hong"/> <authorinitials='C.' surname='Wood' fullname='C. Wood'></author> <date month='July' year='2015' /> </front> <seriesInfo name='draft-wood-icnrg-ccnxmanifests-00' value='' /> </reference> --> <!-- &rfc6830; &rfc6833; --> <!-- <reference anchor='Zhang'> <front> <title>Named data networking</title>initials="W." surname="Chun" fullname="W. Chun"/> <authorinitials='' surname='Zhang, L. et al.' fullname='L. Zhang et al.'></author>initials="H." surname="Jung" fullname="H. Jung"/> <datemonth='July' year='2014' />month="September" year="2015"/> </front> <refcontent>ACM ICN</refcontent> <seriesInfoname='ACM SIGCOMM Computer Communication Review' value='vol. 44, no. 3' />name="DOI" value="10.1145/2810156.2812617"/> </reference> <referenceanchor='Zhang2'>anchor="Dannewitz"> <front><title>A Survey of Mobility Support in Named Data Networking</title> <author initials='Y.' surname='Zhang' fullname='Y. Zhang et al.'></author> <date month='' year='2016' /> </front> <seriesInfo name='NAMED-ORIENTED MOBILITY: ARCHITECTURES, ALGORITHMS, AND APPLICATIONS(NOM)' value='' /> </reference> --> <reference anchor='Dannewitz'> <front> <title> Network<title>Network of Information(NetInf)-An information centric(NetInf) – An information-centric networkingarchitecture </title>architecture</title> <authorinitials='' surname='Dannewitz, C. et al.' fullname='C. Dannewitz et al.' ></author> <date month='April' year='2013' /> </front> <seriesInfo name='Computer Communications' value='vol.initials="" surname="" fullname="ChristianDannewitz"/> <author initials="" surname="" fullname="Dirk Kutscher"/> <author initials="" surname="" fullname="Börje Ohlman"/> <author initials="" surname="" fullname="Stephen Farrell"/> <author initials="" surname="" fullname="Bengt Ahlgren"/> <author initials="" surname="" fullname="Holger Karl"/> <date month="April" year="2013"/> </front> <seriesInfo name="Computer Communications" value="vol. 36,no. 7' /> </reference> <!-- <reference anchor='Seskar'> <front> <title>MobilityFirst Future Internet Architecture Project</title> <author initials='I.' surname='Seskar' fullname='I. Seskar' ></author> <author initials='K.' surname='Nagaraja' fullname='K. Nagaraja' ></author> <author initials='S.' surname='Nelson' fullname='S. Nelson' ></author> <author initials='D.' surname='Raychaudhuri' fullname='D. Raychaudhurin' ></author> <date month='November' year='2011' /> </front>issue 7"/> <seriesInfoname='7th Asian Internet Engineering Conference' value='' />name="DOI" value="10.1016/j.comcom.2013.01.009"/> </reference>--><referenceanchor='Dannewitz2'>anchor="Dannewitz2"> <front> <title>Hierarchical DHT-based name resolution forInformation-Centric Networks</title> <author initials='C.' surname='Dannewitz' fullname='C. Dannewitz' ></author>information-centric networks</title> <authorinitials='M.' surname='DAmbrosio' fullname='M. DAmbrosio' ></author>initials="C." surname="Dannewitz" fullname="Christian Dannewitz"/> <author initials="M." surname="D'Ambrosio" fullname="Matteo D’Ambrosio"/> <authorinitials='V.' surname='Vercellone' fullname='V. Vercellone' ></author>initials="V." surname="Vercellone" fullname="Vinicio Vercellone"/> <datemonth='April' year='2013' />month="April" year="2013"/> </front> <seriesInfoname='Computer Communications' value='vol.name="Computer Communications" value="vol. 36,no. 7' /> </reference> <!-- <reference anchor='Vu'> <front> <title>DMap: A Shared Hosting Scheme for Dynamic Identifier to Locator Mapping in the Global Internet </title> <author initials='' surname='Vu, T. et al.' fullname='T. Vu et al' ></author> <date month='' year='2012' /> </front>issue 7"/> <seriesInfoname='IEEE 32nd International Conference on Distributed Computing Systems' value='' />name="DOI" value="10.1016/j.comcom.2013.01.014"/> </reference><reference anchor='Hong'> <front> <title>Demonstrating a Scalable Name Resolution System for Information-Centric Networking </title> <author initials='J.' surname='Hong' fullname='J. Hong' ></author> <author initials='W.' surname='Chun' fullname='W. Chun' ></author> <author initials='H.' surname='Jung' fullname='H. Jung' ></author> <date month='September' year='2015' /> </front> <seriesInfo name='ACM ICN' value='' /> </reference> <reference anchor='Ravindran'> <front> <title>Forwarding-Label support in CCN Protocol </title> <author initials='' surname='Ravindran, R. et al.' fullname='R. Ravindran et al' ></author> <date month='July' year='2017' /> </front> <seriesInfo name='draft-ravi-icnrg-ccn-forwarding-label-01' value='' /> </reference> <reference anchor='Mosko2'> <front> <title>Nameless Objects </title> <author initials='M.' surname='Mosko' fullname='M. Mosko' ></author> <date month='July' year='2015' /> </front> <seriesInfo name='' value='' /> </reference> --></references> </references> <sectionanchor="Acknowledgments" title="Acknowledgements"anchor="Acknowledgements" numbered="false" toc="include"> <name>Acknowledgements</name> <t> The authors would like to thankDave Oran<contact fullname="Dave Oran"/> (ICNRG Co-chair) for very useful reviews andcomments on the document and theycomments, which helped to immeasurably improvethethis document. </t> </section> </back> </rfc><!-- < </reference> title>Networking named content</title> <sInfo name='IEEE Network' value='vol. 30, no. 2' /> </reference> &id.draft-winter-energy-efficient-internet; </reference> &id.draft-cheshire-edns0-owner-option; <reference anchor='ITU'> <front> <title>Resolution 73 - Information and communication technologies and climate change</title> <author></author> <date month='October' year='2008' /> </front> </reference> <reference anchor='EPC'> <front> <title>The Case for Energy-Proportional Computing</title> <author initials='L.' surname='Barroso' fullname='Luiz Andre Barroso'></author> <author initials='U.' surname='Holzle' fullname='Urs Holzle'></author> <date month='December' year='2007'/> </front> <seriesInfo name='Proc. IEEE International Conference on Network Protocols (ICNP)' value=''/> </reference> <reference anchor='GreenSurvey'> <front> <title>A survey of green networking research</title> <author initials='A.P.' surname='Bianzino' fullname='Aruna Prem Bianzino'></author> <author initials='C.' surname='Chaudet' fullname='Claude Chaudet'></author> <author initials='D.' surname='Rossi' fullname='Dario Rossi'></author> <author initials='J.-L.' surname='Rougier' fullname='Jean-Louis Rougier'></author> <date month='' year='2012' /> </front> <seriesInfo name='IEEE Communications Surveys Tutorials' value='' /> </reference> <reference anchor='EEE'> <front> <title>802.3az-2010</title> <author></author> <date month='' year='2010' /> </front> <seriesInfo name='IEEE std' value='' /> </reference> <reference anchor='PROXZZZY'> <front> <title>ProxZZZy for sleeping hosts</title> <author></author> <date month='June' year='2012' /> </front> <seriesInfo name='ECMA International' value='ECMA-393' /> </reference> <reference anchor='EEEC'> <front> <title>Improving the Energy Efficiency of Ethernet-Connected: A Proposal for Proxying</title> <author initials='B.' surname='Nordman' fullname='Bbuce Nordman'></author> <author initials='K.' surname='Christensen' fullname='Ken Christensen'></author> <date month='September' year='2007' /> </front> <seriesInfo name='Ethernet Alliance' value='' /> </reference> <reference anchor='NCP'> <front> <title>A Network Connection Proxy to Enable Hosts to Sleep and Save Energy</title> <author initials='M.' surname='Jimeno' fullname='M. Jimeno'></author> <author initials='K.' surname='Christensen' fullname='K. Christensen'></author> <author initials='B.' surname='Nordman' fullname='B. Nordman'></author> <date month='' year='2008' /> </front> <seriesInfo name='Proc. IEEE Internat. Performance Computing and Communications Conf' value='' /> </reference> <reference anchor='SKILL'> <front> <title>Skilled in the Art of Being Idle: Reducing Energy Waste in Networked Systems</title> <author initials='S.' surname='Nedevschi' fullname='S. Nedevschi'></author> <author initials='J.' surname='Liu' fullname='J. Liu'></author> <author initials='B.' surname='Nordman' fullname='B. Nordman'></author> <author initials='S.' surname='Ratnasamy' fullname='S. Ratnasamy'></author> <author initials='N.' surname='Taft' fullname='N. Taft'></author> <date month='' year='2009' /> </front> <seriesInfo name='Proc. USENIX Symposium on Networked Systems Design and Implementation' value='' /> </reference> -->