4.3. Verificación de Hipótesis
4.3.1. Verificación de la Hipótesis Especifica 01
At the time of writing this document the services supported by the VN2 Network are HSI, Voice, Video & Business VPN. This section details the QoS recommendation to support the above listed services.
6.8.3.1 Service Classes
A service class represents a set of traffic that requires common delay, loss and jitter characteristics from the network for which consistent and defined per-hop behaviour applies. Conceptually, a service class pertains to applications with similar characteristics and performance requirements. Table 6 details the service classes that shall be supported within the VN2 Network.
Application
Categories Service Classes Application Examples
Control Plane CONTROL Network Routing
Application Control Voice Telephony Signalling
IEEE1588v2 Precision Timing Protocol
Media-Oriented Voice Telephony Bearer
Video Broadcast TV, Video on Demand
Business Data Data 1
Business traffic and OAM (SNMP, SSH)
Data 2 Business Traffic
Best-Effort Standard HSI-Business/Residential
Table 6: Service Classes 6.8.3.2 Control Service Class
The CONTROL service class is used for inter-router signalling protocol traffic.
Inter-router signalling protocols are responsible for maintaining the network logical topology and switching; these protocols are the most important protocols crossing the network; even more important than customer real-time traffic itself. If inter- router signalling protocols are affected, then this can affect all client traffic passing through a network node.
Applications that may use the CONTROL service class are router control-plane traffic that is originated by the VN2 Network itself (i.e. OSPF, ISIS, RSVP), or router control-plane traffic that passes through at least one network node (Multi- Protocol BGP, Targeted LDP).
All flows in the CONTROL service class shall use a Network Control (NC1) PHB and shall be marked with the DiffServ Codepoint Class Selector 48 and IP precendece 6.
6.8.3.3 Voice Service Class
The Voice service class is used for applications that require very low delay, very low jitter and very low packet loss for relatively constant rate traffic sources. All traffic in this class originates from internal network controlled equipment.
The following applications should use the Voice service class
• VoIP (G.711, G.729 and other codecs)
• Voice-band data over IP (modem, fax)
• T.38 fax over IP
• Circuit emulation Service, CESoPSN & SAToP
• IEEE1588v2 Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems
• Peer-to-peer IP telephony signaling (i.e. SIP, H.323)
• Peer-to-peer signalling for multimedia applications (i.e. SIP, H.323)
• Peer-to-peer real-time control function
• Client-server IP telephony signalling (i.e. H.248, MEGACO)
• Signalling flows between high-capacity telephony call servers or soft switches using protocol such as SIP-T. Such high-capacity devices may control thousands of telephony (VoIP) calls.
The Voice service class shall use an Expedited Forwarding (EF) PHB and the recommended DiffServ Codepoint is Expedited Forwarding (EF). This service class should be configured to receive guaranteed forwarding resources and all packets should be forwarded without being subject to delay since the inelastic types of RTP payloads in this class do not react to loss or significant delay in any substantive way.
6.8.3.4 Video Service Class
The Broadcast Video service class is used for applications that require near-real- time packet forwarding with very low packet loss of constant rate and variable rate inelastic traffic sources. Such applications include broadcast TV, streaming of live audio and video events, some video-on-demand applications, and video surveillance. In general, the Broadcast Video service class assumes that the destination end point has a delay jitter buffer, for video application usually a 2 - 8 video-frame buffer (66 to several hundred of milliseconds), and therefore that it is less sensitive to delay and jitter.
The following applications should use the Broadcast Video service class:
• Video surveillance and security (unicast).
• TV broadcast including HDTV (multicast).
• Video on demand (unicast) with control (virtual DVD).
• Streaming of live audio events (both unicast and multicast).
• Streaming of live video events (both unicast and multicast).
The Video service class shall use an Assured Forwarding (AF) PHB and shall be marked with the DiffServ Codepoint AF41 and IP predecence 4.
6.8.3.5 Data 1 Service Class
The Data 1 service class is used for applications that require a low packet loss and are relatively sensitive to delay. The service class is also responsible for carrying OAM (Operations, Administration, and Management) using protocols such as Simple Network Management Protocol (SNMP), FTP/SCP, and SSH.
The following applications should use the Data 1 service class:
• Store and forward applications
• File transfer applications
• VPN service that supports two rates (committed information rate and excess or peak information rate)
• Provisioning and configuration of network elements
• Performance monitoring of network elements
• Any network operational alarms
All flows in the Data 1 service class shall use an Assured Forwarding (AF) PHB and shall be marked with the DiffServ Codepoint AF31 and IP Precedence 3.
6.8.3.6 Data 2 Service Class
The Data 2 service class is used for elastic applications that require timely packet
forwarding of variable rate traffic sources and, more specifically, is configured to provide good throughput for TCP longer-lived flows. TCP or a transport with a consistent
congestion avoidance mechanism will normally drive as high a data rate as it can obtain over a long period of time.
The following applications should use the High-Throughput Data service class:
• Store and forward applications
• File transfer applications
• VPN service that supports two rates (committed information rate and excess or peak information rate)
The High-Throughput Data service class should use an Assured Forwarding (AF) PHB and the recommended DiffServ Codepoint is AF32 and IP Precedence 2.
6.8.3.7 Standard Service Class
The Standard service class is used for traffic that has not been classified into one of the other supported forwarding service classes in the DiffServ network domain. This service class provides "best-effort" forwarding behavior and typically has minimum bandwidth guarantee.
The following applications should use the Standard service class
• Network services, DNS, DHCP, BootP
• Any undifferentiated application/packet flow transported through the DiffServ enabled network.
The Standard service class shall use an Assured Forwarding PHB and the recommended DSCP marking is DF (Default Forwarding).
6.8.3.8 Classification
Classification of traffic is achieved by the SAP ingress policy assigned at the edge of the network. Multi-field classification is the process of selecting packets based on the content of some arbitrary number of header fields; typically some combination of
source/destination address, DiffServ Codepoint, protocol ID, source/destination port.
Following multi-field classification and the relevant marking, subsequent classification is based purely on the contents of the DiffServ Codepoint or MPLS EXP bits and is referred to as Behaviour Aggregate (BA) classification. In turn BA classification is linked to a specific PHB group.
Within the 7x50 this marking is achieved by mapping ingress traffic to the relevant Forwarding Class, and each Forwarding Class is uniquely identified throughout the
remainder of the DiffServ Domain using specific MPLS EXP values. A SAP- ingress QoS policy is provided on the Service Access Point (SAP). Classification of traffic can be based on the physical interface, sub-interface (i.e. VLAN, VPI/VCI,
DLCI) or based on any OSI Layer 2, Layer 3, or Layer 4 criteria as defined in Table 7. Note that for the purpose of brevity IPv4 and IPv6 are simply collapsed into „IP criteria‟.
Layer Criteria Remarks
MAC criteria Frame Type 802.3, 802.2 LLC, 802.2 SNAP,
Ethernet II
Layer Criteria Remarks SNAP-PID
Source MAC
IP Criteria
Protocol i.e. GRE, ICMP, IGMP, PIM, OSPF
DSCP
Destination IP address Destination port
Fragment Criteria applies to IP fragments
Source IP address Source port
Default-FC All traffic received on SAP mapped to
specified FC Table 7: Multi-field Classification Criteria
Although the potential exists to employ multi-field classification using the criteria defined in Table 7 at the SAP ingress, the potential also exists to take all traffic received over a particular SAP and map it to a definable FC using the „Default-FC‟ capability. For the purpose of simplicity, it is recommended that the „Default-FC‟ method of classification be utilised on a single logical/physical interface wherever possible, and that IP/MAC criteria is used only where multiple traffic types are carried over a single logical/physical interface.
6.8.3.9 Service Classes and Traffic Aggregates
Once traffic has been classified, it requires marking in order that transit routers can infer the required PHB group. There is a distinct difference between the granularity of PHB on access (customer/client/subscriber) interfaces and the granularity of PHB on network interfaces.
On network interfaces where there is a large number
of aggregated customer flows the queuing and scheduling is less granular to reduce network complexity. In contrast, on customer/client/subscriber interfaces the potential exists to have much more granular queuing in order to obtain the required forwarding treatment for different traffic classes.
In order to achieve this aggregation on network ports, service classes are aggregated into treatment aggregates within the network core. The proposed application to class of service is taken from Table 8: QoS Service Classes and involves mapping of two or more services classes into a single forwarding treatment aggregate.
The degree of aggregation and hence the number of treatment aggregates depends on a number of factors; most notably these are the speed of the links and whether the scheduler implementing the aggregation can minimize the affects of mixing traffic with different packet sizes/transmit rates on queue depth. Generally however, higher speed links allow for more aggregation and a smaller number of treatment aggregates.
This treatment aggregation of service class subsequently needs to be made identifiable within the core network through DiffServ codepoints and MPLS EXP markings as detailed in Table 8. Note that the STANDARD class (ELASTIC treatment aggregate) is assigned two MPLS EXP settings to differentiate in-profile traffic (Business HSI) from out-of-profile traffic (Residential HSI) with Weighted RED configured to ensure that the latter is dropped before the former.
Application Example Service Class DiffServ
Codepoint
Treatment Aggregate
MPLS EXP Control Protocol RSVP, OSPF,
ISIS, BGP CONTROL CS-6 Network
distribution IEEE1588v2 SIGNALLING EF
Video
STANDARD Default ELASTIC
In- Table 8: QoS Service Classes
Table 9 details the treatment aggregates, MPLS EXP markings together with the internal Forwarding Class and queue types that are proposed to support the service classes defined in Table 8.
Treatment
Aggregate MPLS EXP Forwarding
Class
Class
Type WRED
CONTROL EXP 6 Network Control High
Priority No
REALTIME-VOICE EXP 5 Expedited High
Priority No
Table 9: DiffServ QoS Marking
6.8.3.10 Network QoS Policy
On network interfaces where the queuing and scheduling is less granular to reduce network complexity, treatment aggregation is applied to the large number of aggregated client flows.
Given the service classes defined in Table 8 and the EXP/FC/Queue mappings defined in Table 9, Figure illustrates the network QoS policy, which can essentially be de-composed into four distinct categories
• The Ingress Network Policy that defines the EXP and DSCP mapping to the 7x50 internal Forwarding Classes.
• The Egress Network Policy defining the egress marking to be applied to traffic that has not already been marked (and is therefore applied by the ingress node only as transit traffic has already been marked)
EF
• The Network Queue defines the queuing scheduling characteristics (bandwidth, buffer) for each FC. The Network Queue is applied to all egress network ports. For network ingress traffic a Virtual Output Queue (VOQ) exists on the IOM, which implies some form of buffering on the MDA. However, as over-subscribed MDAs (i.e. >10Gb/s) aggregate <10Gb/s of traffic each MDA has 10Gb/s access to the IOM/Switch Fabric and as such this is not considered a queuing point. This is an important concept as maximum queuing delays are calculated purely on egress port buffering and do not factor ingress MDA queuing/buffering.
• The WRED Slope Policy that defines when Weighted Random Early Detection is applied to the shared buffer space.
Network Policy (Ingress) Network Queue Policy Network Policy (Egress)
Control Exp7 In NC
Figure 19: Network QoS Policy
The queue type and percentage CIR/PIR allocated to each of the network queues is defined in Table 10. CONTROL, REALTIME-VOICE and REALTIME-VIDEO are high-priority (expedited) queues and ASSURED-ELASTIC and ELASTIC queues are low-priority.
Treatment Aggregate Network
Queue Priority CIR PIR
CONTROL 8 High 5% 100%
REALTIME-VOICE 6 High 20% 20%
REALTIME-VIDEO 5 High 30% 30%
ASSURED ELASTIC 4 Low 15% 30%
ASSURED ELASTIC 3 Low 15% 100%
ELASTIC 1 Low 0% 100%
Table 10: Queue Type and CIR/PIR allocation
Given the parameters defined in Table 10 the following scheduling behaviour will be observed
• CONTROL, REALTIME-VOICE and REALTIME-VIDEO queues (queue 8, 6, and 5) are high-priority (expedited) queues and are serviced in a strict priority before the round-robin low-priority queues.
o The REALTIME-VOICE queue has a CIR of 20% and a PIR of 20%.
It is guaranteed 20% of line-rate and is constrained to 20% of line- rate (PIR) as its traffic profile dictates.
o The REALTIME-VIDEO queue has a CIR of 30% and a PIR of 30%.
It is guaranteed 30% of line-rate and is constrained to 30% of line- rate (PIR) as its traffic profile dictates.
o The CONTROL queue has a CIR of 5% and is guaranteed 5% of line-rate and has a PIR of 100% as we have no desire to constrain network control traffic.
• The ASSURED ELASTIC queue (queue 4 and 3) and ELASTIC queue (queue 1) are round-robin (low-priority) queues and are serviced after the CONTROL, REALTIME-VOICE and REALTIME-VIDEO queues up to their respective CIR level. As the ELASTIC queue has 0% CIR, the ASSURED- ELASTIC class will always be serviced first. However, queues 3 can use up to 100% of the available bandwidth in the absence of other traffic.
For control plane (OSPF, RSVP etc) and OAM management traffic marking and queuing (SNMP, SSH, locally-generated ICMP etc) the control plane traffic uses Forwarding Class H1 and DiffServ codepoint CS-6 whilst management traffic uses Forwarding Class H2 and DiffServ codepoint AF41. To ensure that these protocols operate correctly, some resource (in terms of bandwidth/buffer space) is necessary
and consideration has been given to this requirement for the queue allocations detailed in Table 10.
6.8.3.11 Buffer Management
6.8.3.11.1 Servicing Rate and Buffer Allocation
The Committed Burst Size (CBS) defines the guaranteed/committed burst size whilst the Maximum Burst Size (MBS) defines maximum buffer allocation for a given queue. CBS can be considered guaranteed or committed simply because it is taken from reserved pools unlike MBS which is taken from shared pools. The amount of buffer allocated to any queue can be derived from the following formula
The rate at which allocated and configured buffer is emptied is based upon the servicing rate of the queue. For example, a 10 Gigabit Ethernet port has a total buffer pool
allocation of ~250MB; hence with a servicing rate of 10,000,000,000 bits per second (equivalent to line-rate) it is possible to buffer for up to 200 milliseconds if the entire buffer space is allocated to a single queue. When
multiple individual queues are serviced however, the servicing rate is slower hence the potential time spent in a buffer will increase.
On network interfaces, the rate at which the queue is serviced (RATE, CIR) and the buffer allocated to that queue is defined as a percentage of the physical interface and expressed as a non-fractional integer. For example, a buffer allocation of 10% on a 10 Gigabit Ethernet interface would be 25Mbytes (250MB/100*10), which, with a serialisation rate of 10,000,000,000 would represent a maximum of 20 milliseconds of buffer.
6.8.3.11.2 Service-Class Buffer Allocation
As defined in Table 10 network interfaces support five queues, and although no explicit delay characteristics have been requested of the network at the time of writing, it is reasonably clear that the traffic aggregates forming those queues have differing buffer allocation requirements.
1. Queue 8 is an expedited queue dedicated to CONTROL traffic with relatively low tolerance to delay and should be configured with a CBS and MBS of 20 milliseconds of the CIR/PIR respectively.
2. Queue 6 is an expedited queue servicing the REALTIME-VOICE treatment aggregate and predominantly contains IP/UDP/RTP traffic with very low tolerance to delay/jitter. As this traffic has no inherent congestion control mechanism it should not take resource from the shared buffer space (hence PIR=CIR) where WRED is configured and shall be configured with an equal CBS/MBS equal to 10 milliseconds.
3. Queue 5 is an expedited queue servicing the REALTIME-VIDEO treatment aggregate and predominantly contains IP/UDP/RTP or RTSP traffic. As with REALTIME-VOICE this traffic has no inherent congestion control mechanism so once again should not take resource from the shared buffer space (PIR=CIR) and shall be configured with an equal CBS/MBS of 10 milliseconds.
4. Queue 3 and 4 are weighted queue servicing the ASSURED-ELASTIC treatment aggregate and shall be configured with a CBS and MBS equal to 50 milliseconds of the CIR/PIR respectively.
5. Queue 1 is a weighted queue servicing the ELASTIC treatment aggregate.
The service classes contained within this treatment aggregate (Business HSI, Residential HSI) have no stringent latency requirements and are of comparative low priority. In order to ensure that the ASSURED-ELASTIC treatment aggregate is serviced before the ELASTIC treatment aggregate, no CIR value is applied to ELASTIC and all traffic is queued in shared buffer. Therefore a nominal CBS value of 1 to allow a minimum buffer shall be configured with MBS configured for 100 milliseconds.
Per-port buffer allocation varies on an MDA basis (number of ports) and the port configuration (i.e. network/access mode; speed), however, the requirement is that the maximum buffer delay is consistent on a network-wide basis in order to yield a deterministic maximum delay/jitter.
6.8.3.11.3 Weighted RED
As the ELASTIC treatment aggregate will carry in-profile (Business HSI) and out- of-profile (Residential HSI) traffic, Weighted Random Early Detection (WRED) will be used to ensure that in the advent of congestion out-of-profile traffic is discarded before in-profile traffic. The ELASTIC treatment aggregate is serviced by queue 1, and there are two
separate WRED profiles that can be applied to the shared buffer space of this queue; the low slope, which operates on out-of-profile traffic, and the high slope, which operates on in-profile traffic.
Weighted Random Early Detection shall be used within the shared buffer space to ensure that in the advent of congestion low priority traffic (Residential HSI) is discarded before higher priority traffic also consuming shared buffer (Business HSI). WRED monitors the queue depth of a given port and randomly drops traffic with increasing probability as the average queue depth increases. Congestion- aware protocols such as TCP detect congestion after experiencing packet loss; reduce the transmission rate (typically by half), and
subsequently implement a
slow-start algorithm to detect a sustainable throughput. Using WRED to control the average buffer occupancy allows network queues to reach a more stable utilisation level and generally increases throughput for TCP traffic.
The 7x50 has two separate WRED profiles that are applied to the shared buffer space; the low slope operates on out-of-contract/out-of-profile traffic whilst the high slope operates on in-contract/in-profile traffic. Figure shows a typical WRED slope
1 0 Drop Probability max-prob
plotted in an x-y graph; the x-axis is the percentage of shared buffer average utilisation; the y-axis is the probability of packet discard.
max-avg
start-avg
0 Buffer Depth
Figure 20: WRED Parameters
The WRED slopes are specified using the start-avg, max-avg, and max-prob parameters in the associated buffer policy. From zero buffer depth to start-avg the packet discard
probability is zero. Between start-avg and max-avg, the packet discard probability is proportional to the average buffer utilisation and ranges from zero to the max-prob. At the
probability is zero. Between start-avg and max-avg, the packet discard probability is proportional to the average buffer utilisation and ranges from zero to the max-prob. At the