Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation  Back up to About Overview 
ContentIndex
  
[+] Expand All
[-] Collapse All

 A  C  D  E  F  G  I  J  L  M  N  P  Q  R  S  T  W

 

A

address pools    
assigned IP subscribers    
configuring
address pools.     See IP address pools    
application manager    
role, in PCMM environment
assigned IP subscribers    
PCMM network    12
address pools
IP address pools
setting timeouts
voice over IP
 

C

cable modem termination system.     See CMTS devices    
classify-traffic condition    
match direction, setting    
SRC CLI
client type 1, PCMM
client type 2, PCMM
CMTS devices    
adding objects to directory    
SRC CLI
adding virtual router objects to directory    
SRC CLI
configuration statements    12
role
CMTS locator    
monitoring    
C-Web interface
SRC CLI
COA script services, configuring
configuration wizard    
fair usage    
configuration overview
running
running    12
configuration wizards    
fair usage    
overview
overview    12
conventions    
notice icons
text
custom RADIUS authentication plug-ins
customer support    1
contacting JTAC
 

D

Data over Cable Service Interface Specifications.     See DOCSIS protocol    
Diameter    
peers    
configuring    12
Diameter server    
clients, viewing    
SRC CLI
message flows, viewing    
SRC CLI
message handler, viewing    
SRC CLI
monitoring    
SRC CLI
peers, viewing    
SRC CLI
server process, viewing    
SRC CLI
server requests, viewing    
SRC CLI
statistics, viewing    
SRC CLI
status, viewing    
SRC CLI
DOCSIS protocol
documentation    
comments on
domains    
IP service edge
IP subscriber edge
radio frequency
Dynamic policy changes    
Dynamic policy changes, managing
dynamic RADIUS authorization requests    
RADIUS packets, defining    12
 

E

end-to-end services
event notification, PCMM network    
configuration statements
description
properties, configuring    
SRC CLI
 

F

filter actions    
configuring    
SRC CLI
flexible RADIUS authentication plug-ins    
configuring
forwarding class actions    
configuring    
SRC CLI
 

G

Gx router driver    
application information, configuring    
SRC CLI
dynamic PCC rules, configuring    
SRC CLI
flow information, configuring    
SRC CLI
overview
policies, configuration statements    
SRC CLI
policies, configuring    
SRC CLI
policy list, configuring    
SRC CLI
QoS information, configuring    
SRC CLI
redirect information, configuring    
SRC CLI
static PCC rules, configuring    
SRC CLI
steering information, configuring    
SRC CLI
 

I

IP address pools    
assigned IP subscribers
assigned IP subscribers, configuring    
SRC CLI
local address pools, configuring    
SRC CLI
static pools, configuring    
SRC CLI
 

J

JPS (Juniper Policy Server)    
application manager-to-policy server interface, configuring
application manager-to-policy server interface, monitoring    
C-Web interface    12
SRC CLI
architecture
CMTS devices, monitoring    
C-Web interface
CMTS locator, monitoring    
C-Web interface
SRC CLI
JPS state, monitoring
logging, configuring
logging, modifying
message flows, monitoring    
C-Web interface
SRC CLI
message handler, monitoring    
C-Web interface
SRC CLI
monitoring    
C-Web interface
SRC CLI    12
operational status
overview
policy server-to-CMTS interface, configuring
policy server-to-CMTS interface, monitoring    
C-Web interface    12
SRC CLI
policy server-to-RKS interface, configuring
policy server-to-RKS interface, monitoring    
C-Web interface
SRC CLI
server process, monitoring    
C-Web interface
SRC CLI
starting    
SRC CLI
stopping    
SRC CLI
subscriber address mappings, configuring
subscriber configuration, modifying
JSRC    
JSRC and PTSP configuration example    
SRC CLI
Juniper Policy Server.     See JPS    
 

L

login process    
assigned IP subscribers, PCMM
 

M

manuals    
comments on
MX Series router as a PTSP network device    
MX Series router as a PTSP network device, adding    
SRC CLI
 

N

NIC (network information collector)    
IP address pools, configuring    
SRC CLI
notice icons
 

P

