Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!usc!samsung!crackers!martillo From: martillo@crackers.clearpoint.com (Martillo) Newsgroups: comp.dcom.lans Subject: Re: WAN Bridge/Router over Fractional T1 (64K) Message-ID: <1936@crackers.clearpoint.com> Date: 16 Apr 91 03:31:47 GMT References: <1991Mar27.152925.8267@exloghou.portal.com> Organization: Clearpoint Inc., Hopkinton, MA Lines: 239 In article , emv@ox.com (Ed Vielmetti) writes: > In particular it let me determine what the Clearpoint product was not > going to be interesting in the short to medium term because it did not > support the point to point protocol (ppp), and that is a primary > requirement for routers/bridges that I am now evaluating. > Msen Edward Vielmetti > emv@msen.com The Clearpoint Little Dipper is at present a transparent bridge. According to the current indices at sri-nic.arpa there is no RFC specifying the use of PPP as an encapsulation for transparent bridging over WAN links. And of course, there are no national or international standards for such a specification. Consequently, Vielmetti's comment is rather puzzling. I believe I have seen a draft of an RFC for using PPP as an encapsulation for transparent bridging over WAN links but this draft was in such a rough state that following it would not be appropriate to use as a specification. After seeing Vielmetti's comment, I reread RFCs 1171 and 1172. This rereading reinforced my conclusion PPP is rather inelegant, mostly harmless and not terribly relevant. I) INELEGANCE A) Addressing, CCITT, the PTTs and ISO The addressing structure of the CCITT LAP protocols is one of their many irritating features. LAPD provides a slight improvement but not much. I assume that the frame format specified on RFC 1171 p. 5 is an attempt to make PPP "compatible" with the CCITT protocols in the hope that ANSI, ISO or the CCITT might make PPP a national or international standard. If such is the case, the attempt is pointless. Such standards are expressions of national and international policy. Unless the US State Department takes interest (extremely unlikely), PPP will have no success whatsoever. There are good reasons for the absence of probability of success: 1) The PPP RFCs suggest no obvious method of billing except perhaps timed circuit or leased-line billing. 2) The PTTs are ill-disposed to DARPA Internet style computing and all protocols associated with such networking systems. 3) ISO is committed to a very different architecture of computer networks than the DARPA Internet uses and association with the DARPA Internet will prevent any acceptance of such a standard. Billing is a serious issue because people use packet networks when they want to be billed on a per-packet basis. But in an internet, who should be billed? The endpoint or the person who contracts for an intermediate link. Also IP packets in an internet have no fixed route through a concatenated network and the medium is unreliable. Concatenated networks are a big no-no for the PTTs because they allow the possibility of tail-end hop-off in that packets may hop in and out of public networks to avoid long distance charges. Such routing is generally illegal in a large part of the world. ISO accepts and reflects the needs and preference of the PTTs. In ISO OSI, the communications subnet contains all the networking logic and provides end-to-end service to relatively simple end terminals which take no part in the actual networking logic. The DARPA Internetwork assumes that the communications subnet might be rather simple (like an ethernet coaxial cable for example) and that network hosts which could be relatively powerful computer systems will take part intimately in the actual logic or routing packets through the network. Both models have their domain of application, but even with the frills, ornamentation and its somewhat antique style, PPP belong more to the ARPA Internet model than to the ISO OSI model. B) Frame Check Sequence RFC 1171 p. 7 and p. 8 states the following. "The Frame Check Sequence field is normally 16 bits (two octets). By prior agreement, consenting PPP implementations may use a 32-bit (four-octet) FCS for improved error detection." Actually, if dial-up service is to be permitted, I would argue that in the interest of convenience for network administrators the type of FCS should actually be autodetected. In fact, autodetecting the FCS in this situation is so easy that I have to wonder whether the members of the IETF who worked on this part of the specification actually had much experience with implementing this sort of protocol. II) HARMLESSNESS a) The PPP Link Control Protocol (LCP) The FSA is rather ornate, but I will admit to having had to code protocols with even more complicated crenelations, so I guess it could be worse. Personally I prefer the Link Control Protocol associated with Ethernet 2.0 perhaps with the addition of a very simple ping-pong procedure. b) PPP counters and Link-Manager Packets These are rather entertaining, and I can understand why the telephone companies keep and exchange such information over their links. But in DARPA Internet style computer networking, this information should be kept local and be available via applications which use protocols implemented on top of IP. In this way information is potentially available across a concatenated network. Of course, there is nothing harmful about exchanging such information via link-level packets. The effort for such information exchange is simply reduplicative of efforts which *must* be done elsewhere. III) IRRELEVANCE Since PPP is basically a link-level encapsulation with delusions of grandeur, this protocol is essentially irrelevant for any sort of sophisticated computer networking via serial links. Generally, transmitting data over serial links requires sophisticated user-transparent load-sharing over connections, which might be both packet and circuit connections as well as user-transparent programmed link and band-width allocation. PPP provides no mechanism for such procedures, which is not necessarily within the purview of PPP anyway. But since the bridge-router boxes at both ends of the circuits must agree on the implementation of such procedures, the actual encapsulation specification is basically more irrelevant to the customer user than the internal bus structure of the bridge-router box. Now it is possible that the IETF expects the bridge-router box at one end of the link to communicate directly with an end host at the other end of the link, in which case a bare-minimum lingua franca serial communications access method has more importance than I would otherwise ascribe to such a thing, but my market analysis implies that the number of customers who desire such a configuration is simply too small for company resources to be devoted to development of a product which targets this specific need. There is actually a more sophisticated issue with computer networking over serial links. Doug Comer discusses this issue in Internetworking with TCP/IP, Vol. I, Second Edition. On pg. 151, he writes the following. "Recall from Chapter 2 that some wide area networks contain multiple packet switches. For example, the Cypress network consists of gateways that connect to an Ethernet local area network as well as to other Cypress gateways over leased serial lines. Cypress transfers IP datagrams but uses its own internal packet protocol when transferring them across serial lines. The Cypress serial line protocol software must be merged with other protocols, and the question arises: "How do the Cypress protocols fit into the TCP/IP layering scheme?" The answer depends on how the designer views the serial line interconnections. From the perspective of IP, the set of point-to-point connections among gateways can either function like a set of independent physical networks, or they can function collectively like a single physical network. In the first case, each physical link is treated exactly like any other network in the internet. It is assigned a unique (class C) network number, and the two hosts that share the link each have a unique IP address assigned for their connection. Routes are added to the IP routing table as they would be for any other network. A new software module is added at the network interface layer to control the new link hardware, but no substantial changes are made to the layering scheme. The main disadvantage of the independent network approach is that it proliferates network numbers (one for each connection between two machines), causing routing tables to be larger than necessary. The second approach to accomodating point-to-point connections avoids assigning multiple IP addresses to the physical wires. Instead, it treats all the connections collectively as a single, independent IP network with its own frame format, hardware addressing scheme, and data link protocols. Cypress uses the single network approach and has only one network number for all point-to-point connections." PPP does not even address the issue of architecting IP networks over serial links (except for a tiny reference to a 3rd approach, which Comer apparently dismisses or ignores and which is to set up the two hosts at the end of a serial connection as half-gateways). Since PPP does not address the question of architecting an IP network which use multiple serial links, PPP is essentially irrelevant from the standpoint of a system architect (like me) and from the standpoint of the customer or network administrator who has an internet which consists of several networking technologies including serial links. In order to address the question of architecting an IP network which uses multiple serial links, I have architected into the Little Dipper a high-performance intranetwork system similar to the Cypress Intranet Network architecture. Even if both Little Dippers and the boxes of other vendors both talk PPP, unless the boxes of the other vendors conform to the Little Dipper intranetwork architecture, the Little Dipper and these other boxes really will not interwork. The Little Dipper will also support configuring individual serial links as IP networks as well as half-gateway and half-bridge configuration. This sort of flexibility, which directly addresses the implementation of serial IP networks, is probably more desirable than mere PPP (which will also be present). Basically, if a customer only cares about PPP, and purchases boxes simply on the basis of conformance to this specification, this customer will probably have to be content with low performance serial computer networking. IV) CONCLUSION I must wonder about this continual insistence on PPP, which is merely a link-level encapsulation and which does not address any of the real issues of using serial links as a medium for an IP network. When I took part in T1D1 (currently divided into T1S1 and T1E1 and maybe some other committees), I remember that the members of the committee were reluctant to standardize on the international standards without making qualifications which would require supplemental documents. The members were afraid that if they produced no documents, their managements would get upset that the companies had spent money unnecessarily to send representatives to T1D1. People who worked on PPP through the IETF might have a similar interest in demanding the use of PPP in bridges and routers because otherwise their managements might wonder why the companies spent money to send representatives to take part in the IETF deliberations on PPP. In the future, I would hope that people who discuss PPP issues would make clear whether they might be motivated by such an interest. I personally have no stake in PPP, and to tell the truth while PPP looks to me like another RDP or less, I am willing to be persuaded otherwise. Joachim Carlo Santos Martillo Ajami The above comments represent my current thoughts as system architect. They may change as I study issues more deeply and read the comments of thoughtful critics. The above comments are not product announcements and are in no way binding on Clearpoint Research Corporation.