HGI-RD027-R3 Home Gateway QoS Module · PDF file... Celeno, Cisco, Deutsche Telekom, Devolo, Dialog Semiconductor, D-Link Corporation, ... 31 PLC PowerLine ... Home Gateway QoS Module

Home Gateway Initiative – 2012 – All Rights Reserved

1 2

3

4

5

6

7

8

HGI-RD027-R3 9

Home Gateway QoS Module requirements 10

11

12

Dec 1, 2012 13

14

15

16

HGI_RD027-R3

Home Gateway QoS Module Requirements for IPv4 and IPv6

Page 2 of 35 © Home Gateway Initiative – 2012 – All rights reserved

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

PAGE LEFT INTENTIONALLY BLANK 32 33

HGI_RD027-R3



Table of Contents 1

2 1 Important notice, IPR statement, disclaimer and copyright .................................................... 4 3 2 Acronyms ................................................................................................................................ 5 4 3 Introduction ............................................................................................................................. 7 5

3.1 Scope and purpose of this document ..................................................................................... 7 6 3.2 Definitions of terms ................................................................................................................. 7 7

4 Quality of Service Architecture Update .................................................................................. 8 8 4.1 Release 2 Residential Profile QoS Architecture..................................................................... 8 9 4.2 Typical Home Network ........................................................................................................... 8 10 4.3 Impact of IPv6 ........................................................................................................................ 9 11

4.3.1 IP Tunneling ......................................................................................................................... 11 12 4.3.2 DHCP Options ...................................................................................................................... 11 13

4.4 ALA Support ......................................................................................................................... 11 14 4.5 Diagnostics ........................................................................................................................... 12 15 4.6 New Classifiers ..................................................................................................................... 12 16

4.6.1 IP Version ............................................................................................................................. 12 17 5 Additional Use Cases ........................................................................................................... 13 18

5.1 OTT Service Support ............................................................................................................ 13 19 5.2 In-home QoS ........................................................................................................................ 14 20

6 HG QoS Requirements ........................................................................................................ 15 21 6.1 Classification of packets received upon the WAN ingress port ............................................ 15 22 6.2 Multi-field Classification of packets received on the LAN ingress ports ............................... 17 23

6.2.1 Classification of packets received on the LAN ingress using information determined via 24 DHCP ................................................................................................................................... 18 25

6.3 Classification of bridged packets received on the LAN ingress ports .................................. 19 26 6.4 Classification of internally generated packets ...................................................................... 20 27 6.5 LANside VLAN support ........................................................................................................ 21 28 6.6 WANside VLAN support ....................................................................................................... 21 29 6.7 Tunnel QoS .......................................................................................................................... 21 30 6.8 Classification Rule Sets ........................................................................................................ 22 31

6.8.1 Overview ............................................................................................................................... 22 32 6.8.2 Classification Rule Sets ........................................................................................................ 22 33 6.8.3 Sequencing Among Classification Rule Sets ....................................................................... 23 34

6.9 Overload Protection Mechanism .......................................................................................... 23 35 6.10 QoS Mappings ...................................................................................................................... 24 36

6.10.1 Integrated Non-Ethernet Technologies ................................................................................ 24 37 6.11 Dropping/Congestion Management ..................................................................................... 25 38 6.12 Class Queue structure and Scheduling ................................................................................ 26 39

6.12.1 Queuing into the WAN Egress port ...................................................................................... 26 40 6.12.2 Queuing into the LAN Egress ports ...................................................................................... 27 41 6.12.3 Example Queuing Configuration .......................................................................................... 27 42

6.13 Admission Control ................................................................................................................ 28 43 6.13.1 B2BUA requirements for CAC using SIP signalling ............................................................. 29 44

6.14 DLNA Coexistence Guidelines ............................................................................................. 30 45 7 Management......................................................................................................................... 31 46

7.1 QoS Requirement Mapping to TR-098 [4] ............................................................................ 31 47 References 35 48 49

HGI_RD027-R3



1 Important notice, IPR statement, disclaimer and 1

copyright 2

The Home Gateway Initiative (HGI) is a non-profit making organization created to define guidelines 3 and specifications for broadband Home Gateways. 4

This document is the output of the Working Groups of the HGI and its members as of the date of 5 release. Readers of this document should be aware that it can be revised, edited or have its status 6 changed according to the HGI working procedures. 7

The HGI makes no representation or warranty on the contents, completeness and accuracy of this 8 publication. 9

This document, though formally approved by the HGI member companies, is not binding in any part 10 on the HGI members. 11

IPRs essential or potentially essential to the present document may have been declared in 12 conformance to the HGI IPR Policy and Statutes available at the HGI website www.homegateway.org . 13

Any parts of this document may be freely reproduced (for example in RFPs and ITTs) by HGI and 14 non-HGI members subject only to the following: 15

HGI Requirement numbers not being changed 16

an acknowledgement to the HGI being given in the resulting document. 17

Trademarks and copyrights mentioned in this document are the property of their respective owners. 18

19 The HGI membership list as of the date of the formal review of this document is: Actility, Advanced 20

Digital Broadcast, Alcatel-Lucent, Arcadyan, Arm, Belgacom, Bouygues Telecom, Broadcom, Broadlight, 21 BT, Cavium, Celeno, Cisco, Deutsche Telekom, Devolo, Dialog Semiconductor, D-Link Corporation, DSP 22 Group, ECE Paris, eflow, Ericsson AB, Fastweb SpA, France Telecom, Hitachi, Huawei, Ikanos, Intel, 23 IS2T, KDDI, KPN, LAN, Lantiq, Marvell Semiconductor, Mindspeed, Mitsubishi, MStar, NEC Corporation, 24 Netgear, NTT, Oki Electric Industory, Ping Communication, Portugal Telecom, ProSyst, Qualcomm 25 Atheros, Sagemcom, Samsung, Sercomm Corp., Shenzhen GongJin Electronics, Sigma, SoftAtHome, 26 Stollmann, Sumitomo, Swisscom AG, Technicolor, Telecom Italia, Telekom Austria, Telekom Slovenije, 27 Telekomunikacja Polska, TeliaSonera, Telstra, TNO, Trac Telecoms & Radio Ltd, Transwitch, Vodafone, 28 Vtech, Wind River Systems, Zarlink, ZTE, ZyXEL. 29

30

http://www.homegateway.org/

HGI_RD027-R3



2 Acronyms 1

3G Third Generation (mobile) 2

6rd (IPv) 6 Rapid Deployment 3

ALA Active Line Access 4

ASP Application Service Provider 5

AVB Audio Video Bridging 6

B2BUA Back to Back User Agent 7

BSP Broadband Service Provider 8

CAC Call Admission Control 9

CPE Customer Premises Equipment 10

DA Destination Address 11

DHCP Dynamic Host Configuration Protocol 12

DLNA Digital Living Network Alliance 13

DNS Domain Name Server 14

DSCP Differentiated Services Code Point 15

DSL Digital Subscriber LineEU End User 16

GPON Gigabit Passive Optical Network 17

HG Home Gateway 18

HGI Home Gateway Initiative 19

HN Home Network 20

HNID Home Network Infrastructure Device 21

ICMP Internet Control Management Protocol 22

ID Identity 23

IGM Internet Group Management Protocol 24

ISP Internet Service Provider 25

LAN Local Area Network 26

MAC Media Access Control 27

NGA Next Generation Access 28

NT Network Termination 29

OTT Over The Top (services) 30

PLC PowerLine Communications 31

PLT PowerLine Technology 32

PVR Personal Video Recorder 33

QoS Quality of Service 34

RED Random Early Discard 35

SA Source Address 36

HGI_RD027-R3



SBG Service Border Gateway 1

SIP Session Initiation Protocol 2

STB Set Top Box 3

SWEX Software Execution Environment 4

TCP Transmission Control Protocol 5

TOS Type of Service 6

UDP User Datagram Protocol 7

URL Universal Resource Locator 8

VAS Value Added Service 9

VDSL Very high-speed Digital Subscriber Line 10

VLAN Virtual Local Area Network 11

VID VLAN Identity (value) 12

WAN Wide Area Network 13

WMM Wireless Multi Media 14

WRED Weighted Random Early Discard 15

WRR Weighted Round Robin 16

17

HGI_RD027-R3



3 Introduction 1

3.1 Scope and purpose of this document 2

