Access Extensions for ANCPHuawei Technologies Co., Ltd.Industrial Base, bantain LonggangShenzhen518129P.R. Chinahonyu.li@huawei.comDeutsche TelekomHeinrich-Hertz_Strasse 3-7Darmstadt64295Germanyhaagt@telekom.deDeutsche TelekomWinterfeldstrasse 21Berlin10781Germanyb.witschurke@telekom.deThe purpose of this document is to specify extensions to ANCP (Access
Node Control Protocol) (RFC6320) to support PON as described in RFC6934
and some other DSL Technologies including G.fast. This document updates
RFC6320 by modifications to terminologies, flows and specifying new TLV
types.This document updates RFC6320 by modifications to terminologies,
flows and specifying new TLV types.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.RFC6934 introduces application of ANCP to PON. However, RFC6320 haven't been updated to support PON.
Besides, DSL technology is also evolving. G.fast, VDSL2 Vectoring and VDSL2 Annex Q were introduced as upgraded versions to provide higher bandwidths for the last mile..This document considers all existing Access technologies used in a
Telco network, yet not supported by RFC6320 and specifies new TLVs
accordingly.This section repeats some definitions from RFC6320 and RFC6934, but also updates some definitions where
appropriate.Access Node (AN): [RFC5851] Network device, usually located at a
service provider central office or street cabinet that terminates access
(local) loop connections from subscribers. In case the access loop is a
Digital Subscriber Line (DSL), the Access Node provides DSL signal
termination and is referred to as a DSL Access Multiplexer (DSLAM). In
case the access loop is a Passive Optical Network (PON), the Access Node
is referred to as an Optical Line Terminal (OLT).Optical Line Terminal (OLT): is located in the service provider's
central office (CO) or street cabinet. It terminates and aggregates
multiple PONs (providing fiber access to multiple premises or
neighborhoods) on the subscriber side and interfaces with the Network
Access Server (NAS) that provides subscriber management.Optical Network Terminal (ONT): terminates PON on the network side
and provides PON adaptation. The subscriber side interface and the
location of the ONT are dictated by the type of network deployment. For
an FTTP deployment (with fiber all the way to the apartment or living
unit), ONT has Ethernet (Fast Ethernet (FE) / Gigabit Ethernet (GE) /
Multimedia over Coax Alliance (MoCA)) connectivity with the Home Gateway
(HGW) / Customer Premises Equipment (CPE). In certain cases, one ONT may
provide connections to more than one Home Gateway at the same time.Optical Network Unit (ONU): a generic term denoting a device that
terminates any one of the distributed (leaf) endpoints of an Optical
Distribution Network (ODN), implements a PON protocol, and adapts PON
PDUs to subscriber service interfaces. In the case of a multi-dwelling
unit (MDU) or multi-tenant unit (MTU), a multi-subscriber ONU typically
resides in the basement or a wiring closet (FTTB case) and has
FE/GE/Ethernet over native Ethernet link or over xDSL (typically VDSL2)
connectivity with each CPE at the subscriber premises. In the case where
fiber is terminated outside the premises (neighborhood or curb side) on
an ONT/ONU, the last-leg-premises connections could be via existing or
new copper, with xDSL physical layer (typically VDSL2). In this case, the
ONU effectively is a "PON-fed DSLAM". In new FTTdp based deployments the
access node is named DPU (Distribution Point Unit). Basically from ANCP
perspective this node provides the same functionality. Besides VDSL2, G.fast is mature and widely deployed.ANCP message formats remain the same as described in section 3.5.1 of
RFC6320 when it is applied to PON. However, some message
descriptions need to be modified to make them applicable to variant
Access Networks, other than DSL specific.The ANCP Adjacency message is extended to other Access Technologies
than DSL. Generalize the message format to following:The following capabilities are defined for ANCP:o Capability Type: Access Topology Discovery = 0x01Access technology: ANYLength (in bytes): 0Capability Data: NULLFor the detailed protocol specification of this capability, see
Section 6 of RFC6320.o Capability Type: Access Line Configuration = 0x02Access technology: ANYLength (in bytes): 0Capability Data: NULLFor the detailed protocol specification of this capability, see
Section 7 of RFC6320.o Capability Type: Access Remote Line Connectivity Testing = 0x04Access technology: ANYLength (in bytes): 0Capability Data: NULLFor the detailed protocol specification of this capability, see
Section 8 of RFC6320.Add following new DSL-Type values.Value: 32-bit unsigned integerG.fast = 8VDSL2 Annex Q = 9SDSL bonded = 10VDSL2 bonded = 11G.fast bonded = 12VDSL2 Annex Q bonded = 13DSL sub TLVs are listed in Section 6.5 of RFC6320. G.Fast requires beside existing TLVs the following new TLVs.Type: 0x009B Expected Throughput at L2 (ETR) upstreamDescription: Reports the expected throughput upstream after retransmission (ITU-T G.997.2, clause 7.11.1.2)Length: 4 bytesValue: Rate in kbits/s as a 32-bit unsigned integerType: 0x009C Expected Throughput at L2 (ETR) downstreamDescription: Reports the expected throughput downstream after retransmission (ITU-T G.997.2, clause 7.11.1.2)Length: 4 bytesValue: Rate in kbits/s as a 32-bit unsigned integerType: 0x009D Attainable Expected Throughput (ATTETR) upstreamDescription: Reports the attainable expected Throughput upstream at L2 (ITU-T G.997.2, clause 7.11.2.2)Length: 4 bytesValue: Rate in kbits/s as a 32-bit unsigned integerType: 0x009E Attainable Expected Throughput (ATTETR) downstreamDescription: Reports the attainable expected Throughput downstream at L2 (ITU-T G.997.2, clause 7.11.2.2)Length: 4 bytesValue: Rate in kbits/s as a 32-bit unsigned integerType: 0x009F Gamma data rate (GDR) upstreamDescription: Reports the Gamma data rate (GDR) upstream (ITU-T G.997.2, clause 7.11.1.3)Length: 4 bytesValue: Rate in kbits/s as a 32-bit unsigned integerType: 0x00A0 Gamma Data Rate (GDR) downstreamDescription: Reports the Gamma data rate (GDR) downstream(ITU-T G.997.2, clause 7.11.1.3)Length: 4 bytesValue: Rate in kbits/s as a 32-bit unsigned integerType: 0x00A1 Attainable Gamma data rate (ATTGDR) upstreamDescription: Reports the Attainable Gamma data rate upstream (ATTGDR) (ITU-T G.997.2, clause 7.11.2.3)Length: 4 bytesValue: Rate in kbits/s as a 32-bit unsigned integerType: 0x00A2 Attainable Gamma data rate (ATTGDR) downstreamDescription: Reports the Attainable Gamma data rate (ATTGDR) (ITU-T G.997.2, clause 7.11.2.3) downstreamLength: 4 bytesValue: Rate in kbits/s as a 32-bit unsigned integerThis section describes topology discovery messages applied for PON.
TLVs not addressed here remain the same as applied for DSL.The format of the ANCP Port Up and Port Down Event messages is
shown in Figure xx1. It has the same format as the one described in
section 6.3 of RFC6320. The only difference is that
DSL-Line-Attributes TLV is updated as Access-Line-Attributes TLV.NOTE: TLVs MAY be in a different order from what is shown in this
figure.Figure xx1: Format of the ANCP Port Up and Port Down Event Messages
for PON Topology DiscoverySee Section 3.6.1 of RFC6320 for a description of the ANCP general
message header. The Message Type field MUST be set to 80 for Port Up,
81 for Port Down. It is applicable to both DSL and PON based access
systems. The 4-bit Result field MUST be set to zero (signifying
Ignore). The 12-bit Result Code field and the 24-bit Transaction
Identifier field MUST also be set to zeroes. Other fields in the
general header MUST be set a as described in Section 3.6 of
RFC6320.The five-word Unused field is a historical leftover. The handling
of unused/reserved fields is described in Section 3.4 of RFC6320.The remaining message fields belong to the "extension block", and
are described as follows:Extension Flags (8 bits): The flag bits denoted by 'x' are
currently unspecified and reserved.Message Type (8 bits): Message Type has the same value as in the
general header (i.e., 80 or 81).Tech Type (8 bits): MUST be set to 0x01 (PON).Reserved (8 bits): set as described in Section 3.4 of RFC6320.# of TLVs (16 bits): The number of TLVs that follow, not counting
TLVs encapsulated within other TLVs.Extension Block Length (16 bits): The total length of the TLVs
carried in the extension block in bytes, including any padding within
individual TLVs.TLVs: One or more TLVs to identify a PON Access line and zero or
more TLVs to define its characteristics.Most ANCP messages involve actions relating to a specific access
line. Thus, it is necessary to describe how PON access lines are
identified within those messages. This section defines four TLVs for
that purpose and provides an informative description of how they are
used in PON. TLVs not addressed here remain unchanged as applied for
DSL.Type: 0x0001Description: A locally administered human-readable string
generated by or configured on the Access Node, uniquely identifying
the corresponding access loop logical port on the user side of the
Access Node, as described in Section 5.7 of [TR-156]..Length: Up to 63 bytesValue: ASCII stringType: 0x0002Description: An operator-configured string that uniquely
identifies the user on the associated access line, as described in
Section 5.7 of [TR-156].Length: Up to 63 bytesValue: ASCII stringType: 0x0012Description: This TLV encapsulates attribute values of a PON
access line serving a subscriber.Length: Variable (up to 1023 bytes)Value: One or more encapsulated TLVs corresponding to PON access
line attributes. The PON-Access-Line-Attributes TLV MUST contain at
least one TLV when it is present in a Port Up or Port Down message.
The actual contents are determined by the AN control
application. Technology-independent attributes of RFC6320, such as TLV0x0090, are valid for PON and not repeated here.Type: 0x0097Description: Indicates the type of PON transmission system in
use.Length: 4 bytesValue: 32-bit unsigned integerOTHER = 0GPON = 1XG-PON1 = 2TWDM-PON = 3XGS-PON = 4WDM-PON = 5Unknown = 7Type: 0x00b0Description: ONT/ONU downstream average data rate L2Length: 4 bytesValue: Rate in kbits/s as a 32-bit unsigned integerType: 0x00b1Description: ONT/ONU downstream peak data rate L2Length: 4 bytesValue: Rate in kbits/s as a 32-bit unsigned integerType: 0x00b2Description: ONT/ONU upstream maximum data rate L2Length: 4 bytesValue: Rate in kbits/s as a 32-bit unsigned integerType: 0x00b3Description: ONT/ONU upstream assured data rate L2Length: 4 bytesValue: Rate in kbits/s as a 32-bit unsigned integerType: 0x00b4Description: PON Tree upstream maximum data rate L2Length: 4 bytesValue: Rate in kbits/s as a 32-bit unsigned integerType: 0x00b5Description: PON Tree downstream maximum data rate L2Length: 4 bytesValue: Rate in kbits/s as a 32-bit unsigned integerType: 0x00b6Description: ReservedLength: tbdValue: tbdType: 0x00b7Description: ReservedLength: tbdValue: tbdThis document defines following sets of TLVs for PON, some of them
have defined by RFC6320 and are referenced here for completeness:There are no new security considerations beyond what is described in
RFC6320 and RFC6934.Many thanks to Norbert Voigt, John Gibbons, Sven Ooghe, Koen De Sagher and Sven Leimer for joint work reviewing the document and providing valuable comments to this document.Using GPON Access in the context of TR-101The Broadband Forum