MPLS Applications Configuration Guide

Tellabs
8600 Managed Edge System

MPLS Applications Conguration Guide
50123_02
30.10.09
Document Information
Revision History
Document
No.
Date Description of Changes
50123_02 30.10.09 Added LSP afnity bits usage in 1.3 LSP Afnity Constraints.
Added FRR in 1.7 Fast Reroute.
One-to-one backup
Facility backup
FRR fault management
FRR CLI examples 2.5 FRR CLI Conguration Examples.
This manual documents the following network elements and the corresponding feature packs:
FP1.3 Tellabs 8605 access switch
FP1.0A Tellabs 8607 access switch
FP2.11 Tellabs 8620 access switch, Tellabs 8630 access switch, Tellabs 8660 edge switch
2009 Tellabs. All rights reserved.
This Tellabs manual is owned by Tellabs or its licensors and protected by U.S. and international copyright laws, conventions and
treaties. Your right to use this manual is subject to limitations and restrictions imposed by applicable licenses and copyright laws.
Unauthorized reproduction, modication, distribution, display or other use of this manual may result in criminal and civil penalties.
The following trademarks and service marks are owned by Tellabs Operations, Inc. or its afliates in the United States and/or
other countries: TELLABS
, TELLABS
logo, TELLABS and T symbol
, and T symbol
.
Any other company or product names may be trademarks of their respective companies.
The specications and information regarding the products in this manual are subject to change without notice. All statements,
information, and recommendations in this manual are believed to be accurate but are presented without warranty of any kind,
express or implied. Users must take full responsibility for their application of any products.
Adobe
Reader
are registered trademarks of Adobe Systems Incorporated in the United States and/or other countries.
Tellabs
8600 Managed Edge System 50123_02

MPLS Applications Conguration Guide 2009 Tellabs.
2
Terms and Abbreviations
Term Explanation
ATM Asynchronous Transfer Mode
BA Behavior Aggregate
BC Bandwidth Constraint
BD Business Data
BE Best Effort
BFD Bidirectional Forwarding Detection
BGP Border Gateway Protocol
CAC Connection Admission Control
CLI Command Line Interface
CS Class Selector
CSPF Constrained Shortest Path First
CT Class Type
DSCP DiffServ Code Point
DS-TE Differentiated Services-aware MPLS Trafc Engineering
E-LSP EXP-Inferred-PSC LSP
ERO Explicit Route Object
FFD Fast Failure Detection
FM Fault Management
FR Frame Relay
FRR Fast Reroute
HE Head-End
IETF Internet Engineering Task Force
IGP Interior Gateway Protocol
IP Internet Protocol
LDP Label Distribution Protocol (MPLS)
L-LSP Label-Only-Inferred-PSC LSP
LSP Label Switched Path
LSR Label Switch Router
MAM Maximum Allocation Model
MP Merging Point
MP-BGP Multiprotocol Border Gateway Protocol
MPLS Multiprotocol Label Switching
NE Network Element
50123_02 Tellabs

2009 Tellabs. MPLS Applications Conguration Guide
3
OA Ordered Aggregate
OAM Operation and Maintenance
OSPF Open Shortest Path First
PD Priority Data
PE Provider Edge
PHB Per Hop Behavior
PHP Penultimate Hop Popping
PLR Point of Local Repair
P-LSP Protected LSP
POS Packet over SDH/SONET
PSC PHB Scheduling Class
PSN Packet Switched Network
QoS Quality of Service
RDM Russian Dolls Model
RFC Request For Comments (IETF documents)
RRO Record Route Object
RSVP-TE Resource Reservation Protocol with Trafc Engineering Extensions
RT Real Time
SDH Synchronous Digital Hierarchy
SONET Synchronous Optical Network
TCP Transmission Control Protocol
TE Trafc Engineering
ToS Type of Service
UDP User Datagram Protocol
VC Virtual Circuit
VoIP Voice over Internet Protocol
VPN Virtual Private Network
Tellabs

4
Table of Contents
Table of Contents
About This Manual ............................................................................................................ 7
Objectives....................................................................................................................................................................... 7
Audience......................................................................................................................................................................... 7
Related Documentation.................................................................................................................................................. 8
Interface Numbering Conventions ................................................................................................................................. 8
Document Conventions .................................................................................................................................................. 8
Documentation Feedback............................................................................................................................................... 9
1 MPLS Overview ........................................................................................................... 10
1.1 Label Distribution................................................................................................................................................ 11
1.1.1 LDP...................................................................................................................................................... 11
1.1.2 RSVP-TE............................................................................................................................................. 11
1.2 MPLS Support of Differentiated Services........................................................................................................... 12
1.2.1 EXP-Inferred-PSC LSPs (E-LSP) ...................................................................................................... 12
1.2.2 Label-Only-Inferred-PSC LSPs (L-LSP) ............................................................................................ 12
1.2.3 DiffServ Tunneling Models over MPLS ............................................................................................. 12
1.3 LSP Afnity Constraints ..................................................................................................................................... 16
1.4 MPLS Protection Switching................................................................................................................................ 18
1.4.1 MPLS Local Protection ....................................................................................................................... 19
1.4.2 RSVP-TE based 1:1 Protection Switching.......................................................................................... 19
1.4.3 MPLS OAM based 1+1 Protection Switching ................................................................................... 19
1.5 MPLS Trafc Engineering................................................................................................................................... 20
1.6 DiffServ-Aware MPLS Trafc Engineering........................................................................................................ 21
1.6.1 Maximum Allocation Model ............................................................................................................... 21
1.6.2 Russian Dolls Model ........................................................................................................................... 22
1.7 Fast Reroute......................................................................................................................................................... 22
1.7.1 Overview ............................................................................................................................................. 22
1.7.2 FRR Application.................................................................................................................................. 22
1.8 MPLS References ................................................................................................................................................ 30
2 MPLS Conguration Examples.................................................................................. 31
2.1 LDP Conguration .............................................................................................................................................. 31
2.2 Explicitly Routed RSVP-TE LSPs ...................................................................................................................... 31
2.2.1 RSVP-TE Conguration...................................................................................................................... 32
2.2.2 E-LSP Conguration ........................................................................................................................... 33
2.2.3 L-LSP Conguration ........................................................................................................................... 35
2.2.4 RSVP-TE Path Protection Conguration ............................................................................................ 37
2.2.5 DiffServ Tunneling Model Conguration ........................................................................................... 38
50123_02 Tellabs

5
Table of Contents
2.3 DS-TE Network Example.................................................................................................................................... 38
2.4 LSP 1+1 Protection Conguration Example ....................................................................................................... 55
2.4.1 LSP 1+1 Protection with RSVP Tunnels............................................................................................. 55
2.4.2 LSP 1+1 Protection with Static Tunnels.............................................................................................. 58
2.5 FRR CLI Conguration Examples ...................................................................................................................... 59
2.5.1 FRR One-to-One.................................................................................................................................. 60
2.5.2 Facility Backup.................................................................................................................................... 66
Tellabs

6
About This Manual
About This Manual
This chapter discusses the objectives and intended audience of this manual, Tellabs 8600 Managed
Edge System MPLS Applications Conguration Guide and consists of the following sections:
Objectives
Audience
Related Documentation
Conventions
Documentation Feedback
Objectives
This manual provides an overview of the Tellabs 8600 managed edge system MPLS applications
and instructions on how to congure them with a Command-line Interface (CLI) using a routers
console or remote terminal (telnet).
Audience
This manual is designed for administration personnel for conguring Tellabs 8600 managed edge
system functions with CLI. On the other hand, Tellabs
8000 Network Manager provides access to

equal functionality for administration personnel with a graphical user interface.
It is assumed that you have a basic understanding of Ethernet, POS, IP, MPLS, VPN and
Differentiated Services concepts. This manual also assumes that you are familiar with the following
protocols:
IP routing
UDP
TCP
Differentiated Services
50123_02 Tellabs

7
About This Manual
Related Documentation
1
Tellabs
8600 Managed Edge System VPNs

Conguration Guide (50128_XX)
Provides an overview of Tellabs 8600 system
virtual private network (VPN) functions and
instructions on how to congure them with CLI.
Tellabs
8600 Managed Edge System CLI

Commands Manual (50117_XX)
Provides commands available to congure,
monitor and maintain Tellabs 8600 managed edge
system products with CLI.
Tellabs
8600 Managed Edge System Routing

Protocols Conguration Guide (50121_XX)
Provides an overview of Tellabs 8600 system
routing protocol functions and instructions on how
to congure them with CLI.
Tellabs
8600 Managed Edge System Test and

Measurement Conguration Guide (50124_XX)
Provides an overview of Tellabs 8600 managed
edge system testing and measurement tools,
connectivity verication and instructions for
conguring them with CLI.
Interface Numbering Conventions
To be able to follow more easily the feature descriptions and conguration examples given in this
document, see also the Tellabs 8600 system interface numbering and related gures described in
Tellabs
8600 Managed Edge System CLI Commands Manual.

Document Conventions
This is a note symbol. It emphasizes or supplements information in the document.
This is a caution symbol. It indicates that damage to equipment is possible if the instructions
are not followed.
This is a warning symbol. It indicates that bodily injury is possible if the instructions are not
followed.
1
To make sure the references point to the latest available document versions, please refer to the Tellabs 8600 Document Set Description that can be
found in Tellabs Portal www.portal.tellabs.com by navigating to Product Documentation -> Data Networking-> Tellabs 8600 Managed Edge System
-> Technical Documentation-> Document Set Description.
Tellabs

8
About This Manual
Documentation Feedback
Please contact us to suggest improvements or to report errors in our documentation:
Email: -documentation@tellabs.com
Fax: +358.9.4131.2430
50123_02 Tellabs

9
1 MPLS Overview
1 MPLS Overview
The inherently connection-oriented nature of Multiprotocol Label Switching (MPLS)
Label-Switched Paths (LSPs), allows several new networking applications to be introduced into the
IP network infrastructure of the service provider. The ongoing MPLS deployments add value both in
terms of enabling state-of-the-art network engineering techniques, and also in terms of enabling the
introduction of new types of end-user service offerings. Most notably, the new network engineering
techniques include MPLS Trafc Engineering (TE), Differentiated Services (DiffServ) aware MPLS
Trafc Engineering, and different types of LSP-based network protection schemes.
In addition to aiding many network engineering tasks in operational Internet Protocol (IP) routing
infrastructure of the service provider, LSPs are also extremely useful on the network service
layer, where they can be used as Virtual Private Network (VPN) tunnels through shared network
infrastructure. The MPLS-based VPN applications supported by the Tellabs 8600 Network Elements
(NE) are described in Tellabs
8600 Managed Edge System VPNs Conguration Guide.

Tellabs

10
1 MPLS Overview
1.1 Label Distribution
In order to be able to perform label switching, the Label Switch Router (LSR) nodes in an MPLS
network have to rst agree on the label values to be used for each label-switched path. When
entering an MPLS domain, a short, xed-length label is assigned to the packets at the ingress LSR,
and removed at the egress LSR. The label values used in the network have only local signicance
along each path, i.e. each label switching node swaps the incoming label value to an outgoing label
value, according to the contents of the label forwarding table of the node.
In the Tellabs 8600 system, the supported LSP signaling protocols are the following:
Label Distribution Protocol (LDP)
Resource Reservation Protocol with Trafc Engineering extensions (RSVP-TE).
In the [RFC4364] VPN application, also Multiprotocol Border Gateway Protocol (MP-BGP) is used
for carrying labels between the ingress and egress Provider Edge (PE) nodes. This topic is detailed
discussed in the Tellabs
8600 Managed Edge System VPNs Conguration Guide.

1.1.1 LDP
LDP is a session protocol that uses Transmission Control Protocol (TCP) as a transport layer. A
discovery mechanism based on the User Datagram Protocol (UDP) automatically builds LDP
sessions between directly connected LSRs. Once an LDP session is established, it distributes
label information between the LSRs. This may be done either in Downstream on Demand mode,
in which an LSR explicitly requests label information from its peer, or Downstream Unsolicited
mode, in which label information is sent without waiting for a request. Only one of these modes is
used at a time.
1.1.2 RSVP-TE
RSVP-TE is a signaling protocol used for reserving labels and bandwidth across an explicitly
routed network path. For accommodating LSP construction, MPLS trafc engineering extensions
have been added to the traditional RSVP protocol used in conjunction with the IntServ Quality of
Service (QoS) model. These trafc engineering extensions are dened in [RFC3209]. To envision
an RSVP-TE LSP tunnel, remember that it is a virtual trunk that makes one Tellabs 8600 NE
appear to be directly connected to another Tellabs 8600 NE. As with all LSPs, an RSVP-TE LSP is
unidirectional. In order to get bidirectional data ow between two nodes A and B, an LSP must be
built rst from A to B, and then from B to A.
In case the RSVP-TE tunnel LSPs are signalled with bandwidth reservations, each Tellabs 8600
NE on the signaling path performs Connection Admission Control (CAC), in order to determine
whether the LSP path request can be accommodated or not. If bandwidth reservations are not made,
the end result will be just an explicitly routed, point-to-point LSP tunnel between two Tellabs 8600
NEs (typically the ones acting as edge LSRs at the edge of the MPLS network domain).
50123_02 Tellabs

