مدیریت شبکه های خصوصی مجازی بر مبنای پروتکل اینترنت (ip)

[Admin]

مدیریت شبکه های خصوصی مجازی بر مبنای پروتکل اینترنت (IP) ‌‌‌(بخش نخست)


چکیده
این مقاله در ابتدا به تعریف شبکه­های خصوصی مجازی به طور عام و سپس VPNهای مبتنی بر IP می­پردازد و انواع مختلف این شبکه را معرفی می کند. در ادامه نیازمندی­های مدیریتی آن را از دید نواحی کارکردی FCAPS شرح داده می­شود. بخش بعدی این مقاله مدل­های مختلف کیفیت سرویس در این شبکه­ها را ارايه می دهد. سپس نحوه­ي مدیریت IPVPNها برای برآورده ساختن نیازمندی­های کارایی و کیفیت سرویس و در انتها یک روش برای مانیتور کردن نهفته پارامترهای کیفیت سرویس IPVPN ها آورده می­شود. معماری پیشنهادی در این بخش دو مشخصه­ي اصلی دارد، نخست این­که از یک روش in-serveice استفاده می­کند که در آن پارامترهای ترافیک واقعی کاربر به وسیله بسته­های مخصوص مانیتورینگ اندازه گیری می­شوند و دیگر این­که توابع مانیتورینگ، یک بخش مجتمع از عناصر عادی شبکه را تشکیل می­دهند.
­
1. مقدمه
امروزه شبکه­های خصوصی مجازی (Virtual Private Network)ها که از طریق تسهیلات backbone های IP اجرا می شوند، بسیار مورد اقبال قرار گرفته­اند. VPN های مبتنی بر IP به عنوان یکی از نوید بخش­ترین سرویس­ها برای تهیه­کنندگان شبکه نمایان شده­اند. گسترش دامنه­دار IPVPN ها به دلیل نبود پیاده­سازی­های عملی و سردرگمی در بین تعداد بالای راه­حل­هایی که به وسیله ترکیب IPVPN تشریح می­شوند، به تعویق افتاده است. به علاوه پرسش­ها و تردیدهایی در باره­ي امنیت (security)، کیفیت سرویس یا قابلیت گسترش پیاده­سازی VPN مبتنی بر IP وجود دارند.

2. IPVPN چیست؟
سازمان­ها از شبکه­های خصوصی برای ارتباط با سایت­های دور و نیز ارتباط با سازمان­های دیگر استفاده می­کنند. با گسترش اینترنت، بسیاری از سازمان­ها به سمت شبکه­های خصوصی مجازی حرکت کرده­اند که بسیاری از مزایای شبکه­های خصوصی را با هزینه­ای کمتر ارايه می­دهند. اگرچه VPNها دارای خطرهایی را هم دربردارند، با معماری و پیاده­سازی درست می­توانند برای یک سازمان به حد کافی مفید باشند.
مفهوم شبکه­ي خصوصی مجازی یک مفهوم جدید نیست. فناوری­هایی مانند ISDN، FrameRelay یا ATM در دهه­های گذشته به عنوان مبنایی برای پیاده­سازی این مفهوم استفاده شده­اند. بدون توجه به هر قالب یا فناوری که پشت سر آن باشد، یک VPN سرویسی را تهیه می­کند که از لحاظ عملکرد معادل یک شبکه­ي خصوصی با منابع عمومی است.
VPN می­تواند به عنوان سرویسی تعریف شود که اتصال دهندگی مشتری در میان چندین سایت روی یک زیربنای تسهیم شده با همان سیاست­های دست­رسی یا امنیت یک شبکه­ي خصوصی گسترش می­یابد.
یک VPN باید در کارایی، اطمینان، امنیت، مدیریت و کیفیت سرویس قابل مقایسه با یک شبکه­ي خصوصی باشد. مشتری­های سرویس­های VPN تسهیلات و تجهیزات تسهیم شده­ای را که به وسیله یک اپراتور شبکه­ي عمومی، مدیریت، مهندسی و راه اندازی می­شود، استفاده می­کنند.
یک شبکه­ي خصوصی مجازی IP می­تواند به عنوان یک پیاده­سازی VPN تعریف شود که از منابع تسهیم شده یا عمومی شبکه­ي IPبرای پیروی از مشخصات یک شبکه خصوصی مبتنی بر IP استفاده می­کند. در مقایسه با مدل­های VPN اتصال­گرای کلاسیک که مبتنی بر فناوری­هایی هم­چون ATM یا Frame Relayهستند، پیاده­سازی VPNهای مبتنی بر IP با چالش­های زیر روبه­رو هستند:
·چگونه یک شبکه IP تسهیم شده را برای استفاده شرکت خصوصی، ایمن کنیم.
·چگونه تضمین کنیم که کیفیت و ظرفیت شبکه­ که مورد نیاز محدوده­ي وسیعی از کاربران و کاربردهاست، به طور کامل پوشش داده می­شوند.
دو نوع اصلی از VPN ها به طور مشخص شناخته شده اند:
1- VPNهای مبتنی بر تجهیزات مربوط به مشتری یا Customer Premise Equipment(CPE)
2- VPN های مبتنی بر شبکه.
در یک VPN مبتنی بر CPE دانش و اطلاعات مربوط به شبکه­ي مشتری محدود به تجهیزات شخصی مشتری است. تدارک و مدیریت VPN به مدیریت شبکه­ي مشتری وابسته است که به وسیله پیکربندی دستی تونل­های بین CPEها انجام می­شود، هرچند به طور معمول تامین­کنندگان خدمات، مسوولیت مدیریت و تدارک تجهیزات کاربر را، برای کاهش نیازمندی­های مدیریتی مشتری بر عهده دارند. شکل 1، مدلی از این VPN را نشان می­دهد.

http://www.systemgroup.net/admin/images/attachs/Figure1.JPG

در VPNهای مبتنی بر شبکه، عملیات و کنترل به وسیله تجهیزات شبکه­ي تامین­کننده­ی خدمات ایجاد می­شود. شبکه­ي مشتری به وسیله­ي تونل­ها که بین جفت روترهای کناری کار گذاشته می­شوند، پشتیبانی می­شود. تونل­ها ممکن است از کپسوله کردن­های مختلف برای فرستادن ترافیک از طریق تامین­کننده­ي خدمات استفاده کنند. دو نوع اصلی از VPNهای مبتنی بر شبکه، VPNهای مبتنی بر لایه­ي 2 و VPNهای مبتنی بر لایه­ي 3 هستند. شکل 2 مدل یک VPN مبتنی بر شبکه را نشان می­دهد که می­توان آن را با مدل قبلی مقایسه کرد.

http://www.systemgroup.net/admin/images/attachs/Figure2.JPG

یک دسته­بندی رایج از VPNها بر این مبناست که آیا CPE مشتری و تامین­کننده­ي خدمات اطلاعات مسیریابی را در سطح لایه­ي 3 تبادل می­کنند یا خیر. دو مدل پیاده­سازی از VPNها می­تواند بر مبنای ضوابط زیر تعریف شود:
·مدل روی هم قرار گرفته (overlay): مدلی است که سرویس VPN از لحاظ عملکرد، معادل خطوط leased، شبیه­سازی شده است و تامین­کننده خدمات و مشتری اطلاعات مسیریابی لایه­ي 3 را تبادل نمی­کنند. این مدل مسوولیت­های مشتری و provider را به روشنی از یکدیگر جدا می­کند.
·مدل peer-to-peer : وقتی تهیه­کننده­ي خدمات و مشتری اطلاعات مسیریابی لایه­ي 3 را رد و بدل می­کنند، این مدل پیاده­سازی مسیریابی مشتری را آسان می­کند و تدارک آسان­تری برای ارایه­ي خدمات VPN به وجود می­آورد.
مدل overlay: در مدل VPN روی هم قرار گرفته، تضمین کیفیت سرویس به طور معمول مبتنی بر پهنای باند تضمین شده بر روی یک VC مشخص و بیشینه­ي پهنای باند در دسترس، بر روی یک VC خاص بیان می­شود.
مدل peer-to-peer : در حقیقت مدل peer-to-peer VPN به منظور از میان بردن مشکلات موجود در مدل overlay VPNمعرفی شده است. در مدل peer-to-peer، روترهای کناری provider به طور مستقیم اطلاعات مسیریابی را با روتر CPE تبادل می­کنند.
شکل 3 این دو مدل را با هم مقایسه می­کند.

http://www.systemgroup.net/admin/images/attachs/Figure3.JPG

منبع: http://www.systemgroup.net (http://www.systemgroup.net/)

[Admin]

مدیریت شبکه های خصوصی مجازی بر مبنای پروتکل اینترنت (IP) (بخش دوم)

