Anda di halaman 1dari 21

DCC Solution for SONET/SDH Systems

White Paper

Version 1.0, October 2003

DCC Solutions
for
SONET/SDH Systems

Version 1.0
October 2003

Page 1 of 1
Opencon Systems, Inc. Proprietary Information. Unauthorized Distribution is Prohibited.

DCC Solution for SONET/SDH Systems


White Paper

Version 1.0, October 2003

COPYRIGHT
This material is the property of OpenCon Systems, Inc. Unauthorized distribution is prohibited
Copyright 2003
OpenCon Systems, Inc.
All Rights Reserved

Page 2 of 2
Opencon Systems, Inc. Proprietary Information. Unauthorized Distribution is Prohibited.

DCC Solution for SONET/SDH Systems


White Paper

Version 1.0, October 2003

Table of Contents
1.

OVERVIEW

2.

SONET/SDH DATA COMMUNICATION CHANNEL

3.

SONET/SDH DCC PROTOCOL STACKS

4.

DCC SUBSYSTEM REQUIREMENTS

12

5.

DCC NETWORK CONFIGURATIONS

14

5.1

End-to-End OSI-7 Layer Communication

14

4.1.

TCP-IP to OSI-7 Mediation

15

5.2

IP Tunneling

17

6.

OCS DCC PACKAGE

19

7.

REFERENCES

20

8.

ABBREVIATIONS

21

Page 3 of 3
Opencon Systems, Inc. Proprietary Information. Unauthorized Distribution is Prohibited.

DCC Solution for SONET/SDH Systems


White Paper

Version 1.0, October 2003

1. Overview
Each SONET/SDH frame includes two Data Communication Channels (DCC) called Section DCC and
Line DCC for transporting management messages between NEs and between NEs and Management
systems. These in-band data communication channels enable service providers Operation Support
Systems (OSS) to manage SONET/SDH Network Elements (NE) without the need for an expensive outof-band data communication network.
SONET/SDH is the most widely used transport technology in carriers network today and deployment of
SONET/SDH based network equipment continues to grow as carriers extend the reach of fiber from
central offices to business locations. As the size of SONET/SDH networks grow and as carriers start
deploying systems from different vendors, managing these networks have become increasingly difficult
and complicated. To reduce the cost and complexity of managing these networks, carriers rely on
embedded Data Communication Channels (DCC) within a SONET/SDH frame and expect vendors to
provide equipments that are interoperable with the SONET equipments that are already deployed in their
networks. To ensure interoperability with the equipment deployed in the network, SONET/SDH vendors
have to support DCC standards such as Telcordias GR-253 and ITU G.7712.
Telcordias GR-253-CORE standard defines the interfaces and the communication protocols required for
transporting information over DCC. The following is a summary of Telcordia requirements pertaining to
DCC:

Communication interfaces::
(a) Data Communication Channel, X.25 interface
(b) Local Communication Network (LCN)

OSI 7-layer Protocol Stacks

SONET-specific Naming Resolution Protocol: Terminal IDentification (TID) Address


Resolution Protocol (TARP)

Network Management Protocols: Transaction Language-1 (TL-1) or Common Management


Information Protocol (CMIP)

Generic File Management System

With the explosive growth of packet-based traffic in the service providers network, the SONET/SDH
equipment vendors have started to incorporate packet network interfaces such as Ethernet into their
equipment to transport packet-based traffic over SONET/SDH network. Unlike circuit switched traffic,
packet switched traffic is bursty in nature and requires IP based signaling protocols to dynamically set up
and tear down payload paths between the NEs in the network. SONET/SDH network elements that
support packet interfaces are generally managed by IP based protocols such as SNMP and HTTP. To
manage these types of next generation SONET/SDH network elements, the embedded DCC channel has
to carry IP based management messages and has to interoperate at the DCC level with legacy network
elements that are capable of transporting OSI-based messages through DCC. To address this
interoperability problem at the DCC level, ITU G.7712 has defined the following three DCC network
domains:

