The Routing Over Large Clouds Mailing List Archive by date

Cell Relay Retreat>List Archive>month:1996-May> msg00177



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

My personal take on cell switching routers

  • From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
  • Date: Fri, 31 May 96 12:13:50 JST
  • Cc: Sam.Wilson@ed.ac.uk, ion@nexen.com

Though this thread is initiated by a chair, I'm afraid ION is not
a mailing list to discuss CSR...

Note that hype for NHRP or agaist CSR won't make NHRP scale.

But, to protect CSRs...

> There are some things that still need to be explained about CSRs switching
> across AS boundaries, in terms of application of policy, and in terms of
> scaling of the number of virtual channels in the internet. Say multicast...

	CSRs switching across AS boundaries

		Just as a usual router, consult BGP routing table

	in terms of application of policy

		Just as a usual router, reject non-conforming
		reservation request at RSVP level and no cells are relayed

		Just as a usual router, UPC control mechanism will do
		the rest of job.

	in terms of scaling of the number of virtual channels in the internet

		An RSVP CSR will need as many state as a usual RSVP router

		An ST2 CSR will need as many state as a usual ST2 router

	Say multicast...

		Without QoS, it is packet-level multicast, behave just
		as a usual router

		With QoS within subnets, use point-to-multipoint VC (you
		may use MARS)

		With QoS between subnets, just as a usual router copies
		multicast packets, copy multicast cells within CSR from
		a incoming VC to multiple outgoing VCs. It is a typical
		function of ATM switches.

That is, everything is done just as a usual router or just as
a usual ATM equipment.

> There are some things that still need to be explained about CSRs

Any questions remaining?

							Masataka Ohta