MPLS Applications Configuration Guide

Tellabs 8600 Managed Edge SystemMPLS Applications Configuration Guide

50123_0230.10.09

Document Information

Revision History

DocumentNo.

Date Description of Changes

50123_02 30.10.09 Added LSP affinity bits usage in 1.3 LSP Affinity Constraints.Added FRR in 1.7 Fast Reroute. One-to-one backup

Facility backup

FRR fault management

FRR CLI examples 2.5 FRR CLI Configuration 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 andtreaties. Your right to use this manual is subject to limitations and restrictions imposed by applicable licenses and copyright laws.Unauthorized reproduction, modification, 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 affiliates 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 specifications 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_02MPLS Applications Configuration 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 Traffic 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 8600 Managed Edge System 2009 Tellabs. MPLS Applications Configuration 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 Traffic Engineering Extensions

RT Real Time

SDH Synchronous Digital Hierarchy

SONET Synchronous Optical Network

TCP Transmission Control Protocol

TE Traffic Engineering

ToS Type of Service

UDP User Datagram Protocol

VC Virtual Circuit

VoIP Voice over Internet Protocol

VPN Virtual Private Network


4

Table of Contents

Table of Contents

About This Manual ............................................................................................................ 7

Objectives....................................................................................................................................................................... 7Audience......................................................................................................................................................................... 7Related Documentation .................................................................................................................................................. 8Interface Numbering Conventions ................................................................................................................................. 8Document Conventions .................................................................................................................................................. 8Documentation Feedback............................................................................................................................................... 9

1 MPLS Overview ........................................................................................................... 10

1.1 Label Distribution................................................................................................................................................ 111.1.1 LDP...................................................................................................................................................... 111.1.2 RSVP-TE............................................................................................................................................. 11

1.2 MPLS Support of Differentiated Services........................................................................................................... 121.2.1 EXP-Inferred-PSC LSPs (E-LSP) ...................................................................................................... 121.2.2 Label-Only-Inferred-PSC LSPs (L-LSP) ............................................................................................ 121.2.3 DiffServ Tunneling Models over MPLS ............................................................................................. 12

1.3 LSP Affinity Constraints ..................................................................................................................................... 161.4 MPLS Protection Switching ................................................................................................................................ 18

1.4.1 MPLS Local Protection ....................................................................................................................... 191.4.2 RSVP-TE based 1:1 Protection Switching .......................................................................................... 191.4.3 MPLS OAM based 1+1 Protection Switching ................................................................................... 19

1.5 MPLS Traffic Engineering................................................................................................................................... 201.6 DiffServ-Aware MPLS Traffic Engineering ........................................................................................................ 21

1.6.1 Maximum Allocation Model ............................................................................................................... 211.6.2 Russian Dolls Model ........................................................................................................................... 22

1.7 Fast Reroute......................................................................................................................................................... 221.7.1 Overview ............................................................................................................................................. 221.7.2 FRR Application.................................................................................................................................. 22

1.8 MPLS References ................................................................................................................................................ 30

2 MPLS Configuration Examples .................................................................................. 31

2.1 LDP Configuration .............................................................................................................................................. 312.2 Explicitly Routed RSVP-TE LSPs ...................................................................................................................... 31

2.2.1 RSVP-TE Configuration...................................................................................................................... 322.2.2 E-LSP Configuration ........................................................................................................................... 332.2.3 L-LSP Configuration ........................................................................................................................... 352.2.4 RSVP-TE Path Protection Configuration ............................................................................................ 372.2.5 DiffServ Tunneling Model Configuration ........................................................................................... 38


5

Table of Contents

2.3 DS-TE Network Example.................................................................................................................................... 382.4 LSP 1+1 Protection Configuration Example ....................................................................................................... 55

2.4.1 LSP 1+1 Protection with RSVP Tunnels............................................................................................. 552.4.2 LSP 1+1 Protection with Static Tunnels.............................................................................................. 58

2.5 FRR CLI Configuration Examples ...................................................................................................................... 592.5.1 FRR One-to-One.................................................................................................................................. 602.5.2 Facility Backup.................................................................................................................................... 66


6

About This Manual

About This Manual

This chapter discusses the objectives and intended audience of this manual, Tellabs 8600ManagedEdge System MPLS Applications Configuration 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 applicationsand instructions on how to configure them with a Command-line Interface (CLI) using a routersconsole or remote terminal (telnet).

Audience

This manual is designed for administration personnel for configuring Tellabs 8600 managed edgesystem functions with CLI. On the other hand, Tellabs 8000 Network Manager provides access toequal functionality for administration personnel with a graphical user interface.

It is assumed that you have a basic understanding of Ethernet, POS, IP, MPLS, VPN andDifferentiated Services concepts. This manual also assumes that you are familiar with the followingprotocols:

IP routing

UDP

TCP

Differentiated Services


7

About This Manual

Related Documentation1

Tellabs 8600 Managed Edge System VPNsConfiguration Guide (50128_XX)

Provides an overview of Tellabs 8600 systemvirtual private network (VPN) functions andinstructions on how to configure them with CLI.

Tellabs 8600 Managed Edge System CLICommands Manual (50117_XX)

Provides commands available to configure,monitor and maintain Tellabs 8600 managed edgesystem products with CLI.

Tellabs 8600 Managed Edge System RoutingProtocols Configuration Guide (50121_XX)

Provides an overview of Tellabs 8600 systemrouting protocol functions and instructions on howto configure them with CLI.

Tellabs 8600 Managed Edge System Test andMeasurement Configuration Guide (50124_XX)

Provides an overview of Tellabs 8600 managededge system testing and measurement tools,connectivity verification and instructions forconfiguring them with CLI.

Interface Numbering Conventions

To be able to follow more easily the feature descriptions and configuration examples given in thisdocument, see also the Tellabs 8600 system interface numbering and related figures described inTellabs 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 instructionsare not followed.

This is a warning symbol. It indicates that bodily injury is possible if the instructions are notfollowed.

1To make sure the references point to the latest available document versions, please refer to the Tellabs 8600 Document Set Description that can befound in Tellabs Portal www.portal.tellabs.com by navigating to Product Documentation -> Data Networking-> Tellabs 8600 Managed Edge System-> Technical Documentation-> Document Set Description.


8

About This Manual

Documentation Feedback

Please contact us to suggest improvements or to report errors in our documentation:

Email: [email protected]

Fax: +358.9.4131.2430


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 theIP network infrastructure of the service provider. The ongoing MPLS deployments add value both interms of enabling state-of-the-art network engineering techniques, and also in terms of enabling theintroduction of new types of end-user service offerings. Most notably, the new network engineeringtechniques include MPLS Traffic Engineering (TE), Differentiated Services (DiffServ) aware MPLSTraffic Engineering, and different types of LSP-based network protection schemes.

In addition to aiding many network engineering tasks in operational Internet Protocol (IP) routinginfrastructure of the service provider, LSPs are also extremely useful on the network servicelayer, where they can be used as Virtual Private Network (VPN) tunnels through shared networkinfrastructure. The MPLS-based VPN applications supported by the Tellabs 8600 Network Elements(NE) are described in Tellabs 8600 Managed Edge System VPNs Configuration Guide.


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 MPLSnetwork have to first agree on the label values to be used for each label-switched path. Whenentering an MPLS domain, a short, fixed-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 significancealong each path, i.e. each label switching node swaps the incoming label value to an outgoing labelvalue, 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 Traffic Engineering extensions (RSVP-TE).

