How Information Is Distributed

You now have a good understanding of what information is flooded, and when. You might not understand exactly how that information is used, but that's covered in Chapter 4. This section covers the nuts and bolts: How do you configure the IGP to flood? What do the packet formats look like? How are MPLS Traffic Engineering attributes added to the IGP?

MPLS Traffic Engineering in OSPF

You need to enter only two commands to enable flooding of MPLS Traffic Engineering info in OSPF, as shown in Example 3-13.

Example 3-13 Enabling MPLS TE in the OSPF Process

router ospf 1

  mpls traffic-eng router-id Loopback0

  mpls traffic-eng area 0

mpls traffic-eng router-id Loopback0 sets the TE RID. This can be a different value than the OSPF RID, but it shouldn't be. See the discussion of loopback interfaces near the beginning of this chapter.

mpls traffic-eng area 0 configures the area in which traffic engineering is enabled. Generally, MPLS Traffic Engineering is enabled in only a single area. This does not have to be Area 0, but it almost always is. This single-area restriction can be lifted; see Chapter 9 and the "Interarea Tunnels" section of Chapter 4 for details.

One additional command might prove useful in OSPF. If you have a topology such as that shown in Figure 3-7, you might have a virtual link between ABR1 and ABR2.

With a virtual link, the link between ABR1 and ABR2 is configured to be in Area 1, but the virtual link means that this link can be used in Area 0 to route across. MPLS TE doesn't understand virtual links, so in order to advertise the virtual link into Area 0, you need to use this command:

router ospf 1

 mpls traffic-eng interface interface-name area area

interface-name is the name of the interface the virtual link is on, and area is the area you want to advertise that link into. area should always be 0, unless you absolutely, positively, without a doubt know what you're doing.

That's it. If you add the first two lines shown in Example 3-13 to your IGP configuration and configure a basic TE tunnel as described in the earlier section "MPLS Traffic Engineering Configuration," TE tunnels start to come up. You won't actually route any traffic across them yet, but they'll come up.

In OSPF, the relevant data is encoded in an area-local opaque LSA (LSA Type 10). RFC 2370 defines opaque LSAs. The data inside these LSAs is defined in draft-katz-yeung-ospf-traffic.

Inside the Type 10 LSAs, the OSPF TE extensions define several TLV (Type/Length/Value) triplets. Each TLV is encoded as shown in Figure 3-8.

Two TLV types are defined:

• Type 1— The Router Address TLV. The Router Address TLV is 32 bits long and contains the configured MPLS Traffic Engineering router ID (see Chapter 4).

• Type 2— The Link TLV. The Link TLV is repeated once for each link the router describes. The Link TLV is composed of up to nine different sub-TLVs, as documented in Table 3-3. The terms used here correspond to the Cisco terminology; the names given to these sub-TLVs in the draft definition are sometimes different.

Table 3-3. Sub-TLVs

