FMUSER更輕鬆地傳輸視頻和音頻!
es.fmuser.org
it.fmuser.org
fr.fmuser.org
de.fmuser.org
af.fmuser.org ->荷蘭語
sq.fmuser.org ->阿爾巴尼亞人
ar.fmuser.org ->阿拉伯語
hy.fmuser.org - >亞美尼亞
az.fmuser.org ->阿塞拜疆
eu.fmuser.org ->巴斯克
be.fmuser.org ->白俄羅斯語
bg.fmuser.org - >保加利亞
ca.fmuser.org ->加泰羅尼亞語
zh-CN.fmuser.org ->中文(簡體)
zh-TW.fmuser.org - >中國(繁體)
hr.fmuser.org ->克羅地亞語
cs.fmuser.org ->捷克
da.fmuser.org ->丹麥語
nl.fmuser.org - >荷蘭
et.fmuser.org ->愛沙尼亞語
tl.fmuser.org ->菲律賓
fi.fmuser.org ->芬蘭語
fr.fmuser.org - >法國
gl.fmuser.org ->加利西亞語
ka.fmuser.org ->喬治亞
de.fmuser.org ->德語
el.fmuser.org - >希臘
ht.fmuser.org ->海地克里奧爾語
iw.fmuser.org ->希伯來語
hi.fmuser.org ->印地語
hu.fmuser.org - >匈牙利
is.fmuser.org ->冰島語
id.fmuser.org ->印尼語
ga.fmuser.org ->愛爾蘭
it.fmuser.org - >意大利
ja.fmuser.org ->日語
ko.fmuser.org ->韓文
lv.fmuser.org ->拉脫維亞
lt.fmuser.org - >立陶宛
mk.fmuser.org ->馬其頓語
ms.fmuser.org ->馬來語
mt.fmuser.org ->馬耳他語
no.fmuser.org - >挪威
fa.fmuser.org ->波斯語
pl.fmuser.org ->波蘭語
pt.fmuser.org ->葡萄牙語
ro.fmuser.org - >羅馬尼亞
ru.fmuser.org ->俄語
sr.fmuser.org ->塞爾維亞語
sk.fmuser.org ->斯洛伐克
sl.fmuser.org - >斯洛文尼亞
es.fmuser.org ->西班牙語
sw.fmuser.org ->斯瓦希里語
sv.fmuser.org ->瑞典語
th.fmuser.org - >泰國
tr.fmuser.org ->土耳其語
uk.fmuser.org ->烏克蘭語
ur.fmuser.org ->烏爾都語
vi.fmuser.org - >越南
cy.fmuser.org ->威爾士語
yi.fmuser.org - >意第緒語
1簡介
作為一種新的高帶寬,高質量的Internet多媒體服務,IPTV對電信運營商的IP城域網提出了更高的要求。 與傳統的單播技術相比,組播技術的優點是在等效傳輸效率的基礎上,網絡帶寬不會隨著用戶數量的增加而線性增加,可以有效節省視頻服務器和承載網絡的負載。 因此,為使電信運營商高效,經濟地部署和實施IPTV服務,建議使用端到端組播推送,IP組播網絡的配置是關鍵。
目前,電信運營商的IP城域網主要由城域骨幹網和寬帶接入網組成,IPTV業務數據又通過城域骨幹網和寬帶接入網推送到用戶端。 城域骨幹網主要由網絡層(第3層)設備組成,這些設備可以使多播路由協議(例如PIM-SM)訪問多播源(即IPTV前端設備),以路由和轉發多播數據包。 寬帶接入網主要由數據鏈路層(第2層)設備組成,諸如IGMP Proxy或IGMP Snooping之類的技術可用於第2層多播轉發,以訪問IPTV終端設備(即IPTV機頂盒)。 圖1是IPTV端到端多播推送模型的示意圖。
pIYBAGBkThGAZmOzAAMHVeXKfuE734.png
圖1 IPTV端到端組播推送網絡模型
本文從城域骨幹網和寬帶接入網這兩個不同的網絡級別介紹了IPTV端到端多播推送網絡的關鍵配置技術。
2.城域骨幹網關鍵組播配置技術
2.1組播路由技術
多播消息和單播消息之間的主要區別是消息目標地址的標識。 多播消息的目標地址是多播組地址(以“ 1110”開頭的D類IP地址),而單播消息則基於目標主機IP。 該地址用作目標地址。 由於多播組地址和目標主機之間沒有一對一的對應關係,因此多播路由器只能使用消息源地址的唯一性來做出路由決策。 換句話說,多播路由器根據消息的源地址而不是目標地址,在遠離多播源的方向上發送消息。 這項技術稱為反向路徑轉發(簡稱RPF)。
為了避免路由環路等問題,RPF規定多播數據包必須從指定的上游相鄰節點到達路由器,而其他相鄰節點轉發的多播數據包則被丟棄。 當多播路由出現問題時,多播數據包可能無法通過單播數據包等其他路徑到達,IPTV實況廣播信號將在骨幹網中中斷,並且單播應用程序(如Web瀏覽以及郵件發送和接收)是正常的障礙。 這時,沿著多播分發路徑,檢查多播路由器及其上游相鄰節點的RPF路由表。
2.2組播路由交換技術
PIM-SM協議中的組播分發樹可以分為兩類:源樹和共享樹。 源樹使用組播源作為樹的根,也稱為最短路徑樹,可以最大程度地減少端到端組播延遲,但是路由器必須存儲大量路由信息,這會消耗大量資源。系統資源; 共享樹使用RP(PIM-SM),該協議中的一個重要路由器,用於在多播源和多播路由器之間進行路由和聚合。)作為所有多播分發樹的公共根節點,多播源流量必須先到達RP,然後才能進行傳遞,並且多播路徑通常不是最佳的,它將引入額外的網絡延遲,但是路由器需要保留的路由信息可能很小。
PIM-SM協議充分利用了兩個組播分發樹的優點。 在組播的初始階段,組播路由器無法使用源樹,因為它無法知道組播源的位置,但是可以獲取組播源通過已知的RP節點及其共享樹發送的前幾個組播數據包。 了解多播源的位置,並從共享樹切換到源樹,以減少網絡延遲並避免可能由RP節點引起的網絡瓶頸。
城域骨幹網通常主要由Cisco路由器組成。 諸如Cisco之類的路由器通過流率的預設閾值SPT-Threshold來實現多播分發樹的交換。 當檢測到組播源的組播流量超過SPT-Threshold時,組播路由將從共享樹切換到源樹。 同樣,如果多播流率低於SPT-Threshold,則其多播路由也可以從源樹切換回共享樹。 SPT-Threshold通常配置為0,以便路由器在接收到第一個多播數據包後將從共享樹切換到源。
2.3RP配置技術
作為共享樹的根節點,RP在組播過程中起上下鏈接的作用。 考慮到PIM-SM協議具有組播分發樹交換的特性,通常使用RP建立組播源與組播路由器之間的初始連接。 一旦路由器的多播路由從共享樹切換到源樹,它將不再是RP,並且再次需要其共享樹。 因此,RP在組播網絡中的位置不是很重要。 關鍵是它的可靠性和穩定性。
為了提高RP的可靠性和穩定性,可以選擇多個組播路由器來共享RP的功能(即Anycast RP技術),並為每個RP節點的環回接口分配相同的IP地址,從而形成RP。負載共享和故障保護。
組播網絡中的RP配置問題不僅與RP節點本身的配置和部署有關,而且還涉及其他組播路由器如何了解RP節點的問題。 在多播的初始階段,多播路由器可能不知道多播源的位置,但是必須知道RP地址。 組播路由器獲取RP地址的主要方式有兩種,即靜態配置RP方法和自動發現RP方法。 RP的靜態配置更安全,可以有效地防止偽造RP等欺詐活動,但網絡配置的工作量大,不利於RP等節點的動態調整。 RP的自動發現可以減少配置工作量,並簡化網絡更改和控制策略。 進行調整,但存在一定的安全風險。 對於小型城域骨幹網,可以在每個組播路由器上使用靜態配置RP的方法。 對於具有嚴格安全防禦策略的大型城域骨幹網,建議使用自動發現RP的方法。
2.4 IPTV前端組播加入技術
在多播的初始階段,多播路由器通常通過已知的RP節點及其共享樹獲取IPTV頭端(即,多播源)流量和位置信息。 為了使RP了解組播源,直接連接到組播源的組播路由器負責將組播源發送的前幾個組播數據包封裝在單獨的PIM註冊消息中,並以單播方式發起到RP的組播。模式。 來源註冊過程。 通過此消息,RP不僅可以獲取感興趣的組播組的報文,還可以獲取組播源的IP地址。 之後,RP將組播源信息轉發給其他組播路由器,並以PIM Registe-Stop消息結束組播源註冊過程。
3.寬帶接入網的組播關鍵配置技術
3.1 IPTV用戶端組播加入技術
IPTV客戶端(機頂盒)通過寬帶訪問網絡通過IGMP協議與城域骨幹網服務訪問控制層的多播路由器(通常由服務路由器或寬帶訪問服務器進行通信)進行通信,以加入或退出特定的組播組(即IPTV直播頻道)。
當機頂盒向多播路由器發送多播組加入請求消息時,消息的目標MAC地址是多播組的MAC地址而不是多播路由器,這與單播方法不同。 應當注意,組播組MAC地址實際上對應於32個不同的組播組IP地址。 這是因為組播組的MAC地址是01:00:5E:00:00:00〜01:00:5E:7F:FF:FF,即有效地址空間只有23位,有效組播組IP的地址共有28個空格。
兩者之間的映射關係是將MACC地址的低23位等同於IP地址的低23位,從而導致多播組IP地址的高5位丟失。 例如,如果三個不同的IPTV直播頻道使用224.0.0.1、224.128.0.1和239.128.0.1作為多播組IP地址,則它們對應的多播組MAC地址都為01:00:5E:00:00:01,將導致寬帶接入網絡的機頂盒和第二層設備無法區分這三個信號。 因此,在規劃組播IP地址時,請注意此類問題。
3.2二層組播轉發技術
寬帶接入網絡由大量的網絡元素設備組成,例如在數據鏈路層運行的第2層交換機和DSLAM。 第2層設備的功能是,它基於設備端口之間的MAC地址交換/轉發數據幀,並且對IP數據包的第2層(網絡層)的解析和路由功能較差,因此它不能直接支持在IGMP上工作的IGMP。第三層。 和其他多播協議。 當典型的第XNUMX層設備(例如交換機)處理IPTV多播流量時,它將根據未知的目標地址或廣播方法將多播數據幀廣播到其所有端口,這很可能會引起諸如廣播風暴之類的問題。
為了解決組播數據包泛洪的問題,需要採用IGMP Snooping和IGMP Proxy等二層組播轉發技術。 IGMP Snooping技術監視機頂盒和組播路由器之間的IGMP消息,以掌握設備端口到組播數據幀的轉發關係。 儘管IGMP代理技術在機頂盒和多播路由器之間截取IGMP消息,但是過濾和代理轉發可以節省多播路由器和第2層設備之間的多播流量,但是它需要諸如處理能力和內存之類的高性能指標。網元設備的名稱。 在配置第二層設備時,可以根據網元設備的實際性能以及對IGMP Snooping / Proxy技術的支持程度進行選擇。
以帶寬為2 Mbit / s的IPTV直播頻道為例。 如果第二層設備不使用第二層組播轉發技術,則發送到所有IPTV用戶的組播數據包將轉發到所有端口,即使用戶端口的速率為2 Mbit / s。 s的訪問帶寬,可以阻止2個IPTV直播頻道的組播數據包; 採用二層組播轉發技術後,組播數據包僅轉發到具有使用請求的端口,並且每個端口最多僅連接一個IPTV機頂盒,最多只能有一個組播數據包(即,實況頻道的10 Mbit / s流量被轉發到相應的端口。
3.3 VLAN配置技術
第2層組播轉發的流量僅涉及IPTV組播服務,不涉及其他寬帶服務。 因此,在寬帶接入網絡中,通常使用諸如VLAN之類的技術來將IPTV多播流量與其他服務和用戶流量隔離開。 常用的VLAN技術包括從組播VLAN到每個用戶VLAN的跨VLAN組播複製技術和QinQ,QinQ解決了VLAN ID數量不足的問題。
3.4靜態組播和動態組播技術
IPTV直播節目通過IP承載網傳遞給用戶終端,主要有兩種組播方式,即動態組播方式和靜態組播方式。 在動態多播模式下,交換機,DSLAM和其他設備僅在收到第一個用戶加入頻道(多播組)的請求後才接收並傳送頻道節目。 當用戶退出時,網元設備將停止接收組播流。 靜態組播模式是在交換設備上靜態配置每個IPTV頻道(組播組)的MAC組播轉發表項,無論下游用戶是否觀看,組播流已經下發到網元設備。
靜態多播流量與IPTV用戶數量無關,而與頻道數量和每個頻道的帶寬無關。 當用戶數量小於通道數量時,流量將大於單播流量;當用戶數量小於通道數量時,流量將大於單播流量。 動態多播的最大流量是當IPTV並髮用戶數小於通道數時,當IPTV並髮用戶數大於信道數時,等效於靜態多播流量。 靜態組播模式下,用戶的信道切換速度快,業務感知能力好,但網絡帶寬需求較大; 動態多播在任何情況下都可以最大程度地減少網絡流量,但是當用戶收到新的頻道(多播組)時,可能會有一定的網絡延遲。
當連接到網絡設備的IPTV用戶數量很少時,多播的優勢並不明顯。 因此,在IPTV業務發展的初期,IPTV用戶不多,或者寬帶接入網還沒有到位。 您可以使用動態多播甚至單播來傳輸IPTV實時信號。 當連接到網絡設備的用戶數量遠遠超過IPTV頻道數量時,組播以節省網絡流量帶寬的特性變得越來越重要。 此時,也就是說,當IPTV服務已經發展到成熟階段並且寬帶接入網絡已經到位時,可以使用靜態多播模式來傳輸IPTV實況信號,從而進一步提高IPTV服務質量。 因此,運營商可以根據網絡質量,IPTV業務滲透率等實際情況,決定將接入網設備配置為動態還是靜態組播方式。
4結論
結合現有的電信運營商IP城域網,系統地闡述了IPTV端到端組播推送網絡配置的關鍵技術,對於電信運營商高效,經濟地部署和實施IPTV業務具有重要的參考意義。
|
輸入電子郵件以獲取驚喜
es.fmuser.org
it.fmuser.org
fr.fmuser.org
de.fmuser.org
af.fmuser.org ->荷蘭語
sq.fmuser.org ->阿爾巴尼亞人
ar.fmuser.org ->阿拉伯語
hy.fmuser.org - >亞美尼亞
az.fmuser.org ->阿塞拜疆
eu.fmuser.org ->巴斯克
be.fmuser.org ->白俄羅斯語
bg.fmuser.org - >保加利亞
ca.fmuser.org ->加泰羅尼亞語
zh-CN.fmuser.org ->中文(簡體)
zh-TW.fmuser.org - >中國(繁體)
hr.fmuser.org ->克羅地亞語
cs.fmuser.org ->捷克
da.fmuser.org ->丹麥語
nl.fmuser.org - >荷蘭
et.fmuser.org ->愛沙尼亞語
tl.fmuser.org ->菲律賓
fi.fmuser.org ->芬蘭語
fr.fmuser.org - >法國
gl.fmuser.org ->加利西亞語
ka.fmuser.org ->喬治亞
de.fmuser.org ->德語
el.fmuser.org - >希臘
ht.fmuser.org ->海地克里奧爾語
iw.fmuser.org ->希伯來語
hi.fmuser.org ->印地語
hu.fmuser.org - >匈牙利
is.fmuser.org ->冰島語
id.fmuser.org ->印尼語
ga.fmuser.org ->愛爾蘭
it.fmuser.org - >意大利
ja.fmuser.org ->日語
ko.fmuser.org ->韓文
lv.fmuser.org ->拉脫維亞
lt.fmuser.org - >立陶宛
mk.fmuser.org ->馬其頓語
ms.fmuser.org ->馬來語
mt.fmuser.org ->馬耳他語
no.fmuser.org - >挪威
fa.fmuser.org ->波斯語
pl.fmuser.org ->波蘭語
pt.fmuser.org ->葡萄牙語
ro.fmuser.org - >羅馬尼亞
ru.fmuser.org ->俄語
sr.fmuser.org ->塞爾維亞語
sk.fmuser.org ->斯洛伐克
sl.fmuser.org - >斯洛文尼亞
es.fmuser.org ->西班牙語
sw.fmuser.org ->斯瓦希里語
sv.fmuser.org ->瑞典語
th.fmuser.org - >泰國
tr.fmuser.org ->土耳其語
uk.fmuser.org ->烏克蘭語
ur.fmuser.org ->烏爾都語
vi.fmuser.org - >越南
cy.fmuser.org ->威爾士語
yi.fmuser.org - >意第緒語
FMUSER更輕鬆地傳輸視頻和音頻!
聯絡我們
分類
電子通訊