Service Requ

Service Configuration & Management Framework and Requirements for Alphion GPON System
Service Configuration & Management Framework and Requirements for Alphion

GPON System
Document number: 191-0000113

Revision number: 1.0
Document status: Baseline
ECO number: ECO-000636
Effective date: April 26, 2010
Document author(s): Janar Thoguluva
Document keywords: Services, Provisioning, AOLT, AONT, GPON, TR-156
This document contains information that is proprietary to Alphion Corporation. No part of its contents may be used, copied,
disclosed, or conveyed to any third party in any manner whatsoever without prior written permission from Alphion
Corporation.
© Copyright 2010 by Alphion Corporation. All rights reserved.
Alphion Corporation Proprietary and Confidential Page 1 of 56

Controlled Document under Alphion Document Management System (ADMS)
Disclaimers
1. MR against SRD
Some of the requirements specified in this SRD revision may be superseded by MRs issued by Alphion’s problem
reporting system. Outstanding MRs written against this SRD will be incorporated in Alphion’s test management tool and
will be added in the subsequent revision of the SRD and/or ERD. Therefore, to be sure that you have the latest view of
any requirement requires having the latest revision of the SRD and ERD, a list of associated resolved MRs against these
requirements and/or access to Alphion’s test management tool.
Resolving MRs against SRD always requires updating baseline SRD and/or baseline ERD in Omnify.
2. Companion ERD
Each SRD shall have a companion Engineering Response Document (ERD). The ERD indicates in which system and/or
software release each requirement will be implemented and tested. The system and/or software release shall include the
release number and release date.
Requirement ID format
The requirement identification number is composed of the following items:

Omnify document number sans preceding zeros + requirement type + document section + 4-digit sequence number
The requirement types used in this document are:

R – Mandatory requirement; unless superseded or deleted via an approved MR.
O – Objective requirement; should be strongly considered and may become mandatory in the future release.
W – Waived requirement; applicable but waived for the baseline revision.

Revision History
Revision Author Reviewed By Description Of Change Issued by / Issue

# Summary of Review Date
0.1 Janar T SD&E, SW dev. New draft; Non-profiles version of the originally proposed profiles- Janar T /
and SVT teams based R2.x framework. March 21, 2010
(See Review
Notes for the
individuals list)
1.0 Janar T ,, • Incorporated review comments per review on 03/29/10 and Janar T / Apr. 27,
(candidate) 04/6/10, including: 2010
• Added Req. id for individual parameters
• Split service type-specific table into 2 tables, one for per-
service-instance parameters and the other for service activation
parameters
• Rephrased/reorganized some of the subsections in sections 6-9
for more clarity
• Added standard boiler-plate text on 1st page, and filled in the
ERD form in the appendix
1.0 Janar T Frank S.; Yuji H.; Based on discussions on May 06, 2010, and on May 07, 2010: Janar T / May 20,
Kasturi R.; • Grouped service instance and service activation parameters, 2010
Anjaneya S.; where appropriate, into “basic” and “advanced” parameters
Mano S.; • Defined U/S-D/S value combinations for VLAN tag (VID, P-
Vijayanandham bits and TPID) for the VLAN Handling models
K. • Added ‘priority level’ for traffic flows in the D/S dir
• Added the Best Effort priority and weight parameters for T-
CONTs
• Reworded text in the U/S and D/S VLAN Handling parameters
table
• Moved the following B-IPTV service related parameters from
the per-B-IPTV service instance (VID) parameters table to the
B-IPTV service activation parameters table: ‘Allow/Discard user
IGMP messages’, ‘IGMP snooping Immediate Leave function at
ONT/ONU’ and ‘U/S IGMP message rate limit at ONT/ONU’

Table of Contents
1 INTRODUCTION...................................................................................................................................................................................... 6
1.1 REQUIREMENT CATEGORIES/PRIORITIES ........................................................................................................................................ 6
1.2 DEFINITIONS .................................................................................................................................................................................... 6
2 SYSTEM ABSTRACTION....................................................................................................................................................................... 7
2.1 GPON SYSTEM ABSTRACTION ........................................................................................................................................................ 7
3 CONFIGURATION AND MANAGEMENT OVERVIEW .................................................................................................................. 7
4 SERVICES OVERVIEW .......................................................................................................................................................................... 8
4.1 SERVICE TYPES................................................................................................................................................................................ 8
5 SERVICE PROVISIONING ..................................................................................................................................................................... 9
6 SERVICE MODELS & VLAN HANDLING.......................................................................................................................................... 9
6.1 OVERVIEW ....................................................................................................................................................................................... 9
6.2 SERVICE MODELS (OR VLAN FORWARDING MODELS) ................................................................................................................ 10
6.3 VLAN HANDLING REQUIREMENTS .............................................................................................................................................. 11
7 UPSTREAM QOS.................................................................................................................................................................................... 26
7.1 ONT/ONU UPSTREAM SERVICE TRAFFIC DESCRIPTOR (TD) PARAMETER-GROUP................................................................... 26
8 GENERAL SERVICE CONFIGURATION & MANAGEMENT REQUIREMENTS ..................................................................... 31
9 SERVICE TYPE-SPECIFIC PARAMETERS....................................................................................................................................... 32
9.1 HSI SERVICE.................................................................................................................................................................................. 32
9.2 VOICE SERVICE.............................................................................................................................................................................. 36
9.3 BROADCAST-IPTV SERVICE ......................................................................................................................................................... 38
9.4 TLS SERVICE ................................................................................................................................................................................. 44
9.5 VIDEO ON DEMAND (VOD) SERVICE............................................................................................................................................ 46
9.6 EXTERNAL-VOIP SERVICE ............................................................................................................................................................ 46
10 REFERENCES..................................................................................................................................................................................... 46
11 ACRONYMS, ABBREVIATIONS AND DEFINITIONS............................................................................................................... 47
12 PLANNED FOR FUTURE RELEASES............................................................................................................................................ 49
I.1 AOLT FUNCTIONAL ABSTRACTION .............................................................................................................................................. 50
I.1.1 SWITCH AND TIMING (SWT) CARD .............................................................................................................................................. 50
I.1.2 GPON LINE CARD (GLC)............................................................................................................................................................. 51
GPON OLT subsystem ........................................................................................................................................................................ 51
I.1.3 ALPHION OPTICAL NETWORK TERMINAL/UNIT (AONT) ........................................................................................................... 52
List of Figures
FIGURE 1: TR-156 GPON ACCESS NODE .......................................................................................................................................................... 7
FIGURE 2: CONFIGURATION AND MANAGEMENT FLOW .................................................................................................................................... 8
FIGURE 3: AOLT FUNCTIONAL ABSTRACTION ................................................................................................................................................. 50
FIGURE 4: GLC OLT SUBSYSTEM FUNCTIONAL OVERVIEW............................................................................................................................ 51
FIGURE 5: FUNCTIONAL OVERVIEW OF ONT................................................................................................................................................... 52

List of Tables
TABLE 1: SERVICE TYPES .................................................................................................................................................................................... 9
TABLE 2: CORE SERVICE MODELS ................................................................................................................................................................... 10
TABLE 3: U/S VLAN HANDLING PARAMETERS............................................................................................................................................... 13
TABLE 4: DOWNSTREAM VLAN HANDLING PARAMETERS............................................................................................................................. 16
TABLE 5: SERVICE MODEL TO VLAN HANDLING PARAMETERS MAPPING ..................................................................................................... 19
TABLE 6: SERVICE MODELS – POINTS OF VLAN HANDLING WITHIN THE ALPHION GPON SYSTEM............................................................ 21
TABLE 7: ONT/ONU UPSTREAM SERVICE TRAFFIC DESCRIPTOR PARAMETER GROUP ................................................................................ 27
TABLE 8: HSI SERVICE (PER-SERVICE INSTANCE) PARAMETERS .................................................................................................................... 33
TABLE 9: HSI SERVICE ACTIVATION PARAMETERS ......................................................................................................................................... 34
TABLE 10: VOICE SERVICE (PER-SERVICE INSTANCE) PARAMETERS .............................................................................................................. 36
TABLE 11: VOICE SERVICE ACTIVATION PARAMETERS ................................................................................................................................... 37
TABLE 12: BROADCAST-IPTV SERVICE (PER-SERVICE INSTANCE) PARAMETERS.......................................................................................... 39
TABLE 13: BROADCAST-IPTV SERVICE ACTIVATION PARAMETERS .............................................................................................................. 41
TABLE 14: BROADCAST-IPTV USER PORT PARAMETERS ................................................................................................................................ 44
TABLE 15: TLS SERVICE (PER-SERVICE INSTANCE) PARAMETERS.................................................................................................................. 45
TABLE 16: TLS SERVICE ACTIVATION PARAMETERS ...................................................................................................................................... 45

1 Introduction
This document first presents the TR-156 abstracted view of the Alphion GPON system, including the AOLT and the
AONT systems. Based on this abstracted view, this document devises a flexible services framework that shall be used
starting from R2.0 for provisioning and activating different types of services on different AONT types.
The intended audiences of this document are the NE- and EMS- software development teams and the system verification
team. This document is based on the different standards that pertain to GPON services, including TR-156[9], TR-101
[10], and G.984.4 [4], and on the G.984.4 Implementation Guide [8]. As such, a major goal of this document is to guide
the software design and implementation of the service provisioning software framework so that the Alphion GPON
system is fundamentally compliant with the provisioning models proposed in these standards.
This document is based on the original profile-based provisioning framework that was initially proposed for R2.0. Profile-
based provisioning has advantages to the operator of applying to a large number of subscribers the same set of
configuration settings with regards to the different resources of the GPON system and to the services realized over them.
However, as an intermediate step, a non-profile-based provisioning framework is described in this document for R2.0 that
shall evolve to the said original profile-based service provisioning framework post-R2.0. Although this intermediate
provisioning framework is not based on profiles, it includes requirements to support the TR-156 requirements, including
three core VLAN models.
The actual software releases in which the requirements in this document are met shall be specified in the ERD
(Engineering Response Document) for this document.
1.1 Requirement categories/priorities
With regard to the relative priority of requirements in this document, the desired target release from a product
availability/roadmap point of view is decoupled from the absolute release number (e.g., 1.4.1, 1.4.2, etc.) in which the
requirements will actually be met. The desired target release is specified using the requirement priority defined in the table
below. The absolute release number shall be specified in, or derived from, the ERD (Engineering Response Document)
document(s) that shall be generated (by the development team) in response to this requirements document. Also, for the
requirements in this document that are already supported by the AOLT system in the 1.3 or earlier releases, the ERD shall
indicate as such.
Requirement Description
priority
CI Controlled Introduction (Beta release) - includes absolute minimum, i.e. MUST,
requirements/features required for initial introduction
GA General Availability - includes features/requirements that are basic, i.e. MUST, for
the system/product to perform intended function in real field deployments
FC Future Competitive - includes features that our competitors have/will have and
those that will be required for entering potential future markets
VA Value Add - includes features sellable as a price-able option for additional revenue
1.2 Definitions
Provided below are definitions of some of the terminology used in the framework defined in this document:
GPON Access Node or Access Node: In-line with TR-156, GPON Access Node represents the GPON equivalent of the
Access Node as defined in TR101 [10] , with the functions distributed between the AOLT and the AONT.
PON port: represents a GPON MAC/TC layer interface on the AOLT (GLC card).
GPON layer connection or GPON connection: A technology-neutral term for a bi-directional GEM port, this term
represents a logical connection within a given PON, between the associated PON port in the OLT and a specific UNI port
in a specific ONT on that PON. A GPON connection is used to transport one or more subscriber traffic flows associated
with a single traffic class for a specific UNI port.
PON connection group/bundle: the group of all bidirectional GEM connections, including those of all traffic classes,
between a PON port and a specific UNI port on a specific ONT on that PON. For N:1 VLANs, wherein MAC learning is
required on the OLT, a connection group serves as a logical bridge port or flow-id that is learned in the upstream direction
and is looked up for in the downstream direction. In the downstream direction, the actual PON connection within a

connection group (the final GEM port-id) out which the downstream frame is sent on the PON port is derived from the
connection group and the priority associated with the frame.
VLAN tag: the entire VLAN tag comprising the TPID (Tag Protocol ID), the 802.1p bits, and the VLAN ID.
VID or VLAN id: the VLAN ID part of a VLAN tag.
Traffic Class (TC): A TC is a forwarding behavior within the AOLT and AONT; see Definitions section of TR-156 for
more details.
Also, in the context of this document, the terms ‘SFU’, ‘SBU’, ‘MDU’ imply all supported models of that AONT family;
exceptions, that is, requirements or descriptions specific to a particular model within an AONT family, are pointed out
where required. An overview of the different AONT types and models, including the variety and number of the different
UNI ports supported, is provided in the Release-2 planning sheet [13]1.
2 System Abstraction
2.1 GPON system abstraction
The TR-156 abstracted view of the Alphion GPON system, comprising the AOLT and the associated AONTs, is shown in
Figure 1. The GPON Access Node, as defined in TR-156, provides adaptation between GPON and Ethernet at the AOLT,
and adaptation between GPON and subscriber interfaces such as Ethernet and xDSL at the AONT. The abstraction of the
AOLT and the AONTs as a GPON Access Node simplifies service provisioning considerably for the operator, as will be
seen later. Appendix I of this document provides a high-level functional abstraction of the AOLT and AONT systems,
describing the traffic flow and processing within the GPON and Ethernet domains of these systems.
Figure 1: TR-156 GPON Access Node
3 Configuration and Management Overview

The high-level configuration and management flow is schematically shown in Figure 2.
1
The AONT type and model information in this sheet is planned to be incorporated in a marketing requirements document eventually.

START
Configure and manage AOLT system w.r.t:

Management IP address, system location, etc.
AOLT Equipment/ Addressed in the Node level provisioning document
Resource Basic Layer 2 configurations at the AOLT, including those of
Configuration & Service VLAN (S-VLAN) membership, link aggregation, etc. for SNI-s
Management Addressed in the SWT card level provisioning, GLC card level provisioning, and the
Layer 2 SRD documents.
Typical sequence illustrated; these steps may
PON layer settings, including ONT/ONU auto-discovery, FEC, etc.,

Addressed in the AOLT GPON PMD & TC layer requirements document
Add AONTs to PONs and activate them

be executed in any order
AONT addition (to Specify ONT/ONU/subscriber information such as S/N and/or PLOAM
PONs) and activation password (possibly learned through ONT/ONU auto-discovery)
Addressed in the AOLT GPON PMD & TC Layer Requirements and the
ONT Configuration & Management Requirements documents
AONT Equipment/ Configure and manage AONTs w.r.t:

Resource UNI port settings
Configuration & QoS/TM settings for priority queues, traffic scheduler, etc.
Management - Addressed in the ONT Configuration & Management Requirements
document and in SRDs that pertain to special UNI types (e.g., xDSL)
Service Configuration
Configure and manage services on the AOLT and the AONT
& Management on
– Addressed in this document
AOLT and AONTs
END
Figure 2: Configuration and Management flow
The focus of this document is the ‘Service Configuration & Management’ step in the above figure.
4 Services Overview
In the context of the GPON system, services are characterized by attributes such as the contracted traffic flow parameters
(CIR, PIR, etc.), VLAN id, and the desired VLAN and p-bit manipulations, and service configuration refers to the set of
configurations that are related to these attributes that are required to be performed at the OLT and ONT in order to deliver
a service’s traffic.
The service configuration and management requirements in this document are not specific to any particular AONT model
and as such are applicable to any AONT model whose user (UNI) ports are capable of supporting the service types
defined in this document.
4.1 Service Types
The different service types that shall be supported by the Alphion GPON system are shown in Table 1.

Table 1: Service types2
Service type Associated Notes
UNI port type
HSI Ethernet
Voice POTS
Broadcast-IPTV (B-IPTV) Ethernet
TLS Ethernet
External-VoIP Ethernet An end-user VoIP service terminated external to the AONT (e.g., at a IP
phone connected to the AONT via an Ethernet UNI port)3
VoD-IPTV Ethernet An end-user VoD service terminated external to the AONT3
5 Service Provisioning
Service provisioning includes the following settings, applied to a traffic flow corresponding to a specific service instance
that has been activated on a UNI port at the AONT4:
• General service traffic flow configuration - applicable for all service types:
o VLAN Handling - which includes:
Flow classification related settings for this traffic flow, such as the VLAN information (TPID, VID, p-
bits), EtherType, and UNI port. The AONT and the AOLT shall match (the AONT in the U/S direction,
and the AOLT (GLC card) in the D/S direction) received frames against these settings in order to classify
(route) the frames into appropriate PON connections (GEM ports) that are associated with configured
traffic flows associated with service instances.
VLAN Handling action configuration: Actions such as adding, modifying and removing tag that need to
be performed for this traffic flow. The AONT and the AOLT perform these actions on received frames
before they are routed to the appropriate PON connections.
• QoS configuration - such as the priority queue in the AONT on which to transport this flow (over one or more
PON connections) and the CIR and PIR bandwidths to allocate for the traffic flow.
• Service type-specific configuration – such as VoIP-specific settings (e.g., the SIP username and password), and
Broadcast IPTV-specific settings (e.g., maximum number of multicast groups per port).
In the remainder of this document, first the service models are introduced, and the related VLAN Handling requirements
are addressed, in section 6. This is followed by section 7 which addresses the QoS requirements for services. Then the
general service configuration and management requirements are addressed in section 0. Finally, section 9 addresses the
service type-specific requirements.
6 Service Models & VLAN Handling

