EE6364

Multi-Protocol Label Switching (MPLS)

MPLS Terminology
MPLS Forwarding Component
MPLS Control Components
RSVP-TE
LDP
MPLS Fast Re-Route
Pseudo-Wire Emulation

DCW MPLS-1
EE6364

Introduction1

In the connection-oriented protocol, users and the network negotiate

the QoS during the call setup process. For example, in the ATM
connection admission control (CAC) process, the users include the
traffic descriptor and QoS requests in the SETUP messages sent to
the network. Based on the traffic descriptor and the QoS requested,
the network can either accept or reject the connection request. If the
connection request is accepted, a virtual circuit is established and a
corresponding VPI/VCI is assigned to the virtual circuit. The network
reserves resources (e.g., bandwidth and buffer) for as long as this
virtual circuit exists. For each ATM cell received, the switch examines
the VPI/VCI to identify the virtual circuit and the QoS requested, and
handles the cell accordingly. Each switch switches the ATM cell
received by comparing the VPI/VCI with the entries in the switch
routing table. The switching process is relatively simple.

IP traffic is connectionless. Routers route the IP packets based on the

destination IP addresses. The forwarding decision is made on a hop-
by-hop basis. No connection set up is needed. Thus, the routers can
not reserve bandwidth for a session. In addition, the TOS field in the
IP packet header is not supported by many routers. Thus, there is no
QoS support in the IP networks. Each router routes the packet
received by matching the destination IP address with the entries in
the routing table using the longest prefix matching algorithm. This
switching process is more complicated, and could cause longer
delay.

Multiprotocol label switching (MPLS) introduces the connection-

oriented paradigm into the IP traffic flow. With MPLS, IP packets are
routed based on a fixed-length short label, similar to the ATMs
VPI/VCI and frame relays DLCI.

1 E. Rosen, A. Viswanathan, R. Callon, Multiprotocol Label Switching Architecture, RFC

3031, January, 2001.
E. Rosen, et. al., MPLS Label Stack Encoding, RFC 3032, January, 2001.

DCW MPLS-2
EE6364

MPLS Terminologies:

1. MPLS Node:
A node which is running MPLS. It is aware of MPLS control
protocols and is capable of forwarding packets based on labels.
2. MPLS Domain:
A contiguous set of nodes which operate MPLS routing and
forwarding, and which are under one administrative domain.
3. Forward Equivalence Class (FEC):
A group of IP packets that are forwarded in the same manner
(e.g., forwarded to the same next hop, treated with the same
priority).
4. Label:
A short fixed length identifier which is carried by a packet and is
used to identify a FEC, usually of local significance.
5. Shim:
A space in a packet between the layer2 and layer 3 headers. A
label is encoded in the shim.
6. Labeled Packet
A packet into which a label has been encoded.
7. Label Switch Router (LSR):
An MPLS node which is capable of forwarding layer 3 packets. A
LSR can be at the ingress or egress of the MPLS domain, or at
the core of the domain. If a LSR is in the core of the MPLS
domain. It routes the packet based on the label and swap the
label before the packet is sent to the output port of the node. If a
LSR is at the ingress or egress of the MPLS domain. It generates
a label in the ingress, and removes the label at the egress.
8. Label Swapping:
The operation consisting of looking up an incoming label to
determine the outing label, encapsulation, output port, and other
data handling information.
9. Label Switched Path (LSP):
A sequence of LSRs that is to be followed by a packet.
10. Label Stack:
An order set of labels.
11. Label Binding:
The process that two MPLS nodes agree on the assignment of a
label to a FEC.

DCW MPLS-3
EE6364

MPLS Forwarding Components

MPLS involves (1) control component, and (2) packet forwarding

component. The control component includes label binding between
MPLS nodes, and the establishment of a forwarding table. The
packet forwarding component includes table look-up, label swapping
and forwarding of the packet from the input port to the output port.

Label

