Veille technologique

De Gt-metro wiki

Voici la page de nos activités en veille technologique. Vous pouvez contribuer librement (après avoir obtenu votre login ;-) )

Sommaire

Liens

The GÉANT2 Joint Research Programme

IPSPhere Forum

Overview

Internet 2 End-to-End Performance Initiative (E2Epi)

TCP tuning

Conference

Passive And Active Measurement Conference

Internet Measurement Conference

RFC et Drafts concernant la métrologie

Les drafts traversent plusieurs états tout au long de leur processus de normalisation. Dans la mesure du possible, on essaie de tenir à jour leur état dans la normalisation.

Définition de protocoles

Datagram Congestion Control Protocol (DCCP)

  • RFC4340 Datagram Congestion Control Protocol (DCCP) Update by RFC5595,RFC5596,RFC6335
    Résumé : Le protocole de contrôle de congestion de datagrammes (DCCP) est un protocole de transport qui fourni des connexions bidirectionnelles unicast utilisant des datagrammes non-fiables (délivrance au récepteur incertaine) dont la congestion est contrôlée. DCCP est adapté à des applications qui transfèrent de grande quantités de données et qui tirent bénéfice du contrôle dans un équilibre entre les contraintes temporelles et la fiabilité.
  • RFC4341 : Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control
    Résumé : Ce document contient le profil pour l'identifiant de contrôle de congestion 2 (CCID 2), un contrôle de congestion ressemblant à TCP, dans le protocole de contrôle de congestion de datagrammes (DCCP). Le CCID 2 devrait être utilisé par les émetteurs qui voudraient tirer partie de la bande passante disponible dans un environnement où les conditions évoluent rapidement et qui sont capables de s'adapter à des modifications abruptes dans la fenêtre de congestion typiques du contrôle de congestion "Augmentation additive et Diminution multiplicative" (AIMD) de TCP.
  • RFC5348 TCP Friendly Rate Control (TFRC): Protocol Specification.
    Résumé : Ce document spécifie un contrôle de débit amical pour TCP (TCP-Friendly Rate Control (TFRC)). TFRC est un mécanisme de contrôle de congestion pour les flux unicast qui opère dans un environnement de type Best Effort. Il est raisonnablement équitable quand il est en compétition avec des flux TCP pour de la bande passante, tout en ayant une bien plus petite variation de débit au cours du temps, comparé à TCP, ce qui le rend plus adapté pour des applications telles que le streaming où un débit le plus stable possible est très important.
  • RFC5762 RTP and the Datagram Congestion Control Protocol (DCCP).
    Résumé : Le protocole Real-Time Transport Protocol (RTP) est largement utilisé pour le transport de muiltimédia temps réel sur les réseaux IP. Le protocole de contrôle de congestion de datagrammes (DCCP) est un protocole nouvellement défini qui apporte des services appréciables pour des applications temps-réel. Ce mémo spécifie l'implémentation de RTP au-dessus de DCCP, en même temps que la signalisation associée de façon à ce que des applications temps réel puissent utiliser les services apportés par DCCP.

