SIN 503

Issue 1.4
December 2018

Suppliers' Information Note

For The BT Network

Generic Ethernet Access

Multicast
Service & Interface Description

Each SIN is the copyright of British Telecommunications plc. Reproduction of the SIN is permitted only in its
entirety, to disseminate information on the BT Network within your organisation. You must not edit or amend
any SIN or reproduce extracts. You must not remove BT trade marks, notices, headings or copyright markings.
This document does not form a part of any contract with BT customers or suppliers.
Users of this document should not rely solely on the information in this document, but should carry out their
own tests to satisfy themselves that terminal equipment will work with the BT network.
BT reserves the right to amend or replace any or all of the information in this document.
BT shall have no liability in contract, tort or otherwise for any loss or damage, howsoever arising from use of, or
reliance upon, the information in this document by any person.
Due to technological limitations, a very small percentage of customer interfaces may not comply with some of
the individual characteristics, which may be defined in this document.
Publication of this Suppliers' Information Note does not give or imply any licence to any intellectual property
rights belonging to British Telecommunications plc or others. It is your sole responsibility to obtain any
licences, permissions or consents which may be necessary if you choose to act on the information supplied in
the SIN.

This SIN is available in Portable Document Format (pdf) from: http://www.btplc.com/sinet/

Enquiries relating to this document should be directed to: sinet.helpdesk@bt.com

 British Telecommunications plc

Registered Office 81 Newgate Street LONDON EC1A 7AJ
Registered in England no.1800000
CONTENTS
1. INTRODUCTION ....................................................................................................................................... 3

2. SERVICE OUTLINE ................................................................................................................................. 3

2.1 GENERAL ....................................................................................................................................................... 3
2.2 SERVICE AVAILABILITY ................................................................................................................................. 3
3. INTERFACE DESCRIPTIONS ................................................................................................................ 4
3.1 GEA-CABLELINK .......................................................................................................................................... 4
3.1.1 Multicast VLAN tagging ...................................................................................................................... 4
3.1.2 Multicast VLAN bandwidths ................................................................................................................ 4
3.1.3 Ethernet OAM ...................................................................................................................................... 4
3.1.4 Bridging Loops .................................................................................................................................... 4
3.1.5 Downstream priority marking ............................................................................................................. 5
3.1.6 GEA Data Downstream shaping ......................................................................................................... 5
3.1.7 IGMP Operation - CP side .................................................................................................................. 5
3.2 USER NETWORK INTERFACE (UNI) ............................................................................................................... 6
3.2.1 General ................................................................................................................................................ 6
3.2.2 IGMP Operation - User Side ............................................................................................................... 6
3.3 MULTICAST OPERATION - GENERAL .............................................................................................................. 7
3.4 RECOMMENDATIONS FOR RESIDENTIAL GATEWAY IMPLEMENTATION .......................................................... 8
3.4.1 Known limitations ................................................................................................................................ 8
4. REFERENCES ............................................................................................................................................ 9

5. ABBREVIATIONS ................................................................................................................................... 10

6. HISTORY .................................................................................................................................................. 10

SIN 503 Issue 1.4  British Telecommunications plc Page 2 of 11

1. Introduction
The Openreach Next Generation Access (NGA) portfolio provides high bit rate access
solutions utilising fibre and existing copper based infrastructure as described in STIN501 and
SIN498 [4].
This document describes the enhancement to these products to support a Multicast services
capability. Specifically, this document provides details relevant to CPs regarding multicast
protocols, operation and features.
This Suppliers’ Information Note (SIN) provides details relevant to CPs regarding connectivity
and interfaces.
The publication of this SIN does not commit Openreach to a commercial launch of any
new/changed service, nor does it commit Openreach to the particular implementation described
within this document. Should Openreach decide to commence a roll-out of the trialled
engineering implementation, the matters pertaining to this SIN will be reflected in an update
to the relevant Suppliers Information Notes (SINs) and the publication of the necessary Service
Provider Information Notes (SPINs).
It should be noted that the information contained within this SIN might be subject to change
due to either the results of BT developments, testing or due to feedback from customers. Please
check with the http://www.sinet.bt.com site to ensure you have the latest version of this
document.
Users of this document should not rely solely on the information contained in it, but should
carry out their own tests to satisfy themselves that terminal equipment will work with the BT
network
Further information regarding the product trial and pilot product launch can be obtained by
contacting your Openreach Sales & Relationship Manager.

