Câble haut débit : Data-over-Cable Service Interface Specifications (DOCSIS)

Foire aux questions de DOCSIS 1.0 de câble

18 octobre 2016 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu


Ce document répond à des forums aux questions au sujet du DOCSIS (DOCSIS) 1.0.

Q. Quel est DOCSIS 1.0+ ?

A. L'implémentation du Data-over-Cable Service Interface Specifications (DOCSIS) 1.0+ est DOCSIS 1.0 avec des extensions de Qualité de service (QoS) pour prendre en charge la Voix en temps réel, la télécopie, et le vidéo sur un RÉSEAU LOCAL. Le DOCSIS 1.0+ n'est pas une nouvelle ou intermédiaire spécification par des laboratoires de câble. L'architecture entière DOCSIS1.0+ est une solution de temps-à-marché fournie par Cisco et certains constructeurs de modem câble jusqu'à ce que les caractéristiques et le développement de DOCSIS 1.1 soient largement - disponibles.

Q. Le DOCSIS 1.0 sont-ils des Modems câble compatibles avec le DOCSIS 1.0+ CMTS ?

A. Oui. Le DOCSIS 1.0+ est entièrement rétrocompatible avec le DOCSIS 1.0. Il est important de se souvenir que tous les services QoS spéciaux du système de terminaison par modem câble de DOCSIS 1.0+ (CMTS) sont seulement lancés quand un modem câble de DOCSIS 1.0+ (cm) sollicite ces services par l'intermédiaire de nouveaux messages dynamiques de Contrôle d'accès au support (MAC). Si votre cm est DOCSIS 1.0 pur, il ne pourra pas lancer ces services et obtiendra le traitement régulier de DOCSIS 1.0 du DOCSIS 1.0+ CMTS.

Q. Quelles sont les extensions privées de QoS ?

A. Le DOCSIS 1.0+ fournit les caractéristiques supplémentaires de QoS pour la Voix en temps réel, la télécopie, et les paquets de données des Modems câble intégrés de téléphonie (ITCMs). Dans le DOCSIS 1.0+, les extensions privées ajoutées au DOCSIS 1.0 sont :

  • Deux nouveaux messages dynamiques Cm-initiés de MAC : Ajout dynamique de service (DSA) et suppression dynamique de service (DSD). Ces messages permettent les id dynamiques de service (SID) à créer ou être supprimés au délai d'exécution sur une base de par-appel.

  • Service non sollicité de Grant (débit binaire constant [CBR] - programmant) sur l'en amont. Ceci fournit le canal de haute qualité de QoS pour les paquets en amont de Voix et de télécopie de CBR de l'ITCM.

  • Pour tout ITCM donné, capacité de fournir les débits en aval distincts basés sur la valeur de priorité IP dans le paquet. Ceci aide la Voix, la signalisation, et le trafic de données distincts allant au même ITCM pour le formation débit-.

Q. Comment l'architecture de DOCSIS 1.0+ fonctionne-t-elle ?

A. Prenons un exemple où M.X d'abonné a joint votre service et veut le module de service suivant :

  • Un service de données avec du débit maximal de l'en amont (US) 128 Kbps, Mbits/s maximal du débit 2 du signal numérique (DS)

  • Deux lignes téléphoniques virtuelles

