تحقیق درباره پروتکل اینترنت خط سری (SLIP)

پروتکل اینترنت خط سری (SLIP) و پروتکل نقطه به نقطه (PPP) در میان پروتکل‌های ICP/IP منحصر به فرد هستند زیرا عملکرد کامل لایه پیوند داده را در اختیار می‌گذارند. سیستم‌های که به یک LAn وصل می شوند برای کنترل اتصال واقعی به شبکه به یکی از پروتکلهای استاندارد لایه پیوند داده مثل اینترنت TokenRing  وابسته‌اند. دلیل آن این است که سیستم‌ها معمولا از یک رسانه به صورت اشتراکی استفاده  می کنند. پس باید یک مکانیزم MAC برای تنظیم دستیابی به ان وجود داشته باشد.

SLIP و PPP برای استفاده  با مودم‌ها و اتصالات مستقیم دیگر که نیازی به کنترل دستیابی به رسانه ندارند طراحی شده‌اند. از آنجا که SLIP و PPP فقط دو سیستم را به هم وصل می کنند پروتکل‌های نقطه به نقطه یا انتها نامیده می‌شوند. در پشته پروتکل را تعریف می‌کنند، غیر از لایه فیزیکی که به یک استاندارد سخت افزاری مثلا برای واسط درگاه سری RS – 232  وابسته است که اتصال به مودم را در اختیار می‌گذارد.

معمولا سیستم‌ها ار SLIP یا PPP برای برقراری اتصال به انینترنت یا WAN استفاده  می‌کنند، چه به LAN وصل باشد و چه نباشند. تقریبا همه Pc های مستقل که برای دستیابی به انیترنت از مودم برای وصل شدن به یک ISP استفاده  می‌کنند این کار را با استفاده  از یک اتصال PPP انجام می دهند هر چند برخی انواع سیستم‌ها هنوز از SLIP استفاده  می‌کنند. LAn ها  نیز در مسیریابهای خود برای وصل شدن به یک ISP و برقراری امکان دستیابی به اینترنت برای کل شبکه یا برای وصل شدن به یک LAn دیگر و تشکیل یک اتصال WAN از اتصالات SLIP  یا PPP  استفاده  می کنند. هر چند این دو پروتکل تداعی کننده اتصالات مودم هستند، ولی فناوریهای دیگر لایه فیزیکی از جمله  خطوط استیجاری ، ISDN ، رله فریم و TM هم می توانند از SLIP و PPP استفاده  کنند.

SLIP و PPP پروتکل‌های اتصال‌گرا هستند که به ساده‌ترینن بیان یک پیوند داده را بین دو سیستم برقرار می‌سازند. آنها دیتاگرام‌های IP را برای انتقال بین کامپیوترها کپسوله می‌کنند، همان کاری که اترنت و Token Ring هم انجام می‌دهندع ولی آنها از فریم خیلی ساده‌تری استفاده  می‌کنند. دلیل ان این است که این پروتکل‌ها مشکلات پروتکل‌های LAn را ندارند. آنجا که پیوند فقط از یک اتصال بین دو ک تشکیل می‌شود نیازی به مکانیزم‌های کنترل دستیابی به رسانه‌ای همچون CSMA /CD یا تبادل توکن نخواهد بود. همچنین در رابطه با آدرس‌دهی بسته‌ها به یک مقصد خاص مشکلی وجود ندارد، از آنجا که فقط دو کامپیوتر در اتصال شرکت دارند داده‌ها فقط به یک جا می‌توانند بروند.

SLIP

SLIP  در اوایل دهه 1980 به عنوان ساده‌ترین راه حل ممکن برای ارسال داده به روی اتصالات سرای ایجاد شد. هیچ استاندارد رسمی این پروتکل را تعریف نمی‌کند، به خاطر این که چیز زیادی برای استاندارد کردن وجود ندارد و مشکلی در زمینه قابلیت همکاری وجود ندارد. اما در یکی از مستندات IETD تحت عنوان   Nonstadard for Transmission of IPDatagrams over Serial Lines" ( 1055 RFC) عملکرد این پروتکل تعریف شده است.

فریم SLIP خیلی ساده است. یک فیلد یک بایتی با مقدار هگزادسیمال c0 به عنوان مرز  END عمل می کند، که به دنبال تمام دیتاگرام‌های IP که به روی پیوند ارسال می‌شوند می‌آید. کاراکتر END به سیستم دریافت کننده اطلاع می‌دهد بسته که هم اینک ارسال می شد به پایان رسیده است. بعضی از سیستم‌ها پش از هر دیتاگرام IP هم یک کاراکتر END قرار می دهند. به این ترتیب اگر نویز خطی بین دیتاگرام‌ها پیش بیاید سیستم دریافت کننده با آن مثل یک بسته رفتار می‌کنند زیرا در دو طرف آن کاراکترهای END قرار گرفته‌اند. آن گاه وقتی پروتکل‌های لایه‌های بالاتر سعی می‌کنند که این بسته نویز را پردازش کنند می‌فهمند که آشغال است و آن را دور می‌ریزند.

شکل

اگر دیتاگرامی حاوی بایتی c0 باشد سیستم آن را پیش از ارسال به رشته دو بایتی db dc تغییر می‌دهد بسته به اشتباه خاتمه نیابد. بایت db  به کاراکتر ESC(escape) اشاره می‌کند، که وقتی با کاراکتر دیگری جفتشود هدر خاصی را تامین کند. اگر دیتاگرام در قسمتی از داده خود حاوی یک کاراکتر ESC واقعی باشد سیستم پیش از ارسال رشته db dc را جایگزین آن می کند.

نکته: کاراکتر ESC تعریف می‌شود معادل کاراکتر ESC اسکی نیست.

نقایص SLIP

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

SLIP فشرده (CSIP)

هنگامی که دو سیستم با استفاده  از SLIP با هم ارتباط برقرار می‌کنند بیشتر سربار کنترلی که پروتکل‌های لایه‌های شبکه و انتقال ایجاد می‌کنند تکرار می شود، به خصوص در اتصالات TCP مثلا در هر دیتاگرام Ip، حاوی 64 بیت داده است که به آدرس‌های IP سیستم‌های مبدا و مقصد اختصاص داده می‌شوند. اما از آنجا که فقط دو کامپیوتر روی شبکه هستند لزمی ندارد که این آدرس‌ها در تمام بسته‌ها تکرار شوند. در مدتی که اتصال SLIP برقرار است دو سیستم به مبادله صدها یا هزاران بسته می‌پردازند که اطلاعات موجود در سرآیندهای پروتکل‌های لایه‌های شبکه و انتقال آنها مشابه است.

