| Internet-Draft | ANCP Extensions for TSF | October 2026 |
| Song | Expires 25 April 2027 | [Page] |
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).¶
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 (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.¶
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.¶
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).¶
Figure 1 shows the reference architecture for TSF functionaility used in C/U separation broadband networks.¶
+------------------+
| 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) |<------------------>| |
+------------------+ +----------------+
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).¶
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.¶
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.¶
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) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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).¶
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).¶
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.¶
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).¶
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:¶
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Capability Type (16) | Length (16)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Value (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.¶
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Connection Type is taken from the "ANCP TSF Connection Type" registry. Initial values:¶
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.¶
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¶
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].¶
This document requests IANA to make the following allocations in the "Access Node Control Protocol (ANCP) Parameters" registries.¶
Type: TBD1¶
Name: TSF Capability¶
Length: 0 or 2 bytes¶
Value: TSF capability data¶
Reference: This document¶
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¶
| 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 |