Introduction

Ce document traite de la configuration du mode planificateur en amont pour la gamme de systèmes CMTS (Cable Modem Termination Systems) du routeur à large bande universel Cisco uBR (Universal Broadband Router).

Ce document se concentre sur le personnel qui travaille à la conception et à la maintenance de réseaux de données sur câble à haut débit qui utilisent des services en amont sensibles à la latence et à la gigue, par exemple la voix ou la vidéo sur IP.

Conditions préalables

Conditions requises

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Systèmes DOCSIS (Data over Cable Service Interface Specification)

• Gamme Cisco uBR de CMTS

Components Used

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

• CMTS Cisco uBR

• La version du logiciel Cisco IOS® forme 12.3(13a)BC et 12.3(17a)BC

Remarque : Pour plus d'informations sur les modifications apportées aux versions ultérieures du logiciel Cisco IOS, reportez-vous aux notes de version appropriées disponibles sur le site Web Cisco.com.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Informations générales

Dans un réseau DOCSIS (Data-over-Cable Service Interface Specifications), le CMTS contrôle la synchronisation et le débit de toutes les transmissions en amont effectuées par les modems câble. De nombreux types de services avec des exigences de latence, de gigue et de débit différentes s'exécutent simultanément sur un réseau DOCSIS moderne en amont. Par conséquent, vous devez comprendre comment le CMTS décide quand un modem câble peut effectuer des transmissions en amont pour le compte de ces différents types de services.

Ce livre blanc comprend :

• Vue d'ensemble des modes de planification en amont dans DOCSIS, y compris le service au mieux, le service de subvention non sollicitée (UGS) et le service d'interrogation en temps réel (RTPS)

• Fonctionnement et configuration du planificateur conforme DOCSIS pour le CMTS Cisco uBR

• Fonctionnement et configuration du nouveau planificateur de file d'attente à faible latence pour le CMTS Cisco uBR

Planification en amont dans DOCSIS

Un CMTS conforme à DOCSIS peut fournir différents modes de planification en amont pour différents flux de paquets ou applications via le concept de flux de service. Un flux de service représente un flux de données en amont ou en aval, que l'ID de flux de service (SFID) identifie de manière unique. Chaque flux de service peut avoir ses propres paramètres de qualité de service (QoS), par exemple, le débit maximal, le débit garanti minimum et la priorité. Dans le cas des flux de service en amont, vous pouvez également spécifier un mode de planification.

Vous pouvez disposer de plusieurs flux de service en amont pour chaque modem câble afin de prendre en charge différents types d'applications. Par exemple, le Web et la messagerie peuvent utiliser un flux de service, la voix sur IP (VoIP) en utiliser un autre et les jeux Internet peuvent utiliser un autre flux de service. Afin de pouvoir fournir un type de service approprié pour chacune de ces applications, les caractéristiques de ces flux de services doivent être différentes.

Le modem câble et le CMTS sont capables de diriger les types de trafic appropriés vers les flux de service appropriés avec l'utilisation de classificateurs. Les classificateurs sont des filtres spéciaux, comme les listes d’accès, qui correspondent aux propriétés des paquets, telles que les numéros de port UDP et TCP, afin de déterminer le flux de service approprié pour les paquets à traverser.

Dans la Figure 1, un modem câble a trois flux de service en amont. Le premier flux de service est réservé au trafic vocal. Ce flux de service a un débit maximal faible mais est également configuré pour garantir une faible latence. Le prochain flux de services concerne le trafic Web et de messagerie général. Ce flux de services a un débit élevé. Le flux de service final est réservé au trafic peer to peer (P2P). Ce flux de service a un débit maximal plus restrictif pour réduire la vitesse de cette application.

Figure 1 - Un modem câble avec trois flux de services en amont

Les flux de services sont établis et activés lorsqu'un modem câble est mis en ligne pour la première fois. Provisionnez les détails des flux de service dans le fichier de configuration DOCSIS que vous utilisez pour configurer le modem câble. Provisionnez au moins un flux de service pour le trafic en amont et un autre flux de service pour le trafic en aval dans un fichier de configuration DOCSIS. Les premiers flux de service en amont et en aval que vous spécifiez dans le fichier de configuration DOCSIS sont appelés flux de service principal.

Les flux de services peuvent également être créés et activés dynamiquement après la mise en ligne d’un modem câble. Ce scénario s'applique généralement à un flux de service, qui correspond aux données qui appartiennent à un appel téléphonique VoIP. Un tel flux de services est créé et activé lorsqu'une conversation téléphonique commence. Le flux de service est alors désactivé et supprimé à la fin de l'appel. Si le flux de service n'existe que lorsque cela est nécessaire, vous pouvez enregistrer les ressources de bande passante en amont et la charge CPU et mémoire système.

Les modems câble ne peuvent pas transmettre des données en amont à tout moment. Au lieu de cela, les modems doivent attendre les instructions du CMTS avant de pouvoir envoyer des données, car un seul modem câble peut transmettre des données sur un canal en amont à la fois. Sinon, les transmissions peuvent se dépasser et se corrompre. Les instructions relatives au moment où un modem câble peut effectuer une transmission proviennent du CMTS sous la forme d'un message MAP d'allocation de bande passante. Le système Cisco CMTS transmet un message MAP toutes les 2 millisecondes pour indiquer aux modems câble quand ils peuvent transmettre n'importe quelle transmission. Chaque message MAP contient des informations qui indiquent aux modems exactement quand effectuer une transmission, combien de temps la transmission peut durer et quel type de données ils peuvent transmettre. Ainsi, les transmissions de données par modem câble ne sont pas en collision et évitent la corruption des données. Cette section traite de certaines des façons dont un CMTS peut déterminer quand accorder une autorisation de modem câble pour effectuer une transmission en amont.

Meilleur effort

La planification au mieux est adaptée aux applications Internet classiques sans exigence stricte en matière de latence ou de gigue. Parmi ces types d'applications, citons la messagerie électronique, la navigation Web ou le transfert de fichiers d'égal à égal. La planification au mieux ne convient pas aux applications nécessitant une latence ou une gigue garanties, par exemple la voix ou la vidéo sur IP. En effet, dans des conditions congestionnées, aucune garantie de ce type ne peut être faite au mieux. Les systèmes DOCSIS 1.0 ne permettent que ce type de planification.

Les flux de services au mieux sont généralement provisionnés dans le fichier de configuration DOCSIS associé à un modem câble. Par conséquent, les flux de services au mieux sont généralement actifs dès que le modem câble est mis en ligne. Le flux de service principal en amont, c'est-à-dire le premier flux de service en amont à être provisionné dans le fichier de configuration DOCSIS, doit être un flux de service de type de meilleur effort.

Voici les paramètres les plus couramment utilisés qui définissent un flux de service au mieux dans le mode DOCSIS 1.1/2.0 :

• Débit de trafic soutenu maximal (R)

  Maximum Sustained Traffic Rate est le débit maximal auquel le trafic peut fonctionner sur ce flux de service. Cette valeur est exprimée en bits par seconde.

• Débit maximal du trafic (B)

  Maximum Traffic Burst fait référence à la taille de rafale en octets qui s'applique au limiteur de débit de groupement de jetons qui applique les limites de débit en amont. Si aucune valeur n'est spécifiée, la valeur par défaut de 3044 s'applique, soit la taille de deux trames Ethernet complètes. Pour les débits de trafic soutenus maximaux élevés, définissez cette valeur sur au moins le débit de trafic soutenu maximal divisé par 64.

• Priorité du trafic

  Ce paramètre fait référence à la priorité du trafic dans un flux de service compris entre 0 (le plus faible) et 7 (le plus élevé). En amont, tout le trafic en attente pour les flux de service de haute priorité est planifié pour transmission avant le trafic pour les flux de service de faible priorité.

• Taux minimal réservé

  Ce paramètre indique un débit minimal garanti en bits par seconde pour le flux de service, similaire à un débit d'informations garanti (CIR). Les débits minimaux réservés combinés pour tous les flux de service sur un canal ne doivent pas dépasser la bande passante disponible sur ce canal. Sinon, il est impossible de garantir les tarifs minimaux réservés promis.

• rafale concaténée maximale

  Maximum Concatenated Burst est la taille en octets de la plus grande transmission de trames concaténées qu'un modem peut effectuer pour le compte du flux de service. Comme ce paramètre l’indique, un modem peut transmettre plusieurs trames en une seule rafale de transmission. Si cette valeur n'est pas spécifiée, les modems câble DOCSIS 1.0 et les modems DOCSIS 1.1 plus anciens supposent qu'aucune limite explicite n'est définie sur la taille de rafale concaténée. Les modems conformes à des révisions plus récentes des spécifications DOCSIS 1.1 ou ultérieures utilisent une valeur de 1 522 octets.

Lorsqu'un modem câble dispose de données à transmettre pour le compte d'un flux de service au mieux en amont, le modem ne peut pas simplement transférer les données sur le réseau DOCSIS sans délai. Le modem doit passer par un processus dans lequel il demande au CMTS un temps de transmission en amont exclusif. Ce processus de demande garantit que les données ne entrent pas en collision avec les transmissions d'un autre modem câble connecté au même canal en amont.

Parfois, le CMTS planifie certaines périodes au cours desquelles le CMTS permet aux modems câble de transmettre des messages spéciaux appelés requêtes de bande passante. La demande de bande passante est une très petite trame qui contient des détails sur la quantité de données que le modem veut transmettre, plus un identificateur de service (SID) qui correspond au flux de service en amont qui doit transmettre les données. Le CMTS gère une table interne qui fait correspondre les numéros SID aux flux de service en amont.

Le CMTS planifie les opportunités de demande de bande passante lorsqu'aucun autre événement n'est planifié en amont. En d'autres termes, le planificateur fournit des opportunités de demande de bande passante lorsque le planificateur en amont n'a pas prévu une subvention au meilleur effort, ou une subvention UGS ou un autre type de subvention à placer à un point particulier. Par conséquent, lorsqu’un canal en amont est fortement utilisé, les modems câble ont moins d’opportunités de transmettre des requêtes de bande passante.

Le CMTS s'assure toujours qu'un petit nombre d'opportunités de demande de bande passante sont régulièrement planifiées, quelle que soit l'encombrement du canal en amont. Plusieurs modems câble peuvent transmettre simultanément des requêtes de bande passante et corrompre les transmissions des uns et des autres. Afin de réduire le risque de collisions pouvant corrompre les demandes de bande passante, un algorithme “ de réinitialisation et de tentative de ” est en place. Les sections suivantes de ce document traitent de cet algorithme.

Lorsque le CMTS reçoit une demande de bande passante d'un modem câble, il effectue les actions suivantes :

1. Le CMTS utilise le numéro SID reçu dans la demande de bande passante pour examiner le flux de service auquel la demande de bande passante est associée.

2. Le CMTS utilise ensuite l'algorithme de groupement de jetons. Cet algorithme aide le CMTS à vérifier si le flux de service dépasse le débit maximal soutenu prescrit si le CMTS accorde la bande passante demandée. Voici le calcul de l'algorithme de groupement de jetons :

   Max(T) = T * (R / 8) + B

   where:

   • Max(T) indique le nombre maximal d'octets pouvant être transmis sur le flux de service sur le temps T.

   • T représente le temps en secondes.

   • R indique le débit de trafic soutenu maximal pour le flux de service en bits par seconde

   • B est la rafale de trafic maximale pour le flux de service en octets.

3. Lorsque le CMTS s'assure que la demande de bande passante est dans les limites de débit, le CMTS met en file d'attente les détails de la demande de bande passante au planificateur en amont. Le planificateur en amont décide quand accorder la demande de bande passante.

   Le CMTS Cisco uBR implémente deux algorithmes de planification amont, appelés planificateur conforme DOCSIS et planificateur de mise en file d'attente à faible latence. Pour plus d'informations, reportez-vous à la section DOCSIS Compliant Scheduler et à la section Low Latency Queueing Scheduler de ce document.

4. Le CMTS inclut ensuite ces détails dans le prochain message MAP périodique d'allocation de bande passante :

   • Lorsque le modem câble est capable de transmettre.

   • Pendant combien de temps le modem câble est capable de transmettre.

Algorithme de retour arrière et de nouvelle tentative de demande de bande passante

Le mécanisme de demande de bande passante utilise un algorithme de réémission et de réessai de “ simple pour réduire, mais pas totalement éliminer, le risque de collisions entre plusieurs modems câble qui transmettent simultanément des demandes de bande passante.

Un modem câble qui décide de transmettre une demande de bande passante doit d’abord attendre qu’un nombre aléatoire d’opportunités de demande de bande passante passe avant que le modem ne procède à la transmission. Ce délai d’attente permet de réduire les risques de collisions dues à des transmissions simultanées de requêtes de bande passante.

Deux paramètres appelés le démarrage de l'interruption des données et la fin de l'interruption des données déterminent la période d'attente aléatoire. Les modems câble apprennent ces paramètres dans le contenu du message UCD (UCD). Le CMTS transmet le message UCD au nom de chaque canal en amont actif toutes les deux secondes.

Ces paramètres de retour arrière sont exprimés en puissance “ de deux valeurs ”. Les modems utilisent ces paramètres comme puissances de deux pour calculer le temps d’attente avant de transmettre les requêtes de bande passante. Les deux valeurs ont une plage de 0 à 15 et l'extrémité arrière des données doit être supérieure ou égale à l'extrémité arrière des données.

La première fois qu’un modem câble souhaite transmettre une demande de bande passante particulière, il doit d’abord choisir un nombre aléatoire compris entre 0 et 2, en fonction de la puissance du démarrage de la réémission des données moins 1. Par exemple, si le démarrage en arrière-plan des données est défini sur 3, le modem doit choisir un nombre aléatoire compris entre 0 et (2³ - 1) = (8 - 1) = 7.

Le modem câble doit ensuite attendre que le nombre aléatoire sélectionné d'opportunités de transmission de demande de bande passante passe avant que le modem ne transmette une demande de bande passante. Ainsi, alors qu'un modem ne peut pas transmettre une demande de bande passante à la prochaine occasion disponible en raison de ce retard forcé, la possibilité d'une collision avec la transmission d'un autre modem diminue.

Naturellement, plus la valeur de début de la réémission des données est élevée, plus la possibilité de collisions entre les requêtes de bande passante est faible. Des valeurs de démarrage de retour arrière de données plus importantes signifient également que les modems doivent parfois attendre plus longtemps pour transmettre des requêtes de bande passante, et donc que la latence en amont augmente.

Le CMTS inclut un accusé de réception dans le prochain message MAP d'allocation de bande passante transmis. Cet accusé de réception informe le modem câble que la demande de bande passante a été reçue avec succès. Cet accusé de réception peut :

• soit indiquer exactement quand le modem peut transmettre

  OU

• indique uniquement que la demande de bande passante a été reçue et qu'une heure de transmission sera décidée dans un message MAP futur.

Si le CMTS n'inclut pas d'accusé de réception de la demande de bande passante dans le message MAP suivant, le modem peut conclure que la demande de bande passante n'a pas été reçue. Cette situation peut se produire en raison d'une collision ou d'un bruit en amont, ou parce que le débit du service dépasse le débit maximal prescrit si la demande est accordée.

Dans les deux cas, l’étape suivante du modem câble consiste à effectuer une réémission temporisée et à tenter de transmettre à nouveau la demande de bande passante. Le modem augmente la plage sur laquelle une valeur aléatoire est choisie. Pour ce faire, le modem en ajoute un à la valeur de démarrage de la réémission des données. Par exemple, si la valeur de début de la réémission des données est 3 et que le CMTS ne reçoit pas une transmission de demande de bande passante, le modem attend une valeur aléatoire comprise entre 0 et 15 opportunités de demande de bande passante avant de la retransmission. Voici le calcul : 23+1 - 1 = 24 - 1 = 16 - 1 = 15

La plus grande plage de valeurs réduit les risques de collision. Si le modem perd d'autres demandes de bande passante, il continue d'incrémenter la valeur utilisée comme puissance de deux pour chaque retransmission jusqu'à ce que la valeur soit égale à la valeur de fin de réémission de données. La puissance de deux ne doit pas être supérieure à la valeur finale de retour arrière des données.

Le modem retransmet une demande de bande passante jusqu’à 16 fois, après quoi il rejette la demande de bande passante. Cette situation ne se produit que dans des conditions extrêmement congestionnées.

Vous pouvez configurer les valeurs de début et de fin de réémission des données par câble en amont sur un CMTS Cisco uBR avec cette commande d'interface de câble :

câble en amont port-amont data-backoff data-backoff-start data-backoff

Cisco vous recommande de conserver les valeurs par défaut pour les paramètres de démarrage et de fin de retour arrière des données, qui sont 3 et 5. En raison de la nature du système de planification des meilleurs efforts basé sur les conflits, il est impossible de fournir un niveau déterministe ou garanti de latence ou de gigue en amont pour les flux de services au mieux de l'effort. En outre, les conditions encombrées peuvent rendre impossible la garantie d'un niveau de débit particulier pour un flux de services au mieux. Cependant, vous pouvez utiliser des propriétés de flux de service telles que la priorité et le taux minimal réservé. Grâce à ces propriétés, le flux de service peut atteindre le niveau de débit souhaité dans des conditions encombrées.

Exemple d'algorithme de désactivation et de nouvelle tentative

Cet exemple comprend quatre modems câble nommés A, B, C et D, connectés au même canal en amont. Au même moment appelé t₀, les modems A, B et C décident de transmettre certaines données en amont.

Dans ce cas, le démarrage du retour arrière des données est défini sur 2 et le retour arrière des données sur 4. La plage d'intervalles à partir de laquelle les modems choisissent un intervalle avant de tenter pour la première fois de transmettre une demande de bande passante est comprise entre 0 et 3. Voici le calcul :

(22 - 1) = (4 - 1) = 3 intervalles.

Voici le nombre d'opportunités de demande de bande passante que les trois modems choisissent pour attendre à partir du temps t₀.

• Modem A : 3

• Modem B : 2

• Modem C : 3

Notez que les modems A et C ont le même nombre d'opportunités d'attente.

