[Contents] [Prev] [Next] [Index] [Report an Error]

# Service Definition Examples

This section provides examples of service definition macro files. Commented text explains the parameterized values in the examples. Each example is followed by examples of RADIUS information and the CLI command that you might use to activate a subscriber service session.

## Tiered Service Example

This example creates a tiered service. A tiered service typically provides set bandwidths for both inbound and outbound traffic for a subscriber. In this example, the bandwidth values are parameterized. Also, this example assumes that QoS profile triplePlayIP and QoS parameter maxSubscBW are configured.

    !parameterizes input and output bandwidth
    <# tiered(inputBW, outputBW) #>

    <# uid := app.servicemanager.getUniqueId #>
    <# name := "SM-tiered-" $ uid #>
    <# oname := "SM-O-tiered-" $ uid #>
    classifier-list matchAll ip any any
    rate-limit-profile <# name #> one-rate
    	 committed-rate <# inputBW; '\n' #>

    policy-list <# name; '\n' #>
    	 classifier-group matchAll precedence 10000
    		 rate-limit-profile <# name; '\n' #>
    		 traffic-class best-effort

    policy-list <# oname; '\n' #>
    	 classifier-group matchAll precedence 10000
    		 traffic-class best-effort

    profile <# name; '\n' #>
    	 ip policy secondary-input <# name #> statistics enabled merge
    	 ip policy output <# oname #> statistics enabled merge
    	 qos-profile triplePlayIP
    	 qos-parameter maxSubscBW <# outputBW; '\n' #>

    <# env.setResult("activate-profile", name) #>
    <# env.setResult("secondary-input-stat-clacl", "matchAll") #>
    <# env.setResult("output-stat-clacl", "matchAll") #>

    <# endtmpl #>

Sample RADIUS Attributes

RADIUS Attribute | Tag | Value
--- | --- | ---
username | none | client1@isp1.com
activate-service | 1 | tiered(1280000, 5120000)

`

`

Sample CLI Command

`

host1(config)#service-management subscriber-session client1@isp1.com interface atm 4/0.1 service-session “tiered(1280000, 5120000)”

`

## Video-on-Demand Service Definition Example

The following example shows a sample service definition macro file that creates a video-on-demand service—the service provides bandwidth that meets the needs of video streams. The definition creates the bandwidth towards the subscriber and parameterizes the source of the video feed.

The sample CLI command shows an example of the service-management owner-session command that you can use to activate the service session.

    !parameterizes download bandwidth and server address
    <# videoMin(downloadBW, serverAddress) #>

    <# uid := app.servicemanager.getUniqueId #>
    <# name := "SM-video-" $ uid #>

    classifier-list <# name #> ip any <# serverAddress #> 0.0.0.0

    policy-list <# name; '\n' #>
    	  classifier-group <# name #> precedence 5000
    		  traffic-class video

    profile <# name; '\n' #>
    	  ip policy output <# name #> statistics enabled merge
    	  qos-parameter maxVideoBW add <# downloadBW; '\n' #>
    	  exit

    <# env.setResult("activate-profile", name) #>
    <# env.setResult("output-stat-clacl", name) #>

    <# endtmpl #>

Sample Owner ID

Owner | Owner ID | Value
--- | --- | ---
AAA (RADIUS) | Acct-Session-ID (RADIUS attribute 44) | 573498

Sample CLI Command

`

host1(config)#service-management owner-session aaa 573498 service-session “ videoMin(4500000, 192.168.23.58)”

`

## Voice-over-IP Service Definition Example

This example provides a voice-over-IP service. The service is a session border controller (SBC) media gateway (MG)-based service that has upstream and downstream components.

