AToM Pseudowire Operation






AToM Pseudowire Operation

When deploying AToM, it is essential to understand how pseudowires are set up, and how frames, cells, or SDUs received on attachment circuits are transported over pseudowires.

Note

AToM pseudowires are sometimes referred to as Draft Martini pseudowires because the original Internet drafts that defined LDP-signaled MPLS pseudowires were draft-martini-l2circuit-encap-mpls ("Encapsulation Methods for Transport of Layer 2 Frames over IP and MPLS Networks") and draft-martini-l2circuit-trans-mpls ("Transport of Layer 2 Frames over MPLS").


There are two channels, or planes, of communication for AToM pseudowires:

  • The control channel LDP messages are used to set up, maintain, and tear down AToM pseudowires.

  • The data channel Frames, cells, or SDUs received on an attachment circuit are encapsulated and sent over the pseudowire to the peer PE router.

Figure illustrates overall packet formats for control channel and data channel packets used with AToM.

Packet Formats for Control Channel and Data Channel Packets Used with AToM


The sections that follow discuss control channel and data channel messages in more detail.

Control Channel Messages

As shown in Figure, an LDP message consists of the following elements:

  • An IP header and UDP or TCP header An LDP message is carried over either UDP or TCP, but in both cases, port 646 is used.

  • An LDP Protocol Data Unit (PDU) This consists of an LDP header, together with one or more LDP messages.

Figure shows the format of the LDP header.

LDP Header Format


The LDP header (Figure) consists of three fields:

- Version This specifies the version of LDP. At the time of this writing, there is only one version of LDP (version 1).

- PDU Length This is the length of the PDU, with the exception of the Version and PDU Length fields.

- LDP Identifier This field functions as a unique identifier of the label space of a Label Switching Router (LSR)/Provider Edge (PE) router. A label space is a pool of labels, and this pool can either be used for a particular interface or for a platform as a whole.

An LDP Identifier is 6 octets long, with the first 4 octets being a globally unique value (these 4 octets often correspond to an IP address), and the last 2 octets identifying the label space of the LSR. If a platform-wide label space is used, the last 2 octets are 0.

Figure shows the LDP message format.

LDP Message Format


The LDP message format has the following fields:

  • U The Unknown message bit. This can be set either to 1 or 0.

  • Message Type The LDP message type. Figure shows possible LDP message types.

  • Message Length The length of the Message ID, Mandatory Parameters, and Optional Parameters fields.

  • Message ID This is an identifier for this message. This ID can be used in Notification messages to indicate the message to which they correspond.

  • Mandatory Parameters These are parameters that must be included with this message.

  • Optional Parameters These are parameters that may be included with this message.

LDP Message Types

LDP Message Type

Description

Notification

This message is used to inform a peer of a significant event, such as an error.

Hello

Hello messages are exchanged as part of the LDP discovery process.

Initialization

These messages are exchanged during LDP session initialization.

Keepalive

Keepalive messages are used to verify that an LDP session is active.

Address

An LSR uses this message to advertise its interface addresses.

Address Withdraw

Used to withdraw interfaces addresses previously advertised in an Address message.

Label Mapping

Used to advertise Forwarding Equivalence Class (FEC) to label bindings.

Label Request

This message is used to request label bindings from LDP peers.

Label Abort Request

This is used to abort a label request (requested using a Label Request message).

Label Withdraw

Used to withdraw a previously advertised label binding.

Label Release

Used to communicate the fact that the sender no longer requires a label binding (which has already been advertised by an LDP peer or requested by the local LSR).


As shown in Figure, there are 11 possible LDP message types. These message types fall into 4 categories:

  • Discovery messages These messages are used by an LSR to announce its presence to other LSRs, and once announced, maintain that presence.

  • Session messages Session messages are used by LSRs to establish, maintain, and tear down LDP sessions.

  • Advertisement messages Advertisement messages are used to distribute, modify, and delete label bindings.

  • Error messages These messages are used to signal error information.

LDP discovery messages are sent over UDP (see Figure), but all other types of messages are sent over TCP.

