Cell Switch Router (CSR) - label switching router supporting standard ATM interfaces Hiroshi ESAK =!

Shigeo MATS"#A$A ! A%i&oshi M'( ! Ken-ichi )(AM ! Tatsu&a * )ME ! Toru K')+)' ! ,asuhiro KATS"-E R./ Center! T'SH -A Corporation! *apan

Abstract
Architecture overview of Cell Switch Router (CSR ), that is one of actual implementation using label switching paradigm, and the CSR prototype system supporting standard ATM interfaces are described. CSR can operate both with !C " ermanent !irtual Connection) and with S!C "Switched !irtual Connection) as the !C for cut#through pac$et forwarding. CSR contains cell switch fabric and % pac$et switch fabric to achieve high throughput % forwarding. % pac$ets are forwarded either through a cut#through pac$et transmission, in which pac$et are forwarded without reassembling % pac$et nor % header processing, or through a conventional hop#by#hop % pac$et forwarding. This paper describes and proposes the mechanism to forward the connectionless % pac$et flows at the CSR. A CSR prototype system has developed. The CSR prototype system uses !C and S!C connections to transfer the % pac$ets. &ith the CSR prototype system, we can ma$e sure that CSR system could establish the cut#through pac$et transmission path between the ad'acent node with acceptable establishment delay, that was less than few hundred second. The S!C connections for cut#through pac$et transmission are established on demand using ATM (orum )*% +., or )*%+.-. Ke& $ords 0 ATM, label switching, CSR, cut#through, hop#by#hop, % , router, prototype, S!C

12 ntroduction
ATM "Asynchronous Transfer Mode) is reali.ed as one of platforms to provide high speed datalin$ layer service with certain /0S "/uality of Service), with a uni1ue user networ$ interface 2%.-3,42A()*%4. Sometimes, it is said that ATM networ$ will provide a router#less large cloud datalin$ platform, which does not have any routers within the large cloud networ$. 5owever, we will need routers, even large ATM 2R(C-6+74 cloud datalin$ platform will be provided 28sa$i4. Therefore, physical or logical datalin$ networ$ segments "i.e., % subnets) will be interconnected through routers "i.e., through the networ$ layer entities), even when the ATM becomes a ma'or datalin$ platform. Recently, some high performance router architectures based on label switching methodology have been proposed. Those are tag switch 2R(C9-,34, AR%S "Aggregated Route#:ased % Switch) 2AR%S4, % switch 2%psilon4 and CSR "Cell Switch Router) 2CSR4 2R(C9,6;4. 2R(C9,6;4, 2R(C9-,34 and 2%psilon4 propose a router architecture containing both conventional % processing module and cell#switching module. As discussed briefly in this paper, all architecture models e<cepting CSR do not have interoperability with the standard ATM switch and can not use the standard ATM lin$s to interconnect the routers. Since the CSR supports the standard ATM interface "i.e., ATM )*%), CSR has the interoperability with standard ATM switch and can use the standard ATM lin$s to interconnect CSRes. The architecture of CSR proposed in this paper can support S!C "Switched !irtual Connection). The CSRes are interconnected through the standard S!Cs using the ATM signaling and CSRes can be interconnected through the standard ATM switches. The following is the structure of the rest of this paper. Section 9 briefly discusses the technical features of high performance router architectures "i.e., CSR, tag switch, AR%S, % Switch) using label switching paradigm. Sections +

