The IP Over NBMA (ION) Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Integrated service does not scale over non-IP large cloud
As the debate on CSRs in ION ML seems to have stablized, the
below is an Internet Draft on why we must abandon NHRP.
Any counter proof or other comments?
Please reply to an appropriate mailing list.
Masataka Ohta
INTERNET DRAFT M. Ohta
draft-ohta-mcast-large-cloud-01.txt Tokyo Institute of Technology
June 1996
Multicast Inscalability over Large Cloud
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
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as ``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 ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
This memo describes a scalability issue when multicasting to a large
number of recipients over a non-IP large cloud.
The proof is quite generic that no detailed knowledge on specific
protocols, such as RSVP nor NHRP, necessary.
1. Background
It is expected that networks in the future offer the integrated
service: an integration of best effort service and QoS-assured
service and an integration of communication and broadcasting.
Some people believed that ATM is the network to offer the integrated
service and tried to map IP over Q.2931 signaled ATM network to have
the integrated Internet over ATM.
But, to support real-world TV broadcasting, multicast-capable
signaling (or, with IP terminology, resource reservation) protocol
must be scalable up to millions or even billions of receivers.
Such a requirement is satisfied by a multicast protocol with leaf
initiated join where receivers' join requests are propagated toward
M. Ohta Expires on December 10, 1996 [Page 1]
INTERNET DRAFT Multicast Inscalability over Large Cloud June 1996
the sender. During the propagation, the requests can be merged on
intermediate entities within the network so that the number of the
join requests received by the sender is bounded.
That is, such an algorithm can scale with arbitrary large number of
receivers.
For example, both the Internet with RSVP [RSVP] signaling and ATM
networks with UNI4.0 Q.2931 signaling scale.
A problem proven in this memo is that such scalability is lost when
IP signaling mechanism, such as RSVP, is used over a non-IP large
cloud such as large Q.2931 signaled ATM network.
2. Assumptions
To proof the inscalability, an IP signaling mechanism of RSVP over a
large cloud of a Q.2931 signaled ATM network is assumed.
No absolute size of the large cloud is assumed. Instead, it is
assumed that the cloud is so large that it can't be regarded as a
single IP subnet with broadcast ARP or even with NBMA technology such
as ATMARP.
It is assumed that sufficiently large percentage of people watch the
same TV program simultaneously. For example, a prime time TV program
may have an audience rating of 20% or even 30%.
Finally, it is assumed that audiences can't wait so long until their
reservations stabilize. RSVP-like soft state signaling needs frequent
state refresh with a period of some seconds or, at least, few
minutes. Even with hard state signaling, people usually can't wait
so many minutes for stability at the beginning of a TV program to
which 10% of audiences send signaling at once.
3. Proof
By definition of a cloud, it is impossible to let entities in a non-
IP large cloud recognize IP based protocol and perform some
operation.
That is, it is impossible to let entities in the cloud perform merge
operation of RSVP signaling.
But, if receivers or intermediate routers at the edge of the cloud
directly send their signaling request directly toward the sender,
signaling requests implode at the sender (or an intermediate router
to the sender) and will fail (note the assumption that the cloud is
M. Ohta Expires on December 10, 1996 [Page 2]
INTERNET DRAFT Multicast Inscalability over Large Cloud June 1996
so large to cause a scalability problem with ATMARP or LANE).
A usual workaround is to attach layers of RSVP merge servers to the
cloud and perform layered merging by them. But, the merge related to
some traffic parameter such as delay is impossible without some
knowledge local to the actual dataflow branch point. That is, merged
delay requirement can not be computed without the knowledge on the
actual delay between the receiver and the actual merge point.
That is, RSVP multicast over an ATM large cloud does not scale.
Still, there may be a workaround not to use RSVP within the cloud but
to scalably use Q.2931 signaling, and translate between them at the
edge. But, RSVP and Q.2931 signaling are quite different each other
and such translation is impossible. The workaround eventually
requires a lot more than peer model to support two network layer
packet formats with different syntax but the equivalent semantics.
Now, remember that IETF have abandoned CLNP and decided to
concentrate on a single network layer protocol [RFC1958].
4. Solution
It is now proven that, as long as we need the integrated service over
the Internet, we shouldn't have a large number of IP hosts over a
large non-IP cloud.
The Internet with the integrated service will continue to exist with
the Catenet model. RFC1620, NHRP [NHRP] and RFC1937 are obsoleted.
For IP over NBMA protocols, we don't have to mind the scalability.
But, it does not mean that ATM, the cell-relaying technology, is
obsoleted.
While IP over Q.2931 signaled ATM does not scale, it is possible to
signal ATM switches and set up its cell switching fabric not by
Q.2931 but by RSVP.
By combining an IP packet router with an RSVP-signaled ATM switch, we
can construct a CSR (cell relaying router), which seamlessly connects
two ATM subnets, we can scalably form an end-to-end cell relay over
the large scale ATM Internet [CSR1, CSR2, RFC1953, RFC1954].
It should be noted that CSRs need no modification to the existing
Internet architecture, including but not limited to routing,
multicasting, security, the amount of states on routers.
5. References
M. Ohta Expires on December 10, 1996 [Page 3]
INTERNET DRAFT Multicast Inscalability over Large Cloud June 1996
[CSR1] Hiroshi ESAKI, Ken-ichi NAGAMI, Masataka OHTA, "High Speed
Datagram Delivery over Internet using ATM Technology",
Networld+Interop '95 Engineer Conference, E12-1~E12-9, (1995).
[CSR2] Yukinori GOTO, Masataka OHTA, Masaki HIRABARU, "Design of
Internet Resource Reservation on ATM Network", Proceedings of The
10th International Conference on Information Networking (ICOIN-10),
pp.510-516, 1996.
[NHRP] draft-ietf-rolc-nhrp-07.txt
[RSVP] draft-ietf-rsvp-spec-12.txt
6. Security Considerations
It is obvious that, within a non-IP cloud, IP firewalling is
impossible, which WAS a problem with NHRP.
On the other hand, Catenet model with CSRs are capable of IP
firewalling by rejecting improper reservation requests.
7. Author's Address
Masataka Ohta
Computer Center
Tokyo Institute of Technology
2-12-1, O-okayama
Meguro-ku, Tokyo 152, JAPAN
Phone: +81-3-5734-3299
Fax: +81-3-5734-3415
EMail: mohta@necom830.hpcl.titech.ac.jp
M. Ohta Expires on December 10, 1996 [Page 4]
|
|