2. Service Outline
2.1 General
Openreach provides the Multicast product, a Next Generation Access (NGA) product, at GEA-
FTTP and GEA-FTTC locations.

2.2 Service Availability

Openreach provides Generic Ethernet Access on Fibre to the Cabinet (GEA-FTTC) and Fibre
to the Premises infrastructure (GEA-FTTP). Multicast is available at all deployed and released
Layer 2 Switches (L2S).

SIN 503 Issue 1.4  British Telecommunications plc Page 3 of 11

3. Interface Descriptions

3.1 GEA-Cablelink
Unless otherwise stated, the existing FTTx NGA SINs apply and are not repeated herein.
Multicast is supported by a dedicated Multicast VLAN over one, and only one, GEA-Cablelink
interface per CP per L2S. This Multicast VLAN provides isolation between different CPs and
their users in all aspects of multicast operation including layer 2 and layer 3.
The Ethertype of the GEA-Cablelink as a whole is configurable as described in existing FTTx
SINs. The outer VLAN Ethertype configured shall also apply to the Multicast VLAN.
The Multicast VLAN shall carry the media streams (multicast channels) downstream from the
CP and IGMP messaging to and from the NGA network.

3.1.1 Multicast VLAN tagging

The Multicast VLAN is single tagged (IEEE 802.1Q).
The Multicast VLAN will have a VLAN ID in the range 3001 to 3070.
The CP cannot specify the ID to be added; Openreach will allocate the lowest available unused
tag ID. This will be in the range 3001-3070.
Note - It is not possible to change the VLAN tag ID once the Multicast VLAN has been ordered.
CPs should note that multicast traffic from the Modem/ONT will be untagged.

3.1.2 Multicast VLAN bandwidths

Multicast VLANs will be available at discrete bandwidths. These will be available in the range
of 0Mbit/s to 860Mbit/s, between 0Mbit/s and 200Mbit/s, there is an increment of 5Mbit/s,
between 200Mbit/s and 500Mbit/s, and there is an increment of 10Mbit/s. Beyond 500Mbit/s
the increments are of 20Mbit/s. The bandwidth will be policed on ingress at the L2S.
NB - 1Mbit/s = 1,000,000 bits/s

3.1.3 Ethernet OAM

Ethernet OAM is not supported on multicast VLAN.

3.1.4 Bridging Loops

To prevent MAC table corruption and bridging loops, CPs should avoid reflecting L2 frames
back into the Openreach network.

SIN 503 Issue 1.4  British Telecommunications plc Page 4 of 11

3.1.5 Downstream priority marking
All Multicast traffic will be given higher priority than all Data traffic from the GEA Cablelink
to the ONT / DSLAM. It will, however, be given a lower priority than the FVA traffic.
CPs are advised to set the VLAN priority of the Multicast traffic (media and IGMP) to 802.1p
level 3.
Openreach will remark downstream Multicast traffic to level 3.
The priority range of GEA data C-VLAN is 0-4. This gives the CP control of the Data traffic
priority such that selected delay sensitive applications can be promoted above Multicast. This
prioritisation applies only at the downstream egress queue at DSLAM line card and within
ONT; through the OLT, Multicast is always prioritised above data.

3.1.6 GEA Data Downstream shaping

In order to maintain the best possible jitter performance to both Multicast and GEA Data
streams, CPs are urged to shape media streams on a per channel basis as opposed to simply
shaping the aggregate of the channel streams.
Openreach will not provide any form of messaging to the CP with regard to bandwidth
consumed by Multicast for GEA. CPs are encouraged to consider their own solution to ensure
they can manage both the Multicast and Data services according to the available downstream
rate.

3.1.6.1 GEA-FTTC
The Multicast plus Data downstream bandwidth available to FTTC served users is constrained
by the capabilities of the physical access line.
End Users consuming Multicast for GEA will incur reduced bandwidth available to GEA Data
owing to the higher priority of Multicast traffic.

3.1.6.2 GEA-FTTP
The Multicast plus Data downstream bandwidth available to FTTP served users is expected to
be controlled by CPs to be within the peak downstream bandwidth ordered for the GEA Data
service. Openreach will not at this stage enforce this, but reserves the right to do so in future.
Until Openreach enforces the sum of Multicast and Data traffic remaining within the peak
downstream bandwidth ordered, the CP will be responsible for ensuring that sum of the traffic
can be handled correctly by their CPE.

3.1.7 IGMP Operation - CP side