MPLS is layer 2 independent. The link layer can be ATM, frame relay,
Ethernet MAC layer, or PPP. If ATM is used as the data link layer, the
label is the ATM VPI/VCI. If frame relay is used, the label is the DLCI.
In these two data link layers, the label is located in the link layer
header. If other data link layer is used, the label will be place in a
shim, which is located between the layer2 and layer 3 headers. The
MPLS label is four octets long. The position and the format of the
label are as follows:
L2 Header Shim L3 Header Data

Label Value Exp S TTL

Bits 20 3 1 8

In the above figure,

Label Value: Values 0 to 15 are reserved.
Exp: Experimental use (3 bits); can be used for Classes of
Service.
S: Bottom of stack. This bit is set to one for the last entry in
the label stack.
TTL: Time to live. It is used to prevent looping.

A packet with a label is called a labeled packet. A normal IP packet

without MPLS label is called an un-labeled packet. If a labeled packet
is encapsulated by the PPP header, the protocol number in the PPP
header is 0X0281 for unicast and 0X0283 for multicast MPLS. If a

DCW MPLS-4
EE6364

labeled packet is encapsulated by the Ethernet MAC layer header,

the Ether type in the MAC layer header is 0X8847 for unicast and
0X8848 for multicast.

MPLS Packet Forwarding

An example of a MPLS network is shown in the following:

R3

R2 R6
A LSR
HEWLETT
Vectra
Office
PACKARD

R1
LSR LSR
2 R4 Edge
Edge
LSR
LSR R7
1 3
LSR MPLS C
4
Domain
Edge R5 HEWLETT
Vectra
Office
PACKARD

LSR
B

HEWLETT
Vectra
Office
PACKARD

In this network, R1, R5 and R7 are edge LSRs. The edge LSRs can
be ingress or egress. When hosts in network A are sending packets
to network C, R1 is the ingress LSR, and R7 egress LSR. However, if
hosts in network C are sending packets to network A, R1 becomes
the egress LSR, and R7 ingress LSR. The ingress LSR will push the
label, LSRs in the core network will swap the label, and the egress
LSR will pop the label.

When a host in network A send an IP packet to a host in network C, it

send an un-labeled packet (i.e., an IP packet encapsulated in the
Ethernet frame without the label). The ingress LSR, R1, after
examining the destination IP address and other information in the
packet header, pushes a label into the packet and forwards the
labeled packet to the output port. Router R2, an LSR, receives the
labeled packet. It examines the label and performs a table loop-up at
the forwarding table to find the new label and the output port. R2 then

DCW MPLS-5
EE6364

swaps the old label with the new label and routed the new labeled
packet to the output port. Other LSRs will perform the same tasks.
The labeled packet will reach the egress LSR, R7. It then examines
the label and performs a table loop-up at the forwarding table to find
that the packet is to be sent to network C. It then removes the label
and sends an unlabelled packet to network C.

Penultimate Hop Popping

In the above example, the LSP includes <R1, R2, R3, R6, R7>,
where R1 and R7 are ingress and egress LSRs respectively. R6, the
LSR next to the egress LSR, is called the penultimate LSR. The
MPLS standard specifies that the label can be popped at the
penultimate LSR instead of the egress LSR. Label popping at the
penultimate LSR is called penultimate hop popping (PHP).

If label popping is done by the egress LSR, the egress LSR has to
perform two table look-ups: (1) one label forwarding table look up to
determine that it is the egress LSR and to pop the label, and (2) one
IP routing table look up to determine the output port. However, if the
penultimate LSR performs the label forwarding table look up and
determines that it is the penultimate LSR, it can then pop the label
and send an unlabelled packet to the egress LSR. The egress LSR
then is required to perform the IP routing table look up only.

Special labels are reserved between the penultimate LSR and the
egress LSR, so that the penultimate LSR can be informed that it is
the penultimate LSR in a LSP.

DCW MPLS-6
EE6364

Label Stack

The MPLS architecture allows a stack of labels to be pushed into a

packet. It is possible to have a packet with m labels (or m levels). An
unlabelled packet has empty label stack is also called with zero
depth. In a given MPLS domain, the label at the top of the stack
(called depth 1) is the only one that determines the forwarding
decision. The following figure illustrates the concept of label stack.

pop
push
MPLS Domain 1 pop
push
MPLS Domain 2

