patrick.oke...@wamu.net (Patrick O'Keefe) writes: > Well, the N is "Network", not "Networking", but I don't think that > clarifies anything. Lynn apparently has some very specific defibition > of "Networking" in mind. His comment may be accurate (His comments > usually are.) but I'm not sure what that comment really was. > > SNA does not have a universal addressing scheme and IP does. > Perhaps that was the point. But SNI provided that in sort of the > same way that NATing allows interconnection of 2 IP networks that > use private IP addresses. > > SNA does not provide a universal name space for resources, but > neither does IP. The Domain Name space used by IP hosts is > not provided by, or dependent on IP.
re: http://www.garlic.com/~lynn/2009l.html#3 VTAM security issue it was the communication division ... not the networking division. vtam/ncp (pu5/pu4) formed part of a communication hierarchy. networking has tended to apply to talking to other peers ... it was the source of my comment that only in situation where "network" had been co-opt to apply to communication hierarchy that it was necessary to qualify AWP39 networking architecture by "peer-to-peer networking architecture". arpanet ... prior to great converstion to tcp/ip on 1jan83 ... had hosts and network nodes (IMPS). The IMPS talked to other IMPS (network nodes) ... and they talked to attached devices (which happened to be hosts, later there were also "terminal" IMPS). IMPS (network nodes) exchanged information about what other IMPS (network nodes) they were connected to ... so it was possible to dynamically discover network nodes and paths to network nodes and paths to connected devices/hosts. The IMPS/host configuration had some physical similarity to pu4/pu5 ... but the IMPS were full network nodes that managed the dynamic network configuration and then forwarded communication to/from destination hosts. At the time of the great change over ... there was something like 100 IMPS (network nodes) and 255 (connected) HOSTs. TCP/IP has both a network layer and an internetworking layer (gateways and other conventions for supporting the internetworking of networks). At the TCP/IP network layer there is ARP (address resolution protocol) and ARP caches (dynamic maps of IP-addresses to "data link" ... if using the OSI madel), as well as some maintenance/control gorp with ICMP messages (redirects, not reachable, etc). These are networking layer/node to networking layer/node The great change-over to TCP/IP effectively merged the IMP function into the hosts ... with hosts executing networking layer code and higher layer code. It was possible to do (dynamic, networking layer) router function in the hosts and/or custom "router" boxes. The "router" boxes could also provide the gateway/internetworking function for internetworking of networks. the internal network ... some past posts mentioning internal network http://www.garlic.com/~lynn/subnetwork.html#internalnet originated at the science center (virtual machines, lots of interactive computing, GML ... precursor to SGML, HTML, etc, lots of other stuff) ... some past posts mentioning science center http://www.garlic.com/~lynn/subtopic.html#545tech I've claimed that one of the reasons that the internal network (not SNA) was larger than the arpanet/internet from just about the beginning until sometime late 85 (or early 86) was that the prevailing internal networking nodes contained a form of gateway function (significantly easing the addition of nodes in different parts of the network) ... which arpanet/internet didn't get until the 1jan83 great change-over. We were in a booth at interop88 ... but not the ibm booth ... and starting late sunday night before the start of the show ... the (four) floor nets started crashing ... this continued into the wee hours of monday morning before being diagnosed and corrected. The problem was that a large number of nodes (lots & lots of workstations) had connections to all four floor nets ... and all had "ip-forwarding" turned on by default (router function). Any ARP request was automagically being rebroadcast by nearly all nodes on all networks ... which led to ARP storms. In the wake of interop88 ... RFC1122 (IETF internet standard) specified that IP-forwarding should be turned off by default. my internet standard index http://www.garlic.com/~lynn/rfcietff.htm summary entry for 1122 http://www.garlic.com/~lynn/rfcidx3.htm#1122 1122 S Requirements for Internet hosts - communication layers, Braden R., 1989/10/01 (116pp) (.txt=289148) (STD-3) (Updated by 4379) (See Also 1123) .... misc. past posts mentioning interop88 http://www.garlic.com/~lynn/subnetwork.html#interop88 TCP/IP is the technology basis for the modern internet, NSFNET backbone was the operational basis for the modern internet, and CIX was the business basis for the modern internet. some number of past posts mentioning NSFNET backbone http://www.garlic.com/~lynn/subnetwork.html#nsfnet and old email related to NSFNET backbone activity http://www.garlic.com/~lynn/lhwemail.html#nsfnet Note that the domain name system provides a separate naming indirection that rides on-top and independent of tcp/ip (for things like URL/domain name to IP-address mapping). For a little archeological folklore, the person originally responsible for the domain name system did a stint at the science center in the early 70s. other old archeological references: http://www.garlic.com/~lynn/aepay11.htm#43 Mockapetris agrees w/Lynn on DNS security - (April Fool's day??) http://www.garlic.com/~lynn/aepay11.htm#45 Mockapetris agrees w/Lynn on DNS security - (April Fool's day??) http://www.garlic.com/~lynn/aepay12.htm#18 DNS inventor says cure to net identity problems is right under our nose http://www.garlic.com/~lynn/2008r.html#42 Online Bill Payment Website Hijacked - Users were redirected http://www.garlic.com/~lynn/2008s.html#39 The Internet's 100 Oldest Dot-Com Domains NAT (network address translation) ... is a gateway/router "add-on" function ... which at network(ing) gateway boundary remaps traffic IP addresses. The router will take an internal networking address ... like a 10-net ... and remap it to appear as if it is coming from the router's internet/gateway IP-address. NAT'ing requires that the gateway router keep track of the mapping of internal ip-addresses to (internet) sessions using its own address ... in order to correctly rewrite the ip header address i.e. potentially a large number of differen tinternal IP-addresses has been modified to appear as if it is coming from the same router/gateway internet ip-address. Returning traffic will all be directly addressed to that router/gateway internet ip-address and needs to be correctly re-addressed for forwarding to the appropriate destination (the router needs to keep lots of administrative gorp to be able to correctly re-address & forward incoming, returning traffic). from my IETF internet standards index: http://www.garlic.com/~lynn/rfcietff.html click on "Term (term->RFC#)" in the "RFCs listed by" section. Then click on "NAT" in the "Acronym fastpath" network address translation 5555 5508 5389 5382 5207 5135 5128 4966 4787 4380 4008 3947 3715 3519 3489 3424 3235 3105 3104 3103 3102 3027 3022 2993 2766 2709 2694 2663 2428 2391 1631 in the index, "clicking" on the RFC number brings up the summary in the lower index. "clicking" on the ".txt=nnn" field in a summary entry retrieves that actual RFC. NOTE that NAT'ing is similar ... but different to VPN (virtual private network) implementation. In the early 80s, I started a project I called HSDT ... some past posts http://www.garlic.com/~lynn/subnetwork.html#hsdt and we were running T1 & higher speed backbone links. HSDT was also getting some custom built hardware to spec. ... some from overseas. In the mid-80s, somebody in the communication division announced a new internal communication discussion group (on the internal network) ... the announcement went out on Friday before I was to take a trip to the other side of the pacific and included the following definitions: low-speed <9.6kbits medium-speed 19.2kbits high-speed 56kbits very high-speed 1.5mbits the following morning, on a conference wall on the other side of the pacific was: low-speed <20mbits medium-speed 100mbits high-speed 200-300mbits very high-speed >600mbits As indicated in the NSFNET related email ... we had been working with NSF on getting a NSFNET backbone with at least T1 links (since we could point to HSDT operational internal links at T1 and higher speeds). One of the other differences between the internal network and the "internet" was that corporate required encryption on all links leaving corporate premise. This was a real hassle for some links at various places around the world ... especially when the connected corporate locations in different countries. In any case, at some point in the mid-80s, there was a comment that the internal network had over half of all the link encryptors in the world. One of the issues in HSDT was at the time, it was fairly straight-forward to get link encryptors for 56kbit and slower speed links. It became increasingly difficult to get link encryptors that ran at T1 and higher speeds. At one point, I got involved in designing our own encryption hardware for HSDT. For other archeological topic drift ... when we were doing ha/cmp product ... some past posts http://www.garlic.com/~lynn/subtopic.html#hacmp one of the transparent fall-over strategies was to do ip-address take-over (aka the take-over box acquires the ip-address of the failed box). we found a bug in the most comingly deployed tcp/ip code (large number of vendors were using BSD TCP/IP 4.3 TAHOE or RENO). Normally the ARP code requires that the ARP cache entries be periodically timed-out and be forced to be refreshed (which our ip-address "take-over" function was dependent on). However, BSD 4.3 TAHOE/RENO had a "bug" in how ARP entries might work under specific conditions and an ARP entry would never time-out (defeating HA/CMP fall-over attempt to do ip-address take-over). We had to come-up with a kludge work-around for the bug ... that would trick clients into doing ARP entry refresh (i.e. ip/network address to physical address). -- 40+yrs virtualization experience (since Jan68), online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
