I field a fair amount of questions from my customers and users on the Technet forums about the Director role - why is it needed, how does it play into a global architecture, etc. I thought I'd address a few of these topics for other folks with the same questions.
The first thing to know about the Director role is that it's built into OCS Standard and Enterprise - it is not a separate installation like an Edge or Mediation server. Every Standard server and Enterprise pool acts as a Director by default. So why do we need to dedicate one or more servers to this role? First let's review the purpose of a Director.
If you've ever configured an Edge server you noticed that it needs to know it's next hop. The Edge server is pretty intelligent when it comes to blocking traffic that is not permitted and taking care of other OCS security functions, but by design it does not have knowledge of where users are homed and how to authenticate them (which is why it can and should be deployed without being a member of Active Directory). The Edge relies on the next hop server to handle these items. Once it confirms that a set of communication should be passed to the inside, the next hop server can do a few things. Two major steps take place when a user logs on to Communicator:
1) Match the SIP address to a user account in AD and perform authentication
2) After authentication succeeds, route the traffic to the pool specified in the user's AD properties
These steps are basically the same whether the user connects via the Edge (remote access) or from the internal network, though the benefits are slightly different. In both cases the Director provides the benefit of offloading authentication from the pool. This is most helpful if you are pushing the limits on capacity. In an Edge scenario you have the added benefit of an extra security boundary. In the event that an attacker is able to pass through an Edge server or initiate a successful DoS attack, your internal pool environment would not be impacted.
So far, this all sounds pretty good. If you've made the decision to deploy a Director all you have to do is deploy a Standard server, Enterprise pool, or array of Standard servers and disable the services you don't need (Web Conferencing, A/V Conferencing, and Web Components - see page 48 of the Edge Server Deployment Guide for more details), change the next hop on your Edge server, and modify your _sipinternaltls._tcp SRV record to point to the new Director(s).
Now, if you are in the process of architecting a global topology complete with redundancy, you'll pause about the time you think about the contents of the SRV record. Since there can be only one _sipinternaltls._tcp record per domain and it can only point to a single FQDN, where do you put the Director(s)? For simplicity's sake let's assume you have pools in North America, Europe, and Asia. We're also going to assume you have a fully replicated DNS infrastructure (AD or otherwise). If you place a pool of Directors in North America and the connection between Europe and NA goes down (another freight ship somehow ran over the transatlantic fiber run that your telco uses 
), your European users will be unable to login to Communicator until the SRV record is modified or the connection is re-established. To guard against that you can deploy an array of Standard servers in all your data centers, but now comes the major dependency - global redundancy. Because this is now at the network layer there's nothing we can do within OCS to design for this. GSLB (global server load balancing) is basically your only option. Various vendors can employ this (F5, Foundry, Cisco, etc.), and the exact deployment requirements are defined by those vendors, so check with them for details. However, no matter which vendor you choose you'll need this capability to accomodate for such a scenario.
There are other topologies and options. Some customers I've worked with have separate internal DNS zones for each country, so we were able to deploy regional SRV records. This only works if you will not use PIC or federation since most internal DNS namespaces are not internet routable. In another instance it was decided to use group policy to deploy the server settings to the clients and forego autodiscovery altogether (political, regional, and technical complexities all played into this decision).
I hope you'll find this information helpful. Byron Spurlock also has some related information on his blog as well if you'd like to read up a little more on Directors.