Now that you are familiar with the overall LDP message format, it is time to take a look at AToM pseudowire setup, maintenance, and teardown.

AToM Pseudowire Setup

As previously mentioned, AToM uses LDP to set up, maintain, and tear down pseudowires.

Figure illustrates AToM pseudowire setup.

AToM Pseudowire Setup


As you can see in Figure, AToM pseudowire setup consists of three steps:

Step 1.
LDP discovery

Step 2.
LDP session initialization (and establishment)

Step 3.
LDP Label Mapping message (pseudowire [VC] label bindings) exchange

LDP discovery consists of the exchange of Hello messages between the peer PE routers (the pseudowire endpoints). These Hello messages serve to make the PE routers aware of each other's existence.

LDP discovery can be performed in two different ways:

  • Basic discovery This is performed between directly connected peers (at the data link layer), and uses the all routers on this subnet multicast address of 224.0.0.2.

  • Extended discovery Extended discovery uses unicast (targeted Hello) transmission between peers.

In the case of LDP discovery between AToM PE routers, extended discovery is used because the peers are typically not directly connected.

In Figure, you can see LDP extended discovery between peer Cisco PE routers.

LDP Extended Discovery Between Peer Cisco PE Routers

San.Jose.PE#show mpls ldp discovery detail
 Local LDP Identifier:
    10.1.1.2:0
    Discovery Sources:
    Interfaces:
       Serial4/0 (ldp): xmit/recv
       Hello interval: 5000 ms; Transport IP addr: 10.1.1.2
       LDP Id: 10.1.1.4:0
        Src IP addr: 10.4.1.1; Transport IP addr: 10.1.1.4
        Hold time: 15 sec; Proposed local/peer: 15/15 sec
 Targeted Hellos: (line 1)
     10.1.1.2 -> 10.1.1.1 (ldp): active/passive, xmit/recv (line 2)
        Hello interval: 10000 ms; Transport IP addr: 10.1.1.2
        LDP Id: 10.1.1.1:0
         Src IP addr: 10.1.1.1; Transport IP addr: 10.1.1.1
         Hold time: 90 sec; Proposed local/peer: 90/90 sec
San.Jose.PE#

In highlighted lines 1 and 2, you can see that targeted LDP Hellos have been exchanged between the local PE router (10.1.1.2) and the remote PE router (10.1.1.1). This exchange of targeted Hellos is the basis of LDP extended discovery. Note that detailed, step-by-step information on verifying and troubleshooting AToM-based L2VPNs can be found in Troubleshooting Virtual Private Networks by Mark Lewis (Cisco Press).

After the PE routers are aware of each other, they can establish a transport connection and begin LDP session initialization.

During the session initialization process, the PE routers negotiate session parameters such as LDP version, label distribution method, and timers. After the initialization process is finished, an LDP session is established between the PE routers, and they are considered to be LDP peers.

You can use show mpls ldp neighbor neighbor-ip-address detail to examine LDP session information on Cisco PE routers, as demonstrated in Figure.

Examining LDP Session Information

San.Jose.PE#show mpls ldp neighbor 10.1.1.1 detail
    Peer LDP Ident: 10.1.1.1:0; Local LDP Ident 10.1.1.2:0 (line 1)
      TCP connection: 10.1.1.1.646 - 10.1.1.2.11008 (line 2)
      State: Oper; Msgs sent/rcvd: 18/19; Downstream; Last TIB rev sent 17 (line 3)
      Up time: 00:07:10; UID: 5; Peer Id 0; (line 4)
      LDP discovery sources:
       Targeted Hello 10.1.1.2 -> 10.1.1.1, active, passive;
        holdtime: infinite, hello interval: 10000 ms
      Addresses bound to peer LDP Ident:
       10.2.1.1 10.1.1.1
    Peer holdtime: 180000 ms; KA interval: 60000 ms; Peer state: estab
    Clients: Dir Adj Client
San.Jose.PE#