6.1 Overview
As stated before, VLAN Handling refers to (i) the filtering and classification by the AONT and AOLT of received frames
based on configured information, so as to route them to appropriate PON connections, and (ii) the VLAN handling actions
taken before routing the frames to the PON connections.
Following are some general points to be noted with regards to VLAN Handling in a GPON system:
1. Service delivery topology/Layer-2 forwarding paradigm: In accordance with TR-156 (section 5.1) and TR-101 (R-
33), the layer-2 forwarding paradigm for a service instance can be one of: (i) point2multipoint (p2mp), also known as
2
RF video overlay is not considered a service type since only the optical path for the RF-video traffic needs to be activated at the
AONT, and the AONT and AOLT are otherwise transparent to this traffic. Enabling/disabling the RF-video UNI port is discussed in [13].
3
used when the corresponding traffic flow needs to be distinguished with regards to the flow priority and/or VLAN handling from that of
the HSI service that may also be offered on the same port.
4
For readers not familiar with the traffic flow handling within the AOLT and AONT systems, an overview is provided in Appendix I.

N:1 VLAN, forwarding (ii) point2point (p2p), also known as 1:1 VLAN, forwarding and (iii) TLS/VBES (VLAN for
Business Ethernet Services) forwarding. As will be noted later, not all the service types support all the layer-2
forwarding paradigms (e.g., IPTV always uses the p2mp layer-2 forwarding paradigm).
2. Multiple service instances, of same or different types, can be supported on the same UNI port.
3. Multicast traffic is delivered over GPON (OLT and ONU) over one or more N:1 VLANs, as described in TR-156.
Within the GPON domain, i.e. between the OLT and ONUs, a dedicated unidirectional (OLTONT) GEM port per
PON carries all multicast traffic destined to subscribers that are connected to the ONUs on the PON.
4. Double tagged frames received at an UNI port (on the ONT/ONU) are discarded unless a TLS service is associated
with that port.
5. For the TLS/VBES services, the TLS exception traffic, i.e., traffic tagged with special VIDs at UNI that need to be
handled outside a TLS service, shall be provisioned as one or more separate non-TLS service instances, which
themselves shall use the p2p or p2mp layer-2 forwarding paradigm. An example is a HSI service on top of a TLS
service on the same UNI port.
6. To each service instance is associated a Service VID (S-VID) that is specified at service instance creation time. For a
given service instance, the VLAN Handling to apply to the traffic flows on a UNI port is specified at the time of
activation of the service instance on that UNI port.
Although there can be many different VLAN Handling combinations with regards to the packet classification and
filtering, and VLAN actions, the TR-156 and G.984.4 standards define a core subset of these, referred to in this document
as the core service models or VLAN forwarding models.
Section 6.2 below first defines the core service models, followed by sections 6.3 that address the requirements for the
AOLT and AONT system to realize these core service models.
6.2 Service models (or VLAN forwarding models)

In reference to the TR-156 GPON Access Node abstraction, shown in Figure 1, a service model refers to the handling, in
the upstream and downstream direction, of traffic corresponding to a service instance with regard to the following aspects:
the number of levels of VLAN tag (single, double, etc.) that are/shall be present at the ingress and egress ports (i.e the
UNI and SNI ports of the Access Node); how traffic is classified into VLANs at ingress; and the VLAN handling action
(VLAN tag addition, removal, or modification, etc.) that the service instance’s traffic shall undergo at the ingress and
egress ports.
Table 2 below lists the core service models that shall be supported by the AOLT and AONT systems starting from R2.0.
Additional VLAN forwarding models to those in the table may be supported in the future if required.
Table 2: Core Service Models (or Core VLAN Handling Models)
Service model Description Applicable Applicable

(see Figure 1) Service service types
delivery
topologies
Untagged at UNI, Untagged packets at the UNI and single-tagged packets at the p2mp (N:1), All in Table 1
Single-tagged at SNI are accepted and transmitted. p2p (1:1) except TLS (HSI,
SNI Voice, etc.)
Single-tagged at Single tagged packets at the UNI and at the SNI are accepted p2mp (N:1), All in Table 1
UNI, Single- and transmitted. p2p (1:1) except TLS (HSI,
tagged at SNI Voice, etc.)
Untagged at UNI, Untagged packets at the UNI and double-tagged packets at the p2p (1:1) All in Table 1
Double-tagged at SNI are received and transmitted. Tagged packets received at except TLS and B-
SNI the UNI are dropped. IPTV (HSI, Voice,
etc.)
Single tagged at Single tagged packets at the UNI and double-tagged packets at p2p (1:1) All in Table 1
UNI, Double the SNI are accepted and transmitted. except TLS and B-
tagged at SNI IPTV (HSI, Voice,
etc.)

TLS – ‘Untagged, Untagged, priority tagged, and single tagged frames are TLS TLS
Priority tagged, accepted and transmitted at the UNI. In this mode, regardless of (see TR-156
Single tagged at the tag level at the UNI, an additional tag is always added in / section
UNI’ mode the upstream direction to the frames when they exit the Access 5.1.3)
Node. Similarly, in the downstream direction, the outer VLAN
tag is stripped out when frames exit the UNI port.
TLS – ‘Double Double tagged packets with a specific outer VID (S-VID) are TLS TLS
tagged at UNI’ accepted and transmitted at the UNI port. No additional tag is (see TR-156
mode added by AN; the S-VID can optionally be translated by the / Fig. 14)
Access Node.
The following shall be noted with regards to Table 2:
Note 1: With the untagged models (first and third), for a given UNI port, there can be only one service instance based on
this model (as there is no VID in the received frames for traffic distinguishing), unless EtherType-based VLAN (VID
and/or priority) assignment, per TR-156/R-9, is enabled. In this latter case, multiple service instances with these service
models can be supported, each with a different EtherType (e.g., 0x8863 or 0x8864 for PPPoE frames).
Note 2: Each of the service models (except the TLS ones) applies to multiple service types, some also applying to both the
p2mp and p2p Layer-2 forwarding modes.
The VLAN Handling requirements for realizing the core service models above are addressed in the following section.
6.3 VLAN Handling requirements
Since VLAN Handling configuration is critical and required, in some form or the other, for all service types, the VLAN
Handling parameters are defined in a service type independent manner in the following tables, so that the AEMS, and
optionally the AOLT CLI, can present a consistent “template” of parameters that shall be specified at service provisioning
and/or activation time. This also helps with evolving to profiles-based provisioning of VLAN Handling in a future R2.x
release.
In the remainder of this subsection, Table 3 and Table 4, discussed in sub-sections 6.3.1 and 6.3.2, first present the list of
VLAN Handling related parameters to configure when service traffic flows are activated. For a given service traffic flow
to activate, with a specific service model, on a given UNI port, the desired VLAN Handling (checking, addition,
modification, deletion of VLAN tag) in the U/S and D/S directions for the flow is modeled through the parameters in
Table 3 and Table 4, respectively.
These tables are then followed by Table 5 which presents a mapping of the core service models in Table 2 to the VLAN
Handling parameters in Table 3 and Table 4. The mapping includes specifying which VLAN Handling parameters apply
to which service models. Thus Table 3, Table 4, and Table 5 together define a “template” of VLAN Handling parameters
with which to configure the core service models. The VLAN Handling parameters in the above tables and associated
requirements are invoked (referred to) from the service type-specific section, section 9.
The following shall be noted in regards to Table 3, Table 4, and Table 5:
1. The usage of the terms Q-VID, C-VID (inner VID), and S-VID (outer VID) in this table is consistent with the TR-
156 [9] usage of these terms.
2. In order not to preclude special, asymmetrical VLAN Handling requirements, separate parameter sets have been
defined in this table for D/S VLAN handling and U/S VLAN Handling. For symmetrical VLAN Handling the
parameters in these sets shall be set to equivalent values; for example, upstream egress VLAN tag value is same
as downstream ingress VLAN tag value (both as applicable at the SNI).
3. The ‘list’ option, specified as one of the possible values for some of the parameters, may include a single entry as
the value.
4. The functional and OMCI requirements for the AONT with regards to the VLAN Handling requirements are
addressed in the AONT related SRD and/or ORD documents.

6.3.1 Upstream VLAN Handling
The VLAN Handling parameters for the U/S direction are defined in Table 3 below. In the table, the UNI Tag/UNI Outer
Tag represents the VLAN tag against which to check the frames received at the UNI (U/S ingress frames) in order to
classify matching frames to the associated traffic flow. The SNI Tag/SNI Outer Tag and the SNI Inner Tag represent the
desired tags for the traffic flow (to which the U/S ingress frames were classified per the UNI Tag/UNI Outer Tag) as they
appear at the SNI. Where the desired tags are applied within the Alphion GPON system (i.e., the AOLT and/or AONT)
depends on the desired tag level at the SNI (single or double tagged). This is discussed in Table 6 in section 6.3.

Table 3: U/S VLAN Handling parameters
Req.
Parameter Value Reference (if any) Notes
id
U/S VLAN handling One of: • TR-156 (Sections 5.1 & Allowed U/S VLAN Handling actions, to be performed at the AOLT
113-R-6.3.1-10
action • ’No additional tag’ 5.2) and/or AONT depending on the service model, as will be shown in Table
• ’Add one tag (S-Tag)’ • G.984.4 (Ext. VLAN 5 and Table 6.
tagging operation
• ’Add two tags (S-Tag & C-Tag)’ config. data ME, VLAN
tagging operation
config. data ME, VLAN
tagging filter data ME)
UNI Tag / UNI Outer Tag (latter only for ‘Double-tagged frames at UNI’ service models) & EtherType
UNI VID / UNI Outer One of: ,, This is the VID of frames (corresponding to the associated traffic flow)
VID (i.e. UNI Q-VID / • ‘None’ (Untagged or priority tagged) as received by or transmitted from the UNI port. This is the VID against
UNI Outer Q-VID) which received frames at the UNI port are checked in order to be
• ‘Same as S-VID’ (no VID translation)
113-R-6.3.1-20
classified to the associated traffic flow. When the frames are double
• A specific VID (received at UNI), from tagged (TLS – Double tagged at UNI service model), this VID represents
which to translate to the S-VID or C-VID (C- the outer VID.
VID is applicable for the ‘double tagged at The AOLT shall instruct the AONT to check/process received U/S frames
SNI’ models)5; VID shall take any value in per this VID.
the range 2-4094 except the S-VID or C-VID.
When set to ‘Same as S-VID’, the U/S received frames at the UNI port
• ‘Any’ (VID ignored; all VIDs, regardless of shall be checked against the S-VLAN Id of the service instance as part of
their value, are translated to the S-VID or which the associated traffic flow is activated.
C-VID)
UNI P-bits / UNI Outer • ‘None’ ,, Represents the p-bits at the UNI. When frames are double tagged at
113-R-6.3.1-
P-bits • ‘Any’ (ignored) UNI, this parameter represents the outer p-bits.
When this parameter is set to one of the p-bits in a list, the AOLT shall
• A specific p-bits value (in the range 0-7)
30
instruct the AONT to check received frames against these p-bits (along
(against which to filter the received U/S
with other fields) in order for the frames to be classified to the
frames at the UNI)
associated traffic flow.
UNI TPID / UNI Outer • ‘None’ ,, Represents the TPID or outer TPID at UNI.
113-R-6.3.1-
TPID • ‘Any’ (ignored) When this parameter is set to one or more specific TPIDs, the AOLT
shall instruct the AONT to check received frames against these TPIDs so
• A specific two-byte TPID value, e.g.,
40
they can be classified to the associated traffic flow.

0x8100, 0x88a8, 0x9100, etc. (against
which to filter the received U/S frames at
the UNI)
5
Translating to the S-VID or C-VID from one of several VIDs in a list (as opposed to from one specific VID) is deferred for future.

Req.
id
UNI EtherType • PPPoE (0x8863 & 0x8864) G.984.4 / Ext. VLAN The EtherType value against which to filter received frames for the
113-R-6.3.1-
• IPoE (0x0800) tagging operation config. associated service flow. Applicable only when received upstream
data ME; TR-156 / R-9 frames are untagged or priority tagged (i.e. one of the ‘Untagged UNI’
50
• ARP (0x0806) service models).

• ‘Any’ (ignored; do not filter based on Value shall be set to ‘Any’ if no EtherType filtering is required.
EtherType)
SNI Tag / SNI Outer Tag (latter if frames are to be double-tagged at SNI)
Note: The parameters below include only the p-bits and TPID of the S-Tag; the S-VID part of the S-Tag is specified, as stated earlier, at the service instance creation time.
SNI P-bits / SNI Outer • ‘None’ (Not present) ,, The p-bits or outer p-bits (latter when frames are to be double-tagged)
p-bits (i.e. SNI S-p- • ‘Same as (retain) U/S p-bits received at at the SNI that the AOLT shall either itself, or instruct the AONT to, tag
7
bits) the UNI’ the U/S frames of the associated traffic flow with .
• ‘Copy from received Outer p-bits at the The ‘Derive from DSCP’ value is applicable only for the ‘Untagged UNI’
UNI’ VLAN Handling models; the DSCP-to-p-bits mapping for the U/S dir is
113-R-6.3.1-60
configured on a per UNI port basis, as described in section 8 of [14].

• ‘Copy from received Inner p-bits at the
UNI’ The ‘Copy from received Outer p-bits at the UNI’ and ‘Copy from
received Inner p-bits at the UNI’ are applicable if frames at UNI are
• ‘Derive from DSCP’6 received double tagged.
• A specific value, from 0 to 7
• A specific value, from 0 to 7, to which to
translate one of the following p-bits
received at the UNI: p-bits, Outer p-bits, or
Inner p-bits (last two for models wherein
frames are received double-tagged at UNI)
6
The derived p-bits are used only to internally determine the destination priority queue for the associated frames, with no modification to the frames.
7
As noted earlier, whether it is the AOLT or the AONT that adds, or modifies to, the specified VLAN tag component (p-bits or TPID) is determined by the desired tag level at the SNI
for the associated traffic flow and shall be in compliance with TR-156. See Table 6 for details.

Req.
id
SNI TPID / SNI Outer • ‘None’ ,, The TPID or Outer TPID at the SNI that the AOLT shall either itself, or
TPID • ‘Same as (retain) TPID received at the instruct the AONT to, tag the U/S frames of the associated traffic flow
UNI’ (Same as UNI TPID) withError! Bookmark not defined..
Default value:
• ‘Copy from received Outer TPID’
113-R-6.3.1-70
0x8100 value for the ‘Untagged UNI, Single tagged SNI’ model;
• ‘Copy from received UNI Inner TPID’
(above two applicable if received frames at ‘Retain UNI TPID/UNI Outer TPID’ for the ‘Single tagged UNI, Single
UNI are double tagged) tagged SNI’ model;
• A specific two-byte TPID value (0x8100, 0x88a8 value for the ‘Untagged UNI, Double tagged SNI’ and the ‘Single
0x88a8, 0x9100, etc.) tagged UNI, Double tagged SNI’ models
• A specific two-byte TPID value (0x8100,
0x88a8, 0x9100, etc.) to which to translate
the TPID or Outer TPID received at the UNI
SNI Inner Tag (only for the ’Double-tagged frames at SNI’ service models)
SNI Inner VID (i.e. SNI • ‘None’ (Not present) ,, This is the inner VID at the SNI (C-VID) that the AOLT shall instruct the
C-VID) • Same as (retain) VID received at the UNI’ AONT to tag the U/S frames of the associated traffic flow with.
113-R-6.3.1-80
(Same as UNI VID) The ‘Retain’ and ‘Copy’ values are not applicable for service models in
• ’Copy from received Outer VID’ Table 2 wherein frames are received untagged at the UNI.
• ’Copy from received Inner VID’
• A specific VID, from 2 to 4094
• A specific VID, from 2 to 4094, to which to
translate the VID received at the UNI
SNI Inner P-bits (i.e. • ‘None’ (Not present) This is the inner p-bits at the SNI that the AOLT shall instruct the AONT
SNI C-p-bits) • ‘Same as (retain) p-bits received at the to tag the U/S frames of the associated traffic flow with.
UNI’ The ‘Retain’ and ‘Copy’ values are not applicable for service models in
113-R-6.3.1-90
• ‘Copy from received Outer p-bits’ Table 2 wherein frames are received untagged at the UNI.
• ‘Copy from received Inner p-bits’ The ‘Derive from DSCP’ value is applicable only for the ‘Untagged UNI’
VLAN Handling models; the DSCP-to-p-bits mapping for the U/S dir is
• ‘Derive from DSCP’ configured on a per UNI port basis, as described in section 8.2.2 of [14].
• A specific p-bits value, from 0 to 7
• A specific p-bits value, from 0 to 7, to
which to translate the P-bits received at
the UNI (priority re-marking)

Req.
id
SNI Inner TPID • ‘None’ ,, This is the inner TPID at the SNI that the AOLT shall instruct the AONT
• ‘Same as (retain) received TPID’ to tag the U/S frames of the associated traffic flow with.
113-R-6.3.1-100
The ‘Retain’ and ‘Copy’ values are not applicable for service models in
• ‘Copy from received Outer TPID’
Table 2 wherein frames are received untagged at the UNI.
• ‘Copy from received Inner TPID’
• A specific two-byte TPID value, 0x8100,
0x88a8, 0x9100, etc.,
• A specific two-byte TPID value, 0x8100,
0x88a8, 0x9100, etc., to which to translate
the TPID received at the UNI
6.3.2 Downstream VLAN Handling

