RFC 8313
Use of Multicast across Inter-domain Peering Points
Pages: 44
Best Current Practice: 213
Best Current Practice: 213
Part 1 of 3 – Pages 1 to 17
Internet Engineering Task Force (IETF) P. Tarapore, Ed. Request for Comments: 8313 R. Sayko BCP: 213 AT&T Category: Best Current Practice G. Shepherd ISSN: 2070-1721 Cisco T. Eckert, Ed. Huawei R. Krishnan SupportVectors January 2018 Use of Multicast across Inter-domain Peering PointsAbstract
This document examines the use of Source-Specific Multicast (SSM) across inter-domain peering points for a specified set of deployment scenarios. The objectives are to (1) describe the setup process for multicast-based delivery across administrative domains for these scenarios and (2) document supporting functionality to enable this process. Status of This Memo This memo documents an Internet Best Current Practice. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8313.
Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction ....................................................4 2. Overview of Inter-domain Multicast Application Transport ........6 3. Inter-domain Peering Point Requirements for Multicast ...........7 3.1. Native Multicast ...........................................8 3.2. Peering Point Enabled with GRE Tunnel .....................10 3.3. Peering Point Enabled with AMT - Both Domains Multicast Enabled .........................................12 3.4. Peering Point Enabled with AMT - AD-2 Not Multicast Enabled .........................................14 3.5. AD-2 Not Multicast Enabled - Multiple AMT Tunnels through AD-2 ..............................................16 4. Functional Guidelines ..........................................18 4.1. Network Interconnection Transport Guidelines ..............18 4.1.1. Bandwidth Management ...............................19 4.2. Routing Aspects and Related Guidelines ....................20 4.2.1. Native Multicast Routing Aspects ...................21 4.2.2. GRE Tunnel over Interconnecting Peering Point ......22 4.2.3. Routing Aspects with AMT Tunnels ...................22 4.2.4. Public Peering Routing Aspects .....................24 4.3. Back-Office Functions - Provisioning and Logging Guidelines ................................................26 4.3.1. Provisioning Guidelines ............................26 4.3.2. Inter-domain Authentication Guidelines .............28 4.3.3. Log-Management Guidelines ..........................28 4.4. Operations - Service Performance and Monitoring Guidelines ................................................30 4.5. Client Reliability Models / Service Assurance Guidelines ..32 4.6. Application Accounting Guidelines .........................32 5. Troubleshooting and Diagnostics ................................32 6. Security Considerations ........................................33 6.1. DoS Attacks (against State and Bandwidth) .................33 6.2. Content Security ..........................................35 6.3. Peering Encryption ........................................37 6.4. Operational Aspects .......................................37 7. Privacy Considerations .........................................39 8. IANA Considerations ............................................40 9. References .....................................................40 9.1. Normative References ......................................40 9.2. Informative References ....................................42 Acknowledgments ...................................................43 Authors' Addresses ................................................44
1. Introduction
Content and data from several types of applications (e.g., live video streaming, software downloads) are well suited for delivery via multicast means. The use of multicast for delivering such content or other data offers significant savings in terms of utilization of resources in any given administrative domain. End User (EU) demand for such content or other data is growing. Often, this requires transporting the content or other data across administrative domains via inter-domain peering points. The objectives of this document are twofold: o Describe the technical process and establish guidelines for setting up multicast-based delivery of application content or other data across inter-domain peering points via a set of use cases (where "Use Case 3.1" corresponds to Section 3.1, "Use Case 3.2" corresponds to Section 3.2, etc.). o Catalog all required exchanges of information between the administrative domains to support multicast-based delivery. This enables operators to initiate necessary processes to support inter-domain peering with multicast. The scope and assumptions for this document are as follows: o Administrative Domain 1 (AD-1) sources content to one or more EUs in one or more Administrative Domain 2 (AD-2) entities. AD-1 and AD-2 want to use IP multicast to allow support for large and growing EU populations, with a minimum amount of duplicated traffic to send across network links. * This document does not detail the case where EUs are originating content. To support that additional service, it is recommended that some method (outside the scope of this document) be used by which the content from EUs is transmitted to the application in AD-1 and AD-1 can send out the traffic as IP multicast. From that point on, the descriptions in this document apply, except that they are not complete because they do not cover the transport or operational aspects of the leg from the EU to AD-1. * This document does not detail the case where AD-1 and AD-2 are not directly connected to each other and are instead connected via one or more other ADs (as opposed to a peering point) that serve as transit providers. The cases described in this document where tunnels are used between AD-1 and AD-2 can be applied to such scenarios, but SLA ("Service Level Agreement")
control, for example, would be different. Additional issues
will likely exist as well in such scenarios. This topic is
left for further study.
o For the purposes of this document, the term "peering point" refers
to a network connection ("link") between two administrative
network domains over which traffic is exchanged between them.
This is also referred to as a Network-to-Network Interface (NNI).
Unless otherwise noted, it is assumed that the peering point is a
private peering point, where the network connection is a
physically or virtually isolated network connection solely between
AD-1 and AD-2. The other case is that of a broadcast peering
point, which is a common option in public Internet Exchange Points
(IXPs). See Section 4.2.4 for more details.
o AD-1 is enabled with native multicast. A peering point exists
between AD-1 and AD-2.
o It is understood that several protocols are available for this
purpose, including Protocol-Independent Multicast - Sparse Mode
(PIM-SM) and Protocol-Independent Multicast - Source-Specific
Multicast (PIM-SSM) [RFC7761], the Internet Group Management
Protocol (IGMP) [RFC3376], and Multicast Listener Discovery (MLD)
[RFC3810].
o As described in Section 2, the source IP address of the (so-called
"(S,G)") multicast stream in the originating AD (AD-1) is known.
Under this condition, using PIM-SSM is beneficial, as it allows
the receiver's upstream router to send a join message directly to
the source without the need to invoke an intermediate Rendezvous
Point (RP). The use of SSM also presents an improved threat
mitigation profile against attack, as described in [RFC4609].
Hence, in the case of inter-domain peering, it is recommended that
only SSM protocols be used; the setup of inter-domain peering for
ASM (Any-Source Multicast) is out of scope for this document.
o The rest of this document assumes that PIM-SSM and BGP are used
across the peering point, plus Automatic Multicast Tunneling (AMT)
[RFC7450] and/or Generic Routing Encapsulation (GRE), according to
the scenario in question. The use of other protocols is beyond
the scope of this document.
o AMT is set up at the peering point if either the peering point or
AD-2 is not multicast enabled. It is assumed that an AMT relay
will be available to a client for multicast delivery. The
selection of an optimal AMT relay by a client is out of scope for
this document. Note that using AMT is necessary only when native
multicast is unavailable in the peering point (Use Case 3.3) or in
the downstream administrative domain (Use Cases 3.4 and 3.5).
o It is assumed that the collection of billing data is done at the
application level and is not considered to be a networking issue.
The settlements process for EU billing and/or inter-provider
billing is out of scope for this document.
o Inter-domain network connectivity troubleshooting is only
considered within the context of a cooperative process between the
two domains.
This document also attempts to identify ways by which the peering
process can be improved. Development of new methods for improvement
is beyond the scope of this document.
2. Overview of Inter-domain Multicast Application Transport
A multicast-based application delivery scenario is as follows:
o Two independent administrative domains are interconnected via a
peering point.
o The peering point is either multicast enabled (end-to-end native
multicast across the two domains) or connected by one of two
possible tunnel types:
* A GRE tunnel [RFC2784] allowing multicast tunneling across the
peering point, or
* AMT [RFC7450].
o A service provider controls one or more application sources in
AD-1 that will send multicast IP packets via one or more (S,G)s
(multicast traffic flows; see Section 4.2.1 if you are unfamiliar
with IP multicast). It is assumed that the service being provided
is suitable for delivery via multicast (e.g., live video streaming
of popular events, software downloads to many devices) and that
the packet streams will be carried by a suitable multicast
transport protocol.
o An EU controls a device connected to AD-2, which runs an
application client compatible with the service provider's
application source.
o The application client joins appropriate (S,G)s in order to
receive the data necessary to provide the service to the EU. The
mechanisms by which the application client learns the appropriate
(S,G)s are an implementation detail of the application and are out
of scope for this document.
The assumption here is that AD-1 has ultimate responsibility for
delivering the multicast-based service on behalf of the content
source(s). All relevant interactions between the two domains
described in this document are based on this assumption.
Note that AD-2 may be an independent network domain (e.g., a Tier 1
network operator domain). Alternately, AD-2 could also be an
enterprise network domain operated by a single customer of AD-1. The
peering point architecture and requirements may have some unique
aspects associated with enterprise networks; see Section 3.
The use cases describing various architectural configurations for
multicast distribution, along with associated requirements, are
described in Section 3. Section 4 contains a comprehensive list of
pertinent information that needs to be exchanged between the two
domains in order to support functions to enable application
transport.
3. Inter-domain Peering Point Requirements for Multicast
The transport of applications using multicast requires that the
inter-domain peering point be enabled to support such a process.
This section presents five use cases for consideration.
3.1. Native Multicast
This use case involves end-to-end native multicast between the two administrative domains, and the peering point is also native multicast enabled. See Figure 1. ------------------- ------------------- / AD-1 \ / AD-2 \ / (Multicast Enabled) \ / (Multicast Enabled) \ / \ / \ | +----+ | | | | | | +------+ | | +------+ | +----+ | | AS |------>| BR |-|---------|->| BR |-------------|-->| EU | | | | +------+ | I1 | +------+ |I2 +----+ \ +----+ / \ / \ / \ / \ / \ / ------------------- ------------------- AD = Administrative Domain (independent autonomous system) AS = multicast (e.g., content) Application Source BR = Border Router I1 = AD-1 and AD-2 multicast interconnection (e.g., MP-BGP) I2 = AD-2 and EU multicast connection Figure 1: Content Distribution via End-to-End Native Multicast Advantages of this configuration: o Most efficient use of bandwidth in both domains. o Fewer devices in the path traversed by the multicast stream when compared to an AMT-enabled peering point. From the perspective of AD-1, the one disadvantage associated with native multicast to AD-2 instead of individual unicast to every EU in AD-2 is that it does not have the ability to count the number of EUs as well as the transmitted bytes delivered to them. This information is relevant from the perspective of customer billing and operational logs. It is assumed that such data will be collected by the application layer. The application-layer mechanisms for generating this information need to be robust enough so that all pertinent requirements for the source provider and the AD operator are satisfactorily met. The specifics of these methods are beyond the scope of this document.
Architectural guidelines for this configuration are as follows:
a. Dual homing for peering points between domains is recommended as
a way to ensure reliability with full BGP table visibility.
b. If the peering point between AD-1 and AD-2 is a controlled
network environment, then bandwidth can be allocated accordingly
by the two domains to permit the transit of non-rate-adaptive
multicast traffic. If this is not the case, then the multicast
traffic must support congestion control via any of the mechanisms
described in Section 4.1 of [BCP145].
c. The sending and receiving of multicast traffic between two
domains is typically determined by local policies associated with
each domain. For example, if AD-1 is a service provider and AD-2
is an enterprise, then AD-1 may support local policies for
traffic delivery to, but not traffic reception from, AD-2.
Another example is the use of a policy by which AD-1 delivers
specified content to AD-2 only if such delivery has been accepted
by contract.
d. It is assumed that relevant information on multicast streams
delivered to EUs in AD-2 is collected by available capabilities
in the application layer. The precise nature and formats of the
collected information will be determined by directives from the
source owner and the domain operators.
3.2. Peering Point Enabled with GRE Tunnel
The peering point is not native multicast enabled in this use case. There is a GRE tunnel provisioned over the peering point. See Figure 2. ------------------- ------------------- / AD-1 \ / AD-2 \ / (Multicast Enabled) \ / (Multicast Enabled) \ / \ / \ | +----+ +---+ | (I1) | +---+ | | | | +--+ |uBR|-|--------|-|uBR| +--+ | +----+ | | AS |-->|BR| +---+-| | +---+ |BR| -------->|-->| EU | | | | +--+<........|........|........>+--+ |I2 +----+ \ +----+ / I1 \ / \ / GRE \ / \ / Tunnel \ / ------------------- ------------------- AD = Administrative Domain (independent autonomous system) AS = multicast (e.g., content) Application Source uBR = unicast Border Router - not necessarily multicast enabled; may be the same router as BR BR = Border Router - for multicast I1 = AD-1 and AD-2 multicast interconnection (e.g., MP-BGP) I2 = AD-2 and EU multicast connection Figure 2: Content Distribution via GRE Tunnel In this case, interconnection I1 between AD-1 and AD-2 in Figure 2 is multicast enabled via a GRE tunnel [RFC2784] between the two BRs and encapsulating the multicast protocols across it. Normally, this approach is chosen if the uBR physically connected to the peering link cannot or should not be enabled for IP multicast. This approach may also be beneficial if the BR and uBR are the same device but the peering link is a broadcast domain (IXP); see Section 4.2.4. The routing configuration is basically unchanged: instead of running BGP (SAFI-2) ("SAFI" stands for "Subsequent Address Family Identifier") across the native IP multicast link between AD-1 and AD-2, BGP (SAFI-2) is now run across the GRE tunnel.
Advantages of this configuration:
o Highly efficient use of bandwidth in both domains, although not as
efficient as the fully native multicast use case (Section 3.1).
o Fewer devices in the path traversed by the multicast stream when
compared to an AMT-enabled peering point.
o Ability to support partial and/or incremental IP multicast
deployments in AD-1 and/or AD-2: only the path or paths between
the AS/BR (AD-1) and the BR/EU (AD-2) need to be multicast
enabled. The uBRs may not support IP multicast or enabling it
could be seen as operationally risky on that important edge node,
whereas dedicated BR nodes for IP multicast may (at least
initially) be more acceptable. The BR can also be located such
that only parts of the domain may need to support native IP
multicast (e.g., only the core in AD-1 but not edge networks
towards the uBR).
o GRE is an existing technology and is relatively simple to
implement.
Disadvantages of this configuration:
o Per Use Case 3.1, current router technology cannot count the
number of EUs or the number of bytes transmitted.
o The GRE tunnel requires manual configuration.
o The GRE tunnel must be established prior to starting the stream.
o The GRE tunnel is often left pinned up.
Architectural guidelines for this configuration include the
following:
Guidelines (a) through (d) are the same as those described in
Use Case 3.1. Two additional guidelines are as follows:
e. GRE tunnels are typically configured manually between peering
points to support multicast delivery between domains.
f. It is recommended that the GRE tunnel (tunnel server)
configuration in the source network be such that it only
advertises the routes to the application sources and not to the
entire network. This practice will prevent unauthorized delivery
of applications through the tunnel (for example, if the
application (e.g., content) is not part of an agreed-upon
inter-domain partnership).
3.3. Peering Point Enabled with AMT - Both Domains Multicast Enabled
It is assumed that both administrative domains in this use case are
native multicast enabled here; however, the peering point is not.
The peering point is enabled with AMT. The basic configuration is
depicted in Figure 3.
------------------- -------------------
/ AD-1 \ / AD-2 \
/ (Multicast Enabled) \ / (Multicast Enabled) \
/ \ / \
| +----+ +---+ | I1 | +---+ |
| | | +--+ |uBR|-|--------|-|uBR| +--+ | +----+
| | AS |-->|AR| +---+-| | +---+ |AG| -------->|-->| EU |
| | | +--+<........|........|........>+--+ |I2 +----+
\ +----+ / AMT \ /
\ / Tunnel \ /
\ / \ /
------------------- -------------------
AD = Administrative Domain (independent autonomous system)
AS = multicast (e.g., content) Application Source
AR = AMT Relay
AG = AMT Gateway
uBR = unicast Border Router - not multicast enabled;
also, either AR = uBR (AD-1) or uBR = AG (AD-2)
I1 = AMT interconnection between AD-1 and AD-2
I2 = AD-2 and EU multicast connection
Figure 3: AMT Interconnection between AD-1 and AD-2
Advantages of this configuration:
o Highly efficient use of bandwidth in AD-1.
o AMT is an existing technology and is relatively simple to
implement. Attractive properties of AMT include the following:
* Dynamic interconnection between the gateway-relay pair across
the peering point.
* Ability to serve clients and servers with differing policies.
Disadvantages of this configuration:
o Per Use Case 3.1 (AD-2 is native multicast), current router
technology cannot count the number of EUs or the number of bytes
transmitted to all EUs.
o Additional devices (AMT gateway and relay pairs) may be introduced
into the path if these services are not incorporated into the
existing routing nodes.
o Currently undefined mechanisms for the AG to automatically select
the optimal AR.
Architectural guidelines for this configuration are as follows:
Guidelines (a) through (d) are the same as those described in
Use Case 3.1. In addition,
e. It is recommended that AMT relay and gateway pairs be configured
at the peering points to support multicast delivery between
domains. AMT tunnels will then configure dynamically across the
peering points once the gateway in AD-2 receives the (S,G)
information from the EU.
3.4. Peering Point Enabled with AMT - AD-2 Not Multicast Enabled
In this AMT use case, AD-2 is not multicast enabled. Hence, the interconnection between AD-2 and the EU is also not multicast enabled. This use case is depicted in Figure 4. ------------------- ------------------- / AD-1 \ / AD-2 \ / (Multicast Enabled) \ / (Not Multicast \ / \ / Enabled) \ N(large) | +----+ +---+ | | +---+ | # EUs | | | +--+ |uBR|-|--------|-|uBR| | +----+ | | AS |-->|AR| +---+-| | +---+ ................>|EU/G| | | | +--+<........|........|........... |I2 +----+ \ +----+ / N x AMT\ / \ / Tunnel \ / \ / \ / ------------------- ------------------- AS = multicast (e.g., content) Application Source uBR = unicast Border Router - not multicast enabled; otherwise, AR = uBR (in AD-1) AR = AMT Relay EU/G = Gateway client embedded in EU device I2 = AMT tunnel connecting EU/G to AR in AD-1 through non-multicast-enabled AD-2 Figure 4: AMT Tunnel Connecting AD-1 AMT Relay and EU Gateway This use case is equivalent to having unicast distribution of the application through AD-2. The total number of AMT tunnels would be equal to the total number of EUs requesting the application. The peering point thus needs to accommodate the total number of AMT tunnels between the two domains. Each AMT tunnel can provide the data usage associated with each EU. Advantages of this configuration: o Efficient use of bandwidth in AD-1 (the closer the AR is to the uBR, the more efficient). o Ability of AD-1 to introduce content delivery based on IP multicast, without any support by network devices in AD-2: only the application side in the EU device needs to perform AMT gateway library functionality to receive traffic from the AMT relay. o Allows AD-2 to "upgrade" to Use Case 3.5 (see Section 3.5) at a later time, without any change in AD-1 at that time.
o AMT is an existing technology and is relatively simple to
implement. Attractive properties of AMT include the following:
* Dynamic interconnection between the AMT gateway-relay pair
across the peering point.
* Ability to serve clients and servers with differing policies.
o Each AMT tunnel serves as a count for each EU and is also able to
track data usage (bytes) delivered to the EU.
Disadvantages of this configuration:
o Additional devices (AMT gateway and relay pairs) are introduced
into the transport path.
o Assuming multiple peering points between the domains, the EU
gateway needs to be able to find the "correct" AMT relay in AD-1.
Architectural guidelines for this configuration are as follows:
Guidelines (a) through (c) are the same as those described in
Use Case 3.1. In addition,
d. It is necessary that proper procedures be implemented such that
the AMT gateway at the EU device is able to find the correct AMT
relay for each (S,G) content stream. Standard mechanisms for
that selection are still subject to ongoing work. This includes
the use of anycast gateway addresses, anycast DNS names, or
explicit configuration that maps (S,G) to a relay address; or
letting the application in the EU/G provide the relay address to
the embedded AMT gateway function.
e. The AMT tunnel's capabilities are expected to be sufficient for
the purpose of collecting relevant information on the multicast
streams delivered to EUs in AD-2.
3.5. AD-2 Not Multicast Enabled - Multiple AMT Tunnels through AD-2
Figure 5 illustrates a variation of Use Case 3.4: ------------------- ------------------- / AD-1 \ / AD-2 \ / (Multicast Enabled) \ / (Not Multicast \ / +---+ \ (I1) / +---+ Enabled) \ | +----+ |uBR|-|--------|-|uBR| | | | | +--+ +---+ | | +---+ +---+ | +----+ | | AS |-->|AR|<........|.... | +---+ |AG/|....>|EU/G| | | | +--+ | ......|.|AG/|..........>|AR2| |I3 +----+ \ +----+ / I1 \ |AR1| I2 +---+ / \ / Single \+---+ / \ / AMT Tunnel \ / ------------------- ------------------- uBR = unicast Border Router - not multicast enabled; also, either AR = uBR (AD-1) or uBR = AGAR1 (AD-2) AS = multicast (e.g., content) Application Source AR = AMT Relay in AD-1 AGAR1 = AMT Gateway/Relay node in AD-2 across peering point I1 = AMT tunnel connecting AR in AD-1 to gateway in AGAR1 in AD-2 AGAR2 = AMT Gateway/Relay node at AD-2 network edge I2 = AMT tunnel connecting relay in AGAR1 to gateway in AGAR2 EU/G = Gateway client embedded in EU device I3 = AMT tunnel connecting EU/G to AR in AGAR2 Figure 5: AMT Tunnel Connecting AMT Gateways and Relays Use Case 3.4 results in several long AMT tunnels crossing the entire network of AD-2 linking the EU device and the AMT relay in AD-1 through the peering point. Depending on the number of EUs, there is a likelihood of an unacceptably high amount of traffic due to the large number of AMT tunnels -- and unicast streams -- through the peering point. This situation can be alleviated as follows: o Provisioning of strategically located AMT nodes in AD-2. An AMT node comprises co-location of an AMT gateway and an AMT relay. No change is required by AD-1, as compared to Use Case 3.4. This can be done whenever AD-2 sees fit (e.g., too much traffic across the peering point). o One such node is on the AD-2 side of the peering point (AMT node AGAR1 in Figure 5).
o A single AMT tunnel established across the peering point linking
the AMT relay in AD-1 to the AMT gateway in AMT node AGAR1
in AD-2.
o AMT tunnels linking AMT node AGAR1 at the peering point in AD-2 to
other AMT nodes located at the edges of AD-2: e.g., AMT tunnel I2
linking the AMT relay in AGAR1 to the AMT gateway in AMT
node AGAR2 (Figure 5).
o AMT tunnels linking an EU device (via a gateway client embedded in
the device) and an AMT relay in an appropriate AMT node at the
edge of AD-2: e.g., I3 linking the EU gateway in the device to the
AMT relay in AMT node AGAR2.
o In the simplest option (not shown), AD-2 only deploys a single
AGAR1 node and lets the EU/G build AMT tunnels directly to it.
This setup already solves the problem of replicated traffic across
the peering point. As soon as there is a need to support more AMT
tunnels to the EU/G, then additional AGAR2 nodes can be deployed
by AD-2.
The advantage of such a chained set of AMT tunnels is that the total
number of unicast streams across AD-2 is significantly reduced, thus
freeing up bandwidth. Additionally, there will be a single unicast
stream across the peering point instead of, possibly, an unacceptably
large number of such streams per Use Case 3.4. However, this implies
that several AMT tunnels will need to be dynamically configured by
the various AMT gateways, based solely on the (S,G) information
received from the application client at the EU device. A suitable
mechanism for such dynamic configurations is therefore critical.
Architectural guidelines for this configuration are as follows:
Guidelines (a) through (c) are the same as those described in
Use Case 3.1. In addition,
d. It is necessary that proper procedures be implemented such that
the various AMT gateways (at the EU devices and the AMT nodes in
AD-2) are able to find the correct AMT relay in other AMT nodes
as appropriate. Standard mechanisms for that selection are still
subject to ongoing work. This includes the use of anycast
gateway addresses, anycast DNS names, or explicit configuration
that maps (S,G) to a relay address. On the EU/G, this mapping
information may come from the application.
e. The AMT tunnel's capabilities are expected to be sufficient for
the purpose of collecting relevant information on the multicast
streams delivered to EUs in AD-2.
(next page on part 2)