(urther authors information ostal Address= - >omu$ai#Toshiba#cho, Saiwai#$u, >awasa$i, 9-,, ?apan 8mail = @hiroshi, shigeom, mogi, nagami, 'inmei, toru, $atsubeA Bisl.rdc.tohiba.co.'p ftp server = ftp=CCftp.wide.toshiba.co.'pCpubCcsr

proposes the % over ATM architecture using CSR "Cell Switch Router). Section 3 gives the brief specification of CSR prototype system supporting S!C and its evaluation. Section D gives a brief conclusion.

32 High 4erfor5ance Routers using 6abel Switching 321 Concept Su55ar& of Router using 6abel Switching
(or label switching architecture paradigm, some layer + pac$ets are forwarded either using the datalin$ label "e.g., ! %C!C%) or using the tag label between datalin$ header and pac$et header "e.g., tag for 8thernet frame in tag switching architecture 2R(C9-,34). The label is used as the information to forward the pac$ets, without analy.ing the internetwor$ layer address "e.g., % address). This means that the label represents the destination address of internetwor$ layer pac$ets. %n the CSR architecture, pac$et forwarding using the label is called as the cut#through pac$et forwarding 2CSR4. :y using the label instead of internetwor$ layer address for pac$et forwarding, the router "e.g., CSR) does not need to loo$ up the best#match policy based routing table, whose search $ey is the internetwor$ layer address. &hen the internetwor$ layer pac$et arrives at the node "i.e., intermediate router or host) located at the egress point of cut#through path represented by the label, the conventional pac$et processing "i.e., analysis of internetwor$ layer header) is performed. %n label switching architecture, it is not generally assumed all nodes within the datalin$ have a datalin$#level full#mesh connectivity. This means that nodes are interconnected through lin$s with some topology. ac$ets are forwarded along the given topology, even for cut#through pac$et forwarding. This is different architectural paradigm from *5R CM 0A 2*5R 4. %n *5R CM 0A, the short#cut virtual connection "i.e., ATM#!CC for ATM) is established irrelevant to the nodesE topology. &hen a short#cut !C is established to some node, pac$ets to the node does not travel the intermediate router"s), that is"are) given by the routing protocol information. 0n the other hand, in label switching architecture, pac$ets are forwarded along the e<actly the same route, that is given by the routing protocol information. The route, that pac$ets travel, is e<actly the same route indicated by routing protocol. &ith cut#through pac$et forwarding, 'ust the conventional pac$et forwarding process is bypassed, while the conventional route calculation is as it is and the pac$etEs forwarding route is also as it is.

32121 4ac%et 7orwarding Route

32123 Cut-Through 4ath Establish5ent 4olic&

There are two trigger types to invo$e cut#through path establishment. 0ne is according to the appearance of pac$et flow, and the other is according to the appearance of routing entry in the routing table. The former mode is called as the flow driven, and the later mode is called as the topology driven. %n the flow driven mode, the cut#through path is established on demand, according to the actual appearance of pac$et flow at the node. %n the topology driven mode, the cut#through path is established in advance, according to the topology information of routers. Therefore, in the topology driven mode, the cut#through path is established, even if there is no actual pac$et flow. The maintenance of cut#through path is performed based on soft#state, hard#state or the combination of both. %n the soft# state management policy, the state of cut#through path is periodically refreshed. &hen there is no state refreshment, the cut#through path is released. %n the hard#state management policy, the state of cut#through path is securely established and is not refreshed. Fatalin$ protocol "e.g., MAC protocol) has to be modified to apply the label switching technology for all proposed architectures e<cepting CSR. (or e<ample, the tag switching with 8thernet lin$, the frame format has to be modified "i.e., the thin tag is inserted between the 8thernet header and the internetwor$ layer pac$et header).

32128 Cut-Through 4ath Manage5ent 4olic&

32129 /atalin% 4rotocol

323 Su55ar& of 6abel Switching Architectures

%n this subsection, the summary of label switch architectures, e<cepting CSR, are briefly described.

The followings are the technical feature of % switch. G Soft#state cut#through path management G Fown#stream node initiation for cut#through path establishment G Transparent lin$ "e.g., S0*8T lin$) only G % only "i.e., non#multiprotocol) for cut#through forwarding G %n#compatible with standard ATM interface G (low driven operation G 5op#by#hop cut#through path establishment % switch establishes the cut#through path using %(M "%psilonEs (low Management rotocol) 2R(C-63+4. The trigger to establish the cut#through path is invo$ed by the down#stream node to the up#stream node, according to the appearance of % pac$et. &hether to establish the cut#through path is decided using the information of application using the activity information of each pac$et flow. The establishment of cut#through path is local decision, i.e., hop#by#hop establishment. Since the % switch does not support the standard ATM interface "i.e., ATM (orum )*% +.,C+.-), % switch does not have an interoperability with the standard ATM switch and can not use the standard ATM lin$s "i.e., ATM#!C) as the lin$ to interconnect % switches.

32321 4 Switch : psilon;

32323 Tag Switch :R7C31<=;

The following is the technical feature of Tag switch. G Combination of hard#state and soft#state cut#through path management G :oth down#stream and up#stream nodes initiation for cut#through path establishment G Any datalin$, e<cept standard ATM lin$ G Multiprotocol for cut#through forwarding G %n#compatible with standard ATM interface G Topology driven operation G Any granularity of flow aggregation G end#to#end cut#through path establishment Tag switch establishes the cut#through path using TF "Tag Fistribution rotocol) 2TF 4. The trigger to establish the cut# through path is invo$ed both by the down#stream node and by the up#stream node, according to the routing entry in the routing table given by routing protocol. The cut#through path is established using the topology information obtained by routing protocol "e.g., :H ). The establishment of cut#through path is performed end#to#end base, i.e., end#to#end establishment. (or the scaling purpose, any granularity of flow aggregation can be defined. Since the tag switch does not support the standard ATM interface "i.e., ATM (orum )*% +.,C+.-), Tag switch does not have an interoperability with the standard ATM switch and can not use the standard ATM lin$s "i.e., ATM#!C) as the lin$ to interconnect tag switches. Iarge "software) processing capability is re1uired for the egress and ingress routers of given routing domain, when !C#merging function is not supported in the TSR "Tag Switch Router). &hen the !C#merging function is implemented in the ATM switch module in the TSR, large "soft#ware) processing capability may not be re1uired for TSR at the ingress point of aggregated path.

32328 AR S (Aggregated Route--ased 4 Switch) :AR S;

The following is the technical feature of AR%S. G Soft#state cut#through path management G Modified ATM lin$ G Multiprotocol for cut#through forwarding "not specified) G %n#compatible with standard ATM interface G Topology driven operation G Any granularity of flow aggregation G multipoint#to#point cut#through path establishment The cut#through path "* of multipoint#to#point connections) is established using the topology information obtained by routing protocol "e.g., :H ). %n order to provide multipoint#to#point connection, the !C merging function has to be provided for each ATM switch. (or the scaling purpose, any granularity of flow aggregation can be defined.

Since the AR%S does not support the standard ATM interface "i.e., ATM (orum )*% +.,C+.-), AR%S does not have an interoperability with the standard ATM switch and can not use the standard ATM lin$s "i.e., ATM#!C) as the lin$ to interconnect AR%S#based routers.

82 Architecture of Cell Switch Router 821 Architecture of Cell Switch Router (CSR)
The following is the technical feature of CSR "Cell Switch Router). G Soft#state cut#through path management G )p#stream nodes initiation for cut#through path establishment G Any connection oriented datalin$, including standard ATM lin$ G Multiprotocol for cut#through forwarding G (ull compatible with standard ATM interface G (low driven operation "topology driven will be supported) G Any granularity of flow aggregation G hop#by#hop cut#through path establishment CSR establishes the cut#through path using (A* "(low Attribute *otification rotocol) 2R(C9-964. The trigger to establish the cut#through path is invo$ed both by the up#stream node to the up#stream node, according to the appearance of pac$et. The route of cut#through path is determined using the routing table obtained by routing protocol "e.g., :H ). (or the scaling purpose, any granularity of flow aggregation can be defined. Since the CSR supports the standard ATM interface "i.e., ATM (orum )*% +.,C+.-), CSR has a full# interoperability with the standard ATM switch and can use the standard ATM lin$s "i.e., ATM#!C) as the lin$ to interconnect CSRes. CSR provides a cell switching capability in addition to the conventional % pac$et switching. :y the use of cell switching capability, high throughput % pac$et forwarding can be achieved. CSR can forward some % pac$et flows while bypassing the pac$et assemblyCreassembly and % header processing, i.e., the cut#through pac$et forwarding. %n the cut#through pac$et forwarding, % pac$et is forwarded based on ! %C!C% and % header is not e<amined at the CSR. 0n the contrary, the conventional hop#by#hop % pac$et forwarding based on % header can be also applied to the other % pac$et flows. The $ey functionalities of CSR are as follows. G 5op#by#hop pac$et forwarding The pac$ets forwarded with hop#by#hop pac$et forwarding are transferred through the default !C, that is established when CSR turns on. %n the hop#by#hop pac$et forwarding, the % pac$et is reassembled into the % pac$et to analy.e the % header. The CSR decides the ne<t hop node "i.e., router or host) based on destination % address in the received % pac$et, according to the routing information indicated by routing protocol "e.g., 0S (). G Cut#through pac$et forwarding path establishment and cell relaying Cells belonging to the pac$ets, that should and could be forwarded without usual % processing at the CSR, are relayed as the ATM layerEs function, i.e., cut#through pac$et forwarding. &hen the CSR receives % pac$et, that should and could be forwarded by cut#through mode, the CSR tries to establish a dedicated !C between the neighbor nodes "e.g., CSR). &hen the ingress dedicated !C and the egress dedicated !C, regarding a % pac$et flow to be cut#through, are established, these two dedicated !Cs are coupled at the CSR. After the coupling of these two dedicated !Cs, the cells belonging to this % pac$et flow are forwarded in cut#through mode. Since egress and ingress !CCs are independently established, CSR has to have the ! %C!C% translation functionality. 5ere, whether an % pac$et flow is handled by the cut#through pac$et forwarding or is handled by the conventional hop#by#hop pac$et forwarding will be basically determined by every routerEs local decision.

