খসড়া:ইথারনেটের উপর পয়েন্ট-টু-পয়েন্ট প্রোটোকল

উইকিপিডিয়া, মুক্ত বিশ্বকোষ থেকে

পয়েন্ট-টু-পয়েন্ট প্রোটোকল ওভার ইথারনেট ( PPPoE ) হল একটি নেটওয়ার্ক প্রোটোকল যা ইথারনেট ফ্রেমের ভিতরে পয়েন্ট-টু-পয়েন্ট প্রোটোকল (PPP) ফ্রেমগুলিকে এনক্যাপসুলেট করার জন্য। এটি 1999 সালে, ডিএসএল- এর বুমের পরিপ্রেক্ষিতে ডিএসএল সংযোগের মাধ্যমে আইএসপি -এর আইপি নেটওয়ার্কে এবং সেখান থেকে বাকি ইন্টারনেটে প্যাকেটগুলিকে টানেলিং করার সমাধান হিসাবে উপস্থিত হয়েছিল। একটি 2005 নেটওয়ার্কিং বই উল্লেখ করেছে যে "বেশিরভাগ DSL প্রদানকারীরা PPPoE ব্যবহার করে,

যা প্রমাণীকরণ, এনক্রিপশন এবং কম্প্রেশন প্রদান করে।" [১] PPPoE-এর সাধারণ ব্যবহারে ব্যবহারকারীর নাম এবং পাসওয়ার্ড দিয়ে প্রমাণীকরণের জন্য PPP সুবিধাগুলিকে ব্যবহার করা হয়, প্রধানত PAP প্রোটোকলের মাধ্যমে এবং কম প্রায়ই CHAP-এর মাধ্যমে। [২] 2000 সালের দিকে, PPPoE একটি ইথারনেট ল্যানের মাধ্যমে কম্পিউটার বা রাউটারের সাথে সংযুক্ত একটি মডেমের সাথে কথা বলার জন্য একটি প্রতিস্থাপন পদ্ধতি হয়ে উঠতে শুরু করেছিল, যা পুরানো পদ্ধতিটি ছিল, যা ছিল USB । এই ব্যবহারের ক্ষেত্রে, ইথারনেটের মাধ্যমে রাউটারগুলিকে মোডেমের সাথে সংযুক্ত করা আজও অত্যন্ত সাধারণ।

গ্রাহক-প্রাঙ্গনে সরঞ্জামগুলিতে, PPPoE হয় একটি ইউনিফাইড আবাসিক গেটওয়ে ডিভাইসে প্রয়োগ করা যেতে পারে যা ডিএসএল মডেম এবং আইপি রাউটিং ফাংশন উভয়ই পরিচালনা করে বা একটি সাধারণ ডিএসএল মডেমের ক্ষেত্রে (রাউটিং সমর্থন ছাড়া), PPPoE এর পিছনে পরিচালনা করা যেতে পারে আলাদা ইথারনেট-শুধু রাউটার বা এমনকি সরাসরি ব্যবহারকারীর কম্পিউটারে। ( Windows XP, [৩] Linux [৪] থেকে Mac OS X পর্যন্ত বেশিরভাগ অপারেটিং সিস্টেমে PPPoE-এর জন্য সমর্থন বিদ্যমান। [৫] ) অতি সম্প্রতি </link>, কিছু GPON- ভিত্তিক (DSL-ভিত্তিক পরিবর্তে) আবাসিক গেটওয়েগুলিও PPPoE ব্যবহার করে, যদিও GPON মানগুলিতে PPPoE-এর অবস্থা প্রান্তিক৷ PPPoE ইউএনইটি, রেডব্যাক নেটওয়ার্কস (এখন এরিকসন) এবং রাউটারওয়্যার (এখন উইন্ড রিভার সিস্টেমস ) দ্বারা তৈরি করা হয়েছিল [৬] এবং এটি একটি তথ্যমূলক হিসাবে উপলব্ধ  ।

DSL-এর জগতে, PPPoE সাধারণত অন্তর্নিহিত পরিবহন হিসাবে এটিএম (বা DSL) এর উপরে চলমান বলে বোঝা যায়, যদিও PPPoE প্রোটোকলেই এই ধরনের কোন সীমাবদ্ধতা বিদ্যমান নেই। অন্যান্য ব্যবহারের পরিস্থিতি কখনও কখনও একটি প্রত্যয় হিসাবে অন্য অন্তর্নিহিত পরিবহন হিসাবে ট্যাকিং দ্বারা আলাদা করা হয়। উদাহরণস্বরূপ, PPPoEoE, যখন পরিবহন নিজেই ইথারনেট হয়, যেমন মেট্রো ইথারনেট নেটওয়ার্কের ক্ষেত্রে। (এই স্বরলিপিতে, PPPoE এর আসল ব্যবহারকে PPPoEoA লেবেল করা হবে, যদিও এটি PPPoA এর সাথে বিভ্রান্ত করা উচিত নয়, যা একটি ভিন্ন এনক্যাপসুলেশন প্রোটোকল।)

PPPoE কে কিছু বইয়ে " লেয়ার 2.5 " প্রোটোকল হিসাবে বর্ণনা করা হয়েছে, [৭] [৮] কিছু প্রাথমিক অর্থে MPLS এর মতো কারণ এটি একটি ইথারনেট অবকাঠামো ভাগ করে নেওয়া বিভিন্ন আইপি প্রবাহকে আলাদা করতে ব্যবহার করা যেতে পারে, যদিও PPPoE সুইচ তৈরির অভাব। PPPoE হেডারের উপর ভিত্তি করে রাউটিং সিদ্ধান্ত সেই ক্ষেত্রে প্রযোজ্যতা সীমিত করে। [৮]

মূল যুক্তি[সম্পাদনা]

1998 সালের শেষের দিকে, ডিএসএল পরিষেবার মডেলটি এখনও বৃহৎ পরিসরে পৌঁছাতে পারেনি যা দামকে পরিবারের স্তরে নামিয়ে আনবে। ADSL প্রযুক্তি এক দশক আগে প্রস্তাব করা হয়েছিল। [৯] সম্ভাব্য সরঞ্জাম বিক্রেতা এবং বাহক উভয়ই স্বীকার করেছেন যে ব্রডব্যান্ড যেমন ক্যাবল মডেম বা ডিএসএল অবশেষে ডায়ালআপ পরিষেবা প্রতিস্থাপন করবে, কিন্তু হার্ডওয়্যার (উভয় গ্রাহক প্রাঙ্গণ এবং LEC ) একটি উল্লেখযোগ্য কম-পরিমাণ খরচ বাধার সম্মুখীন হয়েছে। DSL-এর কম পরিমাণে স্থাপনার প্রাথমিক অনুমানে DSL মডেমের জন্য $300–$500 পরিসরে খরচ এবং টেলকো থেকে $300/মাসের অ্যাক্সেস ফি দেখানো হয়েছে,[তথ্যসূত্র প্রয়োজন]</link> যা একজন বাড়ির ব্যবহারকারীর অর্থ প্রদানের বাইরে ছিল।

