Anda ingin memperoleh materi Buku Sekolah Elektronik (BSE) namun tidak memiliki koneksi internet ? Hendak mendownload materi tersebut tapi koneksi amat lambat ?
Anda ingin memperoleh video-video pembelajaran terbaru tapi jauh dari perkotaan dan tidak tersedia jaringan apapun ?

Anda ingin mengikuti training online secara jarak jauh yang dilaksanakan oleh SEAMOLEC ?

Anda ingin mengikuti pembelajaran atau kuliah jarak jauh yang disampaikan oleh guru/dosen terbaik secara real time ?

Solusinya adalah dengan terhubung dengan SEA EduNet.

Dan itu semua dapat diperoleh TANPA BIAYA BULANAN/Berlangganan, cukup dengan menyiapkan perangkat-perangkat yang sederhana dan mudah di dapat dan yang paling penting tidak membutuhkan koneksi internet apapun.

Pada tulisan sebelumnya, sudah saya paparkan secara mendalam mengenai pengertian dan manfaat dari SEA EduNet. Pada tulisan ini akan saya paparkan peralatan yang dibutuhkan agar dapat terhubung dan menikmati layanan-layanan dari SEA EduNet.
Secara umum, ada 4 perangkat utama yang dibutuhkan agar dapat terhubung ke SEA EduNet, perangkat tersebut adalah:

1. Antena Parabola
2. Modem Satelit DVB-S Digi.Box
3. Pesawat Televisi
4. PC Server
5. Antena Parabola

Parabola yang digunakan untuk sistem ini menggunakan antena parabola standar yang sering digunakan di perumahan. Berukuran 6 feet minimal, solid dan dilengkapi dengan LNB dan kabel coaxial.

Setelah memiliki antena parabola, pastikan antena tersebut telah terpointing ke Satelit Telkom 1 dan bisa menerima siaran TV Edukasi maupun Trans TV. Apabila sudah berhasil menerima siaran tersebut, maka koneksi ke layanan SEA EduNet akan jauh lebih mudah.

Modem Satelit

Modem satelit yang digunakan untuk terhubung dengan SEA EduNet adalah DVB-S merk Digi.Box. Merk ini sudah didesain khusus agar berfungsi dengan frekwensi dan symbol rate khusus untuk SEA EduNet.

Modem ini juga sudah melalui pengecekan kualitas (Quality Control) dari tim teknis SEAMOLEC termasuk pengecekan penerimaan data. Modem ini dapat diperoleh langsung di SEAMOLEC atau di Pendamping SEAMOLEC di masing-masing propinsi. Daftar pendamping bisa dilihat pada akhir postingan ini.

Harga resmi perangkat adalah US$ 275 (Dua Ratus Tujuh Puluh Lima Dollar Amerika) yang kalau di kurs menggunakan Rate US$ 1 = Rp. 10.000 sebesar Rp. 2,75 Juta (Dua Juta Tujuh Ratus Lima Puluh Ribu Rupiah). Harga ini sudah termasuk PPn 10% dan belum termasuk biaya pengiriman ke lokasi.
PC Server

Satu hal yang membedakan sistem ini dibandingkan sistem TV Satelit biasa adalah kemampuan untuk menerima data. Oleh sebab itu, dibutuhkan server yang berfungsi sebagai File Server dan Web Server untuk menampung data yang dikirimkan oleh SEAMOLEC.

Untuk sistem ini, tidak dibutuhkan komputer server yang Middle End ataupun yang High End. Komputer personal (PC) yang standar juga sudah mencukupi, asalkan memiliki spesifikasi minimal:

1. Processor minimal setara dengan Intel Pentium 4
2. Memori minimal 512 Kb
3. Hard Disk Drive minimal 250 Gb (lebih besar lebih baik, karena akan menjadi File Server)
4. Ethernet card minimal 10/100 (minimal 2 unit, kalau bisa 3 unit)

PC Server ini tidak perlu diinstall apapun, karena sistem operasi dan aplikasi akan disiapkan oleh tim pendamping SEAMOLEC. OS yang digunakan adalah Linux.

Tim Pendamping SEAMOLEC

Salah satu perbedaan sistem ini dibanding sistem lain adalah prosedur instalasi. Perangkat SEA EduNet memiliki kekhasan tersendiri. Pengaturan Modem Satelit yang berbeda dibanding modem lainnya, serta keharusan penyediaan PC Server yang akan digunakan menerima data membutuhkan tenaga-tenaga khusus yang akan menangani hal tersebut.

Dengan pertimbangan ini, dan juga untuk memberikan kemudahan terhadap pelayanan di seluruh Indonesia, maka dibentuklah Tim Pendamping SEAMOLEC di seluruh propinsi, dan direncanakan akan dibentuk hingga ke tingkat Kabupaten/Kota.

Sekolah maupun institusi lainnya yang berminat dengan layanan SEAMOLEC dapat menghubungi tim ini secara langsung. Dan karena domisili mereka berada di propinsi maupun kabupaten/kota, diharapkan akan mempermudah penanganan permasalahan yang terjadi di lapangan.

With the evolution of Smartphone and exponentially growing market for high speed multimedia services the network needs to be smarter for delivering an exhilarating user-experience. .The transformation of mobile devices industry led by advent of successful smartphones such as Blackberry, Apple iPhone the users have become more data hungry and demanding more interactive services loading the mobile network operator’s network.Multicast and Broadcast services (MBS) is the solution that will not only cater this need efficiently but also attract a large subscriber base. MBS offers real time streaming services, audio-video on demand, multiplayer online gaming, localized services, news advertisements, stocks bringing the most anticipated services at your finger tips.

MBS in 3rd Generation and 4th Generation Wireless systems requires efficient network resource utilization in access and core networks along with scalable and reliable service platforms. Also, it should incorporate the mobility aspects to continuously deliver multimedia information over an efficient air interface.

The major MBS technologies used in various 3G/4G deployment models are Media FLO by Qualcomm, DVB-H (Digital Video Broadcasting-Handheld) by DVB, MBBS by 3GPP and BCMCS by3GPP2. These technologies have garnered much attention for the revenues they can bring to terminal suppliers, network equipment suppliers, mobile operators, broadcast operators, service providers and even governments.

The main analysis considering the different old as well as new evolving use cases with the MBS technologies supporting these different services can be mapped as follows:

Considering the above use-cases we can draw insights:

1. Selection: The selection of particular MBS technology by the mobile network operator should be based on following criteria

2. Cost: For heavy duty broadcast applications the resources required would be greater in a 3G network compared to a Broadcast only network such as MediaFLO or DVB-H and hence the cost.
Whereas for light applications and highly interactive applications MBMS or BCMCS would be the ideal choice saving on resources by multicasting to the subscribed group of users instead of broadcasting it to every user in the network. Also, due to availability of an uplink channel, highly interactive applications can be easily supported on the mobile terminal providing a better user experience. Also, from unicasting perspective, with Multicast usage there is a considerable resource savings in core network and radio access network where the radio bearers are lesser than number of users compared to the number of bearers which is equal to number of users in unicast transmissions

3.Reach: MediaFLO and DVB-H have a larger cell size and hence a larger footprint which again thus requires lesser base stations covering groups of subscriber services. But again due to the existing vast coverage of the 2G/3G cellular network, these base stations can be easily upgraded to MBMS/BCMCS capabilities with a comparatively greater reach though smaller individual footprint.

4. Interactivity: Broadcast only networks are limited due to the lack of backward channel and hence no interactivity. But the interactivity can be implemented by using network operator’s feedback channel.

5.Mobile Terminal: In the current scenario, for specific applications such as Live TV, broadcast only technologies like MediaFLO or DVB-H might prove to be more efficient but the downfall is the corresponding handsets should be available to receive such broadcasts so that is an additional cost to the MNO’s.

6.Business Implicaitons: The broadcast and multicast are complimentary technologies where broadcast can be used for stimulating users to subscribe to the services and multicast services are used to cater specific endusers which eventually subscribes t ospecific services which generate revenues for the operators.

7.Mobile Trend: There is a significant growing trend towards a large number of interactive applications with the advent of modile web due to the availability of smartphones with a larger form factor and advanced capabilities. So most of the NGN will be equipped with cutting edge resource efficient technologies supporting heavy duty streaming and at the same time supporting a higher level of interactivity and a richer user experience with a better continous data connectivity and seamless mobility

