Connectionless technology management

Unlike connection oriented Subnetworks which often constitute the widespread transport layer (DWDM, SONET/SDH) shared by many network applications, connectionless Subnetworks such as Metro Ethernet are likely to be deployed as smaller “islands” dedicated to a single network application (e.g., multiple sites of a corporate customer).”
TM Forum’s
SD1-44 Connectionless Technology Management.”

Many OSS tools that have been around for a while were originally conceived around connection-oriented technologies such as PDH, SDH, etc. This meant that network links were nailed up from end-to-end through a network. This made life easier for the OSS because you could easily tell which customer services used which network assets / links. Therefore, if a particular asset or link went down, you could also tell which customer services were impacted.

Connectionless technologies are quite a bit more challenging in some ways, but not in others, which we’ll get to shortly. Packet-switched networks are connectionless in that a communication stream can be broken up into many pieces (packets) and each piece can be dynamically routed through a network. It’s possible that different pieces of the same information stream could traverse different routes.

When you consider the number of packets whizzing around the many links in a network, it’s not viable for the OSS to track every path that a customer’s communication stream from end-to-end.

This concept changes the way you model the network. For a connection-oriented network, you can model every device and every link, if you wish. For a connectionless network, you can model ingress and egress points, but everything in between as a semi-visible cloud. I model off-net circuits the same way as it’s basically an admission that you don’t have full visibility of everything that’s happening inside that part of the circuit. Clouds are much easier from a modelling perspective, but you tend to lose the management granularity and data relationships in the process.

Some time ago, Evan Linwood of ArenaCore brought a slightly obscure document from TMF to my attention. It is entitled “SD1-44 Connectionless Technology Management” and I can’t even find it on anymore. As it states, “This supporting document [to MTOSI] aims at specifying a framework for supporting connectionless technologies from the Interface. While seeking compliance with the generic modelling concepts recommended in ITU-T (G.809 [7], G.8010 [8]) this work is initially intended to address the management of Ethernet and related technologies as defined in ITU-T G.8011 [9] and MEF 10 [15].

It provides some really fascinating insights into how an OSS can handle network / service modelling in connectionless environments. If you are ever tasked with modelling a connectionless network, this document is well worth a read (if you can find it)!

I have v11. Support for point-to-point services (Ethernet Private Line (EPL), Ethernet Virtual Private Line (EVPL)) are provided in compliance with MEF 10 [15] definitions. MEF Phase 2 however has not yet completed its work on multipoint services (Ethernet Private Local Area Network (EPLAN), Ethernet Virtual Private Local Area Network (EVPLAN)) at the time this TMF specification was published.

If this article was helpful, subscribe to the Passionate About OSS Blog to get each new post sent directly to your inbox. 100% free of charge and free of spam.

Our Solutions


Most Recent Articles

2 Responses

  1. Hi Ryan,
    Thanks very much for the mention! As I’ve got more of a ‘connectionless’ background I found this document a little hard to navigate at first, but a good friend Jamie Chard sat me down and explained add/drop multiplexing and other concepts in SDH/PDH networks, and also how Transport MPLS has been layered in since then. The continuing evolution is fascinating to watch!

  2. Hi Evan,
    Good point… I come from the Telco side (SDH/PDH) so there were some similarities in how I used to model those networks (and DWDM, ATM, ADSL, etc) back in the early 2000s. In fact the doc probably would’ve come in handy if I had it back then! 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.