Voici les étapes à suivre :

  1. Le système de ravitaillement prépare un fichier de configuration pour l'abonné ITCM utilisant n'importe quel éditeur disponible immédiatement de fichier de configuration de style de DOCSIS 1.0. Le fichier de configuration contient :

    • Une configuration de la classe de service régulière de style de DOCSIS 1.0 pour le service de données avec du débit des USA 128 Kbps, Mbits/s maximal du débit 2 DS.

    • Un codage de constructeur-particularité appelé le « nombre de lignes téléphoniques », positionnement à 2.

    • Un codage de constructeur-particularité a appelé « par tuple de raté limit de Priorité IP », qui fixe les ratés limits en aval pour des paquets IP de priorité spéciale.

  2. L'ITCM télécharge ce fichier de configuration au moment de l'enregistrement, et envoie les informations de ravitaillement au DOCSIS 1.0+ CMTS.

  3. Quand 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 assigné à l'ITCM pour le service de données. Pour le service de ligne téléphonique, le CMTS crée seulement deux écoulements reportés de service (pour le lancement ultérieur) dans l'entrée de la base de données de l'ITCM. Aucun SID n'est assigné pour le service de ligne téléphonique pendant l'enregistrement.

  4. Toutes les fois qu'un ITCM veut obtenir une Voix ou faxer le canal avec le service CBR en temps réel, lui envoie un message de MAC DSA-REQ au CMTS, spécifiant ses conditions requises de établissement du programme de CBR spécial telles que la concession-taille et le concession-intervalle (la concession-taille et le concession-intervalle dépendent du type G.711/G.729 de codeur-décodeur (CODEC) étant utilisé sur l'ITCM). Pour plus d'informations sur des types de CODECS, voir l'uBR7200 de Cisco - des améliorations QoS/MAC pour la Voix et faxez les appels : DOCSIS 1.0+.

  5. Quand CMTS reçoit le DSA-REQ, il signe d'abord l'entrée de la base de données de cet ITCM pour voir si n'importe quel écoulement reporté de service est disponible. Si un écoulement reporté de service est disponible, le CMTS assigne à un nouveau SID dynamique pour cela ITCM et déclencheurs les concessions que non sollicitées (emplacements pour CBR) sur celle ont nouvellement assigné le SID dynamique. Le CMTS informe l'ITCM du SID dynamique nouvellement assigné utilisant le DSA-RSP.

  6. Étant donné que le CMTS peut faciliter la nouvelle connexion de CBR, cet ITCM continue à obtenir des concessions non sollicitées du paquet correct de taille assez (pour adapter la Voix et la télécopie périodiques) à intervalles périodiques corrects. L'ITCM ne doit pas ne faire face à aucun autre cm sur l'en amont pour envoyer ces paquets en temps réel. Il a un sous-canal dédié du multiplexage temporel (TDM) sur l'en amont sous forme de concessions non sollicitées. Le jitter est bien lié ou limité (vous n'obtiendrez pas de grandes différences de retard entre les paquets), et la bonne qualité vocale est ainsi mise à jour sur le chemin ascendant d'ITCM à l'uBR7200.

    L'ITCM colore les bits de priorité dans l'en-tête IP de ces paquets vocaux avec la valeur de prédéfinis de 0x05 pour propager l'accès local préférentiel QoS dans le circuit principal IP.

    Quand les paquets vocaux arrivent au CMTS dans les emplacements pour CBR, ils sont commutés dans le WAN (nuage IP), ou expédiés à quelque autre ITCM sur le canal descendant.

    S'ils sont commutés dans le nuage BLÊME, vous devez configurer les Routeurs de circuit principal, tels que le routeur de commutateur de gigabit (GSR), identifier et donner le traitement préférentiel pour ces paquets de transport de Voix (valeur 0x05 de priorité) par rapport à la signalisation ou paquets de données de meilleur effort de militaire de carrière avec la priorité 0x3 et 0x0, respectivement.

    Si les paquets en amont sont commutés au canal descendant du même uBR7200, les paquets vocaux 0x05 sont manipulés séparément pour la limitation de débit par rapport aux paquets de données de signalisation basés sur leurs valeurs de priorité.

    Même si au moment de l'appel, la destination ITCM faisait un grand transfert de fichiers en aval, les paquets vocaux expédiés lui sur le même en aval sera inchangée par Protocole FTP (File Transfer Protocol) sur le même ITCM dû à l'utilisation des valeurs de Priorité IP en faisant la comptabilité en aval de bande passante.

  7. Quand l'appel est de finition, l'ITCM envoie un DSD-REQ au CMTS pour libérer le SID dynamique. Le CMTS arrête les concessions de CBR, détruit le SID dynamique indiqué dans DSD-REQ, libère un écoulement reporté pour l'ITCM, et envoie un DSD-RSP à l'ITCM confirmant qu'il a fait ainsi.

