Subject: Re: deploying reservations....

From: Lixia Zhang <[email-masked]>
Date: Sat, 8 Jul 1995 11:44:13 PDT

Disclaimer: I dont know how much this is related to the charter of
Int-Serv; but given others have talked the issues here, I thought I
could say a few words too :-)

Jon can correct me, but I feel that his original intension was
something else other than what's being discussed.

-> Actually, I think Jon's model is exactly opposite the COLIP model,
-> in some senses:  Jon interconnects IP links with an ATM node, while
-> COLIP interconnects ATM links with an IP node.
-> 
-> 
-> Crowcroft model                                    .---.
-> (= conventional IP over           <----->IP-Router-|ATM|-IP-Router<----->
->  ATM-cloud QOS-mapping problem):                   .---.
-> 
-> 
-> Colip model                                     .---------.
-> (= QOS scheduling in router,       <------->ATM-|IP-Router|-ATM<-------->
->  but transport interfaces are ATM):             .---------.

The pictures certainly clarified the models.

The first model was from Jon's pragmatic goal of how to deploy
RBone in today's NAP-connected provider world.  The box in the middle
is just a switch; it is *not* ATM today; will it be later?  we're yet
to see (I heard that two NAPs tried but never made it :-)

I'd be very interested in the RBone discussion.  Jon, are you still
pursuing the idea?

For the issue of how to run IP over ATM,

-> If ATM provides
-> completely isolated connections, like "guaranteed pipes", then
-> the problem is rather uninteresting.

uninteresting to ATM, since it doesnt have much "value added",
but may not be bad for others :-)

- > If, however, the ATM QOS
-> menu is rich, then the ATM connection can be set up to correctly allow
-> the traffic from a flow to share resources with other similarly
-> QOS-ed flows.  If the behavior in the ATM scheduler (essentially
-> the policy of isolation and sharing) is very close to what would
-> happen in the IP w/ QOS router scheduling, then all of the
-> efficiency and QOS benefits of proper traffic management
-> can be obtained in the ATM cloud.  So the end to end route can
-> be chosen to run through ATM-based networks and/or IP-based networks
-> (in the sense of network providers) as is convenient.
-> If the ATM cloud *cannot* effectively combine streams, and has
-> to provide plain-old isolated pipes to effect any QOS at all,
-> then we're in trouble

I feel there is some issue here that's deeper than just how IP and
ATM's QOS can map each other.  Assume ATM can do anything it wants,
should IP buy the service in whole sale, or retail mode?

For the former, IP just buys one pipe and controls all traffic muxing
itself.  For the latter (that ATM community wants to see happen), you
buy one VC per flow at a time.

Lixia

---

From: Hiroshi Esaki <[email-masked]>
Date: Sat, 8 Jul 1995 21:19:31 -0400

Just short comment on Lixia's words. 

 >> buy one VC per flow at a time.

I think, Lixia shows two extreme operation policy. 
One is that all IP flows are aggregatd into one VC with IP level 
scheduling.  The other is that one IP flow is mapped to one VC. 
In the actual operation, some IP flows will have one-to-one mapping 
with ATM-VC, and some IP flows will be aggregatd into one VC. 
Also, one may use only one ATM-VC to transport all IP flows, even 
IP flows in the ATM-VCC require different QOS level. 
Personalily, I think, how to map/aggegate IP flows with/into ATM-VC 
should have variety.  

Regards, 

Hiroshi Esaki.

---

From: Jon Crowcroft <[email-masked]>
Date: Sun, 09 Jul 95 15:36:55 +0100

>I'd be very interested in the RBone discussion.  Jon, are you still

yes, I am still interested in pursuing this.....we already are using
something of a hybrid of this - basically, my model is that 
the Crowcroft model is feasiable because we can use smart small
switches off the shelf, [whereas in the wide area, trying to field the
colip model, while i am 101% sympathetic to its goals, in our expereice in
the PNO pilot showes thaty we will be highly unlikely to get more than a
VP service (and with very limited traffic classes) out of WAN ATM so
we may as well treat the WAN to all intents and purposes as a CBR network,
even if  it is pervasive.....the idea of co-locateing routers and
being able to influence SVC parameters via RSVP is an anathwema to
public operators right now ... maybe one day...)

 >buy one VC per flow at a time.

well, with "ATM - in a NAP box" Crowcroft model, the ATM can be pretty
dumb if the routers around its edges are doing all the smarts.....but
small switches are getting to be quite cute (e.g. we have used the GDC
DV2 and the Fore ASX200 with latest ports to mix traffic classes with
a lot of success [finally....]

in fact, this may be a good way to build the "enterprise"
internetwork....(if not, beam me up, scotty:-)

 jon

---

From: Hiroshi Esaki <[email-masked]>
Date: Sun, 9 Jul 1995 22:00:33 -0400

Jon, 

 >> internetwork....(if not, beam me up, scotty:-)

For me, this model see,s to be similar to the architecture 
discussed in MPOA (multi-protocol over ATM) at ATM Forum. 
# I think Crowcroft model appoach and MPOA's approach is quit 
  reasonable, at least, for LAN.  For WAN, many solutions might 
  co-exist. 

Regards, 

Hiroshi Esaki

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 14 Jul 95 0:22:04 JST

> switches off the shelf,

No one doubt your model work in a small environment.

> [whereas in the wide area, trying to field the

It is well known that the current telco networks are not working
well, which is why the Internet is expected to be a basis of GII.

Today, there already are large-scale IP service providers.

Are there any reason why such providers can't replace their
routers with RSVP-capable ones?

Moreover, we expect that, in the near future, all the telephones
will have IPv6 addresses, don't we? If so, are there any reason
why telcos can avoid using IP routers?

							Masataka Ohta