R1 R2 R3 R4 R5 R6
Depth 0 Depth 0
Depth 1 Depth 1
Depth 1
Depth 2 Depth 2

Two MPLS domains are involved in delivering packets from R1 to R6.

The actual physical path involves routers R1 to R6. However, for
domain 1, the LSP involves <R1, R2, R4, R5, R6>. For domain 2, the
LSP is <R2, R3, R4>.

When R1 receives an unlabeled packet destined to R6, it pushes a

label to the packet, and sends it to R2. R2 swaps the incoming label
with a label that was agreed upon by R4. R2 also pushed on a label
that was agreed upon by R3. Thus, there are two labels in the packet
sent to R3. (What are values of the s bits of these two labels?) R3
swaps the incoming top label with a label from R4. R4 pops the label
stack and replaces the remaining label with the label from R5. If no
PHP is performed, R5 swaps the incoming label with the label from
R6. The egress router R6 pops the label and forwards the unlabeled
packet.

Label stack is useful in supporting tunneling and transit routing

domains.

DCW MPLS-7
EE6364

MPLS Control Component

In the above example, we explain the forwarding component of

MPLS. We assume that LSPs have been established, labels have
been assigned, and forwarding tables have been built.

In MPLS, the decision to bind a particular label to a particular FEC is

made by the downstream LSR. Labels are downstream-assigned,
and label bindings are distributed in the downstream-to-upstream
direction.
The MPLS architecture allows an LSR to explicitly request, from its
next hop for a particular FEC, a label binding for that FEC. This is
called downstream-on-demand label distribution. The architecture
also allows an LSR to distribute binding to LSRs that have not
explicitly requested them. This is called downstream unsolicited
label distribution.

Label binding can be driven by control traffic or data traffic. Control

traffic driven label binding can be (1) topology driven or (2) request
driven. In topology driven label binding, labels are assigned in
response to normal processing of routing protocol control traffic. For
example, as an LSR processes OSPF updates, it makes change to
entries in the routing table and triggers label binding. In request
driven label binding, labels are assigned in response to the requests.
For example, as RSVP messages are processed, the LSR can make
changes to entries in its forwarding table and assign labels to the
entries.

In the data traffic driven label binding, the assignment and distribution
of labels are triggered when an LSR detects patterns in the traffic that
justify the use of labels. For example, in a FTP session, the LSR
identifies a sequence of packets being transferred, it then triggers the
label binding process to establish an LSP.

DCW MPLS-8
EE6364

The sequence of label binding from the egress LSR to the ingress
LSR establishes an LSP. Depending on the way the label binding is
triggered, there are several types of LSPs.

LSP

Static Dynamic (signaled)

(manually
provisioned)
Control Traffic Data Traffic
Driven Driven

Topology Request
Driven Driven

Label Distribution Protocols

RFC 3031, the MPLS Architecture RFC, does not specify a single
label distribution protocol. In fact, several label distribution protocols
are being standardized. Some existing protocols have been
extended, and new protocols have been defined. Examples of
existing protocols that are being extended are RSVP-TE2 and MPLS-
BGP3. A new protocol that has been defined is Label Distribution
Protocol 4(LDP).

2 D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow, RSVP-TE: Extensions

to RSVP for LSP Tunnels, RFC3209, December 2001.
3 Y. Rekhter, E. Rosen, Carrying Label Information in BGP-4, RFC 3107, May 2001.
4 L. Andersson, P. Doolan, N. Feldman, A. Fredette, B. Thomas, LDP Specification,
RFC3036, January 2001.

DCW MPLS-9
EE6364

RSVP-TE:

RSVP-TE (ReSerVation Protocol- Traffic Engineering) extends the

existing RSVP5 protocols by introducing new objects to its messages
and new values to the existing objects to perform label binding and
establish LSPs. RSVP is the protocol used by IntServ to provide QoS
for IP networks. It is used to reserve bandwidth along the path. RSVP
messages, such as PATH and RESV, are sent through the network
hop-by-hop directly over IP. The message is placed in the information
field of the IP datagram. The protocol number in the IP datagram is
set to 46. There will be more discussions on RSVP later in the
discussion of IP QoS.

