Packet over SONET Operation and Specifications
The current Internet Engineering Task Force (IETF) PoS specification is RFC 2615 (PPP over SONET), which obsoletes RFC 1619. The PoS RFCs define the requirements that are needed to transport data packets through PoS across a SONET network. These requirements are summarized as follows:
High-order containment—PoS frames must be placed in the required synchronous transport signals used in SONET. An example of this is an OC-12 concatenated PoS interface. This interface requires an STS-12 circuit to contain the required payload of the PoS traffic.
Octet alignment—This refers to the alignment of the data packet octet boundaries to the STS octet boundaries. An octet (byte) defines an arbitrary group of 8 bits. The word byte is defined as usually containing 8 bits. IBM used to define a byte as containing 7 bits. Although both byte and octet are used interchangeably, octet is a more accurate representation for 8 bits because its meaning is a series of eight.
Payload scrambling—Scrambling is the process of encoding digital 1s and 0s onto a line in such a way that provides an adequate number for a 1s density requirement. The ANSI standard for T1 transmission requires an average density of 1s of 12.5 percent (a single 1 in 8 bits meets this requirement) with no more than 14 consecutive 0s for unframed signals and no more than 15 consecutive 0s for framed signals. The primary reason for enforcing a 1s density requirement is for timing recovery or network synchronization. However, other factors such as automatic-line-build-out (ALBO), equalization, and power usage are affected by 1s density. RFC 1619 inadvertently permitted malicious users to generate packets with bit patterns that could create SONET density synchronization problems and replication of the frame alignment. RFC 2615 provides a more secure mechanism for payload scrambling.
High-Order Containment
End stations at customer sites are predominantly TCP/IP-enabled devices. At the edge of the customer's network, the IP packet is encapsulated into a Layer 2 format that will be supported on the SP's network. The Layer 2 protocols supported by Cisco are PPP and Cisco HDLC, but the PoS standards specify PPP encapsulation for PoS interfaces. The Layer 2 PPP or Cisco HDLC frame information is encapsulated into a generic HDLC header (not Cisco proprietary HDLC) and placed into the appropriate SPE of the Whereas frame. This can be a confusing concept at first. Although HDLC and PPP are different, mutually exclusive Layer 2 protocols, HDLC is used as a SPE delimiter in the SONET frame. The encapsulation process of an IP packet to a SONET frame is illustrated in Figure 9-4.
)
Figure
9-4
Encapsulating IP into a PoS Frame
PPP Frame
RFC 1548 defines a PPP frame that contains the following three components:
Protocol field
Information field
Padding field
The Protocol field is used because PPP was designed to be multiprotocol in nature. Multiprotocol encapsulations transport multiple protocols, including IP and IPX. The Information field is the protocol data unit (PDU) transmitted, and can be from 0 to 64,000 bytes. The Padding field is used to pad the PPP frame if the Information field does not contain enough data. The Padding field might receive padding up to the maximum receive unit (MRU), which will fill the Information field. The default value for the MRU is 1500 octets but can be up to 64,000 octets if negotiated in the PPP implementation. It is the responsibility of the protocol to determine which bits are used as padding. You can find more information about the PPP protocol in RFC 1548 and RFC 1661 at http://www.ietf.org. Figure 9-5 illustrates the PPP in HDLC-like frame format.
)
Figure
9-5 RFC 1662: PPP in HDLC-Like Framing
Figure 9-6 illustrates the values used in the PPP in the HDLC-like framing process. Notice that frame delimiters of hexadecimal 0x7E (126 in decimal) are used to denote the beginning and ending of a frame. The transmitting device generates flags as a time fill when there are no data packets.
)
Figure
9-6 Packet over SONET Frame Information
The Address field is always set to 0xFF (255) because every frame is a broadcast frame in PoS. There are only two ends of the point-to-point connection, and the frame always needs to get to the other side. There is no reason to have more than one address because there are no other addressable destinations. The Layer 2 mechanism is terminated at the other end of the link because PoS interfaces are Layer 3 enabled.
A Control field of 0x03 (3) is used to denote an HDLC frame. The Information field is where the PPP frame is inserted and is variable in nature due to MRU variability. A 16- or 32-bit frame check sequence (FCS) is used as a trailer to the frame. The FCS can be 16 or 32 bits long, but 32-bit CRCs are highly recommended due to the enhanced error recovery that is available using 32 bits. Most interfaces that run at speeds greater than OC-12 use FCS-32 as the default. The FCS is a configurable option, and FCS 32 is always recommended. The FCS field needs to match on both ends of the connection; otherwise, the Layer 2 protocol will never come up.
NOTE
Although this book does not specifically deal with SDH, all Cisco PoS interface card framing can be changed from the default SONET framing to that of SDH.
Payload Scrambling
SONET has a default scrambler that was designed for voice transport. The 7-bit SONET scrambler is not well suited for data transport. Unlike voice signals, data transmissions might contain long streams of 0s or 1s. If the change from a 0 to 1 is not frequent enough, the receiving device can lose synchronization to the incoming signal. This can also cause signal-quality degradation resulting from distributed bit errors. The solution to this synchronization and bit error problem is to add an additional payload scrambler to the one normally found within SONET environments. This scrambler is applied only to the payload section, which contains the data. The SONET overhead bytes do not need this additional scrambling because they continue to use the existing 7-bit SONET scrambler. Certain overhead bytes, including the A1/A2 SONET framing bytes and the J0 section trace byte, are never scrambled with any type of scrambling.
The two versions of scrambling that are supported by PoS are defined in the Telcordia GR-253 and ITU-T I.432 documents. The Telcordia GR-253 standard defines a basic 1 + x^6 + x^7 algorithm that scrambles the transport overhead of the SONET frame (with the exception of certain overhead bytes). This scrambler cannot be disabled and is adequate when the SONET frames carry phone calls in the payload.
The ITU-T I.432 standard defines an ATM-style scrambling. This scrambler uses a polynomial of x^43 + 1 and is a self-synchronous scrambler, meaning that no state needs to be sent from the sender to the receiver. With this scrambler, only the data SPE of the SONET frame is scrambled.
The scrambling function is performed in hardware and does not affect performance in any way. Scrambling is performed directly in the framer application-specific integrated circuits (ASICs) on newer line cards and in a separate adjacent ASIC on older line cards. As technology evolves, more functionality is integrated into the same ASICs to lower the real estate (space) needs of hardware. Cisco supports port densities as large as 16 OC-3 ports on 1 Cisco 12000 series line card.
The path overhead C2 byte (path signal label) is used to instruct the receiving equipment that payload scrambling is turned on. If the traffic is carrying PPP with scrambling turned on, the value is set to a hexadecimal value of 0x16 (22). If scrambling is turned off, the original hexadecimal value of 0xCF (207) is used. Figure 9-7 shows the scrambling functions used in PoS environments.
)
Figure
9-7 SONET RFC 2615 Payload Scrambler