Académique Documents
Professionnel Documents
Culture Documents
Page 1 of 31
Contents 1 2
2.1 2.2 2.3 2.3.1 2.3.2 2.3.3 2.3.4
3
3.1 3.2 3.2.1 3.2.2 3.2.3 3.2.4 3.3
4
4.1 4.1.1 4.1.2 4.1.3 4.1.4 4.1.5 4.2 4.2.1 4.3 4.4
5
5.1 5.2 5.3
6
6.1 6.2 6.3 6.4 6.5
7
7.1 7.2 7.3 7.4 7.5
8 9
Page 2 of 31
1 Introduction
In the Residential Environment, Quality of Service is generally a means to an end for both the Service Provider and End User (EU), rather than being the basis of any quantified Service Level Agreement (SLA). From the Service Provider perspective, the aim is to deliver premium/managed services to end-devices with the necessary and consistent Quality of Experience, and thereby provide service differentiation with over the top (OTT) services (which correspond to Unmanaged Services in HGI terminology). Ideally this should be irrespective of what the end-user (EU) is doing on their Home Network for their own purposes. The SP will be hoping to gain some commercial benefit by doing this, and so a key aspect of any solution must be to minimise the number of support calls which could otherwise threaten the commercial viability of such a service. The user has no direct interest in, or in most cases knowledge of, Quality of Service in itself but he does care that each service is delivered to the appropriate device in a consistent fashion and without any noticeable disruption e.g. pixellation on IPTV, or break-up in a voice service. This needs to be done at a price that he is prepared to pay.
on the Customer Access link - especially in the upstream direction for ADSL based services in the aggregation network, when backhaul is contended in the Home network, when there is a mix of Access traffic and local LAN traffic.
Note that sustained overload cannot be addressed by quality of service mechanisms, but instead needs congestion avoidance mechanisms which range from simple traffic engineering (network planning and monitoring), to more complex approaches such as connection admission control (CAC). A longer term solution is of course to upgrade the capacity of the bottleneck link which may involve a technology change or upgrade (e.g. going from 801.11b to 11n). While any QoS scheme has to take an end to end view, the focus of the HGI QoS activity is (almost by definition) the HG itself, and the Home Network.
Page 3 of 31
Ethernet Switch
100 Mbps
100 Mbps
<10 Mbps
Ethernet-PLT bridge
can be significantly less than this (depending on the mains topology, noise environment and number of users). Simple aggregation devices (e.g. an Ethernet switch) which have the same physical interface type and speed on all links, including the aggregating uplink, can also become congestion points. The HG may not have any knowledge of the presence of such devices.
Managed Services User End User management Wholesale Access Network provider management
VOIP2
VOIP1 IPTV
HG
D S L A
Backhaul Network
BNG
SP edge d
Internet
Page 5 of 31
3.3 Conclusion
Having an SP-managed, HG-based solution avoids all the problems of end-device marking, marking consistency and end-device trust. So while this does not provide an end to end solution, it can form a key part of the solution, and can peacefully co-exist with whatever solutions are needed in the other domains. For these reasons, the HGI decided on a solution mainly based on managing the QoS of all the traffic that transits the HG. There are also extensions which address some of the QoS issues within the Home Network.
Page 6 of 31
Page 7 of 31
IP address (Destination, Source and Subnet) The single most useful classifier is IP address. Many managed services go to a service border gateway (SBG) of some kind, and so the destination address of that SBG can be used to classify upstream traffic. This has the additional benefit that the end user cannot gain any QoS advantage for other traffic types by spoofing this address, as that traffic would then be going to the wrong destination. Examples of a service which might use this classifier are VoIP, in the case where the media goes to a SBG as opposed to being peer to peer. Note however that use of IP destination addresses may eventually suffer from scalability limitations as the number of possible destinations increases. It can also cause problems with network address maintenance e.g. server address renumbering would require a synchronized change to the rules contained in many HGs. This type of classifier is also useful for encrypted services which use an IPSec tunnel. Here it is not possible to use fields of the inner packet header to identify the service signature. However the entire tunnel can be given a higher priority, simply by the use of the tunnel destination address as the classifier. It might be thought that there could be no finer QoS granularity within the tunnel, but in fact this is not the case (see Packet Length below). Source IP address can be used as the classifier for a video streaming application. However the upstream traffic for such a service may also need high priority, e.g. when it is TCP based. The video servers destination address could therefore be used as the upstream classifier. Video services may come from a large number of possible servers, and it would be inconvenient to have to store and maintain a long list of addresses. In this case, the server subnet may be able to be used as the classifier. If the video servers are not in the same (or a small number of) subnet(s), then this approach would also become cumbersome. An alternative would be to use the IP address of the STB. There are 2 potential problems with this; it is under the control of the end-user and so could be spoofed. However in the upstream, it is primarily his own traffic he would be impacting. The more real concern is that this would require each HG to be configured with a different STB IP address, and this would normally be a private, dynamically assigned address. This is clearly impractical manually, but can be done automatically by the use of DHCP Options 60 and 77. The Gateway can recognize DHCP requests, and be configured to locally set a traffic classifier to the source IP address for the appropriate Option 82 value (which identifies the STB/video service). TCP/UDP S/D port or range Where there is no convenient SBG address, then another classifier is needed. Various applications can be identified by their port type and number. Again these may be able to be learned dynamically when that device receives its IP address. A coarse QoS distinction can be made on the basis of protocol type, i.e. UDP or TCP. MAC SA/DA Although the main purpose of HGI QoS is to provide support for managed services, it is recognized that LAN-LAN traffic within the home is likely to become greater in both volume and importance to the user; for example video or audio being streamed around the home from a NAS device. While it may not be in the SPs direct interest to give such traffic priority, it might increase the overall attractiveness of the HG of that SP. The problem is however how to recognize which part of the LAN-LAN traffic should be prioritized. There are two issues, firstly there are no easily configurable or learned IP addresses as discussed above which could be used as service signatures. Secondly, the LAN-LAN traffic may only go via a simple bridge in the HG and so not pass through the (L3) classification engine. The solution to both these is to go to a more device-based approach. If there are certain devices, again such as a NAS, which normally generate streaming video traffic, then if there is a simple way of identifying all the traffic from that device, it can be prioritized over traffic from other devices. This essentially requires a device (i.e. hardware) identifier, and so can be done on the basis of MAC address.
Page 8 of 31
The problem then becomes how to automatically learn the MAC address of such devices, since again these would be very difficult for the SP to administer. The HGI QoS scheme supports MAC addresses as classifiers, and while it does not explicitly cover how they are learned, suggests that an application whereby the end-user could nominate particular devices (e.g. on a GUI which showed the networked devices), could be used together with an ARP. Alternatively DHCP Options 60/77 could again be used to identify device types and the MAC addresses then learnt automatically. Some HN devices will be general purpose, and so it might not be appropriate to prioritise all their traffic. However as both source and destination addresses can be used, this allows rather more discrimination and granularity e.g. all NAS traffic going to a particular PC. LAN interface type (Ethernet, Wifi) or instance Although in most cases a given LAN interface will be used for multiple different traffic types/services, it may be appropriate to apply the same treatment to an entire interface. Certain SPs may want to dedicate a physical interface to a single service in order to ensure the end to end quality, especially for IPTV. Although in some ways this approach is inflexible, and requires some knowledge and correct action on the part of the end-user e.g. plugging into the right LAN port, and only using a point to point connection (not adding an intervening hub), it can be made to work. Physical port (e.g. FXS) In one particular case the service is actually identified by the nature of the port, namely an FXS interface embedded into the HG. In this case there is an implicit classifier, but this still needs to be configured with the appropriate queue treatment. Wifi SSID A subset of physical port classification is to use a logical port within a physical port. A good example of this is wireless, where different SSIDs can be used to separate customers and give them different QoS treatment. This can for example be used to give guest access users a lower priority than the HG owner, as well as applying different security treatment in order to protect the Home Network itself from the Guest user. Packet length Where the same Source and Destination address are used for multiple applications, or more than one application shares an encrypted tunnel, then packet length can be used to discriminate between different services. This is particularly useful in the case of voice. Here the key requirement is that very long packets do not delay short media packets. This can be achieved by making one of the criteria for entry into the high priority queues that the packet must not exceed a certain length. This length needs to be configurable in order to cope with different voice codecs and packetisation times. The length classifier will normally be used in combination with one or more other criteria to fully identify the service. Note also that all the packets associated with an application would have to meet the length criterion, or there would be the potential for packet re-ordering. DSCP value Although in most cases the HG does not rely on ingress QoS markings, if these are trusted, they could be used as part of the service signature, especially for WAN ingress traffic where they may well have been set or checked by a trusted network component. This is not a key feature of the HGI QoS scheme, but can be used if required. ATM VC, Ethernet VLAN (WANside only) Finally the L2 connection ID (ATM VC or VLAN), can be used in the classification process for ingress traffic (on the WANside only).
simply drop them. Further, the VLAN allocation would need to be managed, which is quite complex.
4.1.2
Some applications, for example video streaming, may use large UDP or TCP packets. When packets are greater than the configured MTU (e.g. greater than 1500 bytes), the IP layer will fragment them. Methods for determination of MTU size are beyond the scope of this paper. While each resulting fragment contains a Layer 2 header and an IP header, only the first fragment will contain the UDP and TCP headers. Therefore, fragments must be handled with particular care by those elements of the HG that normally use the full packet headers. This includes classification as well as NAT. Classification could treat fragments in various ways, e.g.: Re-assembly of arriving fragments in the HG so that all header fields, including UDP or TCP fields, are available to the classification logic. Classification on a fragment-by-fragment basis.
In fact the HGI does not advocate either of these methods but to avoid ambiguity in classifier treatment of fragmented flows, it is recommended that either the ASP avoids the use of applications that result in fragmented flows to the HG, or that they only use Layer 2 and IP header fields for classifying such traffic.
4.1.3
Classification treats arriving packets according to their header fields. However, NAT may subsequently alter the IP, TCP and UDP fields of these packets. The HGI does not specify if classification applies to pre- or post- NATed headers. It is recommended that the SP only uses classification based on header fields (e.g. IP Destination Address and UDP or TCP source port) that do not change during NAT.
4.1.4
The main requirement in the downstream direction is to be able to distinguish between managed and unmanaged services, and this can often be done on the basis of IP SA alone. This is not sufficient in all cases and so some, but not all, of the above classifiers are also needed for downstream traffic. However packet length, MAC address, and physical port are generally not - there is only 1 WAN port, and so the fact that it is downstream traffic can be taken into account without there needing to be an explicit classifier.
4.1.5
Transit classifiers
The SP is not directly involved with transit traffic but wants to prevent it adversely impacting his managed services. This could be done by always separating out DS and transit traffic, and simply giving absolute priority to the DS traffic. However there may be an opportunity to distinguish between (transit) streaming and data traffic on the HN, and prioritize the former. The problem is that if this traffic is simply bridged, then it may not be seen by what is essentially a L3 classification engine. Further, if all such traffic were forced via the full classifier, this would require the classifier to be able to operate at a line rate of up to 100 Mbps. Finally, the BSP/ASP has no awareness of these LAN-LAN flows as services, which makes a service-based classifier hard to configure. Therefore there is a simple transit priority scheme, which is essentially device-based and uses MAC address pairs (SA and DA) to identify traffic which can be given higher priority. Separation between DS and transit traffic can still be maintained.
An alternative approach would be to pre-load a common, more complete set of rules prior to service subscription and leave the application layer to control access to each service. Once this had been granted, then the appropriate QoS rules would automatically apply without the need for further HG configuration. Service classification is only part of the story. There then needs to be a configuration of the mapping of a service class to a queue type. There is deliberately no fixed or default mapping in order to leave the maximum opportunity for SP differentiation. It would also be very risky to allow the EU to control this classification and mapping because of its complexity, and the need to consider the impact on all services. However individual end-user preference can be accommodated by the use of profiles, but these are managed by the SP, not directly by the enduser. This could support different types of user, e.g. Homeworker, gamer etc. and could even be changed on a time of day basis. Although most of the rules will be downloaded by the SP, some have to be set locally, but again not by the end-user. These were mentioned in the above Classification Section and include local IP SAs learned during DHCP address acquisition, and local MAC addresses learned after the selection of preferred devices by the end user.
checked (over a relatively short period of time) if this new instance could be accommodated without causing overload, as measured by excessive queue length. In addition to this simple overload protection mechanism, a more traditional Connection Admission Control (CAC) support function has also been defined. This prevents too many instances of a given service, by participating in (as opposed to snooping), the session signaling and rejecting a call if it would exceed the configured bandwidth limit for that class. So far this function has only been defined in detail for SIP based voice.
Page 12 of 31
Page 13 of 31
Further, the overload protection mechanism mentioned above requires an additional queue, making the total number of queues required at least 5. In this minimum queue set, there are at least 2 strict priority queues with the remainder being WRR. The highest priority queue is served to exhaustion. The second strict priority queue is served when the highest priority queue is empty, and the scheduling is such that the jitter on the highest priority queue due to all other queues is limited to a single packet. The highest priority queue would normally be used for voice, with the second queue being used for other CBR applications which were less jitter sensitive. While queues are nominally associated with particular traffic types, any service can be mapped to any queue, and the scheduling behaviour is configurable by means of the round-robin weightings. The overall aggregate can be shaped to a rate which can be configured to be less than the physical line rate, and there is also a per queue shaper for the WRR queues. This could be used for example to limit the maximum upstream rate of an Internet service. Figure 3 shows the data plane architecture for the upstream traffic in the case of 5 queues. The same model can be applied for a greater number of queues (there is an optional HGI requirement for 8 queues), by simple adding more queue instances of one or both types.
Queue 1 - SP Packets sent from LAN to a Layer 2 WAN port Scheduler Queue 2 - SP Packets sent L2 WAN egress port Classifier Sending Queue WRR with starvation prevention mechanism (Minimum bandwidth) Queue 3 WRR Weight 1 Shaping Shaping
Shaping
Page 14 of 31
Page 15 of 31
Delay matters for voice because at some point it impairs normal conversational interaction. This is typically at least ~300 msec for the complete end to end path. However well below this figure, the (de-)jitter buffer size and echo canceller tail-length are likely to be exceeded, which can result in packet drops and/or poor echo cancellation. There are no hard rules on the acceptable network delay, but it is certainly tens rather than hundreds of milliseconds. From the above Table, it can be seen that even the single packet delay is of this order, and that any significant buffer size can result in delays greater than 100 ms. Note that this Table just contains the delays that can be incurred at this single network queuing point. There are many other factors that need to be included in the total end-to-end delay budget, e.g. coding/decoding, backhaul, service platform processing etc. The jitter requirements for video TCP ACKS are likely to be even more stringent.
Page 16 of 31
Delay as a function of buffer size (ms) Rate (Mbps) 1 2 5 10 25 100 Single packet delay (ms) 12.3 6.1 2.5 1.2 0.5 0.1 4kbytes 24.6 12.3 4.9 2.5 1.0 0.2 8kbytes 61.4 30.7 12.3 6.1 2.5 0.6 16kbytes 122.9 61.4 24.6 12.3 4.9 1.2 32kbytes 258.0 129.0 51.6 25.8 10.3 2.6
It can be seen that for downstream interface rates of 25 Mbps+, the delay experienced by downstream packets is minimal from the voice perspective, but certain types of streamed video may be more jitter sensitive. Even for voice, the delay can become significant for the lower rates, albeit much less so than for the upstream access link. The problem is that the rate at which a wireless interface will run is impossible to predict. Since it is possible that the link will run at a rate such that there is a problem, it would be advisable to configure the QoS scheme to address this issue in case it does happen.
Page 17 of 31
This is done in Tabular form for conciseness and ease of comparison. Note that both the service identification and treatment are completely flexible, allowing the Service Provider to tailor service offerings in any way he chooses.
Laptop 2 Laptop 1
WiFi Phone
HOME GATEWAY
ADSL access
TV
Fixed PC
A VoIP call using the FXS port and legacy voice terminal (Example DECT phone) -> red flow A UMA phone call from the Home Zone with the phone therefore connected to the WiFi interface -> blue flow Peer to peer file sharing or FTP server hosting from a fixed PC on the home network -> green flow
The problem is therefore that TCP based upstream data can use all of the available upstream bandwidth and cause excessive delay or packet drops to the voice Proposed Solution The following legend applies to the below Tables: u = upstream, d = downstream, SP = Strict Priority, WRR = Weighted Round Robin The numerical suffix denotes the queue number which in the case of Strict Priority queues is also the queue priority. Therefore uSP1 for example means the highest priority, upstream, strict priority queue.
Application
Flow
HG QoS req
Queue
Weighting
Red
LAN-WAN
uSP1
n/a
Blue Green
LAN-WAN LAN-WAN
uSP1 uSP2
n/a n/a
Notes: In this case there is no transit traffic. The only flows that need to be classified are in fact the voice calls; they can then be given priority over any other traffic, which will include the upstream data traffic. The 2 types of voice need to be identified via different voice signatures, but there is no real need to treat them differently from each other; if there were to be such a need then they could simply be put in different strict priority queues. In this simple example, only Strict Priority queues are needed; this avoids the need to configure a queue weighting, which would have no effect anyway. It is always necessary to specify the queuing behaviour required for packets with no recognised service signature. In general this will be the lowest priority queue, although it could be dropping the packet. In these Tables, SP means Strict Priority rather than Service Provider. Performance Improvement (delay) Assumptions: 8k buffer size, 448kbps US
Page 19 of 31
Flow
Upstream voice (red or blue) single call Upstream voice (red or blue) 2 calls Notes:
27ms
140ms
30ms
The additional delay for 2 calls is because a voice packet from one stream may get delayed behind a voice packet from the other. In addition to the reduction in delay, the use of separated queues also makes voice packet drop less likely
Laptop 2 Laptop 1
WiFi Phone
HOME GATEWAY
ADSL access
TV
Fixed PC
An ADSL2+ line with a maximum of 20 Mbps downstream rate is used with rate adaptive or fixed profiles. Simultaneous usage of the following services is assumed: A UMA phone call while UMA mobile is present in the Home Zone and connected to the WiFi interface -> blue flow Intensive web browsing including large file downloading -> green flow
Page 20 of 31
Laptop displaying HD content stored on an Ethernet hard disk drive acting as a DLNA media center -> red flow. This is assumed to be WMV HD type content, with a resolution as high as 1080p, which results in maximum MTU size packets at a bit rate of up to 8.5 Mbps.
The DS access rate and the in-home PLT rate may well be higher than the in-home Wifi rate depending on the instantaneous wireless transmission environment. The potential issues here are therefore: The wireless may become a bottleneck in the downstream direction, in which case the data download may delay the downstream voice. The wireless may also become a bottleneck in the transit direction, with the download delaying the transiting media stream. Although there is no explicit data upload in this scenario, even the US TCP ACKs from the data download may be sufficient to disrupt the upstream voice if nothing is done.
Proposed Solution Note that in the Downstream direction, there are a set of queues for each LAN port. In the case of Ethernet these are the individual, physical switch ports, whereas for a shared media interface, e.g. wireless, there will be a single set of queues per interface type. The queues are therefore those pertaining to the appropriate port.
Application
Flow
HG QoS req
Queue
Weighting
UMA voice
Blue
WAN-LAN
dSP1
n/a
WAN-LAN
Any unrecognised signatures MAC address of NAS Any unrecognised signatures IP tunnel DA Any unrecognised signatures
dSP3
n/a
Red
LAN-LAN
dSP2
n/a
Orange
LAN-LAN
dSP4
n/a
Blue -
LAN-WAN LAN-WAN
uSP1 uSP2
n/a n/a
Performance Improvement The US Voice improvements are the same as in the above Tables. The DS voice and transit improvements are as follows, and given as a function of the LAN rate.
Page 21 of 31
Flow
10Mbps 1ms
Laptop 2 Laptop 1
ADSL access
WiFi Phone
HOME GATEWAY
TV
Fixed PC
The following end devices and services are assumed to be active in the home network:
Page 22 of 31
Home Gateway Initiative 2009 All Rights Reserved
A VoIP call using FXS port and legacy voice terminal (e.g. DECT phone) A UMA phone call with the UMA phone connected to the WiFi interface A smart mobile phone with a WiFi interface and a SIP UA.
A certain amount of upstream bandwidth is allocated for voice; note that this is not sterilised bandwidth and can be used by other applications when there is no voice present. Note that just as there is the concept of a service class, i.e. a set of services that all receive the same queuing treatment, there can also be a CAC class, i.e. a set of voice services which have a common bandwidth limit for CAC purposes. Currently these would all need to be SIP-based. The bandwidth limit for a CAC class is configurable, and could either be set based on a number of calls, or so as to always leave a significant percentage of the upstream bandwidth available for other purposes. The potential Issues here are therefore: ensuring that the US voice gets priority over other US traffic. limiting the number of calls to less than the US rate, thereby leaving some bandwidth for US data or ACKs
Proposed Solution Application HG QoS req Service Signature Physical (FXS) port IP DA of SIP SBG IP tunnel DA Any unrecognised signatures Queue Weighting
LAN-WAN
uSP1
n/a
LAN-WAN
uSP2
n/a
LAN-WAN LAN-WAN
uSP3 uSP4
n/a n/a
Notes: In this case, the proposed solution actually separates out the different voice applications. Whether or not this is sensible is partly a business decision, but is also related to the way the CAC function works, i.e. only on SIP-voice. The Wifi phones are the only type which actually use SIP and therefore may be subject to call rejection. This traffic is therefore given priority over UMA voice traffic, so it is not penalised twice in the event of overload (which can still occur). However the analogue voice is also subject to a kind of CAC of its own, due to the limited number of FXS ports (2). Since there may be a user expectation that this type of phone can always be used for emergency calls, these are given the top priority. Performance Improvement (delay) Assumptions: 8kbyte buffer size, 448kbps US
Page 23 of 31
Flow
Upstream voice 1 call Upstream voice 2 calls Upstream voice 3 calls Upstream voice 4 calls Notes:
The additional delay for more than one call is because a voice packet from one stream may get delayed behind a voice packet from one or more of the others. In addition to the reduction in delay, the use of separate queues also makes voice packet drop less likely.
ADSL access
Laptop 2
HOME GATEWAY
TV
Fixed PC
Page 24 of 31
Private WiFi network UMA phone call via the WiFi interface Several laptops
Guest access WiFi SIP phone connected to the WiFi guest access One laptop
The bandwidth sharing rules are: the upstream bandwidth sharing split between private zone and guest access is configurable but assumed to be 80:20 for this example. in the case where there is no traffic in the private zone, guests can have 100 % of the upstream bandwidth
The issues here are: ensuring that the Guest User gets a limited, maximum share of the bandwidth under congestion ensuring that the US voice gets priority over data ensuring that the private voice gets priority over Guest voice.
Proposed Solution Application Flow HG QoS req Service Signature Physical (FXS) port IP DA SIP SBG Private SSID Packet length< Red LAN-WAN Guest SSID Packet length< Blue LAN-WAN Private SSID Packet length> Green (dashed) Red LAN-WAN Any Ethernet port Guest SSID Packet length Green LAN-LAN MAC SA or DA of file server Any unrecognised signatures IP SA SIP SBG dSP2 n/a uWRR1 80 uWRR1 80 uSP3 n/a Queue Weighting
Analogue Voice SB VoIP SB UMA voice Guest UMA voice SB US wireless data SB US wired data Guest US data File server access Any other transit data Blue
LAN-WAN
uSP1
n/a
LAN-WAN LAN-WAN
uSP1 uSP2
n/a n/a
LAN-WAN
uWRR2
20
LAN-LAN
dSP4
n/a
SB VoIP
Page 25 of 31
WAN-LAN
dSP1
n/a
Notes The only downstream prioritisation in this case is being done on the SB VoIP, and it is debatable whether even this is necessary if it is going onto a Fast Ethernet LAN. There is no need to prioritize the analogue voice, as it is not queued in the HG in the DS direction. The other types of DS wireless voice could be prioritized, but unlike in the US, where SSID and packet length are used, the SSID here is not known until egress, and so this cannot be used as an ingress classifier. Note however that the packet does have to be sent out on the appropriate SSID, and so there has to be some identifier in order to be able to carry out this basic forwarding; this could be IP address, in which case this could also be as the service classifier. In addition to the service signatures, CAC can be done on any SIP based voice service. It would be sensible to do this separately on the SB and Guest voice access, i.e. specifying separate bandwidth limits for these two services. Indeed it might be appropriate to only do CAC on the Guest Access voice. In contrast to a previous example, even if the Guest Voice is Admissioncontrolled, it should remain the lowest priority voice. Performance Improvement The voice delay improvement is the same as in the above cases. The other improvement is that the guest data is limited to 20% of the capacity when there is congestion, but can get the full upstream and downstream bandwidth when there is no congestion. If a hard limit is required, this can be done by configuring a shaper on uWRR2.
Page 26 of 31
The issues to be addressed for this use case are as follows. ensuring that the Guest User gets a limited maximum share of the bandwidth under congestion ensuring that US voice gets priority over data ensuring that the SB voice gets priority over Guest voice. ensuring that admission control is applied separately to SB and guest access voice. prioritising the file server traffic
Proposed Solution Application Flow HG QoS req Service Signature Physical (FXS) port IP DA SIP SBG Private SSID Packet length< Red LAN-WAN Guest SSID uSP3 n/a Queue Weighting
LAN-WAN
uSP1
n/a
uSP1 uSP2
n/a n/a
voice SB US wireless data SB US wired data Guest US data File server access Any other transit data Blue LAN-WAN
Packet length< Private SSID Packet length> Green (dashed) Red LAN-WAN Any Ethernet port Guest SSID Packet length Green LAN-LAN MAC SA or DA of file server Any unrecognised signatures IP SA SIP SBG dSP2 n/a uWRR1 80 uWRR1 80
LAN-WAN
uWRR2
20
LAN-LAN
dSP4
n/a
SB VoIP
WAN-LAN
dSP1
n/a
Notes The only downstream prioritisation in this case is being done on the SB VoIP, and it is debatable whether even this is necessary if it is going onto a Fast Ethernet LAN. There is no need to prioritize the analogue voice, as it is not queued in the HG in the DS direction. The other types of DS wireless voice could be prioritized, but unlike in the US, where SSID and packet length are used, the SSID here is not known until egress, and so this cannot be used as an ingress classifier. Note however that the packet does have to be sent out on the appropriate SSID, and so there has to be some identifier in order to be able to carry out this basic forwarding; this could be IP address, in which case this could also be as the service classifier. In addition to the service signatures, CAC can be done on any SIP based voice service. It would be sensible to do this separately on the SB and Guest voice access, i.e. specifying separate bandwidth limits for these two services. Indeed it might be appropriate to only do CAC on the Guest Access voice. In contrast to a previous example, even if the Guest Voice is CACed, it should remain the lowest priority voice. Performance Improvement This is a fairly complex scenario, but the benefits are essentially the same as those quantified in the previous scenarios. However these benefits will be relevant far more often, as the overall network use, and in particular the number of voice calls, is likely to be far higher than in the residential environment. The SB and Guest voice are admission controlled independently, but even without CAC, the SB voice can be protected.
Page 28 of 31
Trademarks and copyrights mentioned in this document are the property of their respective owners. The HGI membership list as of the date of the formal review of this document is: 2 Wire, Inc., Alcatel-Lucent, Arcor, AVM, Belgacom, BeWAN, Broadcom, BT, Cisco, Comtrend, Deutsche Telekom, D-Link Corporation, DS2, DSP Group, Echelon EMEA, Entropic Communications, Ericsson AB, Fastweb SpA, France Telecom, Freescale Semiconductor, Gigaset, Gigle Semiconductor, Huawei, Ikanos, Infineon Technologies AG, Intel, Intellon, JDSU, Jungo Software Technologies, KDDI, LG-Nortel Co Ltd, Marvell Semiconductors, Microsoft, Mitsubishi, NEC Corporation, Netgear, NTT, Philips, Pirelli Broadband Solutions, Portugal Telecom, Sagem, Sercomm, SoftAtHome, SiConnect, Spidcom, Swisscom AG, Telecom Italia, Telefonica, Telekom Slovenije, Telekom Malaysia, Telekomunikacja Polska, Telenor, TeliaSonera, Telstra, Thomson, Tilgin AB, TNO, U4EA Technologies Limited, Vtech, Zarlink,
ZTE, ZyXEL
Page 29 of 31
9 Glossary
ADSL Asymmetric Digital Subscriber Line ALG ALL ASP ATM BBF Application Layer Gateway Application Layer Logic Application Service Provider Asynchronous Transfer Mode Broadband Forum
BRAS Broadband Remote Access Server BSP CAC CBR Broadband Service Provider Connection Admission Control Constant Bit Rate
DHCP Dynamic Host Configuration Protocol DLNA Digital Living Network Alliance DSCP Diffserv Codepoint EU GSM GUI HD HG HN HNID IMS LAN MAC MTU NAS NAT OTT PHY PLT QoS SBG SIP SLA SP SP SSID STB End User Global System Mobile Graphical User Interface High Definition Home Gateway Home Network Home Network Infrastructure Device Internet Multimedia Subsystem Local Area Network Media Access Control Maximum Transmission Unit Network Attached Storage Network Address Translation Over The Top (e.g. Internet based service) Physical (Layer) Powerline Technology Quality of Service Service Border Gateway Session Initiation Protocol Service Level Agreement Strict Priority Service Provider Service Set Identifier Set Top Box
Home Gateway Initiative 2009 All Rights Reserved
Page 30 of 31
VLAN Virtual LAN VoIP WAN WRR Voice over Internet Protocol Wide Area Network Weighted Round Robin
Page 31 of 31