Thus with a strong MBS technology selection by the MNO and a lucrative business model a smart telecom value chain is possible and with higher order benefits.

Unicast
Communication point à point.
Envoi de paquets à une seule adresse IP

Multicast
Communication multipoint.
Envoi de paquets à plusieurs adresses IP qui se sont abonnés au préalable pour recevoir les paquets.

Broadcast
Communication multipoint.
Envoi de paquets à toutes les machines du réseau.

I have been frustrated in my Terminal Services environment because every time I seem go get my problems put to bed, they wake up again and meaner than ever. I have approximately 250 TS users with 50 users logged on at any given time. We are running Server 2003 R2 Enterprise and when I initially arrived on the scene we were running two TS machines on a Microsoft Virtual Server platform and a third on a standalone physical machine. They were load-balanced via Microsoft NLB Cluster services and would stop functioning sporadically. The only solution at the time was to tear down the NLB Cluster and rebuild it. Soon thereafter we left the Microsoft virtual environment in lieu of VMWare. We went that route specifically for Site Recovery Manager and the ability to get VM’s restored to our DR facility in fairly short order. So with that I had 3 very beefy servers geared up as ESX 4.0 Hosts. Placed them in my Virtual Center, and installed 2 VERY beefy TS machines (first mistake). I created two 4 core 8 GB servers with 100 GB of storage each. I set up a default Microsoft NLB (second mistake) to load balance both of my TS Servers.

Well, as some of you may have already experienced, it doesn’t quite work that easily. The symptom was that I could not reach the second server. In fact the second server had issues reaching the network consistently as well. After some research I found out that it was due to the way that the NLB handles mac-addresses and the NLB Cluster IP and the way that VMWare handle RARP flood requests. I am not going to deep dive right now but you can find out more about it here. . The short of it was that I needed to configure the NLB in Multicast Mode. So I did, and that too didn’t work. So I took it to the next level and disabled RARP transmission as outlined here, and all seemed good… for a while. V-Motion was acting up after that, mainly because VMWare did not notify the host that the virtual server moved. This ruined my plans for dynamic VM resource management for the entire vswitch. There had to be a better way

I dug down deeper and really began honing in on the ARP/MAC and Cluster IP issue. I started looking at my Cisco switch for ways to solve my problem. I found it. I needed to create static ARP and MAC entries in my switches directly connected to the VM Host. The following commands worked for me (edited of course)

Config t

arp 10.0.100.10 03bf.0a00.640a ARPA

mac-address-table static 03bf.0a00.640a vlan 1 int Fa0/1 Fa0/15 Fa0/16

wr mem

• Where 10.0.100.10 is the NLB Cluster IP address
  
• 03bf.0a00.640a is the virtual MAC address of the NLB Cluster itself
  
• vlan 1 is the vlan that the vswitch the VM is on
  
• Fa0/1 Fa0/15 Fa0/16 are the interfaces connecting to the VM Hosts
  

And I had stability at layer 2/3… but of course that was not good enough.

Shortly thereafter I started getting complaints that the performance was just too slow. I looked at the summary of the VM and I saw that the Consumed Host CPU was minimal and that the memory was also minimal. It was then that I started thinking virtually, not physically. VMWare has an evil habit of waiting until all the assigned cores are available before putting through a process. When I have a 4 core requirement, on a relatively busy VM Host, it takes a long time to get all 4 core’s free to get anything done. So I began to employ the Zerg Rush strategy for TS boxes (hey it worked in Starcraft). I created a small 2 core 4 GB ram TS template and deployed many of them. We have licenses for Server 2003 Enterprise and therefore had a 1 to 3 exchange rate of Physical to Virtual. I also kept most of them on the same VM Host since similar applications would be competing for 2 cores in a similar way, thus giving preference to none. My performance woes seemed to disappear, but as you can guess… seeming is believing.

There are some shortcomings of Server 2003 NLB that make this tool a bit inadequate. All the servers must be on the same network, the Affinity is configurable however restrictions based on connection number are not. If a member of NLB cluster goes down, the NLB will still attempt to route users to it. There is no reporting to speak of, and finally there is a 32 server limit. It is because of these reasons (and because of the goofy way NLB handles arp) that I decided to go with a 3^rd party NLB solution. I ended up choosing loadbalancer.org’s virtual appliance and couldn’t be happier. It uses a loopback adapter on each server with a high metric and the cluster IP to overcome the arp issue. I can choose various weighted approaches to load balancing. I get reporting, health checks, and can use the NLB for a myriad of load balancing scenarios. It was quick to set up and the servers are good to go; now I can party… I wish.

While I have a solid layer 2/3 foundation with a robust NLB setup bringing redundancy and availability to my environment, I am hamstrung at layer 7 itself. The Terminal Servers themselves were just not performing adequately for more than a couple days. I was receiving the following errors every couple days:

“Windows – Low on Registry Space – The system
has reached the maximum size allowed for the system part of the registry.
Additional storage requests will be ignored.”

“Windows was unable to load the profile but has
logged on with the default profile system. Default – Insufficient system
resources exist to complete the requested service.”

I would reset some lingering disconnected sessions as well as eventually reboot the system. All would be well for a while until the message came back. Additionally I noticed that the temporary Profiles in C:\Documents and Settings was eating up all my space. So I figured, “Hey! I have a SAN with plenty of space; I’ll just mount an iSCSI drive and put the Documents and Settings there.” I know, I’m brilliant right!

“Documents and Settings is a Windows system folder and is required for Windows to run properly. It cannot be moved or renamed.”

The problem then was that all the articles I read were really focused on an unattended install with a unattend.txt file. I already had machines in production, I didn’t want to have to build a new machine and create a new template to experiment with this plan. So I took the following article and read to the registry path edit .

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

When I went to the registry path I found the setting to change. I changed the ProfilesDirectory entry to reflect the new iSCSI drive I had mounted. I then deleted all the non stock GUID’s (kept All users, Administrator, Default User).

I was not worried because we have roaming profiles for our users; all the profiles on that machine were temporary. I then navigated to the c:\Documents and Settings folder and deleted all the non stock profiles. I copied over the All Users, Administrator, and Default User folder to the new location and after a reboot I was done with that. Testing showed the new users getting profile creation on the new drive.

As for the registry issue, I dug up this article which made sense. The legacy printers were dragging down my user profiles and creating relics and hogging space. I added the PrinterMasKey to the HKEY_USERS\.default\printers
registry subkey and rebooted the server. That made quick work of the registry error. I made sure I was on the latest service pack then rebooted. The step-by-step is below.

To enable this hotfix, you must create the PrinterMaskKey registry subkey. To do this, follow these steps:

• Click Start, click Run, type regedit, and then click OK.
• Locate the following registry subkey:
• HKEY_USERS\.default\printers
• Right-click the registry subkey that you located in step 2, point to New, click Key, type PrinterMaskKey, and then press ENTER.
• Exit Registry

When all was said and done, I then wanted to reclaim my space. I ran a defrag, emptied the recycle bin. I then downloaded sdelete , extracted the sdelete.exe file and saved it to the root of my C:\ . I then ran sdelete –c on the server to zero out all the space on my vhd. Finally I shut down the TS VM and migrated it to another store, since the drive is thin provisioned I was able to get my space back and move on from there. Now I hope I can rest… we will see.

dear all,
seamolec akan melakukan training on line mobile JENI mulai tgl 15 desember 2009, selama 2 bulan , utk sekolah2 rsbi,mitra 150, 500,7000, maupun individu yg berminat

pola yg di lakukan pembelajaran dgn vicon, streaming, multicast, 3 x /minggu, dan setiap pertemuan lebih kurang 4 jam…

bagi sekolah yg berminat..silahkan kontak pendamping seamolec di masing2 propinsi, atau kontak ratih , cahya@seamolec.org, haritz@seamolec.org.

training utk tahap ini, kita ingin membangun sistem an memperluas dari yg sdh kita kembangkan sebelumnya dimana hanya smkn 1 sby dan smkn 9 saja utk percobaan pertama..

setalah 2 bulan, kurang lebih 24 x pertemuan, kita adalakn lomba di setiap lokal sekolah..yg kita dorong menjadi mitra seamolec…, dan 10 produk yg terbaik di kirimke seamolec utk di seleksi 20 besar…

