]> BUPT

No.10,Xitucheng Road,Haidian District Beijing 100876 P.R.China +8613811761857 yonglizhao@bupt.edu.cn http://www.bupt.edu.cn/

BUPT

No.10,Xitucheng Road,Haidian District Beijing 100876 P.R.China +8613811731723 xiaosongyu@bupt.edu.cn http://www.bupt.edu.cn/

BUPT

No.10,Xitucheng Road,Haidian District Beijing 100876 P.R.China +8613911060930 lgr24@bupt.edu.cn http://www.bupt.edu.cn/

ZTE Corporation

No.16,Huayuan Road,Haidian District Beijing 100191 P.R.China +861061198108 wang.jiayu1@zte.com.cn http://www.zte.com.cn/

ZTE Corporation

No.16,Huayuan Road,Haidian District Beijing 100191 P.R.China +8615901011821 lin.xuefeng@zte.com.cn http://www.zte.com.cn/

Routing Network Working Group P2MP Flexi RSA GMPLS Multicasting over WDM optical networks has enabled many popular Point-to-Multipoint (P2MP) applications, such as video conference, interactive distance learning, replicated database, distributed computing, and so on. However, the low-rate multicasting traffic demands cannot make full use of the capacity of the entire wavelength . Flexi-grid network overcomes the fixed grid constraint of Wavelength Switched Optical Network (WSON) by flexible spectrum allocation based on the demand of the client request. It is an effective solution to address the problem of inefficient spectrum utilization. Therefore, it is essential to exploit multicasting over flexi-grid networks. This document covers the requirements for supporting P2MP over flexi-grid infrastructure. Specifically, the scope of requirements listed in this document covers the functionality that should be supported by the control plane.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

Multicasting over WDM optical networks has enabled many popular Point-to-Multipoint (P2MP) applications, such as video conference, interactive distance learning, replicated database, distributed computing, and so on. RFC [4461] presents a set of requirements for the establishment and maintenance of P2MP Traffic-Engineered (TE) Label Switched Paths (LSPs). The requirements not only apply to packet-switched networks under the control of MPLS protocols, but also encompass the requirements of Layer Two Switching (L2SC), Time Division Multiplexing (TDM), lambda, and port switching networks managed by GMPLS protocols. RFC [4875] describes extensions to Resource reSerVation Protocol - Traffic Engineering (RSVP-TE) for the setup of Traffic Engineered (TE) based P2MP Label Switched Paths (LSPs) in MPLS and GMPLS networks. However, the low-rate multicasting traffic demands cannot make full use of the capacity of the entire wavelength . Therefore in order to increase the network spectrum efficiency, it is essential to exploit multicasting over flexi-grid networks. Flexible grid technology is defined in the latest version of ITU-T G.694.1, which is also a dense wavelength division multiplexing and different from traditional fixed grid technology. Compared to fixed grids, flexible grid has a smaller and agile granularity for the central frequencies and the slot width may range from 12.5GHz to hundreds of GHz. The flexible grid technology allows mixed bit rates or mixed modulation formats transmission system to allocate frequency slots with different slot widths. So that they can be optimized for the bandwidth requirements of a particular bit rate and modulation scheme of the individual channels. In the dynamic flexi-grid networks, not only an appropriate route is necessary to be selected for the client LSP, but also the appropriate width of spectrum slot is needed for the client LSP. The spectrum slot here is made up of several consecutive spectrum slots from end-to-end, and is determined by the data rate and the modulation level. There are several drafts addressing the extensions of GMPLS protocols to support the flexi-grid networks. [draft-farrkingel-ccamp-flexigrid-lambda-label] updates the definition of GMPLS lambda labels to support the flexi-grid, and [draft-hussain-ccamp-super-channel-label] defines a super-channel label as a Super-Channel Identifier and an associated list of 12.5 GHz slices representing the optical spectrum of the super-channel. This label format can be used in GMPLS signaling and routing protocol to establish super-channel based optical label switched paths. In addition, [draft-wang-ccamp-gmpls-glexigrid-framework] provides a framework for applying Generalized Multi-Protocol Label Switching (GMPLS) and the Path Computation Element (PCE) architecture to control the flexible grid network base on the Wavelength Switched Optical Networks (WSONs), and [draft-ogrcetal-ccamp-flexi- grid-fwk-00] defines a framework and the associated control plane requirements for the GMPLS based control of flexi-grid DWDM networks. This document covers the requirements for supporting P2MP over flexi-grid infrastructure. First, section 3 provides some definitions including background terminology and acronym list. Then, section 4 goes over a set of requirements that must be considered when defining the protocol extensions to support P2MP in flexi-grid networks. Next, the framework of extensions for supporting P2MP in flexi-grid networks is presented in Section 5.