In the [RFC4364] VPN application, also Multiprotocol Border Gateway Protocol (MP-BGP) is usedfor carrying labels between the ingress and egress Provider Edge (PE) nodes. This topic is detaileddiscussed in the Tellabs 8600 Managed Edge System VPNs Configuration Guide.

1.1.1 LDP

LDP is a session protocol that uses Transmission Control Protocol (TCP) as a transport layer. Adiscovery mechanism based on the User Datagram Protocol (UDP) automatically builds LDPsessions between directly connected LSRs. Once an LDP session is established, it distributeslabel 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 Unsolicitedmode, in which label information is sent without waiting for a request. Only one of these modes isused at a time.

1.1.2 RSVP-TE

RSVP-TE is a signaling protocol used for reserving labels and bandwidth across an explicitlyrouted network path. For accommodating LSP construction, MPLS traffic engineering extensionshave been added to the traditional RSVP protocol used in conjunction with the IntServ Quality ofService (QoS) model. These traffic engineering extensions are defined in [RFC3209]. To envisionan RSVP-TE LSP tunnel, remember that it is a virtual trunk that makes one Tellabs 8600 NEappear to be directly connected to another Tellabs 8600 NE. As with all LSPs, an RSVP-TE LSP isunidirectional. In order to get bidirectional data flow between two nodes A and B, an LSP must bebuilt first from A to B, and then from B to A.

In case the RSVP-TE tunnel LSPs are signalled with bandwidth reservations, each Tellabs 8600NE on the signaling path performs Connection Admission Control (CAC), in order to determinewhether 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 8600NEs (typically the ones acting as edge LSRs at the edge of the MPLS network domain).


11

1 MPLS Overview

1.2 MPLS Support of Differentiated Services

[RFC3270] defines a solution for supporting DiffServ over MPLS networks. It defines two differenttypes of LSPs, which differ in the way the carried DiffServ Per Hop Behavior (PHB) SchedulingClass(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. The3-bit EXP field of the MPLS shim header conveys to the LSRs the appropriate PHB (both dropprecedence and scheduling class) to be applied to the packet. The mappings between the EXP fieldvalues and the PHBs are either explicitly signalled, or rely on the preconfigured 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 orderingconstraint. These include e.g. packets belonging to the AF11, AF12, and AF13 PHBs. This isimplemented 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 isexplicitly 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 separateinstances of DiffServ PHB information, i.e. the DiffServ Code Point (DSCP) marking on the carrieddatagram itself, and the PHB information inferred from the MPLS shim header fields. In the case ofthe [RFC4364] VPN applications, there are two MPLS shim headers, and thus each VPN datagramcan carry even three different PHB markings. This inherent property of MPLS LSPs allows theinner PHB information to be transparently carried over the MPLS network, which can be very usefulwhen the MPLS network domain belongs to a different QoS policy domain than the one whose IPpackets the LSP is carrying.

Some MPLS networks may also make use of Penultimate Hop Popping (PHP), which means that theoutermost label is popped out already at the last hop before the egress LSR. If the outermost MPLSshim header does not contain any useful label switching or DiffServ information from the point ofview 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 ofthe traversed LSP, depends on the chosen DiffServ Tunnelling Model. The three models defined 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.


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 significant bits of the DSCP field are used for selecting the forwardingtreatment. The reason for not using the standardized EF codepoint for VoIP is that some legacyVoIP terminals and/or networking equipment may not even support processing of the whole 6bitDSCP field, but can instead only process the 3 precedence bits specified in the original IP Type ofService (ToS) octet definition.

Thus, if the network of the service provider uses only the EF PHB and its standardized codepointfor VoIP, and therefore does not have any specific configurations for the Class Selector codepointsin 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 DiffServmulti-field classifiers for reclassifying the VoIP packets to the EF PHB. However, if the VoIP trafficwill re-enter the network of the enterprise after the LSP is terminated, the DSCP field of the VoIPpacket should preferably not be overwritten, but the chosen MPLS domain PHB should instead beindicated only in the MPLS shim header fields.

In this way, the LSRs can use the outermost, service provider controlled DiffServ informationfor their queuing decisions, while the innermost, enterprise-controlled DiffServ information getstransparently carried over the whole MPLS network domain. Thus, when the LSP is terminatedin the egress LSR and the VoIP packets are delivered back into the QoS policy domain of theenterprise, the delivered packets will still be marked with the original CS5 codepoints.

The following tunnelling model specific examples deal only with the basic case of encapsulatingIP packets inside single level label stacks. However, the very same techniques can also be appliedto multilevel label stacks, i.e. the DiffServ tunnelling actions are always applied to each label inthe stack at the ingress and egress points of the LSPs, i.e. the points of pushing and popping thelabel in question.

Pipe Model

The Pipe Model is the only mandatory tunneling model in [RFC3270] and is also the Tellabs 8600system default model. Since the egress LSR makes use of both the inner and the outer DiffServinformation, it can only be used without PHP, as illustrated below.


13

1 MPLS Overview

Fig. 1 Pipe Model

In the above example with one level label stack, (M) denotes the outer MPLS shim header DiffServinformation and (D) the inner IP header DSCP field DiffServ information. All LSRs on the labelswitched path, including the egress LSR, use the outer MPLS header DiffServ information forselecting the appropriate PHB (e.g. the EF forwarding treatment typically used for VoIP). The innerDiffServ 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 theShort Pipe Model the DiffServ forwarding treatment at the egress LSR is chosen based on theinner DiffServ information.

The Short Pipe Model can be used with or without PHP, as illustrated below.

Fig. 2 Short Pipe Model


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 isalways encoded in the outer most label entry. Thus, in spite of being categorized as a DiffServtunnelling model, the Uniform Model effectively does not tunnel any DiffServ information throughthe MPLS network.

The Uniform Model can be used with or without PHP, as illustrated below.

Fig. 4 Uniform Model


15

1 MPLS Overview

Fig. 5 Uniform Model with PHP

1.3 LSP Affinity Constraints

This section describes how affinity constraints of MPLS LSPs are related to "include" and"exclude" attributes of VPN routes and pseudowires.

Although LSP affinity constraint bits are logically similar in function to MPLS administrativegroups (aka link colors, aka link affinities), they are not related and are completelyindependent of each other. For example include-any given for link color for RSVP trunk hasno effect on PWE3 association for RSVP trunk.

By default any inner LSP (L3VPN, PWE3) can use any outer LSP (LDP, RSVP, static) that is goingto a desired destination. The constraints are constructed from two parts:

Affinities 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 ifthe inner LSP has some include or exclude constraints. This rule makes LDP more flexible andeasy to use. Affinities and protocol limits on outer LSP take form "[IP] [MPLS 0xnnnnnnnn]". If[IP] is present, the LSP can be used for pure IP routed traffic. If [MPLS 0xnnnnnnnn] is present,the PWE3 can be used by inner LSPs that match the outer LSPs affinities. The outer LSP canhence have the following configuration options:

Both IP routed traffic and unlimited MPLS (PWE3, L3VPN) traffic can use the LSP, i.e. noconstraints

Both IP routed traffic and selected MPLS (PWE3, L3VPN) traffic can use the LSP


16

1 MPLS Overview

Only IP routed traffic can use the LSP, but no inner labels are associated with the LSP

Selected MPLS (PWE3, L3VPN) traffic can use the LSP. No IP traffic is directed to the LSP (itshould be noted that L3VPN traffic is MPLS, as it has inner-label)

The outer label affinities 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 onmany criteria, such as prefix and the neighbor who advertised the label

Static by using the "mpls static-ftn push" command

Affinity constraints are characterized by a mask value. The mask is usual expressed in hexadecimalformat, but it is interpreted as a string of a 32 bits. For example a mask "0x30A" is interpreted asfollowing:

00000000 00000000 00000011 00001010

Of the 32-bits in this example, four bits namely the second, fourth, ninth and tenth from right areused to constraint the given path. The meaning of these bits in the 32-bit vector is defined by the user.

For the example above, lets give some example of what meaning the user may assign to thesefour 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 specified bit must match the outer LSP affinity

include-all, all of the specified bits must match the outer LSP affinity

exclude-any, none of the specified bits may be present in outer LSP affinity

One rule of each type can be specified:

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 destinationwith suitable QoS class) that does not have IP only constraints. On the other hand, traffic thatuses LSPs, like VPN traffic or pseudowire traffic, can be configured so that affinity is taken intoaccount when deciding which traffic uses a given LSP. For VNP traffic, this is done with commands"exclude-any", "include-all" and "include-any". For other traffic types, e.g. pseudowires, thisis done with attributes exclude-any, include-all and include-any in the commands like "mplsstatic-ftn".

