معماری بین‌شبکه‌ای بازگشتی

معماری بین‌-شبکه‌ای بازگشتی (RINA)
**معماری بین‌-شبکه‌ای بازگشتی (Recursive InterNetwork Architecture یا RINA)** یک معماری شبکه رایانه‌ای جدید است که به عنوان جایگزینی برای معماری متداول پشته پروتکل اینترنت (Internet Protocol Suite) ارائه شده است. اصول پایه‌ای RINA نخستین بار توسط جان دی در کتابش با عنوان *الگوها در معماری شبکه: بازگشتی به اصول* (۲۰۰۸) مطرح شد. این کار نگاهی نو به مسأله دارد و درس‌هایی را که طی ۳۵ سال وجود TCP/IP، همچنین شکست OSI و دیگر فناوری‌های شبکه‌ای نظیر CYCLADES، DECnet و Xerox Network Systems حاصل شده، لحاظ می‌کند. اصل بنیادین RINA این است که شبکه رایانه‌ای چیزی جز ارتباط بین‌فرآیندی (IPC) نیست و لایه‌بندی باید بر اساس دامنه/مقیاس انجام شود و از یک مجموعه پروتکل تکرارپذیر و یکسان استفاده کند، نه بر اساس عملکرد و پروتکل‌های تخصصی. نمونه‌های پروتکل در هر لایه از طریق مفاهیم و اجزای جدید با نمونه‌های پروتکل در لایه‌های بالاتر و پایین‌تر ارتباط برقرار می‌کنند که کارکردهایی را که اکنون خاص پروتکل‌هایی مثل BGP، OSPF و ARP است، مجسم می‌سازند (Reification). به این ترتیب، RINA مدعی است که قابلیت‌هایی مانند جابجایی (mobility)، چندمسیری (multihoming) و کیفیت سرویس (QoS) را بدون نیاز به پروتکل‌های تخصصی افزوده مانند RTP و UDP پشتیبانی می‌کند و همچنین مدیریت شبکه را بدون نیاز به مفاهیمی چون سامانه مستقل و NAT ساده‌تر می‌سازد.

مرور کلی

RINA حاصل تلاشی است برای استخراج اصول کلی در شبکه رایانه‌ای که در همه شرایط صدق می‌کنند. RINA معماری، پیاده‌سازی، پلتفرم آزمایشی و در نهایت نمونه اجرایی مدلی است که به طور غیررسمی با نام مدل IPC شناخته می‌شود. اگرچه این معماری به شبکه مربوط است، اما با مفاهیم و نتایجی نیز سر و کار دارد که در هر برنامه توزیع‌شده‌ای، نه فقط شبکه، کاربرد دارد. چون RINA از جهان برنامه‌های توزیع‌شده می‌آید، بیشتر واژگان آن از توسعه نرم‌افزار گرفته شده‌اند تا شبکه؛ که با توجه به اصل بنیادین RINA که کاهش شبکه به IPC است، قابل درک است.

واحد پایه در RINA فرایند کاربرد توزیع‌شده یا DAP است که معمولاً با یک فرایند روی میزبان مطابقت دارد. دو یا چند DAP، یک تسهیلگر کاربرد توزیع‌شده یا DAF را تشکیل می‌دهند که در شکل ۱ نمایش داده شده است. این DAPها با استفاده از پروتکل مشترک کاربرد توزیع‌شده یا CDAP ارتباط برقرار می‌کنند و داده‌های ساختاریافته را به شکل شیء رد و بدل می‌کنند. این اشیاء در پایگاه اطلاعات منابع یا RIB ساختاربندی شده‌اند که طرح نام‌گذاری و سازمان منطقی آن‌ها را فراهم می‌کند. CDAP شش عملیات پایه را بر روی اشیاء DAP راه‌دور ارائه می‌دهد: ایجاد (create)، حذف (delete)، خواندن (read)، نوشتن (write)، آغاز (start) و توقف (stop).

