This is not a trivial question with a simple answer. You are basically showing part of a GMLAN transaction.
The 0x2C request is the Dynamic PID, or 'DPID' request, and the AA is the actual request for data. The reason that the AA has params is you control requested rate and formatting.
Clearly you are looking at CAN, which is, I think, even more complicated than GMLAN over J1850 VPW. Some responses will be over non standard handshaking pairs. That is, typically in standard mode (11 bit) CAN, there is an offset of 8 between the ID the ECU uses to talk to you and the ID you use to physically talk to it. You can see this by requesting standard DTCs or something like VIN from any generic CAN ECU. But for some GM modules, the pairs are just 'known', you can't find them by a simple formula.
Also, some requests result in completely nonstandard responses. Typically, the first byte in an OBD-II CAN response will tell you if it is self contained, or a multi packet response. But some GMLAN data streams don't follow the ISO protocol.
The common paths to detailed GMLAN knowledge are generally choice a) pay GM $50K and enter a non disclosure agreement or b) reverse engineer, which I can personally attest is quite a bit of work. So I don't think you'll find a lot of folks who are free and easy with the knowledge.
Personally, I'd say that what you appear to be trying to do - essentially spy on someone else's software and pick up a little know how, is not all that difficult. However, I'd put the odds of writing a GMLAN implementation without even investing in some second hand ECU's for the bench at about 0%.
Edit: Although not all ECU's support them, a lot of basic stuff can sometimes be gotten via mode 22 PIDs, which generally follow the standard OBD-II communication rules. That might be a simpler path for you.