File: rfc2098.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 (1011 lines) | stat: -rw-r--r-- 43,622 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






Network Working Group                                        Y. Katsube
Request for Comments: 2098                                    K. Nagami
Category: Informational                                        H. Esaki
                                                     Toshiba R&D Center
                                                          February 1997


      Toshiba's Router Architecture Extensions for ATM : Overview

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 describes a new internetworking architecture which makes
   better use of the property of ATM.  IP datagrams are transferred
   along hop-by-hop path via routers, but datagram assembly/disassembly
   and IP header processing are not necessarily carried out at
   individual routers in the proposed architecture.  A concept of "Cell
   Switch Router (CSR)" is introduced as a new internetworking
   equipment, which has ATM cell switching capabilities in addition to
   conventional IP datagram forwarding.  Proposed architecture can
   provide applications with high-throughput and low-latency ATM pipes
   while retaining current router-based internetworking concept.  It
   also provides applications with specific QoS/bandwidth by cooperating
   with internetworking level resource reservation protocols such as
   RSVP.

1.  Introduction

   The Internet is growing both in its size and its traffic volume. In
   addition, recent applications often require guaranteed bandwidth and
   QoS rather than best effort.  Such changes make the current hop-by-
   hop datagram forwarding paradigm inadequate, then accelerate
   investigations on new internetworking architectures.

   Roughly two distinct approaches can be seen as possible solutions;
   the use of ATM to convey IP datagrams, and the revision of IP to
   support flow concept and resource reservation.  Integration or
   interworking of these approaches will be necessary to provide end
   hosts with high throughput and QoS guaranteed internetworking
   services over any datalink platforms as well as ATM.

   New internetworking architecture proposed in this draft is based on
   "Cell Switch Router (CSR)" which has the following properties.



Katsube, et. al.             Informational                      [Page 1]

RFC 2098          Toshiba's Router Extension for ATM       February 1997


    - It makes the best use of ATM's property while retaining current
      router-based internetworking and routing architecture.

    - It takes into account interoperability with future IP that
      supports flow concept and resource reservations.

   Section 2 of this draft explains background and motivations of our
   proposal.  Section 3 describes an overview of the proposed
   internetworking architecture and its several remarkable features.
   Section 4 discusses control architectures for CSR, which will need to
   be further investigated.

2.  Background and Motivation

   It is considered that the current hop-by-hop best effort datagram
   forwarding paradigm will not be adequate to support future large
   scale Internet which accommodates huge amount of traffic with certain
   QoS requirements.  Two major schools of investigations can be seen in
   IETF whose main purpose is to improve ability of the Internet with
   regard to its throughput and QoS.  One is to utilize ATM technology
   as much as possible, and the other is to introduce the concept of
   resource reservation and flow into IP.

1) Utilization of ATM

   Although basic properties of ATM; necessity of connection setup,
   necessity of traffic contract, etc.; is not necessarily suited to
   conventional IP datagram transmission, its excellent throughput and
   delay characteristics let us to investigate the realization of IP
   datagram transmission over ATM.

   A typical internetworking architecture is the "Classical IP Model"
   [RFC1577].  This model allows direct ATM connectivities only between
   nodes that share the same IP address prefix.  IP datagrams should
   traverse routers whenever they go beyond IP subnet boundaries even
   though their source and destination are accommodated in the same ATM
   cloud.  Although an ATMARP is introduced which is not based on legacy
   datalink broadcast but on centralized ATMARP servers, this model does
   not require drastic changes to the legacy internetworking
   architectures with regard to the IP datagram forwarding process.
   This model still has problems of limited throughput and large
   latency, compared with the ability of ATM, due to IP header
   processing at every router.  It will become more critical when
   multimedia applications that require much larger bandwidth and lower
   latency become dominant in the near future.






Katsube, et. al.             Informational                      [Page 2]

RFC 2098          Toshiba's Router Extension for ATM       February 1997


   Another internetworking architecture is "NHRP (Next Hop Resolution
   Protocol) Model" [NHRP09].  This model aims at resolving throughput
   and latency problems in the Classical IP Model and making the best
   use of ATM.  ATM connections can be directly established from an
   ingress point to an egress point of an ATM cloud even when they do
   not share the same IP address prefix.  In order to enable it, the
   Next Hop Server [KAT95] is introduced which can find an egress point
   of the ATM cloud nearest to the given destination and resolves its
   ATM address.  A sort of query/response protocols between the
   server(s) and clients and possibly server and server are specified.
   After the ATM address of a desired egress point is resolved, the
   client establishes a direct ATM connection to that point through ATM
   signaling procedures [ATM3.1].  Once a direct ATM connection has been
   set up through this procedure, IP datagrams do not have to experience
   hop-by-hop IP processing but can be transmitted over the direct ATM
   connection.  Therefore, high throughput and low latency
   communications become possible even if they go beyond IP subnet
   boundaries.  It should be noted that the provision of such direct ATM
   connections does not mean disappearance of legacy routers which
   interconnect distinct ATM-based IP subnets.  For example, hop-by-hop
   IP datagram forwarding function would still be required in the
   following cases:

   - When you want to transmit IP datagrams before direct ATM connection
     from an ingress point to an egress point of the ATM cloud is
     established

   - When you neither require a certain QoS nor transmit large amount of
     IP datagrams for some communication

   - When the direct ATM connection is not allowed by security or policy
     reasons

