רב-נתיב

ערך זה עוסק בתקשורת נתונים. אם התכוונתם להתנהגות גלי רדיו, ראו ריבוי נתיבים (גלי רדיו).

רב-נתיב (באנגלית: Multicast) היא פעולת ניתוב יחידה של נתונים או הודעה מאלמנט מקור אל קבוצת אלמנטים של תקשורת באופן מקבילי כגון: מחשבים, מרכזיות, מכשירים סלולרים, נתבים, התקני תקשורת וכו'. פעולה זו גם נודעת בשם מולטיקאסט. קיימות דרכים שונות להעברת נתונים מאלמנט המקור אל אלמנט היעד (כמודגם בטבלה). בשיטת הרב-נתיב נתונים עוברים רק אל אלמנטים ייחודיים מתוך כלל האלמנטים, בניגוד ל-Unicast בו הנתונים עוברים ממקור יחיד ליעד יחיד. ברשתות IPv4 כתובות ה-IP שמיועדות לקבוצות ה-Multicast הן כתובות ממחלקה D.

פרטי מימוש

כאשר מדברים על עץ multicast מתייחסים לנתבים של ה-subnets ולא לכל host בנפרד ונתייחס אליהם בשם Multicast router.
Host מודיע ל-multicast router שלו על רצונו להצטרף או לעזוב קבוצה על ידי פרוטוקול IGMP (ראו להלן).
בדרך כלל נתב ה Unicast של ה-host הוא גם נתב ה-multicast שלו.
כדי להיות חלק מהקבוצה על ה-host ראשית להודיע לנתב ה-multicast שהוא מעוניין להצטרף לקבוצה, לאחר מכן עליו להודיע לשכבת ה-IP שהוא מעוניין לקבל חבילות נתונים בעלות הכתובת של הקבוצה G, ולבסוף עליו להודיע לחבילת ה-MAC שהוא מעוניין לקבל חבילות עם ה-IP של הקבוצה.
מהו ה-MAC (כתובת פיזית) של כתובת היעד כאשר שולחים חבילת multicast? לא broadcast כי אז כל ה-host-ים סתם יעבירו את ההודעה לשכבת ה-IP. לכן מגדירים כתובת MAC עבור multicast.
הגדרת כתובת MAC עבור הודעות Multicast בעייתית מאחר שמרחב כתובות ה-MAC מצומצם ניתן על ידי ה-IEEE ולכן במקום כתובת MAC אחת לכל קבוצה נצטרך ליצור כתובת MAC אחת לכל 32 קבוצות.
כרטיסי רשת בימינו באים בשתי גרסאות – האחת מקבלת את כל ה-MAC של ה-Multicast והשנייה מקבלת מספר מוגבל של קבוצות MAC.

IGMP

ערך מורחב – Internet Group Management Protocol

כאשר host מעוניין להצטרף לקבוצת multicast הוא שולח הודעת IGMP Report עם כתובת IP יעד ככתובת הקבוצה.
בכל פרק זמן נתב ה-multicast שולח הודעת IGMP Report ל-host-ים ומבקש שיודיעו לו אם הם עדיין מעוניינים להשתייך לקבוצה.
בגרסה הראשונה של IGMP אם host מעוניין לעזוב הוא פשוט לא מגיב לנתב כאשר הוא מבקש לדעת מי עדיין רוצה להיות משויך לקבוצה. בגרסה השנייה של IGMP קיימת הודעה מפורשת על רצון host לעזוב שנשלחת ל-224.0.0.2 שזו כתובת כל נתבי ה-Multicast וכתוצאה מכך הנתב שולח הודעת בדיקה: האם עדיין קיים מישהו שמעוניין לקבל הודעות?
בגרסה השלישית של IGMP צומת host יכולה לבקש קבלת הודעות Multicast ממקור ספציפי (source, Group).

בניית עץ יעיל

עבור Unicast המסלול הטוב ביותר הוא המסלול הקצר ביותר אך עבור עץ Multicast לא כך הדבר מאחר שיש להתייחס לכלל גודל העץ ולא לכל מסלול בנפרד.

עץ שמכיל את כל המסלולים הקצרים נקרא "shortest path tree" ועץ מינימלי שמגיע לכל הצמתים נקרא "Steiner tree".
בניית עץ Steiner היא NP קשה שאינה מגיבה היטב לשינויים בטופולוגיה, על כן לרוב בונים את עץ המסלולים הקצרים.
עץ המסלולים הקצרים לא יקר מאוד בהשוואה לעץ Steiner.
דרכים לצמצם את מספר העצים שקיימים עבור כל קבוצה בוחרים נקודה בשם RP (‏rendezvous point) ובכך מצמצמים את מספר העצים.

Multicast Routing Protocol

MOSPF עובד רק ברשתות בעלות Link-state.
PIM עובד בשני הסוגים – הן ב-distance vector והן ב-link-state.

Multicast OSFG ‏(M-OSPF)