The IP address and port for both the subscriber and the opposite end of the phone call were originally negotiated with the SBC. The VoIP service learns the IP addresses and ports for both ends of the call, and then specifies that any traffic to either end is put in the voice traffic class.

    !parameterizes source address and port, destination address and port, and protocol type
    <# mgFlow(upDA, upDPort, downDA, downDPort, protType) #>

    <# uid := app.servicemanager.getUniqueId #>
    <# name := "SM-mgFlow-" $ uid #>
    <# oname := "SM-O-mgFlow-" $ uid #>

    classifier-list <# name #> <# protType #> any <#upDA #> 0.0.0.0 eq <# upDPort; '\n' #>
    policy-list <# name; '\n' #>
    	  classifier-group <# name #> precedence 2000
    		  traffic-class voice
    		  forward

    classifier-list <# oname #> <# protType #> any <#downDA #> 0.0.0.0 eq <# downDPort; '\n' #>
    policy-list <# oname; '\n' #>
    	  classifier-group <# oname #> precedence 2000
    		  traffic-class voice
    		  forward

    profile <# name ; '\n' #>
    	  ip policy input <# name #> statistics enabled merge
    	  ip policy output <# oname #> statistics enabled merge

    <# env.setResult("activate-profile", name) #>

    <# endtmpl #>

Sample RADIUS Attributes

RADIUS Attribute | Tag | Value
--- | --- | ---
username | none | client1@isp1.com
activate-service | 1 | mgFlow(10.10.10.10, 1234, 192.168.45.54, 1234, udp)

`

`

Sample CLI Command

`

host1(config)#service-management subscriber-session client1@isp1.com interface atm 4/0.1 service-session “mgFlow(10.10.10.10, 1234, 192.168.45.54, 1234, udp)”

`

## Guided Entrance Service Example

The guided entrance service enables you to create a controlled Internet browsing environment. Guided entrance-based services, which are sometimes called walled gardens or captive portals, are becoming increasingly important offerings for service providers. When a subscriber logs in and opens a Web browser, the Service Manager guided entrance service transparently directs the subscriber to a specific Web site—at that Web site, the subscriber is presented with a selection of possible services to use. For example, a subscriber might be shown a Web site that offers services such as:

- Predefined services—A group of user-selectable services that meets a variety of needs of a single subscriber. The subscriber might select the high-priced highest access speed to perform critical financial transactions but select a lower speed (and lower cost) service for e-mail. For viewing a real-time sports event, the subscriber can select the video-on-demand service. The subscribers have control over the choice and cost of the services they need and use.
- Prepaid services—A group of specific services that have been prepaid by the subscriber. For example, a subscriber who has purchased the sports package service is presented with a Web page that lists the currently available sporting events. Or, a subscriber might prepay a VoIP service for a set amount of time.
- Controlled-service— An educational service that enables students at a school to access authorized research sites. Or, a limited service for young children that restricts access to safe, closely monitored, age-appropriate Web sites.

Figure 30 shows the sequence of actions that take place during a guided entrance service.

Figure 30: Guided Entrance

Service Manager requires additional configuration considerations for the guided entrance service.

- The <# redirectUrlName := "http://" $ serverIp $ ":" $ serverPort #> command in the service definition—Specifies the HTTP local service to which the subscriber is redirected after login. See Guided Entrance Service Definition Example for a sample guided entrance service definition.

  | Note: You must also configure a policy that redirects packets. See Creating an Exception Rule within a Policy Classifier Group in JUNOSe Policy Management Configuration Guide for information on creating redirect policies.

- HTTP local server application—Used by the policy in the activated service to direct a subscriber to a specific Web site when the subscriber logs in. See Configuring the HTTP Local Server to Support Guided Entrance for information about the HTTP local server.
- RADIUS Dynamic Request Server and CoA messages—Enables RADIUS to dynamically activate the new service that the subscriber selects at the Web site. Can also optionally deactivate the original guided entrance service session that is used when the subscriber logs in. See Configuring RADIUS Dynamic-Request Server.

### Guided Entrance Service Definition Example

