While I have not yet implemented it I do intend to and have read through both the OAuth 1 RFC and OAuth 2 draft several times. Unlike OAuth 1 RFC the OAuth 2 draft goes into quite a lot of detail as to how to implement the server and you will find all the details you need in the draft.
What you will need to first figure out is your target group of clients since that will help you decide which methods of authorization you need to support.
Web apps? Check out http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-4.1
JS apps? http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-4.2
Desktop apps? http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-4.3 (if the user will trust your app with their credentials)
The protocol basically boils down to generating tokens using adequate crypto functions and encoding and sending parameters properly. For an example of how the communication might look like go to the Google OAuth 2 Playground.
For example, the draft clearly states that when a client requests authorization as per 4.1 (Authorization Code Grant) it supplies the mandatory fields response_type and client_id together with the two optional fields redirect_uri and scope, as well as the recommended state field. In your server implementation you thus extract and validate those parameters (you may define additional required parameters), authorize the user and if all is well redirect to the client specified redirect uri (including an authorization grant).
How you authenticate clients can vary but the spec suggests that using HTTP Authentication would work fine for web apps (but not apps where hiding the client credentials is difficult).
It is very important that all communication is over a secure channel (TLS/SSL). OAuth is not a substitute for TLS/SSL.