siswa atau masyarakat yg terpilih dari 20 besar ini , di beri kesempatan utk magan di seamolec selama 3 – 4 bulan, 3 – 5 yg trbaik akan kita kirim keasean mendampingi tim seamolec menjadi asisten instruktur utk mengajar di sekolah2 patner seamolec yg membutuhkan.. magang di semaolec di perkirakan mulai maret/april 2010
dan yg terbaik kita kirim keasean bulan juni/juli 2010 selama 2 – 4 bulan..

hal ini sdh kita lakukan 4 siswi dari smkn1 sby sdk ke kambodja dan vietnam selama 2 – 4 bulan mengerjakan program kamus 4 bahasa dan mengajari mereka game edukasi..
hasil kamus 4 bhs di handphone ini sedang kita kompilasi yg akan kita sumbangkan kepada masyarakat asean utk memudahkanberkomunikasi sesama tetangga…
hari sabtu yl 2 siswi dr smkn 1 ini mempresentasikan di depan kadinas se jatim dan mendiknas, dapat apresiasi dari audiese..karena karya mereka yg bermanfaat utk asean..
dan dapat reward masuk politek elektronika surabaya tanpa test utk thn 2010 dgn beasiswa..

kalau siswi smkn 1  surabaya bisa kenapa siswi sekolah anda tidak bisa…? mereka adalah generasi muda yg kita siapkan bersama…ayo kerja bareng utk menyiapkan mereka, memperjlankan mereka keluar dari sekolah/kotanya..utk mencari wawasan baru..
sehingga kita bisa menghasil kan generasi yg lentur, mengerti multikultur dan sbg duta bangsa di level menengah…:)..

kita mengajak juga politek, atau lembaga kursus atau siapapn yg berminat utk menjadi game developer java..juga cc jatim utk menyiapkan kelas khusu atau mt pelajaran khusu didaerah anda masing2..

bangkok 23 november

The SRM (Scalable Reliable Multicast) argues that, unlike reliable unicast protocols, different applications vary widely in their requirements for reliable multicast delivery. Hence:

One cannot make a single reliable multicast delivery scheme that simultaneously meets the functionality, scalability, and efficiency requirements of all applications.

Hence, they propose a model in which a generic skeleton is “fleshed out with application specific details.” The application provides a means to talk about how much data has been sent and received (“application data units”, unlike the connection-state oriented acknowledgments in TCP), a means for allocating bandwidth among the members of the group, and a means for individual nodes to decide how to allocate their local outgoing bandwidth. Following this model, their multicast framework only provides best-effort packet delivery, with possible duplication and reordering of packets — they believe that applications can build stronger reliable delivery and ordering properties on top of their framework, as needed. Best-effort multicast is actually implemented using IP multicast.

Unicast vs. Multicast

The authors point out two differences between reliable delivery for unicast vs. multicast that I thought were interesting:

• In any reliable delivery protocol, one party must take responsibility for detecting lost data and retransmitting it. In unicast, either the sender or receiver can play this role equally well (TCP uses the sender, other protocols like NETBLT use the receiver). In multicast, sender-side delivery state is problematic: the sender must track the set of active recipients and the current state of each recipient, which is expensive, and difficult to do as the multicast group changes. In some sense, the whole point of multicast is to relieve the sender of that responsibility. Hence, they argue that receiver-side delivery state is better for multicast: group membership isn’t relevant, and the burden of keeping per-receiver state is avoided.
• A reliable delivery protocol also needs a vocabulary to talk about how much data has been sent or received. Typical unicast protocols use a vocabulary based on communication state (typically either bytes or packets (segments)). This is not ideal for multicast, because a newly-joining recipient doesn’t share that communication state, and hence can’t interpret byte-oriented or packet-oriented messages. SRM instead argues for talking in terms of “application data units.”

wb Framework

The example multicast application in the paper is wb, a shared distributed whiteboard. This has the advantage that protocol commands (e.g. draw shape X at location Y) are mostly idempotent (if associated with a timestamp), so the underlying multicast protocol doesn’t need to enforce a total order on deliveries.

In wb, new operations are multicast to the entire group. When a receiver detects a loss (by detecting gaps in sequence numbers), it starts a “repair request” timer. The timer value is determined by the distance of the receiver from the original data source. When the timer expires, the recipient multicasts a “repair request” to the entire group, asking for the missing data. If a recipient sees another repair request for the same data before its timer expires, it suppresses its own repair request. Retransmission of missing data is handled similarly: when nodes receive repair requests for data they have seen, they start a response timer based on their distance from the repair request source. When the timer expires, they multicast the requested data to the entire group. Any other nodes that have a response timer for the requested data suppress their own timers. They also propose a bandwidth allocation scheme to divide the available bandwidth among new data operations and repair data.

Tuning the Request/Response Repair Timers

It is important that the repair request and repair response timers at different nodes be de-synchronized, to avoid redundant messages. The paper observes that certain topologies require methods for achieving de-synchronization: in a simple “chain” topology, seeding the timer with network distance is sufficient. For a “star” topology, all nodes are the same distance from the data source, so randomization must be used. A combination of these techniques must be used for a tree topology. Rather than requiring the timers be tuned for each individual network, they instead propose an adaptive algorithm that uses prior request/response behavior to tune the timers automatically.

As the youngest sibling in the radio family, HD radio is still finding its feet in the media market. We are only starting to discover the interesting new ways to implement its unique capabilities, especially multicast. Multicast basically allows HD stations to provide sub-channels with additional content for their listeners. Sometimes it will be a music format such as bluegrass, sometimes just an expanded version of normal programming.  Now it seems that CBS Radio has come up with a new take on how to leverage that quality.

According to an announcement made by CBS last Friday, four of their most popular stations will soon be offered outside of their normal markets via HD multicast channels. Included in this pilot program will be the following:

• WFAN-AM (Sportsradio 66 The Fan)/New York will broadcast sports programming on WOCL-FM HD3 (105.9)/Orlando, WLLD-FM HD3 (94.1)/Tampa and WEAT-FM HD3 (104.3)/West Palm Beach.
• Alternative KROQ-FM/Los Angeles will be carried in the San Diego area via KSCF-FM HD2 (103.7).
• KSCF-FM (Sophie @103.7) is now available to Los Angeles audiences via KAMP-FM HD2 (97.1).
• Next month, WBZ-FM, The Sports Hub, will be available on Hartford based WTIC-FM HD3 (96.5).

Now we shall see how well the original programming scales. Will it be able to be competitive in the new markets? Could be. While localism is an important facet of radio strategy as we move forward, I have a feeling this approach could also yield results. It all comes down to providing engaging content for your audience, and I believe there is room for — and need for — both tactics.

Radio Business Report (RBR-TVBR) is always good for a bit of commentary, and their traditional “observation” on this subject is a fine one:

This should be studied—for ad sales. While some may say this is just another reason HD Radio is underperforming in many markets and that they should be programming and marketing new local format ideas, in reality, this may be very sell-able in these other markets. With HD Radio multicast channels, if you can come up with a way to monetize them, do it. We’re all still in the experimental phase here, and this is a great way to test if “super stations” from other markets can be sold locally in others.

It’s great to see companies beginning to explore the possibilities offered by HD. The capabilities of multicast in particular are very exciting because it allows and encourages experimentation with niche formats and syndication opportunities like this one.

What interesting or “out of the box” uses for HD can you think of?

Image: HD Radio Logo / Fair Use: Reporting

Multicast is clearly an efficient technique for applications with one-to-many communication patterns, but the deployment of in-network multicast has been slow. Therefore, there have been a number of proposals for implementing multicast at the application level, as an overlay over the physical network. This is not as efficient as true in-network multicast (because the same message may be sent over the same link multiple times), but is much more flexible and easier to deploy.

“Scalable Application Layer Multicast” is one such proposal for application-layer multicast via an overlay network; their proposed protocol is called NICE. Their focus is on applications that require low-latency delivery of relatively low-bandwidth data streams to a large set of recipients, although they argue that their techniques are also applicable to high-volume streams with some minor changes.

Network Topology