The HGI activity is largely predicated on the need to provide support for services which require 3 Quality of Service. The HGI Residential Profile in Releases 1 and 2 had a large Section dedicated to QoS. 4 While this focused on QoS management through the Gateway itself, it also took into account both the LAN 5 and WAN connections to the various services. 6

In Release 3, a modular approach has been adopted for the specification of home gateway 7 requirements. In addition to a core residential profile, areas of significant detailed functional specification 8 are moved to separate specification “modules”. This document is the QoS specification for Release 3. It 9 covers the same ground, with updates, as the QoS sections in Releases 1 and 2. The main technical 10 update in comparison with the QoS section of the Release 2 Residential Profile is the addition of explicit 11 support for IPv6. This is covered by both generic statements of applicability, and a small number of IPv6-12 specific requirements. This is intended to cover all the various deployment and migration options, e.g. full 13 IPv4, full IPv6, dual stack, DSlite and 6rd. 14

There have also been a number of changes with regard to the explanatory content, and to the 15 structure of the document. 16

As some of the concepts were novel at the time of Releases 1 and 2, there was a fairly large 17 amount of explanatory material covering both the QoS architecture, and the Use Cases which drove the 18 work from a commercial perspective. This was subsequently published in a QoS White Paper [2] and so 19 has not been retained here. There is however a brief architectural update which covers how home 20 networking has evolved in practice, and the impact of IPv6. 21

The Release 2 Residential Profile also had a rather complex way of defining optional features. In 22 addition to the usual MUST-SHOULD distinction, there was an identification scheme which could denote 23 whole sections as options, and allow ‘conditional’ mandatory requirements. This turned out to be too 24 complicated to be useful and so has been removed. 25

Finally there have been a small number of corrections and clarifications to the Release 2 Residential 26 Profile requirements. 27

28

3.2 Definitions of terms 29

The definitions of MUST and SHOULD in this document are therefore as follows: 30

MUST A functional requirement which is based on a clear consensus among HGI Service 31 Provider members, and is the base level of required functionality for a given class 32 of equipment. 33

MUST NOT This function is prohibited by the specification. 34

SHOULD Functionality which goes beyond the base requirements for a given class of 35 equipment, and can be used to provide vendor product differentiation (within that 36 class). 37

Note: These definitions are specific to the HGI and should not be confused with the same or similar 38 terms used by other bodies. 39

40

41

HGI_RD027-R3



4 Quality of Service Architecture Update 1

4.1 Release 2 Residential Profile QoS Architecture 2

The HGI QoS Architecture used in the Release 2 Residential Profile is shown in Figure 1. This 3 identified all three directions of traffic flow through the HG, namely WAN-LAN, LAN-WAN and LAN-LAN, as 4 being potential congestion points (depending on the technology and/or access products) and therefore all 5 needing separate QoS classification, queuing and scheduling. 6

Ethernet

Switch

Ethernet-PLT

bridge

Low-rate

upstream

Access

High-rate

downstream

Access

100

Mbps

100

Mbps<10 Mbps

Wireless

LAN

HG

High-rate to

low-rate

bridge

Merging

WAN-LAN

and transit

traffic

100

Mbps

100

Mbps

100

Mbps

7

Figure 1 Home Network Architecture and possible congestion points 8 9

4.2 Typical Home Network 10

A typical Home Network (as of 2012) is rather more as shown in Figure 2. Most of the same elements are 11 there, with the exception of the external Ethernet switch. Wireless is being used more and more; although 12 laptops are the only wireless attached devices shown, there is also greatly increased use of WiFi-attached 13 Smartphones and tablets which use Broadband as opposed to 3G when the device is in the home (for cost 14 and performance reasons). It is still the case that all 3 directions of traffic flow through the HG can result in 15 congestion; The Release 2 Residential Profile foresaw the use of higher speed access technologies such 16 as VDSL and GPON which are indeed now being widely deployed. Although uplink speeds may also 17 increase significantly as a result, they still lag a lot of home network technologies; further, in some cases, 18 the upstream product rate is less than the physical line rate. Although wireless rates have also increased, 19 the demands on aggregate in-home bandwidth are also increasing and wireless still suffers from significant 20 temporal variability. Therefore wired technologies, both ‘old-wire’ such as PLT and phoneline, and new-wire 21 Ethernet will continue to play a role. In the case of Ethernet, this is typically used for local, in-room 22 connection via a patch cord; there is still little deployment of residential structured cabling. Many HGs 23 provide multiple Ethernet ports, and so the use of additional external Ethernet switches is not that common. 24 The use of in-home VLANs for QoS purposes was not supported in The Release 2 Residential Profile 25 because of the management complexity, and concerns that simple switches would drop tagged packets. 26 Given the low incidence of external in-home switches, there is no case for now introducing in-home VLAN 27 based QoS. 28

HGI_RD027-R3



1 Therefore the basic QoS architecture is largely unchanged, which means that all the Release 2 Residential 2 Profile requirements are still appropriate. 3

4 Figure 2 – Typical Home Network 5

6

4.3 Impact of IPv6 7

IP addresses and other IP header elements were used as classifiers in various ways in The Release 8 2 Residential Profile. The actual address can be used in identifying a service which has a unique Service 9 Border Gateway, either as the source or destination address depending on the direction of the flow. There 10 is also an address mask which can be configured so as to look for a match with any one of a range of 11 contiguous addresses without needing to specify each individual address in the classifier. 12

Other fields within the IPv4 header which are designated Classifiers are: 13

the 6 DSCP bits of the Type of Service field 14

packet length 15

protocol type 16

It is necessary to consider whether the same fields are available in the IPv6 context, and whether 17 there are any new, IPv6 specific header fields, in particular the flow label, that might be useful. 18

The IPv4 and IPv6 header formats are shown in Figure 3 (below). Although not obvious at first sight, 19 all three of the above are included in some way. The IPv6 Traffic Class is similar to the DSCP field of the 20 IPv4 Type of Service Field, but originally had 8 bits as opposed to the 6 of DSCP. However the original 21 header field names (IPv4 TOS and IPv6 Traffic Class) have now been superseded by a common name, the 22 DS Field (RFC2474). The first 6 bits of this field represent the Diffserv Code Point. The terms ‘DSCP 23 marking’, ‘DSCP value’ or ‘DSCP bits’ will be used when referring to this (6 bit field) in this document. The 24 same term is applicable to both IPv4 and IPv6 packets, and so there is no need for a distinguishing 25 qualifier. 26

HGI_RD027-R3



While both headers have a length field, for IPv6 this is the payload length, whereas for IPv4 it is the 1 entire packet length i.e. payload + header. In fact to be more precise, the IPv6 payload length is the 2 number of bytes after the payload length field itself, so it does include the majority of the header, in 3 particular the 32 address bytes. Only the first 6 bytes are not included in the length. From a classification 4 point of view, it is the entire length of the packet that matters, as this determines the playout time, and 5 hence delay, that a packet can cause to another queued packet. The Broadband Forum management 6 object for packet length does include the header, but makes no distinction between IPv4 and v6 packets. 7 Technically the HG should add 6 bytes to the IPv6 payload length before comparing it with the configured 8 packet length classifier. However packet length was never intended to be a very accurate, fine-grained 9 classifier, but is simply used to distinguish between short and long packets, so this correction is not really 10 necessary. 11

IPv6 lacks an explicitly named protocol field, but in fact the protocol type is one of the possible 12 extension headers. 13

Therefore all 3 of the header fields used in The Release 2 Residential Profile can be used in this 14 document for IPv6, albeit with some caveats and explanation. 15

The Flow Label field might appear to be a candidate for QoS management, and indeed this was one 16 of its original intended purposes. The Source can generate a unique label for each application flow to a 17 given Destination. The idea is to able to efficiently identify these application flows in intermediate routers so 18 that all the packets of a given flow can be given the same, special treatment with regard to QoS and 19 routing. However there are some issues with using the Flow Label, in particular no standard way of 20 signalling the Flow labels and the required treatment to the intermediate routers. Further, these nodes are 21 not supposed to change the Flow Label, but as it is not protected by a checksum, then its use constitutes a 22 security risk. 23

Flow Labels do not fit well with the HGI QoS architecture. As noted above, the main focus of HGI 24 QoS remains managing traffic through the HG itself (albeit with some extensions into the HNID area), and it 25 is largely class-based. In contrast, Flow Labels are about a co-ordinated end to end scheme, and are 26 application instance-based. 27

Therefore the use of Flow Labels has not been defined in this document. 28

29

IPv6 header

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|Version| Traffic Class | Flow Label |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Payload Length | Next Header | Hop Limit |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| |

