پایان نامه رایگان درباره قاعده لاضرر، اشخاص ثالث

آنچه در این فرصت بیان شد بررسی جایگاه پرداخت از جانب دیگری در حوزه اجرای احکام و اسناد بوده است نتایج حاصله از این پژوهش را مورد بررسی قرار می‌دهیم:
1- با توجه به کلی بودن عنوان ایفای تعهد که در ماده 267 قانون مدنی مطرح شد در مورد خسارت تعلق گرفته به تعهد باید گفت ثالث باید نسبت به تأدیه آن ها نیز اقدام کند مگر اینکه قراری غیر از این بین او و متعهد گذاشته شود.
2- طرفین اجرای تعهد اشخاصی هستند که با هم در انعقاد تعهد دخیل بودند. ولی در مواردی ممکن است ثالث طرف اجرای تعهد باشد مثل (نماینده، قائم مقام، وراث، اشخاص ثالث دیگری …) تعهد را اجرا نمایند.
3- عمل پرداخت اثر وفای به عهد و سقوط تعهد را به همراه دارد گرچه از ناحیه مدیون نباشد.
4- در مواردی که شک در تبرعی بودن و عدم تبرعی بودن پرداخت مطرح است به حکم ماده 265 قانون مدنی و همچنین فقدان اماره مثبته آن، اصل عدم تبرعی بودن پرداخت برداشت می‌شود.
5- بنابر قاعده اولیه اجرای تعهد باید به شخص متعهدٌله صورت گیرد و در صورت خودداری وی از دریافت موضوع تعهد مدیون می‌تواند با پرداخت به نماینده قانونی، نماینده قضایی و قراردادی وی یا پرداخت به مراجع رسمی نظیر حاکم، صندوق ثبت و صندوق دادگستری صورت گیرد.
6- کسی که اقدام به پرداخت به جای متعهد میکند مال مورد پرداخت باید ملک طلق باشد و مانع قانونی و قراردادی نداشته باشد.
7- پرداخت از جانب دیگری را باید ایفای تعهد دانست چون موجب میشود طرفین تعهد به نتیجهای که مایل به آن بودهاند برسند.
8- بنابرماده 281 قانون مدنی مدیون موظف به تأدیه کلیه مخارج دین است و به تبع آن ثالث نیز موظف است به پرداخت مخارج دین مگر اینکه خلاف این موضوع شرط شده باشد.
9- درصورتی که متعهد دیون متعدد داشته باشد بنا بر ضابطه ماده 282 قانون مدنی نظر متعهد را به عنوان ضابطه معرفی کرده است در صورت حضور ثالث در جریان ایفای تعهد این حق به ثالث داده شده و در صورتی که ثالث در یکی از تعهدات ذینفع باشد صرفاً می‌تواند به ایفای آن بپردازد.
10- کسی که در تعهد نفعی دارد و به خاطر عدم وفای به عهد متعهد، منافع اش به خطر افتاده است از باب قاعده لاضرر می‌تواند اقدام به پرداخت کند. و به همین دلیل نیز حق رجوع به متعهد را پیدا میکند.]]>

پایان نامه رایگان درباره جبران خسارت، دستور موقت

طبق ماده 76 در صورتی که به نظریه ارزیاب اعتراضی وارد آید و دادگاه موافق باشد هزینه ارزیابی مجدد به عهده معترض خواهد بود. اما اگر ارزیابی مجدد بنا به تشخیص دادگاه باشد هزینه مزبور به عهده مدیون خواهد بود زیرا پرداخت مخارج تأدیه بدهی از وظایف مدیون است و ارزیابی هم از مقدمات تأدیه بدهی است. بنابراین در ارزیابی مجدد در صورتی که محکوم‌‌‌‌‌ٌعلیه از پرداخت خودداری نماید محکوم‌ٌله آن را می‌پردازد.
همچنین زمانی که دستور فروش ملکی صادر می‌شود باید مالیات قبل از تنظیم سند پرداخت شود. در این صورت هزینه مالیات نقل و انتقال ملک برای اجرای حکم ضروری است. این هزینه جزء هزینه اجرایی محسوب و مانند محکوم‌ٌبه باید تأدیه گردد.158 لذا محکوم‌‌ٌعلیه باید هزینه مزبور را متحمل شود و در صورت استنکاف، دادگاه به منظور اجرای حکم مبنی بر انتقال ملک می‌تواند اجازه دهد از وجهی که برنده مزایده به عنوان قیمت ملک به حساب محکوم‌‌‌‌‌‌‌‌‌‌‌‌ٌعلیه فروشنده پرداخت کرده است هزینه مالیاتی پرداخت شود.159
بند سوم: رجوع محکومٌ‌له پرداخت کننده حق‌الحفاظه حافظ به محکومٌ‌علیه
اموال منقول توقیف شده در همان محل که هست حفظ میشود مگر این که نقل اموال به محل دیگر ضرورت داشته باشد.160 اموال توقیف شده برای حفاظت به شخص مسؤلی که حافظ نامیده میشود سپرده میشود. حافظ نسبت به این اموال امین محسوب میشود161 و حق ندارد از آن اموال به نفع خود استفاده کند و یا آن را به کسی بدهد. در صورت مطالبه اداره ثبت، آن اموال را باید به اداره مذکور تحویل دهد در غیر این صورت ضامن است.162 طبق ماده 82 قانون اجرای احکام مدنی163 پرداخت اجرت حافظ بر عهده محکوم‌ٌعلیه است و اگر وی اجرت حافظ را نپردازد محکوم‌‌ٌله هزینه مزبور را خواهد پرداخت. مبنای این مسئولیت همان است که در ماده 76 بیان شد چرا که با توجه به این که محکومٌعلیه مدیون محسوب میشود مخارج آن هم به عهده او خواهد بود.164 در صورتی که محکوم‌ٌعلیه از پرداخت هزینه حافظ خودداری نماید اخطاری توسط مدیر اجرا به محکوم‌ٌله داده می‌شود که ظرف ده روز از تاریخ ابلاغ اخطار اجرت حافظ را بپردازد در این صورت می‌تواند از حاصل فروش اموال توقیف شده محکوم‌ٌعلیه آنچه را که پرداخته دریافت کند.اما مسئله‌ای که در مورد ماده 82 می‌توان راجع به آن بحث کرد این است که اگر محکوم‌ٌله بدون این که اخطاری جهت پرداخت حق‌الزحمه حافظ به محکوم‌ٌعلیه شده باشد این وجه را بپردازد چون بدون اذن محکوم‌ٌعلیه و بدون رعایت شرایط قانونی داده است حق مطالبه ندارد. طبق این ماده پرداخت اجرت حافظ بر عهده محکوم‌ٌعلیه است و به موجب اخطاریه به محکوم‌ٌعلیه ابلاغ تا ظرف مهلتی که در اخطاریه مشخص شده حق‌الزحمه حافظ را بپردازد. در صورت امتناع وی مراتب پرداخت به محکوم‌ٌله توسط قسمت اجرا به موجب اخطاریه ابلاغ خواهد شد. در غیر این صورت امکان مطالبه آنچه را که پرداخته نخواهد داشت.
بنابراین اگر وی قبل از مسجل شدن امتناع محکومٌ‌علیه از پرداخت اجرت حافظ، رأساً و قبل از این که برای او اخطاری مبنی بر پرداخت ارسال شود، آن را بپردازد به نظر می‌رسد مورد مشمول قواعد عام پرداخت از جانب دیگری باشد و چون در این مورد اذن در پرداخت منتفی است لذا محکومٌ‌له برای آنچه که به حافظ پرداخته است حق رجوع به محکومٌ‌علیه را ندارد.165
نظریه شماره 1266/7-14/2/77 در ارتباط با اجرت حافظ چنین مقرر داشته است: “چنانچه حافظ مطالبه اجرت نماید با توجه به مواد 81 و 82 قانون اجرای احکام مدنی دادورز می‌تواند میزان آن را تعیین و از حاصل فروش اشیای توقیف شده اجرت تعیین شده را به حافظ بپردازد. و این روش تا فروش تمامی اشیای توقیف شده می‌تواند ادامه داشته باشد.”166
بند چهارم: رجوع محکومٌ‌له پرداخت کننده سایر هزینه‌های اجرایی به محکومٌ‌علیه
در سایر مواردی که پرداخت هزینه‌ای به عهده محکومٌ‌علیه قرار می‌گیرد. هر چند که در بند 2 ماده 158 قانون اجرای احکام مدنی هزینه‌های اجرایی را نام برده است لذا ممکن است در طی اجرای احکام، مخارجی بوجود آید که اجرای حکم بدون پرداخت آن میسر نباشد. چنانچه محکوم‌ٌعلیه از پرداخت امتناع نماید محکوم‌ٌله بنا بر اخطار دایره اجرا آن را پرداخت و از اموال محکوم‌ٌعلیه به محکوم‌ٌله داده خواهد شد. این هزینه‌ها هم جزء هزینه‌های اجرایی می‌شود. به عنوان مثال حمل و نقل اموال توقیف شده به محل فروش مستلزم هزینه‌هایی است که از اموال محکوم‌ٌعلیه وصول خواهد شد.
همچنین هزینه انتشار آگهی که در ماده 118 قانون اجرای احکام مدنی167 به آن اشاره شده است مشخص نشده که چه کسی باید بپردازد؟
اما به دلالت بند 2 ماده 158 هزینه‌هایی را که برای اجرای حکم ضرورت دارد جزء هزینه اجرایی است. و با توجه به ماده 160 قانون اجرای احکام مدنی168 پرداخت این هزینه‌ها نیز بر عهده محکوم‌ٌعلیه است.
لذا کلیه هزینه‌هایی که برای اجرای حکم ضرورت دارد از قبیل وجوهی که به بانک و برا‌ی فک رهن یا اخذ مفاصا حساب باید پرداخت و به علت استنکاف محکومٌ‌علیه و یا در دسترس نبودن او محکوم‌ٌله نا‌گزیر از پرداخت آن برای فراهم کردن مقدمات اجرای حکم است، همگی مشمول بند 2 ماده 158 قانون اجرای احکام مدنی است و محکوم‌‌ٌله برای وصول آن نیازی به اقامه دعوا و تقدیم دادخواست جداگانه ندارد.169
مطابق با آئین نامه مفاد اسناد رسمی لازم‌الاجرا هزینه آگهی، دستمزد کارشناس، حق الحفاظه، حق الاجرا و حق مزایده نسبت به اموال منقول و غیرمنقول و سایر هزینه‌های قانونی به عهده متعهد می‌باشد و مانند اصل طلب وصول می‌شود. در هر مورد که این هزینه‌ها را نتوان از متعهد وصول کرد متعهدٌله باید آن را پرداخت نماید دراین صورت پس از فروش مال یا وصول طلب به موجب همان اجرائیه وصول و به متعهدٌله داده می‌شود. (ماده 40 قانون مذکور)
در فرضی که دو یا چند نفر به پرداخت مبلغی محکوم شده باشند پرداخت هزینه دادرسی از طرف یکی از آنها موجب سلب تکلیف از سایرین می‌شود. نظریه دادستان کل کشور نیز چنین است: “چون خصوصیت مسئولیت تضامنی در این است که تمام متعهدین مسئول پرداخت شیئی واحد می‌باشند همین که یکی از آنان از عهده پرداخت آن برآید رفع اشتغال ذمه از سایر متعهدین می‌شود. این قاعده نسبت به هزینه دادخواست نیز تسری دارد.”170
بند پنجم: رجوع بیمه گر به عامل زیان
طبق ماده 30 قانون بیمه171 1316در بیمه ها اگر خسارت جبران شده از سوی شرکت های بیمه و سازمان تأمین اجتماعی ناشی از عمل زیان بار شخص دیگری باشد آنها می‌توانند به عامل زیان رجوع کنند. مبنای این رجوع پرداخت دین عامل زیان به وسیله بیمهگر است زیرا مدیون واقعی عامل زیان است که با عمل زیان بار خود موجب زیان بیمه گذار شده است. ولی قانونگذار جهت جبران بهتر خسارت زیان دیدگان به آنها حق داده است که به بیمهگر مراجعه کنند. لذا آنچه بیمهگر می‌پردازد دین عامل زیان است و به همین جهت می‌تواند به وی رجوع کند.
بند ششم: رجوع بستانکار پرداخت کننده طلب بستانکار دارای وثیقه به مدیون
مطابق ماده 34 مکرر قانون ثبت172 1351 اگر شخصی بستانکاران متعدد داشته باشد و این شخص بدهکار، مالی در وثیقه یکی از بستانکاران داشته باشد یکی از بستانکاران که طلبش بدون تضمین است می‌تواند دین شخص دارای وثیقه و همچنین حقوق دولت را بپردازد و مورد وثیقه را به نفع خود بازداشت کند و با فروش آن طلب خود و آنچه را که از طرف مدیون به بستانکار دارای وثیقه پرداخته است وصول کند. در این صورت بستانکار بدون وثیقه ابتدا دین بستانکار دارای وثیقه را پرداخته سپس از محل مال مورد وثیقه تمام طلب خود را وصول می‌کند و این همان رجوع بستانکار تأدیه کننده به مدیون است. مبنای این رجوع مبتنی بر تأدیه دین مدیون از سوی بستانکار است زیرا پرداخت کننده دینی نسبت به شخص دارای وثیقه نداشته و آنچه او می‌پردازد دین مدیون است که او جهت حفظ حقوق خویش اقدام به پرداخت آن نموده است. در این جا تأدیه کننده در پرداخت دین دیگری ذینفع بوده است زیرا نفعی که بستانکار بدون وثیقه در تأدیه طلب بستانکار دارای وثیقه دارد این است که به آسانی می‌تواند از محل مال مورد وثیقه طلب خود را وصول کند وبه این ترتیب جلوی فروش مال مورد وثیقه را که ممکن است تنها دارایی مدیون باشد در یک زمانی که مال مزبور قیمت مناسبی ندارد بگیرد.
به موجب تبصره یک ماده 34 مکرر قانون ثبت173 در معاملات با حق استرداد با فوت مالک و انتقال قهری مال موضوع حق استرداد به وراث مالک حق وثیقه صاحب حق استرداد تجزیه نمی‌شود. یعنی هر ورثه‌ای نمی‌تواند با پرداخت سهم خود از دین مورث حصه خود را از مال مورد حق استرداد فک کند. زیرا شخصی که دارای حق استرداد است تمام مال مورد وثیقه در مقابل تمام طلب وی وثیقه است نه اجزای مال در مقابل اجزای طلب. به این ترتیب ممکن است برخی از وراث حاضر به پرداخت سهم خود از دین مورث نباشند در نتیجه بستانکار مال موضوع حق استرداد را به مزایده گذاشته که شاید به نفع برخی از وراث نباشد یا برخی از وراث به عین مال نیازمند باشند. لذا قانونگذار به خاطر حفظ حقوق وراث و جلوگیری از ضرر آنها این اجازه را به ایشان می‌دهد که تمام دین مورث نسبت به بستانکار را پرداخته و نسبت به حصه دیگر وراث به آنها رجوع کند و مال مزبور جهت تضمین طلب وی نسبت به وراث دیگر در وثیقه او باقی بماند. هر ورثه‌ای که سهم خود از دین مورث را به ورثه پرداخت کننده بپردازد به میزان سهمالارث وی از مال مزبور فک خواهد شد. این که با پرداخت تمام دین مورث از سوی احدی از وراث تمام مال مورد وثیقه در وثیقه پرداخت کننده قرار می‌گیرد مبنای رجوع تأدیه کننده به سایر وراث است زیرا او فقط به میزان سهمالارث خود مدیون دین مورث است و وقتی تمام طلب بستانکار را پرداخت کند در واقع سهمالارث سایر وراث از دین مورث را می‌پردازد و به همین دلیل می‌تواند به آنها رجوع کند.
بند هفتم: رجوع ظهرنویس، ضامن، قبول کننده و تأدیه کننده به صادر کننده سند تجاری
طبق ماده 249 قانون تجارت174 اگر ظهرنویسان وجه اسناد تجاری اعم از برات، سفته و چک را بپردازند آنها می‌توانند به صادر کننده سند یا به امضا کنندگان پیش از خود مراجعه کنند تا در نهایت به صادر کننده برسند. مبنای رجوع به صادر کننده سند، پرداخت دین صادر کننده به وسیله ظهرنویسان است. چون ظهرنویسان فقط طلبی را که به نفع آنها ایجاد شده است یا به آنها انتقال دا ده شده است به دیگران منتقل می‌کنند و این صادر کننده سند است که با صدور سند، موضوع آن را به وجود آورده است. ولی قانونگذار به خاطر تقویت و اعتبار بخشیدن به اسناد تجاری ظهرنویسان را در مقابل دارنده مسئول می‌داند. لذا آنچه ظهرنویسان می‌پردازند دین صادر کننده به دارنده است و پس از پرداخت می‌توانند به وی مراجعه کنند.
این وضعیت در مورد ضامن، قبول کننده ثالث و تأدیه کننده ثالث صدق می‌کند دلیل مدعای ما ماده 271 قانون تجارت175 می‌باشد زیرا این اشخاص هم فقط دین موضوع سند را تضمین یا تأدیه کرده‌اند یعنی دینی که به وسیله صادر کننده ایجاد شده است.
بندهشتم: رجوع متصدی حمل و نقل به مأمور حمل و نقل
طبق ماده 388 قانون تجارت176 قانونگذار در صورتی که متصدی حمل و نقل حتی مباشرت به حمل نکرده و شخص دیگر را مأمور حمل کرده باشد در مقابل صاحب کالا مسئول تلف یا ضایع شدن کالا می‌داند. اما در قسمت اخیر ماده این حق به متصدی حمل داده شده است که پس از جبران خسارت صاحب کالا به مأمور رجوع کند. مبنای این رجوع این است که چون مأمور حمل مسئول تلف یا ضایع شدن کالا بوده است او نیز ضامن جبران خسارت است ولی قانونگذار به خاطر تضمین بیشتر حقوق زیان دیده، متصدی حمل را در کنار وی مسئول می‌داند.
اما به لحاظ این که مدیون واقعی، مأمور است و آنچه متصدی حمل می‌پردازد دین مأمور در مقابل صاحب کالا است و به همین دلیل می‌تواند به وی مراجعه کند.
بند نهم: رجوع غاصب پرداخت کننده به غاصب متلف
طبق ماده 318 قانون مدنی177 در فرض تعاقب ایادی غاصبین در صورتی که مالک به غاصبی که مال در ید او تلف نشده است رجوع کند او نیز می‌تواند به غاصبی که مال در ید او تلف شده یا غاصین لاحق رجوع کند تا در نهایت به غاصب متلف برسد. مبنای رجوع غاصبین جبران کننده خسارت مالک، به غاصبی که مال در ید او تلف شده است پرداخت دین غاصب اخیر از سوی آنهاست. زیرا در فرضی که تعاقب ایادی غاصبان مطرح است غاصبی که مال در ید او تلف شده مدیون و غاصبان دیگر مسئول جبران خسارت هستند ولی قانگذار به خاطر حقوق مالک، غاصبان دیگر را مسئول دانسته است لذا آنچه غاصبان دیگر می‌پردازند دین غاصبی است که مال در ید او تلف شده است و به همین دلیل می‌توانند به وی مراجعه کنند. در این جا تأدیه کننده به حکم قانون به پرداخت دین مدیون ملتزم شده است.
گفتار سوم: اقدام به علت اضطرار
اصل عدم ولایت بر دیگران و اصل حاکمیت اراده ایجاب می‌کند که هیچ کس نتواند بدون داشتن نمایندگی یا اجازه از مالک یا قانون در مال و امور غیر دخالت کند یکی از دلایلی که برای دخالت در مال و امور غیر می‌توان بدان استناد ورزید قاعده “الضرورات تبیح المحظورات” می‌باشد که هنگام بروز ضرورت رافع ممنوعیت می‌شود. طبق این قاعده فقهی و عقلایی شاید بتوان گفت تنها دلیلی است که برای مشروعیت اداره مال غیر یا تصدی امور غیر مورد استفاده قرار گرفته است.178 چنانچه شخصی اقدام به پرداخت دین غیر نماید که نوعی اداره امور غیر بشمار می‌رود به این معنا‌ست که شاید ضرورت اقتضای پرداخت دین را بنماید و تأخیر باعث ضرر شود.
بعنوان مثال اگر شخصی اموال غائب یا محجور را بدون اینکه از سوی مالک اجازه داشته باشد، اداره کند در صورتی که کسب اجازه امکان پذیر بوده و عدم دخالت این شخص هم ضرری به مالک وارد نمی‌کرده، حق مطالبه مخارج را ندارد.
اما اگر عدم دخالت ثالث یا تأخیر در دخالت موجب ضرر مالک شود مستحق دریافت مخارج وارده می‌باشد.179 لذا اداره]]>

