Subject: deploying reservations....

From: Jon Crowcroft <[email-masked]>
Date: Thu, 22 Jun 95 12:20:45 +0100

mark handley and i were chatting about deployment questions for the
rsvp-bone - basically, how do we reverse the current situation with
the mbone, where as we have built a virtual network on top of a FIFO
net, but (courtesy steve&agit) have rate limiting, we can prove we do
not deprive the internet of bandwidth, but they can deprive us of it
(and delay, and delay variation, etc etc)

the NAP (and other FIX architectures) hold one possible solution right
now (i.e. what to do until the router vendors deploy any fancy programmable
queueing....)

picture this:

----------->R[......]R----------->
<-----------R[......]R<-----------
             [..S...]
----------->R[......]R----------->
<-----------R[......]R<-----------

where the box in the middle is a switch S (say switched ether, fddi, or
atm...) - i.e. the usual DMZ...and the Rs are ISPs routers....

now we introduce X, below, which is an RSVP-respondent forwarder (but
not a full fledged partner in the routing....)

if we continue to exchange routes between the edge routers across the
DMZ direct, but simply fix up the tables (how many routers can overlay
multiple logical ports on a single physical port? i know a lot can,
especially with circvuit oriented link levels...), then we want a very
modest change to the router code so that the ip_output routine
equivalent has a flag to say whether a packet is sourced from the
router anbd destined for a router 1 hop aweay, it
should go to the link address that really corresponds
to the IP destination, but for things to anything else, they get sent
to the link address that is configured for each route....(may all be
the same of course....)

----------->R[......]R----------->
<-----------R[......]R<-----------
             [..S...]
----------->R[......]R----------->
<-----------R[......]R<-----------
              X (X....)

now the initial way that the X works is that via net management the Rs
and X (possibley more than one X for performance reasons) act as a two
hop link where the X implements the appropriate queueing for the
classes through it *but simply forwards all things from input port to
output ports dumbly...[big assumption is that the lines to the
outside world are slower than the NAP/FIX internal connections - this
is usually true, so that no queues build in the Rs)

while the S is a switched ether/LAN hub, this is all we can do...

later versions of X can take advantage of Ss that are ATM switches,
and allocate VCs between the Rs (via SNMP, SPANs, or just about
anything avaialble), so that the X is not even in the forwarding
path....i.e. the RSVP requests to X map into signaling requests to S
to setup paths between the Rs....the parameter mapping from flow spec
to QoS (e.g. cell rates, GFCR, CDV, BT etc is fairly simple - i think
most folks using the BAGNet and PNO pilot can give you equations for
this...)  

in this latter scenario, the X boxes are no longer talking any part
in forwarding, only in establishing the paths between routers... 

the RSVP 'soft state' is mapped into dynamic signalling - if the S
only does PVCs, then one might be able to do something in the way of
allocating a lot of them thru SNMP etc, and then just controlling
which (and how many) are used for which traffic by setting up the IP
"next hop to VC" mapping via NHRP or server arp or something...

the link sharing in this latter scenario is still possible since the
VCs could be grouped into VPs which could be VP policed only (assume
renegotiation of VP policing/shaping parameters is possible too,
though with the traffic all being IP, one could always allocate a new
VP and then close the old one) [note that VP policing makes the
assumption that all VCs get a fair treatment - i.e. a cell loss
tolwerance for a VP cannot be mapped into drop every nth cell, since
that could easily hit a particular VC!)

so our measurements here with S=ASX200, and X=SS20 seem (seem!) to
show that this is do-able right now for an aggregate of at least
several 10s of Mbps, for the traffic actually going thru the SS20s
CPU and around a few 1000 different classes of flow....for handing 
off connections, clearly you get whatever the S can do, which for the
switch we use is a couple of Gbps.....

can anyone say what Rs can do this?

jon

p.s. of course, the next stage is to invert the architecture above:
the external long haul links are ATM based, then the Rs simple do what
the X is doing above too - of course, if they can't do it, then the X
becomes the R...choose your share options carefully..:-)

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 22 Jun 95 23:20:53 JST

> the mbone,

As is already proven (by me) in this rsvp ML, the only way to use
RSVP over the Internet, without losing the scalability property
of RSVP, is not to use it with large clouds.

That is, the infrastructure of rsvp-bone must support the CATENET
model.

> atm...) - i.e. the usual DMZ...and the Rs are ISPs routers....

The picture works as long as the CATENET model is preserver, that is,
the intra-link-layer part is not so large so that the intra-link-layer
scalability is, not at all, the issue.

> especially with circvuit oriented link levels...),

You are miserably wrong.

That is the unicast scaling problem of NHRP.

A router can't not have the table as large as routing table.

That is, if the hierarchical routing with is the scalability requirement,
an interface can not support so many connections over the large cloud
link layer.

Don't forget that a separate VC costs as much as a separate routing table
entry.

> then we want a very
> router anbd destined for a router 1 hop aweay,

I'm afraid that you are assuming direct host-routeer connection
over a large could.

But, when hierarchical routing is the must, as is often the case with
the large cloud link layer, you just can't simply say "1 hop away".

That's what the scalability requires.

If you can accept several, but a few hop count, an addressing
architecture in

	draft-ohta-ipv6-addr-arch-00.txt

is the way to go.

