[Search] [txt|xml|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Internet Engineering Task Force                                  Q. Wang
Internet-Draft                                                       ZTE
Intended status: Informational                                  H. Zheng
Expires: May 3, 2018                                              Huawei
                                                             R. Valiveti
                                                           Infinera Corp
                                                             H. Helvoort
                                                         Hai Gaoming B.V
                                                                  Z. Ali
                                                                   Cisco
                                                        October 30, 2017


            GMPLS Routing and Signaling Framework for B100G
                  draft-merge-ccamp-100g-signalling-00

Abstract

   This document provides extensions to GMPLS signalling to control the
   B100G OTUCn/ODUCn Network, as a result of the introduction of new
   beyond 100G OTUCn/ODUCn signals and features in ITU-T Recommendation
   [ITU-T_G709_2016].

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 https://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 May 3, 2018.

Copyright Notice

   Copyright (c) 2017 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
   (https://trustee.ietf.org/license-info) in effect on the date of



Wang, et al.               Expires May 3, 2018                  [Page 1]


Internet-Draft              B100G Extensions                October 2017


   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Overview of the GMPLS Extensions for Support of OTUCn/ODUCn .   3
   5.  Generalized Label Request . . . . . . . . . . . . . . . . . .   4
     5.1.  LSP Encoding Type . . . . . . . . . . . . . . . . . . . .   5
     5.2.  Generalized-PID . . . . . . . . . . . . . . . . . . . . .   5
     5.3.  Traffic Parameters for OTUCn/ODUCn in G.709 . . . . . . .   6
     5.4.  Unavailable slots collection TLV  . . . . . . . . . . . .   7
   6.  Generalized Label . . . . . . . . . . . . . . . . . . . . . .   7
     6.1.  Label Format  . . . . . . . . . . . . . . . . . . . . . .   7
     6.2.  Procedures  . . . . . . . . . . . . . . . . . . . . . . .   8
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   9.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  10
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  10
     10.2.  Informative References . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   The 2016 version of [ITU-T_G709_2016] introduces support for higher
   rate OTU and ODU signals, termed OTUCn and ODUCn (which have a
   nominal rate of 100n Gbps).  The newly introduced OTUCn and ODUCn
   represent a powerful extension to the OTN capabilities, and one which
   naturally scales to transport any newer clients with bit rates in
   excess of 100G, as they are introduced.

   B100G framework document [I-D.merge-ccamp-otn-b100g-fwk] provides an
   overview of the changes and identify the protocol extensions that
   would be required to support GMPLS control of OTUCn/ODUCn as
   specified in [ITU-T_G709_2016].  Based on the framework, this
   document provide Resource Reservation Protocol - Traffic Engineering
   (RSVP-TE) extensions to support control of OTUCn/ODUCn.

   Note: according to the description in
   [I-D.merge-ccamp-otn-b100g-fwk], the setup of ODUk over ODUCn can
   reuse the extensions defined in [RFC7139].



Wang, et al.               Expires May 3, 2018                  [Page 2]


Internet-Draft              B100G Extensions                October 2017


2.  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].

3.  Terminology

   a.  OPUCn: Optical Payload Unit -Cn.

   b.  ODUCn: Optical Data Unit - Cn.

   c.  OTUCn: Fully standardized Optical Transport Unit - Cn.

   d.  OTUCn-M: This signal is an extension of the OTUCn signal
       introduced above.  This signal contains the same amount of
       overhead as the OTUCn signal, but contains a reduced amount of
       payload area.  Specifically the payload area consists of M 5G
       tributary slots (where M is strictly less than 20*n).

4.  Overview of the GMPLS Extensions for Support of OTUCn/ODUCn

   As the new OTUCn/ODUCn signal and features are introduced in
   [ITU-T_G709_2016], corresponding new Signal Types are defined below
   as required:

      completely standardized Optical Transport Unit-Cn (OTUCn)

      Optical Transport Unit-Cn with n OxUC overhead instances and M 5G
      tributary slots (OTUCn-M)

      Optical Data Unit-Cn (ODUCn)

   A new tributary slot granularity (i.e., 5Gbps) is defined in
   [ITU-T_G709_2016].  This granularity is specially used to support
   OPUCn/ODUCn/OTUCn in B100G OTN networks.  Tributary slot is defined
   with a bandwidth of approximately 5 Gbit/s; an OPUCn/ODUCn/OTUCn
   contains 20n tributary slots, numbered 1.1 to n.20.  Legacy OTN
   interfaces will continue to use 2.5Gbps/1.25Gbps tributary slot
   granularity.

   The OTUCn/ODUCn/OPUCn consists of n OTUC/ODUC/OPUC.  Each of them
   contains 20 tributary slots (TS) and these tributary slots are
   interleaved within the payload area.  Each OTUCn/ODUCn/OPUCn includes
   a part of the OH area and a part of the payload area.  An ODUCn
   carries n instances of the ODUC overhead, OPUC overhead and OPUC
   payload.  An OTUCn carries n instances of the OTUC overhead, ODUC
   overhead and ODUC payload.  ODUk frame are mapped into the OPUCn



Wang, et al.               Expires May 3, 2018                  [Page 3]


Internet-Draft              B100G Extensions                October 2017


   tributary slots.  The main difference between OTUCn/ODUCn/OPUCn
   signal and legacy ODUk signal defined in [ITU-T_G709_2012] is how to
   transfer these signals.  As described in
   [I-D.merge-ccamp-otn-b100g-fwk], an OTUCn can be transported over a
   bunch of interfaces, with each OTUC instances maybe distributed over
   different interfaces.  These interfaces are bonded together as a
   single group.  The ODUCn / OTUCn connection does not exist at the
   time the network is deployed.  Signalling is neede to finish the
   setup of ODUCn / OTUCn connection.

   The implementation of the OTUCn/ODUCn Signal which has been briefly
   described in [I-D.merge-ccamp-otn-b100g-fwk], which may be achieved
   through the bonding of FlexO interfaces referred to as PHYs.  Higher
   rate OTUCn is split into n instances of OTUC at the FlexO source
   nodes.  One or more OTUC instances are associated with one FlexO
   interface.  Several end-to-end FlexO connections (PHYs) are bonded
   together as one FlexO group to carry the OTUCn.  The Ethernet PHYs
   are used as the server layer of the OTUCn signal.  The OTU layer
   views FlexO (even if there are some digital sub-layers involved in
   the adaptation) and other OTUCn transport mechanisms as "lower
   layers", and are therefore considered out-of-scope.  GMPLS extensions
   in this draft only consider the use of signalling to set up ODUCn/
   OTUCn connection.

   The OTUCn-M signal is derived from the OTUCn signal by retaining all
   the n instances of overhead (one per OTUC slice) and crunching the
   OPUC tributary slots marked as "unavailable".  Signalling should be
   able to set up OTUCn-M connection by discarding the unavailable slots
   at the source node and restoring the unavailable slots at the sink
   node.

   Virtual Concatenation (VCAT) of Optical channel Payload Unit-k (OPUk)
   and ODUCn is not supported by [ITU-T_G709_2016] any more.New traffic
   parameters for ODUCn/OTUCn are redefined in this draft to reflect the
   changes.

5.  Generalized Label Request

   As defined in [RFC3471], the Generalized Label Request includes a
   common part (i.e., used for any switching technology) and a
   technology dependent part (i.e., the traffic parameters).  Both of
   these two parts are extended in [RFC4328] and [RFC7139] to
   accommodate GMPLS Signalling to the G.709 transport plane technology
   as a result of the introduction of new signal and features.

   In this document, the LSP Encoding Type in the common part and the
   traffic parameter in the technology dependent part are extended/
   refined to accommodate the G.709 Recommendation [ITU-T_G709_2016].



Wang, et al.               Expires May 3, 2018                  [Page 4]


Internet-Draft              B100G Extensions                October 2017


5.1.  LSP Encoding Type

   In [ITU-T_G709_2016], the ODUCn is used as a high-order signal only.
   Only lower-rate (i.e. low-order) ODUs can be multiplexed onto an
   ODUCn signal; In other words, non-OTN client signals can not be
   directly mapped to an ODUCn signal.It must first be mapped on the
   ODUk signal and then traversed through the ODUCn network.

   Additionally, [RFC4328] introduces two new code-points for the LSP
   encoding type, one of them is G.709 ODUk digital path.  This encoding
   type can not be used to describe ODUCn , as ODUCn is not switchable
   and it can only perform digital section layer role.  This is
   different from ODUk.Based on these analysis, a new code-points for
   the LSP Encoding Type is defined in Figure 1.  When signalling is
   used to set up ODUCn/OTUCn LSP, this encoding type can be used to
   represent the nature of the LSP.

             =================================================


                Value           Type
                -----           ----
                 XX             G.709 ODUCn (Digital section)


             =================================================

                       Figure 1: ODUCn Encoding Type

5.2.  Generalized-PID

   This document follows the these extensions defined in [RFC4328] and
   [RFC7139].  New G-PID values are described as follows according to
   update defined in Table 15-8 of [ITU-T_G709_2016].  One thing should
   be noted is the new G-PIDs introduced in this section are just used
   to update [RFC4328] and [RFC7139], as ODUCn can only be used to carry
   ODUk or ODUflex signals, non-OTN client signals must first be mapped
   onto ODUk or ODUflex, then over ODUCn.













Wang, et al.               Expires May 3, 2018                  [Page 5]


Internet-Draft              B100G Extensions                October 2017


             =================================================


   Value    G-PID Type
   -----    ----------
   TBA       New type added to indicate the transportation of "G.709 ODUk" digital Paths over "ODUCn" via 5 Gbps TS granularity.
   TBA       New Type field added to indicate the transportation of FC-3200 over ODUflex.
   TBA       New Type field added to indicate the transportation of FlexE client signal over ODUflex.
   TBA       New Type field added to indicate the transportation of FlexE aware signal over ODUflex.


             =================================================

                              Figure 2: G-PID

   The full list of payload types defined in [ITU-T_G709_2016] and their
   mapping to existing and new G-PID types are as follows:

   [Editor Note: to be added later.]

5.3.  Traffic Parameters for OTUCn/ODUCn in G.709

   Section 3.2 of [RFC4328] is the first place to define the traffic
   parameters of OTN, and [RFC7139] extends the format by adding the
   Bit_Rate field and deleting the NMC (Number of Multiplexed
   Components).ODUCn specific technology traffic parameters are needed
   when requesting the OTUCn/ODUCn LSP.

   This document refine the Traffic Parameter format defined in section
   5 of [RFC7139] to carry ODUCn specific parameters.  Based on the
   description in [ITU-T_G709_2016], this document removes the NVC
   (Number of Virtual Components), as ODUCn is not able to support
   virtual concatenation and multiplication.This Traffic Parameters for
   the ODUCn/OTUCn are carried in the SENDER_TSPEC object in the Path
   message and the FLOWSPEC object in the Resv message.  New C-Type for
   SENDER_TSPEC and FLOWSPEC are defined in this document.

      SENDER_TSPEC object for ODUCn/OTUCn: Class = 12, C-Type = TBD

      FLOWSPEC object for ODUCn/OTUCn: Class = 9, C-Type = TBD











Wang, et al.               Expires May 3, 2018                  [Page 6]


Internet-Draft              B100G Extensions                October 2017


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Signal Type  |       n       |        Multiplier (MT)        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Bit_Rate                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                       Figure 3: Traffic Parameters

   Signal Type: three new signal types (i.e., OTUCn, OTUCn-M, ODUCn) are
   defined in this document.

   n (8 bits): "n" is an positive integer and contained in "OTUCn/OTUCn-
   M/ODUCn", and it can used to represent the bandwidth resource being
   requested.  Also "n" is equal to the number of the OTUC/ODUC/OPUC
   instances.

   MT (Multiplexer): defined in section 3.2.4 of [RFC4328].

   Bit_Rate: defined in section 5 of [RFC7139].  In this draft, this
   filed is extended to indicate the nominal bit rate of ODUCn expressed
   in bytes per second, encoded as a 32-bit IEEE single-precision
   floating-point number (referring to [RFC4506] and [IEEE]).

5.4.  Unavailable slots collection TLV

   When signalling is used to set up OTUCn-M LSP, a new LSP_ATTRIBUTE
   TLV may be needed to negotiate the number and position of the
   unavailable slots at two ends of each ODUC link in the LSP to be set
   up, so the destination node can compute a proper label.  This value
   part of this TLV has the same format as the GMPLS label for setting
   up ODUCn LSP.

6.  Generalized Label

   The generalized label defined in this section can be used to indicate
   how the OTUCn/OTUCn-M/ODUCn LSP is created, how each ODUC/OTUC
   instances are bonded together, which can be treated as a link for the
   client ODUk signal.

6.1.  Label Format

   Following is the GENERALIZED_LABEL object format for OTUCn/OTUCn-M/
   ODUCn.The label contains one or more OTUC/ODUC instances which are
   bonded together as a single ODUCn/OTUCn signal.  ODUCn LSP can be
   used as a link for client ODUk signal.The label is mainly used to



Wang, et al.               Expires May 3, 2018                  [Page 7]


Internet-Draft              B100G Extensions                October 2017


   indicate how to distribute ODUC instances over different interfaces
   and these ODUC instances are bonded together as one group.


          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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Instance ID  | BitMap Length |      NUS      |  Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Slots BitMap                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~               slots assignment information            ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Instance ID  | BitMap Length |      NUS      |   Reserved    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Slots BitMap                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                              Figure 4: Label

   Instance ID: the indication of the ODUC.

   BitMap Length: indicate the length of the slots BitMap.

   Slot BitMap: when the label is used to set up OTUCn-M path, this
   field is used to represent the position of unavailable slots.  When
   the label is used to set up OTUCn/ODUCn path, the bitmap field can be
   set to 0, as there is no indication for allocating slots.  When the
   label is used to set up ODUk path, this field is used to represent
   the ODUCn slots resource allocated for ODUk signal.

   NUS (Number of Unavailable Slots): indicate the number of unavailable
   slots.

   This GENERALIZED_LABEL object contains several label blocks, with
   each block correspond to one OTUC/ODUC instance.

6.2.  Procedures

   This section does not change the procedure of RSVP-TE protocol
   described in section 6.2 of [RFC7139], like birdirectional LSP,
   LABEL_SET object.

   When the source node receives the command from EMS or trigger from
   upper layer, and then decide to set up an ODUCn LSP.The path



Wang, et al.               Expires May 3, 2018                  [Page 8]


Internet-Draft              B100G Extensions                October 2017


   computation module is first used to compute an available path for
   ODUCn LSP, after the computation, how many and which ODUC instances
   would be involved can be known, then the Path message containing a
   traffic parameters in the SENDER_TSPEC object for ODUCn LSP is
   created according to the computation result.Unavailable slots
   collection TLV must be carried to collect the number and position of
   the unavailable slots if there exist OTUC instances with unavailable
   slots between the ODUCn source and sink terminating nodes.

   Before the sending of the ODUCn path message, an OTUCn LSP or OTUCn-M
   LSP needs to be set up first to carry the ODUCn signal.The
   information of OTUC instances involved would be notified to OTUCn
   path setup module by ODUCn path setup module.  An OTUCn or OTUCn-M
   path message with traffic parameters and is created at the source
   OTUCn or OTUCn-M terminating node and sent to the sink OTUCn or
   OTUCn-M terminating node.Unavailable slots collection TLV may not be
   neede, as even there are unavailable slots on this OTUCn link, they
   can be configured by manual or dynamic negotiation.  Upon receiving
   the Path message, OTUCn or OTUCn-M sink terminating node then replies
   with a resv message towards the source terminating node and finish
   the bonding of n OTUC instances.  The bitMap Length field of label
   would be set to 0.

   The ODUCn Path message is then sent to the next hop which is actually
   the OTUCn or OTUCn-M sink terminating node.  As one ODUCn LSP may be
   carried over several different OTUCn LSPs or OTUCn-M LSPs, this hop
   maybe an intermediate ODUCn hop or sink terminating node.  If it is
   an ODUCn sink terminating node, Resv message is then created and sent
   to the source, finish the bonding of n ODUC instances.  If it is an
   intemediate hop, then the above procedure would be repeat until the
   ODUCn sink terminating node.

   The IF_ID RSVP_HOP object must be used in Resv message, and it
   contains several TLVs with each of them has an one-to-one
   relationship to the instance in the label.In another word, which
   component interface is used to carry a specific OTUC/ODUC instance
   needs to be explicitly specified.

   In the case of setup of OTUCn, which means there does not exist any
   unavailable slot between ODUCn source and sink terminating node, bit
   Map information is not required and MUST NOT be included, so the
   Length field MUST be set to 0 as well.  The NUS field should be set
   to 0.

   In the case of setup of OTUCn-M, the NUS field is set to indicate the
   number of unavailable in this connection, and the postions of these
   slots are indicated by the Bit map field.  Unavailable slots can not




Wang, et al.               Expires May 3, 2018                  [Page 9]


Internet-Draft              B100G Extensions                October 2017


   be assigned to client signal and this information should be aware of
   by ODUCn layer.

   ERO can be used to indicate the nodes and Ports which would be passed
   through in the Path message after path computation in according to
   the resource information at each nodes and ports.

7.  Security Considerations

8.  IANA Considerations

9.  Contributors

      Iftekhar Hussain, Infinera Corp, IHussain@infinera.com

      Zheyu Fan, Huawei, fanzheyu2@huawei.com

      Yunbin Xu, CAICT, xuyunbin@ritt.cn

      Sergio Belotti, NOKIA, Sergio Belotti@nokia.com

10.  References

10.1.  Normative References

   [ITU-T_G709.1]
              ITU-T, "ITU-T G.709.1: Flexible OTN short-reach interface;
              2016",  , 2016.

   [ITU-T_G709_2012]
              ITU-T, "ITU-T G.709: Optical Transport Network Interfaces;
              02/2012",  http://www.itu.int/rec/T-REC-
              G..709-201202-S/en, February 2012.

   [ITU-T_G709_2016]
              ITU-T, "ITU-T G.709: Optical Transport Network Interfaces;
              07/2016",  http://www.itu.int/rec/T-REC-
              G..709-201606-P/en, July 2016.

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

   [RFC3471]  Berger, L., Ed., "Generalized Multi-Protocol Label
              Switching (GMPLS) Signaling Functional Description",
              RFC 3471, DOI 10.17487/RFC3471, January 2003,
              <https://www.rfc-editor.org/info/rfc3471>.



Wang, et al.               Expires May 3, 2018                 [Page 10]


Internet-Draft              B100G Extensions                October 2017


   [RFC4328]  Papadimitriou, D., Ed., "Generalized Multi-Protocol Label
              Switching (GMPLS) Signaling Extensions for G.709 Optical
              Transport Networks Control", RFC 4328,
              DOI 10.17487/RFC4328, January 2006,
              <https://www.rfc-editor.org/info/rfc4328>.

   [RFC4506]  Eisler, M., Ed., "XDR: External Data Representation
              Standard", STD 67, RFC 4506, DOI 10.17487/RFC4506, May
              2006, <https://www.rfc-editor.org/info/rfc4506>.

   [RFC7139]  Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D.,
              and K. Pithewan, "GMPLS Signaling Extensions for Control
              of Evolving G.709 Optical Transport Networks", RFC 7139,
              DOI 10.17487/RFC7139, March 2014,
              <https://www.rfc-editor.org/info/rfc7139>.

10.2.  Informative References

   [I-D.merge-ccamp-otn-b100g-fwk]
              Wang, Q., Valiveti, R., zhenghaomian@huawei.com, z.,
              Helvoort, H., and S. Belotti, "GMPLS Routing and Signaling
              Framework for B100G", draft-merge-ccamp-otn-b100g-fwk-01
              (work in progress), July 2017.

Authors' Addresses

   Qilei Wang
   ZTE
   Nanjing
   CN

   Email: wang.qilei@zte.com.cn


   Haomian Zheng
   Huawei
   CN

   Email: zhenghaomian@huawei.com


   Radha Valiveti
   Infinera Corp
   Sunnyvale
   USA

   Email: rvaliveti@infinera.com




Wang, et al.               Expires May 3, 2018                 [Page 11]


Internet-Draft              B100G Extensions                October 2017


   Huub van Helvoort
   Hai Gaoming B.V

   Email: huubatwork@gmail.com


   Zafar Ali
   Cisco

   Email: zali@cisco.com









































Wang, et al.               Expires May 3, 2018                 [Page 12]