]> RtBrick

christian@rtbrick.com

Deutsche Telekom AG

haagt@telekom.de

Deutsche Telekom AG

b.witschurke@telekom.de

This document specifies extensions to the Access Node Control Protocol (ANCP), defined in RFC6320, to support Passive Optical Networks (PON) and evolving DSL technologies such as G.fast. To accommodate these diverse access environments, this document updates RFC6320 by modernizing existing terminologies, adapting message flows, and defining new Type-Length-Value (TLV) attributes. About This Document Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction While outlines the application of ANCP to Passive Optical Networks (PON), the core ANCP specification () has not yet been updated to natively support these deployments. Concurrently, DSL technology has continued to advance, introducing upgraded standards like G.fast, VDSL2 Vectoring, and VDSL2 Annex Q to deliver significantly higher bandwidths over the last mile. To bridge this gap, this document updates the protocol to encompass these modern telecommunication access technologies by specifying the necessary new TLVs not currently supported by .

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This section repeats some definitions from and , but also updates some definitions where appropriate.

Access Node (AN):

• 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):

• The 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):

• The 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):

• The ONU is 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.

Modification to ANCP - General Aspects When applied to PON, ANCP message formats remain identical to those described in . However, specific message descriptions must be updated to broaden their applicability beyond DSL deployments to include other access networks. Specifically, the ANCP Adjacency message is extended to support access technologies beyond DSL. To achieve this, the following existing ANCP capabilities are updated to specify an Access Technology of "ANY":

• Capability Type: Access Topology Discovery = 0x01
  • Access technology: ANY
  • Length (in bytes): 0
  • Capability Data: NULL
  • For the detailed protocol specification of this capability, see .
• Capability Type: Access Line Configuration = 0x02
  • Access technology: ANY
  • Length (in bytes): 0
  • Capability Data: NULL
  • For the detailed protocol specification of this capability, see .
• Capability Type: Access Remote Line Connectivity Testing = 0x04
  • Access technology: ANY
  • Length (in bytes): 0
  • Capability Data: NULL
  • For the detailed protocol specification of this capability, see .

Modification to DSL-Type TLV 0x0091 Add the following new DSL-Type values. Value: 32-bit unsigned integer

• G.fast = 8
• VDSL2 Annex Q = 9
• SDSL bonded = 10
• VDSL2 bonded = 11
• G.fast bonded = 12
• VDSL2 Annex Q bonded = 13

Extension to DSL Sub TLV DSL sub TLVs are listed in . G.fast requires beside existing TLVs the following new TLVs.

Expected Throughput (ETR) TLV

• Type: 0x009B Expected Throughput at L2 (ETR) upstream
  • Length: 4 bytes
  • Value: Rate in kbits/s as a 32-bit unsigned integer.
  • Description: Reports the expected throughput upstream after retransmission (ITU-T G.997.2, clause 7.11.1.2).
• Type: 0x009C Expected Throughput at L2 (ETR) downstream
  • Length: 4 bytes
  • Value: Rate in kbits/s as a 32-bit unsigned integer.
  • Description: Reports the expected throughput downstream after retransmission (ITU-T G.997.2, clause 7.11.1.2).

Attainable Expected Throughput (ATTETR) TLV

• Type: 0x009D Attainable Expected Throughput (ATTETR) upstream
  • Length: 4 bytes
  • Value: Rate in kbits/s as a 32-bit unsigned integer.
  • Description: Reports the attainable expected throughput upstream at L2 (ITU-T G.997.2, clause 7.11.2.2).
• Type: 0x009E Attainable Expected Throughput (ATTETR) downstream
  • Length: 4 bytes
  • Value: Rate in kbits/s as a 32-bit unsigned integer.
  • Description: Reports the attainable expected throughput downstream at L2 (ITU-T G.997.2, clause 7.11.2.2).

Gamma Data Rate (GDR) TLV

• Type: 0x009F Gamma data rate (GDR) upstream
  • Length: 4 bytes
  • Value: Rate in kbits/s as a 32-bit unsigned integer.
  • Description: Reports the Gamma data rate (GDR)
  • upstream (ITU-T G.997.2, clause 7.11.1.3).
