APPLICATION NOTE 4124

DS33X162 Product Family FAQ

By: Arthur Harvey

Abstract: This application note addresses frequently asked questions (FAQs) about the DS33X162 family of EoPDH Ethernet mapping products. The DS33X162 product family is used in carrier Ethernet, Ethernet demarcation, Ethernet access, MSPP, DSLAM, ROADM, microwave radio, WAN router, and Ethernet aggregation applications. They support GFP, VCAT, and LCAS protocols for aggregating PDH links for Ethernet service delivery.

Application Questions
Which device should I choose for my application?
What is an encapsulator/decapsulator?
I need to support EVCs with my equipment. How are those different from VCGs?
What is EoPDH and how is it different from DSL?
What is the difference between HDLC and GFP encapsulation?
Can the DS33X161/DS33X162 transmit data to 16 remote nodes in 16 different locations?
If a DS33X162 is used to connect to four different remote nodes, is the traffic-forwarding mechanism the same as if I used a cheap 4-port Ethernet switch?
Can the DS33X162 product family connect to the DS33R41 or DS33Z41?
Can the DS33X162 product family connect to the DS33Z11, DS33R11, or DS33Z44?
Is an external framer and LIU required to use devices in the DS33X162 product family?
Why must a multiframe sync be provided in most cases?
What frame latency is added by the device?
What Ethernet flow control is supported?
Should I use Ethernet flow control in my application?
Can I limit the amount of bandwidth that I provide to the Ethernet interface?
Can I use this device in a "drop and continue" application?

Hardware Design Questions
Is there a reference design available?
What power-supply decoupling should be used?
Are there special layout requirements for the DDR SDRAM interface bus?

Software Design Questions
How much processor involvement is required for data to flow?
What does the device do to WAN insertion frames prior to transmission?
Could you provide an example WAN insertion frame?
Could you provide an example LAN insertion frame?
How can this device be used for Ethernet OAM?
How do I assign the device an Ethernet (MAC) address?
How do I assign the device an IP address?
How can higher-level protocols such as SNMP be implemented?
Are internal fill levels available for each queue?

Application Questions

Q) Which device should I choose for my application?

A) Choosing the right device from the nine devices in the DS33X162 product family might seem difficult at first glance, but a simple set of criteria based on the application can usually be used to select the best device.

If the application is a point-to-point system, or "bookend solution", then normally only one encapsulator is needed—narrowing selection to the DS33X11, DS33X41, DS33X81, DS33X161, and DS33W11 devices. If the application is a "point-to-multipoint", "rooted multipoint", "drop and continue", or mesh system, it is likely that more than one encapsulator is needed. The DS33X42 and DS33W41 each have two encapsulators, with each encapsulator serving as the endpoint for one point-to-point WAN data path. The DS33X82 and DS33X162 each contain four encapsulators, and thus can originate/terminate four point-to-point WAN data paths.

The VCAT/LCAS protocol enables a WAN data path to be delivered over multiple T1/E1 or DS3/E3 links. The next application requirement to look at is: How many and what type of TDM links are needed for each WAN data path? The answer to this question will normally narrow the selection to devices that contain at least that many TDM ports. For example, if a single WAN path with 16 E1 links is required, the applicable solutions are the DS33X161 and DS33X162. If two WAN data paths with eight E1 links each are required, then the only applicable solution is the DS33X162. If four DS-3 links are required, the applicable solutions are the DS33X41, DS33X42, DS33X81, DS33X82, DS33X161, and DS33X162.

A third selection criterion to consider is the number of Ethernet interfaces required in the system. The DS33X42, DS33X82, and DS33X162 support a single 1000Mbps interface or a dual 10/100Mbps interface. The DS33X11, DS33W11, DS33X41, DS33W41, DS33X81, and DS33X162 support a single 10/100/1000Mbps interface. With all devices, additional Ethernet ports can be gained by using an external Ethernet switch chip. It is also worth noting that the DS33X11 has one PCB footprint, the DS33W11 and DS33W41 have a second PCB footprint, and all remaining devices share a third PCB footprint. It is easy to migrate a design between devices in the product family or to provision a single design for multiple PCB assembly options.

Table 1-1 in the data sheet provides a complete listing of the differentiating factors among the devices in the product family.

Q) What is an encapsulator/decapsulator?

