Subject: reading for INT SERV meetings

From: Craig Partridge <[email-masked]>
Date: Thu, 24 Mar 94 14:37:13 -0800

There are three items of recommended reading:

1. The Integrated Services overview document (from last IETF's BOF)

    ftp.isi.edu:pub/braden/isip/overview.{ps,txt}

2. The Integrated Services WG proposed charter and management plan (appended
    to this note)

3. Section 4 of the recent IAB workshop report

    ftp.isi.edu:pub/braden/IABworkshop.txt (just section 4)


***************************************************************************

Integrated Services Working Group Management Plan

The General Chair is Craig Partridge (BBN).  The Co-Chairs are Dave Clark
(MIT), Scott Shenker(XEROX), and John Wroclawski (MIT)

The dual reasons for this management structure are:

    (1) The WG will have do considerably more outreach into the larger
    networking community than the typical IETF working group.  For instance,
    one of the important tasks is to convince the larger public that IP
    is suitable for integrated services.  So we need management manpower
    to do outreach.

    (2) The WG has a lot of work to do and swiftly.  Even though we plan to
    spin off WGs as fast as we can, a lot of key architectural decisions will
    need to be made in one place (e.g., by this WG) if the final architecture
    is to be sound.  So we need management manpower just to keep the WG
    moving.

So Craig has primary responsibility for keeping the WG moving, and Dave,
Scott, and John have primary responsibility for outreach to different
communities (and titles sufficient to show they can speak for the WG).


***************************************************************************

Integrated Services Working Group Charter

Description of Working Group:

    Recent experiments demonstrate the capability of packet switching
    protocols to support Integrated Services - the transport of audio,
    video, real-time, and classical data traffic within a single network
    infrastructure.  These experiments suggest that expanding the Internet
    service model would better meet the needs of these diverse applications.
    The purpose of this working group is to specify this enhanced service model
    and then to define and standardize certain interfaces and requirements
    necessary to implement the new service model.

    The working group will focus on defining a minimal set of global
    requirements which transition the Internet into a robust
    integrated-service communications infrastructure.  Enhancements to
    individual protocols (e.g., adding additional routing information to
    routing protocols, or choosing IP queueing disciplines for routers)
    will be left to other working groups, except in those rare cases where
    detailed definitions of behavior are critical to the success of the
    enhanced architecture.

    Extending the Internet service model raises a series of questions.
    The working group will focus on the three problems listed below:

    (1) Clearly defining the services to be provided. The first task faced
    by this working group is to define and document the enhanced Internet
    service model.

    (2) Defining the application service, router scheduling and (general)
    subnet interfaces.  The working group must define at least three
    high-level interfaces; that expressing the application's end-to-end
    requirements, that defining what information is made available to
    individual routers within the network, and the additional expectations
    (if any) the enhanced service model has for subnet technologies.  The
    working group will define these abstract interfaces.

    (3) Developing router validation requirements which can ensure that
    the proper service is provided.  We assume that the Internet will
    continue to contain a heterogeneous set of routers, running different
    routing protocols and using different forwarding algorithms.  The
    working group will seek to define a minimal set of additional router
    requirements which ensure that the Internet can support the new
    service model. Rather than presenting specific scheduling and admission
    control algorithms which must be supported, these requirements will likely
    take the form of behavioral tests which measure the capabilities of
    routers in the integrated services environment. This approach is used
    because no single algorithm seems likely to be appropriate in all
    circumstances at this time.

    We expect to generate three RFCs as a products of performing these
    tasks.

    In addition, because many of the integrated services concepts are new,
    the WG may produce informational RFCs explaining specific algorithms
    that may be appropriate certain circumstances and may host some
    educational meetings to assist both IETF members and members of the
    larger Internet community to understand the proposed enhancements to IP.

    The WG proposes to hold regular meetings beyond those held at IETF.


Goals and Milestones:

    [These milestones are conservative.  We hope to finish much more quickly
    than this.]

    4/94: Seattle IETF: First full meeting of working group.  Discuss
    proposed service model.  Discuss strategy for addressing other issues.

    11/94: Submit informational RFC on service model.  Discuss initial
    draft documents describing router requirements and strategies for
    behavioral testing.  Hold coordination meeting with RSVP Working Group
    (and perhaps others as well) to discuss Application (end-to-end) PI.

    3/95: Continue discussion of router requirements. Develop
    experimental verification of behavioural testing approach. Continue
    discussion of API and subnet models.

    11/95: Submit router requirement RFC.  Finalize API.

    3/96: Submit API.  Finalize subnet model.

    6/96: Submit subnet RFC.

The WG mailing list is [email-masked]

---

From: Simon E Spero <[email-masked]>
Date: Thu, 24 Mar 94 20:34:37 -0500

Convince the general public that IP is suitable for Integrated Services?>
I think you have to convince half the IETF too! Mind you, judging from our 
experiences here with the North Carolina Information Porkway, ATM gives
you disintegrated services too. 
Simon // NCIH - gigabits for biga-grits.

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 25 Mar 94 11:20:36 JST

> Simon // NCIH - gigabits for biga-grits.

Could you read the following Internet Draft too see that ATM can give
us Integrated Services with IP.

							Masataka Ohta
------------------------------------------------------------------------

INTERNET DRAFT                                                   M. Ohta
draft-ohta-ip-over-atm-00.txt              Tokyo Institute of Technology
                                                              March 1994

                        Conventional IP over ATM

Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months.  Internet-Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet-
   Drafts as reference material or to cite them other than as a
   ``working draft'' or ``work in progress.''

   To learn the current status of any Internet-Draft, please check the
   1id-abstracts.txt listing contained in the Internet-Drafts Shadow
   Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or
   munnari.oz.au.

Abstract

   The possibility to construct a conventional model to transfer IP over
   ATM is studied.

   The model contains concepts of subnet, bridges, routers, broadcast
   and so on, all of which are familiar with the model of IP over
   Ethernet.

   Still, the model allows QoS assured seamless network level (not
   datalink level) ATM connection which can be directly supported by
   existing ATM hardware. That is, new communication model with resource
   reservation such as RSVP or STII can be supported efficiently.

Introduction

   This memo describes a framework of transmitting IP packets over
   existing ATM hardware without assuming any change to the existing
   model of transmitting IP over other media.

   ATM is a good candidate of the platform for very high speed QoS
   (Quality of Services [RSVP, STII]) assured datalink.  But, unlike
   enthusiastic ATM lovers, the Author does not think ATM will rule the
   world.  On the other hand, the Author believes IP will rule the

M. Ohta                 Expires on Sept. 5, 1994                [Page 1]

INTERNET DRAFT          Conventional IP over ATM              March 1994

   world, at which time ATM based equipments must cooperate with other
   media such as Ethernet or something like Ethernet.

   To make the cooperation smooth, it is better if the model of IP over
   ATM is no different from the model of IP over Ethernet.

   Thus, unlike the model of "Classical IP and ARP over ATM" [CLIP],
   which is modified, non-classical IP technology over PDN-like,
   classical, ATM, the conventional model tryies to keep IP as classical
   and conventional as possible.

   The conventional model is designed so that existing ATM hardware can
   be used as is.

Overview of the WAN/LAN model of the Conventional IP

   While other models of IP over ATM [CLIP, IPATM] assumes PDN like ATM
   WAN, which somewhat affects ATM LAN model and is a lot different from
   Ethernet LAN, the conventional model assumes no fundamental
   difference between Ethernet LAN, ATM LAN and ATM WAN.

   It seems to the Author that there is common misunderstanding of many
   ATM experts that cell-by-cell relaying can only be performed at
   datalink layer, which make thier model unnatural. The last section
   shows how network layer cell-by-cell relaying is possible.

   Just as the current IP LAN over Ethernet and IP WAN are fundamentally
   same, ATM LAN and ATM WAN of the model are fundamentally same.

   That is, just as the current T3 backbone, the WAN model of this memo
   is constructed by leased lines directly connecting IP routers, which
   directly support IP protocols including routing.  Routing packets
   will be propagated by WAN operators as maintenance packets.  When IP
   rules the world and WAN is IP, there is no cloud. So, ROLC (Routing
   over Large Cloud) [ROLC] technology is not necessary.

   With the conventional model, just as Ethernet equipments, ATM
   switches are classified into routers or bridges (or brouters, maybe).
   whose roles are no different from those of Ethernet equipments.

   Bridges are datalink layer entity which connect several physical
   layers.  Bridges copy the incoming packets to all of the output ports
   without trying to optimize the path.  If a bridge is a learning
   bridge and knows to which interface the destination is attached,
   unnecessary copying can be suppressed.  If a link level topology
   contains a loop, bridges should support spanning tree algorithm to
   avoid packets copied infinitely along the loop.

M. Ohta                 Expires on Sept. 5, 1994                [Page 2]

INTERNET DRAFT          Conventional IP over ATM              March 1994

   Routers are network layer entity which connect several data link
   layers.  Routers relay packets beyond (sub-)networks.  Routers
   exchange routing information and maintains routing tables.
   Logically, each packet is relayed to the optimal interface by looking
   up the routing table.  Actually, some cache or bypass is often used
   to minimize the routing delay of complex table looking up.

   It is not the business of bridges to choose the best path to the
   destination. Doing so will make the link level layer as complex as
   the conventional link and network level layers added together, which
   is the destruction of layering.  So, to operate a network with a lot
   of hosts and some amount of redundant pathes, the network should be
   divided into several link layers connected by routers to make use of
   the bandwidth of redundant pathes.  It is impractical to have a
   single datalink layer containing a lot of hosts.

   As PVC based network needs a lot of datalink level static
   configuration, it is difficult to manage and unrealistic for the
   network with more than hundreds of hosts.  As exemplified with
   broadcast storm, wrong static setting at datalink level is often
   fatal.  With ATM, if datalink configuration is wrong, cells may loop.
   It should be noted that on point-to-point links such as ATM, looping
   of cells is equally harmful as broadcasted looping on multiple access
   media for the consumed bandwidth of the link.  That is, though
   looping on a single physical link does not affect other physical
   links, single datalink layer looping affect several physical link.
   To make the matter worse, as ATM has no link level hop count, looping
   will continue forever.  So, PVC ATM is not considered in this memo.

Communication over ATM in a Datalink Layer

   Unless a datalink layer is made of a single physical layer, it is
   beneficial for bridges to maintain some amount of connection
   information.

   With Ethernet, without learning bridges, all the packets are copied
   to all the physical layers. With learning bridges, as a packet is
   relayed by bridges, bridges learn from which interfaces the packet is
   received, which is equivalent to the path setup to the source of the
   packet. If two hosts exchange packets, a soft connection between the
   hosts are established as the state of learning bridges.

   With ATM, things can be no different, though additional support for
   more rigid connection may present.  Such a rigid connection is
   necessary and useful to assure QoS.  If QoS is not necessary,
   datalink communication may be just like that of Ethernet. To do so,
   an AAL containing the MAC addresses of the sender and the receiver in
   the first cell is necessary.  ATM bridges then peek into the first

M. Ohta                 Expires on Sept. 5, 1994                [Page 3]

INTERNET DRAFT          Conventional IP over ATM              March 1994

   cell and learn that the sender is located toward the incoming
   interface of the cell.  Then, if the receiver's location is not
   learned, cells are broadcasted.  Unfortunately, the scheme can not be
   supported efficiently by the current hardware.  Alternative way is to
   use broadcasted ARP [EARP] followed by signaling to establish SVC
   between a pair of hosts.

   As for broadcast, at a physical layer, there is no such thing as NBMA
   (Non-Broadcast Multi-Access).  Regardless of whether the layer is
   point-to-point or multiple-access, everything a sender sends is
   received by all the hosts connected to the layer.

   So, it is not surprising that a datalink layer attempt to throw way
   the physical layer property results in serious loss of information
   necessitating some static configuration [ROLC].  Thus, the
   conventional wisdom of the conventional IP is to support broadcast at
   the link layer.  It should be noted that, with conventional IP, the
   size of a well-managed datalink layer is not so large. So, excessive
   amount of copying of a broadcast packet does not occur.

   Ethernet bridges copies broadcast packets to all the interfaces (on
   the spanning tree).  ATM bridges can also do so.  Most of existing
   ATM switches have efficient hardware mechanism of such copying to
   support point-to-multipoint connections.

   Moreover, broadcast is the only way to communicate with neighbors
   without prior knowledge of neighbor's addresses.  For example, one of
   the goals of DHCP (Dynamic Host Configuration Protocol) to make hand
   configuration completely unnecessary, can not be achieved without
   broadcast.

   So, there seems to be no reason not to have broadcast with ATM.

   This memo does not further address the detail on broadcast with ATM.
   Assuming NBMA ARP within a datalink layer does not affect the rest of
   the memo.

Conventional Communication over ATM in a Network Layer

   The conventional communication, that is communication that does not
   assume connectivity, is no different from that of the existing IP, of
   course.  Communication within a datalink layer is performed as
   described in the previous section.  Communication beyond datalink
   layers is performed by first communicating to a router.  Routers
   exchange routing information and forward packets decrementing TTL by
   one or more toward the next hop routers.  No further explanation is
   necessary nor given.

M. Ohta                 Expires on Sept. 5, 1994                [Page 4]

INTERNET DRAFT          Conventional IP over ATM              March 1994

   Though it is possible to reduce hop count by having ATM connections
   between non-adjacent routers, it is beyond the scope of the
   conventional model and not discussed in this memo.

Connection Oriented QoS Assured Communication over ATM

   The goal of connection oriented communication is to provide end-end
   IP connection. Such a connection is necessary to have QoS-assured
   communication.

   Unlike other models of IP over ATM, the model in this memo assumes
   QoS-assured communication over not only ATM but also other types of
   media.

   The model, in general, is not so different from that of the previous
   section, though seamless optimization is possible for communication
   between ATM datalinks.

   It is assumed that QoS assurance protocol within a datalink layer is
   present and is preformed by hosts (including routers) attached to the
   layer. How it will be is not addressed in this memo.

   Communication within a datalink layer can directly use the protocol
   and needs no special care.

   Communication beyond datalink layers is performed by first
   establishing QoS assured connection to a neighbor router.  Routers
   then establishes the QoS connection using the datalink level
   reservation protocol to the next hop router until the destination is
   reached.  Some processing power of routers should also be reserved.

   After the connection is established, packets are forwarded through
   the QoS assured datalink connection.

   As there can be multiple QoS assured connection between the source
   and the destination, some identifier other than source/destination
   addresses is necessary to uniquely identify a connection.

   A single identifier, called flow ID, could be used along the
   connection. The pair of the source address and the flow ID uniquely
   identifies the connection.

   In general, QoS assured communication can be routed to an appropriate
   next hop datalink connection by flow ID.

   That is:

      1) a packet arrives at a router