+ +

| |

+ Source Address +

| |

+ +

| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| |

+ +

| |

+ Destination Address +

| |

+ +

| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IPv4 header

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|Version| IHL |Type of Service| Total Length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Identification |Flags| Fragment Offset |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Time to Live | Protocol | Header Checksum |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Source Address |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Destination Address |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Options | Padding |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

DS field

0 1 2 3 4 5 6 7

+-+-+-+-+-+-+-+-+

| DS field(DSCP)|ECN|

+-+-+-+-+-+-+-+-+

HGI_RD027-R3



1

Figure 3 - IPv4 and IPv6 Frame Formats 2

3

4.3.1 IP Tunneling 4

BSPs face various challenges with the introduction of IPv6, one of the major ones being the need for 5 a smooth, incremental migration path which allows the various network element types to be upgraded as 6 and when appropriate, i.e. not a big-bang change-out. Further, support for IPv4 will need to be maintained 7 for the foreseeable future. One of the migration techniques being employed is therefore to use tunnelling 8 techniques whereby IPv6 packets are encapsulated in IPv4 packets across the Access and up to the edge 9 of the IPv6 routeable domain (this is the technique used in 6to4 and 6rd). 10

In the HGI context, the tunnel end-point would be the HG, and would allow IPv6 hosts on the Home 11 Network to communicate with IPv6 services/servers via the tunnel. 12

IPv6 tunnelling is not the only tunnel type that an HG might need to support. One variant of IPSec 13 also uses tunnels, and again these would terminate in the HG itself. 14

Although the main focus of HGI QoS is not as part of an end to end scheme, there are some aspects 15 which do use or propagate QoS information on the WANside; in particular ingress DSCP markings can be 16 used in classification, and egress DSCP markings can be set as a result of classification. 17

The use of tunnels can complicate this, in particular there is the issue of whether the inner packet 18 markings are accessible. There is also a subtlety with regard to the different way packet length is 19 expressed in v4 and v6. 20

These have been handled in the following ways. With regard to DSCP markings, there is no way of 21 knowing if the far end of the tunnel has copied these markings to the outer header, or the intention if there 22 is a discrepancy between the 2 sets of markings. Therefore the tunnel header must be removed before 23 ingress classification. This also means that packet length classification does not need to worry about 24 tunnelling; the impact of the different meaning of the length field in v4 and v6 is so small that it can be 25 ignored. It may however be useful for the network to have DSCP markings in the outer header, and so 26 there is an optional requirement for the HG to copy these bits from the inner to the outer header of 27 tunnelled egress packets. 28

These are written as generic tunnel requirements and therefore apply to all tunnel types, e.g. 6/4 29 and IPSec tunnels. 30

4.3.2 DHCP Options 31

The Release 2 Residential Profile used various DHCP Options (60, 61, 77 and 125) to identify 32 various CPE devices or device types so their MAC address or private IP address could be automatically 33 learned by the HG. Although there is the same wish to do this for IPv6 CPE, DHCPv6 does not have the 34 same Options, only supporting 1 of the above 4, and with a different Option number. Therefore the DHCP 35 Option requirements have been made v4 and v6 specific. 36

4.4 ALA Support 37

Although the main focus of The Release 2 Residential Profile was an integrated HG in the sense 38 that the access technology (e.g. ADSL modem) was embedded in the HG, there was also recognition that 39 in some circumstances a so called 2-box model, in which there is a separate modem, connected to the HG 40 via (wired) Ethernet was appropriate. This was not a widespread deployment model for ADSL, and so 41 these were written as guidelines rather than requirements [3]. 42

However with the advent of higher speed ‘NGA’ with VDSL or GPON access, then use of the 2-box 43 model may increase; in the VDSL case for performance reasons, and for (shared-medium) PON, because 44 of network integrity concerns. Therefore the HGI is developing a more formal specification for a standalone 45 NT containing actual requirements. Such a device is known as an ALA NT, as this is the generic term 46

HGI_RD027-R3



increasingly used for Wholesale Layer 2 (Ethernet) access. The ALA NT obviously needs to work in 1 conjunction with the HG from the QoS - and other - perspectives. 2

As ALA is a L2 Ethernet service, the QoS is based solely on the use of .1p bits and VIDs. It has no 3 L3 (or above) capability, and therefore cannot carry out the more complex service signature approach of 4 the HG. Extending the HGI QoS model to include ALA has therefore been done as follows: 5

The HG will continue to carry out per packet classification based on the service signature 6 approach. 7

In an ALA 2-box deployment, the HG will be able to add a VLAN or priority tag to an egress 8 frame, and set the .1p bits to the value configured for that service on the basis of the service 9 signature. The ALA NT will then use these for its upstream scheduling. ALA QoS is also 10 class-based, and so different applications or instances can map to the same ALA QoS class. 11

The HG will be able to use WANside .1p and/or VID values for ingress classification. 12

Note that nearly all the requirements to support this were already included in The Release 2 13 Residential Profile. These have however been reworded and made more explicit with regard to adding 14 VLAN tags, and separating out the setting of DHCP and .1p bits. 15

4.5 Diagnostics 16

The Release 2 Residential Profile defined a set of counters for the various queues with a view to 17 troubleshooting. This approach has been further refined in the forthcoming HGI Diagnostics Specification, 18 the main differences being (a) the addition of the concept of a single, service-specific counter capability, (b) 19 the requirement to support much shorter sample intervals (down to 1 second), and (c) being more 20 prescriptive as to how and where counts are stored in the HG. While there are some diagnostics 21 requirements which are specifically related to QoS, in particular service specific diagnostics, these are 22 covered in the Diagnostics Requirements Specification, and not here 23

4.6 New Classifiers 24

4.6.1 IP Version 25

All of the above have resulted in a very small number of changes. There is only one fundamentally 26 new Classifier, IP Version (6 or 4). The reason for adding this is that certain QoS aspects may need to be 27 applied, or not, to v4 or v6 applications as a Class. There are a small number of new requirements, 28 primarily to do with being specific, where necessary, as to the IP version. 29

HGI_RD027-R3



5 Additional Use Cases 1

The original Use Cases which drove the HGI QoS requirements can be found in the QoS White 2 Paper [2]. There have been a small number of new Use Cases since which have impacted this document, 3 most of which have already been discussed in the Architecture Section. Since these are fairly self-evident, 4 the following do not need further detailed description: 5

1. Support for IPv6 6

2. Support for IPv6 migration technologies 7

3. ALA QoS Support 8

Two other Uses Cases were discussed, OTT Services, and greater support for in-home QoS, going 9 beyond simple L2 QoS mapping to techniques such as in-home admission control. The first of these was 10 accepted, although the impact on the QoS requirements identified so far is limited, but the other has only 11 been adopted in part. 12

5.1 OTT Service Support 13

While BSPs can and do sell value added services (VASs), in particular video, there is now a significantly 14 higher usage of ‘free’ OTT services. In principle, the HGI service signature technique can also be applied to 15 OTT services, although any peer to peer service will normally lack one of the more commonly used 16 signature components, the SBG address. The other issues with OTT services are the commercial model, 17 and configuration. 18

OTT services simply depend on Internet connectivity, and the BSP (or ISP) is generally not aware of these 19 services (although DPI devices can detect them), and does not directly benefit from their transport. Classic 20 OTT service examples are Internet video (e.g. YouTube), VoIP (e.g. Skype), peer to peer file-sharing, 21 Webcams, Gaming and Instant Messaging. 22

OTT services can have disadvantages for BSPs in that they may drive network traffic growth without any 23 associated revenue, and can also adversely impact the customer experience of browsing. The response 24 adopted so far has been the use of network-based DPI devices to throttle certain application types; there 25 are sometimes concerns about ‘net neutrality’, but most BSPs have 'fair-use violations' in their Terms and 26 Conditions which allow them to do this. 27

An alternative approach is to consider if there is a potential opportunity here for BSPs. Is it possible to 28 improve an Internet delivered, OTT service by some network action, does any of this impact the HG and is 29 there a viable business model ? 30

One of the problems with trying to add QoS to OTT services is that they are delivered over the Internet 31 which in general has no QoS support, and most of the traffic is downstream, especially for video services. 32 Therefore by the time the traffic gets to the HG it is too late to do anything to improve its quality. 33