The extension introduces new objects for RSVP. Examples of new

objects are: Label-Request in the Path message to indicate the
request of a label binding, Explicit-Route in the Path message to
specify a specific route to take, Record_Route in the Path or Resv
message to record the actual route, Label in the Resv message to list
the label to be used.
The RSVP-TE Path message format is as follows:

<Path Message> ::= <Common Header> [ <INTEGRITY> ]

<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <SESSION_ATTRIBUTE> ]
[ <POLICY_DATA> ... ]
<sender descriptor>

<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>

[ <ADSPEC> ]
[ <RECORD_ROUTE> ]

5 R. Braden, et. al., Integrated Services in the Internet Architecture: an Overview,

RFC1633, July, 1994.
R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin, Resource ReSerVation
Protocol (RSVP) -- Version 1 Functional Specification, RFC 2205, September 1997.
J. Wroclawski, The use of RSVP with IETF Integrated Services, RFC 2210, September
1997.

DCW MPLS-10
EE6364

The RSVP-TE Reserve message format is as follows:

<Resv Message> ::= <Common Header> [ <INTEGRITY> ]

<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <RESV_CONFIRM> ] [ <SCOPE> ]
[ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list>

<flow descriptor list> ::= <FF flow descriptor list>

| <SE flow descriptor>

<FF flow descriptor list> ::= <FLOWSPEC> <FILTER_SPEC>

<LABEL> [ <RECORD_ROUTE> ]
| <FF flow descriptor list>
<FF flow descriptor>

<FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>

[ <RECORD_ROUTE> ]

<SE flow descriptor> ::= <FLOWSPEC> <SE filter spec list>

<SE filter spec list> ::= <SE filter spec>

| <SE filter spec list> <SE filter spec>

<SE filter spec> ::= <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ]

Establishing a LSP using RSVP-TE:

To establish an LSP, the sender creates an RSVP Path message,

with a session type of LSP_TUNNEL_IPv4 or LSP_TUNNEL_IPv6,
and inserts a LABEL_REQUEST object into the Path message. The
LABEL_REQUEST object indicates that a label binding for this path is
requested and also provides an indication of the network layer
protocol that is to be carried over this path.

If the sender node has knowledge of a route that has high likelihood
of meeting the tunnel's QoS requirements, or that makes efficient use
of network resources, or that satisfies some policy criteria, the sender
can decide to use the route for some or all of its sessions. To do this,
the sender node adds an EXPLICIT_ROUTE object to the RSVP
Path message.

DCW MPLS-11
EE6364

Once the Path message with Label-Request object is received, the

nodes along the path will start label binding process.

The receiver node of a label-switched path responds to a

LABEL_REQUEST by including a LABEL object in its response, the
RSVP Resv message. The LABEL object is inserted in the filter spec
list immediately following the filter spec to which it pertains. The Resv
message is sent back upstream towards the sender, following the
path state created by the Path message, in reverse order.

Each node that receives a Resv message containing a LABEL object

uses that label for outgoing traffic associated with this LSP tunnel. If
the node is not the sender, it allocates a new label and places that
label in the corresponding LABEL object of the Resv message which
it sends upstream to the previous HOP. The label sent upstream in
the LABEL object is the label which this node will use to identify
incoming traffic associated with this LSP tunnel. This label also
serves as shorthand for the Filter Spec.

When the Resv message propagates upstream to the sender node, a

label-switched path is effectively established.

Ingress Egress
Edge LSR LSR LSR LSR Edge LSR

R1 R2 R3 R4 R5
Path
(Label- Path Path
Request) (Label- (Label- Path
Request) Request) (Label-
Request)
RESV
RESV (Label)
RESV (Label)
RESV (Label) ResvConf
(Label) ResvConf
ResvConf
ResvConf

DCW MPLS-12
 EE6364

Label Distribution Protocol (LDP)6:

LDP is a new protocol defined in RFC3036. This protocol is intended

to establish best-effort LSPs based on the routing topology. A newer
protocol, constrained-based routing LDP (CR-LDP), provides
extensions to LDP that are useful in establishing LSPs based on QoS
or other policies.

