tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6917

Proposed STD
Pages: 136
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: MEDIACTRL

Media Resource Brokering

Part 1 of 6, p. 1 to 12
None       Next RFC Part

 


Top       ToC       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.

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       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       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       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       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       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       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       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       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       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       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 RFC Part