However there are some OTT services which are more upstream oriented, or bi-directional which might 34 benefit from upstream prioritisation; examples include VOIP, Webcams and network based games. The 35 HGI QoS signature model is very flexible but it is harder to use one of the most common classifiers, the IP 36 Address, with OTT services. This is because either the service is truly peer to peer, in which case the IP 37 Address of the far end is different every time, and cannot be preconfigured by the BSP, or where there is 38 the equivalent of a SBG, for example a video server, there could be a very large number of them, and 39 again their addresses are not known in advance. 40

There are various ways in which these problems might be overcome. 41

1. Dynamically and automatically learning the address of an OTT SBG 42

2. Using port number 43

3. Using packet length 44

4. Using a CPE hardware device identifier 45

HGI_RD027-R3



Before considering these in any detail, it is appropriate to consider the business model for OTT 1 support. In the case of a BSP VAS, then the SP gets direct financial benefit from delivering the service with 2 appropriate QoS. For an OTT service then there also needs to be some commercial benefit, but this may 3 be neither direct nor financial. There are 2 options. The BSP could contract with individual OTT SPs to 4 prioritise their services, but this would be very difficult, not least because of the number of SPs involved. 5 More importantly, as the QoS scheme is based on prioritisation, then if a given end-user took the same 6 type of service from more than OTT provider, then the individual OTT SPs might not get the kind of 7 performance improvement they were expecting. Further, the OTT SP would have to provide the BSP with 8 details of each of its users so the BSP could configure the HG. 9

A more tenable model would be for the BSP to contract directly with the end-user to prioritise 10 services according to the End User’s wishes. The BSP could then take a sensible, holistic view of the set of 11 services, and would know (by definition) which HGs to configure, and how. This presumes that 12 configuration remains in the hands of the BSP; an alternative would be to give the End User direct QoS 13 configuration control, but this would mean that the BSP would lose the holistic view, and control, in a way 14 that might impact their own VASs. 15

Therefore the most viable commercial model seems to be a direct relationship between the BSP and 16 End User, but with the BSP retaining configuration control. 17

Returning to the above 4 service-signature options. (1) could potentially be done via DNS. If the HG 18 were configured with the IP address of the DNS server, then it could snoop DNS lookup requests, and 19 associate a URL with the IP address of the service. The End User could specify a list of URLs that he 20 wished to have prioritized which the BSP could configure in the HG. In fact the HG itself could do the DNS 21 lookup and preconfigure the rule rather than snoop. Various elements of this approach are covered by 22 existing Requirements (e.g. dynamic rule setting), but it needs to be worked through in greater detail and 23 so is for further study. Option 2 is not viable, as many peer to peer applications use randomly selected port 24 numbers; Skype specifies any port number >1024. Option 3 could work on applications that had short 25 packet lengths, e.g. voice and games but on its own does not distinguish between application examples, 26 i.e. it would prioritize any voice service. The most promising approach might be (4). There are already 27 mechanisms to classify on the basis of hardware device ID (MAC address, vendor ID). These could be 28 used to identify dedicated devices such as IP phones, but would not be useful for a soft client on a PC. 29 However a combination of device ID, packet length and port number might be a possibility. 30

Therefore the existing QoS scheme has some of the elements needed for the support of OTT 31 services. It may simply be a case of working through the options in more detail and providing configuration 32 guidance in a subsequent White Paper. 33

5.2 In-home QoS 34

Enhancing QoS in the Home Network itself (as opposed to through the HG home gateway) can range from 35 upgrading the guidelines on HNID QoS to make them actual requirements, through to in-home bandwidth 36 management including local admission control, using technologies such as AVB. While it was agreed to 37 specify HNID QoS requirements, this will be done in the HNID Module and not here. Although in-home 38 bandwidth management is an interesting idea, there are significant technical and commercial challenges in 39 implementing it. For example, the most widely used in-home technologies, namely wireless and powerline, 40 can undergo significant bit-rate variations on a wide range of timescales. This makes any kind of in-home 41 admission control very challenging, even presuming that the required linkage to the application layer could 42 be devised. AVB is not only about admission control, but really only works over a homogenous, dedicated, 43 purpose-wired Ethernet network, and one which has managed switches. This technology is at odds with the 44 current hybrid network reality (new wires, old wires and wireless) and legacy switches. Therefore neither 45 AVB nor in-home admission control has been included. 46

47

HGI_RD027-R3



6 HG QoS Requirements 1

Where a Requirement referring to an IP address simply uses the ‘IP’ formulation, then that 2 requirement applies to both IPv4 and IPv6. Where a given Requirement only applies to one of the two, then 3 the type (IPv4 or IPv6) is explicitly stated in the requirement itself. 4

5

6.1 Classification of packets received upon the WAN 6

ingress port 7

N° Requirement

R.1 The HG MUST classify all packets received on the WAN ingress port.

R.2 The HG MUST be able to set the home network priority level for each packet by setting the DSCP bits on the basis of the classification result.

R.3

The HG MUST assign each packet to the appropriate egress queue, drop the packet, or deliver it to an internal sink, on the basis of the classification result combined with the forwarding decision. NOTE: the packet drop in this context refers to an ingress function where packets may be dropped as a direct result of classification or policing.

R.4 The HG MUST be able to classify packets based upon IP destination address.

R.5 The HG MUST be able to classify packets based upon IP source address.

R.6

The HG MUST support a configurable mask for, and associated with, each IP address used as a classifier. If a classification rule includes such a mask (or masks), the appropriate IP address (source or destination) is masked before being checked for a match with the IP address in the classification rule.

Note: this is to allow efficient matching with any address in a range, as opposed to having to include a set of addresses in the rule.

The mask may or may not be the same as the subnet mask

This requirement does apply for both IPv4 and IPv6, although different mask lengths will clearly be needed in the 2 cases.

R.7 The HG MUST be able to classify packets based upon the DSCP field.

R.8 The HG MUST be able to classify packets based upon the Protocol field in the IP header (e.g. ICMP, IGMP, TCP, UDP, …).

R.9

The HG MUST be able to classify packets based upon source TCP/UDP port number, and range of port numbers. Port numbers may be either statically configured or determined dynamically within the HG.

Note: This specification does not specify methods for dynamic determination of port number. This could be done, for example, by use of application layer logic.

R.10 The HG MUST be able to classify packets based upon destination TCP/UDP port number, and range of port numbers. Port numbers may be either statically configured or determined dynamically within the HG.

HGI_RD027-R3



N° Requirement

R.11

The HG SHOULD be able to classify packets based upon IP packet size. The size used SHOULD be the total packet to align with the BBF defined managed object, i.e. the total packet length is compared with the configured length classifier. Note: the 6 byte correction to convert the IPv6 payload length to total packet length can usually be safely ignored.

R.12 The HG MUST be able to classify packets based on IP version number (i.e. 4 or 6)

R.13 The HG MUST be able to classify packets based upon any combination of at least any 5 of the WAN ingress classification parameters for a given rule.

R.14 The HG SHOULD be able to classify packets on any combination of the WAN ingress classification parameters for a given rule.

1

For ATM based access systems, the following requirements also apply 2

N° Requirement

R.15 The HG MUST be able to classify packets based upon ATM VPI/VCI

3

Where Ethernet is present on the access link, the following requirements also apply 4

N° Requirement

R.16 The HG MUST be able to classify packets based upon Ethernet priority, as defined in IEEE 802.1D

R.17 The HG MUST be able to classify packets based upon VLAN ID, as defined in IEEE 802.1Q

R.18 The HG MUST be able to classify packets based upon MAC source address

R.19 The HG MUST provide a configurable MAC source address mask, so that classification is performed only upon bit fields within the MAC source address determined by this source address mask.

R.20 The HG MUST be able to classify packets based upon MAC destination address

R.21 The HG MUST provide a configurable MAC destination address mask, so that classification is performed only upon bit fields within the MAC destination address determined by this destination address mask.

R.22 The HG MUST be able to classify packets based upon the Ethernet Length field.

5

6

HGI_RD027-R3



6.2 Multi-field Classification of packets received on the 1

LAN ingress ports 2

The following requirements pertain to the classification of packets received on the LAN ingress ports 3 which are destined for the WAN after multi-field classification. There is a simpler classification set for locally 4 bridged, LAN-LAN traffic (see 6.3). Note: at the classification stage, the means of determining whether the 5 packet will be sent to the WAN is beyond the scope of this specification 6

N° Requirement

R.23 The HG MUST classify all packets received on the LAN ingress ports

R.24 For packets sent to the WAN, the HG MUST be able to set the DSCP bits of each packet on the basis of the classification result.