The VLAN Handling parameters for the D/S direction are defined in Table 4 below. In the table, the SNI Tag/SNI Outer Tag and the SNI Inner Tag represent the
VLAN tags against which to check the frames received at the SNI (D/S ingress frames) and the tags used by the AONT to classify D/S frames to the associated
traffic flow. The UNI Tag/UNI Outer Tag represents the desired tag for the associated traffic flow (to which the D/S frames were classified per the SNI Tag/SNI
Outer Tag and the SNI Inner Tag) as it appears at the UNI.
Table 4: Downstream VLAN Handling parameters
Req.
id
D/S VLAN One or more of: • TR-156 (Sections 5.1 & 5.2) Allowed D/S VLAN Handling actions. Applicable
6.3.2-10
Handling action • No tag to remove • G.984.4 (Ext. VLAN tagging parameters (among those listed in this table) depend on
113-R-
operation config. data ME, VLAN the service model as shown in Table 5.
• Remove one tag (S-Tag)
tagging operation config. data
• Remove two tags (S-Tag & C-Tag) ME, VLAN tagging filter data ME)
SNI Tag / SNI Outer Tag (latter if frames are double-tagged at SNI) (S-Tag at SNI)
Note: The parameters below include only the p-bits and TPID of the S-Tag; the S-VID part of the S-Tag is specified, as stated earlier, at the service instance creation time.
SNI P-bits / SNI • ‘None’ • TR-156 (Sections 5.1 & 5.2) Represents the p-bits as received at the SNI. The AOLT
Outer p-bits (i.e. • ‘Any’ (any value between 0 and 7) • G.984.4 (Ext. VLAN tagging shall instruct the AONT to use these p-bits (along with
SNI S-p-bits) operation config. data ME, other criteria such as TPID) while classifying D/S frames
• A specific p-bits value, from 0 to 7 (against which to to the associated traffic flow. Also the AOLT uses these
VLAN tagging operation config.
113-R-6.3.2-20
filter received D/S frames) p-bits to determine the PON connection (along with
data ME, VLAN tagging filter
data ME) other parameters such as the S-VID and the destination
MAC address) to forward out the frames, to the
destination AONT.
When frames are double tagged at SNI, this parameter
represents the outer p-bits.
In ‘symmetric’ VLAN Handling models, the value of this
parameter matches with that of the upstream egress S-
p-bits parameter in Table 3 (i.e. symmetric p-bits).

Req.
id
SNI TPID / SNI • ‘None’ • TR-156 (Sections 5.1 & 5.2) Represents the TPID or outer TPID (latter when double
113-R-6.3.2-
Outer TPID • ‘Any’ (any two-byte value) • G.984.4 (Ext. VLAN tagging tagged) as received at the SNI. The AOLT shall instruct
operation config. data ME, the AONT to use this TPID (along with other criteria)
• A specific two-byte TPID value, e.g. 0x8100, 0x88a8,
30
VLAN tagging operation config. while classifying D/S frames to the associated traffic
0x9100, etc. (against which to filter D/S received flow.
frames) data ME, VLAN tagging filter
data ME)
SNI Inner Tag (C-Tag at SNI)
SNI Inner VID (i.e. • ‘None’ (does not exist) ,, Represents the inner VID as received at the SNI (when
6.3.2-40
113-R-
SNI C-VID) • ‘Any’ (any value between 2 and 4094) D/S frames for the traffic flow are double tagged). The
AOLT shall instruct the AONT to use this VID (along with
• A specific VID (any value in the range 2-4094) (against other criteria) while classifying D/S frames to the
which to filter D/S received frames at the SNI) associated traffic flow.
SNI Inner P-bits • ‘None’ ,, Represents the inner p-bits as received at the SNI (when
6.3.2-50
113-R-
(i.e. SNI C-p-bits) • ‘Any’ (any value between 0 and 7) D/S frames for the traffic flow are double tagged). The
AOLT shall instruct the AONT to use these p-bits (along
• A specific p-bits value (in the range 0-7) (against with other criteria) while classifying D/S frames to the
which to filter received D/S frames) associated traffic flow.
SNI Inner TPID • ‘None’ ,, Represents the inner TPID as received at the SNI (when
6.3.2-60
• ‘Any’ (any two-byte value) D/S frames for the traffic flow are double tagged). The
113-R-
AOLT shall instruct the AONT to use this TPID (along

• A specific TPID value (a two-byte value – e.g., 0x8100, with other criteria) while classifying D/S frames to the
0x88a8, 0x9100, etc.) (against which to filter received associated traffic flow.
D/S frames)
UNI Tag / UNI Outer Tag (latter when frames are double-tagged at UNI, i.e. ‘TLS – Double tagged at UNI’ service model)
UNI VID / UNI • ‘None’ (Not present) ,, This is the VID or outer VID (latter when frames are to
Outer VID • ’ Same as (retain) received VID’ be double-tagged) at the UNI that the AOLT shall
113-R-6.3.2-70
instruct the AONT to tag the D/S frames of the

• ’Copy from D/S Outer VID received at the SNI’ associated traffic flow with.
• ‘Copy from D/S Inner VID received at the SNI’
• A specific VID, from 2 to 4094, to which to translate
VID or Outer VID received at the SNI
• A specific VID, from 2 to 4094, to which to translate
Inner VID received at the SNI

Req.
id
UNI P-bits / UNI • ‘None’ (Not present) This is the p-bits or outer p-bits (latter when frames are
Outer p-bits • ‘Same as (retain) received p-bits’ to be double-tagged) at the UNI that the AOLT shall
• ‘Copy from D/S Outer p-bits received at the SNI’ associated traffic flow with.
113-R-6.3.2-80
• ‘Copy from D/S Inner p-bits received at the SNI’ The ‘Derive from DSCP’ value for the D/S direction is
• ‘Derive from DSCP’ applicable for future models wherein D/S frames are
received untagged at the SNI; the DSCP-to-p-bits
• A specific p-bits value, from 0 to 7, to which to
mapping for the D/S dir is configured on a per UNI port
translate the p-bits or Outer p-bits received at the SNI
basis, as described in section 8.2.1 of [14].
(priority re-marking)
‘Retain UNI p-bits / UNI Outer p-bits’ for the tagged-UNI
• A specific p-bits value, from 0 to 7, to which to
models; ‘Derive from DSCP’ for untagged-UNI models
translate the Inner p-bits received at the SNI (priority
re-marking)
UNI TPID / UNI • ‘None’ ,, This is the TPID or outer TPID (latter when frames are to
Outer TPID • ‘Same as (retain) received TPID’ be double-tagged) at the UNI that the AOLT shall
113-R-6.3.2-90

• ‘Copy from received Outer TPID’ associated traffic flow with.
• ‘Copy from received Inner TPID’
• A specific two-byte TPID value, 0x8100, etc., to which
to translate the TPID or Outer TPID received at the SNI
• A specific two-byte TPID value, e.g., 0x8100, etc., to
which to translate the Inner TPID received at the SNI

6.3.3 Service model to VLAN Handling parameters mapping
The AOLT shall realize the core service (VLAN Handling) models in Table 2 using subsets of the U/S- and D/S- VLAN Handling parameters defined in Table 3
and Table 4. Table 5 below provides a mapping for each of the core service models to the U/S and D/S VLAN Handling parameters that are applicable for that
service model. As stated earlier, for a given traffic flow that is to be activated as part of a service instance on an UNI port, the VLAN Handling to apply to the
traffic flow is specified, at the time of such activation, via the desired VLAN Handling model (column 2 in Table 5) and the associated parameters.
Table 5: Service model to VLAN Handling parameters mapping
Note 1: VLAN tag includes the TPID, VID and p-bits. The location of tag addition/modification/removal within the Alphion GPON system (AOLT or AONT) is discussed in
Table 6.
Note 2: For each of the core VLAN Handling (Service) models, the valid combinations of the VLAN tag parameters (UNI Tag, SNI Tag, etc.) for the U/S and D/S directions,
including the default combination, are enumerated in Table 7.
U/S VLAN Handling parameter (see Table 3) D/S VLAN Handling parameter (see Table 4)
Service UNI Tag / UNI UNI Inner SNI Tag / SNI SNI Inner Action SNI Tag / SNI UNI Tag / UNI
Req. Req.
model (per UNI Outer Ether Tag (Q- Outer Tag Tag (C- SNI Outer Inner UNI Inner Notes
id Action priority
Table 2) tag (Q- Type Tag (S-Tag)8 Tag) Tag (S-Tag) Tag (C- Outer tag Tag
8
Tag) Inner) Tag) (Q-Tag)
8
Untagged Add N/A Values N/A S-Tag values N/A Remove N/A N/A N/A For this (and other GA
113-R-0-10
Same value
UNI, Single- one as as defined in one tag as that for ‘Untagged UNI’)
tagged SNI tag (S- define Table 3. U/S8 models, the AOLT
Tag) d in ‘Retain’ and shall support optional
Table ‘Copy’ values filtering in U/S dir of
3. not to be ingress frames of
allowed. associated service
flow against the
specified EtherType.
Untagged Add N/A Values N/A S-Tag. C-Tag. Remove Same value C-Tag N/A N/A Applicable only for GA
UNI, two as ‘Retain’ two at SNI
113-R-0-20
9
‘Retain’ and as that for p2p (1:1) VLAN .
Double- tags define ‘Copy’ values and tags U/S
8
tagged SNI (S-Tag d in not to be ‘Copy’
& C- Table allowed. values
Tag) 3. not to be
allowed.
8
Note: As stated earlier, only the p-bits and TPID of the S-Tag are specified as part of the service flow configuration, specified at the service activation time for a UNI port, as the
VID part of the S-Tag (S-VID) is specified on a per-service instance basis, at the time of service instance creation, identifying the S-VLAN for the service instance.
9
For the ‘double-tagged at SNI’ service models, it shall be noted that while the S-VID is specified at the service instance level, the C-Tag (i.e. inner tag at the SNI) is specified for
the UNI port on which to activate the service instance. Implementation note: In compliance with TR-156, the outer S-Tag shall need to be applied at the AOLT, specifically at the
GLC card (as opposed to SWT card), as the ingress AONT and UNI port information regarding upstream frames is available only at this card.

U/S VLAN Handling parameter (see Table 3) D/S VLAN Handling parameter (see Table 4)
Service UNI Tag / UNI UNI Inner SNI Tag / SNI SNI Inner Action SNI Tag / SNI UNI Tag / UNI
Req. Req.
model (per UNI Outer Ether Tag (Q- Outer Tag Tag (C- SNI Outer Inner UNI Inner Notes
id Action priority
Table 2) tag (Q- Type Tag (S-Tag)8 Tag) Tag (S-Tag) Tag (C- Outer tag Tag
8
Tag) Inner) Tag) (Q-Tag)
Single- ‘No the VLAN N/A N/A S-Tag values N/A ‘No tag Same value N/A Same N/A The SNI Tag and the GA
113-R-0-30
tagged UNI, tag to at the UNI (ignor as defined in to as that for value as UNI tag can
Single- add’ (to check ed) Table 3 (’SNI remove’ U/S8 that for optionally be
tagged SNI incoming Tag’ group). U/S different (tag
U/S frames translation case); see
against) Table 3 (for SNI
tag/SNI Outer tag)
and Table 4 (for UNI
tag).
Single- Add the VLAN N/A N/A S-Tag; C-Tag at Remove Same value Value Value N/A As stated in Table 3 GA
tagged UNI, one tag at the (ignor represents SNI. one tag as that for same as same as
113-R-0-40
and Table 4, the SNI

Double- tag UNI ed) the outer tag (Outer U/S; that for that for C-Tag and the UNI
tagged SNI (outer to add. tag/S- represents U/S U/S tag can optionally be
tag/S- tag) the outer different from each
Tag) tag to other (tag translation
remove case).
TLS – Add N/A N/A N/A S-Tag at SNI. N/A Remove Same value Same N/A N/A “Standard” TLS GA
113-R-0-50
Standard ( one (ignored) (ignor (ignored) ‘Retain’ and one tag as that for value (ignored) (ignor service.
Untagged, tag ed) ‘Copy’ values (TLS S- U/S as that ed)
Priority (TLS not to be Tag) for U/S
tagged, or S-Tag) allowed.
Single-
tagged UNI)
mode
TLS – ‘No The outer N/A N/A S-Tag at SNI. N/A ‘No tag Same value N/A Same N/A Special TLS mode FC
113-R-0-60
Double- tag to tag at the (ignor (ignored) The S-Tag (ignored) to as that for (ignore value as (ignor defined in TR-
tagged UNI add’ UNI against ed) can remove’ U/S d) that for ed) 156/section 5.1.3
mode which optionally be U/S and in TR-156/R-{42,
incoming set to be 43} wherein TLS
frames at different frames are received
the UNI from the double-tagged at
are outer tag at UNI.
checked UNI. The UNI Outer tag
against. and the SNI Outer tag
Non- can optionally be
matching different; see Table
frames are
3 and Table 4.
discarded.

Given a service traffic flow, with a desired service model, to activate as part of a service instance (of a specific service
type and delivery topology (p2p, p2mp, etc)) on a given UNI port (as will be discussed later on a per service type basis in
section 9), the AOLT and AEMS shall support the following four VLAN Handling requirements in this subsection:
113-R- The AOLT shall support configuration and retrieval of the subset of the VLAN Handling parameters Priority:
0-70 (defined in Table 3 and Table 4) applicable to that service model in accordance with Table 5. GA
The AEMS shall support the configuration and retrieval, using appropriate user interface, of the subset Priority
113-R-
0-80
of the VLAN Handling parameters (defined in Table 3 and Table 4) applicable to that service model in : GA
accordance with Table 5, graying-out the non-applicable parameters.
For the ‘Untagged UNI, Single Tagged SNI’ and the ‘Untagged UNI, Double Tagged SNI’ service Priority
113-R- models, as defined in Table 5, the AOLT and AEMS shall support optional configuration of EtherType : GA
0-90 filter values against which U/S frames for the associated service flows received at the UNI shall be
filtered.
The AOLT implementation of the service model shall use the Layer-2 OMCI Common Model (L2- Priority:
113-R- OCM) defined in the G.984.4 IG, specifically the use of the combination of the Extended VLAN GA
0-100 Tagging Operation Config Data ME and the VLAN Tagging Filter OMCI MEs, to accomplish the
required VLAN Handling.
As shown in the table below, the AOLT implementation of the service model shall comply with TR-156 (Figs. 12-14) and
the L2-OCM model [8] with regards to where within the Alphion GPON system (i.e., AOLT or AONT) VLAN tags get
added, modified, or removed:
Table 6: Service models – Points of VLAN Handling within the Alphion GPON system
Req. id Service model VLAN Handling point within the Alphion GPON system
113-R-0- Untagged UNI, The AOLT shall configure the AONT to add (remove) the S-Tag in the U/S direction (D/S direction).
110 Single tagged SNI The AOLT just passes-through as-is the S-Tag.
113-R-0- Single tagged UNI, The AOLT shall configure the AONT to pass-through as-is the received tag (Q-tag in the U/S dir, S-
120 Single tagged SNI tag in the D/S dir) or translate it to another tag (S-tag in the U/S dir, Q-tag in the D/S dir). The
AOLT just passes-through as-is the S-Tag.
113-R-0- Untagged UNI, The AOLT shall configure the AONT to add (remove) the C-Tag in the U/S (D/S) direction, and the
130 Double tagged SNI AOLT shall add (remove) the S-Tag in the U/S (D/S) direction10.
113-R-0- Single tagged UNI, The AOLT shall configure the AONT to pass-through as-is the received tag (Q-tag in the U/S dir, C-
140 Double tagged SNI tag in the D/S dir) or translate it to another tag (C-tag in the U/S dir, Q-tag in the D/S dir). The
AOLT shall add (remove) the S-Tag in the U/S (D/S) direction10.
113-R-0- TLS Standard The AOLT shall configure the AONT to transparently (regardless of the tag level in the received
150 (Untagged, Priority frames) add (remove) the TLS S-Tag in the U/S (D/S) direction. The AOLT just passes-through as-is
tagged, Single the traffic tagged with the TLS S-tag.
tagged UNI) mode
113-R-0- TLS - Double The AOLT shall configure the AONT to check the outer tag of received U/S frames at the UNI
160 tagged UNI mode against the specified UNI Outer tag and optionally translate the received outer tag to the specified
SNI Outer tag. In the D/S dir, the AONT shall, again, optionally translate received SNI outer tag to
the specified UNI outer tag. The AOLT passes-through as-is the TLS S-tag in both U/S and D/S dir.
10
Adding/removing the S-Tag is recommended to be done at the GPON line card as information such as the UNI port on which frames
were received or are to be transmitted is available.

6.3.4 Upstream-Downstream value combinations for VLAN Handling parameters

For each of the core VLAN Handling (Service) models, the valid upstream-downstream value combinations for the VLAN tag parameters (UNI tag, SNI Outer
tag, SNI Inner tag, etc.) values, including the default combination, are listed in the table below. It shall be noted that, for a given VLAN Handling model, the
table lists only the combinations that are required for R2.0 among all the possible value combinations.
Table 7: Valid U/S-D/S value combinations for VLAN Handling parameters
VLAN U/S VLAN Handling parameter D/S VLAN Handling parameter

tag UNI SNI / SNI Outer tag (latter SNI Inner tag (for SNI / SNI Outer tag SNI Inner tag (for UNI
Req. id Notes
parame for ‘Double-tagged SNI’ ‘Double-tagged (latter for ‘Double- ‘Double-tagged SNI’
ter models) SNI’ models) tagged SNI’ models) models)
‘Untagged UNI, Single tagged SNI’ VLAN Handling model
113-R- VID N/A N/A (Specified at service N/A N/A (Specified at N/A N/A Default U/S-
6.3.4- instance creation time) service instance D/S
10 creation time) combination
113-R- P-bits N/A A specific p-bits value N/A ‘Any’ N/A N/A Default U/S-
6.3.4- (with which to transmit D/S
20 the frames (of the combination
associated flow) at the
SNI)
113-R- TPID A specific TPID value, A specific TPID value (with N/A A specific TPID value N/A ‘Same as D/S TPID Default U/S-
6.3.4- 0x8100 (default), which to transmit the (against which to received at the D/S
30 0x88a8, 0x9100, etc. frames (of the associated filter received D/S SNI’ combination
(against which to filter flow) at the SNI); value frames); value shall
U/S frames received at shall be same as the U/S be same as the U/S
UNI) TPID received at UNI TPID at the SNI.
‘Single-tagged UNI, Single-tagged SNI’ VLAN Handling model
113-R- ‘Same as (retain) S- N/A (Specified at service N/A N/A (Specified at N/A ‘Same as (retain) Default U/S-
6.3.4- VID’ (no VID instance creation time) service instance D/S VID received D/S
40 translation) (VID creation time) at SNI’ (no VID combination.
VID
against which to filter translation)
frames received at
UNI)
113-R- A specific VID (against N/A (Specified at service N/A N/A (Specified at N/A A specific VID (to Symmetric
6.3.4- which to filter U/S instance creation time) service instance transmit at the VID
50 frames received at the creation time) UNI and to which translation
UNI and which to to translate the
translate to S-VID); D/S VID received
value shall be different at the SNI); value
from the S-VID shall be same as
the U/S VID
received at the
UNI