packet mirroring, configuring
PCMM (PacketCable Multimedia)    
application manager, role
client type 1
client type 2
CMTS device, role
configuring SAE    
SRC CLI
creating sessions
description
end-to-end QoS architecture
end-to-end services
integrating SRC software
IP service edge domain
IP subscriber edge domain
logging in subscribers    
assigned IP method
overview
overview
policy server, role
provisioning end-to-end services
record-keeping server
RF domain
SAE
SAE communities
session store
single-phase resource reservation model
SRC software in    
description
traffic profiles
video-on-demand example
videoconferencing example
PCMM device driver    
configuration statements
configuring    
SRC CLI
PCMM record-keeping server plug-in    
configuration statements
configuring    
SRC CLI
description
plug-ins    
PCMM record-keeping server plug-in
policy actions    
filter    
configuring, SRC CLI
forwarding class    
configuring, SRC CLI
forwarding instance    
configuring, SRC CLI
policy groups    
configuring    
SRC CLI
policy servers    
adding application manager groups    
SRC CLI
adding objects to directory    
SRC CLI
role, in PCMM architecture
specifying application managers    
SRC CLI
specifying SAE communities    
SRC CLI
PTSP    
configuring    
SRC CLI
PTSP and JSRC configuration example    
SRC CLI
PTSP configuration example    
SRC CLI
PTSP policies, configuration statements    
SRC CLI
ssr-writer    
SRC CLI
PTSP actions    
PTSP actions, configuring    
SRC CLI    12
PTSP classify-traffic condition    
destination grouped network, configuring    
SRC CLI
destination network, configuring    
SRC CLI
protocol conditions with parameters, setting    
SRC CLI
protocol conditions with ports, setting    
SRC CLI
protocol conditions, setting    
SRC CLI
TCP conditions, setting    
SRC CLI
traffic match conditions, setting    
SRC CLI
PTSP classify-traffic conditions    
creating    
SRC CLI
PTSP classify-traffic conditions, configuring    
SRC CLI
PTSP device driver    
overview
PTSP device driver, configuring    
SRC CLI
PTSP on MX Series router    
PTSP on MX Series router, configuring    
SRC CLI
PTSP policer instance    
PTSP policer instance, configuring    
SRC CLI
PTSP policies    
PTSP policies, configuring    
SRC CLI
PTSP policy list    
PTSP policy list, configuring    
SRC CLI
PTSP policy rules    
network, specifying
PTSP policy rules, configuring    
SRC CLI
PTSP session store    
PTSP device driver session store, configuring    
SRC CLI
PTSP traffic match    
conditions, setting    
SRC CLI
 

Q

QoS (quality of service)    
PCMM environments    
end-to-end QoS architecture
extending to service edge domain
extending to subscriber edge domain
searching for policies in directory
QoS profile-tracking plug-in    
description
QoS profiles, routers running JunosE Software    
how tracking works
managing dynamically
updating directory, using    
qosProfilePublish
quality of service.     See QoS    
 

R

RADIUS    
vendor-specific attributes for wireless ISP roaming
record-keeping server.     See RKS    
RKS (record-keeping server)    
peers, configuration statements
peers, configuring in plug-ins    
SRC CLI
plug-in
plug-in, configuration statements
plug-in, configuring    
SRC CLI
role in PCMM environment
roaming wireless environment
 

S

SAE (service activation engine)    
configuring as an application manager    
SRC CLI
PCMM environment
redundancy.     See SAE communities    
SAE (service activation engine), configuring    
community manager    
SRC CLI
event notification API properties    
SRC CLI
PCMM device driver    
SRC CLI    12
SAE communities    
configuration overview    
SRC CLI
configuration statements
configuring manager    
SRC CLI
defining members    
SRC CLI
description
service flows
services    
voice over IP (VoIP)
session store    
in PCMM environment
single phase resource reservation model, PCMM
subscriber    
wireless environment
support, technical     See technical support    
 

T

technical support    
contacting JTAC
text conventions defined
traffic policies, PCMM
 

W

wireless environment

Related Documentation

  • For more information about each scheduling type, see Delivering QoS Services in a Cable Environment
  • For more information about PCMM, consult the following specifications provided by CableLabs:
    • PacketCable Multimedia Architecture Framework Technical Report (PKT-TR-MM-ARCH)
    • PacketCable Multimedia Specification PKT-SP-MM-I03-051221
    • PacketCable Security Specifications (PKT-SP-SEC)
  • Using the SAE in a PCMM Environment
  • Using the NIC Resolver in PCMM Environments
  • Example: Providing Premium Services

