Guest

Cisco 3700 Series Multiservice Access Routers

Circuit Emulation over IP Network Modules Q&A

Table Of Contents

Circuit Emulation over IP (CEoIP) Network Modules


Q & A

Circuit Emulation over IP (CEoIP) Network Modules


Q. What are the new Circuit Emulation-over-IP (CEoIP) network modules?

A. There are two new network modules: the NM-CEM-4TE1 and NM-CEM-4SER.

They both support the new CEoIP service offering, which is essentially the use of an IP network to provide a point-to-point, bit-transparent data stream between two endpoints. Such a data stream is completely protocol-independent because the network encapsulates and transports, in a continuous stream of IP packets, every data bit presented to an ingress port for delivery to a designated destination port. The data stream is not examined, interpreted, or manipulated in any way.

Q. Why are there two different network modules?

A. The NM-CEM-4TE1 provides four T1/E1 ports. Depending on the software configuration, all four ports are T1 or all four ports are E1.

The NM-CEM-4SER provides four synchronous serial ports.

Depending on the cable attached to each NM-CEM-4SER port, the port can be:

V.35

X.21

EIA-530

EIA-530A

EIA/TIA-449

EIA/TIA-232

Similarly, depending on the cable attached to each NM-CEM-4SER port, the port can be:

Data communications equipment (DCE)

Data terminal equipment (DTE)

Q. Which platforms are supported?

A. These new network modules are supported in the:

Cisco 3745

Cisco 3725

Cisco 3660

Cisco 2691

Cisco 2600XM Series

Q. How many CEoIP modules per platform are supported?

A. Each network module consumes one network module slot. The maximum number of circuit emulation network modules supported depends on the number of network module slots available in each platform.

Cisco 3745—4 slots

Cisco 3725—2 slots

Cisco 3660—6 slots

Cisco 2691—1 slot

Cisco 2600XM series—1 slot

Q. Which Cisco IOS® Software release is required?

A. Cisco IOS Release 12.3(7)T is required to support these network modules.

Q. Which Cisco IOS feature sets are required?

A. On the Cisco 3745, Cisco 3725, Cisco 2691, and Cisco 2600XM Series router platforms, the NM-CEM-4TE1 and NM-CEM-4SER require one of the following feature sets:

SP Services

Advanced IP Services

Enterprise Services

Advanced Enterprise Services

On the Cisco 3660, the NM-CEM-4TE1 and NM-CEM-4SER require the IP Plus feature set or above.

The NM-CEM-4TE1 and NM-CEM-4SER are also supported in a selection of special-purpose feature sets. For more details of the feature sets supporting these network modules, refer to the Feature Navigator at http://www.cisco.com/go/fn or contact your local Cisco representative.

Q. Can you give me an application example for the NM-CEM-4TE1?

A. The NM-CEM-4TE1 can be used any time a bit-transparent data stream transport is needed between devices with T1 or E1 interfaces. For example, the NM-CEM-4TE1 might be used to provide:

A T1 or E1 leased-line service over an IP network infrastructure

A fractional T1 or fractional E1 (N x 64 kbps) data service capable of carrying any conventional or proprietary data protocol

Q. Can you give me an application example for the NM-CEM-4SER?

A. The NM-CEM-4SER can be used any time a bit-transparent data stream transport is needed between devices with synchronous serial interfaces. Most commonly, the NM-CEM-4SER might be used to connect data devices that generate a synchronous serial data stream that is not in any format (such as IP, High-Level Data Link Control [HDLC], Synchronous Data Link Control [SDLC], Frame Relay, ATM, etc.) recognized by other router interfaces. Such data streams might include:

Encrypted data

Legacy data protocols that have not been, or cannot be, upgraded to IP or some other frame-based format. Such protocols are still widely used in a variety of industries, such as utilities, transportation, etc.

Q. Does the NM-CEM-4TE1 support framed and unframed modes?

A. Yes, each T1/E1 port can be independently configured to operate either in unframed or framed mode.

In unframed mode, a T1 or E1 port encapsulates the entire T1 stream (1544000 bps) or E1 stream (2048000 bps) for transport across the IP network.