This example shows a guided entrance service. Upon login, the subscriber is redirected to a specific uniform resource locator (URL) at which the subscriber can choose from a list of available services.

    !parameterizes server address and port
    <# http(serverIp, serverPort) #>

    <# serviceTag := "http-" #>
    <# uid := app.servicemanager.getUniqueId #>
    <# genericName := "SM-X-" $ serviceTag $ uid #>
    <# genericInputName := "SM-I-" $ serviceTag $ uid #>
    <# genericOutputName := "SM-O-" $ serviceTag $ uid #>
    <# claclName := genericName #>

    <# profileName := genericName #>
    <# inputPolicyName := genericInputName #>
    <# inputRateLimitName := genericInputName #>
    <# outputPolicyName := genericOutputName #>
    <# outputRateLimitName := genericOutputName #>

    <# exceptionClaclName := "exceptionClaclPort" $ serverPort #>
    <# serverClaclName := "serverClaclIp" $ serverIp #>
    <# redirectUrlName := "http://" $ serverIp $ ":" $ serverPort #>

    configure terminal

    classifier-list <# serverClaclName #> ip any host <# serverIp; '\n' #>

    classifier-list <# exceptionClaclName #> tcp any any eq <# serverPort; '\n' #>

    ip policy-list <# inputPolicyName; '\n' #>
    classifier-group <# serverClaclName; '\n' #>
            forward
        classifier-group <# exceptionClaclName; '\n' #>
            exception http-redirect
        classifier-group *
            filter

    profile <# profileName #>
        ip http redirectUrl <# redirectUrlName; '\n' #>
        ip policy input <# inputPolicyName #> statistics enabled merge

    <# env.setResult("activate-profile", "" $ profileName) #>

    <# endtmpl #>

Sample RADIUS Attributes

RADIUS Attribute | Tag | Value
--- | --- | ---
username | none | client5@isp1.com
activate-service | 1 | http(192.168.25.2, 80)

`

`

Sample CLI Command

`

host1(config)#service-management subscriber-session client5@isp1.com interface atm 5/0.1 service-session “ http(192.168.25.2, 80)”

`

### Using CoA Messages with Guided Entrance Services

Typically, a guided entrance service directs a subscriber to a Web site, where the subscriber can select from a group of available services. When the subscriber selects a new service to use, Service Manager uses a RADIUS CoA message to activate the new service—you can also configure RADIUS to deactivate the original guided entrance service. To inform Service Manager to deactivate the original guided entry service, you must include the Deactivate-Service attribute in the RADIUS records of the services that can be selected from the Web site.

If you configure a guided entrance service, you must also ensure that the router’s RADIUS dynamic-request server is enabled and supports CoA messages. See Configuring RADIUS Dynamic-Request Server, for information about the RADIUS dynamic-request server and CoA messages.

Table 148 describes a partial RADIUS Access-Accept message for a guided entrance service and the CoA-Request message for the tiered service that the subscriber subsequently selects from the Web site. The CoA message for the tiered service includes the Deactivate-Service attribute that deactivates the guided entrance service.

Table 148: Deactivating a Guided Entrance Service

Guided Entrance Service Activated at Login |  |
--- | --- | ---
RADIUS Attribute | Tag | Value
username | none | client5@isp1.com
activate-service | 1 | http(192.168.25.2, 80)

Tiered Service Selected at Web Site

RADIUS Attribute | Tag | Value
--- | --- | ---
username | none | client5@isp1.com
activate-service | 2 | tiered(1280000, 5120000)
deactivate-service |  | http(192.168.25.2, 80)
service-timeout | 2 | 720
service-statistics | 2 | 2

### Configuring the HTTP Local Server to Support Guided Entrance

JUNOSe software supports an embedded Web server, known as the HTTP local server, which is used to support the Service Manager application’s guided entrance service. With guided entrance, subscribers are directed to a specific Web site when they log in. At the Web site, the subscribers can then select the service they want to use. You can configure one HTTP local server per virtual router. The HTTP local server is disabled by default.

In lower-numbered releases, the HTTP server listened for and processed only IPv4 exception packets. You can now configure the HTTP local server to listen for and process both IPv4 and IPv6 packets.

| Note: Currently, the HTTP local server does not support two different ports for IPv4 and IPv6 packets. However, the HTTP local server can listen for both IPv4 and IPv6 exception packets on the same port, simultaneously.

To configure the HTTP local server to support guided entrance for IPv4:

1. Access the virtual router context.
   `
   host1(config)#virtual-router west400
   host1:west400(config)#
   `
2. Create the HTTP local server.
   `
   host1:west40(config)#ip http
   `
3. (Optional) Specify a standard IP access list that defines which subscribers can connect to the HTTP local server.
   `
   host1:west40(config)#ip http access-class chicagoList
   `