IPFIX

  • RFC5101 Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information IPFIX Protocol Specification.
    Résumé : Ce document spécifie le protocole IPFIX qui sert à transmettre via le réseau des informations sur les flux IP. De façon à transmettre des informations sur les flux à partir d'un processus d'exportation vers un processus de collecte, une représentation commune des données de flux et un moyen standard de les communiquer sont nécessaire. Ce document décrit comment les données IPFIX et les modèles d'enregistrements sont transportés au travers d'un protocole de transport sensible à la congestion à partir d'un process d'exportation IPFIX vers un process de collecte IPFIX.
  • Architecture for IP Flow Information Export. Draft. Etat actuel : RFC Ed Queue. Date d'expiration : 3 mars 2008.
    Resumé Cette note définie l'architecture d'exportation des flux IP (IPFIX) pour une supervision sélective des flux IP et pour l'exportation des flux IP mesurés à partir de périphériques IPFIX vers un collecteur.
  • RFC5102 Information Model for IP Flow Information Export.
    Resumé Cette note définit un modèle de d'information pour le protocole d'exportation des informations de flux IP (IPFIX). Elle est employée par le protocole IPFIX pour coder l'information mesurée du trafic et les informations liées au point d'observation du trafic, le procédé de mesure de trafic et le processus d'exportation. Bien que développé pour le protocole IPFIX, le modèle est défini d'une manière ouverte qui permet facilement de l'employer pour d'autres protocoles, interfaces et applications.
  • RFC5103 Bidirectional Flow Export using IPFIX.
    Resumé Ce document décrit une méthode efficace pour l'exportation d'informations sur des flux bi-directionnels (Biflow) représentant chaque Biflow par un seul enregistrement de flux.
  • Reducing Redundancy in IPFIX and PSAMP Reports. Draft. Etat actuel : RFC Ed Queue. Date d'expiration : 23 décembre 2007
    Resumé Ce document décrit une méthode de préservation de la bande passante pour l'exportation des paquets du protocole d'exportation des informations de flux IP (IPFIX). Comme le protocole PSAMP est basé sur IPFIX, ces considérations sont valides pour les exports PSAMP aussi.
    Cette méthode fonctionne en séparant l'information commune à plusieurs enregistrements de flux de l'information spécifique à un enregistrement de flux individuel. L'information de flux commune est exportée seulement une seule fois dans un enregistrement de donnée défini dans un modèle d'option, tandis que le reste de l'information spécifique est associé avec l'information commune via un identifier unique.

TCP-Friendly Multicast Congestion Control (TFMCC)

  • RFC456 TCP-Friendly Multicast Congestion Control (TFMCC): Protocol Specification. RFC Expérimental.
    Résumé : Ce document spécifie le contrôle de congestion multicast amical pour TCP (TFMCC). TFMCC est un schéma de contrôle de congestion à taux unique basé sur la source qui est basé sur le mécanisme de contrôle de taux de taux unicast amical pour TCP (TFRC) (RFC3448). TFMCC est stable et sensible à un éventail d'états de réseau et est extensible à des ensembles de récepteurs de l'ordre de plusieurs milliers de récepteurs. Pour soutenir l'extensibilité, le plus possible de contrôle de congestion est située aux récepteurs. Chaque récepteur détermine en permanence un taux désiré qui est amical pour TCP pour le chemin de l'expéditeur à ce récepteur. Des récepteurs choisis rapportent alors ce taux à l'expéditeur en paquets de rétroaction. TFMCC est conçu pour être raisonnablement juste lorsqu'il est en concurrence pour de la bande passante avec des flux TCP.