PCMM Environment Overview

The PacketCable Multimedia (PCMM) specification defines a standards-based way to deliver premium quality of service (QoS)–enhanced services across the radio frequency (RF) portion of a cable network. The PCMM capabilities of the SRC software along with Juniper Networks routers provide an end-to-end solution that seamlessly links the cable operator’s RF domain with IP edge and core QoS services.

Key services supported in this environment include:

  • Bandwidth on demand and variable bandwidth
  • QoS-enabled streaming media, including video on demand and video telephony
  • Residential voice over IP (VoIP)
  • Multicast audio and video applications
  • Videoconferencing
  • Interactive gaming
  • Peer-to-peer controls and protection services

PCMM Architecture

Figure 5 depicts the PCMM architectural framework. The basic roles of the various PCMM components are:

  • Application manager—Provides an interface to policy server(s) for the purpose of requesting QoS-based service on behalf of a subscriber or a network management system. It maps session requests to resource requests and creates policies.
  • Policy server—Acts as a policy decision point and policy enforcement point and manages relationships between application managers and cable modem termination system (CMTS) devices.
  • CMTS device—Cable modem termination system. Performs admission control and manages network resources through Data over Cable Service Interface Specifications (DOCSIS) service flows.
  • Client—Represents endpoints, such as PC applications, that can send or receive data.
  • Record-keeping server—Receives event messages from other network elements, such as the policy server or CMTS device, and acts as a short-term repository for the messages. It can also assemble event messages into coherent sets or call detail records, which are then made available to other back office systems, such as billing, fraud detection, and other systems.

    Figure 5: PCMM Architectural Framework

    PCMM Architectural Framework

In the PCMM architecture, a client requests a multimedia service from an application manager. The application manager relays the request to a policy server. The policy server is then responsible for provisioning the policies on a CMTS device. Based on the request, the policy server records an event that indicates the policy request. The request can include network resource records, and the policy server can provide the records to a record-keeping server, such as a RADIUS accounting server.

The policy server may also provide functions such as tracking resource usage and tracking the authorization of resources on a per-subscriber, per-service, or aggregate basis.

DOCSIS Protocol

The DOCSIS protocol is the standard for providing quality of service for traffic between the cable modem and CMTS devices. The CMTS device is the head-end in the DOCSIS architecture, and it controls the operations of many cable modems. Two channels carry signals between CMTS devices and cable modems:

  • Downstream channels—Carry signals from the CMTS head-end to cable modems.
  • Upstream channels—Carry signals from the cable modems to the CMTS head-end.

The DOCSIS protocol defines the physical layer and the Media Access Control (MAC) protocol layer that is used on these channels.

A cable modem usually uses one upstream channel and an associated downstream channel. Upstream channels are shared, and the CMTS device uses the MAC protocol to control the cable modem’s access to the upstream channel.

Service Flows

The DOCSIS protocol uses the concept of service flows to support QoS on upstream and downstream channels. A service flow is a unidirectional flow of packets that provides a particular quality of service. Traffic is classified into a service flow, and each service flow has its own set of QoS parameters. The SRC software is compliant with the following upstream service flow scheduling types, as defined in the PacketCable Multimedia Specification PKT-SP-MM-I03-051221.

  • Best effort—Used for standard Internet traffic such as Web browsing, e-mail, or instant messaging.
  • Non-real-time polling service (NRTPS)—Used for standard Internet traffic that requires high throughput, and traffic that requires variable-sized data packets on a regular basis, such as high-bandwidth File Transfer Protocol (FTP).
  • Real-time polling service (RTPS)—Used for applications such as Moving Pictures Experts Group (MPEG) video.
  • Unsolicited grant service (UGS)—Used for real-time traffic that generates fixed-size data packets on a periodic basis. Applications include VoIP.
  • Unsolicited grant service with activity detection (UGS-AD)—Used for applications such as voice activity detection, also known as silence suppression.

Downstream service flows are defined through a similar set of QoS parameters that are associated with the best-effort scheduling type on upstream service flows.

Client Types

The PCMM specification uses the concept of clients and defines a client as a logical entity that can send or receive data. The SRC software supports type 1 and type 2 clients.

