PCE Working Group L. Han Internet-Draft H. Huang Intended status: Standards Track M. Wang Expires: 5 May 2027 CMCC L. Zhang Huawei J. Zhou ZTE 1 November 2026 Path Computation Element Communication Protocol (PCEP) Extension for Fine Granularity Metro Transport Network (fgMTN) draft-han-pce-fgmtn-00 Abstract This document focuses on the PCEP extension for G.8312 fine granularity metro transport network. It extends PCEP-LS to report the fgMTN topology resource information, and provides the PCEP extension to support the fgMTNP path setup information. 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 5 May 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 Han, et al. Expires 5 May 2027 [Page 1] Internet-Draft draft-han-pce-fgmtn-00 November 2026 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Overview of PCEP Extension in fgMTNP Network . . . . . . . . 4 5. Protocol Extensions for Topology Resource Information Reporting . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. OPEN Object for LS Capability . . . . . . . . . . . . . . 5 5.1.1. LS Capability TLV . . . . . . . . . . . . . . . . . . 5 5.2. LS Object . . . . . . . . . . . . . . . . . . . . . . . . 6 5.2.1. Parent NRP ID Sub-TLV . . . . . . . . . . . . . . . . 6 5.2.2. Sub-Slot BitMap Sub-TLV . . . . . . . . . . . . . . . 7 5.2.3. FGU Client Sub-Slot Bitmap Relationship Sub-TLV . . . 7 5.2.4. FGU Client Sub-Slot Relationship Sub-TLV . . . . . . 9 6. Protocol Extensions for Path Setup . . . . . . . . . . . . . 11 6.1. The OPEN Object . . . . . . . . . . . . . . . . . . . . . 11 6.1.1. The Path Setup Type Capability TLV . . . . . . . . . 11 6.1.2. The fgMTN PCE Capability Sub-TLV . . . . . . . . . . 11 6.2. The RP/SRP Object . . . . . . . . . . . . . . . . . . . . 11 6.3. The LSP Object . . . . . . . . . . . . . . . . . . . . . 12 6.4. The ERO Object . . . . . . . . . . . . . . . . . . . . . 12 6.4.1. FgMTN-ERO Subobject . . . . . . . . . . . . . . . . . 13 6.5. The BANDWIDTH Object . . . . . . . . . . . . . . . . . . 13 7. Deployment Considerations . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 11. Normative References . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction MTN [ITU-T_G.8310] is a new generation of transport network technology system defined by ITU-T. MTN integrates packet and TDM technologies, enabling compatibility with Ethernet protocol stacks while meeting differentiated requirements of the 5G era, such as hard isolation, low latency, and high reliability, thus further enhancing the bearer capability of 5G networks. With the development of transport networks, TDM-based Metro transport network (MTN) is being extended to fine granularity, enabling the provisioning of flexible N*10 Mbps bandwidths for clients. Han, et al. Expires 5 May 2027 [Page 2] Internet-Draft draft-han-pce-fgmtn-00 November 2026 On this basis, ITU-T published a series of fgMTN Recommendations which includes the fgMTN overview [ITU-T_G.8312.20], the fgMTN layer architecture defined in [ITU-T_G.8310], fgMTN interface defined in [ITU-T_G.8312], fgMTN equipment defined in [ITU-T_G.8321]. The fine grainularity Metro Transport Network path layer (fgMTNP) serves as a client of the MTN Path layer, providing sub-1G services for Ethernet MAC frames and CBR clients. The fgMTN technology is one of the means to realize network resource partitions(NRP) [RFC9543]. Compared to conventional MTNP (N*5Gbps) bandwidth, fgMTNP significantly increases the number of LSPs in metro network. Managing such a massive number of fine-grained channels presents major control and management challenges, especially in efficiently establishing and maintaining numerous LSPs. A PCE-based path computation mechanism helps to address these issues. This document specifies a set of extensions to carry the topology resource information and fgMTNP path information in PCEP message. It extends PCEP-LS by defining several new sub-TLVs for the LS object to report the fgMTN topology resource information, which includes timeslot occupation status of links and the relationship between the FGU client and the occupied timeslots. It also defines some fields in PCEP protocol objects to support the PCE delievering path information related to fine-grained tunnel creation, rerouting, and deletion. 2. Requirements Language 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. 3. Terminology fgCS: Fine Grain Calendar Slot fgMTNP: Fine Grainularity Metro Transport Network Path Layer MTN: Metro Transport Network Han, et al. Expires 5 May 2027 [Page 3] Internet-Draft draft-han-pce-fgmtn-00 November 2026 fgMTN: Fine Grainularity Metro Transport Network FGU: Fine Granularity Unit TDM: Time Division Multiplexing 4. Overview of PCEP Extension in fgMTNP Network As described in [I-D.han-pce-path-computation-fg-transport], to address the massive fgMTN path control issues, it's necessary to hybrid centralized controller and distributed control plane architecture. First, network devices collect topology and resource information via a distributed protocol, and report the information to the controller. Based on the collected network-wide topology and resource information, the controller calculates the LSP path according to service requirements and delivers it to the network devices, which then use the distributed protocol to complete path establishment. The centralized control PCE is used to calculate the routing and left the resource allocation to device itself. The path computation results are delivered to ingress node to let distributed control protocols between devices to perform operations of resource (e.g. fine grain calendar slots) allocation and cross connection configuration. [RFC5440] describes the Path Computation Element Communication Protocol (PCEP) for communication between a Path Computation Client (PCC) and a Path Computation Element (PCE). A PCE computes paths based on various constraints and optimization criteria. [RFC8231] specifies PcRpt and PCUpd massages to enable stateful control of TE LSPs, whereby LSPs are configured on the PCC and control over them is delegated to the PCE. [RFC8281] introduces the PCInitiated message which a PCE can send to a PCC to request the initiation or deletion of an LSP. PCEP-LS [I-D.ietf-pce-pcep-ls] extends PCEP to enable the collection of link-state and TE information from networks and sharing with PCE by extending a new LS Report message. Therefore, the stateful PCEP can be applied to path computation of fgMTNP network. The PCEP-LS can be extended to support the reporting of fgMTN topology resources. Han, et al. Expires 5 May 2027 [Page 4] Internet-Draft draft-han-pce-fgmtn-00 November 2026 +------------------------------+ | PCE | +------------------------------+ / / | \ \ | | | | | | | | | | +-+-+ +--+ +--+ +--+ +-+-+ ----|PE1+----+P1+----+P2+-----+P3+----+PE2+---- +-+-+ +--+ +--+ +--+ +-+-+ | | +-----------fgMTNP channel--------+ Figure 1: Scenario of fgMTNP channel As shown in Figure 1, the topology and fgCS resource information of devices are collected and reported to PCE through PCEP-LS. The path calculation is in a centralized way, the calculated paths are sent to the PE1. Specifically, fgMTN LSP path is carried by the explicit route object (ERO) in the PCEP message. The ERO consists of a series of sub-objects. Then, the fgMTNP channel is established between devices through control signaling. For the fgCS resource allocation, since there may be as many as 480 or 960 serices or 480 or 960 fgCSs for one fgMTNP, centralized PCE resource allocation would be inefficient. Moreover, given the flexibility of fgMTN channel, it may be frequently created, deleted, or modified. The mechanism of local device allocation may be appropriate for the fgCSs allocation. 5. Protocol Extensions for Topology Resource Information Reporting 5.1. OPEN Object for LS Capability 5.1.1. LS Capability TLV [I-D.ietf-pce-pcep-ls] defines LS-CAPABILITY TLV for use in the OPEN Object for link-state (and TE) distribution via PCEP capability advertisement. This document defines a new flag in the flags field of the LS- CAPABILITY TLV to indicate the support of fgMTN resource information reporting. Han, et al. Expires 5 May 2027 [Page 5] Internet-Draft draft-han-pce-fgmtn-00 November 2026 Bit M (fgMTN state collection, 1-bit): if set to 1 by a PCC, the M Flag indicates that the PCC allows the reporting of fgMTN resource information learned via other means like LLDP; if set to 1 by a PCE, the M Flag indicates that the PCE is capable of receiving fgMTN resource information. 5.2. LS Object The LS (link-state) object is defined by [I-D.ietf-pce-pcep-ls], it MUST be carried within LSRpt messages. The LS object contains a set of TLVs used to specify the target node's or link's information. [I-D.ietf-pce-pcep-ls] also defines the Link Descriptors TLV, it contains Link Descriptors for each link. The value of it contains one or more Link Descriptor Sub-TLVs. This document defines four kind of Link Descriptor Sub-TLVs to describe the fgMTN resource information. 5.2.1. Parent NRP ID Sub-TLV The Parent NRP ID sub-TLV indicates the NRP ID that the link belongs to. This sub-TLV is an optional sub-TLV MAY be included in the Link Descriptors TLV. At most one instance of this sub-TLV can be included in the Link Descriptors TLV. The format of this sub-TLV is shown in Figure 2. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NRP-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Parent NRP ID Sub-TLV where: Type: TBD1, needs to be allocated by IANA. Length: the length of NRP-ID, equals to 4. NRP-ID: 4-octet length, the value of NRP-ID is the slice ID of the service-layer interface (MTN client or GE/10GE interface) of a fine- grained interface. If t the information does not exist on the device, the default value 0xFFFFFFFF SHOULD be filled. Han, et al. Expires 5 May 2027 [Page 6] Internet-Draft draft-han-pce-fgmtn-00 November 2026 5.2.2. Sub-Slot BitMap Sub-TLV The sub-slot bitmap sub-TLV indicates the timeslot's occupation status of all FGU clients in the link. This sub-TLV is an optional sub-TLV MAY be included in the Link Descriptors TLV. At most one instance of this sub-TLV can be included in the Link Descriptors TLV. The format of this sub-TLV is shown in Figure 3. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / Sub-slot bitmap (variable) / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Parent NRP ID Sub-TLV where: Type: TBD2, needs to be allocated by IANA. Length: the length of sub-slot bitmap, variable. Sub-slot bitmap: variable, indicates the occupation state of all the timeslots of the link, each bit represents a timeslot. If the last bits are all zeros, the padding can be omitted. 5.2.3. FGU Client Sub-Slot Bitmap Relationship Sub-TLV The FGU Client Sub-Slot Bitmap Relationship sub-TLV indicates the relationship between the occupied timeslots(expressed by bitmap) and corresponding FGU Client. This sub-TLV is an optional sub-TLV MAY be included in the Link Descriptors TLV. More than one instance of this sub-TLV can be included in the Link Descriptors TLV. The format of this sub-TLV is shown in Figure 4. Han, et al. Expires 5 May 2027 [Page 7] Internet-Draft draft-han-pce-fgmtn-00 November 2026 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FGU Client Port index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FGU Client number | Reserved | Start Position| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / Forward fg Channel index (22 Bytes) / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / Backward fg Channel index (22 Bytes) / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / Sub-slot bitmap (variable) / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: FGU Client Sub-Slot BitMap RelationShip Sub-TLV where: Type: TBD3, needs to be allocated by IANA. Length: the length of value field, variable. FGU Client Port index: 4-byte length, the local FGU client port identifier allocated by the device itself, which is unique within a network device. The value ranges from 1 to 0xFFFFFFFF. The value 0 indicates an invalid value. FGU Client number: 2-byte length, the FGU client identifier negotiated by the source and destination device, which is unique within a MTN client. The value ranges from 1 to 1022. The value 0 indicates not used, and the value 1023 is reserved. Start Position: 1-byte length, the start position of the timeslots occupied by the current FGU client. It is expressed in bytes. The timeslots are arranged in the order of timeslots 0 to 959. The value of this field ranges from 0 to 119. Forward fg Channel index: 22-byte length, forward fg channel identifier. It is a unique channel ID on the entire network, which is identified by the combination of the source device's MPLS LSR ID Han, et al. Expires 5 May 2027 [Page 8] Internet-Draft draft-han-pce-fgmtn-00 November 2026 (16 bytes, device IPv4 or IPv6 address), fg Channel ID (4 bytes, allocated by the management and control system, unique within the source node), and LSP ID (2 bytes, allocated by the management and control system, used to distinguish the original path from the rerouting path). Backward fg Channel index: 22-byte length, backward fg channel identifier. It is a unique channel ID on the entire network, which is identified by the combination of the following information: MPLS LSR ID (16 bytes, IPv4 or IPv6 address of the device) of the reverse source, fg Channel ID (4 bytes, allocated by the management and control system, unique within the source node), and LSP ID (2 bytes, allocated by management and control system, used to distinguish the original path from the rerouting path). Sub-slot bitmap: variable, indicates the occupation state of all the sub-slots of the FGU. It starts from the start position. If the last bits are all zeros, the padding can be omitted. 5.2.4. FGU Client Sub-Slot Relationship Sub-TLV The FGU Client Sub-Slot Bitmap Relationship sub-TLV indicates the relationship between the occupied timeslots(expressed by enumeration value) and FGU Client. This sub-TLV is an optional sub-TLV MAY be included in the Link Descriptors TLV. More than one instance of this sub-TLV can be included in the Link Descriptors TLV. The format of this sub-TLV is shown in Figure 5: Han, et al. Expires 5 May 2027 [Page 9] Internet-Draft draft-han-pce-fgmtn-00 November 2026 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FGU Client index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FGU Client number | Reserved | Start Position| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / Forward fg Channel index (22 Bytes) / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / Backward fg Channel index (22 Bytes) / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / Sub-Slot IDs (variable) / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: FGU Client Sub-Slot Relationship Sub-TLV where: Type: TBD4, needs to be allocated by IANA. Length: the length of value field, variable. FGU Client Port index: 4-byte length, the local FGU client port identifier allocated by the device itself, which is unique within a network device. The value ranges from 1 to 0xFFFFFFFF. The value 0 indicates an invalid value. FGU Client number: 2-byte length, the FGU client identifier negotiated by the source and destination device, which is unique within a MTN client. The value ranges from 1 to 1022. The value 0 indicates not used, and the value 1023 is reserved. Start Position: 1-byte length, the start position of the timeslots occupied by the current FGU client. It is expressed in bytes. The timeslots are arranged in the order of timeslots 0 to 959. The value of this field ranges from 0 to 119. Forward fg Channel index: 22-byte length, forward fg channel identifier. It is a unique channel ID on the entire network, which is identified by the combination of the source device's MPLS LSR ID Han, et al. Expires 5 May 2027 [Page 10] Internet-Draft draft-han-pce-fgmtn-00 November 2026 (16 bytes, device IPv4 or IPv6 address), fg Channel ID (4 bytes, allocated by the management and control system, unique within the source node), and LSP ID (2 bytes, allocated by the management and control system, used to distinguish the original path from the rerouting path). Backward fg Channel index: 22-byte length, backward fg channel identifier. It is a unique channel ID on the entire network, which is identified by the combination of the following information: MPLS LSR ID (16 bytes, IPv4 or IPv6 address of the device) of the reverse source, fg Channel ID (4 bytes, allocated by the management and control system, unique within the source node), and LSP ID (2 bytes, allocated by management and control system, used to distinguish the original path from the rerouting path). Sub-slot IDs: Variable length, indicates the enumerated value of the sub-slots occupied by the current FGU client. Each sub-slot ID is represented by 2 bytes. The number of sub-slot ID ranges from 0 to 959. 6. Protocol Extensions for Path Setup 6.1. The OPEN Object 6.1.1. The Path Setup Type Capability TLV [RFC8408] defines the PATH-SETUP-TYPE-CAPABILITY TLV for use in the OPEN object. The fgMTN paths computed by a PCE can be represented in an ERO object as an ordered sets of adjacency identity. 6.1.2. The fgMTN PCE Capability Sub-TLV This document defines a new Path Setup Type (PST) for fgMTNP, as follows: PST = TBD5: Traffic-engineering path is set up for fgMTN LSP. A PCEP speaker SHOULD indicate its support of the function described in this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN object with this new PT included in the PST list. 6.2. The RP/SRP Object To set up an fgMTN LSP, the RP or SRP object MUST include the PATH- SETUP-TYPE TLV, specified in [RFC8408], with the PST set to TBD5. Han, et al. Expires 5 May 2027 [Page 11] Internet-Draft draft-han-pce-fgmtn-00 November 2026 6.3. The LSP Object The LSP object specified in [RFC8231] can be used for fgMTN LSP. The 12bits Flags are reused for fgMTN. IPV4-LSP-IDENTIFIER TLV and IPV6- LSP-IDENTIFIER TLV describes the fgMTN channel which includes the IPv4 or IPv6 Tunnel Sender Address indicating the ingress node of fgMTN channel, Extended Tunnel ID which is unique in the source node, and the IPv4 or IPv6 Tunnel Endpoint Address indicating the egree node of fgMTN channel. These three tuple identifies an fgMTN channel. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=18 | Length=16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | fgMTNP IPv4 Tunnel Ingress Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP ID | Tunnel ID=0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | fgMTNP Extended Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | fgMTNP IPv4 Tunnel Egress Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: IPV4-LSP-IDENTIFIERS TLV Format As shown in Figure 6, this is an example format of IPV4-LSP- IDENTIFIERS TLV for fgMTNP. The IPV6-LSP-IDENTIFIERS TLV format follows the IPV6-LSP-IDENTIFIERS TLV format of Figure 13 in [RFC8231] 6.4. The ERO Object During the path calculation of each fgMTN path, the server layer port for each fgMTN is clearly defined. The port of MTN layer can be configured either statically through network management or via other approach. Regardless of the configuration method deployed, the server layer port supporting fine granalarity mode is unique and unambiguous within a node. In PCEP messages, fgMTN LSP route information is carried in the Explicit Route Object (ERO), which consists of a strictly sequence of subobjects. The fgMTNP paths computed by a PCE is represented in an ERO as an strict ordered set of ports id, without IP addresses. The "fgMTN-ERO subobject" that is capable of carrying an unique adjacency id. Han, et al. Expires 5 May 2027 [Page 12] Internet-Draft draft-han-pce-fgmtn-00 November 2026 6.4.1. FgMTN-ERO Subobject The ERO content is defined in [RFC5440] to support the fgMTN LSPs. Each Label ERO subobject is defined in [RFC3473] represents each hop of MTN client id for the fgMTN LSP. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type | Length |U| Reserved | C-Type=0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: fgMTN-ERO Subobject Format The L bit flag is 0 because fgMTNP is a strict path. The C-Type is not used. The identifier is a unique identifier for server layer port (5Gbps MTN port or 10GE interface) that is enabled in fine grain mode. 6.5. The BANDWIDTH Object The BANDWIDTH object defined in [RFC8779] can be applied to fgMTN. The Bw Spec Type field determines which type of bandwidth is represented by the object. This document defines a new Bw Spec Type for MTN-TDM: Bw Spec Type = TBD6: MTN-TDM In the BANDWIDTH object body, the 32bits "Generalized bandwidth" field can be reused to describe the Bw Spec. The format of the Bw Spec is shown as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type | Reserved | NCS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: Bw Spec Format Signal Type : 8 bits This value indicates the fgMTN LSP. NCS (Number of Calendar Slots): 16 bits This field indicates the number of fgCSs of this fgMTNP. Han, et al. Expires 5 May 2027 [Page 13] Internet-Draft draft-han-pce-fgmtn-00 November 2026 7. Deployment Considerations 8. Security Considerations 9. IANA Considerations This document requests IANA to make the following allocations from this sub-registry. +=======+============================+===============+ | Value | Description | Reference | +=======+============================+===============+ | TBD1 | Parent NRP ID Sub-TLV | This document | +-------+----------------------------+---------------+ | TBD2 | Sub-Slot Bitmap Sub-TLV | This document | +-------+----------------------------+---------------+ | TBD3 | FGU Client Sub-Slot Bitmap | This document | | | Relationship Sub-TLV | | +-------+----------------------------+---------------+ | TBD4 | FGU Client Sub-Slot | This document | | | Relationship Sub-TLV | | +-------+----------------------------+---------------+ | TBD5 | Path Setup Type (PST) for | This document | | | fgMTNP | | +-------+----------------------------+---------------+ | TBD6 | Bw Spec Type for MTN-TDM | This document | +-------+----------------------------+---------------+ Table 1: IANA Considerations 10. Acknowledgments TBD. 11. Normative References [ITU-T_G.8312.20] ITU-T, "ITU-T G.8312.20:Overview of fine grain MTN; 01/2024", https://www.itu.int/rec/T-REC-G.8312.20, January 2024. [ITU-T_G.8310] ITU-T, "ITU-T G.8310: Architecture of the metro transport network; 01/2024", https://www.itu.int/rec/T-REC-G.8310, March 2025. Han, et al. Expires 5 May 2027 [Page 14] Internet-Draft draft-han-pce-fgmtn-00 November 2026 [ITU-T_G.8312] ITU-T, "ITU-T G.8312:Interfaces for metro transport networks; 01/2024", https://www.itu.int/rec/T-REC-G.8312, January 2024. [ITU-T_G.8321] ITU-T, "ITU-T G.8321:Characteristics of metro transport network equipment functional blocks;", https://www.itu.int/rec/T-REC-G.8321. [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", RFC 8231, DOI 10.17487/RFC8231, September 2017, . [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, . [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. Hardwick, "Conveying Path Setup Type in PCE Communication Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, July 2018, . [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) Extensions", RFC 3473, DOI 10.17487/RFC3473, February 2003, . Han, et al. Expires 5 May 2027 [Page 15] Internet-Draft draft-han-pce-fgmtn-00 November 2026 [RFC8779] Margaria, C., Ed., Gonzalez de Dios, O., Ed., and F. Zhang, Ed., "Path Computation Element Communication Protocol (PCEP) Extensions for GMPLS", RFC 8779, DOI 10.17487/RFC8779, July 2020, . [RFC9543] Farrel, A., Ed., Drake, J., Ed., Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J. Tantsura, "A Framework for Network Slices in Networks Built from IETF Technologies", RFC 9543, DOI 10.17487/RFC9543, March 2024, . [I-D.ietf-pce-pcep-ls] Dhody, D., Peng, S., Ceccarelli, D., Wang, A., and G. S. Mishra, "PCEP extensions for Distribution of Link-State and TE Information", Work in Progress, Internet-Draft, draft-ietf-pce-pcep-ls-07, 4 July 2026, . [I-D.han-pce-path-computation-fg-transport] Han, L., Zheng, H., Wang, M., Zhao, Y., Huang, H., and L. Zhang, "Path Computation and Control Extention Requirements for Fine-Granularity Transport Network", Work in Progress, Internet-Draft, draft-han-pce-path- computation-fg-transport-02, 1 March 2026, . Authors' Addresses Liuyan Han China Mobile No.32 Xuanwumen west street Beijing 100053 China Email: hanliuyan@chinamobile.com Haibin Huang China Mobile No.32 Xuanwumen west street Beijing 100053 China Email: huanghaibin@chinamobile.com Han, et al. Expires 5 May 2027 [Page 16] Internet-Draft draft-han-pce-fgmtn-00 November 2026 Minxue Wang China Mobile No.32 Xuanwumen west street Beijing 100053 China Email: wangminxue@chinamobile.com Li Zhang Huawei Beiqing Road Beijing China Email: zhangli344@huawei.com Jin Zhou ZTE Corporation Shenzhen China Email: zhou.jin6@zte.com.cn Han, et al. Expires 5 May 2027 [Page 17]