Page 4 of 4
Opencon Systems, Inc. Proprietary Information. Unauthorized Distribution is Prohibited.

DCC Solution for SONET/SDH Systems


White Paper

Version 1.0, October 2003

OSI DCC network


IP DCC
OSI+IP DCC network

IP Tunneling is one of the methods recommended by ITU G.7712 for tunneling IP traffic through the OSI
based DCN network. In the following subsections, we will illustrate how IP Tunneling method can be
used to integrate next generation SONET/SDH systems with the legacy network elements.
OCS standards-based, off-the-shelf DCC System Solution shortens the DCC implementation time and is
designed to provide DCC interoperability with equipment from leading SONET/SDH equipment vendors
such as Fujitsu, Lucent and Nortel. OCS offers two standards-based DCC packages that can be used by
equipment vendors to quickly implement an interoperable DCC solution in their equipments. These two
DCC packages include support for full OSI 7-Layer Stack and an OSI three layer stack (also referred to as
Short Stack). Both full stack and short stack versions support IP Tunneling as per G.7712
recommendations. OCS solution is designed to be hardware and operating system independent and can
be easily ported to most hardware/software platforms.

Page 5 of 5
Opencon Systems, Inc. Proprietary Information. Unauthorized Distribution is Prohibited.

DCC Solution for SONET/SDH Systems


White Paper

Version 1.0, October 2003

2. SONET/SDH Data Communication Channel


Section DCC is based on three (3) bytes embedded in the SONET frame. These bytes are termed D1, D2
and D3 in the transport overhead of the Synchronous Transport Signal 1 (STS-1) frame. Figure 1 shows
the structure of the STS-1 frame.
1 byte
A1
B1
D1
H1
B2
D4
D7
D10
S1/Z1

1 byte
A2
E1
D2
H2
K1
D5
D8
D11
M0 or
M1/Z2

1 byte
J0/Z0
F1
D3
H3
K2
D6
D9
D12
E2

87 columns

STS-1 payload capacity (9 87 bytes)

Transport Overhead

Figure 1: STS-1 Frame Structure


There are 27 bytes in the transport overhead part of the STS-1 frame. They provide many features for
standard-based SONET equipment such as Automatic Protection Switching (APS).
Bytes D1, D2 and D3 provide the Section Data Communication Channel for message-based
administration, monitoring, alarm maintenance and other communication needs. The Section DCC
bandwidth is 192 Kbit/s between each pair of SONET section termination equipment. Any SONET
equipment that can extract these 3 bytes from the STS-1 frame overhead and process them is considered
to support a DCC interface. Bytes D4 through D12 form another embedded data communication channel
within SONET/SDH frame and are referred to as Line DCC. The bandwidth of Line DCC is 576 Kbit/s.
Most of the SONET equipment vendors extract and process only SDCC overhead bytes.

Page 6 of 6
Opencon Systems, Inc. Proprietary Information. Unauthorized Distribution is Prohibited.

DCC Solution for SONET/SDH Systems


White Paper

Version 1.0, October 2003

3. SONET/SDH DCC Protocol Stacks


In order to exchange SONET/SDH network management information between OSSs and SONET/SDH
NEs, a standards based management framework is needed. Telcordia has defined in GR-253-CORE
standards, a network management architecture for exchanging SONET/SDH operations messages. In
practice, SONET/SDH operations communications architectures will vary depending on deployment
configurations and applications supported by the network. Figure 2, shows an example of the SONET
/SDH Operations Communications Architecture.

NMS-1

NMS-2

Data Communications Network


EMS
LAN HUB
GNE

GNE
ADM

ADM

SONET/SDH Ring
Terminal

Terminal
ADM

ADM

Terminal

Terminal
Terminal
GNE: Gateway NE
ADM: Add-drop Multiplexer

Terminal
EMS: Element Management System
NMS: Network Management System

Figure 2: Example SONET/SDH Network