منابع پایان نامه ارشد با موضوع تلفن همراه

نگوین در پایان نامه کارشناسی ارشد خود، 3 توافق برای OF در WMN ها پیشنهاد کرد. اول، زمانی که کنترل کنند? OF متوجه می شود که اتصال در یکی از پورت های سوئیچ ها پایین است، اقدام مناسبی انجام دهید. این امر منجر به پیکر بندی مجدد پویا بر اساس توپولوژی می شود. دوم، هنگامی که ارتباط با کنترل کننده وجود ندارد، سوئیچ را برای کار در حالت مستقل آموزش دهید و نسخه ی پشتیبان کنترل کننده را برای مقابله با ناپایداری اتصالات WMN ارائه دهید. سوم، پیام هایی را که آمارها را از سوئیچ ها به کنترل کننده ها انتقال می دهند و پیام های ارسالی از سوئیچ ها را که سلامت کنترل کننده را بررسی می کنند، کاهش دهید. تطابق اول در واقع می تواند در کنترل کننده های اجرایی سفارشی، اجرا شود، اما با این وجود، با ناپایداری توپولوژی ناشی از چالش 1 مواجه است. تطابق دوم و سوم روش های فنی جالبی برای مواجه با چالش 2 می باشند.
2.14.2 SDN در محیط های ناهمگن و روستایی
حسن و همکاران [20] روش های بکارگیری SDN در شبکه های روستایی را به منظور کار کردن به عنوان ارائه دهندگان ISP زیر ساخت ها مورد بررسی قرار می دهد. این مقاله، فرصت ها و چالش های موجود در این تلاش را توضیح می دهد. در حالیکه شبکه های روستایی شباهت های بسیاری را با CN ها ارائه می دهند، این کار به مشکل موجود در روش نظری انتزاعی بدون ارائه ی هیچ گونه راه حلی نزدیک می شود. یک رویکرد مشابه و کلی تر توسط مندونکا و همکاران[21] در کنفرانس دانشجویان ACM ارائه شد. نویسندگان یک توصیف انتزاعی از چگونگی استفاده ی تکنیک های SDN در WMN های ناهمگن ارائه می دهند. آنها موارد استفاده ی اصلی را تعریف می کنند، یعنی مجموعه ای از شرایطی که SDN ناهمگن باید موارد استفاده را فعال کنند و از شرایطی که مجموعه ای از چالش های پژوهش های مواجه شده را به دست می آورند. متأسفانه هیچ ساختار و یا توصیه های فنی ارائه نشده است، اما در نظر می گیریم که تلاش آنها در تشویق مبحثی که به ایجاد سریع تر این دامنه تحقیقات منجر می شود، مهم است.
2.14.3 SDN در شبکه های تلفن همراه
یاپ [22] به همراه برخی از محرک های اولیه ی OF، OpenRoods ، یک پلت فرم مبتنی بر of را برای پژوهش در شبکه های تلفن همراه ارائه می دهد. این پلت فرم در درجه اول آزمایش های تحرک را مورد هدف قرار می دهد. OpenRoods از of برای کنترل صفحه داده ها و از SNMP برای کنترل تنظیمات دستگاه استفاده می کند. OpenRoods برای استفاده در محیط های کنترل شده با زیر ساخت همگن ارائه شده، ساخته شده است. به نظر می رسد که به جز حفظ توپولوژی و به طور ویژه توپولوژی سرویس گیرنده، این پروژه حاوی هیچ کمکی مربوط به کار ما نیست. همانطور که در بالا نشان داده شده است، SDN در WMN ها و یا در زمینه های مرتبط کاملاً نابالغ می باشند. فهرست مقالات مرتبط با آن بسیار کم است و راه حل های ارائه شده به مشکلات بسیار خاص با راه حل های بسیار خاص می پردازند. هم چنین متوجه می شویم، همانطور که قبلاً ادعا کردیم، هیچ پژوهش در به کارگیری OF در محیط های متفاوت و ناهمگن واقعا وجود ندارد. امیدواریم که تلاش های ما قادر به کمک در تکامل این موضوع باشد.
2.15 نتیجه گیری
زیرساخت‌های شبکه‌های موجود می‌توانتد به تغییر نیازمندی‌ها برای مدیریت جریان‌های ترافیکی، تهیه سطوح متمایز کیفیت سرویس و امنیت برای جریان‌های مجزا پاسخ دهند ولی این روند می‌تواند خیلی وقت‌گیر باشد و اگر شبکه در سازمانی بزرگ مثل شبکه های اجتماعی باشد و یا شامل دستگاه‌ها و تجهیزات شبکه‌ای از فروشندگان مختلف باشد، مدیر شبکه باید هر یک از تجهیزات مختلف را به طور مجزا پیکربندی نموده و پارامترهای امنیتی و کارایی را بر اساس هر session و application تنظیم نماید.
در سازمان‌های بزرگ هر بار که یک ماشین مجازی جدید ایجاد می‌شود، انجام کارهای ضروری توسط مدیر شبکه در زمینه پیکربندی مجدد آن می‌تواند ساعت‌ها و حتی روزها به طول بینجامد. در دوره mainframe، applicationها، سیستم عاملها و سخت‌افزارها همگی توسط یک سازنده تهیه می‌شدند. ولی امروزه اکثر platformها از مجموعه دستورالعمل‌های X86 و چندین سیستم عامل (ویندوز-لینوکس یا MAC OS) استفاده می‌کنند. هر سیستم عامل، APIهایی را فراهم می‌کند که به تهیه‌کنندگان خارجی این امکان را می‌دهد که applicationها را توسعه دهند که باعث نوآوری‌ها و توسعه سریع آنها می‌شود.
همان طور که بعداً خواهیم دید، معماری SDN و استاندارد OpenFlow یک معماری باز را فراهم می‌کنند که در آن توابع کنترلی از تجهیزات شبکه جدا شده است و روی سرورهای کنترل دسترسی قرار دارند. این تنظیمات باعث می‌شود زیرساخت‌های اساسی برای application ها و سرویس‌های شبکه مجزا باشند و با شبکه به عنوان یک موجودیت منطقی رفتار شود. 3 فصل سوم
روش تحقیق
3.1 مرور کلی و توصیف ساختار
به منظور ارائه درست ساختار خود، ما باید اول محیطی را که در آن آزمایشات اجرا می شود معرفی کنیم. ما یک ساختار بستر آزمایشی شبیه به جامعه آزمایشگاهی را فرض می کنیم که یک فرض معتبر است چرا که رویکردهایی را از بسترهای آزمایشی موفق موجود مانند Planetlab که برای تحقق نیازهای WMN ها و CN ها اصلاح شده به کار گرفته شده. همانطور که در شکل 3.1 مشاهده می کنید، محیط ما توسط گره های بستر آزمایشی، گره های جامعه، و سرور بستر آزمایشی و درواز? بستر آزمایشی تشکیل شده است. این آزمایش ها در واقع در گره های بستر آزمایشی انجام می شوند اما ترافیک می تواند از گره های جامعه نیز عبور کند. گره های بستر آزمایشی حداقل دو واسط شبکه دارند. شکل 3.1 ساختار کلی معماری
آنها از طریق یکی از واسط ها به شبکه مدیریت بستر آزمایشی متصل می شوند و هم چنین به سرور بستر آزمایشی می رسند. علاوه بر این، هر گره باید حداقل از یک واسط شبکه برای اتصالات بی سیم محلی به منظور ارتباط با گره های جامعه ی مجاور استفاده کند. کاربران برای ایجاد و گسترش آزمایش خود، به سرور بستر آزمایشی متصل می شوند. هنگامی که کاربر می خواهد یک آزمایش ایجاد کند، قطعه ای جدید و چندین میزبان را ایجاد می کند که به این قطعه متعلق هستند. میزبان ها به عنوان VM ها در داخل گره های بستر آزمایشی اجرا می شوند.
3.1.2 تصمیم گیری
با فرض محیط توصیف شده در بالا، می خواهیم قابلیت های بستر آزمایشی را گسترش دهیم و توانایی انجام آزمایشات L2 را با استفاده از تکنیک های SDN به آزمایشگران ارائه دهیم. گروه خاصی از آزمایش هایی که برای به کارگیری انتخاب می کنیم نیازمند توانایی مدیریت توپولوژی L2 در تمام میزبان های متعلق به یک قطعه می باشند. لازم است یادآوری کنیم که این فقط مثالی است که طراحی ما را جلو خواهد برد، اما مطمئناً تنها نوع آزمایشی که ساختار ما می تواند پشتیبانی کند، نیست. پس از توصیف تمام اینها، اکنون اقدام به ارائه ساختار خود می نماییم که مهمترین تصمیم های ما را توضیح می دهد. این تصمیم های ارائه شده می توانند در 3 گروه قرار بگیرند: پایه ای، که مربوط به زیر ساخت های لازم است؛ عاملیت، که قابلیت های مورد نظر را به سیستم اضافه می کند؛ و در نهایت بهینه سازی، که عملکرد سیستم را افزایش می دهد. این ها را با این ترتیب، با شروع از تصمیمات اساسی ارائه می دهیم.
3.1.2.1 تصمیم 1 : سوئیچ های OF در قسمت میزبان گره های بستر آزمایشی
از آنجا که می خواهیم SDN را برای آزمایشات پشتیبانی کنیم، هر گره ی آزمایشی باید سوئیچ های OF اختصاصی خود را داشته باشد. این سوئیچ ها یا می توانند داخل میزبان و یا در گره ی میزبان واقع شوند. انتخاب ما این بود که سوئیچ های OF را در گره ی میزبان قرار دهیم به طوری که کاربران بتوانند OF را بدون نیاز به جزئیات فنی مورد استفاده قرار دهند. هم چنین، این روش به OF اجازه می دهد تا از مدیران بستر آزمایشی برای مدیریت منابع شبکه ی میزبان ها، به عنوان مثال برای به کارگیری سیاست های QOS استفاده کنند. شکل 3.2 استقرار OpenVswitch
3.1.2.2 تصمیم 2 : کنترل کننده ی OF در سرور بستر آزمایشی
برای مدیریت سوئیچ های OF، به یک کنترل کننده ی OF نیاز داریم. کنترل کننده ی OF باید با تمام سوئیچ های OF و از این رو با میزبان های گره های مرتبط اتصال داشته باشد. علاوه بر این، این کنترل کننده باید در دسترس کاربر باشد چرا که نهادی است که از طریق آن سوئیچ ها می توانند مدیریت شوند. با در نظر گرفتن تمام این موارد، همراه با این واقعیت که سیستم ما باید به عنوان یک سرویس بستر آزمایشی به کار گرفته شوند، تصمیم گرفتیم که کنترل کننده ی OF را در سرور بستر آزمایشی قرار دهیم. سرور بستر آزمایشی برای تمام گره های بستر آزمایشی در دسترس است و علاوه بر آن، یک رابط برای کاربران به منظور مدیریت آزمایشات فراهم می کند. ما در حال حاضر مهم ترین نهادهای ساختار خود را قرار داده ایم. آنچه که باقی می ماند، فراهم نمودن عملکرد آزمایشات L2 و تلاش برای بهینه سازی ساختار با توجه به محیط می باشد. شکل 3.3 استقرار کنترلر
3.1.2.3 تصمیم 3 : پروتکل مسیریابی لایه 2 مش برای اتصال چندگره ای L2]]>

منابع پایان نامه ارشد با موضوع انتقال اطلاعات