In Figure, highlighted line 1, you can see the remote and local PE routers' LDP (router) IDs (10.1.1.1:0 and 10.1.1.2:0 respectively).

Highlighted line 2 shows that the LDP session has been established over a TCP connection. The TCP ports that the remote and local PE routers have opened for this TCP connection are 646 and 11008.

Highlighted lines 3 and 4 shows the LDP session state (operational [established]), the number of messages sent and received (18 and 19), the method of label distribution (unsolicited downstream), and the session uptime (7 minutes, 10 seconds).

The next step is for the PE routers to exchange LDP Label Mapping messages. These messages contain the pseudowire label bindings consisting of a FEC Type-Length-Value (TLV) and a Generic Label TLV (plus zero or more optional TLVs).

Note

Note that after LDP discovery and session initialization have taken place between peer PE routers, any number of pseudowires can be set up by exchanging LDP Label Mapping messages.


It is a good idea to take a closer look at the exchange of LDP Label Mapping messages during AToM pseudowire setup. Remember that these messages contain FEC and Generic Label TLVs.

Figure depicts the FEC TLV.

FEC TLV


As shown in Figure, contents of the fields in the FEC TLV are as follows:

  • U and F The Unknown (U) and the Forward unknown (F) bits are both set to 0.

  • Type This is set to a value of 0x0100, indicating that this is an FEC TLV.

  • Length Indicates the length of the Value field (the FEC elements) in octets.

  • Value In the case of an FEC TLV, the Value field contains one or more FEC elements. In the case of LDP Label Mapping messages used with AToM, however, only one FEC element is included in an FEC TLV (the specific type of FEC element is discussed later in this section).

Note

Note that the format of the FEC TLV (U and F bits; Type, Length, and Value fields) is common to all LDP TLVs.


Figure illustrates the Generic Label TLV.

Generic Label TLV


The Generic Label TLV can be described as follows:

  • U and F bits Both of these must be set to 0.

  • Type This field contains the value 0x0200, which indicates that this is a Generic Label FEC.

  • Length This indicates the length of the Value field.

  • Value This field contains a label. In the case of a pseudowire Label Mapping message, this field contains a PW (VC) label.

So far so goodan LDP Label Mapping message includes FEC and Generic Label TLVs. But what about the FEC element that is included in the FEC TLV (see Figure)? As previously mentioned, only one FEC element (called a pseudowire [PW] ID FEC element) is included when an LDP Label Mapping message is used with AToM, as illustrated in Figure.

PW (VC) ID FEC Element


The PW ID FEC element consists of the following fields:

  • PW (VC) TLV This field contains the value of 128, indicating that this is a PW ID FEC element.

  • C bit This bit indicates whether a control word will be used with this pseudowire (will be included in pseudowire data channel packets [see Figure]). If the C bit is set to 1, a control word will be used; if the C bit is set to 0, a control word will not be used.

  • PW (VC) Type This indicates the pseudowire type as listed Figure.

    MPLS Pseudowire Types

    Pseudowire (PW/VC) Type

    Description

    0x0001

    Frame Relay DLCI (Martini mode)

    0x0002

    ATM AAL5 SDU VCC transport

    0x0003

    ATM transparent cell transport

    0x0004

    Ethernet Tagged mode

    0x0005

    Ethernet

    0x0006

    High-Level Data Link Control (HDLC)

    0x0007

    PPP

    0x0008

    Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) Circuit Emulation Service over MPLS (CEM)

    0x0009

    ATM n-to-1 VCC cell transport

    0x000A

    ATM n-to-1 VPC cell transport

    0x000B

    IP Layer 2 Transport

    0x000C

    ATM 1-to-1 VCC Cell mode

    0x000D

    ATM 1-to-1 VPC Cell mode

    0x000E

    ATM AAL5 PDU VCC transport

    0x000F

    Frame Relay port mode

    0x0010

    SONET/SDH Circuit Emulation over Packet (CEP)

    0x0011

    Structure-agnostic E1 over Packet (SAToP)

    0x0012

    Structure-agnostic T1 (DS1) over Packet (SAToP)

    0x0013

    Structure-agnostic E3 over Packet (SAToP)

    0x0014

    Structure-agnostic T3 (DS3) over Packet (SAToP)

    0x0015

    CESoPSN basic mode

    0x0016

    TDMoIP AAL1 mode

    0x0017

    CESoPSN TDM with CAS

    0x0018

    TDMoIP AAL2 mode

    0x0019

    Frame Relay DLCI


  • PW (VC) Info Length This field specifies the length of the PW ID and Interface Parameters fields (in octets).

  • Group ID The Group ID field contains a value that is used to represent a group of pseudowires.

    The Group ID can be used to group a number of pseudowires on an interface or virtual tunnel and can, for example, be useful when a PE router needs to withdraw labels for a number of pseudowires associated with a particular interface, or send a notification message that applies to a number of pseudowires associated with a particular interface.

  • PW (VC) ID This, together with the PW type, uniquely identifies an AToM pseudowire.

  • Interface Parameters This field is used to signal attachment circuit interface parameters such as maximum transmission unit (MTU) and interface description string.

