Internet Engineering Task Force Q. Wang, Ed.
Internet-Draft ZTE
Intended status: Informational R. Valiveti
Expires: September 7, 2017 I. Hussain
R. Rao
Infinera Corp
H. Helvoort
Hai Gaoming B.V
Y. Xu
CAICT
March 6, 2017
GMPLS Signalling Extensions for control of B100G OTUCn/ODUCn Network
draft-zihc-ccamp-otn-b100g-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 in ITU-T Recommendation G.709
[G.709-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 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 September 7, 2017.
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
(http://trustee.ietf.org/license-info) in effect on the date of
Wang, et al. Expires September 7, 2017 [Page 1]
Internet-Draft GMPLS ODUCn Framework March 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 . . . . . . . . . . . . . . . . . . . . 4
5.2. Refination of Traffic Parameters for OTUCn/ODUCn in G.709 4
6. Generalized Label . . . . . . . . . . . . . . . . . . . . . . 5
6.1. Label Format . . . . . . . . . . . . . . . . . . . . . . 5
6.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
The 2016 version of G.709 [G.709-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 very 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.zih-ccamp-otn-b100g-fwk] provides a
framework to allow the development of protocol extensions to support
GMPLS control of OTN as specified in [G.709-2016]. Based on this
framework, this document provide Resource Reservation Protocol -
Traffic Engineering (RSVP-TE) extensions to support control of OTUCn/
ODUCn introduced in [G.709-2016].
Note: the RSVP-TE signalling extensions in this document will try to
reuse the extensions defined in RFC4328 [RFC4328] and RFC7139
[RFC7139].
Wang, et al. Expires September 7, 2017 [Page 2]
Internet-Draft GMPLS ODUCn Framework March 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
OPUCn Optical Payload Unit-Cn
ODUCn Optical Data Unit-Cn
OTUCn completely standardized Optical Transport Unit-Cn
OTUCn-M Optical Transport Unit-Cn with n OxUC overhead instances and
M 5G tributary slots
OTUCn completely standardized Optical Transport Unit-Cn
4. Overview of the GMPLS Extensions for Support of OTUCn/ODUCn
New OTUCn/ODUCn are specified in [G.709-2016]. The corresponding new
Signal Types are defined below:
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., 5 Gbps) is described in
[G.709-2016]. But this kind of tributary slot (TS) can only be used
at ODUCn capable interfaces.
Virtual Concatenation (VCAT) of Optical channel Payload Unit-k (OPUk)
and ODUCn is not supported by [G.709-2016] any more.
The implementation of the OTUCn/ODUCn Signal which has been briefly
described in [I-D.zih-ccamp-otn-b100g-fwk] is achieved through the
bonding of FlexO interfaces, which can also be 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 FlexO
layer are used as the server layer of the OTUCn signal.
Wang, et al. Expires September 7, 2017 [Page 3]
Internet-Draft GMPLS ODUCn Framework March 2017
5. Generalized Label Request
As desfined in RFC3471 [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 [RFC4328] and RFC7139
[RFC7139] to accommodate GMPLS Signalling to the G.709 transport
plane recommendation.
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 [G.709-2016]. The
other parts are not changed.
5.1. LSP Encoding Type
In [G.709-2016], the ODUCn is used as a high-order signal only. Only
other lower-rate (i.e. low-order) ODUs can be multiplexed into an
ODUCn signal; in other words, no non-OTN client signals can be
directly mapped to an ODUCn signal.
A new code-points for the LSP LSP Encoding Type is defined:
=================================================
Value Type
----- ----
XX G.709 ODUCn (Digital Path)
=================================================
Figure 1
5.2. Refination of Traffic Parameters for OTUCn/ODUCn in G.709
Section 3.2 of RFC4328 [RFC4328] defines the initial traffic
parameters, and RFC7139 [RFC7139] extend the format by adding the
Bit_Rate field and deleting the NMC (Number of Multiplexed
Components).
This document refine the Traffic Parameter format defined in section
5 RFC7139 [RFC7139].
Wang, et al. Expires September 7, 2017 [Page 4]
Internet-Draft GMPLS ODUCn Framework March 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 2
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.
NVC (Number of Virtual Components) defined in RFC7139 [RFC7139] is
not used any more, because virtual concatenation is not support in
the [G.709-2016].
MT (Multiplexer): defined in section 3.2.4 of RFC4328 [RFC4328].
Bit_Rate: defined in section 5 of RFC7139 [RFC7139].
This Traffic Parameters for the OTN-TDM-capable Switching Type are
carried in the OTN-TDM SENDER_TSPEC object in the Path message and
the OTN-TDM FLOWSPEC object in the Resv message.
6. Generalized Label
This section defines the format of the OTUCn/OTUCn-M/ODUCn
Generalized Label.
6.1. Label Format
Following is the GENERALIZED_LABEL object format for OTUCn/OTUCn-M/
ODUCn.
Wang, et al. Expires September 7, 2017 [Page 5]
Internet-Draft GMPLS ODUCn Framework March 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TPN | IF Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Bit Map of Available/Unavailable Slots | Resvd | NUS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Bit Map of Available/Unavailable Slots | Resvd | NUS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3
This GENERALIZED_LABEL object is used to indicate how the ODU client
signal is multiplexed into the ODUCn link. Note that the LO OUDj
Signal Type is indicated by Traffic Parameters, while the type of
ODUCn link is identified by the bonding FlexO capable interfaces
carried in the IF_ID RSVP_HOP object.
TPN: defined in section 6.1 of RFC7139 [RFC7139].
IF (Interface) Type (8 bits): indicate the interface type of the port
that provide support for OTUCn/OTUCn-M/ODUCn, which can be
100G/200G/400G Ethernet PHY interfaces.
Length (12 bits): indicates the number of bits of the Bit Map field.
This field can also be used to indicate the number of the OTUC/ODUC
instances being requested. For example, the number of OTUC/ODUC
instances can be derived through the length number divided by 4.
Bit Map of Available/Unavailable Slots: 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 ODUCn path, this
field is used to represent the slots resource allocated for client.
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 instance.
Compatibility: actually, there will be different FlexO interfaces
used for carrying OTUCn signal, and the length of the bit map may be
different. The label format defined in this document can only
support the 100G interface. If the label format is used in the case
of 200G/400G interfaces, the bit map field can be extended to
Wang, et al. Expires September 7, 2017 [Page 6]
Internet-Draft GMPLS ODUCn Framework March 2017
accommodate the slots number. Besides this, byte alignment also
needs to be taken into consideration.
6.2. Procedures
This section does not change the procedure of RSVP-TE protocol
described in section 6.2 of RFC7139 [RFC7139], like birdirectional
LSP, LABEL_SET object, except the process procedure at the node.
When a downstream node or egress node receives a Path message
containing a GENERALIZED_LABEL_REQUEST object for setting up an
ODUflex LSP over an ODUCn connection from its upstream neighbor node.
The node need to check if there are n Ethernet PHYs (FlexO capable)
available for transport ODUflex LSP.
When an upstream node receives a Resv message containing a
GENERALIZED_LABEL object, it MUST first identify which ODU Signal
Type is multiplexed or mapped into which ODU Signal Type according to
the Traffic Parameters and the IF_ID RSVP_HOP object in the received
message. The IF_ID RSVP_HOP object contains several TLVs, and each
of them has an one-to-one relationship with one label block. In
another word, which component FlexO interface is used to carry a
specific OTUC instance needs to be explicitly specified.
In the case of ODUCn-to-OTUCn mapping, the TPN field MUST be set
to 0. 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 ODUCn-to-OTUCn-M mapping, 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 ODUCn. This information
is required when provide resource for ODUCn client signal.
In the case of ODU Client-to-ODUCn multiplexing, the node MUST
retrieve the reserved tributary slots in the ODUCn by its
downstream neighbor node according to the position of the bits
that are set to 1 in the Bit Map field. The TS granularity is 5G,
so that the node can multiplex the ODU Client into the ODUCn based
on the TS granularity. The node MUST also retrieve the TPN value
assigned by its downstream neighbor node from the label and fill
the TPN into the related MSI byte(s) in the OPUCn overhead in the
data plane.
A new LSP_ATTRIBUTE object needs to be extended to collect the number
and position of the unavailable slots at each link in the connection,
so the destination node can compute a proper label.
Wang, et al. Expires September 7, 2017 [Page 7]
Internet-Draft GMPLS ODUCn Framework March 2017
When PCE is involved, an ERO can be used to indicate the nodes and
ports passed according to the resouce information at each nodes and
ports. Thus the LSP_ATTRIBUTE object used to collect unavailable
slots information are not needed any more.
7. Security Considerations
TBD
8. IANA Considerations
The signal types documented in this draft needs to be allocate by
IANA.
9. References
9.1. Normative References
[G.709-2012]
ITU, "Optical Transport Network Interfaces",
ITU Recommendation G.709, February 2012,
<http://www.itu.int/rec/T-REC-G.709-201202-S/en>.
[G.709-2016]
ITU, "Optical Transport Network Interfaces",
ITU Recommendation G.709, July 2016,
<http://www.itu.int/rec/T-REC-G.709-201606-P/en>.
[G.709.1] ITU, "Flexible OTN short-reach interface",
ITU Recommendation G.709.1, October 2016.
[G.798] ITU, "Characteristics of optical transport network
hierarchy equipment functional blocks", ITU Recommendation
G.798, February 2014,
<http://www.itu.int/rec/T-REC-G.798-201212-I/en>.
[G.872-2012]
ITU, "The Architecture of Optical Transport Networks",
ITU Recommendation G.872, October 2012,
<http://www.itu.int/rec/T-REC-G.872-201210-S/en>.
[G.872-2017]
ITU, "The Architecture of Optical Transport Networks",
ITU Recommendation G.872, October 2012,
<http://www.itu.int/rec/T-REC-G.872-201701-P/en>.
Wang, et al. Expires September 7, 2017 [Page 8]
Internet-Draft GMPLS ODUCn Framework March 2017
[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>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<http://www.rfc-editor.org/info/rfc3209>.
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description",
RFC 3471, DOI 10.17487/RFC3471, January 2003,
<http://www.rfc-editor.org/info/rfc3471>.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
DOI 10.17487/RFC3473, January 2003,
<http://www.rfc-editor.org/info/rfc3473>.
[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,
<http://www.rfc-editor.org/info/rfc4328>.
[RFC7062] Zhang, F., Ed., Li, D., Li, H., Belotti, S., and D.
Ceccarelli, "Framework for GMPLS and PCE Control of G.709
Optical Transport Networks", RFC 7062,
DOI 10.17487/RFC7062, November 2013,
<http://www.rfc-editor.org/info/rfc7062>.
[RFC7096] Belotti, S., Ed., Grandi, P., Ceccarelli, D., Ed.,
Caviglia, D., Zhang, F., and D. Li, "Evaluation of
Existing GMPLS Encoding against G.709v3 Optical Transport
Networks (OTNs)", RFC 7096, DOI 10.17487/RFC7096, January
2014, <http://www.rfc-editor.org/info/rfc7096>.
[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,
<http://www.rfc-editor.org/info/rfc7139>.
Wang, et al. Expires September 7, 2017 [Page 9]
Internet-Draft GMPLS ODUCn Framework March 2017
9.2. Informative References
[I-D.zih-ccamp-otn-b100g-fwk]
Wang, Q., Zhang, Y., Valiveti, R., Hussain, I., Rao, R.,
and H. Helvoort, "GMPLS Routing and Signaling Framework
for B100G", draft-zih-ccamp-otn-b100g-fwk-00 (work in
progress), February 2017.
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Architecture", RFC 3945,
DOI 10.17487/RFC3945, October 2004,
<http://www.rfc-editor.org/info/rfc3945>.
Authors' Addresses
Qilei Wang (editor)
ZTE
Nanjing
CN
Email: wang.qilei@zte.com.cn
Radha Valiveti
Infinera Corp
169 Java Drive
Sunnyvale, CA 94089
USA
Email: rvaliveti@infinera.com
Iftekhar Hussain
Infinera Corp
169 Java Drive
Sunnyvale, CA 94089
USA
Email: IHussain@infinera.com
Rajan Rao
Infinera Corp
169 Java Drive
Sunnyvale, CA 94089
USA
Email: rrao@infinera.com
Wang, et al. Expires September 7, 2017 [Page 10]
Internet-Draft GMPLS ODUCn Framework March 2017
Huub van Helvoort
Hai Gaoming B.V
Email: huubatwork@gmail.com
Yunbin Xu
CAICT
Beijing
CN
Email: xuyunbin@ritt.cn
Wang, et al. Expires September 7, 2017 [Page 11]