2.10.5.2 VLAN
Open Flow می تواند شبکه های مجزا مانند VLAN را در اختیار کاربران بگذارد. ساده ترین راه ، تعیین VLAN ID برای Flowهای پورت های مشخص است. ترافیکی از یک کاربر فرستاده می شود و VLAN ID مناسب به آن داده می شود. راهکار های بیشتر نیز از طریق کنترل امکان پذیر است.
2.10.5.2.1 Mobile wireless VOIP Clients
کاربران VOIP می توانند ارتباط را از طریق Open Flow ایجاد کنند. کنترل کننده محل کاربران را ردیابی می کند و ارتباطات را دوباره مسیریابی می کند. کاربران با جابجا شدن میان شبکه ها و Access point های مختلف ارتباطشان قطع نمی شود و کنترل کننده ارتباط آنها را دوباره مسیریابی می کند.
2.10.5.2.2 شبکه های غیر IP
در اینجا تمام مثال ها درباره شیکه های IP بوده است اما در Open Flow لازم نیست همه شبکه ها IP باشند، تا زمانی که Header پکت ها با Flow Table منطبق باشد کافی است. این کار در آزمایش ها باعث آدرس دهی ، نامگذاری و مسیریابی های تازه می شود. Open Flow چندین راه برای پشتیبانی شبکه های Non IP پیش روی پژوهشگران می گذارد.
2.10.5.2.3 پردازش پکت ها
مثال های بالا برای پژوهش هایی بودند که کنترل کننده ، مسیر پکت ها و آغاز Flow را تعیین می کند. دو راه برای پردازش پکت ها در openflow enable switch وجود دارد. ساده ترین راه این است که تمام پکت ها از کنترل کننده عبور کنند. در این روش تمام پکت ها مستقیم به کنترل کننده فرستاده می شوند. انعطاف پذیری این روش بالاست اما عملکرد پایین است. این روش برای آزمایش پروتکل های جدید مناسب است و برای پیاده سازی در شبکه های بزرگ مناسب نیست.
راه دوم فرستادن پکت ها به سوئیچ قابل برنامه ریزی است. سوئیچ آنها را پردازش می کند.
2.10.6 Openflow
به منظور پیاده‌سازی عملی SDN دو موضوع باید در نظر گرفته شود. اول این که باید یک معماری منطقی مشترک در تمام سوئیچ‌ها، روترها و سایر تجهیزات شبکه وجود داشه باشد که توسط کنترلر SDN مدیریت شود. این معماری منطقی ممکن است به روش‌های متفاوت با تجهیزات فروشندگان مختلف و روی دستگاه‌های شبکه متفاوت پیاده‌سازی شود. دوم این که، یک پروتکل استاندارد و امن باید بین کنترلر SDN و دستگاه شبکه وجود داشته باشد.
هر دوی این نیازمندی‌ها توسط Openflow برطرف می‌شود که هم یک پروتکل بین کنترلرهای SDN و دستگاه‌های شبکه بوده و هم نمونه یک ساختار منطقی عملکردهای سوئیچ شبکه می‌باشد.
پروتکل Openflow در Openflow Switch Specification که توسط Open Networking Foundation منتشر شده است، تعریف شده است.
2.10.7 معماری منطقی سوئیچ شکل 2.16 معماری منطقی سوئیچ [8]
شکل 2.14 یک ساختار ابتدایی از محیط Openflow را نشان می‌دهد. کنترلر SDN با سوئیچ‌های سازگار با Openflow توسط پروتکل Openflow که روی SSL اجرا می‌شود ارتباط برقرار می‌کند. هر سوئیچ به سایر سوئیچ‌های Openflow و به دستگاه‌های کاربر متصل می‌شود که مبدا و مقصد بسته‌های جریان داده می‌باشند.
با هر سوئیچ یکسری جداول که بر روی سخت‌افزار یا Firmware پیاده‌سازی شده‌اند برای مدیریت جریان‌های بسته‌ها در طول سوئیچ استفاده می‌شوند.
مشخصات Openflow سه نوع جدول را در معماری منطقی سوئیچ تعریف می‌کند. جدول جریان داده که بسته‌های وارده را با یک جریان داده خاص مطابقت می‌دهد و کارهای خاصی را که باید روی بسته‌ها انجام شود را مشخص می‌کند. امکان دارد چندین جدول جریان داده وجود داشته باشد که بصورت خط لوله عمل کنند. یک جدول جریان داده ممکن است یک جریان داده را به سمت Group Table هدایت کند که این کار ممکن است باعث فعال شدن مجموعه‌ای از رفتارها شود که بر روی یک یا چند جریان داده تاثیر بگذارد. یک جدول اندازه‌گیری می‌تواند چند فعالیت مرتبط با کارایی را در جریان داده فعال سازد.
در اینجا لازم است به تعریف بهتری از جریان داده بپردازیم. یک جریان داده یک توالی از بسته های در حال عبور از شبکه می‌باشد که مجموعه‌ای از مقادیر فیلد هدر را به اشتراک می‌گذارد. به عنوان مثال یک جریان داده می‌تواند شامل تمام بسته ها با IP addressها، مبداء و مقصد یکسان، یا تمام بسته ها با مشخصه VLAN یکسان باشد.
2.10.8 مولفه‌های جدول جریان داده
هرجدول جریان داده حاوی ورودی‌هایی می‌باشد که از 6 مولفه تشکیل شده است.
2.10.8.1 Match Fields : برای انتخاب بسته‌هایی که با مقادیر داخل فیلدها مطابقت دارند استفاده می‌شود.
2.10.8.2 Priority :اولویت نسبی ورودی‌های جدول
2.10.8.3 Counters : به روز شده برای بسته‌های تطبیق داده شده. مشخصات Openflow انواع مختلف تایمرها را معرفی می‌کند مثل تعداد بایت‌های بسته‌های دریافتی در هر پورت یا در هر جدول جریان داده و یا هر ورودی جدول جریان داده ؛ تعداد بسته‌های از بین رفته و مدت زمان جریان داده
2.10.8.4 Instructions : کاری که باید انجام شود اگر تطبیق اتفاق بیفتد.
2.10.8.5 Timeouts : ماکزیمم زمان Idle (بی‌کاری) قبل از این که جریان داده توسط سوئیچ از بین برود.
2.10.8.6 Cookie : ارزش داده نامفهوم که توسط کنترلر انتخاب شده است. ممکن است توسط کنترلر برای فیلتر کردن آمار جریان داده، تغییر جریان داده و حذف جریان داده استفاده شود؛ ولی در زمان پردازش بسته استفاده نمی‌شود.
2.10.9 مولفه فیلدهای تطبیق داه شده ورودی یک جدول شامل فیلدهای ضروری زیر است:
2.10.9.1 پورت ورودی: شناسه پورت روی سوئیچ جایی که یک بسته دریافت می‌شود.
2.10.9.2 آدرس‌های مبدا و مقصد Ethernet: هر ورودی می‌تواند یک آدرس دقیق،‌یک مقدار Bitmask که تنها برخی از بیت‌های آدرس‌ آن چک شده است و یا یک مقدار جایگزین شونده (که با هر مقداری Match می‌شود) باشد.
2.10.9.3 شماره پروتکل IPV4 و IPV6: که مقدارش، header بعدی در بسته را مشخص می کند.
2.10.9.4 آدرس مبداء و مقصد IPV4 و IPV6: هر ورودی می‌تواند یک آدرس دقیق، یک مقدار bitmask، یک مقدار Subnet mask یا یک مقدار جایگزین شونده باشد.
2.10.9.5 پورت‌های TCP مبدا و مقصد: مقدار دقیق منطبق شده یا قابل جایگزین شدن
2.10.9.6 پورت‌های UDP مبدا و مقصد: مقدار دقیق منطبق شده یا قابل جایگزین شدن
2.10.9.7 فیلد‌های منطبق قبلی باید توسط هر سوئیچ سازگار با Openflow پشتیبانی شوند.
2.10.10 فیلد‌های زیر ممکن است پشتیبانی شوند:
2.10.10.1 پورت فیزیکی: برای انتخاب پورت فیزیکی، زمانی که بسته روی پورت منطقی دریافت می‌شود
2.10.10.2 Metadata : اطلاعات اضافی که می‌تواند از یک جدول به جدول دیگر هنگام پردازش بسته منتقل شود.
2.10.10.3 نوع Ethernet : فیلد نوع Ethernet
2.10.10.4 VLAN ID و VLAN User Priority
2.10.10.5 IPV4 یا IPV6 DS ، فیلد‌های سرویس‌های متمایز26 و ECN27
2.10.10.6 پورت‌های‌مبداء و مقصد 28SCTP : مقادیر دقیقا منطبق شده یا قابل جایگزین شدن
2.10.10.7 مقادیر دقیقا منطبق شده ICMP29 type Field یا قابل جایگزین شدن ICMP Code Field
2.10.10.8 کد عملیاتی ARP : با فیلد Ethernet Type به طور دقیق منطبق است.
2.10.10.9 آدرس‌های مبداء و مقصد IPV6 در ARP30 Payload می‌تواند یک آدرس دقیق، مقدار bitmask، مقدار Subnet mask یا مقدار قابل جایگزین شدن باشد
2.10.10.10 فیلدهای ICMPV6 Type و ICMPV6 Code : مقدار دقیقا منطبق شده یا قابل جایگزین شدن
2.10.10.11 IPV6 Neighbor Discovery Target Address
2.10.10.12 IPV6 Neighbor Discovery Source and Target Addresses : بخش‌های آدرس Link-Layer در یک IPV6 Neighbor Discovery message
2.10.10.13 MPLS Label Value ، Traffic Class و BoS (Bottom of Stack) فیلد‌های بالای برچسب یک MPLS Label Stack.
بنابراین، Openflow می‌تواند توسط ترافیک شبکه که شامل چندین پروتکل و سرویس‌های شبکه می‌باشد استفاده شود. توجه داشته باشید که در لایه MAC/Link، فقط Ethernet پشتیبانی می‌شود. بنابراین، Openflow نمی‌تواند ترافیک لایه 2 را روی شبکه‌های بی‌سیم کنترل کند.
حال می‌توان تعریف دقیق‌تری از جریان داده را ارائه داد. از دید یک سوئیچ، جریان داده یک توالی از بسته‌هایی است که با یک ورودی خاص در جدول جریان داده، تطبیق داده می‌شود. این تعریف از دید بسته است، به این معنی که مقدار header field های بسته باید جریان داده را ایجاد کنند نه مسیری که در طول شبکه دنبال می‌کنند. ترکیب ورودی‌های جریان داده در چندین سوئیچ، جریان داده ای را تعریف می‌کند که محدود به یک مسیر خاص است.
مولفه دستورالعمل یک ورودی جدول، شامل مجموعه‌ای از دستورالعمل‌ها می‌باشد که در صورتی که بسته با ورودی تطبیق داده شود اجرا می‌گردد. قبل از توضیح در مورد انواع دستورالعمل‌ها، باید اصطلاحات Action و Action Set تعریف شود. Actionها ارسال بسته، تغییر بسته و عملیات پردازش گروهی جدول را توصیف می‌کنند.
2.10.11 مشخصات Openflow کارهای زیر را انجام می دهد:
2.10.11.1 Output : بسته را به صورت خاصی ارسال می‌کند.
2.10.11.2 Set-Queue : مشخصه صف را برای یک بسته تنظیم می‌کند. وقتی یک بسته با استفاده از عمل output به یک پورت ارسال می‌شود، مشخصه صف مشخص می‌کند کدام صف متصل به این پورت برای برنامه‌ریزی و ارسال بسته استفاده می‌شود. مدل ارسال توسط پیکربندی صف مشخص می‌شود و یک پشتیبانی اولیه از QoS فراهم می‌کند.
2.10.11.3 گروه: بسته را در بین گروه خاصی پردازش می‌کند.
2.10.11.4 اضافه کردن / حذف کردن برچسب: ‌اضافه کردن یا حذف کردن یک برچسب برای بسته VLAN یا MPLS.
2.10.11.5 تنظیم فیلد (Set-Field): کارهای Set-Field با نوع فیلدشان از هم تشخیص داده می‌شوند. آنها مقدار header Fieldهای مخصوص به خود را در بسته تغییر می‌دهند.
2.10.11.6 تغییر TTL) TTL-Change): عملیات مختلف تغییر TTL مقادیر IPV4 Time To Live، IPv6 Hop Limit یا MPLS TTL در یک بسته را تغییر می‌دهند.
Action Set لیستی از Actionهای مرتبط با بسته می‌باشد که زمانی که بسته توسط هر جدول پردازش می‌شود روی هم انباشته می‌شود و زمانی که بسته ، خط لوله پردازش را ترک می‌کند اجرا می‌شود.
2.10.12 دستورالعمل‌ها 4 نوع هستند:
2.10.12.1 هدایت بسته در طول خط لوله: دستورالعمل Goto-Table بسته را در طول خط لوله به سمت جدول هدایت می‌کند. دستورالعمل Meter، بسته را به یک Meter خاصی هدایت می‌کند.
2.10.12.2 اجرای Action روی بسته : ممکن است Actionها زمانی که با یک ورودی جدول منطبق شوند روی بسته اجرا شوند.
2.10.12.3 به روز رسانی Action set: ادغام کردن Actionهای خاص با Action set فعلی برای همین بسته روی همین جریان داده یا پاک کردن تمام Actionها در Action set
2.10.12.4 به روز رسانی metadata: مقدار metadata می‌تواند با بسته مرتبط باشد که برای انتقال اطلاعات از یک جدول به جدول بعدی استفاده می‌شود.
2.10.13 خط لوله جدول جریان داده شکل 2.17 خط لوله ی جریان داده [8]
یک سوئیچ شامل یک یا چند جدول جریان داده می‌باشد. همانطور که در شکل 2.15 نشان داده شده است، اگر بیشتر از یک جدول جریان داده وجود داشته باشد، به صورت یک خط لوله، با جداول برچسب گذاری شده که از 0 شروع می‌شود، سازماندهی می‌شوند.
وقتی یک بسته به منظور تطبیق وارد یک جدول می‌شود، ورودی شامل بسته، مشخصه پورت ورودی، مقدار metadata مربوطه و Action Set مربوطه می‌شود. برای جدول 0، مقدار metadata خالی است و Action Set تهی است. پردازش به صورت زیر جریان می‌یابد:
ورودی جریان داده منطبق با بالاترین اولویت را پیدا کنید. اگر هیچ انطباقی با هیچ ورودی وجود ندارد و هیچ Table-miss entry وجود ندارد، بنابراین بسته از بین رفته است. اگر فقط با Table-miss entry انطباق وجود دارد، در این صورت ورودی یکی از این سه Action را مشخص می‌کند:
a ) ارسال بسته به کنترلر . این action، کنترلر را قادر می‌سازد که یک جریان داده جدید برای این بسته و بسته های مشابه تعریف کند یا تصمیم به از بین بردن بسته بگیرد.
b ) ارسال بسته به یک جریان داده Table دیگر در pipeline
c ) از بین بردن بسته
اگر انطباق با یک یا چند ورودی به جز Table-miss entry وجود داشته باشد، در این صورت انطباق به عنوان matching entry (ورودی منطبق) با بالاترین الویت شناخته می شود.
a )هر Counterای را که با این ورودی مرتبط است را به روزرسانی کنید
b ) هر دستورالعملی را که با این ورودی مرتبط است را اجرا کنید. این دستورالعمل‌ها ممکن است شامل به روز رسانی Action set، به روز رسانی مقدار metadata و اجرای Actionها باشد.
c ) سپس این بسته به یک جدول جریان داده در pipeline، به Group table یا به meter Table منتقل می‌شود یا ممکن است به سمت پورت خروجی هدایت شود.
برای آخرین جدول در pipeline، انتقال به یک جریان داده Table دیگر، یک راه‌حل نیست. زمانی که یک بسته نهایتاٌ به سمت پورت خروجی هدایت شد، یک action set اضافی اجرا می‌شود و سپس بسته برای خروج در صف قرار می‌گیرد.
2.10.14 ساختار پروتکل Openflow
پروتکل Openflow پیغام‌های رد و بدل شده بین یک Openflow کنترلر و یک Openflow Switch را توصیف می‌کند. این پروتکل روی SSL یا (Transport Layer Security) ، TLSپیاده‌سازی می‌شود و یک کانال امن Openflow را ایجاد می‌کند.
پروتکل Openflow ، کنترلر را قادر می‌سازد Actionهای اضافه کردن (Add)، به روز رسانی (update) حذف(delete)، را روی ورودی‌های جریان داده در جداول جریان داده اجرا کند. این پروتکل، همانطور که در جدول 2.3 نشان داده شده است،‌از 3 نوع پیام پشتیبانی می‌کند: جدول 2.3 پیغام های ورودی‌های جریان داده در جداول جریان داده [8]
Description
Message
Controller-to-Switch
Request the capabilities of a switch. Switch responds with a features reply that specifies its capabilities.
Features
Set and query configuration parameters. Switch responds with parameter settings.
Configuration
Add, delete, and modify flow/group entries and set switch port properties.
Modify-State
Collect information from switch, such as current configuration, statistics,]]>

تحقیق درباره تلفن همراه

نگوین در پایان نامه کارشناسی ارشد خود، 3 توافق برای OF در WMN ها پیشنهاد کرد. اول، زمانی که کنترل کنند? OF متوجه می شود که اتصال در یکی از پورت های سوئیچ ها پایین است، اقدام مناسبی انجام دهید. این امر منجر به پیکر بندی مجدد پویا بر اساس توپولوژی می شود. دوم، هنگامی که ارتباط با کنترل کننده وجود ندارد، سوئیچ را برای کار در حالت مستقل آموزش دهید و نسخه ی پشتیبان کنترل کننده را برای مقابله با ناپایداری اتصالات WMN ارائه دهید. سوم، پیام هایی را که آمارها را از سوئیچ ها به کنترل کننده ها انتقال می دهند و پیام های ارسالی از سوئیچ ها را که سلامت کنترل کننده را بررسی می کنند، کاهش دهید. تطابق اول در واقع می تواند در کنترل کننده های اجرایی سفارشی، اجرا شود، اما با این وجود، با ناپایداری توپولوژی ناشی از چالش 1 مواجه است. تطابق دوم و سوم روش های فنی جالبی برای مواجه با چالش 2 می باشند.
2.14.2 SDN در محیط های ناهمگن و روستایی
حسن و همکاران [20] روش های بکارگیری SDN در شبکه های روستایی را به منظور کار کردن به عنوان ارائه دهندگان ISP زیر ساخت ها مورد بررسی قرار می دهد. این مقاله، فرصت ها و چالش های موجود در این تلاش را توضیح می دهد. در حالیکه شبکه های روستایی شباهت های بسیاری را با CN ها ارائه می دهند، این کار به مشکل موجود در روش نظری انتزاعی بدون ارائه ی هیچ گونه راه حلی نزدیک می شود. یک رویکرد مشابه و کلی تر توسط مندونکا و همکاران[21] در کنفرانس دانشجویان ACM ارائه شد. نویسندگان یک توصیف انتزاعی از چگونگی استفاده ی تکنیک های SDN در WMN های ناهمگن ارائه می دهند. آنها موارد استفاده ی اصلی را تعریف می کنند، یعنی مجموعه ای از شرایطی که SDN ناهمگن باید موارد استفاده را فعال کنند و از شرایطی که مجموعه ای از چالش های پژوهش های مواجه شده را به دست می آورند. متأسفانه هیچ ساختار و یا توصیه های فنی ارائه نشده است، اما در نظر می گیریم که تلاش آنها در تشویق مبحثی که به ایجاد سریع تر این دامنه تحقیقات منجر می شود، مهم است.
2.14.3 SDN در شبکه های تلفن همراه
یاپ [22] به همراه برخی از محرک های اولیه ی OF، OpenRoods ، یک پلت فرم مبتنی بر of را برای پژوهش در شبکه های تلفن همراه ارائه می دهد. این پلت فرم در درجه اول آزمایش های تحرک را مورد هدف قرار می دهد. OpenRoods از of برای کنترل صفحه داده ها و از SNMP برای کنترل تنظیمات دستگاه استفاده می کند. OpenRoods برای استفاده در محیط های کنترل شده با زیر ساخت همگن ارائه شده، ساخته شده است. به نظر می رسد که به جز حفظ توپولوژی و به طور ویژه توپولوژی سرویس گیرنده، این پروژه حاوی هیچ کمکی مربوط به کار ما نیست. همانطور که در بالا نشان داده شده است، SDN در WMN ها و یا در زمینه های مرتبط کاملاً نابالغ می باشند. فهرست مقالات مرتبط با آن بسیار کم است و راه حل های ارائه شده به مشکلات بسیار خاص با راه حل های بسیار خاص می پردازند. هم چنین متوجه می شویم، همانطور که قبلاً ادعا کردیم، هیچ پژوهش در به کارگیری OF در محیط های متفاوت و ناهمگن واقعا وجود ندارد. امیدواریم که تلاش های ما قادر به کمک در تکامل این موضوع باشد.
2.15 نتیجه گیری
زیرساخت‌های شبکه‌های موجود می‌توانتد به تغییر نیازمندی‌ها برای مدیریت جریان‌های ترافیکی، تهیه سطوح متمایز کیفیت سرویس و امنیت برای جریان‌های مجزا پاسخ دهند ولی این روند می‌تواند خیلی وقت‌گیر باشد و اگر شبکه در سازمانی بزرگ مثل شبکه های اجتماعی باشد و یا شامل دستگاه‌ها و تجهیزات شبکه‌ای از فروشندگان مختلف باشد، مدیر شبکه باید هر یک از تجهیزات مختلف را به طور مجزا پیکربندی نموده و پارامترهای امنیتی و کارایی را بر اساس هر session و application تنظیم نماید.
در سازمان‌های بزرگ هر بار که یک ماشین مجازی جدید ایجاد می‌شود، انجام کارهای ضروری توسط مدیر شبکه در زمینه پیکربندی مجدد آن می‌تواند ساعت‌ها و حتی روزها به طول بینجامد. در دوره mainframe، applicationها، سیستم عاملها و سخت‌افزارها همگی توسط یک سا زنده تهیه می‌شدند. ولی امروزه اکثر platformها از مجموعه دستورالعمل‌های X86 و چندین سیستم عامل (ویندوز-لینوکس یا MAC OS) استفاده می‌کنند. هر سیستم عامل، APIهایی را فراهم می‌کند که به تهیه‌کنندگان خارجی این امکان را می‌دهد که applicationها را توسعه دهند که باعث نوآوری‌ها و توسعه سریع آنها می‌شود.
همان طور که بعداً خواهیم دید، معماری SDN و استاندارد OpenFlow یک معماری باز را فراهم می‌کنند که در آن توابع کنترلی از تجهیزات شبکه جدا شده است و روی سرورهای کنترل دسترسی قرار دارند. این تنظیمات باعث می‌شود زیرساخت‌های اساسی برای application ها و سرویس‌های شبکه مجزا باشند و با شبکه به عنوان یک موجودیت منطقی رفتار شود. 3 فصل سوم
روش تحقیق
3.1 مرور کلی و توصیف ساختار
به منظور ارائه درست ساختار خود، ما باید اول محیطی را که در آن آزمایشات اجرا می شود معرفی کنیم. ما یک ساختار بستر آزمایشی شبیه به جامعه آزمایشگاهی را فرض می کنیم که یک فرض معتبر است چرا که رویکردهایی را از بسترهای آزمایشی موفق موجود مانند Planetlab که برای تحقق نیازهای WMN ها و CN ها اصلاح شده به کار گرفته شده. همانطور که در شکل 3.1 مشاهده می کنید، محیط ما توسط گره های بستر آزمایشی، گره های جامعه، و سرور بستر آزمایشی و درواز? بستر آزمایشی تشکیل شده است. این آزمایش ها در واقع در گره های بستر آزمایشی انجام می شوند اما ترافیک می تواند از گره های جامعه نیز عبور کند. گره های بستر آزمایشی حداقل دو واسط شبکه دارند. شکل 3.1 ساختار کلی معماری
آنها از طریق یکی از واسط ها به شبکه مدیریت بستر آزمایشی متصل می شوند و هم چنین به سرور بستر آزمایشی می رسند. علاوه بر این، هر گره باید حداقل از یک واسط شبکه برای اتصالات بی سیم محلی به منظور ارتباط با گره های جامعه ی مجاور استفاده کند. کاربران برای ایجاد و گسترش آزمایش خود، به سرور بستر آزمایشی متصل می شوند. هنگامی که کاربر می خواهد یک آزمایش ایجاد کند، قطعه ای جدید و چندین میزبان را ایجاد می کند که به این قطعه متعلق هستند. میزبان ها به عنوان VM ها در داخل گره های بستر آزمایشی اجرا می شوند.
3.1.2 تصمیم گیری
با فرض محیط توصیف شده در بالا، می خواهیم قابلیت های بستر آزمایشی را گسترش دهیم و توانایی انجام آزمایشات L2 را با استفاده از تکنیک های SDN به آزمایشگران ارائه دهیم. گروه خاصی از آزمایش هایی که برای به کارگیری انتخاب می کنیم نیازمند توانایی مدیریت توپولوژی L2 در تمام میزبان های متعلق به یک قطعه می باشند. لازم است یادآوری کنیم که این فقط مثالی است که طراحی ما را جلو خواهد برد، اما مطمئناً تنها نوع آزمایشی که ساختار ما می تواند پشتیبانی کند، نیست. پس از توصیف تمام اینها، اکنون اقدام به ارائه ساختار خود می نماییم که مهمترین تصمیم های ما را توضیح می دهد. این تصمیم های ارائه شده می توانند در 3 گروه قرار بگیرند: پایه ای، که مربوط به زیر ساخت های لازم است؛ عاملیت، که قابلیت های مورد نظر را به سیستم اضافه می کند؛ و در نهایت بهینه سازی، که عملکرد سیستم را افزایش می دهد. این ها را با این ترتیب، با شروع از تصمیمات اساسی ارائه می دهیم.
3.1.2.1 تصمیم 1 : سوئیچ های OF در قسمت میزبان گره های بستر آزمایشی
از آنجا که می خواهیم SDN را برای آزمایشات پشتیبانی کنیم، هر گره ی آزمایشی باید سوئیچ های OF اختصاصی خود را داشته باشد. این سوئیچ ها یا می توانند داخل میزبان و یا در گره ی میزبان واقع شوند. انتخاب ما این بود که سوئیچ های OF را در گره ی میزبان قرار دهیم به طوری که کاربران بتوانند OF را بدون نیاز به جزئیات فنی مورد استفاده قرار دهند. هم چنین، این روش به OF اجازه می دهد تا از مدیران بستر آزمایشی برای مدیریت منابع شبکه ی میزبان ها، به عنوان مثال برای به کارگیری سیاست های QOS استفاده کنند. شکل 3.2 استقرار OpenVswitch
3.1.2.2 تصمیم 2 : کنترل کننده ی OF در سرور بستر آزمایشی
برای مدیریت سوئیچ های OF، به یک کنترل کننده ی OF نیاز داریم. کنترل کننده ی OF باید با تمام سوئیچ های OF و از این رو با میزبان های گره های مرتبط اتصال داشته باشد. علاوه بر این، این کنترل کننده باید در دسترس کاربر باشد چرا که نهادی است که از طریق آن سوئیچ ها می توانند مدیریت شوند. با در نظر گرفتن تمام این موارد، همراه با این واقعیت که سیستم ما باید به عنوان یک سرویس بستر آزمایشی به کار گرفته شوند، تصمیم گرفتیم که کنترل کننده ی OF را در سرور بستر آزمایشی قرار دهیم. سرور بستر آزمایشی برای تمام گره های بستر آزمایشی در دسترس است و علاوه بر آن، یک رابط برای کاربران به منظور مدیریت آزمایشات فراهم می کند. ما در حال حاضر مهم ترین نهادهای ساختار خود را قرار داده ایم. آنچه که باقی می ماند، فراهم نمودن عملکرد آزمایشات L2 و تلاش برای بهینه سازی ساختار با توجه به محیط می باشد. شکل 3.3 استقرار کنترلر
3.1.2.3 تصمیم 3 : پروتکل مسیریابی لایه 2 مش برای اتصال چندگره ای L2]]>

