Вы находитесь на странице: 1из 276

GENERIC REQUIREMENTS

GR1230CORE
ISSUE 4, DECEMBER 1998
SONET Bidirectional Line-
Switched Ring Equipment
Generic Criteria
A Module of TSGR, FR440

SONET Bidirectional Line-
Switched Ring Equipment
Generic Criteria
A Module of TSGR, FR440
GENERIC REQUIREMENTS
GR1230CORE
ISSUE 4, DECEMBER 1998

SONET BLSR Equipment Generic Criteria GR1230CORE
Copyright Page Issue 4, December 1998

ii
This document, GR1230CORE, Issue 4, December 1998, replaces:
GR1230CORE, Issue 3, December 1996.
For ordering information, see the References section of this document.
This document may not be reproduced without the express written permission of Bellcore
and any reproduction without written authorization is an infringement of Bellcores
copyright.
Copyright 1998 Bellcore.
All rights reserved.
Project funding year: 1998.
iii
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Notice of Disclaimer

GENERIC REQUIREMENTS
NOTICE OF DISCLAIMER
This Generic Requirements document (GR) is published by Bellcore to inform the industry
of Bellcores view of proposed generic requirements on SONET BLSR Equipment Generic
Criteria. These generic requirements are subject to review and change, and superseding
generic requirements regarding this subject may differ from this document. Bellcore
reserves the right to revise this document for any reason (consistent with applicable
provisions of the Telecommunications Act of 1996 and applicable FCC rules).
BELLCORE, AND FUNDING PARTICIPANTS IDENTIFIED IN THE PREFACE,
MAKE NO REPRESENTATION OR WARRANTY, EXPRESSED OR IMPLIED, WITH
RESPECT TO THE SUFFICIENCY, ACCURACY, OR UTILITY OF ANY
INFORMATION OR OPINION CONTAINED HEREIN.
BELLCORE, AND FUNDING PARTICIPANTS, EXPRESSLY ADVISE THAT ANY
USE OF OR RELIANCE UPON SAID INFORMATION OR OPINION IS AT THE RISK
OF THE USER AND THAT NEITHER BELLCORE, NOR ANY FUNDING
PARTICIPANT, SHALL BE LIABLE FOR ANY DAMAGE OR INJURY INCURRED
BY ANY PERSON ARISING OUT OF THE SUFFICIENCY, ACCURACY, OR
UTILITY OF ANY INFORMATION OR OPINION CONTAINED HEREIN.
LOCAL CONDITIONS MAY GIVE RISE TO A NEED FOR ADDITIONAL
PROFESSIONAL INVESTIGATIONS, MODIFICATIONS, OR SAFEGUARDS TO
MEET SITE, EQUIPMENT, ENVIRONMENTAL SAFETY OR COMPANY-SPECIFIC
REQUIREMENTS. IN NO EVENT IS THIS INFORMATION INTENDED TO
REPLACE FEDERAL, STATE, LOCAL, OR OTHER APPLICABLE CODES, LAWS,
OR REGULATIONS. SPECIFIC APPLICATIONS WILL CONTAIN VARIABLES
UNKNOWN TO OR BEYOND THE CONTROL OF BELLCORE. AS A RESULT,
BELLCORE CANNOT WARRANT THAT THE APPLICATION OF THIS
INFORMATION WILL PRODUCE THE TECHNICAL RESULT OR SAFETY
ORIGINALLY INTENDED.
This GR is not to be construed as a suggestion to anyone to modify or change any of its
products or services, nor does this GR represent any commitment by anyone, including, but
not limited to, Bellcore or any funder (see Preface) of this Bellcore GR to purchase,
manufacture, or sell, any product with the described characteristics.
Readers are specifically advised that any entity may have needs, specifications, or
requirements different from the generic descriptions herein. Therefore, anyone wishing to
know any entitys needs, specifications, or requirements should communicate directly with
that entity.
Nothing contained herein shall be construed as conferring by implication, estoppel, or
otherwise any license or right under any patent, whether or not the use of any information
herein necessarily employs an invention of any existing or later issued patent.
SONET BLSR Equipment Generic Criteria GR1230CORE
Notice of Disclaimer Issue 4, December 1998

iv
Nothing contained herein is intended as a recommendation of any product to anyone.
v
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 TSGR Contents

FR440, Transport System Generic Requirements (TSGR) 1998 Edition
Vol Section Module
1 Common Criteria
Common Requirements, GR499
NEBS, GR63
Alarm Indication Signal, TRTSY000191
Supplier-Provided Documentation, GR454
Supplier-Provided Training, GR839
Supplier Support, TRNWT000840
EMC and Electrical Safety, GR1089
Assuring Corrosion Resistance of Outside Equipment, GR-2836
DLC System, UDC, and Digital Loop Carrier Systems, TRNWT000057
2 Basic Exchange Radio Universal Digital Channel (UDC), TRTSY000398
Systems Basic Exchange Radio Systems, TRNWT000911
3 IDLC System IDLC System, GR303
ISDN Transport, ISDN Basic Access DSL, TRNWT000393
4 Interface, and Related ISDN Basic Access Transport, TRNWT000397
Requirements ISDN PRA Transport, TRTSY000754
5 Digital Radio Systems Microwave Digital Radio, TRTSY000752
SONET Transport Systems: Common Generic Criteria, GR253
6 SONET Common SONET OC192 Criteria, GR1377
Criteria SONET Private Line Service Interface Criteria, GR1365
SONET Inter-Carrier Interface Criteria, GR1374
SONET Add/Drop Multiplex, TRNWT000496
Wideband and Broadband Digital Cross-Connect, TRNWT000233
SONET Digital Switch Trunk Interface, TRTSY000782
SONET RGTR Equipment Criteria, TRNWT000917
7 SONET Network SONET Dual-Fed UPSR Criteria, GR1400
Element Criteria SONET BLSR Criteria, GR1230
Self-Healing Ring-Functionality in Digital Cross-Connect Systems,
GR1375
ATM Virtual Path Functionality in SONET Rings, GR2837
ATM Functionality in SONET Digital Cross-Connect Systems -
Generic Criteria, GR2891
SONET BLSR Equipment Generic Criteria GR1230CORE
TSGR Contents Issue 4, December 1998

vi
Note:
This document is a module of the Transport Systems Generic Requirements (TSGR),
FR440. To order modules or the entire TSGR:
Public should contact:
Bellcore Customer Service
8 Corporate Place, Room 3A184
Piscataway NJ 088544156
1800521CORE (2673)
(732) 6995900 (For Foreign Calls)
BCC personnel should contact their company document coordinator.
Bellcore employees should call the Bellcore Document Hotline: (732) 6995802.
vii
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Contents

SONET Bidirectional Line-Switched Ring Equipment
Generic Criteria
Contents Contents
1. Introduction............................................................................................................... 11
1.1 Update History ................................................................................................ 12
1.2 Scope............................................................................................................... 14
1.3 Criteria............................................................................................................. 15
1.4 Requirement Labeling Conventions................................................................ 15
1.4.1 Numbering of Requirement and Related Objects .............................. 15
1.4.2 Requirement, Conditional Requirement, and Objective Object
Identification ...................................................................................... 16
1.5 Organization.................................................................................................... 16
1.6 Source Documents .......................................................................................... 17
1.7 Assumptions.................................................................................................... 17
2. Definitions, Terminology, and Common Phrases..................................................... 21
3. Overview of the BLSR Architecture......................................................................... 31
3.1 Two-Fiber BLSR Overview............................................................................ 32
3.2 Four-Fiber BLSR Overview.......................................................................... 316
3.3 VT-Access Overview.................................................................................... 323
3.4 Extra Traffic Overview................................................................................. 330
3.4.1 Squelching to Avoid Misconnected Traffic..................................... 330
3.5 Enhanced Non-preemptible Unprotected Traffic (E-NUT) Overview ......... 336
3.6 STS Squelching Logic Overview.................................................................. 338
3.6.1 Squelching for Unidirectional (and Bidirectional) Circuits ............. 338
3.6.2 Squelching for Multiply Sourced/Dropped Unidirectional Circuits 340
3.7 Ring Interworking Overview ........................................................................ 344
3.7.1 Drop-and-Continue Method............................................................. 344
3.7.2 Protection Switching Mechanisms for Inter-ring Traffic................. 347
3.7.2.1 Interconnection Survivability with Drop and Continue on
Working BandwidthChannels.......................................... 348
3.7.2.2 Interconnection Survivability with Drop and Continue on
Protection Bandwidth (Ring Interworking on Protection)
......................................................................................... 349
3.7.2.3 Cable Cut in Ring #1 and Ring #2................................... 354
3.7.2.4 Primary Node Failure in Ring #1 and Cable Cut in Ring #2
......................................................................................... 355
3.7.3 Dual Transmit Method..................................................................... 357
3.7.3.1 Dual Transmit On Working Channels ............................. 357
3.7.3.2 Dual Transmit On Protection Channels........................... 358
SONET BLSR Equipment Generic Criteria GR1230CORE
Contents Issue 4, December 1998

viii
4. Network Applications ............................................................................................... 41
5. Functions Needed for NE Deployment in a BLSR................................................... 51
6. Equipment Criteria and K1/K2 Byte Protocol .......................................................... 61
6.1 Equipment Criteria .......................................................................................... 61
6.1.1 Equipment Criteria for 2- and 4-Fiber Ring....................................... 61
6.1.2 Equipment Criteria for 4-Fiber BLSRs Only..................................... 67
6.1.3 Equipment Criteria for 2-Fiber BLSRs Only..................................... 67
6.2 Switch Initiation and K1 and K2 Protocol ...................................................... 68
6.2.1 Switch Initiation Criteria.................................................................... 68
6.2.1.1 Externally Initiated Protection Switching Commands (OS or
WS) .................................................................................... 69
6.2.1.2 Automatically Initiated Protection Switch Requests ....... 612
6.2.1.3 Functional Requirements ................................................. 614
6.2.2 Bit-Oriented Protocol for K1/K2 Bytes ........................................... 615
6.2.2.1 Steady State Behavior...................................................... 619
6.2.2.2 State Transition Rules...................................................... 627
6.2.2.3 Examples of Protection Switching in a BLSR................. 642
7. Requirements for Ring Interconnection.................................................................... 71
7.1 Ring Interconnection Using Protection Capacity............................................ 79
7.2 Dual Transmit Method .................................................................................. 711
8. Operations, Administration, Maintenance, and Provisioning (OAM&P) Criteria ... 81
8.1 Operations Data Networking........................................................................... 81
8.2 Alarm Surveillance Requirements .................................................................. 82
8.2.1 Troubles in the APS Channel ............................................................. 83
8.2.2 Additional Information Needed in BLSR.......................................... 85
8.2.3 BLSRs and Routine Operations ......................................................... 86
8.3 Performance Monitoring (PM)........................................................................ 87
8.4 Testing and Control Functions ........................................................................ 89
8.5 Memory Administration................................................................................ 812
9. System Availability Criteria...................................................................................... 91
10. Synchronization Criteria ......................................................................................... 101
Requirement-Object List ........................................................................................... ROL1
Requirement-Object Index ......................................................................................... ROI1
References ....................................................................................................... References1
Acronyms.......................................................................................................... Acronyms1
ix
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 List of Figures

List of Figures Figures
Figure 2-1. Isolated Node.......................................................................................... 211
Figure 2-2. Short and Long Paths.............................................................................. 211
Figure 2-3. Ring Segmentation ................................................................................. 212
Figure 2-4. Service Selector (Interconnection Between Two BLSRs) ..................... 213
Figure 3-1. Traffic Flow Support on a BLSR Ring..................................................... 31
Figure 3-2. Simplified Node in a 2-Fiber BLSR......................................................... 33
Figure 3-3. 4-Node, 2-Fiber BLSR ............................................................................. 34
Figure 3-4. Traffic Assignment Illustration for a 2-Fiber BLSR ................................ 35
Figure 3-5. Dropped and Continued Paths .................................................................. 37
Figure 3-6. Ring Switching for a Unidirectional Degradation on a 2-Fiber BLSR .... 38
Figure 3-7. Node Failure on a 2-Fiber BLSR............................................................ 310
Figure 3-8. Misconnection for STS-1 #1 for Traffic from Node 4 to Node 1......... 311
Figure 3-9. Misconnection for STS-1 #1 for Traffic from Node 2 to Node 1......... 312
Figure 3-10. Misconnection for STS-1 #2 for Traffic from Node 3 to Node 1......... 313
Figure 3-11. Misconnection for STS-1 #3 for Traffic from Node 4 to Node 1......... 314
Figure 3-12. Isolation of Two Nodes by a Cable Cut ................................................. 315
Figure 3-13. Simplified Node in a 4-Fiber BLSR....................................................... 317
Figure 3-14. 4-Node, 4-Fiber BLSR ........................................................................... 318
Figure 3-15. Unidirectional Span Failure on a 4-Fiber BLSR.................................... 319
Figure 3-16. Cable Cut on a 4-Fiber BLSR................................................................. 320
Figure 3-17. Restoration for a Cable Cut on a 4-Fiber BLSR..................................... 321
Figure 3-18. Cable Cut and a Span Switch on a 4-Fiber BLSR (Before a Ring Switch)
................................................................................................................ 322
Figure 3-19. Misconnection of Traffic Related to Existing Switches......................... 323
Figure 3-20. VT Squelch Table Example (Bidirectional Traffic) All Nodes VT-
access ...................................................................................................... 326
Figure 3-21. VT Squelch Table Example (Unidirectional Traffic) Not All Nodes VT-
access ...................................................................................................... 327
Figure 3-22. VT Squelch Table Example (Inter-Ring Capability) All Nodes VT-
access ...................................................................................................... 329
Figure 3-23. Example of Potential for Misconnection................................................ 331
Figure 3-24. Signalling during SF-R with Extra Traffic............................................. 333
Figure 3-25. Signalling during SF-S with Extra Traffic ............................................. 335
Figure 3-26. Conceptual Representation of a E-NUT Table....................................... 337
Figure 3-27. Unidirectional Circuit Squelching Example Where the Failure is in the
Opposite Direction from the Unidirectional Circuit ............................... 338
Figure 3-28. Unidirectional Circuit Squelching Example Where the Failure is in the
Direction of the Unidirectional Circuit................................................... 339
Figure 3-29. Bidirectional Circuit Squelching Example............................................. 340
Figure 3-30. Multiply Sourced Unidirectional Circuit Squelching Example where the
Failure is in the Opposite Direction from the Unidirectional Circuit ..... 341
SONET BLSR Equipment Generic Criteria GR1230CORE
List of Figures Issue 4, December 1998

x
Figure 3-31. Multiply Dropped Unidirectional Circuit Squelching Example where the
Failure is in the Opposite Direction from the Unidirectional Circuit ..... 341
Figure 3-32. Multiply Sourced Unidirectional Circuit Squelching Example where the
Failure is in the Direction of the Unidirectional Circuit......................... 342
Figure 3-33. Multiply Dropped Unidirectional Circuit Squelching Example where the
Failure is in the Direction of the Unidirectional Circuit......................... 342
Figure 3-34. Bidirectional Circuit Squelching Example with Multiply Sourced and
Multiply Dropped Traffic ....................................................................... 343
Figure 3-35. Baseline Ring Interconnection................................................................ 345
Figure 3-36. Interconnection of BLSR and Mesh Network ........................................ 346
Figure 3-37. Correlation Between Inter-ring Circuit and Multiply Sourced and Multiply
Dropped Circuits..................................................................................... 348
Figure 3-38. Squelch Table Example for Inter-ring Traffic with Secondary Circuit on
Working Bandwidth ............................................................................... 349
Figure 3-39. Ring Interworking on Protection ............................................................ 350
Figure 3-40. Opposite-Side Routing with (1) Service Circuit on Protection and (2) Service
Circuit on Working: Double Link Failures............................................. 351
Figure 3-41. Squelch Table Example for Inter-ring Traffic with Secondary Circuit on
Protection Bandwidth ............................................................................. 352
Figure 3-42. RIP Table Example for Inter-ring Traffic with Secondary Circuit on
Protection Bandwidth ............................................................................. 352
Figure 3-43. Primary Node Failure Restoral in a BLSR with Secondary Circuit on
Protection: Basic Operation.................................................................... 353
Figure 3-44. Link Failure Restoral in a BLSR with Secondary Circuit on Protection:
Optional Enhanced Operation ................................................................ 353
Figure 3-45. Cable Cut in Ring #1 and Ring #2.......................................................... 354
Figure 3-46. Primary Node Failure in Ring #1 and Cable Cut in Ring #2 with Optional
Enhanced Operation ............................................................................... 355
Figure 3-47. Primary Node Failure in Ring #1 and Cable Cut in Ring #2 with Basic
Secondary Node Operation..................................................................... 356
Figure 3-48. Dual transmit Ring Interworking - Relieved Congestion P-S................ 358
Figure 3-49. Dual Transmit Ring Interworking - Improved Bandwidth Efficiency ... 359
Figure 3-50. BLSR Interconnection with Dual Transmit and Same Side Routing ..... 360
Figure 3-51. BLSR Interconnection with Dual Transmit and Opposite Side Routing361
Figure 6-1. Isolated Node Signaling (Signaling States Before B and D Establish a Ring
Bridge and Switch) ................................................................................. 624
Figure 6-2. Four-Fiber BLSR - Unidirectional Failure (Span) on Working From E to F.
652
Figure 6-3. Four-Fiber BLSR - Unidirectional Failure (Span) on Working From E to F
(Concluded) ............................................................................................ 654
Figure 6-4. Two- or Four-Fiber BLSR - Unidirectional SF (Ring)........................... 655
Figure 6-5. Two- or Four-Fiber BLSR - Unidirectional SF (Ring) (Concluded)...... 657
Figure 6-6. Two- or Four-Fiber BLSR - Bidirectional SF (Ring)............................. 658
Figure 6-7. Two- or Four-Fiber BLSR - Bidirectional SF (Ring) (Concluded)........ 660
xi
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 List of Figures

Figure 6-8. Two- or Four-Fiber BLSR - Unidirectional SD (Ring) .......................... 661
Figure 6-9. Two- or Four-Fiber BLSR - Node Failure.............................................. 663
Figure 6-10. Two- or Four-Fiber BLSR - Node Failure (Concluded)......................... 665
Figure 6-11. Four-Fiber BLSR - Unidirectional Signal Fail (Ring) Pre-empting a
Unidirectional Signal Degrade (Span) on Non-Adjacent Spans ............ 666
Figure 6-12. Four-Fiber BLSR - Unidirectional Signal Fail (Ring) Pre-empting a
Unidirectional Signal Degrade (Span) on Non-Adjacent Spans (Concluded)
668
Figure 6-13. Four-Fiber BLSR - Unidirectional Signal Fail (Ring) Pre-empting a
Unidirectional Signal Degrade (Span) on Adjacent Spans..................... 669
Figure 6-14. Four-Fiber BLSR - Unidirectional Signal Fail (Ring) Pre-empting a
Unidirectional Signal Degrade (Span) on Adjacent Spans (Concluded) 671
Figure 6-15. Four-Fiber BLSR - Unidirectional Signal Fail (Span) Pre-empting a
Unidirectional Signal Fail (Ring) on Adjacent Spans ............................ 672
Figure 6-16. Two- or Four-Fiber BLSR - Unidirectional Signal Fail (Ring) Plus
Unidirectional Signal Fail (Ring) on Non-Adjacent Spans .................... 674
Figure 6-17. Two- or Four-Fiber BLSR - Node Failure on a Ring with VT access ... 676
Figure 6-18. Two- or Four-Fiber BLSR - Node Failure on a Ring with VT access
(Concluded) ............................................................................................ 677
Figure 6-19. Two- or Four-Fiber BLSR - Node Failure on a Ring with VT access and
Extra Traffic ........................................................................................... 678
Figure 6-20. Two- or Four-Fiber BLSR - Node Failure on a Ring with VT access and
Extra Traffic (Concluded) ...................................................................... 679
Figure 7-1. Interconnection between Two BLSRs (Same-side Routing).................... 72
Figure 7-2. Interconnection between Two BLSRs (Opposite-side Routing) .............. 73
Figure 7-3. Primary Node Failure on a BLSR............................................................. 74
Figure 7-4. Interconnection of a BLSR with a UPSR................................................. 75
Figure 7-5. Service Selection in the Presence of STS PDI-P and STS-SD................. 78
Figure 8-1. Protection Switch Counts: 2-Fiber BLSR ................................................ 88
Figure 8-2. Protection Switch Counts: 4-Fiber BLSR ................................................ 88
Figure 8-3. Squelch Table Example (Based on Table 3-1) ....................................... 813
SONET BLSR Equipment Generic Criteria GR1230CORE
List of Figures Issue 4, December 1998

xii
xiii
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 List of Tables

List of Tables Tables
Table 3-1. Traffic Assignments on a 2-Fiber BLSR.................................................. 36
Table 3-2. Interconnection Options Between Two BLSRs..................................... 347
Table 6-1. K1 Bit Assignments................................................................................ 617
Table 6-2. K2 Bit Assignments................................................................................ 618
Table 6-3. Relationships Between K2 Bit 5 and K1 Bits 1-4 .................................. 619
Table 6-4. Byte K1 and K2 Values Sourced in the Idle State.................................. 620
Table 6-5. Default APS Codes................................................................................. 620
Table 6-6. Byte K1 and K2 Values Sourced in the Switching State........................ 621
Table 6-7. SD-P and SF-P (LP-S) Coexisting with Ring Switches on the Same Span ...
622
Table 7-1. Hierarchy of Conditions for Service Selection......................................... 77
SONET BLSR Equipment Generic Criteria GR1230CORE
List of Tables Issue 4, December 1998

xiv
Preface1
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Preface

Preface Preface
This Preface contains important information about Bellcores GR process in general,
as well as important information about this document.
Bellcores GR Process
Generic Requirements documents (GRs) provide Bellcores view of proposed generic
criteria for telecommunications equipment, systems, or services, and involve a wide variety
of factors, including interoperability, network integrity, funding participant expressed
needs, and other input.
Bellcores GR process implements Telecommunications Act of 1996 directives relative to
the development of industry-wide generic requirements relating to telecommunications
equipment, including integral software and customer premises equipment. Pursuant to that
Act, Bellcore invites members of the industry to fund and participate in the development
process for such GRs. Invitations to fund and participate are issued monthly in the Bellcore
Digest of Technical Information, and posted on Bellcores web site at
http://www.bellcore.com/DIGEST.
At the conclusion of the GR development process, Bellcore publishes the GR, which is
available by subscription. The subscription price entitles the purchaser to receive that issue
of the GR (GR-CORE) along with any Issues List Report (GR-ILR) and revisions, if any
are released under that GR project. ILRs contain any technical issues that arise during GR
development that Bellcore and the funding participants would like further industry
interaction on. The ILR may present issues for discussion, with or without proposed
resolutions, and may describe proposed resolutions that lead to changes to the GR.
Significant changes or additional material may be released as a revision to the GR-CORE.
Bellcore may also solicit general industry nonproprietary input regarding such GR material
at the time of its publication, or through a special Industry Interaction Notice appearing in
the Bellcore Digest of Technical Information. While unsolicited comments are welcome,
any subsequent work by Bellcore regarding such comments will depend on funding support
for such GR work. Bellcore will acknowledge receipt of comments and will provide a status
to the submitting company.
SONET BLSR Equipment Generic Criteria GR1230CORE
Preface Issue 4, December 1998

Preface2
About GR1230CORE
A. Funders of GR1230CORE, Issue 4, are:
Alcatel
BellSouth
Fujitsu
SBC
US WEST
B. Relative Maturity Level
This is a mature technology and requirements reflect maintenance mode.
C. GR1230CORE Plans
There are currently no plans to reissue or provide revisions to this document. ILRs will be
issued in the future if necessary to notify industry of any issues that may arise.
To Submit Comments
When submitting comments, please include the GR document number, and cite any
pertinent section and requirement number. In responding to an ILR, please identify the
pertinent Issue ID number. Please provide the name and address of the contact person in
your company for further discussion.
Comments should be submitted by April 1, 1999.
Send comments to:
Bellcore GR1230CORE
Carmine Daloia
331 Newman Springs Road, NVC-2X255
Red Bank, NJ 07701-5699
Phone: (732) 758-2658
FAX: (732) 758-4177
E-Mail: cdaloia@notes.cc.bellcore.com
1-1
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Introduction

1. Introduction
Automatic Protection Switching (APS) improves the survivability of transport systems by
substituting a standby facility when failures occur. Point-to-point protection systems
provide protection against failures that affect only the working line. [GR253CORE,
Synchronous Optical Network (SONET) Transport Systems: Common Generic Criteria,
provides the generic requirements for SONET point-to-point systems.]
For failures that affect not only the working channels but also the protection channels, such
as a cable cut, other methods of protection switching exist. Digital Cross-connect System
(DCS) equipment can be used to reroute the traffic when failures occur. However, the DCS
reconfiguration time is not always adequate. One-to-one dedicated (diversified) paths can
also be used to protect traffic when the failure affects only one of the paths. This method
requires duplicating each path end-to-end. Thus, the impact on the capacity of the network
may be unacceptable. Ring APS provides an alternative method of protection switching
that allows protection bandwidth to be shared (i.e., protection is no longer required to be
dedicated for each path separately) and protects traffic within an acceptable restoration
time.
A ring is defined as a set of nodes interconnected to form a closed loop, where fiber cables
serve as links; thus, unlike a linear add/drop chain, the Network Elements (NEs) are
connected in a ring configuration. Regenerators may be located between the nodes. In this
Generic Requirements document (GR), a node refers to SONET Line Terminating
Equipment (LTE). A node also has add/drop functionality. A ring provides redundant
bandwidth to protect services against failures.
There are two major types of SONET rings: path-switched and line-switched SONET rings.
The generic requirements for path-switched rings are provided in GR1400CORE,
SONET Dual-Fed Unidirectional Path Switched Ring (UPSR) Equipment Generic
Criteria, Issue 1, and will not be repeated in this document. Line-switched rings use the
SONET line level indications to initiate protection switching. Line layer indications include
line layer failures and APS signaling messages that are received from other nodes. A
request for switching may also be initiated via an operations interface. Line-switched rings
can be either unidirectional or bidirectional depending on the traffic flow under normal
conditions. In a unidirectional ring, the traffic between two nodes is provisioned to travel
either clockwise or counterclockwise under normal conditions. A bidirectional connection
on a unidirectional ring uses capacity on the entire ring. If both directions of transmission
use the same set of nodes and links, the transmission is said to be bidirectional. A
bidirectional connection on a bidirectional ring uses capacity only between the nodes where
the traffic is added and where it is dropped.
The main advantage of the Bidirectional Line-Switched Ring (BLSR) is that it can
maximize bandwidth utilization and can provide a capacity advantage over other ring types
for some traffic patterns. The unidirectional line-switched ring may provide less capacity
given the same bandwidth as a bidirectional ring. A second advantage of the BLSR is that
it is similar operationally to today's networks.
SONET BLSR Equipment Generic Criteria GR1230CORE
Introduction Issue 4, December 1998

1-2
There are two types of BLSRs: 2-fiber and 4-fiber BLSRs. In a 4-fiber BLSR, the protection
and working channels are over different physical fibers (lines). In a 2-fiber ring, part of the
bandwidth on each of the two fibers is reserved for protection. The criteria provided in this
GR apply to both 2- and 4-fiber BLSRs unless otherwise stated.
1.1 Update History
This GR replaces GR1230CORE, SONET Bidirectional Line Switched Ring Equipment
Generic Criteria, Issue 3. Comments from vendors, manufacturers, users, and standards
developments have been considered and used in formulating the criteria provided in this
document. Resolutions of issues reflected in GR1230ILR Issue 3A have been
incorporated into this GR.
Specific additions, deletions, and changes (all denoted by change bars throughout) include:
Section 2: The following new definitions were added:
Dual Transmit Method
Enhanced Non-Preemptible Unprotected Channels
Enhanced Non-Preemptible Unprotected Traffic
Invalid K-byte
Node Failure
The following definitions were modified:
Add traffic
Alarm Indication Signal
Bridge
Drop Traffic
Extra Traffic
Protection Channels
Ring Switching
Switch
The following definitions have been removed:
Idle Node
Section 3: Text has been included to clearly indicate that STS Path AIS (AIS-P) is
inserted when traffic is squelched. Note that this change is only for clarification and
1-3
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Introduction

does not change existing BLSR functionality. New tutorial information is provided for
Enhanced Non-Preemptible Unprotected Traffic and the Dual Transmit method.
A new Section 3.5 has been added to provide tutorial material on Enhanced Non-
Preemptible Unprotected Traffic (E-NUT). The data necessary to generate a E-
NUT table is also described.
Section 3.7 has been modified and a new Section 3.7.4 has been added to provide
tutorial material on the Dual Transmit method for ring interworking. Section 3.7.4
covers both Dual Transmit on working and protection channels.
Section 4: No update was necessary for this section.
Section 5:
Text has been added to indicate that the functional criteria in GR-496-CORE for
SONET Add/Drop Multiplexers also apply in a BLSR.
The ability of the ring to carry E-NUT on channels provisioned as enhanced non-
preemptible unprotected channels has been added to the list of factors considered
in developing the criteria in Sections 6 through 8 of this GR.
Section 6: Modifications were made to this section. These changes are outlined below:
R6-17 [17], R6-24 [24], O6-25 [25], O6-26 [26], CR6-27 [27], and R6-36 [35]
which specify cross-connect capabilities, have been deleted since Section 5
specifies that the functional criteria in GR-496-CORE also apply to the BLSR. GR-
496-CORE specifies the necessary cross-connect functions (e.g., add, drop, pass-
through, and drop-and-continue).
R6-28 [32] has been modified to better indicate that nodes supporting VT access
shall support VT level pass-through and drop-and-continue as well as VT level
add/drop capabilities.
R6-47 [51] has been modified to clearly indicate that AIS-P is inserted into
squelched traffic.
CR6-52 [293] and R6-53 [294] has been added to support E-NUT. It specifies that
an E-NUT table must be maintained at each node if the ring supports E-NUT.
A footnote has been added within Table 6-1 to indicate that Lockout of Protection
- span (LP-S) has the same priority as Lockout of Working - Span (LOW-S),
Lockout of Working - Ring (LOW-R), and Lockout of Protection - all spans (LOP-
all spans). Each of these commands can coexist.
R6-131 [129] Rule I-S #4 has been modified to specify a ring or span switching
node to treat the receipt of invalid K-bytes (as defined in Section 2) the same as
default APS code.
SONET BLSR Equipment Generic Criteria GR1230CORE
Introduction Issue 4, December 1998

1-4
R6-147 [145] Rule S-S #2.g has been modified to prevent switches from bouncing
between one set of protection channels to another. This change has been agreed to
within T1X1.5.
R6-148 [274] Rule S-S #2.h has been modified to include text that specifies extra
traffic to be reinserted on the span adjacent to the request that had been preempted.
This text was added to align with standards.
Section 7: New Section 7.2 Dual Transmit Method was added.
CR7-33 [295] and R7-34 [296] were added in support of the Dual Transmit
Method.
Section 8: Modifications were made to Section 8.5 Memory Administration. These
changes are outlined below:
Text has been added to support E-NUT.
R8-60 [297] and R8-63 [298] have been added to support E-NUT. They indicate
that the content of the E-NUT table must be provisionable via the WS/NE or OS/
NE interface and that the E-NUT data must reside in non-volatile memory.
R8-64 [244] has been modified to require E-NUT table data to be retrievable via a
WS/NE or OS/NE interface.
R8-72 [300] has been added to require NEs that support E-NUT to provide
sufficient memory so as to store a temporary E-NUT table.
CR8-69 [299] has been added to specify that secondary nodes that support ring
interworking on protection, may be required to maintain a RIP table.
Section 9: No update was necessary for this section.
Section 10: No update was necessary for this section.
1.2 Scope
The generic equipment criteria provided in this document apply to both 2- and 4-fiber
BLSRs unless otherwise specified. Generic SONET NE criteria are provided in
GR253CORE and will not be repeated. Generic SONET Add/Drop Multiplexer
equipment criteria are provided in GR-496-CORE and will not be repeated. Only the
equipment criteria specific to BLSR applications are provided in this GR.
1-5
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Introduction

1.3 Criteria
This GR contains Bellcores view of generic requirements and objectives to meet a typical
service providers needs for BLSR applications. The following terminology is used
throughout this document:
Requirement Feature or function that, in Bellcore's view, is necessary to satisfy
the needs of a typical service provider. Failure to meet a requirement may cause
application restrictions, result in improper functioning of the product, or hinder
operations. A Requirement contains the words shall or must and is flagged by the letter
R.
Conditional Requirement Feature or function that, in Bellcore's view, is
necessary in specific applications. If a service provider identifies a Conditional
Requirement as necessary, it shall be treated as a requirement for the application(s).
Conditions that may cause the Conditional Requirement to apply include, but are not
limited to, certain application environments, elements, or other requirements, etc. A
Conditional Requirement is flagged by the letters CR.
Objective Feature or function that, in Bellcore's view, is desirable and may be
required by a service provider. An Objective represents a goal to be achieved. An
Objective may be reclassified as a Requirement at a specified date. An objective is
flagged by the letter O and includes the words it is desirable or it is an objective.
Conditional Objective Feature or function that, in Bellcore's view, is desirable in
specific applications and may be required by a service provider. It represents a goal to
be achieved in the specified Condition(s). If a service provider identifies a Conditional
Objective as necessary, it shall be treated as a requirement for the application(s). A
Conditional Objective is flagged by the letters CO.
Condition The circumstances that, in Bellcores view, will cause a Conditional
Requirement or Conditional Objective to apply. A Condition is flagged by the letters
Cn.
1.4 Requirement Labeling Conventions
As part of Bellcore's new GR Process, proposed requirements and objectives are labeled
using conventions that are explained in the following two sections.
1.4.1 Numbering of Requirement and Related Objects
Each Requirement, Objective, Condition, Conditional Requirement, and Conditional
Objective object is identified by both a local and an absolute number. The local number
consists of the object's document section number and its sequence number in the section
SONET BLSR Equipment Generic Criteria GR1230CORE
Introduction Issue 4, December 1998

1-6
(e.g., R3-1 is the first Requirement in Section 3). The local number appears in the margin
to the left of the Requirement. A Requirement objects local number may change in
subsequent issues of a document if other Requirements are added to the section or deleted.
The absolute number is a permanently assigned number that will remain for the life of the
Requirement; it will not change with new issues of the document. The absolute number is
presented in brackets (e.g., [2]) at the beginning of the requirement text.
Neither the local nor the absolute number of a Conditional Requirement or Conditional
Objective depends on the number of the related Condition(s). If there is any ambiguity
about which Conditions apply, the specific Condition(s) will be referred to by number in
the text of the Conditional Requirement or Conditional Objective.
1.4.2 Requirement, Conditional Requirement, and Objective Object
Identification
A Requirement object may have numerous elements (paragraphs, lists, tables, equations,
etc.). To aid the reader in identifying each part of the requirement, an ellipsis character (...)
appears in the margin to the left of all elements of the Requirement.
1.5 Organization
This GR provides tutorial material and criteria for BLSRs. It includes descriptions of
architectures, network applications, and NE-supported functions, as well as interface
requirements, equipment criteria, and operations and availability criteria.
The remaining sections of this GR are organized as follows:
Section 2 defines technical terms that are included in BLSR criteria.
Section 3 provides an overview of the 2- and 4-fiber BLSR architectures, and
describes protection methods for each. VT-access, extra traffic, Enhanced Non-
preemptible Unprotected Traffic (E-NUT), and squelching logic are also described,
with unidirectional service on the BLSR incorporated into sections on VT-access and
squelching logic.
Section 4 describes the network applications being considered for BLSRs.
Section 5 provides the functions needed for NE deployment in a BLSR.
Section 6 provides preliminary equipment criteria and discusses the switching
protocol of the SONET overhead. It also provides switch initiation criteria.
Section 7 provides the interface criteria for ring interconnection.
Section 8 provides operations, administration, maintenance, and provisioning criteria.
1-7
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Introduction

Section 9 provides system availability criteria.
Section 10 provides synchronization criteria.
The Requirement-Objects List provides all the criteria in this GR.
The Requirement-Objects Index provides an index of all the criteria in this GR.
The References section lists the documents referenced in this GR.
The Acronyms section defines the acronyms used in this GR.
1.6 Source Documents
The following documents were used to prepare this GR:
GR253CORE, Synchronous Optical Network (SONET) Transport Systems:
Common Generic Criteria, Issue 2 (Bellcore, December 1995) plus Revision 1
(Bellcore, December 1997).
GR-496-CORE, SONET Add-Drop Multiplexer (SONET ADM) Equipment Generic
Criteria, Issue 1 (Bellcore, December 1998).
GR1400CORE, SONET Dual-Fed Unidirectional Path Switched Ring (UPSR)
Equipment Generic Criteria, Issue 1 (Bellcore, March 1994) plus Revision 1
(Bellcore, October 1995).
GR1230ILR, Synchronous Optical Network (SONET) Automatic Protection
Switching, Issue 3A (Bellcore, December 1996).
1.7 Assumptions
The general assumptions that apply to this GR are as follows:
The NE for the BLSR application can relay (pass through) the K1 and K2 bytes of the
SONET transport overhead.
The switching protocol being standardized in T1X1.5 will support both the 2- and 4-
fiber BLSRs, including VT-access, extra traffic, and unidirectional services/circuits.
There is no traffic that is permanently being inserted on both the protection and
working channels (i.e., there is no permanent bridge).
Some of the protection switching functions, such as lockout of working channels, can
be provided using Data Communications Channels (DCCs).
The following information can be made available to the NE:
SONET BLSR Equipment Generic Criteria GR1230CORE
Introduction Issue 4, December 1998

1-8
The node identification (node ID) number (see Section 3.1) can be assigned and
made available for use during the transport of the K1 and the K2 bytes of the
SONET overhead.
The ring map that includes a complete order of the nodes on the ring can be made
available at each node.
A squelch table that includes drop and add locations for each Synchronous
Transport Signal (STS) or Virtual Tributary (VT) that the node is terminating or
passing through can be made available at that node.
The cross-connect map is available to each node on the ring.
A E-NUT table that includes the type of protection (i.e., ring switch or span switch)
that is not available for each working channel can be made available at each node.
2-1
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Definitions, Terminology, and Common Phrases

2. Definitions, Terminology, and Common Phrases
This section defines technical terms that are frequently used in BLSR criteria.
Add traffic Traffic inserted into working, protection, or enhanced
non-preemptible unprotected channels on the ring at a
ring node.
Adjacent span All ring nodes have a span on both sides. Each span is
considered to be adjacent to the other.
Alarm Indication
Signal (AIS)
A code sent downstream in a digital network as an
indication that an upstream failure has been detected. It
is associated with multiple transport layers.
APS bytes The K1 and K2 bytes of the SONET transport overhead
of a line carrying protection channels are called APS
bytes.
APS controller That part of a node responsible for generating and
terminating information carried in the APS protocol and
implementing the APS algorithm.
APS Request That set of signals into an APS controller that determines
its behavior. An APS request can be either an externally
initiated command or an automatically initiated
command.
Automatic Protection
Switching (APS)
For 2-fiber BLSRs, automatic protection switching is a
ring switch. For 4-fiber BLSRs, it includes both ring
switching and span switching.
Automatically
initiated command
An APS request that is initiated by any one of the
following: (1) SONET line performance criteria, (2)
local equipment performance criteria, or (3) received
bridge requests.
Auto-provisioning The assignment of values to parameters within a NE,
without those values being specifically entered
externally by a user or a management system.
Bidirectional Line
Switched Ring
(BLSR)
A bidirectional ring that uses the line level status and
performance parameters to initiate APS.
SONET BLSR Equipment Generic Criteria GR1230CORE
Definitions, Terminology, and Common Phrases Issue 4, December 1998

2-2
Bidirectional ring A ring in which all nodes send and receive duplex traffic
by traversing the same set of nodes for both directions of
transmission under normal conditions. Thus, if a traffic
from node 1 to node 2 is traveling clockwise, the
traffic from 2 to 1 travels counterclockwise. (See
Figure 3-1.)
Bidirectional
switching
A bridge to protection channel and a selection from a
protection channel of both directions of duplex traffic is
called bidirectional switching to protection.
Bridge The action of transmitting identical traffic (SPE
contents) on both the working and protection channels.
Bridge request A message sent from a tail-end node to the head-end
node requesting the head end perform a bridge of the
working channels onto the protection channels. When a
destination node receives a ring bridge request on the
short (or long) path or a span bridge request on the short
path, it is referred to as a bridge request.
Bridge request status A message sent from a tail-end node to all other nodes
within the protection system (on the path not carrying
the protection channels to be used) indicating the tail end
has requested a bridge. When a destination node receives
span bridge request on the long path, it is referred to as a
bridge request status.
Bridging to protection The action of transmitting identical traffic on both the
working and the protection channels.
Clean ring When neither extra traffic, VT-access, nor pre-existing
protection switching activity is present on a ring, the ring
is said to be a clean ring. A restoration procedure that
begins with a clean ring, rather than with a ring having
another switch action already present, is simpler and, to
some extent, can be executed in less time.
Controller failure The condition during which a node is no longer able to
correctly operate the APS protocol but still generates a
correctly formatted SONET frame.
Crossing K bytes Ring bridge requests of equal priority, or allowed
coexisting priorities, received on both sides of a node.
This includes when a switching node receives a ring
bridge request from the other end.
2-3
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Definitions, Terminology, and Common Phrases

Default APS code The APS bytes transmitted with the source node ID equal
to the destination node ID = 0000.
Drop and continue
feature
When traffic on a given time slot is allowed to be
dropped at more than one node, it is said to be dropped
and continued at all terminating (not continue through)
nodes between the node inserting the traffic and the last
node terminating the traffic. This feature can be used to
support broadcast services and dual access for inter-ring
traffic (see Sections 3.1 and 7).
Drop and continue on
protection
In a BLSR, use of the protection bandwidth to carry the
continue portion of a drop and continue traffic, along
with the duplicate feed from the other ring, for inter-ring
traffic.
Drop traffic Traffic extracted from working, protection, or enhanced
non-preemptible unprotected channels on the ring at a
ring node.
Dual homed service A dual homed service is one that allows a customer's
service to enter the ring at two different nodes for
survivability in the event of a node failure and ring
interconnection facility failure.
Dual Transmit
Method
Add traffic that is transmitted in both directions at a
node. This feature is used to support broadcast services
and dual access for inter-ring traffic.
Enhanced non-
preemptible
unprotected channel
A channel in a BLSR provisioned bidirectionally to
provide transport without BLSR automatic protection
switching. Enhanced non-preemptible unprotected
channels are provisioned on either the working channel,
protection channel, or both the working and
corresponding protection channel.
Enhanced non-
preemptible
unprotected traffic
(E-NUT)
Unprotected traffic carried on enhanced non-
preemptible unprotected channels which may not be
preempted.
Externally initiated
command
An APS request that is initiated by either an OS or
craftsperson.
SONET BLSR Equipment Generic Criteria GR1230CORE
Definitions, Terminology, and Common Phrases Issue 4, December 1998

2-4
Extra traffic Unprotected traffic that is inserted on the protection
channels when the protection channels are not used for
the protection of working channels. Extra traffic is pre-
empted when the working channels require protection.
Ring Interworking on Protection is considered Extra
Traffic.
Full pass-through The action of transmitting the same K1, K2, and
protection channels that are being received. Full pass-
through may be either unidirectional or bidirectional as
specified in the text. When a node enters unidirectional
full-pass-through, it shall continue sourcing the
previously sourced K-bytes in the opposite direction,
with the exception that K2 bits 6-8 shall reflect the
appropriate status code.
Head end The head end is the optics unit or the NE where the line
overhead is inserted. The head end executes the bridge to
protection. For bidirectional switching, a node functions
as the head end for the outgoing line and as the tail end
for the incoming line on the failed span.
Intermediate node A node that is located between the nodes that are
performing the bridging and the switching.
Invalid K-byte The detection of inconsistent APS codes defect, node ID
mismatch defect, or improper APS codes defect is
referred to as invalid K-byte. Section 8.2.1 specifies the
detection requirements for each of the defects mentioned
above.
Isolated node A single node that is isolated, from a traffic perspective,
by ring bridges on each of its two spans by its adjacent
nodes. Therefore, a node is isolated if it receives on both
sides any combination of ring bridge requests for signal
failure and failures (detected by the node itself). (See
Figure 2-1.)
2-5
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Definitions, Terminology, and Common Phrases

K byte pass-through The action of transmitting the same K1 and K2 bytes that
are being received, with the exception that the ET code
is sourced in byte K2 bits 6-8 over any span carrying
extra traffic. If the ET code is received and no extra
traffic exists on the other span, Idle is transmitted (in
place of ET) in byte K2 bits 6-8. Protection channels are
passed through only as required to support extra traffic.
K-byte pass-through is bidirectional.
Line A transmission medium, together with the associated
equipment, required to provide the means of transporting
information between two Network Elements (NEs), one
of which originates the line signal and the other
terminates the line signal.
Line Alarm
Indication Signal
(AIS-L)
An AIS-L code is generated by a Section Terminating
Equipment (STE) upon loss of input signal or loss of
frame. The AIS-L signal will maintain operation of the
downstream Section Terminating Equipment and
therefore prevent generation of unnecessary alarms. At
the same time, data and orderwire communication is
retained between the Section Terminating Equipment
and the downstream Line Terminating Equipment
(LTE).
Line Terminating
Equipment (LTE)
Network elements that originate and/or terminate line
(OC-N) signals. LTEs can originate, access, modify, or
terminate the transport overhead, or can perform any
combination of these actions.
Long path The path segment away from the span for which the
request is initiated. Typically, there are other nodes
along this path segment. (See Figure 2-2.)
Long path request The request sent on the path segment away from the span
for which the request is initiated.
Misconnection A condition in which traffic destined for a given node is
incorrectly routed to another node and no corrective
action has been taken.
Multiply sourced When traffic on a given time slot is allowed to be sourced
at more than one node. This feature can be used to
support multiple points of access for a circuit.
SONET BLSR Equipment Generic Criteria GR1230CORE
Definitions, Terminology, and Common Phrases Issue 4, December 1998

2-6
Node Failure A node failure refers to those failure conditions which
result in ring switching isolating the node from the rest
of the ring.
Non-adjacent span Any span that does not include the node as an endpoint.
Non-revertive system In non-revertive systems, when the condition that
necessitated a switch to protection no longer exists, the
traffic remains on the protection channels until another
bridge request.
Opposite-side routing In a BLSR, routing of inter-ring traffic where the default
path (i.e., the primary path segment) goes through both
the primary and secondary nodes. (See Figure 7-2.)
Optical Carrier level
1 (OC-1)
The optical signal that results from an optical conversion
of an STS-1 signal.
Optical Carrier level
N (OC-N)
The optical signal that results from an optical conversion
of an STS-N signal.
Pass-through The action of transmitting by a node exactly what is
received by that node for any given direction of
transmission. A pass-through can be unidirectional or
bidirectional. For BLSRs, a pass-through refers to the K1
and the K2 bytes and the protection channels. Three
types of pass-throughs are used in BLSRs: K byte pass-
through, unidirectional full pass-through, and
bidirectional full pass-through.
Path A logical connection between the point at which a
standard frame format for the signal at the given rate is
assembled, and the point at which the standard frame
format for the signal is disassembled.
Path AIS (AIS-P) AIS inserted into the SONET path layers (STS path or
VT path) to allow suppression of downstream alarms in
the event of traffic-affecting failure detected at, or
upstream of, the insertion point.
Pre-empt Take precedence over.
Protection channels The redundant bandwidth allocated to transport the
working traffic subsequent to a bridge affecting the
working channels. Protection channels can also be used
to carry Extra Traffic.
2-7
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Definitions, Terminology, and Common Phrases

Protection switching
counts
The protection switching count parameter contains a
count of the number of times that service on a monitored
line has been switched to the protection line plus the
number of times it has been switched back from the
protection line. This parameter applies to each working
and protection line.
Remote Defect
Indication (RDI)
A signal returned at the first opportunity to a transmitting
equipment when a terminal detects specific defects in the
incoming signal.
Request When used without a modifier, this term is equivalent to
APS request.
Restorable traffic Traffic that may be protected via a ring switch (in 2-fiber
and 4-fiber BLSRs) or a span switch (in a 4-fiber BLSR).
Restoral threshold For automatically initiated switches, a hysteresis method
is used when switching traffic from the protection
channels back to the working channels when a failure or
degradation on a line is cleared. This method specifies a
Bit Error Ratio (BER) threshold for the line that is
carrying the working channels. This threshold is
commonly referred to as restoral threshold. The
restoral threshold is set to a lower BER than the signal
degrade.
Restoration The process of re-establishing traffic continuity in the
event of a failure, or failures, affecting that traffic.
Revertive system In revertive systems, when the condition that
necessitated a switch to protection no longer exists, the
traffic is switched back to the working channels.
Ring interworking A network topology where two rings are connected at
two points, and operate such that a failure at either of
these two points will not cause loss of any traffic, except
possibly the traffic dropped or inserted at the point of
failure.
Ring segmentation When multiple ring switches are performed in response
to multiple protection switch initiations, the original ring
can be divided into two or more smaller rings. If more
than a single pair of ring switches are performed on the
original ring, the ring is said to be segmented. (See
Figure 2-3.)
SONET BLSR Equipment Generic Criteria GR1230CORE
Definitions, Terminology, and Common Phrases Issue 4, December 1998

2-8
Ring switching Protection mechanism that applies to both two-fiber and
four-fiber rings. In a ring, when a tail-end NE detects a
failure or receives a request to switch working channels,
it switches all the working channels that are normally
received from the direction of the failure to the
protection channels away from the failure, and bridges
the outgoing channels in the failure-affected direction to
the protection channels away from the failure. Hence, a
ring switch is a switch where the nodes adjacent to the
failure move the traffic normally sent in the failed
direction on the working channels, to the protection
channels away from the failure. All the nodes on the ring
share the protection channels for ring switching.
Same-side routing In a BLSR, routing of inter-ring traffic where the default
path only goes through the primary nodes. (See Figure 7-
1.)
Secondary circuit The channels between two ring nodes on the same ring
that provide an alternate path segment for protection
traffic when these two nodes are used for interconnection
to another ring. (See Figure 7-2.)
Service circuit The channels between two ring nodes on the same ring
that provide the primary path segment for working traffic
when these two nodes are used for interconnection to
another ring. (See Figure 7-2.)
Service selector A service selector allows a primary interconnecting node
on a BLSR to select either 1) traffic received on the low
speed connections to the other ring, or to a dual-homed
service or 2) traffic received on the high-speed
connection from the secondary interconnecting node on
a BLSR. Figure 2-4 illustrates the use of a service
selector with drop and continue to interconnect two
BLSRs.
Short path The path on the span for which the request is initiated.
This span is always the one to which both the head end
and the tail end are connected. (See Figure 2-2.)
Short path request The bridge request sent over the span for which the
request is initiated.
2-9
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Definitions, Terminology, and Common Phrases

Single point failure Failure located at a single physical point in a ring. The
failure may affect one or more fibers. A single point
failure may be detected by any number of NEs.
Span The set of SONET lines between two adjacent nodes on
a ring.
Span switching In a 4-fiber BLSR, the working and protection channels
are carried over different lines. Thus, a 4-fiber ring may
allow protection similar to 1:1 point-to-point protection
switching on individual spans. (Refer to GR253CORE
for the definition of 1:1 protection switching.) For
failures that affect only the working channels (e.g., a
single fiber cut), the restoration can be performed by
switching the working channels to a different line
carrying protection channels on the same span.
Hereafter, when used in context with ring architectures,
this type of switching is called span switching to avoid
confusion. The actual protocol for span switching is part
of the BLSR protocol and differs from the protocol used
in point-to-point APS systems. (GR253CORE defines
the protocol used in linear APS.) Span switching is not
applicable for 2-fiber BLSRs.
Squelching traffic Replacing traffic by the appropriate path AIS to prevent
misconnections. STS level squelching occurs only into
and out of the protection channels (i.e., working channels
are never squelched).
STS Path Payload
Defect Indication
(STS PDI-P)
A code in the STS Path Signal Label which is transmitted
downstream to indicate a defect of one or more directly
mapped embedded payloads, such as VTx or DS3 for an
STS-1 signal. For ring interworking applications, PDI
can be used to detect defects in embedded payloads and
as a protection switching criterion.
Survivable network A network that is capable of restoring traffic in the event
of a failure. The degree of survivability is determined by
the network's ability to survive single line failures,
multiple line failures, and equipment failures.
Switch The action of selecting traffic from the protection
channels rather than the working channels or from the
protection channels to the working channels.
SONET BLSR Equipment Generic Criteria GR1230CORE
Definitions, Terminology, and Common Phrases Issue 4, December 1998

2-10

Switch completion
time
The interval from the decision to switch to the
completion of the bridge and switch operation at a
switching node initiating the request.
Switching node A node that either sources a bridge request or receives a
bridge request. A node that is in any of the pass-through
states cannot be a switching node. A switching node also
performs any necessary squelching to prevent
misconnecting of traffic for STS-1 or higher rate paths.
Switching to
protection
The action of selecting traffic (at the tail end) from the
protection channels instead of the working channels.
Synchronous The essential characteristic of time scales or signals such
that their corresponding significant instants occur at
precisely the same average rate.
Synchronous
Transport Signal
level 1 (STS-1)
The basic logical building block signal with a rate of
51.840 Mbit/s.
Tail end The tail end is the optics unit or the NE where the line
overhead is terminated. When a failure occurs on a line,
the tail-end NE detects the failure and requests the
bridge. For bidirectional switching, a node functions as
the head end for the outgoing line and as the tail end for
the incoming line on the failed span.
Virtual tributary
(VT)
A structure designed for transport and switching of sub-
STS-1 payloads.
VT access The termination of a SONET STS Synchronous Payload
Envelope (SPE) for the purpose of adding, dropping, or
cross-connecting any individual VT or VT group.
Working channels The channels over which working traffic is transported
when there are no switch events. An APS system
performs restoration for the working channels only.
Working traffic Traffic traversing a ring normally carried in working
channels, except in the event of a ring or span protection
switch, in which case it is restored on the protection
channels.
2-11
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Definitions, Terminology, and Common Phrases

Figure 2-1. Isolated Node
Figure 2-2. Short and Long Paths
X
1 2
X
X
3
X
Isolated
Node
Case 1
X
1 2
X
3
Case 2
X
1 2
X
3
Case 3
X
X
X
X
X: Failed line
Case 1: Node 2 is notified of failures on both sides.
Case 2: Node 2 detected failures on both sides.
Case 3: Node 2 is notified of failures by Node 3 and detected failures on the
other side.
1 2
X: Failed span
3
X
Long Path Short Path Long Path
SONET BLSR Equipment Generic Criteria GR1230CORE
Definitions, Terminology, and Common Phrases Issue 4, December 1998

2-12
Figure 2-3. Ring Segmentation
1 2
X: Failed span
3 4
8 7 6 5
Ring Switch for failure
between Nodes 6 and 7
Ring Switch for failure
between Nodes 2 and 3
2-13
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Definitions, Terminology, and Common Phrases

Figure 2-4. Service Selector (Interconnection Between Two BLSRs)
SS
BLSR
: Service Selector
SS
BLSR
P
P
S
S
: Primary Node P
: Secondary Node S
: Drop and Continue
SS
SONET BLSR Equipment Generic Criteria GR1230CORE
Definitions, Terminology, and Common Phrases Issue 4, December 1998

2-14
3-1
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Overview of the BLSR Architecture

3. Overview of the BLSR Architecture
A fiber transmission system where a pair of fibers provides duplex transmission is called a
duplex transmission system. Thus, a bidirectional ring is a duplex transmission ring where
both directions of transmission use the same set of nodes under normal conditions.
Unidirectional service can be provided on the BLSR if the duplex transmission is not
assumed. Figure 3-1 illustrates the bidirectional and unidirectional traffic on the BLSR. In
the unidirectional case, traffic goes from node 1 to node 3. In the bidirectional case, traffic
goes from node 1 to node 3, and from node 3 to node 1. While the BLSR APS signaling
protocol and protection switching is bidirectional, squelching rules will reflect the
unidirectional service, since the bidirectional circuit is the combination of two
unidirectional circuits.
Protection is initiated based on line level conditions detected by the NE, such as Loss Of
Signal (LOS) or excessive BER. The K1 and K2 bytes of the SONET overhead on the
protection line are used to transport the protection switch requests to the appropriate nodes
on the ring.
For the 2-fiber ring, protection is provided by reserving some of the bandwidth on each
fiber because neither fiber is dedicated for protection (see R6-61). Switching is performed
by using a form of time slot selection where each working time slot is preassigned (not user-
settable) to a protection time slot in the opposite direction.
For the 4-fiber BLSR, the working and protection channels use separate fibers. Because
the working and protection channels are on separate fibers, a 4-fiber ring is similar to a
Figure 3-1. Traffic Flow Support on a BLSR Ring
3
1
2
Bidirectional Traffic
3
1
2
Unidirectional Traffic
SONET BLSR Equipment Generic Criteria GR1230CORE
Overview of the BLSR Architecture Issue 4, December 1998

3-2
point-to-point system. Sections 3.1 and 3.2 provide architectural descriptions of the 2- and
4-fiber BLSRs, respectively.
3.1 Two-Fiber BLSR Overview
A 2-fiber BLSR includes a set of nodes interconnected by a pair of fibers, possibly
including regenerators and optical amplifiers between nodes. Figure 3-2 is a simplified
illustration of a NE (a node) in a 2-fiber BLSR. To provide the maximum restoration (i.e.,
100% restoration of restorable traffic) for single failures, it is necessary to reserve 50% of
the rings capacity for protection. Thus, a 2-fiber Optical Carrier level N (OC-N) ring
effectively has a span capacity of OC-(N/2).
Protection is provided by using a time slot select function. The head-end NE bridges the
working time slots in the failed direction to the preassigned protection time slots in the
direction away from the failure, and the tail-end NE receives (selects) from the protection
time slots on the side away from the failure. The time slot select function is assumed to be
implemented at the STS-1 level and not at a VT level. Figure 3-3 illustrates a 4-node, 2-
fiber BLSR. The node IDs are not required to be consecutive.
When a failure occurs, the ring switches are performed by the nodes adjacent to the failed
segment. The failed segment may include a span or any number of nodes. For a 2-fiber
BLSR operating at an OC-N rate, time slot numbers 1 through N/2 at the multiplex input
are reserved for working channels. Time slot numbers (N/2)+1 through N at the multiplex
input are reserved for protection channels. Time slot number X of the first fiber is
protected using time slot number X + (N/2) of the second fiber in the opposite direction,
where X is an integer between 1 and (N/2).
To discuss the impact of a ring switch on traffic, it is necessary to assume a traffic pattern.
Figure 3-4 illustrates a 4-node ring with the following assumptions:
The BLSR is operating at OC-48 rate.
Bidirectional traffic is assigned to the first five STS-1s.
Traffic assignments are as shown in Table 3-1. The drop and continue configuration
for STS-1 #5 is configuration (3) in Figure 3-5. Configurations (1) and (2) in Figure
3-5 are provided for information purposes only.
Table 3-1 summarizes the implied topology for these assumptions. Each indicated line is
bidirectional. (Unidirectional traffic is also supported on the BLSR. See Figure 3-21 for an
illustration of unidirectional service.) STS-1 #5 is provisioned as drop and continue at
node 3. Figure 3-5 illustrates the possible drop and continue configurations for STS-1 #5 at
node 3. For the purposes of this document, the assumed configuration for drop and continue
is configuration (3) in Figure 3-5 (i.e., drop and continue used in conjunction with a service
selector for interconnected rings) (See Section 7 for a discussion of ring interconnection
using drop and continue and a service selector).
3-3
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Overview of the BLSR Architecture

Figure 3-2. Simplified Node in a 2-Fiber BLSR
OC-N
TX
Common Unit
(with Ring
Switching
Matrix)
OC-N
RX
OC-N
RX
OC-N
TX
Tributary
Add/Drop
OC-M,
STS-M,
DSn
Synchronization Operations
Timing
Source(s)
RX : Receiver
TX : Transmitter
Operations System Interface
Work Station Interface
(Performance Monitoring, Alarm Infor-
mation, etc.)
SONET BLSR Equipment Generic Criteria GR1230CORE
Overview of the BLSR Architecture Issue 4, December 1998

3-4
Configurations (1) and (2) in Figure 3-5 are provided for the illustration of possible drop
and continue configurations only. Though the drop and continue mode of operation may be
used for broadcast services, in SONET rings it is also used (in conjunction with a service
selector) to facilitate interconnection of traffic between rings (again, see Section 7 for a
discussion of ring interconnection).
In general, the configurations in Figure 3-5 are allowed for the STS-1 #5 provisioned as
drop and continue at node 3.
In Figure 3-5 configuration (1), for the traffic originating at node 2, terminations have to be
provided at nodes 3 and 4. The equipment implications are slightly different from the
traditional bidirectional traffic. For bidirectional traffic, for each time slot that is
terminated, traffic is also inserted. For configuration (1), no traffic is inserted at node 3.
Instead, the same traffic that was inserted at node 2 is sent downstream. Thus, from node
3s perspective, the traffic does not appear as bidirectional. For the traffic originating at
node 4, termination is provided only at node 2. Also, STS-1 #5 is used on two spans. The
capacity must be planned for on the two spans and not just to the first termination location.
In configuration (2), traffic is inserted by both nodes 2 and 4. The intermediate node (node
3) terminates traffic from both fibers but does not insert traffic on either fiber. No service
selector is needed for configuration (2), but two drop ports are needed at node 3.
In configuration (3), the use of drop and continue with a service selector for interconnected
rings is illustrated (see also Figure 2-4, and Section 7 for a detailed discussion). Traffic
inserted at node 2 is dropped at both nodes 3 and 4; these two drops carry the same
information and may serve as diverse routes to another ring (dual-homing). For example,
Figure 3-3. 4-Node, 2-Fiber BLSR
2
3
1
4
x : Node Number x
3-5
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Overview of the BLSR Architecture

Figure 3-4. Traffic Assignment Illustration for a 2-Fiber BLSR
4
1 4 4
5
3
3
1 1
1 2
3
1
5
1
3
3
2
1
2
2
4
4
5
2
1 1
x
x
: Bidirectional High-Speed Time Slot Number
(The numbering of the high-speed time slot has no relationship
with the numbering of the low-speed port numbers)
y : Node Number y
: Drop and Continue - see configuration (3) in Figure 3-5 for the
traffic assignment of STS-1 #5.
SONET BLSR Equipment Generic Criteria GR1230CORE
Overview of the BLSR Architecture Issue 4, December 1998

3-6
the traffic inserted at nodes 3 and 4 may be identical copies of the same traffic dropped from
another ring (using drop and continue), just as nodes 3 and 4 drop identical traffic (see
Figure 2-4). The service selector would then have two copies of the traffic being fed from
the other ring (over diverse routes) from which to choose should a failure occur on one of
the feeds from the other ring. This method for interconnecting rings is introduced here
but discussed in more detail in Section 7. For the purposes of this document, the drop and
continue configuration assumed for STS-1 #5 of Table 3-1 and Figure 3-4 is configuration
(3).
Figure 3-6 illustrates the ring switch for a four-node, 2-fiber, OC-48 BLSR.
If a unidirectional line degradation occurs between nodes 3 and 4, the following actions
occur:
Table 3-1. Traffic Assignments on a 2-Fiber BLSR
1
Number
Node ID
2 3 4 1
1
2
3
4
5
6-24
25-48
Unassigned
Protection
a b
Bidirectional traffic added and dropped at nodes a and b.
Drop and continue at node b [see possible configurations of
the drop and continue in Figure 3-5; the drop and continue configuration
assumed in this example is Figure 3-5, configuration (3)].
STS
b
West East
3-7
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Overview of the BLSR Architecture

A. Node 3 transmits a ring bridge request to node 4. See W in Figure 3-6. The request
is transmitted on the K1 and K2 bytes in both directions according to the criteria in
Section 6.
B. Upon receiving the bridge request from node 3 on the short path, node 4 starts
transmitting a reverse request on the short path and a request of equal priority to the
request received on the long path.
C. Nodes 1 and 2 pass through the APS bytes and the protection channels (see X in
Figure 3-6) because the request and response are not addressed to them.
D. Upon receiving the ring bridge request from node 3 on the long path, node 4 bridges
STS-1s #1-24 of the failed span to STS-1s #25-48 of the outer ring (away from the
failure) along with the bridged indication addressed to node 3. See Y in Figure 3-6.
E. Upon receiving the ring bridge request from node 4 on the long path, node 3 also
bridges and sends the bridged indication to node 4.
Figure 3-5. Dropped and Continued Paths
: Service Selector
(1)
3 4 2
(2)
(3)
SS
4
2
3 4 2
x
: Node Number x
3
4
: See Section 7 for a discussion of ring interconnection
using drop and continue with a service selector.
Note
SS
: Drop & Continue
SONET BLSR Equipment Generic Criteria GR1230CORE
Overview of the BLSR Architecture Issue 4, December 1998

3-8
Figure 3-6. Ring Switching for a Unidirectional Degradation on a 2-Fiber BLSR
x : Node Number x
: Protection Time Slot Route When In Pass-Through And Service Time Slots
: Protection Time Slot Route When Terminated
PT : Protection Time Slot When Terminated (including idle condition)
S : Service Time Slot - As Assigned In Figure 3-4
Y-Z : Time Slot number y through z
T : Tributary When Provisioned In Add/Drop For The Time Slot
A : Action A as described in text.
1-48
1-48
T
4 3
1 2
PT
1-48
1-24
25-48
PT
1-24
25-48
S T
1-24 25-48
1-24 25-48
PT
S
T
1-48
1-48
25-48
1-24
PT
S
T
25-48
1-24
PT
S
T
25-48
1-24
1-48
1-48
25-48 1-24 25-48 1-24
S
T
PT
T
1-24
25-48
25-48
1-24
1-24 25-48 1-24 25-48
S
T
PT
1-24
25-48
1-24 25-48
S S
1-24 25-48
Y
W
Z
X
X
PT 1-48
3-9
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Overview of the BLSR Architecture

F. Upon receiving the bridged status indication from node 4 on the long path, node 3
performs the reverse process (i.e., selects the traffic in STS-1s #25-48 of the outer ring
instead of STS-1s #1-24 of the inner ring). See Z in Figure 3-6.
G. Upon receiving the bridged status indication from node 3 on the long path, node 4 also
selects the traffic from the protection channels.
The protection is done for both directions of transmission [see R6-66]. For simplicity, only
the ring switch for the traffic from node 4 to node 3 is indicated in Figure 3-6. The
symmetric procedure is used for the traffic from node 3 to node 4.
During ring switching, traffic may travel a considerably longer route. For example, in the
described failure scenario, if the traffic pattern of Table 3-1 is assumed, the traffic
provisioned on STS-1 #3, which normally traverses three spans, traverses five spans during
protection switching. Also, because the failure is unidirectional, the far end does not know
about the failure and cannot initiate switching activity until notified. This implies that a
bidirectional failure (e.g., a cable cut) may take less time to restore than a unidirectional
failure.
If a bidirectional span failure (e.g., a cable cut) occurs, both nodes detecting the LOS
initiate a ring bridge request destined to the respective head-end NEs. The intermediate
nodes, on seeing a ring bridge request not addressed to themselves, enter the appropriate
pass-through mode (see Section 6.2). In general, the crossing K bytes and the bridged (and
switched) status indications in the K2 byte are used for confirmation. In some cases, the
crossing K bytes are adequate to start bridging and/or switching. The requirement depends
on the priority level of the request [see R6-125]. The nodes to which the requests were
addressed then perform ring switches and transmit responses according to the K1 and K2
protocol given in Section 6. Because both directions of transmission are switched even for
a unidirectional failure, the state of the ring after protection switching is completed is the
same for both unidirectional and bidirectional failures. The intermediate nodes continue to
terminate and insert traffic on the working channels.
So far, this section has discussed failures that affect only a single span. One of the
advantages of the ring architecture is its ability to survive node failures. Figure 3-7
illustrates a node failure on a 2-fiber BLSR.
In Figure 3-7, the adjacent nodes, 2 and 4, detect the failure. Traffic that was provisioned
to pass through the failed node is fully restorable. Traffic that was terminated or inserted at
the failed node cannot be protected by performing a ring switch. However, if traffic was
already in the drop and continue mode, the other nodes can still receive the traffic after the
ring switch. For example, suppose that traffic inserted at node 2 was dropped and continued
at node 1, and finally terminated at node 4. Node 4 would still receive the traffic from node
2 after the ring switch. This feature is useful for implementing BLSRs in dual-homed
architectures, as Section 7 describes.
The issues arising from the node failure mainly involve the channels that were being
sourced or terminated at the failed node. When the intermediate nodes are in protection
channel pass-through mode, the nodes adjacent to the failed node are directly
SONET BLSR Equipment Generic Criteria GR1230CORE
Overview of the BLSR Architecture Issue 4, December 1998

3-10
communicating. Thus, squelching occurs during node failures to avoid misconnection of
traffic at other nodes.
For the traffic pattern Table 3-1 and Figure 3-4 shows, STS-1s #1-3 are terminated, and new
traffic is inserted at node 1. If a failure occurs at node 1, the following require squelching
for the reasons provided:
On STS-1 #1, the traffic from node 4 to node 1 may be terminated at node 2 because
node 4 bridges STS-1 #1 onto STS-1 #25 away from the failure, and node 2 performs
the reverse process as Figure 3-8 indicates.
On STS-1 #1, the traffic from node 2 to node 1 may be terminated at node 4 because
node 2 bridges STS-1 #1 onto STS-1 #25 away from the failure, and node 4 performs
the reverse process as Figure 3-9 indicates.
On STS-1 #2, the traffic from node 3 to node 1 may be terminated at node 3 because
nodes 4 and 2 bridge STS-1 #2 onto STS-1 #26 as Figure 3-10 indicates.
On STS-1 #3, the traffic from node 4 to node 1 may be terminated at node 4 because
nodes 4 and 2 bridge STS-1 #3 onto STS-1 #27 as Figure 3-11 indicates.
When traffic is squelched, SONET STS path layer Alarm Indication Signal (AIS-P) is
inserted. The squelching is done by the nodes performing the ring switching. To perform
the squelching, the node has to identify the portion of the ring that is isolated. Figure 3-12
illustrates a cable cut that isolates two nodes from the rest of the ring. Because the ring
switches are done by the nodes that are not normally contiguous, the missing portion has to
Figure 3-7. Node Failure on a 2-Fiber BLSR
4 3
1 2
x
: Node Number x
3-11
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Overview of the BLSR Architecture

Figure 3-8. Misconnection for STS-1 #1 for Traffic from Node 4 to Node 1
4 3
1 2
STS-1 #1
STS-1 #1
STS-1 #1 STS-1 #1
STS-1 #1 STS-1 #1
STS-1 #25
STS-1 #25
STS-1 #25
STS-1 #25
STS-1 #1
STS-1 #1
x : Node Number x
x
x
: High Speed Time Slot Number
SONET BLSR Equipment Generic Criteria GR1230CORE
Overview of the BLSR Architecture Issue 4, December 1998

3-12
Figure 3-9. Misconnection for STS-1 #1 for Traffic from Node 2 to Node 1
4
3
1 2
STS-1 #1
STS-1 #1
STS-1 #1
STS-1 #1
STS-1 #1 STS-1 #1
STS-1 #25
STS-1 #25
STS-1 #25
STS-1 #1
STS-1 #1
STS-1 #25
x : Node Number x
x
x
: High Speed Time Slot Number
3-13
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Overview of the BLSR Architecture

Figure 3-10. Misconnection for STS-1 #2 for Traffic from Node 3 to Node 1
4
3
1
2
STS-1 #2
STS-1 #2
STS-1 #26
STS-1 #26
STS-1 #2
STS-1 #2
STS-1 #2
STS-1 #2
STS-1 #2
STS-1 #2
x : Node Number x
x
x
: High Speed Time Slot Number
SONET BLSR Equipment Generic Criteria GR1230CORE
Overview of the BLSR Architecture Issue 4, December 1998

3-14
Figure 3-11. Misconnection for STS-1 #3 for Traffic from Node 4 to Node 1
4 3
1
2
STS-1 #3
STS-1 #27
STS-1 #27
STS-1 #3
STS-1 #3
STS-1 #3
STS-1 #3
STS-1 #3
STS-1 #3
STS-1 #3
STS-1 #27
STS-1 #27
STS-1 #27
x : Node Number x
x
x
: High Speed Time Slot Number
3-15
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Overview of the BLSR Architecture

be clearly identified. Only the channels that were terminated at the isolated nodes have to
be squelched. Thus, the switching nodes identify the channels that may be misconnected,
and insert AIS-P only in those channels. A ring map is needed at each node. The map
includes the order of the nodes (the order of physical connectivity) on the ring. A squelch
table that provides the source and destination nodes for each channel (added, dropped, or
continued through) and that identifies the channels that are accessed on VT levels, should
also be provided (see Section 6 requirements for VT-squelching).
When the missing node(s) is identified, AIS-P is inserted instead of the traffic destined to
the failed node and/or the traffic expected from the failed node. For signal failures, AIS was
already being inserted until the protection switching could be performed (see Section
6.2.1.2.2 of GR253CORE). Hence, the AIS insertion is continued for some channels that
are being squelched. This includes the channels that are passed-through. For other
requirements regarding misconnection of traffic, refer to Section 6.
A node failure has the same impact on traffic as two cable cuts on adjacent spans. If two
cables are cut on a ring, some nodes will become isolated. Squelching similar to that
performed for a single node failure is performed for multiple failures. Thus, the protocol
that provides a mechanism for squelching addresses the issues of multiple failures, whether
the failures are cable cuts or node failures.
Squelching can also be necessary due to pre-existing traffic on the protection channels. The
squelching for extra traffic is similar to the squelching done for pre-existing span switches
on the 4-fiber rings. Section 3.2 provides the method of squelching for pre-existing traffic
Figure 3-12. Isolation of Two Nodes by a Cable Cut
4
1
3
2
6 5
x : Node Number x
SONET BLSR Equipment Generic Criteria GR1230CORE
Overview of the BLSR Architecture Issue 4, December 1998

3-16
on the protection channels for both extra traffic and span-switched traffic. Section 3.4
provides a failure scenario in which extra traffic is squelched.
3.2 Four-Fiber BLSR Overview
A 4-fiber BLSR consists of a set of nodes interconnected with two pairs of fibers (four
fibers), possibly including regenerators and optical amplifiers, to form a closed loop. Two
fibers are used to carry working channels, and the other two are used to carry protection
channels. A 4-fiber BLSR operating at an OC-N rate has a span capacity of OC-N, as
opposed to OC-(N/2) for the 2-fiber BLSR, but it also has more electronics. Figure 3-13
illustrates a NE in a 4-fiber BLSR.
In a 4-fiber BLSR, the working and protection channels are carried over different physical
lines (fibers). Figure 3-14 illustrates a 4-node, 4-fiber BLSR. If a failure affects only the
working channels, protection similar to that of the point-to-point system can be performed
to restore traffic. A restoration using the ring switch is needed only if both the protection
and the working channels on the same span are affected by the failure(s). If the ring bridge
request is initiated, the working channels from the failed span are bridged to the protection
channels (away from the failure) by the nodes adjacent to the failed segment. As with the
2-fiber BLSR, a failed segment may include a span or any number of nodes.
The provisioning for a 4-fiber BLSR is similar to that of a 2-fiber BLSR, except that all N
time slots at the multiplex input are provisioned for either working or protection channels.
The correspondence between the protection and working channels is also simpler (time slot
number X on the working line is protected by using time slot number X on the
protection line).
The nature of protection switching on a 4-fiber BLSR may or may not be the same as on a
2-fiber BLSR, depending on the type of failure. The difference is in a 4-fiber ring, two
types of protection switching mechanisms are used. The ring switch, which is the only
switching mechanism available for the 2-fiber BLSR, is used for the 4-fiber BLSR only if
restoration is not possible using the span-switching method.
For example, if a unidirectional span failure that affects only the working channels occurs
between nodes 3 and 4, as Figure 3-15 indicates, node 3 detects the failure and initiates a
request for protection. The request is transmitted to node 4 on the short and long paths.
Short path signaling is used even if the failure is on the protection channel. If the outgoing
protection line (from node 3 to node 4) is also affected, the request cannot be received by
node 4. The long path signaling is needed to complete a ring switch.
Signaling on both the short and the long paths may shorten the switch completion time for
some failure scenarios. In general, the request sent on the long path takes more time to be
received because of the processing delay at the intermediate nodes. Therefore, protection
for a unidirectional failure will most likely involve only the request transmitted on the short
path. (The request on the long path may be received first if the nodes adjacent to the failure
3-17
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Overview of the BLSR Architecture

Figure 3-13. Simplified Node in a 4-Fiber BLSR
Synchronization Operations
Timing
Source(s)
Pl : Protection line
RX : Receiver
Wl : Working line
TX : Transmitter
OC-N
TX
OC-N
RX
OC-N
RX
OC-N
TX
Pl
OC-N
TX
OC-N
RX
OC-N
RX
OC-N
TX
Wl
Pl
Wl
Operations System Interface
Work Station Interface
(Performance Monitoring, Alarm Infor-
mation, etc.)
Tributary
Add/Drop
OC-M,
STS-M,
DSn
Common Unit
(with Ring
Switching
Matrix)
SONET BLSR Equipment Generic Criteria GR1230CORE
Overview of the BLSR Architecture Issue 4, December 1998

3-18
use several regenerators on the short path.) Span switching is completed based on the
request transmitted on the short path [see R6-126]. If the span switch cannot be performed,
a ring switch request is initiated [see R6-151]. The long path signaling informs other nodes
that a span switch exists elsewhere in the ring.
For the single unidirectional span failure case in Figure 3-15, when node 4 receives the
request from node 3, it bridges the failed working line onto the protection line on the same
span. It then transmits the reverse request for the span switch with the bridged status
indication on the short path and the actual priority of the request with the bridged status
indication on the long path. Node 3 receives the reverse request, performs the switch,
bridges the outgoing line onto the protection line in response to the reverse request, and
Figure 3-14. 4-Node, 4-Fiber BLSR
Pl : Protection line
Wl : Working line
4
1
3
2
Pl
Wl
Pl
Wl
Wl
Pl
Wl
Pl
x : Node Number x
: Fiberline
: Traffic Assignment (Path)
3-19
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Overview of the BLSR Architecture

transmits the bridged and switched status indication on both paths. Node 4 receives the
indication on the short path and completes the switch.
For the single unidirectional failure case, the impact on the traffic involves only the failed
span. The procedure just described is identical to that of the point-to-point protection
switching system. Thus, unlike the 2-fiber BLSR, the 4-fiber BLSR simply uses the
protection fibers on the same span for this type of failure. Multiple unidirectional failures
on both working and protection lines of the same span will require a ring switch.
If a bidirectional span failure that affects only the working lines occurs, both nodes detect
the failure and initiate requests. Because all the protection switching is done bidirectionally,
even for a unidirectional failure [see R6-66], the result is identical to that of the
unidirectional failure case. The only difference is that, instead of the reverse request code
being transmitted by one of the NEs, both nodes are transmitting identical switch requests.
The result is identical because the K1 and K2 byte protocol includes identifying the failure
Figure 3-15. Unidirectional Span Failure on a 4-Fiber BLSR
4
1 3
2
Pl
Wl
Pl
Wl
Wl
Pl
Wl
Pl
Pl : Protection line
Wl : Working line
x : Node Number x
SONET BLSR Equipment Generic Criteria GR1230CORE
Overview of the BLSR Architecture Issue 4, December 1998

3-20
scenarios that can be protected against using only a span switch. If the span switch cannot
be completed, a ring switch similar to the one used for the 2-fiber case will be performed.
If a unidirectional or a bidirectional failure that affects both the working and protection
lines on the same span is detected, a span switch cannot be used to restore traffic. Thus, the
ring switch must be used. Figure 3-16 illustrates a cable cut on a 4-fiber BLSR.
For the failure scenario Figure 3-16 depicts, nodes 3 and 4 initiate the ring bridge requests,
and nodes 1 and 2 pass through the requests. When the crossing K bytes are received by
nodes 3 and 4, nodes 3 and 4 perform the bridge and the switch. Figure 3-17 illustrates the
completed switch. The intermediate nodes continue to terminate and insert traffic on the
working channels. The bridging to protection and the selection from protection are
performed by the nodes adjacent to the failed segment. The intermediate nodes do not
terminate traffic from the protection channels when operating in the pass-through mode.
The protection switching procedure for node failures is similar to that of cable cuts, except
that the ring switch may isolate some nodes. As described for the 2-fiber BLSR, squelching
Figure 3-16. Cable Cut on a 4-Fiber BLSR
Pl : Protection line
Wl : Working line
4
1 3
2
Pl
Wl
Pl
Wl
Wl
Pl
Wl
Pl
x : Node Number x
3-21
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Overview of the BLSR Architecture

of traffic may be needed if a node is isolated. The squelching is handled as described for
the 2-fiber BLSR.
Section 3.1 describes the squelching associated with node failures, which also applies to the
4-fiber BLSR. However, insertion of STS path AIS can also be used for other failure types.
If a span switch pre-empts a ring switch, the nodes that send the span bridge requests insert
STS path AIS on all protection channels other than those on the requested span. The
insertion of STS path AIS deterministically prevents misconnection of traffic. Similarly, if
a ring switch pre-empts a span switch, the span switch is dropped before the bridging is
done for the ring switch.
Figure 3-18 illustrates a span switch for a signal degrade between nodes 2 and 3 at time 1
and a cable cut between nodes 3 and 4 at time 2. Node 3 performs the ring bridge after the
Figure 3-17. Restoration for a Cable Cut on a 4-Fiber BLSR
Pl : Protection line
1
Pl
Wl
Pl
Wl
Wl
Pl
Wl
Pl
2
4
3
T
R
R
T
Receive from protection line
: Transmit on protection line
T R
x : Node Number x
Wl : Working line
SONET BLSR Equipment Generic Criteria GR1230CORE
Overview of the BLSR Architecture Issue 4, December 1998

3-22
existing span switch is dropped between nodes 2 and 3. Therefore, the traffic bridged by
node 3 is not misconnected at node 2. Figure 3-19 illustrates the misconnection that would
occur if node 3 performed a ring bridge before the existing span switch between nodes 2
and 3 was dropped. The protocol in Section 6 deterministically prevents this type of
misconnection.
The squelching for extra traffic is similar except that it applies to both 2- and 4-fiber
BLSRs. The nodes that either have a span switch (nodes 2 and 3 in the example) or extra
traffic are prevented from going into the full pass-through state until the span switch is
dropped [see R6-156], and VT-access and/or extra traffic are squelched.
The scenarios described thus far for the 4-fiber BLSR are similar to that of the 2-fiber
BLSR. One of the differences between the 2- and 4-fiber BLSRs is that multiple span
Figure 3-18. Cable Cut and a Span Switch on a 4-Fiber BLSR (Before a Ring
Switch)
Pl : Protection line
Wl : Working line
x : Node Number x
4
1 3
2
Pl
Wl
Pl
Wl
Wl
Pl
Wl
Pl
Signal Degrade
(Time 1)
Signal Failure
(Time 2)
3-23
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Overview of the BLSR Architecture

switches can be performed in the 4-fiber BLSR. Thus, if a set of failures affects only the
working channels on multiple spans, the traffic on each span can be restored independently.
The limitation of protection bandwidth exists only if a ring switch is needed for any of the
spans. If the protection and working channels used physically diversified (e.g., use different
routes or cables) lines, the ring switch is used only if a node failure or multiple cable cuts
are detected. If the protection and service channels are not using physically diversified
lines, the span switching is used for equipment failures and single fiber cuts only; for cable
cuts, the ring switch is needed.
3.3 VT-Access Overview
Some nodes on the ring, referred to as VT-access nodes, may be capable of inserting,
dropping, or passing through VTs from the STSs. When multiple nodes on the ring add VTs
or pass-through VTs between STSs, the payload for a given STS may have multiple source
Figure 3-19. Misconnection of Traffic Related to Existing Switches
4
1
3
2
Pl
Wl
Pl
Wl
Wl
Pl
Wl
Pl
T R
Pl : Protection line
Wl : Working line
x : Node Number x
SONET BLSR Equipment Generic Criteria GR1230CORE
Overview of the BLSR Architecture Issue 4, December 1998

3-24
nodes or be dropped among multiple nodes. Such STSs are referred to as VT-accessed
STSs. Each VT-accessed STS-1 SPE is divided into seven VT groups, each of which
contains 4 VT1.5s, 3 VT2s, 2 VT3s, or 1 VT6. See GR253CORE for a detailed
description of VT-structured STSs. A VT-accessed node will be able to add, drop, and/or
pass-through individual VTs within a VT-accessed STS-1 SPE.
The discussions for 2- and 4-fiber BLSRs during normal traffic and certain failure
conditions are applicable to VT-access nodes. For single or multiple failures that do not
require squelching of working traffic, failure recovery conditions are identical to non VT-
access rings. For service-affecting failures that require squelching of traffic, VT-access
nodes handle recovery differently.
Each VT-access node on the ring will maintain VT squelch table information that includes,
at a minimum, the source node ID for each VT timeslot that the node is dropping [see CR6-
50]. For multiply-sourced VTs (e.g., VTs involved in ring interworking [see Figure 3-22]),
the VT squelch information will include the source node IDs of both primary and secondary
source nodes for each VT timeslot that the node is dropping. This information allows
squelching of traffic in case of node failures or node isolation.
Whereas the STS-level squelching is performed at the ring switching nodes, VT-level
squelching will be performed at the node dropping the VT from the ring (i.e., only at VT-
access nodes). Squelching VT-accessed STSs at the ring switching nodes that do not have
VT-access capability is undesirable because each VT-accessed STS contains individual
VTs sourced from (and destined to) different nodes. Squelching the entire VT-accessed
STS will squelch VTs from nodes that are not affected by the failure (i.e., restorable VTs
would be squelched).
VT-access nodes performing VT-level squelching may be in either the switching state or
the pass-through state. For multiply sourced VTs, squelching will be performed when all
source nodes are missing. Nodes in the switching state shall squelch and unsquelch VT-
accessed STSs in the following manner:
The switching node will identify which nodes are missing by comparing K-byte
addresses to the information contained in the ring map. From this information and the
squelch table information, the switching node will squelch all STSs added and/or
dropped at the missing nodes.
Switching nodes with VT-accessed STSs on a ring without coexisting ring switches
will unsquelch all VT-accessed STSs upon receiving the Bridged and Switched
indication, in byte K2 bits 6-8, from the far-end switching node. Switching nodes with
VT-accessed STSs on a ring with another coexisting ring switch (e.g., multiple
failures) will wait 100 ms prior to subsequently unsquelching the VT-accessed STSs
that had been squelched. This allows the VT-access NEs to squelch their VTs prior to
unsquelching of the VT-accessed STSs by the switching nodes. The waiting period is
required since the Bridged and Switched indication may have already been received
in the case of coexisting ring switches.
3-25
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Overview of the BLSR Architecture

Switching nodes that support VT-access will squelch VTs that are sourced from the missing
node and dropped at the switching nodes. VT-access nodes that are in pass-through state
will perform VT-level squelching in the following manner:
The node will first enter unidirectional full pass-through in the direction of the request.
Upon receiving the crossing K-bytes, the node will determine whether any VTs
require squelching, and will squelch accordingly. After completion of VT squelching,
the node will then enter bidirectional full pass-through.
Figures 3-20, 3-21, and 3-22 illustrate the additional data required at the VT-access nodes
to support squelching at the VT level. Nodes 2, 3, and 4 are part of a 4-node BLSR ring as
shown in Figure 3-4. Figures 3-20 and 3-21 assume the STS traffic pattern of Table 3-1 and
Figure 3-4, with the exception that STS-1 channels one and four are VT-access, and STS-
1 channel 4 is unidirectional. Figure 3-20 illustrates bidirectional traffic on the BLSR.
Figure 3-21 illustrates unidirectional traffic on the BLSR. Figure 3-22 illustrates
bidirectional traffic for nodes with ring interworking capability.
In Figure 3-20, STS-1 #1 is VT-access. A VT in VT group 1, channel 1 is added/dropped
at node 2, continued through at node 3, and added/dropped at node 4. Assume that a VT-
level cross-connection is used to continue through the VTs at node 3. In this example, nodes
2, 3, and 4 are VT-access. The VT-level squelch table at node 2 contains the source node
ID of the dropped VT, in this case node 4. The VT-level squelch table at node 4 contains
the source node ID of the dropped VT, in this case node 2. Node 3 has no entry for the VT
squelch table because no VTs are dropped at that node.
If node 2 fails, then the two adjacent nodes, node 1 and node 3, will transition to switching
state and squelch all traffic destined to, or sourced from, node 2. After completion of the
bridge and switch, nodes 1 and 3 will unsquelch all VT-accessed STSs, which in this case
is STS-1 #1. Squelching of VTs affected by the failure is handled by node 4, which drops
the VT sourced at node 2.
In Figure 3-21, STS-1 #4 is VT-access. A VT in VT group 1, channel 1 is added at node 2,
and dropped at node 4. This illustrates the support of unidirectional service on a BLSR ring.
In this example, only nodes 2 and 4 are VT-access. Node 3 passes through all traffic coming
from node 2. The VT squelch table at node 4 contains the source node ID of the dropped
VT, in this case node 2. Nodes 2 and 3 have no entry for the VT squelch table.
If node 2 fails, then the two adjacent nodes, node 1 and node 3, will transition to switching
state and squelch all traffic sourced from node 2. After completion of the bridge and switch,
nodes 1 and 3 unsquelch all VT-accessed STSs, which in this case is STS-1 #4. Squelching
of the VTs is handled by node 4.
In Figure 3-22, STS-1 #1 is VT-access. A VT in VT group 3, channel 2 is added/dropped
at node 2, and added/dropped at node 4. Node 3 selects traffic from either node 2 or the low-
speed add using the service selector. Drop and continue provides broadcast from node 4 to
both nodes 2 and 3. In this example, nodes 2, 3 and 4 are VT-access. The VT squelch table
at nodes 2 and 3 contains the source node ID of the dropped VT, in this case node 4. The
SONET BLSR Equipment Generic Criteria GR1230CORE
Overview of the BLSR Architecture Issue 4, December 1998

3-26
Node 2
STS-1
#
West East
Outgoing Incoming Outgoing Incoming
Dst VT Src VT Dst VT Src VT
1 3 3 VT
Grp/Chan
West East
Src Src
Node 3 1 1 4
STS-1
#
West East
Outgoing Incoming Outgoing Incoming
Dst VT Src VT Dst VT Src VT
1 2 2 4 4
Node 4
STS-1
#
West East
Outgoing Incoming Outgoing Incoming
Dst VT Src VT Dst VT Src VT
1 3 3 VT
Grp/Chan
West East
Src Src
1 1 2
Figure 3-20. VT Squelch Table Example (Bidirectional Traffic) All Nodes VT-
access
Node 2 Node 3
Node 4
West East
STS Path
(STS-1 #1)
STS Path
(STS-1 #1)
VT Path
(VT Group #1 Channel #1 on STS-1 #1)
3-27
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Overview of the BLSR Architecture

Node 2
STS-1 # West East
Outgoing Incoming Outgoing Incoming
Dst VT Src VT Dst VT Src VT
4 4
Node 3
STS-1 # West East
Outgoing Incoming Outgoing Incoming
Dst VT Src VT Dst VT Src VT
4 2 4
Node 4
STS-1 # West East
Outgoing Incoming Outgoing Incoming
Dst VT Src VT Dst VT Src VT
4 2 VT
Grp/Chan
West East
Src Src
1 1 2
Figure 3-21. VT Squelch Table Example (Unidirectional Traffic) Not All Nodes
VT-access
Node 2 Node 3
Node 4
West East
VT Path
(VT Group #1 Channel #1 on STS-1 #4)
STS Path
(STS-1 #4)
SONET BLSR Equipment Generic Criteria GR1230CORE
Overview of the BLSR Architecture Issue 4, December 1998

3-28
VT-level squelch table at node 4 contains two source node IDs, both the primary node
(node 3) and the secondary node (node 2). VTs dropped at node 4 will not be squelched
unless both the primary and the secondary nodes have failed or have been isolated.
If node 2 fails, then the two adjacent nodes, nodes 1 and 3, will transition to the switching
state and squelch all STS traffic destined to, or sourced from, node 2, and perform the
bridge and switch function. After completion of the bridge and switch, VT-accessed STSs
will be unsquelched. The service selector will select between the high-speed and low-speed
lines that are least impacted by the failure. In this case, the low-speed (interconnecting) line
will be selected. Node 4 will not squelch the VTs it dropped because only node 2 failed.
Node 4 will squelch the VTs that it drops only when both nodes 2 and 3 fail.
3-29
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Overview of the BLSR Architecture

Node 2
STS-1 # West East
Outgoing Incoming Outgoing Incoming
Dst VT Src VT Dst VT Src VT
1 3 3 VT
Grp/Chan
West East
Src Src
Node 3 3 2 4
STS-1 # West East
Outgoing Incoming Outgoing Incoming
Dst VT Src VT Dst VT Src VT
1 2 2 4 4 VT
Grp/Chan
West East
Src Src
Node 4 3 2 4
STS-1 # West East
Outgoing Incoming Outgoing Incoming
Dst VT Src VT Dst VT Src VT
1 3 3 VT
Grp/Chan
West East
Src Src
3 2 2,3
Figure 3-22. VT Squelch Table Example (Inter-Ring Capability) All Nodes VT-
access
Node 2 Node 3
Node 4
West East
STS Path
(STS-1 #1)
STS Path
(STS-1 #1)
VT Path
(VT Group #3 Channel #2 on STS-1 #1)
SS
SS
Service Selector Drop and Continue
SONET BLSR Equipment Generic Criteria GR1230CORE
Overview of the BLSR Architecture Issue 4, December 1998

3-30
3.4 Extra Traffic Overview
During fault-free conditions, it is possible to use the protection channels to carry additional
working traffic. This additional traffic, which is referred to as extra traffic, has lower
priority than the traffic on the working channels and has no means for protection. The extra
traffic is set up by provisioning the add and drop nodes for the traffic. Intermediate nodes
along the ring are provisioned so that the protection channel STS-1s carrying extra traffic
are passed through the node. (Protection channels that are not carrying extra traffic are
terminated at the intermediate nodes.) Timeslot assignment of extra traffic on the protection
channel will be supported.
For rings that support extra traffic, extra traffic is allowed on both sides of the node. An
extra traffic STS will be able to enter the ring at any node, and to exit the ring at any node.
Nodes that are inserting, dropping, or passing through extra traffic indicate its presence on
those spans by inserting the Extra Traffic code in byte K2 bits 6-8. Note that extra traffic
has the lowest priority level, and will be pre-empted by any working traffic that requires the
use of the protection channels. The transmission of either Idle or Bridged code in byte K2
bits 6-8 is an indication that extra traffic has been removed.
When a request of higher priority than the No Request priority is received by the node, and
only if that request is a ring request, or requires the usage of the protection channels
carrying the extra traffic, extra traffic is pre-empted and squelched on the spans whose
protection channels are required for the protection switch. When the affected nodes return
to the Idle, K-byte pass-through, or span switching state, extra traffic (on spans whose
protection channels are not used for protection purposes) is restored. For Exerciser request,
extra traffic is allowed to exist on the protection channels. Extra traffic is also allowed on
Locked-out spans.
3.4.1 Squelching to Avoid Misconnected Traffic
In order to perform a ring switch, the protection channels are essentially shared among each
span of the ring. Also, extra traffic may reside in the protection channels when the
protection channels are not currently being used to restore working traffic transported on
the working channels. With no extra traffic on the ring, under certain multiple point
failures, such as those that cause node isolation, services (from the same time slot but on
different spans) may contend for access to the same protection channel time slot. This
situation yields a potential for misconnected traffic. With extra traffic on the ring, even
under single point failures, a service on the working channels may contend for access to the
same protection channel time slot that carries extra traffic. This situation also yields a
potential for misconnected traffic.
Without a mechanism to prevent misconnection, the following two failure scenarios would
yield misconnections. First, using the example of Figure 3-23, a cut on the span between
Nodes 1 and 2 causes Circuit Q to attempt to access time slot #1P of the protection channel,
3-31
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Overview of the BLSR Architecture

where Circuit P resides. Second, again referring to Figure 3-23, a cut in both the spans
between Nodes 1 and 6 and between Nodes 1 and 2 (isolating Node 1) causes Circuits Q
and R to attempt to access time slot #1P on the protection channel, where Circuit P resides.
Figure 3-23. Example of Potential for Misconnection
NOTE Under the Time Slot Assignment column, the designation
1W indicates that it is the first time slot in the capacity reserved for
working traffic and the designation 1P indicates that it is the first time
slot in the capacity reserved for protection. In the case for two-fiber
rings, the actual time slot in the Synchronous Payload Envelope will
not correspond with these designations.
Protection Channels
Working Channels
Node 1
Node 2
Node 3
Node 4
Node 5
Node 6
Circuit P
Circuit R
Circuit Q
Circuit Time Slot Assignment Channel
Q 1W Working
R 1W Working
P 1P Protection
Circuit Transporting Service
SONET BLSR Equipment Generic Criteria GR1230CORE
Overview of the BLSR Architecture Issue 4, December 1998

3-32
Information contained in the ring map and squelch table will be used to prevent any
misconnection of working traffic that arises from either node failures or node isolation, as
described earlier.
In order to prevent misconnection of extra traffic, the bridge or switch operations are not
executed until the switching nodes see that the Extra Traffic code is removed from the spans
required for the protection switch. Extra traffic will not be dropped on spans which are not
using its protection channel, when span switches are active. K-byte pass-through nodes will
also be allowed to carry extra traffic.
Pre-emption of extra traffic on the protection channel requires that the extra traffic be
squelched in order to prevent potential misconnections. Squelching of extra traffic for
nodes in the span switching, ring switching, or full pass-through state are handled
differently.
Squelching of extra traffic for a node executing a span switch that pre-empts extra traffic
on that span is accomplished by inserting STS path AIS on extra traffic channels from that
span that are dropped at that node (i.e., on the low-speed side), and inserting STS path AIS
on extra traffic channels from that span that pass-through the node (i.e., on the high-speed
side), as long as those protection channels are not required for a protection switch.
Squelching of extra traffic for a node executing a ring switch that pre-empts extra traffic on
that span is accomplished by inserting STS path AIS on extra traffic channels that are
dropped at that node (i.e., on the low-speed side).
Squelching of extra traffic for a node entering full pass-through is accomplished by
inserting STS path AIS on extra traffic channels that are dropped at that node (i.e., on the
low-speed side).
Figure 3-24 covers the case of a signal fail-ring in a 2- or 4-fiber ring with extra traffic
support. For a SF-R condition between nodes A and C, ring switching can not be initiated
until all extra traffic has been dropped. Node C will detect signal failure on the line from
node A, drop its extra traffic, then signal SF-R. Node A will drop its extra traffic upon
reception of the SF-R from node C, and send its own SF-R request. Intermediate nodes,
upon reception of SF-R, will drop extra traffic and enter unidirectional full pass-through.
Upon detecting crossing K-bytes, intermediate nodes enter bidirectional full pass-through.
When the long path ring bridge request from node C reaches node A, all intermediate nodes,
such as node B, will have dropped extra traffic. The switching nodes then perform the SF-
R bridge and switch.
After the SF-R clears, and WTR timer has expired, the nodes will revert back to the idle
state. When a node receives No Request or Extra Traffic code from both directions, extra
traffic at the node will resume.
Figure 3-25 covers the case of a signal fail-span in a 4-fiber ring with extra traffic support.
For a SF-S condition, span switching can not be initiated until extra traffic has been
dropped on the span that requires the protection channel. For all other spans that are not
required for protection, extra traffic is allowed to continue. Node C will drop its extra traffic
3-33
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Overview of the BLSR Architecture

Step
#
node West East Action at node
K1 K2 K1 K2
1 A 00000011 00010011 00000010 00010011 no action
with ET indication
B 00000001 00100011 00000011 00100011
C 00000010 00110011 00000001 00110011
2 C 10110001 00111000 10110001 00110110
detect SF-R from node A, squelch
ET, source SF-R on short path and
long path
3 A 00010011 00010000 10110011 00011000
squelch ET, RR on short path, SF-R
on long path
B 10110001 00111000 00000011 00100000
squelch ET, unidir. full pass-through
4 A 00010011 00010010 10110011 00011010
Br & Sw
B 10110001 00111000 10110011 00011000
bidir. full pass-through
5 C 10110001 00111010 10110001 00110110
Br & Sw
Steady State (No ET Sourced on any span)
SF-R Clears
6 C 01010001 00111010 01010001 00110010
source WTR
7 A 00010011 00010010 01010011 00011010
RR on short path, WTR on long path
WTR Expires
8 C 00000001 00111001 00000001 00110001
drop Sw, sends NR & Br on short
path and long path
9 A 00000011 00010000 00000010 00010000
drop Br & Sw, sends NR & Idle on
short path and long path
10 C 00000010 00110011 00000001 00110011
drop Br, revert to idle, initiate ET
11 B 00000001 00100011 00000011 00100011
revert to idle, initiate ET
12 A 00000011 00010011 00000010 00010011
revert to idle, initiate ET
Figure 3-24. Signalling during SF-R with Extra Traffic
B
A
C
Working Channels
Protection Channels
Failure on both working
and protection channels
West
A C B A
East
West East
SONET BLSR Equipment Generic Criteria GR1230CORE
Overview of the BLSR Architecture Issue 4, December 1998

3-34
on the span connecting node A, and continue sourcing extra traffic on the span away from
the failure. Node A will drop its extra traffic on the span connecting node C after receipt of
SF-S bridge request, and continue sourcing extra traffic on the span away from the failure.
Node B, and all intermediate nodes, will enter K-byte pass-through and continue sourcing
extra traffic on both spans. The switching nodes then perform bridge and switch to
protection channels along the failed span.
After the SF-S clears, and WTR timer has expired, the nodes will revert back to the idle
state. When a node receives No Request or Extra Traffic code from both directions, extra
traffic at the node will resume.
3-35
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Overview of the BLSR Architecture

Step
#
node West East Action at node
K1 K2 K1 K2
1 A 00000011 00010011 00000010 00010011
no action
with ET indication
B 00000001 00100011 00000011 00100011
C 00000010 00110011 00000001 00110011
2 C 11000001 00111011 11000001 00110000
squelch ET on short path, signal SF-S
3 A 00100011 00010001 11000011 00011011
squelch ET on short path, Bridge
B 11000001 00111011 11000011 00011011
bidir. K-byte pass-through
4 C 11000001 00111011 11000001 00110010
Br & Sw
5 A 00100011 00010010 11000011 00011011
Br & Sw
Steady State (Extra Traffic on spans not used in protection)
SF-S Clears
6 C 01010001 00111011 01010001 00110010
enter WTR state
7 A 00100011 00100010 01010011 00011011
enter WTR state
WTR Expires
8 C 00000001 00111011 00000001 00110001
drops switch
9 A 00000011 00010000 00000010 00010011
drop Br & Sw, sends NR & Idle on
short path
10 C 00000010 00110011 00000001 00110000
drop Br, sends NR & Idle on short
path
11 C 00000010 00110011 00000001 00110011
revert to idle, initiate ET
B 00000001 00100011 00000011 00100011
revert to idle, initiate ET
12 A 00000011 00010011 00000010 00010011
revert to idle, initiate ET
Figure 3-25. Signalling during SF-S with Extra Traffic
B
A
C
West
A C B A
East
West East
Working Channels
Protection Channels
Failure on working
channels
SONET BLSR Equipment Generic Criteria GR1230CORE
Overview of the BLSR Architecture Issue 4, December 1998

3-36
3.5 Enhanced Non-preemptible Unprotected Traffic (E-NUT)
Overview
It should be noted that enhanced non-preemptible unprotected traffic (E-NUT) as defined
in GR-1230-CORE is an enhanced version of the non-preemptible unprotected traffic
(NUT) defined in ANSI standards. NUT as defined in ANSI allows certain provisioned
channels (a working channel and its corresponding protection channel) to provide transport
without using the BLSR protection mechanism. E-NUT as defined in this GR allows more
flexibility in provisioning channels as non-preemptible unprotected channels. Rather than
automatically provisioning both the working and corresponding protection channel as a
non-preemptible unprotected channel, E-NUT allows the working channel to be
provisioned as a non-preemptible unprotected channel while its corresponding protection
channel to still be used to carry protected traffic in the event of failures on the ring.
BLSR protocols allow the available bandwidth to be partitioned into three types of
channels: working channel to carry working traffic, protection channel which may be used
to carry extra traffic, and enhanced non-preemptible unprotected channel to carry enhanced
non-preemptible unprotected traffic (E-NUT). Working traffic is protected against failure
events via the BLSR APS protocol, while extra traffic is unprotected traffic carried on the
protection channels. Any failure event that may require the protection channels for
protection purposes shall preempt the extra traffic. E-NUT is unprotected traffic that is
carried on channels with the BLSR APS protection switching mechanism disabled for
certain STS-1 channels (i.e., a working channel and/or a protection channel). Traffic carried
on these channels is unprotected and non-preemptible. Thus, E-NUT carried on enhanced
non-preemptible unprotected channels afford a higher level of survivability as compared to
extra traffic, but lower level of survivability as compared to working traffic. Note that E-
NUT is not considered extra traffic, and as such, shall not set the ET code.
In addition, support of enhanced non-preemptible unprotected channel provisioning
requires that a E-NUT table be present at each node on the BLSR. This table contains
information to identify the channels that have been provisioned for E-NUT, and identify
which type of switching (i.e., span or ring switch) is prohibited by the E-NUT. Figure 3-26
provides a conceptual view of a E-NUT table. Figure 3-26 shows a 4-fiber BLSR with E-
NUT provisioned on working STS-1 #1 and its corresponding protection channel for all
spans. The figure also shows E-NUT provisioned on working STS-1 #2 and its
corresponding protection channel for span B-C. The figure also shows E-NUT provisioned
on working STS-1 #3 for span A-B. For 2-fiber BLSR, only the ring column is used.
3-37
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Overview of the BLSR Architecture

Figure 3-26. Conceptual Representation of a E-NUT Table
STS-1#
Ring Switch Span Switch
East West West East
1
2
3
4



:
:
Node A
STS-1#
Ring Switch Span Switch
East West West East
1
2
3
4



:
:
Node B
STS-1#
Ring Switch Span Switch
East West West East
1
2
3
4


:
:
Node C
STS-1#
Ring Switch Span Switch
East West West East
1
2
3
4


:
:
Node D
Node A Node B
Node C Node D
- all spans have E-NUT for working STS-1 #1 and corresponding
protection STS-1
- The span between B and C has E-NUT on working STS-1 #2 and
corresponding protection STS-1
- The span between A and B has E-NUT on working STS-1 #3
: indicates the type of protection that is not available for that working channel

SONET BLSR Equipment Generic Criteria GR1230CORE


Overview of the BLSR Architecture Issue 4, December 1998

3-38
3.6 STS Squelching Logic Overview
This section provides a method for squelching for circuits that are not of a simple
bidirectional nature. Generalized squelching logic can be derived from the notions of
squelching for basic unidirectional circuits, squelching for multiply dropped unidirectional
circuits, and squelching for multiply sourced unidirectional circuits. BLSR switching
protocols described in other parts of this document are not affected by this generalization.
With the support of unidirectional circuit on the BLSR, unidirectional squelching examples
given in this section can be applied to both unidirectional and bidirectional circuit on the
BLSR. The extension of squelching logic formally allows a greater variety of services to be
provisioned.
3.6.1 Squelching for Unidirectional (and Bidirectional) Circuits
There are many instances or combinations of node failures that might require squelching.
The following are two node failure scenarios for a unidirectional circuit that require
squelching: node failure of the source node (failure in the opposite direction from the
unidirectional circuit, see Figure 3-27), and node failure of the destination node (failure in
the direction of the unidirectional circuit, see Figure 3-28):
Figure 3-27. Unidirectional Circuit Squelching Example Where the Failure is in the
Opposite Direction from the Unidirectional Circuit
Node Failure
Do not
squelch
Switching Node
Squelch
3-39
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Overview of the BLSR Architecture

1. For failure in the opposite direction from the direction of the unidirectional circuit,
squelch the circuit (insert path AIS into the circuits corresponding protection channel
as it is switched from the direction away from the failure) if and only if the node failure
scenario includes the source node for the unidirectional circuit. Figure 3-27 shows two
cases, one of which requires squelching and the other does not require squelching of
the unidirectional circuit.
2. For failure in the direction of the unidirectional circuit, squelch the circuit (insert path
AIS into the circuits corresponding protection channel as it is switched from the
direction away from the failure) if and only if the node failure scenario includes the
destination node for the unidirectional circuit. Figure 3-28 shows two cases, one of
which requires squelching and the other does not require squelching of the
unidirectional circuit.
Note that when both unidirectional squelching methods mentioned above are applied to a
bidirectional circuit, the result is the bidirectional squelching of a bidirectional circuit. See
Figure 3-28. Unidirectional Circuit Squelching Example Where the Failure is in the
Direction of the Unidirectional Circuit
Node Failure
Do not
squelch
Switching Node
Squelch
SONET BLSR Equipment Generic Criteria GR1230CORE
Overview of the BLSR Architecture Issue 4, December 1998

3-40
Figure 3-29, which shows two cases, one of which requires squelching and the other does
not require squelching of bidirectional circuit.
3.6.2 Squelching for Multiply Sourced/Dropped Unidirectional Circuits
As with basic unidirectional circuits, there are many instances or combinations of node
failures that require squelching for multiply sourced or multiply dropped unidirectional
circuits. The following are two node failure scenarios for multiply sourced/dropped
unidirectional circuits that require squelching: node failure of the first source node (failure
in the opposite direction from the unidirectional circuit), and node failure of the last
destination node (failure in the direction of the unidirectional circuit):
1. For failure in the opposite direction from the direction of the multiply sourced/dropped
unidirectional circuit, squelch the circuit (insert path AIS into the circuits
corresponding protection channel as it is switched from the direction away from the
failure) if and only if the node failure scenario includes the first source node for the
unidirectional circuit. Figures 3-30 and 3-31 each show two cases, one which requires
squelching and the other does not require squelching of the unidirectional circuit.
Figure 3-30 illustrates the multiply sourced case, and Figure 3-31 illustrates the
multiply dropped case.
2. For failure in the direction of the multiply sourced/dropped unidirectional circuit,
squelch the circuit (insert path AIS into the circuits corresponding protection channel
as it is switched from the direction away from the failure) if and only if the node failure
Figure 3-29. Bidirectional Circuit Squelching Example
Node Failure
Do not
squelch
Switching Node
Squelch
3-41
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Overview of the BLSR Architecture

Figure 3-30. Multiply Sourced Unidirectional Circuit Squelching Example where
the Failure is in the Opposite Direction from the Unidirectional Circuit
Figure 3-31. Multiply Dropped Unidirectional Circuit Squelching Example where
the Failure is in the Opposite Direction from the Unidirectional Circuit
Node Failure
Do not
squelch
Switching Node
Squelch
Node Failure
Do not
squelch
Switching Node
Squelch
SONET BLSR Equipment Generic Criteria GR1230CORE
Overview of the BLSR Architecture Issue 4, December 1998

3-42
Figure 3-32. Multiply Sourced Unidirectional Circuit Squelching Example where
the Failure is in the Direction of the Unidirectional Circuit
Figure 3-33. Multiply Dropped Unidirectional Circuit Squelching Example where
the Failure is in the Direction of the Unidirectional Circuit
Node Failure
Do not
squelch
Switching Node
Squelch
Node Failure
Do not
squelch
Switching Node
Squelch
3-43
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Overview of the BLSR Architecture

scenario includes the last destination node for the unidirectional circuit. Figures 3-32
and 3-33 each show two cases, one which requires squelching and the other does not
require squelching of the unidirectional circuit. Figure 3-32 illustrates the multiply
sourced case, and Figure 3-33 illustrates the multiply dropped case.
Figure 3-34 gives an illustration of squelching for a bidirectional circuit using a
combination of the unidirectional squelching rules for multiply sourced and multiply
dropped unidirectional circuits.
Figure 3-34. Bidirectional Circuit Squelching Example with Multiply Sourced and
Multiply Dropped Traffic
Node Failure
Do not
squelch
Switching Node
Squelch
SONET BLSR Equipment Generic Criteria GR1230CORE
Overview of the BLSR Architecture Issue 4, December 1998

3-44
3.7 Ring Interworking Overview
This section provides an overview of the various methods used for interconnecting two
rings, where the rings may be two interconnected BLSRs, a BLSR interconnected to a
UPSR, or a BLSR interconnected to any network (such as a mesh network). Protocols for
BLSR interconnections provide the protection mechanisms needed for survivable transport
of data between rings. The level of protection (i.e., the method used for interconnection)
may be varied based on the services of the provisioned circuits. In addition, the level of
protection may also be based on the availability of the existing bandwidth on the ring.
The BLSR APS protocol provides shared protection bandwidth for intra-ring customer
traffic (i.e., traffic routed within the ring). For inter-ring customer traffic, various methods
exist to provide survivability of the customer traffic. These protection switching
mechanisms are based on the assumption that dual node ring interconnection is provided
(i.e., that ring interconnections are provided at two nodes, with two different drops to the
other network and two different feeds from the other network (referred to as dual-homed
feature). In addition, failure conditions (that do not affect the dual-feed) in the other
network should not cause any type of transient switching in the BLSR. This provides
network independence.
The following sections describe the various methods used for dual node ring interworking,
and provide examples of how these networks will provide survivability.
3.7.1 Drop-and-Continue Method
Figure 3-35 provides an illustration of the drop-and-continue method of ring interworking.
The figure depicts a BLSR (i.e., network #1) interconnected with a second network (the
interconnected network may be a BLSR, a UPSR, or a mesh network, shown as Network
#2 in the figure).
For two BLSRs (i.e., network #2, in Figure 3-35, is a BLSR), there are two types of network
interconnections. Figure 7-1 illustrates the same-side routing configuration, where the
inter-ring signal from the primary node of the top ring is directly connected to the primary
node of the bottom ring. Figure 7-2 illustrates the opposite-side routing configuration,
where the inter-ring signal from the primary node of the top ring is connected to the
secondary node of the bottom ring.
The continue traffic and the dual-fed traffic are defined as the secondary circuit, which may
be carried over the working or the protection bandwidth, as illustrated in Figure 3-35. The
service circuit applies to the opposite-side routing configuration, where the continue traffic
and the dual-fed traffic are carried on the working bandwidth, as illustrated in Figure 7-2.
The service circuit may also be carried on the protection bandwidth, but by default, the
service circuit is provisioned to be carried on the working bandwidth. Note that same-side
routing requires two secondary circuits (i.e., one per ring, for dual node interworking),
while opposite-side routing requires only one secondary circuit and one service circuit.
3-45
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Overview of the BLSR Architecture

Figure 3-36 illustrates interconnection of the BLSR with a mesh network. Two identical
signals are expected from Network #2, one destined for the primary node and one destined
for the secondary node (i.e., dual feed of a signal originating from Network #2). Two
identical signals from Network #1 are also transmitted to Network #2 via the drop and
continue feature.
The primary node provides the drop and continue feature for the traffic destined to Network
#2, and also provides the service selection feature for the dual-fed traffic entering the ring
from Network #2. For the inter-ring circuits #1 and #2, the functions of the primary and
secondary nodes are:
For circuit #1, the signal is transmitted to Network #2 via the primary node, and
continued onto the secondary node, where the duplicate signal is then transmitted to
Network #2.
For circuit #2, the signal is dual-fed into the secondary and primary nodes. At the
secondary node, the inter-ring traffic is destined to the termination node via the
primary node. At the primary node, the service selector examines the inter-ring traffic
from the secondary node (on the high-speed line) and from Network #2 (on the low-
speed line), and transmits the better of the two signals toward the termination node.
Although the figure shows the same primary and secondary nodes being used for circuit #1
and circuit #2, different nodes may be used for the primary and secondary node functions.
As with intra-ring circuits, inter-ring circuits may be unidirectional, as shown in the figure
(i.e., different termination nodes, such as circuit #1 and circuit #2).
Figure 3-35. Baseline Ring Interconnection
SS
Network #1
Network #2
BLSR
Primary node Secondary node
Source node Termination node
Intermediate node
Circuit #1
Circuit #2
Traffic on working or
protection bandwidth
Secondary
circuit
Secondary
circuit
Interconnecting
Links
SONET BLSR Equipment Generic Criteria GR1230CORE
Overview of the BLSR Architecture Issue 4, December 1998

3-46
As shown in Figure 3-35, there are two options for transmitting the secondary circuit:
1. Transmit the secondary circuit on working bandwidth. Note that for unidirectional
inter-ring service, only one direction of traffic (i.e., either the continue traffic or the
dual-fed traffic) will be transmitted.
2. Transmit the secondary circuit on protection bandwidth as extra traffic. Note that for
unidirectional inter-ring service, only one direction of traffic (i.e., either the continue
traffic or the dual-fed traffic) will be transmitted. This option is also known as drop
and continue on protection or ring interworking on protection (RIP).
The trade-offs for these two options are the survivability and the bandwidth exhaust of the
ring. By taking advantage of the protection bandwidth between the interconnection nodes
on the BLSR, less working bandwidth would be consumed as compared to the method of
using only working bandwidth for ring interconnection.
The following options for ring interworking using combinations of working and protection
bandwidth to carry inter-ring traffic may be used (these options apply to two interconnected
BLSRs)
1. Ring interconnection using working bandwidth in both rings.
2. Ring interconnection using working bandwidth in one ring and protection bandwidth
in the other ring.
Figure 3-36. Interconnection of BLSR and Mesh Network
SS
Network #1
Network #2
BLSR
Primary node Secondary node Intermediate node
Secondary
circuit
Secondary
circuit
Traffic on working or
protection bandwidth
SS
MESH
Point-to-point
connection between
nodes
3-47
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Overview of the BLSR Architecture

3. Ring interconnection using protection bandwidth in both rings.
These ring interworking options may be used on interconnected rings with either same-side
or opposite-side routing. The option of using only working bandwidth provides the highest
level of survivability. If less survivability can be tolerated, certain options that take
advantage of protection bandwidth between interconnecting ring nodes may be used. Table
3-2 lists the various interconnections available. Note that this table outlines the available
options for interconnection of two BLSRs, and does not provide any information on the
survivability associated with these options. The survivability associated with each option is
given in the following sections.
Protection switching mechanisms used for inter-ring traffic remain the same as those used
for intra-ring traffic. In the case of inter-ring traffic, the protocols used are based on the
multiply sourced and multiply dropped circuits, with the accompanying squelching logic
for the multiply sourced and multiply dropped circuits. Figure 3-37 illustrates the
correlation between inter-ring circuits and multiply sourced/dropped circuits, in the case
where the secondary circuit is on working bandwidth. For the case where the secondary
circuit is on protection bandwidth, the protection mechanisms and the squelching logic are
more complex.
Table 3-2. Interconnection Options Between Two BLSRs
Same-side Routing Opposite-side Routing
Secondary circuits on working Secondary circuit on working, service
circuit on working
One secondary circuit on working, one
secondary circuit on protection
Secondary circuit on protection, service
circuit on working
Secondary circuits on protection Secondary circuit on working, service
circuit on protection
Secondary circuit on protection, service
circuit on protection
Figure 3-37. Correlation Between Inter-ring Circuit and Multiply Sourced and
Multiply Dropped Circuits
Multiply dropped circuit
Multiply sourced circuit
Secondary circuit
on working bandwidth
SS
SONET BLSR Equipment Generic Criteria GR1230CORE
Overview of the BLSR Architecture Issue 4, December 1998

3-48
The following subsections outline the protection mechanisms and the squelching logic used
for inter-ring traffic during a failure scenario. Since inter-ring protection mechanisms and
squelching logic are independent of the conditions of other rings, ring interconnection
configurations will not affect the protocol (i.e., it does not matter whether the rings are
interconnected via same-side or opposite-side routing).
3.7.1.1 Interconnection Survivability with Drop and Continue on Working
Channels
Section 3.5 describes the generalized squelching logic used for various types of traffic
patterns, including the multiply sourced and multiply dropped circuits. This generalized
squelching logic also applies to ring interworking. Figure 3-37 shows two circuits, one
multiply sourced (dual-fed from the other network) and one multiply dropped (drop and
continue to the other network). These two circuits correspond to the unidirectional
squelching example, as given in Figures 3-32 and 3-33 with two sources and two drops,
respectively. As such, the generalized squelching logic and the protection mechanisms used
in ring interworking, where the secondary circuit is on working bandwidth, are the same as
those described in Section 3.5. For ring interworking, the secondary node is the trigger for
squelching of inter-ring traffic. This is consistent with Section 3.5, where the first source
node and the last destination node correspond to the secondary, or trigger, node.
The following example illustrates the population of an example squelch table
representation. The squelch table contains the minimal information needed to perform the
squelching function. Figure 3-38 illustrates unidirectional ring interworking where circuit
#1 is sourced from network #1 (BLSR) and circuit #2 is sourced from network #2 (where
network #2 may be a BLSR, UPSR, or other type of network). This example illustrates the
case of two unidirectional inter-ring circuits using the same primary and secondary nodes.
Note that for bidirectional ring interworking, both circuit #1 and circuit #2 have the same
termination, primary, and secondary nodes. In addition, these circuits are carried on
different STS numbers.
For this example, circuit #2 is multiply sourced from nodes 4 and 5 and destined for node
2. The squelch table contains node 5s ID (the first source node) as the source node, and
node 2s ID as the destination node. This inter-ring circuit is mapped onto STS-1 #2.
Circuit #1 is sourced from node 3 and destined (multiply dropped) for nodes 4 and 5. The
squelch table contains node 3s ID as the source node and node 5s ID (the last destination
node) as the destination node. This inter-ring circuit is mapped onto STS-1 #1.
Interconnection with drop and continue on the working bandwidth provides survivability
for single link and single node failures on both rings. For example, a secondary node failure
in one ring and a primary node failure in the other ring do not cause loss of inter-ring traffic.
In certain situations, drop and continue on working may provide inter-ring circuit
survivability when multiple node and link failures occur on either ring.
3-49
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Overview of the BLSR Architecture

3.7.1.2 Interconnection Survivability with Drop and Continue on Protection
Bandwidth (Ring Interworking on Protection)
Ring interworking on protection (RIP) bandwidth provides similar interconnection
capabilities for inter-ring traffic, compared to ring interworking using the working
bandwidth. Figure 3-39 illustrates the concept of RIP, where the secondary circuit is carried
on the protection bandwidth. Again, for each unidirectional inter-ring circuit, only the
continue traffic or the dual-fed traffic is valid. In the RIP scenario, the squelching logic still
uses the secondary node as the squelching trigger. This allows the existing generalized
squelching logic to be used for both ring interworking using working bandwidth and RIP
circuits. The protection mechanism for the RIP will differ from the ring interworking using
working bandwidth.
Node 2 Node 3
STS-1
#
West East STS-1
#
West East
Outgoing Incoming Outgoing Incoming Outgoing Incoming Outgoing Incoming
Dst VT Src VT Dst VT Src VT Dst VT Src VT Dst VT Src VT
1 5
2 5 2 2 5
Node 4 Node 5
STS-1
#
West East STS-1
#
West East
Outgoing Incoming Outgoing Incoming Outgoing Incoming Outgoing Incoming
Dst VT Src VT Dst VT Src VT Dst VT Src VT Dst VT Src VT
1 3 5 1 3
2 2 5 2 2
Figure 3-38. Squelch Table Example for Inter-ring Traffic with Secondary Circuit
on Working Bandwidth
SS
Network #1
Network #2
Primary node Secondary node
Source node
Termination node
Circuit #1, STS-1 #1
Circuit #2, STS-1 #2
Traffic on working
Secondary
circuit
Interconnecting
Links
Node 2
Node 3
Node 4 Node 5
Node 2 Node 3 Node 4 Node 5 Node 2
East West
OC-48 BLSR
SONET BLSR Equipment Generic Criteria GR1230CORE
Overview of the BLSR Architecture Issue 4, December 1998

3-50
Using the protection bandwidth for the continue portion of the drop and continue traffic
(and in combination with the high-speed input from the other network, i.e., the high speed
portion of the dual-fed) allows the working bandwidth to be used for additional protected
intra-ring traffic. One disadvantage of using the protection bandwidth, as discussed
previously, is lower survivability. Since the secondary circuit is carried on the protection
channel, these circuits are considered extra traffic, and are tagged as such (i.e., ET code
associated with these circuits). For any failure on the ring, extra traffic (e.g., the secondary
circuit on protection) is pre-empted and dropped. Thus, in certain failure scenarios, using
the protection bandwidth may provide lower survivability. Take the case of two BLSRs
interconnected using opposite-side routing with double link failures, as shown in Figure 3-
40. As shown in the figure, for the secondary circuit and the service circuit on protection,
Figure 3-39. Ring Interworking on Protection
Figure 3-40. Opposite-Side Routing with (1) Service Circuit on Protection and (2)
Service Circuit on Working: Double Link Failures
Multiply dropped circuit
Multiply sourced circuit
Secondary circuit
on protection bandwidth
SS
Service circuit
on protection
Service circuit
on working
Termination
Node
Termination
Node
Termination
Node
Termination
Node
(1) Complete loss of
inter-ring traffic
(2) Survivable
inter-ring traffic
Secondary circuit
on protection
Secondary circuit
on protection
3-51
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Overview of the BLSR Architecture

both these circuits are pre-empted by working traffic that is bridged onto protection,
resulting in complete loss of inter-ring traffic. For the case where only one circuit is on
protection, the same combination of failures does not result in loss of inter-ring traffic.
Following the example of Section 3.7.2.1, Figure 3-41 provides an example of ring
interworking using the protection bandwidth for the secondary circuit, with the
accompanying squelching table. For the case of the RIP, an additional table is required,
called the RIP table. This table contains the node address of the primary and termination
nodes for each inter-ring circuits carried on the protection bandwidth, and is needed only at
the secondary node. Figure 3-42 illustrates a RIP table representation.
Note that the primary and the secondary nodes do not contain information on the secondary
circuits on protection. This is consistent with the information contained in the squelch table.
Since the secondary circuits are carried on the protection bandwidth, they are considered
Node 2 Node 3
STS-1
#
West East STS-1
#
West East
Outgoing Incoming Outgoing Incoming Outgoing Incoming Outgoing Incoming
Dst VT Src VT Dst VT Src VT Dst VT Src VT Dst VT Src VT
1 5
2 5 2 2 5
Node 4 Node 5
STS-1
#
West East STS-1
#
West East
Outgoing Incoming Outgoing Incoming Outgoing Incoming Outgoing Incoming
Dst VT Src VT Dst VT Src VT Dst VT Src VT Dst VT Src VT
1 3
2 2
Figure 3-41. Squelch Table Example for Inter-ring Traffic with Secondary Circuit
on Protection Bandwidth
SS
Network #1
Network #2
Primary node Secondary node
Source node
Termination node
Circuit #1, STS-1 #1
Circuit #2, STS-1 #2
Traffic on protection
Secondary
circuit
Interconnecting
Links
Node 2
Node 3
Node 4 Node 5
Node 2 Node 3 Node 4 Node 5 Node 2
East West
OC-48 BLSR
SONET BLSR Equipment Generic Criteria GR1230CORE
Overview of the BLSR Architecture Issue 4, December 1998

3-52
extra traffic. As such, any failure that requires the use of the protection bandwidth will pre-
empt the extra traffic, which will then be squelched. The RIP table maintains information
on the secondary circuits. This information may be used to provide an additional level of
survivability.
There are two methods used for survivability when the secondary circuit is carried on
protection bandwidth. These methods provide additional functionalities at the secondary
nodes to perform failure recovery in various failure scenarios. These are
1. The basic method. Using this method, during a primary node failure, with the
secondary circuit on protection bandwidth, the secondary node will select traffic
directly from and/or bridge traffic to the protection bandwidth on the span away from
the failed primary node. Depending on whether the inter-ring traffic is unidirectional
or bidirectional, one or both actions may be taken. All other nodes react to the failure
as usual. Figure 3-43 illustrates this method of protection.
Note, if there are no intermediate nodes between the primary and secondary nodes, a
primary node failure will trigger the secondary node to do a normal ring switch and
select the RIP traffic from the protection bandwidth on the span away from the primary
node. Otherwise, the two adjacent nodes to the failed primary node will do a normal
Node 5 (Secondary Node)
STS-1
#
West East
Outgoing Incoming Outgoing Incoming
Primary
node
Term.
node
Primary
node
Term.
node
Primary
node
Term.
node
Primary
node
Term.
node
25 4 3
26 4 2
Figure 3-42. RIP Table Example for Inter-ring Traffic with Secondary Circuit on
Protection Bandwidth
Figure 3-43. Primary Node Failure Restoral in a BLSR with Secondary Circuit on
Protection: Basic Operation
Termination
Primary Secondary
Intermediate
Working Bandwidth
Protection Bandwidth
node node
node
node
SS
Intra-ring
circuits
3-53
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Overview of the BLSR Architecture

ring switch, and the secondary node will select the RIP traffic directly from the
protection bandwidth on the span away from the primary node.
2. The optional enhanced method. For the optional enhanced secondary node feature,
with the secondary circuit on protection bandwidth, in the event of a failure between
(but not including) the primary and termination nodes for inter-ring traffic, service
selection should be performed by the secondary node (i.e., the enhanced secondary
node temporarily takes on primary node functionality). All other nodes perform failure
recovery as usual.
The service selector at the secondary node will select the better of the two received
STSs coming from (a) the low-speed (interconnecting) line, and (b) the protection
channel on the high-speed line from the direction of the primary node (i.e., STS on the
protection bandwidth that contains the inter-ring traffic coming from the primary
node). In addition, the secondary node will perform the drop and continue on
protection towards the primary node using, as input for the drop and continue function,
the received STS from the protection channel away from the primary node. This is
illustrated in Figure 3-44.
3.7.1.2.1 Examples of Failure Recovery for Ring Interconnections Using RIP
The following examples illustrate how a BLSR using RIP reacts to various multiple failure
scenarios.
Figure 3-44. Link Failure Restoral in a BLSR with Secondary Circuit on Protection:
Optional Enhanced Operation
Termination
Primary
Secondary
Intermediate
Working Bandwidth
Protection Bandwidth
SS
Switching
node node
node
node
node
Switching
node
SONET BLSR Equipment Generic Criteria GR1230CORE
Overview of the BLSR Architecture Issue 4, December 1998

3-54
3.7.1.3 Cable Cut in Ring #1 and Ring #2
Figure 3-45 covers the case of a cable cut in both rings one and two. In ring one, the cable
cut is between the termination node and the secondary node. In ring two, the cable cut is
between the termination node and the primary node.
This example does not assume optional enhanced secondary node operation. The enhanced
secondary node operation should not affect the resulting interconnections. A cable cut in
ring one does not affect the inter-ring traffic from the termination node to the primary node.
Inter-ring traffic from the primary node to the secondary node is pre-empted. Any extra
traffic on the ring will be pre-empted. The secondary node will not provide ring
interconnection. Ring twos behavior is similar. Note that at steady state, ring one has one
inter-connection to ring two, and ring two has one inter-connection to ring one. If optional
enhanced secondary node operation were available, then ring two would have two inter-
connections to ring one. This does not affect the overall survivability since ring one does
not accept inter-ring traffic at the secondary node.
Figure 3-45. Cable Cut in Ring #1 and Ring #2
Termination
Primary
Secondary
Intermediate
Working Bandwidth
Protection Bandwidth
Switching
node node
node
node
node
Switching
node
Termination
Primary
Secondary
Intermediate
Switching
node node
node
node
node
Switching
node
BLSR
One
BLSR
Two
Pre-empted
SS
3-55
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Overview of the BLSR Architecture

3.7.1.4 Primary Node Failure in Ring #1 and Cable Cut in Ring #2
Figure 3-46 covers the case of a primary node failure in ring one and a cable cut in ring two.
In ring two, the cable cut is between the termination and primary nodes.
In this figure, the rings are assumed capable of the optional enhanced operations, whereby
for certain failure scenarios the secondary node functionalities are enhanced to provide the
drop and continue as well as service selector functions. A primary node failure in ring one
results in the inter-ring traffic being re-routed (bridged and switched onto the protection
channels) towards the secondary node. No misconnection occurs since the destination node
entered in the squelch table is the secondary node, which is unaffected by the failure. Any
extra traffic on the ring will be pre-empted. Since the secondary node provides the sole
avenue for inter-ring connectivity, it adds and drops inter-ring traffic directly from the
protection channel. Note that inter-ring traffic on the protection channel is not switched
back to the working channels at the secondary node.
In ring two, inter-ring traffic is restored via both the primary and secondary nodes. The
primary node performs the same actions in both the basic and optional enhanced operation
Figure 3-46. Primary Node Failure in Ring #1 and Cable Cut in Ring #2 with
Optional Enhanced Operation
Working Bandwidth
Protection Bandwidth
Termination
Primary
Secondary
Intermediate
SS
Switching
node node
node
node
node
Switching
node
Termination
Primary Secondary
Intermediate
node node
node
node
SS
Intra-ring
circuits
BLSR
One
BLSR
Two
SONET BLSR Equipment Generic Criteria GR1230CORE
Overview of the BLSR Architecture Issue 4, December 1998

3-56
modes (i.e., the primary node receives outgoing inter-ring traffic from the working channel
and receives incoming inter-ring traffic from the low-speed line).
If ring two only provides the basic secondary node operation, then the secondary node does
not provide the service selector nor the drop and continue feature. The secondary node
functions as a pass-through node for the inter-ring traffic heading for the primary node. The
primary node provides the inter-ring connectivity to ring one. This is illustrated in Figure
3-47. Thus inter-ring connectivity is severed since
The secondary node in ring two is not receiving inter-ring traffic from the secondary
node in ring one, and
The primary node in ring one cannot receive inter-ring traffic from the primary node
in ring two.
For this particular scenario, the optional enhanced operation provides an added
survivability for inter-ring traffic.
Figure 3-47. Primary Node Failure in Ring #1 and Cable Cut in Ring #2 with Basic
Secondary Node Operation
Working Bandwidth
Protection Bandwidth
Termination
Primary
Secondary
Intermediate
Switching
node node
node
node
node
Switching
node
Termination
Primary Secondary
Intermediate
node node
node
node
SS
Intra-ring
circuits
BLSR
One
BLSR
Two
3-57
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Overview of the BLSR Architecture

3.7.2 Dual Transmit Method
Using this method for ring interworking, inter-ring traffic is diversely routed to the primary
and the secondary nodes. The terminating node dual feeds the signal to the primary and
secondary ring interconnection nodes. The circuit destined for the primary node will be
carried on the working channels. The circuit destined for the secondary node (i.e.,
secondary circuit) may be carried on either the working channels or the protection channels.
In the other direction, the terminating node selects, by a service selector, between the
primary and secondary circuit signals.
The dual transmit method of ring interworking may be considered a method for load-
balancing inter-ring traffic and for reducing the total amount of bandwidth (working plus
protection bandwidth) used for inter-ring traffic. For example, if the span between the
primary and secondary nodes are heavily loaded with intra- and inter-ring traffic (including
both working and extra traffic), then the dual transmit method may be used to balance the
load on the span, thus potentially reducing congestion. The dual transmit method also
provides a marked savings in terms of ring bandwidth usage in the case of a terminating
node in between the primary and secondary ring interconnection nodes.
3.7.2.1 Dual Transmit On Working Channels
The added traffic at node A of Figure 3-48 is dual fed toward the primary and secondary
nodes in opposite directions around the ring. This function is referred to as dual transmit.
Traffic from the primary and secondary nodes is selected by a service selector at node A.
The interconnections are at the STS-M or OC-M level, and DSx interconnection is
supported. The same channel assignment on the line is used between node A and the
primary node, and node A and the secondary node. Figure 3-48 is an example of dual
transmit using working channels for the two paths. This interconnection architecture
provides protection against the failure of one or both interconnecting nodes (each on
different rings) or the connection between the two interconnecting nodes. Furthermore, the
interconnection architecture does not require inter-ring signaling.
The dual transmit method provides a marked savings in terms of ring bandwidth usage in
the case of a terminating node in between the primary and secondary ring interconnection
nodes, as shown in Figure 3-49. This method may also be desirable in other cases where the
bandwidth between the primary and secondary nodes is not available.
Use of the dual transmit method on one ring does not require the use of the dual transmit
method for ring interworking on the connecting ring.
SONET BLSR Equipment Generic Criteria GR1230CORE
Overview of the BLSR Architecture Issue 4, December 1998

3-58
3.7.2.2 Dual Transmit On Protection Channels
For the dual transmit method, the terminating node dual feeds the signal to the primary and
secondary ring interconnection nodes. In the other direction, the terminating node selects,
by a service selector, between the primary and secondary circuit signals. Except for the case
of enhanced secondary node option during failure along the primary circuit, the service
selection shall always occur at the terminating node. The path to the primary node must be
on working channels. In this case the path to the secondary node is on protection channels
corresponding to the service channel assignment between the terminating node and the
primary node. The dual transmit method provides a savings in ring bandwidth usage in the
case of the terminating node in between the primary and secondary ring interconnection
nodes, as shown in Figure 3-49. This method may also be desirable in other cases where
bandwidth between the primary and secondary nodes is not available.
Use of the dual transmit method on one ring does not require the use of the dual transmit
method for ring interworking on the connecting ring.
The following options for ring interworking using combinations of working and protection
bandwidth for the secondary circuit are possible:
a. ring interconnection using working bandwidth only;
Figure 3-48. Dual transmit Ring Interworking - Relieved Congestion P-S
A
Terminating Node
BLSR
(Using Dual Transmit Method)
Secondary
Circuit
P
Primary Node
S
Secondary Node
Service Selector
3-59
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Overview of the BLSR Architecture

b. ring interconnection using working bandwidth on one ring and protection in the other;
and
c. ring interconnection using protection bandwidth in both rings.
Selection of the dual transmit method for ring interworking on either working or protection
channels is provisionable on a per STS-1 basis.
These ring interworking options may be used on interconnected rings with either same-side
or opposite-side routing. Same-side routing is illustrated in Figure 3-50, while opposite-
side routing is illustrated in Figure 3-51. (Note that same-side and opposite-side routing are
equivalent as long as both paths are carried on working channels.)
The option of using only working bandwidth provides the highest level of survivability.
Circuits using protection bandwidth have reduced survivability. Same-side ring
interworking may be used in any of the three options listed above. Opposite-side ring
interworking is not recommended using protection bandwidth on both rings. Assigning the
service circuit to protection bandwidth is not recommended. Assigning the service circuit
to protection bandwidth in opposite-side ring interworking should not be used, because it
puts part of the primary circuit on protection.
Figure 3-49. Dual Transmit Ring Interworking - Improved Bandwidth Efficiency
Terminating Node
BLSR
Drop and Continue
Method
Secondary
Circuit
P S
Service Selector
P: Primary Node
S: Secondary Node
Terminating Node
BLSR
Dual Transmit
Method
Secondary
Circuit
P S
(a) Drop and Continue Method (b) Dual Transmit Method
SONET BLSR Equipment Generic Criteria GR1230CORE
Overview of the BLSR Architecture Issue 4, December 1998

3-60
3.7.2.2.1 Optional Enhanced Secondary Node Action During Failures Between
the Primary and Terminating Node Using Dual Transmit Method
With the secondary circuit on protection bandwidth, in the event of a failure between (but
not including) the primary and termination nodes for inter-ring traffic, service selection
should be performed by the secondary node (i.e., secondary node temporarily takes on
terminating node functionality).
The service selector at the secondary node shall select the better of the two received STSs
coming from the low-speed (interconnecting) line, and the protection channel on the high-
speed line from the direction of the primary node (i.e., the STS on the protection bandwidth
that contains the inter-ring traffic coming from the primary node). In addition, the
secondary node shall perform the drop and continue on protection toward the primary node
using, as input for the drop and continue function, the received STS from the protection
channel away from the primary node.
Figure 3-50. BLSR Interconnection with Dual Transmit and Same Side Routing
Service Selector
A
Terminating Node
BLSR
(Using Dual Transmit Method)
Secondary
Circuit
P
Primary Node
S
Secondary Node
P
Primary Node
S
Secondary Node
BLSR
(Using Drop and Continue)
Secondary
Circuit
B
Terminating Node
3-61
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Overview of the BLSR Architecture

Figure 3-51. BLSR Interconnection with Dual Transmit and Opposite Side Routing
Service Selector
A
Terminating Node
BLSR
(Using Dual Transmit Method)
Secondary
Circuit
P
Primary Node
S
Secondary Node
P
Primary Node
S
Secondary Node
BLSR
(Using Drop and Continue)
Service
Circuit
B
Terminating Node
SONET BLSR Equipment Generic Criteria GR1230CORE
Overview of the BLSR Architecture Issue 4, December 1998

3-62
4-1
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Network Applications

4. Network Applications
In a BLSR, traffic in both directions of transmission between two nodes traverse the same
set of nodes. Thus, unlike a unidirectional ring time slot, a BLSR time slot can be reused
several times on the same ring. One of the BLSRs advantages over unidirectional rings is
its better utilization of capacity. All the nodes on the ring share the protection bandwidth,
regardless of the number of times a time slot has been reused. If a time slot is used only
once on the ring, as in centralized traffic demand patterns, the capacity advantage is no
longer apparent.
In a loop environment, most traffic is destined to the serving central office (hub). This
characteristic limits the ring's ability to reuse bandwidth. The choice to use a BLSR for this
application may not be advantageous because other architectures, which are simpler, less
expensive, and robust (in terms of survivability), are available. Thus, when making such a
choice, the actual traffic demand limitations of the deployment environment should be
studied. The bidirectional ring's similarity to today's point-to-point networks should be
considered as well as the fact that it provides at least as much capacity as other types of
rings.
In an interoffice environment, traffic tends to be heavily distributed (assuming a SONET
management scheme with distributed grooming), and bandwidth can be reused. The BLSR
is most advantageous for this kind of traffic pattern because it provides more capacity than
other ring types by allowing the protection bandwidth to be shared. Also, the traffic pattern
cannot be predicted to be purely hubbing in an interoffice environment. The possibility of
the traffic pattern changing after initial deployment is another consideration. However,
because switching is done at the line level, a standard protocol is needed to coordinate
switching activity and to facilitate sharing of the protection bandwidth.
The choice between a 2-fiber and 4-fiber BLSR depends on the desired capacity and level
of survivability. Equipment failures that affect a single fiber account for a significant
percentage of the failures in current networks. If multiple equipment failures occur on a 4-
fiber ring, multiple span protection switches can be performed. If equipment failures
continue to dominate over cable cuts and node failures (in terms of percentage), 4-fiber
BLSRs will continue to be more survivable than 2-fiber BLSRs. If the protection and the
service channels are carried over fibers that are diversely routed, span switching increases
the availability of the channels by providing protection against multiple fiber cuts and
multiple equipment failures.
Thus, for networks with high mesh-like demand, the 4-fiber ring provides a better fit to the
network and provides more survivability. Also, the 4-fiber ring is similar to current
networks in terms of traffic routing and traffic protection. For example, provisioning on a
4-fiber ring is similar to any other point-to-point bidirectional system. Provisioning a 2-
fiber ring requires reserving some of the bandwidth on each fiber for protection of the
working traffic.
SONET BLSR Equipment Generic Criteria GR1230CORE
Network Applications Issue 4, December 1998

4-2
5-1
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Functions Needed for NE Deployment in a BLSR

5. Functions Needed for NE Deployment in a BLSR
The functional criteria in GR253CORE for any SONET NE and GR-496-CORE for
SONET Add/Drop Multiplexers also apply to an NE deployed in a BLSR. The ring
architecture requires that additional functions be supported, and this section highlights
some of these functions. In some cases, functions are described and redefined in the context
of rings. As the applicability of these functions becomes clear, if some of the functions are
redefined for ring applications, the new definitions will be provided in this document.
Bellcore considered the following factors in developing the criteria Sections 6 through 8
provide:
The ability of the ring to restore 100% of the restorable traffic after a single failure
The ability of the ring to restore traffic partially after multiple failures
The ability of the ring to perform the protection switching with no misconnection
Support for some of the switch initiation criteria (e.g., Forced Switch [FS] of working
to protection) Section 6.2.1 provides
The ability to interconnect with other networks, as Section 7 describes
The ability to assign traffic to any time slot in either direction
In-service procedures for moving traffic from one time slot to another, deleting a node,
adding a node, segmenting a ring, and upgrading to a higher SONET rate
The ability of the ring to carry extra traffic on the protection time slots
The ability of the ring to provide VT-access
The ability of the ring to support unidirectional circuits in addition to conventional
duplex (bidirectional) circuits.
The ability of the ring to carry enhanced non-preemptible unprotected traffic on
channels provisioned as enhanced non-preemptible unprotected channels.
As the above procedures are clarified, with the ongoing standardization of the K1 and K2
bytes, the criteria will be expanded.
SONET BLSR Equipment Generic Criteria GR1230CORE
Functions Needed for NE Deployment in a BLSR Issue 4, December 1998

5-2
6-1
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Equipment Criteria and K1/K2 Byte Protocol

6. Equipment Criteria and K1/K2 Byte Protocol
The equipment criteria provided in this section reflect Bellcores view based on the current
agreements in T1X1. When the T1X1 and Bellcore protocol work is completed, the
requirements and objectives will be updated.
Unidirectional service on the bidirectional ring can be supported if the assumption that all
circuits are provisioned bidirectionally is dropped. This entails updating the STS squelch
table to reflect unidirectional circuit routing. Figure 8-3 illustrates the information
contained in a squelch table.
Section 6.1 provides the general equipment criteria for an NE to be used in a BLSR. Section
6.2 describes the actual protocol to be used, the switch initiation criteria, and the rules for
sourcing, passing through, and terminating the K1 and K2 bytes.
6.1 Equipment Criteria
This section provides the general equipment criteria for BLSRs. Section 6.1.1 provides
requirements for both 2- and 4-fiber rings. Sections 6.1.2 and 6.1.3 provide requirements
for NEs to be used in 2- and 4-fiber rings, respectively.
6.1.1 Equipment Criteria for 2- and 4-Fiber Ring
R6-1 [1] The NE on a ring shall operate at a standard SONET rate. All the
nodes on the ring shall operate at the same rate.
R6-2 [2] A ring switching capability using the ring protection switching
protocol described in Section 6.2 shall be provided.
R6-3 [3] The ring APS protocol shall be carried on bytes K1 and K2 defined
only on the first STS-1 of an OC-N line carrying protection channels.
R6-4 [4] Protection bandwidth shall restore 100% of the restorable traffic for
any single failure, including when the failure segments the ring.
R6-5 [5] The NE shall be capable of supporting a protection switching
algorithm for up to 16 (see Section 6.2.2) nodes (i.e., the APS bytes, ring
map, etc., shall provide support for 16 nodes).
R6-6 [6] Node ID assignment shall not be required to be consecutive for correct
operation.
SONET BLSR Equipment Generic Criteria GR1230CORE
Equipment Criteria and K1/K2 Byte Protocol Issue 4, December 1998

6-2
R6-7 [7] For all automatically initiated bridge requests, the request shall use the
K1 and the K2 bytes of the SONET line overhead.
R6-8 [8] For externally initiated bridge requests that are included in the K1 byte
protocol, the K1 and K2 bytes shall be used.
R6-9 [9] For externally initiated requests that are not included in the K1 byte
protocol, the Section DCC shall be used. (See Section 8 for criteria on the
DCC channel.)
R6-10 [10] The NE shall be capable of passing through the K1 and K2 bytes.
(See Section 6.2 for rules on APS byte generation and pass-through.)
R6-11 [11] The NE shall meet the switch initiation time criteria in Section 5.3.3
of GR253CORE for all the Line Signal Fail (SF) and Line Signal
Degrade (SD) conditions.
R6-12 [12] The NE shall meet the clearing time criteria in Section 5.3.4 of
GR253CORE for all the Line Signal Fail (SF) and Line Signal Degrade
(SD) conditions.
R6-13 [13] The end-to-end switch completion time for a single ring or span
switch on a clean ring (as Section 2 defines) with less than 1200 km of fiber
and 16 nodes shall not exceed 50 ms. The switch completion time does not
include detection time.
R6-14 [14] The end-to-end switch completion time for any ring or span switch
[when R6-13 is not applicable] shall not exceed 100 ms after detection.
The extra 50 ms is used to pre-empt existing switches, to remove extra traffic from the
protection channels, or to allow squelching of individual VTs at VT access nodes.
O6-15 [15] It is an objective that the end-to-end switch completion time for any
ring or span switch not exceed 50 ms after detection.
R6-16 [16] Changing the bridge request type for an already initiated protection
switch request (span or ring) shall not increase the switch completion time.
For example, if a signal degrade span switch request is changed to a signal
failure span switch request for the same span, it shall not take any
additional time to complete the switch.
One advantage of BLSRs is that working traffic can be routed on the ring in either of the
two different directions, the long route around the ring or the short route. Although the short
route will usually be preferred, occasionally routing working traffic over the long route
permits some load balancing.
6-3
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Equipment Criteria and K1/K2 Byte Protocol

R6-17 [18] The NE shall be able to allow traffic from one time slot to be
reassigned to another time slot while in service. This includes (1)
reassignment to another time slot on the same route (i.e., the short route or
the long route around the ring), and (2) reassignment to the same or
different time slot on the other route (i.e., from short to long, or long to
short).
This feature may be used to allow in-service load balancing.
R6-18 [19] The associated squelch tables must be updated to reflect the new
traffic reassignment.
R6-19 [20] When traffic is being moved from one time slot to another time slot,
in response to a switch request or for provisioning, the length of the hit
caused by switching (i.e., interruption in error-free traffic) shall not exceed
50 ms per direction.
R6-20 [21] When traffic is being moved from one time slot to another time slot,
the number of Severely Errored Seconds (SESs) caused by switching shall
not exceed 2.
R6-21 [22] The NE shall not reassign the time slots that are provisioned to
continue-through (i.e., the NE shall restrict the continue-through cross-
connects to using the same time slot on both lines of the ring). Performing
a ring switch is not considered reassignment. For secondary circuits in a
ring interworking application, R6-22 shall take precedence.
If the NE is allowed to reassign the time slots, the use of the bandwidth can be maximized.
However, the ring switch would require the entire traffic route, including cross-connection
information, at every intermediate node, and the APS protocol would be more complicated.
Thus, the ring switch is performed under the assumption that the time slot number of the
traffic remains the same until it is terminated. This restriction has minimal effect on the use
of the BLSRs capacity. However, the maximum span capacity may not be realized for
some traffic patterns.
R6-22 [23] To support drop and continue on protection for ring interworking
applications, the NE shall be allowed to reassign the time slots that are
provisioned to continue-through such that:
For an OC-N 2-fiber ring, working channel STS-M shall be reassigned
to protection channel STS-(N/2 + M), where M is an integer between
1 and N/2, inclusive.
For an OC-N 4-fiber ring, working channel STS-M shall be reassigned
to protection channel STS-M, where M is an integer between 1 and N,
inclusive.
SONET BLSR Equipment Generic Criteria GR1230CORE
Equipment Criteria and K1/K2 Byte Protocol Issue 4, December 1998

6-4
R6-23 [27] The NE shall allow 50% to 100% of the rings span capacity to be
terminated from each direction when no extra traffic is on the ring.
The rings span capacity is defined to be the working capacity, or the working bandwidth,
on the ring. For a 4-fiber OC-N ring, the span capacity is N STS-1s. For a 2-fiber OC-N
ring, the span capacity is N/2 STS-1s.
R6-24 [28] The NE shall be able to bridge the working channels to preassigned
(not user-settable) protection channels and select from the preassigned
protection channels to perform protection switching.
R6-25 [29] When the ring switch is in effect, the NE shall carry (bridge) traffic
on both the protection and the working channels.
R6-26 [30] When a segment of the ring fails and a ring switch is to be performed,
the NE adjacent to the failed segment shall perform the ring switch.
CR6-27 [31] A NE may be required to support VT-level access.
R6-28 [32] Nodes with VT-access capability shall be able to cross-connect (i.e.,
add, drop, pass-through, and drop-and-continue) VTs from the VT-
accessed STSs.
When multiple nodes on the ring with VT access add VTs or cross-connect VTs between
STSs, the payload for a given STS may have multiple source nodes, or be dropped among
multiples nodes. Such STSs are referred to as VT-accessed STSs.
CR6-29 [33] Protection channels may be required to be available to provide extra
traffic.
R6-30 [34] A NE that allows extra traffic shall support extra traffic on both sides
of the node.
R6-31 [35] The capability to assign each timeslot for add/drop, pass through, or
drop-and-continue as in Figure 3-5, configuration (3) illustartes, shall
apply to the protection channels for NEs that allow extra traffic.
R6-32 [36] A NE that allows extra traffic shall support extra add/drop ports for
the protection span capacity.
The regular add/drop ports that are used for working channel traffic may be used for extra
traffic if they are available. The number of extra add/drop ports will depend on the
percentage of the protection channels accessible for extra traffic.
R6-33 [37] Timeslot assignment of the extra traffic STS shall be supported.
6-5
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Equipment Criteria and K1/K2 Byte Protocol

R6-34 [38] Extra traffic shall be removed when the protection channels are
needed for protection of working traffic according to the priority Section
6.2 provides.
R6-35 [39] The nodes performing the ring switch shall bridge all the pass
through time slots, as well as the added traffic, from the spans in the
direction of the failure to the spans away from the failure, according to the
appropriate time slot correspondence provided in either Section 6.1.2 or
6.1.3.
R6-36 [40] When the head-end node performs a ring switch, the working
channels being accessed in the affected direction shall be bridged onto and
received from the corresponding protection channels in the direction away
from the failure (i.e., the tail-end node has to perform the mapping from
the protection channels to the working channels).
R6-37 [41] The NE on the ring shall allow an in-service addition of a node. (See
the forced switch - ring command in Section 6.2.1.1.2.)
R6-38 [42] When a node is added to the ring, the length of the hit caused by
switching shall not exceed 50 ms per direction while performing the ring
switch, and 50 ms per direction while reverting to working channels.
R6-39 [43] The NE on the ring shall allow an in-service deletion of a node. All
regular and extra traffic added/dropped at the node is manually removed
before the initiation of any request for this purpose. (See the forced switch
- ring command in Section 6.2.1.1.2.)
R6-40 [44] When a node is deleted from the ring, the length of the hit caused by
switching shall not exceed 50 ms per direction while performing the ring
switch, and 50 ms per direction while reverting to working channels.
R6-41 [45] The NE shall support the capability to segment the ring into multiple
rings in response to a failure (or multiple failures) that isolates some nodes.
Traffic among the nodes in any segment shall remain in-service during the
failure.
R6-42 [46] The NE shall support the capability to segment the ring into multiple
rings in response to high priority, manually initiated commands. (See the
forced switch - ring command in Section 6.2.1.1.2.)
This capability can be used to split a single ring into two independent rings if the number
of nodes on the ring is excessive or approaches the maximum number of nodes allowed on
a BLSR.
SONET BLSR Equipment Generic Criteria GR1230CORE
Equipment Criteria and K1/K2 Byte Protocol Issue 4, December 1998

6-6
R6-43 [47] The NE shall not segment the ring in response to multiple ring bridge
requests with priority of signal degrade or lower (see Table 6-1 in Section
6.2.2).
O6-44 [48] It is desirable that the NE on the ring allow an in-service upgrade to
a higher SONET rate (i.e., while the ring is being upgraded, all the nodes
operate at the previous rate until the upgrade is completed).
R6-45 [49] The NE shall not misconnect traffic regardless of the number of
failures (i.e., the NE shall prevent misconnection of traffic
deterministically by squelching).
R6-46 [50] Squelching shall be carried out according to the protocol in Section
6.2.2.
R6-47 [51] Squelched traffic shall be replaced by inserting STS-path AIS (AIS-
P).
R6-48 [52] Each node on the ring shall maintain the following information:
A node ID that must be unique in a single ring and must be between 0
and 15, inclusive.
A ring topology map (ring map), or sequence of node IDs to be used
for identifying nodes that have been isolated when failures occur at
one or more points on the ring.
A squelch table that contains, for each STS time slot that the node is
terminating (adding/dropping) or passing through, the first source
node ID of the STS entering the node and the last destination node ID
of the STS exiting the node.
CR6-49 [53] If VT access is supported by any node on the ring, each node on the
ring shall maintain squelch tables that indicate which STS SPEs are
terminated and accessed at the VT level anywhere on the ring.
CR6-50 [54] If VT access is supported, each node on the ring that has VT access
capability shall maintain, in addition to the information in R6-48 and CR6-
49, a VT-level squelch table that contains, for each VT time slot that the
node is dropping, the VT group number, channel number, and the source
node ID of the VT it is dropping to allow squelching of traffic in case of
node failures.
For VTs that are dropped and continued in conjunction with a service
selector for ring interconnection, both the primary and secondary nodes
shall be identified as the source node.
6-7
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Equipment Criteria and K1/K2 Byte Protocol

R6-51 [55] The ring map along with the node IDs indicated in the K1 and K2
bytes shall be used to identify the traffic to be squelched.
CR6-52 [293] The BLSR may be required to support Enhanced Non-preemptible
Unprotected Traffic (E-NUT).
R6-53 [294] If E-NUT is supported on the ring, each node on the ring shall
maintain a E-NUT table. The E-NUT table shall indicate the type of
protection that is not available for each working STS time-slot in each
direction. See Figure 3-26 for an example of an E-NUT table.
6.1.2 Equipment Criteria for 4-Fiber BLSRs Only
R6-54 [56] Two fibers shall be used for working channels, and two fibers shall
be used for protection channels.
R6-55 [57] The relationship between the working and the preassigned protection
channels on the paired working and protection fibers shall be as follows:
Protection channel # at the multiplex input = working channel # at the
multiplex input.
R6-56 [58] A span switching capability consistent with the protocol in Section
6.2 shall be provided.
R6-57 [59] A span switch request shall be used when possible instead of the ring
switch request.
R6-58 [60] When protecting the failed span using the span switching capability,
both nodes adjacent to the failed span shall switch the entire line with no
change in time slot numbers.
O6-59 [61] It is desirable that the NE on the ring allow an in-service upgrade
from a route diversified point-to-point system to a ring (e.g., from a 1+1
system to a ring).
6.1.3 Equipment Criteria for 2-Fiber BLSRs Only
R6-60 [62] For a 2-fiber BLSR operating at an OC-N rate where N is even, the
first (N/2) time slots at the multiplex input shall be assigned for working
channels, and the last (N/2) time slots at the multiplex input shall be
assigned for protection channels. At the high-speed (multiplex output)
SONET BLSR Equipment Generic Criteria GR1230CORE
Equipment Criteria and K1/K2 Byte Protocol Issue 4, December 1998

6-8
side, the protection channels are not contiguous because of the
multiplexing rules for SONET.
R6-61 [63] The relationship between the working and the preassigned protection
channels shall be as follows:
Protection channel # at the multiplex input = working channel # at the
multiplex input + (N/2); N is even.
Thus, working channel #1 at the multiplex input in one direction is protected using
protection channel # [(N/2) + 1] at the multiplex input of the other direction, where N is
even.
6.2 Switch Initiation and K1 and K2 Protocol
Two 64-kb/s transport overhead channels in the SONET frame format are dedicated to
exchanging signaling information between NEs for protection switching activity.
1
These
overhead channels are bytes K1 and K2 in the transport overhead of STS-1 #1 of the
protection line. In a BLSR, these bytes relay protection information among all the nodes on
the ring. In the SONET environment, the goal has always been to allow inter-vendor
compatibility. Some of the rings in future networks may not be operated (deployed) by a
single user and may not be from the same vendor. Therefore, it is necessary to have a
standard protocol that allows interworking.
The ANSI Working Group T1X1.5 has defined the APS protocol for BLSRs. The protocol
is defined in ANSI T1.105.01-1998. The material provided in this issue of GR-1230-CORE
reflects Bellcore's view based on the current T1X1 standards in T1.105.01-1998 for a
BLSR protocol at the time this issue was released.
Section 6.2.1 provides switch initiation criteria, and Section 6.2.2 provides the details of the
bit-oriented protocol of the K1 and K2 bytes of the SONET overhead.
6.2.1 Switch Initiation Criteria
The requests to perform protection switching can be initiated either externally or
automatically. Externally initiated commands are entered by way of an Operations System
(OS) or a Work Station (WS) interface. Section 6.2.1.1 describes these externally initiated
commands available at the OS, or WS interfaces. Protection switching requests can also be
initiated automatically based on line and equipment performance criteria. Section 6.2.1.2
provides the automatic switch initiation criteria. Some requests are also transmitted to
indicate the state of the protection facility to the other NEs on the ring. Because these
1. Some bits are also used for maintenance signals (see GR253CORE).
6-9
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Equipment Criteria and K1/K2 Byte Protocol

requests are also initiated automatically (i.e., not on demand), they are included in Section
6.2.1.2. Section 6.2.1.3 provides functional requirements.
The requests related to span switching (except for lockout of protection) are used only for
4-fiber BLSRs. The No Request code is transmitted when there is no need to use the
protection channels.
6.2.1.1 Externally Initiated Protection Switching Commands (OS or WS)
External protection switching requests may be initiated via the OS or WS interface.
Because the originator of the external request is either an OS or WS, the external request is
transmitted from an OS/WS to the NE. The requests are evaluated by the priority logic in
the APS controller.
The externally initiated requests may or may not be transmitted to the appropriate NE over
the K1 and K2 bytes. Some commands are used to modify the protection switching
operation and facilitate queries about the ring status. They are initiated locally or remotely
by the technician. If they are not transmitted over the APS bytes, no pre-emption priority
on the K1 byte is assigned to them. For example, the lockout of working channels
command may be transmitted over the Section DCC, and no pre-emption priority
assignment is needed.
6.2.1.1.1 Commands Not Signaled on the APS Channel
The descriptions of the externally initiated commands that are transmitted from an OS or
WS to the NE are provided below.
Clear
This command clears externally initiated switch commands. It also clears the Wait to
Restore (WTR) state of the node to which the command is addressed. The NE-to-NE
signaling following removal of the externally initiated commands (if no other requests
are active on the ring) is performed using the No Request code.
The following two commands are useful if one span (line) has excessive switching to
protection. Another use for these commands includes blocking protection access on some
spans that have only traffic that does not need protection. The commands are not time-
critical (i.e., need not be completed in tens of milliseconds). Thus, they can be transmitted
over the Section DCC. See Section 8 for Operations, Administration, Maintenance, and
Provisioning (OAM&P) criteria.
Lockout of working channels - ring switch (LOW-R)
This command prevents the working channels over the addressed span from accessing
the protection channels for a ring switch by disabling the nodes capability to request
SONET BLSR Equipment Generic Criteria GR1230CORE
Equipment Criteria and K1/K2 Byte Protocol Issue 4, December 1998

6-10
a ring switch for the working channels on the addressed span. If any working channel
is already on protection, the ring switch is dropped regardless of the condition of the
working channels. If no other requests are active on the ring, the No Request code is
transmitted. This is because the lockout of protection command supported on the K1
byte applies only for the protection channels and not for the working channels. This
command has no impact on the use of the protection channels for any other span. For
example, the node can go into any one of the pass-through modes.
Lockout of working channels - span switch (LOW-S)
This command prevents the working channels over the addressed span from accessing
the protection channels for a span switch. If any working channel is already on
protection, the span switch is dropped regardless of the condition of the working
channels. If no other requests are active on the ring, the No Request code is
transmitted. The command has no impact on the use of the protection channels for any
other span.
Lockout of protection - all spans
This command prevents protection switching on the entire ring. If any working traffic
is using the protection channels on any span, this command causes traffic to switch
back to the working channels regardless of the condition of the working channels. The
K1 and K2 bytes do not support this command. Thus, the command has to be sent to
each of the NEs and the lockout of protection - span (LP-S) request is used by each
NE to coordinate activities with the far end.
6.2.1.1.2 Commands Signaled on the APS Channel
The following commands are carried over the K1 and K2 bytes:
Lockout of protection span (LP-S)
This command prevents the use of the span for any protection activity, and prevents
ring switches anywhere in the ring. If any ring switches exist in the ring, this command
causes the switches to drop. If there is a span switch for this span, it is dropped. Thus,
all ring switching is prevented (and preempted) and span switching is prevented only
on the locked out span. This command is applicable to both two-fiber and four-fiber
BLSRs.
Forced switch ring (FS-R)
This command performs the ring switch from the working channels to the protection
channels for the span between the node at which the command is initiated and the
adjacent node to which the command is destined. This switch occurs regardless of the
state of the protection channels, unless the protection channels are satisfying a higher
priority request.
6-11
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Equipment Criteria and K1/K2 Byte Protocol

Forced switch - span (FS-S)
This command performs the span switch from the working channels to the protection
channels over the same span for which the command was initiated. This occurs
regardless of the state of the protection channels, unless the protection channels are
satisfying a higher priority request or a signal failure (or a K1 and K2 byte failure)
exists on the protection channels of the addressed span.
Manual switch - ring (MS-R)
This command performs the ring switch from the working channels to the protection
channels for the span between the node at which the command is initiated and the node
to which the command is destined. This occurs if the protection channels to be used
are operating at a BER better than the signal degrade threshold and are not satisfying
an equal or higher priority request (including failure of the protection channels).
Manual switch - span (MS-S)
This command switches the traffic from the working channels to the protection
channels over the same span for which the command was initiated. This occurs if the
protection channels to be used are operating at a BER better than the signal degrade
threshold and are not satisfying an equal or higher priority request (including failure
of the protection channels).
In general, failures of protection switching equipment are alarmed immediately and
repaired promptly. Nonalarmed, silent failures cause greater concern. Silent failures cause
no trouble until a bridge request is made, which makes the protection facility unavailable
when it is most needed. In a BLSR, because the protection facility is shared among all the
nodes on the ring, the exerciser function is essential. An undetected failure in one span
makes ring switching impossible for all the spans on the ring. Thus, the probability of
having silent failures is reduced by exercising the APS controller. If a failure is detected
during an exercise or any diagnostic routine, unless the failure is service affecting, no
protection switching request is initiated. An alarm is generated to facilitate prompt repair.
TRNWT000499, Transport Systems Generic Requirements (TSGR): Common
Requirements, describes two exercise routines. The first routine tests all protection
switching functions up to, but not including, the switch. The second routine is controlled
externally and completes the switch. If either of these routines is used, the traffic will incur
hits during exercising. In this GR, the exerciser commands do not complete the bridge and
the switch. The descriptions of the exercise commands provided in BLSRs are as follows:
Exercise - ring (EXER-R)
This command exercises ring protection switching of the requested channel without
completing the actual bridge and switch. The command is issued and the responses are
checked, but no working traffic or extra traffic is affected.
Exercise - span (EXER-S)
SONET BLSR Equipment Generic Criteria GR1230CORE
Equipment Criteria and K1/K2 Byte Protocol Issue 4, December 1998

6-12
This command exercises span protection switching of the requested channel without
completing the actual bridge and switch. The command is issued and the responses are
checked, but no working traffic or extra traffic is affected.
6.2.1.2 Automatically Initiated Protection Switch Requests
Protection switching requests are also initiated based on equipment and line performance
criteria detected by the NE. All the working and protection channels are monitored and all
threshold-crossing conditions are reported, regardless of the failure or degradation
conditions (i.e., after a switch has been completed, all appropriate performance monitoring
data is still collected), as GR253CORE specifies. The NE initiates the following bridge
requests automatically (as opposed to on demand): Signal Fail-Protection (SF-Protection),
Signal Fail (SF), Signal Degrade (SD), Reverse Request (RR), and WTR. The requests are
transmitted from NE to NE (not from OS to NE).
The SF request is used to protect working traffic affected by a hard failure, while the SD
request is used to protect against a soft failure (see GR253CORE for descriptions of Line
Signal Fail and Line Signal Degrade). The requests for switching are transmitted on both
the short and the long paths. Each intermediate node verifies the destination node ID of the
long path request and relays the request. Each node has to verify the switch request for three
consecutive frames before taking any action. The destination node receives the request,
performs the activity according to the priority level, and sends the bridged indication. The
OS receives a notification that a failure or degradation has occurred and whether the
protection attempt was successful.
The WTR request is used to prevent frequent oscillation between the protection channels
and the working channels. The intent is to minimize hits that are incurred during switching.
The WTR request is issued after the working channel's BER meets the restoral threshold.
The hysteresis method of restoral, which GR253CORE provides for the point-to-point
protection switching system, applies for rings as well. The WTR is issued only after a SF
or a SD condition and, thus, does not apply for externally initiated commands. If a SF
clears, and the BER meets the restoral threshold, the NE does not enter the SD condition.
The definitions of the automatically initiated requests are provided below.
Signal fail - span (SF-S)
A SF is defined as a hard failure caused by a Loss of Signal (LOS), a Loss of Frame
(LOF), a line BER exceeding a preselected threshold, a line AIS, or some other
protectable hard failure. The tail end detects the failure and generates the bridge
request. The detection rules, required times, and threshold levels are identical to those
of the point-to-point system GR253CORE provides.
For 4-fiber rings, if the failure affects only the working channels, traffic can be
protected by switching to the protection channels on the same span. The signal fail -
6-13
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Equipment Criteria and K1/K2 Byte Protocol

span request is used to initiate span switching for an SF on the working line of a 4-
fiber ring.
Signal fail - ring (SF-R)
For 2-fiber BLSRs, all channels with SF condition (as defined previously for span
switching) are protected using the ring switch. For 4-fiber rings, to allow multiple
protection switching requests to be completed, the ring switch is used only if traffic
cannot be protected using span switching. If failures exist on both the working and
protection channels within a span, it is necessary to initiate a ring bridge request.
Hence, this request is used to initiate a ring switch for signal failures. For a four-fiber
ring, a SF-R results from the combination of LOW-S and a detected or received
working line failure on the same span or the following combination of detected or
received conditions on the working and protection lines:
working line failed and protection line failed on the same span,
working line failed and protection line degraded on the same span, or
working line degraded and protection line failed on the same span.
Signal fail protection (SF-P)
This command is used to indicate to an adjacent node that the protection channels are
in a SF state. A signal failure on the protection channels is signaled the same way as a
lockout of protection for the span that is affected by the failure. Span switches for the
failed span are prevented (and preempted); however, ring switches that protect the
failed span are allowed. Hence, the K1 byte that is transmitted to the adjacent node is
the same code as that of a Lockout of Protection - Span. Signal Fail - protection is used
only for four-fiber rings.
Signal degrade - span (SD-S)
A SD is defined as a soft failure caused by a BER exceeding a preselected threshold.
It can be used to detect gradual degradation of service to perform preventive
maintenance. The method of processing the line BER code violations to detect the
condition and the threshold requirements are identical to those of the point-to-point
system provided in GR253CORE.
In 4-fiber rings, the working channels of the degraded span can be protected using the
protection channels on the same span. This request is used to switch to the protection
channels in the same span where the failure is located.
Signal degrade - ring (SD-R)
For 2-fiber rings, any degraded line is protected using the ring switch. (Degradation is
defined above under signal degrade - span.) For a four-fiber ring, a SD-R results from
the combination of LOW-S and a detected or received working line degrade on the
same span or the combination of detected or received signal degrade conditions on the
working and protection lines on the same span.
SONET BLSR Equipment Generic Criteria GR1230CORE
Equipment Criteria and K1/K2 Byte Protocol Issue 4, December 1998

6-14
Signal degrade - protection (SD-P)
This request is used to signal a soft failure of the protection channels to the head-end
NE. This request is used only for 4-fiber BLSRs.
Reverse request - span (RR-S)
This request is transmitted to the tail-end NE as an acknowledgment for receiving the
short path span bridge request. The reverse request - span is transmitted on the short
path only.
Reverse request - ring (RR-R)
This request is transmitted to the tail-end NE on the short path as an acknowledgment
for receiving the short path ring bridge request.
Wait to restore (WTR)
This request is issued when working channels meet the restoral threshold after an SD
or SF condition. This request is used to maintain the current state during the WTR
period unless it is pre-empted by a higher priority request. The WTR time is between
5 to 12 minutes for revertive switching. For non-revertive switching, it may be set to
a value that represents infinite WTR time, as specified in Section 8.5.
Infinite WTR time prevents exercise functions from being performed. Infinite WTR
time is not allowed in the WTR criteria GR499CORE provides. The criteria in this
document are extensions of the criteria in GR499CORE and supersede the criteria
in GR499CORE.
6.2.1.3 Functional Requirements
This section provides the functional requirements for the commands Sections 6.2.1.1 and
6.2.1.2 define.
R6-62 [270] The commands described in Sections 6.2.1.1 and 6.2.1.2 shall be
supported by the NE.
R6-63 [64] Each clear command shall remove an externally initiated command
at the addressed NE. The No Request code is used for the NE-to-NE
communication of the clear command. Also, the clear command clears the
WTR state at the addressed NE.
R6-64 [65] A clear command to clear an externally initiated command shall be
received by the same NE that initiated the original request from an
operations channel (i.e., the clear command can be received over the DCC
from another node but cannot be received over the K1 and K2 bytes).
6-15
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Equipment Criteria and K1/K2 Byte Protocol

R6-65 [66] The following requests shall be supported using the K1 and K2 bytes
according to Table 6-1 in Section 6.2.2:
Lockout of protection - span and signal failure of protection - span
Forced switch - span
Forced switch - ring
Signal fail - span
Signal fail - ring
Signal degrade - protection
Signal degrade - span
Signal degrade - ring
Manual switch - span
Manual switch - ring
Wait to restore
Exerciser - span
Exerciser - ring
Reverse request - span
Reverse request - ring
No request.
6.2.2 Bit-Oriented Protocol for K1/K2 Bytes
The protocol this section describes applies for both STS accessed and VT accessed
revertive BLSRs. The non-revertive switching option for automatically initiated requests is
provided using an infinite WTR time. Criteria for VT access, extra traffic, and
unidirectional squelching are addressed in this section. The 2- and 4-fiber BLSRs supported
in this document operate at an OC-N rate, where N is even.
A BLSR can have as many as 16 nodes. Contention among the nodes for the protection
facility may arise when multiple failures occur. Thus, priorities need to be assigned to the
requests and protection switching activity needs to be coordinated. In the SONET
overhead, the K1 and K2 bytes of STS-1 #1 on the protection channel are used to coordinate
switching activity. In addition, bits 6-8 of byte K2 are used on all OC-N line signals to
signal Line RDI and Line AIS. The first four bits of the K1 byte are used to identify the
priority level. Bits 5-8 of the K1 byte are used for the node ID of the node requested to
bridge, and bits 1-4 of the K2 byte are used for the node ID of the node requesting the
SONET BLSR Equipment Generic Criteria GR1230CORE
Equipment Criteria and K1/K2 Byte Protocol Issue 4, December 1998

6-16
bridge. Bit 5 of the K2 byte is used to indicate short versus long path. Bits 6-8 of the K2
byte are used to indicate the status of the bridge and the switch, Extra Traffic, Line AIS,
and Line Remote Defect Indication (RDI). Because there are only 4 bits available to
identify the source node, the number of nodes on a ring cannot exceed 16. If multiple
failures occur on the ring, the request may not reach the destination node. However, a
confirmation is received from the node adjacent to the other failure.
Before the first occurrence of a bridge request, all nodes are in an idle state. When a node
generates a request, the request is relayed to other nodes on the ring. A node receiving the
request verifies it for three consecutive frames. If the request is destined to another node,
the node enters the appropriate pass-through state according to the criteria in this section.
If the request is at its final destination, the appropriate bridge and/or switch action is
performed and a confirmation is transmitted. The node that originated the request waits for
a response (or another request of equal or higher priority). When the intermediate nodes are
in the full pass-through state, the node that originated the request receives the K bytes from
the far end. If a response is not received within a specific waiting period, the failure to
complete the switch is reported (see Section 8 for OAM&P criteria).
In general, the switch is completed after a bridge confirmation is received from the far end
to minimize the time that traffic is interrupted. However, in the case of a signal failure
requiring a ring switch because the traffic is already interrupted, the switch is performed
when the crossing K bytes are received. For SFs that require ring switching, either two
crossing requests or a request and a response can be used to perform the bridging and
switching activities and, if necessary, the squelching activity.
The general criteria for the K1 and K2 bytes are provided below. The specific criteria that
depend on the state of the ring node are in Sections 6.2.2.1 and 6.2.2.2.
R6-66 [67] All BLSR protection switching shall be performed bidirectionally.
R6-67 [68] All protection switching (ring and span) shall be revertive. This
requirement does not exclude the use of the infinite WTR time to provide
the non-revertive mode of operation.
R6-68 [69] For 4-fiber BLSRs, a switch shall revert only from the protection
channels to the working channels, and never to the other protection
channels. For example, if protection is provided using a ring switch during
a cable cut, and the protection channels on the failed span are repaired
before the working channels, the traffic that is already protected shall not
revert unless the ring request is pre-empted or the working channels are
repaired.
R6-69 [70] K1 bits 1-4 shall carry bridge request priorities according to the pre-
emption priority (in descending order) provided in Table 6-1.
6-17
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Equipment Criteria and K1/K2 Byte Protocol

R6-70 [71] Reverse Request shall assume the same priority of the request to
which it is responding.
R6-71 [72] K1 bits 5-8 shall carry the destination node ID for the bridge request
indicated in K1 bits 1-4.
R6-72 [73] The destination node ID used in a bridge request by a switching node
shall always be that of an adjacent node.
a. LP-S shall have the same priority as LOW-R, LOW-S and LP-all spans. Note that
each of these commands are allowed to coexist.
b. Reverse request assumes the priority of the request to which it is responding.
Table 6-1. K1 Bit Assignments
Bits 1-4 Request Pre-emption Priority
Bits Priority
1111 Lockout of Protection (span) [LP-S] or
Signal Fail (protection) [SF-P]
a
1110 Forced Switch (span) [FS-S]
1101 Forced Switch (ring) [FS-R]
1100 Signal Fail (span) [SF-S]
1011 Signal Fail (ring) [SF-R]
1010 Signal Degrade (protection) [SD-P]
1001 Signal Degrade (span) [SD-S]
1000 Signal Degrade (ring) [SD-R]
0111 Manual Switch (span) [MS-S]
0110 Manual Switch (ring) [MS-R]
0101 Wait To Restore [WTR]
0100 Exerciser (span) [EXER-S]
0011 Exerciser (ring) [EXER-R]
0010 Reverse Request (span)
b
[RR-S]
0001 Reverse Request (ring)
b
[RR-R]
0000 No Request [NR]
Bits 5-8 Destination Node ID - These bits shall indicate the
node ID of the node to which the K1 byte is destined
The Destination Node ID is always that of an
adjacent node (except for default APS bytes).
SONET BLSR Equipment Generic Criteria GR1230CORE
Equipment Criteria and K1/K2 Byte Protocol Issue 4, December 1998

6-18
R6-73 [74] There shall be no high priority assignment of a span (i.e., there shall
be no higher priority spans that would allow ring switches for that span to
override automatically other span switches of the same type [e.g., SF, SD,
or FS]).
R6-74 [75] The bits in the K2 byte shall be assigned as Table 6-2 shows.
R6-75 [76] The transmission of either Idle, Bridged, or Bridged and Switched in
byte K2 bits 6-8 shall indicate that extra traffic has been squelched.
R6-76 [77] Extra traffic carried on the protection channels shall have the lowest
priority level.
R6-77 [78] If a node detects an APS controller failure while performing
diagnostics or during an exercise, and there is no transmission failure for
that line, no bridge request shall be initiated.
The above requirement implies that failures of the protection switching mechanism (e.g.,
an adjacent node sending the wrong ID) do not cause ring segmentation. APS failure of a
line is not equivalent to signal failure of the line for BLSRs.
The APS code inserted in the K1 and K2 bytes by a node depends on the state of the node.
There are three types of ring node states: the idle state, the switching state, and the pass-
through state. Section 6.2.2.1 provides the steady state behavior of the node at each of the
three states. Section 6.2.2.2 provides the transition rules among the states. Section 6.2.2.3
provides examples.
Table 6-2. K2 Bit Assignments
Bits 1-4 These bits shall always indicate the node ID of the node sourcing
the request.
Bit 5 This bit shall indicate if the bridge request in byte K1 bits 1-4 is
a short path request (0) or a long path request (1).
Bits 6-8 111 = Line AIS
110 = Line RDI
101 = Reserved for future use
100 = Reserved for future use
011 = Extra Traffic (ET) on Protection Channels
010 = Bridged and Switched (Br & Sw)
001 = Bridged (Br)
000 = Idle
6-19
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Equipment Criteria and K1/K2 Byte Protocol

The following switching rules reflected in these requirements apply conceptually to a single
APS controller operating at a node and choosing switching and signaling actions for both
sides of the node, based on all incoming K-byte signaling from both directions, detected
failures on both sides, local equipment failures, and externally-initiated commands. In
general, the controller looks at all incoming information independently, chooses the highest
priority input, and takes action based on that choice.
6.2.2.1 Steady State Behavior
This section outlines the steady state behavior of a node at the idle state, switching state,
and the pass-through state.
The following set of requirements apply to bridge requests:
Rule G #1 Bridge request validation: (Bridge Request and Bridge Request Status
definition)
R6-78 [79] Rule G #1.a (Bridge request): The information contained in byte K1
bits 1-4 shall be considered as a Bridge Request if
These bits indicate one of the ring bridge request codes and byte K2
bit 5 indicates either a long or short path code,
These bits indicate one of the span bridge request codes and byte K2
bit 5 indicates a short path code.
R6-79 [80] Rule G #1.b (Bridge request status): The information contained in
byte K1 bits 1-4 shall be considered as a Bridge Request Status if these bits
indicate one of the span bridge request codes and byte K2 bit 5 indicates a
long path code.
The relationships among bridge request codes, bridge request status codes, and K-byte
indications are shown in Table 6-3.
R6-80 [271] Rule G #1.c: When a four-fiber ring node is in a SF-R or SD-R
condition, and the SF-R or SD-R request cannot be signaled because it is
not allowed to co-exist with other higher priority APS requests at that
Table 6-3. Relationships Between K2 Bit 5 and K1 Bits 1-4
K2 Bit 5
Code
K1 Bits 1-4
Ring Bridge Code Span Bridge Code
Long Path
Short Path
Bridge Request
Bridge Request
Bridge Request Status
Bridge Request
SONET BLSR Equipment Generic Criteria GR1230CORE
Equipment Criteria and K1/K2 Byte Protocol Issue 4, December 1998

6-20
node, the node shall consider the detected or received protection line
condition as a second input to the APS controller.
A. Idle State
R6-81 [81] A node is in the idle state when it is not sourcing or receiving any
APS requests or bridge request status and it is receiving Idle or ET code
from both directions.
Rule I #1 Idle state sourced K-bytes
R6-82 [82] Rule I #1.a: Any node in the idle state not inserting, dropping, or
passing through extra traffic shall source the K-bytes in both directions as
given in Table 6-4.
R6-83 [83] Rule I #1.b: Any node in the idle state inserting, dropping, or passing
through extra traffic shall source the K-bytes shown in Table 6-4 with the
exception that byte K2 bits 6-8 transmitted over any span that contains
extra traffic shall have the value 011 (Extra Traffic code).
R6-84 [84] Until the node has knowledge of the ring map, squelch table, and
node ID, it shall behave in accordance with R6-130 (Rule I-S #3). Table 6-
5 shows the default APS code.
R6-85 [85] Rule I #2 Idle state received K-bytes: Any node in the idle state
shall terminate K1 and K2 bytes in both directions.
B. Switching State
Table 6-4. Byte K1 and K2 Values Sourced in the Idle State
K1 [1-4] = 0000 (No request code)
K1 [5-8] = Destination node ID [see R6-72]
K2 [1-4] = Source node ID
K2 [5] = 0 (short path code)
K2 [6-8] = 000 (idle code)
Table 6-5. Default APS Codes
K1 Byte K2 Byte
X X X X 0 0 0 0 0 0 0 0 X X X X
X: Any value
6-21
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Equipment Criteria and K1/K2 Byte Protocol

R6-86 [86] A node not in the idle or pass-through state is in the switching state.
Rule S #1 Switching state sourced K-bytes
R6-87 [87] Rule S #1.a: Any node in the switching state shall source K-bytes as
shown in Table 6-6.
R6-88 [88] Rule S #1.b: Any node in the switching state (for either span or ring
requests) shall source a bridge request on the short path and a bridge
request (or bridge request status) on the long path. Both the bridge request
and the bridge request status have the same priority (or one of them is a
Reverse Request), and protect the same span. Exceptions to this can occur
when there are more than one switch requests active at a node. These
exceptions are listed below.
The isolated node cases are described in R6-89 (Rule S #1.c) and R6-
90 (Rule S #1.d).
In the case of a span bridge request on each side of the node, the node
shall source a bridge request on each short path, where the status bits
indicate the state of the bridge and switch for the corresponding span.
The case of a ring bridge request preempting a span bridge request on
an adjacent span is described in R6-142 (Rule S-S #2.b).
Cases where SF-P or SD-P coexists with a ring switch on the same
span. Table 6-7 defines the signaling for these cases.
R6-89 [89] Rule S #1.c: Whenever a node in the ring switching state terminates
a new short path bridge request from an adjacent node, of equal or higher
priority than the request it is currently executing, over the same span, it
shall source a bridge request of the same priority on the corresponding long
path. Whenever a node receives ring bridge requests on both short paths
from its adjacent nodes, the long path bridge request shall be signaled
rather than the short path Reverse Requests. This rule takes precedence
Table 6-6. Byte K1 and K2 Values Sourced in the Switching State
K1 [1-4] = Request code
K1 [5-8] = Destination node ID [see R6-72]
K2 [1-4] = Source node ID
K2 [5] = 0/1 (short/long path code)
K2 [6-8] = Status code
SONET BLSR Equipment Generic Criteria GR1230CORE
Equipment Criteria and K1/K2 Byte Protocol Issue 4, December 1998

6-22
over R6-88 (Rule S #1.b) in case of multiple bridge requests at the same
node. (See Figure 6-1, case a.)
R6-90 [90] Rule S #1.d: Whenever a node detects one or more of the following:
a) an incoming condition requiring a ring switch, or b) an externally
initiated command for a ring switch applied at that node, it shall always
source over the short path a short path ring bridge request as long as the
ring bridge request is not preempted by a higher priority bridge request.
(See Figure 6-1, case b.) This rule takes precedence over R6-89 (Rule S
#1.c). Note that, whenever a node receives in one direction a short path
ring bridge request on one side, and detects one of the above-mentioned
conditions on the other side, it shall signal the bridge request associated
with that condition. (See Figure 6-1, case c.)
R6-91 [91] Rule S #1.e: A node in the switching state shall insert the ET code in
byte K2 bits 68 on spans that are carrying Extra Traffic.
R6-92 [92] Rule S #2 Switching state received K-bytes: Any node in the
switching state shall terminate K1 and K2 bytes in both directions.
R6-93 [93] Rule S #3 Unidirectional bridge request acknowledgment: As soon
as it receives a bridge request, the node to which it is addressed shall
acknowledge the bridge request by changing byte K1 bits 14 to the
Reverse Request code on the short path, and to the received bridge request
priority on the long path.
Table 6-7. SD-P and SF-P (LP-S) Coexisting with Ring Switches on the Same
Span
Highest Priority
Ring Request
Short Path Conditions Priority Signaled
on Short Path
Working Protection
FS-R clear, SD, or SF SF LP-S
FS-R clear, SD, or SF SD SD-P
FS-R clear, SD, or SF LP-S or SD-P (K-byte) RR-S
SF-R (K-byte) clear SF LP-S
SF-R (K-byte) clear or SD SD SD-P
SD-R (K-byte) clear SD SD-P
MS-R or EXER-R clear SF LP-S
MS-R or EXER-R clear SD SD-P
MS-R or EXER-R clear LP-S or SD-P (K-byte) RR-S
6-23
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Equipment Criteria and K1/K2 Byte Protocol

R6-94 [94] The switching node shall identify the nodes that are missing by
comparing the crossing K byte addresses with the information contained in
the ring map. Using the information on missing nodes and the squelch
table:
If the ring switching node determines that the last termination node is
missing for an STS channel, it shall squelch that channel by inserting
path AIS in the corresponding outgoing protection channel when
performing the ring bridge.
If the ring switching node determines that the first source node is
missing for an STS channel, it shall squelch that channel by inserting
path AIS in the corresponding incoming protection channel when
performing the ring switch.
Note that the combination of the two conditions in R6-94 gives bidirectional
squelching of STSs that are added and dropped at the missing node.
The following set of conditional requirements address VT squelching.
CR6-95 [95] If VT access is supported, VT squelching shall be performed by the
node dropping the VT as follows: the node shall identify the nodes that are
missing as described in R6-94. Using the information on missing nodes
and the squelch table, it shall identify only those VTs that are both dropped
at the node itself and sourced at the missing node(s). The node shall
squelch the identified VTs by inserting the appropriate path AIS in the
drop direction when all the source nodes are determined to be missing.
CR6-96 [96] In addition to R6-94, the VT access switching node shall squelch
according to R6-94, before receiving the bridged and switched indications
in byte K2 bits 6-8, all VT-accessed STSs that are added or dropped at the
missing nodes.
CR6-97 [97] The switching node, upon receiving the bridged and switched
indications in byte K2 bits 6-8 from the far-end switching node, may be
required to unsquelch all VT-accessed STSs.
R6-98 [98] The switching node shall stop squelching STSs when there are no
nodes missing. The STS AIS may still be inserted for other purposes.
R6-99 [99] The switching node shall stop squelching when the bridge is dropped
and the switch is released at the node.
R6-100 [100] An isolated node shall not bridge, switch, or squelch.
Rule S #4 Multiple event coexistence (no pre-emption)
SONET BLSR Equipment Generic Criteria GR1230CORE
Equipment Criteria and K1/K2 Byte Protocol Issue 4, December 1998

6-24
Figure 6-1. Isolated Node Signaling (Signaling States Before B and D Establish a
Ring Bridge and Switch)
X
B
C
X
X
D
X
X
B C
X
D
X
B
C
X
D
X
X
X
X
K1:[SF-R/C]
K2:[B/L/Idle]
K1:[SF-R/C]
K2:[B/S/RDI]
K1:[SF-R/D]
K2:[C/L/Idle]
K1:[SF-R/B]
K2:[C/L/Idle]
K1:[SF-R/C]
K2:[D/S/RDI]
K1:[SF-R/C]
K2:[D/L/Idle]
a) C is told of cuts
K1:[SF-R/C]
K2:[B/L/Idle]
K1:[RR-R/C]
K2:[B/S/Idle]
K1:[SF-R/B]
K2:[C/S/RDI]
K1:[SF-R/D]
K2:[C/S/RDI]
K1:[RR-R/C]
K2:[D/S/Idle]
K1:[SF-R/C]
K2:[D/L/Idle]
b) C detects cuts
K1:[SF-R/C]
K2:[B/L/Idle]
K1:[RR-R/C]
K2:[B/S/Idle]
K1:[SF-R/B]
K2:[C/S/RDI]
K1:[SF-R/B]
K2:[C/L/Idle]
K1:[SF-R/C]
K2:[D/S/RDI]
K1:[SF-R/C]
K2:[D/L/Idle]
c) C is told of cut on one side and detects cut on the other side
Working channels
Protection channels
6-25
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Equipment Criteria and K1/K2 Byte Protocol

R6-101 [101] Rule S #4.a The following switches are allowed to co-exist:
SD-P with any span switch
LP-S or SF-P with any span switch for other spans
SF-P or SD-P with any ring switch for the same span
LP-S with SD-P
LP-S with LP-S
SD-P with SD-P
FS-R with FS-R (ring split into multiple sub-rings)
SF-R with SF-R (ring split into multiple sub-rings)
FS-R with SF-R (ring split into multiple sub-rings)
Any span switch with any other span switch on other spans.
R6-102 [102] Rule S #4.b: When multiple equal priority bridge requests over
different spans of SD-R, MS-R, or EXER-R exist at the same time, no
bridge or switch shall be executed and existing switches and bridges shall
be dropped. The nodes shall signal the switch priority in byte K1, and byte
K2 bits 68 shall be set to Idle.
R6-103 [103] Rule S #5 Loss of Ring Bridge Request: If a node executing a ring
bridge and switch no longer receives a valid ring bridge request on the long
path, it shall drop its ring bridge and switch, and shall signal and act based
on its highest priority input.
Reverse Requests and other allowed coexisting ring bridge requests with a short path code
are considered valid ring bridge requests.
R6-104 [104] Rule S #6 Loss of Span Bridge Request: If a node executing a span
bridge and switch no longer receives a valid span bridge request (on the
short path), it shall drop its span bridge and switch, and shall signal and act
based on its highest priority input.
R6-105 [105] Rule S #7 Extra Traffic: A node in the switching state shall not
pass through extra traffic, unless it is in the switching state due to a LP-S
(signal fail-protection), or a SD-P request. A node in the switching state
due to a WTR for a span switch, or any span request, except LP-S, SD-P,
or EXER-S, shall not source or terminate extra traffic on the short path of
that bridge request. A node in the switching state due to WTR for a ring
switch, or any ring request, except EXER-R, shall not source or terminate
extra traffic.
SONET BLSR Equipment Generic Criteria GR1230CORE
Equipment Criteria and K1/K2 Byte Protocol Issue 4, December 1998

6-26
R6-106 [272] Rule S #8: Whenever a node in the WTR state drops its bridge and
switch before the WTR timer expires, it shall immediately terminate the
WTR and act based on its highest priority input.
R6-107 [273] Rule S #9: A node in a ring switching state that receives the external
command LOW-R for the affected span shall drop its bridge and switch
and shall signal No Request, SF-P, or SD-P. Upon the reception of (1) No
Request in combination with either IDLE or ET code, or (2) bridge request
status from the span away from the LOW-R span, the node shall re-insert
extra traffic that was preempted on that span.
R6-108 [106] When span switches are active, extra traffic shall not be dropped on
spans that are not using its protection channel.
C. Pass-Through State
The following requirements address Rule P #1.
R6-109 [107] A node is in the pass through state when its highest priority APS
request is a bridge request or bridge request status not destined to or
sourced by itself.
There are three types of pass-through: unidirectional full pass-through, bidirectional
full pass-through, and K byte pass-through. Section 2 defines the different kinds of
pass-through states.
R6-110 [108] When a node is in a full pass-through state, the K1 and K2 bytes and
the protection channels shall be passed through. Full pass-through may be
either unidirectional or bidirectional.
R6-111 [109] A node in unidirectional full pass-through shall continue sourcing
the previously sourced K-bytes in the opposite direction, with the
exception that byte K2 bits 6-8 shall reflect the appropriate status code.
R6-112 [110] When a node is in a K byte pass-through state, the K1 and K2 bytes
shall be passed through bidirectionally, with the exception that byte K2
bits 6-8 shall reflect the appropriate status code. A K byte pass-through
node that receives the Extra Traffic code shall source the Idle code in the
opposite direction if no extra traffic exists on the opposite span.
R6-113 [111] Rule P #2 Remaining in the pass-through state during signaling
transitions: When a node that is in a pass-through state receives a long path
ring bridge request destined to itself and another long path ring bridge
request of the same priority destined to another node, the node shall not
6-27
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Equipment Criteria and K1/K2 Byte Protocol

transit to another state. (This rule is necessary for the clearing sequence of
the node failure condition. See Figure 6-10.)
R6-114 [112] Rule P #3 Extra Traffic: A node in full pass-through shall not
source or terminate extra traffic. A node that is in the K-byte pass-through
state can source, terminate, and pass-through extra traffic.
6.2.2.2 State Transition Rules
Section 6.2.2.1 provides the steady state behavior of the three ring node states. This section
provides the transition rules among these different states. The rules that apply for any
transition are listed first. The transition rules that apply only for specific cases follow.
6.2.2.2.1 General Transition Rules
R6-115 [113] Rule Basic #1 State transition triggers: All state transitions are
triggered by an incoming K-byte change, an externally initiated command,
WTR expiration, or locally detected line or equipment performance
criteria. A node shall not change the current state based on a received
default code.
R6-116 [114] A node shall not change the current state unless a trigger is received
from the APS controller.
R6-117 [115] Rule Basic #2 K-byte validation: Before accepting the K-bytes as
valid, the value shall be received identically in three successive frames.
R6-118 [116] Rule Basic #3 K2 bits 6-8 update: All bridge and switch actions
shall be reflected by updating K2 bits 68, unless a RDI-L or AIS-L
condition exists, or the span is carrying extra traffic. A RDI-L condition
shall cause the RDI-L code to override all other codes in byte K2 bits 6-8
on the failed span, except for AIS-L, regardless of the state of the Bridge
and Switch. AIS-L overrides RDI-L and all other codes. RDI-L and AIS-
L terminate at LTEs as specified in GR253CORE. A node shall signal
the ET code on any span that is carrying extra traffic.
R6-119 [117] Rule Basic #4: APS requests shall preempt APS requests in
accordance with Table 6-1, unless the APS requests are allowed to coexist.
Actions resulting from incoming bridge requests shall take priority over
actions resulting from incoming bridge request status signaling regardless
of the priority of each. Bridge request status signaling shall never preempt
a bridge request.
SONET BLSR Equipment Generic Criteria GR1230CORE
Equipment Criteria and K1/K2 Byte Protocol Issue 4, December 1998

6-28
R6-120 [118] A node that preempts extra traffic shall squelch the extra traffic
channels that are preempted in the following manner:
For a node executing a span switch that preempts extra traffic on that
span, extra traffic is squelched by
Inserting AIS on extra traffic channels from that span that are
dropped at that node (i.e., on the low-speed side)
Inserting AIS on extra traffic channels from that span that pass-
through the node (i.e., on the high-speed side), as long as those
protection channels are not required for a protection switch
For a node executing a ring switch, extra traffic is squelched by
inserting AIS on extra traffic channels that are dropped at that node
(i.e., on the low-speed side)
For a node entering full pass-through, extra traffic is squelched by
inserting AIS on extra traffic channels that are dropped at that node
(i.e., on the low-speed side).
6.2.2.2.2 State Dependent Transition Rules
The transition rules in this section apply only to specific ring node states. This section is
organized as follows:
Transition rules between the idle and the pass-through states
Transition rules between the idle and the switching states
Transition rules within the switching state
Transition rules between switching and pass-through states
Transition rules within the pass-through state.
A. Transitions Between the Idle and Pass-Through States
Rule I-P #1 Transition from the idle state to the pass-through state
R6-121 [119] Rule I-P #1.a: The transition from the idle state to the pass-through
state shall be triggered by a valid K-byte change, in any direction, from the
No Request code to any other bridge request code, as long as the new
bridge request is not destined for the node itself. Both directions then move
into pass-through according to R6-122 (Rule I-P #1.b).
R6-122 [120] Rule I-P #1.b: For any span bridge request status, or the EXER-R
bridge request, the intermediate nodes on the long path shall go into K-byte
6-29
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Equipment Criteria and K1/K2 Byte Protocol

pass-through. Actions taken at an intermediate node upon receiving a valid
ring bridge request other than EXER-R are:
For NEs without VT access and without extra traffic, when the node in
the idle state receives a valid ring bridge request in any direction that
is not destined for the node itself, the node shall enter the bidirectional
full pass-through state.
For NEs without VT access and with extra traffic, when the node in the
idle state receives a valid ring bridge request in any direction that is not
destined for the node itself, the node shall drop extra traffic
bidirectionally, and shall enter unidirectional full pass-through, in the
direction of the bridge request only. Upon receiving the crossing K-
bytes, the node shall enter bidirectional full pass-through.
For NEs with VT access and without extra traffic, when the node in the
idle state receives a valid ring bridge request in any direction that is not
destined for the node itself, the node shall enter unidirectional full
pass-through in the direction of the request. Upon receiving the
crossing K-bytes, the node shall determine whether any of the VTs that
it drops requires squelching, and shall squelch accordingly, and then
enter bidirectional full pass-through.
For NEs with VT access and with extra traffic, when the node in the
idle state receives a valid ring bridge request in any direction that is not
destined for the node itself, the node shall drop extra traffic
bidirectionally, and shall enter unidirectional full pass-through in the
direction of the bridge request. Upon receiving the crossing K-bytes,
the node shall determine whether any of the VTs that it drops requires
squelching and shall squelch accordingly, and then enter bidirectional
full pass-through.
R6-123 [121] Rule I-P #2 Transition from the pass-through state to the idle
state: A node shall revert from any pass-through state to the idle state when
it detects No Request codes in byte K1 bits 14 and Idle or ET codes in
byte K2 bits 68, from both directions. Both directions revert
simultaneously. Extra traffic that was preempted shall be re-inserted and
the ET code sourced as defined in R6-83 (Rule I #1.b). A VT access node
shall unsquelch any VTs that it drops that had previously been squelched.
B. Transitions Between the Idle and Switching States
Rule I-S #1 Transition from the idle state to the switching state
R6-124 [122] Rule I-S #1.a: Transition of a NE from the idle state to the switching
state shall be triggered by one of the following conditions:
SONET BLSR Equipment Generic Criteria GR1230CORE
Equipment Criteria and K1/K2 Byte Protocol Issue 4, December 1998

6-30
A valid K-byte change from the No Request (NR) code to any ring
bridge request code received on either the long path or the short path
and destined to that NE
A valid K-byte change from the NR code to any span bridge request
code received on the short path and destined to that NE
An externally initiated command for that NE
The detection of a failure at that NE.
R6-125 [123] Rule I-S #1.b: Actions taken at a switching NE upon receiving a
valid bridge request are (Note that in order to execute a ring bridge and
switch, the bridge request shall be received on the long path. See R6-126
[Rule I-S #1.c].):
For FS-R bridge requests, the node shall check if there is any need for
squelching and squelch accordingly, execute a bridge and insert the
Bridged indication code in byte K2 bits 68 in both directions (with
RDI-L and AIS-L exceptions). Upon receiving a Bridged indication in
byte K2 bits 68 on the bridge request path, the NE shall unsquelch
any VT-accessed STSs that had been squelched, execute a switch and
update byte K2 bits 68 on both paths accordingly.
For SF-R bridge requests, the node shall check if there is any need for
squelching and squelch accordingly, execute a bridge and switch, and
insert in byte K2 bits 68 the Bridged and Switched indication on both
the long and the short path (with RDI-L and AIS-L exceptions). Upon
receiving the Bridged (and Switched) indication in byte K2 bits 68 on
the bridge request path, the NE shall unsquelch any VT-accessed STSs
that had been squelched.
For all other bridge requests, except EXER-S, EXER-R, SD-P, and
LP-S, the node shall execute a bridge and insert the Bridged indication
in byte K2 bits 68 in both directions (with RDI-L and AIS-L
exceptions). Upon receiving a Bridged indication in byte K2 bits 68
on the bridge request path, the NE shall execute a switch and update
byte K2 bits 68, on both paths, accordingly.
For EXER-S, EXER-R, SD-P and LP-S, the node shall signal as for
any other bridge request, but shall not execute the bridge or switch.
Extra traffic shall be dropped immediately on all spans for a ring
switch, or on the span whose protection channels are required for a
span switch.
6-31
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Equipment Criteria and K1/K2 Byte Protocol

No bridge or switch shall be executed while the ET code is received on
the span whose protection channels are required by that bridge and
switch.
R6-126 [124] Rule I-S #1.c: A span switch shall be put up or brought down only
with short path bridge requests. A ring switch shall be put up or brought
down only with long path bridge requests.
R6-127 [125] When a node reverts from the switching state to the idle state, both
directions shall revert simultaneously.
R6-128 [126] Rule I-S #2 Transition from the switching state to the idle state: A
node shall revert from the switching state to the idle state when it detects
NR codes in byte K1 bits 14 and Idle or ET codes in byte K2 bits 68 from
both directions. Except for requests of EXER-S, EXER-R, SD-P, or LP-S,
the transition from the switching state to the idle state shall be a three-step
transition.
1. When a WTR time expires or an externally initiated command is
cleared at a node, and the nodes highest priority input is a Reverse
Request, the node shall drop its switch and signal NR in K1 bits 14
and the Bridged code in K2 bits 68. (Note that this step may be
executed in transitions from the switching state to the pass-through
state.)
2. Upon reception of the No Request code, and of the indication that the
switch has been dropped, the head-end node shall drop its bridge and
its switch, and source the Idle code in both directions, as indicated in
Table 6-4. The indication that the switch has been dropped is received
on the short path for span bridge requests, and on the long path for ring
bridge requests.
3. Once the tail-end detects incoming Idle codes, it shall also drop its
bridge and source the Idle code in both directions. Extra traffic that
was preempted shall be re-inserted and the ET code sourced as defined
in R6-83 (Rule I #1.b). A LP-S code due to a signal fail-protection, that
was preempted, shall be reinserted. A VT-access node shall unsquelch
any VTs that it drops that had previously been squelched.
4. Once the head-end detects incoming Idle or ET codes from both
directions, it shall revert to idle state. Extra traffic that was preempted
shall be re-inserted and the ET code sourced as defined in R6-83 (Rule
I #1.b). A LP-S code due to a signal fail-protection, that was
preempted, shall be reinserted. A VT-access node shall unsquelch any
VTs that it drops that had previously been squelched.
SONET BLSR Equipment Generic Criteria GR1230CORE
Equipment Criteria and K1/K2 Byte Protocol Issue 4, December 1998

6-32
For the transition from EXER-S, EXER-R, SD-P, or LP-S to the idle state, there is no
switch to be released and no bridge to be dropped.
R6-129 [127] For transitions from the switching states of EXER-S, EXER-R, SD-
P, or LP-S to the idle state, the NE that initiated the request (i.e., the tail-
end) shall signal the No Request (Idle) code. Upon reception of the NR
code, the head-end shall also source the NR (Idle) code.
R6-130 [128] Rule I-S #3: A node shall transmit the default APS code as Table 6-
5 defines until it is capable of proper APS signaling in accordance with the
current state of the ring. The default APS code shall be used to indicate that
the node can not properly signal APS bytes, and therefore cannot properly
execute protection switching.
R6-131 [129] Rule I-S #4: A ring (span) switching node receiving the default APS
code or invalid K-bytes on the short (long) path shall not change its
signaling or take any action associated with that path until proper APS
codes are received.
A ring (span) switching node receiving default APS code or invalid K-
bytes on the long (short) path shall drop its bridge and switch.
R6-132 [130] Rule I-S #5: A switching node that is not bridged or switched that
receives long path ring bridge requests destined to itself from both its
neighbors shall take no action based on these requests.
R6-133 [131] Rule I-S #6: If a switching node receives the APS bytes that it is
sourcing in both directions, and receives no other APS request, it shall
transition to the idle state. Otherwise, the switching node shall signal
according to its highest priority input.
R6-134 [132] Rule I-S #7: When a node receives a Reverse Request code over the
span that it is protecting, and when that same node is sending a Reverse
Request indication, it shall drop its bridge and switch as described in R6-
128 (Rule I-S #2), except for bridge request status or bridge requests of a
signal fail and signal degrade priority. For signal fail and signal degrade,
the node shall drop the switch and bridge after the expiration of the WTR
time according to R6-149 (Rule S-S #3a). (See also Figures 6-6 and 6-7.)
C. Transitions Within the Switching State
Rule S-S #1 Transition from the switching state to the switching state
R6-135 [133] Rule S-S #1.a: When a NE that is currently executing a SF-R switch
receives another SF-R or FS-R bridge request over the long path, not
6-33
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Equipment Criteria and K1/K2 Byte Protocol

destined to that NE, the NE shall check if there is any need for squelching
and squelch accordingly. NEs with VT access shall determine whether any
of the VTs that it drops requires squelching, and shall squelch accordingly.
The NE shall unsquelch any VT-accessed STSs that had been squelched if
the Bridged and Switched indication in byte K2 bits 68 on the long bridge
request path is still being received after 100 ms. The NE shall stop
squelching when the bridge and switch are dropped.
R6-136 [134] Rule S-S #1.b: When a NE that is currently executing a FS-R switch
receives another FS-R or SF-R bridge request over the long path, not
destined to that NE, the NE shall check if there is any need for squelching
and squelch accordingly. NEs with VT access shall determine whether any
of the VTs that it drops requires squelching, and shall squelch accordingly.
The NE shall unsquelch any VT-accessed STSs that had been squelched if
the Bridged and Switched indication in byte K2 bits 68 on the long bridge
request path is still being received after 100 ms. The NE shall stop
squelching when the bridge and switch are dropped.
R6-137 [135] Rule S-S #1.c: When a NE that is currently executing any ring
switch receives a higher priority ring APS request destined to it for the
same span, it shall upgrade the priority of the ring switch it is executing to
the priority of the received ring APS request.
R6-138 [136] Rule S-S #1.d: When a NE that is currently executing any span
switch receives a higher priority span APS request destined to it for the
same span, it shall upgrade the priority of the span switch it is executing to
the priority of the received span APS request.
R6-139 [137] Rule S-S #1.e: When a NE that is currently executing an EXER-R
request receives a higher priority ring APS request for the same span, it
shall remove any extra traffic. The node shall then execute the new ring
APS request as detailed in R6-124 to R6-126 (Rule I-S #1).
R6-140 [138] Rule S-S #1.f: When a NE that is currently executing an EXER-S
request receives a higher priority span APS request for the same span, with
the exception of LP-S and SD-P, it shall remove any extra traffic from the
short path. It shall then signal the new span bridge request with the Idle
code in K2 bits 68 on the short path, and the new span bridge request
status on the long path. If there is extra traffic on the long path the ET code
shall be signaled in K2 bits 68. The node shall then execute the new span
APS request as detailed in R6-124 to R6-126 (Rule I-S #1).
Rule S-S #2 Switch pre-emption
SONET BLSR Equipment Generic Criteria GR1230CORE
Equipment Criteria and K1/K2 Byte Protocol Issue 4, December 1998

6-34
R6-141 [139] Rule S-S #2.a: When a NE that is currently executing a span switch
receives a ring APS request destined to it of higher priority for the same
span, it shall drop the span bridge and switch immediately, and execute the
ring APS request (as detailed in R6-124 to R6-126 [Rule I-S #1]).
R6-142 [140] Rule S-S #2.b: When a node that is currently executing a span
switch receives a ring APS request destined to it for its adjacent span of
higher priority than the span switch it is executing, it shall drop the span
switch, signal No Request in K1 and Bridged in K2 in the direction of the
span APS request, and signal the ring request in K1 and Idle in K2 in the
direction of the ring APS request.
R6-143 [141] Rule S-S #2.c: When a node that is currently executing a span
switch receives a long path ring bridge request for a non-adjacent span of
higher priority than the span switch it is executing, it shall drop the span
switch and signal No Request in K1 and Bridged in K2 in both directions.
R6-144 [142] Rule S-S #2.d: If a span switching node that is bridged and switched
receives a No Request and an indication that the switch has been dropped
for that span, the node shall drop its bridge and switch, and if the nodes
highest priority input is
a. A span bridge request status destined to the node itself, or No
Request, then the node shall source No Request in K1 and Idle in
K2 in both directions.
b. A span APS request destined to it for an adjacent span, then the
node shall signal in accordance with that request.
c. A ring APS request destined to it for an adjacent span, then the
node shall execute the ring APS request.
d. A long path ring bridge request destined to another node, then the
node shall signal in accordance with either R6-155 (Rule S-P #1.a)
or R6-156 (Rule S-P #1.b), depending upon whether or not the
Bridged indication is being received.
e. A span bridge request status destined to another node, then the
node shall signal in accordance with either R6-157 (Rule S-P #1.c)
or R6-158 (Rule S-P #1.d), depending upon whether or not the
Bridged indication is being received.
f. A span APS request for the same span, the node shall signal the
span bridge request in K1 and Idle in K2.
6-35
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Equipment Criteria and K1/K2 Byte Protocol

R6-145 [143] Rule S-S #2.e: If a span switching node that is bridged receives a No
Request and an indication that the switch has been dropped for that span,
the node shall drop its bridge, and if the nodes highest priority input is
a. A span bridge request status destined to the node itself, or No
Request, then the node shall source No Request in K1 and Idle in
K2 in both directions.
b. A span APS request for an adjacent span, then the node shall
signal in accordance with that request.
c. A ring APS request destined to it for an adjacent span, then the
node shall execute that request.
d. A long path ring bridge request destined to another node, then the
node shall signal in accordance with either R6-155 (Rule S-P #1.a)
or R6-156 (Rule S-P #1.b), depending upon whether or not the
Bridged indication is being received.
e. A span bridge request status destined to another node, then the
node shall enter K-byte pass-through signal in accordance with
either R6-157 (Rule S-P #1.c) or R6-158 (Rule S-P #1.d),
depending upon whether or not the Bridged indication is being
received.
f. A span APS request for the same span, the node shall signal the
span bridge request in K1 and Idle in K2.
R6-146 [144] Rule S-S #2.f: When a NE that is currently executing a ring switch
receives an APS request destined to it for an adjacent span of higher
priority than the ring switch it is executing, it shall
a. Drop the ring bridge and switch immediately
b. Execute the higher priority APS request (as detailed in R6-124 to
R6-126 [Rule I-S #1]).
R6-147 [145] Rule S-S #2.g.1: When a NE that is currently executing a ring
switch receives a MS-S or FS-S command or bridge request destined to it
and that APS request is higher priority than the existing ring switch, it
shall:
a. Drop the ring bridge and switch immediately, and
b. Execute the span APS request.
Rule S-S #2.g.2: When an NE that is currently executing a ring switch
detects an SD-S condition, and SD-S is higher priority than the existing
SONET BLSR Equipment Generic Criteria GR1230CORE
Equipment Criteria and K1/K2 Byte Protocol Issue 4, December 1998

6-36
ring switch, it shall consider the condition to be an SD-R condition, and
upgrade the existing switch to SD-R.
Rule S-S #2.g.3: When an NE that is currently executing a ring switch
detects an SF-S condition, and SF-S is higher priority than the existing ring
switch, it shall consider the condition to be an SF-R condition, and upgrade
the existing switch to SF-R.
R6-148 [274] Rule S-S #2.h: For a four-fiber ring:
If a ring switching node receives an APS request of higher priority than the
ring APS request it is executing, and the two requests are not allowed to
co-exist, the node shall drop the lower priority request and consider its
detected or received protection line condition in addition to the higher
priority request. If the detected or received request for the protection line
is allowed to co-exist with the higher priority APS request, and
if the higher priority APS request is for a span switch on the adjacent
span to the detected or received protection channel request, or
if the higher priority APS request is for a ring switch for the same span
as the detected or received protection channel request,
then it shall respond to both the protection channel request and the higher
priority APS request on the respective spans. If the higher priority request
is a span request, any Extra Traffic on the span adjacent to the request that
had been preempted shall be reinserted. This rule takes precedence over
R6-137 (Rule S-S #1.c) and R6-146 (Rule S-S #2.f).
Rule S-S #3 Ring and span switch clearing rule (no pre-emption)
R6-149 [146] Rule S-S #3.a: When a locally detected failure condition clears at a
node, the node shall enter Wait-to-Restore and remain in Wait-to-Restore
for the appropriate time-out interval unless (1) a bridge request of higher
priority than WTR is received, (2) another failure is detected, or (3) an
externally initiated command becomes active. The node shall send out a
WTR code on both the long and short paths.
R6-150 [147] Rule S-S #3.b: When a node that is executing a switch in response
to an incoming SD-S, SD-R, SF-S, or SF-R bridge request (not due to a
locally detected failure) receives a WTR code (unidirectional failure case),
it shall send out Reverse Request on the short path and the WTR on the
long path.
Simultaneous clearing of a bidirectional failure is illustrated in Figures 6-6 and 6-7.
6-37
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Equipment Criteria and K1/K2 Byte Protocol

R6-151 [148] Rule S-S #4 Span switch time-out: For a four-fiber ring, when it is
not possible to execute a SD-S or SF-S bridge request because no
acknowledgment is received on the short path (time-out), or because the
protection channels become unavailable (including degradation or failure
of the protection line or LOW-S), the appropriate ring switch shall be
attempted.
For example, by R6-151 (Rule S-S #4), the combination of SD-S and either SD-P or
LOW-S on the same span will result in the execution of SD-R for that span. Similarly,
the combination of SF-S and either SD-P, SF-P, or LOW-S on the same span will
result in the execution of SF-R for that span.
R6-152 [149] The duration of the timeout for a span switch attempt shall be equal
to the switch completion time (i.e., 50 ms for clean rings and 100 ms for
rings with multiple failures).
R6-153 [150] Rule S-S #5: A switching node that receives ring bridge requests
destined to itself from both its neighbors shall drop its bridge and release
its switch.
R6-154 [151] Rule S-S #6: When a NE that is currently receiving a LP-S bridge
request or is sourcing a LP-S bridge request because of a signal fail-
protection receives an externally initiated ring bridge command or detects
a failure of the working line for the same span, it shall assume the priority
of the ring bridge request.
D. Transitions Between Switching and Pass-Through States
Rule S-P #1 Switch pre-emption rules (Switching State to Pass-Through State)
R6-155 [152] Rule S-P #1.a: If a span switching node that is not bridged or
switched is receiving a Bridged code for that span, and its highest priority
input is a long path ring bridge request destined to another node, then the
node shall signal No Request in K1 and Idle in K2 in both directions.
R6-156 [153] Rule S-P #1.b: If a span switching node that is not bridged or
switched receives an indication that the bridge has been dropped for that
span, and its highest priority input is a long path ring bridge request
destined to another node, then
For NEs without VT access and without extra traffic, the node shall
enter bidirectional full pass-through.
For NEs without VT access and with extra traffic, the node shall drop
extra traffic bidirectionally, and shall enter unidirectional full pass-
SONET BLSR Equipment Generic Criteria GR1230CORE
Equipment Criteria and K1/K2 Byte Protocol Issue 4, December 1998

6-38
through, in the direction of the bridge request only. Upon receiving the
crossing K-bytes, the node shall enter bidirectional full pass-through.
For NEs with VT access and without extra traffic, the node shall enter
unidirectional full pass-through in the direction of the request. Upon
receiving the crossing K-bytes, the node shall determine whether any
of the VTs that it drops requires squelching, and shall squelch
accordingly, and then enter bidirectional full pass-through.
For NEs with VT access and with extra traffic, the node shall drop
extra traffic bidirectionally, and shall enter unidirectional full pass-
through, in the direction of the bridge request. Upon receiving the
crossing K-bytes, the node shall determine whether any of the VTs that
it drops requires squelching, and shall squelch accordingly, and then
enter bidirectional full pass-through.
R6-157 [154] Rule S-P #1.c: If a span switching node that is not bridged or
switched is receiving a Bridged code for that span and its highest priority
input is a span bridge request status destined to another node, then the node
shall signal No Request in K1 and Idle in K2 in both directions.
R6-158 [155] Rule S-P #1.d: If a span switching node that is not bridged or
switched receives an indication that the bridge has been dropped for that
span, and its highest priority input is a span bridge request status destined
to another node, then the node shall enter K-byte pass-through. It shall then
reinsert any extra traffic that had been preempted.
R6-159 [156] Rule S-P #1.e: When a node that is currently executing a ring switch
receives a long path ring bridge request for a non-adjacent span of higher
priority than the ring switch it is executing, it shall drop its bridge and
switch immediately and then
For NEs without VT access, the node shall enter bidirectional full
pass-through.
For NEs with VT access, the node shall enter unidirectional full pass-
through in the direction of the request. Upon receiving the crossing K-
bytes, the node shall determine whether any of the VTs that it drops
requires squelching, and shall squelch accordingly, and then enter
bidirectional full pass-through.
R6-160 [157] Rule S-P #1.f: When a node that is currently executing a ring switch
has as its highest priority input long path ring bridge requests not destined
to itself from both directions, it shall drop its bridge and switch
immediately and then
6-39
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Equipment Criteria and K1/K2 Byte Protocol

For NEs without VT access, the node shall enter bidirectional full
pass-through.
For NEs with VT access, the node shall enter unidirectional full pass-
through in the direction of the first received request. Upon receiving
the crossing K-bytes, the node shall determine whether any of the VTs
that it drops requires squelching, and shall squelch accordingly, and
then enter bidirectional full pass-through.
R6-161 [158] Rule S-P #1.g: If a ring switching node that is not bridged or
switched has as its highest priority input a span bridge request status
destined to another node, then the node shall enter K-byte pass-through. It
shall then reinsert any extra traffic that had been preempted.
Rule S-P #2 Pass-through to switching transitions
R6-162 [159] Rule S-P #2.a: The transition of a node from full pass-through to
switching shall be triggered by
a. An equal, higher priority, or allowed co-existing externally
initiated command,
b. The detection of an equal, higher priority, or allowed co-existing
failure,
c. The receipt of an equal, higher priority, or allowed coexisting
bridge request destined to that NE,
d. The detection of an APS byte sourced by that NE.
R6-163 [160] Rule S-P #2.b: The transition of a node from K-byte pass-through
to switching shall be triggered by
a. Any externally initiated command,
b. The detection of any failure,
c. The receipt of any bridge request destined to that NE.
R6-164 [161] Rule S-P #2.c: If a node that was in the full pass-through state is
now sourcing a span bridge request due to R6-162 (Rule S-P #2.a), the
node shall insert Path AIS on the protection channels on the span adjacent
to the affected span, until the node receives an indication that the ring
switch has been dropped.
R6-165 [162] Rule S-P #3: If a node that was in the pass-through state due to a SF-
R or FS-R bridge request on the ring, and the node is now sourcing a SF-
R or FS-R bridge request due to R6-162 (Rule S-P #2.a), the node shall
SONET BLSR Equipment Generic Criteria GR1230CORE
Equipment Criteria and K1/K2 Byte Protocol Issue 4, December 1998

6-40
determine if there is any need for squelching and squelch accordingly, and
execute the ring bridge and switch. NEs with VT access shall determine
whether any of the VTs that it drops requires squelching, and shall squelch
accordingly. The NE shall unsquelch any VT-accessed STSs that had been
squelched if the Bridged and Switched indication in byte K2 bits 68 on
the long bridge request path is still being received after 100 ms.
R6-166 [275] Rule S-P #4: If a pass-through node receives from at least one
direction the APS byte that has itself as the source ID, it shall source Idle
in both directions.
R6-167 [163] If a span switch request is clearing and there is another span switch
request on the long path, the span switch that is being cleared shall be
dropped by using the clearing sequence Section 6.2.2.2.2B describes. The
No Request code is pre-empted by the other span switch request on the
long path.
E. Transitions Within the Pass-Through State
R6-168 [164] Rule P-P #1 Transition from K-byte pass-through to full pass-
through
For NEs without VT access and without extra traffic, when a node in
K-byte pass-through receives a long path ring bridge request other
than EXER-R not destined to itself, the node shall enter bidirectional
full pass-through.
For NEs without VT access and with extra traffic, the node shall drop
extra traffic bidirectionally, and shall enter unidirectional full pass-
through, in the direction of the bridge request only. Upon receiving the
crossing K-bytes, the node shall enter bidirectional full pass-through.
For NEs with VT access and without extra traffic, when a node in K-
byte pass-through receives a long path ring bridge request other than
EXER-R not destined to itself, the node shall enter unidirectional full
pass-through in the direction of the request. Upon receiving the
crossing K-bytes, the node shall determine whether any of the VTs that
it drops requires squelching, and shall squelch accordingly, and then
enter bidirectional full pass-through.
For NEs with VT access and with extra traffic, the node shall drop
extra traffic bidirectionally, and shall enter unidirectional full pass-
through, in the direction of the bridge request. Upon receiving the
crossing K-bytes, the node shall determine whether any of the VTs that
it drops requires squelching, and shall squelch accordingly, and then
enter bidirectional full pass-through.
6-41
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Equipment Criteria and K1/K2 Byte Protocol

R6-169 [165] Rule P-P #2 Transition from full pass-through to K-byte pass-
through: A node in bidirectional full pass-through that receives a span
bridge request status not destined to itself from both directions shall enter
K-byte pass-through. A VT access node shall unsquelch any VTs that it
drops that had previously been squelched.
R6-170 [166] Rule P-P #3 Transition from full pass-through to full pass-
through for VT access nodes: When a VT access node in full pass-through
receives a change in K-bytes indicating a long path ring bridge request
other than EXER-R not destined to itself, the node shall remain in full
pass-through and determine whether any of the VTs that it drops require
squelching, and shall squelch accordingly.
SONET BLSR Equipment Generic Criteria GR1230CORE
Equipment Criteria and K1/K2 Byte Protocol Issue 4, December 1998

6-42
6.2.2.3 Examples of Protection Switching in a BLSR
This section provides examples showing how the state transition rules are used to execute
a ring and/or span switch. Sections 6.2.2.3.1 through 6.2.2.3.5 provide single failure/
degrade condition, Sections 6.2.2.3.6 through 6.2.2.3.9 provide multiple failure/degrade
conditions, and Sections 6.2.2.3.10 and 6.2.2.3.11 provide node failure condition with VT
access and extra traffic on the ring.
6.2.2.3.1 Unidirectional Signal Fail (Span) in a 4-fiber Ring (see Figure 6-2 and
Figure 6-3)
In Figure 6-2 and Figure 6-3, a span switch is executed and cleared for an SF condition over
the working channels in a 4-fiber ring. The initial state of the ring is the idle state. At time
T1, node F detects an SF condition on its working channels. It becomes a switching node
[R6-124 (Rule I-S #1.a)] and sends bridge requests in both directions [R6-87 to R6-91
(Rule S #1)]. Node G, and all successive intermediate nodes on the long path, enter K byte
pass-through [R6-121 and R6-122 (Rule I-P #1)]. Node E, on reception of the bridge
request from Node F on the short path, executes a span bridge and transmits a bridge request
status on the long path, and a reverse request on the short path [R6-87 to R6-91, R6-93, R6-
124, and R6-125 (Rule S #1, S #3, I-S #1.a, I-S #1.b)]. Node F, on reception of the bridged
indication from Node E on the short path, executes a span bridge and switch, and updates
its K byte signaling [R6-125 (Rule I-S #1.b)]. Node E, on reception of the bridge and switch
acknowledgment from Node F on the short path, completes the switch. Signaling reaches
steady state.
At time T2, the SF condition on the span clears, and Node F enters the WTR state, and
signals its new state in both directions [R6-149 (Rule S-S #3.a)]. Node E, on reception of
the WTR request from Node F on the short path, sends out Reverse Request on the short
path and WTR on the long path [R6-150 (Rule S-S #3.b)].
At time T3, the WTR interval expires. Node F drops the span switch, and sends out No
Request codes [R6-128 (Rule I-S #2)]. Node E, on reception of the No Request code from
Node F on the short path, drops its bridge and releases its switch, and sources the idle code
[R6-128 (Rule I-S #2)]. Node F, on reception of the idle code on the short path, drops its
bridge and also sources the idle code. All nodes then cascade back to the idle state [R6-123
(Rule I-P #2)].
6.2.2.3.2 Unidirectional Signal Fail (Ring) (see Figure 6-4 and Figure 6-5)
Figures 6-4 and 6-5 cover the case of a unidirectional SF condition in a 2-fiber ring, and of
a unidirectional SF condition on both working and protection channels in a 4-fiber ring.
6-43
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Equipment Criteria and K1/K2 Byte Protocol

The initial state of the ring is the idle state. At time T1, node F detects an SF condition on
its working and protection channels. It becomes a switching node [R6-124 (Rule I-S #1.a)]
and sends bridge requests in both directions [R6-87 to R6-91 (Rule S #1)]. Node G, and all
successive intermediate nodes on the long path, enter bidirectional full pass-through [R6-
121 and R6-122 (Rule I-P #1)]. Node E, on reception of the bridge request from Node F on
the short path, transmits an SF ring bridge request on the long path, and a Reverse Request
on the short path [R6-93, R6-124, R6-126 (Rule S #3, I-S #1.a, I-S #1.c)]. Node E, on
reception of the bridge request from Node F on the long path, executes a ring bridge and
switch, and updates byte K2 bits 6-8 [R6-125 (Rule I-S #1.b)]. Node F, on reception of the
bridge request from Node E on the long path, executes a ring bridge and switch, and updates
its K-byte signaling [R6-125 (Rule I-S #1.b)]. Signaling reaches steady state.
At time T2, the ring SF condition clears. Node F enters the WTR state and signals its new
state in both directions [R6-149 (Rule S-S #3.a)]. Node E, on reception of the WTR request
from Node F on the short path, sends out Reverse Request on the short path and WTR on
the long path [R6-150 (Rule S-S #3.b)].
At time T3, the WTR interval expires. Node F drops the ring switch, and sends out No
Request codes [R6-128 (Rule I-S #2)]. Node E, on reception of the No Request code from
Node F on the long path, drops its bridge and switch, and sources the idle code [R6-128
(Rule I-S #2)]. Node F, on reception of the idle code on the long path, drops its bridge and
also sources the idle code. All nodes then cascade back to the idle state [R6-123 (Rule I-P
#2)].
6.2.2.3.3 Bidirectional Signal Fail (Ring) (see Figure 6-6 and Figure 6-7)
Figures 6-6 and 6-7 cover the case of a bidirectional SF condition in a 2-fiber ring and of a
bidirectional SF condition on both working and protection channels in a 4-fiber ring.
The initial state of the ring is the idle state. At time T1, nodes E and F detect an SF condition
on their working and protection channels. They become switching nodes [R6-124 (Rule I-
S #1.a)] and send bridge requests in both directions [R6-87 to R6-91 (Rule S #1)]. Nodes
D and G, and all successive intermediate nodes on the long paths, enter bidirectional full
pass-through [R6-121 and R6-122 (Rule I-P #1)]. Node E, on reception of the bridge
request from F on the long path, executes a ring bridge and switch, and updates byte K2 bits
6-8 [R6-125 (Rule I-S #1.b)]. Node F, on reception of the bridge request from E on the long
path, executes a ring bridge and switch, and updates byte K2 bits 6-8 [R6-125 (Rule I-S
#1.b)]. Signaling reaches steady state.
At time T2 when the SF-Ring condition clears, the K-byte values that nodes E and F receive
indicate to both E and F that they are head ends of a unidirectional SF condition on the span
that preempts WTR. For this condition, the SF-R priority must be signaled on the long path
and RR-R on the short path [R6-93 (Rule S #3)]. These actions cause crossing RR-R on the
short path between nodes E and F. The WTR period for both head end nodes (due to
SONET BLSR Equipment Generic Criteria GR1230CORE
Equipment Criteria and K1/K2 Byte Protocol Issue 4, December 1998

6-44
simultaneous clearing) is entered after they receive a crossing RR-R from the node that was
its tail end [R6-149, R6-134 (Rule S-S #3.a, I-S #7)].
At time T3, the WTR intervals expire. Both nodes react as head ends to the WTR by
sourcing the WTR priority on the long path and RR-R on the short path [R6-93, R6-150
(Rule S #3, S-S #3.b)]. On receiving the crossing RR-R, nodes E and F drop their ring switch
and send No Request codes [R6-128 (Rule I-S #2)]. Node E, on reception of the No Request
code from F on the long path, drops its bridge and sources the idle code [R6-128 (Rule I-S
#2)]. Node F, on reception of the No Request code from E on the long path, drops its bridge
and sources the idle code [R6-128 (Rule I-S #2)]. All nodes then cascade back to the idle
state [R6-123 (Rule I-P #2)].
6.2.2.3.4 Unidirectional Signal Degrade (Ring) (see Figure 6-8)
In Figure 6-8, a ring switch is executed and cleared for a ring SD condition in a 2-fiber ring,
and for a ring SD condition over the working and protection channels in a 4-fiber ring.
The initial state of the ring is the idle state. At time T1, Node F detects a ring SD condition.
It becomes a switching node [R6-124 (Rule I-S #1.a)] and sends bridge requests in both
directions [R6-87 to R6-91 (Rule S #1)]. Node G, and all successive intermediate nodes on
the long path, enters bidirectional full pass-through [R6-121, R6-122 (Rule I-P #1)]. Node
E, on reception of the bridge request from F on the short path, transmits an SD ring bridge
request on the long path, and a reverse request on the short path [R6-93, R6-124, R6-126
(Rule S #3, I-S #1.a, I-S #1.c)]. Node E, on reception of the bridge request from Node F on
the long path, executes a ring bridge and updates byte K2 bits 6-8 [R6-125 (Rule I-S #1.b)].
Node F, on reception of the SD ring bridge request from node E on the long path, executes
a ring bridge, and updates byte K2 bits 6-8 [R6-125 (Rule I-S #1.b)]. Node F, on reception
of the bridged indication from Node E on the long path, executes a ring switch, and update
its K byte signaling [R6-125 (Rule I-S #1.b)]. Node E, on reception on the long path of the
bridge acknowledgment from Node F, completes the switch [R6-125 (Rule I-S #1.b)].
Signaling reaches steady state. Clearing is identical to the clearing of a unidirectional SF-
R condition.
6.2.2.3.5 Node Failure (see Figure 6-9 and Figure 6-10)
Figures 6-9 and 6-10 cover the case of a node failure in 2- and 4-fiber rings. Node failure
here means that all transmission, incoming and outgoing, to and from the node has failed,
affecting both working and protection channels, and the node itself has lost all provisioned
information.
The initial state of the ring is the idle state. At time T1, both nodes E and G detect an SF
condition on their working and protection channels. They become switching nodes [R6-124
(Rule I-S #1.a)] and source bridge requests on both the short and long paths [R6-87 to R6-
6-45
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Equipment Criteria and K1/K2 Byte Protocol

91 (Rule S #1)]. Nodes A and D and all successive intermediate nodes on the long path enter
bidirectional full pass-through [R6-121, R6-122 (Rule I-P #1)]. Node E, on reception of the
bridge request from G on the long path squelches all potentially misconnected traffic,
executes a ring bridge and switch, and updates byte K2 bits 6-8 [R6-125 (Rule I-S #1.b)].
Node G, on reception of the bridge request from E on the long path, squelches all
potentially misconnected traffic, executes a ring bridge and switch, and updates byte K2
bits 6-8 [R6-125 (Rule I-S #1.b)]. Signaling reaches steady state.
At time T2, the failed node has recovered physically but has not fully recovered its
provisioning information, preventing the recovering node from proper K byte signaling.
Until the recovering node is capable of proper K byte signaling in accordance with the
current state of the ring, default APS codes are transmitted [R6-130 (Rule I-S #3)]. Nodes
E and G detect the physical clearing of the signal from F but also receive default APS codes.
As long as Nodes E and G receive the default APS codes they do not declare the defect
cleared [R6-131 (Rule I-S #4)]. Signaling reaches steady state.
At time T3, node F has fully recovered and signals appropriately [R6-89 (Rule S #1.c)].
Nodes E and G receive non-default APS codes and declare the defect cleared. The WTR
states at nodes E and G are preempted by the higher priority long path bridge requests,
causing nodes E and G to drop their ring bridge and switch, stop squelching, and go into
bidirectional full pass-through [R6-160 (Rule S-P #1.f)]. After nodes E and G go into
bidirectional full pass-through, node F receives long path bridge requests destined to itself
from both E and G and takes no action [R6-132 (Rule I-S #5)]. When node F receives the
same signals that it is sending in both directions, it then signals the idle code in both
directions [R6-133 (Rule I-S #6)]. All nodes then cascade back to the idle state [R6-123
(Rule I-P #2)].
6.2.2.3.6 Unidirectional SF-R pre-empting a Unidirectional SD-S on Non-
Adjacent Spans (see Figure 6-11 and Figure 6-12)
Figures 6-11 and 6-12 cover the case of a unidirectional signal degrade-span condition that
had previously existed on a non-adjacent span.
The initial state of the ring is the idle state. At time T1, Node D detects an SD-S condition
on its working channels from Node C. The signalling proceeds in as shown in Figure 6-2,
except that (1) the switching nodes becomes Nodes C and D, not Nodes E and F, and (2)
the bridge request becomes SD-S, not SF-S. Signalling reaches steady-state.
At time T2, Node F detects an SF condition on its working and protection channels from
Node G. Node F becomes a switching node [R6-163 (Rule S-P #2.b)] and sources bridge
requests in both directions [R6-87 to R6-91 (Rule S #1)]. Node G, upon seeing the short
path ring request from Node F, also becomes a switching node [R6-163 (Rule S-P #2.b)].
Node G sources Reverse Request back on the short path, and SF-R on the long path [R6-
93 (Rule S #3)]. Intermediate Nodes A, B, and E change from K-byte pass-through to
bidirectional full pass-through [R6-168 (Rule P-P #1)]. Node D, upon seeing a higher
SONET BLSR Equipment Generic Criteria GR1230CORE
Equipment Criteria and K1/K2 Byte Protocol Issue 4, December 1998

6-46
priority ring bridge request, drops its span switch, updates byte K2 bits 6-8, and sources No
Request in both directions [R6-143 (Rule S-S #2.c)]. Node C, upon seeing a No Request
and dropped switch from Node D, drops its bridge and switch, updates byte K2 bits 6-8,
and acts on its highest priority input [R6-144 (Rule S-S #2.d)] to source No Request. Node
C eventually sees a ring bridge request destined to Node F, but this does not change Node
Cs signalling [R6-155 (Rule S-P #1.a)]. Node D, upon seeing a dropped switch at Node C,
drops its bridge and acts on its highest priority input [R6-145 (Rule S-S #2.e)] to enter
bidirectional full pass-through. Node C, upon seeing the dropped bridge from Node D, acts
on its highest priority input [R6-156 (Rule S-P #1.b)] to enter bidirectional full pass-
through. With all the intermediate nodes in bidirectional full pass-through, Nodes F and G
finally receive long path ring bridge requests. Nodes F and G each execute a bridge and
switch [R6-125 (Rule I-S #1.b)] and updates byte K2 bits 6-8. Signalling reaches steady
state.
At time T3, the SF condition on the working and protection channels from Node E to Node
F clears. Node F enters Wait-to-Restore [R6-149 (Rule S-S #3.a)]. Node G, upon seeing the
WTR bridge request from Node F, also enters Wait-to-Restore [R6-150 (Rule S-S #3.b)].
Node D, upon seeing two WTR bridge requests which are lower priority than its locally
detected SD condition, becomes a switching node [R6-162 (Rule S-P #2.a)], and signals
appropriately. Node C, upon seeing a higher priority span bridge request destined to it, also
becomes a switching node [R6-162 (Rule S-P #2.a)],executes a span bridge, and updates
byte K2 bits 6-8 [R6-125 (Rule I-S #1.b)]. Node F loses its long path ring bridge request
due to the span bridge request status from Node D. Node F drops its bridge and switch,
terminates the WTR signaling, and responds to its highest priority input, which is a span
bridge request status [R6-106 (Rule S #8)]. Similarly, when Node G loses its long path ring
bridge request, it drops its bridge and switch, terminates the WTR signaling, and responds
to its highest priority input, which is a span bridge request status [R6-107 (Rule S #8)].
Node D, upon seeing a Bridged code on the short path form Node C, executes a span bridge
and switch, and updates byte K2 bits 6-8 [R6-125 (Rule I-S #1.b)]. Node C, upon seeing a
Bridged and Switched code from Node D, completes the process by executing a span switch
and updating byte K2 bits 6-8 [R6-125 (Rule I-S #1.b)].
At time T4 (not shown), the span SD condition on the working channels from Node C to
Node D clears. The signalling proceeds in a manner as shown at time T2 in Figure 6-2,
except that (1) the switching nodes become Nodes C and D, not Nodes E and F, and (2) the
bridge request becomes SD-S, not SF-S.
6.2.2.3.7 Unidirectional SF-R pre-empting a Unidirectional SD-S on Adjacent
Spans (see Figure 6-13 and Figure 6-14)
Figure 6-13 and Figure 6-14 cover the case of a unidirectional signal fail-ring condition on
a four-fiber ring pre-empting a unidirectional signal degrade-span condition that had
previously existed on an adjacent span.
6-47
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Equipment Criteria and K1/K2 Byte Protocol

The initial state of the ring is the idle state. At time T1, Node F detects an SD condition on
its working channels from Node E. The signalling proceeds in a manner as shown in Figure
6-2 (at time T1 in the figure), except that the bridge request becomes SD-S, not SF-S.
Signalling reaches steady-state.
At time T2, Node E detects an SF condition on its working and protection channels from
Node D, Node E drops its span switch, sources a Signal Fail ring bridge request (in byte
K1) and MS RDI (in byte K2) towards Node D, and sources No Request (in byte K1) and
Bridged (in byte K2) towards Node F [R6-142 (Rule S-S #2.b)]. Node D becomes a
switching node [R6-156 (Rule S-P #2.b)]. Node D sources Reverse Request on the short
path, and a Signal Fail ring bridge request on the long path [R6-93 (Rule S #3)]. This long
path ring bridge request changes Nodes C, B, and A from K-byte pass-through to
bidirectional full pass-through [R6-168 (Rule P-P #1)]. Node F, upon seeing a No Request
and dropped switch from Node E, drops its bridge and switch, updates byte K2 bits 6-8, and
acts on its highest priority input [R6-144 (Rule S-S #2.d)] to source a Signal Degrade span
bridge request towards Node E. Node E, upon seeing a dropped switch at Node F, drops its
bridge, updates byte K2 bits 6-8, and acts on its highest priority input [R6-145 (Rule S-S
#2.e)] to source ring bridge requests in both directions. Node F, upon seeing the dropped
bridge from Node E, acts on its highest priority input [R6-156 (Rule S-P #1.b)] to enter
bidirectional full pass-through. This permits a long path ring bridge request to reach Node
G, and Node G changes from K-byte pass-through to bidirectional full pass-through [R6-
168 (Rule P-P #1)]. With all the intermediate nodes in bidirectional full pass-through,
Nodes E and D finally receive long path ring bridge requests. Nodes E and D each execute
a bridge and switch [R6-125 (Rule I-S #1.b)] and updates byte K2 bits 6-8. Signalling
reaches steady state.
At time T3, the SF condition on the working and protection channels from Node D to Node
E clears. Node E starts its Wait-to-Restore period, and signals so [R6-149 (Rule S-S #3.a)].
Node D, upon seeing the WTR bridge request from Node E, also starts its Wait-to-Restore
period, and signals so [R6-150 (Rule S-S #3.b)]. Node F, upon seeing WTR bridge requests
from both directions, acts on the fact that its local SD-S condition is higher priority, and
becomes a span switching node [R6-162 (Rule S-P #2.a)]. Node E, upon seeing the span
bridge request from Node F, loses its long path ring bridge request from Node D. Node E
therefore drops its ring bridge and switch [R6-103 (Rule S #5)], and acts on the span bridge
request from Node F by executing a span bridge [R6-125 (Rule I-S #1.b)]. Node F, upon
seeing the Bridged code from Node E, executes a span bridge and switch, and updates byte
K2 bits 6-8 [R6-125 (Rule I-S #1.b)]. Node E, upon seeing the Bridged and Switched code
from Node F, completes the process by executing a span switch and updating byte K2 bits
6-8 [R6-125 (Rule I-S #1.b)]. Meanwhile, Node D, upon seeing the span bridge request
from Node F, loses its long path ring bridge request form Node E. Node D therefore drops
its ring bridge and switch [R6-103 (Rule S #5)], and acts on the span bridge request status
destined to Node E by entering K-byte pass-through [R6-161 (Rule S-P #1.g)].
Intermediate bidirectional full pass-through Nodes A, B, C, and G eventually receive a span
bridge request status not destined to them from both directions, so they move into K-byte
pass-through. Signalling reaches the same steady state found at time T1.
SONET BLSR Equipment Generic Criteria GR1230CORE
Equipment Criteria and K1/K2 Byte Protocol Issue 4, December 1998

6-48
At time T4 (not shown), the SD condition on the working channels from Node E to Node
F clears. The signalling proceeds in a manner as shown in Figure 6-2 (at time T2 in the
figure), except that the bridge request becomes SD-S, not SF-S.
6.2.2.3.8 Unidirectional SF-S Pre-empting a Unidirectional SF-R on Adjacent
Spans (see Figure 6-15)
Figure 6-15 covers the case of a unidirectional signal fail-span condition on a four-fiber
ring pre-empting a unidirectional signal fail-ring condition that had previously existed on
an adjacent span.
The initial state of the ring is the idle state. At time T1, node D detects an SF condition on
its working and protection channels from node C. The signaling proceeds in a manner as
shown in Figure 6-4 (at time T1 in the figure), except that the switching nodes become
nodes C and D, not nodes E and F. Signaling reaches steady state.
At time T2, node E detects a SF condition on its working channel from node D. Node E
becomes a switching node [R6-162 (Rule S-P #2.a)] and sources a span bridge request
towards node D and a span bridge request status towards node F destined for node D. Node
D, upon seeing the higher priority span bridge request from node E, drops its ring bridge
and switch, and signals based on its highest allowed co-existing APS requests [R6-80, R6-
148 (Rule G #1.c, S-S #2.h)]. Node Ds highest priority input allowed to co-exist is SF-S
request from node E, and SF-P detected from node C [R6-148 (Rule S-S #2.h)]. It executes
a span bridge towards node E [R6-146 (Rule S-S #2.f)], and signals accordingly [R6-125,
R6-93 (Rule I-S #1.b, S #3)]. Node D also signals SF-P and RDI towards node C, since SF-
P and SF-S are allowed to co-exist [R6-101, R6-148 (Rule S #4.a, S-S #2.h)]. Node C, upon
losing the ring bridge request and seeing SF-P destined for it on the short path, becomes a
span switching node, and responds to the span request accordingly [R6-147 (Rule S-S
#2.g)]. Node E, upon seeing the Bridged code from node D, executes a span bridge and
switch, and updates byte K2 bits 6-8 [R6-125 (Rule I-S #1.b)]. Node D, upon seeing the
Bridged code from node E, executes a switch, and updates byte K2 bits 6-8 accordingly
[R6-125 (Rule I-S #1.b)]. Intermediate nodes enter K-byte pass through when crossing K-
bytes are detected [R6-169 (Rule P-P #2)]. Signaling reaches steady state.
At time T3, the SF condition on the working channels from node D to node E clears. Node
E enters Wait-to-Restore and signals accordingly [R6-149 (Rule S-S #3.a)]. Node D, upon
seeing the WTR code from node E, drops its span bridge and switch, and acts on all its
inputs, which is a detected SF-R and a lower priority WTR request from node E. Node D
signals a ring bridge request toward node C on both the long and short path [R6-144 (Rule
S-S #2.d)]. Node E, upon seeing a ring bridge request destined to another node, enters bi-
directional full pass-through [R6-159 (Rule S-P #1.e)]. Node C, upon losing the span
bridge request and seeing a long path ring bridge request from node D, executes a ring
bridge and switch, and updates byte K2 bits 6-8 [R6-104, R6-125 (Rule S #6, I-S #1.b)].
Node D, upon seeing a long path ring bridge request from node C, also executes a ring
6-49
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Equipment Criteria and K1/K2 Byte Protocol

bridge and switch, and updates byte K2 bits 6-8 [R6-125 (Rule I-S #1.b)]. Signaling reaches
the same steady state found at time T1.
At time T4 (not shown), the SF condition on the working and protection channels from
node C to node D clears. The signaling proceeds in a manner as shown in Figure 6-5 (at
time T2 in the figure), except that the switching nodes become nodes C and D, not nodes E
and F.
6.2.2.3.9 Unidirectional SF-R Coexisting with a Unidirectional SF-R on Non-
Adjacent Spans (see Figure 6-16)
Figure 6-16 covers the case of a unidirectional signal fail-ring condition on a four-fiber ring
coexisting with another unidirectional signal fail-ring condition that had previously existed
on a non-adjacent span.
The initial state of the ring is the idle state. At time T1, Node F detects an SF condition on
its working and protection channels. The signalling proceeds in a manner as shown in
Figure 6-4 (at time T1 in the figure). The signalling reaches steady state.
At time T2, Node C detects an SF condition on its working and protection channels. Node
C becomes a switching node [R6-162 (Rule S-P #2.a)], squelches traffic if necessary,
executes a ring bridge and switch, and sources ring bridge requests in both directions [R6-
165 (Rule S-P #3)]. Node B, upon seeing the bridge request from Node C, becomes a
switching node [R6-162 (Rule S-P #2.a)]. Node B also squelches traffic if necessary,
executes a ring bridge and switch, and sources ring bridge requests in both directions [R6-
165 (Rule S-P #3)]. The long path ring bridge request from Nodes B and C do not affect the
bridges and switches at Nodes E and F, because multiple SF-R switches are allowed to
coexist [R6-101, R6-103 (Rule S #4.a, S #5)]. The signalling reaches steady state.
At time T3, the SF condition on the working and protection channels from Node B to Node
C clears. Node C sees from Node D a ring bridge request for a non-adjacent span. This has
higher priority than its local (WTR) condition, so Node C drops its bridge and switch and
enters bidirectional full pass-through [R6-159 (Rule S-P #1.e)]. This permits the short path
ring Reverse Request signal from Node B to reach Node E. Node E still considers this to
be a valid ring bridge request, so Node E retains its ring bridge and switch [R6-103 (Rule
S #5)]. Node B, upon receiving both ring bridge requests that are not destined to it, drops
its bridge and switch and enters bidirectional full pass-through [R6-160 (Rule S-P #1.f)].
Signalling reaches the same steady state as found at time T1.
At time T4 (not shown), the SF condition on the working and protection channels from
Node E to Node F clears. The signalling proceeds in a manner as shown in Figure 6-4 (at
time T3 in the figure).
SONET BLSR Equipment Generic Criteria GR1230CORE
Equipment Criteria and K1/K2 Byte Protocol Issue 4, December 1998

6-50
6.2.2.3.10 Node Failure on a Ring with VT-access Capability (see Figure 6-17
and Figure 6-18)
Figures 6-17 and 6-18 cover the case of VT squelching on a VT access ring after a node
failure on either a two or four fiber ring. Node failure here means that all transmission,
incoming and outgoing, to and from the node has failed, affecting both working and
protection channels, and the node itself has lost all provisioned information.
The initial state of the ring is the idle state. At time T1, both nodes E and G detect an SF
condition on their working and protection channels. They become switching nodes [R6-124
(Rule I-S #1.a)] and source bridge requests on the long and short paths. Non VT-access
nodes on the long path enter bidirectional full pass-through. VT access nodes B and D enter
into unidirectional full pass-through in the direction of their first received requests [R6-
121, R6-122 (Rule I-P #1)]. Upon receiving crossing K-bytes, VT squelching will be
performed for VTs dropped at nodes B and D. Upon completion of the VT squelching,
nodes B and D then enter bidirectional full pass-through [R6-121, R6-122 (Rule I-P #1)].
Node E, upon reception of the bridge request from G on the long path squelches all
potentially misconnected traffic (including VT-accessed STSs), executes a ring bridge and
switch, and updates byte K2 bits 6-8 [R6-125 (Rule I-S #1.b)]. Node G, upon reception of
the bridge request from E on the long path squelches all potentially misconnected traffic
(including VT-accessed STSs), executes a ring bridge and switch, and updates byte K2 bits
6-8 [R6-125 (Rule I-S #1.b)]. Nodes E and G, upon receiving the Bridged and Switched
indication in byte K2 bits 6-8, then unsquelch the VT-accessed STSs [R6-125 (Rule I-S
#1.b)]. Signaling reaches steady state.
At time T2, the failed node has recovered physically but has not fully recovered its
provisioning information, preventing the recovering node from proper K byte signaling.
Until the recovering node is capable of proper K byte signaling in accordance with the
current state of the ring, default APS codes are transmitted [R6-130 (Rule I-S #3)]. Nodes
E and G detect the physical clearing of the signal from F but also receive default APS codes.
As long as Nodes E and G receive the default APS codes they do not declare the defect
cleared [R6-131 (Rule I-S #4)]. Signaling reaches steady state.
At time T3, node F has fully recovered and signals appropriately [R6-89 (Rule S #1.c)].
Nodes E and G receive non-default APS codes and declare the defect cleared. The WTR
states at nodes E and G are preempted by the higher priority long path bridge requests,
causing nodes E and G to drop their ring bridge and switch, stop squelching, and go into
bidirectional full pass-through [R6-160 (Rule S-P #1.f)]. After nodes E and G go into
bidirectional full pass-through, node F receives long path bridge requests destined to itself
from both E and G and takes no action [R6-132 (Rule I-S #5)]. When node F receives the
same signals that it is sending in both directions, it then signals the idle code in both
directions [R6-133 (Rule I-S #6)]. On reception of the idle code, both nodes B and D will
unsquelch all VTs that are squelched. All nodes then cascade back to the idle state [R6-123
(Rule I-P #2)].
6-51
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Equipment Criteria and K1/K2 Byte Protocol

6.2.2.3.11 Node Failure on a Ring with VT-access and Extra Traffic Capability
(see Figure 6-19 and Figure 6-20)
Figures 6-19 and 6-20 cover the case of VT and Extra Traffic squelching on a ring after a
node failure on either a two or four fiber ring. Node failure here means that all transmission,
incoming and outgoing, to and from the node has failed, affecting both working and
protection channels, and the node itself has lost all provisioned information.
The initial state of the ring is the idle state. Extra traffic is supported on the protection
channels. At time T1, both nodes E and G detect an SF condition on their working and
protection channels. Nodes E and G drop extra traffic bidirectionally, become switching
nodes [R6-124, R6-105 (Rule I-S #1.a, S #7)], and source bridge requests on the long and
short paths. All intermediate nodes will drop extra traffic bidirectionally, and enter into
unidirectional full pass-through [R6-121, R6-122 (Rule I-P #1)]. Upon receiving crossing
K-bytes, VT squelching will be performed for VTs dropped at nodes B and D. Upon
completion of the VT squelching, nodes B and D then enter bidirectional full pass-through
[R6-121, R6-122 (Rule I-P #1)]. Non VT-access nodes enter bidirectional full pass-through
upon receiving crossing K-bytes. Node E, upon reception of the bridge request from G on
the long path squelches all potentially misconnected traffic (including VT-accessed STSs),
executes a ring bridge and switch, and updates byte K2 bits 6-8 [R6-125 (Rule I-S #1.b)].
Node G, upon reception of the bridge request from E on the long path squelches all
potentially misconnected traffic (including VT-accessed STSs), executes a ring bridge and
switch, and updates byte K2 bits 6-8 [R6-125 (Rule I-S #1.b)]. Nodes E and G, upon
receiving the Bridged and Switched indication in byte K2 bits 6-8, then unsquelch the VT-
accessed STSs [R6-125 (Rule I-S #1.b)]. Signaling reaches steady state.
At time T2, the failed node has recovered physically but has not fully recovered its
provisioning information, preventing the recovering node from proper K byte signaling.
Until the recovering node is capable of proper K byte signaling in accordance with the
current state of the ring, default APS codes are transmitted [R6-130 (Rule I-S #3)]. Nodes
E and G detect the physical clearing of the signal from F but also receive default APS codes.
As long as Nodes E and G receive the default APS codes they do not declare the defect
cleared [R6-131 (Rule I-S #4)]. Signaling reaches steady state.
At time T3, node F has fully recovered and signals appropriately [R6-89 (Rule S #1.c)].
Nodes E and G receive non-default APS codes and declare the defect cleared. The WTR
states at nodes E and G are preempted by the higher priority long path bridge requests,
causing nodes E and G to drop their ring bridge and switch, stop squelching, and go into
bidirectional full pass-through [R6-160 (Rule S-P #1.f)]. After nodes E and G go into
bidirectional full pass-through, node F receives long path bridge requests destined to itself
from both E and G and takes no action [R6-132 (Rule I-S #5)]. When node F receives the
same signals that it is sending in both directions, it then signals the idle code in both
directions [R6-133 (Rule I-S #6)]. On reception of the idle code, both nodes B and D will
unsquelch all VTs that are squelched. All nodes then source Extra Traffic code and cascade
back to the idle state [R6-123 (Rule I-P #2)].
SONET BLSR Equipment Generic Criteria GR1230CORE
Equipment Criteria and K1/K2 Byte Protocol Issue 4, December 1998

6-52
Figure 6-2. Four-Fiber BLSR - Unidirectional Failure (Span) on Working From E
to F
X
G A B
F
E D C
T1
SF
6-53
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Equipment Criteria and K1/K2 Byte Protocol

Figure 6-2. Four-Fiber BLSR - Unidirectional Failure (Span) on Working From E to
F (Continued)
K2 K1
10b 11b 10b 11b 10b 11b 10b 11b 11a 10a 10b 11b 10b 11b
8b
I-P #1 3b
9b
10b
11b
11b
9b
10b
3b
2b
8b
1b
10b
10a
11a 11b
9a 9b
8b
1a 2b 2a 3b 3a 4b 4a 5b 5a 6b 6a 7b 7a 1b
I-P #1 I-P #1
I-P #1
I-P #1
Span
switch
Span
bridge and
switch
1a
T
0
TIME
A B D C E F A G
NR/B A/S/IDLE
T
1
Detect SF
on working
only
I-S #1.a
Span
bridge
I-S #1.a
I-S #1.b
I-S #1.b
I-S #1.b
8a
1b NR/G A/S/IDLE
2a NR/C B/S/IDLE
2b NR/A B/S/IDLE
3a NR/D C/S/IDLE
3b NR/B C/S/IDLE
4a NR/E D/S/IDLE
4b NR/C D/S/IDLE
5a NR/F E/S/IDLE
5b NR/D E/S/IDLE
6a NR/G F/S/IDLE
6b NR/E F/S/IDLE
7a NR/A G/S/IDLE
7b NR/F G/S/IDLE
8a SF-S/E F/S/IDLE
8b SF-S/E F/L/IDLE
9a RR-S/F E/S/Br
9b SF-S/F E/L/Br
10a SF-S/E F/S/Br&Sw
10b SF-S/E F/L/Br&Sw
11a RR-S/F E/S/Br&Sw
11b SF-S/F E/L/Br&Sw
T
0

-

I
D
L
E

S
T
A
T
E
T
1

-

S
P
A
N

S
F
LEGEND
Node sourcing K1 and K2
Node in K-byte pass-through
NOTE - See Tables 6-1 and 6-2 for byte K1 and K2 formats.
SONET BLSR Equipment Generic Criteria GR1230CORE
Equipment Criteria and K1/K2 Byte Protocol Issue 4, December 1998

6-54
Figure 6-3. Four-Fiber BLSR - Unidirectional Failure (Span) on Working From E
to F (Concluded)
Revert to
idle
14a
Revert to
idle
Revert to
idle
Revert to
idle
Revert to
idle
K2 K1
12b 13b 12b 13b 12b 13b 12b 13b 11a 12a 12b 13b 12b 13b
12b
13b
12b
11a
12b
1a
T
2
TIME
A B D C E F A G
NR/B A/S/IDLE
T
3
S-S #3.a
S-S #3.b
12a
1b NR/G A/S/IDLE
2a NR/C B/S/IDLE
2b NR/A B/S/IDLE
3a NR/D C/S/IDLE
3b NR/B C/S/IDLE
4a NR/E D/S/IDLE
4b NR/C D/S/IDLE
5a NR/F E/S/IDLE
5b NR/D E/S/IDLE
6a NR/G F/S/IDLE
6b NR/E F/S/IDLE
7a NR/A G/S/IDLE
7b NR/F G/S/IDLE
10a SF-S/E F/S/Br&Sw
10b SF-S/E F/L/Br&Sw
11a RR-S/F E/S/Br&Sw
11b SF-S/F E/L/Br&Sw
T
0

-

I
D
L
E

S
T
A
T
E
T
3

-

W
T
R

E
X
P
I
R
E
S
LEGEND
Node sourcing K1 and K2
Node in K-byte pass-through
NOTE - See Tables 6-1 and 6-2 for byte K1 and K2 formats.
10b 11b 10b 11b 10b 11b 10b 11b 11a 10a 10b 11b 10b 11b
14b
5a
14b
I-S #2
I-S #2
6a 6b
I-S #2
14b
I-P #2
I-P #2
I-P #2
I-P #2
I-P #2
I-S #2
I-S #2
1b
1a
2b 2a
3b 3a
4b
4a
5b 5a
6b 6a
7b 7a
1a 2b 2a 3b 3a 4b 4a 5b 5a 6b 6a 7b 7a 1b
13b
13b
5b
12a WTR/E F/S/Br&Sw
12b WTR/E F/L/Br&Sw
13b WTR/F E/L/Br&Sw
14a NR/E F/S/Br
14b NR/E F/L/Br
WTR expires
Drop span Sw
Drop span
Br
Send idle
Span SF
clears
WTR starts
Sends RR on the
short path, and
WTR on the long
path
Drop span
Br&Sw
Send idle
T
1

-

S
T
E
A
D
Y

S
T
A
T
E
T
2

-

S
P
A
N

S
F

C
L
E
A
R
S
5b
6-55
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Equipment Criteria and K1/K2 Byte Protocol

Figure 6-4. Two- or Four-Fiber BLSR - Unidirectional SF (Ring)
T1
SF
G A B
F
E D C
X
X
SONET BLSR Equipment Generic Criteria GR1230CORE
Equipment Criteria and K1/K2 Byte Protocol Issue 4, December 1998

6-56
Figure 6-4. Two- or Four-Fiber BLSR - Unidirectional SF (Ring) (Continued)
2b
3b
4b
5b
9b
8b
8b
K2 K1
8b
1a
2b 2a 3b 3a 4b 4a 5b 5a 6b 6a 7b 7a
1b
T
1
TIME
A B D C E F A G
T
2
Detect SF
I-S #1.a
8a
8a SF-R/E F/S/RDI
8b SF-R/E F/L/IDLE
T
0

-

I
D
L
E

S
T
A
T
E
T
1

-

R
I
N
G

S
F
LEGEND
Node sourcing K1 and K2
NOTE - See Tables 6-1 and 6-2 for byte K1 and K2 formats.
Node in full pass-through (bidirectional);
K1, K2 and protection channels
12b 13b 12b 13b 12b 13b 12b 13b 10a 12a 12b 13b 12b 13b
9a RR-R/F E/S/IDLE
9b SF-R/F E/L/IDLE
10a RR-R/F E/S/Br&Sw
10b SF-R/F E/L/Br&Sw
11a SF-R/E F/S/RDI
11b SF-R/E F/L/Br&Sw
12a WTR/E F/S/Br&Sw
12b WTR/E F/L/Br&Sw
13b WTR/F E/L/Br&Sw
T
2

-

R
I
N
G

S
F

C
L
E
A
R
S
T
0
9a
I-P #1
I-S #1.a
I-S #1.c
9b
11b 10b 11b 10b 11b 10b11b 10b 10a 11a 11b 10b 11b 10b
I-P #1
I-P #1
I-P #1
I-P #1
S #3
9b
3b
4b
5b
Ring
Br&Sw
I-S #1.b
Ring
Br&Sw
I-S #1.b
10a 10b
10b
11b 11a
11b
11b
10b
SF clears
WTR
starts
S-S #3.a
12b 12a
Sends back
RR on short
path and WTR
on long path
S-S #3.b
10a 13b
12b
12b
13b
13b
1a NR/B A/S/IDLE
1b NR/G A/S/IDLE
2a NR/C B/S/IDLE
2b NR/A B/S/IDLE
3a NR/D C/S/IDLE
3b NR/B C/S/IDLE
4a NR/E D/S/IDLE
4b NR/C D/S/IDLE
5a NR/F E/S/IDLE
5b NR/D E/S/IDLE
6a NR/G F/S/IDLE
6b NR/E F/S/IDLE
7a NR/A G/S/IDLE
7b NR/F G/S/IDLE
6-57
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Equipment Criteria and K1/K2 Byte Protocol

Figure 6-5. Two- or Four-Fiber BLSR - Unidirectional SF (Ring) (Concluded)
Revert to
idle
I-P #2
Revert to
idle
I-P #2
Revert to
idle
I-P #2
Revert to
idle
I-P #2
K2 K1
14b
T
3
TIME
A B D C E F A G
WTR expires
Drop ring Sw
I-S #2
14a
T
2

-

S
T
E
A
D
Y
S
T
A
T
E
T
0

-

I
D
L
E

S
T
A
T
E
LEGEND
Node sourcing K1 and K2
NOTE - See Tables 6-1 and 6-2 for byte K1 and K2 formats.
Node in full pass-through (bidirectional);
K1, K2 and protection channels
10a RR-R/F E/S/Br&Sw
12a WTR/E F/S/Br&Sw
12b WTR/E F/L/Br&Sw
T
3

-

W
T
R

E
X
P
I
R
E
S
1a NR/B A/S/IDLE
1b NR/G A/S/IDLE
2a NR/C B/S/IDLE
2b NR/A B/S/IDLE
3a NR/D C/S/IDLE
3b NR/B C/S/IDLE
4a NR/E D/S/IDLE
4b NR/C D/S/IDLE
5a NR/F E/S/IDLE
5b NR/D E/S/IDLE
6a NR/G F/S/IDLE
6b NR/E F/S/IDLE
7a NR/A G/S/IDLE
7b NR/F G/S/IDLE
1a 2b 2a 3b 3a 4b 4a 5b 5a 6b 6a 7b 7a 1b
12b 13b 12b 13b 12b 13b 12b 13b 10a 12a 12b 13b 12b 13b
5a
I-S #2
Drop ring Br&Sw
Send idle
5b
14b
14b
5b
5b
I-S #2
Drop ring Br
Revert to idle
6a 6b
Revert to idle
I-P #2
Revert to
idle
I-S #2
7a 7b
1b
1a
2b 2a
3b 3a
4b 4a
5b 5a
14a NR/E F/S/Br
14b NR/E F/L/Br
13b WTR/F E/L/Br&Sw
SONET BLSR Equipment Generic Criteria GR1230CORE
Equipment Criteria and K1/K2 Byte Protocol Issue 4, December 1998

6-58
Figure 6-6. Two- or Four-Fiber BLSR - Bidirectional SF (Ring)
G A B
F
E D C
T1
SF
6-59
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Equipment Criteria and K1/K2 Byte Protocol

Figure 6-6. Two- or Four-Fiber BLSR - Bidirectional SF (Ring) (Continued)
9b
8b 8a
9a
10a RR-R/F E/S/Br&Sw
11a RR-R/E F/S/Br&Sw
K2 K1
9b
1a 2b 2a 3b 3a 4b 4a 5b 5a 6b 6a 7b 7a 1b
T
1
TIME
A B D C E F A G
T
2
Detect
SF
I-S #1.a
9a
8a SF-R/F E/S/RDI
8b SF-R/F E/L/IDLE
T
0

-

I
D
L
E

S
T
A
T
E
T
1

-

R
I
N
G

S
F
LEGEND
Node sourcing K1 and K2
NOTE - See Tables 6-1 and 6-2 for byte K1 and K2 formats.
Node in full pass-through (bidirectional);
K1, K2 and protection channels
11b 10b 11b 10b 11b 10b 11b 10b 8a 9a 11b 10b 11b 10b
9a SF-R/E F/S/RDI
9b SF-R/E F/L/IDLE
10b SF-R/F E/L/Br&Sw
11b SF-R/E F/L/Br&Sw
12a WTR/F E/S/Br&Sw
12b WTR/F E/L/Br&Sw
13a WTR/E F/S/Br&Sw
T
2

-

R
I
N
G

S
F

C
L
E
A
R
S
T
0
I-P #1
I-P #1
1a NR/B A/S/IDLE
1b NR/G A/S/IDLE
2a NR/C B/S/IDLE
2b NR/A B/S/IDLE
3a NR/D C/S/IDLE
3b NR/B C/S/IDLE
4a NR/E D/S/IDLE
4b NR/C D/S/IDLE
5a NR/F E/S/IDLE
5b NR/D E/S/IDLE
6a NR/G F/S/IDLE
6b NR/E F/S/IDLE
7a NR/A G/S/IDLE
7b NR/F G/S/IDLE
Detect
SF
I-P #1
I-P #1
I-P #1
9b
8b
8b
1b
2b 2a
3a
13b 12b 13b 12b 13b 12b 13b 12b 12a 13a 13b 12b 13b 12b
Ring
Br&Sw
I-S #1.b
Ring
Br&Sw
I-S #1.b 8a
10b 11b
11b
11b
10b
10b
SF clears
RR to 9a
S #3
SF clears
RR to 8a
S #3
10b 11b
10a 11a
WTR starts
S-S #3.a
I-S #7
WTR starts
S-S #3.a
I-S #7
12b 13b
12a 13a
11b
13b
10b
12b
13b WTR/E F/L/Br&Sw
SONET BLSR Equipment Generic Criteria GR1230CORE
Equipment Criteria and K1/K2 Byte Protocol Issue 4, December 1998

6-60
Figure 6-7. Two- or Four-Fiber BLSR - Bidirectional SF (Ring) (Concluded)
Revert to
idle
I-P #2
Revert to
idle
I-P #2
Revert to
idle
I-S #2
Revert to
idle
I-S #2
K2 K1
1a 2b 2a 3b 3a 4b 4a 5b 5a 6b 6a 7b 7a
1b
T
3
TIME
A B D C E F A G
T
2

-

S
T
E
A
D
Y
S
T
A
T
E
T
3

-

W
T
R

E
X
P
I
R
E
S
LEGEND
Node sourcing K1 and K2
NOTE - See Tables 6-1 and 6-2 for byte K1 and K2 formats.
Node in full pass-through (bidirectional);
K1, K2 and protection channels
12a WTR/F E/S/Br&Sw
12b WTR/F E/L/Br&Sw
13a WTR/E F/S/Br&Sw
T
0

-

I
D
L
E

S
T
A
T
E
1a NR/B A/S/IDLE
1b NR/G A/S/IDLE
2a NR/C B/S/IDLE
2b NR/A B/S/IDLE
3a NR/D C/S/IDLE
3b NR/B C/S/IDLE
4a NR/E D/S/IDLE
4b NR/C D/S/IDLE
5a NR/F E/S/IDLE
5b NR/D E/S/IDLE
6a NR/G F/S/IDLE
6b NR/E F/S/IDLE
7a NR/A G/S/IDLE
7b NR/F G/S/IDLE
13b 12b 13b 12b 13b 12b 13b 12b 12a 13a 13b 12b 13b 12b
13b WTR/E F/L/Br&Sw
WTR expires
RR to 13a
S #3
WTR expires
RR to 12a
S #3
12b 13b
12c 13c
RR recvd
Drop ring Sw
I-S #2
RR recvd
Drop ring Sw
I-S #2
14b 15b
14a 15a
13b
15b
12b
14b
Drop ring Br
Send idle
I-S #2
Drop ring Br
Send idle
I-S #2 5a 6b
5b 6a
6a
5b
Revert to
idle
I-P #2
Revert to
idle
I-P #2
12c RR-R/F E/S/Br&Sw
13c RR-R/E F/S/Br&Sw
14a NR/F E/S/Br
14b NR/F E/L/Br
15a NR/E F/S/Br
15b NR/E F/L/Br
Revert to
idle
I-P #2
6-61
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Equipment Criteria and K1/K2 Byte Protocol

Figure 6-8. Two- or Four-Fiber BLSR - Unidirectional SD (Ring)
T1
SD
G A B
F
E D C
SONET BLSR Equipment Generic Criteria GR1230CORE
Equipment Criteria and K1/K2 Byte Protocol Issue 4, December 1998

6-62
Figure 6-8. Two- or Four-Fiber BLSR - Unidirectional SD (Ring) (Concluded)
2b
3b
4b
5b
9b
8b
8b
K2 K1
8b
1a 2b 2a 3b 3a 4b 4a 5b 5a 6b 6a 7b 7a 1b
T
1
TIME
A B D C E F A G
T
2
Detect SD
I-S #1.a
8a
8a SD-R/E F/S/IDLE
8b SD-R/E F/L/IDLE
T
0

-

I
D
L
E

S
T
A
T
E
T
1

-

R
I
N
G

S
D
LEGEND
Node sourcing K1 and K2
NOTE - See Tables 6-1 and 6-2 for byte K1 and K2 formats.
Node in full pass-through (bidirectional);
K1, K2 and protection channels
12b 13b 12b 13b 12b 13b 12b 13b 13a 12a 12b 13b 12b 13b
9a RR-R/F E/S/IDLE
9b SD-R/F E/L/IDLE
10a RR-R/F E/S/Br
10b SD-R/F E/L/Br
11a SD-R/E F/S/Br
11b SD-R/E F/L/Br
12a SD-R/E F/S/Br&Sw
12b SD-R/E F/L/Br&Sw
T
2

-

R
I
N
G

S
D

C
L
E
A
R
S
T
0
9a
I-P #1
I-S #1.a
I-S #1.c
9b
I-P #1
I-P #1
I-P #1
I-P #1
S #3
9b
3b
4b
5b
Ring Br
I-S #1.b
Ring Br
I-S #1.b
10a 10b
10b
11b 11a
11b
11b
10b
1a NR/B A/S/IDLE
1b NR/G A/S/IDLE
2a NR/C B/S/IDLE
2b NR/A B/S/IDLE
3a NR/D C/S/IDLE
3b NR/B C/S/IDLE
4a NR/E D/S/IDLE
4b NR/C D/S/IDLE
5a NR/F E/S/IDLE
5b NR/D E/S/IDLE
6a NR/G F/S/IDLE
6b NR/E F/S/IDLE
7a NR/A G/S/IDLE
7b NR/F G/S/IDLE
Ring Sw
I-S #1.b
12b 12a
12b
13a 13b 12b
Ring Sw
I-S #1.b
13b
14b 14a
SD clears
WTR
starts
S-S #3.a
SEE FIGURE 6-4 at T2 and FIGURE 6-5 at T3
FOR CLEARING SEQUENCE
13a RR-R/F E/S/Br&Sw
13b SD-R/F E/L/Br&Sw
14a WTR/E F/S/Br&Sw
14b WTR/E F/L/Br&Sw
6-63
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Equipment Criteria and K1/K2 Byte Protocol

Figure 6-9. Two- or Four-Fiber BLSR - Node Failure
T1
Node
Failure
G A B
F
E D C
SONET BLSR Equipment Generic Criteria GR1230CORE
Equipment Criteria and K1/K2 Byte Protocol Issue 4, December 1998

6-64
Figure 6-9. Two- or Four-Fiber BLSR - Node Failure (Continued)
D ----/0000
K2 K1
1a 2b 2a 3b 3a 4b 4a 5b 5a 6b 6a 7b 7a 1b
T
1
TIME
A B D C E F A G
T
2
Detect SF
on svce
and prot
8a SF-R/F E/S/RDI
8b SF-R/F E/L/IDLE
T
0

-

I
D
L
E

S
T
A
T
E
T
1

-

N
O
D
E

F

F
A
I
L
S
LEGEND
Node sourcing K1 and K2
NOTE - See Tables 6-1 and 6-2 for byte K1 and K2 formats.
Node in full pass-through (bidirectional);
K1, K2 and protection channels
9a SF-R/F G/S/RDI
9b SF-R/F G/L/IDLE
10b SF-R/F E/L/Br&Sw
11b SF-R/F G/L/Br&Sw
T
2

-

N
O
D
E

F

R
E
P
A
I
R
E
D
T
0
1a NR/B A/S/IDLE
1b NR/G A/S/IDLE
2a NR/C B/S/IDLE
2b NR/A B/S/IDLE
3a NR/D C/S/IDLE
3b NR/B C/S/IDLE
4a NR/E D/S/IDLE
4b NR/C D/S/IDLE
5a NR/F E/S/IDLE
5b NR/D E/S/IDLE
6a NR/G F/S/IDLE
6b NR/E F/S/IDLE
7a NR/A G/S/IDLE
7b NR/F G/S/IDLE
11b 10b 11b 10b 11b 10b 11b 10b 8a 9a 11b 10b
11b 10b 11b 10b 11b 10b 11b 10b 8a 9a 11b 10b D
D
I-S #1.a Detect SF
on svce
and prot
I-S #1.a
Node F catastrophic
failure
8b 8a 9a 9b I-P #1
I-P #1
I-P #1
I-P #1
3b
9b
2b
3b
8b
2a
3a
Squelch
Ring Br&Sw
Squelch
Ring Br&Sw
I-S #1.b
I-S #1b
8a 9a 10b 11b 11b
10b
Node F repaired
Sends default
APS codes
SF clears
Recv default
APS codes
I-S #4
I-S #3
SF clears
Recv default
APS codes
I-S #4
D D
8a 9a 10b 11b 0000/-/---
Signaling from Nodes E and G
does not change until they receive
non-default APS codes.
Default APS codes are defined as
having K1 ID value = K2 ID value
= 0000 with the remaining bits =
dont care (see Table 6-5).
6-65
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Equipment Criteria and K1/K2 Byte Protocol

Figure 6-10. Two- or Four-Fiber BLSR - Node Failure (Concluded)
Revert to
idle
I-P #2
Revert to
idle
I-P #2
Revert to
idle
I-P #2
Revert to
idle
I-P #2
D ----/0000
K2 K1
1a 2b 2a 3b 3a 4b 4a 5b 5a 6b 6a 7b 7a 1b
T
3
TIME
A B D C E F A G
Rcvs non-default APS
code, Drop ring
Br&Sw, Stop squelch-
ing, Full pass-through
8a SF-R/F E/S/RDI
T
2

-

S
T
E
A
D
Y

S
T
A
T
E
LEGEND
Node sourcing K1 and K2
NOTE - See Tables 6-1 and 6-2 for byte K1 and K2 formats.
Node in full pass-through (bidirectional);
K1, K2 and protection channels
9a SF-R/F G/S/RDI
10b SF-R/F E/L/Br&Sw
11b SF-R/F G/L/Br&Sw
T
3
-

N
o
d
e

F

r
e
p
a
i
r
e
d

a
n
d
S
W

r
e
a
d
y
11b 10b 11b 10b 11b 10b 11b 10b 8a 9a 11b 10b D D
S #1.c
12a
13a
S-P #1.f
0000/-/---
S-P #1.f
13a
12a 11b 10b
13a
12a
I-S #5
I-S #5
Rcvs long path Sw re-
quests from both neigh-
bors
No state transition
Rcvs own sourced re-
quests in both dirs
Sends idle code
6b 6a
6a
6b
1a
2b
2a
3b
3a
4b
4a
5b 5a
6b 6a
7b 7a
1b
Revert to
idle
I-P #2
Revert to
idle
I-S #2
Revert to
idle
I-P #2
12a SF-R/G F/L/IDLE
13a SF-R/E F/L/IDLE
T
0

-

I
D
L
E

S
T
A
T
E
1a NR/B A/S/IDLE
1b NR/G A/S/IDLE
2a NR/C B/S/IDLE
2b NR/A B/S/IDLE
3a NR/D C/S/IDLE
3b NR/B C/S/IDLE
4a NR/E D/S/IDLE
4b NR/C D/S/IDLE
5a NR/F E/S/IDLE
5b NR/D E/S/IDLE
6a NR/G F/S/IDLE
6b NR/E F/S/IDLE
7a NR/A G/S/IDLE
7b NR/F G/S/IDLE
Node F SW ready
Sends appropriate K bytes
SONET BLSR Equipment Generic Criteria GR1230CORE
Equipment Criteria and K1/K2 Byte Protocol Issue 4, December 1998

6-66
Figure 6-11. Four-Fiber BLSR - Unidirectional Signal Fail (Ring) Pre-empting a
Unidirectional Signal Degrade (Span) on Non-Adjacent Spans
/
XX
G A B
F
E D C
T2 SF-R
T3 SF-R Clears
T1 SD-S
6-67
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Equipment Criteria and K1/K2 Byte Protocol

Figure 6-11. Four-Fiber BLSR - Unidirectional Signal Fail (Ring) Pre-empting a
Unidirectional Signal Degrade (Span) on Non-Adjacent Spans (Continued)
6b
1b
Drop span
Br&Sw
K2 K1
8b 7b 8b 7b 8b 7b 8b 7b 8b 7b 3a 8a 8b 7b
3a
2b 1b 2b 1b 1a 2a 2b 1b 2b 1b 2b 1b 2b 1b
1a
T
1
TIME
A B D C E F A G
RR-S/D C/S/Br&Sw
T
2
Detect SF-R
Enter Sw
S-P #2.b
3b
1b SD-S/D C/L/Br&Sw
2a SD-S/C D/S/Br&Sw
2b SD-S/C D/L/Br&Sw
3a SF-R/G F/S/RDI
3b SF-R/G F/L/IDLE
4a NR/C D/S/Br
4b NR/C D/L/Br
5a RR-R/F G/S/IDLE
5b SF-R/F G/L/IDLE
6a NR/D C/S/IDLE
6b NR/B C/S/IDLE
7b SF-R/G F/L/Br&Sw
8a RR-R/F G/S/Br&Sw
8b SF-R/F G/L/Br&Sw
T
1

-

S
P
A
N

S
D
T
2

-

R
I
N
G

S
F
LEGEND
Node sourcing K1 and K2
NOTE - See Tables 6-1 and 6-2 for byte K1 and K2 formats.
2b
P-P #1
3b 5b
Enter Sw S-P #2.b
5a
4b
Drop span
Sw
S-S #2.c
4a
6a
S-S #2.d
6b 5b
P-P #1
1b
6a
Drop span Br
Enter Full
pass-through
S-S #2.e
3b
5b
Enter full
pass-through
S-P #1.b
3b
3a
Ring Br&Sw
I-S #1.b
7b
8b 8a
P-P #1
Ring Br&Sw
I-S #1.b
7b
8b
5b
3b
Node in pass-through (bidirectional);
K1, K2 and protection channels
SONET BLSR Equipment Generic Criteria GR1230CORE
Equipment Criteria and K1/K2 Byte Protocol Issue 4, December 1998

6-68
Figure 6-12. Four-Fiber BLSR - Unidirectional Signal Fail (Ring) Pre-empting a
Unidirectional Signal Degrade (Span) on Non-Adjacent Spans (Concluded)
1a 1b
11b
9b
K2 K1
9a
8b 7b 8b 7b
8b 7b 8b
7b 8b 7b 3a 8a 8b 7b
1a
T
3
TIME
A B D C E F A G
RR-S/D C/S/Br&Sw
SF-R clears
enter WTR
S-S #3.a
9b
1b SD-S/D C/L/Br&Sw
2a SD-S/C D/S/Br&Sw
2b SD-S/C D/L/Br&Sw
3a SF-R/G F/S/RDI
3b SF-R/G F/L/IDLE
4a NR/C D/S/Br
4b NR/C D/L/Br
5a RR-R/F G/S/IDLE
5b SF-R/F G/L/IDLE
6a NR/D C/S/IDLE
6b NR/B C/S/IDLE
7b SF-R/G F/L/Br&Sw
8a RR-R/F G/S/Br&Sw
8b SF-R/F G/L/Br&Sw
T
1

-

S
P
A
N

S
D
T
2

-

R
I
N
G

S
F
LEGEND
Node sourcing K1 and K2
NOTE - See Tables 6-1 and 6-2 for byte K1 and K2 formats.
10b
Enter WTR S-S #3.b
8a
Node in K byte pass-through
Node in full pass-through (bidirectional);
K1, K2 and protection channels
Enter Sw
S-P #2.a
10b
11a
Enter Sw
Span Br
S-P #2.a
I-S #1.b
12a 12b
Drop ring
Br&Sw
S #5
S #8
11b
8a
12b
S #5
S #8
Drop ring
Br&Sw
11b 12b
1b
14b
Span Sw
I-S #1.b
9a WTR/G F/S/Br&Sw
9b WTR/G F/L/Br&Sw
10b WTR/F G/L/Br&Sw
11a SD-S/C D/S/IDLE
11b SD-S/C D/L/IDLE
12a RR-S/D C/S/Br
12b SD-S/D C/L/Br
T
3

-

R
I
N
G

S
F

C
L
E
A
R
S
2a 2b
Span
Br&Sw
I-S #1.b
2b 1b 2b 1b 1a 2a 2b 1b 2b 1b 2b 1b 2b 1b
2b
6-69
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Equipment Criteria and K1/K2 Byte Protocol

Figure 6-13. Four-Fiber BLSR - Unidirectional Signal Fail (Ring) Pre-empting a
Unidirectional Signal Degrade (Span) on Adjacent Spans
/
X
X
G A B
F
E D C
T1 SD-S
T2 SF-R
T3 SF-R Clears
SONET BLSR Equipment Generic Criteria GR1230CORE
Equipment Criteria and K1/K2 Byte Protocol Issue 4, December 1998

6-70
Figure 6-13. Four-Fiber BLSR - Unidirectional Signal Fail (Ring) Pre-empting a
Unidirectional Signal Degrade (Span) on Adjacent Spans (Continued)
K2 K1
8b 7b 8b 7b 8b 7b 7a 3a 8b 7b 8b 7b 8b 7b
3b
2b 1b 2b 1b 2b 1b 2b 1b 1a 2a 2b 1b 2b 1b
1a
T
1
TIME
A B D C E F A G
RR-S/F E/S/Br&Sw
T
2
Detect SF-R
Drop span Sw
S-S #2.b
3a
1b SD-S/F E/L/Br&Sw
2a SD-S/E F/S/Br&Sw
2b SD-S/E F/L/Br&Sw
3a SF-R/D E/S/RDI
3b NR/F E/S/Br
4a RR-R/E D/S/IDLE
4b SF-R/E D/L/IDLE
5a SD-S/E F/S/IDLE
5b SD-S/E F/L/IDLE
6b SF-R/D E/L/IDLE
7a RR-R/E D/S/Br&Sw
7b SF-R/E D/L/Br&Sw
8b SF-R/D E/L/Br&Sw
T
1

-

S
P
A
N

S
D
T
2

-

R
I
N
G

S
F
LEGEND
Node sourcing K1 and K2
NOTE - See Tables 6-1 and 6-2 for byte K1 and K2 formats.
4a
S-P #2.b
4b 5b
Drop span
Br&Sw
S-S #2.d
5a
Node in pass-through (bidirectional);
K1, K2 and protection channels
Enter Sw
6b
Ring Br&Sw
Drop span Br
S-S #2.e
3a
7a 7b
8b
3a
P-P #1
P-P #1
P-P #1
P-P #1
4b
4b
4b
4b
2b
5b
5b
6b
6b
6b
2b
1b
Enter full
pass-through S-P #1.b
5b
Ring
Br&Sw
I-S #1.b
Ring
Br&Sw
I-S #1.b
8b
7b
6-71
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Equipment Criteria and K1/K2 Byte Protocol

Figure 6-14. Four-Fiber BLSR - Unidirectional Signal Fail (Ring) Pre-empting a
Unidirectional Signal Degrade (Span) on Adjacent Spans (Concluded)
K2 K1
8b 7b 8b 7b 8b 7b 7a 3a 8b 7b 8b 7b 8b 7b
9b
2b 1b 2b 1b 2b 1b 2b 1b 1a 2a 2b 1b 2b 1b
1a
TIME
A B D C E F A G
RR-S/F E/S/Br&Sw
T
3
SF-R clears
WTR starts
S-S #3.a
9a
1b SD-S/F E/L/Br&Sw
2a SD-S/E F/S/Br&Sw
2b SD-S/E F/L/Br&Sw
3a SF-R/D E/S/RDI
3b NR/F E/S/Br
4a RR-R/E D/S/IDLE
4b SF-R/E D/L/IDLE
5a SD-S/E F/S/IDLE
5b SD-S/E F/L/IDLE
6b SF-R/D E/L/IDLE
7a RR-R/E D/S/Br&Sw
7b SF-R/E D/L/Br&Sw
8b SF-R/D E/L/Br&Sw
T
1

-

S
P
A
N

S
D
T
2

-

R
I
N
G

S
F
LEGEND
Node sourcing K1 and K2
NOTE - See Tables 6-1 and 6-2 for byte K1 and K2 formats.
7a
S-S #3.b
10b
Node in pass-through (bidirectional);
K1, K2 and protection channels
WTR starts
5b
Enter Sw
5a
S-P #2.a
11a
S #5
I-S #1.b
11b
Drop ring
Br&Sw
Span Br
2b
I-S #1.b
2a
Span
Br&Sw
1a
Span Sw
I-S #1.b
1b 5b 11b
Drop ring Br&Sw
Enter K byte pass-
through
10b
9b
S #5
S-P #1.g
P-P #2
P-P #2
P-P #2
P-P #2
5b
5b 11b
2b 11b
2b
11b
1b
2b 11b
Node in K byte pass-through
9a WTR/D E/S/Br&Sw
9b WTR/D E/L/Br&Sw
10b WTR/E D/L/Br&Sw
11a RR-S/E F/S/Br
T
3

-

R
I
N
G

S
F

C
L
E
A
R
S 11b SD-S/E F/L/Br
SONET BLSR Equipment Generic Criteria GR1230CORE
Equipment Criteria and K1/K2 Byte Protocol Issue 4, December 1998

6-72
Figure 6-15. Four-Fiber BLSR - Unidirectional Signal Fail (Span) Pre-empting a
Unidirectional Signal Fail (Ring) on Adjacent Spans
G A B
F
E D C
T1 SF-R T2 SF-S
T3 SF-S Clears
X
X X
6-73
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Equipment Criteria and K1/K2 Byte Protocol

Figure 6-15. Four-Fiber BLSR - Unidirectional Signal Fail (Span) Pre-empting a
Unidirectional Signal Fail (Ring) on Adjacent Spans (Concluded)
K2 K1
2a 1b 2a 1b 1a 2b 2a 1b 2a 1b 2a 1b 2a 1b
3a
2a 1b 2a 1b 1a 2b 2a 1b 2a 1b 2a 1b 2a 1b
1a
TIME
A B D C E F A G
RR-R/D C/S/Br&Sw
T
2
Detect SF-S
Enter span
Sw
S-P #2.a
3b
1b SF-R/D C/L/Br&Sw
2a SF-R/C D/L/Br&Sw
2b SF-R/C D/S/RDI
3a SF-S/D E/L/IDLE
3b SF-S/D E/S/IDLE
4a RR-S/E D/S/Br
4b SF-P/C D/S/RDI
5a SF-S/D E/L/Br&Sw
5b SF-S/D E/S/Br&Sw
6a RR-S/D C/S/IDLE
6b SF-P/D C/L/IDLE
7a RR-S/E D/S/Br&Sw
8a SF-R/C D/L/IDLE
T
1

-

R
I
N
G

S
F
T
2

-

S
P
A
N

S
F
LEGEND
Node sourcing K1 and K2
NOTE - See Tables 6-1 and 6-2 for byte K1 and K2 formats.
4a
G #1.c
S-S #2.h
4b
Node in pass-through (bidirectional);
K1, K2 and protection channels
Drop ring
Br&Sw
Span Br
9a RR-R/D C/S/IDLE
9b SF-R/D C/L/IDLE
T
3

-

S
P
A
N

S
F

C
L
E
A
R
S
T
1
Span
Br&Sw
I-S #1.b
5a 6b 5a 6b 6a 4b
7a
5b 5a 6b 5a 6b 5a 6b
T
3
10a
Span SF clears
Enter WTR
S-S #3.a
10b
8a
Drop span
Br&Sw
Signal
Ring SF
S-S #2.d
2b
2a
Ring
Br&Sw
I-S #1.b
2b
Ring
Br&Sw
I-S #1.b
1a 1b
8a
1b
3a
6a 6b
3a 6b
5a 5b
7a 4b
Span-
Sw
I-S #1.b
S-S #2.g
Drop ring
Br&Sw
Enter
span Sw
P-P #2
K-byte
pass-
through
6b
K-byte
pass-
through
Enter ring
Sw state I-S #1.a
I-S #1.c
9b
10a
9a
9b
1b
2a
Node in K-byte pass-through
10a WTR/D E/L/Br&Sw
10b WTR/D E/S/Br&Sw
SONET BLSR Equipment Generic Criteria GR1230CORE
Equipment Criteria and K1/K2 Byte Protocol Issue 4, December 1998

6-74
Figure 6-16. Two- or Four-Fiber BLSR - Unidirectional Signal Fail (Ring) Plus
Unidirectional Signal Fail (Ring) on Non-Adjacent Spans
X
XX
X
G A B
F
E D C
T2 SF-R
T3 SF-R Clears
T1 SF-R
6-75
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Equipment Criteria and K1/K2 Byte Protocol

Figure 6-16. Two- or Four-Fiber BLSR - Unidirectional Signal Fail (Ring) Pre-
empting a Unidirectional Signal Degrade (Span) on Non-Adjacent Spans
(Concluded)
K2 K1
11b 10b 11b 10b 11b 10b 11b 10b 10a 11a 11b 10b 11b 10b
12b
10a
TIME
A B D C E F A G
RR-R/F E/S/Br&Sw
T
2
Detect SF-R
Enter Sw
Ring Br&Sw
S-P #2.a
S-P #3
12a
10b SF-R/F E/L/Br&Sw
11a SF-R/E F/S/RDI
11b SF-R/E F/L/Br&Sw
12a SF-R/B C/S/RDI
12b SF-R/B C/L/Br&Sw
13a RR-R/C B/S/Br&Sw
13b SF-R/C B/L/Br&Sw
T
1

-

F
I
R
S
T

R
I
N
G

S
F
T
2

-

S
E
C
O
N
D

R
I
N
G

S
F
LEGEND
Node sourcing K1 and K2
NOTE - See Tables 6-1 and 6-2 for byte K1 and K2 formats.
Node in pass-through (bidirectional);
K1, K2 and protection channels
T
1
11b 13b 13a 12a 12b 10b 12b 10b 10a 11a 11b 13b 11b 13b
T
3
13a
Enter Sw
Ring Br&Sw
S-P #2.a
S-P #3
13b
13a
Clear SF-R
Drop ring
Br&Sw
Enter full
pass-through
S-P #1.e
10b
11b
Drop ring Br&Sw
Enter full pass-
through
S-P #1.f
10b
13b
10b
11b 10b 11b 10b 11b 10b 11b 10b 10a 11a 11b 10b 11b 10b
No Action
S #5
SONET BLSR Equipment Generic Criteria GR1230CORE
Equipment Criteria and K1/K2 Byte Protocol Issue 4, December 1998

6-76
Figure 6-17. Two- or Four-Fiber BLSR - Node Failure on a Ring with VT access
D ----/0000
K2 K1
1a 2b 2a 3b 3a 4b 4a 5b 5a 6b 6a 7b 7a 1b
T
1
TIME
A B D C E F A G
T
2
Detect SF
on svce
and prot
8a SF-R/F E/S/RDI
8b SF-R/F E/L/IDLE
T
0

-

I
D
L
E

S
T
A
T
E
T
1

-

N
O
D
E

F

F
A
I
L
S
LEGEND
Node sourcing K1 and K2
NOTE - See Tables 6-1 and 6-2 for byte K1 and K2 formats.
Node in full pass-through (bidirectional);
K1, K2 and protection channels
9a SF-R/F G/S/RDI
9b SF-R/F G/L/IDLE
10b SF-R/F E/L/Br&Sw
11b SF-R/F G/L/Br&Sw
T
2

-

N
O
D
E

F

R
E
P
A
I
R
E
D
T
0
1a NR/B A/S/IDLE
1b NR/G A/S/IDLE
2a NR/C B/S/IDLE
2b NR/A B/S/IDLE
3a NR/D C/S/IDLE
3b NR/B C/S/IDLE
4a NR/E D/S/IDLE
4b NR/C D/S/IDLE
5a NR/F E/S/IDLE
5b NR/D E/S/IDLE
6a NR/G F/S/IDLE
6b NR/E F/S/IDLE
7a NR/A G/S/IDLE
7b NR/F G/S/IDLE
11b 10b 11b 10b 11b 10b 11b 10b 8a 9a 11b 10b
11b 10b 11b 10b 11b 10b 11b 10b 8a 9a 11b 10b D D
I-S #1.a Detect SF
on svce
and prot
I-S #1.a
8b 8a 9a 9b I-P #1
I-P #1
I-P #1
I-P #1
2b
9b
2b
2a
4a
Squelch STS
Ring Br&Sw
Squelch STS
Ring Br&Sw
I-S #1.b
I-S #1b
8a 9a 10b 11b 11b
10b
Node F repaired
Sends default
APS codes
SF clears
Recv default
APS codes
I-S #4
I-S #3
SF clears
Recv default
APS codes
I-S #4
D D
8a 9a 10b 11b
0000/-/---
Signaling from Nodes E and G
does not change until they receive
non-default APS codes.
Default APS codes are defined as
having K1 ID value = K2 ID value
= 0000 with the remaining bits =
dont care (see Table 6-5).
Enter into unidi-
rectional full
pass-through
Squelch VTs
as required
Enter full
pass-through
Squelch VTs
as required
Enter full
pass-through
I-P #1
I-P #1
8b
8b
Node F catastrophic
failure
Unsquelch VT access-
ed STSs (I-S #1.b)
Node in full pass-through (unidirectional);
K1, K2 and protection channels
6-77
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Equipment Criteria and K1/K2 Byte Protocol

Figure 6-18. Two- or Four-Fiber BLSR - Node Failure on a Ring with VT access
(Concluded)
Revert to
idle
I-P #2 Revert to
idle
I-P #2
D ----/0000
K2 K1
1a 2b 2a 3b 3a 4b 4a 5b 5a 6b 6a 7b 7a 1b
T
3
TIME
A B D C E F A G
Rcvs non-default APS
code, Drop ring
Br&Sw, Stop squelch-
ing, Full pass-through
8a SF-R/F E/S/RDI
T
2

-

S
T
E
A
D
Y

S
T
A
T
E
LEGEND
Node sourcing K1 and K2
NOTE - See Tables 6-1 and 6-2 for byte K1 and K2 formats.
Node in full pass-through (bidirectional);
K1, K2 and protection channels
9a SF-R/F G/S/RDI
10b SF-R/F E/L/Br&Sw
11b SF-R/F G/L/Br&Sw
T
3
-

N
o
d
e

F

r
e
p
a
i
r
e
d

a
n
d
S
W

r
e
a
d
y
11b 10b 11b 10b 11b 10b 11b 10b 8a 9a 11b 10b D D
S #1.c
12a
13a
S-P #1.f
0000/-/---
S-P #1.f
13a
12a 11b 10b
13a
12a
I-S #5
I-S #5
Rcvs long path Sw re-
quests from both neigh-
bors
No state transition
Rcvs own sourced re-
quests in both dirs
Sends idle code
6b 6a
6a
6b
1a
2a
3b
3a
4b
4a
5b 5a
6b 6a
7b 7a
1b
Revert to
idle
I-P #2
Revert to
idle
I-S #2
Revert to
idle
I-P #2
12a SF-R/G F/L/IDLE
13a SF-R/E F/L/IDLE
T
0

-

I
D
L
E

S
T
A
T
E
1a NR/B A/S/IDLE
1b NR/G A/S/IDLE
2a NR/C B/S/IDLE
2b NR/A B/S/IDLE
3a NR/D C/S/IDLE
3b NR/B C/S/IDLE
4a NR/E D/S/IDLE
4b NR/C D/S/IDLE
5a NR/F E/S/IDLE
5b NR/D E/S/IDLE
6a NR/G F/S/IDLE
6b NR/E F/S/IDLE
7a NR/A G/S/IDLE
7b NR/F G/S/IDLE
Node F SW ready
Sends appropriate K bytes
Unsquelch VTs
Revert to idle
I-P #2
2b
Unsquelch VTs
Revert to idle
I-P #2
SONET BLSR Equipment Generic Criteria GR1230CORE
Equipment Criteria and K1/K2 Byte Protocol Issue 4, December 1998

6-78
Figure 6-19. Two- or Four-Fiber BLSR - Node Failure on a Ring with VT access
and Extra Traffic
8b 8a
8b
9b
3c
D ----/0000
K2 K1
1a 2b 2a 3b 3a 4b 4a 5b 5a 6b 6a 7b 7a 1b
T
1
TIME
A B D C E F A G
T
2
Detect SF
on svce
and prot
8a SF-R/F E/S/RDI
8b SF-R/F E/L/IDLE
T
0

-

I
D
L
E

S
T
A
T
E
T
1

-

N
O
D
E

F

F
A
I
L
S
LEGEND
Node sourcing K1 and K2
NOTE - See Tables 6-1 and 6-2 for byte K1 and K2 formats.
Node in full pass-through (bidirectional);
K1, K2 and protection channels
9a SF-R/F G/S/RDI
9b SF-R/F G/L/IDLE
10b SF-R/F E/L/Br&Sw
11b SF-R/F G/L/Br&Sw
T
2

-

N
O
D
E

F

R
E
P
A
I
R
E
D
T
0
1a NR/B A/S/ET
1b NR/G A/S/ET
2a NR/C B/S/ET
2b NR/A B/S/ET
3a NR/D C/S/ET
3b NR/B C/S/ET
4a NR/E D/S/ET
4b NR/C D/S/ET
5a NR/F E/S/ET
5b NR/D E/S/ET
6a NR/G F/S/ET
6b NR/E F/S/ET
7a NR/A G/S/ET
7b NR/F G/S/ET
11b 10b 11b 10b 11b 10b 11b 10b 8a 9a 11b 10b
11b 10b 11b 10b 11b 10b 11b 10b 8a 9a 11b 10b D D
I-S #1.a Detect SF
on svce
and prot
I-S #1.a
9a 9b I-P #1
I-P #1
I-P #1
I-P #1
2c
4c
Squelch STS
Ring Br&Sw
Squelch STS
Ring Br&Sw
I-S #1.b
I-S #1b
8a 9a 10b 11b 11b
10b
Node F repaired
Sends default
APS codes
SF clears
Recv default
APS codes
I-S #4
I-S #3
SF clears
Recv default
APS codes
I-S #4
D D
8a 9a 10b 11b
0000/-/---
Signaling from Nodes E and G
does not change until they receive
non-default APS codes.
Default APS codes are defined as
having K1 ID value = K2 ID value
= 0000 with the remaining bits =
dont care (see Table 6-5).
Enter into unidi-
rectional full
pass-through
Squelch VTs
as required
Enter full
pass-through
Squelch VTs
as required
Enter full
pass-through
I-P #1
I-P #1
8b
Node F catastrophic
failure
Unsquelch VT access-
ed STSs (I-S #1.b)
Node in full pass-through (unidirectional);
K1, K2 and protection channels
1c
I-P #1
I-P #1
1c NR/G A/S/IDLE
2c NR/A B/S/IDLE
3c NR/D C/S/IDLE
4c NR/E D/S/IDLE
6-79
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Equipment Criteria and K1/K2 Byte Protocol

Figure 6-20. Two- or Four-Fiber BLSR - Node Failure on a Ring with VT access
and Extra Traffic (Concluded)
Revert to
idle
I-P #2 Revert to
idle
I-P #2
D ----/0000
K2 K1
1a 2b 2a 3b 3a 4b 4a 5b 5a 6b 6a 7b 7a 1b
T
3
TIME
A B D C E F A G
Rcvs non-default APS
code, Drop ring
Br&Sw, Stop squelch-
ing, Full pass-through
8a SF-R/F E/S/RDI
T
2

-

S
T
E
A
D
Y

S
T
A
T
E
LEGEND
Node sourcing K1 and K2
NOTE - See Tables 6-1 and 6-2 for byte K1 and K2 formats.
Node in full pass-through (bidirectional);
K1, K2 and protection channels
9a SF-R/F G/S/RDI
10b SF-R/F E/L/Br&Sw
11b SF-R/F G/L/Br&Sw
T
3
-

N
o
d
e

F

r
e
p
a
i
r
e
d

a
n
d
S
W

r
e
a
d
y
11b 10b 11b 10b 11b 10b 11b 10b 8a 9a 11b 10b D
D
S #1.c
12a
13a
S-P #1.f
0000/-/---
S-P #1.f
13a
12a 11b 10b
13a
12a
I-S #5
I-S #5
Rcvs long path Sw re-
quests from both neigh-
bors
No state transition
Rcvs own sourced re-
quests in both dirs
Sends idle code
6b 6a
6a
6b
1a
2a
3b
3a
4b
4a
5b 5a
6b 6a
7b 7a
1b
Revert to
idle
I-P #2
Revert to
idle
I-S #2
Revert to
idle
I-P #2
12a SF-R/G F/L/IDLE
13a SF-R/E F/L/IDLE
T
0

-

I
D
L
E

S
T
A
T
E
1a NR/B A/S/ET
1b NR/G A/S/ET
2a NR/C B/S/ET
2b NR/A B/S/ET
3a NR/D C/S/ET
3b NR/B C/S/ET
4a NR/E D/S/ET
4b NR/C D/S/ET
5a NR/F E/S/ET
5b NR/D E/S/ET
6a NR/G F/S/ET
6b NR/E F/S/ET
7a NR/A G/S/ET
7b NR/F G/S/ET
Node F SW ready
Sends appropriate K bytes
Unsquelch VTs
Revert to idle
I-P #2
2b
Unsquelch VTs
Revert to idle
I-P #2
6c NR/G F/S/IDLE
6d NR/E F/S/IDLE
SONET BLSR Equipment Generic Criteria GR1230CORE
Equipment Criteria and K1/K2 Byte Protocol Issue 4, December 1998

6-80
7-1
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Requirements for Ring Interconnection

7. Requirements for Ring Interconnection
Just as there are different types of traffic demand patterns in the network, there are different
types of architectures to fit the variety of demand patterns. The different architectures need
to interface, but the levels of survivability they provide vary. Thus, interface requirements
have to be stated for the interconnections.
The BLSR uses the drop and continue feature and a service selector to provide dual homing
and node diversity for inter-ring traffic. The control mechanisms of the rings that may be
interconnected are independent. Hence the restoration involves only the failed ring; it does
not affect the survivability of the rings that may be interconnected to the failed ring (i.e.,
using the protection bandwidth in one ring does not affect the protection bandwidth in the
other ring). However, because the span between the primary and secondary nodes is used
for the implementation of the drop and continue feature, the bandwidth has to be planned
for.
Figure 7-1 illustrates interconnection between two BLSRs using same-side routing. During
provisioning, the primary and the secondary nodes are identified on both rings. The primary
node has a service selector that allows it to choose either the traffic forwarded from the
secondary node via the high-speed connection or directly received from the other ring via
the low-speed connections. As Figure 7-1 shows, the traffic is provisioned bidirectionally,
and the drop and continue feature provides node diversity. Figure 7-2 illustrates
interconnection between two BLSRs using opposite-side routing. Figure 7-3 illustrates a
primary node failure on the BLSR.
Figure 7-4 illustrates interconnection of a BLSR with a Unidirectional Path-Switched Ring
(UPSR). GR1400CORE provides the criteria for the UPSR. The UPSR is included in this
GR only to provide criteria for interconnection. The APS protocol is independent of the
type of network interconnected to the ring. The criteria for a BLSR related to ring
interconnection are provided below.
R7-1 [167] The NE on the BLSR shall support the capability to interconnect
with another ring at two nodes, regardless of the type of the other ring
(path- or line-switched), on an STS basis. The interconnection is at the
electrical STS-M or OC-M level.
O7-2 [168] It is an objective that DSn (e.g., DS3) interconnection shall be
allowed between two BLSRs.
R7-3 [169] The primary and secondary nodes for ring interconnection shall be
selectable for each STS time slot.
R7-4 [170] For each STS, intermediate nodes shall be permitted between the
primary and secondary nodes.
SONET BLSR Equipment Generic Criteria GR1230CORE
Requirements for Ring Interconnection Issue 4, December 1998

7-2
Figure 7-1. Interconnection between Two BLSRs (Same-side Routing)
SS
BLSR
: Service Selector
SS
BLSR
P
P
S
S
: Primary Node P
: Secondary Node S
: Drop and Continue
SS
secondary circuit
secondary circuit
7-3
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Requirements for Ring Interconnection

Figure 7-2. Interconnection between Two BLSRs (Opposite-side Routing)
SS
BLSR
: Service Selector
SS
BLSR
P1
P2
S1
S2
: Primary Node P
: Secondary Node S
: Drop and Continue
SS
secondary/service
circuit
service/secondary
circuit
SONET BLSR Equipment Generic Criteria GR1230CORE
Requirements for Ring Interconnection Issue 4, December 1998

7-4
Figure 7-3. Primary Node Failure on a BLSR
S
BLSR
BLSR
SS
SS
SS : Service Selector
P
P S
: Primary Node P
: Secondary Node S
: Working Traffic Direction
: Fiber
: Drop and Continue
: Protection Traffic Direction
7-5
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Requirements for Ring Interconnection

Figure 7-4. Interconnection of a BLSR with a UPSR
SS
BLSR
SS : Service Selector
PS
UPSR
P
P
S
S
: Primary Node P
: Secondary Node S
PS
PS
PS : Path Selector
: Drop and Continue
SONET BLSR Equipment Generic Criteria GR1230CORE
Requirements for Ring Interconnection Issue 4, December 1998

7-6
R7-5 [171] A NE service selector shall be provided for each STS time slot to
allow the NE to act as a primary node and to select either the traffic
received from the other network or the traffic received from the secondary
node, as Figure 7-1 shows.
CR7-6 [276] The primary and secondary nodes may be required to be
provisionable, on a per inter-ring circuit basis, to provide in-service swap
of the primary and secondary node functions by default.
In order to minimize the total traffic hit due to in-service swap of the primary and secondary
nodes, the following criteria shall apply:
CR7-7 [277] The length of the hit caused by in-service swap of primary and
secondary node functions shall not exceed 50 ms.
R7-8 [172] The default path for the service selector shall be that selected from
the interconnecting line unless provisioned otherwise.
CR7-9 [173] The NE shall be required to be provisionable, on a per-path basis,
to select the path from either the high-speed line or the interconnecting line
by default.
R7-10 [174] Protection for ring interconnection failures (i.e., service selector
switching criteria) shall be based on detecting STS path signal defects.
R7-11 [175] The set of manual commands for path protection switching that are
presented in GR1400CORE shall be used for manual control of the
BLSR service selector. This includes commands for both revertive and
non-revertive service selector operation.
R7-12 [176] The service selector shall select the better of the two received STS
signals in accordance with hierarchy of failure conditions provided in
GR1400CORE for drop-nonterminated paths.
For the benefit of the reader, the hierarchy of conditions for service selector switching
(derived from GR1400CORE) are provided in Table 7-1. Highest priority 1 is worst
impairment, and lowest priority 7 is least impairment.
R7-13 [177] The service selector shall meet the detection and clearing time
criteria in GR1400CORE for all the STS Path Signal Fail and STS Path
Signal Degrade conditions.
Unlike in GR1400CORE where switching on PDI-P is provisionable, the service selector
is required to switch based on detection of PDI-P.
7-7
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Requirements for Ring Interconnection

R7-14 [178] The selection criteria at the service selector shall include PDI-P.
For multiple failures occurring at different levels on the same path, the switching hierarchy
must select the least impacted signal. Following are examples of the actions taken by the
service selector under multiple conditions:
Upon detecting STS PDI and STS SD on one path and STS PDI on the other path, the
path with only STS PDI will be selected.
Upon detecting STS PDI and STS SD on one path and STS-Path AIS on the other path,
the path with STS PDI and STS SD will be selected.
Upon detecting PDI on both incoming signal labels, the signal with the smallest PDI
count will be selected. If the PDI count is the same on both signal labels, no action is
required.
Figure 7-5 illustrates signal failure that leads to detection of the STS PDI-P code on the low
speed line by the service selector, and detection of the STS SD on the high speed line by
the service selector. STS PDI-P is a path layer signal, and is given in the STS path signal
label of the path overhead. STS SD is detected based on having a BER exceeding a
specified threshold (see R8-79), which is derived from STS path BIP-8 of the path
overhead. Based on the hierarchy of conditions, the path with the STS SD will be selected.
See Section 3 of GR253CORE for descriptions of both line overhead and path overhead
signals.
R7-15 [179] For any failure detected at the service selector, a holdoff time of 100
ms shall apply.
O7-16 [278] It is an objective that for any failure detected at the service selector,
a holdoff time of 50 ms shall apply.
a. Excessive BER is nominally any BER > 10
-3
. However, some network providers may desire this
threshold value to be user-selectable over the range 10
-3
to 10
-5
.
Table 7-1. Hierarchy of Conditions for Service Selection
Condition Priority
Lockout of Protection 1
Forced Switch 2
Path AIS, Path LOP or unequipped signal label 3 (hard failure)
Excessive Path BER (Signal Fail)
a
4 (hard failure)
Payload Defect Indication (PDI-P) 5
Signal Degrade (path) 6
Manual Switch 7
SONET BLSR Equipment Generic Criteria GR1230CORE
Requirements for Ring Interconnection Issue 4, December 1998

7-8
R7-17 [180] No service selector switch shall occur if the failure that triggers the
holdoff timer (e.g., STS Path AIS) is no longer present when the holdoff
timer expires.
R7-18 [181] The service selector switch completion time shall be 50 ms.
The 50 ms switch completion time at the service selector does not include the detection
time, nor the holdoff time.
R7-19 [182] Service selector operation shall be revertive.
Revertive operation implies that a wait-to-restore (WTR) time is needed. The WTR time
for the service selector will be identical to that specified in R8-83.
CR7-20 [183] The NE shall be required to be provisionable to use non-revertive
switching at the service selector.
Figure 7-5. Service Selection in the Presence of STS PDI-P and STS-SD
SS
P
P
S
S
secondary circuit selected
STS-1 LOS
STS PDI-P detected by
the service selector
insert AIS-V for
individual VTs,
sends PDI-P
W-DCS/
MUX
: Service Selector
: Primary Node P
: Secondary Node S
: Drop and Continue
SS
STS SD detected
by the service se-
lector
W-DCS/
MUX
7-9
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Requirements for Ring Interconnection

By default, however, operation of the service selector will be revertive (i.e., unless
provisioned otherwise). In the revertive mode, in the absence of any locally detected
impairments or externally initiated commands, the service selector will select from the
default path.
R7-21 [184] When traffic is selected from a secondary node, all other nodes on
the ring shall be able to respond in the normal manner (i.e., the same as
when traffic is received from a primary node).
R7-22 [185] The service selector protection switching shall not require inter-ring
signaling. Providing protection for the interconnecting line is not
considered inter-ring signaling.
R7-23 [186] The NE on the BLSR shall support the capability to operate
independently of an interconnected ring, regardless of the type of the
second ring, consistent with the K1 and K2 byte protocol given in Section
6.
R7-24 [187] The NE on the BLSR shall support the capability to interconnect
with other networks, such as mesh networks, at two points on an electrical
STS-M/OC-M basis.
7.1 Ring Interconnection Using Protection Capacity
An alternative method to ring interworking takes advantage of the protection bandwidth
between primary and secondary ring interworking nodes (in the drop-and-continue method
of ring interworking) and the protection bandwidth between the terminating node and
secondary node (in the dual transmit method of ring interworking) to address the capacity
issue that arises when transporting the secondary circuit on working bandwidth in protected
ring interconnection applications. The issue is one of early bandwidth exhaust between
primary (or terminating node) and secondary node when using only working bandwidth to
transport the secondary circuit.
The problem can be illustrated by referring to Figure 7-1, which shows two interconnected
BLSRs. The two interconnecting ring nodes in each BLSR use the working bandwidth for
the extended circuit between them that allows for dual node ring interworking, i.e., the
combination of the continue segment of the drop and continue (from the primary to the
secondary node), along with the duplicate feed segment from the other ring (from the
secondary node to the service selector in the primary node).
By taking advantage of the protection bandwidth between the interconnection nodes on the
BLSR, less working bandwidth would be consumed as compared to the method of using
only working bandwidth for ring interconnection. For example, either one, or both, of the
secondary circuits in Figure 7-1 can use the protection bandwidth between the primary and
SONET BLSR Equipment Generic Criteria GR1230CORE
Requirements for Ring Interconnection Issue 4, December 1998

7-10
secondary nodes, instead of using the working bandwidth. The protection bandwidth
between the primary and secondary nodes on a BLSR can be used even if the other
interconnected ring is a UPSR (as shown in Figure 7-4).
CR7-25 [279] The secondary circuit may be required to be provisionable to be
carried on either the working bandwidth or the protection bandwidth.
R7-26 [280] Secondary circuit on protection bandwidth shall be considered
extra traffic, and byte K2 bits 6-8 shall indicate the Extra Traffic code.
The capability to provide add/drop, pass through, or drop and continue for the inter-ring
traffic carried on the protection bandwidth (i.e., extra traffic) is given in R6-31.
CR7-27 [281] The secondary node may be required to provide add, drop, and
passing through of inter-ring traffic directly from the protection channels.
R7-28 [282] The squelching trigger for inter-ring traffic shall use the secondary
node and the terminating (or source) node as the trigger.
The following requirements provide secondary node capabilities that allow the secondary
node to perform ring interworking functions in case of a primary node failure or isolation.
R7-29 [283] In the event of a primary node failure, the secondary node shall
select inter-ring traffic directly from and/or bridge traffic to the protection
bandwidth on the span away from the failed primary node.
Note that for unidirectional inter-ring traffic, either the service selection or the bridging
function is performed at the secondary node to provide ring interconnection survivability.
For bidirectional inter-ring traffic, both functions are performed.
O7-30 [284] It is an objective that in the event of a failure between (but not
including) the primary and terminating (or source) node, the secondary
node shall select (using a service selector) the better of the two inter-ring
traffic from
1. The low-speed line, or
2. The protection bandwidth from the direction of the primary node.
In addition, the secondary node shall provide drop and continue function
for inter-ring traffic onto
1. The low-speed line, and
2. The protection channel in the direction of the primary node.
In order to provide correct squelching of inter-ring traffic and correct routing of inter-ring
traffic based on the requirements given above, additional information is required to
7-11
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Requirements for Ring Interconnection

represent inter-ring circuits carried on the protection bandwidth. This table is referred to as
the RIP Table.
CR7-31 [285] The secondary node may be required to maintain a RIP Table that
contains, for each incoming and outgoing inter-ring circuit carried on the
protection bandwidth, the terminating (or source) node address and the
primary node address.
Figure 3-42 illustrates a conceptual representation of a RIP Table, based on inter-ring
traffic given in Figure 3-41.
The option for using only working bandwidth for inter-ring traffic provides the highest
level of survivability. If less survivability can be tolerated, certain options that take
advantage of protection bandwidth between interconnecting ring nodes may be used,
including:
Same-side ring interworking with one secondary circuit on working and one
secondary circuit on protection,
Same-side ring interworking with both secondary circuits on protection,
Opposite-side ring interworking with the service circuit on working and the secondary
circuit on protection.
Assigning the service circuit to protection bandwidth in opposite-side ring interworking is
not recommended. Unlike the recommended options above, concurrent link failures in both
interconnected rings causes loss of inter-ring communication when this option is used (see
Figure 3-40).
R7-32 [286] The service circuit shall be provisionable to be carried on the
working bandwidth by default, or carried on the protection bandwidth.
7.2 Dual Transmit Method
Using this method for ring interworking, inter-ring traffic is diversely routed to the primary
and the secondary nodes. The terminating node dual feeds the signal to the primary and
secondary ring interconnection nodes. The circuit destined for the primary node will be
carried on the working channels. The circuit destined for the secondary node (i.e.,
secondary circuit) may be carried on either the working channels or the protection channels.
In the other direction, the terminating node selects, by a service selector, between the
primary and secondary circuit signals.
The dual transmit method of ring interworking may be considered a method for load-
balancing inter-ring traffic and for reducing the total amount of bandwidth (working plus
protection bandwidth) used for inter-ring traffic. For example, if the span between the
primary and secondary nodes are heavily loaded with intra- and inter-ring traffic (including
SONET BLSR Equipment Generic Criteria GR1230CORE
Requirements for Ring Interconnection Issue 4, December 1998

7-12
both working and extra traffic), then the dual transmit method may be used to balance the
load on the span, thus potentially reducing congestion. The dual transmit method also
provides a marked savings in terms of ring bandwidth usage in the case of a terminating
node in between the primary and secondary ring interconnection nodes.
CR7-33 [295] The BLSR may be required to support Dual Transmit method of
ring interworking.
R7-34 [296] If the dual transmit method is supported, a NE service selector shall
be provided for each STS time slot to allow the NE to support terminating
node functionality in the dual transmit method and to select either the inter-
ring traffic received from the primary node or the secondary node.
8-1
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Operations, Administration, Maintenance, and Provisioning (OAM&P) Criteria

8. Operations, Administration, Maintenance, and
Provisioning (OAM&P) Criteria
This section discusses the OAM&P requirements associated with NEs in a SONET BLSR.
The BLSR architecture and protection switching signaling protocol impose some new
operations requirements on BLSR NEs. This section defines these new requirements. A
BLSR NE is expected to meet all applicable generic SONET NE requirements in
GR253CORE. This section also highlights some of those generic requirements to
provide understanding and clarity in the context of BLSRs or their specific needs.
References to OSs in this section do not preclude the use of subnetwork operations
controllers (element managers) in BLSR applications. The NE detects and reports, for
example, an incoming signal failure. Whether the NE reports the failure to a surveillance
OS or to an element manager does not alter the basic NE requirement. Similarly, there are
NE functions that are initiated by an instruction from an external source. The basic NE
reaction to the instruction is independent of the source (OS, element manager, or WS).
8.1 Operations Data Networking
GR253CORE contains requirements for the types of communications paths and the
interface details for the respective paths. The following requirements further clarify the
specific operations data networking requirements for NEs in a BLSR.
R8-1 [188] For transaction oriented applications via the OS/NE and NE/NE
interfaces, SONET NEs operating in a BLSR architecture shall support the
Section DCC and shall use the Common Management Information Service
Element (CMISE) Application Service Element (ASE) and shall adhere to
the service mappings and information models in GR836CORE, OTGR
Section 15.2: Generic Operations Interfaces Using OSI Tools
Information Model and Usage: Transport Configuration and Surveillance
for Network Elements, and GR1042CORE, Generic Requirements for
Operations Interfaces Using OSI Tools Information Model Overview:
Synchronous Optical Network (SONET) Transport Information Model.
The UPSR information model shall be used to support the service selector
function and can also be found in GR1042CORE.
R8-2 [189] A SONET NE operating in a 4-fiber BLSR shall support the
SONET Section DCC on the fiber pair carrying working channels, and
physically protect the Section DCC when span protection switching is
active.
R8-3 [190] A SONET NE operating in a BLSR shall support selective routing
at the network layer for the Section DCC.
SONET BLSR Equipment Generic Criteria GR1230CORE
Operations, Administration, Maintenance, and Provisioning (OAM&P) Criteria Issue 4, December 1998

8-2
Selective routing includes the End System (ES) to Intermediate System (IS) protocol (ES-
IS) and the IS-IS protocol. A NE in a BLSR application is expected to act as both an ES and
an IS, depending on whether it receives the message or forwards it to another node. See
GR253CORE for a description of, and criteria for selective routing.
8.2 Alarm Surveillance Requirements
Generic requirements for alarm surveillance are generally unchanged in a BLSR
architecture. The BLSR APS protocol differs significantly from the SONET linear APS
protocol. While some of the linear APS protocol trouble specifications are applicable in a
BLSR application, other linear APS protocol specifications are inappropriate. For the
reader's ease, each BLSR APS channel defect, including those that remain unchanged or
are extensions of the corresponding linear APS trouble, is defined. The requirements for
entering and exiting the BLSR APS channel failures are also defined. (See Section 8.2.1.)
R8-4 [191] A NE operating in a BLSR shall detect the occurrence of equipment
failures, incoming signal failures (except possibly linear APS troubles),
and incoming maintenance signals, and shall take the appropriate actions
as defined in GR253CORE. BLSR APS troubles are defined in Section
8.2.1.
Ring interconnection as described in Section 7 makes use of drop and continue in
conjunction with a service selector. The service selector function is identical to the path
protection switch described in GR1400CORE (i.e., service selector switching is identical
to the path switching used for the UPSR). Hence it is expected that the BLSR NE
supporting a service selector function will meet the applicable criteria for path protection
switching in GR1400CORE.
R8-5 [192] A NE operating in a BLSR that supports a service selector function
shall meet the criteria for path switching NEs as defined in
GR1400CORE. Furthermore, the service selector shall meet the criteria
for the path selector function as defined in GR1400CORE.
This includes all applicable operations and maintenance criteria described in
GR1400CORE.
Incoming signal failures and degraded performance on the lines forming the BLSR and
other protectable equipment failures (as Section 6 defines) are the stimuli for automatically
initiated protection switching requests.
R8-6 [193] Any NE-detectable failure that affects the ability of the BLSR NE
to write or detect and process the contents of the APS channel
appropriately shall be reported as an alarm.
8-3
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Operations, Administration, Maintenance, and Provisioning (OAM&P) Criteria

R8-7 [194] A NE that detects an incoming, low-speed signal failure (add/drop
port) that is carrying traffic intra-ring or a mixture of intra- and inter-ring
(or dual-homed) traffic shall report the failure, if appropriate, as a service-
affecting alarm.
8.2.1 Troubles in the APS Channel
The BLSR architecture depends on reliable communications and adherence to the BLSR
APS protocol rules to self heal. This section defines several troubles that are indicators of
the quality of the APS channel and potential problems in the APS software or hardware of
a node that can be detected elsewhere on the ring. Four BLSR APS defects are defined:
Default K Bytes, Inconsistent APS Codes, Node ID Mismatch, and Improper APS Codes.
Default K Bytes defect is the detection of default code in three consecutive frames [see
R6-130].
Inconsistent APS Codes defect is the occurrence of 12 successive frames, starting with
the last frame containing previously consistent APS code, where no 3 consecutive
frames contain identical APS bytes. Because signaling Line RDI in bits 6-8 of byte K2
has precedence over APS status indicator codes, detection of Line RDI as the only
difference is not considered a mismatch.
Node ID Mismatch defect is the occurrence of three consecutive and identical frames
that contain a source node (K2 bits 1-4) that does not match a neighbor's Node ID
according to the destination node's resident ring map or that does not match an entry
in the ring map.
Improper APS Codes defect is the occurrence of three consecutive and identical
frames containing
1. Unused codes in bits 6-8 of byte K2 (Table 6-2)
2. Codes irrelevant to the specific protection switching operation request
An example of a code irrelevant to the protection switching operation is a Reverse
Request with a long path indicator. It is also any code other than an expected
response or higher priority request to an existing long path ring protection
switching request (bridge or release sequence) in a 2-fiber ring or a short path span
protection switching request in a 4-fiber ring. This defect incorporates APS timer
expirations (i.e., failure to receive the expected response code within the allotted
time).
In the process of establishing a ring protection switch in a 2-fiber ring, the node
requesting the bridge may briefly receive idle codes with a short path indicator not
destined to it and not from its neighbor, as the intermediate nodes enter pass-
through bidirectionally. Although expected in the transition, it is not the proper
response to a ring switch request and is considered an improper APS code defect.
SONET BLSR Equipment Generic Criteria GR1230CORE
Operations, Administration, Maintenance, and Provisioning (OAM&P) Criteria Issue 4, December 1998

8-4
(A signal failure response with a bridged indicator would be a proper response.
Similarly, a response with a bridged and switched indicator and a higher priority
request are also proper responses.)
3. Requests irrelevant to the state of the ring
Examples include any span protection switch request to a 2-fiber ring NE, and a
request for a lower priority failure when the ring is already satisfying a higher
priority request.
4. ET code received (sourced) in bits 6-8 of byte K2 on the incoming (outgoing) span,
but not sourced (received) on the outgoing (incoming) span
R8-8 [195] A NE shall detect the Default K Bytes defect according to the above
definition.
R8-9 [196] A NE shall detect Inconsistent APS Code defect according to the
above definition.
R8-10 [197] A NE shall detect Node ID Mismatch defect according to the above
definition.
R8-11 [198] A NE shall detect Improper APS Codes defect according to the
above definition.
R8-12 [199] The Default K Bytes defect shall not result in an Inconsistent APS
Code, Node ID Mismatch, or Improper APS Codes defect.
R8-13 [200] A NE shall terminate the Default K Bytes defect when three
consecutive and identical frames are detected that do not contain default
code.
R8-14 [201] A NE shall terminate the Inconsistent APS Codes defect when three
consecutive and identical frames are detected.
R8-15 [202] A NE shall terminate the Node ID Mismatch defect when three
consecutive and identical frames contain a source ID that corresponds to
its neighbor according to the ring map.
R8-16 [203] The transition from one improper APS code to another improper
APS code shall not cause the NE to terminate the Improper APS Codes
defect.
R8-17 [204] A NE shall terminate the Improper APS Codes defect when three
consecutive and identical frames contain an appropriate message.
8-5
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Operations, Administration, Maintenance, and Provisioning (OAM&P) Criteria

R8-18 [205] If the NE continues to detect an APS trouble defect (Default K
Bytes, Inconsistent APS Codes, Node ID Mismatch, or Improper APS
Codes) for 2.5 (0.5) seconds, the NE shall declare the appropriate BLSR
APS trouble failure.
R8-19 [206] A NE in the idle or switching state shall send an autonomous
message to the OS upon declaring a Default K Bytes failure.
R8-20 [207] A NE in the idle or switching state shall send an autonomous
message to the OS upon declaring an Inconsistent APS codes failure.
R8-21 [208] A NE in the idle, switching, or pass-through state shall send an
autonomous message to the OS upon declaring a Node ID Mismatch
failure.
R8-22 [209] A NE in the idle or switching state shall send an autonomous
message to the OS upon declaring an Improper APS codes failure.
R8-23 [210] A NE in the pass-through state shall not send an autonomous
message to the OS upon declaring the Default K bytes failure.
R8-24 [211] A NE in the pass-through state shall not send an autonomous
message to the OS upon declaring Inconsistent APS codes failure.
R8-25 [212] A NE in the pass-through state shall not send an autonomous
message to the OS upon declaring Improper APS codes failure.
R8-26 [213] The network provider shall be able to retrieve information about the
APS troubles entered by the NE.
R8-27 [214] A BLSR APS failure is cleared when the relevant APS defect is
absent for a time T, where T is 10 (0.5) seconds. The NE shall clear the
alarm indication and, if appropriate, send a clear message to the OS.
R8-28 [215] When the NE detects a loss of signal defect, loss of frame defect, or
Line AIS defect, the NE shall clear any APS trouble defect(s).
8.2.2 Additional Information Needed in BLSR
Knowledge of the squelching activity can help one to understand the impact of failures and
protection switching activities on services. The BLSR protection switching protocol
permits the ring to sustain multiple signal failures, or multiple forced switches, or to drop
an existing protection switch to respond to a higher priority failure. When a BLSR ring is
SONET BLSR Equipment Generic Criteria GR1230CORE
Operations, Administration, Maintenance, and Provisioning (OAM&P) Criteria Issue 4, December 1998

8-6
segmented, those services that are destined to the other segment are squelched to prevent
misconnections. If the ring had been segmented and no squelching had to be initiated by the
switching nodes, then no restorable traffic was lost. Squelching is an indicator of non-
restorable services.
R8-29 [216] A NE shall automatically report to an OS if it is squelching traffic,
including STS-level squelching of working traffic, extra traffic (STSs), or
individual VTs, persistently for a time T, where T is 2.5 (0.5) seconds. In
the case of a switching NE that is squelching working traffic at the STS
level, the message shall additionally identify the line in the direction
toward the failure for which working traffic is squelched. In the case of an
intermediate node that squelches extra traffic or individual VTs, the
automatic message shall identify the node.
Note that squelching working traffic at the STS level refers to the switching nodes
insertion of AIS either into or out of the working channels corresponding protection
channel. Hence, for a switching NE, the message will identify the line carrying the working
channel (the line in the direction toward the failure) for which STS-level squelching is
occurring, not the line carrying the squelched protection channel for that STS (the line in
the direction away from the failure).
The preceding requirement also applies to a NE already in the switching state that squelches
traffic in response to a subsequent switch request. A single automatic message from a NE
to indicate that squelching is activated is sufficient to understand the overall status of the
ring. If further information is needed, it can be retrieved from the NE.
R8-30 [217] A NE shall be capable of responding to a query by an OS (or from
a WS) whether STS-level working traffic in the requested line is being
squelched.
R8-31 [218] A NE that is squelching traffic shall identify those channels,
including working STS channels, extra traffic STS channels, or individual
VT channels that are squelched if queried by an OS or WS.
It is acceptable for a NE to respond to this query with the status of every channel or to
identify only those that are squelched.
8.2.3 BLSRs and Routine Operations
This section is primarily descriptive and is directed more to the network provider. Planning
for the deployment of rings should include a review of current maintenance procedures to
identify if changes are needed to support ring architectures. The BLSR protection switching
protocol imposes some procedural steps for certain activities. As rings are deployed in the
8-7
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Operations, Administration, Maintenance, and Provisioning (OAM&P) Criteria

network, present maintenance scheduling practices should be reviewed to analyze the
relationships of co-existing alarms and the affected services on a ring.
An alarm calls attention to a problem. Information reported in an alarm message (e.g.,
service-affecting or non-service-affecting) helps to determine the relative priority with
respect to other failures in the network and maintenance response-time. However, because
protection is shared around the ring, the reported severity of a failure or service impact is
not necessarily independent of other failures. Attending to a lower priority alarm may be
the fastest way to restore a service-affecting, critical alarm.
For example, consider a 4-fiber BLSR that has a bad transmitter. Span protection self-
healed the ring when the failure was detected. Before this card is replaced, a backhoe cuts
both the working and protection fibers elsewhere on the ring. This accident triggers the NE
to generate a service-affecting, critical alarm. There are now two work orders. If the circuit
pack (the non-service-affecting problem) is replaced first, the ring could self-heal itself
from the fiber cut. Depending on the availability of the replacement circuit pack and the
dispatch time, locating the cut and splicing may be the more time-consuming effort. In
those instances when multiple failures occur on a given ring, it is a good practice to review
the nature of the failures to determine the best course of action, and not to react exclusively
to the message content.
8.3 Performance Monitoring (PM)
In performance monitoring, the SONET NE accumulates counts of various error conditions
in PM registers. Depending on the particular error condition, a different PM register is
incremented to track the specific error. When the value of a given PM register reaches a
predefined threshold, a threshold crossing alert is sent to the OS. The performance
parameters are used to proactively determine when and where problems are likely to occur.
There are two classes of performance parameters: near-end and far-end. Near-end
performance parameters are used to characterize the quality of the incoming signal. Far-end
performance parameters are used to characterize the quality of the outgoing signal as it was
received at the far-end.
A NE in a BLSR architecture adheres to the performance monitoring and thresholding
requirements in GR253CORE. These include protection switching counts and protection
switching duration. A more detailed description of the various performance parameters
available to the line layer can be found in GR253CORE.
The following requirements provide details on the protection switching counts given in
GR253CORE.
R8-32 [219] The NE shall maintain protection switching counts for each
working line and its associated protection line. Separate counters are
required to differentiate between working and protection in a given line.
SONET BLSR Equipment Generic Criteria GR1230CORE
Operations, Administration, Maintenance, and Provisioning (OAM&P) Criteria Issue 4, December 1998

8-8
In a 2-fiber ring, protection and working capacity are co-resident in the same line. In the
event of a ring protection switch, the protection switching count associated with the
working capacity in the failed line is incremented and the protection switching count
associated with the protection capacity in the other, or protecting, line is incremented.
The protection switching count will also be incremented when traffic is switched back to
working capacity. See Figure 8-1.
R8-33 [220] In a 4-fiber ring, the NE shall maintain separate protection
switching counts for span and ring protection switches. See Figure 8-2.
Figure 8-1. Protection Switch Counts: 2-Fiber BLSR
Figure 8-2. Protection Switch Counts: 4-Fiber BLSR
A B
Fiber Pair A: PSC
PSC
work
protect
= X+1
Fiber Pair B: PSC
PSC
work
protect
=
=
= X+1
Y
Y
A B
PSC
ring C D
Protect Fiber Pair C
PSC
span
PSC
work
Working Fiber Pair A
PSC
ring
PSC
span
PSC
work
Protect Fiber Pair D
Working Fiber Pair B
1
2
Failure 1 increments PSC at C and PSC at A
span work
Failure 2 increments PSC at C and PSC at B
ring work
8-9
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Operations, Administration, Maintenance, and Provisioning (OAM&P) Criteria

Because the service selector switching criteria is based on detection of STS path-level
defects (i.e., at the path layer), the performance parameters and thresholding requirements
for service selector switching can be found in Section 6 of GR1400CORE, and Section
6.2.2.5 of GR253CORE. Note that protection switching counts is not a PM parameter at
the path layer.
8.4 Testing and Control Functions
The testing and diagnostic features as well as the control functions that GR253CORE
describes apply to NEs operating in a BLSR. Additionally, information relating to the
protection switching mode of the NE is required.
R8-34 [221] The NE operating in a BLSR shall make available upon request its
current K byte state idle, pass-through, or switching. The pass-through
state shall be further qualified as unidirectional full, bidirectional full, or K
byte pass-through.
O8-35 [222] It is an objective that the NE provide the ability to examine the
contents of the received APS channel (K1 and K2 bytes) for a series of
consecutive frames. When requested via a WS/NE or OS/NE interface, the
minimum display should accommodate APS bytes captured from 12
frames.
CR8-36 [223] To support acceptance testing procedures or trouble-shooting
protection switching anomalies in the field, the ability to request that an
APS channel capture function triggers when a new protection switch
request is detected, and display up to 100 ms of the contents of the APS
channel may be useful in some applications.
R8-37 [224] When reporting a completed, externally initiated protection switch
event, the NE in a 4-fiber BLSR shall include the type of the protection
switch (i.e., span or ring).
R8-38 [225] The NE shall support externally initiated control of the protection
switching functions Section 6.2.1.1 describes via the WS/NE or OS/NE
interfaces.
Section 6.2.1.1 includes, in the protection switching commands, the ability to clear a WTR
initiated by the NE. The intent is to reduce the amount of time that services are squelched.
Linear APS systems do not have a corresponding feature.
As Section 6 describes, the ring APS protocol permits a single Exercise-ring (EXER-R) or
Manual Switch-ring (MS-R) protection request to be completed (switched and bridged). If
an NE detects another request of the same priority for a different span in the APS channel,
SONET BLSR Equipment Generic Criteria GR1230CORE
Operations, Administration, Maintenance, and Provisioning (OAM&P) Criteria Issue 4, December 1998

8-10
the protocol rules dictate that the NEs respond by dropping the bridge and switch. Each NE
would continue to signal the externally initiated request until directed to clear. Each
externally initiated request that needs to be cleared requires a separate clear command.
Rather than having one users command negate the effect of another users command, an
alternative is to not accept the second command. The following requirements further
support the functionality Section 6.2.1.1 describes.
R8-39 [226] The NE shall deny any externally initiated APS command if an
equal or higher priority request exists on the ring that is not permitted to
coexist with the command (see R6-101).
R8-40 [227] Externally initiated commands that are denied or preempted due to
a higher priority APS request at that node shall not go pending. This
includes manual switches that are preempted by higher priority switches
anywhere in the ring.
In addition, R8-39 applies when the node to which the command is destined recognizes,
from the APS signaling on the ring, that a higher priority switch exists on the ring, even if
that signaling is span bridge request status signaling. For example, if FS-R is applied at a
node, and that node is receiving FS-S bridge request status signaling, the FS-R command
will be denied due to the higher priority FS-S on the ring.
R8-41 [228] The NE in a 2-fiber ring architecture shall deny any externally
initiated APS command unique to 4-fiber rings.
R8-42 [229] The NE shall deny an externally initiated Exercise ring command if
an Exercise request for a different span is currently using protection.
R8-43 [230] After receiving the expected response to an Exercise request or
detecting a higher priority request in the APS channel, the NE shall notify
the user of a successful completion and shall autonomously cease
transmitting the Exercise request code as if a clear command had been
received.
R8-44 [231] If the NE detects an APS channel failure while running the
exerciser, the NE shall report the failure to the OS as well as provide the
requisite response to the exerciser instruction. The NE ceases to transmit
the exerciser request.
The exerciser is the only manually initiated request that ceases to transmit the request. All
other manually initiated requests continue to source the request until the user instructs the
NE to stop. Of course, the NE reports any APS channel failure to the OS and may continue
to periodically inform the user of the status of the instruction.
8-11
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Operations, Administration, Maintenance, and Provisioning (OAM&P) Criteria

R8-45 [232] The NE shall deny an externally initiated Manual Switch ring
command if a Manual Switch ring for another span exists.
R8-46 [233] The NE shall implicitly clear an externally initiated protection
switch command when another, higher priority externally initiated
command for the same span is received without an intervening clear
command. For example, a user initiated Manual Switch span instruction
can be overridden with by a Forced Switch span instruction if it is for the
same span and initiated from the same NE.
A Lockout of Working Channels command and a Lockout of Protection Channels
command can co-exist for the same span.
R8-47 [234] The NE shall treat the Lockout of Working Channels and Lockout
of Protection Channels as the highest priority in the externally initiated
command hierarchy; each command must be cleared separately.
Information regarding the provisioning of primary and secondary node IDs shall be made
available to either the WS or the OS. In addition, information regarding the provisioning of
secondary circuits on the protection channels (for ring interworking on protection) shall be
made available to either the workstation or the OS.
R8-48 [287] The ability to retrieve the STS channels used to carry inter-ring
traffic is required.
It is acceptable for a NE to respond to this query with the status of every channel or to
identify only those channels that are carrying inter-ring traffic.
R8-49 [288] The ability to retrieve the primary and secondary node ID for each
inter-ring circuit via a WS/NE or OS/NE interface is required.
CR8-50 [289] A NE shall be capable of responding to a query by an OS (or from
a WS) whether in-service swap feature is enabled.
CR8-51 [290] The ability to retrieve the node IDs of the nodes that have
performed in-service swap is required.
R8-52 [291] A NE shall be capable of responding to a query by an OS (or from
a WS) whether the secondary or service circuit is carried on the protection
channel.
SONET BLSR Equipment Generic Criteria GR1230CORE
Operations, Administration, Maintenance, and Provisioning (OAM&P) Criteria Issue 4, December 1998

8-12
8.5 Memory Administration
Memory administration deals with the functions necessary to control and administer the
databases of NEs. SONET NEs operating in a BLSR contain provisionable data, similar to
other existing SONET NEs, as well as data unique to NEs in a BLSR. The memory
administration section of GR253CORE applies to a BLSR NE.
The ring protection switching protocol proposal requires [see R6-48] each NE to maintain
information about the ring. Because the protection switching protocol has allocated 4 bits
for the node identity, a ring is limited to 16 nodes or less. Each node on the ring is assigned
a node number (a node ID) that is used in the K1 and K2 byte signaling. Each node also
requires a map of the physical connectivity, or topology, of the ring. This map contains the
node identities in the order they are encountered on the ring and is referred to as the ring
map.
In addition to a node ID and a ring map, the ring protection switching protocol requires each
NE to maintain information about the working channels. For every provisioned service on
the ring, each NE through which the working channel transits must be provided with the
identities of the service's entry and exit nodes on the ring to avoid misconnected traffic. For
example, in a 2-fiber OC-48 ring, a NE has two incoming and two outgoing OC-48 lines,
with one incoming and one outgoing line for each direction of the ring. Both incoming and
outgoing lines each have 48 time slots, 24 of which are working channels. The NE must
know where each incoming and outgoing working time slots in each line enters and exits
the ring. Additionally, the STS channel must be flagged if it transports VT structured
payloads that are accessed on the ring.
For NEs that support VT access, a VT-level squelch table must be maintained, with an entry
for each VT time slot that the NE drops (see CR6-50). The VT squelch table will contain,
for each direction of the ring, the VT group and channel number and the source node ID
from which the VT time slot originated. For a VT that is dropped and continued in
conjunction with a service selector for ring interconnection, both the primary and
secondary node IDs will be identified as source nodes in the VT-level squelch table. Section
3.3 contains examples of VT squelch table.
Each time a service is added to or deleted from the ring, all affected BLSR NEs must update
their respective squelch table and cross-connect map. Figure 8-3 illustrates the squelch
table data that corresponds to the traffic example in Section 3.1. In the following discussion,
references are made to provisioning via the WS/NE or OS/NE interface. The gateway and
remote login functions (see Section 8.6 of GR253CORE) permit an OS or person at a WS
to communicate with other NEs indirectly.
In those scenarios where a BLSR is interconnected with another ring or a service is dual-
homed to protect against a node failure, the contents of the squelch table must reflect the
entire length of the service on an individual ring. For example, using Figure 7-1 as a
reference, inter-ring traffic entering the ring at the top node in the upper BLSR has a
8-13
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Operations, Administration, Maintenance, and Provisioning (OAM&P) Criteria

primary exit node at P and a secondary exit node at S. The squelch tables in each node
through which the service flows would contain the node identity for node S as the exit node.
R8-53 [235] The NE identity (Node ID) relative to the ring must be
provisionable via the WS/NE or OS/NE interface. Permitted values are 0
to 15 inclusive.
R8-54 [236] The NE shall deny any Node ID values outside the permitted range.
R8-55 [237] A NE on a BLSR shall accommodate a ring map for a ring size of
16 nodes.
R8-56 [238] The ring map data shall be provisionable via the WS/NE or OS/NE
interface.
R8-57 [239] The NE shall deny duplicated values in the ring map.
R8-58 [240] The contents of the squelch table shall be provisionable via the WS/
NE or OS/NE interface.
The squelch table information includes the entry and exit node IDs for each working STS
channel (i.e., the source/entry node ID for incoming channels and the destination/exit node
Node 1 Node 2
STS-1
#
West East
STS-1
#
West East
Outgoing Incoming Outgoing Incoming Outgoing Incoming Outgoing Incoming
Dst VT Src VT Dst VT Src VT Dst VT Src VT Dst VT Src VT
1 4 4 2 2 1 1 1 3 3
2 3 3 3 3 2 1 1 3 3
3 4 4 4 4 3 1 1 4 4
4 4 4 2 2 4 4 4 4 4
5 5 4 4
Node 3 Node 4
STS-1
#
West East
STS-1
#
West East
Outgoing Incoming Outgoing Incoming Outgoing Incoming Outgoing Incoming
Dst VT Src VT Dst VT Src VT Dst VT Src VT Dst VT Src VT
1 2 2 4 4 1 3 3 1 1
2 1 1 1 1 2 3 3 1 1
3 1 1 4 4 3 1 1 1 1
4 2 2 4 4 4 2 2 2 2
5 2 2 4 4 5 2 2
Figure 8-3. Squelch Table Example (Based on Table 3-1)
SONET BLSR Equipment Generic Criteria GR1230CORE
Operations, Administration, Maintenance, and Provisioning (OAM&P) Criteria Issue 4, December 1998

8-14
ID for outgoing channels) and an indicator for VT structured payloads for each STS time
slot in the working channels. Furthermore, for VT-access nodes that drop VTs from the
ring, the squelch table information includes the entry node ID for each dropped VT.
R8-59 [241] For nodes that support VT access, the contents of the VT squelch
table shall be provisionable via the WS/NE or OS/NE interface.
For NEs that support E-NUT, a E-NUT table must be maintained. A E-NUT table must be
present at each node on the BLSR. The table contains information to identify the channels
provisioned for E-NUT, and identify the type of protection switching (ring and span
switching) that is not available for each working channel.
R8-60 [297] For nodes that support E-NUT, the content of the E-NUT table shall
be provisionable via the WS/NE or OS/NE interface.
R8-61 [242] The Node ID, ring map, and squelch table data must reside in non-
volatile memory.
R8-62 [243] For nodes that support VT access, the VT squelch table must reside
in non-volatile memory.
R8-63 [298] For nodes that support E-NUT, the E-NUT table data must reside in
non-volatile memory.
R8-64 [244] The ability to retrieve the Node ID, the current ring map, squelch
table (STS and VT) and E-NUT table data via a WS/NE or OS/NE
interface is required.
R8-65 [245] A NE shall provide an appropriate designation to indicate that a
time slot is unassigned.
O8-66 [246] It is an objective that a service (i.e., the cross-connect and squelch
table information) can be provisioned with a single command.
The ring APS protocol protects an inter-ring service by also bridging the dropped signal in
the primary node in the same time slot (or the corresponding protection channel time slot)
toward the secondary node. To protect the add portion of the signal, an STS path service
selector is used.
R8-67 [247] For the BLSR to support inter-ring services or dual-homed services,
the signal selector association in a NE must be provisionable on a per STS
path basis, and shall associate any low-speed working channel with any
high-speed working channel.
8-15
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Operations, Administration, Maintenance, and Provisioning (OAM&P) Criteria

R8-68 [248] The NE shall be provisionable to establish the necessary cross-
connections for an inter-ring or dual-homed service. The STS path selector
service must be associated with the same STS time slot in the incoming
OC-N from the secondary node as the received signal from the ring into
the primary node.
CR8-69 [299] Secondary nodes that support ring interworking on protection, may
be required to maintain a RIP table that contains, for each incoming and
outgoing inter-ring circuit carried on the protection bandwidth, the
terminating (or source) node address and the primary node address.
Assigning a Node ID to a NE, maintaining the ring map, and even maintaining the squelch
table are processes that can reside in one or more platforms as compared with the NE, the
OS, and an element manager. The T1X1 APS protocol standard defines auto-provisioning
as the assignment of values to parameters within a NE without those values being
specifically entered externally by a user. At this time, such a function has not been
generically defined. Until one is defined, an auto-provisioning function represents a
proprietary, single-supplier solution. Thus, another approach is needed.
To support coordinating database updates in the different NEs around the ring, some
additional memory will be required for temporary storage. Although the occasions when
the Node ID of a NE would change are expected to be rare, the impact on the contents of
the squelch tables around the ring are significant. The addition and deletion of nodes will
occur occasionally as ring rearrangements are necessary. For the ring and ring protocol to
function properly, the NEs must operate with the same ring topology. The actual time it
takes to synchronize the databases in all NEs on the ring should be as small as possible.
The following approach to database integrity supports a generically implementable, near-
term solution for managing the critical database required by the BLSR APS protocol. Other
approaches are feasible and are for future study. Thus, the approach described below and
the associated requirements are an interim method and may be revised in the future.
By first making the changes in temporary memory, the accuracy and consistency of the
changes can be verified. At the appropriate time, the update of the active memory from the
temporary can then be better coordinated. The manufacturers recommended procedures for
ring rearrangement and capacity growth are considered an essential part of the appropriate
documentation and training, in accordance with GR253CORE, Section 7.
R8-70 [249] The NE shall provide sufficient memory to accommodate a
temporary ring map, temporary squelch table, and Node ID.
R8-71 [250] NEs that support VT access shall provide sufficient memory to
accommodate a temporary VT squelch table.
R8-72 [300] NEs that support E-NUT shall provide sufficient memory to
accommodate a temporary E-NUT table.
SONET BLSR Equipment Generic Criteria GR1230CORE
Operations, Administration, Maintenance, and Provisioning (OAM&P) Criteria Issue 4, December 1998

8-16
R8-73 [251] This temporary storage shall reside in non-volatile memory.
R8-74 [252] The NE must permit the user to change and to retrieve the contents
of the temporary storage.
O8-75 [253] It is an objective that the NE could be scheduled to update the
working ring map, the squelch table, or both from the temporary memory.
R8-76 [254] The NE shall permit the user to control the update of the active
memories from the temporary memories.
Some other provisionable data is needed for ring operations.
R8-77 [255] The BLSR APS line-level BER threshold for SD shall be user
programmable in the range of 10
-5
to 10
-9
.
CR8-78 [256] In some applications, the BLSR APS line-level BER threshold for
SF may be required to be user-selectable over the range 10
-3
to 10
-5
.
R8-79 [257] For service selector applications, the STS path signal degrade BER
threshold level at the service selector shall be user programmable, on a
node-wide basis, in the range 10
-5
to 10
-9
, with a default value of 10
-6
.
O8-80 [258] For service selector applications, it is an objective that the NE
provide the capability to allow the STS path signal degrade BER threshold
level to be provisioned on an individual STS path basis, rather than on a
node-wide basis.
R8-81 [259] The SONET NE operating in a 2-fiber BLSR ring shall provide a
provisionable WTR value.
R8-82 [260] The SONET NE operating in a 4-fiber BLSR ring shall provide two
separate WTR restore values. One shall be for ring protection on the high-
speed lines, and the other shall be for the span protection.
R8-83 [261] The WTR value shall be user programmable in the range of 5 to 12
minutes in 1 minute increments. The default value is 5.
O8-84 [292] It is an objective that the WTR value shall be accurate to within 30
seconds.
O8-85 [262] A wider range for WTR is desirable with a lower bound of zero
minutes. Finer granularity in the time intervals is not a violation of the
requirement.
8-17
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Operations, Administration, Maintenance, and Provisioning (OAM&P) Criteria

CR8-86 [263] For ring interconnection, if linear APS is provided on the
interconnecting line, the criteria for linear APS in Section 5.3 of
GR253CORE shall be applicable.
CR8-87 [264] If linear APS is provided for an OC-M tributary, the NE shall
provide a separate provisionable WTR value.
R8-88 [265] A value of 99 for either ring or span protection WTR times shall be
interpreted as specifying non-revertive action.
Typically, the range for WTR values is between 0 and 12 minutes in 1-minute increments.
The value 99 is intended as a flag, and is not to be used as a clock timer value set to 99
minutes.
R8-89 [266] Changes to the working database made via the WS/NE interface,
must be reported to the provisioning OS.
R8-90 [267] The NE shall periodically (automatically) run a data integrity check
mechanism for the ring map and report any errors to the provisioning and
maintenance OSs.
Security is another aspect of memory administration. To avoid accidental segmentation of
the ring and potential service outages, it would be desirable if the NE could place a higher
security level on the commands (or a parameter within a command) that permit a user to
invoke a forced switch or lockout on the ring.
O8-91 [268] It is an objective that the NE require a higher authorization level for
the initiator of a forced switch command, especially if the forced switch
will segment the ring. This also applies to lockout command, especially if
services will be dropped.
SONET BLSR Equipment Generic Criteria GR1230CORE
Operations, Administration, Maintenance, and Provisioning (OAM&P) Criteria Issue 4, December 1998

8-18
9-1
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 System Availability Criteria

9. System Availability Criteria
The proposed SONET BLSR equipment availability criteria are detailed in GR-418-CORE,
Generic Reliability Assurance Requirements for Fiber Optic Transport Systems, and reflect
the potential deployment of SONET rings. By revising the SONET hypothetical reference
circuit to include rings, the appropriate criteria were derived to ensure that the end-to-end
availability criteria have been satisfied.
SONET BLSR Equipment Generic Criteria GR1230CORE
System Availability Criteria Issue 4, December 1998

9-2
10-1
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Synchronization Criteria

10. Synchronization Criteria
The synchronization issues for a BLSR are the same as for a UPSR. These issues are
described in GR1400CORE, Section 4.7. Bellcore has reviewed the use of
synchronization status messages for interoffice rings. Bellcore believes that both directions
of a SONET ring can be used to provide primary and secondary references to the office
BITS (Building Integrated Timing Supply) clock in certain limited applications, as
discussed in Section 5 of GR436CORE. The synchronization messaging requirements
for SONET NEs and BITS clocks are included in GR253CORE and GR378CORE,
Generic Requirements for Timing Signal Generators, Issue 1, respectively. Note that in
order to use both directions of a SONET ring as primary and secondary references to the
BITS, both the SONET NE and the BITS must support synchronization messaging. Some
network operators have indicated that they do not think that the cost of upgrading their
BITS to support synchronization messaging will be worth the added benefit. For network
providers who do not plan to upgrade their BITS clocks to support SSMs, timing can only
be distributed in one direction around a ring.
SONET BLSR Equipment Generic Criteria GR1230CORE
Synchronization Criteria Issue 4, December 1998

10-2
ROL-1
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Requirement-Object List

Requirement-Object List ROL
R6-1 [1] The NE on a ring shall operate at a standard SONET rate. All the
nodes on the ring shall operate at the same rate.
Page 61
R6-2 [2] A ring switching capability using the ring protection switching
protocol described in Section 6.2 shall be provided.
Page 61
R6-3 [3] The ring APS protocol shall be carried on bytes K1 and K2 defined
only on the first STS-1 of an OC-N line carrying protection channels.
Page 61
R6-4 [4] Protection bandwidth shall restore 100% of the restorable traffic for
any single failure, including when the failure segments the ring.
Page 61
R6-5 [5] The NE shall be capable of supporting a protection switching
algorithm for up to 16 (see Section 6.2.2) nodes (i.e., the APS bytes, ring
map, etc., shall provide support for 16 nodes).
Page 61
R6-6 [6] Node ID assignment shall not be required to be consecutive for correct
operation.
Page 61
R6-7 [7] For all automatically initiated bridge requests, the request shall use the
K1 and the K2 bytes of the SONET line overhead.
Page 62
R6-8 [8] For externally initiated bridge requests that are included in the K1 byte
protocol, the K1 and K2 bytes shall be used.
Page 62
R6-9 [9] For externally initiated requests that are not included in the K1 byte
protocol, the Section DCC shall be used. (See Section 8 for criteria on the
DCC channel.)
Page 62
SONET BLSR Equipment Generic Criteria GR1230CORE
Requirement-Object List Issue 4, December 1998

ROL-2
R6-10 [10] The NE shall be capable of passing through the K1 and K2 bytes.
(See Section 6.2 for rules on APS byte generation and pass-through.)
Page 62
R6-11 [11] The NE shall meet the switch initiation time criteria in Section 5.3.3
of GR253CORE for all the Line Signal Fail (SF) and Line Signal
Degrade (SD) conditions.
Page 62
R6-12 [12] The NE shall meet the clearing time criteria in Section 5.3.4 of
GR253CORE for all the Line Signal Fail (SF) and Line Signal Degrade
(SD) conditions.
Page 62
R6-13 [13] The end-to-end switch completion time for a single ring or span
switch on a clean ring (as Section 2 defines) with less than 1200 km of fiber
and 16 nodes shall not exceed 50 ms. The switch completion time does not
include detection time.
Page 62
R6-14 [14] The end-to-end switch completion time for any ring or span switch
[when R6-13 is not applicable] shall not exceed 100 ms after detection.
Page 62
O6-15 [15] It is an objective that the end-to-end switch completion time for any
ring or span switch not exceed 50 ms after detection.
Page 62
R6-16 [16] Changing the bridge request type for an already initiated protection
switch request (span or ring) shall not increase the switch completion time.
For example, if a signal degrade span switch request is changed to a signal
failure span switch request for the same span, it shall not take any
additional time to complete the switch.
Page 62
R6-17 [18] The NE shall be able to allow traffic from one time slot to be
reassigned to another time slot while in service. This includes (1)
reassignment to another time slot on the same route (i.e., the short route or
the long route around the ring), and (2) reassignment to the same or
ROL-3
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Requirement-Object List

different time slot on the other route (i.e., from short to long, or long to
short).
Page 63
R6-18 [19] The associated squelch tables must be updated to reflect the new
traffic reassignment.
Page 63
R6-19 [20] When traffic is being moved from one time slot to another time slot,
in response to a switch request or for provisioning, the length of the hit
caused by switching (i.e., interruption in error-free traffic) shall not exceed
50 ms per direction.
Page 63
R6-20 [21] When traffic is being moved from one time slot to another time slot,
the number of Severely Errored Seconds (SESs) caused by switching shall
not exceed 2.
Page 63
R6-21 [22] The NE shall not reassign the time slots that are provisioned to
continue-through (i.e., the NE shall restrict the continue-through cross-
connects to using the same time slot on both lines of the ring). Performing
a ring switch is not considered reassignment. For secondary circuits in a
ring interworking application, R6-22 shall take precedence.
Page 63
R6-22 [23] To support drop and continue on protection for ring interworking
applications, the NE shall be allowed to reassign the time slots that are
provisioned to continue-through such that:
For an OC-N 2-fiber ring, working channel STS-M shall be reassigned
to protection channel STS-(N/2 + M), where M is an integer between
1 and N/2, inclusive.
For an OC-N 4-fiber ring, working channel STS-M shall be reassigned
to protection channel STS-M, where M is an integer between 1 and N,
inclusive.
Page 63
R6-23 [27] The NE shall allow 50% to 100% of the ring's span capacity to be
terminated from each direction when no extra traffic is on the ring.
SONET BLSR Equipment Generic Criteria GR1230CORE
Requirement-Object List Issue 4, December 1998

ROL-4
Page 64
R6-24 [28] The NE shall be able to bridge the working channels to preassigned
(not user-settable) protection channels and select from the preassigned
protection channels to perform protection switching.
Page 64
R6-25 [29] When the ring switch is in effect, the NE shall carry (bridge) traffic
on both the protection and the working channels.
Page 64
R6-26 [30] When a segment of the ring fails and a ring switch is to be performed,
the NE adjacent to the failed segment shall perform the ring switch.
Page 64
CR6-27 [31] A NE may be required to support VT-level access.
Page 64
R6-28 [32] Nodes with VT-access capability shall be able to cross-connect (i.e.,
add, drop, pass-through, and drop-and-continue) VTs from the VT-
accessed STSs.
Page 64
CR6-29 [33] Protection channels may be required to be available to provide extra
traffic.
Page 64
R6-30 [34] A NE that allows extra traffic shall support extra traffic on both sides
of the node.
Page 64
R6-31 [35] The capability to assign each timeslot for add/drop, pass through, or
drop-and-continue as in Figure 3-5, configuration (3) illustartes, shall
apply to the protection channels for NEs that allow extra traffic.
Page 64
R6-32 [36] A NE that allows extra traffic shall support extra add/drop ports for
the protection span capacity.
Page 64
ROL-5
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Requirement-Object List

R6-33 [37] Timeslot assignment of the extra traffic STS shall be supported.
Page 64
R6-34 [38] Extra traffic shall be removed when the protection channels are
needed for protection of working traffic according to the priority Section
6.2 provides.
Page 65
R6-35 [39] The nodes performing the ring switch shall bridge all the pass
through time slots, as well as the added traffic, from the spans in the
direction of the failure to the spans away from the failure, according to the
appropriate time slot correspondence provided in either Section 6.1.2 or
6.1.3.
Page 65
R6-36 [40] When the head-end node performs a ring switch, the working
channels being accessed in the affected direction shall be bridged onto and
received from the corresponding protection channels in the direction away
from the failure (i.e., the tail-end node has to perform the mapping from
the protection channels to the working channels).
Page 65
R6-37 [41] The NE on the ring shall allow an in-service addition of a node. (See
the forced switch - ring command in Section 6.2.1.1.2.)
Page 65
R6-38 [42] When a node is added to the ring, the length of the hit caused by
switching shall not exceed 50 ms per direction while performing the ring
switch, and 50 ms per direction while reverting to working channels.
Page 65
R6-39 [43] The NE on the ring shall allow an in-service deletion of a node. All
regular and extra traffic added/dropped at the node is manually removed
before the initiation of any request for this purpose. (See the forced switch
- ring command in Section 6.2.1.1.2.)
Page 65
R6-40 [44] When a node is deleted from the ring, the length of the hit caused by
switching shall not exceed 50 ms per direction while performing the ring
switch, and 50 ms per direction while reverting to working channels.
SONET BLSR Equipment Generic Criteria GR1230CORE
Requirement-Object List Issue 4, December 1998

ROL-6
Page 65
R6-41 [45] The NE shall support the capability to segment the ring into multiple
rings in response to a failure (or multiple failures) that isolates some nodes.
Traffic among the nodes in any segment shall remain in-service during the
failure.
Page 65
R6-42 [46] The NE shall support the capability to segment the ring into multiple
rings in response to high priority, manually initiated commands. (See the
forced switch - ring command in Section 6.2.1.1.2.)
Page 65
R6-43 [47] The NE shall not segment the ring in response to multiple ring bridge
requests with priority of signal degrade or lower (see Table 10-1 in Section
6.2.2).
Page 66
O6-44 [48] It is desirable that the NE on the ring allow an in-service upgrade to
a higher SONET rate (i.e., while the ring is being upgraded, all the nodes
operate at the previous rate until the upgrade is completed).
Page 66
R6-45 [49] The NE shall not misconnect traffic regardless of the number of
failures (i.e., the NE shall prevent misconnection of traffic
deterministically by squelching).
Page 66
R6-46 [50] Squelching shall be carried out according to the protocol in Section
6.2.2.
Page 66
R6-47 [51] Squelched traffic shall be replaced by inserting STS-path AIS (AIS-
P).
Page 66
R6-48 [52] Each node on the ring shall maintain the following information:
A node ID that must be unique in a single ring and must be between 0
and 15, inclusive.
ROL-7
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Requirement-Object List

A ring topology map (ring map), or sequence of node IDs to be used
for identifying nodes that have been isolated when failures occur at
one or more points on the ring.
A squelch table that contains, for each STS time slot that the node is
terminating (adding/dropping) or passing through, the first source
node ID of the STS entering the node and the last destination node ID
of the STS exiting the node.
Page 66
CR6-49 [53] If VT access is supported by any node on the ring, each node on the
ring shall maintain squelch tables that indicate which STS SPEs are
terminated and accessed at the VT level anywhere on the ring.
Page 66
CR6-50 [54] If VT access is supported, each node on the ring that has VT access
capability shall maintain, in addition to the information in R6-48 and CR6-
49, a VT-level squelch table that contains, for each VT time slot that the
node is dropping, the VT group number, channel number, and the source
node ID of the VT it is dropping to allow squelching of traffic in case of
node failures.
For VTs that are dropped and continued in conjunction with a service
selector for ring interconnection, both the primary and secondary nodes
shall be identified as the source node.
Page 66
R6-51 [55] The ring map along with the node IDs indicated in the K1 and K2
bytes shall be used to identify the traffic to be squelched.
Page 67
CR6-52 [293] The BLSR may be required to support Enhanced Non-preemptible
Unprotected Traffic (E-NUT).
Page 67
R6-53 [294] If E-NUT is supported on the ring, each node on the ring shall
maintain a E-NUT table. The E-NUT table shall indicate the type of
protection that is not available for each working STS time-slot in each
direction. See Figure 3-26 for an example of an E-NUT table.
Page 67
SONET BLSR Equipment Generic Criteria GR1230CORE
Requirement-Object List Issue 4, December 1998

ROL-8
R6-54 [56] Two fibers shall be used for working channels, and two fibers shall
be used for protection channels.
Page 67
R6-55 [57] The relationship between the working and the preassigned protection
channels on the paired working and protection fibers shall be as follows:
Protection channel # at the multiplex input = working channel # at the
multiplex input.
Page 67
R6-56 [58] A span switching capability consistent with the protocol in Section
6.2 shall be provided.
Page 67
R6-57 [59] A span switch request shall be used when possible instead of the ring
switch request.
Page 67
R6-58 [60] When protecting the failed span using the span switching capability,
both nodes adjacent to the failed span shall switch the entire line with no
change in time slot numbers.
Page 67
O6-59 [61] It is desirable that the NE on the ring allow an in-service upgrade
from a route diversified point-to-point system to a ring (e.g., from a 1+1
system to a ring).
Page 67
R6-60 [62] For a 2-fiber BLSR operating at an OC-N rate where N is even, the
first (N/2) time slots at the multiplex input shall be assigned for working
channels, and the last (N/2) time slots at the multiplex input shall be
assigned for protection channels. At the high-speed (multiplex output)
side, the protection channels are not contiguous because of the
multiplexing rules for SONET.
Page 67
R6-61 [63] The relationship between the working and the preassigned protection
channels shall be as follows:
ROL-9
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Requirement-Object List

Protection channel # at the multiplex input = working channel # at the
multiplex input + (N/2); N is even.
Page 68
R6-62 [270] The commands described in Sections 6.2.1.1 and 6.2.1.2 shall be
supported by the NE.
Page 614
R6-63 [64] Each clear command shall remove an externally initiated command
at the addressed NE. The No Request code is used for the NE-to-NE
communication of the clear command. Also, the clear command clears the
WTR state at the addressed NE.
Page 614
R6-64 [65] A clear command to clear an externally initiated command shall be
received by the same NE that initiated the original request from an
operations channel (i.e., the clear command can be received over the DCC
from another node but cannot be received over the K1 and K2 bytes).
Page 614
R6-65 [66] The following requests shall be supported using the K1 and K2 bytes
according to Table 10-1 in Section 6.2.2:
Lockout of protection - span and signal failure of protection - span
Forced switch - span
Forced switch - ring
Signal fail - span
Signal fail - ring
Signal degrade - protection
Signal degrade - span
Signal degrade - ring
Manual switch - span
Manual switch - ring
Wait to restore
Exerciser - span
Exerciser - ring
SONET BLSR Equipment Generic Criteria GR1230CORE
Requirement-Object List Issue 4, December 1998

ROL-10
Reverse request - span
Reverse request - ring
No request.
Page 615
R6-66 [67] All BLSR protection switching shall be performed bidirectionally.
Page 616
R6-67 [68] All protection switching (ring and span) shall be revertive. This
requirement does not exclude the use of the infinite WTR time to provide
the non-revertive mode of operation.
Page 616
R6-68 [69] For 4-fiber BLSRs, a switch shall revert only from the protection
channels to the working channels, and never to the other protection
channels. For example, if protection is provided using a ring switch during
a cable cut, and the protection channels on the failed span are repaired
before the working channels, the traffic that is already protected shall not
revert unless the ring request is pre-empted or the working channels are
repaired.
Page 616
R6-69 [70] K1 bits 1-4 shall carry bridge request priorities according to the pre-
emption priority (in descending order) provided in Table 10-1.
Page 616
R6-70 [71] Reverse Request shall assume the same priority of the request to
which it is responding.
Page 617
R6-71 [72] K1 bits 5-8 shall carry the destination node ID for the bridge request
indicated in K1 bits 1-4.
Page 617
R6-72 [73] The destination node ID used in a bridge request by a switching node
shall always be that of an adjacent node.
Page 617
ROL-11
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Requirement-Object List

R6-73 [74] There shall be no high priority assignment of a span (i.e., there shall
be no higher priority spans that would allow ring switches for that span to
override automatically other span switches of the same type [e.g., SF, SD,
or FS]).
Page 618
R6-74 [75] The bits in the K2 byte shall be assigned as Table 10-2 shows.
Page 618
R6-75 [76] The transmission of either Idle, Bridged, or Bridged and Switched in
byte K2 bits 6-8 shall indicate that extra traffic has been squelched.
Page 618
Table 10-1. K1 Bit Assignments
Bits 1-4 Request Pre-emption Priority
Bits Priority
1111 Lockout of Protection (span) [LP-S] or
Signal Fail (protection) [SF-P]
1110 Forced Switch (span) [FS-S]
1101 Forced Switch (ring) [FS-R]
1100 Signal Fail (span) [SF-S]
1011 Signal Fail (ring) [SF-R]
1010 Signal Degrade (protection) [SD-P]
1001 Signal Degrade (span) [SD-S]
1000 Signal Degrade (ring) [SD-R]
0111 Manual Switch (span) [MS-S]
0110 Manual Switch (ring) [MS-R]
0101 Wait To Restore [WTR]
0100 Exerciser (span) [EXER-S]
0011 Exerciser (ring) [EXER-R]
0010 Reverse Request (span) [RR-S]
0001 Reverse Request (ring) [RR-R]
0000 No Request [NR]
Bits 5-8 Destination Node ID - These bits shall indicate the
node ID of the node to which the K1 byte is destined
The Destination Node ID is always that of an
adjacent node (except for default APS bytes).
SONET BLSR Equipment Generic Criteria GR1230CORE
Requirement-Object List Issue 4, December 1998

ROL-12
R6-76 [77] Extra traffic carried on the protection channels shall have the lowest
priority level.
Page 618
R6-77 [78] If a node detects an APS controller failure while performing
diagnostics or during an exercise, and there is no transmission failure for
that line, no bridge request shall be initiated.
Page 618
R6-78 [79] Rule G #1.a (Bridge request): The information contained in byte K1
bits 1-4 shall be considered as a Bridge Request if
These bits indicate one of the ring bridge request codes and byte K2
bit 5 indicates either a long or short path code,
These bits indicate one of the span bridge request codes and byte K2
bit 5 indicates a short path code.
Page 619
R6-79 [80] Rule G #1.b (Bridge request status): The information contained in
byte K1 bits 1-4 shall be considered as a Bridge Request Status if these bits
indicate one of the span bridge request codes and byte K2 bit 5 indicates a
long path code.
Page 619
Table 10-2. K2 Bit Assignments
Bits 1-4 These bits shall always indicate the node ID of the node sourcing
the request.
Bit 5 This bit shall indicate if the bridge request in byte K1 bits 1-4 is
a short path request (0) or a long path request (1).
Bits 6-8 111 = Line AIS
110 = Line RDI
101 = Reserved for future use
100 = Reserved for future use
011 = Extra Traffic (ET) on Protection Channels
010 = Bridged and Switched (Br & Sw)
001 = Bridged (Br)
000 = Idle
ROL-13
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Requirement-Object List

R6-80 [271] Rule G #1.c: When a four-fiber ring node is in a SF-R or SD-R
condition, and the SF-R or SD-R request cannot be signaled because it is
not allowed to co-exist with other higher priority APS requests at that
node, the node shall consider the detected or received protection line
condition as a second input to the APS controller.
Page 619
R6-81 [81] A node is in the idle state when it is not sourcing or receiving any
APS requests or bridge request status and it is receiving Idle or ET code
from both directions.
Page 620
R6-82 [82] Rule I #1.a: Any node in the idle state not inserting, dropping, or
passing through extra traffic shall source the K-bytes in both directions as
given in Table 6-4.
Page 620
R6-83 [83] Rule I #1.b: Any node in the idle state inserting, dropping, or passing
through extra traffic shall source the K-bytes shown in Table 6-4 with the
exception that byte K2 bits 6-8 transmitted over any span that contains
extra traffic shall have the value 011 (Extra Traffic code).
Page 620
R6-84 [84] Until the node has knowledge of the ring map, squelch table, and
node ID, it shall behave in accordance with R6-130 (Rule I-S #3). Table 6-
5 shows the default APS code.
Page 620
R6-85 [85] Rule I #2 Idle state received K-bytes: Any node in the idle state
shall terminate K1 and K2 bytes in both directions.
Page 620
R6-86 [86] A node not in the idle or pass-through state is in the switching state.
Page 621
R6-87 [87] Rule S #1.a: Any node in the switching state shall source K-bytes as
shown in Table 6-6.
Page 621
SONET BLSR Equipment Generic Criteria GR1230CORE
Requirement-Object List Issue 4, December 1998

ROL-14
R6-88 [88] Rule S #1.b: Any node in the switching state (for either span or ring
requests) shall source a bridge request on the short path and a bridge
request (or bridge request status) on the long path. Both the bridge request
and the bridge request status have the same priority (or one of them is a
Reverse Request), and protect the same span. Exceptions to this can occur
when there are more than one switch requests active at a node. These
exceptions are listed below.
The isolated node cases are described in R6-89 (Rule S #1.c) and R6-
90 (Rule S #1.d).
In the case of a span bridge request on each side of the node, the node
shall source a bridge request on each short path, where the status bits
indicate the state of the bridge and switch for the corresponding span.
The case of a ring bridge request preempting a span bridge request on
an adjacent span is described in R6-142 (Rule S-S #2.b).
Cases where SF-P or SD-P coexists with a ring switch on the same
span. Table 6-7 defines the signaling for these cases.
Page 621
R6-89 [89] Rule S #1.c: Whenever a node in the ring switching state terminates
a new short path bridge request from an adjacent node, of equal or higher
priority than the request it is currently executing, over the same span, it
shall source a bridge request of the same priority on the corresponding long
path. Whenever a node receives ring bridge requests on both short paths
from its adjacent nodes, the long path bridge request shall be signaled
rather than the short path Reverse Requests. This rule takes precedence
over R6-88 (Rule S #1.b) in case of multiple bridge requests at the same
node. (See Figure 6-1, case a.)
Page 621
R6-90 [90] Rule S #1.d: Whenever a node detects one or more of the following:
a) an incoming condition requiring a ring switch, or b) an externally
initiated command for a ring switch applied at that node, it shall always
source over the short path a short path ring bridge request as long as the
ring bridge request is not preempted by a higher priority bridge request.
(See Figure 6-1, case b.) This rule takes precedence over R6-89 (Rule S
#1.c). Note that, whenever a node receives in one direction a short path
ring bridge request on one side, and detects one of the above-mentioned
conditions on the other side, it shall signal the bridge request associated
with that condition. (See Figure 6-1, case c.)
Page 622
ROL-15
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Requirement-Object List

R6-91 [91] Rule S #1.e: A node in the switching state shall insert the ET code in
byte K2 bits 68 on spans that are carrying Extra Traffic.
Page 622
R6-92 [92] Rule S #2 Switching state received K-bytes: Any node in the
switching state shall terminate K1 and K2 bytes in both directions.
Page 622
R6-93 [93] Rule S #3 Unidirectional bridge request acknowledgment: As soon
as it receives a bridge request, the node to which it is addressed shall
acknowledge the bridge request by changing byte K1 bits 14 to the
Reverse Request code on the short path, and to the received bridge request
priority on the long path.
Page 622
R6-94 [94] The switching node shall identify the nodes that are missing by
comparing the crossing K byte addresses with the information contained in
the ring map. Using the information on missing nodes and the squelch
table:
If the ring switching node determines that the last termination node is
missing for an STS channel, it shall squelch that channel by inserting
path AIS in the corresponding outgoing protection channel when
performing the ring bridge.
If the ring switching node determines that the first source node is
missing for an STS channel, it shall squelch that channel by inserting
path AIS in the corresponding incoming protection channel when
performing the ring switch.
Page 623
CR6-95 [95] If VT access is supported, VT squelching shall be performed by the
node dropping the VT as follows: the node shall identify the nodes that are
missing as described in R6-94. Using the information on missing nodes
and the squelch table, it shall identify only those VTs that are both dropped
at the node itself and sourced at the missing node(s). The node shall
squelch the identified VTs by inserting the appropriate path AIS in the
drop direction when all the source nodes are determined to be missing.
Page 623
CR6-96 [96] In addition to R6-94, the VT access switching node shall squelch
according to R6-94, before receiving the bridged and switched indications
SONET BLSR Equipment Generic Criteria GR1230CORE
Requirement-Object List Issue 4, December 1998

ROL-16
in byte K2 bits 6-8, all VT-accessed STSs that are added or dropped at the
missing nodes.
Page 623
CR6-97 [97] The switching node, upon receiving the bridged and switched
indications in byte K2 bits 6-8 from the far-end switching node, may be
required to unsquelch all VT-accessed STSs.
Page 623
R6-98 [98] The switching node shall stop squelching STSs when there are no
nodes missing. The STS AIS may still be inserted for other purposes.
Page 623
R6-99 [99] The switching node shall stop squelching when the bridge is dropped
and the switch is released at the node.
Page 623
R6-100 [100] An isolated node shall not bridge, switch, or squelch.
Page 623
R6-101 [101] Rule S #4.a The following switches are allowed to co-exist:
SD-P with any span switch
LP-S or SF-P with any span switch for other spans
SF-P or SD-P with any ring switch for the same span
LP-S with SD-P
LP-S with LP-S
SD-P with SD-P
FS-R with FS-R (ring split into multiple sub-rings)
SF-R with SF-R (ring split into multiple sub-rings)
FS-R with SF-R (ring split into multiple sub-rings)
Any span switch with any other span switch on other spans.
Page 625
R6-102 [102] Rule S #4.b: When multiple equal priority bridge requests over
different spans of SD-R, MS-R, or EXER-R exist at the same time, no
bridge or switch shall be executed and existing switches and bridges shall
ROL-17
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Requirement-Object List

be dropped. The nodes shall signal the switch priority in byte K1, and byte
K2 bits 68 shall be set to Idle.
Page 625
R6-103 [103] Rule S #5 Loss of Ring Bridge Request: If a node executing a ring
bridge and switch no longer receives a valid ring bridge request on the long
path, it shall drop its ring bridge and switch, and shall signal and act based
on its highest priority input.
Page 625
R6-104 [104] Rule S #6 Loss of Span Bridge Request: If a node executing a span
bridge and switch no longer receives a valid span bridge request (on the
short path), it shall drop its span bridge and switch, and shall signal and act
based on its highest priority input.
Page 625
R6-105 [105] Rule S #7 Extra Traffic: A node in the switching state shall not
pass through extra traffic, unless it is in the switching state due to a LP-S
(signal fail-protection), or a SD-P request. A node in the switching state
due to a WTR for a span switch, or any span request, except LP-S, SD-P,
or EXER-S, shall not source or terminate extra traffic on the short path of
that bridge request. A node in the switching state due to WTR for a ring
switch, or any ring request, except EXER-R, shall not source or terminate
extra traffic.
Page 625
R6-106 [272] Rule S #8: Whenever a node in the WTR state drops its bridge and
switch before the WTR timer expires, it shall immediately terminate the
WTR and act based on its highest priority input.
Page 626
R6-107 [273] Rule S #9: A node in a ring switching state that receives the external
command LOW-R for the affected span shall drop its bridge and switch
and shall signal No Request, SF-P, or SD-P. Upon the reception of (1) No
Request in combination with either IDLE or ET code, or (2) bridge request
status from the span away from the LOW-R span, the node shall re-insert
extra traffic that was preempted on that span.
Page 626
R6-108 [106] When span switches are active, extra traffic shall not be dropped on
spans that are not using its protection channel.
SONET BLSR Equipment Generic Criteria GR1230CORE
Requirement-Object List Issue 4, December 1998

ROL-18
Page 626
R6-109 [107] A node is in the pass through state when its highest priority APS
request is a bridge request or bridge request status not destined to or
sourced by itself.
Page 626
R6-110 [108] When a node is in a full pass-through state, the K1 and K2 bytes and
the protection channels shall be passed through. Full pass-through may be
either unidirectional or bidirectional.
Page 626
R6-111 [109] A node in unidirectional full pass-through shall continue sourcing
the previously sourced K-bytes in the opposite direction, with the
exception that byte K2 bits 6-8 shall reflect the appropriate status code.
Page 626
R6-112 [110] When a node is in a K byte pass-through state, the K1 and K2 bytes
shall be passed through bidirectionally, with the exception that byte K2
bits 6-8 shall reflect the appropriate status code. A K byte pass-through
node that receives the Extra Traffic code shall source the Idle code in the
opposite direction if no extra traffic exists on the opposite span.
Page 626
R6-113 [111] Rule P #2 Remaining in the pass-through state during signaling
transitions: When a node that is in a pass-through state receives a long path
ring bridge request destined to itself and another long path ring bridge
request of the same priority destined to another node, the node shall not
transit to another state. (This rule is necessary for the clearing sequence of
the node failure condition. See Figure 6-10.)
Page 626
R6-114 [112] Rule P #3 Extra Traffic: A node in full pass-through shall not
source or terminate extra traffic. A node that is in the K-byte pass-through
state can source, terminate, and pass-through extra traffic.
Page 627
R6-115 [113] Rule Basic #1 State transition triggers: All state transitions are
triggered by an incoming K-byte change, an externally initiated command,
WTR expiration, or locally detected line or equipment performance
ROL-19
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Requirement-Object List

criteria. A node shall not change the current state based on a received
default code.
Page 627
R6-116 [114] A node shall not change the current state unless a trigger is received
from the APS controller.
Page 627
R6-117 [115] Rule Basic #2 K-byte validation: Before accepting the K-bytes as
valid, the value shall be received identically in three successive frames.
Page 627
R6-118 [116] Rule Basic #3 K2 bits 6-8 update: All bridge and switch actions
shall be reflected by updating K2 bits 68, unless a RDI-L or AIS-L
condition exists, or the span is carrying extra traffic. A RDI-L condition
shall cause the RDI-L code to override all other codes in byte K2 bits 6-8
on the failed span, except for AIS-L, regardless of the state of the Bridge
and Switch. AIS-L overrides RDI-L and all other codes. RDI-L and AIS-
L terminate at LTEs as specified in GR253CORE. A node shall signal
the ET code on any span that is carrying extra traffic.
Page 627
R6-119 [117] Rule Basic #4: APS requests shall preempt APS requests in
accordance with 101, unless the APS requests are allowed to
coexist. Actions resulting from incoming bridge requests shall take priority
over actions resulting from incoming bridge request status signaling
regardless of the priority of each. Bridge request status signaling shall
never preempt a bridge request.
Page 627
R6-120 [118] A node that preempts extra traffic shall squelch the extra traffic
channels that are preempted in the following manner:
For a node executing a span switch that preempts extra traffic on that
span, extra traffic is squelched by
Inserting AIS on extra traffic channels from that span that are
dropped at that node (i.e., on the low-speed side)
Inserting AIS on extra traffic channels from that span that pass-
through the node (i.e., on the high-speed side), as long as those
protection channels are not required for a protection switch
SONET BLSR Equipment Generic Criteria GR1230CORE
Requirement-Object List Issue 4, December 1998

ROL-20
For a node executing a ring switch, extra traffic is squelched by
inserting AIS on extra traffic channels that are dropped at that node
(i.e., on the low-speed side)
For a node entering full pass-through, extra traffic is squelched by
inserting AIS on extra traffic channels that are dropped at that node
(i.e., on the low-speed side).
Page 628
R6-121 [119] Rule I-P #1.a: The transition from the idle state to the pass-through
state shall be triggered by a valid K-byte change, in any direction, from the
No Request code to any other bridge request code, as long as the new
bridge request is not destined for the node itself. Both directions then move
into pass-through according to R6-122 (Rule I-P #1.b).
Page 628
R6-122 [120] Rule I-P #1.b: For any span bridge request status, or the EXER-R
bridge request, the intermediate nodes on the long path shall go into K-byte
pass-through. Actions taken at an intermediate node upon receiving a valid
ring bridge request other than EXER-R are:
For NEs without VT access and without extra traffic, when the node in
the idle state receives a valid ring bridge request in any direction that
is not destined for the node itself, the node shall enter the bidirectional
full pass-through state.
For NEs without VT access and with extra traffic, when the node in the
idle state receives a valid ring bridge request in any direction that is not
destined for the node itself, the node shall drop extra traffic
bidirectionally, and shall enter unidirectional full pass-through, in the
direction of the bridge request only. Upon receiving the crossing K-
bytes, the node shall enter bidirectional full pass-through.
For NEs with VT access and without extra traffic, when the node in the
idle state receives a valid ring bridge request in any direction that is not
destined for the node itself, the node shall enter unidirectional full
pass-through in the direction of the request. Upon receiving the
crossing K-bytes, the node shall determine whether any of the VTs that
it drops requires squelching, and shall squelch accordingly, and then
enter bidirectional full pass-through.
For NEs with VT access and with extra traffic, when the node in the
idle state receives a valid ring bridge request in any direction that is not
destined for the node itself, the node shall drop extra traffic
bidirectionally, and shall enter unidirectional full pass-through in the
ROL-21
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Requirement-Object List

direction of the bridge request. Upon receiving the crossing K-bytes,
the node shall determine whether any of the VTs that it drops requires
squelching and shall squelch accordingly, and then enter bidirectional
full pass-through.
Page 628
R6-123 [121] Rule I-P #2 Transition from the pass-through state to the idle
state: A node shall revert from any pass-through state to the idle state when
it detects No Request codes in byte K1 bits 14 and Idle or ET codes in
byte K2 bits 68, from both directions. Both directions revert
simultaneously. Extra traffic that was preempted shall be re-inserted and
the ET code sourced as defined in R6-83 (Rule I #1.b). A VT access node
shall unsquelch any VTs that it drops that had previously been squelched.
Page 629
R6-124 [122] Rule I-S #1.a: Transition of a NE from the idle state to the switching
state shall be triggered by one of the following conditions:
A valid K-byte change from the No Request (NR) code to any ring
bridge request code received on either the long path or the short path
and destined to that NE
A valid K-byte change from the NR code to any span bridge request
code received on the short path and destined to that NE
An externally initiated command for that NE
The detection of a failure at that NE.
Page 629
R6-125 [123] Rule I-S #1.b: Actions taken at a switching NE upon receiving a
valid bridge request are (Note that in order to execute a ring bridge and
switch, the bridge request shall be received on the long path. See R6-126
[Rule I-S #1.c].):
For FS-R bridge requests, the node shall check if there is any need for
squelching and squelch accordingly, execute a bridge and insert the
Bridged indication code in byte K2 bits 68 in both directions (with
RDI-L and AIS-L exceptions). Upon receiving a Bridged indication in
byte K2 bits 68 on the bridge request path, the NE shall unsquelch
any VT-accessed STSs that had been squelched, execute a switch and
update byte K2 bits 68 on both paths accordingly.
For SF-R bridge requests, the node shall check if there is any need for
squelching and squelch accordingly, execute a bridge and switch, and
SONET BLSR Equipment Generic Criteria GR1230CORE
Requirement-Object List Issue 4, December 1998

ROL-22
insert in byte K2 bits 68 the Bridged and Switched indication on both
the long and the short path (with RDI-L and AIS-L exceptions). Upon
receiving the Bridged (and Switched) indication in byte K2 bits 68 on
the bridge request path, the NE shall unsquelch any VT-accessed STSs
that had been squelched.
For all other bridge requests, except EXER-S, EXER-R, SD-P, and
LP-S, the node shall execute a bridge and insert the Bridged indication
in byte K2 bits 68 in both directions (with RDI-L and AIS-L
exceptions). Upon receiving a Bridged indication in byte K2 bits 68
on the bridge request path, the NE shall execute a switch and update
byte K2 bits 68, on both paths, accordingly.
For EXER-S, EXER-R, SD-P and LP-S, the node shall signal as for
any other bridge request, but shall not execute the bridge or switch.
Extra traffic shall be dropped immediately on all spans for a ring
switch, or on the span whose protection channels are required for a
span switch.
No bridge or switch shall be executed while the ET code is received on
the span whose protection channels are required by that bridge and
switch.
Page 630
R6-126 [124] Rule I-S #1.c: A span switch shall be put up or brought down only
with short path bridge requests. A ring switch shall be put up or brought
down only with long path bridge requests.
Page 631
R6-127 [125] When a node reverts from the switching state to the idle state, both
directions shall revert simultaneously.
Page 631
R6-128 [126] Rule I-S #2 Transition from the switching state to the idle state: A
node shall revert from the switching state to the idle state when it detects
NR codes in byte K1 bits 14 and Idle or ET codes in byte K2 bits 68 from
both directions. Except for requests of EXER-S, EXER-R, SD-P, or LP-S,
the transition from the switching state to the idle state shall be a three-step
transition.
1. When a WTR time expires or an externally initiated command is
cleared at a node, and the nodes highest priority input is a Reverse
Request, the node shall drop its switch and signal NR in K1 bits 14
and the Bridged code in K2 bits 68. (Note that this step may be
ROL-23
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Requirement-Object List

executed in transitions from the switching state to the pass-through
state.)
2. Upon reception of the No Request code, and of the indication that the
switch has been dropped, the head-end node shall drop its bridge and
its switch, and source the Idle code in both directions, as indicated in
Table 6-4. The indication that the switch has been dropped is received
on the short path for span bridge requests, and on the long path for ring
bridge requests.
3. Once the tail-end detects incoming Idle codes, it shall also drop its
bridge and source the Idle code in both directions. Extra traffic that
was preempted shall be re-inserted and the ET code sourced as defined
in R6-83 (Rule I #1.b). A LP-S code due to a signal fail-protection, that
was preempted, shall be reinserted. A VT-access node shall unsquelch
any VTs that it drops that had previously been squelched.
4. Once the head-end detects incoming Idle or ET codes from both
directions, it shall revert to idle state. Extra traffic that was preempted
shall be re-inserted and the ET code sourced as defined in R6-83 (Rule
I #1.b). A LP-S code due to a signal fail-protection, that was
preempted, shall be reinserted. A VT-access node shall unsquelch any
VTs that it drops that had previously been squelched.
Page 631
R6-129 [127] For transitions from the switching states of EXER-S, EXER-R, SD-
P, or LP-S to the idle state, the NE that initiated the request (i.e., the tail-
end) shall signal the No Request (Idle) code. Upon reception of the NR
code, the head-end shall also source the NR (Idle) code.
Page 632
R6-130 [128] Rule I-S #3: A node shall transmit the default APS code as Table 6-
5 defines until it is capable of proper APS signaling in accordance with the
current state of the ring. The default APS code shall be used to indicate that
the node can not properly signal APS bytes, and therefore cannot properly
execute protection switching.
Page 632
R6-131 [129] Rule I-S #4: A ring (span) switching node receiving the default APS
code or invalid K-bytes on the short (long) path shall not change its
signaling or take any action associated with that path until proper APS
codes are received.
SONET BLSR Equipment Generic Criteria GR1230CORE
Requirement-Object List Issue 4, December 1998

ROL-24
A ring (span) switching node receiving default APS code or invalid K-
bytes on the long (short) path shall drop its bridge and switch.
Page 632
R6-132 [130] Rule I-S #5: A switching node that is not bridged or switched that
receives long path ring bridge requests destined to itself from both its
neighbors shall take no action based on these requests.
Page 632
R6-133 [131] Rule I-S #6: If a switching node receives the APS bytes that it is
sourcing in both directions, and receives no other APS request, it shall
transition to the idle state. Otherwise, the switching node shall signal
according to its highest priority input.
Page 632
R6-134 [132] Rule I-S #7: When a node receives a Reverse Request code over the
span that it is protecting, and when that same node is sending a Reverse
Request indication, it shall drop its bridge and switch as described in R6-
128 (Rule I-S #2), except for bridge request status or bridge requests of a
signal fail and signal degrade priority. For signal fail and signal degrade,
the node shall drop the switch and bridge after the expiration of the WTR
time according to R6-149 (Rule S-S #3a). (See also Figures 6-6 and 6-7.)
Page 632
R6-135 [133] Rule S-S #1.a: When a NE that is currently executing a SF-R switch
receives another SF-R or FS-R bridge request over the long path, not
destined to that NE, the NE shall check if there is any need for squelching
and squelch accordingly. NEs with VT access shall determine whether any
of the VTs that it drops requires squelching, and shall squelch accordingly.
The NE shall unsquelch any VT-accessed STSs that had been squelched if
the Bridged and Switched indication in byte K2 bits 68 on the long bridge
request path is still being received after 100 ms. The NE shall stop
squelching when the bridge and switch are dropped.
Page 632
R6-136 [134] Rule S-S #1.b: When a NE that is currently executing a FS-R switch
receives another FS-R or SF-R bridge request over the long path, not
destined to that NE, the NE shall check if there is any need for squelching
and squelch accordingly. NEs with VT access shall determine whether any
of the VTs that it drops requires squelching, and shall squelch accordingly.
The NE shall unsquelch any VT-accessed STSs that had been squelched if
ROL-25
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Requirement-Object List

the Bridged and Switched indication in byte K2 bits 68 on the long bridge
request path is still being received after 100 ms. The NE shall stop
squelching when the bridge and switch are dropped.
Page 633
R6-137 [135] Rule S-S #1.c: When a NE that is currently executing any ring
switch receives a higher priority ring APS request destined to it for the
same span, it shall upgrade the priority of the ring switch it is executing to
the priority of the received ring APS request.
Page 633
R6-138 [136] Rule S-S #1.d: When a NE that is currently executing any span
switch receives a higher priority span APS request destined to it for the
same span, it shall upgrade the priority of the span switch it is executing to
the priority of the received span APS request.
Page 633
R6-139 [137] Rule S-S #1.e: When a NE that is currently executing an EXER-R
request receives a higher priority ring APS request for the same span, it
shall remove any extra traffic. The node shall then execute the new ring
APS request as detailed in R6-124 to R6-126 (Rule I-S #1).
Page 633
R6-140 [138] Rule S-S #1.f: When a NE that is currently executing an EXER-S
request receives a higher priority span APS request for the same span, with
the exception of LP-S and SD-P, it shall remove any extra traffic from the
short path. It shall then signal the new span bridge request with the Idle
code in K2 bits 68 on the short path, and the new span bridge request
status on the long path. If there is extra traffic on the long path the ET code
shall be signaled in K2 bits 68. The node shall then execute the new span
APS request as detailed in R6-124 to R6-126 (Rule I-S #1).
Page 633
R6-141 [139] Rule S-S #2.a: When a NE that is currently executing a span switch
receives a ring APS request destined to it of higher priority for the same
span, it shall drop the span bridge and switch immediately, and execute the
ring APS request (as detailed in R6-124 to R6-126 [Rule I-S #1]).
Page 634
R6-142 [140] Rule S-S #2.b: When a node that is currently executing a span
switch receives a ring APS request destined to it for its adjacent span of
SONET BLSR Equipment Generic Criteria GR1230CORE
Requirement-Object List Issue 4, December 1998

ROL-26
higher priority than the span switch it is executing, it shall drop the span
switch, signal No Request in K1 and Bridged in K2 in the direction of the
span APS request, and signal the ring request in K1 and Idle in K2 in the
direction of the ring APS request.
Page 634
R6-143 [141] Rule S-S #2.c: When a node that is currently executing a span
switch receives a long path ring bridge request for a non-adjacent span of
higher priority than the span switch it is executing, it shall drop the span
switch and signal No Request in K1 and Bridged in K2 in both directions.
Page 634
R6-144 [142] Rule S-S #2.d: If a span switching node that is bridged and switched
receives a No Request and an indication that the switch has been dropped
for that span, the node shall drop its bridge and switch, and if the node's
highest priority input is
a. A span bridge request status destined to the node itself, or No
Request, then the node shall source No Request in K1 and Idle in
K2 in both directions.
b. A span APS request destined to it for an adjacent span, then the
node shall signal in accordance with that request.
c. A ring APS request destined to it for an adjacent span, then the
node shall execute the ring APS request.
d. A long path ring bridge request destined to another node, then the
node shall signal in accordance with either R6-155 (Rule S-P #1.a)
or R6-156 (Rule S-P #1.b), depending upon whether or not the
Bridged indication is being received.
e. A span bridge request status destined to another node, then the
node shall signal in accordance with either R6-157 (Rule S-P #1.c)
or R6-158 (Rule S-P #1.d), depending upon whether or not the
Bridged indication is being received.
f. A span APS request for the same span, the node shall signal the
span bridge request in K1 and Idle in K2.
Page 634
R6-145 [143] Rule S-S #2.e: If a span switching node that is bridged receives a No
Request and an indication that the switch has been dropped for that span,
the node shall drop its bridge, and if the node's highest priority input is
ROL-27
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Requirement-Object List

a. A span bridge request status destined to the node itself, or No
Request, then the node shall source No Request in K1 and Idle in
K2 in both directions.
b. A span APS request for an adjacent span, then the node shall
signal in accordance with that request.
c. A ring APS request destined to it for an adjacent span, then the
node shall execute that request.
d. A long path ring bridge request destined to another node, then the
node shall signal in accordance with either R6-155 (Rule S-P #1.a)
or R6-156 (Rule S-P #1.b), depending upon whether or not the
Bridged indication is being received.
e. A span bridge request status destined to another node, then the
node shall enter K-byte pass-through signal in accordance with
either R6-157 (Rule S-P #1.c) or R6-158 (Rule S-P #1.d),
depending upon whether or not the Bridged indication is being
received.
f. A span APS request for the same span, the node shall signal the
span bridge request in K1 and Idle in K2.
Page 635
R6-146 [144] Rule S-S #2.f: When a NE that is currently executing a ring switch
receives an APS request destined to it for an adjacent span of higher
priority than the ring switch it is executing, it shall
a. Drop the ring bridge and switch immediately
b. Execute the higher priority APS request (as detailed in R6-124 to
R6-126 [Rule I-S #1]).
Page 635
R6-147 [145] Rule S-S #2.g.1: When a NE that is currently executing a ring
switch receives a MS-S or FS-S command or bridge request destined to it
and that APS request is higher priority than the existing ring switch, it
shall:
a. Drop the ring bridge and switch immediately, and
b. Execute the span APS request.
Page 635
R6-148 [274] Rule S-S #2.h: For a four-fiber ring:
SONET BLSR Equipment Generic Criteria GR1230CORE
Requirement-Object List Issue 4, December 1998

ROL-28
If a ring switching node receives an APS request of higher priority than the
ring APS request it is executing, and the two requests are not allowed to
co-exist, the node shall drop the lower priority request and consider its
detected or received protection line condition in addition to the higher
priority request. If the detected or received request for the protection line
is allowed to co-exist with the higher priority APS request, and
if the higher priority APS request is for a span switch on the adjacent
span to the detected or received protection channel request, or
if the higher priority APS request is for a ring switch for the same span
as the detected or received protection channel request,
then it shall respond to both the protection channel request and the higher
priority APS request on the respective spans. If the higher priority request
is a span request, any Extra Traffic on the span adjacent to the request that
had been preempted shall be reinserted. This rule takes precedence over
R6-137 (Rule S-S #1.c) and R6-146 (Rule S-S #2.f).
Page 636
R6-149 [146] Rule S-S #3.a: When a locally detected failure condition clears at a
node, the node shall enter Wait-to-Restore and remain in Wait-to-Restore
for the appropriate time-out interval unless (1) a bridge request of higher
priority than WTR is received, (2) another failure is detected, or (3) an
externally initiated command becomes active. The node shall send out a
WTR code on both the long and short paths.
Page 636
R6-150 [147] Rule S-S #3.b: When a node that is executing a switch in response
to an incoming SD-S, SD-R, SF-S, or SF-R bridge request (not due to a
locally detected failure) receives a WTR code (unidirectional failure case),
it shall send out Reverse Request on the short path and the WTR on the
long path.
Page 636
R6-151 [148] Rule S-S #4 Span switch time-out: For a four-fiber ring, when it is
not possible to execute a SD-S or SF-S bridge request because no
acknowledgment is received on the short path (time-out), or because the
protection channels become unavailable (including degradation or failure
of the protection line or LOW-S), the appropriate ring switch shall be
attempted.
Page 637
ROL-29
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Requirement-Object List

R6-152 [149] The duration of the timeout for a span switch attempt shall be equal
to the switch completion time (i.e., 50 ms for clean rings and 100 ms for
rings with multiple failures).
Page 637
R6-153 [150] Rule S-S #5: A switching node that receives ring bridge requests
destined to itself from both its neighbors shall drop its bridge and release
its switch.
Page 637
R6-154 [151] Rule S-S #6: When a NE that is currently receiving a LP-S bridge
request or is sourcing a LP-S bridge request because of a signal fail-
protection receives an externally initiated ring bridge command or detects
a failure of the working line for the same span, it shall assume the priority
of the ring bridge request.
Page 637
R6-155 [152] Rule S-P #1.a: If a span switching node that is not bridged or
switched is receiving a Bridged code for that span, and its highest priority
input is a long path ring bridge request destined to another node, then the
node shall signal No Request in K1 and Idle in K2 in both directions.
Page 637
R6-156 [153] Rule S-P #1.b: If a span switching node that is not bridged or
switched receives an indication that the bridge has been dropped for that
span, and its highest priority input is a long path ring bridge request
destined to another node, then
For NEs without VT access and without extra traffic, the node shall
enter bidirectional full pass-through.
For NEs without VT access and with extra traffic, the node shall drop
extra traffic bidirectionally, and shall enter unidirectional full pass-
through, in the direction of the bridge request only. Upon receiving the
crossing K-bytes, the node shall enter bidirectional full pass-through.
For NEs with VT access and without extra traffic, the node shall enter
unidirectional full pass-through in the direction of the request. Upon
receiving the crossing K-bytes, the node shall determine whether any
of the VTs that it drops requires squelching, and shall squelch
accordingly, and then enter bidirectional full pass-through.
For NEs with VT access and with extra traffic, the node shall drop
extra traffic bidirectionally, and shall enter unidirectional full pass-
SONET BLSR Equipment Generic Criteria GR1230CORE
Requirement-Object List Issue 4, December 1998

ROL-30
through, in the direction of the bridge request. Upon receiving the
crossing K-bytes, the node shall determine whether any of the VTs that
it drops requires squelching, and shall squelch accordingly, and then
enter bidirectional full pass-through.
Page 637
R6-157 [154] Rule S-P #1.c: If a span switching node that is not bridged or
switched is receiving a Bridged code for that span and its highest priority
input is a span bridge request status destined to another node, then the node
shall signal No Request in K1 and Idle in K2 in both directions.
Page 638
R6-158 [155] Rule S-P #1.d: If a span switching node that is not bridged or
switched receives an indication that the bridge has been dropped for that
span, and its highest priority input is a span bridge request status destined
to another node, then the node shall enter K-byte pass-through. It shall then
reinsert any extra traffic that had been preempted.
Page 638
R6-159 [156] Rule S-P #1.e: When a node that is currently executing a ring switch
receives a long path ring bridge request for a non-adjacent span of higher
priority than the ring switch it is executing, it shall drop its bridge and
switch immediately and then
For NEs without VT access, the node shall enter bidirectional full
pass-through.
For NEs with VT access, the node shall enter unidirectional full pass-
through in the direction of the request. Upon receiving the crossing K-
bytes, the node shall determine whether any of the VTs that it drops
requires squelching, and shall squelch accordingly, and then enter
bidirectional full pass-through.
Page 638
R6-160 [157] Rule S-P #1.f: When a node that is currently executing a ring switch
has as its highest priority input long path ring bridge requests not destined
to itself from both directions, it shall drop its bridge and switch
immediately and then
For NEs without VT access, the node shall enter bidirectional full
pass-through.
For NEs with VT access, the node shall enter unidirectional full pass-
through in the direction of the first received request. Upon receiving
ROL-31
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Requirement-Object List

the crossing K-bytes, the node shall determine whether any of the VTs
that it drops requires squelching, and shall squelch accordingly, and
then enter bidirectional full pass-through.
Page 638
R6-161 [158] Rule S-P #1.g: If a ring switching node that is not bridged or
switched has as its highest priority input a span bridge request status
destined to another node, then the node shall enter K-byte pass-through. It
shall then reinsert any extra traffic that had been preempted.
Page 639
R6-162 [159] Rule S-P #2.a: The transition of a node from full pass-through to
switching shall be triggered by
a. An equal, higher priority, or allowed co-existing externally
initiated command,
b. The detection of an equal, higher priority, or allowed co-existing
failure,
c. The receipt of an equal, higher priority, or allowed coexisting
bridge request destined to that NE,
d. The detection of an APS byte sourced by that NE.
Page 639
R6-163 [160] Rule S-P #2.b: The transition of a node from K-byte pass-through
to switching shall be triggered by
a. Any externally initiated command,
b. The detection of any failure,
c. The receipt of any bridge request destined to that NE.
Page 639
R6-164 [161] Rule S-P #2.c: If a node that was in the full pass-through state is
now sourcing a span bridge request due to R6-162 (Rule S-P #2.a), the
node shall insert Path AIS on the protection channels on the span adjacent
to the affected span, until the node receives an indication that the ring
switch has been dropped.
Page 639
R6-165 [162] Rule S-P #3: If a node that was in the pass-through state due to a SF-
R or FS-R bridge request on the ring, and the node is now sourcing a SF-
SONET BLSR Equipment Generic Criteria GR1230CORE
Requirement-Object List Issue 4, December 1998

ROL-32
R or FS-R bridge request due to R6-162 (Rule S-P #2.a), the node shall
determine if there is any need for squelching and squelch accordingly, and
execute the ring bridge and switch. NEs with VT access shall determine
whether any of the VTs that it drops requires squelching, and shall squelch
accordingly. The NE shall unsquelch any VT-accessed STSs that had been
squelched if the Bridged and Switched indication in byte K2 bits 68 on
the long bridge request path is still being received after 100 ms.
Page 639
R6-166 [275] Rule S-P #4: If a pass-through node receives from at least one
direction the APS byte that has itself as the source ID, it shall source Idle
in both directions.
Page 640
R6-167 [163] If a span switch request is clearing and there is another span switch
request on the long path, the span switch that is being cleared shall be
dropped by using the clearing sequence Section 6.2.2.2.2B describes. The
No Request code is pre-empted by the other span switch request on the
long path.
Page 640
R6-168 [164] Rule P-P #1 Transition from K-byte pass-through to full pass-
through
For NEs without VT access and without extra traffic, when a node in
K-byte pass-through receives a long path ring bridge request other
than EXER-R not destined to itself, the node shall enter bidirectional
full pass-through.
For NEs without VT access and with extra traffic, the node shall drop
extra traffic bidirectionally, and shall enter unidirectional full pass-
through, in the direction of the bridge request only. Upon receiving the
crossing K-bytes, the node shall enter bidirectional full pass-through.
For NEs with VT access and without extra traffic, when a node in K-
byte pass-through receives a long path ring bridge request other than
EXER-R not destined to itself, the node shall enter unidirectional full
pass-through in the direction of the request. Upon receiving the
crossing K-bytes, the node shall determine whether any of the VTs that
it drops requires squelching, and shall squelch accordingly, and then
enter bidirectional full pass-through.
For NEs with VT access and with extra traffic, the node shall drop
extra traffic bidirectionally, and shall enter unidirectional full pass-
ROL-33
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Requirement-Object List

through, in the direction of the bridge request. Upon receiving the
crossing K-bytes, the node shall determine whether any of the VTs that
it drops requires squelching, and shall squelch accordingly, and then
enter bidirectional full pass-through.
Page 640
R6-169 [165] Rule P-P #2 Transition from full pass-through to K-byte pass-
through: A node in bidirectional full pass-through that receives a span
bridge request status not destined to itself from both directions shall enter
K-byte pass-through. A VT access node shall unsquelch any VTs that it
drops that had previously been squelched.
Page 641
R6-170 [166] Rule P-P #3 Transition from full pass-through to full pass-
through for VT access nodes: When a VT access node in full pass-through
receives a change in K-bytes indicating a long path ring bridge request
other than EXER-R not destined to itself, the node shall remain in full
pass-through and determine whether any of the VTs that it drops require
squelching, and shall squelch accordingly.
Page 641
R7-1 [167] The NE on the BLSR shall support the capability to interconnect
with another ring at two nodes, regardless of the type of the other ring
(path- or line-switched), on an STS basis. The interconnection is at the
electrical STS-M or OC-M level.
Page 71
O7-2 [168] It is an objective that DSn (e.g., DS3) interconnection shall be
allowed between two BLSRs.
Page 71
R7-3 [169] The primary and secondary nodes for ring interconnection shall be
selectable for each STS time slot.
Page 71
R7-4 [170] For each STS, intermediate nodes shall be permitted between the
primary and secondary nodes.
Page 71
SONET BLSR Equipment Generic Criteria GR1230CORE
Requirement-Object List Issue 4, December 1998

ROL-34
R7-5 [171] A NE service selector shall be provided for each STS time slot to
allow the NE to act as a primary node and to select either the traffic
received from the other network or the traffic received from the secondary
node, as Figure 7-1 shows.
Page 76
CR7-6 [276] The primary and secondary nodes may be required to be
provisionable, on a per inter-ring circuit basis, to provide in-service swap
of the primary and secondary node functions by default.
Page 76
CR7-7 [277] The length of the hit caused by in-service swap of primary and
secondary node functions shall not exceed 50 ms.
Page 76
R7-8 [172] The default path for the service selector shall be that selected from
the interconnecting line unless provisioned otherwise.
Page 76
CR7-9 [173] The NE shall be required to be provisionable, on a per-path basis,
to select the path from either the high-speed line or the interconnecting line
by default.
Page 76
R7-10 [174] Protection for ring interconnection failures (i.e., service selector
switching criteria) shall be based on detecting STS path signal defects.
Page 76
R7-11 [175] The set of manual commands for path protection switching that are
presented in GR1400CORE shall be used for manual control of the
BLSR service selector. This includes commands for both revertive and
non-revertive service selector operation.
Page 76
R7-12 [176] The service selector shall select the better of the two received STS
signals in accordance with hierarchy of failure conditions provided in
GR1400CORE for drop-nonterminated paths.
Page 76
ROL-35
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Requirement-Object List

R7-13 [177] The service selector shall meet the detection and clearing time
criteria in GR1400CORE for all the STS Path Signal Fail and STS Path
Signal Degrade conditions.
Page 76
R7-14 [178] The selection criteria at the service selector shall include PDI-P.
Page 77
R7-15 [179] For any failure detected at the service selector, a holdoff time of 100
ms shall apply.
Page 77
O7-16 [278] It is an objective that for any failure detected at the service selector,
a holdoff time of 50 ms shall apply.
Page 77
R7-17 [180] No service selector switch shall occur if the failure that triggers the
holdoff timer (e.g., STS Path AIS) is no longer present when the holdoff
timer expires.
Page 78
R7-18 [181] The service selector switch completion time shall be 50 ms.
Page 78
R7-19 [182] Service selector operation shall be revertive.
Page 78
CR7-20 [183] The NE shall be required to be provisionable to use non-revertive
switching at the service selector.
Page 78
R7-21 [184] When traffic is selected from a secondary node, all other nodes on
the ring shall be able to respond in the normal manner (i.e., the same as
when traffic is received from a primary node).
Page 79
R7-22 [185] The service selector protection switching shall not require inter-ring
signaling. Providing protection for the interconnecting line is not
considered inter-ring signaling.
SONET BLSR Equipment Generic Criteria GR1230CORE
Requirement-Object List Issue 4, December 1998

ROL-36
Page 79
R7-23 [186] The NE on the BLSR shall support the capability to operate
independently of an interconnected ring, regardless of the type of the
second ring, consistent with the K1 and K2 byte protocol given in Section
6.
Page 79
R7-24 [187] The NE on the BLSR shall support the capability to interconnect
with other networks, such as mesh networks, at two points on an electrical
STS-M/OC-M basis.
Page 79
CR7-25 [279] The secondary circuit may be required to be provisionable to be
carried on either the working bandwidth or the protection bandwidth.
Page 710
R7-26 [280] Secondary circuit on protection bandwidth shall be considered
extra traffic, and byte K2 bits 6-8 shall indicate the Extra Traffic code.
Page 710
CR7-27 [281] The secondary node may be required to provide add, drop, and
passing through of inter-ring traffic directly from the protection channels.
Page 710
R7-28 [282] The squelching trigger for inter-ring traffic shall use the secondary
node and the terminating (or source) node as the trigger.
Page 710
R7-29 [283] In the event of a primary node failure, the secondary node shall
select inter-ring traffic directly from and/or bridge traffic to the protection
bandwidth on the span away from the failed primary node.
Page 710
O7-30 [284] It is an objective that in the event of a failure between (but not
including) the primary and terminating (or source) node, the secondary
node shall select (using a service selector) the better of the two inter-ring
traffic from
1. The low-speed line, or
ROL-37
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Requirement-Object List

2. The protection bandwidth from the direction of the primary node.
In addition, the secondary node shall provide drop and continue function
for inter-ring traffic onto
1. The low-speed line, and
2. The protection channel in the direction of the primary node.
Page 710
CR7-31 [285] The secondary node may be required to maintain a RIP Table that
contains, for each incoming and outgoing inter-ring circuit carried on the
protection bandwidth, the terminating (or source) node address and the
primary node address.
Page 711
R7-32 [286] The service circuit shall be provisionable to be carried on the
working bandwidth by default, or carried on the protection bandwidth.
Page 711
CR7-33 [295] The BLSR may be required to support Dual Transmit method of
ring interworking.
Page 712
R7-34 [296] If the dual transmit method is supported, a NE service selector shall
be provided for each STS time slot to allow the NE to support terminating
node functionality in the dual transmit method and to select either the inter-
ring traffic received from the primary node or the secondary node.
Page 712
R8-1 [188] For transaction oriented applications via the OS/NE and NE/NE
interfaces, SONET NEs operating in a BLSR architecture shall support the
Section DCC and shall use the Common Management Information Service
Element (CMISE) Application Service Element (ASE) and shall adhere to
the service mappings and information models in GR836CORE, OTGR
Section 15.2: Generic Operations Interfaces Using OSI Tools
Information Model and Usage: Transport Configuration and Surveillance
for Network Elements, and GR1042CORE, Generic Requirements for
Operations Interfaces Using OSI Tools Information Model Overview:
Synchronous Optical Network (SONET) Transport Information Model.
The UPSR information model shall be used to support the service selector
function and can also be found in GR1042CORE.
SONET BLSR Equipment Generic Criteria GR1230CORE
Requirement-Object List Issue 4, December 1998

ROL-38
Page 81
R8-2 [189] A SONET NE operating in a 4-fiber BLSR shall support the
SONET Section DCC on the fiber pair carrying working channels, and
physically protect the Section DCC when span protection switching is
active.
Page 81
R8-3 [190] A SONET NE operating in a BLSR shall support selective routing
at the network layer for the Section DCC.
Page 81
R8-4 [191] A NE operating in a BLSR shall detect the occurrence of equipment
failures, incoming signal failures (except possibly linear APS troubles),
and incoming maintenance signals, and shall take the appropriate actions
as defined in GR253CORE. BLSR APS troubles are defined in Section
8.2.1.
Page 82
R8-5 [192] A NE operating in a BLSR that supports a service selector function
shall meet the criteria for path switching NEs as defined in
GR1400CORE. Furthermore, the service selector shall meet the criteria
for the path selector function as defined in GR1400CORE.
Page 82
R8-6 [193] Any NE-detectable failure that affects the ability of the BLSR NE
to write or detect and process the contents of the APS channel
appropriately shall be reported as an alarm.
Page 82
R8-7 [194] A NE that detects an incoming, low-speed signal failure (add/drop
port) that is carrying traffic intra-ring or a mixture of intra- and inter-ring
(or dual-homed) traffic shall report the failure, if appropriate, as a service-
affecting alarm.
Page 83
R8-8 [195] A NE shall detect the Default K Bytes defect according to the above
definition.
Page 84
ROL-39
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Requirement-Object List

R8-9 [196] A NE shall detect Inconsistent APS Code defect according to the
above definition.
Page 84
R8-10 [197] A NE shall detect Node ID Mismatch defect according to the above
definition.
Page 84
R8-11 [198] A NE shall detect Improper APS Codes defect according to the
above definition.
Page 84
R8-12 [199] The Default K Bytes defect shall not result in an Inconsistent APS
Code, Node ID Mismatch, or Improper APS Codes defect.
Page 84
R8-13 [200] A NE shall terminate the Default K Bytes defect when three
consecutive and identical frames are detected that do not contain default
code.
Page 84
R8-14 [201] A NE shall terminate the Inconsistent APS Codes defect when three
consecutive and identical frames are detected.
Page 84
R8-15 [202] A NE shall terminate the Node ID Mismatch defect when three
consecutive and identical frames contain a source ID that corresponds to
its neighbor according to the ring map.
Page 84
R8-16 [203] The transition from one improper APS code to another improper
APS code shall not cause the NE to terminate the Improper APS Codes
defect.
Page 84
R8-17 [204] A NE shall terminate the Improper APS Codes defect when three
consecutive and identical frames contain an appropriate message.
Page 84
SONET BLSR Equipment Generic Criteria GR1230CORE
Requirement-Object List Issue 4, December 1998

ROL-40
R8-18 [205] If the NE continues to detect an APS trouble defect (Default K
Bytes, Inconsistent APS Codes, Node ID Mismatch, or Improper APS
Codes) for 2.5 (0.5) seconds, the NE shall declare the appropriate BLSR
APS trouble failure.
Page 85
R8-19 [206] A NE in the idle or switching state shall send an autonomous
message to the OS upon declaring a Default K Bytes failure.
Page 85
R8-20 [207] A NE in the idle or switching state shall send an autonomous
message to the OS upon declaring an Inconsistent APS codes failure.
Page 85
R8-21 [208] A NE in the idle, switching, or pass-through state shall send an
autonomous message to the OS upon declaring a Node ID Mismatch
failure.
Page 85
R8-22 [209] A NE in the idle or switching state shall send an autonomous
message to the OS upon declaring an Improper APS codes failure.
Page 85
R8-23 [210] A NE in the pass-through state shall not send an autonomous
message to the OS upon declaring the Default K bytes failure.
Page 85
R8-24 [211] A NE in the pass-through state shall not send an autonomous
message to the OS upon declaring Inconsistent APS codes failure.
Page 85
R8-25 [212] A NE in the pass-through state shall not send an autonomous
message to the OS upon declaring Improper APS codes failure.
Page 85
R8-26 [213] The network provider shall be able to retrieve information about the
APS troubles entered by the NE.
Page 85
ROL-41
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Requirement-Object List

R8-27 [214] A BLSR APS failure is cleared when the relevant APS defect is
absent for a time T, where T is 10 (0.5) seconds. The NE shall clear the
alarm indication and, if appropriate, send a clear message to the OS.
Page 85
R8-28 [215] When the NE detects a loss of signal defect, loss of frame defect, or
Line AIS defect, the NE shall clear any APS trouble defect(s).
Page 85
R8-29 [216] A NE shall automatically report to an OS if it is squelching traffic,
including STS-level squelching of working traffic, extra traffic (STSs), or
individual VTs, persistently for a time T, where T is 2.5 (0.5) seconds. In
the case of a switching NE that is squelching working traffic at the STS
level, the message shall additionally identify the line in the direction
toward the failure for which working traffic is squelched. In the case of an
intermediate node that squelches extra traffic or individual VTs, the
automatic message shall identify the node.
Page 86
R8-30 [217] A NE shall be capable of responding to a query by an OS (or from
a WS) whether STS-level working traffic in the requested line is being
squelched.
Page 86
R8-31 [218] A NE that is squelching traffic shall identify those channels,
including working STS channels, extra traffic STS channels, or individual
VT channels that are squelched if queried by an OS or WS.
Page 86
R8-32 [219] The NE shall maintain protection switching counts for each
working line and its associated protection line. Separate counters are
required to differentiate between working and protection in a given line.
Page 87
R8-33 [220] In a 4-fiber ring, the NE shall maintain separate protection
switching counts for span and ring protection switches. See Figure 8-2.
Page 88
R8-34 [221] The NE operating in a BLSR shall make available upon request its
current K byte state idle, pass-through, or switching. The pass-through
SONET BLSR Equipment Generic Criteria GR1230CORE
Requirement-Object List Issue 4, December 1998

ROL-42
state shall be further qualified as unidirectional full, bidirectional full, or K
byte pass-through.
Page 89
O8-35 [222] It is an objective that the NE provide the ability to examine the
contents of the received APS channel (K1 and K2 bytes) for a series of
consecutive frames. When requested via a WS/NE or OS/NE interface, the
minimum display should accommodate APS bytes captured from 12
frames.
Page 89
CR8-36 [223] To support acceptance testing procedures or trouble-shooting
protection switching anomalies in the field, the ability to request that an
APS channel capture function triggers when a new protection switch
request is detected, and display up to 100 ms of the contents of the APS
channel may be useful in some applications.
Page 89
R8-37 [224] When reporting a completed, externally initiated protection switch
event, the NE in a 4-fiber BLSR shall include the type of the protection
switch (i.e., span or ring).
Page 89
R8-38 [225] The NE shall support externally initiated control of the protection
switching functions Section 6.2.1.1 describes via the WS/NE or OS/NE
interfaces.
Page 89
R8-39 [226] The NE shall deny any externally initiated APS command if an
equal or higher priority request exists on the ring that is not permitted to
coexist with the command (see R6-101).
Page 810
R8-40 [227] Externally initiated commands that are denied or preempted due to
a higher priority APS request at that node shall not go pending. This
includes manual switches that are preempted by higher priority switches
anywhere in the ring.
Page 810
ROL-43
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Requirement-Object List

R8-41 [228] The NE in a 2-fiber ring architecture shall deny any externally
initiated APS command unique to 4-fiber rings.
Page 810
R8-42 [229] The NE shall deny an externally initiated Exercise ring command if
an Exercise request for a different span is currently using protection.
Page 810
R8-43 [230] After receiving the expected response to an Exercise request or
detecting a higher priority request in the APS channel, the NE shall notify
the user of a successful completion and shall autonomously cease
transmitting the Exercise request code as if a clear command had been
received.
Page 810
R8-44 [231] If the NE detects an APS channel failure while running the
exerciser, the NE shall report the failure to the OS as well as provide the
requisite response to the exerciser instruction. The NE ceases to transmit
the exerciser request.
Page 810
R8-45 [232] The NE shall deny an externally initiated Manual Switch ring
command if a Manual Switch ring for another span exists.
Page 811
R8-46 [233] The NE shall implicitly clear an externally initiated protection
switch command when another, higher priority externally initiated
command for the same span is received without an intervening clear
command. For example, a user initiated Manual Switch span instruction
can be overridden with by a Forced Switch span instruction if it is for the
same span and initiated from the same NE.
Page 811
R8-47 [234] The NE shall treat the Lockout of Working Channels and Lockout
of Protection Channels as the highest priority in the externally initiated
command hierarchy; each command must be cleared separately.
Page 811
R8-48 [287] The ability to retrieve the STS channels used to carry inter-ring
traffic is required.
SONET BLSR Equipment Generic Criteria GR1230CORE
Requirement-Object List Issue 4, December 1998

ROL-44
Page 811
R8-49 [288] The ability to retrieve the primary and secondary node ID for each
inter-ring circuit via a WS/NE or OS/NE interface is required.
Page 811
CR8-50 [289] A NE shall be capable of responding to a query by an OS (or from
a WS) whether in-service swap feature is enabled.
Page 811
CR8-51 [290] The ability to retrieve the node IDs of the nodes that have
performed in-service swap is required.
Page 811
R8-52 [291] A NE shall be capable of responding to a query by an OS (or from
a WS) whether the secondary or service circuit is carried on the protection
channel.
Page 811
R8-53 [235] The NE identity (Node ID) relative to the ring must be
provisionable via the WS/NE or OS/NE interface. Permitted values are 0
to 15 inclusive.
Page 813
R8-54 [236] The NE shall deny any Node ID values outside the permitted range.
Page 813
R8-55 [237] A NE on a BLSR shall accommodate a ring map for a ring size of
16 nodes.
Page 813
R8-56 [238] The ring map data shall be provisionable via the WS/NE or OS/NE
interface.
Page 813
R8-57 [239] The NE shall deny duplicated values in the ring map.
Page 813
ROL-45
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Requirement-Object List

R8-58 [240] The contents of the squelch table shall be provisionable via the WS/
NE or OS/NE interface.
Page 813
R8-59 [241] For nodes that support VT access, the contents of the VT squelch
table shall be provisionable via the WS/NE or OS/NE interface.
Page 814
R8-60 [297] For nodes that support E-NUT, the content of the E-NUT table shall
be provisionable via the WS/NE or OS/NE interface.
Page 814
R8-61 [242] The Node ID, ring map, and squelch table data must reside in non-
volatile memory.
Page 814
R8-62 [243] For nodes that support VT access, the VT squelch table must reside
in non-volatile memory.
Page 814
R8-63 [298] For nodes that support E-NUT, the E-NUT table data must reside in
non-volatile memory.
Page 814
R8-64 [244] The ability to retrieve the Node ID, the current ring map, squelch
table (STS and VT) and E-NUT table data via a WS/NE or OS/NE
interface is required.
Page 814
R8-65 [245] A NE shall provide an appropriate designation to indicate that a
time slot is unassigned.
Page 814
O8-66 [246] It is an objective that a service (i.e., the cross-connect and squelch
table information) can be provisioned with a single command.
Page 814
R8-67 [247] For the BLSR to support inter-ring services or dual-homed services,
the signal selector association in a NE must be provisionable on a per STS
SONET BLSR Equipment Generic Criteria GR1230CORE
Requirement-Object List Issue 4, December 1998

ROL-46
path basis, and shall associate any low-speed working channel with any
high-speed working channel.
Page 814
R8-68 [248] The NE shall be provisionable to establish the necessary cross-
connections for an inter-ring or dual-homed service. The STS path selector
service must be associated with the same STS time slot in the incoming
OC-N from the secondary node as the received signal from the ring into
the primary node.
Page 815
CR8-69 [299] Secondary nodes that support ring interworking on protection, may
be required to maintain a RIP table that contains, for each incoming and
outgoing inter-ring circuit carried on the protection bandwidth, the
terminating (or source) node address and the primary node address.
Page 815
R8-70 [249] The NE shall provide sufficient memory to accommodate a
temporary ring map, temporary squelch table, and Node ID.
Page 815
R8-71 [250] NEs that support VT access shall provide sufficient memory to
accommodate a temporary VT squelch table.
Page 815
R8-72 [300] NEs that support E-NUT shall provide sufficient memory to
accommodate a temporary E-NUT table.
Page 815
R8-73 [251] This temporary storage shall reside in non-volatile memory.
Page 816
R8-74 [252] The NE must permit the user to change and to retrieve the contents
of the temporary storage.
Page 816
O8-75 [253] It is an objective that the NE could be scheduled to update the
working ring map, the squelch table, or both from the temporary memory.
Page 816
ROL-47
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Requirement-Object List

R8-76 [254] The NE shall permit the user to control the update of the active
memories from the temporary memories.
Page 816
R8-77 [255] The BLSR APS line-level BER threshold for SD shall be user
programmable in the range of 10
-5
to 10
-9
.
Page 816
CR8-78 [256] In some applications, the BLSR APS line-level BER threshold for
SF may be required to be user-selectable over the range 10
-3
to 10
-5
.
Page 816
R8-79 [257] For service selector applications, the STS path signal degrade BER
threshold level at the service selector shall be user programmable, on a
node-wide basis, in the range 10
-5
to 10
-9
, with a default value of 10
-6
.
Page 816
O8-80 [258] For service selector applications, it is an objective that the NE
provide the capability to allow the STS path signal degrade BER threshold
level to be provisioned on an individual STS path basis, rather than on a
node-wide basis.
Page 816
R8-81 [259] The SONET NE operating in a 2-fiber BLSR ring shall provide a
provisionable WTR value.
Page 816
R8-82 [260] The SONET NE operating in a 4-fiber BLSR ring shall provide two
separate WTR restore values. One shall be for ring protection on the high-
speed lines, and the other shall be for the span protection.
Page 816
R8-83 [261] The WTR value shall be user programmable in the range of 5 to 12
minutes in 1 minute increments. The default value is 5.
Page 816
O8-84 [292] It is an objective that the WTR value shall be accurate to within 30
seconds.
Page 816
SONET BLSR Equipment Generic Criteria GR1230CORE
Requirement-Object List Issue 4, December 1998

ROL-48
O8-85 [262] A wider range for WTR is desirable with a lower bound of zero
minutes. Finer granularity in the time intervals is not a violation of the
requirement.
Page 816
CR8-86 [263] For ring interconnection, if linear APS is provided on the
interconnecting line, the criteria for linear APS in Section 5.3 of
GR253CORE shall be applicable.
Page 817
CR8-87 [264] If linear APS is provided for an OC-M tributary, the NE shall
provide a separate provisionable WTR value.
Page 817
R8-88 [265] A value of 99 for either ring or span protection WTR times shall be
interpreted as specifying non-revertive action.
Page 817
R8-89 [266] Changes to the working database made via the WS/NE interface,
must be reported to the provisioning OS.
Page 817
R8-90 [267] The NE shall periodically (automatically) run a data integrity check
mechanism for the ring map and report any errors to the provisioning and
maintenance OSs.
Page 817
O8-91 [268] It is an objective that the NE require a higher authorization level for
the initiator of a forced switch command, especially if the forced switch
will segment the ring. This also applies to lockout command, especially if
services will be dropped.
Page 817
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Requirement-Object Index

ROI-1
[1] R6-1 Page 61
[2] R6-2 Page 61
[3] R6-3 Page 61
[4] R6-4 Page 61
[5] R6-5 Page 61
[6] R6-6 Page 61
[7] R6-7 Page 62
[8] R6-8 Page 62
[9] R6-9 Page 62
[10] R6-10 Page 62
[11] R6-11 Page 62
[12] R6-12 Page 62
[13] R6-13 Page 62
[14] R6-14 Page 62
[15] O6-15 Page 62
[16] R6-16 Page 62
[18] R6-17 Page 63
[19] R6-18 Page 63
[20] R6-19 Page 63
[21] R6-20 Page 63
[22] R6-21 Page 63
[23] R6-22 Page 63
[27] R6-23 Page 64
[28] R6-24 Page 64
[29] R6-25 Page 64
[30] R6-26 Page 64
[31] CR6-27 Page 64
[32] R6-28 Page 64
[33] CR6-29 Page 64
[34] R6-30 Page 64
[35] R6-31 Page 64
[36] R6-32 Page 64
[37] R6-33 Page 64
[38] R6-34 Page 65
[39] R6-35 Page 65
[40] R6-36 Page 65
[41] R6-37 Page 65
[42] R6-38 Page 65
[43] R6-39 Page 65
[44] R6-40 Page 65
[45] R6-41 Page 65
[46] R6-42 Page 65
[47] R6-43 Page 66
[48] O6-44 Page 66
[49] R6-45 Page 66
[50] R6-46 Page 66
[51] R6-47 Page 66
[52] R6-48 Page 66
[53] CR6-49 Page 66
[54] CR6-50 Page 66
[55] R6-51 Page 67
[56] R6-54 Page 67
[57] R6-55 Page 67
[58] R6-56 Page 67
[59] R6-57 Page 67
[60] R6-58 Page 67
[61] O6-59 Page 67
[62] R6-60 Page 67
[63] R6-61 Page 68
[64] R6-63 Page 614
[65] R6-64 Page 614
[66] R6-65 Page 615
[67] R6-66 Page 616
[68] R6-67 Page 616
[69] R6-68 Page 616
[70] R6-69 Page 616
[71] R6-70 Page 617
[72] R6-71 Page 617
[73] R6-72 Page 617
[74] R6-73 Page 618
[75] R6-74 Page 618
[76] R6-75 Page 618
[77] R6-76 Page 618
[78] R6-77 Page 618
[79] R6-78 Page 619
[80] R6-79 Page 619
[81] R6-81 Page 620
[82] R6-82 Page 620
Requirement-Object Index ROI
SONET BLSR Equipment Generic Criteria GR1230CORE
Requirement-Object Index Issue 4, December 1998

ROI-2
[83] R6-83 Page 620
[84] R6-84 Page 620
[85] R6-85 Page 620
[86] R6-86 Page 621
[87] R6-87 Page 621
[88] R6-88 Page 621
[89] R6-89 Page 621
[90] R6-90 Page 622
[91] R6-91 Page 622
[92] R6-92 Page 622
[93] R6-93 Page 622
[94] R6-94 Page 623
[95] CR6-95 Page 623
[96] CR6-96 Page 623
[97] CR6-97 Page 623
[98] R6-98 Page 623
[99] R6-99 Page 623
[100] R6-100 Page 623
[101] R6-101 Page 625
[102] R6-102 Page 625
[103] R6-103 Page 625
[104] R6-104 Page 625
[105] R6-105 Page 625
[106] R6-108 Page 626
[107] R6-109 Page 626
[108] R6-110 Page 626
[109] R6-111 Page 626
[110] R6-112 Page 626
[111] R6-113 Page 626
[112] R6-114 Page 627
[113] R6-115 Page 627
[114] R6-116 Page 627
[115] R6-117 Page 627
[116] R6-118 Page 627
[117] R6-119 Page 627
[118] R6-120 Page 628
[119] R6-121 Page 628
[120] R6-122 Page 628
[121] R6-123 Page 629
[122] R6-124 Page 629
[123] R6-125 Page 630
[124] R6-126 Page 631
[125] R6-127 Page 631
[126] R6-128 Page 631
[127] R6-129 Page 632
[128] R6-130 Page 632
[129] R6-131 Page 632
[130] R6-132 Page 632
[131] R6-133 Page 632
[132] R6-134 Page 632
[133] R6-135 Page 632
[134] R6-136 Page 633
[135] R6-137 Page 633
[136] R6-138 Page 633
[137] R6-139 Page 633
[138] R6-140 Page 633
[139] R6-141 Page 634
[140] R6-142 Page 634
[141] R6-143 Page 634
[142] R6-144 Page 634
[143] R6-145 Page 635
[144] R6-146 Page 635
[145] R6-147 Page 635
[146] R6-149 Page 636
[147] R6-150 Page 636
[148] R6-151 Page 637
[149] R6-152 Page 637
[150] R6-153 Page 637
[151] R6-154 Page 637
[152] R6-155 Page 637
[153] R6-156 Page 637
[154] R6-157 Page 638
[155] R6-158 Page 638
[156] R6-159 Page 638
[157] R6-160 Page 638
[158] R6-161 Page 639
[159] R6-162 Page 639
[160] R6-163 Page 639
[161] R6-164 Page 639
[162] R6-165 Page 639
[163] R6-167 Page 640
[164] R6-168 Page 640
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Requirement-Object Index

ROI-3
[165] R6-169 Page 641
[166] R6-170 Page 641
[167] R7-1 Page 71
[168] O7-2 Page 71
[169] R7-3 Page 71
[170] R7-4 Page 71
[171] R7-5 Page 76
[172] R7-8 Page 76
[173] CR7-9 Page 76
[174] R7-10 Page 76
[175] R7-11 Page 76
[176] R7-12 Page 76
[177] R7-13 Page 76
[178] R7-14 Page 77
[179] R7-15 Page 77
[180] R7-17 Page 78
[181] R7-18 Page 78
[182] R7-19 Page 78
[183] CR7-20 Page 78
[184] R7-21 Page 79
[185] R7-22 Page 79
[186] R7-23 Page 79
[187] R7-24 Page 79
[188] R8-1 Page 81
[189] R8-2 Page 81
[190] R8-3 Page 81
[191] R8-4 Page 82
[192] R8-5 Page 82
[193] R8-6 Page 82
[194] R8-7 Page 83
[195] R8-8 Page 84
[196] R8-9 Page 84
[197] R8-10 Page 84
[198] R8-11 Page 84
[199] R8-12 Page 84
[200] R8-13 Page 84
[201] R8-14 Page 84
[202] R8-15 Page 84
[203] R8-16 Page 84
[204] R8-17 Page 84
[205] R8-18 Page 85
[206] R8-19 Page 85
[207] R8-20 Page 85
[208] R8-21 Page 85
[209] R8-22 Page 85
[210] R8-23 Page 85
[211] R8-24 Page 85
[212] R8-25 Page 85
[213] R8-26 Page 85
[214] R8-27 Page 85
[215] R8-28 Page 85
[216] R8-29 Page 86
[217] R8-30 Page 86
[218] R8-31 Page 86
[219] R8-32 Page 87
[220] R8-33 Page 88
[221] R8-34 Page 89
[222] O8-35 Page 89
[223] CR8-36 Page 89
[224] R8-37 Page 89
[225] R8-38 Page 89
[226] R8-39 Page 810
[227] R8-40 Page 810
[228] R8-41 Page 810
[229] R8-42 Page 810
[230] R8-43 Page 810
[231] R8-44 Page 810
[232] R8-45 Page 811
[233] R8-46 Page 811
[234] R8-47 Page 811
[235] R8-53 Page 813
[236] R8-54 Page 813
[237] R8-55 Page 813
[238] R8-56 Page 813
[239] R8-57 Page 813
[240] R8-58 Page 813
[241] R8-59 Page 814
[242] R8-61 Page 814
[243] R8-62 Page 814
[244] R8-64 Page 814
[245] R8-65 Page 814
[246] O8-66 Page 814
SONET BLSR Equipment Generic Criteria GR1230CORE
Requirement-Object Index Issue 4, December 1998

ROI-4
[247] R8-67 Page 814
[248] R8-68 Page 815
[249] R8-70 Page 815
[250] R8-71 Page 815
[251] R8-73 Page 816
[252] R8-74 Page 816
[253] O8-75 Page 816
[254] R8-76 Page 816
[255] R8-77 Page 816
[256] CR8-78 Page 816
[257] R8-79 Page 816
[258] O8-80 Page 816
[259] R8-81 Page 816
[260] R8-82 Page 816
[261] R8-83 Page 816
[262] O8-85 Page 816
[263] CR8-86 Page 817
[264] CR8-87 Page 817
[265] R8-88 Page 817
[266] R8-89 Page 817
[267] R8-90 Page 817
[268] O8-91 Page 817
[270] R6-62 Page 614
[271] R6-80 Page 619
[272] R6-106 Page 626
[273] R6-107 Page 626
[274] R6-148 Page 636
[275] R6-166 Page 640
[276] CR7-6 Page 76
[277] CR7-7 Page 76
[278] O7-16 Page 77
[279] CR7-25 Page 710
[280] R7-26 Page 710
[281] CR7-27 Page 710
[282] R7-28 Page 710
[283] R7-29 Page 710
[284] O7-30 Page 710
[285] CR7-31 Page 711
[286] R7-32 Page 711
[287] R8-48 Page 811
[288] R8-49 Page 811
[289] CR8-50 Page 811
[290] CR8-51 Page 811
[291] R8-52 Page 811
[292] O8-84 Page 816
[293] CR6-52 Page 67
[294] R6-53 Page 67
[295] CR7-33 Page 712
[296] R7-34 Page 712
[297] R8-60 Page 814
[298] R8-63 Page 814
[299] CR8-69 Page 815
[300] R8-72 Page 815
References-1
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 References

References References
Bellcore Publications
Generic Requirements
GR253CORE, Synchronous Optical Network (SONET) Transport Systems:
Common Generic Criteria (A module of TSGR, FR440), Issue 2 (Bellcore,
December 1995) plus Revision 1 (Bellcore, December 1997).
GR378CORE, Generic Requirements for Timing Signal Generators, Issue 1
(Bellcore, June 1995).
GR496CORE, SONET Add-Drop Multiplexer (SONET ADM) Generic Criteria (A
module of TSGR, FR440), Issue 1 (Bellcore, December 1998).
GR499CORE, Transport Systems Generic Requirements (TSGR): Common
Requirements (A module of TSGR, FR440), Issue 1 (Bellcore, December 1995).
GR836CORE, OTGR Section 15.2: Generic Operations Interfaces Using OSI
Tools: Information Model Overview: Transport Configuration and Surveillance for
Network Elements (A module of OTGR, FR439), Issue 2 (Bellcore, September
1996).
GR1042CORE, Generic Requirements for Operations Interfaces Using OSI Tools
Information Model Overview: Synchronous Optical Network (SONET) Transport
Information Model, Issue 2 (Bellcore, September 1996).
GR1400CORE, SONET Dual-Fed Unidirectional Path Switched Ring (UPSR)
Equipment Generic Criteria (A module of TSGR, FR440), Issue 1 (Bellcore, March
1994) plus Revision 1 (Bellcore, October 1995).
Special Reports
SRNWT001756, Automatic Protection Switching for SONET, Issue 1 (Bellcore,
October 1990).
NOTE:
All Bellcore documents are subject to change, and their citation in this document reflects
the most current information available at the time of this printing. Readers are advised to
check current status and availability of all documents.
SONET BLSR Equipment Generic Criteria GR1230CORE
References Issue 4, December 1998

References-2
To Contact Bellcore
Bellcore Customer Service
8 Corporate Place, Room 3A-184
Piscataway, New Jersey 08854-4156
1-800-521-CORE (2673) (USA and Canada)
1 (732) 699-5800 (all others)
1 (732) 336-2559 (FAX)
To Order Documents
Perform the following steps to order from the on-line catalog:
1. Enter the URL line: telecom-info.bellcore.com
2. Click on the Search button located on top
3. In the Keywords field, enter the document number (or keywords),
then click on Submit Search.
or . . .
1. Enter the above URL line
2. Click on the Browse button located on top, then click on the subject of interest.
Bellcore employees should perform the following steps:
1. Access the Bellcore Internal Home Page
2. Click on the Marketwise button located on top
3. Click on DOCS - Bellcore Product Catalog
Enter data in one or more of the fields (e.g., enter a document number in the Product
Number field), then follow the instructions to search the on-line catalog.
American National Standards Institute (ANSI) Documents
T1.105.01 1998, Synchronous Optical Network (SONET) - Automatic Protection
Switching.
This publication is available from:
American National Standards Institute, Inc.
11 West 42nd Street
New York, NY 10036
Acronyms1
GR1230CORE SONET BLSR Equipment Generic Criteria
Issue 4, December 1998 Acronyms

Acronyms Acronyms
AIS Alarm Indication Signal
APS Automatic Protection
Switching
ASE Application Service Element
BCC Bellcore Client Company
BER Bit Error Ratio
BIP Bit Interleaved Parity
BITS Building Integrated Timing
Supply
BLSR Bidirectional Line-Switched
Ring
CMISE Common Management
Information Service Element
DCC Data Communications Channel
DCS Digital Cross-connect System
DSn Digital Signal level n
E-NUT Enhanced Non-preemptible
Unprotected Traffic
ES End System
EXER-R Exercise - ring
EXER-S Exercise - span
FS Forced Switch
FS-R Forced Switch - ring
FS-S Forced switch - span
GR Generic Requirements
document
IS Intermediate System
LOF Loss Of Frame
LOS Loss Of Signal
LOW Lockout of Working
LP-S Lockout of protection - span
LTE Line Terminating Equipment
MS-R Manual switch - ring
NE Network Element
OAM&P Operations, Administration,
Maintenance, and Provisioning
OC-N Optical Carrier level N
OS Operations System
PDI Payload Defect Indication
PFI Payload Failure Indication
PM Performance Monitoring
RDI Remote Defect Indication
RIP Ring Interworking on
Protection
RR Reverse Request
SD Signal Degrade
SDH Synchronous Digital Hierarchy
SD-P Signal Degrade - protection
SD-R Signal degrade - ring
SES Severely Errored Second
SF Signal Failure
SF-R SF - ring
SF-S SF - span
SONET Synchronous Optical Network
SPE Synchronous Payload
Envelope
STE Section Terminating
Equipment
STS Synchronous Transport Signal
TSGR Transport Systems Generic
Requirements
UPSR Unidirectional Path-Switched
Ring
VT Virtual Tributary
WS Work Station
WTR Wait To Restore
SONET BLSR Equipment Generic Criteria GR1230CORE
Acronyms Issue 4, December 1998

Acronyms2