برای تبادل اطلاعات، DAPها به یک تسهیلگر زیرین نیاز دارند که وظیفه آن فراهم‌سازی و مدیریت سرویس‌های IPC روی دامنه‌ای خاص است. این تسهیلگر خود یک DAF دیگر است که تسهیلگر IPC توزیع‌شده یا DIF نامیده می‌شود. یک DIF این امکان را به DAP می‌دهد که جریان‌هایی را به یک یا چند DAP دیگر با ارائه نام DAPهای هدف و پارامترهای QoS مورد نظر (مثل محدودیت‌های اتلاف داده و تأخیر، ترتیب‌دهی، اطمینان‌پذیری و غیره) تخصیص دهد. به عنوان مثال، DAPها ممکن است به DIF خود اعتماد نکنند و بنابراین داده‌های خود را پیش از نوشتن روی جریان، رمزنگاری کنند (مثلاً با ماژول حفاظت SDU). DAPهای یک DIF، فرآیندهای IPC یا IPCP نام دارند. آن‌ها همان ساختار کلی DAP را دارند (شکل ۳)، به‌علاوه وظایف خاص برای ارائه و مدیریت IPC. این وظایف (شکل ۴) در سه دسته کلی قرار می‌گیرند، به ترتیب پیچیدگی افزاینده و تکرارپذیری کاهنده:
۱. انتقال داده،
۲. کنترل انتقال داده و
۳. مدیریت لایه.

یک DAF معادل لایه کاربرد است و یک DIF معادل لایه بلافصل زیرین آن، طبق بیشتر مدل‌های شبکه فعلی؛ و سه دسته وظیفه فوق معادل عمده وظایف نه تنها عملیات شبکه، بلکه مدیریت و حتی احراز هویت شبکه هستند (با مقداری جابه‌جایی مسئولیت که در ادامه خواهد آمد).

DIFها که خود DAF هستند، به نوبه خود از DIFهای زیرین بهره می‌گیرند تا جایی که به پایین‌ترین لایه فیزیکی که سیم‌ها و پورت‌ها را کنترل می‌کند برسند. این همان جایی است که خاصیت بازگشتی RINA از آن ناشی می‌شود. تمام لایه‌های RINA ساختار و اجزای یکسانی دارند و عملکرد یکسانی ارائه می‌دهند؛ تفاوت‌شان فقط در دامنه، پیکربندی یا سیاست‌هایشان است (مشابه جداسازی سازوکار از سیاست در سیستم‌عامل‌ها). همان‌طور که در شکل ۲ دیده می‌شود، شبکه‌های RINA معمولاً به صورت DIFهایی با دامنه افزاینده سازمان یافته‌اند. شکل ۳ نمونه‌ای از ساختار احتمالی وب با RINA را نشان می‌دهد: بالاترین لایه نزدیک‌ترین لایه به برنامه‌هاست (مانند ایمیل یا وبسایت)؛ لایه‌های پایینی، ترافیک لایه‌های بالاتر را جمع و تقسیم می‌کنند (مثلاً ستون فقرات ISP). DIFهای چندارائه‌دهنده (مانند اینترنت عمومی) بر روی لایه‌های ISP شناور هستند. در این مدل، سه نوع سامانه وجود دارند: میزبان‌ها (حاوی DAP)، مسیریاب‌های داخلی یک لایه، و مسیریاب‌های مرزی که در مرز لایه‌ها قرار دارند و بسته‌ها را به لایه بالا یا پایین هدایت می‌کنند.

خلاصه اینکه RINA مفاهیم PDU و SDU را حفظ می‌کند اما به جای لایه‌بندی بر اساس عملکرد، بر اساس دامنه لایه‌بندی می‌کند. لایه‌ها معادل مسئولیت‌های متفاوت نیستند بلکه معادل مقیاس‌های متفاوت‌اند و مدل به طور خاص برای تطبیق از یک اتصال نقطه‌به‌نقطه اترنت تا شبکه جهانی وب طراحی شده است. هدف RINA، استفاده مجدد هرچه بیشتر از نظریه و حذف نیاز به طراحی پروتکل‌های موردی (ad-hoc) و در نتیجه کاهش پیچیدگی ساخت، مدیریت و بهره‌برداری از شبکه است.

نام‌گذاری، نشانی‌دهی، مسیرگزینی، جابجایی و چندمسیری
همان‌طور که گفته شد، نشانی IP برای پشتیبانی مؤثر از چندمسیری و جابجایی بسیار سطح پایین است و نیازمند جدول‌های مسیریابی بزرگ‌تر از حد ضروری. ادبیات RINA نظریه کلی جری سالتزر درباره نشانی‌دهی و نام‌گذاری را دنبال می‌کند. بر اساس سالتزر، باید چهار عنصر شناسایی شوند: برنامه‌ها، گره‌ها، نقاط اتصال و مسیرها. یک برنامه می‌تواند روی یک یا چند گره اجرا شود و باید بتواند بدون از دست دادن هویت خود در شبکه، بین گره‌ها جابجا شود. یک گره می‌تواند به یک جفت نقطه اتصال وصل شود و باید بتواند بین آن‌ها جابجا شود بدون از دست دادن هویت. یک فهرست‌نگار، نام برنامه را به نشانی گره و مسیرها را به توالی نشانی‌ها و نقاط اتصال نگاشت می‌کند. این موارد در شکل ۴ نمایش داده شده است.