এইভাবে প্রাথমিক ফোকাস ছিল ছোট এবং বাড়ির ব্যবসার গ্রাহকদের উপর যাদের জন্য একটি ~1.5 মেগাবিট T1 লাইন (সে সময়ে প্রতি মাসে $800–$1500) লাভজনক ছিল না, কিন্তু যাদের ডায়ালআপ বা ISDN সরবরাহ করতে পারে তার চেয়ে বেশি প্রয়োজন। যদি এই গ্রাহকদের পর্যাপ্ত পথ প্রশস্ত করা হয়, তবে পরিমাণগুলি দামকে নীচে নিয়ে যাবে যেখানে হোম-ব্যবহারের ডায়ালআপ ব্যবহারকারী আগ্রহী হতে পারে।

বিভিন্ন ব্যবহার প্রোফাইল[সম্পাদনা]

সমস্যাটি ছিল যে ছোট ব্যবসার গ্রাহকদের একটি হোম-ব্যবহারের ডায়ালআপ ব্যবহারকারীর চেয়ে আলাদা ব্যবহার প্রোফাইল ছিল, যার মধ্যে রয়েছে:

  • ইন্টারনেটের সাথে একটি সম্পূর্ণ LAN সংযোগ করা;
  • সংযোগের দূরের দিক থেকে অ্যাক্সেসযোগ্য একটি স্থানীয় LAN-এ পরিষেবা প্রদান করা;
  • একাধিক বাহ্যিক ডেটা উত্সে একযোগে অ্যাক্সেস, যেমন একটি কোম্পানি ভিপিএন এবং একটি সাধারণ উদ্দেশ্য আইএসপি;
  • কর্মদিবস জুড়ে বা এমনকি ঘড়ির চারপাশে ক্রমাগত ব্যবহার।

এই প্রয়োজনীয়তাগুলি একটি ডায়াল-আপ প্রক্রিয়ার সংযোগ স্থাপনের ব্যবধানে বা এর ওয়ান-কম্পিউটার-টু-ওয়ান-আইএসপি মডেল, এমনকি NAT প্লাস ডায়াল-আপ প্রদান করে এমন বহু-থেকে-একটিও ধার দেয়নি। একটি নতুন মডেল প্রয়োজন ছিল. PPPoE প্রধানত ব্যবহৃত হয়:

  • PPPoE-ভাষী ইন্টারনেট DSL পরিষেবাগুলির সাথে যেখানে একটি PPPoE-ভাষী মডেম - রাউটার ( আবাসিক গেটওয়ে ) DSL পরিষেবার সাথে সংযোগ করে৷ এখানে ISP এবং মডেম-রাউটার উভয়কেই PPPoE কথা বলতে হবে। (উল্লেখ্য যে এই ক্ষেত্রে, PPPoE-ওভার-DSL সাইড অফ জিনিসগুলিকে মাঝে মাঝে 'PPPoE over ATM'- এর জন্য PPPoEoA হিসাবে উল্লেখ করা হয়।)
  • অথবা যখন একটি PPPoE-ভাষী DSL মডেম একটি ইথারনেট কেবল ব্যবহার করে একটি PPPoE-ভাষী ইথারনেট-শুধু রাউটারের সাথে সংযুক্ত থাকে।

বাজার করার সময়: সহজতর ভাল[সম্পাদনা]

এই চাহিদাগুলি পূরণ করার জন্য একটি সম্পূর্ণ নতুন প্রোটোকল তৈরি করার সাথে একটি সমস্যা ছিল সময়। পরিষেবার মতোই সরঞ্জামগুলি অবিলম্বে উপলব্ধ ছিল, এবং একটি সম্পূর্ণ নতুন প্রোটোকল স্ট্যাক ( মাইক্রোসফ্ট সেই সময়ে ফাইবার-ভিত্তিক এটিএম-সেল-টু-দ্য-ডেস্কটপ-এর পক্ষে পরামর্শ দিচ্ছিল, [১০] এবং L2TP পাশাপাশি তৈরি হচ্ছিল, কিন্তু ছিল না সমাপ্তির কাছাকাছি) বাস্তবায়ন করতে এত বেশি সময় লাগবে যে সুযোগের উইন্ডোটি পিছলে যেতে পারে। দ্রুত একটি সম্পূর্ণ সমাধান প্রদানের প্রয়াসে বাস্তবায়ন এবং প্রমিতকরণকে সহজ করার জন্য বেশ কয়েকটি সিদ্ধান্ত নেওয়া হয়েছিল।

বিদ্যমান সফ্টওয়্যার স্ট্যাকগুলি পুনরায় ব্যবহার করুন৷[সম্পাদনা]

PPPoE ব্যাপক ইথারনেট অবকাঠামোকে সর্বব্যাপী PPP-এর সাথে একীভূত করার আশা করেছিল, যা বিক্রেতাদের তাদের বিদ্যমান সফ্টওয়্যার পুনরায় ব্যবহার করতে এবং খুব কাছাকাছি সময়ে পণ্য সরবরাহ করতে দেয়। মূলত সেই সময়ে সমস্ত অপারেটিং সিস্টেমে একটি পিপিপি স্ট্যাক ছিল, এবং PPPoE-এর ডিজাইন লাইন-এনকোডিং পর্যায়ে পিপিপি থেকে পিপিপিওই-তে রূপান্তর করার জন্য একটি সাধারণ শিমের অনুমতি দেয়।[তথ্যসূত্র প্রয়োজন]</link>[ তথ্যসূত্র প্রয়োজন ]

হার্ডওয়্যার প্রয়োজনীয়তা সরলীকরণ[সম্পাদনা]

প্রতিযোগী WAN প্রযুক্তির (T1, ISDN) গ্রাহক প্রাঙ্গনে একটি রাউটার প্রয়োজন। PPPoE একটি ভিন্ন ইথারনেট ফ্রেম টাইপ ব্যবহার করেছে, যা DSL হার্ডওয়্যারকে কেবল একটি সেতু হিসাবে কাজ করার অনুমতি দেয়, কিছু ফ্রেম WAN-এ পাস করে এবং অন্যগুলিকে উপেক্ষা করে। এই ধরনের একটি সেতুর বাস্তবায়ন একটি রাউটারের চেয়ে সহজ মাত্রার একাধিক আদেশ।