11
1 MPLS Overview
1.2 MPLS Support of Differentiated Services
[RFC3270] denes a solution for supporting DiffServ over MPLS networks. It denes two different
types of LSPs, which differ in the way the carried DiffServ Per Hop Behavior (PHB) Scheduling
Class(es) (PSCs) are inferred:
EXP-Inferred-PSC LSPs (E-LSP)
Label-Only-Inferred-PSC LSPs (L-LSP)
1.2.1 EXP-Inferred-PSC LSPs (E-LSP)
E-LSPs support up to eight Behavior Aggregates (BAs), i.e. packets of up to 8 different PHBs. The
3-bit EXP eld of the MPLS shim header conveys to the LSRs the appropriate PHB (both drop
precedence and scheduling class) to be applied to the packet. The mappings between the EXP eld
values and the PHBs are either explicitly signalled, or rely on the precongured mapping tables.
1.2.2 Label-Only-Inferred-PSC LSPs (L-LSP)
L-LSPs transport only a single Ordered Aggregate (OA), i.e. a set of BAs sharing the same ordering
constraint. These include e.g. packets belonging to the AF11, AF12, and AF13 PHBs. This is
implemented so that the scheduling treatment of the packet (PSC) is determined from its label value,
and the drop precedence is carried in the EXP bits of the MPLS shim header. The used PSC is
explicitly signalled at the time of establishing an L-LSP.
1.2.3 DiffServ Tunneling Models over MPLS
When traversing a label switched path, each labelled IP packet can carry at least two separate
instances of DiffServ PHB information, i.e. the DiffServ Code Point (DSCP) marking on the carried
datagram itself, and the PHB information inferred from the MPLS shim header elds. In the case of
the [RFC4364] VPN applications, there are two MPLS shim headers, and thus each VPN datagram
can carry even three different PHB markings. This inherent property of MPLS LSPs allows the
inner PHB information to be transparently carried over the MPLS network, which can be very useful
when the MPLS network domain belongs to a different QoS policy domain than the one whose IP
packets the LSP is carrying.
Some MPLS networks may also make use of Penultimate Hop Popping (PHP), which means that the
outermost label is popped out already at the last hop before the egress LSR. If the outermost MPLS
shim header does not contain any useful label switching or DiffServ information from the point of
view of the egress LSR, it may request the penultimate LSR to perform PHP. This can be done e.g.
with LDP by advertising the implicit NULL label value to the penultimate LSR.
Exactly how the PHB markings on the different layers can be used and interpreted at each hop of
the traversed LSP, depends on the chosen DiffServ Tunnelling Model. The three models dened in
[RFC3270] and supported by the Tellabs 8600 system are called the Pipe Model, Short Pipe Model,
and the Uniform Model, of which the Pipe Model is the Tellabs 8600 system default model.
Tellabs

12
1 MPLS Overview
Example Networking Scenario
Some enterprise networks may still mark VoIP packets with the Class Selector 5 (CS5) codepoint,
where only the 3 most signicant bits of the DSCP eld are used for selecting the forwarding
treatment. The reason for not using the standardized EF codepoint for VoIP is that some legacy
VoIP terminals and/or networking equipment may not even support processing of the whole 6bit
DSCP eld, but can instead only process the 3 precedence bits specied in the original IP Type of
Service (ToS) octet denition.
Thus, if the network of the service provider uses only the EF PHB and its standardized codepoint
for VoIP, and therefore does not have any specic congurations for the Class Selector codepoints
in each and every network node, the VoIP packets may end up in the Best Effort (BE) queue (i.e.
receive the Default Forwarding treatment).
In order to avoid this, the ingress LSR can, of course, use e.g. QoS mapping tables or DiffServ
multi-eld classiers for reclassifying the VoIP packets to the EF PHB. However, if the VoIP trafc
will re-enter the network of the enterprise after the LSP is terminated, the DSCP eld of the VoIP
packet should preferably not be overwritten, but the chosen MPLS domain PHB should instead be
indicated only in the MPLS shim header elds.
In this way, the LSRs can use the outermost, service provider controlled DiffServ information
for their queuing decisions, while the innermost, enterprise-controlled DiffServ information gets
transparently carried over the whole MPLS network domain. Thus, when the LSP is terminated
in the egress LSR and the VoIP packets are delivered back into the QoS policy domain of the
enterprise, the delivered packets will still be marked with the original CS5 codepoints.
The following tunnelling model specic examples deal only with the basic case of encapsulating
IP packets inside single level label stacks. However, the very same techniques can also be applied
to multilevel label stacks, i.e. the DiffServ tunnelling actions are always applied to each label in
the stack at the ingress and egress points of the LSPs, i.e. the points of pushing and popping the
label in question.
Pipe Model
The Pipe Model is the only mandatory tunneling model in [RFC3270] and is also the Tellabs 8600
system default model. Since the egress LSR makes use of both the inner and the outer DiffServ
information, it can only be used without PHP, as illustrated below.
50123_02 Tellabs

13
1 MPLS Overview
Fig. 1 Pipe Model
In the above example with one level label stack, (M) denotes the outer MPLS shim header DiffServ
information and (D) the inner IP header DSCP eld DiffServ information. All LSRs on the label
switched path, including the egress LSR, use the outer MPLS header DiffServ information for
selecting the appropriate PHB (e.g. the EF forwarding treatment typically used for VoIP). The inner
DiffServ information (e.g. the CS5 codepoint markings still found on some enterprise VoIP packets)
has simply been tunnelled through the MPLS network untouched.
Short Pipe Model
The Short Pipe Model is a slight variation of the Pipe Model. The only difference is that with the
Short Pipe Model the DiffServ forwarding treatment at the egress LSR is chosen based on the
inner DiffServ information.
The Short Pipe Model can be used with or without PHP, as illustrated below.
Fig. 2 Short Pipe Model
Tellabs

14
1 MPLS Overview
Fig. 3 Short Pipe with PHP
Uniform Model
In the Uniform Model, each packet carries only one piece of DiffServ information, which is
always encoded in the outer most label entry. Thus, in spite of being categorized as a DiffServ
tunnelling model, the Uniform Model effectively does not tunnel any DiffServ information through
the MPLS network.
The Uniform Model can be used with or without PHP, as illustrated below.
Fig. 4 Uniform Model
50123_02 Tellabs

15
1 MPLS Overview
Fig. 5 Uniform Model with PHP
1.3 LSP Afnity Constraints
This section describes how afnity constraints of MPLS LSPs are related to "include" and
"exclude" attributes of VPN routes and pseudowires.
Although LSP afnity constraint bits are logically similar in function to MPLS administrative
groups (aka link colors, aka link afnities), they are not related and are completely
independent of each other. For example include-any given for link color for RSVP trunk has
no effect on PWE3 association for RSVP trunk.
By default any inner LSP (L3VPN, PWE3) can use any outer LSP (LDP, RSVP, static) that is going
to a desired destination. The constraints are constructed from two parts:
Afnities and protocol limits on outer LSP
Include or exclude constraints on inner LSPs
It is important to understand that if outer LSP has no constraints, the inner LSP can use it even if
the inner LSP has some include or exclude constraints. This rule makes LDP more exible and
easy to use. Afnities and protocol limits on outer LSP take form "[IP] [MPLS 0xnnnnnnnn]". If
[IP] is present, the LSP can be used for pure IP routed trafc. If [MPLS 0xnnnnnnnn] is present,
the PWE3 can be used by inner LSPs that match the outer LSPs afnities. The outer LSP can
hence have the following conguration options:
Both IP routed trafc and unlimited MPLS (PWE3, L3VPN) trafc can use the LSP, i.e. no
constraints
Both IP routed trafc and selected MPLS (PWE3, L3VPN) trafc can use the LSP
Tellabs

16
1 MPLS Overview
Only IP routed trafc can use the LSP, but no inner labels are associated with the LSP
Selected MPLS (PWE3, L3VPN) trafc can use the LSP. No IP trafc is directed to the LSP (it
should be noted that L3VPN trafc is MPLS, as it has inner-label)
The outer label afnities can be applied in:
RSVP by using the "map-route" command
LDP by using receive-labels route-map command. FTN constraints can be set here based on
many criteria, such as prex and the neighbor who advertised the label
Static by using the "mpls static-ftn push" command
Afnity constraints are characterized by a mask value. The mask is usual expressed in hexadecimal
format, but it is interpreted as a string of a 32 bits. For example a mask "0x30A" is interpreted as
following:
00000000 00000000 00000011 00001010
Of the 32-bits in this example, four bits namely the second, fourth, ninth and tenth from right are
used to constraint the given path. The meaning of these bits in the 32-bit vector is dened by the user.
For the example above, lets give some example of what meaning the user may assign to these
four bits:
Second bit is set to one, if the tunnel goes through 1+1 protected long haul link, zero if otherwise
Fourth bit is set to one, if the tunnel uses low-delay path, zero if high-delay path
Ninth bit is set to one, if the tunnel can be used for "premium" customers, zero if otherwise
Tenth bit is set to one if the tunnel goes through at least one compressed link, zero otherwise
The inner label constraints can be expressed using the following three rules:
include-any, at least one of the specied bit must match the outer LSP afnity
include-all, all of the specied bits must match the outer LSP afnity
exclude-any, none of the specied bits may be present in outer LSP afnity
One rule of each type can be specied:
For any LDP PWE3 circuit in the "pwe3 circuit" command
For static PWE3 circuits in the "mpls static-ftn push-and-lookup-for-vc" command
For PWE3 circuits under "ip vrf NAME" mode
If no constraint is present, the inner label can use any outer label (to the suitable destination
with suitable QoS class) that does not have IP only constraints. On the other hand, trafc that
uses LSPs, like VPN trafc or pseudowire trafc, can be congured so that afnity is taken into
account when deciding which trafc uses a given LSP. For VNP trafc, this is done with commands
"exclude-any", "include-all" and "include-any". For other trafc types, e.g. pseudowires, this
is done with attributes exclude-any, include-all and include-any in the commands like "mpls
static-ftn".
Example:
mpls static-ftn push-and-lookup-for-vc abc 313 1.2.3.4
include-any 0x1f0 include-all 0xa exclude-any 0x1
50123_02 Tellabs

17
1 MPLS Overview
This example is very complex, however is presented here to illustrate how the constraints work in
most general cases. When deciding which tunnel trafc can use (in the example above, VC named
"abc"), the decision procedure is based on a bit-by-bit comparison of all four bits.
The tunnel afnity is congured as:
Tunnel affinity: 00000000 00000000 00000011 00001010
The following constraint masks are congured for the VC abc that is carried across the tunnel.
The three values 0x1F0, 0xA and 0x1 are converted in binary format as shown below:
include-any for abc: 00000000 00000000 00000001 11110000
include-all for abc: 00000000 00000000 00000000 00001010
exclude-any for abc: 00000000 00000000 00000000 00000001
Any or all of the three masks, include-any, include-all and exclude-any could have been zero (and
are in fact zero by default). Zero masks logically do not constraint the choice of LSP at all. But if
the user has opted to use non-zero masks, their effect is as follows:
If include-any mask contains at least one non-zero bit, then the afnity mask must have at least
one corresponding bit set to non-zero. In the example above, the ninth bit from right fulls this
condition
Every bit that is set in include-all mask must also be set in afnity mask. In the example above,
the second and fourth bits from right are required, and this requirement is fullled
Every bit that is set in exclude-any mask must be absent in afnity mask. In the example above,
the right most bit is required to be absent in the afnity mask, and indeed it is absent
In this example, the afnity mask passes all three tests and VC "abc" can use the tunnel. If at least
one test had failed, the tunnel would not have been used for this particular VC.
MPLS constraints should only be used when the specied LSP is required for a given inner label. A
good reason would for example be to redirect some trafc to protected LSP while leaving the rest to
use LDP. In that case one could indicate protected quality with single bit, and do include-any for
that bit for the trafc that desires protection, while doing exclude-any for the rest. Alternatively
unprotected LSPs could have another bit that is used for the rest of the LSPs. Afnities are not
required for associating QoS of specic PWE3s to suitable L-LSPs (or E-LSPs that carry only few
QoS classes), because "map-route" does contain separate QoS specier that is used for that purpose.
1.4 MPLS Protection Switching
The inherent connection oriented nature of MPLS LSPs makes them also a very good candidate for
implementing different types of protection schemes. As an example, different types of end-to-end
path protection techniques between the ingress and the egress edge LSRs can be accommodated by
signalling two explicitly routed point-to-point LSPs, traversing diverse physical routes. Since the
trafc rerouting decisions and protection LSP setup procedures have been done already before any
failures occur, these techniques enable signicantly faster network and trafc restoration times than
normal trafc rerouting functionality, and especially if the rerouting decisions also require initiation
of subsequent signalling procedures for LSP reestablishment.
Tellabs