سالتزر این مدل را از سیستم‌عامل‌ها گرفته بود اما نویسندگان RINA نتیجه گرفتند که این مدل را نمی‌توان به راحتی به شبکه‌های بین‌-شبکه‌ای تعمیم داد؛ چون ممکن است بیش از یک مسیر بین جفتی از گره‌ها وجود داشته باشد (چه رسد به شبکه‌های کامل). راه‌حل RINA مدل‌سازی مسیرها به صورت توالی گره‌هاست: در هر گام، گره مربوطه مناسب‌ترین نقطه اتصال را برای ارسال بسته به گره بعدی انتخاب می‌کند. بنابراین، مسیرهای RINA در دو گام تعیین می‌شوند: ابتدا مسیر به صورت توالی نشانی گره‌ها محاسبه می‌شود و سپس در هر گام، نقطه اتصال مناسب انتخاب می‌شود. این‌ها مراحل تولید جدول هدایت (forwarding) هستند: هدایت همچنان با یک جستجوی واحد انجام می‌شود. افزون بر این، گام آخر می‌تواند با فرکانس بیشتری انجام شود تا از چندمسیری برای توازن بار استفاده شود.

با این ساختار نام‌گذاری، جابجایی و چندمسیری به طور ذاتی پشتیبانی می‌شوند اگر نام‌ها ویژگی‌های زیر را داشته باشند:

۱. نام برنامه‌ها مستقل از موقعیت باشد تا برنامه بتواند جابجا شود؛
۲. نشانی گره‌ها وابسته به مکان ولی مستقل از مسیر باشد؛
۳. نقاط اتصال ذاتاً وابسته به مسیر هستند.

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

طراحی پروتکل
پشته پروتکل اینترنت، معمولاً پروتکل‌ها را به صورت جداگانه طراحی می‌کند، بدون توجه به تکرار یا امکان تبدیل برخی جنبه‌ها به سیاست (policy). RINA سعی دارد این مشکل را با به‌کارگیری اصل جداسازی سازوکار و سیاست از سیستم‌عامل‌ها در طراحی پروتکل حل کند. هر DIF از سیاست‌های متفاوتی برای ارائه کلاس‌های متفاوت کیفیت سرویس و سازگاری با ویژگی‌های رسانه فیزیکی (در DIFهای سطح پایین) یا برنامه‌ها (در DIFهای سطح بالا) استفاده می‌کند.

RINA نظریه پروتکل Delta-T توسعه‌یافته توسط ریچارد واتسون (۱۹۸۱) را به کار می‌گیرد. پژوهش واتسون نشان داد که شرایط کافی برای انتقال مطمئن، کراندار کردن سه تایمر است. Delta-T نمونه‌ای است از نحوه این کار: این پروتکل تنظیم یا خاتمه اتصال ندارد. همین پژوهش اشاره می‌کند که TCP نیز همین تایمرها را به کار می‌گیرد، اما Delta-T از نظر پیاده‌سازی ساده‌تر است. همچنین اشاره می‌شود که همگام‌سازی و تخصیص پورت باید وظایف جداگانه باشند؛ تخصیص پورت جزو مدیریت لایه و همگام‌سازی جزو انتقال داده است.

امنیت

برای پشتیبانی از امنیت، RINA الزام می‌کند که هر DIF/DAF یک سیاست امنیتی تعیین کند که توابع آن در شکل ۵ نشان داده شده‌اند. این کار امکان تأمین امنیت نه فقط برنامه‌ها، بلکه ستون‌فقرات و بسترهای سوئیچینگ را نیز فراهم می‌کند. یک شبکه عمومی صرفاً نمونه‌ای است که در آن سیاست امنیتی هیچ کاری انجام نمی‌دهد. این امر ممکن است برای شبکه‌های کوچک سربار داشته باشد اما برای شبکه‌های بزرگ مقیاس‌پذیرتر است، چون لایه‌ها نیازی به هماهنگی مکانیزم‌های امنیتی خود ندارند: تخمین زده می‌شود که اینترنت فعلی حدود ۵ برابر بیشتر از RINA به نهادهای امنیتی مستقل نیاز دارد. علاوه بر این، سیاست امنیتی می‌تواند مکانیزم احراز هویت تعیین کند؛ بنابراین فایروال‌ها و لیست‌های سیاه منسوخ می‌شوند، زیرا DAP یا IPCPی که نتواند به یک DAF یا DIF ملحق شود، امکان ارسال یا دریافت ندارد. همچنین DIFها نشانی IPCPهای خود را به لایه‌های بالاتر آشکار نمی‌کنند که مانع طیف وسیعی از حملات مرد میانی می‌شود.

