Internet Engineering Task Force                               I. Hussain
Internet-Draft                                               R. Valiveti
Intended status: Standards Track                             K. Pithewan
Expires: January 8, 2017                                   Infinera Corp
                                                            July 7, 2016


                    FlexE GMPLS Signaling Extensions
           draft-hussain-ccamp-flexe-signaling-extensions-00

Abstract

   This document describes GMPLS signaling extensions for configuring a
   FlexE group and adding or removing FlexE client(s) to a FlexE group
   [OIFFLEXE1].

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 8, 2017.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.




Hussain, et al.          Expires January 8, 2017                [Page 1]

Internet-Draft               FlexE Signaling                   July 2016


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Protocol Extensions . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Generalized Label . . . . . . . . . . . . . . . . . . . .   3
     3.2.  FlexE Group Initial Setup . . . . . . . . . . . . . . . .   4
     3.3.  FlexE Client Setup  . . . . . . . . . . . . . . . . . . .   5
     3.4.  Related Work  . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Appendix A.  Additional Stuff . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   This document describes GMPLS signaling extensions for configuring a
   FlexE group and adding or removing FlexE client(s) to a FlexE group
   [OIFFLEXE1].  The various usecases that arise when transporting
   Flexible Rate Ethernet signals in Optical transport networks are
   described in [FLEXEUSECASES].  The routing extensions in support of
   carrying link state information for a FlexE group are described in
   [FLEXEROUTING].

1.1.  Requirements Language

   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 RFC 2119 [RFC2119].

2.  Terminology

   a.  Ethernet PHY: an entity representing 100G-R Physical Coding
       Sublayer (PCS), Physical Media Attachment (PMA), and Physical
       Media Dependent (PMD) layers.

   b.  FlexE Group: a group of from 1 to 254 bonded Ethernet PHYs.

   c.  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).





Hussain, et al.          Expires January 8, 2017                [Page 2]

Internet-Draft               FlexE Signaling                   July 2016


   d.  FlexE Shim: the layer that maps or demaps the FlexE clients
       carried over a FlexE group.

   e.  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.

3.  Protocol Extensions

   This section describes extensions to RSVP-TE signaling for GMPLS
   [RFC3473] to support FlexE.

3.1.  Generalized Label

   Figure 1 shows the proposed FlexE generalized label format to be
   carried in the Generalized Label Request [RFC3471].  This document
   proposes LSP Encoding type = Flexible Ethernet (FlexE) (a new value
   of 15 as defined in [FLEXEROUTING]), Switching type = Layer-2 Switch
   Capable (L2SC) (a value of 51 as defined in [RFC3471]) 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.

      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    |
     +-----------------------------------------------+---------------+
     |                           ......                              |
     +---------------------------------------------------------------+



                     Figure 1: FlexE Generalized Label



Hussain, et al.          Expires January 8, 2017                [Page 3]

Internet-Draft               FlexE Signaling                   July 2016


      FlexE Group Number (20 bits) fields allows to check that the
      correct PHY is being received from the correct group number
      [OIFFLEXE1].

      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
      [OIFFLEXE1].

      Flags (8 bits) field is reserved for future use.  [OIFFLEXE1].

      PHY Number (8 bits) field is used to identify PHY by a number in
      the 1-254 range [OIFFLEXE1].

      Rate (8 bits) field is used to specify rate of the given PHY
      number.  Currently [OIFFLEXE1] has defined a 100G PHY rate.  In
      the future, this field may be used to indicate other PHY rates
      (e.g., 400G).

      Granularity (8 bits) field is used to indicate granularity of the
      FlexE calendar.  Currently [OIFFLEXE1] has defined 5G granularity.
      In future, this field can have additional values, as further
      granularity are defined.

      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.

      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) [OIFFLEXE1].

3.2.  FlexE Group Initial Setup

   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:

   a.  FlexE Group Number = 100 (say), Client = 0x0000 (i.e., no client)




Hussain, et al.          Expires January 8, 2017                [Page 4]

Internet-Draft               FlexE Signaling                   July 2016


   b.  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)

   c.  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)

   Thus both ends will have the same FlexE group configuration and the
   FlexE group can be brought in service.

3.3.  FlexE Client Setup

   Suppose it is desired to establish a FlexE client of rate 50G node A
   and B to the FlexE group created in the Section 3.2.  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:

   a.  FlexE Group Number = 100, Client = 0x0001 (i.e., client id = 1)

   b.  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)

   c.  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)

3.4.  Related Work

   The generalized label described in [FLEXESIGNAL] 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).

4.  Acknowledgements

5.  IANA Considerations

   This memo includes no request to IANA.

6.  Security Considerations

   None.





Hussain, et al.          Expires January 8, 2017                [Page 5]

Internet-Draft               FlexE Signaling                   July 2016


7.  References

7.1.  Normative References

   [FLEXEROUTING]
              IETF, "FlexE GMPLS Routing Extension, draft-pithewan-
              ccamp-flexe-routing-extensions", June 2016.

   [FLEXESIGNAL]
              IETF, "RSVP-TE Signaling Extensions in support of Flexible
              Ethernet networks, draft-wang-ccamp-flexe-signaling-00",
              March 2016.

   [FLEXEUSECASES]
              IETF, "FlexE Usecases, draft-hussain-ccamp-flexe-
              usecases", June 2016.

   [OIFFLEXE1]
              OIF, "FLex Ethernet Implementation Agreement Version 1.0
              (OIF-FLEXE-01.0)", March 2016.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC3471]  IETF, "G Generalized Multi-Protocol Label Switching
              (GMPLS) Signaling Functional Description, RFC3471",
              January 2003.

   [RFC3473]  IETF, "Generalized Multi-Protocol Label Switching (GMPLS)
              Signaling Resource ReserVation Protocol-Traffic
              Engineering (RSVP-TE) Extensions, RFC3473", January 2003.

7.2.  Informative References

   [OIFMLG3]  OIF, "Multi-Lane Gearbox Implementation Agreement Version
              3.0 (OIF-MLG-3.0)", April 2016.

Appendix A.  Additional Stuff

   This becomes an Appendix.

Authors' Addresses







Hussain, et al.          Expires January 8, 2017                [Page 6]

Internet-Draft               FlexE Signaling                   July 2016


   Iftekhar Hussain
   Infinera Corp
   169 Java Drive
   Sunnyvale, CA  94089
   USA

   Phone: +1-408-572-5200
   Email: IHussain@infinera.com


   Radha Valiveti
   Infinera Corp
   169 Java Drive
   Sunnyvale, CA  94089
   USA

   Phone: +1-408-572-5200
   Email: rvaliveti@infinera.com


   Khuzema Pithewan
   Infinera Corp
   169 Java Drive
   Sunnyvale, CA  94089
   USA

   Phone: +1-408-572-5200
   Email: kpithewan@infinera.com























Hussain, et al.          Expires January 8, 2017                [Page 7]