LDP has four categories of defined messages and one additional

category for vendor specific and experimental messages. These four
categories of defined messages are:

Type Description Transport

Protocol
Discovery To announce and maintain the presence of an UDP (port=
LSR in a network 646)
- Hello to be exchanged as part of discovery process
Session To establish, maintain and terminate sessions TCP
between LDP peers (port=646)
- Initialization to establish a session between two peers
- KeepAlive to inform and monitor the integrity of the
session
Advertisement To create, change and delete label mappings TCP
for FECs (port=646)
- Address to advertise the interface address to LDP peer
- Address Withdraw to withdraw the address previously sent
- Label mapping to advertise FEC-label bindings to the peer
- Label request to request a binding (mapping) for a FEC
- Label withdraw to signal the peer that the peer may not
continue to use specific label-FEC mapping
- Label release to notify a peer the label has been released
- Label abort request to abort a outstanding label request
Notification To provide advisory and error information TCP
(port=646)
- Notification to provide advisory and error information

6 L. Andersson, P. Doolan, N. Feldman, A. Fredette, B. Thomas , LDP Specification, RFC

3036, January 2001.

DCW MPLS-13
EE6364

LDP peers discover adjacent peers via Hello messages. An LSR

periodically send LDP Hello packets (using UDP) to the well-known
LDP discovery port for the all routers on this subnet group multicast
IP address (i.e., 224.0.0.2).

When a Hello message is received on an LDP-enabled interface, the

LSR establishes an adjacency. Each adjacent LSR starts the session
initiation process using TCP to establish an LDP session. Once an
LDP session is established for all peers along the path of an LSP,
LSP establishment can proceed.

LDP may be used to establish LSPs using downstream unsolicited or

downstream on-demand label distribution. The ingress LSR initiates
the label binding process by sending a Label-Request message to its
downstream LSR, which then sends a Label-Request message to its
downstream LSR. When a Label-Request message arrives at the
egress LSR, the egress LSR allocates a label and includes this label
in the Label-Mapping message it sends to its upstream LSR.

An intermediate LSR along the LSP receives a Label-Mapping

message and record the label into the forwarding table. It then
allocates a label and sends a Label-Mapping message to its
upstream LSR. When a Label-Mapping message reaches the ingress
LSR, the LSP is established.

Ingress Egress
Edge LSR LSR LSR LSR Edge LSR

R1 R2 R3 R4 R5
Label
Request Label
Label
Request Label
Request
Request
Label
Label Mapping
Label
Label Mapping
Mapping
Mapping

DCW MPLS-14
EE6364

RFC 32707 specifies the solution for supporting DiffServ behavior

aggregates over an MPLS network. Two types of MPLS LSPs have
been defined:

E-LSP (Exp-inferred-PHB-Scheduling-Class LSP)

The EXP field of the MPLS shim header is used by the LSR to
determine the PHB to be applied to the packet received. This
includes both the scheduling class and the dropping preference.

The mapping from the EXP field to the PHB for a given LSP is
either explicitly signaled at the label set-up or relies on a pre-
configured mapping.

L-LSP (Label-Only-Inferred-PHB-Scheduling-Class LSP)

The PHB scheduling class is inferred from the label. The EXP field
is used to indicate the packet dropping priority.

7 F. Le Faucheur, et. Al., Multi-Protocol Label Switching (MPLS) Support of

Differentiated Services, RFC 3270, May 2002.

DCW MPLS-15
EE6364

MPLS Fast-Reroute

To increase the network availability for MPLS networks, RFC 40908

defines RSVP-TE extensions to establish backup label-switched path
(LSP) tunnels for local repair of LSP tunnels. These mechanisms
enable the re-direction of traffic onto backup LSP tunnels in 10s of
milliseconds, in the event of a failure. This timing requirement can be
satisfied by computing and signaling backup LSP tunnels in advance
of failure and by re-directing traffic as close to the failure point as
possible. In this way, the time for redirection includes no path
computation and no signaling delays, and only includes delays to
detect failure and to propagate failure notification between LSRs.

Two methods are defined in RFC 4090. They are:

The one-to-one backup method.

The facility backup method.

