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: <transport-spec> [, <transport-spec>].
Each <transport-spec> 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 <transport-spec> 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: <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.
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]