Deploying Vista – Part 6: Using Windows SIM

This series of articles on automating the deployment of Windows Vista to desktop computers continues by looking at how to use the Windows System Image Manager (Windows SIM) tool to create and edit answer files.

Examining Windows SIM

As Figure 1 shows, the Windows SIM user interface has five separate panes:

Figure 1: The Windows SIM user interface

The five panes of Windows SIM server the following purposes:

• Distribution Share – This pane displays the currently opened distribution share. You also use this pane to create new distribution shares, add items to the share, and close an open share.
• Windows Image – This pane displays the currently opened Windows Image (.wim) file. As we’ll see soon, you must open a .wim file before you can create an answer file.
• Answer File – This pane is where you create a new answer file and add components (groups of operating system settings) and packages (includes software updates, language packs, and so on) to your answer file.
• Properties – This pane lets you assign values to the component or package that is currently selected in your Answer File pane.
• Messages – This pane displays errors, warnings and information messages concerning the syntax and structure of your answer file when you try and validate your answer file.

The simplest way to see how to use Windows SIM is to create a small answer file using this tool, so let’s do this now. The steps we’ll follow are these:

1. Open a Windows Image file
2. Create a new answer file
3. Add a component to your answer file
4. Configure the component you just added
5. Validate your answer file

Opening a Windows Image file

Begin by copying the Install.wim file (the default install image) from your Windows Vista with Service Pack 1 Enterprise Edition product DVD to a folder such as W:\Sources\Vista Enterprise on a hard drive of your technician computer. Then open Windows SIM by clicking Start, All Programs (or Programs), Microsoft Windows AIK, Windows System Image Manager.

Now, in the Window Image pane, right-click on “Select a Windows image or catalog file” and choose Select Windows Image from the shortcut menu to open the Select A Windows Image dialog box. Browse to your W:\Sources\Vista Enterprise SP1 folder and double-click on the Install.wim file to open the Windows image file in Windows SIM. If a catalog file can’t be found for the image file, a dialog box will prompt you to create a new catalog file:

Figure 2: Creating a new catalog file for a Windows image (Install.wim) file

A catalog file is a binary file containing a description of all the various components and packages in a Windows image. By working directly with catalog files instead of the image files themselves, Windows SIM can display components and packages more quickly. Clicking Yes in the above dialog box will cause Windows SIM to mount the image, process its contents (this takes a few minutes) and then display configurable settings for components and packages contained within the image.

Once the catalog file has been generated, Windows SIM now looks like this:

Figure 3: Opening a Windows image (Install.wim) file in Windows SIM

Creating a new answer file

Next we’ll create a new answer file for deploying Windows Vista SP1. To do this, in the Answer File pane, right-click on “Create or open an answer file” and choose New Answer File from the shortcut menu. A new answer file is created with no components in it:

Figure 4: Creating a new answer file

Notice what you see in the Answer File pane under Components? The seven configuration passes used by Windows Setup! (Refer back to Part 3 of this series if you need to refresh your memory concerning what configuration passes are.)

It’s instructive to examine the XML syntax of this new, unconfigured answer file. To do this, let’s first save the answer file using the filename autounattend.xml. To do this, make sure the root node (“Untitled”) of your answer file is selected, and then choose Save Answer File from the File menu. Browse to somewhere on your hard drive where you want to store your answer file and save the file. Then open the autounattend.xml file you just created using Notepad, and here’s what it should look like:

Deploying Vista – Part 7: Creating a Minimal Answer File

This series of articles on automating the deployment of Windows Vista to desktop computers continues by walking you through creating a basic answer file for unattended deployment of Vista.

In the previous article of this series, we looked at Windows System Image Manager (Windows SIM), a key tool of the Windows Automated Installation Kit (Windows AIK) that you use to create and configure answer files for automated deployment of Windows Vista. In that article, we learned how to use Windows SIM to create, configure, validate and save answer files. This present article and the next two articles in this series will walk you through the steps of creating a simple answer file you can use to perform a completely unattended installation of Windows Vista onto bare-metal systems using the Unattended Install From DVD deployment method. The answer file we will create will be a bare-bones one, that is, the minimal answer file you need to completely automate Vista deployments. In future articles we’ll examine additional answer file settings you can configure to automate other aspects of Vista deployment.

Specifying Regional and Language Options

