Merkkaus
Tietoliikenteen palvelunlaadun merkkaus
Lehtori Karo Saharinen
karo.saharinen@jamk.fi tai Slackissä @sahka
Luokittelun perusteet
- Tarvitaan tapa jolla voidaan erotella paketit toisistaan jotta niitä voidaan käsitellä oikein
- Esim
- VC numero
- MPLS otsikko
- ToS (Type of Service)
- Protokolla
- Osoite
- Lähde IP osoite
- Kohde IP osoite
- Porttinumero
- Lähdeportti
- Kohdeportti
- Tuleva portti
- DSCP (DiffServ Code Point)
Differentiated Services Code Point
IPv4 -otsikko
IPv6 -otsikko
DSCP
- IPv4 TOS-kentän uudelleen käyttö
- RFC791 -> RFC2474
- Differentiated Services Code Point -luokat
- Expedited Forwarding (EF)
- Assured Forwarding (AFxy, jossa X luokka, Y drop preference)
- Best Effort (BE)
- [Class Selector (CS)]
Expedited Forwarding (EF)
The intent of Expedited Forwarding PHB [RFC3246] is to provide a building block for low-loss, low-delay, and low-jitter services. It can be used to build an enhanced best-effort service: traffic remains subject to loss due to line errors and reordering during routing changes. However, using queuing techniques, the probability of delay or variation in delay is minimized. For this reason, it is generally used to carry voice and for transport of data information that requires "wire like" behavior through the IP network. Voice is an inelastic "real-time" application that sends packets at the rate the codec produces them, regardless of availability of capacity. As such, this service has the potential to disrupt or congest a network if not controlled. It also has the potential for abuse.
Source: RFC4594 Section 1.5.3
Assured Forwarding (AFxy)
The Assured Forwarding PHB [RFC2597] behavior is explicitly modeled on Frame Relay's Discard Eligible (DE) flag or ATM's Cell Loss Priority (CLP) capability. It is intended for networks that offer average-rate Service Level Agreements (SLAs) (as FR and ATM networks do). This is an enhanced best-effort service; traffic is expected to be "elastic" in nature. The receiver will detect loss or variation in delay in the network and provide feedback such that the sender adjusts its transmission rate to approximate available capacity.
For such behaviors, multiple DSCP values are provided (two or three, perhaps more using local values) to identify the traffic, a common queue to store the aggregate, and active queue management to protect the network from it and to limit delays. Traffic is metered as it enters the network, and traffic is variously marked depending on the arrival rate of the aggregate. The premise is that it is normal for users occasionally to use more capacity than their contract stipulates, perhaps up to some bound. However, if traffic should be marked or lost to manage the queue, this excess traffic will bemarked or lost first.
Source: RFC4594 Section 1.5.2
Best Effort (BE)
The basic forwarding behaviors applied to any class of traffic are those described in [RFC2474] and [RFC2309]. Best-effort service may be summarized as "I will accept your packets" and is typically configured with some bandwidth guarantee. Packets in transit may be lost, reordered, duplicated, or delayed at random. Generally, networks are engineered to limit this behavior, but changing traffic loads can push any network into such a state.
Source: RFC4594 Section 1.5.1
Class Selector (CS)
Class Selector provides support for historical codepoint definitions and PHB requirement. The Class Selector DS field provides a limited backward compatibility with legacy (pre DiffServ) practice, as described in [RFC2474], Section 4. Backward compatibility is addressed in two ways. First, there are per-hop behaviors that are already in widespread use (e.g., those satisfying the IPv4 Precedence queuing requirements specified in [RFC1812]), and we wish to permit their continued use in DS-compliant networks. In addition, there are some codepoints that correspond to historical use of the IP Precedence field, and we reserve these codepoints to map to PHBs that meet the general requirements specified in [RFC2474], Section 4.2.2.2.
No attempt is made to maintain backward compatibility with the "DTR" or Type of Service (TOS) bits of the IPv4 TOS octet, as defined in [RFC0791] and [RFC1349].
Source: RFC4594 Section 1.5.4
DSCP -luokat
DSCP -luokat
- Bitit 0, 1 ja 2
- Määrittävät luokan
- Bitit 3 ja 4
- Määrittävät paketin tiputuksen todennäköisyyden (WRED)
- Bitti 5
- Aina arvo 0
Best Effort
- Kaikki bitit kentässä ovat nollia
- Huom! Jos verkkolaitteita ei ole konfiguroitu QoS DiffServ –asetuksilla niin kaikki paketit merkkauksesta huolimatta kuuluvat Best Efforttiin.
Assured Forwarding 1 - AF1
- Class Selector == DSCP –kentän kokonaisarvo
- AF1 = CS8
- AF11 = CS10
- AF1 – low drop precedence
- AF12 = CS12
- AF1 – medium drop precedence
- AF13 = CS14
- AF1 – High drop precedence
Assured Forwarding 2 - AF2
- Class Selector == DSCP –kentän kokonaisarvo
- AF2 = CS16
- AF21 = CS18
- AF2 – low drop precedence
- AF22 = CS20
- AF2 – medium drop precedence
- AF23 = CS22
- AF2 – high drop precedence
Assured Forwarding 3 - AF3
- Class Selector == DSCP –kentän kokonaisarvo
- AF3 = CS24
- AF31 = CS26
- AF3 – low drop precedence
- AF32 = CS28
- AF3 – medium drop precedence
- AF33 = CS30
- AF3 – high drop precedence
Assured Forwarding 4 - AF4
- Class Selector == DSCP –kentän kokonaisarvo
- AF4 = CS32
- AF41 = CS34
- AF4 – low drop precedence
- AF42 = CS36
- AF4 – medium drop precedence
- AF43 = CS38
- AF4 – high drop precedence
Expedited Forwarding - EF
- Class Selector == DSCP –kentän kokonaisarvo
- EF = CS40
- EF = CS46
DSCP luokkataulukko
DSCP luokkataulukko
Precedence
IPv4 -otsikko
IPv6 -otsikko
Precedence
- Vanhentuneet määritelmät (RFC 791), jotka DSCP RFC:ssä 2474 korvaa
- Jotkin laitteet silti tukevat vain näitä arvoja
Precedence<->DSCP -
luokkataulukko
- HUOM!
Precedence toimii käytännössä CS-arvona! DSCP tuo drop probabilityt lisäyksenä!
Ethernet
802.1p User Priority –kenttä, sekä QinQ ja MinM
802.1Q VLAN-leima
802.1p vs Precedence
QinQ (802.1ad)
- Tuplaleimauksella 802.1p –kenttä on kahdesti yhdessä Ethernet –kehyksessä
- Asiakkaan 802.1p –arvo
- Operaattorin 802.1p -arvo
MinM (802.1ah)
- MinM –headerissa QinQ-arvot säilyvät
- Asiakas + Operaattorileima
- Lisäyksenä MinM-leima
- Prioriteettikenttä 7bittiä
- Pystytään kopioida DSCP-kentän arvo suoraan MinM-headeriin
MPLS Traffic Class -kenttä
MPLS
RFC 5462
- TC = 3bittiä
- Ei yleistä ohjeistusta miten käyttää
- Käytännössä
- DSCP CS-kenttä tai Precedence kopioidaan MPLS TC-kenttään
- Leimakytkentä yleisesti Operaattorilla, joten asiakkaan DSCP tai Precedence voidaan muuttaa tällä rajalla
ATM ja Frame Relay
ATM
- CLP 1 bit
- Saa tiputtaa, jos ruuhkaa
Source: Microsoft Technet
Frame Relay
- DE 1 bit
- Saa tiputtaa, jos ruuhkaa
Source: Broadband-forum
Miten näitä kaikkia kenttiä nyt sitten pitäisi käyttää!?
RFC löytyy sitäkin varten :)
Source: RFC4594 Configuration Guidelines for DiffServ Service Classes
This document describes service classes configured with Diffserv and recommends how they can be used and how to construct them using Differentiated Services Code Points (DSCPs), traffic conditioners, Per-Hop Behaviors (PHBs), and Active Queue Management (AQM) mechanisms.
Source: RFC4594 Configuration Guidelines for DiffServ Service Classes