Advanced WAN AToM Case Studies

This section concentrates on advanced concepts and techniques in deployments of AToM Layer 2 transport of WAN protocols. It covers diverse in-depth topics that involve a higher degree of complexity or understanding.

This section analyzes four additional case studies. The first two case studies present additional details about LDP signaling of pseudowires and specifics about Cisco implementation, including techniques so that you can understand hardware specifics and documentation matrices. Although these two case studies use WAN transport over MPLS examples, they are applicable to all other Layer 2 transports.

Finally, this section includes two advanced cases of ATMoMPLS, namely ATM cell packing and a detailed comparison of different AToM transports for ATM VCs.

Case Study 8-6: Decoding LDP Label Mapping and Pseudowire ID FEC Elements

Chapter 6 presented theoretical aspects of the AToM control plane and details on LDP messages. You have seen examples of using LDP to provide VC label mapping throughout Chapters 7, "LAN Protocols over MPLS Case Studies," and 8, "WAN Protocols over MPLS Case Studies." This section includes the decoding of a real LDP label mapping message captured from the HDLCoMPLS signaling in Case Study 8-1. You can also capture the hexadecimal dump of LDP messages by using the Cisco IOS debug facility with the command debug mpls ldp session io all. Example 8-40 shows the decoding of the LDP label mapping message for a pseudowire (VC) FEC highlighting the LDP message, TLVs, and items in the VC FEC element. The decode was obtained using ethereal software.

Example 8-40. Decoding an LDP Label Mapping Message for a VC

From Example 8-40, you can see that the LDP label mapping message is sent from SanFran (LDP ID 10.0.0.201) and contains two type, length, value (TLV) triplets to provide the FEC-to-label mapping (FEC <-> label):

Note

It is interesting to note the value for the Group ID of 5. The Group ID is an arbitrary 32-bit number that represents a group of pseudowires (a second degree of freedom by creating groups in the VC ID space). These groups are per LDP peer, meaning that VC IDs with the same Group ID belong to the same group if they belong to the same peer. The Group ID provides a superficial incremental benefit when sending one LDP label withdrawal message to a given peer for the group of VCs instead of multiple individual withdrawals for each VC. Earlier releases of Cisco IOS Software used the Interface Index of the main hardware interface descriptor block (IDB) as the Group ID. For example, for a VLAN attachment circuit in interface Gigabit-Ethernet 1/0.100, the Group ID used to be the IfIndex for GigabitEthernet 1/0. This way, wildcard label withdrawals or notifications could be sent on physical port failure. However, because of the limited benefit of the wildcard withdrawal, current releases of Cisco IOS software set the Group ID to 0 for all pseudowires, and wildcard withdraw messages are not sent. For ATM ACs, a non-zero value is still used, but wildcard withdrawals are not sent.

Case Study 8-7: AToM Hardware Capabilities

Throughout this book, multiple case studies provide generic configuration but do not focus on platform-specific differences. Although remaining hardware agnostic in the case studies is useful, some platform information is required. This section provides a means of checking support on specific platforms without actually listing all platform restrictions.

This section presents an exec command that displays the AToM hardware capability and uses a c7200 VXR series router with two ATM port adapters (PA):

First issue the command specifying the ATM PA that does not support ATM transport. See Example 8-41 for abbreviated output. Core functionality refers to a core-facing PE interface, and Edge functionality refers to an edge-facing PE interface.

Example 8-41. Unsupported AToM Layer 2 Transport Hardware Capability

You can see from Example 8-41 that imposition is not supported for any ATM transport type. Therefore, the commands to configure AToM ATM transport do not appear in the router CLI. In contrast, you can issue the same command against an ATM PA that does support AToM ATM transport (see Example 8-42).

Example 8-42. Supported AToM Layer 2 Transport Hardware Capability

In Example 8-42, you can see that imposition functions are supported for all AToM ATM transport. Specific information about ATM transport features is also included in the command output.

This procedure enables you to check the hardware dependencies without having to check support matrices.

Case Study 8-8: Packed Cell Relay over MPLS

The forthcoming two sections present advanced topics on ATM transport over MPLS. This section introduces ideas and configuration examples on packed cell relay over MPLS, and the next section compares different ATM transports from a data plane perspective.

The concept of cell packing that was presented previously in this chapter is straightforward. It involves concatenating multiple cells into a single AToM packet. The tradeoff is also quite direct: bandwidth efficiency gained by sharing the AToM and lower PCI overhead versus increased latency and jitter.

This section presents a case study on packed cell relay using the topology shown in Figure 8-16.

Configuring Cell Packing

The configuration for the SanFran side is shown in Example 8-43. It highlights the specific cell packing commands.

Example 8-43. Packed Cell Relay Configuration

Three interface level timers are configured with the atm mcpt-timers command. They are shared by all Layer 2 transport VCs and VPs under that interface and its subinterfaces.

Verifying Cell Packing Configuration and Operation

You advertise the max cells to be packed by adding a new interface parameter to the LDP label mapping message (see Example 8-44). As mentioned earlier in the "Encapsulations and Packet Format for Cell Transport" section, the MTU interface parameter does not apply to ATM Cell transport and is not advertised.

Example 8-44. Packed Cell Relay Verification

To fully understand how cell relay packing works, you can perform a simple experiment. First calculate the size of a ping that would fully occupy ten cells without padding. You can use the following formula and refer to the packets shown in Figure 8-7:

You can see that specifying a PING size of 464 bytes requires exactly ten ATM cells. The first part of the exercise consists of sending 10,000 PING packets of 464 bytes and checking the average number of cells per packet (see Example 8-45).

Example 8-45. Packed Cell Relay Exercise Part 1

