jpbion@cisco.com (Joel P. Bion) (02/27/91)
Hello. Thank you for your questions concerning cisco's existing and upcoming support for protocols in IBM's SNA. There are many questions, from more than one person, so let me try to address them all here: 1) SDLC (SNA serial lines): We will support in release 8.3 SDLC "transport" functionality, which allows SDLC traffic through routers in any of the following configurations: 1: The two speaking SDLC devices connected to the same router (we call this "direct" SDLC transport), as in: FEP--cisco--3174 2: The two speaking SDLC devices connected to distinct routers separated by only a serial link, as in: FEP--ciscoA----, '------ciscoB--3174 (we call this "serial interface SDLC transport" mode) 3: The two speaking SDLC devices connected to distinct routers separated by more complex, possibly redundant topologies: FEP--ciscoA---"complex networking cloud"--ciscoB--3174 (we call this "full (or TCP based) SDLC transport" mode) These three types are increasingly "efficient" (less overhead) as you get simpler configurations: Type 1 is most, type 2 less so, and type 3 least. As to the "efficiency" of it, to answer: . How efficient is the cisco SDLC-over-TCP (e.g. is there any compression or other measure to compensate for encapsulation overhead)? the answer is that it is "efficient" as TCP is (which means, yes, overhead in each packet), but we are working on overall header compression algorithms that may reduce this. The efficiency problem is greatly sidestepped though, by the answer to your second question: . Is SNA "chatty" at the SDLC level, e.g. would an SNA link running via SDLC tunnelling in TCP generate significant IP load even when SNA clients are idle (or can "smart" acknowledgements or some-such avoid low level noise)? Yes -- very much so -- SDLC primaries links will constantly poll SDLC secondaries with RR (receive ready) frames with the P bit set, as the secondary can only send data in response to a frame with the Poll bit set. To provide reasonable Secondary->primary delay, the polls from the primary are frequent. Therefore I've implemented "proxy polling" with our SDLC transport, which, if the configurer of the cicso router simply enables it, will "spoof" the generation and replies to polls during idle periods -- keeping network traffic to a bare mimimum. . Is the SNA link level demanding in terms of low RTTs and/or low variance in RTTs? If so we may require priority for SDLC tunnelling so heavy nntp and ftp traffic doesn't break SNA. Also we could run into trouble with our use of variance 2 IGRP multipathing. Somewhat, but this is very configurable in your "primary" hosts (times between polls, time to wait for a response to a poll, etc.) For those who run into this problem (it should be but a few), I added "priority queuing" for the SDLC transported traffic. . Does/could SDLC tunnelling provide any mechanism to concentrate multiple PU connections through a single interface to a host, e.g. by emulating multidrop? We support this, marketing calling it "virtual multidrop" -- in reality quite siple as we will "route" SDLC frames through the internet based on the SDLC address. Therefore, if you had a multidrop setup before, you can get effectively the same setup again using combinations of routers -- and the linkings between the "drops" can be arbitrarily complex. 2) SNA Routing (PU4 support) . Once SNA routing is supported what are the key added feaures, e.g. does this mean multiple PU-PU circuits are handled something like multiple TCP connections? Could it mean transport of an SDLC link layer is unnecessary, i.e. SNA upper layers could run direct on UDP or TCP? Could this provide the basis for the channel-attached solution postulated by Peter Weiss? SNA routing would support explicit routes, virtual routes, transmission groups, etc.. The implementation details are not finished, but with it the support of SDLC transport would still be in the unit, as many people want this but *not* the full routing capability. I don't see us attaching directly to IBM channels at this time... -Joel