Nortel Secure Router 2330/4134 Configuration MPLS. Release: 10.2 Document Revision: NN

Transcription

1 Release: 10.2 Document Revision: NN

2 . Release: 10.2 Publication: NN Document release date: 7 September 2009 While the information in this document is believed to be accurate and reliable, except as otherwise expressly agreed to in writing NORTEL PROVIDES THIS DOCUMENT "AS IS" WITHOUT WARRANTY OR CONDITION OF ANY KIND, EITHER EXPRESS OR IMPLIED. The information and/or products described in this document are subject to change without notice. Nortel, Nortel Networks, the Nortel logo, and the Globemark are trademarks of Nortel Networks. THE SOFTWARE DESCRIBED IN THIS DOCUMENT IS FURNISHED UNDER A LICENSE AGREEMENT AND MAY BE USED ONLY IN ACCORDANCE WITH THE TERMS OF THAT LICENSE. All other trademarks are the property of their respective owners.

3 . Contents 3 New in this release 11 Features 11 SR2330 hardware 11 HDLC over MPLS pseudowire 11 MPLS over VLAN 11 Other changes 11 Specifying controlled load traffic or guaranteed traffic for an LSP no longer supported 12 Introduction 13 Navigation 13 MPLS fundamentals 15 MPLS elements 15 Label switched path 15 LSRs and LERs 16 Supported interfaces 16 MPLS label 16 Label description 17 Label allocation 17 Operations on labels 17 NHLFE 18 ILM 18 FTN 18 Penultimate Hop Popping 18 Implicit null 18 Explicit null 19 PHP disabled 19 LSP routes 20 Routing traffic with policy-based redirection 20 Types of LSPs 20 Static LSP 21 LDP LSP 21 RSVP-TE-signaled LSPs 21 Standards compliance 22

4 4 LDP fundamentals 25 LDP overview 25 LDP identifier and label space 25 LDP discovery 25 LDP sessions 26 LDP message types 27 LDP operation modes 28 Label advertisement modes 28 Label retention mode 29 Label control mode 30 ACL configuration with LDP 31 LDP loop detection 31 Hop count limit 31 Path vector limit 31 RSVP-TE fundamentals 33 RSVP-TE overview 33 Control messages 33 RVSP-TE tunnel setup 34 OSPF-TE and CSPF 35 RSVP-TE resource reservation styles 35 Fixed filter 36 Shared explicit 36 Priority of signaled LSP 37 Setup priority 37 Hold priority 37 Explicitly routed LSPs 37 Route Recording 38 Refresh reduction 38 Reliable messaging 38 Fast reroute and node protection 39 Node protection 39 Secondary LSP (global repair) 40 Secondary LSP signaling 40 Secondary LSP with fast reroute 41 Administrative groups 41 MPLS QoS 41 Ingress LER- EXP marking 42 DSCP Marking on Egress LER 43 MPLS Pseudowire fundamentals 45 Layer 2 virtual circuits 45 Virtual circuit labelling 46 Binding an attachment circuit to the pseudowire 46

5 5 LDP requirement for dynamic virtual circuits 46 Static virtual circuits 47 Multiple virtual circuits 47 PPP over MPLS 47 HDLC over MPLS 48 Ethernet over MPLS 48 VLAN Rewrite 48 Static LSP configuration 49 Static LSP configuration procedures 49 Static LSP configuration task navigation 50 Configuring a static FTN entry on the ingress router 50 Configuring static ILM entries on transit and egress routers 51 Displaying the static FTN entry 52 Displaying the static ILM entry 52 Displaying static FTN statistics 53 Displaying static ILM statistics 53 LDP LSP configuration 55 LDP configuration procedures 55 LDP configuration task navigation 57 Configuring loopback interface and router ID 57 Enabling LDP at the router level 58 Configuring targeted LDP peer adjacency 58 Specifying a targeted LDP peer for extended discovery 58 Configuring the global targeted LDP peer hello interval 59 Configuring the interface targeted LDP peer hello interval 59 Configuring the global targeted LDP peer hold time 60 Configuring the interface targeted LDP peer hold time 61 Configuring LDP properties 61 Configuring explicit-null labels 61 Configuring the transport address for a label space 62 Configuring global loop detection 63 Configuring the global loop detection count 63 Configuring global request retries 64 Configuring the global request retry timeout 64 Propagating the global release of labels to downstream routers 65 Configuring the global label control mode 66 Applying ACL rules to LDP 66 Configuring the global label advertisement mode 67 Configuring the interface label advertisement mode 68 Configuring the global label retention mode 69 Configuring the interface label retention mode 69 Configuring the global LDP hello interval 70 Configuring the interface LDP hello interval 71

6 6 Configuring the global LDP hold time 72 Configuring the interface LDP hold time 72 Configuring the global keepalive interval 73 Configuring the interface keepalive interval 74 Configuring the global keepalive timeout 75 Configuring the interface keepalive timeout 75 Enabling LDP on an interface 76 Enabling auto-discovery of LDP peers 77 Configuring global multicast hellos 77 Configuring interface multicast hellos 77 Displaying LDP configuration and statistics 78 Displaying LDP adjacency 78 Displaying the IP access list of LDP advertise-labels 78 Displaying FECs known to the current LSR 78 Displaying detailed LDP information for interfaces 79 Displaying LDP LSP configuration 79 Displaying LDP LSP hosts corresponding to an FEC 79 Displaying LDP LSP host 80 Displaying LDP LSP prefix 80 Displaying LDP session 81 Displaying LDP packet statistics 81 Displaying LDP advertise-labels statistics 81 Clearing LDP adjacencies 82 Clearing LDP statistics 82 RSVP-TE LSP configuration 83 RSVP-TE configuration procedures 83 RSVP-TE configuration task navigation 85 Configuring loopback interface and router ID 85 Enabling RSVP-TE at the router level 86 Enabling RSVP-TE at the interface level 86 Creating an RSVP-TE LSP 87 Creating an RSVP-TE LSP 87 Configuring the ingress address for the LSP 87 Configuring the egress router for the LSP 88 Configuring an explicit path LSP 89 Disabling and enabling CSPF globally 89 Disabling and enabling CSPF on RSVP-TE LSPs 89 Create the explicit route and define the hops 90 Associate the RSVP-TE explicit route with an LSP 91 Specifying the Route Record List as an explicit route 91 Configuring constrained path LSP properties 92 Reserving bandwidth for RSVP-TE LSPs 92 Configuring the filter style for RSVP-TE LSP 93

