Inhalt

Einführung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Konventionen

QSAAL Protocol Stack

Was ist SSCOP?

Erläuterungen zum SSCOP-Trailer

SSCOP-Nachrichten oder PDUs

SSCOP-Timer

SSCOP-Sequenznummern

Beispielausgabe für Debugging

Zugehörige Informationen

Einführung

Ein Protokoll wird im Allgemeinen als Regeln für die Kommunikation zwischen zwei Geräten definiert. Ein Signalisierungsprotokoll definiert die Kommunikationsregeln zwischen zwei ATM-Schnittstellen, die Signalisierungsnachrichten zum Erstellen von On-Demand- oder Switched Virtual Circuits (SVCs) verwenden, um Benutzerdaten zu übertragen. ATM-Schnittstellen unterstützen einen Signalisierungsprotokollstapel, der "Benutzer"-Signalisierungsnachrichten aus dem Protokoll User-Network Interface (UNI) Q.2931 und eine spezielle Signaling ATM Adaptive Layer (SAAL) umfasst. Das SAAL besteht aus dem Service-Specific Connection-Oriented Protocol (SSCOP) und der Service-Specific Koordination Function (SSCF).

Offensichtlich führt die ATM-Signalisierung viele Akronyme ein, die zusammen SSCOP kompliziert erscheinen lassen, wenn es wirklich eine einfache Aufgabe ausführt - die Übertragung von Signalisierungsnachrichten über die UNI hinweg.

Ein Verständnis von SSCOP kann ein wichtiges Tool zur Fehlerbehebung sein, wenn der Grund für unerwartete LAN Emulation (LANE)-Clientstatusänderungen untersucht wird. Wenn solche Änderungen auftreten, druckt der Router die folgenden Meldungen in das Protokoll aus.

Hinweis: Die folgenden Ausgabezeilen erscheinen aufgrund von Platzbeschränkungen auf mehreren Zeilen.

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

Dieses Dokument enthält eine einfache Theorie zu SSCOP. Er verwendet einfache Tabellen, um SSCOP-Protokolldateneinheiten (Protocol Data Units, PDUs), Sequenznummern und Statusvariablen zu beschreiben. Anschließend wird die Ausgabe des Befehls debug sscop events dargestellt, um zu veranschaulichen, wie die PDUs, Zahlen und Variablen auf den Cisco Routern angezeigt werden.

Hinweis: Der Schwerpunkt dieses Dokuments liegt auf Cisco Routern, die als Benutzerseite einer UNI fungieren. In diesem Dokument wird die NNI-Signalisierung (Network-to-Network Interface) nicht behandelt.

Voraussetzungen

Anforderungen

Für dieses Dokument bestehen keine speziellen Anforderungen.

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardwareversionen beschränkt.

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie in den Cisco Technical Tips Conventions.

QSAAL Protocol Stack

ATM ist sowohl ein Protokoll- als auch ein Protokollstapel. Es ist wichtig, die folgende Abbildung zu berücksichtigen und zu beachten, wie drei Protokoll-Stacks parallel auf einer ATM-Schnittstelle arbeiten, die Signalisierung und Netzwerkmanagement unterstützt. Jeder Protokoll-Stack bietet eine andere Funktion als der erfolgreiche Betrieb der Schnittstelle.

Kontrollebene

Benutzerebene

Managementebene

Q.2931 UNI-Signalisierung

Sprache, Video oder Daten

Integrierte Local Management Interface (ILMI)

SAAL

SSCF

ATM-Adapterschicht (AAL)

AAL

SSCOP

Common Part Convergence Sublayer (CPCS)

ATM-Schicht

Physical Layer - SONET/Synchronous Digital Hierarchy (SDH), DS3, E3, T1 usw.

Auf der Benutzerebene ist AAL5 die häufigste Variante, die einen 8-Byte-Trailer bereitstellt. Die SAAL stellt eine Variante von AAL5 dar. Der Unterschied besteht in einer servicespezifischen Konvergenz-Subschicht (SSCS), die aus SSCOP und SSCF besteht. Dieses Diagramm zeigt diese Ebenen:

---------------------------------------------

|              "User Data" Q.2931           |

-------------------------------------------------------

|   Service Specific Convergence Sublayer   |         |

|        Consists of SSCOP and SSCF         |   SAAL  |

---------------------------------------------  Layer  |

|                     CPCS                  |         |

-------------------------------------------------------

