WAN.ATM.15

The RG MUST be able to perform an auto search for the VPI/VCI settings for the first PVC based on a definable search list VPI/VCI sequence order.

If the RG reaches a state of session establishment (e.g. IP when the RG is responsible for session termination) after performing the auto search, the default VPI/VCI settings MUST be set to the newly discovered values. The new default pair MUST be stored on the RG across power off situations. If an ATM connection cannot be established after power is restored, the search process starts over again.

WAN.CONNECT.3

The RG MUST support a “manual connect” option for connections. In this mode the connection to the broadband network is initiated manually through the Web GUI or via

TR-064i2 request and, by default, terminates only when done so explicitly by the user, due to a power loss or when the connection is lost.

WAN.BRIDGE.3

If bridge mode is enabled for IPv4 on the RG by default for LAN connected devices, the RG MUST be able to support additional connections to a Controller for remote management addressability (using direct DHCPv4 or static IPv4, PPP, etc.), and connections for any locally terminated service that require IP (v4 or v6) addressability (e.g. gateway integrated voice ATA ports, etc.).

Note that this special bridge mode that includes a device remote management session connection requires an additional WAN connection from the network. This requirement is considered conditional as a result of the network side dependency, but the RG must support this type of configuration.

WAN.DHCPC.1

The RG MUST be able to obtain IPv4 network information dynamically on its WAN interface. This information includes IPv4 address, primary and secondary DNS addresses and default gateway address.

Dynamically obtaining IPv4 network information is accomplished using DHCP (v4) and / or IPCP (IPv4).

WAN.DHCPC.5

The RG IAID value in DHCPv4 and DHCPv6 MUST be a 32 bit number encoded in network byte order. In cases where the RG is functioning with a single DHCP client identity, it MUST use value 1 for IAID for all DHCP interactions. IAID is defined in RFC 3315 [81].

In cases where the RG is functioning with multiple DHCP client identities, the values of IAID have to start at 1 for the first identity and be incremented for each subsequent identity. The RG’s mapping of IAID to its physical aspects or logical configuration SHOULD be as non-volatile as possible. For example, the RG MAY use IAID value 1 for the first physical interface and value 2 for the second. Alternatively, the RG MAY use IAID value 1 for the virtual circuit corresponding to the first connection object in the data model and value 2 for the second connection object in the data model.

WAN.DHCPC.7

A RG functioning as a DHCPv4 client MUST identify its manufacturer OUI, product class, model name and serial number using vendor-specific options as defined in RFC 3925 [91]. Specifically, it MUST use option 125.

Note that with exception of ModelName, the data contained in this option will be redundant with what is included in the Device ID in option 61. However, this is desirable because these two options serve different purposes.

The data in option 125 allows the DHCPv4 server to be pre-configured with policy for handling classes of devices in a certain way without requiring the DHCPv4 server to be able to parse the unique format used in client-identifier option (which can also vary in TR-181 depending on presence of a ProductClass value). On the other hand, the client-identifier serves as an opaque but predictable identifier. It is predictable because it is the same identifier as used by the RG for interactions with other services. The same identifier is used for HTTP authentication and in SSL client certificates.

Each sub-option value to be provided in option 125 MUST be treated as a string encoded into binary using UTF-8. The data MUST be encapsulated in option 125 under enterprise code 3561 decimal (0x0DE9), corresponding to the IANA “ADSL Forum” entry in the Private Enterprise Numbers registry. A specific sub-option is defined for each value. The value must match the corresponding TR-181 [35] parameter as defined in the following table:

If the value of a parameter is empty, the sub-option MUST be omitted.

WAN.DHCPC.BFDKA.13

When a BFD session on the RG receives a poll with a Diag code set to “Path Down” it MUST perform the following actions:

• Transition into the Down state;

• Respond to the poll with the Diag code set to 3 (“Neighbor Signaled BFD Session Down”)

• Prompt the DHCP client to transition into the Init-Reboot state for DHCPv4 initiated IP Sessions.