7 7 Configuring retry limit for RSVP-TE LSP 93 Configuring retry timer for RSVP-TE LSP 94 Configuring setup priority for RSVP-TE LSP 95 Configuring the hold priority for RSVP-TE LSP 96 Configuring CSPF retry limit 96 Configuring CSPF retry timer 97 Configuring the hop limit for RSVP-TE LSP 98 Configuring label recording 99 Configuring route recording 99 Creating an MPLS administrative group 100 Adding an interface to an administrative group 100 Including administrative groups in an RSVP-TE LSP 101 Excluding administrative groups from an RSVP-TE LSP 102 Disabling affinity 103 Configuring Fast Reroute for constrained path LSP 103 Enabling and disabling one-to-one fast reroute protection 103 Configuring fast reroute node protection 104 Configuring fast reroute bandwidth 104 Specifying the administrative groups to include in the fast reroute 105 Excluding administrative groups from the fast-reroute 106 Configuring fast reroute setup priority 106 Configuring fast reroute hold priority 107 Configuring fast reroute hop limit 108 Configuring detour LSP identification method 108 Configuring RSVP-TE LSP properties 109 Configuring the extended tunnel ID in RSVP-TE messages 109 Configuring the creation and tear-down method for the RSVP-TE LSP 110 Restarting the RSVP-TE LSP 110 Configuring hello exchanges with a specific neighbor 111 Configuring RSVP-TE global and interface properties 112 Configuring the RSVP-TE source address 112 Configuring explicit-null labels 112 Configuring Penultimate-Hop-Popping 113 Configuring loop detection 113 Configuring MPLS tunnel-mode 114 Enabling the receipt of Hello messages globally 115 Enabling the receipt of Hello messages on the interface 115 Configuring the global Hello interval 116 Configuring the Hello interval and enabling Hello transmission on the interface 117 Configuring the global hello timeout 118 Configuring the interface hello timeout 118 Configuring the global RSVP keep multiplier 119 Configuring the interface RSVP keep multiplier 120

8 8 Configuring the global RSVP refresh time 121 Configuring the interface RSVP refresh time 121 Configuring the global refresh reduction advertisement 122 Configuring the interface refresh reduction advertisement 122 Configuring global message acknowledgement 123 Configuring interface message acknowledgement 124 Configuring the global acknowledgement wait timeout 124 Configuring the interface acknowledgement wait timeout 125 Mapping routes to RSVP-TE LSPs 125 Displaying RSVP-TE LSP configuration and statistics 126 Displaying session-related information for configured LSPs 126 Displaying LSP session count 127 Displaying session-related information for egress router 127 Displaying session-related information for specific egress router 127 Displaying session-related information for ingress router 128 Displaying session-related information for specific ingress router 128 Displaying session-related information for specific sessions 129 Displaying session-related information for transit router 129 Clearing traffic-engineered LSP data 130 Displaying RSVP-TE configuration and statistics 130 Displaying RSVP-TE interface information 130 Displaying RSVP-TE neighbors 131 Displaying next-hop data cached in RSVP-TE 131 Displaying RSVP-TE statistics 131 Displaying RSVP-TE summary refresh data 132 Displaying RSVP-TE version 132 Displaying traffic engineering path 132 Displaying MPLS tunnel mode 133 Displaying all configured MPLS administrative groups 133 Clearing RSVP sessions 133 Clearing RSVP statistics 134 MPLS Pseudowire configuration 135 Pseudowire configuration procedures 135 Pseudowire configuration task navigation 137 Configuring a pseudowire Layer 2 virtual circuit 137 Creating a Layer 2 virtual circuit 137 Binding an Ethernet interface to a Layer 2 virtual circuit 138 Binding a VLAN interface to a Layer 2 virtual circuit 138 Binding a WAN interface to a Layer 2 virtual circuit 139 Configuring a static FTN entry for ingress virtual circuit 140 Configuring a static ILM entry for egress virtual circuit 140 Displaying the pseudowire configuration and statistics 141 Displaying the static Layer 2-circuit FTN entry 141

9 9 Displaying the static L2-circuit ILM entry 141 Displaying the Layer 2 virtual circuit summary information 141 Displaying Layer 2 virtual circuit data 142 Displaying Layer 2 virtual circuit group data 142 Displaying Layer 2 virtual circuit statistics 142 Displaying Layer 2 virtual circuit table 143 Common procedures 145 Displaying MPLS-enabled interfaces 145 Displaying interface statistics 145 Displaying originating LSP statistics 146 Displaying MPLS forwarding table 146 Displaying incoming label map table 146 Clearing MPLS statistics 147 Configuration examples 149 Static LSP configuration 149 Static LSP configuration on Secure Router LSP configuration on Secure Router LDP-based LSP configuration 151 RSVP-TE LSP configuration 152 LSP1 configuration on SR LSP2 configuration on SR Configuring fast reroute for SR Configuring fast reroute for SR Configuring policy-based redirection into an RSVP-TE LSP 156 Ethernet over RSVP-TE pseudowire configuration 157 Ethernet over pseudowire configuration for SR Ethernet over pseudowire configuration for SR PPP over RSVP-TE pseudowire configuration 158 PPP over pseudowire configuration for SR PPP over pseudowire configuration for SR HDLC over MPLS pseudowire 160 HDLC over pseudowire configuration for SR Static L2VPN pseudowire configuration 162 SR configuration 163 SR configuration 164