Start by selecting and opening the Install.wim file of the version of Vista you want to deploy by following the procedure outlined in the previous article of this series. In this walkthrough, I’ll be using the 32-bit US English version of Windows Vista SP1 Enterprise Edition. Once the image file is open, create a new answer file by selecting New Answer File from the File menu.

Now we’re ready to begin adding components to our answer file. In the Windows Image pane, expand the Components node and select the Microsoft-Windows-International-Core-WinPE node beneath it. Then right-click on the Microsoft-Windows-International-Core-WinPE node and select Add Setting to Pass 1 windows PE to add this component to the windowPE pass for your answer file. Now in the Properties pane, type values for the various settings of this component as indicated by the following table:

Setting	Value
InputLocale	en-us
Layered Driver
SystemLocale	en-us
UILanguage	en-us
UILanguageFallback	en-us
UserLocale	en-us

The result should look like this (Figure 1):

Figure 1: Configuring regional and language settings.

What we’ve done up to this point is to specify answer file settings for the default language and locale for Windows Setup. The following table describes the settings we’ve just configured in more detail:

Setting	Description
InputLocale	Keyboard layout and system input locale
Layered Driver	Optional—used only for Japanese and Korean keyboards
SystemLocale	Default language for Windows Setup
UILanguage	Default system user interface language
UILanguageFallback	Fallback language if UILanguage is not fully localized
UserLocale	Locale to use for dates, times, currency and numbers

We’re not quite through however as there’s another answer file component we need to specify to finish configuring user locale and language settings. Here’s what to do next: in the Answer File pane, expand the Microsoft-Windows-International-Core-Win PE node and select the Setup UILanguage node beneath it. Then in the Properties pane, click in the box to the right of the UILanguage setting and type en-us as the value for this setting (see Figure 2):

Figure 2: Configuring regional and language settings (continued)

I’m not sure why you need to specify UILanguage in two places like this, but you need to.

Accepting the EULA

Next we’re going to specify the answer file setting that will automatically accept the EULA. In the Windows Image pane, under Components, find the Microsoft-Windows-Setup node and expand it to display the user data node beneath it. Then right-click on the user data node and select Add Setting to Pass 1 windows PE to add this component to the window PE pass for your answer file. Click the box to the right of the AcceptEula setting to display a drop-down arrow, then click the arrow and select True. The result should look like this (Figure 3):

Figure 3: Configuring the setting to accept the EULA

Tip: If you’re deploying a retail version of Windows Vista (such as Windows Vista Business edition) instead of the volume-licensed Enterprise edition, you’ll also need to specify your product key at this point. To do that, expand the Microsoft-Windows-Setup\UserData node in the Answer File pane to display the ProductKey node beneath it, and they type your 29 character product key (you must include the dashes) in the box beside the Key setting in the Properties pane.

Creating a New Primary Partition

Next, we need to prepare the hard disk on our computer so it will be ready to install Vista onto it. We’re assuming in this article that we’re deploying Vista onto bare-metal, that is, onto a hard drive that is unpartitioned and therefore has no existing volumes on it. We’re also assuming that our target system has only one hard drive in it. This means we have to configure our answer file to create a new primary partition, set it as the active partition, and format it using NTFS. Here’s how we do this:

First, add the Microsoft-Windows-Setup\disk configuration\Disk component to the windows PE configuration pass of your answer file, and in the Properties pane, set the value of disk id to the number 0 (see Figure 4):

Figure 4: Selecting disk 0 in order to create a new partition on it

Next, add the Microsoft-Windows-Setup\DiskConfiguration\Disk\CreatePartitions\CreatePartition node to the windowsPE configuration pass of your answer file, and in the Properties pane, configure the settings shown in the figure below to create a new primary partition of size 50 GB (see Figure 5):

Figure 5: Creating a new primary partition on the selected disk

Tip: If you want your new partition to fill up your entire hard drive, set the Extend setting to True and don’t specify a value for the Size setting.

Now we have to mark our new partition (partition 1) as active and format it using NTFS. To do this, add the Microsoft-Windows-Setup\DiskConfiguration\Disk\ModifyPartitions\ModifyPartition node to the windowsPE configuration pass of your answer file, and in the Properties pane, configure the settings shown in Figure 6 below:

Figure 6: Setting the new partition as active and formatting it using NTFS