Both methods can be used to protect links and nodes during network
failure.

One-to-One Backup Method

This method creates detour LSPs for each protected LSP at each
potential point of local repair. It allows for forwarding around the next
downstream node and link. With this method, each node along the
LSPs path creates an alternate LSP around the downstream node
and headed towards the egress node. During a failure, the label is
swapped and sent to the alternate path. No label stacking is needed.

The following figure shows the one-to-one backup protection. The

LSP path (R1-R6-R7-R5) is the primary path. Node R1 creates an
alternate path (R1-R4-R5) to protect failure of R6 or the connection
between R1 and R6. R6 creates an alternate path (R6-R4-R5) to
protect failure of R7 or the interface between R6 and R7. R7 creates
an alternate path (R7-R4-R5) to protect the failure of the interface
between R7 and R5. During a failure, the original label is swapped

8 P. Pan, G. Swallow, A. Atlas, Fast Reroute Extensions to RSVP-TE for LSP Tunnels,
RFC 4090, May 2005.

DCW MPLS-16
EE6364

and sent into the alternate path using the new label. No label stacking
is needed.
R2 R3

R1 R4 R5
Ingress Egress
Node Node

R6
R7

Facility Backup Method

It creates a bypass tunnel to protect a potential failure point; by taking

advantage of MPLS label stacking. This bypass tunnel can protect a
set of LSPs that have similar backup constraints.

The following figure illustrates the facility backup method for link
protection. Each node creates an alternate LSP around the
downstream link.
R2 R3

R1 R4 R5
Ingress Egress
Node Node

R6
R7

DCW MPLS-17
EE6364

In this method, the alternate LSP connects to the next downstream

node and allows for forwarding around the next downstream link. In
the above figure, the primary LSP path is (R1-R6-R7-R5). Each node,
R1, R6, and R7 creates an alternate LSP around the downstream
link. If the link between R1 and R6 fails, Node R1 pushes the primary
LSPs label to the bottom, and adds the label for the LSP (R1-R4-R6)
on the top. It then uses the LSP (R1-R4-R6) to reach R6.

The following figure illustrates the facility backup method for node
protection. Each node creates an alternate LSP around the
downstream node and the interconnecting link.

R2 R3

R1 R4 R5
Ingress Egress
Node Node

R6
R7

Extensions to RSVP-TE include:

Fast-reroute object: Included in the PATH message of the

protected LSP. This object signals the ingress nodes desire to
protect the LSP, and contains information to be used by each
node to establish the protected path.
Detour object: This object allows nodes along the detour path to
associate multiple detours with the same RSVP session. It
includes information about the detour ingress node and the node
which the detour is avoiding.

DCW MPLS-18
EE6364

Pseudo-Wire Emulation End-to-End (PWE3)

RFC 39859 specifies the architecture of pseudo-wire emulation end-

to-end (PWE3). PWE3 is a mechanism that emulates the essential
attributes of a telecommunications service (such as a TDM leased
line, ATM, Frame Relay, Ethernet) over a Packet Switched Network
(PSN), such as IP or MPLS network. It is intended to provide the
necessary functionality to emulate the wire with the required degree
of faithfulness for the given service definition. This wire is called
pseudo wire (PW).

The required functions of pseudo wires include encapsulating

service-specific bit streams, cells, or PDUs arriving at an ingress port,
carrying them across an IP path or MPLS tunnel, and decapsulating
service-specific bit streams, cells, or PDUs and transmitting them to
the customer. In some cases it is necessary to perform other
operations such as managing their timing and order, to emulate the
behavior and characteristics of the service to the required degree of
faithfulness.

The network reference model of PWE3 is shown in the following

figure.

Emulated Service

Pseudo Wire

PSN Tunnel
Attached Attached
Circuit Circuit
PE 1 PW 1 PE 2
CE 1 CE 2

PW 2

Packet Switched Network Native

Native Service
Service

9 S. Bryant, Ed., P. Pate, Ed., Pseudo Wire Emulation Edge-to-Edge (PWE3)

Architecture, RFC 3950, March 2005.

DCW MPLS-19
EE6364

