پروتکل اینترنت خط سری (SLIP)
SLIP و PPP برای استفاده با مودم‌ها و اتصالات مستقیم دیگر که نیازی به کنترل دستیابی به رسانه ندارند طراحی شده‌اند. از آنجا که SLIP و PPP فقط دو سیستم را به هم وصل می کنند پروتکلهای نقطه به نقطه یا انتها نامیده می‌شوند. در پشته پروتکل را تعریف میکنند، غیر از لایه فیزیکی که به یک استاندارد سخت افزاری مثلا برای واسط درگاه سری RS – ۲۳۲ وابسته است که اتصال به مودم را در اختیار می‌گذارد.
معمولا سیستم‌ها ار 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 در اوایل دهه ۱۹۸۰ به عنوان ساده‌ترین راه حل ممکن برای ارسال داده به روی اتصالات سرای ایجاد شد. هیچ استاندارد رسمی این پروتکل را تعریف نمی‌کند، به خاطر این که چیز زیادی برای استاندارد کردن وجود ندارد و مشکلی در زمینه قابلیت همکاری وجود ندارد. اما در یکی از مستندات IETD تحت عنوان Nonstadard for Transmission of IP Datagrams over Serial Lines” ( ۱۰۵۵ 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، حاوی ۶۴ بیت داده است که به آدرس‌های IP سیستم‌های مبدا و مقصد اختصاص داده می‌شوند. اما از آنجا که فقط دو کامپیوتر روی شبکه هستند لزمی ندارد که این آدرس‌ها در تمام بسته‌ها تکرار شوند. در مدتی که اتصال SLIP برقرار است دو سیستم به مبادله صدها یا هزاران بسته می‌پردازند که اطلاعات موجود در سرآیندهای پروتکلهای لایه‌های شبکه و انتقال آنها مشابه است.
“Compressing TCP / IP Headers for Low- Speed SerialLinks ” RFC 1144 مکانیزمی را تعریف می کند که توسط آن سیستم‌های شرکت کننده در یک اتصال SLIP بیشتر اطلاعات اضافی را از سرایندها حذف میکنند و سربار از ۴۰ بایت به پنج بایت یا کمتر کاهش می‌دهند. به این ترتیب کارایی اتصال به میزان قابل توجهی افزایش می یابد.
این نوع فشرده سازی سرآیند در بسیاری از پیاده‌سازی های PPP نیز تحت عنوان فشرده‌سازی سرآیند ون جکسون یافت میشود، نامی که از مولف ” RFC 1144 گرفته شده است.
PPP
PPP به عنوان انتخاب دیگری در مقابل SLIP ایجاد شد، که کارایی بیشتری دارد، از جمله قابلیت ترکیب پروتکلهای مختلف لایه شبکه و پشتیبانی از پروتکلهای تایید اعتبار مختلف. طبیعی است که هزینه این ویژگیهای افزوده یک سرایند بزگتر است، ولی PPP فقط حداکثر هشت بایت به هر بسته اضافه می کند ( با فریم اترنت مقایسه کنید که ۱۶ بایت برای آن لازم است ) برای بیشتر اتصالات به فراهم کنندگان خدمات اینترنت، همچنین توسط سیستم‌های مستقل و چه توسط مسیر یابها، از PPP استفاده می شود، زیرا ISP را قادر می سازد تمهیداتی را برای کنترل دستیابی پیاده‌سازی کند که شبکه‌های آنها را از ورود کاربران غیر مجاز محافظت می‌نمایند. هر نشست PPP شامل چند عملیات برقراری و خاتمه اتصال است، که برای انجام آنها از پروتکل‌هی دیگر غیر از PPP نیز استفاده می شود این عملیات عبارتند از:
برقراری اتصال
سیستمی که می‌خواهد اتصال را به راه اندازد از پروتکل کنترل پیوند (ICP) استفاده می‌کند تا درباره پارامترهای ارتباطی مشترک بین دو دستگاه مذاکره نماید.
تایید اعتبار – هر چند ضروری نیست، ولی سیستم می تواند برای مذاکره درباره دستیابی به سیستم دیگر از یک پروتکل تایید اعتبار مثل PAP (Challenge HandshakeAuthention Protocol ) CHAP , (Passwprd Authention Protocol استفاده کند.
برقراری اتصال پروتکل لایه شبکه – برای هر پروتکل لایه شبکه که سیستم‌ها در طی نشست از آن استفاده میکنند یک عملیات برقراری اتصال جداگانه با استفاده از یک پروتکل کنترل شبکه (NCP) مثل IPCP (پروتکل کنترل پروتکل اینترنت) انجام می دهند.
بر خلاف SLIP ، PPP استاندارد شده است، ولی مشخصه‌های آن بین چند REF تقسیم شده‌اند. مستندات مربوط به این پروتکل در جدول فهرست شده‌اند.
RFC 1661 ThePoint – Point Protocol (PPP)
RFC 1662 PPP in HDLC- like Framing
RFC 1663 PPP Reliable Transmission
RFC 1332 The PPP internet Protocol Control protocol (IPCP)
RFC 1552 The PPP Internetworking Packet Exchange Contorol protocol (IPXCP)
RFC 1334 PPP Authention Protocol
RFC 1994 PPP Challenge Handshake Authention Protocol (CHAP)
RFC 1989 PPPChallengeHandshake Authentication
فریم PPP
REF 1661 فرمی که پروتکل PPP به کار می برد تا پروتکلهای دیگر را کپسوله کند و به مقصد ارسال نماید تعریف می‌کند. این فریم کوچک است، با اندازه ۸ ( یا گاهی ۱۰ ) بایت و در شکل نشان داده شده است.
فیلدهای آن عبارتند از:
پرچم: (یک بایت) : حاوی مقداری هگزادیسمالV e است و به عنوان مرز بسته عمل می‌کند، مثل کاراکتر End که در SLIP همین نقش را دارد.
آدرس: (یک بایت) حاوی مقداری هگزادیسمال ff است به نشانه این که بسته به همه ایستگاه‌ها ارسال شود.
کنترل ( یک بایت) حاوی مقدار هگزادیسمال ۰۳ است، که نشان می‌دهد بسته حاوی یک پیغام اطلاعاتی شماره‌گذاری شده HDLC است .
پروتکل ( دوبایت) – حاوی کدی است که پروتکلی را مشخص می‌کند که اطلاعات داخل فیلد را تولید کرده است. مقادیر فیلد در محدوده ۰xxx تا ۳xxx برای مشخص کردن پروتکلهای لایه شبکه، مقادیر از ۴xxx تا ۷xxx برای مشخص کردن پروتکلهای لایه شبکه low – volume که NCP متناظر ندارند، مقادیر از ۸xxx تا bxxx برای مشخص کردن پروتکلهای شبکه که NCP متناظر دارند و مقادیر fxxx تا cxxx برای مشخص کردن پروتکلهای کنترل پیوند مثل LCP و پروتکلهای تایید اعتبار به کار می‌روند. کدهای مجاز که در سند TCP / IP “Assined Numbers” ( ۱۷۷۰ REF) مشخص شده اند.
۰۰۲۱– دیتاگرام IP فشرده نشده وقتی به کار می‌رود که فشرده‌سازی وم جکوبسن فعال باشد.)
B002 – دیتاگرام IPX ناول
D002- دیتاگرام‌های IP با سرایندهای IP , TCP فشرده شده ( به کار می‌رود که فشرده سازی جکوبسن فعال باشد) .
۸۰۲۱– پروتکل کنترل پروتکل اینترنت (IPcP)
802 b – پروتکل کنترل Novell IPX (IPXP)
021C –پروتکل کنترل پیوند (LCP)
021c –پروتکل تایید کلمه عبور (PAP)
223C – پروتکل تایید اعتبار لا مصافحه مطالبه‌ای (CHAP)
داده و پد ( متغیر تا ۱۵۰۰ بایت) – حاوی بار تحویل شده بسته است، با طول حداکثر پیش فرض ۱۵۰۰ بایت ( که حداکثر واحد دریافتی ، یا MRU نامیده می شود) این فیلد ممکن است حاوی بایت‌های بی‌معنی باشد تا اندازه‌اش به MRU برسد.
دنباله بررسی فریم (FCS) ( 2 یا ۴ بایت ) حاوی یک مقدار CRC است که به منظور تشخیص خطا روی کل فریم غیر از فیلدهای پرچم و دنباله بررسی فیلد محاسبه می شود.
پرچم ( یک بایت) – حاوی همان مقدار پرچم فیلد پرچم فریم است. وقتی سیستمی دو بسته را پشت سر هم ارسال می‌کند از فیلدهای پرچم حذف میشود، زیرا دو فیلد پرچم پشت سر هم به جای یک فریم خالی اشتباه گرفته می شود. در نتیجه مذاکرات LCP بین دو سیستم، چند فیلد فریم PPP ممکن است تغییر کنند، از جمله فیلدهای طول پروتکل و FCS وMRU فیلد داده. سیستم‌ها می‌توانند بر سر استفاده از فیلد پروتکل یک بایتی یا فیلد FCS بایتی توافق کنند.
فریم LCP
سیستم‌های PPP در طول فرایند برقراری اتصال برای مذاکرده درباره قابلیت‌‌هایشان از LCP استفاده میکنند تا بتوانند بهترین اتصال ممکن را داشته باشند. پیغامهای LCP در فریم‌های PPP انتقال می‌یابند و حاوی انتخابهای پیکربندی برای اتصال هستند. پس از آنکه دو سیستم درباره یک پیکربندی که هر دو قادر به پشتیبانی آن هستند به توافق رسیدند فرایند اطلاعات اضافی در سرایند تمام بسته‌های داده معاف می‌شوند.
فرمت پیغام LCP در شکل نشان داده شده است. و فیلدهای آن عبارتند از :
کد بایت – نوع پیغام LCP را با استفاده از این کدها مشخص می‌کند.
۱– تقاضای پیکربندی
۲– تصدیق پیکربندی
۳– عدم تصدیق پیکربندی
۴– رد پیکربندی
۵– تقاضای خاتمه
۶– تصدیق خاتمه
۷– رد کد
۸– رد پروتکل
۹– تقاضای اکو
۱۰– پاسخ اکو
۱۱– تقاضای دور ریختن
شناسه: ( یک بایت) حاوی کد است که برای برقراری تناظر بین تقاضا و پاسخهای یک مبادله LCP خاص به کار می رود.
طول ( دوبایت) – طول پیغام شامل فیلدهای کد، شناسه، طول و داده را مشخص می‌کند.
طول (متغیر) – حاوی چند انتخاب پیکربندی است که هر یک از سه فیلد تشکل می شوند. هر یک از انتخابهای داخل فیلد داده پیاغم LCP شامل زیر فیلدهایی است که در شکل نشان داده شده‌اند. این زیر فیلدها عبارتند از :
نوع ( یک بایت) – انتخابی که قرار است پیکربندی شود را مشخص می کند، این کار را با استفاده از یکی از کدهای Assigned Number RFC که در زیر آمده است انجام می‌دهد:
۰– خاص سازنده
۱– حداکثر واحد دریافتی
۲– نقشه کاراکتر کنترل ناهمگام
۳– پروتکل تایید اعتبار
۴– پروتکل کیفیت
۵– عدد جادویی
۶– رزرو
۷– فشرده سازی فیلد پروتکل
۸– فشرده سازی فیلد آدرس و کنترل
۹– جانشینهای FCS
10- پد توصیف کننده خود
۱۱– مد شماره گذاری شده
۱۲– عملیات چند پیوندی
۱۳– تماس مجدد
۱۴– زمان اتصال
۱۵– فریم‌های ترکیبی
۱۶– کپسوله‌های اسمی داده
۱۷– MRRN چند پیوندی
۱۸– فرمت سرآیند شماره دنباله کوتاه
۱۹– تمیز دهنده نقطه انتهایی چند پیوندی
۲۰– اختصاصی
۲۱– شناسه DCE
طول ( یک بایت) طول پیغام LCP شامل فیلدهای کد، شناسه، طول و داده را مشخص می کند.
داده(متغیر) – حاوی اطلاعات مربوط به نوع خاص پیغام LCP است، که در فیلد مشخص شده است.
پروتکل LCP چنان طراحی شده است که قابل توسعه نیز باشد. با استفاده از مقدار صفر سازندگان می‌توانند از انتخابهای خود بدون این که توسط IANA استاندارد شده باشند استفاده کنند، به طوری که رد ۲۱۵۳ RFC ، “PPP Vendor Extensions” آمده است.
پروتکل های تایید اعتبار
در اتصالات PPP می توان در صورت تمایل با استفاده از یک پروتکل خارجی که در مدت مبادله پیغامهای پیکربندی LCP بر سر آن توافق میشود و در فریم‌های PPP کپسوله می شود، تایید اعتبار را الزامی می‌کرد تا جلوی دستیابی‌های غیر مجاز گرفته شود. دو تا از متداولترین پروتکلهای تایید اعتبار، PAP و CHAP در مشخصه های TCP / IP تعریف شده‌اند،ولی سیستم ها می‌توانند از پروتکلهای اختصاصی دیگر که توسط سایر سازندگان تدوین شده‌اند نیز استفاده کنند.
فریم PAP – PAP در میان دو پروتکل اصلی تایید اعتبار، پروتکل ضعیفتر است زیرا فقط از یک مصاحفه دو مرحله‌ای استفاده می کند و نام اکانت و کلمات عبور را به صورت متنی روی پیوند ارسال می‌کند. سیستم‌ها معمولا فقط وقتی از PAP استفاده میکنند که هیچ پروتکل تایید اعتبار مشترک دیگری نداشته باشند . در بسته‌های PAP در فیلد پروتکل سرایند PPP مقدار ۰۲۳ قرار دارد و فرمت پیغام انها اساسا همان فرمت LCP است، غیر از انتخابها، فیلدهای پیغم PAP عبارتند از:
کد ( یک بایت) نوع پیغام PAP را با استفاده از این مقادیر مشخص می‌کند.
۱– تقاضای تایید اعتبار
۲– تصدیق تایید اعتبار
۳– عدم تصدیق تایید اعتبار
شناسه ( یک بایت)- حاوی کدی است که برای برقراری تناظر بین تقاضا و پاسخهای یک مبادله PAP به کار می رود.
طول (دو بایت) – طول پیغام PAP، شامل فیلدهای کد، شناسه، طول و داده را مشخص می کند.
داده (متغیر) – بسته به مقدار فیلد کد، حاوی تعدادی زیر فیلد است که عبارتند از:
طول ID همتا ( یک بایت) – طول فیلدهای ID همتا را مشخص می کند. ( فقط در پیغامهای تقاضای تایید اعتبار)
IDی همتا ( متغیر ) – اکانتی که کامپیوتر مقصد برای تایید اعتبار سیستم مبدا از آن استفاده خواهد کرد را مشخص می‌کند. (فقط در پیغامهای تقاضا تایید اعتبار)
طول کلمه عبور( متغیر) کلمه عبور متناظر با نام اکانت واقع در فیلد ID همتا را مشخص می‌کند ( فقط در پیغامهای تقاضای تائید اعتبار.)
طول پیغام ( یک بایت) – طول فیلد پیغام را مشخص می‌کند ( فقط در پیغامهای تصدیق تایید اعتبار و عدم تصدیق تایید اعتبار)
پیغام ( متغیر) – حاوی یک پیغام متنی است که روی واسط کاربر به نمایش درخواهد آمد و موفقیت یا شکست عملیات تایید اعتبار را توصیف می‌کند ( فقط در پیغامهای تصدیق تایید اعتبار و عدم تصدیق تایید اعتبار)
فریم CHAP- امنیت پروتکل CHAP به میزان قابل توجهی از PAP بیشتر است زیرا از مصاحفه سه مرحله‌ای استفاده می کند و هرگز نام اکانت و کلمات عبور را به صورت متنی ارسال نمی‌نماید. در بسته های CHAP در فیلد پروتکل سرایند PPP مقدار ۲۲۳c قرار دارد و فرمت پیغام آنها تقریبا مشابه PAP است. فیلدهای پیغام CHAP عبارتند از:
کد ( یک بایت)- نوع پیغام CHAP را با استفاده از مقادیر زیر مشخص می کند.
۱– مطالبه
۲– پاسخ
۳– موفقیت
۴– شکست
شناسه ( یک بایت) –حاوی کدی است که برای برقراری تناظر بین تقضا و پاسخهای یک مبادله CHAP خاص به کار می رود.
طول ( دو بایت) – طول پیغام CHAP شامل فیلدهای کد ، شناسه، طول و داده را مشخص می‌کند.
داده (متغیر):بسته به مقدار فیلد کد حاوی تعدادی زیر کد است که عبارتند از:
مقدار (متغیر) – در یک پیغام حاوی یک رشته بایتی یکتاست که دریافت کننده ازآن و محتوای فیلد شناسه و یک «ورد» رمزنگاری استفاده می کند تا فیلد مقدار را برای پیغام پاسخ تولید کند ( فقط در پیغامهای مطالبه و پاسخ )
نام متغیر – حاوی رشته‌ای است که سیستم ارسال کننده را مشخص می کند ( فقط در پیغامهای مطالبه و پاسخ )
پیغام متغیر – حاوی یک پیغام متنی است که روی واسط کاربر به نمایش درمی‌اید و موفقیت یا شکست عملیات تایید اعتبار را توصیف می‌کند ( فقط در پیغامهای موفقیت و شکست)
فریم IPCP
سیستم‌های برای مذاکره درباره اتصالات هر یک از پروتکل‌هی لایه شبکه که در مدت نشست از آنها استفاده خواهند کرد از پروتکلهای کنترل شبکه (NCP) استفاده میکنند. برای آن که یک سیستم بتواند ترکیب بارهای تولید شده توسط پروتکلهای مختلف را که روی یک اتصال PPP در جریانند حل و فصل کند باید برای هر پروتکل با استفاده از NCPهای مناسب یک اتصال را برقرار نماید.
پروتکل کنترل پروتکل اینترنت IPCP که NCPی IP است مثال خوبی از ساختار این پروتکل‌ها می باشد . فرمت پیغام NCP ها تقریبا مشابه LCP است غیر از این که برای فیلد کد (مقادیر پیکربندی پیوند، خاتمه پیوند و رد کردن کد) فقط مقادیر ۱ تا ۷ را پشتیبانی می‌کند و در فیلد داده از انتخابهای مختلفی استفاده می کند . مثل LCP پیغامها در فریم‌های PPP منتقل می شوند، ولی مقدار فیلد پروتکل سرایند PPP 8021 است.
انتخابهایی که می توانند در فیلد داده یک پیغام IPCP قرار گیرند در فیلد نوع از مقادیر زیر استفاده میکنند:
۲ ( پروتکل فشرده سازی IP) – پروتکلی که سیستم باید برای فشرده سازی سرایندهای IP از آن استفاده کند را مشخص می‌کند که تنها انتخاب معتبر برای آن فشرده سازی ون جکسون است.
۳( آدس IP) – توسط سیستم ارسال کننده برای تقاضای یک آدرس IP خاص به کار می‌رود، یا اگر مقدار آن ۰۰۰۰ باشد برای تقاضای این که سیستم دریافت کننده آدرس را در اختیار بگذارد استفاده میشود. ( جانشین انتخاب آدرس‌های IP نوع ۱ شده است، که دیگر به کار نمی‌رود)
برقراری اتصال PPP
وقتی اتصال لایه فیزیکی ( از طریق مصافحه مودمی یا به صورتی دیگر) بین دو سیستم برقرار شد فرایند برقراری اتصال PPP آغاز میشود. در مدت این نشست دو سیستم از چند فاز مجزا می‌گذرند، همان طور که در شکل ۷- ۱۳ نشان داده شده و در بخشهای آتی مورد بررسی قرار گرفته است.
پیوند مرده – هر دو سیستم نشست را در فاز پیوند مرده آغاز میکنند و به پایان می رسانند، که نشان می دهد هیچ اتصال لایه فیزیکی بین دو دستگاه وجود ندارد. در هر نشست برنامه یا سرویسی از یک سیستم با شماره گیری مودم یا به طریق دیگر اتصال لایه فیزیکی را به راه می‌اندازد. وقتی فرایند اتصال سخت‌افزاری کامل شد سیستم‌ها به فاز برقراری پیوند می‌روند.
برقراری پیوند – در فاز برقراری پیوند، سیستمی که اتصال را به راه انداخته است یک پیغام LCP تقاضای پیکربندی را به مقصد ارسال می کند، که حاوی انتخابهایی است که او می‌خواهد فعال شوند، از جمله استفاده از تایید اعتبار خاص، نظارت بر کیفیت پیوند، و در صورت لزوم پروتکلهای لایه شبکه، و این که آیا لازم است سیستم‌ها ویژگیهای استاندارد از جمله اندازه فیلد FCS را تغییر دهند یا از یک مقدار MRNی دیگر استفاده کنند. اگر سیستم دریافت کننده قادر به پشتیبانی همه انتخابهای مشخص ده باشد در پاسخ یک پیغام تصدیق پییکربندی می فرستد که حاوی همان مقادیر انتخاب است و این فاز فرایند اتصال کامل می شود.
اگر سیستم دریافت کننده انتخابهای داخل پیغام تقاضا را تشخیص دهد، ولی نتواند مقادیر ان انتخابها را که فرستنده تعیین کرده است پشتیبانی نماید ( مثلا اگر سیستم تایید اعتبار را پشتیبانی می‌کند، ولی نه با پروتکلی که فرستنده مشخص کرده است) در پاسخ یک پیغام عدم تصدیق پیکربندی می‌فرستد که حاوی انتخابها با مقداری است که نمی‌تواند پشتیبانی کند. با این انتخابها سیستم پاسخ گوینده همه مقادیری که پشتیبانی می‌کند، را تعیین می نماید و ممکن است انتخابهای رد شده، نیست، و عملیات به همان صورتی که قبلا شرح داده شد ادامه می‌یابد. سرانجام سیستم‌ها یک مبادله موفق تقاضا / تصدیق را انجام می‌دهنده و فرایند وارد فاز بعد می شود.
تایید اعتبار – فاز تایید اعتبار فرایند اتصال، اختیاری است و در صورت وجود انتخاب پروتکل تایید اعتبار در پیغام تقاضای پیکربندی LCP به کار می‌افتد. در مدت فرایند برقراری پیوند LCP، دو سیستم بر سر استفاده از یک پروتکل تایید اعتبار توافق می کنند برای تایید اعتبار معمولا از پروتکلهای PAP و CHAP استفاده می شود، ولی پروتکلهای اختصاصی دیگری نیز وجود دارند.
فرمت پیغام و عملیات مبادله برای فاز تایید اعتبار توسط پروتکل انتخاب شده دیکته می شوند. مثلا در تایید اعتبار PAP سیستم فرستنده یک پیغام تقاضای تایید اعتبار را که حاوی یک نام اکانت و کلمه عبور است ارسال می‌کند، و گیرنده در پاسخ به آن پیغام تصدیق تایید اعتبار یا عدم تصدیق تایید اعتبار را ارسال می نماید.
CHAP از PAP امنیت بیشتری دارد و مبادله پیغام آن پیچیده‌تر است. سیستم فرستنده یک پیغام مطالبه ارسال می کند که حاوی داده‌ای می باشد که گیرنده از آن و کلید رمزنگاری خود استفاده می کند تا مقداری را محاسبه کند که در پیغام پاسخ برای فرستنده می فرستد. بسته به این که این مقدار موجود در پاسخ با محاسبات خود فرستنده هماهنگی داشته باشد یا خیر، او پیغام موفقیت یا شکست را ارسال می نماید.
یک مبادله موفق باعث میشود که عملیات اتصال وارد فاز بعد شود، ولی این که در نتیجه شکست چه کاری انجام می شود توسط پیاده سازی پروتکل دیکته می شود. برخی سیستم‌ها در صورت شکست تایید اعتبار به طور مستقیم به فاز خاتمه پیوند وارد می شوند، در حالی که دیگران ممکن است اجازه تلاش مجدد یا دستیابی مجدد به شبکه را به یک زیر سیستم کمکی بدهند.
