tain risk exists that the fate of a packet may already have been decided upon and that the packet may already have been forwarded onto a certain egress port before some other functionality of the switch had the time to step in and decide about some other overriding alternative that precludes the forwarding decision that was previously made. To further illustrate the point, cut-through archi- tectures are also well suited for low-end Ethernet switches since for instance they cannot manage traf- fic congestion with a QoS framework, they cannot check cyclic redundancy check (CRC) before actually forwarding, and SO on. For example, say that an incoming packet associated with a VPN enters the switch from one of its ingress points and with the appropriate prefixed label tag in an MPLS backbone network. The switch proudly decides on-the-fly that based on this label tag and the internal forwarding-associations table, the egress point for this specific packet is going to be its output port called X. The packet is now switched by the switch fabric onto the port X and bits start to exit the switch from that port while bits are still coming in at the ingress point. A traffic manager in conjunction with specific QoS require- ments that the switch must satisfy may then intercept a specific bit field of the incoming packet at the ingress point, which may for all practical purposes be located deep inside the parading packet. The switch/router all of a sudden may realize that this specific application class requires priority handling over a separate link. It may also require some exceptional treatment that is guaranteed through reserved bandwidth resources (as a result of Resource Reservation Protocol [RSVP] and DiffServ actions) associated with another egress port called Y. It will flag the event as an exception. The switch may then realize that the packet should not have been forwarded through egress point X in the first place. It will try to block the output, but it may already be too late for the next hop station, as some Dow