



|
|
LLC Type 2 Commands and Response FramesType 2 LLC includes these frames:
All the frames defined as Type 1 are technically considered to be Type 2 frames as well. However, you should absolutely know which frames are specific to Type 1 and which frames are specific to Type 2. If you were asked whether a UI frame was Type 1 or Type 2 the reasonable response would be to say, "Type 1" even though you know that technically it would be valid to say, "Type 2" since all Type 1 is included in Type 2. I Information frame ‘I’ frames transfer sequentially numbered blocks of data between communicators. The I frame contains a send sequence number (NS= or N(S)=) indicating the number of the currently transmitted block. Additionally, each I frame includes the number of the next expected frame from the other communicator. SUPERVISORY TYPE 2 COMMANDSSupervisory Commands do not contain an Information field and, therefore, do not increment the sequence number being sent. The RR frame is used when a station is acknowledging previously sent data but has no new data to send. In the case where the station DOES have more information to send it simply sends it (NS=). If there is no ‘NS=‘ then the ‘NR=‘ is accompanied by the RR (or RNR) indication. If a station sends ‘RNR’ it means that a temporary busy condition exists and the station is currently unable to accept I frames. A brief time after sending an RNR indication it is expected (hoped) that the station will become ready to accept frames and will send the RR indication. A REJ command is used to request the resending of one or more frames starting with the frame indicated in the REJ command. For example, if a station sends: NS=0, NS=1, NS=2 but frame #2 is corrupted in transit then the receiver gets: NS=0, NS=2. The receiver will now transmit a REJ command with NR=2 indicating that resending should start with NS=2 and proceed from there (with a resend, in this case, of NS=3). The REJ frame is a polite request to retransmit something that was lost in transit. Unnumbered Type 2 CommandsSABME Set Asynchronous Balanced Mode Extended This command is used to establish the link between two LLC stations. This command will always be seen at the beginning of a Type 2 connection. If a SABME is received from a station to which acknowledgments are due (from a previous connection) then the pending acknowledgments are canceled assuming that the other communicator encountered some situation requiring the re-establishment of an entirely new connection. When a station wants to terminate a connection it sends a DISC command. The command informs the destination that the source is suspending operation of the data link connection. The destination should then enter the Disconnect Mode. If acknowledgments are pending when a DISC is received then the acknowledgments are canceled assuming that the other communicator has suspended operation for reasons of its own. ResponsesResponses could include any of these previously defined frames: I, RR, RNR, REJ Responses could also include these: The DM response is used to report the status of a station that has entered the disconnected mode. It is usually seen following the receipt of a DISC command. I tell you I am DISConnected and you report that you have entered the Disconnect Mode. The FRMR is one of the most misunderstood commands. The 802.2 spec says that the frame is sent when a condition occurs that is not correctable by resending previously sent frames. In effect, a FRMR indicates a catastrophic failure. If you see FRMR frames, suspect possible bugs in device driver software or possible hardware failure. Lost frames on a network will not cause FRMR’s, only REJ’s. The events that may cause the transmission of an LLC FRMR frame are:
The response to receipt of an FRMR is dependent on the implementation. An LLC implementation may be designed to implement some corrective action or it may simply ‘hang’. If you see FRMR frames you need to find out who is sending them, and why. |
Lawful Intercept
Deploying & Testing Applications
Distributed Networks
Network Baselining
Network Forensics
Network Performance Analysis
- NetFlow
Network Performance Management
Network Security
Network Troubleshooting
Product Development Support
VoIP Monitoring and Analysis
Video Monitoring and Analysis
Wireless Network Analysis
10 Gigabit Networks
Industry Specific Solutions
OmniFlow Collector
NetFlow Collector
sFlow Collector
OmniPeek Network Analyzer
Compass Live
OmniEngine Software Probe
OmniVirtual VMware Probe
TimeLine Network Recorder
Omnipliance Network Recorder
OmniAdapter Analysis Cards
Omnipliance Portable
Product Activation FAQs
Maintenance Programs
Product Versions
Contact Tech Support
Downloads
Training / Courses
Consulting
Custom Engineering
WildPackets Forums
MyPeek Community Portal
Information Kits
Video How-To's
Product Tips and Tricks
Networking Glossary
Networking Links
Free Utilities
Media Coverage
Media Kit
Blog
Peeks Newsletter
Success Stories
Reviews & Awards
Upcoming Events
Webinars & Webcasts
Software Upgrades
Hardware
Training
Maintenance Renewal
Per Incident Support
Sales Policies
Contact Sales






Germany
Japan
Korea
UK
United States