R.25 The HG MUST assign each packet to the appropriate egress queue, drop the packet, deliver it to application layer logic, or deliver it to internal sink, on the basis of the classification result combined with the forwarding decision.

R.26 The HG MUST be able to classify packets based upon the LAN type (Ethernet, Wi-Fi, etc.)

R.27 The HG SHOULD be able to classify packets based upon physical port.


R.29 The HG MUST have a configurable MAC source address mask, so that classification is performed only upon bit fields within the MAC source address determined by this source address mask.

R.30 The HG MUST be able to classify packets based upon Wi-Fi SSID


R.32 The HG MUST have a configurable MAC destination address mask, so that classification is performed only upon bit fields within the MAC destination address determined by this destination address mask.

R.33 The HG MUST be able to classify packets based upon IP destination address

R.34 The HG MUST be able to classify packets based upon IP source address

R.35

The HG MUST support a configurable mask for, and associated with, each IP address used as a classifier. If a classification rule includes such a mask (or masks), the appropriate IP address (source or destination) is masked before being checked for a match with the IP address in the classification rule.

R.36 The HG MUST be able to classify packets based upon their DSCP value.

R.37 The HG MUST be able to classify packets based upon the Protocol field in the IP Header (e.g. ICMP, IGMP, TCP, UDP,…).

HGI_RD027-R3



N° Requirement

R.38

The HG MUST be able to classify packets based upon source TCP/UDP port number or range of port numbers. Port numbers may be either statically configured or determined dynamically within the HG.

Note: this specification does not specify methods for dynamic determination of port number. This could be done, for example, by use of application layer logic.

R.39 The HG MUST be able to classify packets based upon destination TCP/UDP port number or range of port numbers. Port numbers may be either statically configured or determined dynamically within the HG.

R.40

The HG SHOULD be able to classify packets based upon IP packet size. The size used SHOULD be the total packet length to align with the BBF defined managed object. i.e. the total packet length is compared with the configured length classifier. Note: the 6 byte correction to convert the IPv6 payload length to total packet length can usually be safely ignored.


R.42 The HG MUST be able to classify packets based upon any combination of at least any 5 of the LAN ingress classification parameters for a given rule

R.43 The HG SHOULD be able to classify packets on any combination of the LAN ingress classification parameters for a given rule.

6.2.1 Classification of packets received on the LAN ingress using information 1

determined via DHCP 2

The classifier can use several LAN-side fields as classification keys. The HG can learn classification 3 keys through the DHCP client requests that it services. In this case, the HG associates information 4 conveyed to the HG in a DHCP client request with a corresponding MAC or IP address. 5

N° Requirement

R.44 The HG MUST be able to interpret DHCPv4 option 60 messages received on LAN ports and associate a vendor class ID with a source IPv4 address so that the source IPv4 address can be used as a classification parameter.

R.45 The HG MUST be able to interpret DHCPv4 option 60 messages received on LAN ports and associate a vendor class ID with a source MAC address so that the source MAC address can be used as a classification parameter.

R.46 The HG MUST be able to interpret DHCPv4 option 61 messages received on LAN ports and associate a client identifier with a source IPv4 address so that the source IP address can be used as a classification parameter.

R.47 The HG MUST be able to interpret DHCPv4 option 61 messages received on LAN ports and associate a client identifier with a source MAC address so that the source MAC address can be used as a classification parameter.

HGI_RD027-R3



N° Requirement

R.48 The HG MUST be able to interpret DHCPv6 option 1 messages received on LAN ports and associate a client identifier with a source IPv6 address so that the source IPv6 address can be used as a classification parameter.

R.49 The HG MUST be able to interpret DHCPv6 option 1 messages received on LAN ports and associate a client identifier with a source MAC address so that the source MAC address can be used as a classification parameter.

R.50 The HG MUST be able to interpret DHCPv4 option 77 messages received on LAN ports and associate a user class ID with a source IPv4 address so that the source IPv4 address can be used as a classification parameter.

R.51 The HG MUST be able to interpret DHCPv4 option 77 messages received on LAN ports and associate a user class ID with a source MAC address so that the source MAC address can be used as a classification parameter.

R.52 The HG MUST be able to interpret DHCPv4 option 125 messages received on LAN ports and associate a V-I Vendor-Specific Information with a source MAC address so that the source MAC address can be used as a classification parameter.

R.53 The HG MUST be able to interpret DHCPv4 option 125 messages received on LAN ports and associate a V-I Vendor-Specific Information with a source IPv4 address so that the source IPv4 address can be used as a classification parameter.

1

6.3 Classification of bridged packets received on the LAN 2

ingress ports 3

The following requirements pertain to the classification of packets received on the LAN ingress ports 4 which are destined for the LAN, i.e. simply bridged in the HG. Note: at the classification stage, the means 5 of determining whether the packet will be bridged to the LAN is beyond the scope of this specification. 6

N° Requirement

R.54 The HG MUST classify all packets received on the LAN ports

R.55 The HG MUST assign each packet to the appropriate egress queues on the basis of the classification result combined with the forwarding decision



R.58 The HG MUST be able to set the home network priority level for each packet by setting the DSCP bits on the basis of the classification result.

R.59 The HG MUST be able to classify packets based upon any combination of the classification parameters described in this subsection.

7

HGI_RD027-R3



6.4 Classification of internally generated packets 1

N° Requirement

R.60 The HG MUST be able to classify all packets generated internally within the HG

R.61 For packets sent to the LAN, the HG MUST be able to set the home network priority level for each packet by setting the DSCP value on the basis of the classification result.

R.62 For packets sent to the WAN, the HG MUST be able to set the DSCP value for each packet on the basis of the classification result.

R.63 The HG MUST assign each packet to the appropriate egress queue or deliver it to application layer logic, on the basis of the classification result combined with the forwarding decision.

R.64 The HG MUST be able to classify packets based upon IP destination address.

R.65 The HG MUST be able to classify packets based upon IP source address.

R.66

The HG MUST support a configurable mask for, and associated with, each IP address used as a classifier. If a classification rule includes such a mask (or masks), the appropriate IP address (source or destination) is masked before being checked for a match with the address in the classification rule.

R.67 The HG MUST be able to classify packets based upon the DSCP value.

R.68 The HG MUST be able to classify packets based upon the Protocol field in the IP header (e.g. ICMP, IGMP, TCP, UDP, …).

R.69

The HG MUST be able to classify packets based upon source TCP/UDP port number or range of port numbers. Port numbers may be either statically configured or determined dynamically within the HG.

Note: this specification does not specify methods for dynamic determination of port number. This could be done, for example, by use of application layer logic.

R.70 The HG MUST be able to classify packets based upon destination TCP/UDP port number or range of port numbers. Port numbers may be either statically configured or determined dynamically within the HG.

R.71

The HG SHOULD be able to classify packets based upon IP packet size. The size used MUST be the total packet length to align with the BBF defined managed object i.e. the total packet length is compared with the configured length classifier. Note: the 6 byte correction to convert the IPv6 payload length to total packet length can usually be safely ignored.

R.72 The HG MUST be able to classify internally generated voice packets based upon physical port


HGI_RD027-R3



N° Requirement

R.74 The HG MUST be able to classify packets based upon any combination of at least any 5 of the classification parameters for a given rule

R.75 The HG SHOULD be able to classify packets on any combination of the classification parameters for a given rule.

1

6.5 LANside VLAN support 2

N° Requirement

R.76 The HG MUST NOT add VLAN headers to any frames which are transmitted on a LAN side port

R.77 The HG MUST be able to receive VLAN tagged or priority tagged frames on any of its LAN ports. Where these frames are locally bridged to the LAN, the VLAN ID and priority tag MUST be forwarded unchanged.

R.78 Where VLAN or priority tagged frames received on the WAN are bridged to the LAN, the VLAN ID and priority tag SHOULD either be forwarded unchanged or removed. This MUST be configurable from the remote management server.

3

6.6 WANside VLAN support 4

N° Requirement

R.79 The HG MUST be able to add a full VLAN header or priority tag (VID=0) to any frames which are transmitted on a WANside port

R.80 The HG MUST be able to set the value of the .1p bits as a result of the packet classification

R.81 The HG MUST be able to set the VID value as a result of the packet classification

5

6.7 Tunnel QoS 6

7

N° Requirement

R.82 Where the HG is the end-point of any (WANside) IP tunnel (e.g. IPv6 in IPv4, IPSec) the HG MUST remove the tunnel header before carrying out the classification.

