tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 7698

 
 
 

Framework and Requirements for GMPLS-Based Control of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks

Part 3 of 3, p. 31 to 42
Prev RFC Part

 


prevText      Top      Up      ToC       Page 31 
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

Top      Up      ToC       Page 32 
   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.

Top      Up      ToC       Page 33 
   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).

Top      Up      ToC       Page 34 
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.

Top      Up      ToC       Page 35 
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.

Top      Up      ToC       Page 36 
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>.

Top      Up      ToC       Page 37 
   [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>.

Top      Up      ToC       Page 38 
   [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>.

Top      Up      ToC       Page 39 
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

Top      Up      ToC       Page 40 
   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

Top      Up      ToC       Page 41 
   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.com

Authors' 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

Top      Up      ToC       Page 42 
   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