Example:

mpls static-ftn push-and-lookup-for-vc abc 313 1.2.3.4include-any 0x1f0 include-all 0xa exclude-any 0x1


17

1 MPLS Overview

This example is very complex, however is presented here to illustrate how the constraints work inmost general cases. When deciding which tunnel traffic 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 affinity is configured as:

Tunnel affinity: 00000000 00000000 00000011 00001010

The following constraint masks are configured 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 (andare in fact zero by default). Zero masks logically do not constraint the choice of LSP at all. But ifthe 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 affinity mask must have at leastone corresponding bit set to non-zero. In the example above, the ninth bit from right fulfils thiscondition

Every bit that is set in include-all mask must also be set in affinity mask. In the example above,the second and fourth bits from right are required, and this requirement is fulfilled

Every bit that is set in exclude-any mask must be absent in affinity mask. In the example above,the right most bit is required to be absent in the affinity mask, and indeed it is absent

In this example, the affinity mask passes all three tests and VC "abc" can use the tunnel. If at leastone test had failed, the tunnel would not have been used for this particular VC.

MPLS constraints should only be used when the specified LSP is required for a given inner label. Agood reason would for example be to redirect some traffic to protected LSP while leaving the rest touse LDP. In that case one could indicate protected quality with single bit, and do include-any forthat bit for the traffic that desires protection, while doing exclude-any for the rest. Alternativelyunprotected LSPs could have another bit that is used for the rest of the LSPs. Affinities are notrequired for associating QoS of specific PWE3s to suitable L-LSPs (or E-LSPs that carry only fewQoS classes), because "map-route" does contain separate QoS specifier 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 forimplementing different types of protection schemes. As an example, different types of end-to-endpath protection techniques between the ingress and the egress edge LSRs can be accommodated bysignalling two explicitly routed point-to-point LSPs, traversing diverse physical routes. Since thetraffic rerouting decisions and protection LSP setup procedures have been done already before anyfailures occur, these techniques enable significantly faster network and traffic restoration times thannormal traffic rerouting functionality, and especially if the rerouting decisions also require initiationof subsequent signalling procedures for LSP reestablishment.


18

1 MPLS Overview

Furthermore, the speed of the protection switching also depends both on the conceptual protectionmodel, and the used triggering mechanisms. In general, 1+1 type of protection schemes are usuallythe fastest, but also consume a double amount of capacity from the network. The speed of othertypes of protection models often depends on the mechanisms used for propagating the faultinformation along the LSPs route to the NEs doing the protection switching, which in end-to-endpath protection cases are the edge LSRs. Typically, such triggering mechanisms that reside asclose as possible to the protected networking layer function much faster than purely control planesoftware based mechanisms.

1.4.1 MPLS Local Protection

In an MPLS-based network local protection can be achieved by switching traffic onto a presetbackup path with a technique known as Fast Reroute (FRR). The main advantage of FRR as aprotection solution is its capability of using local repair methods to guarantee fast failure responseand 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, Tellabs8630 access switch and Tellabs 8660 edge switch is RSVP-TE-based LSP path protection, wheretraffic is switched from a primary LSP to a pre-signalled secondary LSP in case the primary LSPgoes down. This protection mechanism uses a combination of L1 defect, RSVP-TE signalling, andL3 routing information as the possible triggers for determining that the primary LSP is down. Thefastest restoration times are typically achieved if the failure can be detected locally by the NE doingthe actual switching, but for pseudowire traffic the switchover time should always be below 50milliseconds 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 alsosupport the ITU-T MPLS OAM [Y.1711] based unidirectional 1+1 path protection switchingmechanism described in [Y.1720]. In this mode, the ingress edge LSR forwards the traffic to theegress 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 traffic, 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...7200seconds after the LSP-connectivity has been restored.

In Tellabs 8630 access switch and Tellabs 8660 edge switch the primary and the protectingLSP must reside in different line cards, and the protection feature only works on Ethernetports and otherwise unprotected POS ports (i.e. ports not already protected by any L1 basedprotection schemes).

The sending frequency of the FFD packets has a strong affect on the speed of the protectionswitching, and is thus user configurable, with a default value of 1 packet in 50 milliseconds. Theprotection switching is initiated as soon as the egress edge LSR detects that 3 consecutive FFDpackets have been lost in the primary LSP tunnel. Thus, by using the fastest sending frequency of 1packet in 10 milliseconds, even restoration times well below 50 milliseconds are achievable.


19

1 MPLS Overview

Please note that 1+1 protection is not supported for MPLS over VLAN based configurationswhen 2x1000BASE-X IFM is used.

1.5 MPLS Traffic Engineering