"Compressing TCP / IP Headers for Low- Speed SerialLinks " RFC 1144 مکانیزمی را تعریف می کند که توسط آن سیستم‌های شرکت کننده در یک اتصال SLIP بیشتر اطلاعات اضافی را از سرایندها حذف می‌‌کنند و سربار از 40 بایت به پنج بایت یا کمتر کاهش می‌دهند. به این ترتیب کارایی اتصال به میزان قابل توجهی افزایش می یابد.

این نوع فشرده سازی سرآیند در بسیاری از پیاده‌سازی های PPP نیز تحت عنوان فشرده‌سازی سرآیند ون جکسون یافت می‌شود، نامی که از مولف " RFC 1144 گرفته شده است.

PPP

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

برقراری اتصال

سیستمی که می‌خواهد اتصال را به راه اندازد از پروتکل کنترل پیوند (ICP) استفاده  می‌کند تا درباره پارامترهای ارتباطی مشترک بین دو دستگاه مذاکره نماید.

تایید اعتبار – هر چند ضروری نیست، ولی سیستم می تواند برای مذاکره درباره دستیابی به سیستم دیگر از یک پروتکل تایید اعتبار مثل PAP  (Challenge HandshakeAuthention Protocol ) CHAP , (Passwprd Authention Protocol استفاده  کند.

برقراری اتصال پروتکل لایه شبکه – برای هر پروتکل لایه شبکه که سیستم‌ها در طی نشست از آن استفاده  می‌کنند یک عملیات برقراری اتصال جداگانه با استفاده  از یک پروتکل کنترل شبکه (NCP) مثل IPCP (پروتکل کنترل پروتکل اینترنت) انجام می دهند.

بر خلاف SLIP ، PPP استاندارد شده است، ولی مشخصه‌های آن بین چند REF تقسیم‌ شده‌اند. مستندات مربوط به این پروتکل در جدول  فهرست شده‌اند.

 فریم PPP

REF 1661 فرمی که پروتکل PPP  به کار می برد تا پروتکل‌های دیگر را کپسوله کند و به مقصد ارسال نماید تعریف می‌کند. این فریم کوچک است، با اندازه 8 ( یا گاهی 10 ) بایت و در شکل  نشان داده شده است.

فیلدهای آن عبارتند از:

پرچم: (یک بایت) : حاوی مقداری هگزادیسمالV e است و به عنوان مرز بسته عمل می‌کند، مثل کاراکتر  End که در SLIP همین نقش را دارد.

آدرس: (یک بایت)  حاوی مقداری هگزادیسمال ff است به نشانه این که بسته به همه ایستگاه‌ها ارسال شود.

کنترل ( یک بایت) حاوی مقدار هگزادیسمال 03 است، که نشان می‌دهد بسته حاوی یک پیغام اطلاعاتی شماره‌گذاری شده HDLC است .

پروتکل ( دوبایت) – حاوی کدی است که پروتکلی را مشخص می‌کند که اطلاعات داخل فیلد را تولید کرده است. مقادیر فیلد در محدوده 0xxx تا 3xxx برای مشخص کردن پروتکل‌های لایه شبکه، مقادیر از 4xxx تا 7xxx برای مشخص کردن پروتکل‌های لایه شبکه low – volume که NCP متناظر ندارند، مقادیر از 8xxx تا bxxx برای مشخص کردن پروتکل‌های شبکه که NCP متناظر دارند و مقادیر fxxx تا cxxx برای مشخص کردن پروتکل‌های کنترل پیوند مثل LCP و پروتکل‌های تایید اعتبار به کار می‌روند. کدهای مجاز که در سند TCP / IP "Assined  Numbers" ( 1770 REF) مشخص شده ‌اند.

0021- دیتاگرام‌ IP فشرده نشده  وقتی به کار می‌رود که فشرده‌سازی وم جکوبسن فعال باشد.)

B002 – دیتاگرام IPX ناول

D002- دیتاگرام‌های IP با سرایندهای IP , TCP فشرده شده ( به کار می‌رود که فشرده سازی جکوبسن فعال باشد) .

8021- پروتکل کنترل  پروتکل اینترنت  (IPcP)

802 b - پروتکل کنترل Novell IPX  (IPXP)

021C -پروتکل کنترل پیوند (LCP)

021c -پروتکل تایید کلمه عبور (PAP)

223C -  پروتکل تایید اعتبار لا مصافحه مطالبه‌ای (CHAP)

داده و پد ( متغیر تا 1500 بایت) – حاوی بار تحویل شده بسته است، با طول حداکثر پیش فرض 1500 بایت ( که حداکثر واحد دریافتی ، یا MRU نامیده می شود) این فیلد ممکن است حاوی بایت‌های بی‌معنی باشد تا اندازه‌اش به MRU برسد.

دنباله بررسی فریم(FCS) ( 2 یا 4 بایت ) حاوی یک مقدار  CRC است که به منظور تشخیص خطا روی کل فریم غیر از فیلدهای پرچم  و دنباله بررسی فیلد محاسبه می شود.

پرچم ( یک بایت) – حاوی همان مقدار پرچم فیلد پرچم فریم است. وقتی سیستمی دو بسته را پشت سر هم ارسال می‌کند از فیلدهای پرچم حذف می‌شود، زیرا دو فیلد پرچم پشت سر هم به جای یک فریم خالی اشتباه گرفته می شود. در نتیجه مذاکرات LCP بین دو سیستم، چند فیلد فریم PPP ممکن است تغییر کنند، از جمله فیلدهای طول پروتکل و FCS  وMRU فیلد داده. سیستم‌ها می‌توانند بر سر استفاده  از فیلد پروتکل یک بایتی یا فیلد FCS بایتی توافق کنند.

فریم LCP

سیستم‌های PPP در طول فرایند برقراری اتصال برای مذاکرده درباره قابلیت‌‌هایشان از LCP  استفاده  می‌کنند تا بتوانند بهترین اتصال ممکن را داشته باشند. پیغامهای LCP در فریم‌های PPP  انتقال می‌یابند و حاوی انتخابهای پیکربندی برای اتصال هستند. پس از آنکه  دو سیستم درباره یک پیکربندی که هر دو قادر به پشتیبانی آن هستند به توافق رسیدند فرایند اطلاعات اضافی در سرایند تمام بسته‌های داده معاف می‌شوند.