The counter from Example 8-45 shows nine cells instead of ten because of OAM cells bringing down the average slightly. The second part of the exercise is to clear the counters and send another 10,000 PING packets but now 1 byte longer than before, which is 465 bytes (see Example 8-46).

Example 8-46. Packed Cell Relay Exercise Part 2

Example 8-46 shows that the average number of cells packed both in receive and transmit directions dropped drastically to 5. This is because each ICMP echo request and echo packets now require 11 cells instead of 10. Therefore, each PING packet is sent using two MPLS AToM packets, one with 10 cells and the other with just 1 cell, averaging a bit over 5 cells per MPLS packet. Note that the timers are short enough that the second MPLS packet does not have 10 cells. In addition, the second packet is sent with only one cell because the timer expires before the second echo request is received.

Case Study 8-9: Understanding Different ATM Transfer Modes

You have learned about the different AToM encapsulationsin particular the different modes of transporting an ATM PVC (AAL5 CPCS-SDU, single cell relay, and packed cell relay). This section illustrates their similarities and differences with examples to solidify the concepts.

You can highlight some of the differences among ATM transfer modes by sending a 36-byte ping from the Oakland CE routers in the three modes and comparing the capture of those AToM packets in the link between the Denver P and NewYork P routers. You can obtain the capture as output for the command debug mpls l2transport packet data. All packets you capture share the same Layer 2 encapsulation (source and destination MAC address and MPLS unicast Ethertype). They also share the absence of a PSN label because of Penultimate Hop Popping (PHP) and a VC MPLS header with a different label. Finally, all the packets share the presence of a control word that has different characteristics.

AAL5 CPCS-SDU Mode

The first case is the AAL5 SDU transport of the ICMP PING. The AAL5 CPCS-SDU consists of the IP/ICMP packet with a SNAP header. Therefore, the contents of the AToM packet are 48 bytes: 4 bytes of control word, 8 bytes of LLC-SNAP Header, and 36 bytes of IP/ICMP packet. The packet is shown in Example 8-47, including inline decoding. The AAL5 CPCS-SDU is highlighted.

Example 8-47. AAL5 SDU Mode Packet Decode

In Example 8-47, you can see that the contents of the MPLS packets are the 4-byte control word plus the 44-byte AAL5 CPCS-SDU, totaling 48 bytes. You can also see that the value of the control word is 0x00300000, which contains the length equal to 0x30 = 48 bytes.

For completeness, Example 8-47 also includes the first line of the output of the transport of ATM OAM cells in AAL5 CPCS-SDU mode. The value of the control word is now 0x08380000. This depicts a length of 0x38 = 56 bytes (52 bytes of the ATM cell plus 4 bytes of the control word). The T-bit is set to indicate that the contents are an ATM cell. Remember this length to compare it to the single cell relay and packed cell relay modes.

Single Cell Relay Mode

This section describes the ATM cell relay transport VC mode with single cell relay. In this case, the complete AAL5 CPCS-PDU is transported and is made of the CPCS-SDU plus the 8-byte CPCS-PDU trailer and padding if needed. For the 36-byte PING, the CPCS-SDU and the CPCS-Trailer total 52 bytes. Therefore, the AAL5 PDU is segmented into two cells in the SAR layer and padded with 44 bytes (48 * 2 52). Because this case is single cell relay, two AToM packets are generated, each containing one ATM cell (see Example 8-48). For comparison, the AAL5 CPCS-SDU is highlighted.

Example 8-48. Single Cell Relay Mode Packet Decode

From Example 8-48, you can see the 44 bytes of CPCS-PDU padding, the 8-byte CPCS-PDU trailer, and 4 bytes for each of the ATM-Layer ATM cell headers. The value of the control word is 0x00380000, from which the length equals 0x38 = 56 bytes. These 56 bytes are 52 bytes of ATM cell plus 4 bytes of control word.

Packed Cell Relay Mode

This section includes a capture for ATM packed cell relay VC mode (see Example 8-49). In this case, the two transported cells are concatenated into a single AToM packet.

Example 8-49. Packed Cell Relay Mode Packet Decode

The format of the contents of this single AToM packet is similar to merging the contents of two AToM packets in the previous case. That is, the two cells share the Layer 2, MPLS, and pseudowire (control word) overheads. The control word presents a value of 0x00000000. The length is not included because it is 108 bytes (52 * 2 + 4), which is greater than 63 bytes, which is the maximum value the length field can take with 6 bits (2⁶ - 1 = 63).

The overhead is quite significant in the ATM cell transport because the size of the user data transported is small, and there is additional overhead from the ATM cell header and AAL5 padding and trailer. Table 8-4 lists all the fields of the AToM packet contents and their lengths for the three cases.

Table 8-4. Comparing ATM Transport Overheads
Transport Type	Control Word	ATM Cell Header	LLC-SNAP	IP/ICMP	CPCS-Pad	CPCS-Trailer	Total
AAL5 CPCS-SDU	4 bytes	0	8 bytes	36 bytes	0	0	48 bytes
Single Cell Relay	2 * 4 bytes	2 * 4 bytes	8 bytes	36 bytes	44 bytes	8 bytes	112 bytes
Packed Cell Relay	4 bytes	2 * 4 bytes	8 bytes	36 bytes	44 bytes	8 bytes	108 bytes

From this table, you can see that when you are transporting AAL5 packets, AAL5 CPCS-SDU mode is more efficient, especially when the ATM AAL5 packets are small. When you are transporting other AALs, such as AAL1 for Circuit Emulation Services (CES) or AAL2 for Voice over ATM (VoATM), cell relay is the only option. Similarly, CRoMPLS is the only option when you are trunking using VP or port mode, because AAL5 mode does not exist for VP and port mode ATM transport.