One document matched: draft-fontana-gmpls-control-g709-00.txt
CCAMP Working Group Michele Fontana
Internet Draft Germano Gasparini
Document: draft-fontana-gmpls-control-g709-00 Alberto Bellato
Category: Internet Draft Gert Grammel
Expiration Date: August 2001 Jim Jones
Dimitri Papadimitriou
Eric Mannie
Ebone (GTS)
Alcatel
February 2001
GMPLS Signalling Extensions for G.709 Optical Transport Networks
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].
Abstract
Along with the current development of packet over lambda switching,
there is considerable development in transport systems based on the
ITU-T G.709 specification. For that purpose, the inter-working of
G.709 capable devices on top lambda switched networks is relevant to
new optical developments at the OIF and IETF.
We propose to introduce the G.709 Optical Transport Hierarchy (OTH)
defined at the ITU-T [ITUT-G709] into the label space of GMPLS.
[GMPLS-ARCH] introduced the digital wrapper as an LSP encoding type
for GMPLS. The objective of this draft is to specify additional
Internet Draft û Expires August 2001 1
Draft-fontana-gmpls-control-g709-00.txt February 2001
extensions needed to support GMPLS [GMPLS-SIG] signalling for
Optical Transport Networks (OTN) currently under definition at the
ITU-T. These extensions indicate the bit rate and hierarchical layer
relationships needed for transport over a G.709 OTN.
1. Introduction
Recently, the ITU-T finalized the first version of the Optical
Transport Networks (OTN) standardization [ITUT-G709] at the Network-
to-Network Interface (NNI) to provide the transparent digital pipe
(digital wrapper) to be associated with the optical channels.
Soon, the multiplexing of lower bit-rate wavelength with ODU
structure will come to provide granularity transmission (where
needed) in the backbone network. Where low cost is the first goal,
OTN provides a further degree of flexibility allowing the management
of a relatively small all-optical sub-network (even if today with
some limitations).
At that point the OTN will have the 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.
Unfortunately the expected flexible OTN architecture has today no
explicit association with a control layer, without which the future
deployment of OTN equipment is really questionable. In any case,
[ITUT-G709] foresees some margins for future evolutions that could
be taken into consideration for future explicit support of the
control layer. The forthcoming Automated Switched Transport Network
[ITUT-GASTN] should overcome the deployment at the boundary layer.
GMPLS (as specified in [GMPLS-SIG], is today certainly the best
candidate to provide the guidelines for the "control service" needed
by the OTN. Moreover GMPLS may give today fundamental indications in
terms of how OTN can be controlled and where something else (if
needed) is to be added to the physical transmission level, which is
open enough to hit the goal for the future intelligent optical
networks.
2. Current Solutions
In this section, we describe the G.709 specification foundations:
2.1 Pre-OTN DWDM Development
ITU-T G709 describes also pre-OTN WDM development for backward
compatibility with the state of the art of the equipments. Pre-OTN
development has generated the current OTN development at the ITU-T
but also the current all-optical development at the OIF and the
IETF.
Internet Draft û Expires August 2001 2
Draft-fontana-gmpls-control-g709-00.txt February 2001
Pre-OTN DWDM has been developed during the last years in order to
overcome the drawbacks of synchronous transmission. 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. providing 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 the C-band and the L-band simultaneously. Some vendors are
proposing a lambda spacing of only 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). Note that the
ITU-T currently only specifies 50 GHz spacing in [ITUT-G692] within
the so-called ITU-T Grid, in order to guarantee interoperability.
In the pre-OTN application, client signals (STM-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 definition through the
definition of a dedicated framing protocol. OAM (Operation and
Management) capabilities and signal quality monitoring are currently
under definition in [IPO-LMP].
2.2 OTN Standard
Optical networks are comprised of functionality providing transport,
multiplexing, routing, supervision and survivability of client
signals that are processed predominantly in the photonic domain.
Optical signals are characterized by wavelength and may be processed
per wavelength or as a wavelength division multiplexed group of
wavelengths.
The OTN model is decomposed into independent transport network
layers where each network layer can be separately partitioned in a
way that reflects the internal structure of that network layer.
So that the Optical Transport Network (OTN) layered structure is
defined as follows:
-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.
Internet Draft û Expires August 2001 3
Draft-fontana-gmpls-control-g709-00.txt February 2001
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, 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.
As far as the client handling is concerned, the OCH layer is further
layered as follows:
@ The Optical Transport Unit (OTUk) provides FEC capabilities and
optical section protection and monitoring capabilities.
@ The Optical Data Unit (ODUk) layer provides client independent
connectivity, connection protection and monitoring (also without the
need to terminate the overhead information).
@ 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 Payload Unit (OPU).
For each of the three layers specified above, an associated (in
band) overhead carrying the management information is added inside
the framed structure itself.
The need for the development of a hierarchical transport (i.e.
transport networking layer) is required for the following reasons:
- Next step (after TDM - SDH/SONET) to support ever growing data
driven needs for bandwidth and emergence of new broadband services
- Support next generation Terabit/second per fiber via DWDM lines at
the transport level as well as optical channels at 2.5 Gb/s, 10 Gb/s
and 40 Gb/s bit rates wire speed level.
- 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.
3. Optical Transport Networks
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)
Internet Draft û Expires August 2001 4
Draft-fontana-gmpls-control-g709-00.txt February 2001
- 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].
3.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)
The reduced functionality OTM interfaces are defined with 3R
processing at each end of the OTN.
3.1.1 Full Functional Stack
The full functional stack (OTM n.m) is defined as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OCh Payload Unit OPUk |
Internet Draft û Expires August 2001 5
Draft-fontana-gmpls-control-g709-00.txt February 2001
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OCh Data Unit ODUk |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----------------------------
| OCh Transport Unit OTUk | Optical Boundary
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----------------------------
| Optical Channel Layer OCh |
+-------------------------------------+ ^
| Optical Channel Carrier (OCC) | | Lambda Multiplexing
+-------------------------------------+ v
| Optical Carrier Group (OCG) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optical Multiplex Section OMSn |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optical Transport Section OTSn |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OTMn.m (n > 1)
Up to n 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.
For the case of the full functionality OTM-n.m interfaces, the OSC
is multiplexed into the OTM-n.m using wavelength division
multiplexing.
3.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 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).
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OCh Payload Unit OPUk |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OCh Data Unit ODUk |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----------------------------
| OCh Transport Unit OTUk | Optical Boundary
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----------------------------
| Optical Channel Layer OCHr |
+-------------------------------------+ ^
| Optical Channel Carrier (OCC-r) | | Lambda Multiplexing
+-------------------------------------+ v
| Optical Carrier Group (OCG-nr.m) |
Internet Draft û Expires August 2001 6
Draft-fontana-gmpls-control-g709-00.txt February 2001
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Optical Physical Section (OPSn) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OTM-nr.m (n > 1)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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)
3.2 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 1 describes
the indexes used within the [ITUT-G709] terminology.
3.2.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).
3.2.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).
3.2.3 OTUk Signal
Internet Draft û Expires August 2001 7
Draft-fontana-gmpls-control-g709-00.txt February 2001
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).
3.2.4 OTM Module
The OTM-n 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 OTN overhead is not required 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
interface signals are currently defined.
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.
At least one of the OCCrs is in service during normal operation and
transporting an OTUk. However, there is no predefined order in which
the OCCrs are taken into service.
There are six defined OTM-16r.m interface signals and the OTM-16r.m
multiplexing structure.
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
Internet Draft û Expires August 2001 8
Draft-fontana-gmpls-control-g709-00.txt February 2001
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.
For instance, the OTM16 can be separated in several cases:
- the OTM16.0 (with up to 16 wavelengths mixing possibly bit-rates)
- the OTM16.1 (with up to 16 wavelengths only at 2.5Gbits/s)
- the OTM16.2 (with up to 16 wavelengths only at 10Gbits/s)
- the OTM16.3 (with up to 16 wavelengths only at 40Gbits/s)
3.2.5 ODUk Multiplexing
ODUk TDM Multiplexing will be included in the future release of
G.709. Note that ODUk and OTUk still remain in the electrical domain
but referred to as Optical Channel layer within [ITUT-G709].
Two levels of multiplexing could be defined: four ODU1 can be
multiplexed in one ODU2, and four ODU2 can be multiplexed in one
ODU3.
4. 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.
4.1 Packet Mapping
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.
Internet Draft û Expires August 2001 9
Draft-fontana-gmpls-control-g709-00.txt February 2001
The GFP Idle frame format is defined as:
+----------+
|Idle Frame|
| 4bytes |
+----------+
A idle GFP frame includes a NULL PLI and a HEC of 2 bytes
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.
4.4 OCh Encapsulation
An overhead is associated to the OPUk, the ODUk and the OTUk
signals. Moreover, the OTUk signal can include a tailer FEC.
Internet Draft û Expires August 2001 10
Draft-fontana-gmpls-control-g709-00.txt February 2001
The control non-associated overhead at the lower OCh level is
multiplexed within the OOS and then inserted to the Optical
Supervisory Channel.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client PDU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|OH | OCh Payload Unit (OPUk) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|OH | OCh Data Unit (ODUk) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|OH | OCh Transport Unit (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
@ Network General Communications Channels (GCC)
@ Manufacturer-Specific Communications Channel
5. GMPLS Extensions for G.709
Adapting GMPLS to control G.709 (also previously known as the
"Digital Wrapper") seems straightforward. Note that G.709 defines
indeed two layers. First, an electrical layer (the old "Digital
Wrapper"), aka the Optical Channel Network Layer, indeed a new TDM
technology. Second, a photonic layer (with a digital OTN Overhead
Signal: OOS), i.e. a non-associated overhead.
Internet Draft û Expires August 2001 11
Draft-fontana-gmpls-control-g709-00.txt February 2001
GMPLS extensions for G.709 need to cover the Generalized Label
Request, the Generalized Label as well as specific fields currently
assigned to the SDH/Sonet labels. Since the electrical multiplexing
will be added soon, in the next version, we could already have a
label for that purpose, so that GMPLS could already consider the
requirements for G.709.
As specified already mentioned for GMPLS-over-SDH/Sonet [GMPLS-SDH],
since GFP is only used as a framing protocol we donÆt consider the
transport of MPLS label within this layer. Rather as defined for
Packet-over-SDH/Sonet, we directly use the G.709 OTH in order to
define the label space.
5.1 Generalized Label Request
The Generalized Label Request [GMPLS-SIG] currently includes the LSP
Encoding Type (i.e. Digital Wrapper) needed in order to enable the
deployment of GMPLS signalling on top of G.709 networks.
For that purpose, a new G.709 specific Generalized Label Request
needs to be defined. The information carried in a Generalized Label
Request for G.709 is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Enc. Type | Transparency | G-PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Signal Type | OOS | Resv |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
As mentioned here above, we suggest here to adapt the LSP Encoding
Type (section 3.1.1) and the GPID to G.709:
- LSP Encoding Type (see section 3.1.1 [GMPLS-SIG])
The current "Digital Wrapper" (DW) code could be replaced by two
separate codes:
- code for the G.709 Optical Channel Network Layer.
- code for a generic DW (for proprietary implementations).
In the same way, the "Lambda" code could be replaced by two
separate codes:
- code for the G.709 optical layer.
- code for a generic lambda layer (transparent).
The code for the G.709 optical layer will indicate the capability
of an end-system to use the G.709 non-associated overhead (i.e. the
OOS).
- Transparency Type: (See Section 3.1.1 [GMPLS-SIG])
Internet Draft û Expires August 2001 12
Draft-fontana-gmpls-control-g709-00.txt February 2001
This vector of flags (8 bits) indicates the type of transparency
being requested. It is only applicable to the G.709 Optical Channel
Network Layer. Note that the transparency does not change the bit
rate. This field is zeroed if only the G.709 optical layer is used.
Bit 1: indicates ODU transparency. This means that the ODU overhead
cannot be modified.
Bit 2: indicates OTU transparency. This means that the OTU overhead
and the ODU overhead cannot be modified.
- Signal Type: (See Section 3.1.1 [GMPLS-SIG])
This field (8 bits) indicates the requested G.709 signal type. The
possible values are:
Value Type
----- ----
0 irrelevant
1 2.5 Gbps
2 10 Gbps
3 40 Gbps
This field may equal to zero if only the G.709 optical layer is
used.
- OOS (OTN Overhead Signal) Type:
This field (4 bits) indicates the type of OOS for the G.709 optical
layer. Possible values are:
Value Type
----- ----
0 irrelevant
1 OOS reduced functionality (limited overhead)
2 OOS full overhead
5.2 Generalized Label
G.709 at the Optical Channel Network layer 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). Two levels of multiplexing could be defined: four ODU1 can be
multiplexed in one ODU2, and four ODU2 can be multiplexed in one
ODU3.
The G.709 Optical Channel Network Layer label has the following
format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Internet Draft û Expires August 2001 13
Draft-fontana-gmpls-control-g709-00.txt February 2001
| Reserved | k2 | k1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
k1: 0 -> 4: indicates a particular ODU1 in one ODU2.
k2: 0 -> 4: indicates a particular ODU2 in one ODU3.
If k1 and k2 are equal to zero means non-significant: a particular
ODUk is not structured, i.e. ki=0 indicates that the ODUi+1 in not
structured.
Examples:
k2=0, k1=0 indicates a full ODU3 (full 40 Gbps).
k2=2, k1=0 indicates the second unstructured ODU2 in the ODU3.
k2=4, k1=2 indicates the second ODU1 of the fourth ODU2 in the ODU3.
5.3 In-band/In-fiber GMPLS Signalling Transport
Furthermore, standardization is required within ITU-T to define an
in-fiber/in-band signaling transport mechanism through an OTN. We
propose the allocation of a General Communication Channel (GCC),
particularly GCC1, within the optical layer overhead, to transport
the GMPLS signalling.
6. Security Considerations
Security considerations are left for further study.
7. Reference
1. [ITUT-G707] æNetwork node interface for the synchronous digital
hierarchy (SDH)Æ, ITU-T Recommendation, 03/1996.
2. [ITUT-G709] æInterface for the Optical Transport Network (OTN),
ITU-T draft version, 02/2001.
3. [ITUT-G872] æArchitecture of Optical Transport NetworkÆ, ITU-T
draft version, 02/2001
5. [ITUT-G692] æOptical interfaces for multi-channel systems with
optical amplifiersÆ, ITU-T Recommendation, 10/1998.
7. [ITUT-GASTN] æAutomated Switched Transport NetworkÆ, ITU-T draft
version, 02/2001
8. [GMPLS-ARCH] E. Mannie et al., æGeneralized Multi-Protocol Label
Switching (GMPLS) ArchitectureÆ, Internet Draft, Work in progress,
draft-broad-concensus-gmpls-architecture-00.txt, February 2001.
9. [GMPLS-SDH] G. Bernstein et al., æFramework for MPLS-based
Control of Optical SDH/SONET NetworksÆ, Internet Draft, Work in
Internet Draft û Expires August 2001 14
Draft-fontana-gmpls-control-g709-00.txt February 2001
progress, draft-bms-optical-sdhsonet-mpls-control-frmwrk-00.txt,
November 2000.
10. [GMPLS-SIG] P. Ashwood-Smith et al., æGeneralized MPLS -
Signaling Functional DescriptionÆ, Internet Draft, Work in
progress, draft-ietf-mpls-generalized-signaling-00.txt, November
2000.
11. [IPO-LMP] A. Fredette et al., æLink Management Protocol (LMP)
for WDM Transmission SystemsÆ, Internet Draft, Work in progress,
draft-fredette-lmp-wdm-00.txt, November 2000.
8. Acknowledgments
The authors would like to be thank Bernard Sales, Emmanuel Desmet,
Jean-Loup Ferrant, Mathieu Garnot and Germano Gasparini for their
constructive comments and inputs.
9. 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
Papadimitriou Dimitri (Editor)
Alcatel û IPO NSG
Francis Wellesplein, 1
B-2018 Antwerpen, Belgium
Phone: +32 3 240-8491
Internet Draft û Expires August 2001 15
Draft-fontana-gmpls-control-g709-00.txt February 2001
Email: dimitri.papadimitriou@alcatel.be
Eric Mannie
Ebone/GTS
Terhulpsesteenweg, 6A
1560 Hoeilaart, Belgium
Phone: +32 2 658-5652
Email: eric.mannie@gts.com
12. 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
Internet Draft û Expires August 2001 16
Draft-fontana-gmpls-control-g709-00.txt February 2001
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
13. 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 and k = 3 an approximate but rate of 40
Gbit/s. The exact bit-rate values are in kbits/s:
. OPU: 2 488 320.000, 9 995 276.962, 40 150 519.322
. ODU: 2 498 775.126, 10 037 273.924, 40 319 218.983
. OTU: 2 666 057.143, 10 709 225.316, 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, 123, 23).
- 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.
Internet Draft û Expires August 2001 17
Draft-fontana-gmpls-control-g709-00.txt February 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
Internet Draft û Expires August 2001 18
| PAFTECH AB 2003-2026 | 2026-04-24 04:29:23 |