In framed mode, the framing structure of the line is not encapsulated for transport across the IP network. Thus, on a T1 port in framed mode, up to 1536000 bps can be carried across the network. Similarly, on an E1 port in framed mode, up to 1984000 bps can be carried across the network.

Q. Does the NM-CEM-4TE1 support Channelized and Unchannelized modes?

A. Yes. If a T1/E1 port is configured in framed mode (see previous question), then it can be used in either an Unchannelized or a Channelized mode.

In Unchannelized mode, a T1 or E1 port encapsulates the entire T1 payload (1536000 bps) or E1 payload (1984000 bps) for transport across the IP network as a single data stream.

In Channelized mode, a T1 or E1 port can be configured with up to N separate data streams. N = 24 for a T1 port and N = 31 for an E1 port. Each data stream can include any combination of timeslots, either contiguous or not. Of course, each timeslot can be included in only one data stream.

Q. How many channels can be created on the NM-CEM-4TE1?

A. The NM-CEM-4TE1 supports a maximum of 64 channels. Each channel can be N x 64 kbps (or N x 56 kbps in T1 mode).

Q. Is grooming supported on the NM-CEM-4TE1?

A. Yes. Each N x 64 kbps or N x 56 kbps channel is independent and able to terminate on a separate network destination.

Q. How many channels can be created on the NM-CEM-4SER?

A. The NM-CEM-4SER supports a maximum of 4 channels. Each port supports a single data stream.

Q. What port speeds are supported on the NM-CEM-4SER?

A. Each data port of the NM-CEM-4SER can be independently configured for any of the following data rates (shown in bps).

200

8000

38400

128000

512000

400

9600

48000

144000

672000

800

12000

56000

168000

768000

1200

12800

57600

192000

772000

1800

14400

64000

224000

896000

2400

16000

72000

230400

1024000

3200

16800

76800

256000

1152000

3600

19200

84000

288000

1344000

4800

24000

96000

336000

1536000

6400

28800

112000

384000

1544000

7200

32000

115200

448000

2048000


Q. Can I use all four ports simultaneously at the maximum speed?

A. The NM-CEM-4SER can operate all four ports at 2 Mbps with no restrictions.

The NM-CEM-4TE1 can operate all four ports at 2 Mbps (E1 rate) as long as the default (or larger) packet payload sizes are used. The NM-CEM-4TE1 can support (very approximately) 10,000 packets/second (pps). That limit could, in theory, be exceeded if a large number of N x 64 kbps channels are created (with small values of N) with very small packet payload sizes.

Q. Is there any dependency between the number of supported channels and platforms?

A. Officially, no. However, certain router platforms (the Cisco 2600XM Series) can become severely congested if they are forced to attempt to route an excessive number of packets/second. That can occur with the NM-CEM-4TE1 if a large number of N x 64 kbps channels are created (with small values of N) with very small packet payload sizes.

To avoid any such problems with large numbers of low-speed channels, use the default (or larger) packet payload size.

Q. What are the network requirements?

A. There are no specific network requirements. However, in the interest of minimizing jitter (see below), it is best to ensure that CEoIP data streams have high Quality of Service (QoS) characteristics through the use of priority queuing, etc.

Q. What is jitter, and why do I have to worry about it?

A. Jitter is simply the variation in the end-to-end network delay experienced by packets as they travel from their source port to their destination port through the network.

Because the goal of circuit emulation is to deliver exactly the same bit stream to the destination port as was received at the source port, it is important to ensure that each packet arrives at the destination in time to be played out as soon as the previous packet has been played out to the attached device.

The NM-CEM-4TE1 and NM-CEM-4SER compensate for jitter by holding packets at their destination port in a"de-jitter buffer" that is intended to be half full on average. Packets that arrive with less delay will cause the de-jitter buffer to fill over half full momentarily. Packets that arrive with more delay will cause the de-jitter buffer to be under half full momentarily.

The goal, of course, is to ensure that the de-jitter buffer never overflows or underflows.

Q. How much jitter can be accommodated on these network modules (in other words, what is the maximum de-jitter buffer size)?

A. The de-jitter buffer for each channel is independently configurable up to a maximum of 500 milliseconds. This accommodates jitter of ± 250 milliseconds.

Q. What is the smallest de-jitter buffer size?