تحقیق درباره Flow، سوئیچ، OpenFlow، پکت

2.9.3.2 قابلیتهای SDNi شامل موارد زیر است:
2.9.3.2.1 هماهنگ کردن تنظیمات جریان داده که از برنامه‌هایی که حاوی اطلاعاتی مثل QoS و توافق‌های سطح سرویس بین چندین دامنه SDN می‌باشند نشأت می‌گیرد.
2.9.3.2.2 تبادل اطلاعات قابل دسترسی به منظور ساده‌سازی مسیریابی بین دامنه‌های SDN. این تبادل اطلاعات به یک جریان داده این امکان را می‌دهد که از SDNها عبور کند و هر کنترلر بهترین مسیر را در زمانی که مسیرهای مختلف در دسترس است انتخاب کند.
2.9.3.3 انواع پیام‌های SDNi شامل موارد زیر می‌باشد:
2.9.3.3.1 به روز رسانی قابلیت دسترسی
2.9.3.3.2 درخواست تنظیمات/ به روزرسانی جریان داده (که شامل مواردی مثل QoS، میزان داده انتقالی، تاخیر و… می‌باشد)
2.9.3.3.3 به روز رسانی توانایی و قابلیتها (شامل توانایی‌های مربوط به شبکه مثل میزان داده انتقالی و QoS و توانایی‌های نرم‌افزاری و سیستمی موجود در دامنه)
2.10 پروتکل OpenFlow
با افزایش روزافزون ترافیک اینترنت و پیدایش رویکردهای نوین مانند رایانش ابری و خدمات شبکه های اجتماعی، نیاز مبرم به بستری امن، سریع،گسترده و قابل توسعه بیش از پیش مشاهده می شود. لذا محققان نیاز به بستری بزرگ و نزدیک به واقعیت دارند تا بتوانند ایده ها و پروتکل های جدید را در محیطی عملیاتی آزمایش کنند. مشتریان IT نیز با خرید حجم زیادی از تجهیزات شبکه، بدنبال کنترل بیشتر و هزینه کمتر در شبکه های خود هستند؛ اما با توجه به معماری متفاوت هر تولیدکننده، جای خالی یک استاندارد که محققان و مشتریان را قادر به برنامه نویسی تجهیزات شبکه بر حسب نیازهای پژوهشی و سازمانی کند حس می شود. از این رو محققان دانشگاه استنفورد با استفاده از سرمایه بنیاد ملی علوم آمریکا به ابداع پروتکل Open Flow پرداختند[10]. این پروتکل از یک طرف امکان تجربه و آزمایش روی سوئیچ های نامتجانس را با استفاده از یک رویکرد مشترک برای محققان فراهم می سازد و از طرف دیگر این امکان را فراهم می سازد که تولیدکنندگان، مشخصات فناوری داخلی سوئیچ های خود را افشا نکنند. پروژه مربوط به این پروتکل در یک آزمایشگاه مجازی بنام GENI21که متشکل از زیرساخت شبکه 14 دانشگاه و دو شبکه اصلی ملی آمریکا می باشد، انجام می شود. به این ترتیب محققان معماری پیشنهادی خود را به طور موازی با ترافیک امروزی اینترنت اما به طور مستقل از آن آزمایش می کنند.
فناوری Open Flow بخشی از عملیات Clean Slate است که روش‏های ممکن را برای باز مهندسی اینترنت به منظور بهبود عکس‏العمل ساختارهای آن در مقابل شیوه استفاده کاربران، مورد بررسی قرار می‏دهد[11]. محققان Open Flow را به گونه‏ای طراحی کرده‏اند که بدون برهم زدن جریان تولید، پروتکل‏های جدید شبکه را درون شبکه‏های موجود آزمایش می‏کند. راهکار جایگزین دیگر، راه‏اندازی یک زیر ساخت مجزا برای انجام آزمایش‏های عملی است که هزینه بسیار زیادی را در پی دارد.
Open Flow هدف جدیدی در ارتباطات و تکنولوژی های آینده میباشد که این امکان را به ما میدهد که در انتقال و سویچینگ بسته های شبکه بتوانیم از توانایی های متعددی نظیر تست و بررسی ، استفاده از یک کنترل کننده خارجی ( Remote Controller ) و … بهره ببریم که این ویژگی جدید را میتوانیم در دستگاه هایی نظیر سویج ، روتر ، اکسس پوینت و … داشته باشیم[12] . شکل 2.12 اجزای سازنده ی Open Flow [8] Open Flow یک استاندارد آزاد جهت ارتباطات میباشد که میتواند توسط سازنده ها و تولید کننده های مختلف مورد استفاده قرار گیرد و همچنین امکان ایجاد یک پروتکل جدید را در محیط های آزمایشگاهی و آموزشی داشته باشیم[12] ، به عنوان مثال به کمک این استاندارد یک پروتکل جدید بنام Amy-OSPF ایجاد شد و قصد بر این داشت که جای OSPF را بگیرد .
از دیگر نمونه های استفاده از این پروتکل ، ایجاد یک کنترل کننده مرکزی در سطخ شبکه برای مدیریت بسته ها و سطوح دسترسی بوده است که توسط شخصی بنام Ethan مورد بررسی و آزمایش قرار گرفته شده است . شکل 2.13 نمونه ای از شبکه Openflow enabled switch [8]
در دستگاه های معمولی نظیر سویچ ها و روتر ها( Fast Packet Forwarding ) Data Plane و Control Plane (Routing Decision) هر دو در همان دستگاه صورت میگرفت در صورتی که با استفاده از تکنولوژی Open Flow این توانایی را خواهیم داشت تا مسیر دیتا در همان سویچ صورت گیرد ولی Routing Decision در یک دستگاه دیگر و یک کنترل کننده خارجی ( Remote Controller ) صورت گیرد.
با استفاده از OpenFlow می‌توان به شیوه‌ای قابل‌برنامه‌ریزی روی چگونگی راه‌اندازی و از کار انداختن شبکه‌ها براساس افزایش یا کاهش تعداد ماشین‌های مجازی دست یافت. تعیین مشخصات دقیق برای این رابط‌های برنامه‌نویسی مدیریت شبکه، کلید موفقیت SDN و OpenFlow است. اکنون که پای VMware نیز به OpenFlow باز شده است، به نظر می‌رسد باید منتظر محصولات بیشتر و پشتیبانی بهتری برای آن باشیم. همچنین، شاید تا زمانی که استانداردها تعیین نشده باشند، برخی شرکت‌ها نمونه‌های جایگزینی را هم معرفی خواهند کرد.
OpenFlow یک نمونه از تجرید انتقال از SDN می باشد. سوئیچ کنترلر های OpenFlow پروتکل های OpenFlow مولفه های اصلی OpenFlow هستند .
ساختار داخلی سوئیچ ها با هم متفاوت هستند ، هر شرکت بر اساس تجربه و امکاناتی که در اختیار مش تریانش قرار می دهد، ساختار متفاوتی را ارائه می دهد. اما بیشتر سوئیچ ها یک ویژگی مشترک دارند. Flow table ها که قابلیت Firewall , QOS , NAT را پشتیبانی می کنند.
Open Flow از این ویژگی مشترک استفاده می کند. Open Flow یک پروتکل باز لایه 2 است که ادمین های شبکه به وسیله ی آن می توانند ترافیک شبکه های آزمایشی و شبکه های واقعی را کنترل کنند. ترافیک های آزمایشی کاملا جدا از شبکه خواهند بود و این ویژگی به پژوهشگران اجازه می دهد تا پروتکل ها و راه کارهای امنیتی جدید را به راحتی آزمایش کنند. خود پژوهشگران مسئول کنترل شبکه های آزمایشی خود خواهند بود.
سوئیچ های Open Flow دارای OpenFlowTable هستند که اطلاعات تمام پکت های شبکه وارد این جدول می شود. این سوئیچ ها کمترین امکاناتی که در اختیار ادمین ها قرار می دهد کنترل و پیگیری تمام پکت های داخل شبکه است.
2.10.1 FlowTable
FlowTable های موجود در Open Flow Switch دارای سه ستون می باشند که 1- packet header جریان را تعریف می کند. 2- statistics که تعداد بسته ها و بایت های هر جریان و زمان آخرین تطبیق جریان قبلی را پیگیری می کند. (برای کمک به حذف جریان غیر فعال) و 3- Action که تعریف می کند که بسته چگونه باید پردازش شود. شکل 2.14 فیلد های یک Flow Table [29]
در داخل خود یک Open Flow Table دو جدول وجود دارد که جریان را تعریف می کند. جدول اول جدول خطی است که از whildcards برای تعریف جریان ها استفاده می کند که دارای 100 wildcard برای ورودی های جریان ها می باشد. wildcard-entry یک مدخل است که فقط بعضی فیلد های یک جریان را تعریف می کند. (MAC address, IP adress, TCP port , …) و جریان های منطبق بر این فیلد از جدول خطی را با OpenFlow switch مطابقت می دهد.
جدول دوم یک جدول مطابقت دقیق22 است که از الگوریتم HASH برای ذخیره سازی و جستجو در ورودی ها استفاده می کند. exact-match-entry یک مدخل است که تمام مقادیر ممکن برای یک جریان را تعریف می کند. (Input port ,MAC source/destination address, Ethernet protocol type, IP MAC source/destination address, ,network protocol,… – source/destination port ). Open Flow Switch تنها ورودی هایی را مطابقت می دهد که مشابه ورودی جدول HASH باشند.
2.10.2 Open Flow Switch
دو نوع OpenFlow switch وجود دارد. نوع اول سوویچ کام های تجاری مبتنی بر سخت افزار هستند که از TCAM و سیستم عامل سوئیچ/ روتر برای اجرای Flow Table و پروتکل Open Flow استفاده می کنند . نوع دوم سوئیچ های مجازی مبتنی بر نرم افزار23 هستند که با استفاده از سیستم های یونیکس/لینوکس قابل اجرا هستند تا تمام توابع Open Flow Switch را یکپارچه کنند.
Open Flow Switch حداقل باید دارای 3 ویژگی باشد:
2.10.2.1 هر flow entry را ثبت کند و روش پردازش آنها را بگوید.
2.10.2.2 دارای کانال امن باشد. این کانال ارتباط میان کنترل کننده و سوئیچ را برقرار می کند و اجازه فرستادن پکت ها را صادر می کند.
2.10.2.3 Open Flow Protocol که زبان مشترک میان کنترل کننده و سوئیچ خواهد بود.
2.10.2.4 سوئچ های مبتنی بر OpenFlow بر اساس ویژگی هایشان به دو دسته تقسیم می شوند:
* Dedicated OpenFlow Switch
* OpenFlow Enabled Switch
2.10.2.4.1 Dedicated OpenFlow Switch
پکت ها را بر اساس دستور کنترل کننده بین پورت ها می فرستد. این سوئیچ تمام پکت های TCP,IP ,MAC address,VLAN Tag را پشتیبانی می کند. برای هر flow entry سه کار انجام می دهد.
1- فرستادن flow به پکت مورد نظر
2- کپسول کردن و فرستادن پکت ها به کنترل کنده
3- از بین بردن پکت ها برای افزایش امنیت و همچنین کاهش ترافیک
Flow Table سه بخش دارد:
1- Header پکت ها
2- عملکرد، که نحوه پردازش پکت ها را عنوان می کند.
3- آمار ، که شماره و تعداد پکت های ارسالی در شبکه را نگه می دارد.
2.10.2.4.2 OpenFlow Enabled Switch
تعدادی از تولید کنندگان سوئیچ ، روتر و اکسس پوینت با اضافه کردن کانال امن، openflow protocol و Flow Table خاصیت Open Flow را به محصولاتشان اضافه کرده اند. تمام Open Flow Table ها با یک کنترل کننده، کنترل می شوند. Openflow protocol به سوویچ اجازه می دهد تا برای افزایش کیفیت و سرعت شبکه، تحت کنترل دو یا چند کنترل کننده باشد.
Openflow enabled switch باید ترافیک آزمایش را از ترافیک موجود در شبکه جدا کند که به روند نرمال سوئیچ لایه ی 2 و 3 پردازش می شود. 2 راه برای این جدا سازی ترافیک وجود دارد:
اضافه کردن مرحله 4 به مراحل سه گانه قبلی ? پکت ها را از طریق پردازش نرمال سوئیچ ها ارسال کنیم.
راه دیگر ، با ساختن Vlan ها ترافیک موجود و آزمایشی را جدا کنیم.
دو راه بالا مشکل ما را حل می کند. تمام Openflow enabled switch ها باید حداقل یکی از این راه کارها را پشتیبانی کنند.
ویژگی های اضافی OpemFlow Switch نسبت به سوئیچ های معمولی
اگر سوئیچ ، فرمت هدر و 4 عملکرد گفته شده در بالا را پشتیبانی کند به آن سوئیچ Type0 گفته می شود. شکل 2.15 هدر یک سوئیچ Type0 [30]
ما انتظار داریم که سوئیچ ها ویژگی های بیشتری را پشتیبانی کنند. برای مثال توانایی دوباره نویسی بخش هدر و یا اولویت بندی پکت ها و توانایی سازگاری با پروتکل های جدید را داشته باشند. اگر این ویژگی ها به سوئیچ اضافه شود به آن Type1 گفته می شود.
2.10.3 کنترل کننده
Flow entry را به Flow table اضافه یا حذف می کند. برای مثال کنترل کننده ای که گزارش پکت ها را ثبت می کند می تواند یک نرم افزار ساده باشد که بر روی یک کامپیوتر معمولی نصب شده است.
پژوهشگران می توانند کنترل کامل مسیریابی24 و یا ارسال پکت ها در سوئیچ را به وسیله کنترل کننده انجام دهند. بعضی از کنترل کننده ها می توانند توسط چند پژوهشگر استفاده شوند. برای هر کدام می توان دسته های جداگانه به همراه قوانین و محدودیت های مربوط به پروژه یشان تع ریف کرد.
کنترل کننده ها معمولا بر روی لینوکس و به زبان C نوشته می شوند. از انواع کنترل کننده ها می توان به موارد زیر اشاره کرد.
2.10.3.1 NOX
nox اولین کنترلر برای openflow میباشد که به زبان c++ نوشته شده و فراهم کننده ی API برای python نیز می باشد. Nox پایه ی بسیاری از پروژه های تحقیقاتی و توسعه ای در زمینه ی openflow و SDN می باشد nox دارای دو نوع توزیع می باشد .[68]
2.10.3.1.1 NOX Classic تشکیل شده است از یک توسعه ی خوش فرم که از python و c++ پشتیبانی می کند به همراه گروهی از برنامه های شبکه . با این حال این توزیع برآورده کننده ی همه ی نیاز ها نیست و برنامه ای برای توسعه های آتی ندارد.
2.10.3.1.2 NOX
2.10.3.2 nox جدید تنها از c++ پشتیبانی می کند و با برنامه های شبکه ی کمتری نسبت به NOX-Classic همراه است ، ولی دارای بستر کدینگ تمیزتر و بسیار سریعتر می باشد.
2.10.3.3 POX
pox فقط ورژن python ، NOX می باشد و عموما می تواند دارای تفکر درست تری به عنوان یک کنترلر متن باز openflow که به زبان python نوشته شده باشد و همچنین یک پلت فرم برای توسعه ی سریع تر و مدل اولیه ای برای برنامه های شبکه باشد . هدف اولیه ی POX تحقیقات می باشد.[69]
2.10.3.4 NDDI-OEE
برنامه ای برای کنترل OpenFlow سوئیچ ها می باشد و دارای یک واسط کاربری ساده و کاربر پسند برای این کار می باشد، این کنترلر در بطن خود از Nox استفاده می نماید.
2.10.3.5 Open DayLight (ODL)
OpenDaylight یک پلت فرم متن باز بر اساس جاوا برای برنامه ریزی شبکه های SDN می باشد و دارای یک واسط کاربری ساده و کاربر پسند برای این کار می باشد.
2.10.3.6 Beacon : یک کنترل کننده جاوا می باشد که بر روی OSGI ساخته شده است و به برنامه های Open Flow اجازه می دهد تا بدون قطع شدن ارتباطشان با سوئیچ، Start , Stop , Refresh و نصب شوند.
2.10.3.7 Hellos : کنترل کننده ای است که توسط NEC برای انجام آزمایشات طراحی و ساخته شده است.
2.10.3.7.1 BigSwitch : کنترل کننده ی منبع بسته است و یک محیط کاملا دوستانه برای مدیریت شبکه در اختیار کاربران می گذارد.
2.10.3.7.2 SNAC : بر اساس NOX 0. 4 نوشته شده است، قوانین انعطاف پذیری دارد و برای نصب سخت افزارها و کنترل وقایع محیط دوستانه ای دارد.
2.10.3.7.3 Maestro : کنترل کننده جاوا است که توسط دانشگاه رایس برای کارهای تحقیقاتی، نوشته و معرفی شده است
2.10.3.8 نسخه های پروتکل
در 28 فوریه سال 2011 نسخه 1. 1 این پروتکل معرفی شد که هنوز هم مورد استفاده قرار می گیرد. اما در]]>