Le modem B attend deux opportunités de demande de bande passante qui apparaissent après t₀. Le modem B transmet ensuite la demande de bande passante que le CMTS reçoit. Le modem A et le modem C attendent que 3 opportunités de demande de bande passante passent après t₀. Les modems A et C transmettent ensuite les requêtes de bande passante en même temps. Ces deux requêtes de bande passante entrent en collision et deviennent corrompues. Par conséquent, aucune des deux demandes n'atteint le CMTS. La Figure 2 présente cette séquence d'événements.

Figure 2 - Exemple de demande de bande passante Partie 1

La barre grise en haut du schéma représente une série d'opportunités de demande de bande passante disponibles pour les modems câble après le temps t₀. Les flèches de couleur représentent les demandes de bande passante que les modems câble transmettent. La zone de couleur de la barre grise représente une demande de bande passante qui atteint le CMTS avec succès.

Le message MAP suivant diffusé à partir du CMTS contient une subvention pour le modem B mais aucune instruction pour les modems A et C. Cela indique aux modems A et C qu'ils doivent retransmettre leurs demandes de bande passante.

Lors de la deuxième tentative, les modems A et C doivent incrémenter la puissance de deux à utiliser lorsqu'ils calculent la plage d'intervalles à partir de laquelle choisir. Maintenant, le modem A et le modem C sélectionnent un nombre aléatoire d'intervalles compris entre 0 et 7. Voici le calcul :

(22+1 -1) = (23 - 1) = (8 - 1) = 7 intervalles.

Supposons que le moment où le modem A et le modem C se rendent compte de la nécessité de retransmettre est t₁. Supposons également qu'un autre modem appelé modem D décide de transmettre certaines données en amont au même moment, t₁. Le modem D est sur le point de transmettre une demande de bande passante pour la première fois. Par conséquent, le modem D utilise la valeur d'origine pour le démarrage et le retour arrière des données, à savoir entre 0 et 3 [(22 - 1) = (4 - 1) = 3 intervalles].

Les trois modems sélectionnent ce nombre aléatoire d'opportunités de demande de bande passante à attendre à partir du temps t₁.

• Modem A : 5

• Modem C : 2

• Modem D : 2

Les deux modems C et D attendent deux opportunités de demande de bande passante qui apparaissent après le temps t₁. Les modems C et D transmettent ensuite les requêtes de bande passante en même temps. Ces requêtes de bande passante entrent en collision et n'atteignent donc pas le CMTS. Le modem A permet à cinq opportunités de demande de bande passante de passer. Ensuite, le modem A transmet la demande de bande passante que le CMTS reçoit. La figure 3 montre la collision entre la transmission des modems C et D et la réception réussie de la transmission du modem A. La référence de l'heure de début de cette figure est t₁.

Figure 3 - Exemple de demande de bande passante Partie 2

Le message MAP suivant diffusé à partir du CMTS contient une subvention pour le modem A mais aucune instruction pour les modems C et D. Les modems C et D se rendent compte de la nécessité de retransmettre les requêtes de bande passante. Le modem D est sur le point de transmettre la demande de bande passante pour la deuxième fois. Par conséquent, le modem D utilise le démarrage de la réémission des données + 1 comme puissance de deux pour le calcul de la plage d'intervalles à attendre. Le modem D choisit un intervalle compris entre 0 et 7. Voici le calcul :

(22+1 - 1) = (23 - 1) = (8 - 1) = 7 intervalles.

Le modem C est sur le point de transmettre la demande de bande passante pour la troisième fois. Par conséquent, le modem C utilise le démarrage de la réémission des données + 2 comme puissance de deux à dans le calcul de la plage d'intervalles à attendre. Le modem C choisit un intervalle compris entre 0 et 15. Voici le calcul :

(22+2 - 1) = (24 - 1) = (16 - 1) = 15 intervalles.

Notez que la puissance de deux ici est la même que la valeur de fin de retour arrière des données, qui est quatre. Il s'agit de la puissance maximale de deux valeurs pour un modem sur ce canal en amont. Dans le cycle de transmission suivant des demandes de bande passante, les deux modems sélectionnent le nombre d’opportunités de demande de bande passante à attendre :

• Modem C : 9

• Modem D : 4

Le modem D peut transmettre la demande de bande passante car le modem D attend quatre opportunités de demande de bande passante pour passer. En outre, le modem C est également capable de transmettre la demande de bande passante, car le modem C reporte désormais la transmission pour neuf opportunités de demande de bande passante.

Malheureusement, lorsque le modem C effectue une transmission, une forte rafale de bruit d'entrée interfère avec la transmission et le CMTS ne reçoit pas la demande de bande passante (voir Figure 4). Par conséquent, une fois de plus, le modem C ne voit pas d'octroi dans le prochain message MAP que le CMTS transmet. Ceci fait de la tentative de modem C une quatrième transmission de la demande de bande passante.

Figure 4 - Exemple de demande de bande passante Partie 3

Le modem C a déjà atteint la valeur finale de la sauvegarde des données de 4. Le modem C ne peut pas augmenter la plage utilisée pour choisir un nombre aléatoire d'intervalles à attendre. Par conséquent, le modem C utilise à nouveau 4 comme puissance de deux pour calculer la plage aléatoire. Le modem C utilise toujours des intervalles de 0 à 15 selon ce calcul :

(24 - 1) = (16 - 1) = 15 intervalles.

Lors de la quatrième tentative, le modem C est en mesure d’effectuer une transmission de demande de bande passante réussie en l’absence de conflit ou de bruit.

Les retransmissions de requêtes de bande passante multiples du modem C dans cet exemple montrent ce qui peut se passer sur un canal en amont congestionné. Cet exemple illustre également les problèmes potentiels liés au mode de planification de l'effort le plus efficace et explique pourquoi la planification de l'effort le plus efficace ne convient pas aux services qui nécessitent des niveaux strictement contrôlés de latence et de gigue des paquets.

Priorité du trafic

Lorsque le CMTS a plusieurs demandes de bande passante en attente provenant de plusieurs flux de service, le CMTS examine la priorité de trafic de chaque flux de service pour décider lesquels accorder la bande passante en premier.

Le CMTS accorde un temps de transmission à toutes les demandes en attente provenant de flux de service ayant une priorité plus élevée avant les demandes de bande passante provenant de flux de service ayant une priorité plus faible. Dans des conditions en amont congestionnées, cela conduit généralement à un débit plus élevé pour les flux de services hautement prioritaires par rapport aux flux de services de faible priorité.

Il est important de noter que, bien qu'un flux de service au meilleur effort hautement prioritaire soit plus susceptible de recevoir de la bande passante rapidement, le flux de service est toujours sujet à la possibilité de collisions de demandes de bande passante. Pour cette raison, si la priorité de trafic peut améliorer le débit et les caractéristiques de latence d'un flux de service, la priorité de trafic n'est toujours pas un moyen approprié de fournir une garantie de service pour les applications qui en ont besoin.

Taux minimal réservé

Les flux de services au mieux peuvent recevoir un taux minimum réservé auquel se conformer. Le CMTS garantit qu'un flux de service avec un débit minimal réservé spécifié reçoit de la bande passante de préférence à tous les autres flux de service au mieux, quelle que soit la priorité.

Cette méthode est une tentative de fournir un type de service de type débit d’informations garanti (CIR) analogue à un réseau Frame Relay. Le CMTS dispose de mécanismes de contrôle d'admission pour s'assurer que, sur un amont particulier, le débit minimal réservé combiné de tous les flux de services connectés ne peut pas dépasser la bande passante disponible du canal amont, ou un pourcentage de celle-ci. Vous pouvez activer ces mécanismes avec cette commande par port en amont :

[no] câble en amont port-id-port-admission-control max-reservation-limit

Le paramètre max-reservation-limit a une plage de 10 à 1000 pour cent pour indiquer le niveau d'abonnement par rapport au débit de canal brut disponible que les services de type CIR peuvent consommer. Si vous configurez une limite de réservation maximale supérieure à 100, le service de type CIR en amont peut être surabonné par la limite de pourcentage spécifiée.

Le CMTS ne permet pas d'établir de nouveaux flux de service à débit minimal réservé s'ils font que le port en amont dépasse le pourcentage maximum-reservation-limit configuré de la bande passante du canal en amont disponible. Les flux de service à débit minimal réservé sont toujours sujets à des collisions potentielles de demandes de bande passante. En tant que tels, les flux de services à débit minimal réservé ne peuvent fournir une véritable garantie d'un débit particulier, en particulier dans des conditions extrêmement congestionnées. En d'autres termes, le CMTS ne peut garantir qu'un débit de service minimal réservé est en mesure d'atteindre un débit en amont garanti particulier si le CMTS est en mesure de recevoir toutes les demandes de bande passante requises du modem câble. Cette exigence peut être réalisée si vous faites du flux de service un flux de service d'interrogation en temps réel (RTPS) au lieu d'un flux de service au mieux. Consultez la section Real Time Polling Service (RTPS) pour plus d'informations.

Demandes de bande passante Piggyback

Lorsqu’un flux de service au mieux en amont transmet des trames à un débit élevé, il est possible de replacer les requêtes de bande passante sur des trames de données en amont plutôt que d’avoir une transmission séparée des requêtes de bande passante. Les détails de la prochaine demande de bande passante sont simplement ajoutés à l’en-tête d’un paquet de données transmis en amont au CMTS.

Cela signifie que la demande de bande passante n'est pas sujette à conflit et qu'elle a donc beaucoup plus de chances d'atteindre le CMTS. Le concept de demande de bande passante de retour de données réduit le temps nécessaire à une trame Ethernet pour atteindre l’équipement du client (CPE) de l’utilisateur final, car le temps que la trame prend dans la transmission en amont diminue. En effet, le modem n'a pas besoin de passer par le processus de réémission et de tentative de transmission de demande de bande passante, qui peut être sujet à des retards.

Le piratage des requêtes de bande passante se produit généralement dans ce scénario :

Pendant que le modem câble attend de transmettre une trame, par exemple X, en amont, le modem reçoit une autre trame, par exemple Y, d’un CPE pour transmettre en amont. Le modem câble ne peut pas ajouter les octets de la nouvelle trame Y à la transmission, car cela implique l'utilisation d'un temps en amont supérieur à celui accordé au modem. À la place, le modem remplit un champ dans l’en-tête DOCSIS de la trame X pour indiquer le temps de transmission requis pour la trame Y.

Le CMTS reçoit la trame X ainsi que les détails d’une demande de bande passante pour le compte de Y. En fonction de la disponibilité, le CMTS accorde au modem un temps de transmission supplémentaire pour le compte de Y.

En termes très prudents, pas moins de 5 millisecondes s'écoulent entre la transmission d'une demande de bande passante et la réception de l'allocation de bande passante, ainsi qu'un accusé de réception MAP qui alloue du temps pour la transmission de données. Cela signifie que, pour que le recouvrement se produise, le modem câble doit recevoir des trames de l’équipement d’abonné dans un délai inférieur à 5 ms l’un de l’autre.

Cela est remarquable car un codec VoIP type G.711 utilise généralement une période d'intertrame de 10 ou 20 ms. Un flux VoIP type qui fonctionne sur un flux de service au mieux ne peut pas tirer parti du piggyback.

Concaténation

Lorsqu’un flux de service au mieux en amont transmet des trames à un débit élevé, le modem câble peut joindre quelques trames ensemble et demander l’autorisation de transmettre les trames en même temps. C'est ce qu'on appelle la concaténation. Le modem câble doit transmettre une seule demande de bande passante au nom de toutes les trames d’un groupe de trames concaténées, ce qui améliore l’efficacité.

La concaténation a tendance à se produire dans des circonstances similaires à la piggyback, sauf que la concaténation nécessite que plusieurs trames soient mises en file d’attente à l’intérieur du modem câble lorsque le modem décide de transmettre une demande de bande passante. Cela signifie que la concaténation a tendance à se produire à des débits de trames moyens plus élevés que le piggyback. En outre, les deux mécanismes fonctionnent généralement ensemble pour améliorer l'efficacité du trafic au mieux.

Le champ Maximum Concatenated Burst que vous pouvez configurer pour un flux de service limite la taille maximale d'une trame concaténée qu'un flux de service peut transmettre. Vous pouvez également utiliser la commande cable default-phy-burst pour limiter la taille d'une trame concaténée et la taille de rafale maximale dans le profil de modulation de canal en amont.

La concaténation est activée par défaut sur les ports en amont de la gamme Cisco uBR de CMTS. Cependant, vous pouvez contrôler la concaténation par port en amont avec la commande d'interface de câble [no] cable en amont de port en amont concaténation [docsis10].

Si vous configurez le paramètre docsis10, la commande s'applique uniquement aux modems câble fonctionnant en mode DOCSIS 1.0.

Si vous apportez des modifications à cette commande, les modems câble doivent être réenregistrés sur le CMTS pour que les modifications prennent effet. Les modems sur l'amont affecté doivent être réinitialisés. Un modem câble apprend si la concaténation est autorisée au moment où le modem effectue l'enregistrement dans le cadre du processus de mise en ligne.

Fragmentation

La transmission en amont des trames de grande taille prend beaucoup de temps. Ce délai de transmission est appelé délai de sérialisation. Les trames en amont particulièrement volumineuses peuvent prendre tellement de temps à transmettre qu’elles peuvent retarder de manière inoffensive les paquets qui appartiennent à des services sensibles au temps, par exemple, la VoIP. Ceci est particulièrement vrai pour les cadres concaténés de grande taille. C’est pourquoi la fragmentation a été introduite dans DOCSIS 1.1 afin que les trames de grande taille puissent être divisées en trames plus petites pour la transmission en rafales distinctes qui prennent chacune moins de temps à transmettre.

La fragmentation permet d’entremêler de petites trames sensibles au temps entre les fragments de grandes trames plutôt que d’attendre la transmission de la grande trame entière. La transmission d'une trame sous forme de fragments multiples est légèrement moins efficace que la transmission d'une trame en une rafale en raison de l'ensemble supplémentaire d'en-têtes DOCSIS qui doivent accompagner chaque fragment. Cependant, la flexibilité que la fragmentation ajoute au canal en amont justifie la surcharge supplémentaire.

Les modems câble fonctionnant en mode DOCSIS 1.0 ne peuvent pas effectuer de fragmentation.

La fragmentation est activée par défaut sur les ports en amont de la gamme Cisco uBR de CMTS. Cependant, vous pouvez activer ou désactiver la fragmentation par port en amont à l'aide de la commande d'interface de câble [no] cable en amont de port en amont et d'id de fragmentation.

Vous n'avez pas besoin de réinitialiser les modems câble pour que la commande prenne effet. Cisco recommande d'activer la fragmentation. La fragmentation se produit normalement lorsque le CMTS estime qu’une trame de données volumineuse peut interférer avec la transmission de trames à temps limité ou certains événements de gestion DOCSIS périodiques.

Vous pouvez forcer les modems câble DOCSIS 1.1/2.0 à fragmenter toutes les trames de grande taille à l'aide de la commande d'interface de câble [no] cable-amont port-id fragment-force [threshold number-of-fragments].

Par défaut, cette fonction est désactivée. Si vous ne spécifiez pas de valeurs de seuil et de nombre de fragments dans la configuration, le seuil est défini sur 2 000 octets et le nombre de fragments est défini sur 3. La commande fragment-force compare le nombre d'octets qu'un flux de service demande pour transmission avec le paramètre de seuil spécifié. Si la taille de la demande est supérieure au seuil, le CMTS accorde la bande passante au flux de service en “ nombre de fragments ” pièces de taille égale.

Par exemple, supposez que pour un fragment-force en amont particulier est activé avec une valeur de 2000 octets pour le seuil et 3 pour le nombre de fragments. Supposons ensuite qu’une requête de transmission d’une rafale de 3 000 octets arrive. Étant donné que 3 000 octets sont supérieurs au seuil de 2 000 octets, la subvention doit être fragmentée. Comme le nombre de fragments est défini sur 3, le temps de transmission est de trois subventions de taille égale de 1 000 octets chacune.

Veillez à ce que les tailles des fragments individuels ne dépassent pas la capacité du type de carte de ligne de câble utilisé. Pour les cartes de ligne MC5x20S, le plus grand fragment individuel ne doit pas dépasser 2 000 octets, et pour les autres cartes de ligne, dont MC28U, MC5x20U et MC5x20H, le plus grand fragment individuel ne doit pas dépasser 4 000 octets.

Service de subventions non sollicitées (UGS)

Le service de subvention non sollicitée (UGS) accorde des subventions périodiques pour un flux de service en amont sans qu'un modem câble ne soit nécessaire pour transmettre des demandes de bande passante. Ce type de service convient aux applications qui génèrent des trames de taille fixe à intervalles réguliers et qui ne tolèrent pas la perte de paquets. La voix sur IP est l'exemple classique.

Comparez le système de planification UGS à un créneau horaire dans un système de multiplexage temporel (TDM) tel qu'un circuit T1 ou E1. UGS offre un débit et une latence garantis, qui à leur tour fournit un flux continu d'intervalles périodiques fixes à transmettre sans que le client ait besoin de demander ou de se disputer périodiquement la bande passante. Ce système est parfait pour la VoIP car le trafic vocal est généralement transmis en continu sous forme de flux de données périodiques de taille fixe.

UGS a été conçu en raison de l'absence de garanties pour la latence, la gigue et le débit en mode de planification au mieux. Le mode de planification au mieux ne garantit pas qu’une trame donnée peut être transmise à un moment donné et, dans un système congestionné, il n’y a aucune garantie qu’une trame particulière puisse être transmise.

Notez que bien que les flux de services de type UGS soient le type de flux de services le plus approprié pour transmettre le trafic porteur VoIP, ils ne sont pas considérés comme appropriés pour les applications Internet classiques telles que le Web, la messagerie électronique ou le P2P. En effet, les applications Internet classiques ne génèrent pas de données à intervalles réguliers fixes et peuvent en fait passer des périodes importantes sans transmettre de données du tout. Si un flux de service UGS est utilisé pour transmettre le trafic Internet classique, le flux de service peut rester inutilisé pendant de longues périodes lorsque l'application arrête brièvement les transmissions. Cela conduit à des subventions UGS inutilisées qui représentent un gaspillage de ressources de bande passante en amont qui n'est pas souhaitable.

