<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
    which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
    There has to be one entity for each item to be referenced. 
    An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM
                     "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
    please see http://xml.resource.org/authoring/README.html. -->


<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>

<rfc category="std"
     docName="draft-hussain-ccamp-flexe-signaling-extensions-00"
     ipr="trust200902">

    <!-- ***** FRONT MATTER ***** -->

    <front>
        <title abbrev="FlexE Signaling">FlexE GMPLS Signaling Extensions
        </title>

        <author fullname="Iftekhar Hussain"
                initials="I."
                surname="Hussain">
            <organization>Infinera Corp</organization>
            <address>
                <postal>
                    <street> 169 Java Drive</street>
                    <city>Sunnyvale</city>
                    <region>CA</region>
                    <code>94089</code>
                    <country>USA</country>
                </postal>
                <phone>+1-408-572-5200</phone>
                <email>IHussain@infinera.com</email>
            </address>
        </author>
        <author fullname="Radha Valiveti"
                initials="R.S."
                surname="Valiveti">
            <organization>Infinera Corp</organization>
            <address>
                <postal>
                    <street> 169 Java Drive</street>
                    <city>Sunnyvale</city>
                    <region>CA</region>
                    <code>94089</code>
                    <country>USA</country>
                </postal>
                <phone>+1-408-572-5200</phone>
                <email>rvaliveti@infinera.com</email>
            </address>
        </author>
        <author fullname="Khuzema Pithewan"
                initials="K."
                surname="Pithewan">
            <organization>Infinera Corp</organization>
            <address>
                <postal>
                    <street> 169 Java Drive</street>
                    <city>Sunnyvale</city>
                    <region>CA</region>
                    <code>94089</code>
                    <country>USA</country>
                </postal>
                <phone>+1-408-572-5200</phone>
                <email>kpithewan@infinera.com</email>
            </address>
        </author>


        <date month="July"
              year="2016"/>

        <!-- Meta-data Declarations -->

        <area>General</area>
        <workgroup>Internet Engineering Task Force</workgroup>
        <keyword>template</keyword>

        <abstract>
            <t>This document describes GMPLS signaling extensions for configuring a FlexE group and adding or removing FlexE client(s) to a FlexE group <xref target="OIFFLEXE1"> </xref>.
            </t>
        </abstract>
    </front>

    <middle>
        <section title="Introduction"
                 anchor="section-introduction">
            <t> 
			This document describes GMPLS signaling extensions for configuring a FlexE group and adding or removing FlexE client(s) to a FlexE group <xref target="OIFFLEXE1"> </xref>.
            The various usecases that arise when transporting Flexible Rate Ethernet signals in Optical transport networks are described in <xref target="FLEXEUSECASES"> </xref>. The routing extensions in support of carrying  
            link state information for a FlexE group are described in <xref target="FLEXEROUTING"> </xref>.
            </t>

            <section title="Requirements Language">
                <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
                    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
                    document are to be interpreted as described in <xref target="RFC2119">RFC 2119</xref>.</t>
            </section>
        </section>

        <section title="Terminology">
            <t><list style="letters">
                    <t>Ethernet PHY: an entity representing 100G-R Physical Coding Sublayer (PCS), Physical Media Attachment (PMA), and Physical Media Dependent (PMD) layers. </t>
                    <t>FlexE Group: a group of from 1 to 254 bonded Ethernet PHYs.</t>
                    <t>FlexE Client: an Ethernet flow based on a MAC data rate that may or may not correspond to any Ethernet PHY rate (e.g., 10, 40, m x 25 Gb/s). </t>
                    <t>FlexE Shim: the layer that maps or demaps the FlexE clients carried over a FlexE group. </t>
                    <t>FlexE Calendar: Representation of a FlexE group of n PHYs as a calendar of 20n slots logical length with 20 slots per PHY for scheduling of slots (i.e., a PHY bandwidth) among the FlexE clients. </t>
                </list></t>
        </section>

        <?rfc needLines="8" ?>

        <section title="Protocol Extensions">
		<t> This section describes extensions to RSVP-TE signaling for GMPLS <xref target="RFC3473"> </xref> to support FlexE.</t>
            <section title="Generalized Label"
                     anchor="generalized_label">
                <t> <xref target="fig_gen_label"> </xref> shows the proposed FlexE generalized label format to be carried in the Generalized Label Request <xref target="RFC3471"> </xref>. 
				This document proposes LSP Encoding type = Flexible Ethernet (FlexE) (a new value of 15 as defined in <xref target="FLEXEROUTING"> </xref>), Switching type = Layer-2 Switch Capable (L2SC) (a value of 51 as defined in <xref target="RFC3471"> </xref>) and  Generalized PID (G-PID) = FlexE (a new value of 71 as defined in this document). 
				 A FlexE Group consists of 1 to n 100GBASE-R Ethernet PHYs. The label lists all PHY numbers (1 to 254) that are members of the FlexE group. For a client, the label also lists calendar slots in each member PHY that are assigned to the client. 
				      </t>
                <figure title = "FlexE Generalized Label"
                                align="center"
                                anchor="fig_gen_label">
                    <artwork align="center"><![CDATA[
 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
+---------------------------------------+-----------------------+
|         FlexE Group Number            |        Reserved       |
+---------------------------------------+-----------------------+
| Client (being added or removed) |  Flags                      |
+----------------+--------------------------------+-------------+
|  PHY Number    |     Rate       | Granularity   | Unav. Slots |
+----------------+----------------+-------------+-+-------------+
|  Slot Map (0 to 19 slot for 100G PHY)         |   Reserved    |
+-----------------------------------------------+---------------+
|                           ......                              |
+----------------+----------------+---------------+-------------+
|   PHY Number   |     Rate       |  Granularity  | Unav.  Slots|
+----------------+----------------+-------------+-+-------------+
|  Slot Map (0 to 19 slot for 100G PHY)         |   Reserved    |
+-----------------------------------------------+---------------+
|                           ......                              |
+---------------------------------------------------------------+
		 
                    ]]>
                    </artwork>
                </figure>  
				<t><list style="">
				<t> FlexE Group Number (20 bits) fields allows to check that the correct PHY is being
                   received from the correct group number <xref target="OIFFLEXE1"> </xref>.
                 </t>
				<t> Client (16 bits) field indicates which of the FlexE clients is mapped into a given calendar slot
                    in the A and B calendar configurations for the sub-calendar carried over that PHY <xref target="OIFFLEXE1"> </xref>.
				</t> 
				<t>
				   Flags (8 bits) field is reserved for future use. <xref target="OIFFLEXE1"> </xref>.
				</t>
				<t>
				  PHY Number (8 bits) field is used to identify PHY by a number in the 1-254 range <xref target="OIFFLEXE1"> </xref>.
				</t>
				<t>
				  Rate (8 bits) field is used to specify rate of the given PHY number. Currently <xref target="OIFFLEXE1"> </xref> has defined a 100G PHY rate. In the future, this field may be used to indicate other PHY rates (e.g., 400G).
				</t>
				<t>
				  Granularity (8 bits) field is used to indicate granularity of the FlexE calendar. Currently <xref target="OIFFLEXE1"> </xref> has defined 5G granularity. In future, this field can
   have additional values, as further granularity are defined.
				</t>
				<t>
				 Slot Map (20 bits) field is used to indicate which calendar slots of the associated PHY number is assigned to a given FlexE client. For a PHY with a rate of 100G and granularity of 5G, the slot map consists of 20 slots (0-19 range). In the future, when other PHY rates and/or calender granularities are defined, the slot map size for a PHY can be derived based on the Rate and Granularity fields values.
				</t>
				<t> Unavailable Slots (8 bits) field is used to indicate the number of unavailable calendar slots (0-19 range) for example due to transport network constraints (i.e., no FlexE client
                    should be assigned to the unused slots). Unavailable slots are placed