Through bypassing the conventional % forwarding processing cell#relaying, we could dramatically increase the % processing capacity of the router. %n order to provide the cut#through pac$et forwarding by the CSR, the additional protocol "i.e., (A* ) messages, that will be described by the other article, e.g., 2R(C9-964, and is not described in this paper. &ith (A* , neighbor CSRes e<change the information how the % pac$et flows are aggregated into the Fedicated !C.

823 ATM->CC Manage5ent Architecture

(igure +#- shows an e<ample of the configuration of ATM#!CCs and % pac$et flows with the cut#through pac$et forwarding at CSRs. All ATM#!CCs, i.e., !CCs between CSRs and between CSR and host, are !C " ermanent !irtual Connection) or S!C "Switched !irtual Connection). Furing the boot procedure of each node "CSR and host), the Fefault !Cs are established to the ad'acent nodes. Fefault !Cs can be !C and be S!C. The system operator can choose which S!C or !C should be used for the Fefault !C. The Fefault#!C transfers both control pac$ets "e.g., the control pac$ets of (A* described in the following subsection) and hop#by#hop based user pac$ets. Fedicated#!C transfers only the user pac$ets that are forwarded through the cut#through pac$et forwarding mode. &ith !C mode, the bundle of !Cs are established between the ad'acent CSR in advance "e.g., during a boot procedure of CSR), and pic$ up one of un#used !C for the newly appeared pac$et flow, that should be forwarded with cut#through mode. 0n the contrary, with S!C mode, the Fedicated !C is established on demand, in accordance with the appearance of pac$et flow, that should be forwarded through cut#through mode. As a result, in the operation, the !Cs shown in figure +#- will be configured, i.e., single Fedicated !C with hop#by#hop pac$et forwarding and bundle of Fedicated !Cs for each particular pac$et flow with cut#through forwarding. 5ere, the cell flow arrived at a CSR through a Fedicated#!C may be transferred by the Fefault#!C to forward the % pac$et to the ad'acent CSR, and vice versa. %n the figure, the pac$et flows forwarded with Fedicated !C are forwarded through the corresponding Fedicated !C. The control messages to manage the user pac$et flows using the Fedicated#!Cs are transferred through the Fefault#!C. The % pac$ets transferred through the Fefault#!C are always performed the usual % processing. Therefore, the management of cut#through path can be hop#by#hop, and the % header in the cut#through path does not have to be e<amined. The detail of the protocols and messages for control and management of the user pac$et flows are not discussed in this paper. Management of the dedicated#!Cs, i.e., establishment, tearing down of the dedicated#!Cs, and management of the mapping between % pac$et flow and ATM#!CC are matters of every CSREs local decision. /.96+- defined by ATM (orum )*%+.,C+.- is used to establish or tear#down the Fedicated#!Cs among the CSRes. &hen we use digital lin$s "e.g., 0C#+ or FS+ S0*8T pipe) to interconnect CSRes, /.96+- is not used to establishCtear#down the dedicated#!Cs.

% Subnet J % process

% subnet K

Fefault#!C % Subnet L % process

5ost J.Fedicated#!C

CSR-

CSR9 Coupling Fedicated#!Cs

5ost L.-

(igure +#-. ATM#!CC Configuration 8<ample for CSR

828 4ac%et 7orwarding of Connectionless 4 7low

% pac$ets beyond the data#lin$ segment are sent to an appropriate router from the source end#host. Routers e<change routing information and forward % pac$ets to the appropriate router. The operation of connectionless % pac$et forwarding is shown in figure +#9. &hen the first % pac$et "of the session or after the idle period) arrives at a CSR through the dedicated !C, the ne<t hop router is decided using the % header, i.e., the routing decision will be done based on the % address "and the flow#%F in % vD) 2% vD4. After the ne<t router is decided, the received % pac$et is forwarded through the Fefault !C toward the ne<t hop router. CSR analy.es TC C)F header, as well as % header. &hen the received % pac$et belongs to the % flow, that is li$ely to be long life session, a Fedicated !C is established for the % pac$et flow through /.69+- and CSR establishes the mapping table between the incoming ! %C!C% "or some flow#%F in the data#lin$ layer) and the outgoing ! %C!C%. &hen the pac$et comes from the conventional platform "e.g., 8thernetC(FF%), the router always e<amines the % header in the case of % vM "in % vD, the flow#%F could be mapped to the outgoing ! %C!C%). &hen the % pac$et comes from an ATM networ$, the successive % pac$ets are forwarded based on the incoming ! %C!C% value, without any usual % processing. %f the activity of the % pac$et flow becomes low, the mapping information "i.e., the cached information) is pushed out. This means that the pushed out % pac$et flow from the cache must be e<amined by the usual % processing "loo$ing at the % header) at the CSR, i.e., transferred through the Fefault !C, and the corresponding Fedicated !C for the pac$et flow is teared down with /.96+-. As a result, % pac$et flow with a high activity can cut#through a usual % processing at the CSR. The above procedure is performed independently at every CSR. The 'ob of CSR is maintaining the ! %C!C% mapping table in the cell switch, or is maintaining the mapping table between the flow#%F and the ! %C!C%.

CSR
4 processing

6ong-life session

)4 7A

CSR
4 processing

7A )4