4. (Optional) Specify the port on which the HTTP local server receives connection attempts.
   `
   host1:west40(config)#ip http port 8080
   `
5. (Optional) Specify the maximum number of connections that can exist between one IP address and the HTTP local server.
   `
   host1:west40(config)#ip http same-host-limit 20
   `
6. Specify the maximum time that HTTP local servers maintain connections.
   `
   host1:west40(config)#ip http max-connection-time 1000
   `
7. Enable the HTTP local server to listen for and process IPv4 exception packets
   `
   host1:west40(config)#ip http server
   `
8. Configure the HTTP redirect feature for the profile, interface, or subinterface that will be referenced in the guided entrance service definition.
   `
   host1:west40(config)#profile guidEnt6
   host1:west40(config-profile)#ip http redirectUrl http://ispsite.redirect.com
   `

To configure the HTTP local server to support guided entrance for IPv6:

1. Access the virtual router context.
   `
   host1(config)#virtual-router west400
   host1:west400(config)#
   `
2. Create the HTTP local server.
   `
   host1:west40(config)#ipv6 http
   `
3. (Optional) Specify a standard IP access list that defines which subscribers can connect to the HTTP local server.
   `
   host1:west40(config)#ip http access-class chicagoList
   `
4. (Optional) Specify the port on which the HTTP local server receives connection attempts.
   `
   host1:west40(config)#ipv6 http port 8080
   `

   | Note: You can modify the port on which the HTTP local server receives connection attempts. However, you must first disable the HTTP local server and then modify the port.

5. (Optional) Specify the maximum number of connections that can exist between one IP address and the HTTP local server.
   `
   host1:west40(config)#ip http same-host-limit 20
   `
6. Specify the maximum time that HTTP local servers maintain connections.
   `
   host1:west40(config)#ip http max-connection-time 1000
   `
7. Enable the HTTP local server to listen for and process IPv6 exception packets.
   `
   host1:west40(config)#ipv6 http server
   `
8. Configure the HTTP redirect feature for the IPv6 interface or subinterface to be referenced in the guided entrance service definition.
   `
   host1:west40(config)#interface gigabitEthernet 6/0
   host1:west40(config-if)#ipv6 http redirectUrl http://ispsite.redirect.com
   `

#### HTTP Local Server Commands

This section describes the commands used to configure the HTTP local server application for IPv4 and IPv6 on the E-series router.

ip http

- Use to create the HTTP local server for IPv4.
- Example
  `
  host1(config)#ip http
  `
- Use the no version to delete the HTTP local server.
- See ip http

ip http access-class

- Use to allow only subscribers on the specified standard IP access list to connect to the HTTP local server.
- Example
  `
  host1(config)#ip http access-class chicagoList
  `
- Use the no version to remove the association between the access list and the HTTP local server.
- See ip http access-class

ip http max-connection-time

- Use to specify the maximum time that the HTTP local server maintains an inactive connection.
- Specify a time in the range 3–7200 seconds, or 0. A value of 0 causes the server to maintain an inactive connection indefinitely.
- Example
  `
  host1(config)#ip http max-connection-time 1000
  `
- Use the no version to restore the default time, 30 seconds.
- See ip http max-connection-time

ip http port

- Use to specify the port on which the HTTP local server receives connection attempts for IPv4 exception packets.
- Specify a port number in the range 1–65535.
- Example
  `
  host1(config)#ip http port 8080
  `
- Use the no version to restore the default port number, 80.
- See ip http port

ip http redirectUrl

- Use to specify the URL to which a subscriber’s HTTP access session is redirected.
- The first access session is typically used by the Service Manager application to provide initial provisioning and service selection for the subscriber.
- HTTP redirect is per-interface; use the command in Profile Configuration mode for dynamic interfaces; use the command in Interface Configuration mode or Subinterface Configuration mode for static interfaces.
- The redirect URL can be a maximum of 64 characters.

  | Note: The HTTP local server must be configured and enabled in the virtual router for the interface on which you use the ip http redirectUrl command. Otherwise, the URL redirect operation will fail.

- Example
  `
  host1(config-if)#ip http redirectUrl http://ispsite.redirect.com
  `
- Use the no version to restore the default, which disables the HTTP redirect feature.
- See ip http redirectUrl