The PCMM specification defines two resource reservation models for each client type—a single phase and a dual phase. The SRC software supports the single-phase model.

Client Type 1 Single Phase Resource Reservation Model

Type 1 clients represent endpoints, such as PC applications or gaming consoles, that lack specific QoS awareness or signaling capabilities. Type 1 clients communicate with an application manager to request a service. They do not request QoS resources directly from the multiple service operator (MSO) network.

Client type 1 entities support the proxied-QoS with policy-push scenario of service delivery defined in PacketCable Multimedia Architecture Framework Technical Report (PKT-TR-MM-ARCH). In this scenario, the application manager requests QoS resources on behalf of the client, and the policy server pushes the request to the CMTS device. The CMTS device sets up and manages the DOCSIS service flow that the application requires, and might also set up and manage the cable modems.

Figure 6 shows the message flow in an application scenario for the client type 1 single-phase resource reservation model.

Figure 6: Client Type 1 Single-Phase Resource Reservation Model

Client Type 1 Single-Phase Resource Reservation
Model

Client Type 2 Single Phase Resource Reservation Model

Type 2 clients represent endpoints that have QoS awareness or signaling capabilities. Type 2 clients communicate with an application manager to request a service and to obtain a token to present for requesting QoS resources directly from the MSO network.

Client type 2 entities support the client-requested QoS with policy-push scenario of service delivery defined in PacketCable Multimedia Architecture Framework Technical Report (PKT-TR-MM-ARCH). In this scenario, the application manager requests QoS resources on behalf of the client, and the policy server pushes the request to the CMTS device. The CMTS device sets up and manages the DOCSIS service flow that the application requires. After the CMTS device sets up the policy, the client can request QoS resources directly from the CMTS device as long as the request is authorized by the policy server.

Figure 7 shows the message flow in an application scenario for the client type 2 single-phase resource reservation model.

Figure 7: Client Type 2 Single-Phase Resource Reservation Model

Client Type 2 Single-Phase Resource Reservation
Model

SRC Software in the PCMM Environment

Figure 8 shows the SRC software in the PCMM environment. The SAE is an application manager that can manage a PCMM-compliant policy server and/or a CMTS device on behalf of applications. The SAE has an embedded policy server that is not fully PCMM-compliant, but it can manage CMTS devices without requiring an external policy server. The Juniper Policy Server (JPS), a component of the SRC software that acts as a policy server, is a PCMM-compliant policy server. For more information about using the JPS, see JPS Framework.

Figure 8: SRC Software in the PCMM Environment

SRC Software in the PCMM Environment

Traffic Profiles

The SRC software supports three types of policies that you can use to define traffic profiles between the CMTS device and the cable modem:

  • DOCSIS parameters—Specifies the traffic profile through DOCSIS-specific parameters. You select the type of service flow that you want to offer, and then configure QoS parameters for the service flow.
  • Service class name—Specifies the name of a service class that is configured on the CMTS device.
  • FlowSpec—Defines the traffic profile through an Resource Reservation Protocol (RSVP)-like parameterization scheme. FlowSpecs support both controlled-load and guaranteed services.

You can also mark packets and then install policies that handle the marked packets in a certain way. The mark action sets the ToS byte in the IP header of IPv4 traffic or the traffic-class field in the IP header of IPv6 traffic.

For more information about traffic profiles, see Delivering QoS Services in a Cable Environment.

End-to-End QoS Architecture

The previous sections show how the SRC software supports QoS in the cable operator’s RF domain, which encompasses the connection from the cable modem to the CMTS device. Using the SRC software along with Juniper Networks routers, you can link the RF domain to the subscriber and service edge domains.

  • IP subscriber edge domain—Includes the IP network from the CMTS device to the edge router that typically connects to the cable operator’s regional access network. (See Extending QoS to the Subscriber Edge Domain.)
  • IP service edge domain—Typically includes the IP network that connects the data center that houses service delivery applications to a backbone or directly to a cable head-on facility. (See Extending QoS to the Service Edge Domain .)

By provisioning services across a network path, you can deliver a particular level of service for specified types of traffic. Figure 9 shows a typical high-level architecture of a cable operator and how the SRC software and Juniper Networks routers can be deployed to deliver end-to-end QoS services.