10 10

11 . New in this release 11 The following section details what s new in Nortel Secure Router 2330/4134 (NN ) for Release Features See the following sections for information about feature changes: SR2330 hardware This document is updated to show support for the Nortel Secure Router 2330 (SR2330) chassis. HDLC over MPLS pseudowire Release 10.2 supports HDLC over MPLS pseudowire. With this feature, you can transmit HDLC traffic between sites over Ethernet packet-switched networks. For a configuration example, see HDLC over MPLS pseudowire (page 160). MPLS over VLAN Release 10.2 supports MPLS over VLAN interfaces. However, interface-specific parameter configurations are not supported for VLAN interfaces. In which case, the global MPLS parameters apply to MPLS over VLAN. For more information, see: Supported interfaces (page 16) Enabling LDP on an interface (page 76) Enabling RSVP-TE at the interface level (page 86) Adding an interface to an administrative group (page 100) Binding a VLAN interface to a Layer 2 virtual circuit (page 138) Other changes See the following sections for information about other changes.

12 12 New in this release Specifying controlled load traffic or guaranteed traffic for an LSP no longer supported The procedure for specifying controlled load traffic or guaranteed traffic for an LSP is removed. The SR2330/4134 supports only controlled-load service.

13 . Introduction 13 This document describes the operation and configuration of the MPLS features on the Secure Router 2330/4134 (Secure Router 2330/4134). Navigation MPLS fundamentals (page 15) LDP fundamentals (page 25) RSVP-TE fundamentals (page 33) MPLS Pseudowire fundamentals (page 45) Static LSP configuration (page 49) LDP LSP configuration (page 55) RSVP-TE LSP configuration (page 83) MPLS Pseudowire configuration (page 135) Configuration examples (page 149)

14 14 Introduction

15 . MPLS fundamentals 15 In traditional IP networks, each transit node makes an independent forwarding decision when transmitting packets through the network. MPLS defines a mechanism for forwarding traffic packets based on fixed-length labels instead of IP address-based routing at each hop. MPLS uses an underlying interior gateway protocol (IGP) to establish network reachability, and associates fixed-length labels with discovered routes to forward packets through the network. Packets are classified once, when they enter the MPLS domain, then travel along a predefined Label Switched Path (LSP) to the network egress. Transit nodes do not make any routing decisions when processing packets, but merely forward them based on the MPLS label, independent of the information in the encapsulated IP header. The ingress node assigns a fixed-length label to each packet as it enters the network, and forwards it to the next hop. As traffic moves through the network, each node swaps the incoming label for an outgoing label, based on a predefined label database on each node. MPLS elements The following sections describe the elements of MPLS networks. Label switched path A label switched path (LSP) is an end-to-end unidirectional tunnel set up between MPLS-enabled routers. Data travels through the MPLS network over LSPs from the network ingress to the network egress. The LSP is determined by a sequence of labels, initiated at the ingress node. Packets that require the same treatment for transport through the network are grouped into a forwarding equivalence class (FEC). The FECs are identified by the destination subnet of the packets to be forwarded. All packets within the same FEC use the same LSP to travel across the network. Packets are classified once, as they enter the network; all subsequent forwarding decisions are based on the FEC to which each

16 16 MPLS fundamentals packet belongs (that is, each label corresponds to a FEC). MPLS-enabled routers use a label distribution protocol (such as LDP or RSVP-TE) to generate and distribute label-to-fec bindings. Because LSPs are unidirectional, you must create a pair of LSPs to support bidirectional traffic. LSRs and LERs MPLS-enabled routers are grouped into two categories: label switching routers (LSRs), or provider (P) nodes label edge routers (LERs), or provider edge (PE) nodes LSRs reside in the network core, and provide high-speed switching functions for the network. LERs reside at the network edge, initiating and terminating LSPs and assigning packets to FECs as traffic enters the network. Each LSR and LER builds a Label Information Base (LIB) to map FECs to incoming and outgoing labels. Supported interfaces The Secure Router 2330/4134 supports MPLS on the following interfaces: WAN interfaces supporting PPP or HDLC encapsulation: T1/E1 interfaces CT3/DS3 interfaces Serial and HSSI interfaces WAN interfaces running MLPPP are not supported. All SR2330 Ethernet ports, and VLAN interfaces containing these ports. SR4134 Chassis Ethernet ports, and VLAN interfaces containing only Chassis Ethernet ports. SR4134 Module Ethernet ports and VLAN interfaces that contain any of these ports are not supported. Interface-specific MPLS parameter configurations are not supported for VLAN interfaces. In which case, the global MPLS parameters apply to MPLS over VLAN. MPLS cannot operate on IPSec-enabled (crypto) interfaces. MPLS label The following sections provide additional detail about the MPLS label distribution.

