Tech-invite3GPPspaceIETF RFCsSIP
9190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6917

Media Resource Brokering

Pages: 136
Proposed Standard
Part 1 of 6 – Pages 1 to 12
None   None   Next

Top   ToC   RFC6917 - Page 1
Internet Engineering Task Force (IETF)                        C. Boulton
Request for Comments: 6917                               NS-Technologies
Category: Standards Track                                     L. Miniero
ISSN: 2070-1721                                                 Meetecho
                                                               G. Munson
                                                                    AT&T
                                                              April 2013


                        Media Resource Brokering

Abstract

The MediaCtrl working group in the IETF has proposed an architecture for controlling media services. The Session Initiation Protocol (SIP) is used as the signaling protocol that provides many inherent capabilities for message routing. In addition to such signaling properties, a need exists for intelligent, application-level media service selection based on non-static signaling properties. This is especially true when considered in conjunction with deployment architectures that include 1:M and M:N combinations of Application Servers and Media Servers. This document introduces a Media Resource Broker (MRB) entity, which manages the availability of Media Servers and the media resource demands of Application Servers. The document includes potential deployment options for an MRB and appropriate interfaces to Application Servers and Media Servers. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6917.
Top   ToC   RFC6917 - Page 2
Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

1. Introduction ....................................................3 2. Conventions and Terminology .....................................6 3. Problem Discussion ..............................................6 4. Deployment Scenario Options .....................................7 4.1. Query MRB ..................................................8 4.1.1. Hybrid Query MRB ....................................9 4.2. In-Line MRB ...............................................11 5. MRB Interface Definitions ......................................12 5.1. Media Server Resource Publish Interface ...................12 5.1.1. Control Package Definition .........................13 5.1.2. Element Definitions ................................15 5.1.3. <mrbrequest> .......................................15 5.1.4. <mrbresponse> ......................................17 5.1.5. <mrbnotification> ..................................19 5.2. Media Service Resource Consumer Interface .................30 5.2.1. Query Mode/HTTP Consumer Interface Usage ...........31 5.2.2. In-Line Aware Mode/SIP Consumer Interface Usage ....32 5.2.3. Consumer Interface Lease Mechanism .................35 5.2.4. <mrbconsumer> ......................................38 5.2.5. Media Service Resource Request .....................39 5.2.6. Media Service Resource Response ....................51 5.3. In-Line Unaware MRB Interface .............................54 6. MRB Acting as a B2BUA ..........................................54 7. Multimodal MRB Implementations .................................55 8. Relative Merits of Query Mode, IAMM, and IUMM ..................56 9. Examples .......................................................58 9.1. Publish Example ...........................................58 9.2. Consumer Examples .........................................64 9.2.1. Query Example ......................................64 9.2.2. IAMM Examples ......................................68 10. Media Service Resource Publisher Interface XML Schema .........83
Top   ToC   RFC6917 - Page 3
   11. Media Service Resource Consumer Interface XML Schema .........106
   12. Security Considerations ......................................127
   13. IANA Considerations ..........................................130
      13.1. Media Control Channel Framework Package Registration ....130
      13.2. application/mrb-publish+xml Media Type ..................130
      13.3. application/mrb-consumer+xml Media Type .................131
      13.4. URN Sub-Namespace Registration for mrb-publish ..........132
      13.5. URN Sub-Namespace Registration for mrb-consumer .........132
      13.6. XML Schema Registration for mrb-publish .................132
      13.7. XML Schema Registration for mrb-consumer ................133
   14. Acknowledgements .............................................133
   15. References ...................................................133
      15.1. Normative References ....................................133
      15.2. Informative References ..................................135

1. Introduction

As IP-based multimedia 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 working 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 one introduces a flexible level of deployment scenarios, as specified in RFC 5167 [RFC5167] and RFC 5567 [RFC5567]. These documents make statements like "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, to provide what can be effectively described as media resource brokering. 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 control multiple (greater than 1) Media Server instances at any one time. 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
Top   ToC   RFC6917 - Page 4
   that each Media Server possesses a different media capability set.
   Media Servers may offer different media services as specified in the
   MediaCtrl architecture document [RFC5567].  A Media Server may have
   similar media functionality but may have different capacity or media
   codec support.

                                           +---+-----+---+
                                           |    Media    |
                                    +----->|    Server   |
                                    |      +-------------+
                                    |
   +---+-----+---+                  |      +---+-----+---+
   | Application |                  |      |    Media    |
   |   Server    |<--MS Control-----+----->|    Server   |
   +-------------+                  |      +-------------+
                                    |
                                    |      +---+-----+---+
                                    +----->|    Media    |
                                           |    Server   |
                                           +-------------+

                     Figure 2: Multiple Media Servers

   Figure 3 conveys the opposite view to that in Figure 2.  In this
   model, there are a number of (greater than 1) Application Servers,
   possibly supporting dissimilar applications, 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: Multiple Application Servers