2) IP level resource reservation and flow support

   Apart from investigation on specific datalink technology such as ATM,
   resource reservation technologies for desired IP level flows have
   been studied and are still under discussion.  Their typical examples
   are RSVP [RSVP13] and STII [RFC1819].

   RSVP itself is not a connection oriented technology since datagrams
   can be transmitted regardless of the result of the resource
   reservation process.  After a resource reservation process from a
   receiver (or receivers) to a sender (or senders) is successfully
   completed, RSVP-capable routers along the path of the flow reserve
   their resources for datagram forwarding according to the requested
   flow spec.




Katsube, et. al.             Informational                      [Page 3]

RFC 2098          Toshiba's Router Extension for ATM       February 1997


   STII is regarded as a connection oriented IP which requires
   connection setup process from a sender to a receiver (or receivers)
   before transmitting datagrams.  STII-capable routers along the path
   of the requested connection reserve their resources for datagram
   forwarding according to the flow spec.

   Neither RSVP nor STII restrict underlying datalink networks since
   their primary purpose is to let routers provide each IP flow with
   desired forwarding quality (by controlling their datagram scheduling
   rules).  Since various datalink networks will coexist as well as ATM
   in the future, these IP level resource reservation technologies would
   be necessary in order to provide end-to-end IP flow with desired
   bandwidth and QoS.

   aking this background into consideration, we should be aware of
   several issues which motivate our proposal.

   - As of the time of writing, the ATM specific internetworking
     architecture proposed does not take into account interoperability
     with IP level resource reservation or connection setup protocols.
     In particular, operating RSVP in the NHRP-based ATM cloud seems to
     require much effort since RSVP is a soft-state receiver-oriented
     protocol with multicast capability as a default, while ATM with
     NHRP is a hard-state sender-oriented protocol which does not
     support multicast yet.

   - Although RSVP or STII-based routers will provide each IP flow with
     a desired bandwidth and QoS, they have some native throughput
     limitations due to the processor-based IP forwarding mechanism
     compared with the hardware switching mechanism of ATM.

   The main objective of our proposal is to resolve the above issues.

   The proposed internetworking architecture makes the best use of the
   property of ATM by extending legacy routers to handle future IP
   features such as flow support and resource reservation with the help
   of ATM's cell switching capabilities.

3.  Internetworking Architecture Based On the Cell Switch Router (CSR)

3.1  Overview

   The Cell Switch Router (CSR) is a key network element of the proposed
   internetworking architecture.  The CSR provides cell switching
   functionality in addition to conventional IP datagram forwarding.
   Communications with high throughput and low latency, that are native
   properties of ATM, become possible by using this cell switching
   functionality even when the communications pass through IP subnetwork



Katsube, et. al.             Informational                      [Page 4]

RFC 2098          Toshiba's Router Extension for ATM       February 1997


   boundaries.  In an ATM internet composed of CSRs, VPI/VCI-based cell
   switching which bypasses datagram assembly/disassembly and IP header
   processing is possible at every CSR for communications which lend
   themselves to such (e.g., communications which require certain amount
   of bandwidth and QoS), while conventional hop-by-hop datagram
   forwarding based on the IP header is also possible at every CSR for
   other conventional communications.

   By using such cell-level switching capabilities, the CSR is able to
   concatenate incoming and outgoing ATM VCs, although the concatenation
   in this case is controlled outside the ATM cloud (ATM's control/
   management-plane) unlike conventional ATM switch nodes.  That is, the
   CSR is attached to ATM networks via an ATM-UNI instead of NNI.  By
   carrying out such VPI/VCI concatenations at multiple CSRs
   consecutively, ATM level connectivity composed of multiple ATM VCs,
   each of which connects adjacent CSRs (or CSR and hosts/routers), can
   be provided.  We call such an ATM pipe "ATM Bypass-pipe" to
   differentiate it from "ATM VCC (VC connection)" provided by a single
   ATM datalink cloud through ATM signaling.

   Example network configurations based on CSRs are shown in figure 1.
   An ATM datalink network may be a large cloud which accommodates
   multiple IP subnets X, Y and Z.  Or several distinct ATM datalinks
   may accommodate single IP subnet X, Y and Z respectively.  The latter
   configuration would be straightforward in discussing the CSR, but the
   CSR is also applicable to the former configuration as well.  In
   addition, the CSR would be applicable as a router which interconnects
   multiple NHRP-based ATM clouds.

   Two different kinds of ATM VCs are defined between adjacent CSRs or
   between CSR and ATM-attached hosts/routers.