فرمت پیغام LCP در شکل نشان داده شده است. و فیلدهای آن عبارتند از :

کد بایت– نوع پیغام LCP را با استفاده  از این کدها مشخص می‌کند.

1-    تقاضای پیکربندی

2-    تصدیق پیکربندی

3-    عدم تصدیق پیکربندی

4-    رد پیکربندی

5-    تقاضای خاتمه

6-    تصدیق خاتمه

7-    رد کد

8-    رد پروتکل

9-    تقاضای اکو

10-پاسخ اکو

11-تقاضای دور ریختن

شناسه: ( یک بایت) حاوی کد است که برای برقراری تناظر بین تقاضا و پاسخهای یک مبادله LCP خاص به کار می رود.

طول  ( دوبایت) – طول پیغام شامل فیلدهای کد، شناسه، طول و داده را مشخص می‌کند.

طول (متغیر) – حاوی چند انتخاب پیکربندی است که هر یک از سه فیلد تشکل می شوند. هر یک از انتخاب‌های  داخل فیلد داده پیاغم LCP شامل زیر فیلدهایی است که در شکل نشان داده شده‌اند. این زیر فیلدها عبارتند از :

نوع ( یک بایت) – انتخابی که قرار است پیکربندی شود را مشخص می کند، این کار را با استفاده  از یکی از کدهای Assigned Number RFC که در زیر آمده است انجام می‌دهد:

0-    خاص سازنده

1-    حداکثر واحد دریافتی

2-    نقشه کاراکتر کنترل ناهمگام

3-    پروتکل تایید اعتبار

4-    پروتکل کیفیت

5-    عدد جادویی

6-    رزرو

7-    فشرده سازی فیلد پروتکل

8-    فشرده سازی فیلد آدرس و کنترل

9-    جانشینهای FCS

10-پد توصیف کننده خود

11-مد شماره گذاری شده

12-عملیات چند پیوندی

13-تماس مجدد

14-زمان اتصال

15-فریم‌های ترکیبی

16-کپسوله‌های اسمی داده

17-MRRN چند پیوندی

18-فرمت سرآیند شماره دنباله کوتاه

19-تمیز دهنده نقطه انتهایی چند پیوندی

20-اختصاصی

21-شناسه DCE

طول ( یک بایت) طول پیغام LCP شامل فیلدهای کد، شناسه، طول و داده را مشخص می کند.

داده(متغیر) – حاوی اطلاعات مربوط به نوع خاص پیغام  LCP است، که در فیلد مشخص شده است.

پروتکل LCP چنان طراحی شده است که قابل توسعه نیز باشد. با استفاده  از مقدار صفر سازندگان می‌توانند از انتخابهای خود بدون این که توسط IANA استاندارد شده باشند استفاده  کنند، به طوری که رد 2153 RFC ، "PPP Vendor Extensions" آمده است.

پروتکل های تایید اعتبار

در اتصالات PPP می توان در صورت تمایل با استفاده  از یک پروتکل خارجی که در مدت مبادله پیغامهای پیکربندی LCP بر سر آن توافق می‌شود و در فریم‌های PPP  کپسوله می شود، تایید اعتبار را الزامی می‌کرد تا جلوی دستیابی‌های غیر مجاز گرفته شود. دو تا از متداولترین پروتکل‌های تایید اعتبار، PAP و CHAP در مشخصه های TCP / IP  تعریف شده‌اند،ولی سیستم ها می‌توانند از پروتکل‌های اختصاصی دیگر که توسط سایر سازندگان تدوین شده‌اند نیز استفاده  کنند.

فریمPAP– PAP در میان دو پروتکل اصلی تایید اعتبار، پروتکل ضعیفتر است زیرا فقط از یک مصاحفه دو مرحله‌ای استفاده  می کند و نام اکانت و کلمات عبور را به صورت متنی روی پیوند ارسال می‌کند. سیستم‌ها معمولا فقط وقتی از PAP استفاده  می‌کنند که هیچ پروتکل تایید اعتبار مشترک دیگری نداشته باشند . در بسته‌های PAP در فیلد پروتکل سرایند PPP مقدار 023 قرار دارد و فرمت پیغام انها  اساسا همان فرمت LCP است، غیر از انتخابها، فیلدهای پیغم PAP عبارتند از:

کد ( یک بایت) نوع پیغام PAP را با استفاده  از این مقادیر مشخص می‌کند.

1-    تقاضای تایید اعتبار

2-    تصدیق تایید اعتبار

3-    عدم تصدیق تایید اعتبار

شناسه ( یک بایت)- حاوی کدی است که برای برقراری تناظر بین تقاضا و پاسخهای یک مبادله PAP به کار می رود.

طول (دو بایت) – طول پیغام PAP، شامل فیلدهای کد، شناسه، طول و داده را مشخص می کند.

داده (متغیر) – بسته به مقدار فیلد کد، حاوی تعدادی زیر فیلد است که عبارتند از:

طول ID همتا ( یک بایت) – طول فیلدهای ID همتا را مشخص می کند. ( فقط در پیغامهای تقاضای تایید اعتبار)

IDی همتا ( متغیر ) – اکانتی که کامپیوتر مقصد برای تایید اعتبار سیستم مبدا از آن استفاده  خواهد کرد را مشخص می‌کند. (فقط در پیغامهای تقاضا تایید اعتبار)

طول کلمه عبور( متغیر) کلمه عبور متناظر با نام اکانت واقع در فیلد ID همتا را مشخص می‌کند ( فقط در پیغامهای تقاضاي تائيد اعتبار.)

طول پیغام ( یک بایت) – طول فیلد پیغام را مشخص می‌کند ( فقط در پیغامهای تصدیق تایید اعتبار و عدم تصدیق تایید اعتبار)

پیغام ( متغیر) – حاوی یک پیغام متنی است که روی واسط کاربر به نمایش درخواهد آمد و موفقیت یا شکست عملیات تایید اعتبار را توصیف می‌کند ( فقط در پیغامهای تصدیق تایید اعتبار و عدم تصدیق تایید اعتبار)

