File: rfc1622.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (899 lines) | stat: -rw-r--r-- 34,837 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899






Network Working Group                                         P. Francis
Request for Comments: 1622                                           NTT
Category: Informational                                         May 1994


                         Pip Header Processing

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Preamble

   During 1992 and 1993, the Pip internet protocol, developed at
   Bellcore, was one of the candidate replacments for IP.  In mid 1993,
   Pip was merged with another candidate, the Simple Internet Protocol
   (SIP), creating SIPP (SIP Plus).  While the major aspects of Pip--
   particularly its distinction of identifier from address, and its use
   of the source route mechanism to achieve rich routing capabilities--
   were preserved, many of the ideas in Pip were not.  The purpose of
   this RFC and the companion RFC "Pip Near-term Architecture" are to
   record the ideas (good and bad) of Pip.

   The remainder of this document is taken verbatem from the Pip draft
   memo of the same title that existed when the Pip project ended.  As
   such, any text that indicates that Pip is an intended replacement for
   IP should be ignored.

Abstract

   Pip is an internet protocol intended as the replacement for IP
   version 4.  Pip is a general purpose internet protocol, designed to
   handle all forseeable internet protocol requirements.  This
   specification defines the Pip header processing for Routers and
   Hosts.

Acknowledgements

   I want to individually acknowledge Rob Coltun, Steve Deering, Ramesh
   Govindan, Joel Halpern, John Ioannidis, Chris Petrilli, Bob Smart,
   and Zheng Wang.  I want also to acknowledge the many people from the
   Pip working group who have participated in developing Pip.  Finally,
   I want to acknowledge the SIP protocol (or, more accurately, the
   people behind the SIP protocol) for providing certain good ideas.





Francis                                                         [Page 1]

RFC 1622                 Pip Header Processing                  May 1994


Conventions

   All functions in this specification are mandatory.

1.  Introduction

   Pip is an internet protocol intended as the replacement for IP
   version 4.  Pip is a general purpose internet protocol, designed to
   handle all forseeable internet protocol requirements.  This
   specification defines the Pip header processing for Routers and
   Hosts.

   The design of Pip is fundamentally different from that of previous
   internetwork protocols.  Pip is designed to be as general as
   possible, but without significantly compromising performance.
   Because of Pip's generality, it can handle forseeable routing and
   addressing requirements.  It is hoped that it will be able to handle
   most if not all future routing and addressing requirements.

   There are many detailed aspects of Pip that provide this generality
   that are not discussed here.  It is useful, however, to mention one
   general aspect.  That is, Pip strives to remove as much "functional
   semantics" from the base specification as possible.  Pip defines a
   packet header and forwarding rules that can include many different
   functional semantics (that is, routing, addressing, and flow
   paradigms).  Therefore, the reader may often find him or herself
   asking "But how do you do foo with Pip?" The answer to this sort of
   question belongs in companion documents to the basic Pip spec.

   Pip can be thought of as a mechanism for triggering actions in hosts
   and routers, just as a machine language can be thought of as a
   mechanism for triggering actions in CPUs.  The machine language has
   no functional semantics outside of the specific actions it triggers
   (move this register, write that memory location, etc.).  But, the
   machine language is a very powerful tool upon which functional
   semantics are built.  Likewise, Pip is a powerful tool upon which
   routing, addressing, and flow functions can be built.














Francis                                                         [Page 2]

RFC 1622                 Pip Header Processing                  May 1994


