CCAMP Working Group Alberto Bellato (Alcatel)
Category: Informational Draft Sudheer Dharanikota (Nayna)
Expiration Date: May 2002 Michele Fontana (Alcatel)
Germano Gasparini (Alcatel)
Nasir Ghani (Sorrento)
Gert Grammel (Alcatel)
Dan Guo (Turin)
Juergen Heiles (Siemens)
Jim Jones (Alcatel)
Zhi-Wei Lin (Lucent)
Eric Mannie (Ebone)
D. Papadimitriou (Alcatel)
S. Sankaranarayanan (Lucent)
Maarten Vissers (Lucent)
Yong Xue (WorldCom)
November 2001
Enabling GMPLS control of G.709 Optical Transport Networks
- Architectural Framework -
draft-bellato-ccamp-g709-framework-01.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 May 2002 1
draft-bellato-ccamp-g709-framework-01.txt November 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 Optical Transport Hierarchy
(OTH) defined at the ITU-T and the relationships with the current
GMPLS specification [GMPLS-ARCH]. The purpose is to determine how
the current GMPLS protocol suite can be accommodated in order to
encompass G.709-based optical networks.
DISCLAIMER
The scope of this memo is to provide basic information about ITU-T
G.709 recommendation by keeping in mind the IETF CCAMP context aka
how GMPLS shall be extended in order to provide a control plane
supporting G.709 OTN networks÷. Consequently, the presented view of
G.709 is restricted intentionally as needed from the GMPLS
perspective.
Hence, the objective of this document is not to replicate the
content of the ITU-T OTN recommendations. Therefore, the reader
interested in going into more details is kindly invited to consult
the corresponding ITU-T documents (referenced in this memo).
1. Introduction
The ITU-T recommendations "Optical Transport Networks (OTN)
Architecture" [ITU-T G.872] and "Interfaces for the OTN" [ITU-T
G.709] specify in detail the Optical Transport Hierarchy (OTH) and
corresponding functions of the interfaces for (all-)optical
networks. These include the transport of transparent digital pipes,
carried into optical channels by using the so-called digital wrapper
layer. The OTN recommendations provide an additional degree of
flexibility compared to the current pre-OTN approach (also referred
to as MPLambdaS due to the similarity between Label and Lambda
Switching when using MPLS for control plane purposes) as they enable
the multiplexing of lower bit-rate optical channel with digital
wrapper sub-structure.
Consequently, the OTN provides two fundamental levels of
flexibility. First in terms of optical channels (i.e. wavelengths)
and second, in terms of bandwidth transmission optimization by using
re-grooming capabilities without losing the integrity of the lower
bit rates pipes, filled by the access network devices since the
transport of the client signal is fully transparent.
D.Papadimitriou - Internet Draft Expires May 2002 2
draft-bellato-ccamp-g709-framework-01.txt November 2001
Today, Generalized MPLS (GMPLS) efforts are directed in extending
IP/MPLS well known technologies and protocols to control and manage
lower non-packet based networks, in particular layered networks.
Using the same framework and the same kinds of signaling and routing
protocols suite to control multiple layers will not only reduce the
overall complexity of designing, deploying and 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 perfectly suited for controlling each
layer completely independently.
Moreover, GMPLS can provide new capabilities and features for OTN
such as distributed, flexible and scalable connection i.e. LSP
establishment (today performed through the use of centralized
Network Management Systems - NMS), multi-layer circuit establishment
and distributed restoration, all methods that are of paramount
importance for operators and carriers.
Consequently, the Generalized MPLS (GMPLS) protocol suite (see
[GMPLS-ARCH]) can undoubtedly be used as the distributed "control-
plane architecture÷ requested by OTN.
In this memo, we introduce the additional signalling and traffic-
engineering routing extensions required to provide GMPLS control for
OTNs. For this purpose, we analyze the differences between Lambda
(pre-OTN) and G.709 OTN Label Switched Paths (LSP) as well as GMPLS-
based control-plane implementation aspects for such networks. G.709
connectivity and GMPLS control plane integration for (all-)optical
backbone networks are addressed through several illustrative and
detailed examples.
2. Current Solutions
In this section, we describe the G.709 OTN specification foundations
as the evolution from point-to-point Dense WDM (DWDM) link through
the pre-OTN developments(s).
2.1 Pre-OTN DWDM Development
ITU-T describes pre-OTN WDM development for backward compatibility
with state of the art equipmentËs. Pre-OTN development constitutes
the early foundation of the current OTN recommendation(s) at the
ITU-T (see ITU-T G.872, G.798 and G.709), but also the MPLambdaS
developments at the IETF for the next generation optical networks.
MPLambdaS has evolved in two ways since end 90Ës, first to the
current GMPLS control plane protocol suite at the CCAMP Working
Group and second to the so-called all-optical approach developed at
the IPO Working Group. The next paragraphs detail the key drivers
for the current pre-OTN developments.
Pre-OTN DWDM has been developed during the last years in order to
overcome the bandwidth limitations and increase the bit-rate per
D.Papadimitriou - Internet Draft Expires May 2002 3
draft-bellato-ccamp-g709-framework-01.txt November 2001
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 meshed topology
including Optical Cross-Connects (OXC) or Photonic Cross-
Connects (PXC).
Note: the following terminology is used in the next sections of this
document, a PXC is defined as an all-optical device (i.e. no O/E)
and an OXC as a non-transparent device (i.e. it provides O/E/O
conversion at each interface) so at least bit-rate dependent.
The current bandwidth bottleneck is overcome by the use of DWDM
technology enabling systems. These systems allow the multiplexing of
more than 160 wavelengths at 10 Gbps (i.e. 1.6 Tbps per fiber with
25 GHz spacing) by using simultaneously both the C-band and the L-
band. Today, some DWDM equipment reduces the channel spacing to 12.5
GHz or/and improves the bit-rate per wavelength up to 160 Gbps.
Consequently, it will be possible for instance 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).
Nevertheless, the ITU-T currently refers to 50 GHz spacing within
the ITU-T Grid, and in order to guarantee line interface
interoperability, [ITUT-G.962] currently 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
(also referred to as a digital wrapper layer). Moreover, additional
standard Transparency levels to the one defined for SONET (ANSI
T1.105) and SDH (ITU-T G.707) 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
D.Papadimitriou - Internet Draft Expires May 2002 4
draft-bellato-ccamp-g709-framework-01.txt November 2001
layered structure defining an Optical Transport Hierarchy (OTH)
comprising an optical and a digital part (or entity). The former is
composed by the following layers:
- Optical Transmission Section (OTS) layer: this networking 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 networking 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 switching layer provides end-to-
end networking of optical channels for transparently conveying
client information of various formats (e.g. SDH STM-N, Sonet STS-
N, ATM, IP, etc.). The capabilities of this network layer concern
With connection rearrangement for flexible routing, overhead
processing, administration and maintenance functions.
Note: OCh is defined as a switching layer since a connection
function (OCh-CF) for this layer exists.
For the three layers specified above, non-associated overhead (naOH)
is transported via the Optical Supervisory Channel (OSC) in order to
supervise and manage the connectivity in the optical domain. It has
to be noticed that these three layers are common to both pre-OTN and
OTN applications.
For applications with only a single optical link and no flexibility
between two 3R regenerators reduced functionality layers are
defined:
- Optical Physical Section (OPS): this layer represents a optical
single- or multi-wavelength signal on optical media of
various types with 3-R regeneration on both sides.
- Reduced functionality Optical Channel (OChr): this layer
represents a single optical channel over a single optical span
between two 3-R regenerators.
OPS and OChr have no overhead assigned. All supervision and
management functions that rely on overhead are performed at the
OTU layer (see below) which is also terminated at 3-R regenerators.
Above the OCh/OChr layer, the G.709 Digital part is further
subdivided as follows:
- The Optical Channel Transport Unit (OTUk): this networking layer
provides FEC capabilities and optical section protection and
monitoring capabilities; it also referred to as the Digital
Section layer
- The Optical Channel Data Unit (ODUk): this switching layer
D.Papadimitriou - Internet Draft Expires May 2002 5
draft-bellato-ccamp-g709-framework-01.txt November 2001
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);
it also referred to the Digital Path layer
- Clients signals i.e. STM-N signals, IP packets, ATM cells and
Ethernet frames are mapped (meaning digitally wrapped) into the
Optical Channel Payload Unit (OPUk).
For each of these digital entities specified above (the OPUk mapping
and ODUk/OTUk networking layers), 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 switching layers. The OTN layered transport
structure (with full functionality) can be schematically represented
as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ===========================
| OCh Payload Unit (OPUk) | Client Signal Adaptation
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---------------------------
| OCh Data Unit (ODUk) | Digital Path Layer
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---------------------------
| OCh Transport Unit (OTUk) | Digital Section Layer
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ===========================
| Optical Channel Layer (OCh) | Optical Channel Layer
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---------------------------
| Optical Multiplex Section OMS | Optical Multiplex Layer
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---------------------------
| Optical Transmission Section OTS | Optical Transmission Layer
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ===========================
Note: the OPUk, ODUk and OTUk constitute the Digital Transport
Hierarchy also referred to as Digital Wrapper Layer.
The OTN specification supports also layered transport structure with
reduced functionality that can be schematically represented as
follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ===========================
| OCh Payload Unit (OPUk) | Client Signal Adaptation
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---------------------------
| OCh Data Unit (ODUk) | Digital Path Layer
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---------------------------
| OCh Transport Unit (OTUk) | Digital Section Layer
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ===========================
| Reduced functionality |
| Optical Channel Layer (OChr) | Optical Channel Layer
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---------------------------
| Optical Physical Section (OPS) | Optical Multiplex
| | and Physical Layer
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ===========================
In this context, the main features the optical transport hierarchy
(i.e. networking layer) can be summarized as follows:
D.Papadimitriou - Internet Draft Expires May 2002 6
draft-bellato-ccamp-g709-framework-01.txt November 2001
- It is the next step (after SDH/SONET) to support ever growing data
driven needs for bandwidth and emergence of new broadband services
- It provides the transparent transport for any kind of
client signals including full STM-N/STS-N signals, and ODUk TDM
for higher channel bit rates
- It supports 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)
- It enables network supervision and 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 more details in Section 4. We
first give an overview of the relationship between ITU-T G.872 and
G.709 recommendations.
3. Relationship between G.872 and G.709
The ITU-T G.872 recommendation is restricted to the functional
description of optical transport networks that support digital
signals. It defines optical networks as comprising a set of
functionality providing transport, multiplexing, routing,
supervision and survivability of client signals that are processed
predominantly in the optical domain. This set of functionality for
optical networks is described from a network level viewpoint using
the generic principles defined ITU-T G.805. It provides the specific
aspects concerning the optical transport network layered structure,
characteristic information, client/server layer associations,
network topology, and layer network functionality.
In accordance with ITU-T G.805 recommendation (see [ITUT-G805]), the
optical transport network is decomposed into independent transport
layer networks where each layer network can be separately
partitioned in a way which reflects the internal structure of that
layer network.
In the following functional description, optical signals are
characterized by wavelength (or central frequency) and may be
processed per wavelength or as a wavelength division multiplexed
group of wavelengths. Latest release of ITU-T G.872 also includes
the description of OTN Time Division Multiplexing (TDM) in the
digital domain also referred to as ODUk multiplexing (see Section
5.2).
In this context, ITU-T G.872 defines the architectural and
functional aspects of OTNs while ITU-T G.709 recommendation
specifies the Optical Transport Module of order n (OTM-n) interface
signals required within and between OTN sub-networks. Using ITU-T
terminology, the interfaces defined in the G.709 recommendation are
applicable at the User to Network Interface (UNI) and Network Node
Interface (NNI) if the OTN. Both interface functions are currently
D.Papadimitriou - Internet Draft Expires May 2002 7
draft-bellato-ccamp-g709-framework-01.txt November 2001
(more than) covered by the GMPLS protocol suite and in particular by
the current signalling subset of specifications (see [GMPLS-SIG]).
In fact both interfaces perfectly fit within specific GMPLS profiles
(out of the scope of this document).
4. Optical Transport Networks Specification
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 only functionally covered
by ITU-T G.709 recommendation without limiting the implementation to
a specific technology.
4.1 Optical Transport Module (OTM)
The Optical Transport Hierarchy (OTH) structure is defined as
specified in [ITUT-G.872] which, specifies the Optical Channel (OCh)
layer. The OTH is further structured in the digital domain by sub-
dividing the OCh layer which provides transparent network
connections between 3R regeneration points in the OTN, in order to
support multiplexing, management and supervision functions:
- The fully standardized Optical Channel Transport Unit-k (OTUk)
which provides supervision and conditions the signal for transport
between regeneration points in the OTN (1-R, 2-R and for pre-OTN
only, 3-R).
- The Optical Channel Data Unit (ODUk) which provides
. time division multiplexing (ODUk-TDM)
. tandem connection monitoring (ODUk-TCM),
. end-to-end path monitoring (ODUk-PM)
- The Optical Channel Payload Unit (OPUk) which provides adaptation
of client signals and thus defined as an adaptation layer
The Optical Transport Module-n (OTM-n) is the information structure
used to support OTN interfaces. Two OTM-n structure classes are
currently 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 May 2002 8
draft-bellato-ccamp-g709-framework-01.txt November 2001
The reduced functionality OTM interfaces are defined with 3R
processing at each end of the OTN. However, the full and reduced
functionality interfaces are identical in the digital domain
including OPUk, ODUk and OTUk. The only differ in the optical
domain. The full functionality interface supports non-associated
overhead for the optical layers while reduced functionality
interface doesnËt.
The optical layer non-associated overhead currently supports the
following capabilities:
- Backward and Forward Defect Indication (BDI and FDI, resp.)
- Open Connection Indication (OCI) at OCh
- Payload Missing Indication (PMI) at OMS and OTS
- Tracing using the Trail Trace Identifier (TTI) at OTS
Note: G.709 indexes k, m, n and r are described in Appendix 2.
4.1.1 Full Functional Stack: OTM-n.m
With a full functional stack (OTM-n.m), the digital structure is
transported by the OCh. The latter has its own overhead transported
in a non-associated manner in the OTM Overhead Signal (OOS). The OCh
is modulated into a wavelength to form the Optical Channel Carrier
(OCC). Up to n OCC are multiplexed into an OCG-n.m using wavelength
division multiplexing. Together with the OMS and the OCh non-
associated overhead (OMSOH and OCHOH, respectively), the OCG-n.m
constitutes the OMS layer. In a last step, the OTS non-associated
overhead (OTSOH) is added to the OOS which is then transported on a
dedicated optical channel also referred to as the Optical
Supervisory Channel (OSC). Both OCG-n.m and OSC are transported in
the OTM-n.m interface signal.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^
| OCh Payload Unit OPUk |A| |
+-------------------------------------+-+ | Digital
| OCh Data Unit ODUk |S| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v
| OCh Transport Unit OTUk |N| -------------------------
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Optical (Analog) Boundary
| Optical Channel Layer OCh |S| -------------------------
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optical Channel Carrier (OCC) |A| -------------------------
+-------------------------------------+-+ OCh Multiplexing
| Optical Carrier Group (OCG-n.m) |A| -------------------------
+-------------------------------------+-+
| Optical Multiplex Section OMSn |N|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optical Transmission Section OTSn |N|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OTM-n.m (n > 1)
Where A: Adaptation N: Networking S: Switching layer
D.Papadimitriou - Internet Draft Expires May 2002 9
draft-bellato-ccamp-g709-framework-01.txt November 2001
The order of an OTM-n is defined by the order of the OCG-n that it
supports.
4.1.2 Reduced Functionality Stack: OTM-0r.m and OTM-nr.m
The OTM with reduced functionality could be either
- OTM-0r.m: consists of a single optical channel without a specific
assigned wavelength. Non associated overhead is not supported (see
Figure)
- OTM-nr.m: consists of up to n multiplexed optical channels. Non
associated overhead is not supported (see Figure)
Note that the first version of G.709, only defines reduced
functionality stack for standardized inter-domain interfaces.
1. OTM-nr.m
The digital signal structure is transported by the reduced
functionality Optical Channel OChr (OCh without non-associated
overhead). The OChr is then modulated into a wavelength to form the
reduced functionality Optical Channel Carrier (OCCr). Up to n OCCr
can be multiplexed into an OCG-nr.m using wavelength division
multiplexing. The OCG-nr.m is transported via the OTM-nr.m interface
signal.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^
| OCh Payload Unit (OPUk) |A| |
+-------------------------------------+-+ | Digital Domain
| OCh Data Unit (ODUk) |S| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v
| OCh Transport Unit (OTUk) |N| --------------------------
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Optical (Analog) Boundary
| Optical Channel Layer (OChr) |S| --------------------------
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optical Channel Carrier (OCCr) |A| --------------------------
+-------------------------------------+-+ OCh Multiplexing
| Optical Carrier Group (OCG-nr.m) |A| --------------------------
+-------------------------------------+-+
| | |
| Optical Physical Section (OPSn) |N|
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OTM-nr.m (n > 1)
Where A: Adaptation N: Networking S: Switching layer
The order of an OTM-nr is defined by the order of the OCG-nr that it
supports.
2. OTM-0r.m (OTM-0.m)
The digital signal structure is transported by one single reduced
functionality Optical Channel (OChr) without non-associated
D.Papadimitriou - Internet Draft Expires May 2002 10
draft-bellato-ccamp-g709-framework-01.txt November 2001
overhead. The OChr is modulated into a non-colored wavelength to
form the reduced functionality Optical Channel Carrier (OCCr).
Consequently, reduced functionality OTM-0r.m interface does not
support wavelength division multiplexing functionality. The OCCr is
transported via the OTM-0r.m (or simply OTM-0.m) interface.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^
| OCh Payload Unit (OPUk) |A| |
+-------------------------------------+-+ | Digital Domain
| OCh Data Unit (ODUk) |S| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v
| OCh Transport Unit (OTUk) |N| --------------------------
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Optical (Analog) Boundary
| Optical Channel Layer (OChr) |S| --------------------------
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^
| Optical Channel Carrier (OCCr) |A| |
+-------------------------------------+-+ |
| | | | Optical Domain
| Optical Physical Section (OPS0) |N| |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v
OTM-0r.m
Where A: Adaptation N: Networking S: Switching layer
4.2 Standardized OTM Interfaces
In the current ITU-T G.709 version, only two sub-classes of the OTM-
nr.m interfaces with reduced functionality are currently defined:
OTM-0.m and OTM-16r.m. These interfaces are only defined for inter-
domain interoperability purposes (while not strictly restricted to
this usage).
The OTM-nr.m 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-nr.m (and OTM-0r.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 across the OTM-nr.m (and OTM-0r.m) interfaces and
consequently, Optical Supervisory Channel (OSC) and OTM Overhead
Signal (OOS) are not supported.
4.2.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 with respect to the index m
values (m = 1, 2, 3, 12, 23, 123). Notice that m = 13 bit-rate is
not defined.
D.Papadimitriou - Internet Draft Expires May 2002 11
draft-bellato-ccamp-g709-framework-01.txt November 2001
The OTM-16r.m signal is an OTM-nr.m signal with 16 Optical Channel
Carriers (OCCr) numbered from OCCr #0 to OCCr #15. Moreover, the
optical OSC is not present and there is no OOS either.
For instance, the OTM-16r can be separated in several cases
depending on the m index value:
- OTM-16r.1 with up to 16 wavelengths only at 2.5 Gbps
- OTM-16r.2 with up to 16 wavelengths only at 10 Gbps
- OTM-16r.3 with up to 16 wavelengths only at 40 Gbps
- OTM-16r.m with up to 16 wavelengths mixing all possible 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: As OPS and OChr overhead is not currently defined. The
interface will use the OTUk Supervision and Management OverHead
(SMOH) in this multi-wavelength interface for supervision and
management. OTM-16r.m connectivity failure reports (using TIM
Trace Identifier Mismatch) will be computed from the individual OTUk
reports by means of failure correlation in fault management process.
4.2.2 OTM-0.m Interface
The OTM-0.m supports a single wavelength optical channel on a single
optical fiber with 3-R regeneration at each end. Three OTM-0.m
interface signals are defined with respect to the index m values 1,
2 and 3; each these of them 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.
Note: As OPS and OChr overhead is not currently defined. The
interface will use the OTUk Supervision and Management OverHead
(SMOH) in this multi-wavelength interface for supervision and
management. OTM-0r.m connectivity failure reports (using TIM Trace
Identifier Mismatch) will be computed from the individual OTUk
reports by means of failure correlation in fault management process.
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
(OPU), OCh Data Unit (ODU) and OCh Transport Unit (OTU). 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
D.Papadimitriou - Internet Draft Expires May 2002 12
draft-bellato-ccamp-g709-framework-01.txt November 2001
(4 x 3810 Bytes) are the OPUk Overhead area (column 15 and 16) and
OPUk Payload area (columns 17 to 3824).
OPUk overhead includes payload type information, multiplex structure
information in case of ODU multiplexing, concatenation information
in case of ODU virtual concatenation and mapping specific
information (e.g. justification/stuffing information and data) if
needed.
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 row 1 dedicated to FA and
OTUk specific alignment) and OPUk area (Columns 15 to 3824).
The ODUk overhead includes connectivity supervision (trace), signal
quality supervision (bit interleaved parity BIP), backward
information (for single ended maintenance) and status information
(e.g. alarm indication signal, open connection) for the end-to-end
path and 6 levels of tandem connection monitoring.
Furthermore overhead for automatic protection switching/protection
control, generic communication channels (e.g. for network management
communication or signaling), fault type and fault location
indication and experimental use.
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 includes overhead for supervision and
management purposes, frame alignment information and scrambling/line
coding for clock recovery.
The fully standardized OTUk (k = 1, 2, 3) frame structure is based
on the ODUk frame structure and extends it with a forward error
correction (FEC). The ODUk frame structure is organized in an octet
based block frame structure with 4 rows and 4080 columns. Columns 1
to 3824 are the ODUk frame and columns 3825 to 4080 contain the FEC
code. The OTUk overhead and frame alignment is contained in columns
1 to 14 of row 1.
The ODUk overhead includes connectivity supervision (trace), signal
quality supervision (bit interleaved parity BIP), backward
information (for single ended maintenance) and status information
(e.g. alarm indication signal, open connection). Furthermore
overhead for generic communication channels also referred to as GCC
(e.g. for network management communication or signaling). For frame
and multi-frame alignment AIX frame alignment bytes and a multi-
frame counter (for a 256 frame multi-frame) are used.
D.Papadimitriou - Internet Draft Expires May 2002 13
draft-bellato-ccamp-g709-framework-01.txt November 2001
The whole OTUk signal including the FEC code, excluding the six
frame alignment bytes is scrambled.
Note: In addition to the standard OTUk, non-standardized, vendor
specific OTUk formats OTUkV are allowed for intra-domain interfaces.
An OTUkV has to support the same overhead as the standard OTUk, but
it can use different (and enhanced) FEC schemes.
4.3.4 OCh Signal
The OCh consists of the single channel payload signal and non-OCh
associated overhead. The overhead includes signal status
information: forward defect information for payload and overhead,
and open connection indication.
4.3.5 OMS Signal
The OMS consists of the multi-channel payload signal and non-
associated OMS overhead. The overhead includes signal status
information: forward defect information for payload and overhead,
backward defect information for payload and overhead, payload
missing indication.
4.3.6 OTS Signal
The OTS consists of the multi-channel payload signal and non-
associated OTS overhead (OTSOH). This overhead includes signal
status information: backward defect information for payload and
overhead, payload missing indication, and connectivity supervision
information (e.g. optical section trace).
4.3.7 OTM Overhead Signal (OOS)
The OOS is the digital structure that transports the OCh, OMS and
OTS non-associated overhead. In addition it provides overhead for
generic communication channels (e.g. network management
communication, signaling, engineering order wire). The specific
frame format of the OOS and overhead coding is not defined. The OOS
is transported on the OSC. The OSC wavelength is not defined.
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 May 2002 14
draft-bellato-ccamp-g709-framework-01.txt November 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 OCh/OChr and the OCh/OChr is then
modulated onto an OCC/OCCr.
The ODUk mapping is depicted 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
In addition to the support of ODUk mapping into OTUk, the G.709
recommendation defines ODUk flexible multiplexing (or simply ODUk
multiplexing). By definition, when multiplexing ODUj into ODUk (k >
j) an ODUj is multiplexed into an ODUk Tributary Unit Group (i.e. an
ODTUG constituted by ODU tributary slots) is mapped into an OPUk.
The resulting OPUk is then mapped into an ODUk. The ODUk follows
then the rules defined ODUk mapping as described in the Section
4.4.1.
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 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 can be mapped into the OTU2. OTU2 Overhead and Frame Alignment
Overhead and FEC are added to complete the signal for transport via
an OTM signal.
In brief, ODUk multiplexing refers to multiplexing of ODUj (j = 1,
2) into an ODUk (k > j), and in particular:
- ODU1 into ODU2 multiplexing
- ODU1 into ODU3 multiplexing
- ODU2 into ODU3 multiplexing
- ODU1 and ODU2 into ODU3 multiplexing
D.Papadimitriou - Internet Draft Expires May 2002 15
draft-bellato-ccamp-g709-framework-01.txt November 2001
And, two levels of ODUk multiplexing are currently defined:
- ODU1 multiplexing:
. four ODU1 are multiplexed into one ODTUG2 mapped into one OPU2
which is then mapped into one ODU2
. sixteen ODU1 are multiplexed into one ODTUG3 mapped into one
OPU3 which is then mapped into one ODU3
- ODU2 multiplexing:
. four ODU2 are multiplexed into one ODTUG3 mapped into one OPU3
which is then mapped into one ODU3
The ODUk multiplexing (and mapping) is described by the following
figure (where Client means Client Signal):
x1 x1
OTU3 <---- ODU3 <---- OPU3 <--------------------------------- Client
<--ODTUG3-
| |
| |
|x4 |x16
x1 | |
OTU2 <----------------------- ODU2 <--- OPU2 <--------------- Client
| <-ODTUG2
| |
| |x4
x1 -------- |
OTU1 <---------------------------------------- ODU1 <- OPU1 - Client
4.4.3 ODUk Inverse Multiplexing (Virtual Concatenation)
Inverse multiplexing is implemented by means of virtual
concatenation of two (or more than two) ODUk signals resulting into
an ODUk-Xv signal. The resulting ODUk-Xv signal can then 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 the set of X ODUk signals
constituting a single connection (i.e. a single LSP), each of the X
ODUk signal 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
D.Papadimitriou - Internet Draft Expires May 2002 16
draft-bellato-ccamp-g709-framework-01.txt November 2001
|
|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.
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 OH, OMS OH, 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 payload area has been provided through the definition of
different solutions depending upon the type of Client-layer signal.
ITU-T G.709 defines a bit synchronous and asynchronous mapping for
constant bit rate (CBR) at 2.5, 10 and 40 Gbps into OPU1, OPU2 and
OPU3, respectively. The CBR signals could be for instance SDH/Sonet
or 10 GbE WAN.
IP and Ethernet packet mapping is defined by the G.709 specification
through the use of the Generic Framing Procedure (GFP) as defined in
ITU-T G.7041 recommendation. This framing procedure 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.). As such, GFP provides a generic
framing for client signals.
D.Papadimitriou - Internet Draft Expires May 2002 17
draft-bellato-ccamp-g709-framework-01.txt November 2001
Details concerning GFP are covered in Appendix 3.
5. GMPLS Signalling Extensions for G.709
Adapting the GMPLS protocol suite to control G.709 can be achieved
by considering that G.709 defines an optical transport hierarchy
subdivided into a digital part (also known as the Digital Wrapper÷)
and an optical part. In this context, adapting GMPLS to control
G.709 OTN, can be achieved by considering:
- a Digital Path layer by extending the previously defined
Digital Wrapper÷ in [GMPLS-SIG] corresponding to the ODUk
switching layer.
- an Optical Path layer by extending the Lambda÷ concept defined in
[GMPLS-SIG] to the OCh switching layer.
GMPLS extensions for G.709 need also to be covered by the
Generalized Label Request, the Generalized Label as well as specific
technology dependent fields (also referred to as traffic parameters)
such as those currently assigned to the SDH/Sonet labels [GMPLS-
SSS].
Moreover, since the multiplexing in the digital domain (such as ODUk
multiplexing) has been considered in the updated version of the
G.709 recommendation (October 2001), we can already propose a label
space definition suitable for that purpose. Notice also that
directly consider the usage of the G.709 ODUk (i.e. Digital Path)
and OCh layers in order to define the corresponding label spaces.
5.1 G.709 Label Request Considerations
A label request as defined in [GMPLS-SIG], includes a technology
independent part i.e. the Generalized Label Request and a technology
dependent part also referred to as the traffic parameters.
5.1.1 Technology Independent Part
As defined in [GMPLS-SIG], the Generalized Label Request includes
the LSP Encoding Type, Switching Type and the Generalized Protocol
Identifier (G-PID) which constitutes the technology independent part
of the label request.
As mentioned here above, we suggest here to adapt the LSP Encoding
Type, the Switching Type and the Generalized-PID (G-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:
D.Papadimitriou - Internet Draft Expires May 2002 18
draft-bellato-ccamp-g709-framework-01.txt November 2001
- 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 without
distinguishing between LSPs.
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
The fundamental point is not related to whether or not we have to
introduce one or two code-points but to the fact that a single LSP
Encoding Type will preclude ODUk switching when using reduced
functionality point-to-point optical channels (i.e. OChr). This
because the latter networking layer does not support any connection
function (i.e. OChr-CF is not defined by ITU-T G.709
recommendation).
Remember also here that the LSP encoding type represents the nature
of the links that LSP traverses, for the sake of clarity, one
assumes that when used with layer model÷ based technologies such as
G.709 OTN, the LSP Encoding type simply refers to the networking
layer which determines the LSP definition. Consequently, a G.709 OCh
LSP Encoding Type translates a G.709 OCh LSP request while a G.709
ODUk LSP Encoding Type a G.709 ODUk LSP request.
2. Switching Type
The Switching Type indicates the type of switching that should be
performed on a particular link. This field should only be used for
links that advertise more than one type of switching capability.
Noticed that in the context of layered networks the usage of this
field is strictly optional and should not impact the processing of
the other fields included in the Generalized Label Request.
D.Papadimitriou - Internet Draft Expires May 2002 19
draft-bellato-ccamp-g709-framework-01.txt November 2001
Moreover, no additional values are to be considered in order to
accommodate G.709 switching since an ODUk switching belongs to the
TDM Class while OCh switching to the OCh Class. Consequently, we
have a 1:1 mapping between the LSP Encoding Type and the Switching
Type making this field optional for G.709 LSP requests.
3. Generalized-PID (G-PID)
The G-PID (16 bits field) as defined in [GMPLS-SIG], identifies the
payload carried by an LSP, i.e. an identifier of the client layer of
that LSP. This identifier is used by the endpoints of the G.709 LSP.
When the client payload is transported over the Digital Path layer,
in addition to the payload identifiers already defined in [GMPLS-
SIG], the G-PID can be defined as one of the following:
- Asynchronous Constant Bit Rate (CBRa) i.e. mapping of STM-16/OC-
48, STM-64/OC-192 and STM-256/OC-768
- Bit synchronous Constant Bit Rate (CBRb) i.e. mapping of STM-
16/OC-48, STM-64/OC-192 and STM-256/OC-768
- ATM: mapping at 2.5, 10 and 40 Gbps
- Non-specific client Bit Stream with Octet Timing (BSOT) i.e.
Mapping of 2.5, 10 and 40 Gbps Bit Stream
- Non-specific client Bit Stream without Octet Timing (BSNT) i.e.
Mapping of 2.5, 10 and 40 Gbps Bit Stream
- ODUj into ODUk (k > j) when performing ODU multiplexing before
mapping into OTUk/OTUkV
In addition, the G-PID can take one of the following definitions
when the client payload is transported over the Optical Channel
layer, in addition to the payload identifiers already defined in
[GMPLS-SIG]:
- Constant Bit Rate (CBR) i.e. mapping of STM-16/OC-48, STM-64/OC-
192 and STM-256/OC-768
- (ODUk mapped into) OTUk/OTUkV into OCh at 2.5, 10 or 40 Gbps
When the client payloads such as Ethernet/MAC and IP/PPP are
encapsulated through the Generic Framing Procedure (GFP) (ITU-T Rec.
G.7042), we use dedicated G-PID values. Notice that additional G-PID
values not defined in [GMPLS-SIG] such as ESCON, FICON and Fiber
Channel could complete this list in the near future.
In order to include pre-OTN developments, the G-PID can take one of
the values currently defined in [GMPLS-SIG], when the client payload
is transported over an Optical Channel (i.e. a lambda):
- SDH: STM-16, STM-64 and STM-256
- Sonet: OC-48, OC-192 and OC-768
- Gigabit Ethernet: 1 Gbps and 10 Gbps
5.1.2 Technology Dependent Part
The technology dependent of the label request also referred to as
the traffic-parameters must reflect the following G.709 features:
ODUk mapping, ODUk multiplexing, OCh multiplexing and Multiple
D.Papadimitriou - Internet Draft Expires May 2002 20
draft-bellato-ccamp-g709-framework-01.txt November 2001
simultaneous requests. We also consider the support of the OTM
Overhead Signal (OOS) for informational purposes only.
1. Signal Type
As defined in [GMPLS-SSS], the traffic-parameters must include the
technology specific G.709 Signal Types i.e. the signals processed by
the GMPLS control-plane. The corresponding identifiers reflect the
Signal Types requested during the LSP setup.
For each G.709 switching layers specific Signal Types must be
considered: ODU1, ODU2, ODU3 for the Digital Path layer and (at
least one) OCh for the Optical Channel layer. In the pre-OTN case,
only one Signal Type value would be needed.
Note: Additional Signal Type code-points such as ODU4 (currently
under definition at the ITU-T) or ODU5 could also be reserved for
future considerations.
2. Multiplexing Type
As defined in section 4.4, ODUk multiplexing is currently defined in
the digital domain. Consequently, a dedicated field must indicate
the type of multiplexing being requested during the ODUk LSP setup.
The application of this field to an ODUk elementary signal results
in an ODUk multiplexed signal.
This multiplexing field specifies the type of multiplexing being
requested for ODUk LSP. Each value of this field refers to a
particular ODUk multiplexing type. Therefore we refer to this field
as the Requested Multiplexing Type (RMT). This field is set to zero
to indicate that no multiplexing is requested at all.
This field can then allow an upstream node to indicate to a
downstream node the different types of multiplexing that it
supports. However, the downstream node decides which one to use
according to its own rules. Several values could be set
simultaneously to indicate a particular choice.
Notice that this field (under the current version of the ITU-T G.709
recommendation) is not applicable. Therefore, when requesting an OCh
LSP, this field is set to its default value.
3. ODUk Multiplexing
A dedicated field must be considered which indicates the number of
ODU tributary slots used by an ODUj when multiplexed into an ODUk (k
> j) for the requested LSP, as specified by the RMT field. We refer
to this field as the Number of Multiplexed Components (NMC). This
field is thus irrelevant if no ODUk multiplexed signal is requested
and in particular at the Optical Channel layer.
D.Papadimitriou - Internet Draft Expires May 2002 21
draft-bellato-ccamp-g709-framework-01.txt November 2001
When applied at the Digital Path layer and requesting flexible
multiplexing, in particular for ODU2 connections multiplexed into an
ODU3 payload, the NMC field specifies the number of individual
tributary slots constituting the requested connection. These
components are still processed within the context of a single
connection entity.
4. ODUk Virtual Concatenation
A dedicated field must be considered to indicate the number of ODUk
elementary signals to be inversely multiplexed (i.e. virtually
concatenated) for the requested. We refer to this field as the
Number of Virtual Components (NVC). This field is thus irrelevant if
no ODUk virtually concatenated signal is requested and in particular
at the Optical Channel layer.
The NVC field indicates the number of ODU1, ODU2 or ODU3 elementary
signals that are requested to be virtually concatenated to form a
composed ODUk-Xv signal. These elementary signals must be of the
same type by definition while being co-routed since belonging to a
given LSP. This because GMPLS signalling implies today that all the
components of a composed signal must be part of the same LSP.
5. OTM Overhead Signal (OOS)
A dedicated field could optionally be provided to indicate whether
or not the non-associated overhead is supported at the G.709 Optical
Channel layer. This feature is thus irrelevant for the G.709 Digital
Path layer by definition and for the pre-OTN Optical Channel layer
since the latter does not support non-associated overhead.
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-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).
D.Papadimitriou - Internet Draft Expires May 2002 22
draft-bellato-ccamp-g709-framework-01.txt November 2001
6. Multiplication
Multiplication is the operation allowing the simultaneous setup of
more than one composed signal connection using a unique LSP request.
A composed signal is the resulting signal from the application of
the RMT, NMC and NVC fields to an elementary Signal Type. Therefore,
a dedicated field simply referred to as Multiplier must be
considered in order to specify the number of identical composed
signals requested for the multiplied LSP. Consequently, the
multiplier field will be set to one (default value) to indicate that
exactly one composed signal is being requested. Notice that current
GMPLS signalling implies today that all the composed signals must be
part of the same LSP.
7. Transparency
Transparency could be considered for pre-OTN developments since by
definition any signal transported over an OTN is fully transparent.
This feature through its corresponding field referred to as
Transparency is used when requesting 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 RSn STM-N/STS-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 STM-N/STS-N signals
- 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 and STM-N/STS-N signals limited
to a single contiguously concatenated VC-4-Nc/STS-Nc SPE
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.
With pre-OTN interfaces terminating RS/Section and MS/Line overhead,
the optical network must be capable to transport transparently
HOVC/STS-SPE signals. This transparency type is defined as the
default transparency for pre-OTN LSP and is specified value by
D.Papadimitriou - Internet Draft Expires May 2002 23
draft-bellato-ccamp-g709-framework-01.txt November 2001
zeroing all flags (default Transport OH (TOH) transparency). We
refer to [GMPLS-SSS] for an extended set of transparency flags.
Pre-OTN developments also include the following cases which
applies when the client signal is Gigabit Ethernet, ESCON, FICON
or Fiber Channel (FC):
- pre-OTN digital wrapper frame terminated; service signal is bit
stream oriented and transparently passed throughout the network
- pre-OTN case FEC frame terminated; service signal is bit stream
oriented and transparently passed through
Notice that in such a case Transparency feature is not considered
in the scope of this document.
5.2 G.709 Label Space
This section describes the Generalized Label space for the Digital
Path and the Optical Channel Layer. 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 Channel layer
(i.e. the OCh layer). The label distribution rules follows the ones
defined in [GMPLS-SSS] as detailed in Section 4.2.
5.2.1 ODUk Label
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 supports the sub-levels of ODUk flexible multiplexing
(or simply ODUk multiplexing). ODUk multiplexing refers to
multiplexing of ODUj (j = 1, 2) into an ODUk (k > j), in particular:
- ODU1 into ODU2 multiplexing
- ODU1 into ODU3 multiplexing
- ODU2 into ODU3 multiplexing
- ODU1 and ODU2 into ODU3 multiplexing
More precisely, ODUj into ODUk multiplexing (k > j) is defined when
an ODUj is multiplexed into an ODUk Tributary Unit Group (i.e. an
ODTUG constituted by ODU tributary slots) which is mapped into an
OPUk. The resulting OPUk is mapped into an ODUk and the ODUk is
mapped into an OTUk.
Therefore, the corresponding label space structure can be defined as
a tree whose root is an OTUk signal and leaves the ODUj signals (k
>= j) that can be transported via the tributary slots and switched
between these slots. A G.709 Digital Path layer label identifies the
exact position of a particular ODUj signal in an ODUk multiplexing
structure.
D.Papadimitriou - Internet Draft Expires May 2002 24
draft-bellato-ccamp-g709-framework-01.txt November 2001
The G.709 Digital Path Layer label or ODUk label is based on
definition of the three fields: k1, k2 and k3. The value of these
fields self-consistently characterizes the ODUk label space. The
value space of the k1, k2 and k3 fields is defined as follows:
1. k1 (1-bit) indicates:
- an unstructured client signal mapped into an ODU1 (k1 = 1)
via OPU1
2. k2 (3-bit) indicates:
- an unstructured client signal mapped into an ODU2 (k2 = 1)
via OPU2
- or the position of an ODU1 tributary slot in an ODTUG2 (k2 =
2,..,5) mapped into an ODU2 (via OPU2)
3. k3 (6-bit) indicates:
- an unstructured client signal mapped into an ODU3 (k3 = 1)
via OPU3
- or the position of an ODU1 tributary slot in an ODTUG3 (k3 =
2,..,17) mapped into an ODU3 (via OPU3)
- or the position of an ODU2 tributary slot in an ODTUG3 (k3 =
18,..,33) mapped into an ODU3 (via OPU3)
If label k[i]=1 (i = 1, 2 or 3) and labels k[j]=0 (j = 1, 2 and 3
with j=/=i), the corresponding ODUk signal ODU[i] is not structured
and therefore simply mapped into the corresponding OTU[i]. We refer
to this as the mapping of an ODUk into an OTUk. Therefore, the
numbering starts at 1, zero is used to indicate a non-significant
field. A label field equal to zero is an invalid value.
Examples:
- k3=0, k2=0, k1=1 indicated an ODU1 mapped into an OTU1
- k3=0, k2=1, k1=0 indicated an ODU2 mapped into an OTU2
- k3=1, k2=0, k1=0 indicates an ODU3 mapped into an OTU3
- k3=0, k2=3, k1=0 indicates the second ODU1 into an ODTUG2 mapped
into an ODU2 (via OPU2) mapped into an OTU2
- k3=5, k2=0, k1=0 indicates the fourth ODU1 into an ODTUG3 mapped
into an ODU3 (via OPU3) mapped into an OTU3
5.2.2 Label Distribution Rules
In case of ODUk in OTUk mapping, only one of label can appear in the
Label field of a Generalized Label.
In case of ODUj in ODUk (k > j) multiplexing, the explicit ordered
list of the labels in the multiplex is given (this list can be
restricted to only one label when needed). Each label indicates a
component (ODUj tributary slot) of the multiplexed signal. The order
of the labels must reflect the order of the ODUj into the multiplex
(not the physical order of tributary slots).
In case of ODUk virtual concatenation, the explicit ordered list of
all labels in the concatenation is given. Each label indicates a
D.Papadimitriou - Internet Draft Expires May 2002 25
draft-bellato-ccamp-g709-framework-01.txt November 2001
component of the virtually concatenated signal. The order of the
labels must reflect the order of the ODUk to concatenate (not the
physical order of time-slots). This representation limits virtual
concatenation to remain within a single (component) link.
In case of multiplication (i.e. when using the MT field), the
explicit ordered list of all labels taking part in the composed
signal is given. In case of multiplication of multiplexed/virtually
concatenated signals, the first set of labels indicates the first
multiplexed/virtually concatenated signal, the second set of labels
indicates the second multiplexed/virtually concatenated signal, and
so on. The above representation limits multiplication to remain
within a single (component) link.
5.2.3 Optical Channel Label
At the Optical Channel layer, the label space should be consistently
defined as a flat space whose values reflect the local assignment of
OCh identifiers corresponding to the OTM-n.m sub-interface signals
(m = 1, 2 or 3). Notice that these identifiers do not cover OChr
since the corresponding Connection Function (OChr-CF) between OTM-
nr.m/OTM-0r.m is not yet defined in [ITUT-G798].
The OCh identifiers could be defined as specified in [GMPLS-SIG]
either with absolute values: (optical) 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
former could be defined as a local or a global label space. Such an
OCh label space is applicable to both OTN Optical Channel layer and
pre-OTN Optical Channel layer. For this layer, label distribution
rules are defined in [GMPSL-SIG].
5.3 Applications
GMPLS extensions for G.709 OTN must support the following
applications:
1. ODUk in OTUk mapping: when one ODU1 (ODU2 or ODU3) non-
structured signal is transported into the payload of an OTU1
(OTU2 or OTU3), the upstream node requests results in a non-
structured ODU1 (ODU2 or ODU3) signal request.
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). Since a single ODUk mapped
signal is requested, the downstream node has to return a single
ODUk label which can be for instance one of the following when
the Signal Type = 1:
- k3=0, k2=0, k1=1 indicating a single ODU1 mapped into an OTU1
- k3=0, k2=1, k1=0 indicating a single ODU2 mapped into an OTU2
- k3=1, k2=0, k1=0 indicating a single ODU3 mapped into an OTU3
D.Papadimitriou - Internet Draft Expires May 2002 26
draft-bellato-ccamp-g709-framework-01.txt November 2001
2. ODU1 into ODUk multiplexing (k > 1): when one ODU1 is multiplexed
into the payload of a structured ODU2 (or ODU3), the upstream
node requests results in a multiplexed ODU1 signal request (RMT =
1).
In such conditions, the downstream node has to return a unique
label since the ODU1 is multiplexed into one ODTUG2 (or ODTUG3).
The latter is then mapped into the ODU2 (or ODU3) via OPU2 (or
OPU3) and then mapped into the corresponding OTU2 (or OTU3).
Since a single ODU1 multiplexed signal is requested the
downstream node has to return a single ODU1 label which can take
for instance one of the following values:
- k3=0, k2=4, k1=0 indicates the third ODU1 TS into ODTUG2
- k3=2, k2=0, k1=0 indicates the first ODU1 TS into ODTUG3
- k3=7, k2=0, k1=0 indicates the sixth ODU1 TS into ODTUG3
3. ODU2 into ODU3 multiplexing: when one unstructured ODU2 is
multiplexed into the payload of a structured ODU3, the upstream
node requests results in a multiplexed ODU2 signal request.
In such conditions, the downstream node has to return four labels
since the ODU2 is multiplexed into one ODTUG3. The latter is
mapped into an ODU3 (via OPU3) and then mapped into an OTU3.
Since an ODU2 multiplexed signal is requested, the downstream
node has to return four ODU label which can take for instance the
following values:
- k3=18, k2=0, k1=0 (first ODU TS into ODTUG3)
- k3=22, k2=0, k1=0 (fifth ODU TS into ODTUG3)
- k3=23, k2=0, k1=0 (sixth ODU TS into ODTUG3)
- k3=26, k2=0, k1=0 (ninth ODU TS into ODTUG3)
4. When a single OCh signal of 40 Gbps is requested, the downstream
node must return a single wavelength label as specified in
[GMPLS-SIG].
5. When requesting multiple ODUk LSP, an explicit list of labels is
returned to the requestor node. When the downstream node receives
a request for a 4 x ODU1 signal, it returns an ordered list of
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.
For instance, the corresponding labels can take the following
values:
- First ODU1: k3=2, k2=0, k1=0 (first ODU1 TS into ODTUG3)
- Second ODU1: k3=6, k2=0, k1=0 (fifth ODU1 TS into ODTUG3)
- Third ODU1: k3=7, k2=0, k1=0 (sixth ODU1 TS into ODTUG3)
- Fourth ODU1: k3=10, k2=0, k1=0 (ninth ODU1 TS into ODTUG3)
6. GMPLS Signalling Transport for G.709
Furthermore, ITU-T defines an in-fiber/in-band signaling transport
mechanism through an OTN by propose the allocation of a General
D.Papadimitriou - Internet Draft Expires May 2002 27
draft-bellato-ccamp-g709-framework-01.txt November 2001
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
in-fiber/out-of-band signalling transport mechanisms (through the
use of dedicated communication channels) at the OCh layer.
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 (GCC) between any pair of 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 (GCC) between any
couple of network elements with access to the OTUk frame structure
(i.e. between OTUk termination points). These GCC(0) bytes are
located in row 1, columns 11 and 12 of the OTUk overhead.
7. GMPLS TE-Routing Extensions for G.709 OTN
TE extensions are defined for OSPF and ISIS in [OSPF-TE] and [ISIS-
TE], respectively. They have been extended for GMPLS purposes in
[GMPLS-OSPF-TE] and [GMPLS-ISIS-TE]. [MPLS-HIER] introduces the
notion of Forwarding Adjacency (FA) while support of Link Bundling
is defined in [MPLS-BDL].
The scope of the TE-Routing Extensions is restricted here to intra-
domain routing. Routing information is transported by OSPF in Link
State Advertisements (LSAs) grouped in OSPF PDUs, and is transported
by IS-IS in Link State PDUs (LSPs).
As specified in [LMP], a set of data bearing links between two
adjacent LSRs is defined as a TE link (which is identified by a link
ID). GMPLS integrates the TE-link notion by defining the following
concepts:
- links that are not Packet Switch Capable (PSC) may have TE
properties; however, a Routing Adjacency (RA) cannot be brought up
directly on such links
- LSP can be advertised as a point-to-point TE-links in IGP routing
protocol, i.e. as a Forwarding Adjacency (FA); thus, an advertised
TE-link need no longer be between two direct neighbors (Forwarding
D.Papadimitriou - Internet Draft Expires May 2002 28
draft-bellato-ccamp-g709-framework-01.txt November 2001
Adjacencies (FA) are more extensively considered in [MPLS-HIER]).
- several links having the same Traffic Engineering (TE)
capabilities (i.e. same TE metric, same set of Resource Class and
same Link Multiplexing capability) can be advertised as a single
TE-link, such TE-links are referred to as link bundles whose
individual link (or data bearing links) are referred to as
component links; so there is no longer a one-to-one association
between a regular routing adjacency and a TE-link.
G.709 defines a digital hierarchy and an optical transport
hierarchy. As described in Section 2, the first one includes the
Digital Path Layer (i.e. the ODUk layers) while the OTH one includes
the Optical Channel Layer (i.e. the OCh layer). Consequently we can
define for of each of these hierarchies a separated set of specific
TLV. We refer to the first set as LD (Link Digital) and to the
second as LO (Link Optical). However, we do not foresee additional
extensions from the one defined in [GMPLS-OSPF-TE] and [GMPLS-ISIS-
TE] for pre-OTN routing domains.
Moreover for each of these sets, two specific sub-sets of
information must be transported by an extended routing protocol to
enable Traffic-Engineering of the G.709 LSPs (ODUk and OCh LSPs) in
OTN. First, a set of information describing the TE-link capabilities
(i.e. the OTM-n.m/OTM-nr.m/OTM-0.m interface capabilities)
independently of their usage must be defined. Then a set of
information describing the resources utilization (also referred to
as ODUk or OCh component allocation) used on each TE-link, i.e. the
operational status of a link. This in turn (using fine-tuned
parameter configuration) will reduce the amount of static
information (changes are less frequent when considering TE-link
capabilities) flooded throughout the routing domain. For more
dynamic TE-attributes implying more frequent changes (consider for
instance the TE-link component allocation), the information flooding
will be confined to the layer to which this information is relevant.
Therefore, for each of these sets, new TLV are defined:
1. G.709 TE-link capabilities:
- Link ODUk Mapping Capability TLV
- Link ODUk Multiplexing Capability TLV
- Link ODUk Virtual Concatenation Capability TLV
- Link OCh Multiplexing Capability TLV
2. G.709 TE-link allocation:
- Link ODUk Component Allocation TLV
- Link OCh Component Allocation TLV
It results from the TE-link definition (see [MPLS-BDL]) that each
component link of a bundled link must have the same G.709
multiplexing and concatenation capabilities as defined hereafter.
The corresponding TLVs (LD-MT, LO-MT and LD-VC) are specified once,
D.Papadimitriou - Internet Draft Expires May 2002 29
draft-bellato-ccamp-g709-framework-01.txt November 2001
and apply to each component link. No per component information or
identification is required for these TLVs.
8. Security Considerations
Security considerations for OTN networks are not defined in this
document.
9. 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 and Revision October 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, G.807, October 2001.
6. [ITUT-GASON] Automated Switched Optical NetworkË, ITU-T draft
version, G.8080, October 2001.
7. [GMPLS-ARCH] E. Mannie et al., Generalized Multi-Protocol Label
Switching (GMPLS) ArchitectureË, Internet Draft, Work in progress,
draft-ietf-ccamp-gmpls-architecture-01.txt, July 2001.
8. [GMPLS-ISIS-TE] K. Kompella et al., IS-IS Extensions in Support
of Generalized MPLS,Ë Internet Draft, Work in progress, draft-
ietf-isis-gmpls-extensions-04.txt, September 2001.
9. [GMPLS-LDP] P. Ashwood-Smith, L. Berger et al., Generalized MPLS
Signaling -CR-LDP ExtensionsË, Internet Draft, Work in progress,
draft-ietf-mpls-generalized-cr-ldp-04.txt, July 2001.
10. [GMPLS-OSPF-TE] K. Kompella et al., OSPF Extensions in Support
of Generalized MPLS,Ë Internet Draft, Work in progress, draft-
ietf-ccamp-ospf-gmpls-extensions-00.txt, September 2001.
11. [GMPLS-RSVP] P. Ashwood-Smith, L. Berger et al., Generalized
MPLS Signaling - RSVP-TE ExtensionsË, Internet Draft, Work in
progress, draft-ietf-mpls-generalized-rsvp-te-05.txt, October
2001.
12. [GMPLS-SIG] P. Ashwood-Smith, L. Berger et al., Generalized MPLS
- Signaling Functional DescriptionË, Internet Draft, Work in
progress, draft-ietf-mpls-generalized-signaling-06.txt, October
2001.
D.Papadimitriou - Internet Draft Expires May 2002 30
draft-bellato-ccamp-g709-framework-01.txt November 2001
13. [GMPLS-SSS] E. Mannie et al., Generalized MPLS SDH/Sonet
SpecificsË, Internet Draft, Work in progress, draft-ietf-ccamp-
gmpls-sonet-sdh-02.txt, October 2001.
14. [ISIS-TE] T. Li et al.,IS-IS Extensions for Traffic
EngineeringË, draft-ietf-isis-traffic-04.txt, Internet Draft,
Work in Progress, August 2001.
15. [MPLS-BDL] K. Kompella et al., Link Bundling in MPLS Traffic
Engineering,Ë Internet Draft, draft-kompella-mpls-bundle-05.txt,
March 2001.
16. [OSPF-TE] D. Katz et al., "Traffic Engineering Extensions to
OSPF", draft-katz-yeung-ospf-traffic-06.txt, Internet Draft, Work
in progress, September 2001.
10. 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.
This draft incorporates material and ideas from draft-lin-ccamp-ipo-
common-label-request-00.txt.
11. Author's Addresses
Alberto Bellato
Alcatel
Via Trento 30,
I-20059 Vimercate, Italy
Phone: +39 039 686-7215
Email: alberto.bellato@netit.alcatel.it
Michele Fontana
Alcatel
Via Trento 30,
I-20059 Vimercate, Italy
Phone: +39 039 686-7053
Email: michele.fontana@netit.alcatel.it
Germano Gasparini
Alcatel
Via Trento 30,
I-20059 Vimercate, Italy
Phone: +39 039 686-7670
Email: germano.gasparini@netit.alcatel.it
Nasir Ghani
Sorrento Networks
9990 Mesa Rim Road,
San Diego, CA 92121, USA
D.Papadimitriou - Internet Draft Expires May 2002 31
draft-bellato-ccamp-g709-framework-01.txt November 2001
Phone: +1 858 646-7192
Email: nghani@sorrentonet.com
Gert Grammel
Alcatel
Via Trento 30,
I-20059 Vimercate, Italy
Phone: +39 039 686-7060
Email: gert.grammel@netit.alcatel.it
Dan Guo
Turin Networks
1415 N. McDowell Blvd
Petaluma, CA 94954, USA
Phone: +1 707 665-4357
Email: dguo@turinnetworks.com
Juergen Heiles
Siemens AG
Hofmannstr. 51
D-81379 Munich, Germany
Phone: +49 89 722 - 486 64
Email: Juergen.Heiles@icn.siemens.de
Jim Jones
Alcatel
3400 W. Plano Parkway,
Plano, TX 75075, USA
Phone: +1 972 519-2744
Email: Jim.D.Jones1@usa.alcatel.com
Zhi-Wei Lin
Lucent
101 Crawfords Corner Rd, Rm 3C-512
Holmdel, NJ 07733-3030, USA
Phone: +1 732 949-5141
Email: zwlin@lucent.com
Dimitri Papadimitriou (Editor)
Alcatel
Francis Wellesplein 1,
B-2018 Antwerpen, Belgium
Phone: +32 3 240-8491
Email: dimitri.papadimitriou@alcatel.be
Siva Sankaranarayanan
Lucent
101 Crawfords Corner Rd
Holmdel, NJ 07733-3030, USA
Email: siva@hotair.hobl.lucent.com
Maarten Vissers
Lucent
D.Papadimitriou - Internet Draft Expires May 2002 32
draft-bellato-ccamp-g709-framework-01.txt November 2001
Boterstraat 45, PB-18
1270 AA Huizen, Netherlands
Email: mvissers@lucent.com
Yong Xue
WorldCom
22001 Loudoun County Parkway
Ashburn, VA 20147, USA
Phone: +1 703 886-5358
E-mail: yong.xue@wcom.com
D.Papadimitriou - Internet Draft Expires May 2002 33
draft-bellato-ccamp-g709-framework-01.txt November 2001
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
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
D.Papadimitriou - Internet Draft Expires May 2002 34
draft-bellato-ccamp-g709-framework-01.txt November 2001
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.
Appendix 3 - Client Signal Mapping and GFP
Generic Framing Procedure (GFP) provides a generic mechanism to
adapt traffic from higher-layer client signals over SONET/SDH or
OTNs. Client signals may be PDU-oriented (such as IP/PPP or Ethernet
MAC), block-code-oriented such as Enterprise System Connect (ESCON),
Fiber Connection (FICON), Fibre Channel (FC), or a Constant Bit Rate
(CBR) stream.
GFP consists of both common and client-specific aspects. Common
aspects of GFP apply to all GFP-adapted traffic. Currently, two
modes of client signal adaptation are defined for GFP:
- a PDU-oriented adaptation mode, referred to as frame-mapped GFP
- and a block-code-oriented adaptation mode, referred to as
D.Papadimitriou - Internet Draft Expires May 2002 35
draft-bellato-ccamp-g709-framework-01.txt November 2001
transparent GFP.
Client-specific mapping definitions are well underway for
Ethernet/GbE frames and HDLC, with work ongoing to include other
client signals including unspecified 8B/10B, ESCON, FICON, and FC.
In short, GFP defines a standard framing procedure for octet-
aligned, variable-length payloads for subsequent mapping into
SONET/SDH synchronous payload envelopes as defined in ANSI T1.105
(v.02) or OTN G.709 OCh payloads.
The GFP specification for SONET/SDH also leverages a parallel
activity to standardize so-called virtual concatenation (VC) of
SONET/SDH paths. In combination with VC, GFP will allow the mapping
of a wide variety of data signals over SONET/SDH.
Therefore 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 or simply ODUk). 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:
+----------+
|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:
D.Papadimitriou - Internet Draft Expires May 2002 36
draft-bellato-ccamp-g709-framework-01.txt November 2001
- 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.
D.Papadimitriou - Internet Draft Expires May 2002 37
draft-bellato-ccamp-g709-framework-01.txt November 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 May 2002 38