• Type: 0x00A0 Gamma Data Rate (GDR) downstream
  • Length: 4 bytes
  • Value: Rate in kbits/s as a 32-bit unsigned integer.
  • Description: Reports the Gamma data rate (GDR)
  • downstream (ITU-T G.997.2, clause 7.11.1.3).

Attainable Gamma Data Rate (ATTGDR) TLV

• Type: 0x00A1 Attainable Gamma data rate (ATTGDR) upstream
  • Length: 4 bytes
  • Value: Rate in kbits/s as a 32-bit unsigned integer.
  • Description: Reports the attainable Gamma data rate upstream (ATTGDR) (ITU-T G.997.2, clause 7.11.2.3).
• Type: 0x00A2 Attainable Gamma data rate (ATTGDR) downstream
  • Length: 4 bytes
  • Value: Rate in kbits/s as a 32-bit unsigned integer.
  • Description: Reports the attainable Gamma data rate (ATTGDR) downstream (ITU-T G.997.2, clause 7.11.2.3).

ANCP-Based PON Topology Discovery This section describes topology discovery messages applied for PON. TLVs not addressed here remain the same as applied for DSL.

ANCP Port Up and Port Down Event Message Descriptions The format of the ANCP Port Up and Port Down Event messages is shown in . 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.

Format of the ANCP Port Up and Port Down Event Messages for PON Topology Discovery

NOTE: TLVs MAY be in a different order from what is shown in this figure. See 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 as described in . The five-word Unused field is a historical leftover. The handling of unused/reserved fields is described in . 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 . # 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.

PON Access Line Identification 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.

Access-Loop-Circuit-ID TLV

• Type: 0x0001
• Description: 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 .
• Length: Up to 63 bytes
• Value: ASCII string

Access-Loop-Remote-ID TLV

• Type: 0x0002
• Description: An operator-configured string that uniquely identifies the user on the associated access line, as described in Section 5.7 of .
• Length: Up to 63 bytes
• Value: ASCII string

PON-Access-Line-Attributes TLV

• Type: 0x0012
• Description: 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 , such as TLV0x0090, are valid for PON and not repeated here.

PON-Access-Type TLV

• Type: 0x0097
• Description: Indicates the type of PON transmission system in use.
• Length: 4 bytes
• Value: 32-bit unsigned integer
  • OTHER = 0
  • GPON = 1
  • XG-PON1 = 2
  • TWDM-PON = 3
  • XGS-PON = 4
  • WDM-PON = 5
  • Unknown = 7
  • 25GS-PON = 8
  • 50G-PON = 9

ONT/ONU-Average-Data-Rate-Downstream TLV

• Type: 0x00B0
• Description: ONT/ONU downstream average data rate L2
• Length: 4 bytes
• Value: Rate in kbits/s as a 32-bit unsigned integer

ONT/ONU-Peak-Data-Rate-Downstream TLV

• Type: 0x00B1
• Description: ONT/ONU downstream peak data rate L2
• Length: 4 bytes
• Value: Rate in kbits/s as a 32-bit unsigned integer

ONT/ONU-Maximum-Data-Rate-Upstream TLV

• Type: 0x00B2
• Description: ONT/ONU upstream maximum data rate L2
• Length: 4 bytes
• Value: Rate in kbits/s as a 32-bit unsigned integer

ONT/ONU-Assured-Data-Rate-Upstream TLV

• Type: 0x00B3
• Description: ONT/ONU upstream assured data rate L2
• Length: 4 bytes
• Value: Rate in kbits/s as a 32-bit unsigned integer

PON-Tree-Maximum-Data-Rate-Upstream TLV

• Type: 0x00B4
• Description: PON Tree upstream maximum data rate L2
• Length: 4 bytes
• Value: Rate in kbits/s as a 32-bit unsigned integer

PON-Tree-Maximum-Data-Rate-Downstream TLV

