4.4 MGMT – Management & Diagnostics

4.4.1 MGMT.GEN – General

ID Requirement
MGMT.GEN.1 Configuration and installation of the RG SHOULD minimize the number of restarts of the RG when enabling changes.
MGMT.GEN.2 If software is loaded on LAN CPE for installation or configuration of the RG, this software MUST NOT require the associated LAN CPE to restart, except in the case of the installation of networking drivers (e.g. USB, wireless, etc.) or a change in IP address assignment (e.g. static to DHCP, public to private, private to public or assignment of a specific IP address using DHCP).
MGMT.GEN.3 The RG MUST maintain an internal log of WAN side connection flows (e.g. WAN link layer, DHCP, IP and PPP sessions). At a minimum, the log MUST record the last 250 events. This includes WAN physical interface events initiated locally or by the access network. The purpose of the log is to provide a troubleshooting aid in resolving line and connection problems.
MGMT.GEN.4 The RG MUST timestamp each log entry.

MGMT.GEN.5

The factory default timestamp value for log entries SHOULD indicate the elapsed time since the unit was first powered on. The log entry timestamp SHOULD be formatted, consistent with ISO 8601, as follows:

  • PYYYY-MM-DDThh:mm:ss

where:

  • P = the letter “P” used to indicate that what follows is a time interval (period) data element

  • YYYY = number of years (digits)

  • MM = number of months (digits, 00 – 11; 1 month is the equivalent of 30 days for time interval purposes)

  • DD = number of days (digits, 00 – 29)

  • hh = number of hours (digits, 00 – 23)

  • mm = number of minutes (digits, 00 – 59)

  • ss = number of seconds (digits, 00 – 59)

Once the RG has established connectivity to an Internet based time server, all log entry timestamps SHOULD be formatted for GMT or user specified time zone (24 hour military format), consistent with ISO 8601, as follows:

  • YYYY-MM-DDThh:mm:ss±hh:mm or

  • YYYY-MM-DDThh:mm:ssZ ,

where:

  • YYYY = year (digits)

  • MM = month (digits, 01 – 12)

  • DD = day of month (digits, 01 – 31)

  • T = the letter “T”, used to indicate the start of the time of day

  • Z = the letter “Z”, used to indicate that the time is UTC (Coordinated Universal Time)

  • hh = hours (digits, 00 – 23)

  • mm = minutes (digits, 00 – 59)

  • ss = seconds (digits, 00 – 59)

  • ±hh:mm = the difference between local time and UTC in hours and minutes (e.g. -05:00 would indicate Eastern Standard Time, 5 hours behind UTC)

MGMT.GEN.6 The RG MUST have diagnostic information available that allows the user to identify the precise nature of any connection or performance problem. It MUST be able to indicate if the problem is at the physical layer, ATM, Ethernet, PPP, or IP layer. This information MUST be accessible from the Web GUI, TR-064i4 interfaces and from a Controller.
MGMT.GEN.7 The RG MUST have an embedded ICMP ping client capable of being initiated via the Web GUI interfaces and from a Controller to ping to WAN and LAN side IP addressable devices.
MGMT.GEN.8 The RG log SHOULD reside on the RG and persist across power loss.
MGMT.GEN.9 The RG log SHOULD NOT interfere with the normal performance of the RG. That is, writing log entries to non-volatile storage SHOULD NOT be done at a priority or in a manner that would degrade the user experience nor the connection throughput.
MGMT.GEN.10 The RG MUST be able to start training, establish a network connection and respond to network tests by default upon power up prior to any additional configuration or software installation on the associated PC. The absence of a PC MUST have no effect on these operations.

4.4.2 MGMT.UPnP – UPnP

ID Requirement
MGMT.UPnP.1 The RG MUST support UPnP device architecture 1.0. This specification is available for download at http://www.upnp.org.

MGMT.UPnP.2