نیازمندیهای مدیریتی IPVPN – از دیدگاه service provider
1. مدیریت خرابی (fault management): جنبه‌های پشتیبانی و کارکردهای مورد نیاز برای مدیریت خرابی شامل موارد زیر است:
·مشخص کردن مشتری‌هایی که از خرابی متاثر شده‌اند.
·کشف خطا (گزارش‌های حوادث، alarmها، مشخص کردن خطاها)
·تعیین محل خرابی
·ثبت حوادث
·عملیات اصلاحی (ترافیک، مسیریابی، تخصیص منابع).
VPNهای مبتني بر شبکه بر یک زیرساخت شبکه‌ای واحد تکیه دارند، بنابراین سیستم مدیریت شبکه باید ابزاری برای اطلاع دادن به provider مربوط به VPNی که تحت تاثیر یک خرابی قرار گرفته است، تدارک ببیند. باید ابزاری برای مانیتور کردن وضعیت عنصر شبکه و ثبت رخداد مربوط به قطع سرویس به صورت جزيی یا کلی وجود داشته باشد. در اين راستا برای VPNهای مبتني بر شبکه‌های به هم متصل، نه تنها برچسب زدن troubleها که ارسال علايمی که نشانه‌های alarm را در بردارد نیز - به ويژه در محیطی که دارای چندین تدارک سرویس است- مورد نیاز است.
خرابی‌هایی که به وسیله‌ي انواع مختلف خطاهای پیکربندی ایجاد شده‌اند و سرویس‌هایی که به دلیل پایین آمدن‌ جدی کارایی، از رده خارج شده‌اند، باید به دقت شناخته شوند، اما تشخیص اين‌گونه خطاها و پاک کردن خرابی‌ها در مواقعی که مساله شامل حوزه‌های provider ی به هم متصل فراوان و گره‌های زیاد است، ممکن است دشوار باشد. مدیریت خرابی باید به وسیله مانیتور کردن وضعیت و رخداد با استفاده از پروتکل‌های کنترلی موجود، وجود دسترسی‌های خاص مشتری و قیدهای مسیریابی و استفاده از تنظیم‌های مناسب پارامتر پیکربندی را بررسي كند. به عنوان حداقل ملزومات، باید توانایی تشخیص برقراری اتصال لایه 2 (L2) یا مسیرهای قابل رسیدن لایه 3 (L3)در داخل یک VPN به وجود آيد.
2. مدیریت پیکربندی(configuration management)- نیازهای مرتبط: IETF به تازگي جزيیات نیازمندی‌ها را به طور جداگانه‌ برای پیکربندی‌های مبتني بر CE و مبتني بر PE به صورت زیر تعریف کرده است:
مدیریت پیکربندی برای VPNهای مبتني بر شبکه(طرف provider):
نیازمندی‌های مدیریت پیکربندی که تنها برای یک VPN طرف provider است، به شرح زیر است:
·سیستم مدیریت شبکه(NMS) باید دست كم پیکربندی جنبه‌های زیر را برای روترهای PE لایه‌ي 3 پشتیبانی کند: عضویت اینترانت و اکسترانت و پروتکل مسیریابی CE برای هر اتصال قابل دست‌رسی، اندازه‌گیری‌های مسیر، تونل‌ها و غیره.
·NMS باید شناسه‌هایی را برای SPها، PPVPNها، PEها و CEها به کار برد و از "تونل‌های سلسله مراتبی" پشتیبانی کند.
·تونل‌ها باید بین دستگاه‌های P و PE پیکربندی شوند. که این پيكربندي نیازمند هماهنگی و مشارکت شناسه‌های تونل‌ها، تونل‌های سلسله مراتبی، VPNها و هر اطلاعات سرویس وابسته به آن‌ها، براي مثال یک سرویس QoS/SLA است.
·پروتکل‌های مسیریابی که بین روترهای PE و دستگاه‌های CE اجرا می‌شوند باید برای هر VPN پیکربندی شوند.
·برای سرویس چندپخشی، پروتکل‌های مسیریابی چندبخشی نیز باید قابل پیکربندی باشند.
·پروتکل‌های مسیریابی که بین روترهای PE اجرا می‌شوند و آن‌هایی که بین روترهای P و PE اجرا می‌شوند نیز باید پیکربندی شوند.
·پیکربندی یک PPVPN بر مبنای PE باید متناسب با پیکربندی زیرساخت پایه‌ي آن شامل اجزای متصل شده‌ي شبکه‌های لایه 2 و لایه 1 یک PPVPN باشد.
مدیریت پیکربندی برای VPN های بر مبنای CE
نیازمندی‌های مدیریتی خاص برای VPNهای بر مبنای CE، شامل موارد زیر است:
·تونل‌ها باید بین دستگاه‌های CE پیکربندی شوند. براي اين پيكربندي بايد:
·هماهنگی شناسه‌های تونل‌ها، VPNها و هر نوع اطلاعات سرویس وابسته به آن‌ها؛ برای مثال، یک سرویس QoS/SLA.
·پروتکل‌های مسیریابی که بین روترهای PE اجرا می‌شوند و دستگاه‌های CE، باید پیکربندی شوند. همچنین برای سرویس چندپخشی، باید پروتکل‌های مسیریابی چندپخشی قابل پیکربندی باشند.
3. مدیریت حسابداری(Accounting management)-بسیاری از تهیه کنندگان سرویس هزینه شارژ را بر مبنای میزان مصرف ارايه می‌كنند، بنابراین اندازه‌گیری‌هایی که میزان مصرف منابع را نشان می‌دهد باید (با استفاده از سیستم‌های پشتیبانی و پروتکل ها) کامل باشد، تا بتوان به حساب مشتریان رسیدگی کرد. همچنین ممکن است NMS به نگه‌داري همبستگی ميان اطلاعات حسابداری با اطلاعات مدیریت خرابی و کارآیی نیاز داشته باشد. همه‌ي راه‌حل‌های گسترش PPVPN باید چه‌گونگی انجام توابع مدیریت حسابداری زیر را تشریح کنند:
·اندازه‌گیری میزان استفاده از منابع
·جمع‌آوری اطلاعات حسابداری
·ذخیره‌سازی و مدیریت اندازه‌گیری‌ها
بسیاری از تهیه‌کنندگان سرویس ممکن است به اطلاعات اندازه‌گیری نزدیک به زمان واقعی نیاز داشته باشند و ممکن است این نیازمندی را به عنوان بخشی از یک سرویس مدیریت شبکه مشتری ارايه دهند.
4. مدیریت کارایی (Performance Management)- مدیریت کارایی شامل مجموعه توابعی است که درگیر مانیتور کردن و جمع‌آوری داده‌های مربوط به کارایی دستگاه‌های مربوط، تسهیلات و خدمات و هم‌چنین محاسبه‌ي میزان توافق با مشخصات سطح سرویس (SLS) مانند QoS و اندازه‌گیری‌های قابل دسترسی بودن هستند. مدیریت کارایی هم‌چنین باید تحلیل جنبه‌های مهم یک PPVPN، مانند میزان استفاده از پهنای باند، زمان پاسخ، در دست‌رس بودن، آمارگیری‌های QoS، و برنامه‌ریزی‌های آینده بر مبنای داده‌های جمع آوری شده را پشتیبانی کند.
مانیتور کردن کارایی
NMS باید رفتار دستگاه را از لحاظ توانايي در ارزیابی اندازه‌گیری‌های کارایی مربوط به یک توافق سطح سرویس مشخص، مانیتور کند. NMS هم‌چنین باید جنبه هایی از یک VPN را که به طورمستقيم به یک SLA وابسته نیستند، مانند سطوح مصرف و تغییرات کارایی در وضعیت‌های پرباری، مانیتور کند.
سیستم مدیریت شبکه باید SLAهای بین SP و مشتری‌های گوناگون رابر طبق SLS (Service Level Specification)های مرتبط پشتیبانی کند.
5. مدیریت امنیت- تابع مدیریت امنیت کارکردی NMS، باید شامل جنبه‌هایی از مدیریت برای تضمین امنیت دستگاه‌ها، اتصالات قابل دسترس و پروتکل‌های داخل شبکه PPVPN و هم‌چنین امنیت داده‌ها و کنترل‌های مشتریان باشد. .
Qos در IPVPN ها
کیفیت سرویس به طور کلی به معناي اطمینان از داشتن كم‌ترين تاخیر یا گم شدن كم‌ترين ميران بسته‌هاست. که برای انواع مشخصی از کاربردها یا ترافیک تعریف شود. شبکه‌های سنتی شرکت‌ها مي‌توانستند سطوح ثابتی را برای در دسترس بودن منابع در همه‌ي وضعیت‌ها تضمین کنند که این تضمین با استفاده از مدارهای اجاره‌ای اختصاصی صورت می‌گرفت. VPNهای لایه‌ي 2 مي‌توانند کارایی قابل قبول و قابل مقایسه با راه‌حل‌های خطوط اختصاصی، ایجاد كنند. هم‌چنین انتظار می‌رود که تهیه کنندگان سرویس IPVPN نیز ز QoS به همان نوع پشتیبانی كنند.
به وسیله IETF دو چارچوب به عنوان معماری‌های QoS در شبکه‌های بر مبنای IP به وجود آمده است: سرویس‌های مجتمع (IntServ) و سرویس‌های متمایز (DiffServ). هم‌چنین MPLS همراه با مدیریت ترافیک و مسیریابی مبتني بر محدودیت نیز ابزارهای جدیدی را برای مدیریت و کنترل QoS تهیه می‌کنند. که این روش‌ها قابل کاربرد به VPNهای مبتني بر IP نیز هستند.
IntServ:
در مدل سرویس‌های مجتمع، applicationها مشخصات ترافیکی خود را می دانند و به گره‌های میانی شبکه علامت می‌دهند تا منابع مشخصی را برای‌شان ذخيره کنند تا بتوانند مشخصات ترافیکی آن‌ها را برآورده سازند. بر حسب در دست‌رس بودن منابع، گره‌هاي مياني شبکه، منابع را رزرو می‌کند و یک پیغام acknowledgement مثبت یا منفی برمی‌گرداند. این بخش از استاندارد، کنترل ورود (admission control) نامیده می‌شود. پروتکل سیگنالینگی که در اين بخش بيش‌تر استفاده می‌شود RSVP یا Resource reSerVation Protocol نامیده می‌شود.
RSVP دو نوع کلاس سرویس را وابسته به نوع کاربرد و ميزان حساسیت آن به تاخیر، گم شدن بسته ها و ... تحویل می‌دهد:


سرویس تضمین شدهGuaranteed service: این سرویس پهنای باند را برای ترافیک application مورد نظر و بيشينه‌ي معینی را برای تاخیر تضمین می‌کند.
سرویس با بار کنترل شدهControl-load service: در این سرویس تاخیر متوسط تضمین می‌شود، اما تاخیر انتها به انتهایی، که به وسیله یک بسته‌ي دلخواه ایجاد می‌شود، به طور دقيق نمی‌تواند محاسبه شود.

عمده‌ترين ‌مشکل روش‌های سرویس مجتمع، در استفاده از RSVP است. RSVP به تک تک جریان‌های هر ترافیک یک QoS نسبت می‌دهد. بنابراین ترافیک سیگنالینگ سنگینی باید بین عناصر شبکه که وابسته به یک ناحیه مرکزی از شبکه هستند، مبادله شود. به علاوه، بعد از این‌که یک رزرو صورت گرفت و ارتباط برقرار شد، هر عنصر شبکه باید برای هر بسته IP رسیده، کلاسی مشخص کند تا متعلق بودن آن به یک جریان QoS مشخص شود و اگر بسته IP رسیده متعلق به جريان QoS مورد نظر بود، منابع لازم را به جریان نسبت دهد. بنابراین در استفاده از RSVP مسايلي هم‌چون قابلیت گسترش در حوزه‌ي سیگنالینگ، کلاس‌بندی و مکانیزم‌های زمان‌بندی وجود دارد.
DiffServ:
تدارک سرویس متمایز برای تهیه‌ي QoS در یک شبکه از طریق مکانیزم‌هايی است که می‌توانند برای به دست آوردن یک سرویس برای مشتری انتهایی استفاده شوند. یکی از این مکانیزم‌ها رفتار در هر (HOP)یا (PHB) است. DiffServ تعدادی از رفتارهای داده‌ها را که به عنوان یک PHB شناخته می‌شوند، تعریف می‌کند. اين رفتارها می‌توانند به بسته‌های هر گره اعمال شوند (همه‌ي بسته‌هایی که از یک لینک عبور می‌کنند و به رفتار مشابهی نیاز دارند یک Behavior Aggregate (BA) را تشکیل می‌دهند). PHB برای مشخص کردن رفتار نسبت داده شده به هر بسته در گره به كار مي‌رود. این رفتار شامل انتخاب صف و تنظیم زمان‌بندی و آستانه‌ي ازدحام است. بسته‌ها برای تشخیص رفتاری که نیاز دارند، با استفاده از بایت DS علامت‌گذاری می‌شوند. بایت DS در قسمت بایتTOS که در هِدِر IP وجود دارد، قرار می‌گیرد. PHBهای تعریف شده عبارت‌اند از:
·Expedited Forwarding(EF)
EF PHB در هر گره loss پایین، jitter پایین و تاخیر پایین را عرضه می‌دارد.
·Assured Forwarding(AF)
گروه AF PHB، N کلاس فورواردینگ غیر وابسته را تعریف می‌کند (در حال حاضر 4 كلاس فورواردينگ غير وابسته تعریف شده است) که به صورت AF1 تا AFn هستند. در داخل هر یک از این کلاس‌های فورواردینگ، برای احتمال تحویل بسته، M زیر کلاس وجود دارد (در حال حاضر 3 زيركلاس تعریف شده است). هر کلاس فورواردینگ در داخل این گروه به طور مستقل برای منابعی مانند فضای بافر و حداقل ظرفیت خروجی که باید به وسیله‌ي مکانیزم زمان‌بندی تضمین شود، پیکربندی می‌شود.
·Default Behavior(DE)
DE PHB ترافیک موجود best effort را مشخص و رفتاري تعریف می‌کند که گره، هر تعدادی از این بسته‌ها را که امکان داشته باشد در کوتاه‌ترین زمان ممکن تحویل ‌گردد.

[Admin]

مدیریت شبکه های خصوصی مجازی بر مبنای پروتکل اینترنت (IP) (بخش سوم)

MPLS
برای سرویس های QoS در یک شبکه IP، می­توان از معماری سرویس­های مجتمع و سرویس­های متمایز استفاده کرد. اما به دلیل استفاده از برچسب­ها درMPLS، برای کار کردن بر روی یک معماری MPLS، به ایجاد تغییراتی نیاز است. برای ایجاد این تغییرات سه روش به IETF پیش­نهاد شده است:

1.سرویس­های مجتمع در حوزه­های MPLS با استفاده از سیگنالینگ CR-LDP
یکی از پی­آمدهای مهم مسایل قابلیت گسترش در IntServ این است که QoS در سطح IntServ فقط می­تواند در بین نواحی جانبی شبکه ایجاد شود. این وضعیت باعث جلوگیری از توسعه­ي آن به داخل نواحی مرکزی و پیاده سازی QoS انتها به انتها می­شود. استفاده از پروتکل MPLS در شبکه­ي مرکزی بعضی از مسایل مربوط به scalability را حذف می­کند و با پروتکل CD-LDP مسیرهایی به نام LSP یا Lable Switched Path تعریف می­شوند که دارای محدودیت های QoS هستند و کلاس­بندی QoS را با استفاده از حوزه های MPLS و نواحی IntServ ایجاد می­کنند. بدین منظور، LSR ورودی MPLS مانند یک gateway دارای کیفیت سرویس MPLS/IntServ عمل می­کند. بعد از پذیرش یک پیغام RSVP که منابع را رزرو می­کند، LSR ورودی، یک LSR مسیریابی شده به طرف LSRهای خروجی برقرار می­کند. مقادیر پارامترهای ترافیکی (مانند پارامترهای QoS) از پیغام­های resv مربوط استخراج می­شود. ترافیک فرستنده RSVP حوزه­ي MPLS با استفاده از این مسیر CR-LSP عبور می­کند. LSRهایی که در کناره­ي حوزه­های MPLS نیستند، تنها پیغام­های CR-LDP را پردازش می­کنند. اگرچه این روش می­تواند تا حدی مشکل scalability را حل کند، برای همکاری بهتر روش سرویس متمایز با MPLS به نظر می­رسد که تغییرات بیش­تری در شبکه­ي هسته موردنیاز است.
2.MPLS و DiffServ
ممکن است لازم باشد یک LSP به دلیل ارتباط با خواص کیفیت یک سرویس خاص، به وسیله­ي مکانیزم­های QoS در داخل LSRها از طریق ابزاری غیر از MPLS اجرا شود. نیازمندی اصلی MPLS برای پشتیبانی از DiffServ این است که تضمین كند بسته‌ها رفتار QoS مناسب خود را به وسیله هر LSR داخل شبکه دریافت می‌کنند.
3.QoS در MPLS VPNها
VPNهای سنتی که بر مبنای فناوري‌های لایه 2 یا خطوط اجاره‌ای (leased line) هستند، به صورت تضمین شده، پايين‌ترين سطح کیفیت سرویسی را که به وسیله پارامترهایی مانند CIR (در مورد Frame Relay)، CBR و SCR (در موردATM) یا پهنای باند مدار (در مورد خطوط اجاره‌ای) بیان می شوند، عرضه می کنند. البته در مورد VPNهای MPLS نیز کاربران باید تضمین‌های مشابهی برای QoS داشته باشند.

