Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 8313

BCP 213
Pages: 44
Top     in Index     Prev     Next
in Group Index     Prev in Group     No Next: Highest Number in Group     Group: MBONED

Use of Multicast across Inter-domain Peering Points

Part 1 of 3, p. 1 to 17
None       Next Section

 


Top       ToC       Page 1 
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 Points

Abstract

   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.

Top      ToC       Page 2 
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.

Top       Page 3 
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

Top      ToC       Page 4 
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")

Top      ToC       Page 5 
         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

Top      ToC       Page 6 
      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.

Top      ToC       Page 7 
   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.

Top      ToC       Page 8 
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.

Top      ToC       Page 9 
   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.

Top      ToC       Page 10 
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.

Top      ToC       Page 11 
   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

Top      ToC       Page 12 
       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.

Top      ToC       Page 13 
   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.

Top      ToC       Page 14 
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.

Top      ToC       Page 15 
   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.

Top      ToC       Page 16 
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).

Top      ToC       Page 17 
   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 Section