تحقیق درباره انتقال اطلاعات

2.10.4 حالت های برنامه های کنترلی OpenFlow
دو روش مهم برای نوشتن برنامه های کاربردی برای یک شبکه OpenFlow وجود دارد:
2.10.4.1 حالت proactive
در این حالت کنترلر جریان ها را به صورت پیشبردی تنظیم می کند و در این صورت مجبور نیست برای هر بسته ی ورودی ، رویدادی تعریف کند.
2.10.4.2 حالت Reactive
در این حالت کنترلر تنها برای مقابله با یک جریان خاص اقدام به ایجاد مدهای جریانی می نماید تا به رویدادهای بسته ورودی پاسخ دهد.
2.10.5 کاربرد های Open Flow
2.10.5.1 مدیریت و کنترل شبکه
امکان مدیریت و کنترل شبکه از طریق کنترل کننده وجود دارد. می توان برای تمام کاربران قوانین و دسترسی تعریف کرد ” میهمانان می توانند از HTTP استفاده کنند اما فقط با استفاده از WebProxy “. کنترل کننده تمام پکت ها را با اطلاعات فرستندگان دسته بندی می کند و مانند DNS و DHCP کار می کند. تمام کاربران را Authenticate می کند و عملکرد تمام پورت ها را پیگیری می کند.
2.10.5.2 VLAN
Open Flow می تواند شبکه های مجزا مانند VLAN را در اختیار کاربران بگذارد. ساده ترین راه ، تعیین VLAN ID برای Flowهای پورت های مشخص است. ترافیکی از یک کاربر فرستاده می شود و VLAN ID مناسب به آن داده می شود. راهکار های بیشتر نیز از طریق کنترل امکان پذیر است.
2.10.5.2.1 Mobile wireless VOIP Clients
کاربران VOIP می توانند ارتباط را از طریق Open Flow ایجاد کنند. کنترل کننده محل کاربران را ردیابی می کند و ارتباطات را دوباره مسیریابی می کند. کاربران با جابجا شدن میان شبکه ها و Access point های مختلف ارتباطشان قطع نمی شود و کنترل کننده ارتباط آنها را دوباره مسیریابی می کند.
2.10.5.2.2 شبکه های غیر IP
در اینجا تمام مثال ها درباره شیکه های IP بوده است اما در Open Flow لازم نیست همه شبکه ها IP باشند، تا زمانی که Header پکت ها با Flow Table منطبق باشد کافی است. این کار در آزمایش ها باعث آدرس دهی ، نامگذاری و مسیریابی های تازه می شود. Open Flow چندین راه برای پشتیبانی شبکه های Non IP پیش روی پژوهشگران می گذارد.
2.10.5.2.3 پردازش پکت ها
مثال های بالا برای پژوهش هایی بودند که کنترل کننده ، مسیر پکت ها و آغاز Flow را تعیین می کند. دو راه برای پردازش پکت ها در openflow enable switch وجود دارد. ساده ترین راه این است که تمام پکت ها از کنترل کننده عبور کنند. در این روش تمام پکت ها مستقیم به کنترل کننده فرستاده می شوند. انعطاف پذیری این روش بالاست اما عملکرد پایین است. این روش برای آزمایش پروتکل های جدید مناسب است و برای پیاده سازی در شبکه های بزرگ مناسب نیست.
راه دوم فرستادن پکت ها به سوئیچ قابل برنامه ریزی است. سوئیچ آنها را پردازش می کند.
2.10.6 Openflow
به منظور پیاده‌سازی عملی SDN دو موضوع باید در نظر گرفته شود. اول این که باید یک معماری منطقی مشترک در تمام سوئیچ‌ها، روترها و سایر تجهیزات شبکه وجود داشه باشد که توسط کنترلر SDN مدیریت شود. این معماری منطقی ممکن است به روش‌های متفاوت با تجهیزات فروشندگان مختلف و روی دستگاه‌های شبکه متفاوت پیاده‌سازی شود. دوم این که، یک پروتکل استاندارد و امن باید بین کنترلر SDN و دستگاه شبکه وجود داشته باشد.
هر دوی این نیازمندی‌ها توسط Openflow برطرف می‌شود که هم یک پروتکل بین کنترلرهای SDN و دستگاه‌های شبکه بوده و هم نمونه یک ساختار منطقی عملکردهای سوئیچ شبکه می‌باشد.
پروتکل Openflow در Openflow Switch Specification که توسط Open Networking Foundation منتشر شده است، تعریف شده است.
2.10.7 معماری منطقی سوئیچ شکل 2.16 معماری منطقی سوئیچ [8]
شکل 2.14 یک ساختار ابتدایی از محیط Openflow را نشان می‌دهد. کنترلر SDN با سوئیچ‌های سازگار با Openflow توسط پروتکل Openflow که روی SSL اجرا می‌شود ارتباط برقرار می‌کند. هر سوئیچ به سایر سوئیچ‌های Openflow و به دستگاه‌های کاربر متصل می‌شود که مبدا و مقصد بسته‌های جریان داده می‌باشند.
با هر سوئیچ یکسری جداول که بر روی سخت‌افزار یا Firmware پیاده‌سازی شده‌اند برای مدیریت جریان‌های بسته‌ها در طول سوئیچ استفاده می‌شوند.
مشخصات Openflow سه نوع جدول را در معماری منطقی سوئیچ تعریف می‌کند. جدول جریان داده که بسته‌های وارده را با یک جریان داده خاص مطابقت می‌دهد و کارهای خاصی را که باید روی بسته‌ها انجام شود را مشخص می‌کند. امکان دارد چندین جدول جریان داده وجود داشته باشد که بصورت خط لوله عمل کنند. یک جدول جریان داده ممکن است یک جریان داده را به سمت Group Table هدایت کند که این کار ممکن است باعث فعال شدن مجموعه‌ای از رفتارها شود که بر روی یک یا چند جریان داده تاثیر بگذارد. یک جدول اندازه‌گیری می‌تواند چند فعالیت مرتبط با کارایی را در جریان داده فعال سازد.
در اینجا لازم است به تعریف بهتری از جریان داده بپردازیم. یک جریان داده یک توالی از بسته های در حال عبور از شبکه می‌باشد که مجموعه‌ای از مقادیر فیلد هدر را به اشتراک می‌گذارد. به عنوان مثال یک جریان داده می‌تواند شامل تمام بسته ها با IP addressها، مبداء و مقصد یکسان، یا تمام بسته ها با مشخصه VLAN یکسان باشد.
2.10.8 مو لفه‌های جدول جریان داده
هرجدول جریان داده حاوی ورودی‌هایی می‌باشد که از 6 مولفه تشکیل شده است.
2.10.8.1 Match Fields : برای انتخاب بسته‌هایی که با مقادیر داخل فیلدها مطابقت دارند استفاده می‌شود.
2.10.8.2 Priority :اولویت نسبی ورودی‌های جدول
2.10.8.3 Counters : به روز شده برای بسته‌های تطبیق داده شده. مشخصات Openflow انواع مختلف تایمرها را معرفی می‌کند مثل تعداد بایت‌های بسته‌های دریافتی در هر پورت یا در هر جدول جریان داده و یا هر ورودی جدول جریان داده ؛ تعداد بسته‌های از بین رفته و مدت زمان جریان داده
2.10.8.4 Instructions : کاری که باید انجام شود اگر تطبیق اتفاق بیفتد.
2.10.8.5 Timeouts : ماکزیمم زمان Idle (بی‌کاری) قبل از این که جریان داده توسط سوئیچ از بین برود.
2.10.8.6 Cookie : ارزش داده نامفهوم که توسط کنترلر انتخاب شده است. ممکن است توسط کنترلر برای فیلتر کردن آمار جریان داده، تغییر جریان داده و حذف جریان داده استفاده شود؛ ولی در زمان پردازش بسته استفاده نمی‌شود.
2.10.9 مولفه فیلدهای تطبیق داه شده ورودی یک جدول شامل فیلدهای ضروری زیر است:
2.10.9.1 پورت ورودی: شناسه پورت روی سوئیچ جایی که یک بسته دریافت می‌شود.
2.10.9.2 آدرس‌های مبدا و مقصد Ethernet: هر ورودی می‌تواند یک آدرس دقیق،‌یک مقدار Bitmask که تنها برخی از بیت‌های آدرس‌ آن چک شده است و یا یک مقدار جایگزین شونده (که با هر مقداری Match می‌شود) باشد.
2.10.9.3 شماره پروتکل IPV4 و IPV6: که مقدارش، header بعدی در بسته را مشخص می کند.
2.10.9.4 آدرس مبداء و مقصد IPV4 و IPV6: هر ورودی می‌تواند یک آدرس دقیق، یک مقدار bitmask، یک مقدار Subnet mask یا یک مقدار جایگزین شونده باشد.
2.10.9.5 پورت‌های TCP مبدا و مقصد: مقدار دقیق منطبق شده یا قابل جایگزین شدن
2.10.9.6 پورت‌های UDP مبدا و مقصد: مقدار دقیق منطبق شده یا قابل جایگزین شدن
2.10.9.7 فیلد‌های منطبق قبلی باید توسط هر سوئیچ سازگار با Openflow پشتیبانی شوند.
2.10.10 فیلد‌های زیر ممکن است پشتیبانی شوند:
2.10.10.1 پورت فیزیکی: برای انتخاب پورت فیزیکی، زمانی که بسته روی پورت منطقی دریافت می‌شود
2.10.10.2 Metadata : اطلاعات اضافی که می‌تواند از یک جدول به جدول دیگر هنگام پردازش بسته منتقل شود.
2.10.10.3 نوع Ethernet : فیلد نوع Ethernet
2.10.10.4 VLAN ID و VLAN User Priority
2.10.10.5 IPV4 یا IPV6 DS ، فیلد‌های سرویس‌های متمایز26 و ECN27
2.10.10.6 پورت‌های‌مبداء و مقصد 28SCTP : مقادیر دقیقا منطبق شده یا قابل جایگزین شدن
2.10.10.7 مقادیر دقیقا منطبق شده ICMP29 type Field یا قابل جایگزین شدن ICMP Code Field
2.10.10.8 کد عملیاتی ARP : با فیلد Ethernet Type به طور دقیق منطبق است.
2.10.10.9 آدرس‌های مبداء و مقصد IPV6 در ARP30 Payload می‌تواند یک آدرس دقیق، مقدار bitmask، مقدار Subnet mask یا مقدار قابل جایگزین شدن باشد
2.10.10.10 فیلدهای ICMPV6 Type و ICMPV6 Code : مقدار دقیقا منطبق شده یا قابل جایگزین شدن
2.10.10.11 IPV6 Neighbor Discovery Target Address
2.10.10.12 IPV6 Neighbor Discovery Source and Target Addresses : بخش‌های آدرس Link-Layer در یک IPV6 Neighbor Discovery message
2.10.10.13 MPLS Label Value ، Traffic Class و BoS (Bottom of Stack) فیلد‌های بالای برچسب یک MPLS Label Stack.
بنابراین، Openflow می‌تواند توسط ترافیک شبکه که شامل چندین پروتکل و سرویس‌های شبکه می‌باشد استفاده شود. توجه داشته باشید که در لایه MAC/Link، فقط Ethernet پشتیبانی می‌شود. بنابراین، Openflow نمی‌تواند ترافیک لایه 2 را روی شبکه‌های بی‌سیم کنترل کند.
حال می‌توان تعریف دقیق‌تری از جریان داده را ارائه داد. از دید یک سوئیچ، جریان داده یک توالی از بسته‌هایی است که با یک ورودی خاص در جدول جریان داده، تطبیق داده می‌شود. این تعریف از دید بسته است، به این معنی که مقدار header field های بسته باید جریان داده را ایجاد کنند نه مسیری که در طول شبکه دنبال می‌کنند. ترکیب ورودی‌های جریان داده در چندین سوئیچ، جریان داده ای را تعریف می‌کند که محدود به یک مسیر خاص است.
مولفه دستورالعمل یک ورودی جدول، شامل مجموعه‌ای از دستورالعمل‌ها می‌باشد که در صورتی که بسته با ورودی تطبیق داده شود اجرا می‌گردد. قبل از توضیح در مورد انواع دستورالعمل‌ها، باید اصطلاحات Action و Action Set تعریف شود. Actionها ارسال بسته، تغییر بسته و عملیات پردازش گروهی جدول را توصیف می‌کنند.
2.10.11 مشخصات Openflow کارهای زیر را انجام می دهد:
2.10.11.1 Output : بسته را به صورت خاصی ارسال می‌کند.
2.10.11.2 Set-Queue : مشخصه صف را برای یک بسته تنظیم می‌کند. وقتی یک بسته با استفاده از عمل output به یک پورت ارسال می‌شود، مشخصه صف مشخص می‌کند کدام صف متصل به این پورت برای برنامه‌ریزی و ارسال بسته استفاده می‌شود. مدل ارسال توسط پیکربندی صف مشخص می‌شود و یک پشتیبانی اولیه از QoS فراهم می‌کند.
2.10.11.3 گروه: بسته را در بین گروه خاصی پردازش می‌کند.
2.10.11.4 اضافه کردن / حذف کردن برچسب: ‌اضافه کردن یا حذف کردن یک برچسب برای بسته VLAN یا MPLS.
2.10.11.5 تنظیم فیلد (Set-Field): کارهای Set-Field با نوع فیلدشان از هم تشخیص داده می‌شوند. آنها مقدار header Fieldهای مخصوص به خود را در بسته تغییر می‌دهند.
2.10.11.6 تغییر TTL) TTL-Change): عملیات مختلف تغییر TTL مقادیر IPV4 Time To Live، IPv6 Hop Limit یا MPLS TTL در یک بسته را تغییر می‌دهند.
Action Set لیستی از Actionهای مرتبط با بسته می‌باشد که زمانی که بسته توسط هر جدول پردازش می‌شود روی هم انباشته می‌شود و زمانی که بسته ، خط لوله پردازش را ترک می‌کند اجرا می‌شود.
2.10.12 دستورالعمل‌ها 4 نوع هستند:
2.10.12.1 هدایت بسته در طول خط لوله: دستو رالعمل Goto-Table بسته را در طول خط لوله به سمت جدول هدایت می‌کند. دستورالعمل Meter، بسته را به یک Meter خاصی هدایت می‌کند.
2.10.12.2 اجرای Action روی بسته : ممکن است Actionها زمانی که با یک ورودی جدول منطبق شوند روی بسته اجرا شوند.
2.10.12.3 به روز رسانی Action set: ادغام کردن Actionهای خاص با Action set فعلی برای همین بسته روی همین جریان داده یا پاک کردن تمام Actionها در Action set
2.10.12.4 به روز رسانی metadata: مقدار metadata می‌تواند با بسته مرتبط باشد که برای انتقال اطلاعات از یک جدول به جدول بعدی استفاده می‌شود.
2.10.13 خط لوله جدول جریان داده شکل 2.17 خط لوله ی جریان داده [8]
یک سوئیچ شامل یک یا چند جدول جریان داده می‌باشد. همانطور که در شکل 2.15 نشان داده شده است، اگر بیشتر از یک جدول جریان داده وجود داشته باشد، به صورت یک خط لوله، با جداول برچسب گذاری شده که از 0 شروع می‌شود، سازماندهی می‌شوند.
وقتی یک بسته به منظور تطبیق وارد یک جدول می‌شود، ورودی شامل بسته، مشخصه پورت ورودی، مقدار metadata مربوطه و Action Set مربوطه می‌شود. برای جدول 0، مقدار metadata خالی است و Action Set تهی است. پردازش به صورت زیر جریان می‌یابد:
ورودی جریان داده منطبق با بالاترین اولویت را پیدا کنید. اگر هیچ انطباقی با هیچ ورودی وجود ندارد و هیچ Table-miss entry وجود ندارد، بنابراین بسته از بین رفته است. اگر فقط با Table-miss entry انطباق وجود دارد، در این صورت ورودی یکی از این سه Action را مشخص می‌کند:
a ) ارسال بسته به کنترلر . این action، کنترلر را قادر می‌سازد که یک جریان داده جدید برای این بسته و بسته های مشابه تعریف کند یا تصمیم به از بین بردن بسته بگیرد.
b ) ارسال بسته به یک جریان داده Table دیگر در pipeline
c ) از بین بردن بسته
اگر انطباق با یک یا چند ورودی به جز Table-miss entry وجود داشته باشد، در این صورت انطباق به عنوان matching entry (ورودی منطبق) با بالاترین الویت شناخته می شود.
a )هر Counterای را که با این ورودی مرتبط است را به روزرسانی کنید
b ) هر دستورالعملی را که با این ورودی مرتبط است را اجرا کنید. این دستورالعمل‌ها ممکن است شامل به روز رسانی Action set، به روز رسانی مقدار metadata و اجرای Actionها باشد.
c ) سپس این بسته به یک جدول جریان داده در pipeline، به Group table یا به meter Table منتقل می‌شود یا ممکن است به سمت پورت خروجی هدایت شود.
برای آخرین جدول در pipeline، انتقال به یک جریان داده ]]>

