"Migration to an IP Management of SONET/SDH" in Optical Fiber Communication Conference and Exposition and The National Fiber Optic Engineers Conference
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:
But there are also technical drivers to move to IP
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.
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:
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).
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.
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.
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.
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 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:
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.
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 ?
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).
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.
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.
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 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]).
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.
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).
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.
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.
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.
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.
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 ?
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.
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).
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).
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.
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.
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).
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.
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.
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.
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, • MARBEN OSIAM OSPF.
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.
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 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.
