Nəzəri əsaslar və memarlıq
RFC 3270 MPLS üçün üç QoS tunelləmə modelini təsvir edir: Uniform, Pipe və Short-Pipe. Seçim DSCP və TC-nin girişdə, tranzitdə və çıxışda necə dəyişdiyini müəyyən edir. 1. Uniform: tam şəffaflıq. Girişdə müştəri DSCP-si TC-yə uyğunlaşdırılır. Nüvə node-u TC-ni dəyişsə (məsələn, drop precedence-i artırsa), çıxışda dəyişmiş dəyər müştəri DSCP-sinə geri köçürülür və müştəri nüvənin təsirini görür. 2. Pipe: müştərinin izolyasiyası. DSCP girişdə TC-yə uyğunlaşdırılır, çıxışda müştəri DSCP-si dəyişməz qalır; bununla belə çıxış PE öz növbəsini etiketin TC-sinə görə planlaşdırır, ona görə TC ona çatmalıdır (PHP olmadan, məsələn explicit null ilə). 3. Short-Pipe: VPN xidmətləri üçün ən çox seçilən variant. Müştəri DSCP-si saxlanılır, çıxış interfeysində növbə müştərinin ilkin DSCP-sinə görə seçilir, ona görə nüvə müamiləsindən asılı deyil və PHP ilə işləyir.
Bir paketdə iki PHB iyerarxiyası
L3VPN-də müştəri paketi iki müstəqil prioritet daşıyır: müştəri DSCP-sinə uyğun daxili (tunneled PHB) və operator etiketinin TC-sinə uyğun xarici (LSP PHB). RFC 3270 (bölmə 4) üç tunelləmə modelini adlandırır, yəni üç suala üç cavab verir: push zamanı daxili prioritet xariciyə köçürülürmü; pop zamanı xarici daxiliyə qaytarılırmı; egress PE paketi CE-yə çıxışda iki PHB-dən hansına görə növbəyə qoyur. Seçim performans məsələsi deyil, müqavilə şərtidir: operator müştəri DSCP-sini dəyişirmi və müştəri işarələməsi SLA-nın bir hissəsidirmi.
Uniform: CE-dən CE-yə qədər bir DiffServ domeni
Push zamanı TC DSCP-dən çıxarılır (köçürmə və ya cədvəl); tranzit P-lər TC-ni dəyişə bilər (re-marking, sıxlıq və ya profil pozuntusu zamanı mark-down) və bu dəyişiklik lokal deyil: etiket götürüləndə TC dəyəri açılan başlığa köçürülür, yəni növbəti etiketin TC-sinə və ya IP paketin DSCP-sinə (RFC 3270). Nəticə: CE-yə çıxan IP paket müştərinin yox, nüvənin müəyyən etdiyi DSCP daşıyır. Model operator və müştəri bir DiffServ inzibati domenini təşkil etdikdə uyğundur: MPLS üzərində korporativ şəbəkə, istifadəçi IP trafikinin onsuz da provayderə məxsus olduğu provayder magistralı və ya ümumi siyasəti olan domenlər arasında tranzit. Öz QoS sxemi olan müştəriyə satılan VPN xidməti üçün Uniform zərərlidir: müştəri onun işarələməsinin nüvə tərəfindən yenidən yazıldığını görür.
Pipe: nüvə görünməzdir, amma egress ona tabedir
Ingress PE TC-ni operator siyasəti ilə təyin edir (köçürmə ilə yox, xidmətin SLA-sına görə) və daxili DSCP-yə toxunmur; pop zamanı heç nə köçürülmür, çıxışda müştəri DSCP-si olduğu kimi qalır. Lakin RFC 3270-ə görə egress LSR paketi xarici PHB-yə, yəni operator tərəfindən təyin edilmiş (və nüvə tərəfindən dəyişdirilə bilən) TC-yə görə növbəyə qoyur, müştəri DSCP-sinə görə yox. Mənası: operator müştərinin DSCP-də nə yazdığından asılı olmayaraq, CE-yə son link də daxil olmaqla, bütün yol boyu xidmət sinfini zəmanət edə bilər. Qiyməti: egress PE TC-ni görməlidir. PHP penultimate P-də etiketi götürəndə TC yoxa çıxır; L3VPN-də çıxış yolu var, çünki VPN etiketi stekdə qalır və öz TC-sini daşıyır, VPN etiketi olmayan tək etiketli LSP-lər (IPv4 over LDP, VPN etiketsiz 6PE) üçün isə PHP söndürülməlidir: egress explicit-null elan edir (IPv4 üçün 0, IPv6 üçün 2 etiketi, RFC 3032) və son hop TC olan etiket daşıyır.
Short-Pipe: nüvə görünməzdir və egress onu nəzərə almır
Ingress və tranzit Pipe ilə eynidir: TC operator tərəfindən təyin edilir, DSCP nə köçürülür, nə də dəyişdirilir. Fərq yalnız egress PE-dədir: CE-yə çıxış növbəsi daxili PHB-yə, yəni müştəri DSCP-sinə görə, adi IP trafiki kimi seçilir. Nüvədəki mark-down son linkdə "bağışlanır": P sıxlığa görə EF-i TC 5-dən TC 0-a salıbsa, müştəri EF-i yenə də çıxışda prioritet növbəyə düşür. PHP maneə olmur: egress PE yalnız VPN etiketini (və ya sadə IP-ni) alır və hər halda DSCP-yə görə təsnif edir. Bu, provayderlərdə ən geniş yayılmış modeldir: CE interfeysindəki müştəri növbəsi müştərinin məsuliyyətidir, müştərinin DSCP profilini isə PE ingress təsnifatından artıq bilir.
| Model | Ingress PE (push) | P və PHP | Egress PE: çıxış növbəsi | CE-yə çıxışda DSCP | UHP lazımdır? |
|---|---|---|---|---|---|
| Uniform | TC DSCP-dən | TC dəyişir, pop zamanı aşağı köçürülür | TC-yə görə (köçürmədən sonra bu DSCP-dir) | Nüvə tərəfindən yenidən yazılıb | Xeyr |
| Pipe | TC operator siyasəti ilə | TC dəyişir, köçürülmür | Etiketin TC-sinə görə | Müştərinin ilkin dəyəri | VPN etiketi olmayan LSP-lər üçün bəli |
| Short-Pipe | TC operator siyasəti ilə | TC dəyişir, köçürülmür | Müştəri DSCP-sinə görə | Müştərinin ilkin dəyəri | Xeyr |
Eyni paket üç modeldə
Müştəri EF (DSCP 46) göndərdi. Ingress PE TC 5 qoydu. P1-də profil pozuldu və P1 TC-ni 0-a yenidən yazdı. Bundan sonra modellər fərqlənir:
| Paket nə görür | Uniform | Pipe | Short-Pipe |
|---|---|---|---|
| P1-dən sonra nüvədə TC | 0 | 0 | 0 |
| CE-yə son linkdə növbə | Best Effort | Best Effort (TC 0-a görə) | Prioritet (DSCP EF-ə görə) |
| CE-yə çıxışda DSCP | 0 (itirilib) | 46 (saxlanılıb) | 46 (saxlanılıb) |
| Mark-down-un müştəriyə görünməsi | DSCP-də görünür | Gizlidir, amma gecikmə və itki görünür | Gizlidir, təsir minimaldır |
Hər qovşaqda nə baş verir
Ingress PE: müştəri DSCP/ACL-inə görə təsnif edir və TC-ni stekin bütün etiketlərinə (nəqliyyat və VPN) qoyur. Tranzit P: yalnız xarici etiketi dəyişir (swap), policer və ya remark işləməyibsə TC ötürülür; P nə DSCP-ni, nə də daxili etiketi görür. Penultimate P PHP zamanı nəqliyyat etiketini götürür; Uniform-da o (və ya egress PE) TC-ni açılmış VPN etiketinə və ya IP-yə köçürür; Pipe və Short-Pipe-da köçürmə yoxdur. Egress PE: VRF-i VPN etiketinə görə tapır, IP lookup edir və paketi seçilmiş modelin qaydalarına görə çıxış növbəsinə qoyur. PHP seqmentində explicit-null qoyulubsa, əlavə etiket son linkdə 4 bayta və egress-də əlavə lookup-a başa gəlir: bəzi ASIC-lər onu ikinci keçiddə edir, ona görə explicit-null şüurlu şəkildə və yalnız VPN etiketi olmayan LSP-lər üçün aktivləşdirilir.
