This document reviews the basic differences in the framing used with
Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) in
an Asynchronous Transfer Mode (ATM) environment, and in a Packet over SONET
(POS) environment. Currently, SONET is more widely used in North America, while
SDH is more widely deployed in Europe.
Note: A detailed discussion of SONET and SDH differences is outside the
scope of this document.
There are no specific requirements for this document.
This document is not restricted to specific software and hardware
Technical Tips Conventions for more information on document
SONET and SDH have relatively minor, but still important differences
between them, mostly in terminology. In many cases, the SDH definitions of some
overhead messages are more general in nature, and their SONET equivalents are
more tuned to the operating conditions within North America.
Some key differences between SONET and SDH are listed here:
SONET and SDH use different terms to describe the three layers. SDH
uses the terms path, multiplex section, and regenerator section while SONET
uses the terms section, line, and path.
The values of the C2 Path Overhead (POH) byte are slightly different.
Both SONET and SDH use 0x16 and 0xCF for POS.
Specific overhead bytes, and the content of Automatic Protection
Systems (APS) messages transmitted in the K1/K2 bytes are different. The
overhead of SDH framing is illustrated here. Refer to
Guide for Synchronous Digital Hierarchy for more
The International Telecommunications Union (ITU-T) defines the format
of unassigned and idle cells in its I.361 Recommendation. The purpose of these
cells is to ensure proper cell decoupling or cell delineation, which enables a
receiving ATM interface to recognize the start of each new cell. The ITU-T
defines cell delineation mechanisms in its I.432 Recommendation.
In ATM environments, the key difference between SONET and SDH framing
modes is the type of cell transmission when no user or data cells are
available. The ATM forum specifies the use of idle cells if unassigned cells
are not generated. More specifically, in Synchronous Transport Module-X (STM-X)
mode, an ATM interface sends idle cells for cell-rate decoupling. In
Synchronous Transport Signal-Xc (STS-Xc) mode, the ATM interface sends
unassigned cells for cell-rate decoupling.
The default SONET setting is STS-Xc. Issue this command in interface
configuration mode in order to configure for Synchronous Transport Module-level
Router(config-if)#atm sonet stm-4
Control Cells Illustrated - Idle Cells, Unassigned Cells, IMA Filler Cells and
Invalid Cells for more information.
The POs framing command enables you to set
framing to SONET Optical Carrier (OC) or SDH STM. The default is SONET.
Router(config-if)#POs framing [sdh|sonet]
One more difference between SONET and SDH framing is the value of the
s0 and s1 bits (s is for size), which are bits 5 and 6 in SONET's H1 byte. SDH
uses these bits to form the Administrative Unit (AU) field. The ITU-T G.709
standard (or G.707, which combines G.707, G.708, and G.709) describes the AU
pointer. There are two major AU types, which are listed here:
AU-3 operates in the same way as three sets of H1,
H2, and H3 pointers would operate in channelized STS-3
AU-4 operates like a single set of pointers in
Synchronous Transport Signal-3c (STS-3c) concatenated
The s1s0 bits or flag is unused in SONET. A transmitting POS interface
configured with SONET framing sends ss = 00, and a receiving SONET device
ignores these bits, because they are used to indicate payload mapping type
information, which is communicated through other fields. A POS interface
configured with SDH framing typically sends ss = 10.
This table illustrates well-known values for these bits:
Used in older ADMs
AU3/4 - Most implementations in Europe use 3.
Originally, with SDH framing, the ss bits needed manual reconfiguration
with the pos flag s1s0 2 command. On the Cisco 12000
Series Engine 2 POS line cards, the value now changes automatically when the
framing type is configured (Cisco bug ID CSCdm62748).
router(config-if)#pos flag ?
c2 Path overhead byte
j0 Section trace byte (0x01 for compatibility, 0xCC is default)
s1s0 Specify bit S1 and S0 of H1
router(config-if)#pos flag s1s0 ?
<0-3> S1 & S0 bits
router(config-if)#pos flag s1s0 0
!--- Set to 0 for SONET.
router(config-if)#pos flag s1s0 2
!--- Set to 2 for SDH.
Issue the srp flag s1s0 command on Spatial
Reuse Protocol (SRP) interfaces.
ip address 188.8.131.52 255.255.255.240
srp clock-source line a
srp clock-source line b
srp framing sdh a
srp framing sdh b
srp flag c2 19 a
srp flag c2 19 b
srp flag s1s0 2 a
srp flag s1s0 2 b
The show controller pos and
show controller srp commands display the value of
the s1s0 received from the remote end.
router2#show controller pos 5/1 detail
LOF = 0 LOS = 0 BIP(B1) = 0
AIS = 0 RDI = 0 FEBE = 0 BIP(B2) = 0
AIS = 0 RDI = 0 FEBE = 0 BIP(B3) = 675
LOP = 0 NEWPTR = 0 PSE = 0 NSE = 0
Line triggers delayed 100 ms
Active Defects: None
Active Alarms: None
Alarm reporting enabled for: SF SLOS SLOF B1-TCA B2-TCA PLOP B3-TCA
COAPS = 0 PSBF = 0
State: PSBF_state = False
ais_shut = TRUE
Rx(K1/K2): 00/00 S1S0 = 02, C2 = 16
If the transmitted value is incorrect, ADMs in the network might detect
the difference, and report a Loss of Pointer (LOP) alarm. Cisco routers ignore
this value. They do not declare an alarm, and only reflect what the network has
If two router endpoints in a back-to-back lab setup are configured for
different framing types, pings succeed, and neither device declares an alarm.
However, when router endpoints are connected to a SONET or SDH network, the
ADMs might detect the mismatch, and report a Path Loss of Pointer (PLOP) alarm.
The output of show controller pos command might then
report "Facility alarm: PathFarEndRxFailure". In order to troubleshoot this
problem, ensure that both sides are configured for the same framing type. If
they are, you may need to use a WAN analyzer to capture the frames.
The s1s0 flag configured on POS interfaces automaticaly resets to 0
after a reload of a Cisco 7200 or 7500 Series Router that runs Cisco IOS®
Software Release 12.1(9)E. This issue is resolved by Cisco bug ID
(registered customers only)