Sub-TLV Name	Sub- TLV ID	Size	Definition	Interface Configuration
Link type	1	1 byte	1 = point-to-point, 2 = multiaccess (for example, Ethernet)	N/A
Link ID	2	4 bytes	On point-to-point links, the neighbor's OSPF RID On multiaccess links, the designated router's (DR's) interface address	N/A
Local interface IP address	3	4 bytes	IP address of the advertising router on the link, or set to the advertiser's TE RID if unnumbered	ip address address mask
Remote interface address	4	4 bytes	Interface address of the neighbor on the other end of this link, or the DR interface address if a multipoint interface	N/A
Traffic engineering metric	5	4 bytes	The link's OSPF cost, or a cost assigned by the TE code	ip ospf cost or mpls traffic-eng administrative-weight
Maximum link bandwidth	6	4 bytes	Maximum physical bandwidth on the interface, as seen in show interface and optionally set with the bandwidth command	bandwidth x
Maximum reservable bandwidth	7	4 bytes	Amount of bandwidth that can be reserved on the link	ip rsvp bandwidth x
Unreserved bandwidth (per priority level)	8	32 bytes	For each priority level, the difference between the maximum reservable bandwidth and the reserved bandwidth per priority level	N/A
Attribute flags	9	4 bytes	32-bit bitmask that puts the link in one or more administrative groups	mpls traffic-eng attribute-flags

MPLS Traffic Engineering Flooding in IS-IS

IS-IS floods exactly the same information as OSPF; however, it encodes the data a little differently. The Internet draft draft-ietf-isis-traffic was put forth not only to add MPLS TE information to IS-IS, but also to

• Expand the link metrics from 6 bits to 24 and the total path metric from 1023 to just over 4 billion

• Change some internal details of metric encoding

• Advertise a 32-bit router ID

These changes were made to make IS-IS more useful in large networks, which might contain many different types of links.

Expanding the link metrics also lets IS-IS advertise traffic engineering information. The other two modifications to IS-IS, changing the metric encoding and advertising a router ID, are not covered here; see the draft (or, eventually, RFC) for more details.

In order to use IS-IS traffic engineering, you first need to enable support for these new TLVs. These TLVs are collectively referred to as wide metrics; enabling them is called wide metric support.

The IS-IS configuration, shown in Example 3-14, is almost as simple as the OSPF configuration.

Example 3-14 Enabling Wide Metric Support in IS-IS

router isis name

  mpls traffic-eng router-id Loopback0

  mpls traffic-eng {level-1 | level-2}

  metric-style {narrow | transition | wide}

Like OSPF, IS-IS traffic engineering is generally enabled at only a single level, either Level 1 or Level 2. This restriction can be lifted, however, as discussed in the "Interarea Tunnels" section of Chapter 4.

Note the addition of the metric-style command.

When new IS-IS TLVs were defined to carry traffic engineering information, a TLV was also defined to carry larger metrics for IP links, whether those links were involved in MPLS Traffic Engineering or not. This additional TLV (TLV Type 135) increased the per-link metric range from 0 to 63 (a 6-bit link metric) to 0 to 1,677,214 (a 24-bit link metric). Type 135 TLVs are often called IP-Extended TLVs.

Although IP-Extended TLVs have nothing to do with MPLS Traffic Engineering per se, MPLS Traffic Engineering enhancements and IP-Extended TLVs go hand in hand. Before you can do MPLS Traffic Engineering, support for wide metrics must be enabled.

The problem is that many networks run code that does not understand the new TLVs. Advertising IP-Extended TLVs to routers that don't understand them can result in all sorts of routing problems. Routers that can understand both old- and new-style TLVs need to be able to gracefully transition from one style to the other—hence the metric-style command. You can use five different options with the metric-style command, as defined in Table 3-4.

Table 3-4. metric-style Command Options

Command	Description
metric-style narrow	Originates and accepts old-style TLVs only. Default behavior on code that understands old- and new-style TLVs.
metric-style narrow transition	Originates old-style TLVs and accepts both old- and new-style TLVs.
metric-style transition	Originates and accepts both old- and new-style TLVs.
metric-style wide	Originates and accepts only new-style TLVs. The end goal of a move from old- to new-style metrics is to have all routers configured with metric-style wide.
metric-style wide transition	Originates only new-style metrics and accepts both old- and new-style metrics.

There are a few different ways to migrate from old to new, taking into consideration how much work you want to do and how perilous it might be to advertise both old- and new-style TLVs at the same time.

In order for MPLS Traffic Engineering to work, all routers that are participating in MPLS Traffic Engineering must have a metric style of transition, wide, or wide transition so that they can receive and originate wide metrics and MPLS Traffic Engineering TLVs.

Appendix B, "CCO and Other References," refers to a paper on CCO called "MPLS Traffic Engineering and Enhancements." It discusses migration from narrow to wide metrics in more detail.

The first point, expanding link metrics, is covered in this chapter because it is an integral part of MPLS Traffic Engineering. The other two points are not discussed here; see the drafts for full details.

IS-IS encodes MPLS Traffic Engineering information in an extended IS reachability TLV, TLV Type 22. Figure 3-9 shows the format of this TLV.

The field for systemID and pseudonode number is 7 bytes (56 bits) long. The default link metric is 3 bytes long. The sub-TLV length field is also 1 byte long. It indicates the length of the total number of sub-TLVs.

Table 3-5 describes the seven different sub-TLVs that carry MPLS Traffic Engineering link information.

Table 3-5. Sub-TLVs That Carry MPLS Traffic Engineering Link Information

Sub-TLV Name	Sub-TLV ID	Size	Definition	Interface Configuration
Attribute flags	3	4 bytes	32-bit bitmask that puts the link in one or more administrative groups	mpls traffic-eng attribute-flags
IPv4 interface address	6	4 bytes	Interface mask is in the Type-22 TLV	ip address network mask
IPv4 neighbor address	8	4 bytes	IP address of a neighbor on a p2p link; 0.0.0.0 if describing a broadcast link	N/A
Maximum link bandwidth	9	4 bytes	Maximum physical bandwidth on the interface, as seen in sh int and optionally set with the bandwidth command	bandwidth x
Maximum reservable bandwidth	10	4 bytes	Amount of bandwidth that can be reserved on the link	ip rsvp bandwidth x
Unreserved bandwidth (per priority level)	11	32 bytes	For each priority level, the difference between the maximum reservable bandwidth and the reserved bandwidth per priority	N/A
Traffic engineering metric	18	3 bytes	The IS-IS cost of the link, or a cost assigned by the TE code	isis metric or mpls traffic-eng administrative-weight

If you compare IS-IS to OSPF, you see that although the packet formats are different, both protocols advertise exactly the same information.