তথ্যমূলক RFC[সম্পাদনা]

RFC 2516 প্রাথমিকভাবে একই কারণে একটি তথ্যমূলক ( স্ট্যান্ডার্ড-ট্র্যাকের পরিবর্তে) RFC হিসাবে প্রকাশ করা হয়েছিল: একটি স্ট্যান্ডার্ড-ট্র্যাক RFC এর গ্রহণের সময়কাল ছিল নিষেধমূলকভাবে দীর্ঘ।

সফলতা[সম্পাদনা]

PPPoE প্রাথমিকভাবে ইন্টারনেটে স্বতন্ত্র স্বতন্ত্র সংযোগ সহ একটি ছোট LAN প্রদান করার জন্য ডিজাইন করা হয়েছিল, তবে এমনও যে প্রোটোকলটি নিজেই যথেষ্ট হালকা হবে যে এটি অবশেষে পৌঁছানোর সময় বাড়ির ব্যবহারের জন্য আশা করা বাজারে আঘাত করবে না। যদিও দ্বিতীয় বিষয়ে সাফল্য নিয়ে বিতর্ক হতে পারে (কেউ কেউ অভিযোগ করেন যে প্রতি প্যাকেটে 8 বাইট অনেক বেশি) PPPoE পরিষ্কারভাবে পর্যাপ্ত পরিমাণে পরিসেবার জন্য দাম কমিয়ে আনতে সফল হয়েছে যেটা একজন হোম ব্যবহারকারী দিতে হবে।

আধুনিক দিনের ব্যবহারের ক্ষেত্রে[সম্পাদনা]

2000 সালের দিকে, PPPoE প্রোটোকল ব্যবহার করা হয়েছিল (i) একটি কম্পিউটার বা রাউটারের সাথে একটি DSL মডেম সংযোগ করার জন্য, USB ব্যবহার করার আগের পদ্ধতিকে স্থানচ্যুত করে, অথবা (ii) একটি রাউটারকে সংযুক্ত করতে প্রোটোকল হেডারগুলির PPP+PPPoE ত্রয়ী ব্যবহার করা হয়েছিল। একটি নেটওয়ার্ক নোড, একটি প্রোটোকল রূপান্তরকারী, কিছুটা আরও আপস্ট্রিম যা হয় আইএসপি বা একটি পাইকারি দীর্ঘ-দূরত্বের ক্যারিয়ারের সাথে জড়িত যারা ঘুরে ঘুরে আইএসপির আইপি নেটওয়ার্ক এবং তারপরে ইন্টারনেটের সাথে সংযোগ স্থাপন করে।

প্রথম ব্যবহার-কেস, রাউটার-টু-মডেম সংযোগ, তথাকথিত 'PPPoEoE' (একটি ভৌত ইথারনেট ল্যানের উপর PPPoE প্রোটোকল ত্রয়ী) জড়িত, যদি PPP ব্যবহার করা হয় তবে রাউটারগুলির সাথে মডেম সংযোগ করার জন্য আজও খুব বেশি ব্যবহৃত হয়।

দ্বিতীয় ব্যবহারের ক্ষেত্রে, যেখানে PPPoE প্রোটোকল ত্রয়ী এক বা একাধিক ইন্টারনেট অ্যাক্সেস লিঙ্কের উপর ব্যবহার করা হয় যা একটি বৃহত্তর বা কম গভীরতায় আপস্ট্রিমে পৌঁছায়, সর্বসম্মতি অনুসারে, শুধুমাত্র ঐতিহাসিক কারণেই ব্যবহৃত হয়। যদিও পিপিপি কিছু আইএসপি-র কাছে টানেলিং প্রোটোকল হিসাবে জনপ্রিয় থেকে যায়, যেখানে একটি আইএসপি একটি পাইকারি অ্যাক্সেস ক্যারিয়ার/রিসেলার ব্যবহার করে বা পিপিপি-এর বৈশিষ্ট্যগুলি আবার পছন্দসই, বা উভয়ই ব্যবহার করে।

যেমনটি আগে উল্লেখ করা হয়েছে, আশ্চর্যজনকভাবে, ইথারনেট MAC হেডারগুলি বাস্তবে কখনও কখনও PPPoE হেডারগুলির সাথে ব্যবহার করা হয় এমনকি যখন ইথারনেট প্রোটোকল ব্যবহার করা হয় না, একটি ইথারনেট নেটওয়ার্কে শারীরিকভাবে উপস্থিত না থাকে। আরও অপ্রয়োজনীয় হেডার ওভারহেড, তথাকথিত ব্লাট যোগ করা ছাড়া এটি কোনও উদ্দেশ্য পূরণ করে না বলে মনে হয়।

উদাহরণ স্বরূপ, PPPoEoA- এর ক্ষেত্রে, যেখানে কোন ফিজিক্যাল ইথারনেট ছিল না, শুধুমাত্র ATM ছিল, শুধুমাত্র হেডার ওভারহেডের একটি অপ্রয়োজনীয় ইথারনেট MAC লেয়ার যোগ করা হয়নি বরং এটিএম-এর উপরে ইথারনেট ফিট করার জন্য একটি অতিরিক্ত ইথারনেট অভিযোজন স্তরও যোগ করা হয়েছে। .দ্বিতীয় ব্যবহারের ক্ষেত্রে, এই অতিরিক্ত প্রোটোকল শিরোনামগুলি গুরুতর পরিমাণে ফোলা যোগ করে এবং তাই অল্প পরিমাণে কার্যক্ষমতার ক্ষতি করে।

দ্বিতীয় ব্যবহারের ক্ষেত্রে, PPP+PPPoE+ইথারনেট MAC-এর ব্যবহার একটি পরিবর্তনশীল দূরত্ব আপস্ট্রিম পর্যন্ত প্রসারিত হয়। এটি ' প্রথম মাইল' -এর মধ্যে সীমাবদ্ধ থাকতে পারে: ADSL বা VDSL2 / FTTC- এ একটি তামার টুইস্টেড পেয়ার যাতে মডেম জড়িত থাকে এবং আরও কিছু নয়, অথবা এটি আরও আপস্ট্রিম BRAS 'ব্রডব্যান্ড রিমোট অ্যাকসেস সার্ভার' বা 'অ্যাক্সেস কনসেনট্রেটর' পর্যন্ত ব্যবহার করা যেতে পারে। যা লগইন পরিচালনা করতে পারে বা নাও পারে তবে অবশ্যই কোনও ধরণের প্রোটোকল রূপান্তরকারী হবে। একটি উদাহরণের ক্ষেত্রে PPPoE একটি পাইকারি ক্যারিয়ার দ্বারা পরিচালিত এই ধরনের একটি নোডে আপস্ট্রিম পর্যন্ত প্রসারিত এবং সমাপ্ত করে যা L2TP টানেলিং প্রোটোকলে রূপান্তর করে যা ISP-এর IP POPs ('পয়েন্ট অফ উপস্থিতি') এ টানেল করে।