تحقیق درباره انتقال اطلاعات

با به کارگیری مجازی سازی در ساختار شبکه و فراهم کردن امکان جداسازی و تمییز دادن عناصر مختلف تجهیزات شبکه ای (مسیریاب ها و راه گزین ها) از جمله Control Plane و Data Plane و به وجود آوردن دسترسی مستقیم به جداول مختلف ارسال بسته ها مانند CAM Table، مدیران شبکه ها را قادر می سازد بدون نیاز به دسترسی فیزیکی به تجهیزات، نسبت به مدیریت بهینه و متمرکز تمام آنها اقدام کنند[10]. در واقع این راهکار به گونه ای امکان برنامه ریزی متمرکز ترافیک شبکه را به وجود می آورد.
تا به حال مراکز تحقیقاتی سازوکارهای مختلفی برای استفاده از راهکار SDN در شبکه ها به وجود آورده اند که کامل ترین نسخه آنها OpenFlow است که یک رابط استاندارد برای مدیریت متمرکز تجهیزات شبکه های رایانه ای در اختیار می گذارد. در واقع با استفاده از OpenFlow می توان مسیر عبور بسته ها در شبکه روی تجهیزات شبکه ای مختلف را به صورت نرم افزاری تعیین و سیاست های پیچیده مسیریابی و امنیتی را بسادگی پیاده سازی کرد.
هدف نهایی و نتیجه مطلوبی که به وسیله راهکار SDN در شبکه ها به دست خواهد آمد، به نظارت دقیق لحظه ای و بررسی صحت عملکرد بستر شبکه و همخوانی با سیاست های مدنظر و عیب یابی سریع تر و دقیق تر مشکلات در شبکه منجر خواهد شد.
SDN هم ‌اکنون برای یک مورد خاص بسیار مفید است: تنظیمات ابرهای ترکیبی (Hybrid Cloud)، یعنی جایی که برخی سرورهای شما در سازمان خودتان مستقر باشند و برخی در مراکز داده یا سرورفارم‌های یک سرویس‌دهنده دیگر. درست به همین دلیل است که نیاز است شبکه های اجتماعی (و البته دیگران) از آن‌ها برای اتصال تعداد زیاد سایت‌های بین‌المللی‌شان استفاده کنند. با OpenFlow آن‌ها می‌توانند به ظرفیت‌های جدیدی در سرتاسر جهان دست پیدا کنند و تمام این ظرفیت را مانند یک مرکز داده واحد مورد استفاده قرار دهند.
با این همه، SDN نوش‌داروی تمام مشکلات نیست. در حال حاضر شاید برای مدیران IT بهتر باشد که تنظیمات و راه‌اندازی شبکه‌ها را به صورت دستی انجام دهند تا بخواهند تمام زیرساخت موجود را دور ریخته و از تجهیزات جدید سازگار با SDN استفاده کنند. تولیدکنندگانی که سهم عمده‌ای در بازار تجهیزات زیرساخت شبکه دارند، هنوز از SDN و OpenFlow عقب هستند یا به سمت آن نمی‌روند. یک دلیل شاید این باشد که SDN را تهدیدی برای کسب‌وکار فعلی‌شان به شمار می‌آورند. البته با معمول‌تر شدن SDN و کامل‌تر شدن پروتکل‌ها این وضعیت به‌یقین تغییر خواهد کرد.
2.9.2 شبکه های نرم افزار محور
SDN یا شبکه‌های نرم‌افزارمحور سعی دارند هوشمندی شبکه‌ها را بیشتر کرده و با انتقال بخش کنترل داده‌ها از سوئیچ و روتر سخت‌افزاری به لایه‌های نرم‌افزاری مجازی شبکه و بهره‌گیری از یک کنترلر نرم‌افزاری متمرکز، قابلیت‌هایی مانند برنامه‌ریزی، مقیاس‌پذیری، انعطاف‌پذیری، خودکارسازی، هوشمندی و توسعه نرم‌افزاری شبکه توسط سازمان‌ها را فراهم کنند[9].
مدیریت و کنترل شبکه‌های بزرگ همیشه دردسرهای مخصوص به خود را دارد. یکی از آسان‌ترین روش‌های پیشگیری از بروز مشکلات و پیچیدگی‌های مدیریت شبکه‌های بزرگ استفاده از محصولات یک تولید کننده در تمامی قسمت‌های شبکه مورد نظر است. اتکا به یک تولید کننده، علاوه بر تحمیل هزینه‌های بیشتر (به خاطر محدودیت‌های مربوط به لایسنس و حق نام…) می‌تواند خلاقیت را از سازمان‌ها و شرکت‌ها دور کند.
شبکه‌های امروزی شامل کاربرانی است که بوسیله سوئیچ ها و روترها با یکدیگر ارتباط یافته‌اند. این تجهیزات به صورت دستگاه ‌هایی عرضه می‌شود که سخت‌افزار، سیستم‌‌عامل و نرم‌افزار توسط تولید‌کننده به صورت یکپارچه در آنها تعبیه شده و تغییر در سیستم‌‌عامل تقریبا امکان‌پذیر نیست. از این‌رو منطق معماری این تجهیزات را “عمودی” می‌نامند. در واقع در ساختارهای فعلی، در شبکه‌های بزرگ سوئیچ ها، روترها و سایر تجهیزات شبکه، هم داده و هم اطلاعات کنترلی را در بر دارند که کار بهینه‌سازی ساختار شبکه را بسیار مشکل می‌سازد. شکل 2.7 معماری عمودی تجهیزات فعلی شبکه
اما تجهیزاتی که برایSDN و استفاده از OpenFlow تولید می‌شود، از منطق معماری “افقی” پیروی می‌کند. در این معماری، دیگر از دستگاه‌هایی یکپارچه خبری نیست و تولیدکننده امکان استفاده از سیستم‌عامل و نرم‌افزار دلخواه مشتری را روی سخت‌افزار تولید شده فراهم می‌کند تا بتوان به‌طور سفارشی از سخت‌افزار بهره جست. در واقع از دیدگاه شبکه می‌توان گفت، قابلیت مدیریت دلخواه چند Control Plane مختلف و استفاده از نرم‌افزارهای کاربردی مجزا روی این تجهیزات فراهم می‌‌شود. در SDN، داده‌ها و اطلاعات کنترلی تجهیزات شبکه مانند سوئیچ ها و روترها، توسط یک API 20 یا رابط برنامه‌نویسی کاربردی، جدا می‌شود. شکل 2.8 معماری افقی تجهیزات شبکه ی SDN
SDN یک معماری جدید برای شبکه های کامپیوتری است که طی آن کنترل اطلاعات از خود اطلاعات و انتقال اطلاعات مجزا می شود و لایه های زیرین شبکه مانند لایه پیوند داده ها و لایه سخت افزار شبکه به لایه های بالاتر مانند لایه برنامه ها منتقل می شود. روتر ها و سوئیچ های کنونی شبکه ها هرچقدر که پیشرفته و قدرتمند باشند عملیات انتقال و کنترل اطلاعات را با هم انجام میدهند. در معماری SDN کنترل اطلاعات از سخت افزار سوئیچ و روتر مجزا شده و به یک لایه با لاتر رفته و توسط نرم افزار انجام می شود.
با مجزا شدن Control Plane از Data Plane در سخت افزارها ، شرکت ها می توانند نرم افزارها و ابزارهای زیادی برای کنترل اطلاعات نوشته و در نتیجه سرعت ، انعطاف پذیری ، مقیاس پذیری ، دسترس پذیری و قابلیت اعتماد شبکه را بیشتر کنند. شرکت های مختلف می توانند برای سخت افزارهایی با برند های مختلف API هایی بنویسند که قابلیت ها و امکانات بیشتری برای شبکه به همراه دارند و مدیریت شبکه را متمرکز و یکپارچه می کنند و همچنین امنیت شبکه بالاتر می رود زیرا کاربران با نوشتن نرم افزارهایی می توانند مدیریت و مانیتورینگ بهتر و بیشتری روی اطلاعات داشته باشند و بر اساس نیازهای شبکه و تهدیداتی که متوجه شبکه آنها است، فایروال ها و سیستم های کشف فیلترینگ را برنامه ریزی و سیاست گذاری کنند. مزیت دیگر پیکربندی مجدد شبکه و سخت افزار بدون نیاز به شرکت سازنده آن سخت افزار است. در شبکه های کنونی کاربران محدود به استفاده از فناوری و معماری ارائه شده توسط شرکت های سازنده سخت افزار هستند و نمی توانند خودشان دست به توسعه شبکه بزنند. برنامه نویسی رابط شبکه در SDN توسط خود کاربر صورت می گیرد و مطابق با نیاز های او می تواند بومی سازی شود. استاندارد SDN به گونه ای طراحی شده است که فرآیند ارسال اطلاعات در شبکه ها را آسان تر و انعطاف پذیری شبکه ها را تحت فضای برنامه ریزی شده هوشمند بیشتر می کند.
اگر بخواهیم شبکه‌های نرم‌افزارمحور یا SDN را خیلی ساده تعریف کنیم باید بگوییم: “نسل جدیدی از شبکه‌ها که با استفاده از لایه‌های مجازی، سوئیچ‌های مجازی، کنترلر مرکزی، استانداردهای ارتباطی و API های سطح بالا سعی می‌کنند برخی از کارهای کنترلی و مدیریتی سوئیچ‌ها و روترهای شبکه را در لایه‌های بالاتر به صورت نرم‌افزاری انجام دهند”. به زبان دیگر SDN وابستگی به سخت‌افزار را کاهش داده و قابلیت‌های نرم‌افزاری و هوشمندی شبکه را افزایش می‌دهد. از این رهگذر سازمان‌ها و شرکت‌های گسترده می‌توانند خودشان اقدام به برنامه‌ریزی و برنامه‌نویسی برای شبکه خودشان کرده و قابلیت‌های سفارشی و اختصاصی را به وجود بیاورند که نتیجه آن سرویس‌های جدیدی برای مشتریان است. شکل زیر شمایی از SDN را نشان می‌دهد. لایه کنترل که می‌تواند یک سوئیچ مجازی یا یک محصول کنترلر مرکزی باشد دستورات لایه برنامه‌های کاربردی را با زبان OpenFlow به سخت‌افزار منتقل و سخت‌افزار داده‌ها را براساس نیازها و سیاست‌های اعمال شده جابه‌جا و هدایت می‌کند. شکل 2.9 شمایی از SDN
* لایه زیرساخت : شامل عناصر شبکه و تجهیزاتی که Packet Switching و Forwarding را پشتیبانی می کنند.
* لایه کنترل : قابلیت تثبیت کنترل را فراهم می کند که بر روی رفتار حمل و نقل از طریق یک Open Interface نظارت دارد.
* لایه برنامه های کاربردی : شامل برنامه های کاربردی کاربر نهایی می باشد که از سرویس ها و خدمات SDN استفاده می کنند.
* API مرز بین لایه کنترل و لایه برنامه های کاربردی می باشد.
بر اساس این مدل، یک معماری SDN توسط سه ویژگی کلیدی، مشخص می شود:
0- هوش منطقی متمرکز : در یک معماری SDN، کنترل شبکه حمل و نقل با استفاده از یک رابط استاندارد توزیع شده (Open Flow) انجام می گیرد. با متمرکز شدن شبکه های اطلاعاتی، تصمیم گیری بوسیله یک دید جهانی نسبت به شبکه، نسبت به شبکه های امروزی که در آنها گره ها از حالت کلی شبکه بی اطلاع هستند راحت تر است.
1- قابلیت برنامه ریزی : شبکه های SDN ذاتا قابلیت برنامه ریزی توسط فروشندگان یا خود اپراتورهای شبکه را دارند. این قابلیت باعث می شود که الگوی مدیریت دستی با خودکارسازی جایگزین شود و همچنین با فراهم آوردن API های باز برای برقراری ارتباط برنامه های کاربردی با شبکه، شبکه های SDN می توانند نوآوری های زیادی را ایجاد کنند.
تجرید : در یک شبکه SDN ، برنامه های کاربردی کسب و کار که خدمات SDN را ارائه می دهند از تکنولوژی های زیربنایی شبکه مجزا شده اند. تجهیزات شبکه از لایه کنترل SDN مجزا شده و برنامه های کاربردی در این لایه ساکن شده اند.
2.9.3 معماری SDN :
شکل 2.8 ساختار منطقی SDN را نشان می‌دهد. کنترل‌کننده مرکزی وظیفه انجام تمام کارهای پیچیده از جمله مسیریابی، نامگذاری، سیاست‌گذاری و چک‌های امنیتی را بعهده دارد. این صفحه شامل صفحه کنترل SDN و یک یا چند سرور SDN می‌باشد. شکل 2.10 ساختار منطقی SDN [8]
کنترل‌کننده مرکزیSDN جریان‌های داده که در صفحه داده SDN جریان دارند را مشخص می‌کند. هر جریان داده در شبکه ابتدا باید از کنترلر که مشخص می‌کند ارتباطات از نظر سیاست‌های شبکه مجاز است یا خیر مجوز بگیرد. اگر کنترلرجریانی را مجاز اعلام کند، مسیر را برای آن جریان محاسبه کرده و در طول مسیر یک ورودی به آن جریان در تمام سوئیچ‌های موجود در مسیر اضافه می‌کند. سوئیچ‌ها به آسانی جداول جریان داده را که داده‌هایشان فقط توسط کنترلر می‌تواند پر شود را مدیریت می‌کنند. ارتباطات بین کنترلر و سوئیچ‌ها از یک پروتکل و API استاندارد استفاده می‌کنند. در اکثر اوقات این رابط Openflow می‌باشد که بعدا در مورد آن توضیح داده می‌شود.
معماری SDN بسیار انعطاف‌پذیر بوده و می‌تواند با انواع مختلفی از سوئیچ‌ها در لایه‌های مختلف پروتکلی کار کند. کنترلرهای SDN و سوئیچ‌ها را می‌توان برای سوئیچ‌های Ethernet (لایه 2)، Internet Router ها (لایه 3)، Transport Switching (لایه 4) یا Application Layer Switching و Routing پیاده‌سازی نمود. معماری SDN و ابسته به عملکردهای متداولی که بر روی تجهیزات شبکه وجود دارد، می‌باشد که بصورت اساسی شامل هدایت بسته ها برمبنای مدل خاصی از تعریف جریان داده است.[8]
جدول 2.2 مدل مرجع OSI و تجهیزات SDN پیاده سازی شده بر روی این مدل
پروتکل های TCP/IP
SDN
مدل مرجع OSI NFS
SMTP
TELNET
TFTP
FTP Application
RIP Persentation OSPF
Session
Dns
Udp
Tcp
Transport Switching , Application Layer Switching & Routing
Transport
ICMP
IP
Internet Router
Network
RARP
ARP Others
BATMAN
PDN
Token Ring
Ethernet
Ethernet Switch
Datalink
Physical
در معماری SDN، سوئیچ کارهای زیر را انجام می‌دهد:
* سوئیچ اولین بسته جریان داده را بسته‌بندی کرده و به کنترلر SDN ارسال می‌کند و کنترلر را قادر می‌سازد که در مورد این که آیا آن جریان باید به جدول جریان داده سوئیچ اضافه شود یا خیر تصمیم‌گیری کند.
* سوئیچ بسته وارده را با توجه به جدول جریان داده به پورت مناسب ارسال می‌کند.
* سوئیچ می‌تواند بسته را برای جریان خاصی به طور موقت یا دایمی بر اساس آنچه کنترلر مشخص کرده، حذف کند. حذف کردن بسته می‌تواند برای اهداف امنیتی، مهار حملات DOS یا نیازمندهای مدیریت ترافیک باشد.
به عبارت ساده‌تر، کنترلر SDN وضعیت Forwarding سوئیچ‌ها را در SDN مدیریت می‌کند. این مدیریت توسط یک API انجام می‌شود که به کنترلر اجازه می‌دهد طیف وسیعی از نیازمندی‌های کاربر را بدون تغییر جنبه‌های دیگر شبکه مثل توپولوژی، مدیریت کند. با جدا کردن کنترل و سطوح داده از هم، SDN برنامه‌ها را قادر می‌سازد که بدون توجه به جزییات چگونگی کار کردن دستگاه‌های شبکه، با یک دستگاه شبکه بصورت مجزا کار کنند. برنامه‌های شبکه کنترلر را توسط یک API واحد می‌بینند بنابراین می‌‌توان به سرعت برنامه‌های جدید را ایجاد کرد و گسترش داد.
2.9.3.1 دامنه‌های SDN:
در یک شبکه بزرگ، استقرار یک کنترلر واحد برای مدیریت تمام دستگاه‌های شبکه کار مناسبی نیست. یک سناریو محتمل‌تر این است که مدیر شبکه، شبکه را همانطور که در شکل 2.9 نشان داده شده است، به تعدادی دامنه SDN که همپوشانی ندارند تقسیم ‌کند. شکل 2.11 SDN Domain [8]
2.9.3.1.2 دلایل استفاه از دامنه های SDN شامل موارد زیر است:
* مقیاس‌پذیری : تعداد دستگاه‌هایی که یک SDN کنترلر می‌تواند به طور عملی مدیریت کند محدود است. بنابراین، یک شبکه بزرگ ممکن است نیاز به استقرار چندین SDN کنترلر داشته باشد.
* حریم خصوصی (Privacy)
یک سازمان ممکن است سیاست‌های حفظ‌حریم‌خصوصی‌متفاوتی را در دامنه های SDN متفاوت پیاده‌سازی کند. به عنوان مثال، یک دامنه SDN ممکن است به یک گروهی از کاربران اختصاص داده شود که سیاست‌های حفظ حریم خصوصی بسیار خاصی را لازم دارند که در این صورت لازم است یکسری اطلاعات شبکه‌ای در این دامنه (به عنوان مثال، توپولوژی شبکه) برای یک موجودیت خارجی افشا نشود.
* توسعه افزایشی (Incremental Deployment):
شبکه یک سازمان ممکن است شامل زیرساخت های قدیمی و جدید باشد. تقسیم شبکه به چندین دامنهSDN ‌ که به طور مجزا مدیریت می‌شوند، توسعه افزایشی انعطاف‌پذیری را رقم می‌زند.
وجود چندین]]>