Note that we also had to specify the Order setting in the above figure—this is required.

Specifying the Target Partition

Now we’re ready to tell Windows Setup which disk partition we want to install Vista onto. To specify where you want to install the image, add the Microsoft-Windows-Setup\DiskConfiguration\ImageInstall\OSImage\InstallTo node to the windowsPE configuration pass of your answer file, and in the Properties pane, configure the settings shown in Figure 7 below:

Figure 7: Specifying that Windows Setup will install Vista onto partition 1 of disk 0

Validating and Saving the Answer File

At this point let’s select Validate Answer File from the Tools menu and check for any error or warning events that are displayed in the Messages pane (only informational events should be displayed, and those you can safely ignore). Now save your answer file using the filename autounattend.xml in the root folder of a USB flash drive. Why name it autounattend.xml? And why save it onto a flash drive? You’ll find out in the next article of this series!

and so on. We’ll continue this in the next article of this series.

Deploying Vista – Part 8:Unattended Install from DVD Method

Windows Setup and Answer Files

In the second and third articles of this series, we examined how Windows Setup works and described the three phases of Setup and the seven configuration passes associated with Setup. When you run Windows Setup (setup.exe) to install Vista, you can do it with or without an answer file. Automated deployment of Vista requires using an answer file, and Setup.exe can use answer files in two ways: explicitly or implicitly. Let’s look at these two ways of specifying an answer file.

Explicit Answer File

You can explicitly specify an answer file when you run Setup.exe by using the /unattend switch. For example, if you run Setup from over the network and you have your answer file on one network share and your Vista installation files on another, you could launch Windows Setup by running the command setup /unattend:unattend.xml where unattend.xml is the name of your answer file. Of course, running a command like this from your destination computer means you need some operating system from which to install it, and long ago when Windows 95/98/2000 were used, this typically meant booting your destination computer using a network boot floppy. Or you could use setup /unattend to upgrade your existing version of Windows to a newer one. Then when Windows XP became available, OEMs and enterprise customers got to use WinPE (Windows Preinstallation Environment), a stripped-down version of Windows that you could use to boot a bare-metal system to a command prompt, connect to a network share, and start the Setup process. We’ll look at how to use Windows PE soon in a later article of this series.

Implicit Answer File

Setup.exe can also use answer files implicitly however, that is, without having to explicitly specify where you answer file is located. In fact, when Setup begins, it automatically looks in several locations in order to see whether an answer file is present, and if it finds one, it uses it to begin performing an unattended installation. Not only that, this implicit search for an answer file happens automatically at the start of every configuration pass that occurs during the Setup process including the windowsPE, offlineServicing, specialize, generalize, auditSystem, auditUser, and oobeSystem configuration passes. Finally, for this automatic implicit search for an answer file to work during the first two passes (windowsPE and offlineServicing) the answer file must be named autounattend.xml instead of the usual unattend.xml.

Here are the details: when Setup begins a configuration pass, it automatically looks for an answer file in the locations indicated in the following order:

1. In the registry in the location HKLM\System\Setup!UnattendFile
2. In the %WINDIR%\Panther\Unattend folder (but only if Setup is being launched from a previous version of Windows)
3. In the %WINDIR%\Panther folder, which is the location where Setup caches answer files. When Setup finds an answer file at the beginning of a configuration pass, it caches it in this directory so it can use this cached answer file for the remaining configuration passes provided no other answer files are found in a location of higher precedence in this search procedure.
4. In the root directory of removable media that are writable. Setup searches the root directory of each writable flash drive or floppy, in order of drive letter, until it finds an answer file.
5. In the root directory of removable media that are read-only. Setup searches the root directory of each read-only removable media, in order of drive letter, until it finds an answer file.
6. In the \Sources folder where your Vista installation files are found (windowsPE and offlineServicing passes only) and in the %WINDIR%\System32\Sysprep folder (all other passes). For the windowsPE and offlineServicing passes, your answer file must be named autounattend.xml. For all other passes, it must be named unattend.xml.
7. In %SYSTEMDRIVE% (the root of your system drive)

Performing an Unattended Install from DVD

Let’s try using the basic answer file we created in the previous article of this series and see whether it works or not. You need three things to perform your install:

• Your Windows Vista with SP1 Enterprise Edition product DVD
• Your autounattend.xml answer file saved in the root directory of a USB flash drive
• A destination computer that has no operating system installed on it

Follow these steps to install Vista using the Unattended Install From DVD method:

1. Turn on your destination computer, insert your Vista product DVD into your DVD-ROM drive, and plug your flash drive into a USB port on the computer.
2. Press CTRL+ALT+DEL to reboot your system.
3. Sit back and watch as the windowPE configuration pass launches and uses its implicit answer file search algorithm to find the autounattend.xml file in the root of your flash drive. Setup.exe then caches this answer file and uses it to automatically install Vista on your computer. During Setup, your computer will reboot twice and then you are eventually presented with the following screen (Figure 1):

Figure 1: First screen of machine OOBE

This is the first screen of the machine out-of-box-experience (OOBE), which is also called Windows Welcome, and it’s the start of a wizard that walks the user through the final steps of configuring his computer before he can log on and start using it. The screens presented by this Set Up Windows wizard require the user to perform the following tasks in the order indicated:

1. The user chooses a user name and picture. The user types a user name, a password, and a password hint. Typing a password hint is now required as of Service Pack 1 for Vista.
2. The user types a computer name and chooses a desktop background to use.
3. The user chooses an option on the Help Protect Windows Automatically page of the wizard. Typically you would select Use Recommended Settings here.
4. The user can review and modify his time and date settings including setting the time zone.
5. The user selects his computer’s current location, which can be home, work or public.
6. On the Thank You page, the user clicks Start. A message appears saying “Please wait while Windows checks your computer’s performance.” Once that is done, the logon screen appears, and the user types his password and logs on to his computer and can begin working.

What’s the point of having this machine OOBE as part of Setup? The main purpose is for OEMs who preinstall Vista on computers and then deliver these computers to customers. As a customer, you want your new computer to come with the username BoB configured when your name is Jane, or with the timezone set to Central when you live in the Pacific zone. So in a scenario where computers are being prepared for customers, some final customization steps must be left to the customer herself to perform.

But what if you’re an administrator in an enterprise however and you need to prepare a computer for a user on your network? You know the user’s name and the time zone your network is in—is there any way to automate this Windows Welcome process so that the user can just turn the computer on, log on, and get to work? Yes there is, and that’s what the next article in this series will talk about.

Throttling Bandwidth through QoS (Part 2)

The Traffic Control API

One of the biggest problems with prioritizing network traffic is that you can’t prioritize traffic based on the computer that generated it. It is very common for a single computer to run multiple applications, and for each of those applications (and the operating system) to produce its own traffic stream. When this happens, each traffic stream must be prioritized individually. After all, one application may require reserved bandwidth, while best effort delivery is fine for the other traffic streams.

This is where the Traffic Control API comes into play. The Traffic Control API is the Application Programming Interface that allows QoS parameters to be applied to individual packets. The Traffic Control API works by identifying individual traffic streams, and then applying various QoS controls to those streams.

The first thing that the Traffic Control API does is to create what is known as a filterspec. A filterspec is essentially a filter that defines what it means for a packet to belong to a particular stream. Some of the attributes used by a filterspec include the packet’s source and destination IP address, and the port number.

Once a filterspec has been defined, the API allows for the creation of a flowspec. A flowspec identifies the QoS parameters that will be applied to a sequence of packets. Some of the parameters defined by the flowspec include the token rate (the permitted rate of transmission) and the service type.

The third concept defined by the Traffic Control API is that of a flow. A flow is simply a sequence of packets that are all subject to the same flowspec. To put it simply, the filterspec identifies which packets will be included in a flowspec. The flowspec determines whether or not those packets receive preferential treatment, and the flow is the actual transmission of the packets that are subject to the flowspec. All packets within a flow are treated equally.

It is worth mentioning that one of the advantages that the Traffic Control API has over the Generic QoS API that was used by Windows 2000, is the ability to use flow aggregation. If a host has multiple applications transmitting multiple data streams to a common destination, then those packets can all be combined into a common flow. This is true even if the applications are using different port numbers, so long as the source and destination IP addresses are the same.

The Generic Packet Classifier

In the previous section, I explained the relationships between the flowspec, the filterspec, and the flow. It is important to remember though, that the Traffic Control API is just that; an API. As such, it’s job it to identify and prioritize traffic streams, not to create the actual flow.