|                     ATM                   |

---------------------------------------------

|                     PHY                   |

---------------------------------------------

ATM-Schnittstellen übertragen Signalisierungsnachrichten "Out-of-Band" oder außerhalb der Bandbreite der regulären Datenverbindung. Sie verwenden eine dedizierte permanente virtuelle Verbindung (PVC), die mit einem speziellen Kapselungstyp Q.2931 SAAL (QSAAL) konfiguriert ist.

Geben Sie den Befehl pvc vpi/vci auf einer ATM-Router-Schnittstelle ein, um QSAAL PVC zu konfigurieren.

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

Cisco ATM-Switches sind für jede Schnittstelle mit QSAAL PVC vorkonfiguriert. Geben Sie den Befehl show atm vc interface atm ein, um diese Standardkonfiguration zu bestätigen.

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

SSCOP ist in mehreren Empfehlungen der International Telecommunication Union Telecommunication Standardization Sector (ITU-T) definiert. Die Q.2110-Empfehlung enthält Informationen, die für die Behebung von SSCOP-bezogenen Problemen an ATM-Routerschnittstellen am relevantesten sind.

- Q.2100 : Definiert die Struktur von SAAL.

- Q.2110 : Definiert SSCOP als Protokolleinheit.

- Q.2130 : Definiert das SSCF für UNI-Schnittstellen.

- Q.2140 : Definiert das SSCF für NNI-Schnittstellen.

- I.363 : Definiert das CPCS.

Hinweis: UNI- und NNI-Schnittstellen verwenden unterschiedliche Versionen von SSCF. NNI wird in diesem Dokument nicht behandelt.

Was ist SSCOP?

SSCOP ist ein Transportprotokoll, das die garantierte sequenzweise Übermittlung von Nachrichten an die Signalisierungsprotokolle ermöglicht, die sich darüber im Signalisierungsprotokollstapel befinden. SSCOP führt außerdem eine Flusskontrolle, Fehlerberichte an die Verwaltungsebene und eine Keepalive-Funktion durch.

In dieser Tabelle werden die vielen wichtigen Funktionen beschrieben, die SSCOP für ATM-Schnittstellen bietet:

Funktion

Beschreibung

sequenzielle und zuverlässige Bereitstellung von Signalisierungsnachrichten

Die vom UNI Q.2931-Protokoll generierten Signalisierungsmeldungen stellen die "Benutzerdaten" im Signalisierungs-Stack dar. SSCOP behält die Reihenfolge dieser Nachrichten durch Sequenznummern und eine selektive erneute Übertragung bei. Beachten Sie, dass SSCOP den Inhalt der Signalisierungsnachrichten nicht selbst überprüft.

Flusssteuerung

Legt Beschränkungen für die Geschwindigkeit fest, mit der die Peer-ATM-Schnittstelle SSCOP-Nachrichten sendet.

Fehlerberichte

Erkennt und meldet Fehler im Betrieb von SSCOP selbst.

Keepalive

Tauscht in regelmäßigen Abständen POLL-Nachrichten aus, um sicherzustellen, dass beide Enden und die Verbindung selbst betriebsbereit und aktiv bleiben, insbesondere während eines Zeitraums, in dem keine Signalisierungsnachrichten übertragen werden.

Lokaler Datenabruf

Führt Statistiken (sichtbar mit dem Befehl show sscop) über Signalisierungsnachrichten, die noch nicht "freigegeben" oder von der Peer-ATM-Schnittstelle bestätigt wurden.

Statusberichte

Stellt Meldungen bereit, die Statusinformationen einschließlich Informationen an die Verwaltungsebene weiterleiten.

Erläuterungen zum SSCOP-Trailer

ATM UNI-Schnittstellen verwenden Q.2931 als Signalisierungsprotokoll. SSCOP pads die Q.2931-Nachrichten auf ein Vielfaches von 4 Byte und fügt einen Trailer mit SSCOP-spezifischen Informationen an, der immer ein Vielfaches von 4 Byte ist.

+------------------------------------------------+

|  Q.2931 Signalling Messages    | SSCOP Trailer |

+---------------------------------------------------------------+

|       AAL5 CPCS Service Data Unit (SDU)        | AAL5 Trailer |

+---------------------------------------------------------------+

Der Inhalt des SSCOP-Trailer variiert je nach PDU-Typ, der im nächsten Abschnitt beschrieben wird: SSCOP-Nachrichten oder PDUs. Dieses Diagramm zeigt das Format des SSCOP-Trailers für eine POLL PDU:

---------------------------------------------------

| Reserved |                 N(PS)                |

---------------------------------------------------

| Reserved | PDU Type |           N(S)            |

---------------------------------------------------

SSCOP-Nachrichten oder PDUs

SSCOP verwendet 15 Meldungstypen bzw. PDUs, um die zahlreichen Funktionen auszuführen. Der Befehl show sscop enthält Statistiken zur Anzahl der gesendeten und empfangenen PDUs. In dieser Beispielausgabe hat die ATM-Schnittstelle 3/0 11 PDUs gesendet und empfangen, darunter 8 POLL PDUs und 1 BEGIN PDU:

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

In dieser Tabelle werden die SSCOP-Meldungen nach der Funktion gruppiert:

Funktion

Abkürzung

Name der Nachricht

Beschreibung

Verbindungsherstellung

BGN

Starten

Startet den SSCOP-Verbindungsprozess zwischen zwei ATM-Schnittstellen. Initialisiert die Peer-Puffer sowie die Übertragungs- und Empfangszähler.

RÜCKEN

Bestätigung beginnen

Bestätigt die Peer-Verbindungsanforderung.

GRÜN

Ablehnen beginnen

Lehnt die Peer-Verbindungsanforderung ab. Der Peer überträgt die BGN PDU erneut und initiiert weiterhin eine Verbindung.

Verbindungstrennung

ENDE

Ende

Stellt die Verbindung zwischen zwei Peer-ATM-Geräten frei.

ENDAK

Bestätigung beenden

Bestätigt die Freigabeanforderung.

Resynchronisierung

RS

Resynchronisierung

Synchronisiert Nachrichtenpuffer sowie die Sender- und Empfängerzustandsvariablen oder Zähler neu.

RSAK

Bestätigung der Resynchronisierung

Bestätigt die Resynchronisierungsanfrage.

Fehlerbehebung

ER

Fehlerbehebung

Fehlerbehebungen, die während einer aktiven Verbindung auftreten.

FEHLER

Fehlerbehebungsbestätigung

Bestätigt die Wiederherstellungsanfrage für Fehler.

Sichere Datenübertragung

SD

Sequenzierte Daten

Überträgt "Benutzer"-Nachrichten vom UNI Q.2931-Signalisierungsprotokoll an den Peer.

POLEN

Statusanfrage

Fordert Statusinformationen über den Peer an.

START

Gesuchte Status-Antwort

Stellt eine Antwort auf eine POLL PDU dar. Enthält Informationen zum erfolgreichen Empfang von SD-PDUs, die Sequenznummer der letzten POLL PDUs. Er enthält außerdem einen Bonitätswert, der angibt, wie viele Nachrichten der Peer vor der Bestätigung senden kann oder kann.

NUTZEN

Unerwünschte Status-Antwort

Übermittelt verlorene oder fehlende PDUs, die erkannt wurden, indem die Sequenznummern in anderen PDUs analysiert werden.

Unzugesicherte Datenübertragung

UD

Nicht nummerierte Daten

Sendet "Benutzernachrichten" zwischen den Peers. Enthält keine Sequenznummer und kann ohne Benachrichtigung verloren gehen.

Management-Datenübertragung

MD

Managementdaten

Sendet Managementinformationen an die Verwaltungsebene. Enthält keine Sequenznummer und kann ohne Benachrichtigung verloren gehen.

Hinweis: Die ITU-T Q.2110-Empfehlung definiert eine ungültige PDU als PDU, die einen unbekannten PDU-Typcode hat, nicht 32-Bit abgestimmt ist oder nicht die richtige Länge für eine PDU des angegebenen Typs ist.

SSCOP-Timer

SSCOP folgt einem Statuscomputer, in dem das Protokoll selbst mehrere Zustände durchläuft, bevor es aktiv wird. Ein Satz von fünf Timern steuert (teilweise), wenn SSCOP in einen anderen Zustand wechselt. Geben Sie den Befehl sscop im Schnittstellenkonfigurationsmodus aus, um diese Timer anzuzeigen.

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

In dieser Tabelle werden die fünf SSCOP-Timer beschrieben:

Timer

Beschreibung

Standardwert

cc-timer

