Internet DRAFT - draft-merge-ccamp-100g-signalling
draft-merge-ccamp-100g-signalling
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]