17 MPLS label 17 Label description As traffic enters the MPLS network, each packet is marked with a label. A label, in its simplest form, identifies the path a packet should traverse. An MPLS label is carried or encapsulated in between the Layer 2 and the Layer 3 header. The receiving router examines the packet for its label content to determine the next hop. Once a packet has been labeled, the rest of the journey of the packet through the MPLS network is based on label switching. The label values are of local significance only, meaning that they pertain only to hops between LSRs. Figure 1 MPLS label Label: Label carries the actual value of the Label. Exp: Experimental Use. Reserved for experimental use. S: Bottom of Stack. This bit is set to one for the last entry in the label stack, and zero for all other label stack entries TTL: Time to Live field is used to encode a time-to-live value. Label allocation As traffic enters the MPLS network, the ingress LSR groups traffic requiring similar treatment into forward equivalence classes (FECs). Each transit LSR maps the FECs to incoming and outgoing labels. Each downstream router advertise the FEC-to-label assignments to the upstream router. Operations on labels The Secure Router 2330/4134 supports the following label operations: Push: adds a new label onto the packet. Pop: removes the label from the packet. Swap: replaces the existing label with a new label.

18 18 MPLS fundamentals NHLFE The Next Hop Label Forwarding Entry (NHLFE) specifies the actions to take for each labeled packet. The details it provides include: next hop for the packet the operation to perform on the label: push, pop, swap ILM FTN The Incoming Label Map (ILM) maps each incoming label to a set of NHLFEs. MPLS uses the ILM to determine the action to perform on incoming labeled packets. The FEC-to-NHLFE (FTN) maps each FEC to a set of NHLFEs. MPLS uses FTN to determine the label to apply and the action to perform on incoming unlabeled packets. Penultimate Hop Popping Penultimate Hop Popping (PHP) provides a mechanism for improving label process efficiency at the LSP egress. With full PHP enabled, the egress LSR can save processing time on the outer label lookup by notifying its upstream neighbor to pop the outer label before forwarding the packet. Secure Router 2330/4134 supports three modes for Penultimate Hop Popping (PHP) behavior: Implicit null Explicit null PHP Disabled Implicit null In implicit null mode, the Secure Router 2330/4134 router advertises the implicit null label (label 3) for LSPs that it terminates. Label 3 indicates that the upstream router must remove the outer label before forwarding the packet to the egress router, without replacing it with another label. Upon receipt, the Secure Router 2330/4134 router does not have to process the outer label, and forwards the packet based on the next inner label or the destination address in the encapsulated IP header.

19 Penultimate Hop Popping 19 Figure 2 Implicit null Figure 3 Explicit null Explicit null In explicit null mode, the Secure Router 2330/4134 router advertises the explicit null label (label 0) for LSPs that it terminates. The upstream router uses label 0 as the outgoing label for the packet, which indicates to the Secure Router 2330/4134 router that it is the final hop on the LSP. Upon receipt, the Secure Router 2330/4134 router pops the label without performing a label lookup, and forwards the packet based on the next inner label or the destination address in the encapsulated IP header. In explicit-null mode, the system marks the EXP bits in the explicit-null label to match the EXP bits of the popped label, so that Diff-Serv treatment is preserved at the egress LER. PHP disabled If PHP is disabled, the Secure Router 2330/4134 router advertises a normal label (from the range ) for an LSP when sending a label mapping to the upstream router. Upon receipt of a packet, the

20 20 MPLS fundamentals Figure 4 PHP disabled Secure Router 2330/4134 router performs a label lookup, then pops the label and forwards the packet based on the next inner label (if present) or the destination address in the encapsulated IP header. Because each egress LSP is assigned a different label, this option allows traffic statistic collection for individual egress LSPs. LSP routes When you configure an LSP on an ingress router, the ingress router configures an associated host route toward the egress router. The host route address is the destination address of the LSP. The default administrative distance of the route is set to 10, which is higher than all routes other than direct interfaces and static routes. The route is configured with a 32-bit mask, which ensures that the route is a longer match and therefore more specific than all other subnet routes. Routing traffic with policy-based redirection To route traffic to LSPs, you can also use the QoS policy-based redirect feature. This feature allows you to redirect user-configured traffic flows to specific LSPs. For details, see Performance Management Quality of Service (NN ). Types of LSPs There are three types of LSP: Static LSP LDP LSP RSVP-signaled LSP

21 Types of LSPs 21 Figure 5 Static LSP Static LSP Static LSPs are manually configured LSPs. No label distribution protocol is enabled. For each LSR along the LSP path, you must manually configure LSP labels, similar to static routes. The following figure shows the label actions that each LSR must perform along the LSP path. LDP LSP LDP allows routers to discover neighbors and to establish LDP sessions with them so that they can exchange label mapping information. An LDP LSR identifies the best routes, as selected by the underlying IGP, and binds a locally significant label to each, then propagates this binding to neighbors. RSVP-TE-signaled LSPs Resource Reservation Protocol with traffic engineering extensions (RSVP-TE) is a label signaling protocol that allows you to set up traffic-engineered LSPs through the MPLS network. RSVP-TE allows an ingress router to set up traffic-engineered LSPs (also called tunnels) through the MPLS network. The intermediate and egress routers accept RSVP-TE signaling messages from the ingress router to set up and maintain the LSP and dynamically assign labels. Where LDP LSPs are dynamic, RSVP-TE tunnels are user-initiated: you need only configure the ingress router. You can use RSVP-TE to create tunnels that avoid points of congestion in the network. RSVP-TE-signaled LSPs can be one of two types: explicit-path LSP or constrained-path LSP.