Q. Comment nous assurons-nous que un abonné ITCM provisioned pour deux lignes téléphoniques virtuelles obtient seulement jusqu'à deux le CBR dynamique de haute qualité QoS SID au délai d'exécution ?

A. Chaque fois que l'ITCM envoie un DSA-REQ demandant un nouveau SID dynamique, le CMTS vérifie d'abord pour voir si cet ITCM a n'importe quels écoulements reportés inutilisés de service disponibles avant de créer un nouveau SID dynamique. Si l'ITCM utilise déjà deux SID dynamiques, chacun des deux ses écoulements reportés de service affichent comme normalement utilisé à CMTS. Tant que un SID dynamique utilise l'écoulement de service, l'écoulement de service est indisponible pour la création de tous les nouveaux SID dynamiques de cet ITCM.

Q. Est-ce que je dois provision séparément la Voix et faxer des lignes ?

A. Non. Le concept virtuel de ligne téléphonique est très semblable à une vraie ligne téléphonique. Vous pouvez d'une manière transparente employer chacune de ses lignes téléphoniques virtuelles N pour envoyer une télécopie ou la communication voix. Le DOCSIS 1.0+ CMTS n'impose pas quel type de trafic de l'application est envoyé par l'ITCM dans les concessions non sollicitées (emplacements pour CBR) de son SID dynamique.

Q. Y a-t-il de la fragmentation dans le DOCSIS 1.0+ ?

A. Non. Cependant, le DOCSIS 1.0+ CMTS peut encore fournir le bon service CBR en temps réel puisque l'absence de la fragmentation entraîne quelques msecs du jitter supplémentaire pour les emplacements pour CBR (qui est dans la conception typique VoIP économise pour des liens d'accès local). En outre, le DOCSIS 1.0+ n'a pas la classification de paquet et la suppression d'en-tête de charge utile, qui slated pour la release de DOCSIS 1.1.

Q. Comment je provision QoS sur le système de DOCSIS 1.0+ ?

A. Afin de cette section, nous supposons qu'un opérateur s'attend à des trois types de paquet de base sur le réseau IP de bout en bout :

  • Paquets IP avec la priorité égale à 0x05 pour la Voix ou le transport de télécopie

  • Paquets IP avec la priorité égale à 0x03 pour la Voix ou la signalisation de télécopie

  • Paquets IP avec la priorité autre que 0x03 ou 0x05 pour des données régulières

Pour que QoS de bout en bout fonctionne, il est important que tous les Noeuds dans le réseau de bout en bout comprennent et honorent la cartographie ci-dessus de Priorité IP. Tous les Noeuds de réseau à partir d'ITCM à l'uBR7200 aux routeurs de circuit principal à la passerelle de jonction (TGW) devront avoir à traduction cohérente de la priorité ci-dessus.

Pour un fichier de configuration de Protocole TFTP (Trivial File Transfer Protocol) ITCM DOCSIS, nous supposons que l'ITCM provisioned avec une classe de données simple de meilleur effort et deux lignes de téléphone VoIP. Une variation immédiate est de provision deux classes de données, une classe de données de meilleur effort pour des paquets de données et des messages de MAC, et une classe de données CIR pour des paquets de signalisation de Voix.

Pour le ravitaillement statique des classes de service de DOCSIS 1.0 pour le service de données régulier, l'ITCM peut être assigné à un ou plusieurs la classe de service statique de DOCSIS 1.0. L'opérateur est libre pour choisir n'importe quelle combinaison des cinq paramètres ci-dessous pour concevoir un service de données fait sur commande pour l'ITCM.

Un codage de classe de service de DOCSIS 1.0 d'échantillon est fourni ci-dessous pour illustrer comment une classe de services typique de données ITCM pourrait apparaître dans le fichier de configuration :

Type Longueur Valeur (sous-type) Longueur Valeur Commentaires
4 28       Configuration de classe de service
    1 1 1 ID 1 de classe
    2 4 2000000 Le débit en aval maximum égale 2 Mbits/s
    3 4 128000 Le débit en amont maximum égale 128 Kbps
    4 1 5 Égaux en amont 5 prioritaires
    5 4 0 Aucun débit en amont minimum
    6 2 1800 Maximum transmettez les égaux de rafale 1800 octets