18
1 MPLS Overview
Furthermore, the speed of the protection switching also depends both on the conceptual protection
model, and the used triggering mechanisms. In general, 1+1 type of protection schemes are usually
the fastest, but also consume a double amount of capacity from the network. The speed of other
types of protection models often depends on the mechanisms used for propagating the fault
information along the LSPs route to the NEs doing the protection switching, which in end-to-end
path protection cases are the edge LSRs. Typically, such triggering mechanisms that reside as
close as possible to the protected networking layer function much faster than purely control plane
software based mechanisms.
1.4.1 MPLS Local Protection
In an MPLS-based network local protection can be achieved by switching trafc onto a preset
backup path with a technique known as Fast Reroute (FRR). The main advantage of FRR as a
protection solution is its capability of using local repair methods to guarantee fast failure response
and recovery as close as possible to the point of failure. FRR is detailed covered in 1.7 Fast Reroute.
1.4.2 RSVP-TE based 1:1 Protection Switching
The 1:1 type of MPLS protection technique supported by the Tellabs 8620 access switch, Tellabs
8630 access switch and Tellabs 8660 edge switch is RSVP-TE-based LSP path protection, where
trafc is switched from a primary LSP to a pre-signalled secondary LSP in case the primary LSP
goes down. This protection mechanism uses a combination of L1 defect, RSVP-TE signalling, and
L3 routing information as the possible triggers for determining that the primary LSP is down. The
fastest restoration times are typically achieved if the failure can be detected locally by the NE doing
the actual switching, but for pseudowire trafc the switchover time should always be below 50
milliseconds regardless of the number of connections carried on the LSP.
1.4.3 MPLS OAM based 1+1 Protection Switching
The Tellabs 8620 access switch, Tellabs 8630 access switch and Tellabs 8660 edge switch also
support the ITU-T MPLS OAM [Y.1711] based unidirectional 1+1 path protection switching
mechanism described in [Y.1720]. In this mode, the ingress edge LSR forwards the trafc to the
egress edge LSR over a protection group consisting of two diversely routed RSVP-TE (or static)
tunnel LSPs. Along with both copies of the forwarded user plane trafc, Fast Failure Detection
(FFD) OAM packets are also periodically sent. By default, the protection switching is non-revertive,
but it is also possible to set a restoration timer for switching back to the primary LSP side 60...7200
seconds after the LSP-connectivity has been restored.
In Tellabs 8630 access switch and Tellabs 8660 edge switch the primary and the protecting
LSP must reside in different line cards, and the protection feature only works on Ethernet
ports and otherwise unprotected POS ports (i.e. ports not already protected by any L1 based
protection schemes).
The sending frequency of the FFD packets has a strong affect on the speed of the protection
switching, and is thus user congurable, with a default value of 1 packet in 50 milliseconds. The
protection switching is initiated as soon as the egress edge LSR detects that 3 consecutive FFD
packets have been lost in the primary LSP tunnel. Thus, by using the fastest sending frequency of 1
packet in 10 milliseconds, even restoration times well below 50 milliseconds are achievable.
50123_02 Tellabs

19
1 MPLS Overview
Please note that 1+1 protection is not supported for MPLS over VLAN based congurations
when 2x1000BASE-X IFM is used.
1.5 MPLS Trafc Engineering
[RFC2702] species the requirements for Trafc Engineering over MPLS. Instead of the more
traditional TE methods, explicitly routed point-to-point LSPs offer a more efcient and controlled
way to perform trafc engineering. In addition to [RFC2702], Internet Engineering Task Force
(IETF) has also specied protocol-specic TE extensions for the most common Interior Gateway
Protocols (IGPs) and label signaling protocols.
In the Tellabs 8600 system, all explicitly routed LSP tunnels are set up using the RSVP-TE protocol.
They can be signalled either with or without bandwidth reservations, largely depending on the
selected MPLS deployment model and network engineering applications.
There are traditional TE methods such as adjusting the IGP metrics on a congested link, or relying
on an L2 overlay network design. These include e.g. IP over Asynchronous Transfer Mode (ATM)
or IP over Frame Relay (FR). Instead of the more traditional TE methods, manual MPLS TE can be
performed without making any bandwidth reservations in the network. This can be accomplished
simply by diverting some of the trafc on a congested link to an explicitly routed point-to-point LSP
that bypasses it. As soon as the link congestion has been detected, a new TE tunnel can be set up
between a selected pair of LSRs in the network (often a pair of edge LSRs), and simply signalled
onto a different route than the shortest path that would be selected by the IP routing protocols.
Next, some of the trafc traversing the congested link can be redirected to it, thus relieving the
congestion. In practise, these types of manual TE operations rely totally on online monitoring of the
link utilizations in the network, and require reactive deployment of MPLS TE tunnels (or their L2
equivalents) only in the event of some link(s) getting congested.
In order to proactively prevent the congestion from happening in the rst place, bandwidth
reservations can be made for the trafc trunks with a controlled load (i.e. appropriately policed),
traversing the MPLS network. In this MPLS deployment model, the RSVP-TE path requests are
subjected to Connection Admission Control (CAC) at each Tellabs 8600 NE. For performing
automated TE LSP routing, also the IGP TE extensions and the Constrained Shortest Path First
(CSPF) algorithm must be enabled in the Tellabs 8600 NEs. In this case, the LSP routing decisions
can be made automatically by the head-end LSRs, since all nodes in the network use the TE
extensions of the selected IGP for advertising the amount of available bandwidth on the directly
attached network links. When a new trafc trunk is to be set up in the network, the head-end LSR
uses the CSPF algorithm for calculating the shortest possible path through the network that still
has enough unreserved bandwidth left to accommodate the needs of the new tunnel LSP. In this
deployment model, a full mesh of TE tunnels is often deployed between all of the edge LSRs in the
network, and most of the end user trafc is mapped on the resulting, logical TE topology.
Please refer to Tellabs
8600 Managed Edge System Routing Protocols Conguration Guide for

more information on different types of routing protocols, and their conguration details.
Tellabs

20
1 MPLS Overview
1.6 DiffServ-Aware MPLS Trafc Engineering
The requirements for DiffServ-aware MPLS Trafc Engineering (DS-TE) have been specied in
[RFC3564]. Instead of setting up aggregate LSPs for carrying all trafc classes (as in the basic form
of MPLS TE), the DS-TE approach performs MPLS trafc engineering at a per-class level. In
DS-TE, the trafc from different DiffServ classes of service is mapped to separate LSPs. Also the
network resources have been divided among the different trafc classes, and the IGP TE extensions
advertise the available bandwidth on the attached links on a per-class basis.
In DS-TE, a TE class is a combination of a Class Type (CT) and an LSP pre-emption priority.
There are a maximum of eight CTs. The network resources are divided into per-CT pools, which
has prompted the need for different types of Bandwidth Constraint (BC) models. The BC models
supported by the Tellabs 8600 system are the Maximum Allocation Model (MAM), and the Russian
Dolls Model (RDM).
1.6.1 Maximum Allocation Model
MAM [RFC4125] is the most intuitive and the most simple BC model. It provides good isolation
between the resources allocated to different CTs, but may in some cases not be the most efcient
model in terms of achieved network utilization. MAM implements an individual BC for each
CT, and can also limit the aggregate of reserved bandwidth across all CTs, as illustrated in the
following gure.
Fig. 6 Maximum Allocation Model (MAM) by IETF
50123_02 Tellabs

21
1 MPLS Overview
1.6.2 Russian Dolls Model
RDM [RFC4127] is the default BC model used in the Tellabs 8600 system. When used together
with LSP pre-emption, RDM can offer good isolation between CTs and also efcient utilization of
the network resources. The CT and BC structure of RDM are illustrated in the following gure.
Fig. 7 Russian Dolls Model (RDM) by IETF
1.7 Fast Reroute
1.7.1 Overview
The continuous growing of real-time applications in the networks imposes a high demand on trafc
protection. This means that when a failure occurs, a fast response and timely switchover close as
possible to the point where a failure occurred are desirable to avoid signaling delays during recovery.
A technique used to address these challenges is known as Fast Reroute (FRR).
FRR provides mechanisms for link or node protection by switching trafc on backup paths around
the point of failure. When a failure occurs the node immediately upstream of the point of failure will
switch trafc to a pre-signaled backup path in response to the failure.
FRR can be utilized as long as the network has enough connectivity for the creation of backup
paths. To protect downstream links or nodes, each node on the protected path can act as a Point of
Local Repair (PLR).
1.7.2 FRR Application
In the Tellabs 8600 system FRR is implemented according to [RFC4090]. There are two different
variants of FRR:
Tellabs

22
1 MPLS Overview
One-to-one backup
Facility backup
FRR is currently supported by the Tellabs 8620 access switch, Tellabs 8630 access switch and
Tellabs 8660 edge switch.
Both FRR variants can be congured to provide either link or node protection.
In link protection, if a link is faulted PLR will bypass that link by switching trafc to detour LSP
or bypass tunnel.
In node protection, if a node is faulted PLR will bypass that node by switching trafc to a backup
path.
FRR denes the following terms, which are wide used in this document:
Backup path refers to either a detour LSP or a bypass tunnel and it is responsible for backing
up protected LSP(s).
Bypass tunnel a tunnel that is used to protect a set of LSPs passing over a common facility.
Detour LSP the LSP that is used to re-route trafc around a failure in one-to-one backup.
Merge Point (MP) the LSR where one or more backup paths rejoin the path of the protected
LSP downstream of the potential failure. The same LSR may be acting as an MP and PLR si-
multaneously.
PLR is any node performing repair, i.e. the head-end LSR of detour LSP or bypass tunnel.
One-to-one Backup
In one-to-one variant, a backup LSP known as detour is pre-signaled downstream for each protected
LSP at each PLR. Detour LSPs are signalled at each node along the path of the protected LSP, with
exception of the egress node. These nodes are known as potential PLRs. The following is an
example topology of the one-to-one backup.
Fig. 8 FRR One-to-One Backup
50123_02 Tellabs

23
1 MPLS Overview
The principle of one-to-one backup is illustrated in Fig. 8, where as an example four detour LSPs can
be created for the protected LSP. When a failure occurs along the protected LSP, the PLR detecting a
failure switches trafc into the detour LSP. For example, if a fault condition occurs in node R3 or
link R2 R3, node R2 will switch trafc sent by node R1 downstream on the detour R2 B-LSP.
In this case R2 B-LSP can be used to protect link R2 R3, or node R3. The same is true for R1
B-LSP and R3 B-LSP (node and link protection), while R4 B-LSP can perform only link protection.
In the downstream when a detour LSP intersects its protected LSP with the same outgoing interface,
the merge will occur at MP.
In one-to-one backup there can be N-1 detour LSPs to fully protect a LSP of N hops, which can
turn to a large number of LSPs in the network. If there are multiple protected LSPs, merging can
help to reduce the amount of LSPs.
One-to-one backup conguration in the network:
Sufcient degree of connectivity available for backup paths
CSPF must be enabled in all nodes on the path
Global parameters are applied for detour LSPs created in transit nodes
CSPF takes into account detour specic bandwidth and link colors to inuence the paths of pos-
sible detour LSPs
Facility Backup
The facility backup works by creating single bypass tunnel for each protected link or node. The
bypass tunnel can also protect a set of LSPs if the following are fullled:
Bypass tunnel must intersect the path of the protected LSP downstream
Protected LSPs must pass through the PLR and common downstream node
When a failure occurs along the protected path, the PLR will reroute trafc onto the bypass tunnel.
This implies that facility backup provides a scalability improvement compared to one-to-one
backup, by utilizing the same bypass tunnel to protect multiple LSPs when a failure occurs in a node
or link, which the bypass tunnel is protecting.
Fig. 9 FRR Facility Backup
Tellabs

