her hand, routing, microscopically speaking, in many contexts refers to the process of actually build- ing the table itself, although macroscopically it is associated in people's minds mostly as implying the forwarding function. This is the right time to clarify two common terms that may already be familiar to many readers and are used quite frequently in the industry in order to characterize specific design philosophies that lead to specific architectures. A store-and-forward architecture, as the term implies, stores the incoming packet temporarily and then decides what to do with it. On one hand, it gives the architect more flexibility and wider appli- cability for the final outcome of the packet handling process. On the other hand, it also implies a higher implementation cost, as buffering facilities must be provided and as an overall longer end-to- end delay is incurred due to increased latency from the ingress point to the egress point. This is obvi- ously the case even if the storage time is shrunk down to minimum acceptable levels for a specific application. For example, this is certainly applicable in a typical low-end router and/or Ethernet hub. An incoming packet is first written into memory and then the switching device's CPU decides on which port to output it. A cut-through design eliminates both the cost of the extra buffering and the longer latency asso- ciated with store-and-forward architectures by making the forwarding decision on-the-fly, based on specific bit fields that it parses in real-time on the incoming packet headers. In many cases, given the high wire speed, this decision must be made even before the incoming serialized packet has com- pletely entered the switch/router. A typical example would be the latest MPLS switches on the WAN backbone, where the small label tag that has been prefixed to the arriving packet already signals to the switch the switch output port from which the packet must egress. It is clear that this approach only lends itself to some very fast implementations. A cer