Migration to an IP management of Sonet/SDH networks



"Migration to an IP Management of SONET/SDH" in Optical Fiber Communication Conference and Exposition and The National Fiber Optic Engineers Conference

I. Introduction

The SONET and SDH technologies have been revealed in the 80's. Although both standards were competing (SONET was introduced in the US by Bellcore while SDH was presented by CCITT in Europe), both were agreed to implement the OAM&P (Operation, Administration, Maintenance and Provisioning) functionality by using a Data Communication Network relying on OSI protocols. The OSI was the emerging and well-standardized model at that time, and TCP/IP had not yet taken the importance it has now (mainly due to the success of Internet).

As a consequence, the SONET and SDH Data Communication Network (DCN) have been relying for many years on OSI protocols. In a world that is now widely driven by IP networks, the deployment, support and maintenance of OSI networks raise high costs issues for carriers and telecom equipment manufacturers:

  • Maintaining OSI networks increases the operational expenses because of the OSI skills decrease and lack of rationalization of network infrastructures,
  • OSI increases the development complexity and costs for new equipment (and many new network elements are natively using IP management for that reason).

But there are also technical drivers to move to IP

  • Most of access DCN are already IP based
  • There is a need to be able to manage IP data equipment (routers) at the border of SONET/SDH rings (and possibly at customer premises),
  • And more important, OSI is a hurdle for moving to next generation optical network management and control planes.

If it is obvious that moving to a full IP management is a big benefit, how to achieve this is not so straightforward. The legacy SONET and SDH network elements installed base is now huge and very stable, and no telecom operator is ready to upgrade its whole networks at once for evident cost and feasibility reasons.

As a consequence, a slow migration process is starting, and the key issue is to have a migration as smooth as possible.

II. The Legacy Dcn At A Glance

The DCN network profiles and management interfaces are described in the GR.253 (see [1]) for SONET and in G.784/Q.811 for SDH (see [2,3]) and are “quite” similar. The main difference comes from the adoption by SONET network of the Q3/TL1 management interface instead of a Q3/CMISE one.

The DCN protocol stack can then be summarized as shown in the following Fig. 1:

Legacy DCN protocol stack profiles
Figure 1: Legacy DCN protocol stack profiles

III. Migration: An Interoperability Issue

For the reasons exposed earlier, the migration from an OSI to an IP DCN means that the process is progressive. At a point in time, that can be quite long, both OSI and IP have to cohabit, or better to interoperate.

This interoperability issue mainly concerns the network layer (layer 3 in the OSI model) that is in charge of the routing/addressing in the networks. Here, we do not take into account interoperability of management applications (e.g. TL1 vs. SNMP).

IP and CLNP, its counterpart in OSI world, are strictly incompatible (both in term of addressing and Packet format).

IV. Moving To Ip: A Step By Step Process

Actually, this migration has already been started for some time now, and always in a very pragmatic way: for each problem, a solution more or less proprietary. Even if some solutions can answer different problems, they are generally used to be very specific to a deployment constraint.

The ultimate goal, if possible, would be to have one global solution.


The first attempt was done on the access DCN. Management platforms (OSS/EMS) that were primarily connected to the Gateway Network Elements (GNE) were using X.25. Rapidly, the need was to allow the management platform connection through an IP access DCN.

Access and embedded DCN
Figure 2: Access and embedded DCN

IV.1.1 RFC-1006

As soon as access DCN started to rely on TCP/IP, a new solution was required to at least reach the embedded OSI DCN through the Gateway Network Element.

Access using RFC-1006
Figure 3: Access using RFC-1006

Solutions based on the RFC-1006 network profile defined by the IETF were first adopted (see [4]). This standard describes the mapping of an OSI stack over TCP/IP as shown in Fig. 4.

The Transport RFC-1006 profile
Figure 4: The Transport RFC-1006 profile

This solution was very simple but not satisfying in a migration process because it was not able to interoperate with Legacy equipment meaning that an application running on top of an RFC-1006 stack was not able to connect to an application running on a Q3 stack: • RFC-1006 is not compatible with CLNP: GNE can be reached but communication ends there, • RFC-1006 addressing based on the RFC-1277 (see [5]) is not compatible with GR.253 addressing, • The TARP protocol used for the TL1 Identifier address resolution cannot operate over an RFC-1006 network.

• RFC-1006 Transport service bridge

