Information Centric Networking over SDN and OpenFlow: Architectural Aspects and Experiments on the OFELIA Testbed

1. Introduction

• ICN deployment may require replacing or updating running equipment, while SDN is presented as an opportunity to support ICN without deploying new ICN-capable hardware.The paper also motivates SDN by its promise to enable continuous evolution of networking architectures.Source: §1 · p. 2
• CONET addresses the scale of content names by confining routing to Name Routing System nodes, which instruct forwarding nodes.The paper notes that content names are expected to greatly outnumber hosts, making per-node name-based routing potentially costly in processing, delay, and throughput.Source: §1 · p. 2
• CONET’s separation of forwarding and routing maps naturally to SDN, where a controller can process forwarding-node events and issue reactive or proactive instructions.The paper describes this as a proposed SDN-based approach for supporting ICN.Source: §1 · pp. 2–3
• The paper takes two complementary approaches: an unconstrained longer-term SDN design and an ICN prototype tested on the OpenFlow 1.0 OFELIA testbed.The longer-term perspective does not account for current OpenFlow specification and equipment limitations; the prototype is designed around available features.Source: §1 · p. 3
• The paper proposes an ICN packet format for SDN/OpenFlow and analyzes whether OpenFlow switches can match its fields.The longer-term proposal assumes the specification and equipment can be enhanced to meet ICN needs.Source: §1 · p. 3
• The short-term solution is implemented and tested with OpenFlow 1.0 equipment on OFELIA, and the paper reports implementation results and experience.The experiment is constrained to features available in off-the-shelf OpenFlow equipment.Source: §1 · p. 3
• Although some details are specific to CONET, the authors state that the broader concepts apply to a class of ICN proposals following CCN/NDN’s basic operation.They identify the approach as not limited to CONET.Source: §1 · pp. 3–4

Forward-by-name and routing

• CONET uses a FIB cache for currently needed routes while centralized routing logic manages the full RIB.A forwarding node queues an interest when its FIB lacks a route, asks an NRS node for the next hop, then stores that route and forwards the interest.Source: §2 · pp. 5–6
• The system's scalability was verified under a workload comparable to current HTTP content requests over backbone links.The analysis addressed RIB size and the rate of lookup requests between forwarding nodes and NRS nodes.Source: §2 · p. 6
• The NRS logically centralizes routing intelligence, while scalability and reliability may require distributed, redundant NRS deployment not yet addressed in the prototypes.The RIB logically serves the nodes of a subsystem.Source: §2 · p. 7
• CONET inter-domain routing exchanges reachability and AS-path information between NRS nodes, but its scalability remains an ongoing research topic.The approach is conceptually similar to BGP inter-domain routing.Source: §2 · p. 7

Segmentation and transport

• CONET segments content into chunks and Carrier-Packets, with ICTP regulating Carrier-Packet transfer through reliability and congestion control.The segmentation mechanism allows chunks larger than the layer 2 MTU without IP-level fragmentation.Source: §2 · p. 7

Integration with IP

• CONET integrates ICN information into IP using new IPv4 and IPv6 options, which ICN-capable nodes process while legacy routers forward using regular IP headers.This contrasts with an overlay approach that tunnels ICN information within TCP or UDP flows over IP.Source: §2 · pp. 7–8

Architecture

• The architecture separates an ICN data plane from a control plane containing NRS nodes, security infrastructure, and orchestrators.NRS nodes act as OpenFlow controllers and control one or more ICN nodes through an extended OpenFlow interface.Source: §3 · p. 8
• NRS nodes host name-based routing intelligence, and controllers expose a Northbound API to orchestrate domain behavior.The architecture separates this intelligence from forwarding and caching.Source: §3 · p. 8

Reference interfaces

• The reference interfaces connect NRS nodes to ICN nodes and servers, while iC links NRS nodes across domains and is outside the document's OpenFlow scope.The iS interface lets ICN servers publish hosted-content information to the NRS.Source: §3 · p. 9

Intra-domain support

