A
- access policy, examples 1
- action threshold, service schedules
- actions. See policy actions
- aggregate services 1
- adding
- before you configure
- fragment services
- infrastructure services
- mandatory services
- Python expressions
- redundancy
- sessions 1
- timers, configuring
- apply-groups statement, routers running Junos OS
C
- captive portal
- using with next-hop action
- classify-traffic condition 1
- application protocol
- application, setting
- application-group, setting
- configuring
- destination grouped network, configuring
- destination network, configuring
- expanded classifiers 1
- extended classifiers 1
- ICMP conditions, setting
- IGMP conditions, setting
- IPSec conditions, setting
- Junos OS filter conditions, setting
- JunosE secondary input policy conditions, setting
- match direction, setting
- multiple classifiers
- packet length, setting
- PCMM I02 and I03 1
- port definitions, overview
- protocol conditions with parameters, setting
- protocol conditions with ports, setting
- protocol conditions, setting
- route class, configuring
- source grouped network, configuring
- source network, setting
- TCP conditions, setting
- term-precedence, setting
- ToS byte conditions, setting
- color actions 1
- configuring
- color mark actions 1, 2
- controlled load service, FlowSpec
- conventions
- CoS (class of service)
- ToS byte, setting
- customer support 1
D
- Data-over-Cable Service Interface Specifications. See DOCSIS
- default policies
- example
- DHCP (Dynamic Host Configuration Protocol)
- access policy example
- Differentiated Services code point, ToS byte
- DOCSIS policy actions 1
- configuring
- documentation
- drop profile maps
- DSCP (Differentiated Services code point), ToS byte
E
- effective period, service schedules
- exclusions to service schedule 1
- defining
- expanded classifiers 1
- configuring
- expressions
- map, application protocol conditions
- parameter definitions
- extended classifiers, PCMM 1
- configuring
- external parent groups
- external parent groups,
- aggregate rate-limit
- configuration statements
- for JunosE policies
- hierarchical policy parameter
- JunosE
- rate-limit profiles
F
G
- gates, PCMM
- gateSpec actions 1
- configuring
- global parameters 1
- guaranteed service, FlowSpec
H
I
J
- Junos OS ASP policy rules 1
- Junos OS filter policy rules 1
- conditions, setting
- Junos OS policer policy rules 1
- policer actions 1
- Junos OS port mirror policy rules
- Junos OS scheduler policy rules 1, 2, See also drop profile maps
- actions 1
- QoS conditions, configuring
- Junos OS shaping policy rules
- JunosE IPv6 policy rules
- JunosE secondary input policy rules
- conditions, setting
L
M
- manuals
- map expressions
- application protocol conditions
- substitutions
- mark actions 1
- configuring
- multiple classifiers, policies
- multitask
- mutex group 1
- adding
N
- NAT (Network Address Translation) policies
- actions 1
- application protocol condition
- next-hop actions 1
- next-interface actions 1
- configuring
- next-rule actions 1
- configuring
- non-real-time polling service.
- notice icons
- NRTPS (non-real-time polling service)
O
P
- packet loss priority. See loss priority actions
- PacketCable Multimedia Specifications. See PCMM
- parameter names
- parameter value acquisition 1, 2, See also substitutions
- parameter values, setting in services
- parameters 1, See also substitutions
- defining
- definition
- fixing
- global. See global parameters
- local. See local parameters
- ranking sources
- runtime. See runtime parameters
- types
- parent groups 1, 2, 3, 4, 5
- PCMM policies
- classifiers
- client type 1 support
- conditions and actions supported
- DOCSIS parameters 1
- extended classifiers 1
- FlowSpec parameters
- gate
- gateSpec parameters, configuring
- I02 and I03 classifiers
- marking packets
- proxied QoS with policy push
- service class name
- service flow scheduling types
- SessionClassId
- traffic profiles
- permanent service 1
- configuring
- plug-ins
- policer actions 1
- configuring
- policies
- policing policies
- example
- policy actions 1
- color 1
- color mark 1, 2
- combining
- configuring
- DOCSIS 1
- dynamic profiles
- filter 1
- FlowSpec 1
- forward 1
- forwarding class 1
- forwarding instance
- gateSpec 1
- loss priority 1
- mark 1
- NAT 1
- next hop 1
- next interface 1
- next rule 1
- policer 1
- policy rules supported
- QoS profile attachment 1
- rate limit 1
- rate limit hierarchy
- rate limit types
- rate-limit hierarchy
- reject 1
- routing instance 1
- scheduler 1
- service class name 1
- stateful firewall 1
- template activation
- traffic class 1
- traffic mirror 1
- traffic-shape 1
- types
- user packet class 1
- policy components 1
- policy conditions 1, 2, See also classify-traffic condition
- policy engine
- policy examples
- policy folders 1
- configuring
- policy groups 1
- configuring
- policy lists 1
- configuring
- policy management
- policy objects
- policy overview
- actions. See policy actions
- conditions. See classify-traffic condition\
- policy object organization
- policy repository, description
- policy rules 1
- actions supported
- conditions supported
- configuring
- Junos Adaptive Services PIC (ASP). See Junos OS ASP policy rules
- Junos OS filter. See Junos OS filter policy rules
- Junos OS policer. See Junos OS policer policy rules
- Junos OS scheduler. See Junos OS scheduler policy rules
- Junos OS shaping. See Junos OS shaping policy rules
- precedence
- types
- PPP
- access policy example
- precedence
- policy rules
- premium service, example
- preparation time, service schedules
- proxied QoS with policy push
- PTSP actions
- PTSP actions, configuring
Q
R
- rate-limit actions 1
- rate-limit hierarchy actions
- rate-limit type actions
- configuring
- rate-limiting, with multiple classifiers
- real-time polling service. See RTPS
- reject actions 1
- configuring
- routers running Junos OS
- policy features
- routing instance actions 1
- configuring
- RTPS (real-time polling service) 1
- runtime parameters
S
- scheduleAuth plug-in
- scheduler actions 1, 2, See also drop profile maps
- configuring
- scopes. See service scopes
- script services 1
- service
- 3gpp attributes (Gx router driver)
- service class name actions 1
- configuring
- service flow scheduling types
- service schedules
- action threshold, setting
- authorization schedules, configuring
- configuring
- examples
- exclusions, defining
- guidelines
- overview 1
- planning
- preparation time, setting
- weekly-recur-freq
- service scopes 1, 2
- service-mgm-schedules-nonwork
- services
- activate-only
- adding aggregate
- adding infrastructure
- adding normal
- adding script services
- aggregate. See aggregate services
- assigning to service scopes
- automatic activation
- infrastructure. See infrastructure services
- mutually exclusive
- overview
- premium service example
- restricting availability
- restricting simultaneous activation
- script. See script services
- setting parameter values
- tiered Internet example
- SessionClassId, PCMM policies
- shaping rate. See traffic shaping
- stateful firewall policies
- actions 1
- application protocol conditions
- substitutions 1, See also parameters
- support, technical See technical support
T
- technical support
- template activation actions
- configuring
- text conventions defined
- tiered Internet service, example
- traffic mirror actions 1
- configuring
- traffic profiles, PCMM policies
- traffic shape actions
- configuring
- traffic shaping
- traffic-class actions 1
- configuring
- traffic-shape actions
U
V
- validating
- value acquisition for parameters
Download This Guide
Related Documentation
Service Schedules Overview
Service schedules define when specified services will be activated or deactivated and can also indicate when specified services are available or unavailable to subscribers. You can configure a service schedule for all subscribers to a service, or for a selected subscriber or subscribers. Schedules are composed of a number of rules expressed as schedule entries in the schedule configuration.
You can exclude specified times, such as a day of the week, a specific date, or a time interval, from schedule rules. These times are referred to as schedule exclusions.
There are three types of schedules:
- Event-based schedules—The SAE activates or deactivates a service at a specified time. You specify the time the action is to occur, and any intervals to extend that time.
- Authorization schedules—The SAE allows or disallows access to a service during a specified interval; it can also deactivate sessions for current subscribers to a service at the beginning or end of an interval.
- State-based schedules—The SAE controls the times at which a service is available. Subscribers cannot change these schedules.
Event-Based Schedules
For each rule in event-based schedules, you specify a time at which the SAE activates or deactivates a specified service. In most cases for schedules configured under the global service configuration (for example, o=Services), a subscriber must be logged in at the time that the event occurs. For example, if a service is scheduled to be activated at 8 AM, the subscriber must already be logged in to the system at 8 AM.
You can extend the time at which a scheduled action can be initiated by configuring the following for event-based schedules:
- Action threshold—Interval after a scheduled time that an action can occur. The action threshold is configured globally for the SAE server.
- Preparation time—Interval before a scheduled time that an action can occur. The preparation time is configured globally for the SAE server.
Extending the time gives subscribers flexibility in when they can log in and in the time they can perform a task. It also gives the system time to complete a transition from one state to another and distributes the load on the system.
You can also configure an interval after a scheduled time that an action can occur for individual schedules and event-based schedules.
Action Threshold
The action threshold indicates the maximum delay that a service allows for a time-related change to occur. For example, you can allow a 15-minute delay so that if an event is scheduled for 5:00 AM but the system is not able to perform the event at 5:00 AM, the SAE attempts to perform the action until 5:15 AM, as shown in Figure 3.
Figure 3: Sample Action Threshold