A) An encapsulator is a circuit that takes frames from an Ethernet LAN and prepares them for transport across a WAN network. A decapsulator performs the opposite function by accepting a stream of encapsulated frames from a WAN and preparing the frames for transmission on an Ethernet LAN. In the DS33X162 product family, the encapsulator/decapsulator also performs a variety of packet-processing functions such as inserting/removing information and prioritizing traffic. An encapsulator/decapsulator pair must sit at each end of a WAN connection. Using the virtual concatenation (VCAT) protocol, an encapsulator's data can be spread over multiple physical PDH links to improve throughput and reduce latency. The VCAT term for the bundle of links used for this purpose is a virtually concatenated group (VCG). Each encapsulator supports one VCG.

Q) I need to support EVCs with my equipment. How are those different from VCGs?

A) An Ethernet virtual connection (EVC) is a pathway between two points, usually two physical Ethernet interfaces, over which an Ethernet service is provided. Only frames that belong to the EVC are delivered to each endpoint of an EVC. Equipment based on the DS33X162 family of products can normally support at least one EVC per encapsulator. A virtually concatenated group (VCG) can be used to deliver the EVC, or a single line can be used. Support for additional EVCs can be added by using an additional Ethernet switch that supports VLAN tagging based on the physical port of service.

Q) What is EoPDH and how is it different from DSL?

A) EoPDH is the transport of native Ethernet (layer-2) frames over the plesiochronous digital hierarchy (PDH) network comprised of T1/E1 and DS3/E3 links. xDSL systems are not usually considered as part of the PDH network. Additionally, traditional residential xDSL systems transport only layer-3 IP datagrams and prevent layer-2 protocols such as ARP, BPDU, RSPT, or Ethernet OAM from running across them. For a comprehensive white paper covering EoPDH technology, refer to application note 3849: "Ethernet-over-PDH Technology Overview."

Q) What is the difference between HDLC and GFP encapsulation?

A) HDLC encapsulation has been used in legacy systems for several decades. However, HDLC suffers a problem when the "flag sequence" used to denote the start and end of a frame occurs natively in the data being transported. HDLC must substitute the offending sequence with a longer nonoffending sequence. In the worst cases, this can choke the available bandwidth down to 50% of the expected value. GFP avoids this problem by using a length-indicating header with error correction. Because of the predictable overhead, GFP is generally the preferred encapsulation method for new systems. The DS33X162 family of products supports both HDLC and GFP.

Q) Can the DS33X161/DS33X162 transmit data to 16 remote nodes in 16 different locations?

A) No. Because the DS33X162 contains four encapsulators, the maximum number of distinct remote nodes each DS33X162 can communicate with is four. If more than four WAN paths are required, an external Ethernet switch should be used.

Q) If a DS33X162 is used to connect to four different remote nodes, is the traffic-forwarding mechanism the same as if I used a cheap 4-port Ethernet switch?

A) No. The DS33X162 uses VLAN tag information to forward frames to the encapsulators. Most common Ethernet switches found in today's enterprise environment use only Ethernet destination address information to forward traffic by using an imperfect learning and filtering mechanism. The use of an imperfect mechanism results in some traffic occasionally being broadcast on all ports; that is, a single user's data is transmitted to unintended recipients, resulting in both security and privacy issues. The DS33X162's use of VLAN forwarding allows for a well-defined flow of traffic that contains and manages user traffic within a specific physical path.

Q) Can the DS33X162 product family connect to the DS33R41 or DS33Z41?

A) No. The DS33R41 and DS33Z41 use a proprietary inverse-multiplexing protocol. The DS33X162 family of products uses the ITU-standardized VCAT/LCAS protocol. The two protocols are not compatible.

Q) Can the DS33X162 product family connect to the DS33Z11, DS33R11, or DS33Z44?

A) Yes. Devices in the DS33X162 product family have an operating mode that supports legacy HDLC over single PDH connections. This is the same protocol used in the DS33Z11, DS33R11, and DS33Z44. Revision A1 of the DS33X162 family of devices did not support this operation, while all later revisions support this legacy HDLC protocol.

Q) Is an external framer and LIU required to use devices in the DS33X162 product family?

A) In most applications, an external T1/E1 or DS3/E3 framer and line interface unit will be needed to provide a multiframe synchronization signal. One exception is the case of a point-to-point connection over a single physical link using bit-stuffed HDLC. The DS33X162 family of devices is designed to seamlessly interface with Maxim's line of single-chip transceivers and framers.

Q) Why must a multiframe sync be provided in most cases?

A) The Ethernet-over-PDH standards have alignment requirements that can only be met with the use of a multiframe alignment signal.

Q) What frame latency is added by the device?

A) The last-bit-in to first-bit-out frame latency in continuous undersubscribed conditions is less than 100µs. In oversubscribed conditions, frame latency is dependent on many factors and cannot be simply described. The device's strict-priority and round-robin frame scheduling algorithms can be used to reduce the latency of high-priority frames with respect to lower-priority frames.