Les flux de services UGS sont généralement établis de manière dynamique lorsqu'ils sont nécessaires plutôt que d'être provisionnés dans le fichier de configuration DOCSIS. Un modem câble avec ports VoIP intégrés peut généralement demander au CMTS de créer un flux de service UGS approprié lorsque le modem détecte qu'un appel téléphonique VoIP est en cours.

Cisco vous recommande de ne pas configurer de flux de service UGS dans un fichier de configuration DOCSIS, car cette configuration maintient le flux de service UGS actif tant que le modem câble est en ligne, que des services l'utilisent ou non. Cette configuration gaspille la bande passante en amont car un flux de service UGS réserve constamment du temps de transmission en amont pour le compte du modem câble. Il est bien préférable de permettre la création et la suppression dynamiques du flux de service UGS de sorte qu'UGS soit actif au besoin.

Voici les paramètres les plus couramment utilisés qui définissent un flux de service UGS :

• Taille de subvention non sollicitée (G) : taille de chaque subvention périodique en octets.

• Intervalle de subvention nominal (I) : intervalle en microsecondes entre les subventions.

• Tolerated Grant Jitter (J) : variation autorisée en microsecondes par rapport aux subventions périodiques. En d'autres termes, il s'agit de la marge de manoeuvre dont dispose le SMTS lorsqu'il tente de planifier une subvention UGS à temps.

Lorsqu'un flux de service UGS est actif, toutes les (I) millisecondes, le CMTS offre la possibilité pour le flux de service de transmettre à la taille de subvention non sollicitée (G) octets. Bien que, idéalement, le SMTS offre la subvention exactement toutes les (I) millisecondes, il peut être en retard d'un maximum de (J) millisecondes.

La figure 5 montre un calendrier qui montre comment les subventions UGS peuvent être attribuées avec une taille de subvention donnée, un intervalle de subvention et une gigue tolérée.

Figure 5 - Calendrier indiquant les subventions UGS périodiques

Les blocs à motifs verts représentent l'heure à laquelle le CMTS consacre le temps de transmission en amont à un flux de service UGS.

Service d'interrogation en temps réel (RTPS)

Le service d'interrogation en temps réel (RTPS) fournit des opportunités de demande de bande passante non basée sur des conflits périodiques, de sorte qu'un flux de service dispose de temps dédié pour transmettre des demandes de bande passante. Seul le flux de service RTPS est autorisé à utiliser cette opportunité de demande de bande passante de monodiffusion. Les autres modems câble ne peuvent pas provoquer de collision de demande de bande passante.

Le protocole RTPS est adapté aux applications qui génèrent des trames de longueur variable sur une base semi-périodique et nécessitent un débit minimal garanti pour fonctionner efficacement. La téléphonie vidéo sur IP ou les jeux en ligne multi-joueurs en sont des exemples typiques.

RTPS est également utilisé pour le trafic de signalisation VoIP. Bien que le trafic de signalisation VoIP n'ait pas besoin d'être transmis avec une latence ou une instabilité extrêmement faibles, la VoIP doit avoir une forte probabilité d'atteindre le CMTS dans un délai raisonnable. Si vous utilisez RTPS plutôt que la planification au mieux, vous pouvez être assuré que la signalisation vocale n'est pas significativement retardée ou abandonnée en raison de collisions répétées de requêtes de bande passante.

Un flux de service RTPS possède généralement les attributs suivants :

• Intervalle d'interrogation nominal : intervalle en microsecondes entre les opportunités de demande de bande passante de monodiffusion.

• Tolerated Poll Jitter : variation autorisée en microsecondes par rapport aux sondages périodiques. Autrement dit, c'est la marge de manoeuvre dont dispose le CMTS lorsqu'il tente de planifier une opportunité de demande de bande passante monodiffusion RTPS à temps.

La Figure 6 montre une chronologie qui montre comment les sondages RTPS sont alloués avec un intervalle d'interrogation nominal donné et une gigue de sondage tolérée.

Figure 6 : chronologie montrant un interrogation RTPS périodique

Les petits blocs à motifs verts représentent le temps pendant lequel le CMTS offre un flux de service RTPS une opportunité de demande de bande passante de monodiffusion.

Lorsque le CMTS reçoit une demande de bande passante pour le compte d'un flux de service RTPS, le CMTS traite la demande de bande passante de la même manière qu'une demande provenant d'un flux de service “ au mieux ”. Cela signifie qu'en plus des paramètres ci-dessus, des propriétés telles que le débit de trafic soutenu maximal et la priorité de trafic doivent être incluses dans une définition de flux de service RTPS. Un flux de service RTPS contient généralement un débit de trafic minimal réservé afin de s'assurer que le trafic associé au flux de service peut recevoir une garantie de bande passante validée.

Service de subvention non sollicité avec détection d'activité (UGS-AD)

Le service de subvention non sollicité avec détection d'activité (UGS-AS) affecte le temps de transmission de type UGS à un flux de service uniquement lorsque UGS-AS a réellement besoin de transmettre des paquets. Lorsque le CMTS détecte que le modem câble n'a pas transmis de trames pendant une certaine période, le CMTS offre des opportunités de demande de bande passante de type RTPS au lieu de subventions de type UGS. Si le CMTS détecte par la suite que le flux de service effectue des demandes de bande passante, le CMTS rétablit le flux de service en proposant des subventions de type UGS et cesse d'offrir des opportunités de demande de bande passante de type RTPS.

UGS-AD est généralement utilisé dans une situation où le trafic VoIP qui utilisait la détection d'activité vocale (VAD) était transmis. La détection de l'activité vocale entraîne l'arrêt de la transmission des trames VoIP par le point d'extrémité VoIP si UGS-AD détecte une pause dans la parole de l'utilisateur. Bien que ce comportement puisse économiser de la bande passante, il peut causer des problèmes de qualité de la voix, en particulier si le mécanisme de détection d'activité VAD ou UGS-AD s'active légèrement après que la partie finale commence à reprendre la parole. Cela peut conduire à un clic ou une sonnerie lorsqu'un utilisateur reprend la parole après un silence. C'est pourquoi UGS-AD n'est pas largement déployé.

Émettez la commande de configuration CMTS globale cable service flow inactivité-threshold threshold-in-seconds pour définir la période après laquelle le CMTS bascule un flux de service UGS-AD inactif du mode UGS vers le mode RTPS.

La valeur par défaut du paramètre threshold-in-seconds est de 10 secondes. Les flux de service UGS-AD possèdent généralement les attributs d'un flux de service UGS et l'intervalle d'interrogation nominal et l'attribut de gigue d'interrogation toléré associé aux flux de service RTPS.

Service d'interrogation en temps non réel (nRTPS)

Le mode de planification nRTPS (service d'interrogation non en temps réel) est essentiellement le même que RTPS, sauf que nRTPS est généralement associé à des services non interactifs tels que les transferts de fichiers. Le composant non en temps réel peut impliquer que l'intervalle d'interrogation nominal pour les opportunités de demande de bande passante de monodiffusion n'est pas exactement régulier ou peut se produire à un rythme inférieur à un par seconde.

Certains opérateurs de réseau câblé peuvent choisir d’utiliser nRTPS au lieu des flux de service RTPS pour transmettre le trafic de signalisation vocale.

Algorithmes de planification

Avant de discuter des spécificités du planificateur conforme DOCSIS et du planificateur de mise en file d'attente à faible latence, vous devez comprendre les compromis que vous devez effectuer pour déterminer les caractéristiques d'un planificateur en amont. Bien que la discussion sur les algorithmes de planification se concentre principalement sur le mode de planification UGS, la discussion s'applique également aux services de style RTPS.

Lorsque vous décidez de planifier des flux de services UGS, il n'y a pas beaucoup d'options flexibles. Vous ne pouvez pas faire modifier la taille de subvention ou l'intervalle de subvention des flux de service UGS par le planificateur, car une telle modification entraîne l'échec complet des appels VoIP. Cependant, si vous modifiez la gigue, les appels fonctionnent, même si cela peut augmenter la latence de l'appel. En outre, la modification du nombre maximal d'appels autorisés sur un appel en amont n'affecte pas la qualité des appels individuels. Par conséquent, tenez compte de ces deux facteurs principaux lorsque vous planifiez un grand nombre de flux de services UGS :

• Jaillir

• Capacité de flux de service UGS par amont

Jaillir

Une gigue de subvention tolérée est spécifiée comme l'un des attributs d'un flux de service UGS ou RTPS. Cependant, le support simultané de certains flux de services avec une gigue tolérée très faible et d'autres avec de très grandes quantités de gigue peut être inefficace. En général, vous devez faire un choix uniforme quant au type de gigue que les flux de service subissent sur un amont.

Si de faibles niveaux de gigue sont requis, le planificateur doit être inflexible et rigide lorsqu'il planifie des subventions. Par conséquent, le planificateur doit imposer des restrictions sur le nombre de flux de service UGS pris en charge sur un amont.

Les niveaux de gigue n'ont pas toujours besoin d'être extrêmement bas pour la VoIP grand public normale, car la technologie de tampon de gigue peut compenser les niveaux élevés de gigue. Les mémoires tampon VoIP adaptatives modernes peuvent compenser plus de 150 ms de gigue. Cependant, un réseau VoIP ajoute la quantité de mise en mémoire tampon qui se produit à la latence des paquets. Des niveaux élevés de latence peuvent contribuer à une expérience VoIP plus pauvre.

Capacité de flux de services UGS par flux ascendant

Les attributs de la couche physique tels que la largeur du canal, le schéma de modulation et la force de correction d'erreur déterminent la capacité physique d'une source amont. Cependant, le nombre de flux de service UGS simultanés que le amont peut prendre en charge dépend également de l'algorithme du planificateur.

Si des niveaux de gigue extrêmement bas ne sont pas nécessaires, vous pouvez assouplir la rigidité du planificateur et prendre en charge un plus grand nombre de flux de service UGS que le amont peut prendre en charge simultanément. Vous pouvez optimiser l'efficacité du trafic non vocal en amont si vous assouplissez les exigences de gigue.

Remarque : différents algorithmes de planification peuvent permettre à un canal amont particulier de prendre en charge différents nombres de flux de services UGS et RTPS. Cependant, ces services ne peuvent pas utiliser 100 % de la capacité en amont dans un système DOCSIS. En effet, le canal en amont doit dédier une partie au trafic de gestion DOCSIS, comme les messages de maintenance initiaux que les modems câble utilisent pour établir un contact initial avec le CMTS, et le trafic de maintenance de station utilisé pour s'assurer que les modems câble peuvent maintenir la connectivité au CMTS.

Planificateur conforme à DOCSIS

Le planificateur conforme DOCSIS est le système par défaut pour planifier les services en amont sur un système CMTS Cisco uBR. Ce planificateur a été conçu pour minimiser la gigue que subissent les flux de services UGS et RTPS. Cependant, ce planificateur vous permet toujours de conserver un certain degré de flexibilité afin d'optimiser le nombre d'appels UGS simultanés par amont.

Le planificateur conforme DOCSIS préalloue du temps en amont à l'avance pour les flux de service UGS. Avant toute autre allocation de bande passante prévue, le CMTS réserve à l'avenir du temps pour les subventions qui appartiennent aux flux de services UGS actifs afin de s'assurer qu'aucun des autres types de flux de services ou de trafic ne remplace les subventions UGS et provoque une gigue significative.

Si le CMTS reçoit des demandes de bande passante pour le compte de flux de services de type Meilleur effort, le CMTS doit programmer le temps de transmission pour les flux de services de meilleur effort autour des subventions UGS préattribuées afin de ne pas avoir d'incidence sur la planification en temps opportun de chaque subvention UGS.

Configuration

Le planificateur conforme DOCSIS est le seul algorithme de planificateur en amont disponible pour le logiciel Cisco IOS versions 12.3(9a)BCx et antérieures. Par conséquent, ce planificateur ne nécessite aucune commande de configuration pour l'activation.

Pour les versions du logiciel Cisco IOS 12.3(13a)BC et ultérieures, le planificateur conforme DOCSIS est l'un des deux algorithmes de planificateur alternatifs, mais il est défini comme planificateur par défaut. Vous pouvez activer le planificateur conforme DOCSIS pour un, tous ou certains de ces types de planification :

• UGS

• RTPS

• NRTPS

Vous pouvez explicitement activer le planificateur conforme DOCSIS pour chacun de ces types de planification avec le type de planification câble amont port amont [nrtps] | rtps | ugs] mode docsis cable interface command.

L'utilisation d'un planificateur conforme DOCSIS fait partie de la configuration par défaut. Par conséquent, vous devez exécuter cette commande uniquement si vous revenez de l'algorithme du planificateur de mise en file d'attente à faible latence autre que par défaut. Pour plus d'informations, reportez-vous à la section Planificateur de mise en file d'attente à faible latence.

Contrôle des admissions

L'un des grands avantages du planificateur conforme à DOCSIS est que ce planificateur s'assure que les flux de service UGS ne surabonnent pas à l'amont. Si un nouveau flux de services UGS doit être établi et que le planificateur découvre qu'un calendrier de subventions n'est pas possible car il ne reste plus de place, le CMTS rejette le nouveau flux de services UGS. Si les flux de service UGS qui transmettent le trafic VoIP sont autorisés à surabonner un canal en amont, la qualité de tous les appels VoIP est sévèrement dégradée.

Afin de démontrer comment le planificateur conforme à DOCSIS s'assure que les flux de service UGS ne surabonnent jamais au amont, reportez-vous aux figures de cette section. Les figures 7, 8 et 9 indiquent les lignes de temps d'allocation de bande passante.

Dans tous ces chiffres, les sections en couleur des modèles indiquent le moment où les modems câble reçoivent des subventions pour le compte de leurs flux de services UGS. Aucune autre transmission en amont à partir d’autres modems câble ne peut se produire pendant cette période. La partie grise de la ligne de temps n’est pas encore allouée à la bande passante. Les modems câble utilisent cette fois pour transmettre des requêtes de bande passante. Le CMTS pourra utiliser ce temps pour planifier d'autres types de services.

Figure 7 - Le planificateur conforme DOCSIS préplanifie trois flux de service UGS

Ajoutez deux autres flux de services UGS de même taille de subvention et intervalle de subvention. Néanmoins, le planificateur n'a aucun problème à les préprogrammer.

Figure 8 - Le planificateur conforme DOCSIS préplanifie cinq flux de service UGS

Si vous ajoutez deux flux de services UGS supplémentaires, vous remplissez toute la bande passante ascendante disponible.

Figure 9 - Les flux de services UGS consomment toute la bande passante ascendante disponible

De toute évidence, le planificateur ne peut pas admettre d'autres flux de service UGS ici. Par conséquent, si un autre flux de services UGS tente de devenir actif, le planificateur conforme DOCSIS se rend compte qu'il n'y a pas de place pour d'autres subventions et empêche l'établissement de ce flux de services.

Note : Il est impossible de remplir complètement un amont avec des flux de services UGS comme le montrent les figures suivantes. Le planificateur doit prendre en charge d'autres types importants de trafic, par exemple les keepalives de maintenance de la station et le trafic de données au mieux. En outre, la garantie d'éviter la sursouscription avec le planificateur conforme DOCSIS ne s'applique que si tous les modes de planification de flux de service, à savoir UGS, RTPS et nRTPS, utilisent le planificateur conforme DOCSIS.

Bien que la configuration explicite du contrôle d'admission ne soit pas nécessaire lorsque vous utilisez le planificateur conforme à DOCSIS, Cisco recommande de s'assurer que l'utilisation du canal en amont n'augmente pas jusqu'à des niveaux qui peuvent avoir un impact négatif sur le trafic au mieux de l'effort. Cisco recommande également que l'utilisation totale du canal en amont ne dépasse pas 75 % pendant des périodes importantes. Il s'agit du niveau d'utilisation en amont où les services au mieux commencent à connaître une latence beaucoup plus élevée et un débit plus lent. Les services UGS fonctionnent toujours, quelle que soit l'utilisation en amont.

Si vous voulez limiter la quantité de trafic admis sur un amont particulier, configurez le contrôle d'admission pour les flux de services UGS, RTPS, NRTPS, UGS-AD ou best effort avec l'interface globale, par câble ou par commande en amont. Le paramètre le plus important est le champ exclusif threshold-percent.

cable [upstream upstream-number] admission-control us-bandwidth
scheduling-type UGS|AD-UGS|RTPS|NRTPS|BE minor minor-threshold-percent 
major major-threshold-percent exclusive exclusive-threshold-percent
[non-exclusive non-excl-threshold-percent]

Voici les paramètres :

• [numéro_source>] : Spécifiez ce paramètre si vous voulez appliquer la commande à un amont particulier plutôt qu'à une interface de câble ou globalement.

• <UGS|AD-UGS|RTPS|NRTPS|BE> : Ce paramètre spécifie le mode de planification des flux de service auxquels vous voulez appliquer le contrôle d'admission.

• <mineur-threshold-percent> : Ce paramètre indique le pourcentage d'utilisation en amont par le type de planification configuré auquel une alarme mineure est envoyée à une station d'administration réseau.

• <pourcentage de seuil majeur> : Ce paramètre spécifie le pourcentage d'utilisation en amont par le type de planification configuré auquel une alarme majeure est envoyée à une station d'administration réseau. Cette valeur doit être supérieure à la valeur que vous avez définie pour le paramètre <minor-threshold-percent>.

• <seuil-exclusif> : Ce paramètre représente le pourcentage d'utilisation en amont réservé exclusivement au type de planification spécifié. Si vous ne spécifiez pas la valeur de <non-excl-threshold-percent>, cette valeur représente la limite maximale d'utilisation pour ce type de flux de service. Cette valeur doit être supérieure à la valeur <majeur-threshold-percent>.

• <non excl-threshold-percent> : Ce paramètre représente le pourcentage d'utilisation en amont au-dessus du <seuil exclusif-pourcentage> que ce type de planification peut utiliser, tant qu'un autre type de planification ne l'utilise pas déjà.

