DS34S132 DATA SHEET
19-4750; Rev1; 7/11
27 of 194
9
FUNCTIONAL DESCRIPTION
This section provides a high level, functional view of the S132. Because of the high level of integration and
complexity that has been included in the S132, it is necessary to first explain the terminology and conventions that
are used. This Functional Description section is further supported by the Register Guide section, which identifies
common settings for specific applications, and the Register Definition section which provides a definition for each
register, but without as much regard for application information.
The industry term “Pseudowire” (PW) includes the idea of a “virtual connection” (pseudo virtual; wire
connection). PW data is carried in packets. The connection is not a “hardwired” connection but “virtual” in nature
where the “virtual connection” is recognized by interpreting the PW packet header (e.g. the PW-ID provides the PW
destination address).
There are multiple PW protocols to carry different types of data. Each is designed to support a particular service
type, for example PCM, HDLC, ATM and Frame Relay. The PW protocols enable a Service Provider to transport
and switch all of its services using a single unified switching/routing/forwarding technique (e.g. IPv4).
Enterprise and CPE equipment can similarly use the PW protocols. PWs can enable LAN
switching/routing/forwarding using a single protocol/equipment type (e.g. Ethernet switch) to support both packet
encapsulated-TDM and bursty packet data. PWs can also be used to enable the use of a single WAN interface to
carry aggregated Enterprise data across the WAN/PSN. For example, if the WAN service/interface is Ethernet, then
a single WAN-Ethernet interface can be used to carry “bursty” Ethernet data and packet encapsulated TDM data
across the WAN. This prevents the need to pay for independent Ethernet WAN and TDM WAN services.
The DS34S132 supports three PW types. The term “TDMoP PW” is used to refer to a PW that is used to transport
a constant-bit-rate TDM service. The S132 supports two types of TDMoP PWs: SAToP (SAT) and CESoPSN
(CES). The term “HDLC PW” is used to refer to a PW that is used to transport the non-idle payload data from an
HDLC data stream. The S132 includes the necessary functions to translate TDM constant bit rate data streams
to/from TDMoP PWs and HDLC data streams to/from HDLC PWs for PSNs using the UDP/IP, L2TPv3/IP, MEF-8
or MFA-8 protocol.
PWs that are recognized by the S132 are described using the terms “Connection”, ”Packet”, “Bundle” and “Bundle
ID” (BID). Each term emphasizes a different aspect of the PW. The S132 supports up to 256 programmed Bundles
(numbered Bundle 0 through Bundle 255). The term “Bundle” emphasizes the recognized/programmed parameters
associated with a PW (the programmed header format, payload format, PW-ID value, etc.). If a PW packet is
received by an S132, but the packet format or PW-ID of the packet does not equal that of a programmed Bundle,
then the packet is not recognized. The term “BID” equates to a “recognized/programmed PW-ID” (part of a Bundle).
The term “Connection” emphasizes the type of data carried by a packet (e.g. timing) and emphasizes where the
data is forwarded inside the S132 (e.g. to a Clock Recovery Engine). The S132 Bundle Connection types include
SAT/CES Payload, HDLC Payload, SAT/CES PW-Timing and CPU. SAT, CES and HDLC Payload Connections
are used to forward the data between a TDM Port and the payload of a TDMoP PW. A SAT or CES PW-Timing
Connection is used to forward the timing information between a TDM Port and the TDMoP PW. A CPU Connection
is used to forward packets between the CPU and the Ethernet Port. CPU packets can be PW packets or non-PW
packets. A “connection” is commonly “established” by enabling an internal S132 function. For example enabling the
Clock Recovery Engine for a particular Bundle “establishes” a PW-Timing Connection for that Bundle.
The term “Bundle” can be thought of as a “small set of connections and parameters”. The packets for a Bundle can
contain data/information for multiple connections, e.g. the packet for a SAT Bundle can contain data/information for
a SAT Payload Connection and a SAT PW-Timing Connection.
The S132 supports a number of CPU packet types that are not Bundle/PWs. The term “CPU Connection” indicates
that the data stream carries data that is forwarded to the CPU. The S132 supports specialized header field values
and conditions that identify CPU Connections (e.g. the MEF OAM header).
The terms “OAM Bundle” and “OAM BID” are similar in meaning to “Bundle” and “BID” except that they are only
used for CPU Connections. The S132 supports up to 32 “OAM Bundles” that are programmed independent of the
256 Bundles. “OAM Bundles” are used to support Out-band VCCV (also known as UDP-specific OAM).
The term “Packet”, when used in combination with one of the Connection/data types emphasizes that the packet
contains data/information for a particular type of connection (e.g. CES, SAT, HDLC, PW-Timing and/or CPU
Packet). The terms “packet” and “frame” are loosely used interchangeably to identify a “datagram/unit” of data that