22 22 MPLS fundamentals Explicit-path LSP With explicit-path LSPs, you can manually specify the intermediate hops along the LSP. Each hop in the explicit-path LSP is either strict or loose. If the hop is strict, the LSP must go to the specified address directly, without traversing any intermediary nodes. If the hop is loose, the RSVP-TE relies on IGP lookups to determine the best route to the specified address. Constrained-path LSP With constrained-path LSP, the router uses the Constrained Shortest Path First (CSPF) protocol to determine the LSP path. In this case, RSVP-TE and CSPF must be enabled on all routers along the LSP path. With CSPF LSPs, you can specify traffic engineering parameters that must be met by each LSR in order to create the LSP. Standards compliance The Secure Router 2330/4134 implementation of MPLS complies with the following RFCs: RFC 2702, Requirements for Traffic Engineering Over MPLS RFC 3031, MPLS Architecture RFC 3032, Label Stack Encoding RFC 3036, LDP Specification RFC 3215, LDP State Machine RFC 2205, Resource ReSerVation Protocol (RSVP)--Version 1 Functional Specifications RFC 2209, RSVP Version 1 Message Processing Rules RFC 2961, RSVP Refresh Overhead Reduction Extensions RFC 3209, RSVP-TE: Extensions to RSVP for LSP Tunnels RFC 3210, Applicability Statement for Extensions to RSVP for LSP-tunnels RFC 4090, Fast Reroute Extensions to RSVP-TE for LSP Tunnels The Secure Router 2330/4134 implementation of MPLS pseudowire complies with the following RFCs: draft-ietf-pwe3-arch-07.txt,sept-2004, PWE3 Architecture. draft-ietf-pwe3-requirements-08.txt,june-2004, Requirements for Pseudo-Wire Emulation Edge-to-Edge draft-ietf-pwe3-control-protocol-06.txt,sept-2004, Pseudowire Setup and Maintenance using LDP (draft-martini-l2circuit-trans-mpls-13.txt, June-2004)

23 Standards compliance 23 draft-ietf-pwe3-ethernet-encap-06.txt,june-2004, Encapsulation Methods for Transport of Ethernet Frames Over IP/MPLS Networks (draft-martini-l2circuit-encap-mpls-06.txt, May-2004) draft-ietf-pwe3-hdlc-ppp-encap-mpls-03.txt,oct-2004, Encapsulation Methods for Transport of PPP/HDLC Over IP and MPLS Networks

24 24 MPLS fundamentals

25 . LDP fundamentals 25 Label Distribution Protocol (LDP) provides a mechanism for dynamic hop-by-hop label distribution between routers in an MPLS network. LDP assigns labels to IGP-learned routes and distributes these label bindings to its peers, to establish label switched paths (LSPs) through the network. LDP overview LDP allows routers to discover neighbors and to establish LDP sessions so they can exchange label mapping information. Each LDP router identifies the best routes, as selected by the underlying IGP, and binds a locally significant label to each, then propagates this binding to neighbors. LDP identifier and label space When a router running LDP communicates with its peers, it identifies itself with a unique LDP identifier (ID). The LDP ID indicates the LSR s IP address (that is, the LSR ID) and the label space from which the LSR assigns its labels. Thus, the LSR advertises its LDP ID in the format <LSR ID>:<label space>. The Secure Router 2330/4134 LSR ID is the same as the node router ID. The router ID is a unique 32-bit address that identifies the router to routing protocols such as OSPF. The router ID is typically a local IP address, and therefore reachable by IP. The Secure Router 2330/4134 also uses its router ID for the LDP transport address, required for the TCP session over which LDP runs. The transport address must be one of the node s local IP addresses (preferably a loopback address) for LDP to operate; therefore, if LDP is running on the node, the router ID must be a local IP address. The Secure Router 2330/4134 supports a per-platform, or global, label space 0. LDP discovery LDP discovery is the process by which LDP routers discover neighboring routers, for the purpose of exchanging label-to-fec binding information. LDP routers exchange LDP Hello messages to form a Hello adjacency, prior to establishing an LDP session.

26 26 LDP fundamentals Figure 6 LDP discovery LDP uses two types of discovery to find LDP peers: Basic discovery LDP uses basic discovery to find directly-connected routers with which to exchange label information. The router transmits multicast UDP Hello messages to all routers on the subnet. When the neighbor responds with Hello messages to the local router, the two routers form a Hello adjacency. Extended discovery Extended discovery allows an LDP router to discover peers that are not directly connected to it, and to establish LDP sessions with them. The router transmits unicast UDP Hello messages to a specific peer router, which may or may not be directly connected to it. If the peer responds to these targeted Hello messages, the pair form an extended Hello adjacency and normal LDP session establishment procedures follow. LDP sessions When MPLS routers have formed an LDP Hello adjacency, they establish an LDP session. LDP sessions are bidirectional and allow LDP peers to learn each other s label-to-fec bindings. The LDP session is identified by the pair of LDP IDs: the LDP ID of the local router and LDP ID of the peer router. If the Secure Router 2330/4134 connects to a peer node over multiple interfaces, the LDP ID pair (that is, local LDP ID, peer LDP ID) is the same for each Hello adjacency between the two nodes. When this occurs, only one LDP session is established between the two LSRs, with all Hello adjacencies being part of that session. The LDP session remains active as long as at least one Hello adjacency to the peer router is up; thus, a link failure does not impact the LDP control path as long as there is at least one physical connection to the peer.