24
1 MPLS Overview
The principle of facility backup is illustrated in Fig. 9, where as an example created bypass tunnel
protects node R3 and three LSPs that pass through this node against failure in node R3 or link R2
R3. When a failure occurs in node R3 or link R2 R3, node R2 will switch all trafc sent from
R1, R8 and R2 itself into the bypass tunnel. In this example R4 serves as the MP.
In facility backup bypass tunnels are specically created by conguring the protected link or node,
and the desired MP for the bypass tunnel. In Tellabs 8600 system the PLR node supports LSP
ping and traceroute for bypass tunnel.
Facility backup conguration in the network:
Desired potential PLR nodes must have bypass paths
Protected path is strict congured
Each LSR acting as PLR must have a bypass tunnel pre-congured. All RSVP-TE trunk options
are available
FRR attributes can be taken into account.
Head-End
The creation and establishment of the protected LSP session follows the same principle as
conventional LSP in a RSV-TE. Please refer to Tellabs
8600 Managed Edge System MPLS

Applications Conguration Guide for more details.
Depending on the network topology, the head-end makes decision on wether a protection path must
be established and which protection variant (link or node) is required. For example, if at head-end
there are two provisioned paths, primary and secondary LSPs it is possible to create a detour LSP to
protect the primary LSP (primary detour LSP) and a second detour LSP to protect the secondary
LSP (secondary detour LSP). With such protection scenario there is a precedence order in the
Tellabs 8600 system to handle the protection when there is more than one protection path. The
following table illustrates the order of the precedence, i.e. how data trafc is switched:
State Condition Description of Data Flow
No failure If all paths are available, trafc will be carried on the primary protected
LSP
Failure in protected LSP If protected LSP is not available (faulted) trafc will be switched to
the primary detour LSP, i.e. primary detour LSPs are preferred over
secondary LSPs
Primary detour LSP failure If primary detour LSP is not available trafc is switched to secondary
protected LSP
Failure in secondary protected
LSP
If secondary protected LSP is not available and both primary protected
LSP and primary detour too, trafc will be switched to secondary
detour LSP
The above implies that only one active path can exist at the time and that detour is a
hot-standby path, i.e. no trafc passes through before switchover.
In Tellabs 8600 system it is possible to prevent detour creation at Head-End when there is more than
one protection path. In such case detour can be created in the downstream. In the downstream if
there is a path available a detour will be created automatically.
50123_02 Tellabs

25
1 MPLS Overview
When a failure occurs the head-end employes global revertive mode to re-optimize the LSPs that
used the failed path.
Path Identication
When FRR is enabled backup paths are signalled and the following conditions imply:
Backup paths must be uniquely identied
Protected paths must be associated with their backup paths
Global and non-global labels utilization
Backup paths must be merged downstream
RSVP-TE status maintenance during and after failure
One-to-One Backup
A detour LSP needs to be clearly identied with its protected session to allow correct merging and
state treatment. This implies that a detour LSP must inherit its LSP ID from the associated protected
LSP. To be able to uniquely identify a detour LSP, two approaches are dened:
Sender Template-Specic
Path-Specic
Sender Template-Specic - in this approach every PLR uses a local router address as the ingress
address of detour LSP. Additionally detour LSP object may be added to the path message. Detour
LSPs may be merged using this approach. A merge will occur if the outgoing interface, Explicit
Route Object (ERO) and the next-hop LSR are the same.
Path-Specic - in this approach detour LSP uses the protected LSP ingress address and a detour
LSP object is added to the path message. Detour LSPs can be merged using path-specic approach.
A merge must occur only if the path messages share the same outgoing interface and next-hop LSR.
In the Tellabs 8600 system Path-Specic is the default mode.
If strict path is used, trafc cuts may occur when detours LSPs are merged to detour LSP. It is
recommended not to use explicit path when FRR is used in global revertive mode.
There might be circumstances (though very unlikely, but possible depending on the network
topology) where merge must be done, but cannot be constructed. In such cases MP will
tear down some of the detour LSPs. The head-end will see that the path is only partially
protected (fault indication will be raised).
Facility Backup
To allow correct merge bypass tunnels must also be uniquely identied. They are identied using the
Path-Specic method and follows the same procedures as to those described in One-to-One Backup.
Tellabs

26
1 MPLS Overview
Provisioning and BFD
When enabling FRR in one-to-one backup, the paths used for detour LSPs must meet the following:
Downstream interface cannot be shared
Protected LSP and its detour LSP must intersect downstream past the protected resource (link or
node)
Detour LSPs must have the same egress IP address as the LSP being protected
Detour LSPs might have different attributes than the protected LSP
Facility Backup:
Protection scenarios are laid out node per node against link or node protection
Only nodes having bypass tunnel congured, make paths computation
Bypass tunnel can have an ERO object (strict path with predetermined hops)
It is possible to specify how much bandwidth is reserved for detour LSPs, which of course might
affect detour path selection. In Tellabs 8600 system by default no bandwidth is allocated for detour
LSPs. However depending on the operators needs and the importance of trafc, the following
options are available:
Provision no bandwidth and rely on quick global recovery to reroute trafc quickly;
Overbook, i.e. congure detour LSPs to reserve less bandwidth than the protected LSP;
Reserve the same amount of bandwidth
FRR will be activated if a downstream link or node goes down. However when a failure occurs,
RSVP status (error) messages are propagated upstream towards the head-end traversing nodes on
the path and these intermediate nodes also process these messages. There will be a signicant delay
until the head-end gets notied about the failure condition, or the error message might get lost due to
the nature of the RSVP protocol itself. This means that link down triggering mechanism might not
be reliable or in some cases even not available. Therefore Bidirectional Forwarding Detection (BFD)
can be used for quick failure detection. Please refer to Tellabs
8600 Managed Edge System Test and

Measurement Conguration Guide BFD sections for more information and conguration details.
With SONET/SDH POS interfaces link failure detection time is almost 1 second, which exceed
signicantly the FRR requirement of <50ms. This requires that timers should be tuned in
SDH/SONET POS interfaces so that any possible link level protection schemes are faster enough
than upper layer detection time. The Tellabs 8620 access switch, Tellabs 8630 access switch and
Tellabs 8660 edge switch provide a way to specically set the link failure detection time with aid
of the following command:
ssf-delay layer2 50
Switched Ethernet networks can aggregate multiple hops, which are transparent to MPLS nodes. In
such situation it is possible to launch a BFD session sending packets at regular intervals. When
multiplier value of BFD hellos are missing, the session is declared down, hence RSVP session
and underlying trunks drop over this interface.
BFD has to be tied to RSVP neighbor
50123_02 Tellabs

27
1 MPLS Overview
In facility backup CAC is not supported.
Attributes
The FRR attributes are:
Setup priority
Holding priority
Hop-limits
Flags
Bandwidth
Exclude-any
Include-any
Include-all
When congured, FRR attributes are signaled with the protected LSP Path message. When a
downstream node creates a detour LSP, these attributes will be copied from the protected sessions
FRR attributes. If the FRR attributes are not congured by the head-end, the downstream LSR
inherits the attributes of the protected LSP while signaling its detour LSP.
Network Topologies
In the Tellabs 8600 system FRR supports any network topology with sufcient degree of
connectivity.
The following is an example of a ring topology using the one-to-one backup.
Fig. 10 FRR One-to-One Backup in Ring Topology
Tellabs

28
1 MPLS Overview
In Fig. 10 the protected LSP is established and connects via nodes R1, R2, R3, R4 to R5 and trafc
ows in the same direction. In this example when protected LSP is established, every node in the
ring creates detour LSP in the reverse direction of the protected path (LSP). These detour LSPs are
merged in the downstream detour path. As an example, Fig. 10 shows detour LSP D2 being merged
in node R1 when protecting against a failure in link R2 R3. The same merging mechanism is
valid for the rest of nodes in a ring topology.
The following is an example of a ring topology using facility backup method.
Fig. 11 FRR Facility Backup in Ring Topology
In Fig. 11 lets assume ingress node R1 and egress R5. In a protected ring topology using facility
backup, bypass tunnel is established depending on the protection type used link or node.
If a failure occurs e.g. in link R2 R3, bypass tunnel R2-R1-R6-R5-R4-R3 (node R3 is the MP)
is used as the protecting path of link R2 R3.
If a failure occurs e.g. in node R3, bypass tunnel (node R4 is the MP) R2-R1-R6-R5-R4 is used
as protecting path of node R3.
Bypass tunnel:
One bypass tunnel provides protection for each link or node in the ring (shared by all LSPs on
that link).
Switched trafc and RSVP signaling for the failing protected LSP are carried by the bypass tunnel
in the reverse direction and rejoins at the MP into the original protected LSP. The protected LSP
is intact around the ring except the fast rerouting in the reverse direction enabling the user to
avoid the failed link / node.
Fault Management
The Tellabs 8600 system supports FRR Fault Management (FM) and the faults reported are
summarized in the following table.
50123_02 Tellabs

29
1 MPLS Overview
FRR Faults
Fault Description
mplsPrimaryLspFrrActive Some part of primary LSP uses detour or bypass
tunnel
mplsPrimaryLspNotFullyProtected At least one hop is not protected or link protection
is used when node protection was desired
genTunnelBypassDown Whole bypass tunnel is down i.e. not operational
(typically session is not properly established)
mplsSecondaryLspFrrActive Some part of secondary LSP uses detour or bypass
mplsSecondaryLspNotFullyProtected At least one hop is not protected or link protection
is used when node protection was desired
1.8 MPLS References
Feature Description
[RFC2702] RFC2702 (199909), Requirements for trafc engineering over
MPLS
[RFC3209] RFC3209 (200112), RSVP-TE: Extensions to RSVP for LSP tunnels
[RFC3270] RFC3270 (200205), Multiprotocol label switching (MPLS) support
of differentiated services
[RFC3564] RFC3564 (200307), Requirements for support of differentiated
services-aware MPLS trafc engineering
[RFC4090] RFC4090 (200605), RSVP-TE Fast Reroute
[RFC4125] RFC4125 (200506), Maximum allocation bandwidth constraints
model for DiffServ-aware MPLS trafc engineering
[RFC4127] RFC4127 (200506), Russian dolls bandwidth constraints model for
DiffServ-aware MPLS trafc engineering
[RFC4364] RFC4364 (200602), BGP/MPLS IP Virtual Private Networks
(VPNs)
[Y.1711] ITU-T Recommendation Y.1711 (200402), Operation &
Maintenance mechanism for MPLS networks
[Y.1720] ITU-T Recommendation Y.1720 (200612), Protection switching
for MPLS networks
Tellabs

30
2 MPLS Conguration Examples
The conguration examples in this chapter focus on the signalling of LSPs on a precongured
IP/MPLS routing infrastructure, which is already running the OSPF and OSPF-TE protocols. Thus,
the detailed description for setting the OSPF routing parameters, and its TE extensions, can be found
in Tellabs
8600 Managed Edge System Routing Protocols Conguration Guide.

2.1 LDP Conguration
If neither explicit routing nor bandwidth reservations are needed, LDP can automatically create the
required E-LSPs between adjacent LSRs simply by enabling the protocol on each label-switched
interface. Doing this on all of the label-switched interfaces in each router node, will result in an
automatically created multipoint-to-point LSP topology. It can in some cases be used for carrying all
the label-switched trafc within the whole IP/MPLS domain. This can take place e.g. when running
[RFC4364] VPNs in a high capacity core network without any MPLS-based trafc engineering or
LSP protection needs.
Command Description
router(config)# interface fe 3/0/0 Congures the Fast Ethernet port at slot #3 /
module #0 / interface #0.
router(cfg-if[fe 3/0/0])# label-
switching
Enables label switching on the interface.
router(cfg-if[fe 3/0/0])# no shutdown Turns the IP interface state up (default state is
shutdown).
router(cfg-if[fe 3/0/0])# ip address
10.0.10.1/24
Assigns an IP address to the interface.
router(cfg-if[fe 3/0/0])# mpls label
protocol ldp
Enables automatic LDP label distribution with
adjacent peers.
router(cfg-if[fe 3/0/0])# exit Exits from the Interface Conguration command
mode.
2.2 Explicitly Routed RSVP-TE LSPs
In the case of running MPLS-based trafc engineering and/or LSP protection applications in the
network, explicitly routed, point-to-point LSP tunnels are used for carrying at least some portion of
the trafc within the IP/MPLS network domain. In the Tellabs 8600 system, all explicitly routed
LSPs (with or without bandwidth reservations) are signalled using RSVP-TE.
The Explicit Route Object (ERO), which denes the LSP route to be signalled by RSVP-TE, can
include both loose and strict hops:
50123_02 Tellabs