1) Default-VC

   It is a general purpose VC used by any communications which select
   conventional hop-by-hop IP routed paths.  All incoming cells received
   from this VC are assembled to IP datagrams and handled based on their
   IP headers.  VCs set up in the Classical IP Model are classified into
   this category.

2) Dedicated-VC

   It is used by specific communications (IP flows) which are specified
   by, for example, any combination of the destination IP address/port,
   the source IP address/port or IPv6 flow label.  It can be
   concatenated with other Dedicated-VCs which accommodate the same IP
   flow as it, and can constitute an ATM Bypass-pipe for those IP flows.




Katsube, et. al.             Informational                      [Page 5]

RFC 2098          Toshiba's Router Extension for ATM       February 1997


   Ingress/egress nodes of the Bypass-pipe can be either CSRs or ATM-
   attached routers/hosts both of which speak a Bypass-pipe control
   protocol.  (we call that "Bypass-capable nodes") On the other hand,
   intermediate nodes of the Bypass-pipe should be CSRs since they need
   to have cell switching capabilities as well as to speak the Bypass-
   pipe control protocol.

   The route for a Bypass-pipe follows IP routing information in each
   CSR.  In figure 1, IP datagrams from a source host or router X.1 to a
   destination host or router Z.1 are transferred over the route X.1 ->
   CSR1 -> CSR2 -> Z.1 regardless of whether the communication is on a
   hop-by-hop basis or Bypass-pipe basis.  Routes for individual
   Dedicated-VCs which constitutes the Bypass-pipe X.1 --> Z.1 (X.1 ->
   CSR1, CSR1 -> CSR2, CSR2 -> Z.1) would be determined based on ATM
   routing protocols such as PNNI [PNNI1.0], and would be independent of
   IP level routing.

   An example of IP datagram transmission mechanism is as follows.

   o The host/router X.1 checks an identifier of each IP datagram,
     which may be the "destination IP address (prefix)",
     "source/destination IP address (prefix) pair", "destination IP
     address and port", "source IP address and Flow label (in IPv6)",
     and so on.  Based on either of those identifiers, it determines
     over which VC the datagram should be transmitted.

   o The CSR1/2 checks the VPI/VCI value of each incoming cell.  When
     the mapping from the incoming interface/VPI/VCI to outgoing
     interface/VPI/VCI is found in an ATM routing table, it is directly
     forwarded to the specified interface through an ATM switch module.
     When the mapping in not found in the ATM routing table (or the
     table shows an IP module as an output interface), the cell is
     assembled to an IP datagram and then forwarded to an appropriate
     outgoing interface/VPI/VCI based on an identifier of the datagram.

















Katsube, et. al.             Informational                      [Page 6]

RFC 2098          Toshiba's Router Extension for ATM       February 1997


        IP subnet X           IP subnet Y          IP subnet Z
  <---------------------> <-----------------> <--------------------->

  +-------+ Default  +-------+ Default   +-------+ Default  +-------+
  |       |     -VC  | CSR 1 |     -VC   | CSR 2 |     -VC  |       |
  | Host +=============+   +===============+   +=============+ Host |
  |  X.1 +-------------+++++---------------+++++-------------+  Z.1 |
  |      +-------------+++++---------------+++++-------------+      |
  |      +-------------+++++---------------+++++-------------+      |
  |       |Dedicated |       | Dedicated |       |Dedicated |       |
  +-------+     -VCs +-------+      -VCs +-------+     -VCs +-------+
         <--------------------------------------------------->
                             Bypass-pipe


         Figure 1  Internetworking Architecture based on CSR

3.2  Features

   The main feature of the CSR-based internetworking architecture is the
   same as that of the NHRP-based architecture in the sense that they
   both provide direct ATM level connectivity beyond IP subnet
   boundaries.  There are, however, several notable differences in the
   CSR-based architecture compared with the NHRP-based one as follows.

