Network Working Group C. Boulton Internet-Draft Avaya Intended status: Standards Track R. Even Expires: May 22, 2008 Polycom November 19, 2007 Media Resource Brokering draft-boulton-mediactrl-mrb-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 22, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Boulton & Even Expires May 22, 2008 [Page 1] Internet-Draft Media Resource Brokering November 2007 Abstract The MediaCtrl work group in the IETF is currently proposing an architecture for controlling media services. The Session Initiation Protocol will be used as the signalling protocol which provides many inherent capabilities for message routing. In addition to such signalling properties, a need exists for intelligent, application level media service selection based on non-static signalling properties. This is especially true when considered in conjunction with deployment architectures that include 1:M and M:M combinations of Application Servers and Media Servers. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 6 3. Problem Discussion . . . . . . . . . . . . . . . . . . . . . . 7 4. Deployment Scenario Options . . . . . . . . . . . . . . . . . 8 4.1. Query MRB . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1.1. Hybrid Query MRB . . . . . . . . . . . . . . . . . . . 9 4.2. In-Line MRB . . . . . . . . . . . . . . . . . . . . . . . 10 5. Interface Discussion . . . . . . . . . . . . . . . . . . . . . 12 5.1. Media Server Resource Publishing Interface . . . . . . . . 12 5.2. Media Service Resource Consumer Interface . . . . . . . . 12 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. Normative References . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 18 Boulton & Even Expires May 22, 2008 [Page 2] Internet-Draft Media Resource Brokering November 2007 1. Introduction The topic of Media Resources has been in discussion for a number of years with varying proprietary solutions being used. It is clear that as we move towards a consistent architecture and protocol for Media Server Control, a standard mechanism is required for accurate media resource location. As IP based telecom infrastructures mature, the complexity and demands from deployments increase. Such complexity will result in a wide variety of capabilities from a range of vendors that should all be interoperable using the architecture and protocols produced by the MediaCtrl work group. It should be possible for a controlling entity to be assisted in Media Server selection so that the most appropriate resource is selected for a particular operation. The importance increases when you introduce a flexible level of deployment scenarios, as specified in the MediaCtrl requirements[ref]. This document states that "it should be possible to have a many-to-many relationship between Application Servers and Media Servers that use this protocol". This leads to the following deployment architectures being possible when considering media resources. The simplest deployment view is illustrated in Figure 1. +---+-----+---+ +---+-----+---+ | Application | | Media | | Server |<-------MS Control------>| Server | +-------------+ +-------------+ Figure 1: Basic Architecture This simply involves a single Application Server and Media Server. Expanding on this view, it is also possible for an Application Server to be controlling multiple (greater that 1) Media Servers. This deployment view is illustrated in Figure 2. Typically, such architectures are associated with application logic that requires high demand media services. It is more than possible that each media server possesses a different media capability set. Media servers may offer different media services as specified in the Mediactrl architecture document. A Media server may have similar media functionality but may have different capacity or media codec support. Boulton & Even Expires May 22, 2008 [Page 3] Internet-Draft Media Resource Brokering November 2007 +---+-----+---+ | Media | +----->| Server | | +-------------+ | +---+-----+---+ | +---+-----+---+ | Application | | | Media | | Server |<--MS Control-----+----->| Server | +-------------+ | +-------------+ | | +---+-----+---+ +----->| Media | | Server | +-------------+ Figure 2: Basic Architecture Figure 3 conveys the opposite view to that in Figure 2. In this model there are a number of (greater than 1) application servers controlling a single media server. Typically, such architectures are associated with application logic that requires low demand media services. +---+-----+---+ | Application | | Server |<-----+ +-------------+ | | +---+-----+---+ | +---+-----+---+ | Application | | | Media | | Server |<-----+-----MS Control-->| Server | +-------------+ | +-------------+ | +---+-----+---+ | | Application | | | Server |<-----+ +-------------+ Figure 3: Basic Architecture The final deployment view is the most complex. In this model (M:M) there exists any number of Application Servers and any number of Media Servers. It is again possible in this model that media servers might not be homogenous and have different capability sets. Boulton & Even Expires May 22, 2008 [Page 4] Internet-Draft Media Resource Brokering November 2007 +---+-----+---+ +---+-----+---+ | Application | | Media | | Server |<-----+ +---->| Server | +-------------+ | | +-------------+ | | +---+-----+---+ | | +---+-----+---+ | Application | | | | Media | | Server |<-----+-MS Control-+---->| Server | +-------------+ | | +-------------+ | | +---+-----+---+ | | +---+-----+---+ | Application | | +---->| Media | | Server |<-----+ | Server | +-------------+ +---+-----+---+ Figure 4: Basic Architecture This document will take a look at the specific problem areas related to such deployment architectures and some potential solutions. Finally some proposed Interface solutions will be looked at in more detail. Boulton & Even Expires May 22, 2008 [Page 5] Internet-Draft Media Resource Brokering November 2007 2. Conventions and Terminology In this document, BCP 14/RFC 2119 [RFC2119] defines the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL". In addition, BCP 15 indicates requirement levels for compliant implementations. This document inherits terminology proposed in the MediaCtrl Framework [ref]. In addition, The following terms are defined for use in this document and for use in the context of the MediaCtrl Work group in the IETF: Media Resource Broker (MRB) A logical entity that is responsible for both collection of appropriate published Media Server (MS) information and supplying of appropriate MS information to consuming entities. Query MRB An instantiation of an MRB (See previous definition) that provides an interface for an Application Server to retrieve the location of an appropriate Media Server. The result returned to the Application Server can be influenced by information contained in the query request. In-line MRB An instantiation of an MRB (See definition) that directly receives requests on the signalling path. The decision making process is totally delegated to the MRB. Boulton & Even Expires May 22, 2008 [Page 6] Internet-Draft Media Resource Brokering November 2007 3. Problem Discussion It is clear from Section 1 that the MediaCtrl group will be producing a solution that must service a wide variety of deployment architectures. These range from the simplest 1:1 relationship between Media Servers and Application Servers to potentially linearly scaling 1:M, M:1 and M:M deployments. This still does not seem like a major issue for the proposed solution until you add a number of additional factors into the equation that increase complexity. As Media Servers evolve it must be taken into consideration that where many can exist in a deployment, they may not have been produced by the same vendor and may not have the same capability set. It should be possible for an Application Server that exists in a deployment to select a Media Service based on an appropriate capability set. In conjunction with capabilities, it is also important to take available resources into consideration. The ability to select an appropriate Media Service function is an extremely useful feature but becomes even more powerful when considered in conjunction with available resources for servicing a request. In conclusion, the intention is to create a tool set that allows MediaCtrl deployments to effectively utilize the available media resources. It should be noted that in the simplest deployments where only a single media server exists, an MRB function is probably not required. Only a single capability set exists and resource unavailability can be handled using the appropriate underlying signalling e.g. SIP response. Boulton & Even Expires May 22, 2008 [Page 7] Internet-Draft Media Resource Brokering November 2007 4. Deployment Scenario Options On researching Media Resource Brokering it became clear that a couple of high level models exist. The general principles of "in-line" and "query" MRB concepts are discussed in the rest of this section. 4.1. Query MRB The "Query" model for MRB interactions provides the ability for a client of media services (for example an Application Server) to "ask" an MRB for an appropriate Media Server, as illustrated in Figure 5. +---+-----+---+ +------------>| MRB |<----------+----<-----+---+ | +-------------+ (1)| | | | | | | |(2) +---+--+--+---+ | | | | Media | | | | +---->| Server | | | | | +-------------+ | | | | (1)| | +---+--+--+---+ | +---+-----+---+ | | | Application | | | Media | | | | Server |<-----+-MS Control-+---->| Server |->-+ | +-------------+ (3) | +-------------+ | | | | +---+-----+---+ (1)| +---->| Media | | | Server |--->---+ +---+-----+---+ Figure 5: Query MRB In this deployment, the Media Servers use the "Media Server Resource Publishing Interface", as discussed in Section 5.1, to convey capability sets as well as resource information. This is depicted by (1) in Figure 5. It is then the MRB's responsibility to accumulate all appropriate information relating to media services in the logical deployment cluster. The Application Server (or other media services client) is then able to query the MRB for an appropriate resource (as identified by (2) in Figure 5). Such a query would carry specific information related to the Media Service required and enable the MRB to provide an increased accuracy in its response. This particular interface is discussed in "Media Resource Consumer Interface" in Section 5.2. The Application Server is then able to direct control commands (for example create conference) and Media Dialogs to the Boulton & Even Expires May 22, 2008 [Page 8] Internet-Draft Media Resource Brokering November 2007 appropriate Media Server, as shown by (3) in Figure 5. 4.1.1. Hybrid Query MRB As mentioned previously, it is the intention that a tool kit is provided for MRB functionality within a MediaCtrl architecture. It is expected that in specific deployment scenarios the role of the MRB might be co-hosted as a hybrid logical entity with an Application Server, as shown in Figure 6. +------------<----------------<---------+----<-----+---+ | (1) | | | | | | | | +---+--+--+---+ | | | | Media | | | V +---->| Server | | | +------+------+ | +-------------+ | | | MRB | | | | +---+--+--+---+ | +---+-----+---+ | | | Application | | | Media | | | | Server |<-----+-MS Control-+---->| Server |->-+ | +-------------+ | +-------------+ | | | | +---+-----+---+ | +---->| Media | | | Server |--->---+ +---+-----+---+ Figure 6: Hybrid Query MRB - AS Hosted This diagram is identical to that in Figure 5 with the exception that the MRB is now hosted on the Application Server. The "Media Server Publishing Interface" is still being used to accumulate resource information at the MRB but as it is co-hosted on the Application Server, the "Media Server Consumer Interface" has collapsed. It might still exist within the Application Server/MRB interaction but this is an implementation issue. This type of deployment suits a single Application Server environment but it should be noted that a "Media Server Consumer Interface" could then be offered from the hybrid if required. In a similar manner, the Media Server could also act as a hybrid for the deployment cluster, as illustrated in Figure 7. Boulton & Even Expires May 22, 2008 [Page 9] Internet-Draft Media Resource Brokering November 2007 (1) +---+-----+---+ +---+---+------------->---------------->----------->| MRB | | | | +---+--+--+---+ +---+-----+---+ | | +-<-| Application | | Media | | | | Server |<--+-MS Control-+------->| Server | | | +-------------+ | +-------------+ | | | | | +---+--+--+---+ | | +---<---| Application | | | | Server |<--+-MS Control-+--+ | +-------------+ | | | | +---+--+--+---+ | +---<-------| Application | | | Server |<--+-MS Control-+--+ +-------------+ Figure 7: Hybrid Query MRB - MS Hosted This time the MRB has collapsed and is co-hosted by the Media Server. The "Media Server Consumer Interface" is still available to the Application Servers (1) to query Media Server resources. This time the "Media Server Publishing Interface" has collapsed onto the Media Server. It might still exist within the Media Server/MRB interaction but this is an implementation issue. This type of deployment suits a single Media Server environment but it should be noted that a "Media Server Publishing Interface" could then be offered from the hybrid if required. 4.2. In-Line MRB The "In-line" MRB has a subtle difference from the "Query" model that was discussed in the previous section. The Concept of a "Media Server Consumer Interface" disappears. The client of the MRB simply uses the signalling to offload the decision making process - this applies to both media server Control and Media Dialogs. This type of deployment is illustrated in Figure 8. Boulton & Even Expires May 22, 2008 [Page 10] Internet-Draft Media Resource Brokering November 2007 +-------<----------+----<-------+---+ | | (1) | | | | | | | +---+--+--+---+ | | | | Media | | | | +------>| Server | | | | |(3) +-------------+ | | | | (1)| | +---+--+--+---+ | | +---+-----+---+ | | | Application | (2) +---+--V--+---+ (3) | Media | | | | Server |----->| MRB |----->| Server |->-+ | +-------------+ +---+-----+---+ +-------------+ | | | | (3) +---+-----+---+ (1)| +------>| Media | | | Server |--->---+ +---+-----+---+ Figure 8: In-line MRB The Media Servers still use the 'Media Server Publishing Interface' to convey capabilities and resources to the MRB - as illustrated by (1). The media server Control and Media dialogs are blindly sent to the MRB (2) which then selects an appropriate Media Server (3). The result of such an architecture is that the decision is left entirely to the MRB and the Application Server has no input into the selection process. This is the opposite to the "Query" model which provided information that would help influence the Media Server decision making process on the application server. As a by-product of this decision shift, a lot more emphasis is placed on the intelligence of the MRB. It will actually have to inspect both the SIP signalling and the media server control protocol PDUs for the purpose of Media Server selection. This includes, for example, looking for explicit capabilities in the signalling and session details such as media types, codecs and bandwidth requirements. Ultimately the decision making and policy enforcement is removed from the Application Server and shifted to the MRB logical entity. Boulton & Even Expires May 22, 2008 [Page 11] Internet-Draft Media Resource Brokering November 2007 5. Interface Discussion As discussed in previous sections in this document, the intention is to provide a toolkit for a variety of architectures where media resource brokering can take place. As a result, two main interfaces are required to support the differing requirements. The two interfaces are described in the remainder of this section and have been named the 'Media Server Resource Publishing' and Media Server Resource Consumer' interfaces. These two interfaces have extremely differing responsibilities and usages which is reflected in the choice of solutions. It is beyond the scope of this document to define exactly how to construct an MRB. This includes interpreting the data for the Media Service Consumer interface supplied by the Media Serer Publishing interface. It is, however, important that the two interfaces are complimentary so that development of appropriate MRB functionality is supported. 5.1. Media Server Resource Publishing Interface The Media Server Resource Publishing interface is responsible for providing an MRB with appropriate Media Server resource information. It is generally accepted that this interface provides both general and specific details related to Media Server resources. This information needs to be conveyed using an industry standard mechanism to provide increased levels of adoption and interoperability. The Simple Network Management Protocol (SNMP) will provide the basis for the interface. An overview of the documents of the Internet-Standard Management Framework is provided in section 7 of RFC 3410 [RFC3410]. This interface will provide Management Information Base (MIB) objects that are accessed through the Simple Network Management Protocol (SNMP). Objects contained within the Media Server publishing interface are defined using Structure of Management Information (SMI). The Media Server publishing MIB will be compliant to SMIv2, which is defined in RFC 2578 [RFC2578], RFC 2579 [RFC2579] and RFC 2580 [RFC2578]. EDITORS NOTE: Need to map resources to MIB and define appropriately. 5.2. Media Service Resource Consumer Interface The Media Server Consumer interface provides the ability for clients of an MRB, such as Application Servers, to request an appropriate Media Server to satisfy specific criteria. The interface allows a client to pass detailed meta-information to the MRB to help select an appropriate Media Server. The MRB is then able to make and informed Boulton & Even Expires May 22, 2008 [Page 12] Internet-Draft Media Resource Brokering November 2007 decision and provide the client with an appropriate media server resource. The interface is therefore based on a client-server Remote Procedure Call mechanism, with the Simple Object Access Protocol (SOAP) [W3C.REC-soap12-part1-20030624] [W3C.REC-soap12-part2-20030624] used to carry out the interactions. The data structures will be defined using the Web Services Description Language (WSDL) [W3C.CR-wsdl20-20051215] definition and XML schema. EDITORS NOTE: Need to map appropriate RPC to WSDL and define appropriately. Boulton & Even Expires May 22, 2008 [Page 13] Internet-Draft Media Resource Brokering November 2007 6. Acknowledgments The authors would like to thank Boulton & Even Expires May 22, 2008 [Page 14] Internet-Draft Media Resource Brokering November 2007 7. Security Considerations Security Considerations to be included in later versions of this document. Boulton & Even Expires May 22, 2008 [Page 15] Internet-Draft Media Resource Brokering November 2007 8. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [W3C.CR-wsdl20-20051215] Chinnici, R., Moreau, J., Ryman, A., and S. Weerawarana, "Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language", W3C CR CR-wsdl20-20051215, December 2005. [W3C.REC-soap12-part1-20030624] Gudgin, M., Moreau, J., Mendelsohn, N., Hadley, M., and H. Nielsen, "SOAP Version 1.2 Part 1: Messaging Framework", World Wide Web Consortium FirstEdition REC-soap12-part1- 20030624, June 2003, . [W3C.REC-soap12-part2-20030624] Mendelsohn, N., Gudgin, M., Hadley, M., Nielsen, H., and J. Moreau, "SOAP Version 1.2 Part 2: Adjuncts", World Wide Web Consortium FirstEdition REC-soap12-part2-20030624, June 2003, . Boulton & Even Expires May 22, 2008 [Page 16] Internet-Draft Media Resource Brokering November 2007 Authors' Addresses Chris Boulton Avaya Building 3 Wern Fawr Lane St Mellons Cardiff, South Wales CF3 5EA Email: cboulton@avaya.com Roni Even Polycom 94 Derech Em Hamoshavot Petach Tikva 49130, Israel Email: roni.even@polycom.co.il Boulton & Even Expires May 22, 2008 [Page 17] Internet-Draft Media Resource Brokering November 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Boulton & Even Expires May 22, 2008 [Page 18]