CSR
ATM switch
ATM subnet

CSR

CSR
ATM switch
ATM subnet

CSR

ATM subnet

? Hop-Hop 4ac%et 7orwarding @

ATM subnet

)4 A 7

CSR
4 processing

7A )4

/ecrease flow actiAit&

CSR
4 processing

CSR
ATM switch
ATM subnet

CSR

CSR
ATM switch
ATM subnet

CSR

ATM subnet

ATM subnet

? Cut-thru 4ac%et 7orwarding @

(igure +#9. 0peration of (low Friven ac$et (orwarding in CSR

92 CSR 4rotot&pe S&ste5 Supporting S>C 921 5ple5entation Configuration of 4rotot&pe S&ste5
The following is the configuration of CSR prototype system supporting S!C. # CSR % controller moduleN G C )N entium -DDM5. G 0SN :SFC0S v9.G *%C cardN 8fficient *etwor$ -33 C% *%C with 9M: memory # CSR cell#switch moduleN (0R8 ASJ#9,,&H # CSR cell#switch module controlN S*M through 8thernet interface # Cut#through arameters for (low Friven mode"configurable) G Applications to be cut#through= web, ftp, telnet, nntp G Cut#through time out = two minutes

923 /edicated->C Establish5ent /ela&

The delay to establishCrelease the Fedicated !C within the CSR is evaluated. The ma'or contributions on the delay to establishCrelease the Fedicated !C are the S!C signaling delay across the ATM switch"es) and the Fedicated !C configuration in the CSR. The configuration of Fedicated#!C at the cell#switch module "(0R8 ASJ#9,,&H) is performed using S*M through 8thernet interface. Table M#- gives the average delay performances of Fedicated !C configuration and the delay performance of S!C signaling for a single ATM switch "AJ#-3,, by Toshiba). Table M#- Average Felay of Fedicated !C Configuration and S!C signaling S!C Signaling !C%F *egotiation (low *otification Total Felay 73.7 msec -,.9 msec M.+ msec 6,.9 msec

The above result gives us the total delay performance to establish the cut#through path in each CSR will be less than -,, msec. As shown in the table, the large part of Fedicated#!C establishment delay is contributed by S!C signaling, that occupies more than ;MO.

928 /iscussion and 7uture $or%s

As evaluated in section M.M, the delay to establish the cut#through path will be sometimes more than -,, msec. 5ere, the delay performance to release the Fedicated !C does not need to be so fast, since no pac$et is transferred through the corresponding Fedicated !C. 0n the contrary, the faster cut#through path establishment achieves the better pac$et transmission performance by the CSR. %n order to improve the delay performance to estab lish cut#through path, the following mechanism will be introduced into the CSR prototype system. Some unused !Cs "called as stand#by Fedicated !C) for the future use as the Fedicated !C are established, in advance. &hen the trigger pac$et to establish the cut# through path appears at the CSR, one of stand#by Fedicated !Cs is pic$ed up as the Fedicated !C to be used for the appeared pac$et flow. After one stand#by Fedicated !C is pic$ed up for the actual cut#through pac$et forwarding, a new stand#by Fedicated !C will be established. Through this operation, the S!C signaling delay across the ATM switch"es), that should be ma'or delay factor for cut#through path establishment, can be dramatically reduced. The other method to reduce the cut#through path establishment delay performance would be the reduce of Fedicated !C configuration in the cell#switch module in CSR. Special command or instruction could be defined to configure the Fedicated !C in the cell#switch module.

92821 5proAe5ent of Cut-through 4ath Establish5ent /ela&

92823 Cut-through 4 4ac%et 7low Aggregation

:y the following two reasons, CSR should have the flow aggregation supported by hardware. "-) &hen the CSR system becomes large scale networ$, the re1uired number of !Cs for cut#through pac$et forwarding will become large. %n order to reduce the re1uired number of ATM#!CC, the multiple ATM#!CC should be aggregated into a single ATM#!CC. "9) &hen the CSRes are interconnected through an ATM lin$ across the wide area networ$s "&A*), it may be better to multiple< multiple % flows using the dedicated#!C into a single ATM#!CC, in order to transfer % pac$ets to the CSR across the &A*. This would happen when the cost of an additional ATM#!CC establishment across the &A* is more e<pensive, than using an ATM#!CC which has a sufficiently large bandwidth. %n these cases, multiple cell flows using different dedicated#!Cs must be merged into a single dedicated#!C. %n general, we must re#construct % pac$ets in the multiple dedicated#!Cs in order to merge them into a single dedicated#!C. 5owever, if we have a cell switching fabric that can schedule a cell transmission from the output port so as to avoid a cell interleaving associated with the pac$ets that belong to the different ingress ATM#!CC but using the same egress ATM# !CC "i.e., using the same ! %C!C%), we do not have to relay on the pac$et switching fabric with the reconstruction of % pac$ets. &hen we have such a cell switching fabric, the pac$et switching fabric can transfer the % pac$et in pipe#line "i.e., % pac$et transmission will be able to start before re#assembly of % pac$et is completed) and could aggregate the multiple cut#through % pac$et flows into a single cut#through path.