1) Relationship between IP routing and ATM routing

   In the NHRP model, an egress point of the ATM network is first
   determined in the next hop resolution phase based on IP level routing
   information.  Then the actual route for an ATM-VC to the obtained
   egress point is determined in the ATM connection setup phase based on
   ATM level routing information.  Both kinds of routing information
   would be calculated according to factors such as network topology and
   available bandwidth for the large ATM cloud.  The ATM routing will be
   based on PNNI phase1 [PNNI1.0] while the IP routing will be based on
   OSPF, BGP, IS-IS, etc.  We need to manage two different routing
   protocols over the large ATM cloud until Integtrated-PNNI [IPNNI96]
   which takes both ATM level metric and IP level metric into account
   will be phased in in the future.

   In the CSR model, IP level routing determines an egress point of the
   ATM cloud as well as determines inter-subnet level path to the point
   that shows which CSRs it should pass through.  ATM level routing
   determines an intra-subnet level path for ATM-VCs (both Dedicated-VC
   and Default-VC) only between adjacent nodes (CSRs or ATM-attached
   hosts/routers).  Since the roles of routing are hierarchically
   subdivided into inter-subnet level (router level) and intra-subnet
   level (ATM SW level), ATM routing does not have to operate all over



Katsube, et. al.             Informational                      [Page 7]

RFC 2098          Toshiba's Router Extension for ATM       February 1997


   the ATM cloud but only in individual IP subnets independent from each
   other.  This will decrease the amount of information for ATM routing
   protocol handling.  But an end-to-end ATM path may not be optimal
   compared with the NHRP model since the path should go through routers
   at subnet boundaries in the CSR model.

2) Dynamic routing and redundancy support

   A CSR-based network can dynamically change routes for Bypass-pipes
   when related IP level routing information changes.  Bypass-pipes
   related to the routing changes do not have to be torn down nor
   established from scratch since intermediate CSRs related to IP
   routing changes can follow them and change routes for related
   Bypass-pipes by themselves.

   The same things apply when some error or outage happens in any ATM
   nodes/links/routers on the route of a Bypass-pipe.  CSRs that have
   noticed such errors or outages would change routes for related
   Bypass-pipes by themselves.

3) Interoperability with IP level resource reservation protocols in
   multicast environments

   As current NHRP specification assumes application of NHRP to unicast
   environments only, multicast IP flows should still be carried based
   on a hop-by-hop manner with multicast routers.  In addition,
   realization of IP level resource reservation protocols such as RSVP
   over NHRP environments requires further investigation.

   The CSR-based internetworking architecture which keeps subnet-by-
   subnet internetworking with regard to any control protocol sequence
   can provide multicast Bypass-pipes without requiring any
   modifications in IP multicast over ATM [IPMC96] or multicast routing
   techniques.  In addition, since the CSR can handle RSVP messages
   which are transmitted in a hop-by-hop manner, it can provide Bypass-
   pipes which satisfy QoS requirements by the cooperation of the RSVP
   and the Bypass-pipe control protocol.

4.  Control Architecture for CSR

   Several issues with regard to a control architecture for the CSR are
   discussed in this section.

4.1  Network Reference Model

   In order to help understanding discussions in this section, the
   following network reference model is assumed.  Source hosts S1, S2,
   and destination hosts D1, D2 are attached to Ethernets, while S3 and



Katsube, et. al.             Informational                      [Page 8]

RFC 2098          Toshiba's Router Extension for ATM       February 1997


   D3 are attached to the ATM.  Routers R1 and R5 are attached to
   Ethernets only, while R2, R3 and R4 are attached to the ATM.  The ATM
   datalink for subnet #3 and subnet #4 can either be physically
   separated datalinks or be the same datalink.  In other words, R3 can
   be either one-port or multi-port router.

      Ether    Ether        ATM          ATM        Ether    Ether
        |        |        +-----+      +-----+        |        |
        |        |        |     |      |     |        |        |
    S1--|   S2---|   S3---|     |      |     |---D3   |---D2   |--D1
        |        |        |     |      |     |        |        |
        |---R1---|---R2---|     |--R3--|     |---R4---|---R5---|
        |        |        |     |      |     |        |        |
        |        |        +-----+      +-----+        |        |
     subnet   subnet      subnet       subnet      subnet   subnet
       #1       #2          #3           #4          #5       #6


                   Figure 2  Network Reference Model

   Bypass-pipes can be configured [S3 or R2]-->R3-->[D3 or R4].  That
   means that S3, D3, R2, R3 and R4 need to speak Bypass-pipe control
   protocol, and means that R3 needs to be the CSR.  We use term
   "Bypass-capable nodes" for hosts/routers which can speak Bypass-pipe
   control protocol but are not necessarily CSRs.

   As shown in this reference model, Bypass-pipe can be configured from
   host to host (S3-->R3-->D3), router to host (R2-->R3-->D3), host to
   router (S3-->R3-->R4), and router to router (R2-->R3-->R4).