Top   ToC   RFC6917 - Page 5
   The final deployment view is the most complex (Figure 4).  In this
   model (M:N), there exist any number of Application Servers and any
   number of Media Servers.  It is again possible in this model that
   Media Servers might not be homogeneous, and they might have different
   capability sets and capacities.

   +---+-----+---+                         +---+-----+---+
   | Application |                         |    Media    |
   |   Server    |<-----+            +---->|    Server   |
   +-------------+      |            |     +-------------+
                        |            |
   +---+-----+---+      |            |     +---+-----+---+
   | Application |      |            |     |    Media    |
   |   Server    |<-----+-MS Control-+---->|    Server   |
   +-------------+      |            |     +-------------+
                        |            |
   +---+-----+---+      |            |     +---+-----+---+
   | Application |      |            +---->|    Media    |
   |   Server    |<-----+                  |    Server   |
   +-------------+                         +---+-----+---+

                    Figure 4: Many-to-Many Architecture

   The remaining sections in this specification will focus on a new
   entity called a Media Resource Broker (MRB), which can be utilized in
   the deployment architectures described previously in this section.
   The MRB entity provides the ability to obtain media resource
   information and appropriately allocate (broker) on behalf of client
   applications.

   The high-level deployment options discussed in this section rely on
   network architecture and policy to prohibit inappropriate use.  Such
   policies are out of scope for this document.

   This document will take a look at the specific problem areas related
   to such deployment architectures.  It is recognized that the
   solutions proposed in this document should be equally adaptable to
   all of the previously described deployment models.  It is also
   recognized that the solution is far more relevant to some of the
   previously discussed deployment models and can almost be viewed as
   redundant on others.
Top   ToC   RFC6917 - Page 6

2. Conventions and Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. This document inherits terminology proposed in RFC 5567 [RFC5567] and in "Media Control Channel Framework" [RFC6230]. In addition, the following terms are defined for use in this document and for use in the context of the MediaCtrl working 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 selecting appropriate Media Server resources on behalf of consuming entities. Query MRB: An instantiation of an MRB (see previous definition) that provides an interface for an Application Server to retrieve the address 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 previous definition) that directly receives requests on the signaling path. There is no separate query. CFW: Media Control Channel Framework, as specified in [RFC6230]. Within the context of In-line MRBs, additional terms are defined: In-line Aware MRB Mode (IAMM): Defined in Section 5.2.2.1. In-line Unaware MRB Mode (IUMM): Defined in Section 5.3. The document will often specify when a specific identifier in a protocol message needs to be unique. Unless stated otherwise, such uniqueness will always be within the scope of the Media Servers controlled by the same MRB. The interaction between different MRB instances, e.g., the partitioning of a logical MRB, is out of scope for this document.

3. Problem Discussion

As discussed in Section 1, a goal of the MediaCtrl working group is to produce a solution that will service a wide variety of deployment architectures. Such architectures range from the simplest 1:1 relationship between Media Servers and Application Servers to potentially linearly scaling 1:M, M:1, and M:N deployments.
Top   ToC   RFC6917 - Page 7
   Managing such deployments is itself non-trivial for the proposed
   solution until an additional number of factors that increase
   complexity are included in the equation.  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 a common, 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 with available resources for
   servicing a request.

   In conclusion, the intention is to create a toolkit 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
   availability can be handled using the appropriate underlying
   signaling, e.g., SIP response.  This document does not prohibit such
   uses of an MRB; it simply provides the tools for various entities to
   interact where appropriate.  It is also worth noting that the
   functions specified in this document aim to provide a 'best effort'
   view of media resources at the time of request for initial Media
   Server routing decisions.  Any dramatic change in media capabilities
   or capacity after a request has taken place should be handled by the
   underlying protocol.

   It should be noted that there may be additional information that is
   desirable for the MRB to have for purposes of selecting a Media
   Server resource, such as resource allocation rules across different
   applications, planned or unplanned downtime of Media Server
   resources, the planned addition of future Media Server resources, or
   Media Server resource capacity models.  How the MRB acquires such
   information is outside the scope of this document.  The specific
   techniques used for selecting an appropriate media resource by an MRB
   is also outside the scope of this document.