Figure 2, shows the SONET/SDH network that includes SONET/SDH Add-drop multiplexers (ADM) and
Terminals. As illustrated in the Figure, the network management systems use wide area Data
Communication Network (e.g., X.25) to manage elements in the SONET/SDH network. Figure 2, also
illustrates the configuration where two network elements communicate with each other via an intra-site
Local Area Network (LAN).
Figure 3, illustrates the protocol stacks for the X.25 DCN, the DCC and the intra-site LAN. In all three
cases, it is assumed that OSI based protocols are used for communication.

Page 7 of 7
Opencon Systems, Inc. Proprietary Information. Unauthorized Distribution is Prohibited.

DCC Solution for SONET/SDH Systems


White Paper

Application

Pre sentation
Session
Transport

Network
Data Link
Physical

Stack A: OS
(X.25 DCN)
TL1
CMISE
ROSE
ACSE

Version 1.0, October 2003


Stack B: NE
(DCC)
TL1

Stack C: NE
(LAN)
TL1
CMISE
ROSE
ACSE

CMISE
ROSE
ACSE

ASN.1/BER
Kernel/Full Duplex
TP4
CLNP
X.25
LAPB

ASN.1/BER
Kernel/Full Duplex
TP4
CLNP
ES-IS
IS-IS
LAPD

EIA-232-D
V.35

DCC

ASN.1/BER
Kernel/Full Duplex
TP4
CLNP
ES-IS
IS-IS
LLC1
CSMA/CD
AUI

10BASE2

10BASE-T

Figure 3: Protocol Components of OSI-7 layer DCC


On top of these three stacks are the TL-1 and Common Management Information Service Element
(CMISE) management applications. In this example, both TL-1 and CMISE applications are implemented
on top of OSI-7 protocols.
v

TL-1 is easily the most widely used protocol in telecommunication management today.
Most telecommunication elements in North America today are managed using TL-1. TL-1 was
designed to be a human readable machine language for craft operators and operations personnel. In
the 1980s, Telcordia adopted TL-1 as the network element management protocol for their Network
Monitoring and Analysis (NMA) system. NMA is a fault management OSS wide ly used by Regional
Bell Operating Company (RBOCs). One of the pre-requisites for deployment in a network owned by
RBOCs, is that the equipment must support TL-1 and should be manageable by NMA and other OSSs
used by RBOCs.

CMISE is the service element built on CMIP.


CMIP defines the format and protocol for exchanging management messages between different OSSs
and NEs so that each party can understand the messages sent from the other side. Despite gaining
much press and some implementations by workstation vendors, CMIP has not been embedded in
many network elements. A possible reason is the lack of an important, widely used OSS that supports
CMIP. Another contributing factor may be the failure of the OSI family of protocols to become the
dominant networking protocol suite.

TARP is another special protocol in the SONET management framework.


TID is used in the TL-1 language to identify each NE in the network. In a TL-1 managed SONET
network, each node including the OSS and the NEs are assigned a unique TID. TARP 1 provides the
function to translate the TID into a network address used by CLNP for routing and relaying.

OSI Short Stack


Prior to standardization based on OSI-7 layer protocols, number of vendors had implemented their
own version of OSI-3 layer stack, popularly known as the short stack. Therefore, interoperability at
the DCC level was impossible between SONET equipment from different vendors utilizing the
proprietary short stack DCC solution. Due to cost considerations, some vendors, especially

OCS worked with Fujitsu to propose TARP protocol to SONET Interoperability Forum (SIF), which was later
adopted by Telcordia as part of GR-253 standard
Page 8 of 8
Opencon Systems, Inc. Proprietary Information. Unauthorized Distribution is Prohibited.

DCC Solution for SONET/SDH Systems


White Paper

Version 1.0, October 2003

Terminal equipment vendors are reluctant to implement full OSI-7 layer stack in their equipment as
required by GR-253 standard. OSI short stack solution based on lower three OSI layer protocols
enables vendors to implement a cost effective DCC solution that would provide interoperability with
OSI-7 layer DCC solution. There are two versions of OSI short stack as illustrated in Figure 4. OSI
short stack based on X.25/LAPB can be used for communicating with OSS but cannot be used for
communication between NEs over DCC.