Req. id Notes
113-R- ‘Any’ (VID ignored and N/A (Specified at service N/A N/A (Specified at N/A A specific VID (to “Un-trusted”
6.3.4- translated to S-VID) instance creation time) service instance transmit at the subscriber
60 creation time) UNI and to which scenario; VID
to translate the translation
received D/S VID
at the SNI)
113-R- ‘Any’ (not filtered ‘Same as (retain) U/S p- N/A ‘Any’ (not filtered N/A ‘Same as (retain) Default U/S-
6.3.4- against) bits received at the UNI’ against) D/S p-bits D/S
70 received at the combination
SNI’
113-R- ‘Any’ (not filtered A specific p-bits value (to N/A ‘Any’ (not filtered N/A ‘Same as (retain) For “Un-
6.3.4- against) which to translate U/S p- against) D/S p-bits trusted”
80 bits received at UNI) (U/S received at the subscribers;
priority re-marking) SNI’ U/S priority
P-bits
re-marking
113-R- A specific p-bits value ‘Same as U/S p-bits N/A ‘Any’ (not filtered N/A ‘Same as (retain) For U/S
6.3.4- (against which to filter received at the UNI’ against) D/S p-bits service
90 U/S frames received at received at the traffic flows
UNI) SNI’ to be
identified
with specific
p-bits
113-R- A specific TPID value ‘Same as (retain) U/S TPID N/A A specific TPID value N/A ‘Same as (retain) Default U/S-
6.3.4- (0x8100 (default), received at the UNI’ (no (against which to D/S TPID received D/S
100 0x88a8, 0x9100, etc.) TPID translation) filter D/S frames); at the SNI’ (no combination
(against which to filter value shall be same TPID translation)
U/S frames received at as the U/S TPID
UNI) transmitted at the
SNI
TPID
113-R- A specific TPID value A specific TPID value (to N/A A specific TPID value N/A A specific TPID Symmetric
6.3.4- (0x8100 (default), which to translate U/S (against which to value (to which to TPID
110 0x88a8, 0x9100, etc.) TPID received at UNI); the filter D/S frames); translate the D/S translation
(against which to filter value shall be different value shall be same p-bits received at
U/S frames received at than the U/S TPID at the as the U/S TPID the SNI); the
UNI) UNI) transmitted at the value shall be
SNI same as the U/S
TPID at the UNI


Req. id Notes
‘Untagged UNI, Double-tagged SNI’ VLAN Handling model
113-R- VID N/A N/A (S-VID specified at A specific VID (C- N/A (S-VID specified A specific VID (against N/A Default U/S-
6.3.4- service instance creation VID), from 2 to at service instance which to check inner-VID D/S
120 time) 4094 (with which creation time) of the D/S frames combination
to transmit U/S received); value shall be
frames at SNI) same as the U/S C-VID
113-R- P-bits N/A A specific value (from 0 to A specific value ‘Any’ (not filtered ‘Any’ (not filtered N/A Default U/S-
6.3.4- 7) (with which to transmit (from 0 to 7) against) against) D/S
130 U/S frames at the SNI) (with which to combination
transmit U/S Default
frames at the SNI)
113-R- TPID N/A A specific value (0x88a8 A specific value A specific value A specific value (0x88a8, N/A Default U/S-
6.3.4- (default), 0x8100, 0x9100, (0x88a8, 0x8100 (0x88a8 (default),, 0x8100 (default), D/S
140 etc.) (with which to (default), 0x9100, 0x8100, 0x9100, 0x9100, etc.) (against combination
transmit U/S frames at the etc.) (with which etc.); value shall be which to filter Inner-
SNI) to transmit U/S same as that for U/S TPID of D/S received
frames at the SNI) frames); value shall be
same as that for U/S
‘Single-tagged UNI, Double-tagged SNI’ VLAN Handling model
113-R- A specific VID (against N/A (S-VID specified at ‘Same as VID N/A (S-VID specified A specific VID (against ‘Copy from Default U/S-
6.3.4- which to filter U/S service instance creation received at UNI’ at service instance which to check inner-VID received Inner-VID D/S
150 frames received at the time) (C-VID or Inner creation time) of the D/S frames at SNI’ combination
UNI) VID) received); value shall be
same as the U/S C-VID
113-R- A specific VID (against N/A (S-VID specified at A specific VID (to N/A (S-VID specified A specific VID (against A specific VID to Symmetric
6.3.4- VID which to filter U/S service instance creation which to translate at service instance which to check inner-VID which to translate Inner-VID
160 frames received at the time) U/S VID received creation time) of the D/S frames the Inner VID (C- translation
UNI and which to at UNI); value received); value shall be VID) received at
translate to C-VID) shall be different same as the U/S C-VID the SNI; value
from the US VID shall be same as
received at UNI the one
configured for U/S
UNI VID
113-R- ‘Any’ (not filtered A specific value (from 0 to ‘Same as U/S p- ‘Any’ (not filtered ‘Any’ (not filtered ‘Copy from D/S Default U/S-
6.3.4- against) 7) (with which to transmit bits received at against) against) Inner p-bits D/S
170 P-bits U/S frames at the SNI) the UNI’ received at the combination
SNI’ (no
translation)


Req. id Notes
113-R- ‘Any’ (not filtered ‘Same as U/S p-bits ‘Same as U/S p- ‘Any’ (not filtered ‘Any’ (not filtered ‘Copy from D/S Copy Inner-p-
6.3.4- against) received at the UNI’ bits received at against) against) Inner p-bits bits to Outer-
180 the UNI’ received at the p-bits
SNI’ (no
translation)
113-R- ‘Any’ (not filtered A specific value (from 0 to A specific value ‘Any’ (not filtered ‘Any’ (not filtered ‘Copy from D/S Inner p-bits
6.3.4- against) 7) (with which to transmit (to which to against) against) Inner p-bits priority re-
190 U/S frames at the SNI) translate U/S p- received at the marking in
bits received at SNI’ (no U/S dir
UNI) translation)
113-R- A specific value A specific value (0x88a8 ‘Same as U/S TPID A specific value ‘Any’ (not filtered ‘Copy from D/S Default U/S-
6.3.4- (0x88a8, 0x8100 (default), 0x8100, 0x9100, received at the (0x88a8 (default), against) Inner TPID D/S
200 (default), 0x9100, etc.) (with which to UNI’ 0x8100, 0x9100, received at the combination
etc.) (against which to transmit U/S frames at the etc.); value shall be SNI’
filter received frames SNI) same as that for U/S
at the UNI)
113-R- A specific value A specific value (0x88a8 A specific two- A specific value A specific two-byte TPID A specific two- Inner TPID
6.3.4- (0x88a8, 0x8100 (default), 0x8100, 0x9100, byte TPID value (0x88a8 (default), value (0x8100, 0x88a8, byte TPID value translation
210 TPID (default), 0x9100, etc.) (with which to (0x8100, 0x88a8, 0x8100, 0x9100, 0x9100, etc.) (against (0x8100, 0x88a8,
etc.) (against which to transmit U/S frames at the 0x9100, etc.) to etc.) (against which which to filter Inner- 0x9100, etc.), to
filter received frames SNI) which to translate to filter received TPID of D/S received which to translate
at the UNI) the TPID received frames at the SNI); frames); value shall be the Inner TPID
at the UNI value shall be same same as that for U/S received at the
as that for U/S SNI; value shall be
same as the U/S
UNI TPID (TPID
translation)
‘TLS – ‘Untagged, Priority tagged, Single tagged at UNI’ mode’ VLAN Handling model
113-R- VID N/A N/A (S-VID specified at N/A N/A (S-VID specified N/A N/A Default U/S-
6.3.4- service instance creation at service instance D/S
220 time) creation time) combination
113-R- P-bits N/A A specific value (from 0 to N/A ‘Any’ N/A N/A Default U/S-
6.3.4- 7) (with which to transmit D/S
230 U/S frames at the SNI) combination
113-R- TPID N/A A specific value (0x88a8 N/A A specific value N/A N/A Default U/S-
6.3.4- (default), 0x8100, 0x9100, (0x88a8 (default), D/S
240 etc.) (with which to 0x8100, 0x9100, combination
transmit U/S frames at the etc.); value shall be
SNI) same as that for U/S

7 Upstream QoS
An overview of the U/S QoS capabilities is provided first, followed by the ONT/ONU U/S Service Traffic Descriptor
parameter-group that includes traffic parameters that are specified at the time of activation of a service traffic flow on a
UNI port.
The QoS capabilities at the ONT/ONU include priority queues (PQs) and their scheduling, traffic rate controlling, and
traffic marking11. The U/S PQs are mapped to T-CONTs, which represent GPON-domain traffic classes at the OLT.
With regard to traffic rate controlling and marking, it shall be noted, as also noted in section 7 of [13], that they are
performed at different granularities for the U/S and D/S direction: on a per PON connection (GEM port) basis in the U/S
direction and on a per-UNI port in the downstream direction. The U/S traffic rate controlling and marking are addressed
through the ONT/ONU Upstream Service Traffic Descriptor (TD) parameters, described in 7.1. The D/S traffic rate
controlling and marking are addressed through the UNI port Downstream Traffic Descriptor parameters, described in
section 7 of [13].
With regard to the T-CONT assignment scheme of how to assign T-CONTs to service instances, as also stated in section 7
of [13], the AOLT shall support the ‘T-CONT per service-type’ scheme. In this scheme a T-CONT is dedicated to a
service type, and the relative- QoS handling of service instances of that type within that T-CONT is performed using the
PQs that are mapped to that T-CONT.
7.1 ONT/ONU Upstream Service Traffic Descriptor (TD) parameter-group
The ONT/ONU Upstream Service Traffic Descriptor parameter-group includes the U/S traffic parameters that are
associated with a traffic flow that is activated for a service instance on a UNI port. The parameters include the priority
level, CIR, and PIR, etc., that pertain to the traffic flow and are specified at the time of activation of a service instance on
a UNI port. The ONT/ONU Upstream Service Traffic Descriptor parameters are defined in Table 8 below and are referred
to from the service type-specific section, section 9. It shall be noted that the parameters in Table 8 do not apply for B-
IPTV; the p-bits for the U/S IGMP control messages are addressed as part of the B-IPTV-specific parameters in 9.3.1.
11
An overview of these capabilities is in G.984.4/Appendix III. Traffic marking refers to marking packets green, yellow or red based on a
color marking algorithm that uses the ingress packet rate and attributes of the traffic descriptor associated to the ingress interface. The
packet color determines the packet drop precedence, which is used by PQ-s to conditionally drop packets during congestions; red
packets are dropped immediately, yellow packets are marked as drop eligible, and green packets are marked as not drop eligible.
The functional and OMCI requirements for the AONT with regards to the QoS capabilities are addressed in the AONT SRD and ORD
documents.

Table 8: ONT/ONU Upstream Service Traffic Descriptor parameter group
Req. Access
Reference (if Req.
id Parameter Value (RO, Factory Default Value Notes
any) priority
RW)
113- Priority level One of: RW Service type Default Table G-2 of Represents the priority level (class of service) for the GA
• A specific value of associated Priority IEEE 802.1Q- U/S traffic flow on a UNI port that is activated for a
R-
from 0 to 7 traffic flow value12 2005 service instance, as will be described later in section 9.
7.1- Values include:
10 • Based on p-bits HSI 0
Specific priority level (0 to 7): The priority level that
Voice 713 shall be associated with the U/S traffic flow of the
service instance; this level shall override priority
TLS 3
information in the frames (p-bits, DSCP, etc.). This
priority level, regardless of the received p-bits,
determines the U/S PQ on which to enqueue the frames
of associated traffic flow in the U/S dir; the Priority
level to PQ mapping is defined in the ONT/ONU
Upstream PQ parameter-group defined in [13]/section
8.2.2.
Based on p-bits: The PQ on which to enqueue the U/S
frames of this service instance is determined from the p-
bits in the U/S frames, which can be either the original
p-bits as received at the UNI port or translated values.
The p-bits-to-PQ-mapping parameter defined in the
ONT/ONU Upstream PQ parameter-group defined in
[13]//section 8.2.2 is used for this purpose.
113- CIR (also referred One of: RW Service type Default G.984.4 / GEM Committed information rate. See Reference for details. GA
to as SIR or • ‘Not enforced’ (not of associated CIR traffic
R-
Sustained honored) traffic flow descriptor ME;
7.1- Information Rate) G.984.3 / DBA
20 • 0 to 99.96814 Mbps, HSI 8 Mbps section
in 64 kbps steps
Voice 256 kbps
TLS ‘Not
enforced’
113- PIR One of: RW ‘Not enforced’ G.984.4 / GEM Peak information rate. See Reference for details. GA
• ‘Not enforced’ (can traffic
R-
be unlimited) descriptor;
7.1- G.984.3 / DBA
30 • 0 to 100 Mbps, in section
250 kbps steps
12
Values are based on the recommended traffic type-to-priority level mapping in 802.1Q/Table G-2: 0 – Best Effort traffic, 7 – Network Control traffic, 3 – Critical Applications traffic
13
We use the value ‘7’ here to accommodate BSNL’s requirement, although the recommended p-bit value for voice traffic in 802.1Q-2005/Table G-2 is the value ‘5’.
14
Largest multiple of 64 kbps that is less than 100 Mbps

Req. Access
Reference (if Req.
id Parameter Value (RO, Factory Default Value Notes
any) priority
RW)
113- CBS One of: RW ‘Not enforced’ G.984.4 / GEM Committed burst size; FC
• ‘Not enforced’ (can traffic CBS is used, per the configured Meter type parameter,
R-
be unlimited) descriptor to mark packet color, which indicates packet drop
7.1-
40 • 2000 bytes to eligibility. Packet color is subsequently used by the
300,000 bytes, in priority queues to drop packets conditionally during
steps of 1000 bytes congestions.
113- PBS One of: RW ‘Not enforced’ G.984.4 / GEM Peak burst size; used when the AONT U/S traffic FC
• ‘Not enforced’ (can traffic management mode is ‘priority & rate controlled’;
R-
be unlimited) descriptor determines packet color (per the Meter type
7.1- parameter), which is eventually used by the priority
50 • 2000 bytes to queues.
300,000 bytes, in
steps of 1000 bytes
113- Egress color • No marking RW No marking G.984.4 / GEM This parameter specifies if and how drop precedence is FC
marking (Disabled) traffic to be marked by the ONT on egress packets. The color
R-
• Internal marking descriptor ; marking meter type that is used is specified by the
7.1- IEEE 802.1ad; ‘Color marking Meter type’ parameter.
60 only
RFC 2597 If set to ‘No marking’, color marking at egress is
• DEI
disabled. If set to internal marking only, the externally
• PCP8P0D visible packet contents are not modified, but the packet
• PCP7P1D is identified in an AONT-internal way that indicates its
color to the priority queue.
• PCP6P2D
When set to any other value (DEI, PCP*, etc.), specified
• PCP5P3D
egress color marking shall be performed, including any
• DSCP AF class necessary translation from the marking at ingress, which
is specified by the ‘Ingress color marking’ parameter
(e.g., ingress PCP marking could be translated to DEI
egress marking).
113- Ingress color One of: RW Color-blind (ignore ingress G.984.4 / GEM This parameter specifies if the pre-existing drop FC
marking • Color-blind marking) traffic precedence as marked on the ingress packets is used and
R-
descriptor ; if so how it is marked. For DEI and PCP marking, a drop
7.1- • DEI IEEE 802.1ad; eligible indicator is equivalent to yellow color, otherwise
70 • PCP8P0D RFC 2597 the color is green. For DSCP AF marking, the lowest drop
• PCP7P1D precedence is equivalent to green, otherwise the color is
yellow.
• PCP6P2D
• PCP5P3D
• DSCP AF class
113- Color marking One of: RW RFC 4115 G.984.4 / GEM The color marking meter type, applicable when egress FC
Meter type, • RFC 4115 traffic color marking is enabled.
R-
applicable only if descriptor; RFC
7.1- egress color • RFC 2698 4115; RFC 2698
80 marking is enabled

113-R- Priority:
7.1-90
The AOLT shall support the ONU U/S Service Traffic Descriptor parameters defined in Table 8. GA
The AEMS shall support the configuration and retrieval, using appropriate user interface, of the
ONU U/S Service Traffic Descriptor parameters defined in Table 8.
113-R-
In regards to AEMS presentation of the parameters in Table 8 above for configuration and status Priority:
7.1-
100 retrieval, it is recommended that the following parameters be presented as part of the “basic” GA
parameters, with the remaining presented as part of the “advanced” parameters:
Priority level, CIR, and PIR.
With regard to the priority level parameter in Table 8, the value assigned to it determines the number of PON connections
that need to be created (between the AOLT and AONT) and how they are connected to the U/S PQs, which will be
described as follows. Per the architecture defined in TR-156[9] and the G.984.4 Implementers’ Guide (IG) [8]/section 9.3,
each traffic sub-flow in a GPON system (see Figure 1) that needs a specific traffic class treatment is transported within the
GPON domain over a dedicated PON connection (GEM port). In the context of this document, thus when a service traffic
flow is activated on a UNI port (for a service instance), one or more PON connections need to be created depending on
how the priority level in the U/S Service Traffic Descriptor parameter group, described in Table 8, is assigned for the
associated traffic flow: If an explicit priority level is assigned to the flow, the OLT shall create a single PON connection
(GEM port) for that traffic flow, and associate that connection with an appropriate priority queue (PQ) within the service
type’s T-CONT. Otherwise if the priority level is assigned based on received frames’ p-bits, the AOLT shall create a
group of eight PON connections (one for each p-bit combination) for the service traffic flow and associate them with
appropriate PQs within the service type’s T-CONT15.
It shall be noted that in either of the above cases, the AOLT shall automatically (without operator intervention) create, and
associate to appropriate PQ(s), the PON connection(s) for a given service instance, at the service activation time.
In relation to the above requirements, the AOLT shall support, at the time of activation of a service Priority:
113-R- traffic flow on a UNI port, automatically creating one or more of PON connections (GEM ports) on GA
7.1- which to transport the service traffic flow. The AOLT determines the number of PON connections to
110 create and how they are connected to U/S PQs depending on the priority level setting in the U/S
Service Traffic Descriptor parameter-group for that service traffic flow.
With regard to the CIR parameter in Table 8, the AOLT shall add this parameter to the Assured
113-R- Bandwidth of the T-CONT to which the service instance under question is associated (e.g. the HSI
T-CONT for a HSI service instance). Priority:
7.1-
120 GA
If the specified CIR value cannot be accommodated within the T-CONT, the AOLT and AEMS shall
accordingly report the failure to the operator.
With regard to the PIR parameter in Table 8, per G.984.3, the Maximum Bandwidth assigned to a T-
CONT shall always be higher than or equal to the largest of the PIR rates of its constituent flows. In
113-R- relation to this, for the T-CONT to which the service instance under question is associated, the AOLT
Priority:
7.1-
shall update, as required, its Maximum Bandwidth to reflect the service instance’s configured PIR. GA
130
If the T-CONT Maximum Bandwidth update is required and failed for some reason, the AOLT and
AEMS shall accordingly report the failure to the operator.
15
As described in G.984.4 IG / Section 9.3, in this latter case, the UNI port on which the service is activated is connected to the GEM
ports via a p-bit mapper OMCI ME.