In NICE, nodes are arranged into layers; a single node can appear in more than one layer. Every node belongs to the lowest layer, L0. The nodes in a layer are arranged (automatically) into clusters of nodes that are “near” to one another (in terms of network distance/latency). Each cluster has a leader, which is the node in the “center” of the cluster (NICE tries to make the leader the node that has the smallest maximal latency to the other nodes in the cluster). Layer L1 consists of all the cluster leaders from L0; the clustering algorithm is applied to L1 in turn, yielding another set of cluster leaders which form L2, and so forth. The height of the tree is determined by the number of nodes and a constant k: each cluster contains between k and 3k-1 nodes.

To multicast a data message, a node forwards the message to every cluster peer in every layer in which the node belongs, except that a node never forwards a message back to the message’s previous hop.

Protocol

To join the multicast group, a node begins by contacting a designated node called the Rendezvous Point (RP). The RP is typically the root of the NICE tree. The joining node walks down the tree from the root, choosing the child node that is closest to it (lowest latency).

Cluster leaders periodically check whether the cluster size constraint (k <= size <= 3k-1) has been violated; if so, they initiate a cluster merge or split, as appropriate. Splitting a cluster into two clusters is done by trying to minimize the maximum of the radii of the resulting clusters.

All the nodes in a cluster periodically sends heartbeats to each of its cluster peers. This is used to detect node failures, and to update pair-wise latency information for nodes. If a cluster leader fails or deliberately leaves the NICE group, a new leader is chosen by the same heuristic (minimize maximum latency from new center to any cluster peer). A new leader may also be chosen if the pair-wise latencies in the cluster drift sufficiently far to make selecting a new leader justified. Also, each member of every layer i periodically probes its latency to the nodes in layer i+1 — if the node is closer to another i+1 layer node, it moves to the corresponding cluster in layer i.

Discussion

I didn’t see that the authors provided any grounds for choosing an appropriate k value (essentially the tree fan-in), which seems like it would be an important parameter.

In just the few months since it was released this summer, Apple’s video streaming to the iPhone has become a part of many business plans. Two announcements were made on that front today:

Multicast announced full support for transcoding, managing, delivering and displaying content on the iPhone, both live and on-demand. However, the company’s customers tend to be corporate — from internal teams like investor relations, human resources and sales that put on live events — while the iPhone is still mainly a consumer device. Nevertheless, it’s useful to have your main online video platform provide extensions to all sorts of devices.

Meanwhile, Stickam, the live video community site, today launched an iPhone SDK of its own. The idea is that other companies, for instance partner 211me, which works with celebrities, can build their own iPhone apps that include Stickam live streaming and chat. 211me’s first Stickam-powered app will be for Twilight star Peter Facinelli. Competitor Kyte already simplifies this process even further, enabling stars and their entourages to make video apps for various mobile platforms.

In other recent iPhone video news, Brightcove pre-announced an iPhone SDK and Livestream added iPhone streaming last week at our NewTeeVee Live conference.

hari jumat tgl 6 november kemarin kita sepakati antara ITB, SESMOLEC dan 7 pt provider d3 tkj, utk memberi kesempatan putra-putri daerah kabupaten di jabar , utkmengikuti alih jenjang ke d4 di ITB bulan febuari 2010.;di rencanakan ada 2 jurusan yaitu jurusan media digital dan teknik komputer dan jaringan, dengan kapasitas maksimum100 mhs.
disepakati tempat testing di 6 lokasi dan waktu yaitu :
1. 10 desember di itb, poltek sukabumi, dan stimik subang
2. 9 november di politek negeri jakarta
3. 8 desember di politek tedc cimahi
4. 14 desember stimik cirebon, tasikmalaya

5.utk diy dan jateng kita kumpulkan di poliseni jogja, antara 10 – 15 desember , sedang di cari waktu yg tetap, kontak personnya bu ainun dan p zubeir, bagi yg berminat daftar saja ke poliseni diy- jln kaliurang.

bagi lulusan d3tkj angkatan 2006 yg berminat meneruskan ke d4 dan di utus dan di biayai oleh daerah/sekolah/institusinya bisa memanfaatkan peluang ini..
di rencanakan yg lulus testing di infokan pantara tgl 16 – 20 desember 2009, dan pengumuman tsb kita kirimkan ke bupatei/kadinas dan instansi yg relevan utk dapat membiayai putra-putri daerahnya yg lolos test ITb tersebut.
utk bach 2 SEAMOLEC memberikan beasiswapendidikan sebesar 50 % utk 30 peserta, sisanya di bibiayai oleh instansi pengirim..

pola pendidikan spt batch 1 yg sudah jalan saat ini, 2 bulan di itb – 6 bulan di institusi pengirim – 4 bulan di itb;
selama di institusi pengirim, perkuliah memanfaatkan internet, satelit dan media yg relevan utk pendidikan jarak jauh…
setiap mhs di harapkan dapat menginstall sistem multicast – seaedunet di masing2 institusinya, utk pengayaan materi kuliah.
selain itu di harapkan dalam jangka panjang sekolah yg mtersambung dgnsistem seamolec dapat menjadi sumber belajar buat siswa, guru-mgmp-kkg,dan masyarakat – pnfi dgn memanfaatkan materi yg di kirim melalui satelit dari sistem seamolec.

ini info awal utk mereka yg berminat utk meneruskan pendidikan ke d4…tolong di sebarluaskan ke eman2 anda ya…kritik , usul dan saran tolong di tulis di bawah ini..

utk indonesia timur, kita sedang menyiapkan program sejenis dgn UT jatim, PENS, dan UM..

seleksi di UM akan kita lakukan bln desember – januari.2010..setiap batch yg mengembangkan model2 pendidikan jarak jauh yg di kembangkan oleh seamolec, kita coba berikan beasiswa 30 peserta setiap batch dgn subsidibiaya pendidikan 50 % utk PENS dan UM, serta 100 % utk UT.
utk pens – kontak personya p edy, tilpon pens saja, biaya pendidikan 12 jt sampai selesai slama 3 semester, dgn pola model pjj pens
utk UM p slamet kajur TIK, tilp kantor  umdgn pola 3 semester dan di perkirakan biaya total 10,5 jt sd selesai
utk UT ibu kisyiani,tilp. ut, lama pendidikan 3 semester dgn biaya pendidikan sekitar 7 jt sd selesai
utk masing2 institusi, di rencanakan kapasitas maksimum 100 peserta/batch
mt kulih wajib yg akan di berikan oleh tim seamolec bersama tim pt al : multicast dgn praktek instalasi dimasing2 sekolah pengirim, mjeni dgn membuat game dgn mengajarkan pada murid2 di sekolah pegirim serta moodle pembelajaran utk sharing dgn kwn2 lainnya.

selamat berusaha utk kemajuan kita semuanya…
kontak person di seamolec sdr dani, hafid, cahya dan faisal, info lain bisa di lihat di www.seamolec.org

“Internet Indirection Infrastructure” (i3) proposes a communication abstraction in which applications send packets to identifiers, rather than network addresses. Receivers register triggers that express their interest in packets sent to a particular identifier— the i3 infrastructure takes care of the routing. i3 is designed to be a general-purpose substrate, which can be used to build communication patterns including multicast, anycast, load balanced server selection, and host mobility.

Basic Model

To register interest in data, a receiver registers a trigger for the pair (id, addr) — this specifies that packets sent to identifier id should be routed to IP address addr. Multiple receivers for a single ID can be registered, in which case the packet is delivered to all matching trigger addresses. i3 generalizes this basic model in a few ways:

• Inexact matching. Identifiers are divided into two pieces: an “exact match prefix” of k bits, and a suffix that is used to do longest-prefix matches. That is, a trigger matches an identifier if the first k bits match exactly, and if no other trigger has a longer prefix match against the rest of the identifier.
• Identifier stacks. Rather than sending a packet to a single identifier, packets can instead be sent to a stack of identifiers. Similarly, triggers are generalized to mean “When a match for id is found, push a, b, … onto the stack.” i3 looks for a trigger that matches the first element of the stack; if no such trigger is found, the first element is popped from the stack. This continues until the stack is empty or a matching trigger is found; if a match is found, the trigger’s identifier stack is pushed onto the packet’s stack, and routing continues anew. i3 assumes that this process will eventually result in matching a trigger against an identifier holding an IP address. When that occurs, the packet’s data and the rest of the identifier stack is sent to the address.
• Private triggers. This is not an i3-level concept, but a design pattern that i3-using applications often follow. A “public” trigger is a trigger on a well-known identifier, and is used to initiate a session with a server; “private” triggers are used to communicate between pairs of end hosts. A pair of private trigger identifiers might be exchanged via a service’s public trigger identifier, and then subsequent communication will proceed via the private triggers.