31
For the loose hops, the route taken from the previous router to the current router does not need to
be a direct path, and the path message exchanged between the two routers can pass other routers.
For the strict hops, the route taken from the previous router to the current router must be a directly
connected path, and the path message exchanged between the two routers should not pass any
intermediate routers. This ensures that the routing is enforced on the basis of each link.
The explicit LSP route can either be automatically calculated by the CSPF algorithm, as will be
demonstrated in the DS-TE network example, or manually specied by the network administrator,
as in the following E-LSP and L-LSP conguration examples, which are based on the following
network diagram (with label switching and LDP already enabled on all interfaces).
Fig. 12 A Simple RSVP-TE LSP Conguration Topology Example
2.2.1 RSVP-TE Conguration
Before starting to set up any explicitly routed LSPs, also the RSVP-TE protocol has to be enabled
on all interfaces of the example network, as shown in the following example.
Command Description
R1(config)# interface fe 3/0/0
R1(cfg-if[fe 3/0/0])# mpls label
protocol rsvp
R1(cfg-if[fe 3/0/0])# exit
Enables the RSVP-TE protocol on the Fast Ethernet
port at slot #3 / module #0 / interface #0 of node R1.
Tellabs

32
2.2.2 E-LSP Conguration
Explicitly routed E-LSPs can carry up to eight BAs (i.e. packets of up to 8 different PHBs), and
since they are not explicitly associated with any particular PSC during the setup signalling, E-LSPs
can be signalled either with or without the optional RSVP-TE DiffServ object.
Tellabs 8605 access switch does not support prex+QoS longest prex match lookups in IP
routing. Although the command map-route ignores QoS for IP trafc forwarding, these QoS
qualiers affect PWE3 trafc associations. Currently, IP lookups QoS qualiers are ignored
in the Tellabs 8605 access switch.
Command Description
R1(config)# rsvp-path R1-R5_via_R3
R1(cfg-rsvp-path[R1-R5_via_R3])#
10.30.0.2 strict
10.60.0.2 strict
R1(cfg-rsvp-path[R1-R5_via_R3])# exit
Species an explicit route, with two strict hops, for
the new tunnel LSP.
R1(config)# rsvp-trunk R1-R5_data Sets up a new trunk for data trafc.
R1(cfg-rsvp-trunk[R1R5_data])# primary
path R1-R5_via_R3
The new trunk will be routed according to the LSP
path specied earlier.
setup-priority 7
Sets the setup priority of the trunk to 7 (= lowest
possible preemption priority), so this trunk will not
preempt any other trunks. This is also the default
setup priority value.
hold-priority 0
Sets the hold priority of the trunk to 0 (= highest
possible preemption priority), so this trunk will
never get preempted by any other trunk. This is
also the default hold priority value.
bandwidth 30M
The bandwidth to be reserved for the trunk is 30
Mbps.
R1(cfg-rsvp-trunk[R1R5_data])# no
primary diffserv-object
The DiffServ object of RSVP-TE is not used (it is
mandatory only when signalling L-LSPs).
class-type data
The DS-TE class type for the trunk is the data CT.
This may be omitted if the network does not run
DS-TE.
elsp-preconfigured
The LSP tunnel will be of the precongured E-LSP
type, with default PHB <-> EXP mapping tables
used at each router.
50123_02 Tellabs

33
R1(cfg-rsvp-trunk[R1R5_data])#
map-route 10.10.0.5/32 qos af1
Maps an IP route to the current trunk, i.e. instead of
traversing the multipoint-to-point LDP LSPs used
for the default forwarding treatment, those AF1,
AF2 and AF3 PSC packets, whose next hop lookup
resolves to the gateway address 10.10.0.5, will be
directed to the new point-to-point data trunk.
R1(cfg-rsvp-trunk[R1R5_data])# to
10.10.0.5
Species the IP loopback address of the egress node
of the new tunnel LSP, after which the protocol
session will be set up, and the LSP initialization
can begin.
R1(cfg-rsvp-trunk[R1R5_data])# exit Exits from the RSVP-TE Trunk Conguration
command mode.
Tellabs

34
2.2.3 L-LSP Conguration
Explicitly routed L-LSP tunnels are signalled in a very similar fashion as in the previous example
of signaling explicitly routed E-LSPs. There is, however, a fundamental difference. As L-LSPs
are always explicitly associated with a single PSC, the optional RSVP-TE DiffServ object has to
be used in the signaling. Thus, the trafc belonging to just that one single PSC can be directed to
the trunk, as shown in the following example.
Command Description
R1(config)# rsvp-path R1-R5_via_R4
10.40.0.2 strict
10.70.0.2 strict
R1(cfg-rsvp-path[R1-R5_via_R4])# exit
Species an explicit route, with two strict hops,
for the new tunnel LSP (this time via R4, instead
of R3).
R1(config)# rsvp-trunk R1-R5_real-time Sets up a new trunk for real-time trafc.
R1(cfg-rsvp-trunk[R1R5_real-time])#
primary path R1-R5_via_R4
The new trunk will be routed according to the LSP
path specied earlier.
primary setup-priority 0
Sets the setup priority of the trunk to 0 (= highest
possible preemption priority), so this real-time
trunk may preempt other lower priority (e.g. data)
trunks in order to get into the low latency (i.e.
shortest) path.
primary hold-priority 0
never get preempted by any other trunk.
primary bandwidth 10M
Mbps.
primary class-type real-time
The DS-TE class type for the trunk is the real-time
CT. Again, this is not needed if the network does
not run DS-TE.
primary llsp ef
The LSP tunnel will be of the L-LSP type, and will
be explicitly associated with the EF PSC during
the set up signalling by including the RSVP-TE
DiffServ object.
map-route 10.10.0.5/32 qos ef
Maps an IP route to the current trunk, i.e. instead
of traversing the multipoint-to-point LDP LSPs
used for the default forwarding treatment, those
EF packets, whose next hop lookup resolves to the
gateway address 10.10.0.5, will be directed to the
new point-to-point real-time trunk.
50123_02 Tellabs

35
R1(cfg-rsvp-trunk[R1R5_real-time])# to
10.10.0.5
of the new tunnel LSP, after which the protocol
can begin.
exit
Exits from the RSVP-TE Trunk Conguration
command mode.
Tellabs

36
2.2.4 RSVP-TE Path Protection Conguration
In order to utilize RSVP-TE based path protection in the Tellabs 8600 system, two diversely routed
LSPs can be signalled to set up both the primary path and the secondary path for the protected
trafc trunk. In this example, two explicitly routed E-LSPs will be signalled without making
any bandwidth reservations, using the same explicit LSP routes which were already specied in
the two previous examples.
Command Description
R1(config)# rsvp-trunk R1-R5_protected Sets up a new trunk for protected trafc.
R1(cfg-rsvp-trunk[R1R5_protected])#
primary path R1-R5_via_R3
The primary LSP of the new trunk will be routed
on the path traversing R3.
secondary path R1-R5_via_R4
The secondary LSP of the new trunk will be routed
on the path traversing R4.
AF4 PSC packets, whose next hop lookup resolves
to the gateway address 10.10.0.5, will be directed
to the new protected trafc trunk.
R1(cfg-rsvp-trunk[R1R5_protected])# to
10.10.0.5
of the new tunnel LSPs, after which the protocol
can begin.
exit
Exits from the RSVP-TE Trunk Conguration
command mode.
50123_02 Tellabs

37
2.2.5 DiffServ Tunneling Model Conguration
The DiffServ Tunneling Model selections are done on the network element level in the Tellabs
8600 system as shown in the following example.
Command Description
router(config)# mpls tunnel-model
tunnel-label short-pipe
Sets the outer label tunneling model to Short Pipe.
router(config)# no mpls tunnel-model
tunnel-label short-pipe
Using the no option cancels the command and
returns to node defaults (i.e. Pipe Model).
Please note that if the Tellabs 8600 network element acts as the penultimate LSR and
penultimate hop popping is applied, the tunneling model behavior is uniform, even if the
node conguration is short pipe.
Exactly similar settings can be made also for the inner VPN labels, as follows.
Command Description
router(config)# mpls vpn-tunnel-model
tunnel-label uniform
Sets the VPN label tunneling model to Uniform.
router(config)# mpls vpn-tunnel-model
tunnel-label pipe
Sets the VPN label tunneling model back to Pipe,
which is the node default setting.
2.3 DS-TE Network Example
The following DS-TE network example is based on RDM, which is also the default BC model in the
Tellabs 8600 system. In addition to RDM, also MAM is supported in the Tellabs 8600 system. If
required, the BC model on each interface can be changed as follows.
Command Description
router(config)# interface fe 3/0/1
router(cfg-if[fe 3/0/1])# bc-mode mam
Changes the BC model on the interface to MAM.
router(cfg-if[fe 3/0/1])# no bc-mode
mam
Using the no option cancels the command and
returns to node defaults (i.e. RDM).
router(cfg-if[fe 3/0/1])# bc-mode
russian-doll
Alternatively, the BC model can also be explicitly
set to RDM.
In this particular RDM-based network example, the default BC model settings can be used, so no
BC model congurations are needed in the network nodes. The example topology consists of six
Tellabs 8600 NEs, which have been interconnected as shown in the following network diagram.
Tellabs

38
Fig. 13 A DS-TE Network Topology Example with Six Nodes
All links in the network are 100 Mbps Fast Ethernet links. Under the chosen QoS policy, no resource
reservations are made for the BE/Default Forwarding trafc, which utilizes the basic LDP-based
multipoint-to-point E-LSP transport. Also the DS-TE trunks will be of the E-LSP type, and thus the
optional DiffServ object will not be used in the RSVP-TE signalling.
Out of the maximum of eight possible DS-TE Class Types, only three CTs are taken into use
in the network:
CT0 for AF1 based Business Data (BD) trafc
CT1 for AF4 based Priority Data (PD) trafc
CT2 for EF based Real Time (RT) trafc
The reservable link bandwidth will be allocated to the three chosen CTs according to the RDM BC
settings illustrated below, leaving a total of 40 Mbps of unreservable bandwidth for the BE/Default
Forwarding trafc.
50123_02 Tellabs

39
Fig. 14 RDM Bandwidth Allocations in the Network
LSP preemption is used in the network in the following fashion:
Only RT trunks can preempt other trunks and are never preempted by other trunks.
PD trunks never preempt other trunks and are never preempted by other trunks.
BD trunks never preempt other trunks but can become preempted by RT trunks.
To achieve this, the LSP setup and hold priorities can be set as follows (0 is the highest possible
preemption priority level and 7 the lowest possible preemption priority level):
RT trunks will be congured with setup priority 0 and hold priority 0.
PD trunks will be congured with setup priority 1 and hold priority 0.
BD trunks will be congured with setup priority 1 and hold priority 1.
In order to be able to congure a new trafc trunk in DS-TE, the setup priority and the Class Type
must be such that, together, they form one of the (up to) eight TE Classes. Also the hold priority and
the Class Type of the trunk must, together, match one of the congured TE Classes.
Thus, the chosen preemption strategy then yields, e.g. the following TE Class mapping:
TE Class 0 = <CT0, preemption 1> = <BD, 1>
TE Class 1 = <CT1, preemption 1> = <PD, 1>
TE Class 2 = <CT1, preemption 0> = <PD, 0>
TE Class 3 = <CT2, preemption 0> = <RT, 0>
TE Classes 4...7 will be marked unused
Apart from the required Fast Ethernet interfaces and IP addresses indicated in the network diagram,
the basic interface, OSPF, and DS-TE settings in each node are identical to the below example
of node 1.
Tellabs