M. Ohta                 Expires on Sept. 5, 1994                [Page 5]

INTERNET DRAFT          Conventional IP over ATM              March 1994

      2) packet's flow ID and source address are checked and the next
      hop is determined

      3) packet's TTL is decremented by 1 (or more)

      4) unless the router is the destination, the packet is forwarded

   the above scheme assumes nothing ATM specific and applicable to all
   the QoS assured media such as a fixed speed dedicated link, FDDI II
   or switched Ethernet.

   With ATM, packets are reassembled at step 1) and re-celled at step
   4), which means certain amount of delay and certain amount of
   processing overhead and is not so desirable.

   Optimization is possible by making use of the fact that flow ID is
   not necessary at step 2).  That is, if some information to identify
   flow locally at each interface is provideed, it is enough to
   determine the next datalink connection.  With ATM, VCI/VPI is such
   locally unique identifier.  Moreover, ATM equipments have efficient
   hardware mechanism to forward cells based on VCI/VPI of incoming
   cells.

   So, if both the incoming and outgoing interface are ATM, the
   following cell-by-cell scheme works:

      1) a cell arrives at a router

      2) cell's VCI/VPI/incoming_interface is checked and the next hop
      VCI/VPI/outgoing_interface is determined by hardware

      3) unless the router is the destination, the cell is forwarded

   It is assumed that information used at the step 2) is provided during
   the connection establishment.

   Thus, if ATM hosts communicate purely over ATM routers, a seamless
   single ATM link is established between them.  It should be noted
   that, though many think ATM connection is considered to be at the
   datalink layer, the above seamless connection on ATM routers is at
   the network layer.  So, all the network layer property such as the
   selection of the best path is naturally available.

   Seamlessness, here, should considered to be something like lower
   level caching. Whether some ATM equipment forward information cell by
   cell or packet by packet is merely an internal implementation detail,
   which does not affect the classification on whether the equipment is
   considered to be a bridge or a router.

