Exclusive Interview with

Mac Devine

Architecture, Strategy and Design Manager, IBM

IBM Communications Controller for Linux on zSeries (CCL) was previewed in May 2004 when
the groundbreaking IBM Comm. Server for z/Linux was announced.

CCL is a highly strategic software offering that is meant to serve as a replacement for the IBM 3745/3746 communications controllers [that were withdrawn from the market as of September 2002] for SNA customers that still require business-critical, high-end functionality such as: SNI (SNA Network Interconnection), XRF (Extended Recovery Facility for disaster recovery), BNN (Boundary Network Node), and SSCP takeover.

Mac Devine, the Manager of IBM's Enterprise Networking Solutions Architecture, Strategy
and Design Group, who really is "Mr. Comm. Server" and the driving force behind CCL,
gives us an exclusive, in-depth look at this intriguing offering -- in this interview with Anura Guruge, IT In-Depth's editor at large.

  Read the Nov. 2005 CCL v1R2 White Paper 

  Read the 1st interview  

  Read the 3rd interview  

Mac Devine: a synopsis

Mac Devine is a 1989 graduate of Clemson University with a Master's degree in Mathematical Sciences. Mac spent 7 years in VTAM development working on a variety of APPN/HPR functions and was the Chief Programmer of several major releases. Mac then transitioned into the Communications Server Architecture, Design and Strategy group and spent 4 years designing TN3720E and Sysplex functions and served as the Chief Designer of several  major releases. Mac then served 2 years as the lead solutions architect for networking alliances (Cisco, Nortel, etc.) responsible for the development of joint solutions which leverage IBM's eServer and e-business framework. Mac is currently the manager of the Enterprise  Networking Solutions Architecture, Strategy and Design group responsible for the architecture, design and strategy of solutions which leverage IBM's zSeries and e-business framework.

 Click here for an IBM presentation on CLL by Alfred B. Christensen [750KB PDF]

Q1:  Mac, please set the stage for the readership and explain, conceptually (at a high-level), what the Communication Controller for Linux on zSeries (CCL) is all about and what it is trying to achieve?

 A1: The Communication Controller for Linux on zSeries (CCL) was explicitly developed to emulate the 3745/6 Communication Controller so that the Network Control Program (NCP) software could continue to provide business critical functions like SNI, XRF, BNN, INN, and SSCP takeover. By allowing customers to leverage their existing NCP functions on a “virtualized” communication controller within the Linux zSeries environment, customers get to take advantage of the virtualization, business resiliency, security and scalability of the zSeries platform while simplifying their networking infrastructure and removing dependencies on aging SNA networking equipment.

 Q2: Mac, can CCL be used as an ‘one-to-one’ replacement for a 374x running SNI … or does CCL also require that you have Communications Server for Linux on zSeries  (CSL) also running … and if so do they have to run on separate Linux LPARs?

 A2: Since CCL allows customers to use their existing NCP software, the easiest migration for SNI is to use CCL as a 1-1 replacement for the 3745/6 Communication Controllers performing the SNI function. Keeping this 1-1 relationship between the physical communication controller (i.e. 3745/6) and the virtualized communication controller (i.e. CCL) also allows customers to keep almost all of the NCP and VTAM definitions intact and more importantly allows them to maintain the same operational and automation procedures. Another key reason we recommend (but we do not require) this 1-1 relationship for SNI is that the 3745/6 to CCL migration can occur transparently to the business partners (i.e. the business partners see no change in the SNI connections and can continue to use their 3745/6 Communication Controllers).

       The Communications Server for Linux (CSL) and the Communication Controller for Linux (CCL) are completely separate products and perform completely different roles. CCL is focused on providing an execution environment for the NCP software while CSL is focused on providing an execution environment for SNA applications and providing SNA/IP integration gateway functions (e.g. TN3270E and Enterprise Extender). However, because each of these products is operating in the Linux zSeries environment and is designed to assist with infrastructure simplification, they can also be used in a complimentary fashion. For example, currently many customers utilize outboard TN3270E servers which are downstream from 3745/6 Communication Controllers. This type of TN3270E implementation can easily be consolidated to Linux zSeries by utilizing the TN3270E server of CSL in conjunction with CCL. In other words, allowing customers to maintain their existing VTAM/NCP definitions, management processes and operational procedures while simplifying the networking infrastructure to pure IP. In such a scenario, CCL and CSL could run on the same Linux LPAR, different Linux LPARs, or on Linux running as a guest operating system under VM.