[RFC2702] specifies the requirements for Traffic Engineering over MPLS. Instead of the moretraditional TE methods, explicitly routed point-to-point LSPs offer a more efficient and controlledway to perform traffic engineering. In addition to [RFC2702], Internet Engineering Task Force(IETF) has also specified protocol-specific TE extensions for the most common Interior GatewayProtocols (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 theselected MPLS deployment model and network engineering applications.

There are traditional TE methods such as adjusting the IGP metrics on a congested link, or relyingon 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 beperformed without making any bandwidth reservations in the network. This can be accomplishedsimply by diverting some of the traffic on a congested link to an explicitly routed point-to-point LSPthat bypasses it. As soon as the link congestion has been detected, a new TE tunnel can be set upbetween a selected pair of LSRs in the network (often a pair of edge LSRs), and simply signalledonto a different route than the shortest path that would be selected by the IP routing protocols.Next, some of the traffic traversing the congested link can be redirected to it, thus relieving thecongestion. In practise, these types of manual TE operations rely totally on online monitoring of thelink utilizations in the network, and require reactive deployment of MPLS TE tunnels (or their L2equivalents) only in the event of some link(s) getting congested.

In order to proactively prevent the congestion from happening in the first place, bandwidthreservations can be made for the traffic trunks with a controlled load (i.e. appropriately policed),traversing the MPLS network. In this MPLS deployment model, the RSVP-TE path requests aresubjected to Connection Admission Control (CAC) at each Tellabs 8600 NE. For performingautomated 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 decisionscan be made automatically by the head-end LSRs, since all nodes in the network use the TEextensions of the selected IGP for advertising the amount of available bandwidth on the directlyattached network links. When a new traffic trunk is to be set up in the network, the head-end LSRuses the CSPF algorithm for calculating the shortest possible path through the network that stillhas enough unreserved bandwidth left to accommodate the needs of the new tunnel LSP. In thisdeployment model, a full mesh of TE tunnels is often deployed between all of the edge LSRs in thenetwork, and most of the end user traffic is mapped on the resulting, logical TE topology.

Please refer to Tellabs 8600 Managed Edge System Routing Protocols Configuration Guide formore information on different types of routing protocols, and their configuration details.


20

1 MPLS Overview

1.6 DiffServ-Aware MPLS Traffic Engineering

The requirements for DiffServ-aware MPLS Traffic Engineering (DS-TE) have been specified in[RFC3564]. Instead of setting up aggregate LSPs for carrying all traffic classes (as in the basic formof MPLS TE), the DS-TE approach performs MPLS traffic engineering at a per-class level. InDS-TE, the traffic from different DiffServ classes of service is mapped to separate LSPs. Also thenetwork resources have been divided among the different traffic classes, and the IGP TE extensionsadvertise 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, whichhas prompted the need for different types of Bandwidth Constraint (BC) models. The BC modelssupported by the Tellabs 8600 system are the Maximum Allocation Model (MAM), and the RussianDolls Model (RDM).

1.6.1 Maximum Allocation Model

MAM [RFC4125] is the most intuitive and the most simple BC model. It provides good isolationbetween the resources allocated to different CTs, but may in some cases not be the most efficientmodel in terms of achieved network utilization. MAM implements an individual BC for eachCT, and can also limit the aggregate of reserved bandwidth across all CTs, as illustrated in thefollowing figure.

Fig. 6 Maximum Allocation Model (MAM) by IETF


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 togetherwith LSP pre-emption, RDM can offer good isolation between CTs and also efficient utilization ofthe network resources. The CT and BC structure of RDM are illustrated in the following figure.

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 trafficprotection. This means that when a failure occurs, a fast response and timely switchover close aspossible 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 traffic on backup paths aroundthe point of failure. When a failure occurs the node immediately upstream of the point of failure willswitch traffic 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 backuppaths. To protect downstream links or nodes, each node on the protected path can act as a Point ofLocal Repair (PLR).

1.7.2 FRR Application

In the Tellabs 8600 system FRR is implemented according to [RFC4090]. There are two differentvariants of FRR:


22

1 MPLS Overview

One-to-one backup

Facility backup

FRR is currently supported by the Tellabs 8620 access switch, Tellabs 8630 access switch andTellabs 8660 edge switch.

Both FRR variants can be configured to provide either link or node protection.

In link protection, if a link is faulted PLR will bypass that link by switching traffic to detour LSPor bypass tunnel.

In node protection, if a node is faulted PLR will bypass that node by switching traffic to a backuppath.

FRR defines 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 backingup 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 traffic around a failure in one-to-one backup.

Merge Point (MP) the LSR where one or more backup paths rejoin the path of the protectedLSP 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 protectedLSP at each PLR. Detour LSPs are signalled at each node along the path of the protected LSP, withexception of the egress node. These nodes are known as potential PLRs. The following is anexample topology of the one-to-one backup.

Fig. 8 FRR One-to-One Backup


23

1 MPLS Overview

The principle of one-to-one backup is illustrated in Fig. 8, where as an example four detour LSPs canbe created for the protected LSP. When a failure occurs along the protected LSP, the PLR detecting afailure switches traffic into the detour LSP. For example, if a fault condition occurs in node R3 orlink R2R3, node R2 will switch traffic 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 R1B-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 canturn to a large number of LSPs in the network. If there are multiple protected LSPs, merging canhelp to reduce the amount of LSPs.

One-to-one backup configuration in the network:

Sufficient 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 specific bandwidth and link colors to influence the paths of pos-sible detour LSPs

Facility Backup

The facility backup works by creating single bypass tunnel for each protected link or node. Thebypass tunnel can also protect a set of LSPs if the following are fulfilled:

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 traffic onto the bypass tunnel.This implies that facility backup provides a scalability improvement compared to one-to-onebackup, by utilizing the same bypass tunnel to protect multiple LSPs when a failure occurs in a nodeor link, which the bypass tunnel is protecting.

Fig. 9 FRR Facility Backup


24

1 MPLS Overview

The principle of facility backup is illustrated in Fig. 9, where as an example created bypass tunnelprotects node R3 and three LSPs that pass through this node against failure in node R3 or link R2R3. When a failure occurs in node R3 or link R2R3, node R2 will switch all traffic sent fromR1, R8 and R2 itself into the bypass tunnel. In this example R4 serves as the MP.

In facility backup bypass tunnels are specifically created by configuring the protected link or node,and the desired MP for the bypass tunnel. In Tellabs 8600 system the PLR node supports LSPping and traceroute for bypass tunnel.

Facility backup configuration in the network:

Desired potential PLR nodes must have bypass paths

Protected path is strict configured

Each LSR acting as PLR must have a bypass tunnel pre-configured. All RSVP-TE trunk optionsare available

FRR attributes can be taken into account.

Head-End

The creation and establishment of the protected LSP session follows the same principle asconventional LSP in a RSV-TE. Please refer to Tellabs 8600 Managed Edge System MPLSApplications Configuration Guide for more details.

Depending on the network topology, the head-end makes decision on wether a protection path mustbe established and which protection variant (link or node) is required. For example, if at head-endthere are two provisioned paths, primary and secondary LSPs it is possible to create a detour LSP toprotect the primary LSP (primary detour LSP) and a second detour LSP to protect the secondaryLSP (secondary detour LSP). With such protection scenario there is a precedence order in theTellabs 8600 system to handle the protection when there is more than one protection path. Thefollowing table illustrates the order of the precedence, i.e. how data traffic is switched:

State Condition Description of Data Flow

No failure If all paths are available, traffic will be carried on the primary protectedLSP

Failure in protected LSP If protected LSP is not available (faulted) traffic will be switched tothe primary detour LSP, i.e. primary detour LSPs are preferred oversecondary LSPs

Primary detour LSP failure If primary detour LSP is not available traffic is switched to secondaryprotected LSP

Failure in secondary protectedLSP

If secondary protected LSP is not available and both primary protectedLSP and primary detour too, traffic will be switched to secondarydetour LSP

The above implies that only one active path can exist at the time and that detour is ahot-standby path, i.e. no traffic passes through before switchover.

In Tellabs 8600 system it is possible to prevent detour creation at Head-End when there is more thanone protection path. In such case detour can be created in the downstream. In the downstream ifthere is a path available a detour will be created automatically.


25

1 MPLS Overview

When a failure occurs the head-end employes global revertive mode to re-optimize the LSPs thatused the failed path.

Path Identification

When FRR is enabled backup paths are signalled and the following conditions imply:

Backup paths must be uniquely identified

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 identified with its protected session to allow correct merging andstate treatment. This implies that a detour LSP must inherit its LSP ID from the associated protectedLSP. To be able to uniquely identify a detour LSP, two approaches are defined:

Sender Template-Specific

Path-Specific

Sender Template-Specific - in this approach every PLR uses a local router address as the ingressaddress of detour LSP. Additionally detour LSP object may be added to the path message. DetourLSPs may be merged using this approach. A merge will occur if the outgoing interface, ExplicitRoute Object (ERO) and the next-hop LSR are the same.

Path-Specific - in this approach detour LSP uses the protected LSP ingress address and a detourLSP object is added to the path message. Detour LSPs can be merged using path-specific 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-Specific is the default mode.

If strict path is used, traffic cuts may occur when detours LSPs are merged to detour LSP. It isrecommended 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 networktopology) where merge must be done, but cannot be constructed. In such cases MP willtear down some of the detour LSPs. The head-end will see that the path is only partiallyprotected (fault indication will be raised).