Preparation Time
Because the transition from one state to another does not occur instantaneously, the SAE uses the preparation time to allow for the time that the SAE needs to make the transition. For example, if you have a pay-per-view service and many subscribers need to have the service activated by a certain time, you can configure the service schedule preparation time to begin the process early to make sure that everyone gets their service activated by the time the event starts. Or you could schedule a few minutes of preparation time for setting up a video conference.
A preparation time applies only to subscribers
who have a service schedule and who are logged in to their subscriber
session before the preparation time starts. For example, if you define
a service schedule that activates service Audio-Gold at
8:00 AM, this service is activated only for subscribers who are
subscribed to this service and are logged in as of 7:55 AM (assuming
a default preparation time of 5 minutes). The service is not activated
for subscribers who log in between 7:55 AM and 8:00 AM, as shown in Figure 4.
Figure 4: Sample Preparation Time

![]() | Note: To avoid applying the preparation time of a service to scheduled deactivate events of the service, set the disable-preparation-time option under the [edit shared sae configuration time-based-policies] hierarchy. When this option is set, the SRC software does not calculate the preparation time for scheduled events that contain only deactivate actions. You can enable the disable-preparation-time option to ensure that the preparation time is applied only to activate events at the beginning of the service and not to deactivate events at the end of the service. The preparation time is applied to scheduled events that contain various action types (such as activate, deactivate, deny, and deny-deactivate) even though the disable-preparation-time option is enabled. |
Authorization Schedules
SAE uses authorization schedules to restrict access to both activate-on-login (AOL) services and manual services during a specified time period. For an authorization schedule, the types of action can be:
- Deny—Denies service activations in the specified time period and does not deactivate services that are already active for current subscribers.
- Deny deactivate—Denies new activation requests during the specified time period and deactivates the service sessions that are already active for current subscribers.
For authorization schedules, a service is either available or unavailable. You can configure intervals during which subscribers can login and activate a specified service and intervals during which subscribers cannot activate a specified service. In addition, an authorization schedule can deactivate a service at a specified time for subscribers who are using the service.
For example, you could use an authorization schedule to offer a service only between 5 PM and 8 PM. In this case, you can configure a schedule that denies activation of the service during any other time period. If a subscriber attempts to activate the service at a time other than between 5 PM and 8 PM, the activation is denied.
You can configure authorization schedules only for services that use authorization; that is, a service configured to use an authorization plug-in, such as the scheduleAuth plug-in provided by the sample data.
State-Based Schedules
For state-based schedules, you create service schedules that are controlled administratively. A state-based schedule defines when a service is available or unavailable.
For example, you could configure a schedule to provide a service at 5 Mbps from 8 AM to 4 PM and another service at 2 Mbps from 3:45 PM to 8:15 AM. The time overlap ensures that one of the services is available at transition time.
You create state-based service schedules from:
- Enterprise Manager Portal—Service providers make
schedules available to IT managers in enterprises. IT managers can
then configure service schedules for their enterprises.
See the SRC PE Sample Applications Guide.
- An application that uses the CORBA remote API—You
can incorporate service schedules, including schedules that affect
subscriber sessions, in an application that has been created with
the CORBA remote API, such as a residential portal.
Note: The only way to associate a session with a service schedule is through the CORBA remote API.
For information about the residential portal, see the SRC PE Sample Applications Guide.
For information about the SAE CORBA remote API, see the documentation for the API on the Juniper Networks website at https://www.juniper.net/techpubs/software/management/src/api-index.html.
Effective Period for Service Activation or Deactivation
You can configure an effective period for a schedule rule to give subscribers an opportunity to take advantage of a scheduled action for a specified amount of time, rather than for one specific time. If users log in after a scheduled action but before the end of the effective period, they can take advantage of the service. Although similar to an action threshold, an effective period can be configured for each schedule rule, whereas the action threshold applies to all schedules on an SAE.
An effective period is active for service schedules assigned to subscribers under the subscriber tree (for example, o=Users), but not for services under the global service configuration or a defined service scope (for example, o=Services or o=Scopes).
An effective period applies to subscribers who:
- Have a service schedule that includes an effective period
- Are logging in to their subscriber session
An effective period does not apply to subscribers who are already logged in to the system.
For example, you could create a schedule that includes a scheduled event to start at 9 AM and an effective period of 2 hours; subscribers can log in between 9 AM and 11 AM and have the event take place, as shown in Figure 5.
Figure 5: Sample Effective Period