Par exemple, supposez que vous voulez limiter les flux de service UGS à 60 % de la bande passante ascendante totale disponible. Supposons également que des stations de gestion de réseau vous ont averti que si le pourcentage d'utilisation en amont dû aux flux de services UGS a augmenté de plus de 40 %, une alarme mineure doit être envoyée et plus de 50 %, une alarme majeure doit être envoyée. Émettez la commande suivante :

cable admission-control us-bandwidth schedule-type UGS minor 40 major 50 exclusif 60

Planification du trafic au mieux à l'aide de la fragmentation

Le planificateur conforme DOCSIS planifie simplement le trafic au mieux autour des subventions UGS ou RTPS préallouées. Les figures de cette section illustrent ce comportement.

Figure 10 - Subventions pour les meilleurs efforts en attente de planification

La Figure 10 montre que le flux en amont a trois flux de service UGS avec la même taille de subvention et l'intervalle de subvention pré-planifié. L’amont reçoit des demandes de bande passante pour le compte de trois flux de services distincts, A, B et C. Le flux de service A demande un temps de transmission moyen, le flux de service B demande un temps de transmission faible et le flux de service C demande un temps de transmission important.

Accorder une priorité égale à chacun des flux de services au mieux. En outre, supposons que le SMTC reçoit les demandes de bande passante pour chacune de ces subventions dans l’ordre A puis B, puis C. Le CMTS alloue d’abord le temps de transmission pour les subventions dans le même ordre. La figure 11 montre comment le planificateur conforme DOCSIS alloue ces subventions.

Figure 11 - Subventions au meilleur effort prévues autour des subventions de flux de services UGS fixes

Le planificateur est en mesure de répartir les subventions pour A et B dans l'écart entre les deux premiers blocs de subventions UGS. Cependant, la subvention pour C est plus importante que tout écart disponible. Par conséquent, le planificateur conforme DOCSIS divise la subvention pour C autour du troisième bloc de subventions UGS en deux subventions plus petites appelées C1 et C2. La fragmentation évite les retards pour les subventions UGS et veille à ce que ces subventions ne soient pas sujettes à la gigue provoquée par le trafic au mieux.

La fragmentation augmente légèrement la surcharge du protocole DOCSIS associée à la transmission des données. Pour chaque fragment supplémentaire transmis, un jeu supplémentaire d'en-têtes DOCSIS doit également être transmis. Cependant, sans fragmentation, l'organisateur ne peut pas interlaisser efficacement les subventions au meilleur effort entre les subventions UGS fixes. La fragmentation ne peut pas se produire pour les modems câble fonctionnant en mode DOCSIS 1.0.

Priorité

Le planificateur conforme DOCSIS place les subventions en attente d'allocation dans des files d'attente en fonction de la priorité du flux de services auquel appartient la subvention. Il y a huit priorités DOCSIS avec zéro comme valeur la plus faible et sept comme valeur la plus élevée. Chacune de ces priorités a une file d'attente associée.

Le planificateur conforme à DOCSIS utilise un mécanisme de mise en file d'attente à priorité stricte pour déterminer quand des allocations de priorité différente sont affectées du temps de transmission. En d'autres termes, toutes les subventions stockées dans les files d'attente de priorité élevée doivent être servies avant les subventions dans les files d'attente de priorité inférieure.

Par exemple, supposez que le planificateur conforme à DOCSIS reçoit cinq subventions en peu de temps dans les ordres A, B, C, D, E et F. Le planificateur met en file d'attente chacune des subventions dans la file d'attente qui correspond à la priorité du flux de service de la subvention.

Figure 12 - Subventions assorties de priorités différentes

Le planificateur conforme à DOCSIS planifie les subventions au meilleur effort autour des subventions UGS pré-planifiées qui apparaissent comme des blocs modélisés dans la Figure 12. La première action du planificateur conforme DOCSIS consiste à vérifier la file d'attente de priorité la plus élevée. Dans ce cas, la file d'attente prioritaire 7 a des subventions prêtes à être planifiées. Le planificateur continue et alloue du temps de transmission pour les subventions B et E. Notez que la subvention E doit être fragmentée de sorte que la subvention n'interfère pas avec le calendrier des subventions UGS préattribuées.

Figure 13 - Planification des subventions de priorité 7

Le planificateur s'assure que toutes les subventions de priorité 7 reçoivent du temps de transmission. Ensuite, le planificateur vérifie la file d'attente prioritaire 6. Dans ce cas, la file d'attente de priorité 6 est vide, de sorte que le planificateur passe à la file d'attente de priorité 5 qui contient la priorité C.

Figure 14 - Planification des subventions de priorité 5

Le planificateur procède ensuite de la même manière dans les files d'attente de priorité inférieure jusqu'à ce que toutes les files d'attente soient vides. S'il y a un grand nombre de subventions à programmer, les nouvelles demandes de bande passante peuvent atteindre le CMTS avant que le planificateur conforme DOCSIS ne termine l'allocation du temps de transmission à toutes les subventions en attente. Supposons que le CMTS reçoive une demande de bande passante G de la priorité 6 à ce stade de l'exemple.

Figure 15 - Une subvention de priorité 6 est mise en file d'attente

Même si accorde A, F et D une attente plus longue que la nouvelle subvention G mise en file d'attente, le planificateur conforme DOCSIS doit ensuite allouer le temps de transmission à G car G a la priorité la plus élevée. Cela signifie que la prochaine allocation de bande passante du planificateur conforme DOCSIS sera G, A puis D (voir Figure 16).

Figure 16 - Planification des subventions de priorité 6 et de priorité 2

La prochaine subvention à programmer est F, si vous supposez qu'aucune subvention de priorité supérieure n'entre dans le système de mise en file d'attente dans le temps moyen.

Le planificateur conforme DOCSIS dispose de deux files d'attente supplémentaires qui n'ont pas été mentionnées dans les exemples. La première file d'attente est la file d'attente utilisée pour planifier le trafic de veille de maintenance périodique de la station afin de maintenir les modems câble en ligne. Cette file d'attente est utilisée pour planifier les opportunités pour les modems câble d'envoyer le trafic de keepalive périodique CMTS. Lorsque le planificateur conforme DOCSIS est actif, cette file d'attente est traitée avant toutes les autres files d'attente. La seconde est une file d'attente pour les subventions allouées aux flux de services avec un taux minimal réservé (CIR) spécifié. Le planificateur traite cette file d'attente CIR comme une file d'attente de priorité 8 afin de s'assurer que les flux de service avec un débit garanti reçoivent le débit minimal requis.

Subventions DOCSIS 1.0 non fragmentées

D'après les exemples de la section précédente, les subventions doivent parfois être fragmentées en plusieurs parties afin de s'assurer que la gigue ne soit pas induite dans les subventions UGS préaffectées. Cela peut être un problème pour les modems câble qui fonctionnent en mode DOCSIS 1.0 sur les segments en amont avec une quantité importante de trafic UGS, car un modem câble DOCSIS 1.0 peut demander de transmettre une trame trop grande pour s'adapter à la prochaine opportunité de transmission disponible.

Voici un autre exemple, qui suppose que le planificateur reçoit de nouvelles subventions A et B dans cet ordre. Supposez également que les deux subventions ont la même priorité, mais que la subvention B est pour un modem câble qui fonctionne en mode DOCSIS 1.0.

Figure 17 - Subventions en attente DOCSIS 1.1 et DOCSIS 1.0

Le planificateur tente d'allouer du temps pour accorder un A en premier. Ensuite, le planificateur tente d'allouer la prochaine opportunité de transmission disponible à accorder B. Toutefois, il n'y a pas de place pour que la subvention B reste non fragmentée entre A et le bloc suivant des subventions UGS (voir Figure 18).

Figure 18 - Octroi d'une subvention B DOCSIS 1.0 reporté

C'est pourquoi la subvention B est reportée jusqu'à la fin du deuxième bloc de subventions UGS lorsque la subvention B est disponible. Notez qu'il y a maintenant de l'espace inutilisé avant le deuxième bloc de subventions UGS. Les modems câble utilisent cette fois pour transmettre des requêtes de bande passante au CMTS, mais cela représente une utilisation inefficace de la bande passante.

Revoyez cet exemple et ajoutez deux flux de service UGS supplémentaires au planificateur. Bien que la subvention A puisse être fragmentée, il n'y a aucune possibilité que la subvention B non fragmentable soit prévue parce que la subvention B est trop importante pour s'adapter à des blocs de subventions UGS. Cette situation empêche le modem câble associé à grant B de transmettre de grandes trames en amont.

Figure 19 - Impossible de planifier la subvention B DOCSIS 1.0

Vous pouvez autoriser l'organisateur à simplement repousser, ou légèrement retarder un bloc de subventions UGS afin de faire de la place pour la subvention B, mais cette action provoque une gigue dans le flux de service UGS. Pour le moment, si vous supposez vouloir minimiser la gigue, c'est une solution inacceptable.

Afin de surmonter ce problème avec de grandes subventions DOCSIS 1.0 non fragmentables, le planificateur conforme DOCSIS planifie périodiquement des blocs de temps amont aussi importants que la trame la plus importante qu'un modem câble DOCSIS 1.0 peut transmettre. Le planificateur le fait avant que les flux de service UGS ne soient planifiés. Cette durée équivaut généralement à environ 2000 octets de transmission en amont, et est appelée le ” de blocs non fragmentables “ ou le ” de blocs libres UGS “.

Le planificateur conforme DOCSIS ne place aucune subvention de type UGS ou RTPS dans les temps alloués au trafic non fragmentable afin de garantir qu'il y a toujours une possibilité pour les subventions DOCSIS 1.0 importantes à planifier. Dans ce système, la réservation de temps pour le trafic DOCSIS 1.0 non fragmentable réduit le nombre de flux de service UGS que le amont peut prendre en charge simultanément.

La Figure 20 montre le bloc non fragmentable en bleu et quatre flux de services UGS avec la même taille de subvention et le même intervalle de subvention. Vous ne pouvez pas ajouter un autre flux de service UGS de la même taille de subvention et d'intervalle de subvention à ce flux en amont, car les subventions UGS ne sont pas autorisées à être planifiées dans la région de bloc non fragmentable bleue.

Figure 20 - Le bloc non fragmentable : Aucune autre subvention UGS ne peut être admise

Même si le bloc non fragmentable est planifié moins souvent que la période des subventions UGS, ce bloc a tendance à provoquer un espace de bande passante non allouée aussi important qu'il l'est lui-même entre tous les blocs de subventions UGS. Cela offre de nombreuses possibilités de prévoir des subventions non fragmentables importantes.

Revenez à l'exemple de subvention A et DOCSIS 1.0 Grant B. Vous pouvez voir qu'avec le bloc non fragmentable en place, le planificateur conforme DOCSIS peut maintenant planifier avec succès la subvention B après le premier bloc de subventions UGS.

Figure 21 - Planification des subventions à l'aide du bloc non fragmentable

Bien que la subvention B de DOCSIS 1.0 soit prévue avec succès, il reste un petit écart entre la subvention A et le premier bloc de subventions UGS. Cet écart représente une utilisation non optimale de la bande passante et démontre pourquoi vous devez utiliser des modems câble en mode DOCSIS 1.1 lorsque vous déployez des services UGS.

Cable default-phy-burst

Par défaut sur un CMTS Cisco uBR, la plus grande rafale qu'un modem câble puisse transmettre est de 2 000 octets. Cette valeur pour la taille de rafale en amont la plus importante est utilisée pour calculer la taille du bloc non fragmentable comme le planificateur conforme DOCSIS l'utilise.

Vous pouvez modifier la taille de rafale la plus importante à l'aide de la commande cable default-phy-burst max-bytes-allowed-in-burst par interface de câble.

Le paramètre <max-bytes-allowed-in-burst> a une plage de 0 à 4 096 octets et une valeur par défaut de 2 000 octets. Il existe des restrictions importantes sur la façon dont vous devez définir cette valeur si vous voulez modifier la valeur par défaut.

Pour les interfaces de câble sur la carte de ligne MC5x20S, ne définissez pas ce paramètre au-dessus de la valeur par défaut de 2 000 octets. Pour tous les autres types de cartes de ligne, y compris les cartes de ligne MC28U, MC5x20U et MC5x20H, vous pouvez définir ce paramètre jusqu'à 4 000 octets.

Ne définissez pas le paramètre <max-bytes-allowed-in-burst> inférieur à la taille de la plus grande trame Ethernet qu’un modem câble peut avoir besoin de transmettre, y compris DOCSIS ou la surcharge 802.1q. Cela signifie que cette valeur ne doit pas être inférieure à environ 1 540 octets.

Si vous affectez la valeur spéciale 0 à <max-bytes-allowed-in-burst>, le CMTS n'utilise pas ce paramètre pour limiter la taille d'une rafale en amont. Vous devez configurer d'autres variables afin de limiter la taille de rafale en amont à une limite raisonnable, par exemple le paramètre de rafale concaténée maximum dans le fichier de configuration DOCSIS ou la commande de fragment-force en amont du câble.

Lorsque vous modifiez cable default-phy-burst pour modifier la taille maximale de rafale en amont, la taille du bloc libre UGS est également modifiée en conséquence. La Figure 22 montre que si vous réduisez le paramètre de rafale par défaut du câble, la taille du bloc libre UGS diminue et que par conséquent, le planificateur conforme à DOCSIS peut autoriser davantage d'appels UGS sur un amont. Dans cet exemple, réduisez le paramètre par défaut du câble de 2000 à 1600 pour laisser de la place à un flux de service UGS supplémentaire.

Figure 22 - Réduction de la taille de bloc non fragmentable par défaut

La réduction de la taille de rafale maximale autorisée avec la commande cable default-phy-burst peut légèrement réduire l'efficacité du trafic en amont pour optimiser le trafic, car cette commande réduit le nombre de trames pouvant être concaténées en une rafale. Une telle réduction peut également conduire à des niveaux de fragmentation plus élevés lorsque le flux de services UGS en amont est plus important.

La réduction des tailles de rafales concaténées peut avoir un impact sur la vitesse de chargement des données dans un flux de services au mieux. En effet, la transmission simultanée de plusieurs trames est plus rapide que la transmission d’une demande de bande passante pour chaque trame. La réduction des niveaux de concaténation peut également avoir un impact sur la vitesse des téléchargements en raison de la capacité réduite du modem câble à concaténer un grand nombre de paquets TCP ACK qui se déplacent dans la direction amont.

Parfois, la taille de rafale maximale configurée dans le “ long ” IUC du profil de modulation de câble appliqué à un amont peut déterminer la taille de rafale la plus importante en amont. Cela peut se produire si la taille de rafale maximale dans le profil de modulation est inférieure à la valeur du câble default-phy-burst en octets. C'est un scénario rare. Cependant, si vous augmentez le paramètre cable default-phy-burst à partir de la valeur par défaut de 2 000 octets, vérifiez la taille de rafale maximale dans la configuration du “ long ” IUC pour vous assurer qu'il ne limite pas les rafales.

L'autre limite à la taille de rafale en amont est qu'un maximum de 255 mini-lots peut être transmis en une rafale. Cela peut devenir un facteur si la taille du mini-lot est définie sur un minimum de 8 octets. Un mini-lot est la plus petite unité de transmission en amont dans un réseau DOCSIS et équivaut généralement à 8 ou 16 octets.

Amorçage de logement non fragmenté

Une autre façon de modifier le planificateur conforme à DOCSIS afin de permettre un plus grand nombre de flux UGS simultanés sur un amont est de permettre au planificateur de laisser de grandes rafales de trafic au meilleur effort non fragmentable introduire de petites quantités de gigue aux flux de service UGS. Vous pouvez le faire avec la commande d'interface de câble ascendante numéro unfrag-slot-jitter limit val.

Dans cette commande, <val> est spécifié en microsecondes et a une valeur par défaut égale à zéro, ce qui signifie que le comportement par défaut du planificateur conforme à DOCSIS est de ne pas autoriser les subventions non fragmentables à provoquer la gigue pour les flux de services UGS et RTPS. Lorsqu'une gigue de logement non fragmentable positive est spécifiée, le planificateur conforme à DOCSIS peut retarder les subventions UGS d'un maximum de <val> microsecondes à partir du moment où l'allocation UGS doit idéalement être planifiée, et donc provoquer une gigue.

Cela a le même effet que la réduction de la taille de bloc non fragmentable par une longueur équivalente au nombre de microsecondes spécifié. Par exemple, si vous conservez la valeur par défaut pour default-phy-burst (2 000 octets) et si vous spécifiez une valeur de 1 000 microsecondes pour la gigue de logement non fragmentable, le bloc non fragmentable se réduit (voir Figure 23).

Figure 23 - La gigue non-nulle des emplacements non fragmentables réduit la taille de bloc non fragmentable

Remarque : Le nombre d'octets auxquels correspond la durée de 1 000 microsecondes dépend de la vitesse à laquelle le canal en amont est configuré pour fonctionner via les paramètres de largeur de canal et de schéma de modulation.

Remarque : avec une gigue de logement non-zéro non fragmentable, le planificateur conforme DOCSIS peut augmenter le nombre d'allocations UGS qu'un amont prend en charge de la même manière qu'avec une rafale de phy par défaut réduite.

Remarque : Revenez à l'exemple avec une subvention DOCSIS 1.1 importante A suivie d'une subvention DOCSIS 1.0 non fragmentable B importante pour programmer sur un amont. Vous définissez la gigue de logement non fragmentable sur 1 000 microsecondes. Le planificateur conforme DOCSIS se comporte comme indiqué dans les figures de cette section.

Remarque : Tout d'abord, le planificateur alloue du temps de transmission pour la subvention A. Pour ce faire, l'ordonnateur divise la subvention en subventions A₁ et A₂ afin que les subventions s'appliquent avant et après le premier bloc de subventions UGS. Afin de planifier l'octroi B, le planificateur doit décider si l'ordonnanceur peut ajuster le bloc non fragmentable dans l'espace libre après l'octroi A₂ sans délai au bloc suivant d'allocations UGS de plus que la gigue de logement non fragmentable configurée de 1000 microsecondes. Ces chiffres montrent que si le planificateur place grant B en regard de grant A₂, le bloc suivant du trafic UGS est retardé, ou repoussé, de plus de 1500 microsecondes. Par conséquent, le planificateur ne peut pas placer la subvention B directement après la subvention A₂.