فریم CHAP- امنیت پروتکل CHAP به میزان قابل توجهی از PAP بیشتر است زیرا از مصاحفه سه مرحله‌ای استفاده  می کند و هرگز نام اکانت و کلمات عبور را به صورت متنی ارسال نمی‌نماید. در بسته های CHAP در فیلد پروتکل سرایند PPP  مقدار 223c قرار دارد و فرمت پیغام آنها تقریبا مشابه PAP است. فیلدهای پیغام CHAP عبارتند از:

کد ( یک بایت)- نوع پیغام CHAP را با استفاده  از مقادیر زیر مشخص می کند.

1- مطالبه

2- پاسخ

3- موفقیت

4- شکست

شناسه ( یک بایت) –حاوی کدی است که برای برقراری تناظر بین تقضا و پاسخهای یک مبادله CHAP خاص به کار می رود.

طول ( دو بایت) – طول پیغام CHAP شامل فیلدهای کد ، شناسه، طول و داده را مشخص می‌کند.

داده (متغير):بسته به مقدار فيلد كد حاوي تعدادي زير كد است كه عبارتند از:

مقدار (متغیر) – در یک پیغام حاوی یک رشته بایتی یکتاست که دریافت کننده ازآن و محتوای فیلد شناسه و یک «ورد» رمزنگاری استفاده  می کند تا  فیلد مقدار را برای پیغام پاسخ تولید کند ( فقط در پیغامهای مطالبه و پاسخ )

نام متغیر– حاوی رشته‌ای است که سیستم ارسال کننده را مشخص می کند ( فقط در پیغامهای مطالبه و پاسخ )

پیغام متغیر – حاوی یک پیغام متنی است که روی واسط کاربر به نمایش درمی‌اید و موفقیت یا شکست عملیات تایید اعتبار را توصیف می‌کند ( فقط در پیغامهای موفقیت و شکست)

فریم IPCP

سیستم‌های برای مذاکره درباره اتصالات هر یک از پروتکل‌هی لایه شبکه که در مدت نشست از آنها استفاده  خواهند کرد از پروتکل‌های کنترل شبکه (NCP) استفاده  می‌کنند. برای آن که یک سیستم بتواند ترکیب بارهای تولید شده توسط پروتکل‌های مختلف را که روی یک اتصال PPP در جریانند حل و فصل کند باید برای هر پروتکل با استفاده  از NCPهای مناسب یک اتصال را برقرار نماید.

پروتکل کنترل پروتکل اینترنت IPCP که NCPی IP است مثال خوبی از ساختار این پروتکل‌ها می باشد . فرمت پیغام NCP ها تقریبا مشابه LCP است غیر از این که برای فیلد کد (مقادیر پیکربندی پیوند، خاتمه پیوند و رد کردن کد) فقط مقادیر 1 تا 7 را پشتیبانی می‌کند و در فیلد داده از انتخاب‌های مختلفی استفاده  می کند . مثل LCP پیغامها در فریم‌های PPP منتقل می شوند، ولی مقدار فیلد پروتکل سرایند PPP 8021 است.

انتخابهایی که می توانند در فیلد داده یک پیغام IPCP قرار گیرند در فیلد نوع از مقادیر زیر استفاده  می‌کنند:

2 ( پروتکل فشرده سازی IP)– پروتکلی که سیستم باید برای فشرده سازی سرایندهای IP از آن استفاده  کند را مشخص می‌کند که تنها انتخاب معتبر برای آن فشرده سازی ون جکسون است.

3( آدس IP)– توسط سیستم ارسال کننده برای تقاضای یک آدرس IP خاص به کار می‌رود، یا اگر مقدار آن 0000 باشد برای تقاضای این که سیستم دریافت کننده آدرس را در اختیار بگذارد استفاده  می‌شود. ( جانشین انتخاب آدرس‌های IP نوع 1 شده است، که دیگر به کار نمی‌رود)

برقراری اتصال PPP

وقتی اتصال لایه فیزیکی ( از طریق مصافحه مودمی یا به صورتی دیگر) بین دو سیستم برقرار  شد فرایند برقراری اتصال PPP آغاز می‌شود. در مدت این نشست دو سیستم از چند فاز مجزا می‌گذرند، همان طور که در شکل 7- 13 نشان داده شده  و در بخشهای آتی مورد بررسی قرار گرفته است.

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

برقراری پیوند– در فاز برقراری پیوند، سیستمی که اتصال را به راه انداخته است یک پیغام LCP تقاضای پیکربندی را به مقصد ارسال می کند، که حاوی انتخابهایی است که او می‌خواهد فعال شوند، از جمله استفاده  از تایید اعتبار خاص، نظارت بر کیفیت پیوند، و در صورت لزوم پروتکل‌های لایه شبکه، و این که آیا لازم است سیستم‌ها ویژگی‌های استاندارد از جمله اندازه فیلد FCS را تغییر دهند یا از یک مقدار MRNی دیگر استفاده  کنند. اگر سیستم دریافت کننده قادر به پشتیبانی همه انتخابهای  مشخص ده باشد در پاسخ یک پیغام تصدیق پییکربندی می فرستد که حاوی همان مقادیر انتخاب است و این فاز فرایند اتصال کامل می شود.

اگر سیستم دریافت کننده انتخابهای داخل پیغام تقاضا را تشخیص  دهد، ولی نتواند مقادیر ان انتخاب‌ها را که فرستنده تعیین کرده است پشتیبانی نماید ( مثلا اگر سیستم تایید اعتبار را پشتیبانی می‌کند، ولی نه با پروتکلی که فرستنده مشخص کرده است) در پاسخ یک پیغام عدم تصدیق پیکربندی می‌فرستد که حاوی انتخاب‌ها با مقداری است که نمی‌تواند پشتیبانی کند. با این انتخابها سیستم پاسخ گوینده همه مقادیری که پشتیبانی می‌کند، را تعیین می نماید و ممکن است انتخابهای رد شده، نیست، و عملیات به همان صورتی که قبلا شرح داده شد ادامه می‌یابد. سرانجام سیستم‌ها یک مبادله موفق  تقاضا / تصدیق را انجام می‌دهنده و فرایند وارد فاز بعد می شود.

تایید اعتبار– فاز تایید اعتبار فرایند اتصال، اختیاری است و در صورت وجود انتخاب پروتکل تایید اعتبار در پیغام تقاضای پیکربندی  LCP به کار می‌افتد. در مدت فرایند برقراری پیوند LCP، دو سیستم بر سر استفاده  از یک پروتکل تایید اعتبار توافق می کنند برای تایید اعتبار  معمولا از پروتکل‌های PAP و CHAP استفاده  می شود، ولی پروتکل‌های  اختصاصی دیگری نیز وجود دارند.

