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.
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.
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.
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.
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. Its 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.
Introduction This article will help you understand the steps on how to
download the UCS licenses from the Cisco Systems website and then
installing it on the UCS. The redacted (blue lines) just covers up
certain numbers for privacy please do not take them...
Introduction This article will help you understand and educate the
customer on how to clear their "expired licenses"
(license-graceperiod-expired) from their UCS-M. If a customer just
purchased a license and needs a step by step guide on how to download
==================== VIC FNIC driver does not support Virtual Volumes (
second level LUN ID ) An enhancement request has been created to track
this feature - CSCux64473 UPDATE - 12-14-2016 We made some traction on
the enhancement request - The Fix is in t...