Application
Transport
Network
Data Link
Physical

Stack A: OS
(X.25 DCN)
TL-1
CLNP
X.25
LAPB
EIA-232-D
V.35

Stack B: NE
(DCC)
TL-1
CLNP
ES-IS, IS-IS
LAPD
DCC

Figure 4:Protocol Components of the Short Stack DCC


Dual Stack
As indicated in the earlier section, the next generation SONET/SDH network elements support IP based
protocols for signaling and management. Some of these NEs support only IP based protocols. These NEs
cannot interwork at the DCC level with the legacy NEs that support only OSI based protocols. To
overcome this DCC interoperability problem, some vendors support both OSI and IP protocol stacks in
their NEs. To transport an IP packet through a network based on OSI-only network elements, the IP
packet is encapsulated with OSI network layer protocol header and tunneled through the OSI network
until it reaches the exit point in the OSI network, where the encapsulation header is removed and the IP
packet is sent over the IP-only network towards its destination. Figure 5, illustrates the protocol stacks
used by a network element in an IP-only network and a network element with a dual stack.
v

Page 9 of 9
Opencon Systems, Inc. Proprietary Information. Unauthorized Distribution is Prohibited.

DCC Solution for SONET/SDH Systems


White Paper

Version 1.0, October 2003

IP Only Stack

OSI Only Stack


CMIP
TL1

FTAM

Application

ROSE
ACSE
HTTP, FTP
Telnet, TL1

Presentation

SNMPv1/v2/v3
RMON

Presentation

Session

Session

Transport

TCP

TP4

UDP

TARP
Network

OSPF
RIP

IPv4

PPP over
HDLC
(RFC1661)

Link

Physical

DCC
DCC

LAN

IS-IS,
ES-IS,
CLNP

ICMP
ARP

LLC1

LAPD

LLC1

X.25
LAPB

LAN
X.25

DCC

DCC
LAN

RS-449/
V.35

Figure 5: IP-only and OSI-only Protocol Stack Components


Figure 6, illustrates the protocol components used in the implementation of a Dual Stack with
encapsulation module for tunneling OSI traffic into IP-only domain and IP traffic into OSI-only domain.
Dual Stack
CMIP
TL1

FTAM

Application

ROSE
ACSE

Presentation

HTTP, FTP
Telnet, TL1

SNMPv1/v2/v3
RMON

Presentation

Session

Transport

Network

Session

TCP

UDP

Tunneling
(GRE)

TP4
TARP

OSPF
RIP
ES-IS,IS-IS

IPv4

CLNP

Link

PPP over HDLC/LAPD

LLC1

LAPB

Physical

DCC

LAN

RS-449
V.35

Page 10 of 10
Opencon Systems, Inc. Proprietary Information. Unauthorized Distribution is Prohibited.

DCC Solution for SONET/SDH Systems


White Paper

Version 1.0, October 2003

Figure 6: Dual Stack Protocol Components


v

TCP-IP to OSI Mediation


High capacity SONET/SDH network elements with hundreds of network interfaces and crossconnects tend to generate large number of messages to report performance data periodically to the
OSS. These network elements also tend to generate large number of alarms/events when a failure
such as fiber cut occurs in the network. If messages from number of these high capacity SONET/SDH
network elements are channeled through a slow X.25 link from the GNE in the network to the NMS,
the buffers in the GNE will overflow resulting in loss of important alarm/event messages from the
NE. Replacing the slow X.25 based link from GNE to OSS with high-speed link such as ATM or
Frame Relay would require an external OSI router. OSI routers are generally more expensive than IP
based routers and furthermore, service providers have an extensive IP based data network
infrastructure that connects their network operations center to most of the central offices where the
GNEs are located. Therefore, service providers generally prefer to use their existing IP based data
network infrastructure to manage the SONET/SDH network elements. To achieve this goal, the GNE
must support TL1/TCP-IP to TL1/OSI-7layer mediation. Figure 7, below illustrates the protocol
components required to support such a function in GNE.
TCP-IP to OSI Mediation in GNE

