There are a number of reasons why this solution is not sufficient, some already covered in replies. However, the main problem, especially with modern DoS attacks is bandwidth.
Originally, DoS attacks were primarily about sending a sufficient number of requests to a server to swamp the servers ability to process the requests. Often it was a resource issue on the server i.e. not enough CPU or memory resources. In many cases, only a single service would be impacted. For example, the web server might appear to be unresponsive because of too many requests, but other service might still work.
Modern Dos, especially DDoS type attacks are now more about flooding the network. You have so much data coming in, your firewall, router and internal network becomes flooded. Part of the reason it is so devastating is that you cannot communicate effectively with anything else. You can't send a message to an upstream router because the connection is flooded - switches, firewalls and routers have become unresponsive. Even if you know what you want to tell the upstream device/router to do, you can't get the message through.
This is why the solution often involves your upstream service provider. Either you need a separate communication channel, which could even be a telephone call, to get your provider to take some action, such as creating a BGP 'black hole' for the ip address in your network which is being targeted. This 'black hole' will send all data addressed to your internal IP address to a black hole so that the amount of traffic coming down the pipe to your network drops off and you can now send/receive other data. The problem is, if you use NAT or similar, so that you really only have 1 public address, then the black hole means your effectively off the network and the DoS has succeeded. On the other hand, if you have multiple public IP addresses, then you may be lucky and only suffer a partial loss of service.
The other problem with your suggestion is that to work, it needs to be fast and light-weight. However, it also needs to be secure otherwise you would run the risk of creating a new DoS vector. for example, if you used a fast light-weight connecitonless protocol, it might be too easy to spoof the IP address. This would allow me to send requests to your upstream router pretending to be you asking that no data be sent. So, any commands which would affect what data is sent need to be secure and verifiable - you now have a command which requires more processing power to process - multiply that by the number of machines and now you have to have more powerful routers - faster with more memory and this multiplies as you move up from your local router, to your ISP router to the segment router etc.