Figure shows the format of the Interface Parameters field contained in the PW ID FEC element (also see Figure).

Interface Parameters Field


The components of the Interface Parameters field can be described as follows:

- Parameter ID Identifies the type of interface parameter (interface MTU, description, and so on) contained in the Variable Length Value field.

- Length Specifies the overall length of the Interface Parameters field, including Parameter ID and Length.

- Variable Length Value Contains the actual data, whether the interface MTU, the interface description, or other interface parameter.

If you are a little confused about how all of these TLVs, FEC elements, and Interface Parameters fields fit together, take a look at Figure.

Interrelationship Between FEC/Generic Label TLVs, PW ID FEC Element, and Interface Parameters Field


As shown in Figure, the LDP PDU consists of the following:

  • An LDP header.

  • An LDP message, which in this case is a Label Mapping message. The LDP Label Mapping message comprises the following:

    - An FEC TLV

    - A Generic Label TLV

Although not shown in Figure, the Label Mapping message may also contain zero or more optional parameter TLVs.

Finally, the FEC TLV contains a PW ID FEC element in its Interface Parameters field.

Figure shows the exchange of PW (VC) labels between peer Cisco PE routers.

Exchange of PW (VC) Labels Between Peer PE Routers

San.Jose.PE#debug mpls l2transport signaling message
AToM LDP message debugging is on
San.Jose.PE#
*May 26 20:34:21.555: %LDP-5-NBRCHG: LDP Neighbor 10.1.1.1:0 is UP (line 1)
*May 26 20:34:21.555: AToM LDP [10.1.1.1]: Sending label mapping msg (line 2)
 vc type 6, cbit 1, vc id 1001, group id 0, vc label 21, status 0, mtu 1500 (line 3)
*May 26 20:34:21.835: AToM LDP [10.1.1.1]: Received label mapping msg, id 99 (line 4)
 vc type 6, cbit 1, vc id 1001, group id 3, vc label 21, status 0, mtu 1500 (line 5)
San.Jose.PE#

As you can see in Figure, the LDP session has been established (highlighted line 1), and label bindings have been sent and received (highlighted lines 2 and 3).

A closer look at highlighted lines 2 and 3 shows some of the information contained in the PW (VC) ID FEC element (see Figure), such as the following:

  • The VC (PW) type (6, see Figure)

  • The C bit setting

  • The VC (PW) ID (1001)

  • The Group ID (0)

  • The VC (PW) label (21), status (0), and (attachment circuit) interface MTU (1500 bytes)

You can also view AToM label bindings using the show mpls l2transport binding command.

Note

The debug mpls l2transport signaling message command is used here for illustrative purposes only. Exercise caution when using debug commands because they can disrupt the operation of heavily loaded routers.


So that is pseudowire setupnow on to pseudowire status signaling.

AToM Status Signaling

LDP is not only used to setup pseudowires, it can also be used to signal pseudowire status. This can be important if, for example, one PE router wants to signal its peer PE router that its attachment circuit has changed state.