فرمت پیغام و عملیات مبادله برای فاز تایید اعتبار توسط پروتکل انتخاب شده  دیکته می شوند. مثلا در تایید اعتبار PAP سیستم فرستنده یک پیغام تقاضای تایید اعتبار را که حاوی یک نام اکانت  و کلمه عبور است ارسال می‌کند، و گیرنده در پاسخ به آن پیغام تصدیق تایید اعتبار یا عدم تصدیق تایید اعتبار را ارسال می نماید.

CHAP از PAP امنیت بیشتری دارد و مبادله پیغام آن پیچیده‌تر است. سیستم فرستنده یک پیغام مطالبه ارسال می کند که حاوی داده‌ای می باشد که گیرنده از آن و کلید رمزنگاری خود استفاده  می کند تا مقداری را محاسبه کند که در پیغام پاسخ برای فرستنده می فرستد. بسته به این که این مقدار موجود در پاسخ با محاسبات خود فرستنده هماهنگی داشته باشد یا خیر، او پیغام موفقیت یا شکست را ارسال می نماید.

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

نظارت بر کیفیت  پیوند– استفاده  از یک  پروتکل نظارت بر کیفیت پیوند نیز یک عنصر اختیاری در فرایند اتصال است که در صورت وجود انتخاب پروتکل کیفیت در پیغام‌ تقاضای پیکربندی LCP به کار می افتد. هر چند این انتخاب سیستم فرستنده را قادر می سازد تا هر پروتکل دلخوهی را به این منظور مشخص نماید اما فقط یکی از این پروتکل‌ها استاندارد شده است، که پروتکل  گزارش کیفیت پیوند نام دارد. فرایند مذاکره که در این فاز اتفاق می‌افتد سیستم‌ها را قادر می سازد بر سر یک بازه زمانی توافق کنند تا در مدت نشست در آن به ارسال پیغامهای حاوی اطلاعات آماری بار پیوند و خطا بپردازند.

پیکربندی پروتکل لایه شبکه–PPP استفاده  از چند پروتکل لایه شبکه روی یک اتصال را پشتیبانی می کند، و در مدت این فاز سیستم‌ها برای هر یک از پروتکل‌های لایه شبکه که در فاز برقراری پیوند بر سر استفاده  از آنها توافق کرده‌اند یک عملیات جداگانه نبرقراری اتصال لایه شبکه را انجام می دهند. هر پروتکل لایه شبکه، پروتکل کنترل شبکه (NCP) خود را بدین منظور دارد، مثلا پروتکل کنترل پروتکل اینترنت IPCP یا پروتکل کنترل مبادله بسته بین شبکه‌ها IPXCP ساختار یک مبادله پیغام NCP مشابه LCP است فقط انتخاب‌هایی که در پیغام تقاضای پیکربندی انتقال می‌یابند بر اساس نیازهای پروتکل منحصر به فرد هستند. مثلا در مدت یک مبادله IPCP سیستم‌ها یکدیگر را از آدرس‌های
IP  خویش خبردار می‌کنند و نیازهای خاص خود را دارند که سیستم‌ها به مذاکره درباره آنها می پردازند. عملیات آغاز و خاتمه NCP می‌تواند در مدت اتصال در هر زمانی انجام شود.

پیوند باز– وقتی مبادلات NCP کامل شدند اتصال کاملا برقرار می شود و سیستم‌ها وارد فاز پیوند باز می شوند. اکنون داده پروتکل لایه شبکه می‌تواند در دو جهت روی پیوند حرکت کند.

خاتمه پیوند- هر گاه یکی از سیستم‌ها به نشست خاتمه بدهد، یا شرایط دیگری          پیش بیاید مثلا قطع  لایه فیزیکی شکست تایید اعتبار، یا اتمام مهلت عدم فعالیت، سیستم‌ها به فاز خاتمه پیوند وارد می شوند. برای قطع کردن پیوند، یکی از سیستم‌هخا یک پیغام تقاضای خاتمه LCP را ارسال می‌کند، که سیستم دیگر با یک پیغام تصدیق خاتمه به آن پاسخ می‌دهد. آن گاه هر دو سیستم به فاز پیوند مرده باز می‌گردد.

NCP نیز پیغام‌های تقاضای خاتمه و تصدیق خاتمه را پشتیبانی می‌کنند، لی از آنها وقتی استفاده  می‌شود که اتصال ppp برقرار بماند. در حقیقت اتصال ppp می‌تواند حتی با وجود خاتمه همه اتصالهای پروتکل‌های لایه شبکه فعال بماند لزومی ندارد که سیستم‌ها پیش از خاتمه دادن به اتصال ppp اتصالات پروتکل‌های لایه شبکه را خاتمه دهند.

The point – to point protocol (PPP) suite  include  the following protocols :

BAP Bound  width Allocation Protocol

Bap  unix Compress Command Source

CHAP Challenge  Hanshake Authentication protocol

DESE DES Encryption Algorithm

IPHC IP Header Comporession

LCP Link Control protocol

LQR Link Quality report.

Lzs stac  Lsz Algorithm

Multippp ppp Moltilink protocol

Ppp – BPDU ppp Bridge protocol Data unit

The ppp suite is illustrated here in relation to the   

BAP,PPP Bandwidth Allocation Protocol

Protocol suite:ppp

Type:PPP Link Protocol

پروتکل تخصیص پهنای باند

پروتکل BAP برای مدیریت تخصیص پهنای باند برای پیاده‌سازی و تحقق حمایت (PPP Maltl –Linke Ptotocol ) Mp  طراحی شده است. پروتکل BAP می‌تواند برای مدیریت تعدادی خط ارتباطی در یک بسته چند اتصالی استفاده  شود. BAP دیتاگرام‌هایی برای اضافه کردن و حذف کردن پیوندهای انفرادی در یک بسته چند پیوندی تعریف می کند. به خوبی این که کدام دستگاه همتا یا نظیر برای مدیریت رعایت تصمیمات پهنای باند در طول یک اتصال چند پیوندی مسئول است.