Autres

  • RFC4782 : Quick-Start for TCP and IP.
    Résumé : Ce document spécifie un mécanisme optionnel de démarrage rapide pour des protocoles de transport, en coopération avec les routeurs, pour déterminer un taux de transmission autorisé au début (et quelque fois au milieu d'un transfet de données (c.a.d. après une période sans activité)). Bien que Quick-Sart soit conçu pour être utilisé par divers protocoles de transport, dans ce document nous spécifions uniquement son utilisation avec TCP. Quick-Start est conçu pour permettre aux connexions l'utilisation de taux de transfert plus élevés quand il y a une quantité significative de bande passante inutilisée le long du chemin et que l'émetteur et tous les routeurs traversés autorisent la requête de démarrage rapide.
  • Unicast UDP Usage Guidelines for Application Designers. draft
    Résumé : UDP (User Datagram Protocol) offre un service minimum de passage de messages qui n'a pas de mécanismes de contrôle de congestion inclus. Parce que le contrôle de congestion est essentiel pour le fonctionnement stable de l'Internet, les applications et les couches supérieures de protocoles qui choisissent d'utiliser UDP comme moyen de transport doivent employer des mécanismes pour prévenir des effondrements dus à la congestion et établir une certaine équité avec la circulation concomitante. Ce document fournit des lignes directrices pour l'usage d'UDP à l'attention des concepteurs d'applications unicasts et de protocoles de couches supérieurs. Des lignes directrices pour le contrôle de Congestion sont une priorité, mais le document fournit également des conseils sur d'autres sujets, y compris sur la taille des message, sur la fiabilité, sur les sommes de contrôle et sur la traversée d'équipements intermédiaires.

Diffserv

  • RFC4594 Configuration Guidelines for DiffServ Service Classes.
    Résumé : Ce document décrit des classes de service configurées avec Diffserv, fait des recommandations sur la façon dont elles peuvent être employées et comment les construire en employant des valeurs DSCP, les conditionneurs du trafic, des comportements par noeud (PHB), et des mécanismes actifs de la gestion de file d'attente (AQM). Il n'y a aucune condition intrinsèque que des valeurs DSCPs particulières, des conditionneurs du trafic, des PHBs et AQM soient employé pour une certaine classe de service, mais en tant que politique et pour l'interopérabilité il est utile de les appliquer uniformément.


  • RFC5127 Aggregation of DiffServ Service Classes.
    Resumé : Dans le coeur d'un réseau de grande capacité, la différenciation de service est encore nécessaire afin de permettre l'utilisation du réseau par des applications. Des applications avec des caractéristiques similaires, en termes de performance, sont associées à des classes de services diffserv à partir des besoins en comportement de bout en bout de ces applications, comme indiqué par le RFC sur les classes de services Diffserv. Toutefois, certains segments du réseau peuvent être configurés de façon à ce qu'une seule politique de routage satisfasse les caractéristiques de trafic et les besoins de performances de deux classes ou plus. Dans ce cas, il pourrait être souhaitable d'agréger deux classes Diffserv ou plus en un seul comportement de routage. Ce document propose des règles pour l'agrégation de classes de services Diffserv en des politiques de routage.

RSVP

  • RFC3175 Aggregation of RSVP for IPv4 and IPv6 Reservations.
    Résumé : Ce document décrit l'utilisation d'une seule réservation RSVP (Protocole de Réservation de Ressources) pour agréger d'autres réservations RSVP au travers d'une région de routage de transit, d'une façon conceptuellement similaire à l'utilisation des chemins virtuels dans un réseau ATM. Le document propose un moyen de créer dynamiquement des réservations agrégées, de classifier les types de trafic auxquels de telles agrégations s'appliquent, de déterminer combien de bande passante est nécessaire pour remplir les conditions requises et pour restaurer la bande passante quand des sous-réservations ne sont plus nécessaires. Il contient aussi des recommandations concernant les algorithmes et les règles s'appliquant à des réservations prédictives.
  • RFC4860 Generic Aggregate RSVP Reservations.
    Résumé : Le RFC3175 défini des réservations RSVP agrégées qui permettent d'allouer des ressources dans un réseau Diffserv pour un DSCP et une source donnée vers une destination donnée. Le RFC3175 défini aussi comment des réservations RSVP de bout en bout peuvent être elles-mêmes agrégées pour traverser un nuage Diffserv. Il y a des situations dans lesquelles de telles agrégations multiples sont nécessaires pour les mêmes adresse IP source, adresse de destination et DSCP. Toutefois, ceci n'est pas supporté par la réservation d'agrégat définie dans le RFC3175. De façon à permettre ce type d'agrégation, le présent document défini un type de réservation d'agrégats RSVP plus flexible auquel on se référera comme une réservation d'agrégat générique. De multiples réservations d'agrégats de ce type peuvent être établies pour un DSCP, une adresse IP source et une adresse IP destination données. La réservation d'agrégat générique peut-être utilisée pour agréger des réservations RSVP de bout en bout. Ce document défini aussi la procédure pour de telles agrégations. La réservation d'agrégat générique pourrait aussi être utilisée de bout en bout directement par des systèmes terminaux attachés à un réseau Diffserv.

Mesures de performances

OWAMP

  • A One-way Active Measurement Protocol (OWAMP).
    Résumé : Avec la disponibilité croissante de bonnes sources de temps aux noeuds de réseau, il devient de plus en plus possible de mesurer des métriques de performances IP à sens unique avec une précision élevée. Pour le faire d'une façon interoperable, un protocole commun pour de telles mesures est exigé. Le protocole de mesures actives à sens unique (OWAMP) peut mesurer le délai à sens unique, aussi bien que d'autres caractéristiques à sens unique, telles que les pertes à sens unique.

TWAMP

  • RFC5357 A Two-Way Active Measurement Protocol (TWAMP). Update by RFC5618,RFC5938,RFC6038
    Résumé : Le protocole de mesure actives à sens-unique (OWAMP), spécifié dans la RFC 4656, fournit un protocole commun pour la mesure de métriques à sens unique entre des périphériques réseau. OWAMP peut être utilisé d'un côté ou d'un autre pour faire des mesures de métriques à sens unique entre deux éléments réseaux. Toutefois, il ne prenait pas en compte les voyages aller-retour ou les mesures dans les deux sens. Cette note précise un protocole de mesure active dans les deux sens (TWAMP) sur la base de OWAMP, qui ajoute des capacités de mesure dans les deux sens ou aller-retour. L'architecture de mesure TWAMP est généralement composée de deux hôtes avec des rôles spécifiques, ce qui permet certaines simplifications protocolaires, ce qui en fait une alternative attractive dans certaines circonstances.

IPPM

  • RFC2330 Framework for IP Performance Metrics
    Résumé : Le but de cette note est de définir un cadre général pour que des métriques particulières soient développées par le groupe de l'IETF en charge des métriques de performance IP, commencée par le groupe de travail "méthodologie de Benchmarking (BMWG)" de la zone des conditions opérationnelles, et continuée par le groupe de travail sur les métriques de performance IP (IPPM) de la zone de transport.
  • RFC2678 IPPM Metrics for Measuring Connectivity.
    Résumé : La connectivité est la substance de base dont l'Internet est fait. Par conséquent, des métriques déterminant si des paires de machines (adresses d'IP) peuvent s'atteindre doivent former la base d'une suite d'outils de mesure. Nous définissons plusieurs métriques de ce type, dont une partie sert principalement de modules pour les autres. Cette note définit une série de métriques pour la connectivité entre une paire de machines sur Internet. Il est basée sur des notions présentées et discutées
  • RFC2679 A One-way Delay Metric for IPPM .
    Résumé : Cette note définit un métrique pour le délai à sens unique des paquets à travers des chemins d'Internet. Il est bati sur des notions présentées et discutées dans le document de cadre d'IPPM, RFC2330 ; on suppose que le lecteur connaît ce document. Cette note est prévue pour être parallèle en structure à un document compagnon pour la perte de paquet ("une métrique pour la perte de paquets à sens unique pour IPPM").
  • RFC2680 A One-way Packet Loss Metric for IPPM.
    Résumé : Cette note définit un métrique pour la perte de paquets à sens unique à travers des chemins d'Internet. Il est bâti sur des notions présentées et discutées dans le document de cadre d'IPPM, RFC2330 ; on suppose que le lecteur connaît ce document. Cette note est prévue pour être parallèle en structure à un document compagnon pour le délai à sens unique ("Une métrique pour le délai à sens unique pour IPPM") ; on suppose que le lecteur connaît ce document.
  • RFC4737 Packet Reordering Metric for IPPM. Update by RFC6248
    Résumé : Cette note définit des métriques pour évaluer si un réseau a maintenu l'ordre des paquets sur une base de paquet par paquet. Elle fournit des motivations pour les nouvelles métriques et discute les problèmes de mesures, y compris les informations de contexte nécessaires pour toute les métriques. La note définit d'abord un singleton de réordonnancement, puis l'utilise comme base pour quantifier l'étendue du réordonnancement dans plusieurs dimensions utiles pour la caractérisation de réseau ou le design des récepteurs. Des métriques additionnelles mesurent la fréquence des réordonnancements et la distance entre les différentes occurrences. Nous définissons alors une métrique orientée vers l'évaluation des effets du réordonnancement sur TCP. Plusieurs exemples d'évaluation employant les diverses métriques sont inclus. Une annexe donne des définitions approfondies pour évaluer l'ordonnancement avec de la fragmentation de paquet
  • RFC5136 Defining Network Capacity.
    Resumé : Mesurer la capacité est une tâche qui semble simple, mais qui peut-être assez complexe dans la réalité. De plus, l'absence d'une nomemclature unifiée sur ce sujet rend de plus en plus difficile la construction, les tests et l'utilisation de techniques et d'outils batis autour de ces constructions. Ce document propose des définitions pour les termes Capacité et Capacité disponible relatifs à du trafic IP entre une source et une destination dans un réseau IP. Ce faisant, nous espérons mettre en place un cadre de travail commun pour les discussions et l'analyse d'un ensemble de techniques d'estimation diverses actuelles et futures.
  • RFC5388 Information Model and XML Data Model for Traceroute Measurements.
    Resumé : Ce document décrit une méthode standard de stockage de la configuration et des résultats des mesures de traceroute. Il décrit tout d'abord l'outil lui-même ; il défini ensuite le modèle d'information commun en divisant les éléments d'information en deux groupes sémantiquement séparés (les éléments de configuration et les éléments de résultat). De plus, un élément additionnel est défini pour relier les éléments de configuration et les éléments de résultat au moyen d'un identifiant unique commun. Sur la base du modèle d'information, un modèle de données basé sur XML est défini pour stocker les résultats des mesures de traceroute.