• Within an OpenFlow domain, tagging adds domain-specific information for capable equipment, with InterWorking Elements at ingress and egress removing it outside the domain.The extended iN+T interface includes this tagging functionality.Source: §3 · p. 10

4. CONET packet format and matching in OpenFlow switches

• Format #2 carries ICN information in the transport layer without a CONET IP option; the authors prefer it because terminal implementation is simpler and legacy IP nodes are unaffected.The paper notes that processing transport-layer information does not pose the same disadvantage for SDN/OpenFlow nodes.Source: §4 · pp. 10, 12
• CONET interests target content chunks using an ICN-ID and Chunk Sequence Number; Diffserv and Type identifies QoS operations or content class, and these fields appear in interest and data packets.The ICN-ID can have fixed or variable size and support different naming schemas.Source: §4 · pp. 10–11
• Because ICN forwarding and caching decisions are made packet by packet, ICTP carries ICN information in every packet header for ICN-node processing.The same headers can support OpenFlow-based operation.Source: §4 · p. 11
• The IP-option format lets an ICN node route using only the IP header, but legacy routers may slow or drop packets; PlanetLab tests generally succeeded, with a few drops.The test passage reports end-to-end CONET connectivity among arbitrary PlanetLab nodes in the large majority of tests.Source: §4 · pp. 11–12

4.1 Packet matching and its critical aspects

• OpenFlow 1.2/1.3 flexible matching does not parse arbitrary unknown protocols, and matching variable-length ICN names remains beyond current switch capabilities.Format #1 requires matching IP options, while format #2 can first match the IP protocol number but encounters the same variable-length ICN-ID issue.Source: §4.1 · pp. 13–14

4.2 The tagging approach

• Arbitrary variable-length names are complex for OpenFlow switches and may be impractical to match in hardware; fixed-length naming can constrain naming schemas and ICN design flexibility.The authors therefore propose dynamically mapping content names to fixed-length tags at ingress Edge Nodes.Source: §4.2 · p. 14
• Ingress Edge Nodes map names to tags for use within the ICN/OpenFlow domain, egress Edge Nodes can remove them, and an 8-byte tag enables fixed-length matching.The required OpenFlow and switch extensions are described as straightforward examples of flexible matching.Source: §4.2 · pp. 14–15
• Tags could reuse VLAN or MPLS fields, but that requires coexistence with their regular semantics; explicitly carrying tags in CONET avoids collisions with those uses.Adding a tag to formats #1 and #2 yields formats #3 and #4, respectively.Source: §4.2 · pp. 14–15
• The implementation targets the OFELIA testbed, which uses OpenFlow v1.0 equipment.Source: §4.2 · p. 15

5. ICN related OpenFlow operations

• The long-term, still-conceptual design assumes OpenFlow extensions and groups ICN operations as content-, routing-, tagging-, and security-related.The authors report that the solution does not yet have mature results.Source: §5 · p. 15

5.1 Routing-related operations

• Name-based forwarding uses a node’s FIB; NRS nodes populate entries and resolve misses, while table updates, eviction, and export may be controller-assisted.The node may also manage forwarding-table entries autonomously under simple rules.Source: §5.1 · pp. 15–16

5.2 Content-related operations

• Content operations include publication, cache notifications, proactive pushes, request tracing, and selective caching decisions made locally or with NRS support.The proposed operations also include tracking requests locally or delegating that work to the NRS.Source: §5.2 · pp. 16–17

5.3 Tagging-related operations

• Within one domain, an ICN node can request a tag for content, and the NRS can asynchronously inject the name-to-tag mapping.Source: §5.3 · p. 17

5.4 Security-related operations

• Content or chunks use private-key signatures for authenticity and integrity, verified before forwarding; other naming schemes rely on NRS-managed key associations and key revocation.Source: §5.4 · p. 17

5.5 Design of OpenFlow protocol extensions

• Proposed extensions cover cached-content notices, publication, name-to-next-hop, connection setup, and name-to-tag messages, using a generic Experimenter message to carry JSON operations and parameters.A binary format could instead be defined when message length is preferred over readability.Source: §5.5 · pp. 17–18

