4.1 GEN – General Device Requirements

4.1.1 GEN.DESIGN – Design

ID Requirement
GEN.DESIGN.1 The RG MUST be compact and have a physical profile suitable for a desktop.
GEN.DESIGN.2 The RG SHOULD be able to be wall mounted and stand on its side.
GEN.DESIGN.3 The RG MAY have the ability to be mounted horizontally or vertically.
GEN.DESIGN.4 If wall mounted, the RG SHOULD be oriented so that the cabling is routed toward the ground in order to reduce strain on the cabling.
GEN.DESIGN.5 A detachable wall-mounting bracket MAY be added to the RG.
GEN.DESIGN.6 The power connector at the RG MUST be securely connected to avoid accidental disconnect. This means that the connector MUST be either secured via a clip to the box or be held in place with significant force so that it does not readily pull out by minor pulling on the power cord.
GEN.DESIGN.7 If the power supply is external to the RG, it SHOULD be labeled with the RG vendor’s name and the model number of the RG.
GEN.DESIGN.8 If the power supply is external to the RG it SHOULD be either small enough, or appropriately positioned on the power cord, so as not to block other power outlets.
GEN.DESIGN.9 If the power cable includes an AC to DC conversion brick, that brick MAY have a light on it.
GEN.DESIGN.10 The RG MUST NOT be USB powered.
GEN.DESIGN.11 The RG MUST NOT use the local phone loop for power.
GEN.DESIGN.12 The model and serial number of the RG MUST be visible via external markings on the RG.
GEN.DESIGN.13 The model and serial number of the RG MUST be visible via external markings on the RG packaging.
GEN.DESIGN.14 If a console port used for local technician configuration is provided on the RG, it SHOULD NOT be physically accessible to end users (e.g. it should not be placed on the outside of the device).
GEN.DESIGN.15 The RG MUST have a single function reset button in order to reset the device to the default factory settings.

4.1.2 GEN.OPS – Device Operation