পর্যায়[সম্পাদনা]

PPPoE এর দুটি স্বতন্ত্র পর্যায় রয়েছে:

PPPoE আবিষ্কার[সম্পাদনা]

যেহেতু প্রথাগত PPP সংযোগ দুটি প্রান্তের মধ্যে একটি সিরিয়াল লিঙ্কের মাধ্যমে বা একটি ATM ভার্চুয়াল সার্কিটের মধ্যে প্রতিষ্ঠিত হয় যা ইতিমধ্যেই ডায়াল-আপের সময় স্থাপিত হয়েছে, তাই তারে পাঠানো সমস্ত PPP ফ্রেম অন্য প্রান্তে পৌঁছাতে নিশ্চিত। কিন্তু ইথারনেট নেটওয়ার্ক হল মাল্টি-অ্যাক্সেস যেখানে নেটওয়ার্কের প্রতিটি নোড অন্য নোড অ্যাক্সেস করতে পারে। একটি ইথারনেট ফ্রেমে গন্তব্য নোডের হার্ডওয়্যার ঠিকানা থাকে ( MAC ঠিকানা )। এটি ফ্রেমটিকে কাঙ্ক্ষিত গন্তব্যে পৌঁছাতে সহায়তা করে।

তাই ইথারনেটের মাধ্যমে সংযোগ স্থাপনের জন্য পিপিপি কন্ট্রোল প্যাকেটগুলি বিনিময় করার আগে, দুটি শেষ পয়েন্টের MAC ঠিকানাগুলি একে অপরকে জানা উচিত যাতে সেগুলি এই নিয়ন্ত্রণ প্যাকেটগুলিতে এনকোড করা যায়। PPPoE আবিষ্কার পর্যায় ঠিক এই কাজ করে। এটি একটি সেশন আইডি প্রতিষ্ঠা করতেও সাহায্য করে যা প্যাকেটের আরও বিনিময়ের জন্য ব্যবহার করা যেতে পারে।

পিপিপি অধিবেশন[সম্পাদনা]

একবার পিয়ারের MAC ঠিকানা জানা হয়ে গেলে এবং একটি সেশন প্রতিষ্ঠিত হলে, সেশন স্টেজ শুরু হবে।

PPPoE আবিষ্কার (PPPoED)[সম্পাদনা]

যদিও প্রথাগত PPP একটি পিয়ার-টু-পিয়ার প্রোটোকল, PPPoE সহজাতভাবে একটি ক্লায়েন্ট-সার্ভার সম্পর্ক কারণ একাধিক হোস্ট একটি একক শারীরিক সংযোগের মাধ্যমে একটি পরিষেবা প্রদানকারীর সাথে সংযোগ করতে পারে।

আবিষ্কার প্রক্রিয়াটি হোস্ট কম্পিউটারের মধ্যে চারটি ধাপ নিয়ে গঠিত যা ক্লায়েন্ট হিসাবে কাজ করে এবং ইন্টারনেট পরিষেবা প্রদানকারীর শেষে অ্যাক্সেস কনসেনট্রেটর সার্ভার হিসাবে কাজ করে। তারা নীচে রূপরেখা দেওয়া হয়. পঞ্চম এবং শেষ ধাপ হল একটি বিদ্যমান অধিবেশন বন্ধ করার উপায়।

সার্ভারে ক্লায়েন্ট: সূচনা (PADI)[সম্পাদনা]

PADI এর অর্থ হল PPPoE অ্যাক্টিভ ডিসকভারি ইনিশিয়েশন। [১১]

যদি একজন ব্যবহারকারী ডিএসএল ব্যবহার করে ইন্টারনেটে "ডায়াল আপ" করতে চান, তাহলে তাদের কম্পিউটারকে প্রথমে ব্যবহারকারীর ইন্টারনেট পরিষেবা প্রদানকারীর উপস্থিতি পয়েন্টে (পিওপি) ডিএসএল অ্যাক্সেস কনসেনট্রেটর (ডিএসএল-এসি) খুঁজে বের করতে হবে। ইথারনেটের মাধ্যমে যোগাযোগ শুধুমাত্র MAC ঠিকানার মাধ্যমেই সম্ভব। যেহেতু কম্পিউটার DSL-AC এর MAC ঠিকানা জানে না, তাই এটি একটি ইথারনেট সম্প্রচারের মাধ্যমে একটি PADI প্যাকেট পাঠায় (MAC: ff:ff:ff:ff:ff:ff:ff)। এই PADI প্যাকেটে পাঠানো কম্পিউটারের MAC ঠিকানা রয়েছে।

Frame 1 (44 bytes on wire, 44 bytes captured)
Ethernet II, Src: 00:50:da:42:d7:df, Dst: ff:ff:ff:ff:ff:ff
PPP-over-Ethernet Discovery
 Version: 1
 Type 1
 Code Active Discovery Initiation (PADI)
 Session ID: 0000
 Payload Length: 24
PPPoE Tags
 Tag: Service-Name
 Tag: Host-Uniq
  Binary Data: (16 bytes)

Src. (= উৎস) PADI পাঠানো কম্পিউটারের MAC ঠিকানা ধারণ করে।

</br> Dst. (=গন্তব্য) হল ইথারনেট সম্প্রচার ঠিকানা। </br> PADI প্যাকেট একাধিক DSL-AC দ্বারা গ্রহণ করা যেতে পারে। শুধুমাত্র DSL-AC সরঞ্জাম যেগুলি "পরিষেবা-নাম" ট্যাগ পরিবেশন করতে পারে তাদের উত্তর দেওয়া উচিত।

ক্লায়েন্টকে সার্ভার: অফার (PADO)[সম্পাদনা]

PADO এর অর্থ হল PPPoE সক্রিয় আবিষ্কার অফার। [১২]

একবার ব্যবহারকারীর কম্পিউটার PADI প্যাকেটটি প্রেরণ করলে, DSL-AC PADI-তে সরবরাহ করা MAC ঠিকানা ব্যবহার করে একটি PADO প্যাকেটের সাথে উত্তর দেয়। PADO প্যাকেটে DSL-AC এর MAC ঠিকানা, এর নাম (যেমন Leipzig- এ T-Com DSL-AC-এর জন্য LEIX11-erx) এবং পরিষেবার নাম রয়েছে। যদি একাধিক POP এর DSL-AC একটি PADO প্যাকেটের সাথে উত্তর দেয়, ব্যবহারকারীর কম্পিউটার সরবরাহকৃত নাম বা পরিষেবা ব্যবহার করে একটি নির্দিষ্ট POP-এর জন্য DSL-AC নির্বাচন করে।