R.83 Where the HG is the end-point of any (WANside) IP tunnel (e.g. IPv6 in IPv4, IPSec) the HG SHOULD be able to copy the DSCP marking from the tunnelled (inner) packet header to the tunnel (outer) packet header for WAN egress packets)

HGI_RD027-R3



1

2

6.8 Classification Rule Sets 3

6.8.1 Overview 4

This section describes requirements in the HG for classification rule sets, which are sets of individual 5 classification rules as defined in Section 6.8. This section also describes requirements for sequencing 6 among the classification rule sets. 7

During classification, individual classification rules are checked for a match with the corresponding 8 fields in each packet. A rule-match occurs when all the individual classifiers within that rule match. A rule 9 set is an associated collection of rules. 10

The internal representation of the classification rules and rule sets is not specified. 11

There are four distinct classification rule sets which are present in the HG. They are: 12

WAN_Rule_Set, which embodies the classification rules for packets arriving on the WAN 13 ingress. 14

LAN_Rule_Set_1, which embodies the classification rules for LAN-WAN traffic, and LAN-15 LAN traffic which is multi-field classified 16

LAN_Rule_Set_2, which embodies the classification rules which are used to identify LAN-17 WAN service instances as part of the overload protection mechanism 18

LAN_Rule_Set_3, which embodies the classification rules for LAN-LAN traffic which is 19 bridged through the HG with no multifield classification. 20

6.8.2 Classification Rule Sets 21

N° Requirement

R.84 The HG MUST support a classification rule set for WAN ingress (WAN_Rule_Set)

R.85 The classification rules associated with WAN_Rule_Set MUST only be able to be configured by remote download from the ACS.

R.86 The HG MUST support 3 classification rule sets for LAN ingress: LAN_Rule_Set_1, LAN_Rule_Set_2, and LAN_Rule_Set_3

R.87

The classification rules associated with LAN_Rule_Set_1 MUST be able to be configured by remote download from the ACS and MUST be able to be modified by the local Application Layer Logic (e.g. the DHCPv4 options). Individual rules associated with LAN_Rule_Set_1 are formed according to requirements in Section 6.2

R.88

Individual rules associated with LAN_Rule_Set_2 MUST only be created internally in the HG. For example, such rules may be created in response to an event, such as signalling that informs the RG that a voice flow is about to start; the HG may use the information received from this signalling to create classification rules that identify the subsequent voice flow.

R.89 LAN_Rule_Set_3 contains additional rules for bridged, LAN-LAN traffic. Individual rules associated with LAN_Rule_Set_3 are formed according to requirements in Section 6.3. These MUST be able to be downloaded from the ACS.

HGI_RD027-R3



N° Requirement

R.90 The rules defined in R.89 SHOULD be able to be entered locally by the user.

R.91 For each rule in LAN tables 1 and 2 it MUST be possible to configure a pointer to an additional, per packet operation (e.g. application layer logic). The mechanism described in R177 is an example of this kind of per-packet operation.

R.92 The HG MUST support a minimum of 32 concurrent rules for WAN_Rule_Set_1

R.93 The HG MUST support a minimum of 32 concurrent rules for LAN_Rule_Set_1



6.8.3 Sequencing Among Classification Rule Sets 1

N° Requirement

R.96 For routed LAN-WAN traffic, the rules in LAN_Rule_Set_2 MUST be tested

1 first (i.e.

before the rules in LAN_Rule_Set_1).

R.97 The first rule match in any Rule_Set MUST terminate the classification process for that packet. Note; that if more than one rule match is possible for a given packet, the terminating match will depend on the order in which the rules are specified

R.98 The gateway MUST process the rules in the sequence in which they are configured

R.99 If there is no rule match in LAN_Rule_Set_2, then the rules in LAN_Rule_Set_1 MUST be tested

R.100 For WAN-LAN traffic, the rules in the WAN_Rule_Set MUST be tested

R.101 It MUST be possible to configure a default classification in the event of no rule match

6.9 Overload Protection Mechanism 2

The following requirements relate to an overload protection mechanism. This description is an 3 example of a protection mechanism; alternative protection mechanisms may be employed. 4

The protection mechanism utilizes an Instance Table within the HG. The Instance Table is used by 5 the HG to record instances of services which have been recognized by the classification using the 6 LAN_Rule_Set_2. The formulation of the Instance Table is vendor-specific. 7

1 Testing means that all the classifiers in a rule are checked for a match with the corresponding field in each packet. A rule-match occurs when all the classifiers match.

HGI_RD027-R3



N° Requirement

R.102

The HG SHOULD support a mechanism (e.g. an ALG) which:

i. differentiates instances of a service on the basis of one or more, configured parameters (e.g. IP SA)

ii. creates a service instance Table entry, for each newly recognised instance of the specified service, subject to a configurable limit. This allows the maximum number of service instances to be constrained if required. There needs to be a Table for each service for which this technique is used

iii. increments a packet count every time a recognised service instance packet is classified

iv. performs a real time check of each service instance packet count against a configurable upper and lower limit (i.e. < InactivePackets per SampleInterval, > ActivePackets per SampleInterval)

v. checks whether a configurable queue length threshold (QueueThreshold) has been exceeded during the same SampleInterval time period

vi. when the upper limit is exceeded without the queue length threshold being exceeded, a new classification rule is added to the Rules Table. This rule which is a copy of the non-instance specific rule, with the appropriate instance identifier added, and the queue changed to that appropriate for an established flow.

vii. when the lower limit is not met, the instance specific rule is deleted from the Rules Table

viii. marks the most recently established flow in some way. This would be typically used by a separate process to delete this service instance rule in the event of subsequent congestion

1

6.10 QoS Mappings 2

Note: This section is informative and not normative except where specific requirements are listed 3 and it provides guidance on the use of QoS Markings in the home LAN. 4

6.10.1 Integrated Non-Ethernet Technologies 5

The following requirement pertains to the use of priority markings for integrated wireless access 6 points or powerline devices within the HG. 7

N° Requirement

R.103 If both layer 2 and layer 3 egress markings are used, the marking action associated with the classification rules SHOULD be configured so that layer 2 and layer 3 markings follow the correspondence with service classes as shown in Table 1.

8

HGI_RD027-R3



Layer 3

PLC PLC

(4 Level) (8 Level)

Serv

ice

Cla

ss

Guest, Hotspot

access0x08 1

AC_BK

(AC0)

Priority 0

(CA0)CA1

Transit BE Data 0x00 0AC_BE

(AC1)

Priority 1

(CA1)CA0

Downstream BE

Data0x18 3

AC_BE

(AC1)

Priority 1

(CA1)CA3

Transit VAS 0x20 4 AC_VI (AC2)Priority 2

(CA2)CA4

Downstream

Video0x28 5 AC_VI (AC2)

Priority 2

(CA2)CA5

Downstream

Voice0x38 7

AC_VO

(AC3)

Priority 3

(CA3)CA7

DS

CP

Access

Cate

gory

Channel

Access P

rio

rity

Channel

Access P

rio

rity

HGIDiffserv

WMM /

802.11e

Ethernet

802.1D

Layer 2

User

Prio

rity

1

Table 1 Correspondence between Service Classes and HG Egress Markings 2 3

6.11 Dropping/Congestion Management 4

The congestion manager monitors the buffer resource consumption by tracking the depth of each 5 class queue for each out-going port. The congestion manager will either permit or deny the packet from 6 being enqueued into the class queue based on the Random Early Discard algorithm. 7

The following requirements pertain to congestion management functions in the HG. 8

N° Requirement

R.104 The HG MUST support Random Early Discard (RED)for the upstream WAN queues and the LAN egress queues

R.105 The operation of the RED function in both directions MUST be configurable from the ACS for each queue

R.106 The HG MUST support disabling the RED function in either direction.

R.107 The HG MUST support independent configuration of the maximum threshold parameter for RED in each direction.

R.108 The HG MUST support independent configuration of the minimum threshold parameter for RED in each direction

HGI_RD027-R3



N° Requirement

R.109 The HG MUST support independent configuration of the w_q (weighting factor) parameter for RED in each direction

R.110 The HG MUST support independent configuration of the maximum probability parameter for RED in each direction

6.12 Class Queue structure and Scheduling 1

6.12.1 Queuing into the WAN Egress port 2

The following requirements apply to the HG’s upstream queues and scheduling those queues into 3 the WAN. 4

N° Requirement

