FASTWEB:   experiences on Video over IP Andrea Lasagna  27 Maggio 2008  PFI Pisa
Agenda <ul><li>Fastweb IPTV architecture </li></ul><ul><li>Protocols and network problems </li></ul><ul><li>Video quality ...
Service Innovation: FastwebTV Fastweb TV , a new way of watching TV …  it’s a Gaming Console …  it’s a programme guide …  ...
IPTV building blocks
Fastweb Network in figures <ul><li>4 billion euros invested since 1999  </li></ul><ul><li>50% population directly covered ...
Service- Agnostic  Access & Core Technologies Access Network Home / Office Core Network Services FTTH xDSL ULL / WS WI-MAX...
FASTWEB Network Topology Long Distance PoP Metropolitan Network Access National IPNetwork Large Business Access Bank Headq...
QoS enforcement: end-to-end requirement <ul><li>In a packet network, different traffic components compete for shared commu...
QoS enforcement: end-to-end requirement <ul><li>Traffic  Classification  at the Edge (source) </li></ul><ul><ul><li>Traffi...
Video over IP services <ul><li>Based onto  multiple  video distribution policies </li></ul><ul><ul><li>Video on Demand Ser...
Broadcast TV & VoD distribution Milan Turin Rome VOD Video Pumps VOD Video Pumps VOD Video Pumps Back-end Servers National...
VoD services over FTTH Streaming Farm Fastweb  MiniPoP Residential Customers Fastweb MiniPoP PoP PoP Video Pumps Video Ser...
VoD services over DSL Streaming Farm PoP Video Pumps Video Server Residential Customers VOD Content Video Access Request
Architecture of Broadcast TV services <ul><li>Multicast Channels </li></ul><ul><li>V ideo MPEG2  coding  Transport/Program...
Broadcast TV over FTTH Streaming Farm Fastweb  MiniPoP Residential Customers Fastweb MiniPoP PoP PoP Video Pumps Video Ser...
Broadcast TV over DSL Streaming Farm PoP Video Pumps Video Server Residential Customers Multicast Channells Multicast Chan...
Video services & access technologies <ul><li>FTTH </li></ul><ul><li>Fully scalable access architecture </li></ul><ul><li>Q...
Agenda <ul><li>Fastweb IPTV architecture </li></ul><ul><li>Protocols and network problems </li></ul><ul><li>Video quality ...
Design Multicast requirements <ul><li>Total number of multicast sources; </li></ul><ul><li>Total number of multicast group...
FW IP Multicast building blocks <ul><li>IGMP(v2) </li></ul><ul><ul><li>Manages receivers multicast group (channel) request...
Multicast forwarding <ul><li>Forget unicast forwarding: IP Destination Address, Routing table. </li></ul><ul><li>When forw...
IGMP <ul><li>IGMP (v2) </li></ul><ul><li>Very simple protocol: </li></ul><ul><li>Receivers: Join and Leave a multicast gro...
PIM-SM need for a Rendezvous Point <ul><li>Receiver: I ask for channel1 (multicast group 224.X.X.X)….. </li></ul><ul><li>I...
PIM-SM <ul><li>‘ Pull-mode’ protocol </li></ul><ul><li>Multicast trees are built from receivers up to source exploiting th...
Multicast in the access <ul><li>Ethernet boxes and IP Dslam are well designed for multicast delivery and qos. BNG as well ...
Agenda <ul><li>Fastweb IPTV architecture </li></ul><ul><li>Protocols and network problems </li></ul><ul><li>Video quality ...
IPTV QoE Engineering approach <ul><li>QoE  Top Down approach: </li></ul><ul><li>Characterize the high level metrics (Exper...
System end-to-end view <ul><li>Define end-to-end network performance requirements to achieve target QoE </li></ul>Courtesy...
QoE and IP network requirements <ul><li>A subset of user experience requirements for SD IPTV : </li></ul><ul><ul><li>Same ...
Network and IP transport layers  <ul><li>Minimum IP end-to-end bandwidth available for IPTV  </li></ul><ul><li>End-to-end ...
Based on field experience <ul><li>TV users may not complain or open a ticket for  </li></ul><ul><li>each error they notice...
<ul><li>IPTV service is highly sensitive to packet loss </li></ul><ul><li>Although the impact of a single packet loss depe...
IPTV IP Transport performance objectives Delay <ul><li>The delay introduced by a well performing IP network (say up to hun...
IP Transport performance objectives Channel change -  Delay variation <ul><li>Delay Variation: </li></ul><ul><ul><li>Becau...
Agenda <ul><li>Fastweb IPTV architecture </li></ul><ul><li>Protocols and network problems </li></ul><ul><li>Video quality ...
Internet Video challenges <ul><li>Video over internet is a big challenge </li></ul><ul><li>The growing range of video serv...
Summary <ul><li>Fastweb has the experience of several years of Video services over IP </li></ul><ul><ul><li>Multicast netw...
E-MBGP pim-sm pim-sm pim-sm pim-sm pim-sm pim-sm pim-sm pim-sm pim-sm pim-sm E-MBGP E-MBGP MSDP / RP RR pim-sm pim-sm SWIS...
contact: Andrea.Lasagna@fastweb.it
Upcoming SlideShare
Loading in...5
×

FASTWEB: experiences on Video over IP

907

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
907
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
18
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Leggere CLICK Copertura ULL e CVP
  • FASTWEB: experiences on Video over IP

    1. 1. FASTWEB: experiences on Video over IP Andrea Lasagna 27 Maggio 2008 PFI Pisa
    2. 2. Agenda <ul><li>Fastweb IPTV architecture </li></ul><ul><li>Protocols and network problems </li></ul><ul><li>Video quality of experience </li></ul><ul><li>Closing and summary </li></ul>
    3. 3. Service Innovation: FastwebTV Fastweb TV , a new way of watching TV … it’s a Gaming Console … it’s a programme guide … it’s a PVR … it’s a FAX … it’s a videoteque … it’s DTT … it’s Home Cinema … it’s voice mail … it’s Fastweb TV ! … it’s satellite TV with no dish! … it’s a PC
    4. 4. IPTV building blocks
    5. 5. Fastweb Network in figures <ul><li>4 billion euros invested since 1999 </li></ul><ul><li>50% population directly covered </li></ul><ul><li>180 local areas </li></ul><ul><li>10.000.000 home passed </li></ul><ul><li>1000 Local Switches with LLU </li></ul><ul><li>25.000 km network </li></ul>25.000 km
    6. 6. Service- Agnostic Access & Core Technologies Access Network Home / Office Core Network Services FTTH xDSL ULL / WS WI-MAX ? GSM / UMTS agnostic towards... Data , Voice and Video <ul><li>These advantages allow: </li></ul><ul><ul><li>Easy creation of new services with guaranteed QoS </li></ul></ul><ul><ul><li>Simplified operations </li></ul></ul><ul><ul><li>Strong competitive edge </li></ul></ul><ul><li>FASTWEB infrastructure: </li></ul><ul><ul><li>Fully IP  easy addition of new access technologies </li></ul></ul><ul><ul><li>Fully owned  total freedom in driving evolution </li></ul></ul>IP Core Network
    7. 7. FASTWEB Network Topology Long Distance PoP Metropolitan Network Access National IPNetwork Large Business Access Bank Headquarter FTTx Access Medium Enterprise Family xDSL Access Family Family Interconnection at local level OLO Network TI Network Central Office Medium Enterprise Metropolitan PoP
    8. 8. QoS enforcement: end-to-end requirement <ul><li>In a packet network, different traffic components compete for shared communication resources </li></ul><ul><li>Each communication trunk and network element contributes to determine the overall quality level of services offered to the Customer base </li></ul><ul><li>QoS enforcement policies must be implemented in both the Backbone and Access Layers </li></ul>GR F O P C P R M O R E A L N O B G TO BO GE RM NA MI FI BA RE VR BG GR F O P C P R M O R E A L N O B G TO BO GE RM NA MI BA RE PD Customer CPE Access B/Bone Customer CPE Access B/Bone Best Effort Data Hi Voice Video
    9. 9. QoS enforcement: end-to-end requirement <ul><li>Traffic Classification at the Edge (source) </li></ul><ul><ul><li>Traffic Marking </li></ul></ul><ul><ul><ul><li>IP (TOS Byte) </li></ul></ul></ul><ul><ul><ul><li>Ethernet (Tag Control Info) </li></ul></ul></ul><ul><ul><ul><li>MPLS (EXP Bits) </li></ul></ul></ul><ul><ul><ul><li>ATM (CLP Bit, ATM Class) </li></ul></ul></ul><ul><li>Forwarding classes Identification </li></ul><ul><ul><li>Traffic Matching </li></ul></ul><ul><li>Per Hop Behavior Enforcement </li></ul><ul><ul><li>Congestion Avoidance/Congestion Management </li></ul></ul><ul><ul><li>Marking mantenance, extension, modification </li></ul></ul>GR F O P C P R M O R E A L N O B G TO BO GE RM NA MI FI BA RE VR BG GR F O P C P R M O R E A L N O B G TO BO GE RM NA MI BA RE PD Customer CPE Access B/Bone Customer CPE Access B/Bone Best Effort Data Hi Voice Video
    10. 10. Video over IP services <ul><li>Based onto multiple video distribution policies </li></ul><ul><ul><li>Video on Demand Services (Unicast) </li></ul></ul><ul><ul><li>Broadcast Video Services (Multicast) </li></ul></ul><ul><li>VoD and Broadcast Video Services based onto MPEG2 over IP streams (H.264 for HD video) </li></ul><ul><ul><li>Each stream requires 4 Mbps on average for SD video </li></ul></ul><ul><li>Service elements </li></ul><ul><ul><li>Video Servers </li></ul></ul><ul><ul><ul><li>Registration and validation of Customer accesses and service requests </li></ul></ul></ul><ul><ul><li>Video Pumps </li></ul></ul><ul><ul><ul><li>Providing video streams towards client stations </li></ul></ul></ul><ul><ul><li>Video Station </li></ul></ul><ul><ul><ul><li>Client device with extended service access and stream management capabilities </li></ul></ul></ul>
    11. 11. Broadcast TV & VoD distribution Milan Turin Rome VOD Video Pumps VOD Video Pumps VOD Video Pumps Back-end Servers National B-bone National B-bone Central-server Overlay MAN Central-server Overlay MAN POP POP POP Video Broadcast Streamer Central-server Overlay Man Unicast Forwarding paths - VOD Multicast Forwarding trees – TV Channels
    12. 12. VoD services over FTTH Streaming Farm Fastweb MiniPoP Residential Customers Fastweb MiniPoP PoP PoP Video Pumps Video Server Video Access Request Video Output Residential Customers <ul><li>Video Server </li></ul><ul><li>Registration and validation of the Client station (STB) </li></ul><ul><li>Streams activation towards client stations </li></ul><ul><li>Video Pumps </li></ul><ul><li>distribute the video flows </li></ul><ul><li>Video Station </li></ul><ul><li>Set Top Box that allows customers to play video contents </li></ul>Video Traffic Signaling traffic
    13. 13. VoD services over DSL Streaming Farm PoP Video Pumps Video Server Residential Customers VOD Content Video Access Request
    14. 14. Architecture of Broadcast TV services <ul><li>Multicast Channels </li></ul><ul><li>V ideo MPEG2 coding Transport/Program up to 4Mbps </li></ul><ul><li>Around 120 Television Channels ‘broadcast ed ’ in the network </li></ul><ul><li>Video quality with standard resolution PAL 720x576 @ 25 frame/sec </li></ul><ul><li>Up to 400 Mbps simultaneous Multicast Traffic per network link (Backbone & Access) </li></ul><ul><li>Contents distribution from the cent ral-server (Mila n ) towards all other MAN over the national backbone </li></ul>
    15. 15. Broadcast TV over FTTH Streaming Farm Fastweb MiniPoP Residential Customers Fastweb MiniPoP PoP PoP Video Pumps Video Server Residential Customers Video Output <ul><li>Video Server </li></ul><ul><li>Registration and validation of the Client station (STB) </li></ul><ul><li>Streams activation towards client stations </li></ul><ul><li>Video Pumps </li></ul><ul><li>distribute the video flows </li></ul><ul><li>Video Station </li></ul><ul><li>Set Top Box that allows customers to play video contents </li></ul>
    16. 16. Broadcast TV over DSL Streaming Farm PoP Video Pumps Video Server Residential Customers Multicast Channells Multicast Channells Video Access Request
    17. 17. Video services & access technologies <ul><li>FTTH </li></ul><ul><li>Fully scalable access architecture </li></ul><ul><li>Quality of services provided by quality of optical network </li></ul><ul><li>Practically unlimited bouquet of services (creativity-limited only) dependent only on level of investment (network implementation investment/service revenues ratio) </li></ul><ul><li>xDSL </li></ul><ul><li>Limits arise principally from the access network </li></ul><ul><li>Time-dependent behaviour of copper pair </li></ul><ul><li>Penetration of services is less than the number of customers potentially available because of the limitations of bandwidth of the access network </li></ul>
    18. 18. Agenda <ul><li>Fastweb IPTV architecture </li></ul><ul><li>Protocols and network problems </li></ul><ul><li>Video quality of experience </li></ul><ul><li>Closing and summary </li></ul>
    19. 19. Design Multicast requirements <ul><li>Total number of multicast sources; </li></ul><ul><li>Total number of multicast groups; </li></ul><ul><li>Dislocation/distribution of multicast sources (sites); </li></ul><ul><li>Overall multicast bandwitdh requirement; </li></ul><ul><li>Maximum bandwidth per multicast group (and packet size); </li></ul><ul><li>Multicast group type of service (Video or transactional); </li></ul><ul><li>Multicast services paradigm: </li></ul><ul><ul><li>a) “One to Many” (sources distributed in few sites); </li></ul></ul><ul><ul><li>b) “Many to Many” (sources and receivers in all multicast sites) </li></ul></ul><ul><ul><li>c) “Some to Many” (different groups of sources and receivers in all multicast sites); </li></ul></ul>
    20. 20. FW IP Multicast building blocks <ul><li>IGMP(v2) </li></ul><ul><ul><li>Manages receivers multicast group (channel) request in the receiver LAN (broadcast domain) </li></ul></ul><ul><ul><li>Interface the IP L3 multicast protocol to forward the requested multicast group in the receiver LAN </li></ul></ul><ul><li>PIM-SM </li></ul><ul><ul><li>IP Multicast protocol: builds the distribution trees from the multicast sources to the receivers that have asked for a multicast group </li></ul></ul><ul><ul><li>The most used, robust and scalable multicast protocol deployed over operators network </li></ul></ul><ul><li>MSDP </li></ul><ul><ul><li>IP multicast protocol used to ‘find’ and exchange multicast source information in the network </li></ul></ul><ul><li>SSM </li></ul><ul><ul><li>IP multicast protocol, actually a subset of PIM-SSM, simpler, usable if multicast source IP addresses are well known and managed </li></ul></ul><ul><li>Anycast </li></ul><ul><ul><li>Technique to guarantee redundancy layering on a IP routing protocol </li></ul></ul>
    21. 21. Multicast forwarding <ul><li>Forget unicast forwarding: IP Destination Address, Routing table. </li></ul><ul><li>When forwarding unicast, the output interface is selected only matching the incoming packet IP DA in the Routing table where one (and one only) output interface is specified. </li></ul><ul><li>Multicast routing is first concerned about where the packet is coming from (RPF Check) in order to build and maintain check the multicast tree. </li></ul><ul><li>RPF Check: </li></ul><ul><ul><li>The routing table used for multicasting is checked against the “source” IP address in the packet. </li></ul></ul><ul><ul><li>If the datagram arrived on the interface specified in the routing table for the source address; then the RPF check succeeds. </li></ul></ul><ul><ul><li>Otherwise, the RPF Check fails </li></ul></ul>
    22. 22. IGMP <ul><li>IGMP (v2) </li></ul><ul><li>Very simple protocol: </li></ul><ul><li>Receivers: Join and Leave a multicast group: IPTV Leave Ch1, Join Ch11 </li></ul><ul><li>Querier: Maintain the state of the requested channel in broadcast domain (LAN or VLAN) to cooperate with the L3 multicast protocol and ask for sources down to the LAN </li></ul><ul><li>General Queries (which multicast groups are requested in this LAN?) </li></ul><ul><li>Group Specific Queries </li></ul><ul><li>Can be tuned to optimize perfomance (time-outs, robustness variable, number of queries before expiring a multicast group, etc) </li></ul>
    23. 23. PIM-SM need for a Rendezvous Point <ul><li>Receiver: I ask for channel1 (multicast group 224.X.X.X)….. </li></ul><ul><li>IP Router:…. where is the source for group 224.X.X.X? </li></ul><ul><li>Source: I am source 224.Y.Y.Y, deliver me towards who’s asking for me…. </li></ul><ul><li>IP Router….where are the receivers? </li></ul><ul><li>-> A mechanism is needed to make sources and receivers meet… </li></ul><ul><li>A Rendezvous Point! </li></ul><ul><li>In PIM-SM sources and receivers ‘meet’ at the Rendezvous Point </li></ul><ul><li>In PIM SM deployment one or more routers have to provide RP functionalities </li></ul><ul><li> Every router in the PIM-SM domain must know the RP! </li></ul>
    24. 24. PIM-SM <ul><li>‘ Pull-mode’ protocol </li></ul><ul><li>Multicast trees are built from receivers up to source exploiting the Rendezvous Point </li></ul><ul><li>Shared trees (From Receivers to RP) </li></ul><ul><li>Source trees (From RP to sources) </li></ul><ul><li>Shortest path trees (From Receivers to sources) </li></ul><ul><li>Switch over: when a receiver receives the first multicast packet from the RP through the Shared tree, it can directly build and use the SPT (Action done by the first IP PIM router) </li></ul><ul><li>RPF Check: towards RP for shared trees, towards sources for SPT and Source trees </li></ul><ul><li>When everything is put together, traffic flows through Shortest Path Trees. </li></ul><ul><li>SPT connects the closest router to the receiver to closest router to the source </li></ul><ul><li>Each node (router) in the tree will have a: </li></ul><ul><li>(S,G) state associated to a list of output interfaces. </li></ul>
    25. 25. Multicast in the access <ul><li>Ethernet boxes and IP Dslam are well designed for multicast delivery and qos. BNG as well </li></ul><ul><li>ATM equipment is not… </li></ul><ul><li>ATM DSLAM with IGMP Proxy and BNG with Multicast (oif mapping) </li></ul><ul><li>ATM switch with Multicast enabled (IGMP Proxy) </li></ul>
    26. 26. Agenda <ul><li>Fastweb IPTV architecture </li></ul><ul><li>Protocols and network problems </li></ul><ul><li>Video quality of experience </li></ul><ul><li>Closing and summary </li></ul>
    27. 27. IPTV QoE Engineering approach <ul><li>QoE Top Down approach: </li></ul><ul><li>Characterize the high level metrics (Experience, user perspective), to define low level requirements (ie application, coding, network and transport) </li></ul><ul><li>Goal: To guarantee an IPTV flow in respect of the IPTV service requirements from the Source to the end user STB </li></ul>Source: DSL-FORUM TR 126
    28. 28. System end-to-end view <ul><li>Define end-to-end network performance requirements to achieve target QoE </li></ul>Courtesy of: Nortel, Tim Rahrer This is where quality counts! Need a complete end-to-end view and user needs to ensure network architecture and service success Content & Video Headend Transport, Voice, and Core Local Content Content Management VOD / Middleware Digital Content Internet Voice Services In-Home Access Infrastructure
    29. 29. QoE and IP network requirements <ul><li>A subset of user experience requirements for SD IPTV : </li></ul><ul><ul><li>Same video quality as the user is normally used to through other means of distribution (Satellite, terrestrial, cable) </li></ul></ul><ul><ul><li>High availability and continuity of the service </li></ul></ul><ul><ul><li>Very low visible impairment (error) rate – how low? </li></ul></ul><ul><ul><ul><li>Current standards and guidelines converge to a target of one visible impairment per hour </li></ul></ul></ul><ul><ul><li>Channel Change time comparable to what the user is used to </li></ul></ul>
    30. 30. Network and IP transport layers <ul><li>Minimum IP end-to-end bandwidth available for IPTV </li></ul><ul><li>End-to-end IP Transport performance objectives for: </li></ul><ul><ul><ul><li>Packet Loss </li></ul></ul></ul><ul><ul><ul><li>Delay </li></ul></ul></ul><ul><ul><ul><li>Delay variation </li></ul></ul></ul><ul><li>IP QoS support to handle congestion </li></ul>
    31. 31. Based on field experience <ul><li>TV users may not complain or open a ticket for </li></ul><ul><li>each error they notice… but they always compare </li></ul><ul><li>what they get through IP/DSL with traditional </li></ul><ul><li>broadcasting service, and based on this may decide </li></ul><ul><li>whether to subscribe or confirm subscription: </li></ul><ul><ul><ul><li>Input in the network good enough quality video </li></ul></ul></ul><ul><ul><ul><li>Preserve it throughout all the IP delivery chain </li></ul></ul></ul>
    32. 32. <ul><li>IPTV service is highly sensitive to packet loss </li></ul><ul><li>Although the impact of a single packet loss depends of several factors such as: </li></ul><ul><ul><ul><li>Compression algorithm (MPEG2, H.264, etc.) </li></ul></ul></ul><ul><ul><ul><li>GOP Structure </li></ul></ul></ul><ul><ul><ul><li>Type of information lost (I,P,B frame, other MPEG information, etc) </li></ul></ul></ul><ul><ul><ul><li>Codec performance (encoding and decoding) </li></ul></ul></ul><ul><ul><ul><li>Complexity of the video content </li></ul></ul></ul><ul><ul><ul><li>Error concealment at the STB </li></ul></ul></ul><ul><li>It is highly likely that a single IP packet loss produce a visible impairment to the user – Note that a single IP packet usually transports 7 188 Byte MPEG packets </li></ul>IP Transport performance objectives Packet Loss <ul><li>Packet loss has to be minimized and strictly controlled: </li></ul><ul><li>Simple metrics as average Packet Loss Ratio are not enough to describe the packet loss requirement </li></ul><ul><li> what matters is the loss event, its rate (MTBE) and shape (loss period and distance), not only the ratio lost_packets/received_packets. </li></ul>
    33. 33. IPTV IP Transport performance objectives Delay <ul><li>The delay introduced by a well performing IP network (say up to hundreds of milliseconds for a huge geographical network) is usually negligible for the IPTV service considering that: </li></ul><ul><ul><li>Most of the delay from the live content will be added from the Head-end and video acquisition/coding/transcoding chain </li></ul></ul><ul><ul><li>Current satellite broadcast TV service already may insert a delay up to a few seconds </li></ul></ul><ul><ul><li>Delay in Channel Change time due to network transfer delay signalling processing (IGMP Leave/Join signalling and first packet reception of the requested channel for multicast service) is negligible (up to few tenths of milliseconds) when compared to the time needed to the STB to buffer enough video content for a smooth start for the play out .This time is usually comparable to a GOP interval which for 4 Mbps MPEG2 video streams is about half a second </li></ul></ul>
    34. 34. IP Transport performance objectives Channel change - Delay variation <ul><li>Delay Variation: </li></ul><ul><ul><li>Because of the presence of a quite large play-out/de-jitter buffer at the receiving side (STB), all potential jitter introduced by a well performing IP network is removed for a smooth play-out and virtually no packets is lost due to late arrival. </li></ul></ul>
    35. 35. Agenda <ul><li>Fastweb IPTV architecture </li></ul><ul><li>Protocols and network problems </li></ul><ul><li>Video quality of experience </li></ul><ul><li>Closing and summary </li></ul>
    36. 36. Internet Video challenges <ul><li>Video over internet is a big challenge </li></ul><ul><li>The growing range of video services available over the Internet is already subject to congestion and contention issues </li></ul><ul><li>Which type of service? Guaranteed or Best effort </li></ul><ul><li>Do contents arrive from the content provider only or also from the consumers? </li></ul><ul><li>Do we need Reliability ? Replication or ACK-based mechanisms ? </li></ul><ul><li>Do we need QoS? </li></ul><ul><li>Rate Adaption codec? </li></ul>
    37. 37. Summary <ul><li>Fastweb has the experience of several years of Video services over IP </li></ul><ul><ul><li>Multicast networking </li></ul></ul><ul><ul><li>QoS and QoE measurements and reporting </li></ul></ul><ul><li>We are ready to multicast with everyone </li></ul>
    38. 38. E-MBGP pim-sm pim-sm pim-sm pim-sm pim-sm pim-sm pim-sm pim-sm pim-sm pim-sm E-MBGP E-MBGP MSDP / RP RR pim-sm pim-sm SWISSCOM I-MBGP I-MBGP I-MGBP I-MGBP MSDP Internet Nr001 Nr002 Ih001 Ih002 IM Ir001 Ir005 Ir003 pim-sm interface loopback239 description MSDP/RP ip address 81.208.50.50/32 pim-sm pim-sm
    39. 39. contact: Andrea.Lasagna@fastweb.it
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×