এখানে একটি PADO প্যাকেটের একটি উদাহরণ:

Frame 2 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: 00:0e:40:7b:f3:8a, Dst: 00:50:da:42:d7:df
PPP-over-Ethernet Discovery
  Version: 1
  Type 1
  Code Active Discovery Offer (PADO)
  Session ID: 0000
  Payload Length: 36
PPPoE Tags
  Tag: AC-Name
    String Data: IpzbrOOl
  Tag: Host-Uniq
    Binary Data: (16 bytes)

AC-Name -> স্ট্রিং ডেটা এসি নাম ধারণ করে, এই ক্ষেত্রে "Ipzbr001" (লিপজিগে Arcor DSL-AC) </br> Src. DSL-AC এর MAC ঠিকানা ধারণ করে। </br> DSL-AC এর MAC ঠিকানাটি DSL-AC এর নির্মাতাকেও প্রকাশ করে (এই ক্ষেত্রে Nortel Networks )।

সার্ভারে ক্লায়েন্ট: অনুরোধ (PADR)[সম্পাদনা]

PADR মানে PPPoE সক্রিয় আবিষ্কারের অনুরোধ। [১৩]

DSL-AC থেকে একটি গ্রহণযোগ্য PADO প্যাকেট প্রাপ্তির পর ব্যবহারকারীর কম্পিউটার দ্বারা একটি PADR প্যাকেট DSL-AC-তে পাঠানো হয়। এটি PADO প্যাকেট প্রদানকারী DSL-AC দ্বারা তৈরি একটি PPPoE সংযোগের প্রস্তাবের গ্রহণযোগ্যতা নিশ্চিত করে।

সার্ভার থেকে ক্লায়েন্ট: সেশন-নিশ্চিতকরণ (PADS)[সম্পাদনা]

PADS এর অর্থ হল PPPoE অ্যাক্টিভ ডিসকভারি সেশন-নিশ্চিতকরণ। [১৪]

উপরের PADR প্যাকেটটি একটি PADS প্যাকেটের সাথে DSL-AC দ্বারা নিশ্চিত করা হয়েছে এবং এটির সাথে একটি সেশন আইডি দেওয়া হয়েছে৷ সেই POP-এর জন্য DSL-AC-এর সাথে সংযোগ এখন সম্পূর্ণরূপে প্রতিষ্ঠিত হয়েছে৷

হয় প্রান্ত থেকে অন্য প্রান্তে: সমাপ্তি (PADT)[সম্পাদনা]

PADT এর অর্থ হল PPPoE অ্যাক্টিভ ডিসকভারি টার্মিনেশন। [১৫] এই প্যাকেট POP এর সাথে সংযোগ বন্ধ করে দেয়। এটি ব্যবহারকারীর কম্পিউটার বা DSL-AC থেকে পাঠানো যেতে পারে।

প্রোটোকল ওভারহেড[সম্পাদনা]

PPPoE একটি ইথারনেট লিঙ্কের মাধ্যমে একটি পিসি বা একটি রাউটারকে একটি মডেমের সাথে সংযোগ করতে ব্যবহৃত হয় এবং এটি ADSL প্রোটোকল স্ট্যাকের উপর PPPoE ওভার ATM (PPPoEoA) এর একটি টেলিফোন লাইনে DSL এর মাধ্যমে ইন্টারনেট অ্যাক্সেসের ক্ষেত্রেও ব্যবহার করা যেতে পারে। এটিএম- এর উপর PPPoE-এর জনপ্রিয় DSL বিতরণ পদ্ধতির মধ্যে সর্বোচ্চ ওভারহেড রয়েছে, উদাহরণস্বরূপ PPPoA ( RFC 2364 ) এর সাথে তুলনা করা হলে। [১৬] [১৭] [১৮] [১৯]

DSL-এর সাথে ব্যবহার করুন - PPPoE ওভার ATM (PPPoEoA)[সম্পাদনা]

একটি DSL লিঙ্কে PPPoEoA দ্বারা যুক্ত ওভারহেডের পরিমাণ প্যাকেটের আকারের উপর নির্ভর করে কারণ (i) এটিএম সেল-প্যাডিংয়ের শোষণকারী প্রভাব (নীচে আলোচনা করা হয়েছে), যা কিছু ক্ষেত্রে PPPoEoA-এর অতিরিক্ত ওভারহেড সম্পূর্ণরূপে বাতিল করে, (ii) PPPoEoA + AAL5 ওভারহেড যা একটি সম্পূর্ণ অতিরিক্ত 53-বাইট ATM সেলের প্রয়োজন হতে পারে এবং (iii) IP প্যাকেটের ক্ষেত্রে, PPPoE ওভারহেড প্যাকেটগুলিতে যোগ করা হয়েছে যেগুলি সর্বাধিক দৈর্ঘ্যের ( ' MRU ' ) আইপি ফ্র্যাগমেন্টেশনের কারণ হতে পারে,

যা এছাড়াও ফলাফল উভয় আইপি টুকরা জন্য প্রথম দুটি বিবেচনা জড়িত. [২০] তবে এই মুহূর্তে ATM এবং IP ফ্র্যাগমেন্টেশন উপেক্ষা করে, PPP + PPPoEoA বেছে নেওয়ার কারণে ATM পেলোডের জন্য প্রোটোকল হেডার ওভারহেড 44 বাইট = 2 বাইট (PPP-এর জন্য) + 6 (PPPoE-এর জন্য) + 18 (ইথারনেট MAC, পরিবর্তনশীল) হতে পারে। ) + 10 ( RFC 2684 LLC, পরিবর্তনশীল) + 8 (AAL5 CPCS)। [২১] PPPoEoA-এর জন্য [rfc:2684 RFC 2684-] এ বর্ণিত LLC হেডার বিকল্প ব্যবহার করার সময় এই ওভারহেডটি পাওয়া যায়। [২২] [২৩]

এটিকে আরও বেশি হেডার-দক্ষ প্রোটোকলের সাথে তুলনা করুন, PPP + PPPoA RFC 2364 VC-MUX ওভার ATM+DSL, যার ATM পেলোডের মধ্যে মাত্র 10-বাইট ওভারহেড রয়েছে। (আসলে, শুধু মাত্র 10 বাইট = 2 বাইট PPP এর জন্য + শূন্য RFC 2364 + 8 (AAL5 CPCS) এর জন্য ) [২৪] [২৫]