The AOLT shall support reporting to the AEMS the following per-T-CONT current information on a per Priority:
113-R- AONT and per service type basis: Fixed Bandwidth, Assured Bandwidth, and Maximum Bandwidth. GA
7.1- Note: The above bandwidth values for the T-CONTs are not configured directly by the operator and
140 instead are updated and maintained by the AOLT software based on the CIR and PIR values configured
by the operator for the constituent traffic flows in the T-CONTs, as per the previous two requirements.
113-R- The AEMS shall support retrieving and presenting via appropriate user interface the following per-T- Priority:
7.1- CONT information on a per AONT and per service type basis: Fixed Bandwidth, Assured Bandwidth, GA
150 and Maximum Bandwidth.
In addition to the above bandwidth parameters for T-CONTs, in support for the G.984.3 Extended Priority:
113-R-
Bandwidth Assignment model ([3]/section 7.4.5; [9]/Appendix A), the AOLT and the AEMS shall GA
7.1-
160 support specifying and reading of the following parameters on a per AONT and per service type (T-
CONT; in accordance with the ‘T-CONT-per-service-type’ model) basis:
Table 9: Extended Bandwidth Assignment model parameters for T-CONTs
Req. Access Factory Default Req.
Parameter Value Reference Notes
id (RO, RW) Value priority
113- AONT-id String of up to RW N/A N/A Identifies the AONT GA

32 characters, in question.
R-7.1-
in accordance
170 with 114-R-5-
10 of [14]
113- T-CONT (service) One of the RW N/A N/A Identifies the T- GA

type service types CONT (service type)
R-7.1-
(HSI, Voice, B- within the above
180 IPTV, TLS) AONT for which to
configure the
parameters below.
113- Additional-BW One of: RW Service Default [9] / Identifies the GA
eligibility mode • None type Value Appendix A; Additional-BW
R-7.1-
[3] / section eligibility mode for
190 • Non-Assured HSI BE 7.4.5 the AONT and T-
(NA) CONT (service type)
Voice None
• Best Effort in question.
(BE) B-IPTV None
TLS NA
Parameters applicable if ‘Additional-BW eligibility mode’ above is ‘BE’
113- T-CONT One of: RW WRR [9] / The Best Effort T- WRR: GA
scheduling mode • SP Appendix A; CONT scheduling Others: FC
R-7.1-
[3] / section mode.
200 • WRR 7.4.5
• SP+WRR
113- T-CONT Priority 0 to 7 RW 0 [9] / The SP Priority of FC

(applicable for SP Appendix A the T-CONT in
R-7.1-
and SP+WRR question.
210 scheduling modes)
113- T-CONT Weight 1 to 255 RW 1 (by default, all HSI- [9] / The WRR weight of GA
(applicable for service-carrying T- Appendix A the T-CONT in
R-7.1-
WRR and SP+WRR CONTs are allocated question. The
220 scheduling modes) the same weight) functional
requirement is in
[26]/39-R-3.3-0115.

Per-traffic flow D/S traffic management: In addition to the above requirements for U/S traffic management, the following
is a requirement for specifying/reading the priority level in the D/S direction on a per traffic flow basis (Note: unlike in
the U/S direction, other traffic parameters such as CIR and PIR, apply only on a per UNI port basis and not on a per traffic
flow basis; these parameters are discussed in [14]/section 8.2.1):
Access
Req. Reference Req.
Parameter Value (RO, Factory Default Value Notes
id (if any) priority
RW)
113- Priority One of: RW Service Default Table G-2 This parameter is the D/S equivalent of GA
level • A type of Priority of IEEE the ‘Priority level’ parameter of the U/S
R-
specific associated value 802.1Q- Traffic Descriptor above and represents
7.1- traffic 2005 the priority level (traffic class) to apply in
230 value
from 0 flow the D/S direction to the associated traffic
to 7 flow that is activated for a service
HSI 0 instance on a UNI port, as will be
• Based on described later in section 9. Values Formatted: Bullets and Numbering
Voice 716
p-bits include:
TLS 3
Specific priority level (0 to 7): The
priority level that shall be associated with
the D/S traffic flow of the service
instance; this level shall override priority
information in the frames (p-bits, DSCP,
etc.). This priority level, regardless of the
p-bits in the received frames, determines
the D/S PQ on which to enqueue the
frames of associated traffic flow in the
D/S dir; the Priority level to PQ mapping
is defined in the Priority level parameter
of the ONT/ONU D/S PQ parameter-group
defined in [13]/section 8.2.1.
Based on p-bits: The PQ on which to
enqueue the D/S frames of this service
instance is determined from the p-bits in
the D/S frames, which can be either the
original p-bits as received at the SNI port
or translated values. The p-bits-to-PQ-
mapping parameter defined in the
ONT/ONU D/S PQ parameter-group
defined in [13] /section 8.2.1 is used for
this purpose.
8 General Service Configuration & Management Requirements

This section addresses general requirements with regards to configuration and management of services; the requirements
in this section apply to all the service types introduced in Table 1.
A service instance is uniquely identified by a service name and an S-VID, which both are specified at the time of service
instance creation, as will be discussed in section 9. As shown in the first step of Figure 2, the S-VID membership
configuration for the SNIs (i.e. SNI to S-VID association) is performed as part of the basic Layer-2 configurations
performed at the AOLT, as addressed in [20].
At the time of creation of a service instance, the AOLT and the AEMS shall check that the specified Priority:
113-R-
0-10
service name and the S-VID for the service instance do not already exist and notify to the operator if GA
the uniqueness check fails.
16
We use the value ‘7’ here to accommodate BSNL’s requirement, although the recommended p-bit value for voice traffic in 802.1Q-
2005/Table G-2 is the value ‘5’.

At the time of activation of a service instance on a UNI port, if the specified service delivery Priority:
topology is p2p (1:1) and the service model is a ‘Double tagged SNI’ one (i.e., ‘Untagged UNI, Checking
Double-tagged SNI’ or ‘Single tagged UNI, Double tagged SNI’), the AOLT and the AEMS shall within a
113-R- check for uniqueness of the S-VID/C-VID combination as follows: single
0-20 a) The AOLT shall check that the specified S-VID/C-VID combination is unique within the AOLT AOLT:
system. GA
b) The AEMS shall check that the specified S-VID/C-VID combination is unique within the AOLT Others:
system and also across AOLTs that are managed by the AEMS. FC17
User interface alternative: With regard to the AEMS user interface for specifying the S-VID at the Priority:
time service instance creation (as will be shown in section 9), while allowing an already existing S- FC
113-R-
0-30
VID (configured per [20]) to be specified, as a convenient user-interface alternative, the AEMS shall
allow invoking the user interface that is used to create a new S-VLAN (and configure its membership
for SNI interfaces) (see [20]) from also within the contexts of service instance creation18.
Where ever an UNI port or an AONT is required to be specified or presented in any of the Priority:
requirements in this document (e.g., service activation on a UNI port of an AONT), the AONT shall GA
113-R- be referred or identified in the AEMS in a form that identifies the following information: the AOLT
0-40 system, the shelf within the AOLT system, the GPON line card within the AOLT shelf, the PON port
within the AOLT GPON line card, and the AONT system name [13]; additionally, for the UNI port,
the port label as it appears externally shall also be included as part of this information.
Virtual AONTs: The AOLT shall support configuring and modifying service activation parameters on Priority:
an UNI port even when the AONT is not physically present on the PON or has not been activated yet FC
113-R- (such an AONT is referred to as a virtual AONT; see also [13]/section 5). The service activation
0-50 settings configured on a virtual AONT shall be applied after the AONT has been discovered on the
specified PON, successfully authenticated, validated, and activated, as described in the ONT/ONU-
level parameters section of [13].
9 Service type-specific Parameters

The sub-sections in this section address the service-type specific parameters for the different service types introduced in
Table 1. These sub-sections invoke the VLAN Handling and the U/S traffic management requirements that were discussed
in the previous sections.
9.1 HSI Service

9.1.1 HSI Service requirements
The AOLT and the AEMS shall support the HSI Service parameters in Table 10 below, which apply on a per HSI service
instance basis.
17
In absence of support for this, the onus is on the operator to ensure the uniqueness of the S-VID/C-VID combination across AOLTs.
18
For example, a special ‘Create new S-VLAN’ option could be provided as an option to the list of already existing/created S-VLANs.

Table 10: HSI Service (per-service instance) parameters
Req. id Access Default Reference Req.
Parameter Value Notes
(RO, RW) value (if any) priority
113-R- Service name Display-String RW N/A N/A The AEMS and AOLT shall support specifying/reading via this parameter a human GA
of up to 32 readable name with which to uniquely refer to this service instance. In relation
9.1.1-10
characters to this, the AOLT and AEMS shall check for the uniqueness of this parameter’s
value against those of configured service instances, as discussed in section 0.
113-R- SVLAN Id (S- One of: RW N/A N/A The AEMS and AOLT shall support specifying/reading via this parameter the S- GA
VID) • ‘None’ VLAN id for this service instance. (This VID represents the Outer S-VID when
9.1.1-20
(Untagged or frames are double tagged at the SNI.)
priority The P-bits and TPID parts of the S-Tag are specified at the time of activation of a
tagged) service flow for this service instance on an UNI port, as noted earlier.
• A value With regard to the AEMS user interface, an option to create a new S-VLAN from
between 2 within this (services) context is discussed in section 0.
and 4094
113-R- Service • p2mp (N:1) RW p2mp TR-101/R- The AEMS and AOLT shall support specifying/reading via this parameter the GA
delivery • p2p (1:1) (N:1) 33 desired service delivery topology (as defined in 6.1) for this service instance.
9.1.1-30
topology As noted earlier, for the p2p topology, the C-VID (inner tag at SNI) is specified at
the time of activation of service flow for this service instance on an UNI port.
113-R- Per-SVLAN security related settings (per TR-156/R-116-R-112; IP address spoofing prevention, etc.) shall be supported as addressed in the AOLT-4000 Per [25]
MAC- & IP- Anti-spoofing SRD [25]
9.1.1-40
Parameters applicable for the p2mp (N:1 VLAN) service delivery topology
113-R- Filter D/S Enabled, RW Disabled TR-101/R- The AOLT and AEMS shall enable/disable per this parameter GA
broadcast Disabled 88 discarding/forwarding of D/S broadcast frames for this service instance received
9.1.1-50
frames at the SNI19.
113-R- Filter D/S Enabled, RW Disabled TR-101/R- The AOLT and AEMS shall enable/disable per this parameter discarding / GA
multicast Disabled 88 forwarding of D/S multicast frames for this service instance received at the SNI.
9.1.1-60
frames
113-R- Subscriber Enabled, RW Enabled TR-101/R- The AOLT and AEMS shall enable/disable per this parameter subscriber to GA
isolation Disabled 40 subscriber communication (among subscribers served by this AOLT) for this
9.1.1-70
status service instance.
113-R- Layer-2 DHCP Enabled, RW Enabled TR-101/R- The AOLT and AEMS shall enable/disable per this parameter the Layer 2 DHCP ‘Enabled’:
Relay Agent Disabled 96, TR- Relay Agent function for this service instance. GA
9.1.1-80
enable 101/R-97 ‘Disabled’:
FC
19
As described in TR-101, if a service for which filtering D/S broadcast frames is enabled (e.g., for security reasons) but does rely on protocols that use broadcast frames
(e.g., ARP), the AOLT is required to implement an interworking function for each of such protocols, which shall ensure that the downstream broadcast frames are forwarded
only to the destination AONT, on the appropriate PON connection (GEM port) corresponding to the destination UNI port on the AONT. See [25] for details.

Parameters applicable for the p2p (1:1 VLAN) service delivery topology
113-R- MAC learning Enabled, RW Disabled TR-156/R- The AOLT and AEMS shall enable/disable per this parameter MAC learning for p2p FC
Disabled 32 S-VLANs.
9.1.1-90
In regards to AEMS presentation of the parameters in Table 10 above for configuration and status retrieval, it is recommended that the Priority:
113-R- following parameters be presented as part of the “basic” parameters, with the remaining presented as part of the “advanced” parameters:
9.1.1-100
GA
Service name, S-VLAN id, service delivery topology, and subscriber isolation status (only for p2mp service delivery topology).
113-R- The AOLT and AEMS shall support configuration of up to a maximum of 1024 HSI Service instances (S-VIDs) per AOLT system. Priority:
9.1.1-110 (Service activation requirements for the UNI ports (at the AONT) are discussed in the next section.) GA
9.1.2 HSI Service activation requirements

The AOLT and the AEMS shall support the HSI Service activation parameters in Table 11, which apply when a traffic flow corresponding to a HSI service
instance is activated on a UNI port. The traffic flow is characterized via the VLAN Handling and QoS/traffic parameters in the table.
Table 11: HSI Service activation parameters
113-R- User port An Ethernet UNI port identifier. RW N/A N/A The UNI port on which to activate the HSI GA
service. The AEMS and AOLT shall identify the
9.1.2-10
port in accordance with 113-R-8-40.
113-R- Service Display String of up to 32 characters RW N/A N/A Identifies the HSI service instance (created per GA
name Table 10 above) to activate on the user port
9.1.2-20
specified above. The AOLT and AEMS shall check
for uniqueness of service name per 113-R-8-10.
113-R- Flow name Display String of up to 32 characters RW N/A N/A Identifies the HSI service flow to activate on the GA
user port for the specified service instance. (The
9.1.2-30
flow’s VLAN and QoS Handling are specified in
the remainder of the parameters in the table.)
113-R- Activation One of: ‘Activated’, ‘Deactivated’ RW ‘Deactiva N/A The AEMS and AOLT shall support specifying via GA
status ted’ this parameter the activation state of the
9.1.2-40
specified traffic flow. When this param. is set to
‘Activated’ (‘Deactivated’), the AOLT shall
instruct the AONT to configure (release) the
internal resources used at the AONT (GEM port,
VLAN filter, PQ, etc.).

113-R- VLAN One of: RW Untagged The AEMS and AOLT shall support specifying GA
Handling at UNI, using this parameter the service model (VLAN
9.1.2-50
model
• Untagged at UNI, Single-tagged at SNI Single- Handling performed at the UNI and SNI, in the
(Service • Single tagged UNI, Single tagged SNI tagged at U/S and D/S directions) with which to handle
model) SNI traffic flows associated with the specified
• Untagged UNI, Double tagged SNI service instance and UNI port.
• Single tagged UNI, Double tagged SNI (last
two only for p2p service delivery topology)
113-R- VLAN Handling parameters: The AEMS and AOLT shall support configuration and status retrieval of the VLAN Handling parameters, defined in Table 3 Per Table 4,
9.1.2-60 and Table 4, for the specified traffic flow associated with the specified service instance and UNI port. In relation to this, as also noted in section 6.3 Table 5 and
and in accordance with Table 5 and Table 7, the AEMS shall support presenting, using appropriate user interface, only the VLAN Handling parameters Table 7
that are specific to the service instance’s service delivery topology (see Table 10) and the service model specified above.
113-R- U/S QoS/TM parameters: The AEMS and AOLT shall support configuration and status retrieval of the U/S Qos/TM parameters, defined in Table 8, for Per Table 8
9.1.2-70 the specified traffic flow associated with the specified service instance and UNI port. See 113-R-7.1-80 for AEMS presentation-specific requirements.
Note: For HSI flows that are layer-3 routed (as opposed to layer-2 bridged), as part of the Residential Gateway (RG) function (applicable for AONT-1240, AONT-1241, etc. per
[13]) in the AONT, the SFU ORD [17]/section 8 discusses the RG requirements related to mapping of this (GPON-domain) traffic flow to a WAN-side IP subnet (of the RG) in the
D/S direction and to a LAN-side IP subnet and a RG connection (combination of source IP, destination IP, , and layer 4 protocol, source port, and destination port) in the U/S
direction.
113-R- For the AONT models in [13] that support Ethernet UNI ports (i.e., AONT-100C, AONT-1240, AONT-2244, AONT-3030, etc.), the AOLT Priority:
9.1.2-90 and AEMS shall support activation of up to a maximum of 8 (eight) HSI Service traffic flows (per Table 11 above) per Ethernet UNI port20. GA
20
Allows operator to deliver up to 8 different HSI traffic flows (with different QoS (PIR, CIR, etc.) and/or VLAN Handling) on the same UNI port, on same or different service
instances. The limit of ‘8’ comes from consideration of the current VLAN- and QoS handling limits of AONT-100/C (SW limit of up to 12 VLANs per Ethernet UNI port, #GEM ports,
etc.). If the specified limit cannot be supported due to implementation constraints (for any of the applicable AONT models in [13]), the ERD shall reflect the same. Also if in the
future, different maximum numbers are required for different AONT models, this requirement shall be revised accordingly.