Figure 9: End-to-End QoS Architecture in a Cable Network

End-to-End QoS Architecture in a Cable
Network

Extending QoS to the Subscriber Edge Domain

The subscriber edge domain includes subscriber edge routers that aggregate CMTS devices. To support QoS in subscriber edge domains, QoS must be enabled across the subscriber edge into the core or regional access network. When the SRC software receives a service request, it performs service authorization, which can include admission control. It then sends policies to the appropriate CMTS device and subscriber edge router interface.

In addition to the QoS services required in the RF domain, service policies in the subscriber edge domain that must be available for provisioning at this point include:

  • Policy routing to best-of-breed appliances and premium paths
  • Rate limiting, traffic shaping, and marking
  • Admission control (edge resources and core resources)
  • Captive portal and Web redirect capabilities
  • Filtering and routers running Junos OS–based firewall services
  • Routers running Junos OS virtual private network (VPN) services

Extending QoS to the Service Edge Domain

The service edge domain includes service edge routers that aggregate applications. To support QoS in service edge domains, the SRC software sends policies to a service edge router that provides for enhanced service delivery to the service origination edge for centralized or hosted services, such as multimedia or VoD.

In addition to the QoS services required in the RF domain, service policies in the service edge domain that must be capable of being provisioned at this point include:

  • Policy routing to best-of-breed appliances and premium paths
  • Rate limiting, traffic shaping (called hierarchical queuing in JunosE software), and marking
  • Filtering and routers running Junos OS–based firewall services
  • Routers running Junos OS VPN services

Provisioning End-to-End Services

The following sections provide examples of how you can use the SRC software to provision services for video applications. Although the examples show one SAE managing all the network devices, separate SAEs could manage each device and provide the same service.

Example for Videoconferencing Services

You can configure services to mark traffic forwarded from specified systems, and then apply an end-to-end service level for that traffic. Figure 10 shows a scenario in which videoconferencing is delivered in a PCMM environment.

Figure 10: Videoconferencing Example

Videoconferencing Example

To ensure a specified level of service from each client PC to the videoconference server and then to each client PC participating in the videoconference, you could configure the following types of services:

  • Three services:
    • A service that provides policies to mark packets with a specified type of service for the videoconferencing software.
    • A service that provides policies for the type of service specified for CMTS device.
    • A service that provides policies for the type of service specified for the routers running Junos or JunosE Software.
  • An infrastructure service for each service.
  • An aggregate service that contains the three infrastructure services as fragment services.

This configuration marks packets that the CMTS device receives from both client and server, and applies forwarding policies on the CMTS device and on the routers running JunosE or Junos OS for packets sent to and received from the videoconferencing server.

Example for Video-on-Demand Services

You can configure services to provide server-to-client service for traffic sent from a video-on-demand server to client PCs. Figure 11 shows a scenario in which video on demand is delivered in a PCMM environment.

Figure 11: Video-on-Demand Example

Video-on-Demand Example

To ensure a specified level of service from the video-on-demand server to the client PC, you could configure the following types of services:

  • Services that provide bandwidth-on-demand (BoD) policies for traffic that is being forwarded from the video-on-demand server through:
    • Routers running Junos OS
    • CMTS devices
  • A script service that sets up the Multiprotocol Label Switching (MPLS) path and delivers the specified service level for traffic that is being forwarded from the video-on-demand server through the MPLS domain.
  • An infrastructure service for each value-added and script service.
  • An aggregate service that contains all the infrastructure services as fragment services.

This configuration applies BoD policies to routers running JunosE or Junos OS, the MPLS domain, and the CMTS device, and sets up the MPLS path from router running Junos OS (2) to router running Junos OS (1).

Related Documentation

  • For more information about each scheduling type, see Delivering QoS Services in a Cable Environment
  • For more information about PCMM, consult the following specifications provided by CableLabs:
    • PacketCable Multimedia Architecture Framework Technical Report (PKT-TR-MM-ARCH)
    • PacketCable Multimedia Specification PKT-SP-MM-I03-051221
    • PacketCable Security Specifications (PKT-SP-SEC)
  • Using the SAE in a PCMM Environment
  • Using the NIC Resolver in PCMM Environments
  • Example: Providing Premium Services

Modified: 2015-06-19