at the end of each relevant sub-calendar (i.e., the highest numbered slots) <xref target="OIFFLEXE1"> </xref>.
                </t>
				
				 </list></t>
            </section>
             
			<section title="FlexE Group Initial Setup"
                     anchor="flexg_setup">
			<t>
			Suppose it is desired to establish a FlexE group containing two 100G PHYs between node A and B. This can be accomplished by having node A send a RSVP-TE message containing a FlexE generalized label to node B with the following field values:
			 <list style="letters">
			   <t> FlexE Group Number = 100 (say), Client = 0x0000 (i.e., no client) </t>
			   <t> First PHY Number = 5 (say), Rate= 100G, Granularity=5G, Unavailable Slots=0, Slot Map = 0-19 bit set to 0 (i.e., all slots available)</t>
			   <t> Second PHY Number = 7 (say), Rate-100G, Granularity=5G, Unavailable Slots=0, Slot Map = 0-19 bit set to 0 (i.e., all slots available)</t>
			 </list>
			 Thus both ends will have the same FlexE group configuration and the FlexE group can be brought in service. 
			</t>
			</section>
			
			<section title="FlexE Client Setup"
                     anchor="client_setup">
			<t>
			Suppose it is desired to establish a FlexE client of rate 50G node A and B to the FlexE group created in the <xref target="flexg_setup"> </xref>. This can be accomplished by having node A send a RSVP-TE message containing a FlexE generalized label to node B with the following field values:
			 <list style="letters">
			   <t> FlexE Group Number = 100, Client = 0x0001 (i.e., client id = 1) </t>
			   <t> First PHY Number = 5 , Rate= 100G, Granularity=5G, Unavailable Slots=0, Slot Map = 0 to 4 bit set to 1 (i.e., 25G on this PHY)</t>
			   <t> Second PHY Number = 7, Rate-100G, Granularity=5G, Unavailable Slots=0, Slot Map = 0 to 4 bit set to 1 (i.e., 25G on this PHY)</t>
			 </list>
			  
			</t>
			</section>
            <section title="Related Work" anchor="comparison">
			 <t>
			 The generalized label described in <xref target="FLEXESIGNAL"> </xref> is limited to 100G PHY only. In contrast, the generalized label proposed in this document is extendible to PHY rates beyond 100G. Specifically, 
			 the label proposed in this document introduces additional per PHY fields, namely, Rate and Granularity. This enables to drive per PHY calendar size information in the face of calendar granularity and/or calendar size changes that might be required for PHY rates beyond 100G (such as 400G).
			 </t>
			 </section>
        </section>

        <section anchor="Acknowledgements"
                 title="Acknowledgements">
            <t></t>
        </section>

        <!-- Possibly a 'Contributors' section ... -->

        <section anchor="IANA"
                 title="IANA Considerations">
            <t>This memo includes no request to IANA.</t>
        </section>

        <section anchor="Security"
                 title="Security Considerations">
            <t>None.</t>
        </section>
    </middle>

    <!--  *****BACK MATTER ***** -->

    <back>
        <!-- References split into informative and normative -->

        <!-- There are 2 ways to insert reference entries from the citation libraries:
    1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
    2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
       (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

    Both are cited textually in the same manner: by using xref elements.
    If you use the PI option, xml2rfc will, by default, try to find included files in the same
    directory as the including file. You can also define the XML_LIBRARY environment variable
    with a value containing a set of directories to search.  These can be either in the local
    filing system or remote ones accessed by http (http://domain/dir/... ).-->

        <references title="Normative References">
            <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
            &RFC2119;

            <reference anchor="OIFFLEXE1">
                <!-- the following is the minimum to make xml2rfc happy -->
                <front>
                    <title>FLex Ethernet Implementation Agreement Version 1.0 (OIF-FLEXE-01.0)</title>
                    <author>
                        <organization> OIF</organization>
                    </author>
                    <date year="2016"
                          month="March"/>
                </front>
            </reference>

            
			
			
			<reference anchor="FLEXEUSECASES">
                <!-- the following is the minimum to make xml2rfc happy -->
                <front>
                    <title>FlexE Usecases, draft-hussain-ccamp-flexe-usecases</title>
                    <author>
                        <organization> IETF</organization>
                    </author>
                    <date year="2016"
                          month="June"/>
                </front>
            </reference>
			
			<reference anchor="FLEXEROUTING">
                <!-- the following is the minimum to make xml2rfc happy -->
                <front>
                    <title>FlexE GMPLS Routing Extension, draft-pithewan-ccamp-flexe-routing-extensions</title>
                    <author>
                        <organization> IETF</organization>
                    </author>
                    <date year="2016"
                          month="June"/>
                </front>
            </reference>
			
			<reference anchor="RFC3473">
                <!-- the following is the minimum to make xml2rfc happy -->
                <front>
                    <title>Generalized Multi-Protocol Label Switching (GMPLS) Signaling
 Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions, RFC3473</title>
                    <author>
                        <organization> IETF</organization>
                    </author>
                    <date year="2003"
                          month="January"/>
                </front>
            </reference>
			
			<reference anchor="RFC3471">
                <!-- the following is the minimum to make xml2rfc happy -->
                <front>
                    <title>G Generalized Multi-Protocol Label Switching (GMPLS)
                    Signaling Functional Description, RFC3471</title>
                    <author>
                        <organization> IETF</organization>
                    </author>
                    <date year="2003"
                          month="January"/>
                </front>
            </reference>
			
			<reference anchor="FLEXESIGNAL">
                <!-- the following is the minimum to make xml2rfc happy -->
                <front>
                    <title> RSVP-TE Signaling Extensions in support of Flexible Ethernet networks, draft-wang-ccamp-flexe-signaling-00</title>
                    <author>
                        <organization> IETF</organization>
                    </author>
                    <date year="2016"
                          month="March"/>
                </front>
            </reference>
			
			
        </references>
		
        <references title="Informative References">
            <reference anchor="OIFMLG3">
                <!-- the following is the minimum to make xml2rfc happy -->
                <front>
                    <title>Multi-Lane Gearbox Implementation Agreement Version 3.0 (OIF-MLG-3.0)</title>
                    <author>
                        <organization> OIF</organization>
                    </author>
                    <date year="2016"
                          month="April"/>
                </front>
            </reference>
        </references>

        <section anchor="app-additional"
                 title="Additional Stuff">
            <t>This becomes an Appendix.</t>
        </section>
    </back>
</rfc>
