Download as ppt, pdf, or txt
Download as ppt, pdf, or txt
You are on page 1of 52

Any Transport over MPLS

Overview

AToM is a pseudowire emulation


application that is part of the Unified VPN
Suite Solution that Cisco offers to transport
Layer 2 traffic over an MPLS network.
AToM is capable of interconnecting
disparate Layer 2 protocols through Layer
2 interworking.
An AToM pseudowire is made of a pair of
MPLS label-switched paths (LSP).
Because an MPLS LSP is inherently
unidirectional, to have bidirectional
connectivity, a pseudowire is formed by
establishing two LSPs in the opposite
directions
AToM utilizes targeted LDP sessions
between PE routers to exchange MPLS
labels that are used for pseudowires.
Using Label Stacking in AToM

One common technique that many MPLS


applications utilize is label stacking.
The semantics of labels in a label stack
might vary from one MPLS application to
another.
in MPLS traffic engineering, the top label
in the label stack represents the traffic-
engineered path, and the bottom label
represents the original Interior Gateway
Protocol (IGP) path.
In MPLS Layer 3 VPN, the top label in the
label stack represents the IGP path to the
next-hop Border Gateway Protocol (BGP)
router, which is normally the PE router that
originates the VPN routes. The bottom
label represents a specific or aggregated
VPN route.
In Layer 2 VPN, the LDP top label usually
represents the IGP path to the peering PE
router, and the bottom label represents a
Layer 2 VPN forwarder on the peering PE
router.
The top label is usually known as the
tunnel label or the IGP label. The bottom
label is usually known as the VC label or
the pseudowire label. The optional control
word is not part of the MPLS label stack,
but pseudowire encapsulation.
AToM takes advantage of routing protocols
to dynamically set up virtual paths across
the core network. Only PE routers need to
maintain and manage the pseudowire
labels for the virtual connections.
The pseudowire labels are at the bottom of
the label stack, so they are not visible to
the transit routers, also known as the
Provider (P) routers. The P routers forward
packets using the top label and are
unaware of the existence of pseudowires.
Many pseudowires can be multiplexed in a
single MPLS tunnel LSP. In such a way,
the core network is spared from managing
and maintaining forwarding information
for each pseudowire
Layer 2 Protocols Supported by
AToM

AToM supports a wide range of Layer 2


protocols, including PPP, High-Level Data
Link Control (HDLC), Ethernet, Frame
Relay, and ATM.
Two types of Ethernet frames are supported
in Ethernet over MPLS:
Untagged Ethernet frames
IEEE 802.1q tagged Ethernet VLAN
frames
PE routers classify Ethernet frames that are
received from CE routers into different
pseudowires based on the receiving
interface or the VLAN tag carried in the
Ethernet VLAN frames.
Deciding Whether to Use AToM

When determining whether AToM is the right


choice for your company, you need to consider
several factors, including the following:
Existing network installation base
Advanced network services
Interoperability
Network operation complexity
Advanced Network Services
Besides the basic MPLS features such as
routing optimization and network
consolidation, AToM can leverage
advanced MPLS features for enhanced
network services, such as MPLS traffic
engineering, QoS guarantee, and fast
rerouting.
Another important advanced MPLS feature
that AToM can rely on is the ability to
reroute traffic to an alternate path in a short
period when a failure occurs along the
original path
MPLS fast rerouting constructs a
protection LSP in advance for a given link
by explicitly establishing an alternate path
that circumvents the possible failing link.
Because the alternate path is set up prior to
the link failure, rerouting can take place
rather quickly.
In Atom LDP sessions are established
through LDP extended discovery between
PE routers. These sessions are known as
targeted LDP sessions.
AToM Deployment Model
The following steps explain the procedures of
establishing an AToM pseudowire:
1. A pseudowire is provisioned with an
attachment circuit on PE1.

2. PE1 initiates a targeted LDP session to PE2 if


none already exists. Both PE routers receive LDP
Keepalive messages from each other and
complete the session establishment. They are
ready to exchange pseudowire label bindings.
3. When the attachment circuit state on PE1
transitions to up, PE1 allocates a local pseudowire
label corresponding to the pseudowire ID that is
provisioned for the pseudowire.

