Today’s video-on-demand (VoD) systems are centralized in many respects – resource management, session management, and storage. However, there are many benefits from distributed architectures for some or all of the above. Many of the lessons that have been learned from widespread deployments of VoIP and other content-based networks can be applied to VoD networks. Today’s video servers in many cases actually perform several logical functions, including session based resource management, storage, video streaming, etc. Separating, at least at a logical level, many of these components can provide significant benefits in terms of scalability, cost, and performance. One candidate for breaking out from the components that actually store and stream the video is session and resource management. And beyond simply breaking out the different logical functions from each other, each individual function can be also done in either a centralized or distributed way themselves. It’s the “all knowing database in the sky and dumb edge boxes” vs. “smarter edge devices that manage their own capabilities” debate that has raged on for years in networking, most recently manifesting itself in the VoIP debates. To enable distributed resource management, network components responsible for allocating different classes of session-based resources can be separated from the session and resource manager. A component called the session manager is then responsible for determining the classes of resources required for a session request and communicating with the resource managers responsible for allocating those resources. There are two predominate schools of thought on how the session manager interacts with resource managers. The first has the session manager responsible for the final decision on all resources. This model is a logical outgrowth of session resource management vendors who currently implement both session and resource management in the same node. In this model, the session manager would receive a session setup request, and then send individual messages to various resource managers to ask for the potential resources that are available for that session. Then having all of the information locally in one place, the session manager decides which resources should be used for that session. This model is similar to the centralized call manager model used in some VoIP networks. Alternatively, session resource allocation can be distributed in more of a flow-through. In this model, the session manager would receive a session setup request, determine the classes of resources needed for the session and then let the resource managers themselves determine the actual resources to be allocated for the session. Instead of the session manager communicating directly with each resource manager, it embeds a list of resource managers that must be used into a resource request and sends the resource request to the first resource manager on the list. Resource managers then communicate with each other to determine the optimal set of resources for the session. This threaded model of signaling, takes advantage of the concept of a signaling proxy which is common in Internet protocols such as HTTP, RTSP, SIP, and others. Internet deployments of signaling proxies have shown that they are very adaptable to changes in services and that they scale to very large networks since functionality is distributed. This paper will go into detail on the pros and cons of distributed versus centralized control architectures for session and resources management. It will cover specific call flow examples, processing requirements, scalability concerns, and where possible real world examples of how this has been done in existing networks today.