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 [84].

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 [94]. 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 [167] 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 ([82]),

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.