4. PE1 encodes the local pseudowire label into


the Label TLV and the pseudowire ID into the
FEC TLV. Then it sends this label binding to PE2
in a Label Mapping message.
5. PE1 receives a Label Mapping message
from PE2 and decodes the pseudowire
label and pseudowire ID from the Label
TLV and FEC TLV.

6. PE2 performs Steps 1 through 5


independently.
7. After PE1 and PE2 exchange the
pseudowire labels and validate interface
parameters for a particular pseudowire ID,
the pseudowire with that pseudowire ID is
considered established.
If one attachment circuit on one PE router
goes down, a Label Withdraw message is
sent to the peering PE router to withdraw
the pseudowire label that it previously
advertised.
MTU Size Requirements

Core MTU >= Edge MTU + 18 + 4 + (2 *


4)
Supported VC Types
EoMPLS can operate in two modes: port-
tunneling mode and VLAN-tunneling
mode. Port-tunneling is also referred to as
port-to-port transport.
VLAN-tunneled interfaces are VC type 4,
or, 0x0004, and port-tunneled interfaces
are VC type 5, or 0x0005 (as specified in
the draft-martini). Cisco devices support
both VC types.
The newest Cisco implementations provide
for auto-sensing of the VC type.
In VLAN-tunneling mode, the ingress
information for the VLAN is contained
within the dot1Q header of the packet.
"LAN Protocols," for more information on
dot1Q.) By looking at the VLAN ID in the
dot1Q header, the network processor (NP)
can determine the next step in processing,
described in the
In port-tunneling mode, the packet does
not have ingress port information. For
inclusion of ingress information, the port-
tunneled interface is put into the QinQ
mode.
A hidden VLAN is then created and added
onto the packet. A hidden VLAN is a
VLAN that is numbered outside the
allowed range for VLAN IDs. This is how
the NP learns the ingress information
In contrast, VLAN-tunneled mode does not
require a hidden VLAN. The NP can
discern the ingress information from the
packet's dot1Q header.
A similar concept applies to routers
(VLAN stacking method). It involves the
use of subinterfaces.
Another difference between the port-
tunneling mode and VLAN-tunneling
mode is in the handling of VLAN IDs.
In port-tunneling mode, the VLAN ID is
transparently passed from the ingress PE to
the egress PE over MPLS in a single
VLAN.
In VLAN-tunneling mode, however, the
VLAN ID at each end of the EoMPLS
tunnel can be different.
To overcome this, the egress side of the
tunnel that is mapped to a VLAN rewrites
the VLAN ID in outgoing dot1Q packets to
the ID of the local VLAN.
To impose labels on packets, the ingress PE
router maintains a table, which associates
an EoMPLS tunnel with an interface/FEC.
This table keeps the information needed
for sending the packet, such as the
outgoing interface and encapsulation.
Ethernet over MPLS

In Ethernet over MPLS environment,


Ethernet frames are exchanged between
customer sites using the SP backbone as
the medium of transport. Ethernet over
MPLS is implemented in two different
modes:
Port mode
VLAN mode
Router-Based Ethernet over MPLS
Port Mode

In port mode, the entire Ethernet frame


without the preamble or FCS is transported
as a single AToM packet.
In port mode, the interface uses VC type 5
or 0x0005.
Ethernet over MPLSPort Mode
Control and Data Plane EoMPLS
Port Mode
Router-Based Ethernet over MPLS
VLAN Mode
In the VLAN mode, PE devices do not
filter any frames based on the MAC
addresses. In other words, there is no
support for MAC layer address learning
and filtering. In EoMPLS, the Spanning-
Tree Protocol is not used, and BPDUs are
propagated transparently but not
processed.
Data Plane OperationEthernet
over MPLS: VLAN Mode
Router-Based EoMPLSVLAN
Rewrite

VLAN mapping does not have to be


consistent across sites to implement router-
based Ethernet over MPLS VLAN mode.

You might also like