Benchmarking

  • RFC2544 Benchmarking Methodology for Network Interconnect Devices. Ce document commente et décrit les caractéristiques de performance d'un équipement d'interconnexion de réseaux. Il ne se contente pas de définir des tests, mais il décrit aussi des formats spécifiques pour rendre compte du résultat des tests. L'appendice A liste les tests et les conditions qui, d'après les auteurs, devraient être incluses dans des cas spécifiques et donne des information additionnelles sur les techniques de test. L'appendice B est une référence qui liste les taux maximum d'émission de trames à utiliser avec des tailles spécifiques sur différents médias et l'appendice C donne quelques exemple de format de trames à utiliser pour les tests
  • RFC5180 IPv6 Benchmarking Methodology for Network Interconnect Devices. Les méthodologies de benchmarking définies dans le RFC2544 sont indépendantes de la version d'IP. Toutefois, le RFC2544 ne traite pas de certaines spécificités d'IPv6. Ce document donne des directives additionnelles de benchmarking qui, en conjonction avec le RFC2544, conduisent à une évaluation plus complète et plus réaliste des performances IPv6 des équipements d'interconnexion de réseaux. Les mécanismes de transition vers IPv6 sont hors du périmètre de ce document.
  • RFC4689 Terminology for Benchmarking Network-layer Traffic Control Mechanisms .
    Résumé : Ce document décrit la terminologie pour réaliser des benchmarks sur les dispositifs équipant des périphériques qui implémentent du contrôle de trafic basé sur la l'IP Precedence ou le code de contrôle Diffserv.
    La terminologie doit être appliquée aux mesures faites au niveau du plan de commutation des données pour évaluer les mécanismes de contrôle de trafic IP. La nouvelle terminologie est nécessaire parce que la plupart des mesures existantes tiennent pour acquise l'absence de la congestion et un comportement de type saut unique.
    Ce document présente plusieurs nouveaux termes qui permettront d'effectuer des mesures pendant des périodes de congestion.
    Une autre différence principale avec la terminologie existante est la définition des mesures prises en sortie aussi bien qu'en entrée d'un équipement/système en test. De plus, l'existence de congestion exige l'ajout de mesures en sortie aussi bien que celles effectues en entrée ; sans observer le trafic en sortie d'un équipement/système, il n'est pas possible de dire si les mécanismes de contrôle de trafic ont efficacement traité la congestion. Les principales mesures présentées dans ce document sont des vecteurs pour le débit, le délai et la latence qui peuvent tous être observés avec ou sans congestion du DUT/SUT*.
* DUT = Device Under Test (Equipement en cours de test)
* SUT = System Under Test (Système en cours de test)

MIBs

  • RFC4560 Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations
    Résumé : Cette note définit des MIBs pour effectuer des opérations de type ping, traceroute et de résolution d'adresses sur un système distant. Pour l'administrateur réseau, il est utile de pouvoir lancer et rechercher les résultats des opérations de type ping ou traceroute exécutées sur un site distant. Une capacité de résolution d'adresse est définie afin de permettre soit la résolution d'une addresse IP en un nom DNS soit d'un nom DNS vers une addresse IP sur une station distante.
  • RFC4898 TCP Extended Statistics MIB
    Résumé : Cette note décrit des statistiques de performances étendues pour TCP. Elle sont conçues afin d'utiliser l'avantage idéal de TCP afin de de diagnostiquer des problèmes de performances à la fois dans le réseau et dans l'application. Si une application utilisant le réseau se comporte avec des performances faibles, TCP peut déterminer si le goulot d'étranglement est l'expéditeur, le destinataire ou le réseau lui-même. Si le goulot d'étranglement est dans le réseau, TCP peut apporter des informations spécifiques sur sa nature.

Autres documents

Une présentation sur IPFIX PDF

Outils personnels