DCC White Paper Rev2

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.
COPYRIGHT This material is the property of OpenCon Systems, Inc. Unauthorized distribution is prohibited Copyright 2003 OpenCon Systems, Inc. All Rights Reserved
Table of Contents
1. 2. 3. 4. 5.
5.1 4.1. 5.2
OVERVIEW SONET/SDH DATA COMMUNICATION CHANNEL SONET/SDH DCC PROTOCOL STACKS DCC SUBSYSTEM REQUIREMENTS DCC NETWORK CONFIGURATIONS
End-to-End OSI-7 Layer Communication TCP-IP to OSI-7 Mediation IP Tunneling
4 6 7 12 14
14 15 17
6. 7. 8.
OCS DCC PACKAGE REFERENCES ABBREVIATIONS
19 20 21
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:
DCC Solution for SONET/SDH Systems White Paper 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.
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.
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 ADM GNE
ADM
SONET/SDH Ring Terminal ADM ADM Terminal
Terminal Terminal GNE: Gateway NE ADM: Add-drop Multiplexer Terminal EMS: Element Management System
Terminal
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.

Stack A: OS (X.25 DCN) TL1 CMISE ROSE ACSE ASN.1/BER Kernel/Full Duplex TP4 CLNP X.25 LAPB
EIA-232-D V.35
Version 1.0, October 2003 Stack B: NE (DCC)

TL1 CMISE ROSE ACSE Stack C: NE (LAN) TL1 CMISE ROSE ACSE ASN.1/BER Kernel/Full Duplex TP4 CLNP ES-IS IS-IS LLC1 CSMA/CD
AUI 10BASE2 10BASE-T
Application
Pre sentation
Session Transport
Network Data Link Physical
ASN.1/BER Kernel/Full Duplex TP4 CLNP ES-IS IS-IS LAPD

DCC
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.
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.
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
Application Transport Network Data Link Physical
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

IP Only Stack

OSI Only Stack CMIP TL1 FTAM ROSE ACSE
Application
Presentation
HTTP, FTP Telnet, TL1
SNMPv1/v2/v3 RMON
Presentation
Session
Session TP4 TARP
Transport
TCP
UDP
Network
IPv4
OSPF RIP
ICMP ARP LAPD
IS-IS, ES-IS, CLNP LLC1 X.25 LAPB
Link
PPP over HDLC (RFC1661) DCC DCC LAN
LLC1
Physical
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 Application ACSE Presentation HTTP, FTP Telnet, TL1 SNMPv1/v2/v3 RMON Presentation FTAM ROSE
Session
Session TP4 TARP CLNP
Transport
TCP
UDP
Tunneling (GRE) OSPF RIP ES-IS,IS-IS
Network
IPv4
Link
PPP over HDLC/LAPD
LLC1
LAPB
Physical
DCC
LAN
RS-449 V.35
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 CMIP TL1 FTAM ROSE ACSE Presentation SNMPv1/v2/v3 RMON TL1 -----------Telnet Presentation
TL1 Mediation Application
Session
Session TP4 TARP
Transport
UDP
TCP
Network
IPv4
CLNP
Link
LLC1
LAPD
Physical
LAN
DCC
OSS
NE
Figure 7: TL1/TCP-IP to TL1/OSI-7 Mediation in GNE
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
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.
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 GNE ADM NE-A GNE
ADM
SONET/SDH Ring Terminal ADM ADM NE-B Terminal
Terminal
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
DCC Solution for SONET/SDH Systems White Paper exceed the packet size limit.
GNE (NE-A) CMIP
OSS FTA M ACSE Presentation
NE-B FTA M ACSE Presentation CMIP ROSE
TL1
TL1 ROSE OSI Upper Layers
Session TP4 TARP ES-IS CLNP X.25 LAPB RS-449/ V.35 X.25 LAPB RS-449/ V.35 TARP IS-IS, ES-IS, CLNP LAPD
Session TP4 TARP IS-IS ES-IS CLNP LAPD
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.
OSS
NMS-1
NMS-2
Router
CI CO S
SY S E MS T
Data Communications Network
EMS
LAN HUB GNE ADM NE-A GNE
ADM
SONET/SDH Ring Terminal ADM ADM NE-B Terminal
Terminal Terminal GNE: Gateway NE ADM: Add-drop Multiplexer Terminal EMS: Element Management System NMS: Network Management System
Terminal
Figure 10: TL/TCP-IP to TL1/OSI-7 Mediation

OSS (NMS-2) GNE (NE-A) TL1 Mediation FTA M ACSE TL1 -----------Telnet Presentation CMIP TL1 ROSE ACSE Presentation
FTAM
NE-B
CMIP ROSE
TL1
SNMPv1/v2/v3 RMON
TL1 -----------Telnet
SNMPv1/v2/ v3 RMON
UDP
TCP
UDP
TCP
IPv4
IPv4
LLC1
LLC1
LAPD
LAPD
LAN
LAN
DCC
DCC
Figure 11: Protocol Components involved in TCP-IP to OSI-7 Mediation

5.2
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 GNE ADM NE-A GNE
ADM
SONET/SDH Ring Terminal ADM NE-C NE-D ADM NE-B Terminal
Terminal
Figure 12: IP Tunneling

NE-D NE-C NE-B

NE-A (GNE) EMS
SNMP v1/v2/ v3 RMON
HTTP FTP Telent
SNMPv1/v2/ v3 RMON
HTTP FTP Telent
UDP
TCP Tunneli ng GRE
UDP
TCP
IPv4
CLNP
CLNP LAPD DCC
CLNP LAPD DCC
CLNP
Tunneli ng GRE
IPv4 IPv4 LLC1
LLC1
LAPD
LAPD
LLC1
LAN
DCC
DCC
LAN
LAN
Figure 13: Protocol Components involved in an IP Tunneling Communication Path
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.
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
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

DCC White Paper Rev2

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

DCC White Paper Rev2

Încărcat de

Drepturi de autor:

Formate disponibile

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

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

OCS DCC PACKAGE REFERENCES ABBREVIATIONS

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

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

Version 1.0, October 2003

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

STS-1 payload capacity (9 87 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

Data Communications Network EMS LAN HUB GNE ADM GNE

SONET/SDH Ring Terminal ADM ADM Terminal

NMS: Network Management System

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

DCC Solution for SONET/SDH Systems White Paper

Version 1.0, October 2003 Stack B: NE (DCC)

Network Data Link Physical

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

DCC Solution for SONET/SDH Systems White Paper

Version 1.0, October 2003

Application Transport Network Data Link Physical

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

HTTP, FTP Telnet, TL1

Session TP4 TARP

ICMP ARP LAPD

IS-IS, ES-IS, CLNP LLC1 X.25 LAPB

PPP over HDLC (RFC1661) DCC DCC LAN

Session TP4 TARP CLNP

Tunneling (GRE) OSPF RIP ES-IS,IS-IS

PPP over HDLC/LAPD

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

TL1 Mediation Application

Session TP4 TARP

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.

DCC Solution for SONET/SDH Systems White Paper

Version 1.0, October 2003

4. DCC Subsystem Requirements

DCC Solution for SONET/SDH Systems White Paper

Version 1.0, October 2003

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