ip http same-host-limit

- Use to specify the maximum number of connections that can exist between one IP address and the HTTP local server.
- Specify a number in the range 0–1000.
- Example
  `
  host1(config)#ip http same-host-limit 20
  `
- Use the no version to restore the default number of allowed connections, 3.
- See ip http same-host-limit

ip http server

- Use to enable the HTTP local server to listen for and process IPv4 exception packets.
- Example
  `
  host1(config)#ip http server
  `
- Use the no version to disable the HTTP local server.
- See ip http server

ipv6 http

- Use to create the HTTP local server to listen and process for IPv6 exception packets.
- Example
  `
  host1(config)#ipv6 http
  `
- Use the no version to delete the HTTP local server.
- See ipv6 http.

ipv6 http port

- Use to specify the port on which the HTTP local server receives connection attempts for IPv6 exception packets.

  | Note: You can modify the port on which the HTTP local server receives connection attempts. However, you must first disable the HTTP local server and then modify the port.

- Specify a port number in the range 1–65535.
- Example
  `
  host1(config)#ipv6 http port 8080
  `
- Use the no version to restore the default port number, 80.
- See ipv6 http port.

ipv6 http redirectUrl

- Use to specify the URL to which a subscriber’s HTTP access session is redirected.
- The first access session is typically used by the Service Manager application to provide initial provisioning and service selection for the subscriber.
- HTTP redirect is per-interface; use the command in Interface Configuration mode or Subinterface Configuration mode for static interfaces.
- The redirect URL can be a maximum of 64 characters.

  | Note: The HTTP local server must be configured and enabled in the virtual router for the interface on which you use the ipv6 http redirectUrl command. Otherwise, the URL redirect operation will fail.

- Example
  `
  host1(config-if)#ipv6 http redirectUrl http://ispsite.redirect.com
  `
- Use the no version to restore the default, which disables the HTTP redirect feature.
- See ipv6 http redirectUrl.

ipv6 http server

- Use to enable the HTTP local server to listen for and process IPv6 exception packets.
- Example
  `
  host1(config)#ipv6 http server
  `
- Use the no version to disable the HTTP local server.
- See ipv6 http server.

## Combined IPv4 and IPv6 Service in a Dual Stack Example

When you configure a combined IPv4 and IPv6 service in a dual stack, the policies defined in the interface profile are attached to the appropriate interfaces based on the type of the interface. For example, all IPv4 policies are attached to the IPv4 interface and all IPv6 policies are attached to the IPv6 interface.

Figure 31 shows a topology in which the C-VLAN interface on the customer edge device is connected to the ingress IPv4 and IPv6 interfaces on the provider edge or E-series router. A combined IPv4/IPv6 service, which contains a hierarchical policy and an external parent group with a rate-limit profile that is associated with the hierarchical policy, is applied at the secondary input stage on the router. The incoming voice-over-IP classified traffic flows for IPv4 and IPv6 subscribers are allocated a total of 64 Kbps. The common rate limit cannot drop voice-over-IP packets, but must limit the total flow (for IPv4 and IPv6 interfaces) to 64 Kbps.

Figure 31: Input Traffic Flow with Rate-Limit Profile on an External Parent Group for a Combined IPv4/IPv6 Service

Similarly, for traffic flowing from the provider edge device to the C-VLAN interface for voice-over-IP packets, Figure 32 shows how the rate-limit profile in the external parent group associated with a hierarchical policy parameter applied to the egress IPv4 and IPv6 interfaces limits the voice-over-IP traffic flowing to the C-VLAN interface on the customer edge device.

Figure 32: Output Traffic Flow with Rate-Limit Profile on an External Parent Group for a Combined IPv4/IPv6 Service