Flexi-grid: a new technology allows mixed bit rates or mixed modulation formats transmission system to allocate frequency slots with different slot widths. So they can be optimized for the bandwidth requirements of a particular bit rate and modulation scheme of the individual channels. Frequency Slot: a frequency slot is defined by its nominal central frequency and its slot width. It denotes the frequency range allocated to a channel, but unavailable for any other channels. Spectral Slice: the minimum granularity of a frequency slot (e.g. 12.5 GHz). Slot Width: the full width of a frequency slot in a flexible grid. Frequency Range: a frequency range is defined as the portion of frequency spectrum included between a lowest and a highest frequency. P2MP tree: the ordered set of LSRs and TE links that comprise the path of a P2MP TE LSP from its ingress LSR to all of its egress LSRs. Ingress LSR: the LSR that is responsible for initiating the signaling messages that set up the P2MP TE LSP. Egress LSR: one of potential many destinations of the P2MP TE LSP. Egress LSRs may also be referred to as leaf nodes or leaves. Branch LSR: an LSR that has more than one directly connected downstream LSRs. Source: the sender of traffic that is carried on a P2MP service supported by a P2MP LSP. The sender is not necessarily the ingress LSR of the P2MP LSP. Receiver: a recipient of traffic carried on a P2MP service supported by a P2MP LSP. A receiver is not necessarily an egress LSR of the P2MP LSP. Zero, one, or more receivers may receiver data through a given egress LSR.

GMPLS: Generalized Multi-Protocol Label Switching P2MP: Point-to-Multipoint LSP: Label Switched Paths LSR: Label Switched Router WXC: Wavelength Cross Connect WSS: Wavelength Selective Switch

The broadcast-and-select mechanism at the WXC node by employing bandwidth-variable WSS is suitable for multicasting traffic. This document covers the high level requirements for the support P2MP over flexi-grid infrastructure. [Requirement 1 ] Flexible Bandwidth of P2MP LSP The protocol should allow the P2MP LSP in the flexi-grid network to be of different sizes/bandwidths. The number of Spectral Slices and the granularity of each slice could be flexible. [Requirement 2 ] Flexible mapping of P2MP LSP This means the P2MP LSP should be allowed to be mapped to any Frequency Range in the ITU grid. Note that the Frequency Range allocation of P2MP LSP on the ITU-Grid shall confirm to [G.FLEXGRID]. [Requirement 3 ] Consecutive Frequency Range of P2MP LSP This means that the spectral resources allocated to P2MP LSP must be consecutive. [Requirement 4 ] Flexibly choose the modulation format for P2MP LSP Each channel mapped to the flexi-grid system shall have the capability to support different modulation formats, e.g. BPSK, QPSK, 8PSK, 16QAM, 64QAM, and so on. [Requirement 5 ] Bandwidth Resizing of P2MP LSP Since the bandwidth of P2MP LSP depends on the modulation format of the signal, the protocol shall allow bandwidth resizing if the modulation format of optical signal changes. [Requirement 6 ] Bandwidth Resizing for subset of P2MP LSP Moreover, the extended protocol should support the functionality which allows a subset of the P2MP LSP bandwidth resizing, e.g., changing the modulation format of optical signal.

In the current optical networks, a single given modulation format, such as BPSK, QPSK, and most recently n-QAM is employed. In P2MP scenario, there may be more than one destination LSR, and each destination LSR has a different path length. The design of the system ensures that the longest path can be transmitted with a sufficient quality of signal. Therefore, at the transmitter of all destination LSRs have the highest modulation format and occupy the largest spectral width regardless of the different optical path length. Thus, some paths shorter than the others result in overspending of network resources. However, in the flexi-grid networks, the modulation format can be elastically selected based on the length of the LSP. The different assignment of spectral bandwidth of P2MP LSP for each destination LSR (including Egress LSR and branch LSR) is based on the different modulation format by varying the number of bits per symbol, for example QPSK (2 bits per symbol) for one destination LSR and 16QAM (4 bits per symbol) for another. Note that the increasing of modulation levels lies in the narrower spacing of symbols of signal constellation, resulting in receiver sensitivity deterioration. Here is an example for P2MP in flexi-grid network as shown in figure 1.

There is a P2MP request from Node A to Nodes F and H, and suppose its bit rate is 60Gbit/s. When we construct a P2MP tree like figure 1, the hops from A to F is 5, and from A to H is 6. Suppose a LSP which has more than 5 hops must take QPSK modulation level for reducing the nonlinear transmission impairments. then, in order to ensure that the worst case optical path in this P2MP request, usually we take QPSK as the modulate level. Here, 60 GHz spectral resources are needed. Since the minimum granularity of a Frequency Slot is 12.5 GHz, a frequency slot consisting 5 spectral slices with the Slot Width being 62.5 GHz are used. Note that these 5 frequency slices must be consecutive in the spectral domain. In the first scenario, link A-B has not enough spectral resources, e.g. only has 4 spectral slices being consecutive. So we could change the modulate level if we want to route this P2MP LSP successfully. Here, we change the modulation level from QPSK to 16QAM. That's mean only 3 spectral slices are needed here. In the second scenario, link A-B has not enough spectral resources, e.g. only has 4 spectral slices being consecutive. Under the assumption that O/E/O converting is permitted at the middle nodes, we could cut this P2MP LSPs into three parts, one from A to D, one from D to F, and the third one from D to H. For the LSP from A to D, we take 16QAM as its modulation level; for the LSP from D to F, we take 64 QAM as the modulation level; and for the LSP from D to H, we take 16 QAM as the modulation level. That's means that only 3, 2, 3 spectral slices are needed here respectively.