Openreach will control the excessive unauthorised rate of flow of Ethernet multicast frames by
utilising IGMP messages from CPE equipment and report these to the CP interface via a proxy
agent. Therefore when multiple users request to join a particular group the CP will see only
the first IGMP join to that group and the last IGMP leave from that group. The CP will have

SIN 503 Issue 1.4  British Telecommunications plc Page 5 of 11

no visibility of the original user’s IGMP message either via the Multicast VLAN or Data
VLAN.
IGMP Membership Queries from the CP to the GEA network must avoid using an IP header
source address in the same range as that used for GEA element management. Specifically
address range 10.0.0.0/8 should be avoided. Note that additional management reserved ranges
are likely to be needed by Openreach in future. It is recommended CPs avoid using addresses
in this range to ensure their Query messages are not ignored.
The Openreach GEA network will support IGMPv3 as defined by RFC3376 except for known
limitations, as described in section 3.3.2. Note that IGMPv3 includes backward compatibility
to IGMPv2. IGMPv1 messages are not supported.
The IGMPv3 membership reports proxied by the L2S to the CP interface will have an IP header
source of 0.0.0.0. Note: Should this prove not to be possible for the trial, Openreach may need
to choose a non-zero address initially.

3.2 User Network Interface (UNI)

3.2.1 General
When a CP orders Multicast for GEA on an L2S, Openreach will enable that capability to all
their GEA Data services served by that L2S. It will not be possible to selectively enable
Multicast on a per GEA Data service basis. All subsequent end users will be enabled for the
Multicast capability as part of their GEA Data order.
A GEA Data service can only be served with Multicast traffic from the Multicast VLAN owned
by their CP.
Initially, Openreach will only support Multicast on the first data port on GEA-FTTP. Further
support will be made available in due course.
End Users of CPs that have a Multicast VLAN on their L2S will no longer be transparent to
IGMP over IP over GEA Data; these packets will be intercepted by Openreach to support the
Multicast for GEA service.
Openreach will prevent users injecting traffic into the Multicast VLAN; therefore no user-to-
user communication is possible through multicast group membership.

3.2.2 IGMP Operation - User Side

As stated in the IGMP specification [2], there will be no acknowledgement that Openreach or
the CP has accepted a membership join report or that a media stream exists for the group and
is being sent.
Openreach will employ “fast leave” mode of IGMP. The benefit is most apparent when an
FTTC served user changes from one channel stream to another. By immediately cutting the
stream of the unwanted channel, the downstream bandwidth is released for the new channel
and other services sharing the downstream bandwidth.
Openreach will operate in IGMP snooping mode with proxy agent. CPE should therefore
expect and should respond to IGMPv2 and IGMPv3 query messages from the proxy agent
having a source IP address of 0.0.0.0. Note: Should this prove not to be possible for the trial,
Openreach may need to choose a non-zero address initially.

SIN 503 Issue 1.4  British Telecommunications plc Page 6 of 11

It is recommended that CPs are familiar with Residential gateway requirements to support
Multicast as set out in the broadband forum’s guidance in TR101 and TR156, available at
www.broadband-forum.org/.

3.2.2.1 IGMP encapsulation

IGMP messages intended for the Openreach Multicast service must be sent asIGMP over IP.
IGMP messages sent as IGMPoPPPoE will be passed through transparently to the CP and will
not be acted on by Openreach.
In the case of GEA-FTTP and GEA-FTTC with a white Openreach modem IGMP messages
can be tagged with VLAN ID 0 (zero) by the CPE in order to set a preferred 802.1p value
upstream. A VLAN tag with an ID of 0 will be removed by the ONT and white Openreach
modem but the 802.1p value will be used to ensure the desired upstream scheulding of the
IGMP messages on to the PON and VDSL line respectively.
Further information on upstream VLAN tagging can be found in SIN498 [6] and SIN506 [7]
for FTTC (including wires only) and FTTP respectively.

3.2.2.2 IGMP upstream prioritisation

To ensure IGMP upstream packets are treated with the highest available scheduling priority,
the CPE should set the IEEE 802.1p priority field to 3 or above. For GEA_FTTP and GEA-
FTTC with a white Openreach modem this is done using VLAN 0 as described above. For
wires only GEA-FTTC it is the responsibility of the CPE to schedule IGMPs appropriately
directly on to the VDSL line.
Further information on upstream priority can be found in SIN498 [6] and SIN506 [7] for FTTC
(including wires only) and FTTP respectively.