If a PE router wants to signal attachment circuit status changes to its peer PE router, it can use two different methods:

  • It can send an LDP Label Withdraw message.

  • It can send an LDP Notification message.

Signaling Attachment Circuit Status Changes with an LDP Label Withdraw Message

The LDP Label Withdraw message can be used to signal circuit down status.

Figure shows the signaling of circuit down status using the LDP Label Withdraw message.

Signaling Circuit Down Status Using the LDP Withdraw Message


Figure shows the LDP Label Withdraw message being used to signal attachment circuit status between peer Cisco PE routers.

LDP Label Withdraw Message Being Used to Signal Pseudowire Status Between Peer Cisco PE Routers

San.Jose.PE#debug mpls l2transport signaling message
AToM LDP message debugging is on
San.Jose.PE#
*May 26 21:48:54.279: AToM LDP [10.1.1.1]: Received label withdraw msg, id 279 (line 1)
  vc type 6, cbit 1, vc id 1001, group id 3, vc label 21, status 0, mtu 0 (line 2)
San.Jose.PE#

Highlighted line 1 shows that the local PE router has received an LDP Label Withdraw message from the remote PE router indicating an attachment circuit status change.

Signaling Attachment Circuit Status Changes with an LDP Notification Message

This alternative (and relatively recent) method of signaling status must be negotiated when LDP Label Mapping messages are exchanged during pseudowire setup (see Figure).

If the PE router initiating pseudowire setup supports status signaling using the LDP Notification message, it includes a PW Status TLV along with the FEC and Generic Label TLVs in the LDP Label Mapping message.

If the peer PE router also supports status signaling using the LDP Notification message, it also includes a PW Status TLV in the LDP Label Mapping message that it sends. If, on the other hand, either peer PE router does not include the PW Status TLV in the LDP Label Mapping message that it sends, both peer PE routers revert to using LDP Label Withdraw messages to signal status.

Figure shows the format of the LDP Notification message used to signal pseudowire status.

Format of the LDP Notification Message Used to Signal Status


The key fields to notice in the LDP Notification message are the Status and PW Status TLVs, as well as the PW ID FEC element (see also Figure). Note that the PW ID FEC element does not include the Interface Parameters field when carried in the LDP Notification message.

A status code that indicates the status of the pseudowire is carried in the PW Status TLV. The PW ID FEC element is carried in the LDP Notification message to indicate the ID of the pseudowire (PW ID) or group (Group ID) to which the status code corresponds.

Figure shows possible PW status codes that can be carried in the PW Status TLV in the LDP Notification message.

Possible PW Status Codes Carried in the PW Status TLV

(PW) Status Code

Description

0x00000000

Pseudowire forwarding (clear all failures)

0x00000001

Pseudowire not forwarding

0x00000002

Local attachment circuit (ingress) receive fault

0x00000004

Local attachment circuit (egress)transmit fault

0x00000008

Local PSN-facing PW (ingress) receive fault

0x00000010

Local PSN-facing PW (egress) transmit fault


As you can see in Figure, the PW Status TLV can be used to signal a number of statuses. So, signaling pseudowire status using the LDP Notification message (including a PW Status TLV) is more flexible than signaling pseudowire status using the LDP Label Withdraw message because the LDP Label Withdraw message can only be used to signal attachment circuit down status.

Figure illustrates negotiation of pseudowire status signaling (with the LDP Notification message) during LDP Label Mapping message exchange.

Negotiation of Pseudowire Status Signaling (with the LDP Notification Message) During LDP Label Mapping Message Exchange


In Figure, both peer PE routers include the PW Status TLV in the LDP Label Mapping messages that they send, and this results in the PE routers using the LDP Notification message to signal pseudowire status.

Figure shows the signaling of pseudowire status using the LDP Notification message.

Signaling Pseudowire Status Using the LDP Notification Message


AToM Data Channel Packet Forwarding