40
Command Description
NODE1(config)# mpls class-type ct0 BD
NODE1(config)# mpls class-type ct1 PD
NODE1(config)# mpls class-type ct2 RT
Denes the DS-TE class types (CTs).
NODE1(config)# mpls te-class te0 BD 1
NODE1(config)# mpls te-class te1 PD 1
NODE1(config)# mpls te-class te2 PD 0
NODE1(config)# mpls te-class te3 RT 0
Denes the required TE Classes with appropriate
preemption priorities.
NODE1(config)# interface lo 0
NODE1(cfg-if[lo 0])# no shutdown
NODE1(cfg-if[lo 0])# ip address
10.123.100.41/32
Loopback interface is required in order to get the
OSPF and RSVP-TE protocol sessions with the
peer nodes working.
NODE1(cfg-if[lo 0])# interface fe 3/0/0 Congures the Fast Ethernet port at slot #3 /
module #0 / interface #0.
NODE1(cfg-if[fe 3/0/0])# label-
switching
Enables label switching on the interface.
NODE1(cfg-if[fe 3/0/0])# reservable-
bandwidth 60M
Sets the maximum reservable bandwidth to 60
Mbps.
NODE1(cfg-if[fe 3/0/0])# bandwidth-
constraint BD 60M
Sets BC0 of the Russian Dolls BC model; all LSPs
from CT0, CT1, and CT2 (i.e. BD, PD, and RT)
may use no more than 60 Mbps.
constraint PD 40M
from CT1 and CT2 (i.e. PD and RT) may use no
more than 40 Mbps.
constraint RT 20M
from CT1 (i.e. RT) may use no more than 20 Mbps.
NODE1(cfg-if[fe 3/0/0])# no shutdown Turns the IP interface state up (default state is
shutdown).
NODE1(cfg-if[fe 3/0/0])# ip address
10.0.10.1/24
Sets the interface IP host address according to
addressing plan indicated in the network diagram.
NODE1(cfg-if[fe 3/0/0])# mpls label
protocol ldp
Enables automatic LDP label distribution for
carrying the BE/Default Forwarding trafc.
protocol rsvp
Enables RSVP-TE signalling on the interface.
50123_02 Tellabs

41
NODE1(cfg-if[fe 3/0/0])# interface fe
3/0/1
NODE1(cfg-if[fe 3/0/1])# label-
switching
NODE1(cfg-if[fe 3/0/1])# reservable-
bandwidth 60M
constraint BD 60M
constraint PD 40M
constraint RT 20M
NODE1(cfg-if[fe 3/0/1])# no shutdown
NODE1(cfg-if[fe 3/0/1])# ip address
10.0.20.1/24
protocol ldp
protocol rsvp
Makes equivalent settings to the Fast Ethernet port
at slot #3 / module #0 / interface #1.
NODE1(cfg-if[fe 3/0/1])# router ospf 1
NODE1(cfg-ospf[1])# ospf router-id
10.123.100.41
NODE1(cfg-ospf[1])# network
10.0.10.0/24 area 0.0.0.0
10.123.100.41/32 area 0.0.0.0
10.0.20.0/24 area 0.0.0.0
NODE1(cfg-ospf[1])# cspf tie-break
least-fill
Congures the OSPF settings. In case there are
more than one route alternatives, requiring equal
number of router hops for explicit LSP routing,
preference for the least-lled path will be used as
the CSPF tie break method. Please refer to Tellabs
8600 Managed Edge System Routing Protocols

Conguration Guide for more details on the other
OSPF settings.
After all of the nodes have been set up in a similar fashion to the above example of node 1, the
signalling of the required DS-TE trafc trunks can begin.
Please note in the following examples that only the point-to-point TE tunnel LSPs for the
trafc owing towards node 6 are being signalled (i.e. node 1 > node 6 and node 2 > node
6), leaving all of the trafc in the opposite direction to the multipoint-to-point LDP LSPs.
However, since real service provider networks usually carry mostly bidirectional trafc, also
the trafc trunks in the opposite directions would normally have to be set up.
When the Russian Dolls bandwidth constraint model is used, the temporal order of the signalled
trafc trunks has a strong effect on the resulting LSP routing. Those trunks that are signalled earlier,
will normally have better chances of occupying the shortest path, unless preempted by higher priority
trunks later on. This is also the case with the initially signalled RT and BD trunks in the following
example, which will get to be routed on the shortest paths N1 > N4 > N6 and N2 > N5 > N6.
Tellabs

42
Command Description
NODE1(config)# rsvp-trunk
trunk1_RT10_N1-N6
Congures an RT trunk from node 1 to node 6.
NODE1(cfg-rsvp-trunk[trunk1_RT10_N1-
N6])# primary setup-priority 0
Sets the setup priority of the trunk to 0 (= highest
possible preemption priority), so this trunk may
preempt other trunks having a hold priority of 1 (=
the lowest priority level in use in this example).
N6])# primary hold-priority 0
never get preempted by any other trunk.
N6])# primary bandwidth 10M
Mbps.
N6])# no primary diffserv-object
The optional RSVP-TE DiffServ object will not
be used.
N6])# primary class-type RT
DS-TE class type for this session will be RT (i.e.
CT2).
N6])# primary elsp-preconfigured
The LSP tunnel will be of the precongured E-LSP
type, with default PHB <-> EXP mapping tables
used at each node.
N6])# update-type make-before-break
If the trunk parameters need to be changed later, a
new LSP will be created for each attribute update.
Once the new LSP becomes operational, the
original LSP will be torn down.
N6])# map-route 10.123.100.46/32 qos ef
EF packets, whose next hop lookup resolves to the
gateway address 10.123.100.46, will be directed to
the new point-to-point RT trunk.
N6])# to 10.123.100.46
Species the IP loopback address of the egress
node (i.e. node 6) of the new tunnel LSP, after
which the protocol session will be set up, and the
LSP initialization can begin.
50123_02 Tellabs

43
Command Description
trunk2_BD10_N1-N6
NODE1(cfg-rsvp-trunk[trunk2_BD10_N1-
N6])# primary class-type BD
N6])# map-route 10.123.100.46/32 qos
af1
N6])# to 10.123.100.46
Congures a 10 Mbps BD trunk from node 1 to
node 6, and directs AF1 trafc to it. This time
both the setup and hold priorities are set to 1 (= the
lowest priority level in use in this example), so this
trunk will not preempt other trunks, but may get
preempted later by higher priority trunks.
Command Description
trunk3_RT15_N2-N6
N6])# map-route 10.123.100.46/32 qos ef
N6])# to 10.123.100.46
Congures a 15 Mbps RT trunk from node 2 to
node 6, and directs EF trafc to it.
Tellabs

44
Command Description
trunk4_BD15_N2-N6
N6])# primary class-type BD
N6])# map-route 10.123.100.46/32 qos
af1
N6])# to 10.123.100.46
Congures a 15 Mbps BD trunk from node 2 to
node 6, and directs AF1 trafc to it.
Next an attempt is made to signal a PD trunk from node 2 to node 6 and from node 1 to node 6. At
this phase, there are already existing LSPs on the shortest paths N1>N4>N6 and N2>N5>N6,
so CSPF may have to calculate alternative routes for these trunks.
Command Description
trunk5_PD30_N2-N6
Establishes a new PD trunk from node 2 to node 6.
NODE2(cfg-rsvp-trunk[trunk5_PD30_N2-
This time the setup priority is 1 (i.e. the lowest
priority level in use in this example), and the hold
priority 0 (i.e. the highest possible priority level),
so the new PD trunk will neither preempt other
trunks, nor will it be preempted by other trunks.
N6])# primary class-type PD
The desired trunk bandwidth is 30 Mbps. There is
already a 15 Mbps RT trunk on the shortest path
N2>N5>N6, and since BC1 (i.e. the maximum
bandwidth consumed by all RT and PD trunks)
has been congured to 40 Mbps, an alternative
route has to be calculated. This will result in
a tie between routes N2>N3>N4>N6 and
N2>N1>N4>N6, out of which the least ll
Tie Break mode will select the N2>N3>N4>N6
route.
N6])# map-route 10.123.100.46/32 qos
af4
N6])# to 10.123.100.46
Finally, the LSP initialization can begin, and AF4
trafc is directed to the new N2>N3>N4>N6
PD trunk.
50123_02 Tellabs

45
Command Description
trunk6_PD20_N1-N6
N6])# primary class-type PD
N6])# map-route 10.123.100.46/32 qos
af4
N6])# to 10.123.100.46
The new PD trunk to be set up from node 1 to
node 6 will not t on the shortest path either,
since the 10 Mbps N1>N4>N6 RT trunk and
30 Mbps N2>N3>N4>N6 PD trunk have
already consumed all of the 40 Mbps of BC1
bandwidth on the link between node 4 and node
6. Thus, CSPF will select the next-best alternative
N1>N2>N5>N6, and AF4 trafc will be
directed to the new PD trunk.
At this stage, there are already 6 DS-TE trunks up and running in the network. For example, at node
2, the RSVP-TE session details of both terminating (labelled Ingress (Primary)) and transiting
(labelled Transit (Primary)) trunks can easily be checked as follows.
Command Description
NODE2# show rsvp session detail Shows detailed information about all RSVP-TE
sessions running at node 2.
Ingress (Primary)
10.123.100.46
From: 10.123.100.42, LSPstate: Up, LSPname: trunk3_RT15_N2-N6
Setup priority: 0, Hold priority: 0
CSPF usage: Enabled, CSPF Retry Count: 0, CSPF Retry Interval: 30 seconds
Label in: -, Label out: 87040,
Tspec rate: 15M, Fspec rate: 15M
Tunnel Id: 1, LSP Id: 1, Ext-Tunnel Id: 10.123.100.42
Downstream: 10.0.50.2, fe1/1/1
Path refresh: 2 seconds (due in 0 seconds)
Resv lifetime 247 seconds (due in 221 seconds)
Retry count: 0, intrvl: 30 seconds
RRO re-use as ERO: Disabled
Label Recording: Disabled
Admin Groups: none
Tellabs

46
Congured Path: none
Session Explicit Route Detail:
10.0.50.2/32 strict
10.0.60.2/32 strict
Record route: <self> 10.0.50.2 10.0.60.2
Style: Shared Explicit Filter
Trafc type: controlled-load
Minimum Path MTU: 1500
LSP Type: ELSP_CONFIG
DSTE Class Type Number: 2, Class Type name: RT
Last Recorded Error Code: None
Last Recorded Error Value: None
Transit (Primary)
10.123.100.46
From: 10.123.100.41, LSPstate: Up, LSPname: trunk6_PD20_N1-N6
Label in: 87040, Label out: 87042,
Downstream: 10.0.50.2, fe1/1/1 Upstream: 10.0.10.1, fe1/1/0
Path lifetime 16 seconds (due in 13 seconds)
Resv refresh: 2 seconds (due in 2 seconds)
Admin Groups: none
Received Explicit Route Detail:
10.0.10.2/32 strict
10.0.50.2/32 strict
10.0.60.2/32 strict
10.0.50.2/32 strict
10.0.60.2/32 strict
Record route: 10.0.10.1 <self> 10.0.50.2 10.0.60.2
50123_02 Tellabs

47
DSTE Class Type Number: 1, Class Type name: PD
Blacklist:N/A,
Ingress (Primary)
10.123.100.46
From: 10.123.100.42, LSPstate: Up, LSPname: trunk5_PD30_N2-N6
Admin Groups: none
Congured Path: none
10.0.30.2/32 strict
10.0.40.2/32 strict
10.0.70.2/32 strict
Record route: <self> 10.0.30.2 10.0.40.2 10.0.70.2
DSTE Class Type Number: 1, Class Type name: PD
Ingress (Primary)
10.123.100.46
From: 10.123.100.42, LSPstate: Up, LSPname: trunk4_BD15_N2-N6
Tellabs

48
Admin Groups: none
Congured Path: none
10.0.50.2/32 strict
10.0.60.2/32 strict
DSTE Class Type Number: 0, Class Type name: BD
Next the bandwidth of the 15 Mbps BD trunk between node 2 and node 6 will be increased to 25
Mbps. Since all trunks were signalled with update type make-before-break (which is also the
node default mode), a new LSP is created for implementing the trunk attribute update. Once the
new LSP becomes operational and the modied trunk begins to be transported over it, the original
LSP is torn down. If the break-before-make mode would have been used, the existing LSP would
have been torn down and restarted after the session attribute update, which would have resulted in
a service disruption.
Command Description
trunk4_BD15_N2-N6
NODE2(cfg-rsvp-
trunk[trunk4_BD15_N2N6])# primary
bandwidth 25M
Increases the trunk bandwidth to 25 Mbps.
After this, the RSVP-TE session details of the modied BD trunk can be checked to make sure
it is up and running.
Command Description
NODE2# show rsvp session name
trunk4_BD15_N2-N6
Shows detailed RSVP-TE session information of
trunk4_BD15_N2-N6.
50123_02 Tellabs

49
Ingress (Primary)
10.123.100.46
From: 10.123.100.42, LSPstate: Up, LSPname: trunk4_BD15_N2-N6
Setup priority: 1, Hold priority: 1 CSPF usage: Enabled, CSPF Retry Count: 0, CSPF Retry Interval:
30 seconds
Admin Groups: none
Congured Path: none
10.0.50.2/32 strict
10.0.60.2/32 strict
DSTE Class Type Number: 0, Class Type name: BD
For demonstrating the preemption feature, one more RT trunk will be created from node 1 to node 6,
this time with 5 Mbps bandwidth.
Tellabs