27 LDP overview 27 Figure 7 LDP sessions LDP message types The following table describes the LDP message types. Table 1 LDP message types Discovery Session Advertisement Notification Secure Router 2330/4134 uses discovery messages to announce its presence in a network by periodically transmitting multicast UDP Hello messages to all routers on the subnet or unicast UDP Hello messages to a specific router. Secure Router 2330/4134 uses session messages to establish, maintain, and terminate sessions between LDP peers. After MPLS routers have formed an LDP Hello adjacency, they establish an LDP session over Transmission Control Protocol (TCP). When the session is successfully established, the two routers can exchange advertisement messages. Secure Router 2330/4134 uses advertisement messages to advertise FEC-to-label bindings to LDP peers. Secure Router 2330/4134 sends LDP notification messages to report errors and events. Error notifications signal fatal errors. If a router receives an error notification from a peer for an LDP session, it terminates the LDP session by closing the TCP transport connection for the session and discarding all label mappings learned through the session. Advisory notifications, which pass information to a router about the LDP session or the status of some previous message received from the peer.

28 28 LDP fundamentals LDP operation modes LDP has several control modes that affect how labels are exchanged between LSRs: Label advertisement modes (page 28) Label retention mode (page 29) Label control mode (page 30) Label advertisement modes The label advertisement mode determines when an LSR advertises a FEC-to-label binding to its LDP peers. LDP has two label advertisement modes: downstream unsolicited (DU) and downstream-on-demand (DoD) mode. The Secure Router 2330/4134 only supports the downstream unsolicited mode. For any single LDP adjacency, the LDP peers must agree on a label distribution mode. Downstream-unsolicited label advertisement With downstream-unsolicited label advertisement, each LSR advertises its FEC-to-label assignments to upstream routers as soon as they are available; thus, upstream routers do not have to send label mapping requests for FECs. Downstream-unsolicited advertisement is typically used with the liberal label retention mode. Figure 8 Downstream-unsolicited label advertisement Downstream-on-demand label advertisement The Secure Router 2330/4134 does not support downstream-on-demand label advertisement. The following information is provided for reference only. With Downstream-on-demand label advertisement, LSRs only advertise a FEC-to-label assignment in response to a specific request from an upstream router.

29 LDP operation modes 29 Downstream-on-demand advertisement is typically used with the conservative label retention mode. Figure 9 Downstream-on-demand label advertisement Label retention mode The label retention mode determines which labels an LSR retains in its Label Information Base (LIB), particularly those FEC-to-label bindings that are learned from neighbors that are not next hops for the FEC. LDP provides supports two label retention modes: liberal and conservative. The Secure Router 2330/4134 only supports the liberal label retention mode. Liberal label retention In liberal label retention mode, the LSR accepts and retains all label mappings received from LDP peers, regardless of whether the neighboring router is actually the next hop for the FEC. This means that the router can quickly adapt to routing changes in the network because it already has alternate labels for the same FEC; however, it requires that the LSR maintain a much larger LIB and retain labels that it may never use. Figure 10 Liberal label retention

30 30 LDP fundamentals Conservative label retention The Secure Router 2330/4134 does not support conservative label retention. The following information is provided for reference only. In conservative label retention mode, the LSR discards any label mappings it receives that were not originated by the current next hop for the FEC. This means that the router has fewer labels to maintain in the LIB; however, if the next hop for a FEC changes, the router must request a new label mapping from new next hop, resulting in slower network convergence. Figure 11 Conservative label retention Label control mode The label control mode controls when labels are distributed between LDP peers when creating an LSP. The Secure Router 2330/4134 supports both LDP label control modes: ordered and independent. Independent In independent mode, an LSR advertises label mappings for FECs at any time, regardless of whether it is the egress for the FEC or has received a label mapping from the next hop for the FEC. FEC-to-label bindings are advertised as soon as the next hop has been recognized. In independent downstream-on-demand mode, an LSR can answer requests for label mappings immediately, without waiting for a label mapping from the next hop. In independent downstream unsolicited mode, an LSR can advertise a label mapping for an FEC to neighbors whenever it is prepared to label-switch that FEC.

31 LDP loop detection 31 Ordered In ordered mode, an LSR only advertises label mappings for an FEC when it is the egress router for the FEC, or when it has received a label mapping from the current next hop for the FEC. If neither of these conditions are met, the LSR must wait for a label mapping from a downstream neighbor before it can map the FEC to a label and advertise the binding to an upstream neighbor. In this way, an LSP is set up from egress to ingress, hop-by-hop. ACL configuration with LDP With LDP, you can use ACL to modify the routes to be distributed to peering neighbors. You can configure ACL rules to permit or deny the advertisement of labels for specific routes to a configured list of neighbors. After the routes are redistributed, denied routes are no longer advertised to the listed LDP neighbors. LDP loop detection LDP supports two mechanisms for LDP loop detection: Hop count limit Path vector limit The Secure Router 2330/4134 only supports the hop count limit mechanism for loop detection. Hop count limit With the hop count limit method, each LSR increments the hop count field in the LDP packet as it traverses the network. If the value in the hop count field exceeds a predetermined value (established by the router that initiates the LSP), the LSR assumes a routing loop and discards the packet. Path vector limit The Secure Router 2330/4134 does not support the path vector limit mechanism for loop detection. The following information is provided for reference only. With the path vector limit method, each LSR adds its router ID to the path vector field as it processes a packet. If an LSR sees its own router ID in the list of intermediate hops, or if the number of entries in the path vector field exceeds a predetermined value (established by the router that initiates the LSP), the LSR assumes a routing loop and discards the packet.

32 32 LDP fundamentals

