idnits 2.17.1 draft-ietf-pip-processing-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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 seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Expected the document's filename to be given on the first page, but didn't find any ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard 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 document seems to lack an Authors' Addresses Section. Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (August 1993) is 11210 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Francis 3 INTERNET-DRAFT (formerly Tsuchiya) 4 Bellcore 5 August 1993 7 Pip Header Processing 9 Changes Since Last Version 11 This version has the following changes from the previous version, 12 dated November 1992. 14 1. The management of the HD and RC fields has changed (though the 15 semantics and evolvability of them has not). The HD and RC 16 fields are still opaque (meaning that the semantics of the HD 17 and RC cannot be determined without additional information), but 18 Pip will operate globally under well-known sets of semantics, 19 and each packet indicates which set the packet falls under. The 20 need to remap the HD and RC fields hop-by-hop has been elim- 21 inated (though tagging is still a feature of Pip). 23 2. This version has made options faster to process and more gen- 24 eral. It has introduced fields in the fixed part of the Transit 25 Part to indicate which options are present, and the first option 26 now indicates where each individual option is in the list of 27 options. In addition, the Transit Options part can now be in 28 the self-encapsulation header. 30 3. The router and host options have been combined into one options 31 part. 33 4. The entire Host Part has been moved into the Initial Part. 35 5. All checksums have been removed. 37 6. The FTIFs have been limited to a single length (16 bits). No 38 that this does not limit a single "number" in the FTIF chain to 39 16 bits or less. A "number" can be encoded as mulitple FTIFs. 41 Status of this Memo 43 This document is an Internet Draft. Internet Drafts are working 44 documents of the Internet Engineering Task Force (IETF), its Areas, 45 and its Working Groups. Note that other groups may also distribute 46 working documents as Internet Drafts). 48 Internet Drafts are draft documents valid for a maximum of six 49 months. Internet Drafts may be updated, replaced, or obsoleted by 50 other documents at any time. It is not appropriate to use Internet 51 Drafts as reference material or to cite them other than as a "working 52 draft" or "work in progress." 54 Please check the I-D abstract listing contained in each Internet 55 Draft directory to learn the current status of this or any other 56 Internet Draft. 58 Abstract 60 Pip is an internet protocol intended as the replacement for IP ver- 61 sion 4. Pip is a general purpose internet protocol, designed to han- 62 dle all forseeable internet protocol requirements. This specifica- 63 tion defines the Pip header processing for Routers and Hosts. 65 Acknowledgements 67 I want to individually acknowledge Rob Coltun, Steve Deering, Ramesh 68 Govindan, Joel Halpern, John Ioannidis, Chris Petrilli, Bob Smart, 69 and Zheng Wang. I want also to acknowledge the many people from the 70 Pip working group who have participated in developing Pip. Finally, 71 I want to acknowledge the SIP protocol (or, more accurately, the peo- 72 ple behind the SIP protocol) for providing certain good ideas. 74 Conventions 76 All functions in this specification are mandatory. 78 1. Introduction 80 Pip is an internet protocol intended as the replacement for IP ver- 81 sion 4. Pip is a general purpose internet protocol, designed to 82 handle all forseeable internet protocol requirements. This specifi- 83 cation defines the Pip header processing for Routers and Hosts. 85 The design of Pip is fundamentally different from that of previous 86 internetwork protocols. Pip is designed to be as general as possi- 87 ble, but without significantly compromising performance. Because of 88 Pip's generality, it can handle forseeable routing and addressing 89 requirements. It is hoped that it will be able to handle most if not 90 all future routing and addressing requirements. 92 There are many detailed aspects of Pip that provide this generality 93 that are not discussed here. It is useful, however, to mention one 94 general aspect. That is, Pip strives to remove as much "functional 95 semantics" from the base specification as possible. Pip defines a 96 packet header and forwarding rules that can include many different 97 functional semantics (that is, routing, addressing, and flow para- 98 digms). Therefore, the reader may often find him or herself asking 99 "But how do you do foo with Pip?" The answer to this sort of question 100 belongs in companion documents to the basic Pip spec. 102 Pip can be thought of as a mechanism for triggering actions in hosts 103 and routers, just as a machine language can be thought of as a 104 mechanism for triggering actions in CPUs. The machine language has 105 no functional semantics outside of the specific actions it triggers 106 (move this register, write that memory location, etc.). But, the 107 machine language is a very powerful tool upon which functional seman- 108 tics are built. Likewise, Pip is a powerful tool upon which routing, 109 addressing, and flow functions can be built. 111 2. Pip Specification 113 The Pip header is partitioned into three parts, the Initial Part, the 114 Transit Part, and the Options Part. 116 +===========================+ 117 | Initial Part | 118 +===========================+ 119 | Transit Part | 120 +===========================+ 121 | Options Part | 122 +===========================+ 123 | | 124 | Payload | 125 | | 127 Each part falls on a 32-bit boundary (as indicated by the double 128 lines shown), and the Transit Part falls on a 64 bit boundary. 130 The concept of tunneling in an integral part of Pip. Pip achieves 131 tunneling by encapsulating the Transit Part of the Pip header in 132 another Transit Part. Therefore, when tunneling, there is one Tran- 133 sit Part for each (nested) tunnel: 135 +===========================+ 136 | Initial Part | 137 +===========================+ 138 | Transit Part | 139 +===========================+ 140 | Transit Part | 141 +===========================+ 142 . 143 . 144 . 145 +===========================+ 146 | Transit Part | 147 +===========================+ 148 | Options Part | 149 +===========================+ 151 Because each Transit Part has only what is necessary for router for- 152 warding and handling, this method of tunneling is reasonably effi- 153 cient in terms of packet size. 155 2.1. Initial Part 157 The Initial Part is formatted as shown in Figure 1. 159 length, in bits 160 +===========================+ 161 | Version Number = 8 | 4 162 +---------------------------+ 163 | Sub-Version | 4 164 +---------------------------+ 165 | Options Offset | 8 166 +---------------------------+ 167 | Options Contents | 8 168 +---------------------------+ 169 | Options Present | 8 170 +===========================+ 171 | Packet SubID | 16 172 +---------------------------+ 173 | Protocol | 16 174 +===========================+ 175 | Dest ID | 64 176 +===========================+ 177 | Source ID | 64 178 +===========================+ 179 | Payload Length | 32 180 +===========================+ 181 | Host Version | 8 182 +---------------------------+ 183 | Payload Offset | 8 184 +---------------------------+ 185 | Hop Count | 16 186 +===========================+ 188 Figure 1: Initial Part 190 An explanation of each field follows. 192 2.1.1. Version Numbers 194 The first octet is divided into two 4-bit fields, the Version and the 195 Sub-Version. The Version field is set to be 8, and is meant to be 196 version 8 of IP. (As of this writing, this is an experimental number 197 assigned for development of Pip.) Thus, all encapsulation schemes 198 defined for IP can work for Pip as well. 200 As long as the Version field is 8, the Initial Part and Options Part 201 of the Pip Header is as specified in this standard. (In other words, 202 the Sub-Version field refers only to the Transit Part.) 204 By doing this, we allow the Transit Part of the Pip Header to change 205 completely without necessarily requiring a host to understand the new 206 Transit Part. If a host receives a Pip header with a Version number 207 of 8 and an unknown Sub-version number, the host does not try to 208 parse the Transit Part at all, rather it processes only the Initial 209 Part and the Options Part. (By using the Pip Header Protocol to for- 210 mat Pip Headers, a host can be made to formulate the right Transit 211 Part, even though the host doesn't understand the semantics of the 212 Transit Part. This allows radical migration of the Transit Part 213 while potentially not requiring changes to hosts.) 215 If a host or a router receives a packet with an unknown Version 216 number, the packet is silently discarded. 218 The Sub-Version field is set to the value 0 for the version of Pip 219 defined in this specification. As long as the Sub-Version number is 220 0, the Transit Part is as specified in this standard. Any packet 221 received by a router with a Version number of 8 and an unknown Sub- 222 Version number is silently discarded. 224 2.1.2. Options Offset 226 The Options Offset indicates the position of the Options Part. The 227 unit of measure of the Options Offset is 32-bit words, counting the 228 first word of the Pip Header as word 0. 230 2.1.3. Options Contents 232 This field indicates how the Options Present field should be inter- 233 preted. Each bit of the Options field indicates if each of up to 234 eight options is present in the Options Part. The Options Contents 235 field indirectly indicates which option each bit of the Options 236 Present field refers to. We say indirectly because the mapping 237 referred to by the Options Contents field is stored locally. In other 238 words, without additional information (the mapping), it is not possi- 239 ble to examine the Options Contents field and know what option each 240 bit of the Options Present field refers to. 242 Any of 256 possible Options Contents values can be active at a given 243 time. (Note that the means by which the meaning of the Options Con- 244 tents values are assigned and conveyed to routers and hosts is out- 245 side the scope of this specification.) 247 2.1.4. Options Present 249 This field indicates which of the Options indicated by the Options 250 Contents field are actually present in the Options Part. Each bit of 251 this field refers to a single option type. The mapping of each bit 252 to its' option type is determined by the Options Contents field. 254 For instance, assume that the Options Contents field indicates that 255 bit 0 of the Options Present field refers to the PDN Address option, 256 that bit 1 of the Options Present field refers to the foo option, and 257 that bit 2 of the Options Present field refers to the Fragmentation 258 option. (As of this writing, there is only one option. Until there 259 are more than eight options, there is no need to define more than one 260 Options Contents values.) 262 In this case, a value of 101 in the Options Present field indicates 263 that the PDN Address and Fragmentation options are present in the 264 Options Part, and that the foo option is not present. 266 Note that an Options Present value of 0 indicates that there are no 267 options present, regardless of the value of the Options Contents 268 field. Note also that no more than 8 options, not including the 269 default first option (the Options Descriptor), can be present in any 270 Options Part. 272 The Options Contents/Options Present method of processing options 273 allows for efficient processing of options. First, a router can 274 ignore any options that may be present but that do not impact it (for 275 instance, a router not attached to a PDN need not consider the PDN 276 Address option). Second, the desired option can be very quickly 277 retrieved, because the first option, the Options Descriptor option, 278 contains the offset of each of the up to eight options indicated by 279 the Options Present field. 281 2.1.5. Packet SubID 283 This field is used by Pip hosts to correctly associate received PCMP 284 messages with local control blocks. This is necessary because the 285 semantics of the Transit Part can change while a packet is in 286 transit. Therefore, a router sending a PCMP message cannot neces- 287 sarily provide all of the information needed by the Pip host to 288 correctly identify the context of the received message (that is, 289 which "packet flow" it is identified with). 291 A PCMP message uses the Protocol, Source ID, Dest ID, and Packet 292 SubID to define the PCMP messages context. It is not sufficient to 293 use just Protocol, Source ID, and Dest ID, because two hosts running 294 the same protocol between them may have multiple "flows", for 295 instance, a data flow, a video flow, and an audio flow in the case of 296 multi-media. Each flow may have a different Transit Part, and take 297 different paths. Therefore, the Packet SubID field is needed to 298 further differentiate. 300 2.1.6. Protocol 302 Indicates the protocol header found in the payload. The values for 303 this field are the same as those used for IPv4. 305 2.1.7. Dest ID 307 The Dest ID field indicates the Pip ID of the final recipient of the 308 Pip packet. This field is examined by both hosts and routers. 310 When a Pip System processes the Routing Directive (RD), it may deter- 311 mine that it needs to examine the Dest ID for further processing. 312 This may happen both when a host or router receives a Pip packet des- 313 tined for itself, or when a router receives a packet that should be 314 forwarded based on Dest ID (as indicated by the RD). 316 When a Pip system determines at forwarding time that a packet is des- 317 tined for itself, it checks the Dest ID to verify if that packet is 318 destined for it. If the complete Dest ID matches one of its own Pip 319 IDs, then the packet is for it, and is passed to the layer indicated 320 by the Protocol field (in the Host Part). (The Pip system may of 321 course wish to check a security option before passing a packet to an 322 upper layer.) 324 If the complete Dest ID field does not match one of its own IDs, then 325 an ID/RD Mismatch PCMP message is sent to the source of the packet, 326 as indicated by the Source ID and potentially source information in 327 the RD. The purpose of this message is to flush the ID to RD binding 328 in the source Pip host. 330 2.1.8. Source ID 332 This is the Pip ID of the source of the packet. It is passed to 333 upper layers for the purposes of identifying the context for the 334 packet. 336 2.1.9. Payload Length 338 The Payload Length gives the length of the Pip packet payload in 339 units of 8 bits. The Payload Length does not include the length of 340 the Pip header. 342 2.1.10. Host Version 344 The Host Version field indicates what "version" of Pip software the 345 sending host has implemented. This is to allow a host to inform a 346 router which ancillary protocols/messages the host is able to accept. 347 It is envisioned that over time, new host functions will be 348 developed. Different hosts will install these new functions at dif- 349 ferent times. This field allows routers to know what functions the 350 host can and cannot handle. 352 2.1.11. Payload Offset 354 The Payload Offset indicates the position of the Payload Part. The 355 unit of measure of the Payload Offset is 32-bit words, counting the 356 first word of the Pip Header as word 0. 358 If a Pip system encapsulates a Transit Part in another Transit Part, 359 then the Payload Offset is increased by the length of the new Transit 360 Part. 362 2.1.12. Hop Count 364 The Hop Count is decremented by every router that forwards the Pip 365 packet. If a system receives a Pip header with a Hop Count equal to 366 0, and is not the recipient of the packet, then the packet is dis- 367 carded and a PCMP Destination Unreachable is routed to the system 368 indicated by the Routing Directive. (In other words, a host can 369 legally receive a Transit Part with a Hop Count of 0, and indeed a 370 host doesn't look at the Hop Count field upon reception.) 372 2.2. Transit Part 374 The Transit Part is formatted as shown in Figure 2. 376 length, in bits 377 +===========================+ 378 | Reserved | 16 379 +---------------------------+ 380 | Transit Part Offset | 8 381 +---------------------------+ 382 | HD Contents | 8 383 +===========================+ 384 | Handling Directive (HD) | 32 385 ---------------+===========================+ 386 ^ | FTIF Offset | 8 387 | +---------------------------+ 388 | | RC Contents | 8 389 | +---------------------------+ 390 | | Routing Context (RC) | 16 391 Routing +===========================+ 392 | FTIF 1 | 16 393 Directive +---------------------------+ 394 | | FTIF 2 | 16 395 | +---------------------------+ 396 | . 397 | . 398 | . 399 | +---------------------------+ 400 | | FTIF N | 16 401 | +---------------------------+ 402 v | Padding | Variable 403 ---------------+===========================+ 405 Figure 2: Transit Part 407 An explanation of each field follows. 409 2.2.1. Transit Part Offset 411 This field gives the position of the first word of the next Transit 412 Part. The unit of measure of the Transit Part Offset is 32-bit 413 words, counting the first word of the current Transit Part as word 0. 414 If there is no next Transit Part, then this field is written as all 415 0's. 417 2.2.2. HD Contents 419 He HD Contents field indicates how the Handling Directive (HD) field 420 should be interpreted. The HD field is divided into multiple fields, 421 each representing a different handling function. Each individual 422 field in the HD is called an HD Unit (HDU). The Options Contents 423 field indirectly indicates which HDUs are in the HD field, and where 424 they are. We say indirectly because the mapping referred to by the 425 HD Contents field is stored locally. In other words, without addi- 426 tional information (the mapping), it is not possible to examine the 427 HD Contents field and know what the HDU locations are. 429 Any of 256 possible HD Contents values can be active at a given time. 430 (Note that the means by which the meaning of the HD Contents values 431 are assigned and conveyed to routers and hosts is outside the scope 432 of this specification.) 434 2.2.3. Handling Directive (HD) 436 The HD is a general purpose field used for the purpose of triggering 437 special packet handling by a Pip system. The HD field does not 438 influence a Pip router's next hop choice for a Pip packet, nor does 439 it influence a Pip host's determination as to whether the Pip packet 440 is destined for it. Examples of special packet handling would be 441 "low priority queueing", or "high priority discard", etc. (Note that 442 the Transit Options also influence "handling", in the sense that han- 443 dling is essentially defined here to mean "anything that is not rout- 444 ing. The HD field, though, is intended for the most common types of 445 handling--handling that is expected to be in a significant percentage 446 of packets.) 448 Both hosts and routers use the HD field. (Hosts may make use of the 449 HD field for packet handling for both incoming and outgoing packets.) 451 There is a complete distinction between the syntax and the semantics 452 of the HD field. (This can be contrasted with, for instance, IP, 453 which couples the semantics and syntax of the TOS bits. That is, the 454 IP specification itself determines, to a first degree, how the TOS 455 bits are interpreted.) Each Pip system can modify the semantic 456 meaning of the HD, for instance, by increasing or decreasing the 457 queueing priority of a packet. This is called packet tagging. 459 From an abstract modeling perspective, the HD is handled as follows: 461 1. Extract the semantic meaning(s) (the handling instructions asso- 462 ciated with the HDUs) from the HD field. Transmitting Pip hosts 463 determine the semantic meaning by some other means, such as the 464 upper layer protocol. If the receiving system decapsulates mul- 465 tiple Pip headers, then the HD semantics are extracted from the 466 lowest Pip header for which it is not the target (see example on 467 tunneling below). 469 2. Handle the Pip packet according to those instructions. In some 470 cases, it is possible that the Pip system does not understand 471 the semantics of one or more HDUs of the HD field. For each HDU 472 whose semantics are not understood, however, the pip system at 473 least knows whether to 1) pass the HDU on untouched, 2) set it 474 to all 0s, 3) set it to all 1s, 4) discard the packet silently, 475 or 5) discard the packet with a PCMP HDU Not Understood packet. 477 3. Modify the semantic meaning if necessary. Note also that if the 478 Pip packet is replicated for multicast, each packet has its HD 479 semantics modified individually. 481 2.2.4. Tunneling 483 Consider two Pip systems, X and Y, separated by one or more inter- 484 mediate Pip systems. X wishes to tunnel a Transit Part to Y. Y is 485 therefore the target system of the tunnel. A Transit Part He arrives 486 at X. In order to forward the Transit Part to Y, X encapsulates He 487 in another Transit Part, Hy. Y is the target system for Transit Part 488 Hy. X sets the HD of He to what it would have been if Y was directly 489 connected to X (that is, there were no intermediate Pip systems 490 between X and Y). Further, it is intended that Y will derive its HD 491 semantics from the HD of Transit Part He, not Transit Part Hy. 493 ----0-----o-----o-----o-----o-----0---- 494 X I J K L Y 496 Now consider the operation of Pip system L (the previous hop system 497 to Y). When L forwards the packet to Y, it may either decapsulate 498 the packet (in the knowledge that Y is the target for Hy), or not 499 decapsulate the packet. Either way, L derives its HD semantics from 500 the HD of Transit Part He. 502 If L does not decapsulate the Transit Part, then it is as though I, 503 J, K, and L are a "subnetwork" (albeit a Pip subnetwork), and Y is 504 stripping the "subnetwork" header (Hy) off before processing the true 505 Transit Part (He). If L does decapsulate the Transit Part, then, 506 from Y's perspective, it is essentially as though Y were directly 507 connected to X. 509 2.2.5. Routing Directive (RD) 511 The RD consists of the Routing Context (RC), the RC Contents, the 512 FTIF Offset, and a series of zero or more FTIFs (Forwarding Table 513 Index Fields). This series of FTIFs is called the FTIF Chain. The 514 sole purpose of the RD is to determine how to forward the Pip 515 packet--the RD does not influence handling in any way. 517 Figure 3 illustrates the decision process for forwarding the Pip 518 packet. 520 Figure 3 is interpreted as follows. The FIB is the Forwarding Infor- 521 mation Block. The FIB contains all the information needed to forward 522 a packet, and may contain multiple next hop (for multicast). This 523 information includes 1) the outgoing interface, 2) how to encapsulate 524 the packet, including lower-layer address(es) (the lower-layer 525 address(es) along with the outgoing interface determine the next hop 526 Pip system), 3) whether and how to tunnel, 4) how to modify the 527 semantics of the HD and RC, and how to modify the FTIF Offset. The 528 goal of the forwarding algorithm is to reach the appropriate FIB. 530 The directed lines in Figure 3 start at the RC and, through various 531 possible paths, reach a FIB. These lines represent the various 532 information that can influence the forwarding decision (that is, the 533 FIB chosen). For instance, there is no way to reach a FIB without 534 first examining the information in the RC. However, it is possible 535 to identify a FIB by considering only the information in the RC (as 536 indicated by the directed line leading directly right from the RC). 537 Based on the information in the RC, it is also possible to determine 538 +---------+(next level RC) 539 (decapsulate)| | 540 | v 541 |<--------RC----------------->FIB 542 | / | | IF Offset) 543 | | | 544 | | v 545 |<------|---FTIF------------->FIB 546 | | / : 547 | |<- :(repeatedly...) 548 | | : 549 | | v 550 |<------|---FTIF------------->FIB 551 | / | 552 |<- | 553 v v 554 DestID-------------->FIB 556 Figure 3: Forwarding Process 558 that the Transit Part must be decapsulated, and 1) the RC of the next 559 Transit Part be processed (the line leading directly left), 2) the 560 FTIF indicated by the FTIF Offset is processed (the line leading down 561 and right), or 3) the Dest ID is processed (the line leading down and 562 lest). 564 Likewise, when considering the value of an FTIF (in addition to all 565 information already considered), the resulting action may be that 1) 566 a FIB is identified, 2) the Transit Part is decapsulated, 3) the sub- 567 sequent FTIF is processed, or 4) the Dest ID is processed. 569 The RC is handled similarly to the HD. The RC Contents field indi- 570 cates how the RC should be interpreted. While the RC is constructed 571 similarly to the HD in the sense that it consists of multiple fields, 572 the RC can be interpreted as a flat field in-so-far as forwarding a 573 Pip packet is concerned, whereas the HD cannot. 575 Thus, in a mechanical sense, the RC Contents can be viewed as an 576 index into a table that returns a pointer to another table (an 577 rcTable), which is indexed by the RC itself. (Or, the combined RC 578 Contents/RC can be viewed as a single large index into a single 579 table, etc.) 580 The FTIF Offset field indicates which FTIF is active. The active 581 FTIF is the one that is used to index the forwarding table indicated 582 by the RC Contents/RC. An FTIF Offset value of 0 means that the 583 first FTIF is active, an FTIF Offset value of 1 means that the second 584 FTIF is active, and so on. If there are no FTIFs, then the FTIF 585 Offset has no meaning, and can be any value. In this case, the RC 586 field itself will indicate how to forward the packet. 588 The FTIF Chain is padded out to a 32-bit boundary. Note that there 589 can be more than 16 bits of padding (for instance, if it is desirable 590 to pad out to a 64-bit boundary). The padding is ignored upon 591 receipt, and can be transmitted as any value (that is, it does not 592 have to be any specific pattern of 0's or 1's). 594 Note that a single "number" in the FTIF chain may in fact be more 595 than 16 bits in length. In this case, the number can be encoded as 596 multiple FTIFs with no loss of generality. It is only required that 597 in all cases a multiple FTIF number be distinguishable from a single 598 FTIF number. 600 2.2.6. Router RD Forwarding Algorithm 602 This section describes the forwarding algorithm for a Pip router. 604 1. Using the value of the RC field as an index, retrieve one of the 605 following instructions (steps 2 - 5) from the rcTable determined 606 by the RC Contents. 608 2. If the instruction is decapsulate, then decapsulate the Transit 609 Part and re-execute step 1 using the next Transit Part. 611 3. If the instruction is forward, then retrieve the associated For- 612 warding Information Block (FIB), and go to step 12. 614 4. If the instruction is to examine the Dest ID, then retrieve the 615 FIB associated with the Dest ID, and go to step 12. 617 5. If the instruction is to examine the FTIF Chain, then retrieve 618 the forwardingTable indicated by the rcTable entry, and continue 619 on to step 6. 621 6. Using the value of the currently active FTIF (this is the FTIF 622 indicated by the FTIF Offset if this is the first FTIF examined) 623 as an index, retrieve one or more of the following instructions 624 (steps 7 - 10) from the forwardingTable identified in step 5 or 625 step 10. 627 7. If the instruction is decapsulate, then decapsulate the Pip 628 header and re-execute step 1 using the new header (this is the 629 same as step 2). 631 8. If the instruction is forward, then (possibly additionally) 632 retrieve the associated FIB, and go to step 12 (this is the same 633 as step 3). 635 9. If the instruction is to examine the Dest ID, then retrieve the 636 FIB associated with the Dest ID and go to step 12 (this is the 637 same as step 4). 639 10. If the instruction is to examine the next FTIF, then, according 640 to the information in the current forwardingTable entry, modify 641 the current FTIF and choose a new forwardingTable. 643 11. Make the next FTIF the current FTIF and go to step 6. 645 12. The FIB contains a set of potential recipients for the Pip 646 packet, including next hop Pip systems (both directly connected 647 and at the end of Pip tunnels) and the upper layer of the local 648 system. Taking into consideration 1) the incoming interface, 2) 649 the previous hop Pip system if known (as determined by the 650 lower-layer source address and incoming interface), and 3) 651 potentially other local information (such as congestion on out- 652 going queues), prune the set of potential recipients. (This may 653 result in no pruning having taken place or in every potential 654 next hop having been pruned.) 656 13. For each remaining next hop, format a Pip header by modifying a) 657 the RC, b) the current FTIF, c) the FTIF Offset (to point to 1) 658 the FTIF pointed to in the received RD, 2) the current FTIF, 3) 659 the Nth FTIF counting from the 0th FTIF, or 4) the Nth FTIF 660 counting forwards or backwards from the current FTIF) and d) any 661 Pip header encapsulations, according to the information in the 662 FIB, and transmit the packet to the recipient (either a next hop 663 or upper layer). 665 2.3. Options Part 667 The Option Part is formatted as shown in Figure 4. 669 +===========================+ 670 | Options Descriptor | 64 671 +===========================+ 672 | Option 2 | Variable 673 +===========================+ 674 | Option 3 | Variable 675 +===========================+ 676 . 677 . 678 . 679 +===========================+ 680 | Option N | Variable 681 +===========================+ 683 Figure 4: Options Part 685 Every Option is at least one 32-bit word in length, and ends on a 686 32-bit word boundary. Because the type of each option is known from 687 the Options Contents field, there is no need to indicate the option 688 type in the options field themselves. Thus, there is no common for- 689 mat among the options--each option has its own format. The indivi- 690 dual options are defined in another specification. 692 2.3.1. Options Descriptor 694 The Options Descriptor option gives the offset of each option in the 695 Options Part. The Options Descriptor consists of eight eight-bit 696 Option Position fields, each of which gives the position of up to 697 eight options (there can be no more than 8 Options Part). Each of 698 the Option Position fields correspond to one of the bits in the 699 Options Present field. The unit of measure of each Option Position 700 is 32-bit words, counting the first word of the Options Part as word 701 0. The high order Option Position field corresponds to the high 702 order bit in the Options Present field.