The RG MUST support UPnP device identification in accordance with the UPnP device architecture. The RG MUST display itself as a network device with the following information:

  • Manufacturer name

  • RG name

  • Model number

  • Description (e.g. VendorName Wireless Gateway)

  • Device address (e.g. http://192.168.1.254)

4.4.2.1 MGMT.UPnP.IGD – UPnP IGD

ID Requirement
MGMT.UPnP.IGD.1 This requirement has been replaced by MGMT.UPnP.IGD.4.
MGMT.UPnP.IGD.2 The RG MUST allow the user to enable logging of all UPnP IGD actions and events.
MGMT.UPnP.IGD.3 The user SHOULD be warned upon enabling UPnP IGD that this may allow applications to configure the box and allow unintended access to local devices.
MGMT.UPnP.IGD.4 At a minimum, the RG MUST support UPnP InternetGatewayDevice:2 device template version 1.01 standardized DCP. This specification is available for download at http://www.upnp.org.
4.4.2.1.1 MGMT.UPnP.IGD.ACRF – UPnP IGD to allow Connection Request Forwarding
ID Requirement
MGMT.UPnP.IGD.ACRF.1 The RG MUST support UPnP Internet Gateway Device:2 root device. This specification is available for download at http://upnp.org/specs/gw/UPnP-gw-InternetGatewayDevice-v2-Device.pdf
MGMT.UPnP.IGD.ACRF.2 The RG MUST support IGD specific security as defined in section 2.3 Security Policies of UPnP InternetGatewayDevice:2.
MGMT.UPnP.IGD.ACRF.3 Across resets or reboots, the RG MUST remove port mappings and pinholes.
4.4.2.1.1.1 MGMT.UPnP.IGD.ACRF.IPv4 – UPnP IGD to allow Connection Request Forwarding through the NAT of the

device {#req:mgmt.upnp.igd.acrf.ipv4}

ID Requirement
MGMT.UPnP.IGD.ACRF.IPv4.1 When the external IP address (ExternalIPAddress parameter) of the RG changes, the RG MUST continue to forward packets received on the new external IP as defined by the existing NAT port mappings rules
MGMT.UPnP.IGD.ACRF.IPv4.2 The RG MUST have a WANIPConnection:2 service when supporting a WAN IP Connection. The specification is available for download at http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf
MGMT.UPnP.IGD.ACRF.IPv4.3 The RG MUST have a WANPPPConnection:1 service when supporting a WAN PPP Connection. The specification is available for download at http://upnp.org/specs/gw/UPnP-gw-WANPPPConnection-v1-Service.pdf
MGMT.UPnP.IGD.ACRF.IPv4.4 When supporting a WAN PPP Connection, the RG MUST support internal and external port values being different (the RG MUST NOT return SamePortValuesRequired on AddPortMapping).
MGMT.UPnP.IGD.ACRF.IPv4.5 When supporting a WAN PPP Connection, the RG MUST support non permanent leases on port mappings (the RG MUST NOT return OnlyPermanentLeasesSupported on AddPortMapping).
MGMT.UPnP.IGD.ACRF.IPv4.6 When supporting a WAN PPP Connection, the RG MUST support specific IP address for RemoteHost (the RG MUST NOT return RemoteHostOnlySupportsWildcard on AddPortMapping).
MGMT.UPnP.IGD.ACRF.IPv4.7 When supporting a WAN PPP Connection, the RG MUST support specific port value for external port (the RG MUST NOT return ExternalPortOnlySupportsWildcard on AddPortMapping).
MGMT.UPnP.IGD.ACRF.IPv4.8 The RG MUST support NAT (UPnP NATEnabled state variable set to “1” as well as UPnP ConnectionType state variable set to “IP_Routed”).
4.4.2.1.1.2 MGMT.UPnP.IGD.ACRF.IPv6 – UPnP IGD to allow Connection Request Forwarding through the Firewall

of the device {#req:mgmt.upnp.igd.acrf.ipv6}

ID Requirement
MGMT.UPnP.IGD.ACRF.IPv6.1 The RG MUST have a WANIPv6FirewallControl:1 service. The specification is available for download at http://upnp.org/specs/gw/UPnP-gw-WANIPv6FirewallControl-v1-Service.pdf
MGMT.UPnP.IGD.ACRF.IPv6.2 The RG MUST allow Inbound Pinhole management (InboundPinholeAllowed set to “1”).

4.4.3 MGMT.LOCAL – Local Management

ID Requirement
MGMT.LOCAL.1 If the RG is in a bridged configuration the RG MUST be able to disable all LAN side configuration mechanisms (i.e. the Web GUI, Broadband Forum TR-064i2 [158], etc.).
MGMT.LOCAL.2 The RG MUST support a configuration mechanism from the PC as defined in Broadband Forum TR-064i2 [158].
MGMT.LOCAL.3 This requirement has been obsoleted.
MGMT.LOCAL.4 The RG MUST be configurable via embedded, easy-to-use Web GUI pages.
MGMT.LOCAL.5 Broadband Forum TR-064i2 [158] and Web GUI authorization MUST time out after 30 minutes of disuse.
MGMT.LOCAL.6 The Web GUI pages MUST be available when the RG is in bridged mode.
MGMT.LOCAL.7 The RG MUST NOT require browser support of Java, ActiveX nor VBSCRIPT in its web pages.
MGMT.LOCAL.8 The Web GUI pages SHOULD minimize internal page complexity (e.g. excessive use of frames, pop-ups, style sheets, JavaScript, etc.) that places demands on browser resources or causes interoperability problems with different browsers. In general, all pages SHOULD load within five seconds.
MGMT.LOCAL.9 The web interface MUST be OS independent and browser independent (e.g. must work with versions of Internet Explorer, Firefox, Chrome, Safari and Opera that were released within the past five years).
MGMT.LOCAL.10 The RG MUST have a software mechanism by which the user can reset it to default factory settings.
MGMT.LOCAL.11 The RG MUST support an RG access code (i.e. password) that protects it from being updated (firmware, configuration, operational state, etc.) from the local LAN.
MGMT.LOCAL.12 If a default RG access code has been set, the default RG access code MUST be on the bottom of the RG.
MGMT.LOCAL.13 If a default RG access code has been set, the RG MUST force the user to accept the default RG access code or install a new RG access code prior to allowing any initial configuration (e.g. during initial installation or after an RG reset to factory defaults).
MGMT.LOCAL.14 The user MUST be able to disable the use of the RG access code. The user MUST be warned in the Web GUI of the implications of undertaking this action.
MGMT.LOCAL.15 The RG MUST support updating of its firmware via the Web GUI and Broadband Forum TR-064i2 [158] interfaces.
MGMT.LOCAL.16 The RG MUST use standard protocols when using FTP, HTTP and HTTPS as defined in IETF RFCs 959, 2616, 5246, and 2818.
MGMT.LOCAL.17 The RG MUST support restarting the broadband connection (all layers) via the Web GUI and Broadband Forum TR-064i2 [158] interfaces.
MGMT.LOCAL.18 The RG SHOULD be able to copy log files to a PC on the local LAN or network server in ASCII text format, using the Web GUI and Broadband Forum TR-064i2 [158] interfaces.
MGMT.LOCAL.19 The RG MUST have a quick start page in the Web GUI allowing for rapid configuration in a minimum number of steps (e.g. on a single page). Default values for PPPoE and PVC can be used to facilitate this.
MGMT.LOCAL.20 The model and firmware/software versions MUST be easily identifiable via the Web GUI interface.
MGMT.LOCAL.21 The Web GUI interface MUST allow the user to browse and select an update file from a local PC and use HTTP to update the RG using this file (see IETF RFCs 1867, 2388 and HTML 4.1 specifications for more details).
MGMT.LOCAL.22 If the RG has been configured to do so, the Web GUI MUST allow the user to specify that firmware be updated from a predefined web location. The RG MUST allow the web location to be specified via the Web GUI and Broadband Forum TR-064i2 [158] interfaces.
MGMT.LOCAL.23 The web location MAY be predefined by the RG manufacturer. This value is overridden by the mechanisms and information identified in requirement MGMT.LOCAL.21.
MGMT.LOCAL.24 If the RG has been configured to allow updating from a predefined web location, the RG MUST display an update button in the Web GUI. The user can then select the update button to initiate an update using a file retrieved via ftp or http as identified in the associated URL (2 URLs may be hard coded; the second URL will be used if file retrieval is not possible from the first URL).

MGMT.LOCAL.25

If the RG has been configured to allow updating from a predefined web location, the mechanism used to identify the availability of an update, the description of the update and the actual update SHOULD operate solely based on the presence (or absence) of named files returned in a directory list using the web location URL.

For example, an RG might retrieve the directory list, find the update associated with the RG by the presence of the following file:

Vendor-model-v100210-n100215.pkg

This would identify that for device “model” from “vendor” currently running version 10.02.10 there exists an update whose version is 10.02.15. The text describing the update, if available, might be located in a file of the name:

Vendor-model-v100210-n100215.txt

MGMT.LOCAL.26 If the RG has been configured to do so, the Web GUI MUST display a web link to which the user may go to browse for update files and other update information. The RG MUST allow this URL to be specified and overridden by the Broadband Forum TR-064i2 [158] interfaces and from a Controller.
MGMT.LOCAL.27 The web link MAY be set to a default value by the RG manufacturer.

4.4.3.1 MGMT.LOCAL.TR-064 – TR-064 Issue 2

ID Requirement
MGMT.LOCAL.TR-064.1 The RG MUST support requirements defined in Broadband Forum TR-064i2 [158].
MGMT.LOCAL.TR-064.2 The RG SHOULD support logging of all Broadband Forum TR-064i2 [158] actions and events.

4.4.4 MGMT.REMOTE – Remote Management

4.4.4.1 MGMT.REMOTE.TR-069 – Remote Management (TR-069)

ID Requirement
MGMT.REMOTE.TR-069.1 The RG MUST support the remote management protocol as defined in Broadband Forum TR-069 [160] CPE WAN Management protocol.
MGMT.REMOTE.TR-069.2 The RG MUST support the latest version of Broadband Forum Device:2 [167] data model for CWMP (profile Baseline:3).
MGMT.REMOTE.TR-069.3 If the RG supports built-in file sharing clients (e.g. Windows networking, CIFS, Samba) or includes integrated storage server functions, the RG MUST NOT allow the use of the TR-069 file transfer mechanisms (i.e. upload and download RPCs) to place or retrieve files that are not explicitly authorized by the user on network shared storage locations to which the RG may have access.

4.4.4.2 MGMT.REMOTE.USP – Remote Management (USP)

ID Requirement
MGMT.REMOTE.USP.1 The RG MUST support the remote management protocol as defined in Broadband Forum User Services Platform (USP) [169].
MGMT.REMOTE.USP.2 The RG MUST support the latest version of Broadband Forum Device:2 [167] data model for USP.

4.4.4.3 MGMT.REMOTE.WEB – Remote Management (Web Browser)

This module applies to IPv6 as well as IPv4, but only if the RG has an IPv6 stack.

ID Requirement
MGMT.REMOTE.WEB.1 The RG MUST be able to allow temporary manual remote access to its web GUI remotely from the WAN interface.
MGMT.REMOTE.WEB.2 When temporary WAN side remote access is enabled to the RG, the remote access session MUST be started within 20 minutes and the activated session MUST time out after 20 minutes of inactivity.
MGMT.REMOTE.WEB.3 The user MUST be able to specify that the temporary WAN side remote access is a read only connection or one that allows for updates. The default MUST be read only.
MGMT.REMOTE.WEB.4 Temporary WAN side remote access MUST NOT allow for changing the RG password.
MGMT.REMOTE.WEB.5 Temporary WAN side remote access MUST be disabled by default.
MGMT.REMOTE.WEB.6 Temporary WAN side remote access SHOULD be through HTTP over TLS (i.e. https using TLS).
MGMT.REMOTE.WEB.7 The RG SHOULD use a randomly selected port for temporary WAN side remote access to prevent hacking of a well-known port.
MGMT.REMOTE.WEB.8 If a default port is used for temporary WAN side remote access, it MUST be 51003.
MGMT.REMOTE.WEB.9 The user MUST specify a non-blank password to be used for each temporary WAN side remote access session. This information MUST NOT be saved across sessions.
MGMT.REMOTE.WEB.10 The User ID for all temporary WAN side remote access sessions, if required based on the method of implementation, MUST be “tech” by default.
MGMT.REMOTE.WEB.11 The user MUST be able to change the User ID for all subsequent temporary WAN-side remote access sessions.
MGMT.REMOTE.WEB.12 The RG MUST allow only one temporary WAN side remote access session to be active at a time.
MGMT.REMOTE.WEB.13 Aside from the requirements in this profile, all other direct access to the RG from the WAN side MUST be disabled and blocked by default.

4.4.5 MGMT.NTP – Network Time Client

This module applies to IPv6 as well as IPv4, but only if the RG has an IPv6 stack.

ID Requirement
MGMT.NTP.1 The RG MUST support an internal clock with a date and time mechanism.
MGMT.NTP.2 The RG clock MUST be able to be set via an internal time client from an Internet source using RFC 1305 [52].
MGMT.NTP.3 The RG MUST support the use of time server identification by both domain name and IP (v4 or v6) address.
MGMT.NTP.4 If the RG includes default time server values, they SHOULD be specified by domain name and not by IP (v4 or v6) address.
MGMT.NTP.5 The RG SHOULD allow configuration of the primary and alternate time server values in addition to or in place of any default values.
MGMT.NTP.6 If the RG includes default time server values or if time server values are identified in documentation, these values SHOULD be selected using industry best practices for NTP and SNTP clients, as published in section 10 of RFC 4330 [106].
MGMT.NTP.7 The time client SHOULD support DNS responses with CNAMEs or multiple A or AAAA records.
MGMT.NTP.8 The default frequency with which the RG updates its time from a time server MUST NOT be less than 60 minutes, or use an operator-specific configuration.
MGMT.NTP.9 The default frequency with which the RG updates its time from a time server MUST NOT be greater than 24 hours, or use an operator-specific configuration.
MGMT.NTP.10 The frequency with which the RG updates its time from a time server SHOULD be able to be configured.

4.4.6 MGMT.TWAMP – Two Way Active Measurement Protocol

This module applies to IPv6 as well as IPv4, but only if the RG has an IPv6 stack.

ID Requirement
MGMT.TWAMP.1 The RG MUST support acting as a TWL Session-Reflector as defined in RFC 5357 [194] Two-Way Active Measurement Protocol Light (TWL).
MGMT.TWAMP.2 The RG MUST support static provisioning of the TWL Session-Reflector.
MGMT.TWAMP.3 The RG MUST disable the TWL Session-Reflector by default and MUST only allow it to be enabled by the management system.

4.4.7 MGMT.DATCOL – Data collection Requirements

4.4.7.1 MGMT.DATCOL.WIFIDIAG – Wi-Fi Diagnostics Data Collection

For measuring the WiFi experience in the home, these requirements specify which data is continuously collected about the state and performance of the home Wi-Fi network(s).

ID Requirement

MGMT.DATCOL.WIFIDIAG.1

The RG MUST support the collection of these operation parameters for each AP device it controls (integrated or connected in the home network) :

  • MAC address

  • Number of radios

MGMT.DATCOL.WIFIDIAG.2

The RG SHOULD support the collection of these parameters for each AP device it controls (integrated or in home network) :

  • Name

  • Model/Serial Number

  • HW/SW Version

  • CPU Usage

  • Memory Usage

MGMT.DATCOL.WIFIDIAG.3

The RG MUST support the collection of these operation parameters for each radio per AP device it controls (integrated or connected in the home network) :

  • MAC address

  • State

  • Current operating Channel

  • Current channel bandwidth

  • Current frequency band (2,4GHz, 5Ghz, 60Ghz)

  • WiFi signal strength (% of transmit power)

The RG SHOULD support the collection of these operation parameters for each radio per AP device it controls (integrated or connected in the home network) :

  • Country code

  • Channel Utilization (Total, Transmit, Receive)

  • Noise

MGMT.DATCOL.WIFIDIAG.4

The RG MUST support the collection of these neighborhood (channel scan) parameters from each radio per AP device it controls (integrated or connected in the home network):

  • Seen Channels and utilization

MGMT.DATCOL.WIFIDIAG.5

The RG SHOULD support the collection of these neighborhood station information from each radio per AP device it controls (integrated or connected in the home network):

  • BSSID

  • SSID

  • SignalStrength

MGMT.DATCOL.WIFIDIAG.6

The RG MUST support the collection of these configuration parameters for each AP per radio on all AP devices it controls:

  • BSSID

  • Encryption Mode (WEP, WPA2, WPA§ etc.)

  • Number of AP

  • SSID Advertisement status (on/off)

MGMT.DATCOL.WIFIDIAG.7

The RG MUST support the collection of these station parameters for each AP it controls:

  • Number of Connected Wireless Devices (STAs)

MGMT.DATCOL.WIFIDIAG.8

The RG MUST support the collection of these Wi-Fi station parameters per AP for each connected device (STA):

  • MAC address

  • Operating standard

  • CurrentUplinkRate

  • CurrentDownLinkRate

MGMT.DATCOL.WIFIDIAG.9

The RG SHOULD support the collection of these Wi-Fi station parameters per AP for each connected device (STA):

  • IP addresses (IPV4/IPv6)

  • Hostname

MGMT.DATCOL.WIFIDIAG.10

The RG SHOULD support the collection of these Wi-Fi station statistics for each connected device (STA):

  • Bytes and Packets send

  • Bytes and Packets received

  • Errors Sent and received