• <?xml version="1.0" encoding="US-ASCII"?>
  • <!DOCTYPE rfc SYSTEM "rfc2629.dtd">
  • <rfc submissionType="IETF" category="std" consensus="yes" number="8363" obsoletes="" updates="" {http://www.w3.org/XML/1998/namespace}lang="en">
    • <?rfc compact="yes"?>
    • <?rfc text-list-symbols="o*+-"?>
    • <?rfc subcompact="no"?>
    • <?rfc sortrefs="yes"?>
    • <?rfc sortrefs="no"?>
    • <?rfc symrefs="yes"?>
    • <?rfc toc="yes"?>
    • <front>
      • <title abbrev="GMPLS OSPF-TE for Flexi-Grid DWDM">
        • GMPLS OSPF-TE Extensions in Support of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks
        • </title>
      • <author fullname="Xian Zhang" initials="X." surname="Zhang">
        • <organization abbrev="Huawei">
          • Huawei Technologies
          • </organization>
        • <address>
          • <email>
            • zhang.xian@huawei.com
            • </email>
          • </address>
        • </author>
      • <author fullname="Haomian Zheng" initials="H." surname="Zheng">
        • <organization abbrev="Huawei">
          • Huawei Technologies
          • </organization>
        • <address>
          • <email>
            • zhenghaomian@huawei.com
            • </email>
          • </address>
        • </author>
      • <author fullname="Ramon Casellas, Ph.D." initials="R." surname="Casellas">
        • <organization>
          • CTTC
          • </organization>
        • <address>
          • <postal>
            • <street>
              • Spain
              • </street>
            • </postal>
          • <phone>
            • +34 936452916
            • </phone>
          • <email>
            • ramon.casellas@cttc.es
            • </email>
          • </address>
        • </author>
      • <author fullname="Oscar Gonzalez de Dios" initials="O." surname="Gonzalez de Dios">
        • <organization abbrev="Telefonica">
          • Telefonica Investigacion y Desarrollo
          • </organization>
        • <address>
          • <postal>
            • <street>
              • Emilio Vargas 6
              • </street>
            • <street>
              • Madrid, 28045
              • </street>
            • <street>
              • Spain
              • </street>
            • </postal>
          • <phone>
            • +34 913374013
            • </phone>
          • <email>
            • ogondio@tid.es
            • oscar.gonzalezdedios@telefonica.com
            • </email>
          • </address>
        • </author>
      • <author fullname="Daniele Ceccarelli" initials="D." surname="Ceccarelli">
        • <organization>
          • Ericsson
          • </organization>
        • <address>
          • <postal>
            • <street>
              • Via A. Negrone 1/A
              • </street>
            • <street>
              • Genova - Sestri Ponente
              • </street>
            • <street>
              • Italy
              • </street>
            • </postal>
          • <email>
            • daniele.ceccarelli@ericsson.com
            • </email>
          • </address>
        • </author>
      • <date month="March" year="2018"/>
      • <workgroup>
        • CCAMP Working Group
        • </workgroup>
      • <!--[rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. >
      • <keyword>
        • example
        • </keyword>
      • <!--[rfced] Please clarify the "by defining" phrase in this sentence. Does "set" apply to "channel spacings" as well as "nominal central frequencies"? Original: The International Telecommunication Union Telecommunication Standardization Sector (ITU-T) has extended its Recommendations G.694.1 and G.872 to include a new Dense Wavelength Division Multiplexing (DWDM) grid by defining a set of nominal central frequencies, channel spacings, and the concept of the "frequency slot". Perhaps (set includes nominal central frequencies and channel spacings): The International Telecommunication Union Telecommunication standardization sector (ITU-T) has extended its Recommendations G.694.1 and G.872 to include a new Dense Wavelength Division Multiplexing (DWDM) grid by defining the concept of the "frequency slot" and a set of nominal central frequencies and channel spacings. Or (channel spacings separate from set of nominal central frequencies): The International Telecommunication Union Telecommunication standardization sector (ITU-T) has extended its Recommendations G.694.1 and G.872 to include a new Dense Wavelength Division Multiplexing (DWDM) grid by defining channel spacings, a set of nominal central frequencies, and the concept of the "frequency slot". >
      • <abstract>
        • <t>
          • The International Telecommunication Union Telecommunication standardization sector (ITU-T) has extended its Recommendations G.694.1 and G.872 to include a new Dense Wavelength Division Multiplexing (DWDM) grid by defining channel spacings, a set of nominal central frequencies, channel spacings, and the concept of the "frequency slot. Corresponding techniques for data-plane connections are known as ". Corresponding techniques for dataflexi-plane connections are known as grid"flexi-grid"..
          • </t>
        • <t>
          • Based on the characteristics of flexi-grid defined in G.694.1 and in RFCs 7698 and 7699, this document describes the Open Shortest Path First - Traffic Engineering (OSPF-TE) extensions in support of GMPLS control of networks that include devices that use the new flexible optical grid.
          • </t>
        • </abstract>
      • </front>
    • <middle>
      • <section title="Introduction" anchor="section-1" numbered="true" toc="default">
        • <t>
          • <xref target="G.694.1" format="default" pageno="false"/> defines the Dense Wavelength Division Multiplexing (DWDM) frequency grids for Wavelength Division Multiplexing (WDM) applications. A frequency grid is a reference set of frequencies used to denote allowed nominal central frequencies that may be used for defining applications. The channel spacing is the frequency spacing between two allowed nominal central frequencies. All of the wavelengths on a fiber should use different central frequencies and occupy a fixed bandwidth of frequency. defines the Dense Wavelength Division Multiplexing (DWDM) frequency grids for Wavelength Division Multiplexing (WDM) applications. A frequency grid is a reference set of frequencies used to denote allowed nominal central frequencies that may be used for defining applications. The channel spacing is the frequency spacing between two allowed nominal central frequencies. All of the wavelengths on a fiber should use different central frequencies and occupy a fixed bandwidth of frequency.
          • </t>
        • <t>
          • <!Fixed--[rfced] How grid channel spacing ranges fromay we clarify this range? Original: Fixed grid channel spacing ranges from one of 12.5 GHz, 25 GHz, 50 GHz, or 100 GHz to integer multiples of 100 GHz. Perhaps: Fixed-grid channel spacing ranges from one of 12.5 GHz, 25 GHz, 50 GHz, or 100 GHz to integer multiples of 100 GHz. --> Fixed-grid channel spacing ranges from 12.5 GHz, 25 GHz, 50 GHz, 100 GHz to integer multiples of 100 GHz. But Fixed-grid channel spacing ranges from 12.5 GHz, 25 GHz, 50 GHz, 100 GHz to integer multiples of 100 GHz. But <xref target="G.694.1" format="default" pageno="false"/> also defines a "flexible grid", also known as "flexi-grid". The terms "frequency slot" (i.e., the frequency range allocated to a specific channel and unavailable to other channels within a flexible grid) and "slot width" (i.e., the full width of a frequency slot in a flexible grid) are used to define a flexible grid. also defines a "flexible grid", also known as "flexi-grid". The terms "frequency slot" (i.e., the frequency range allocated to a specific channel and unavailable to other channels within a flexible grid) and "slot width" (i.e., the full width of a frequency slot in a flexible grid) are used to define a flexible grid.
          • </t>
        • <t>
          • <xref target="RFC7698" format="default" pageno="false"/> defines a framework and the associated control-plane requirements for the GMPLS-based control of flexi-grid DWDM networks. defines a framework and the associated control-plane requirements for the GMPLS-based control of flexi-grid DWDM networks.
          • </t>
        • <t>
          • <xref target="RFC6163" format="default" pageno="false"/> provides a framework for GMPLS and Path Computation Element (PCE) control of Wavelength Switched Optical Networks (WSONs). provides a framework for GMPLS and Path Computation Element (PCE) control of Wavelength Switched Optical Networks (WSONs). <xref target="RFC7688" format="default" pageno="false"/> defines the requirements and OSPF-TE extensions in support of GMPLS control of a WSON. defines the requirements and OSPF-TE extensions in support of GMPLS control of a WSON.
          • </t>
        • <t>
          • <xref target="RFC7792" format="default" pageno="false"/> describes requirements and protocol extensions for signaling to set up Label Switched Paths (LSPs) in networks that support the flexi-grid. This document complements describes requirements and protocol extensions for signaling to set up Label Switched Paths (LSPs) in networks that support the flexi-grid. This document complements <xref target="RFC7792" format="default" pageno="false"/> by describing the requirement and extensions for OSPF-TE routing in a flexi-grid network. by describing the requirement and extensions for OSPF-TE routing in a flexi-grid network.
          • </t>
        • <t>
          • This document complements the efforts to provide extensions to the OSPF-TE protocol so as to support GMPLS control of flexi-grid networks.
          • </t>
        • </section>
      • <section title="Terminology" anchor="section-2" numbered="true" toc="default">
        • <t>
          • For terminology related to flexi-grid, please consult <xref target="RFC7698" format="default" pageno="false"/> and and <xref target="G.694.1" format="default" pageno="false"/>..
          • </t>
        • <section title="Conventions Used in This Document" anchor="section-2.1" numbered="true" toc="default">
          • <t>
            • 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 <xref target="RFC2119" format="default" pageno="false"/> <xref target="RFC8174" format="default" pageno="false"/> when, and only when, they appear in all capitals, as shown here. when, and only when, they appear in all capitals, as shown here.
            • </t>
          • </section>
        • </section>
      • <section title="Requirements for Flexi-Grid Routing" anchor="section-3" numbered="true" toc="default">
        • <t>
          • The architecture for establishing LSPs in a Spectrum Switched Optical Network (SSON) is described in <xref target="RFC7698" format="default" pageno="false"/>..
          • </t>
        • <t>
          • A flexi-grid LSP occupies a specific frequency slot, i.e., a frequency range. The process of computing a route and the allocation of a frequency slot is referred to as "RSA" (Routing and Spectrum Assignment). <xref target="RFC7698" format="default" pageno="false"/> describes three types of architectural approaches to RSA: combined RSA, separated RSA, and distributed SA. describes three types of architectural approaches to RSA: combined RSA, separated RSA, and distributed SA. <!--[rfced] RFC 7698 lists the following: Combined RSA (R&SA) Separated RSA (R+SA) Routing and Distributed SA (R+DSA) Should we globally update mentions of "distributed SA" to "routing and distributed SA"? For example: Original: [RFC7698] describes three types of architectural approaches to RSA: combined RSA, separated RSA, and distributed SA. Perhaps: [RFC7698] describes three types of architectural approaches to RSA: combined RSA, separated RSA, and routing and distributed SA. --> The first two approaches could be called "centralized SA" because the spectrum (frequency slot) assignment is performed by a single entity before the signaling procedure. The first two approaches could be called "centralized SA" because the spectrum (frequency slot) assignment is performed by a single entity before the signaling procedure.
          • A flexi-grid LSP occupies one or multiple specific frequency slots. The process of computing a route and the allocation of a frequency slot is referred to as "RSA" (Routing and Spectrum Assignment). <xref target="RFC7698" format="default" pageno="false"/> describes three types of architectural approaches to RSA: combined RSA, separated RSA, and routing and distributed SA. The first two approaches could be called "centralized SA" because the spectrum (frequency slot) assignment is performed by a single entity before the signaling procedure. describes three types of architectural approaches to RSA: combined RSA, separated RSA, and routing and distributed SA. The first two approaches could be called "centralized SA" because the spectrum (frequency slot) assignment is performed by a single entity before the signaling procedure.
          • </t>
        • <t>
          • In the case of centralized SA, the assigned frequency slot is specified in the RSVP-TE Path message during the signaling process. In the case of routing and distributed SA, only the requested slot width of the flexi-grid LSP is specified in the Path message, allowing the involved network elements to select the frequency slot to be used.
          • </t>
        • <t>
          • If the capability of switching or converting the whole optical spectrum allocated to an optical spectrum LSP is not available at nodes along the path of the LSP, the LSP is subject to the Optical "Spectrum Continuity Constraint", as described in <xref target="RFC7698" format="default" pageno="false"/>..
          • </t>
        • <t>
          • The remainder of this section states the additional extensions on the routing protocols in a flexi-grid network.
          • </t>
        • <section title="Available Frequency Ranges" anchor="ranges" numbered="true" toc="default">
          • <t>
            • In the case of flexi-grids, the central frequency steps from 193.1 THz with 6.25 GHz granularity. The calculation method of central frequency and the frequency slot width of a frequency slot are defined in <xref target="G.694.1" format="default" pageno="false"/>, i.e., by using nominal central frequency n and the slot width m., i.e., by using nominal central frequency n and the slot width m.
            • </t>
          • <t>
            • On a DWDM link, the allocated or in-use frequency slots do not overlap with each other. However, the border frequencies of two frequency slots may be the same frequency, i.e., the upper bound of a frequency slot and the lower bound of the directly adjacent frequency slot are the same.
            • </t>
          • <figure title="Two Frequency Slots on a Link" anchor="fig1" suppress-title="false" align="left" alt="" width="" height="">
            • <artwork {http://www.w3.org/XML/1998/namespace}space="preserve" name="" type="" align="left" alt="" width="" height="">

              •                       Frequency Slot 1   Frequency Slot 2
                                        +-----------+-----------------------+
                                        |           |                       |
                   -9 -8 -7 -6 -5 -4 -3 -2 -1 0  1  2  3  4  5  6  7  8  9 10  11
                ...+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--...
                                        ------------ ------------------------
                                              ^                 ^
                                 Central F = 193.1 THz   Central F = 193.1375 THz
                                  Slot width = 25 GHz    Slot width = 50 GHz
              • </artwork>
            • </figure>
          • <t>
            • <xref target="fig1" format="default" pageno="false"/> shows two adjacent frequency slots on a link. The highest frequency of frequency slot 1 denoted by n=2 is the lowest frequency of slot 2. In this example, it means that the frequency range from n=-2 to n=10 is unavailable to other flexi-grid LSPs. Available central frequencies are advertised for m=1, which means that for an available central frequency n, the frequency slot from central frequency n-1 to central frequency n+1 is available. shows two adjacent frequency slots on a link. The highest frequency of frequency slot 1 denoted by n=2 is the lowest frequency of slot 2. In this example, it means that the frequency range from n=-2 to n=10 is unavailable to other flexi-grid LSPs. Available central frequencies are advertised for m=1, which means that for an available central frequency n, the frequency slot from central frequency n-1 to central frequency n+1 is available.
            • </t>
          • <t>
            • Hence, in order to clearly show which frequency slots are available and can be used for LSPs can be supported establishment and whatich frequency slots are unavailable, the availableility of frequency ranges areslots is advertised by the routing protocol for the flexi-grid DWDM links. A set of non-overlapping available frequency ranges is disseminated in order to allow efficient resource management of flexi-grid DWDM links and RSA procedures, which are described in Section 4.8 of <xref target="RFC7698" format="default" pageno="false"/>..
            • </t>
          • </section>
        • <section title="Application Compliance Considerations" anchor="compliance" numbered="true" toc="default">
          • <t>
            • As described in <xref target="G.694.1" format="default" pageno="false"/>, devices or applications that make use of the flexi-grid may not be capable of supporting every possible slot width or position (i.e., central frequency). In other words, applications or implementations may be defined where only a subset of the possible slot widths and positions are required to be supported., devices or applications that make use of the flexi-grid may not be capable of supporting every possible slot width or position (i.e., central frequency). In other words, applications or implementations may be defined where only a subset of the possible slot widths and positions are required to be supported.
            • </t>
          • <t>
            • <!--[rfced] Juxtaposing the "where" and "and that" clauses here makes this sentence difficult to parse. May we update as suggested? Original: For example, an application could be defined where the nominal central frequency granularity is 12.5 GHz (by only requiring values of n that are even) and that only requires slot widths as a multiple of 25 GHz (by only requiring values of m that are even). Perhaps: For example, an application could be defined where the nominal central frequency granularity is 12.5 GHz (by only requiring values of n that are even) and the same application only requires slot widths as a multiple of 25 GHz (by only requiring values of m that are even). --> For example, an application could be defined where the nominal central frequency granularity is 12.5 GHz (by only requiring values of n that are even) and that only requires slot widths as a multiple of 25 GHz (by only requiring values of m that are even). For example, an application could be defined where the nominal central frequency granularity is 12.5 GHz (by only requiring values of n that are even) and that only requires slot widths as a multiple of 25 GHz (by only requiring values of m that are even).
            • For example, an application could be defined where the nominal central frequency granularity is 12.5 GHz (by only requiring values of n that are even) and the same application only requires slot widths as a multiple of 25 GHz (by only requiring values of m that are even).
            • </t>
          • <t>
            • Hence, in order to support all possible applications and implementations, the following information SHOULD be advertised for a flexi-grid DWDM link:
            • </t>
          • <t>
            • <list style="symbols">
              • <t>
                • Channel Spacing (C.S.): as defined in <xref target="RFC7699" format="default" pageno="false"/> for flexi-grid, is set to 5 to denote 6.25 GHz. for flexi-grid, is set to 5 to denote 6.25 GHz.
                • </t>
              • <t>
                • Central frequency granularity: a multiplier of C.S.
                • </t>
              • <t>
                • Slot width granularity: a multiplier of 2*C.S.
                • </t>
              • <t>
                • Slot width range: two multipliers of the slot width granularity, each indicating the minimal and maximal slot width supported by a port, respectively.
                • </t>
              • </list>
            • </t>
          • <t>
            • The combination of slot width range and slot width granularity can be used to determine the slot widths set supported by a port.
            • </t>
          • </section>
        • <section title="Comparison with Fixed-Grid DWDM Links" anchor="section-3.3" numbered="true" toc="default">
          • <t>
            • In the case of fixed-grid DWDM links, each wavelength has a predefined central frequency. Each wavelength maps to a predefined central frequency, and the usable frequency range is implicit by the channel spacing. All the wavelengths on a DWDM link can be identified with an identifier that mainly conveys its central frequency as the label defined in <xref target="RFC6205" format="default" pageno="false"/>; the status of the wavelengths (available or not) can be advertised through a routing protocol.; the status of the wavelengths (available or not) can be advertised through a routing protocol.
            • </t>
          • <t>
            • <xref target="fig2" format="default" pageno="false"/> shows a link that supports a fixed-grid with 50 GHz channel spacing. The central frequencies of the wavelengths are predefined by values of "n", and each wavelength occupies a fixed 50 GHz frequency range as described in shows a link that supports a fixed-grid with 50 GHz channel spacing. The central frequencies of the wavelengths are predefined by values of "n", and each wavelength occupies a fixed 50 GHz frequency range as described in <xref target="G.694.1" format="default" pageno="false"/>..
            • </t>
          • <figure title="A Link Supports Fixed Wavelengths with 50 GHz Channel Spacing" anchor="fig2" suppress-title="false" align="left" alt="" width="" height="">
            • <artwork {http://www.w3.org/XML/1998/namespace}space="preserve" name="" type="" align="left" alt="" width="" height="">

              •      W(-2)  |    W(-1)  |    W(0)   |    W(1)   |     W(2)  |
                ...---------+-----------+-----------+-----------+-----------+----...
                      |   50 GHz  |  50 GHz   |  50 GHz   |   50 GHz  |

                    n=-2        n=-1        n=0         n=1         n=2
                ...---+-----------+-----------+-----------+-----------+----------...
                                              ^
                                 Central F = 193.1 THz
              • </artwork>
            • </figure>
          • <t>
            • Unlike the fixed-grid DWDM links, on a flexi-grid DWDM link, the slot width of the frequency slot is flexible, as described in <xref target="ranges" format="default" pageno="false"/>. That is, the value of m in the following formula from . That is, the value of m in the following formula from <xref target="G.694.1" format="default" pageno="false"/> is uncertain before a frequency slot is actually allocated for a flexi-grid LSP. is uncertain before a frequency slot is actually allocated for a flexi-grid LSP.
            • </t>
          • <t>
            • <list hangIndent="13" style="hanging">
              • <t>
                • Slot Width (in GHz) = 12.5GHz * m
                • </t>
              • </list>
            • </t>
          • <t>
            • <!--[rfced] Please clarify this use of the "/" character. Original: For this reason, the available frequency slot/ranges are advertised for a flexi-grid DWDM link instead of the specific "wavelengths" points that are sufficient for a fixed-grid link. Perhaps: For this reason, the available frequency slots or ranges are advertised for a flexi-grid DWDM link instead of the specific "wavelength" points that are sufficient for a fixed-grid link. --> For this reason, the available frequency slot/ranges are advertised for a flexi-grid DWDM link instead of the specific "wavelength" points that are sufficient for a fixed-grid link. Moreover, this advertisement is represented by the combination of central frequency granularity and slot width granularity. For this reason, the available frequency slot/ranges are advertised for a flexi-grid DWDM link instead of the specific "wavelength" points that are sufficient for a fixed-grid link. Moreover, this advertisement is represented by the combination of central frequency granularity and slot width granularity.
            • For this reason, the available frequency slots (or ranges) are advertised for a flexi-grid DWDM link instead of the specific "wavelength" points that are sufficient for a fixed-grid link. Moreover, this advertisement is represented by the combination of central frequency granularity and slot width granularity.
            • </t>
          • </section>
        • </section>
      • <section title="Extensions" anchor="section-4" numbered="true" toc="default">
        • <t>
          • The network-connectivity topology constructed by the links and/or nodes and node capabilities are the same as for WSON, as described in <xref target="RFC7698" format="default" pageno="false"/>, and they can be advertised by the GMPLS routing protocols using Opaque Link State Advertisements (LSAs) , and they can be advertised by the GMPLS routing protocols using Opaque Link State Advertisements (LSAs) <xref target="RFC3630" format="default" pageno="false"/> in the case of OSPF-TE in the case of OSPF-TE <xref target="RFC4203" format="default" pageno="false"/> (refer to Section 6.2 of (refer to Section 6.2 of <xref target="RFC6163" format="default" pageno="false"/>). In the flexi-grid case, the available frequency ranges, instead of the specific "wavelengths", are advertised for the link. This section defines the GMPLS OSPF-TE extensions in support of advertising the available frequency ranges for flexi-grid DWDM links.). In the flexi-grid case, the available frequency ranges, instead of the specific "wavelengths", are advertised for the link. This section defines the GMPLS OSPF-TE extensions in support of advertising the available frequency ranges for flexi-grid DWDM links.
          • </t>
        • <section title="Interface Switching Capability Descriptor (ISCD) Extensions for Flexi-Grid" anchor="flexi" numbered="true" toc="default">
          • <t>
            • This section defines a new value for the Switching Capability field of the ISCD with a value of 152 and type name Flexi-Grid-LSC.
            • </t>
          • <!--[rfced] In the following, should "Type" be "Name"? Please review and let us know if any updates are needed. Current: Value Type - - - - - - - - - - - 152 Flexi-Grid-LSC >
          • <figure title="" suppress-title="false" align="left" alt="" width="" height="">
            • <artwork {http://www.w3.org/XML/1998/namespace}space="preserve" name="" type="" align="left" alt="" width="" height="">

              •          Value              
                TypName
                         -----              --------------
                         152                Flexi-Grid-LSC

                Switching Capability and Encoding values MUST be used as follows:

                         Switching Capability = Flexi-Grid-LSC

                         Encoding Type = lambda (as defined in [RFC3471])
              • </artwork>
            • </figure>
          • <t>
            • When the Switching Capability and Encoding fields are set to values as stated above, the ISCD is interpreted as in <xref target="RFC4203" format="default" pageno="false"/> with the optional inclusion of one or more Switching Capability-Specific Information (SCSI) sub-TLVs. with the optional inclusion of one or more Switching Capability-Specific Information (SCSI) sub-TLVs.
            • </t>
          • <t>
            • As the "Max LSP Bandwidth at priority x" (x from 0 to 7) fields in the generic part of the ISCD <xref target="RFC4203" format="default" pageno="false"/> are not meaningful for flexi-grid DWDM links, the values of these fields MUST be set to zero and MUST be ignored. The SCSI as defined below provides the corresponding information for flexi-grid DWDM links. are not meaningful for flexi-grid DWDM links, the values of these fields MUST be set to zero and MUST be ignored. The SCSI as defined below provides the corresponding information for flexi-grid DWDM links.
            • </t>
          • <section title="Switching Capability-Specific Information (SCSI)" anchor="switch" numbered="true" toc="default">
            • <t>
              • <xref target="RFC8258" format="default" pageno="false"/> defines a Generalized SCSI for the ISCD. This document defines the Frequency aAvailability Bitmap as a new type of the Generalized SCSI TLV. The technology-specific part of the flexi-grid ISCD includes the availabitmap as a nele frequency-spectrum resource as w type of the Generalized SCSIell as the information regarding max slot widths per priority. The technology-specific part of theformat of this flexi-grid ISCD includes the available frequency-spectrum resource as well as the information regarding max slot widths per priority. defines a Generalized SCSI for the ISCD. This document defines the Frequency availability bitmap as a new type of the Generalized SCSI. The technology-specific part of the flexi-grid ISCD includes the available frequency-spectrum resource as well as the information regarding max slot widths per priority. <!--[rfced] Should instances of "flex-grid" in these sentences be updated to "flexi-grid"? Original The format of this flex-grid SCSI, the fFrequency aAvailable ility Bitmap subitmap -TLV, is depicted in the following figure: defines a Generalized SCSI for the ISCD. This document defines the Frequency Availability Bitmap as a new type of the Generalized SCSI TLV. The technology-specific part of the flexi-grid ISCD includes the available frequency-spectrum resource as well as the information regarding max slot widths per priority. This document e format of this flextends [RFC4203] and [RFC7580] to carry flex-grid specific information in OSPF Opaque LSAs. --> The format of this flexi-grid SCSI, the fFrequency aAvailability Bitmap subitmap -TLV, is depicted in the following figure: The format of this flex-grid SCSI, the frequency availability bitmap TLV, is depicted in the following figure:
              • </t>
            • <!--[rfced] We have a few question about the use of the following: frequency availability bitmap vs. Frequency availability bitmap First, should the capitalization be consistent? If so, please let us know which form is preferred. We question if initial caps would be appropriate (i.e., Frequency Availability Bitmap"). Second, should the use of "TLV" or "sub-TLV" be made uniform (i.e., "frequency availability bitmap TLV" or "frequency availability bitmap sub-TLV")? Last, should either "TLV" or "sub-TLV" be added after "Frequency availability bitmap" in this sentence? Original (from updated file sent by Deborah Brungard): [RFC8258] defines a Generalized SCSI for the ISCD. This document defines the Frequency availability bitmap as a new type of the Generalized SCSI. >
            • <!--[rfced] In Section 4.1.1, "Bit Map" (two words) is used for the name of a field. We note that "bitmap" (one word) is used elsewhere in the document. Should this field be updated to "Bitmap" (one word) accordingly? >
            • <!--[rfced] For the ease of the reader, should titles be added to figures in the document that have no titles (i.e., the TLVs)? If so, please provide the titles. >
            • <figure title="" suppress-title="false" align="left" alt="" width="" height="">
              • <artwork {http://www.w3.org/XML/1998/namespace}space="preserve" name="" type="" align="left" alt="" width="" height="">

                •   0                   1                   2                   3
                    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |          Type  = 11           |           Length              |
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |   Priority    |                   Reserved                    |
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   ~ Max Slot Width at Priority k  |   Unreserved Padding          ~
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   | C.S.  |       Starting n              | No. of Effective Bits |
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |       Bit
                   Mmap                  ...                             ~
                   ~      ...                              |  padding bits         ~
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                • </artwork>
              • </figure>
            • <t>
              • Type (16 bits): The type of this sub-TLV (11).
              • </t>
            • <t>
              • Length (16 bits): The length of the value field of this sub-TLV in octets.
              • </t>
            • <t>
              • Priority (8 bits): A bitmap used to indicate which priorities are being advertised. The bitmap is in ascending order, with the leftmost bit representing priority level 0 (i.e., the highest) and the rightmost bit representing priority level 7 (i.e., the lowest). A bit is set (1) corresponding to each priority represented in the sub-TLV and clear (0) for each priority not represented in the sub-TLV. At least one priority level MUST be advertised. If only one priority level is advertised, it MUST be at priority level 0.
              • </t>
            • <t>
              • Reserved: The Reserved field MUST be set to zero on transmission and MUST be ignored on receipt.
              • </t>
            • <t>
              • Max Slot Width at Priority k (16 bits): This field indicates maximal frequency slot width supported at a particular priority level, up to 8. This field is set to max frequency slot width supported in the unit of 2*C.S., for a particular priority level. <!--[rfced] Please clarify the subject of the clause beginning with "and is": Original: One field MUST be present for each bit set in the Priority field, and is ordered to match the Priority field. Perhaps: One field MUST be present for each bit set in the Priority field, and each field is ordered to match the Priority field. --> One field MUST be present for each bit set in the Priority field, and is ordered to match the Priority field. Fields MUST be present for priority levels that are indicated in the Priority field. One field MUST be present for each bit set in the Priority field, and is ordered to match the Priority field. Fields MUST be present for priority levels that are indicated in the Priority field.
              • Max Slot Width at Priority k (16 bits): This field indicates maximal frequency slot width supported at a particular priority level, up to 8. This field is set to max frequency slot width supported in the unit of 2*C.S., for a particular priority level. One field MUST be present for each bit set in the Priority field, and each present field is ordered to match the Priority field. Fields MUST be present for priority levels that are indicated in the Priority field.
              • </t>
            • <t>
              • <!--[rfced] Should the field names in the following text be updated? We do not see a "Padding field" in the figure this text is describing. Also, should "Max Slot Width fields" be made "Max Slot Width at Priority k"? Original: Unreserved Padding (16 bits): The Padding field is used to ensure the 32 bit alignment of Max Slot Width fields. When the number of priorities is odd, the Unreserved Padding field MUST be included. --> Unreserved Padding (16 bits): The Padding field is used to ensure the 32-bit alignment of Max Slot Width fields. When the number of priorities is odd, the Unreserved Padding field MUST be included. When the number of priorities is even, the Unreserved Padding field MUST be omitted. This field MUST be set to 0 and MUST be ignored on receipt. Unreserved Padding (16 bits): The Padding field is used to ensure the 32-bit alignment of Max Slot Width fields. When the number of priorities is odd, the Unreserved Padding field MUST be included. When the number of priorities is even, the Unreserved Padding field MUST be omitted. This field MUST be set to 0 and MUST be ignored on receipt.
              • Unreserved Padding (16 bits): The Padding field is used to ensure the 32-bit alignment of Max Slot Width at Priority k. When k is an odd number, the Unreserved Padding field MUST be included. When k is an even number, the Unreserved Padding field MUST be omitted. This field MUST be set to 0 and MUST be ignored on receipt.
              • </t>
            • <t>
              • C.S. (4 bits): As defined in <xref target="RFC7699" format="default" pageno="false"/>; it is currently set to 5.; it is currently set to 5.
              • </t>
            • <!--[rfced] We find "starting nominal central frequency point" difficult to read. Does the suggested text below accurately convey the intended meaning? Original Starting n (16 bits): as defined in [RFC7699] and this value denotes the starting nominal central frequency point of the frequency availability bitmap sub-TLV. Perhaps Starting n (16 bits): As defined in [RFC7699]. This value denotes the starting point of the nominal central frequency of the frequency availability bitmap sub-TLV. >
            • <t>
              • Starting n (16 bits): As defined in <xref target="RFC7699" format="default" pageno="false"/>. This value denotes the starting nominal central frequency point of the frequency availability bitmap sub-TLV.. This value denotes the starting nominal central frequency point of the frequency availability bitmap sub-TLV.
              • Starting n (16 bits): As defined in [RFC7699]. This value denotes the starting point of the nominal central frequency of the frequency availability bitmap sub-TLV.
              • </t>
            • <t>
              • No. of Effective Bits (12 bits): Indicates the number of effective bits in the Bit Mmap field.
              • </t>
            • <t>
              • Bit Map (variable): Indicates whether or not a basic frequency slot, characterized by a nominal central frequency and a fixed m value of 1, is available for flexi-grid LSP setup. <!--[rfced] We have updated this sentence as follows for clarity. Please review and confirm that the updated text accurately conveys the intended meaning. Original The first nominal central frequency is the value of starting n and with the subsequent ones implied by the position in the bitmap. Perhaps The first nominal central frequency is the value of starting n; subsequent nominal central frequencies are implied by the position in the bitmap. --> The first nominal central frequency is the value of starting n; subsequent nominal central frequencies are implied by the position in the bitmap. Note that setting to 1 indicates that the corresponding central frequency is available for a flexi-grid LSP with m=1 and setting to 0 indicates the corresponding central frequency is unavailable. Note that a centralized SA process will need to extend this to high values of m by checking a sufficiently large number of consecutive basic frequency slots that are available. The first nominal central frequency is the value of starting n; subsequent nominal central frequencies are implied by the position in the bitmap. Note that setting to 1 indicates that the corresponding central frequency is available for a flexi-grid LSP with m=1 and setting to 0 indicates the corresponding central frequency is unavailable. Note that a centralized SA process will need to extend this to high values of m by checking a sufficiently large number of consecutive basic frequency slots that are available.
              • Bitmap (variable): Indicates whether or not a basic frequency slot, characterized by a nominal central frequency and a fixed m value of 1, is available for flexi-grid LSP setup. The first nominal central frequency is the value of starting n; subsequent nominal central frequencies are implied by the position in the bitmap. Note that setting to 1 indicates that the corresponding central frequency is available for a flexi-grid LSP with m=1 and setting to 0 indicates the corresponding central frequency is unavailable. Note that a centralized SA process will need to extend this to high values of m by checking a sufficiently large number of consecutive basic frequency slots that are available.
              • </t>
            • <t>
              • padding bits (variable): Padded after the Bit Mmap to make it a multiple of four bytes, if necessary. Padding bits MUST be set to 0 and MUST be ignored on receipt.
              • </t>
            • <t>
              • An example is provided in <xref target="scsi" format="default" pageno="false"/>..
              • </t>
            • </section>
          • <section title="An SCSI Example" anchor="scsi" numbered="true" toc="default">
            • <t>
              • <xref target="fig3" format="default" pageno="false"/> shows an example of the available frequency spectrum resource of a flexi-grid DWDM link. shows an example of the available frequency spectrum resource of a flexi-grid DWDM link.
              • </t>
            • <figure title="Flexi-Grid DWDM Link Example" anchor="fig3" suppress-title="false" align="left" alt="" width="" height="">
              • <artwork {http://www.w3.org/XML/1998/namespace}space="preserve" name="" type="" align="left" alt="" width="" height="">

                •    -9 -8 -7 -6 -5 -4 -3 -2 -1 0  1  2  3  4  5  6  7  8  9 10  11
                  ...+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--...
                                          |--Available Frequency Range--|
                • </artwork>
              • </figure>
            • <!--[rfced] Please clarify "as currently be standardized" here. (Note that we used "-" (single dash) rather than the double dash in the text below because the double dash is not allowed in XML comments.) Original The symbol "-" represents a central frequency granularity of 6.25 GHz, as currently be standardized in [G.694.1]. Perhaps The symbol "-" represents a central frequency granularity of 6.25 GHz, which is currently standardized in [G.694.1]. >
            • <t>
              • The symbol "+" represents the allowed nominal central frequency. The symbol "--" represents a central frequency granularity of 6.25 GHz, as currently bewhich is currently standardized in <xref target="G.694.1" format="default" pageno="false"/>. The number on the top of the line represents the "n" in the frequency calculation formula (193.1 + n * 0.00625). The nominal central frequency is 193.1 THz when n equals zero.. The number on the top of the line represents the "n" in the frequency calculation formula (193.1 + n * 0.00625). The nominal central frequency is 193.1 THz when n equals zero.
              • </t>
            • <t>
              • In this example, it is assumed that the lowest nominal central frequency supported is n=-9 and the highest is n=11. Note they cannot be used as a nominal central frequency for setting up an LSP, but merely as the way to express the supported frequency range. Using the encoding defined in <xref target="switch" format="default" pageno="false"/>, the relevant fields to express the frequency resource availability can be filled as below:, the relevant fields to express the frequency resource availability can be filled as below:
              • </t>
            • <figure title="" suppress-title="false" align="left" alt="" width="" height="">
              • <artwork {http://www.w3.org/XML/1998/namespace}space="preserve" name="" type="" align="left" alt="" width="" height="">

                •   0                   1                   2                   3
                    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |          Type  = 11           |           Length              |
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |   Priority    |                   Reserved                    |
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   ~ Max Slot Width at Priority k  |   Unreserved Padding          ~
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |   5   |       Starting n (-9)         | No. of Effec. Bits(21)|
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |0|0|0|0|0|0|0|0|1|1|1|1|1|1|1|1|1|0|0|0|0|  padding bits (0s)  |
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                • </artwork>
              • </figure>
            • <t>
              • In the above example, the starting n is selected to be the lowest nominal central frequency, i.e., -9. It is observed from the bitmap that n=-1 to 7 can be used to set up LSPs. Note other starting n values can be chosen to represent the bitmap; for example, the first available nominal central frequency (a.k.a., the first available basic frequency slot) can be chosen, and the SCSI will be expressed as the following:
              • </t>
            • <figure title="" suppress-title="false" align="left" alt="" width="" height="">
              • <artwork {http://www.w3.org/XML/1998/namespace}space="preserve" name="" type="" align="left" alt="" width="" height="">

                •   0                   1                   2                   3
                    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |          Type  = 11           |           Length              |
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |   Priority    |                   Reserved                    |
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   ~ Max Slot Width at Priority k  |   Unreserved Padding          ~
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |   5   |       Starting n (-1)         | No. of Effec. Bits(9)|
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |1|1|1|1|1|1|1|1|1|            padding bits (0s)                |
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                • </artwork>
              • </figure>
            • <!--[rfced] Is it clear what "This" refers to here? Please review and let us know if any updates are needed. Original This denotes that other than the advertised available nominal central frequencies, the other nominal central frequencies within the whole frequency range supported by the link are not available for flexi-grid LSP set up. >
            • <t>
              • This denotes thatencoding denotes that, other than the advertised available nominal central frequencies, the other nominal central frequencies within the whole frequency range supported by the link are not available for flexi-grid LSP setup.
              • </t>
            • <t>
              • If an LSP with slot width m equal to 1 is set up using this link, say using n=-1, then the SCSI information is updated to be the following:
              • </t>
            • <figure title="" suppress-title="false" align="left" alt="" width="" height="">
              • <artwork {http://www.w3.org/XML/1998/namespace}space="preserve" name="" type="" align="left" alt="" width="" height="">

                •   0                   1                   2                   3
                    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |          Type  = 11           |           Length              |
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |   Priority    |                   Reserved                    |
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   ~ Max Slot Width at Priority k  |   Unreserved Padding          ~
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |   5   |       Starting n (-1)         | No. of Effec. Bits(9)|
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |0|0|1|1|1|1|1|1|1|            padding bits (0s)                |
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                • </artwork>
              • </figure>
            • </section>
          • </section>
        • <section title="Extensions to the Port Label Restriction Sub-TLV" title="Extensions to the Port Label Restrictions Field" anchor="section-4.2" numbered="true" toc="default">
          • <t>
            • As described in <xref target="compliance" format="default" pageno="false"/>, a port that supports flexi-grid may support only a restricted subset of the full flexible grid. The Port Label Restrictions field is defined in , a port that supports flexi-grid may support only a restricted subset of the full flexible grid. <!--[rfced] Should the following be updated to "The Port Label Restrictions" (note the "s" at the end of "Restrictions") per RFC 7579? Also, should "Sub-TLV" or "field" be used? We note that RFC 7579 uses "field". Port Label Restriction Sub-TLV (in title of Section 4.2) Port Label Restriction field (in text in Section 4.2) --> The Port Label Restriction field is defined in The Port Label Restriction field is defined in <xref target="RFC7579" format="default" pageno="false"/>. It can be used to describe the label restrictions on a port and is carried in the top-level Link TLV as specified in . It can be used to describe the label restrictions on a port and is carried in the top-level Link TLV as specified in <xref target="RFC7580" format="default" pageno="false"/>. A new restriction type, the flexi-grid Restriction Type, is defined here to specify the restrictions on a port to support flexi-grid.. A new restriction type, the flexi-grid Restriction Type, is defined here to specify the restrictions on a port to support flexi-grid.
            • </t>
          • <figure title="" suppress-title="false" align="left" alt="" width="" height="">
            • <artwork {http://www.w3.org/XML/1998/namespace}space="preserve" name="" type="" align="left" alt="" width="" height="">

              •   0                   1                   2                   3
                  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                 | MatrixID      | RstType = 5   | Switching Cap |   Encoding    |
                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                 |  C.S. |     C.F.G     |    S.W.G      |     Reserved          |
                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                 |      Min Slot Width           |        Reserved               |
                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              • </artwork>
            • </figure>
          • <t>
            • MatrixID (8 bits): As defined in <xref target="RFC7579" format="default" pageno="false"/>..
            • </t>
          • <t>
            • RstType (Restriction Type, 8 bits): Takes the value of 5 to indicate the restrictions on a port to support flexi-grid.
            • </t>
          • <t>
            • Switching Cap (Switching Capability, 8 bits): As defined in <xref target="RFC7579" format="default" pageno="false"/>, MUST be consistent with the one specified in ISCD as described in , MUST be consistent with the one specified in ISCD as described in <xref target="flexi" format="default" pageno="false"/>..
            • </t>
          • <t>
            • Encoding (8 bits): As defined in <xref target="RFC7579" format="default" pageno="false"/>, MUST be consistent with the one specified in ISCD as described in , MUST be consistent with the one specified in ISCD as described in <xref target="flexi" format="default" pageno="false"/>..
            • </t>
          • <t>
            • C.S. (4 bits): As defined in <xref target="RFC7699" format="default" pageno="false"/>. For flexi-grid, it is 5 to denote 6.25 GHz.. For flexi-grid, it is 5 to denote 6.25 GHz.
            • </t>
          • <t>
            • C.F.G (Central Frequency Granularity, 8 bits): A positive integer. Its value indicates the multiple of C.S., in terms of central frequency granularity.
            • </t>
          • <t>
            • S.W.G (Slot Width Granularity, 8 bits): A positive integer. Its value indicates the multiple of 2*C.S., in terms of slot width granularity.
            • </t>
          • <!--[rfced] Please clarify the parenthetical here. Is the meaning "(in GHz)" or something else? Original Its value indicates the multiple of 2*C.S. (GHz), in terms of the supported minimal slot width. >
          • <t>
            • Min Slot Width (16 bits): A positive integer. Its value indicates the multiple of 2*C.S. (in GHz), in terms of the supported minimal slot width.
            • </t>
          • <t>
            • Reserved: The Reserved field MUST be set to zero on transmission and SHOULD be ignored on receipt.
            • </t>
          • </section>
        • </section>
      • <section title="IANA Considerations" anchor="section-5" numbered="true" toc="default">
        • <!--[rfced] We have included some specific questions about the IANA text in the document. In addition to responding to these questions, please review all of the IANA-related updates carefully and let us know if any updates are needed. a) We have updated the text in Section 5.2 to reflect the following per information from IANA (email dated 2018-01-25). Should the "Types for sub-TLVs of Flexi-Grid-LSC SCSI (Switch Capability-Specific Information)" registry be removed from <https://www.iana.org/assignments/ospf-traffic-eng-tlvs>? We've added the following entry to the "Generalized SCSI (Switching Capability Specific Information) TLV Types" registry: Value: 11 SCSI-TLV: Frequency availability bitmap Switching Type: 152 Reference: [RFC-ietf-ccamp-flexible-grid-ospf-ext-09] b) Is "Signal Type" correct here? Or should this read "Switching Type"? Current This document defines a new generalized SCSI sub-TLV that is carried in the Interface Switching Capability Descriptors [RFC4203] when the Signal Type is set to Flexi-Grid-LSC. >
        • <!--[rfced] We have included some specific questions about the IANA text in the document. In addition to responding to these questions, please review all of the IANA-related updates carefully and let us know if any updates are needed. a) We have updated the text in Section 5.2 to reflect the following per information from IANA (email dated 2018-01-25). Should the "Types for sub-TLVs of Flexi-Grid-LSC SCSI (Switch Capability-Specific Information)" registry be removed from <https://www.iana.org/assignments/ospf-traffic-eng-tlvs>? We've added the following entry to the "Generalized SCSI (Switching Capability Specific Information) TLV Types" registry: Value: 11 SCSI-TLV: Frequency availability bitmap Switching Type: 152 Reference: [RFC-ietf-ccamp-flexible-grid-ospf-ext-09] >
        • <section title="New ISCD Switching Type" anchor="section-5.1" numbered="true" toc="default">
          • <t>
            • IANA has made the following assignment in the "Switching Types" sub-registry of the "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Parameters" registry located at <eref target="https://www.iana.org/assignments/gmpls-sig-parameters"/>: :
            • </t>
          • <figure title="" suppress-title="false" align="left" alt="" width="" height="">
            • <artwork {http://www.w3.org/XML/1998/namespace}space="preserve" name="" type="" align="left" alt="" width="" height="">

              •       Value      Name                Reference 
                      -------    ----------------    ---------- 
                      152        Flexi-Grid-LSC      RFC 8363 
              • </artwork>
            • </figure>
          • </section>
        • <section title="New SCSI Type" anchor="section-5.2" numbered="true" toc="default">
          • <t>
            • This document defines a new generalized SCSI sub-TLV that is carried in the Interface Switching Capability Descriptors <xref target="RFC4203" format="default" pageno="false"/> when the Signalwitching Type is set to Flexi-Grid-LSC. when the Signalwitching Type is set to Flexi-Grid-LSC.
            • </t>
          • <t>
            • IANA has made the following assignment in the "Generalized SCSI (Switching Capability Specific Information) TLV Types" sub-registry <xref target="RFC8258" format="default" pageno="false"/> of the "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Parameters" registry located at of the "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Parameters" registry located at <eref target="https://www.iana.org/assignments/gmpls-sig-parameters"/>::
            • </t>
          • <figure title="" suppress-title="false" align="left" alt="" width="" height="">
            • <artwork {http://www.w3.org/XML/1998/namespace}space="preserve" name="" type="" align="left" alt="" width="" height="">

              • Value  SCSI-TLV                        Switching Type   Reference
                -----  -----------------------------   --------------   ---------
                 11    Frequency 
                aAvailability bBitmap   152              RFC 8363
              • </artwork>
            • </figure>
          • </section>
        • </section>
      • <section title="Security Considerations" anchor="section-8" numbered="true" toc="default">
        • <t>
          • This document extends <xref target="RFC4203" format="default" pageno="false"/> and and <xref target="RFC7580" format="default" pageno="false"/> to carry flexi-grid-specific information in OSPF Opaque LSAs. This document does not introduce any further security issues other than those discussed in to carry flexi-grid-specific information in OSPF Opaque LSAs. This document does not introduce any further security issues other than those discussed in <xref target="RFC3630" format="default" pageno="false"/> and and <xref target="RFC4203" format="default" pageno="false"/>. To be more specific, the security mechanisms described in . To be more specific, the security mechanisms described in <xref target="RFC2328" format="default" pageno="false"/>, which apply to Opaque LSAs carried in OSPF, still apply. An analysis of the OSPF security is provided in , which apply to Opaque LSAs carried in OSPF, still apply. An analysis of the OSPF security is provided in <xref target="RFC6863" format="default" pageno="false"/> and applies to the extensions to OSPF in this document as well. and applies to the extensions to OSPF in this document as well.
          • </t>
        • </section>
      • </middle>
    • <!--[rfced] We see RFC 3471 cited in the text. Should its corresponding reference entry be listed in the Normative or Informative References section? >
    • <!--[rfced] Would you like the references to be alphabetized or left in their current order? >
    • <back>
      • <references title="Normative References">
        • <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quote-title="true">
          • <front>
            • <title>
              • Key words for use in RFCs to Indicate Requirement Levels
              • </title>
            • <author initials="S." surname="Bradner" fullname="S. Bradner">
              • <organization/>
              • </author>
            • <date year="1997" month="March"/>
            • <abstract>
              • <t>
                • In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
                • </t>
              • </abstract>
            • </front>
          • <seriesInfo name="BCP" value="14"/>
          • <seriesInfo name="RFC" value="2119"/>
          • <seriesInfo name="DOI" value="10.17487/RFC2119"/>
          • </reference>
        • <reference anchor="RFC4203" target="https://www.rfc-editor.org/info/rfc4203" quote-title="true">
          • <front>
            • <title>
              • OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)
              • </title>
            • <author initials="K." surname="Kompella" fullname="K. Kompella" role="editor">
              • <organization/>
              • </author>
            • <author initials="Y." surname="Rekhter" fullname="Y. Rekhter" role="editor">
              • <organization/>
              • </author>
            • <date year="2005" month="October"/>
            • <abstract>
              • <t>
                • This document specifies encoding of extensions to the OSPF routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). [STANDARDS-TRACK]
                • </t>
              • </abstract>
            • </front>
          • <seriesInfo name="RFC" value="4203"/>
          • <seriesInfo name="DOI" value="10.17487/RFC4203"/>
          • </reference>
        • <reference anchor="RFC7579" target="https://www.rfc-editor.org/info/rfc7579" quote-title="true">
          • <front>
            • <title>
              • General Network Element Constraint Encoding for GMPLS-Controlled Networks
              • </title>
            • <author initials="G." surname="Bernstein" fullname="G. Bernstein" role="editor">
              • <organization/>
              • </author>
            • <author initials="Y." surname="Lee" fullname="Y. Lee" role="editor">
              • <organization/>
              • </author>
            • <author initials="D." surname="Li" fullname="D. Li">
              • <organization/>
              • </author>
            • <author initials="W." surname="Imajuku" fullname="W. Imajuku">
              • <organization/>
              • </author>
            • <author initials="J." surname="Han" fullname="J. Han">
              • <organization/>
              • </author>
            • <date year="2015" month="June"/>
            • <abstract>
              • <t>
                • Generalized Multiprotocol Label Switching (GMPLS) can be used to control a wide variety of technologies. In some of these technologies, network elements and links may impose additional routing constraints such as asymmetric switch connectivity, non-local label assignment, and label range limitations on links.
                • </t>
              • <t>
                • This document provides efficient, protocol-agnostic encodings for general information elements representing connectivity and label constraints as well as label availability. It is intended that protocol-specific documents will reference this memo to describe how information is carried for specific uses.
                • </t>
              • </abstract>
            • </front>
          • <seriesInfo name="RFC" value="7579"/>
          • <seriesInfo name="DOI" value="10.17487/RFC7579"/>
          • </reference>
        • <reference anchor="RFC7580" target="https://www.rfc-editor.org/info/rfc7580" quote-title="true">
          • <front>
            • <title>
              • OSPF-TE Extensions for General Network Element Constraints
              • </title>
            • <author initials="F." surname="Zhang" fullname="F. Zhang">
              • <organization/>
              • </author>
            • <author initials="Y." surname="Lee" fullname="Y. Lee">
              • <organization/>
              • </author>
            • <author initials="J." surname="Han" fullname="J. Han">
              • <organization/>
              • </author>
            • <author initials="G." surname="Bernstein" fullname="G. Bernstein">
              • <organization/>
              • </author>
            • <author initials="Y." surname="Xu" fullname="Y. Xu">
              • <organization/>
              • </author>
            • <date year="2015" month="June"/>
            • <abstract>
              • <t>
                • Generalized Multiprotocol Label Switching (GMPLS) can be used to control a wide variety of technologies including packet switching (e.g., MPLS), time division (e.g., Synchronous Optical Network / Synchronous Digital Hierarchy (SONET/SDH) and Optical Transport Network (OTN)), wavelength (lambdas), and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). In some of these technologies, network elements and links may impose additional routing constraints such as asymmetric switch connectivity, non- local label assignment, and label range limitations on links. This document describes Open Shortest Path First (OSPF) routing protocol extensions to support these kinds of constraints under the control of GMPLS.
                • </t>
              • </abstract>
            • </front>
          • <seriesInfo name="RFC" value="7580"/>
          • <seriesInfo name="DOI" value="10.17487/RFC7580"/>
          • </reference>
        • <reference anchor="RFC6205" target="https://www.rfc-editor.org/info/rfc6205" quote-title="true">
          • <front>
            • <title>
              • Generalized Labels for Lambda-Switch-Capable (LSC) Label Switching Routers
              • </title>
            • <author initials="T." surname="Otani" fullname="T. Otani" role="editor">
              • <organization/>
              • </author>
            • <author initials="D." surname="Li" fullname="D. Li" role="editor">
              • <organization/>
              • </author>
            • <date year="2011" month="March"/>
            • <abstract>
              • <t>
                • Technology in the optical domain is constantly evolving, and, as a consequence, new equipment providing lambda switching capability has been developed and is currently being deployed.
                • </t>
              • <t>
                • Generalized MPLS (GMPLS) is a family of protocols that can be used to operate networks built from a range of technologies including wavelength (or lambda) switching. For this purpose, GMPLS defined a wavelength label as only having significance between two neighbors. Global wavelength semantics are not considered.
                • </t>
              • <t>
                • In order to facilitate interoperability in a network composed of next generation lambda-switch-capable equipment, this document defines a standard lambda label format that is compliant with the Dense Wavelength Division Multiplexing (DWDM) and Coarse Wavelength Division Multiplexing (CWDM) grids defined by the International Telecommunication Union Telecommunication Standardization Sector. The label format defined in this document can be used in GMPLS signaling and routing protocols. [STANDARDS-TRACK]
                • </t>
              • </abstract>
            • </front>
          • <seriesInfo name="RFC" value="6205"/>
          • <seriesInfo name="DOI" value="10.17487/RFC6205"/>
          • </reference>
        • <reference anchor="RFC7699" target="https://www.rfc-editor.org/info/rfc7699" quote-title="true">
          • <front>
            • <title>
              • Generalized Labels for the Flexi-Grid in Lambda Switch Capable (LSC) Label Switching Routers
              • </title>
            • <author initials="A." surname="Farrel" fullname="A. Farrel">
              • <organization/>
              • </author>
            • <author initials="D." surname="King" fullname="D. King">
              • <organization/>
              • </author>
            • <author initials="Y." surname="Li" fullname="Y. Li">
              • <organization/>
              • </author>
            • <author initials="F." surname="Zhang" fullname="F. Zhang">
              • <organization/>
              • </author>
            • <date year="2015" month="November"/>
            • <abstract>
              • <t>
                • GMPLS supports the description of optical switching by identifying entries in fixed lists of switchable wavelengths (called grids) through the encoding of lambda labels. Work within the ITU-T Study Group 15 has defined a finer-granularity grid, and the facility to flexibly select different widths of spectrum from the grid. This document defines a new GMPLS lambda label format to support this flexi-grid.
                • </t>
              • <t>
                • This document updates RFCs 3471 and 6205 by introducing a new label format.
                • </t>
              • </abstract>
            • </front>
          • <seriesInfo name="RFC" value="7699"/>
          • <seriesInfo name="DOI" value="10.17487/RFC7699"/>
          • </reference>
        • <reference anchor="RFC8258" target="https://www.rfc-editor.org/info/rfc8258" quote-title="true">
          • <front>
            • <title>
              • Generalized SCSI: A Generic Structure for Interface Switching Capability Descriptor (ISCD) Switching Capability Specific Information (SCSI)
              • </title>
            • <author initials="D." surname="Ceccarelli" fullname="D. Ceccarelli">
              • <organization/>
              • </author>
            • <author initials="L." surname="Berger" fullname="L. Berger">
              • <organization/>
              • </author>
            • <date year="2017" month="October"/>
            • <abstract>
              • <t>
                • This document defines a generic information structure for information carried in routing protocol Interface Switching Capability Descriptor (ISCD) Switching Capability Specific Information (SCSI) fields. This "Generalized SCSI" can be used with routing protocols that define GMPLS ISCDs and any specific technology. This document does not modify any existing technology-specific formats and is defined for use in conjunction with new GMPLS Switching Capability types. The context for this document is Generalized MPLS, and the reader is expected to be familiar with the GMPLS architecture and associated protocol standards.
                • </t>
              • </abstract>
            • </front>
          • <seriesInfo name="RFC" value="8258"/>
          • <seriesInfo name="DOI" value="10.17487/RFC8258"/>
          • </reference>
        • <reference anchor="RFC3471" target="https://www.rfc-editor.org/info/rfc3471" quote-title="true">
          • <front>
            • <title>
              • Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description
              • </title>
            • <author initials="L." surname="Berger" fullname="L. Berger" role="editor">
              • <organization/>
              • </author>
            • <date year="2003" month="January"/>
            • <abstract>
              • <t>
                • This document describes extensions to Multi-Protocol Label Switching (MPLS) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a functional description of the extensions. Protocol specific formats and mechanisms, and technology specific details are specified in separate documents. [STANDARDS-TRACK]
                • </t>
              • </abstract>
            • </front>
          • <seriesInfo name="RFC" value="3471"/>
          • <seriesInfo name="DOI" value="10.17487/RFC3471"/>
          • </reference>
        • <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
          • <front>
            • <title>
              • Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
              • </title>
            • <author initials="B." surname="Leiba" fullname="B. Leiba">
              • <organization/>
              • </author>
            • <date year="2017" month="May"/>
            • <abstract>
              • <t>
                • RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.
                • </t>
              • </abstract>
            • </front>
          • <seriesInfo name="BCP" value="14"/>
          • <seriesInfo name="RFC" value="8174"/>
          • <seriesInfo name="DOI" value="10.17487/RFC8174"/>
          • </reference>
        • <reference anchor="G.694.1" target="https://www.itu.int/rec/T-REC-G.694.1/en" quote-title="true">
          • <front>
            • <title>
              • Spectral grids for WDM applications: DWDM frequency grid
              • </title>
            • <author>
              • <organization abbrev="ITU-T">
                • International Telecommunication Union
                • </organization>
              • </author>
            • <date year="2012" month="February"/>
            • </front>
          • <seriesInfo name="ITU-T Recommendation" value="G.694.1"/>
          • </reference>
        • </references>
      • <references title="Informative References">
        • <reference anchor="RFC6163" target="https://www.rfc-editor.org/info/rfc6163" quote-title="true">
          • <front>
            • <title>
              • Framework for GMPLS and Path Computation Element (PCE) Control of Wavelength Switched Optical Networks (WSONs)
              • </title>
            • <author initials="Y." surname="Lee" fullname="Y. Lee" role="editor">
              • <organization/>
              • </author>
            • <author initials="G." surname="Bernstein" fullname="G. Bernstein" role="editor">
              • <organization/>
              • </author>
            • <author initials="W." surname="Imajuku" fullname="W. Imajuku">
              • <organization/>
              • </author>
            • <date year="2011" month="April"/>
            • <abstract>
              • <t>
                • This document provides a framework for applying Generalized Multi-Protocol Label Switching (GMPLS) and the Path Computation Element (PCE) architecture to the control of Wavelength Switched Optical Networks (WSONs). In particular, it examines Routing and Wavelength Assignment (RWA) of optical paths.
                • </t>
              • <t>
                • This document focuses on topological elements and path selection constraints that are common across different WSON environments; as such, it does not address optical impairments in any depth. This document is not an Internet Standards Track specification; it is published for informational purposes.
                • </t>
              • </abstract>
            • </front>
          • <seriesInfo name="RFC" value="6163"/>
          • <seriesInfo name="DOI" value="10.17487/RFC6163"/>
          • </reference>
        • <reference anchor="RFC7792" target="https://www.rfc-editor.org/info/rfc7792" quote-title="true">
          • <front>
            • <title>
              • RSVP-TE Signaling Extensions in Support of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks
              • </title>
            • <author initials="F." surname="Zhang" fullname="F. Zhang">
              • <organization/>
              • </author>
            • <author initials="X." surname="Zhang" fullname="X. Zhang">
              • <organization/>
              • </author>
            • <author initials="A." surname="Farrel" fullname="A. Farrel">
              • <organization/>
              • </author>
            • <author initials="O." surname="Gonzalez de Dios" fullname="O. Gonzalez de Dios">
              • <organization/>
              • </author>
            • <author initials="D." surname="Ceccarelli" fullname="D. Ceccarelli">
              • <organization/>
              • </author>
            • <date year="2016" month="March"/>
            • <abstract>
              • <t>
                • This memo describes the extensions to the Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling protocol to support Label Switched Paths (LSPs) in a GMPLS-controlled network that includes devices using the flexible optical grid.
                • </t>
              • </abstract>
            • </front>
          • <seriesInfo name="RFC" value="7792"/>
          • <seriesInfo name="DOI" value="10.17487/RFC7792"/>
          • </reference>
        • <reference anchor="RFC7698" target="https://www.rfc-editor.org/info/rfc7698" quote-title="true">
          • <front>
            • <title>
              • Framework and Requirements for GMPLS-Based Control of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks
              • </title>
            • <author initials="O." surname="Gonzalez de Dios" fullname="O. Gonzalez de Dios" role="editor">
              • <organization/>
              • </author>
            • <author initials="R." surname="Casellas" fullname="R. Casellas" role="editor">
              • <organization/>
              • </author>
            • <author initials="F." surname="Zhang" fullname="F. Zhang">
              • <organization/>
              • </author>
            • <author initials="X." surname="Fu" fullname="X. Fu">
              • <organization/>
              • </author>
            • <author initials="D." surname="Ceccarelli" fullname="D. Ceccarelli">
              • <organization/>
              • </author>
            • <author initials="I." surname="Hussain" fullname="I. Hussain">
              • <organization/>
              • </author>
            • <date year="2015" month="November"/>
            • <abstract>
              • <t>
                • To allow efficient allocation of optical spectral bandwidth for systems that have high bit-rates, the International Telecommunication Union Telecommunication Standardization Sector (ITU-T) has extended its Recommendations G.694.1 and G.872 to include a new Dense Wavelength Division Multiplexing (DWDM) grid by defining a set of nominal central frequencies, channel spacings, and the concept of the "frequency slot". In such an environment, a data-plane connection is switched based on allocated, variable-sized frequency ranges within the optical spectrum, creating what is known as a flexible grid (flexi-grid).
                • </t>
              • <t>
                • Given the specific characteristics of flexi-grid optical networks and their associated technology, this document defines a framework and the associated control-plane requirements for the application of the existing GMPLS architecture and control-plane protocols to the control of flexi-grid DWDM networks. The actual extensions to the GMPLS protocols will be defined in companion documents.
                • </t>
              • </abstract>
            • </front>
          • <seriesInfo name="RFC" value="7698"/>
          • <seriesInfo name="DOI" value="10.17487/RFC7698"/>
          • </reference>
        • <reference anchor="RFC7688" target="https://www.rfc-editor.org/info/rfc7688" quote-title="true">
          • <front>
            • <title>
              • GMPLS OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks
              • </title>
            • <author initials="Y." surname="Lee" fullname="Y. Lee" role="editor">
              • <organization/>
              • </author>
            • <author initials="G." surname="Bernstein" fullname="G. Bernstein" role="editor">
              • <organization/>
              • </author>
            • <date year="2015" month="November"/>
            • <abstract>
              • <t>
                • This document provides Generalized Multiprotocol Label Switching (GMPLS) Open Shortest Path First (OSPF) routing enhancements to support signal compatibility constraints associated with Wavelength Switched Optical Network (WSON) elements. These routing enhancements are applicable in common optical or hybrid electro-optical networks where not all the optical signals in the network are compatible with all network elements participating in the network.
                • </t>
              • <t>
                • This compatibility constraint model is applicable to common optical or hybrid electro-optical systems such as optical-electronic-optical (OEO) switches, regenerators, and wavelength converters, since such systems can be limited to processing only certain types of WSON signals.
                • </t>
              • </abstract>
            • </front>
          • <seriesInfo name="RFC" value="7688"/>
          • <seriesInfo name="DOI" value="10.17487/RFC7688"/>
          • </reference>
        • <reference anchor="RFC2328" target="https://www.rfc-editor.org/info/rfc2328" quote-title="true">
          • <front>
            • <title>
              • OSPF Version 2
              • </title>
            • <author initials="J." surname="Moy" fullname="J. Moy">
              • <organization/>
              • </author>
            • <date year="1998" month="April"/>
            • <abstract>
              • <t>
                • This memo documents version 2 of the OSPF protocol. OSPF is a link- state routing protocol. [STANDARDS-TRACK]
                • </t>
              • </abstract>
            • </front>
          • <seriesInfo name="STD" value="54"/>
          • <seriesInfo name="RFC" value="2328"/>
          • <seriesInfo name="DOI" value="10.17487/RFC2328"/>
          • </reference>
        • <reference anchor="RFC3630" target="https://www.rfc-editor.org/info/rfc3630" quote-title="true">
          • <front>
            • <title>
              • Traffic Engineering (TE) Extensions to OSPF Version 2
              • </title>
            • <author initials="D." surname="Katz" fullname="D. Katz">
              • <organization/>
              • </author>
            • <author initials="K." surname="Kompella" fullname="K. Kompella">
              • <organization/>
              • </author>
            • <author initials="D." surname="Yeung" fullname="D. Yeung">
              • <organization/>
              • </author>
            • <date year="2003" month="September"/>
            • <abstract>
              • <t>
                • This document describes extensions to the OSPF protocol version 2 to support intra-area Traffic Engineering (TE), using Opaque Link State Advertisements.
                • </t>
              • </abstract>
            • </front>
          • <seriesInfo name="RFC" value="3630"/>
          • <seriesInfo name="DOI" value="10.17487/RFC3630"/>
          • </reference>
        • <reference anchor="RFC6863" target="https://www.rfc-editor.org/info/rfc6863" quote-title="true">
          • <front>
            • <title>
              • Analysis of OSPF Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guide
              • </title>
            • <author initials="S." surname="Hartman" fullname="S. Hartman">
              • <organization/>
              • </author>
            • <author initials="D." surname="Zhang" fullname="D. Zhang">
              • <organization/>
              • </author>
            • <date year="2013" month="March"/>
            • <abstract>
              • <t>
                • This document analyzes OSPFv2 and OSPFv3 according to the guidelines set forth in Section 4.2 of the "Keying and Authentication for Routing Protocols (KARP) Design Guidelines" (RFC 6518). Key components of solutions to gaps identified in this document are already underway.
                • </t>
              • </abstract>
            • </front>
          • <seriesInfo name="RFC" value="6863"/>
          • <seriesInfo name="DOI" value="10.17487/RFC6863"/>
          • </reference>
        • </references>
      • <section title="Acknowledgments" anchor="acks" numbered="no" toc="default">
        • <t>
          • This work was supported in part by the FP-7 IDEALIST project under grant agreement number 317999.
          • </t>
        • <t>
          • This work was supported in part by NSFC Project 61201260.
          • </t>
        • </section>
      • <section title="Contributors" anchor="contributors" numbered="no" toc="default">
        • <figure title="" suppress-title="false" align="left" alt="" width="" height="">
          • <artwork {http://www.w3.org/XML/1998/namespace}space="preserve" name="" type="" align="left" alt="" width="" height="">

            • Adrian Farrel
              Juniper Networks

              Email: afarrel@juniper.net


              Fatai Zhang
              Huawei Technologies

              Email: zhangfatai@huawei.com


              Lei Wang
              Beijing University of Posts and Telecommunications

              Email: wang.lei@bupt.edu.cn


              Guoying Zhang
              China Academy of Information and Communication Technology

              Email: zhangguoying@ritt.cn
            • </artwork>
          • </figure>
        • </section>
      • </back>
    • </rfc>