File: rfc2129.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 (1067 lines) | stat: -rw-r--r-- 41,137 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
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067






Network Working Group                                          K. Nagami
Request for Comments: 2129                                    Y. Katsube
Category: Informational                                     Y. Shobatake
                                                                 A. Mogi
                                                            S. Matsuzawa
                                                               T. Jinmei
                                                                H. Esaki
                                                      Toshiba R&D Center
                                                              April 1997


  Toshiba's Flow Attribute Notification Protocol (FANP) Specification

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.

Abstract

   This memo discusses Flow Attribute Notification Protocol (FANP),
   which is a protocol between neighbor nodes for the management of
   cut-through packet forwarding functionalities. In cut-through packet
   forwarding, a router doesn't have to perform conventional IP packet
   processing for received packets.  FANP indicates mapping information
   between a datalink connection and a packet flow to the neighbor node
   and helps a pair of nodes manage the mapping information.  By using
   FANP, routers (e.g., CSR; Cell Switch Router) can forward incoming
   packets based on their datalink-level connection identifiers,
   bypassing usual IP packet processing.  The design policy of the FANP
   is;

       (1)  soft-state cut-through path (Dedicated-VC) management
       (2)  protocol between neighbor nodes instead of end-to-end
       (3)  applicable to any connection oriented datalink platform

1.  Background

   Due to the scalability requirement, connection oriented (CO) datalink
   platforms, e.g., ATM and Frame Relay, are going to be used as well as
   connection less (CL) datalink platforms, e.g., Ethernet and FDDI.
   One of the important features of the CO datalink is the presence of a
   datalink-level connection identifier.  In the CO datalink, we can
   establish multiple virtual connections (VCs) with their VC
   identifiers among the nodes. When we aggregate packets that have the
   same direction (e.g., having the same destination IP address) into a
   single VC, we can forward the packets in the VC without IP



Nagami, et. al.              Informational                      [Page 1]

RFC 2129                   FANP Specification                 April 1997


   processing.  With this configuration, routers can decide which node
   is the next-hop for the packets based on the VC identifier.  CSRs [1]
   can forward the incoming packets using an ATM switch engine bypassing
   the conventional IP processing.  According to the ingress VPI/VCI
   value with ingress interface information, CSR determines the egress
   interface and egress VPI/VCI value.

   In order to configure the cut-through packet forwarding state, a pair
   of neighbor nodes have to share the mapping information between the
   packet flow and the datalink VC.  FANP (Flow Attribute Notification
   Protocol) described in this memo is the protocol to configure and
   manage the cut-through packet forwarding state.

2.  Protocol Requirements and Future Enhancement