• Type: 0x00B5
• Description: PON Tree downstream maximum data rate L2
• Length: 4 bytes
• Value: Rate in kbits/s as a 32-bit unsigned integer

Reserved TLV

• Type: 0x00B6 - 0x00B7
• Description: Reserved
• Length: tbd
• Value: tbd

Security Considerations This document does not introduce additional security considerations beyond those discussed in and .

IANA Considerations

Early IANA Allocation Request Note to the RFC Editor and IANA: Multiple vendors have already implemented the ANCP extensions described in this document, and the exact TLV Type values specified below are actively deployed in production networks. To prevent severe breakage of backwards compatibility within this existing deployed base, the authors formally request the early allocation of these specific TLV Type values according to the procedures defined in .

ANCP TLV Type Registry This document defines the following sets of new TLVs for PON and evolving DSL access technologies. Some values previously defined by are referenced here for completeness. IANA is requested to allocate the specific code points listed below in the "ANCP TLV Type" registry.

Type Code	TLV Name	Reference
0x0000	Reserved	RFC 6320
0x0001	Access-Loop-Circuit-ID	RFC 6320
0x0002	Access-Loop-Remote-ID	RFC 6320
0x0003	Access-Aggregation-Circuit-ID-ASCII	RFC 6320
0x0005	Service-Profile-Name	RFC 6320
0x0006	Access-Aggregation-Circuit-ID-Binary	RFC 6320
0x0011	Command	RFC 6320
0x0012	PON-Access-Line-Attributes	RFC TBD1
0x0097	PON-Access-Type	RFC TBD1
0x0098	Reserved	RFC TBD1
0x0099	Reserved	RFC TBD1
0x009A	Reserved	RFC TBD1
0x009B	Expected Throughput (ETR) upstream	RFC TBD1
0x009C	Expected Throughput (ETR) downstream	RFC TBD1
0x009D	Attainable Expected Throughput (ATTETR) upstream	RFC TBD1
0x009E	Attainable Expected Throughput (ATTETR) downstream	RFC TBD1
0x009F	Gamma Data Rate (GDR) upstream	RFC TBD1
0x00A0	Gamma Data Rate (GDR) downstream	RFC TBD1
0x00A1	Attainable Gamma Data Rate (ATTGDR) upstream	RFC TBD1
0x00A2	Attainable Gamma Data Rate (ATTGDR) downstream	RFC TBD1
0x00B0	ONT/ONU-Average-Data-Rate-Downstream	RFC TBD1
0x00B1	ONT/ONU-Peak-Data-Rate-Downstream	RFC TBD1
0x00B2	ONT/ONU-Maximum-Data-Rate-Upstream	RFC TBD1
0x00B3	ONT/ONU-Assured-Data-Rate-Upstream	RFC TBD1
0x00B4	PON-Tree-Maximum-Data-Rate-Upstream	RFC TBD1
0x00B5	PON-Tree-Maximum-Data-Rate-Downstream	RFC TBD1
0x00B6	Reserved	RFC TBD1
0x00B7	Reserved	RFC TBD1
0x0106	Status-Info	RFC 6320
0x1000	Target (single access line variant)	RFC 6320
0x1001 -	Reserved for Target variants	RFC 6320

Note to the RFC Editor: Please replace "TBD1" with the assigned RFC number prior to publication.

Creation of the ANCP DSL-Type Registry This document requests that IANA create a new registry titled "ANCP DSL-Type" within the Access Node Control Protocol (ANCP). The registration procedure for this registry is "IETF Review" as defined in RFC 8126. The registry consists of 32-bit unsigned integers. IANA is requested to populate this new registry with the initial values defined in RFC 6320, as well as the new values defined in this document (which are subject to the early allocation request noted above).

Value	Description	Reference
1	ADSL1	RFC 6320
2	ADSL2	RFC 6320
3	ADSL2+	RFC 6320
4	VDSL1	RFC 6320
5	VDSL2	RFC 6320
6	SDSL	RFC 6320
7	Unknown	RFC 6320
8	G.fast	TBD1
9	VDSL2 Annex Q	TBD1
10	SDSL bonded	TBD1
11	VDSL2 bonded	TBD1
12	G.fast bonded	TBD1
13	VDSL2 Annex Q bonded	TBD1

