idnits 2.17.1 draft-boulton-mediactrl-mrb-location-function-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (January 27, 2014) is 3735 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Boulton 3 Internet-Draft J. Dally 4 Intended status: Informational NS-Technologies 5 Expires: July 31, 2014 January 27, 2014 7 Media Resource Broker (MRB) Location Function (MLF) 8 draft-boulton-mediactrl-mrb-location-function-06 10 Abstract 12 The MediaCtrl work group in the IETF has produced a complete 13 architecture for controlling media server resources in Internet 14 Protocol (IP) based networks. An important function in the MediaCtrl 15 architecture is the Media Resource Broker entity which monitors and 16 allocates media resources to requesting applications. This document 17 introduces a Media Resource Broker (MRB) Location Function (MLF) 18 which works in partnership with MRB's in large deployments providing 19 a light weight scaling and failover mechanism. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on July 31, 2014. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 57 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5 58 3.1. MLF using HTTP . . . . . . . . . . . . . . . . . . . . . 7 59 3.2. MLF using SIP . . . . . . . . . . . . . . . . . . . . . . 8 60 4. MLF Interface Definitions . . . . . . . . . . . . . . . . . . 8 61 5. Media Service Resource Publisher Interface XML Schema . . . . 8 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 64 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 67 9.2. Informative References . . . . . . . . . . . . . . . . . 10 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 70 1. Introduction 72 As Internet Protocol(IP) networks continue to grow and IP based media 73 servers increase in numbers, the complexity associated increases. 74 This includes important areas such as provisioning, media resource 75 allocation, media resource management and media resource scalability. 76 The MediaCtrl Media Resource Broker (MRB) [I-D.ietf-mediactrl-mrb] 77 was introduced to provide virtualisation of IP media resources. The 78 MRB moves deployments away from the current siloed deployment model 79 where media servers are explicitly associated and utilized by 80 specified applications. Figure 1 illustrates the common model used 81 by many deployments today. 83 +---+-----+---+ 84 | Media | 85 +----->| Server | 86 | +-------------+ 87 | 88 +---+-----+---+ | +---+-----+---+ 89 | Application | | | Media | 90 | Server |<--MS Control-----+----->| Server | 91 +-------------+ | +-------------+ 92 | 93 | +---+-----+---+ 94 +----->| Media | 95 | Server | 96 +-------------+ 98 Figure 1: Silo Deployment 100 The MRB is introduced to break this siloed approach allowing media 101 resources to be provisioned, managed and utilized in a virtualized 102 manner. This allows for greater productivity from a virtualized pool 103 of media resources and also introduces application level intelligence 104 and consolidation for managing media resources. Figure 2 illustrates 105 the introduction of an MRB entity. 107 +---+-----+---+ +---+-----+---+ 108 | Application | | Media | 109 | Server |<-----+ +------>| Server | 110 +-------------+ | | +-------------+ 111 | | 112 +---+-----+---+ | +---+----+---+ | +---+-----+---+ 113 | Application | | | MRB | | | Media | 114 | Server |<-----+----| |----+------>| Server | 115 +-------------+ | +---+----+---+ | +-------------+ 116 | | 117 +---+-----+---+ | | +---+-----+---+ 118 | Application | | +------>| Media | 119 | Server |<-----+ | Server | 120 +-------------+ +---+-----+---+ 122 Figure 2: MRB Deployment 124 Large networks that require segmented deployment and/or span 125 geographic boundaries may require multiple MRB instances. In such 126 deployments, applications will require an efficient, light weight, 127 centralised directory look-up service that enables client 128 applications to obtain the most relevant MRB for its media resource 129 request. The MRB Location Function (MLF) defined in this 130 specification provides such a service, as illustrated in Figure 3. 132 +--------------+ 133 | | 134 +---+-----+---+ +---+----+---+ +---+-----+---+ | 135 | Application | (2) | MRB | | Media |--+ 136 | Server |<-------->| (London) |<--------->| Server | 137 +------+------+ +---+----+---+ +-------------+ 138 | 139 | (1) +--------------+ 140 v | | 141 +---+-----+---+ +---+-----+--+ +-------------+ | 142 | MLF | | MRB | | Media |--+ 143 | | | (New York) |<--------->| Server | 144 +-------------+ +---+-----+--+ +-------------+ 146 Figure 3: MLF Deployment 148 Figure 3 provides a simplistic representation of an application 149 firstly requesting media resources from an MLF, as illustrated by 150 (1). The MLF makes a decision based on the information provided by 151 the application and returns the most appropriate MRB for use. The 152 application then continues as per [I-D.ietf-mediactrl-mrb] and 153 utilizes the selected MRB. 155 It should be noted that the MLF entity defined in this specification 156 is a logical role. The role can either be carried out by a 157 standalone instance of an MLF or an MRB acting in the logical role of 158 an MLF. This specification makes no recommendations or judgements on 159 how an MLF is deployed and simply provides the mechanisms to achieve 160 the functionality. 162 2. Conventions and Terminology 164 In this document, BCP 14/RFC 2119 [RFC2119] defines the key words 165 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 166 "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 167 "OPTIONAL". In addition, BCP 15 indicates requirement levels for 168 compliant implementations. 170 This document inherits terminology proposed in the MediaCtrl 171 Architecture [I-D.ietf-mediactrl-architecture] and the Media Control 172 Channel Framework [I-D.ietf-mediactrl-sip-control-framework]. In 173 addition, the following terms are defined for use in this document 174 and for use in the context of the MediaCtrl Work group in the IETF: 176 MLF: An MRB Location Function. The light weight MRB directory 177 service as defined in this document. 179 3. Overview of Operation 181 The MRB lookup provided by the MLF needs to be extremely light weight 182 and performant. This section provides normative detail on using the 183 MLF. 185 An application will be configured to use the MLF to ask for an 186 appropriate MRB instance that is available in the network. The 187 specific configuration mechanism is out of the scope of this document 188 and is implementation specific. A client of the MLF MUST then 189 produce a valid Consumer interface XML document as specified in 190 [I-D.ietf-mediactrl-mrb] as if it were requesting resources from an 191 MRB. Additionally, the application MUST include a single instance of 192 the element as defined in Section 5. Details of the 193 element can be found in Section 4. The element is included in 194 the resource request XML to enable an MLF entity to identify a 195 request for an appropriate MRB. 197 A valid MLF request MUST contain a single instance of the 198 element. The element MUST appear as a child element of the 199 element from the Consumer interface defined in 200 [I-D.ietf-mediactrl-mrb]. The element appears with the other 201 appropriately populated elements and attributes from the Consumer 202 interface defined in [I-D.ietf-mediactrl-mrb]. The element 203 MUST NOT contain the child element and if present will 204 be ignored. The following is an example: 206 207 208 209 210 211 msc-ivr/1.0 212 msc-mixer/1.0 213 214 215 216 217 218 10 219 10 220 221 222 223 224 225 226 227 228 229 230 232 Once the previous steps have been carried out the request can be 233 dispatched to the MLF using the mechanisms described in 234 [I-D.ietf-mediactrl-mrb] using either Hypertext Transfer 235 Protocol(HTTP)[RFC2616] or the Session Initiation Protocol 236 (SIP)[RFC3261]. Using HTTP is described further in Section 3.1 and 237 using SIP is described further in Section 3.2. 239 On receiving a valid request from an application, as previously 240 defined, the MLF inspects the XML payload. The presence of the 241 element indicates to the MLF an appropriate MRB resource is being 242 requested. This enables an entity to clearly determine between an 243 MRB request and an an MLF request. The MLF is free to use the 244 Consumer interface information provided to help select an appropriate 245 MRB. The MLF MUST then produce a valid Consumer interface XML 246 document as specified in [I-D.ietf-mediactrl-mrb] as if it were 247 responding to a Consumer interface request. Additionally, the 248 application MUST include a single instance of the element as 249 defined in Section 5. Details of the element can be found in 250 Section 4. The element is included in the resource request XML 251 to enable an MLF entity to specify appropriate MRB locations. 253 [Editors Note: Need to cope with error condition if MLF receives 254 request without element.] 256 A valid MLF response MUST contain a single instance of the 257 element. The element MUST appear as a child element of the 258 element from the Consumer interface defined 259 in [I-D.ietf-mediactrl-mrb]. Only the element is allowed to 260 appear and no other child elements from the Consumer interface should 261 be present. The element MUST contain at least one occurrence 262 of the the child element which indicates the MRB 263 resource to use. The 'status' attribute will 264 return a value of 200 to signal a successful MLF request. The 265 following is an example: 267 268 269 270 sip:mrb1@ns-technologies.com 271 272 273 275 [Editors Note: Include other values for the 'status' attribute - for 276 example, no matching MRB found.] 278 Once the previous steps have been carried out the response can be 279 dispatched from the MLF using the mechanisms described in 280 [I-D.ietf-mediactrl-mrb] using either Hypertext Transfer 281 Protocol(HTTP)[RFC2616] or the Session Initiation Protocol 282 (SIP)[RFC3261]. Using HTTP is described further in Section 3.1 and 283 using SIP is described further in Section 3.2. 285 The client application is then free to contact an MRB returned from 286 the MLF request. 288 [Editors Note: Consider including an optional priority attribute in 289 next version.] 291 3.1. MLF using HTTP 293 [Editors Note: Consider including HTTP probe for MLF support in next 294 version.] 296 Consumer interface interactions using HTTP between an application and 297 an MLF, as defined in Section 3, MUST use the HTTP protocol as per 298 [I-D.ietf-mediactrl-mrb]. 300 3.2. MLF using SIP 302 [Editors Note: Consider including SIP Options probe for MLF support 303 in next version.] 305 Consumer interface requests using SIP between an application and an 306 MLF, as defined in Section 3, MUST use the SIP protocol as per 307 [I-D.ietf-mediactrl-mrb]. Consumer interface responses using SIP 308 between an MLF and an application, as defined in Section 3, MUST use 309 a SIP 300 redirect response to carry the MLF response. 311 4. MLF Interface Definitions 313 This section defines the XML elements for interactions between an 314 application and an MLF. The formal schema definition for the 315 interactions can be found in Section 5. 317 The root element is . All other MLF related information is 318 contained within it. The element has a single child element - 319 . The element appears at least once and 320 provides the URI of an MRB that can be used to service a media 321 resource request. 323 5. Media Service Resource Publisher Interface XML Schema 325 This section gives the XML Schema Definition [W3C.REC- 326 xmlschema-1-20041028], [W3C.REC-xmlschema-2-20041028] of the 327 "application/mlf+xml" format. 329 330 335 336 337 MLF 339 This is the schema for MLF usage. 341 The schema namespace is urn:ietf:params:xml:ns:mlf 343 344 345 353 355 356 357 This import brings in the XML attributes for 358 xml:base, xml:lang, etc 359 360 361 363 371 372 373 374 376 378 379 380 381 383 385 387 389 391 6. Security Considerations 393 Security Considerations to be included in later versions of this 394 document. 396 7. IANA Considerations 398 IANA Considerations to be included in later versions of this document 399 if required. 401 8. Acknowledgments 403 The authors would like to thank Rhys Morgan of NS-Technologies for 404 review and feedback on this draft. 406 9. References 408 9.1. Normative References 410 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 411 Requirement Levels", BCP 14, RFC 2119, March 1997. 413 9.2. Informative References 415 [I-D.ietf-mediactrl-architecture] 416 Melanchuk, T., "An Architectural Framework for Media 417 Server Control", draft-ietf-mediactrl-architecture-04 418 (work in progress), November 2008. 420 [I-D.ietf-mediactrl-mrb] 421 Boulton, C., Miniero, L., and G. Munson, "Media Resource 422 Brokering", draft-ietf-mediactrl-mrb-19 (work in 423 progress), February 2013. 425 [I-D.ietf-mediactrl-sip-control-framework] 426 Boulton, C., Melanchuk, T., and S. McGlashan, "Media 427 Control Channel Framework", draft-ietf-mediactrl-sip- 428 control-framework-12 (work in progress), September 2010. 430 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 431 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 432 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 434 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 435 A., Peterson, J., Sparks, R., Handley, M., and E. 436 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 437 June 2002. 439 Authors' Addresses 441 Chris Boulton 442 NS-Technologies 444 Email: chris@ns-technologies.com 446 John Dally 447 NS-Technologies 449 Email: john@ns-technologies.com