2.1 Protocol Requirements

   The followings are the protocol requirements for FANP.

   (1) Applicable to various types of CO datalink platforms

   (2) Available with various connection types (i.e., SVC, PVC, VP)

   (3) Robust operation
       The system should operate correctly even under the following
       conditions.

        (a) VC failure
            Some systems can detect VC failure as the function of
            datalink (e.g., OAM function in the ATM).  However, we can
            not assume all nodes in the system can detect VC failure.
            The system has to operate correctly, assuming that every
            node can not detect VC failure.

        (b) Message loss
            Control messages in the FANP may be lost.  The system has to
            operate correctly, even when some control messages are lost.

        (c Node failure
            A node may be down without any explicit notification to its
            neighbors.  The system has to operate correctly, even with
            node failure.

   Though FANP is not the protocol only for ATM, the following
   discussion assumes that the datalink is an ATM network.






Nagami, et. al.              Informational                      [Page 2]

RFC 2129                   FANP Specification                 April 1997


2.2  Future Enhancement

   The followings are the future enhancements to be done.

        (1) Aggregated flow

          In this memo, we define the flow which contain source and
          destination IP address.  As this may require many VC
          resources, we also need a new definition of aggregated flow
          which includes several end-to-end flows.  The concrete
          definition of the aggregated flow is for future study.

        (2) Providing multicast service
        (3) Supporting IP level QOS signaling like RSVP
        (4) Supporting IPv6

3. Terminology and Definition

   o VCID (Virtual Connection IDentifier)
      Since VPI/VCI values at the origination and the termination points
      of a VC (and VP) may not be the same, we need an identifier to
      uniquely identify the datalink connection between neighbor nodes.
      We define this identifier as a VCID.  Currently, only one type of
      VCID is defined.  This VCID contains the ESI (End System
      Identifier) of a source node and the unique identifier within a
      source node.

   o Flow ID (Flow IDentifier)
      IP level packet flow is identified by some parameters in a packet.
      Currently, only one type of flow ID is defined.  This flow ID
      contains a source IP address and a destination IP address.  Note
      that flow ID used in this specification is not the same as the
      flow-id specified in IPv6.

   o Cut-through packet forwarding
      Packets are forwarded without any IP processing at the router
      using the datalink level information (e.g.,VPI/VCI).
      Internetworking level information (e.g., destination IP address)
      is mapped to the corresponding datalink-level identifier by using
      the FANP.

   o Hop-by-Hop packet forwarding
      Packets are forwarded using IP level information like conventional
      routers.  In ATM, cells are re-assembled into packets at the
      router to analyze the IP header.






Nagami, et. al.              Informational                      [Page 3]

RFC 2129                   FANP Specification                 April 1997


   o Default-VC
      Default-VC is used for hop-by-hop packet forwarding.  Cells
      received from the Default-VC are reassembled into IP packets.
      Conventional IP processing is performed for these packets.  The
      encapsulation over the Default-VC is LLC for routed non-ISO
      protocols defined by RFC1483 [3].

   o Dedicated-VC
      Dedicated-VC is used for the specific IP packet flow identified by
      the flow-ID.  When the flow-ID for an incoming VC and an outgoing
      VC are the same at a CSR, it can forward the packets belonging to
      the flow through the cut-through packet forwarding.  The
      encapsulation over the Dedicated-VC is LLC for routed non-ISO
      protocols defined by RFC1483 [3].

   o Cut-through trigger
      When a FANP capable node receives a trigger packet, it tries to
      establish Dedicated-VC and to notify the mapping information
      between the Dedicated-VC and the IP packet flow which the received
      trigger packet belongs to.  Trigger packets are defined by the
      port-ID of TCP/UDP with the local policy of each FANP capable
      node.  In general, they would be the port-ID's of sessions with a
      long life-time and/or with large amount of packets; e.g., http,
      ftp and nntp.  Future implementation will include other triggers
      such as an arrival of resource reservation request.

4. Protocol Overview

   Figure 1 shows an operational overview of FANP.  In the figure, a
   cut-through packet forwarding path is established from host 1 (H1) to
   host 2 (H2) using two Dedicated-VCs.  H1 and H2 are connected to
   Ethernets, and R1, R2 and R3 are routers which can speak FANP.  R1
   and R3 have both an ATM interface and an Ethernet interface.  R2 has
   two ATM interfaces.

   When R1 receives an IP packet from H1, R1 analyzes the payload of the
   received IP packet whether it is a trigger packet or not.  When the
   received packet is a trigger packet, R1 fetches a Dedicated-VC to its
   downstream neighbor(R2) and sends FANP messages.  FANP is effective
   between the neighboring nodes only.  The same procedure would be
   performed between R2 and R3 independently from the procedure between
   R1 and R2.  The flow-ID of the packet flow from H1 to H2 is
   represented as id(H1,H2).  Here, id(H1,H2) is the set of the IP
   address of H1 and that of H2.







Nagami, et. al.              Informational                      [Page 4]

RFC 2129                   FANP Specification                 April 1997


   The Dedicated-VC is released when no packet is transferred on it for
   a given period.  We do not need to explicitly indicate release of the
   Dedicated-VC to the neighbor node, since the state management in FANP
   is of soft-state, rather than of hard-state.

    +--+ Ethernet +--+   +-----+   +--+   +-----+   +--+ Ethernet +--+
    |H1|----------|R1|---| ATM |---|R2|---| ATM |---|R3|----------|H2|
    +--+          +--+   +-----+   +--+   +-----+   +--+          +--+
       trigger pkt
       |----------> trigger packet
                    |------------->   trigger packet
                       FANP          |-------------->  trigger pkt
                    <=============>        FANP        |----------->
                                     <==============>

                    |=============|
                     Dedicated-VC    |==============|
                                       Dedicated-VC

             Figure 1. Trigger packet and FANP initiation

5. Protocol Sequence

   FANP has the following five procedures, that are (1) Dedicated-VC
   selection, (2) VCID negotiation, (3) flow-ID notification, (4)
   Dedicated-VC refresh and (5) Dedicated-VC release.  Procedures (2),
   (3) and (4) have nothing to do with the kind of the Dedicated-
   VC;i.e.,SVC,PVC or VP.  On the contrary, the procedures (1) and (5)
   with SVC are different from the procedures with PVC and with VP.

   The detailed procedures are described in the following subsections.

5.1 Dedicated-VC Selection Procedure

   A VC is picked up in order to use as a Dedicated-VC.  The ways of
   picking up the Dedicated-VC is either of the followings.

   (1) A number of VCs are prepared in advance, and registered into an
      un-used VC list.  When a Dedicated-VC is needed, one of them is
      picked up from the un-used VC list.

   (2) A new VC is established through ATM signaling on demand.

   With ATM PVC/VP configuration, a Dedicated-VC is activated by the
   procedure (1).






Nagami, et. al.              Informational                      [Page 5]

RFC 2129                   FANP Specification                 April 1997


   With ATM SVC configuration, a Dedicated-VC is activated by the
   procedure (1) or (2).  When the procedure (1) is used, some number of
   VCs are prepared in advance through ATM signaling.  These VCs are
   registered into the un-used VC list.  When a Dedicated-VC is needed,
   a VC is picked up from the un-used VC list.  When the procedure (2)
   is used, a Dedicated-VC is established through ATM signaling each
   time it is required.

   The procedure (1) can decrease a time to activate a Dedicated-VC.
   But the necessary VC resource will increase as it need to prepare
   additional VCs.  Which procedure should be applied to is a matter of
   local decision in each node, taking the economical requirement and
   the system responsiveness into account.

   A Dedicated-VC is used as a uni-directional VC, although it is
   generally bi-directional.  This means that packets are transferred
   only from upstream node to downstream node in the Dedicated-VC. The
   packets from downstream node to upstream node are transferred through
   the Default-VC or through another Dedicated-VC.

5.2 VCID Negotiation Procedure

   After the Dedicated-VC selection procedure, the upstream node
   transmits the PROPOSE message to the downstream node through the
   Dedicated-VC.  The PROPOSE message contains a VCID for the
   Dedicated-VC and IP address (target IP address) of downstream node.
   When the downstream node accepts the PROPOSE message, it transmits
   the PROPOSE ACK message to the upstream node through the Default-VC.
   With this procedure, the upstream and the downstream nodes (both
   end-points of the Dedicated-VC) can share the same indicator "VCID"
   for the Dedicated-VC.  When the downstream node can not accept the
   proposal from the upstream node with some reason (e.g., policy), the
   downstream node sends an ERROR message to the upstream node through
   the Default-VC.

   The procedure at the downstream node which has received PROPOSE
   message is;

    1. if(Target IP address of the PROPOSE message isn't equal to my IP
          address)
       then Goto end.

    2. if(The PROPOSE message should be refused)
       then  Send an ERROR(refuse by policy) message. Go to end.

    3. if(VCID Type in the PROPOSE message isn't known)
       then Send an ERROR(unknown VCID Type) message. Go to end.




Nagami, et. al.              Informational                      [Page 6]

RFC 2129                   FANP Specification                 April 1997


    4. if(The VCID in the PROPOSE message is  the same as the VCID which
       has already been registered for another Dedicated-VC in the node)
       then Delete the registered VCID.
       Release the old Dedicated-VC.

    5. if(A VCID is registered for the Dedicated-VC which has received
       the PROPOSE message)
       then Delete the registered VCID.

    6. Register the mapping between VCID and  I/F, VPI, VCI for the
       Dedicated-VC.

    7. if(The mapping is successful)
       then Send a PROPOSE ACK.
       else Send an ERROR(resource unavailable).

   The upstream node retransmits the PROPOSE message when it neither
   receive PROPOSE ACK message nor ERROR message.  When the upstream
   node has received neither of the messages even with five
   retransmissions of the PROPOSE message, the Dedicated-VC picked up
   through the Dedicated-VC selection procedure should be released.
   Here, the number of retransmissions (five in this specification)is
   recommended value and can be modified in the future.

   The purpose of the VCID negotiation procedure is not only to share
   the VCID information regarding the Dedicated-VC, but also to confirm
   whether the Dedicated-VC is available and whether the neighbor node
   operates correctly.

   If the VCID negotiation procedure with a neighbor node always fails,
   it is considered that the node may not be FANP-capable node.
   Therefore the upstream node should not try the VCID negotiation
   procedure to that node for a certain time period.

5.3 Flow-ID Notification Procedure

   After the VCID negotiation procedure, the upstream node transmits an
   OFFER message to the downstream node through the Default-VC.  The
   OFFER message contains the VCID of the Dedicated-VC, the flow-ID of
   the packet flow transferred through the Dedicated-VC and the refresh
   interval of a READY message.

   When the downstream node receives the OFFER message from the upstream
   node, it transmits the READY message to the upstream node through the
   Default-VC in order to indicate that the OFFER message issued by the
   upstream node is accepted.  By the reception of the READY message,
   the upstream node realizes that the downstream node can receive IP
   packets transferred through the Dedicated-VC.



Nagami, et. al.              Informational                      [Page 7]

RFC 2129                   FANP Specification                 April 1997


   The upstream node retransmits the OFFER message when it does not
   receive a READY message from the downstream node.  When the upstream
   node has not receive a READY message even with five retransmissions,
   the Dedicated-VC should be released.  Here, the number of
   retransmissions (i.e., five in this specification) is a recommended
   value and may be modified in the future.

   The node transmits an ERROR message to its neighbor in the following
   cases.  When the node receives the ERROR message, the Dedicated-VC
   should be released.

    (a) unknown VCID: The VCID in the message is unknown.
    (b) unknown VCID Type: The VCID Type is unknown.
    (c) unknown flow-ID Type: the flow-ID Type is unknown.

   When the downstream node accepts the OFFER message from the upstream
   node, it must send a READY message to the upstream node within the
   refresh interval offered by the upstream node.  If it can not, the
   downstream node sends the ERROR message (this refresh interval is not
   supported) to the upstream node.  The downstream node should accept
   the refresh interval larger than 120 seconds.  Therefore the
   downstream node shouldn't send the ERROR message (this refresh
   interval is not supported) when the refresh interval in the OFFER
   message is larger than 120 seconds.

   The following describes the procedure of the node which has received
   an OFFER message.

    1. if(unknown version in the OFFER message)
       then Discard the message.  Goto end.

    2. if(unknown VCID Type in the OFFER message)
       then Send an ERROR (unknown VCID Type) message.  Goto end.

    3. if(VCID in the OFFER message has not been registered)
       then Send an ERROR (unknown VCID) message.  Goto end.

    4. if(unknown Flow ID Type in the OFFER message)
       then Send an ERROR (unknown Flow ID Type) message.  Goto end.

    5. if(refuse Flow ID in the OFFER message)
       then Send an ERROR (refused by policy) message.  Goto end.

    6. if(refuse refresh interval in the OFFER message)
       then Send an ERROR(This refresh interval is not supported)
       message.  Goto end.





Nagami, et. al.              Informational                      [Page 8]

RFC 2129                   FANP Specification                 April 1997


    7. if(the mapping between Flow ID and VCID already exists and
          Flow ID in the OFFER message is different from the registered
          Flow ID for the corresponding VCID)
       then Do Flow-ID removal procedure.  Goto end.

    8. Do the procedure of receiving the OFFER message.

    7. if(successful)
       then Send a READY message.
       else Send an ERROR (resource unavailable) message.

    8. end.

   The procedure of the node which has received a READY message is
   described.

    1. if(unknown version in the READY message)
       then Discard the message.  Goto end.

    2. if(unknown VCID Type in the READY message)
       then Send an ERROR (unknown VCID Type) message.  Goto end.

    3. if(VCID in the READY message has not been registered)
       then Send an ERROR (unknown VCID) message.  Goto end.

    4. if(unknown Flow ID Type in the READY message)
       then Send an ERROR (unknown Flow ID Type) message.  Goto end.

    5. if((the mapping between Flow ID and VCID doesn't exist)||
          (the mapping between Flow ID and VCID already exists and
           Flow ID in the READY message is different from registered Flow
           ID for the corresponding VCID))
       then Send an ERROR (unknown VCID) message.  Goto end.

    6. Do the procedure of receiving the READY message.

    7. end.

5.4 Flow ID Refresh Procedure

   While the downstream node receives IP packets through the Dedicated-
   VC, it should periodically (with a refresh interval) send the READY
   message to the upstream node.  When the downstream node does not
   receive any IP packet during the refresh interval, it does not send
   the READY message to the upstream node.






Nagami, et. al.              Informational                      [Page 9]

RFC 2129                   FANP Specification                 April 1997


   While the upstream node continues to receive READY messages, it
   realizes that it can transmit the IP packets through the Dedicated-
   VC.  When it does not receive a READY message at all for a
   predetermined period (dead interval), it removes the mapping between
   the Flow IP and VCID.  The dead interval is defined below.

   When the upstream node falls into failure without the Flow ID removal
   procedure for a Dedicated-VC, its mapping must be removed by the
   downstream node.  The downstream node removes the mapping between the
   Flow ID and VCID for the Dedicated-VC when it does not receive any IP
   packet for a "removal period" (=refresh interval times m).

   The refresh interval, the dead interval and the removal period should
   satisfy the following equation.

    refresh interval < dead interval < removal period (=refresh
    interval times m)

    The recommended values are:
        refresh interval =  2 minutes
        dead interval    =  6 minutes (=refresh interval x 3)
        removal period  = 20 minutes (=refresh interval x 10)

5.5 Flow ID Removal Procedure

   When the upstream node realizes that the Dedicated-VC is not used, it
   performs a Flow ID removal procedure.

   The Flow ID removal procedure differs between the case of PVC/VP
   configuration and the case of SVC configuration.

   With the PVC/VP configuration, the upstream node issues a REMOVE
   message to the downstream node, and the downstream node sends back a
   REMOVE ACK message to the upstream node.  The upstream node
   retransmits REMOVE messages when it does not receive a REMOVE ACK
   message.  The upstream node assumes that the downstream node is in
   failure state when it dose not receive any REMOVE ACK message from
   the downstream node even with five REMOVE message retransmissions.













Nagami, et. al.              Informational                     [Page 10]

RFC 2129                   FANP Specification                 April 1997


   With SVC configuration, two procedures are possible.  One is that the
   mapping between the Flow ID and the VCID is removed without the
   release of the ATM connection, which is the same procedure as the
   PVC/VP configuration.  The other procedure is that the mapping
   between the Flow ID and the VCID is removed by releasing the VC
   through ATM signaling.  The former procedure can promptly create and
   delete the mapping between Flow ID and VCID, since the ATM signaling
   does not have to be performed each time.  However, an un-used ATM
   connections have to be maintained by the node.  Which procedure is
   applied to is a matter of each CSR's local decision, taking the VC
   resource cost and responsiveness into account.

   The downstream node may want to remove the mapping between the Flow
   ID and the VCID.  When the upstream node receives the REMOVE message,
   it sends a REMOVE ACK message to the downstream node.

             +--+                              +--+
             |R1|------------------------------|R2|
             +--+                              +--+
               |           PROPOSE              |
               |===============================>|
      VCID     |       [VCID, target IP]        |
  negotiation  |          PROPOSE ACK           |
               |<===============================|
               |            [VCID]              |
               |                                |
               |            OFFER               |
               |===============================>|
     Flow-ID   |       [VCID, flow-ID]          |
  notification |            READY               |
               |<===============================|
               |       [VCID, flow-ID]          |
               |                                |
                    :         :           :
                    :         :           :
               |           READY                |
               |<===============================|
  Dedicated-VC |       [VCID, flow-ID]          |
  refresh      |           READY                |
               |<===============================|
               |       [VCID, flow-ID]          |

          Figure 2. Flow ID notification and refresh procedure








Nagami, et. al.              Informational                     [Page 11]

RFC 2129                   FANP Specification                 April 1997


             +--+                              +--+
             |R1|------------------------------|R2|
             +--+                              +--+
               |                                 |
               |             REMOVE              |
               |================================>|
               |             [VCID]              |
               |                                 |
               |           REMOVE ACK            |
               |<================================|
               |             [VCID]              |

          (a) Flow ID removal (independent of ATM signaling)

             +--+                              +--+
             |R1|------------------------------|R2|
             +--+                              +--+
               |          ATM signaling          |
               |           (release)             |
               |<===============================>|
               |                                 |

            (b) Flow ID removal through ATM signaling

             Figure 3.  Flow ID removal procedure

6. Message Format

   FANP control procedure includes seven messages described from 6.2 to
   6.8.  Among them, a PROPOSE message used for VCID negotiation
   procedure uses an extended ATM ARP message format defined in RFC1577
   [2].  The other messages are encapsulated into IP packets.

   The destination IP address in the IP packet header signifies the
   neighbor node's IP address and the source IP address signifies
   sender's IP address.  Currently, the protocol ID for these messages
   is 110(decimal).  This protocol ID must be registered by IANA.

   The reserved field in the following packet format must be zero.












Nagami, et. al.              Informational                     [Page 12]

RFC 2129                   FANP Specification                 April 1997


6.1 Field Format

6.1.1 VCID field

   VCID type value decides VCID field format.  Currently, only type "1"
   is defined.  The VCID field format of VCID type 1 is shown below.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    ESI of upstream node                       |
    +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                               |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
    |                              ID                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       ESI field: ESI of upstream node
       ID       : upstream node decides unique identifier.

6.1.2 Flow ID field

   Flow ID type value decides flow-ID field format.  Currently, flow-ID
   type "0" and "1" are defined.  The flow ID type value "0" signifies
   that the flow ID field is null.  When flow ID type value is "1", the
   format shown below is used.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                   Source IP address                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                   Destination IP address                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Source IP address      : source IP address of flow
       Destination IP address : destination IP address of flow

6.2 PROPOSE message

   PROPOSE message uses the extended ATM-ARP message format [2] to which
   the VCID type and the VCID field are added.  Type & Length fields are
   set to zero, because the messages don't need sender/target ATM
   address.  This message is transferred from the upstream node to the
   downstream node through the Dedicated-VC.

   PROPOSE message is transferred from the upstream node to the
   downstream node through the Dedicated-VC.



Nagami, et. al.              Informational                     [Page 13]

RFC 2129                   FANP Specification                 April 1997


     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Hardware Type = 0x13          |  Protocol Type = 0x0800       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Type&Length 1 | Type&Length 2 |      Opereation Code          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Length 1   | Type&Length 3 | Type&Length 4 |   Length 2    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Sender IP Address                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Target IP Address                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   VCID Type   |VCID Length    |       Reserved                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        VCID                                   |
    /                                                               /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Type&Length 1 ; Type & Length of sender ATM number = 0
    Type&Length 2 ; Type & Length of sender ATM subnumber = 0
    Type&Length 3 ; Type & Length of sender ATM number = 0
    Type&Length 4 ; Type & Length of sender ATM subnumber =0
    Length 1      ; Source IP address length
    Length 2      ; Target IP address length

    Operation code
             0x10 = PROPOSE

    VCID Type:   Currently , VCID Type = 1 is defined.
    VCID Length: Length of VCID field
    VCID :       VCID described previous

6.3 PROPOSE ACK

   PROPOSE ACK messages is transferred through the Default-VC.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Version       |Op code = 1    |        Checksum               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | VCID type     |Flow-ID type=0 |         Reserved              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           VCID                                |
    /                                                               /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Nagami, et. al.              Informational                     [Page 14]

RFC 2129                   FANP Specification                 April 1997


    Version
        This field indicates the version   number of FANP.    Currently,
        Version = 1

    Operation Code

        This field  indicates the operation code   of the message. There
        are five operation codes, below.

        operation code = 1 : PROPOSE ACK message

    Checksum
        This field is the 16 bits checksum for whole body of FANP message.
        The checksum algorithm is same as the IP header.

    VCID Type
        This field indicates the VCID type.  Currently, only "1" is
        defined.

6.4 OFFER message

   OFFER message is transferred from an upstream node to a downstream
   node.  The following is the message format.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Version = 1   | Op Code = 2   |        Checksum               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | VCID type     |Flow-ID type   |     Refresh Interval          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           VCID                                |
    /                                                               /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Flow-ID                               |
    /                                                               /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Refresh Interval
        This field indicates the interval of refresh timer.  The refresh
        interval is represented by second in integer.  This field is
        used only in OFFER message.  Recommended value is 120 (second).









Nagami, et. al.              Informational                     [Page 15]

RFC 2129                   FANP Specification                 April 1997


6.5 READY message

   READY message is transfered from a downstream node to an upstream
   node. This message is transferred when the downstream node receives
   OFFER message. And this message is transferred periodically in each
   refresh interval. The following is the message format.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Version = 1   | Op Code = 3   |        Checksum               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | VCID type     |Flow-ID type   |     Reserved                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           VCID                                |
    /                                                               /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Flow-ID                               |
    /                                                               /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6.6 ERROR message

   ERROR message is transfered from a downstream node to an upstream
   node or from an upstream node to a downstream node. This message is
   transferred when some of the fields in the receive message is unknown
   or refused.  When the receive message is the ERROR message, ERROR
   message isn't sent.  VCID type ,VCID, Flow ID Type and Flow ID field
   in the ERROR message are filled with the same field in the receive
   message.

   The following is the message format.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Version = 1   | Op Code = 4   |        Checksum               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | VCID type     |Flow-ID type   |     Error code                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           VCID                                |
    /                                                               /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Flow-ID                               |
    /                                                               /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





Nagami, et. al.              Informational                     [Page 16]

RFC 2129                   FANP Specification                 April 1997


    Error Code = 1 : unknown VCID type
               = 2 : unknown Flow-ID type
               = 3 : unknown VCID
               = 4 : resource is unavailable
               = 5 : unavailable refresh interval is offered
               = 6 : refuse by policy

6.7 REMOVE message

   REMOVE message is transfered from a downstream node to an upstream
   node or vice versa.  This message is transferred to remove the
   mapping relationship between the flow ID and and the VCID. The node
   which receives REMOVE message must send REMOVE ACK message, even when
   VCID in the receive message isn't known .

   The following is the message format.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Version = 1   | Op Code = 5   |        Checksum               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | VCID type     |Flow-ID type   |     Reserved                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           VCID                                |
    /                                                               /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6.8 REMOVE ACK message

   REMOVE ACK message is transferred from a downstream node to an
   upstream node or from an upstream node to a downstream node.  The
   following is the message format.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Version = 1   | Op Code = 6   |        Checksum               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | VCID type     |Flow-ID type   |     Reserved                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           VCID                                |
    /                                                               /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+







Nagami, et. al.              Informational                     [Page 17]

RFC 2129                   FANP Specification                 April 1997


7. Security Considerations

   Security issues are not discussed in this memo.

8. References


   [1] Katsube, Y., Nagami, K., and H. Esaki, "Router Architecture
       Extensions for ATM; overview", Work in Progress.

   [2] Laubach, M., "Classical IP and ARP over ATM", RFC 1577,
       October 1993.

   [3] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation
       Layer 5", RFC 1483, July 1993.

   Ethernet is a registered trademark of Xerox Corp.  All other product
   names mentioned herein may be trademarks of their respective
   companies.

9. Authors' Addresses

   Ken-ichi Nagami
   R&D Center, Toshiba
   1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210 Japan
   Phone : +81-44-549-2238
   EMail : nagami@isl.rdc.toshiba.co.jp

   Yasuhiro Katsube
   R&D Center, Toshiba
   1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210 Japan
   Phone : +81-44-549-2238
   EMail : katsube@isl.rdc.toshiba.co.jp

   Yasuro Shobatake
   R&D Center, Toshiba
   1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210 Japan
   Phone : +81-44-549-2238
   Email : masahata@csl.rdc.toshiba.co.jp

   Akiyoshi Mogi
   R&D Center, Toshiba
   1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210 Japan
   Phone : +81-44-549-2238
   EMail : mogi@isl.rdc.toshiba.co.jp






Nagami, et. al.              Informational                     [Page 18]

RFC 2129                   FANP Specification                 April 1997


   Shigeo Matsuzawa
   R&D Center, Toshiba
   1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210 Japan
   Phone : +81-44-549-2238
   EMail : shigeom@isl.rdc.toshiba.co.jp

   Tatsuya Jinmei
   R&D Center, Toshiba
   1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210 Japan
   Phone : +81-44-549-2238
   EMail : jinmei@isl.rdc.toshiba.co.jp

   Hiroshi Esaki
   R&D Center, Toshiba
   1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210 Japan
   Phone : +81-44-549-2238
   EMail : hiroshi@isl.rdc.toshiba.co.jp


































Nagami, et. al.              Informational                     [Page 19]