TL1 Mediation

CMIP
TL1

FTAM

Application

ROSE
ACSE

Presentation

SNMPv1/v2/v3
RMON

TL1
-----------Telnet

Session

Presentation

Session

Transport

UDP

TP4

TCP

TARP
Network

IPv4

CLNP

Link

LLC1

LAPD

Physical

LAN

DCC

OSS

Figure 7: TL1/TCP-IP to TL1/OSI-7 Mediation in GNE

Page 11 of 11
Opencon Systems, Inc. Proprietary Information. Unauthorized Distribution is Prohibited.

NE

DCC Solution for SONET/SDH Systems


White Paper

Version 1.0, October 2003

4. DCC Subsystem Requirements


The protocol components and other supporting modules used in the implementation of a DCC solution is
referred to a DCC subsystem in the network element. Depending on the system architecture of the NE, a
DCC Subsystem can reside on a single processor or span across multiple processors. Regardless of the
architecture used for implementation, a DCC subsystem generally has the following characteristics:
v

Support different types of communication interfaces, such as Section DCC, X.25 and LAN
Telcordias GR-253-CORE and ITU G.7712 have defined the following standard interfaces for
SONET/SDH operations communications: Section/Line DCC, X.25 over RS-449/V.35 and
10/100Base-T.

Support OS (Operation Systems) to NE and NE to NE communications


OS to NE communications is required by all SONET/SDH NEs to perform network operations
and management functions. As illustrated in Figure 2, OS to NE communication path can be
direct or indirect connection (i.e., connection thru a GNE). A direct communication path is one
with no gateway or intermediate NE between the OS and NE (i.e., a dedicated physical
connection or through a X.25 DCN). An indirect OS to NE communication path may consist of
at least one gateway NE, intermediate NE or Mediation Device (MD) between the OS and NE.
A DCC subsystem should support both direct and indirect OS to NE interfaces. The OS to NE
interface is defined in a layered fashion with the requirements of protocol support on each layer
of the OSI model.
NE to NE communications are also required by all SONET/SDH NEs in order to route
management information such as alarm, failure report, status and error indications to the OSSs. In
order to satisfy this requirement, an interoperable network layer interface between the NEs is
required.

Support IP Tunneling
As indicated in the earlier sections, to extend the reach of IP based applications through a OSIonly DCC network, the network elements located at the boundary between IP and OSI network
domains must support dual stack as illustrated in Figure 6.

Support Software Download and Remote Memory Backup/Restoration


Memory administration is an important task of SONET/SDH operations. It includes memory
backup and NE firmware management. Memory backup involves the backup and restoration of a
network elements configuration database. For faster recovery from equipment failures, service
providers normally upload the configuration database from the network element and store it on a
workstation or on a storage media such as CD and magnetic tape.
Like any other software, the firmware used by a SONET/SDH network element is upgraded
periodically to fix software bugs or to introduce new features. The process of upgrading the
firmware stored in a NE is called Software Download.
File transfer protocols such as FTP, TFTP and File Transfer Access Management (FTAM) are
used to upload/download files between the NE and OSSs. FTP and TFTP protocols are supported
by NEs, which are managed by IP based protocols and FTAM is supported by NEs, which are
Page 12 of 12
Opencon Systems, Inc. Proprietary Information. Unauthorized Distribution is Prohibited.

DCC Solution for SONET/SDH Systems


White Paper

Version 1.0, October 2003

managed by OSI based protocols. NEs, which support Dual Stack use FTP for file transfer over
IP based network and FTAM over OSI based network to perform software download operations.
v

TCP/IP to OSI Mediation