RFC2125 : این سند یک روش را برای مدیریت تخصیص پهنای باند پویا برای حمایت پیاده‌سازی پروتکل چند  پیوندی PPP پیشنهاد و مطرح می‌کند و این به وسیله تعریف پروتکل تخصیص پهنای باند BAP و به خوبی پروتکل کنترل وابسته‌اش پروتکل همان اندازه که پیاده‌سازی چند پیوندی PPP به طور افزاینده عمومی شد یک نیاز اصلی برای مطابقت و برابری در چگونگی مدیریت کردن پهنای باند فراتر از چندین لینک وجود دارد. BAP   و BAP یک راه مقاوم انعطاف پذیر برای مدیریت پهنای باند بین دو دستگاه همت و نظیر تامین می کنند BAP این کار را به وسیله تعریف بسته های call – Control  ( کنترل فراخوانی ) و یک پروتکل که اجازه این انتخاب پیکربندی LCP  (Lince – contol  Proced ure)  ( 23 برای ممیز پیکربندی) برای توصیف یک ممیز یکتا برای  پیوندی که امکان فرستاده شدن دو را دارد، استفاده  شده است. این انتخاب باید به وسیله LCP روی هر پیوند ذکر شود.

BAP ممیز پیوند را برای مشتق گرفتن پیوندهای مختلف و متنوع در بسته استفاده  می‌کند.

هر پیوند ممیز پیوند در بسته چند پیوندی باید یک فرق‌گذار یکتا داشته باشد. ممیز به هر دستگاه نظیر وابسته است. بنابراین هر پیوند ممکن است دو ارزش ممیز پیوند LCP داشته باشد، یکی برای هر دستگاه نظیر دریافت شده در بسته BAP هر دستگاه نظیر می فرستد.

BAP بسته‌ها ، پارامترها و روال‌های مذاکره را برای اجازه دادن دو نقطه انتهایی برای مذاکره کردن اضافه و حذف پیوندها از یک بسته چند پیوندی معرفی می کند یک پیاده‌سازی می تواند

§        مجوز برای اضافه کردن یک پیوند به بسته درخواست کند.

§        درخواست کند گه دستگاه نظیر یک لینک به بسته از طریق  بازفراخوانی اضافه کند.

§   با دستگاه نظیر برای حذف یک پیوند  بسته ( این ایجاب می کند که دستگاه نظیر می‌تواند امتناع کند) مذاکره کند.  (Link Drop Query Reguent)