Creation of the ANCP PON-Access-Type Registry This document requests that IANA create a new registry titled "ANCP PON-Access-Type" within the Access Node Control Protocol (ANCP) parameters. The registration procedure for this registry is "IETF Review" as defined in RFC 8126. The registry consists of 32-bit unsigned integers representing the type of PON transmission system in use. IANA is requested to populate this new registry with the initial values defined in this document (which are subject to the early allocation request noted above).

Value	Description	Reference
0	OTHER	TBD1
1	GPON	TBD1
2	XG-PON1	TBD1
3	TWDM-PON	TBD1
4	XGS-PON	TBD1
5	WDM-PON	TBD1
7	Unknown	TBD1
8	25GS-PON	TBD1
9	50G-PON	TBD1

References Normative References The purpose of this document is to provide applicability of the Access Node Control Mechanism to broadband access based on Passive Optical Networks (PONs). The need for an Access Node Control Mechanism between a Network Access Server (NAS) and an Access Node Complex, composed of a combination of Optical Line Termination (OLT) and Optical Network Termination (ONT) elements, is described in a multi-service reference architecture in order to perform QoS-related, service-related, and subscriber-related operations. The Access Node Control Mechanism is also extended for interaction between components of the Access Node Complex (OLT and ONT). The Access Node Control Mechanism will ensure that the transmission of information between the NAS and Access Node Complex (ANX) and between the OLT and ONT within an ANX does not need to go through distinct element managers but rather uses direct device-to-device communication and stays on net. This allows for performing access-link-related operations within those network elements to meet performance objectives. This document describes the Access Node Control Protocol (ANCP). ANCP operates between a Network Access Server (NAS) and an Access Node (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)) in a multi-service reference architecture in order to perform operations related to Quality of Service, service, and subscribers. Use cases for ANCP are documented in RFC 5851. As well as describing the base ANCP protocol, this document specifies capabilities for Digital Subscriber Line (DSL) topology discovery, line configuration, and remote line connectivity testing. The design of ANCP allows for protocol extensions in other documents if they are needed to support other use cases and other access technologies. ANCP is based on the General Switch Management Protocol version 3 (GSMPv3) described in RFC 3292, but with many modifications and extensions, to the point that the two protocols are not interoperable. For this reason, ANCP was assigned a separate version number to distinguish it. [STANDARDS-TRACK] In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This memo describes the process for early allocation of code points by IANA from registries for which "Specification Required", "RFC Required", "IETF Review", or "Standards Action" policies apply. This process can be used to alleviate the problem where code point allocation is needed to facilitate desired or required implementation and deployment experience prior to publication of an RFC, which would normally trigger code point allocation. The procedures in this document are intended to apply only to IETF Stream documents. Informative References Broadband Forum The purpose of this document is to define a framework for an Access Node Control Mechanism between a Network Access Server (NAS) and an Access Node (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)) in a multi-service reference architecture in order to perform operations related to service, quality of service, and subscribers. The Access Node Control Mechanism will ensure that the transmission of the information does not need to go through distinct element managers but rather uses a direct device-device communication. This allows for performing access-link-related operations within those network elements, while avoiding impact on the existing Operational Support Systems. This document first identifies a number of use cases for which the Access Node Control Mechanism may be appropriate. It then presents the requirements for the Access Node Control Protocol (ANCP) that must be taken into account during protocol design. Finally, it describes requirements for the network elements that need to support ANCP and the described use cases. These requirements should be seen as guidelines rather than as absolute requirements. RFC 2119 therefore does not apply to the nodal requirements. This document is not an Internet Standards Track specification; it is published for informational purposes.

Acknowledgments The authors would like to give special recognition to Hongyu Li, who served as a primary author on earlier versions of this draft. His foundational efforts and significant technical contributions during his time at Huawei Technologies were instrumental in shaping this document. 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.