M. Ohta                 Expires on Sept. 5, 1994                [Page 6]

INTERNET DRAFT          Conventional IP over ATM              March 1994

   The problem of the scheme above is that TTL of the packet is not
   decremented at all.  If ATM routers recognize AAL and can decrement
   TTL by hardware, it's OK. But, currently, they can't.

   As the number of routers along the seamless path is known in advance,
   packets with insufficient TTL may be dropped at the starting point of
   the seamless link.

   The TTL issue never be an issue in practice, unless the path itself
   is setup to form a loop, in which case no models of IP over ATM with
   seamless connection can function, anyway.  Resource reservation
   protocols should be designed to make the formation of the loop
   completely unlikely.  The lack of datalink level TTL makes the
   looping serious issue.  It might be necessary in the future to design
   a new AAL that supports cell-wise or packet-wise TTL supported by
   hardware.

References

   [CLIP] M. Laubach, "Classical IP and ARP over ATM", RFC1577, January
          1994.

   [EARP] D. Plummer, "Ethernet Address Resolution Protocol: Or
          converting network protocol addresses to 48.bit Ethernet
          address for transmission on Ethernet hardware", STD37, RFC826,
          November 1982.

   [IPATM] An Internet Draft may be available (J. Heinanen, R. Govindan,
           "IP over ATM: A Framework Document", <draft-ietf-atm-
           framework-doc-00.txt, .ps>).

   [ROLC] An Internet Draft may be available (J. Heinanen, R. Govindan,
          "NBMA Next Hop Resolution Protocol (NHRP)", <draft-ietf-rolc-
          nhrp-00.txt>).

   [RSVP] An Internet Draft may be available (L. Zhang, R. Braden, D.
          Estrin, "Resource ReSerVation Protocol (RSVP) -- Version 1
          Functional Specification", <draft-braden-rsvp-00.txt, .ps>).

   [STII] C. Topolcic, "Experimental Internet Stream Protocol, Version 2
          (ST-II)", RFC1190, October 1990.

Acknowledgements

   This memo is a result of discussion in TNG (The Next Generation)
   working group of JAIN consortium.  Many ATM experts in Japan
   including Hiroshi Esaki of Toshiba, Masayuki Murata of Osaka
   University, Kenji Fujisawa of SONY, Yuichiroh Nozue of Sumitomo

M. Ohta                 Expires on Sept. 5, 1994                [Page 7]

INTERNET DRAFT          Conventional IP over ATM              March 1994

   Electric Industries and Akira Chugo of Fujitsu have contributed to
   the discussion.  Interested parties are encouraged to read the
   original discussion (available as ftp.jain.ad.jp:pub/archive/tng-wg
   in Japanese with ISO-2022-JP encoding).  Among all the contributers,
   the only reason that Hiroshi Esaki is not the co-author of this memo
   is to avoid complex formalities to get publication permission from
   his company.

Security Considerations

   Security issues are not discussed in this memo.

Authors' Address

   Masataka Ohta
   Tokyo Institute of Technology
   2-12-1, O-okayama, Meguro-ku,
   Tokyo 152, JAPAN

   Phone: +81-3-5499-7084
   Fax: +81-3-3729-1940
   EMail: [email-masked]

   Comments may also be directed to:

   TNG Working Group
   JAIN Consortium
   EMail: [email-masked]

M. Ohta                 Expires on Sept. 5, 1994                [Page 8]

---

From: Craig Partridge <[email-masked]>
Date: Thu, 24 Mar 94 21:12:12 -0800

Simon:

    Yes we have to convince some folks in IETF.  However I think it is
less than half the IETF.  Anyone who believes that ATM can support integrated
services must axiomatically believe IP can support integrated services, since
(but for some low-order terms) the theoretical work saying ATM works for
integrated services applies to IP too.  This means that the only folks we
have to convince are those folks who believe ATM is a bad idea, and based
on the frequency which which ATM is mentioned favorably on IETF lists, I
suspect the folks who think ATM is a bad thing constitute less than half
the IETF.... :-)

