Un protocole est généralement défini comme étant les règles de communication entre deux périphériques. Un protocole de signalisation définit les règles de communication entre deux interfaces ATM qui utilisent des messages de signalisation pour créer des circuits virtuels commutés (SVC) ou à la demande pour transporter des données utilisateur. Les interfaces ATM prennent en charge une pile de protocoles de signalisation comprenant des messages de signalisation « utilisateur » provenant du protocole UNI (User-Network Interface) Q.2931 et une couche d’adaptation ATM de signalisation spéciale (SAAL). Le SAAL est composé du protocole orienté connexion spécifique au service (SSCOP) et de la fonction de coordination spécifique au service (SSCF).
De toute évidence, la signalisation ATM introduit de nombreux acronymes, ce qui, ensemble, peut rendre le protocole SSCOP compliqué lorsqu’il effectue une tâche simple : transporter des messages de signalisation à travers l’interface UNI.
Une compréhension du protocole SSCOP peut être un outil de dépannage clé lors de l’étude de la raison des changements d’état inattendus du client d’émulation de réseau local (LANE). Lorsque de telles modifications se produisent, le routeur imprime les messages ci-dessous dans le journal.
Remarque : Les lignes de sortie ci-dessous apparaissent sur plusieurs lignes en raison de limitations d'espace.
Aug 25 18:32:59.973 MEST: %LANE-5-UPDOWN: ATM0.1 elan default: LE Client changed state to down Aug 25 18:32:59.981 MEST: %LANE-5-UPDOWN: ATM0.39 elan admin: LE Client changed state to down
Ce document fournit une théorie simple sur le protocole SSCOP. Il utilise des tableaux simples pour décrire les unités de données de protocole (PDU) SSCOP, les numéros de séquence et les variables d'état. Il présente ensuite le résultat de la commande debug sscop events pour illustrer comment les unités de données de protocole, les nombres et les variables apparaissent sur les routeurs Cisco.
Remarque : ce document porte principalement sur les routeurs Cisco agissant comme côté utilisateur d'une interface UNI. Ce document ne traite pas de la signalisation NNI (Network-to-Network Interface).
Aucune spécification déterminée n'est requise pour ce document.
Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.
For more information on document conventions, refer to the Cisco Technical Tips Conventions.
ATM est à la fois un protocole et une pile de protocoles. Il est important de considérer l’illustration ci-dessous et de noter comment trois piles de protocoles fonctionnent en parallèle sur une interface ATM prenant en charge la signalisation et la gestion du réseau. Chaque pile de protocoles fournit une fonction différente pour le bon fonctionnement de l'interface.
Plan de contrôle | Plan utilisateur | Plan de gestion | |
---|---|---|---|
Signalisation UNI Q.2931 | Voix, vidéo ou données | Interface de gestion locale intégrée (ILMI) | |
SALAIRE | SSCF | Couche d'adaptation ATM (AAL) | AAL |
SSCOP | |||
Sous-couche de convergence de pièce commune (CPCS) | |||
Couche ATM | |||
Couche physique : hiérarchie numérique SONET/synchrone (SDH), DS3, E3, T1, etc. |
Sur le plan de l'utilisateur, la couche d'adaptation la plus courante est la couche d'adaptation AAL5, qui fournit une queue de bande de 8 octets. La SAAL représente une variante de l'AAL5. Ce qui la différencie est une sous-couche de convergence spécifique au service (SSCS) composée de SSCOP et SSCF. Ce schéma illustre ces couches :
--------------------------------------------- | "User Data" Q.2931 | ------------------------------------------------------- | Service Specific Convergence Sublayer | | | Consists of SSCOP and SSCF | SAAL | --------------------------------------------- Layer | | CPCS | | ------------------------------------------------------- | ATM | --------------------------------------------- | PHY | ---------------------------------------------
Les interfaces ATM transmettent des messages de signalisation hors bande ou hors bande passante de la connexion de données régulière. Ils utilisent une connexion virtuelle permanente dédiée (PVC) configurée avec un type d'encapsulation QSAAL (QSAAL) Q.2931 spécial.
Exécutez la commande pvc vpi/vci sur une interface de routeur ATM pour configurer le circuit virtuel permanent QSAAL.
7500-3.4(config)# interface atm 3/0 7500-3.4(config-if)# pvc 0/5 ? ilmi Configure the management PVC for this interface qsaal Configure the signaling PVC for this interface <cr> 7500-3.4(config-if)# pvc 0/5 qsaal
Les commutateurs ATM Cisco sont préconfigurés avec le circuit virtuel permanent QSAAL sur chaque interface. Exécutez la commande show atm vc interface atm pour confirmer cette configuration par défaut.
ls1010-2# show atm vc interface atm 0/0/2 Interface VPI VCI Type X-Interface X-VPI X-VCI Encap Status ATM0/0/2 0 5 PVC ATM2/0/0 0 45 QSAAL UP ATM0/0/2 0 16 PVC ATM2/0/0 0 37 ILMI UP
Le SCOP est défini dans plusieurs recommandations de l'Union internationale des télécommunications (UIT-T) relatives au secteur de la normalisation des télécommunications. La recommandation Q.2110 fournit les informations les plus pertinentes pour le dépannage des problèmes liés à SSCOP sur les interfaces de routeur ATM.
Q.2100 : définit la structure de SAAL.
Q.2110 : définit SSCOP comme une entité de protocole.
Q.2130 : définit le SSCF pour les interfaces UNI.
Q.2140 : définit le SSCF pour les interfaces NNI.
I.363 : définit le CPCS.
Remarque : les interfaces UNI et NNI utilisent différentes versions de SSCF. NNI n'est pas abordé dans ce document.
SSCOP est un protocole de transport qui fournit une livraison garantie et en séquence des messages aux protocoles de signalisation qui se trouvent au-dessus de celui-ci dans la pile de protocoles de signalisation. SSCOP effectue également un contrôle de flux, des rapports d'erreurs au plan de gestion et une fonction de test d'activité.
Ce tableau décrit les nombreuses fonctions importantes que le protocole SSCOP fournit aux interfaces ATM :
Fonction | Description |
---|---|
Remise en séquence et fiable des messages de signalisation | Les messages de signalisation générés par le protocole Q.2931 UNI constituent les « données utilisateur » dans la pile de signalisation. SSCOP préserve l'ordre de ces messages par des numéros de séquence et une retransmission sélective. Notez que SSCOP ne vérifie pas le contenu des messages de signalisation eux-mêmes. |
Contrôle de flux | Définit des limites sur le débit auquel l’interface ATM homologue envoie des messages SSCOP. |
Rapport d'erreurs | Détecte et signale les erreurs dans le fonctionnement du protocole SSCOP lui-même. |
Keepalive | Échange des messages de POLL à intervalles réguliers pour s'assurer que les deux extrémités et la connexion elle-même restent opérationnelles et actives, en particulier pendant une période où aucun message de signalisation n'est transmis. |
Récupération de données locales | Conserve les statistiques (visibles à l'aide de la commande show sscop) sur les messages de signalisation qui ne sont pas encore « libérés » ou reconnus par l'interface ATM homologue. |
Rapports d'état | Fournit des messages qui communiquent des informations d'état, y compris des informations au plan de gestion. |
Les interfaces ATM UNI utilisent Q.2931 comme protocole de signalisation. SSCOP place les messages Q.2931 à un multiple de 4 octets et ajoute un trailer d'informations spécifiques à SSCOP qui est toujours un multiple de 4 octets.
+------------------------------------------------+ | Q.2931 Signalling Messages | SSCOP Trailer | +---------------------------------------------------------------+ | AAL5 CPCS Service Data Unit (SDU) | AAL5 Trailer | +---------------------------------------------------------------+
Le contenu de la queue de bande SSCOP varie en fonction du type de PDU, décrit dans la section suivante, Messages SSCOP ou PDU. Ce diagramme montre le format de la queue de bande SSCOP pour une unité de données de protocole POLL :
--------------------------------------------------- | Reserved | N(PS) | --------------------------------------------------- | Reserved | PDU Type | N(S) | ---------------------------------------------------
Le protocole SSCOP utilise 15 types de message ou PDU pour remplir ses nombreuses fonctions. La commande show sscop fournit des statistiques sur le nombre de chaque unité de données de protocole envoyée et reçue. Dans cet exemple de sortie, l'interface ATM 3/0 a envoyé et reçu 11 PDU, dont 8 PDU POLL et 1 PDU BEGIN :
7500# show sscop atm 3/0 SSCOP details for interface ATM3/0 Current State = Active, Uni version = 4.0 [output omitted] Statistics - Pdu's Sent = 11, Pdu's Received = 11, Pdu's Ignored = 0 Begin = 1/1, Begin Ack = 1/1, Begin Reject = 0/0 End = 1/0, End Ack = 0/1 Resync = 0/0, Resync Ack = 0/0 Sequenced Data = 0/0, Sequenced Poll Data = 0/0 Poll = 8/8, Stat = 8/8, Unsolicited Stat = 0/0 Unassured Data = 0/0, Mgmt Data = 0/0, Unknown Pdu's = 0 Error Recovery/Ack = 0/0, lack of credit 0
Ce tableau regroupe les messages SSCOP en fonction de la fonction :
Fonction | Abréviation du message | Nom du message | Description |
---|---|---|---|
Établissement de la connexion | BGN | Commencer | Démarre le processus de connexion SSCOP entre deux interfaces ATM. Initialise les tampons homologues et les compteurs de transmission et de réception. |
REVENIR | Commencer l'accusé de réception | Reconnaît la demande de connexion homologue. | |
BGREJ | Commencer le rejet | Rejette la demande de connexion homologue. L’homologue retransmet l’unité de données de protocole BGN et continue d’initier une connexion. | |
Arrêt de la connexion | FIN | Tranche | Libère la connexion entre deux périphériques ATM homologues. |
ENDAK | Accusé de réception de fin | Confirme la demande de publication. | |
Resynchronisation | RS | Resynchronisation | Resynchronise les tampons de messages ainsi que les variables ou compteurs d'état de l'émetteur et du récepteur. |
RSAK | Accusé de réception de resynchronisation | Reconnaît la demande de resynchronisation. | |
Récupération des erreurs | ER | Récupération des erreurs | Récupère les erreurs qui se produisent pendant une connexion active. |
ERAK | Accusé de réception de récupération d'erreur | Reconnaît la demande de récupération d'erreur. | |
Transfert de données garanti | SD | Données séquentielles | Transfère les messages « utilisateur » du protocole de signalisation UNI Q.2931 à l'homologue. |
VOTE | Demande d'état | Demande des informations d'état sur l'homologue. | |
ÉTAT | Réponse d'état sollicité | Représente une réponse à une PDU POLL. Fournit des informations sur la réception réussie des PDU SD, le numéro de séquence de la dernière PDU POLL. Elle contient également une valeur de crédit qui indique le nombre de messages supplémentaires que l'homologue peut ou ne peut pas envoyer avant accusé de réception. | |
USTAT | Réponse d'état non sollicité | Communication des unités de données de protocole perdues ou manquantes qui ont été détectées en analysant les numéros de séquence dans d'autres unités de données de protocole. | |
Transfert de données non garanti | UD | Données non numérotées | Transmet des messages « utilisateur » entre les homologues. N'inclut pas de numéro de séquence et peut être perdu sans notification. |
Transfert de données de gestion | MD | Données de gestion | Transmet les informations de gestion au plan de gestion. N'inclut pas de numéro de séquence et peut être perdu sans notification. |
Remarque : La recommandation UIT-T Q.2110 définit une unité de données de protocole non valide comme une unité de données de protocole dont le code de type de unité de données de protocole est inconnu, qui n'est pas alignée sur 32 bits ou qui n'est pas la longueur appropriée pour une unité de données de protocole de type indiqué.
SSCOP suit une machine à état, dans laquelle le protocole lui-même passe par plusieurs états avant de devenir actif. Ensemble de cinq contrôles temporels (en partie) lorsque SSCOP passe à un autre état. Émettez la commande sscop en mode de configuration d'interface pour afficher ces temporisateurs.
7200(config-if)# sscop ? cc-timer timer (in secs) to send BGN/END/RS/ER pdu at the connection control phase idle-timer timer (in secs) to send poll pdu at the idle phase keepalive-timer timer (in secs) to send poll pdu at the transient phase noResponse-timer timer (in secs) at lease one STAT PDU needs to be received poll-timer timer (in msecs) to send poll pdu at the active phase
Ce tableau décrit les cinq temporisateurs SSCOP :
Minuteur | Description | Valeur par défaut |
---|---|---|
cc-timer | Le contrôle de connexion (cc) est l'ensemble des processus utilisés pour établir, libérer ou resynchroniser une connexion SSCOP entre deux interfaces ATM. Le minuteur cc définit le délai entre les retransmissions des PDU BGN, END ou RS en attendant un accusé de réception. La valeur max-cc définit le nombre de tentatives. | 1 seconde (s) |
compteur d'inactivité | Si la connexion est assez stable et qu'il n'y a aucun message de données à transmettre et aucun accusé de réception en attente, le protocole SSCOP bascule du keepalive du minuteur au ralenti du minuteur. | 10 sec |
keepalive-timer | Contrôle le temps maximal entre la transmission d'une PDU POLL lorsqu'aucune PDU SD n'est mise en file d'attente pour transmission ou est en attente d'accusé de réception. | 5 sec |
noResponse-timer | S'exécute en parallèle avec deux autres minuteurs : sonl et keepalive. Définit l'intervalle de temps maximal pendant lequel au moins un message STAT doit être reçu en réponse à un POLL. Si ce compteur expire, la connexion est arrêtée. | 45 secondes |
poll-timer | Définit le délai maximal entre la transmission d'une unité de données de protocole de POLL lorsque des unités de données de protocole SD sont mises en file d'attente pour transmission ou sont en attente d'accusé de réception. | 1 000 millisecondes (ms) |
Exécutez la commande show sscop atm pour afficher les valeurs par défaut des compteurs SSCOP.
7500# show sscop atm 3/0 SSCOP details for interface ATM3/0 Current State = Idle, Uni version = 4.0 Send Sequence Number: Current = 0, Maximum = 30 Send Sequence Number Acked = 0 Rcv Sequence Number: Lower Edge = 0, Upper Edge = 0, Max = 30 Poll Sequence Number = 0, Poll Ack Sequence Number = 1 Vt(Pd) = 0 Vt(Sq) = 0 Timer_IDLE = 10 - Inactive Timer_CC = 1 - Inactive Timer_POLL = 1000 - Inactive Timer_KEEPALIVE = 5 - Inactive Timer_NO-RESPONSE = 45 - Inactive Current Retry Count = 0, Maximum Retry Count = 10 !--- Output suppressed.
Le processus SSCOP sur une interface ATM suit deux ensembles de numéros de séquence ou de variables d'état, puis mappe ces valeurs dans des champs des unités de données de protocole réelles. Plus précisément, les PDU SD et les PDU POLL sont numérotées de manière séquentielle et indépendante. L’émetteur et le récepteur conservent les numéros de séquence en tant que variables d’état. Ces variables sont ensuite mappées en paramètres ou champs réels dans les PDU SSCOP. La commande show sscop affiche les valeurs actuelles des numéros de séquence.
ATM# show sscop SSCOP details for interface ATM0 Current State = Active, Uni version = 3.1 Send Sequence Number: Current = 79, Maximum = 109 Send Sequence Number Acked = 79 Rcv Sequence Number: Lower Edge = 93, Upper Edge = 93, Max = 123 Poll Sequence Number = 32597, Poll Ack Sequence Number = 32597 Vt(Pd) = 0 Vt(Sq) = 1 Timer_IDLE = 10 - Active !--- Output suppressed.
Les sections suivantes décrivent les variables d'état et les numéros de PDU réels.
Une interface ATM conserve un ensemble de variables d’état de transmission qui commencent par VT.
Variable d'état | Name (nom) | Description |
---|---|---|
VT(S) | Envoyer | Numéro de séquence qui s'incrémente avec chaque unité de données de protocole SD. Ne s'incrémente pas lorsque la même unité de données de protocole SD est retransmise. |
VT(PS) | Envoi du sondage | Numéro de séquence qui s'incrémente avec chaque PDU POLL. |
VT(A) | Reconnaître | Numéro de séquence de l'unité de données de protocole SD qui doit être reconnue ensuite. S'incrémente chaque fois qu'une unité de données de protocole SD est reconnue. |
VT(PA) | Accusé de réception du sondage | Numéro de séquence de la PDU STAT qui doit recevoir le prochain accusé de réception de la PDU POLL. |
VT(MS) | Envoi maximal | Numéro de séquence le plus élevé d’une unité de données de protocole que l’interface émettrice peut envoyer (et que le récepteur acceptera) sans recevoir l’une des unités de données de protocole suivantes : USTAT, STAT, BGN, BGAK, RS, RSAK, ER ou ERAK PDU. En d'autres termes, VT(MS) définit la taille de fenêtre de transmission. VT(S) ne doit pas être supérieur à VT(MS). |
VT(PD) | Données de sondage | Nombre de PDU SD transmises entre deux PDU POLL. S'incrémente lors de la transmission d'une unité de données de protocole SD et se réinitialise à zéro lors de la transmission d'une unité de données de protocole POLL. |
VT(CC) | Contrôle de connexion | Nombre d'unités de données de protocole BGN, END, ER ou RS non reconnues. Si l’interface ATM envoie une unité de données de protocole END en réponse à une erreur de protocole, SSCOP passe directement à l’état inactif et n’incrémente pas la valeur VT(CC). |
VT(SQ) | Séquence de connexion de l'émetteur | Identifie les PDU BGN, ER et RS retransmises. Est initialisé à zéro au démarrage du processus SSCOP, puis mappé en N(SQ). |
Une interface ATM conserve un ensemble de variables d’état de réception commençant par VR.
Variable d'état | Name (nom) | Description |
---|---|---|
VR(R) | Recevoir | Numéro de séquence de la prochaine unité de données de protocole SD dans la séquence que le récepteur attend. Il est incrémenté lorsque ce message est vu. |
VR(H) | Plus élevé attendu | Numéro de séquence le plus élevé attendu dans une unité de données de protocole SD. Mis à jour à partir du prochain message SD ou POLL et doit être à peu près égal au(x) homologue(s) VT(s). |
VR(MR) | Réception maximale | Numéro de séquence le plus élevé dans une unité de données de protocole SD que le récepteur acceptera. En d'autres termes, le récepteur autorise jusqu'à VR(MR) - 1, puis il rejette toute unité de données de protocole SD avec un numéro de séquence plus élevé. La mise à jour de VR(MR) dépend de la mise en oeuvre. |
VR(SQ) | Séquence de connexion du récepteur | Utilisé pour identifier les PDU BGN, ER et RS retransmis. Lorsqu’une interface ATM reçoit une de ces unités de données de protocole, elle compare la valeur N(SQ) à sa propre valeur VR(SQ). Si les deux valeurs sont différentes, la PDU est traitée comme un nouveau message. Si les deux valeurs sont égales, la PDU est identifiée comme une retransmission. |
Les variables d'état de réception et de transmission sont traduites ou mappées en paramètres PDU réels avec des noms légèrement différents. Ce tableau présente les paramètres PDU et la variable d'état à partir de laquelle ils sont dérivés :
Paramètre | Mappé de | Description |
---|---|---|
N(SQ) | VR(SQ) | Numéro de séquence de connexion transporté dans une unité de données de protocole BGN, RS ou ER. Utilisé avec le compteur VR(SQ) au niveau du récepteur pour identifier toute retransmission de ces unités de données de protocole. |
N(S) | VT(S) | Envoyer le numéro de séquence transporté dans chaque unité de données de protocole SD ou POLL et incrémenté avec chaque nouvelle unité de données de protocole non retransmise. |
N(PS) | VT(PS) | Transféré dans une unité de données de protocole de POLL et une unité de données de protocole STAT correspondante pour corréler les deux messages. |
N(R) | VR(R) | Numéro de séquence de réception transporté dans une unité de données de protocole STAT ou USTAT. Envoyé par le périphérique homologue lors de l'accusé de réception d'un ou de plusieurs messages de signalisation. |
N(MR) | VR(MR) | Transporté dans les unités de données de protocole suivantes : STAT, USTAT, RS, RSAK, ER, ERAK, BGN, BGAK. Indique le nombre de crédits de réception restants et si l'homologue peut envoyer un autre message. Par exemple, une valeur N(MR) de 5 signifie que l'homologue peut envoyer jusqu'à 5 PDU sans attendre de réponse. |
Le résultat ci-dessous a été généré en exécutant la commande debug sscop event atm 3/0 sur un routeur de la gamme 7500 avec un PA-A3. Les commentaires en bleu sont utilisés pour interpréter la sortie de débogage.
*Mar 21 03:18:43.440: SSCOP(ATM3/0): i Begin pdu, Idle state, length = 8 *Mar 21 03:18:43.440: SSCOP(ATM3/0): Rcv Begin in Idle State *Mar 21 03:18:43.440: SSCOP(ATM3/0): receive window in Begin Pdu = 30 *Mar 21 03:18:43.440: SSCOP(ATM3/0): o Begin Ack pdu, Idle state, rcv window v(mr) = 30 !--- A BEGIN PDU is received by the router, which responds with a BEGIN ACK PDU. !--- The window size V(MR) is initialized to 30. *Mar 21 03:18:43.440: SSCOP(ATM3/0): state changed from Idle to Active *Mar 21 03:18:47.968: SSCOP(ATM3/0): o Poll pdu, state = Active, n(s) = 0, n(ps) = 1 *Mar 21 03:18:47.968: SSCOP(ATM3/0): i Stat pdu, Active state, length = 12 *Mar 21 03:18:47.968: SSCOP(ATM3/0): Rcv Stat in Active State *Mar 21 03:18:47.968: SSCOP(ATM3/0): processStatPdu: ps 1, nmr 30, nr 0 *Mar 21 03:18:47.968: SSCOP(ATM3/0): processStatPdu: vtPa 1, vps 1 *Mar 21 03:18:47.968: SSCOP(ATM3/0): processStatPdu: vta 0, vts 0 *Mar 21 03:18:47.968: SSCOP(ATM3/0): processStatPdu: listCount = 0 - normal !--- This is the first outbound POLL PDU and inbound STAT PDU. *Mar 21 03:18:48.040: SSCOP(ATM3/0): * Poll pdu, ns = 0, nps = 1 *Mar 21 03:18:48.040: SSCOP(ATM3/0): o Stat pdu, n(r) = 0, n(mr) = 30, n(ps) = 1 !--- The "*" indicates an inbound POLL PDU from the attached ATM switch. !--- The router responds with an outbound STAT PDU. *Mar 21 03:18:57.292: SSCOP(ATM3/0): o Poll pdu, state = Active, n(s) = 0, n(ps) = 2 *Mar 21 03:18:57.292: SSCOP(ATM3/0): i Stat pdu, Active state, length = 12 *Mar 21 03:18:57.292: SSCOP(ATM3/0): Rcv Stat in Active State *Mar 21 03:18:57.292: SSCOP(ATM3/0): processStatPdu: ps 2, nmr 30, nr 0 *Mar 21 03:18:57.292: SSCOP(ATM3/0): processStatPdu: vtPa 1, vps 2 *Mar 21 03:18:57.292: SSCOP(ATM3/0): processStatPdu: vta 0, vts 0 *Mar 21 03:18:57.292: SSCOP(ATM3/0): processStatPdu: listCount = 0 - normal !--- This is the second outbound POLL PDU and inbound STAT PDU. N(PS) and V(PS) !--- increment to 2. *Mar 21 03:18:58.004: SSCOP(ATM3/0): * Poll pdu, ns = 0, nps = 2 *Mar 21 03:18:58.004: SSCOP(ATM3/0): o Stat pdu, n(r) = 0, n(mr) = 30, n(ps) = 2 *Mar 21 03:19:06.812: SSCOP(ATM3/0): o Poll pdu, state = Active, n(s) = 0, n(ps) = 3 *Mar 21 03:19:06.812: SSCOP(ATM3/0): i Stat pdu, Active state, length = 12 *Mar 21 03:19:06.812: SSCOP(ATM3/0): Rcv Stat in Active State *Mar 21 03:19:06.812: SSCOP(ATM3/0): processStatPdu: ps 3, nmr 30, nr 0 *Mar 21 03:19:06.812: SSCOP(ATM3/0): processStatPdu: vtPa 2, vps 3 *Mar 21 03:19:06.812: SSCOP(ATM3/0): processStatPdu: vta 0, vts 0 *Mar 21 03:19:06.812: SSCOP(ATM3/0): processStatPdu: listCount = 0 - normal *Mar 21 03:19:07.228: SSCOP(ATM3/0): * Poll pdu, ns = 0, nps = 3 *Mar 21 03:19:07.228: SSCOP(ATM3/0): o Stat pdu, n(r) = 0, n(mr) = 30, n(ps) = 3 !--- This is the third outbound POLL PDU and inbound STAT PDU. N(PS) and V(PS) !--- increment to 3. N(MR) remains at 30. N(S), VT(S), and VT(A) remain at 0 since !--- no sequenced Q.2931 "user" data is being transmitted.
La sortie de débogage capture les messages SSCOP envoyés lors de l'établissement de la connexion et dans le cadre du mécanisme de keepalive. Une capture simultanée de la commande show sscop atm alors que les commandes debug étaient en cours d'exécution montre l'incrémentation des valeurs pour Pdu's Sent et Pdu's Received, ainsi que pour Poll et Stat.
7500# show sscop atm 3/0 SSCOP details for interface ATM3/0 Current State = Active, Uni version = 4.0 Send Sequence Number: Current = 0, Maximum = 30 Send Sequence Number Acked = 0 Rcv Sequence Number: Lower Edge = 0, Upper Edge = 0, Max = 30 Poll Sequence Number = 6, Poll Ack Sequence Number = 6 Vt(Pd) = 0 Vt(Sq) = 1 Timer_IDLE = 10 - Active Timer_CC = 1 - Inactive Timer_POLL = 1000 - Inactive Timer_KEEPALIVE = 5 - Inactive Timer_NO-RESPONSE = 45 - Inactive Current Retry Count = 0, Maximum Retry Count = 10 AckQ count = 0, RcvQ count = 0, TxQ count = 0 AckQ HWM = 0, RcvQ HWM = 0, TxQ HWM = 0 Local connections currently pending = 0 Max local connections allowed pending = 0 Statistics - Pdu's Sent = 9, Pdu's Received = 9, Pdu's Ignored = 0 Begin = 1/1, Begin Ack = 1/1, Begin Reject = 0/0 End = 1/0, End Ack = 0/1 Resync = 0/0, Resync Ack = 0/0 Sequenced Data = 0/0, Sequenced Poll Data = 0/0 Poll = 6/6, Stat = 6/6, Unsolicited Stat = 0/0 Unassured Data = 0/0, Mgmt Data = 0/0, Unknown Pdu's = 0 Error Recovery/Ack = 0/0, lack of credit 0 7500# show sscop atm 3/0 SSCOP details for interface ATM3/0 Current State = Active, Uni version = 4.0 Send Sequence Number: Current = 0, Maximum = 30 Send Sequence Number Acked = 0 Rcv Sequence Number: Lower Edge = 0, Upper Edge = 0, Max = 30 Poll Sequence Number = 7, Poll Ack Sequence Number = 7 Vt(Pd) = 0 Vt(Sq) = 1 Timer_IDLE = 10 - Active Timer_CC = 1 - Inactive Timer_POLL = 1000 - Inactive Timer_KEEPALIVE = 5 - Inactive Timer_NO-RESPONSE = 45 - Inactive Current Retry Count = 0, Maximum Retry Count = 10 AckQ count = 0, RcvQ count = 0, TxQ count = 0 AckQ HWM = 0, RcvQ HWM = 0, TxQ HWM = 0 Local connections currently pending = 0 Max local connections allowed pending = 0 Statistics - Pdu's Sent = 10, Pdu's Received = 10, Pdu's Ignored = 0 Begin = 1/1, Begin Ack = 1/1, Begin Reject = 0/0 End = 1/0, End Ack = 0/1 Resync = 0/0, Resync Ack = 0/0 Sequenced Data = 0/0, Sequenced Poll Data = 0/0 Poll = 7/7, Stat = 7/7, Unsolicited Stat = 0/0 Unassured Data = 0/0, Mgmt Data = 0/0, Unknown Pdu's = 0 Error Recovery/Ack = 0/0, lack of credit 0