Hi
1. The .bss section (variables initialised with 0) is about 75k in size and so occupies around 60% of the available SRAM of the K60
2. It is not absolutely clear whether you are building for execution in SRAM or in Flash. If in SRAM I can't imagine that there is then enough space for the bss, variable and code, however when building for Flash it will depend on the space required for initialised variables (including heap) plus stack sizes. This depends on the program and what it does.
3. I don't think that changing the linker script will help since the linker script is already telling the linker that it has about 128k SRAM to work with and this is the physical limit which can't be increased. However I may be wrong because the lnker script is breaking the SRAM into two areas, and possibly the linker wants to fit the 75k in just one of the two possible, but contiguous, areas. In this case it may be worth declaring the SRAM as one "single" area from 0x1fff0410... 0x20010000 instead.
4. If 3) doesn't help, you need to check what the space is being used for (the .bss and other variables - by studying the map file generated it is possible to see which chunks of storage are required by the various parts of the program) and see whether you can reduce this in the code by reducing buffer sizes (where configurable) or possibly reducing the heap size reserved (assuming it is not all needed). This will require a certain amount of understanding on the project parts used and the overall memory footprint/performance balance that can be adjusted to suit its aims. Possibly you could remove certain TCP/IP protocols from the stack to reduce memory requirements.
Regards
Mark
P.S. I notice that many students/developers in China use full versions of IAR. In Europe most people use CodeWarrior (or more recently KDS) because IAR is (although very good) very expensive. Does IAR have a different price politic or student versions that allows its widespread use in certain parts of the world?