دو مسیر اصلی کنترل QoS در VPNهای MPLS وجود دارد- مدل pipe و مدل hose:
مدل hose بر مبنای دو پارامترICR (Ingress Committed Rate) و ECR
(Egress Committed Reate) است که برای هر رابط CE/PE تعریف می‌شوند. این دو پارامتر، ترافیکی را که هر روتر CE (طرف مشتری) می‌تواند به سایت‌های VPN دیگر انتقال دهد یا از سایت‌های VPN دیگر دریافت کند، مشخص می‌کنند.
شکل 4 مثالی را از مدل hose نشان می‌دهد.که در این مورد روتر CE که به سایت 1 متصل است می تواند تا 512 kbit/s را از سایت‌های دیگر همان VPN دریافت کند و تا 256 kbit/s را انتقال دهد. باید توجه شود که این مقادیر وابسته به توزیع ترافیک در بین سایت‌های remote هستند. براي مثال به سایت 1 اجازه داده می‌شود که اگر در همان زمان در حال ارسال هیچ ترافیکی به سایت 3 نباشد، 256kbit/s را در یک فاصله زمانی مشخص به سایت 2 بفرستد.


http://www.systemgroup.net/admin/images/attachs/F1.JPGشكل 4: مدل hose


کنترل QoS در هسته MPLS ممکن است به وسیله‌ي DiffServ صورت گیرد. در این مورد مدل مبنای hose می‌تواند به طور جداگانه برای هر کلاس سرویسی به کار برده شود. از دیدگاه مشتری یکی از فواید مدل hose این است که نیاز به دانستن جزيیات توزیع ترافیک بین سایت‌های VPN ندارد. این ويژگي پیاده‌سازی این روش را آسان می‌کند.
مدل دیگر، مدل pipeاست که شامل تدارک برای تضمین QoS، براي مثال كمينه‌ي پهنای باند، بین هر جفت از روترهای CE است. LSPهای دارای پهنای باند تضمین شده بین PEها که در MPLS مورد استفاده قرار می‌گیرند، می‌توانند برای پشتیبانی از مدل pipe استفاده شوند.
مدل pipe روش QoS پایه‌ای را که در VPNهای ATM یا Frame Relay سنتی استفاده می‌شود، در خود دارد. (جدا از این واقعیت که مدل pipe یک طرفه است در حالی که در ATM یا Frame Relay ارتباط در حالت عادی دو طرفه تعریف می شود.)
در مثالی که در شکل 5 نشان داده شده است، دو ارتباط سایت‌هاي "3 و"1 و سایت‌هاي "3 و 2" به ترتیب دارای پهنای باند 5 Mbit/s و 7 Mbit/s هستند.
مدل pipe می‌تواند به تعدادی از کلاس‌های سرویس اعمال شود.


http://www.systemgroup.net/admin/images/attachs/F2.JPG



شکل 5-مدل pipe

از آن‌جا که يك راه‌حل واحد كه دربرگيرنده و برطرف‌كننده‌ي همه‌ي نيازها باشد، وجود ندارد، در عمل پیاده‌سازی‌هایی که به صورت ترکیبی از دو مدل هستند، مي‌توانند مناسب‌ترین راه‌حل باشند.

مدیریت IPVPN ها
در این بخش ابتدا بر مبنای آخرین نسخه‌ي سندIETF، توان‌مندی‌های کارکردی که به علاوه جزيی از سرویس‌های پشتیبانی مدیریتی برای تدارک IPVPN به شمار مي‌آيند، تشریح می‌شود و سپس مطابق مفهوم TMNمروری بر جنبه‌های مدیریتی مربوط به آن، خواهد شد. در انتها بر مبنای ويرايش‌های تازه توسعه یافته‌ي مدل مدیریتی و QoS، چارچوب در بر گیرنده‌ي IP و معماری مدیریتی مخصوص VPN نشان داده می‌شود.

نیازمندیهای مدیریت QoS
از آن‌جایی که VPNها به طور معمول اتصالات شبکه‌ي خصوصی امنی هستند که در روی یک زیرساخت قابل دسترس عمومی مانند اینترنت یا شبکه‌ي تلفن عمومی ایجاد می‌شوند، به طور ایده آل یک VPN باید شبیه یک شبکه‌ي خصوصی رفتار کند؛ یعنی امن باشد، در دست‌رس باشد و نيز کارایی قابل پیش بینی داشته باشد. به طور معمول بر طبق مدل TMN، رفتار جداگانه‌ای برای جنبه‌های مدیریتی شبکه و جنبه‌های کنترلی آن در نظر گرفته می‌شود.
توابع مدیریتی اغلب به صورت یک لایه‌ي پوششی که عملیات مخصوص FCAPS را انجام می‌دهند، پیاده‌سازی می‌شوند. امروزه این جداسازی واضح بین سطح کنترلی و سطح مدیریتی چندان آشکار نیست. انواع مخصوصی از مدیریت شبکه تا کنون در پروتکل‌ها (لایه بالا) به صورت نهفته قرار گرفته‌اند و روند و خط سیر به سمت سرمایه‌گذاری بسیار بیش‌تری در مدیریت خدمات و توسعه‌ي مکانیزم‌های مدیریتی سطح بالا برای خودكار کردن زیربرنامه‌های خاص مدیریتی و کاهش زمان تحویل تا حد امکان در حركت است.
یکی از موضوعات کلیدی برای موفقیت یک راه‌حل VPN، مساله کیفیت سرویس– QoS است. ترکیب VPN همراه QoS منجر به محصولاتی با قابلیت رقابتی بالا می‌شود. بنابراین هم VPN و هم QoS باید با یک روش مجتمع مدیریت شوند. بدون توجه به اینکه چه معماریی برای VPN انتخاب می‌شود یا چه فناوري، QoS را پشتیبانی می‌کند. سرویس‌های IPVPN فرصت خوبی را برای تهیه‌کنندگان خدمات فراهم می‌کنند تا منافع جدید و بیش‌تری را دریافت کنند. تامين كتتدگاني که بتوانند سرویس‌های IPVPN قابل مدیریت و به سرعت قابل گسترشی را عرضه كنند، سود رقابتی را به دست می‌آورند. کلید موفقیت و سودبخشی نهایی خدمات IPVPN را می‌توان به طور ساده در فناوري فراهم شده جست‌وجو کرد. مدیریت‌پذیری سرویس و مدیریت کل دوره‌ي زمانی؛ یعنی برنامه‌ریزی (planning)، تدارک (provisioning)، مانیتورینگ، عملیات (operation) و صورت‌حساب (billing)؛ هر دو مهم هستند.
مدیریت سرویس به مدیریت زیر ساخت شبکه ای که در زیر آن قرار گرفته و تدارک و تهیه رابط‌هایی براي داده‌ها و مکانیزم‌هایی که فرایند کلی تجاری provider را پیش ببرند بستگی دارد. تهیه‌کنندگان سرویس، دیگر، روی قیمت با یکدیگر رقابت نمی‌کنند بلکه بر روی زمان تحویل سرویس رقابت می‌کنند. بنابراین کلید گسترش سودآور سرویس VPN، مدیریت است.

قابلیتهای عمومی مدیریت QoS برای تدارک IPVPN
1. پشتیبانی از نیازمندی‌های گوناگون ترافیک (QoS) کاربر آن گونه که کاربر تعریف می‌کند.
2. ارائه، پشتیبانی و نگه‌داری سطوح توافق شده‌ي سرویس (براي مثال پیکربندی، خرابی، کارایی، امنیت و...)
3. هر FCAPS ی باید با SLA مقایسه شود و هر تخطی از QoS و SLA باید به طور خودكار کشف شود . تدارک و تهیه‌ي اطلاعات کارایی، آمارها و غیره ؛ یعنی فعال کردن مکانیزم‌های مانیتورینگ و اندازه‌گیری‌های مناسب نیازمندی‌های QoS و SLA؛ تحلیل اطلاعات ( برای مثال پهنای باند‌، زمان پاسخ‌، فراهم بودن، تلفات بسته و غیره )، پیش بینی روند آینده، حتا مسايل و یا توصیه‌هایی در ارتباط با SLA های جاری، الگوی ترافیکی، QoS و غیره.

[Admin]

مدیریت شبکه های خصوصی مجازی بر مبنای پروتکل اینترنت (IP) (بخش چهارم)

مدیریت QoS برای توافقات سطح سرویس (SLA)
برخي از قابلیت‌های مدیریتی باید در SLAها قرار گیرند و برای هر VPN، هر سایت VPN و یا هر مسیر VPN فرمول‌بندی شوند. مدیریت SLA باید بر مبنای موارد زیر باشد:

·اهداف سطح خدمات که از بعضی یا همه موارد مقابل تشکیل می شود:قابلیت انتقال IP، پارامترهای QoS، در دست‌رس بودن، مطمئن بودن، تثبیت و تایید تحویل، پشتیبانی پویا و قابلیت حمل ونقل، امنیت، پهنای باند، اولویت ها، تشخیص هویت، پروتکل‌های پشتیبانی شده، گسترش انعطاف‌پذیری و متصل بودن و مدت زمان SLA.
·اهداف مانیتورینگ سرویس: مانیتورینگ QoS با در نظر گرفتن اهداف، ردیابی جریان، تهيه و ارايه گزارش‌های موردنیاز، اهداف سود و زیان مالی، گزینش صورت‌حساب، جریمه‌ها، قیمت‌گذاری و هزینه‌های خاتمه‌ي زود هنگام سرویس.
مدیریت QoS کمک می‌کند تا ترافیک بحرانی، کارایی قابل قبولی داشته باشد.

