SNA and QOS

[cdjohnson]

Subject: SNA/QOS

I AM CURRENTLY RUNNING 12.1(11a) IOS ON A ROUTER BASED NETWORK WITH FOUR

7500 ROUTERS. I AM CURRENTLY RUNNING CUSTOMER QUEUEING AS MY QOS. I AM

NOW LOOKING TO USING LLQ W/ CBWFQ AND DISTRIBUTED MODES, AS WELL. I HAVE

VIP-40 CARDS IN ALL ROUTER. HOWEVER, MY NETWORK IS COMPOSED OF --

TP0 - BATCH TRAFFIC

TP1- INTERACTIVE TRAFFIC

TP2-CONTROLLED TRAFFIC - HIGH AMOUNTS

I HAVE BEEN TOLD THAT CISCO'S QOS WILL SUPPORT TP1 TRAFFIC SO, I AM

CONCERNED ABOUT MY TP2 (CONTROLLED TRAFFIC) AND IF I CAN IMPLEMENT LLQ/CBWFQ

INTO MY NETWORK.

I WOULD LIKE TO IMPLEMENT THIS FOR MY CRITICAL APPS SUCH AS SNA, AND HTTP

WEB BASED APPS. THUS, LIMITING MY SQL, FTP AND TELNET TRAFFIC.

THANKS IN ADVANCE.

ANY PPT FILES WOULD BE APPRECIATED.

[dmccullo]

Hi Connie,

You open the door to an interesting discussion, by including both SNA and QoS in your question. As you know, a variety of QoS mechanisms have been available for SNA traffic for quite a while. I can't tell from your description what sort of traffic is contained in "TP2-CONTROLLED", so I will assume it is voice and video traffic, and not the "TP2" from OSI Transport Protocols.

The quick answer is that you can definitely support TP1 traffic while protecting the quality of your TP2 traffic. Essentially you decide what percentage of the available bandwidth to allocate to each class of traffic, providing a minimum guaranteed value. In addition, there is a special class, Low Latency Queuing (LLQ), available for delay and jitter sensitive traffic such as voice. Within each traffic class, IOS will then provide Weighted Fair Queuing (WFQ) for each unique flow (session). This becomes a bit more interesting when combined with different WAN types such as frame relay and ATM, you can take advantage of the VIPs that you mention, and there are considerations for low speed circuits. So here are a couple of URLs that provide more information.

http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/qos_c/qcprt2/qcdconmg.htm

http://www.cisco.com/univercd/cc/td/doc/product/voice/ip_tele/avvidqos/qoswan.htm

Coming back to the SNA traffic, I assume you're currently using custom queuing with DLSw+, using the priority parameter to create four TCP connections, and classifying traffic using one of the three available methods. In moving to a CBWFQ model, you will want to map the existing custom queues into the newly created classes. In other words, you can continue to use the same classification techniques, while changing to the easier to define, and more efficient WFQ for output queue processing.

The absolute best traffic classification comes with using the Enterprise Extender (EE) feature of SNASw. When SNA traffic is sent across an EE link, the precedence bits in the IP packets are automatically marked with the same values that are used in the SNA Class of Service (CoS). Since SNASw is our APPN node implementation, propagating the precedence markings from SNASw to DLSw+ also provides an automatic means of classifying the SNA traffic.

Rgds, Dan

[cdjohnson]

To answer two of your questions the TP2 is controlled

SNA over IP traffic, not voice or video. Also, we are currently using only CQ with no priority parameters to create the four TCP connections, nor are we classifying traffic. We are in the process of seeing what's available (i.e. LLQ and EE) Most of our WAN links are point to point w/ a little FR.

Thanks for links and EE information.

[david.wilkinson]

Dan

Is Cisco still actively enhancing SNASw and EE services within IOS, or are they at the end of development? The reason for the question is, given Cisco's overall strategy of moving to IP only networks, SNASw seems to prolong support for legacy protocols. I understand that this support is still currently very much required but for how long? I have a customer who is at the crossroads of continuing with SNA (easy option) or moving to IP (hard option) and I would value your opinion.

[dmccullo]

Hi David,

It's important to point out that SNASw is our second generation, or "NEW" APPN product. As such, we expect a long life in front of it, and we will be actively working with customers to ensure that it works in their networks.

As for enhancements to SNASw, and particularly Enterprise Extender (EE), we don't think it likely that much will be necessary. EE, and the critical Responsive mode Adaptive Rate Based flow control that enables it, has been remarkably stable from the very beginning. There is very little change taking place or anticipated in the APPN realm. Where changes and enhancements are necessary, we will step up to them. A recent example would be our making a change to accommodate the Global Connection Network capability that became available in Z/OS V1R2.

As for whether your customer ought to deploy SNASw or move to IP applications, it is probably more of a business/timing decision, than a technical one. The single largest factor is often the size of the application conversion effort, the (hard option) in your words, and estimating the size and duration of this move is often tricky.

Using EE to immediately move the business critical application traffic to a layer 3 IP routed network could be viewed as a huge enabling step towards deploying native IP applications. If SNASw is placed near the edge, adjacent to the SNA devices, and EE is used to connect to the host, you come very close to a purely IP network. It may also make sense to deploy SNASw in a more central location, allowing a move away from the endangered Token Ring technology, facilitating high speed layer 3 switching in the data center, and removing the need for front end processors.

On the other hand, if converting to SNASw looks to be a fairly lengthy project in itself, it may very well make more sense to devote that energy to changing the applications. It’s likely to all hinge on just how hard the hard option is, and whether the application conversion effort is actually underway, or truly about to begin.

Rgds, Dan