Facility Backup

To allow correct merge bypass tunnels must also be uniquely identified. They are identified using thePath-Specific method and follows the same procedures as to those described in One-to-One Backup.


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 ornode)

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 configured, 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 mightaffect detour path selection. In Tellabs 8600 system by default no bandwidth is allocated for detourLSPs. However depending on the operators needs and the importance of traffic, the followingoptions are available:

Provision no bandwidth and rely on quick global recovery to reroute traffic quickly;

Overbook, i.e. configure 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 onthe path and these intermediate nodes also process these messages. There will be a significant delayuntil the head-end gets notified about the failure condition, or the error message might get lost due tothe nature of the RSVP protocol itself. This means that link down triggering mechanism might notbe 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 andMeasurement Configuration Guide BFD sections for more information and configuration details.

With SONET/SDH POS interfaces link failure detection time is almost 1 second, which exceedsignificantly the FRR requirement of

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 configured, FRR attributes are signaled with the protected LSP Path message. When adownstream node creates a detour LSP, these attributes will be copied from the protected sessionsFRR attributes. If the FRR attributes are not configured by the head-end, the downstream LSRinherits the attributes of the protected LSP while signaling its detour LSP.

Network Topologies

In the Tellabs 8600 system FRR supports any network topology with sufficient degree ofconnectivity.

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


28

1 MPLS Overview

In Fig. 10 the protected LSP is established and connects via nodes R1, R2, R3, R4 to R5 and trafficflows in the same direction. In this example when protected LSP is established, every node in thering creates detour LSP in the reverse direction of the protected path (LSP). These detour LSPs aremerged in the downstream detour path. As an example, Fig. 10 shows detour LSP D2 being mergedin node R1 when protecting against a failure in link R2R3. The same merging mechanism isvalid 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 facilitybackup, bypass tunnel is established depending on the protection type used link or node.

If a failure occurs e.g. in link R2R3, bypass tunnel R2-R1-R6-R5-R4-R3 (node R3 is the MP)is used as the protecting path of link R2R3.

If a failure occurs e.g. in node R3, bypass tunnel (node R4 is the MP) R2-R1-R6-R5-R4 is usedas protecting path of node R3.

Bypass tunnel:

One bypass tunnel provides protection for each link or node in the ring (shared by all LSPs onthat link).

Switched traffic and RSVP signaling for the failing protected LSP are carried by the bypass tunnelin the reverse direction and rejoins at the MP into the original protected LSP. The protected LSPis intact around the ring except the fast rerouting in the reverse direction enabling the user toavoid the failed link / node.

Fault Management

The Tellabs 8600 system supports FRR Fault Management (FM) and the faults reported aresummarized in the following table.


29

1 MPLS Overview

FRR Faults

Fault Description

mplsPrimaryLspFrrActive Some part of primary LSP uses detour or bypasstunnel

mplsPrimaryLspNotFullyProtected At least one hop is not protected or link protectionis 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 protectionis used when node protection was desired

1.8 MPLS References

Feature Description

[RFC2702] RFC2702 (199909), Requirements for traffic engineering overMPLS

[RFC3209] RFC3209 (200112), RSVP-TE: Extensions to RSVP for LSP tunnels

[RFC3270] RFC3270 (200205), Multiprotocol label switching (MPLS) supportof differentiated services

[RFC3564] RFC3564 (200307), Requirements for support of differentiatedservices-aware MPLS traffic engineering

[RFC4090] RFC4090 (200605), RSVP-TE Fast Reroute

[RFC4125] RFC4125 (200506), Maximum allocation bandwidth constraintsmodel for DiffServ-aware MPLS traffic engineering

[RFC4127] RFC4127 (200506), Russian dolls bandwidth constraints model forDiffServ-aware MPLS traffic 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 switchingfor MPLS networks


30

2 MPLS Configuration Examples


The configuration examples in this chapter focus on the signalling of LSPs on a preconfiguredIP/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 foundin Tellabs 8600 Managed Edge System Routing Protocols Configuration Guide.

2.1 LDP Configuration

If neither explicit routing nor bandwidth reservations are needed, LDP can automatically create therequired E-LSPs between adjacent LSRs simply by enabling the protocol on each label-switchedinterface. Doing this on all of the label-switched interfaces in each router node, will result in anautomatically created multipoint-to-point LSP topology. It can in some cases be used for carrying allthe label-switched traffic 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 traffic engineering orLSP protection needs.

Command Description

router(config)# interface fe 3/0/0 Configures 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 isshutdown).

router(cfg-if[fe 3/0/0])# ip address10.0.10.1/24

Assigns an IP address to the interface.

router(cfg-if[fe 3/0/0])# mpls labelprotocol ldp

Enables automatic LDP label distribution withadjacent peers.

router(cfg-if[fe 3/0/0])# exit Exits from the Interface Configuration commandmode.

2.2 Explicitly Routed RSVP-TE LSPs

In the case of running MPLS-based traffic engineering and/or LSP protection applications in thenetwork, explicitly routed, point-to-point LSP tunnels are used for carrying at least some portion ofthe traffic within the IP/MPLS network domain. In the Tellabs 8600 system, all explicitly routedLSPs (with or without bandwidth reservations) are signalled using RSVP-TE.

The Explicit Route Object (ERO), which defines the LSP route to be signalled by RSVP-TE, caninclude both loose and strict hops:


31


For the loose hops, the route taken from the previous router to the current router does not need tobe 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 directlyconnected path, and the path message exchanged between the two routers should not pass anyintermediate 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 bedemonstrated in the DS-TE network example, or manually specified by the network administrator,as in the following E-LSP and L-LSP configuration examples, which are based on the followingnetwork diagram (with label switching and LDP already enabled on all interfaces).

Fig. 12 A Simple RSVP-TE LSP Configuration Topology Example

2.2.1 RSVP-TE Configuration

Before starting to set up any explicitly routed LSPs, also the RSVP-TE protocol has to be enabledon all interfaces of the example network, as shown in the following example.

Command Description

R1(config)# interface fe 3/0/0R1(cfg-if[fe 3/0/0])# mpls labelprotocol rsvpR1(cfg-if[fe 3/0/0])# exit

Enables the RSVP-TE protocol on the Fast Ethernetport at slot #3 / module #0 / interface #0 of node R1.


32


2.2.2 E-LSP Configuration

Explicitly routed E-LSPs can carry up to eight BAs (i.e. packets of up to 8 different PHBs), andsince they are not explicitly associated with any particular PSC during the setup signalling, E-LSPscan be signalled either with or without the optional RSVP-TE DiffServ object.

Tellabs 8605 access switch does not support prefix+QoS longest prefix match lookups in IProuting. Although the command map-route ignores QoS for IP traffic forwarding, these QoSqualifiers affect PWE3 traffic associations. Currently, IP lookups QoS qualifiers are ignoredin the Tellabs 8605 access switch.

Command Description

