DCPCP
פרוטוקול בקרת DCP – DCPCP, משמש לאפשר, לא לאפשר ולעצב DCP.
ל- DCPCP יש שני מצבי פעולה: מצב 1 ומצב 2.
מצב 2 מספק יכולות מו"מ מלאות לאפשר, לא לאפשר ולעצב DCP באמצעות שימוש בפרוצדורות מו"מ של פרוטוקול נקודה לנקודה (PPP) ופרוטוקול בקרת קישור (LCP).
מצב 1 משתמש בתת מערכת של המו"מ של מצב 2 עם פרוצדורות פשוטות על מנת לאפשר ולא לאפשר DCP עם ברירת המחדל DCFD וערכי פרמטר של ברירת מחדל.
פעולה במצב 1 היא חובה, בעוד שפעולה במצב 2 אופציונאלית.
אורך כותרת ה- DCP של ה- PDU של בקרת ה- DCP הוא אוקטט אחד.
PDU של DCPCP משתמשים באותן תבניות כמו של PPP LCP , כפי שמוגדר ב- RFC 1661, מצב 1 של DCPCP משתמש בתת מערכת של תבניות DCPCP PDU (בקשת תצורה ואישור קבלת תצורה עם תצורת מצב 1 אופציונאלית בלבד).
תבנית מנת ה- DCPCP מכילה את הכותרת ואחריו ה- PDU, אשר משתמש באותו הפורמט כמו ה- PPP LCP כמודגם להלן:
|
קוד |
מזהה |
אורך |
נתונים |
|
1 בית |
1 בית |
2 בתים |
משתנה |
DCPCP PDU מבנה
קוד
ערך דצימלי המראה את סוג המנה:
1 – בקשת תצורה
2 – אישור קבלת תצורה
3 – Nak. של תצורה
4 – דחיית תצורה
5 – בקשת השמדה
6 – אישור קבלת השמדה
7 – דחיית קוד
8 – דחיית פרוטוקול
9 – בקשת Echo
10 – תגובת Echo
11 – בקשת השלכה
12 – דו"ח איכות הקישור
מזהה
ערך דצימלי אשר מסייע להתאים בקשות ותגובות.
אורך
אורך המנה, כולל הקוד, המזהה, אורך ושדות נתונים.
נתונים
שדה בעל אורך משתנה שיכול להכיל אחת או יותר אפשרויות תצורה.
תבנית אפשרויות התצורה היא כדלקמן:
|
סוג |
אורך |
שיפור |
DCPCP אפשרויות תצורת
סוג
מזהה בן בית אחד של סוג אפשרות התצורה, נקבע ל- 254 בהודעות של מצב 1.
אורך
אורך אפשרות התצורה כולל הסוג, אורך ושדות נתונים, נקבע ל- 3.
שיפור
שדה השיפור חייב להיות באורך של אוקטט אחד ולהכיל את מספר השיפור. המספר הנוכחי הוא 1.
הודעות בקשה ותגובה של מצב 1
הודעת בקשת מצב 1 היא מנת בקשת תצורת DCPCP עם שדה קוד שנקבע כ- 1
הודעת תגובה של מצב 1 היא מנת אישור קבלת תצורת DCPCP עם שדה קוד שנקבע כ- 2
תבניות מצב 2
תבניות מצב 2 הן כמו התבניות של מנת ה- LCP , כפי שניתן לראות למעלה, עם סט מיחוד של אפשרויות תצורה.
מנות ה- LCP עם קודים מ- 1 עד 7 הן חובה. המנות האחרות מוגדרות ב- RFC 1661 והן אופציונאליות.
NNI SVC (FRF.10)
המאבחן גם תומך בקידוד של מסגרות SVC של רשת לרשת (NNI) בהתאם להסכם היישום של פורום ה- Frame Relay – FRF .10.
הסכם היישום מיישם SVC דרך NNI של Frame Relay ול- SPVC.
זה מיושם ב- NNI-ים כאשר שתי הרשתות הן פרטיות, שתיהן ציבוריות או שאחת היא פרטית ואחת ציבורית.
מסגרות אלו מזוהות באופן אוטומטי ע"י המאבחן ומוצגות באופן הנכון.
FRF.12
זהו הסכם יישום חלוקה של Frame Relay.
החלוקה/קיטוע מפחיתה את השהות והעיכוב ברשתות ה- Frame Relay באמצעות חלוקת מנות נתונים גדולות למנות קטנות יותר ולאחר מכן כינוס מחדש של הנתונים אל תוך המסגרות המקוריות ביעד.
יכולת זו רלוונטית באופן מיחוד למשתמשים הרוצים לשלב קול ויישומים אחרים הרגישים לזמן, כמו יישומי משימה קריטית – SNA, עם יישומים שלא רגישים לזמן או נתונים אחרים על מעגל וירטואלי זמני אחד – PVC.
הרווח העיקרי של החלוקה הוא היכולת לנצל את הגישה לקוים של מנשק הרשת ע"י המשתמש הנפוץ או לקווי מנשק הרשת לרשת (NNI) וגם/או PVC-ים עבור חיבורים המשלבים מספר מסגרות גדול ופרוטוקולים של זמן אמת.
חלוקת מסגרות מגדילה את התועלת והאחידות של רשתות Frame Relay , מפחיתה עיכובים ושינויי שהות בזמן שהיא משדרגת את תגובות היישום, איכותו ואמינותו.
כתוצאה מכך, סוגים שונים של תעבורה, כמו קול, פקס ונתונים יכולים להיות משולבים בצורה שקופה על UNI אחד, NNI או PVC.
הסכם יישום החלוקה מספק תשדורת של ציוד טרמינל של נתוני Frame Relay (DTE) וציוד חיבורי נתונים (DCE) עם היכולת לחלק מסגרות נתונים ארוכות לרצף של מסגרות קצרות שיכונסו מחדש למסגרת המקורית ע"י קבלה של עמית DTE או DCE. חלוקת מסגרת חיונית לבקרה על עיכובים ושינויי שהות כאשר תנועה בזמן אמת נישאת על גבי אותם מנקשים כתנועת נתונים.
חלוקה מאפשרת להיפטר מרגישות לעיכובים של תנועה על PVC אחד עם חלוקה של מסגרות ארוכות על PVC אחר המשתמש באותו המנשק.
FRF .12 תומך בשלושה ישומי חלוקה:
1. מקומית דרך מנשק Frame Relay UNI בין עמיתי ה- DTE/DCE.
2. מקומית דרך מנשק Frame Relay NNI בין עמיתי ה- DCE.
3. קצה לקצה בין שני DTE-ים של Frame Relay המחוברים ע"י אחת או שתי רשתות Frame Relay.
כאשר משתמשים בקצה לקצה, פרוצדורת החלוקה היא שקופה לרשת(ות) Frame Relay בין שידור וקבלת DTE-ים.
FREther
זהו וריאנט של Frame Relay הכולל את כותרת ה- Frame Relay ולאחריו שדה סוג Ether.
זוהי צורה נוספת של קישוריות דרך Frame Relay הנמצאת בשימוש ע"י כמה לקוחות.
גולשים מקוונים: 5