2.  Pip Specification

   The Pip header is partitioned into three parts, the Initial Part, the
   Transit Part, and the Options Part.


           +===========================+
           |       Initial Part        |
           +===========================+
           |       Transit Part        |
           +===========================+
           |       Options Part        |
           +===========================+
           |                           |
           |         Payload           |
           |                           |


   Each part falls on a 32-bit boundary (as indicated by the double
   lines shown), and the Transit Part falls on a 64 bit boundary.

   The concept of tunneling in an integral part of Pip.  Pip achieves
   tunneling by encapsulating the Transit Part of the Pip header in
   another Transit Part.  Therefore, when tunneling, there is one
   Transit Part for each (nested) tunnel:


           +===========================+
           |       Initial Part        |
           +===========================+
           |       Transit Part        |
           +===========================+
           |       Transit Part        |
           +===========================+
                       .
                       .
                       .
           +===========================+
           |       Transit Part        |
           +===========================+
           |       Options Part        |
           +===========================+


   Because each Transit Part has only what is necessary for router
   forwarding and handling, this method of tunneling is reasonably
   efficient in terms of packet size.




Francis                                                         [Page 3]

RFC 1622                 Pip Header Processing                  May 1994


2.1  Initial Part

   The Initial Part is formatted as shown in Figure 1.

                                         length, in bits
           +===========================+
           |    Version Number = 8     |     4
           +---------------------------+
           |       Sub-Version         |     4
           +---------------------------+
           |      Options Offset       |     8
           +---------------------------+
           |     Options Contents      |     8
           +---------------------------+
           |     Options Present       |     8
           +===========================+
           |       Packet SubID        |     16
           +---------------------------+
           |         Protocol          |     16
           +===========================+
           |         Dest ID           |     64
           +===========================+
           |        Source ID          |     64
           +===========================+
           |      Payload Length       |     32
           +===========================+
           |       Host Version        |     8
           +---------------------------+
           |      Payload Offset       |     8
           +---------------------------+
           |        Hop Count          |     16
           +===========================+

                          Figure 1:  Initial Part

   An explanation of each field follows.

   2.1.1  Version Numbers

   The first octet is divided into two 4-bit fields, the Version and the
   Sub-Version.  The Version field is set to be 8, and is meant to be
   version 8 of IP.  (As of this writing, this is an experimental number
   assigned for development of Pip.) Thus, all encapsulation schemes
   defined for IP can work for Pip as well.

   As long as the Version field is 8, the Initial Part and Options Part
   of the Pip Header is as specified in this standard.  (In other words,
   the Sub-Version field refers only to the Transit Part.)



Francis                                                         [Page 4]

RFC 1622                 Pip Header Processing                  May 1994


   By doing this, we allow the Transit Part of the Pip Header to change
   completely without necessarily requiring a host to understand the new
   Transit Part.  If a host receives a Pip header with a Version number
   of 8 and an unknown Sub-version number, the host does not try to
   parse the Transit Part at all, rather it processes only the Initial
   Part and the Options Part.  (By using the Pip Header Protocol to
   format Pip Headers, a host can be made to formulate the right Transit
   Part, even though the host doesn't understand the semantics of the
   Transit Part.  This allows radical migration of the Transit Part
   while potentially not requiring changes to hosts.)

   If a host or a router receives a packet with an unknown Version
   number, the packet is silently discarded.

   The Sub-Version field is set to the value 0 for the version of Pip
   defined in this specification.  As long as the Sub-Version number is
   0, the Transit Part is as specified in this standard.  Any packet
   received by a router with a Version number of 8 and an unknown Sub-
   Version number is silently discarded.

   2.1.2  Options Offset

   The Options Offset indicates the position of the Options Part.  The
   unit of measure of the Options Offset is 32-bit words, counting the
   first word of the Pip Header as word 0.

   2.1.3  Options Contents

   This field indicates how the Options Present field should be
   interpreted.  Each bit of the Options field indicates if each of up
   to eight options is present in the Options Part.  The Options
   Contents field indirectly indicates which option each bit of the
   Options Present field refers to.  We say indirectly because the
   mapping referred to by the Options Contents field is stored locally.
   In other words, without additional information (the mapping), it is
   not possible to examine the Options Contents field and know what
   option each bit of the Options Present field refers to.

   Any of 256 possible Options Contents values can be active at a given
   time.  (Note that the means by which the meaning of the Options
   Contents values are assigned and conveyed to routers and hosts is
   outside the scope of this specification.)