> [big assumption is that the lines to the

As long as NAP/FIX is using widely available commodity link layer
protocols (is must do so not to exclude a lot of proviers), NAP/FIX
interla connections are assured to be slower than external ones.

> anything avaialble),

Say "scalability" 100 times.

> only does PVCs,

Unfortunately, no ATM signaling is dynamic.

RSVP is the dynamic sigaling.

With the Internet-wide RSVP-bone, RSVP is the dynamic and the global
sigaling.

> then one might be able to do something in the way of

SNMP should have nothing to do with intra-link-layer signaling.

"next hop to VC" MUST be determined by QoS routing and RSVP. NHRP
can only designate the final-hop outside the current link layer
in unscalable way and is unrelated the global signaling.

> VCs could be grouped into VPs which could be VP policed only

If you say VP, it's ATM. And, you must consider VP policing

> (assume

whose parameters MUST be affected by the individual addition
of each VCs.

That is, handling of VP (and VC) policing is only twice complex
as VC-only policing.

> [note that VP policing makes the

I'm afraind you are thinking of best-effort services only.

With RSVP, one not only need fairness but also assured communication.

> switch we use is a couple of Gbps.....

How many hosts, did you used?

If it's less than 1,000, yes, it is doable within a single link
layeer without worrying about scalability issues.

> p.s. of course, the next stage is to invert the architecture above:

Not at all.

The way to go is to preserve the CATENET architecture which is
the only architecture proven to scale without periodic renumbering
such as that of the current phone systems.

						Masataka Ohta

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 22 Jun 95 15:46:07 +0100

>of RSVP, is not to use it with large clouds.

this is nothing to do with large clouds whatsoever - you have totally
misunderstood my message.
 
 >You are miserably wrong.

well, a) i  am not miserable, as the sun is shining and
b) i am not wrong....
 
 >A router can't not have the table as large as routing table.

there are as many VCs as there are output lines from a NAP/FIX times
the number of classes of flow.....i.e. if we support 2 classes of
audio (hi & lo quality), 6 classes of video  (broadcast, conference,
seminar, videophone, ephemeral and mtv, say) and a typical NAP has 10
providers, then we need around 60 VCs....
 
 >layeer without worrying about scalability issues.

see
http://www-nrg.ee.lbl.gov/floyd/cbq.html
we don't have to know anything about hosts in this architecture...
(or hack, as i prefer to call it)_

Now should this stay on rsvp, or int-serv, or should i stop discussing
it all together...

 jon

---

From: [email-masked] (Hiroshi Esaki)
Date: Thu, 22 Jun 1995 19:58:51 -0400

Hi, 

I am very sorry again for the mail that may not directly associated 
with Int-serv ML......

 ohta> As is already proven (by me) in this rsvp ML, the only way to use
 ohta> RSVP over the Internet, without losing the scalability property
 ohta> of RSVP, is not to use it with large clouds.
 ohta> That is, the infrastructure of rsvp-bone must support the CATENET
 ohta> model.
I think this is not exactly true. 
RSVP, which provides a soft-state multicast service, requires 
a reasonable fan-out to datalink multicast service (e.g. ATM's 
multicast VCC). 
In order to provide RSVP-type (soft-state) large scale  multicast 
service across the large cloud datalink networks, it is better to
have reasonable size of IP subnets, that are interconnected by 
the routers.   Therefore, large scale RSVP-type multicast will 
work well over LISes in large cloud datalink networks, "IF" the 
size of LIS is reasonable size. 
The point realized at the colip-BoF was that we should keep the 
fan-out from the routers as a reasonable size, if my understanding 
is correct. 

> the RSVP 'soft state' is mapped into dynamic signalling - if the S
 ohta> Unfortunately, no ATM signaling is dynamic.
 ohta> RSVP is the dynamic sigaling.

I interpreted "dynamic signaling" is not the capability of 
[S], e.g. ATM signaling. 
Jon refers PVC ("Permanent"-VC). 
Which PVC is selected as the IP packet forwarding route in [S] 
can be dynamic, by my understanding for Jon's suggestion. 
In other words, PVCs are just pipes that are prepared to be 
picked up as the route where the IP packet will take. 
Therefore, basically, the PVC will be picked up based on 
destination IP address (e.g.multicast address).  Of course, 
the PVC can be picked up based on source destination IP address 
pair (i.e. for end-to-end flow). 

 > "next hop to VC" mapping via NHRP or server arp or something...
  oht> SNMP should have nothing to do with intra-link-layer signaling.
Sorry, I think, for PVC (Permanent VC), it will be fine. 
                    ^^^^^^^^^^^^^^^^^^

  oht> "next hop to VC" MUST be determined by QoS routing and RSVP. NHRP
  oht> can only designate the final-hop outside the current link layer
  oht> in unscalable way and is unrelated the global signaling.
I think Jon just says NHRP can be used within [S] part. 
I think it is not related to the global signaling. 

> renegotiation of VP policing/shaping parameters is possible too,
  ohta> whose parameters MUST be affected by the individual addition
  ohta> of each VCs.
  ohta> That is, handling of VP (and VC) policing is only twice complex
  ohta> as VC-only policing.

I think the end-point of VP will perform cell scheduling as that 
the aggregated cell flow of VCs in the VP will not violate the
VP policing parameter. 
Within the VP, how to schedule the cells of VCs is a matter of 
the entity at the end-point of the VP. 

Hiroshi Esaki 
(c/o CTR, Columbia University)