خود طراحی پروتکل Delta-T، با تأکید بر سادگی، عاملی دیگر است. برای مثال، این پروتکل بدون دست‌دهی (handshake) است، بنابراین پیام کنترلی قابل جعل یا حالتی که قابل سوءاستفاده باشد (مثل حمله SYN flood) وجود ندارد. همین مکانیزم همگام‌سازی، رفتار غیرعادی را با تلاش نفوذگر مرتبط‌تر می‌سازد و بنابراین تشخیص حمله را آسان‌تر می‌کند.

پیشینه
نقطه آغاز معماری کاملاً نوین و متفاوتی چون RINA، تلاش برای حل یا واکنشی به مشکلات زیر است که به نظر نمی‌رسد راه‌حلی عملی یا بدون مصالحه در معماری‌های فعلی شبکه (به‌ویژه پشته پروتکل اینترنت و لایه‌بندی کارکردی آن مطابق شکل ۶) داشته باشند:

پیچیدگی انتقال: جداسازی IP و TCP منجر به ناکارآمدی می‌شود؛ نمونه بارز آن کشف MTU مسیر برای جلوگیری از تکه‌تکه‌سازی IP است.

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

چندمسیری: نشانی IP و شماره پورت، برای شناسایی یک برنامه در دو شبکه مختلف، بسیار سطح پایین هستند. DNS این مشکل را حل نمی‌کند، چون هر نام میزبان باید به یک ترکیب IP و پورت نگاشت شود، که آن‌ها را به نام مستعار تبدیل می‌کند نه هویت واقعی. LISP هم مشکل را حل نمی‌کند، چون هنوز از نشانی IP برای مسیریابی استفاده می‌کند و بر تمایز غلطی تکیه دارد که در واقع همه موجودیت‌ها در یک دامنه با شناسه‌شان مکان‌یابی می‌شوند؛ همچنین خودش مشکلات مقیاس‌پذیری ایجاد می‌کند.

جابجایی: نشانی IP و پورت برای شناسایی یک برنامه در حال حرکت ناکارآمدند و برای دستگاه‌های سیار مشکلاتی پدید می‌آورند. Mobile IP عملاً مشکل را به نشانی care-of و تونل‌زنی IP منتقل می‌کند که پیچیدگی را افزایش می‌دهد.

مدیریت: ماهیت سطح پایین نشانی IP باعث اختصاص چندین نشانی یا حتی بازه‌های نشانی به میزبان‌ها می‌شود که فشار بر تخصیص و تسریع اتمام نشانی‌ها را افزایش می‌دهد. NAT فقط روند اتمام را کند می‌کند و حتی مشکلات بیشتری هم می‌آفریند. در همین حال، لایه‌بندی کارکردی پشته اینترنت فقط دو دامنه ارائه می‌دهد که تقسیم‌بندی مدیریت اینترنت را پیچیده می‌کند و نیازمند مفاهیم مصنوعی چون سامانه‌های مستقل است. OSPF و IS-IS مشکلات کمتری دارند اما خوب مقیاس نمی‌شوند و به BGP برای شبکه‌های بزرگ‌تر و مسیریابی بین دامنه نیاز است.

امنیت: ماهیت فضای نشانی IP منجر به امنیت ضعیف می‌شود، چون هیچ سیاست واقعی برای افزودن/حذف نشانی‌ها نیست مگر جلوگیری فیزیکی. TLS و IPSec راه‌حل‌هایی ارائه می‌کنند اما با پیچیدگی بالا. دیوار آتش و لیست سیاهها آسیب‌پذیر و نامقیاس‌پذیر هستند. تجربه نشان داده افزودن امنیت به یک پشته پروتکل دشوار است مگر این‌که از ابتدا در معماری تعبیه شده باشد.

این مشکلات امروز کاملاً مشهودتر شده‌اند اما تقریباً از همان آغاز ARPANET، که محیط طراحی اینترنت بود، سابقه داشته‌اند:

۱۹۷۲: چندمسیری در ARPANET پشتیبانی نشد
در ۱۹۷۲ پایگاه نیروی هوایی تینکر می‌خواست برای افزونگی به دو IMP مختلف متصل شود اما طراحان ARPANET متوجه شدند که نشانی میزبان همان نشانی پورت IMP است که میزبان به آن متصل شده بود (الگوبرداری از تلفن). بنابراین دو واسط یک میزبان نشانی متفاوت داشتند؛ یعنی نشانی خیلی سطح پایین بود.

۱۹۷۸: جداسازی TCP از IP
نسخه‌های اولیه TCP کنترل خطا و جریان (TCP فعلی) و رله و چندگانه‌سازی (IP) را با هم داشتند. در ۱۹۷۸ این دو جدا شدند، هرچند دامنه یکسان داشتند. تا ۱۹۸۷ جامعه شبکه از مشکلات تکه‌تکه‌سازی IP کاملاً آگاه شده بود. اما وابستگی TCP و IP به هم، به عنوان یک مشکل بنیادی درک نشد.

۱۹۸۱: نتایج بنیادی واتسون نادیده گرفته شد
ریچارد واتسون (۱۹۸۱) نظریه بنیادی انتقال مطمئن را ارائه کرد که طبق آن، مدیریت اتصال فقط به تایمرهایی نیاز دارد که با عاملی کوچک از حداکثر عمر بسته (MPL) کراندار باشند. بر اساس این نظریه، پروتکل Delta-T  توسعه یافت که وضعیت اتصال فقط با کراندار کردن سه تایمر مشخص می‌شود و نیاز به دست‌دهی ندارد. اما TCP همچنان هم دست‌دهی و هم مدیریت مبتنی بر تایمر محدود دارد.

۱۹۸۳: لایه بین‌-شبکه‌ای حذف شد

اوایل ۱۹۷۲ گروه کاری بین‌المللی شبکه (INWG) برای گردهم‌آوردن جامعه نوپای پژوهش شبکه شکل گرفت. یکی از دستاوردهای اولیه، رأی‌گیری برای یک پروتکل انتقال شبکه بین‌المللی بود که ۱۹۷۶ تأیید شد. جالب این‌که همه گزینه‌ها سه لایه با دامنه فزاینده داشتند: پیوند داده (برای انواع رسانه فیزیکی)، شبکه (برای انواع شبکه) و بین‌-شبکه (برای شبکه‌ای از شبکه‌ها) با فضای نشانی مجزا. TCP/IP در ابتدا روی لایه بین‌-شبکه و بالای پروتکل Host-IMP (ARPANET) اجرا می‌شد اما با خاموشی NCP، TCP/IP نقش شبکه را گرفت و لایه بین‌-شبکه حذف شد. این حذف دلیل نیاز به سامانه‌های مستقل و NAT امروز است.

۱۹۸۳: اولین فرصت برای اصلاح نشانی‌دهی از دست رفت
نیاز به نشانی بالاتر از IP از اواسط دهه ۷۰ میلادی شناخته شده بود. اما نام برنامه اضافه نشد و DNS همچنان به پورت‌های شناخته‌شده متکی ماند. ظهور وب و HTTP به نام برنامه نیاز داشت و URLها شکل گرفتند که هر نمونه برنامه را به یک واسط فیزیکی و یک ارتباط حمل و نقل خاص (حاوی نام DNS و پورت TCP) محدود کردند و مشکلات چندمسیری و جابجایی را به برنامه‌ها منتقل کردند.

۱۹۸۶: ازدحام شبکه اینترنت را غافلگیر کرد
هرچند مشکل کنترل ازدحام در شبکه‌های دیتاگرام از دهه ۷۰ و اوایل ۸۰ شناخته شده بود، اما فروپاشی ازدحام (congestion collapse) سال ۱۹۸۶ اینترنت را غافلگیر کرد. بدتر اینکه راهکار اعمال‌شده - طرح اجتناب ازدحام اترنت با تغییرات اندک - در TCP قرار گرفت.

۱۹۸۸: مدیریت شبکه عقب‌گرد کرد
در ۱۹۸۸ IAB توصیه کرد SNMP به‌طور موقت به عنوان پروتکل مدیریت شبکه اینترنت استفاده شود تا بعدها به رویکرد شیءگرا (CMIP) گذار کند. اما این گذار هیچ‌گاه رخ نداد.

