idnits 2.17.1 draft-ietf-isis-auto-encap-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document is more than 15 pages and seems to lack a Table of Contents. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([4], [5], [12], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 249: '...tic encapsulation/unencapsulation MUST...' RFC 2119 keyword, line 251: '...ber 0. This TLV MUST be included in b...' RFC 2119 keyword, line 266: '... type equal to 1 MUST contain three by...' RFC 2119 keyword, line 283: '...capsulation-mode SHALL be 47 (decimal)...' RFC 2119 keyword, line 287: '... Inner-Protocol SHALL be the NLPID of...' (53 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 988 has weird spacing: '... to the neigh...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If a dual automatic encapsulating IS originates an ICMP redirect request, the request MUST not redirect IPv4 packets from an IPv4 capable IS to a non-IPv4 capable IS, or redirect IPv6 packets from an IPv6 capable IS to a non-IPv6 capable IS. Likewise if a dual automatic encapsulating router originates ISO/IEC 9542[5] Redirect PDUs, the redirect MUST not redirect CLNS packets from an OSI capable IS to a non-OSI capable IS. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 2002) is 7895 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 1105 looks like a reference -- Missing reference section? '12' on line 871 looks like a reference -- Missing reference section? '4' on line 853 looks like a reference -- Missing reference section? '5' on line 855 looks like a reference -- Missing reference section? '2' on line 849 looks like a reference -- Missing reference section? '3' on line 851 looks like a reference -- Missing reference section? '8' on line 861 looks like a reference -- Missing reference section? '10' on line 866 looks like a reference -- Missing reference section? '11' on line 869 looks like a reference -- Missing reference section? '6' on line 857 looks like a reference -- Missing reference section? '7' on line 859 looks like a reference -- Missing reference section? '9' on line 864 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force P. Christian, 2 INTERNET-DRAFT Christian Tena LTD, 3 Category: Informational September 2002 4 Expires: March 2003 6 IS-IS Automatic Encapsulation 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC 2026. 14 The IETF is advised of potential intellectual property rights in 15 regard to some or all of the specification contained in this 16 document. For more information consult the online list for notices 17 and/or updates. 19 Internet Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its Areas, and its Working Groups. Note that 21 other groups may also distribute working documents as Internet 22 Drafts. 24 Internet Drafts are draft documents valid for a maximum of six 25 months. Internet Drafts may be updated, replaced, or obsoleted by 26 other documents at any time. It is not appropriate to use Internet 27 Drafts as reference material or to cite them other than as a 28 "working draft" or "work in progress". 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This memo provides information for the Internet community. This memo 37 does not specify an Internet standard of any kind. 39 Distribution of this draft is unlimited. 41 Christian Expires March 2003 1 42 IS-IS Automatic Encapsulation 44 Abstract 46 RFC 1195 [1] documents a dual routing protocol that can be used to 47 route both CLNP and IPv4, that is Integrated IS-IS. Integrated IS- 48 IS can now also be used to route IPv6 [12]. 50 RFC 1195 [1] places certain topological restrictions on networks 51 that are routed using Integrated IS-IS, specifically that every 52 Intermediate System in a level-1 area must be able to forward all 53 network layer protocols that are present in that area, and that 54 every level-2 Intermediate System must be able to forward all 55 network layer protocols present in the routing domain. 57 The mechanism described in this document enables an Intermediate 58 System or a group of Intermediate Systems that do not support a 59 particular network layer protocol to be used in a level-1 area or 60 level-2 subdomain where that network layer protocol is present. 62 Specifically the mechanism provides automatic encapsulation and 63 unencapsulation so that a packet or PDU may pass through an 64 Intermediate System that would not normally be able to forward that 65 type of packet. 67 1.History 69 The automatic encapsulation mechanism was originally presented to 70 Study Group 15 of the ITU-T as part of a push by the ITU-T to 71 migrate SONET / SDH DCN networks from CLNP to IP. The scheme was 72 presented as an "autotunnelling scheme" that used the existing IS-IS 73 routing protocol that was present in all standards compliant SONET 74 or SDH multiplexers, so that IP traffic could be passed through 75 existing CLNP capable multiplexers without needing to upgrade them. 77 In May 2002 the ITU-T Draft Recommendation G.7712 version 1.1 and 78 1.2 were liaised to the IETF IS-IS Working Group. The liaison 79 statement and these version of G.7712 may be viewed from 81 ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport 82 /COMMUNICATIONS/isis/index.html 84 The automatic encapsulation mechanism was then documented as an 85 IETF document in draft-ietf-isis-proprietary-tlv-00.txt. This 86 document included a modified PseudoNode election process that 87 was intended to improve interoperability and ease topologic 88 restrictions compared with G.7712. 90 The modification turned out to be impossible to implement, as it 91 would have required an automatically encapsulating IS to create 92 two or more pseudonodes in certain circumstances (one for each 93 supported network-layer protocol). Multiple pseudonodes would have 94 required multiple IDs in LAN Hello PDUs, which is not possible. 96 Christian Expires March 2003 2 97 IS-IS Automatic Encapsulation 99 draft-ietf-isis-proprietary-tlv-01.txt therefore reverted the 100 pseudonode election process back to that used in G.7712. 102 This version converges further towards G.7712 as it only documents 103 GRE encapsulation. G.7712 requires SONET / SDH multiplexers to 104 support GRE for encapsulation of CLNP, IPv4 or IPv6 PDUs. This 105 modification is designed to improve interoperability between 106 vendors. 108 Shortest paths are calculated by ISs in the domain without 109 considering whether a complete path for any particular network-layer 110 protocol exists or not, nor whether encapsulation and 111 unencapsulation is available or not. Thus if some automatically 112 encapsulating ISs support only GRE encapsulation, whilst others 113 support only some other encapsulation, then dynamic tunnels cannot 114 be built between the two. The result is paths that cannot forward 115 traffic which causes blackholes, or very complex topological 116 restrictions to avoid them. 118 Given that GRE is the only standardised encapsulation mechanism that 119 supports CLNP (see RFC 2784[4] and RC 3147[5]) it makes sense to use 120 it here. As a result implementations that conform to this draft are 121 guaranteed to interwork with others (by virtue of a common 122 encapsulation) and with ITU-T G.7712 implementations (by virture of 123 using GRE). 125 2.Introduction 127 RFC 1195 [1] documents a dual routing protocol that can be used to 128 route both CLNP and IPv4, that is Integrated IS-IS. Integrated IS-IS 129 can now also be used to route IPv6 [12]. 131 RFC 1195 [1] also foresaw the possibility of an automatic 132 encapsulation feature. Automatic encapsulation is stated as for 133 "for further study" in section 3.8. The automatic encapsulation 134 scheme detailed here may be considered a continuation of section 3.8 135 of RFC 1195 [1]. 137 Integrated IS-IS ISs (Intermediate Systems) can calculate routes to 138 CLNS, IPv4 and IPv6 destinations using a single SPF calculation. 139 This is achieved by treating OSI End System, IPv4 and IPv6 addresses 140 in a similar way, but it does rely on an assumption which forces 141 topological restrictions onto the network. 143 Integrated IS-IS views a level-1 area or level-2 subdomain as a 144 collection of connected ISs, without considering which ISs can 145 actually forward which network-layer protocols. It simply assumes 146 that all ISs that it can see, can forward all packet types. For 147 Integrated IS-IS to be able to pick different routes for different 148 network-layer protocols would imply a separate SPF calculation for 149 each network layer protocol. It would then arguably no longer be an 150 integrated routing protocol. 152 Christian Expires March 2003 3 153 IS-IS Automatic Encapsulation 155 Specifically page 26 of RFC 1195 [1] states:- 157 "The Dijkstra computation does not take into consideration whether 158 a router is IP-only, OSI-only, or dual. The topological 159 restrictions specified in section 1.4 ensure that IP packets will 160 only be sent via IP-capable routers, and OSI packets will only be 161 sent via OSI-capable routers." 163 It is important that all ISs in a network calculate routes in such 164 a way that they all arrive at the same shortest path. If some ISs 165 calculate a different shortest path to others then routing loops 166 and blackholes can occur. Therefore in a multiprotocol environment 167 having ISs that consider forwarding capabilities when calculating 168 the shortest path, mixed with ISs that do not could result in 169 routing loops and packet loss. 171 Consequently, RFC 1195 states that if both IPv4 and CLNP are to be 172 forwarded anywhere in a level-1 area or level-2 subdomain, then, all 173 of the ISs in that level-1 area or level-2 subdomain must be capable 174 of forwarding both IPv4 and CLNP. The same logic applies if it is 175 required to have both IPv4 and IPv6 present in a level-1 area or 176 level-2 subdomain. 178 This topological rule can already be broken with extreme care. If it 179 can be guaranteed that a certain part of an IS-IS network will never 180 receive a certain type of packet, then that network layer protocol 181 need not be supported. 183 However, failure to observe these topological restrictions can 184 result in blackholes forming, and packet loss. Consider the 185 following (illegal) example:- 187 +--------+ +-------+ +--------+ 188 IPv6 host#1--+ IS A +--+ IS B +--+ IS C +--IPv6 host#2 189 | v4/v6 | | v4 IS | | v4/v6 | 190 +--------+ +-------+ +--------+ 192 IS A will find the shortest path to IPv6 host#2 as being through IS 193 B. If host#1 then sends an IPv6 packet to the host#2, then the dual 194 IS will forward it to the IS B, which will not be able to forward 195 the packet. IS B will discard the packet instead, resulting in 196 packet loss and a blackhole. 198 This document describes a mechanism that can be used to overcome 199 this topological restriction. The mechanism detects that a packet is 200 about to be send to an IS that does not support that network-layer 201 protocol, and automatically encapsulates the packet into a form that 202 then can be forwarded. Essentially the mechanism can take an 203 existing IS, or collection of ISs, that support forwarding of IPv4 204 for example, and, by automatic encapsulation of IPv6 inside IPv4, 205 can enable IPv6 traffic to also cross these IPv4 ISs, making that 206 part of the network behave as if it is dual. 208 Christian Expires March 2003 4 209 IS-IS Automatic Encapsulation 211 3.The automatic encapsulation mechanism. 213 3.1. Introduction. 215 Consider the following example:- 217 +--------+ +-------+ +--------+ 218 IPv4 host--+ IS A | | IS B | | IS C +--IPv4 host 219 | v4/v6 +--+ v4 IS +--+ v4/v6 | 220 IPv6 host--+ | | | | +--IPv6 host 221 +--------+ +-------+ +--------+ 223 Forwarding of IPv4 traffic from one host to the other is not a 224 problem in this network. However IPv6 traffic cannot be forwarded by 225 IS B without being encapsulated inside an IPv4 packet. 227 IS A and IS C actually have most of the information that they need 228 in order to automatically perform this encapsulation. 230 1. IS A can detect that IS B cannot forward an IPv6 packet, because 231 RFC 1195 [1] already requires IS B to include a "protocols 232 supported" TLV in Hello packets. Absence of the TLV indicates 233 that an IS that can forward only CLNP. 235 2. IS A receives LSPs (Link State PDUs) from IS C. This is because 236 IS-IS LSPs are neither IPv4 nor IPv6 packets. IS-IS is a 237 network-layer protocol in its own right, and is used in common 238 by all ISs whether they forward CLNP, IPv4 or IPv6 packets. 240 By adding an extra TLV to the LSPs that IS C transmits, containing 241 the encapsulation/unencapsulation capability of C, this information 242 will be flooded throughout the level-1 area or level-2 subdomain. 243 IS A is now able to encapsulate IPv6 traffic inside IPv4 packets, 244 and send them to IS C, on the understanding that IS C will 245 unencapsulate the IPv6 traffic and forward it onwards. 247 3.2. Encapsulation Capability Field. 249 Any IS that supports automatic encapsulation/unencapsulation MUST 250 include an "Encapsulation Capability" TLV in LSPs that have LSP 251 number 0. This TLV MUST be included in both level-1 LSPs and level- 252 2 LSPs. 254 The structure of the TLV is as follows:- 256 Code: 16 (decimal) 257 Length: The length of the value 258 Value: The value shall contain Sub-TLVs of the form:- 259 Sub-TLV Type 260 Sub-TLV Length: The length of the sub-TLV value 261 Sub-TLV Value: Variable number of bytes 263 Christian Expires March 2003 5 264 IS-IS Automatic Encapsulation 266 Sub-TLVs with sub-TLV type equal to 1 MUST contain three byte 267 encapsulation modes with the following structure:- 269 Sub-TLV type: 1 270 Sub-TLV length: Three times the number of encapsulation modes 271 Sub-TLV value: Encapsulation-mode#1 272 Inner-Protocol#1 273 Outer-Protocol#1 274 Encapsulation-mode#2 275 Inner-Protocol#2 276 Outer-Protocol#2 277 . 278 . 279 Encapsulation-mode#n 280 Inner-Protocol#n 281 Outer-Protocol#n 283 Encapsulation-mode SHALL be 47 (decimal) to describe a 284 GRE encapsulation as defined in RFCs 1701[2], 1702[3], 285 2784[4] and 3147[5]. 287 Inner-Protocol SHALL be the NLPID of a packet that the 288 IS is capable of sending or receiving in an encapsulated 289 form. 291 Outer-Protocol SHALL be the NLPID of a packet that the 292 IS is capable of using to transport the Inner-Protocol 293 in encapsulated form. 295 NLPIDs SHALL be those as specified in ISO/TR 9577[8]. 297 47 is chosen simply as it is the IP protocol number for GRE 298 encapsulation. 300 Note that ITU-T G.7712 [10] mandates that GRE shall be used for all 301 combinations of CLNS, IPv4 and IPv6 over CLNS, IPv4 or IPv6. 302 Therefore if interoperability is required with SONET / SDH DCC 303 channels then GRE will have to be supported. RFC 3147 [5] also 304 describes IP encapsulation over CLNS using GRE. 306 Future capabilities, such as non-NLPID definitions, may be provided 307 using the same TLV number by using an alternative sub-TLV number. 309 Christian Expires March 2003 6 310 IS-IS Automatic Encapsulation 312 By way of an example, a dual IPv4/IPv6 IS that supports automatic 313 encapsulation of IPv6 over IPv4, and automatic encapsulation of IPv4 314 over IPv6, using GRE would therefore transmit the TLV with the 315 following contents:- 317 Dec (Hex) 318 16 (0x10): The TLV number 319 8 (0x08): The length of the value 320 1 (0x01): Sub-TLV type 1 321 6 (0x06): Length of the value of the sub-TLV 322 47 (0x2F): Indicating that the next two bytes are a GRE mode 323 204 (0xCC): Inner-protocol of IPv4 324 142 (0x8E): Outer-protocol of IPv6 325 47 (0x2F): Indicating that the next two bytes are a GRE mode 326 142 (0x8E): Inner protocol of IPv6 327 204 (0xCC): Outer protocol of IPv4 329 An IS that includes an encapsulation mode in its "encapsulation 330 capability" TLV MUST be capable of both transmitting and receiving 331 that encapsulation mode, as specified in sections 3.3 and 3.4. 333 3.3. Transmission of automatically encapsulated packets 335 Shortest paths SHALL be calculated in the normal way, as per RFC 336 1195 [1]. 338 Before forwarding a packet to a next hop, an IS MUST check that the 339 next hop can forward that type of packet. The IS MUST check this by 340 referring to the "protocol supported" TLV in IS-IS Hello PDUs. 341 Absence of a "Protocols Supported" TLV in Hello PDUs indicates that 342 the next hop can forward only CLNP packets. 344 If an IS finds that the next hop does support the type of packet 345 that it is attempting to forward, then it MUST simply forward the 346 packet to that adjacency as normal, without encapsulating it. 348 If an IS finds that the next hop does not support the type of packet 349 that it is attempting to forward, then it MUST search along the 350 shortest path from itself to the destination, and MUST inspect the 351 "encapsulation capability" TLV of LSP 0 of each IS until it finds an 352 IS that it is able to send the packet to in an encapsulated form. 354 Christian Expires March 2003 7 355 IS-IS Automatic Encapsulation 357 The IS MUST search within each "encapsulation capability" TLV until 358 it finds an encapsulation mode that meets the following three 359 conditions:- 361 1.The encapsulation-mode MUST be one that this IS supports. 362 2.The inner-protocol MUST be equal to the NLPID of the packet that 363 this IS is attempting to forward. 364 3.The outer-protocol MUST be equal to one of the NLPIDs that the 365 next hop lists in the "protocols supported" TLV of IS-IS Hello 366 PDUs, or equal to the NLPID for CLNS/CLNP if no "protocols 367 supported" TLV is present in IS-IS Hello PDUs from the next hop. 369 When inspecting an "encapsulation capability" TLV, then, an IS MUST 370 ignore any encapsulation modes that it does not understand, but 371 instead jump forward to inspect the next encapsulation mode, until 372 it finds a suitable mode or until it reaches the end of the TLV. 374 When inspecting an "encapsulation capability" TLV, then, an IS MUST 375 ignore any sub-TLVs that it does not understand, but instead jump 376 forward to inspect the next sub-TLV, until it finds a suitable mode 377 or until it reaches the end of the TLV. 379 The IS MUST encapsulate the packet inside another and send it to the 380 first IS along the shortest path to the destination that meets the 381 criteria, using the encapsulation mode that resulted in it meeting 382 the above criteria. See 2.3.1. for an explanation. 384 It is suggested that this search is pre-calculated and performed for 385 every destination that cannot be forwarded natively every time the 386 SPF (Dijkstra) algorithm is run, and that the results are included 387 in each forwarding table, with a marker indicating that for that 388 particular destination that the packet should be encapsulated using 389 a certain encapsulation mode (if more than one is supported) and 390 with a certain destination address, which will be a destination 391 address expressed in the format used by the outer-protocol that is 392 going to be used. For this a modified SPF algorithm is provided in 393 Annex A. 395 The destination address of the resultant encapsulation packet MUST 396 be equal to the identity of the IS that sent the TLV that was the 397 first along the shortest path that met the above criteria. 399 The source address of the resultant encapsulation packet MUST be 400 equal to the identity of the IS that is performing the 401 encapsulation. 403 If the outer protocol is IPv4 then the "Don't Fragment" bit MUST NOT 404 be set. If the outer protocol is CLNP then the "Segmentation 405 Permitted" flag MUST be set. This will protect against packet loss 406 due to the new packet being longer than the MTU size of the link 407 over which it is to be transmitted, and will prevent unwanted 408 interactions with path MTU discovery [11]. 410 Christian Expires March 2003 8 411 IS-IS Automatic Encapsulation 413 3.3.1. Reasoning for sending to first capable IS 415 Section 3.3 indicates that a packet that cannot be forwarded 416 natively should be encapsulated and sent to the first IS along the 417 shortest path that advertises itself as being capable of 418 unencapsulating it. In fact, the packet could be encapsulated and 419 sent to any IS along the shortest path that advertises itself as 420 being capable of unencapsulating it, and the packet would arrive at 421 its destination. 423 The most reasonable choices would appear to be either the first, or 424 the last IS unencapsulation capable IS, each choice has advantages 425 and disadvantages. 427 Choosing the first may result in a packet being encapsulated and 428 unencapsulated several times on its way to its destination, as it 429 crosses multiple "subnetworks" that do not support forwarding of 430 that type of packet. When the packet is being forwarded by a part of 431 the network that can forward it natively, it is in its original 432 form. 434 Choosing the last may result in encapsulation within encapsulation 435 within encapsulation, as for example an IPv6 packet will become an 436 IPv4 packet and remain so till the last IS that can unencapsulate. 437 This IPv4 packet may in turn need to traverse an IPv6-only 438 "subnetwork" and be encapsulated again. If the last IS capable of 439 unencapsulation advertises itself as being capable of IPv6/IPv4 and 440 IPv4/IPv6, then it will loaded with unencapsulating all of the 441 layers of encapsulation in one go. 443 Although the argument is probably a religious one, unencapsulating a 444 packet as soon as possible, and avoiding encapsulation within 445 encapsulation (and the long packets that may result) would appear to 446 be the lesser of the two evils. The load of fragmentation and 447 reassembly must also be considered if multiple layers of 448 encapsulation results in an MTU size being blown. Also it is 449 probably better for a packet to exist in the network in its native 450 form whenever possible, making the network easier to debug, and 451 reducing the impact of encapsulation to the smallest part of the 452 network possible. 454 However, any IS MUST be able to unencapsulate any packet that 455 arrives at it with its destination address, and with an 456 encapsulation mode that it advertised in its "encapsulation 457 capability" TLV. This opens the possibility for more intelligent 458 algorithms to be developed that choose an IS capable of 459 unencapsulating, other than the first. 461 Christian Expires March 2003 9 462 IS-IS Automatic Encapsulation 464 3.4. Receipt of automatically encapsulated packets 466 An IS that supports automatic encapsulation / unencapsulation MUST 467 inspect any received packet that has a destination address equal to 468 itself to see if it is an encapsulation of a type that it 469 transmitted in its "encapsulation capability" TLV. 471 If the IS finds that such a received packet is an encapsulation 472 packet then it SHOULD discard the inner packet if it is of a type 473 that it did not list as an "inner-protocol" in an encapsulation mode 474 in its "encapsulation capability" TLV. 476 Upon discarding such a packet it is suggested that the IS reports or 477 logs an error report. 479 An IS that also supports manually configured tunnels will need to 480 check that a packet has not arrived over a manual tunnel in the 481 normal way before discarding it. 483 Otherwise the received packet MUST be unencapsulated and re- 484 received. Note that encapsulation within encapsulation is a 485 possibility, particularly for ISs that support three or more network 486 layer protocols. 488 3.5. Interaction with Path MTU Discovery (PMTU), RFC 1191 [11]. 490 Although packets become encapsulated, no tunnel "interface" or 491 circuit as such really exists. Therefore there will be no MTU limit 492 for the inner-protocol. It is suggested that packets of any size 493 are accepted, then encapsulated, and that the encapsulated outer- 494 protocol packet is fragmented/segmented if necessary in order to be 495 forwarded over the real interface. For this reason in the new 496 outer-protocol packet the Don't Fragment MUST NOT be set (for IPv4), 497 or Segmentation Permitted flag MUST be set (for CLNP). 499 One consequence of this is that a link, if packets traverse it in 500 an encapsulated form, becomes invisible to Path MTU Discovery. 502 However this is the safest option as it guarantees that packets will 503 never be discarded due to MTU issues. Because the inner-protocol is 504 different to the outer-protocol, if the outer-protocol where to be 505 discarded for any reason then the reason is not likely to be known 506 to the originator of the inner-protocol packet. Path MTU discovery 507 does rely on knowing the reason for discard of packets, and so the 508 safest option is to make the outer-protocol and encapsulation 509 process invisible to it. 511 Christian Expires March 2003 10 512 IS-IS Automatic Encapsulation 514 An additional option is to reject packets for encapsulation that are 515 bigger than a certain size, and to report back to the originator a 516 suitable error message. If this approach is chosen then the packet 517 MUST be rejected before encapsulation, and a suitable error message 518 MUST be returned to the originator using the correct mechanism for 519 that network layer protocol. Such a process would be prior to and 520 independent of automatic encapsulation, and does not alter the 521 requirement that the outer-protocol packets are never discarded, but 522 fragmented/segmented instead. 524 4.Allowable and non-allowable topologies 526 This mechanism effectively enables an IS or group of ISs to act as 527 if they support one or more network layer protocols that they 528 actually do not. Automatic encapsulation is the process that 529 enables this to be possible, but care must be taken to ensure that 530 incompatible packets are not leaked into such a "subnetwork" without 531 going through an automatic encapsulation capable IS. 533 Thus, at the all of the boundaries to the "subnetwork", there MUST 534 be installed an IS that supports automatic encapsulation. At points 535 where the inner "subnetwork" meet the outer general network without 536 an automatic encapsulation IS between the two, any adjacency MUST be 537 disabled. 539 In order to partially automate this the ITU-T mandated in G.7712[10] 540 that any Integrated IS-IS capable SDH NE must not consider itself a 541 neighbour to any other IS unless the other IS supports at least one 542 network layer protocol in common with it. This effectively makes it 543 impossible to accidentally have an adjacency between an OSI-only and 544 an IP-only SDH NE, or between an IPv4-only and an IPv6-only SDH NE. 546 This cannot be retrospectively applied to RFC 1195[1] compliant ISs, 547 however it is recommended that all Integrated IS-IS ISs include this 548 safeguard whenever possible. In the absence of this behaviour it is 549 the responsibility of the network manager to manually insure that no 550 such adjacencies are formed. Certain Integrated IS-IS 551 implementations also check for correct subnetting of a neighbour 552 before accepting an adjacency; usefully this should also prevent an 553 IPv4-only IS from forming an adjacency with an OSI-only or an 554 IPv6-only IS. 556 Christian Expires March 2003 11 557 IS-IS Automatic Encapsulation 559 In general the existing RFC 1195[1] topological restrictions still 560 apply inside a "subnetwork" that is bounded by automatically 561 encapsulating ISs, and outside of the automatically encapsulating 562 ISs too. For example:- 564 1. Within a "subnetwork" that can forward only IPv4, only IPv4 can 565 be forwarded. A dual IPv4/IPv6 IS MAY be installed inside this 566 "subnetwork", but, it MUST NOT forward any IPv6 packets. No IPv6 567 hosts (including hosts internal to an IPv4/IPv6 IS) may be 568 present in the "subnetwork". 570 2. Outside of the "subnetwork", i.e. on the other side of an 571 automatic encapsulation capable IS, if both IPv4 and IPv6 packets 572 are present in a native form, then all ISs must be capable of 573 forwarding both IPv4 and IPv6. 575 IPv6-only 576 .......... 577 IPv4 host-+------+ +------+ .+------+. +------+ +------+-IPv4 host 578 | IS G |--| IS H |--| IS I |--| IS J |--| IS K | 579 IPv6 host-+------+ +---+--+ .+--+---+. +--+---+ +------+-IPv6 host 580 | ....X..... | 581 | X | 582 .......|........X.........|....... 583 . +---+--+ +--+---+ +--+---+ . 584 . | IS A |--| IS B |--| IS C | . 585 . +--+---+ +------+ +---+--+ . 586 . | | .IPv4-only 587 . +--+---+ +------+ +---+--+ . 588 . | IS D |--| IS E |--| IS F | . 589 . +---+--+ +------+ +--+---+ . 590 .......|..................|....... 591 | | 592 +------+ +---+--+ +--+---+ +------+ 593 IPv6 host-+ IS L |--| IS M | | IS N |--| IS O +-IPv6 host 594 +------+ +------+ +------+ +------+ 596 ISs A, B, C, D, E and F are an IPv4-only "subnetwork"; therefore ISs 597 H, J, M and N must be capable of automatically encapsulating IPv6 598 over IPv4. 600 IS I is an IPv6-only "subnetwork", therefore ISs H and J must be 601 capable of automatically encapsulating IPv4 over IPv6. 603 ISs I and B support no network layer protocol in common and must 604 therefore not form an adjacency. 606 ISs G and K must forward IPv4 and IPv6 traffic and must therefore 607 both be dual. 609 ISs L and O need to forward only IPv6 and therefore may be either 610 IPv6 only or dual. 612 Christian Expires March 2003 12 613 IS-IS Automatic Encapsulation 615 5.LAN interfaces 617 As stated in section 4, ISs must not have adjacencies if they are 618 able to forward packets that the neighbour does not support, unless 619 they can automatically encapsulate. 621 Consequently an IPv4-only and an IPv6-only IS may exist in the same 622 area and on the same LAN, but will have no adjacency with each 623 other. 625 If there is a dual IS on the LAN that does support automatic 626 encapsulation, then both the IPv4 and the IPv6 IS will have an 627 adjacency with it. 629 5.1. PseudoNode election process 631 ISs can choose a Designated IS (DIS) only from valid adjacencies, 632 therefore an IPv4-only IS cannot elect an IPv6-only IS as DIS, and 633 vice versa. 635 In this case there are effectively two separate "sub-LANs" on the 636 physical LAN. The IPv4-only ISs form one "sub-LAN" and elect a DIS, 637 whilst the IPv6-only ISs form a second "sub-LAN" and a second DIS. 639 Clearly a dual automatically encapsulating IS needs to be capable of 640 connecting to both "sub-LANs", and so MUST participate in both 641 pseudonode election processes. 643 In this case a dual IS that does not support automatic 644 encapsulation MUST NOT have adjacencies both with IPv4-only and with 645 IPv6-only ISs, as this would form a leak between the two 646 "subnetworks" and may cause packet loss. Therefore such a dual IS 647 simply cannot appear on such a LAN, and a modified pseudonode 648 election process does not apply to it. The following scenarios must 649 be considered:- 651 1.The dual automatic encapsulating IS might win neither election 652 process, in which case it is not DIS. 654 2.The dual automatic encapsulating IS might be elected DIS by the 655 IPv4 ISs on the LAN, but not the IPv6 ISs; in this case it MUST 656 create a pseudonode, and the pseudonode MUST declare adjacencies 657 with all IPv4-capable ISs on the LAN (the IPv4-only ISs and the 658 dual IPv4/IPv6 ISs on the LAN), but MUST NOT declare adjacencies 659 with any IPv6-only ISs. 661 3.The dual automatic encapsulating IS might be elected DIS by the 662 IPv6 ISs on the LAN, but not the IPv4 ISs; in this case it MUST 663 create a pseudonode, and the pseudonode MUST declare adjacencies 664 with all IPv6-capable ISs on the LAN (the IPv6-only ISs and the 665 dual IPv4/IPv6 ISs on the LAN), but MUST NOT declare adjacencies 666 with any IPv4-only ISs. 668 Christian Expires March 2003 13 669 IS-IS Automatic Encapsulation 671 4.The dual automatic encapsulating IS might be elected DIS both by 672 the IPv4 ISs and by the IPv6 ISs; in this case it MUST create one 673 pseudonode which MUST declare adjacencies with all IPv4-capable 674 ISs on the LAN, with all-IPv6 capable ISs on the LAN, and with 675 the dual automatic encapsulating IS. 677 The first three scenarios will always forward traffic correctly in 678 on a LAN and will result in packets being encapsulated before being 679 forwarded across incompatible ISs. 681 The fourth scenario relies on other ISs on the LAN conforming to 682 ISO/IEC 10589 section C.2.5 item "h" or RFC 1195 [1] section 683 C.1.4 step 0 clause 8. ISs that do not will drop packets 684 rather than send traffic to a dual IS for automatic encapsulation, 685 if the dual IS is the DIS, and if non-compatible ISs on the same LAN 686 are on the shortest path. This is because the psuedonode declares 687 itself to be between two ISs that are actually incompatible and 688 therefore should not share an adjacency. The SPF algorithm in one 689 IS on the LAN may find other ISs on the LAN to be the shortest path 690 to certain destinations, through the pseudonode, but then cannot 691 actually forward traffic to them as there is no adjacency. This 692 can result in packets being dropped rather than being encapsulated 693 in order to traverse incompatible ISs on the LAN. 695 ISO/IEC 10589 section C.2.5 item "h" or RFC 1195 [1] section 696 C.1.4 step 0 clause 8 causes an IS to forward traffic to the DIS in 697 this scenario, which in this case is an automatic encapsulation IS. 698 Thus if all ISs on the LAN that have a lower priority than the 699 automatic encapsulation IS are conformant with this clause then 700 packets are forwarded and encapsulated properly. 702 Network administrators need to ensure that ISs that do not conform 703 with ISO/IEC 10589 section C.2.5 item "h" or RFC 1195 [1] section 704 C.1.4 step 0 clause 8 have a higher priority than any automatic 705 encapsulation ISs on the same LAN if it is a mixed protocol LAN. 707 5.2. LSP update process 709 ISO/IEC 10589 [2] states in section 7.3.15.1 that an LSP received 710 that does not come from a valid adjacency must be discarded. A 711 strict single protocol implementation will therefore reject LSPs 712 that are transmitted onto a LAN interface by an IS that it has 713 rejected an adjacency with due to no network-layer protocol in 714 common (or by manual configuration or no subnet in common). 716 Thus if an IPv4-only IS transmits an LSP onto a LAN then an IPv6- 717 only IS can receive such an LSP only from a dual automatic 718 encapsulating IS. Normally a dual IS will only forward such an LSP 719 during periodic LSP database synchronisation. 721 Christian Expires March 2003 14 722 IS-IS Automatic Encapsulation 724 Dual automatic encapsulating ISs are therefore required to have 725 modified LSP flooding behaviour so that OSI-only, IPv4-only or IPv6- 726 only ISs do not need to wait for the next LSP database 727 synchronisation event. 729 Dual automatic encapsulating ISs MUST check incoming LSPs that 730 arrive on LAN interfaces to see if they come from a neighbour that 731 supports all of the network layer protocols that the dual automatic 732 encapsulating IS does. This MUST be achieved by inspection of the 733 "protocols supported" TLV in Hello packets received from that 734 neighbour. 736 If the LSP is received from a neighbour that does support all of the 737 network layer protocols that the dual or multilingual IS supports, 738 then the dual automatic encapsulating IS SHALL behave as per ISO/IEC 739 10589 and unset the SRM flag for that LSP on that LAN interface if 740 it already has the LSP, or shall flood it out of all other 741 interfaces if it does not already have the LSP. 743 If the LSP is received from a neighbour that does not support all of 744 the network layer protocols that the dual automatic encapsulating IS 745 supports, and, if it does not already have the LSP then the dual 746 automatic encapsulating IS SHALL set the SRM flag for that LSP on 747 the LAN interface over which the LSP was received, in addition to 748 all other interfaces, resulting in the dual automatic encapsulating 749 IS re-transmitting the LSP onto the LAN. 751 In this way if an LSP is transmitted onto the LAN by an IPv4-only 752 IS, then one of the dual automatic encapsulating ISs will re- 753 transmit the LSP, so that it may be received on a valid adjacency by 754 IPv6-only ISs on the LAN and vice versa. 756 5.3. Redirects 758 If a dual automatic encapsulating IS originates an ICMP redirect 759 request, the request MUST not redirect IPv4 packets from an IPv4 760 capable IS to a non-IPv4 capable IS, or redirect IPv6 packets from 761 an IPv6 capable IS to a non-IPv6 capable IS. Likewise if a dual 762 automatic encapsulating router originates ISO/IEC 9542[5] Redirect 763 PDUs, the redirect MUST not redirect CLNS packets from an OSI 764 capable IS to a non-OSI capable IS. 766 6.Level-1, level-2 ISs 768 Although this mechanism allows "subnetworks" to exist in a level-1 769 area or level-2 subdomain that do not support all of the network 770 layer protocols present in the area or subdomain, packets must still 771 be able to get in and out of an area and onto the level-2 subdomain. 773 Christian Expires March 2003 15 774 IS-IS Automatic Encapsulation 776 It is therefore recommended that all ISs that support both level-1 777 and level-2 can forward all network layer protocols that exist in 778 the area. 780 However this may not be possible, if for example an existing network 781 is using this mechanism to upgrade parts of an area to support a new 782 network layer protocol, but a level-1, level-2 IS cannot be 783 upgraded. 785 In this case another IS that does support the new network layer 786 protocol must become the gateway for that protocol. This can be 787 achieved by configuration either of a default route, or a collection 788 of static routes that cover all possible "out of area" destinations. 790 Note that RFC 1195 [1] forbids default routes in level-1 LSPs 791 (however this does not reduce its usefulness as a solution). 793 This gateway IS must then tunnel all "out of area" packets of the 794 new network layer protocol across the incompatible level-1,level-2 795 IS to another IS somewhere in the level-2 subdomain or other routing 796 protocol. 798 Multiple gateways may be configured for redundancy, in this case a 799 gateway SHOULD gate advertisement of a default route on the validity 800 of the tunnel that it is using to send "out of area" packets across. 801 i.e. the IS SHOULD somehow detect that the other end of the tunnel 802 is alive and contactable, and if it is not, it SHOULD stop 803 advertising a default route into the area. This can be achieved by 804 running some other routing protocol such as RIP or OSPF across the 805 tunnel, or another instance of IS-IS, for example. 807 7.Security Considerations 809 7.1 Injection of IP and CLNP packets into the network 811 An IS that employs automatic encapsulation is required to 812 unencapsulate any incoming packet that is of a an advertised 813 encapsulation mode, and forward the contents. 815 Consequently packets may potentially be injected at such an IS 816 in an encapsulated form that maybe would normally be filtered 817 at the edge of a routing domain, but which are now an 818 encapsulation packet. 820 Such a risk is not unique to automatic encapsulation, but is 821 present in manually configured tunnels too, such as RFC 2784 [4] 822 GRE tunnels. 824 Encapsulated packets should never arrive from any source other 825 than another IS in the same level-1 area or level-2 subdomain, 826 and this MAY then be used as the basis of a security filter. 828 Christian Expires March 2003 16 829 IS-IS Automatic Encapsulation 831 In any case such a mechanism will allow an attacker only to 832 inject packets into a network; it does not supply a return path. 834 7.2 Injection of other packets into the network 836 Section 3.4 states that incoming packets SHOULD be discarded if 837 they are not of an inner-protocol type that the IS advertised as 838 being able to unencapsulate. 840 This clause is an important security feature as it prevents 841 false routing packets and consequent false routes from being 842 injected into the network. 844 8.References 846 [1] RFC 1195 847 Use of OSI IS-IS for Routing in TCP/IP and Dual Environments. 849 [2] RFC 1701 Generic Routing Encapsulation (GRE). 851 [3] RFC 1702 Generic Routing Encapsulation over IPv4 networks. 853 [4] RFC 2784 Generic Routing Encapsulation (GRE). 855 [5] RFC 3147 Generic Routing Encapsulation over CLNS Networks. 857 [6] RFC 2893 Transition Mechanisms for IPv6 Hosts and Routers. 859 [7] RFC 2003 IP Encapsulation within IP. 861 [8] ISO 9577 and ITU-T X.263 Information Technology - Protocol 862 Identification In The Network Layer. 864 [9] http://www.iana.org/assignments/ethernet-numbers. 866 [10] ITU-T Recommendation G.7712 v1.2 Architecture and 867 Specification of Data Communication Network. 869 [11] RFC 1191 Path MTU discovery. 871 [12] draft-ietf-isis-ipv6-02.txt Routing IPv6 with IS-IS 873 9.Acknowledgements 875 Jonathan Sadler, Mike Shand and Les Ginsberg have made various 876 suggestions that have improved the automatic encapsulation scheme 877 way beyond what was originally presented. 879 Christian Expires March 2003 17 880 IS-IS Automatic Encapsulation 882 10.Author's Address 884 Philip Christian, 885 Christian Tena LTD, 886 Essex, 887 UK 888 Email: philip.christian@christiantena.co.uk 890 11.Copyright Notice 892 Copyright (C) The Internet Society 2001. All Rights Reserved. 894 This document and translations of it may be copied and furnished to 895 others, and derivative works that comment on or otherwise explain it 896 or assist in its implementation may be prepared, copied, published 897 and distributed, in whole or in part, without restriction of any 898 kind, provided that the above copyright notice and this paragraph 899 are included on all such copies and derivative works. However, this 900 document itself may not be modified in any way, such as by removing 901 the copyright notice or references to the Internet Society or other 902 Internet organisations, except as needed for the purpose of 903 developing Internet standards in which case the procedures for 904 copyrights defined in the Internet Standards process must be 905 followed, or as required to translate it into languages other than 906 English. 908 The limited permissions granted above are perpetual and will not be 909 revoked by the Internet Society or its successors or assigns. 911 This document and the information contained herein is provided on an 912 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 913 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 914 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 915 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 916 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 918 Christian Expires March 2003 18 919 IS-IS Automatic Encapsulation 921 Annex A 922 Updates to Dijkstra's Algorithm 924 The following Annex contains the full Dijkstra's algorithm including 925 extensions to support automatic tunnelling. It is based on the 926 algorithm as specified in RFC 1195 [1]. The algorithm describes the 927 behaviour of a dual protocol IS capable of supporting network-layer 928 protocols A and B. A and B represent any pair of network-layer 929 protocols such as CLNP, IPv4 or IPv6. 931 A1. Changes to the Database 933 The PATHS and TENTS database should be updated to contain an 934 extension to the {Adj(N)}, element of the triple. The adjacency N 935 element will contain two corresponding Dual Protocol Support 936 (ABDP(N)-BADP(N)) entries which will represent the System ID of the 937 first Dual router on the path from S to N capable of de- 938 encapsulating A over B tunnelled packets (ABDP(N)) and the System ID 939 of the first dual router on that path from S to N capable of de- 940 encapsulating B over A tunnelled packets (BADP(N). If no *DP(N) 941 router exists on the PATH then this value will be set to zero. If 942 multiple Adj(N) entries exist in either the TENTS or the PATHS 943 database then each adjacency will have corresponding *DP(N) entries. 944 Thus each triple will take the format 945 946 If the value of ABDP(N) is set to 0 then this means that no dual 947 router exists on the path to the destination capable of de- 948 encapsulating and encapsulating A over B packets. 949 If the value of BADP(N) is set to 0 then this means that no dual 950 router exists on the path to the destination capable of de- 951 encapsulating and encapsulating B over A packets. 953 A2. Changes to the Algorithm 955 The SPF algorithm specified in section C.2.3 of [1] is amended to 956 appear as follows: 958 Step 0: Initialize TENT and PATHS to empty. Initialize tentlength to 959 [internalmetric=0, externalmetric=0]. 961 (tentlength is the pathlength of elements in TENT that we are 962 examining.) 964 1) Add to PATHS, where W is a special value 965 indicating traffic to SELF is passed up to internal processes 966 (rather than forwarded). 968 2) Now pre-load TENT with the local adjacency database (Each entry 969 made to TENT must be marked as being either an End System or a 970 router to enable the check at the end of Step 2 to be made 971 correctly - Note that each local IP reachability entry is 972 included as an adjacency, and is marked as being an End System). 974 Christian Expires March 2003 19 975 IS-IS Automatic Encapsulation 977 For each adjacency Adj(N) (including level 1 OSI Manual 978 Adjacencies, or level 2 OSI enabled reachable addresses, and IP 979 reachability entries) on enabled circuits, to system N of SELF in 980 state "Up" compute: 982 d(N) = cost of the parent circuit of the adjacency (N), 983 obtained from metric.k , where k = one of {default metric, 984 delay metric, monetary metric, error metric} 986 Adj(N)-ABDP(N)-BADP(N) = the adjacency number of the 987 adjacency to N ,the SID of the next-hop router along the path 988 to the neighbour capable of de-encapsulating A over B packets 989 and the SID of the next-hop router along the path to the 990 neighbour capable of de-encapsulating B over A packets . In 991 this case i.e. during initialisation both DP values will be 992 set to 0 994 3) If a triple is in TENT, then: 996 If x = d(N), then {Adj(M)-ABDP(N)-BADP(N)} <--- {Adj(M)- 997 ABDP(M)-BADP(M)} U {Adj(N)-ABDP(N)-BADP(N)}. 999 4) If N is a router or an OSI End System entry, and there are now 1000 more adjacencies in {Adj(M)} than maximumPathSplits, then remove 1001 excess adjacencies as described in Clause 7.2.7 of [1]. If N is 1002 an IP Reachability Entry, then excess adjacencies may be removed 1003 as desired. This will not effect the correctness of routing, but 1004 may eliminate the determinism for IP routes (i.e., IP packets 1005 still follow optimal routes within an area, but where multiple 1006 equally good routes exist, will not necessarily follow precisely 1007 the route that any one particular router would have anticipated). 1009 5) If x < d(N), do nothing. 1011 6) If x > d(N), remove from TENT and 1012 add the triple . 1014 7) If no triple is in TENT, then 1015 add to TENT. 1017 8) Now add systems to which the local router does not have 1018 adjacencies, but which are mentioned in neighbouring pseudonode 1019 LSPs. The adjacency for such systems is set to that of the 1020 designated router. 1021 Note that this does not include IP reachability entries from 1022 neighbouring pseudonode LSPs. In particular, the pseudonode LSPs 1023 do not include IP reachability entries. 1025 9) For all broadcast circuits in state "On", find the pseudonode LSP 1026 for that circuit (specifically, the LSP with number zero and with 1027 the first 7 octets of LSPID equal to LnCircuitID for that 1028 circuit, where n is 1 (for level 1 routing) or 2 (level 2 1030 Christian Expires March 2003 20 1031 IS-IS Automatic Encapsulation 1033 routing)). If it is present, for all the neighbours N reported in 1034 all the LSPs of this pseudonode which do not exist in TENT add an 1035 entry to TENT, where: 1037 d(N) = metric.k of the circuit. 1038 Adj(N) = the adjacency number of the adjacency to the DR. 1040 10) Go to Step 2. 1042 Step 1: Examine the zeroeth link state PDU of P, the system just 1043 placed on PATHS (i.e., the LSP with the same first 7 octets of LSPID 1044 as P, and LSP number zero). 1046 1) If this LSP is present and the "Infinite Hippity Cost" bit is 1047 clear, then for each Adj(*)-ABDP(*)-BADP(*) pair in the PATHS 1048 database for P:- 1050 If this is not a pseudonode LSP and if ABDP(*) is equal to 1051 zero then check the unencapsulation capability field of the 1052 LSP, if it supports A over B then set the ABDP(P) value for 1053 this adjacency to be the system ID of P. 1055 If this is not a pseudonode LSP and if BADP(*) is equal to 1056 zero then check the unencapsulation capability field of the 1057 LSP, if it supports B over A then set the BADP(P)value for 1058 this adjacency to be the system ID of P. 1060 2) If this LSP is present, and the "Infinite Hippity Cost" bit is 1061 clear, then for each LSP of P (i.e., all LSPs with the same first 1062 7 octets of LSPID and P, irrespective of the value of LSP number) 1063 compute: 1065 dist(P,N) = d(P) + metric.k(P,N) 1067 for each neighbour N (both End System and router) of the system 1068 P. If the "Infinite Hippity Cost" bit is set, only consider the 1069 End System neighbours of the system P. 1070 Note that the End Systems neighbours of the system P includes IP 1071 reachable address entries included in the LSPs from system P. 1072 Here, d(P) is the second element of the triple 1074 1076 and metric.k(P,N) is the cost of the link from P to N as reported 1077 in P's link state PDU. 1079 3) If dist(P,N) > MaxPathMetric, then do nothing. 1081 4) If is in PATHS, then do 1082 nothing. 1084 Note: d(N) must be less than dist(P,N), or else N would not 1086 Christian Expires March 2003 21 1087 IS-IS Automatic Encapsulation 1089 have been put into PATHS. An additional sanity check may be 1090 done here to ensure that d(N) is in fact less than dist(P,N) 1092 6) If a triple is in TENT, then: 1094 a) If x = dist(P,N), then {Adj(N), ABDP(N)-BADP(N)} <-- {Adj(N) - 1095 ABDP(N)-BADP(N)} U {Adj(P) -ABDP(P)-BADP(N)}. 1097 Note that even if the value of Adj(N) is equal to the value 1098 Adj(P) but the corresponding values of either ABDP(P) or 1099 BADP(P) and ABDP(N) or BADP(N) are different then this should 1100 be treated as a different adjacency and will represent a 1101 different path to the destination. 1103 b) If N is a router or an OSI end system, and there are now more 1104 adjacencies in {Adj(N)} than maximumPath Splits, then remove 1105 excess adjacencies, as described in clause 7.2.7 of [1]. For IP 1106 Reachability Entries, excess adjacencies may be removed as 1107 desired. This will not effect the correctness of routing, but 1108 may eliminate the determinism for IP routes (i.e., IP packets 1109 will still follow optimal routes within an area, but where 1110 multiple equally good routes exist, will not necessarily follow 1111 precisely the route that any one particular router would have 1112 anticipated). 1114 c) if x < dist(P,N), do nothing. 1116 d) if x > dist(P,N), remove from 1117 TENT, and add 1118 1120 7) if no triple is in TENT, then add 1121 to TENT. 1123 Step 2: If TENT is empty, stop. Else: 1125 1) Find the element , with minimal x 1126 as follows: 1128 a) If an element <*,tentlength,*> remains in TENT in the list for 1129 tentlength, choose that element. If there are more than one 1130 elements in the list for tentlength, choose one of the elements 1131 (if any) for a system which is a pseudonode in preference to 1132 one for a non-pseudonode. If there are no more elements in the 1133 list for tentlength, increment tentlength and repeat Step 2. 1135 b) Remove from TENT. 1137 c) Add to PATHS. 1139 Christian Expires March 2003 22 1140 IS-IS Automatic Encapsulation 1142 d) If this is the Level 2 Decision Process running, and the system 1143 just added to PATHS listed itself as Partition Designated Level 1144 2 Intermediate system, then additionally add 1145 to PATHS, where AREA.P is the Network 1146 Entity Title of the other end of the Virtual Link, obtained by 1147 taking the first AREA listed in P's LSP and appending P's ID. 1149 e) If the system just added to PATHS was an end system, go to step 1150 2. Else go to Step 1. 1152 NOTE - In the level 2 context, the "End Systems" are the set of 1153 Reachable Address Prefixes (for OSI), the set of Area Addresses with 1154 zero cost (again, for OSI), plus the set of IP reachability entries 1155 (including both internal and external). 1157 Christian Expires March 2003 23