Evolving to end-to-end

MPLS architectures
Seamless, scalable, resilient MPLS
for mission-critical networks

Technology white paper

Faced with ever-increasing bandwidth demands, operators of mission-critical

networks are compelled to expand network capacity while keeping costs down.
In response, many operators are implementing a network architecture that is
ready for service convergence.
A Seamless Multiprotocol Label Switching (MPLS) architecture provides the
required scalability and flexibility to meet evolving needs and support simple
and rapid service provisioning over a single, end-to-end network. This paper
reviews the requirements for and architecture of a Seamless MPLS network,
explains the Nokia toolkit for implementing end-to-end MPLS, and discusses
alternate interim options.

Technology white paper

Evolving to end-to-end MPLS architectures

Contents
MPLS: A proven technology

Why seamless MPLS?

Creating an end-to-end transport layer

Implementing services with seamless MPLS

Seamless MPLS end-to-end resiliency

Seamless MPLS OAM requirements

11

End-to-end MPLS deployment: Other alternatives

11

Conclusion 14
Acronyms 15

Technology white paper

Evolving to end-to-end MPLS architectures

MPLS: A proven technology

Operators of mission-critical networks in industries such as energy and
transportation as well as the public sector are faced with ever-increasing
bandwidth demands from new Ethernet- and IP-based applications. They also
need to deal with more data-intensive monitoring and supervisory control and
data acquisition (SCADA) devices, and the requirement to provide corporate
mobile devices for their personnel in the field. As a result, operators are
compelled to expand network capacitywhile keeping costs down.
Traditionally, operators have implemented separate networks for separate
services (for example, SCADA and video surveillance), which results in a suboptimal utilization of network resources. To optimize network utilization and
reduce CAPEX and OPEX, many network operators are implementing a network
architecture that is ready for service convergence.
When offering services over a single converged network, the end-to-end
network must be scalable, flexible to meet evolving needs, and able to
support simple and rapid service provisioning.
The proven ability of MPLS to work cohesively with IP and Ethernet makes
MPLS the preferred choice for implementing highly scalable end-to-end
networks. MPLS technology was initially implemented in service provider
core networks but has since been adopted by many mission-critical private
networks. Operators have successfully implemented architectures that
combine operational and corporate service, whether fixed or mobile, over
a single converged IP/MPLS core network.
The success of MPLS in core networks and the benefits it brings have paved
the way for the technology to be implemented in aggregation and access
networks as an alternative to SDH/SONET/PDH, ATM and legacy Ethernetbased aggregation.
While MPLS adoption continues to gain momentum, implementing
end-to-end MPLS networks presents some important considerations
for network operators.

Why seamless MPLS?

Extending MPLS from the core to aggregation and access requires designing
the network with a hierarchical domain architecture for current scalability and
future expansion of the network. However, this architecture can bring new
challenges in provisioning end-to-end service.
Figure 1 shows a reference customer network architecture for network
operators in industries such as energy and transportation as well as the public
sector. The main characteristics of this architecture are:
There are two or more central locations for hosting the network operations
centers (NOCs). For disaster recovery protection, they are usually from tens
to thousands of kilometers apart.
3

Technology white paper

Evolving to end-to-end MPLS architectures

 There are two main types of service traffic flow:

Hub-and-spoke type from remote location to central location crossing
domains; this traffic is designated as Flow A in Figure 1
Spoke-to-spoke type between neighboring remote locations; this traffic
typically stays within the domain and is designated as Flow B in Figure 1
Configuring and deploying flow type B is straightforward but doing the same
for flow type A requires additional provisioning at the intermediate point
(the aggregation location in Figure 1), including breaking the end-to-end
service into segments. Breaking the service into segments results in extra
troubleshooting and fault recovery considerations. However, a versatile and
powerful service-aware management system can, to a large degree, simplify
all these complexities for network operators, lessening the work required
by them.
Figure 1. A multi-domain network for converged services

Remote
location #1
B

Remote
location #2

Aggregation
location #1

Core
Domain

Central
location
NOC #1

Aggregation
Domains
Aggregation
location #2

Central
location
NOC #2

Remote
location #3

To address the challenges of extending MPLS, the Internet Engineering Task

