View
214
Download
0
Category
Preview:
Citation preview
P a g e 1 © HGI 2013 – All rights reserved
HGI-RD024
REQUIREMENTS FOR AN NGA (ACTIVE LINE ACCESS)
CAPABLE NT
Published April, 2013
Source HGI02185_R06
HGI-RD024 Requirements for an NGA (Active Line Access) Capable NT
P a g e 2 © HGI 2013 – All rights reserved
1 CONTENTS 2 Important notices, IPR statement, disclaimers and copyright.............................................................. 5
2.1 About HGI ......................................................................................................................................... 5
2.2 This may not be the latest version of This HGI Document .............................................................. 5
2.3 There is no warranty provided with This HGI Document ................................................................ 5
2.4 Exclusion of Liability ......................................................................................................................... 5
2.5 This HGI Document is not binding on HGI nor its member companies ........................................... 5
2.6 Intellectual Property Rights ............................................................................................................. 6
2.7 Copyright Provisions ........................................................................................................................ 6
2.7.1 Incorporating HGI Documents in whole or part within Documents Related to Commercial
Tenders 6
2.7.2 Copying This HGI Document in its entirety ............................................................................. 6
2.8 HGI Membership .............................................................................................................................. 7
3 Acronyms .............................................................................................................................................. 8
4 Introduction ........................................................................................................................................ 11
4.1 Scope And Purpose ........................................................................................................................ 11
4.2 Definitions Of Terms ...................................................................................................................... 11
5 ALA Background and Introduction ...................................................................................................... 12
5.1 ALA Business Entities ..................................................................................................................... 13
5.1.1 ALA Commercial Model ......................................................................................................... 13
5.2 ALA Basic Concepts ........................................................................................................................ 13
5.3 ALA QoS Architecture .................................................................................................................... 14
5.4 ALA Service Classes ........................................................................................................................ 14
5.5 Access Line Sharing ........................................................................................................................ 15
5.6 ALA Port Types ............................................................................................................................... 15
5.6.1 Frame handling at a port based UNI ..................................................................................... 15
5.6.2 Frame handling at an S-tagged UNI ...................................................................................... 16
5.6.3 Frame handling at an customer edge port UNI..................................................................... 16
5.7 ALA Multicast ................................................................................................................................. 16
HGI-RD024 Requirements for an NGA (Active Line Access) Capable NT
P a g e 3 © HGI 2013 – All rights reserved
5.8 ALA OAM ........................................................................................................................................ 16
5.8.1 ALA-User MEG ....................................................................................................................... 17
5.8.2 Extended AUC MEG ............................................................................................................... 17
5.8.3 AUC MEG ............................................................................................................................... 17
5.8.4 UNI MEG ................................................................................................................................ 18
5.8.5 NNI MEG ................................................................................................................................ 18
5.9 ALA and Line Sharing...................................................................................................................... 18
6 2-box History in the HGI ...................................................................................................................... 19
6.1 Overview of the Existing HGI Document ....................................................................................... 19
6.2 Rationale for a New Document...................................................................................................... 19
6.3 Relationship to ETSI Work .............................................................................................................. 19
7 Generic Requirements ........................................................................................................................ 20
7.1 Physical Connections and Connectivity ......................................................................................... 20
7.2 ALA Port Mode Support ................................................................................................................. 20
7.3 VLAN Handling ............................................................................................................................... 21
7.3.1 S-tagged UNI.......................................................................................................................... 21
7.3.2 Customer Edge Port UNI ....................................................................................................... 22
7.3.3 Port Tagged UNI .................................................................................................................... 22
7.4 Frame Transparency ...................................................................................................................... 22
7.5 Upstream QoS Support .................................................................................................................. 23
7.6 QoS Markings ................................................................................................................................. 24
7.7 Energy Efficiency ............................................................................................................................ 25
7.8 Multicast Support .......................................................................................................................... 25
7.9 Secondary LAN Interfaces .............................................................................................................. 25
8 Technology Specific Requirements ..................................................................................................... 27
8.1 VDSL2 ............................................................................................................................................. 27
8.1.1 WAN-side Interfaces ............................................................................................................. 27
8.1.2 LAN-side Interfaces ............................................................................................................... 28
8.2 Upstream Queues .......................................................................................................................... 28
8.3 Ethernet WAN Interface ................................................................................................................ 28
HGI-RD024 Requirements for an NGA (Active Line Access) Capable NT
P a g e 4 © HGI 2013 – All rights reserved
8.3.1 WAN interface ....................................................................................................................... 28
8.3.2 LAN Interfaces ....................................................................................................................... 29
8.4 Upstream Queues .......................................................................................................................... 29
8.5 GPON .............................................................................................................................................. 29
8.5.1 WAN interface ....................................................................................................................... 29
8.5.2 LAN Interfaces ....................................................................................................................... 29
8.5.3 T-Conts .................................................................................................................................. 30
8.6 Point to Point Fibre ........................................................................................................................ 30
8.6.1 WAN Interface ....................................................................................................................... 30
8.6.2 LAN Interfaces ....................................................................................................................... 30
8.7 Upstream Queues .......................................................................................................................... 31
9 Diagnostics .......................................................................................................................................... 32
10 OAM ............................................................................................................................................... 33
10.1 ALA-User MEG ........................................................................................................................... 33
11 Management .................................................................................................................................. 34
12 References ..................................................................................................................................... 35
1 Annexe 1 ............................................................................................................................................. 36
HGI-RD024 Requirements for an NGA (Active Line Access) Capable NT
P a g e 5 © HGI 2013 – All rights reserved
2 IMPORTANT NOTICES, IPR STATEMENT, DISCLAIMERS AND
COPYRIGHT
This chapter contains important information about HGI and this document (hereinafter ‘This HGI
Document’).
2.1 ABOUT HGI The Home Gateway Initiative (HGI) is a non-profit making organization which publishes guidelines,
requirements documents, white papers, vision papers, test plans and other documents concerning
broadband equipment and services which are deployed in the home.
2.2 THIS MAY NOT BE THE LATEST VERSION OF THIS HGI DOCUMENT This HGI Document is the output of the Working Groups of the HGI and its members as of the date of
publication. Readers of This HGI Document should be aware that it can be revised, edited or have its
status changed according to the HGI working procedures.
2.3 THERE IS NO WARRANTY PROVIDED WITH THIS HGI DOCUMENT The services, the content and the information in this HGI Document are provided on an "as is" basis.
HGI, to the fullest extent permitted by law, disclaims all warranties, whether express, implied, statutory
or otherwise, including but not limited to the implied warranties of merchantability, non-infringement of
third parties rights and fitness for a particular purpose. HGI, its affiliates and licensors make no
representations or warranties about the accuracy, completeness, security or timeliness of the content or
information provided in the HGI Document. No information obtained via the HGI Document shall create
any warranty not expressly stated by HGI in these terms and conditions.
2.4 EXCLUSION OF LIABILITY Any person holding a copyright in This HGI Document, or any portion thereof, disclaims to the fullest
extent permitted by law (a) any liability (including direct, indirect, special, or consequential damages
under any legal theory) arising from or related to the use of or reliance upon This HGI Document; and (b)
any obligation to update or correct this technical report.
2.5 THIS HGI DOCUMENT IS NOT BINDING ON HGI NOR ITS MEMBER
COMPANIES This HGI Document, though formally approved by the HGI member companies, is not binding in any way
upon the HGI members.
HGI-RD024 Requirements for an NGA (Active Line Access) Capable NT
P a g e 6 © HGI 2013 – All rights reserved
2.6 INTELLECTUAL PROPERTY RIGHTS Patents essential or potentially essential to the implementation of features described in This HGI
Document may have been declared in conformance to the HGI IPR Policy and Statutes (available at the
HGI website www.homegateway.org).
2.7 COPYRIGHT PROVISIONS © 2013 HGI. This HGI Document is copyrighted by HGI, and all rights are reserved. The contents of This
HGI Document are protected by the copyrights of HGI or the copyrights of third parties that are used by
agreement. Trademarks and copyrights mentioned in This HGI Document are the property of their
respective owners. The content of This HGI Document may only be reproduced, distributed, modified,
framed, cached, adapted or linked to, or made available in any form by any photographic, electronic,
digital, mechanical, photostat, microfilm, xerography or other means, or incorporated into or used in
any information storage and retrieval system, electronic or mechanical, with the prior written
permission of HGI or the applicable third party copyright owner. Such written permission is not
however required under the conditions specified in Section 2.7.1 and Section 2.7.2 :
2.7.1 INCORPORATING HGI DOCUMENTS IN WHOLE OR PART WITHIN DOCUMENTS RELATED
TO COMMERCIAL TENDERS Any or all section(s) of HGI Documents may be incorporated into Commercial Tenders (RFP, RFT, RFQ,
ITT, etc.) by HGI and non-HGI members under the following conditions:
(a) The HGI Requirements numbers, where applicable, must not be changed from those within the HGI Documents.
(b) A prominent acknowledgement of the HGI must be provided within the Commercial document identifying any and all HGI Documents referenced, and giving the web address of the HGI.
(c) The Commercial Tender must identify which of its section(s) include material taken from HGI Documents and must identify each HGI Document used, and the relevant HGI Section Numbers.
(d) The Commercial Tender must refer to the copyright provisions of HGI Documents and must state that the sections taken from HGI Documents are subject to copyright by HGI and/or applicable third parties.
2.7.2 COPYING THIS HGI DOCUMENT IN ITS ENTIRETY This HGI Document may be electronically copied, reproduced, distributed, linked to, or made available in
any form by any photographic, electronic, digital, mechanical, photostat, microfilm, xerography or other
means, or incorporated into or used in any information storage and retrieval system, electronic or
mechanical, but only in its original, unaltered PDF format, and with its original HGI title and file name
unaltered. It may not be modified without the advanced written permission of the HGI.
HGI-RD024 Requirements for an NGA (Active Line Access) Capable NT
P a g e 7 © HGI 2013 – All rights reserved
2.8 HGI MEMBERSHIP The HGI membership list as of the date of the formal review of this document is: Actility, Advanced
Digital Broadcast, Alcatel-Lucent, Arcadyan, Arm, Belgacom, Bouygues Telecom, British Sky Broadcasting
Ltd., Broadcom, BT, Cavium, Celeno, Cisco, Deutsche Telekom, Devolo, Dialog Semiconductor, D-Link
Corporation, DSP Group, eflow, EnOcean Alliance, Ericsson AB, Fastweb SpA, France Telecom, Hitachi,
Huawei, Ikanos, Intel, IS2T, KDDI, KPN, LAN, Lantiq, LG Electronics, Lionic, Makewave, Marvell
Semiconductor, Mindspeed, Mitsubishi, MStar, NEC Corporation, Netgear, NTT, Oki Electric Industory,
Portugal Telecom, ProSyst, Qualcomm Atheros, Sagemcom, Samsung, Seagate, Sercomm Corp., Sigma,
SoftAtHome, Stollmann, Sumitomo, Swisscom AG, Technicolor, Telecom Italia, Telekom Austria,
TeliaSonera, Telstra, TNO, Trac Telecoms & Radio Ltd, Vodafone, Vtech, Zarlink, ZTE, ZyXEL.
HGI-RD024 Requirements for an NGA (Active Line Access) Capable NT
P a g e 8 © HGI 2013 – All rights reserved
3 ACRONYMS
ACS Auto-Configuration Server
ADSL Asymmetric Digital Subscriber Line
AN Access Network
ANP Access Network Provider
ARP Address Resolution Protocol
ATA Analogue Terminal Adapter
BRAS Broadband Remote Access Server
BSP Broadband Service Provider
CAC Call Admission Control/Connection Admission Control
CE Customer Experience
CoS Class of Service
CPE Customer Premises Equipment
CPU Central Processing Unit
CRC Cyclic Redundancy Check
DHCP Dynamic Host Control Protocol
DNS Domain Name Server
DRAM Dynamic Random Access Memory
DSL Digital Subscriber Line
DSLAM DSL Access Multiplexer
ED End Device
EU End user
GPON Gigabit Passive Optical Network
GUI Graphical user Interface
HGI-RD024 Requirements for an NGA (Active Line Access) Capable NT
P a g e 9 © HGI 2013 – All rights reserved
HG Home Gateway
HGI Home Gateway Initiative
HN Home Network
HNID Home Network Infrastructure Device
I/F Interface
MAC Media Access Control
LAN Local Area Network
NAS Network Attached Storage
NAT Network Address Translation
NGN Next Generation Network
NGA Next Generation Access
NT(E) Network Termination (Equipment)
OAM Operations, Administration & Maintenance
OS Operating System
OTT Over The Top (service)
OUI-SN Organisationally Unique Identifier
PHY Physical Layer
PLT Power Line Technology
PM Performance Monitoring
PPP Point-to-Point Protocol
PVR Personal Video Recorder
QoS Quality of Service
RCPI Received Channel Power Indicator
RMS Remote management System
HGI-RD024 Requirements for an NGA (Active Line Access) Capable NT
P a g e 10 © HGI 2013 – All rights reserved
RTP Real Time Protocol
SLA Service Level Agreement
SNMP Simple Network Management Protocol
SP Service Provider
SSID Service Set Identifier
STB Set Top Box
SWEX Software Execution Environment
UI User Interface
UMTS Universal Mobile Telephone System
UPnP Universal Plug and Play
URL Universal Resource Locator
USB Universal Serial Bus
VAS Value Added Service
VDSL Very highspeed Digital Subscriber Line
VoD Video on Demand
VoIP Voice Over IP
WAN Wide Area Network
xDSL ADSL and VDSL
HGI-RD024 Requirements for an NGA (Active Line Access) Capable NT
P a g e 11 © HGI 2013 – All rights reserved
4 INTRODUCTION
4.1 SCOPE AND PURPOSE
The purpose of this document is to define the HGI Service Provider requirements for a Next Generation
Access/Active Line Access Capable NT device. The scope of the requirements provided is ALA-specific
requirements, Layer 2 marking and handling, Quality of Service, Diagnostics, technology specific
requirements on the NT line side, and technology specific requirements on the NT WAN side.
4.2 DEFINITIONS OF TERMS
The definitions of MUST and SHOULD in this document are as follows:
MUST A functional requirement which is based on a clear consensus among HGI Service
Provider members, and is the base level of required functionality for a given class of equipment.
MUST NOT This function is prohibited by the specification.
SHOULD Functionality which goes beyond the base requirements for a given class of HG, and can
be used to provide vendor product differentiation (within that class).
Note: These definitions are specific to the HGI and should not be confused with the same or similar
terms used by other bodies.
HGI-RD024 Requirements for an NGA (Active Line Access) Capable NT
P a g e 12 © HGI 2013 – All rights reserved
5 ALA BACKGROUND AND INTRODUCTION
Most ADSL Broadband deployments use an integrated modem-router, i.e. the ADSL modem which
terminates the access network transmission is combined with L3 functionality to produce an integrated
Home Gateway. With the move to higher speed access systems this model may change, with the VDSL
modem or GPON ONT being standalone, separate devices. There are different reasons in the 2 cases. For
optimum performance, VDSL needs a centralised splitter, and so is less amenable to self-install than
ADSL which can use distributed microfilters. Further, the state of multi-vendor VDSL interoperability and
performance is not yet as advanced as with ADSL and so BSPs may want to offer bookended
transmission systems so as to maximise performance, without necessarily wanting to provide the HG
themselves. In the GPON case, the network provider may wish to retain control of the ONT because of
the shared-medium nature of GPON, and the impact a ‘rogue’ 3rd party device can have on all other
users on the GPON, while again not wishing to provide the HG as a whole.
Two of the main drivers for competition in ADSL have been wires-only and local loop unbundling. Wires-
only has allowed competition in HGs (via price, functionality, performance and branding), but wires-only
NGA suffers from the above difficulties. Local loop unbundling is also problematic with NGA; while
subloop unbundling, (i.e. allowing access to that part of the loop between the cabinet and the home to
3rd parties) is technically feasible, it is commercially and logistically challenging. Deploying electronics at
the cabinet has high fixed costs, and so sharing that cost between a smaller number of customers, as
would be the case if there was equipment there from multiple operators, makes this financially
unattractive. In the GPON case, there is no separate infrastructure link to individual customers, and so a
GPON cannot be unbundled at the individual customer level.
The UK regulator, Ofcom, therefore considered how competition could be provided in the absence of
unbundling, and came up with the concept of Active Line Access (ALA) [Ref 1]. This is a Layer 2,
Ethernet-presented bitstream service which allows access to individual customers, via an aggregate
handover, and it can support multiple services, via several different levels of network QoS. The intention
is to provide this access service at the lowest possible Layer, and so there is no presumption of higher
Layer protocols, e.g. PPP, although these can be supported. It differs from previous bitstream products
in that there is less requirement to specify the internal details of the connectivity. Both point to point
and point to multipoint connectivity (specifically for multicast) are supported.
While the initial drive behind ALA came from the UK, the expectation is that it will have a much broader
applicability, both within and beyond the EU, in particular in any NGA market where there is L2
Wholesale rather than vertical integration.
HGI-RD024 Requirements for an NGA (Active Line Access) Capable NT
P a g e 13 © HGI 2013 – All rights reserved
5.1 ALA BUSINESS ENTITIES
The ALA service is defined in terms of three different business entities each of which has a specific role
with regard to the ALA service. These are as follows.
The ALA Provider who is responsible for the provision of the active and passive infrastructure over
which ALA is delivered. The ALA provider offers standardised interfaces to which the ALA user can
connect, and delivers the ALA user’s traffic between these interfaces, across the ALA domain. The ALA
domain extends from the end-user premises to an interconnect point further up the network. ALA
providers may include both fixed and some types of wireless infrastructure providers. They may own or
lease the passive and active parts of network, e.g. an ALA provider may own the active electronics, but
lease the passive infrastructure.
The ALA User purchases Ethernet transport to an end-user from the ALA provider over which it delivers
services such as voice, video and internet connectivity. The ALA user has a direct, contractual
relationship with the ALA provider. The ALA user may also have a direct relationship with the LAN side or
with other communications providers on a wholesale basis.ALA users include ISPs and triple-play
operators.
The End-User is the ultimate recipient of the services provided over ALA. End-users include both
residential consumers and business users. The end-user is unaware of the ALA service and of the
interfaces between the ALA provider and the ALA user. An end-user is typically (but not always) served
by a single ALA provider. The end-user may buy services from multiple ALA users who would in turn buy
service from the ALA provider(s) serving the end-user. This means that at a given end-user premises it is
possible to have multiple ALA users consuming the service offered by a single ALA provider.
5.1.1 ALA COMMERCIAL MODEL In the ALA model, the NT itself is provided by the Access Network provider. The retail service provider is
typically a different business entity to the ANP. The retail service provider is responsible for providing
the HG, and just as in the single box model, would normally want to control and manage the HG. The HG
in the ALA model therefore remains a SP provided or specified box, rather than supporting an open
retail HG market.
5.2 ALA BASIC CONCEPTS
The ALA service delivers Ethernet packets between the UNI on the NT and a handover point (NNI) in the
network. This is done over an AUC – ALA User connection. There are 2 types of AUC, point to point, and
point to multipoint which is exclusively used for multicast. A single AUC can support all 4 ALA service
classes. AUCs are not shared between ALA Providers, but there can be multiple AUCs on the same access
line.
HGI-RD024 Requirements for an NGA (Active Line Access) Capable NT
P a g e 14 © HGI 2013 – All rights reserved
5.3 ALA QOS ARCHITECTURE
ALA does not presume a single service edge, a single BNG (or indeed any BNG), and although its main
focus is residential, there is an intention to be able to support business services as well. There is a need
for QoS management at the ALA UNI, and therefore the NT.
5.4 ALA SERVICE CLASSES
ALA supports 4 QoS Classes (A,B,C,D), A, B and C have some aspects of the traditional IP EF, AF and BE
Classes. While they are intended to support a variety of service types, some typical examples are given
in the below Table.
Class Typical Use
A Realtime, delay sensitive applications e.g. voice
B Streaming applications (video)
C Internet data
D Guest or 3rd party Access
Each of these classes has associated performance objectives that form a per-class Service Level
Specification. These performance objectives are such that Class A will have better performance than
Class B, which will have better performance than Classes C and D.
In order to meet the Service Level Specification, it is expected that the ALA Provider (L2 Wholesale
Access Provider) will need to implement strict priority scheduling at any congestion points in their
network to prioritise transmission of Class A traffic over Class B traffic, which in turn would be prioritised
over Class C and D traffic. Starvation of the lower priority queues can be avoided by the use of per class
policers.
Classes A and B only support committed bandwidth. The bandwidth available for each of Classes A and B
may need to be restricted by the ALA provider to ensure that appropriate performance levels can be
delivered for lower priority classes and other ALA users.
Classes C and D support both committed and excess bandwidth. The bandwidth profiles at the UNI and
NNI can be configured to be colour aware so that the ALA User’s drop precedence marking is respected
HGI-RD024 Requirements for an NGA (Active Line Access) Capable NT
P a g e 15 © HGI 2013 – All rights reserved
within these classes. In the case that both classes C and D send excess traffic at the same time, the ALA
provider will limit the bandwidth share of Class D. Typical use cases for Class D would be to support
(wireless) guest access at the end-user premises, or to limit the bandwidth of a background application
such as push video.
5.5 ACCESS LINE SHARING
Another new feature of ALA is access line sharing; this means that there can be more than one ALA user
on a given access line. The business rationale for this is not primarily to have more than one multi-play
service provider (although this is supported), but for secondary or niche service providers in addition to
the main multiplay SP. Examples of such service types are utility services such as smart grid related,
security, E-health, work at home and corporate voice. This means that the QoS mechanisms need to be
able to protect different ALA users on the same line from each other; for example it is not sufficient to
simply provide shared queues or only strict priority scheduling.
5.6 ALA PORT TYPES
ALA supports three (user) port types:
• A port based UNI • An S-Tagged UNI • A customer edge port based UNI.
The S-Tagged UNI requires the ALA User to identify the AUC of a frame using either an S-VLAN tag or the
default S-VLAN on the port. This means that to use a VLAN tagged presentation at the UNI in the S-
Tagged interface, the ALA User needs to send two VLAN tags at the NNI and configure which S-VLAN to
use at the UNI.
A customer edge port based UNI offers the same capability but in this case the CVLAN tags used at the
UNI are tunnelled over a point-to-point AUC. This means that to use a VLAN-tagged presentation at the
UNI the ALA User will need to send three VLAN tags at the NNI; where the two outer VLAN tags are
defined by the AUC endpoint map at the NNI and the inner-most VLAN tag needs to match the VLAN tag
being used by the ALA User at the UNI. This inner-most VLAN tag is not significant to the ALA provider at
the NNI and is carried transparently over it.
5.6.1 FRAME HANDLING AT A PORT BASED UNI At a port based UNI the UNI identifier identifies the AUC. All service frames received on the UNI that
have a TPID of 0x8100 are accepted regardless of any VLAN tagging, and treated as untagged frames. All
service frames received on the UNI that have a TPID of 0x88A8 are accepted regardless of any VLAN
tagging and treated as untagged frames. VLAN tagging is preserved through the ALA provider’s network.
In the downstream direction (towards the end-user) any VLAN tags used by the ALA provider to identify
HGI-RD024 Requirements for an NGA (Active Line Access) Capable NT
P a g e 16 © HGI 2013 – All rights reserved
the AUC will be stripped off before the frame is passed over the UNI. Note that this mode only supports
a single ALA Class of Service.
5.6.2 FRAME HANDLING AT AN S-TAGGED UNI At an S-tagged UNI the AUC end point map uses the S-VID of the frame to identify the AUC. The UNI AUC
end point map will therefore contain a list of S-VID to AUC mappings. Traffic arriving over the AUC will
be passed out over the UNI with the appropriate S-tag. An S-VID will map to at most one AUC, and an
AUC will map to only one S-VID.
At each S-tagged UNI it is possible to define a default VLAN to which any untagged or priority tagged
frames are mapped. This default VLAN can be mapped to an AUC (as for any other S-tagged VLAN) by
the end point map. If no default VLAN is defined for the UNI then untagged and priority tagged frames
will be dropped since they do not match a defined S-VID.
5.6.3 FRAME HANDLING AT AN CUSTOMER EDGE PORT UNI At a customer edge port UNI, one C-Tag value is used to identify the multicast AUC. This value needs to
be defined by the ALA provider as part of their product description. All other frames, untagged, priority
tagged or tagged with a value other than the multicast tag, are mapped to the point to point AUC. The
priority within the AUC for frames entering the network at the UNI is mapped from the priority bits of
the C-tags received.
5.7 ALA MULTICAST
ALA always uses a separate (point to multipoint) VLAN for multicast between the ALA provider and ALA
user. A given access line can support more than one multicast AUC, but there is no sharing of a given
multicast AUC between different service providers.
5.8 ALA OAM
The mapping of Ethernet OAM to the ALA architecture is shown in figure 1:
HGI-RD024 Requirements for an NGA (Active Line Access) Capable NT
P a g e 17 © HGI 2013 – All rights reserved
Figure 1 – Ethernet OAM Architecture
Figure 1 shows the following MEGs
5.8.1 ALA-USER MEG The ALA provider configures the ALA-user MEG on the VLAN that supports the AUC. It supports MIPs
that allow the ALA-User to perform linktrace and loopback operations to the UNI and NNI for each AUC.
This MEG is equivalent to the EVC MEG in the MEF architecture and the Customer MEG in the
Broadband Forum Architecture.
5.8.2 EXTENDED AUC MEG
The Extended-AUC MEG allows an ALA user to monitor the Frame Delay and Frame Loss performance of
an AUC without deploying CPE. It supports a MEP at the ALA UNI which supports loopback and linktrace
and generation of Y.1731 LMR and DMR Messages in response to a Y.1731 LMM or DMM message from
a remote MEP. This allows support for single ended frame loss measurement and two-way frame delay
Measurement.
5.8.3 AUC MEG
The ALA provider can configure the ALA-user MEG on the VLAN that supports the AUC. It supports MEPs
that allow the ALA-provider to run continuity check, linktrace and loopback operations between the UNI
and NNI for each AUC. Support of this MEG by the ALA provider allows the ALA provider to report the
state of the AUC to the ALA User using ETH-AIS. This MEG is equivalent to the Operator MEG in the MEF
architecture, and the Carrier MEG in the Broadband Forum Architecture.
A1, A2 CPE NTU
A3, A4
UNI MEG NNI MEG
AUC MEG
ALA-User MEG
Untagged
Tagged
Extended-AUC MEG
HGI-RD024 Requirements for an NGA (Active Line Access) Capable NT
P a g e 18 © HGI 2013 – All rights reserved
The AUC MEG exists entirely within the domain of the ALA provider. The operation of this MEG is
therefore a matter for the ALA-Provider and does not need to be specified as part of ALA. The only
related requirement arising from the ALA service definition is that a MEG level is reserved for the use of
the ALA provider.
5.8.4 UNI MEG
The UNI MEG monitors the UNI interface. It can support Continuity Check, Loopback and Linktrace.
This MEG is equivalent to the Access Link MEG in TR-101 [2] and the MEF UNI MEG.
5.8.5 NNI MEG
The NNI MEG monitors the NNI interface. It can support Continuity Check, Loopback and Linktrace.
This MEG is equivalent to the MEF NNI MEG.
5.9 ALA AND LINE SHARING
The ALA service provides a technology agnostic bit-stream service. Therefore it is possible to provide
more than one ALA service connection on a single line, also known as line-sharing. The main business
rationale for this is to support services beyond traditional triple-play, which may not necessarily be
provided by the main Broadband Service. Examples of such services are utilities such as smart metering
or smart grid, business services such as work at home (remote corporate LAN and voice access), and
mobile data offload. The ALA service definition and architecture support such line sharing. The
implications for the NT are that additional QoS and policing functionality are required, and there is an
impact on the number of physical ports, and their functionality (i.e. no local bridging or switching
between LAN ports). There is architectural support for both having a dedicated port per ALA User, and
sharing ports between users, although the latter has significant implications for the in-home network(s).
HGI-RD024 Requirements for an NGA (Active Line Access) Capable NT
P a g e 19 © HGI 2013 – All rights reserved
6 2-BOX HISTORY IN THE HGI
6.1 OVERVIEW OF THE EXISTING HGI DOCUMENT
The concept of a 2-box model is not particularly new. While the HGI Residential Profile Release 1 [3]
focuses on an integrated Gateway, the possibility of a separate NT was recognised in HGI-RD007-R2 [4];
this describes the 2-box scenario, the resulting requirements for the HG, and recommendations (not
requirements) for the NT functionality. The reason for this was that at that time the HGI did not want to
set requirements for boxes other than HGs, and there were few proposed 2-box deployments.
6.2 RATIONALE FOR A NEW DOCUMENT
The HGI has now extended its remit beyond the HG itself and interest in the 2-box model has increased
with the deployment of NGA. Therefore at the very least the 2-box document would have needed to be
updated to turn the recommendations into Requirements. However ALA goes beyond this with its
explicit support for line sharing, and the specification of multiple network QoS classes. This document
therefore specifies NT requirements, driven by, but not limited to, the support of ALA.
This document makes HGI-RD007-R2 obsolete
6.3 RELATIONSHIP TO ETSI WORK
ETSI has also produced a specification for a 2-box NT and while there is some overlap, this does not
obviate the need for this HGI document for the following reasons. The ETSI document contains
significant detail on the physical aspects of the NT box (LEDs etc.) whereas HGI specifies functionality
only. There is a lot of detail on the WAN interfaces in the ETSI case. This is much simpler in the HGI case
and done by reference. The ETSI specification contains elements of ATM where the HGI NT is for pure
Ethernet WAN attachment. Upstream QoS is optional in the ETSI document, whereas it is mandatory in
the HGI case, and it must meet the specific requirements of ALA QoS. The resulting queue structure is
different in the 2 cases. Finally ALA is a pure L2 service with the exception of essential IGMP support
functionality, and while it is able to support the use of PPP, DHCP etc. the HGI NT itself has no
knowledge or awareness of these protocols.
HGI-RD024 Requirements for an NGA (Active Line Access) Capable NT
P a g e 20 © HGI 2013 – All rights reserved
7 GENERIC REQUIREMENTS
7.1 PHYSICAL CONNECTIONS AND CONNECTIVITY
ALA requires support for multiple interfaces on the LAN side; the number is dependent on the access
technology type, and so is specified in the technology-specific Sections.
N° Requirement
R1. The NT MUST NOT allow any local bridging of packets between LANside ports.
R2. The NT MUST forward any ingress customer packets which map to a configured or the default AUC to the upstream Ethernet port.
R3. The NT MUST forward any ingress WAN packets to the appropriate LAN side port on the basis of the S-Tag.
7.2 ALA PORT MODE SUPPORT
ALA specifies 3 port modes at the UNI; S-tagged, Customer Edge tagged and Port tagged. Port tagged is
intended to support a TLS for business customers and only provides a single class of service. While the
use of Port tagged mode is not expected to be common in the residential market, it is included in this
specification to avoid the need for (and possible confusion of) a separate NT specification just for
business use. The S-tagged interface identifies different AUCs, and so allows multiple AUCs to be
supported on a given port. These can belong to the same ALA User or to different ones. Note that a
single AUC can support all the ALA service classes. The Customer Edge port supports a single ALA User
per port, although that user can have both a multicast and unicast service, and access to all 4 service
classes. This mode requires the minimum of configuration, and allows the ALA User the maximum
flexibility with regard to packet tagging.
N° Requirement
R4. The NT MUST support the S-tagged mode on any of its LAN side interfaces.
R5. The NT MUST support the Port tagged mode on any of its LAN side interfaces.
R6. The NT MUST support the Customer edge tagged port mode on any of its LAN side
interfaces.
HGI-RD024 Requirements for an NGA (Active Line Access) Capable NT
P a g e 21 © HGI 2013 – All rights reserved
N° Requirement
R7. The NT MUST only allow the configuration of a single port mode type per physical
(LAN side) interface.
R8. The port mode types for each LAN side physical interface on a given NT device MUST
be able to be independently configured, i.e. they do not need to be of the same type.
7.3 VLAN HANDLING
The following 3 subsections specify the VLAN tag adding, removal and translation for the 3 different
port types. The handling is dependent on both the tagging of the incoming packets, and whether the
handover at the NNI is single or double tagged.
7.3.1 S-TAGGED UNI
N° Requirement
R9. The NT MUST support the configuration of one and only one S-VID per LAN side port as the untagged UNI.
R10. The NT MUST support the configuration at least 4 SVIDs per LAN side port (including the untagged UNI S-VID).
R11.
The NT MUST accept any LAN side, ingress untagged, priority tagged, or S-tagged frames with the VID that matches the configured, untagged UNI VID, remove the S-tag (if present), add the configured default NNI S-tag or S and C tag pair and forward to the appropriate upstream WAN port queue.
R12.
The NT MUST accept any LAN side ingress S-tagged frames with a VID which matches any of the configured VID values for that port, remove the S-tag, add the configured NNI S-tag or S and C tag pair and forward to the appropriate upstream WAN port queue.
R13. The NT MUST drop any LAN side ingress S-tagged frames with an SVID which does not match the untagged UNI VID, or any of the other configured S-tags for that port.
HGI-RD024 Requirements for an NGA (Active Line Access) Capable NT
P a g e 22 © HGI 2013 – All rights reserved
7.3.2 CUSTOMER EDGE PORT UNI
N° Requirement
R14. The NT MUST support the configuration of one and only one CVID per LAN side port as the multicast VID.
R15. The NT MUST accept any LAN side, ingress C-tagged frame with a VID that matches the configured, multicast VID, remove the C-tag, add the configured NNI S-tag or S and C tag pair and forward to the appropriate upstream WAN port queue.
R16.
The NT MUST accept any LAN side, ingress untagged, priority tagged, or C-tagged frames with a VID that does NOT match the configured, multicast VID, add the configured default NNI S-tag or S and C tag pair and forward to the appropriate upstream WAN port queue.
R17. The NT MUST be able to copy the .1p bits in the outermost customer tag to the added S-tag, or S and C-tags.
R18. The NT MUST forward WAN side, ingress frames to ports on the basis of the S-tag. The NT MUST remove the S or S+C tags imposed by the ALA network.
7.3.3 PORT TAGGED UNI
N° Requirement
R19. The NT MUST accept any LAN side, ingress frames, add the configured NNI S-tag or S and C tag pair for that port, and forward to a single upstream WAN port queue regardless of any ingress .1p markings.
R20. The NT MUST forward WAN side, ingress frames to ports on the basis of the S-tag. The NT MUST remove the S or S+C tag imposed by the ALA network.
7.4 FRAME TRANSPARENCY
N° Requirement
R21. The NT MUST transparently forward any VLAN tags that may be present in the payload of the Ethernet frame that are not used for AUC classification.
HGI-RD024 Requirements for an NGA (Active Line Access) Capable NT
P a g e 23 © HGI 2013 – All rights reserved
N° Requirement
R22.
The NT MUST transparently forward any Ethernet frame types except for the following control frames which MUST be dropped:
nBmB Line Code
Inter-Frame Gap
Preamble
Start of frame delimiter
Pause Frames.
R23. The NT MUST process the Frame Check Sequence and discard any errored frames.
.
7.5 UPSTREAM QOS SUPPORT
ALA provides 4 Classes of service, which allows support for a variety of service types such as voice,
unicast and multicast video, data and a lower class data service which receives a maximum defined
share of the available bandwidth under congestion.
N° Requirement
R24. The NT MUST support all 4 ALA classes of service (A,B,C,D).
R25. The NT MUST support giving Class A traffic strict priority over all other classes.
R26. The NT MUST support giving Class B traffic strict priority over classes C and D.
R27. The NT MUST support a configurable weighting between Class C and Class D traffic in the event of upstream congestion.
R28. The NT MUST support a configurable, per-Class policer for Classes A, B and C+D for each AUC.
R29. The NT MUST support a total of at least 8 queues (allocated over all its AUCs), of which at least 6 MUST be able to be strict priority.
HGI-RD024 Requirements for an NGA (Active Line Access) Capable NT
P a g e 24 © HGI 2013 – All rights reserved
7.6 QOS MARKINGS
N° Requirement
R30.
The NT MUST allocate packets to Classes on the basis of the following markings for C-tagged frames, or S-tagged frames with a TPID=0x8100:
PCP Class
4 A
3 B
2 C
1 C drop eligible
0 D
R31.
The NT MUST allocate packets to Classes on the basis of the following markings for S-tagged frames with a TPID=0x88a8:
PCP DEI Class
4 X A
3 X B
2 0 C
2 1 C drop eligible
1 X C drop eligible
0 X D
R32. The NT MUST treat user packets which do not have a defined PCP marking, i.e. PCP = 5, 6 or 7, as Class C, Drop Eligible or drop them.
HGI-RD024 Requirements for an NGA (Active Line Access) Capable NT
P a g e 25 © HGI 2013 – All rights reserved
7.7 ENERGY EFFICIENCY
The ALA NT is a simpler device than a full blown HG, and further, the primary purpose of the NT is to
terminate the access transmission system. There is therefore less opportunity for power saving than
with an HG, especially given the increase in services such as Smart Grid, security and Cloud which
require a continuous access connection.
However one of the features of the ALA NT is its multiple LAN side Ethernet interfaces. These may not all
be used in all deployments and so there is the opportunity to turn some off. This is done automatically
by detecting the absence of a cable, rather than by management control.
N° Requirement
R33. The NT MUST automatically power down any LAN side Ethernet port which is not connected to an external cable.
R34. The NT MUST ensure that any LAN side Ethernet ports is powered up within 3 seconds
of an external cable being plugged into that port.
R35. The NT MUST comply with the appropriate power consumption levels of the EU CoC
on Broadband Power.
R36. The NT Ethernet ports MUST be of the Energy Efficiency type (IEEE 802.az).
7.8 MULTICAST SUPPORT
.N° Requirement
R37. The NT MUST only deliver multicast frames to the LAN side port mapped to a given AUC.
R38. The NT MUST NOT broadcast multicast packets to LAN side ports.
R39. The NT MUST NOT support IGMP snooping and replication.
7.9 SECONDARY LAN INTERFACES
The primary purpose of a secondary LAN interface is to provide L2, wireless connectivity to sensors or
controllers used as part of a utility service such as security and home automation, or Smart Grid related
applications.
HGI-RD024 Requirements for an NGA (Active Line Access) Capable NT
P a g e 26 © HGI 2013 – All rights reserved
N° Requirement
R40.
The NT SHOULD be able to support at least one of the following secondary LAN interfaces:
Zigbee
Z-Wave
DECT ULE.
HGI-RD024 Requirements for an NGA (Active Line Access) Capable NT
P a g e 27 © HGI 2013 – All rights reserved
8 TECHNOLOGY SPECIFIC REQUIREMENTS
Four different types of WAN interface are specified in this document:
VDSL2
Ethernet (short reach, electrical)
GPON
Point to point fibre (long reach, single mode)
Any given NT would normally only have one of these WAN interface types.
While the same architecture can in principle apply to a cable network, there are some significant technology, functional and commercial differences between a cable network and the above access types, and so cable access is not covered in this document.
8.1 VDSL2
8.1.1 WAN-SIDE INTERFACES
N° Requirement
R41. The NT MUST support VDSL2 as per [5].
R42.
The NT MUST support at least the following VDSL2 Region B bandplans:
Plan 997, 7 MHz
Plan 997, 12 MHz
Plan 997, 17 MHz
Plan 998, 8.5 MHz
Plan 998, 12 MHz
Plan 998, 17 MHz.
R43. The NT SHOULD support the bonding of 2 VDSL access systems according to G.bond.
HGI-RD024 Requirements for an NGA (Active Line Access) Capable NT
P a g e 28 © HGI 2013 – All rights reserved
8.1.2 LAN-SIDE INTERFACES
N° Requirement
R44. The NT MUST provide at least 2 LAN-side 100/1000 Mbps Ethernet ports.
Note: 100/1000 Mbps means the ability to support 100 Mbps and 1Gbps
R45. The LAN-side ports MUST support rate auto-negotiation between 100 Mbps and 1 Gbps.
8.2 UPSTREAM QUEUES
N° Requirement
R46. The NT MUST support allocating any queue to any AUC.
R47. The NT MUST support mapping packets to queues on the basis of VID and priority bit.
R48. The NT MUST support at least 8 strict priority queues with at least 6 different priority levels.
R49. Each queue MUST have a configurable weighting.
R50.
Where 2 or more queues have the same priority level, the NT MUST schedule between
these queues on a WRR basis. Where the weights are equal, the scheduling
opportunities MUST be done on a single packet by packet basis.
R51. The NT MUST support a configurable policer per queue.
An example queuing implementation is shown in Annexe 1.
8.3 ETHERNET WAN INTERFACE
8.3.1 WAN INTERFACE
N° Requirement
R52. The NT MUST support a single 100/1000 Mbps WANside electrical Ethernet interface.
HGI-RD024 Requirements for an NGA (Active Line Access) Capable NT
P a g e 29 © HGI 2013 – All rights reserved
N° Requirement
R53. The WANside port MUST support rate auto-negotiation between 100 Mbps and 1 Gbps.
8.3.2 LAN INTERFACES
N° Requirement
R54. The NT MUST provide at least 4 LAN side 100/1000 Mbps Ethernet interfaces.
R55. The LAN side ports MUST support rate auto-negotiation between 100 Mbps and 1 Gbps.
8.4 UPSTREAM QUEUES
N° Requirement
R56. The NT MUST support allocating any queue to any AUC.
R57. The NT MUST support mapping packets to queues on the basis of VID and priority bit.
R58. The NT MUST support at least 8 strict priority queues with at least 4 different priority levels.
R59. The NT MUST support a configurable policer per queue.
8.5 GPON
8.5.1 WAN INTERFACE
N° Requirement
R60. The NT MUST provide a GPON interface as per ITU-T G.984 [6]
8.5.2 LAN INTERFACES
HGI-RD024 Requirements for an NGA (Active Line Access) Capable NT
P a g e 30 © HGI 2013 – All rights reserved
N° Requirement
R61. The NT MUST provide 4 LAN side100/1000 Mbps interface.
R62. The LAN side interfaces MUST support rate auto-negotiation between 100 Mbps and 1 Gbps.
8.5.3 T-CONTS
N° Requirement
R63. The NT MUST support at least 4, Type 5 T-CONTs per port.
8.6 POINT TO POINT FIBRE
8.6.1 WAN INTERFACE
N° Requirement
R64. The NT MUST support a single mode, Gigabit Ethernet Fibre (LX) interface.
8.6.2 LAN INTERFACES
N° Requirement
R65. The NT MUST provide at least 4 LAN side100/1000 Mbps ports.
R66. The LAN side ports MUST support rate auto-negotiation between 100 Mbps and 1 Gbps.
HGI-RD024 Requirements for an NGA (Active Line Access) Capable NT
P a g e 31 © HGI 2013 – All rights reserved
8.7 UPSTREAM QUEUES
N° Requirement
R67. The NT MUST support allocating any queue to any AUC.
R68. The NT MUST support mapping packets to queues on the basis of VID and priority bit.
R69. The NT MUST support at least 8 strict priority queues with at least 4 different priority levels.
R70. The NT MUST support a configurable policer per queue.
HGI-RD024 Requirements for an NGA (Active Line Access) Capable NT
P a g e 32 © HGI 2013 – All rights reserved
9 DIAGNOSTICS
These requirements are a simplified subset of the HG diagnostics requirements specified in [7]. The NT
has no concept of service signatures, and so packet counting can only be qualified by the value of the
.1p bits. Access to these counters is only available remotely.
N° Requirement
R71. All the following counters in this Section MUST be available for each WAN and LAN interface logical (L2) interface.
R72. All counts MUST be available as the total number of packets per sample time, packets per second and kbps.
R73. Every counter MUST be reset upon reception of a specific remote management command.
R74. All counters SHOULD be individually resettable via a remote management command.
R75. The current value of all counters MUST be able to be read by a remote management system.
R76.
The NT MUST have a single configurable sample interval. The sample interval MUST be configurable from 1-60 seconds with 1 second granularity and SHOULD be configurable from 1-900 seconds.
R77. The sample intervals of all counters MUST be synchronised.
R78. The NT MUST store in DRAM the last N results for the sample interval counters, where N is configurable from 1 to 256.
R79. The NT MUST maintain a sample interval count of the number of sent packets with a specified .1p marking.
R80. The NT MUST maintain a sample interval count of the number of received packets with a specified .1p marking.
HGI-RD024 Requirements for an NGA (Active Line Access) Capable NT
P a g e 33 © HGI 2013 – All rights reserved
10 OAM
These requirements are adapted from the RG OAM requirements in the BB Forum TR-101v2
specification [2].
10.1 ALA-USER MEG
N° Requirement
R81. The NT MUST support a Maintenance association End Point (MEP) on a per VLAN basis.
R82. The NT MUST support a default ME level value of 5 for the Customer level.
R83.
The NT SHOULD support a Loopback Message (LBM) function that can generate a Multicast LBM towards its peer MEP(s). This requirement allows the HG to dynamically learn the MAC address of the BNG MEP (i.e. from the LBR) and could also be used to announce the HG MEP MAC address to the BNG upon request.
R84. The NT MUST support a Loopback Reply (LBR) function towards its peer MEP(s) in response to both unicast and multicast LBMs.
R85. The NT MUST support a Link Trace Reply (LTR) function towards the source address of a received LTM.
R86. The NT SHOULD support generating Continuity Check Messages (CCMs).
R87. The NT MUST support turning off the sending of CCMs, while keeping the associated MEP active.
R88. The NT MUST support receiving AIS messages.
R89. The NT SHOULD trigger the appropriate alarms for Loss of Continuity.
HGI-RD024 Requirements for an NGA (Active Line Access) Capable NT
P a g e 34 © HGI 2013 – All rights reserved
11 MANAGEMENT
Management of GPON NTs is expected to be done by OMCI, and so there are no additional ONT
management requirements.
Management of VDSL, Ethernet and point to point fibre NTs will be IP-based and therefore require an IP-
stack and support for CWMP.
N° Requirement
R90. Non GPON NTs MUST have an IP stack for management purposes.
R91. Non GPON NTs MUST support CWMP based management as per [8], [9] and [10] etc.
HGI-RD024 Requirements for an NGA (Active Line Access) Capable NT
P a g e 35 © HGI 2013 – All rights reserved
12 REFERENCES 1 NICC ND 1644 V1.1.1
http://www.niccstandards.org.uk/files/current/ND1644v1.1.1.pdf?type=pdf 2 Migration to Ethernet-Based Broadband Aggregation - TR101v2, Broadband Forum, 2011 3 Home Gateway Technical Requirements: Residential Profile V1.01 - HGI-RD001-R2.01, 2008 4 Requirements for HG Interworking with an External NT- HGI-RD007-R2, 2009 5 ITU G.993.2, 2011 6 ITU G.984.1, 2008 7 HGI-RD016 ”Home Gateway and Home Network Diagnostics Module Requirements” 8 CPE WAN Management Protocol - (TR-069 Amendment 4, Broadband Forum 2011) 9 Internet Gateway Device Data Model for TR-069 - TR-098 Amendment 2, Broadband Forum,
2008 10 Device Data Model for TR-069 - TR-181 Issue 2, Amendment 6, Broadband Forum, 2012
HGI-RD024 Requirements for an NGA (Active Line Access) Capable NT
P a g e 36 © HGI 2013 – All rights reserved
1 ANNEXE 1
Figure 2 shows a scheduling implementation at the ALA NT VDSL2 upstream interface supporting 2, 4-
Class ALA users. However as the primary reason for not sharing Class B queues is to control multicast
injection, in this example (upstream) Class B traffic is shown sharing a queue.
Figure 2: VDSL interface upstream scheduling example
On the ALA NT upstream ingress, class A and class B traffic is policed according to the ingress bandwidth
profile for the AUC group corresponding to each ALA User. This allows traffic from ALA User X and ALA
User Y to share the Class B upstream queue, but the Class A traffic for each user is queued separately so
the jitter is constrained to a single packet. Class A traffic is scheduled with strict priority over Class B
traffic. Class B traffic is scheduled with strict priority over Class C/D traffic.
Class C and Class D are scheduled using a weighted round robin algorithm. The weighting between Class
C and Class D traffic is combined with any weighting desired between the traffic of different ALA Users.
In this case the bandwidth is split 60:40 between ALA Users (as they are taking different products) and
the split between Class C and Class D is 90:10 for User X, and 75:25 for User Y. The Class C and Class D
queues use WRED to ensure that drop eligible frames tend to be discarded first.
Priority 3
Priority 2
Priority 1
VDSL2
interface (US)
DWRR
Class A, ALA User X
ALA User X, Class C, Weight = 54%
ALA User X, Class D, Weight = 6%
ALA User Y, Class C, Weight = 30%
ALA User Y, Class D, Weight = 10%
Class B, ALA User X&Y
Class A, ALA User Y
Round
Robin
Recommended