Path Computation Element Communication Protocol (PCEP) Extension for Fine Granularity Metro Transport Network (fgMTN) Path Setup

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 , the fgMTN layer architecture defined in , fgMTN interface defined in , fgMTN equipment defined in . 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 when, and only when, they appear in all capitals, as shown here.

Terminology fgCS:

Fine Grain Calendar Slot

fgMTNP:

Fine Grainularity Metro Transport Network Path Layer

MTN:

Metro Transport Network

As described in , 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. 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. 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. 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.

As shown in Figure 1, the PCE communication protocol can be extended to meet the communication between PCE and PCC according to . 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 , , , and any other applicable PCEP specifications.

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 , with the PST set to TBD1.

The LSP object specified in 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.

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

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 to support the fgMTN LSPs. Each Label ERO subobject is defined in represents each hop of MTN client id for the fgMTN LSP.

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 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:

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.

This document requests IANA to make the following allocations from this sub-registry. IANA Considerations

Value	Description	Reference
TBD1	Path Setup Type (PST) for fgMTNP	This document
TBD2	Bw Spec Type for MTN-TDM	This document

TBD.