9.2 Voice Service

This section addresses only the VLAN Handling requirements for the Voice service. The SIP and POTS related
configuration requirements for the Voice service are addressed in the VoIP OA&M SRD [24]. The AOLT implementation
of the Voice service shall in general comply with section 11 of the G.984.4 IG [8].
9.2.1 Voice Service parameters
The AOLT and AEMS shall support the Voice service parameters shown in Table 12 below that apply on a per Voice
Service instance basis.
Table 12: Voice Service (per-service instance) parameters
113-R- Service Display-String of up to 32 RW N/A N/A Same as that for the HSI GA
name characters Service in Table 10 (113-R-
9.2.1-10
9.1.1-10).
113-R- SVLAN Id One of: RW N/A N/A Same as that for the HSI GA
(S-VID) • ‘None’ (Untagged or Service in Table 10.
9.2.1-20
priority tagged)
• A value between 2 and 4094
113-R- Service • p2mp (N:1) RW p2mp TR- Same as that for the HSI GA
delivery • p2p (1:1) (N:1) 101/R-33 Service in Table 10.
9.2.1-30
topology
113-R- Per Voice Service S-VLAN-level parameters such as that for enabling/disabling of ‘Direct RTP forwarding’ as GA
addressed in [22] and [24].
9.2.1-40
The AOLT and AEMS shall allow configuration of up to a maximum of 512 Voice Service instances (S- Priority
113-R-
9.2.1-50
VIDs) per AOLT system21. (Service activation requirements for the UNI ports (at the AONT) are : GA
discussed in the next section.)
9.2.2 Voice Service activation requirements

The AOLT and the AEMS shall support the Voice Service activation parameters in Table 13 below, which apply when a
traffic flow corresponding to a Voice service instance is activated on a UNI port. The traffic flow is characterized via the
VLAN Handling and QoS/traffic parameters in the table.
21
The rather high maximum number of 512 Voice S-VLANs is mainly to accommodate the p2p service delivery topology, as with the
p2mp (N:1) topology a single or a handful of S-VLANs per AOLT is sufficient to deliver the Voice service.

Table 13: Voice Service activation parameters
Req. id Access
Default Reference Req.
Parameter Value (RO, Notes
value (if any) priority
RW)
113-R- User port A POTS UNI port RW N/A N/A The UNI port on which to activate GA
identifier. the Voice service. The AEMS and
9.2.2-10
AOLT shall identify the port in
accordance with 113-R-8-40.
113-R- Service Display String of up to RW N/A Identifies the Voice service GA

name 32 characters instance (created per Table 12
9.2.2-20
above) to activate on the user port
specified above. The AOLT and
AEMS shall check for uniqueness of
service name per 113-R-8-10.
113-R- Flow name Display String of up to RW N/A N/A Identifies the Voice service flow to GA
32 characters activate on the user port for the
9.2.2-30
specified service instance. (The
flow’s VLAN and QoS Handling are
specified in the remainder of the
parameters in the table.)
113-R- Activation One of: ‘Activated’, RW ‘Deacti N/A The AEMS and AOLT shall support GA
status ‘Deactivated’ vated’ specifying via this parameter the
9.2.2-40
activation state of the specified
traffic flow. When this param. is
set to ‘Activated’ (‘Deactivated’),
the AOLT shall instruct the AONT to
configure (release) the internal
resources used at the AONT (GEM
port, VLAN filter, PQ, etc.).
113-R- VLAN One of: RW Untagg The AEMS and AOLT shall support GA
Handling ed at specifying using this parameter the
9.2.2-50
model
• Untagged at UNI, UNI, service model (i.e., VLAN Handling
Single-tagged at SNI
(Service Single- performed at the UNI and SNI, in
model) • Untagged UNI, tagged the U/S and D/S directions) with
Double tagged SNI at SNI which to handle traffic flows
(only for p2p service associated with the specified
delivery topology) service instance and UNI port.
113-R- VLAN Handling parameters: The AEMS and AOLT shall support configuration and status retrieval of the VLAN Per Table
9.2.2-60 Handling parameters, defined in Table 3 and Table 4, for the specified traffic flow associated with the 3, Table 4,
specified service instance and UNI port. In relation to this, as also noted in section 6.3 and in accordance Table 5 and
with Table 5 and Table 7, the AEMS shall support presenting, using appropriate user interface, only the Table 7
VLAN Handling parameters that are specific to the service instance’s service delivery topology (see Table
10) and the service model specified above.
113-R- U/S QoS/TM parameters: The AEMS and AOLT shall support configuration and status retrieval of the U/S Per Table 8
9.2.2-70 Qos/TM parameters, defined in Table 8, for the specified traffic flow associated with the specified service
instance and UNI port. See 113-R-7.1-80 for AEMS presentation-specific requirements.
113-R- For the AONT models in [13] that support POTS UNI ports (i.e., AONT-100C, AONT-1240, AONT- Priority
9.2.2-90 2244, AONT-3330, etc.), the AOLT and AEMS shall support activation of up to a maximum of 4 : GA
(four) traffic flows per POTS UNI port22.
22
This allows up to 4 different traffic flows on the same UNI port. As with the HSI service, if in the future different maximum numbers
are required for different AONT models, this requirement shall be revised accordingly.

9.3 Broadcast-IPTV Service
Due to the point to multipoint nature of its traffic, the Broadcast-IPTV service is always delivered using the p2mp (N:1)
VLAN forwarding paradigm. Multicast data traffic and downstream IGMP signaling traffic (IGMP query message, etc.)
use a dedicated unidirectional (AOLT to AONT) PON connection (GEM port). Therefore the upstream IGMP signaling
traffic (AONT to the AOLT) shall need to be transported over a separate PON connection. For this purpose a bidirectional
PON connection (GEM port) that is associated with the AONT’s IPTV UNI port that supports the highest-priority traffic
class for that port. This upstream IGMP signaling PON connection (GEM port) could possibly be shared by other services
supported on the same UNI port that share the traffic class (TR-156/R-79).
It shall be noted that the Broadcast-IPTV Service relies on the IGMP snooping related functional requirements that are
addressed in the Layer-2 SRD / IGMP sections and in TR-156 / Section 5.3.
The IPTV Service related parameters are grouped as follows: (i) parameters that apply on a per Broadcast-IPTV Service
instance (i.e. multicast VLAN) basis, (ii) parameters that apply when a Broadcast-IPTV Service instance is activated on
an Ethernet UNI port (e.g., allowed multicast group addresses, etc.), and (iii) parameters that are not specific to any
specific Broadcast-IPTV Service but apply to the UNI port on a whole. These parameter-groups are addressed in the
following subsections.
Implementers Note: In the requirements in the following subsections, the ERD shall indicate if a requirement that is called
out for the AOLT cannot be implemented in the AOLT due to implementation constraints and instead is implemented in
the AONT, and vice versa for requirements called out for the AONT.
9.3.1 Broadcast-IPTV (B-IPTV) Service requirements
The AOLT and AEMS shall support the B-IPTV service parameters shown in Table 14 below, which apply on a per B-
IPTV service instance basis.

Table 14: Broadcast-IPTV Service (per-service instance) parameters

Access Default Reference (if Req.
Req. id Parameter Value (RO, RW) Notes
value any) priority
113-R- Service name Display-String of up to 32 RW N/A Same as that for the HSI Service in Table 10 (113-R-9.1.1-10). GA
characters
9.3.1-
10
113-R- SVLAN Id (S- One of: RW N/A G.984.4 / Same as that for the HSI Service in Table 10. Identifies the GA
VID) / • ‘None’ (Untagged or priority Multicast multicast-VID for this B-IPTV service instance.
9.3.1-
Multicast VID tagged) Operations Also, as noted earlier, the service delivery topology for B-
20 Profile ME; TR-
• A value between 2 and 4094 IPTV Service is always p2mp (N:1).
156/R-76
OLT-specific B-IPTV Service parameters
113-R- IGMP One of: RW IGMPv2 TR-156/{R-88, IGMP processing mode at the AOLT for the specified service IGMPv2
processing • IGMPv3 TS
23 SPR R-102 to R-104} instance (multicast VLAN). The modes are as defined in TR- SPR,
9.3.1-
mode at OLT TR-101/{R-202, 101 / ‘Key Terminology’ section. IGMPv3
30 • IGMPv3 SPR
23
SPR &
23
R-209, R-221} The AOLT and AEMS shall support specifying/reading via this
• IGMPv3 Proxy parameter the IGMP processing mode for the specified ‘Discard’
options:
• IGMPv2 TS service instance (multicast VID). See [22]/IGMP sections and
GA
• IGMPv2 SPR TR-156/Section 5.3 for the IGMP snooping related functional
requirements. Other
• IGMPv2 Proxy values:
Note: In the context of this document, the IGMPv3 options
• Transparent Forwarding (no FC
need only support the IGMPv3 control plane aspects (‘IGMPv3
snooping) compatibility’) including matching the source IP address in
• Discard IGMPv3 messages against configured allowed values.
113-R- Source IP One of: RW ‘Any’ G.984.4 / The AOLT and AEMS shall support specifying/reading via this GA
address(es) • ‘Any’ (ignored) (ignored) Multicast parameter the allowed source (video server) IP address(es)
9.3.1-
Operations for this service instance.
40 • List24 or range of IP Profile ME; TR- When IGMPv3 TS or IGMPv3 SPR is enabled at the AOLT for
addresses 156/{R-76, R- this service, the AOLT shall match received U/S IGMP
78, R-84} messages against this parameter before configuring entries in
the multicast groups table.
113-R- Group • ‘Any’ RW ‘Any’ G.984.4 / The AOLT and AEMS shall support specifying/reading via this GA
address(es) • Multicast parameter the allowed multicast groups for this service
9.3.1- List or range of Group IP
addresses Operations instance.
50 Profile ME; TR- The AOLT shall maintain a per-multicast-VID ‘acceptable
156/{R-76, R- multicast groups list’ per this parameter and shall match
78, R-84} received IGMP Join messages against this list before
configuring the multicast groups. Deleted: 113-R-9.3.1-60 ... [1]
23
TS – Transparent Snooping; SPR – Snooping with Proxy Reporting. Also, all the IGMPv3 options include inherent backward support for IGMPv2.
24
The list may include a single entry.

value any) priority
113-R- U/S IGMP One of : RW ‘No limit’ TR-156/R-87 The AOLT and AEMS shall support specifying/reading via this GA
message rate • ‘No limit’ parameter the rate limit for U/S IGMP messages associated
9.3.1-
limit at OLT with the B-IPTV service (multicast-VID) that are received
60 • 1-300 messages/s from user ports, before the messages are forwarded to the
specified IGMP snooping function.
113-R- Upstream 0 to 7 RW 7 TR-156/R-105; This parameter is applicable for the IGMPv3 SPR & IGMPv2 GA
IGMP p-bits at TR-101/R-215; SPR modes and determines the p-bits with which the AOLT
9.3.1-
AOLT Table G-2 of shall mark the U/S IGMP messages generated locally by these
70 IGMP snooping modes (as part of proxy reporting).
IEEE 802.1Q-
2005
ONT/ONU-specific parameters25
IGMP SFU AONTs:- RW SFU TR-156/R-88; The IGMP processing mode at the AONT for the specified 26
113-R- FC
processing One of: AONTs: TR-101/{R-202, service (VID). The modes are as defined in TR-101/‘Key
9.3.1-
mode at • IGMPv3 TS IGMPv3 R-209, R-221} Terminology’ section.
80 ONT/ONU
• IGMPv2 TS TS The AOLT shall instruct the AONT to process per this
MDU parameter the received IGMP messages associated with the
• Transparent Forwarding (no
AONTs : B-IPTV service (multicast-VID).
snooping)
IGMPv3
• Discard
SPR
MDU AONTs:-
One of:
• IGMPv3 TS
• IGMPv3 SPR
• IGMPv3 Proxy
• IGMPv2 TS
• IGMPv2 SPR
• IGMPv2 Proxy
• Transparent Forwarding (no
snooping)
• Discard Deleted: 113-R-9.3.1-100 ... [2]
113-R- Upstream 0 to 7 RW 7 TR-156/R-94; Defines the p-bits that the AOLT shall instruct the AONT to GA
IGMP p-bits at TR-101/R-215; mark the U/S IGMP messages (for this multicast-VID) with;
9.3.1-
AONT Table G-2 of applies to both messages received from users and locally
90 generated by the IGMP snooping function.
IEEE 802.1Q-
2005 Deleted: 113-R-9.3.1-120 ... [3]
25
Implementers note: The AOLT can optionally defer applying of these parameters onto an AONT to the time of activation of this service instance on an UNI port of the AONT (as
discussed in 0).
26
For the 2.0 release, the IGMP processing mode at the AONT shall be set to the same mode as that for the AOLT (per the ‘IGMP processing mode at the OLT’ parameter).

value any) priority
113-R- Imputed • None RW None G.984.4 / This parameter represents the aggregate D/S bandwidth that FC
Bandwidth • Multicast is attributed to the multicast groups associated with this
9.3.1- 1 to <Max. line rate> Mbps,
with a granularity of 1 Operations service instance and is used in Multicast-CAC checks at the
100 Profile ME AONT. Specifically, when multicast-CAC is enabled on an UNI
Mbps; where <Max. line
rate> is 100 Mbps or 1000 port (see Table 16) on an AONT, the AONT shall, on receiving
Mbps depending on the on that port a U/S IGMP Join for this service instance
AONT. (multicast-VID), use this parameter and the currently
available multicast bandwidth for that port to check against
that port’s maximum multicast bandwidth limit (configurable
parameter in Table 16) before allowing that port to forward
this service’s traffic.
The AOLT shall instruct the AONT to use the specified value
of this parameter in performing Multicast-CAC checks (per
G.984.4 / Multicast Operations Profile ME).
In regards to AEMS presentation of the parameters in Table 14 above for configuration and status retrieval, it is recommended that the Priority:
113-R-
9.3.1-110
following parameters be presented as part of the “basic” parameters, with the remaining presented as part of the “advanced” parameters: GA
Service name, S-VLAN id, and the IGMP processing mode at OLT.
113-R- Priority
The AOLT and AEMS shall support configuration of up to a maximum of 1024 B-IPTV Service instances (multicast VIDs) per AOLT system. : GA
9.3.1-
120 (Service activation requirements for the UNI ports (at the AONT) are discussed in the next section.)
9.3.2 Broadcast IPTV Service activation requirements

The AOLT and the AEMS shall support the B-IPTV Service activation parameters in Table 15 below, which apply when a B-IPTV service instance is activated
on a UNI port.
Table 15: Broadcast-IPTV Service activation parameters
Req. id Access
Reference Req.
Parameter Value (RO, Default value Notes
(if any) priority
RW)
113-R- User port An Ethernet UNI port RW N/A N/A The UNI port on which to activate the B-IPTV service GA
identifier. instance specified below. The AEMS and AOLT shall identify
9.3.2-10
the port in accordance with 113-R-8-40.

Req. id Access
Reference Req.
(if any) priority
RW)
113-R- Service name Display String of up to 32 RW N/A Identifies the B-IPTV service instance (created per Table 14) GA
characters to activate on the user port specified above. The AOLT and
9.3.2-20
AEMS shall check for uniqueness of service name per 113-R-
8-10.
113-R- Service model One of: RW Untagged at The AEMS and AOLT shall support specifying using this GA
(VLAN Handling UNI, Single- parameter the service model (i.e., VLAN Handling
9.3.2-30
model)
• Untagged at UNI, Single- tagged at SNI performed at the UNI and SNI, in the U/S and D/S
tagged at SNI
directions) with which to handle the traffic flows associated
• Single tagged at UNI27, with the specified service instance and UNI port.
Single-tagged at SNI
113-R- VLAN Handling parameters: The AEMS and AOLT shall support configuration and status retrieval of the VLAN Handling parameters, defined in Table 3 and Per Table
9.3.2-40 Table 4, for the traffic associated with the specified service instance and UNI port. In relation to this, as addressed in section 6.3 and in accordance with 3, Table 4,
Table 5 and Table 7, the AEMS shall support presenting, using appropriate user interface, only the VLAN Handling parameters that are specific to the Table 5 and
service instance’s service delivery topology (see Table 10) and the service model specified above. Table 7
113-R- Allowed Source IP • ‘Any of the addresses RW ‘All addresses G.984.4 / The subset of the multicast sources (video servers) among FC
addresses allowed for the service allowed for Multicast those that have been configured for this service instance (in
9.3.2-50
instance’ the service’ Operations Table 14) that is applicable for the specified UNI port. This
• List or range of IP Profile ME; parameter is applicable only when one of the v3 IGMP
addresses TR-156/{R- processing modes is enabled at the AONT for this service
76, R-78, R- (per Table 14).
84}
The AOLT and AEMS shall support specifying via this
parameter the source IP addresses against which to check,
as well as to instruct the AONT to check, received IGMP
messages (on the port for the specified service instance), to
accordingly determine to forward or drop the messages 28.
113-R- Allowed Group One of: RW ‘All addresses ,, The subset of the multicast groups that is forwarded on the FC
addresses • Any of the addresses allowed for user port among those that have been configured for the
9.3.2-60
allowed for the service the service’ specified service instance (in Table 14).
instance’ The AOLT and AEMS shall support specifying via this
• List or range of IP parameter the group IP addresses against which to check, as
addresses well as to instruct the AONT to check, received IGMP
messages (on the port for the specified service instance), to
accordingly determine to forward or drop the messages.
27
For IPTV set-top boxes capable of sending/receiving VLAN tagged frames
28
TR-156 (R-76-78) requires the OLT to match received IGMP messages against source IP (for IGMP v3 messages) and/or group IP addresses, regardless of whether the
ONT/ONU performs the same function; the ONT/ONU is viewed as “un-trustable” by the operator

