MMUSIC Working Group J-F. Mule Internet-Draft G. White Intended status: Informational CableLabs Expires: April 30, 2009 October 27, 2008 Extensions to RTSP for the CableLabs Edge Resource Management Interface Specification (ERMI) draft-mule-mmusic-rtsp-ermi-extensions-00 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 April 30, 2009. Mule & White Expires April 30, 2009 [Page 1] Internet-Draft mmusic-rtsp-ermi-extensions October 2008 Abstract This document provides a description of the RTSP extensions used in the second version of the CableLabs Edge Resource Manager Interface specification. It is provided to seek comments from the IETF with the intent of following the IETF procedures for protocol extensions and variations. It is a work-in-progress document and future revisions will contain IANA registrations. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. ERMI extensions to RTSP . . . . . . . . . . . . . . . . . . . 5 2.1. List of ERMI extensions . . . . . . . . . . . . . . . . . 5 2.2. Limited Applicability of RTSP ERMI extensions . . . . . . 6 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 7. Informative References . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 13 Mule & White Expires April 30, 2009 [Page 2] Internet-Draft mmusic-rtsp-ermi-extensions October 2008 1. Introduction In 2004-2005, work was initiated on a Modular Cable Modem Termination System (M-CMTS) architecture at CableLabs. A number of specifications were published under the M-CMTS effort, including the Edge Resource Manager Interface Specification [ERMI]. The current version of [ERMI] is numbered I02, and it relies on RTSP for requesting and allocating resources internal to cable systems. An update to ERMI version 2 is planned in the near future that will incorporate some of the feedback already received from IETF and add new RTSP extensions; those new extensions will be integrated in future revisions of this document. A block diagram of the architecture relevant to the ERMI specification and its use of the RTSP protocol is shown on Figure 1. DOCSIS(tm) stands for Data-Over-Cable-Service-Interface Specifications. The cable head-end architecture centers on DOCSIS CMTS systems that send Video and Internet data to subscribers. An Edge QAM (EQAM) is a head-end or hub device that receives packets of digital video or data from the operator network. It re-packetizes the video or data into an MPEG transport stream and digitally modulates the transport stream onto a downstream RF carrier using Quadrature Amplitude Modulation (QAM). A CMTS requires resources (such as EQAMs) to relay this data to subscriber modems. These resources are allocated by an Edge Resource Manager (ERM). The CMTS and EQAMs use the Real-Time Streaming Protocol (RTSP, [RFC2326]), as defined in the CableLabs Edge Resource Manager Interface Specification ([ERMI]) during the resource allocation process. The CMTS asks the Edge Resource Manager for an EQAM, the ERM confers with the EQAMs, and then gives the CMTS the appropriate EQAM resource. It should be noted that the choice of RTSP as a protocol for edge resource management was done historically by product vendors and operators based on the basic needs to setup and tear down sessions for media that has similar realtime, multimedia properties as the typical media established using RTSP. Mule & White Expires April 30, 2009 [Page 3] Internet-Draft mmusic-rtsp-ermi-extensions October 2008 +------------+ +-------------------------+ | +------+ | |+------+ Edge Resource | | |RTSP <-+-->+RTSP | Manager | | |Client| | ||Server| +-----------+ | | +------+ | |+------+ |RTSP Client| | | | | +-------^---+ | | | +-------------------|-----+ | | | | | | | Modular | | | Cable | EQAMs | | Modem | +------------+ | | Termination| | +------------- | | System | | | +---------- | -+ | Core | | | | +---------|--------+ | | +-| | | +------v----+ | +-------+ | (M-CMTS | +--| | |RTSP Server| | | Cable | | Core) | +-| +-----------+ | | Modem | | | DATA | | | | ==|========================-+-=================+-|=======|==>> | | +------------------+ +-------+ | | +------------+ RTSP Usage in Edge Resource Manager Interface Specification Figure 1 The M-CMTS core, the ERM, and the EQAM use TCP as the transport-layer protocol and listen on TCP port 554 for incoming RTSP connections. The M-CMTS core acts as an RTSP client. The ERM plays the role of an RTSP client and an RTSP server. The EQAM acts as an RTSP server. The RTSP SETUP, TEARDOWN, SET_PARAMETER and GET_PARAMETER methods must at a minimum be supported by M-CMTS, ERM and EQAM. In addition, the M-CMTS core and the ERM must also support the ANNOUNCE method. A session keepalive method named PING was defined as part of the ERMI specification version I02. Its use has been deprecated and the keepalive mechanism now relies on the SET_PARAMETER method. The ERMI specification makes extensions to RTSP [RFC2326] to add EQAM-specific parameters. The applicability of these ERMI RTSP messages is within the internal system architecture of a DOCSIS M-CMTS system and within a DOCSIS cable network. This is done by enforcing RTSP clients to insert the RTSP Require header with a specific extension tag. The option tag and its associated extensions are briefly discussed in Section 2.1. Mule & White Expires April 30, 2009 [Page 4] Internet-Draft mmusic-rtsp-ermi-extensions October 2008 2. ERMI extensions to RTSP 2.1. List of ERMI extensions Section 7 of the [ERMI] specification outlines the relevant extensions. These extensions are briefly summarized here. It is recommended that the reader reviews the referenced CableLabs specification for more details. The following extensions to RTSP have been used in ERMI version I02: o New parameters for the Transport header: Section 12.39 of [RFC2326] specifies the Transport header. ERMI Extensions to the Transport header identify parameters associated with the transport of the media stream through an EQAM. Transport headers take the form of: Transport: [, ]. Each takes the form: DOCSIS/QAM; unicast. The bit rate, QAM ID and DEPI mode are passed as part of the transport header with additional optional values. In an upcoming revision of ERMI, the will be of the form: clab-DOCSIS/QAM and optional field values will be more precisely defined. o New DOCSIS-Notice header: The DOCSIS-Notice header header provides information sent from an RTSP server to a client in an ANNOUNCE request, specifically to reclaim an ERMI session. The syntax of the DOCSIS-Notice header is: DOCSIS-Notice: The RTSP client and server must support the values of notice- code and code-description defined in the ERMI specification. Currently, only the value of '5701' is define to reclaim a session. In an upcoming revision of ERMI, this header will be renamed clab-DOCSIS-Notice. o New RTSP option tag in the Require header: The Require: header must be present in RTSP requests methods, with the newly defined 'ermi' tag (see IANA consideration section). In an upcoming revision of ERMI, a new option tag is defined as 'com.cablelabs.ermi'. o New parameters for GET_PARAMETER method: The RTSP GET_PARAMETER method is used by the client to obtain the list of active RTSP sessions that were initiated by the Mule & White Expires April 30, 2009 [Page 5] Internet-Draft mmusic-rtsp-ermi-extensions October 2008 client before the current TCP connection was established. It is used by a client as a mechanism to synchronize its session state with the RTSP server following a client reboot. 2.2. Limited Applicability of RTSP ERMI extensions There are several considerations to the ERMI RTSP extensions. First, the ERMI specification is intended to be used within a single cable administrative domain, a 'closed' cable system head-end with controlled network and administrative domains. It is unlikely that the [ERMI] protocols will escape these domains as the ERMI traffic is considered as a service control and management. Secondly, the ERMI specification requires that RTSP requests include the Require Header with a specific option tag. Section 12.32 of [RFC2326] requires a non-ERMI server to reject this ERMI option tag header as Unsupported. Mule & White Expires April 30, 2009 [Page 6] Internet-Draft mmusic-rtsp-ermi-extensions October 2008 3. 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 [RFC2119]. This document also reuses the terminology defined in [ERMI] and it is recommended for the reader to read the ERMI specification. Mule & White Expires April 30, 2009 [Page 7] Internet-Draft mmusic-rtsp-ermi-extensions October 2008 4. IANA Considerations The CableLabs ERMI specification currently makes use of a new option tag indicating support for the ERMI RTSP requirements; this option tag means that the various extensions (Transport, clab-Notice-header header, etc.) are supported. As the RTSP usage in ERMI matures, this document will request IANA to register an option tag and associated header and field values. For example, a new option tag will be defined as described in section 3.8.1 of [RFC2326]: o Name and description of option: The name of this new option is 'com.cablelabs.ermi'. //todo: This text should explicitly define what is required to be supposed to claim compliance with this new option tag. o Change of control: CableLabs o Reference: [ERMI] Mule & White Expires April 30, 2009 [Page 8] Internet-Draft mmusic-rtsp-ermi-extensions October 2008 5. Security Considerations This section is left for further study. Mule & White Expires April 30, 2009 [Page 9] Internet-Draft mmusic-rtsp-ermi-extensions October 2008 6. Acknowledgments This IETF Internet-Draft document provides some high-level information and pointers to the RTSP extensions used in the CableLabs ERMI specification published by CableLabs as part of the Modular Cable Modem Termination System (M-CMTS) architecture. The following individuals are acknowledged in the CableLabs ERMI document version I02 as the main contributors: Charles Bergren, Eduardo Cardona of CableLabs, Doc Evans of ARRIS International, Inc., Xiaomei Liu of Cisco Systems, Inc., Michael Mercurio of Camiant, Mike Patrick of Motorola, Sangeeta Ramkrishnan of Cisco Systems, Inc., Dan Smith of BigBand Networks, and Bruce Thompson of Cisco Systems, Inc. In particular, Xiaomei Liu and Doc Evans contributed extensively by serving as lead authors for the ERMI specification. We thank Dan Smith, Mike Patrick and Michael Mercurio who provided valuable thoughts and text. We would also like to acknowledge Bruce Thompson and Sangeeta Ramkrishnan for their work on the initial text. We thank Charles Bergren and Eduardo Cardona, who were the ERMI team leads for revision I02. And finally many thanks go out to all the active cable operator participants, members of the CableLabs who contributed to the ERMI specification. Mule & White Expires April 30, 2009 [Page 10] Internet-Draft mmusic-rtsp-ermi-extensions October 2008 7. Informative References [ERMI] CableLabs, "Edge Resource Manager Interface Specification, CM-SP-ERMI-I02-051209", CableLabs Specification http:// www.cablelabs.com/specifications/ CM-SP-ERMI-I02-051209.pdf, February 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998. Mule & White Expires April 30, 2009 [Page 11] Internet-Draft mmusic-rtsp-ermi-extensions October 2008 Authors' Addresses Jean-Francois Mule CableLabs 858 Coal Creek Circle Louisville, CO 80027 USA Email: jf.mule@cablelabs.com Greg White CableLabs 858 Coal Creek Circle Louisville, CO 80027 USA Email: g.white@cablelabs.com Mule & White Expires April 30, 2009 [Page 12] Internet-Draft mmusic-rtsp-ermi-extensions October 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. Mule & White Expires April 30, 2009 [Page 13]