=2 Conclusion
0verview of CSR architecture supporting S!C, that is the only label switching architecture interoperable with the standard ATM switch and with the standard ATM lin$s, and itEs prototype system is discussed. CSR has both cell switching fabric and pac$et switching fabric. CSR can forward some % pac$ets cell#by#cell based on ! %C!C% without e<amining % header "i.e., cut#through pac$et forwarding using Fedicated !C), rather than the conventional pac$et#by# pac$et forwarding "i.e., hop#by#hop pac$et forwarding using Fefault !C). Fefault !C and Fedicated !C can be provided both by !C and by S!C, in the system proposed in this paper. &ith using S!C, Fefault !C and Fedicated !C among the CSRes can be established through the standard ATM signaling "i.e., /.96+-). &ith using !C, the unused !C is pic$ed up as a Fedicated !C. &e have evaluated the Fedicated !C establishment delay for the CSR prototype system supporting S!C. The evaluation shows the delay to establish the Fedicated !C could be acceptable for the introduction stage operation. As the future wor$s, CSR will support stand#by !C provision to improve Fedicated !C establishment delay, and will support RS! to provide the end#to#end /oS "/uality of Service) over the %nternet. Also, CSR will support the

multicast service using the hardware#based multicast within the CSR, in order to provide high performance multicast services.

