寒冬过后的挑战
两年前，网络处理器吸引了所有的注重力，而现在，交换结构（Switch Fabric）正面临新机遇。虽然交换背板的概念成为路由器和交换机的标准才仅仅几年时间，但一些厂商认为这种概念在应付大量端口、更高的线速度和服务质量(QoS)形成的多种压力的能力上已经碰到了障碍。
必须承认，电信业的不景气造成了大型交换机市场的疲软。但是，电信业仍在继续发展，许多业界观察家认为路由器和交换机的规模越变越大是不可避免的。当这一天到来时，人们会问现有Switch Fabric是否能满足要求。许多人认为将需要全新的架构和全新的算法来实现。
解决问题的方法并不简单，比如说：设计者可以将注重力集中在尽可能少地丢弃包，但这可能会导致高优先级传输流受到阻塞。设计者可以将重点放在满足高优先级传输流上，但这可能会使低优先级的数据完全被丢弃。无论哪种方式，设计者都必须为众多的队列排定优先次序，并恰当地调度输入与输出端口之间的交叉匹配交换操作。
在理想的输出排队Switch Fabric中，传输流到达输入队列，接着被传送穿过交换元件，然后没有任何延迟地通过出口队列离开。由于大多数Switch Fabric将传输流分割为固定长度的信元，因此在出口端口轻易出现传输流的拥塞。比如像IP包这样的可变长度传输流会被细分为多个信元。这种作法通过确保所有的端口同步传送或接收，从而简化调度功能。
但是，按照这样的规则，这些信元必须为争取处理资源而竞争。每个输入端口可以立即向Switch Fabric发送信元，但是在接收端上，每个输出端口只能将一个信元发送到系统之外。其他信元必须被缓冲。假如等待信元的数量超过缓冲区长度，那么随后的信元可能就会被丢弃。
传输流治理器
传输流治理器可以解决一些问题，但是一些厂商对太多依靠这一机制持谨慎态度。
现有高端Switch Fabric采用了许多避免丢包或至少保证高优先级包不被丢弃的技巧。首先，大型Switch Fabric在多个位置需要队列。在理想的情况下，你可能只在输出端口上具有队列，但是假如有一个输出端口变得太拥挤，将使交换机轻易受到阻塞的影响。例如，假如每个输入端口在每个时钟周期向输出端口1发送一个信元的话，除非队列缓冲区无限大，否则这个输出端口会迅速溢出。
因此，输入端口上或中心Switch Fabric自身需要队列。Vitesse SemicondUCtor公司的TeraStream结构就是一个例子。这种设计用于聚合高达160 Gbps的吞吐量的结构，利用多层次的调度功能和一种存储―转发架构。在其存储转发架构中，除了输出端口上的缓冲区外，在Switch Fabric中还有一组缓冲区。每个纵横位置都有一组优先级队列。因此，即使输出端口十分繁忙，仍可以从输入端口发送帧，发送的帧将被保存在Switch Fabric中。
但是假如传输流在到达输出端口前排成长队，那么有造成可怕的线端(head-of-line)阻塞的可能性。假设有一个低优先级包到达输入端口1，并且后面紧跟着一个高优先级包。端口1现在陷入了困境，因为高优先级包要等到低优先级包移动之后才能移动，而低优先级包可能一时不会移动到任何地方。
因此，大多数现代Switch Fabric采用虚拟输出队列，在虚拟输出队列中，每个输入端口都有一条针对每个输出端口的独立队列。这就防止了线端阻塞，但却造成了调度问题：对于一台具有N个端口的路由器来说，这意味着系统需要应付N × N条队列。为了调度这些队列，大多数高端结构采用一种请求与批准系统。现任斯坦福大学副教授Nick McKeown发明的iSlip算法就是这样的经典例子。像iSlip这样的算法执行请求-批准过程的多次迭代，寻找输入端口/输出端口匹配的最佳排列。
QoS策略
最近，一些公司已经开始宣称请求-批准方案不足以提供QoS保证，并说这类方案不能提供满足服务水平协议的保证带宽。目前QoS被认为是至关重要的特性，因为它是服务提供商潜在的摇钱树。Nortel Networks公司首席科学家Victor Firoiu说，请求-批准算法的一些变种试图包括QoS功能，但它们一般过于复杂，以致没有什么用处。
Firoiu近期提出了一种首先利用反馈回路避免拥塞的Switch Fabric架构。Firoiu的反馈输出队列(FOQ)架构提前通告拥塞的输入端口，使Switch Fabric不浪费资源地去转发可能将被丢弃的包或信元。FOQ架构可以单独地进行控制，这样请求-批准周期不会每次当一个新数据报达到时都被激活。
来自Internet Machines公司的一种不同的反馈方法让输出端口告诉输入端口减速，来防止丢弃信元。这种功能是利用公司自己的叫做动态分布式加权公平队列技术(DDWFQ)的请求-批准算法实现的。
Avici Systems公司的Switch Fabric略微有所不同，它由多个可以安装在不同设备机架中的部件组成。但是，其大多数概念是相同的，并且Avici在带宽共享方面还增加了自己的东西。简单地说，Avici将传输流划分为两个级别：一个级别用于严格的优先级，赋予实时视频等，而第二类传输流在Switch Fabric上共享带宽，保证所有的低优先级流得到处理。
这种划分效果很好，原因不仅是它为实时传输流提供了优先级，而且是由于这些实时传输流一般都是确定性的。换句话说，视频流在整个传输期间可能消耗恒定量的带宽，从而简化了路由器在是否为视频流分配所需带宽上的决策。假如系统无需占用低优先级会话带宽就可满足实时流，那么它就可以在实时流生存期内安全地锁定所需要带宽。
