1. Architecture
1.1. Interest Packet
1.1.1. Content name/Prefix
1.1.1.1. Identifie par un nom la ressource désirée
1.1.2. Selectors
1.1.2.1. Optionnels
1.1.2.2. Permet de sélectionner la donnée qui correspond le plus à la demande
1.1.2.3. Exemples
1.1.2.3.1. Exclude
1.1.2.3.2. MustBeFresh
1.1.2.3.3. MinSuffixComponents, MaxSuffixComponents
1.1.3. Nonce
1.1.3.1. Chaîne de caractère de 4 octets générée aléatoirement pour détecter les boucles infinies
1.1.4. InterestLifetime
1.1.4.1. Optionnel
1.1.4.2. Indique le temps avant que l'Interest Packet expire
1.2. Data Packet
1.2.1. Content name
1.2.2. MetaInfo
1.2.2.1. ContentType
1.2.2.2. FreshnessPeriod
1.2.2.2.1. Indique combien de temps la donnée doit être considérée comme "à jour". La donnée est conservée mais ne sera pas envoyée à un Interest avec MustBeFresh activé.
1.2.2.3. FinalBlockId
1.2.3. Content
1.2.3.1. Contenu demandé par l'Interest Packet
1.2.4. Signature
1.2.4.1. Signature des 3 éléments précédents
1.3. Node
1.3.1. Forwarding Information Base (FIB)
1.3.1.1. Table faisant l'association nom <-> face(s) afin de savoir où faire suivre l'Interest Packet
1.3.1.2. Entrée manuellement ou par un protocole de routage
1.3.1.3. Si plusieurs faces sont associées à un nom, un mécanisme de "forwarding strategy"est mis en place pour déterminer sur quelle face router. Il est aussi possible de faire suivre sur toutes les faces
1.3.2. Pending Interest Table (PIT)
1.3.2.1. Table faisant l'association nom <-> face(s) d'arrivée de l'Interest Quand le Data Packet arrive, il est envoyé à/aux face(s) listées et l'entrée supprimée de la table
1.3.2.2. Les entrées possèdent une date d'expiration
1.3.3. Content Store (CS)
1.3.3.1. Cache auquel est ajouté le contenu des Data Packet chaque fois qu'ils arrivent
1.4. Noms
1.4.1. Exemple : /parc.com/ videos/WidgetA.mpg/_version/_segment
1.4.2. Structure hiérarchisée et ordonnée
1.4.2.1. Permet, dans un Interest Packet, de pouvoir spécifier un nom incomplet (d'où le terme préfixe)
1.4.2.2. On peut obtenir un contenu relativement/par rapport à un autre que l'on connait
1.4.2.3. Exemple
1.4.2.3.1. "/parc.com/ videos/WidgetA.mpg RightmostChild" permet d'obtenir le premier segment de la dernière version de la vidéo
1.4.3. Peuvent-être chiffrés pour protéger la vie privée
1.4.4. Longueur variable
1.5. Fonctionnement
1.5.1. Si le consommateur ne reçoit pas un Packet, c'est à lui de redemander (consumer-driven)
1.5.2. Principe du "flow-balance" : Un Interest Packet correspond au plus à un Data Packet
1.5.3. Workflow
1.5.3.1. Un utilisateur envoie un Interest Packet sur le réseau
2. Un noeud reçoit l'Interest
2.1. 3 étapes
2.1.1. Etape 1 : Une recherche dans la CS est effectuée sur le préfix de l'Interest Packet
2.1.1.1. Si une entrée existe, le contenu est renvoyé à la face demandeuse.
2.1.1.1.1. Prendre en compte la fraicheur du contenu
2.1.1.2. Si aucune entrée, alors étape 2
2.1.2. Etape 2 : Une recherche dans la PIT est effectuée sur le préfix de l'Interest Packet pour savoir si quelqu'un d'autre a demandé la même donnée
2.1.2.1. Si une entrée existe, alors la face d'arrivée de l'Interest Packet est ajoutée à cette entrée et l'Interest Packet est supprimé
2.1.2.1.1. Quand le Data Packet qui avait été envoyé prélablement arrive, il faut simplement s'assurer d'envoyer une copie à la face qui vient de s'ajouter à l'entrée
2.1.2.2. Si aucune entrée, alors étape 3
2.1.3. Etape 3 : Une recherche dans la FIB est effectuée sur le préfix de l'Interest Packet
2.1.3.1. Si une entrée existe, l'Interest Packet est envoyé à une face de l'entrée
2.1.3.2. Si aucune entrée, l'Interest Packet est supprimé
3. Contexte
3.1. De plus en plus de contenu multimédia (son, vidéo, image)
3.2. Exabytes de contenu crée chaque année
3.3. De plus en plus d'appareils connectés
3.4. Principes
3.4.1. Modèle basé sur le QUOI plutôt que le OÙ et le QUI
3.4.2. ICN (Information-Centric Networking)
3.4.2.1. Nouvelle approche d'internet afin de le transformer en architecture centrée autour du contenu
3.4.2.1.1. NDN est une branche de recherche suivant cette approche
3.5. Réseau point à point
3.5.1. Créé dans les années 60-70
3.5.2. Communication d'une machine à une autre (IP source -> IP destinataire)
3.5.3. Pas adapté à l'utilisation actuelle d'internet basée sur l'échange de contenu
4. Inconvénients
5. Sécurité
5.1. Pensée dès la conception (à la différence d'IP)
5.1.1. Signature des paquets
5.1.2. Protocole NLSR sécurisé
5.1.3. Chaque paquet est signé par un système de clé publique
5.1.3.1. Valider le contenu plutôt que qui l'a fournit et d'où il provient comme dans IP
5.1.3.2. L'algorithme est sélectionné par le fournisseur de contenu parmi un large choix selon le cas (minimiser le temps de génération ou de vérification, de la quantité de data vérifiée...)
5.1.3.3. La clé est récupérée via un autre Data Packet. une convention de nom doit donc être respectée
5.1.3.4. Pas besoin d'une partie tier pour générer les certificats
5.2. Les attaques DOS en NDN
5.3. "Privacy Policy" => Si le temps de réponse est faible alors le paquet était stocké dans le CS d'un routeur à proximité => quelqu'un à proximité l'avait demandé
5.4. Au niveau du cache
5.5. Problème de confiance dans un réseau qui n'est pas totalement NDN mais contient aussi des noeuds IP (conext intra_domain)
6. Avantages
6.1. Mobilité
6.2. Peut-être utilisé conjoitement avec IP
7. Protocole de routage NLSR (Named-data Link State Routing Protocol)
7.1. Protocole de type Link State
7.1.1. Consiste à fournir à l’ensemble des routeurs d’une « zone » considérée, une vision complète de la topologie de la zone
7.1.2. Communication par LSA (link-state advertisement) pour construire la topologie du réseau et distribuer les préfixes de nom
7.1.2.1. format des noms
7.1.2.1.1. Idéalement : /<network>/<site>/<router>/NLSR/LSA
7.1.2.1.2. Réalité : /<network>/NLSR/LSA/<site>/<router>
7.1.2.2. 2 types de LSA
7.1.2.2.1. Adjacency LSA
7.1.2.2.2. Prefix LSA
7.1.3. Rediffusion par LSA à tout le réseau si échec, ajout de nom à un routeur
7.1.4. Différenciation avec les autres Link State protocoles
7.1.4.1. Peut fournir plusieurs routes pour un nom
7.1.4.2. Signer et vérifier les LSA