RFC 7698
Framework and Requirements for GMPLS-Based Control of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks
Pages: 42
Informational
Informational
Part 3 of 3 – Pages 31 to 42
5. Control-Plane Requirements
The control of flexi-grid networks places additional requirements on the GMPLS protocols. This section summarizes those requirements for signaling and routing.5.1. Support for Media Channels
The control plane SHALL be able to support media channels, characterized by a single frequency slot. The representation of the media channel in the GMPLS control plane is the so-called "flexi-grid LSP". Since network media channels are media channels, an LSP may
also be the control-plane representation of a network media channel. Consequently, the control plane will also be able to support network media channels.5.1.1. Signaling
The signaling procedure SHALL be able to configure the nominal central frequency (n) of a flexi-grid LSP. The signaling procedure SHALL allow a flexible range of values for the frequency slot width (m) parameter. Specifically, the control plane SHALL allow setting up a media channel with frequency slot width (m) ranging from a minimum of m = 1 (12.5 GHz) to a maximum of the entire C-band (the wavelength range 1530 nm to 1565 nm, which corresponds to the amplification range of erbium-doped fiber amplifiers) with a slot width granularity of 12.5 GHz. The signaling procedure SHALL be able to configure the minimum width (m) of a flexi-grid LSP. In addition, the signaling procedure SHALL be able to configure local frequency slots. The control-plane architecture SHOULD allow for the support of the L-band (the wavelength range 1565 nm to 1625 nm) and the S-band (the wavelength range 1460 nm to 1530 nm). The signaling process SHALL be able to collect the local frequency slot assigned at each link along the path. The signaling procedures SHALL support all of the RSA architectural models (R&SA, R+SA, and R+DSA) within a single set of protocol objects, although some objects may only be applicable within one of the models.5.1.2. Routing
The routing protocol will support all functions described in [RFC4202] and extend them to a flexi-grid data plane. The routing protocol SHALL distribute sufficient information to compute paths to enable the signaling procedure to establish LSPs as described in the previous sections. This includes, at a minimum, the data described by the information model in Figure 17. The routing protocol SHALL update its advertisements of available resources and capabilities as the usage of resources in the network varies with the establishment or teardown of LSPs. These updates SHOULD be amenable to damping and thresholds as in other traffic engineering routing advertisements.
The routing protocol SHALL support all of the RSA architectural models (R&SA, R+SA, and R+DSA) without any configuration or change of behavior. Thus, the routing protocols SHALL be agnostic to the computation and signaling model that is in use.5.2. Support for Media Channel Resizing
The signaling procedures SHALL allow the resizing (growing or shrinking) of the frequency slot width of a media channel or network media channel. The resizing MAY imply resizing the local frequency slots along the path of the flexi-grid LSP. The routing protocol SHALL update its advertisements of available resources and capabilities as the usage of resources in the network varies with the resizing of LSPs. These updates SHOULD be amenable to damping and thresholds as in other traffic engineering routing advertisements.5.3. Support for Logical Associations of Multiple Media Channels
A set of media channels can be used to transport signals that have a logical association between them. The control-plane architecture SHOULD allow multiple media channels to be logically associated. The control plane SHOULD allow the co-routing of a set of media channels that are logically associated.5.4. Support for Composite Media Channels
As described in Sections 3.2.5 and 4.3, a media channel may be composed of multiple network media channels. The signaling procedures SHOULD include support for signaling a single control-plane LSP that includes information about multiple network media channels that will comprise the single compound media channel. The signaling procedures SHOULD include a mechanism to associate separately signaled control-plane LSPs so that the endpoints may correlate them into a single compound media channel. The signaling procedures MAY include a mechanism to dynamically vary the composition of a composite media channel by allowing network media channels to be added to or removed from the whole. The routing protocols MUST provide sufficient information for the computation of paths and slots for composite media channels using any of the three RSA architectural models (R&SA, R+SA, and R+DSA).
5.5. Support for Neighbor Discovery and Link Property Correlation
The control plane MAY include support for neighbor discovery such that a flexi-grid network can be constructed in a "plug-and-play" manner. Note, however, that in common operational practice, validation processes are used rather than automatic discovery. The control plane SHOULD allow the nodes at opposite ends of a link to correlate the properties that they will apply to the link. Such a correlation SHOULD include at least the identities of the nodes and the identities that they apply to the link. Other properties, such as the link characteristics described for the routing information model in Figure 17, SHOULD also be correlated. Such neighbor discovery and link property correlation, if provided, MUST be able to operate in both an out-of-band and an out-of-fiber control channel.6. Security Considerations
The control-plane and data-plane aspects of a flexi-grid system are fundamentally the same as a fixed-grid system, and there is no substantial reason to expect the security considerations to be any different. A good overview of the security considerations for a GMPLS-based control plane can be found in [RFC5920]. [RFC6163] includes a section describing security considerations for WSON, and it is reasonable to infer that these considerations apply and may be exacerbated in a flexi-grid SSON system. In particular, the detailed and granular information describing a flexi-grid network and the capabilities of nodes in that network could put stress on the routing protocol or the out-of-band control channel used by the protocol. An attacker might be able to cause small variations in the use of the network or the available resources (perhaps by modifying the environment of a fiber) and so trigger the routing protocol to make new flooding announcements. This situation is explicitly mitigated in the requirements for the routing protocol extensions where it is noted that the protocol must include damping and configurable thresholds as already exist in the core GMPLS routing protocols.
7. Manageability Considerations
GMPLS systems already contain a number of management tools: o MIB modules exist to model the control-plane protocols and the network elements [RFC4802] [RFC4803], and there is early work to provide similar access through YANG. The features described in these models are currently designed to represent fixed-label technologies such as optical networks using the fixed grid; extensions may be needed in order to represent bandwidth, frequency slots, and effective frequency slots in flexi-grid networks. o There are protocol extensions within GMPLS signaling to allow control-plane systems to report the presence of faults that affect LSPs [RFC4783], although it must be carefully noted that these mechanisms do not constitute an alarm mechanism that could be used to rapidly propagate information about faults in a way that would allow the data plane to perform protection switching. These mechanisms could easily be enhanced with the addition of technology-specific reason codes if any are needed. o The GMPLS protocols, themselves, already include fault detection and recovery mechanisms (such as the PathErr and Notify messages in RSVP-TE signaling as used by GMPLS [RFC3473]). It is not anticipated that these mechanisms will need enhancement to support flexi-grid, although additional reason codes may be needed to describe technology-specific error cases. o [RFC7260] describes a framework for the control and configuration of data-plane Operations, Administration, and Maintenance (OAM). It would not be appropriate for the IETF to define or describe data-plane OAM for optical systems, but the framework described in RFC 7260 could be used (with minor protocol extensions) to enable data-plane OAM that has been defined by the originators of the flexi-grid data-plane technology (the ITU-T). o The Link Management Protocol (LMP) [RFC4204] is designed to allow the two ends of a network link to coordinate and confirm the configuration and capabilities that they will apply to the link. LMP is particularly applicable to optical links, where the characteristics of the network devices may considerably affect how the link is used and where misconfiguration or mis-fibering could make physical interoperability impossible. LMP could easily be extended to collect and report information between the endpoints of links in a flexi-grid network.
8. References
8.1. Normative References
[G.694.1] International Telecommunication Union, "Spectral grids for WDM applications: DWDM frequency grid", ITU-T Recommendation G.694.1, February 2012, <https://www.itu.int/rec/T-REC-G.694.1/en>. [G.800] International Telecommunication Union, "Unified functional architecture of transport networks", ITU-T Recommendation G.800, February 2012, <http://www.itu.int/rec/T-REC-G.800/>. [G.805] International Telecommunication Union, "Generic functional architecture of transport networks", ITU-T Recommendation G.805, March 2000, <https://www.itu.int/rec/T-REC-G.805-200003-I/en>. [G.8080] International Telecommunication Union, "Architecture for the automatically switched optical network", ITU-T Recommendation G.8080/Y.1304, February 2012, <https://www.itu.int/rec/T-REC-G.8080-201202-I/en>. [G.870] International Telecommunication Union, "Terms and definitions for optical transport networks", ITU-T Recommendation G.870/Y.1352, October 2012, <https://www.itu.int/rec/T-REC-G.870/en>. [G.872] International Telecommunication Union, "Architecture of optical transport networks", ITU-T Recommendation G.872, October 2012, <http://www.itu.int/rec/T-REC-G.872-201210-I>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, DOI 10.17487/RFC3945, October 2004, <http://www.rfc-editor.org/info/rfc3945>. [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, <http://www.rfc-editor.org/info/rfc4202>.
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, DOI 10.17487/RFC4206, October 2005, <http://www.rfc-editor.org/info/rfc4206>. [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, DOI 10.17487/RFC5511, April 2009, <http://www.rfc-editor.org/info/rfc5511>.8.2. Informative References
[G.959.1-2013] International Telecommunication Union, "Optical transport network physical layer interfaces", Update to ITU-T Recommendation G.959.1, 2013. [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, <http://www.rfc-editor.org/info/rfc3473>. [RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, DOI 10.17487/RFC4204, October 2005, <http://www.rfc-editor.org/info/rfc4204>. [RFC4397] Bryskin, I. and A. Farrel, "A Lexicography for the Interpretation of Generalized Multiprotocol Label Switching (GMPLS) Terminology within the Context of the ITU-T's Automatically Switched Optical Network (ASON) Architecture", RFC 4397, DOI 10.17487/RFC4397, February 2006, <http://www.rfc-editor.org/info/rfc4397>. [RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control", RFC 4606, DOI 10.17487/RFC4606, August 2006, <http://www.rfc-editor.org/info/rfc4606>. [RFC4783] Berger, L., Ed., "GMPLS - Communication of Alarm Information", RFC 4783, DOI 10.17487/RFC4783, December 2006, <http://www.rfc-editor.org/info/rfc4783>.
[RFC4802] Nadeau, T., Ed., Farrel, A., and , "Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base", RFC 4802, DOI 10.17487/RFC4802, February 2007, <http://www.rfc-editor.org/info/rfc4802>. [RFC4803] Nadeau, T., Ed., and A. Farrel, Ed., "Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base", RFC 4803, DOI 10.17487/RFC4803, February 2007, <http://www.rfc-editor.org/info/rfc4803>. [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <http://www.rfc-editor.org/info/rfc5920>. [RFC6163] Lee, Y., Ed., Bernstein, G., Ed., and W. Imajuku, "Framework for GMPLS and Path Computation Element (PCE) Control of Wavelength Switched Optical Networks (WSONs)", RFC 6163, DOI 10.17487/RFC6163, April 2011, <http://www.rfc-editor.org/info/rfc6163>. [RFC6344] Bernstein, G., Ed., Caviglia, D., Rabbat, R., and H. van Helvoort, "Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS)", RFC 6344, DOI 10.17487/RFC6344, August 2011, <http://www.rfc-editor.org/info/rfc6344>. [RFC7139] Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D., and K. Pithewan, "GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks", RFC 7139, DOI 10.17487/RFC7139, March 2014, <http://www.rfc-editor.org/info/rfc7139>. [RFC7260] Takacs, A., Fedyk, D., and J. He, "GMPLS RSVP-TE Extensions for Operations, Administration, and Maintenance (OAM) Configuration", RFC 7260, DOI 10.17487/RFC7260, June 2014, <http://www.rfc-editor.org/info/rfc7260>.
Acknowledgments
The authors would like to thank Pete Anslow for his insights and clarifications, and Matt Hartley and Jonas Maertensson for their reviews. This work was supported in part by the FP-7 IDEALIST project under grant agreement number 317999.Contributors
Adrian Farrel Old Dog Consulting Email: adrian@olddog.co.uk Daniel King Old Dog Consulting Email: daniel@olddog.co.uk Xian Zhang Huawei Email: zhang.xian@huawei.com Cyril Margaria Juniper Networks Email: cmargaria@juniper.net Qilei Wang ZTE Ruanjian Avenue, Nanjing, China Email: wang.qilei@zte.com.cn Malcolm Betts ZTE Email: malcolm.betts@zte.com.cn Sergio Belotti Alcatel-Lucent Optics CTO Via Trento 30 20059 Vimercate (Milano) Italy Phone: +39 039 686 3033 Email: sergio.belotti@alcatel-lucent.com Yao Li Nanjing University Email: wsliguotou@hotmail.com
Fei Zhang Huawei Email: zhangfei7@huawei.com Lei Wang Email: wang.lei@bupt.edu.cn Guoying Zhang China Academy of Telecom Research No.52 Huayuan Bei Road, Beijing, China Email: zhangguoying@ritt.cn Takehiro Tsuritani KDDI R&D Laboratories Inc. 2-1-15 Ohara, Fujimino, Saitama, Japan Email: tsuri@kddilabs.jp Lei Liu UC Davis, United States Email: leiliu@ucdavis.edu Eve Varma Alcatel-Lucent Phone: +1 732 239 7656 Email: eve.varma@alcatel-lucent.com Young Lee Huawei Jianrui Han Huawei Sharfuddin Syed Infinera Rajan Rao Infinera Marco Sosa Infinera Biao Lu Infinera Abinder Dhillon Infinera
Felipe Jimenez Arribas Telefonica I+D Andrew G. Malis Huawei Email: agmalis@gmail.com Huub van Helvoort Hai Gaoming BV The Netherlands Email: huubatwork@gmail.comAuthors' Addresses
Oscar Gonzalez de Dios (editor) Telefonica I+D Ronda de la Comunicacion s/n Madrid 28050 Spain Phone: +34 91 312 96 47 Email: oscar.gonzalezdedios@telefonica.com Ramon Casellas (editor) CTTC Av. Carl Friedrich Gauss n.7 Castelldefels Barcelona Spain Phone: +34 93 645 29 00 Email: ramon.casellas@cttc.es Fatai Zhang Huawei Huawei Base, Bantian, Longgang District Shenzhen 518129 China Phone: +86 755 28972912 Email: zhangfatai@huawei.com
Xihua Fu Stairnote No.118, Taibai Road, Yanta District Xi'An China Email: fu.xihua@stairnote.com Daniele Ceccarelli Ericsson Via Calda 5 Genova Italy Phone: +39 010 600 2512 Email: daniele.ceccarelli@ericsson.com Iftekhar Hussain Infinera 140 Caspian Ct. Sunnyvale, CA 94089 United States Phone: 408 572 5233 Email: ihussain@infinera.com