خصوصیات مدیریت QoS برای پیاده سازی
کاربران به طور عادی توجهی به مكان‌شناسي شبکه یا سطح بالای امنیت و یا حتا فناوری خاص یا پروتکلی که VPN مورد استفاده‌ي ‌آن‌ها را پشتیبانی می‌کند، ندارند. آن‌ها به طور معمول درباره‌ي زمان پاسخ مورد قبول در دست‌رسي به یک سایت راه دور و کیفیت مورد نظر در زمانی که از سرویس‌ها استفاده می‌کنند، توجه دارند.
تهیه‌کنندگان سرویس باید بتوانند SLAهای انتها به انتها و QoS تضمین شده تحویل دهند. تهیه‌کنندگان سرویس ممکن است مايل باشند سرویس‌های پردازش را که به وسیله SLAها تعریف شده‌اند، به عنوان بخشی از VPNهای‌ خود، ارايه دهند. QoS در شبکه‌های IP به دستگاه‌ها این هوشمندی را می‌دهد که در ابتدا به ترافیکی رسيدگي كنند كه با سياست شبكه مطابقت دارد.
ويژگي‌های مورد نیاز مدیریتی بر طبق جداسازی سطح سرویس و سطح شبکه، به دو گروه تقسیم مي‌شوند:

در سطح سرویس، applicationهای مدیریت QoS، باید حداقل کارکردهای زیر را فراهم کنند (روش‌های مدیریت QoS):
·تدارک خودکار سرویسVPN: بر طبق تقاضای مشتریان، درخواست‌های اتصال باید به سرعت و به طور کامل برآورده وQoS باید تضمین شود. ابزارهای مدیریت QoS باید دارای راه‌حل‌هایی باشند که اجازه دهند VPNها ایجاد شوند، دارای پشتیبانی از انتخاب‌های مختلف برای کلاس‌های سرویس (COS) باشند، SLA خاص VPN را تدارک ببینند، داراي گزارش‌های کارایی باشند و...
·مانیتورینگ کارایی: گرفتن اطلاعات ترافیکی از شبکه‌ و جمع‌آوری آن از جهات گوناگون و در فواصل زمانی مختلف و تعریف چگونگی نگاشت اندازه‌گیری‌های QoS به پارامترهای کارایی سطح سرویس به طوری که بتواند برای مشتری ارايه شود، باید امکان‌پذیر باشد. ویژگی‌های SLA، مانند تاخیر، در دست‌رس بودن، بازدهی و jitter باید در سطوح مختلف مانیتور و جمع‌آوری شود.
·مدیریت سرویس مشتری: مشتری‌ها باید با خدمات مدیریتی مانند: تدارک و فراهم‌آوری خودکار، سرویس‌های پیکربندی QoS، گزارش‌های زمان‌بندی شده از پیروی SLA و غیره آشنا شوند.

در سطح شبکه روش‌های مدیریت QoS زیر باید مورد توجه قرار گیرند:
·کلاس‌بندی بسته‌ها- به گروه‌بندی بسته‌ها بر طبق ضوابط از پیش تعریف شده کمک می‌کند، به طوری که گروه‌های به دست آمده از بسته‌ها می‌توانند، برای داشتن رفتارهای مشخص با بسته های هر گروه به کار روند.
ضوابط کلاس بندی ترافیک قبل و بعد از وارد شدن به VPN می‌تواند آدرس‌های IP، URL، آدرس‌های MAC، شماره‌ي پورت TCP/UDP، حق تقدم IP یا نوبت‌دهی در زمان باشد.
·علامت‌گذاری رنگ‌بندی بسته- بعد از کلاس‌بندی، بسته‌ها باید با یک Id يكسان (با استفاده از فیلد TOS در IP، DSCP و غیره)، علامت‌گذاری شوند تا اطمینان حاصل شود که کلاس‌بندی به صورت انتها به انتها در نظر گرفته شده است.
·مدیریت پهنای باند- بعد از کلاس‌بندی ترافیک، باید دریافت رفتار صحیح به وسیله آن از جهت زمان‌بندی و صف‌بندی در روترها تضمین شود.
·Traffic Shaping- این روش برای صاف کردن و مرتب کردن جریان‌های ترافیک استفاده می‌شود. Tocken Bucket Shaper می‌تواند برای جلوگیری از ترافیک burst و نيز جلوگیری از peakهای ترافیکی به جای استفاده از مشخصات روترهای PE، استفاده شود، هم‌چنین دستگاه‌های shaper ممکن است به ازای هر سایت بین CE و PE به وسیله مشتریان پیاده‌سازی شوند.
·جلوگیری از ازدحام- shaping در هر مورد ممکن است باعث ایجاد صف‌های طولانی در روترهای کناری شود، بنابراین جلوگیری از ورود یا drop کردن بسته‌ها از جریان‌های تولید شده به وسیله‌ي کاربردهای غیرحساس می‌تواند از ازدحام زياد در شرایط بارهای زیاد جلوگیری کند.

مفاهیم مدیریتی کاربردی و مدل های پیش‌نهادی
در اثبات تحویل مناسب و مدیریت شده‌ي خدمات VPN، موضوعات اساسی مورد توجه اپراتورهای شبکه و تولیدکنندگان خدمات به شرح زیر است:
I. برای پیاده‌سازی ابزارهای اندازه‌گیری مقدار مصرف؛ اندازه گیری‌های کارایی مصرف منابع و اندازه‌گیری انواع نقاط دست‌رسی قابل اندازه‌گیری، رابط‌هایی که به دست آوردن داده‌های مربوط را از نتایج اندازه‌گیری امکان‌پذیر می‌کنند.
II. برای انتخاب و پیاده‌سازی در گرفتن داده‌ها؛ مدیریت، مستندسازی، ابزارهای رسیدگی به داده‌ها، قوانین و راه‌حل‌ها، منابع مورد نیاز و جنبه‌هایی که رسیدگی به داده‌ها و قابلیت‌های ذخیره‌سازی و هم‌چنین تبدیلات داده‌ها و ابزارهای پردازش داده‌ها را می‌پوشانند، باید یک MIB استاندارد به کار برده شود و سیستم‌های پایگاه داده‌ي پشتیبان عملیات و مدیریت باید به صورت مجتمع وجود داشته باشد.
III. برای عرضه مدیریت خرابی که وابسته به عنصر شبکه است، برای پیاده سازی ثبت رخدادها و قابلیت‌های مانیتور کردن وضعیت، علاوه بر سطوح alarm قابل انتخاب برای سیگنال زدن نشانه‌ي alarm، مجتمع‌سازی گزارش‌دهی خرابی و فرآیندها و سیستم‌های trouble ticket پیش‌نهاد می‌شود.
IV. برای پشتیبانی از اتوماسیون در مدیریت پیکربندی، مدل تحویل سرویس IPVPN بر مبنای مفهوم تهیه‌کننده‌ي اصلی پیش‌نهاد می‌شود. عملیات زیر می‌تواند بر مبنای این مدل انجام شود:
·مذاکرات در مورد مكان‌شناسی سایت و پیش‌بینی ترافیک مربوط (ظرفیت و نوع payloadی که قرار است انتقال یابد) و تغییرات بر حسب تقاضا در رزرو منابع.
·توجه به مشتری و در نظر گرفتن رابط‌هایی برای رسیدگی به دستورات سیستم پشتیبانی از زمان تحویل سرویس، به صورت مجتمع.
V.برای به کار بردن مناسب ابزارهای انتخاب شده مانیتورینگ کارایی، راه‌حل‌های استاندارد اندازه‌گیری، و طرح‌های ارزیابی‌کننده در مدیریت کارایی. پارامترها، ضوابط اندازه‌گیری و اهداف باید از SLAهای محصولات معمول و مورد توافق گروههای کاربری مربوط انتخاب شوند. افزون بر اين ارزیابی آماری نیز مورد نیاز است.
VI. برای پیاده‌سازی سیستم‌های پشتیبانی استاندارد، که برای اهداف تشخیص هویت، حدود و اختیارات و مدیریت حساب‌رسی به کار برده می‌شوند. برای به کاربردن معماری بر مبنای امنیت، برای پیاده‌سازی قابلیت‌های ایجاد بازرسی‌های امنیتی.