Pré-provisionnement le nombre de lignes téléphoniques et de ravitaillement les ratés limits de Priorité IP pour l'en aval

Ces deux nouveaux objets ne sont pas une partie de la classe de service régulière de DOCSIS 1.0, et sont encodés ainsi utilisant « les informations spécifiques de constructeur » comme affiché ci-dessous :

Type Longueur Valeur (sous-type) Longueur Valeur Commentaires
43 28       Les informations de spécification de constructeur
    8 3 0x00 0x00 0x00 ID de constructeur de Cisco

Valeur spécifique 43:8:X de longueur de sous-type de constructeur de Cisco

Type Longueur Valeur (sous-type) Longueur Valeur Commentaires
10 1 2     Deux lignes téléphoniques permises pour l'ITCM
11 18 1 1 0x05 0x00 0x00 priorité de Voix-transport (5)
2 4 128000 Raté limit en aval 128 Kbps pour 0x05
1 1 0x03 priorité de Voix-signalisation (3)
2 4 64000 64 Kbits/s en aval de raté limit pour 0x03

Remarque: Tout le trafic en aval (sauf Priorité IP 0x05 et 0x03) sera en forme de débit ensemble au raté limit en aval par défaut de 2 Mbits/s provisioned dans la classe de service de données de DOCSIS 1.0 d'ITCMs.

Q. Est-ce que j'ai besoin d'un éditeur de fichier de configuration spéciale pour provision des extensions de DOCSIS 1.0+ ?

A. Non. N'importe quel éditeur régulier de fichier de configuration de DOCSIS 1.0 avec le soutien des champs de constructeur-particularité réalisera le travail.

Q. Y a-t-il de autres questions sur l'ensemble du réseau de configuration qui doivent être prises en considération dans l'environnement de DOCSIS 1.0+ ?

A. Oui. Les configurations de Priorité IP utilisées pour séparer la Voix et signaler des données doivent être connues et comprises. En cas d'appel où un point final est en dehors du réseau câblé, il est de la responsabilité du réseau de « extérieur » de s'assurer que tous les paquets vocaux sont colorés convenablement avant de les expédier à l'uBR7200. En cas d'appel où les deux points finaux sont sur le réseau câblé, il est de la responsabilité du point final (ITCM) lançant le trafic pour colorer les paquets vocaux avant de les lancer dans le réseau.

Q. Y a-t-il une configuration optimale sur l'uBR7200 pour maximiser le nombre d'appels VoIP pour chaque port ascendant ?

A. Oui. Cette section montre les paramètres de couche physique témoin qui pourraient être utilisés sur le CMTS pour des canaux ascendants prévus pour avoir la densité d'appel de la haute VoIP. Essai de ces paramètres pour réduire le temps système de couche physique produit pour chaque paquet vocal à taille fixe (de 89 octets). Le réglage fin en résultant donne une amélioration directe dans le nombre de connexions vocales de CBR qui peuvent être admises sur un canal ascendant simple. Les configurations suivantes doivent être configurées pour que le canal ascendant maximise le nombre de connexions de 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 codeword

Pour configurer le profil ci-dessus de modulation au CMTS, utilisez le CLI existant comme suit :

  1. Créez un nouveau modèle de profil de modulation de qpsk (m) avec tous les paramètres par défaut excepté le profil « de concession courte » qui a des paramètres spéciaux comme donné 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 uw8
    
  2. Configurez le port ascendant (n) sur une interface donnée pour utiliser la taille du mini emplacement de 8 coutils et au-dessus du modèle de profil de modulation (m) :

    cmts(config-if)#cable upstream n minislot-size 8
    cmts(config-if)#cable upstream n modulation-profile m
    
    

Q. Quelle version logicielle de Cisco IOS prend en charge le DOCSIS 1.0+ ?