Req. id Access
Reference Req.
(if any) priority
RW)
113-R- Filter/forward U/S ‘Filter’, ‘Forward’ RW Filter TR-156/R- Filtering or forwarding of upstream multicast data received ‘Filter’: GA
multicast data 85; TR- at the UNI port on the specified multicast-VID. ‘Forward’:
9.3.2-70
traffic 101/R-206 The AOLT and AEMS shall support specifying via this FC
parameter the handling (filter or forward), at the AOLT and
AONT, of U/S multicast data traffic received on the
specified user port tagged with the specified VID.
113-R- Allow/Discard user One of : RW Allow TR-156/R- The AOLT and AEMS shall support specifying/reading via this GA
IGMP messages • Allow 86 parameter whether to allow (for processing) or discard U/S
9.3.2-80
IGMP messages that are received from a user port on which
Discard the specified B-IPTV service instance (multicast-VID) is
activated.
113-R- IGMP snooping – Enabled, Disabled RW Enabled G.984.4/Mu This parameter is N/A when the IGMP processing mode at GA
Immediate Leave lticast the AONT for the specified B-IPTV service instance is set to
9.3.2-90
function at Operations ‘Transparent Forward’ or ‘Discard’.
ONT/ONU Profile; TR- The AOLT and AEMS shall support specifying via this
156/R-91 parameter whether to enable/disable the ‘Immediate
Leave’ function at the AONT for the specified UNI port and
the specified B-IPTV service instance (multicast-VID).
113-R- U/S IGMP message One of : RW ‘No limit’ TR-156/R- The AOLT shall instruct the AONT to rate-limit per this GA
rate limit at ONT • ‘No limit’ 87; G.984.4 parameter the U/S IGMP messages associated with this B-
9.3.2-
/ Multicast IPTV service (multicast-VID) that are received from the
100 • 1-10 messages/s Operations specified UNI port.
Profile ME
113-R- For the AONT models in [13] that support Ethernet UNI ports (i.e., AONT-100C, AONT-1240, AONT-2244, AONT-3030, etc.) the AOLT Priority:
9.3.2-110 and AEMS shall support activation of up to a maximum of 64 B-IPTV Service instances (multicst VIDs) per Ethernet UNI port.29 GA
29
The limit of ‘12’ comes from current SW limitations of AONT-100/C - If this number cannot be supported due to implementation constraints in the AOLT (for any of the applicable
AONT models in [13]), the ERD shall reflect that. Also, if in the future, different maximum numbers are required for different AONT models, this requirement shall be revised
accordingly.

9.3.3 Broadcast IPTV User port requirements
The AOLT and the AEMS shall support the B-IPTV user port parameters in Table 16 below, which are configured on a per
IPTV user port basis and are not in the context of any specific B-IPTV Service instance.
Table 16: Broadcast-IPTV user port parameters
Req. id Access
Parameter Value (RW, Notes
RO)
113-R- User port An Ethernet UNI RW N/A N/A The UNI port for which to configure the GA
port identifier. parameters below. The AEMS and AOLT
9.3.3-
shall identify the port in accordance with
10 113-R-8-40.
Maximum One of: RW ‘Not TR-156/R- The AEMS and AOLT shall support GA
113-R-
simultaneous • ‘Not enforced’ 97; G.984.4 specifying via this parameter the
9.3.3-
groups enforced’ / Multicast maximum number of multicast groups
20 (‘unlimited’) subscriber that the AOLT shall itself, as well as
• 1-64 config. Info instruct the AONT to, allow the UNI port
ME to forward at any time (including all Deleted: Multicast Operations
multicast VIDs)30. Profile ME
113-R- Multicast- • Enforced RW Disabled G.984.4 / The AEMS and AOLT shall support FC
CAC status • Not enforced Multicast enabling/disabling via this parameter the
9.3.3-
subscriber multicast-CAC function at the AONT for
30 config. Info the specified UNI port.
ME When multicast-CAC is enabled, the
AONT uses the ‘Max Multicast Bandwidth’
parameter below and the ‘Imputed
Bandwidth’ parameter (in Table 14) to
perform the CAC checks.
113-R- Max. One of: RW Not- G.984.4 / Maximum aggregate bandwidth of FC

Multicast • Not-enforced enforced Multicast multicast traffic, on all B-IPTV service
9.3.3-
Bandwidth, subscriber instances activated on the specified
40 applicable • 1-<Max. line config. Info port, that is allowed to be forwarded on
only when rate> Mbps, ME the port;
Multicast- with a
granularity of The AEMS and AOLT shall support
CAC (above specifying via this parameter the max.
parameter) is 1 Mbps; where
<Max. line multicast bandwidth as defined above
enforced. that the AOLT shall instruct the AONT to
rate> is 100
Mbps or 1000 check received IGMP-Join messages
Mbps against as part of the multicast-CAC
depending on function. See also notes for the ‘Imputed
AONT type group bandwidth’ parameter in Table 14.
9.4 TLS service

As described in TR-156/{5.1.3 and 5.1.4} and noted in section 6.2, there are two TLS Service models, viz. the ‘TLS –
Untagged, Priority tagged, Single tagged at UNI’ mode (‘Standard’ TLS mode) and the ‘TLS – Double tagged at UNI’
mode. The per-service instance requirements and service activation requirements for the TLS Service are addressed in the
sections below, followed by TLS Service Exception requirements.
9.4.1 TLS Service requirements
The AOLT and AEMS shall support the TLS service parameters shown in Table 17 below, which apply on a per TLS
service instance basis.
30
In relation to this, the AOLT shall itself, and instruct the AONT to, check received IGMP-Join messages against this parameter.

Table 17: TLS Service (per-service instance) parameters
Access
Req. id Parameter Value (RO, Notes
RW)
113-R- Service Display-String RW N/A N/A Same as that for the HSI Service in Table 10 GA
name of up to 32 (113-R-9.1.1-10).
9.4.1-
characters
10
113-R- SVLAN Id • A value RW N/A N/A Same as that for the HSI Service in Table 10. GA
(S-VID) between 2
9.4.1-
and 4094
20
113-R- Local hair- One of: RW Disabled TR-156 / The AOLT and AEMS shall support specifying via GA
pinning • Enabled {5.1.3, this parameter the enabling/disabling of hair-
9.4.1-
status 5.1.4} pinning (bridging at layer 2; similar to that for
30 • Disabled HSI) within the AOLT31 of traffic corresponding
to this service instance among the UNI ports
(belonging to the AOLT) on which this service
instance is activated.
113-R- The AOLT and AEMS shall support configuration of up to a maximum of 512 TLS Service instances Priority:
9.4.1- (TLS S-VIDs) per AOLT system. (Service activation requirements for the UNI ports (at the AONT) are GA
40 discussed in the next section.)
9.4.2 TLS Service activation requirements

The AOLT and the AEMS shall support the TLS Service activation parameters in Table 18 below, which apply when a TLS
Service instance is activated on a UNI port.
Table 18: TLS Service activation parameters
Req. id Access
RW)
113-R- User port An Ethernet UNI RW N/A N/A The UNI port on which to activate the GA
port identifier. TLS service. The AEMS and AOLT shall
9.4.2-
identify the port in accordance with
10
113-R-8-40.
113-R- Service Display String of up RW N/A Identifies the TLS service instance GA
name to 32 characters (created per Table 17) to activate on
9.4.2-
the user port specified. The AOLT and
20
AEMS shall check for uniqueness of
service name per 113-R-8-10.
113-R- Service One of: RW ‘Standard TR- The AEMS and AOLT shall support ‘Standard
model TLS’ 156/{5.1. specifying using this parameter the TLS’
9.4.2-
(VLAN
• ‘TLS – Untagged, 3, 5.1.4} service model (i.e., VLAN Handling mode: GA
30 Handling
Priority tagged,
performed at the UNI and SNI, in the
Single tagged Others: FC
model) U/S and D/S directions) with which to
UNI’ (‘Standard
handle the traffic flows associated with
TLS’)
the TLS service instance and UNI port
• ‘TLS – Double specified above.
tagged UNI’
113-R- VLAN Handling parameters: The AEMS and AOLT shall support configuration and status retrieval of the VLAN Per Table
9.4.2- Handling parameters, defined in Table 3 and Table 4, for the traffic associated with the specified service 5, Table
40 instance and UNI port. In relation to this, as addressed in section 6.3 and in accordance with Table 5 and Table 3, Table 4
7, the AEMS shall support presenting, using appropriate user interface, only the VLAN Handling parameters that and Table
are specific to the service instance’s service delivery topology (see Table 10) and the service model specified 7
above.
31
At the GPON line card or the SWT card depending on the location of the destination UNI port

Req. id Access
RW)
113-R- U/S QoS/TM parameters: The AEMS and AOLT shall support configuration and status retrieval of the U/S Qos/TM Per Table
parameters, defined in Table 8, for the traffic associated with the specified service instance and UNI port. 8
9.4.2-
50
113-R- For the AONT models in [13] that support Ethernet UNI ports (i.e., AONT-100C, AONT-1240, Priority:
9.4.2- AONT-2244, AONT-3030, etc.) the AOLT and AEMS shall support activation of up to only one TLS GA
60 Service instance (TLS S-VID) per Ethernet UNI port32.
9.4.3 TLS Service Exception requirements

With reference to an UNI port on which a TLS Service has been activated, the TLS exception traffic (see TR-156/5.1.3)
refers to traffic that is received or transmitted on that same port but that needs to be handled outside the TLS service context.
Examples include supporting a HSI Service instance (on a separate VLAN) on the same port on which a TLS service has
been activated.
In the services framework described in this document, as noted in section 6.1, the TLS exception traffic shall be configured
as separate service instances (e.g., of HSI Service type) that are activated on the same UNI port that has been enabled for
TLS.
113-R- On an UNI port that has been enabled for TLS, the AOLT and the AEMS shall allow TLS Priority:
9.4.3- exception traffic to be configured as separate non-TLS service instances (as addressed in the FC
10 previous sections) and activated on the same UNI port.
9.5 Video on Demand (VoD) Service

In contrast with the Broadcast-IPTV service, the traffic corresponding to a VoD Service is unicast in nature and shall be
transported within the GPON domain over a unicast (bidirectional) PON connection.
113-R- In R2.0, the VoD Service shall be supported as a special form of the HSI Service, supporting the Priority:
9.5-10 parameters described in section 9.1. GA
If required in a future release, a new VoD service type shall be created in which VoD Service-specific parameters shall be
added as appropriate.
9.6 External-VoIP Service
113-R- In R2.0, the External-VoIP Service shall also be supported as a special form of the HSI Service, Priority:
9.6-10 supporting the parameters described in section 9.1. GA
If required in a future release, a new VoD service type shall be created in which VoD Service-specific parameters shall be
added as appropriate.
10 References
[1] ITU-T Recommendation G.984.1, Gigabit-capable Passive Optical Networks (GPON): General characteristics, March,
2008
[2] ITU-T Recommendation G.984.2, Gigabit-capable Passive Optical Networks (GPON): Physical Media Dependent
(PMD) layer specification, February, 2006
[3] ITU-T Recommendation G.984.3, Gigabit-capable Passive Optical Networks (G-PON): Transmission convergence layer
specification, March, 2008
32
Maximum only one TLS service instance on an UNI port since that TLS instance, by definition, includes all traffic on that port, except for
the TLS-Exception traffic (discussed in the next section), which is handled as separate traffic flows.

[4] ITU-T Recommendation G.984.4, Gigabit-capable Passive Optical Networks (G-PON): ONT management and control
interface specification, March, 2008, with Amendment 1 (June 2009), and Amendment 2 (Nov. 2009)
[5] ITU-T Draft Recommendation G.984.5, Enhancement band for gigabit capable optical access networks, September, 2007
(PMD) layer specification, Amendment 1, February, 2006
(PMD) layer specification, Amendment 2, March, 2008
[8] G.984.4 Implementer’s Guide, Rev. 2.9, August 2009
[9] TR-156, Using GPON Access in the context of TR-101, Broadband Forum, Issue 1, Dec. 2008
[10] TR-101, Migration to Ethernet Based DSL Aggregation, DSL Forum, April 2006
[11] TR-167, GPON-fed TR-101 Ethernet Access Node., Broadband Forum, Issue: 1, Feb. 2010
[12] IEEE 802.1ad, Virtual Bridged Local Area Networks, Amendment 4: Provider Bridges, IEEE, 2005
[13] Release-2 Planning and Tracking sheet, 19th April, 2010
[14] ONT/ONU Configuration & Management Requirements for the AOLT System, 191-00000114, Rev. 1.0, May 2010
[15] AOLT-4000 GPON PMD & TC layer requirements for Alphion GPON system, 191-0000049, Rev. 1.0, Apr. 2010
[16] xDSL OAM Requirements SRD, 191-0000084, Rev. 1.0, Nov., 2009
[17] SFU and SBU OEM/ODM Requirements Document, 191-0000056, Rev. 1.0, July, 2009
[18] MDU System Requirement Document, 191-0000027, Rev. 1.1, May, 2009
[19] Alphion GPON OLT (AOLT) Provisioning – Node level Provisioning Requirements SRD, 191-0000088, Nov., 2009
[20] Alphion GPON OLT (AOLT) Provisioning – SWT Card Provisioning Requirements SRD, 191-0000089, Apr. 2010
[21] Alphion GPON OLT (AOLT) Provisioning – GLC Card Provisioning Requirements SRD, 191-0000090, Nov., 2009
[22] AOLT-4000 Layer-2 SRD, 191-0000038, Rev 2.0, March 2010
[23] TR-156 Conformance Requirements for the AOLT System, 191-0000080, Rev 1.0, April 2010
[24] VoIP OAM System Requirements Document, 191-0000085, Rev. 1.0, Jan. 2010
[25] AOLT-4000 MAC- and IP- Anti-spoofing Requirements, 191-0000110, Rev 1.0, April 2010
[26] DBA SRD, 191-0000039, Rev. 1.0, June 2009
[27] Access Business Unit Product Roadmap, Nov. 2009
[28] G28/G80/G100 OMCI Specification, R3.1.1, Cambridge Industries Group (CIG), April 2009
[29] BL3458 Quad GPON OLT Controller datasheet, v1.45, August 2008
11 Acronyms, Abbreviations and Definitions

ANI Access Node Interface
AOLT Alphion OLT
AONT Alphion ONT33
C-Tag The innermost VLAN tag as defined in IEEE 802.1ad and having an
EtherType value of 0x8100
C-VID The VLAN ID value of some C-Tag
C-VLAN The VLAN defined by some C-VID
CIR Committed Information Rate
CPE Customer Premises Equipment
CPN Customer Premises Network
CTL AOLT Controller Card
DHCP Dynamic Host Configuration Protocol
DSCP Differentiated Services Code Point
33
Note: AONT in this document is used as a general term to refer to all existing and future flavors of Alphion’s ONT solution, including the
CIG based AONT, the Acorn ONT, and MDU ONT; where distinction is required ‘SFU AONT’ and ‘MDU AONT’ are used.

GEM GPON Encapsulation Mode
GLC GPON Line Card
C-Tag The innermost VLAN tag as defined in IEEE 802.1ad and having an
EtherType value of 0x8100
C-VID The VLAN ID value of some C-Tag
C-VLAN The VLAN defined by some C-VID
GLC1 GLC employing Alphion FPGA based GPON MAC interfaces
GLC2 GLC employing BroadLight BL3458 based GPON MAC interfaces
GLCP Path-protected version of GLC
GPON Gigabit Passive Optical Network
IGMP Internet Group Multicast Protocol
IN Implementation Note
MAC Multi-Access Control
MDU Multi-Dwelling Unit
NE Network Element
ODN Optical Distribution Network
OMCI ONT/ONU Management Control Interface
ONU Optical Network Unit
ONT Optical Network Terminal
PIR Peak Information Rate
PMD Physical Media Dependent
Q-Tag VLAN tag as defined in IEEE 802.1Q-1998
R/S ITU-T Reference interfaces at the PON port of ONT
RG Residential Gateway
S/R ITU-T Reference interfaces at the PON port of OLT
S-Tag the outermost or single VLAN tag as defined in IEEE 802.1ad
S-VID the VLAN ID value of some S-Tag
S-VLAN the VLAN defined by some S-VID
SFU Single Family Unit
SNI Single Family Unit
SWT AOLT Switch and Timing Card
T-CONT Traffic Container
TC Traffic Class – set of upstream and downstream forwarding behaviors in
a network element (AOLT, AONT)
TCI Tag Control Identifier (IEEE 802.1Q)
TLS Transparent LAN Services
UNI User Network Interface
VBES VLAN for Ethernet Business Service
VLAN Virtual Local Area Network
SWT Switch and Timing Card in the AOLT

12 Planned for future releases
The following are target of a later release:
1) IGMP snooping features
o Configurations related to the ‘Local IGMP Host function / Echo client’ function, per TR-156/{R-99 to R-101,}for supporting
IGMP/PPPoE
o IGMP SPR and IGMP PR mode related parameters for MDU AONT, including: Robustness variable, Querier IP address (for
IGMP PR mode), Query interval, Query max response time, Last member querier interval, etc.
2) TDM service type – A new service type, this will be added after the TDM-SBU functional requirements are done. The VLAN
Handling & GPON-domain QoS handling for the TDM services shall be same as the HSI service type, while the TDM-specific
aspects shall be based on section 9.8 (TDM services) of G.984.4.

I Appendix I – Alphion GPON System Abstraction
I.1 AOLT functional abstraction

Figure 3 presents the functional abstraction of the AOLT network element. The AOLT system is a chassis based system with support for
a maximum of 16 slots per shelf. The first and 16th slots are reserved for the AOLT system controller card, known as the CTL card. The
second and third slots and the 14th and 15th slots are reserved for the system’s switch and timing circuit pack, known as the SWT card.
The remaining 10 slots accept the GPON line card (any of its variants), known as the GLC card, which implements the GPON functions.
The AOLT system on a whole comprises of the Ethernet domain and the GPON domain. While the GPON domain is realized in the GLC
cards, the Ethernet domain is realized in the SWT cards and partly in the GLC cards.
Figure 3: AOLT functional abstraction
I.1.1 Switch and Timing (SWT) Card