4.2  Possible Use of Bypass-pipe

   Possible use (or purposes) of Bypass-pipe provided by CSRs, in other
   words, possible triggers that initiate Bypass-pipe setup procedure,
   is discussed in this subsection.

   Following two purposes for Bypass-pipe setup are assumed at present;

a) Provision of low latency path

   This indicates cases in which end hosts or routers initiate a
   Bypass-pipe setup procedure when they will transmit large amount of
   datagrams toward a specific destination.  For instance,

   - End hosts or routers initiate Bypass-pipe setup procedures based
     on the measurement of IP datagrams transmitted toward a certain
     destination.




Katsube, et. al.             Informational                      [Page 9]

RFC 2098          Toshiba's Router Extension for ATM       February 1997


   - End hosts or routers initiate Bypass-pipe setup procedures when
     it detects datagrams with certain higher layer protocols such as
     ftp, nntp, http, etc.

   Other triggers may be possible depending on the policy in each
   network.  In any case, the purpose of Bypass-pipe setup in each of
   these cases is to reduce IP processing burden at intermediate routers
   as well as to provide a communication path with low latency for burst
   data transfer, rather than to provide end host applications with
   specific bandwidth/QoS.

   There would be no rule for determining bandwidth for such kinds of
   Bypass-pipes since no explicit information about bandwidth/QoS
   requirement by end hosts is available without IP-level resource
   reservation protocols such as RSVP.  Using UBR VCs as components of
   the Bypass-pipe would be the easiest choice although there is no
   guarantees for cell loss quality, while using other services such as
   CBR/VBR/ABR with an adequate parameter tuning would be possible.

b) Provision of specific bandwidth/QoS requested by hosts

   This indicates cases in which routers or end hosts initiate a
   Bypass-pipe setup procedure by triggers related to IP-level
   bandwidth/QoS request from end hosts.  The "resource management
   entity" in the host or router, which has received bandwidth/QoS
   requests from applications or adjacent nodes may choose to
   accommodate the requested IP flow to an existing VC or choose to
   allocate a new Dedicated-VC for the requested IP flow.  Selecting the
   latter choice at each router can correspond to the trigger for
   constituting a Bypass-pipe.  When both an incoming VC and an outgoing
   VC (or VCs) are dedicated to the same IP flow(s), those VCs can be
   concatenated at the CSR (ATM cut-through) to constitute a Bypass-
   pipe.  Bandwidth for the Bypass-pipe (namely, individual VCs
   constituting the Bypass-pipe) in this case would be determined based
   on the bandwidth/QoS requirements by the end host which is conveyed
   by, e.g., RSVP messages.  The ATM service classes; e.g., CBR/VBR/ABR;
   that would be selected depends on the IP-level service classes
   requested by the end hosts.

   Bypass-pipe provision for the purpose of b) will surely be beneficial
   in the near future when related IP-level resource reservation
   protocol will become available as well as when definitions of
   individual service classes and flow specs offered to applications
   become clear.  On the other hand, Bypass-pipe setup for the purpose
   of a) may be beneficial right now since it does not require
   availability of IP-level resource reservation protocols.  In that
   sense, a) can be regarded as a kind of short-term use while b) is a
   long-term use.



Katsube, et. al.             Informational                     [Page 10]

RFC 2098          Toshiba's Router Extension for ATM       February 1997


4.3  Variations of Bypass-pipe Control Architecture

   A number of variations regarding Bypass-pipe control architecture are
   introduced.  Items which are related to architectural variations are;

    o Ways of providing Dedicated-VCs

    o Channels for Bypass-pipe control message transfer

    o Bypass-pipe control procedures

   Each of these items are discussed below.

4.3.1  Ways of Providing Dedicated-VCs

   There are roughly three alternatives regarding the way of providing
   Dedicated-VCs in individual IP subnets as components of a Bypass-
   pipe.

a) On-demand SVC setup

   Dedicated-VCs are set up in individual IP subnets each time you want
   to set up a Bypass-pipe through the ATM signaling procedure.

b) Picking up one from a bunch of (semi-)PVCs

   Several VCs are set up beforehand between CSR and CSR, or CSR and
   other ATM-attached nodes (hosts/router) in each IP subnet. Unused VC
   is picked up as a Dedicated-VC from these PVCs in each IP subnet when
   a Bypass-pipe is set up.