Implementation

i3 is implemented on top of a distributed hash table (DHT); the authors use the Chord DHT in the paper. The DHT provides a service to find the node associated with a key; for the purposes of i3, this allows a packet sender to find the node that holds the triggers for the first identifier in the packet’s identifier stack (the DHT lookup is only done on the “exact match prefix” of the identifier). The target i3 node then finds the matching trigger, if any, by doing a longest-prefix match against trigger identifiers. Once a match is found, the packet is routed to the receiver address or addresses via IP, or another DHT lookup occurs (if the trigger contains an ID stack, not an address).

Senders cache the IP address of the i3 node responsible for each identifier. Hence, in the common case, routing an i3 packet requires two physical network traversals: one to get from the sender to the i3 node, and then another from the i3 node to the receiver.

Example Usage

i3 provides direct support for simple multicast; anycast is supported using inexact identifier matching, and appropriate choices for the inexact suffix of the identifier. Host mobility can be supported by simply updating a receiver’s trigger. Multicast trees can be implemented by constructing routing trees in i3, using the identifier stack feature (triggers that “invoke” triggers can essentially be used to construct an arbitrary graph, and to do recursive queries over graphs).

Performance

In the paper’s experiments, the latency to route the first packet to an identifier is about 4 times that of raw IP routing, because a Chord lookup must be done (after applying some standard Chord tricks to try to pick the “closest” Chord node among the alternatives as the ring is traversed). To reduce the latency required to route subsequent packets, i3 employs two techniques:

• Caching the address of the i3 node that owns a given identifier, as discussed above.
• A receiver generates k random trigger identifiers, and then chooses the identifier that it can reach via IP with the lowest latency.

By having each receiver generate 15-30 random triggers with this technique, the authors are able to reduce the i3 routing latency for subsequent packets send to an identifier to between 2 and 1.5 times more than raw IP.

Discussion

Overall, I liked this paper: it is an elegant idea that is explained well. A cynical view of this paper is that it isn’t all that innovative or “deep”: it is just a thin logic layer on top of a DHT. i3 is basically a generalization of the name-to-value lookup service provided by the DHT.

Both performance and security are serious issues with this design, and the paper didn’t really convince me that their approach addresses these problems.

I would have liked to see a performance comparison between IP-level multicast and anycast with implementations built on i3.

It would be interesting to compare i3 with group communication systems (GCS) that provide totally-ordered broadcast messages. What features could you add to i3 to make it easier to write reliable distributed systems?

dear all,
hari ini mulai kuliah 43 mhs d4 pjj seamolec dgn ITB, mereka akan menylskn progrm slm12 bln, dgn perincian 3 bln di bandung, 6 bln di daerah dan 3 bulan di bandung lagi, selama di daerah mrk mempraktekkan sistem seaedunet – multicast dlm memperkaya konten dan mjeni di sklh masing2… batch ke 2 dakan kita buka bulan des. 2009, bagi yg berminat..ndaftar di masing2 provider d3 saja…utk kita seleksi…pada bulan desember dan januari 2010 .dan infokan juga ke kami siapa saja yg berminat dan dari mana saja ya.; kuliah batch 2 mulai bulan febuari/maret 2010.. info tmbahan bisa di lihat di www. seamolec.org/alihjenjang… bila ada saran.dan masukan ….kita juga tunggu..di bawah ini ya.. beasiswa subsidi pendidikan 50 % dan 100 % utk jumlah terbatas di sediakan oleh seamolec maupun industri, dll sumber.
terimakasih….atas saran dan usulnya..
.

dear all,

saya baru mendapat masukan dari kalteng utk memikirikan ttg training on line, utk tkj dll.

seamolec saat ini mempunyai cadangan sd 200 lebih modul yg berbentuk web base cource atau kita sebut moodle, dan sedang kita cek pada bbrp titik utk transfer file nya memanfaatkan seaedunet – multicast.

mudah2an nvember program training utk guru on line baik indonesia atau asean dapat kita luncurkan , asal ada sambungan internet atau tersambung dgn multicast nya seamolec.

tapi ini masih belum sempurna, kita harus sempurnakan bersama, dan sasaran kita adalah guru 2 yg ingin meng up date wawasannya..dan pengetahuannya..

selain itu testing moodle bisa di lihat

Berikut ini link SEAMOLEC ELEARNING (MOODLE) yang dijadikan sebagai prototipe

DIKLAT ONLINE : http://elearning.seamolec.org/course/category.php?id=40

Jika ingin masuk ke dalam course, dapat menggunakan ID sementara :

USERNAME : prototipe

PASSWORD : ujicoba

Konten course DIKLAT diantaranya :

1.       Pembenihan Ikan Kerapu 2.       Pengenalan Sistem PJJ 3.       Pembekalan Belajar Mandiri 4.       Matematika Dasar 5 dll, testing sesuai dgn keinginan anda..dan sarankan dibawah ini perbaikan dan judul nya yg anda butuhkan..

Demikian informasi yang dapat kami sampaikan. Please advice.

masukan serta bidang apa yg kalian butuhkan ..tolonng tuliskan di bawah ini ..ya..
terimakasih

The MPLS VPN network needs to be carefully designed and the service provider core must be configured for native multicast service: PIM-SM, Source specific multicast (PIM-SSM), or Bidirectional PIM (PIM-BIDIR) are required at core. PIM-DM is not supported as core protocol for MVPN services, but all multicast protocols are supported within multicast VRF for customers (CE).

Note: Dense mode PIM (PIM-DM) is not supported as core protocol in MVPN configurations.

• An MDT default configuration is mandatory for MVPN to work (Multicast Distribution Tree).
• Configuring data MDT is optional.
• The IP address of the default MDT determines which multicast domain VRF belongs to (to share multicast packets with other VRFs)
• Multicast needs to be enabled on MBGP peers loopbacks (between PEs)

Reference:

http://www.cisco.com/en/US/tech/tk436/tk428/
technologies_configuration_example09186a0080242aa8.shtml

Example:

Configuration

R5:

ip vrf A 
rd 10.10.5.5:1
route-target export 666:1
route-target import 666:1
 mdt default 232.10.10.10
!
ip multicast-routing
ip multicast-routing vrf A
!
interface Loopback0
ip address 10.10.5.5 255.255.255.255
 ip pim sparse-dense-mode
!
interface Ethernet0/0
ip address 10.10.35.5 255.255.255.0
ip pim sparse-mode
!
interface Ethernet0/3
 ip vrf forwarding A
ip address 10.10.57.5 255.255.255.0
 ip pim dense-mode
!
router ospf 1
mpls ldp autoconfig area 0
log-adjacency-changes
network 10.10.0.0 0.0.255.255 area 0
!
router bgp 666
bgp log-neighbor-changes
neighbor 10.10.6.6 remote-as 666
neighbor 10.10.6.6 update-source Loopback0
!
address-family ipv4
  neighbor 10.10.6.6 activate
  no auto-summary
  no synchronization
exit-address-family
!
address-family vpnv4
  neighbor 10.10.6.6 activate
  neighbor 10.10.6.6 send-community extended
exit-address-family
!
address-family ipv4 vrf A
  redistribute connected
  no synchronization
exit-address-family
!

R6:

ip vrf A 
rd 10.10.6.6:1
route-target export 666:1
route-target import 666:1
 mdt default 232.10.10.10
!
ip multicast-routing
ip multicast-routing vrf A
!
interface Loopback0
ip address 10.10.6.6 255.255.255.255
 ip pim sparse-dense-mode
!
interface Ethernet0/0
ip address 10.10.46.6 255.255.255.0
ip pim sparse-mode
!
interface Ethernet0/3
 ip vrf forwarding A
ip address 10.10.68.6 255.255.255.0
 ip pim dense-mode