Figure 24 - La subvention B ne peut pas être planifiée à côté de la subvention A2.

L'étape suivante du planificateur conforme à DOCSIS consiste à déterminer si le prochain écart disponible peut prendre en charge la subvention B. La figure 25 montre que si le planificateur place grant B après le deuxième bloc d'allocations UGS, le troisième bloc n'est pas retardé de plus de la gigue de logement non fragmentable configurée de 1000 microsecondes.

Figure 25 - Subvention B prévue après le deuxième bloc de subventions UGS

Sachant que l'insertion de la subvention B à ce stade ne provoque pas de gigue inacceptable pour les subventions UGS, le planificateur conforme DOCSIS insère la subvention B et retarde légèrement le bloc suivant de subventions UGS.

Figure 26 - Subvention non fragmentable B prévue et subventions UGS différées

Sortie de la commande show

Vous pouvez utiliser la commande show interface cable interface-number mac-Scheduler en amont-number pour évaluer l'état actuel du planificateur conforme DOCSIS. Voici un exemple du résultat de cette commande tel qu'il apparaît sur un Cisco uBR7200VXR avec une carte de ligne MC28U.

uBR7200VXR# show interface cable 3/0 mac-scheduler 0
     DOCSIS 1.1 MAC scheduler for Cable3/0/U0
     Queue[Rng Polls] 0/128, 0 drops, max 1
     Queue[CIR Grants] 0/64, 0 drops, max 0
     Queue[BE(7) Grants] 1/64, 0 drops, max 2
     Queue[BE(6) Grants] 0/64, 0 drops, max 0
     Queue[BE(5) Grants] 0/64, 0 drops, max 0
     Queue[BE(4) Grants] 0/64, 0 drops, max 0
     Queue[BE(3) Grants] 0/64, 0 drops, max 0
     Queue[BE(2) Grants] 0/64, 0 drops, max 0
     Queue[BE(1) Grants] 0/64, 0 drops, max 0
     Queue[BE(0) Grants] 1/64, 0 drops, max 1
     Req Slots 36356057, Req/Data Slots 185165
     Init Mtn Slots 514263, Stn Mtn Slots 314793
     Short Grant Slots 12256, Long Grant Slots 4691
     ATDMA Short Grant Slots 0, ATDMA Long Grant Slots 0
     ATDMA UGS Grant Slots 0
     Awacs Slots 277629
     Fragmentation count 41
     Fragmentation test disabled
     Avg upstream channel utilization : 26%
     Avg percent contention slots : 73%
     Avg percent initial ranging slots : 2%
     Avg percent minislots lost on late MAPs : 0%
     Sched Table Rsv-state: Grants 0, Reqpolls 0
     Sched Table Adm-State: Grants 6, Reqpolls 0, Util 27%
     UGS    : 6 SIDs, Reservation-level in bps 556800
     UGS-AD : 0 SIDs, Reservation-level in bps 0
     RTPS   : 0 SIDs, Reservation-level in bps 0
     NRTPS  : 0 SIDs, Reservation-level in bps 0
     BE     : 35 SIDs, Reservation-level in bps 0
     RTPS   : 0 SIDs, Reservation-level in bps 0
     NRTPS  : 0 SIDs, Reservation-level in bps 0
     BE     : 0 SIDs, Reservation-level in bps 0

Cette section explique chaque ligne du résultat de cette commande. Notez que cette section du document suppose que vous connaissez déjà bien les concepts généraux de planification en amont DOCSIS.

• Planificateur MAC DOCSIS 1.1 pour Cable3/0/U0

  La première ligne du résultat de la commande indique le port en amont auquel les données se trouvent.

• Queue[Rng Polls] 0/128, 0 abandons, max 1

  Cette ligne indique l'état de la file d'attente qui alimente les keepalives de maintenance de la station ou qui enregistre les opportunités dans le planificateur conforme DOCSIS. 0/128 indique qu'il y a actuellement zéro sur un maximum de 128 opportunités de portée en attente dans la file d'attente.

  Le compteur de pertes indique le nombre de fois où une opportunité de portée n'a pas pu être mise en file d'attente car cette file d'attente était déjà pleine (c'est-à-dire 128 opportunités de portée en attente). Il est probable que les abandons ici ne se produiront que sur un amont avec un très grand nombre de modems câble en ligne et s'il y a un grand nombre de flux de services UGS ou RTPS actifs. Cette file d'attente est traitée avec la priorité la plus élevée lorsque le planificateur de plaintes DOCSIS s'exécute. Par conséquent, les abandons dans cette file d'attente sont très peu probables, mais indiquent très probablement une sursouscription sérieuse du canal en amont.

  Le compteur max indique le nombre maximal d'éléments présents et dans cette file d'attente depuis la dernière exécution de la commande show interface cable mac-Scheduler. Idéalement, cela devrait rester aussi proche de zéro que possible.

• File d'attente[Subventions CIR] 0/64, 0 abandons, max 0

  Cette ligne indique l'état de la file d'attente qui gère les subventions pour les flux de service avec un débit de trafic minimal réservé spécifié. En d'autres termes, ces services de file d'attente accordent des subventions pour les flux de services CIR (Committed Information Rate). 0/64 indique qu'il y a actuellement zéro sur un maximum de 64 subventions en attente dans la file d'attente.

  Le compteur de pertes indique le nombre de fois où une subvention CIR n'a pas pu être mise en file d'attente car cette file d'attente était déjà pleine (c'est-à-dire 64 subventions en file d'attente). Les abandons peuvent s'accumuler ici si les flux de services de type UGS, RTPS et CIR sursouscrivent en amont, et peuvent indiquer la nécessité d'un contrôle d'admission plus strict.

  Le compteur max indique le nombre maximal de subventions dans cette file d'attente depuis la dernière exécution de la commande show interface cable mac-Scheduler. Cette file d'attente a la deuxième priorité la plus élevée, de sorte que le planificateur conforme DOCSIS alloue du temps pour les éléments de cette file d'attente avant que le planificateur ne gère les files d'attente au mieux.

• File d'attente[BE(w) Grants] x/64, y abandons, max z

  Les huit entrées suivantes indiquent l'état des files d'attente qui gèrent les subventions pour les flux de services de priorité 7 à 0. Les champs de ces entrées ont la même signification que les champs de l'entrée de file d'attente CIR. La première file d'attente à desservir dans ce groupe est la file d'attente BE (7) et la dernière à desservir est la file d'attente BE (0).

  Des abandons peuvent se produire dans ces files d'attente si un niveau de priorité plus élevé du trafic consomme toute la bande passante en amont ou si un surabonnement de l'amont avec des flux de services UGS, RTPS et de type CIR se produit. Cela peut indiquer la nécessité de réévaluer les priorités de DOCSIS pour les flux de services à fort volume ou la nécessité d'un contrôle plus strict de l'admission en amont.

• Logements requis 36356057

  Cette ligne indique le nombre d'opportunités de demande de bande passante annoncées depuis l'activation du flux en amont. Ce nombre doit constamment augmenter.

• Logements de données/requis 185165

  Bien que le nom suggère que ce champ indique le nombre d'opportunités de demande ou de données annoncées en amont, ce champ indique réellement le nombre de périodes que le CMTS annonce afin de faciliter la fonctionnalité avancée de gestion du spectre. Ce compteur devrait s'incrémenter pour les flux ascendants sur les cartes de ligne de style MC28U et MC520.

  Les opportunités de requête/données sont les mêmes que les opportunités de demande de bande passante, sauf que les modems câble peuvent également transmettre de petites rafales de données au cours de ces périodes. Les CMTS de la gamme Cisco uBR ne planifient pas actuellement d'opportunités réelles de demande/données.

• Logements Mtn Init 514263

  Cette ligne représente le nombre d'opportunités de maintenance initiale annoncées depuis l'activation de l'amont. Ce nombre doit constamment augmenter. Les modems câble qui tentent d’établir la connectivité au CMTS utilisent les opportunités de maintenance initiale.

• Logements Stn Mtn 314793

  Cette ligne indique le nombre d'opportunités de maintien de la maintenance de la station ou de portée offertes en amont. S'il existe des modems câble en ligne en amont, ce nombre doit augmenter continuellement.

• Emplacements à subvention courte 12256, Emplacements à subvention longue 4691

  Cette ligne indique le nombre de subventions de données offertes en amont. Si des modems câblés transmettent des données en amont, ces numéros doivent être continuellement en hausse.

• Emplacements ATDMA à subvention courte 0, Emplacements ATDMA à subvention longue 0, Emplacements ATDMA UGS à subvention courte 0

  Cette ligne représente le nombre d'allocations de données offertes en mode ATDMA (Advanced Time Division Multiple Access) en amont. Si des modems câble fonctionnent en mode DOCSIS 2.0 et qu'ils transmettent des données en amont, ces numéros doivent être continuellement en augmentation. Notez que ATDMA comptabilise séparément le trafic UGS.

• Emplacements Awacs 277629

  Cette ligne indique le nombre de périodes dédiées à la gestion avancée du spectre. Afin de permettre une gestion avancée du spectre, le CMTS doit planifier périodiquement des heures pendant lesquelles chaque modem câble doit effectuer une brève transmission afin que la fonction d’analyse du spectre interne puisse évaluer la qualité du signal de chaque modem.

• Décompte de fragmentation 41

  Cette ligne indique le nombre total de fragments que le port en amont doit recevoir. Par exemple, une trame fragmentée en trois parties entraînerait l'incrémentation de ce compteur de trois.

• Test de fragmentation désactivé

  Cette ligne indique que la commande test cable fragmentation n'a pas été appelée. N'utilisez pas cette commande dans un réseau de production.

• Utilisation moyenne du canal en amont : 26%

  Cette ligne indique l'utilisation actuelle du canal en amont par les transmissions de données en amont. Cela comprend les transmissions effectuées par le biais de concessions ATDMA courtes, longues, ATDMA longues et ATDMA UGS. La valeur est calculée toutes les secondes sous forme de moyenne mobile. Cisco recommande que cette valeur ne dépasse pas 75 % sur une base prolongée pendant les périodes de pointe. Dans le cas contraire, les utilisateurs finaux peuvent commencer à remarquer les problèmes de performances avec un trafic au mieux.

• Pourcentage moyen de logements de contention : 73%

  Cette ligne indique le pourcentage de temps en amont consacré aux demandes de bande passante. Cela équivaut à la quantité de temps libre en amont, et par conséquent réduit à mesure que le pourcentage moyen d'utilisation du canal en amont augmente.

• Pourcentage moyen de logements de plage initiale : 2%

  Cette ligne indique le pourcentage de temps en amont consacré aux opportunités de portée initiale que les modems câble utilisent lorsqu'ils tentent d'établir une connectivité initiale avec le CMTS. Cette valeur doit toujours rester un faible pourcentage de l'utilisation totale.

• Pourcentage moyen de mini-lots perdus sur les MAP tardives : 0%

  Cette ligne indique le pourcentage de temps en amont qui n'a pas été planifié car le CMTS n'a pas pu transmettre un message MAP d'allocation de bande passante aux modems câble dans le temps. Ce paramètre doit toujours être proche de zéro mais peut commencer à afficher des valeurs plus grandes sur les systèmes qui ont une charge CPU extrêmement élevée.

• État Rsv de la table Sched : Subventions 0, Requêtes 0

  Cette ligne indique le nombre de flux de service de style UGS (Grants) ou de flux de service de style RTPS (Reqpolls) dont les subventions sont préaffectées dans le planificateur conforme DOCSIS, mais qui n'ont pas encore été activées. Cela se produit lorsque vous déplacez un modem câble avec des flux de service UGS ou RTPS existants d'un amont à un autre via l'équilibrage de charge. Notez que cette figure ne s'applique qu'aux subventions qui utilisent le planificateur conforme DOCSIS et non le planificateur LLQ.

• État Adm De La Table Jumelée : Subventions 6, demandes 0, jusqu'à 27 %

  Cette ligne indique le nombre de flux de service de style UGS (Grants) ou de flux de service de style RTPS (Reqpolls) dont les subventions sont préaffectées dans le planificateur conforme DOCSIS pour ce projet en amont. Util représente l'utilisation estimée de la bande passante ascendante totale disponible par ces flux de services. Notez que cette figure ne s'applique qu'aux subventions qui utilisent le planificateur conforme DOCSIS et non le planificateur LLQ.

• <Type de planification> : x SID, niveau de réservation en bits/s y

  Cette ligne indique le nombre de flux de service <Scheduling-type> ou de SID présents en amont, ainsi que la quantité de bande passante en bits par seconde réservée par ces flux de service. Pour optimiser les efforts et les flux de service de type RTPS, la bande passante est réservée uniquement si le flux de service a un débit minimal réservé configuré.

Avantages et inconvénients du planificateur conforme DOCSIS

L'objectif du planificateur conforme à DOCSIS est de minimiser la gigue pour les flux de services de type UGS et RTPS et de prendre en charge les rafales DOCSIS 1.0 non fragmentables. Pour atteindre ces objectifs, le planificateur conforme à DOCSIS fait le compromis suivant : le nombre maximal de flux de services UGS pris en charge par amont est inférieur au maximum théorique qu'un ascendant DOCSIS peut prendre en charge physiquement et le trafic au mieux peut être soumis à un degré de fragmentation.

Bien que le planificateur conforme DOCSIS prenne en charge un peu moins que le nombre maximal théorique de flux de service UGS simultanés sur un amont et que d'autres implémentations de planification puissent prendre en charge plus de flux de service UGS par amont, vous devez vous concentrer sur le compromis.

Par exemple, aucun planificateur ne peut prendre en charge les flux de service UGS sans interruption qui consomment près de 100 % de bande passante d'un canal en amont et prennent en charge simultanément de grandes trames concaténées non fragmentables à partir de modems DOCSIS 1.0. En ce qui concerne la conception du planificateur conforme à DOCSIS, il y a deux points importants à comprendre.

• 75 % est l'utilisation maximale souhaitable en amont.

  Cisco a constaté que lorsqu'un réseau en amont fonctionne de manière constante avec une utilisation supérieure à 75 %, y compris en raison des flux de services UGS, les performances du trafic au mieux commencent à être affectées de manière significative. Cela signifie que si la signalisation UGS et VoIP consomme plus de 75 % du trafic en amont, tout trafic IP normal transmis par les flux de services au mieux commence à souffrir d'une latence supplémentaire qui entraîne une diminution sensible du débit et des temps de réponse. Cette dégradation des performances à des niveaux d'utilisation plus élevés est une propriété que partagent la plupart des systèmes de réseau à accès multiple modernes, par exemple les réseaux LAN Ethernet ou sans fil.

• Lorsque la largeur de canal en amont généralement déployée de 3,2 MHz est utilisée, le planificateur conforme DOCSIS permet aux flux de services UGS d'utiliser jusqu'à 75 % du canal en amont. Ces flux de services transmettent des appels VoIP G.711.

Ces deux points donnent un aperçu des considérations de conception qui ont été prises en compte lors de la création du planificateur conforme DOCSIS. Le planificateur conforme à DOCSIS a été conçu de sorte que pour les flux de services UGS standard (G.711) et avec la largeur de canal la plus couramment déployée de 3,2 MHz, les limites d'appel par amont commencent à s'appliquer aux alentours de 75 %. Cela signifie que le planificateur réussit à réduire la gigue et autorise également un nombre raisonnable de flux de service UGS en amont.

En d'autres termes, le planificateur conforme à DOCSIS a été conçu pour fonctionner correctement dans les réseaux DOCSIS de production, et non pour permettre aux flux de services UGS d'utiliser un pourcentage irréaliste de la bande passante en amont. Ce scénario peut se produire dans un scénario d'essai en laboratoire artificiel.

Vous pouvez ajuster le planificateur conforme DOCSIS pour prendre en charge un nombre accru d'appels UGS par amont, mais au détriment de la gigue UGS et de l'efficacité du trafic au mieux. Pour cela, vous devez réduire le paramètre cable default-phy-burst au paramètre minimum recommandé de 1 540 octets. Si vous avez besoin d'une densité d'appel supplémentaire, définissez la valeur de la gigue unfrag-slot en amont sur 2 000 microsecondes. Cependant, Cisco ne recommande généralement pas ces paramètres pour un réseau de production.

Un autre avantage du planificateur conforme à DOCSIS est qu'il n'est pas obligatoire que les opérateurs CMTS configurent explicitement le contrôle d'admission pour les flux de services de type UGS et RTPS. En effet, la méthode de planification de préallocation élimine la possibilité de surabonnement accidentel. Même si c'est le cas, Cisco suggère toujours que les opérateurs s'assurent que l'utilisation totale en amont ne dépasse pas 75 % pendant les périodes prolongées pendant l'heure de pointe. Par conséquent, Cisco recommande la configuration du contrôle d'admission comme meilleure pratique.

L'un des inconvénients du planificateur conforme à DOCSIS est que la position fixe des subventions UGS peut nécessiter la fragmentation des subventions au meilleur effort lorsque l'utilisation d'UGS est élevée. En règle générale, la fragmentation ne cause pas de problèmes de performances notables, mais elle entraîne une légère augmentation de la latence pour le trafic au mieux des efforts et une augmentation de la surcharge de protocole présente sur le canal en amont.

Un autre inconvénient est que lorsque les modems câble DOCSIS 1.0 veulent rendre les transmissions ascendantes non fragmentables de grande taille, il peut y avoir un délai avant qu'un écart approprié entre les blocs de subventions UGS préprogrammées n'apparaisse. Cela peut également entraîner une latence accrue pour le trafic en amont DOCSIS 1.0 et une utilisation moins qu'optimale du temps de transmission en amont disponible.

Enfin, le planificateur conforme DOCSIS est conçu pour fonctionner au mieux dans les environnements où tous les flux de services UGS partagent la même taille de subvention et le même intervalle de subvention. C'est-à-dire que tous les appels VoIP partagent le même codec, tel que la mise en paquets G.711 de 10 ms ou de 20 ms, comme cela se produirait dans un système Packetcable 1.0 classique. Lorsque des intervalles et des tailles de subvention disparates sont présents, la capacité du planificateur conforme à DOCSIS à prendre en charge un nombre élevé de flux de service UGS diminue sur un amont. En outre, une très petite quantité de gigue (inférieure à 2 ms) peut se produire pour certaines subventions lorsque le planificateur tente d'interlaisser les flux de service UGS avec des périodes et des tailles différentes.