c) Picking up one VCI in PVP/SVP

   PVPs or SVPs are set up between CSR and CSR, or CSR and other ATM-
   attached nodes (hosts/routers) in each IP subnet.  PVPs would be set
   up as a router/host initialization procedure, while SVPs, on the
   other hand, would be set up through ATM signaling when the first VC
   (either Default- or Dedicated-) setup request is initiated by either
   of some peer nodes.  Then, Unused VCI value is picked up as a
   Dedicated-VC in the PVP/SVP in each IP subnet when a Bypass-pipe is
   set up.  The SVP can be released through ATM signaling when no VCI
   value is in active state.

   The best choice will be a) with regard to efficient network resource
   usage.  However, you may go through three steps, ATMARP (for unicast
   [RFC1577] or multicast [IPMC96] in each IP subnet), SVC setup (in
   each IP subnet) and exchange of Bypass-pipe control message in this
   case.  Whether a) is practical choice or not will depend on whether



Katsube, et. al.             Informational                     [Page 11]

RFC 2098          Toshiba's Router Extension for ATM       February 1997


   you can allow larger Bypass-pipe setup time due to three-step
   procedure mentioned above, or whether you can send datagrams over
   Default-VCs in a hop-by-hop manner while waiting for the Bypass-pipe
   set up.

   In the case of b) or c), the issue of Bypass-pipe setup time will be
   improved since SVC setup step can be skipped.  In b), each node (CSR
   or ATM-attached host/router) should specify some traffic descriptors
   even for unused VCs, and the ATM datalink should reserve its desired
   resource (such as VCI value and bandwidth) for them.  In addition,
   the ATM datalink may have to carry out UPC functions for those unused
   VCs.  Such burden would be reduced when you use UBR-PVCs and set peak
   cell rate for each of them equal to link rate, but bandwidth/QoS for
   the Bypass-pipe is not provided in this case.  In c), on the other
   hand, traffic descriptors which should be specified by each node for
   the ATM datalink is not each VC's but VP's only.  Resource
   reservations for individual VCs will be carried out not as a
   functionality of the ATM datalink but of each CSR or ATM-attached
   host/router if necessary.  A functionality which need to be provided
   by the ATM datalink is control of VPs' bandwidth only such as UPC and
   dynamic bandwidth negotiation if it would be widely available.

4.3.2  Channels for Bypass-pipe Control Message Transfer

   There are several alternatives regarding the channels for managing
   (setting up, releasing, and possibly changing the route of) a
   Bypass-pipe.  This subsection explains these alternatives and
   discusses their properties.

   Three alternatives are discussed, Inband control message, Outband
   control message, and use of ATM signaling.

i) Inband Control Message

   When setting up a Bypass-pipe, control messages are transmitted over
   a Dedicated-VC which will eventually be used as a component of the
   Bypass-pipe.  These messages are handled at each CSR, and similar
   messages are transmitted to the next-hop node over a Dedicated-VC
   along the selected route (based on IP routing table).  Unlike outband
   message protocol described in ii), each message does not have to
   indicate a Dedicated-VC which will be used since the message itself
   is carried over "that" VC.

   The inband control message can be either "datagram dedicated for
   Bypass-pipe control" or "actual IP datagram" sent by user
   application.  Actual IP datagrams can be transmitted over Bypass-pipe
   after it has been set up in the former case.  In the latter case, on
   the other hand, the first (or several) IP datagram(s) received from



Katsube, et. al.             Informational                     [Page 12]

RFC 2098          Toshiba's Router Extension for ATM       February 1997


   an unused Dedicated-VC are analyzed at IP level and transmitted
   toward adequate next hop over an unused Dedicated-VC.  Then incoming
   Dedicated-VC and outgoing Dedicated-VC are concatenated to construct
   a Bypass-pipe.

   In inband control, Bypass-pipe control messages transmitted after a
   Bypass-pipe has been set up cannot be identified at intermediate CSRs
   since those messages are forwarded at cell level there.  As a
   possible solution for this issue, intermediate CSRs can identify
   Bypass-pipe control messages by marking cell headers, e.g., PTI bit
   which indicates F5 OAM cell.  With regard to Bypass-pipe release,
   explicit release message may not be necessary if individual CSRs
   administer the amount of traffic over each Dedicated-VC and deletes
   concatenation information for an inactive Bypass-pipe with their own
   decision.

ii) Outband Control Message

   When a Bypass-pipe is set up or released, control messages are
   transmitted over VCs which are different from Dedicated-VCs used as
   components of the Bypass-pipe.  Unlike inband message protocol
   described in i), each message has to indicate which Dedicated-VCs the
   message would like to control.  Therefore, an identifier that
   uniquely discriminates a VC, which is not a VPI/VCI that is not
   identical at both endpoints of the VC, need to be defined and be
   given at VC initiation phase.  However, an issue of control message
   transmission after a Bypass-pipe has been set up in inband case does
   not exist.

   Four alternatives are possible regarding how to convey Bypass-pipe
   control messages hop-by-hop over ATM datalink networks.

   1) Defines VC for Bypass-pipe control messages only.

   2) Uses Default-VC and discriminates Bypass-pipe control messages
      from user datagrams by an LLC/SANP value in RFC1483 encapsulation.

   3) Uses Default-VC and discriminates Bypass-pipe control messages
      from user datagrams by a protocol field value in IP header.

   4) Uses Default-VC and discriminates Bypass-pipe control messages
      from user datagrams by a port ID in the UDP frame.

   When we take into account interoperability with Bypass-incapable
   routers, 1) will not be a good choice.  Whether we select 2) or 3) 4)
   depends on whether we should consider multiprotocol rather than IP
   only.




