Home > Articles > Networking

  • Print
  • + Share This

2.4 Signaling

Assuming that you can provide differentiated queuing and scheduling on a per-hop basis and have the appropriately controllable underlying link layers, the question becomes one of establishing and modifying the network's actual behavior. This matter requires coordination of the actual (rather than theoretical) behaviors along each path. A generic term for this process is signaling—the act of informing each hop along a path (or paths) how to recognize traffic for which a special processing behavior is required and the type of special processing required.

Signaling can be achieved in a number of ways with varying degrees of timeliness, flexibility, and human intervention (not all of which are conventionally considered signaling per se). At one extreme sits dynamic edge-to-edge signaling, where the network is informed each and every time a new class of traffic requires specific support.

The network itself responds on demand by internally establishing additional information (or modifying existing information) at each hop to achieve the requested edge-to-edge behavior. Examples of on-demand signaling include ATM's User Network Interface (UNI) and Network Node Interface (NNI) signaling protocols and the IETF's Resource Reservation Protocol (RSVP).

New network technologies frequently either do not have fully dynamic signaling protocols defined or have not matured to the point where reliable implementations of their signaling protocols exist. Under such circumstances the networks are usually provisioned for new services—often entailing human intervention to configure (or reconfigure) the controllers of the links and nodes along the affected paths. Provisioning is a form of signaling, even though the response time is usually orders of magnitude slower than dynamic signaling.

Because the number of links and nodes in a network can be quite large, many vendors are developing centralized controllers or servers where configuration or provisioning actually occurs. These controllers then automatically distribute the appropriate rules to the links and nodes in the network on behalf of the human operator. Designs that are more advanced allow these controllers to automatically react to changing network conditions in accordance with general policies that may be imposed by the human operator. Although such centralized schemes also constitute a dynamic mechanism, they differ from edge-to-edge signaling in that it is not user controlled.

The Internet has used a form of dynamic signaling for years—its routing protocols. Although most of us have been conditioned to think of signaling and routing as distinct activities, protocols such as Open Shortest Path First (OSPF) and Border Gateway Protocol (BGP) are the Internet's mechanisms for signaling topology changes. These mechanisms ensure the construction of up-to-date forwarding tables that reflect the best set of shortest paths across the network and adapt dynamically to changing topological conditions. Therefore, these mechanisms (that is, OSPF and BGP) qualify as signaling protocols. However, their focus is internal to the network itself, and their actions are generally not explicitly triggered by some user's request. Furthermore, their actions are designed primarily to effect the construction of paths, not the allocation of resources or priority processing for specific traffic along those paths.

Typically, signaling in the IP context is thought of as the additional actions required to establish a particular edge-to-edge QoS over and above the default Best Effort QoS. As previously noted this process can involve dynamic or provisioned behaviors (or some combination). In all cases, the process of establishing a desired edge-to-edge QoS requires careful balancing of existing per-hop resources and network-wide paths.

When a signaling request states a particular QoS goal, there are a number of variables to consider. In theory, both the path and the resources along the path are open to modification. For a given path, the signaling protocol should determine whether resources (for example, queuing space or share of link bandwidth) are available along that path. If the first path checked does not support the desired QoS, an ideal signaling protocol would find another path and try again. As an example, ATM's Private Network Node Interface (PNNI) signaling tries different paths until it finds one that can support the requested edge-to-edge QoS. Trying alternative paths presumes that the network has the capability to force traffic along the path that is discovered to be capable of supporting the desired QoS.

In conventional connectionless IP, however, traffic must follow the shortest-path trees established by the routing protocols (using whatever metric is specified by the network operator). As a consequence the IETF developed its RSVP signaling mechanism to simply follow (and adapt to) whatever routing exists in the network without attempting to discover alternative, non-shortest-path routes that might better support the requested QoS. Inherently a trade-off, RSVP avoids any reengineering of existing IP networks, doesn't reinvent or replicate the actions of the existing IP routing protocols, and can be introduced as a simple hardware or software upgrade to existing routers. However, if resources are exhausted along a particular shortest path, no simple way exists for RSVP to force traffic along a longer, but perhaps more lightly loaded path.

Another issue with signaling is the amount of additional state information the routers must carry. State information is anything that the router needs to characterize the special traffic—for example, IP header information on which to classify the packets—and to process the special traffic—for example, associated queue(s), packet-drop parameters, and scheduler priorities or weights. The routing and forwarding tables already held by each router represent topological state information—adding signaling for QoS only increases the number of tables consuming valuable memory in routers.

Any realistic QoS solution for IP networking must cope with the often conflicting demands that it be easy to implement, not send the amount of state information skyrocketing, optimize the use of network resources, adapt dynamically to routing changes, and work in a world where routing and signaling are decoupled.

  • + Share This
  • 🔖 Save To Your Account

Related Resources

There are currently no related titles. Please check back later.