R1(config)# rsvp-path R1-R5_via_R3R1(cfg-rsvp-path[R1-R5_via_R3])#10.30.0.2 strictR1(cfg-rsvp-path[R1-R5_via_R3])#10.60.0.2 strictR1(cfg-rsvp-path[R1-R5_via_R3])# exit

Specifies an explicit route, with two strict hops, forthe new tunnel LSP.

R1(config)# rsvp-trunk R1-R5_data Sets up a new trunk for data traffic.

R1(cfg-rsvp-trunk[R1R5_data])# primarypath R1-R5_via_R3

The new trunk will be routed according to the LSPpath specified earlier.

R1(cfg-rsvp-trunk[R1R5_data])# primarysetup-priority 7

Sets the setup priority of the trunk to 7 (= lowestpossible preemption priority), so this trunk will notpreempt any other trunks. This is also the defaultsetup priority value.

R1(cfg-rsvp-trunk[R1R5_data])# primaryhold-priority 0

Sets the hold priority of the trunk to 0 (= highestpossible preemption priority), so this trunk willnever get preempted by any other trunk. This isalso the default hold priority value.

R1(cfg-rsvp-trunk[R1R5_data])# primarybandwidth 30M

The bandwidth to be reserved for the trunk is 30Mbps.

R1(cfg-rsvp-trunk[R1R5_data])# noprimary diffserv-object

The DiffServ object of RSVP-TE is not used (it ismandatory only when signalling L-LSPs).

R1(cfg-rsvp-trunk[R1R5_data])# primaryclass-type data

The DS-TE class type for the trunk is the data CT.This may be omitted if the network does not runDS-TE.

R1(cfg-rsvp-trunk[R1R5_data])# primaryelsp-preconfigured

The LSP tunnel will be of the preconfigured E-LSPtype, with default PHB EXP mapping tablesused at each router.


33


R1(cfg-rsvp-trunk[R1R5_data])#map-route 10.10.0.5/32 qos af1R1(cfg-rsvp-trunk[R1R5_data])#map-route 10.10.0.5/32 qos af2R1(cfg-rsvp-trunk[R1R5_data])#map-route 10.10.0.5/32 qos af3

Maps an IP route to the current trunk, i.e. instead oftraversing the multipoint-to-point LDP LSPs usedfor the default forwarding treatment, those AF1,AF2 and AF3 PSC packets, whose next hop lookupresolves to the gateway address 10.10.0.5, will bedirected to the new point-to-point data trunk.

R1(cfg-rsvp-trunk[R1R5_data])# to10.10.0.5

Specifies the IP loopback address of the egress nodeof the new tunnel LSP, after which the protocolsession will be set up, and the LSP initializationcan begin.

R1(cfg-rsvp-trunk[R1R5_data])# exit Exits from the RSVP-TE Trunk Configurationcommand mode.


34


2.2.3 L-LSP Configuration

Explicitly routed L-LSP tunnels are signalled in a very similar fashion as in the previous exampleof signaling explicitly routed E-LSPs. There is, however, a fundamental difference. As L-LSPsare always explicitly associated with a single PSC, the optional RSVP-TE DiffServ object has tobe used in the signaling. Thus, the traffic belonging to just that one single PSC can be directed tothe trunk, as shown in the following example.

Command Description

R1(config)# rsvp-path R1-R5_via_R4R1(cfg-rsvp-path[R1-R5_via_R4])#10.40.0.2 strictR1(cfg-rsvp-path[R1-R5_via_R4])#10.70.0.2 strictR1(cfg-rsvp-path[R1-R5_via_R4])# exit

Specifies an explicit route, with two strict hops,for the new tunnel LSP (this time via R4, insteadof R3).

R1(config)# rsvp-trunk R1-R5_real-time Sets up a new trunk for real-time traffic.

R1(cfg-rsvp-trunk[R1R5_real-time])#primary path R1-R5_via_R4

The new trunk will be routed according to the LSPpath specified earlier.

R1(cfg-rsvp-trunk[R1R5_real-time])#primary setup-priority 0

Sets the setup priority of the trunk to 0 (= highestpossible preemption priority), so this real-timetrunk may preempt other lower priority (e.g. data)trunks in order to get into the low latency (i.e.shortest) path.

R1(cfg-rsvp-trunk[R1R5_real-time])#primary hold-priority 0

Sets the hold priority of the trunk to 0 (= highestpossible preemption priority), so this trunk willnever get preempted by any other trunk.

R1(cfg-rsvp-trunk[R1R5_real-time])#primary bandwidth 10M


R1(cfg-rsvp-trunk[R1R5_real-time])#primary class-type real-time

The DS-TE class type for the trunk is the real-timeCT. Again, this is not needed if the network doesnot run DS-TE.

R1(cfg-rsvp-trunk[R1R5_real-time])#primary llsp ef

The LSP tunnel will be of the L-LSP type, and willbe explicitly associated with the EF PSC duringthe set up signalling by including the RSVP-TEDiffServ object.

R1(cfg-rsvp-trunk[R1R5_real-time])#map-route 10.10.0.5/32 qos ef

Maps an IP route to the current trunk, i.e. insteadof traversing the multipoint-to-point LDP LSPsused for the default forwarding treatment, thoseEF packets, whose next hop lookup resolves to thegateway address 10.10.0.5, will be directed to thenew point-to-point real-time trunk.


35


R1(cfg-rsvp-trunk[R1R5_real-time])# to10.10.0.5

Specifies the IP loopback address of the egress nodeof the new tunnel LSP, after which the protocolsession will be set up, and the LSP initializationcan begin.

R1(cfg-rsvp-trunk[R1R5_real-time])#exit

Exits from the RSVP-TE Trunk Configurationcommand mode.


36


2.2.4 RSVP-TE Path Protection Configuration

In order to utilize RSVP-TE based path protection in the Tellabs 8600 system, two diversely routedLSPs can be signalled to set up both the primary path and the secondary path for the protectedtraffic trunk. In this example, two explicitly routed E-LSPs will be signalled without makingany bandwidth reservations, using the same explicit LSP routes which were already specified inthe two previous examples.

Command Description

R1(config)# rsvp-trunk R1-R5_protected Sets up a new trunk for protected traffic.

R1(cfg-rsvp-trunk[R1R5_protected])#primary path R1-R5_via_R3

The primary LSP of the new trunk will be routedon the path traversing R3.

R1(cfg-rsvp-trunk[R1R5_protected])#secondary path R1-R5_via_R4

The secondary LSP of the new trunk will be routedon the path traversing R4.

R1(cfg-rsvp-trunk[R1R5_protected])#map-route 10.10.0.5/32 qos af4

Maps an IP route to the current trunk, i.e. insteadof traversing the multipoint-to-point LDP LSPsused for the default forwarding treatment, thoseAF4 PSC packets, whose next hop lookup resolvesto the gateway address 10.10.0.5, will be directedto the new protected traffic trunk.

R1(cfg-rsvp-trunk[R1R5_protected])# to10.10.0.5

Specifies the IP loopback address of the egress nodeof the new tunnel LSPs, after which the protocolsession will be set up, and the LSP initializationcan begin.

R1(cfg-rsvp-trunk[R1R5_protected])#exit

Exits from the RSVP-TE Trunk Configurationcommand mode.


37


2.2.5 DiffServ Tunneling Model Configuration

The DiffServ Tunneling Model selections are done on the network element level in the Tellabs8600 system as shown in the following example.

Command Description