• Prompt the DHCP client to send a CONFIRM message for DHCPv6 initiated IP Sessions.

WAN.QoS.1

The RG MUST support classification of WAN directed LAN traffic and placement into appropriate queues (or discard) based on any one or more of the following pieces of information:

1. destination IP (v4 or v6) address(es) with subnet mask,

2. originating IP (v4 or v6) address(es) with subnet mask,

3. source MAC address,

4. destination MAC address,

5. protocol (TCP, UDP, ICMP, IGMP, …)

6. source TCP/UDP port and port range,

7. destination TCP/UDP port and port range,

8. IEEE 802.1Q Ethernet priority,

9. FQDN (fully qualified domain name) of WAN session,

10. Diffserv codepoint ([79]),

11. Ethertype (IEEE 802.3) length/type field),

12. traffic handled by an ALG,

13. IEEE 802.1Q VLAN identification.

14. Wi-Fi SSID and,

15. LAN type (Ethernet, WiFi, etc.).

WAN.QoS.11

The RG SHOULD support the appropriate mechanism to effectively implement Diffserv per-hop scheduling behaviors. The RG SHOULD be able to configure each queue defined in WAN.QoS.9 for strict priority or weighted round robin scheduling.

SP queues are served with priority over all other queues. A strict priority scheduler is preferred for EF.

WRR queues are served on the basis of configurable weights, provided with a mechanism to prevent starvation (WRR queue minimum bandwidth)

WAN.QoS.13

The RG MUST support per-class shaping of upstream traffic.

Classes are defined in WAN.QoS.4.

WAN.QoS.21

The RG SHOULD support classification of WAN directed internally generated traffic and placement into appropriate queues based on any one or more of the following pieces of information:

1. packet length.

LAN.DHCPS.1

The RG MUST provide application layer support for host name mapping, booting, and management including DHCPv4 and the Domain Name System (DNS) protocol. This includes support for the standards below:

• RFC 1034 [41] Domain Names – Concepts and Facilities

• RFC 1035 [42] Domain Names – Implementation and Specification

• RFC 2131 [57] Dynamic Host Configuration Protocol

• RFC 2132 [58] DHCP Options and BOOTP Vendor Extensions

• RFC 2181 [59] Clarifications to the DNS Specification

• RFC 2939 [72] Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types

LAN.DHCPS.19

The RG MUST support a single PC mode of operation. In this mode of operation only a single LAN device is supported. Note that this is not the default mode of operation.

In this configured mode, all network traffic, except for configured management traffic destined for the RG itself (e.g. temporary remote access to the Web GUI) MUST be passed between the access network and the designated LAN device as if the RG was not present.

One possible implementation is for the embedded DHCPv4 server to issue one and only one private address in this situation, with the start and stop addresses for the embedded DHCPv4 server being the same.

The LAN devices can be assigned either a private IPv4 address (i.e. using 1:1 NAT) or the public IPv4 address of the RG (i.e. using IP pass-through as identified in requirement LAN.ADDRESS.6). The type of IPv4 address to be used (private or public) is configured through the Web GUI, TR-064i2 interfaces and from a Controller. The default is a public IPv4 address.

If a WAN connection is not available when the RG is configured to use a public IPv4 address, the RG provides a private IPv4 address to the LAN device via DHCPv4. Once a WAN connection is established, the public IPv4 address provided by the broadband network is passed to the LAN device during the next DHCPv4 lease renewal.

The RG acts as the default gateway to the LAN devices when private IPv4 addressing is in use. When public IPv4 addressing is in use, the gateway identified to the LAN device should be that identified in requirement LAN.ADDRESS.6 above.

No other restrictions (e.g. restricted routing for other devices) need to be implemented to meet this requirement (e.g. no routing restrictions on traffic from secondary devices on the LAN).

LAN.DNS.3