Customer Edge (CE) Equipment is connected to the Provider Edge

(PE) device at the Packet Switched Network (PSN). The interface is
using native service, such as T1 lease line, ATM, Frame Relay or
Ethernet. The two PEs (PE1 and PE2) have to provide PWs on behalf
of their client CEs (CE1 and CE2) to enable the client CEs to
communicate over the PSN. A PSN tunnel is established to provide a
data path for the PW. The PW traffic is invisible to the PSN, and the
PSN is transparent to the CEs. Native data units (bits, cells, frame,
or packets) arrive via the attached circuits (AC), are encapsulated in
PW-Protocol Data Units (PW-PDU), and are carried across the
underlying network via the PSN tunnel. The PEs perform the
necessary encapsulation and decapsulation of PW-PDUs and handle
any other functions required by the PW service, such as sequencing
or timing. From the perspective of Customer Edge Equipment (CE),
the PW is characterized as an unshared link or circuit of the chosen
service.

PWs provide the following functions in order to emulate the behavior

and characteristics of the native service:

Encapsulation of service-specific PDUs or circuit data arriving

at the PE-bound port.
Carriage of the encapsulated data across a PSN tunnel.
Establishment of the PW, including the exchange and/or
distribution of the PW identifiers used by the PSN tunnel
endpoints.
Managing the signaling, timing, order, or other aspects of the
service at the boundaries of the PW.
Service-specific status and alarm management.

To achieve the above functionality, RFC 3950 defines a layer

approach for PWE3. This layer approach indicates the protocol layers
required and processing needed. The following figure shows the
protocol layering for PWE3.

DCW MPLS-20
EE6364

Payload

Encapsulation May be empty

PW Demultiplexer

PSN Convergence May be empty

PSN

Data Link

Physical

The payload (i.e., native service information, such as ATM cells,

Ethernet frames, etc.) is transported over the Encapsulation Layer.
The Encapsulation Layer carries any information, not already present
within the payload itself, that is needed by the PW CE-bound PE
interface to send the payload to the CE via the physical interface. If
no further information is needed in the payload itself, this layer is
empty. The Encapsulation Layer also provides support for real-time
processing, and if needed for sequencing.

The PW Demultiplexer layer provides the ability to deliver multiple

pseudo wires over a single PSN tunnel. It must be unique per tunnel
endpoint.

The PSN Convergence layer provides the enhancements needed to

make the PSN conform to the assumed PSN service requirement.
Therefore, this layer provides a consistent interface to the PW,
making the PW independent of the PSN type. If the PSN already
meets the service requirements, this layer is empty. The Data Link
layer is the data link layer that the PSN uses.

The following figure illustrates the general format for encapsulation of

native service payload over a PW over a PSN.

DCW MPLS-21
EE6364

bits
0 7 15 23 31

PSN Transport Header

Pseudo Wire Header

Native Service Control Word

Native Service Payload

The PSN Transport Header is used to transport the encapsulated

native service through the tunnel in the PSN. The Pseudo Wire
Header identifies the native service on the tunnel. The Control Word
is inserted before the Native Service Payload. It may contain a length
and sequence number in addition to certain control bits needed to
transport the native service.

If the PSN is a MPLS network, LDP or RSVP-TE can be used to set

up the MPLS tunnel. IETF is proposing enhancement to LDP10 to set
up the PWs within a tunnel. Thus, if the PSN is a MPLS network,
stacked labels are used. The outer label is the PSN Transport Header
and signifies the MPLS tunnel. It is used by the LSRs in the MPLS
network to forward the packets. The inner label is the Pseudo Wire
Header and is used by the PEs only to identify the PW. The egress
PE also examines the Native Service Control Word and processes
whatever information needed before transport the payload to the
corresponding CE.

10 L. Martini, ed. Pseudowire Setup and Maintenance Using LDP, RFC 4447, April, 2006.

DCW MPLS-22
 EE6364

The following shows the MPLS PW encapsulation of the PPP

packet11:
bits
0 7 15 23 31
Tunnel Label Exp 0 TTL MPLS Header

VC Label Exp 1 TTL Pseudo Wire Demultiplexer

