Network Working Group C. Bergren Internet-Draft J-F. Mule, Ed. Intended status: Informational CableLabs Expires: August 21, 2008 February 18, 2008 Extensions to RTSP based on the CableLabs Edge Resource Management Interface Specification (ERMI) draft-bergren-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 August 21, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Bergren & Mule, Ed. Expires August 21, 2008 [Page 1]
Internet-Draft mmusic-rtsp-ermi-extensions February 2008 Abstract This document provides a description of the RTSP extensions used in the CableLabs Edge Resource Manager Interface specification. It is provided as an informational note based on a recent liaison statement received by CableLabs from the IETF MMUSIC working group. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. ERMI extensions to RTSP . . . . . . . . . . . . . . . . . . . 6 2.1. List of ERMI extensions . . . . . . . . . . . . . . . . . 6 2.2. Limited Applicability of RTSP ERMI extensions . . . . . . 7 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 7. Informative References . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Bergren & Mule, Ed. Expires August 21, 2008 [Page 2]
Internet-Draft mmusic-rtsp-ermi-extensions February 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 including the Edge Resource Manager Interface Specification [ERMI]. A block diagram of the architecture relevant to the ERMI specification and its use of the RTSP protocol is shown on Figure 1. DOCSIS 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 section 5.2.3. of 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. Bergren & Mule, Ed. Expires August 21, 2008 [Page 3]
Internet-Draft mmusic-rtsp-ermi-extensions February 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, PING 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 has been added as part of the ERMI specification. The authors note that the OPTIONS method could have been used to act as a PING mechanism as it is the case with some SIP implementations. Bergren & Mule, Ed. Expires August 21, 2008 [Page 4]
Internet-Draft mmusic-rtsp-ermi-extensions February 2008 PING rtsp://172.22.10.3 RTSP/1.0 CSeq: 123 Session: 1234567 Require: ermi A corresponding response from the RTSP server to the client: RTSP/1.0 200 OK CSeq: 123 Session: 1234567 The ERMI specification makes extensions to RTSP [RFC2326] to add EQAM-specific parameters; the applicability of ERMI messages is within the internal system architecture of a DOCSIS M-CMTS system and within a DOCSIS cable network. These extensions are briefly discussed Section 2.1. Bergren & Mule, Ed. Expires August 21, 2008 [Page 5]
Internet-Draft mmusic-rtsp-ermi-extensions February 2008 2. ERMI extensions to RTSP 2.1. List of ERMI extensions Section 7.1.5 "RTSP Extensions" of the [ERMI] specification outlines the relevant extensions. These extensions are briefly summarized here; the specification should be examined directly for more details. The following extensions to RTSP have been used in ERMI: 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: <channel> [, <channel>]. Each <channel> field 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. 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: <notice-code> 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. 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). 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 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. Bergren & Mule, Ed. Expires August 21, 2008 [Page 6]
Internet-Draft mmusic-rtsp-ermi-extensions February 2008 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 the 'ermi' option tag. Section 12.32 of [RFC2326] requires a non-ERMI server to reject this ERMI option tag header as Unsupported. Bergren & Mule, Ed. Expires August 21, 2008 [Page 7]
Internet-Draft mmusic-rtsp-ermi-extensions February 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. Bergren & Mule, Ed. Expires August 21, 2008 [Page 8]
Internet-Draft mmusic-rtsp-ermi-extensions February 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 (PING Method, Transport header, etc.) are supported. Depending on the feedback from the IETF MMUSIC working group, this section should properly register the extensions that are deemed necessary. For example, a new option tag should be defined as described in section 3.8.1 of [RFC2326]: o Name and description of option: The name of this new option is 'ermi' (or may be com.cablelabs.ermi). 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] Bergren & Mule, Ed. Expires August 21, 2008 [Page 9]
Internet-Draft mmusic-rtsp-ermi-extensions February 2008 5. Security Considerations This section is left for further study. Bergren & Mule, Ed. Expires August 21, 2008 [Page 10]
Internet-Draft mmusic-rtsp-ermi-extensions February 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 as the main contributors: Charles Bergren and 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. And finally many thanks go out to all the active cable operator participants, members of the CableLabs who contributed to the ERMI specification. Bergren & Mule, Ed. Expires August 21, 2008 [Page 11]
Internet-Draft mmusic-rtsp-ermi-extensions February 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. Bergren & Mule, Ed. Expires August 21, 2008 [Page 12]
Internet-Draft mmusic-rtsp-ermi-extensions February 2008 Authors' Addresses Charles Bergren CableLabs 858 Coal Creek Circle Louisville, CO 80027 USA Email: c.bergren@cablelabs.com Jean-Francois Mule CableLabs 858 Coal Creek Circle Louisville, CO 80027 USA Email: jfm@cablelabs.com Bergren & Mule, Ed. Expires August 21, 2008 [Page 13]
Internet-Draft mmusic-rtsp-ermi-extensions February 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Bergren & Mule, Ed. Expires August 21, 2008 [Page 14]