À mesure que les réseaux PacketCable MultiMedia (PCMM) deviennent de plus en plus répandus, il peut devenir plus fréquent pour plusieurs codecs VoIP avec différents intervalles de mise en paquets de fonctionner simultanément. Ce type d'environnement peut se prêter au planificateur de mise en file d'attente à faible latence.

Planificateur de mise en file d'attente à faible latence

Le planificateur LLQ (Low Latency Queueing) a été introduit dans le logiciel Cisco IOS Version 12.3(13a)BC. LLQ est la méthode alternative pour planifier des services en amont sur un CMTS Cisco uBR. Ce planificateur a été conçu pour optimiser le nombre de flux de services de type UGS et RTPS qu'un amont peut prendre en charge simultanément et améliorer l'efficacité du trafic au mieux en présence de flux de services UGS. Le compromis est que le planificateur LLQ ne donne aucune garantie en ce qui concerne la gigue des flux de services UGS et RTPS.

Comme le discute la section du planificateur conforme DOCSIS, le planificateur conforme DOCSIS alloue le temps de transmission à l'avance pour les flux de services de type UGS et RTPS. C'est similaire à la manière dont un système TDM (Time Division Multiplexing) hérité alloue la bande passante à un service pour garantir certains niveaux de latence et de gigue.

Dans les réseaux modernes à base de paquets, la mise en file d’attente à faible latence est la méthode que les routeurs utilisent pour s’assurer que les paquets associés à des services de haute priorité, par exemple la voix et la vidéo, peuvent être livrés dans un réseau avant d’autres paquets de moindre priorité. C’est également la méthode que les routeurs modernes utilisent pour s’assurer que la latence et la gigue sont réduites au minimum pour le trafic important.

L'utilisation du mot “ garantie ” pour le système basé sur TDM et “ minimisé ” pour le système basé sur LLQ en relation avec la gigue et la latence. Bien qu'une garantie de latence et de gigue zéro soit souhaitable, le compromis est qu'un tel système est généralement inflexible, difficile à reconfigurer et généralement incapable de s'adapter facilement aux changements des conditions du réseau.

Un système qui minimise la latence et la gigue, plutôt que de fournir une garantie stricte, est capable de fournir une flexibilité afin de s'optimiser en permanence face aux changements des conditions du réseau. Le planificateur de mise en file d’attente à faible latence se comporte de la même manière que le système LLQ basé sur le routeur de paquets. Au lieu d'un système d'allocation préprogrammé pour les subventions UGS, ce système planifie les “ de subventions dès que possible ” au moment où elles doivent être planifiées.

L'approche selon laquelle les subventions pour les flux de services UGS doivent être attribuées dès que possible mais pas nécessairement avec une périodicité parfaite, ce système échange des garanties strictes de gigue pour une capacité UGS accrue et une fragmentation des données au mieux.

Configuration

Pour les versions du logiciel Cisco IOS 12.3(13a)BC et ultérieures, le planificateur LLQ est l'un des deux algorithmes de planification alternative. Vous pouvez activer LLQ pour un, tous ou certains de ces modes de planification :

• UGS

• RTPS

• NRTPS

Le planificateur LLQ n'est pas activé par défaut. Vous devez explicitement activer le planificateur LLQ pour les types de planification amont requis. Utiliser le type de planification du port amont du câble [nrtps] | rtps | ugs] mode llq cable interface command.

En général, vous pouvez activer le planificateur LLQ pour tous les modes de planification répertoriés s'il s'agit du mode de planification souhaité. Voici un exemple de situation dans laquelle vous voulez activer la planification LLQ pour un seul type de mode de planification mais conserver le planificateur conforme DOCSIS pour d'autres :

Les flux de service RTPS n'ont pas de condition stricte pour la gigue, mais les flux de service UGS le sont. Dans ce cas, vous pouvez activer le planificateur LLQ pour les flux de service RTPS et conserver le planificateur conforme DOCSIS pour UGS.

Fonctionnement du planificateur LLQ

Le planificateur LLQ fonctionne de la même manière que la fonction de mise en file d'attente prioritaire du planificateur conforme à DOCSIS avec l'ajout d'une file d'attente spéciale à faible latence (LLQ), qui prime sur toutes les autres files d'attente.

Le planificateur LLQ démarre un minuteur au nom de tous les flux de service de type UGS (et RTPS) actifs. Le compteur est configuré pour s'arrêter une fois tous les ” d'intervalle de subvention “. Chaque fois que le compteur expire, une subvention UGS est mise en file d'attente dans la file d'attente LLQ. Comme cette subvention est placée dans la file d'attente LLQ qui a la priorité la plus élevée, la subvention est planifiée au prochain moment possible où il y a de l'espace libre.

Les diagrammes de cette section montrent un exemple de système avec trois flux de service UGS actifs avec le même intervalle de subvention. La Figure 27 montre les compteurs des flux de service UGS à gauche, libellés UGS-1 à UGS-3. La flèche jaune se déplace dans le sens des aiguilles d'une montre. Lorsque la flèche jaune pointe vers le haut vers le point rouge, une subvention UGS est ajoutée à la file d'attente LLQ. Vous pouvez également voir les huit files d'attente de priorité comprises entre 0 et 7, ainsi qu'une nouvelle file d'attente LLQ qui a la priorité sur toutes les files d'attente. Enfin, à droite, figure la ligne de temps d'allocation de bande passante qui décrit la façon dont les subventions sont planifiées en amont. Pour plus de clarté, la ligne de temps d'allocation de bande passante inclut un pointeur ” heure “. Ce pointeur se déplace le long de la chronologie au fur et à mesure que l'exemple progresse.

Figure 27 : système de mise en file d'attente à faible latence

Le premier événement qui se produit est que le minuteur UGS-1 en haut à gauche expire. Une subvention correspondante est mise en file d'attente dans la file d'attente LLQ. Dans le même temps, une subvention au mieux appelée A avec priorité 2 est mise en file d'attente.

Figure 28 - La subvention pour UGS-1 et la subvention de priorité 2 A sont mises en file d'attente

Le planificateur LLQ alloue maintenant du temps de transmission aux subventions en attente dans l'ordre de priorité. La première subvention à recevoir est la subvention pour UGS-1 qui attend dans la file d'attente LLQ. Subvention A :

Figure 29 - Octroi de la licence UGS-1 et de la licence A pour le temps de transmission alloué

L'événement suivant est que le minuteur UGS-2 expire et provoque une allocation pour le flux de service UGS-2 à mettre en file d'attente LLQ. En même temps, une subvention de priorité 0 B est mise en file d'attente et la subvention de priorité 6 C est mise en file d'attente.

Figure 30 - Le minuteur UGS-2 expire. Les subventions B et C sont mises en file d'attente

Le planificateur LLQ alloue une fois de plus du temps de transmission dans l'ordre de priorité de subvention, ce qui signifie que le planificateur alloue d'abord du temps à la subvention pour UGS-2, puis pour la subvention C, et enfin pour la subvention B.

Figure 31 - Les subventions UGS-2, C et B sont affectées au temps de transmission

Supposez qu'aucune subvention d'effort n'entre dans le planificateur pendant un certain temps. Les temporisateurs UGS expirent plusieurs fois plus. Vous pouvez maintenant voir le type de période pendant laquelle le planificateur alloue des subventions aux flux de service UGS. Elles semblent être espacées de manière égale. Supposons que lorsque les subventions apparaissent de cette manière les unes par rapport aux autres sur le calendrier d'allocation de bande passante, elles ne subissent aucune gigue significative.

Figure 32 - UGS-1, UGS-2 et UGS-3 reçoivent un certain nombre de subventions. L'octroi D est mis en file d'attente

La figure 32 indique la position idéale pour la prochaine subvention UGS-2. Si UGS-2 peut faire placer la subvention à cet endroit, UGS-2 ne connaîtra aucune gigue pour la subvention. Notez qu'il est encore temps que la prochaine subvention UGS-2 soit mise en file d'attente dans la file d'attente LLQ.

La figure 32 indique également qu'une priorité 0 D très importante vient d'entrer la file d'attente prioritaire 0. L'action suivante du planificateur LLQ consiste à planifier le temps de transmission pour l'octroi D.

La figure 33 illustre ce scénario. Remontez un peu le temps jusqu'au point où la prochaine subvention pour UGS-2 est mise en file d'attente.

Figure 33 - La Dons D Reçoit Le Temps De Transmission. L'allocation pour UGS-2 est mise en file d'attente

La subvention D semble être prévue au moment où la prochaine subvention UGS-2 doit être prévue pour zéro gigue. Maintenant, la question est de savoir pourquoi le planificateur LLQ permet que l'octroi D soit planifié à ce moment et ne retarde pas l'octroi D jusqu'après l'octroi de l'UGS-2 ou pourquoi D n'est pas fragmenté. La réponse est que le planificateur LLQ ne préalloue pas le temps de transmission pour les flux de service UGS. Par conséquent, le planificateur LLQ ne sait pas à l'avance où les subventions UGS seront placées sur la ligne de temps d'allocation de bande passante. Le planificateur LLQ ne connaît pas les subventions UGS tant qu'elles ne sont pas mises en file d'attente dans la file d'attente LLQ. Dans cet exemple, au moment où la subvention pour UGS-2 est mise en file d'attente, la subvention D est déjà planifiée.

Le planificateur LLQ planifie la subvention pour UGS-2 à la prochaine opportunité disponible, mais cette subvention est légèrement retardée de la position idéale, ce qui signifie par définition que cette subvention particulière subit une certaine gigue.

Figure 34 - L'octroi d'une subvention pour UGS-2 est retardé et l'expérience est instable

Bien que le planificateur conforme DOCSIS ait pu éviter cette gigue, le planificateur LLQ évite un retard ou une fragmentation de la subvention D au détriment d'une petite quantité de gigue. Un tampon de gigue dans un terminal VoIP peut facilement compenser cette gigue.

L'autre situation où la gigue peut se produire est lorsque le compteur LLQ pour plusieurs flux de services expire simultanément et que les subventions UGS attendent derrière les autres subventions UGS mises en file d'attente dans la file d'attente LLQ. Le planificateur LLQ a été conçu pour minimiser la possibilité de cette occurrence. Le planificateur répartit automatiquement les délais d'expiration des temporisateurs de flux de service.

Selon le planificateur conforme DOCSIS, le planificateur LLQ dispose de deux files d'attente supplémentaires que les exemples ne mentionnent pas. Voici les files d'attente :

1. La première file d'attente est utilisée pour planifier le trafic de veille de maintenance périodique de la station afin de maintenir les modems câble en ligne. Cette file d'attente est servie juste après la file d'attente LLQ.

2. La seconde est une file d'attente pour les subventions allouées aux flux de services avec un taux minimal réservé (flux de services CIR). Cette file d'attente CIR est traitée comme une file d'attente “ priorité 8 ” afin de s'assurer que les flux de service avec un débit garanti reçoivent le débit minimal requis.

Contrôle des admissions

Contrairement au planificateur conforme à DOCSIS, le planificateur LLQ n'utilise pas de système de préplanification qui arrête la sursouscription accidentelle d'un amont avec des flux de services UGS et RTPS. C'est pourquoi vous devez explicitement configurer le contrôle d'admission en amont sur tout en amont qui utilise le planificateur LLQ. Cette configuration garantit que la bande passante ascendante totale des flux de services UGS ne dépasse pas les limites raisonnables.

Cisco suggère généralement que vous ne permettiez pas l'utilisation d'un canal en amont de dépasser 75 % pendant les périodes prolongées pendant les périodes de pointe. Par exemple, si le trafic UGS consomme plus de 75 % de la bande passante en amont, les données du meilleur effort commencent à souffrir d'une latence excessive et de problèmes de performances de débit.

Naturellement, si un opérateur CMTS peut accepter les conséquences négatives pour le trafic au mieux, vous pouvez laisser les flux de service UGS consommer plus de 75 % de la bande passante ascendante disponible. Cependant, vous devez également tenir compte de l'impact sur le trafic de gestion de couche 2 sur le canal en amont. Vous devez prévoir du temps pour la messagerie de maintenance initiale et de station (keepalives du modem câble). Si vous ne tenez pas compte de cela et que le trafic UGS consomme près de 100 % de la bande passante, les modems câble ne peuvent pas être mis en ligne ou peuvent tomber hors connexion.

Voici un exemple de configuration pour le contrôle d'admission. Cet exemple limite les flux de service UGS sur un amont particulier à 50 % de la bande passante disponible du amont. Cette forme de commande transmet également des interruptions SNMP à toutes les stations de gestion de réseau configurées lorsque les seuils mineurs et principaux de 30 % et 40 % d'utilisation sont atteints. La commande est la suivante :

câble en amont numéro d'admission contrôle de bande passante usb type de planification UGS mineur 30 majeur 40 exclusif 50

Reportez-vous à la section Contrôle d'admission sous la section Planificateur conforme DOCSIS de ce document pour savoir comment configurer le contrôle d'admission.

Sortie de la commande show

Exécutez la commande show interface cable interface-number mac-Scheduler en amont-number pour évaluer l'état actuel du planificateur LLQ.

Voici un exemple du résultat de cette commande. Les parties de la sortie de commande qui sont différentes de lorsque le planificateur conforme DOCSIS est opérationnel sont en gras :

uBR7200VXR# show interface cable 5/0 mac-scheduler 0
     DOCSIS 1.1 MAC scheduler for Cable5/0/U0
     Queue[Rng Polls] 0/128, 0 drops, max 1
     Queue[CIR Grants] 0/64, 0 drops, max 2
     Queue[BE(7) Grants] 0/64, 0 drops, max 0
     Queue[BE(6) Grants] 0/64, 0 drops, max 0
     Queue[BE(5) Grants] 0/64, 0 drops, max 0
     Queue[BE(4) Grants] 0/64, 0 drops, max 0
     Queue[BE(3) Grants] 0/64, 0 drops, max 2
     Queue[BE(2) Grants] 0/64, 0 drops, max 0
     Queue[BE(1) Grants] 0/64, 0 drops, max 0
     Queue[BE(0) Grants] 0/64, 0 drops, max 5
     Queue[LLQ Grants] 0/64, 0 drops, max 3
     Req Slots 165488850, Req/Data Slots 871206
     Init Mtn Slots 1727283, Stn Mtn Slots 1478295
     Short Grant Slots 105668683, Long Grant Slots 52721
     ATDMA Short Grant Slots 0, ATDMA Long Grant Slots 0
     ATDMA UGS Grant Slots 0
     Awacs Slots 1303668
     Fragmentation count 11215
     Fragmentation test disabled
     Avg upstream channel utilization : 6%
     Avg percent contention slots : 91%
     Avg percent initial ranging slots : 3%
     Avg percent minislots lost on late MAPs : 0%
     Sched Table Rsv-state: Grants 0, Reqpolls 0
     Sched Table Adm-State: Grants 0, Reqpolls 0, Util 1%
     UGS    : 3 SIDs, Reservation-level in bps 278400
     UGS-AD : 0 SIDs, Reservation-level in bps 0
     RTPS   : 0 SIDs, Reservation-level in bps 0
     NRTPS  : 0 SIDs, Reservation-level in bps 0
     BE     : 14 SIDs, Reservation-level in bps 0
     r4k ticks in 1ms 600000
     Total scheduling events 5009
     No search was needed 5009
     Previous entry free 0
     Next entry free 0
     Could not schedule 0
     Recovery failed 0
Curr time 1341 entry 61
Entry 188, Bin 13
    SID: 416 IUC: 5, size_ms: 17 size_byte: 232 Frag: N Inval: 20
    type 8, perfect time ref 188, skew from ref 0, priority 10
    position 188, bin 13
Entry 188, Bin 14
    SID: 414 IUC: 5, size_ms: 17 size_byte: 232 Frag: N Inval: 20
    type 8, perfect time ref 188, skew from ref 0, priority 10
    position 188, bin 14
Entry 192, Bin 12
    SID: 415 IUC: 5, size_ms: 17 size_byte: 232 Frag: N Inval: 20
    type 8, perfect time ref 192, skew from ref 0, priority 10
    position 192, bin 12

Pour obtenir une explication des lignes de texte brut dans cette sortie, reportez-vous à la section Show Command Output pour le planificateur conforme DOCSIS.

Voici les descriptions des lignes en gras de la sortie show :

• File d'attente[Subventions LLQ] 0/64, 0 abandons, max 3

  Cette ligne indique l'état de la file d'attente LLQ, qui gère les subventions pour les types de flux de service spécifiés dans le type de planification en amont du câble [nrtps] | rtps | ugs] mode llq, commande. 0/64 indique qu'il y a actuellement zéro sur un maximum de 64 subventions en attente dans la file d'attente.

  Le compteur de pertes indique le nombre de fois où le planificateur n'a pas pu mettre en file d'attente une subvention UGS ou un sondage RTPS car cette file d'attente était déjà pleine (en d'autres termes, lorsque 64 subventions sont en file d'attente). Si des abandons se produisent dans cette file d'attente, l'explication la plus probable est que l'amont est surabonné avec des flux de services UGS ou RTPS et vous devez appliquer un contrôle d'admission plus strict.

  Le compteur max indique le nombre maximal de subventions qui sont dans cette file d'attente depuis la dernière exécution de la commande show interface cable mac-Scheduler. Lorsqu'elle est présente, cette file d'attente a la priorité la plus élevée de toutes les files d'attente répertoriées.

• ticks r4k dans 1ms 600000

  Ce champ représente une variable de synchronisation interne que le planificateur LLQ utilise afin de s'assurer que les subventions sont placées dans la file d'attente LLQ avec une grande précision.

• Nombre total d'événements de planification 5009

  Cette ligne indique le nombre de fois où le planificateur LLQ tente de mettre en file d'attente une subvention depuis la dernière exécution de la commande show interface cable mac-Scheduler pour cette source amont. Ce compteur est réinitialisé chaque fois que la commande show est exécutée.