0000 0000 Frg Length (6b) Sequence Number (16b) Control Word

PPP Frame
(Exclude flags, Address, Control fields, and FCS)

Where
Frg: 2-bit fragmentation field. Frg=00, if the entire (unfragmented)
payload is carried in a MPLS packet, Frg=01, the MPLS packet
carrying the first fragment, Frg=10, carrying the last fragment,
Frg=11, carrying the intermediate fragment.
Length: 6-bit length field. If the length of the payload is greater than
64, this field is set to zero.
Sequence number: 16 bit.

11. L. Martini, E. Rosen, G. Heron, A. Malis, Encapsulation Methods for Transport of PPP/High-
Level Data Link Control (HDLC) over MPLS Networks, RFC 4618, Sep. 2006.

DCW MPLS-23
EE6364

The following illustrates the MPLS PW encapsulation of a frame relay

frame12:
bits
0 7 15 23 31
Tunnel Label Exp 0 TTL MPLS Header

VC Label Exp 1 TTL Pseudo Wire Demultiplexer

0 0 0 0 F B D C Frg Length (6b) Sequence Number (16b) Control Word

Frame Relay Information Field

(Exclude flags, header, and FCS)

where
F: FECN bit
B: BECN bit
D: DE bit
C: C/R (Command/Response) bit

12
L. Martini, C. Kawa, A. Malis, Encapsulation Methods for Transport of Frame Relay over
Multiprotocol Label Switching (MPLS) Networks, RFC 4619, Sep. 2006.

DCW MPLS-24
EE6364

The following illustrates the MPLS PW encapsulation of an Ethernet

frame13:

bits
0 7 15 23 31
Tunnel Label Exp 0 TTL MPLS Header

VC Label Exp 1 TTL Pseudo Wire Demultiplexer

0000 Reserved Sequence Number (16b) Control Word

Ethernet Frame
(No preamble, SFD, and FCS)

13L. Martini, E. Rosen, N. El-Aawar, G. Heron, Encapsulation Methods for Transport of Ethernet
over MPLS Networks, RFC 4448, April 2006.

DCW MPLS-25
EE6364

An application of pseudowire using MPLS is the layer 2 virtual private

network (VPN)14. Layer 2 VPN is a layer 2 provider provisioned VPN
service that the service provider can offer to connect customers sites
using the service providers network. There are two kinds of layer 2
VPN service that a service provider can offer: (1) virtual private wire
service (VPWS), and (2) virtual private LAN service (VPLS).

Virtual Private Wire Service (VPWS)

In a VPWS, each pair of CE devices is connected by a point-to-point

virtual circuit. Forwarding of a frame from one CE device to another is
not affected by the content of the frame, but is fully determined by the
virtual circuit on which the frame is transmitted. The PE that receives
the frame acts as a virtual circuit switch.

This type of L2VPN has been available over ATM and Frame Relay
backbones. VPWS can been provided using MPLS pseudowire.

Virtual Private LAN Service (VPLS)

In a VPLS, each CE device has one or more LAN interfaces that are
connected to a service providers network, which functions as a
virtual backbone network. Two CEs are connected to the same virtual
backbone if and only if they are members of the same VPLS instance
(i.e., same VPN).

When a CE transmits a frame, the PE that receives it examines the

MAC destination address field in order to determine how to forward
the frame. Thus, the PE functions as a bridge. If a set of PEs support
a common VPLS instance, then there is an emulated LAN,
corresponding to that VPLS instance, to which each of those PE
bridges attaches (via an emulated interface). From the perspective of
a CE device, the virtual backbone is the set of PE bridges and the
emulated LAN on which they reside. Thus to a CE device, the LAN
that attaches it to the PE is extended transparently over the routed
MPLS and/or IP backbone.

14 L. Andersson, et.al., Framework for Layer 2 Virtual Private Networks (L2VPNs),

RFC 4664, September 2006.

DCW MPLS-26
EE6364

The PE bridge function treats the Emulated LAN as it would any other
LAN to which it has an interface. Forwarding decisions are made in
the manner that is normal for bridges, which is based on MAC Source
Address learning.

DCW MPLS-27