CCAMP Working Group Alberto Bellato (Alcatel)
Category: Internet Draft Michele Fontana (Alcatel)
Expiration Date: December 2001 Germano Gasparini (Alcatel)
Gert Grammel (Alcatel)
Jim Jones (Alcatel)
Zhi-Wei Lin (Lucent)
Eric Mannie (Ebone)
Dimitri Papadimitriou (Alcatel)
Siva Sankaranarayanan (Lucent)
Maarten Vissers (Lucent)
June 2001
G.709 Optical Transport Networks GMPLS Control Framework
draft-bellato-ccamp-g709-framework-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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."
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.
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 [2].
D.Papadimitriou - Internet Draft û Expires December 2001 1
draft-bellato-ccamp-g709-framework-00.txt June 2001
Abstract
Along with the current development of packet over lambda switching
(referred to as MPLambdaS), there are considerable developments in
optical transport systems based on the ITU-T G.872 [ITUT-G872] and
G.709 [ITUT-G709] specification. The Optical Transport Network (OTN)
defined in G.872 and G.709 enables ultra-long-haul transmission of
various client signal types through the use of Forward Error
Correction (FEC) bytes. G.709 specifies the data plane transport
structure and allocates overhead bytes for the OTN control plane.
In this document, we describe the G.709 Digital and Optical
Transport Hierarchies (OTH) defined at the ITU-T and the
relationships with the current GMPLS specification [GMPLS-ARCH].
This in order to specify how current GMPLS Signalling specification
[GMPLS-SIG] can be accommodated in order to encompass these
hierarchies to extend GMPLS signalling for OTN.
1. Introduction
Recently, the ITU-T finalized the first version of the Optical
Transport Networks (OTN) standardization [ITUT-G709] to provide the
transparent digital pipe (digital wrapper) to be transported into
optical channels.
The OTN provides two fundamental degrees of flexibility: in terms of
wavelength and in terms of bandwidth transmission optimization
without losing the integrity of the lower bit rates pipes filled by
the access network. From that perspective, the OTN specification
enables as well the control of all-optical sub-networks.
However, the OTN architecture has today no explicit association with
any IP-based control plane, without which the future deployment of
OTN equipment is clearly uncertain. Therefore, [ITUT-G709] foresees
a strong requirement for future evolutions that can provide explicit
support for the OTN control layer. Requirements for the definition
of the OTN control plane (also referred to as Automatic Switched
Transport Network û ASON) are currently under definition at the ITU-
T.
Consequently, Generalized MPLS (GMPLS) as specified in [GMPLS-SIG],
can more than certainly provide the efficient "control-plane
service" needed by the OTN specifications. Moreover, GMPLS can give
fundamental indications in terms of how OTN can be controlled and
where some additional features have to added (if needed) at the
optical transmission layer level, in order to hit the goal of
intelligent optical networks.
Today, GMPLS efforts are directed in extending IP well known
technology to control and manage lower non-packet based layered
networks. Using the same framework and the same kinds of signalling
and routing protocols suite to control multiple layers will not only
reduce the overall complexity of designing, deploying and
D.Papadimitriou - Internet Draft û Expires December 2001 2
draft-bellato-ccamp-g709-framework-00.txt June 2001
maintaining OTN networks but also allow potentially two contiguous
layers to inter-operate when using either an overlay, an augmented
or a peer model. In the mean time, GMPLS is very suitable for
controlling each layer completely independently.
Moreover, GMPLS can provide new capabilities and features for OTN
such as flexible and distributed LSP establishment (today performed
through the use of centralized Network Management Systems - NMS),
multi-layer circuit establishment and GMPLS-based restoration
methods that are of paramount importance for operators and carriers.
2. Current Solutions
In this section, we describe the G.709 specification foundations.
2.1 Pre-OTN DWDM Development
ITU-T G.709 describes also pre-OTN WDM development for backward
compatibility with state of the art equipmentÆs. Pre-OTN development
has generated the current OTN development at the ITU-T but also the
current MPLambdaS and All-optical developments at the IETF for the
next generation optical networks.
Pre-OTN DWDM has been developed during the last years in order to
overcome the bandwidth limitations and increase the bit-rate per
fiber until several Tbps per fiber. Tomorrow, pre-OTN DWDM systems
will provide up to 1000 wavelengths at 2.5 Gbps (or 500 x 10 Gbps or
250 x 40 Gbps) per fiber. This development includes the definition
of point-to-point DWDM optical channels on top of a mesh optical
topology including Optical Cross-Connects (OXC) or Photonic Cross-
Connects (PXC). A PXC is defined as an all-optical device (i.e. no
O/E) and an OXC as a bit-rate transparent device (i.e. it provides
O/E/O conversion at each interface).
The signalling paradigm developed for Lambda-switched LSP-capable
networks has been included of the MPLS signalling paradigm. The MPLS
generalization for fiber (space switching) lambda (wavelength
switching), TDM (circuit switching) and packet LSPs (packet
switching) is referred to as Generalized MPLS [GMPLS-SIG].
The current bandwidth bottleneck is overcome by the use of DWDM
systems. DWDM systems allow the multiplexing of more than 160
wavelengths of 10 Gbps (1.6 Tbps per fiber with a 25 GHz spacing) by
using simultaneously both the C-band and the L-band. Today, some
vendors are proposing a lambda spacing of 12.5 GHz. Consequently, it
will be possible to house 320 wavelengths of 10 Gbps in a single
fiber (for a total throughput of 3.2 Terabits per fiber).
A complementary method for increasing the effective capacity of a
DWDM system is to include the 1480nm (S-Band) and 1650nm (U-Band)
together with the deployment of fibers covering an ultra-wide
waveband from 1460 to 1675nm (i.e. from the S-Band to the U-Band).
D.Papadimitriou - Internet Draft û Expires December 2001 3
draft-bellato-ccamp-g709-framework-00.txt June 2001
Nevertheless, the ITU-T currently refers to 50 GHz spacing within
the so-called ITU-T Grid, and in order to guarantee line interface
interoperability, [ITUT-G.962] recommends 200 GHz wavelength
spacing.
In the pre-OTN application, client signals (STM-N, STS-N, GbE, IP,
etc.) are directly mapped on wavelength through the use of a
mapping-framing variable-length layer. This means that this
development does not include G.709 client-signal mapping
specification through the definition of a dedicated framing
protocol.
Moreover, additional standard Transparency levels to the one defined
for SONET/SDH networks are defined for pre-OTN networks.
2.2 OTN Standard
Optical networks include a set of functionality providing transport,
multiplexing, routing, supervision and survivability of client
signals that are processed predominantly in the optical domain.
Optical signals are characterized by wavelength and may be processed
per wavelength or as a wavelength division multiplexed group.
The OTN model is decomposed into independent (transport) network
layers where each layer can be separately partitioned in a way that
reflects its internal structure. So that the OTN model refers to a
layered structure comprising a Digital and an Optical Transport
Hierarchy (OTH). The latter is constituted by the following network
layers:
- Optical Transmission Section (OTS) layer: This network layer
provides functionality for transmission of optical signals on
optical media of various types. This layer ensures the integrity
and maintenance of the optical transmitted signal by overhead
processing
- Optical Multiplex Section (OMS) layer: This network layer provides
functionality for networking of a multi-wavelength optical signal.
A "multi-wavelength" signal includes the case of just one optical
channel. This layer ensures the integrity and maintenance of the
multi-wavelength signal by overhead processing.
- Optical Channel (OCh) layer: this network layer provides end-to-
end networking of optical channels for transparently conveying
client information of various formats (e.g. SDH STM-N, Sonet OC-N,
ATM, IP, etc.). The capabilities of this network layer concern
With connection rearrangement for flexible routing, overhead
processing, administration and maintenance functions.
For the three layers specified above, non-associated overhead is
transported via the Optical Supervisory Channel (OSC) in order to
manage the optical connectivity. It has to be noted that these three
layers are common to both pre-OTN and OTN applications.
D.Papadimitriou - Internet Draft û Expires December 2001 4
draft-bellato-ccamp-g709-framework-00.txt June 2001
As far as the client signal handling is concerned, the Digital
Wrapper layer is further layered as follows:
- The Optical Channel Transport Unit (OTUk) provides FEC
capabilities and optical section protection and monitoring
capabilities.
- The Optical Channel Data Unit (ODUk) layer provides client
independent connectivity, connection protection and monitoring
(also without the need to terminate the overhead information,
the ODUk overhead may be monitored non-intrusively).
- Clients signals i.e. STM-N signals, IP packets, ATM cells and
Ethernet frames are mapped (meaning digitally wrapped) into a new
structured frame defined as Optical Channel Payload Unit (OPUk).
For each of the three layers specified above, an associated (in-
band) overhead carrying the management information is added inside
the framed structure itself. Notice, that only the ODUk (k= 1, 2, 3)
and OCh are defined today as networking layers. The OTN layered
transport structure can be schematically represented as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ===========================
| OCh Payload Unit (OPUk) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---------------------------
| OCh Data Unit (ODUk) | Digital Path Layer
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---------------------------
| OCh Transport Unit (OTUk) | Digital Section Layer
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ===========================
| Optical Channel Layer (OCh) |
+-----------------------------------+ Optical Channel Layer
| Optical Channel Multiplexing |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ===========================
| Optical Multiplex Section OMS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Optical Physical Section
| Optical Transmission Section OTS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ===========================
The OPUk, ODUk and OTUk layers constitute the Digital Transport
Hierarchy also referred to as Digital Wrapper Layer.
The development of a digital and an optical transport hierarchy
(i.e. networking layer) is required for the following reasons:
- It is the next step (after TDM - SDH/SONET) to support ever
growing data driven needs for bandwidth and emergence of new
broadband services
- To support next generation Terabit/second per fiber via DWDM lines
at the transport level as well as optical channels at 2.5 Gbps, 10
Gbps and 40 Gbps bit rates at wire speed level (and in the future
160 Gbps currently under definition)
- To provide network operational management, planning,
administration, survivability, and finally cost of maintenance
limited only to the OTUk/ODUk rates of transmission without caring
about the granularity of the client signal.
The OTN Specification is described in details in the next section.
D.Papadimitriou - Internet Draft û Expires December 2001 5
draft-bellato-ccamp-g709-framework-00.txt June 2001
4. Optical Transport Networks Specification
The OTN specifies an Optical Transport Hierarchy (OTH) supporting
the operation and management aspects of optical networks of various
architectures such as point-to-point, ring and mesh architectures.
The G.709 specification defines the interfaces of the OTN to be used
within and between sub-networks of the optical network, in terms of:
- Optical Transport Hierarchy (OTH)
- functionality of the overhead in support of multi-wavelength
optical sub-networks
- frame structures
- bit rates
- formats for mapping client signals
The OTN interfaces specifications can be applied at User to Network
Interfaces (UNI) and Network Node Interfaces (NNI) of the OTN. The
overhead functionality necessary for operations and management of
optical sub-networks is also defined. For interfaces used within
optical sub-networks, the aspects related to the interface depend on
the optical technology progress and so are not covered by G.709
recommendation. This is within the scope of other ITU-T
recommendations [ITUT-G959.1].
4.1 Optical Transport Hierarchy (OTH)
The Optical Transport Hierarchy (OTH) structure is defined as
specified in [ITUT-G.872] that defines the Optical Channel (OCH)
layer. The OTH further sub-structured the OCh layer in sub-layer
networks in order to support the network management and supervision
functions such as:
- The Optical Channel with full (OCh) or reduced functionality
(OChr), provides transparent network connections between 3R
regeneration points in the OTN.
- The fully standardized Optical Channel Transport Unit-k (OTUk)
which provides supervision and conditions the signal for transport
between regeneration points in the OTN (1R, 2R and for pre-OTN
only, 3R).
- The Optical Channel Data Unit (ODUk) which provides
. tandem connection monitoring (ODUk-TCM),
. end-to-end path monitoring (ODUk-PM)
- The Optical Channel Payload Unit (OPUk) which provides adaptation
of client signals
The Optical Transport Module-n (OTM-n) is the information structure
used to support OTN interfaces. Two OTM-n structures are defined:
- OTM interfaces with full functionality (OTM-n.m)
- OTM interfaces with reduced functionality (OTM-0.m, OTM-nr.m)
D.Papadimitriou - Internet Draft û Expires December 2001 6
draft-bellato-ccamp-g709-framework-00.txt June 2001
The reduced functionality OTM interfaces are defined with 3R
processing at each end of the OTN.
4.1.1 Full Functional Stack: OTM-n.m
With a full functional stack (OTM-n.m), up to n OCC are multiplexed
into an OCG-n.m using wavelength division multiplexing. The OCC
tributary slots of the OCG-n.m can be of different size depending on
the value of the index m (m = 1, 2, 3, 12, 23 or 123). The OCG-n.m
is transported via the OTM-n.m.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OCh Payload Unit OPUk |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OCh Data Unit ODUk |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OCh Transport Unit OTUk | ----------------------------
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Optical Boundary
| Optical Channel Layer OCh | ----------------------------
+-------------------------------------+
| Optical Channel Carrier (OCC) | ^
+-------------------------------------+ | Wavelength Multiplexing
| Optical Carrier Group (OCG-n.m) | v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optical Multiplex Section OMSn |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optical Transmission Section OTSn |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OTM-n.m (n > 1)
For the case of the full functional OTM-n.m interfaces, the OSC is
multiplexed into the OTM-n.m using wavelength division multiplexing.
4.1.2 Reduced Functionality Stack: OTM-0.r and OTM-nr.m
The OTM with reduced functionality could be either
- OTM-0: consists of a single optical channel without a specific
wavelength assigned (see Figure)
- OTM-nr.m: consists of up to n multiplexed optical channels. Non
associated overhead is not supported (see Figure)
The OTM-nr.m/OTM-0.m is the information structure used to support
Optical Physical Section (OPS) layer connections in the OTN.
The order of an OTM-nr is defined by the order of the OCG-nr that it
supports. Note that the first version of G.709, only includes
reduced functionality for standardized inter-domain interfaces
(IrDI).
1. OTM-nr.m
D.Papadimitriou - Internet Draft û Expires December 2001 7
draft-bellato-ccamp-g709-framework-00.txt June 2001
Up to n OCCr are multiplexed into an OCG-nr.m using wavelength
division multiplexing. The OCCr tributary slots of the OCG-r.m can
be of different size (m = 1, 2, 3, 12, 23 or 123). The OCG-nr.m is
transported via the OTM-nr.m.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OCh Payload Unit (OPUk) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OCh Data Unit (ODUk) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OCh Transport Unit (OTUk) | ----------------------------
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Optical Boundary
| Optical Channel Layer (OChr) | ----------------------------
+-------------------------------------+
| Optical Channel Carrier (OCCr) | ^
+-------------------------------------+ | Wavelength Multiplexing
| Optical Carrier Group (OCG-nr.m) | v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Optical Physical Section (OPSn) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OTM-nr.m (n > 1)
2. OTM-0r.m (OTM-0.m)
Only one OCCr tributary slot is provided so that the OCG-0r.m is not
defined. Consequently, reduced functionality OTM-0r.m stack does not
support wavelength division multiplexing functionality. The OCCr
tributary slot can be of different size (m = 1, 2 or 3). The OCCr is
transported via the OTM-0.m.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OCh Payload Unit (OPUk) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OCh Data Unit (ODUk) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OCh Transport Unit (OTUk) | ----------------------------
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Optical Boundary
| Optical Channel Layer (OChr) | ----------------------------
+-------------------------------------+
| Optical Channel Carrier (OCCr) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Optical Physical Section (OPS0) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OTM-0.m (n = 0)
4.2 Optical Channel Encapsulation
D.Papadimitriou - Internet Draft û Expires December 2001 8
draft-bellato-ccamp-g709-framework-00.txt June 2001
An overhead is associated to the OPUk, the ODUk and the OTUk
signals. Moreover, the OTUk signal can include a tailer FEC.
As not indicated in the following figure, the control non-associated
overhead at the lower OCh level is multiplexed within the OTM
Overhead Signal (OOS) and then inserted to the OSC. The OOS is the
information structure used for transport of OTM non-associated
overhead over the OSC. The non-associated overhead consists of the
Optical Transmission Section (OTS) overhead, Optical Multiplex
Section (OMS) overhead and Optical Channel (OCh) non-associated
overhead; it is characterized by its frame structure, bit rate and
bandwidth.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client PDU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|OH | OCh Payload Unit Payload (OPUk) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|OH | OCh Data Unit Payload (ODUk) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|OH | OCh Transport Unit Payload (OTUk) | FEC |
+===============================================+=====+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optical Channel Layer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. /
. --------------------------------------------
. /
+-------+ +-------+ +-------+ +-------+ +-------+
| OCC | | OCC | | OCC | | OCC | | OCC |
+-------+ +-------+ +-------+ +-------+ +-------+
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+
| Optical Multiplex Section OMSn | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPS |
| Optical Transport Section OTSn | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+
The optical channel network-layer overhead bytes defined in [ITUT-
G.709] support the following capabilities:
- Forward Error Correction (FEC)
- Performance Monitoring (PM)
- Network Fault localization
- Network Restoration Signaling
D.Papadimitriou - Internet Draft û Expires December 2001 9
draft-bellato-ccamp-g709-framework-00.txt June 2001
- Network General Communications Channels (GCC)
- Manufacturer-Specific Communications Channel
4.3 Signal Types
Signal types defined by the [ITUT-G709] specification can be divided
in Optical Channel Unit layer and Optical Transport Module (OTM).
The Payload Unit layer can itself be sub-divided in OCh Payload
Unit, OCh Data Unit and OCh Transport Unit. The Appendix 2 describes
the indexes used within the [ITUT-G709] terminology.
4.3.1 OPUk Signal
Optical channel Payload Unit (OPU) is defined as a structured signal
of order k (k = 1, 2, 3) and referred to as OPUk signal. The OPUk
frame structure is organized in an octet based block frame structure
with 4 rows and 3810 columns. The two main areas of the OPUk frame
(4 x 3810 Bytes) are the OPUk Overhead area (column 15 and 16) and
OPUk Payload area (columns 17 to 3824).
4.3.2 ODUk Signal
Optical channel Data Unit (ODU) is defined as a structured signal of
order k (k = 1, 2, 3) and referred to as ODUk signal. The ODUk frame
structure is organized in an octet based block frame structure with
4 rows and 3824 columns. The two main areas of the ODUk frame are
ODUk Overhead area (columns 1 to 14 with column 1 dedicated to FA
and OTUk specific alignment) and OPUk area (Columns 15 to 3824 which
are dedicated to the OPUk area).
4.3.3 OTUk Signal
Optical channel Transport Unit (OTU) of order k (k = 1, 2, 3)
defines the conditioning for transport over an Optical Channel
network connection. This signal is referred to as OTUk signal. The
OTUk (k=1,2,3) frame structure is based on the ODUk frame structure
and extends it with a forward error correction (FEC). Scrambling is
performed after FEC computation and insertion into the OTUk signal.
In the OTUk signal, 256 columns are added to the ODUk frame for the
FEC and the reserved overhead bytes in row 1, columns 9 to 14 of the
ODUk overhead are used for OTUk specific overhead, resulting in an
octet based block frame structure with 4 rows and 4080 columns (4 x
4080 bytes).
4.3.4 OTM Interface Signal
The OTM-n interface signal supports n optical channels on a single
fiber with 3R regeneration and termination of the OTUk signal on
each end. As 3R regeneration is performed on both sides of the OTM-
0.m and OTM-nr.m interfaces access to OTUk overhead is available and
maintenance as well as supervision of the interface is provided via
this overhead. Therefore non-associated OTM overhead is not required
D.Papadimitriou - Internet Draft û Expires December 2001 10
draft-bellato-ccamp-g709-framework-00.txt June 2001
across the OTM-0.m and OTM-nr.m interfaces. Consequently, Optical
Supervisory Channel (OSC) and OTM Overhead Signal (OOS) are not
supported.
In the first G.709 version, only two OTM interfaces classes with
reduced functionality are defined: OTM-0.m and OTM-16r.m.
1. OTM-16r.m Interface
The OTM-16r.m interface supports 16 Optical Channels (n = 16) on a
single optical span with 3R regeneration at each end. Six OTM-16r.m
interface signals are currently defined (m = 1, 2, 3, 12, 23, 123).
The OTM-16r.m signal is an OTM-nr.m signal with 16 Optical Channel
Carriers (OCCr) numbered OCCr #0 to OCCr #15. An Optical OSC is not
present and there is no OOS either.
For instance, the OTM16 can be separated in several cases:
- the OTM-16r.1 (with up to 16 wavelengths only at 2.5 Gbps)
- the OTM-16r.2 (with up to 16 wavelengths only at 10 Gbps)
- the OTM-16r.3 (with up to 16 wavelengths only at 40 Gbps)
- the OTM-16r.m (with up to 16 wavelengths mixing possibly bit-
rates)
At least one of the OCCr is in service during normal operation and
transporting an OTUk. However, there is no predefined order in which
the OCCrÆs are taken into service.
Note: OTM-16r.m OPS overhead is not defined. The interface will use
the OTUk SMOH in this multi-wavelength interface for supervision and
management. OTM-16r.m connectivity failure (TIM) reports will be
computed from the individual OTUk reports by means of failure
correlation in fault management.
2. OTM-0.m Interface
The OTM-0.m supports a single wavelength optical channel on a single
optical fiber with 3R regeneration at each end. Three OTM-0.m
interface signals are defined (with m = 1, 2, 3), each carrying a
single channel optical signal containing one OTUk (with k = 1, 2, 3)
signal. There is neither OSC defined nor OOS for OTM-0.m.
4.4 ODUk Mapping and Multiplexing
Since G.709 defines at the Optical Channel layer three distinct
client payload bit rates, an Optical Channel Data Unit (ODU) frame
has been defined for each of these bit rates. An ODUk refers to a
bit rate k framing signal, where k = 1 (for 2.5 Gbps), 2 (for 10
Gbps) or 3 (for 40 Gbps).
ODUk Multiplexing will be included in the future release of G.709
[ITUT-G709] while ODUk Mapping can be considered as the basic
mechanism underlying the Digital Transport Hierarchy layered
D.Papadimitriou - Internet Draft û Expires December 2001 11
draft-bellato-ccamp-g709-framework-00.txt June 2001
structure. Note that ODUk and OTUk layers still remain in the
electrical domain and are referred to as Digital Path and Digital
Section in the ITU-T G.709 recommendation.
4.4.1 ODUk Mapping
By definition in ODUk mapping, the client signal is mapped into the
OPUk. The OPUk is mapped into an ODUk and the ODUk is mapped into an
OTUk. The OTUk is mapped into an OChr and the OChr is then modulated
onto an OCCr.
The ODUk mapping is described by the following figure:
x1 x1
OTU3 <---- ODU3 <---- OPU3 <--------------------------- Client PDU
x1 x1
OTU2 <--------------- ODU2 <---- OPU2 <---------------- Client PDU
x1 x1
OTU1 <-------------------------- ODU1 <---- OPU1 ------ Client PDU
4.4.2 ODUk Multiplexing
By definition of ODUk multiplexing, an ODUk (or ODUk Tributary Unit
Group) is mapped into the OPU[k+1] if k = 1 or 2 or OPU[k+2] if k =
1. The resulting OPUk is mapped into an ODUk and the ODUk is mapped
into an OTUk. The OTUk is mapped into an OChr and the OChr is then
modulated onto an OCCr.
Therefore, two levels of ODUk multiplexing can be defined:
- ODU1 multiplexing:
. four ODU1 are multiplexed into one OPU2 which is mapped into one
ODU2
. sixteen ODU1 are multiplexed into one OPU3 which is mapped into
one ODU3
- ODU2 multiplexing:
. four ODU2 are multiplexed into one OPU3 which is mapped into
one ODU3
For instance, when multiplexing four ODU1 signals into an ODU2. The
ODU1 signals including the Frame Alignment OH and an all-0's pattern
in the OTUk Overhead locations are scrambled and then adapted to the
ODU2 clock via justification (asynchronous mapping). These adapted
ODU1 signals are byte interleaved into the OPU2 Payload area, and
their justification control and opportunity signals are frame
interleaved into the OPU2 Overhead area. ODU2 Overhead is added
after which the ODU2 is mapped into the OTU2. OTU2 Overhead and
Frame Alignment Overhead are added to complete the signal for
transport via an OTM signal.
D.Papadimitriou - Internet Draft û Expires December 2001 12
draft-bellato-ccamp-g709-framework-00.txt June 2001
The ODUk multiplexing is described by the following figure:
x1 x1
OTU3 <---- ODU3 <---- OPU3 <---------------------------- Client PDU
| <--
x4| |x16
x1 | |
OTU2 <--------------- ODU2 <----- OPU2 <---------------- Client PDU
| |
| |x4
x1 -- | x1
OTU1 <--------------------------- ODU1 <---- OPU1 ------ Client PDU
4.4.3 ODUk Inverse Multiplexing
Inverse multiplexing is currently under specification at the ITU-T.
It should be implemented by means of virtual concatenation of two or
more than two ODUk signals (defined as ODUk-Xv). The ODUk-Xv signal
can transport a non-OTN client signal (for instance, an ODU2-4v may
transport an STM-256).
The characteristic information of a virtual concatenated ODUk (ODUk-
Xv) layer network is transported via a set of X ODUk LSP, each LSP
having its own transfer delay. The egress LSR terminating the ODUk-
Xv LSP has to compensate this differential delay in order to provide
a contiguous payload at the output.
4.5 Wavelength Division Multiplexing
With reduced stack functionality: up to n (n >= 1) OCCr are
multiplexed into an OCG-nr.m using wavelength division multiplexing.
The OCCr tributary slots of the OCG-nr.m can be of different size.
The OCG-nr.m is transported via the OTM-nr.m.
x1 x1
-------- OCCr <-------- OChr <-------- OTU3
|
|xi
x1 | xj x1 x1
OTM-nr.m <------- OCG-nr.m <----- OCCr <-------- OChr <-------- OTU2
|
|xk
| x1 x1
-------- OCCr <-------- OChr <-------- OTU1
with 1 =< i + j + k =< n
With full stack functionality: up to n (n >= 1) OCC are multiplexed
into an OCG-n.m using wavelength division multiplexing. The OCC
tributary slots of the OCG-n.m can be of different size. The OCG-n.m
is transported via the OTM-n.m.
D.Papadimitriou - Internet Draft û Expires December 2001 13
draft-bellato-ccamp-g709-framework-00.txt June 2001
x1 x1
--------- OCC <-------- OCh <-------- OTU3
|
|xi
x1 | xj x1 x1
OTM-n.m <------- OCG-n.m <------ OCC <-------- OCh <-------- OTU2
| |
| |xk
| | x1 x1
| --------- OCC <-------- OCh <-------- OTU1
|
| x1
-------------- OSC <------ OOS (OTS, OMS, OCh OH)
with 1 =< i + j + k =< n
For the case of the full functionality OTM-n.m interfaces the OSC is
multiplexed into the OTM-n.m using wavelength division multiplexing.
4.6 Client Signal Mapping
The specification of the Client-layer signal encapsulation in the
OPU layer has been provided through the definition of different
solutions depending upon the type of Client-layer signal.
IP and Ethernet packet mapping is defined by the G.709 specification
through the use of the Generic Framing Procedure (GFP). This (new)
framing has been specified in order to avoid the use of Ethernet
framing or SDH/Sonet in order to encapsulate IP packets and other
types of packet (such as ESCON, Fiber Channel, etc.).
GFP is defined as a generic mechanism to transport any client layer
over a fixed data-rate optical channels (specifically, the so-called
OTN ODU of unit-k). This means that GFP idle frames must be
generated when the client layer does not send data packet.
Consequently the service offered to the client packet layer is
strictly equivalent to the one offered in SDH.
The Generic Framing Procedure (GFP) frame format is defined as:
+----------+--------------------------------------------+----------+
| Header | Payload | FCS |
| 4 bytes | 4 û 65535 bytes | Optional |
+----------+--------------------------------------------+----------+
The header (4-bytes) is composed by a PDU Length Indicator (PLI) of
2 bytes and a HEC (Header Error Control) of 2 bytes.
The GFP Idle frame format, which includes a NULL PLI and a HEC of 2
bytes, is defined as:
D.Papadimitriou - Internet Draft û Expires December 2001 14
draft-bellato-ccamp-g709-framework-00.txt June 2001
+----------+
|Idle Frame|
| 4bytes |
+----------+
GFP defines also two basic frame-oriented mechanisms:
1. GFP Frame Multiplexing: the GFP frame multiplexing is performed
on a frame-by-frame basis. When no frames are waiting, idle
frames are inserted.
2. GFP Frame Delineation Algorithm: as defined for cell delineation,
GFP frame delineation is based on the detection of correct HEC.
PLI is used to find the start of the next frame.
The GFP frames constitute the OPUk payload. The corresponding OPUk
overhead is defined as follows by the Payload Structure Identifier
(PSI) which includes the following fields:
- PT: Payload Type (1-byte)
- RES: Reserved (254-bytes)
The GFP OPUk (k = 1, 2, 3) capacity are defined such that they can
include the following client bit rates:
- GFP (OPU1): 2 488 320 kbit/s
- GFP (OPU2): 9 995 276 kbit/s
- GFP (OPU3): 40 150 519 kbit/s
Aligning the byte structure of every GFP frame with the byte
structure of the OPUk Payload performs the mapping of GFP frames.
Since the GFP frames are of variable length (the mapping does not
impose any restrictions on the maximum frame length), a frame may
cross the OPUk frame boundary.
GFP frames arrive as a continuous bit stream (Idle frames when no
client packets) with a capacity that is identical to the OPUk
payload area, due to the insertion of Idle frames at the GFP
encapsulation stage. Note that here, the GFP frame stream is
scrambled during encapsulation.
As currently defined in [ITUT-G709], GFP provides also ATM Constant
Bit Rate (CBR) û by using ATM cell multiplexing - and TDM Circuits
Encapsulation and mapping into the OPUk payload area.
5. GMPLS Extensions for G.709
Adapting GMPLS to control G.709 can be achieved by considering that
G.709 defines two transport hierarchies: a digital hierarchy (also
known as the ôDigital Wrapperö) and an optical transport hierarchy.
First, within the digital hierarchy (the previously defined ôDigital
Wrapperö), a Digital Path Layer is defined. Then, within the optical
transport hierarchy, an Optical Channel layer or Optical Path layer
including a digital OTM Overhead Signal (OOS), i.e. a non-associated
overhead, is defined.
D.Papadimitriou - Internet Draft û Expires December 2001 15
draft-bellato-ccamp-g709-framework-00.txt June 2001
GMPLS extensions for G.709 need to cover the Generalized Label
Request, the Generalized Label as well as specific technology
dependent fields such as those currently assigned to the SDH/Sonet
labels [GMPLS-SSS]. Since the multiplexing in the electrical domain
(such as ODUk multiplexing) will be added very soon into the next
version of the G.709 recommendation, we can already specify a label
space definition suitable for that purpose.
As implicitly specified in GMPLS control for SDH/SONET Networks
[GMPLS-SSS], since GFP is only used as a framing protocol we donÆt
consider this framing layer to be included into the G.709 label
space. Rather, we directly use the G.709 digital and optical
transport hierarchies in order to define the corresponding label
spaces.
5.1 G.709 Label Request Considerations
The Generalized Label Request as defined in [GMPLS-SIG], includes a
technology independent part and a technology dependent part (i.e.
the traffic parameters).
5.1.1 Technology Independent Part
As defined in [GMPLS-SIG], the LSP Encoding Type and the Generalized
Protocol Identifier (G-PID) constitute the technology independent
part. As mentioned here above, we suggest here to adapt the LSP
Encoding Type and the G-PID (Generalized-PID) to accommodate G.709
recommendation [ITUT-G709].
1. LSP Encoding Type
Since G.709 defines two networking layers (ODUk layers and OCh
layer), the LSP Encoding Type can reflect these two layers or be
considered as a common layer:
- If an LSP Encoding Type is specified per networking layer or more
precisely per group of functional networking layer (i.e. ODUk and
OCh), then the Signal Type must not reflect these layers. This
means that two LSP Encoding Types have to defined:
. one reflecting the digital hierarchy (also referred to as the
ôDigital Wrapperö layer) through the definition of the digital
path layer i.e. the ODUk layers
. the other reflecting the Optical Transport Hierarchy through the
definition of the optical path layer i.e. the OCh layer
- If the LSP Encoding Type is considered as a common space for G.709
meaning that the LSP Encoding Type doesnÆt reflect the two G.709
hierarchies, then the Signal Type must reflect these layers. This
means that at least four Signal types must be defined: one for each
ODUk signal and one for the OCh signal
D.Papadimitriou - Internet Draft û Expires December 2001 16
draft-bellato-ccamp-g709-framework-00.txt June 2001
In the latter case only one new code-point has to be defined for the
LSP Encoding Type while in the former case, two new code-points must
be defined. Therefore, the current "Digital Wrapper" code defined in
[GMPLS-SIG], could be replaced by two separated codes:
- code for the G.709 Digital Path layer
- code for the non-standard Digital Wrapper layer
In the same way, two separated code points could replace the current
defined ôLambdaö code:
- code for the G.709 Optical Channel layer
- code for the non-standard Lambda layer (also simply referred to
as Lambda layer) which the pre-OTN Optical Channel layer
Moreover, the code for the G.709 Optical Channel (OCh) layer will
indicate the capability of an end-system to use the G.709 non-
associated overhead (naOH) i.e. the OTM Overhead Signal (OOS)
multiplexed into the OTM-n.m interface signal.
2. Generalized-PID
The Generalized-PID (G-PID) as defined in [GMPLS-SIG], identifies
the payload carried by an LSP. The G-PID, which defines the client
layer of that LSP, is used by the G.709 endpoints of the LSP.
As described in [ITUT-G709], the G-PID could take one of the
following values at the Digital Path layer, in addition to the
payload identifiers already defined in [GMPLS-SIG]:
- CBRa: asynchronous Constant Bit Rate i.e. STM-16/OC-48, STM-
64/OC-192 and STM-256/OC-768
- CBRb: bit synchronous Constant Bit Rate i.e. STM-16/OC-48, STM-
64/OC-192 and STM-256/OC-768
- ATM: Constant Bit Rate at 2.5, 10 and 40 Gbps
- BSOT: non-specific client Bit Stream with Octet Timing at 2.5, 10
and 40 Gbps
- BSNT: non-specific client Bit Stream without Octet Timing at 2.5,
10 and 40 Gbps
The G-PID defined in [GMPLS-SIG] are then used when the client
payloads are encapsulated through the GFP mapping procedure:
Ethernet, ATM Mapping and Packets (translated by PoS). Other G-PID
values not defined in [GMPLS-SIG] such as Escon and Fiber Channel
could complete in the near future the list of payload mapped by
using GFP mapping procedure.
In order to include pre-OTN developments, the G-PID at the Optical
Channel Layer can in addition to the G.709 Digital Path Layer (at
2.5 Gbps i.e. ODU1, 10 Gbps i.e. ODU2 and 40 Gbps i.e. ODU3) take
one of the values currently defined in [GMPLS-SIG], in particular:
- SDH: STM-16, STM-64 and STM-256
- Sonet: OC-48, OC-192 and OC-768
- Ethernet: 1 Gbps and 10 Gbps
5.1.2 Technology Dependent Part
D.Papadimitriou - Internet Draft û Expires December 2001 17
draft-bellato-ccamp-g709-framework-00.txt June 2001
The technology dependent of the Generalized Label Request also
referred to as traffic-parameters must reflect the following G.709
features: ODUk mapping, ODUk multiplexing, OCh multiplexing, OTM
Overhead signal (OOS) and Transparency (only for pre-OTN).
1. Signal Type
As defined in [GMPLS-SSS], the traffic-parameters must include the
technology specific G.709 networking Signal Types i.e. the signals
processed by the GMPLS control-plane. The corresponding identifiers
reflect the signal types requested during the LSP setup. As
described in section 5.1, the following signal types must be
considered: ODU1, ODU2, ODU3 and (at least one) OCh. Obviously, pre-
OTN developments support only one OCh Signal Type value.
Note: Additional Signal Type code-points such as ODU4 (currently
under definition at the ITU-T) could also be reserved for future
considerations.
2. Multiplexing
A second field must indicate the type of multiplexing being
requested for ODUk LSP or OCh LSP. As defined in section 4.4, two
kinds of multiplexing are currently defined: flexible multiplexing
(or simply multiplexing) and inverse multiplexing.
At the ODUk layer (i.e. digital path layer), flexible multiplexing
as described in Section 4.4, refers to the mapping of an ODU2 into
four arbitrary OPU3 tributary slots (i.e. each slot containing one
ODU1) arbitrarily selected. Inverse multiplexing currently under
definition at ITU-T should also be considered. The requested
multiplexing type must include a default value indicating that
neither ODUk flexible multiplexing nor ODUk inverse multiplexing is
requested.
At the Optical Channel layer, flexible multiplexing is not defined
today while inverse multiplexing means that the requested composed
signal constitutes a waveband (i.e. an optical channel multiplex). A
waveband, denoted as OCh[j.k] (j >= 1) is defined as a non-
contiguous set of identical optical channels j x OCh, each of them
is associated to an OTM-x.m (x = nr or n) sub-interface signal. The
bit rate of each OCh constituting the waveband (i.e. the composed L-
LSP) must be identical, k is unique per OCh multiplex.
Note: today both OTN and Pre-OTN specifications do not define the
optical channel multiplex. Therefore, in this context, any waveband
switching development as defined in this specification is purely
vendor specific.
Consequently, since the number of identical components included in
an ODU multiplex or an OCh multiplex is arbitrary, a dedicated field
indicating the requested number of components must also be defined
D.Papadimitriou - Internet Draft û Expires December 2001 18
draft-bellato-ccamp-g709-framework-00.txt June 2001
in order to reflect individual signals constituting the requested
LSP.
3. OTM Overhead Signal (OOS)
A dedicated field should indicate whether or not the non-associated
overhead is supported at the G.709 Optical Channel layer. This
feature is irrelevant at the G.709 Digital Path layer and the pre-
OTN Optical Channel layer if the latter does not support non
associated overhead (naOH).
This field should also not restrict the transport mechanism of the
OTM Overhead Signal (OOS) since in-fiber/out-of-band OSC and out-of-
fiber/out-of-band transport mechanisms are allowed. This field must
ideally support the following options:
- With OTM-0r.m and OTM-nr.m interfaces (reduced functionality
stack), OTM Overhead Signal (OOS) is not supported. Therefore with
these types of interface signals, non-associated OTM overhead
indication is not required.
- With OTM-n.m interfaces (full functionality stack), the OOS is
supported and mapped into the Optical Supervisory Channel (OSC)
which is multiplexed into the OTM-n.m using wavelength division
multiplexing.
- With OTM-n.m interfaces or even with OTM-0.m and OTM-nr.m
interfaces, ônon-standardö OOS can be defined to allow for instance
interoperability with pre-OTN based devices or with any optical
devices which does not support G.709 OOS specification. This
specific OOS enables the use of any proprietary monitoring signal
exchange through any kind of supervisory channel (it can be
transport by using any kind of IP-based control channel).
4. Transparency
Transparency is only defined for pre-OTN developments since by
definition any signal transported over an OTN is fully transparent.
This feature is used to request a pre-OTN LSP (i.e. a non-standard
Lambda-LSP) including transparency support. It may also be used to
setup the transparency process to be applied in each intermediate
LSR.
As it is commonly the case today with pre-OTN capable interfaces,
three kinds of transparency levels are currently defined:
- SONET/SDH Pre-OTN interfaces with RS/Section and MS/Line overhead
transparency: the pre-OTN network is capable to transport
transparently STM-N/OC-N signals.
- SONET/SDH Pre-OTN interfaces terminating RS/Section overhead with
MS/Line overhead transparency: the pre-OTN network is capable to
transport transparently MSn signals
D.Papadimitriou - Internet Draft û Expires December 2001 19
draft-bellato-ccamp-g709-framework-00.txt June 2001
- SONET/SDH Pre-OTN interfaces terminating RS/Section and MS/Line
overhead: the pre-OTN network is capable to transport
transparently HOVC/STS-SPE signals.
Consequently, for pre-OTN Optical Channels a specific field (in the
Generalized Label Request) must indicate the transparency level
requested during the L-LSP setup. However, this field is only
relevant when the LSP Encoding Type value corresponds to the Non-
standard Lambda layer.
5.2 G.709 Label Space
The G.709 label space must include two sub-spaces: the first
reflecting the digital path layer (i.e. the ODUk layers) and the
second, the optical path layer (i.e. the OCh layer).
5.2.1 ODUk Label Space
At the Digital Path layer (i.e. ODUk layers), G.709 defines three
different client payload bit rates. An Optical Data Unit (ODU)
frame has been defined for each of these bit rates. ODUk refers to
the frame at bit rate k, where k = 1 (for 2.5 Gbps), 2 (for 10 Gbps)
or 3 (for 40 Gbps).
In addition to the support of ODUk mapping into OTUk, the G.709
label space must support the sub-levels of ODUk flexible
multiplexing (or simply ODUk multiplexing):
- ODU2 multiplexing:
. The mapping of an ODU2 into four arbitrary OPU3 tributary
slots selected arbitrarily (i.e. each slot containing one
ODU1)
- ODU3 multiplexing:
. Not applicable today since higher order OPU tributary slots
are not defined in the current [ITUT-G709] recommendation
Defining three fields (k1, k2 and k3) self-consistently specifies
the ODUk label space. The value space of the k1, k2 and k3 fields
are defined as follows:
- k1: indicates a particular ODU1 in one ODU2 (k1 = 1,..,4), ODU3
(k1 = 5,..,20); k1 values from 21 to 84 are reserved for
future use
- k2: indicates a particular ODU2 in one ODU3 (k2 = 1,..,4); k2
values from 5 to 20 are reserved for future use
- k3: k3 values (k3 = 1,..,4) are reserved for future use
If k1, k2 and k3 values are equal to zero, the corresponding ODUk
are not structured, i.e. k[i]=0 (i=1,2,3) indicates that the ODU[i]
is not structured and the ODU[i] is simply mapped into the OTU[i] as
described in Section 4.4.
D.Papadimitriou - Internet Draft û Expires December 2001 20
draft-bellato-ccamp-g709-framework-00.txt June 2001
Since k3 usage is not yet fully specified, k3 value always equals
zero, k2 valid interval is [0,4] and k1 valid interval is [0,20].
Thus, when used in a G.709 Generalized Label:
- k1: indicates a particular ODU1 in one ODU2 (k1 = 1,..,4) or in
one ODU3 (k1 = 5,..,20)
- k2: indicates a particular ODU2 in one ODU3 (k2 = 1,..,4)
If k1 and k2 values are equal to zero means non-significant: a
particular ODUk is not structured, i.e. ki=0 indicates that the ODUi
in not structured.
Examples:
- k2=0, k1=0 indicates a full ODU3 (full 40 Gbps).
- k2=0, k1=3 indicates the third unstructured ODU1 in the ODU2.
- k2=2, k1=0 indicates the second unstructured ODU2 in the ODU3.
- k2=0, k1=8 indicates the fourth unstructured ODU1 in the ODU3.
- k2=4, k1=2 indicates the second ODU1 of the fourth ODU2 in the
ODU3.
5.2.2 OCh Label Space
The OCh label space should be consistently defined as a flat value
space whose values reflect the local assignment of OCh identifiers
corresponding to the OTM-x.m sub-interface signals (m = 1, 2 or 3
and x = 0r, nr or n). The OCh identifiers could be defined as
specified in [GMPLS-SIG] either with absolute values: channel
identifiers (Channel ID) also referred to as wavelength identifiers
or relative values: channel spacing also referred to as inter-
wavelength spacing. The latter is strictly confined to a per-port
label space while the latter could be defined as a local or a global
label space.
Such an OCh label space is applicable to the OTN Optical Channel
layer and the pre-OTN Optical Channel layer.
5.3 Applications
GMPLS extensions for G.709 must support the following applications:
1. When one ODU1 (ODU2 or ODU3) non-structured signal is transported
into one OTU1 (OTU2 or OTU3) payload, the upstream node requests in
a non-structured ODU1 (ODU2 or ODU3) signal. In such conditions, the
downstream node has to return a unique label since the ODU1 (ODU2 or
ODU3) is directly mapped into the corresponding OTU1 (OTU2 or OTU3).
When a single ODUk signal is requested the downstream node has to
return a single ODUk label.
2. When one ODU2 signal is transported into an ODU3 payload, which
is sub-divided into 16 ODU1 tributary slots, the ODU1 tributary
slots (here, denoted A, B, C and D with A < B < C < D) can be
arbitrary selected. For instance, one ODU2 can be transported in
ODU1 tributary slots 5, 12, 13 and 18. Therefore, when the upstream
D.Papadimitriou - Internet Draft û Expires December 2001 21
draft-bellato-ccamp-g709-framework-00.txt June 2001
node requests in such conditions a composed ODU2 signal, the
downstream node returns four labels each of them representing a
pointer to an ODU1 tributary slot.
3. When a single OCh signal of 40Gbps is requested, the downstream
node has to return a single wavelength label to the requestor node.
4. When a composed OCh[4.2] signal is requested i.e. a waveband or
optical channel multiplex composed by four bit-rate identical OCh
signal of 10Gbps, the downstream node has to return four wavelength
labels to the requesting upstream node since the optical channels
constituting the optical multiplex are not necessarily contiguously
multiplexed.
5. When requesting multiple LSP, more than one label is returned to
the requestor node. For instance, when the downstream node receives
a 4 x ODU1 Generalized Label Request, it returns four labels to the
upstream node: the first ODU1 label corresponding to the first
signal of the LSP, the second ODU1 label corresponding to the second
signal of the LSP, etc.
6. GMPLS Signalling Transport for G.709
Furthermore, standardization is further required within ITU-T to
define an in-fiber/in-band signaling transport mechanism through an
OTN. Here, we propose the allocation of a General Communication
Channel (GCC), particularly GCC(0) at the OTUk layer and GCC(1),
GCC(2) at the ODUk layer, within the optical layer overhead to
transport the GMPLS signalling.
Notice that [ITUT-G.709] foresees also the possibility to provide
transport in-fiber/out-of-band signalling (through the use of
communication channels).
6.1 ODUk General Communication Channel
As defined in the [ITUT-G.709] recommendation, two fields of two
bytes are allocated in the ODUk Overhead to support two General
Communications Channels between any two network elements with access
to the ODUk frame structure (i.e. at 3-R regeneration points). The
bytes for GCC(1) are located in row 4, columns 1 and 2, and the
bytes for GCC(2) are located in bytes row 4, columns 3 and 4 of the
ODUk overhead.
These bytes are defined as clear channels so that the format
specification and their content can be defined for the purpose of
in-fiber/in-band signalling transport mechanism.
6.2 OTUk General Communication Channel
Similarly, one field of two bytes is allocated in the OTUk Overhead
to support two General Communications Channels between any couple of
network elements with access to the OTUk frame structure (i.e.
D.Papadimitriou - Internet Draft û Expires December 2001 22
draft-bellato-ccamp-g709-framework-00.txt June 2001
between OTUk termination points). These GCC(0) bytes are located in
row 1, columns 11 and 12 of the OTUk overhead.
7. Security Considerations
Security considerations for OTN networks are not defined in this
document.
8. References
1. [ITUT-G707] æNetwork node interface for the synchronous digital
hierarchy (SDH)Æ, ITU-T Recommendation, March 1996.
2. [ITUT-G709] æInterface for the Optical Transport Network (OTN)Æ,
ITU-T draft version, February 2001.
3. [ITUT-G872] æArchitecture of Optical Transport NetworkÆ, ITU-T
draft version, February 2001.
4. [ITUT-G962] æOptical interfaces for multi-channel systems with
optical amplifiersÆ, ITU-T Recommendation, October 1998.
5. [ITUT-GASTN] æAutomated Switched Transport NetworkÆ, ITU-T draft
version, May 2001.
6. [ITUT-GASON] æAutomated Switched Optical NetworkÆ, ITU-T draft
version, May 2001.
7. [GMPLS-ARCH] E. Mannie et al., æGeneralized Multi-Protocol Label
Switching (GMPLS) ArchitectureÆ, Internet Draft, Work in progress,
draft-many-gmpls-architecture-00.txt, February 2001.
8. [GMPLS-LDP] P. Ashwood-Smith et al., æGeneralized MPLS Signaling -
CR-LDP ExtensionsÆ, Internet Draft, Work in progress, draft-ietf-
mpls-generalized-cr-ldp-03.txt, May 2001.
9. [GMPLS-RSVP] P. Ashwood-Smith et al., æGeneralized MPLS Signaling
- RSVP-TE ExtensionsÆ, Internet Draft, draft-ietf-mpls-generalized-
rsvp-te-03.txt, May 2001.
10. [GMPLS-SIG] P. Ashwood-Smith et al., æGeneralized MPLS -
Signaling Functional DescriptionÆ, Internet Draft, Work in progress,
draft-ietf-mpls-generalized-signaling-04.txt, May 2001.
11. [GMPLS-SSS] S. Ansorge et al., æGeneralized MPLS û SDH/Sonet
SpecificsÆ, Internet Draft, Work in progress, draft-ietf-ccamp-gmpls-
sonet-sdh-00.txt, May 2001.
9. Acknowledgments
The authors would like to be thank Bernard Sales, Emmanuel Desmet,
Jean-Loup Ferrant, Mathieu Garnot and Massimo Canali for their
constructive comments and inputs.
D.Papadimitriou - Internet Draft û Expires December 2001 23
draft-bellato-ccamp-g709-framework-00.txt June 2001
This draft incorporates material and ideas from draft-lin-ccamp-ipo-
common-label-request-00.txt.
10. Author's Addresses
Michele Fontana
Alcatel TND-Vimercate
Via Trento 30,
I-20059 Vimercate, Italy
Phone: +39 039 686-7053
Email: michele.fontana@netit.alcatel.it
Germano Gasparini
Alcatel TND-Vimercate
Via Trento 30,
I-20059 Vimercate, Italy
Phone: +39 039 686-7670
Email: germano.gasparini@netit.alcatel.it
Alberto Bellato
Alcatel TND-Vimercate
Via Trento 30,
I-20059 Vimercate, Italy
Phone: +39 039 686-7215
Email: alberto.bellato@netit.alcatel.it
Gert Grammel
Alcatel TND-Vimercate
Via Trento 30,
I-20059 Vimercate, Italy
Phone: +39 039 686-7060
Email: gert.grammel@netit.alcatel.it
Jim Jones
Alcatel TND-USA
3400 W. Plano Parkway,
Plano, TX 75075, USA
Phone: +1 972 519-2744
Email: Jim.D.Jones1@usa.alcatel.com
Dimitri Papadimitriou (Editor)
Senior R&D Engineer û Optical Networking
Alcatel IPO-NSG
Francis Wellesplein 1,
B-2018 Antwerpen, Belgium
Phone: +32 3 240-8491
Email: Dimitri.Papadimitriou@alcatel.be
Eric Mannie
EBone (GTS)
Terhulpsesteenweg, 6A
1560 Hoeilaart, Belgium
D.Papadimitriou - Internet Draft û Expires December 2001 24
draft-bellato-ccamp-g709-framework-00.txt June 2001
Phone: +32 2 658-5652
Email: eric.mannie@ebone.com
Zhi-Wei Lin
Lucent Technologies
101 Crawfords Corner Rd, Rm 3C-512
Holmdel, New Jersey 07733-3030, USA
Tel: +1 732 949-5141
Email: zwlin@lucent.com
Appendix 1 û Abbreviations
1R Re-amplification
2R Re-amplification and Re-shaping
3R Re-amplification, Re-shaping and Re-timing
AI Adapted information
AIS Alarm Indication Signal
APS Automatic Protection Switching
BDI Backward Defect Indication
BEI Backward Error Indication
BI Backward Indication
BIP Bit Interleaved Parity
CBR Constant Bit Rate
CI Characteristic information
CM Connection Monitoring
EDC Error Detection Code
EXP Experimental
ExTI Expected Trace Identifier
FAS Frame Alignment Signal
FDI Forward Defect Indication
FEC Forward Error Correction
GCC General Communication Channel
IaDI Intra-Domain Interface
IAE Incoming Alignment Error
IrDI Inter-Domain Interface
MFAS MultiFrame Alignment Signal
MS Maintenance Signal
naOH non-associated Overhead
NNI Network-to-Network interface
OCC Optical Channel Carrier
OCG Optical Carrier Group
OCI Open Connection Indication
OCh Optical Channel (with full functionality)
OChr Optical Channel (with reduced functionality)
ODU Optical Channel Data Unit
OH Overhead
OMS Optical Multiplex Section
OMU Optical Multiplex Unit
OOS OTM Overhead Signal
OPS Optical Physical Section
OPU Optical Channel Payload Unit
OSC Optical Supervisory Channel
D.Papadimitriou - Internet Draft û Expires December 2001 25
draft-bellato-ccamp-g709-framework-00.txt June 2001
OTH Optical transport hierarchy
OTM Optical transport module
OTN Optical transport network
OTS Optical transmission section
OTU Optical Channel Transport Unit
PCC Protection Communication Channel
PLD Payload
PM Path Monitoring
PMI Payload Missing Indication
PRBS Pseudo Random Binary Sequence
PSI Payload Structure Identifier
PT Payload Type
RES Reserved
RS Reed-Solomon
SM Section Monitoring
TC Tandem Connection
TCM Tandem Connection Monitoring
UNI User-to-Network Interface
Appendix 2 û G.709 Indexes
- Index k: The index "k" is used to represent a supported bit rate
and the different versions of OPUk, ODUk and OTUk. k=1 represents an
approximate bit rate of 2.5 Gbit/s, k=2 represents an approximate
bit rate of 10 Gbit/s, k = 3 an approximate bit rate of 40 Gbit/s
and k = 4 an approximate bit rate of 160 Gbit/s (under definition).
The exact bit-rate values are in kbits/s:
. OPU: k=1: 2 488 320.000, k=2: 9 995 276.962, k=3: 40 150 519.322
. ODU: k=1: 2 498 775.126, k=2: 10 037 273.924, k=3: 40 319 218.983
. OTU: k=1: 2 666 057.143, k=2: 10 709 225.316, k=3: 43 018 413.559
- Index m: The index "m" is used to represent the bit rate or set of
bit rates supported on the interface. This is a one or more digit
ôkö, where each ôkö represents a particular bit rate. The valid
values for m are (1, 2, 3, 12, 23, 123).
- Index n: The index "n" is used to represent the order of the OTM,
OTS, OMS, OPS, OCG and OMU. This index represents the maximum number
of wavelengths that can be supported at the lowest bit rate
supported on the wavelength. It is possible that a reduced number of
higher bit rate wavelengths are supported. The case n=0 represents a
single channel without a specific wavelength assigned to the
channel.
- Index r: The index "r", if present, is used to indicate a reduced
functionality OTM, OCG, OCC and OCh (non-associated overhead is not
supported). Note that for n=0 the index r is not required as it
implies always reduced functionality.
D.Papadimitriou - Internet Draft û Expires December 2001 26
draft-bellato-ccamp-g709-framework-00.txt June 2001
Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
D.Papadimitriou - Internet Draft û Expires December 2001 27