Creating the flow is the job of the Generic Packet Classifier. As you may recall from the previous section, one of the attributes that was defined within the flowspec was the service type. The service type basically defines the flow’s priority. The Generic Packet Classifier is responsible for examining the service type that has been assigned to a flowspec, and then placing the related packets into a queue that corresponds to the service type. Each flow is placed into a separate queue.

The QoS Packet Scheduler

The third QoS component that you need to be aware of is the QoS Packet Scheduler. To put it simply, the QoS Packet Scheduler’s primary job is traffic shaping. To accomplish this, the packet scheduler retrieves the packets from the various queues, and then marks the packets with a priority and flow rate.

As I explained in the first part of this article series, in order for QoS to work properly, the various network components located between a packet’s source and its destination must be QoS aware. Although these devices need to know how to deal with QoS, they also need to know how to process normal, non prioritized traffic as well. In order to make this possible, QoS uses a technique called marking.

There are actually two types of marking that take place. The QoS Packet Scheduler uses Diffserv marking that is recognized by layer 3 devices, and 802.1p marking that is acknowledged by layer 2 devices.

Setting Up the QoS Packet Scheduler

Before I show you how marking works, I need to point out that you will need to setup the QoS Packet Scheduler in order for it to work. In Windows Server 2003, the QoS Packet Scheduler is treated as an optional network component, just like the Client for Microsoft Networks or the TCP/IP Protocol. To enable the QoS Packet Scheduler, open the properties sheet for your server’s network connection, and select the check box next to the QoS Packet Scheduler, as shown in Figure A. If the QoS Packet Scheduler is not on the list, then click the Install button and follow the prompts.

Figure A: The QoS Packet Scheduler must be enabled before you can use QoS

Another thing that you need to know about the QoS Packet Scheduler is that in order for it to work properly, your network adapter must support 802.1p marking. To check your network adapter, click the Configure button that’s shown in Figure A, and Windows will display the properties sheet for your network adapter. If you look at the properties sheet’s Advanced tab, you will see the various properties that are supported by your network adapter.

If you look at Figure B, you can see that one of the properties that is listed is 802.1Q / 1P VLAN Tagging. You can also see that this property is disabled by default. To enable 802.1p marking, simply enable this property, and click OK.

Figure B: You must enable 802.1Q/1P VLAN Tagging

You might have noticed in Figure B that the property that you enabled is related to VLAN tagging, not to packet marking. The reason for this is that the priority markings are embedded inside VLAN tags. The 802.1Q standard defines VLANs and VLAN tags. This standard actually reserves three bits within a VLAN packet that are to be used to hold a priority code. Unfortunately, the 802.1Q standard never defines what these priority codes should be.

The 802.1P standard was created as a compliment to 802.1Q. 802.1P defines the priority markings that can be embedded into a VLAN tag. I will show you how these two standards work together in Part 3.

Throttling Bandwidth through QoS (Part 3)

802.1P Signaling

As I explained in the previous article, 802.1p signalin

g takes place at layer 2 of the OSI model. That’s the layer used by hardware devices such as switches. Layer 2 devices that are 802.1p aware are able to look at the priority markings that are assigned to packets, and then group those packets into separate classes of traffic.

On Ethernet networks, the priority markings are embedded inside of VLAN tags. VLANs and VLAN tags are defined by the 802.1Q standard, which specifies a three bit priority field, but does not actually specify how the priority field should be used. This is where the 802.1P standard comes into play.

802.1P defines various priority classes that can be used in conjunction with the 802.1Q standard. Ultimately, 802.1Q leaves priority marking to the administrator’s discretion, so you don’t technically have to abide by the 802.1P guidelines, but the 802.1P standard seems to be what everyone is adopting.

Although the idea of using 802.1P standards to provi

de layer 2 markings probably sounds theoretical, the markings can actually be defined through group policy settings. The 802.1P standard allows for eight different priority classes (ranging from 0 to 7). QoS treats packets with higher priority classes with a higher delivery priority.

Microsoft assigns the following priority markings by default:

Priority Marking	Level of Service
0	Packets that do not conform to the flowspec
0	Qualitative
0	Best effort delivery
4	Controlled load
5	Guaranteed service
7	Network control