Francis                                                         [Page 5]

RFC 1622                 Pip Header Processing                  May 1994


   2.1.4  Options Present

   This field indicates which of the Options indicated by the Options
   Contents field are actually present in the Options Part.  Each bit of
   this field refers to a single option type.  The mapping of each bit
   to its' option type is determined by the Options Contents field.

   For instance, assume that the Options Contents field indicates that
   bit 0 of the Options Present field refers to the PDN Address option,
   that bit 1 of the Options Present field refers to the foo option, and
   that bit 2 of the Options Present field refers to the Fragmentation
   option.  (As of this writing, there is only one option.  Until there
   are more than eight options, there is no need to define more than one
   Options Contents values.)

   In this case, a value of 101 in the Options Present field indicates
   that the PDN Address and Fragmentation options are present in the
   Options Part, and that the foo option is not present.

   Note that an Options Present value of 0 indicates that there are no
   options present, regardless of the value of the Options Contents
   field.  Note also that no more than 8 options, not including the
   default first option (the Options Descriptor), can be present in any
   Options Part.

   The Options Contents/Options Present method of processing options
   allows for efficient processing of options.  First, a router can
   ignore any options that may be present but that do not impact it (for
   instance, a router not attached to a PDN need not consider the PDN
   Address option).  Second, the desired option can be very quickly
   retrieved, because the first option, the Options Descriptor option,
   contains the offset of each of the up to eight options indicated by
   the Options Present field.

   2.1.5  Packet SubID

   This field is used by Pip hosts to correctly associate received PCMP
   messages with local control blocks.  This is necessary because the
   semantics of the Transit Part can change while a packet is in
   transit.  Therefore, a router sending a PCMP message cannot
   necessarily provide all of the information needed by the Pip host to
   correctly identify the context of the received message (that is,
   which "packet flow" it is identified with).

   A PCMP message uses the Protocol, Source ID, Dest ID, and Packet
   SubID to define the PCMP messages context.  It is not sufficient to
   use just Protocol, Source ID, and Dest ID, because two hosts running
   the same protocol between them may have multiple "flows", for



Francis                                                         [Page 6]

RFC 1622                 Pip Header Processing                  May 1994


   instance, a data flow, a video flow, and an audio flow in the case of
   multi-media.  Each flow may have a different Transit Part, and take
   different paths.  Therefore, the Packet SubID field is needed to
   further differentiate.

   2.1.6  Protocol

   Indicates the protocol header found in the payload.  The values for
   this field are the same as those used for IPv4.

   2.1.7  Dest ID

   The Dest ID field indicates the Pip ID of the final recipient of the
   Pip packet.  This field is examined by both hosts and routers.

   When a Pip System processes the Routing Directive (RD), it may
   determine that it needs to examine the Dest ID for further
   processing.  This may happen both when a host or router receives a
   Pip packet destined for itself, or when a router receives a packet
   that should be forwarded based on Dest ID (as indicated by the RD).

   When a Pip system determines at forwarding time that a packet is
   destined for itself, it checks the Dest ID to verify if that packet
   is destined for it.  If the complete Dest ID matches one of its own
   Pip IDs, then the packet is for it, and is passed to the layer
   indicated by the Protocol field (in the Host Part).  (The Pip system
   may of course wish to check a security option before passing a packet
   to an upper layer.)

   If the complete Dest ID field does not match one of its own IDs, then
   an ID/RD Mismatch PCMP message is sent to the source of the packet,
   as indicated by the Source ID and potentially source information in
   the RD.  The purpose of this message is to flush the ID to RD binding
   in the source Pip host.

   2.1.8  Source ID

   This is the Pip ID of the source of the packet.  It is passed to
   upper layers for the purposes of identifying the context for the
   packet.

   2.1.9  Payload Length

   The Payload Length gives the length of the Pip packet payload in
   units of 8 bits.  The Payload Length does not include the length of
   the Pip header.





Francis                                                         [Page 7]