33 . RSVP-TE fundamentals 33 Resource Reservation Protocol with traffic engineering extensions (RSVP-TE) is a label signaling protocol that allows you to set up traffic-engineered LSPs through the MPLS network. You can set up multiple RSVP LSPs to the same destination with the same or different traffic engineering parameters. RSVP-TE overview RSVP-TE allows an ingress router to set up traffic-engineered LSPs (also called tunnels) through the MPLS network. You can use RSVP-TE to create tunnels that avoid points of congestion in the network or load balance across of available network resources. Where LDP LSPs are dynamic, RSVP-TE tunnels are user-initiated. RSVP tunnels are persistent: that is, when an LSP goes down, the router attempts to re-establish the LSP, based on a configurable retry limit and retry interval. When the node reaches the retry limit without restoring the LSP, no further attempts are made to establish the LSP until it is administratively disabled and re-enabled. Control messages RSVP-TE is a soft-state protocol. LSRs exchange periodic control messages to refresh state information, and any non-refreshed states time out automatically. This allows RSVP-TE to adapt to changes in topology and resource availability, and to recover from any failures more quickly. RSVP-TE uses two primary messages to set up and maintain tunnels: the Path message, to request resources and label bindings, and the Resv message, to confirm available resources and distribute label-to-fec bindings. You can control how often the Path and Resv messages are sent, and how long the Secure Router 2330/4134 waits before removing forwarding states and resource reservations after receiving a control message.

34 34 RSVP-TE fundamentals Table 2 RSVP-TE message types Message Path Resv PathTear ResvTear PathErr ResvErr ResvConfirm Description Requests resources and label mapping for a new LSP, or refreshes path state information for an existing LSP. Reserves resources for a new LSP and specifies label mapping, or refreshes reservation state information for an existing LSP. Removes path states in routers along an LSP; usually initiated by the sender. Releases reservation states along an LSP; usually initiated by the receiver. Indicates a problem establishing a new path or refreshing existing state information (advisory message only). Indicates a problem reserving resources for a new LSP, or refreshing existing resource reservation information (advisory message only). Confirms that resources have been reserved for a new LSP. RVSP-TE tunnel setup RSVP-TE tunnels are source-routed. The ingress LER determines the path through the network to the destination, based on a user-provided list of explicit hops, or along the best route selected by the underlying IGP (calculated from local routing tables). LSRs exchange Path and Resv messages to set up and maintain RSVP-TE tunnels, using the Label Object in the Resv messages for label distribution. When setting up an RSVP-TE tunnel, the ingress LER sends a Path message to the egress LER, requesting resources and label mapping information. The Path message is propagated downstream through the network, and stores a path state (indicating the previous and next-hop address) in each transit node as it travels to the egress LER. The egress LER responds with a Resv message, confirming that resources are available for the LSP. The Resv message travels upstream to the ingress router, along the same route as the original Path message (in the reverse direction). The Resv message stores a reservation state in each transit node, and specifies the local label binding for the LSP to each successive upstream router. When the ingress LER receives the Resv message, the tunnel is established.

35 RSVP-TE resource reservation styles 35 Figure 12 RSVP-TE tunnel setup OSPF-TE and CSPF OSPF-TE is an extension to OSPF that can identify the shortest path to a destination node that can meet specific bandwidth requirements. It is used to identify and propagate bandwidth-constrained routes throughout the network. Using the routes provided by OSPF-TE, the Secure Router 2330/4134 uses the CSPF algorithm to compute the best paths for LSPs that are subject to various constraints such as: bandwidth, hop count, administrative groups, priority and explicit routes. When computing paths for LSPs, CSPF considers not only the topology of the network and the attributes defined for the LSP but also the links. It attempts to minimize congestion by intelligently balancing the network load. Using the information calculated with CSPF, the Secure Router 2330/4134 then uses RSVP-TE as the signaling protocol to set up and maintain the traffic-engineered LSPs through the MPLS network. RSVP-TE resource reservation styles Resource reservation provides control over bandwidth allocation during LSP setup. Secure Router 2330/4134 supports both RSVP-TE resource reservation styles: Fixed filter Shared explicit

36 36 RSVP-TE fundamentals Fixed filter A fixed filter (FF) reservation creates a distinct resource reservation for each sender in a specified list. Each reservation is specific to a sender, and is not shared with any other sender in the session. Fixed filter reservation is appropriate for traffic flows that are independent but likely to be transmitted at the same time (such as video applications). RSVP-TE tunnels reserved with fixed filter (FF) style never share bandwidth with other LSPs. The tunnel consumes its own share of the bandwidth on all links traversed. Figure 13 Fixed filter Shared explicit A shared explicit (SE) reservation creates a single resource reservation that is shared by all senders in a specified list. RSVP-TE tunnels reserved with shared explicit (SE) style in the same RSVP session can share bandwidth on common links. SE style is usually used when traffic can only flow on one of the LSPs in the session at a given time, for instance, for primary and backup LSPs, or when performing LSP optimization or modification. LSPs that belong to different sessions, even when SE style is used, cannot share bandwidth.