To facilitate the management of SONET/SDH NEs over IP based DCN, GNEs must support TL1
over TCP-IP to TL1 over OSI-7 protocol mediation. If software download and remote memory
backup functions are supported from NMS then the GNEs must have store and forward capability
to distribute the files from NMS to NEs and vice versa. Since GNE communicates with the NMS
over IP based DCN, it must support FTP protocol for file transfer purposes. GNE uses FTAM
protocol to transfer files to non-GNEs.

Page 13 of 13
Opencon Systems, Inc. Proprietary Information. Unauthorized Distribution is Prohibited.

DCC Solution for SONET/SDH Systems


White Paper

Version 1.0, October 2003

5. DCC Network Configurations


In this section, we will examine some of the commonly used DCC network configurations and the
protocol elements involved in providing an end-to-end communication over each one of the commonly
used DCC network configuration.

5.1

End-to-End OSI-7 Layer Communication

Figure 8, illustrates an OSI-7 layer based communication path between an OSS (NMS-1) and a
SONET/SDH NE named NE-B. The communication path between NMS-1 and NE-B traverses through
DCN and GNE before terminating in NE-B. It is assumed that the NMS-1 has built-in OSI-7 layer stack
and uses TL1 over OSI-7 layer to manage the SONET/SDH NEs in the network. The physical link
between NMS-1 and GNE is assumed to be X.25 Permanent Virtual Circuit.

OSS

NMS-1

NMS-2

Data Communications Network


EMS
LAN HUB
NE-A

GNE
ADM

GNE

ADM

SONET/SDH Ring
Terminal

Terminal

ADM
ADM

NE-B

Terminal

Terminal
Terminal
GNE: Gateway NE
ADM: Add-drop Multiplexer

Terminal
EMS: Element Management System
NMS: Network Management System

Figure 8: OSS to NE Communication thru OSI Network


Figure 9, illustrates the protocol components involved in the end-to-end communication between
NMS-1 and NE-B. NMS-1 establishes OSI association directly with the NE-B. The GNE (NE-A) in
this particular scenario is used to forward the OSI network layer PDU between NMS-1 and NE-B. If
the X.25 packet size is smaller than the LAPD frame size used over the DCC links, then the GNE will
segment packets from NE-B to NMS-1 so that the packets transmitted over the X.25 PVC links do not
Page 14 of 14
Opencon Systems, Inc. Proprietary Information. Unauthorized Distribution is Prohibited.

DCC Solution for SONET/SDH Systems


White Paper

Version 1.0, October 2003

exceed the packet size limit.


GNE
(NE-A)

OSS

TL1

NE-B

CMIP

FTA
M

TL1
ROSE

ACSE

OSI Upper Layers

FTA
M

CMIP
ROSE

ACSE

Presentation

Presentation

Session

Session

TP4

TP4

TARP

TARP

TARP

ES-IS
CLNP

IS-IS,
ES-IS,
CLNP

IS-IS
ES-IS
CLNP

X.25
LAPB

X.25
LAPB

LAPD

LAPD

RS-449/
V.35

RS-449/
V.35

DCC

DCC

Figure 9: Protocol Components involved in OSS to NE Communication thru OSI Network

4.1. TCP-IP to OSI-7 Mediation


Figure 10, illustrates the communication path between an IP based OSS (i.e., NMS-2) and an OSI-7 layer
based NE (i.e., NE-B) and Figure 11 illustrates the protocol components involved in the communication
path between NMS-2 and NE-B. To establish communication with NE-B, NMS-2 establishes a TCP
connection to GNE (NE-A in the Figure) and sends the TL-1 message for NE-B over the established TCP
connection to GNE. The GNE in turn sets up an OSI association with the NE-B and once the association
is established between GNE and NE-B, the TL1 message from NMS-2 will be forwarded over the
established OSI association. The TL1 mediation module in GNE uses a mapping table to establish the
correspondence between TCP connections and OSI association.

Page 15 of 15
Opencon Systems, Inc. Proprietary Information. Unauthorized Distribution is Prohibited.

DCC Solution for SONET/SDH Systems