router(config)# mpls tunnel-modeltunnel-label short-pipe

Sets the outer label tunneling model to Short Pipe.

router(config)# no mpls tunnel-modeltunnel-label short-pipe

Using the no option cancels the command andreturns to node defaults (i.e. Pipe Model).

Please note that if the Tellabs 8600 network element acts as the penultimate LSR andpenultimate hop popping is applied, the tunneling model behavior is uniform, even if thenode configuration is short pipe.

Exactly similar settings can be made also for the inner VPN labels, as follows.

Command Description

router(config)# mpls vpn-tunnel-modeltunnel-label uniform

Sets the VPN label tunneling model to Uniform.

router(config)# mpls vpn-tunnel-modeltunnel-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 theTellabs 8600 system. In addition to RDM, also MAM is supported in the Tellabs 8600 system. Ifrequired, the BC model on each interface can be changed as follows.

Command Description

router(config)# interface fe 3/0/1router(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-modemam

Using the no option cancels the command andreturns to node defaults (i.e. RDM).

router(cfg-if[fe 3/0/1])# bc-moderussian-doll

Alternatively, the BC model can also be explicitlyset to RDM.

In this particular RDM-based network example, the default BC model settings can be used, so noBC model configurations are needed in the network nodes. The example topology consists of sixTellabs 8600 NEs, which have been interconnected as shown in the following network diagram.


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 resourcereservations are made for the BE/Default Forwarding traffic, which utilizes the basic LDP-basedmultipoint-to-point E-LSP transport. Also the DS-TE trunks will be of the E-LSP type, and thus theoptional 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 usein the network:

CT0 for AF1 based Business Data (BD) traffic

CT1 for AF4 based Priority Data (PD) traffic

CT2 for EF based Real Time (RT) traffic

The reservable link bandwidth will be allocated to the three chosen CTs according to the RDM BCsettings illustrated below, leaving a total of 40 Mbps of unreservable bandwidth for the BE/DefaultForwarding traffic.


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 possiblepreemption priority level and 7 the lowest possible preemption priority level):

RT trunks will be configured with setup priority 0 and hold priority 0.

PD trunks will be configured with setup priority 1 and hold priority 0.

BD trunks will be configured with setup priority 1 and hold priority 1.

In order to be able to configure a new traffic trunk in DS-TE, the setup priority and the Class Typemust be such that, together, they form one of the (up to) eight TE Classes. Also the hold priority andthe Class Type of the trunk must, together, match one of the configured TE Classes.

Thus, the chosen preemption strategy then yields, e.g. the following TE Class mapping:

TE Class 0 = =

TE Class 1 = =

TE Class 2 = =

TE Class 3 = =

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 exampleof node 1.


40


Command Description

NODE1(config)# mpls class-type ct0 BDNODE1(config)# mpls class-type ct1 PDNODE1(config)# mpls class-type ct2 RT

Defines the DS-TE class types (CTs).

NODE1(config)# mpls te-class te0 BD 1NODE1(config)# mpls te-class te1 PD 1NODE1(config)# mpls te-class te2 PD 0NODE1(config)# mpls te-class te3 RT 0

Defines the required TE Classes with appropriatepreemption priorities.

NODE1(config)# interface lo 0NODE1(cfg-if[lo 0])# no shutdownNODE1(cfg-if[lo 0])# ip address10.123.100.41/32

Loopback interface is required in order to get theOSPF and RSVP-TE protocol sessions with thepeer nodes working.

NODE1(cfg-if[lo 0])# interface fe 3/0/0 Configures 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 60Mbps.

NODE1(cfg-if[fe 3/0/0])# bandwidth-constraint BD 60M

Sets BC0 of the Russian Dolls BC model; all LSPsfrom CT0, CT1, and CT2 (i.e. BD, PD, and RT)may use no more than 60 Mbps.

NODE1(cfg-if[fe 3/0/0])# bandwidth-constraint PD 40M

Sets BC1 of the Russian Dolls BC model; all LSPsfrom CT1 and CT2 (i.e. PD and RT) may use nomore than 40 Mbps.

NODE1(cfg-if[fe 3/0/0])# bandwidth-constraint RT 20M

Sets BC2 of the Russian Dolls BC model; all LSPsfrom 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 isshutdown).

NODE1(cfg-if[fe 3/0/0])# ip address10.0.10.1/24

Sets the interface IP host address according toaddressing plan indicated in the network diagram.

NODE1(cfg-if[fe 3/0/0])# mpls labelprotocol ldp

Enables automatic LDP label distribution forcarrying the BE/Default Forwarding traffic.

NODE1(cfg-if[fe 3/0/0])# mpls labelprotocol rsvp

Enables RSVP-TE signalling on the interface.


41


NODE1(cfg-if[fe 3/0/0])# interface fe3/0/1NODE1(cfg-if[fe 3/0/1])# label-switchingNODE1(cfg-if[fe 3/0/1])# reservable-bandwidth 60MNODE1(cfg-if[fe 3/0/1])# bandwidth-constraint BD 60MNODE1(cfg-if[fe 3/0/1])# bandwidth-constraint PD 40MNODE1(cfg-if[fe 3/0/1])# bandwidth-constraint RT 20MNODE1(cfg-if[fe 3/0/1])# no shutdownNODE1(cfg-if[fe 3/0/1])# ip address10.0.20.1/24NODE1(cfg-if[fe 3/0/1])# mpls labelprotocol ldpNODE1(cfg-if[fe 3/0/1])# mpls labelprotocol rsvp

Makes equivalent settings to the Fast Ethernet portat slot #3 / module #0 / interface #1.

NODE1(cfg-if[fe 3/0/1])# router ospf 1NODE1(cfg-ospf[1])# ospf router-id10.123.100.41NODE1(cfg-ospf[1])# network10.0.10.0/24 area 0.0.0.0NODE1(cfg-ospf[1])# network10.123.100.41/32 area 0.0.0.0NODE1(cfg-ospf[1])# network10.0.20.0/24 area 0.0.0.0NODE1(cfg-ospf[1])# cspf tie-breakleast-fill

Configures the OSPF settings. In case there aremore than one route alternatives, requiring equalnumber of router hops for explicit LSP routing,preference for the least-filled path will be used asthe CSPF tie break method. Please refer to Tellabs8600 Managed Edge System Routing ProtocolsConfiguration Guide for more details on the otherOSPF settings.

After all of the nodes have been set up in a similar fashion to the above example of node 1, thesignalling of the required DS-TE traffic trunks can begin.

Please note in the following examples that only the point-to-point TE tunnel LSPs for thetraffic flowing towards node 6 are being signalled (i.e. node 1 > node 6 and node 2 > node6), leaving all of the traffic in the opposite direction to the multipoint-to-point LDP LSPs.However, since real service provider networks usually carry mostly bidirectional traffic, alsothe traffic 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 signalledtraffic 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 prioritytrunks later on. This is also the case with the initially signalled RT and BD trunks in the followingexample, which will get to be routed on the shortest paths N1 > N4 > N6 and N2 > N5 > N6.


42


Command Description

NODE1(config)# rsvp-trunktrunk1_RT10_N1-N6

Configures 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 (= highestpossible preemption priority), so this trunk maypreempt other trunks having a hold priority of 1 (=the lowest priority level in use in this example).

NODE1(cfg-rsvp-trunk[trunk1_RT10_N1-N6])# primary hold-priority 0

Sets the hold priority of the trunk to 0 (= highestpossible preemption priority), so this trunk willnever get preempted by any other trunk.

