The Complete IS-IS Routing Protocol- P11

The Complete IS-IS Routing Protocol- P11:IS-IS has always been my favourite Interior Gateway Protocol. Its elegant simplicity, itswell-structured data formats, its flexibility and easy extensibility are all appealing – IS-ISepitomizes link-state routing. Whether for this reason or others, IS-IS is the IGP of choicein some of the world’s largest networks. Thus, if one is at all interested in routing, it is wellworth the time and effort to learn IS-IS.
Nội dung trích xuất từ tài liệu:
The Complete IS-IS Routing Protocol- P11 Analysis of IS-IS Extensibility 289 Consider extending OSPF by adding a new, hypothetical LSA type. The number couldbe anything not currently used or defined – LSA type 53, for example. Now, what if a routerrunning older OSPF software does not recognize the new, hypothetical LSA type 53?Should the router flood the LSA further across the network or should the router simplydiscard the update? To explain what OSPF does with extensions that the router does notunderstand, it is necessary to borrow a term from BGP terminology. The term is calledtransitivity. Certain BGP attributes are transitive as the attributes flow from BGP routerto BGP router. But the term can be applied to protocols other than BGP. Transitivity meansthat if a router cannot interpret a given message, the router will flood the message furtheracross the network anyway. Non-transitive behaviour means that a router does not for-ward an LSA that the router cannot interpret in terms of the LSA payload. OSPF is a strictly non-transitive protocol. OSPF routers will not flood LSA types thatthe routers themselves do not understand. The ramifications of that are a bit depressing.Non-transitive OSPF behaviour means that a new feature cannot be rolled out unless allOSPF routers in a given link-state domain are updated with the new software. Given thefact that the role of the IGP is changing from the narrow role of distributing NLRI infor-mation towards a wider role with regard to a topology discovery function, it might benecessary for new OSPF features of increasing interest to use the flooding sub-system ofOSPF for distributing network-wide information. And this information must be spreadall over the network, information that not each OSPF speaker must necessarily see.I won’t flood because I do not understand behaviour is not migration-friendly, and there-fore causes a lot of headache for preparing migrations. Fortunately, the issue of OSPF transitivity has been addressed. RFC 2370, The OSPFOpaque LSA Option, describes an enhancement to base OSPF. A set of opaque LSAs isdefined in this RFC that correct the problem with OSPF being non-transitive. Instead ofusing the BGP terminology of transitive, OSPF uses the concept of an LSA that is visible(and understandable) to some OSPF routes and yet not visible to all OSPF routers. Thenew LSAs are not transparent to all OSPF routers, but opaque to some routers, routers thatmust still pass on this LSA type through flooding nonetheless. With RFC 2370, type 9, 10and 11 LSAs now become the universal transport vehicle for routing and topology-relateddata that need to get distributed by the flooding sub-system of OSPF. With those extensionsin place, arbitrary data, including reachability information from other address families suchas IPv6, could theoretically be distributed about an OSPF routing domain. A full discus-sion of opaque LSA types in OSPF is not needed in a book on IS-IS. It is enough to notethe presence of opaque LSA types in OSPF for the purposes of extensibility.11.3 Analysis of IS-IS ExtensibilityIS-IS uses TLVs to encode Hellos, NLRIs, as well as miscellaneous other informationneeded for the IS-IS routing protocol to function properly. Virtually all these message elem-ents use Type-Length-Value (TLV) encoding to get their data across to other IS-IS routers.11.3.1 TLV FormatFigure 11.4 shows the basic elements for TLV encoding.290 11. TLVs and Sub-TLVs The first element of the TLV structure is the Type field. The size of the Type field is8-bits wide, which gives room for 256 different codes. In fact, a lot of documents call thisthe Code-Length-Value (CLV) structure instead of TLV. But the TLV terminology ismuch more common and is therefore used here. Type number 0 is reserved for furtherexpansion of the protocol. The Type field is a well-known field that should be understoodby all routers in a given link-state domain ( IS-IS level). Next comes the Length fieldthat indicates the length of the payload data, which is stored in the Value field. Why is theLength field needed if the Type code establishes the format of the information in theValue field? As long as all Type codes are well known, it would seem that the router hasenough information to decipher the value that the Type contains. But it is not that simple. Let’s invent an example demonstrating the need for a Length field. Suppose we want toencode an IPv4 prefix. What we need is 8 bytes of space in the TLV. Four bytes are for theprefix itself and four bytes are for the Netmask. Next, let’s give this Value field the hypo-thetical Type number, say 47. Because Type Code #47 is well known by all routers runningthe IS-IS protocol, one could suppose that there could be a rule in the IS-ISprotocol that Code 47 always means an implicit length of 8 bytes for the Value field.However, what happens if a router running older software does not recognize our newhypothetical Type Code 47 Message? How is the Length made know to IS-IS routers thatdo not know what a Type Code 47 is? Even worse, the section of IS-IS code that parses allthe incoming routing messages does not know when other messages-codes beyond theType Code 47 begin, because the code has no indication when the unknown Type Code 47message ends. Figure 11.5 illustrates the dilemma of the receiving router’s message parser. So an explicit Length field is always needed for TLVs. The Length field is again 8-bitswide, which leaves room for Values up to 255 bytes. Although this may sound like a small Bytes Type 1–255 1 Length 1–255 1 Value 1–255 ...