A. La version de logiciel 12.1(01)T de ½ du ¿  de Cisco IOSï prend en charge le DOCSIS 1.0+ sur l'uBR7200 de Cisco et l'uBR924. La version de logiciel 12.07XR de Cisco IOS fournira les images IOS pour l'uBR7200 de Cisco et l'uBR924.

Q. Quel est le plan de migration pour le DOCSIS 1.0+ et le DOCSIS 1.1 ?

A. Actuellement, le DOCSIS 1.1 CMTS slated pour la version logicielle 12.(1)5EC de Cisco IOS. Jusqu'à ce temps, le DOCSIS 1.0+ est la solution de temps-à-marché pour la Voix en temps réel et la télécopie au-dessus de fibre-coaxial hybride (HFC). On s'attend à ce que le transfert du DOCSIS 1.0+ au DOCSIS 1.1 soit une mise à niveau de logiciel.

Le ravitaillement de DOCSIS 1.1 exige un nouvel éditeur de fichier de configuration, et prend en charge toutes les caractéristiques de DOCSIS 1.0+ en plus de plusieurs caractéristiques avancées de QoS. L'uBR7200 de Cisco approuve pleinement des caractéristiques de DOCSIS 1.1.

Q. Qui est-je responsable de la spécification DOCSIS, et où peut trouver les caractéristiques ?

A. CableLabsleavingcisco.com , non une organisation de profit des opérateurs du système de la télévision via câble qui représentent le Nord et l'Amérique du Sud, est responsable de la création de la spécification DOCSIS.

Vous pouvez trouver les caractéristiques ici :

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 a les paramètres pour que les Modems câble soient livré en ligne dans l'accord à ce que l'ISP provisions, comme les débits de réception et d'émission maximum, le débit de rafale d'émission maximale, le Classe de service (Cos) ou la sécurisation de base, le MIB, et beaucoup d'autres paramètres. Vous pouvez établir ce fichier avec le configurateur CPE de Cisco DOCSIS (clients enregistrés seulement) ou avec plusieurs autres outils sur l'Internet. Pour apprendre comment établir un fichier de configuration DOCSIS, référez-vous aux fichiers de configuration de DOCSIS 1.0 de bâtiment utilisant le Configurateur Cisco DOCSIS (clients enregistrés seulement).

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 de Traduction d'adresses de réseau (NAT), et d'autres. Ces configurations peuvent être téléchargées dans le fichier de configuration DOCSIS.

C'est un exemple d'un 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
end

Remarque: Pour les modems câble Cisco qui n'ont pas un port de console (semblable à la gamme Cisco CVA120), il est dans des habitudes très courants d'envoyer la configuration Cisco IOS incluse dans le fichier de configuration DOCSIS.

Q. Queest-ce que les conditions requises de protocole du minimum DOCSIS pour qu'un modem câble soit livré sont-elles en ligne ?

A. Ce sont les conditions requises de protocole du minimum DOCSIS :

  • Serveur d'heure (ToD)

  • Protocole DHCP (DHCP)

  • Trivial File Transfer Protocol (TFTP)

ToD est exigé ; cependant, les laboratoires de câble a apporté quelques modifications qui détendent cette condition. Par conséquent, il est possible que d'autres constructeurs de modem câble seront livré en ligne quoiqu'ils ne passent pas ToD. Si vous faites activer l'interface de sécurisation de base (BPI), le BPI sera une condition requise supplémentaire.

Q. Où peux-je obtenir les modèles de Cisco pour les fichiers de configuration DOCSIS DOCSIS ou BPI bronze.cm, silver.cm, gold.cm, et platinum.cm ?

A. Vous pouvez obtenir les modèles ici :

Ce sont les caractéristiques des modèles :

Fichier DOCSIS cm Vitesse en aval Vitesse en amont Priorité CPEs
bronze.cm 128000 64000 1 1
bronze-bpi.cm
silver.cm 512000 128000 3 1
silver-bpi.cm
gold.cm 2048000 512000 6 1
gold-bpi.cm
platinum.cm 10000000 1024000 7 3
platinum-bpi.cm


Informations connexes


Document ID: 12181