Die Verbindungssteuerung (Connection Control, cc) ist der Satz von Prozessen, mit denen eine SSCOP-Verbindung zwischen zwei ATM-Schnittstellen eingerichtet, freigegeben oder re-synchronisiert wird. Der cc-Timer legt die Zeit zwischen der erneuten Übertragung von BGN-, END- oder RS PDUs während des Wartens auf eine Bestätigung fest. Der max-cc-Wert legt die Anzahl der Wiederholungen fest.

1 Sekunde (Sek.)

Leerlaufzeitgeber

Wenn die Verbindung stabil genug ist und keine Datenmeldungen zu übertragen sind und keine ausstehenden Bestätigungen vorhanden sind, schaltet SSCOP vom Timer-Keepalive zum Timer Inaktivität um.

10 Sek.

Keepalive-Timer

Steuert die maximale Zeit zwischen der Übertragung einer POLL PDU, wenn keine SD-PDUs für die Übertragung in die Warteschlange gestellt werden oder ausstehende Bestätigung aussteht.

5 Sek.

noResponse-Timer

Läuft parallel mit zwei anderen Timern, Polling und Keepalive. Legt das maximale Zeitintervall fest, in dem mindestens eine STAT-Nachricht als Reaktion auf einen POLL empfangen werden muss. Wenn dieser Timer abläuft, wird die Verbindung abgebrochen.

45 s

Zeitgeber

Legt die maximale Zeit zwischen der Übertragung einer POLL PDU fest, wenn SD-PDUs in die Warteschlange für die Übertragung gestellt werden oder ausstehende Bestätigung ausstehen.

1000 Millisekunden

Geben Sie den Befehl show sscop atm ein, um die Standardwerte der SSCOP-Timer anzuzeigen.

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.

SSCOP-Sequenznummern

Der SSCOP-Prozess auf einer ATM-Schnittstelle verfolgt zwei Gruppen von Sequenznummern oder Statusvariablen und ordnet diese Werte dann den Feldern in den tatsächlichen PDUs zu. Insbesondere SD-PDUs und POLL-PDUs sind sequenziell und unabhängig nummeriert. Der Sender und der Empfänger behalten die Sequenznummern als Statusvariablen bei. Diese Variablen werden dann den tatsächlichen Parametern oder Feldern in den SSCOP PDUs zugeordnet. Der Befehl show sscop zeigt die aktuellen Werte der Sequenznummern an.

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.

In den folgenden Abschnitten werden die Zustandsvariablen und die tatsächlichen PDU-Nummern beschrieben.

Zustandsvariablen am Sender

Eine ATM-Schnittstelle behält eine Reihe von Transmit-Side-Statusvariablen bei, die mit VT beginnen.

Statusvariable

Name

Beschreibung

VT(s)

Senden

Sequenznummer, die mit jeder SD-PDU erhöht wird. Erhöht nicht, wenn dieselbe SD-PDU erneut übertragen wird.

VT (PS)

Umfrage senden

Sequenznummer, die mit jeder POLL-PDU erhöht wird.

VT(A)

Bestätigen

Sequenznummer der SD-PDU, die als Nächstes bestätigt werden soll. Erhöht jedes Mal, wenn eine SD-PDU bestätigt wird.

VT (PA)

Bestätigung der Umfrage

Sequenznummer der STAT PDU, die als Nächstes als Bestätigung der POLL PDU empfangen wird.

VT (MS)

Maximales Senden

Höchste Sequenznummer einer PDU, die die Sendeschnittstelle senden kann (und der Empfänger akzeptiert), ohne dass eine der folgenden PDUs empfangen wird: USTAT, STAT, BGN, BGAK, RS, RSAK, ER oder ERAK PDU. Mit anderen Worten: VT(MS) definiert die Größe des Sendefensters. VT(S) darf nicht größer als VT(MS) sein.

VT (PD)

Umfragedaten

Anzahl der SD-PDUs, die zwischen zwei POLL-PDUs übertragen werden Erhöhungen bei Übertragung einer SD PDU und Reset auf Null bei Übertragung einer POLL PDU.

VT (CC)

Verbindungssteuerung

Anzahl der nicht bestätigten BGN-, END-, ER- oder RS-PDUs Wenn die ATM-Schnittstelle als Reaktion auf einen Protokollfehler eine END-PDU sendet, wechselt SSCOP direkt in den Leerlaufzustand und erhöht nicht den VT(CC)-Wert.

VT (SQ)

Verbindungssequenz des Transmitters