R.111 The HG MUST support at least five class queues at the WAN egress interface

R.112 The HG SHOULD support at least eight class queues at the WAN egress interface

R.113 The HG MUST provide a configurable mapping between WAN egress queues and logical layer 2 WAN ports (i.e. ATM VC or VLAN)

R.114 The HG MUST support configurable shaping per WAN class queue

R.115 The HG SHOULD be able to configure each queue for strict priority or Weighted Round Robin scheduling

R.116 The HG MUST support at least 2 strict priority queues

R.117 The HG MUST support at least 3 queues which use Weighted Round Robin scheduling

R.118

The HG MUST provide a mechanism to prevent starvation of the WRR queues by the strict priority queues. The starvation prevention mechanism is vendor-specific but it MUST be able to be configured in terms of an average, absolute minimum bandwidth (in kbps) which is available to the WRR queues if they need it. If this bandwidth is not required then it MUST be available to the strict priority queues.

R.119 The Round Robin weights MUST be individually configurable

R.120 The first strict priority queue MUST be given priority over all other queues i.e. served until exhaustion except when subjected to the starvation prevention mechanism for lower priority queues. Note: this queue would typically be used for voice.

R.121 The second strict priority queue MUST be given priority over all other queues except the first strict priority queue, except when subjected to the starvation prevention mechanism for lower priority queues. Note: this queue would typically be used for video

R.122 The first strict priority queue MUST provide very low jitter for voice packets. The first strict priority queue MUST be serviced immediately after every single packet is scheduled from any other queue.

HGI_RD027-R3



N° Requirement

R.123 When all strict priority queues are empty, the WRR queues MUST be serviced according to their weighting priority and subject to any per queue shaping limit.

R.124 The HG MUST support aggregate shaping into each WAN egress logical layer 2 port, i.e. the overall rate at which all queues are serviced is dependent on this shaping value.

R.125 Requirements R.111, R.112, R.114, R.115, R.116, R.117, R.118, R.119, R.120, R.121, R.122, R.123 and R.124 MUST be met for every Layer 2 WAN connection.

1

6.12.2 Queuing into the LAN Egress ports 2

The following requirements pertain to the HG’s LAN egress class queue structures and scheduling 3 from those queues into the port level. 4

N° Requirement

R.126 The HG MUST support queuing of data from any source into the LAN egress queues (as a result of the classifier)

R.127 The HG MUST implement at least four class queues for each LAN egress port

R.128 The HG MUST support at least 2 strict priority queues per LAN egress port

R.129 The HG MUST support at least 2 queues which use Weighted Round Robin scheduling per LAN egress port

R.130 The Round Robin weights MUST be individually configurable

R.131 The first strict priority queue

2 MUST be given priority over all other queues i.e. served

until exhaustion

R.132 The second strict priority queue

3 MUST be given priority over all other queues except the

first strict priority queue, but might not be served to exhaustion

R.133 When all strict priority queues are empty, the WRR queues

4 MUST be serviced

according to their weighting priority.

6.12.3 Example Queuing Configuration 5

Table 2 provides an example of a queuing configuration 6

7

2 This queue would typically be used for WAN ingress Managed Services 3 This queue would typically be used for transit streaming (audio/video/voice) traffic 4 One of the WRR queues would typically be used for WAN ingress best efforts traffic, and the other for transit best efforts traffic.

HGI_RD027-R3



Direction Purpose Scheduling into Port

Upstream Voice Strict Priority (highest)

Upstream Video Strict Priority (next)

Upstream Temporary Voice W1 Weighted Round Robin

Upstream Premium Data, GPRS Data, Game

Data W2 Weighted Round Robin

Upstream Best Effort Data W3 Weighted Round Robin

Downstream Managed Services Strict Priority (highest)

Transit LAN streaming Strict Priority (next)

Downstream Best Effort Data W2 Weighted Round Robin

1 Table 2 Example of Queuing Configuration 2

3

4 5

6.13 Admission Control 6

The Admission control function is specified as two sets of requirements. The first set describes a 7 generic Admission Control function. The second set describes requirements to support a specific use case, 8 namely multi-terminal, multi-line SIP-based voice. Further use cases and their specific additional 9 requirements, could be added in the future. 10

In the requirements below, the CAC Class is a conceptual grouping of services, each of which is 11 admission-controlled within a particular bandwidth limit. Classifiers are used to identify flows as belonging 12 to services within a CAC class. There is a bandwidth limit for each CAC Class. A running total of bandwidth 13 being used by flows within each CAC Class determines how much bandwidth remains. For services within 14 a particular CAC Class, new flows are admitted only when there is available bandwidth remaining within 15 that CAC Class. 16

N° Requirement

R.134 The HG MUST support a CAC function for both inbound and outbound sessions.

R.135

The CAC function MUST operate on a per-CAC class basis

Note: the QoS classifier for more than one service can be mapped to the same CAC class. This allows (but does not require) more than one service to be included in a single CAC class.

R.136 The HG MUST be able to calculate and store locally a running total of the bandwidth requested for all the accepted sessions in progress for each CAC class

HGI_RD027-R3



N° Requirement

R.137

The HG MUST be able to check the requested bandwidth plus the current total for that CAC class against a configurable, per CAC class limit.

The HG MUST be able to check the requested bandwidth, plus the sum of all the CAC class running totals against the upstream bandwidth minus a configurable value.

If the resulting total requested bandwidth does not exceed either of the above limits, the session signalling MUST be passed on unmodified, and the requested bandwidth MUST be added to the running bandwidth total for that class, otherwise the session MUST be rejected locally, and the requested bandwidth MUST NOT be added to the running total.

R.138 The HG MUST generate a unique identifier (Session ID) for each accepted session, and store this with the bandwidth requested for that session.

R139.

The HG MUST be able to monitor all session termination messages (including those which indicate that the session has not been accepted by the called party) and decrement the running bandwidth total by the bandwidth associated with that session as identified by the Session ID. The HG MUST delete the Session ID and bandwidth for the terminated session.

R140.

The HG MUST provide a mechanism to clean up the state relating to the CAC mechanism so as to allow for abnormal session terminations.

For example, this could be a mechanism which monitors the number of packets sent in the queue associated with that CAC class and resets the appropriate running bandwidth total to zero when there has been <10 such packets during the previous T minutes. If the bandwidth total is reset to zero, then all Session IDs and bandwidths associated with that class must be cleared.

R141.

The running bandwidth totals for all service classes MUST be able to be reset to zero by a single management command. All Session IDs and bandwidths MUST be cleared by the same, single management command (this will not have any impact on existing media flows).

R142. The HG CAC function MUST be able to be enabled or disabled by the Remote Management System

R143. All CAC parameters MUST be able to be set via the Remote Management System

1

6.13.1 B2BUA requirements for CAC using SIP signalling 2

N° Requirement

R144. The SIP B2BUA MUST interact with the CAC function prior to allowing the call

R145. For all accepted calls, the SIP B2BUA MUST forward the SIP messages and store the Session ID with the call bandwidth.

R146. For all locally rejected calls, the SIP B2BUA MUST return a NOT ACCEPTABLE (606) message to the calling party

HGI_RD027-R3



R147. For all locally rejected calls, the SIP B2BUA MUST NOT forward the SIP messages, so as to prevent the call being placed.

R148. The SIP B2BUA MUST be able to read the (optional) Bandwidth parameter in the embedded SDP string

R149. If the optional bandwidth parameter is not set, the SIP B2BUA MUST read the codec type in the SIP INVITE header. The HG MUST provide a configurable mapping table between codec type and bandwidth.

R150. The SIP B2BUA MUST monitor SIP BYE messages and use these as the trigger for the HG to decrement the running bandwidth total for that CAC class by the amount associated with that Session ID.

1

6.14 DLNA Coexistence Guidelines 2

The goal of the following requirements is to ensure that transit flows from DLNA devices are treated, 3 in the QoS sense, according to DLNA guidelines. The QoS configuration of the HG should respect as far as 4 possible DLNA QoS markings originating from the LAN, particularly those in the DLNA Video and Audio 5 categories, even for unmanaged services, giving them better treatment than Best Effort traffic, while 6 remaining compatible with the operator's managed service requirements. Indeed, some LAN-LAN flows 7 used by DLNA devices may be using premium content for which the BSP or ASP may have a commercial 8 responsibility. 9

