Deploying AToM Pseudowires

As previously mentioned, a number of AToM pseudowire types can be configured on Cisco routers. These pseudowire types are as follows:

• Ethernet
• Ethernet VLAN (802.1Q)
• HDLC
• PPP
• Frame Relay
• ATM cell relay
• ATM AAL5-SDU
• IP Layer 2 transport

IP Layer 2 transport is discussed toward the end of this chapter, but all the other types listed are discussed in this section.

Implementing AToM Pseudowires for Ethernet Traffic Transport

Ethernet traffic can be transported over AToM pseudowires in two ways:

• Ethernet port (raw) mode
• Ethernet VLAN (802.1Q) mode

Before examining each of these methods of transporting Ethernet traffic, it might be worthwhile to re-acquaint yourself with Ethernet and Ethernet VLAN (802.1Q) frame formats. Figure 2-13 on page 47 and Figure 2-15 on page 50 illustrate these frame formats.

Now that you've reminded yourself of the Ethernet frame formats, its time to move on to configuration, starting with Ethernet port mode.

AToM Pseudowire Ethernet Port Transport

Before describing the configuration of Ethernet port transport, it is a good idea to take a look at the form of AToM data channel packets when used to transport Ethernet port frames. AToM data channel packets used to transport Ethernet frames conform to the general packet format shown in Figure 3-2, with the format of the optional control word shown in Figure 3-16.

Figure 3-16. Optional Control Word for AToM Ethernet Port Transport

The control word used with Ethernet pseudowires consists of the following fields:

• Reserved These bits are reserved for future use.
• Sequence Number As the name suggests, this field contains a sequence number.

The control word is only included in AToM data channel packets used to transport Ethernet frames when sequencing is configured.

Figure 3-17 illustrates the encapsulation of an Ethernet frame received on an attachment circuit and its transmission on an AToM pseudowire (when using either Ethernet port or Ethernet VLAN [802.1Q] mode).

Figure 3-17. Encapsulation of an Ethernet Frame and Its Transmission on an AToM Pseudowire

When an Ethernet frame is received on an attachment circuit, the preamble and FCS are stripped from the frame; the tunnel label(s), pseudowire (PW) label, and optionally control word are prepended; and the resulting packet is transmitted to the egress PE router.

The egress PE router performs the same operations as the ingress PE router, just in reverse. It removes remaining labels (including the PW label), removes the control word, reconstructs the preamble and FCS, and then transmits the frame on the appropriate attachment circuit (as indicated by the PW label).

That is the theory, but how about configuration?

AToM Pseudowire Configuration on PE Routers

Configuration of an AToM pseudowire consists of the following general steps:

Figure 3-18 shows the network topology for the Ethernet pseudowire configurations in this section.

Figure 3-18. AToM Ethernet Pseudowire Topology

Example 3-5 shows an example configuration that encapsulates these steps on PE router Los.Angeles.PE.

Example 3-5. Configuration of an Ethernet Port Mode AToM Pseudowire on Los.Angeles.PE

Highlighted line 1 shows the ip cef command (Step 1 of the AToM pseudowire configuration process). This command enables CEF on the PE router. Certain platforms such as the 12000 series are capable of supporting distributed CEFthis can be enabled using the ip cef distributed command.

In highlighted line 2, mpls label protocol ldp enables you to specify that the label protocol to be used to advertise label bindings will be LDP (Step 3). Note that this command changes the label protocol used to signal tunnel labels from the default of TDP, but does not affect the protocol that is used to signal AToM pseudowire PW labels (it is always LDP).

The mpls ldp router-id interface [force] command (highlighted line 3) is then used to ensure that the IP address configured on interface loopback 1 is used as the first four octets of the LDP (router) identifier that is carried in the LDP header (see Figure 3-3 on page 140).

Next, in highlighted lines 4 and 5, an IP address (10.1.1.1/32) is configured on interface loopback 1 (Step 2). This IP address is referenced by the mpls ldp router-id interface [force] command in highlighted line 3, and also serves as the pseudowire endpoint.

