Internet DRAFT - draft-zheng-ccamp-gmpls-g709v5-fwk
draft-zheng-ccamp-gmpls-g709v5-fwk
CCAMP Working Group Haomian Zheng
Internet-Draft Italo Busi
Intended status: Standards Track Huawei
Zafar Ali
Cisco
Sergio Belotti
Nokia
Daniele Ceccarelli
Ericsson
Daniel King
Lancaster University
Expires: September 6, 2017 March 6, 2017
Framework for GMPLS Control of Optical Transport Networks in G.709
Edition 5
draft-zheng-ccamp-gmpls-g709v5-fwk-00.txt
Abstract
The International Telecommunication Union Telecommunication
Standardization Sector (ITU-T) has extended its Recommendations
Optical Transport Networks (OTNs, G.709) to edition 5 to support new
features, including beyond 100 Gbps (B100G) OTN containers.
This document summarizes the architecture and requirements, and
provides corresponding control plane considerations to guide
protocol extensions development in support of OTNv5 control
mechanisms.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
Zheng et al Expires September 2017 [Page 1]
draft-zheng-ccamp-b100g-otn-fwk-00.txt March 2017
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 6, 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
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 ................................................. 3
1.1. Scope ................................................... 3
2. Terminology .................................................. 3
2.1. Conventions Used in this Document ....................... 3
2.2. OTN Related Terminologies in this Document .............. 3
3. Optical Transport Network Version 5 Overview ................. 4
3.1. OTN B100G Network ....................................... 4
3.1.1. Client Signal Mapping .............................. 4
3.1.2. Supporting clients signals with ODUCn .............. 5
3.2. MSI of ODUCn ............................................ 6
3.3. OTUCn sub rates (OTUCn-M) ............................... 7
4. Connection Management of ODUCn ............................... 7
5. GMPLS Implications ........................................... 8
5.1. Implications for GMPLS Signaling ........................ 8
5.2. Implications for GMPLS Routing .......................... 8
6. Security Considerations ...................................... 9
7. Contributors' Addresses ..................................... 10
8. References .................................................. 10
8.1. Normative References ................................... 10
8.2. Informative References ................................. 11
Authors' Addresses ............................................. 11
Zheng et al Expires September 2017 [Page 2]
draft-zheng-ccamp-b100g-otn-fwk-00.txt March 2017
1. Introduction
ITU-T G.709v3, published in 2012, defined the interfaces to Optical
Transport Network (OTN), supporting a variety of Optical Data Unit
(ODU) containers up to 100 Gbps and flexible multiplexing hierarchy.
The OTN control plane framework was described in [RFC7062],
corresponding signaling and routing extensions were further
specified in [RFC7139] and [RFC7138] respectively. Furthermore,
there were additional updates made to G.709v4, resulting in
additional extensions which are described in [RFC7892] and [RFC7963].
To meet the increasing demand for higher client bit rates, Edition 5
of G.709 [ITU-T G.709v5] has been released to provide beyond 100G
capabilities by introducing an ODUCn layer, which contains an
optical payload unit(OPUCn).
This document reviews relevant aspects of beyond 100 Gbps (B100G)
OTN technology and how it impacts current GMPLS control-plane
protocols. It highlights new considerations and proposes how to
update the mechanisms described in [RFC7062] to meet B100G control
plane requirements.
1.1. Scope
For the purposes of the B100G control plane discussion, the OTN
should be considered as a combination of the current OTN ODUk/Cn and
the wavelength optical layer. This document focuses on only the
control of the ODUk/ODUCn layer. The optical layer control will be
addressed in a separate document.
2. Terminology
2.1. Conventions Used in this Document
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.2. OTN Related Terminologies in this Document
Terminologies from section 2 of [RFC7062] are reused in this
document, with the following additional terminologies defined in
[ITU-T G.709v5] used in this document:
ODUCn: Optical Data Unit - Cn
Zheng et al Expires September 2017 [Page 3]
draft-zheng-ccamp-b100g-otn-fwk-00.txt March 2017
OPUCn: Optical Payload Unit- Cn
OTUCn: completely standardized Optical Transport Unit-Cn
3. Optical Transport Network Version 5 Overview
This section provides an overview of new features provided by
G.709v5 Optical Transport Network.
3.1. OTN B100G Network
3.1.1. Client Signal Mapping
+-----------------------+-----------------------------------+
| ODU Type | ODU nominal bit rate |
+-----------------------+-----------------------------------+
| ODU0 | 1,244,160 Kbps |
| ODU1 | 239/238 x 2,488,320 Kbps |
| ODU2 | 239/237 x 9,953,280 Kbps |
| ODU3 | 239/236 x 39,813,120 Kbps |
| ODU4 | 239/227 x 99,532,800 Kbps |
| ODUCn | n x 239/226 x 99,532,800 Kbps |
| | |
| ODUflex for | |
|Constant Bit Rate (CBR)| 239/238 x client signal bit rate |
| Client signals | |
| | |
| ODUflex for Generic | |
| Framing Procedure | Configured bit rate |
| - Framed (GFP-F) | |
| Mapped client signal | |
+-----------------------+-----------------------------------+
Table 1: ODU Types and Bit Rates
NOTE: The nominal ODUCn rates are approximately n x 105,258,138.053
kbit/s.
Zheng et al Expires September 2017 [Page 4]
draft-zheng-ccamp-b100g-otn-fwk-00.txt March 2017
Furthermore, and per [ITU-T G.709v5], the tolerance of ODUCn is +/-
20 ppm. The frame period for ODUCn is 1.163 s. Additionally, it
defined 5 Gbps tributary slots for ODU Cn. The number of tributary
slots (TS) defined in [ITU-T G.709v5] for each ODU are shown in
Table 2.
+------------+-------------------------------------+
| | Nominal TS capacity |
| ODU Server +-------------------------------------+
| | 1.25 Gbit/s | 2.5 Gbit/s | 5 Gbit/s |
+------------+-------------+------------+----------+
| ODU0 | 1 | N/A | N/A |
+------------+-------------+------------+----------+
| ODU1 | 2 | N/A | N/A |
+------------+-------------+------------+----------+
| ODU2 | 8 | 4 | N/A |
+------------+-------------+------------+----------+
| ODU3 | 32 | 16 | N/A |
+------------+-------------+------------+----------+
| ODU4 | 80 | N/A | N/A |
+------------+-------------+------------+----------+
| ODUCn | N/A | N/A | 20*n |
+------------+-------------+------------+----------+
Table 2: Number of tributary slots (TS)
3.1.2. Supporting clients signals with ODUCn
According to [ITU-T G.709v5], various client signals can be mapped
to be supported by ODUCn. Typical client signal includes Ethernet,
MPLS and IP. The signal hierarchies can be found in Figure 1.
Client (e.g., IP, Ethernet, MPLS, ...)
|
OTN client signals (ODUk)
|
ODUCn
Zheng et al Expires September 2017 [Page 5]
draft-zheng-ccamp-b100g-otn-fwk-00.txt March 2017
|
OTUCn
Figure 1: Mapping Client Signal to ODUCn
Packet streams (e.g., Ethernet, MPLS, IP) which are encapsulated
with the generic framing procedure is considered as the client and
can be carried by OTN client signals (known as ODUk, including
ODU0~4 and ODUflex). Then the OTN client signals will be further
mapped into ODUCn containers and multiplexed into OTUCn. It is worth
noting that the maximum bit rate for ODUk is 100G (ODU4), which is
the same rate of ODUC1. The mapping from ODU client signal to ODU
Containers is also required when ODU4 is multiplexed into ODUC1.
Examples of multiplexing can be found as follow:
- ODU0/ ODU1/ ODU2/ ODU3/ ODU4 into ODUC1 multiplexing with
5Gbps TS granularity: ODU0/ ODU1/ ODU2/ ODU3/ ODU4 occupies
1/1/2/8/20 of the 20 TSs for ODUC1. It is worth noting that for ODU0
and ODU1, the 5G TS is only partially occupied.
The type of the transported payload, encoded as the payload type, is
set to 22 for ODUCn.
3.2. MSI of ODUCn
When multiplexing an OTN client signal into ODUCn, [ITU-T G.709v5]
specifies the information that must be transported in-band to
correctly demultiplexing the signal. MSI is used to specify the
identifier of each multiplexing section. The MSI information is
located in the mapping specific area of the PSI signal and is local
to each link.
The MSI information is organized as a set of entries, with n
entries for each OPUC TS. The MSI has a fixed length of 40n bytes
and indicates the ODTU content of each tributary slot (TS) of an
OPUCn.
Two bytes are used for each tributary slot. The information carried
by each entry is:
- TS availability bit 1 indicates if the tributary slot is
available or unavailable.
Zheng et al Expires September 2017 [Page 6]
draft-zheng-ccamp-b100g-otn-fwk-00.txt March 2017
- The TS occupation bit 9 indicates if the tributary slot is
allocated or unallocated.
- The tributary port number in bits 2 to 8 and 10 to 16 indicates
the port number of the ODTUCn.ts that is being transported in this
TS; a flexible assignment of tributary port to tributary slots is
possible. ODTUC.ts tributary ports are numbered 1 to 10n. The value
is set to all-0s when the occupation bit has the value 0 (tributary
slot is unallocated).
Tributary Port Number (TPN) indicates the port number of the OTN
client signal transported by the ODUCn. The TPN is the same for all
the TSs assigned to the transport of the same OTN client signal.
3.3. OTUCn sub rates (OTUCn-M)
An OTUCn with a bit rate that is not an integer multiple of 100
Gbit/s can be described as an OTUCn-M. An OTUCn-M frame contains n
instances of OTUC overhead, ODUC overhead and OPUC overhead together
with M 5Gbit/s OPUCn TS.
When an OTUCn-M is used to carry an ODUCn (20n-M) TS are marked as
unavailable, in the OPUCn multiplex structure identifier (MSI),
since they cannot be used to carry a client signal.
4. Connection Management of ODUCn
ODUk based connection management has been described in section 4 of
[RFC7062]. In this section the connection management of ODUCn is
described, which is independent but used together with ODUk based
connection management.
ODUCn based connection management is concerned with controlling the
connectivity of ODUCn paths. According to ITU-T G.872, the
intermediate nodes with ODUCn do not support the switching of ODUCn
time slot. Intermediate ODUCn points are only considered as a
forwarding node. Once an ODUCn path is used to transport client
signal, the TS occupied will not change across the ODUCn network.
Zheng et al Expires September 2017 [Page 7]
draft-zheng-ccamp-b100g-otn-fwk-00.txt March 2017
5. GMPLS Implications
5.1. Implications for GMPLS Signaling
For OTNv3 network control, [RFC7139] defines RSVP-TE signaling
extensions, extending the base specifications [RFC3473] and
[RFC4328].
As described in Section 3, [ITU-T G.709v5] introduced some new
features including the ODUCn, OTUCn for beyond 100G control. The
mechanisms defined in [RFC7139] do not support such features, and
protocol extensions SHALL be necessary to allow them to be
controlled by a GMPLS control plane. In summary, the following new
signaling aspects SHOULD be considered:
- Support for specifying new signal types and related traffic
information: The traffic parameters should be extended in a
signaling message to support the new ODUCn;
- Support the new TS granularity: the signaling protocol should be
able to identify the TS granularity (i.e., the new 5 Gbps TS
granularity) to be used for establishing a Hierarchical LSP that
will be used to carry service LSP(s) requiring a specific TS
granularity.
- Support for LSP setup of new ODUCn containers with related
mapping and multiplexing capabilities: A new label format must be
defined to carry the exact TS's allocation information related to
the extended mapping and multiplexing hierarchy (for example, ODU4
into ODUCn multiplexing (with 5 Gbps TS granularity)), in order to
set up all the possible ODU connections.
- Support for TPN allocation and negotiation: TPN needs to be
configured as part of the MSI information (see more information in
Section 3.1.2.1). A signaling mechanism must be identified to carry
TPN information if the control plane is used to configure MSI
information.
- Support for LSP setup of OTUCn sub rates (OTUCn-M) path: based on
previous extensions, there should be new signal mechanism to declare
the OTUCn-m information.
5.2. Implications for GMPLS Routing
The path computation process needs to select a suitable route for an
ODUCn connection request. Evaluation of the available bandwidth on
each candidate link is required for path computation. The routing
Zheng et al Expires September 2017 [Page 8]
draft-zheng-ccamp-b100g-otn-fwk-00.txt March 2017
protocol SHOULD be extended to carry sufficient information to
represent ODU Traffic Engineering (TE) topology.
The Interface Switching Capability Descriptors defined in [RFC4203]
present a new constraint for LSP path computation. [RFC4203]
defines the Switching Capability, related Maximum LSP Bandwidth, and
Switching Capability specific information. [RFC7138] updates the
ISCD to support ODU4, ODU2e and ODUflex. The new Switching
Capability specific information provided in [RFC7138] have to be
adapted to support new features contained in [ITU-T G.709v5]. The
following requirements should be considered:
- Support for carrying the link multiplexing capability: As
discussed in Section 3.1.2, many different types of ODUk can be
multiplexed into the ODUCn. For example, ODU4 may be multiplexed
into ODUC1. An OTUCn link may support one or more types of ODUk
signals. The routing protocol should be capable of carrying this
multiplexing capability.
- Support for additional Tributary Slot Granularity advertisement:
as new tributary slot granularity (5G TS) is introduced in [G.709
v5], there is a need to specify this parameter.
- Support for advertisement of OTUCn sub rates support information:
Given the same n value, there is possible different OTUCn sub rates.
Corresponding information should be defined in the routing mechanism
to satisfy this feature.
6. Security Considerations
TBD.
Zheng et al Expires September 2017 [Page 9]
draft-zheng-ccamp-b100g-otn-fwk-00.txt March 2017
7. Contributors' Addresses
Xian Zhang
Huawei Technologies
Email: zhang.xian@huawei.com
Antonello Bonfanti
Cisco
Email: abonfant@cisco.com
Dieter Beller
Nokia
Email: Dieter.Beller@nokia.com
8. References
8.1. Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to indicate
requirements levels", RFC 2119, March 1997.
[ITU-T G.709v5] ITU-T, "Interface for the Optical Transport Network
(OTN)", G.709/Y.1331 Recommendation, June 2016.
[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,
[RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support
of Generalized Multi-Protocol Label Switching (GMPLS)",
RFC 4203, October 2005.
[RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Extensions for G.709 Optical
Transport Networks Control", RFC 4328, January 2006,
[RFC7138] D. Ceccarelli, F. Zhang, S. Belotti, R. Rao, J. Drake,
'Traffic Engineering Extensions to OSPF for GMPLS Control
of Evolving G.709 Optical Transport Networks', RFC7138,
March 2014.
[RFC7139] F. Zhang, G. Zhang, S. Belotti, D. Ceccarelli, K. Pithewan,
'GMPLS Signaling Extensions for Control of Evolving G.709
Optical Transport Networks', RFC7139, March 2014.
Zheng et al Expires September 2017 [Page 10]
draft-zheng-ccamp-b100g-otn-fwk-00.txt March 2017
[RFC7892] Z. Ali, A. Bonfanti, M. Hartley, F. Zhang, 'IANA
Allocation Procedures for the GMPLS OTN Signal Type
Registry', RFC7892, May 2016.
8.2. Informative References
[RFC7062] F. Zhang, D. Li, H. Li, S. Belotti, D. Ceccarelli,
'Framework for GMPLS and PCE Control of G.709 Optical
Transport Networks', RFC 7062, November 2013.
[RFC7963] Z. Ali, A. Bonfanti, M. Hartley, F. Zhang, 'RSVP-TE
Extension for Additional Signal Types in G.709 Optical
Transport Networks (OTNs)', RFC7963, August 2016.
Authors' Addresses
Haomian Zheng
Huawei Technologies
Email: zhenghaomian@huawei.com
Italo Busi
Huawei Technologies
Email: Italo.Busi@huawei.com
Zafar Ali
Cisco
Email: zali@cisco.com
Sergio Belotti
Nokia
Email: sergio.belotti@nokia.com
Daniele Ceccarelli
Ericsson
Email: daniele.ceccarelli@ericsson.com
Daniel King
Lancaster University
Email: d.king@lancaster.ac.uk
Zheng et al Expires September 2017 [Page 11]