The SWT card includes an Ethernet layer-2 aggregation switch and timing hardware circuits. The Ethernet aggregation switch supports
layer-2 switching features such as MAC learning, packet classification, packet filtering, priority queing, QoS-aware traffic management
and double tagging. The subscriber-facing Ethernet ports of the SWT card’s layer-2 aggregation switch are connected over the backplane
to the GLC cards, while the network-facing SNI/uplink Ethernet ports can be connected to upstream devices in the network.

I.1.2 GPON Line Card (GLC)
The GLC card includes an Ethernet layer-2 aggregation switch and a GPON OLT subsystem. The OLT subsystem includes GPON related
functions including GPON PMD & TC layer functions, GEM-Ethernet adaptation, the GPON DBA function, etc.
The Ethernet aggregation switch supports layer-2 switching features including MAC learning, packet classification, packet filtering,
priority queing, QoS aware traffic management and double tagging. As illustrated in Figure 3, the subscriber-facing Ethernet interfaces of
the GLC card’s layer-2 aggregation switch are connected to the Ethernet interfaces of the OLT subsystem, while the network-facing
SNI/uplink Ethernet interface of the aggregation switch is connected over the backplane to the SWT card.
The currently available variants of the GLC card include:
GLC1 – This card is based on Alphion’s FPGA-based GPON MAC implementation
GLC2 – This card is based on BroadLight BL3458 GPON OLT-MAC SoC
GLCP – This card is a path protection version of GLC2 and is also based on BroadLight BL3458 GPON OLT-MAC SoC.
The GLC1 and GLC2 cards feature four GPON OLT-MAC interfaces and four SFP-based optical transceiver interfaces, one per MAC
interface. The GLCP card features four GPON OLT-MAC interfaces, and eight SFP-based optical transceiver interfaces, two (1 working
+ 1 protection) transceiver interfaces per one MAC interface.
GPON OLT subsystem
The OLT subsystem is the key subsystem in the GLC card and implements the functions of GPON TC layer (burst mode clock and data
recovery, Ranging, PLOAM, DBA, etc.), GEM encapsulation, MAC learning (in the upstream direction), packet header modification, and
priority queing, etc. Figure 4 presents a functional abstraction of the OLT subsystem of the GLC card. The OLT subsystem implements
the interworking between the Ethernet and GPON domains through the stages shown in Figure 4.
PON port
Queue
Pkt.
U/S Packet Flow mapping & GPON
Classification,
egress header optionally MAC PMD/TC
CoS
scheduler modification learning layer
assignment
Upstream
Downstream
Pkt. Classification, CoS Packet GPON

D/S egress
assignment & GPON header PMD/TC
scheduler
connection mapping modification layer
Back
plane
Pkt.
U/S Packet Flow mapping & GPON
Classification,
egress header optionally MAC PMD/TC
CoS
scheduler modification learning layer
assignment
Pkt. Classification, CoS Packet GPON

D/S egress
assignment & GPON header PMD/TC
scheduler
connection mapping modification layer
GLC card
Figure 4: GLC OLT subsystem functional overview

In the upstream direction, the processing stages include:
GPON PMD/TC layer: This represents the physical media dependent (PMD) and transmission convergence (TC) layer processing
(per ITU-T Rec. G.984.3 [3]) that incoming GPON layer frames go through.
Packet classification & CoS assignment: This refers to the classification of incoming Ethernet frames into a class of service (priority)
depending on factors such as 802.1p priority bits in the frame or the GPON connection (GEM port) on which the frame was received.
After a priority is assigned to a frame, it is enqueued into an appropriate upstream egress CoS queue among the eight CoS queues.
Flow mapping and MAC learning: This refers to the mapping of a received upstream Ethernet frame to a provisioned service flow,
which dictates subsequent processing of the frame according to the service model (VLAN topology) corresponding to the flow. For
example, if the service model of the flow is N:1[8][10], the MAC learning process is performed on the frame resulting in association

of the MAC source address and VID in the frame with the GPON connection bundle (GEM port group) on which the frame was
received. The information learned in the upstream direction is used, along with packet priority, in the downstream direction to
determine the GPON connection (GEM port) out which to forward downstream frames.
Packet header modification: This refers to the modification of a received upstream frame’s VLAN tag (VID and/or 802.1p priority
field), or insertion of a new (outer) VLAN tag to it. Packet header modification is provisioned on a per service flow basis.
Upstream egress scheduler: This refers to the selection of one of the eight upstream CoS queues from which queued frames will be
sent over the SGMII interface to the Ethernet layer 2 switch. This selection is based on the scheduler mode configured - strict priority
(SP) or weighted round robin (WRR) mode.
In the downstream direction, the processing sequence is as follows:
Packet classification, CoS assignment & GPON connection mapping: This refers to the classification of outgoing Ethernet frames
into a class of service (priority) and enqueuing them into appropriate downstream egress CoS queues. At the end of this stage is
performed the identification of the GPON connection (GEM port) out which the frames shall be transmitted based on the service
instance (flow) to which the frames belong. The GPON connection identification mechanism depends on the service model associated
with the flow. If the service model is 1:1, the VID determines the connection (GEM port); if the service model of the flow is N:1, the
VID, MAC DA and priority determine the connection (GEM port).
Packet header modification: This refers to the modification of the VID and/or 802.1p priority field or removal of a (outer) VLAN tag
of an outgoing downstream frame. Packet header modification is provisioned on a per service flow basis.
Downstream egress scheduler: This refers to the selection of one of the eight downstream CoS queues from which queued frames
will be sent out on the GEM port (on the appropriate PON port) chosen during the GPON connection mapping step of the first stage,
discussed above. This selection is based on the scheduler mode configured - strict priority (SP) or weighted round robin (WRR)
mode.
GPON PMD/TC layer: This represents the physical media dependent (PMD) and transmission convergence (TC) layer processing
(per ITU-T Rec. G.984.3 [3]) that outgoing GPON frames go through.
I.1.3 Alphion Optical Network Terminal/Unit (AONT)

Figure 5 shows the functional overview of the SFU AONT.
As shown in the figure, in the upstream direction, first packet classification and CoS mapping is performed. This leads to selecting an
appropriate GPON connection (GEM port) that can support the CoS, and results in the frame getting enqueued into the appropriate CoS
queue of a T-CONT. This is followed by any packet header modification, including modification of VID and/or 802.1p priority field, or
addition of a new VLAN tag, that may have been provisioned to be performed. The frame is then scheduled to be sent out the PON port,
towards the AOLT.
ANI (PON) port

T-CONT Packet classification,
Pkt. header (VID,
GPON PMD/ mapping / CoS mapping &
priority)
TC layer U/S egress GPON connection
modification
scheduling (GEM port) mapping
To ODN UNI
ports
CoS mapping Pkt. header (VID,

GPON PMD/ based on GPON D/S egress scheduler
priority)
TC layer connection (GEM at UNI port
modification
port)
Figure 5: Functional Overview of ONT

In the downstream direction, after PMD/TC layer processing, CoS mapping is performed on the downstream frames based on the
received GPON connection (GEM port), which results in the frames being enqueued into an appropriate CoS queue of the appropriate
UNI port. This is followed by optional packet header modification, including modification of VID and/or 802.1p priority field, or
removal of a VLAN tag, that may be provisioned to be performed. The Ethernet frame is then scheduled to be sent out the UNI port.

Appendix II – Engineering Response Document (ERD) Form
Provided below is the ERD form that shall be used to generate the ERD for this document. The ERD will evolve and keep
track of the implementation status of the requirements in this document.
Line Req. Id SD&E expected Release R&D - Indicate R&D comments (implementation
item # Release deviations w.r.t requirements, etc.)
1 113-R-6.3.1-10 2.0
2 113-R-6.3.1-20 2.0
3 113-R-6.3.1-30 2.0
4 113-R-6.3.1-40 2.0
5 113-R-6.3.1-50 2.0
6 113-R-6.3.1-60 2.0
7 113-R-6.3.1-70 2.0
8 113-R-6.3.1-80 2.0
9 113-R-6.3.1-90 2.0
10 113-R-6.3.1-100 2.0
11 113-R-6.3.2-10 2.0
12 113-R-6.3.2-20 2.0
13 113-R-6.3.2-30 2.0
14 113-R-6.3.2-40 2.0
15 113-R-6.3.2-50 2.0
16 113-R-6.3.2-60 2.0
17 113-R-6.3.2-70 2.0
18 113-R-6.3.2-80 2.0
19 113-R-6.3.2-90 2.0
20 113-R-6.3.3-10 2.0
21 113-R-6.3.3-20 2.0
22 113-R-6.3.3-30 2.0
23 113-R-6.3.3-40 2.0
24 113-R-6.3.3-50 2.0
25 113-R-6.3.3-60 After 2.0
26 113-R-6.3.3-70 2.0
27 113-R-6.3.3-80 2.0
28 113-R-6.3.3-90 2.0
29 113-R-6.3.3-100 2.0
30 113-R-6.3.3-110 2.0
31 113-R-6.3.3-120 2.0
32 113-R-6.3.3-130 2.0
33 113-R-6.3.3-140 2.0

34 113-R-6.3.3-150 2.0
35 113-R-6.3.3-160 2.0
36 113-R-7.1-10 2.0
37 113-R-7.1-20 2.0
38 113-R-7.1-30 2.0
39 113-R-7.1-40 After 2.0
40 113-R-7.1-50 After 2.0
41 113-R-7.1-60 After 2.0
42 113-R-7.1-70 After 2.0
43 113-R-7.1-80 After 2.0
44 113-R-7.1-90 2.0
45 113-R-7.1-100 2.0
46 113-R-7.1-110 2.0
47 113-R-7.1-120 2.0
48 113-R-7.1-130 2.0
49 113-R-7.1-140 2.0
50 113-R-7.1-150 2.0
51 113-R-8-10 2.0
52 113-R-8-20 2.0
53 113-R-8-30 After 2.0
54 113-R-8-40 2.0
55 113-R-8-50 After 2.0
56 113-R-9.1.1-10 2.0
57 113-R-9.1.1-20 2.0
58 113-R-9.1.1-30 2.0
59 113-R-9.1.1-40 2.0
60 113-R-9.1.1-50 2.0
61 113-R-9.1.1-60 2.0
62 113-R-9.1.1-70 2.0
63 113-R-9.1.1-80 2.0 (Non-default value - After
2.0)
64 113-R-9.1.1-90 After 2.0
65 113-R-9.1.1-100 2.0
66 113-R-9.1.2-10 2.0
67 113-R-9.1.2-20 2.0
68 113-R-9.1.2-30 2.0

69 113-R-9.1.2-40 2.0
70 113-R-9.1.2-50 2.0
71 113-R-9.1.2-60 2.0
72 113-R-9.1.2-70 2.0
73 113-R-9.1.2-80 2.0
74 113-R-9.2.1-10 2.0
75 113-R-9.2.1-20 2.0
76 113-R-9.2.1-30 2.0
77 113-R-9.2.1-40 2.0
78 113-R-9.2.1-50 2.0
79 113-R-9.2.2-10 2.0
80 113-R-9.2.2-20 2.0
81 113-R-9.2.2-30 2.0
82 113-R-9.2.2-40 2.0
83 113-R-9.2.2-50 2.0
84 113-R-9.2.2-60 2.0
85 113-R-9.2.2-70 2.0
86 113-R-9.2.2-80 2.0
87 113-R-9.3.1-10 2.0
88 113-R-9.3.1-20 2.0
89 113-R-9.3.1-30 2.0 (Proxy and Transparent
snooping – After 2.0)
90 113-R-9.3.1-40 2.0
91 113-R-9.3.1-50 2.0
92 113-R-9.3.1-60 2.0
93 113-R-9.3.1-70 2.0
94 113-R-9.3.1-80 After 2.0
95 113-R-9.3.1-90 2.0
96 113-R-9.3.1-100 2.0
97 113-R-9.3.1-110 2.0
98 113-R-9.3.1-120 After 2.0
99 113-R-9.3.1-130 2.0
100 113-R-9.3.2-10 2.0
101 113-R-9.3.2-20 2.0
102 113-R-9.3.2-30 2.0
103 113-R-9.3.2-40 2.0

104 113-R-9.3.2-50 After 2.0
105 113-R-9.3.2-60 After 2.0
106 113-R-9.3.2-70 2.0 (‘Forward’ value - After 2.0)
107 113-R-9.3.2-80 2.0
108 113-R-9.3.3-10 2.0
109 113-R-9.3.3-20 2.0
110 113-R-9.3.3-30 After 2.0
111 113-R-9.3.3-40 After 2.0
112 113-R-9.4.1-10 2.0
113 113-R-9.4.1-20 2.0
114 113-R-9.4.1-30 2.0
115 113-R-9.4.1-40 2.0
116 113-R-9.4.2-10 2.0
117 113-R-9.4.2-20 2.0 (‘TLS – Double tagged UNI
mode’ - After 2.0)
118 113-R-9.4.2-30 2.0 (‘TLS – Double tagged UNI
mode’ - After 2.0)
119 113-R-9.4.2-40 2.0
120 113-R-9.4.2-50 2.0
121 113-R-9.4.2-60 2.0
122 113-R-9.4.3-10 After 2.0

Page 39: [1] Deleted Janar Thoguluva, Alphion Corporation 5/20/2010 12:26:00 PM
113-R- Allow/Discard One of : RW Allow TR-156/R-86 The AOLT and AEMS shall
user IGMP Allow parameter whether to al
9.3.1-
messages IGMP messages that are r
60 Discard
this service instance (mu
113-R- IGMP snooping

– Immediate
9.3.1-
Leave
100 function at
ONT/ONU
113-R- U/S IGMP One of : RW ‘No limit’ TR-156/R-87; The AOLT shall instruct t
message rate ‘No limit’ G.984.4 / parameter the U/S IGMP
9.3.1-
limit at ONT Multicast IPTV service (multicast-V
120 1-10 messages/s for SFU AONTs Operations ports.
1-100 messages/s for MDU Profile ME
AONTs

Service Requ

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Service Requ

Загружено:

Авторское право:

Доступные форматы

Service Configuration & Management Framework and Requirements for Alphion GPON System

Service Configuration & Management Framework and Requirements for Alphion

Document number: 191-0000113

Alphion Corporation Proprietary and Confidential Page 1 of 56

The requirement identification number is composed of the following items:

The requirement types used in this document are:

Alphion Corporation Proprietary and Confidential Page 2 of 56

Revision Author Reviewed By Description Of Change Issued by / Issue

Alphion Corporation Proprietary and Confidential Page 3 of 56

Alphion Corporation Proprietary and Confidential Page 4 of 56

Alphion Corporation Proprietary and Confidential Page 5 of 56

Alphion Corporation Proprietary and Confidential Page 6 of 56

Figure 1: TR-156 GPON Access Node

3 Configuration and Management Overview

Alphion Corporation Proprietary and Confidential Page 7 of 56

Configure and manage AOLT system w.r.t:

PON layer settings, including ONT/ONU auto-discovery, FEC, etc.,

Add AONTs to PONs and activate them

AONT Equipment/ Configure and manage AONTs w.r.t:

Figure 2: Configuration and Management flow

Alphion Corporation Proprietary and Confidential Page 8 of 56

6 Service Models & VLAN Handling

Alphion Corporation Proprietary and Confidential Page 9 of 56

6.2 Service models (or VLAN forwarding models)

Service model Description Applicable Applicable

Alphion Corporation Proprietary and Confidential Page 10 of 56

Alphion Corporation Proprietary and Confidential Page 11 of 56

Alphion Corporation Proprietary and Confidential Page 12 of 56

they can be classified to the associated traffic flow.

Alphion Corporation Proprietary and Confidential Page 13 of 56

• ARP (0x0806) service models).

configured on a per UNI port basis, as described in section 8 of [14].

Alphion Corporation Proprietary and Confidential Page 14 of 56

Alphion Corporation Proprietary and Confidential Page 15 of 56

6.3.2 Downstream VLAN Handling

Alphion Corporation Proprietary and Confidential Page 16 of 56

AOLT shall instruct the AONT to use this TPID (along

instruct the AONT to tag the D/S frames of the

Alphion Corporation Proprietary and Confidential Page 17 of 56

instruct the AONT to tag the D/S frames of the

Alphion Corporation Proprietary and Confidential Page 18 of 56

Alphion Corporation Proprietary and Confidential Page 19 of 56

and Table 4, the SNI

Alphion Corporation Proprietary and Confidential Page 20 of 56

Alphion Corporation Proprietary and Confidential Page 21 of 56

6.3.4 Upstream-Downstream value combinations for VLAN Handling parameters

VLAN U/S VLAN Handling parameter D/S VLAN Handling parameter

Alphion Corporation Proprietary and Confidential Page 22 of 56

VLAN U/S VLAN Handling parameter D/S VLAN Handling parameter

Alphion Corporation Proprietary and Confidential Page 23 of 56

VLAN U/S VLAN Handling parameter D/S VLAN Handling parameter

Alphion Corporation Proprietary and Confidential Page 24 of 56

VLAN U/S VLAN Handling parameter D/S VLAN Handling parameter

Alphion Corporation Proprietary and Confidential Page 25 of 56

Alphion Corporation Proprietary and Confidential Page 26 of 56

Alphion Corporation Proprietary and Confidential Page 27 of 56

Alphion Corporation Proprietary and Confidential Page 28 of 56

Alphion Corporation Proprietary and Confidential Page 29 of 56

113- AONT-id String of up to RW N/A N/A Identifies the AONT GA

113- T-CONT (service) One of the RW N/A N/A Identifies the T- GA

113- T-CONT Priority 0 to 7 RW 0 [9] / The SP Priority of FC

Alphion Corporation Proprietary and Confidential Page 30 of 56

8 General Service Configuration & Management Requirements

Alphion Corporation Proprietary and Confidential Page 31 of 56