1. Introduction

Les travaux sur les environnements RESTful contraints (CoRE) visent à réaliser l'architecture REST (Representational State Transfer) sous une forme adaptée aux nœuds les plus contraints (tels que les microcontrôleurs avec RAM et ROM limitées [RFC7228]) et aux réseaux (tels que IPv6 sur les réseaux personnels sans fil à faible puissance (6LoWPANs) [RFC4944]) [RFC7252]. Le protocole CoAP est destiné à fournir des services RESTful [REST] assez similaires à HTTP [RFC7230], tout en réduisant la complexité de mise en œuvre ainsi que la taille des paquets échangés afin de rendre ces services utiles dans un réseau très contraint de nœuds très contraints.

Cet objectif nécessite de la retenue de plusieurs manières parfois contradictoires :

réduire la complexité de mise en œuvre afin de minimiser la taille du code,
réduire la taille des messages afin de minimiser le nombre de fragments nécessaires pour chaque message (pour maximiser la probabilité de livraison du message), la quantité de puissance de transmission nécessaire et la charge du canal à bande passante limitée,
réduire les exigences sur l'environnement telles que le stockage stable, de bonnes sources d'aléatoire ou des capacités d'interaction avec l'utilisateur.

Comme CoAP est basé sur des transports par datagrammes tels que UDP ou Datagram Transport Layer Security (DTLS), la taille maximale des représentations de ressources qui peuvent être transférées sans trop de fragmentation est limitée. De plus, toutes les représentations de ressources ne tiendront pas dans un seul paquet de couche liaison d'un réseau contraint, ce qui peut entraîner une fragmentation de la couche d'adaptation même si la fragmentation de la couche IP n'est pas requise. L'utilisation de la fragmentation (soit au niveau de la couche d'adaptation, soit au niveau de la couche IP) pour le transport de représentations plus grandes serait possible jusqu'à la taille maximale du protocole de datagramme sous-jacent (tel que UDP), mais le processus de fragmentation/réassemblage charge les couches inférieures avec un état de conversation qui est mieux géré dans la couche application.

La présente spécification définit une paire d'options CoAP pour permettre l'accès par blocs aux représentations de ressources. Les options Block fournissent un moyen minimal de transférer des représentations de ressources plus grandes de manière fragmentée (par blocs). L'objectif primordial est d'éviter d'avoir à créer un état de conversation au niveau du serveur pour les requêtes GET par blocs. (Il est impossible d'éviter totalement de créer un état de conversation pour POST/PUT, si la création/le remplacement de ressources doit être atomique ; lorsque cette propriété n'est pas nécessaire, il n'est pas non plus nécessaire de créer un état de conversation serveur dans ce cas.)

Les transferts par blocs sont réalisés comme des combinaisons d'échanges, chacun étant effectué conformément au protocole de base CoAP [RFC7252]. Chaque échange dans une telle combinaison est régi par les spécifications de [RFC7252], y compris les spécifications de contrôle de congestion (section 4.7 de [RFC7252]) et les considérations de sécurité (section 11 de [RFC7252] ; des considérations de sécurité supplémentaires s'appliquent alors aux transferts dans leur ensemble, voir section 7). La présente spécification minimise les contraintes qu'elle ajoute à ces échanges de base ; cependant, toutes les variantes d'utilisation de CoAP ne sont pas très utiles dans un transfert par blocs (par exemple, l'utilisation de requêtes non confirmables dans des transferts par blocs en dehors du cas d'utilisation de la section 2.8 augmenterait la probabilité globale de non-livraison). Pour être parfaitement clair, la présente spécification ne supprime non plus aucune des contraintes posées par la spécification de base sur laquelle elle est strictement superposée. Par exemple, les paquets consécutifs sont limités par le contrôle de congestion décrit dans la section 4.7 de [RFC7252] (NSTART comme limite pour initier des échanges, PROBING_RATE comme limite pour envoyer sans réponse) ; les transferts par blocs ne peuvent pas envoyer/solliciter plus de trafic qu'un client pourrait envoyer à / solliciter du même serveur sans le mode par blocs.

Dans certains cas, la présente spécification RECOMMANDERA qu'un client effectue une séquence de transferts par blocs "sans délai excessif". Cela ne peut pas être formulé comme une exigence d'interopérabilité, mais est une attente sur la qualité de la mise en œuvre. Inversement, l'attente est que les serveurs n'auront pas à se mettre en quatre pour accommoder les clients qui prennent un temps considérable pour terminer un transfert par blocs. Par exemple, pour un GET par blocs, si la ressource change pendant que cela se poursuit, l'étiquette d'entité (ETag) pour un bloc ultérieur obtenu peut être différente. Pour éviter que cela ne se produise tout le temps pour une ressource changeant rapidement, un serveur PEUT essayer de garder un cache pour un client spécifique pendant une courte période. L'attente ici est que la durée de vie d'un tel cache peut être maintenue courte, de l'ordre de quelques temps d'aller-retour attendus, en comptant à partir du bloc précédent transféré.

En résumé, cette spécification ajoute une paire d'options Block à CoAP qui peuvent être utilisées pour les transferts par blocs. Les avantages de l'utilisation de ces options incluent :

Les transferts plus importants que ce qui peut être accommodé dans les paquets de couche liaison de réseau contraint peuvent être effectués en blocs plus petits.
Aucun état de conversation difficile à gérer n'est créé au niveau de la couche d'adaptation ou de la couche IP pour la fragmentation.
Le transfert de chaque bloc est acquitté, permettant une retransmission individuelle si nécessaire.
Les deux parties ont leur mot à dire sur la taille de bloc qui sera réellement utilisée.
Les échanges résultants sont faciles à comprendre à l'aide d'outils d'analyse de paquets, et donc très accessibles au débogage.
Si nécessaire, les options Block peuvent également être utilisées (sans modification) pour fournir un accès aléatoire à des blocs de taille puissance de deux au sein d'une représentation de ressource.

Une implémentation CoAP qui ne prend pas en charge ces options est généralement limitée dans la taille des représentations qui peuvent être échangées, voir la section 4.6 de [RFC7252]. Même si les options sont Critiques, un serveur peut décider de commencer à les utiliser de manière non sollicitée dans une réponse (Block2) à une requête qui ne contenait pas d'option Block.