• The authors start from Floodlight’s HTTP REST Northbound interface, while noting that Northbound API definition and standardization are at an early stage.Source: §6 · p. 18
• The Northbound API can query cached content at each cache node and activate or deactivate caching on a specific node.Source: §6 · p. 18
• Planned extensions include statistics on content requests and advance cache population; these capabilities remain future work.Source: §6 · p. 18

• To accommodate existing switches, Cache Servers are external; switches copy returning data to them, and after a full chunk is cached, the controller installs flows so later interests may be redirected there.Source: §7 · pp. 19, 21
• Because OpenFlow 1.0 switches cannot inspect CONET content names, edge nodes and the NRS map names to tags carried in UDP ports for forwarding.The NRS provides a logically centralized mapping within an OpenFlow domain, ensuring that a content name maps to one tag across that domain.Source: §7 · pp. 20–21
• The implementation reserves an IP address for CONET terminals so switches can distinguish CONET packets from real UDP traffic; this workaround reflects OpenFlow 1.0 limitations.Source: §7 · pp. 21–22
• The testbed configuration used an ICN Client, ICN Server, Cache Server, Floodlight controller, and two OpenFlow switches to serve requests for more than 200 chunks.The client and server ran CCNx applications with a CONET-enhanced ccnd daemon; both implemented the IWE to send tagged CONET packets.Source: §7 · pp. 22–23
• As cached chunks accumulate, ICN Server incoming and outgoing load decreases while Cache Server incoming load rises during transient caching.The Cache Server’s incoming load rises because data chunks are copied to it; the number of cached items increases until all chunks are cached.Source: §7 · p. 23

7. Experimentation in the OFELIA testbed

• When all chunks are cached, the Cache Server serves every client request, leaving the ICN Server with zero load and the Cache Server receiving only interest packets.The Cache Server has fully replaced the ICN Server in this phase.Source: §7 · p. 23
• After ICN is disabled and content entries are cleared, switches resume plain MAC learning, forwarding all requests to the ICN Server and restoring its load to the first-phase level.The controller disables the ICN mechanism and clears the content-related switch entries.Source: §7 · p. 23

• The authors place their work among recent SDN–ICN research, noting related proposals that use SDN concepts to improve ICN design [30].Source: §8 · p. 24
• [31] describes SDIA edge controllers instructing nodes to insert packet headers for internal or edge delivery, while [32] and [33] generalize SDN/OpenFlow with storage and caching primitives for content routing.Source: §8 · pp. 24–25
• Some prior approaches map HTTP requests into SDN-routed flows while leaving clients and servers on legacy HTTP; adds content-based traffic engineering to work in [32] and [33].Source: §8 · p. 25
• Other proposals use ICN tagging for data-center routing or centralize routing information, including Routing Control Platforms, BGP route reflectors, and SDN-backbone approaches and.Source: §8 · p. 25
• Name-based inter-domain routing has been proposed using a BGP-like approach and by extending BGP to advertise content-object URIs.Source: §8 · p. 25

• The authors report support for existing CCNx applications and ICN proposals that follow CCN/NDN's basic operation.Source: §9 · p. 25
• The paper presents a long-term design without limitations from OpenFlow switch or protocol evolution, alongside a short-term solution deployed on the OFELIA testbed with OpenFlow 1.0 equipment.Source: §9 · p. 25
• CONET segmentation is useful when OpenFlow requires ICN information in every packet, because IP fragmentation should be avoided.Source: §9 · p. 26
• For SDN/OpenFlow, carrying ICN information in transport-level headers is simpler than using IP Options, assuming a CONET transport protocol.Source: §9 · p. 26
• Matching variable-length ICN names is impractical; the paper discusses fixed-length names, which do not fit all naming schemes, or adding and removing tags at SDN-domain boundaries.Source: §9 · p. 26
• The paper has begun analyzing an ICN northbound API and identifies it as a topic needing deeper analysis.Source: §9 · p. 26