When the RG learns DNS name server addresses from multiple WAN connections, the RG MUST follow specified DNS selection policy (if one is configured) to make recursive queries to DNS name servers, or (if there is no DNS selection policy) MUST query a server on each connection simultaneously and provide the requesting LAN client with the first returned positive result from these DNS servers. A negative response will not be transmitted to a LAN device until all WAN DNS servers have either timed out or returned a negative response to a common query.

Service providers may choose not to provide DNS name server addresses on certain connections in a multiple connection configuration.

LAN.PFWD.1

The RG MUST support port forwarding. That is, the RG MUST be able to be configured to direct traffic based on any combination of source IPv4 address, source protocol (TCP or UDP) and port (or port range) to a particular LAN device and port (or port range on that device).

Individual port forwarding rules MUST be associated with a LAN device, not the IPv4 address of the LAN device, and follow the LAN device should its IPv4 address change.

LAN.ALG.1

The RG MUST allow for pass-through of IPv4 traffic in which the payload is compressed or encrypted (e.g. VPN traffic).

This means that, as well as the RG, it must be possible that LAN CPE originate PPTP and L2TP sessions to an external network (over IPv4).

LAN.FWD.11

The RG MUST allow for the selection of which traffic to forward over which connection (in the case of multiple PVCs, multiple PPPoE sessions, etc.) according to any one or more of the following pieces of information:

1. IEEE 802.1Q VLAN identification, and

2. packet length (Note: to be used judiciously to avoid out of order packet delivery).

LAN.FW.SPI.7

The RG MUST support the user specifying the order in which firewall rules are processed.

Note: not all firewall rules need be included under the scope of this requirement.

LAN.FW.SPI.13

In addition to blocking or passing traffic identified by a firewall filter, the RG MUST support other actions as well, including but not limited to:

• logging on success or failure,

• notification on success or failure (to email or pager if supported),

• sending notification to a PC monitor application (either originator and or centralized source), and

• requesting verification from a PC monitor application.

LAN.DIAGNOSTICS.1

If the RG is on the same subnet as any LAN device, when network connectivity problems occur, the RG MUST provide a mechanism that intercepts web browser pages (i.e. port 80 web page requests) and responds to these by directing the web browser to appropriate internal web pages to identify and resolve network connectivity problems including but not limited to:

• DSL cannot train

• DSL signal not detected

• Broadband Ethernet not connected (if applicable)

• ATM PVC not detected (if applicable)

• IEEE 802.1x failure (if applicable)

• PPP server not detected (if applicable)

• PPP authentication failed (if applicable)

• DHCP not available

LAN.CAPTIVE.1

The RG MUST support a redirect function, which, when enabled, intercepts WAN destination IP (v4 or v6) HTTP requests and responds to these by substituting a specified URL in place of the web page request.

The URL, as well as a list of locations for which this redirect would be bypassed (i.e. white list), MUST be settable from a Controller.

The actual captive portal to be redirected to may be established at the time the white list is defined or the white list may be defined first and the captive portal specified at a later time.

LAN.CAPTIVE.7

Variable length subnet masking (VLSM) MUST be supported in the redirect white list. For example:

• Individual IPv4 address:

  • ipaddress or

  • ipaddress/32 or

  • ipaddress 255.255.255.255

• Range of 64 IPv4 addresses:

  • ipaddress/26 or

  • ipaddress 255.255.192.0

LAN.QoS.1

The RG MUST support classification of LAN directed WAN traffic and placement into appropriate queues (or discard) based on any one or more of the following pieces of information:

1. destination IP address(es) with subnet mask,

2. originating IP address(es) with subnet mask,

3. Diffserv codepoint ([79]),

4. protocol (TCP, UDP, ICMP, IGMP …),

5. source TCP/UDP port and port range,

6. destination TCP/UDP port and port range

In an ATM based access network:

1. ATM VPI/VCI

Where Ethernet is present on the access link:

1. source MAC address,

2. destination MAC address,

3. IEEE 802.1Q Ethernet priority,

4. Ethertype (IEEE 802.3) length/type field), and

5. IEEE 802.1Q VLAN identification.

LAN.QoS.3

