Network Working Group X. Song Internet-Draft ZTE Corp. Intended status: Standards Track 22 October 2026 Expires: 25 April 2027 TSF Extensions to ANCP in CU Separation Broadband Networks draft-song-broadband-ancp-tsf-00 Abstract This document specifies a Traffic Steering Function (TSF) capability extension to the Access Node Control Protocol (ANCP), to discover and manage disaggregated user-plane (UP) functions in control/user plane separated networks, including the Access Network User Plane (AN-UP) and the Network Access Server User Plane (NAS-UP). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 25 April 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Song Expires 25 April 2027 [Page 1] Internet-Draft ANCP Extensions for TSF October 2026 Table of Contents 1. Background and Motivation . . . . . . . . . . . . . . . . . . 2 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. Reference Architecture . . . . . . . . . . . . . . . . . . . 3 4. TSF Capability in the ANCP Adjacency Message . . . . . . . . 4 5. TSF UP Report Message . . . . . . . . . . . . . . . . . . . . 5 6. TSF TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. UP-Device-Info TLV . . . . . . . . . . . . . . . . . . . 6 6.2. UP-Capability TLV . . . . . . . . . . . . . . . . . . . . 6 6.3. UP-Connection-Info TLV . . . . . . . . . . . . . . . . . 7 6.4. UP-Status TLV . . . . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8.1. ANCP Capability Type Registry . . . . . . . . . . . . . . 8 8.2. ANCP Message Type Registry . . . . . . . . . . . . . . . 9 8.3. ANCP TLV Type Registry . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 1. Background and Motivation ANCP [RFC6320] was designed for communication between the Access Node (AN, e.g., a DSLAM) and the Network Access Server (NAS, e.g., a BNG). With the cloudification of metro networks, both the AN and the NAS are gradually evolving into control/user plane separated network functions. For example, an OLT is decomposed into AN-CP and AN-UP functions, and a BNG is decomposed into NAS-CP (BNG-CP) and NAS-UP (BNG-UP) functions. The BBF TR-474 architecture defines Session Steering Context (SSC), in which a User Plane Selection Function (UPSF) acts as the policy hub that selects the optimal user-plane functions for subscriber sessions. TR-474 defines the functional roles and requirements, but does not specify a protocol for user- plane discovery and capability reporting between the UPSF and the control-plane functions. ANCP already runs between access control entities, and it has an extensible TLV machinery and a capability negotiation mechanism in the Adjacency message. This document defines a TSF capability extension to ANCP that allows AN-CP and NAS-CP to report the device information, capabilities, connectivity, and status of the user-plane functions they manage (AN-UP on the OLT, NAS-UP on the BNG) to a UPSF. Song Expires 25 April 2027 [Page 2] Internet-Draft ANCP Extensions for TSF October 2026 2. 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 [RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here. This section repeats some definitions from [RFC6320] and [RFC6934] and adds terms from BBF TR-474. Access Node Control Plane (AN-CP): The control-plane function of TSF. In the BBF TR-474 architecture, the TSF-CP corresponds to the Traffic Steering Function control plane (TSF-CP). Access Node User Plane (AN-UP): The user-plane function of a disaggregated Access Node, e.g., the forwarding function of an OLT. In the BBF TR-474 architecture, the AN-UP corresponds to the Traffic Steering Function user plane (TSF-UP). Network Access Server Control Plane (NAS-CP): The control-plane function of a disaggregated NAS, e.g., the BNG-CP. In the BBF TR-474 architecture, the NAS-CP corresponds to the Service Gateway control plane (SG-CP), which can be BNG-CP, FMIF-CP, AGF-CP, etc. Network Access Server User Plane (NAS-UP): The user-plane function of a disaggregated NAS, e.g., the BNG-UP, FMIF-UP, AGF-UP, etc. Traffic Steering Function (TSF): The access-side function defined in BBF TR-474 that decides which user-plane instance a subscriber session should be steered to. User Plane Selection Function (UPSF): The policy hub defined in BBF TR-474 that collects user-plane information and establishes subscriber-to-user-plane mappings. Subscriber Session Context (SSC): The BBF TR-474 framework for dynamically steering subscriber sessions to optimal user-plane instances based on policy (e.g., QoS, load, location). 3. Reference Architecture Figure 1 shows the reference architecture for TSF functionaility used in C/U separation broadband networks. Song Expires 25 April 2027 [Page 3] Internet-Draft ANCP Extensions for TSF October 2026 +------------------+ | UPSF | | (TR-474 policy | | hub) | +--------+---------+ TSF adjacency| |TSF adjacency +-----------------+ +---------------+ | | +--------+---------+ +-------+--------+ | AN-CP | | NAS-CP | | (TSF-CP, on OLT | | (SG-CP, | | control plane) | | BNG-CP) | +--------+---------+ +-------+--------+ | management/ | management/ | provisioning | provisioning +--------+---------+ +-------+--------+ | AN-UP | AN-UP <-> NAS-UP | NAS-UP | | (OLT forwarding,| user-plane path | (BNG-UP) | | e.g., PON) |<------------------>| | +------------------+ +----------------+ Figure 1: Reference Architecture for TSF Capability Extension Two new ANCP adjacencies are introduced: UPSF to AN-CP: the UPSF discovers and manages the AN-UP functions administered by the AN-CP (e.g., the OLT user plane). UPSF to NAS-CP: the UPSF discovers and manages the NAS-UP functions administered by the NAS-CP (e.g., BNG-UP instances). 4. TSF Capability in the ANCP Adjacency Message Capability negotiation uses the ANCP Adjacency message (Message Type which has value 10) defined in Section 3.5.1 of [RFC6320]. A new capability is defined: Capability Type: TSF (Traffic Steering Function) Access technology: 0 (Not technology dependent) Length: The number of bytes of data contained in the Capability Data sub-field, excluding padding. If the definition of a particular capability includes no capability data, the value of the Capability Length sub-field is zero. Song Expires 25 April 2027 [Page 4] Internet-Draft ANCP Extensions for TSF October 2026 Capability Data: Contains data associated with the capability as specified for that capability. A node advertises the TSF capability only on adjacencies that are provisioned for TSF operation, i.e., toward a peer that is known to implement this extension (e.g., a UPSF). Per the capability negotiation rules of [RFC6320], if the TSF capability is not advertised by both peers, TSF procedures MUST NOT be used on that adjacency, and TSF messages received on such an adjacency MUST be silently discarded. 5. TSF UP Report Message The TSF UP Report message is used by AN-CP and NAS-CP to report the information of the user-plane functions they manage to the UPSF. The format follows the format of the ANCP Port Up and Port Down Event messages defined in section 6.3 of [RFC6320]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TCP/IP Encapsulating Header (section 3.2 of RFC6320) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ANCP General Message Header | + (section 3.6.1 of RFC6320) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |x|x|x|x|x|x|x|x| Message Type | Tech Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | # of TLVs | Extension Block length (bytes)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ TSF TLVs (Section 6) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: TSF UP Report Message Format In the ANCP general message header, the Message Type field MUST be set to TBD2. The Result field MUST be set to zero (Ignore), the Result Code and Transaction Identifier fields MUST be set to zero. Extension Flags (8 bits): reserved, MUST be set to zero. Message Type (8 bits): TBD2. Tech Type (8 bits): MUST be set to 0 (Not technology dependent). Song Expires 25 April 2027 [Page 5] Internet-Draft ANCP Extensions for TSF October 2026 Reserved (8 bits): set as described in Section 3.4 of [RFC6320]. # of TLVs (16 bits): number of TLVs that follow. Extension Block Length (16 bits): total length of the TLVs in bytes, including padding. A TSF UP Report message contains at least one or more UP report TLV identifying the reported user-plane function. It is sent to the UPSF: once, for each managed UP function, after the TSF-capable adjacency has been established; and whenever the reported information changes (e.g., UP status change, new capability, connectivity change). 6. TSF TLVs All TLVs use the TLV format of [RFC6320] Section 3.6.2 (16-bit Type, 16-bit Length, variable Value). The Type values below are suggested to be included to report TSF data. which are marked TBD3 through TBD6. 6.1. UP-Device-Info TLV Type: TBD3 Description: Identifies a user-plane function managed by the sending AN-CP or NAS-CP, e.g., an AN-UP on an OLT or a NAS-UP (BNG-UP) instance. Length: Variable Value: locally unique within the scope of the sending control-plane function (e.g., a device identifier in the style of the circuit identifiers defined in BBF TR156). 6.2. UP-Capability TLV Type: TBD4 Description: Lists the capability descriptors of the reported user- plane function. Length: Variable Value: One or more capability descriptors, each of the form as figure below: Song Expires 25 April 2027 [Page 6] Internet-Draft ANCP Extensions for TSF October 2026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Capability Type (16) | Length (16)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Value (optional) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Capability TLV Capability Type is taken from the "ANCP TSF Capability Type" registry. Initial values: 1 = low-latency forwarding 2 = high-throughput forwarding 3 = low-loss forwarding 4 = customized service (operator-defined) Value is optional and carries a parameter for the capability (e.g., a latency class), its semantics are capability-specific. 6.3. UP-Connection-Info TLV Type: TBD5 Description: Describes how the reported user-plane function is reachable, i.e., the network-side (NNI-side) connectivity that a peer user-plane function would use to reach it. Length: Variable Value: One or more connection descriptors, each of the form: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Connection Type (16) | Length (16)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Value ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Conection TLV Connection Type is taken from the "ANCP TSF Connection Type" registry. Initial values: Song Expires 25 April 2027 [Page 7] Internet-Draft ANCP Extensions for TSF October 2026 1 = physical port (Value: port identifier) 2 = VLAN interface (Value: 4-byte VLAN ID, network byte order) 3 = tunnel (Value: opaque tunnel identifier, e.g., an MPLS label or SRv6 SID) Value is optional and carries a parameter for the connection information. 6.4. UP-Status TLV Type: TBD6 Description: Reports the status of the reported user-plane function. Length: 1 byte Value: 0 = up, 1 = down, 2 = admin-down, 3 = unknown 7. Security Considerations This document does not introduce additional security considerations beyond those discussed in [RFC6320] and [RFC6934]. TSF UP Report messages reveal network topology, user-plane capabilities, and connectivity information; they SHOULD be exchanged only over the trusted control-plane connectivity used for ANCP adjacencies, and adjacency formation SHOULD follow the validation rules of [RFC6320]. 8. IANA Considerations This document requests IANA to make the following allocations in the "Access Node Control Protocol (ANCP) Parameters" registries. 8.1. ANCP Capability Type Registry Type: TBD1 Name: TSF Capability Length: 0 or 2 bytes Value: TSF capability data Reference: This document Song Expires 25 April 2027 [Page 8] Internet-Draft ANCP Extensions for TSF October 2026 8.2. ANCP Message Type Registry Type: TBD2 Name: TSF UP Report Length: 0 or 2 bytes Value: A TSF UP Report message contains at least one UP-Device-Info TLV identifying the reported user-plane function. Reference: This document 8.3. ANCP TLV Type Registry +===========+====================+===============+ | Type Code | TLV Name | Reference | +===========+====================+===============+ | TBD3 | UP-Device-Info | This document | +-----------+--------------------+---------------+ | TBD4 | UP-Capability | This document | +-----------+--------------------+---------------+ | TBD5 | UP-Connection-Info | This document | +-----------+--------------------+---------------+ | TBD6 | UP-Status | This document | +-----------+--------------------+---------------+ Table 1: ANCP TLV Type Registry 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6320] Wadhwa, S., Moisand, J., Haag, T., Voigt, N., and T. Taylor, Ed., "Protocol for Access Node Control Mechanism in Broadband Networks", RFC 6320, DOI 10.17487/RFC6320, October 2011, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 9.2. Informative References Song Expires 25 April 2027 [Page 9] Internet-Draft ANCP Extensions for TSF October 2026 [RFC6934] Bitar, N., Ed., Wadhwa, S., Ed., Haag, T., and H. Li, "Applicability of the Access Node Control Mechanism to Broadband Networks Based on Passive Optical Networks (PONs)", RFC 6934, DOI 10.17487/RFC6934, June 2013, . Author's Address Xueyan Song ZTE Corp. China Email: song.xueyan2@zte.com.cn Song Expires 25 April 2027 [Page 10]