ETSI TS 103 161-5 V1.1.1 (2011-10)

Access, Terminals, Transmission and Multiplexing (ATTM); Integrated Broadband Cable and Television Networks; IPCablecom 1.5; Part 5: Dynamic Quality of Service for the Provision of Real Time Services over Cable Television Networks using Cable Modems

DTS/ATTM-003011-5

General Information

• Status: Published
• Publication Date: 26-Oct-2011
• Technical Committee: ATTM AT3 - Integrated broadband cable and television networks
• Current Stage: 12 - Completion
• Due Date: 31-Oct-2011
• Completion Date: 27-Oct-2011

Standards Content (Sample)

Technical Specification
Access, Terminals, Transmission and Multiplexing (ATTM);
Integrated Broadband Cable and Television Networks;
IPCablecom 1.5;
Part 5: Dynamic Quality of Service for the Provision of
Real Time Services over Cable Television Networks
using Cable Modems
2 ETSI TS 103 161-5 V1.1.1 (2011-10)

Reference
DTS/ATTM-003011-5
Keywords
access, broadband, cable, IP, multimedia, PSTN
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2011.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners. ®
GSM and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI TS 103 161-5 V1.1.1 (2011-10)
Contents
Intellectual Property Rights . 6
Foreword . 6
1 Scope . 8
2 References . 8
2.1 Normative references . 8
2.2 Informative references . 9
3 Definitions, symbols and abbreviations . 9
3.1 Definitions . 9
3.2 Abbreviations . 10
4 Void . 11
5 Technical Overview . 11
5.1 IPCablecom QoS Architecture Requirements . 12
5.2 IP QoS Access Network Elements . 14
5.2.1 Multimedia Terminal Adapter (MTA) . 14
5.2.2 Cable Modem (CM) . 14
5.2.3 Cable Modem Termination System (CMTS) . 14
5.2.4 Call Management Server (CMS) and Gate Controller (GC) . 14
5.2.5 Record Keeping Server (RKS). 14
5.3 IPCablecom Dynamic QoS Architecture . 15
5.4 QoS Interfaces . 15
5.5 Framework for IPCablecom QoS . 17
5.6 Requirements of Access Network Resource Management . 18
5.6.1 Preventing Theft of Service . 19
5.6.2 Two-phase Resource Commitment . 19
5.6.3 Segmented Resource Assignment . 19
5.6.4 Resource Changes during a Session. 20
5.6.5 Dynamic Binding of Resources . 20
5.6.6 Dynamic QoS Performance . 20
5.6.7 Session Class . 20
5.6.8 Intermediate Network Support . 20
5.6.9 Backbone QoS Support . 20
5.6.10 Handling Multiple Codecs . 21
5.6.11 V.152 Support . 21
5.6.12 MTA Port-to-Port Calls . 22
5.6.13 Multiple Grants per Interval. 22
5.7 Theory of Operation . 22
5.7.1 Basic Session Setup . 22
5.7.2 Gate Coordination . 23
5.7.3 Changing the Packet Classifiers Associated With a Gate . 24
5.7.4 Session Resources . 24
5.7.5 Admission Control and Session Classes . 25
5.7.6 Resource Renegotiations . 25
5.7.7 Dynamic Binding of Resources (Re-reserve) . 25
5.7.8 Support for Billing . 26
5.7.9 Backbone Resource Management . 26
5.7.10 Setting the DiffServ Code Point . 26
5.8 Sample Mapping of SDP Descriptions into RSVP Flowspecs . 26
6 Embedded MTA to CM QoS Protocol (pkt-q1) . . 28
6.1 RSVP FlowSpecs . 28
6.1.1 Complex SDP Descriptions with Multiple Codecs . 29 ®
6.1.2 Mapping RSVP FlowSpecs into DOCSIS 1.1 QoS Parameters . 30
6.1.2.1 Upstream Quality of Service Encodings . 30
6.1.2.2 Upstream Packet Classification Encodings . 31
ETSI
4 ETSI TS 103 161-5 V1.1.1 (2011-10)
6.1.2.3 Payload Header Suppression Encodings . 32
6.1.2.4 Downstream Quality of Service Encodings . 33
6.1.2.5 Downstream Packet Classification Encodings . 34
6.1.2.6 Example of Mapping . 35
6.1.3 CMTS Authorization and Behaviour . 36 ®
6.2 DOCSIS 1.1 Support for Resource Reservation . 37
6.2.1 Two Phase QoS Reservation/Commit. 37
6.2.2 Reservation Maintenance . 39
6.2.3 Support for Dynamic Binding of Resources . 39
6.2.4 QoS Parameter Mapping for Authorization . 40
6.2.5 Authorization Block Encoding . 42
6.2.6 Payload Header Suppression Handling . 43 ®
6.3 Use of DOCSIS 1.1 MAC Control Service Interface . 43
6.3.1 Reservation Establishment . 43
6.3.2 Reservation Change . 44
6.3.3 Reservation Deletion. 44
6.3.4 Multiple Grants per Interval Considerations . 45
6.3.4.1 Adding a Sub-Flow Pair . 45
6.3.4.2 Modifying a Sub-Flow Pair . 45
6.3.4.3 Deleting a Sub-Flow Pair . 46
6.3.4.4 Grouping Service Flows . 46
7 Authorization Interface Description (pkt-q6) . 46
7.1 Gates: the Framework for QoS Control . 47
7.1.1 Classifier . 47
7.1.2 Gate . 47
7.1.3 Gate Identification . 48
7.1.4 Gate Transition Diagram . 49
7.1.5 Gate Coordination . 51
7.2 COPS Profile for IPCablecom . 52
7.3 Gate Control Protocol Message Formats . 53
7.3.1 COPS Common Message Format . 53
7.3.2 Additional COPS Objects for Gate Control . 54
7.3.2.1 TransactionID . 54
7.3.2.2 Subscriber-ID . 55
7.3.2.3 GateID . 55
7.3.2.4 Activity-Count . 55
7.3.2.5 Gate-Spec . 56
7.3.2.6 Remote-Gate-Info . 57
7.3.2.7 Event-Generation-Info . 57
7.3.2.8 Media-Connection-Event-Info . 58
7.3.2.9 IPCablecom-Reason . 58
7.3.2.10 IPCablecom-Error . 58
7.3.2.11 Electronic-Surveillance-Parameters . 59
7.3.2.12 Session-Description-Parameters . 60
7.3.3 Definition of Gate Control Messages. 60
7.4 Gate Control Protocol Operation . 62
7.4.1 Initialization Sequence . 62
7.4.2 Operation Sequence . 63
7.4.3 Procedures for Allocating a new Gate . 63
7.4.4 Procedures for Authorizing Resources Through a Gate. 64
7.4.5 Procedures for Querying a Gate . 66
7.4.6 Procedures for Committing a Gate . 66
7.4.7 Procedures for Closing a Gate . 66
7.4.8 Procedures for Deleting a Gate . 66
7.4.9 Termination Sequence . 67
7.4.10 Failure Scenario . 67
7.5 CMS Use of Gate Protocol . 67
7.6 Gate-Coordination . 68
7.6.1 Connecting a Call . 68
7.6.2 Terminating a Call . 68
ETSI
5 ETSI TS 103 161-5 V1.1.1 (2011-10)
8 Timer Definitions and Values . 69
8.1 Timer T0 . 69
8.2 Timer T1 . 69
8.3 Timer T2 . 70
8.4 Timer T3 . 70
8.5 Timer T4 . 70
8.6 Timer T5 . 70
8.7 Timer T6 . 70
8.8 Timer T7 . 70
8.9 Timer T8 . 70
Annex A (informative): Theft of Service Scenarios . 71
Annex B (informative): Common Open Policy Service (COPS) . 73
Annex C (informative): TCP Considerations . . 75
Annex D (informative): Bibliography . 79
History . 80

