Câble DOCSIS 1.0 - Forum Aux Questions
Contenu
Ce document répond aux questions fréquemment posées au sujet de la spécification DOCSIS 1.0 (Data Over Cable Service Interface Specification).
Q. Qu'est-ce que DOCSIS 1.0+ ?
A. La mise en oeuvre DOCSIS 1.0+ (Data-over-Cable Service Interface Specifications) est DOCSIS 1.0 avec des extensions QoS (Quality of Service) pour la prise en charge de la voix, de la télécopie et de la vidéo en temps réel sur un réseau local. DOCSIS 1.0+ n’est pas une spécification nouvelle ou intermédiaire des TP sur les câbles. L'ensemble de l'architecture DOCSIS1.0+ est une solution de délai de commercialisation fournie par Cisco et certains fournisseurs de modem câble jusqu'à ce que les spécifications et le développement de DOCSIS 1.1 soient largement disponibles.
Q. Les modems câble DOCSIS 1.0 sont-ils compatibles avec les CMTS DOCSIS 1.0+ ?
A. Oui. DOCSIS 1.0+ est entièrement rétrocompatible avec DOCSIS 1.0. Il est important de se rappeler que tous les services QoS spéciaux du système CMTS (Cable Modem Termination System) DOCSIS 1.0+ ne sont activés que lorsqu'un modem câble DOCSIS 1.0+ sollicite ces services via de nouveaux messages MAC (Media Access Control) dynamiques. Si votre CM est DOCSIS 1.0 pur, il ne pourra pas activer ces services et recevra un traitement DOCSIS 1.0 régulier du CMTS DOCSIS 1.0+.
Q. Quelles sont les extensions QoS privées ?
A. DOCSIS 1.0+ offre des fonctions QoS supplémentaires pour les paquets voix, télécopie et données en temps réel à partir des modems câble de téléphonie intégrés (ITCM). Dans DOCSIS 1.0+, les extensions privées ajoutées à DOCSIS 1.0 sont les suivantes :
Deux nouveaux messages MAC dynamiques initiés par CM : DSA (Dynamic Service Addition) et DSD (Dynamic Service Delection). Ces messages permettent de créer ou de supprimer des ID de service (SID) dynamiques au moment de l'exécution par appel.
Service de subvention non sollicité (planification CBR [constant bit rate]) en amont. Cela fournit un canal QoS de haute qualité pour les paquets voix/télécopie CBR en amont de l'ITCM.
Pour tout ITCM donné, possibilité de fournir des débits en aval distincts en fonction de la valeur de priorité IP dans le paquet. Cela permet de séparer le trafic voix, de signalisation et de données transmis au même ITCM à des fins de formatage de débit.
Q. Comment fonctionne l'architecture DOCSIS 1.0+ ?
A. Prenons un exemple où l'abonné M. X a rejoint votre service et souhaite obtenir le package de services suivant :
Un service de données avec un débit de pointe en amont (États-Unis) de 128 kBps, un débit de signal numérique de pointe de 2 Mbits/s
Deux lignes téléphoniques virtuelles
Voici les étapes à suivre :
Le système d'approvisionnement prépare un fichier de configuration pour l'abonné ITCM à l'aide de n'importe quel éditeur de fichier de configuration de type DOCSIS 1.0 disponible. Le fichier de configuration contient :
Un paramètre de classe de service standard de type DOCSIS 1.0 pour le service de données avec un débit US de 128 kBps, débit DS maximal de 2 Mbits/s.
Codage spécifique au fournisseur appelé « nombre de lignes téléphoniques », défini sur 2.
Un codage spécifique au fournisseur appelé « Per IP priority rate limit tuple », qui définit les limites de débit en aval pour les paquets IP de priorité spéciale.
L'ITCM télécharge ce fichier de configuration au moment de l'enregistrement et envoie les informations de mise en service au CMTS DOCSIS 1.0+.
Lorsque CMTS reçoit la demande d'enregistrement (REG-REQ), il crée une entrée de base de données locale pour l'ITCM. Un SID statique est immédiatement attribué à l'ITCM pour le service de données. Pour le service de ligne téléphonique, le CMTS crée uniquement deux flux de service différés (pour activation ultérieure) dans l'entrée de base de données de l'ITCM. Aucun SID n'est attribué au service de ligne téléphonique lors de l'enregistrement.
Chaque fois qu'un ITCM souhaite obtenir un canal voix ou télécopie avec un service CBR en temps réel, il envoie un message MAC DSA-REQ au CMTS, en spécifiant ses exigences spéciales de planification CBR telles que grant-size et grant-interval (grant-size et grant-interval dépendent du codeur-décodeur G.711/G.729 utilisé sur l'ITCM). Pour plus d'informations sur les types de CODEC, consultez Cisco uBR7200 - Améliorations QoS/MAC pour les appels vocaux et de télécopie : DOCSIS 1.0+.
Lorsque CMTS reçoit la DSA-REQ, il vérifie d'abord l'entrée de la base de données de l'ITCM pour voir si un flux de service différé est disponible. Si un flux de service différé est disponible, le CMTS attribue un nouveau SID dynamique pour cet ITCM et déclenche des subventions non sollicitées (logements CBR) sur ce SID dynamique nouvellement attribué. Le CMTS informe l'ITCM du SID dynamique nouvellement attribué à l'aide du DSA-RSP.
Étant donné que le CMTS peut prendre en charge la nouvelle connexion CBR, ITCM continue d'obtenir des subventions non sollicitées de la bonne taille de paquet (suffisamment pour s'adapter à la voix et à la télécopie périodiques) à des intervalles réguliers. L'ITCM n'a pas besoin de rivaliser avec aucun autre CM sur le serveur en amont pour envoyer ces paquets en temps réel. Il dispose d'un sous-canal dédié de multiplexage temporel (TDM) en amont sous la forme de subventions non sollicitées. La gigue est bien limitée ou limitée (vous n'obtiendrez pas de différences de délai importantes entre les paquets), et une bonne qualité vocale est ainsi maintenue sur le chemin en amont de ITCM vers uBR7200.
L'ITCM colore les bits de priorité dans l'en-tête IP de ces paquets vocaux avec la valeur prédéfinie 0x05 pour propager la QoS d'accès local préférentiel dans le backbone IP.
Lorsque les paquets vocaux arrivent au CMTS dans les logements CBR, ils sont soit commutés dans le WAN (nuage IP), soit transférés à un autre ITCM sur le canal en aval.
S'ils sont commutés dans le nuage WAN, vous devez configurer les routeurs de backbone, tels que le routeur de commutation Gigabit (GSR), pour reconnaître et accorder un traitement préférentiel pour ces paquets de transport vocal (valeur de priorité 0x05) par rapport aux paquets de données de signalisation ou aux paquets de données au meilleur effort réguliers avec priorité 0x3 et 0x0, respectivement.
Si les paquets en amont sont commutés sur le canal en aval du même uBR7200, les paquets vocaux 0x05 sont traités séparément pour la limitation de débit par rapport aux paquets de données de signalisation en fonction de leurs valeurs de priorité.
Même si, au moment de l'appel, l'ITCM de destination effectuait un transfert de fichiers en aval important, les paquets vocaux qui lui sont transmis sur le même canal en aval ne seront pas affectés par le protocole FTP (File Transfer Protocol) sur le même processeur ITCM en raison de l'utilisation de valeurs de priorité IP lors de la comptabilisation de la bande passante en aval.
Une fois l'appel terminé, l'ITCM envoie une DSD-REQ au CMTS pour libérer le SID dynamique. Le CMTS arrête les subventions CBR, détruit le SID dynamique indiqué dans DSD-REQ, libère un flux différé pour l'ITCM et envoie un DSD-RSP à l'ITCM confirmant qu'il l'a fait.
Q. Comment s'assurer qu'un abonné ITCM provisionné pour deux lignes téléphoniques virtuelles obtient jusqu'à deux SID QoS CBR dynamiques de haute qualité au moment de l'exécution ?
A. Chaque fois que l'ITCM envoie une DSA-REQ demandant un nouveau SID dynamique, le CMTS vérifie d'abord si ce dernier dispose de flux de services différés inutilisés avant de créer un SID dynamique. Si l'ITCM utilise déjà deux SID dynamiques, les deux flux de services différés s'affichent comme étant en cours d'utilisation au CMTS. Tant qu'un SID dynamique utilise le flux de service, le flux de service n'est pas disponible pour la création de nouveaux SID dynamiques à partir de cet ITCM.
Q. Dois-je provisionner séparément les lignes voix et télécopie ?
A. Non. Le concept de ligne téléphonique virtuelle est très similaire à une ligne téléphonique réelle. Vous pouvez utiliser de manière transparente chacune de ses N lignes téléphoniques virtuelles pour envoyer un appel voix ou un fax. Le CMTS DOCSIS 1.0+ n'applique pas le type de trafic d'applications envoyé par l'ITCM dans les subventions non sollicitées (logements CBR) de son SID dynamique.
Q. Existe-t-il une fragmentation dans DOCSIS 1.0+ ?
A. Non. Cependant, les CMTS DOCSIS 1.0+ peuvent toujours fournir un bon service CBR en temps réel, car l'absence de fragmentation provoque quelques secondes de gigue supplémentaire pour les logements CBR (qui se trouvent dans les budgets de conception VoIP standard pour les liaisons d'accès locales). En outre, DOCSIS 1.0+ ne possède pas de classification de paquets et de suppression d'en-tête de charge utile, qui sont tous deux prévus pour la version DOCSIS 1.1.
Q. Comment mettre en service la QoS sur le système DOCSIS 1.0+ ?
A. Aux fins de cette section, nous supposons qu’un opérateur attend trois types de paquets de base sur le réseau IP de bout en bout :
Paquets IP avec priorité égale à 0x05 pour le transport de la voix ou de la télécopie
Paquets IP avec priorité égale à 0x03 pour la signalisation de la voix ou de la télécopie
Paquets IP avec une priorité autre que 0x03 ou 0x05 pour les données normales
Pour que la QoS de bout en bout fonctionne, il est important que tous les noeuds du réseau de bout en bout comprennent et respectent le mappage de priorité IP ci-dessus. Tous les noeuds de réseau allant de ITCM à uBR7200 en passant par les routeurs de backbone et la passerelle d'agrégation (TGW) devront avoir une interprétation cohérente de la priorité ci-dessus.
Pour un fichier de configuration TFTP (Trivial File Transfer Protocol) ITCM DOCSIS, nous supposons que l'ITCM est provisionné avec une seule classe de données Best Effort et deux lignes téléphoniques VoIP. Une variante immédiate consiste à fournir deux classes de données, une classe de données au mieux pour les paquets de données et les messages MAC et une classe de données CIR pour les paquets de signalisation vocale.
Pour le provisionnement statique de la ou des classes de services DOCSIS 1.0 pour le service de données régulier, l'ITCM peut se voir attribuer une ou plusieurs classes de services DOCSIS 1.0 statiques. L'opérateur est libre de choisir n'importe quelle combinaison des cinq paramètres ci-dessous pour concevoir un service de données personnalisé pour l'ITCM.
Un exemple de codage de classe de service DOCSIS 1.0 est fourni ci-dessous pour illustrer comment une classe de service de données ITCM typique peut apparaître dans le fichier de configuration :
Type Longueur Valeur (sous-type) Longueur Valeur Commentaires 4 28 Configuration de la classe de service 1 1 1 ID de classe 1 2 4 2000000 Débit maximal en aval égal à 2 Mbits/s 3 4 128000 Débit ascendant maximal égal à 128 kBps 4 1 5 Priorité en amont égale à 5 5 4 0 Pas de débit minimum en amont 6 2 1800 La rafale de transmission maximale est égale à 1 800 octets Préprovisionnement du nombre de lignes téléphoniques et provisionnement des limites de débit de priorité IP en aval
Ces deux nouveaux objets ne font pas partie de la classe de service DOCSIS 1.0 standard et sont donc codés à l'aide de la mention « Informations spécifiques au fournisseur » comme indiqué ci-dessous :
Type Longueur Valeur (sous-type) Longueur Valeur Commentaires 43 28 Informations sur les spécifications du fournisseur 8 3 0x00 0x00 0x00 ID fournisseur Cisco Valeur de longueur de sous-type spécifique au fournisseur Cisco 43:8:X
Type Longueur Valeur (sous-type) Longueur Valeur Commentaires 10 1 2 Deux lignes téléphoniques sont autorisées pour ITCM 11 18 1 1 0x05 0x00 0x00 Priorité de transport vocal (5) 2 4 128000 Limite de débit en aval de 128 kBps pour 0x05 1 1 0x03 Priorité de signalisation vocale (3) 2 4 64000 Limite de débit en aval de 64 kBps pour 0x03 Remarque : Tout le trafic en aval (à l'exception de la priorité IP 0x05 et 0x03) sera formaté en fonction du débit par défaut de 2 Mbits/s prévu dans la classe de service DOCSIS 1.0 Data de ITCM.
Q. Ai-je besoin d'un éditeur de fichiers de configuration spécial pour provisionner les extensions DOCSIS 1.0+ ?
A. Non. N'importe quel éditeur de fichier de configuration DOCSIS 1.0 standard prenant en charge des champs spécifiques au fournisseur fera le travail.
Q. Y a-t-il d'autres problèmes de configuration à l'échelle du réseau qui doivent être pris en compte dans l'environnement DOCSIS 1.0+ ?
A. Oui. Les paramètres de priorité IP utilisés pour séparer la voix et la signalisation des données doivent être connus et compris. Dans le cas d'un appel où un point d'extrémité se trouve en dehors du réseau câblé, il incombe au réseau « externe » de s'assurer que tous les paquets vocaux sont colorés de manière appropriée avant de les transmettre au uBR7200. Dans le cas d'un appel où les deux points d'extrémité se trouvent sur le réseau câblé, il incombe au point d'extrémité (ITCM) à l'origine du trafic de colorier les paquets vocaux avant de les lancer dans le réseau.
Q. Existe-t-il une configuration optimale sur le uBR7200 pour optimiser le nombre d'appels VoIP pour chaque port en amont ?
A. Oui. Cette section illustre des exemples de paramètres de couche physique qui pourraient être utilisés sur le CMTS pour les canaux en amont dont la densité d'appels VoIP est élevée. Ces paramètres tentent de minimiser la surcharge de la couche physique rencontrée pour chaque paquet vocal de taille fixe (89 octets). Le réglage fin qui en résulte améliore directement le nombre de connexions vocales CBR pouvant être admises sur un seul canal en amont. Les paramètres suivants doivent être configurés pour le canal en amont pour maximiser le nombre de connexions CBR :
Minislot size: 8 Symbol rate: 1280 ksymbols/sec Modulation type: QPSK Preamble length: 72 bits FEC error correction (T bytes): 2 bytes FEC codeword length: 52 bytes Guard time: 8 symbols Last codeword: shortened last codewordPour configurer le profil de modulation ci-dessus au niveau du CMTS, utilisez la CLI existante comme suit :
Créez un nouveau modèle de profil de modulation qpsk (m) avec tous les paramètres par défaut, à l'exception du profil « subvention courte » qui a des paramètres spéciaux comme indiqué ci-dessous :
cmts(config)#cable modulation-profile m qpsk cmts(config)#cable modulation-profile m short 2 52 16 8 qpsk scrambler 152 diff 72 shortened uw8Configurez le port en amont (n) sur une interface donnée pour utiliser la taille de mini-lot de 8 tiques et le modèle de profil de modulation supérieur (m) :
cmts(config-if)#cable upstream n minislot-size 8 cmts(config-if)#cable upstream n modulation-profile m
Q. Quelle version du logiciel Cisco IOS prend en charge DOCSIS 1.0+ ?
A. Le logiciel Cisco IOS® version 12.1(01)T prend en charge DOCSIS 1.0+ sur les routeurs Cisco uBR7200 et uBR924. La version 12.07XR du logiciel Cisco IOS fournit les images IOS pour les routeurs Cisco uBR7200 et uBR924.
Q. Quel est le plan de migration pour DOCSIS 1.0+ et DOCSIS 1.1 ?
A. Actuellement, le CMTS DOCSIS 1.1 est prévu pour la version 12.1(1)5EC du logiciel Cisco IOS. Jusque-là, DOCSIS 1.0+ est la solution de délai de commercialisation pour la voix et le fax en temps réel sur fibre optique-coaxial hybride (HFC). La migration de DOCSIS 1.0+ vers DOCSIS 1.1 devrait être une mise à niveau logicielle.
La mise en service de DOCSIS 1.1 nécessite un nouvel éditeur de fichiers de configuration et prend en charge toutes les fonctionnalités de DOCSIS 1.0+ en plus de plusieurs fonctionnalités QoS avancées. Le Cisco uBR7200 prend entièrement en charge les spécifications DOCSIS 1.1.
Q. Qui est responsable de la spécification DOCSIS, et où puis-je trouver les spécifications ?
A. CableLabs
, un organisme à but non lucratif de câblodistributeurs qui représentent l'Amérique du Nord et de l'Amérique du Sud, est responsable de la création de la spécification DOCSIS.
Vous trouverez les spécifications ici :
, un organisme à but non lucratif de câblodistributeurs qui représentent l'Amérique du Nord et de l'Amérique du Sud, est responsable de la création de la spécification DOCSIS.
Q. Quelle est la différence entre un fichier de configuration DOCSIS et un fichier de configuration Cisco IOS ?
A. Un fichier de configuration DOCSIS est un fichier binaire qui contient les paramètres permettant aux modems câble de se connecter en fonction des dispositions du FAI, telles que les débits en aval et en amont maximaux, le débit de rafale en amont maximal, la classe de service (CoS) ou la confidentialité de base, les MIB et de nombreux autres paramètres. Vous pouvez créer ce fichier avec Cisco DOCSIS CPE Configurator (clients enregistrés uniquement) ou avec plusieurs autres outils sur Internet. Pour savoir comment créer un fichier de configuration DOCSIS, reportez-vous à Création de fichiers de configuration DOCSIS 1.0 à l'aide de Cisco DOCSIS Configurator (clients enregistrés uniquement).
Un fichier de configuration Cisco IOS est un fichier texte ASCII qui peut contenir des configurations spécifiques, telles que des listes d’accès, des mots de passe, des configurations NAT (Network Address Translation), etc. Ces configurations peuvent être téléchargées dans le fichier de configuration DOCSIS.
Voici un exemple de fichier de configuration Cisco IOS nommé ios.cfg :
hostname SUCCEED service line service time deb date local msec service time log date local msec no service password no enable secret enable password ww line con 0 login pass ww line vty 0 4 password ww login snmp community public RO snmp community private RW endRemarque : pour les modems câble Cisco qui ne possèdent pas de port de console (similaire à la gamme Cisco CVA120), il est très courant d'envoyer la configuration Cisco IOS intégrée dans le fichier de configuration DOCSIS.
Q. Quelles sont les exigences minimales du protocole DOCSIS pour qu’un modem câble puisse être mis en ligne ?
A. Voici la configuration minimale requise pour le protocole DOCSIS :
Serveur ToD (Time of Day)
DHCP (Dynamic Host Configuration Protocol)
Trivial File Transfer Protocol (TFTP)
ToD est requis ; Cependant, Cable Labs a apporté quelques modifications qui assouplissent cette condition. Par conséquent, il est possible que d'autres fournisseurs de modem câble se connectent même s'ils ne passent pas à ToD. Si l'interface de confidentialité de la ligne de base (BPI) est activée, BPI est une condition supplémentaire.
Q. Où puis-je obtenir les modèles Cisco pour les fichiers de configuration DOCSIS ou BPI DOCSIS bronze.cm, silver.cm, gold.cm et platinum.cm ?
A. Vous pouvez obtenir les modèles ici :
DOCSIS : cmbootfiles.zip.
BPI (Baseline Privacy Interface) DOCSIS : cmbootfiles-bpi.zip.
Voici les spécifications des modèles :
Fichier DOCSIS cm Vitesse en aval Vitesse en amont Priorité CPE bronze.cm 128000 64000 1 1 bronze-bpi.cm argent.cm 512000 128000 3 1 silver-bpi.cm or.cm 2048000 512000 6 1 or-bpi.cm platine.cm 10000000 1024000 7 3 platine-bpi.cm
Informations connexes
Historique de révision
| Révision | Date de publication | Commentaires |
|---|---|---|
1.0 |
03-Sep-2006 |
Première publication |
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)