Q3:  Mac, what are the advantages of the CCL approach over using EE with Extended Border Node as an SNI replacement strategy?  Mac, given that CCL is obviously an alternative to EE/EBN, what should customers who have already started to think about EE/EBN do at this juncture?

 A3: The most significant advantage of CCL over EE/EBN is that CCL allows customers to move their SNI traffic off of the 3745/6 Communication Controller without requiring changes at the business partner end.  This removes a significant obstacle (coordinated changes with business partners) customers have encountered when trying to replace their 3745/6 Communication Controllers. It is important to understand that EE/EBN requires that customers implement APPN/HPR. Many mainframe customers remain SNA subarea only or use VTAM on z/VM or VSE/ESA systems which do not support EE/EBN.  If an enterprise has already begun an EE/EBN migration, there is no reason to change direction.  However, they may determine that some of their business partners are not capable or prepared to implement EE/EBN so CCL gives them an alternative solution which can be used in conjunction with EE/EBN to remove their dependency on legacy SNA networking equipment.

 Q4: Mac, I note that you plan to roll out CCL in two phases.  Can you please elaborate when these two phases are likely to be available and what each phase will provide?

 A4: The first phase of CCL is scheduled to GA 1Q2005 and is focused on allowing customers to leverage as many of their NCP business critical functions as possible within the Linux zSeries environment. Linux zSeries provides the ideal environment for these NCP functions since the SNA communications can be isolated to the data center LAN via OSA Express thus reducing the total cost of ownership of the networking infrastructure. We are planning to deliver the second phase of CCL by 4Q2005 and this phase is focused on allowing IP connectivity via the OSA Express by utilizing technologies like DLSw to encapsulate the SNA communications across IP to further simplify the networking infrastructure.

 Q5: Mac, does CCL work in native SNA mode across OSA-(Express) or is it an “SNA-over-IP” [i.e. EE] scheme … or does it support both these modes of operation in conjunction with DLSw and EE?

 A5: The first phase of CCL uses native SNA communications across the OSA Express while the second phase plans to support additional SNA over IP technologies like DLSw.  For SNA communication, CCL works in conjunction with OSA Express to allow communication between the NCP and VTAM as well as allow SNA communication to locally attached SNA devices (e.g. 3174, AS400, etc.) or to DLSw capable routers which are supporting remote SNA clients/devices.  In addition, the Communications Server for Linux on zSeries can connect to the CCL via internal LAN protocols (i.e. communication between Linux images) and act as a TN3270E server, Remote API server or an Enterprise Extender gateway to downstream SNA clients/devices via the IP connectivity of OSA Express.
 

Q6:  Mac, ‘mainframers’ looking at the various diagram you have for CCL, including those reproduced here, are going to come across these references to OSA-Express working in Link Services Architecture (LSA) and LAN Channel Station (LCS) mode.  Mac, could you please explain, very briefly, what the difference is between these two modes?  Given that I know that some people (including me), who vaguely recall some of these terms of the IBM 2216 days, associate LCS with predominantly IP traffic, can you please explain why CCL appears to insist on LCS mode – even when it is supposedly working with SNA-only traffic?

 A6: Some of your more “device driver savvy” readers may already be aware that the TCP/IP LCS device driver’s characteristics are very similar in nature to the SNA LSA device driver. Both device drivers are LAN oriented and use the same basic methods for MAC level routing. Traditionally, LCS was only needed for and therefore used for IP traffic and LSA was used for SNA traffic. However, once we moved SNA functions onto Linux, we then needed SNA traffic to be enabled through LCS.  This was solved by using the SNA LLC support in CSL and CCL and then enabling SNA frames through OSA Express.  OSA Express provided a small firmware change that allows our users to configure SNA Service Access Points (SAPs) in addition to IP addresses. This “transparent bridging” by CCL of these 2 LAN device drivers was a critical design point for the solution since it means that the CCL can support connectivity to all VTAMs (i.e. z/OS, VSE/ESA, and z/VM) across all supported releases.