44 বাইট AAL5 পেলোড ওভারহেডের এই চিত্রটি দুটি উপায়ে হ্রাস করা যেতে পারে: (i) 4-বাইট ইথারনেট MAC FCS বাতিল করার RFC 2684 বিকল্পটি বেছে নেওয়ার মাধ্যমে, যা 18 বাইটের উপরের চিত্রটিকে 14-এ কমিয়ে দেয় এবং (ii) দ্বারা RFC 2684 VC-MUX বিকল্প ব্যবহার করে, যার ওভারহেড অবদান এলএলসি বিকল্পের 10 বাইট ওভারহেডের তুলনায় মাত্র 2 বাইট। এটা দেখা যাচ্ছে যে এই ওভারহেড হ্রাস একটি মূল্যবান দক্ষতা উন্নতি হতে পারে। এলএলসি-এর পরিবর্তে VC-MUX ব্যবহার করে, এটিএম পেলোড ওভারহেড হয় 32 বাইট (ইথারনেট এফসিএস ছাড়া) বা 36 বাইট (এফসিএস সহ)। [২৬] [২৭]

ATM AAL5 এর জন্য প্রয়োজন যে একটি 8-বাইট-লম্বা 'CPCS' ট্রেলার অবশ্যই AAL5 পেলোড প্যাকেট তৈরি করে ATM সেলগুলির রানের চূড়ান্ত সেলের একেবারে শেষে ('সঠিক ন্যায়সঙ্গত') উপস্থিত থাকতে হবে। এলএলসি ক্ষেত্রে, ইথারনেট MAC এফসিএস থাকলে মোট ATM পেলোড ওভারহেড 2 + 6 + 18 + 10 + 8 = 44 বাইট, অথবা 2 + 6 + 14 + 10 + 8 = 40 বাইট কোনো FCS ছাড়াই। আরও দক্ষ VC-MUX ক্ষেত্রে এটিএম পেলোড ওভারহেড হল 2 + 6 + 18 + 2 + 8 = 36 বাইট (FCS সহ), বা 2 + 6 + 14 + 2 + 8 = 32 বাইট (কোনও FCS নেই)।

যাইহোক, প্রেরিত ATM পেলোড ডেটার মোট পরিমাণের পরিপ্রেক্ষিতে সত্যিকারের ওভারহেড শুধুমাত্র একটি নির্দিষ্ট অতিরিক্ত মান নয় - এটি শুধুমাত্র শূন্য বা 48 বাইট হতে পারে (আগে উল্লেখিত দৃশ্য (iii) বাদ দিয়ে, আইপি ফ্র্যাগমেন্টেশন)। এর কারণ হল ATM সেলগুলি 48 বাইটের পেলোড ক্ষমতা সহ স্থির দৈর্ঘ্য, এবং অতিরিক্ত হেডারের কারণে AAL5 পেলোডের একটি বৃহত্তর অতিরিক্ত পরিমাণ যোগ করার জন্য অতিরিক্ত একটি সম্পূর্ণ ATM সেল পাঠানোর প্রয়োজন হতে পারে। প্রতিটি কক্ষের পেলোড 48 বাইট দীর্ঘ তা নিশ্চিত করার জন্য শেষ এক বা দুটি ATM কোষে প্যাডিং বাইট থাকে। [২৮] [২৯]

একটি উদাহরণ: PPPoEoA এবং RFC2684-LLC সহ AAL5/ATM-এর উপর পাঠানো 1500-বাইটের আইপি প্যাকেটের ক্ষেত্রে, এই মুহূর্তের জন্য চূড়ান্ত সেল প্যাডিংকে উপেক্ষা করে, একটি 1500 + 2 + 6 + 18 + 10 + 8 (AAL5 CPCS) দিয়ে শুরু হয় ট্রেলার) = 1544 বাইট যদি ইথারনেট FCS উপস্থিত থাকে, অন্যথায় + 2 + 6 + 14 + 10 + 8 = 40 বাইট নেই FCS ছাড়া। ATM এর মাধ্যমে 1544 বাইট পাঠাতে 33 48-বাইট ATM সেল প্রয়োজন, যেহেতু 32 সেল × 48 বাইট প্রতি সেল = 1536 বাইটের উপলব্ধ পেলোড ক্ষমতা যথেষ্ট নয়৷ এটিকে PPP + PPPoA এর ক্ষেত্রে তুলনা করুন যা 1500 + 2 (PPP) + 0 (PPPoA: RFC 2364 VC-MUX) + 8 (CPCS ট্রেলার) = 1510 বাইট 32 টি ঘরে ফিট করে। তাই 1500-বাইট আইপি প্যাকেটের জন্য PPPoEoA প্লাস RFC2684-LLC বেছে নেওয়ার আসল খরচ হল প্রতি IP প্যাকেটের জন্য একটি অতিরিক্ত ATM সেল, 33:32 অনুপাত। [৩০] [৩১] [৩২] তাই 1500 বাইট প্যাকেটের জন্য, LLC সহ PPPoEoA PPPoA বা PPPoEoA হেডার বিকল্পগুলির সর্বোত্তম পছন্দগুলির চেয়ে ~3.125% ধীর।

কিছু প্যাকেট দৈর্ঘ্যের জন্য PPPoA এর তুলনায় PPPoEoA বেছে নেওয়ার কারণে প্রকৃত অতিরিক্ত কার্যকর DSL ওভারহেড শূন্য হবে যদি অতিরিক্ত হেডার ওভারহেড সেই নির্দিষ্ট প্যাকেট দৈর্ঘ্যে একটি অতিরিক্ত ATM সেল প্রয়োজনের জন্য যথেষ্ট না হয়। উদাহরণস্বরূপ, RFC2684-LLC প্লাস FCS ব্যবহার করে PPP + PPPoEoA-এর সাথে পাঠানো একটি 1492 বাইট লম্বা প্যাকেট আমাদের মোট ATM পেলোড দেয় 1492 + 44 = 1536 বাইট = 32 সেল ঠিক, এবং এই বিশেষ ক্ষেত্রে ওভারহেড এর চেয়ে বেশি নয় যদি আমরা হেডার-দক্ষ PPPoA প্রোটোকল ব্যবহার করছিল, যার জন্য 1492 + 2 + 0 + 8 = 1502 বাইট ATM পেলোড = 32 সেল প্রয়োজন হবে। [৩৩] [৩৪] যে ক্ষেত্রে প্যাকেটের দৈর্ঘ্য 1492 হয় সেটি অনুপাতের শর্তে RFC2684-LLC-এর সাথে PPPoEoA-এর জন্য সর্বোত্তম দক্ষতার প্রতিনিধিত্ব করে, যদি না আরও লম্বা প্যাকেট অনুমোদিত হয়।