RFC-1006 was not allowing interoperability with Legacy equipment because TCP/IP (RFC-1006) and CLNP were not compatible, meaning that only the GNE was accessible, but not the Network Elements behind. The solution was then to make a protocol conversion one layer above, at transport layer. This solution also known as active transport relay is depicted in the following Fig. 5:

The RFC-1006 Transport service bridge
Figure 5: The RFC-1006 Transport service bridge

Generally located on the Gateway Network Element, the RFC-1006 Transport service bridge allows interoperation with CLNP based network elements but still suffers several limitations including:

• The need for the user to manage two different NSAPs: The management application needs both the NSAPs of the Transport Service Bridge and of the remote Network element. That last NSAP need also to be encoded by some mean because only one NSAP can be used when connecting. Deployed solutions are actually using the Transport selector to carry the actual GR.253 network address, while the RFC-1277 was the one of the bridge . • The non-use of dynamic route adaptation of IS-IS. • The TARP protocol still cannot operate over RFC-1006.

• VP2P - CLNP Tunneling over TCP/IP

The RFC-1006 based solutions were mainly suffering from the fact they were trying to make the interoperation at the transport layer, while keeping two different network layers. As a consequence they were loosing the main benefits from the network layer in terms of routing and addressing. So how to keep full OSI from end to end and allow crossing of a TCP/IP access DCN ?

CLNP Tuneling over TCP/IP
Figure 6: CLNP Tuneling over TCP/IP

A different approach was then adopted: keep only one unique CLNP DCN network layer while TCP/IP is only used to create virtual links between OSS and network elements. This solution is known as the Virtual Point to Point (VP2P) (see [6]). It offers a tunneling (encapsulation) of the CLNP traffic into TCP/IP connections (see Fig. 7).

VP2P CLNP Tunneling profile
Figure 7: VP2P CLNP Tunneling profile

The benefits of such a solution are:

• The addressing plan of TCP/IP is transparent to the applications that only handle NSAPs.
• The IS-IS and TARP protocols are supported transparently above the VP2P links (In fact, we stay in a strict OSI world).
• Although such tunneling solution needs its support at both ends, it allows very flexible configurations. This functionality can be embedded on the elements/managers or on intermediate CLNP routers.
However there are still some drawbacks that are more operational than strictly technical:
• It requires manual provisioning of tunnels and the potential setup of a mesh of tunnels.
• It might not scale easily with the networks.

• TL1 Translation device

Here the approach is drastically different. It is driven by the possibility to have the TL1 protocol using directly TCP/IP instead of the Q3 stack. Actually, more and more TL1 managers are available on TCP/IP, not only because of Legacy equipment needing to migrate to IP but mostly because more and more network elements are natively supporting a TL1 IP management (and often no OSI management at all). In that case, the scenario case becomes a bit different: how to make a Legacy equipment interoperable with an IP manager.

Introducing GNE Translation Devices
Figure 8: Introducing GNE Translation Devices

The chosen solution shown in Fig. 9 is an applicative gateway (also called a Translation device) that allows an automatic relaying of TL1 messages over IP to TL1 messages over OSI (see [7]).

The TL1 Translation device
Figure 9: The TL1 Translation device

The TL1 Translation device is normally located on a GNE, and as a consequence does not imply special constraint of deployment. This is a very pragmatic solution that answers a very specific need. Its main drawbacks are:
• The TL1 application still has to know the IP address of the Gateway (like with the Transport Service Bridge) but here, the OSI addressing is hidden thanks to the TID usage. The TID network address (NSAP) is normally resolved by TARP on the GNE.
• It is an applicative gateway, and thus it only covers the TL1 usage. For instance management applications might require some other applicative gateway for the file transfer functions (e.g. Software download). This kind of gateway also exists and is known as File Transfer Translation device performing the protocol conversion between FTAM and FTP (see [7]).

IV.2 Managing IP-Only Network Element

The next step in the migration is driven by the fact that more an more Network Elements (including SONET or SDH equipment) are now natively managed using SNMP, Corba or XML that requires an IP network: under the pressure of cost and time to market, many new comers in the SONET/SDH market restricted to a proprietary IP management system because it could be acceptable by some carriers in specific contexts. However, as soon as these network elements need to be deployed in wider legacy network, the problem of interoperability is raised.