!
router ospf 1
mpls ldp autoconfig area 0
log-adjacency-changes
network 10.10.0.0 0.0.255.255 area 0
!
router bgp 666
bgp log-neighbor-changes
neighbor 10.10.5.5 remote-as 666
neighbor 10.10.5.5 update-source Loopback0
!
address-family ipv4
  neighbor 10.10.5.5 activate
  no auto-summary
  no synchronization
exit-address-family
!       
address-family vpnv4
  neighbor 10.10.5.5 activate
  neighbor 10.10.5.5 send-community extended
exit-address-family
!
address-family ipv4 vrf A
  redistribute connected
  no synchronization
exit-address-family
!

Verification

R5#deb ip mpacket

IP(1): s=10.10.57.7 (Ethernet0/3) d=224.69.69.69 (Tunnel0) id=820, ttl=254, prot=1, len=100(100), mforward

IP(0): s=10.10.5.5 (Loopback0) d=232.10.10.10 (Ethernet0/0) id=563, ttl=255, prot=47, len=124(124), mforward

R5#sh ip mroute
IP Multicast Routing Table
Flags: D – Dense, S – Sparse, C – Connected,
       L – Local, T – SPT-bit set, Z – Multicast Tunnel,
       z – MDT-data group sender…

(10.10.5.5, 232.10.10.10), 00:28:22/00:03:23, flags: sT
  Incoming interface: Loopback0, RPF nbr 0.0.0.0
  Outgoing interface list:
    Ethernet0/0, Forward/Sparse, 00:01:04/00:02:26

(10.10.6.6, 232.10.10.10), 01:25:37/00:02:53, flags: sTIZ
  Incoming interface: Ethernet0/0, RPF nbr 10.10.35.3
  Outgoing interface list:
    MVRF A, Forward/Sparse-Dense, 01:22:53/00:00:00

(*, 224.0.1.40), 12:23:16/00:02:34, RP 0.0.0.0, flags: DCL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Ethernet0/0, Forward/Sparse, 12:23:16/00:00:00

R5#sh ip pim mdt
  * implies group is the MDT default group
  MDT Group       Interface   Source           VRF
* 232.10.10.10    Tunnel0     Loopback0        A

R5#sh ip pim mdt bgp
Peer (Route Distinguisher + IPv4)    Next Hop
  MDT group 232.10.10.10
   2:2570:101056513:10.10.6.6        10.10.6.6

In the previous port, we reviewed MSDP, Multicast Source Discovery Protocol (MSDP) is the key protocol that makes Anycast RP possible. The Anycast RP uses MSDP for redundancy and failover between RPs in Protocol Independent Multicast sparse mode (PIM-SM) networks. Rendezvous Points can share one IP address (same-address allocated to their loopback) and load-balance multicast traffic within the network. Data is routed to the nearest and the best destination as viewed by the routing topology. RP can be configured statically by “ip pim rp-address” command or dynamically using Auto-RP or PIMv2 (BSR).

Note: adding a new loopback can change your OSPF/BGP/LDP Router-ID, it’s always recommended to hard-code your router-ID by router-id command.

Example:

Multicast path is: R7-> R5 –> R3 –> R1 –> R2 –> R4 –> R6 –> R8

R1:
interface Loopback0
ip address 10.10.1.1 255.255.255.255
ip pim sparse-mode
!
interface Loopback69
ip address 10.10.69.69 255.255.255.255
ip pim sparse-mode
!
interface FastEthernet0/0
ip pim sparse-mode
!
interface ATM2/0
ip pim sparse-mode
!
!
router ospf 1
 router-id 10.10.1.1
network 10.10.0.0 0.0.255.255 area 0
!
ip pim autorp listener
ip pim send-rp-announce Loopback69 scope 255
ip pim send-rp-discovery Loopback69 scope 255
ip msdp peer 10.10.12.2 connect-source FastEthernet0/0
!

R2:
interface Loopback0
ip address 10.10.2.2 255.255.255.255
ip pim sparse-mode
!
interface Loopback69
ip address 10.10.69.69 255.255.255.255
ip pim sparse-mode
!
interface Ethernet0/0
ip pim sparse-mode
!
interface Serial1/0
ip pim sparse-mode
!
router ospf 1
router-id 10.10.2.2
network 10.10.0.0 0.0.255.255 area 0
!
ip pim bsr-candidate Loopback69 0
ip pim rp-candidate Loopback69
ip msdp peer 10.10.12.1 connect-source Ethernet0/0
!

R2#sh ip msdp sa-cache
MSDP Source-Active Cache – 1 entries
(10.10.57.7, 224.100.100.100), RP 10.10.69.69,
AS ?,00:00:15/00:05:44, Peer 10.10.12.1

R5#sh ip pim rp mapping
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
  RP 10.10.69.69 (?), v2v1
    Info source: 10.10.69.69 (?), elected via Auto-RP

R6#sh ip pim rp mapping
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
  RP 10.10.69.69 (?), v2
    Info source: 10.10.69.69 (?), via bootstrap

For more information:

http://www.cisco.com/en/US/docs/ios/solutions_docs/
ip_multicast/White_papers/anycast.html

Multicast BGP feature adds capabilities to BGP to enable multicast routing to connect multicast topologies within and between BGP autonomous systems. MBGP is an enhanced BGP that carries IP multicast routes. PIM uses the multicast BGP database to perform Reverse Path Forwarding (RPF) lookups for multicast-capable sources. In our example, we will create a simple RPF failure in the network and then we will solve it by the multicast BGP. Example:

All routers are configured with PIM dense mode end-to-end. The multicast traffic path is:

R7 –> R5 –> R3 –> R1 –> R2 –> R4 –> R6 –> R8

Due to existence of eBGP between R3 and R4, Unicast path is:

R7 –> R5 –> R3 –> R4 –> R6 –> R8

So there’s an RPF failure, detected by R4… We can solve it either statically by “ip mroute” command or dynamically by MBGP.

Note: MBGP’s duty is to solve RPF failure, In fact multicast BGP routes are preferred over BGP unicast routes. We still need PIM for end to end delivery of IP multicast packets.

Configuration

R5:
ip multicast-routing
!
interface Ethernet0/0
ip pim dense-mode
!
interface Ethernet0/3
ip pim dense-mode
!

R3:
ip multicast-routing
!
interface FastEthernet0/0
ip pim dense-mode
!
interface ATM2/0
ip pim dense-mode
!

R1:
ip multicast-routing
!
interface FastEthernet0/0
ip pim dense-mode
!
interface ATM2/0
ip pim dense-mode
!
router bgp 135
neighbor 10.10.12.2 remote-as 246
neighbor 10.10.13.3 remote-as 135
!       
address-family ipv4
neighbor 10.10.12.2 activate
neighbor 10.10.13.3 activate
no auto-summary
no synchronization
exit-address-family
!
 address-family ipv4 multicast
 neighbor 10.10.12.2 activate
no auto-summary
 network 10.10.57.0 mask 255.255.255.0
exit-address-family
!
R2:
ip multicast-routing
!
interface Ethernet0/0
ip pim dense-mode
!
interface Serial1/0
ip pim dense-mode
!
router bgp 246
neighbor 10.10.12.1 remote-as 135
neighbor 10.10.24.4 remote-as 246
!
address-family ipv4
  neighbor 10.10.12.1 activate
  neighbor 10.10.24.4 activate
  no auto-summary
  no synchronization
exit-address-family
!
 address-family ipv4 multicast
  neighbor 10.10.12.1 activate
  neighbor 10.10.24.4 activate
  no auto-summary
  no synchronization
exit-address-family
!
R4:
ip multicast-routing
!
interface Ethernet0/0
ip pim dense-mode
!
interface Serial1/0
ip pim dense-mode
!
router bgp 246
neighbor 10.10.24.2 remote-as 246
neighbor 10.10.34.3 remote-as 135
neighbor 10.10.46.6 remote-as 246
!
address-family ipv4
  neighbor 10.10.24.2 activate
  neighbor 10.10.24.2 route-reflector-client
  neighbor 10.10.34.3 activate
  neighbor 10.10.46.6 activate
  neighbor 10.10.46.6 route-reflector-client
  no auto-summary
  no synchronization
exit-address-family
!
address-family ipv4 multicast
  neighbor 10.10.24.2 activate
  no auto-summary
  no synchronization