Q7:  Mac, could you again, at a high level, please share with us the amount of changes that will be required to VTAM and NCP when migrating to CCL … and can you please be kind enough to spell out the conversion steps that will be needed to move from an 374x/SNI environment to a CCL/SNI scenario?

 A7: One of our primary goals during the design and development stages of the CCL was to keep the changes to VTAM and NCP to an absolute minimum. In particular, we especially wanted customers to be able to migrate SNI connections to their business partners without requiring any changes by (or coordination with) the business partners. I’m very pleased to say that CCL accomplished these objectives. The primary connectivity for zSeries is OSA Express and fortunately, VTAM already supported LAN connectivity to a 3745/6 Communication Controller. However, VTAM did not support activation of NCP or ownership of NCP resources over LAN. Therefore, the following list is a high level summary of the required changes:

          1.  A VTAM PTF is required. This PTF enables NCP activation and ownership over OSA Express LAN via specification
              of a new VTAM keyword on the XCA PU statement

          2. OSA Express must be at a microcode level which includes the support for configuring the SAPs needed to enable SNA
              traffic over LCS. This microcode level has been available since 5/2004. 

          3. The NCP must be genned to reflect LAN (TIC2) attachment to VTAM instead of channel link attachment

          4. The OSA Express must be configured to re-use the MAC addresses which were used by the replaced 3745/6
              Communication Controller or the SNI connected business partner must match the MAC address of the OSA Express within
              their NCP (i.e. the MAC address of the OSA Express must match the MAC address specified within the SNI connected
              NCP). 

       Believe it or not, these are the only changes required to utilize CCL for SNI, XRF, SSCP Takeover and local LAN attached SNA devices. In addition, if a customer already utilizes DLSw routers in the data center to communicate to downstream SNA clients/devices then no additional changes for NCP or VTAM are required to connect these DLSw routers using the Ethernet or Token Ring connectivity of OSA Express.  If the customer doesn’t yet utilize DLSw then several changes will need to be made to both VTAM and NCP definitions but these changes are relatively straight-forward.

Q8:  Mac, are there any limitations with this CCL approach … in terms of it not being able to fully support functionality that is currently available on 374xs … and if so what options to people have in terms of getting around these?

 A8: The 3745/6 Communication Controller supports a wide variety of line connectivity options which are not available on zSeries (e.g. X.25, SDLC, etc.). However, in many cases, SNA devices/clients using this direct SNA line connectivity to the 3745/6 can instead utilize DLSw capable routers. In other words, terminate the SNA lines on a remote (near the SNA device/client) DLSw router which communicates via IP to another DLSw router in the data center. Many customers have successfully used DLSw in this manner for years and with AT&T’s recent announcement about withdrawing support for SNA line connectivity (requiring the use of DLSw connectivity instead), many more customers are now considering DLSw implementations so that they can consolidate to a pure IP WAN. Therefore, any SNA device/client which can be supported via DLSw to a 3745/6 Communication Controller can also be supported by the Communication Controller for Linux on zSeries and more importantly all NCP functions associated with this type of connectivity are also supported.

Q9:  Mac, as the final question, does CCL mean that customers, especially SNI customers, can finally think about getting rid of their venerable 374xs and if so … what are your thoughts as to what might be a fitting end to these stalwart machines given that we all know that in reality, despite what they used to be disparagingly referred to by router vendors, they are too unwieldy and “corrosive” to be used as boat anchors (or more appropriate boat moorings)?

 A9: Since the 3745/6 Communication Controller supported hundreds of functions, it will take time before all customers will eliminate the need for their 3745/6 boxes but many customers will replace their 3745/6 boxes with the CCL. My team feels that the fitting place for retirement of these great boxes is to have a permanent home in the Smithsonian Institute within the History of Computing wing.

Thank you very much Mac.

We know that your first interview was a major hit and this interview will be invaluable to those that have an interest in SNI.  Mac, maybe you can do a few more interviews for us on other SNA/IP topics in the future.  Lets sign off here, wishing that the CCL will prosper for as long as the 37xxs did!