50
Command Description
trunk7_RT5_N1-N6
N6])# map-route 10.123.100.46/32 qos ef
N6])# to 10.123.100.46
Congures a 5 Mbps RT trunk from node 1 to node
6, and directs EF trafc to it.
As was already concluded earlier, the 10 Mbps N1>N4>N6 RT trunk and 30 Mbps
N2>N3>N4>N6 PD trunk have already consumed all of the 40 Mbps of BC1 bandwidth on the
link between node 4 and node 6. Furthermore, all possible higher cost routes to reach node 6 would
have to traverse the link between node 5 and node 6, where the rest of the available bandwidth
allowed by the 60 Mbps BC0 (which in RDM also equals to maximum reservable bandwidth) was
just a moment ago consumed by the bandwidth increase of the 15 Mbps BD trunk between node 2
and node 6 to 25 Mbps. Since the new trunk is a high priority RT trunk carrying delay sensitive
trafc, preemption will clearly be the next step.
For ensuring the optimal path latency characteristics for the most delay-sensitive trafc, typically
interactive multimedia or Voice over Internet Protocol (VoIP) applications, RT trunks should
normally be routed on the shortest path. In this example, however, the shortest path N1>N4>N6
is blocked by BC1, which limits the sum of all RT and PD reservations, and since under the
chosen network wide preemption policy only BD trunks may be preempted, the longer path
N1>N2>N5>N6 has to be considered instead.
Thus, the only alternative CSPF will nd is to preempt the BD trunk between node 2 and node 6,
whose bandwidth was just increased to 25 Mbps. The route selected by CSPF can be easily checked
by displaying the RSVP-TE session details of the new RT trunk and looking under the Session
Explicit Route Detail heading.
Command Description
NODE1# show rsvp session name
trunk7_RT5_N1-N6
Shows detailed RSVP-TE session information of
trunk7_RT5_N1-N6.
Ingress (Primary)
10.123.100.46
From: 10.123.100.41, LSPstate: Up, LSPname: trunk7_RT5_N1-N6
50123_02 Tellabs

51
Setup priority: 0, Hold priority: 0 CSPF usage: Enabled, CSPF Retry Count: 0, CSPF Retry Interval:
30 seconds
Admin Groups: none
Congured Path: none
10.0.10.2/32 strict
10.0.50.2/32 strict
10.0.60.2/32 strict
Record route: <self> 10.0.10.2 10.0.50.2 10.0.60.2
DSTE Class Type Number: 2, Class Type name: RT
The available bandwidth on the link between node 1 and node 2 can also be checked by displaying
the corresponding interface information at node 1. At this point, there should be a 20 Mbps PD
trunk and a 5 Mbps RT trunk loading the link. Thus:
Available BD bandwidth = BC0 (BD + PD + RT) = 60M - (0M + 20M +5M) = 35M
Available PD bandwidth = BC1 (PD + RT) = 40M - (20M + 5M) = 15M
Available RT bandwidth = BC2 RT = 20M 5M = 15M
Command Description
NODE1# show ip interface fe 3/0/0 Shows the IP interface information about the Fast
Ethernet port at slot #3 / module #0 / interface #0.
Interface fe3/0/0
Hardware is Ethernet, address is 00:b0:c7:02:eb:db
index 5004 metric 1 mtu 1500 <UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST>
Tellabs

52
VRF Binding: Not bound
Label switching is enabled
No Virtual Circuit congured
Administrative Group(s): None
Bandwidth 100M
Maximum reservable bandwidth 60M
DSTE Bandwidth Constraint Mode is RSDL
Bandwidth Constraint for Class Type BD is 60M
Bandwidth Constraint for Class Type PD is 40M
Bandwidth Constraint for Class Type RT is 20M
Available b/w for TE-CLASS 0 {BD, 1} is 35M
Available b/w for TE-CLASS 1 {PD, 1} is 15M
Available b/w for TE-CLASS 2 {PD, 0} is 15M
Available b/w for TE-CLASS 3 {RT, 0} is 15M
inet 10.0.10.1/24 broadcast 10.0.10.255
As can be seen from the show command response, also the available bandwidth calculation checks
out. Thus, from node 1 perspective, everything is ne. Unfortunately, however, at node 2 the CSPF
algorithm was not able to nd a new route for the preempted BD trunk between node 2 and node 6,
as can be seen by checking the RSVP-TE session states at node 2.
Command Description
NODE2# show rsvp session Shows basic information about all RSVP-TE
sessions running at node 2.
50123_02 Tellabs