بر طبق استاندارد IETF سه گزینه برای گسترش سیستم‌های مدیریت VPN و سیستم‌های پشتیبانی QoS برای تحویل سرویس VPN وجود دارد:
·استفاده از یک مدل call-centre برای کنترل مشتری
·گسترش سیستم‌های مدیریتی سفارشی و اغلب اختصاصی و کنترل سیستم‌ها، مانیتور کردن راه‌حل‌های پیاده‌سازی برای مدیریت backbone شبکه‌ي IPVPN و تحویل سرویس VPN.
·برای پیاده سازی استاندارد و نيز راه‌حل‌های مدیریت VPN بر مبنای سیاست.

مدیریت بر مبنای سیاست با استفاده از یک معماری عملیاتی لایه‌ای
مدل معماری QoS بر مبنای سیاست در استاندارد IETF شامل چهار گزینه‌ي کارکردی است: پیکربندی، عنصر شبکه، موتور سیاست و حساب‌رسی. با این روش، فرآیندهای مدیریتی انعطاف‌پذیر و توسعه‌پذیر پیاده‌سازی می‌شوند که با یکدیگر می توانند از هزینه‌ي QoS و هزینه‌های مبتني بر میزان استفاده، پشتیبانی كنند.
این معماری یک ارايه عملی را در زمان واقعی از دیدگاه‌های مختلف، عرضه می دارد. این دیدگاه‌ها می‌تواند مبتني بر مشتریان، فیلتر کردن داده‌های مدیریتی به ازای هر VPN و يا حساب‌رسی نیازمندی‌های مورد نیاز امنیتی باشد. شکل خاصی از مدل مدیریت بر مبنای سیاست همراه با پروتکل‌های استاندارد در شکل 6 نشان داده شده است.
در این معماری نقاط اعمال سیاست (Policy Enforcement Points-PEP) مسوول عرضه‌ي کنترل بر مبنای سیاست به وسیله پیاده‌سازی سیاست و فرآیند اندازه‌گیری در لایه‌ي NE و سپس اعمال کنترل به مدیریت عنصر (Element Management-EM) است، در حالی که سیاست به وسیله لایه‌ي مدیریت شبکه انتخاب و پیاده‌سازی می‌شود.
بر مبنای سیاست کیفیت خدمات NMS/OSS، قابلیت‌های مدیریت SLA و هزینه‌ي QoS نیز ممکن است پیاده سازی شوند (در این شکل لایه‌ي مدیریت سرویس/تجاری که در بالای لایه مدیریت شبکه قرار دارد، نشان داده نشده است).
وقتی که یک provider اصلی وجود دارد که داراي سیستم‌ها و راه‌حل‌های مختلف دست‌رسی برای تهیه و تدارک شبکه و هم‌چنین یک شبکه‌ي مرکزی و یک backboneIP است، به طور خاص مي‌توان از اين مدل استفاده كرذ.




http://www.systemgroup.net/admin/images/attachs/F6.JPG



شکل 6- مدیریت QoS بوسیله معماری عملیاتی بر مبنای سیاست


SLA مجتمع شده ومدیریت اطلاعات QoS
برای این‌که بتوانیم به طور واقعی مدیریت مجتمع SLA را انجام دهیم، لازم است در همه‌ي سرویس‌های وابسته و اطلاعات مشتریان، يك مدیریت موثر داشته باشیم. توابع مدیریت SLA بايد گستره‌ي وسیعی از منابع داده را ترکیب کنند، وابستگی آن‌ها را پیدا و در نهایت ارزیابی و مدیریت کنند تا بتوانند به گونه‌اي موثر برآورده شدن SLAها را مدیریت و ضمانت کنند.

جداسازی مدیریت در شبکه سرویس‌های VPN و شبکه انتقال VPN
تا كنون لایه‌های جداسازی شده شبکه‌ي سرویس‌ها و شبکه‌ي انتقال به وسیله‌ي ITU-T که سرویس‌های IP و چارچوب پشتیبانی از IPVPN را گسترش دادند، معرفی شده‌اند. این مفهوم لایه‌ای به عنوان یک روش بنيادين برای مدل مدیریت شبکه و QoS شناخته می‌شود.
با این مفهوم مدیریت شبکه (و QoS)، اندازه‌گیری‌های کارایی، توابع تولید آلارم و مانیتور کردن، می‌توانند بر مبنای اهداف پارامتری دارای انتخاب، اندازه‌گیری‌های استاندارد موجود و ابزارهای مدیریتی موجود باشند. نقاط مرجع که رابط‌های مدیریتی پیاده‌سازی شده برای توابع گوناگون هستند، باید برای مانیتور کردن و اندازه‌گیری‌های QoS، تبادل اطلاعات QoS و فعل وانفعالات اجزای مختلف به کار برده شوند. سیستم‌های مدیریت QoS و نقاط مرجع قرار است به طور خاص برای انواع مختلف ترافیک انتها به انتها و برای ویژگی‌های ارتباطی VPNها طراحی شوند.

[Admin]

مدیریت شبکه های خصوصی مجازی بر مبنای پروتکل اینترنت (IP) (بخش پنجم)