exit-address-family
!
R6:
ip multicast-routing
!
interface Ethernet0/0
ip pim dense-mode
!
interface Ethernet0/3
ip pim dense-mode
!
R8:
interface Ethernet0/0
ip address 10.10.68.8 255.255.255.0
 ip igmp join-group 224.69.69.69
!

Verification

R7#ping       
Protocol [ip]:
Target IP address: 224.69.69.69
Repeat count [1]: 100
Extended commands [n]: y
Interface [All]: ethernet0/0
Time to live [255]:           
Source address: 10.10.57.7 
Sending 100, 100-byte ICMP Echos to 224.69.69.69:
Packet sent with a source address of 10.10.57.7

Reply to request 0 from 10.10.68.8
Reply to request 1 from 10.10.68.8
Reply to request 2 from 10.10.68.8

R2#sh ip bgp ipv4 multicast

   Network          Next Hop   Metric LocPrf Weight Path
*> 10.10.57.0/24    10.10.12.1 12             0 135 i

R2#sh ip bgp

   Network          Next Hop   Metric LocPrf Weight Path
* i10.10.57.0/24    10.10.34.3  0    100      0 135 i
*>                  10.10.12.1                0 135 i
r>i10.10.68.0/24    10.10.46.6  0    100      0 i

R4#sh ip bgp ipv4 multicast

   Network          Next Hop   Metric LocPrf Weight Path
*>i10.10.57.0/24    10.10.12.1 12    100      0 135 i

R4#sh ip rpf event
Last 15 triggered multicast RPF check events

RPF backoff delay: 500 msec
RPF maximum delay: 5 sec

DATE/TIME          BACKOFF  PROTOCOL   EVENT      RPF CHANGES
Mar 1 00:20:24.767 500 msec BGP        Route Modified  1
Mar 1 00:05:08.631 500 msec OSPF       Route UP        0
Mar 1 00:05:05.851 500 msec BGP        Route UP        0
Mar 1 00:05:01.595 500 msec PIM        Nbr UP          0
Mar 1 00:03:08.263 500 msec OSPF       Route UP        0
Mar 1 00:03:00.531 500 msec PIM        Nbr UP          0
Mar 1 00:01:22.611 500 msec Connected  Route UP        0
Mar 1 00:01:02.747 500 msec Connected  Route Down      0
Mar 1 00:00:51.635 500 msec PIM        Nbr UP          0
Mar 1 00:00:44.995 500 msec OSPF       Route UP        0
Mar 1 00:00:28.915 500 msec Connected  Route UP        0

R4#sh ip rpf 10.10.57.7
RPF information for ? (10.10.57.7)
  RPF interface: Serial1/0
  RPF neighbor: ? (10.10.24.2)
  RPF route/mask: 10.10.57.0/24
  RPF type: mbgp
  RPF recursion count: 0
  Doing distance-preferred lookups across tables

R4#sh ip mroute
IP Multicast Routing Table

(*, 224.0.1.40), 01:34:08/00:02:39, RP 0.0.0.0, flags: DCL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Ethernet0/0, Forward/Dense, 01:19:37/00:00:00

(*, 224.69.69.69), 00:10:43/stopped, RP 0.0.0.0, flags: D
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Serial1/0, Forward/Dense, 00:10:43/00:00:00
    Ethernet0/0, Forward/Dense, 00:10:43/00:00:00

(10.10.57.7, 224.69.69.69), 00:10:43/00:00:02, flags: T
  Incoming interface: Serial1/0, RPF nbr 10.10.24.2, Mbgp
  Outgoing interface list:
    Ethernet0/0, Forward/Dense, 00:10:23/00:00:00

MSDP or Multicast Source Distribution Protocol allows multicast sources for a group to be known to all rendezvous points (RPs) in different domains. Each PIM-SM domain uses its own RP and MSDP connects source based trees to destination trees. MSDP uses TCP as control protocol and you will require end to end multicast routing protocol such as PIM. At boundries (Autonomous systems) we will filter RP announcements from other autonomous systems. Example:

Our example is very simple, two multicast domains with no RPF failure and end-to-end PIM sparse mode between R5 and R6. Multicast source is R7 (sending Ping to multicast group) and R8 as multicast member (IGMP join). R1 is Auto-RP MA and RP for AS135 and R2 is BSR for AS246. R1 and R2 communicate with MSDP language and deliver SA (Source Active) messages to each-others as peers, in this way each RP is infromed about active sources in different domain and can join its memebers to that multicast tree (S,G) to (*,G). To debug MSDP messages we can use “debug ip msdp peer” and “debug ip msdp routes”

Multicast path from source to member is:

R7 –> R5 –> R3 -> R1 –> R2 –> R4 –> R6 –> R8

R7#trace 10.10.68.8

  1 10.10.57.5
  2 10.10.35.3
  3 10.10.13.1
  4 10.10.12.2
  5 10.10.24.4
  6 10.10.46.6
  7 10.10.68.8

Configuration

R7:

R7#ping       
Protocol [ip]:
Target IP address: 224.69.69.69
Repeat count [1]: 10
Extended commands [n]: y
Interface [All]: ethernet0/0
Source address: 10.10.57.7

Sending 10, 100-byte ICMP Echos to 224.69.69.69, timeout is 2 seconds:
Packet sent with a source address of 10.10.57.7
..

R5:

ip multicast-routing
!
interface Ethernet0/0
ip address 10.10.35.5 255.255.255.0
ip pim sparse-mode
!
interface Ethernet0/3
ip address 10.10.57.5 255.255.255.0
ip pim sparse-mode
!
ip pim autorp listener
!

R3:

ip multicast-routing
!
interface FastEthernet0/0
ip address 10.10.35.3 255.255.255.0
ip pim sparse-mode
!
interface ATM2/0
ip address 10.10.13.3 255.255.255.0
ip pim sparse-mode
!
ip pim autorp listener
!

R1:

ip multicast-routing
!
interface Loopback0
ip address 10.10.1.1 255.255.255.255
ip pim sparse-mode
!
interface FastEthernet0/0
ip address 10.10.12.1 255.255.255.0
 ip pim bsr-border
ip pim sparse-mode
 ip multicast boundary 1
!
interface ATM2/0
ip address 10.10.13.1 255.255.255.0
ip pim sparse-mode
!
ip pim autorp listener
ip pim send-rp-announce Loopback0 scope 255
ip pim send-rp-discovery Loopback0 scope 255
ip msdp peer 10.10.12.2 connect-source FastEthernet0/0
!
access-list 1 deny   224.0.1.39
access-list 1 deny   224.0.1.40
access-list 1 permit any
!

R2:

ip multicast-routing
!
interface Loopback0
ip address 10.10.2.2 255.255.255.255
ip pim sparse-mode
!
interface Ethernet0/0
ip address 10.10.12.2 255.255.255.0
 ip pim bsr-border
ip pim sparse-mode
 ip multicast boundary 1
!
interface Serial1/0
ip address 10.10.24.2 255.255.255.0
ip pim sparse-mode
!
ip pim bsr-candidate Loopback0 0
ip pim rp-candidate Loopback0
ip msdp peer 10.10.12.1 connect-source Ethernet0/0
!
access-list 1 deny   224.0.1.39
access-list 1 deny   224.0.1.40
access-list 1 permit any
!

R4:

ip multicast-routing
!
interface Ethernet0/0
ip address 10.10.46.4 255.255.255.0
ip pim sparse-mode
!
interface Serial1/0
ip address 10.10.24.4 255.255.255.0
ip pim sparse-mode
!

R6:

ip multicast-routing
!
interface Ethernet0/0
ip address 10.10.46.6 255.255.255.0
ip pim sparse-mode
!
interface Ethernet0/3
ip address 10.10.68.6 255.255.255.0
ip pim sparse-mode
!

R8:

interface Ethernet0/0
ip address 10.10.68.8 255.255.255.0
ip igmp join-group 224.69.69.69
!

Verification

At this point, R8 joins multicast tree and R2 is aware of multicast source through MSDP SA messages from R1 and can responses are sent back from R8 to R7:

R7#ping       
Protocol [ip]:
Target IP address: 224.69.69.69
Repeat count [1]: 10
Extended commands [n]: y
Interface [All]: ethernet0/0
Source address: 10.10.57.7

