| 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
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].
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 (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 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.
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].
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.
As the new OTUCn/ODUCn signal and features are introduced in [ITU-T_G709_2016], corresponding new Signal Types are defined below as required:
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 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.
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].
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
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.
=================================================
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.]
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.
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]).
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.
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.
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 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.
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 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 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.
| [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", Internet-Draft draft-merge-ccamp-otn-b100g-fwk-01, July 2017. |