(Message nnsc-pol-proc:6) Received: from Osprey.Telcom.Arizona.EDU by NNSC.NSF.NET id aa03733; 14 Oct 92 15:31 EDT Received: from Arizona.edu by Arizona.edu (PMDF #2381 ) id <01GPXT85NCHU96VKBH@Arizona.edu>; Wed, 14 Oct 1992 12:31:19 MST Date: 14 Oct 1992 12:31:18 -0700 (MST) From: Aaron Leonard Subject: [uofa.commandments]commandments.version-2 from Arizona.EDU [OBSOLETE] To: pol-proc-doc@NNSC.NSF.NET Message-id: <01GPXT85NM5G96VKBH@Arizona.edu> X-VMS-To: IN%"pol-proc-doc@NNSC.NSF.NET" MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT * DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT * This is the second draft of the UofA Network Requirements and Guidelines document. This seeks to incorporate the insights offered in the ad-hoc meeting held at the Mosaic house in early Feb. '90. NOTHING IN THIS DOCUMENT SHOULD BE TAKEN AS A COMMITMENT FROM CCIT TELECOM. THIS IS ONLY A DRAFT. 26-Mar-1990 Aaron Leonard CCIT Telecom * DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT * University of Arizona Data Network Requirements and Guidelines 0. Introduction. - This document contains requirements and recommendations for entities that wish to connect to the UofA data network. - Please note that data security is NOT guaranteed in this network. - Special terms: - subdomain: a more or less autonomous administrative entity within or associated with the University - netmgr: an individual responsible for the technical administration of a subdomain 1. Connectivity provided by the CCIT Telecom dept. Telecom offers the following connectivity to on-campus subdomains of the UofA: 1.1. Trunk connectivity to each building. To each building, Telecom offers connectivity to the "Campus Ethernet". That is, each building will have routed and/or bridged access to all protocols spoken on the UofA Extended Ethernet. These protocols include: DECnet, TCP/IP, LAT, and AppleTalk, and any other protocol that conforms to Ethernet type-II framing standards. At the discretion of the netmgr of each subdomain, and if technically feasible and sound, the range of protocols that get delivered to each subdomain may be restricted to a subset of the protocols spoken campuswide. However, if new users in the subdomain should appear wishing to speak a protocol that had been filtered out, then access to that protocol shall be restored to the subdomain. The bandwidth of the trunk connecting the building entrance point to the campus backbone may not necessarily be full Ethernet speed. Or it may be greater than Ethernet speed. Such bandwidth shall be determined by various factors, including the availability of existing cabling, the expected traffic to/from the building, the distance to the building, the political clout wielded by the subdomain, and the size of the pecuniary inducement offered to Telecom. 1.2. Office connectivity to the office within each building. Within each building connected to the Campus Ethernet, Telecom will offer connectivity to the office via the TIPS unshielded twisted-pair wiring (UTP). This connectivity extends to the data leads in each TIPS wall jack and can take one of two forms, at the choice of the subdomain. (Note: if it proves to be technically feasible, Telecom may be able to provide both 1.2.1 AND 1.2.2 simultaneously to the same data jack.) 1.2.1. Ethernet over UTP to the wall jack. Full 10 Mbps Ethernet can be extended to the wall jack via the TIPS UTP. This can take one of two forms: for single-station requirements, a 10baseT-compliant connection can be offered, with either an RJ45 or an AUI interface provided. For multi-drop requirements (such as a computer lab), a BNC (ThinWire) capable of servicing a daisychain of at least 10 stations can be provided. 1.2.2. Asynchronous serial connectivity over UTP to the wall jack. For users who prefer a traditional slow-speed serial terminal connection, Telecom can provide asynchronous serial connectivity to the wall jack. The user's equipment will be able to connect either via an RJ45 or a DB25 interface. Telecom will offer speeds of up to at least 9600 bps, with connectivity offered to TCP/IP, LAT, and 3270-type hosts. This service may initially be offered via the existing IDX-3000, but may transition to using Ethernet-based terminal servers. 2. Per-protocol requirements for connecting to the campus network. Telecom recognizes several protocols as being supported on the UofA network. These protocols are: TCP/IP, DECnet, LAT, LAVc, and AppleTalk. Subdomains that wish to talk these protocols with the rest of campus must observe the following requirements. 2.1. Requirements for connecting to the campus TCP/IP network. 2.1.1. IP address assignment. In order for a node to be assigned an IP address on the campus TCP/IP network, a subdomain must have its netmgr request such via mail to IPREQUEST@ARIZONA.EDU. (This is unless the node is on a separate subnet belonging to the subdomain, which subnet has reverse name service provided by the netmgr.) 2.1.2. Internet host name assignment. See section 3.1 for more information on host name assignment. 2.1.3. Standards. Subdomains connecting to the campus TCP/IP network must observe the following standards: - Subnet mask of 255.255.255.0 - Broadcast address of 128.196.subnet.255, unless otherwise instructed by your subdomain's netmgr. - Don't run rwhod. - You must not emit RIP packets unless explicitly granted leave to do so by Telecom. You must NOT run routed unless absolutely necessary. In addition, Telecom makes the following RECOMMENDATIONS: - Use domain name service rather than static host tables. - Don't use Yellow Pages if you can help it. 2.2. Requirements for connecting to Arizonet (the campus DECnet.) 2.2.1. DECnet node number assignment. All nodes in Arizonet must be in area 50 unless your subdomain is to participate in a national DECnet, in which case you may only join the campus DECnet after careful consultation with Telecom. Node numbers are assigned by sending mail to TELCOM::DECNET_REQUEST. 2.2.2. DECnet node name assignment. All DECnet node names must be less than or equal six characters in length, and moreover must be compliant with section 3.1 below. 2.2.3. DECnet standards. Subdomains connecting to Arizonet MUST observe the following standards: - no node may act as a level-II (area) router without the explicit approval of Telecom - no node may act as a level-I router unless it has two or more circuits going into it. (However, each VAXcluster is allowed to have one level-I router in order to provide for a cluster alias.) - each node on the Campus Ethernet must have its Maximum Broadcast Nonrouters executor characteristic increased to 255, and its Maximum address increased to 1023. In addition, Telecom makes the following RECOMMENDATIONS: - the Executor Outgoing Timer should be increased to at least 90 seconds in order to accomodate overloaded servers. 2.3. LAT standards. [JMS's offerings go here ... meantime, see the document [arizonet.lat]lat-groups.standard on ARIZONA.EDU.] 2.4. LAVc standards. Local Area VAXcluster cluster numbers must be coordinated with Telecom. LAVc's may not span Telecom-maintained bridges. We RECOMMEND that LAVc's have their SYSGEN param RECNXINTERVAL increased to at least 90 seconds in order better to weather network meltdowns. 2.5. Appletalk standards. [Face's offerings go here.] 2.6. OSI/DECnet Phase V standards. Any concerns in this area are largely speculative. The first things to consider are the organization of the campus namespace, and routing requirements. An exploratory working group (dnans-group@arizona.edu) has been formed to look into OSI/Phase V. 2.7. Other protocols not otherwise mentioned in this section. Departments are free to run other protocols not otherwise mentioned in this section, subject to the condition that these protocols not adversely affect other users of the shared network. If two or more subdomains are found to be running an otherwise unused protocol and come into conflict with each other, then Telecom reserves the right to knock their heads together and then deputize the thus illuminated netmgrs to write up standards for the sane use (if any) of THOSE protocols. 3.0. General rules for data networking. This section includes rules that apply to all protocols in use in the campus network. 3.1. Node naming. Node names must be unique across all subdomains and all networking protocols. Node names must be cleared with IPREQUEST@ARIZONA.EDU. Aliases for node names must not be allowed to multiply unnecessarily. If a department is serving its own names, then it must check the relevant databases (currently, [arizonet]arizonet.nodes and [hosts]local.hosts) for uniqueness before coining names. 3.2. Mail addressing and gatewaying. See the auxiliary document,[mail]ua-standards for more information on this subject. [Stuff on forwarding aliases needs to be added there.] 3.3. Paging/swapping across Telecom-maintained brouters. Forbidden. In particular, neither diskless nor "dataless" workstations may boot across Telecom-maintained brouters. 3.4. Catch-all fair play rule. If any subdomain is found to be emitting traffic that either 1) hogs more than its "fair share" of the network resources, to the detriment of other network users, or 2) causes protocol-wise confusion or misery among other network users, appropriate action must be taken. (See sections 2.7 above and 4.1.1 below.) 4.0. Administrative functions. 4.1. Network Management. The Campus internet shall be administered by the University of Arizona Telecommunications Department. Adminstration of subdomains of the network may be delegated to qualified entities. Each subdomain must have a netmgr responsible for the network behavior of all connected computing devices. The list of such netmgrs shall be maintained in the mailing list , and in the file INFORMATION on arizona.edu. 4.1.1 Duties of the Telecommunications Data Networking Group Telecommunications is responsible for inter-building networking, off-campus network connections, name service and network support/consulting services for the U of A Campus Internet. Additionally, they perform duties of "network police" by preventing network outages or minimizing the damage caused by network events. Naming authority for the Internet domain "arizona.edu" and the all local DECnet nodes is managed by Telecommunications. 4.1.2 Duties of the Subdomain Network Manager ("Netmgr") Each subdomain shall have a Network Manager responsible for the network behavior of all machines within the subdomain. The Network Manager shall the the only entity recognized by the Telecommunications Department for name/address requests or changes. The Network Manager shall act as a clearinghouse for all network-related topics within the subdomain. The Network Manager should attend the periodic Network Managers' meetings. Information for reaching the Network Manager must be provided to Telecommunications. 4.1.3 Damage Control and Fault Isolation The Telecommunications Data Networking Group shall retain the authority to segment the Campus network, or isolate computing devices from the network if the behavior of the device is causing harm to any other network connections. Telecommunications shall attempt to notify the responsible Network Manager or System Administrator before summarily disconnecting hosts or segments. In order to more effectively manage the network in this manner, the Network Managers shall provide information to Telecommunications necessary to maintain a database of computing devices on the campus network. *** DRAFT *** DRAFT *** DRAFT *** DRAFT *** DRAFT *** DRAFT *** DRAFT *** DRAFT