Can anybody explain these different fields in both the algorithms and their usage.
Both these fields are designed to detect it if someone in the middle tries to play games with the encrypted data. That is, if the receiver decrypts the data, GCM tries to ensure that the data he received is precisely what the sender sent.
The authentication tag is the easiest to understand; it's a complex function of the ciphertext; if the attacker generates his own ciphertext (or modifies one that was sent), we have a provably [1] low probability that the tag the attacker sent will be the tag computed by the receiver; if the tag doesn't match, the message is rejected.
The Additional Authenticated Data (AAD) is there to address a more subtle issue; what if the attacker takes a message that was sent in one context, and resend it into another. To take a fancible example, we can have:
Alice: Encrypt("Do you like ice cream") -> Bob
Alice: <- Encrypt("Yes") : Bob
Alice: Encrypt("Will you marry me" ) -> Bob
If a prankster were to take Bob's first yes (to an innocuous question) and repeat it to Alice, well, Alice may think that Bob just accepted her marriage proposal.
AAD is there to frustrate such pranksters; with each GCM encryption, the AAD can be used to signify the context that the encryption was sent.
During encryption, Alice encrypts with the AAD that corresponds to the context she means; Bob decrypts with the AAD that corresponds to the context he meant. If Bob receives the message in the wrong context (for example, the answer to the wrong question), the tags won't match, and the message will be rejected.
The AAD can be any string that identifies the encryption; it might be just a serial number (e.g. "1" for the first message, "2" for the second); in my whimsical example, the AAD for the answers might just be the question the answer was to.
And, if you're using GCM in such a way where you are only encrypting only a single message with a key (e.g. as the symmetric part of IES), you can leave it out (because you don't need the security service that it provides).
[1]: Any such provability statement makes assumptions: the ones here are a) the attacker doesn't know the AES key, b) AES isn't broken, c) the attacker hasn't seen two different valid ciphertexts messages with the same nonce