Craig

---

From: Christian Huitema <[email-masked]>
Date: Fri, 25 Mar 1994 10:20:03 +0100

=>     Yes we have to convince some folks in IETF.  However I think it is
=> less than half the IETF.  Anyone who believes that ATM can support integrated
=> services must axiomatically believe IP can support integrated services, since
=> (but for some low-order terms) the theoretical work saying ATM works for
=> integrated services applies to IP too.  This means that the only folks we
=> have to convince are those folks who believe ATM is a bad idea, and based
=> on the frequency which which ATM is mentioned favorably on IETF lists, I
=> suspect the folks who think ATM is a bad thing constitute less than half
=> the IETF.... :-)

.. not to mention a number of folks who believe that ATM is a bad idea because
it is based on a circuit-switching paradigm, which is not needed for
integrated services. In fact, I believe that a lot of what ATM is claimed to
provide, e.g. phone circuits or video circuits, can easily be achieved with
conventional datagram IP.

Christian Huitema

---

From: Andy Malis <[email-masked]>
Date: Fri, 25 Mar 1994 09:28:38 -0500

Christian,

> In fact, I believe that a lot of what ATM is claimed to provide,
> e.g. phone circuits or video circuits, can easily be achieved with

Well, what makes this "interesting" to discuss, and less than obvious
to implement, are the mechanisms used to provide the appications'
required quality of service under other than very lightly loaded
conditions (and without adding an inordinate amount of overhead,
resource overreservation, or other wastage).  But then I'm not telling
THIS crowd anything!