3.2.2.3 IGMP use limitations

Openreach will impose a limit to the total number of groups a UNI is permitted to join
simultaneously, sixteen or less group memberships will be permitted irrespective of their
bandwidth.
There will be a finite limit to the rate of IGMP messages that Openreach will process. This
limit is still to be determined but will be set at a level not less than 10 IGMP packets per second.

3.3 Multicast Operation - General

Openreach will support IPv4 multicast only.
Except for the following restrictions stated, Openreach will accept membership join reports to
all groups; there is no support within Openreach network to accept or deny joins based on
bandwidth allocation or group addresses permitted to a user or their CP.
Openreach will use a common multicast GEM for distribution of downstream multicast content
over GPON. Openreach does not encrypt this content. All ONTs attached to the PON receive
this content. The Openreach ONT will only forward this content to UNIs that have a valid
membership join.
Openreach will support IP multicast group addresses in the range 225.0.0.0 to
239.255.255.255. The range 224.0.0.0/24 reserved range will not be accepted in accordance
with IANA rules.

SIN 503 Issue 1.4  British Telecommunications plc Page 7 of 11

Irrespective of source specific multicast service model implied by the use of IGMPv3,
Openreach will not enforce the use of SSM destination addresses (232.0.0.0/8) as defined by
RFC3376 (IGMPv3). Likewise there is no special treatment or restriction of the GLOP address
range defined by RFC2770.
GEA will replicate multicast streams according to destination MAC address. Since the
multicast MAC address is derived from the IP group address, CPs must ensure IP group
addresses are unique when a 23 bit mask is applied.
Because IGMPv3 includes backward compatibility to IGMPv2, any host sending an IGMPv2
report will cause the Openreach interface to revert to v2 mode and will initiate an immediate
IGMPv2 query to other hosts attached to that interface, thus causing those hosts to revert to
IGMPv2 mode. The scope of the Openreach interface for FTTC is the modem UNI and
attached LAN. For FTTP the interface scope is all ONT UNIs (and their attached LANs)
common to that CP on the same PON.
3.3.1 Recommendations for Residential Gateway implementation
Most networked home devices will generate IGMP in relation to uPNP (SSDP) potentially
causing unnecessary MAC learning and IGMP processing load on the DSLAM line port.
IGMP proxy as described in RFC4605 provides effective layer 2 and layer 3 isolation between
the home environment and the Openreach NGA platform. The benefits of IGMP proxy
include:
 Source MAC addresses from numerous LAN hosts are not visible to the Openreach
network thus eliminating risk of the limited MAC learning table becoming exhausted.
 Reduction in IGMP report flows to the upstream device (Openreach DSLAM or
OLT). If the number of IGMP devices in the home is excessive, a high volume of
IGMP from uPNP (SSDP protocol) and other non-TV multicast operating system
services could impact user experience in terms of reliability when changing TV
channels. Group address filtering of non-TV IGMP reports within the residential
gateway is also recommended for the same reason.
 Multicast for GEA generates and receives IGMP. This layer 3 protocol conveys
parameters such as source IP address and timer values all of which are a potential
source of interworking issue. The risk of interworking issues can be reduced, or the
level of end to end testing complexity can be reduced if IGMP proxy is implemented.
With the isolation provided by proxy working, variants of STB need only be tested
against variants of residential gateway and variants of residential gateway against
variants of DSLAM. With IGMP bridging/snooping, of all permutations of DSLAM,
residential gateway and STB variants would be necessary to ensure service reliability.
 In accordance with broadband forum TR101, a VDSL port that is Multicast for GEA
enabled will not relinquish elected IGMP querier status. If other multicast routing
devices are present in the home or CP data network, this could be problematic without
careful consideration at the design stage. IGMP proxy offers an ideal solution.

3.3.2 Known limitations

RFC3376 for IGMPv3 details support for source filtering, that is, the ability for a system to
report interest in receiving packets ‘only’ from specific source addresses, as required to support

SIN 503 Issue 1.4  British Telecommunications plc Page 8 of 11

Source-Specific Multicast [SSM], or from ‘all but’ specific source addresses, sent to a
particular multicast address. Openreach will not support the “‘all but’ specific source
addresses” requirement. Specifically, If GEA receives IGMPv3 report of To_EXclude
({X},G), or Is_EXclude ({X},G), meaning join to group G except from source X (or multiple
sources listed), the membership report will be silently ignored by Openreach. If an empty list
is provided, the report will be accepted and acted upon.