The RG MUST support classification of LAN directed traffic and placement into appropriate queues (or discard) based on any one or more of the following pieces of information:

1. source MAC address, and

2. destination MAC address.

LAN.QoS.9

The RG SHOULD be able to configure each queue for strict priority or weighted round robin scheduling.

Strict priority queues are served with priority over all other queues. WRR queues are served on the basis of configurable weights.

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.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.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.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.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.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.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

IF.WAN.VDSL2.5

The RG MUST include support for the following application reference models from ITU-T G.993.2 [166]:

• G.993.2 clause 5.4.2, Data with POTS service

• G.993.2 clause 5.4.1, Data service (no POTS or ISDN)

IF.WAN.VDSL2.11

[Europe] The RG MUST include support for the following application reference model from ITU-T G.993.2 [166]:

• G.993.2 clause 5.4.3, Data with ISDN service

IF.WAN.xDSL.BOND.3

If the RG supports DSL bonding, the RG MAY support the following parameters in the Web GUI and in vendor-specific extensions to Broadband Forum TR-064i2 [2] and TR-181:

– Group parameters (per group instance):

• Group ID (group number assigned from ATM based xTU-C)

• Status (valid values include: Operational, Unavailable)

• Number of links (number of DSL links in the group)

• RX cell loss (total number of cells lost in the receive direction for all ATM links)

– Link parameters (per link instance):

• Group ID (to which the link is a member for all ATM links)

• Link status (valid values include: Not in use, Standby, Available)

• Data rate (Should return the TC-layer data rate in bits/sec (in case of ATM, the ATM cell rate at the ATM layer after removal of idle/incorrect cells)

IF.WAN.xDSL.BOND.9

The RG MUST allow manual configuration of the following bonding options:

• DSL line 1 only (single xDSL link on inner pair only if a single jack, or jack 1 if presented on separate jacks)

• DSL line 2 only (single xDSL link on outer pair only if a single jack, or jack 2 if presented on separate jacks)

• xDSL bonding (both xDSL links) using pairs for bonding described in IF.WAN.xDSL.BOND.5 and 6).

IF.WAN.xDSL.REPORT.1

The RG MUST be capable of reporting a DSL Re-Initialization Cause Code parameter to the Controller. When the RG re-initializes its DSL connection, it MUST store, in non-volatile memory, a code indicating the cause of the re-initialization. After re-initialization and after a data connection is available to the Controller, the RG MUST report to the server the cause code. At a minimum, the following cause codes MUST be supported:

1. Autonomous re-initialization of the DSL connection

2. Loss of local power

3. External re-initialization, e.g. via a local reset

4. Cause not determined

IF.WAN.xDSL.SURGE.1

The RG MUST tolerate an AC surge, as specified in EN 61000-4-5, test level 3;

• Criterion 1: The RG MUST NOT – as a result of the surge – transmit or receive bit errors for more than 2 seconds.

• Criterion 2: The RG MUST NOT – as a result of the surge – re-initialize.

• Criterion 3: The RG MUST NOT – as a result of the surge – transmit a dying gasp message.

IF.WAN.ETH.5

The RG MUST support configuring the current default WAN port being used via Web GUI or from a Controller.

This should result in the RG immediately switching to the selected port.

IF.WAN.MoCA.3

The RG MUST provide a facility to enable or disable the MoCA WAN port via the Web GUI, Broadband Forum TR-064i2 [2] interfaces and from a Controller.

Note: The ability to remotely disable the port is intended for RGs with more than one WAN port.

IF.WAN.MoCA.15

The MoCA WAN network MUST support the following sustained aggregate MAC throughput with PER < 1E-6 with 50 db attenuation (measured aggregate MAC throughput is based on 1500 byte packets, independent of the traffic pattern):

• 125Mbps with 2 MoCA devices in the network

• 117.5Mbps with 3 MoCA devices in the network

• 110.5Mbps with 4 MoCA devices in the network

• 103.8Mbps with 5 MoCA devices in the network

• 98Mbps with 6 and above MoCA devices in the network.