• Aucune recherche requise 5009

  Une fois que le planificateur LLQ a mis une subvention en file d'attente, le planificateur LLQ tente de réinitialiser le compteur de flux de service pour se préparer à la prochaine mise en file d'attente d'une subvention. S'il n'y a aucun problème avec une réinitialisation du compteur, ce compteur s'incrémente. Ce compteur doit idéalement avoir la même valeur que le compteur Événements de planification totaux.

• Entrée précédente gratuite 0, Entrée suivante gratuite 0

  Aucun de ces compteurs ne s'incrémente jamais dans les versions actuelles du logiciel Cisco IOS. Ces compteurs restent toujours à zéro.

• Impossible de planifier 0, échec de la récupération 0

  Cette ligne indique le nombre de fois où le planificateur LLQ n'a pas pu organiser la définition correcte du minuteur d'octroi d'un flux de service. Cela ne doit se produire que si le planificateur LLQ gère un nombre extrêmement important de subventions avec des intervalles de subvention très faibles. Il est très peu probable que ces compteurs s'incrémentent sur un réseau de production. Un incrément de ces compteurs peut indiquer que les flux de service UGS et RTPS consomment plus de bande passante que ce qui est physiquement disponible en amont. Dans ce scénario, vous devez implémenter les commandes de contrôle d'admission appropriées.

• Heure de cours 1341 entrée 61

  Cette ligne affiche les temporisateurs internes du planificateur LLQ, mesurés en millisecondes. Lorsque l'” d'entrée “ indiquée ici est égale au champ ” d'entrée “ indiqué dans les statistiques de flux de service, une subvention est mise en file d'attente dans la file d'attente LLQ.

Ces statistiques sont répétées pour chaque flux de service géré par le planificateur LLQ. Dans cet exemple, il existe trois flux de services de ce type.

• Entrée 188, Corbeille 13

  Lorsque la valeur de ” d'entrée de “ est égale au champ ” d'entrée de “ de l'élément précédent, le compteur de ce flux de service expire et une subvention entre dans la file d'attente LLQ. Ce champ se réinitialise chaque fois que le flux de service a une subvention mise en file d'attente.

• SID : 416

  Identificateur de service (SID) du flux de service dont le planificateur LLQ accorde les planifications.

• IUC : 5

  Code d'utilisation d'intervalle annoncé dans un message MAP pour les subventions qui appartiennent à ce flux de service. C'est presque toujours 5 pour “ courte ” de données, 6 pour “ Long Data ” ou 11 pour “ Advanced PHY UGS ” lorsqu'un flux de service de type UGS est utilisé. Pour le flux de service de style RTPS, cette valeur est toujours 1 pour “ ” de demande.

• size_ms : 17 octets_taille : 232

  Taille de la subvention en mini-lots, suivie de la taille de la subvention en octets. Un mini-lot est la plus petite unité de transmission en amont dans un réseau DOCSIS et équivaut généralement à 8 ou 16 octets.

• Frag : n

  Indique si la subvention est fragmentable. Actuellement, cette valeur est toujours définie sur N.

• Inval : 20

  Intervalle d'approbation ou d'interrogation en millisecondes.

• type 8

  8 indique que ce flux de service est UGS, 10 indique RTPS et 11 indique NRTPS.

• perfection time ref 188

  Le moment idéal où cette subvention doit avoir été prévue. C'est normalement la même chose que “ Entry ” en haut. Si ce n'est pas le cas, il y a une indication d'un amont fortement encombré qui a besoin d'un contrôle d'admission plus strict.

• bifurquer de ref 0

  Différence entre le moment où cette subvention a été prévue et le moment où la subvention doit idéalement avoir été prévue. C'est la différence entre “ ” d'entrée et “ temps parfait ref ”. Par conséquent, cette valeur doit normalement être égale à zéro.

• priority (priorité) 10

  Dans les versions actuelles du logiciel Cisco IOS, cette valeur est toujours définie sur 10, mais peut varier à l'avenir.

• position 188, bin 13

  Ces champs doivent être identiques à “ Entrée, ” de la corbeille en haut de cette liste.

Avantages et inconvénients du planificateur LLQ

L'objectif du planificateur LLQ est d'augmenter la capacité UGS et RTPS pour les canaux en amont et d'accroître l'efficacité du trafic au mieux. Le compromis que le planificateur LLQ fait pour atteindre ces objectifs est que ce planificateur ne donne pas explicitement de garanties pour la gigue de flux de service UGS et RTPS. Au contraire, le planificateur LLQ planifie des subventions UGS et des sondages RTPS aussi près que possible du moment idéal afin de minimiser la gigue.

Le planificateur LLQ est également en mesure de mieux gérer plusieurs flux de services UGS avec différents intervalles de subvention et tailles de subvention que le planificateur conforme DOCSIS. Cette fonctionnalité peut s'avérer utile dans un environnement PCMM où différents types d'appels VoIP et éventuellement d'autres applications sont simultanément servis sur un seul canal en amont.

Le planificateur LLQ planifie plus efficacement le trafic au mieux, car il réduit la probabilité de fragmentation des subventions. Lorsque des rafales DOCSIS 1.0 non fragmentables sont planifiées, le planificateur LLQ ne crée pas d'écarts de bande passante inutilisée devant les subventions UGS ou les sondages RTPS comme le planificateur conforme DOCSIS le fait parfois. Cela permet une meilleure utilisation du temps ascendant disponible.

Bien que la gigue UGS soit généralement plus élevée lorsque vous utilisez le planificateur LLQ que lorsque vous utilisez le planificateur conforme DOCSIS, dans les réseaux DOCSIS ou PacketCable classiques, les niveaux de gigue du planificateur LLQ sont bien en deçà de la capacité de la technologie de tampon de gigue des points d'extrémité VoIP. Cela signifie qu'il n'y a aucun impact notable sur la qualité des appels VoIP lorsque vous utilisez le planificateur LLQ dans un réseau VoIP correctement conçu.

Vous pouvez limiter la gigue qui résulte de grandes rafales en amont. Pour cela, assurez-vous de conserver le paramètre cable default-phy-burst à la valeur par défaut de 2 000 octets ou moins. Si un système utilise un canal en amont particulièrement lent, par exemple avec une largeur de canal de 800 kHz ou plus petite, vous pouvez réduire davantage la gigue si vous forcez de grandes rafales à être fragmentées en des rafales plus petites à l'aide de la commande cable cable en amont fragment-force.

Lorsque le planificateur LLQ est en cours d'utilisation, vous devez configurer le contrôle d'admission des câbles afin d'éviter la possibilité de surabonnement du canal en amont. Les flux de service UGS plus actifs que ceux que l'amont peut gérer physiquement conduisent à une mauvaise qualité vocale sur tous les flux de service UGS en amont. Dans les cas extrêmes, cela signifie également que les modems câble sont déconnectés et que les nouveaux modems câble ne peuvent pas être mis en ligne. Cisco recommande aux opérateurs CMTS de configurer le contrôle d'admission de sorte que l'utilisation totale en amont sur tout port en amont ne dépasse pas 75 % pendant de longues périodes.

Conclusions

La gamme Cisco uBR de produits CMTS DOCSIS offre deux algorithmes de planification ascendante de remplacement et peut donc prendre en charge diverses conditions de réseau.

Le planificateur conforme à DOCSIS, optimisé pour une faible gigue, est le mieux adapté aux systèmes vocaux Packet 1.x classiques avec un codec VoIP uniforme en place et où des niveaux standard d'utilisation des canaux en amont par les flux de service UGS sont souhaités.

Le planificateur de mise en file d'attente à faible latence est conçu pour prendre en charge des niveaux d'utilisation en amont supérieurs à la normale par les flux de services UGS, une efficacité accrue du trafic au mieux de l'effort et des systèmes qui utilisent les flux de services UGS et RTPS avec une variété d'intervalles de subvention et de tailles de subvention.

Annexe A : Ministères

Un mini-lot est la plus petite unité de transmission dans le DOCSIS en amont. Lorsqu'un modem câble transmet une demande de bande passante au CMTS pour demander le temps de transmission en amont, le modem demande en unités de mini-lots plutôt qu'en octets ou en millisecondes. En outre, lorsqu'un message MAP d'allocation de bande passante informe les modems du moment où ils peuvent transmettre et de la durée pendant laquelle ils le peuvent, le message contient les informations en unités de mini-lots.

Le nombre maximal de mini-lots qu'un modem peut demander de transmettre en une rafale est de 255. La taille du mini-lot est spécifiée dans les unités appelées graduations DOCSIS. Une graduation DOCSIS équivaut à 6,25 microsecondes dans le temps.

Pour définir la taille du mini-lot en graduations pour un port en amont, émettez le câble <numéro-amont> minislot-size [1] | 2 | 4 | 8 | 16 | 32 | 64 | 128] commande d'interface de câble.

Seules certaines tailles de mini-lot sont autorisées avec des largeurs de canaux en amont particulières. Ce tableau montre les tailles de mini-lot valides par rapport aux largeurs de canal en amont DOCSIS, et montre également la longueur dans les symboles de schéma de modulation d'un mini-lot avec des paramètres valides.

Remarque : Une marque X signifie une combinaison non valide.

	Largeur du canal	200 kHz	400 kHz	800 kHz	1,6 MHz	3,2 MHz	6,4 MHz
Taille du mini-lot en tiques
1		X	X	X	X	X	32
2		X	X	X	X	32	64
4		X	X	X	32	64	128
8		X	X	32	64	128	256
16		X	32	64	128	256	X
32		32	64	128	256	X	X
64		64	128	256	X	X	X
128		128	256	X	X	X	X

Pour calculer le nombre d'octets transmis par mini-lot, multipliez les symboles par mini-lot par le nombre de bits par symbole du schéma de modulation configuré. Différents schémas de modulation transmettent différents nombres de bits par symbole, comme indiqué dans ce tableau :

Schémas de modulation DOCSIS 1.1 TDMA	Bits par symbole
QPSK	2
16-QAM	4

Schémas de modulation ATDMA DOCSIS 2.0	Bits par symbole
8 QAM	3
32-QAM	5
MAQ-64	6

Par exemple, avec une largeur de canal de 1,6 MHz et une taille de mini-lot de 4 tiques, vous pouvez utiliser le premier tableau pour obtenir une figure de 32 symboles par mini-lot. Utilisez le deuxième tableau pour convertir cette figure en octets, car un symbole QPSK contient 2 bits. Un mini-lot dans cet exemple équivaut à 32 symboles par mini-lot * 2 bits par symbole = 64 bits par mini-lot = 8 octets par mini-lot.

N’oubliez pas que le nombre maximal de mini-lots qu’un modem câble peut demander à transmettre est de 255. Par conséquent, dans cet exemple en amont, la plus grande rafale d'octets qu'un modem peut faire est 255 mini-lots * 8 octets par mini-lot = 2 040 octets.

Notez que cette figure en octets correspond à la correction d'erreur post-transfert et à la figure de surcharge de couche physique post-transfert. La correction des erreurs et d'autres surcharges de couche PHY DOCSIS ajoutent environ 10 à 20 % à la longueur d'une trame Ethernet lorsqu'elle passe par le canal en amont. Pour obtenir la figure précise, utilisez le profil de modulation appliqué au port en amont.

Cette discussion est importante car une section précédente de ce document indique que l'une des limites de la taille de rafale maximale d'un modem câble est la valeur configurée dans la commande cable default-phy-burst. Si la commande cable default-phy-burst est définie sur 4 000 octets dans le contexte de cet exemple, le facteur de limitation ou la taille de rafale est la limite de 255 mini-lot (2 040 octets moins la surcharge) plutôt que la valeur cable default-phy-burst.

Vous pouvez observer différentes expressions de la taille du mini-lot pour un amont à l'aide de la commande show controller cable interface-number en amont numéro-amont. Voici un exemple :

uBR7200VXR# show controller cable 5/0 upstream 0
 Cable5/0 Upstream 0 is up
  Frequency 20.600 MHz, Channel Width 1.600 MHz, QPSK Symbol Rate 1.280 Msps
  This upstream is mapped to physical port 0
  Spectrum Group 1, Last Frequency Hop Data Error: NO(0)
  MC28U CNR measurement : better than 40 dB
  US phy MER(SNR)_estimate for good packets - 36.1280 dB
  Nominal Input Power Level 0 dBmV, Tx Timing Offset 3100
  Ranging Backoff Start 3, Ranging Backoff End 6
  Ranging Insertion Interval automatic (60 ms)
  US throttling off
  Tx Backoff Start 3, Tx Backoff End 5
  Modulation Profile Group 41
  Concatenation is enabled
  Fragmentation is enabled
  part_id=0x3138, rev_id=0x03, rev2_id=0x00
  nb_agc_thr=0x0000, nb_agc_nom=0x0000
  Range Load Reg Size=0x58
  Request Load Reg Size=0x0E
  Minislot Size in number of Timebase Ticks is = 8
  Minislot Size in Symbols = 64
  Bandwidth Requests = 0x338C
  Piggyback Requests = 0x66D
  Invalid BW Requests= 0xD9
  Minislots Requested= 0x756C2
  Minislots Granted  = 0x4E09
  Minislot Size in Bytes = 16
  Map Advance (Dynamic) : 2482 usecs
  UCD Count = 8353

Cisco vous recommande de définir la taille du mini-lot de sorte qu'un mini-lot soit équivalent à 16 octets ou à la valeur la plus proche autorisée. Une taille de mini-lot de 16 octets permet aux modems câble de générer une rafale post-FEC allant jusqu'à 255 * 16 = 4096 octets.

Annexe B : Avance MAP

Le CMTS génère périodiquement un message spécial appelé MAP d'allocation de bande passante qui informe les modems câble d'un moment précis où les modems peuvent transmettre des données sur le canal en amont. Les signaux électriques qui véhiculent le message MAP prennent un certain temps pour se propager physiquement via le réseau HFC (Hybrid Fiber Coax) du CMTS à tous les modems câble connectés. Par conséquent, le message MAP doit être transmis suffisamment tôt pour que les modems puissent recevoir le message et être en mesure de transmettre leurs transmissions en amont afin qu'ils atteignent le CMTS au moment désigné.

Le délai d'avance MAP ou le délai d'attente MAP représente la différence entre l'heure à laquelle le CMTS génère le message MAP et l'heure à laquelle la première transmission commandée par le MAP doit être reçue par le CMTS. Cette fois représente une combinaison de ces retards présents dans un système DOCSIS :

• Temps nécessaire au CMTS pour construire le message MAP dans le logiciel et pour que le message soit mis en file d'attente et traité par le circuit de transmission en aval. La valeur de ce composant est spécifique à différentes plates-formes et architectures et est généralement une valeur fixe.

• La latence que la fonction d'entrelacement en aval ajoute, qui est utilisée à des fins de correction d'erreur de transfert pour se protéger contre le bruit d'impulsion. Pour modifier cette valeur, modifiez les paramètres de l'entrelaceur en aval.

• Temps nécessaire aux signaux électriques pour traverser le réseau HFC du CMTS au modem câble, puis de nouveau. DOCSIS spécifie un temps de trajet aller-retour maximal entre le CMTS et le modem câble de 800 microsecondes. Cette valeur varie en fonction de la longueur physique du câblage. Le schéma de modulation en aval et le schéma de modulation et de largeur de canal en amont influent également sur cette valeur.

• Durée pendant laquelle le modem câble traite un message MAP reçu et peut se préparer à la transmission en amont. Ce délai ne doit pas dépasser 200 microsecondes plus tout délai d'interleaver en amont, conformément aux directives de la spécification DOCSIS. En réalité, cette durée peut atteindre 300 microsecondes ou 100 microsecondes selon la marque, le modèle et la révision du micrologiciel du modem câble.

Figure 35 - Composants du temps d'avance MAP

Le délai d'avance de la carte peut affecter de manière significative la latence des transmissions en amont, car cette valeur représente le délai minimal entre le moment où le CMTS sait qu'un modem câble veut effectuer une transmission et le moment où le modem est autorisé à effectuer cette transmission. Pour cette raison, réduisez le temps d'avance de la carte pour réduire la latence en amont.

Notez que dans un amont congestionné, d'autres facteurs influencent également la latence en amont. Par exemple, retarde la création de l'algorithme de demande de bande passante de retour arrière et de nouvelle tentative, ainsi que la mise en file d'attente des subventions en attente les unes derrière les autres.

La figure 36 montre la relation entre un MAP généré par le CMTS et la réception de données correspondante en amont.

Figure 36 - Relation entre la génération MAP et la réception de données en amont

Profondeur de l'interleaver

Le premier facteur du temps d'avance de la carte qui peut varier est l'entrelaceur en aval utilisé pour la protection contre le bruit des impulsions. Ce tableau montre la latence ajoutée aux transmissions en aval pour divers paramètres d'incrémentation de l'interleaver et de l'interleaver :

Note : Plus la taille du robinet est grande, plus la correction des erreurs est puissante, mais plus la latence induite est importante.

I (Nombre de prises)	J (incrément)	Latence 64-QAM	Latence 256-QAM
8	16	220 µs	150 µs
16	8	480 µs	330 µs
32	4	980 µs	680 µs
64	2	2 000 µs	1 400 µs
128	1	4 000 µs	2 800 µs
12 (EuroDOCSIS)	17 (EuroDOCSIS)	430 µs	320 µs

Vous pouvez définir les paramètres de l'interleaver avec le câble aval interleave-profondeur [8 | 16 | 32 | 64 | 128] commande de configuration d'interface de câble

Remarque : La valeur de I (nombre de robinets) est spécifiée et une valeur correspondante fixe pour J (incrément) telle qu'elle apparaît dans le tableau s'applique automatiquement. En outre, pour le mode EuroDOCSIS (Annexe A), les paramètres interleaver sont fixés à I = 12 et J = 17. La valeur par défaut pour I est 32, ce qui donne une valeur par défaut pour J de 4.

Durée du trajet aller-retour

Le deuxième facteur qui contribue au temps avancé de cartographie qui peut être modifié est le temps de transmission électrique entre le CMTS et les modems câble. La distance physique entre le CMTS et les modems câble et le délai de traitement inhérent aux modems câble influencent cette valeur.