MAC learning of end user IGMP over Ethernet is enabled for Multicast for GEA. The CP
Hand-over Port is restricted to a Maximum 8 MAC addresses. Once this MAC limit has been
reached, learning of additional MAC addresses is disabled and frames from unknown sources
are dropped on entry to the Openreach head end. The aging time for MAC addresses in the
table is 300 seconds; once a source is no longer transmitting traffic its MAC address is removed
from the table after this period. Typically, CP’s will forward multicast traffic to the NGA head
end via one or two edge routers. If this is the case, the restriction of 8 MAC addresses will not
be an issue. The MAC address restriction applies to only certain Openreach head ends
depending on the vendor of the equipment.

MAC learning of end user IGMP over Ethernet is enabled for Multicast for GEA. This only
applies if their associated CP is Multicast for GEA enabled. VDSL ports are restricted to a
maximum 8 MAC addresses. Once the MAC limit has been reached, learning of additional
MAC addresses is disabled and frames from unknown sources are dropped. The aging time
for MAC addresses is 300 seconds. Typically, all traffic originating from the end user will be
via a layer 3 gateway device in the end user premises. Source MAC addresses from various
home computers and networked devices could propagate through the residential gateway
depending on the type of IGMP implementation. It is highly recommended that RG’s
supporting Multicast for GEA implement IGMP proxy as described in RFC4605 as opposed to
forms of IGMP bridging/snooping similar to that described in RFC4541. See section 2.2.2.
for a description of the benefits and impacts of not using IGMP proxy. The MAC address
restriction applies to only certain Openreach DSLAMs depending on the vendor of the
equipment.

4. References
[1] Reserved multicast addresses http://www.iana.org/assignments/multicast-addresses
[2] RFC3376 (IGMPv3) http://www.rfc-editor.org/rfc/rfc3376.txt
[3] RFC2770 (GLOP Addressing) http://www.rfc-editor.org/rfc/rfc2770.txt
[4] Openreach NGA FTTC and FTTP interface specification http://www.btplc.com/sinet/
[5] IEEE 802.1Q http://www.ieee802.org/
[6] SIN498 Fibre to the Cabinet (FTTC) Generic Ethernet Access Service and Interface
Description http://www.btplc.com/sinet/
[7] SIN506 Fibre to the Premises (FTTP) Generic Ethernet Access, Service and Interface
Description http://www.btplc.com/sinet/

SIN 503 Issue 1.4  British Telecommunications plc Page 9 of 11

5. Abbreviations

CP Communications Provider
CPE Customer Premises Equipment
CVLAN Customer VLAN
FTTC Fibre to the Cabinet
FTTP Fibre To The Premise
GEA Generic Ethernet Access
GEM Generic Event Manager
GPON Gigabit Capable Passive Optic Network
ID Identifier
IEEE Institute of Electrical and Electronics Engineers
IGMP Internet Group Management Protocol
L2S Layer 2 Switch
NGA Next Generation Access
NTE Network Termination Equipment
OAM Operations, Administration, Maintenance
OLT Optical Line Termination
ONT Optical Network Termination device
PON Passive Optic Network
PPPoE Point to Point Protocol over Ethernet
SIN Suppliers’ Information Note (BT Publication)
SSM Source-Specific Multicast
VLAN Virtual Local Area Network
SVLAN Service VLAN
UNI User Network Interface

6. History

Issue Date Changes

Issue 0.1 18/06/2010 Initial text provided.
Issue 1.0 September 2012 Initial text reviewed and amended to reflect product status.
Issue 1.1 January 2013 Updated as a result of the maximum bandwidth for Multicast
up from 300Mbps to 500Mbps (as a result of additional

SIN 503 Issue 1.4  British Telecommunications plc Page 10 of 11

 capability) with additional information on Max MAC settings
and additional Residential Gateway settings advice.
Issue 1.2 November 2013 Update to section 3.2.2.1 around IGMP encapsulation
behaviour.
Issue 1.3 January 2015 Update to section 3.1.2 Multicast VLAN bandwidths
Change SINet site references from http://www.sinet.bt.com to
http://www.btplc.com/sinet/
Issue 1.4 December 2018 Update to section 3.2.2 IGMP Operation - User Side
Additional clarification text

-END-

SIN 503 Issue 1.4  British Telecommunications plc Page 11 of 11