The following example shows the service macro definition file that creates a voice-over-IP service for the topology described above.

    <# combined_service(inBw, outBw, VBG1, VB6G1, NODE) #>

    <# uid := app.servicemanager.getUniqueId #>
    <# genericName := "combined-service-" $ uid #>
    <# SAClaclName := genericName $ "SA" #>
    <# profileName := genericName #>

    policy-parameter v4v6-<# uid #> hierarchical
     aggregation-node <# NODE #><# '\n' #>

    rate-limit-profile rlpv4v6-<# genericName #>-vb-out one-rate hier
    committed-rate <# outBw #><# '\n' #>
    committed-action transmit unconditional
    conformed-action transmit unconditional

    rate-limit-profile rlpv4v6-<# genericName #>-vb-in one-rate hier
    committed-rate <# inBw #><# '\n' #>
    committed-action transmit unconditional
    conformed-action transmit unconditional

    parent-group vb-v4v6-<# uid #>-in
     rate-limit-profile rlpv4v6-<# genericName #>-vb-in

    parent-group vb-v4v6-<# uid #>-out
     rate-limit-profile rlpv4v6-<# genericName #>-vb-out

    classifier-list cl46-4-<# genericName #>-vb-in ip any host <# VBG1 #> <# '\n' #>
    classifier-list cl46-4-<# genericName #>-vb-out ip host <# VBG1 #> any

    ipv6 classifier-list cl46-6-<# genericName #>-vb-in destination-host <# VB6G1 #><# '\n' #>
    ipv6 classifier-list cl46-6-<# genericName #>-vb-out source-host <# VB6G1 #><# '\n' #>

    ip policy-list pl-v4v6-<# genericName #>-in
     classifier-group cl46-4-<# genericName #>-vb-in external parent-group vb-v4v6-<# uid #>-in parameter v4v6-<# uid #><# '\n' #>
      forward

    ip policy-list pl-v4v6-<# genericName #>-out
     classifier-group cl46-4-<# genericName #>-vb-out  external parent-group vb-v4v6-<# uid #>-out parameter v4v6-<# uid #><# '\n' #>
      forward

    ipv6 policy-list pl6-v4v6-<# genericName #>-in
     classifier-group cl46-6-<# genericName #>-vb-in external parent-group vb-v4v6-<# uid #>-in parameter v4v6-<# uid #><# '\n' #>
      forward

    ipv6 policy-list pl6-v4v6-<# genericName #>-out
     classifier-group cl46-6-<# genericName #>-vb-out external parent-group vb-v4v6-<# uid #>-out parameter v4v6-<# uid #><# '\n' #>
      forward

    profile <# profileName #><# '\n' #>
     ip policy output pl-v4v6-<# genericName #>-out statistics enabled merge
     ip policy secondary-input pl-v4v6-<# genericName #>-in statistics enabled merge
     ipv6 policy output pl6-v4v6-<# genericName #>-out statistics enabled merge
     ipv6 policy secondary-input pl6-v4v6-<# genericName #>-in statistics enabled merge

    <# env.setResult("activate-profile", profileName) #>
    <# env.setResult("service-interface-type", "ipv4-ipv6") #>
    <# env.setResult("secondary-input-stat-epg", "vb-v4v6-"$ uid $"-in v4v6-"$ uid $"") #>
    <# env.setResult("output-stat-epg", "vb-v4v6-"$ uid $"-out v4v6-"$ uid $"") #>
    <# endtmpl #>

In the service definition macro, a hierarchical policy parameter for the rate limit is created with an aggregation node value. The aggregation node stores a single rate-limit instance and statistics for this rate-limit. An external rate-limit aggregation node can be defined by the 4-tuple (slot, direction, external parent group name, parameter value). Each reference to a policy parameter in a policy is substituted with its value for all attachments of this policy at the interface.

Two rate-limit profiles are created, one each for the ingress and egress interfaces. Rate limiters are implemented using a dual token bucket scheme: a token bucket for conformed (yellow) packets and a token bucket for committed (green) packets. The following are the attributes configured in the rate-limit profile applied to ingress and egress interfaces:

- The committed rate for the rate-limit profile is entered as a specified value.
- The committed action, which specifies the action for packets conforming to the committed rate and committed burst size and conforming to the exceed rate and exceed burst size for a rate-limit profile is set to receive transmit unconditional.
- The conformed action, which sets the action for packets not conforming to the committed rate and committed burst size, but conforming to the peak rate and peak burst size for a rate-limit profile is set to receive transmit unconditional.

Two external parent groups, one each for the ingress and egress interfaces, that reference the rate-limit profiles created for incoming and outgoing traffic, are created and specified in the service definition.