Highlighted line 6 shows the xconnect peer-pe-ip-address pwid encapsulation mpls command (Step 7). This command is configured on interface Fast Ethernet 1/0, and so binds this attachment circuit interface to a pseudowire to the specified peer PE router (using the peer's loopback [LDP ID] address), with the specified pseudowire ID (otherwise known as a VC ID), using MPLS encapsulation. The peer PE router is, in this example, San.Jose.PE (the other end of the Ethernet port mode pseudowire).

Caution

The pseudowire IDs (VC IDs) at either end of a pseudowire (configured using the xconnect command on peer PE routers) must match. If they do not match, pseudowire setup will fail.

The mpls ip command is then configured on interface Fast Ethernet 3/0 in highlighted line 7 (Step 4). This command is used to enable MPLS on this MPLS backbone network interface (this interface is connected to Los.Angeles.P in this example).

In highlighted lines 8 to 10, OSPF process 100 is configured using the router ospf process-id command, and OSPF is enabled on interfaces Fast Ethernet 3/0 (an MPLS backbone network interface) and loopback 1 using the network ip-address wildcard-mask area area-id command (Step 5). In highlighted line 11, interface loopback1 is configured as a passive interface (no OSPF packets will be sent on this interface).

Although OSPF is used as the backbone IGP in this particular example, it is important to understand that Intermediate System-to-Intermediate System (IS-IS) is also a popular choice as an MPLS backbone IGP. IS-IS and OSPF are by far the two most popular choices for an MPLS backbone IGP for a number of reasons, the most important of which is that they are the only two IGPs that currently support the necessary extensions for MPLS-TE.

Caution

Note that you must make sure that the PE routers have reachability to the IP address configured on the peer PE router's loopback interface (the pseudowire endpoint address as specified using the xconnect command). If there is no IP reachability between peer PE routers' loopback interfaces, pseudowire setup will fail.

That is a sample configuration, but you may have noticed the absence of any commands relating to a pseudowire class (Step 6) in Example 3-5. As previously mentioned, configuration of a pseudowire class is optional, but is essential if you are configuring AToM features such as sequencing and tunnel selection. For more information on the configuration of pseudowire classes, see the section on tunnel selection later in this chapter.

Example 3-6 shows the configuration for San.Jose.PE. Los.Angeles.PE and San.Jose.PE are the two ends of the Ethernet port mode pseudowire.

Example 3-6. Configuration of an Ethernet Port Mode AToM Pseudowire on San.Jose.PE

One quick look at the configuration in Example 3-6 will tell you that it is almost identical to that shown in Example 3-5. The only differences are the interface IP addresses and corresponding addresses specified using the OSPF network commands (highlighted lines 4, 5, 9, and 10), as well as the IP address specified using the xconnect command (highlighted line 6).

The IP address specified using the xconnect command on San.Jose.PE (highlighted line 6) is the loopback interface IP address (LDP router ID) on Los.Angeles.PE.

You will also notice that the PW (VC) ID specified using the xconnect command (1001) is the same as that specified at the other end of the pseudowire, Los.Angeles.PE (see Example 3-5). Although not explicitly shown, the MTU on the attachment circuits at either end of the pseudowire (on interface Fast Ethernet 1/0 on Los.Angeles.PE (see Example 3-5), and on interface Fast Ethernet 2/0) is also identicalin this case, 1500 bytes. If either the PW ID or the attachment circuit MTU is not identical at both ends of the pseudowire, it will not become active.

Steps 1 to 6 of the configuration of PE routers are the same regardless of which type of Layer 2 protocol is being transported over AToM pseudowires. For that reason, these steps are not described again in subsequent sections dealing with the configuration of other pseudowire types (the completion of steps 1 to 6 is assumed).

Configuration on P Routers

Before finishing this section, it is worth taking a look at a sample configuration of a P router. The steps necessary to configure a P router are as follows:

Example 3-7 shows the configuration of a P router, Los.Angeles.P.

Example 3-7. Configuration of Los.Angeles.P

In highlighted lines 1 to 4, CEF is enabled (Step 1), LDP is specified as the label protocol (Step 3), interface loopback 1 is configured as the LDP router ID, and an IP address (10.1.1.3/32) is configured on interface loopback 1 (Step 2).

The mpls ip command is used to enable MPLS on MPLS backbone interfaces (interface Fast Ethernet [connected to Los.Angeles.PE] and interface serial 4/0 [connected to San.Jose.P]) in highlighted lines 5 and 6 (Step 4).

OSPF is then configured and enabled on MPLS backbone interfaces and interface loopback 1 in highlighted lines 7 to 11 (Step 5).

Note that the configuration of P routers is the same regardless of the type of Layer 2 protocols transported using AToM.

As you can see, the example configurations for Los.Angeles.PE, San.Jose.PE, and Los.Angeles.P use LDP to exchange tunnel label bindings and establish LSPsMPLS-TE is not configured in this particular example, and RSVP-TE is not used to distribute tunnel label bindings.

AToM Pseudowire Ethernet VLAN (802.1Q) Transport

The (optional) control word used when transporting Ethernet VLAN (802.1Q) frames over an AToM pseudowire is identical to that used when transporting raw Ethernet frames (see Figure 3-16).

As with Ethernet port mode transport, when using Ethernet VLAN (802.1Q) transport, the ingress PE router removes the preamble and FCS before encapsulating the frame in an AToM data channel packet (see Figure 3-17). The egress PE router reconstitutes the preamble and FCS prior to forwarding an Ethernet frame on its local attachment circuit.

Figure 3-19 shows the topology for the Ethernet VLAN (802.1Q) pseudowire configurations covered in this section.

Figure 3-19. AToM Ethernet VLAN (802.1Q) Pseudowire Topology

Example 3-8 shows the configuration of Ethernet VLAN (802.1Q) transport over an AToM pseudowire.

Example 3-8. Configuration of Ethernet VLAN (8021Q) Transport over an AToM Pseudowire

Highlighted lines 1 and 2 shows the configuration of subinterface Fast Ethernet 2/0.100 and the configuration of 802.1Q encapsulation for VLAN ID 100 (encapsulation dot1q vlan-id) on Los.Angeles.PE.

Subinterface Fast Ethernet 2/0.100 is then bound to a pseudowire to peer PE router 10.1.1.2 (San.Jose.PE), with PW (VC) ID 1002, using MPLS (AToM) encapsulation.

The corresponding peer PE router (San.Jose.PE) configuration is shown in highlighted lines 4 to 6.

In this case, subinterface 4/0.100 is configured in highlighted line 4, and 802.1Q encapsulation is configured for VLAN ID 100 in highlighted line 5.

In highlighted line 6, subinterface Fast Ethernet 4/0.100 is bound to a pseudowire to peer PE router 10.1.1.1 (Los.Angeles.PE), with PW (VC) ID 1002, using MPLS encapsulation.

So, the configuration of Ethernet VLAN (802.1Q) pseudowire is pretty similar to that for regular port mode Ethernet pseudowires. The main difference is that the xconnect command must be configured under an Ethernet subinterface with IEEE 802.1Q encapsulation.

One thing to notice in Example 3-8 is the fact that the VLAN ID configured using the encapsulation dot1q vlan-id command is identical on both PE routers (VLAN ID 100). If the VLAN ID is not identical, the PE routers have to perform a function known as VLAN ID rewrite. In this case, when an 802.1Q frame is received over a pseudowire, the VLAN ID is modified to be equal to the locally configured VLAN ID (refer to Figure 2-15 on page 50).

Note

With the exception of the 12000 series (with the 3-port Gigabit Ethernet card), VLAN rewrite is automatic if the VLAN ID is different at either end of the pseudowire.

On the 12000 series with the 3-port Gigabit Ethernet card, however, you must configure the remote circuit id remote-vlan-id command in xconnect configuration mode (after configuring the xconnect command) on both PE routers.

If (both peer) 12000 series PE routers are running 12.0(30)S or later, however, there is no need to configure the remote circuit id command (VLAN ID rewrite is automatic).

Deploying AToM Pseudowires for HDLC and PPP Traffic Transport

When deploying AToM pseudowires for HDLC and PPP traffic transport, the control word is again optional in data channel packets, but can be used if sequencing is configured.

HDLC pseudowires can be used to transport HDLC or HDLC-like traffic, including older encapsulations such as X.25.

Figure 3-20 shows the optional control word for HDLC and PPP traffic transport.

Figure 3-20. The Optional Control Word for HDLC and PPP Traffic Transport

The fields of the HDLC control word can be described as follows:

• The first 4 bits are set to 0 This indicates a control word.
• The next 4 bits are used for protocol specific flags In the case of HDLC and PPP transport, there are no are no flags, and so these bits are set to 0.
• Reserved (Res) These bits are reserved for future use.
• Length If the packet length, including the control word and the packet payload containing the HDLC or PPP frame, is less than 64 bytes, this field specifies the packet length. If the packet length is greater than or equal to 64 bytes, this field contains a value of 0.
• Sequence Number This contains a sequence number.

Figure 3-21 shows the encapsulation of an HDLC or PPP frame in an AToM data channel packet as it is received on an attachment circuit.

Figure 3-21. Encapsulation of an HDLC or PPP Frame in an AToM Data Channel Packet

In Figure 3-21, an HDLC or PPP frame received on an attachment circuit is placed into the payload of an AToM data channel packet. Note that HDLC or PPP frames are carried in their entirety, with the exception of the flags and FCS fields (see Figure 2-16 and Figure 2-18 on pages xx and xx, respectively). Any bit stuffing is also undone prior to transmission of the frame over the pseudowire.

Example 3-9 shows a sample configuration for the transport of HDLC frames using an AToM pseudowire. This configuration corresponds to the sample topology shown in Figure 3-22.

Figure 3-22. Sample Topology for Transport of HDLC Frames over an AToM Pseudowire

As shown in Figure 3-22, an HDLC connection extends between mjlnet.Los.Angeles.CE and mjlnet.San.Jose.CE over the pseudowire between Los.Angeles.PE and San.Jose.PE. The pseudowire type is 0x0006 (see Table 3-2 on page 147).

Example 3-9. Sample Configuration for the Transport of HDLC Frames Using an AToM Pseudowire

As you can see in Example 3-9, the configuration of HDLC pseudowires is simpleall that is required (apart from Steps 1 to 6 described in the previous section) is to configure the xconnect peer-pe-ip-address pwid encapsulation mpls command under the HDLC attachment circuit interface.

In Example 3-9, xconnect command is configured under interface serial 1/0 and interface serial 3/0 on Los.Angeles.PE and San.Jose.PE, respectively.

The xconnect command on Los.Angeles.PE is used to bind the attachment circuit to a pseudowire to 10.1.1.2 (San.Jose.PE), with PW (VC) ID 1002, using MPLS (AToM) encapsulation.

Similarly, the xconnect command on San.Jose.PE is used to bind the attachment circuit to a pseudowire to 10.1.1.1 (Los.Angeles.PE), with PW (VC) ID 1002, using MPLS encapsulation.

You will also notice the encapsulation hdlc command configured under interface serial 1/0 on Los.Angeles.PE and serial 3/0 on San.Jose.PE. This command is actually a default and so is not really requiredit is shown for illustrative purposes only.

You can verify AToM HDLC pseudowires using the show mpls l2transport vc vcid command, as shown in Example 3-10.

Example 3-10. Verifying AToM HDLC Pseudowires Using the show mpls l2transport vc Command

As you can see in the highlighted line in Example 3-10, the pseudowire is associated with an attachment circuit on interface serial 4/1, the circuit type is HDLC, the remote endpoint (peer PE router) is 10.1.1.1, the VC (PW) ID is 1002, and the status is UP.

The configuration of AToM PPP pseudowires is similar to that for HDLC pseudowires. Example 3-11 shows the configuration of an AToM PPP pseudowire, and Figure 3-23 shows the topology to which the configuration corresponds.

Figure 3-23. AToM PPP Pseudowire Topology

In Figure 3-23, an AToM PPP pseudowire is configured between Los.Angeles.PE and San.Jose.PE to transport a PPP connection between mjlnet.Los.Angeles.CE and mjlnet.San.Jose.CE.

One important thing to notice about Figure 3-23 is the fact that PPP negotiation (LCP, optional authentication, and NCP) takes place between CE devicesPE routers (Los.Angeles.PE and San.Jose.PE, in this example) do not take part in PPP negotiation.

Example 3-11. Configuration of an AToM PPP Pseudowire

As shown in Example 3-11, the encapsulation ppp command must be configured under the attachment circuit interface (see highlighted lines 1 and 3).

In highlighted line 2, the xconnect peer-pe-ip-address pwid encapsulation mpls command is used to bind the PPP attachment circuit to a pseudowire to 10.1.1.2 (San.Jose.PE), with PW (VC) ID 1005, using MPLS (AToM) encapsulation.

The xconnect command is also used in highlighted line 4 to bind the attachment circuit to a pseudowire to 10.1.1.1 (Los.Angeles.PE), with PW (VC) ID 1005, using MPLS encapsulation.

After you have configured an AToM PPP pseudowire, you can verify correct operation using the show mpls l2transport vc vcid command (see Example 3-12).

Example 3-12. Verifying an AToM PPP Pseudowire Using the show mpls l2transport vc Command

In the highlighted line in Example 3-12, you can see that the local attachment circuit (and pseudowire) type is PPP. You can also see that the circuit status is UP (active).

You can also examine PPP negotiation between the CE devices using the debug ppp negotiation command, as demonstrated in Example 3-13.

Example 3-13. Examining PPP Negotiation Using the debug ppp negotiation Command

Highlighted line 1 shows that the PPP phase is ESTABLISHINGthis indicates that PPP negotiation is about to begin.

PPP negotiation then proceeds, and in highlighted line 2, the Link Control Protocol (LCP) state changes to OPEN, indicating that LCP negotiation has succeeded.

PPP authentication now begins, and in highlighted lines 3 to 8, mjlnet.Los.Angeles.CE and mjlnet.San.Jose.CE exchange Challenge Handshake Authentication Protocol (CHAP) messages over the pseudowire, and successfully authenticate each other.

Network Control Protocol (NCP) then begins, and you can see that IP Control Protocol (IPCP) and Cisco Discovery Protocol Control Protocol (CDPCP) negotiation has succeeded (their states change to Open in lines 9 and 10).

Finally, in highlighted line 11, the line protocol changes state to up.

Frame Relay Traffic Transport with AToM Pseudowires

Frame Relay is another Layer 2 traffic type that can be transported over AToM pseudowires. The two methods that support Frame Relay traffic transport are as follows:

• Frame Relay port mode
• Frame Relay DLCI-to-DLCI switching

The sections that follow discuss these two methods of Frame Relay traffic transport.

Frame Relay Port Mode Traffic Transport

The first method of transporting Frame Relay traffic using AToM is to configure an HDLC pseudowire. Remember that HDLC pseudowires can transport HDLC and HDLC-like traffic. If you compare the HDLC and Frame Relay frame formats (see Figures 2-16 and 2-21 on pages xx and xx), you will notice that the Frame Relay frame is based on the HDLC frame.

Figure 3-24 illustrates the transport of Frame Relay traffic over an HDLC pseudowire.

Figure 3-24. Transport of Frame Relay Traffic over an HDLC Pseudowire

As shown in Figure 3-24, mjlnet.Los.Angeles.CE and mjlnet.San.Jose.CE are configured for Frame Relay encapsulation. The attachment circuit interfaces on Los.Angeles.PE and San.Jose.PE are configured for HDLC encapsulation, however.

As illustrated in Figure 3-24, if an HDLC pseudowire is used to transport Frame Relay traffic, the PE routers (Los.Angeles.PE and San.Jose.PE, in this example) do not participate in LMIinstead, LMI is signaled over the pseudowire between the CE devices.

The configuration of an HDLC pseudowire for Frame Relay traffic transport is shown in Example 3-9 on page 167it is identical to the configuration of a regular HDLC pseudowire.

You can verify the status of an HDLC pseudowire using the show mpls l2transport vc vcid command, as shown in Example 3-10 on page 167.

You can also verify Frame Relay traffic transport on the CE devices using the show frame-relay pvc command, as demonstrated in Example 3-14.

Example 3-14. Verifying Frame Relay Traffic Transport on CE Devices Using the show frame-relay pvc Command

Highlighted line 1 shows that a Frame Relay PVC with DLCI 100 is active on interface serial 0.

Frame Relay DLCI-to-DLCI Switching Traffic Transport

The second method of transporting Frame Relay traffic over an AToM pseudowire is to use a DLCI-to-DLCI switching pseudowire.

Figure 3-25 shows the control word that is used with Frame Relay DLCI-to-DLCI switching.

Figure 3-25. Control Word Used with Frame Relay DLCI-to-DLCI Switching

The fields in the control word are as follows:

• The first 4 bits must be set to 0 Indicates that this is pseudowire data.
• The F (Forward Explicit Congestion Notification [FECN]) bit The setting of this bit should be copied from the FECN bit in the address field of the Frame Relay frame (see Figure 2-21 on page 61).
• The B (Backward Explicit Congestion Notification [BECN]) The setting of this bit should be copied from the BECN bit in the address field of the Frame Relay frame.

  It is worth noting that in earlier specifications the order of the B and F bits was reversed in the control word.

• The D (Discard Eligibility [DE]) bit This should be copied from the DE bit in the address field of the Frame Relay frame.
• The C (Command/Response [C/R]) bit This should be copied from the C/R bit of the Frame Relay frame.
• Res These two bits are reserved for future use, and must be set to 0.
• Length This field is useful when the AToM pseudowire transits a link that requires a certain minimum frame size.

  If the frame size is less than 64 octets (including the AToM data channel packet payload, plus the control word [see Figure 3-2]), the value contained Length field equals the length of the payloadthis value allows the egress PE router to remove the padding that is added to ensure the minimum frame size. If the frame size is not less than 64 octets, the Length field is set to a value of 0.

• Sequence Number When sequencing is enabled (a mechanism used to ensure the ordered delivery of pseudowire packets), this field contains a sequence number value.

Figure 3-26 illustrates the encapsulation of a Frame Relay frame received on an attachment circuit in an AToM data channel packet.

Figure 3-26. Encapsulation of a Frame Relay Frame in an AToM Data Channel Packet

In Figure 3-26, a Frame Relay frame is received on an attachment circuit. The FECN, BECN, DE, and C/R bit setting are copied from the Frame Relay frame address field to the control word, and the frame itself is placed in the packet payload. PW (VC) and tunnel labels are added, and the packet is transmitted to the egress PE router.

Note that FECN, BECN, and DE bit settings in the control word can also be affected by configuration of the PE router (for example, the configuration of quality of service [QoS]).

When an AToM data channel packet containing a Frame Relay frame is received by the egress PE router, the process just described is performed in reverse, before the Frame Relay frame is transmitted to the connected CE device on the attachment circuit.

Example 3-15 shows the configuration of a Frame Relay DLCI-to-DLCI switching pseudowire between two PE routers. Figure 3-27 illustrates the corresponding network topology.

Figure 3-27. Frame Relay DLCI-to-DLCI Pseudowire

One particular thing to notice about Figure 3-27 is that unlike with Frame Relay port mode transport (Figure 3-24), when using Frame Relay DLCI-to-DLCI switching, LMI is terminated by the PE routers (Los.Angeles.PE and San.Jose.PE participate in LMI with their connected CE device).

Example 3-15. Configuration of Frame Relay DLCI-to-DLCI Switching AToM Pseudowires

Highlighted lines 1 to 5 show the configuration of Los.Angeles.PE.

In highlighted line 1, the frame-relay switching command is used to configure the switching of Frame Relay PVCs.

The encapsulation frame-relay command in highlighted line 2 is used to configure Frame Relay encapsulation on the attachment circuit interface.

Following the encapsulation frame-relay command is the frame-relay interface-type [dte | dte | nni] command. In this example, the interface type is configured as User-to-Network Interface (UNI) data circuit terminating equipment (DCE) using the dce parameter. The dte and nni parameters can be used to configure the UNI data terminal equipment and Network-to-Network Interface (NNI) interface types, respectively.

After the encapsulation and interface type have been configured, the next step is to bind the attachment circuit to the AToM pseudowire using the connect and xconnect commands.

The connect connection_name interface dlci l2transport command in highlighted line 4 configures a locally significant connection name (FR.DLCI.To.DLCI, in this example) and associates that name with an attachment circuit interface (serial 2/1) and DLCI (100).

In highlighted line 5, the xconnect peer-pe-ip-address pwid encapsulation mpls command is used to bind the attachment circuit to a pseudowire to 10.1.1.2 (San.Jose.PE), with PW (VC) ID 1010, using MPLS (AToM) encapsulation.

The configuration of San.Jose.PE (highlighted lines 6 to 10) is similar to that for Los.Angeles.PE. The only differences are the interface name and IP address specified using the connect and xconnect commands.

The connect connection_name interface dlci l2transport command in highlighted line 9 is used to specify the connection name FR.DLCI.To.DLCI, interface serial 1/1, and DLCI 100.

In highlighted line 10, the xconnect command binds the attachment circuit interface (serial 1/1) to a pseudowire to 10.1.1.1 (Los.Angeles.PE), with PW (VC) ID 1010, using MPLS encapsulation.

One thing to note about the configurations of peer PE routers with Frame Relay DLCI-to-DLCI switching is that it is possible for different Frame Relay encapsulation types (Cisco or IETF RFC 1490) and LMI types (Cisco, ANSI, or ITU Q.933a) to be used at either end of the pseudowire.

To verify Frame Relay DLCI-to-DLCI AToM pseudowires, you can use the show mpls l2transport vc vcid command (see Example 3-16).

Example 3-16. Verifying Frame Relay DLCI-to-DLCI AToM Pseudowires Using the show mpls l2transport vc Command

The highlighted line shows that a Frame Relay pseudowire with VC (PW) ID 1010 to 10.1.1.1 (the peer PE router) is in an UP state. This pseudowire is associated with local interface serial 1/1 and Frame Relay DLCI 100.

Using AToM Pseudowires to Transport ATM Traffic

There are a number of different methods of transporting ATM traffic over MPLS networks:

• ATM port mode cell relay In this case, all ATM cells received on an attachment circuit are transport over the same pseudowire, irrespective of the values contained within the Virtual Path Indicator (VPI) or Virtual Channel Identifier (VCI) fields of the ATM headers (see Figure 2-26 on page 68).

  The AToM pseudowire type corresponding to ATM port mode cell relay is 0x0003 (see Table 3-2 on page 147).

• ATM n-to-one cell relay In this mode, one or more ATM Virtual Circuit Connections (VCC) or Virtual Path Connections (VPC) are transported over the same pseudowire, as follows:
  - ATM VCC mode n-to-one cell relay Cells corresponding to one or more VCCs are switched over the same pseudowire.

   

  An ATM VCC is an ATM connection where cells are switched based on the values contained in the VPI and VCI fields of the ATM cell header.

  The AToM pseudowire type corresponding to ATM VCC mode n-to-one cell relay is 0x0009.

  - ATM VPC mode n-to-one cell relay Cells corresponding to one or more VPCs are transported over the same AToM pseudowire.

   

  An ATM VPC is an ATM connection where ATM cells are switched based on the value contained in the VPI field of the ATM cell header.

  The pseudowire type corresponding to ATM VPC mode n-to-one cell relay is 0x000A.

• ATM one-to-one cell relay In this case, one ATM VCC or VPC is transport over a pseudowire.
• ATM AAL5 SDU mode The ingress PE router reassembles ATM Adaption Layer 5 Common Part Convergence Sublayer Service Data Unit (AAL5 CPCS-SDU, see Figure 2-27 on page 71) before transmitting them over the pseudowire in this mode.

  The pseudowire type for ATM AAL5 SDU mode is 0x0002.

• ATM AAL5 PDU mode The ingress PE router assembles the AAL5 Protocol Data Unit (PDU) before transmitting it over the pseudowire.

Note

An important consideration when deploying AToM pseudowires for ATM traffic transport is OAM. As with L2TPv3 pseudowires, there are two methods of handling OAM cells: OAM cells can either be transported transparently over the pseudowire or terminated on the PE routers (if the oam-ac emulation-enable is configured).

For more information on the considerations for OAM, see the note in the section from Chapter 2 titled "Operations, Administration, and Management (OAM)" on page 71. OAM considerations for AToM pseudowires are the same as those described in Chapter 2.

Figure 3-28 illustrates the (optional) control word that is used with ATM transport.

Figure 3-28. (Optional) Control Word Used with ATM Transport

The fields of the control word are as follows:

• 4 bits set to zero These bits indicate pseudowire data.
• Flags The significance of these bits is dependent on the particular transport type (see subsequent sections for details).
• Res These bits are reserved for future use.
• Length This field reflects the length of the packet if the packet length (payload, plus the control word) is less than 64 bytes. If the length is not less than 64 bytes, this field contains a value of 0.
• Sequence Number This field contains a sequence number if sequencing is enabled for the pseudowire.

The specifics of ATM port mode and n-to-one cell relay, as well as AAL5 SDU mode transport over AToM pseudowires are discussed in the following two sections.

ATM Cell Relay

As already mentioned, there are two basic methods of transporting ATM cells over an AToM pseudowire:

• ATM port mode cell relay
• ATM VCC or VPC n-to-one cell relay

The sections that follow cover each method in more detail.

ATM Port Mode Cell Relay Transport over AToM Pseudowires

In ATM port mode cell relay, ATM cells received on the attachment circuit are transported over the pseudowire, without regard to the VCC or VPC to which they correspond (there is no match on the VPI or VCI fields in the ATM cell header).

Figure 3-29 depicts ATM port mode cell relay.

Figure 3-29. ATM Port Mode Cell Relay

As illustrated in Figure 3-29, when an ATM cell is received on the attachment circuit, it is placed in the payload of an AToM data channel packet that includes one or more tunnel labels, a PW (VC) label, and optionally a control word.

It is worth pointing out that the ATM cell with the exception of the Header Error Control (HEC) field (see Figure 2-26 on page 68) is carried in the AToM data channel packet.

Figure 3-30 shows a sample topology that illustrates ATM port mode cell relay pseudowire transport between two PE routers.

Figure 3-30. ATM Port Mode Cell Relay Pseudowire Transport Between Two PE Routers

Example 3-17 shows the configuration of ATM port mode cell relay.

Example 3-17. Configuration of ATM Port Mode Cell Relay

The first thing that you will notice about the configurations shown in Example 3-17 is their relative simplicitywith the exception of Steps 1 to 6 described in the section titled "AToM Pseudowire Ethernet Port Transport" earlier in this chapter, the only command required is the xconnect command under the ATM interface.

In highlighted line 1, the xconnect peer-pe-ip-address pwid encapsulation mpls command binds the attachment circuit to a pseudowire to 10.1.1.2 (San.Jose.PE), with PW (VC) ID 1015, using MPLS encapsulation.

The xconnect command in highlighted line 2 binds the attachment circuit to a pseudowire to 10.1.1.1 (Los.Angeles.PE), with PW (VC) ID 1015, using MPLS encapsulation.

As shown in Example 3-18, after the pseudowire has been established, you can verify its operation using the show mpls l2transport vc vcid command.

Example 3-18. Verifying ATM Port Mode Cell Relay

You can see that an ATM port mode cell relay AToM pseudowire with VC (PW) ID 1015 is configured to peer PE router 10.1.1.1. This pseudowire is associated with local attachment circuit interface ATM1/0, and it is in an UP state.

ATM n-to-One Cell Relay Transport over AToM Pseudowires

There are two methods of configuring VCC and VPC n-to-one cell relay transport:

• Single cell relay This method allows the encapsulation of a single ATM cell in each AToM data channel packet as it is transmitted over the pseudowire.
• Packed cell relay (cell packing) This allows the encapsulation of multiple ATM cells in each AToM data channel packet.

The sections that follow examine both methods in greater detail.

VCC and VPC N-to-One Cell Relay Transport with Single Cell Relay

Figure 3-31 illustrates ATM VCC and VPC single cell relay.

Figure 3-31. ATM VCC and VPC Single Cell Relay

Figure 3-32 illustrates the AToM data channel packet format when using single cell relay.

Figure 3-32. AToM Data Plan Packet Format When Using Single Cell Relay

In Figure 3-32, the AToM data channel packet consists of a tunnel label, a PW (VC) label, the control word (see Figure 3-28), and an ATM cell (VPI, VCI, PTI, C [CLP] bit, and ATM cell payload).

Note that although Figure 3-32 shows only one tunnel label, in reality (depending on the precise configuration) there may be more than one tunnel label.

VCC and VPC N-to-One Cell Relay Transport with Packed Cell Relay

Figure 3-33 illustrates the encapsulation of multiple ATM cells in an AToM data channel packet by the ingress PE router (packed cell relay).

Figure 3-33. Encapsulation of Multiple ATM Cells by the Ingress PE Router (Packed Cell Relay)

In Figure 3-33, a number of ATM cells are packed into the payload of a single AToM data channel packet.

Figure 3-34 illustrates the precise format of an AToM data channel packet when using ATM N-to-one packed cell relay.

Figure 3-34. AToM Packet Format When Using Packed Cell Relay

The AToM packet shown in Figure 3-34 is the same as that shown in Figure 3-32, with the exception that multiple ATM cells are carried in the payload (two ATM cells, in this example).

That is the theorynow on to configuration.

Deploying ATM VCC N-to-One Cell Relay

Example 3-19 shows the configuration of ATM VCC n-to-one single cell relay. Figure 3-35 shows the corresponding network topology.

Figure 3-35. ATM VCC N-to-One Cell Relay: Network Topology

Example 3-19. Configuration of ATM VCC N-to-One Single Cell Relay

You can see the configuration of Los.Angeles.PE in highlighted lines 1 to 3, and the configuration of San.Jose.PE in highlighted lines 4 to 6.

The pvc vpi/vci l2transport command in highlighted line 1 specifies the VCI and VPI for the PVC (1 and 100, in this example), and configures the PVC as a PVC that will be switched to an AToM pseudowire.

In highlighted line 2, the encapsulation aal0 command configures AAL0 encapsulation (cell relay).

Finally, the xconnect peer-ip-address vcid encapsulation mpls command in highlighted line 3 binds the PVC to a pseudowire to 10.1.1.2 (San.Jose.PE), with PW (VC) ID 1020, using MPLS encapsulation.

The configuration of San.Jose.PE is almost the same, with the only difference being the PE router IP address specified using the xconnect peer-ip-address vcid encapsulation mpls command.

The xconnect command on San.Jose.PE is used to bind the PVC to a pseudowire to Los.Angeles.PE (10.1.1.1), with PW (VC) ID 1020, using MPLS encapsulation.

Example 3-20 shows the configuration of ATM VCC n-to-one packed cell relay.

Example 3-20. Configuration of ATM VCC N-to-One Packed Cell Relay

The only differences between the configurations for packed cell relay shown in Example 3-20 and those for single cell relay in Example 3-19 are the atm mcpt-timers and cell-packing commands.

The atm mcpt-timers [timeout-value-1 timeout-value-2 timeout-value-3] command in highlighted lines 1 and 3 configures three maximum cell packing timeouts. These timeouts specify the maximum time that an ingress PE router will wait for ATM cells (to be packed into an AToM data channel packet [see Figure 3-33]) before sending the AToM data channel packet.

The cell-packing [cells] [mcpt-timer timer] command in highlighted lines 2 and 4 enables cell packing, and specifies the maximum number of cells that can be packed into a single AToM data channel packet (specified using the cells parameter), as well as to specify one of the three timeouts configured using the atm mcpt-timers command (specified using the timer parameter).

In the configurations shown in Example 3-20, the cell-packing command specifies a maximum of three cells, as well as a maximum cell packing timeout of 100 microseconds (the first timeout specified using the atm mcpt-timers command).

This particular configuration means that the ingress PE router will pack a maximum of three ATM cells in a single AToM data channel packet, but will wait no more than 100 microseconds to receive these three cells. If three cells are not received in these 100 microseconds, the ingress PE router will transmit the AToM data channel packet with however many ATM cells have been received.

As shown in Example 3-21, you can verify ATM VCC n-to-one cell relay using the show mpls l2transport vc vcid command.

Example 3-21. Verifying ATM VCC N-to-One Cell Relay Using the show mpls l2transport vc Command

The highlighted line in Example 3-21 shows that an ATM VCC cell relay pseudowire has been set up to the peer PE router (10.1.1.1) with VC (PW) ID 1020. This pseudowire is associated with interface ATM1/0.100, and it is active (UP).

It is also possible to check packed cell relay using the show atm cell-packing command (see Example 3-22).

Example 3-22. Verifying ATM VCC N-to-One Packed Cell Relay Using the show atm cell-packing Command

The highlighted line in Example 3-22 shows the maximum number of cells that can be packed into a single AToM data channel packet on the local and peer PE routers (local MNCP/peer MNCP), the average number of cells that have been sent and received in one AToM data channel packet, and the maximum cell-packing timeout (MCPT).

Deploying ATM VPC N-to-One Cell Relay

In Example 3-23, you can find the configuration of ATM VPC n-to-one single cell relay. Figure 3-36 shows the corresponding network topology.

Figure 3-36. ATM VPC N-to-One Cell Relay: Network Topology

Example 3-23. Configuration of ATM VPC N-to-One Single Cell Relay

The first command in Example 3-23 is atm pvp vpi l2transport (highlighted lines 1 and 3). This command specifies that the Permanent Virtual Path (Connection) in question will be bound to a pseudowire. In this example, the PVP has a VPI of 20.

The second command is xconnect peer-ip-address vcid encapsulation mpls. In highlighted line 2, this command is used to bind the attachment circuit (PVP with VPI 20) to a pseudowire to San.Jose.PE (10.1.1.2), with PW (VC) ID 1030, using MPLS encapsulation.

The xconnect command is also used in highlighted line 4 to bind the attachment circuit on San.Jose.PE (PVP with VPI 20) to a pseudowire to Los.Angeles.PE (10.1.1.2), with PW (VC) ID 1030, using MPLS encapsulation.

Configuration of ATM VPC n-to-one packed cell relay takes advantage of the same command as ATM VCC n-to-one packed cell relay (see Example 3-24).

Example 3-24. Configuration of ATM VPC N-to-One Packed Cell Relay

In this example, the atm mcpt-timers command (highlighted lines 1 and 3) is used to configure timeouts of 200, 300, and 400 microseconds.

The cell-packing command specifies a maximum of 5 ATM cells in a single AToM data channel packet, and indicates a maximum timeout of 300 microseconds (the second timeout configured using the atm mcpt-timers command).

See the previous section for more information on the atm mcpt-timers and cell-packing commands.

Verification of ATM VPC n-to-one cell relay can begin with the show mpls l2transport vc vcid command (see Example 3-25).

Example 3-25. Verification of ATM VPC N-to-One Cell Relay Using the show mpls l2transport vc Command

The highlighted line in the output of the show mpls l2transport vc vcid command shows that attachment circuit interface ATM 1/0 and VPC with VPI 20 is bound to a pseudowire to peer PE router 10.1.1.1. This pseudowire has a VC (PW) ID of 1030, and its status is UP.