Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!nosc!ucsd!ucbvax!sequoia.Berkeley.EDU!sklower From: sklower@sequoia.Berkeley.EDU.berkeley.edu (Keith Sklower) Newsgroups: comp.protocols.iso Subject: Re: Transport routing issues Message-ID: <25270@ucbvax.BERKELEY.EDU> Date: 28 Jul 88 04:35:17 GMT References: <3d63cf41.1223a@apollo.uucp> Sender: usenet@ucbvax.BERKELEY.EDU Reply-To: sklower@sequoia.Berkeley.EDU.UUCP (Keith Sklower) Organization: University of California, Berkeley Lines: 33 In article <3d63cf41.1223a@apollo.uucp> brezak@apollo.uucp (John Brezak) writes: + Maybe someone has some ideas on this. If you have a transport layer (TP4) + that can work over different networks, how do you know which network to + send something over ? + + [Shows TP over CLNS and X.25] + + I know that each network would have a different NSAP. But how does the + transport layer know which network that the destination PDU has to go + through? + + John Brezak UUCP: {mit-eddie,yale,uw-beaver}!apollo!brezak + Apollo Computer Inc. ARPA: brezak@apollo.com + Chelmsford, MA Phone: (617) 256-6600 + When 4.3BSD establishes a TCP connection, it attempts to establish a route to the destination. Based on the NSAP, maybe TP should consult the routing layer for guidance. Berkeley is already considering extending the routing entries for useful protocol specific (read TCP) parameters (like round trip times, congestion tolerance parameters). So, if we can make connection oriented and packet switched interfaces share some kind of common routing lookup based on address, we might be able to place some TP-oriented parameters like prefered class (0 for for an X.25 network layer?), or suggested packet size for connection negotiation in TP. Another alternative is to punt and provide some means of telling TP a priori which way to go. In BSD, this might be done by means of a setsockopt before doing a connect() call on an AF_ISO socket. Keith Sklower UUCP: ucbvax!sklower ARPA: sklower@okeeffe.Berkeley.EDU