Version 0.6, 2008-Oct-21
We need to have a way to specify NCP policy in terms of the individual elements (Network Configuration Units, or NCUs) that comprise it. We would like to be able to specify policy preferences such as "prefer wired over wireless", "one interface at a time", etc. We also need to describe conditional relationships between NCUs, for example an IP NCU depends on the underlying link NCU.
Five properties in the NCU data structure will be used to represent the activation policy. They are "activation mode", "enabled", "priority group", "priority group mode", and "condition". These properties are discussed in more detail in the following sections.
property: activation mode
type: enum
value: MANUAL, PRIORITIZED, CONDITIONAL_ANY, CONDITIONAL_ALL
The meaning of each value is:
Note that regardless of the activation mode or other activation policy settings, an IP NCU of class IP will always implicitly depend on the link NCU of the same name, i.e. the underlying link must be active in order for IP to be plumbed. That condition may be explicitly called out in the activation policy settings (as in the examples in section 2.1.2), but will be enforced whether it is called out or not.
property: enabled (activation mode == MANUAL)
type: boolean
value: true or false
Specifies what should be done to a manually activated NCU on startup; if enabled is true, the NCU will be activated; if enabled is false, the NCU will not be activated.
property: priority group (activation mode == PRIORITIZED)
type: int
value: An integer, with 0 being the lowest priority. Negative values
are invalid.
Among all the available priority groups, only the NCU(s) in the highest available priority group will be activated. Activation behavior when more than one NCU with the same priority is available is defined by "priority group mode" below.
Note: The priority number will not be seen by end users and is subject to change when the NCP repository is updated. But the priority order will be strictly enforced.
property: priority group mode (activation mode == PRIORITIZED)
type: enum
values: EXCLUSIVE, SHARED, ALL
The meaning of each value is:
property: condition (activation mode == CONDITIONAL_ANY or CONDITIONAL_ALL)
type: list of strings
value: String(s) identifying the NCU(s) upon which this NCU depends.
Each condition string should be formatted as "ncu
For all physical links:
Include an IP interface plumbed on each active link:
For all physical links:
Include an IP interface plumbed on each active link:
For link bge0:
For link tun0:
For all other links:
Include an IP interface plumbed on each active link:
We need to determine how to represent policy choices derived from this model to the GUI user. To keep things simple, it might be best to simply allow users to select a preferred type of link - wired, wireless, or none, - and a preferred mode of operation - one link active or all links active. In other words the properties editor would have a dropdown list labeled "Prefer active links that are (wired | wireless | "no preference"). In addition we need a way of specifying the link activity policy, which we split into wired and wireless activation. This we could represent as a dropdown labeled "Use (no | all | one) wired link(s)", and another labeled "Use (no | all | one) wireless link(s)".
In addition to these manipulations, link icons can be moved up or down in the list of links, and these changes represent priority changes (initially all links of a given type, wired or wireless, will have the same priority). Link activation can also be disabled/enabled explicitly via clicking on the link.
In NWAM phase 1, we will have 2 NCPs: the Automatic and User-Configured NCPs. The former will specify DHCP for address acquisition method, and will default to a policy of one active link at a time, preferring plugged-in, wired links over wireless, and plumbing IP and IPv6 on that link. If network links are hotplug inserted, these will be automatically enabled, and if the new link is wired and plugged in, a switch of active link is possible.
On a fresh install, the Automatic NCP will be the only NCP available until the user has created an NCP via the UI; NWAM will therefore run with the Automatic NCP active until the user makes a change. In the upgrade case, if a phase 0 /etc/nwam/llp file existed on the previous installation, that file will be used to create the initial User-Configured NCP, and NWAM will run with that NCP by default. If there was no pre-existing NWAM configuration, the behavior on upgrade will be the same as on initial install, with the Automatic NCP being the default active NCP.
In terms of GUI representation, we will probably do something like the following:
Properties Editor
Network Status View
Add some text like "Active Profile: Automatic / User Config" above the list of NCUs.
Network Configuration View
Add a drop-down list that allows users to select from Automatic/User Config. When Automatic is selected things will need to be in a "view only" mode
So switching NCP would be done by selecting the active profile from the dropdown list.
| Revision | Date | Changes |
|---|---|---|
| 0.1 | 2008-Apr-17 | initial draft |
| 0.2 | 2008-Apr-21 | added UI switching approach suggested by Darren |
| 0.3 | 2008-Apr-24 | added initial thoughts on GUI representation of policy |
| 0.4 | 2008-Apr-25 | editorial/formatting updates |
| 0.5 | 2008-Sep-09 | update property names/values |
| 0.6 | 2008-Oct-21 | update property details |