Katsube, et. al.             Informational                     [Page 13]

RFC 2098          Toshiba's Router Extension for ATM       February 1997


   In the case of IP multicast, point-to-multipoint VCs in individual
   subnets are concatenated at CSRs consecutively in order to constitute
   end-to-end multicast tree.  Above four alternatives may require the
   same number of point-to-multipoint Defalut-VCs as the number of
   requested point-to-multipoint Dedicated-VCs in multicast case.  The
   fifth alternative which can reduce the necessary number of VCs to
   convey control messages in a multicast environment is;

   5) Defines point-to-multipoint VC whose leaves are members of
      multicast group 224.0.0.1.  All nodes which are members of at
      least one of active multicast group would become leaves of this
      point-to-multipoint VC.

   Each upstream node may become a root of the point-to-multipoint VC,
   or a sort of multicast server to which each upstream node transmits
   cells over a point-to-point VC may become a root of that.  In any
   case, Bypass-pipe control messages for every multicast group are
   transmitted to all nodes which are members of either of the group.
   When a downstream node has received control messages which are not
   related to a multicast group it belongs, it should discard them by
   referring to a destination group address on their IP header.
   Donwstream node would still need to use point-to-point VC to send
   control messages toward upstream.

iii)  Use of ATM Signaling Message

   Supposing that ATM signaling messages can convey IP addresses (and
   possibly port IDs) of source and destination, it may be possible that
   ATM signaling messages be used as Bypass-pipe control messages also.
   In that case, an ATM connection setup message indicates a setup of a
   Dedicated-VC to an ATM address of a desirable next-hop IP node, and
   also indicates a setup of a Bypass-pipe to an IP address (and
   possibly port ID) of a target destination node.  Information elements
   for the Dedicated-VC setup (ATM address of a next-hop node,
   bandwidth, QoS, etc.) are handled at ATM nodes, while information
   elements for the Bypass-pipe setup (source and destination IP
   addresses, possibly their port IDs, or flow label for IPv6, etc.) are
   transparently transferred to the next-hop IP node.  The next-hop IP
   node accepts Dedicated-VC setup and handles such IP level information
   elements.

   ATM signaling messages can be transferred from receiver to sender as
   well as sender to receiver when you set zero Forward Cell Rate and
   non-zero Backward Cell Rate as an ATM traffic descriptor information
   element in unicast case, or when Leaf Initiated Join capabilities
   will become available in multicast case.





Katsube, et. al.             Informational                     [Page 14]

RFC 2098          Toshiba's Router Extension for ATM       February 1997


   Issues in this method are,

    - Information elements which specify IP level (and port level)
      information need to be defined, e.g., B-HLI or B-UUI, as an ATM
      signaling specification.

    - It would be difficult to support soft-state Bypass-pipe control
      which transmits control messages periodically since ATM signaling
      is a hard-state protocol.

4.3.3  Bypass-pipe Control Procedures

   This subsection discusses several items with regard to actual
   procedures for Bypass-pipe control.

a) Distributed trigger vs. Centralized (restricted) trigger

   The first item to be discussed is whether the functionality of
   detecting a trigger of Dedicated-VC/Bypass-pipe control is
   distributed to all the nodes (including CSRs and hosts/edge devices)
   or restricted to specific nodes.

   In the case of the distributed trigger, every node is regarded as
   having a capability of detecting a trigger of Bypass-pipe setup or
   termination.  For example, every node detects datagrams for ftp, and
   sets up (or fetches) a Dedicated-VC individually to construct a
   Bypass-pipe.  After setting up or fetching the Dedicated-VCs,
   messages which informs (or requests) the transmission of the IP flow
   over the Dedicated-VC are exchanged between adjacent nodes.  That
   enables peer nodes to share the same knowledge about the mapping
   relationship between the IP flow and the Dedicated-VC.  There is no
   end-to-end message transmission in the Bypass-pipe control procedure
   itself, but transmission between adjacent nodes only.

   In the case of the centralized (or restricted) trigger, capability of
   detecting a trigger of Bypass-pipe setup or termination is restricted
   to nodes which are located at "the boundary of the CSR-cloud".  The
   boundary of the CSR-cloud signifies, for individual IP flows, the
   node which is the first-hop or the last-hop CSR-capable node.  For
   example, a node which detects datagrams for ftp can initiate Bypass-
   pipe setup procedure only when its previous hop is non-ATM or CSR-
   incapable.  In this case, Bypass-pipe control messages are originated
   at the boundary of the CSR-cloud, and forwarded hop-by-hop toward
   another side of the boundary, which is similar to ATM signaling
   messages.  The semantics of the messages may be the request of end-
   to-end Bypass-pipe setup as well as notification or request of
   mapping relationship between the IP flow and the Dedicated-VC.