White Paper

Version 1.0, October 2003

OSS

NMS-1

NMS-2

Router
CIS CO

SY S
T E MS

Data Communications Network

EMS

LAN HUB
NE-A

GNE

GNE

ADM

ADM

SONET/SDH Ring
Terminal

ADM
ADM

Terminal

NE-B

Terminal

Terminal
Terminal

Terminal

GNE: Gateway NE

EMS: Element Management System

ADM: Add-drop Multiplexer

NMS: Network Management System

Figure 10: TL/TCP-IP to TL1/OSI-7 Mediation


OSS
(NMS-2)

GNE
(NE-A)
TL1 Mediation

TL1
-----------Telnet

SNMPv1/v2/v3
RMON

UDP

TCP

SNMPv1/v2/
v3
RMON

UDP

TL1
-----------Telnet

TCP

NE-B

TL1

FTA
M

CMIP

CMIP
TL1

FTAM

ROSE

ROSE

ACSE

ACSE

Presentation

Presentation

Session

Session

TP4

TP4

TARP

TARP

IPv4

IPv4

CLNP

CLNP

LLC1

LLC1

LAPD

LAPD

LAN

LAN

DCC

DCC

Figure 11: Protocol Components involved in TCP-IP to OSI-7 Mediation


Page 16 of 16
Opencon Systems, Inc. Proprietary Information. Unauthorized Distribution is Prohibited.

DCC Solution for SONET/SDH Systems


White Paper

5.2

Version 1.0, October 2003

IP Tunneling

Figure 12, illustrates the communication path between an EMS that manages SONET/SDH network
element using IP based management protocol such as SNMP or HTTP. In this example, an EMS
connected to GNE (NE-A) is assumed to manage all SONET/SDH terminals using SNMP protocol. Since
the communication path between the EMS and SONET/SDH terminals go through ADMs. Some of the
ADMs (e.g., NE-B and NE-C) are assumed to support only OSI-7 layer protocols over DCC. To support
this type of configuration an IP tunnel is created between SONET/SDH terminal (e.g. NE-D) and GNE
(NE-A). Figure 13, illustrates the protocol components involved in IP tunneling path between NE-D and
GNE.

OSS

NMS-1

NMS-2

Data Communications Network


EMS
LAN HUB
NE-A

GNE

GNE

ADM

ADM

SONET/SDH Ring
Terminal

Terminal

ADM
ADM

NE-B

NE-C
NE-D

Terminal

Terminal
Terminal

Terminal

GNE: Gateway NE

EMS: Element Management System

ADM: Add-drop Multiplexer

NMS: Network Management System

Figure 12: IP Tunneling

Page 17 of 17
Opencon Systems, Inc. Proprietary Information. Unauthorized Distribution is Prohibited.

DCC Solution for SONET/SDH Systems


White Paper
NE-D

SNMP
v1/v2/
v3
RMON

HTTP
FTP
Telent

UDP

TCP

NE-A (GNE)

NE-B

EMS

SNMPv1/v2/
v3
RMON

UDP
Tunneli
ng
GRE

IPv4

NE-C

Version 1.0, October 2003

CLNP

CLNP

CLNP

LLC1

LAPD

LAPD

LAPD

LAN

DCC

DCC

DCC

CLNP

Tunneli
ng
GRE

TCP

IPv4
IPv4

LAPD

LLC1

DCC

LAN

LLC1

LAN

Figure 13: Protocol Components involved in an IP Tunneling Communication Path

Page 18 of 18
Opencon Systems, Inc. Proprietary Information. Unauthorized Distribution is Prohibited.

HTTP
FTP
Telent

DCC Solution for SONET/SDH Systems


White Paper

Version 1.0, October 2003

6. OCS DCC Package


