لطفا منتظر باشید ...
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
Label Distribution Protocol
Version: 1
PDU Length: 77
LSR ID: 10.0.0.201 (10.0.0.201)
Label Space ID: 0
Label Mapping Message
0... .... = U bit: Unknown bit not set
Message Type: Label Mapping Message (0x400)
Message Length: 67
Message ID: 0x000012d5
Forwarding Equivalence Classes TLV
00.. .... = TLV Unknown bits: Known TLV, do not Forward (0x00)
TLV Type: Forwarding Equivalence Classes TLV (0x100)
TLV Length: 51
FEC Elements
FEC Element 1 VCID: 50
FEC Element Type: Virtual Circuit FEC (128)
1... .... = C-bit: Control Word Present
.000 0000 0000 0110 = VC Type: HDLC (0x0006)
VC Info Length: 43
Group ID: 5
VC ID: 50
Interface Parameter: MTU 1500
ID: MTU (0x01)
Length: 4
MTU: 1500
Interface Parameter: Description
ID: Interface Description (0x03)
Length: 31
Description: *** To Oakland Serial 5/0 ***
Interface Parameter: VCCV
ID: VCCV (0x0c)
Length: 4
CC Type
.... ...1 = PWE3 Control Word: True
.... ..1. = MPLS Router Alert: True
CV Type
.... ...0 = ICMP Ping: False
.... ..1. = LSP Ping: True
.... .0.. = BFD: False
Generic Label TLV
00.. .... = TLV Unknown bits: Known TLV, do not Forward (0x00)
TLV Type: Generic Label TLV (0x200)
TLV Length: 4
Generic Label: 19
From Chapter 6. This FEC element includes the following information:
Control word present
VC Type 0x0006 for HDLC
Group ID 5
VC ID 50
A set of interface parameters:
MTU interface parameter
Interface description
VCCV capabilities of control channel (CC) and connectivity verification (CV)
Generic Label TLV This TLV advertises label 19 for the previously referenced FEC.
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):
PA-A1 in slot 3 that does not support AToM
PA-A3 version 2.0 in slot 4 that does support AToM
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
C7206VXR#show mpls l2transport hw-capability interface ATM 3/0
Interface ATM3/0
!Output omitted for brevity
Transport type ATM AAL5
Core functionality:
MPLS label disposition supported
Control word processing supported
Sequence number processing not supported
VCCV Type 1 processing supported
Edge functionality:
Not supported
Transport type ATM CELL
Core functionality:
MPLS label disposition supported
Control word processing not supported
Sequence number processing not supported
VCCV Type 1 processing not supported
Edge functionality:
Not supported
!Output omitted for brevity
Transport type ATM VCC CELL
Core functionality:
MPLS label disposition supported
Control word processing supported
Sequence number processing not supported
VCCV Type 1 processing supported
Edge functionality:
Not supported
Transport type ATM VPC CELL
Core functionality:
MPLS label disposition supported
Control word processing supported
Sequence number processing not supported
VCCV Type 1 processing supported
Edge functionality:
Not supported
C7206VXR#
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
C7206VXR#show mpls l2transport hw-capability interface ATM 4/0
Interface ATM4/0
!Output omitted for brevity
Transport type ATM AAL5
Core functionality:
MPLS label disposition supported
Control word processing supported
Sequence number processing not supported
VCCV Type 1 processing supported
Edge functionality:
MPLS label imposition supported
Control word processing supported
Sequence number processing not supported
ATM AAL5 forwarding supported
F5 OAM cell forwarding supported
CLP bit setting supported
CLP bit detecting supported
EFCI bit setting supported
EFCI bit detecting supported
Transport type ATM CELL
Core functionality:
MPLS label disposition supported
Control word processing supported
Sequence number processing not supported
VCCV Type 1 processing supported
Edge functionality:
MPLS label imposition supported
Control word processing supported
Sequence number processing not supported
ATM cell forwarding not supported
ATM cell packing not supported
F5 OAM cell forwarding supported
CLP bit setting not supported
CLP bit detecting not supported
EFCI bit setting not supported
EFCI bit detecting not supported
!Output omitted for brevity
C7206VXR#
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.
Figure 8-16. Packed Cell Relay Case Study Topology
[View full size image]
Configuring Cell Packing
Configuring packed cell relay involves two steps:
Step 1. | Specifying three timers for the length of time that a PE router can wait for cells to be concatenated into the same MPLS packet. The maximum cell packing timeout (MCPT) configuration is performed at the ATM interface level. |
Step 2. | Specifying the maximum number of cells to be concatenated in an MPLS packet and the timer that is available for use. You perform this step at the l2transport PVC configuration. |
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
SanFran#show running-config interface ATM 4/0
Building configuration...
Current configuration : 179 bytes
!
interface ATM4/0
no ip address
load-interval 30
atm mcpt-timers 500 800 4095
end
SanFran#
SanFran#show running-config interface ATM 4/0.3
Building configuration...
Current configuration : 296 bytes
!
interface ATM4/0.3 point-to-point
description *** Packed Cell VC AToM to Oakland ***
pvc 0/300 l2transport
encapsulation aal0
cell-packing 10 mcpt-timer 2
xconnect 10.0.0.203 300 encapsulation mpls
!
end
SanFran#
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 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
SanFran#show mpls l2transport binding 300
Destination Address: 10.0.0.203, VC ID: 300
Local Label: 18
Cbit: 1, VC Type: ATM VCC CELL, GroupID: 5
MTU: n/a, Interface Desc: *** Packed Cell VC AToM to Oakland ***
Max Concatenated ATM Cells: 10
VCCV Capabilities: Type 1, Type 2
Remote Label: 18
Cbit: 1, VC Type: ATM VCC CELL, GroupID: 2
MTU: n/a, Interface Desc: *** Packed Cell VC AToM to Albany ***
Max Concatenated ATM Cells: 10
VCCV Capabilities: Type 1, Type 2
SanFran#
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:
Number of cells * 48 Bytes/cell - AAL5 PDU Trailer - SNAP Header for IP =
Number of cells * 48 Bytes/cell - (UU + CPI + Length + CRC) - (LLC + OUI + etype) =
10 * 48 - (1 + 1 + 2 + 4) - (3 + 3 + 2) = 464 Bytes
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
SanFran#ping
Protocol [ip]:
Target IP address: 192.168.3.2
Repeat count [5]: 10000
Datagram size [100]: 464
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 10000, 464-byte ICMP Echos to 192.168.3.2, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!Output omitted for brevity
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (10000/10000), round-trip min/avg/max = 1/2/16 ms
SanFran#show atm cell-packing
average average
circuit local nbr of cells peer nbr of cells MCPT
type MNCP rcvd in one pkt MNCP sent in one pkt (us)
ATM4/0.3 vc 0/300 10 9 10 9 800
SanFran#
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
SanFran#clear counters
Clear "show interface" counters on all interfaces [confirm]
SanFran#
*May 27 01:22:25.858: %CLEAR-5-COUNTERS: Clear counter on all interfaces by
console
SanFran#ping
Protocol [ip]:
Target IP address: 192.168.3.2
Repeat count [5]: 10000
Datagram size [100]: 465
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 10000, 465-byte ICMP Echos to 192.168.3.2, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!Output omitted for brevity
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (10000/10000), round-trip min/avg/max = 4/7/24 ms
SanFran#show atm cell-packing
average average
circuit local nbr of cells peer nbr of cells MCPT
type MNCP rcvd in one pkt MNCP sent in one pkt (us)
ATM4/0.3 vc 0/300 10 5 10 5 800
SanFran#
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
SanFran#debug mpls l2transport packet data
01:45:36: ATOM imposition: out Fa4/0, size 66, EXP 0x0, seq 0, control word
0x300000
01:45:36: 00 0C CF 55 24 08 00 04 4E 26 18 70 88 47 00 01
^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^ ^^^^^ ^^^^^
SA MAC DA MAC | VC Label-->
etype = MPLS Unicast
01:45:36: 31 02 00 30 00 00 AA AA 03 00 00 00 08 00 45 00
^^^^^ ^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^ ^^...
<--VC_Label Ctrl-word SNAP Begins IP Packet
Label=19 LLC: AAAA03
S=1 OUI: 000000
TTL=2 etype: 0x0800 (IP)
01:45:36: 00 24 00 14 00 00 FF 01 38 71 C0 A8 01 02 C0 A8
01:45:36: 01 01 00 00 27 F7 00 04 00 00 00 00 00 00 00 70
01:45:36: D7 94
^^^^^
Ends IP Packet
01:45:40: ATOM imposition: out Fa4/0, size 74, EXP 0x0, seq 0, control word
0x8380000
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
SanFran#debug mpls l2transport packet data
02:27:46: ATOM imposition: out Fa4/0, size 74, EXP 0x0, seq 0, control word
0x380000
02:27:46: 00 0C CF 55 24 08 00 04 4E 26 18 70 88 47 00 01
^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^ ^^^^^ ^^^^^
SA MAC DA MAC | VC Label-->
etype = MPLS Unicast
02:27:46: 21 02 00 38 00 00 00 00 0C 80 AA AA 03 00 00 00
^^^^^ ^^^^^^^^^^^ ^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^
<--VC_Label Ctrl-word ATM Cell SNAP
Label=18 Header LLC: AAAA03
S=1 0/200 OUI: 000000
TTL=2 EoAAL5=0 etype: 0x0800 (IP)
02:27:46: 08 00 45 00 00 24 00 2F 00 00 FF 01 36 56 C0 A8
^^^^^^ ^^...
SNAP Begins IP Packet
02:27:46: 02 02 C0 A8 02 01 00 00 8C DE 00 0E 00 00 00 00
02:27:46: 00 00 00 97 72 7C 00 00 00 00
^^...
CPCS-PDU Padding
02:27:46: ATOM imposition: out Fa4/0, size 74, EXP 0x0, seq 0, control word
0x380000
02:27:46: 00 0C CF 55 24 08 00 04 4E 26 18 70 88 47 00 01
^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^ ^^^^^ ^^^^^
SA MAC DA MAC | VC Label-->
etype = MPLS Unicast
02:27:46: 21 02 00 38 00 00 00 00 0C 82 00 00 00 00 00 00
^^^^^ ^^^^^^^^^^^ ^^^^^^^^^^^ ^^...
<--VC_Label Ctrl-word ATM Cell CPCS-PDU Padding
Label=18 Header
S=1 VPI=0; VCI = 200
TTL=2 EoAAL5 = 1
02:27:46: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
02:27:46: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
02:27:46: 00 00 00 00 00 2C 2B F1 73 FD
...^^ ^^^^^^^^^^^^^^^^^^^^^^^
CPCS-PDU Pad CPCS-PDU Trailer
UU = 0; CPI = 0;
Length = 0x2C = 44 Bytes
CRC = 0x2BF173FD
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
SanFran#debug mpls l2transport packet data
02:30:27: ATOM imposition: out Fa4/0, size 126, EXP 0x0, seq 0, control word 0x0
02:30:27: 00 0C CF 55 24 08 00 04 4E 26 18 70 88 47 00 01
^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^ ^^^^^ ^^^^^
SA MAC DA MAC | VC Label-->
etype = MPLS Unicast
02:30:27: 41 02 00 00 00 00 00 00 12 C0 AA AA 03 00 00 00
^^^^^ ^^^^^^^^^^^ ^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^
<--VC_Label Ctrl-word ATM Cell SNAP
Label=20 Header LLC: AAAA03
S=1 0/300 OUI: 000000
TTL=2 EoAAL5=0 etype: 0x0800 (IP)
02:30:27: 08 00 45 00 00 24 00 3A 00 00 FF 01 34 4B C0 A8
^^^^^^ ^^...
SNAP Begins IP Packet
02:30:27: 03 02 C0 A8 03 01 00 00 06 1C 00 12 00 00 00 00
02:30:27: 00 00 06 01 F3 D0 00 00 00 00 00 00 12 C2 00 00
...^^^^^^^^^^^ ^^^^^^^^^^^ ^^...
CPCS-PDU Padding ATM Cell CPCS-PDU Padding
Header
VPI/VCI = 0/300
EoAAL5=1
02:30:27: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
02:30:27: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
02:30:27: 00 00 00 00 00 00 00 00 00 2C A6 9C AA FC
...^^ ^^^^^^^^^^^^^^^^^^^^^^^
CPCS-PDU Pad CPCS-PDU Trailer
UU = 0; CPI = 0;
Length = 0x2C = 44 Bytes
CRC = 0xA69CAAFC
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 (26 - 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.
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.