Q) What Ethernet flow control is supported?

A) The DS33X162 family provides IEEE® 802.3-compliant flow control for both full- and half-duplex operation. Flow control is configurable, and can be disabled.

Q) Should I use Ethernet flow control in my application?

A) In some applications, Ethernet's layer-2 flow control can interfere with higher-layer flow control protocols. For example, TCP/IP flow control depends on lost frames in order to detect when it has exceeded a system's capabilities. TCP/IP flow control uses an increasing flow rate until lost frames are detected, at which point it uses a back-off and resend algorithm based on the number of lost frames until a steady stream is maintained. If no frames are lost, TCP/IP will continue attempting to increase the flow rate. If TCP/IP flow control is used in conjunction with Ethernet flow control, the results may be undesirable. The system architect should carefully study the effects of flow control on the entire system to determine if the system should use Ethernet flow control or frame discarding.

Q) Can I limit the amount of bandwidth that I provide to the Ethernet interface?

A) Yes. By using the committed information rate (CIR) controller, you can program the amount of bandwidth available to the Ethernet interface and dynamically adjust it from zero Mbps up to the PDH line rate.

Q) Can I use this device in a "drop and continue" application?

A) Yes. The DS33X82 and DS33X162 devices support several complex configurations based on VLAN ID information.

Hardware Design Questions

Q) Is there a reference design available?

A) Yes. Contact technical support at for the latest reference design information.

Q) What power-supply decoupling should be used?

A) The amount of decoupling required varies with the noise present on the supply, but here are some general decoupling and layout recommendations.
  1. Place at least one 0.1µF ceramic cap per power supply on the device.
  2. Place the decoupling cap as close to the device's power pin as possible.
  3. Do not share vias to power or ground with other caps.
  4. Use the smallest cap package possible for the required voltage.
  5. The connections to the plane should be as wide of a trace as possible.
  6. Do not break-up the planes. Keep higher-frequency planes close to high-speed devices.
  7. Use at least one 4.7µF tantalum cap per power supply on the board.
Q) Are there special layout requirements for the DDR SDRAM interface bus?

A) Yes. The traces of the DDR SDRAM bus should be length and impedance matched as closely as possible. Signal stubs should be avoided. P2P mode is supported, which simplifies the line-termination circuitry. More specific layout questions will be answered by technical support staff at .

Software Design Questions

Q) How much processor involvement is required for data to flow?

A) For normal user traffic, no host processor interaction is required. The data and control planes of the device are completely separate. Once configuration is complete, the host processor only needs to monitor for status and interrupts, taking action only when necessary. The user can choose to make use of the device's trap, extraction, and insertion functions to implement management protocols or perform other functions. In this case, frames meeting a specific set of user-programmed conditions will be passed between the data and control planes for processing by the host processor. The processing requirements of the host processor vary by the particular protocol or application implementation.

Q) What does the device do to WAN insertion frames prior to transmission?

A) When transmitting frames that have been placed in the WAN insertion FIFO, the device manages the basic frame-delineation functions and allows others to be programmed by the user. HDLC start/stop flags are automatically inserted by the device if in HDLC mode. GPF payload length and cHEC values are inserted by the device when in GFP mode. Encapsulation CRC values, GFP type headers, GFP extension headers, VLAN tags, or other frame modifications must be performed by the user software prior to placement in the WAN insertion FIFO.

For example, consider inserting a WAN frame with cHDLC encapsulation. The user software must insert the cHDLC 4-byte Address, Control, and Protocol header bytes prior to the beginning of the Ethernet frame, and write the resulting data into the WAN insertion FIFO. The cHDLC example given below has a brief description of the entire packet and the data that should be written to WAN Insertion FIFO.

Q) Could you provide an example WAN insertion frame?

A) An example WAN insertion frame is shown below.
Encode: cHDLC
Length: 4 HDLC + 132 Ethernet
H HDR:  Cisco HDLC Unicast IP (0F 00 80 00)
MAC DA: Internet Multicast (01 00 5E 7F FF FF)
MAC SA: Dallas Semiconductor (00 60 35 12 34 56)
VLAN:   PRI 0, CFI 0, VID 2047 (81 00 07 FF)
Type:   IP (08 00)
E HDR:  45 00 00 6E 00 00 00 00 40 72 EB 2E
Net SA: 198.019.001.100 (C6 13 01 64)
Net DA: 198.019.001.101 (C6 13 01 65)
Data:   AA + Analysis Data
E FCS:  84 96 3B 14