ID Requirement
GEN.OPS.1 All RG firmware and associated system files MUST be pre-installed.
GEN.OPS.2 The RG MUST operate 24 hours a day, 7 days a week without the need to reboot.
GEN.OPS.3 The MTBF (Mean Time Between Failures) of the RG and operating system SHOULD be equal to or exceed 1 year (e.g. it should not need a reboot more than one time per year).
GEN.OPS.4 The life expectancy of the RG SHOULD be at least seven years.
GEN.OPS.5 The RG SHOULD tolerate power fluctuations and brown-outs, continuing to operate normally and maintaining its configuration after these events.
GEN.OPS.6 The RG SHOULD be able to detect faults and reset appropriately upon detection.
GEN.OPS.7 The RG SHOULD include sufficient non-volatile memory to accommodate future control and data plane protocol upgrades over a minimum of four years. The potential upgrades may include: initiating and terminating signaling protocols at IP and ATM layers; logic for packet classification, policing, forwarding, traffic shaping and QoS support at IP, Ethernet and ATM layers.
GEN.OPS.8 The RG MUST preserve local configuration information during power-off and power interruption.
GEN.OPS.9 The RG MUST complete power up in 60 seconds or less.
GEN.OPS.10 The RG SHOULD be self-installable by an end user in under 20 minutes assuming the default configuration and mode of operation. This is the time from when the box is opened to when the user is using the service including any driver installation (assuming no network complications and excluding micro-filter installation and customer ordering/registration).
GEN.OPS.11 Other than networking drivers (e.g. USB, wireless, etc…), other software or drivers MUST NOT be required on computers and other devices for proper and full use of the RG.
GEN.OPS.12 The RG, its drivers and any packaged software SHOULD support Macintosh OS 8.6 and above.
GEN.OPS.13 The RG, its drivers and any packaged software SHOULD support all Microsoft PC based operating systems that have not yet reached “End of Support” status (see http://support.microsoft.com/lifecycle for more details).
GEN.OPS.14 The RG, its drivers and any packaged software MAY support Linux. It is especially desirable to do so with an open interface.
GEN.OPS.15 The RG MUST preserve its configuration across firmware updates.
GEN.OPS.16 All software revisions SHOULD be backward compatible with all previous versions. There SHOULD be no loss of existing functionality.
GEN.OPS.17 Software revisions MUST NOT require service provider network changes to maintain proper operation of previous features.
GEN.OPS.18 The RG firmware MUST be identified by a revision number. This revision number MUST be formatted using an X.Y.Z incremental numbering format where X indicates the major release number, Y indicates the minor release number, and Z represents the revision number (e.g. 2.4.1).
GEN.OPS.19 The RG vendor SHOULD have a web site where firmware updates and documentation are available.
GEN.OPS.20 The firmware at the RG vendor’s web site SHOULD include all error correcting updates for the RG.

GEN.OPS.21

The RG MUST NOT allow “back door” entry to the unit (e.g. there must be no hidden telnet or web access using secret passwords).

This requirement is not intended to preclude physically secured craft access in accordance with GEN.DESIGN.14.
GEN.OPS.22 All firmware updates MUST be verified using security mechanisms. A checksum mechanism is a minimum requirement for achieving this.
GEN.OPS.23 All firmware updates SHOULD be signed with a cryptographic “fingerprint” of at least 256 bits.

GEN.OPS.24

In the event of a failure occurring during an update, the RG MUST be able to back off to the prior version of the firmware installed on the RG. That is, the prior version of the RG’s firmware MUST continue to be useable in the event that a firmware update fails to complete.

This is not a requirement for a dual image, although that is one manner in which this requirement might be satisfied.

4.1.3 GEN.NET – Networking Protocols

ID Requirement
GEN.NET.1 The RG MUST support Ethernet (IEEE 802.3).
GEN.NET.2 The RG MUST support IP Version 4.
GEN.NET.3 If the RG does not support IPV6, it SHOULD be software configurable or upgradeable to support IP Version 6 in the future. This means that the processing power, memory and networking components be designed appropriately and be sufficiently robust to provide this support.

GEN.NET.4

The RG MUST support the TCP, IP, UDP, routing and associated IETF protocols identified here:

  • RFC 768 [142] User Datagram Protocol

  • RFC 791 [144] Internet Protocol

  • RFC 792 [145] Internet Control Message Protocol

  • RFC 793 [146] Transmission Control Protocol

  • RFC 826 [147] Ethernet Address Resolution Protocol (ARP)

  • RFC 894 [149] Standards for the Transmission of IP Datagrams over Ethernet Networks

  • RFC 922 [150] Broadcasting Internet Datagrams in the Presence of Subnets

  • RFC 950 [151] Internet Standard Subnetting Procedure

  • RFC 1042 [46] Standard for the Transmission of IP Datagrams over IEEE 802 Networks

  • RFC 1112 [47] Host Extensions for IP Multicasting

  • RFC 1122 [48] Requirements for Internet Hosts - Communication Layers

  • RFC 1123 [49] Requirements for Internet Hosts - Application and Support

  • RFC 1256 [51] ICMP Router Discovery Messages (Router Specification only)

  • RFC 1812 [54] Requirements for IP Version 4 Routers

  • RFC 1918 [55] Address Allocation for Private Internets

  • RFC 4632 [110] Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan

IANA Directory of General Assigned Numbers (http://www.iana.org/numbers.html)
GEN.NET.5 The RG MUST support IP over Ethernet.
GEN.NET.6 The RG MUST support, at a minimum, a 256 MAC address table for LAN devices.

4.1.4 GEN.NETv6 – IPv6 Networking Protocols

ID Requirement
GEN.NETv6.1 The RG MUST support IP Version 6, which is defined in RFC 2460 [66].
GEN.NETv6.2 The RG MUST support enabling and disabling of IPv6.