Section 8.3. Fragmentation
8.3. FragmentationSections 7.3.2 and 7.4.2 discuss the issue of large LSAs and LSPs and the effect they have on the scalability of an area in terms of bandwidth usage during flooding and memory usage as they are stored in the link state databases. Another issue with the scaling of LSAs and LSPs concerns the ability of link MTUs to accommodate them. That issue is the question of how to handle an LSA or LSP that is larger than the MTU of a link it is supposed to traverse. When there is a low-MTU link along the flooding path, an OSPF or IS-IS implementation can do one of three things:
Fragmentation is a common and well-understood part of IP networks, so using fragmentation makes sense in situations where an OSPF or IS-IS protocol data unit is larger than the MTU of a link it must traverse. Fragmentation is less of an issue for OSPF than for IS-IS for two reasons. First, because a single originator can generate many different LSAs of several different types to convey information, no one LSA is likely to grow extremely large. Types 3, 4, 5, and 7 LSAs carry only a single prefix, so they are always small. Type 2 LSAs might grow large, but it is rare to find a pseudonode with a great number of neighbors. Of all the LSA types, only type 1 is likely to grow large and even then only if the router has a large number of neighbors or stub links (an access router is a good example of a router with a very large number of stub links). The maximum size of an LSA is 64KB. Given 24 bytes of fixed fields and 12 bytes to represent each link, a type 1 LSA can advertise a maximum of 5331 links. In any reasonable network design, this LSA capacity should more than suffice. The second reason that fragmentation is less of an issue for OSPF is that the LSAs, whatever their size, are encapsulated in Update messages for transmission to neighbors. The Update message is in turn encapsulated in an IP packet, and IP packet headers are formatted to accommodate fragmentation. In other words, the standard IP fragmentation procedures serve OSPF just fine. IS-IS is a little more problematic: Unlike OSPF's many LSAs, IS-IS generates one LSP per level, per router. As a result, this one LSP can become quite large. And because the LSP is not an IP packet, it cannot take advantage of IP's fragmentation mechanism. Therefore, IS-IS must have its own fragmentation mechanism. Prerequisite to IS-IS fragmentation, IS-IS must be able to assume that every link on which it floods LSPs can handle PDUs up to at least a certain size. That is, there must be a minimum guaranteed MTU such that IS-IS knows it can send PDUs up to that size without them exceeding the link MTU. Recall from the discussion of IS-IS Hello protocol basics in Section 4.2.2 that when Hellos are initially exchanged between IS-IS neighbors the Padding TLV is used to pad the Hello up to the ReceiveLSPBufferSize of 1492 bytes.[11] If a neighboring interface has an MTU lower than 1492 bytes, it cannot receive the padded Hellos and drops them, so that an adjacency is not formed. Therefore, if an adjacency exists with a neighbor, an IS-IS router knows that so long as its PDUs do not exceed 1492 bytes they will not exceed the MTU of any of its links.
If the number of TLVs a router originates would result in an LSP larger than 1492 bytes IS-IS breaks the LSP into fragments, none of which are larger than 1492 bytes (including the header). The 8-bit LSP Number field in the LSP header (Figure 8.40) is used to track these "LSP fragments." The first LSP, whether it is fragmented or not, has an LSP number of 0x00. Subsequent fragments are numbered 0x01, 0x02, and so on. Figure 8.41 shows a database display with 17 fragments of the same LSP. Figure 8.40. The LSP Number in the LSP header is used for tracking a fragmented LSP.
A note about semantics is in order here. If you deal mostly with IETF terminology, using the term fragments when discussing a multipart LSP such as the one shown in Figure 8.41 might make the most sense to you. However, you might also say that the router RTR1-SFO has originated 17 LSPs. That is, instead of saying a router fragments its LSPs when they are large, you can say that a router produces multiple LSPs when necessary, and that the LSP number is used to differentiate the multiple LSPs from the same source. In fact, the language of ISO 10589 is oriented to multiple LSPs rather than fragments. Looking at the entries in Figure 8.41, you can see that each of the fragments have their own sequence numbers, checksums, and remaining lifetimes. And they are stored in the database as separate LSPs. But although they are flooded and stored separately, during the SPF calculations all the fragments from a single originating router are considered as a single LSP. So, you can consider these entities as fragments of the same LSP or as multiple LSPs originated from the same router. Either term is acceptable; use the one that makes more sense to you. Also note that IS-IS does not do any sort of summation or other checking of the LSP numbers to ensure that all fragments are in the database; if there is a gap in the LSP number sequence, the SPF calculation still takes place. The one exception to this is LSP number 0. If that first fragment is missing, the other fragments are discarded. The reason for this is that only LSP number 0 contains information that is vital to the correct inclusion of the originating node in the SPF calculation, such as the ATT bit and the Overload bit (discussed in the next section). Yet another scaling issue with IS-IS fragmentation has to do with the size of the LSP Number field. Because it is 8 bits, a single originator can generate a maximum of 256 fragments. Considering that every LSP can carry up to 1470 bytes of TLV space (after the 8 byte IS-IS header and a 19 byte LSP header, as discussed in Section 7.4.2), 256 fragments constitutes 256 * 1470 = 376,320 bytes of payload space for TLVs. If every TLV is 12 bytes long (a conservative assumptionmany TLVs are much shorter), 256 LSP fragments can carry over 31,000 TLVs. This would seem to be more than sufficient for an intelligent network design. Nevertheless, the 256-fragment maximum has been the cause for some concern that IS-IS might not scale into the future, given the evolution of large-scale networks. Among the contributing factors to larger and larger LSPs are:
Whether the 256-fragment limitation turns out to be imagined or real, an extension now permits IS-IS to exceed that limit.[12] Looking once more at the fragments in Figure 8.41, you can see that the identical LSP ID identifies the fragments as belonging to the same originator; the LSP number differentiates the fragments from one another. And of course, the LSP ID is based on the system ID assigned to the originator. So, overcoming the 256fragment limitation becomes a simple matter of assigning more than one SysID to the same router. This additional SysID is then viewed as identifying a virtual system attached to the originating router. For every additional SysID given to it, an originator can generate an additional 256 LSP fragments.
The SPF calculation ordinarily would view the virtual system as a separate node from the originating system. To circumvent this potential problem, the virtual system is instead viewed as leaf node from the originator and is calculated as a cost of 0 from the originator. In this, the concept is similar to that of a pseudonode. The additional SysIDs for the virtual systems are advertised in type 24 TLVs (Figure 8.42), called the IS Alias ID TLV. This TLV must always be included, if it exists, in fragment 0 of the originator's LSP, and notifies other routers that the specified additional SysIDs are a part of the originator's LSPs. Figure 8.42. Type 24 TLVs enable the use of additional SysIDs to overcome the IS-IS 256-fragment limitation.
|
Attributes RTR1-SFO.00-00 0x4298 0x8144 47193 
EAN: 2147483647
Pages: 111