This implies active trust establishment with DLNA devices, and the creation of appropriate 10 classification rules for such trusted device streams. Trust could be established, for example, by using 11 unspoofable classifiers. This implies the use of a service running on the HG that detects the arrival of new 12 devices on the LAN, attempts to establish trust with them, and subsequently generates additional 13 classifiers for them in the HG. 14

15

N° Requirement

R151. The HG SHOULD NOT re-mark LAN-side ingress DSCP markings on packets that originate from trusted DLNA devices (see also R.77).

R152. Flows recognised as DLNA Video and Audio flows SHOULD be given treatment, such as placement in LAN-LAN streaming queues, which limits the possibility of packet dropping and limits latency.

R153. The HG SHOULD be able to treat flows that originate from trusted DLNA devices on the same level as operator managed services, according to operator configured policy.

R154. The HG SHOULD be able to dynamically add classification rules for trusted DLNA devices as they are installed and recognized in the network.

16

17

HGI_RD027-R3



7 Management 1

7.1 QoS Requirement Mapping to TR-098 [4] 2

These 2 Tables illustrate the mapping of HGI QoS requirements to TR-098 objects and parameters. They 3 do not include the following as these are not currently covered in TR-098 (application of these requirements 4 to TR-181 is for further study): 5

the CAC configuration parameters 6

classifier for internally generated traffic 7

queue congestion statistics 8

The following abbreviations are used in these Tables: 9

Abbreviation Description

R Readable.

W Readable and writeable.

C Object instances can be created and deleted

10

Name ‘Type’ HGI

InternetGatewayDevice.QueueManagement. -

Enable W

MaxQueues R R.111: WAN egress: must be at least 5 plus…

R.127: LAN egress: …4 per LAN egress interface

R.112: WAN egress: should be at least 8 plus…

R.127: LAN egress: 4 per LAN egress interface.

MaxClassificationEntries R R.92: WAN ingress: must be at least 32 plus…

R.93: LAN ingress: …32, i.e. 64.

ClassificationNumberOfEntries R

MaxQueueEntries R R.116, R.128: must be at least 2 Strict Priority queues

R.117: WAN egress: must be at least 3 WRR queues

(so must be at least 5 WAN queues per egress interface)

R.129: LAN egress: must be at least 2 WRR queues

(so must be at least 4 LAN queues per egress interface)

QueueNumberOfEntries R

DefaultQueue W R.101

DefaultDSCPMark R

DefaultEthernetPriorityMark R

InternetGatewayDevice.QueueManagement.Classification.{i}. C

ClassificationEnable W

ClassificationStatus R

ClassificationOrder W

ClassInterface W R.10: WANConnectionDevice instance: VPI/VCI

R.26: LANxxxInterfaceConfig instance: physical port

R.30: WLANConfiguration instance: WLAN SSID

DestIP W R.4: WAN ingress

R.33: LAN ingress

DestMask W R.6: WAN ingress

R.35: LAN ingress

HGI_RD027-R3



Name ‘Type’ HGI

SourceIP W R.5: WAN ingress

R.34: LAN ingress

SourceMask W R.6: WAN ingress

R.35: LAN ingress

Protocol W R.8: WAN ingress

R.37: LAN ingress

DestPort W R.10, R.39: will be used only when the port can be statically configured. If application layer logic is required in order to determine the port number, the HG will presumably support the standard TR-098 QoSDynamicFlow:1 profile.

DestPortRangeMax W R.10, R.39

SourcePort W R.9, R.38: WAN ingress: will be used only when the port can be statically configured. If application layer logic is required in order to determine the port number, the HG will presumably support the standard TR-098 QoSDynamicFlow:1 profile.

SourcePortRangeMax W R.9, R.38

SourceMACAddress W R.28: LAN ingress

R.56: transit

SourceMACMask W R.29: LAN ingress

DestMACAddress W R.31: WAN ingress

R.56: transit

DestMACMask W R.32: WAN ingress

Ethertype W

SourceVendorClassID W R.44, R.45: LAN ingress

SourceClientID W R.46, R.47: LAN ingress

SourceUserClassID W R.50, R.51: LAN ingress

IPLengthMin W R.11, R.40

DSCPCheck W R.7, R.36

DSCPMark W R.2, , R.24

EthernetPriorityCheck W R.10: Only for WAN ingress.

EthernetPriorityMark W R.24

VLANIDCheck W R.13: Only for WAN ingress.

ClassQueue W

InternetGatewayDevice.QueueManagement.Queue.{i}. C

QueueEnable W

QueueStatus R

QueueInterface W

QueueBufferLength R

QueueWeight W R.119 WAN egress

QueuePrecedence W R.120, R.121

REDThreshold W R.105, R.107, R.108:RED parameters are not well modelled in TR-098

REDPercentage W R.105, R.109, R.110: RED parameters are not well modelled in TR-098

DropAlgorithm W R.104: “RED”

R.106: “DT”

SchedulerAlgorithm W R.115: “Strict Priority. “WRR”

ShapingRate W R.114

ShapingBurstSize W R.114

HGI_RD027-R3



Name ‘Type’ HGI

InternetGatewayDevice.WANDevice.{i}.WANConnection-Device.{i}.WANDSLLinkConfig.

-

ATMQoS W R.124

ATMPeakCellRate W R.124

ATMMaximumBurstSize W R.124

ATMSustainableCellRate W R.124

InternetGatewayDevice.WANDevice.{i}.WANConnection-Device.{i}.WANIPConnection.{i}.

-

ShapingRate W R.114


InternetGatewayDevice.WANDevice.{i}.WANConnection-Device.{i}.WANPPPConnection.{i}.

-

ShapingRate W R.114


1 Table 3 Basic QoS Requirement Mapping 2

3

Name Req HGI

InternetGatewayDevice.QueueManagement. -

MaxAppEntries R Must be at least 1.

AppNumberOfEntries R

MaxFlowEntries R Must be at least 1.

FlowNumberOfEntries R

AvailableAppList R Must include “urn:homegatewayinitiative-org:qos:overload-protection1”.

InternetGatewayDevice.QueueManagement.Classification.{i}. C

ClassApp W Must be instance number of the App entry that handles overload protection.

InternetGatewayDevice.QueueManagement.App.{i}. C These requirements relate to the App entry that handles overload protection.

AppEnable W

AppStatus R

ProtocolIdentifier W Must be “urn:homegatewayinitiative-org:qos:overload-protection:1”.

AppName W

AppDefaultQueue W Must be the instance number of the queue that is used for flows that are not yet established (i.e. the temporary queue).

AppDefaultDSCPMark W

AppDefaultEthernetPriorityMark W

InternetGatewayDevice.QueueManagement.Flow.{i}. C These requirements relate to the Flow entry that handles overload protection.

FlowEnable W

FlowStatus R

FlowType W Must be “urn:homegatewayinitiative-org:qos:overload-protection:1”.

HGI_RD027-R3



Name Req HGI

FlowTypeParameters W Must encode the overload protection algorithm parameters as specified in TR-098, i.e. (loosely) in the form “name1=value1&name2=value2”. The following parameter names and values Must be supported:

Name Value

MaxInstances Maximum number of instances of this service (whether established or not)

SampleInterval Interval (in ms) between executions of the state machine algorithm

InactivePackets If number of packets in sample interval is less than this, service instance is considered inactive

ActivePackets If number of packets in sample interval is greater than this, service instance is considered active

QueueThreshold If “established flow” queue depth exceeds this within sample interval, no new service instances will be allowed to become established

FlowName W

AppIdentifier W Must be instance number of the App entry that handles overload protection.

FlowQueue W Must be the instance number of the queue that is used for established flows.

FlowDSCPMark W

FlowEthernetPriorityMark W

1 Table 4 Overload Protection Parameter Mapping to TR-098 2

3

4

HGI_RD027-R3



References 1

[1] HGI-RD001-R2.01 Home Gateway Technical Requirements: Residential Profile V1.01 2

[2] HGI-GD013-R2 HGI Release 2 QoS Whitepaper 3

[3] HGI-RD007-R2 Requirements for HG Interworking with an External NT 4

[4] Broadband Forum TR-098 Amendment 2 “Internet Gateway Device Data Model for TR-069” 5

(2008) 6

[5] Broadband Forum TR-181 Amendment 5 “Device Data Model for TR-069”(2012), Broadband 7

Forum. 8

9

Documents

HGI-RD027-R3 Home Gateway QoS Module · PDF file... Celeno, Cisco, Deutsche Telekom, Devolo, Dialog Semiconductor, D-Link Corporation, ... 31 PLC PowerLine ... Home Gateway QoS Module