Self service depends greatly on specific functionality of provisioning servers (DHCP,
BOOTP, TFTP). The following requirements represent what is needed from these provisioning
servers to evolve self service and its components.
| Functional Requirements |
Priority |
Phase |
Comments & Assumptions |
| 1.0 |
Platform |
|
|
|
| |
See system-level requirements |
|
|
|
| 2.0 |
Server Interface |
|
|
|
| |
Server will operate on machines with one or
more interfaces. |
|
1 |
|
| |
Machines with multiple interfaces will have
the ability to select which interface the server will use at server startup. |
|
1 |
|
| |
More detail to follow… |
|
|
|
| 3.0 |
Policy Configuration |
|
|
|
| |
Policies must be independent entities and
have the ability to be associated with one or more other objects. |
|
1 |
|
| |
Clients (individual ethernet addresses),
service groups (groups of similarly configured clients), subnets, and policies have the
capability to be associated with at least one policy. |
|
1 |
|
| |
Hierarchy (base/inheritance) configuration
of policies will be supported. |
|
1 |
|
| |
A full complement (255) of DHCP options
will be supported in each policy. |
|
1 |
|
| |
Any DHCP options that are not yet
officially named can be configured manually in each policy. |
|
1 |
|
| |
Each policy will contain a home directory
and bootfile name DHCP option that is joined together before it is given to the client. |
|
1 |
|
| |
Each policy will contain an additional home
directory option specifically for DHCP. This home directory will be used in leu of the
previous home directory for DHCP transactions. If this option is not assigned, the
standard home directory will be included in all BOOTP/DHCP transactions. |
|
1 |
|
| |
More detail to follow… |
|
|
|
| 4.0 |
Service Group (Policy) |
|
|
|
| |
Server will support 100 or more service
groups. |
|
1 |
|
| |
Each service group will not be limited to
how may clients can be associated with it. |
|
1 |
|
| |
Hierarchy (base/inheritance) configuration
of service groups will be supported. |
|
1 |
|
| |
A full complement (255) of DHCP options
will be supported in each service group. |
|
1 |
|
| |
Any DHCP options that are not yet
officially named can be configured manually in each service group. |
|
1 |
|
| |
DHCP options set in service groups can only
be over-written by those associated with a particular client. |
|
1 |
|
| |
More detail to follow… |
|
|
|
| 5.0 |
Policy Propagation |
|
|
|
| |
Policies associated with any transaction
will be applied in order of generalized (i.e. server defaults and subnets) to specific
(i.e. service groups and/or individual clients). |
|
1 |
|
| |
DHCP options associated with each policy
can be overwritten or cleared by similar DHCP options associated with subsequently
encountered policies. |
|
1 |
|
| |
DHCP and BOOTP will propagate DHCP options
set for clients, service groups, subnets, and defaults similarly. |
|
1 |
|
| |
More detail to follow… |
|
|
|
| 6.0 |
Subnets |
|
|
|
| |
Each subnet and secondary will support
classless addressing. |
|
1 |
|
| |
Each subnet will support zero or more
dynamic ranges. |
|
1 |
|
| |
Each subnet will support zero or more
policies. |
|
1 |
|
| |
Each subnet will support zero or more
secondary subnets. |
|
1 |
|
| |
Each secondary subnet will support zero or
more dynamic ranges. |
|
1 |
|
| |
Each secondary subnet will support zero or
more policies. |
|
1 |
|
| |
Each secondary subnet will mirror the
subnet mask of its parent (primary parent) subnet. |
|
1 |
|
| |
Each dynamic range will support zero or one
subnet groups assigned to it. |
|
1 |
|
| |
Each subnet (primary or secondary) will
represent all the working components of a network (network, subnet mask, gateway,
policy(s), forward DNS zone, reverse DNS zone, etc.). |
|
1 |
|
| |
Each dynamic range will be capable of
supporting BOOTP and DHCP clients. |
|
1 |
|
| |
More detail to follow… |
|
|
|
| 7.0 |
Subnet Group |
|
|
|
| |
Each subnet group will support an unlimited
number of subnet dynamic ranges |
|
1 |
|
| |
Each subnet group will support an unlimited
number of clients. |
|
1 |
|
| |
A subnet group associated with multiple
dynamic ranges within a particular subnet (primary and its secondaries) will together
represent a single pool of dynamic addresses. |
|
2 |
|
| |
More detail to follow… |
|
|
|
| 8.0 |
Client Functionality |
|
|
|
| |
Clients will have the ability to be
registered or not registered. |
|
1 |
|
| |
Unregistered clients receive an address
(lease) from the dynamic range that is not associated with a subnet group (Normal DHCP
operation). |
|
1 |
|
| |
Unregistered clients receive DHCP options
associated with server defaults, subnets, and subnet policies (and their associated
parent) ONLY. |
|
1 |
|
| |
Clients may be registered to a subnet group
to obtain an address in a defined dynamic range. |
|
1 |
|
| |
Registered clients assigned to a subnet
group not associated with any dynamic range on the server will NOT be answered. |
|
1 |
|
| |
Registered clients may receive DHCP options
similar to unregistered clients. |
|
1 |
|
| |
Clients may be registered to a service
group to obtain particular DHCP options associated with that group and its parent (in
leu/addition to those previously assigned). |
|
1 |
|
| |
Clients may be registered with an
additional subscriber information field in leu of registering each client to an external
database such as LDAP. |
|
1 |
|
| |
Clients may be statically assigned
(reserved) an IP address in the dynamic range. |
|
1 |
|
| |
Any IP address within a dynamic pool that
is statically assigned (reserved) will be unavailable for dynamic assignment. |
|
1 |
|
| |
More detail to follow… |
|
|
|
| 9.0 |
BOOTP Support |
|
|
|
| |
Support for BOOTP will be configurable
(turn on/off). |
|
1 |
|
| |
"Classic" BOOTP (mapping
addresses and other DHCP options to specific clients) will be supported. |
|
1 |
|
| |
BOOTP server will have option to utilize
dynamic addressing. |
|
1 |
|
| |
BOOTP server may be configured via standard
bootptab file. |
|
1 |
|
| |
More detail to follow… |
|
|
|
| 10.0 |
Filtering |
|
|
|
| |
Server will support variable client prefix
(vendor ID) filtering. |
|
1 |
|
| |
Filtering will have the option to either
"pass" or "block" zero or more vendor IDs. |
|
1 |
|
| |
Filtering set to "pass" will
limit the server to only answering requests from vendor IDs associated with
"pass". |
|
1 |
|
| |
Filtering set to "block" will
only ignore (drop) only those requests from vendor IDs associated with "block". |
|
1 |
|
| |
More detail to follow… |
|
|
|
| 11.0 |
IP Address Management |
|
|
|
| |
Server will support 3rd party IP
address management tools. |
|
2 |
|
| |
More detail to follow… |
|
|
|
| 12.0 |
Dynamic DNS |
|
|
|
| |
Server must be able to maintain mapping of
hostname to mac address as defined in client registry. |
|
1 |
|
| |
Changes to a client’s hostname or
domain name will become active on the next transaction with that client. |
|
1 |
|
| |
Hostname/domain mapping will follow client
subnet roaming. |
|
1 |
|
| |
More detail to follow… |
|
2 |
|
| 13.0 |
Centralized Configuration Database (CCD) |
|
|
|
| |
A central interface will manage service
groups maintained on all provisioning systems and provide external mappings of service
groups to appropriate server configurations required to support them. |
|
1 |
|
| |
Central interface configures service groups
locally on provisioning servers in parallel with storing them on central configuration
database. |
|
2 |
|
| |
More detail to follow… |
|
|
|
| 14.0 |
Bootfile Generation |
|
|
|
| |
Bootfile generation will be handled by
central interface using a "shared" bootfile model and managed through service
groups. |
|
1 |
|
| |
Central interface generates each bootfile
according to its associated service group parameters locally on provisioning servers in
parallel with storing its associated definitions on central configuration database. |
|
2 |
|
| |
Bootfile generation for advanced (custom
tailored services) will be built On-The-Fly by TFTP server. |
|
3 |
|
| |
Non-tailored service group’s bootfile
will continue to be static but handled by a multi-threaded TFTP server. |
|
3 |
|
| |
More detail to follow… |
|
|
|
| 15.0 |
TFTP Services |
|
|
|
| |
TFTP services are share hardware platform
of provisioning server. |
|
1 |
|
| |
TFTP services utilize their own hardware
platform |
|
2 |
Or late phase 1 |
| |
Multi-threaded TFTP services are utilized
with a shared bootfile model. |
|
3 |
Or late phase 2 |
| |
On-The-Fly TFTP services are used for
special service types. |
|
3 |
|
| |
TFTP server will be available 24x7x365
average up time should not be less than 99.99% (which includes schedule maintenance,
renumbering, software tuning, and hardware upgrades). |
|
3 |
|
| |
TFTP server and its components will capable
of being monitored by NOC via SNMP. |
|
3 |
|
| |
TFTP server and its supporting components
(hardware & OS) will be managed via ping. |
|
2 |
|
| |
More detail to follow… |
|
|
|
| Operational Requirements |
Priority |
Phase |
Assumptions |
| 1.0 |
Configuration |
|
|
|
| |
The server will be configurable through a
variety of different means (GUI, CLI, LDAP). |
|
1 |
|
| |
Each means of configuration will support
similar functionality. |
|
1 |
|
| |
Server will be fully configurable via the
command line interface (CLI). Setup and maintenance can exclusively use the CLI. |
|
1 |
|
| |
Server will support external
add/modify/change for subnets. |
|
1 |
|
| |
Server will support external
add/modify/change for policies. |
|
1 |
|
| |
Server will support external
add/modify/change for service groups. |
|
1 |
|
| |
More detail to follow… |
|
|
|
| 2.0 |
Server Administration |
|
|
|
| |
Operational changes in configuration made
to the server will be completed and active in no more than 1 minute. |
|
1 |
|
| |
Adding and removing subnets will be
completed and active in no more than 2 minutes when 100 subnets in service. |
|
1 |
|
| |
Server will have the ability to recover
(complete rebuild of server configuration and addresses) from disaster state (database
corrupted or hardware failure) in no more than 10 minutes. |
|
1 |
|
| |
Server will adhere to ServiceCo General
System-Level & Interface Requirements contained in separate documents. |
|
1 |
|
| |
Server must provide a tool for data
integration check after service has been recovered from disaster state. |
|
1 |
|
| |
Server will be available 24x7x365 average
up time should not be less than 99.99% (which includes schedule maintenance, renumbering,
software tuning, and hardware upgrades). |
|
1 |
|
| |
Server and its components will capable of
being monitored by NOC via SNMP. |
|
2 |
|
| |
Server and its supporting components
(hardware & OS) will be managed via ping. |
|
1 |
|
| |
More detail to follow… |
|
|
|
| 3.0 |
Lease Handling |
|
|
|
| |
Server must maintain a single persistent
address for each client across all subnets maintained by server (auto-release). |
|
1 |
|
| |
Server must not reuse client leases as long
as free addresses are available in the dynamic address pool. |
|
1 |
|
| |
Registered and Unregistered clients will be
allowed to change subnets and/or dynamic ranges (roam subnets). |
|
1 |
|
| |
BOOTP and DHCP will be handled the same as
far as changing subnets. |
|
1 |
|
| |
A client’s change in subnet groups
will be handled operationally the same as a change in subnets. |
|
1 |
|
| |
More detail to follow… |
|
|
|
| 4.0 |
Client Registration |
|
|
|
| |
Each client registry will contain the mac
address of the client. |
|
1 |
|
| |
Each client registry will contain the
hardware type of the client. |
|
1 |
|
| |
Each client registry will contain the
hardware length of the client. |
|
1 |
|
| |
Each client registry will contain the
subnet group to be assigned to the client. |
|
1 |
|
| |
Each client registry will contain the
service group to be assigned to the client. |
|
1 |
|
| |
Each client registry may contain the
hostname to be given to the client. |
|
1 |
|
| |
Each client registry may contain the domain
name to be given to the client (if different from the default domain name defined for the
server). |
|
1 |
|
| |
Client registry data must be stored locally
or on LDAP but not both. |
|
1 |
|
| |
Client registry data stored on LDAP will be
READ ONLY for provisioning servers. |
|
1 |
|
| |
More detail to follow… |
|
|
|
| 5.0 |
Systems Integration |
|
|
|
| |
Server must provide a import tool for lease
data |
|
1 |
|
| |
Server must provide a import tool for
registry data |
|
1 |
|
| |
Server must provide a import tool for
subnet configuration. |
|
1 |
|
| |
Server must provide a import tool for
policy configuration. |
|
1 |
|
| |
Server must provide a import tool for
service group configuration. |
|
1 |
|
| |
Server must provide a import tool for
subnet group configuration. |
|
1 |
|
| |
Server must provide a export tool for lease
data. |
|
1 |
|
| |
Server must provide a export tool for
registry data. |
|
1 |
|
| |
Server must provide a export tool for
subnet data. |
|
1 |
|
| |
Server must provide a export tool for
policy data. |
|
1 |
|
| |
Server must provide a export tool for
service group data. |
|
1 |
|
| |
Server must provide a export tool for
subnet group data. |
|
1 |
|
| |
Server will provide a tool to lookup client
leases by mac address. |
|
1 |
|
| |
Lease lookup tool will return an answer in
no more than 3 seconds. |
|
1 |
|
| |
Server will provide a tool that will return
zero or more client registration(s) associated with a subscriber information field. |
|
1 |
|
| |
More detail to follow… |
|
|
|
| 6.0 |
Client Registry LDAP |
|
|
|
| |
A separate LDAP server will be used for
READ ONLY client registry. |
|
1 |
|
| |
Regional client registry data will not be
replicated. |
|
1 |
|
| |
Any existing directory services schema
and/or server will not be used/changed to support self service. |
|
1 |
|
| |
More detail to follow… |
|
1 |
|
| 7.0 |
Redundancy/Distributed Load |
|
|
|
| |
Load sharing and/or redundancy will be
supported. |
|
1 |
|
| |
Provisioning services will be supported by
two specially tuned provisioning systems. |
|
1 |
|
| |
Provisioning services will be further
distributed such that some services can either be redundant or deployed closer to the
clients. |
|
2 |
|
| |
Full redundancy of provisioning services
will be provided with a centralized database and configuration. |
|
3+ |
|
| |
More detail to follow… |
|
|
|
| 8.0 |
Modularity |
|
|
|
| |
Provisioning server database and registry
database will be separate. |
|
1 |
|
| |
Provisioning server, registry, and
configuration databases will be separate. |
|
3 |
|
| |
Provisioning server will not have any local
database and rely on ODBC connectivity to customer selected datastore. |
|
3+ |
|
| |
More detail to follow… |
|
|
|
| 9.0 |
Logging Facilities |
|
|
|
| |
Provisioning server will support various
levels of logging and debuging. |
|
1 |
|
| |
Each transaction processed will be noted in
the log and be clearly separated from other transactions via some common delimiter (string
of characters). |
|
1 |
|
| |
Each logged instance will be date time
stamped with the correct local time of the server at which the transaction was received. |
|
1 |
|
| |
Log rotation will be handled either by the
server or by the administrator. |
|
1 |
|
| |
More detail to follow… |
|
|
|