Mixed bitrate transmission systems can allocate their channels with different spectral bandwidths so that the channels can be optimized for the bandwidth requirements of the particular bit rate and modulation format of the individual channels. A flexible grid network selects its data channels as arbitrarily assigned spectral slices. It is being developed within the ITU-T Study Group 15 to allow the selection and switching of individual lambdas chosen flexibly from a detailed, fine granularity grid of wavelength with arbitrary spectral bandwidth [G.FLEXIGRID]. Our analysis has determined that there are significant problems with existing protocols for supporting P2MP in flexi-grid networks. The problems include RSVP, OSPF, PCE, PCEP and so on. So additional extensions may be needed because of new features introduced by flexible grid. This section addresses the framework extensions of the requirements.

RFC [4875] describes extensions to Resource reSerVation Protocol-Traffic Engineering (RSVP-TE) for the setup of Traffic Engineered (TE) P2MP Label Switched Paths (LSPs) in MPLS and GMPLS networks. This section outlines RSVP-TE extensions for the support of P2MP in flexi-grid networks. The ingress and egress nodes of the LSP must be capable of indicating whether the Link-State and the modulation format of the LSP should be collected during the signaling procedure of setting up the LSP, and the endpoints of the LSP may collect the Link-State and modulation format information and use it for configuration purposes. When the Link-State and the modulation format of a LSP changes, e.g., if the administrator changes the route of a LSP, the endpoints of the LSP need to be capable of updating the Link-State information and the modulation format information of the LSA. During a new P2MP LSP establishment, each node along the path allocates the required number of spectral slices and also learns the other optical parameters.

RFC [3630] describes extensions to the OSPF protocol version 2 to support intra-area traffic engineering, using Opaque Link State Advertisements. This section outlines OSPF-TE extensions for the support of P2MP in flexi-grid networks. As for stateful PCE, the PCE has a TED plus an LSP-DB which are the active LSPs state (e.g. the route and the slot used by a working LSP). So no extensions needed here; As for stateless PCE, the TED may be filled through OSPF-TE, thus OSPF-TE extensions may be required to carry used frequency slot information, such as the associated bit-rate and modulation format.

The Path Computation Element (PCE) defined in [RFC4655] provides path computation functions in support of traffic engineering in GMPLS networks. It is an entity that is capable of computing a network path or route based on a network graph and of applying computational constraints. [RFC4655] also defines various deployment models that place PCEs differently within the network. The PCEs may be collocated with the Label Switching Routers (LSRs), may be part of the management system that requests the LSPs to be established, or may be positioned as one or more computation servers within the network. This part examines the applicability of PCE to path computation for P2MP TE LSPs in Flexi-grid networks. As for stateful PCE, PCE has a TED plus an LSP-DB which are the active LSPs state; and as for stateless PCE, PCE exploits a TED which includes per-link information regarding the usage of the optical spectrum resource. In order to identify the information of the route, the TED plus the LSP-DB exploited by the PCE should be extended to store the following information: Bit rate of any working LSP in the network. Modulation format of any working LSP in the network. Allocated central frequency and slot width for any active LSP in the network.

RFC [5862] complements the general requirements and presents a detailed set of PCC-PCE communication protocol requirements for P2MP MPLS/GMPLS traffic engineering. This part examines the applicability of PCEP to path computation for P2MP TE LSPs in Flexi-grid networks. Similar with PCE, an extension may be needed in the PCEP Path Computation Reply message to inform the ingress node about the following information along the route: Bit rate of any working LSP in the network. Modulation format of any working LSP in the network. Allocated central frequency and slot width for any active LSP in the network.

TBD.

TBD.

Harvard University Juniper Networks Juniper Networks Procket Networks NTT Old Dog Consulting Cisco Systems, Inc. ATT Juniper Networks Alcatel NTT NTT Old Dog Consulting ITU-T Old Dog Consulting Old Dog Consulting Old Dog Consulting ZTE CTTC Infinera Infinera Infinera Infinera Verizon Communications Verizon Communications Verizon Communications ZTE ZTE Telefinica CTTC Huawei ZTE Ericsson Infinera

The RFC text was produced using Marshall Rose's xml2rfc tool.