एका गजबजलेल्या हॉटेल, शॉपिंग सेंटर किंवा हॉस्पिटलमध्ये भरपूर बँडविड्थ असूनही खराब अनुभव येऊ शकतो. एखादा पाहुणा मोठे डाउनलोड सुरू करतो, कर्मचाऱ्यांचे डिव्हाइसेस बॅकग्राउंडमध्ये सिंक्रोनाइझ होतात आणि अचानक व्हॉईस कॉल तुटायला लागतो तर दुसरीकडे पेमेंट टर्मिनल प्रतिसादाची वाट पाहत राहते. याचा अर्थ लिंक अपुरी आहे असे नाही. तर नेटवर्क वेगवेगळ्या व्यावसायिक परिणामांच्या ट्रॅफिकला समान वागणूक देत आहे.
म्हणूनच नेटवर्क ट्रॅफिकला प्राधान्य कसे द्यावे याची सुरुवात राउटर चेकबॉक्सने नव्हे, तर पॉलिसीने होते. संघर्षादरम्यान कोणते ॲप्लिकेशन्स, लोक आणि डिव्हाइसेस वापरण्यायोग्य राहिले पाहिजेत हे तुम्हाला ठरवावे लागेल, नंतर हे निर्णय कॉन्फिगरेशन, ओळख यंत्रणा आणि ऑपरेशनल दस्तऐवजीकरणामध्ये दृश्यमान करावे लागतील. UK मार्गदर्शन ट्रॅफिक व्यवस्थापनाला पारदर्शकता अपेक्षेसह एक दस्तऐवजीकरण सराव म्हणून मानते, विशेषतः जिथे गर्दीच्या वेळी लॅटन्सी-संवेदनशील सेवांना संरक्षणाची आवश्यकता असते.
नेटवर्क ट्रॅफिकला प्राधान्य देणे आता का महत्त्वाचे आहे
एखाद्या कार्यक्रमाच्या ठिकाणी, बिघाड होण्याचे स्वरूप परिचित असते. अतिथी WiFi वापर वाढतो, व्हिडिओ अपलोड कर्मचारी यंत्रणांशी स्पर्धा करतात आणि बॅकग्राउंड अपडेट्स पॉइंट-ऑफ-सेल ट्रॅफिकसारखाच ॲक्सेस पाथ वापरतात. पेमेंट टर्मिनल कदाचित कमी प्रमाणात डेटाची देवाणघेवाण करू शकते, परंतु चुकीच्या वेळी झालेला उशीर व्यवहारावर परिणाम करतो. व्हॉईस किंवा व्हिडिओ कॉलचे स्वरूप याच्या विरुद्ध असते, त्याला मोठ्या प्रमाणावरील ट्रान्सफरच्या मागे थांबण्याऐवजी पॅकेट्स सातत्याने पोहोचणे आवश्यक असते.
QoS क्षमता निर्माण करत नाही. जेव्हा मागणी उपलब्ध क्षमतेपेक्षा जास्त होते, तेव्हा ती क्षमता कशी वापरायची हे ते ठरवते. हा फरक महत्त्वाचा आहे कारण प्राधान्यीकरण एखाद्या कॉल, ट्रान्झॅक्शन किंवा क्लिनिकल वर्कफ्लोचे संरक्षण करू शकते, परंतु ते बिघडलेले सर्किट दुरुस्त करू शकत नाही, अपस्ट्रीम ISP मधील अडथळे दूर करू शकत नाही किंवा खराब वायरलेस कव्हरेजची भरपाई करू शकत नाही.
समान वागणुकीचे व्यावसायिक परिणाम
योग्य धोरणाशिवाय, पाहुण्यांच्या ट्रॅफिकला बऱ्याचदा कर्मचारी ॲप्लिकेशन्स, IoT टेलिमेट्री आणि ऑपरेशनल सिस्टम्ससारखीच शेड्युलिंगची संधी मिळते. हॉस्पिटॅलिटी, रिटेल आणि हेल्थकेअरमध्ये, यामुळे नेटवर्कचे वर्तन आणि व्यावसायिक जोखीम यामध्ये तफावत निर्माण होते. बॅकग्राउंड सिंक्रोनाइझेशन जॉबमध्ये थोडा उशीर झालेला सामान्यतः चालू शकतो. परंतु व्हॉईस क्यू, पेमेंट फ्लो किंवा तातडीच्या कोलाबोरेशन सेशनमध्ये असाच उशीर झालेला चालत नाही.
Ofcom चे UK नेट-न्यूट्रॅलिटी मार्गदर्शन हे मान्य करते की जेव्हा श्रेणींना सातत्याने वागणूक दिली जाते आणि तांत्रिक गरजा आणि गर्दीच्या जोखमीच्या प्रमाणात दृष्टिकोन असतो तेव्हा ट्रॅफिक व्यवस्थापन इतरांपेक्षा काही श्रेणींना प्राधान्य देऊ शकते. मार्गदर्शन हे देखील स्पष्ट करते की कशा प्रकारे प्रमुख निश्चित आणि मोबाइल ISPs नी २०१२ पासून एका सामान्य की फॅक्ट्स इंडिकेटर टेम्पलेटद्वारे ट्रॅफिक-व्यवस्थापन पद्धती उघड केल्या आहेत, ज्यामुळे ग्राहकांसाठी प्राधान्य अधिक पारदर्शक बनले आहे. Ofcom चे ट्रॅफिक-व्यवस्थापन मार्गदर्शन ऑपरेशनल मुद्दा स्पष्ट करते: प्राधान्य देण्याला एक बचावात्मक कारण आणि समजण्यायोग्य वर्णन आवश्यक आहे.
व्यावहारिक नियम: ॲप्लिकेशनच्या आउटकमचे संरक्षण करा, ते वापरत असलेल्या डिव्हाइसचे नाही.
डिव्हाइस-आधारित नियम होम नेटवर्कमध्ये काम करू शकतो, परंतु एंटरप्राइझ वातावरण डायनॅमिक असते. कर्मचारी ऍक्सेस पॉईंट्स दरम्यान फिरतात, कंत्राटदार मॅनेज्ड किंवा अनमॅनेज्ड हार्डवेअर वापरतात आणि एकच लॅपटॉप एकाच वेळी व्हॉईस, ब्राउझिंग आणि मोठ्या प्रमाणावर डेटा ट्रान्सफर चालवू शकतो. MAC ऍड्रेसच्या स्टॅटिक सूचीपेक्षा ओळख, ऍप्लिकेशन आणि डिव्हाइसच्या भूमिकेवर आधारित वर्गीकरण अधिक टिकाऊ असते.
उत्तम प्राधान्यीकरण काय करू शकते आणि काय करू शकत नाही
एक चांगली डिझाईन संघर्षाच्या वेळी महत्त्वपूर्ण ट्रॅफिकला चांगली संधी देते, महत्त्वाच्या क्लासेससाठी क्षमता राखीव ठेवते आणि बॅकग्राउंड फ्लोमुळे क्यू (queues) भरण्यास प्रतिबंध करते. हे घटनांचे निदान करणे देखील सोपे करू शकते कारण पॉलिसी स्पष्ट करते की पॅकेट का मार्क केले गेले, क्यूमध्ये ठेवले गेले किंवा मर्यादित केले गेले.
हे प्रत्येक ॲप्लिकेशनमध्ये समान रीतीने सुधारणा करणार नाही आणि यामुळे कमी-प्राधान्य असलेले ट्रॅफिक जाणूनबुजून कमी केले जाऊ शकते. तो तडजोड पर्याय केवळ तेव्हाच स्वीकार्य असतो जेव्हा पॉलिसीमध्ये काय सुरक्षित केले जात आहे, निर्णयाचा मालक कोण आहे आणि हा नियम कधी लागू होतो हे स्पष्ट केलेले असते. IT आणि नेटवर्क टीम्ससाठी Purple WiFi सोल्यूशन या गव्हर्नन्स समस्येसाठी सुसंगत आहे कारण ओळख आणि डिव्हाइस संदर्भ नेटवर्क टीम्सना अतिथी, कर्मचारी आणि ऑपरेशनल ट्रॅफिक इच्छित पॉलिसी डोमेनमध्ये ठेवण्यास मदत करू शकतात.
नियोजनाच्या आवश्यकता आणि ट्रॅफिक क्लासेस परिभाषित करणे
इन्व्हेंटरीपासून सुरुवात करा, मार्किंग स्कीमपासून नाही. ॲप्लिकेशन्स, युजर्स, डिवाइसेस, साइट्स आणि लिंक्सची यादी तयार करा, त्यानंतर नेटवर्क व्यस्त असताना सर्वात आधी काय खंडित होते ते नोंदवा. महत्त्वाचे वाटणाऱ्या प्रत्येक गोष्टीला सर्वात जास्त प्राधान्य देऊन सुरुवात करू नका. एखादा क्लास तेव्हाच उपयुक्त ठरतो जेव्हा तो आवश्यक ट्रॅफिक सुरक्षित ठेवण्यासाठी पुरेसा दुर्मिळ राहतो.
व्यावसायिक आउटकमवरून पॉलिसी तयार करा
प्रत्येक ट्रॅफिक स्त्रोताला सेवा अपेक्षेसह मॅप करा. व्हॉईस आणि इंटरएक्टिव्ह व्हिडिओसाठी सहसा कमी विलंब, कमी जिटर आणि नियंत्रित लॉस आवश्यक असतो. पेमेंट, क्लिनिकल आणि ऑपरेशनल ऍप्लिकेशन्सना प्रेडिक्टेबल डिलिव्हरी आणि खात्रीशीर बँडविड्थची आवश्यकता असू शकते. सॉफ्टवेअर अपडेट्स, बॅकअप, गेस्ट ब्राउझिंग आणि मोठे मीडिया ट्रान्सफर सामान्यतः बेस्ट-इफर्ट किंवा स्कॅव्हेंजर ट्रीटमेंट वापरू शकतात.
एक लहान वर्गीकरण संच वापरा जो ऑपरेटर दबावाखाली समजू शकतील:
- Real-time: व्हॉईस, परस्परसंवादी व्हिडिओ आणि इतर प्रवाह जिथे विलंबातील बदलामुळे उपयुक्ततेवर परिणाम होतो.
- Critical business: पेमेंट, क्लिनिकल, ऑपरेशनल किंवा ट्रान्झॅक्शन ट्रॅफिक ज्याला संघर्षादरम्यान विश्वसनीय किमान मर्यादेची आवश्यकता असते.
- Default: सामान्य कर्मचारी, अतिथी आणि ॲप्लिकेशन ट्रॅफिक ज्याला कोणतेही अपवादात्मक ट्रिटमेंट दिले जात नाही.
- Scavenger: मोठ्या प्रमाणावर ट्रान्सफर, अपडेट्स, बॅकअप आणि गैर-तातडीचे सिंक्रोनाइझेशन.
हे लेबल्स सार्वत्रिक मानके नाहीत. प्रत्येक लेबलमागील निर्णय हा महत्त्वाचा भाग असतो, ज्यामध्ये मालक, मोजण्यायोग्य सेवा अपेक्षा आणि त्या सक्रिय करणाऱ्या परिस्थितींचा समावेश होतो.
कडक प्राधान्य काळजीपूर्वक निवडा
उशीर सहन न होणाऱ्या ट्रॅफिकसाठी स्ट्रिक्ट-प्रायोरिटी क्यू योग्य आहे, परंतु ते मर्यादित असणे आवश्यक आहे. जर खूप जास्त ॲप्लिकेशन्स त्या क्यूमध्ये आले, तर शेड्युलरकडे इतर ट्रॅफिक हाताळण्यासाठी खूप कमी वाव उरतो आणि त्यामुळे इतरत्र स्टार्व्हेशन (डेटा न मिळणे) होऊ शकते. महत्त्वाच्या व्यावसायिक ट्रॅफिकसाठी अशुअर्ड फॉरवर्डिंग किंवा क्लास-बेस्ड वेटेड शेड्युलिंग बऱ्याचदा सुरक्षित असते कारण ते प्रत्येक पॅकेटला थेट समोर न पाठवता किमान हिश्श्याचे संरक्षण करते.
ओळख (आयडेंटिटी) ही इन्व्हेंटरीचा भाग असावी. कर्मचारी व्हॉईस क्लायंट, पाहुण्यांचा व्हिडिओ स्ट्रीम आणि बिल्डिंग-मॅनेजमेंट सेन्सर कदाचित एकच ॲक्सेस पॉईंट वापरत असतील पण त्यांच्या धोरणाच्या गरजा वेगवेगळ्या असू शकतात. Purple identity-based networking सारखे प्लॅटफॉर्म वर्गीकरणासाठी युझर आणि डिव्हाइसचे संदर्भ प्रदान करू शकतात, ज्यामुळे अतिरिक्त SSIDs किंवा नाजूक डिव्हाइस लिस्ट्सवरील अवलंबित्व कमी होते.
लागू करण्यापूर्वी निकषांचे दस्तऐवजीकरण करा
UK च्या पारदर्शकता अपेक्षांमुळे दस्तऐवजीकरण (documentation) हा तांत्रिक डिझाइनचा एक भाग बनतो. Ofcom साहित्य हे स्पष्ट करते की सर्व ॲप्लिकेशन्सना समान QoS मिळते की नाही, ट्रॅफिक-व्यवस्थापन निकष उघड करणे, प्रभावित ॲप्लिकेशन्स आणि पीक पिरियड्स ओळखणे, आणि वाजवी-वापर (fair-use) नियमांचे उल्लंघन झाल्यास त्याचे परिणाम सांगणे हे ISP साठी किती आवश्यक आहे. Ofcom चे नेट-न्यूट्रॅलिटी दस्तऐवज संबंधित अनुपालन संदर्भ प्रदान करते.
किमान खालील गोष्टींची नोंद करा:
- ट्रॅफिक व्याख्या: ॲप्लिकेशन, प्रोटोकॉल, डेस्टिनेशन, वापरकर्ता गट किंवा डिव्हाइसची भूमिका.
- ट्रिटमेंट: मार्किंग, क्यू, किमान रिझर्व्हेशन, शेपिंग आणि पोलिसिंग कृती.
- व्याप्ती: साइट्स, SSIDs, लिंक्स, टेनंट्स आणि व्यवसायाच्या वेळा.
- कारण: पॉलिसीद्वारे संरक्षित केलेले सेवा परिणाम.
- मालक आणि पुनरावलोकन ट्रिगर: बदलांना कोण मान्यता देते आणि कोणती पुराव्यामुळे पुनरावृत्ती होते.
NHS England चे HSCN गुणवत्ता-सेवा मॉडेल दर्शवते की प्रत्यक्ष धोरण व्यवहारात कसे दिसते. त्याचे प्रकाशित प्रोफाइल कॉन्ट्रॅक्ट केलेल्या बँडविड्थपैकी AF1 ५%, AF2 ७.५%, AF3 ३०%, AF4 ७.५%, DE ३९%, EF १०%, आणि व्यवस्थापन १% आरक्षित करते, जे एकूण १००% होते. HSCN QoS विहंगावलोकन हा एक उपयुक्त UK बेंचमार्क आहे कारण तो अनौपचारिक "उच्च प्राधान्य" लेबलांवर अवलंबून राहण्याऐवज वर्गाद्वारे किमान वचनबद्धता परिभाषित करतो.
Marking, Queuing, Shaping आणि Policing स्पष्ट केले
हे मेकॅनिझम्स वेगवेगळ्या समस्या सोडवतात. Marking वर्ग ओळखते, queuing ट्रान्समिशनचा क्रम नियंत्रित करते, shaping फ्लो सुरळीत करण्यासाठी पॅकेट्सना उशीर करते, आणि policing ट्रॅफिक ड्रॉप किंवा रिमार्क करून मर्यादा लागू करते. इतरांशिवाय फक्त एकच तैनात केल्यास बऱ्याचदा असे धोरण तयार होते जे डॅशबोर्डवर योग्य दिसते परंतु गर्दीच्या ठिकाणी अपयशी ठरते.
एजवर मार्क करा, निवडकपणे विश्वास ठेवा
IP ट्रॅफिकवरील DSCP आणि इथरनेट फ्रेम्सवरील CoS क्लासची माहिती वाहून नेतात. आपण जिथे ट्रॅफिक विश्वसनीयरित्या ओळखू शकता, सहसा नियंत्रित ऍक्सेस एजवर, तिथे ट्रॅफिक मार्क करा आणि स्पष्टपणे ट्रस्ट बाउंड्रीज परिभाषित करा. पडताळणीनंतर मॅनेज्ड व्हॉईस डिव्हाइसवर विश्वास ठेवला जाऊ शकतो. अनुकूल मूल्य सेट करून गेस्ट एंडपॉईंटला स्वतःला क्रिटिकल घोषित करण्याची परवानगी दिली जाऊ नये.
जेव्हा ट्रॅफिक प्रशासकीय सीमा ओलांडते तेव्हा स्विचेस आणि राउटर मार्किंग्ज काढून टाकू शकतात किंवा पुन्हा लिहू शकतात. म्हणून, तुमच्या डिझाइनला रिमार्किंग पॉलिसीची आवश्यकता असते, केवळ एखादे मूल्य सुरुवातीपासून शेवटपर्यंत टिकून राहील अशा गृहीतकाची नाही.
संघर्षासाठी रांग (Queue for contention)
इंटरफेस पूर्ण भरलेला असताना कोणता पॅकेट कधी पाठवायचा हे शेड्यूलिंग ठरवते. कमी लेटन्सी किंवा कडक प्राधान्याची वागणूक मर्यादित रिअल - टाइम ट्रॅफिकसाठी योग्य ठरते. क्लास - आधारित वेटेड शेड्यूलिंग हे प्रमाणबद्ध ॲक्सेस आणि किमान हमी आवश्यक असलेल्या बिझनेस क्लासेससाठी योग्य आहे. बेस्ट - एफ्फर्ट आणि स्कॅव्हेंजर क्यूज विलंब सहन करू शकणारे ट्रॅफिक सामावून घेतात.
HSCN मॉडेल हे स्पष्ट करते की किमान रिझर्व्हेशन का महत्त्वाचे आहे. केवळ प्रायोरिटी मार्किंग केल्याने संघर्षादरम्यान सेवेची हमी मिळत नाही. CloudSwitched द्वारे वर्णन केलेली व्यावहारिक QoS पद्धत प्रथम वर्गीकरणावर भर देते, त्यानंतर टक्केवारीवर आधारित पोलिसिंग किंवा शेपिंगवर भर देते जेणेकरून क्लासेस स्पर्धा करत असताना महत्त्वपूर्ण प्रवाहांना राउटिंगच्या संधी मिळतील.
अडथळ्यापूर्वी shape करा, सीमेवर police करा
Shaping हे पॅकेट्स बफर करते आणि त्यांना नियंत्रित गतीने रिलीज करते. जेव्हा प्रत्यक्ष प्रदाता गती माहित असते आणि स्थानिक डिव्हाइसने अपस्ट्रीम रांग अनियंत्रित अडथळा बनण्यापासून रोखली पाहिजे, तेव्हा हे संस्थेच्या WAN एजवर चांगल्या प्रकारे कार्य करते.
पॉलिसिंग अधिक अचानक असते. हे एका मर्यादेच्या विरूद्ध ट्रॅफिक मोजते आणि त्यापेक्षा जास्त जाणारे पॅकेट्स ड्रॉप किंवा रिमार्क करू शकते. जेथे कठोर करार, क्लास बाउंड्री किंवा भाडेकरू मर्यादा महत्त्वाची असते तिथे याचा वापर करा. चाचणी केल्याशिवाय बर्स्टी इंटरएक्टिव्ह ट्रॅफिकसाठी आक्रमक पॉलिसिंग वापरू नका, कारण ड्रॉप्समुळे त्याच ऍप्लिकेशनचे नुकसान होऊ शकते ज्याचे रक्षण करण्यासाठी ही पॉलिसी तयार केली आहे.
| ट्रॅफिक क्लास | शिफारस केलेली यंत्रणा | ती कधी वापरावी |
|---|---|---|
| Real-time | मर्यादेसह कडक प्राधान्य, तसेच एज मार्किंग | व्हॉईस आणि परस्परसंवादी व्हिडिओला कमी विलंबाची आवश्यकता असते, परंतु रांग मर्यादित राहिली पाहिजे |
| महत्त्वाचा व्यवसाय | किमान आरक्षणासह भारित रांग | व्यवहार आणि ऑपरेशनल ॲप्लिकेशन्सना संघर्षादरम्यान अंदाज लावण्यायोग्य प्रवेशाची आवश्यकता असते |
| डिफॉल्ट | वाजवी किंवा भारित सर्वोत्तम-प्रयत्न रांग | सामान्य कर्मचारी, अतिथी आणि सामान्य ॲप्लिकेशन ट्रॅफिक |
| स्कॅव्हेंजर | कमी वजनाची रांग, शेपिंग किंवा कमी मार्किंग | बॅकअप, अपडेट्स आणि मोठ्या प्रमाणावर ट्रान्सफर अनावश्यकपणे ब्लॉक न होता मागे राहिले पाहिजेत |
मुख्य उत्पादन अपयश म्हणजे अति-प्राधान्य देणे होय. UK Ofcom सबमिशन उच्च-प्राधान्य असलेल्या पॅकेट्सची डिलिव्हरी होण्याची अधिक शक्यता असल्याचे वर्णन करते तर कमी-प्राधान्य असलेल्या पॅकेट्सना गर्दीच्या वेळी उशीर होऊ शकतो किंवा ते ड्रॉप केले जाऊ शकतात, आणि मोबाइल डाउनलोड गती व्यस्त वेळेत ४४% ने मंदावल्याचा अहवाल देते. Three UK चे Ofcom कडील सबमिशन व्यावहारिक प्रतिसादाला समर्थन देते: गर्दीच्या मर्यादा मोजा, रिअल-टाइम ट्रॅफिकचे संरक्षण करा आणि पार्श्वभूमी प्रवाह सर्वोत्तम-प्रयत्न ठेवा.
राउटर्स, स्विचेस आणि वायरलेसवर धोरणे लागू करणे
अंमलबजावणी ट्रॅफिकच्या मार्गाचे अनुसरण करणारी असावी. जिथे अडथळा आहे तिथे रेट कंट्रोल ठेवा, विश्वसनीय विभागांमध्ये क्लास माहिती जतन करा आणि वायर्ड क्लासेसना ओव्हर-द-एअर पॅकेट्स ट्रान्समिट करणाऱ्या वायरलेस रांगांमध्ये मॅप करा.
WAN एजपासून सुरुवात करा
इंटरनेट राउटर किंवा SD-WAN अप्लायन्सवर, मर्यादित इग्रेस इंटरफेसच्या आधी ट्रॅफिकचे वर्गीकरण करा. जेव्हा प्रोव्हाइडरची क्यू (queue) विलंब निर्माण करत असेल, तेव्हा प्रोव्हाइडरच्या वापरण्यायोग्य दरापेक्षा किंचित कमी दरावर शेपिंग लागू करा. जेथे कठोर मर्यादा आवश्यक आहे अशा ठिकाणी गेस्ट किंवा भाडेकरू (tenant) वर्गांवर नियंत्रण ठेवा आणि व्यवस्थापन वर्ग राखून ठेवा जेणेकरून सॅच्युरेशन दरम्यान देखील प्रशासक साइटवर पोहोचू शकतील.
साइट-टू-साइट ट्रॅफिकसाठी, ओव्हरले आणि अंडरलेवर समान क्लास मॉडेल लागू करा. LAN वरील व्हॉईसचे रक्षण करणारी परंतु सर्व एनक्रिप्टेड टनेल्स एका अनमॅनेज्ड क्यूद्वारे पाठवणारी पॉलिसी एंड-टू-एंड समस्येचे निराकरण करत नाही. SD-WAN प्लॅटफॉर्म एनक्रिप्शनपूर्वी वर्गीकरण करू शकतो का, टनेलमध्ये क्लासची माहिती वाहून नेऊ शकतो का आणि प्रति मार्ग ट्रॅफिकचे शेड्यूलिंग करू शकतो का ते तपासा.
स्विचची ट्रस्ट बाउंड्री परिभाषित करा
ऍक्सेस स्विचेसने केवळ तुम्ही विश्वास ठेवता अशा उपकरणांमधून आणि पोर्ट्समधूनच मार्किंग्स स्वीकारले पाहिजेत. व्हॉइस हँडसेट किंवा नियंत्रित ऍक्सेस पॉईंटला मंजूर मार्किंग कायम ठेवण्याची परवानगी दिली जाऊ शकते. गेस्ट समोरील पोर्ट्स, व्यवस्थापित नसलेले एंडपॉइंट्स आणि सामान्य वापरकर्ता पोर्ट्स इनग्रेसवर योग्य क्लासमध्ये रीमार्क केले जावेत.
कॅम्पस अपलिंक्सवर, मान्य केलेल्या क्लास मॉडेलशी जुळणाऱ्या क्यूज कॉन्फिगर करा. प्रत्येक स्विचवर स्वतंत्र व्याख्या तयार करणे टाळा. मिश्रित व्हेंडर व्यवस्था अनेकदा अयशस्वी ठरते कारण एक प्लॅटफॉर्म क्यूला "व्हॉइस" म्हणतो, दुसरा त्यास वेगवेगळ्या DSCP व्हॅल्यूवर मॅप करतो आणि वायरलेस कंट्रोलर पूर्णपणे वेगळी ट्रीटमेंट लागू करतो.
वायरलेस पॉलिसी WMM मध्ये मॅप करा
वायरलेस कंट्रोलर्स ट्रॅफिक क्लासेसचे WiFi मल्टीमीडिया क्यूमध्ये रूपांतर करतात. व्हॉइस आणि व्हिडिओला संबंधित वायरलेस ट्रिटमेंटची आवश्यकता असते, परंतु एअरटाइम हे सामायिक माध्यमच राहते. कव्हरेज, चॅनेलचा वापर किंवा क्लायंटचे वर्तन खराब असल्यास उच्च-प्राधान्य असलेल्या वायरलेस क्यूला तरीही त्रास सहन करावा लागू शकतो.
ट्रॅफिक कंट्रोलरपर्यंत पोहोचण्यापूर्वी त्याचे वर्गीकरण करण्यासाठी ओळख आणि डिव्हाइसची भूमिका वापरा. कर्मचारी, पाहुणे आणि IoT सिस्टम्स एकाच ॲक्सेस लेयरचा वापर करू शकतात आणि तरीही त्यांना वेगळी पॉलिसी ट्रिटमेंट मिळू शकते, बशर्ते ओळखीचा स्त्रोत विश्वसनीय असावा. Microsoft Entra ID, Google Workspace किंवा Okta सह डिरेक्टरी इंटिग्रेशन कर्मचाऱ्यांच्या संदर्भाला सपोर्ट करू शकते, तर आधुनिक ओळख प्रवाह पूर्ण करू न शकणाऱ्या जुन्या डिव्हाइसेससाठी iPSK उपयुक्त ठरते.
क्लाउड प्लॅटफॉर्म सुसंगत ठेवा
Meraki, Aruba, Ruckus, Mist आणि UniFi वेगवेगळ्या नावांचे आणि नियंत्रणाचे स्तर दर्शवतात, म्हणून आधी तुमच्या पॉलिसीचे वेंडर-न्यूट्रल आवश्यकतांमध्ये रूपांतर करा:
- वर्गीकरण करा: ओळख, ॲप्लिकेशन, डिव्हाइस भूमिका किंवा सबनेट जुळवा.
- मार्क करा: परिभाषित ट्रस्ट बाउंड्रीवर DSCP सेट करा किंवा रिमार्क करा.
- क्यूमध्ये ठेवा: क्लासला वायर्ड किंवा वायरलेस शेड्यूलरशी मॅप करा.
- नियंत्रण करा: प्रत्यक्ष मर्यादित इंटरफेसवर शेपिंग किंवा पोलिसिंग करा.
- नोंद करा: पॉलिसीचे मालक, व्याप्ती, कारण आणि बदलांचा इतिहास संग्रहित करा.
क्लाउड - व्यवस्थापित प्लॅटफॉर्म्स रोलआउट सोपे करतात, परंतु यामुळे प्रेसिडेन्स समजून घेण्याची गरज कमी होत नाही. एखादा ग्लोबल ॲप्लिकेशन नियम SSID पॉलिसी ओव्हरराइड करू शकतो, तर एखादा स्विच WAN अप्लायन्सच्या आधी मार्किंग्स रीराइट करू शकतो. एका मार्गाची चाचणी घ्या, प्रत्येक हॉपवर क्लास तपासा आणि त्यानंतरच कॉन्फिगरेशनची प्रतिकृती तयार करा.
देखरेख पडताळणी आणि निरंतर ऑप्टिमायझेशन
कॉन्फिगरेशन यशस्वीरित्या लागू झाले आहे म्हणजे QoS पॉलिसी कार्य करत आहे असे नाही. हे तेव्हा कार्य करते जेव्हा इच्छित ट्रॅफिकचे योग्यरित्या वर्गीकरण केले जाते, संपूर्ण मार्गावर अपेक्षित ट्रिटमेंट राखली जाते आणि स्पर्धात्मक ट्रॅफिक असताना देखील ती त्याच्या सेवा आवश्यकता पूर्ण करते.
पॅकेटच्या प्रवासाची पडताळणी करा
चार स्तरांमध्ये चाचणी करा:
- वर्गीकरण: ॲप्लिकेशन, ओळख आणि डिव्हाइस इच्छित नियमाशी जुळत असल्याची खात्री करा.
- मार्किंग: राउटर, स्विचेस, ॲक्सेस पॉइंट्स आणि टनेल्सवर इनग्रेस आणि इग्रेस दरम्यान DSCP किंवा CoS चे निरीक्षण करा.
- शेड्युलिंग: क्यू (queue) वापर, ड्रॉप्स, टेल ड्रॉप्स, शेपिंग विलंब आणि पोलिसिंग क्रियांवर पुनरावलोकन करा.
- अनुभव: सामान्य आणि गर्दीच्या कालावधीत लेटन्सी, जिटर, लॉस, कॉल गुणवत्ता आणि ट्रान्झॅक्शन रिस्पॉन्सिव्हनेसची तुलना करा.
इंटरफेस काउंटर्स तुम्हाला क्यू सक्रिय आहे की नाही हे सांगतात. ते युझरचा अनुभव स्वीकारार्ह आहे की नाही हे सांगत नाहीत, म्हणून त्यांना ॲप्लिकेशन टेलिमेट्री आणि नियंत्रित चाचण्यांसह जोडा. वायरलेस वातावरणासाठी, latency and jitter test from Purple ही कंट्रोलर आणि स्विच डेटासह प्रत्यक्ष अनुभवाची तपासणी करण्यास मदत करू शकते.
पॉलिसी बदलण्यापूर्वी बेसलाइन करा
डिव्हाइस उपयोजनापूर्वी सामान्य वर्तनाची नोंद घ्या. कोंडी कुठे होते, कोणत्या रांगा भरतात, कोणत्या ॲप्लिकेशन्सना विलंब होतो आणि समस्या कधी उद्भवते याकडे लक्ष द्या. अंमलबजावणीनंतर, तुलना करण्यायोग्य परिस्थितींमध्ये याच गोष्टींचे पुन्हा निरीक्षण करा.
प्रत्येक पॅकेट ड्रॉपवर अलर्ट देण्याऐवजी गर्दीच्या वेळेनुसार अलर्ट सेट करा. स्कॅव्हेंजर क्यूमध्ये काही प्रमाणात ड्रॉप्सची अपेक्षा केली जाऊ शकते. रिअल-टाइम क्यूमध्ये सतत ड्रॉप्स होणे, शेपिंग विलंब वाढणे किंवा अनपेक्षित सीमेवर वारंवार रीमार्किंग होणे या गोष्टींची चौकशी करणे आवश्यक आहे.
काउंटर्सशिवाय असलेली प्रायोरिटी पॉलिसी ही कामगिरीबद्दलचे केवळ एक मत आहे, कामगिरीचा पुरावा नाही.
जेव्हा ॲप्लिकेशन्सचे मिश्रण बदलते, साइट्स नवीन सेवा जोडतात किंवा बिझनेसचे मालक त्यांचे SLAs बदलतात तेव्हा रिझर्व्हेशन्सचे पुनरावलोकन करा. NHS England चे HSCN प्रोफाइल हे एक उपयुक्त स्मरणपत्र आहे की स्पष्ट क्लास वाटपामुळे तडजोड स्पष्टपणे दिसून येते. ऑपरेटर केवळ ऐकीव गोष्टींवरून वाद घालण्याऐवजी एखाद्या क्लासला पुरेसे संरक्षण मिळाले आहे की नाही यावर चर्चा करू शकतात.
क्लासिक QoS आणि स्लाइसिंग मधील पर्याय निवडा
जेव्हा आपण ॲक्सेस इंटरफेस नियंत्रित करता आणि कर्मचारी, अतिथी आणि ऑपरेशनल ट्रॅफिकमधील स्पर्धेचा निवाडा करण्याची आवश्यकता असते तेव्हा क्लासिक QoS रांगा हा व्यावहारिक पर्याय ठरतात. त्या पॅकेट्सचे वर्गीकरण करतात आणि उपलब्ध मार्गामध्ये त्यांचे नियोजन करतात.
स्लाइसिंग-आधारित प्राधान्यीकरण हे एक वेगळे सर्व्हिस मॉडेल आहे. EE ने 2026 मध्ये ग्राहक 5G+ फास्ट लेन सुरू केली, ज्यामध्ये स्टेडियम, शॉपिंग सेंटर्स आणि रेल्वे स्टेशन्स यांसारख्या गर्दीच्या ठिकाणांसाठी समर्पित 5G स्टँडअलोन नेटवर्क संसाधनांचे वर्णन केले आहे, तर त्याचे नेटवर्क बूस्ट वैशिष्ट्य गर्दीच्या सेल टॉवर्सवर पारंपारिक QoS क्युइंग वापरते. EE च्या 5G नेटवर्क स्लाइसिंग योजनांवरील ISPreview अहवाल हा फरक स्पष्ट करतो.
एखाद्या ठिकाणासाठी, कर्मचारी सिस्टीम आणि स्थानिक WLAN ट्रॅफिकसाठी क्लासिक QoS पुरेसे असू शकते. स्लाइसिंग-आधारित उत्पादन अशा ठिकाणी संबंधित ठरू शकते जेथे एखाद्या इव्हेंट दरम्यान मोबाईल ऍक्सेस सेवेलाच वेगळ्या उपचाराची आवश्यकता असते. त्यांना स्वतंत्र नियंत्रण स्तर (control planes) समजा आणि ही हमी कोण प्रदान करते याचे दस्तऐवजीकरण करा.
सामान्य प्राधान्यीकरणाच्या समस्यांचे निवारण करणे
बहुतेक अयशस्वी QoS डिप्लॉयमेंट्स हे सीमेवर किंवा वर्गीकरण निर्णयामध्ये खंडित होतात. निरीक्षण केलेले वर्तन पॉलिसीपेक्षा वेगळे असणारा पहिला हॉप शोधून सुरुवात करा, नंतर अधिक नियम जोडण्याऐवजी त्या लेयरचे निराकरण करा.
जर प्रायोरिटी क्यू ट्रॅफिकचे संरक्षण करत नसेल
ऍप्लिकेशन नियमाशी जुळत आहे का, पॅकेट अपेक्षेनुसार मार्क केले आहे का आणि क्यूमध्ये गर्दी आहे का ते तपासा. कधीही न भरणारी प्रायोरिटी क्यू फार काही सिद्ध करत नाही. नियंत्रित संघर्ष निर्माण करा, नंतर संरक्षित ऍप्लिकेशन सुरू असताना क्यू काउंटर्सची तपासणी करा.
रिअल-टाइम ट्रॅफिकला विलंब होत असल्यास, अत्यधिक प्रायोरिटी सदस्यत्व, अमर्यादित क्यू किंवा समतुल्य ट्रिटमेंट नसलेला डाउनस्ट्रीम इंटरफेस शोधा. प्रायोरिटी वाढवण्यापूर्वी व्यापक ऍप्लिकेशन सामने काढून टाका. अधिक प्रायोरिटी क्लासेस सामान्यतः कमी अर्थपूर्ण प्रायोरिटी तयार करतात.
जर मार्किंग्ज अदृश्य झाले
ट्रस्ट बाउंड्रीवर पॅकेट ट्रेस करा. ऍक्सेस स्विचेस अविश्वासू एंडपॉईंट्स रिमार्क करू शकतात, वायरलेस नियंत्रक मूल्यांचे WMM ट्रीटमेंटमध्ये भाषांतर करू शकतात आणि एनक्रिप्टेड ओव्हरले अंडरले शेड्युलरपासून आतील मार्किंग लपवू शकतात. मार्किंग कुठे अधिकृत आहे ते ठरवा, नंतर ते जतन करण्यासाठी किंवा जाणीवपूर्वक त्याचे भाषांतर करण्यासाठी प्रत्येक पुढील हॉप कॉन्फिगर करा.
अपस्ट्रीम ISP हँडलिंग ही दुसरी शक्यता आहे. तुमचा स्थानिक राउटर एग्रेस ट्रॅफिक शेड्यूल करू शकतो, परंतु तो बाह्य प्रदात्याच्या अंतर्गत क्यू (queues) नियंत्रित करू शकत नाही. प्रदाता गर्दीचे व्यवस्थापन वेगळ्या पद्धतीने करत असल्यास, प्रकरणाचा पाठपुरावा करण्यापूर्वी टाइमस्टॅम्प, क्यू पुरावा आणि ऍप्लिकेशनची लक्षणे गोळा करा.
जर वायरलेस कामगिरी सुमार राहिली तर
QoS ला रेडिओ समस्यांपासून वेगळे करा. उच्च रीट्रान्समिशन, कमकुवत कव्हरेज, चॅनेल कॉन्टेंशन आणि ओव्हरसबस्क्राइब्ड ॲक्सेस पॉइंट्स योग्य WMM मॅपिंगला कमकुवत करू शकतात. क्लायंटच्या ठिकाणी चाचणी घ्या, वायर्ड आणि वायरलेस मार्गांची तुलना करा आणि व्हॉइस व व्हिडिओ इच्छित वायरलेस क्यूमध्ये प्रवेश करत आहेत की नाही ते तपासा.
अतिथी, कर्मचारी आणि IoT ओळख अचूक ठेवा. डिव्हाइसेसनी भूमिका बदलल्यास किंवा ऑथेंटिकेशन सामायिक नेटवर्कवर परत गेल्यास, शेड्युलर चुकीची पॉलिसी उत्तम प्रकारे लागू करू शकतो.
पॉलिसीचे समर्थन करता येईल अशी ठेवा
प्रत्येक बदल त्याचे कारण, मालक, व्याप्ती आणि रोलबॅक पद्धतीसह दस्तऐवजीकरण करा. ट्रॅफिक व्यवस्थापन लागू असलेल्या ठिकाणी प्रभावित ॲप्लिकेशन्स आणि पीक पिरियड्सची नोंद ठेवा, Ofcom च्या प्रकाशित मार्गदर्शकतत्त्वांमध्ये वर्णन केलेल्या पारदर्शकता तत्त्वांचे पालन करा. घटना, मुख्य ॲप्लिकेशन बदल आणि SD-WAN किंवा 5G स्लाइसिंग यांसारख्या नवीन ॲक्सेस मॉडेल्सनंतर पॉलिसीचे पुनरावलोकन करा.
प्राधान्य देणे म्हणजे पॅकेट मेकॅनिक्सद्वारे समर्थित असलेले निरंतर पॉलिसी व्यवस्थापन आहे. जेव्हा नियम, ओळख संदर्भ, रांगा आणि मोजमाप सुसंगत असतात, तेव्हा नेटवर्क बँडविड्थ अमर्यादित आहे असा आव न आणता महत्त्वाच्या सेवांचे संरक्षण करते.
Purple युझर आणि डिव्हाइसची ओळख अंमलात आणण्यायोग्य नेटवर्क पॉलिसीसह जोडू शकते, ज्यामुळे टीम्सना मिक्स व्हेन्डर इस्टेटमध्ये कर्मचारी, गेस्ट आणि ऑपरेशनल ट्रॅफिक वेगळे करण्यास मदत होते. ओळख-आधारित WiFi, विश्लेषण आणि नेटवर्क इंटिग्रेशन दस्तऐवजीकरण केलेल्या ट्रॅफिक-प्राधान्य धोरणाला कसे समर्थन देऊ शकतात याचे मूल्यांकन करण्यासाठी Purple ला भेट द्या.