Now, the problem is no more to cross a TCP/IP backbone but an OSI backbone and this problem is not only restricted to SONET/SDH equipment. Indeed, carriers or operator are wishing to be able to manage pure IP equipment (routers, DSLAM,…) remotely across the SONET/SDH rings: why not using the available DCN instead of allocating some trunk in the transport plane for that purpose. Here again the issue is to take benefit from the OSI backbone for an IP traffic.

IP manageable Network Elements
Figure 10: IP manageable Network Elements

A global solution to answer this class of issue is the tunneling of IP traffic within the CLNP (known as IP Tunneling). This solution is quite similar to the VP2P solution in its principle, however tunnels are realized over a connection-less network layer instead of a connection oriented transport layer (Fig. 11).

IP Tunneling solution
Figure 11:IP Tunneling solution

This kind of solution based on somehow proprietary encapsulation of the IP traffic has been relatively deployed already. It can be either collocated on the NE or GNE or on intermediate IP routers. However, this solution has some drawbacks:
• A lot of manual provisioning is required to populate the IP to NSAP routing tables allowing to determine the OSI exit of the tunnel from on IP address. The IP routing table provisioning can also be an issue if the tunnel interfaces exposed to IP cannot be used by its IP routing protocol.
• Deployed solutions are not always interoperable, meaning generally that both ends of the tunnel have to be provided by the same equipment vendor.

V. Itu-T G.7712: A Global Solution

It has been seen above that, according to the various deployment constraints and during the whole migration period of time, there is need both for OSI traffic to cross IP backbones and IP traffic to cross OSI backbones.

The new ITU-T G.7712 (see [8]) is a global recommendation applicable for the DCN of optical networks that intends to define (among other things) its architecture for an interworking between OSI an IP network elements.

I.1 The Protocol Stack Profiles

For OSI, the stack profile is for long time standardized, but nothing were defined up to now for the IP stack profile for the DCN. The G.7712 clarifies this and, although it does not forbid some other profile, it fixes recommendations with the goal to have a migration as smooth as possible. This ITU-T standard only focuses on the layer 2 and 3, leaving free upper layers (for instance TARP is not mentioned at all). The following Fig. 12 shows the two OSI and IP lower layer profiles.

G.7712 basic stack profiles
Figure 12: G.7712 basic stack profiles

It can be noticed that the major recommendation deals with the use of the IS-IS routing protocol for IP networks. The IS-IS link state routing protocol is coming from the ISO standardization (see [9,10,11]) and was originally suited for the OSI CLNP routing. It was extended by the IETF in the RFC-1195 (known as Integrated IS-IS) to allow also the routing of IP v4 traffic (see [9]).

This choice can appear a bit strange when we know that the OSPF routing protocol has the favor of the enterprise IP networks. However, most of carrier grade IP networks are currently based on the integrated IS-IS routing protocol. In addition, the choice is also driven by all the benefits that the usage of the same routing protocol can bring in the scope of the migration and the interworking of OSI and IP.

V.2 Auto-Encapsulation: The Smooth Tunneling Approach

As presented earlier, the tunneling solutions are attractive but imply generally a lot of manual provisioning of network element embedding them. This provisioning is mostly implied by the need to make a correspondence between the two OSI and IP addressing scheme: what is the address of the OSI (respectively IP) tunnel exit to access the IP (respectively OSI) address of the remote node ?

• Encapsulation

The solution proposed by the ITU-T G.7712 standard is based on the usage of GRE that has been standardized by the IETF (see [13, 14]). The tunneling (or encapsulation) is then performed on Dual nodes (meaning that they embed both IP and OSI network layers). Such node stack profile is shown in the Fig. 13.

G.7712 Dual nodes
Figure 13: G.7712 Dual nodes

In order to reduce the manual provisioning of tunnels, the ITU-T G.7712 standard proposes to take benefit from the capability of the IS-IS protocol to route both OSI and IP traffic. Dual nodes are then responsible for the automatic encapsulation of the traffic when it detects incompatibility in the route path): OSI (respectively IP) traffic that needs to be routed through an IP (respectively OSI) part of the network is encapsulated using GRE. Reversibly, the traffics are un-encapsulated on the nearest Dual node with compatible connectivity (Fig. 14).

Encapsulation by Dual node
Figure 14:Encapsulation by Dual node

• Back to Integrated IS-IS – RFC-1195

To understand better what is hidden behind the auto-encapsulation feature, let’s go back to Integrated IS-IS. The RFC-1195 specifies a set of extensions to the OSI IS-IS standard (ISO-10589), making IS-IS an integrated routing protocol for IP-only, OSI-only or dual (i.e. integrating both IP and OSI) networks.