۱۹۹۲: دومین فرصت برای اصلاح نشانی‌دهی از دست رفت
در ۱۹۹۲ IAB مجموعه‌ای توصیه برای حل مشکل مقیاس‌پذیری اینترنت مبتنی بر IPv4 ارائه کرد: مصرف فضای نشانی و انفجار اطلاعات مسیریابی. سه گزینه پیشنهاد شد: معرفی CIDR برای کاهش مشکل؛ طراحی نسخه بعدی IP (IPv7) بر اساس CLNP؛ یا ادامه پژوهش درباره نام‌گذاری، نشانی‌دهی و مسیرگزینی. CLNP پروتکل OSI بود که گره‌ها را نشانی‌دهی می‌کرد نه واسط‌ها، و مشکل چندمسیری قدیمی ARPANET را حل و تجمیع بهتر اطلاعات مسیریابی را ممکن می‌کرد. CIDR معرفی شد، اما IETF IPv7 مبتنی بر CLNP را نپذیرفت. فرایند IPng شروع شد که منجر به IPv6 شد. یکی از قوانین IPng تغییر ندادن معناشناسی نشانی IP بود، که همچنان به معنای نشانی واسط باقی ماند و مشکل چندمسیری ادامه یافت.

پروژه‌های پژوهشی
از انتشار کتاب PNA در ۲۰۰۸ تا ۲۰۱۴، پژوهش و توسعه فراوانی روی RINA انجام شد. یک گروه غیررسمی به نام انجمن پوزین به افتخار لویی پوزین چندین فعالیت بین‌المللی را هماهنگ می‌کند.

گروه پژوهشی BU
گروه تحقیقاتی RINA دانشگاه بوستون به سرپرستی اساتید ابراهیم ماتا، جان دی و لو چیتکوشف با دریافت چندین گرنت از بنیاد ملی علوم و EC، به بررسی اصول بنیادین RINA، توسعه نمونه متن‌باز بر بستر UDP/IP برای جاوا  و آزمایش روی زیرساخت GENI پرداخته‌اند. این دانشگاه از اعضای انجمن پوزین و مشارکت‌کننده فعال پروژه‌های FP7 IRATI و PRISTINE است. مفاهیم و نظریه RINA در آموزش شبکه رایانه‌ای BU نیز به کار می‌رود.

پروژه FP7 IRATI
IRATI پروژه‌ای با حمایت FP7 با پنج شریک: i2CAT، Nextworks، iMinds، Interoute و دانشگاه بوستون است که یک پیاده‌سازی متن‌باز RINA برای لینوکس بر بستر اترنت تولید کرده است.

پروژه FP7 PRISTINE
PRISTINE پروژه‌ای با حمایت FP7 با ۱۵ شریک از جمله WIT-TSSG، i2CAT، Nextworks، Telefónica I+D، Thales، Nexedi، B-ISDN، Atos، دانشگاه اسلو، Juniper Networks، دانشگاه برنو، IMT-TSP، CREATE-NET، iMinds و UPC است. هدف اصلی آن بررسی قابلیت برنامه‌پذیری RINA برای پیاده‌سازی سیاست‌های نوآورانه کنترل ازدحام، تخصیص منابع، مسیرگزینی، امنیت و مدیریت شبکه است.

پروژه IRINA (برنده Open Call جیانت۳+)
IRINA با حمایت GÉANT3+ و با چهار شریک: iMinds، WIT-TSSG، i2CAT و Nextworks اجرا شده است. هدف IRINA بررسی استفاده از RINA به عنوان پایه نسل بعدی معماری شبکه‌های NREN و GÉANT است. IRINA بر مبنای نمونه اولیه IRATI ساخته شده و RINA را در برابر وضعیت فعلی و معماری‌های نوین مقایسه می‌کند؛ مطالعه‌ای روی کاربرد RINA در سناریوهای NREN انجام می‌دهد و نمونه آزمایشگاهی ارائه می‌دهد.

## همچنین ببینید

جنگ‌های پروتکل

## منابع

## پیوند به بیرون

وب‌سایت انجمن پوزین: http://pouzinsociety.org

صفحه آموزش RINA در وب‌سایت IRATI: http://irati.eu/education/

مخزن اسناد RINA توسط TSSG: http://rina.tssg.org

آموزش RINA در کنفرانس IEEE Globecom 2014: http://www.slideshare.net/irati-project/rina-tutorial-ieee-globecom-2014

رده:معماری شبکه