Path Computation Element Communication Protocol (PCEP) Extension for Fine Granularity Metro Transport Network (fgMTN) Path Setup
draft-han-pce-fgmtn-setup-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Liuyan Han , Haibin Huang , Minxue Wang , Jin Zhou , Li Zhang | ||
| Last updated | 2026-03-01 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-han-pce-fgmtn-setup-00
PCE Working Group L. Han
Internet-Draft H. Huang
Intended status: Standards Track M. Wang
Expires: 2 September 2026 CMCC
J. Zhou
ZTE
L. Zhang
Huawei
1 March 2026
Path Computation Element Communication Protocol (PCEP) Extension for
Fine Granularity Metro Transport Network (fgMTN) Path Setup
draft-han-pce-fgmtn-setup-00
Abstract
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.
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 2 September 2026.
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 2 September 2026 [Page 1]
Internet-Draft draft-han-pce-fgmtn-setup-00 March 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 . . . . . . . . 3
5. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 4
5.1. The OPEN Object . . . . . . . . . . . . . . . . . . . . . 4
5.1.1. The Path Setup Type Capability TLV . . . . . . . . . 4
5.1.2. The fgMTN PCE Capability Sub-TLV . . . . . . . . . . 5
5.2. The RP/SRP Object . . . . . . . . . . . . . . . . . . . . 5
5.3. The LSP Object . . . . . . . . . . . . . . . . . . . . . 5
5.4. The ERO Object . . . . . . . . . . . . . . . . . . . . . 6
5.4.1. FgMTN-ERO Subobject . . . . . . . . . . . . . . . . . 6
5.5. The BANDWIDTH Object . . . . . . . . . . . . . . . . . . 6
6. Deployment Considerations . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
10. Normative References . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
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.
Han, et al. Expires 2 September 2026 [Page 2]
Internet-Draft draft-han-pce-fgmtn-setup-00 March 2026
This document specifies a set of extensions to carry the fgMTNP path
information in PCEP message.
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
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 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.
Han, et al. Expires 2 September 2026 [Page 3]
Internet-Draft draft-han-pce-fgmtn-setup-00 March 2026
+------------------------------+
| PCE |
+------------------------------+
/ \
| |
| |
+-+-+ +--+ +--+ +--+ +-+-+
----|PE1+----+P1+----+P2+-----+P3+----+PE2+----
+-+-+ +--+ +--+ +--+ +-+-+
| |
+-----------fgMTNP channel--------+
Figure 1: Scenario of 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.
5. Object Formats
5.1. The OPEN Object
5.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 ENO as an ordered sets of adjacency identity.
Han, et al. Expires 2 September 2026 [Page 4]
Internet-Draft draft-han-pce-fgmtn-setup-00 March 2026
5.1.2. The fgMTN PCE Capability Sub-TLV
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.
5.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 TBD1.
5.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 2: IPV4-LSP-IDENTIFIERS TLV Format
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]
Han, et al. Expires 2 September 2026 [Page 5]
Internet-Draft draft-han-pce-fgmtn-setup-00 March 2026
5.4. The ERO Object
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.
5.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 3: 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.
5.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 = TBD2: MTN-TDM
Han, et al. Expires 2 September 2026 [Page 6]
Internet-Draft draft-han-pce-fgmtn-setup-00 March 2026
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 4: 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.
6. Deployment Considerations
7. Security Considerations
8. IANA Considerations
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 |
+-------+----------------------------------+---------------+
Table 1: IANA Considerations
9. Acknowledgments
TBD.
10. 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.
Han, et al. Expires 2 September 2026 [Page 7]
Internet-Draft draft-han-pce-fgmtn-setup-00 March 2026
[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.
[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.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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,
<https://www.rfc-editor.org/info/rfc8231>.
[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,
<https://www.rfc-editor.org/info/rfc8281>.
Han, et al. Expires 2 September 2026 [Page 8]
Internet-Draft draft-han-pce-fgmtn-setup-00 March 2026
[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, <https://www.rfc-editor.org/info/rfc8408>.
[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, January 2003,
<https://www.rfc-editor.org/info/rfc3473>.
[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,
<https://www.rfc-editor.org/info/rfc8779>.
[I-D.han-pce-path-computation-fg-transport]
Han, L., Zheng, H., Wang, M., and Y. Zhao, "Path
Computation and Control Extention Requirements for Fine-
Granularity Transport Network", Work in Progress,
Internet-Draft, draft-han-pce-path-computation-fg-
transport-01, 4 March 2024,
<https://datatracker.ietf.org/doc/html/draft-han-pce-path-
computation-fg-transport-01>.
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 2 September 2026 [Page 9]
Internet-Draft draft-han-pce-fgmtn-setup-00 March 2026
Minxue Wang
China Mobile
No.32 Xuanwumen west street
Beijing
100053
China
Email: wangminxue@chinamobile.com
Jin Zhou
ZTE Corporation
Shenzhen
China
Email: zhou.jin6@zte.com.cn
Li Zhang
Huawei
Beiqing Road
Beijing
China
Email: zhangli344@huawei.com
Han, et al. Expires 2 September 2026 [Page 10]