RFC 1622                 Pip Header Processing                  May 1994


   2.1.10  Host Version

   The Host Version field indicates what "version" of Pip software the
   sending host has implemented.  This is to allow a host to inform a
   router which ancillary protocols/messages the host is able to accept.
   It is envisioned that over time, new host functions will be
   developed.  Different hosts will install these new functions at
   different times.  This field allows routers to know what functions
   the host can and cannot handle.

   2.1.11  Payload Offset

   The Payload Offset indicates the position of the Payload Part.  The
   unit of measure of the Payload Offset is 32-bit words, counting the
   first word of the Pip Header as word 0.

   If a Pip system encapsulates a Transit Part in another Transit Part,
   then the Payload Offset is increased by the length of the new Transit
   Part.

   2.1.12  Hop Count

   The Hop Count is decremented by every router that forwards the Pip
   packet.  If a system receives a Pip header with a Hop Count equal to
   0, and is not the recipient of the packet, then the packet is
   discarded and a PCMP Destination Unreachable is routed to the system
   indicated by the Routing Directive.  (In other words, a host can
   legally receive a Transit Part with a Hop Count of 0, and indeed a
   host doesn't look at the Hop Count field upon reception.)






















Francis                                                         [Page 8]

RFC 1622                 Pip Header Processing                  May 1994


2.2  Transit Part

   The Transit Part is formatted as shown in Figure 2.


                                         length, in bits
                   +===========================+
                   |         Reserved          |     16
                   +---------------------------+
                   |    Transit Part Offset    |     8
                   +---------------------------+
                   |        HD Contents        |     8
                   +===========================+
                   |  Handling Directive (HD)  |     32
    ---------------+===========================+
        ^          |        FTIF Offset        |     8
        |          +---------------------------+
        |          |        RC Contents        |     8
        |          +---------------------------+
        |          |   Routing Context (RC)    |     16
     Routing       +===========================+
                   |         FTIF 1            |     16
     Directive     +---------------------------+
        |          |         FTIF 2            |     16
        |          +---------------------------+
        |                       .
        |                       .
        |                       .
        |          +---------------------------+
        |          |         FTIF N            |     16
        |          +---------------------------+
        v          |         Padding           |     Variable
    ---------------+===========================+

                          Figure 2: Transit Part

   An explanation of each field follows.

   2.2.1  Transit Part Offset

   This field gives the position of the first word of the next Transit
   Part.  The unit of measure of the Transit Part Offset is 32-bit
   words, counting the first word of the current Transit Part as word 0.
   If there is no next Transit Part, then this field is written as all
   0's.






Francis                                                         [Page 9]

RFC 1622                 Pip Header Processing                  May 1994


   2.2.2  HD Contents

   The HD Contents field indicates how the Handling Directive (HD) field
   should be interpreted.  The HD field is divided into multiple fields,
   each representing a different handling function.  Each individual
   field in the HD is called an HD Unit (HDU).  The Options Contents
   field indirectly indicates which HDUs are in the HD field, and where
   they are.  We say indirectly because the mapping referred to by the
   HD Contents field is stored locally. In other words, without
   additional information (the mapping), it is not possible to examine
   the HD Contents field and know what the HDU locations are.

   Any of 256 possible HD Contents values can be active at a given time.
   (Note that the means by which the meaning of the HD Contents values
   are assigned and conveyed to routers and hosts is outside the scope
   of this specification.)

   2.2.3  Handling Directive (HD)

   The HD is a general purpose field used for the purpose of triggering
   special packet handling by a Pip system.  The HD field does not
   influence a Pip router's next hop choice for a Pip packet, nor does
   it influence a Pip host's determination as to whether the Pip packet
   is destined for it.  Examples of special packet handling would be
   "low priority queueing", or "high priority discard", etc.  (Note that
   the Transit Options also influence "handling", in the sense that
   handling is essentially defined here to mean "anything that is not
   routing.  The HD field, though, is intended for the most common types
   of handling--handling that is expected to be in a significant
   percentage of packets.)

   Both hosts and routers use the HD field.  (Hosts may make use of the
   HD field for packet handling for both incoming and outgoing packets.)

   There is a complete distinction between the syntax and the semantics
   of the HD field.  (This can be contrasted with, for instance, IP,
   which couples the semantics and syntax of the TOS bits.  That is, the
   IP specification itself determines, to a first degree, how the TOS
   bits are interpreted.) Each Pip system can modify the semantic
   meaning of the HD, for instance, by increasing or decreasing the
   queueing priority of a packet.  This is called packet tagging.

   From an abstract modeling perspective, the HD is handled as follows:

   1.  Extract the semantic meaning(s) (the handling instructions
       associated with the HDUs) from the HD field.  Transmitting Pip
       hosts determine the semantic meaning by some other means, such as
       the upper layer protocol.  If the receiving system decapsulates



Francis                                                        [Page 10]

RFC 1622                 Pip Header Processing                  May 1994


       multiple Pip headers, then the HD semantics are extracted from the
       lowest Pip header for which it is not the target (see example on
       tunneling below).

   2.  Handle the Pip packet according to those instructions.  In some
       cases, it is possible that the Pip system does not understand the
       semantics of one or more HDUs of the HD field.  For each HDU whose
       semantics are not understood, however, the pip system at least
       knows whether to 1) pass the HDU on untouched, 2) set it to all
       0s, 3) set it to all 1s, 4) discard the packet silently, or 5)
       discard the packet with a PCMP HDU Not Understood packet.

   3.  Modify the semantic meaning if necessary.  Note also that if the
       Pip packet is replicated for multicast, each packet has its HD
       semantics modified individually.  .LP .in 3 2.2.4 Tunneling .LP
       Consider two Pip systems, X and Y, separated by one or
       intermediate Pip systems.  X wishes to tunnel a Transit Part to Y.
       Y is therefore the target system of the tunnel.  A Transit Part He
       arrives at X.  In order to forward the Transit Part to Y, X
       encapsulates He in another Transit Part, Hy.  Y is the target
       system for Transit Part Hy.  X sets the HD of He to what it would
       have been if Y was directly connected to X (that is, there were no
       intermediate Pip systems between X and Y).  Further, it is
       intended that Y will derive its HD semantics from the HD of
       Transit Part He, not Transit Part Hy.  .sp .KS

        ----0-----o-----o-----o-----o-----0----
            X     I     J     K     L     Y

   Now consider the operation of Pip system L (the previous hop system
   to Y).  When L forwards the packet to Y, it may either decapsulate
   the packet (in the knowledge that Y is the target for Hy), or not
   decapsulate the packet.  Either way, L derives its HD semantics from
   the HD of Transit Part Hy.

   If L does not decapsulate the Transit Part, then it is as though I,
   J, K, and L are a "subnetwork" (albeit a Pip subnetwork), and Y is
   stripping the "subnetwork" header (Hy) off before processing the true
   Transit Part (He).  If L does decapsulate the Transit Part, then,
   from Y's perspective, it is essentially as though Y were directly
   connected to X.