פרוטוקול זה הוא הרחבה של OSPF.
הנתבים שולחים מידע נוסף ב-LSA.
המידע הנוסף הוא מסביר איזה נתב מעוניין להקשיב לאילו קבוצות.
כאשר נתב מקבל הודעת IGMP מ-host ששייך אליו הוא בודק האם הוא כבר שייך לקבוצה ואם לא הוא מפרסם הודעת LSA שמכילה מידע לגבי רצונו של הנתב להיות שייך לקבוצה.
עץ ה-Multicast נבנה לכל קבוצה בנפרד.
כמו כן ברור שהעץ צריך להבנות עבור כל מקור בנפרד (נעשה on-demand וגם נשמר במטמון).
אם משתמשים בפרוטוקול ניתוב פנימי של RIP אזי ניתן להשתמש ב-multicast של DVMRP.

Protocol Independent Multicast ‏(PIM)

מתחלק לשני תתי פרוטוקולים, האחד עבור קבוצות בעלות מעט משתתפים והשנייה עבור קבוצות שכמעט כולם משתתפים. ניתן להבדיל בין סוגי הקבוצות לפי כתובת ה IP שלהן.

Sparse mode

משתמש בנתב מרכזי בשם rendezvous point ‏(RP) שמתאם את ה-Multicast.
כאשר נתב מעוניין להצטרף לקבוצת Multicast הוא שולח הודעת JOIN ל-RP וכתוצאה מכך כל נתב בדרך ל RP מבין שמעתה והלאה הוא יצטרך להעביר הודעות Multicast של הקבוצה הספציפית אל הנתב ששלח את ה-JOIN.
אם הודעת JOIN נשלחת ובדרך ל-RP היא עוברת בנתב שהוא כבר חלק מעץ ה-Multicast אז היא תעצר שם ויתווסף ענף לעץ.
כאשר מקור רוצה לשלוח הודעה בעץ הוא שולח אותה לנתב שלו בהודעת IP. הנתב שלו עוטף אותה בעוד IP ושולח אותה ל-RP. משם ה-RP פותח את המעטפת של הנתב של המקור ושולח אותה לכל העץ. לאחר מכן (אם המקור לא היה כבר חלק מהעץ), ה-RP שולח הודעה למקור לגבי הצטרפות לקבוצה וכך כל הנתבים בדרך ידעו גם להעביר לו הודעה.
ניתן ליצור חיבור ישיר (לא דרך ה-RP) על ידי שליחת הודעת JOIN מנתב לנתב דרך המסלול הקצר ביותר ובכך יבנה עץ Multicast מהכיוון הקצר ביותר. זה שימושי כאשר יש תשדורת גבוהה מהמקור הספציפי. לאחר מכן לא ישלחו הודעות מה-RP אל הנתב המבקש אלא רק דרך המקור הישיר.
הודעת ה-JOIN שנשלחת (ל-RP או לנתב ספציפי) צריכה להישלח באופן קבוע כדי לרענן את העץ.
אם נתב עלה מעוניין לצאת מהקבוצה (כי אין יותר host שמעוניינים בו) הוא ישלח הודעת PRUNE לנתב ה-upstream שלו ויבדוק בתורו אם יש לו גם צורך לא להיות חלק מהקבוצה.
אם יש שינוי טופולוגיה והמסלול ל-RP משתנה יש לשלוח JOIN ל-RP דרך המסלול החדש ולשלוח PRUNE לנתב הישן.

Source Specific Multicast ‏(PIM-SSM)

זהו שינוי של ה-PIM-SM.
הודעת JOIN שתשלח לא תהיה (*,G) אלא (Source, G). כלומר שכשנרצה להצטרף לקבוצה נציין גם מיהו המקור המבוקש (על המצטרף להכיר מראש את IP השולח).
אין RP מאחר שהנתבים בונים את עץ המקור של הקבוצה שהוא עץ מסלולים קצרים.
פרוטוקול זה מניח שהנתבים וה-host מריצים IGMP 3.
פרוטוקול זה פותר את בעיית חוסר הכתובות ל-Multicast מאחר שכעת לכל (Source, G) יש מזהה של 64 סיביות שהוא source_ip | multicast_ip (למעשה לא מסתכלים על כתובת ה-multicast ip).
כאשר עוד חבר רוצה להצטרף לרשת, העץ שלו ישתלב עם העץ הקיים.

Dense mode

פרוטוקול זה הפוך מה-sparse mode בכך ש-host צריך להודיע לנתב שהוא לא מעוניין להיות שייך ורק כאשר כולם מודיעים שהם לא רוצים להיות שייכים הנתב יוצא.
בניגוד ל-DVRPM, נתב שולח הודעות לכל שכניו.
משתמשים ב-"flood-and-prune" שבו נתב בוחר את הנתבים שמהם הוא מעוניין לקבל חבילות ומודיע לכל השאר על ידי prune שלא ישלחו לו חבילות.

דוגמה

הנקודה האדומה מציינת את אלמנט המקור.
הנקודות הירוקות מציינות את אלמנטי היעד אליהם יגיע המידע.
הנקודות הצהובות מציינות את האלמנטים שאינם היעד ולכן המידע לא יגיע אליהם.

ראו גם

קישורים חיצוניים

מדיה וקבצים בנושא רב-נתיב בוויקישיתוף

הערך באדיבות ויקיפדיה העברית, קרדיט,
רשימת התורמים
רישיון cc-by-sa 3.0

35349451רב-נתיב

רב-נתיב

תוכן עניינים

פרטי מימוש