Classifier control lists for ingress IPv4 and IPv6 traffic, and for egress IPv4 and IPv6 traffic, are also created. These classifiers classify traffic based on source and destination addresses.

The input and output classifier lists for IPv4 traffic are used in IP policy lists that are attached to the ingress and egress IPv4 interfaces respectively. The input and output classifier lists for IPv6 traffic are used in IPv6 policy lists that are attached to the ingress and egress IPv6 interfaces respectively. The external parent-group keyword creates an external parent group in a rate-limit hierarchy for IPv4 and IPv6. All packets matching the classifier are sent to the parent group for further processing.

The policy lists for voice-over-IP traffic are configured in the service definition macro file that creates a combined IPv4/IPv6 service to be applied to the ingress IPv4 and IPv6 interfaces.

A profile is created that you want to attach to the service session. The IPv4 and IPv6 policies for voice-over-IP traffic arriving at the IPv4 and IPv6 interfaces respectively are applied to the secondary input stage. The IPv4 and IPv6 policies for voice-over-IP traffic leaving the IPv4 and IPv6 interfaces respectively are applied to the output stage. Statistics collection is enabled for the policies referenced in the service macro using the statistics enabled keyword in the command used for policy attachment in the profile. The merge keyword enables merging of multiple policies to form a single policy.

The <# env.setResult("activate-profile", profileName) #> command specifies the interface profile to be used on activation of the interface. After the subscriber service session is activated, the policies defined in the interface profile are applied to both IPv4 and IPv6 interfaces. The elements in the profile to be attached to the interfaces are determined by the type of the interface.

The <# env.setResult("service-interface-type", "ipv4-ipv6") #> command configures the service macro to be used for IPv4 and IPv6 interfaces in a dual stack. The profile identifier returned from the activate-profile object will be applied to both IPv4 and IPv6 interfaces.

The service definition macro is configured to collect input and output statistics associated with external parent groups in a hierarchical policy for IPv4 and IPv6 subscribers as follows:

`

<# env.setResult("secondary-input-stat-epg", "vb-v4v6-"$ uid $"-in v4v6-"$ uid $"") #>
<# env.setResult("output-stat-epg", "vb-v4v6-"$ uid $"-out v4v6-"$ uid $"") #>

`

The <# env.setResult("secondary-input-stat-epg", "vb-v4v6-"$ uid $"-in v4v6-"$ uid $"") #> command specifies that Service Manager track statistics associated with the external parent group named vb-v4v6-in and the corresponding hierarchical policy named v4v6, and that this external parent group is associated with the policy that is attached at the input stage.

The <# env.setResult("output-stat-epg", "vb-v4v6-"$ uid $"-out v4v6-"$ uid $"") #> command specifies that Service Manager track the output statistics associated with the external parent group named vb-v4v6-out and the corresponding hierarchical policy named v4v6, which is associated with the policy attached at the output stage.

The input and output statistics associated with the external parent group are collected and forwarded to the Service Manager to be displayed in the Acct-Stop and Interim-Acct messages.

If you use the secondary-intput-stat-clacl and output-stat-clacl objects in the service macro to track Service Manager statistics, the values returned in the output of the show service-management command do not accurately reflect the packets that are rate-limited. In this case, although some of the packets that were classified by the classifier lists are dropped by the rate-limiter on the external parent group, the Service Manager statistics collection application counts all the packets that were classified without excluding those that were dropped by the rate limiter. As a result, the values returned by the output-stat-clacl and secondary-input-stat-clacl objects represent more packets than those sent to the subscriber and core interfaces respectively.

Using the macro that has been described here, you can configure the following combined service, for example:

combined_service(64000, 64000, 10.0.0.1, 2001::1, vlan)

where

- 64000—Bandwidth for outbound traffic, denoted as outBw in the macro
- 64000—Bandwidth for inbound traffic, denoted as inBw in the macro
- 10.0.0.1—Host IP address for IPv4 subscribers, denoted as VBG1 in the macro
- 2001::1—Host IP address for IPv6 subscribers, denoted as VB6G1 in the macro
- vlan—Interface on which the service is configured, denoted as NODE in the macro

[Contents] [Prev] [Next] [Index] [Report an Error]