I'm looking forward to the BOF.

Cheers,
Andy
__________________________________________________________________________
Andrew G. Malis   [email-masked]             +1 508 266-4522
Ascom Timeplex    289 Great Rd., Acton MA 01720 USA   FAX: +1 508 264-4999

---

From: Christian Huitema <[email-masked]>
Date: Fri, 25 Mar 1994 15:48:17 +0100

=> Christian,
=> 
=> > In fact, I believe that a lot of what ATM is claimed to provide,
=> > e.g. phone circuits or video circuits, can easily be achieved with
=> > conventional datagram IP.
=> 
=> Well, what makes this "interesting" to discuss, and less than obvious
=> to implement, are the mechanisms used to provide the appications'
=> required quality of service under other than very lightly loaded
=> conditions (and without adding an inordinate amount of overhead,
=> resource overreservation, or other wastage).  But then I'm not telling
=> THIS crowd anything!
=> 

Hey, I am not that ignorant. I know pretty well that a datagram network does
not guaranty a quality of service! What I mean is that for classic audio or
video application, in a point to point or small group environment, it is
possible to design applications that adapt dynamically to the network's
quality of service. Much in the same way that the average TCP adapts its
windows to the variable networking conditions.

Christian Huitema

---

From: Andy Malis <[email-masked]>
Date: Fri, 25 Mar 1994 09:55:48 -0500