Francis                                                        [Page 11]

RFC 1622                 Pip Header Processing                  May 1994


   2.2.5  Routing Directive (RD)

   The RD consists of the Routing Context (RC), the RC Contents, the
   FTIF Offset, and a series of zero or more FTIFs (Forwarding Table
   Index Fields).  This series of FTIFs is called the FTIF Chain.  The
   sole purpose of the RD is to determine how to forward the Pip
   packet--the RD does not influence handling in any way.


   Figure 3 illustrates the decision process for forwarding the Pip
   packet.

                 +---------+(next level RC)
    (decapsulate)|         |
                 |         v
                 |<--------RC----------------->FIB
                 |        /              |       |    IF Offset)
                 |       |     |
                 |       |     v
                 |<------|---FTIF------------->FIB
                 |       |  /  :
                 |       |<-   :(repeatedly...)
                 |       |     :
                 |       |     v
                 |<------|---FTIF------------->FIB
                         |  /  |
                         |<-   |
                         v     v
                          DestID-------------->FIB

                       Figure 3:  Forwarding Process


   Figure 3 is interpreted as follows.  The FIB is the Forwarding
   Information Block.  The FIB contains all the information needed to
   forward a packet, and may contain multiple next hop (for multicast).
   This information includes 1) the outgoing interface, 2) how to
   encapsulate the packet, including lower-layer address(es) (the
   lower-layer address(es) along with the outgoing interface determine
   the next hop Pip system), 3) whether and how to tunnel, 4) how to
   modify the semantics of the HD and RC, and how to modify the FTIF
   Offset.  The goal of the forwarding algorithm is to reach the
   appropriate FIB.

   The directed lines in Figure 3 start at the RC and, through various
   possible paths, reach a FIB.  These lines represent the various
   information that can influence the forwarding decision (that is, the
   FIB chosen).  For instance, there is no way to reach a FIB without