You can use effective periods rather than activate-on-login for subscriptions. If activate-on-login is configured for a subscription, we recommend that the service for the subscription not have an effective period configured.
![]() | Note: If an effective period is configured so that it overlaps with an excluded time, the scheduled event does not take place because it is within an excluded time period. To clearly define when a scheduled event can occur, do not configure an effective period to overlap with an excluded time. |
One-Time Events and Recurring Events
You can specify service schedules for numerous situations. For example, you can set up:
- A one-time event—Performs an action at a specified time; for example, activating a gold Internet service at 7:00 AM on January 1, 2006.
- A recurring event—Performs an action over a period of time at specified intervals; for example, activating a gold video service at 7:00 AM every morning.
- A working-hours service—Performs actions at specified times on Monday through Friday; for example, a gold Internet service that is activated Monday through Friday at 8:00 AM and deactivated Monday through Friday at 5:00 PM. This type of service requires two schedule entries—one that activates the service and one that deactivates the service.
Schedule Availability to Subscribers
Which subscribers a service schedule affects depends on the configuration for the schedule. Table 5 shows which subscribers are affected by a schedule.
Table 5: Schedule Availability to Service Subscribers
Schedule Configured | Applies to These Subscribers |
---|---|
Service | All subscribers to that service |
Scope | All subscribers to the specified service in that scope |
Retailer | Any subscriber subordinate to the retailer for whom the service schedule is configured |
Subscriber | The subscriber for whom the service schedule is configured or, in the case of enterprise subscribers, any subscribers subordinate to that subscriber |
When a service provider or IT manager creates a schedule and attaches it to a service, the service schedule can be assigned to enterprise subscribers or residential subscribers. In some instances, subscribers can also create their own service schedules. When the scheduled action occurs, it applies to subscribers who are logged in and have a subscription to the scheduled service.
Schedule Exclusions
You can also exclude specific time intervals from a service schedule. For example, you can set:
- A holiday schedule—Ignores the service schedule for a specified day; for example, for January 1.
- A promotional period—Ignores the service schedule for a specified interval; for example, a 2-week period after the start date for the promotion.
Excluded times can apply to event schedules and authorization schedules. You can create numerous exclusion intervals to specify different actions and different times.
Related Documentation
- Schedule Configuration Guidelines
- Planning Service Schedules
- Setting the Action Threshold and Preparation Time (SRC CLI)
- Associating the Authorization Plug-In with a Scheduled Service (SRC CLI)
- Adding a Service Schedule (SRC CLI)
- Authorizing Scheduled Services Overview (SRC CLI)