Force (IETF) has developed the Seamless MPLS IETF draft (draft-ietf-mplsseamless-mpls), which proposes integrating core and aggregation domains
in a single MPLS domain. The draft, which has received strong support from
network operators and the IETF community, provides a robust framework that
enables network operators to deploy scalable and flexible end-to-end services
seamlessly in a multi-domain network.
Seamless MPLS has the following key attributes:
Scalability and resiliency: By leveraging an end-to-end control plane for
service provisioning, as explained later, edge nodes can scale in number
during deployment, enabling straightforward service provisioning with
strong resiliency.
4

Technology white paper

Evolving to end-to-end MPLS architectures

 A single end-to-end MPLS domain: Seamless MPLS extends the core domain
and integrates aggregation domains into a single MPLS domain. This single
domain enables more efficient management and troubleshooting of the
transport and services layers.
A network without boundaries (seamless): Seamless MPLS allows MPLSbased services to be established between any two endpoints without
per-service configuration in intermediate nodes at aggregation locations.
Rapid fault detection and recovery: Seamless MPLS supports end-to-end
fault detection, fast protection and end-to-end operations, administration
and maintenance (OAM) functions.
Decoupling of transport layer from services: Seamless MPLS allows services
to be provisioned wherever they are needed, regardless of the architecture
of the underlying transport layer. This is achieved by implementing a
three-label hierarchy consisting of a transport layer and a services layer
(see Figure 2).
Figure 2. Decoupling transport layer from services

MPLS
Aggregation
Domain

MPLS
Core
Domain

Service label (PW, VC label)

Tranport Layer

Inter-area/AS label (BGP label)

Intra-area/AS label (LDP/RSVP)
End-to-end seamless MPLS network using Label BGP

Creating an end-to-end transport layer

As shown in Figure 3, a Seamless MPLS network consists of multiple domains.
In this paper, a core domain and an aggregation domain are used for
illustration.
With other end-to-end MPLS options (for example, end-to-end Label
Distribution Protocol [LDP] in a flat network), Interior Gateway Protocol (IGP)
or MPLS signaling information is not contained in the domain and is exchanged
across domains. This increases the size of IP routing/forwarding tables as well
as the MPLS label forwarding information base (LFIB) in each router, making it
difficult to scale the network.
Seamless MPLS transport consists of an inter-domain tunnel and an intradomain tunnel.

Technology white paper

Evolving to end-to-end MPLS architectures

Inter-domain BGP transport tunnel

The use of an inter-domain transport tunnel can minimize scaling constraints
on routing nodes in the end-to-end network. This requires controlling how
reachability information is propagated across domain boundaries.
Each domain communicates using end-to-end transport tunnels configured
according to RFC 3107 (carrying label information using the Border Gateway
Protocol [BGP]). BGP was built to handle boundary control and is therefore
the best choice to create the inter-domain transport tunnel.
RFC 31071 specifies how the label mapping information for a particular route
is piggybacked in the same BGP update message used to distribute the route
itself by using the Multiprotocol Extensions attribute specified in RFC 2283
(hence called MP-BGP4). MP-BGP4 can be used to distribute a particular route
and the MPLS label mapped to it. In the rest of the paper, MP-BGP4 will be just
referred as BGP for simplicity.
Figure 3. Creating an end-to-end transport layer using Seamless MPLS
ABR-11
(RR)

PE-11

iBGP
PE-12

IP/MPLS
Aggregation
Domain

P1
(RR)

PE-21
Central
location
NOC #1

iBGP
IP/MPLS
Core Domain

iBGP

Inter-area/AS label (BGP label)

ABR-12
(RR)

Intra-area/AS label (LDP/RSVP)

ABR-22

PE-22
Central
location
NOC #2

RR = Route Reector (BGP)

Single end-to-end MPLS domain

A domain can represent an Open Shortest Path First (OSPF) area, an

Intermediate System-to-Intermediate System (IS-IS) level, an OSPF/IS-IS
instance or even a BGP autonomous system (AS). The Area Border Router
(ABR) nodes act as Route Reflectors (RRs) for the domain and act as RR
clients of the core RRs (P1 in Figure 3).
The network represents an inter-area scenario and therefore uses internal
Border Gateway Protocol (iBGP) between RRs and RR clients which are
Provider Edge (PE) routers, whose. loopback addresses and label bindings
are advertised by iBGP to other BGP peers by the RR.
1 RFC3107: http://tools.ietf.org/html/rfc3107

Technology white paper

Evolving to end-to-end MPLS architectures

Figure 3 shows two inter-domain transport tunnels:

Inter-domain tunnel between PE-11 and PE-21
Inter-domain tunnel between PE-12 and PE-22
These tunnels provide the PE-to-PE reachability across domains and also
provide the inner tunnel label of the transport layer hierarchy. For Tunnel 1
(PE11 to PE21), the ABR nodes (ABR-11 and ABR-12) receive from PE21 the
loopback address and label, then subsequently advertise these to PE11 with
next-hop self.
When initially configured, BGP tunnels are established automatically between
all PE nodes in the end-to-end network; this includes tunnels between PE nodes
in domains as well as tunnels between PE nodes across domains. Often, BGP
tunnel connectivity may not be required between all PE nodes.
A key benefit of the BGP-based approach is the ability to use BGP filtering
policies based on IPv4 prefixes or BGP communities to limit (permit/deny)
propagating loopback reachability to different parts of the network on an asneeded basis. These policies can be optionally configured on specific nodes
in the network to prevent loopback propagation (and therefore no BGP tunnel
creation beyond that point).

Intra-domain LDP/RSVP-TE transport tunnel

The intra-domain transport tunnel provides transport for inter-domain BGP
tunnels in each domain by providing the outer tunnel label of the transport
layer hierarchy. An intra-domain tunnel, established by LDP or Resource
Reservation Protocol (RSVP) with Traffic Engineering (RSVP-TE), switches the
packet between the PE and its BGP peer, the RR (which is also the BGP next hop).

Implementing services with seamless MPLS

As described in the previous section, initial configuration creates the interdomain tunnels between PE nodes and the intra-domain tunnels between BGP
peers. These two types of tunnels form the transport layer of the hierarchy.
Once the transport layer is created, services can now be provisioned end-to-end.
Figure 4 shows two service examples:
A Layer 2 Virtual Leased Line (VLL) service (also called pseudowire [PW])
between PE-11 and PE-21. This service can be offered across Domain 1 and
Domain 2 between a remote station and the central control station for a
SCADA application. The service label for the VLL is created using targeted
LDP (T-LDP) between PE-11 and PE-21.
A Layer 3 IP-VPN service between PE-12 and PE-22. This can be an IP-based
LAN application. The service label for the IP-VPN service is created using
multiprotocol BGP (MP-BGP) for IP-VPN between PE-12 and PE-22.

Technology white paper

Evolving to end-to-end MPLS architectures

Figure 4. Implementing services using MPLS

P1
(RR)

ABR-11
(RR)

PE-11
VLL

VLL
iBGP
IP/MPLS
Aggregation
Domain

PE-12

PE-21
Central
location
NOC #1

iBGP
IP/MPLS
Core Domain

iBGP

IP-VPN

IP-VPN
ABR-12
(RR)

Service label (PW, VC label)

ABR-22

Inter-area/AS label (BGP label)

PE-22
Central
location
NOC #2

Intra-area/AS label (LDP/RSVP)

RR = Route Reector (BGP)
Single end-to-end MPLS domain

Decoupling the transport and services layers within the Seamless MPLS
framework allows services to be provisioned wherever they are needed,
independent of the underlying transport layer. As more services are required
between PE-11 and PE-21 or PE12 and PE-22, only T-LDP and MP-BGP4 are
used to signal new service label to create new service binding directly between
them. There is no involvement of the transport tunnel and intermediate
nodes, including the RR.

Seamless MPLS end-to-end resiliency

As shown in Figure 5, Seamless MPLS provides end-to-end resiliency at both
the transport and services layers. The framework supports PW redundancy at
the services layer. The transport layer supports protection of the inter-domain
transport tunnel (BGP tunnel) as well as the intra-domain transport tunnel
(MPLS tunnel).
During failures, this architecture ensures that local MPLS Fast Re-route
protection is initiated when end-to-end protocol convergence occurs,
which eventually results in a new set of BGP transport tunnels being
created end-to-end.

Technology white paper

Evolving to end-to-end MPLS architectures

Figure 5. End-to-end resiliency with Seamless MPLS

Service
level

PW redundancy

Transport
level

BGP FRR (Edge PIC)

BGP FRR (Edge PIC)

MPLS FRR

MPLS FRR
P1
ABR-11
(RR)

PE-11
VLL

VLL
iBGP
IP/MPLS
Aggregation
Domain

PE-12

PE-21
Central
location
NOC #1

iBGP
IP/MPLS
Core Domain

iBGP

IP-VPN

IP-VPN
ABR-12
(RR)