OCS offers standards-based, off-the-shelf DCC System Solution designed to shorten the DCC
implementation time and to provide DCC interoperability with equipment from leading SONET/SDH
equipment vendors such as Fujitsu, Lucent and Nortel. OCS offers two standards-based DCC Solutions
that provide interoperability for products deployed in a SONET/SDH ring: a Full OSI 7-Layer Stack and
a Short Stack DCC Subsystem. OCS solution is designed to be hardware and operating system
independent and can be easily ported to most hardware/software platforms.
OCS-DCC package is offered in two versions: as a full stack and a short stack. The full stack version
incorporates all seven OSI layers as specified in GR-253 and the short stack version incorporates OSI
layers one through three. Both full stack and short stack versions include API for integration with
customer developed application and low-level drivers. For customers who develop SONET/SDH terminal
equipment, OCS offers a package called IP Tunneling-Lite which includes all the components of a
Short stack with the exception of IS-IS protocol. OCS-DCC package also includes the following two
features:

ITU G.7712 compliant IP Tunneling Module for IP Relay through OSI network (included
in both OSI-7 layer and Short stack packages)

NSIF-033-1999 compliant TL1 translation device (T-TD) to support TL1 over TCP/IP to
TL1 over OSI-7 layer mediation

NSIF-033-1999 compliant File Transfer Translation Device (FT-TD) to support FTP to


FTAM mediation2

FT-TD is an optional module in OCS-DCC package


Page 19 of 19
Opencon Systems, Inc. Proprietary Information. Unauthorized Distribution is Prohibited.

DCC Solution for SONET/SDH Systems


White Paper

Version 1.0, October 2003

7. References
1.
2.
3.
4.
5.

GR-253, Synchronous Optical Network (SONET) Transport Systems: Common Generic Criteria
ITU G.7712/Y.1703, Architecture and Specification of Data Communication Network
RFC-1661, Point-to-Point Protocol
RFC-1662, PPP in HDLC-like framing
RFC-2784, Generic Routing Encapsulation

Page 20 of 20
Opencon Systems, Inc. Proprietary Information. Unauthorized Distribution is Prohibited.

DCC Solution for SONET/SDH Systems


White Paper

Version 1.0, October 2003

8. Abbreviations
ACSE
ARP
ATM
BER
CLNP
CLNS
CMISE
CMIP
CSMA/CD
DCC
DCN
EMS
ES
ES IS
FR
FTP
FTAM
GNE
GRE
HDLC
ICMP
ID
IP
IPv4
IPCP
IS
ISDN
ISIS
LAN
LAPB
LAPD
LLC1
LCN
NE
NSAP
OS
OSS
OSI
OSPF
PDU
PPP
RFC
ROSE
SDH
SONET
STS-1
TARP
TCP
TL1
WAN

Association Control Service Element


Address Resolution Protocol
Asynchronous Transfer Mode
Basic Encoding Rules
Connection-less Network Layer Protocol
Connection-less Network Layer Service
Common Management Information Service Element
Common Management Information Protocol
Carrier Sense Multiple Access/Collision Detection
Data Communications Channel
Data Communication Network
Element Management System
End System
End System to Intermediate System
Frame Relay
File Transfer Protocol
File Transfer, Access and Management
Gateway Network Element
Generic Routing Encapsulation
High Level Data Link Control
Internet Control Message Protocol
Identifier
Internetwork Protocol
Internetwork Protocol Version 4
Internet Protocol Control Protocol
Intermediate System
Integrated Services Digital Network
Intermediate System to Intermediate System
Local Area Network
Link Access Procedure B-Channel
Link-Access Procedure D-Channel
Link Layer Control
Local Communications Network
Network Element
Network Service Access Point
Operations System
Operations Support System
Open System Interface
Open Shortest Path First
Packet Data Unit
Point-to-Point Protocol
Request For Comment
Remote Operations Service Element
Synchronous Digital Hierarchy
Synchronous Optical Network
Synchronous Transport Signal-1
TID Address Resolution Protocol
Transmission Control Protocol
Transaction Language 1
Wide Area Network

Page 21 of 21
Opencon Systems, Inc. Proprietary Information. Unauthorized Distribution is Prohibited.