Francis                                                        [Page 12]

RFC 1622                 Pip Header Processing                  May 1994


   first examining the information in the RC.  However, it is possible
   to identify a FIB by considering only the information in the RC (as
   indicated by the directed line leading directly right from the RC).
   Based on the information in the RC, it is also possible to determine
   that the Transit Part must be decapsulated, and 1) the RC of the next
   Transit Part be processed (the line leading directly left), 2) the
   FTIF indicated by the FTIF Offset is processed (the line leading down
   and right), or 3) the Dest ID is processed (the line leading down and
   lest).

   Likewise, when considering the value of an FTIF (in addition to all
   information already considered), the resulting action may be that 1)
   a FIB is identified, 2) the Transit Part is decapsulated, 3) the
   subsequent FTIF is processed, or 4) the Dest ID is processed.

   The RC is handled similarly to the HD.  The RC Contents field
   indicates how the RC should be interpreted.  While the RC is
   constructed similarly to the HD in the sense that it consists of
   multiple fields, the RC can be interpreted as a flat field in-so-far
   as forwarding a Pip packet is concerned, whereas the HD cannot.

   Thus, in a mechanical sense, the RC Contents can be viewed as an
   index into a table that returns a pointer to another table (an
   rcTable), which is indexed by the RC itself.  (Or, the combined RC
   Contents/RC can be viewed as a single large index into a single
   table, etc.)

   The FTIF Offset field indicates which FTIF is active.  The active
   FTIF is the one that is used to index the forwarding table indicated
   by the RC Contents/RC.  An FTIF Offset value of 0 means that the
   first FTIF is active, an FTIF Offset value of 1 means that the second
   FTIF is active, and so on.  If there are no FTIFs, then the FTIF
   Offset has no meaning, and can be any value.  In this case, the RC
   field itself will indicate how to forward the packet.

   The FTIF Chain is padded out to a 32-bit boundary.  Note that there
   can be more than 16 bits of padding (for instance, if it is desirable
   to pad out to a 64-bit boundary).  The padding is ignored upon
   receipt, and can be transmitted as any value (that is, it does not
   have to be any specific pattern of 0's or 1's).

   Note that a single "number" in the FTIF chain may in fact be more
   than 16 bits in length.  In this case, the number can be encoded as
   multiple FTIFs with no loss of generality.  It is only required that
   in all cases a multiple FTIF number be distinguishable from a single
   FTIF number.





Francis                                                        [Page 13]