53
2
M
P
L
S
C
o
n
g
u
r
a
t
i
o
n
E
x
a
m
p
l
e
s
Ingress RSVP:
To From State Pri Rt Style Labelin Labelout LSPName DSType
10.123.100.46 10.123.100.42 Up Yes 1 1 SE
-
87040 trunk3_RT15_N2-
N6
ELSP_CON
10.123.100.46 10.123.100.42 Dn Yes 0 0 SE - -
trunk4_BD15_N2N6 ELSP-CON
10.123.100.46 10.123.100.42 Up Yes 1 1 SE - 87040 trunk5_PD30_N2N6 ELSP-CON
Total 3 displayed, Up 2, Down 1.
Transit RSVP:
To From State Pri Rt Style Labelin Labelout LSPName DSType
10.123.100.46 10.123.100.41 Up Yes 1 1 SE 87040 87042 trunk6_PD20_N1-
N6
ELSP_CON
10.123.100.46 10.123.100.41 Up Yes 1 1 SE 87041 87041 trunk7_RT5_N1N6 ELSP-CON
Total 2 displayed, Up 2, Down 0.
T
e
l
l
a
b
s
8
6
0
0
M
a
n
a
g
e
d
E
d
g
e
S
y
s
t
e
m
5
0
1
2
3
_
0
2
M
P
L
S
A
p
p
l
i
c
a
t
i
o
n
s
C
o
n
g
u
r
a
t
i
o
n
G
u
i
d
e
2
0
0
9
T
e
l
l
a
b
s
.
5
4
It can be concluded, that the network has clearly become too congested. In this case, the potential
method of improvement would be either of the following:
Increase the bandwidth of the bottleneck links
Add new links (e.g. one between node 3 and node 6)
In large production networks with more topological complexity, it may be in some cases also have a
third alternative. If it seems that the already existing network resources are suboptimal utilized,
it may be also useful attempting to re-optimize the routing of the tunnel LSPs on a network-wide
scope, for example, by using ofine network modelling and simulation tools. However, the very
obvious danger with that approach is the potential connectivity disruptions on a large number of
operational trafc trunks in the network, so such mass-optimization tasks should always be planned
and executed with great care.
2.4 LSP 1+1 Protection Conguration Example
Suppose interface had been congured properly. LSP 1+1 protection congurations require 2 MPLS
administrative groups, 2 RSVP trunks, 2 OAM instances, and protection group. The following
examples will apply to source NODE2 and sink NODE5, see Fig. 13 .
2.4.1 LSP 1+1 Protection with RSVP Tunnels
SOURCE NODE conguration
Command Description
NODE2(config)# mpls admin-group lsp-p-w
10
NODE2(config)# mpls admin-group lsp-p-p
11
Creates two MPLS administrative groups lsp-p-w
.and lsp-p-p.
NODE2(config)# rsvp-trunk R2R5W
NODE2(cfg-rsvp-trunk[R2-R5-W)# primary
retry-timer 5
NODE2(cfg-rsvp-trunk[R2-R5-W)# primary
include-any lsp-p-w
NODE2(cfg-rsvp-trunk[R2-R5-W)# from
10.123.100.42
NODE2(cfg-rsvp-trunk[R2-R5-W)#
map-route 10.123.100.45/32
NODE2(cfg-rsvp-trunk[R2-R5-W)# to
10.123.100.45
NODE2(cfg-rsvp-trunk[R2-R5-W)# exit
Creates a working rsvp trunk. R2R5W from
NODE2 to NODE5.
50123_02 Tellabs

55
NODE2(config)# rsvp-trunk R2R5P
NODE2(cfg-rsvp-trunk[R2-R5-P)# primary
retry-timer 5
NODE2(cfg-rsvp-trunk[R2-R5-P)# primary
include-any lsp-p-p
NODE2(cfg-rsvp-trunk[R2-R5-P)# from
10.123.100.42
NODE2(cfg-rsvp-trunk[R2-R5-P)#
map-route 10.123.100.45/32
NODE2(cfg-rsvp-trunk[R2-R5-P)# to
10.123.100.45
NODE2(cfg-rsvp-trunk[R2-R5-P)# exit
Creates a protecting rsvp trunk R2R5P from
NODE2 to NODE5.
NODE2(config)# mpls oam ingress rsvp
R2R5W send-interval 10
NODE2(config)# mpls oam ingress rsvp
R2R5P send-interval 10
Creates two OAM instances.
NODE2(config)# protection lsp ingress
lpg-rsvp
NODE2(cfg-protection-lsp[lpgrsvp])#
primary R2R5W
backup R2R5P
exit
Creates LSP ingress protection group lpg-rsvp.
SINK NODE conguration
Command Description
NODE5(config)# mpls admin-group lsp-p-w
10
NODE5(config)# mpls admin-group lsp-p-p
11
Creates two MPLS administrative groups lsp-p-w
.and lsp-p-p.
NODE5(config)# mpls oam egress rsvp
R2R5W expected-interval 10
NODE5(config)# mpls oam egress rsvp
R2R5P expected-interval 10
NODE5(config)# protection lsp egress
lpg-rsvp
NODE5(cfg-protection-lsp[lpgrsvp)#
primary R2R5W
backup R2R5P
exit
Creates LSP egress protection group lpg-rsvp.
Tellabs

56
Check the congurations and Protection status
Congurations and protection status can be checked with CLI show command at Source NODE2
and Sink NODE5, for examples:
Command Description
NODE2(config)# show rsvp session name
R2R5W
NODE5(config)# show rsvp session name
R2R5P
Shows the conguration and protection status of
the source and sink nodes.
NODE2(config)# show protection lsp
Codes: > - Complete, i - Ingress, e - Egress
* - Active, M - Manually set active, F - Forced active
O - Ok, W - Degraded, E - Error
Group Primary Backup
i> lpgrsvp R2R5W [ *O] R2R5P [ O]
At Sink side, show protection lsp gives some output.
To test the protection switching, use the following command at Sink NODE5:
Command Description
NODE5# protection force-switchover lsp
lpg-rsvp R2R5P
This command allows testing of the protection
switching.
If Sink NODE5 does not recognize RSVP TRUNKs congured in Source NODE2, the most
possible reason is either the connection between the two NODEs does not work or the
interfaces are not congured correctly.
50123_02 Tellabs

57
2.4.2 LSP 1+1 Protection with Static Tunnels
SOURCE NODE conguration
Command Description
NODE2(config)# mpls static-ftn push
10.123.100.45/32 12345 fe 4/0/7
172.168.7.4 name R2R5S-W lsp-id 123
NODE2(config)# mpls static-ftn push
10.123.100.45/32 23456 fe 8/0/7
172.168.7.8 name R2R5S-p lsp-id 234
Creates two MPLS static tunnels R2R5S-W and
R2R5S-P. 10.123.100.45/32 is the destination
address which uses this route, fe 4/0/7 172.168.7.4
and fe 8/0/7 172.168.7.8 are the egress interfaces.
NODE2(config)# mpls oam ingress manual
R2R5S-W ttsi-send 10.123.100.42 123
send-interval 10
NODE2(config)# mpls oam ingress manual
R2R5S-P ttsi-send 10.123.100.42 234
send-interval 10
Creates two OAM instances. 10.123.100.42 is LSR
ID (IPv4 address).
NODE2(config)# protection lsp ingress
lpg-static
NODE2(cfg-protection-lsp[lpgstatic])#
primary R2R5-S-W
backup R2R5S-P
exit
Creates protection group lgp-static.
Tellabs

58
SINK NODE conguration
Command Description
NODE5(config)# mpls static-ilm pop
fe 5/0/7 12345 lo0 10.123.100.45 name
R2R5S-W
NODE5(config)# mpls static-ilm pop
fe 7/0/7 23456 lo0 10.123.100.45 name
R2R5S-P
Creates two MPLS static tunnels R2R5S-W and
R2R5S-P. fe 5/0/7 and fe 7/0/7 are the ingress
interfaces.
NODE5(config)# mpls oam egress manual
R2R5S-W ttsi-expected 10.123.100.42
123 expected-interval 10
NODE5(config)# mpls oam egress manual
R2R5S-P ttsi-expected 10.123.100.42
234 expected-interval 10
NODE5(config)# protection lsp egress
lpg-static
primary R2R5-S-W
backup R2R5S-P
exit
Creates protection group lpg-static.
Check the congurations and Protection status
Congurations and protection status can be checked with CLI show command at source NODE2
and sink NODE5, for examples:
Command Description
NODE2(config)# show mpls ftn static
NODE5(config)# show mpls ilm static
NODE2(config)# show protection lsp
The conguration status is checked from the rst
two commands at source and sink nodes. The last
command shows the protection status.
2.5 FRR CLI Conguration Examples
This chapter provides CLI conguration examples of FRR.
FRR is currently supported by the Tellabs 8620 access switch, Tellabs 8630 access switch and
Tellabs 8660 edge switch.
FRR conguration guidelines:
50123_02 Tellabs

59
One-to-one backup
Congure protected path and enable FRR (protection type)
Specify the attributes desired for the protection path if required, otherwise default attributes
are applicable
Dene backup identication method
Facility backup
Congure protected path and enable FRR (protection type)
Congure bypass tunnels to all links or nodes requiring protection
The following topology is used as an example for FRR congurations.
Fig. 15 FRR One-to-one Backup Method
2.5.1 FRR One-to-One
This section provides examples of how to congure FRR one-to-one protection. The example
covers basic FRR congurations at Head-End for link protection. Node protection follows the
same conguration procedures.
Command Description
router# configure terminal
router(config)# router rsvp
router(cfg-rsvp)#
Use this command to enter Router RSVP-TE
Conguration mode.
router(cfg-rsvp)# cspf-type isis Specify database for CSPF. Default is OSPF-TE
database.
Tellabs

60
router(config)# rsvp-path plsp-123
router(cfg-rsvp-path[plsp-123])#
192.168.91.221 strict
192.168.92.126 strict
192.168.98.124 strict
192.168.96.123 strict
router(cfg-rsvp-path[plsp-123])# exit
Specify an explicit protected path to be used.
router(config)# rsvp-trunk frr-N211-
N123
router(cfg-rsvp-trunk[frr-N211N123])#
primary fast-reroute protection
one-to-one
primary path plsp-123
primary label-record
primary elsp-preconfigured
map-route 10.123.100.123/32
to 10.123.100.123
exit
Congure RSVP trunk. Specify protection type
(one-to-one backup). Map an IP destination route
10.123.100.123 onto the current trunk.
router(cfg-rsvp)# detour from
10.123.101.211
Specify detour source IP address.
router(cfg-rsvp)# detour identification
sender-template
Set detour LSP identication method, in this
example Sender Template-Specic method is set.
Default is Path-Specic.
At this stage the basic FRR setups are accomplished. The following examples illustrate FRR
conguration status information from the Head-End N211, transit node N221 and the egress node
N123.
Command Description
router-N211# show rsvp session name
frr-N211-N123
Display session-related information for the
congured P-LSP frr-N211N123 at the Head-End
N211.
Head-End (N211) RSVP Session Information
Ingress (Primary) 10.123.100.123
From: 10.123.100.211, LSPstate: Up, LSPname: frr-211-123
CSPF usage: Enabled, CSPF type: ISIS, CSPF Retry Count: 0,
CSPF Retry Interval: 30 seconds, CSPF metric: 24
Reoptimization: disabled
Fast Reroute Recovery: reoptimize
FRR Mode: one-to-one
50123_02 Tellabs

61
LSP partially protected
Tspec rate: 0, Fspec rate: 0
Downstream: 192.168.91.221, ge2/0/7
Resv lifetime: 157 seconds (due in 142 seconds)
Label Recording: Enabled
Admin Groups: none
Configured Path: plsp-123 (in use)
Configured Explicit Route Detail:
192.168.91.221/32 strict
192.168.92.126/32 strict
192.168.98.124/32 strict
192.168.96.123/32 strict
192.168.91.221/32 strict
192.168.92.126/32 strict
192.168.98.124/32 strict
192.168.96.123/32 strict
Record route:
<self> no protection
192.168.91.221 link protected 87109
192.168.92.126 link protected 90245
192.168.98.124 link protected 1965
192.168.96.123 no protection 1920
Traffic type: controlled-load
QoS Reservation Reference Count: 1
Ingress (Primary detour) 10.123.100.123
From: 10.123.100.211, LSPstate: Dn, LSPname: frr-211-123
CSPF usage: Enabled, CSPF type: ISIS, CSPF Retry Count: 0
CSPF Retry Interval: 30 seconds
FRR Mode: None
Label in: -, Label out: -,
Downstream: 10.123.91.10, N/A
Retry count: 0, intrvl: 30 seconds,
next retry in: 11 seconds
Admin Groups: none
Configured Path: none
10.123.91.10/32 strict
10.123.91.14/32 strict
10.123.91.18/32 strict
Tellabs

62
10.123.91.22/32 strict
192.168.98.124/32 strict
192.168.96.123/32 strict
Record route:
<self> no protection ...incomplete
Command Description
frr-N211-N123
Display session-related information at transit node
N221.
Transit node (N221) RSVP Session Information
Transit 10.123.100.123
Label in: 87109, Label out: 90245
Downstream: 192.168.92.126, ge13/1/4
Upstream: 192.168.91.211, ge13/1/1
Path lifetime: 157 seconds (due in 147 seconds)
Admin Groups: none
192.168.91.221/32 strict
192.168.92.126/32 strict
192.168.98.124/32 strict
192.168.96.123/32 strict
192.168.92.126/32 strict
192.168.98.124/32 strict
192.168.96.123/32 strict
Record route:
192.168.91.211 no protection 87109
<self> link protected
192.168.92.126 link protected 90245
192.168.98.124 link protected 1965
192.168.96.123 no protection 1920
Ingress (Detour) 10.123.100.123
50123_02 Tellabs

63
CSPF usage: Enabled, CSPF type: ISIS, CSPF Retry Count: 0
CSPF Retry Interval: 30 seconds, CSPF metric: 16
FRR Mode: None
Label in: -, Label out: 87093
Downstream: 10.123.91.18, so10/1/0
Admin Groups: none
Configured Path: none
10.123.91.18/32 strict
10.123.91.22/32 strict
192.168.98.124/32 strict
192.168.96.123/32 strict
Record route:
10.123.91.18 no protection 87093
10.123.91.22 no protection 90246
192.168.98.124 no protection 1965
192.168.96.123 no protection 1920
Transit 10.123.100.123
From: 10.123.100.211, LSPstate: Dn, LSPname: frr-211-123
FRR Mode: None
Label in: -, Label out: -,
Downstream: 10.123.91.18, so10/1/0
Upstream: 10.123.91.13, so2/1/0
Admin Groups: none
10.123.91.14/32 strict
10.123.91.18/32 strict
10.123.91.22/32 strict
192.168.98.124/32 strict
192.168.96.123/32 strict
Tellabs

64
10.123.91.18/32 strict
10.123.91.22/32 strict
192.168.98.124/32 strict
192.168.96.123/32 strict
Record route:
10.123.91.9 no protection
10.123.91.13 no protection
<self> no protection ...incomplete
Traffic type: N/A, Minimum Path MTU: N/A
Command Description
frr-211-123
Display session-related information at egress node
N123.
Egress (N123) RSVP Session Information
Egress 10.123.100.123
Label in: 1920, Label out: -,
Upstream: 192.168.96.124, ge0/2
Admin Groups: none
192.168.96.123/32 strict
Record route:
192.168.91.211 no protection 87109
192.168.92.221 no protection 90245
192.168.98.126 no protection 1965
192.168.96.124 no protection 1920
DSTE Class Type Number: 0, Class Type name: default
Uptime: 00:48:25, Total uptime: 00:48:25,
First up: 00:48:25 ago
State transitions: 1
Egress FSM state: Operational
Node where Last Recorded Error originated: None
50123_02 Tellabs

65
Previous Recorded Error Code: None
Previous Recorded Error Value: None
Node where Previous Recorded Error originated: None
Egress 10.123.100.123
FRR Mode: None
Label in: 1937, Label out: -,
Upstream: 192.168.97.122, ge0/4
Admin Groups: none
192.168.97.123/32 strict
Record route:
192.168.99.124 no protection 1940
192.168.97.122 no protection 1937
2.5.2 Facility Backup
This section provides conguration examples of FRR facility backup. The conguration is based
on the network topology presented in Fig. 15.
Tellabs

66
Command Description
router(config)# rsvp-trunk frr-N211-
N123
primary fast-reroute protection
facility
primary path plsp-123
primary setup-priority 0
no primary diffserv-object
primary class-type ct0
primary elsp-preconfigured
from 10.123.100.211
map-route 10.123.100.123/32
to 10.123.100.123
exit
Create RSVP trunk of the protected path. Enable
FRR by specifying protection type, in this example
facility backup is declared and also the path to be
used. Map a destination IP route 10.123.100.123
onto the bypass tunnel.
The following example shows how to congure link protection in facility backup. To protect the
link between nodes N211 and N126, bypass tunnel shall be routed via node N131 and merge
in node N126.
Command Description
router(cfg-rsvp)# rsvp-bypass
bypass221126
router(cfg-rsvp-path[bypass221126])#
bypass-for link 192.168.92.221
map-bypass 192.168.92.126
label-record
elsp-preconfigured
from 10.123.100.221
to 10.123.100.126
exit
Create bypass tunnel that will protect
communication link 192.168.92.221 against
failure. With command map-bypass specify the
match list with protected LSP(s) RRO. Specify
the PLR node (10.123.100.221) and MP node
(10.123.100.126).
Note that to fully protect the primary session, all
links must be congured in similar way as shown
in this step.
The following example shows how to congure node protection in facility backup. To protect
node N221 against failure, bypass tunnel shall be routed via nodes N215 and N131 and merge
in node N126.
50123_02 Tellabs

67
Command Description
router(cfg-rsvp)# rsvp-bypass
bypassN221
router(cfg-rsvp-path[bypassN221])#
bypass-for node 192.168.92.221
map-bypass 192.168.92.126
router(cfg-rsvp-path[bypassN221)#
label-record
elsp-preconfigured
from 10.123.100.211
router(cfg-rsvp-path[bypassN221])# to
10.123.100.126
exit
Create bypass tunnel that will protect node N221
communication link 192.168.92.221 against failure.
With command map-bypass specify the match list
with protected LSP(s) RRO. Specify the PLR node
(10.123.100.211) and MP node (10.123.100.126).
Tellabs

68

MPLS Applications Configuration Guide

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

MPLS Applications Configuration Guide

Caricato da

Copyright:

Formati disponibili

Tellabs

8600 Managed Edge System

logo, TELLABS and T symbol

8600 Managed Edge System 50123_02

8600 Managed Edge System

8600 Managed Edge System 50123_02

8600 Managed Edge System

8600 Managed Edge System 50123_02

8000 Network Manager provides access to

8600 Managed Edge System

8600 Managed Edge System VPNs

8600 Managed Edge System CLI

8600 Managed Edge System Routing

8600 Managed Edge System Test and

8600 Managed Edge System CLI Commands Manual.

8600 Managed Edge System 50123_02

8600 Managed Edge System

8600 Managed Edge System VPNs Conguration Guide.

8600 Managed Edge System 50123_02

8600 Managed Edge System VPNs Conguration Guide.

8600 Managed Edge System

8600 Managed Edge System 50123_02

8600 Managed Edge System

8600 Managed Edge System 50123_02

8600 Managed Edge System

8600 Managed Edge System 50123_02

8600 Managed Edge System

8600 Managed Edge System 50123_02

8600 Managed Edge System

8600 Managed Edge System Routing Protocols Conguration Guide for

8600 Managed Edge System 50123_02

8600 Managed Edge System

8600 Managed Edge System 50123_02

8600 Managed Edge System

8600 Managed Edge System 50123_02

8600 Managed Edge System MPLS

8600 Managed Edge System

8600 Managed Edge System 50123_02

8600 Managed Edge System Test and

8600 Managed Edge System

8600 Managed Edge System 50123_02

8600 Managed Edge System

8600 Managed Edge System 50123_02

8600 Managed Edge System Routing Protocols Conguration Guide.

8600 Managed Edge System

8600 Managed Edge System 50123_02

8600 Managed Edge System

8600 Managed Edge System 50123_02

8600 Managed Edge System

8600 Managed Edge System 50123_02

8600 Managed Edge System

8600 Managed Edge System 50123_02

8600 Managed Edge System

8600 Managed Edge System 50123_02

8600 Managed Edge System

8600 Managed Edge System Routing Protocols

8600 Managed Edge System 50123_02

8600 Managed Edge System

8600 Managed Edge System 50123_02

8600 Managed Edge System

8600 Managed Edge System 50123_02

8600 Managed Edge System

8600 Managed Edge System 50123_02

8600 Managed Edge System