0F 00 08 00 01 00 5E 7F FF FF 00 60 35 12 34 56 
81 00 07 FF 08 00 45 00 00 6E 00 00 00 00 40 72 
EB 2E C6 13 01 64 C6 13 01 65 AA AA AA AA AA AA 
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA 
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA 
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA 
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA 
AA AA 00 04 20 01 00 08 00 00 00 00 2F 78 D4 F4 
D0 87 2B 0B 84 96 3B 14
Q) Could you provide an example LAN insertion frame?

A) An example LAN insertion frame is shown below.
Destination Address: 00:45:54:48:5f:30
Source Address: 00:0e:7f:a5:65:c6 
Type: IP (0800)
IP version 4 (45) 
DiffServ = 00
Length =60 bytes (003c)
Identification (64ed)         
Flags & Fragment offset = 0 (0000)
Time to live=128 (80) 
Protocol = ICMP (01) 
Header Checksum (5480) 
Source IP = 192.168.0.2 (c0a80002)
Destination IP = 192.168.0.1 (c0a80001)
Begin ICMP message (0800)
ICMP Message: 
 97570200
 b4046162     :ICMP Message 
 63646566     :ICMP Message
 6768696a     :ICMP Message 
 6b6c6d6e     :ICMP Message 
 6f707172     :ICMP Message 
 73747576     :ICMP Message
 77616263     :ICMP Message 
 64656667     :ICMP Message 
 6869         :ICMP Message End
Ethernet FCS CRC-16 (870e)

00 45 54 48 5f 30 00 0e 7f a5 65 c6 08 00 45 00 
00 3c 64 ed 00 00 80 01 54 80 c0 a8 00 02 c0 a8
00 01 08 00 97 57 02 00 b4 04 61 62 63 64 65 66
67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76
77 61 62 63 64 65 66 67 68 69 87 0e
Q) How can this device be used for Ethernet OAM?

A) The device can be configured to trap frames in the slow-protocol range of 01:80:C2:xx:xx:xx, which includes Ethernet OAM frames. All frames within this address range will be held in a FIFO for extraction by the host microprocessor. The host microprocessor can parse, interpret, and respond to OAM messages.

Q) How do I assign the device an Ethernet (MAC) address?

A) Use the software to choose an Ethernet (MAC) address to communicate with. For the MAC address associated with the LAN extract, the value is programmed into the SU.LEDAL, SU.LEDAM, and SU.LEDAH registers. A different (or the same) MAC address can be used for the WAN extract in the SU.WEDAL, SU.WEDAM, and SU.WEDAH registers.

Q) How do I assign the device an IP address?

A) In almost all networked equipment, the associating of Ethernet addresses to IP addresses is performed by a layer-2 protocol named the address resolution protocol (ARP). The host processor must use the trap and insert functions of the device as the communication path for a software ARP agent.

Q) How can higher-level protocols such as SNMP be implemented?

A) SNMP—like any other high-level protocol that can be implemented using the DS33X162 family of products—requires software development by the customer. Maxim does not provide high-level protocol software at this time. The DS33X162 products provide the required hardware support needed to implement an SNMP agent for an RMON MIB in software. Specifically, the device allows trapping and insertion of unicast frames (i.e. Ethernet frame addresses assigned to the equipment). An "SNMP agent" is the software application that runs on the host microprocessor and processes the SNMP frames. To implement an SNMP agent, the user needs to develop (or purchase) software for a minimal TCP/IP stack to run on their microprocessor, including an ARP client. The DS33X162 also contains the hardware counters required for the RMON MIB. The SNMP agent needs to be able to handle the SNMP messages in software. The SNMP agent reads the hardware counters in order to respond to RMON messages. The customer could also develop their own SNMP MIB that would allow access to all functions of the device—including remote configuration and more complex status messages.

Q) Are internal fill levels available for each queue?

A) No. A fill value would be meaningless to a slow host processor as the fill value can change at a rate of up to 1Gbps in GbE applications. However, it is possible to set a threshold of remaining queue space available such that an interrupt can be generated when a queue has less than a certain amount of space remaining. The threshold setting is common to all LAN queues.
Next Steps
EE-Mail Subscribe to EE-Mail and receive automatic notice of new documents in your areas of interest.
Download Download, PDF Format
© , Maxim Integrated Products, Inc.
The content on this webpage is protected by copyright laws of the United States and of foreign countries. For requests to copy this content, contact us.
APP 4124:
APPLICATION NOTE 4124,AN4124, AN 4124, APP4124, Appnote4124, Appnote 4124