However, the RFC-1195 specifies strict topological rules for dual networks: all level 2 IS must be dual, and within each area, there must not exist both IP-only and OSI-only Intermediate Systems. Such rules prevent IS-IS to be seen as a straightforward solution for the interworking of existing OSI and IP networks (since many nodes must be upgraded to support dual routing).

• IS-IS Auto-encapsulation: automatic provisioning of tunnels

The IS-IS Auto-encapsulation mechanism, specified in the ITU-T G.7712 standard, allows RFC-1195 topological rules to be broken: IP-only and OSI-only nodes can exist in the same IS-IS area.

This mechanism relies on some Intermediate Systems being able to detect that a packet is about to be sent to a next hop that does not support that packet network protocol, and to automatically encapsulate that packet into another network protocol packet.

Then in an OSI only area, instead of upgrading all nodes to dual nodes, one of the two following alternatives can be chosen:

• only a few nodes may be upgraded to support the IS-IS auto-encapsulation function;
• or a few nodes supporting the IS-IS auto-encapsulation function can be added in the network, hence leaving the original OSI-only network unchanged.
This is shown in Fig. 15:
• nodes #1, #2, #3 and #4 have been upgraded to support the IS-IS auto-encapsulation function;
• a new IS node (#5) supporting the IS-IS auto-encapsulation function has been added to the LAN in the OSI-only area.

G.7712 Auto-encapsulation using IS-IS
Figure 15: G.7712 Auto-encapsulation using IS-IS

Note that facing the constraints of real telecommunication networks, the manual provisioning of tunnel is (and must be) still possible both for the encapsulation of IP over OSI and OSI over IP using GRE.


The G.7712 standard is new, and even if equivalent solutions have already been deployed, true compliant Network Elements are still quite rare. In particular, systems embedding the Auto-encapsulation feature are just starting to be put on the field.

• Edge Network Elements

The first candidate is the access or edge network elements. This also corresponds to where the SONET and SDH market is growing more.

These elements are generally expected to provide both OSI and IP connectivity for the reasons already exposed in chapter IV.2. At the border of the Core Network, they acts as bridges between the Optical Core network and the IP Infrastructure.

An issue here is the interconnections with IP network that are not using Integrated IS-IS natively as routing protocol (they generally use OSPF instead) that would prevent to take benefit from the automatic manual provisioning-free encapsulation.

A solution to avoid too much manual provisioning of tunnels is to implement the Network element with two routing protocols: a G.7712 IS-IS Dual and OSPF.

A first solution to avoid the manual provisioning of IP Tunnels across the OSI networks is shown in Fig. 16. The Network Element is split in two domains and acts both as a Dual IS-IS Level 2 node and an OSPF Area Border Router. A provisioning of each IS-IS and OSPF router external reachability is still required, but knowledge of the OSI topology is necessary, only the IP addressing plan knowledge is required. In the counter part, this might require the node to be both Level 2 and ASBR, and puts constraints on the adjacent nodes that requires also to be Level 2 on the IS-IS domain and ABR in the OSPF domain. However this constraint can be avoided on IS-IS if the Domain Wide IP prefix advertising feature specified by the RFC 2966 is supported (this feature allows IS-IS L1/L2 nodes the advertising of configured IP destination prefixes learned via L2 into L1 LSPs).

IS-IS Auto-encapsulation and OSPF interworking
Figure 16: IS-IS Auto-encapsulation and OSPF interworking

A second solution, based on the one shown in the Fig. 16 is to implement an automatic distribution and filtering of OSPF routes in IS-IS: the routes in the adjacent OSPF area are automatically learned by IS-IS. The main benefit is that it prevents most of the manual provisioning and it might also avoid forcing the Network Element to act as a level 2 router. However, a special attention might be taken when applying the filters of routes to avoid loops in the network. This kind of solution is currently not standardized at all and is left open by the G.7712.

• Core Network Elements

The situation in Core networks is slightly different because the issue of crossing parts of the DCN that are pure IP is possible. This is typically the case when some rings of IP managed equipment has to be integrated within a legacy DCN. This is very easy to solve if the IP Ring is using Integrated IS-IS already. Unfortunately, such IP equipment is often using OSPF instead.

We face again the problem exposed for Edge routers: Make interoperation between IS-IS and OSPF. Some solutions like the one shown in chapter • can solve the crossing of OSI islands using an automatic encapsulation. But because OSPF does not handle the OSI addressing plan, it is not possible to have this automatic encapsulation and then the use of manually provisioned tunnels in the OSPF domain is required.

VI. The Marben Osiam Solutions

Marben Products has been involved for more than 15 years in the edition of networking protocol suites, with its MARBEN Products line. Our solutions are embedded by majors optical equipment manufacturers in their Sonet/SDH network elements and are now widely deployed on the field.

The MARBEN™ OSIAM products offer
Figure 17: The MARBEN™ OSIAM products offer

Thanks to its MARBEN OSIAM products, Marben Products is acknowledged to be the leader in Sonet/SDH DCN OSI to IP DCN migration software solutions and its portfolio provides a complet set of off-the shelf solutions covering all aspects presented in this document:
• MARBEN OSIAM TARP/TL1 protocol suites,
• MARBEN OSIAM RFC-1006 profile and Transport Service Bridge support,
• MARBEN OSIAM Virtual Point-to-Point (VP2P),
• MARBEN OSIAM TL1 and File Transfer Translation Devices,
• MARBEN OSIAM G.7712 stacks including Auto-Encapsulation Support,

In addition, The MARBEN Network Simulator/Emulator product offers a full support of G.7712 profiles to allow optical equipment manfacturers to test and validate the implementation of their OSI or IP DCN implementation.

For more details about our complete portfolio, please visit us on www.marben-products.com.

VII. References

1. Telcordia/Bellcore, “Synchronous Optical Network (SONET) Transport Systems: Common Generic Criteria”, GR-253-CORE, September 2000
2. ITU-T, “Synchronous digital hierarchy (SDH) management”, G.784
3. ITU-T, “Lower layer protocol profiles for the Q3 and X interfaces”, Q.811
4. Marshall T. Rose, Dwight E. Cass, “ISO transport services on top of the TCP: Version 3”, RFC-1006, May 1987
5. S.E. Hardcastle-Kille, “Encoding Network Addresses to Support Operation over Non-OSI Lower Layers”, RFC-1277, November 1991
6. Junji Tanabe & Alec Hothan, “OSI Network Layer Over TCP/IP (VP2P) for IP on the DCN”, SIF-AR-9802-37
7. Brian Crowe, “Requirements for the TCP/IP Protocol Suite on the SONET Access DCN.”, NSIF-033-1999
8. ITU-“Architecture and Specification of Data communication Network Recommendation”, G.7712/Y.1703, March 2003
9. ISO/IEC, “IS to IS intra-domain information exchange protocol”, ISO/IEC 10589, 16-Jan-1992
10. ISO/IEC, “IS to IS Technical Corrigendum 1”, ISO/IEC 10589 Cor1, 01-Jan-1993
11. ISO/IEC, “IS to IS Technical Corrigendum 2”, ISO/IEC 10589 Cor2, 21-Jun-1995
12. R.W. Callon., “Use of OSI IS-IS for routing in TCP/IP and dual environments.”, RFC-1195, Dec-01-1990
13. D. Farinacci et Al, “Generic Routing Encapsulation (GRE).”, RFC-2784, March 2000
14. P. Christian, “Generic Routing Encapsulation over CLNS Networks.”, RFC-3147, July 2001
15. T. Li, T.Przygienda, H. Smit, “Domain-wide Prefix Distribution with Two-Level IS-IS”, RFC-2966, October 2000


Why is OSI still widely deployed on the SONET and SDH DCN? Certainly because the migration to IP is very complex. First trial started about 6 or 7 years ago, and about 90 % of the deployed SONET/SDH networks are still Legacy.

The ITU-T G.7712 standard is a major step in this process, and more and more carriers are requiring compliance to it. It proposes innovative solution to reduce the on the field configuration (and thus the operational expense).

The process is engaged, and accelerating. OSI has to disappear. And to keep the system engineers to be hard at it, the next step is to meet the upcoming requirement of the Optical Networks relative to the dynamic provisioning of network elements thanks to the implementation of a GMPLS control plane. Here again, IP is a must. Text.

Marben Products

Marben Products has been a leading telecommunication software editor for more than 25 years.

Its portfolio includes the SONET/SDH management stack with the full support of the ITU-T G.7712 recommendation.

Marben Products is committed to offer products that conform to the latest standards; Marben Products was member of SIF and the TMF SIF for SONET management and is now member of OIF and ITU-T SG15, as well as involved in IETF work.