تحقیق رایگان درمورد سازمان ملل، رفتار انسان، توسل به زور، حل و فصل اختلافات

مجمع عمومی سازمان ملل متحد در سال 1959 اعلام داشت که مسئله خلع سلاح جامع و کامل ،” مهمترین مسئله در برابر جهان است.”161 لذا از آن زمان تاکنون مسئله خلع سلاح همچنان در دستور کار مجمع عمومی این سازمان قرار داشته است. با این حال، اختلاف نظر بین دولتهایی که بیشترین سهم را در روند نظامی شدن جهان دارند، مانع تحقق این هدف انسانی شده است.
قابل ذکر است که اختلاف نظرهای اساسی میان آمریکا و شوروی از همان ابتدای تشکیل سازمان ملل متحد، مانع هرگونه پیشرفت عمده ای در زمینه خلع سلاح گردید. زیرا آمریکا بر این باور بود که خلع سلاح باید با بهبود اساسی ابزار حل و فصل اختلافات بین المللی از جمله نیروهای حافظ صلح سازمان ملل متحد توام باشد، در حالی که شوروی بر این امر تاکید می کرد که مطمئن ترین راه برای حفظ صلح و امنیت بین المللی ابتدا و پیش از هر چیز حذف تسلیحات و نیز انحلال نیروهای نظامی است. 162
از سوی دیگر برخی بر ا ین باورند که مفهوم خلع سلاح که دوبار در منشور به آن اشاره شده است163 حذف کامل تسلیحات نیست، بلکه مقصود محدودیت تسلیحات در راستای تقویت امنیت و ثبات بین المللی است و از این رو منشور در مورد عملی بودن و اجرای خلع سلاح کامل از طریق توافقهای بین المللی خوشبین نبوده است.164
معهذا سازمان ملل متحد از همان ابتدا در جهت تحقق خواست اکثر کشورها و به منظور پیشگیری از مسابقه تسلیحاتی با تلاش پیگیرانه اقدام به تشکیل دو کمیسیون کرد:
1- کمیسیون انرژی اتمی165 در سال 1946.
2- کمیسیون تسلیحاتی معمولی166 در سال 1947
ولی در سال 1952 دو کمیسیون مذکور در یک نهاد به نام ” کمیسیون خلع سلاح” ادغام شدند و کلیه اعضای دائمی شورای امنیت و همچنین کانادا که دانشمندان آن کشور در شکافت اتم فعالیت کرده بودند، اعضای کمیسیون خلع سلاح را تشکیل دادند.
در سال 1957، مجمع عمومی سازمان ملل متحد کشورهای عضو کمیسیون خلع سلاح را به 25 کشور افزایش داد و یک سال بعد کلیه کشورهای عضو سازمان ملل متحد مشمول عضویت در آن کمیسیون شدند، ولی از آنجا که چنین کمیسیونی که مرکب از بیش از یکصد کشور بود قادر نبود در امر خلع سلاح موثر واقع شود؛ لذا آمریکا و شوروی توافق کردند که کمیسیون خلع سلاح به منظور کارآیی بیشتری در انجام مذاکرات مربوط به خلع سلاح، فقط از 18 کشور تشکیل شود و مجمع عمومی سازمان ملل متحد این توافق را تایید کرد. این جلسات از سال 1961 در کاخ ملل در ژنو تشکیل شد و به نام ” کمیته 18 ملتی خلع سلاح”167 معروف گردید. دولت فرانسه، که جز 18 کشور عضو کمیسیون خلع سلاح بود، بنا به ملاحظات سیاسی از اعزام نماینده به این کمیته خودداری کرد. اعضای ” کمیته 18 ملتی خلع سلاح” در سال 1969 به 26 کشور افزایش یافت و کمیته مزبور از آن زمان تحت عنوان ” کنفرانس کمیته خلع سلاح “168 کار خود را ادامه داد.169
اعضای کنفرانس کمیته خلع سلاح در سال 1975 به 31 کشور افزایش یافت و ایران یکی از کشورهایی بود که به عضویت این کنفرانس درآمد.
در سال1979، در پی افزایش اعضای کنفرانس به 40 کشور170 نام این کنفرانس به
“کمیته خلع سلاح”171 و سپس به کنفرانس خلع سلاح172 تغییر یافت و اینک تحت این عنوان به کار خود ادامه می دهد.173
2-20. نظریه کنوانسیونهای چهارگانه در مورد اسیران جنگی
اگر به تاریخچه حمایت از اسیران جنگی توجه کنیم، می بینیم که کنفرانس 1874، بیانیه 1888 اکسفورد، کنوانسیون (2) 1899 و کنوانسیونهای 1907 ، بویژه بخش الحاقی به کنوانسیون چهارم توجه خاصی به اسیران جنگی مبذول داشته است. قدم بعدی، کنوانسیون 1929 اسیران جنگی بود که حاصل فعالیت کمیته صلیب سرخ جهانی است. نتایج آن را به طور کامل می توانیم در کنوانسیونهای اول و سوم 1949 ژنو ببینیم .
در خلال جنگ جهانی دوم،کنوانسیونهای موجود درباره حمایت از قربانیان جنگ دارای اثرات مثبت فراوان بود. ولی در عین حال، نیاز به تجدیدنظر و بسط قوانین جنگ در این خصوص بخوبی احساس می شد و این نیاز بر پایه دو اصل قرار داشت:
1- در بسیاری از حوزه ها حقوق موجود ناقص و مبهم بود
2- حتی در حوزه هایی که وضوح بیشتری به چشم می خورد ، نقضهای مکرر لزوم تدوین مکانیسم تازه ای را جهت مقابله با نقض ایجاب می کرد.
پس از جنگ جهانی دوم، کمیته بین المللی صلیب سرخ طرحی را ارائه داد که در آن توسعه حقوق بینالملل بشردوستانه در برخوردهای مسلحانه مورد نظر بود. در هفدهمین کنفرانس بینالمللی صلیب سرخ که در 1948 در استکهلم برگزار شد، مقرر گردید که متن حاصل در کنفرانس دیپلماتیک مطرحگردد. کنفرانس دیپلماتیک مزبور، تحت عنوان “کنفرانس دیپلماتیک برای ایجاد کنوانسیونهای بین المللی جهت حمایت از قربانیان جنگ” با حضور نمایندگان 64 کشور هدف خود را چنین مطرح ساخت:
1- تجدیدنظر در کنوانسیون 1929 در مورد بهبود وضع افراد بیمار و مجروح ارتش در صحنه جنگ
2- تجدیدنظر در کنوانسیون دهم 1907 لاهه
3- تجدیدنظر در مواد کنوانسیون 1929 مرتبط با رفتار با اسیران جنگی
4- ایجاد کنوانسیون جهت حمایت از افراد عادی در ایام جنگ
تجدیدنظر در مواد کنوانسیون 1929، منجر به تدوین کنوانسیون سوم ژنو در مورد اسیران جنگی شد. این کنوانسیون ، ضمن تجدیدنظری که در تقسیم بندی اشخاص رزمنده کرد، حق اسیر جنگی بودن را توسعه داد و گروههای جدیدی را نیز محق به استفاده از این امتیاز دانست، که ع بارتند از : کسانی که به دست دشمن اسیر شده اند، از جمله افراد غیرنظامی، هواپیماهای نظامی، افراد ساکن در مناطق اشغالی که با نیروهای اشغالگر در نبردند و همچنین سربازان نیروهایی که حکومتهای آنان مورد شناسایی دول متخاصم قرار نگرفته است.
با تغییراتی که پروتکل 1 در شرطهای رزمنده بودن به وجود آورده به تبع ، تعداد گروهای حائز شرایط برخورداری از وضعیت اسیر جنگی نیز افزایش یافت و رفتار عمومی ملحوظ در کنوانسیون سوم ژنو در مورد اسیران جنگی را بهبود بخشید.
2-20. قواعد ناظر بر حسن رفتار با اسیران جنگی
1- رفتار انسانی: ماده 4 مقررات لاهه، ماده 48 کنوانسیون 1929 ژن و مواد 13 و 14 کنوانسیون سوم ژنو مقرر می دارند که با اسیران جنگی باید رفتار انسانی شود.
2- عدم اعمال تلافیجویانه: ماده 2 پاراگراف 3 کنوانسیون 1929 و ماده 13 بند سوم کنوانسیون سوم ژنو بصراحت اعلام میدارد که نمی توان اسیران جنگی را موضوع اعمال تلافیجویانه قرار داد.
3- کسب اخبار و اطلاعات : تدوین شرایطی در بازجویی از اسیران جنگی، اولین بار در مقررات 1899 لاهه ظاهر شد که با امتناع بسیاری از دول امضا کننده از جمله اتریش، آلمان و ژاپن مواجه شد. ارتقای حقوق اسیران جنگی در کنوانسیون چهارم 1907 لاهه، باعث شد تا بسیاری از کشورها از امضای آن سرباز زنند، به طوری که در طول جنگ جهانی اول، دولی که این کنوانسیون را امضا نکرده بودند، تنها خود را ملزم به اجرای کنوانسیون 1899 می دانستند. طبق ماده 17 کنوانسیون سوم ژنو، کسب اطلاعات از راههای غیر قانونی از اسیران جنگی ممنوع است و اسیران تنها ملزم به دادن نام، درجه و نمره ردیف خود هستند. ماده 44 پروتکل نیز این مسئله را مورد تایید مجدد قرار داده است. خوراک و پوشاک و مراقبتهای پزشکی و لزوم وجود میزان معینی از ا صول بهداشتی در اردوگاههای محل استقرار اسیران ، از دیگر قواعد ناظر بر حسن رفتار با اسیران جنگی است.
4- در مورد لزوم مجازات قضایی: اقدام به فرار اسیران طبق ماده 8 (2) مقررات لاهه و مواد کنوانسیون سوم ژنو نمی تواند تحت مجازات قضایی قرار گیرد، ولی میتوان اقداماتی را در خصوص انضباط آنها برقرار کرد. ولی اگر از اسیر جرمی سر زند که نیازمند مجازات قضایی باشد، باید دادگاه عادل و صالحی قضاوت را عهده دار گردد.
5- در مورد کار اسیران جنگی: ماده 6 (1) مقررات لاهه و همچنین کنوانسیون 1929 ژنو اصولی را در مورد کار اسیران در نظر گرفته که کم و بیش در کنوانسیون سوم ژنو 1949 نیز تکرار شده است. ماده 50 کنوانسیون سوم ژنو بدون ذکر موارد ممنوع، حوزه های خاصی را که اسیران جنگی می توانند در آن مشغول به کار شوند، بر می شمارد؛ طبق مواد همین کنوانسیون نمی توان از اسیران جنگی درخواست کرد که به کارهای خطرناک و غیربهداشتی بپردازند.
6- استخلاص: ماده 20 مقررات لاهه ماده 75 ، بند (1) کنوانسیون 1929 ژنو و ماده 118 (1) کنوانسیون سوم 1949 ژنو، مقرر می دارند که هرچه زودتر و بدون تاخیر، پس از خاتمه متخاصمات باید اسیران آزاد شوند، ولی قواعد ناظر بر حسن رفتار، یک بار دیگر در مسئله آزادی از اسارت نیز خودنمایی میکند و آن قاعده عدم توسل به زور است. مجمع عمومی سازمان ملل متحد طی قطعنامهای در 1952 متذکر می شود که نباید به اسیران جنگی جهت بازگشت به موطن خود فشار آورد و متوسل به زور شد. همچنین کمیته صلیب سرخ جهانی در که در آزادسازی اسیران دخیل است، به شرط کسب اطلاعات موثق در این خصوص که ممکن است اسرا در هنگام بازگشت به موطن خود، مورد “رفتارهای غیرعادلانه” بر حسب زمینه های اعتقادی و نژادی و سیاسی قرار گیرند، آزادی اسیران را خلاف اصول حقوق بین ا لملل و حمایت از آحاد بشر می داند. بعضی ها به تجزیه ناپذیری مواد کنوانسیون سوم که در ماده 7 آن ذکر شده است، استناد می کنند و مسئله عدم تمایل به بازگشت در مورد اسیران جنگی را نمی پذیرند . ولی با توجه به اسناد دیگر، از جمله ماده 220 (2) عهدنامه ورسای، ماده 17 (1) عهدنامه برست لیتوسک، می توان ادعا کرد که نوعی حق عدم بازگشت برای اسیران جنگی ممکن و موجود است..
در مورد بازداشت شدگان جنگهای داخلی، مسئله متفاوت است. این عده به رغم درخواستهای مکرر و اقدامات بعضی از جناحهای جنبشهای آزادی بخش و اقدامات مجمع سازمان ملل متحد، از مواد حمایتی که در مورد اسیران جنگی وجود دارد، برخوردار نیستند، ولی پروتکل 2، رعایت بعضی از حقوق اساسی را در مورد آنان واجب و لازم می داند.
2-21. ارتقا و بهبود وضع بیماران، مجروحان و مغروقان
یکی دیگر از هدفهای بشردوستانه اسناد حقوق جنگ چگونگی رفتار با افراد زخمی و بیمار و مغروق است که برای نخستین بار در کنفرانس 1868 ژنو مورد توجه قرار گرفت و منجر به تدوین موادی شد که هیچ گاه قوت قانونی نیافت. کنفرانس نخست صلح لاهه، آن مواد را در دستور کار خود قرار داد و کنوانسیون سوم 1899 لاهه بر اساس اصول کنوانسیون 1864 ژنو شکل گرفت. در دومین کنفرانس صلح لاهه در 1907 ، مواد کنوانسیون سوم (1899)مورد بازبینی قرار گرفت و به صورت مبسوط تحت کنوانسیون دهم مدون شد. پس از جنگ جهانی اول، کوششهایی جهت تجدیدنظر در مواد کنوانسیون دهم (1907) صورت گرفت که به تهیه پیش نویسی از جانب کمیته صلیب سرخ بین المللی در 1973 انجامید، اما به علت بروز جنگ جهانی دوم مسکوت ماند.
پس از جنگ، کنوانسیون دوم ژنو (1949) جایگزین کنوانسیون دهم شد. این کنوانسیون را باید در حقیقت بسط همان کنوانسیون دانست. اصول پروتکلهای متمم به کنوانسیونهای 1 و 2 ژنو مشابه کنوانسیون دوم است.
2-22. مولفه های موجود در اجرای حقوق جنگ
1- ماده مشارکت عمومی
1- تفاوت بین توافقی که به طور عام قوت قانونی یافته است و توافقی که برای متعاهدین خاص دارای قوت قانونی می شود. توافقات نوع نخست با تحقق شرایطی خاص ( به عنوان مثال، امضای میزان مشخصی از کشورها یا تصویب توسط تعدادی معین…) محقق می شوند.در ا ین صورت ، تا عدم تحقق آن شرایط هیچ ا لتزامی، حتی برای دولتهای امضا کننده و یا تصویب کننده ، وجود ندارد، ولی هنگامی که توافق صاحب قوت قانونی شد، برای تمام تصویب کنندگان لازم الاجرا و واجب الرعایه است.
توافقات نوع دوم، همانند مورد اول، محدود به دول عضو بود و تنها شامل مواردی می باشد که طرح و ترسیم شده است. به عنوان مثال، در بسیاری از توافقات قدیمی حقوق جنگ، مثل بیانیه 1868 سن پطرزبورگ و کنوانسیون دوم 1899 لاهه و کنوانسیون 1907 ماده ای تحت عنوان ” ماده مشارکت عمومی ” وجود دارد که می گوید:
” موافقتنامه در صورتی قابل اجراست که تمام متخاصمان از اعضای موافقت نامه باشند.”
به عبارت دیگر، در صورتی که یکی از متخاصمان جزو متعاهدان نباشد، موافقت نامه به طور عملی غیر قابل اجرا می شود.
در تجزیه و تحلیل اجرای توافقات بین المللی حقوق جنگ، همیشه مسئله مشارکت عمومی و پیوستگی آن با مسئله دول عضو، موضوع پراهمیتی بوده است. می توان گفت که بعضی از اسناد و یا پاره ای از مواد مرتبط با حقوق جنگ، همان حقوق عرفی هستند که مدون شده اند و مسلما وضعیت چنین اسنادی ماهیتا با اسناد دیگر متفاوت است.
به نظر می رسد اسنادی که حاوی حقوق عرفی مدون هستند، چه ماده مشارکت عمومی در آن گنجانده شده باشد و چه نشده باشد، بر تمام متعاهدین لازم اجرا است.
حتی به رغم بسیاری ، پای بندی به اصول عرفی مدون در اسناد، برای غیر امضاکنندگان نیز واجب است. ضعف اکثر کنوانسیونهای لاهه در مورد ماده مشارکت عمومی بود. همین ماده بود که در جنگ جهانی اول باعث شد تا دول متعاهد مسئله ورود یکی از دول غیر امضاکننده به جرگه متخاصمان را دستاویز قرار داده، خود را از رعایت مقررات حقوق جنگ مبرا بدانند. حتی بعضی معتقد بودند که کنوانسیونهای لاهه تنها تا اوت 1917 برای امضاکنندگان لازم الرعایه بوده و بعد از آن، با ورود لیبریا به جنگ که جزو متعاهدین نبود، مسئله التزام دگرگون شده است.
به رغم این نظرات افراطی، بسیاری دیگر معتقدند با آنکه مقررات 1899 و 1907 کنوانسیون را تنها در مورد امضاکنندگان معتبر می دانند، ولی باید آن را به عنوان حقوق عرفی ملتها قلمداد کرد که قبال تسری به تمام اوضاع و احوال است. چنین دستاویزهایی برای رهایی از حقوق ناظر بر مخاصمات در طول جنگ جهانی دوم هم صورت گرفت. ولی دادگاههای جنایات جنگی ، در دو مسئله جداگانه، بر شمول مقرراتکنوانسیون به همهدول تاکید کردند؛ زیرا آن را منبعث از آن دستهاصولی میدانستند که موقع پذیرش وجود داشته و تمام ملل ان را به رسمیت شناخته شده بودند و تنها کنوانسیون آن را به صورت مدون درآورد بود. به عبارت دیگر، از دید دادگاه، کنوانسیون تنها حالت اخباری بر وجود اصول موجود حقوق بین الملل داشتند. دادگاه نورنبرگ، بر همین مبنا دلیل چکسلواکی را که]]>

