Re: [icnrg] BoF Proposal - Forwarding Using Names - FUN BOF

[[e-mail]]

On Wed May 25 18:47:32 2016 GMT+0100, Ignacio Solis wrote:
> Forwarding Using Names - FUN BOF
> 
> The work in ICN protocols has advanced to the point where we need to
> consider the creation of a Working Group. For this reason we would like to
> request a Forwarding Using Names BoF (FUN BoF) to be scheduled for the
> Berlin meeting. The FUN BoF would be used to gauge the level of interest
> from the community, define the scope of a potential WG, determine what
> items from ICNRG we’re going to carry over and in what form, discuss a
> possible charter and talk about where and how this work fits in the IETF.
> 
> For this purpose I would like to present a draft charter and agenda.
> Feedback is requested and welcome.
> 
> 
> ======================
> 
> Proposed agenda for the FUN BoF:
> 
> 1) Objective and agenda bashing
> 2) Problem statement
> 3) State of current documents and technology
> 3a) draft-irtf-icnrg-ccnxsemantics-02
> 3b) draft-irtf-icnrg-ccnxmessages-02
> 3c) draft-mosko-icnrg-ccnxurischeme-01
> 3d) draft-tschudin-icnrg-flic-00
> 3e) draft-wood-icnrg-ccnxoverudp.txt
> 3f) others?
> 4) Scoping
> 5) Charter discussion
> 6) Next steps
> 
> Proposed WG Charter:
> Name:
>  Forwarding Using Names Working Group (FUNWG)
> 
> Chairs:
>  TBD
> 
> Area:
>  Transport/Internet (?)
> 
> AD:
>  ?
> 
> Description of WG:
> 
> The purpose of the Forwarding Using Names Working Group (FUNWG) is to
> specify protocols and mechanisms for forwarding packets using names.
> Network nodes produce or request packets based on names (explicit or
> implicit). Networks that use named pieces of content as the main
> communication abstraction have been labeled as Information Centric
> Networks. As the name implies, this Working Group specifically focuses on
> using names to forward packets; that is, layer 3.
> 
> Forwarding packets using names is the cornerstone of the predominant ICN
> approaches and has been the focus of most academic and industrial research.
> The CCN and NDN protocols use a request-response object protocol to provide
> an adaptable, resilient and secure communication environment that doesn’t
> suffer from some of the drawbacks introduced by the IP/TCP/HTTP/TLS
> combination.
> 
> Work on ICN started in 2007 at PARC with the creation of CCN. In 2009 the
> NDN project was formed using CCN as a base. At the same time a number of
> European projects (NetINF, Pursuit) also started evaluating different ICN
> techniques. The NetINF project for example produced “Naming Things with
> Hashes” [RFC 6920]. In 2012 the IRTF chartered a Research Group to do work
> on ICN, the ICNRG. The community consensus settled on the CCN approach with
> most ICNRG work and discussions revolving around it.
> 
> The CCN protocol is a request-response protocol made up of 2 core network
> messages; Interests and ContentObjects. Interests request content by name.
> ContentObjects are named pieces of content. Forwarders us the name in the
> messages to determine where to forward them. Interests follow a FIB doing
> prefix matching on the name. ContentObjects follow the reverse path.
> 
> Forwarding packets using names has a number of implications, specifically
> it allows the network to name each piece of data. Once you can name each
> piece of data and request the data by name you can get a number of benefits
> including object-based security, decoupling of producer and sender,
> improved flow control, native indirection, caching, etc.
> 
> Work items for this Working Group
> - Define a set of coherent core protocols that communicate by forwarding
> using names.
> - Define a set of transport protocols built on top of the core protocols
> that communicate at the level of application data units.
> - Define a set of overlay protocols to transport named objects over UDP and
> Ethernet.
> 
> There are some areas that while very related, are out of scope for this
> Working Group.
> These include routing, key distribution, novel security techniques, etc.

Sorry but that last puzzles me. If there are no current ICN confidentiality services, how can novel ones be out of scope? 

Ta, 
S.

> 
> Expected documents:
> 9 months - core protocol
> 15 months - transport protocol
> 6 months - overlay protocol (xxx-over-UDP, xxx-over-IP)
> 9 months - native protocol (xxx-over-Ethernet, ??)
> 
> -- 
> Nacho - Ignacio Solis - [e-mail]
>