References
2A()*%4 ATM (orum = PATM )ser *etwor$ %nterface Specification version +.-P, September -66M 2AR%S4 R.&oundy, A.!iswanathan, *.(eldman, R.:oivie = PAR%S= Aggregate Route#:ased % SwitchingP, %8T( %nternet#Fraft, draft#woundy#aris#ipswitching#,,.t<t, *ovember, -66D. 2CSR4 S,Masu.awa, >.*agami, A.Mogi, T.?inmei, K.>atsube, 5.8sa$i = PArchitecture of Cell Switch Router and rototype System %mplementationP "to be appeared), %8%C8 Transactions on Communications. 28sa$i4 5.8sa$i, >.*agami, M.0hta = P5igh Speed Fatagram Felivery over %nternet using ATM TechnologyP, %8%C8 Transactions on Communications, !ol.87;#: *o.;, August -663 2%psilon4 .*ewman, T.Iyan, H.Minshall = P(low labeled= Connectionless ATM )nder % P, 8ngineer Conference, *etworldG%nteropE6D Ias !egas, April, -66D. 2% vD4 S.Feering, R.5inden = P%nternet rotocol, !ersion D "% vD), SpecificationP, %8T( %nternet#Fraft, draft#ietf#ipngwg#ipvD#spec#,-.t<t, March -663 2%.-3,4 %T)#T Recommendation %.-3,= P:#%SF* Asynchronous Transfer ModeP, -663 2*5R 4 ?.!.Iuciani, F.>at., F. iscitello and :.Cole = P*:MA *e<t 5op Resolution rotocol "*5R )P, %8T( %nternet#Fraft, draft#ietf#rolc#nhrp#-,.t<t, 0ctober, -66D 2R(C-6+74 K.Re$hter and F.>andlur = PIocalCRemote (orwarding Fecision in Switched Fatalin$ Subnetwor$sP, %8T( R(C-6+7, May, -66D. 2R(C9,6;4 K.>atusbe, >.*agami, 5.8sa$i = PToshibaQs Router Architecture 8<tensions for ATM = 0verviewP, %8T( R(C9,6;, (eb., -667. 2R(C9-,34 K.Re$hter,:.Favie,F.>at.,8.Rosen,H.Swallow = PCisco SystemsQs Tag Switching Architecture 0verviewP, %8T( R(C9-,3, (eb., -667. 2R(C9-964 >.*agami, K.>atsube, K.Shobata$e, A.Mogi, S.Matsu.awa, T.?inmei, 5.8sa$i = RToshibaEs (low Attribute *otification rotocol "(A* ) SpecificationS, %8T( R(C9-96, April, -667. 2RS! 4 I.Lhang, R.:raden, S.:erson, S.5er.og, S.?amin =PResource ReSer!ation rotocol "RS! ) ## !ersion (unctional SpecificationP, %8T( %nternet#Fraft, draft#ietf#rsvp#spec#-+.t<t, August, -66D. 2TF 4 .Foolan, :.Favie, F.>at., K.Re$hter, 8.Rosen = PTag Fistribution rotocolP, %8T( %nternet#Fraft, draft#doolan#tdp#spec#,,.t<t, September, -66D.