4. Deployment Scenario Options

Research into media resource brokering concluded that a couple of high-level models provided an appropriate level of flexibility. The general principles of "in-line" and "query" MRB concepts are discussed in the rest of this section. It should be noted that while the interfaces are different, they both use common underlying mechanisms defined in this specification.
Top   ToC   RFC6917 - Page 8

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 Publish 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 increased accuracy in its response. This particular interface is discussed in "Media Service Resource Consumer Interface" (Section 5.2). The Application Server is then able to direct control commands (for example, create a conference) and media dialogs to the appropriate Media Server, as shown by (3) in Figure 5. Additionally, with Query mode, the MRB is not directly in the signaling path between the Application Server and the selected Media Server resource.
Top   ToC   RFC6917 - Page 9

4.1.1. Hybrid Query MRB

As mentioned previously, it is the intention that a toolkit 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 - Application Server 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 Publish 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.
Top   ToC   RFC6917 - Page 10
   In a similar manner, the Media Server could also act as a hybrid for
   the deployment cluster, as illustrated in Figure 7.

                                   (1)                 +---+-----+---+
   +---+---+------------->---------------->----------->|     MRB     |
   |   |   |   +---+--+--+---+                         +---+-----+---+
   |   |   +-<-| Application |                         |    Media    |
   |   |       |   Server    |<--+-MS Control-+------->|    Server   |
   |   |       +-------------+                   |     +-------------+
   |   |                                         |
   |   |       +---+--+--+---+                   |
   |   +---<---| Application |                   |
   |           |   Server    |<--+-MS Control-+--+
   |           +-------------+                   |
   |                                             |
   |           +---+--+--+---+                   |
   +---<-------| Application |                   |
               |   Server    |<--+-MS Control-+--+
               +-------------+

                  Figure 7: Hybrid Query MRB - MS Hosted

   In this example, 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.  The
   Media Server Publish 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 Publish interface could then be offered from the hybrid if
   required.  A typical use case scenario for such a topology would be a
   single Media Server representing a pool of MSs in a cluster.  In this
   case, the MRB would actually be handling a cluster of Media Servers,
   rather than one.
Top   ToC   RFC6917 - Page 11

4.2. In-Line MRB

The "In-line" MRB is architecturally different from the "Query" model discussed in the previous section. The concept of a separate query disappears. The client of the MRB simply uses the media resource control and media dialog signaling to involve the MRB. This type of deployment is illustrated in Figure 8. +-------<----------+----<-------+---+ | | (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 Publish interface to convey capabilities and resources to the MRB, as illustrated by (1). The Media Server Control Channels (and media dialogs as well, if required) are sent to the MRB (2), which then selects an appropriate Media Server (3) and remains in the signaling path between the Application Server and the Media Server resources. The In-line MRB can be split into two distinct logical roles that can be applied on a per-request basis. They are: In-line Unaware MRB Mode (IUMM): Allows an MRB to act on behalf of clients requiring media services who are not aware of an MRB or its operation. In this case, the Application Server does not provide explicit information on the kind of Media Server resource it needs (as in Section 5.2), and the MRB is left to deduce it by potentially inspecting other information in the request from the Application Server (for example, Session Description Protocol (SDP) content, or address of the requesting Application Server, or additional Request-URI parameters as per RFC 4240 [RFC4240]).
Top   ToC   RFC6917 - Page 12
   In-line Aware MRB Mode (IAMM):  Allows an MRB to act on behalf of
      clients requiring media services who are aware of an MRB and its
      operation.  In particular, it allows the Application Server to
      explicitly convey matching characteristics to those provided by
      Media Servers, as does the Query MRB mode (as in Section 5.2).

   In either of the previously described roles, signaling as specified
   by the Media Control Channel Framework ([RFC6230]) would be involved,
   and the MRB would deduce that the selected Media Server resources are
   no longer needed when the Application Server or Media Server
   terminates the corresponding SIP dialog.  The two modes are discussed
   in more detail in Section 5.3.



(page 12 continued on part 2)

Next Section