RFC2684 VC-MUX হেডার বিকল্পের সাথে PPPoEoA ব্যবহার করা সবসময় এলএলসি বিকল্পের চেয়ে অনেক বেশি কার্যকর, যেহেতু এটিএম ওভারহেড, যেমনটি আগে উল্লেখ করা হয়েছে, শুধুমাত্র 32 বা 36 বাইট (এটি PPPoEoA-তে ইথারনেট এফসিএস বিকল্প ছাড়া বা সহ আছে কিনা তার উপর নির্ভর করে) ) যাতে VC-MUX ব্যবহার করে PPP + PPPoEoA-এর সমস্ত ওভারহেড সহ একটি 1500 বাইট লম্বা প্যাকেট মোট 1500 + 36 = 1536 বাইট ATM পেলোডের সমান হয় যদি FCS উপস্থিত থাকে = 32 ATM সেল ঠিক থাকে, এইভাবে একটি সম্পূর্ণ ATM সেল সংরক্ষণ করা হয়৷ [৩৫] [৩৬]

সংক্ষিপ্ত প্যাকেটের সাথে, হেডার যত বেশি লম্বা হবে একটি অতিরিক্ত ATM সেল তৈরির সম্ভাবনা তত বেশি। একটি খারাপ ক্ষেত্রে একটি 10 বাইট হেডার ওভারহেডের তুলনায় 44 বাইট হেডার ওভারহেডের কারণে দুটির পরিবর্তে 3টি এটিএম সেল পাঠানো হতে পারে, তাই ডেটা প্রেরণ করতে 50% বেশি সময় লাগে৷ উদাহরণস্বরূপ, IPv6-এর উপরে একটি TCP ACK প্যাকেট 60 বাইট দীর্ঘ, এবং PPPoEoA + LLC-এর জন্য 40 বা 44 বাইটের ওভারহেড সহ এর জন্য তিনটি 48 বাইট ATM সেলের পেলোড প্রয়োজন। তুলনা হিসাবে, PPPoA 10 বাইটের ওভারহেড সহ তাই 70 বাইট মোট দুটি ঘরে ফিট করে। তাই PPPoA এর চেয়ে PPPoE/LLC বেছে নেওয়ার অতিরিক্ত খরচ 50% অতিরিক্ত ডেটা পাঠানো হয়। PPPoEoA + VC-MUX যদিও ঠিক হবে: 32 বা 36 বাইট ওভারহেড সহ, আমাদের আইপি প্যাকেট এখনও দুটি ঘরে ফিট করে।

সব ক্ষেত্রে এটিএম-ভিত্তিক ADSL ইন্টারনেট অ্যাক্সেসের জন্য সবচেয়ে কার্যকর বিকল্প হল PPPoA (RFC2364) VC-MUX বেছে নেওয়া। যাইহোক, যদি PPPoEoA প্রয়োজন হয়, তাহলে সর্বোত্তম পছন্দ হল VC-MUX ব্যবহার করা (LLC-এর বিপরীতে) কোনো ইথারনেট FCS ছাড়াই, একটি ATM পেলোড 32 বাইট = 2 বাইট (PPP-এর জন্য) + 6 (PPPoE-এর জন্য) ওভারহেড দেওয়া। + 14 (ইথারনেট MAC, FCS নেই) + 2 ( RFC 2684 VC-MUX) + 8 (AAL5 CPCS ট্রেলার)।

দুর্ভাগ্যবশত কিছু DSL পরিষেবার জন্য PPPoE-এর সাথে অযথা এলএলসি হেডার ব্যবহার করা প্রয়োজন এবং আরও দক্ষ VC-MUX বিকল্পের অনুমতি দেয় না। সেক্ষেত্রে, একটি হ্রাসকৃত প্যাকেটের দৈর্ঘ্য ব্যবহার করে, যেমন 1492-এর সর্বোচ্চ MTU প্রয়োগ করা দীর্ঘ প্যাকেটের সাথে এমনকি এলএলসি শিরোনামগুলির সাথেও দক্ষতা পুনরুদ্ধার করে এবং, যেমনটি আগে উল্লেখ করা হয়েছে, সেই ক্ষেত্রে কোনও অতিরিক্ত অপচয়কারী ATM সেল তৈরি হয় না।

ইথারনেটে ওভারহেড[সম্পাদনা]

একটি ইথারনেট LAN-এ, PPP + PPPoE-এর ওভারহেড হল একটি নির্দিষ্ট 2 + 6 = 8 বাইট, যদি না আইপি ফ্র্যাগমেন্টেশন তৈরি হয়।