Service label (PW, VC label)

Inter-area/AS label (BGP label)

ABR-22

PE-22
Central
location
NOC #2

Intra-area/AS label (LDP/RSVP)

RR = Route Reector (BGP)
Single end-to-end MPLS domain

Service layer redundancy

In most circumstances, the PW is protected through the transport tunnel
redundancy mechanism of MPLS. For example, if the tunnel is an RSVP-TE
established label-switched path (LSP) and is protected by a secondary standby
path and/or by Fast-Reroute (FRR) paths, the PW is also protected. LDP LSP is
protected by LDP ECMP in a similar way.
There are, however, some scenarios in which tunnel redundancy does not
protect the end-to-end PW path, such as when the peer PE or the network
link to a single-homed PE fails. To cover such failure scenarios, customer
equipment (CE) can dual-home to two PEs. With this CE dual-homing topology,
pseudowire redundancy allows PWs to be protected with a second preprovisioned PW on the second peer PE. In the event of first peer PE failure,
traffic is switched over to the standby PW on the second PE, and delivered
to the customer equipment.

Technology white paper

Evolving to end-to-end MPLS architectures

Transport layer redundancy: Inter-domain tunnel

Inter-domain transport layer redundancy is supported using BGP Fast
Reroute (BGP FRR) and/or an egress node BGP FRR mechanism.
BGP FRR (also called Edge Prefix Independent Convergence [Edge PIC) is a
feature that brings together indirection techniques in the forwarding plane
and pre-computation of BGP backup paths in the control plane to support
fast reroute of BGP tunnel traffic around unreachable/failed next-hops.
When BGP FRR is enabled, the control plane attempts to find an eligible
backup path for every received IP prefix, depending on configuration. When
BGP decides that a primary path is no longer usable (detected, for example,
using next-hop tracking or Bidirectional Forwarding Detection [BFD]),
the affected traffic is immediately switched to the backup path. Traffic
immediately fails over to the backup path without the need to wait for the
BGP decision process and Forwarding Information Base (FIB) updates: the
failover time and convergence are prefix independent.
In Figure 6, BGP FRR capability is enabled on PE1. An alternate BGP next-hop
(NH2 on PE3) is provided to the FIB in PE1 along with the primary (best) path
(NH1 on PE2).
PE1 groups route with the same next-hops in the FIB so that the time
to switch many routes to the backup path is independent of the number
of destination prefixes (prefix independent).
If node PE2 fails, traffic is switched to the backup path (NH2) by PE3.
NH1 unavailability can be detected by IGP or BFD mechanisms.
Figure 6. BGP FFR
PE2

PE1

iBGP
BGP
prexes
PE1

BGP NH1

IGP NH1

oif

BGP NH2

IGP NH2

oif

SET 1

iBGP

oif - outgoing interface

PE3

Transport layer redundancy: Intra-domain tunnel

Intra- domain transport layer redundancy is supported using MPLS FRR.
MPLS FRR, based on RSVP-TE and defined in RFC 40902, provides the ability
to pre-establish backup LSP tunnels for local LSP tunnel repair. This
mechanism enables the rapid switching of traffic onto backup LSP tunnels
after failure detection.
2 RFC4090: http://tools.ietf.org/html/rfc4090

10

Technology white paper

Evolving to end-to-end MPLS architectures

MPLS FRR can be accomplished using two methods, both of which can be used
to protect links and nodes during network failure:
The one-to-one backup method, which creates detour LSPs for each
protected LSP at each potential point of local repair
The facility backup method, which 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

Seamless MPLS OAM requirements

The Nokia end-to-end MPLS toolkit includes a comprehensive OAM suite
for MPLS tunnels and services. This includes LSP-level diagnostics, Ethernet
Connectivity Fault Management (CFM) and service diagnostics for Layer 2
and Layer 3 MPLS services. A Service Assurance Agent (SAA) allows service
providers to periodically configure a number of different tests to provide
performance information, such as delay, jitter and loss for services or network
segments. SAA functionality can be used in conjunction with the OAM suite
for performance monitoring.
The popular IP ping and trace route tools are not sufficient to provide
seamless MPLS OAM, and therefore need to be supplemented with diagnostics
specialized for the different levels in the service delivery model.
In accordance with RFC 64243 (Mechanism for performing LSP ping over MPLS
tunnels), the OAM suite must support methods for performing LSP ping and
trace over different MPLS tunnel types. In addition to the MPLS transport
tunnel with RSVP-TE or LDP, LSP ping and trace are now extended to cover
the BGP tunnel. When validating a BGP RFC 3107 label with LSP ping and trace,
it will be resolved to an RSVP or LDP LSP.
The end-to-end MPLS tool kit supports in-band, packet-based OAM tools
with the ability to test the transport and services layers in a seamless
MPLS network.

End-to-end MPLS deployment:

Other alternatives
This section provides a brief review of alternative approaches for deploying
end-to-end MPLS services along with the pros and cons of each approach.

Flat network using LDP

One way to extend an MPLS tunnel end-to-end is to implement a flat IP/
MPLS multi-area network using LDP. This network can be implemented with
IGP aggregate route leaking as defined in RFC 5283 (LDP extensions for inter
3

11

RFC 6424 http://tools.ietf.org/html/rfc6424

Technology white paper

Evolving to end-to-end MPLS architectures

area LSPs)4. RFC 5283 defines a new LDP label mapping procedure to support
setting up contiguous inter-area LSPs while maintaining IP prefix aggregation
on the ABR nodes.
This procedure is similar to the one defined in the LDP specification (RFC
5036) but performs an IP longest-match lookup when searching the Forward
Equivalence Class (FEC) element in the Routing Information Base (RIB).
Pros
LSP transport tunnels can be created endto-end.
Services can be deployed without provisioning intermediate points.
With prefix aggregation, leaking all the /32 FECs into the IGP area/level is
not required, thereby reducing routing table size.
Cons
If prefix aggregation (summarized entries) is not supported, the router table
sizes can become quite large, burdening router resources. In addition, large
tables take longer to converge and make troubleshooting complex.
Even if prefix aggregation is supported and IP Routing Information Base/
IP Forwarding Information Base (IP RIB/IP FIB) tables are reduced, Label
Forwarding Information Bases (LFIBs) are still flooded with all the /32 FECs
of the whole network, reducing the overall scalability and increasing the
complexity.
Reducing FEC distribution requires complex policies.

MPLS network using RSVP-TE

Another way to extend an MPLS tunnel is to set up inter-area LSP with
RSVP-TE. Because traffic engineering information carried in IGP cannot be
carried into an area, an end-to-end explicit route needs to be calculated
and specified.
Pros
LSP transport tunnels can be created endto-end.
Services can be deployed without provisioning intermediate points.
Cons
Router table sizes can become very large and the RSVP state needs to be
maintained, affecting performance when the network needs to be scaled.
Large routing tables burden routers, take longer to converge and make
troubleshooting complex.
Calculating many explicit routes is a laborious task.
Fast Re-Route cannot protect the ABR router.
4

12

RFC 5283 http://tools.ietf.org/html/rfc5283

Technology white paper

Evolving to end-to-end MPLS architectures

Pseudowire switching
Pseudowire switching (also called multi-segment PW) allows VLL services
to be scaled over a multi-area network by making a full mesh of TargetedLDP sessions between PE nodes unnecessary. The end-to-end segment is
split into multiple segments that are switched at switching points. PE nodes
that terminate the end-to-end service are referred to as T-PEs and the
intermediate PEs at the junctions of each segment are referred to as S-PEs.
The T-PE node acts as a master and the S-PE nodes act as slaves for PW
signaling. The S-PE waits for an LDP-mapping message from the T-PE. The
PW is signaled using T-LDP. Pseudowire switching limits the propagation of
/32 FECs; however PW switching requires provisioning at multiple points
(T-PE and S-PEs).
Pros
A full mesh of T-LDP sessions between PE nodes is not required.
Propagation of /32 FECs and router table size are limited.
Cons
You may need to provision intermediate points unless dynamic multisegment PW (draft-ietf-pwe3-dynamic-ms-pw) is deployed in every
T-PE and S-PE, which adds another layer of complexity.
End-to-end troubleshooting is more complex.
No L3 VPN is possible because only VLL services are supported.

Inter-AS options
RFC 4364 (BGP/MPLS IP VPNs)5 describes three options for supporting interAS IP-VPNs.
Option A uses back-to-back connections between the AS boundary router
(ASBR) nodes. This option does not support end-to-end MPLS and is only
suitable when the number of IP-VPNs is very small because the option
requires per-VPN configuration on ASBRs (that is, a sub-interface and external
BGP (eBGP) session is required for each IP-VPN).
Option B eliminates the need for per-VPN configuration on the ASBRs. The
ASBRs receive IP-VPN information from PEs in the local AS and forward this
information to their eBGP peer ASBRs. Each peer ASBR, in turn, forwards the
IP-VPN information to its local BGP peers in the remote AS. This option is
suitable for inter-AS IP-VPNs when working with different service providers
because all routes advertised between ASs can be controlled by routing
policies at the ASBR.
Option C is essentially the seamless MPLS approach to implementing interAS VPRNs. With Option C, VPN prefixes are neither held nor re-advertised by
5

13

RFC 4364 http://tools.ietf.org/html/rfc4364

Technology white paper

Evolving to end-to-end MPLS architectures

the ASBR. PEs in different ASs can establish multi-hop, multi-protocol eBGP
sessions with each other to exchange customer VPN prefixes. Together with
the inter- and intra-domain transport tunnels previously described, a threelevel label stack is formed, which is essentially the Seamless MPLS architecture
model.
The bottom-level label is assigned by the egress PE (advertised in multi-hop,
multi-protocol eBGP without next-hop override) and is commonly referred
to as the VPN label or service label. The middle label is assigned by the local
ASBR-PE and corresponds to the /32 route of the egress PE (in a different AS)
using BGP-LBL (RFC 3107, Carrying Label Information in BGP-4). The top-level
label is assigned by the local ASBR-PE(s)/32 loop-back address, which would
be assigned by the IGP next-hop of the ingress PE.
Option C allows for a higher scale of VPRNs across AS boundaries and also
expands the trust model between ASs. As a result, this model is typically
used within a single company that may have multiple ASs.

Conclusion
MPLS is the preferred technology to implement scalable networks for missioncritical networks as well as service provider networks carrying business,
residential and mobile services. Although several options and technologies can
be used to implement end-to-end MPLS networks, Seamless MPLS provides
maximum scalability, flexibility and ease of provisioning and maintenance.
Some networks may not be ready to implement Seamless MPLS architectures
immediately. Alternative approaches described at the end of this paper can
be considered as interim solutions to deploy end-to-end MPLS networks and
services. For a fully scalable and flexible solution, however, the Seamless MPLS
framework must be considered in the future.
Nokia, a leader in MPLS development and IP service routing, offers
a complete, comprehensive and industry-validated toolkit that enables
network operators to migrate to or implement new end-to-end MPLS
network architectures.

14

Technology white paper

Evolving to end-to-end MPLS architectures

Acronyms
ABR

Area Border Router

LSP

label-switched path

ATM

Asynchronous Transfer Mode

MP-BGP

Multiprotocol BGP

AS

autonomous system

MPLS

Multiprotocol Label Switching

ASBR

Autonomous System Boundary Router

NOC

network operations center

BFD

Bidirectional Forwarding Detection

OAM

operations, administration and maintenance

BGP

Border Gateway Protocol

OSPF

Open Shortest Path First

CFM

Connectivity Fault Management

PDH

Plesiochronous Digital Hierarchy

eBGP

external BGP

PE

Provider Edge

FEC

Forward Equivalence Class

PIC

Prefix-Independent Convergence

FIB

Forwarding Information Base

PW pseudowire

FRR

Fast Reroute

RIB

iBGP

internal Border Gateway Protocol

IETF

Internet Engineering Task Force

RSVP-TE Resource Reservation Protocol with Traffic

Engineering

IGP

Interior Gateway Protocol

IP

Internet Protocol

IP FIB

IP Forwarding Information Base

IP RIB

IP Routing Information Base

IS-IS Intermediate System-to-Intermediate

System

Routing Information Base

RR

Route Reflector

SAA

Service Assurance Agent

SCADA

supervisory control and data acquisition

SDH

Synchronous Digital Hierarchy

SONET

Synchronous Optical Networking

T-LDP

Targeted Label Distribution Protocol

Virtual Leased Line

LAN

Local Area Network

VLL

LDP

Label Distribution Protocol

LFIB

Label Forwarding Information Base

VPRN Virtual Private Routed Network

(also called IP-VPN)

Nokia is a registered trademark of Nokia Corporation. Other product and company names
mentioned herein may be trademarks or trade names of their respective owners.
Nokia Oyj
Karaportti 3
FI-02610 Espoo
Finland
Tel. +358 (0) 10 44 88 000
Product code: PR1605020293EN (July)

Nokia 2016

nokia.com