BAP ` پیاده سازی دو دستگاه نظیر را برای مدیریت کردن پهنای باند در دسترس را برای پروتکل‌ها اجازه می دهد که بسته چند پیوندی را به وسیله مذاکره کردن هنگام  اضافه کردن و حذف کردن پیوندها استفاده  کنند.

تمام درخواست‌های  BAP و بسته‌های وابسته به پاکت در پاسخ در پاسخگویی قبل از انجام هر عمل نیاز دارند.

به منظور تطبیق وضعیت رقابت یک پیاده‌سازی باید امکان پیکربندی دستکاه نظیر هوا و سازگار BACP را انجام دهد. قبل از این که ارتباط هر پاکت BAP برقرار شود، PPP باید به فاز پروتکل شبکه برسد و BCAP باید به وضعیت باز برسد.

BAP header:

Type. 8 bits. Binary coded hexadecimal.
Specifies the BAP message.

Type       Description

01           Call - Resguest

02           Call - Resguese

03           Call back  - Resguest

04           Call back  - Resguese

05           Call Drop  - Query-  Resguest

06           Call Drop  - Query-  Resguese

07           Call – status - Jndication 

08           Call – status - Jndication 

Type : پیام BAP را تعریف می کند.

Identifier : شناسه: 8 Bit

 این فیلد به تطبیق درخواست‌ها و نشانه‌ها با پاسخ‌ها کمک می کند. بسته‌هایCall – 8 tatus – Indication  باید شناسه یکسان که به وسیله درخواست فراخوانی یا درخواست  بازفراخوانی استفاده  شده استفاده  کنند که برای آغاز کردن فراخوانی استفاده  شده است. تمام درخواست‌های دیگر یا بسته‌های دیگر باید یک شناسه یکتا برای هر درخواست جدید یانشانه استفاده  کند. تمام بسته‌های پاسخ باید یک شناسه مثل شناسه در بسته درخاست یا نشانه که پاسخگو شده است استفاده  کند. هنگامی که یکدرخواست یا نشانه ارسال مجدد می شود، شناسه‌ای که در انتقال قبلی درخواست یا نشانه استفاده  شده، یکسان شود.

16 bit : Langth

بر طور بسته ای که شامل نوع، شناسه طول و فیلد آپشن است دلالت دارد. بایت‌های خارج از رنج فیلد طول باید مثال پر شدن لایه پیوند داده رفتار کند و بر دریافت چشم پوشی شود.

Data : طول متغیر

این فیلد معمولا لیستی از صفر یا بیشتر از آپشن BAP شامل خواهد شد که فرستنده مایل به انتقال است. بایت اول فیلد دیتا در دیتاگرام پاسخ را شامل خواهد شد.

Response cod : کد پاسخ که کد باینری است

Code      Description

00          Reguest – Ack

01          Reguest – Nak

02          Reguest – Rej

03          Reguest – Full – Nak

BAp Datagram Dption   طول مغیر

آپشن دیتاگرام BAP در بسته متغیر BAP استفاده  می شود. فرمت این آپشن از فرمت تبدیل آپشن پیکربندی LCP پیروی می کند . هنگامی که آپشن چندگانه BAP در یک بسته BAP وجود دارد، آپشن‌ها در هر دستوری ارسال شوند.

Binary coded hexadecimed, 8 bite: Option  

نوع درخواستی آپشن دیتاگرام BAP را تعریف می‌کند.

Option     Length     Description  

1                    1                 :ink – Type

2                    1                phone – Delta

3                    2                No – phone – Number - Nrrded

4                    1                Reason

5                   4                 Link - Diiscriminator

6                   4                Call – Status

7         bite : Length

بر طول این آپشن  BAP که شامل نوع ، و فیلد داده آپشن دلالت دارد.

Data: طول متغیر

شامل اطلاعات بهویژه آپشن BAP می‌شود. فرمت و طول این فیلد به وسیله نوع و طول مشخص شده است.

PAP ,PPP Password Authentication Protocol

Description:

Protocol suite :ppp

Type:ppp link control protocol

پروتکل تصدیق پسورد (PAP) 

پروتکل تصدیق (PAP) می‌تواند یک هویت و پسورد را برای  نتیجه یک دستگاه نظیر در پیروزی، یا شکست تصدیق می‌کند.

RFC 1339 : به منظور تاسیس ارتباطات روی یک پیوند نقطه به نقطه هر نقطه پایان پیوند PPP باید ابتدا بسته‌های LCP را برای پیکربندی پروتکل تصدیق در طول فاز تاسیس خطوط شماره‌گری متصلند نامرد هستند. اما ممکن است به خوبی در پیوندهای اختصاصی به کار بسته شوند. سرویس دهنده می‌تواند مشخصه اتصال میزبان یا مسیریاب را در مجموعه انتخابات برای مذاکره لایه استفاده  کند.

پروتکل تصدیق پسورد (PAP) یک روش ساده برای دستگاه نظیر برای ساخت هویتش  فراهم می‌کند. دو راه دستور را استفاده  می‌کند. این فقط با تاسیس روی پیوند نخستین انجام می‌شود. بعد از این که فاز تاسیس پیوند کامل شد، یک صف Id پسورد به طور تکراری فرستاده می شوند به وسیله دستگاه نظیر برای تصدیق کننده تا زمانی تصدیق پذیرفته شود یا اتصال پایان پذیرد.

(PAP) یک روش تصدیق قوی نیست. پسورد روی مدار به طور واضح فرستاده می‌شود و حمایتی از پخش یا تکرار حمله‌های آزمون سعی و خطا وجود ندارد.

هر پیاده سازی که یک روش قویتر تصدیق مثال (CHAP) را شامل می‌شود باید برای مذاکره آن روش قبلی برای (PAP) پیشنهاد شود. این روش تصدیق به طور مناسب بیشتر جایی استفاده  می‌شود که پسورد متن عادی باید برای شبیه‌سازی یک اتصال به سیستم در یک میزبان دوردست در دسترس باشد در چندین استفاده  این روش یک سطح مشابه از امنیت برای اتصال به سیستم کاربر معمولی در میزبان دوردست فراهم می‌کند.

Packet Format

(PAP) Configuration Options:

Option: 8 bite

Options     Length     Description

3               4              Authentication_protocol

Length 8 bite

Data . Vaniable Length

RFCS

[RFC 1334] ppp Authentication Pmtocols

ChAP , PPP Challenge handshake Authentication protocol

Protocol suite : ppp

Type ppp protocol : QXC 223

 پروتکل تایید و دستداد شروع کننده ارتباط

از (CHAP) برای بازبینی کردن هویت دستگاه نظیر که از 3 راه دستداد توافق نهایی استفاده  می‌کند، به طور تناوبی استفاده  می شود. این روی نخستین تاسیس پیوند انجام می شود و ممکن است هر زمان بعد از این که پیوند تاسیس شده است. تکرار شود. 

1-             بعد از این که فاز تاسیس کامل شد ، تصدیق کننده یک پیام Challenge یا شروع برای دستگاه نظیری می فرستد.

2-             دستگاه نظیر با یک ارزش محاسبه شده توسط تابع One – way  hash پاسخ می‌دهد.

3-      تصدیق کننده پاسخ را بر خلاف محاسبه خود از ارزش درهم مقدار منتظره چک می‌کند اگر ارزش مطابقت داشت تصدیق مورد تایید است. در غیر این صورت اتصال باید پایان پذیرد.

4-      در فاصله‌های زمانی تصادفی، تصدیق کننده یک شروع جدید به دستگاه نظیر می‌فرستد و مراحل 1 تا 3 را تکرار می‌کند.

RFC 1224 به منظور تاسیس ارتباطات روی پیوند نقطه به نقطه: هر نقطه انتهایی پیوند PPP باید ابتدا بسته‌های LCP را برای پیکربندی پیوند داده در طی فاز تاسیس پیوند بفرستد. بعد از این که پیوند ساخته شد PPP برای یک فاز تصدیق اختیاری ، قبل از پیش رفتن در فاز پروتکل لایه شبکه تامین می شود.

به صورت پیش فرض تصدیق الزامی نیست، اگر تصدیق پیوند مطلوب باشد پیاده‌سازی باید امکان پیکربندی پروتکل تصدیق در طول فاز تاسیس پیوند تعیین گردد.

این پروتکل‌های تصدیق برای استفاده  اولیه به وسیله میزبان و مسیریاب که به وسیله یک سرویس دهنده شبکه ppp از طریق مدارهای سوئیچ شده یا خطوط شماره‌گیری متصلند نامزد هستند، اما ممکن است به خوبی در پیئندهای اختصاصی به کار بسته شوند. سرویس دهنده می‌تواند مشخص اتصال میزبان یا مسیریاب را در مجموعه انتخابات برای مذاکره لایه استفاده  کند.

این سند یک پروتکل تصدیق ppp را تعریف می کند تاسیس پیوند و فاز تصدیق آپشن پیکربندی پروتکل تصدیق در پروتکل نقطه به نقطه تعریف شده است.

(CHAP) حفاظت بر خلاف حمله پخش را به وسیله دستگاه نظیر در میان استفاده  از یک شناسه تغییر یافته‌ی نموی ( دارای رشد) و ارزش شروع متغیر را تامین می‌کند.

استفاده  از شروع‌های تکراری برای محدود کردن زمان آشکار سازی برای هر حمله مجرد نامزد است.

تصدیق کننده در کنترل فرکانس و زمانبندی بسته‌های شروع است. این روش تصدیق روی یک راز secret شناخته شده فقط بین تصدیق کننده و ان دستگاه نظیر بستگی دارد. این راز روی ارتباط خطی فرستاده نمی‌شود. اگر چه تصدیق فقط یک راه است به وسیله مذاکره (CHAP) در دو جهت مجموعه محرمانه یکسان ممکن است به طور آسان برای تصدیق دو جانبه استفاده  شود.

از زمانی که (CHAP) ممکن است برای تصدیق کردن بسیاری از سیستم‌های متفاوت استفاده  شود، فیلدهای نام ممکن است مانند یک  ایندکس برای مکان یابی راز مناسب در یک جدول بزرگ از محرمانه‌ها استفاده  شود.

این همچنین این را برای پشتیبانی کردن بیشتر از یک جفت (راز /نام ) در سیستم و برای عوض کردن راز در استفاده  در هر زمان در طول جلسه ممکن می‌سازد.

CHAP نیاز دارد راز فرم متن عادی در دسترس باشد. پسورد رمز دار شده به طور تغییر ناپذیر پایگاه داده‌ها که به طور مشترک در دسترسند. نمی‌توانند استفاده  شوند. این برای نصب‌های بزرگ مفید نیست، از زمانی که هر راز ممکن است در هر دو انتهای پیوند نگه داشته شود.

پاکت شروع، برای شروع پروتکل CHAP استفاده  می‌شود. تصدیق کننده باید یک پاکت CHAP

 با مجموعه فیلد کد تا 1 (Challenge) انتقال دهد. به طور افزاینده بسته‌های شروع باید تا زمانی که یک پاکت پاسخ درست دریافت می شود، یا یک شماره تلاش مجرد اختیاری خاتمه می یابد، فرستاده شود.

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

CHAP header:

bite: code 

تابع را برای اجرا شدن تعریف می‌کند.

Code    Discription    Response

1          Challenge      RFC 1994

2          Response     RFC 1994

3          Success       RFC 1994

4          Failure         RFC 1994

8 bite : Identifier(شناسه )

برای تطبیق بسته های شروع پاسخ و جواب استفاده  می شود.

16 bite : Lenth  

اندازه بسته‌های CHAP شامل فیلدهای شناسه طول داده است. بایت‌های خارج از رنج فیلد طول باید مثل پر شدن لایه پیوند داده رفتار می‌کند و بر دریافت چشم پوشی شود.

Data  : طول متغیر

صفر یا بیشتر بایت‌های دیتا توسط فیلد طول مشخص شده است.

Authentication: تصدیق کننده

 RFC 1994 انتهای پیوند تصدیق نیاز دارد. تصدیق کننده، تصدیق پروتکل را که در پیکربندی درخواست در طول فاز تاسیس پیوند استفاده  شده است، مشخص می‌کند.

Peer  : دستگاه نظیر

RFC 1994 نقطه دیگر پایان :پیوند نقطه به نقطه پایانی است که به وسیله تصدیق کننده تصدیق شده است.

Silentlt discard: ترک کردن آهسته

RFC 1994 این معني كه  پیاده سازی بسته را بدون پیش رفتن دورتر ترک می‌کند. پیاده‌سازی باید قابلیت خطای اتصال به سیستم را فراهم کند که شامل محتویات پاکت ترک کردن آهسته است و باید رخداد را در شماره‌گر آمار ضبط کند.

RFCS

[RFC 1994] ppp challage Handohake Authntican protocol CHAP

Obsoletse: RFC 1334

Obsoletse: RFCS

[RFC 1994] ppp Authetiation Protocols

PPP_BPDU   :   Bridge Protocol Data Unit  

واحد داده پروتكل پل

BPDU پيام هاي داده است كه درميان سوئيچ ها دريك LAN توسعه يافته كه يك توپولوژي درخت پوشا استفاده مي كند مبادله شده است. بسته هاي BPDU شامل اطلاعاتي روي پورت ها , ادرسها, دوره هاي تناوب وقيمت ها است ومراقبت مي كند كه داده ها درجايي پايان يابند كه براي رفتن نامزد شده اند .پيام هاي BPDU درميان پل ها در حلقه هاي اشكار در توپولوژي شبكه مبادله مي شود حلقه ها توسط  خاموش كردن رابط پل انتخاب شده وقرار گرفتن پورتهاي سوئيچ  زائد در پشتيبان , يا وضعيت بلاك شده حذف مي شوند .

واحد داده پرتوكل پل  )BPDU) يكپروتوكل در مجموعه يPPP چند  

بسته سلام از پروتوكل درخت پوشا است كه در فاصله ي زماني براي تبديل اطلاعات در طول پلها درشبكه فرستاده شده است .BPDU درتوصيف وتعريف خصوصيات پورت سوئيچ كمك مي كند وبه سوئيچ ها دربدست اوردن اطلاعات درمورديكديگر كمك مي كند .  

دونوع پايه ازپل وجود دارد , انهايي كه به طور مستقيم  باLAN ها اتصال داخلي دارند , پلهاي محلي ناميده مي شوند وانهايي كه از طريق

يك رسانه WAN مياني مثل خط اجاره اي , اتصال داخلي دارند , پل

دوردست ناميده مي شوند .

PPP_BPDU براي اتصال پلهاي دوردست استفاده مي شود .

فرمت بسته PPP_BPDU درنمونه ي زيرنشان داده شده است .

F: پرچم F, اگر فيلد LANFCS حاضر باشد, مي نشيند.

I :پرچم I اگرفيلد LANID حاضرباشد, مي نشيند .

Z : پرچم Z اگرلايه 38O2.  IEEE   صفربه كمترين اندازه پر شود ,

مي نشيند .

O :پرچم  رزرو شده O بايد صفر باشد .

Pads    : صفحه ها ,هرفريمPPP ممكن است به صورت پرشونده درفيلد پركننده لايه پيوند داده اختياري وارد شود . اين عدد مي گويد كه سيستم دريافتي چند صفحه هشتايي خالي شود.

MAC TYPE :نوع MAC

1     Bridge_Identification

2     Line_Identification

3    MAC_Support

4    Timygram_Compression

5    LAN_Identification

6    MAC_Address

7    Spanning_Tree_Protocol

LANID:

فيلد 32 بيتي اختياري كه ارتباط LAN ها كه ممكن است علاقه مند در دريافت اين فريم باشد , تعريف ميكند اگر پرچم LANID نشيند , سپس اين فيلد حاضر نيست و PDU, چهارتا هشتايي كوچكتر است .

Frame Control

فريم كنترل , در 802.4 و 802.5 و FDDI LAN, چندتا هشتايي وجود دارد كه آدرس مقصد MAC را مقدم ميشمارد, يكي از آن بوسيله FCS حفاظت شده است.نوع فريم MAC, محتويات فيلد فريم كنترل را مشخص مي كند.يك صفحه هشتايي براي تهيه همترازي بسته 32 بيتي حاضر است.

Destination MAC Address :

آدرس مقصد MAC, بوسيله IEEE تعريف شده است.فيلد نوع MAC بيت دستور را تعريف مي كند.

Source MAC Address :

آدرس منبع MAC, بوسيله IEEE تعريف شده است.فيلد نوع MAC بيت دستور را تعريف مي كند.

LLC data :

اين باقيمانده فريم MAC است كه توسط LAN FCS حفاظت شده است.