Network Working Group YL. Zhao Internet-Draft XS. Yu Intended status: Informational J. Zhang Expires: July 13, 2013 BUPT JY. Wang XF. Lin ZTE Corporation January 9, 2013 Requirements for Supporting P2MP in Flexi-Grid Networks draft-zhaoyl-ccamp-p2mp-requirement-flexi-grid-01 Abstract 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, on the one hand, the low-rate multicasting traffic demands cannot make full use of the capacity of the entire wavelength, and on the other hand, new services such as data center migration and cloud applications need higher transmission rates and higher spectrum efficiency. Flexi-grid network is an effective solution to address the problem of transmission rate and spectrum utilization. It overcomes the fixed grid constraint of Wavelength Swithched Optical Network (WSON) by using advanced technologies such as coherent detection and Bandwidth Variable- Wavelength Selective Switches (BV-WSS). 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. 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 http://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." Zhao, et al. Expires July 13, 2013 [Page 1] Internet-Draft P2MP in Flexi-Grid Networks January 2013 This Internet-Draft will expire on July 13, 2013. Copyright Notice Copyright (c) 2013 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 (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Zhao, et al. Expires July 13, 2013 [Page 2] Internet-Draft P2MP in Flexi-Grid Networks January 2013 Table of Contents 1. Conventions Used in This Document . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Terminologies . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Requirements for Supporting P2MP in Flexi-grid Networks . . . 6 4.1. Requirements description . . . . . . . . . . . . . . . . . 6 4.2. Examples for Requirements . . . . . . . . . . . . . . . . 7 5. Framework of Protocol Extensions . . . . . . . . . . . . . . . 9 5.1. Signaling . . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.3. PCE . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.4. PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Zhao, et al. Expires July 13, 2013 [Page 3] Internet-Draft P2MP in Flexi-Grid Networks January 2013 1. Conventions Used in This Document 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 [RFC2119]. 2. Introduction 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. Furthermore, new services such as data center migration and cloud applications need higher transmission rates and higher spectrum efficiency. Flexi-grid network discussed recently is an effective solution to address the problem of transmission rate and spectrum utilization. It overcomes the fixed grid constraint of Wavelength Swithched Optical Network (WSON) by using advanced technologies such as coherent detection and Bandwidth Variable- Wavelength Selective Switches (BV-WSS). It's essential to extend the protocols to exploit P2MP applications over such 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. Zhao, et al. Expires July 13, 2013 [Page 4] Internet-Draft P2MP in Flexi-Grid Networks January 2013 There are several drafts addressing the extensions of GMPLS protocols to support the flexi-grid networks. [draft-ogrcetal-ccamp-flexi-grid-fwk-01] defines a framework and the associated control plane requirements for the GMPLS based control of flexi-grid DWDM networks, and [draft-farrkingel-ccamp-flexigrid-lambda-label-04] defines a new GMPLS lambda label format to support flexi-grid. Besides, [draft-dhillon-ccamp-super-channel-ospfte-ext-04] specifies the extension to TELINK LSA of OSPF routing protocol in support of GMPLS for flex-grid networks, and [draft-hussain-ccamp-super-channel-label-04] 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 (LSPs). 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 should 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. 3. Definitions 3.1. Terminologies 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 Zhao, et al. Expires July 13, 2013 [Page 5] Internet-Draft P2MP in Flexi-Grid Networks January 2013 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. 3.2. Acronyms 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 4. Requirements for Supporting P2MP in Flexi-grid Networks 4.1. Requirements description 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 Zhao, et al. Expires July 13, 2013 [Page 6] Internet-Draft P2MP in Flexi-Grid Networks January 2013 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. 4.2. Examples for Requirements 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 Zhao, et al. Expires July 13, 2013 [Page 7] Internet-Draft P2MP in Flexi-Grid Networks January 2013 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. Egress LSR +++++ - + F + Ingress Branch - +++++ LSR LSR LSR LSR LSR - Receiver +++++ +++++ +++++ +++++ +++++ - + A + --- + B + --- + C + --- + D + --- + E + - +++++ +++++ +++++ +++++ +++++ - Source - LSR Egress LSR - +++++ +++++ - + G + --- + H + +++++ +++++ Receiver Figure 1 An example for bandwidth resizing of P2MP LSP 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 Zhao, et al. Expires July 13, 2013 [Page 8] Internet-Draft P2MP in Flexi-Grid Networks January 2013 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. 5. Framework of Protocol Extensions 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. 5.1. Signaling 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. 5.2. Routing RFC [3630] describes extensions to the OSPF protocol version 2 to support intra-area traffic engineering, using Opaque Link State Zhao, et al. Expires July 13, 2013 [Page 9] Internet-Draft P2MP in Flexi-Grid Networks January 2013 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. 5.3. PCE 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: o Bit rate of any working LSP in the network. o Modulation format of any working LSP in the network. o Allocated central frequency and slot width for any active LSP in the network. 5.4. PCEP 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: Zhao, et al. Expires July 13, 2013 [Page 10] Internet-Draft P2MP in Flexi-Grid Networks January 2013 o Bit rate of any working LSP in the network. o Modulation format of any working LSP in the network. o Allocated central frequency and slot width for any active LSP in the network. 6. Security Considerations TBD. 7. IANA Considerations TBD. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFC's to Indicate Requirement Levels", RFC 2119, March 1997. [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. [RFC4461] Yasukawa, S., "Signaling Requirements for Point-to- Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)", RFC 4461, April 2006. [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007. [RFC5862] Yasukawa, S. and A. Farrel, "Path Computation Clients (PCC) "C Path Computation Element (PCE) Requirements for Point-to-Multipoint MPLS-TE", RFC 5862, June 2010. Zhao, et al. Expires July 13, 2013 [Page 11] Internet-Draft P2MP in Flexi-Grid Networks January 2013 8.2. Informative References [1] ITU-T, "Draft revised G.694.1 version 1.6", December 2011. [2] Gonzalez de Dios, O., Casellas, R., Zhang, F., Fu, X., Ceccarelli, D., and I. Hussain, "draft-ogrcetal-ccamp-flexi-grid-fwk-01", October 2012. [3] King, D., Farrel, A., Li, Y., Zhang, F., and R. Casellas, "draft-farrkingel-ccamp-flexigrid-lambda-label-04", October 2012. [4] Dhillon, A., Hussain, I., Rao, R., and M. Sosa, "draft-dhillon-ccamp-super-channel-ospfte-ext-04", November 2012. [5] Hussain, I., Dhillon, A., Pan, Z., Sosa, M., Basch, B., Liu, S., and Andrew G. Malis, "draft-hussain-ccamp-super-channel-label-04", September 2012 . Appendix A. Acknowledgments The RFC text was produced using Marshall Rose's xml2rfc tool. Authors' Addresses Yongli Zhao BUPT No.10,Xitucheng Road,Haidian District Beijing 100876 P.R.China Phone: +8613811761857 Email: yonglizhao@bupt.edu.cn URI: http://www.bupt.edu.cn/ Zhao, et al. Expires July 13, 2013 [Page 12] Internet-Draft P2MP in Flexi-Grid Networks January 2013 Xiaosong Yu BUPT No.10,Xitucheng Road,Haidian District Beijing 100876 P.R.China Phone: +8613811731723 Email: xiaosongyu@bupt.edu.cn URI: http://www.bupt.edu.cn/ Jie Zhang BUPT No.10,Xitucheng Road,Haidian District Beijing 100876 P.R.China Phone: +8613911060930 Email: lgr24@bupt.edu.cn URI: http://www.bupt.edu.cn/ Jiayu Wang ZTE Corporation No.16,Huayuan Road,Haidian District Beijing 100191 P.R.China Phone: +861061198108 Email: wang.jiayu1@zte.com.cn URI: http://www.zte.com.cn/ Xuefeng Lin ZTE Corporation No.16,Huayuan Road,Haidian District Beijing 100191 P.R.China Phone: +8615901011821 Email: lin.xuefeng@zte.com.cn URI: http://www.zte.com.cn/ Zhao, et al. Expires July 13, 2013 [Page 13]