ETSI
6 ETSI TS 103 161-5 V1.1.1 (2011-10)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://ipr.etsi.org).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Specification (TS) has been produced by ETSI Technical Committee Access, Terminals, Transmission
and Multiplexing (ATTM).
The present document is part 5 of a multi-part IPCablecom 1.5 deliverable covering the Digital Broadband Cable
Access to the Public Telecommunications Network; IP Multimedia Time Critical Services, as identified below:
Part 1: "Overview";
Part 2: "Architectural framework for the delivery of time critical services over Cable Television Networks using
Cable Modems";
Part 3: "Audio Codec Requirements for the Provision of Bi-Directional Audio Service over Cable Television
Networks using Cable Modems";
Part 4: "Network Call Signalling Protocol";
Part 5: "Dynamic Quality of Service for the Provision of Real Time Services over Cable Television
Networks using Cable Modems";
Part 6: "Event Message Specification";
Part 7: "Media Terminal Adapter (MTA Management Information Base (MIB)";
Part 8: "Network Call Signalling (NCS) MIB Requirements";
Part 9: "Security";
Part 10: "Management Information Base (MIB) Framework";
Part 11: "Media terminal adapter (MTA) device provisioning";
Part 12: "Management Event Mechanism";
Part 13: "Trunking Gateway Control Protocol - MGCP option";
Part 14: "Embedded MTA Analog Interface and Powering Specification"
Part 15: "Analog Trunking for PBX Specification";
Part 16: "Signalling for Call Management Server";
Part 17: "CMS Subscriber Provisioning Specification";
Part 18: "Media Terminal Adapter Extension MIB";
Part 19: "IPCablecom Audio Server Protocol Specification - MGCP option";
Part 20: "Management Event MIB Specification";
ETSI
7 ETSI TS 103 161-5 V1.1.1 (2011-10)
Part 21: "Signalling Extension MIB Specification".
NOTE 1: Additional parts may be proposed and will be added to the list in future versions.
NOTE 2: The choice of a multi-part format for this deliverable is to facilitate maintenance and future
enhancements.
ETSI
8 ETSI TS 103 161-5 V1.1.1 (2011-10)
1 Scope
The present document describes a dynamic Quality-of-Service (QoS) mechanism for the IPCablecom project. It was
issued to facilitate design and field-testing leading to the manufacture and interoperability of conforming hardware and
software by multiple vendors.
IPCablecom is a set of protocols developed to deliver Quality of Service enhanced communications services using
packetized data transmission technology to a consumer's home over the cable network. IPCablecom utilizes a network
superstructure that overlays the two-way data-ready cable television network. While the initial service offerings in the
IPCablecom product line are anticipated to be Packet Voice and Packet Video, the long-term project vision
encompasses a large family of packet-based services.
The present document addresses requirements for a client device to obtain access to IPCablecom network resources. In
particular, it specifies a comprehensive mechanism for a client device to request a specific Quality of Service from the ®
DOCSIS network. Extensive examples illustrate the use of the present document.
The scope of the present document is to define the QoS Architecture for the "Access" portion of the IPCablecom
network, provided to requesting applications on a per-flow basis. The access portion of the network is defined to be
between the Multimedia Terminal Adapter (MTA) and the Cable Modem Termination System (CMTS), including the ®
DOCSIS network. The method of QoS allocation over the backbone is unspecified in the present document. Interface
to the managed IP backbone and issues related to IP multicast are not within the scope of the present document. The
present document also recognizes that per-flow reservations may be required within the customer premises, and the
protocol developed addresses this potential need.
To summarize, the scope of the present document is:
• Allocation of QoS between the MTA and the CMTS.
• Specification of the interfaces which are available for control and delivery of QoS in IPCablecom Networks.
• Support for IPCablecom embedded MTAs.
• Support for Network-based Call Signalling (NCS) [3]. ®
The present document assumes that DOCSIS QoS (specifically RFI version 1.1 [2] or later) is used to control and
® ®
deliver QoS across the DOCSIS networks. Any reference to DOCSIS in the present document is understood to be ®
DOCSIS version 1.1 or later.
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
reference document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are necessary for the application of the present document.
[1] IETF RFC 2748: "The COPS (Common Open Policy Service) Protocol", January 2000.
[2] ETSI ES 201 488: "Data-Over-Cable Service Interface Specifications Radio Frequency Interface
Specification".
ETSI
9 ETSI TS 103 161-5 V1.1.1 (2011-10)
[3] ETSI TS 103 161-4: "Access, Terminals, Transmission and Multiplexing (ATTM); Integrated
Broadband Cable and Television Networks; IPCablecom 1.5 Part 4: Network Call Signalling
Protocol".
[4] IETF RFC 0791: "Internet Protocol", September 1981.
[5] IETF RFC 2474: "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6
Headers", December 1998.
2.2 Informative references
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] IETF RFC 2753: "A Framework for Policy Based Admission Control", January 2000.
[i.2] IETF RFC 3084: "COPS Usage for Policy Provisioning", March, 2001.
[i.3] IETF RFC 2327: SDP: Session Description Protocol, April 1998.
[i.4] ETSI TS 103 161-6: "Access, Terminals, Transmission and Multiplexing (ATTM); Integrated
Broadband Cable and Television Networks; IPCablecom 1.5; Part 6: Event Message
Specification".
[i.5] ETSI TS 103 161-3: "Access, Terminals, Transmission and Multiplexing (ATTM); Integrated
Broadband Cable and Television Networks; IPCablecom 1.5; Part 3: Audio Codec Requirements
for the Provision of Bi-Directional Audio Service over Cable Television Networks using Cable
Modems".
[i.6] IETF RFC 2749: "COPS Usage for RSVP", January 2000.
[i.7] IETF RFC 3551: "RTP Profile for Audio and Video Conferences with Minimal control",
July 2003.
[i.8] ETSI TS 103 161-2: "Access, Terminals, Transmission and Multiplexing (ATTM); Integrated
Broadband Cable and Television Networks; IPCablecom 1.5 Part 2: Architectural framework for
the delivery of time critical services over Cable Television Networks using Cable Modems".
[i.9] IETF RFC 3168: "The Addition of Explicitly Congestion Notification (ECN) to IPI", September
2001.
[i.10] ETSI TS 103 161-9: "Access, Terminals, Transmission and Multiplexing (ATTM); Integrated
Broadband Cable and Television Networks; IPCablecom 1.5 Part 9: Security".
[i.11] ITU-T Recommendation G.114: "One-way transmission time".
3 Definitions, symbols and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
access control: limiting the flow of information from the resources of a system only to authorized persons, programs,
processes, or other system resources on a network
admitted: allowed
authentication: process of verifying the claimed identity of an entity to another entity.
authorization: act of giving access to a service or device if one has permission to have the access
downstream: direction from the headend toward the subscriber location
ETSI
10 ETSI TS 103 161-5 V1.1.1 (2011-10)
embedded MTA: single node that contains both an MTA and a cable modem
endpoint: Terminal, Gateway or Multipoint Conference Unit (MCU)
event message: message capturing a single portion of a connection.
gateway: devices bridging between the IPCablecom IP Voice Communication world and the PSTN
NOTE: Examples are the Media Gateway, which provides the bearer circuit interfaces to the PSTN and
transcodes the media stream, and the Signalling Gateway, which sends and receives circuit switched
network signalling to the edge of the IPCablecom network.
header: protocol control information located at the beginning of a protocol data unit
jitter: variability in the delay of a stream of incoming packets making up a flow such as a voice communication
latency: time, expressed in quantity of symbols, taken for a signal element to pass through a device
Media Access Control (MAC): sublayer of the Data Link Layer that normally runs directly over the physical layer
Multimedia Terminal Adapter (MTA): device that contains the interface to a physical voice device, a network
interface, CODECs, and all signalling and encapsulation functions required for VoIP transport, class features signalling,
and QoS signalling
Pulse Code Modulation (PCM): A commonly employed algorithm to digitize an analogue signal (such as a human
voice) into a digital bit stream using simple analogue-to-digital conversion techniques.
subflow: unidirectional flow of IP packets characterized by a single source and destination IP address and single source
and destination UDP/TCP port
upstream: direction from the subscriber location toward the headend
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ATM Asynchronous Transfer Mode
BPI+ Baseline Privacy Plus Interface Specification
CBR Constant Bit Rate
CM Cable Modem
CMS Call Management Server
CMTS Cable Modem Termination System
CODEC COder-DECoder
COPS Common Open Policy Service (defined in RFC 2748 [1])
CRCX Create Connection
DF Delivery Function
DQoS Dynamic Quality-of-Service
DSA Dynamic Service Add
DSC Dynamic Service Change
DSCP DiffServ Code Point
E-MTA Embedded MTA
ETSI European Telecommunications Standards Institute
GC Gate Controller
IANA Internet Assigned Numbered Authority
IETF Internet Engineering Task Force
IP Internet Protocol
ITU-T International Telecommunication Union-Telecommunication Standardization Sector
LCO Local Connection Option
LDAP Lightweight Directory Access Protocol
LDP Local Decision Point
LLC Logical Link Control
LUB Local Connection Option
MAC Media Access Control
MTA Multimedia Terminal Adapter
ETSI
11 ETSI TS 103 161-5 V1.1.1 (2011-10)
NCS Network Call Signalling
OSS Operations Systems Support
PCM Pulse Code Modulation
PDP Policy Decision Point
PEP Policy Enforcement Point
PSTN Public Switched Telephone Network
QoS Quality of Service
RADIUS Remote Authentication Dial-In User Service
RAP Resource Allocation Protocol
RFC Request for Comments ®
RFI The DOCSIS Radio Frequency Interface document
RKS Record Keeping Server
RSVP Resource Reservation Protocol
RTCP Real-Time Control Protocol
RTO Retransmission Timeout
RTP Real-time Transport Protocol
SDP Session Description Protocol
TCP Transmission Control Protocol
TLV Type-Length-Value
TOS Type of Service
UDP User Datagram Protocol
VBD Voice Band Data
VoIP Voice-over-IP
4 Void
5 Technical Overview
Enhanced Quality of Service is required for supporting interactive multimedia applications. Resources may be
constrained in segments of the network, requiring allocation of resources in the network. The scope of the present
document is to define the Quality of Service Architecture for the "Access" portion of the IPCablecom network. The
access portion of the network is defined to be between the Multimedia Terminal Adapter (MTA) and the Cable Modem ®
Termination System (CMTS), including the DOCSIS network. The present document also recognizes that per-flow
reservations may be required within the customer premises, and the protocols developed herein address this potential
need. Although some segments of the backbone network may require resource reservation to provide adequate quality
of service, the protocols for backbone resource management are considered to be outside the scope of the present
document. ®
Resources are allocated on the DOCSIS network for individual flows associated with each session of an application,
per subscriber, on an authorized and authenticated basis. A DQoS session, or simply a session, is defined by the present
document to be a single bi-directional data flow between two clients. When a multi-media application needs multiple
bi-directional data flows (e.g. one for voice and a separate for video), separate DQoS sessions are established for each.
Applications may use only half of the session's bi-directional data flow, thereby providing send-only or receive-only
services. For example, in a typical voice communications application, a simple communication between two parties is
implemented by a single session, while complex, multiparty communications (e.g. "conference calls") are implemented
by multiple simultaneous sessions.
Network-based Call Signalling (NCS) is the defined IPCablecom Call Signalling Protocol. This Dynamic QoS
document is the underlying QoS framework for this call signalling protocol. QoS is allocated for flows associated with a
session in concert with the signalling protocol.
The present document introduces the concept of a segment-by-segment QoS framework. It exploits the information ®
available from signalling protocols to perform the QoS on both the "local" segment (on the DOCSIS network close to ®
the originating party) and the "remote" segment (the DOCSIS network close to the terminating party). Thus, the
present document allows different providers to use the most appropriate mechanisms for the segment that they are
managing. Using a concatenation of the segments with QoS, end-to-end QoS assurance for the session is provided.
ETSI
12 ETSI TS 103 161-5 V1.1.1 (2011-10)
The Dynamic QoS document incorporates protocols to enable providers of packet-based voice communications using
the IPCablecom framework to use different charging models, including both flat-rate charging as well as usage-based
charging. It is the intent of the present document to ensure that enhanced QoS is provided only to authorized and
authenticated users. The specific techniques used for authorizing and authenticating a user are beyond the scope of the
present document.
This Dynamic QoS document recognizes the requirements of a commercially viable voice communications service
analogous to that offered by means of the public switched telephone network. It is important to ensure that resources are
available before the two parties involved in the session are invited to communicate. Thus, resources are reserved before
the recipient of the communication is notified that someone is trying to initiate a communication. If there are
insufficient resources for a session, then the session is blocked.
The protocols developed in the present document explicitly recognize the need to ensure that there is no potential for
fraud or theft of service by end-points that do not wish to cooperate with the call signalling and QoS signalling
protocols with the intent of avoiding being charged for usage. The present document introduces the concept of a two-
phase for resource reservation (reserve and commit). The two-phases allow a provider to both allocate resources only
when they are required (when the voice path is cut-through) which may be used for billing. Further, because the second
phase to commit resources requires an explicit request from the MTA, it enables the provider to prevent fraud and theft
of service.
5.1 IPCablecom QoS Architecture Requirements
The following list presents the QoS requirements for supporting multimedia applications over IPCablecom Networks.
1) Provide IPCablecom accounting for the QoS resources on a per-session basis.
It is anticipated that, from a billing perspective, one of the resources that will need to be accounted for is the ®
use of QoS in the DOCSIS network. Thus, information needs to be identified and tracked that allows ®
reconciliation of the use of the DOCSIS QoS resource with IPCablecom session activity.
2) Both two-phase (reserve-commit) and single phase (commit) QoS activation models.
Under application control it should be possible to utilize either a two-phase or single-phase QoS activation
model. In the two-phase model the application reserves the resource, and later commits it. In the single phase ®
model both reservation and commitment occur as a single autonomous operation. As in the DOCSIS model,
resources that are reserved but not yet committed are available for temporary assignment to other (e.g. best
effort) service flows. The present document provides mechanisms for both two-phase and single-phase
activation for embedded MTAs. ®
3) Provide IPCablecom defined policies to control QoS in both the DOCSIS network and the IP backbone.
It should be possible for different types of sessions to have different QoS characteristics. For example, sessions
within a single cable operator provider's domain may receive different QoS than sessions outside the domain
(e.g. international sessions including links to the PSTN). This dynamic QoS document may allow a cable
operator to provide different QoS for different types of customers (e.g. higher QoS for subscribers of a
business service at certain times of the day compared to residential customers), or different types of
applications for a single customer.
4) Prevent (minimize) abusive QoS usage.
Two types of abusive QoS usage are identified: that which is accurately billed but leads to denying service to
others, and that which is not accurately billed and leads to theft of service. Subscriber applications and
IPCablecom applications (either embedded or PC-based) may inadvertently or intentionally abuse their QoS
privileges (e.g. use of enhanced QoS, which the provider wants limited to voice applications, by an FTP ®
application). Even though the DOCSIS network is expected to enforce a subscriber's access to QoS, rich
packet classification and signalling control mechanisms should exist to keep the subscriber (and the subscriber
devices) from fraudulent use of QoS. Admission control procedures should be employed to reduce denial-of-
service attacks. ®
5) Provide admission control mechanisms for both upstream and downstream directions in the DOCSIS
network.
Both upstream and downstream QoS should be subject to per-session admission control.
ETSI
13 ETSI TS 103 161-5 V1.1.1 (2011-10) ®
6) DOCSIS QoS.
It should be possible to police (defined as marking, dropping, or delaying packets) all aspects of QoS defined ®
in the service at the CMTS using the DOCSIS QoS mechanisms. Furthermore, it should be possible to
support multiple flow mapping models - single IPCablecom session to a single Service Flow and multiple
IPCablecom sessions to a single Service Flow.
7) Policy is enforced by the CMTS.
Ultimate policy control is entrusted to the CMTS. The philosophy is that any client can make any QoS request,
but the CMTS (or an entity behind the CMTS) is the only entity entrusted to grant or deny QoS requests. ®
8) IPCablecom entities must be as unaware as possible of specific DOCSIS QoS primitives and parameters.
For IPCablecom, like any other application that uses the IP-network, the design objective is to minimize the
amount of access-link-specific knowledge contained within the application layer. The less access-link
knowledge in the application layer, the more applications will be available for development and deployment,
and the fewer testing and support-problems will be encountered.
9) Reclamation of QoS resources for dead/stale sessions.
It is necessary to re-claim and re-allocate precious QoS resources for sessions that are no longer active, but ®
have not been properly torn down. There should be no resource 'leaks' in the DOCSIS link. For example, if an ®
IPCablecom client module malfunctions in the midst of an IPCablecom session, all DOCSIS QoS resources
used by the session should be released within a reasonable period of time.
10) Dynamic QoS policy changes.
It is desirable to dynamically change QoS policies for subscribers. For example, this requirement addresses the
ability to change a customer's service level (e.g. upgraded from a "bronze" service to a "gold" service) on-the-
fly without resetting the cable modem.
11) Absolute minimum session setup latency time and post pickup delay.
The IPCablecom Network should allow for emulation and enhancement of the PSTN experience to the user,
and should be equally good, if not better, in session setup and post pickup delay met
...