RFC 1622                 Pip Header Processing                  May 1994


   2.2.6  Router RD Forwarding Algorithm

   This section describes the forwarding algorithm for a Pip router.

   1.  Using the value of the RC field as an index, retrieve one of the
       following instructions (steps 2 - 5) from the rcTable determined
       by the RC Contents.

   2.  If the instruction is decapsulate, then decapsulate the Transit
       Part and re-execute step 1 using the next Transit Part.

   3.  If the instruction is forward, then retrieve the associated
       Forwarding Information Block (FIB), and go to step 12.

   4.  If the instruction is to examine the Dest ID, then retrieve the
       FIB associated with the Dest ID, and go to step 12.

   5.  If the instruction is to examine the FTIF Chain, then retrieve the
       forwardingTable indicated by the rcTable entry, and continue on to
       step 6.

   6.  Using the value of the currently active FTIF (this is the FTIF
       indicated by the FTIF Offset if this is the first FTIF examined)
       as an index, retrieve one or more of the following instructions
       (steps 7 - 10) from the forwardingTable identified in step 5 or
       step 10.

   7.  If the instruction is decapsulate, then decapsulate the Pip header
       and re-execute step 1 using the new header (this is the same as
       step 2).

   8.  If the instruction is forward, then (possibly additionally)
       retrieve the associated FIB, and go to step 12 (this is the same
       as step 3).

   9.  If the instruction is to examine the Dest ID, then retrieve the
       FIB associated with the Dest ID and go to step 12 (this is the
       same as step 4).

   10.  If the instruction is to examine the next FTIF, then, according
        to the information in the current forwardingTable entry, modify
        the current FTIF and choose a new forwardingTable.

   11.  Make the next FTIF the current FTIF and go to step 6.

   12.  The FIB contains a set of potential recipients for the Pip
        packet, including next hop Pip systems (both directly connected
        and at the end of Pip tunnels) and the upper layer of the local



Francis                                                        [Page 14]

RFC 1622                 Pip Header Processing                  May 1994


        system.  Taking into consideration 1) the incoming interface, 2)
        the previous hop Pip system if known (as determined by the
        lower-layer source address and incoming interface), and 3)
        potentially other local information (such as congestion on
        outgoing queues), prune the set of potential recipients.  (This
        may result in no pruning having taken place or in every potential
        next hop having been pruned.)

   13.  For each remaining next hop, format a Pip header by modifying a)
        the RC, b) the current FTIF, c) the FTIF Offset (to point to 1)
        the FTIF pointed to in the received RD, 2) the current FTIF, 3)
        the Nth FTIF counting from the 0th FTIF, or 4) the Nth FTIF
        counting forwards or backwards from the current FTIF) and d) any
        Pip header encapsulations, according to the information in the
        FIB, and transmit the packet to the recipient (either a next hop
        or upper layer).

   2.3  Options Part

   The Option Part is formatted as shown in Figure 4.


           +===========================+
           |    Options Descriptor     |     64
           +===========================+
           |        Option 2           |     Variable
           +===========================+
           |        Option 3           |     Variable
           +===========================+
                       .
                       .
                       .
           +===========================+
           |        Option N           |     Variable
           +===========================+


                          Figure 4: Options Part

   Every Option is at least one 32-bit word in length, and ends on a
   32-bit word boundary.  Because the type of each option is known from
   the Options Contents field, there is no need to indicate the option
   type in the options field themselves.  Thus, there is no common
   format among the options--each option has its own format.  The
   individual options are defined in another specification.






Francis                                                        [Page 15]

RFC 1622                 Pip Header Processing                  May 1994


   2.3.1  Options Descriptor

   The Options Descriptor option gives the offset of each option in the
   Options Part.  The Options Descriptor consists of eight eight-bit
   Option Position fields, each of which gives the position of up to
   eight options (there can be no more than 8 Options Part).  Each of
   the Option Position fields correspond to one of the bits in the
   Options Present field.  The unit of measure of each Option Position
   is 32-bit words, counting the first word of the Options Part as word
   0.  The high order Option Position field corresponds to the high
   order bit in the Options Present field.

Security Considerations

   Security issues are not discussed in this memo.

Author's Address

   Paul Francis
   NTT Software Lab
   3-9-11 Midori-cho Musashino-shi
   Tokyo 180 Japan

   Phone: +81-422-59-3843
   Fax +81-422-59-3765
   EMail: francis@cactus.ntt.jp

























Francis                                                        [Page 16]