MPLS TE Basics
MPLS TE Basics
MPLS TE Overview
Traditional IP routing is based on forwarding the traffic to the destination as quickly as possible. As a result, the routing protocols find out the shortest path to the destination based on the cost of the link (also called metric) that the packet is forwarded. Further, the IP packets are forwarded on a per-hop basis i.e. every router (hop) forwards the packet based on the destination IP address. Traditional IP routing does not take into account the available bandwidth of the link. This can cause some links to be over-utilized compared to others.
This behavior in traditional IP routing can be tackled using Policy-based Routing (PBR). However, it requires policies to be implemented on every router along the path to the destination. This can result in massive configurations on every router. MPLS TE solves this problem-
- Source-based routing is applied to the traffic from the headend router (source of MPLS TE tunnel). An explicitly defined path can be configured on the headend router through which the traffic for a particular LSP must follow.
- MPLS TE provides efficient way of forwarding traffic throughout the network, avoiding over-utilized and under-utilized links.
- MPLS TE adapts to changing bandwidth.
- MPLS TE takes into account configured bandwidth of the links.
For example, if traffic engineering is to be applied for destinations behind PE4 router coming from within the PE1 router in the below network (every link represents {cost, bandwidth}), an explicit path can be configured on the PE1 router which defines how exactly the traffic must be forwarded. All the intermediate routers follow this explicitly defined path by PE1 router. Thus, PE1 can suggest all traffic to follow PE1-P2-P3-PE4 path for traffic destined for destinations behind PE4 router. Comparing this to traditional IP routing, all traffic for destinations behind PE4 router would follow the path PE1-P2-PE4 due to its shortest path.
OSPF Extensions for MPLS TE
A link-state routing protocol (IS-IS or OSPF) is required in MPLS TE for resource allocation information flooding through the network. The resource attributes are flooded by the routers to make them available at the headend router of the TE tunnel during LSP path computation. OSPF can be used using extended link attributes. The information made available by these extensions can be used to build an extended link-state database just as Router LSAs are used to build a link-state database. The extended link-state database (also appropriately called TE database) has additional link attributes. For example, an OSPF router can participate in an OSPF area, build a TE database and report on reservation state of links in that area.
This extension makes use of Opaque LSA. RFC 2370 defines Opaque LSA. They are of 3 types- Type 9, 10 and 11 LSAs. Type-9 LSAs are not flooded beyond the local network. Type-10 LSAs are not flooded beyond the borders of their associated area. Type-11 LSAs are flooded throughout the AS. Opaque LSAs are not flooded to non-opaque-capable routers. Opaque capability is learnt at the beginning of DBD exchange- opaque-capable routers set O-bit in Options field of the DBD packets.
An Opaque LSA called Traffic Engineering LSA (TE LSA) carries the additional attributes related to TE links, and standard link-state database flooding mechanisms are used to distribute TE LSAs. It describes routers, p2p links, and connections to multi-access network (like Router LSA).
The LSA payload consists of one or more nested TLVs (Type, Length, Value) triplets for extensibility. There are two types of TE LSAs.
1. Router Address TLV (Type 1): This TLV specifies a stable IP Address (usually the Loopback interface) of the advertising router.
2. Link TLV (Type 2): This TLV describes a TE link. It is constructed of a set of sub-TLVs that specify the link attributes. The following are the sub-TLVs defined:
- Link Type: This sub-TLV indicates whether the link is point-to-point or multi-access.
- Link ID: This sub-TLV identifies the other end of the link. If the link is a point-to-point link, this field is the Router-ID of the neighbor. For a multi-access link, this field is the IP address of the DR.
- Local Interface IP Address: This sub-TLV specifies the IP address(es) of the interface corresponding to this link. If there are multiple IP addresses, they are all listed.
- Remote Interface IP Address: This sub-TLV specifies the IP address(es) of neighbor's interface corresponding to this link. If the link type is multi-access, this field is set to 0.0.0.0.
- Traffic Engineering Metric: This sub-TLV specifies the link metric for TE purposes. This metric is configurable (using mpls traffic-eng administrative-weight interface configuration command) and hence can be different to OSPF metric.
- Maximum Bandwidth: This sub-TLV specifies the maximum bandwidth that can be used on this link from this router to the neighbor. This can be configured using bandwidth <value> interface configuration command, or, the default interface bandwidth is accepted.
- Maximum Reservable Bandwidth: This sub-TLV specifies the maximum reservable bandwidth on this link, in this direction. This can be configured using ip rsvp bandwidth <value> interface configuration command.
- Unreserved Bandwidth: This sub-TLV specifies the total bandwidth not reserved yet at each of eight priority levels (0 - 7).
- Administrative Group: This is also called Resource (link) color. This sub-TLV contains a 4-byte bit mask assigned by the network administrator. Each set bit corresponds to one administrative group assigned to the interface. The least significant bit is referred to as "group 0" and the most significant bit is referred to as "group 31". This can be configured using mpls traffic-eng attribute-flags interface configuration command.
To enable MPLS TE for OSPF, the following simple configuration is required on each router from headend to tailend. Also, all interfaces willing to participate in MPLS TE must be enabled with mpls traffic-eng tunnels (this command must also be enabled globally) and ip rsvp bandwidth commands. The later command reserves bandwidth for RSVP. By default, 75% of the bandwidth available on an interface can be reserved.
Enabling MPLS TE in OSPF
router ospf 1 mpls traffic-eng area 0 mpls traffic-eng router-id Loopback 0!!--- The following output shows bandwidth reserved by RSVP on RSVP-enabled interfaces on each routerPE1# show ip rsvp interfaceinterface allocated i/f max flow max sub maxFa0/0 0 75M 75M 0P2# show ip rsvp interfaceinterface allocated i/f max flow max sub maxFa0/0 0 75M 75M 0Fa0/1 0 75M 75M 0Fa1/0 0 7500K 7500K 0P3# show ip rsvp interfaceinterface allocated i/f max flow max sub maxFa0/1 0 75M 75M 0Fa0/0 0 75M 75M 0PE4# show ip rsvp interfaceinterface allocated i/f max flow max sub maxFa0/0 0 7500K 7500K 0Fa0/1 0 75M 75M 0A sample packet capture of TE LSA is as below:
Constraint-based SPF (CSPF)
In normal SPF calculation process, a router places itself at the root of the tree with shortest paths to each of the destinations, only taking into account least metric (cost) to the destination.
The process that generates a path for a TE tunnel to take is different from the regular SPF process. CSPF uses more than link cost to identify the probable paths that can be used for TE LSP paths. CSPF determines the best path to only the tunnel tailend router, not to all routers. Further, instead of just a single cost for a link between two neighbors, there's also bandwidth, link attributes and administrative weight. The decision as to which path is chosen to set up a TE LSP is performed at the headend router after ruling out all links that do not meet the bandwidth requirements in addition to the cost of the link. The result of the CSPF calculation is an ordered list of IP addresses that maps to the next-hop addresses of routers that form the TE LSP.
CSPF takes the input from, both, user-specified path constraints and the information in TE database, before initiating the path computation. The following example shows basic user-specified constraints on PE1 router in Figure-1:
User-specified Path Constraints on PE1 router
interface Tunnel 10 ip unnumbered Loopback 0 tunnel mode mpls traffic-eng tunnel destination 4.4.4.4 tunnel mpls traffic-eng path-option 2 dynamic tunnel mpls traffic-eng bandwidth 20000 tunnel mpls traffic-eng record-route!For the network in Figure-1, the TE database on PE1 router looks like as below. All the routers in the network have a similar TE database. Notice the maximum reservable bandwidth advertised by P2 and PE4 routers highlighted in Yellow.
TE Database on PE1 router
PE1# show ip ospf database OSPF Router with ID (1.1.1.1) (Process ID 1) Router Link States (Area 0)Link ID ADV Router Age Seq# Checksum Link count1.1.1.1 1.1.1.1 189 0x80000002 0x001ED1 12.2.2.2 2.2.2.2 164 0x80000004 0x00FA28 33.3.3.3 3.3.3.3 146 0x80000003 0x00EA66 24.4.4.4 4.4.4.4 146 0x80000003 0x00C284 2 Net Link States (Area 0)Link ID ADV Router Age Seq# Checksum10.12.1.2 2.2.2.2 191 0x80000001 0x00A76510.23.1.2 3.3.3.3 165 0x80000001 0x00599C10.24.1.1 2.2.2.2 183 0x80000001 0x00B73E10.34.1.2 4.4.4.4 146 0x80000001 0x000BD3 Type-10 Opaque Link Area Link States (Area 0)Link ID ADV Router Age Seq# Checksum Opaque ID1.0.0.0 1.1.1.1 211 0x80000001 0x00FE4A 01.0.0.0 2.2.2.2 191 0x80000001 0x002917 01.0.0.0 3.3.3.3 166 0x80000001 0x008C80 01.0.0.0 4.4.4.4 185 0x80000001 0x00E945 01.0.0.1 2.2.2.2 192 0x80000001 0x00D668 11.0.0.1 3.3.3.3 50 0x80000001 0x00D663 11.0.0.1 4.4.4.4 147 0x80000001 0x00CA55 11.0.0.2 2.2.2.2 192 0x80000001 0x006BE7 2PE1# show ip ospf database opaque-area OSPF Router with ID (1.1.1.1) (Process ID 1) Type-10 Opaque Link Area Link States (Area 0) LS age: 247 Options: (No TOS-capability, DC) LS Type: Opaque Area Link Link State ID: 1.0.0.0 Opaque Type: 1 Opaque ID: 0 Advertising Router: 1.1.1.1 LS Seq Number: 80000001 Checksum: 0xFE4A Length: 132 Fragment number : 0 MPLS TE router ID : 1.1.1.1 Link connected to Broadcast network Link ID : 10.12.1.2 Interface Address : 10.12.1.1 Admin Metric : 10 Maximum bandwidth : 12500000 Maximum reservable bandwidth : 9375000 Number of Priority : 8 Priority 0 : 9375000 Priority 1 : 9375000 Priority 2 : 9375000 Priority 3 : 9375000 Priority 4 : 9375000 Priority 5 : 9375000 Priority 6 : 9375000 Priority 7 : 9375000 Affinity Bit : 0x0 IGP Metric : 10 Number of Links : 1 LS age: 229 Options: (No TOS-capability, DC) LS Type: Opaque Area Link Link State ID: 1.0.0.0 Opaque Type: 1 Opaque ID: 0 Advertising Router: 2.2.2.2 LS Seq Number: 80000001 Checksum: 0x2917 Length: 132 Fragment number : 0 MPLS TE router ID : 2.2.2.2 Link connected to Broadcast network Link ID : 10.12.1.2 Interface Address : 10.12.1.2 Admin Metric : 10 Maximum bandwidth : 12500000 Maximum reservable bandwidth : 9375000 Number of Priority : 8 Priority 0 : 9375000 Priority 1 : 9375000 Priority 2 : 9375000 Priority 3 : 9375000 Priority 4 : 9375000 Priority 5 : 9375000 Priority 6 : 9375000 Priority 7 : 9375000 Affinity Bit : 0x0 IGP Metric : 10 Number of Links : 1 LS age: 204 Options: (No TOS-capability, DC) LS Type: Opaque Area Link Link State ID: 1.0.0.0 Opaque Type: 1 Opaque ID: 0 Advertising Router: 3.3.3.3 LS Seq Number: 80000001 Checksum: 0x8C80 Length: 132 Fragment number : 0 MPLS TE router ID : 3.3.3.3 Link connected to Broadcast network Link ID : 10.34.1.2 Interface Address : 10.34.1.1 Admin Metric : 10 Maximum bandwidth : 12500000 Maximum reservable bandwidth : 9375000 Number of Priority : 8 Priority 0 : 9375000 Priority 1 : 9375000 Priority 2 : 9375000 Priority 3 : 9375000 Priority 4 : 9375000 Priority 5 : 9375000 Priority 6 : 9375000 Priority 7 : 9375000 Affinity Bit : 0x0 IGP Metric : 10 Number of Links : 1 LS age: 224 Options: (No TOS-capability, DC) LS Type: Opaque Area Link Link State ID: 1.0.0.0 Opaque Type: 1 Opaque ID: 0 Advertising Router: 4.4.4.4 LS Seq Number: 80000001 Checksum: 0xE945 Length: 132 Fragment number : 0 MPLS TE router ID : 4.4.4.4 Link connected to Broadcast network Link ID : 10.24.1.1 Interface Address : 10.24.1.2 Admin Metric : 10 Maximum bandwidth : 1250000 Maximum reservable bandwidth : 937500 Number of Priority : 8 Priority 0 : 937500 Priority 1 : 937500 Priority 2 : 937500 Priority 3 : 937500 Priority 4 : 937500 Priority 5 : 937500 Priority 6 : 937500 Priority 7 : 937500 Affinity Bit : 0x0 IGP Metric : 10 Number of Links : 1 LS age: 254 Options: (No TOS-capability, DC) LS Type: Opaque Area Link Link State ID: 1.0.0.1 Opaque Type: 1 Opaque ID: 1 Advertising Router: 2.2.2.2 LS Seq Number: 80000001 Checksum: 0xD668 Length: 124 Fragment number : 1 Link connected to Broadcast network Link ID : 10.23.1.2 Interface Address : 10.23.1.1 Admin Metric : 10 Maximum bandwidth : 12500000 Maximum reservable bandwidth : 9375000 Number of Priority : 8 Priority 0 : 9375000 Priority 1 : 9375000 Priority 2 : 9375000 Priority 3 : 9375000 Priority 4 : 9375000 Priority 5 : 9375000 Priority 6 : 9375000 Priority 7 : 9375000 Affinity Bit : 0x0 IGP Metric : 10 Number of Links : 1 LS age: 114 Options: (No TOS-capability, DC) LS Type: Opaque Area Link Link State ID: 1.0.0.1 Opaque Type: 1 Opaque ID: 1 Advertising Router: 3.3.3.3 LS Seq Number: 80000001 Checksum: 0xD663 Length: 124 Fragment number : 1 Link connected to Broadcast network Link ID : 10.23.1.2 Interface Address : 10.23.1.2 Admin Metric : 10 Maximum bandwidth : 12500000 Maximum reservable bandwidth : 9375000 Number of Priority : 8 Priority 0 : 9375000 Priority 1 : 9375000 Priority 2 : 9375000 Priority 3 : 9375000 Priority 4 : 9375000 Priority 5 : 9375000 Priority 6 : 9375000 Priority 7 : 9375000 Affinity Bit : 0x0 IGP Metric : 10 Number of Links : 1 LS age: 212 Options: (No TOS-capability, DC) LS Type: Opaque Area Link Link State ID: 1.0.0.1 Opaque Type: 1 Opaque ID: 1 Advertising Router: 4.4.4.4 LS Seq Number: 80000001 Checksum: 0xCA55 Length: 124 Fragment number : 1 Link connected to Broadcast network Link ID : 10.34.1.2 Interface Address : 10.34.1.2 Admin Metric : 10 Maximum bandwidth : 12500000 Maximum reservable bandwidth : 9375000 Number of Priority : 8 Priority 0 : 9375000 Priority 1 : 9375000 Priority 2 : 9375000 Priority 3 : 9375000 Priority 4 : 9375000 Priority 5 : 9375000 Priority 6 : 9375000 Priority 7 : 9375000 Affinity Bit : 0x0 IGP Metric : 10 Number of Links : 1 LS age: 257 Options: (No TOS-capability, DC) LS Type: Opaque Area Link Link State ID: 1.0.0.2 Opaque Type: 1 Opaque ID: 2 Advertising Router: 2.2.2.2 LS Seq Number: 80000001 Checksum: 0x6BE7 Length: 124 Fragment number : 2 Link connected to Broadcast network Link ID : 10.24.1.1 Interface Address : 10.24.1.1 Admin Metric : 10 Maximum bandwidth : 1250000 Maximum reservable bandwidth : 937500 Number of Priority : 8 Priority 0 : 937500 Priority 1 : 937500 Priority 2 : 937500 Priority 3 : 937500 Priority 4 : 937500 Priority 5 : 937500 Priority 6 : 937500 Priority 7 : 937500 Affinity Bit : 0x0 IGP Metric : 10 Number of Links : 1Note: The Link-State ID of the Opaque LSA is divided into an Opaque Type field (first 8 bits) and an Opaque ID (remaining 24 bits). The Opaque Type for MPLS TE is 1 for TE LSA. The Opaque ID is an arbitrary value used to uniquely identify TE LSAs.Link State ID has no topological significance.Just considering the bandwidth requirements, the headend router is specified with 20Mbps bandwidth requirement for the tunnel to destination 3.3.3.3 on PE4 router. When CSPF computes a path, the link between P2 and PE4 is not considered as it does not meet the requirement of 20Mbps. So, the CSPF computes a path PE1-P2-P3-PE4 to setup a TE LSP to 3.3.3.3 on PE4 router. This information is passed to RSVP.
The path calculated by CSPF for TE tunnel can be seen as below:
CSPF Calculated Path on PE1
PE1# show mpls traffic-eng topology path tunnel 10Query Parameters: Destination: 4.4.4.4 Bandwidth: 20000 Priorities: 7 (setup), 7 (hold) Affinity: 0x0 (value), 0xFFFF (mask)Query Results: Min Bandwidth Along Path: 55000 (kbps) Max Bandwidth Along Path: 75000 (kbps) Hop 0: 10.12.1.1 : affinity 00000000, bandwidth 55000 (kbps) Hop 1: 10.12.1.2 : affinity 00000000, bandwidth 75000 (kbps) Hop 2: 10.23.1.1 : affinity 00000000, bandwidth 55000 (kbps) Hop 3: 10.23.1.2 : affinity 00000000, bandwidth 75000 (kbps) Hop 4: 10.34.1.1 : affinity 00000000, bandwidth 55000 (kbps) Hop 5: 10.34.1.2 : affinity 00000000, bandwidth 75000 (kbps) Hop 6: 4.4.4.4The figure below shows a relationship between SPF and CSPF:
Consider, from Figure-1, that the MPLS network is responsible for forwarding Data and Voice traffic. Data is resistant to high delay but not to low bandwidth while Voice cares less about low bandwidth and more about high delay. MPLS TE provides the ability to consider both link bandwidth and link delay. In this case, two MPLS TE tunnels can be configured on PE1 router (namely Data Tunnel and Voice Tunnel). Voice tunnel can consider delay as a separate cost from the metric Data tunnel uses. This can be accomplished in 2 steps:
1. Using mpls traffic-eng administrative-weight <link-weight> interface configuration command, link delay can be configured.
2. The tunnel decision process can be changed on Data tunnel to use IGP metric. This can be done using tunnel mpls traffic-eng path-selection metric igp tunnel-interface configuration mode. While for Voice tunnel, the tunnel decision process can be changed to use TE metric. This can be done using tunnel mpls traffic-eng metric te command.
Tiebreakers in CSPF
In regular SPF, the result of path computation may be two equal cost multipaths (ECMP) to a destination. However, the result of CSPF is always one path to the tailend router. In case, two paths are equal, CSPF has 3 rules followed sequentially to break the tie:
a. Take the path with largest minimum available bandwidth
b. Take the path with the lowest hop-count (number of routers in the path)
c. Take one path at random.
Resource Reservation Protocol (RSVP) operation in MPLS TE
Once CSPF is completed, the path needs to be signaled across the network to establish a TE LSP and to consume resources across that path. RSVP (protocol type 46) is used to reserve resource throughout the network.
Extensions were made to RSVP to allow RSVP to carry MPLS labels and other TE specifics. RSVP tries to signal the TE tunnel along the path from headend to tailend LSR. RSVP needs to signal it to get the label information set up at each LSR. RSVP also reserves bandwidth along the path.
RSVP messages are sent by the headend router to identify resource availability along the path. There are four main messages used in implementation of MPLS TE:
1. RSVP PATH message
The RSVP PATH messages are generated by the headend router after it completes CSPF for a TE tunnel to signal the path to the network. The PATH message is sent to the next-hop LSR along the calculated path to the tunnel tailend LSR. A PATH message has following attributes (objects)-
- SESSION: It carries the Session Type (LSP_TUNNEL_IPv4 or LSP_TUNNEL_IPv6), Tunnel Destination IP address, Tunnel ID and Extended Tunnel ID (usually set to Tunnel Source IP address).
- HOP: It contains the upstream LSR's interface IP address (previous HOP - PHOP).
- TIME VALUES: It is a refresh period (in msec) used to send PATH or RESV messages. The default value is 30000 ms.
- EXPLICIT ROUTE (ERO): It defines a path an MPLS TE tunnel takes. It is a collection of sub-objects. Cisco IOS uses only IPv4 sub-objects containing IP addresses to which the router should forward this PATH message.
- LABEL REQUEST: It requests a label. It contains the Layer 3 Protocol ID (L3PID) that is carried in the label. The L3PID is always 0x0800 for IPv4. It requests the tailend router to provide a label for this IPv4 TE tunnel.
- SESSION ATTRIBUTE: It contains the setup and holding priorities of the LSP tunnel. It also contains the local protection flag (0x01 for link-protection and 0x10 for node-protection). Cisco IOS always sets SE style flag as well indicating Shared Explicit reservation style.
- SENDER TEMPLATE: It carries the Tunnel Sender IP address which is the Router-ID of the TE tunnel headend router and an LSP ID which is the tunnel's LSP ID. The LSP ID changes when tunnel's properties change like bandwidth or path.
- SENDER TSPEC: It defines the traffic characteristics of the sender's data flow. It carries the requested bandwidth for the LSP tunnel.
- ADSPEC: It describes a reservation model in which PATH messages sent downstream gather information that the receivers can use to predict end-to-end service.
- RECORD ROUTE: This is optional and must be configured. It is used to collect detailed path information and is useful for loop detection and diagnostics. Essentially, it keeps track of list of LSRs the PATH message has traversed. It may be present in RESV message.
A sample RSVP PATH message packet capture is as below:
2. RSVP RESV message
The RSVP Reservation (RESV) messages are generated by the TE tunnel tailend router and confirm the reservation request sent using PATH messages. The RSVP RESV message performs the function of label assignment for a particular LSP mapping to TE tunnel. The tailend router first generates a label for the TE tunnel and sends it upstream. This process is followed at each hop where local label mapping to TE tunnel are assigned and propagated upstream until the headend router is reached. A RESV message has following attributes (objects):
- SESSION: It carries exactly the same information as PATH message.
- HOP: It contains the downstream LSR's interface IP address (next hop - NHOP).
- TIME VALUES: It is a refresh period (in msec) used to send PATH or RESV messages. The default value is 30000 ms.
- STYLE: Although, the sender flags the reservation style in PATH message, they have no influence on the type of reservation style chosen. The receiver can choose from one different styles; each RSVP session must have a reservation style. There are 3 different reservation styles:
- Fixed Filter (FF) Style: This style creates a distinct reservation for traffic from each sender that is not shared by other senders. Since each sender has its own reservation, a unique label is assigned to each sender. This results in P2P LSP between every sender-receiver pair.
- Wildcard Filter (WF) Style: With this style, a single shared reservation is used for all senders to a session. A single multipoint-to-point (MP2P) LSP is created for all sessions to the sender. A single label value is allocated to the session.
- Shared Explicit (SE) Style: This style allows a receiver to explicitly specify the senders to allowed in a reservation. Because each sender is explicitly listed in the RESV message, different labels are assigned to different senders, creating a separate LSP for each sender.
- FLOWSPEC: It specifies the desired QoS. It also specifies the tunnel bandwidth in bytes/sec.
- FILTERSPEC: It carries the Tunnel Sender IP address which is the Router-ID of the TE tunnel headend router and an LSP ID which is the tunnel's LSP ID. The LSP ID changes when tunnel's properties change like bandwidth or path. It is exactly same as SENDER TEMPLATE object in PATH message.
- LABEL: It carries a label value that the PHOP should use for a particular tunnel.
A sample RSVP RESV message packet capture is as below:
3. RSVP error messages
Due to unavailability of requested resources, the router generates RSVP error messages and sends them to the router from which the request or reply was received. There are 2 types of RSVP error messages: PATHERR and RESVERR messages. PATHERR messages are simply sent upstream to the sender that created the error. While RESVERR messages are sent downstream. Both error messages contain the ERROR SPEC object along with other objects discussed above.
- ERROR SPEC: It contains the Error Code and Error Value which are used to decode the error types. Most common Error Code and Error Value is 00. It indicates Confirmation sent in response to receiving a Confirmation object. Another common Error Code is 24 but there are 10 different Error Values for this code. Some of the error values mean bad ERO (value 1) or unacceptable label value (value 6) or no route available towards destination (value 5), etc.
4. RSVP tear messages
RSVP has 2 types of tear messages: PATHTEAR and RESVTEAR. PATHTEAR message travels towards all receivers downstream from its point of initiation. RESVTEAR message travels towards all senders upstream from its point of initiation. These messages immediately clear the reservation states on the router. This enables the reuse of resources on the router for other requests. The teardown request may be initiated by the router as a result of state timeout or tunnel pre-emption.
Operation of LSP Tunnels
1. To create an LSP tunnel, the PE1 router creates an RSVP PATH message with session type of IPv4 LSP and inserts a LABEL REQUESTobject. This object indicates that label binding for the path is requested and also indicates the network layer protocol that is to be carried over the path. The PATH message also contains an ERO object containing the route as a list of LSRs to the tailend router. It adds the outgoing interface IP address in the RECORD ROUTE, if configured.
PATH messages from PE1 router
PE1# debug ip rsvp dump-messages path*Mar 1 00:09:59.495: RSVP: version:1 flags:0000 type:Path cksum:83FA ttl:255 reserved:0 length:228*Mar 1 00:09:59.503: SESSION type 7 length 16:*Mar 1 00:09:59.503: Destination 4.4.4.4, TunnelId 10, Source 1.1.1.1, Protocol 0, Flags 0000*Mar 1 00:09:59.507: HOP type 1 length 12:*Mar 1 00:09:59.507: Neighbor 10.12.1.1, LIH 0x03000403*Mar 1 00:09:59.511: TIME_VALUES type 1 length 8 :*Mar 1 00:09:59.511: Refresh period is 30000 msecs*Mar 1 00:09:59.511: EXPLICIT_ROUTE type 1 length 52:*Mar 1 00:09:59.511: (#1) Strict IPv4 Prefix, 8 bytes, 10.12.1.2/32*Mar 1 00:09:59.511: (#2) Strict IPv4 Prefix, 8 bytes, 10.23.1.1/32*Mar 1 00:09:59.511: (#3) Strict IPv4 Prefix, 8 bytes, 10.23.1.2/32*Mar 1 00:09:59.511: (#4) Strict IPv4 Prefix, 8 bytes, 10.34.1.1/32*Mar 1 00:09:59.511: (#5) Strict IPv4 Prefix, 8 bytes, 10.34.1.2/32*Mar 1 00:09:59.511: (#6) Strict IPv4 Prefix, 8 bytes, 4.4.4.4/32*Mar 1 00:09:59.511: LABEL_REQUEST type 1 length 8 :*Mar 1 00:09:59.511: Layer 3 protocol ID: 2048*Mar 1 00:09:59.511: SESSION_ATTRIBUTE type 7 length 16:*Mar 1 00:09:59.511: Session name: PE1_t10*Mar 1 00:09:59.511: Setup priority: 7, reservation priority: 7*Mar 1 00:09:59.511: Status: May-Reroute*Mar 1 00:09:59.511: SENDER_TEMPLATE type 7 length 12:*Mar 1 00:09:59.511: Source 1.1.1.1, tunnel_id 5*Mar 1 00:09:59.511: SENDER_TSPEC type 2 length 36:*Mar 1 00:09:59.511: version=0, length in words=7*Mar 1 00:09:59.511: Token bucket fragment (service_id=1, length=6 words*Mar 1 00:09:59.511: parameter id=127, flags=0, parameter length=5*Mar 1 00:09:59.511: average rate=2500000 bytes/sec, burst depth=1000 bytes*Mar 1 00:09:59.511: peak rate =2500000 bytes/sec*Mar 1 00:09:59.511: min unit=0 bytes, max pkt size=2147483647 bytes*Mar 1 00:09:59.511: ADSPEC type 2 length 48:*Mar 1 00:09:59.511: version=0 length in words=10*Mar 1 00:09:59.511: General Parameters break bit=0 service length=8*Mar 1 00:09:59.511: IS Hops:1*Mar 1 00:09:59.511: Minimum Path Bandwidth (bytes/sec):12500000*Mar 1 00:09:59.511: Path Latency (microseconds):0*Mar 1 00:09:59.511: Path MTU:1500*Mar 1 00:09:59.511: Controlled Load Service break bit=0 service length=0*Mar 1 00:09:59.511: RECORD_ROUTE type 1 length 12:*Mar 1 00:09:59.515: (#1) IPv4 address, 10.12.1.1/322. As can be seen from above output, the PATH message is sent to the next-hop (downstream) router - P2. The P2 router ensures the message's format and checks the amount of bandwidth the PATH message is requesting. This is called admission control. If the admission control is successful and the PATH message reserves the requested bandwidth, P2 router generates a new PATH message and sends it to the next-hop in the ERO. P2 router keeps track of the interface it received the PATH message on.
3. This process continues until the PATH messages reach the MPLS TE tailend router - PE4. It performs admission control on the PATH message, like other downstream routers.
4. PE4 router realizes that it is the destination of the PATH message, it replies with an RESV message. PE4 router begins the label allocation process upon generation of RESV message. PE4 assigns an explicit-null label by default (label value 0) to the LSP tunnel that the upstream router (P3) can use to send packets along the TE LSP to PE4 router. This label is placed in the LABEL object of the RESV message. The RESV message is sent out to the upstream routers. The RESV message follows the same path as ERO of the PATH message, in reverse-order. The RECORD ROUTE object is re-initialized and adds the outgoing interface IP address of PE4 router.
However, the explicit-null label is interpreted as implicit-null label (label value 3) on, both, tailend (PE4) and penultimate-hop (P3) routers. To change this default behavior, use mpls traffic-eng signalling advertise implicit-null global configuration command on tailend router.
RESV message on PE4 router
PE4# debug ip rsvp dump-messages resv*Mar 1 00:09:50.619: RSVP: version:1 flags:0000 type:Resv cksum:5F91 ttl:255 reserved:0 length:120*Mar 1 00:09:50.627: SESSION type 7 length 16:*Mar 1 00:09:50.627: Destination 4.4.4.4, TunnelId 10, Source 1.1.1.1, Protocol 0, Flags 0000*Mar 1 00:09:50.631: HOP type 1 length 12:*Mar 1 00:09:50.631: Neighbor 10.34.1.2, LIH 0x01000402*Mar 1 00:09:50.635: TIME_VALUES type 1 length 8 :*Mar 1 00:09:50.635: Refresh period is 30000 msecs*Mar 1 00:09:50.635: STYLE type 1 length 8 :*Mar 1 00:09:50.639: Shared-Explicit (SE)*Mar 1 00:09:50.639: FLOWSPEC type 2 length 36:*Mar 1 00:09:50.643: version = 0 length in words = 7*Mar 1 00:09:50.643: service id = 5, service length = 6*Mar 1 00:09:50.643: tspec parameter id = 127, flags = 0, length = 5*Mar 1 00:09:50.643: average rate = 2500000 bytes/sec, burst depth = 1000 bytes*Mar 1 00:09:50.643: peak rate = 2500000 bytes/sec*Mar 1 00:09:50.643: min unit = 0 bytes, max pkt size = 0 bytes*Mar 1 00:09:50.643: FILTER_SPEC type 7 length 12:*Mar 1 00:09:50.643: Source 1.1.1.1, tunnel_id 5*Mar 1 00:09:50.643: LABEL type 1 length 8 :*Mar 1 00:09:50.643: Labels: 0*Mar 1 00:09:50.643: RECORD_ROUTE type 1 length 12:*Mar 1 00:09:50.647: (#1) IPv4 address, 10.34.1.2/325. P3 router receives the RESV message containing the label for the TE tunnel. Since, P3 is not the headend router, it allocates a new label and places that label in the corresponding LABEL object of the RESV message which it sends upstream to the P2 router.
6. This process continues until the RESV message reaches the headend router - PE1. At this point, a uni-directional LSP is established and the MPLS TE tunnel state changes to UP.
Notice in below output, the path weight is 30 although the shortest path to 4.4.4.4 is 21 according to the routing table.
"show mpls traffic-eng tunnels tunnel 10" on PE1 router
PE1# show mpls traffic-eng tunnelsName: PE1_t10 (Tunnel10) Destination: 4.4.4.4 Status: Admin: up Oper: up Path: valid Signalling: connected path option 2, type dynamic (Basis for Setup, path weight 30) Config Parameters: Bandwidth: 20000 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF Metric Type: TE (default) AutoRoute: disabled LockDown: disabled Loadshare: 20000 bw-based auto-bw: disabled InLabel : - OutLabel : FastEthernet0/0, 16 RSVP Signalling Info: Src 1.1.1.1, Dst 4.4.4.4, Tun_Id 10, Tun_Instance 5 RSVP Path Info: My Address: 10.12.1.1 Explicit Route: 10.12.1.2 10.23.1.1 10.23.1.2 10.34.1.1 10.34.1.2 4.4.4.4 Record Route: Tspec: ave rate=20000 kbits, burst=1000 bytes, peak rate=20000 kbits RSVP Resv Info: Record Route: 10.12.1.2 10.23.1.2 10.34.1.2 Fspec: ave rate=20000 kbits, burst=1000 bytes, peak rate=20000 kbits History: Tunnel: Time since created: 4 minutes, 56 seconds Time since path change: 4 minutes, 5 seconds Current LSP: Uptime: 4 minutes, 5 seconds Prior LSP: ID: path option 2 [4] Removal Trigger: router ID changedNote that until now only a uni-directional LSP is setup. A similar process needs to follow from PE4 to PE1 router. Also, by default, no traffic is forwarded onto the TE tunnels. Special mechanisms are in place to forward traffic onto TE tunnels like-
- Using Static Route
- Using Policy-based routing
- Autoroute Announce - includes TE tunnel only on the headend router. Topology database is not affected on other routers in the network.
- Forwarding Adjacency - A bi-directional LSP is setup and adjacency is formed over TE tunnel.