La spécification DOCSIS stipule que le temps de propagation à sens unique maximal autorisé entre le CMTS et le modem câble le plus éloigné du système ne doit pas dépasser 800 microsecondes. Cela implique un temps de trajet aller-retour d'environ 1 600 microsecondes, à l'exclusion du délai de traitement du modem câble.

La vitesse de la lumière dans le vide est d'environ 186 000 milles par seconde (300 000 kilomètres par seconde) et la vitesse de propagation de la fibre est généralement citée à 0,67. Par conséquent, la distance d’un chemin maximum autorisée entre un CMTS et un modem câble est approximativement :

	Distance = Velocity * Time

       		 = (186,000 miles/sec * 0.67) * 800 microseconds

       		 = 100 miles or 161 kilometers.

Conformément à la spécification DOCSIS, le délai de traitement du modem câble ne doit pas dépasser 200 microsecondes plus tout délai d'entrelacement en amont. Cependant, dans de rares cas, certaines marques plus anciennes de modem câble peuvent prendre jusqu'à 300 microsecondes pour traiter un message MAP. Les nouveaux types de modems câblés dotés de processeurs plus puissants peuvent prendre jusqu'à 100 microsecondes pour traiter un message MAP.

Supposez que les modems câble sont, en moyenne, conformes à la spécification DOCSIS. Par conséquent, la durée maximale du trajet aller-retour doit être de 1 600 + 200 = 1 800 microsecondes.

La plupart des systèmes de câblage sont beaucoup plus courts que 100 miles. Par conséquent, il n'est pas optimal pour un CMTS de toujours supposer que le temps de transmission électrique entre le CMTS et le modem câble le plus éloigné est la valeur maximale de 1 800 microsecondes.

Pour une estimation approximative du temps de transmission électrique le plus important attendu, additionnez la distance de la fibre entre le CMTS et le modem câble et multipliez par 16 microsecondes par mille (10 microsecondes par km). Ensuite, additionnez la distance de tout coaxial et multipliez cette valeur par 12,4 microsecondes par mille (7,6 microsecondes par km). Ajoutez ensuite le délai de traitement de 200 microsecondes.

Par exemple, un segment HFC avec un total de 20 milles de fibre et un mille de coaxial entre le CMTS et le modem câble le plus éloigné peut s'attendre à un délai de transmission électrique de :

20 miles * 16 microseconds/mile + 1 mile * 12.4 microseconds/mile + 200 microseconds
 
= 320 microseconds + 12.4 microseconds + 200 microseconds

= 532.4 microseconds

Ce chiffre ne tient pas compte des retards supplémentaires dus aux caractéristiques des canaux en amont et en aval et aux variations des temps de traitement des modems. Par conséquent, cette valeur n'est pas appropriée à utiliser lorsque vous calculez le temps d'avance MAP.

Une méthode plus précise pour déterminer le temps de trajet aller-retour dans un système consiste à observer le ” de décalage “ pour les modems câble, comme le montre le résultat de la commande show cable modem.Dans le cadre du processus de plage utilisé par les modems câble pour maintenir la communication avec le CMTS, le CMTS calcule le temps de trajet aller-retour pour chaque modem câble. Ce temps de retour apparaît comme le ” de décalage de temporisation “ dans la sortie de commande show cable modem en unités de 1/10,24 MHz = 97,7 nanosecondes appelées décalages de temporisation ou décalages de distance. Pour convertir le décalage temporel d'un modem en microsecondes, multipliez la valeur par 25/256 ou divisez la valeur par 10.

Voici un exemple dans lequel les décalages temporels de divers modems dans la sortie de commande show cable modem sont convertis en une valeur de microseconde :

Remarque : La valeur de la microseconde apparaît en italique.

uBR7200VXR# show cable modem
MAC Address    IP Address   I/F       MAC         Prim RxPwr Timing  Num BPI
                                      State       Sid  (dB)  Offset  CPE Enb
00aa.bb99.0859 4.24.64.28   C5/1/U0   online(pt)  16   0.00  2027     0   Y  (198μs)
00aa.bb99.7459 4.24.64.11   C5/1/U0   online(pt)  17   1.00  3528     0   Y  (345μs)
00aa.bbf3.7258 4.24.64.31   C5/1/U0   online(pt)  18   0.00  2531     0   Y  (247μs)
00aa.bbf3.5658 4.24.64.39   C5/1/U0   online(pt)  19   0.00  6030     0   Y  (589μs)

Dans ce cas, le modem le plus éloigné électriquement est le dernier modem avec un décalage temporel de 6030. Cela équivaut à un temps de trajet aller-retour de 6030 * 25/256 = 589 microsecondes.

Avance MAP statique

Dans un système où vous savez que la longueur du réseau HFC est significativement inférieure à 100 miles, vous pouvez configurer le CMTS pour qu'il utilise un temps de trajet aller-retour maximum inférieur à la durée standard de 1 800 microsecondes lorsque vous calculez le temps d'avance MAP.

Pour forcer le CMTS à utiliser une valeur personnalisée pour le temps aller-retour dans le calcul avancé MAP, émettez la commande d'interface de câble cable map-advanced static max-round-trip-time.

La plage de temps max-aller-retour est comprise entre 100 et 2 000 microsecondes. Si aucune valeur n'est spécifiée pour max-round-trip-time, la valeur par défaut de 1 800 microsecondes s'applique.

Note : Vous pouvez remplacer le mot clé statique par le mot clé dynamique. Reportez-vous à la section suivante.

Assurez-vous que le temps de trajet aller-retour spécifié est en effet supérieur au temps de trajet aller-retour le plus important du CMTS vers le modem câble sur le canal en aval. Si un modem câble a un temps de trajet aller-retour supérieur à celui spécifié dans max-round-trip-time, il peut être difficile pour le modem de rester en ligne. En effet, un tel modem ne dispose pas de suffisamment de temps pour répondre à un message MAP et ne peut donc pas communiquer avec le CMTS.

Si le décalage temporel d'un modem câble, converti en microsecondes, dépasse le délai maximal d'aller-retour spécifié, le modem est marqué avec l'indicateur de décalage de temporisation incorrect. Cet indicateur de décalage apparaît sous la forme d'un point d'exclamation (!) en regard du décalage temporel du modem câble dans la sortie de la commande show cable modem. Cette situation peut se produire si le paramètre max-round-trip-time est défini trop bas ou si le modem câble souffre d'un problème où son décalage temporel est instable et augmente constamment au fil du temps.

Voici un exemple :

uBR7200VXR# show cable modem
MAC Address    IP Address   I/F      MAC         Prim RxPwr  Timing  Num BPI
                                     State       Sid  (dB)   Offset  CPE Enb
00aa.bb99.0859 4.24.64.28   C5/1/U0  online(pt)  16   0.00  2027     0   Y  (198μs)
00aa.bb99.7459 4.24.64.11   C5/1/U0  online(pt)  17   1.00  3528     0   Y  (345μs)
00aa.bbf3.7258 4.24.64.31   C5/1/U0  online(pt)  18   0.00  2531     0   Y  (247μs)
00aa.bbf3.5658 4.24.64.39   C5/1/U0  online(pt)  19   0.00  !5120    0   Y  (500μs)

Dans cet exemple, la commande cable map-advanced static 500 est spécifiée. Cependant, un des modems câble connectés à l'interface de câble a un décalage de synchronisation supérieur à 500 microsecondes (équivalent à 500 * 256/25 = 5 120 unités de décalage de synchronisation).

Notez que le décalage de synchronisation du dernier modem câble est marqué par l'indicateur de décalage de synchronisation incorrect, un ” “ ! Cette valeur est également fixée à la valeur maximale autorisée de 5 120 unités, même si le décalage de synchronisation réel peut être beaucoup plus élevé. Ce modem câble peut se déconnecter et présenter des performances médiocres.

L'indicateur de décalage de synchronisation incorrect reste défini pour le modem câble, même si le décalage de synchronisation est inférieur au délai max-round-trip-time. La seule façon de supprimer l'indicateur est de retirer temporairement le modem de la liste show cable modem. Pour cela, vous pouvez utiliser la commande clear cable modem mac-address delete. Vous pouvez également réinitialiser l'interface du câble ou le port en amont.

Pour observer le fonctionnement de l'algorithme d'avance de la carte statique sur une base par amont, émettez la commande show controller cable interface-number en amont numéro-amont. Voici un exemple :

uBR7200VXR# show controller cable 5/0 upstream 0
 Cable5/0 Upstream 0 is up
  Frequency 20.600 MHz, Channel Width 1.600 MHz, QPSK Symbol Rate 1.280 Msps
  This upstream is mapped to physical port 0
  Spectrum Group is overridden
  US phy MER(SNR)_estimate for good packets - 36.1280 dB
  Nominal Input Power Level 0 dBmV, Tx Timing Offset 2037
  Ranging Backoff automatic (Start 0, End 3)
  Ranging Insertion Interval automatic (60 ms)
  US throttling off
  Tx Backoff automatic (Start 0, End 3)
  Modulation Profile Group 43
  Concatenation is enabled
  Fragmentation is enabled
  part_id=0x3138, rev_id=0x03, rev2_id=0x00
  nb_agc_thr=0x0000, nb_agc_nom=0x0000
  Range Load Reg Size=0x58
  Request Load Reg Size=0x0E
  Minislot Size in number of Timebase Ticks is = 16
  Minislot Size in Symbols = 128
  Bandwidth Requests = 0x6ECEA
  Piggyback Requests = 0xDE79
  Invalid BW Requests= 0x63D
  Minislots Requested= 0x8DEE0E
  Minislots Granted  = 0x7CE03
  Minislot Size in Bytes = 32
  Map Advance (Static) : 3480 usecs
  UCD Count = 289392

Le champ Avance de la carte (statique) indique un délai d'avance de la carte de 3 480 microsecondes. Si vous modifiez les caractéristiques de l'entrelaceur en aval ou le paramètre max-round-trip-time, la modification est reflétée dans la valeur d'avance de la carte statique.

Avancement MAP dynamique

L'utilisation du calcul statique de l'avance MAP pour optimiser les temps d'avance MAP nécessite que l'opérateur CMTS détermine manuellement le temps de trajet aller-retour le plus important sur un segment de câble. Si les caractéristiques des canaux en aval ou en amont changent, ou si les conditions de l'usine changent, le temps maximal de trajet aller-retour peut changer de façon significative. Il peut être difficile de mettre continuellement à jour la configuration pour tenir compte de l'évolution des conditions du système.

L'algorithme d'avance MAP dynamique résout ce problème. L'algorithme d'avance MAP dynamique analyse périodiquement la liste show cable modem pour rechercher le modem avec le décalage initial de la plage de synchronisation le plus important, puis utilise automatiquement cette valeur pour calculer le temps d'avance MAP. Ainsi, le CMTS utilise toujours le temps d'avance de la carte le plus bas possible.

Le décalage de synchronisation initial d'un modem câble est le décalage de synchronisation que le modem signale au point où le modem se connecte. Dans la plupart des cas, ceci est proche du décalage de synchronisation en cours tel qu'indiqué dans la sortie de la commande show cable modem. Cependant, certains types de modems câble ont un problème lorsque le décalage de synchronisation augmente au fil du temps pour atteindre des valeurs très élevées. Cela peut fausser le calcul du temps avancé de la carte. Par conséquent, seul le décalage de temporisation initial, qui n'est mis à jour que si un modem est mis en ligne, est utilisé. Pour afficher le décalage de synchronisation initial et le décalage de synchronisation en cours d'un modem câble, exécutez la commande show cable modem verbose. Voici un exemple :

uBR7200VXR# show cable modem 00aa.bbf3.7858 verbose
MAC Address                         : 00aa.bbf3.7858
IP Address                          : 4.24.64.18
Prim Sid                            : 48
Interface                           : C5/1/U0
Upstream Power                      : 39.06 dBmV (SNR = 36.12 dB)
Downstream Power                    : 14.01 dBmV (SNR = 35.04 dB)
Timing Offset                       : 2566
Initial Timing Offset               : 2560
Received Power                      :  0.00 dBmV
MAC Version                         : DOC1.1
QoS Provisioned Mode                : DOC1.1
Enable DOCSIS2.0 Mode               : Y
Phy Operating Mode                  : tdma
Capabilities                        : {Frag=Y, Concat=Y, PHS=Y, Priv=BPI+}
Sid/Said Limit                      : {Max US Sids=16, Max DS Saids=15}
Optional Filtering Support          : {802.1P=N, 802.1Q=N}
Transmit Equalizer Support          : {Taps/Symbol= 1, Num of Taps= 8}
Number of CPE IPs                   : 0(Max CPE IPs = 16)
CFG Max-CPE                         : 32
Flaps                               : 4(Mar 13 21:13:50)
Errors                              : 0 CRCs, 0 HCSes
Stn Mtn Failures                    : 0 aborts, 1 exhausted
Total US Flows                      : 1(1 active)
Total DS Flows                      : 1(1 active)
Total US Data                       : 321 packets, 40199 bytes
Total US Throughput                 : 129 bits/sec, 0 packets/sec
Total DS Data                       : 28 packets, 2516 bytes
Total DS Throughput                 : 0 bits/sec, 0 packets/sec
Active Classifiers                  : 0 (Max = NO LIMIT)
DSA/DSX messages                    : permit all
Total Time Online                   : 1h00m

Dans cet exemple, le décalage temporel continu (2566) est légèrement supérieur au décalage temporel initial de la plage de valeurs (2560). Ces valeurs peuvent différer légèrement. Cependant, si les valeurs diffèrent de plus de quelques centaines d’unités, il peut y avoir un problème avec le contrôle de décalage de synchronisation du modem câble.

Pour activer le calcul d'avance de la carte dynamique, émettez la commande d'interface de câble cable map-advanced dynamic security-factor max-round-trip-time.

Le paramètre de facteur de sécurité varie de 100 à 2 000 microsecondes. Ce paramètre est ajouté au temps d'avance MAP afin de fournir une petite sauvegarde pour tenir compte de tout retard imprévu supplémentaire dans la propagation du signal. La valeur par défaut est 1 000 microsecondes. Toutefois, pour les systèmes de câblage stables qui ne subissent pas de modifications importantes dans l’installation de câblage ou dans les caractéristiques des canaux en amont ou en aval, utilisez une valeur inférieure, par exemple 500 microsecondes.

Le paramètre max-round-trip-time varie de 100 à 2 000 microsecondes. Ce paramètre est utilisé comme limite supérieure pour les décalages temporels des modems câble connectés au segment de câble. La valeur par défaut est 1 800 microsecondes. Si le décalage temporel d'un modem câble, converti en microsecondes, dépasse le délai maximal d'aller-retour spécifié, il apparaît marqué par l'indicateur de décalage de temporisation incorrect.

Définissez le paramètre max-round-trip time sur une valeur autre que la valeur par défaut lorsque vous savez que la longueur du système de câblage est sensiblement inférieure à 100 miles et que vous savez quel doit être le décalage horaire normal maximal pour les modems câble connectés au segment.

Observez le fonctionnement de l'algorithme d'avance de la carte dynamique sur une base par amont à l'aide de la commande show controller cable interface-number en amont numéro-amont. Voici un exemple :

uBR7200VXR# show controller cable 5/0 upstream 0
 Cable5/0 Upstream 0 is up
  Frequency 20.600 MHz, Channel Width 1.600 MHz, QPSK Symbol Rate 1.280 Msps
  This upstream is mapped to physical port 0
  Spectrum Group 1, Last Frequency Hop Data Error: NO(0)
  MC28U CNR measurement : better than 40 dB
  US phy MER(SNR)_estimate for good packets - 36.1280 dB
  Nominal Input Power Level 0 dBmV, Tx Timing Offset 3100
  Ranging Backoff Start 3, Ranging Backoff End 6
  Ranging Insertion Interval automatic (60 ms)
  US throttling off
  Tx Backoff Start 3, Tx Backoff End 5
  Modulation Profile Group 41
  Concatenation is enabled
  Fragmentation is enabled
  part_id=0x3138, rev_id=0x03, rev2_id=0x00
  nb_agc_thr=0x0000, nb_agc_nom=0x0000
  Range Load Reg Size=0x58
  Request Load Reg Size=0x0E
  Minislot Size in number of Timebase Ticks is = 8
  Minislot Size in Symbols = 64
  Bandwidth Requests = 0x338C
  Piggyback Requests = 0x66D
  Invalid BW Requests= 0xD9
  Minislots Requested= 0x756C2
  Minislots Granted  = 0x4E09
  Minislot Size in Bytes = 16
  Map Advance (Dynamic) : 2482 usecs
  UCD Count = 8353

La valeur Tx Timing Offset indique le décalage de synchronisation le plus important pour tous les modems câble connectés à l'amont en unités de décalage de synchronisation. Utilisez cette valeur pour calculer le temps d'avance MAP. Le champ Avance de la carte (dynamique) indique le délai d'avance de la carte résultant. Cette valeur peut varier si le décalage temporel Tx change, si la valeur de sécurité est modifiée ou si les caractéristiques de l'intercalaire en aval sont modifiées.

L'algorithme d'avance MAP dynamique dépend de la mesure dans laquelle les modems câble signalent correctement le décalage initial de la plage de synchronisation au CMTS. Malheureusement, certaines marques et certains modèles de modems câblés indiquent que les décalages de synchronisation de la gamme initiale sont des valeurs nettement inférieures à la valeur réelle. Vous pouvez observer cela lorsque les modems affichent des décalages de synchronisation proches de zéro, voire des valeurs négatives.

Messages d'erreur similaires à %UBR7200-4-BADTXOFFSET : Décalage de synchronisation incorrect - 2 détecté pour le modem câble 00ff.0bad.caf3 peut apparaître sur ces modems câble. Ces types de modems câble ne signalent pas leurs décalages de synchronisation de manière conforme à DOCSIS. L'algorithme d'avance de carte dynamique ne peut pas calculer correctement un délai d'avance de carte garanti pour chaque modem câble afin de recevoir et de répondre aux messages MAP.

Si de tels modems sont présents sur un segment de câble, désactivez l'algorithme d'avance MAP dynamique et revenez à l'algorithme d'avance MAP statique. Reportez-vous à Pourquoi certains modems câble affichent-ils un décalage temporel négatif ? pour plus d'informations.

Informations connexes

• Support et documentation techniques - Cisco Systems