Katsube, et. al.             Informational                     [Page 15]

RFC 2098          Toshiba's Router Extension for ATM       February 1997


b) Upstream-initiated control vs. Downstream-initiated control

   The second item to be discussed is whether the setup of a Dedicated-
   VC and the control procedure for constructing a Bypass-pipe are
   initiated by upstream side or downstream side.

   In the case of the upstream-initiated control, the upstream node
   takes the initiative when setting up a Dedicated-VC for a specific IP
   flow and creating the mapping relationship between the IP flow and
   the Dedicated-VC.  For example, a CSR which detects datagrams for ftp
   sets up (or fetches) a Dedicated-VC toward its downstream neighbor
   and notifies its downstream neighbor that it will transmit a specific
   IP flow over the Dedicated-VC.  This means that the downstream node
   is requested to receive datagrams from the Dedicated-VC.

   In the case of the downstream-initiated control, the downstream node
   takes the initiative when setting up a Dedicated-VC for a specific IP
   flow and creating the mapping relationship between the IP flow and
   the Dedicated-VC.  For example, a CSR which detects datagrams for ftp
   sets up (or fetches) a Dedicated-VC toward its upstream neighbor and
   requests its upstream neighbor to transmit a specific IP flow over
   the Dedicated-VC.  This means that the upstream node is requested to
   transmit the IP flow over the Dedicated-VC.

c) Hard-state management vs. Soft-state management

   The third item to be discussed is whether the control (setup,
   maintain, and release) of the Bypass-pipe is based on hard-state or
   soft-state.

   In hard-state management, individual nodes transmit Bypass-pipe
   control messages only when they want to notify or request any change
   in their neighbors' state.  They should wait for an acknowledgement
   of the message before they change their internal state.  For example,
   after setting up a Bypass-pipe, it is maintained until either of a
   peer nodes transmits a message to release the Bypass-pipe.

   In soft-state management, individual nodes periodically transmit
   Bypass-pipe control messages in order to maintain their neighbors'
   state.  They do not have to wait for an acknowledgement of the
   message before they changes its internal state.  For example, even
   after setting up a Bypass-pipe, either of a peer nodes is required to
   periodically transmit refresh messages to its neighbor in order to
   maintain the Bypass-pipe.

5.  Security Considerations

   Security issues are not discussed in this memo.



Katsube, et. al.             Informational                     [Page 16]

RFC 2098          Toshiba's Router Extension for ATM       February 1997


6.  Summary

   Basic concept of Cell Switch Router (CSR) are clarified and control
   architecture for CSR is discussed.  A number of methods to control
   Bypass-pipe will be possible each of which has its own advantages and
   disadvantages.  Further investigation and discussion will be
   necessary to design control protocol which may depend on the
   requirements by users.

7.  References

   [IPMC96] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based
   ATM Networks", RFC 2022, November 1996.

   [ATM3.1] The ATM-Forum, "ATM User-Network Interface Specification,
   v.3.1", Sept. 1994.

   [RSVP13] Braden, R., et al., "Resource ReSerVation Protocol (RSVP),
   Version 1 Functional Specification", Work in Progress.

   [IPNNI96] R. Callon, et al., "Issues and Approaches for Integrated
   PNNI", The ATM Forum Contribution No. 96-0355, April 1996.

   [NHRP09]  Luciani, J., et al., "NBMA Next Hop Resolution Protocol
   (NHRP)", Work in Progress.

   [PNNI1.0] The ATM-Forum, "P-NNI Specification Version 1.0", March
   1996.

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

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

   [RFC1819] Delgrossi, L, and L. Berger, "Internet STream Protocol
   Version 2 (STII) Protocol Specification Version ST2+", RFC 1819,
   August 1995.













Katsube, et. al.             Informational                     [Page 17]

RFC 2098          Toshiba's Router Extension for ATM       February 1997


8.  Authors' Addresses

   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

   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

   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





























Katsube, et. al.             Informational                     [Page 18]