তথ্যসূত্র[সম্পাদনা]

  1. ↑ James Boney (২০০৫)। Cisco IOS in a Nutshell। O'Reilly Media, Inc.। পৃষ্ঠা 88। আইএসবিএন 978-0-596-55311-1। 
  2. ↑ Philip Golden; Hervé Dedieu (২০০৭)। Implementation and Applications of DSL Technology। Taylor & Francis। পৃষ্ঠা 479। আইএসবিএন 978-1-4200-1307-8। 
  3. ↑ "How to create a PPPoE connection in Windows XP"। ৩ ডিসেম্বর ২০১৩ তারিখে মূল থেকে আর্কাইভ করা। সংগ্রহের তারিখ ১১ ডিসেম্বর ২০১৩। 
  4. ↑ "Configuring Linux"। www.tldp.org। সংগ্রহের তারিখ ২৬ মার্চ ২০১৯। 
  5. ↑ "Connecting to the Internet with PPPoE (Mac OS X v10.5 and earlier)"। Apple Support। সংগ্রহের তারিখ ২৬ মার্চ ২০১৯। 
  6. ↑ Wind River Systems Acquires RouterWare, Inc.. Findarticles.com (1999-07-05). Retrieved on 2011-09-27. ওয়েব্যাক মেশিনে আর্কাইভকৃত ২০০৫-০৫-২৬ তারিখে
  7. ↑ Philip Golden; Hervé Dedieu (২০০৭)। Implementation and Applications of DSL Technology। Taylor & Francis। পৃষ্ঠা 479। আইএসবিএন 978-1-4200-1307-8। 
  8. ↑ ক খ Michael Beck (২০০৫)। Ethernet in the First Mile : The IEEE 802.3ah EFM Standard। McGraw Hill Professional। পৃষ্ঠা 27। আইএসবিএন 978-0-07-146991-3। 
  9. ↑ Richard D. Gitlin; Sailesh K. Rao (৮ মে ১৯৯০)। "Method and apparatus for wideband transmission of digital signals between, for example, a telephone central office and customer premises"। US Patent 4,924,492। 
  10. ↑ "TouchWave Partners With Telogy Networks For VoIP Embedded Communications Software"। Business Wire। ৫ অক্টোবর ১৯৯৮। সংগ্রহের তারিখ ১৬ ডিসেম্বর ২০০৮। [অকার্যকর সংযোগ]
  11. ↑ Mamakos, L.; Simone, D. (ফেব্রুয়ারি ১৯৯৯)। "A Method for Transmitting PPP Over Ethernet (PPPoE)"। ডিওআই:10.17487/RFC2516। সংগ্রহের তারিখ ২৬ মার্চ ২০১৯। 
  12. ↑ Mamakos, L.; Simone, D. (ফেব্রুয়ারি ১৯৯৯)। "A Method for Transmitting PPP Over Ethernet (PPPoE)"। ডিওআই:10.17487/RFC2516। সংগ্রহের তারিখ ২৬ মার্চ ২০১৯। 
  13. ↑ Mamakos, L.; Simone, D. (ফেব্রুয়ারি ১৯৯৯)। "A Method for Transmitting PPP Over Ethernet (PPPoE)"। ডিওআই:10.17487/RFC2516। সংগ্রহের তারিখ ২৬ মার্চ ২০১৯। 
  14. ↑ Mamakos, L.; Simone, D. (ফেব্রুয়ারি ১৯৯৯)। "A Method for Transmitting PPP Over Ethernet (PPPoE)"। ডিওআই:10.17487/RFC2516। সংগ্রহের তারিখ ২৬ মার্চ ২০১৯। 
  15. ↑ Mamakos, L.; Simone, D. (ফেব্রুয়ারি ১৯৯৯)। "A Method for Transmitting PPP Over Ethernet (PPPoE)"। ডিওআই:10.17487/RFC2516। সংগ্রহের তারিখ ২৬ মার্চ ২০১৯। 
  16. ↑ Dirk Van Aken, Sascha Peckelbeen Encapsulation Overhead(s) in ADSL Access Networks, June 2003
  17. ↑ Kaycee, Manu; Gross, George (জুলাই ১৯৯৮)। "PPP Over AAL5"। ডিওআই:10.17487/RFC2364। সংগ্রহের তারিখ ২৬ মার্চ ২০১৯। 
  18. ↑ Grossman, Dan; Heinanen, Juha (সেপ্টেম্বর ১৯৯৯)। "Multiprotocol Encapsulation over ATM Adaptation Layer 5"। ডিওআই:10.17487/RFC2684। সংগ্রহের তারিখ ২৬ মার্চ ২০১৯। 
  19. ↑ "Simon Farnsworth article"। farnz.org.uk। সংগ্রহের তারিখ ২৬ মার্চ ২০১৯। 
  20. ↑ Encapsulation Overhead(s) in ADSL Access Networks.[অকার্যকর সংযোগ]
  21. ↑ Dirk Van Aken, Sascha Peckelbeen Encapsulation Overhead(s) in ADSL Access Networks, June 2003
  22. ↑ Grossman, Dan; Heinanen, Juha (সেপ্টেম্বর ১৯৯৯)। "Multiprotocol Encapsulation over ATM Adaptation Layer 5"। ডিওআই:10.17487/RFC2684। সংগ্রহের তারিখ ২৬ মার্চ ২০১৯। 
  23. ↑ "Simon Farnsworth article"। farnz.org.uk। সংগ্রহের তারিখ ২৬ মার্চ ২০১৯। 
  24. ↑ Kaycee, Manu; Gross, George (জুলাই ১৯৯৮)। "PPP Over AAL5"। ডিওআই:10.17487/RFC2364। সংগ্রহের তারিখ ২৬ মার্চ ২০১৯। 
  25. ↑ "Simon Farnsworth article"। farnz.org.uk। সংগ্রহের তারিখ ২৬ মার্চ ২০১৯। 
  26. ↑ Dirk Van Aken, Sascha Peckelbeen Encapsulation Overhead(s) in ADSL Access Networks, June 2003
  27. ↑ Grossman, Dan; Heinanen, Juha (সেপ্টেম্বর ১৯৯৯)। "Multiprotocol Encapsulation over ATM Adaptation Layer 5"। ডিওআই:10.17487/RFC2684। সংগ্রহের তারিখ ২৬ মার্চ ২০১৯। 
  28. ↑ Dirk Van Aken, Sascha Peckelbeen Encapsulation Overhead(s) in ADSL Access Networks, June 2003
  29. ↑ Grossman, Dan; Heinanen, Juha (সেপ্টেম্বর ১৯৯৯)। "Multiprotocol Encapsulation over ATM Adaptation Layer 5"। ডিওআই:10.17487/RFC2684। সংগ্রহের তারিখ ২৬ মার্চ ২০১৯। 
  30. ↑ Dirk Van Aken, Sascha Peckelbeen Encapsulation Overhead(s) in ADSL Access Networks, June 2003
  31. ↑ Kaycee, Manu; Gross, George (জুলাই ১৯৯৮)। "PPP Over AAL5"। ডিওআই:10.17487/RFC2364। সংগ্রহের তারিখ ২৬ মার্চ ২০১৯। 
  32. ↑ Grossman, Dan; Heinanen, Juha (সেপ্টেম্বর ১৯৯৯)। "Multiprotocol Encapsulation over ATM Adaptation Layer 5"। ডিওআই:10.17487/RFC2684। সংগ্রহের তারিখ ২৬ মার্চ ২০১৯। 
  33. ↑ Dirk Van Aken, Sascha Peckelbeen Encapsulation Overhead(s) in ADSL Access Networks, June 2003
  34. ↑ Grossman, Dan; Heinanen, Juha (সেপ্টেম্বর ১৯৯৯)। "Multiprotocol Encapsulation over ATM Adaptation Layer 5"। ডিওআই:10.17487/RFC2684। সংগ্রহের তারিখ ২৬ মার্চ ২০১৯। 
  35. ↑ Dirk Van Aken, Sascha Peckelbeen Encapsulation Overhead(s) in ADSL Access Networks, June 2003
  36. ↑ Grossman, Dan; Heinanen, Juha (সেপ্টেম্বর ১৯৯৯)। "Multiprotocol Encapsulation over ATM Adaptation Layer 5"। ডিওআই:10.17487/RFC2684। সংগ্রহের তারিখ ২৬ মার্চ ২০১৯। 
'https://bn.wikipedia.org/w/index.php?title=খসড়া:ইথারনেটের_উপর_পয়েন্ট-টু-পয়েন্ট_প্রোটোকল&oldid=7121808' থেকে আনীত