A. The minimum configurable de-jitter buffer size is 5 milliseconds (± 2.5 milliseconds), but it is best to ensure that the de-jitter buffer is at least large enough to hold four datapackets.

Q. Can the de-jitter buffer size be tuned?

A. Yes, the de-jitter buffer size is configurable.

Q. What happens if a packet gets dropped?

A. If a packet gets dropped (or excessively delayed) in the IP network, its content in the egress data stream is replaced with a configurable idle pattern.

Q. Is there any protection against packet drops, and how does it work?

A. There is an optional feature called "data protection", which ensures that no data is lost in the event of any nonconsecutive packet drops in the network.

It works by sending each data bit twice, once in each of two consecutive packets. Each packet consists of N bits of data repeated from the previous packets plus N new bits of data (that will be repeated in the subsequent packet).

This mechanism is based on RFC 2198, developed originally for modem signal transport in voice over IP (VoIP).

Q. What is the overhead of a CEoIP packet?

A. Each CEoIP packet has a 44-byte header consisting of:

a 20-byte IP header

an 8-byte User Datagram Protocol (UDP) header

a 12-byte Real-Time Transport Protocol (RTP) header

a 4-byte circuit emulation header

Q. What are the supported packet payload sizes?

A. The payload size is configurable between 1 byte (for very low data rates) and 1312 bytes. The actual payload sizes supported depend on the data rate of the channel.

Q. What is the default packet payload size?

A. The default packet payload size depends on the data rate of the connection. Most data rates use a default packet payload size in the range of 32 to 512 bytes.

Q. Can the overhead be reduced?

A. The overhead of a CEoIP packet can be reduced some by:

using compressed RTP (cRTP) to compress the packet header

using a large packet payload size

Using cRTP, the 40-byte IP/UDP/RTP header can be reduced to 2 to 4 bytes, resulting in a total header size of 6 to 8bytes.

Q. Can the packet payload be compressed? If so, what is the compression ratio?

A. Payload compression may be enabled. Lempel-Zif-Stac (LZS) compression is used. The LZS algorithm performs a historical search for repeating patterns in the data stream. If a repeating pattern is found, it is replaced with a pointer to the previous occurrence of the pattern in the data stream.

Naturally, the effectiveness of this algorithm depends entirely on the nature of the data in the data stream. The best-case compression (repeating "idle" data) approaches 90%.

Q. How much delay does compression cause?

A. The delay caused by the compression algorithm is one packet time. Naturally, that is a function of the channel data rate and the packet payload size.

Q. How much traffic can be compressed?

A. A maximum of 3 Mbps of data may be compressed per network module.

Q. What delay does CEoIP cause?

A. The principal sources of end-to-end delay in a CEoIP service are the following:

Packetizing delay

Routing delays in the source, intermediate, and destination routers

Packet serialization delays on the links in the network

De-jitter buffer delay at the destination port

Q. Is there any way to minimize delay?

A. The packetizing delay can be minimized by using a high data rate and a small packet payload size, at the cost of a higher pps rate and lower packet efficiency (percentage of packet carrying payload bits).

The de-jitter buffer delay can be minimized by using a small de-jitter buffer size (at the risk of occasional buffer under-runs or over-runs as a result of variable network jitter).

The routing and link delays can be minimized by using high-speed platforms connected by high-speed links.

Q. Does CEoIP require end-to-end synchronization?

A. In order to achieve end-to-end bit-transparent circuit emulation without bit errors, it is imperative that both endpoints of a circuit use the same bit clock frequency. Specifically, the source ingress bit clock frequency of a data stream must be the same as the destination egress bit clock frequency of that data stream If that is not the case, the de-jitter buffer at the destination of the circuit will eventually over-flow or under-flow.

Q. Which clock sources can be used to achieve end-to-end synchronization?

A. The egress bit clock frequency on each port can be any one of the following:

The "internal" clock derived from the oscillator on the network module or the central oscillator of the router (onrouters equipped with a time-division multiplexing [TDM] bus)

The "line" clock provided by the attached device

The "adaptive" clock, which is a locally synthesized clock tuned to match the source ingress bit clock by monitoring the average level of data in the egress de-jitter buffer.

Q. How does adaptive clocking work?

