| Internet-Draft | draft-han-pce-fgmtn-setup-00 | March 2026 |
| Han, et al. | Expires 2 September 2026 | [Page] |
This document focuses on the PCEP extension for G.8312 fine granularity metro transport network. It provides the PCEP considerations on the path setup requirements of PCEP extension in fgMTNP.¶
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 2 September 2026.¶
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.¶
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.¶
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 fgMTNP serves as a client of the MTN Path layer, providing sub-1G services for Ethernet MAC frames and CBR clients. 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 help to address these issues.¶
This document specifies a set of extensions to carry the fgMTNP path information in PCEP message.¶
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.¶
fgCS:¶
Fine Grain Calendar Slot¶
fgMTNP:¶
Fine Grainularity Metro Transport Network Path Layer¶
MTN:¶
Metro Transport Network¶
As described in [I-D.han-pce-path-computation-fg-transport], to address the massive fgMTN path computation issues, it's necessary to hybrid centralized control and distributed control architecture. 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 connnection 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 constratints and optimization criteria. [RFC8231] specifies PcRpt and PCUpd messages 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. All of the PCEP mechanism can be applied to path computation of fgMTNP layer network.¶
+------------------------------+
| PCE |
+------------------------------+
/ \
| |
| |
+-+-+ +--+ +--+ +--+ +-+-+
----|PE1+----+P1+----+P2+-----+P3+----+PE2+----
+-+-+ +--+ +--+ +--+ +-+-+
| |
+-----------fgMTNP channel--------+
As shown in Figure 1, the PCE communication protocol can be extended to meet the communication between PCE and PCC according to [RFC4655]. The path calculation is in a centralized way and sends path information to the PE1. At the same time, fgMTN LSP routing information 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. The topology and fgCS resource information of devices are collected and reported to PCE through traditional IGP protocols, BGP-LS, or centralized PCEP-LS.¶
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 device itself allocation may be appropriate for the fgCSs allocation.¶
The extensions specified in this document complement the existing PCEP specifications to support fgMTN paths. As such, the PCEP messages (e.g., PCReq, PCRep, PCRpt, PCUpd, PCInitiate, etc.) are formatted according to [RFC5440], [RFC8231], [RFC8281], and any other applicable PCEP specifications.¶
[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 ENO as an ordered sets of adjacency identity.¶
This document defines a new Path Setup Type (PST) for fgMTNP, as follows:¶
PST = TBD1: 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.¶
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 TBD1.¶
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
As shown in Figure 2, this is an example of IPV4-LSP-IDENTIFIERS TLV format. The IPV6-LSP-IDENTIFIERS TLV format follows the IPV6-LSP-IDENTIFIERS TLV format of Figure 13 in [RFC8231]¶
During the path calculation of each fgMTN path, the server layer port for each fgMTN is clearly defined. The 5Gbps 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 5Gbps 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.¶
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.¶
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 = TBD2: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This document requests IANA to make the following allocations from this sub-registry.¶
| Value | Description | Reference |
|---|---|---|
| TBD1 | Path Setup Type (PST) for fgMTNP | This document |
| TBD2 | Bw Spec Type for MTN-TDM | This document |
TBD.¶