Identifiziert neu übertragene BGN-, ER- und RS-PDUs. Ist beim Starten des SSCOP-Prozesses auf Null initialisiert und wird dann N (SQ) zugeordnet.

Zustandsvariablen am Receiver

Eine ATM-Schnittstelle behält eine Reihe von Empfangs-Side-Statusvariablen bei, die mit VR beginnen.

Statusvariable

Name

Beschreibung

VR(R)

Empfangen

Sequenznummer der nächsten SD-PDU in der Sequenz, die der Empfänger erwartet. Sie wird erhöht, wenn diese Meldung angezeigt wird.

VR(H)

Höchst erwartet

Die höchste erwartete Sequenznummer in einer SD-PDU. Wird von der nächsten SD- oder POLL-Nachricht aktualisiert und sollte ungefähr gleich dem Peer-VT(S) sein.

VR(MR)

Maximaler Empfang

Höchste Sequenznummer in einer SD-PDU, die der Empfänger akzeptieren wird. Mit anderen Worten, der Receiver lässt bis zu VR(MR) - 1 zu und verwirft dann alle SD-PDUs mit einer höheren Sequenznummer. Die Aktualisierung von VR (MR) hängt von der Implementierung ab.

VR(SQ)

Empfängerverbindungssequenz

Diese Funktion dient zum Identifizieren der erneut übertragenen BGN-, ER- und RS-PDUs. Wenn eine ATM-Schnittstelle eine dieser PDUs empfängt, vergleicht sie den N(SQ)-Wert mit ihrem eigenen VR(SQ)-Wert. Wenn sich die beiden Werte unterscheiden, wird die PDU als neue Nachricht verarbeitet. Wenn die beiden Werte gleich sind, wird die Stromverteilungseinheit als erneute Übertragung identifiziert.

In PDU-Parameter übersetzte Statusvariablen

Receive- und Transmit-State-Variablen werden übersetzt oder in tatsächliche PDU-Parameter mit leicht unterschiedlichen Namen zugeordnet. Diese Tabelle zeigt die PDU-Parameter und die Statusvariable, von der sie abgeleitet werden:

Parameter

Zugeordnet von

Beschreibung

N (SQ)

VR(SQ)

In einer BGN-, RS- oder ER PDU übertragene Verbindungssequenznummer. Wird mit dem VR(SQ)-Zähler am Empfänger verwendet, um Neuübertragungen dieser PDUs zu identifizieren.

N (S)

VT(s)

Die Seriennummer wird in jeder SD- oder POLL-PDU übertragen und mit jeder neuen, nicht erneut übertragenen PDU erhöht.

N (PS)

VT (PS)

Wird in einer POLL-PDU und einer übereinstimmenden STAT-PDU übertragen, um die beiden Nachrichten miteinander zu korrelieren.

N (R)

VR(R)

Die in einer STAT- oder USTAT-PDU mitgeführte Sequenznummer wird empfangen. Wird vom Peer-Gerät gesendet, wenn der Empfang einer oder mehrerer Signalisierungsnachrichten bestätigt wird.

N (MR)

VR(MR)

Folgendes Stromverteilereinheiten enthalten: STAT, USTAT, RS, RSAK, ER, ERAK, BGN, BGAK. Gibt die Anzahl der verbleibenden Empfangsgutschriften an und an, ob der Peer eine andere Nachricht senden kann. Beispiel: Ein N(MR)-Wert von 5 bedeutet, dass der Peer bis zu 5 PDUs senden kann, ohne auf eine Antwort zu warten.

Beispielausgabe für Debugging

Die folgende Ausgabe wurde durch Ausgabe des Befehls debug sscop event atm 3/0 auf einem Router der Serie 7500 mit PA-A3 generiert. Die blauen Kommentare werden verwendet, um die Debug-Ausgabe zu interpretieren.

*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.

Die Debug-Ausgabe erfasst SSCOP-Nachrichten, die während der Verbindungseinrichtung und als Teil des Keepalive-Mechanismus gesendet werden. Eine gleichzeitige Erfassung des Befehls show sscop atm während der Ausführung der debug-Befehle zeigt inkrementelle Werte für Pdus Sent und Pdus Received sowie für Polll und 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

Zugehörige Informationen

- ITU-T User-Network Interface (UNI)-Spezifikation

- UNI-Spezifikationen des ATM-Forums

- Support-Seiten für ATM-Technologie

- Technischer Support - Cisco Systems