Sending 10, 100-byte ICMP Echos to 224.69.69.69, timeout is 2 seconds:
Packet sent with a source address of 10.10.57.7
..
Reply to request 3 from 10.10.68.8
Reply to request 4 from 10.10.68.8
Reply to request 5 from 10.10.68.8
Reply to request 6 from 10.10.68.8
Reply to request 7 from 10.10.68.8
Reply to request 8 from 10.10.68.8
Reply to request 9 from 10.10.68.8

R1#sh ip pim rp mapping
PIM Group-to-RP Mappings
This system is an RP (Auto-RP)
This system is an RP-mapping agent (Loopback0)

Group(s) 224.0.0.0/4
  RP 10.10.1.1 (?), v2v1
    Info source: 10.10.1.1 (?), elected via Auto-RP
         Uptime: 17:03:06, expires: 00:02:52

R1#sh ip mroute
IP Multicast Routing Table
Flags: D – Dense, S – Sparse, B – Bidir Group, C – Connected,
       L – Local, P – Pruned, T – SPT-bit set, J – Join SPT,
       M – MSDP created entry,
       A – Candidate for MSDP Advertisement
 

(*, 224.0.1.39), 17:04:10/stopped, RP 0.0.0.0, flags: DCL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Loopback0, Forward/Sparse, 17:03:11/00:00:00
    ATM2/0, Forward/Sparse, 17:04:10/00:00:00

(10.10.1.1, 224.0.1.39), 17:04:10/00:02:49, flags: LTA
  Incoming interface: Loopback0, RPF nbr 0.0.0.0
  Outgoing interface list:
    ATM2/0, Forward/Sparse, 17:03:11/00:00:00

(*, 224.0.1.40), 17:06:10/stopped, RP 0.0.0.0, flags: DCL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Loopback0, Forward/Sparse, 17:03:11/00:00:00
    ATM2/0, Forward/Sparse, 17:06:10/00:00:00

(10.10.1.1, 224.0.1.40), 17:03:10/00:02:54, flags: LTA
  Incoming interface: Loopback0, RPF nbr 0.0.0.0
  Outgoing interface list:
    ATM2/0, Forward/Sparse, 17:03:11/00:00:00

(*, 224.69.69.69), 00:01:50/stopped, RP 10.10.1.1, flags: SP
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list: Null

(10.10.57.7, 224.69.69.69), 00:01:50/00:01:54, flags: TA
  Incoming interface: ATM2/0, RPF nbr 10.10.13.3
  Outgoing interface list:
    FastEthernet0/0, Forward/Sparse, 00:01:49/00:02:39

R1#sh ip msdp peer
MSDP Peer 10.10.12.2 (?), AS 246
Description:
  Connection status:
    State: Up, Resets: 0,
    Connection source: FastEthernet0/0 (10.10.12.1)
    Uptime(Downtime): 14:14:08, Messages sent/received: 922/854
    Output messages discarded: 0
    Connection and counters cleared 14:16:09 ago
  SA Filtering:
    Input (S,G) filter: none, route-map: none
    Input RP filter: none, route-map: none
    Output (S,G) filter: none, route-map: none
    Output RP filter: none, route-map: none
  SA-Requests:
    Input filter: none
  Peer ttl threshold: 0
  SAs learned from this peer: 0
  Input queue size: 0, Output queue size: 0

R2 Verification

R2#sh ip pim rp mapping
PIM Group-to-RP Mappings
This system is a candidate RP (v2)
This system is the Bootstrap Router (v2)

Group(s) 224.0.0.0/4
  RP 10.10.2.2 (?), v2
    Info source: 10.10.2.2 (?), via bootstrap, priority 0
    holdtime 150      Uptime: 16:13:59, expires: 00:01:27

R2#sh ip msdp summary
MSDP Peer Status Summary
Peer Address     AS    State    Uptime/  Reset SA    Peer Name
                                Downtime Count Count
10.10.12.1       135   Up       14:15:47 0     1     ?

R2#sh ip mroute

(*, 224.0.1.40), 16:22:23/00:02:02, RP 0.0.0.0, flags: DPL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list: Null

(*, 224.69.69.69), 01:17:15/stopped, RP 10.10.2.2, flags: S
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Serial1/0, Forward/Sparse, 01:17:15/00:03:03

(10.10.57.7, 224.69.69.69), 00:00:02/00:02:57, flags: M
  Incoming interface: Ethernet0/0, RPF nbr 10.10.12.1
  Outgoing interface list:
    Serial1/0, Forward/Sparse, 00:00:02/00:03:28

R6 Verification

R6#sh ip mroute

(*, 224.0.1.40), 16:17:35/00:02:49, RP 0.0.0.0, flags: DCL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Ethernet0/0, Forward/Sparse, 16:17:35/00:02:49

(*, 224.69.69.69), 01:13:28/stopped, RP 10.10.2.2, flags: SJC
  Incoming interface: Ethernet0/0, RPF nbr 10.10.46.4
  Outgoing interface list:
    Ethernet0/3, Forward/Sparse, 01:13:28/00:02:30

(10.10.57.7, 224.69.69.69), 00:00:02/00:02:57, flags: JT
  Incoming interface: Ethernet0/0, RPF nbr 10.10.46.4
  Outgoing interface list:
    Ethernet0/3, Forward/Sparse, 00:00:02/00:02:57

R6#sh ip pim rp mapping
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
  RP 10.10.2.2 (?), v2
    Info source: 10.10.2.2 (?), via bootstrap, priority 0, holdtime 150
         Uptime: 16:15:26, expires: 00:02:27

Multidifusión (Multicast): Se basa en un único proceso de envío, independientemente del número de potenciales máquinas receptoras, de una misma información en una o más unidades de datos (datagramas IP) desde una máquina origen a “>todas las máquinas destinatarias que class=”mceItemHidden”> posean al menos un miembro de un determinado grupo de multidifusión y que, además, compartan una misma dirección de multidifusión; y, posiblemente, dispersas geográficamente en múltiples redes por Internet

Multicast (multidifusión) es el envío de información en una red a múltiples receptores de forma simultanea, un emisor envía un mensaje y son varios los receptores que reciben el mismo.

Si antes hablabamos de que una comunicación unicast era una llamada telefónica entre dos personas, podemos decir que una comunicación multicast podría ser una conferencia, en la que son varias las personas que se comunican entre sí. Un ejemplo claro de comunicación multicast en Internet es un IRC (Internet Relay Chat).

El método Multicast sólo se puede usar en ambientes corporativos, a pesar de algunos esfuerzos aislados para introducirlo en Internet, y se aplica únicamente para transmisiones en vivo.

Autor de este post: Carlos Alonso: Director de Desarrollo de Negocio de Techex.

¿Como es posible grabar la televisión en su formato digital original MPEG 2?

Esto es posible gracias al uso de tecnología que permita extraer la información encapsulada en la señal de TDT o Satélite y entregársela al sistema de grabación. Actualmente esta tecnología está disponible en las Cabeceras de TV sobre IP, equipos de demultiplexación que por cada canal de televisión generan un servicio en la red de datos, un servicio multicast que lleva la información de audio/video, EPG y subtítulos. Un servidor informático recoge esa información que le llega por red y lo graba en el almacenamiento en disco. Si la red local de las dependencias esta configurada para dar servicios “Multicast” estas cadenas de televisión pueden, además, ser vistas en cualquier PC de la red, a través de un visor específico, que las plataformas de gestión ya incluyen.

 ¿Qué sucede si mi red no tiene posibilidades de tráfico multicast?

En ese caso, la información de los canales de televisión se aísla para que sólo llegue al sistema de grabación y no inunde la red de datos con emisiones broadcast no soportadas por las electrónicas. Este aislamiento se realiza poniendo una electrónica de red especifica que recibe la información de televisión y se la entrega al grabador, sin que salga de esa pequeña red configurada a propósito.

Si la emisión de televisión no se entrega en la red local de datos, ¿cómo acceden los usuarios a esa información?

Los usuarios, si bien es una comodidad poder visionar la televisión en vivo en sus propios PC de trabajo, no necesitan hacerlo para consultar la información grabada ni siquiera para documentarla, ya que el usuario accede al fichero grabado o que se está grabando y este acceso ya no se produce en modo multicast. El usuario podrá consultar el contenido sistema sin problema ni limitación alguna mas allá de sus permisos propios de usuario.