As I mentioned a moment ago though, you can change these priorities by modifying various group policy settings. To do so, open the Group Policy Editor, and navigate through the console tree to Computer Configuration \ Administrative Templates \ Network \ QoS Packet Scheduler \ Layer-2 Priority Value. As you can see in Figure A, there are group policy settings corresponding to each of the priority markings that I have listed above. You can assign your own priority marking levels to any of these service types. One thing to keep in mind though, is that these group policy settings are only valid for hosts running Windows XP, 2003, or Vista.


Figure A: You can use the Group Policy Editor to customize layer 2 priority markings.

Differentiated Services

As I explained in the previous article, QoS performs priority marking at both layer 2 and at layer 3 of the OSI model. This helps to ensure that priorities will be honored throughout the entire packet delivery process. For example, switches work at layer 2 of the OSI model, but routers typically work at layer 3. Therefore, if packets only used 802.1p prioritization markings, then packets would be prioritized by network switches, but the prioritization would be completely ignored by network routers. To keep that from happening, QoS uses the Differentiated Services protocol (sometimes referred to as Diffserv) to prioritize traffic at layer 3 of the OSI model. Diffserv marking are included in a packet’s IP header by TCP/IP.

The architecture used by Diffserv was originally defined by RFC 2475. However, many of the architecture’s specifications were rewritten in RFC 2474. RFC 2474 defines the Diffserv architecture for both IPv4 and for IPv6.

The interesting thing about the IPv4 implementation of RFC 2474 is that even though Diffserv has been completely redefined, it is still backward compatible with the original RFC 2475 specification. This means that older routers that are not aware of the new specification are still able to understand the priorities that have been assigned.

The current Diffserv implementation uses a packet’s Type of Service (TOS) octet to store the Diffserv value (which is sometimes referred to as the DSCP value). Within this octet, the first six bits store the DSCP value, and the last two bits are unused. The reason why it is possible for the markings to be backward compatible with the RFC 2475 specification is because RFC 2475 required the first three bits of this same octet to be used for IP precedence information. Although DSCP values are six bits in length, the first three bits still reflect IP precedence.

Like the 802.1p markings that I showed you earlier, you can adjust Diffserv priorities through various group policy settings. Before I show you how, here are the default Diffserv priority markings used by Windows:

Priority Marking	Service Type
0	Best Effort
0	Qualitative
24	Controlled Load
40	Guaranteed Service
48	Network Control

You might have noticed that Diffserv priority markings use a completely different range than 802.1P priority markings do. Rather than supporting a range of 0 to 7, Diffserv supports priority markings ranging from 0 to 63, with higher numbers receiving higher priorities.

As I mentioned, Windows does allow you to define Diffserv priority markings through group policy settings. You must keep in mind though, that some higher end routers will assign their own Diffserv values to packets, regardless of the values that are assigned by Windows.

With that in mind, you can configure Diffserv priority markings by opening the Group Policy Editor, and navigating through the console tree to Computer Configuration \ Administrative Templates \ Network \ QoS Packet Scheduler .

If you look at Figure B, you will notice that there are two DSCP related containers beneath the QoS Packet Scheduler container. One of these containers allows you to set DSCP priority markings for packets that conform to the flowspec, while the other allows you to set DSCP priority markings for non conforming packets. The actual settings themselves are identical for both containers, as shown in Figure C.

Figure B: Windows handles DSCP priority markings separately for packets that conform to the flowspec, and for those that don’t.


Figure C: You can manually assign DSCP priority markings for the various service types.

Miscellaneous Group Policy Settings

If you look at Figure B, you will notice that there are three group policy settings that I haven’t talked about. I wanted to quickly mention what these settings are and what they do, for those of you who might be curious.

The Limit Outstanding Packets setting is essentially a service threshold value. If the number of outstanding packets reaches the specified value, then QoS will not allow any additional submissions to network adapters until the value falls beneath the specified threshold.

The Limit Reservable Bandwidth setting controls the percentage of the total bandwidth that can be reserved by QoS aware applications. By default, QoS aware applications can reserve up to 80% of the network bandwidth. Of course any bandwidth that has been reserved, but is currently not being used by QoS applications can be used by other applications.

The Set Timer Resolution setting controls the smallest unit of time (in microseconds) that the QoS packet scheduler will use when scheduling packets. Essentially, this setting controls the maximum frequency at which packets can be scheduled for delivery.