ایجاد چارچوبی برای مانیتورکردن نهفته‌ي پارامترهای کیفیت خدمات در شبکه‌های خصوصی مجازی مبتني بر پروتکل اینترنت
در این بخش به طور مختصر یک چار چوب برای مانیتور كردن نهفته‌ي کارایی پارامترهای QoS در شبکه‌های IP و به طور خاص در شبکه‌های خصوصی مجازی ارايه مي‌شود.
فعالیت‌های اندازه‌گیری باید تابع سیاست‌های اپراتور و اهداف مدیریت کارایی باشند، که آن‌ها نیز به توافقات سطح سرویس (SLA) و نیازهای عملیاتی وابسته هستند و دلیلی برای انجام مانیتورینگ گسترده‌ي کارایی به خودی خود، وجود ندارد.
معماری پپش‌نهاد شده مبتني بر یک روش in-service است که در بخش‌های بعدی مفهوم آن توضیح داده خواهد شد. در این روش پارامترهای ترافیکی کاربر به وسیله مانیتورینگ اختصاصی اندازه گیری می‌شوند. توابع مانیتورینگ، یک بخش مجتمع از عناصر عادی شبکه را تشکیل می‌دهند. شبیه‌سازی‌هایی که مبتني بر ثبت مسیر ترافیک تست با استفاده از ردیابی هستند، نتایج امکان‌پذیر را در استفاده از این مدل نشان می‌دهند. در انتهای این بخش بعضی از نتایج پیاده‌سازی توصیف خواهد شد.
اپراتورهای مخابرات تمایل دارند که خدماتي از مخابرات در شبکه‌های IP ایجاد کنند، که نیازمندی‌های کیفیت خدمات را به طور جدی برآورده سازند. در نتیجه یک اپراتور بايد به ابزار کارآمدی برای مانیتورینگ و کنترل پارامترهای کارایی مربوط دست‌رسي داشته باشد. به علاوه داشتن دانش كافي درباره رفتار شبکه برای اهداف عملیاتی، بازبینی و تحقیق درباره برآورده شدن توافقات سطح خدمات، بسيار حياتي و مهم است. تا كنون در شبکه‌های تلفنی سنتی از روش ایجاد دامنه‌های خصوصی منطقی استفاده شده است. اما از آن‌جایی که پروتکل اینترنت امروزه در همه جا، از جمله مخابات عمومي، حاضر است، شبکه‌های خصوصی مجازی مبتنی بر IP به عنوان یک روش مهم برای تهیه‌ي خدمات مخابراتی معتبر و ایمن مورد ملاحظه قرار گرفته‌اند.
به طور کلی روش‌های اندازه گیری و مانیتور کردن پارامترهای کارایی شبکه به دو دسته تقسیم می‌شوند:
1- روش‌های پسیو مانندsnifferهای متداول و وسایل اندازه‌گیری ترافیک
2- روش‌های اکتیو که درآن بسته‌های مخصوص کنترل یا تست تولید می‌شوند. (مانند(ping در روش‌های پسیو، به منظور ذخیره‌سازی و جمع آوری اطلاعات، بسته‌ها به ترتیب از فیلدهای مختلف هدر بسته، دريافت مي‌شوند. snifferهای متداول، تحلیل‌گرهای پروتکل و وسایل اندازه‌گیری ترافیک همگی بر این اصل بنا شده‌اند (مانند RMON Probes,NetFlow,NetraMet,ntop,tcpdump). بر خلاف روش‌های اکتیو، مانیتورهای پسیو بار ترافیکی اضافی به شبکه تحمیل نمی‌کنند. گذشته از این ويژگي non-intrusive بودن، روش‌های پسیو را قادر به جمع‌آوری اطلاعات جزيي فراوان مي‌كند. افزون بر اين ثبت و نوشتن تاریخچه از ردپای بسته‌ها در شبکه‌های با سرعت بالا بيش‌تر به مقدمات مخصوصی برای جمع‌آوری، ذخیره و پردازش حجم زیادی از داده‌ها نیاز دارد. در عوض روش‌های اکتیو بر مبنای تزریق بسته‌های probe با استفاده از ICMP عمل مي‌كنند.مثال‌هایی از ابزارهای مبتني بر روش‌های اکتیو عبارت‌اند از: PingER، Active Measurement Project(AMP) ، National Internet Measurement Infrastructure، surveyor و RIPE’s test traffic project.
یک روش گسترش یافته که در طبقه}بندی قبلی نمی گنجد استفاده از پروتکل مدیریتی SNMP برای بازیابی اطلاعات از MIBهای عناصر شبکه است. بسیاری از ابزارها مانند Multi Router Traffic Grapher بر مبنای رای‌گیری (polling) از شمارنده‌های ترافیک در MIBهای روترهاست.RMON که گامي به سوي مانیتورینگ توزیع شده به شمار مي‌آيد، به صورت یک MIB سازمان‌دهی شده است. بنابراین یک مدیر می‌تواند با استفاده از SNMP، اطلاعات ترافیکی را از Probeها به دست آورد.
روش‌های مانیتورینگ کارایی همچنین به دو گروه in-service یا out-of-service تقسیم‌بندی مي‌شوند. روش‌های out-of-service فقط به ترافیک تستی که به طور خاص تولید شده است، اعمال می‌شوند، درحالی که هدف از روش‌های in-service مانیتور کردن ترافیک واقعی کاربر است: مانیتورینگ in-service ممکن است با استفاده از روش‌های مختلف اکتیو يا روش‌های پسیو غیرمداخلانه انجام شود. در دنباله‌ي اين مقاله تمركز اصلي بر روي مانیتورینگ in-service خواهد بود و مدلي برای مانیتور كردن بسته‌هایی که به منظور برآورد پارامترهای کارایی به ترافیک کاربر اضافه شده اند، پیش‌نهاد می‌شود. این بسته‌های مانیتورینگ اختصاصی که حامل اطلاعات OAM(Operation,Administration,Maintenance) هستند. ممکن است به عنوان یک روش in-service اکتیو مورد توجه قرار گیرند.
ITU-T سلول‌های OAM را برای مانیتورینگ کارایی و خرابی در شبکه‌های ATM، استاندارد کرده است. اما بر خلاف ATM، IP یک پروتکل بدون اتصال با طول بسته متغیر است که به احتمال زياد مهم‌ترین دلیل برای ناچیز بودن پروتکل‌های مشابه در دنیای IP است.

[Admin]

مدیریت شبکه های خصوصی مجازی بر مبنای پروتکل اینترنت (IP) (بخش ششم)

6.1. معماری ایده­ي اصلی، توسعه­ي یک ساختار مناسب برای مانیتور کردن پارامترهای کارایی شبکه در شبکه­های IP است. بعضی معتقدند که اندازه­گیری­ها و توابع مانیتورینگ باید مطابق با سیاست اپراتور و اهداف مدیریت کارایی محاسبه و با نوع سرویس عر ضه شده، تنظیم شود. یک اپراتور شبکه افزون بر آگاهی از رفتار شبکه­، باید به مانیتور کردن توافقات سطح سرویس (SLA)ها و کیفیت سرویس اشراف کامل داشته باشد. این مهارت­­ها به وسیله­ي سیستم­های مدیریت شبکه­ي مبتنی بر مشتری پشتیبانی می­شود. به علاوه، یک سیستم مانیتورینگ قدرت­مند که بتواند کارایی وا قعی شبکه را منعکس کند، باید قادر به ایجاد توابع تخصیص ظرفیت پویا باشد.
در این مقاله IPVPNها را به عنوان مبنای مطالعه انتخاب شده­اند. همان­طور که در شکل 7 دیده می­شود، در مکان­شناسی فرض شده، یک شبکه­ي هسته، به وسیله­ي گره­های کناری provider و گره­های کناری مشتری احاطه شده است. شبکه­های خصوصی مجازی می­توانند به روش­های مختلف پیاده­سازی شوند. شبکه­های مبتنی بر روتر که "تونل­" نامیده می­شوند، به وسیله اتصالات نقطه به نقطه­ي روی­ هم قرار گرفته، ایجاد می­شوند. با استفاده از کپسوله کردن مسیر کلی یا IPSec، MPLS وعده می­دهد که چارچوب انعطاف­پذیرتر و توسعه­­پذیرتری را برای VPNهای مبتنی بر سويیچ­های سلولی، یا محیطي ترکیب شده از روترها و سويیچ­ها ایجاد کند.


http://www.systemgroup.net/admin/images/attachs/F1.JPG



شکل 7: یک شبکه­ي مرکزی مشترک بین همه­ي گره­ها


6.2. مانیتورکردن برمبنای سیاست
در روش نهفته که در ادامه با جزيیات بیش­تری تشریح خواهد شد، گره­های مانیتورینگ باید بتوانند به طور دینامیک و خودکار، مطابق سیاست­ها و کمک­های اپراتور پیکربندی شوند. شبکه­هایي که دارای راهنمای سرویس هستند، یک معماری توافقي و عملی برای پیاده­سازی مانیتورینگ کارایی بر مبنای سیاست دارند. یک اپراتور باید بتواند درباره­ي زمان، چگونگی و محل قرارگیری توابع مانیتورینگ در شبکه، تصمیم­گیری کند. از آن­جا که چندین شبکه­ي منطقی، کلاس­های سرویس مختلف، پارامترهای گوناگون و مقادير زیادی از عناصر شبکه در اين تصميم‌گيري قرار مي‌گيرند، رابط مدیریتی در این محیط پیچیده، بايد بر حسب سیاست‌های مختلف مانیتورینگ بیان شود، اين در حالی است که جزيیات سطح پایین، پوشیده هستند.

6.3.بسته های OAM نهفته
هدف از مانیتورینگ نهفته‌، اندازه‌گیری پارامترهای کارایی شبکه بر مبنای ترافیک واقعی کاربر است. این بسته‌های مانیتورینگ اختصاص داده شده یا همان بسته‌های OAM، بین بلاک‌های بسته‌‌ی داده‌هاي معمولی جای داده می‌شوند. گره فرستنده بسته‌های مانیتورینگی تولید می کند که اطلاعات مانیتورینگ را بین هر N بسته‌ي کاربر، به طور متوسط، حمل می‌کند. گره گیرنده بسته‌های مانیتورینگ را کشف و اطلاعات را اضافه می کند. سپس آن‌ها را به گره مبدا برمی‌گرداند. پردازش، ذخیره‌سازی و تحلیل ممکن است به وسیله‌ي سرورهای اختصاصی برای کل شبکه صورت گیرد. هم‌زمان‌سازی کلاک‌ها در گره‌های مانیتورینگ، برای اندازه‌گیری تاخیر یک طرفه، براي مثال می‌تواند به وسیله‌ي سیستم موقعیت‌یاب GPS و پروتکل زمانی شبکه (NTP) صورت گیرد. با استفاده از این روش می‌توان نتایج زیر را به دست آورد:
·تعداد بسته‌های گم شده بین گره‌های گیرنده و فرستنده و نرخ گم شدن بسته‌ها در طول دوره‌ي اندازه‌گیری
·طول پریودهای بدون loss و پریودهای loss که بر حسب تعداد بلاک‌های OAM پشت سرهم - شامل بسته های گم شده و تعداد بلاک های OAM که بدون loss - بیان شده است.
·نمونه‌هایی از تاخیر انتقال و تغییرات تاخیر، بین گره‌های فرستنده و گیرنده.
·برآوردی از ظرفیت استفاده شده (throughput) بین هر جفت از گره‌های کناری فرستنده –گیرنده. براي اين كار بايد طول متوسط بسته را به دست آورد.
یک قالب از بسته‌های OAM پیش‌نهادی در شکل 8 نشان داده شده است. هِدِر IP معمولی بسته‌های OAM شامل نشاني مقصد گره گیرنده (خروجی) و نشاني مبدا گره فرستنده (ورودی) است. یک شماره، ترتیب بسته‌های OAM گم شده را کشف می‌کند. گره ورودی تعداد کلی بسته‌های فرستاده شده (به طور تجمعی) و زمان جاری را در مكان‌های مربوط می‌نویسد. گره خروجی تعداد کلی بسته‌های دریافتی (به طور تجمعی) و زمان جاری را در مكان‌های هدر مربوط قرار می‌دهد.


An OAM block consisting of N packets



http://www.systemgroup.net/admin/images/attachs/F7.JPG



شکل 8: دو بسته OAM یک بلوک OAM (به طور متوسط N بسته کاربر) را در بر می‌گیرند.


6.4. نیازمندی‌های شبکه‌های بدون اتصال
مانیتورینگ کارایی در شبکه‌های مبتني بر پروتکل‌های بدون اتصال مانند IP اهمیت زيادي دارد. در پروتکل‌های اتصال‌گرا مانند ATM، هر بسته یا سلول وابسته به یک اتصال منطقی در یک مسیر از پیش تعیین شده قرار مي‌گيرد. یک دیتاگرام IP فقط آدرس‌های شبکه‌ي مبدا و مقصد را حمل می‌کند و هیچ تضمینی وجود ندارد كه هر دیتاگرام در یک session همان مسیر را از فرستنده به گیرنده طی کند و به همان ترتیب اولیه برسد. در مقایسه با ATM يك تفاوت دیگر این است که IP اجازه مي‌دهد بسته‌ها طول متغیر داشته باشند. به همين دليل باید هنگام برآورد، نرخ‌های انتقال و نرخ گم شدن بسته‌ها مورد توجه قرار گیرد.
در نتیجه در به کاربردن بسته‌های OAM برای نظارت بر پارامترهای کارایی در شبکه‌های IP یک گره ورودی (فرستنده) بايد بتواند گره‌های خروجی (گیرنده) را که بسته باید از طریق آن‌ها عبور کند، پیدا کند. اين كار به طور خاص با استفاده از آدرس‌های IP مقصد در هدر بسته صورت مي‌گيرد. به طور مشابه یک گره گیرنده باید تعیین کند که یک بسته‌ رسيده با توجه به آدرس مبدا IP، از کدام گره فرستنده، ارسال شده است. به علاوه، گره گیرنده باید بتواند اندازه‌ي متوسط بسته برای بلوک‌های OAM را محاسبه كند تا در برآورد بهره‌وری و مصرف از اين اطلاعات استفاده شود. گرچه ممکن است حالت عمومی پیچیده باشد، این روش در شبکه‌های خصوصی مجازی که مكان‌شناسي، به طور كامل شناخته و مسیریابی محدود شده است، عملی است.

[Admin]

مدیریت شبکه های خصوصی مجازی بر مبنای پروتکل اینترنت (IP) (بخش هفتم و پاياني)

مانیتور کردن ترافیک در شبکه های خصوصی مجازی
هدف از مانیتور کردن ترافیک، اندازه گیری و تخمین lossها، تاخیرها و بهره‌وری برای ترافیک IP در شبکه‌های خصوصی مجازی و بین گره‌های کناری provider یا گره‌های کناری مشتری بر مبنای یک مكان‌شناسي عمومی که در شکل 10 نشان داده شده، است.
همان‌طور که پيش از اين بيان شد، طبیعت connection-less بودن IP مساله‌اي اساسی در طراحی سیستم‌های مانیتورینگ است. برای استفاده از بسته‌های OAM در شبکه‌های IP به توابع جست‌و‌جو (look-up)، لازم است که گره‌های مانیتورینگ خروجی (و ورودی) را تعیین کنند. اگرچه در شبکه‌های خصوصی مجازی، که به وسیله‌ي تونل‌های نقطه به نقطه پیاده سازی شده است، آدرس گره خروجی در یک هدر IP اضافی حمل می‌شود. براي اين كار، آدرس، به گره مانیتورینگ خروجی صحیح با آدرس مقصد IP در هدر بسته منطبق می‌شود. در موارد عمومی‌تر یک رویه‌ي مشابه ممکن است به توابع جست‌وجوی پیچیده‌تری نیاز داشته داشته باشد.

عملیات گره های مانیتورینگ
توابع مانیتورینگ وقتی فعال می‌شوند که مجموعه‌ای از وضعیت‌های خاص که سیاست مانیتورینگ اپراتور را به طور کامل بیان می‌کنند، پوشانده شوند. براي کلاس‌های يك سرویس مشخص باید در طی پریودهای زمانی مشخصی مانیتور شوند. یک روتر وقتی به عنوان یک گره مانیتورینگ ورودی عمل می‌کند، باید عملیات مانیتورینگ را برای هر VPN انجام دهد (و به طور مشابه به عنوان یک گره مانیتورینگ خروجی). روتر باید شمارنده‌های جداگانه‌ای را برای هر گره خروجی مانیتورینگ به دست آورد تا بتواند توالی تعداد بسته‌هایی را که به هر یک از گره‌های گیرنده فرستاده شده‌اند، نگه‌داری کند. بسته‌های OAM به وسیله‌ي گره ورودی، تولید می‌شوند و به طور متوالی در داخل ترافیک کاربر بین بلوک‌های بسته‌های کاربر قرار می‌گیرند، به طوری که آدرس مقصد به گره مانیتورینگ خروجی اشاره کند. آدرس مبدا با آدرس گره مانیتورینگ ورودی هماهنگ می‌شود. شکل 9payload بسته OAM را نشان می‌دهد. یک روتر که به عنوان گره مانیتورینگ خروجی عمل می‌کند، باید تعیین کند که بسته‌های رسیده کاربر از کدام گره ورودی رسیده‌اند، با توجه به آدرس مبدا در هدر بسته. هر گره گیرنده باید یک شمارنده برای هر گره ورودی نگه‌دارد و عملیات زیر را انجام دهد:


بسته‌های OAM را از طریق شماره پروتکل منحصر به فرد در هدر بسته پیدا می‌کند.
یک مهر زمانی در بسته‌های OAM قرار دهد که نشان دهنده‌ي زمان جاری در گره خروجی باشد.
مقدار جاری شمارنده را در بسته وارد کند تا ردپای شماره بسته‌های دریافت شده از گره خروجی را نشان داده شود.
بسته OAM را به گره ورودی فرستنده برگرداند.



http://www.systemgroup.net/admin/images/attachs/FG1.JPG



شکل 9: قالب یک بسته OAM


نتیجه گیری روش مانیتورینگ نهفته
داده‌های اندازه گیری شده که به وسیله‌ي بسته‌های OAM حمل می‌شوند یا در گره‌های مربوط ذخیره می‌شوند، ممکن است به وسیله‌ي گره ورودی آغازین یا یک سرور تنها، پردازش شوند. اختلاف بین تعداد بسته‌های فرستاده شده (Number Of Sent Packets) در بسته nام OAM و بسته‌ي n-1ام OAM تعداد بسته‌های فرستاده شده در یک بلوک OAM را مشخص می‌کند. اين محاسبات در مورد تعداد بسته‌های دریافت شده (Number Of Received Packets) نيز صادق است (شکل 9). بنابراین اختلاف این دو نشان‌گر تعداد بسته‌های گم شده در بلوک OAM است. یک نمونه از تاخیر انتقال بین یک گره فرستنده و یک گره گیرنده به وسیله اختلاف بین TimeAtReceiver و TimeAtSenderدر یک بسته OAM داده می‌شود.بسته‌های مانیتورینگ گم شده از طریق شماره‌های ترتیب گم شده کشف می‌شوند.
هیچ تضمینی وجود ندارد که همه بسته‌ها در یک رشته بین دو گره یک مسیر را در کل دوره‌ي زمانی دنبال کنند. یک راه برای تشخیص تغییرات در مسیر این است که از ابزاری استفاده کنیم که به طور متناوب مسیر بین دو گره کناری را ثبت کند. اگر بسته‌ها به ترتیبی غیر از ترتیب فرستاده شدن دریافت شدند، اختلاف در ترتيب می‌تواند باعث شود که بلوک‌های OAM شامل بسته‌های بیش‌تر یا کم‌تری ازتعداد N بسته پیش‌بینی شده باشند. بنابراین یک بسته که متعلق به بلوکي در فرستنده است، ممکن است به دلیل تغییراتی در مسیر، در یکي از بلوک‌هاي مجاور در گره گیرنده دیده شود. اگر در همان زمان بسته‌ها در این بلوک‌ها گم شوند تعیین این‌که در کدام بلوک loss اتفاق افتاده، همیشه امکان‌پذیر نيست. اگرچه از آن‌جایی که مقادیر شمارنده در بسته‌های OAM تجمعی هستند، تلفیق تعدادی از بلوک‌های پشت سر هم در واحدهای بزرگ‌تر امکان‌پذیر است.

http://www.systemgroup.net/admin/images/attachs/FG2.JPG


شکل 10: یک مكان‌شناسي برای شبکه‌های خصوصی مجازی





نتایج
شبکه‌های خصوصی مجازی با داشتن معماری مدیریتی مناسب و پیاده‌سازی صحیح، می‌توانند برای سازمان‌ها مفید باشند، به طوری که دیگر به داشتن یک شبکه خصوصی کامل که منابع زیادی را برای پیاده‌سازی استفاده می‌کند، نیازی نباشد. از طرفی وقتی یک شبکه‌ي خصوصی مجازی برای داشتن ارتباط با دنیای اینترنت بر روی backbone اینترنت سوار می‌شود و بسته‌های آن آدرس IP می‌گیرند، مساله اشتراک منابع پیش می‌آید و ممکن است، در اختیار قرار دادن منابع برای درخواست‌ها در همه‌ي زمان‌ها امکان‌پذیر نباشد. بنابراین باید توابعی را برای تضمین کیفیت سرویس در این شبکه‌ها به کار ببریم. بنابراین ضرورت مدیریت این شبکه‌ها در مقایسه با شبکه‌هایی که براي کیفیت سرویس تضمین پایین‌تری دارند، بسيار محسوس است.