Christian,

> not guaranty a quality of service! 

Peace ... sorry about that - I certainly didn't intend to imply
anything of the sort!

> What I mean is that for classic audio or

Absolutely - however, is the BOF (and WG that follows) going to
confine itself to the Internet layer and service model to meet the
requirements of existing applications, or is it also going to work on
application design as well?  Specifying application service
requirements is already on the charter, but do we need to go beyond
that?  It's an important question of scope that we'll have to discuss
in the meeting.

Cheers,
Andy

---

From: Steve Deering <[email-masked]>
Date: Fri, 25 Mar 1994 07:36:12 PST

> resource overreservation, or other wastage).

A possible answer is:

	(1) receiver buffering to make applications jitter-tolerant,

	(2) layered, VBR media encodings to provide elasticity of demand,

	(3) statistical fair queueing to share bandwidth equally among all
	    active, competing sources,

	(4) priority dropping within a single source's packets, so that
	    when they don't all fit in the source's current share of a
	    link, its less important layers get dropped before its more
	    important layers,

	(5) low rate feedback from receivers on reception success for
	    specific layers, so that packets in insufficiently well
	    received layers can be suppressed before reaching the
	    congestion point (in the case of multicast, this feedback
	    takes the form of joining/leaving different multicast groups
	    for different layers), and

	(6) no less link bandwidth than the alternative ATM infrastructure.
	    More would be nice -- whether or not any such "wastage" is a
	    good engineering choice will depend on the price of bandwidth,
	    which is related more to policy/regulatory/monopoly issues than
	    anything else.

Steve

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 25 Mar 94 12:58:16 -0500

> Convince the general public that IP is suitable for Integrated
> Services?> I think you have to convince half the IETF too! Mind you,
> judging from our experiences here with the North Carolina Information
> Porkway, ATM gives you disintegrated services too.

Simon,

If you can convince the people who are will be responsible for the
vBNS level 3 service, that's a big win.  If you can convince them now,
they will try to convince router vendors to move quickly in this area.

Of course, if they are already convinced, then you just have to
produce standards that they can ask router vendors to implement.
In fact, they may have already spoken to router vendors about
requirements like best-effort real time, RSVP using IPv4, and link
sharing and would like something that can be implemented with the
blessing of an IETF standardization effort and the benefits of smart
people like the chair and co-chairs of this group.  [HINT!!!]

No one has quite won the vBNS bid yet, but there is certainly a short
list of parties that might have to be convinced.  Nothing quite like a
major existance proof to win people over.

Curtis

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 26 Mar 94 17:04:01 JST

> A possible answer is:

Use STII, RSVP or any other resource reservation protocol at internetwork
layer.

If QoS requirement is strict, we should also use datalinks which support
connectionless communication AND QoS assured connection oriented
communication.

						Masataka Ohta