37 Explicitly routed LSPs 37 Figure 14 Shared explicit Priority of signaled LSP In cases where there is insufficient bandwidth to accommodate the creation of a new LSP, the Secure Router 2330/4134 can remove less important existing LSPs to free up the necessary bandwidth for the new LSP. This can be done by preempting one or more of the signaled LSPs. To specify the relative priority for the existing LSP and the new LSP, you can configure the following parameters: Setup priority The setup priority determines if a new LSP can preempt an existing LSP. The setup priority of the new LSP must be higher than the hold priority of an existing LSP for the existing LSP to be preempted. Please note that for a trunk, the setup priority should not be higher than the hold priority. Hold priority The hold priority determines the degree to which an LSP holds onto its reservation for a session after the LSP has been set up successfully. When the hold priority is high, the existing LSP is less likely to give up its reservation. Explicitly routed LSPs RSVP-TE tunnels can be configured to traverse specific nodes through the network. The Explicit Route Object (ERO) in the Path message defines one or more hops in the LSP, specified by an IP address. Each hop in the ERO is either strict or loose. If the hop is strict, the LSP must go to the specified address directly, without traversing any intermediary nodes. If the hop is loose, the RSVP-TE relies on IGP lookups to determine the best route to the specified address (either directly

38 38 RSVP-TE fundamentals or otherwise). If no ERO is specified, the tunnel destination is treated as a single loose hop. Secure Router 2330/4134 supports a combination of strict or loose hops in the ERO. A hop can identify a link or a loopback address (such as a router ID). To ensure that an RSVP-TE tunnel takes a specific link, you must specify the IP address of the link interface on the neighboring router; otherwise, specify the router loopback address, so that the LSP can be re-routed in the event of a link failure. Once established, explicitly routed RSVP-TE tunnels are pinned: changes in the network topology (for example, when the IGP learns of a better route) have no impact on the LSP path. If the LSP is torn down (for example, because of a link failure), the node attempts to re-establish the LSP and uses the most recent IGP information to setup the LSP path. Route Recording Route recording describes the actual path taken by an LSP, as a list of all the nodes traversed from ingress to egress. When route recording is enabled, each node records its LSR ID in the Route Record Object (RRO) of the Path message before forwarding it to the next hop. Route recording is a useful diagnostic tool when examining the path of an LSP (particularly for LSPs with loose hops, that rely on the IGP for the best path), or for loop detection. Refresh reduction Due to the soft-state nature of RSVP, LSRs must exchange control messages periodically to refresh installed state information in each node. Additionally, because control messages are sent as IP datagrams (with no guaranteed delivery), periodic refresh messages cover any lost messages. However, as the number of RSVP-TE sessions increases, so does the volume of control traffic between nodes. Refresh reduction allows you to reduce the amount of RSVP control traffic in the network. To provide RSVP refresh reduction, the Secure Router 2330/4134 supports reliable messaging. Reliable messaging Reliable messaging provides an acknowledgement mechanism between RSVP-TE neighbors to confirm that control messages have been delivered successfully. Since message loss can be detected independently, RSVP does not have to rely on periodic refresh messages to recover from any dropped messages, and the refresh interval can be longer. This reduces the amount of control traffic between RSVP-TE neighbors.

39 Fast reroute and node protection 39 A receiver acknowledges successful RSVP message delivery with either an ACK message (that references the original message s ID) or piggy-backed in another RSVP message. Fast reroute and node protection For an LSP to survive the failure of a node in the path, you can configure fast reroute one-to-one protection. Fast reroute protection provides an alternate path to a downstream router in case of a link failure. The alternate path uses a different interface to reach the same downstream router. The upstream router signals the ingress router about the failure to maintain the flow of traffic. Figure 15 Fast reroute If the failed LSR comes back up, the LSP reverts to the original protected path. Node protection The Secure Router 2330/4134 also supports fast reroute with node protection. In this case, if an LSR fails, the alternate path initiated by the upstream router bypasses the failed router completely, reconnecting to the original LSP path at the next downstream router. Figure 16 Fast reroute with node protection

40 40 RSVP-TE fundamentals Secondary LSP (global repair) The Secure Router 2330/4134 supports RSVP-TE LSP protection through primary and secondary paths. An LSP can have a primary path and (optionally) a secondary backup path. The secondary path is always pre-established, thus eliminating the need to calculate a new route and signal a new path during a failure. However, no traffic is allowed on the secondary LSP path until it is promoted to active LSP status. You only need to configure the secondary LSP on the ingress router. If the primary LSP fails, the ingress router automatically reroutes traffic over to the secondary LSP. When the primary LSP recovers, the traffic automatically reverts back to the primary LSP. Figure 17 Primary and secondary LSP Secondary LSP signaling The Secure Router 2330/4134 can perform Secondary LSP signaling using either of 2 independent methods: Sender-Template Identification method: In this method, a detour shares the RSVP Session object and LSPID with the protected LSP and changes the ingress IP address in the RSVP PATH message. According to the RSVP resource sharing rules, this LSP can be merged with the protected LSP as they have same session object. Path Specific method: In this method, a new RSVP object (DETOUR) is added to the PATH message to differentiate it from the protected LSP s path messages. Since, a detour has the same session object as the protected LSP, it can share common network resources.

41 MPLS QoS 41 Secondary LSP with fast reroute Fast reroute and secondary LSP are independent features which can be enabled for the LSP at the same time. In this case, if the primary LSP goes down, the route switches first to the fast reroute. Then, if a secondary LSP is configured, the LSP switches to the secondary LSP as the permanent LSP. Fast reroute is typically used only as a temporary entity, as the detour LSP is not necessarily traffic-engineering optimal, unlike the primary and secondary LSP, which are always optimal paths. Administrative groups Administrative groups are manually assigned attributes that describe the "color" of links, so that links with the same color are in one class. These groups are used to implement different policy-based LSP setups. With RSVP-TE, you can specify the administrative groups to include or exclude in the primary or secondary path for an LSP. The available options are: include-any: all links must belong to at least one of the administrative groups listed in the include-any list. include-all all links must belong to all of the administrative groups listed in the include-all list exclude-any none of the links must have a color found in the list of groups. MPLS QoS MPLS QoS provides support for global DSCP-to-EXP mapping on the ingress LER, and global EXP-to-DSCP mapping on the egress LER. On the ingress LER, MPLS QoS also supports flow-based EXP marking for inbound traffic, and class-based queueing for outbound traffic. The following sections provide an overview of the supported MPLS QoS features. For detailed QoS configuration information, see Configuration Traffic Management (NN ).