ST 2110 Ağlarında STP, RSTP, MSTP ve ST 2022-7: Hangisini Nerede Kullanırız?
ST 2110 Ağlarında STP, RSTP, MSTP ve ST 2022-7: Hangisini Nerede Kullanırız?
Özet
Bu makale, SDI altyapıdan ST 2110/IP tabanlı yayın mimarisine geçen ağ mühendisleri, broadcast teknisyenleri ve sistem tasarımcıları için yazıldı. Amaç STP/RSTP/MSTP, multicast ve ST 2022-7 kavramlarını aynı cümlede görünce oluşan karışıklığı netleştirmek.
ST 2110 tasarımında en çok karışan sorulardan biri şudur:
Medya ağı için STP mi, RSTP mi, MSTP mi kullanacağız; yoksa ST 2022-7 mi?
Kısa cevap:
STP/RSTP/MSTP switch loop problemini çözer. ST 2022-7 medya paket sürekliliğini çözer. Bunlar aynı katmanda çalışan alternatifler değildir.
Modern ST 2110 medya fabric için pratik yaklaşım çoğunlukla şudur:
- STP/RSTP/MSTP’ye medya yedekliliği mekanizması gibi güvenilmez
- Network A ve Network B fiziksel olarak ayrı tasarlanır
- Leaf-spine veya kontrollü L3 multicast mimari tercih edilir
- PTP, QoS, IGMP/PIM-SSM ve multicast state ayrı ayrı doğrulanır
- Medya sürekliliği için receiver tarafında SMPTE ST 2022-7 kullanılır
Yani STP ailesi “network loop olmasın” der. ST 2022-7 ise “medya paketi kaybolsa bile yayın sürsün” der.
SDI dünyasında yedeklilik çoğu zaman primary/backup kablo veya router crosspoint mantığıyla düşünülürdü. ST 2110’a geçince aynı problem artık packet, multicast, path ve receiver merge davranışıyla çözülür. Bu yüzden “yedek link var mı?” sorusu tek başına yetmez; iki path’in gerçekten bağımsız olup olmadığı ve receiver’ın ST 2022-7 merge yapıp yapmadığı önemlidir.
1. ST 2110 medya ağında STP, RSTP veya MSTP kullanır mıyız?
Önce çok net ayıralım:
| Protokol / mekanizma | Ne işe yarar? | ST 2110 medya fabric için rolü |
|---|---|---|
| STP | Layer 2 loop oluşmasını engeller, bazı portları bloklar | Medya yedekliliği için uygun ana mekanizma değildir |
| RSTP | STP’nin daha hızlı toparlanan sürümüdür | Kurumsal L2 erişim ağlarında faydalı olabilir, ama RTP sürekliliği garantisi değildir |
| MSTP | VLAN bazlı birden fazla spanning tree instance yönetebilir | Karmaşık L2 tasarımlarda kullanılabilir, fakat ST 2110 A/B medya yedekliliğinin yerine geçmez |
| LACP / LAG | Birden fazla fiziksel linki tek logical bağlantı gibi kullanır | Link kapasitesi/availability sağlar, ST 2022-7 değildir |
| L3 multicast | Routed multicast ile kontrollü medya dağıtımı sağlar | Büyük ST 2110 fabric’lerde yaygın ve daha deterministik yaklaşımdır |
| ST 2022-7 | Aynı RTP akışını iki path’ten alıp receiver’da birleştirir | Medya sürekliliği için ana mekanizmadır |
LACP ve ST 2022-7 farkı nedir?
Burada LACP/LAG özellikle karışabilir. Çünkü o da birden fazla fiziksel link kullanır. Fakat LACP iki bağımsız medya path’i oluşturmaz; switch ve cihaz arasında tek logical interface oluşturur. Hash algoritmasına göre flow’ları linklere dağıtabilir, link koparsa logical bağlantıyı ayakta tutmaya çalışır. Ama receiver tarafında iki RTP kopyasını packet-level merge etmez.
ST 2022-7 ise farklıdır: Aynı RTP medya flow’u A ve B gibi iki bağımsız network üzerinden taşınır, receiver iki kopyayı aynı anda görür ve paket seviyesinde en sağlam çıktıyı üretir.
Kısa ayrım:
LACP link’i güçlendirir; ST 2022-7 yayını korur.
Peki LACP olmadan ST 2022-7 yapılabilir mi? Evet. ST 2022-7 için zorunlu olan şey LACP değil, A ve B medya path’lerinin gerçekten bağımsız olmasıdır. Sender aynı RTP flow’u Network A ve Network B üzerinden gönderir; receiver iki kopyayı aynı anda alır ve packet-level merge yapar.
LACP yine kullanılabilir, ama doğru yerde: örneğin Network A fabric içinde uplink kapasitesi veya link availability için, ya da Network B fabric içinde benzer amaçla. Fakat A ve B path’lerini tek LAG bundle gibi düşünmek yanlış olur. ST 2022-7 A/B ayrımı, aynı logical link içindeki iki fiziksel port değil; iki ayrı fault domain demektir.
Bu yüzden pratik kural şudur:
ST 2022-7 için LACP şart değildir. LACP fabric içinde opsiyonel kapasite aracıdır; ST 2022-7 medya yedekliliğinin ana mekanizmasıdır.
STP ailesi kötü değildir. Yanlış yerde yanlış beklentiyle kullanıldığında problemdir.
Bir management VLAN’ında, düşük kritikli kontrol ağında veya küçük bir access topolojisinde RSTP/MSTP kullanılabilir. Ama ST 2110 media fabric tarafında “yayın kesilmesin” hedefini STP convergence davranışına bırakmak doğru değildir.
Çünkü ST 2110 medya trafiği:
- Gerçek zamanlıdır
- Yüksek bant genişliği kullanır
- Multicast ağırlıklıdır
- PTP zamanlamasına duyarlıdır
- Packet loss ve jitter’a karşı hassastır
Bu nedenle medya sürekliliği için STP değil, tasarlanmış A/B fabric + ST 2022-7 gerekir.
2. STP, RSTP ve MSTP neyi çözer?
STP ailesi Ethernet dünyasında Layer 2 loop oluşmasını engeller. Eğer switch’ler arasında fiziksel döngü varsa, broadcast storm ve MAC table instability oluşabilir. STP bu döngüyü kırmak için bazı portları blocking duruma alır.
RSTP bunu daha hızlı yapar. MSTP ise farklı VLAN grupları için farklı spanning tree instance’ları yönetebilir.
Fakat üçü de aynı problem ailesine aittir:
Switch topolojisinde loop olmasın.
Hiçbiri şu soruyu cevaplamaz:
Bir RTP medya paketi A path üzerinde kaybolursa receiver yayını nasıl kesmeden sürdürecek?
Bu yüzden STP/RSTP/MSTP ile ST 2022-7 arasındaki fark katman farkıdır.
Bu ayrımı net kurmadan ST 2110 network tasarımı yapılırsa, yanlış güvenlik hissi oluşur.
3. ST 2110 medya fabric için pratik öneri nedir?
Büyük ve kritik ST 2110 sistemlerinde pratik öneri genellikle şudur:
- Media fabric için iki ayrı network tasarla: Network A ve Network B
- A ve B arasında Layer 2 loop oluşturma
- A ve B’yi fiziksel fault domain olarak ayır
- Multicast dağıtımı için kontrollü IGMP/PIM-SSM/SDN yaklaşımı kullan
- PTP’yi her iki path kaybında da korunacak şekilde tasarla
- Receiver tarafında ST 2022-7 merge kullan
Bu yaklaşımda STP ana koruma mekanizması değildir. Hatta A ve B fabric doğru ayrılmışsa, medya path’leri arasında STP’nin çözmesi gereken bir loop zaten olmamalıdır.
Kısaca:
ST 2110 medya ağında STP ailesi loop prevention için vardır; yayın sürekliliği için ST 2022-7 vardır.
4. Problem: IP dünyasında kablo koparsa ne olur?
SDI dünyasında yedeklilik çoğu zaman fiziksel yedek hatlarla düşünülürdü. Bir primary SDI sinyal, bir de backup SDI sinyal olabilir. IP dünyasında ise medya paketler halinde taşınır. Bu bize daha ince bir koruma imkânı verir:
Aynı medya paketlerini iki ayrı network üzerinden gönder, receiver tarafında en sağlam paketi kullan.
Bu yaklaşımda sender aynı RTP essence’ı iki path’e gönderir:
- Network A: primary path
- Network B: secondary path
Receiver iki akışı da dinler. Eğer A tarafında paket kaybolursa, aynı paketin B tarafındaki kopyası kullanılabilir.
Bu yüzden ST 2022-7, “path failover”dan daha hassas bir şeydir. İdeal durumda receiver bir path’in tamamen düşmesini beklemez; paket seviyesinde seçim yapar.
5. ST 2022-7 nasıl çalışır?
ST 2022-7’nin temel mantığı şudur:
- Sender aynı RTP stream’i iki ayrı network interface veya path üzerinden gönderir
- Flow A ve Flow B aynı medya essence’ını taşır
- Receiver iki akışı aynı anda alır
- RTP sequence number ve timestamp bilgilerine bakarak paketleri hizalar
- Bir path’te paket kaybolursa veya geç kalırsa diğer path’teki paket kullanılır
- Çıkışta tek, temiz bir medya akışı üretilir
Burada kritik nokta şudur: ST 2022-7 çalışması için iki path’in aynı paketi taşıması gerekir. Receiver “benzer bir yayın” değil, aynı RTP akışının iki kopyasını bekler.
6. ST 2022-7 ne değildir?
ST 2022-7 bazı network kavramlarıyla sık karıştırılır.
| Kavram | Ne yapar? | ST 2022-7 ile ilişkisi |
|---|---|---|
| STP / RSTP | Layer 2 loop önler, bazı portları bloklar | Medya packet merge yapmaz |
| LACP / LAG | Birden fazla linki tek logical bağlantı gibi kullanır | Link availability/load sharing sağlar; receiver tarafında RTP packet merge yapmaz |
| ECMP | IP routing’de yük paylaşımı yapabilir | Aynı flow’un iki kopyasını receiver’da birleştirmez |
| PTP | Ortak zaman referansı sağlar | ST 2022-7 merge davranışının doğru çalışmasına yardım eder ama merge yapmaz |
| NMOS | Cihaz keşfi ve bağlantı yönetimi sağlar | Flow’ları kurabilir, ancak paket koruması yapmaz |
| Multicast | RTP flow’ları dağıtır | ST 2022-7’nin taşıdığı akış modelidir, koruma mekanizması değildir |
En kısa ayrım:
STP ağı korur. ST 2022-7 medyayı korur.
NMOS tarafında ise ayrım şudur: IS-04 cihaz ve flow keşfini, IS-05 bağlantı yönetimini sağlar. Yani orchestration sistemi A ve B flow’larını doğru sender/receiver arasında kurabilir; fakat A path’te kaybolan RTP paketinin B path’teki kopyasıyla tamamlanması NMOS’un değil receiver tarafındaki ST 2022-7 merge engine’in işidir. NMOS detayları için ayrı AMWA NMOS yazısına bakmak daha doğru olur.
7. STP ile ST 2022-7 arasında bağ var mı?
Bağ vardır, ama “birbirinin yerine geçme” şeklinde değildir.
STP ailesi network topolojisinin loop’a düşmesini engeller. ST 2022-7 ise medya paketlerinin iki bağımsız path üzerinden korunmasını sağlar.
Yani ilişki şudur:
- STP/RSTP/MSTP varsa, bu yalnızca Layer 2 topolojinin loop kontrolüdür
- ST 2022-7 varsa, bu RTP medya paketlerinin receiver tarafındaki korunmasıdır
- STP’nin convergence davranışı ST 2022-7 merge davranışının alternatifi değildir
- A/B fabric doğru ayrılmışsa, STP’nin A ile B arasında path seçmesi beklenmez
Bu yüzden “STP var, 2022-7’ye gerek yok” cümlesi yanlıştır. STP network loop problemini çözer; ST 2022-7 ise medya flow continuity problemini çözer.
8. STP, RSTP, MSTP ve ST 2022-7 karşılaştırması
STP ile ST 2022-7 birbirinin alternatifi değildir.
STP şu soruya cevap verir:
Layer 2 network’te loop oluşursa switch topolojisi nasıl korunacak?
ST 2022-7 şu soruya cevap verir:
Medya paketlerinden biri bir path’te kaybolursa receiver yayını nasıl kesmeden sürdürecek?
Bu iki soru farklıdır.
| Tasarım konusu | STP / RSTP | ST 2022-7 |
|---|---|---|
| Katman | Layer 2 control plane | RTP media plane |
| Amaç | Loop önleme | Medya sürekliliği |
| Çalıştığı yer | Switch topolojisi | Receiver merge engine |
| Failover davranışı | Port/topoloji convergence | Paket seviyesinde seçim |
| Broadcast medya için rol | Yardımcı / sınırlı | Ana redundancy mekanizması |
| A/B network yaklaşımı | Tek looplu topoloji tasarlamamalı | İki bağımsız fabric ister |
Modern ST 2110 tesislerinde çoğu tasarım, medya fabric için STP’ye dayanmaktan kaçınır. Bunun yerine açıkça tanımlanmış leaf-spine, L3 multicast, PIM-SSM/IGMP, QoS, PTP-aware switching ve ST 2022-7 A/B separation kullanılır.
9. Kısa not: PTP’nin ST 2022-7 ile ilişkisi
Bu yazının odağı PTP değil; PTP ve SMPTE ST 2059 konusunu ayrı makalede detaylı ele aldık. Burada sadece ST 2022-7 tasarımını etkileyen kısmı netleştirelim:
PTP zaman referansını sağlar; ST 2022-7 aynı RTP medya paketinin A/B path üzerinden korunmasını sağlar.
Yani PTP, ST 2022-7’nin yerine geçmez. ST 2022-7 de PTP’nin yerine geçmez. Fakat A/B medya path’leri yedeklenirken zaman referansı tek noktadan kırılmamalıdır. A path çalışırken zaman kilidi var, B path’e geçince zaman davranışı bozuluyorsa, 2022-7 çizimi doğru görünse bile gerçek sistem güvenilir değildir.
Detaylı PTP, ST 2059, domain 127, BMCA ve grandmaster mimarisi için ayrı PTP ve SMPTE ST 2059 yazısına bakmak daha doğru olur; burada konuyu sadece redundancy tasarımı açısından sınırlı tutuyoruz.
10. Gerçek hayatta nerede bozulur?
ST 2022-7 kağıt üzerinde basit görünür. Gerçek hayatta ise küçük tasarım hataları koruma mekanizmasını boşa çıkarabilir.
| Problem | Muhtemel neden | Çözüm |
|---|---|---|
| A path kopunca yayın yine kesiliyor | B path fiziksel olarak aynı güzergâhtan geçiyor | A/B fiber, switch, PSU, linecard ve bina yolu ayrılmalı |
| Receiver merge yapmıyor | Flow A ve Flow B aynı essence değil | SDP, SSRC, payload type, RTP timestamp ve format eşleşmesi kontrol edilmeli |
| Packet loss var ama korunmuyor | A/B latency farkı receiver buffer sınırını aşıyor | Path delay ölçülmeli, receiver buffer kapasitesi doğrulanmalı |
| Zaman kilidi kaybında görüntü bozuluyor | Zaman referansı medya A/B kadar yedekli değil | Zaman referansının A ve B arızasında korunup korunmadığı test edilmeli |
| Multicast join yanlış path’e gidiyor | IGMP/PIM/SDN policy hatası | A ve B multicast state ayrı ayrı izlenmeli |
| Maintenance sırasında yayın kesiliyor | “Fiziksel ayrı” sanılan path aynı switch veya patch panelden geçiyor | Gerçek kablo güzergâhı ve fault domain haritası çıkarılmalı |
11. Hangi cihaz ST 2022-7 merge yapar?
ST 2022-7 merge genellikle receiver tarafındaki media cihazında yapılır. Bu bir gateway, multiviewer input’u, decoder, production switcher input kartı, IP receiver modülü veya modern encoder/decoder platformunun RX tarafı olabilir.
Pratikte kontrol edilmesi gereken şey marka ismi değil, cihazın şu davranışı gerçekten destekleyip desteklemediğidir:
- Aynı essence için A ve B RTP flow’larını aynı anda alabiliyor mu?
- SDP/flow metadata üzerinden iki path’i aynı medya akışının kopyası olarak eşleştirebiliyor mu?
- RTP sequence number ve timestamp’e göre packet merge yapabiliyor mu?
- A/B path latency farkı için yeterli buffer sunuyor mu?
- A path, B path ve merged output’u ayrı ayrı raporlayabiliyor mu?
Bu yüzden satın alma veya tasarım aşamasında “ST 2022-7 destekli” ifadesi tek başına yeterli değildir. Cihazın hangi essence türlerinde, hangi bitrate’lerde ve hangi latency farklarında merge yaptığı test edilmelidir.
12. Monitoring: A/B path ayrı ayrı izlenmeli
ST 2022-7’nin çalıştığını anlamanın yolu sadece “ekranda görüntü var” demek değildir. Receiver kusursuz görüntü verirken A path üzerinde packet loss, B path üzerinde multicast join problemi veya merge buffer sınırına yaklaşma durumu yaşanıyor olabilir.
En azından şu metrikler ayrı ayrı izlenmelidir:
| İzlenecek metrik | Neden önemli? |
|---|---|
| A path packet loss / sequence gap | Primary path’in sağlığını gösterir |
| B path packet loss / sequence gap | Secondary path’in gerçekten hazır olup olmadığını gösterir |
| A/B latency difference | Receiver merge buffer sınırına yaklaşılıyor mu gösterir |
| Active packet source / merge decision | Receiver’ın hangi path’ten paket kullandığını anlamayı sağlar |
| Multicast join state | A ve B flow’larının doğru network’ten alındığını doğrular |
| Receiver buffer / underrun event | Merge’in kağıt üzerinde değil pratikte sağlıklı çalıştığını gösterir |
Bu konu başlı başına geniştir; detaylı monitoring tarafı için ST 2110 monitoring yazısına bağlanmak daha doğru olur.
13. Tasarım checklist’i
ST 2022-7 tasarımı için pratik checklist:
- Network A ve Network B fiziksel olarak ayrı mı?
- A ve B farklı switch, PSU, linecard ve mümkünse farklı fiber güzergâhı kullanıyor mu?
- Sender gerçekten iki eşdeğer RTP flow üretiyor mu?
- Flow A ve Flow B aynı essence, format, RTP timestamp ve sequence ilişkisine sahip mi?
- Receiver ST 2022-7 merge destekliyor mu?
- A/B path latency farkı receiver buffer sınırı içinde mi?
- Zaman referansı A veya B path kaybında korunuyor mu?
- PTP/ST 2059 ayrıntıları ayrı zaman senkronizasyonu checklist’i ile doğrulandı mı?
- Multicast join state A ve B network’te ayrı ayrı doğrulandı mı?
- Gerçek fiber/switch kesme testi yapıldı mı?
- Monitoring sistemi A path, B path ve merged output’u ayrı ayrı gösteriyor mu?
Bu checklist’te en önemli madde sonlara doğru gelir:
ST 2022-7 tasarımı yalnız çizimle doğrulanmaz; fiziksel arıza testiyle doğrulanır.
14. ST 2022-7 bant genişliğini nasıl etkiler?
ST 2022-7 bant genişliği tasarrufu sağlamaz. Tam tersine, aynı medya akışı iki ayrı network üzerinden taşınır.
Örnek:
| Flow | Tek path | ST 2022-7 toplamı |
|---|---|---|
| 1x 1080i50 ST 2110-20 video | ~1.6 Gbps | ~3.2 Gbps |
| Video + audio + ANC güvenli bütçe | ~1.8 Gbps | ~3.6 Gbps |
| 1x UHD/2160p50 ST 2110-20 video | ~12 Gbps | ~24 Gbps |
| 10 program | ~18 Gbps | ~36 Gbps |
Fakat burada dikkat edilmesi gereken nokta şudur: A ve B network ayrı kapasite havuzlarıdır. Yani “3.6 Gbps aynı linke biner” diye düşünülmez. Doğru tasarımda:
- Network A kendi başına tam yükü taşıyabilir
- Network B kendi başına tam yükü taşıyabilir
- Bir path kaybında diğer path yayını sürdürebilir
Bu nedenle ST 2022-7 maliyetli görünür, ama canlı yayın sürekliliği için en kritik güvenlik katmanlarından biridir.
15. Sonuç
ST 2022-7, ST 2110 dünyasında yedekliliğin merkezindeki standartlardan biridir.
Ama onu doğru konumlandırmak gerekir:
- STP değildir
- PTP değildir
- Routing değildir
- NMOS değildir
- LAG değildir
- “Tek network içinde yedeklilik” değildir
ST 2022-7, iki bağımsız network path üzerinden gelen aynı RTP medya akışını receiver tarafında birleştiren koruma mekanizmasıdır.
En kısa özet:
STP switch loop’larını engeller. PTP zamanı hizalar. NMOS bağlantıyı yönetir. ST 2022-7 ise medya paketlerini korur.
ST 2110 sistemlerinde gerçek redundancy istiyorsak, A/B network’ü fiziksel olarak ayırmalı, zaman referansının kırılmadığını doğrulamalı, multicast state’i izlemeli ve ST 2022-7’yi gerçek arıza testleriyle doğrulamalıyız.