• طبقه بندی مقالات
    • محدودیت های اینترنت کنونی و اصول طراحی اینترنت آینده
      مقدّمه
      نیازهای جدید به اینترنت باعث ایجاد نیاز به سرمایه گذاری های روزافزون در زیرساخت های این شبکه شده است، اما با این حال تحقیقات جدید حاکی از آن است که حتی افزایش پهنای باند هسته اصلی این شبکه به پتابیت در ثانیه نیز قادر به رفع نیازهای کیفی کنونی از جمله: سرویس های حیاتی همچون اپلیکیشن های سلامت الکترونیکی، سرویس های ابری، شبکه های اجتماعی جدید مثل محیط های همه جانبه سه بعدی، اپلیکیشن های جدید تجاری و تراکنشی، سرویس های جدید بر پایه موقعیت و ... نمی باشد.
      گروه معماری اینترنت آینده (FIArch) بعد از انتشار مقاله ای مبنی بر محدودیت های بنیادی معماری اینترنت کنونی، گام بعدی را در جهت انتشار مشخصات اصول طراحی برای معماری اینترنت در این مقاله برداشته است.
      اصول طراحی، نقش مهمی در معماری اینترنت به عنوان ایجاد کننده تصمیمات مهندسی چه در مرحله مفهومی و چه در مرحله عملیاتی (به صورت سیستم های مخابراتی) ایفا می کند که یکی از نقاط قوت آن در مقایسه با دیگر معماری ها که صرفاً بر اساس مدل سازی طراحی می شوند به حساب می آید. در طراحی سیستم های مخابراتی کلاسیک، اصول طراحی را در نظر نمی گیرند و مستقیماً از روی الزامات آنها را مدل سازی می کنند. اما در طراحی اینترنت، فرموله کردن اصول طراحی از مهمترین ارکان در فرایند طراحی اینترنت به حساب می آید که ما را به ویژگی های مدل طراحی هدایت می کند. در این مقاله سعی شده است که اصول طراحی اینترنت امروز مورد تجزیه و تحلیل قرار گیرد و اصول طراحی اینترنت آینده پیش بینی گردد.


      1. محدودیت های بنیادی معماری اینترنت کنونی
      1.1. محدودیت در پردازش داده ها
      • عدم توانایی در توصیف اِشکال، دلایل ایجاد و چگونگی رفع آن به هاست ها، در صورت بروز خرابی در اینترنت کنونی
      • فقدان روش های کلی برای تشخیص رفتارهای بد (که ممکن است به دلیل منافع خودخواهانه یا سوء نیت باشد) و تسکین اثرات آنها، که می تواند برای روابط میان کاربران و ارائه دهندگان مخرب باشد.
      • عدم وجود هویت داده ها و سرویس ها که باعث حرکت چندین باره داده ها در زیرساخت های مخابراتی شده و به بهره وری سیستم های مخابراتی آسیب وارد می کند.
      • فقدان روش هایی برای پردازش قابل اعتماد و اطمینان زیرساخت سیستم ها، شبکه ها و سرویس های ضروری همچون بهداشت و حمل و نقل
      • عدم وجود پردازش بلادرنگ (Real-time) برای بسیاری از اپلیکیشن ها مثل شبکه سنسورها

      2.1. محدودیت در ذخیره داده ها
      • فقدان مدیریت ذخیره سازی آگاه از محتوا؛ تصمیم گیری در مورد ذخیره سازی، مدیریت، استخراج، نوشتن/پاک کردن سریع برای انواع مختلف داده (از لحاظ محتوا) را پشتیبانی نمی کند.
      • عدم وجود حریم شخصی مناسب برای کاربرها و داده های مختلف، به علت نبود مدیریت ذخیره سازی آگاه از محتوا؛
      • فقدان یکپارچگی، قابلیت اعتماد و اطمینان داده ها به منظور حفظ امنیت و حفاظت از آنها.
      • فقدان سیستم کَش کردن و آینه کردن (caching & mirroring) مؤثر برای مقابله با پدیده هایی همچون افزایش ناگهانی ترافیک برای داده های خاص (flash crowding)؛ پردازش بسته ها در لایه شبکه، اجازه پردازش اطلاعات درون بسته ها را نمی دهد و بازرسی درون بسته ها در بین مسیر نیز می تواند اشکالات بنیادی در مقیاس پذیری، مقاومت و امنیت ایجاد کند.
      • فقدان راه حل های ذخیره سازی یکپارچه و متحد برای دسترسی به داده ها در منابع ذخیره توزیع شده متحد، به خصوص از دید فعالیت های مشترک (collaborative activities) و ترکیب سرویس های ad-hoc و یا داده های جمع آوری شده از سنسورها

      3.1. محدودیت در انتقال داده ها
      • فقدان سیستم انتقال ترافیک مؤثر بر پایه محتوا؛ CDN با استفاده از کَش کردن توزیع شده اطلاعات، تا حدودی بر مشکل انتقال اطلاعات چند رسانه ای که نسبت به دیگر اطلاعات، داده های بیشتری را تولید می کنند، فائق آمده است اما قابلیت توسعه به کل اینترنت را ندارد.
      • فقدان یکپارچگی در تجهیزات با منابع محدود به عنوان ورودی های قابل آدرس دهی مستقل (autonomous addressable entities) به اینترنت؛ محیط هایی همچون شبکه سنسورها و محیط های ماشین به ماشین (machine-to-machine) با محدودیت هایی در ظرفیت پردازش، ذخیره سازی و انتقال روبرو هستند که فقط برخی از پروتکل های مهم را برای ادغام با اینترنت به طور نسبی پیاده سازی می کنند.
      • الزامات امنیتی در لینک های انتقالی؛ در لینک های انتقال کافی نیست که فقط از داده ها محافظت شود بلکه باید از خود لینک ارتباطی نیز (بسطه به وابستگی و تعاملاتش با دیگر بخش ها) محافظت شود.

      4.1. محدودیت در کنترل پردازش، ذخیره سازی و انتقال سیستم ها و توابع
      • فقدان کنترل انعطاف پذیر و وفق پذیر؛ سیستم باید در هنگام مواجهه با اتفاقات داخلی و خارجی، عکس العملی مناسب که از لحاظ زمانی و هزینه ای مؤثر است از خود نشان دهد (انعطاف پذیری).
      • فقدان معماری مرجع برای بخش کنترلی IP؛ بخش داده IP نسبتاً ساده است اما با اجزاء کنترلی زیادی ادغام شده که گاهاً با هم تلاقی دارند و منجر به تعاملات هرچه پیچیده تر آنها در طول زمان شده است.
      • فقدان کنترل ازدحام مؤثر؛ کنترل ازدحام ممکن است به اصل انتها به انتها صدمه وارد کند.
      • پشتیبانی از تحرک؛ مشخصه مکان (Location) در پروتکل TCP برای کاربر متحرک وجود ندارد. به علت تحرک در شبکه بی سیم، بسته ها می توانند به علت تداخل گم شوند.


      2. اصول طراحی اینترنت کنونی و بسط آنها به اینترنت آینده
      اصول طراحی به مجموعه ای از قوانین ساختاری و رفتاری که یک طراح یا معمار می تواند بر اساس آن بهترین ساختار را برای اجزای مختلف معماری ارائه و قوانین بنیادی و تغییر ناپذیر با زمان را توصیف کند، گفته می شود.
      قوانین ساختاری و رفتاری نیز به قوانین توافق شده ای گفته می شود که به هدایت طراح یک سیستم در ایجاد یک ساختار مناسب و قابل قبول در زمان طراحی و یک رفتار مناسب و قابل قبول در زمان اجرا کمک می کند.
      اصول طراحی اینترنت عبارتند از :
      1.2. اصل پشتیبانی از عدم تجانس (Heterogeneity support)
      عدم تجانس یکی از مهمترین ویژگی های اینترنت از بدو شروع به کار این شبکه به شمار می آید.
      ترکیب ترافیک در تجهیزات و nodeها، الگوریتم های زمانبندی روتر و مکانیزم های مدیریت صف، پروتکل های مسیریابی، مالتی پلکسینگ های مختلف، لایه های زیرین اتصال (اتصال نقطه به نقطه، اتصالات دسترسی چندگانه، بی سیم و غیره) در زمان ها و مکان های مختلف و همچنین ISPهای مختلف هر کدام با سیاست های جداگانه، همه از عدم تجانس در شبکه اینترنت حکایت دارند.
      اصل پشتیبانی از عدم تجانس باید به عنوان یک اصل در طراحی اینترنت در نظر گرفته شود. (RFC1958)
      2.2. اصل مقیاس پذیری و تقویت (Scalability & the Amplification)
      اصل مقیاس پذیری به توانایی یک سیستم محاسباتی (نرم افزاری یا سخت افزاری) به ادامه کار خود بدون تغییر در سیستم و بدون تأثیر در عملکرد آن، وقتی که سایز و حجم ورودی ها تغییر می کنند، گویند. مثل زیاد شدن تعداد node ها یا ASها، زیاد شدن تعداد اتصالات، زیاد شدن تعداد هاستها وغیره. (RFC1287) و (RFC1958)
      اصل تقویت: در بسیاری از شبکه های با اتصالات داخلی فراوان حتی کوچکترین چیزها می توانند منجر به اتفاقات بزرگ شوند. حتی اختلالات کوچک در ورودی یک فرایند می تواند خروجی سیستم را به ناپایداری ببرد. در نتیجه پیچیدگی می تواند اختلالات کوچک را تقویت کند و مهندس طراح باید مطمئن باشد که چنین اختلالاتی به ندرت در سیستم اتفاق می افتند. (RFC3439) و (RFC3439)
      3.2. اصل Robustness
      تعریف: میزان عملکرد صحیح سیستم در شرایط محیطی اضطراب آور و یا ورودی های استثنایی.
      اصل Robustness بر پایه این شرط نهاده شده است که هر پروتکل باید بتواند با دیگر پروتکل ها همکاری داشته باشد و هر کدام باید « آزاد در قبول و دریافت و محتاط در ارسال » باشند. هدف اساسی در این اصل، افزایش همکاری بین پروتکل های شبکه می باشد به ویژه در مواجهه با مشخصات مبهم و ناقص. (RFC760) و (RFC791)
      همچنین اصل Robustness در بخش نرم افزار اینترنت به این صورت تمرکز دارد: نرم افزار باید به گونه ای نوشته شود که بتواند با هرگونه خطای ممکن دست و پنجه نرم کند. به طور کلی بهتر است فرض شود که شبکه پر از ورودی های مخرب است که برای ایجاد بدترین اختلالات طراحی شده اند. با این فرض، طراحی ما یک نوع طراحی حفاظت شده مناسب خواهد بود. (RFC 793) و (RFC1122)
      اصل Robustness: در ارسال محتاط باش و در دریافت و قبول کردن از دیگران حتی محتاط تر!
      این اصل همچنان باید در طراحی اینترنت آینده حفظ شود اما نه به قیمت از دست رفتن قابلیت اعتماد (آیا برای یک دریافت کننده مناسب است که اطلاعات جعلی دریافت کند؟!) و همچنین امنیت (سیستمی که 100 درصد CPU خود را به پاسخگویی به اطلاعات جعلی می پردازد بلااستفاده می شود).
      بسیار مطلوب است اگر حامل های اینترنت بتوانند از هویت و امنیت کل ترافیک محافظت کنند اما به عنوان یک الزام در معماری آنها به حساب نمی آید. محرمانه نگه داشتن و حفظ امنیت جزو مسئولیت های کاربر انتهایی می باشد. (RFC1958)
      بنابراین این اصل باید به یک اصل ساختاری خود محافظ تغییر کند.
      4.2. اصل مطابقت (Adaptability)
      مطابقت به تغییر باید در تمامی سطوح نرم افزار هاست های اینترنت طراحی شود. (RFC1122) به عنوان مثال اگر در یک پروتکل خاص چهار کد خطای ممکن تعریف شده است، نرم افزار نباید در مواجهه با پنجمین کد از کار بیفتد.
      دومین بخش از این اصل حاکی از آن است که اگر نرم افزار یک هاست دارای نواقصی باشد و امکان ایجاد خطا در پروتکل های شبکه را داشته باشد، دیگر هاست ها باید بتوانند با هم همکاری کرده و میزان خسارت هایی که هاست مخرب می تواند بر تسهیلات مشترک ارتباطی بین آنها داشته باشد را محدود کنند.
      باید توجه داشت که هر دو اصل Robustness و مطابقت برای تمامی لایه های شبکه صادقند از جمله لایه اپلیکیشن.
      5.2. اصل ماژول بندی (modularization)
      سیستم های ارتباطاتی از اصل ماژول بندی برای تجزیه قابلیت های ارتباطاتی به ماژول های مختلف با رابط های مناسب استفاده می کنند.
      اصل لایه بندی در طراحی پروتکل شبکه مزیت های مفهومی و ساختاری متنوعی را در اختیار ما قرار می دهد، از جمله: کاهش پیچیدگی ها، ایزوله کردن قابلیت ها، قابلیت استفاده مجدد از ماژول های پروتکل و غیره. هر لایه با استفاده از سرویس هایی که از لایه پایین تر خود می گیرد سرویس هایی را به لایه بالاتر خود می دهد. وظیفه هر لایه به طور کامل انجام می گیرد و سپس واحد داده پروتکل به لایه بعد فرستاده می شود.
      در این میان برخی از پروتکل ها و جود دارند که اصل لایه بندی را نقض می کنند و دست به تغییر محتوای بسته ها که خارج از حوزه وظیفه لایه خود می باشد، می زنند. از این جمله می توان به پروتکل های NAT و Firewall اشاره کرد.
      این نقض به این علت به وجود می آید که لایه بندی در شبکه به صورت عمودی انجام می شود. اخیراً روش های فراوانی برای فرار از لایه بندی عمودی پیشنهاد شده است مثل مدل های بین لایه ای، مدل بدون لایه، مدل بر پایه نقش و مدل افقی.
      6.2. اصل چندریختی (Polymorphism) در اینترنت آینده (به عنوان توسعه ای بر اصل ماژول بندی)
      چندریختی به قابلیت گرفتن شکل های مختلف گفته می شود. در علم کامپیوتر به تابعی گفته می شود که می تواند به مقادیری در انواع مختلف اعمال شود. این قابلیت می تواند متُدها را بر روی یک شئ بدون اطلاع از نوع آن پیاده کند.
      در این اصل اشیا از کلاس های متفاوت می توانند پاسخ های متفاوت به یک تابع داشته باشند که باعث ایجاد قابلیت های متفاوت فقط با صدا کردن یک تابع می شود. (مطابق با عملکرد قطعه کدهای ذیل)




      اصل مذکور در طراحی اینترنت آینده این اجازه را می دهد که اجزا یا اشیاء خود مختار تحت شرایط مختلف رفتار تابعی یا غیر تابعی مختلف از خود نشان دهند.

      7.2. اصل جفت شدگی (اتصال) سست (Loose coupling)
      جفت شدگی به میزان وابستگی هر ماژول به ماژول های دیگر تلقی می شود.
      جفت شدگی سست به اتصال اجزای یک سیستم گفته می شود که در آن میزان وابستگی بین اجزا به حداقل ممکن رسیده باشد.
      بیشترین تعداد تغییراتی که در المان های یک سیستم می توان اعمال کرد، به طوری که در عملکرد سیستم اثرات چندانی مشاهده نشود، میزان سست بودن جفت شدگی را تعیین می کند. از جمله این تغییرات می توان به اضافه و کم کردن المان ها، تغییر نام و برنامه ریزی مجدد المان ها و تغییر در شیوه اتصال بین آنها اشاره کرد.
      بیشتر اتفاقات غیر خطی در سیستم های بزرگ به علت جفت شدگی های فراوان اتفاق می افتند. جفت شدگی بین اجزا می تواند به صورت عمودی یا افقی باشد. در بحث شبکه جفت شدگی افقی بین پروتکل ها در یک لایه و جفت شدگی عمودی بین لایه ها وجود دارد.
      برای حفظ هماهنگی بین اجزای گوناگون یک سیستم بهتر است برای شرایط اضطراب آور، همبستگی بین اجزا را افزایش داد تا بتوان عملکرد مناسب را از سیستم انتظار داشت. بنابراین تعیین میزان جفت شدگی در زمان اجرا می تواند راه حل خوبی برای فائق آمدن به این مشکل باشد.
      اما به طور کلی خصوصاً با افزایش سیستم های توزیع شده با تعاملات پیچیده بین آنها، امکان پیدایش اتفاقات غیر خطی در سیستم ها افزایش پیدا کرده است که بیشتر به علت جفت شدگی زیاد بین اجزاء آنها می باشد. جفت شدگی سست می تواند از انتشار این اتفاقات در سیستم جلوگیری نماید.
      مزایا:
      از آنجایی که در جفت شدگی سست خطاها به راحتی ایزوله می شوند و امکان انتشار آن ها در شبکه کاهش می یابد، عیب یابی و نگهداری شبکه آسان می شود.
      همچنین جفت شدگی سست تعاملات ناخواسته بین المان های یک سیستم را کاهش می دهد.
      معایب:
      جفت شدگی سست می تواند باعث ایجاد دشواری در حفظ هماهنگی بین اجزای مختلف یک سیستم شود.
      در برخی از سیستم ها وابستگی زیاد میان المان ها امری لازم برای ادامه کار صحیح و مناسب سیستم است.
      8.2. اصل محل محوری (Locality)
      در علم فیزیک: عوامل محلی منجر به اثرات محلی می شوند.
      در علم کامپیوتر: دسترسی به داده ها و دستورالعمل ها از الگوهایی که به طور مداوم برای ذخیره و دسترسی اطلاعات استفاده می شوند پیروی می کنند.
      محل محوری زمانی: داده ها و دستورالعمل هایی که اخیراً مورد دسترسی قرار گرفته اند محتمل ترند که در آینده نزدیک مورد دسترسی قرار بگیرند.
      محل محوری مکانی: داده ها و دستورالعمل هایی که نزدیک داده ها و دستورالعمل هایی که اخیراً مورد دسترسی قرار گرفته اند محتمل ترند که در آینده نزدیک مورد دسترسی قرار بگیرند.
      بنابراین به طور کلی داده ها و دستورالعمل هایی که اخیراً مورد دسترسی قرار گرفته اند و داده ها و دستورالعمل های نزدیک به آن ها محتمل ترند که در آینده نزدیک مورد دسترسی قرار بگیرند.
      امروزه این اصل مستقیماً در طراحی کَش ها، پایگاه داده ها، موتورهای جستجوگر و غیره استفاده می شود.
      در سیستم های توزیع شده مکانیزم ترکیب و تقسیم سیستم های مسیریابی در ناحیه های مختلف، روشی است برای نگه داشتن عوامل محلی و اثرات محلی در کنار هم (همچون مدل فیزیکی اصل محل محوری).
      اصل محلی محوری نقش بنیادی در سیستم های توزیع شده خود ثبات (Self-Stabilizing Distributed Systems) ایفا خواهند کرد. بنابراین این اصل باید در اینترنت آینده برای سیستم های توزیع شده نیز تأمین یابد.
      9.2. اصل «انتها به انتها» (End-to-end)
      اگر بتوان یک مکانیزم را در گره انتهایی به طور کامل و صحیح پیاده کرد، نباید آن را درون شبکه پیاده سازی کرد مگر اینکه قابلیت ایجاد بهبود در عملکرد شبکه داشته باشد. هسته شبکه فقط باید سرویس های مربوط به اتصالات کلی را شامل شود نه سرویس هایی که مخصوص یک اپلیکیشن خاص می باشند.
      اصل انتها به انتها باعث نامرئی شدن شبکه برای اپلیکیشن های هاست ها می شود و سعی دارد فقط یک سرویس انتقال کلی را برای پشتیبانی از اپلیکیشن های گوناگون فراهم کند.
      اینترنت برعکس شبکه های تلفنی (PSTN) برای یک اپلیکیشن طراحی نشده است و به صورت کلی و قابل تکامل طراحی شده است. در اصل انتها به انتها اگر تمام اپلیکیشن ها به یک قابلیت نیاز داشته باشند، آن قابلیت را به جای هاست ها در شبکه جای می دهد تا میزان عملکرد و هزینه ها را بهبود بخشد. به عنوان یکی از چالش ها در این اصل، می توان به برخی از اپلیکیشن ها همچون IP multicast و Mobile IP اشاره کرد که در آن ها نیاز به گرفتن پشتیبانی از گره های میانی است. چالش دیگر در اینترنت اشیا و ارتباطات اشیاء هوشمند می باشد که در آن ارتباطات انتها به انتها به شدت تحت تأثیر گیت وی های میانی و گره های مقصد در شبکه سنسورها می باشد.
      سرانجام گروه FIArch بعد از تجزیه و تحلیل به این نتیجه رسیده است که پشتیبانی از کنترل ازدحام نمی تواند یک تابع خالص انتها به انتها باشد. ازدحام یک پدیده ذاتی شبکه ای می باشد که برای رفع آن نیاز به همکاری سیستم های انتهایی و زیرساخت مشترک ارتباطات می باشد. به جای قرار دادن توابع خاص در مکان های خاص (در سیستم های انتهایی یا در روترهای درون شبکه)، سرویس ها و توابع باید هر کجا که به آنها نیاز است به کار گرفته شوند.
      10.2.اصل کمترین مداخله (minimum intervention)
      برای بهبود بازده جریان داده ها در هنگام کپسوله کردن (Encapsulation)، داده ها تا حد امکان باید به صورتی که دریافت شده اند ارسال شوند بدون اعمال تغییرات. اصل کمترین مداخله برای حفظ یکپارچگی داده ها و همچنین اجتناب از پردازش های میانی بر روی بسته ها، امری حیاتی می باشد. در برخی موارد اصل کمترین مداخله ممکن است با اصل سادگی تناقض داشته باشند برای مثال در شبکه سنسورها و اینترنت اشیا که Gateway ها و Actuatorها قرار است ارتباط بین شبکه ها را با پیاده سازی قابلیت هایی که پشتیبانی آنها در سنسورها بسیار پر هزینه می شود، برقرار کنند. به این علت FIArch به کمرنگ تر کردن نقش این اصل در طراحی اینترنت آینده پیشنهاد می دهد.
      11.2.اصل سادگی (simplicity)
      وقتی در طراحی شک دارید، ساده ترین راه حل را انتخاب کنید. (RFC1958)
      افزایش قابلیت ها یا بهبود عملکرد سیستم نباید به قیمت افزایش پیچیدگی ها در سیستم تمام شود. سیستم های پیچیده معمولاً کمتر قابل اعتماد و انعطاف پذیر هستند. برای افزایش قابلیت اعتماد باید تعداد اجزا در مسیر سرویس انتقال (مسیر پروتکل، مسیر نرم افزاری یا مسیر فیزیکی) به حداقل کاهش یابد. مسائل پیچیده مانند معماری اینترنت معمولاً راه حل های پیچیده ای نیز می طلبند. بنابراین این اصل با کمی تغییر برای طراحی اینترنت آینده مطرح می شود. مکان و توزیع قابلیت ها می بایستی به گونه ای تعیین شود که پیچیدگی معماری به صورت سراسری به حداقل برسد. بنابراین کاهش دلخواه پیچیدگی ممکن است به طور محلی خوب تلقی شود اما ممکن است به طور سراسری به ضرر کل سیستم باشد.
      همه چیز باید حتی الامکان ساده ساخته شوند اما نه ساده تر. (انیشتین)
      12.2.اصل نام دهی و آدرس دهی بی ابهام (Unambiguous naming and addressing)
      پروتکل های اینترنت باید مستقل از واسطه سخت افزاری و همینطور آدرس دهی سخت افزاری طراحی شوند. (RFC1958)
      این اصل به اینترنت اجازه می دهد تا هرگونه وسیله مخابراتی دیجیتال مستقل از آدرس سخت افزاری به اینترنت متصل شود و یک پلت فرم استاندارد برای بازه وسیعی از اپلیکیشن ها و سرویس های مختلف باشد.
      1. اجتناب از طرح هایی که در آن ها نیاز به ثبت آدرس ها به صورت دائمی در منابع ذخیره باشد. به طور کلی اپلیکیشن ها باید از اسامی به جای آدرس ها استفاده کنند. بنابراین آدرس لایه انتقال باید از IP جدا شود و از ID به جای آن استفاده شود.
      2. یک ساختار نام دهی یکتا و مشترک باید استفاده شود.
      3. جدا سازی IP از ID : به علت کمبود ظرفیت IP، پروتکل های لایه های بالاتر باید قابلیت تعیین بی ابهام ID در نقاط انتهایی را داشته باشند و از IPها فقط برای مسیریابی انتها به انتها استفاده شود (برای پردازش در گره های میانی).

      این اصل در اینترنت آینده باید به IDهای بی ابهام برای دیگر بخش ها همچون منابع، داده ها و سرویس ها توسعه داده شود.


      3. بذرها برای اصول طراحی جدید

      استفاده از واژه بذر (Seed) به دلایل زیر صورت گرفته است:
      1. فرمول کردن اصول، امری پیچیده می باشد.
      2. تحقیقات برای اثبات سودمندی و تأثیرات این اصول همچنان ادامه دارد (ممکن است هنوز به بلوغ نرسیده باشد).
      3. بذرهای پیشنهاد شده ممکن است قابلیت شکوفایی را نداشته باشند (پیشنهادات فراوان وارد اما تعداد کمی عملی می شوند)



      1.3. آگاهی منابع (Resources Awareness)
      چالش ها:
      • زیرساخت ها ناآگاه از سرویس اند.
      • رشد داده ها یک شمای جدید تحویل، برای غلبه بر محدودیت ها می طلبد.

      بذر:
      روش های مدیریتی در اینترنت کنونی بر پایه داده ها می باشد اما در اینترنت آینده مدیریت ها باید بر پایه سرویس ها انجام گیرد به طوری که اصطلاحاً می گوییم منابع باید به صورت انتزاعی از سرویس ها آگاه باشند. برای این منظور باید مفاهیم انتزاعی پیچیده تر و با معناتری نسبت به مفاهیم انتزاعی کنونی (مانند URLها و APIها) برای سرویس ها در زیر ساخت ها تعیین گردد به طوری که این مفاهیم انتزاعی بر نحوه رفتار لایه زیرساخت در سطوح پایین تر آن تأثیر بگذارد.
      هر لایه معماری اینترنت آینده باید به صورت دسته ای از سرویس های خود مدیریت شده و خودآگاه باشند که به طور ایزوله قابلیت های خاصی را فراهم می آورند و همزمان باید با لایه های دیگر همکاری کنند تا یک سرویس جامع را ایجاد کنند. انتظار می رود که این آگاهی سرویس در زیرساخت، در تحویل سرویس مفید واقع شود. به همچنین عملیاتی که در سطوح پایین تر انجام می گیرد (مثل مسیریابی) سرویس ها را درک می کنند و بر اساس آنها رفتار خود را بهینه می سازند. در این اصل، از اصول ماژول بندی به وسیله لایه بندی (همکاری بین لایه ای)، جفت شدگی سست (برای کاهش تعاملات ناخواسته واتفاقات غیر خطی) و محل محوری (برای کاهش فاصله بین یک فرایند مثل سرویس و داده متناظر آن) استفاده می شود.

      انتظار می رود که این آگاهی سرویس در زیرساخت، در تحویل سرویس مفید واقع شود. به همچنین عملیاتی که در سطوح پایین تر انجام می گیرد (مثل مسیریابی) سرویس ها را درک می کنند و بر اساس آنها رفتار خود را بهینه می سازند. در این اصل، از اصول ماژول بندی به وسیله لایه بندی (همکاری بین لایه ای)، جفت شدگی سست (برای کاهش تعاملات ناخواسته واتفاقات غیر خطی) و محل محوری (برای کاهش فاصله بین یک فرایند مثل سرویس و داده متناظر آن) استفاده می شود.

      2.3. منطق قابلیت اعتماد و اطمینان (Dependability)
      چالش ها:
      • سرویس ها بر اساس «بهترین کوشش» عمل می کنند.
      • تضمین کم یا حتی بدون تضمین سرویس به کاربران
      • مدل شدن سرویس ها قبل از به کارگیری
      • زیرساخت ناآگاه از سرویس

      بذر:
      اینترنت کنونی فاقد روش ها و وسیله هایی برای پردازش قابل اعتماد، قابل اطمینان و قابل تأیید شبکه و زیرساخت سیستم ها متناظر با سرویس هایشان می باشد که این موضوع از اهمیت بالایی برخوردار است. برای تأمین این خواسته، طراحی اینترنت با سرویس هایش باید با اصل قابلیت اعتماد و اطمینان (قابلیت اعتماد، قابلیت اطمینان و قابلیت تأیید) به همراه قابلیت خود وفق دهی و خود آموزش دهی ترکیب شود تا بتواند از تغییرات در شرایط عملیاتی، آموزش ببیند.


      3.3. اجازه تبادل اطلاعات میان نقاط انتهایی از انواع مختلف: (Allow the exchange of information between end-points of different type
      اینترنت در سال های اخیر از یک شبکه با اهداف تحقیقاتی به صحنه بازی عده ای ذینفع از جمله:
      • ISPها (Internet Service Providers)
      • CDNها (Content Distributed Networks Providers)
      • CPها (Content Providers)
      • کاربران و ...
      تبدیل شده است.
      هر ذینفعی با استفاده از اطلاعات ناقص موجود بدون در نظر گرفتن دیگران، بر بهینه سازی در حیطه خود می کوشد به طور مثال، ISPها سعی در تعدیل هزینه های بین دامینی را دارند، CDNها برای بهبود مسیریابی محتوایی تلاش می کنند و کاربران به دنبال سود خود در انتخاب هایی که می توانند داشته باشند (از جمله انتخاب برای ارائه دهندگان اپلیکیشن یا ISPها و غیره) می باشند.
      این عدم تقارن اطلاعات بین ذینفع ها می تواند منجر به انتخاب های نامناسب شود که به تضعیف عملکرد کلی اینترنت بیانجامد. از طرفی دیگر به علت غیر قابل پیش بینی بودن اینترنت، طراحان نمی توانند خروجی مشخصی را به عنوان بهترین و مؤثرترین خروجی پیش بینی کنند بنابراین طراحی باید به گونه ای باشد که سیستم از خروجی های مختلف پشتیبانی کند.

      بذر:
      بنابراین ذینفع ها باید اطلاعاتی را بر اساس انتخاب و ترجیح دیگر ذینفع ها در اختیار آنها قرار دهند. این انتشار اطلاعات می تواند یک وضعیت «همه-بُرد» ایجاد کند. در عمل، اصل پیشنهاد شده می تواند به طراحی رابط ها و سیستم های باز برای تعامل و ارتباط بین ذینفع ها و همچنین پیش بینی عکس العمل کاربران در تجربه کیفیت نامطلوب بیانجامد.

      تبادل و پردازش اطلاعات میان ذینفع ها به صورت زیر می باشد:
      • نمایش اطلاعات به یک ذینفع
      • چکیده کردن اطلاعات مورد تبادل
      • جمع آوری اطلاعات توسط ذینفع
      • ارزشیابی اطلاعات توسط ذینفع، و در انتها
      • تصمیم گیری

      نمایش اطلاعات باید به گونه ای باشد که هیچ اطلاعات حساس و حیاتی که باعث آسیب مالک شود، آشکار نشود.

      در عمل:
      مدیریت لایه های رویی: درخواست اطلاعات کمکی لایه رویی از لایه های زیرین در انتخاب منابع


      TCP چند مسیره: اطلاعات ازدحام به وسیله جریان ها (Flows) حمل می شوند. هاست های انتهایی در چگونگی انتقال بار میان جریان ها تصمیم گیری می کنند. Re-ECN (Re-feedback of Explicit Congestion Notification): اطلاعات ازدحام در دسترس تمامی نُدهای شبکه قرار می گیرد.


      4.3. تقویت منابع و سرمایه گذاری فکری (Sustain the Resources and Brain Investment)
      چالش:
      رقابت میان بخش های مختلف اینترنت به علت تضاد در منافع آنها می تواند به اثرات منفی سراسری که اصطلاحاً به آنها «کشمکش» (Tussle) گفته می شود، منجر شود.


      جستجو درکاندیداهای این کشمکش ها می تواند ما را به انگیزه های اجتماعی-اقتصادی آنها در ایجاد این کشمکش ها سوق دهد.

      نمونه ای از کشمکش ها:
      • مسیردهی و مهندسی ترافیک
      با پیچیده شدن توپولوژی بین دامینی در اینترنت، مهندسی ترافیک تلاش دارد تا یک کنترل اقتصادی بر مسیر انتقال در توپولوژی داشته باشد. در حالی که مکانیزم اصلی یعنی BGP به کنترل اقتصادی بر مسیر انتقال در تعاملات میان ارائه دهندگان حساس نیست. بنابراین اپراتورها در مدیریت ترافیک با توجه به منافع خود، ممکن است به قابلیت دسترسی انتها به انتها آسیب وارد کنند.
      • کنترل منابع
      اپلیکیشن های جدیدی همچون ارتباطات Peer-to-Peer، ارتباطات صوتی، VPNهای حیاتی کاری و غیره ممکن است از ده ها جریان TCP استفاده کنند که لازمه آن استفاده زیادی از پهنای باند می باشد. در صورتی که اپلیکیشن های قدیمی تر همچون Web Browserها یک یا تعداد بسیار محدودی جریان TCP استفاده می کنند. بنابراین ISPها نسبت به منافع اقتصادی خود، دست به تعادل میزان پهنای باند میان کاربران می زنند. این تعادل ممکن است به نفع ارائه دهندگان باشد اما کاربران اپلیکیشن های جدید از سرویس خود ناراضی خواهند بود. نحوه صحیح رفتار با این کشمکش ها (با اثر گذاشتن و یا مذاکره کردن بر سر خروجی هایی که از دید فناوری منطقی باشند نه از دید هر پکت)، می تواند اثرات منفی سراسری را کاهش دهد.

      بذر:
      اینترنت فقط نباید برای تحمل کشمکش ها طراحی شود بلکه باید به گونه ای طراحی شود که اثر مثبت سراسری برای تمام کاربران آن (چه شخصی و چه اعضای انجمن های مختلف) را به همراه داشته باشد و اصطلاحاً به وضعیت «همه-بُرد» منجر شود. بنابراین بسیار مهم است که طراحی اینترنت بتواند سرمایه گذاری در بخش فکری، نوآوری و منابع را برای رسیدن به یک اثر مثبت سراسری تقویت کند.

      در عمل:
      طراحی اینترنت باید به کمک توسعه اپلیکیشن های باز به مردم و انجمن های مختلف اجازه مشارکت و همکاری برای ایجاد اثر مثبت سراسری را بدهد. طراحی باید این امکان را به انجمن های مختلف (کاربران، توسعه دهندگان، شرکت ها و انجمن های عملیاتی) بدهد تا بتوانند ماژول ها و اجزایی (و تعاملاتی که بین آنها برقرار است) که منجر به اثرات مثبت می شوند را برای ایجاد انگیزه تشویق نمایند.

      4. اصول طراحی پیشنهاد شده در دیگر مقالات علمی برای مقابله با کشمکش ها
      1.4. نمایش اطلاعات (Information Exposure)
      داده ها و تعاملاتی که از منابع کمیاب در شبکه استفاده می کنند باید به صورت لحظه ای اطلاعات کمی کنترلی در مورد منبع مورد استفاده خود را در اختیار شبکه بگذارند. اطلاعات کنترلی میزان استفاده از منبع و همچنین جایگزین مناسب برای آن را نشان می دهد. از این اطلاعات همچنین می توان در ساختار قیمت گذاری نیز استفاده کرد.
      به عنوان مثال اگر منبع کمیاب در شبکه را پهنای باند محدود یک روتر در نظر بگیریم، اطلاعات کنترلی می تواند در مورد ازدحام در آن روتر باشد. از دیگر منابع کمیاب می تواند به طور مثال به کمبود فضای یک جدول برای ذخیره نقشه روترهای میانی، یا میزان قدرت پردازش برای اداره پیام های روتر اشاره کرد.

      2.4. جداسازی سیاست از مکانیزم (Separation of Policy and Mechanism)
      باید به شبکه اجازه داده شود تا سیاست ها به صورت محلی انتخاب شوند و مکانیزم به صورت یک روش و پروتکل استاندارد طراحی شود تا سیاست ها بتوانند به کمک آن نحوه ارتباط منابع را به طور دلخواه تعیین کنند. اما به کمک اصل نمایش اطلاعات، تلاقی میان سیاست ها باید محدود شود. بنابراین سیاست ها باید در اعمال آزاد باشند و بر خلاف مکانیزم ها نیازی به استانداردسازی نداشته باشند.
      برای مثال:
      در پروتکل DCCP (Datagram Congestion Control Protocol) دست دادن سه طرفه (Three-way handshake) برای برقراری اتصال، یک مکانیزم استاندارد است اما سیاست گذاری برای تعیین الگوریتم مناسب کنترل ازدحام، آزاد و به عهده شبکه می باشد.
      در مسیردهی BGP مکانیزم به این صورت است که یک AS به AS همسایه مسیرهایی بر اساس پیشوند IPها پیشنهاد می دهد ولی AS در انتخاب بهتربن مسیر، آزاد و سیاست های خود را مستقلاً تعیین می کند.
      با این حال سیاست گذاری ها باید منطقی باشند و سیاست یک کاربر نباید به ضرر کاربر دیگر بینجامد، که این امر می تواند به کمک اصل نمایش اطلاعات، محقق گردد.

      3.4. اصل نقاط انتهایی فازی (The Fuzzy Ends)
      باید به نقاط انتهایی این اختیار داده شود تا در صورت نیاز، وظیفه انجام برخی از توابع را به شبکه محول کنند. اما اینگونه توابع نباید پیچیده و مشکل زا باشند به طوری که اصل انتها به انتها را نقض کنند.
      به عنوان مثال:
      اولویت بندی اپلیکیشن ها: یک جعبه DPI در شبکه اولویت های ترافیکی را تخمین می زند تا متقاضی بتواند بهترین استفاده را از ظرفیت قراردادی خود داشته باشد.
      حفاظت: فایروال در شبکه، ترافیک های از پیش تعیین شده مثل محتواهای افراد بزرگسال، اشتراک فایل ها، بازی ها، اتاق های چت و غیره را برای متقاضی فیلتر می کند که می تواند کاربردهای خانگی و اداری داشته باشد.
      کَش کردن محتوا: بنا به تقاضا شبکه، محتواهای یک سرور را کَش می کند تا بتواند سرعت تحویل به متقاضی را افزایش دهد.

      4.4. اتحاد منابع (Resource Pooling)
      به اتحاد منابع مختلف و جدا از هم برای تشکیل یک منبع بزرگ تر گفته می شود که این امکان را به بار می دهد تا بتواند بین منابع، نقل مکان (Relocate) کند و یا میان آنها پخش (Spread) شود. فقط باید از عدم مغایرت مکانیزم های اتحاد منابع، اطمینان حاصل گردد.
      برای مثال:
      شبکه های تحویل محتوا (CDNs)، سیکل های پردازش، پهنای باند و قابلیت اعتماد را از تمام سرورهای توزیع شده، متحد می کند.
      در سیستم های دانلود Peer-to-Peer مثل BitTorrent، گیرنده از چندین Peer دیگر برای دریافت یک داده مشترک استفاده می کند به طوری که گویی دانلود از یک منبع واحد صورت می گیرد.
      چند خانگی (Multihoming)، مسیردهی چند مسیره (Multipath routing) و مهندسی ترافیک، لینک ها یا شبکه های جدا از هم را با هم متحد می کنند.

      مزایا:
      • افزایش Robustness در مواجهه با خرابی اجزا
      • اداره بهتر ترافیک محلی
      • بیشترین بهره برداری از منابع


      5. جمع بندی






      تهیه شده در معاونت فناوری - 1394
      کلمات کلیدی

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

      منبع درج

      -Papadimitriou, D., et al. "Fundamental Limitations of Current Internet and the path to Future Internet, European Commission." FIArch Group, Ver 1 (2010).
      -Müller, Paul. "Future Internet Design Principles." (2012).
      -Ford, Alan, Philip Eardley, and Barbara Van Schewick. "New design principles for the internet." Communications Workshops, 2009. ICC Workshops 2009. IEEE International Conference on. IEEE, 2009.

      نظر کاربران
      نام:
      پست الکترونیک:
      شرح نظر:
      کد امنیتی:
       
تمامی حقوق برای مرکز ملی فضای مجازی محفوظ است. هر گونه کپی‌برداری از مطالب با ذکر منبع بلامانع است.