The overall format of AToM data channel packets is shown in Figure on page 139. As you can see, the packet format consists of the following:

  • One or more tunnel labels These tunnel labels can be advertised between adjacent PE and P routers (LSRs) using LDP, TDP, or RSVP-TE. Note, however, that the use of the Cisco-proprietary Tag Distribution Protocol (TDP) is now deprecated in MPLS networks.

  • A PW label This is also referred to as the VC label and serves as a demultiplexor that ensures that data channel packets are correctly associated with an attachment circuit.

    The PW label serves the same purpose as the session header (session ID and optional cookie) does with L2TPv3 pseudowires.

  • An optional control word This performs the same function as the service-specific sublayer with L2TPv3 pseudowires.

The PW label and the presence (or otherwise) of a control word are advertised in LDP Label Mapping messages exchanged during pseudowire setup.

Figure depicts the transmission of AToM data channel packets.

Transmission of AToM Data Channel Packets


Figure shows the transport of a AToM data channel packet across the MPLS backbone network between Los.Angeles.PE to San.Jose.PE (see the lower half of the figure), but it also shows how control channel packets (see the upper half of the figure) influence the form of data channel packets.

If you take a close look at Figure, you can see that the following events occur:

Step 1.
San.Jose.PE advertises a (tunnel) label (3 [implicit-null]) corresponding to its IP address (10.1.1.2) to Los.Angeles.P using LDP.

Similarly, Los.Angeles.P advertises a (tunnel) label (200) corresponding to San.Jose.PE's IP address (10.1.1.2) to Los.Angeles.PE.

Step 2.
San.Jose.PE sends an LDP Label Mapping message to Los.Angeles.PE. This message includes an FEC TLV (Figure) and a Generic Label TLV (Figure).

The FEC TLV includes a PW ID FEC element (Figure), with the C bit set to 1, the PW Type specified as High-Level Data Link Control (HDLC), the PW (VC) ID set to 1001, and the Interface Parameters, which specify an attachment circuit MTU of 1500.

The Generic Label TLV specifies a label value of 100 (this is the PW label).

Although not explicitly shown in Figure, Los.Angeles.PE also sends an LDP Label Mapping message to San.Jose.PE, and the pseudowire has been established.

Step 3.
Los.Angeles.PE now receives an HDLC frame on the attachment circuit connected to mjlnet.Los.Angeles.CE.

Step 4.
Los.Angeles.PE encapsulates the HDLC with a control word (this is included because the C bit was set to 1 in the PW ID FEC element in the LDP Label Mapping message in Step 2), a PW (VC) label (100, which was included in the Generic Label FEC in the LDP Label Mapping message sent in Step 2), and a tunnel label (200, which was received from Los.Angeles.P in Step 1). The purpose of the tunnel label is to transport the encapsulated frame to the egress PE router, which in this case is San.Jose.PE.

Los.Angeles.PE then sends the encapsulated HDLC frame to Los.Angeles.P.

Note that by default a control word is not required with an HDLC pseudowire. A control word is required only if sequencing is configured. Configuration of sequencing is discussed later in this chapter.

Step 5.
Los.Angeles.P pops the tunnel label because the outgoing label (3, implicit-null) indicates that the egress PE router is the next hop (so, Los.Angeles.P performs a penultimate hop pop [PHP]).

Los.Angeles.P now forwards the encapsulated HDLC frame to San.Jose.PE.

Step 6.
San.Jose.PE receives the encapsulated HDLC frame, and removes the PW (VC) label and the control word. The PW (VC) label indicates the local attachment circuit on which the encapsulated HDLC frame should be forwarded, and so San.Jose.PE then sends the HDLC frame to mjlnet.San.Jose.CE.

That is AToM data channel packet forwarding from Los.Angeles.PE to San.Jose.PE. Data channel packet forwarding from San.Jose.PE to Los.Angeles.PE happens in exactly the same manner, just in the opposite direction.

Now that you understand the background to AToM pseudowire operation, it is time to move on to AToM configuration.



 Python   SQL   Java   php   Perl 
 game development   web development   internet   *nix   graphics   hardware 
 telecommunications   C++ 
 Flash   Active Directory   Windows