NODE1(cfg-rsvp-trunk[trunk1_RT10_N1-N6])# primary bandwidth 10M


NODE1(cfg-rsvp-trunk[trunk1_RT10_N1-N6])# no primary diffserv-object

The optional RSVP-TE DiffServ object will notbe used.

NODE1(cfg-rsvp-trunk[trunk1_RT10_N1-N6])# primary class-type RT

DS-TE class type for this session will be RT (i.e.CT2).

NODE1(cfg-rsvp-trunk[trunk1_RT10_N1-N6])# primary elsp-preconfigured

The LSP tunnel will be of the preconfigured E-LSPtype, with default PHB EXP mapping tablesused at each node.

NODE1(cfg-rsvp-trunk[trunk1_RT10_N1-N6])# update-type make-before-break

If the trunk parameters need to be changed later, anew LSP will be created for each attribute update.Once the new LSP becomes operational, theoriginal LSP will be torn down.

NODE1(cfg-rsvp-trunk[trunk1_RT10_N1-N6])# map-route 10.123.100.46/32 qos ef

Maps an IP route to the current trunk, i.e. insteadof traversing the multipoint-to-point LDP LSPsused for the default forwarding treatment, thoseEF packets, whose next hop lookup resolves to thegateway address 10.123.100.46, will be directed tothe new point-to-point RT trunk.

NODE1(cfg-rsvp-trunk[trunk1_RT10_N1-N6])# to 10.123.100.46

Specifies the IP loopback address of the egressnode (i.e. node 6) of the new tunnel LSP, afterwhich the protocol session will be set up, and theLSP initialization can begin.


43


Command Description

NODE1(config)# rsvp-trunktrunk2_BD10_N1-N6NODE1(cfg-rsvp-trunk[trunk2_BD10_N1-N6])# primary setup-priority 1NODE1(cfg-rsvp-trunk[trunk2_BD10_N1-N6])# primary hold-priority 1NODE1(cfg-rsvp-trunk[trunk2_BD10_N1-N6])# primary bandwidth 10MNODE1(cfg-rsvp-trunk[trunk2_BD10_N1-N6])# no primary diffserv-objectNODE1(cfg-rsvp-trunk[trunk2_BD10_N1-N6])# primary class-type BDNODE1(cfg-rsvp-trunk[trunk2_BD10_N1-N6])# primary elsp-preconfiguredNODE1(cfg-rsvp-trunk[trunk2_BD10_N1-N6])# update-type make-before-breakNODE1(cfg-rsvp-trunk[trunk2_BD10_N1-N6])# map-route 10.123.100.46/32 qosaf1NODE1(cfg-rsvp-trunk[trunk2_BD10_N1-N6])# to 10.123.100.46

Configures a 10 Mbps BD trunk from node 1 tonode 6, and directs AF1 traffic to it. This timeboth the setup and hold priorities are set to 1 (= thelowest priority level in use in this example), so thistrunk will not preempt other trunks, but may getpreempted later by higher priority trunks.

Command Description

NODE2(config)# rsvp-trunktrunk3_RT15_N2-N6NODE2(cfg-rsvp-trunk[trunk3_RT15_N2-N6])# primary setup-priority 0NODE2(cfg-rsvp-trunk[trunk3_RT15_N2-N6])# primary hold-priority 0NODE2(cfg-rsvp-trunk[trunk3_RT15_N2-N6])# primary bandwidth 15MNODE2(cfg-rsvp-trunk[trunk3_RT15_N2-N6])# no primary diffserv-objectNODE2(cfg-rsvp-trunk[trunk3_RT15_N2-N6])# primary class-type RTNODE2(cfg-rsvp-trunk[trunk3_RT15_N2-N6])# primary elsp-preconfiguredNODE2(cfg-rsvp-trunk[trunk3_RT15_N2-N6])# update-type make-before-breakNODE2(cfg-rsvp-trunk[trunk3_RT15_N2-N6])# map-route 10.123.100.46/32 qos efNODE2(cfg-rsvp-trunk[trunk3_RT15_N2-N6])# to 10.123.100.46

Configures a 15 Mbps RT trunk from node 2 tonode 6, and directs EF traffic to it.


44


Command Description

NODE2(config)# rsvp-trunktrunk4_BD15_N2-N6NODE2(cfg-rsvp-trunk[trunk4_BD15_N2-N6])# primary setup-priority 1NODE2(cfg-rsvp-trunk[trunk4_BD15_N2-N6])# primary hold-priority 1NODE2(cfg-rsvp-trunk[trunk4_BD15_N2-N6])# primary bandwidth 15MNODE2(cfg-rsvp-trunk[trunk4_BD15_N2-N6])# no primary diffserv-objectNODE2(cfg-rsvp-trunk[trunk4_BD15_N2-N6])# primary class-type BDNODE2(cfg-rsvp-trunk[trunk4_BD15_N2-N6])# primary elsp-preconfiguredNODE2(cfg-rsvp-trunk[trunk4_BD15_N2-N6])# update-type make-before-breakNODE2(cfg-rsvp-trunk[trunk4_BD15_N2-N6])# map-route 10.123.100.46/32 qosaf1NODE2(cfg-rsvp-trunk[trunk4_BD15_N2-N6])# to 10.123.100.46

Configures a 15 Mbps BD trunk from node 2 tonode 6, and directs AF1 traffic 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. Atthis 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

NODE2(config)# rsvp-trunktrunk5_PD30_N2-N6

Establishes a new PD trunk from node 2 to node 6.

NODE2(cfg-rsvp-trunk[trunk5_PD30_N2-N6])# primary setup-priority 1NODE2(cfg-rsvp-trunk[trunk5_PD30_N2-N6])# primary hold-priority 0

This time the setup priority is 1 (i.e. the lowestpriority level in use in this example), and the holdpriority 0 (i.e. the highest possible priority level),so the new PD trunk will neither preempt othertrunks, nor will it be preempted by other trunks.

NODE2(cfg-rsvp-trunk[trunk5_PD30_N2-N6])# primary bandwidth 30MNODE2(cfg-rsvp-trunk[trunk5_PD30_N2-N6])# no primary diffserv-objectNODE2(cfg-rsvp-trunk[trunk5_PD30_N2-N6])# primary class-type PDNODE2(cfg-rsvp-trunk[trunk5_PD30_N2-N6])# primary elsp-preconfiguredNODE2(cfg-rsvp-trunk[trunk5_PD30_N2-N6])# update-type make-before-break

The desired trunk bandwidth is 30 Mbps. There isalready a 15 Mbps RT trunk on the shortest pathN2>N5>N6, and since BC1 (i.e. the maximumbandwidth consumed by all RT and PD trunks)has been configured to 40 Mbps, an alternativeroute has to be calculated. This will result ina tie between routes N2>N3>N4>N6 andN2>N1>N4>N6, out of which the least fillTie Break mode will select the N2>N3>N4>N6route.

NODE2(cfg-rsvp-trunk[trunk5_PD30_N2-N6])# map-route 10.123.100.46/32 qosaf4NODE2(cfg-rsvp-trunk[trunk5_PD30_N2-N6])# to 10.123.100.46

Finally, the LSP initialization can begin, and AF4traffic is directed to the new N2>N3>N4>N6PD trunk.


45


Command Description

NODE1(config)# rsvp-trunktrunk6_PD20_N1

Documents

MPLS Applications Configuration Guide