A. As mentioned previously, the adaptive clock mechanism works by monitoring the average amount of data in the egress de-jitter buffer for the channel. When the de-jitter buffer is found to be filling slowly over time, the adaptive clock is increased slightly. When the de-jitter buffer is found to be depleting slowly over time, the adaptive clock is decreased slightly.

Q. Can I choose a different clock source for every port?

A. The clock source selection is independent on each port. However, on the NM-CEM-4TE1, all N x 64 kbps channels that share a single port must, of course, share the clock frequency selected for that port.

Q. What are the clock options on the NM-CEM-4SER?

A. Each port of the NM-CEM-4SER may be independently configured in either normal clock mode or split clock mode.

In normal clock mode, the DCE provides both the Receive Clock and the Transmit Clock to the DTE.

In split clock mode, the DCE provides the Receive Clock to the DTE and the DTE provides the Transmit Clock (sometimes called the External Transmit Clock clock [XTC], or Terminal Timing [TT]) to the DCE.

Q. Why are there so many different clock options, and when should I use what?

A. The requirement is simply to ensure that the flow of data in each direction has exactly one master clock frequency. That often requires careful examination and configuration of:

the source CPE

the source circuit emulation port

the destination circuit emulation port

the destination CPE

This configuration ensures that there is exactly one clock master frequency in each direction.

In most cases, the same master clock frequency is used for both directions of a bidirectional data stream.

Q. Is channel associated signaling (CAS) supported on the NM-CEM-4TE1?

A. Yes.

Q. When do I need CAS?

A. CAS support is needed if the NM-CEM-4TE1 is being used for transparent transport of voice channels between private branch exchanges (PBXs or equivalent) that used CAS between them.

Q. Are control signals supported on the NM-CEM-4SER?

A. The NM-CEM-4SER supports the monitoring and end-to-end transport of the most commonly used control signals on the interface types supported. Specifically, the following control signals are supported with the Cisco-standard 12-in-1 "smart serial" cables:

Data Terminal Ready (DTR)

Data Set Ready (DSR)

Request to Send (RTS)

Clear to Send (CTS)

Data Carrier Detect (DCD)

Local Loop (LL)

The following additional control signals are supported with the new extended 12-in-1 "smart serial" cables introduced with this network module:

Remote Loop (RL)

Test Mode (TM)

Ring Indicator (RI)

The set of control signals supported on each port and the standards-based name for each control signal depend on the interface type. Each control signal listed previously may not be supported on every interface type. Also, the control signal names shown are simply the most commonly used names.

Q. Are the serial control signals used for anything?

A. By default, the serial port control signals are not used by the NM-CEM-4SER for anything. They are merely transported between end devices to be used in any way the attached devices see fit.

However, any input control signal on a serial data port may be configured as a "data strobe" to indicate to the NM-CEM-4SER whether ingress data on the port should be encapsulated for transmission or ignored. If the "data strobe" control signal is on, data packets are created and sent. If the "data strobe" is off (either intentionally, or as a result of the failure of the customer premises equipment [CPE]), no data packets are created, resulting in preservation of bandwidth in the IP network.

Q. Which QoS bits are supported, and what are their default settings?

A. The NM-CEM-4TE1 and the NM-CEM-4SER generate IP packets that use the standard QoS fields in the IP header.

By default, the Differentiated Services Code Point (DSCP) byte is set to 46.

If DSCP is not used, that field in the IP header may be used to support IP Type of Service, or ToS, (set to 5, by default), and IP Precedence (set to 0, by default).

Q. Can the QoS bits be modified?

A. All of the QoS bits are configurable for each channel.

Q. Is interworking supported between the NM-CEM-4TE1 and the NM-CEM-4SER?

A. Data streams are supported between the NM-CEM-4TE1 and the NM-CEM-4SER. Naturally, such data streams must use configuration parameters (such as data rate and payload size) that are supported on both network module types.

Q. Is this solution standards-compliant?

A. The Cisco T1/E1 CEoIP implementation is compliant to the ITU-T Y.1413 standard.

There is no standard for the Cisco serial port solution.

Q. Does CEoIP use the VoIP stack?

A. Yes, CEoIP uses an IP header structure similar to VoIP.