تحقیق رایگان درمورد سازمان ملل، مکان کنترل، عرضه کننده

اختلافات آلمان، لیتوانی (1919 تا 1924)
وضعیت جزایر اولند129 در سال 1920
اختلافات لهستان و لیتوانی (1920 تا 1923)
اختلافات ارضی یوگسلاوی و یونان (1923)
بحران یونان و بلغارستان (1925)
اختلاف چین و ژاپن و حمله ایتالیا به اتیوپی
ضمنا در سپتامبر 1931، شورای جامعه ملل مقاوله نامه “بهسازی ابزار جلوگیری از جنگ” را تصویب کرد و هدف اصلی از مقاوله نامه مزبور این بود که کمیسیون بازرسی جامعه ملل130 که مسئولیتهای آن در پروتکل الحاقی آن مقاوله نامه مشخص شده بود، مجاور مناطق مورد مناقشه، حوزه های غیرنظامی ایجاد نماید، ولی مفاد مقاوله نامه مذکور هرگز اجرا نشد، زیرا در همان سال(1931) ژاپن به منچوری حمله کرد و در سالهای بعد آلمان نازی و ایتالیا نیز فعالیت جامعه ملل را در مورد حفظ صلح فلج کردند.131
2-17. فعالیت نیروهای حافظ صلح
از نیروهای چندملیتی تحت فرماندهی سازمان ملل متحد در عملیات حفظ و صلح و پیشگیری از بروز برخورد میان کشورها یا جوامع در حال تخاصم و در عین حال به منظور کمک به آنها برای آغاز و مذاکره و یافتن راه حل استفاده می گردد. در زمان نگارش این سطور، بیش از 10000 سرباز از 23 کشور عضو سازمان ملل متحد در نیروهای حافظ صلح به خدمت اشتغال دارند.
عملیات حفظ صلح یکی از بزرگترین موفقیتهای سازمان ملل متحد به شمار می رود؛ به طوری که در پی اقدامات ثمربخش این نیروها در تخفیف مناقشات و بحرانهای بین المللی در سال 1987، جایزه صلح نوبل به این نیروها اعطا شد. تاکنون 7 نیروی حافظ صلح و 7 هیئت نظامی ناظر در 13 عملیات “حفظ صلح” شرکت کرده اند. در حال حاضر نیروهای حافظ صلح و هیئتهای نظامی ناظر، به شرح زیر به ماموریتهای محوله اشتغال دارند.132
2-17-1. سازمان ناظر بر ترک مخاصمه سازمان ملل متحد ( یونتسو)133
هدف از تاسیس این سازمان در سال 1948 ، نظارت بر ترک مخاصمه در اولین جنگ اعراب و اسرائیل بود. ” یونتسو” نقش اصلی را به عنوان بخشی از نیروهای حافظ صلح در خاورمیانه به عهده دارد و از اعضای آن در زمان کوتاهی به عنوان هسته مرکزی، در سایر عملیات حفظ صلح استفاده شده است. در سال 1960 ناظران نظامی (یونتسو) فعلی در شروع عملیات سازمان ملل متحد در کنگو به لئوپولدویل (کینشازا) اعزام شدند. در حال حاضر “یونتسو” به “یوندوف” کمکهای لازم را میرساند.
2-18-2. گروه ناظر نظامی سازمان ملل متحد در هند و پاکستان ( یونموجیپ)134
طبق قطعنامه سال 1948 شورای امنیت و در پی اقدام شورای امنیت برای ایجاد نظم و امنیت در جامو و کشمیر که حاکمیت آن مورد اختلاف هند و پاکستان بود، “یونموجیپ” تشکیل شد، و در ژانویه 1949 پس از برقراری آتش بس میان هند و پاکستان برای انجام نظارت در این منطقه مستقر گردید. در قراردادی که در ژوئیه 1949 میان هند و پاکستان در کراچی به امضا رسید، بر این وظیفه گروه مزبور تاکید گردید. درحال حاضر”یونموجیپ” در دو سوی “خط کنترل”135 که هند و پاکستان در ژوئیه 1972 در “سمیلا” در مورد آن توافق کردند، مستقر می باشد.
یونموجیپ شامل 38 ناظر نظامی بوده و مقر آن هر شش ماه به ترتیب در راولپندی و سرینگار است.
2-17-3. نیروی حافظ صلح سازمان ملل متحد در قبرس ( یونفیسیپ) 136
شورای امنیت در ماه مارس 1964 پس از خشونتهای گسترده ای که میان دو جامعه ترک و یونانی ساکن قبرس درگرفت. ” یونفیسیپ” را تاسیس کرد.
در پی مداخله نظامی ترکیه در سال 1974، میان گارد ملی قبرس و نیروهای ترکیه در مورد آتش بس توافق حاصل گردید. از آن زمان تاکنون ” یونفسیپ” منطقه حائلی را به طول 180 کیلومتر در حد فاصل خطوط آتش بس کنترل می کند و امنیت غیرنظامیانی را که در حدفاصل خطوط آتش بس به سر می برند، تامین می نماید.
” یونفیسیپ” شامل 2150 نظامی و 34 غیرنظامی است و مقر آن نیکوزیا می باشد.
2-17-4. نیروی سازمان ملل متحد ناظر بر جداسازی ( یوندوف)137
هدف از تشکیل “یوندوف” جداسازی نیروهای سوریه و اسرائیل در پی جنگ اعراب و اسرائیل در سال 1973 بود. بنابر موافقت سوریه و اسرائیل در مورد جداسازی نیروها، در ماه مه 1974 یک “منطقه جداسازی”138 به طور یکسان محدود سازند.
2-17-4-1. مشارکت ایران در یوندوف
در سال 1355 هجری شمسی طبق درخواست سازمان ملل متحد یک گردان پیاده نظام ارتش ایران به عنوان بخشی از نیروهای حافظ صلح به ارتفاعات جولان در خاک سوریه، که به وسیله اسرائیل اشغال شده بود، اعزام گردید. واحد مزبور تحت فرماندهی نیروهای حافظ صلح سازمان ملل متحد بر جداسازی نیروهای اسرائیل و سوریه نظارت داشت و نیروهای ایران پس از پیروزی انقلاب اسلامی به ایران بازگشتند.
2-17-5. نیروی حائل سازمان ملل متحد در لبنان ( یونیفیل)139
شورای امنیت سازمان ملل متحد در 15 مارس 1978 در پی تجاوز اسرائیل به جنوب لبنان خواستار پایان دادن به عملیات نظامی اسرائیل در لبنان شد و به منظور آنکه از خروج نیروهای اسرائیل اطمینان بیابد و ضمنا به دولت لبنان در به دست گرفتن اختیارات حکومتی در منطقه کمک کند، در 19 مارس همان سال “یونیفیل” را تشکیل داد. پس از تجاوز اسرائیل به لبنان در سال 1982، ” یونیفیل” در ماموریت قبلی خود در منطقه ابقا شد؛ زیرا اسرائیل از خروج کامل سربازان خود از لبنان خودداری کرد، و برای خود در جنوب لبنان منطقه امنیتی تشکیل داد. این اقدام موجب شد که “یونیفیل” نتواند وظایف خود را اجرا کند.
نیروهای حائل سازمان سازمان ملل متحد در لبنان ش امل 5800 نظامی می باشد و مقر آن در ناقوره لبنان است.
2-17-6. گروه نظامی ناظر سازمان ملل متحد در ایران و عراق ( یونیماگ )140
گروه “یونیماگ” بر اساس قطعنامه 619 (اوت 1988) شورای امنیت تشکیل شد. در ابتدا مدت 6 ماه ( یعنی از تاریخ هشتم اوت 1988) مطابق با هفدهم شهریورماه 1367) به این گروه ماموریت داده شد تا بر آتش بس در مرزهای ایران و عراق نظارت کنند؛ پس از پایان مدت مزبور، در تاریخ هشتم فوریه 1989 مطابق با نوزدهم بهمن ماه 1367 ماموریت گروه مزبور از سوی شورای امنیت به مدت شش ماه دیگر تمدید گردید. گروه “یونیماگ” متشکل از 1300 نفر می باشند که از سوی کشورهای زیر اعزام شده اند:
آرژانتین، استرالیا، اتریش، بنگلادش، کانادا، دانمارک، فنلاند، غنا، مجارستان، هند، اندونزی، ایرلند، ایتالیا، کنیا، مالزی، زلاندنو، نیجریه، نروژ، لهستان، سنگال، سوئد، ترکیه، یوگسلاوی و زامبیا.
گروه مزبور شامل 350 نفر ناظر نظامی و 615 نفر نظامی می باشند که از این عده 80 نفر پلیس نظامی، 375 نفر مامور مخابرات، 130 نفر خدمه هلیکوپتر و 30 نفر دریانورد می باشند. همچنین 350 نفر غیرنظامی نیز به انجام امور اداری در گروه اشتغال دارند.
ستاد مرکزی گروه نظامی ناظر سازمان ملل متحد ( یونیماگ) در تهران و بغداد استقرار یافته است. هریک از ستادهای مزبور متشکل از سرپرست نظامیان ناظر، مشاور سیاسی ارشد، سخنگوی گروه، و سایر پرسنل اصلی است که به طور متناوب در تهران و بغداد انجام وظیفه می نمایند. ستادهای ناظرین اعزام شده، در دو ناحیه بغداد و باختران مستقر شده اند که در هریک از آنها ده نفر نظامی و عده ای از کارمندان غیرنظامی و پشتیبانی ( خدماتی) حضور دارند.
ستادهای بخش الف: در شهرهای سقز، باختران، دزفول و اهواز در ایران و بخش ب: در شهرهای کرکوک، بعقوبه و بصره در عراق استقرار یافته اند.
هریک از بخشها شامل 8 تیم متشکل از 8 نفر ناظر می باشد. همچنین نیروی ذخیره یونیماگ که شامل 30 نفر ناظر می باشد. در بغداد مستقر شده اند.141
طبق قطعنامه مجمع عمومی، در مورد تامین مالی هزینه های ” یونیماگ” مقرر گردیده است که کمکهای داوطلبانه اعضای سازمان ملل متحد به یونیماگ طبق روش مقرر در مورد نیروهای حایل سازمان ملل متحد در لبنان یونیف142 به صورت نقدی و یا تدارکاتی و خدماتی، که دبیرکل با آن موافقت می کند، انجام گیرد.143 بنا به دستورالعمل مزبور یک حساب موقتی ویژه هزینه های مربوطه باز شد.
2-18. حفظ صلح و امنیت بین المللی
بحث درباره خلع سلاح در سازمان ملل متحد ، در حقیقت بحث در مورد مسائل عمده ای چون صلح و امنیت بین المللی است. امروزه به منظور حفظ صلح و امنیت بین المللی، خلع سلاح به صورت محور اصلی کلیه اقدامات سازمانهای بین المللی در آمده است و در واقع هیچ یک از اصول مندرج در منشور، مانند کنترل تسلیحات و خلع سلاح تا این حد به حیات و بقای بشر بستگی ندارد.144 در آن جدایی طلبان و نیروهای چریک هر دو طرف شرکت داشته اند.145
در جریان جنگهای مزبور متاسفانه اغلب قواعد و مقررات جنگی ناظر بر رفتار نیروهای نظامی در جریان جنگ، ماند آنچه که در مقاوله نامه های بین المللی سالهای 1461899 و 1907147 لاهه و 1948148 ژنو که مفاد آن به منظور کاهش اثرات جنگ بر غیر نظامیان، حمایت از اسرای جنگی، و ممنوعیت برخی از سلاحها تدوین و توصیه گردیده است اجرا نشده است نقض آشکار مقررات مزبور بخصوص کاربرد وسیع سلاحهای شیمیایی از سوی رژیم عراق (که بعدا در گزارش سازمان ملل متحد نیز منعکس شده) از جمله موارد بارز چنین تخلفاتی به شمار می رود. به هر حال یکی از مسائل مهمی که در سالهای اخیر در زمینه خلع سلاح خودنمایی کرده است، کاربرد وسیع سلاحهای شیمیایی و خطر اشاعه جهانی این سلاح مرگبار و همچنین پیدایش موشکهای برد متوسط در زاردخانه بسیاری از کشورهای کوچک و متوسط است که در نتیجه خطر گسترش جنگها و اثرات مرگبار، سلاحهای به کار رفته را در ابعادی وسیع افزایش داده است. علاوه بر این دورنمای نظامی شدن فضای ماورای جو و استفاده از سیستمهای تسلیحاتی خودکار ( بدون نیاز به حضور انسان در صحنه نبرد) امکان کنترل تشنجات سیاسی، و محدود ساختن دامنه مناقشات نظامی و در کل جنگها را بیش از پیش دشوار ساخته است.
از زمان جنگ جهانی دوم به این طرف کاربرد سلاحهای معمولی در جنگها، به تنهایی موجب مرگ میلیونها نفر شده است.
در سند نهایی اولین اجلاس ویژه سازمان ملل متحد در مورد خلع سلاح که در سال 1978 تشکیل گردید، از کشورهای عرضه کننده عمده و کشورهای دریافت کننده تسلیحات خواسته شد انتقال سلاحهای معمولی را محدود نمایند تا بدین وسیله امنیت و ثبات در سطح پایین تری از تمهیدات نظامی برقرار شود.149
در طی دومین اجلاس ویژه خلع سلاح در سال 1982 و سومین اجلاس ویژه خلع سلاح150 در سال 1987 نیز بر توصیه های اولین اجلاس ویژه تاکید گردید، و به طور کلی اکثر کشورهای خواستار تحقق امور زیر بودند:
– توقف کلیه آزمایشهای سلاحهای هسته ای؛ از جمله آزمایشهای زیرزمینی سلاحهای هستهای و امضای قرارداد منع جامع آزمایشهای هسته ای.
– تثبیت151 سقف سلاحهای هسته ای کلیه کشورهای دارنده سلاح هسته ای، بویژه شوروی و آمریکا
– تعیین مناطق عاری از سلاح هسته ای در خاورمیانه و آسیای جنوبی و اجرای اعلامیه 1971 مبنی بر اعلام اقیانوس هند به عنوان منطقه صلح.152
– انعقاد مقاوله نامه بین المللی در مورد تقویت امنیت کشورهای غیر هسته ای در برابر تهدید و یا استفاده از سلاح هسته ای .
– انعقاد مقاوله نامه بین المللی در مورد ممنوعیت توسعه، تولید، انباشت و کاربرد انواع سلاحهای شیمیایی، بیولوژیکی و رادیولوژیکی و انهدام سلاحهای موجود.
– انعقاد پیمان ممنوعیت توسعه و تولید سلاحهای انهدام وسیع و سیستمهای جدید تسلیحاتی
– کاهش بودجه نظامی و تخصیص منابعی که اینک برای مقاصد نظامی به کار می روند؛ جهت اجرای برنامه های توسعه اقتصادی و اجتماعی کشورها، خاصه در کشورهای در حال توسعه .153
قابل ذکر است که سازمان ملل متحد فقط به صدور قطعنامه ها در مورد خلع سلاح بسنده نکرده است، بلکه از طریق کنفرانس 40 ملتی154 خلع سلاح در ژنو نیز در مذاکرات دوجانبه شرق و غرق شرکت کرده و زمینه انعقاد قراردادهایی را در مورد خلع سلاح فراهم نموده است.155
سازمان ملل متحد همچنین به وسیله تشکیل گروههای کاری، هیئتهای حقیقت یاب156 و انتشار نشریات مختلف به مسائل اساسی خلع سلاح مانند نقل و انتقالات تسلیحات معمولی، سلاحهای شیمیایی ، آزمایشهای سلاحهای هسته ای، و محدودیت بودجه نظامی توجه خاصی مبذول نموده است.
اقدامات مهمی که در زمینه انعقاد معاهدات چند جانبه مربوط به خلع سلاح تاکنون به عمل آمده است عبارتند از :
– معاهده قطب جنوب157 که در سال 1959 منعقد گردید./ این اولین قراردادی بود که مفهوم منطقه عاری از سلاح هسته ای را عینیت بخشید. به موجب این قرارداد هرگونه عملیات نظامی، آزمایش تسلیحات، احداث ساختمان و تاسیسات هسته ای، و یا دفن زباله های هسته ای در قطب جنوب ممنوع اعلام شده است.
– معاهده ای که در سال 1963 درباره ممنوعیت آزمایشهای هسته ای در جو و فضای ماورای جو و زیر آب به امضا رسید، به معاهده منع نسبی آزمایشهای هسته ای158 موسوم است. در این معاهده آزمایشهای هسته ای زیرزمینی ممنوع نشده است، و لذا اکثر کشورهای جهان در سازمان ملل متحد خواستار انعقاد پیمان جامعی در این زمینه گردیده اند.
– معاهده سال 1966 که در آن اصول ناظر بر فعالیت کشورها در اکتشاف و استفاده از فضای ماورای جو از جمله کره ماه و سایر اجرام سماوی و همچنین ممنوعیت استقرار سلاحهای هسته ای و سایر سلاحهای انهدام وسیع در جو، مدار زمین، فضای ماورای جو، کره ماه و سایر اجرام سماوی ، مقرر گردیده است.
– معاهده سال 1967 در مورد ممنوعیت استقرارسلاحهای هسته ای در آمریکای لاتین است که به تعیین نخستین منطقه عاری از سلاحهای هسته ای در یکی از پرجمعیت ترین مناطق جهان منتهی شد. این اولین پیمان کنترل تسلیحاتی است که یک سازمان بین المللی آن را کنترل و بازرسی می نماید.
– مقاوله نامه سال 1971 که به موجب آن توسعه، تولید و انباشت سلاحهای باکترولوژیک (بیولوژیک) و سمی ممنوع اعلام گردید و انهدام ذخایر موجود این نوع سلاحها در جهان الزامی شد. این نخستین پیمان بین المللی است که طبق آن سلاحهای موجود به طور کلی منهدم می شوند.
– مقاوله نامه سال 1977 دربار ” ممنوعیت استفاده نظامی و کاربرد هر گونه ( عوامل ) خصمانه و روشهای دیگری است که موجب تغییراتی در محیط طبیعی (کره زمین ) مانند زلزله، مد دریاهایا تغییر آب و هوا ودرجه حرارت محیط”159 می گردند. مورد رسیدگی]]>