ATM and DSL and IP network

[philip.peck801]

Hi everyone,

I have some questions regarding ATM and DSL. Please explain my questions in a basic language. I have seen many configurations of DSL done on ATM interfaces.

My question.

1- DSL is related to ATM?

2- Does the service provider have also ATM interface and ATM network and what is the span of the ATM network. It spans before internet gateway?

3-ATM cells are 53 byte , where as  IP packets are 1500. How IP network works in this case (Going through  DSL and ATM).

4- we can assign ip on ATM interface. How it works? ATM has its own physical address.

Many thanks.

[Peter Paluch · Accepted solution]

Hi Philip,

1- DSL is related to ATM?

Yes, it is. While DSL is primarily a physical layer technology, there are a few framing formats of choice that are carried over the DSL physical link signalling, and ATM is one of them. ADSL makes heavy use of ATM framing. VDSL service is sometimes provided using Ethernet framing.

The choice of ATM for DSL was logical because at the time DSL was an emerging technology, ATM was relatively popular with service providers. Among other things, it allowed the provider to treat each DSL customer as if connected through a dedicated point-to-point "connection" - in ATM, it is called the virtual circuit. Every customer had its own virtual circuit, so accounting, billing, etc. was relatively easy to apply on virtual circuits independently. Also, because these virtual circuits never "leaked into each other" in the provider's network, customers were perfectly isolated.

2- Does the service provider have also ATM interface and ATM network and what is the span of the ATM network. It spans before internet gateway?

Originally, yes. The ATM network was contiguous - it started at the customer's DSL interface, continued through the DSLAM and through the service provider's network (in fact, the service provider's network was based on ATM) up to the BRAS where the customer's packets were first inspected and either kept in the same service provider's network, or tunneled away to a different internet service provider.

Nowadays, ATM is not used anymore inside service provider's networks. While DSLAMs still need to speak ATM to customer's DSL modems and routers, they no longer use ATM on the interfaces toward the service provider's network. Instead, today's DSLAMs can use technologies such as MPLS pseudowires or Layer2 Tunneling Protocol to carry user data and direct it toward a BRAS.

3-ATM cells are 53 byte , where as  IP packets are 1500. How IP network works in this case (Going through  DSL and ATM).

IP packets are chopped up to pieces of at most 48 bytes (this is the size of the payload portion of an ATM cell) and are carried in multiple ATM cells. ATM actually uses a so-called ATM Adaptation Layer, or AAL, to assist in fragmenting the IP packets and putting them back together. There were multiple AAL types defined in an ATM network; DSL uses AAL5. You can read more about AAL5 here but it is admittedly a fairly involved reading:

https://en.wikipedia.org/wiki/ATM_Adaptation_Layer_5

In original DSL deployments where the entire service provider network was ATM-based, IP packets became chopped and put piece-by-piece into individual ATM cells on the customer's DSL modem, proceeded in this form through the DSLAM and the service provider network to the BRAS where they were reassembled again. In today's networks, IP packets are still put piece-by-piece into ATM frames on customer DSL modems/routers, but based on DSLAM capabilities, they may be reassembled right at the DSLAM and carried over the service provider's network using any suitable technology currenly used - Ethernet, MPLS, L2TP. There is no ATM network anymore between the DSLAM and the BRAS.

4- we can assign ip on ATM interface. How it works? ATM has its own physical address.

Addressing in ATM is a complex issue because on the ATM layer, there is the VPI/VCI addressing, and if we implemented the entire ATM stack including the higher protocols, we would also be using so-called NSAP addressing.

However, the relation between an IP address and a VPI/VCI is somewhat similar to the relation between an IP address configured on an Ethernet interface, and the interface's MAC address. With ATM interface, the IP address is independent of the whole ATM underneath. However, what allows other stations to talk to this IP address is the VPI/VCI configured on the ATM interface, that makes a specific virtual circuit to be processed by this interface and thus reach this IP address. If this ATM interface was used to reach multiple other stations over the ATM network, each of these stations would sit on a different virtual circuit with a different VPI/VCI combination. In the simplest case, you would need to define a mapping of all remote IP addresses onto the specific VPI/VCI combinations that identify virtual circuits going to these respective remote IP hosts. More complex environments used dynamic helper protocols to set up these mappings automatically.

Please feel welcome to ask further!

Best regards,
Peter

[philip.peck801]

Thank you very much. I did not expect to receive such an accurate answer.

I have more questions if you dont mind.

1- Originally, can I compare ATM with TCP/IP? You said physical layer of ATM can be DSL? ATM does not have its own physical and transport and application layers?

2- How about PPPOA? It is IP over PPP over ATM over DSL? Why do we need to set MTU 1500  in PPPOA? How do you relate it to IP packet and PPP frame and ATM cells?

Thank you in advance.

[philip.peck801]

More complex environments used dynamic helper protocols to set up these mappings automatically.

That protocol is NHRP?

thanks

[Peter Paluch · Accepted solution]

Hi Philip,

I apologize for this late reply. It's been a busy week.

1- Originally, can I compare ATM with TCP/IP? You said physical layer of ATM can be DSL? ATM does not have its own physical and transport and application layers?

It is really difficult to exactly compare TCP/IP to ATM because they have been developed in very different environments with very different goals. Even though ATM itself has a fairly complex reference model consisting of 4 layers plus additional planes, it was most often treated just like a (sophisticated) data link layer technology. To TCP/IP, an ATM network was simply an OSI Layer1+2 technology. It is difficult to place or map ATM onto OSI model because, depending on the way it was deployed and perceived, it could be seen either as Layer1+2 (physical + data-link layer) or Layer1+2+3 (up to network layer) technology.

ATM provides virtual circuits between attached hosts, allowing them to talk to each other directly as immediate neighbors, and this would be exactly what OSI Layer2 does. However, ATM also had its own addressing model and was capable of searching for best paths between any two end hosts, which is a Layer3 function. The ATM addressing was derived either from ITU-T E.164 telephone numbering plan (for public networks), or from ISO NSAP addressing (also called ATM End System Address, AESA, for private networks). If the entire internet was based on ATM and used ATM addressing, we would not need IP anymore, and we would be placing TCP/UDP/etc. segments directly into ATM cells, bypassing IP entirely. So from this point of view, ATM was also capable of running as a Layer3 technology. Because it is the style of deploying ATM that has an impact whether ATM will be reduced to Layer2 or Layer3 services, it is so difficult to state with clarity whether ATM is Layer2 or Layer3 technology.

In any case, ATM had numerous physical layer implementations. Check out this presentation for a list of them, and notice that there are different speeds and even different interface types - for LAN, usually, 25 Mbps and 155 Mbps were standardized, while for WAN interfaces (T1, E1, T3, DS1, etc.), there was a multitude of different speeds. With specific regard to DSL, DSL is just another physical layer to ATM.

As you are asking about the layers ATM does or does not have, let's check out the ATM reference model from the Cisco DocWiki ATM page:

ATM has its physical layer called PHY in many variants. Then there is the ATM layer that is roughly equivalent to the data-link layer in that it concerns with carrying "frames" called ATM cells between attached devices. Above the ATM layer is the ATM Adaptation Layer, also called AAL, that governs all processes related to segmentation and reassembly of IP packets and their contents into ATM cells. There were 6 AAL types in total (AAL0 through AAL5) for different types of traffic having different quality of service requirements. Out of these, DSL uses AAL5 which is arguably the simplest one. Our common networks and data-link layer technologies do not usually have a layer similar to AAL, but because the operations of AAL are so closely tied to the process of carrying useful data in ATM cells, AAL and ATM together provide services we're used to seeing in the data-link layer, and that is what is also suggested in the picture above.

ATM did not in general specify higher layer protocols, so you don't see a network/transport/session/presentation/app layer in this model. It simply has the 4th layer saying "higher protocols", and that's where all higher protocols are.

2- How about PPPOA? It is IP over PPP over ATM over DSL? Why do we need to set MTU 1500  in PPPOA? How do you relate it to IP packet and PPP frame and ATM cells?

This is an extensive question and requires lots of explaining.

ATM - as a technology - can provide a virtual circuit between a subscriber and his service provider, but there is a lack of other features a service provider needs to do: authenticating the subscriber, performing the accounting, negotiating what higher protocols will be carried over the virtual circuit (such as IPv4 or IPv6), what settings should those higher protocols use, etc. The virtual circuit provided by ATM was just a raw data conduit, and some other protocol offering all these services was required to carry customer's data over this conduit.

PPP was the natural choice here. It provides easy framing, authentication, accounting properties, it is able to carry multiple packet types itself, it provides mechanisms to negotiate which higher level protocols will be used and how they should be configured, so from this point of view, it was just perfect.

However, there are different ways of carrying PPP frames over ATM circuits, and this causes considerable confusion.

It is absolutely possible for a DSL router to receive IP packets from an attached LAN, encapsulate them into PPP frames and hand them over to the ATM/DSL interface. This ATM/DSL interface will encapsulate the PPP frames into an AAL5 datagram, chop it into ATM cells and send them over the DSL link. This mode of operation is called PPP-over-ATM, or PPPoA, and is based on sending PPP frames right down the ATM/DSL interface. Contrary to what you said, PPPoA does not require modifying the DSL's interface MTU. AAL5 is capable of carrying (segmenting and reassembling) upper-layer datagrams of up to roughly 64 KiB which is far beyond the usual IP packet sizes. With PPPoA, there are absolutely no MTU issues.

The use of PPPoA poses a very strong requirement: It assumes that the device that originates PPP frames is also the endpoint of the ATM circuit (because it needs to feed the created PPP frames directly into the ATM circuit). This in turn means that the device running the PPP driver must be the very device with the DSL interface. For a modern DSL router, there's no problem in doing that because a DSL router has both a built-in DSL interface and also runs the PPP driver internally.

However, in the beginnings of DSL, such integrated routers were extremely rare or did not exist at all. Also, there were no PCI or similar PC extension boards with DSL interfaces on them. Instead, there were only external DSL modems that operated in an extremely simplified way: They had an Ethernet LAN interface, and a DSL WAN interface. Every Ethernet frame received on the LAN interface of a DSL modem was encapsulated in its entirety (including the headers) into AAL5, cut into ATM cells and sent out the DSL interface. In the opposite direction, data arriving in ATM cells on the DSL interface were reassembled into Ethernet frames and sent out the Ethernet interface. There was no routing, no NAT, no PPP, no additional processing involved on such a DSL modem at all. The DSL modem simply carried Ethernet frames to and from the service provider inside ATM cells.

With the lack of any PPP driver in a DSL modem, the PPP driver had to be running on a normal PC using a common Ethernet interface. This posed another problem - if the PC can be connected to the DSL modem over an Ethernet interface only, how should the PPP frames created on the PC be delivered to the DSL modem so they can be ultimately forwarded to the service provider, and vice versa?

You probably guessed it - the PPP frames would get encapsulated into Ethernet frames, and the Ethernet frames would be then sent to the DSL modem, cut into pieces and carried inside ATM cells over the DSL link to the service provider. This approach is called PPP-over-Ethernet, or PPPoE. PPPoE was actually developed independently of ATM and DSL as a means of turning an Ethernet-based LAN into an overlay network of point-to-point PPP circuits between end hosts and an access concentrator, but it came very handy with DSL as well.

With PPPoE, therefore, the basic idea is that the PPP is running on the PC while the DSL modem only takes care of carrying the resulting Ethernet frames over the DSL ATM link as a series of ATM cells and their contents, and the PPP frames will be carried inside the Ethernet frames. However, because Ethernet frames can carry at most 1500 bytes in their payload, this payload now needs to accomodate the added PPP and PPPoE headers plus the original IP packet. PPPoE encapsulation consumes additional 8 bytes in its headers that need to fit into the Ethernet payload. This means that whatever IP packets are originated by the PC, they have to be smaller by 8 bytes than usual, otherwise, after the PPP+PPPoE headers are added, the resulting Ethernet frame would be oversized and considered invalid.

This is the reason why PPPoE needs to have the interface MTU modified from 1500 to 1492 to accomodate the added 8 bytes of PPP+PPPoE headers - to prevent the resulting payload exceeding the maximum allowable size of 1500 bytes for an Ethernet frame.

With today's modern DSL routers running PPP and PPPoE inside, you actually have a choice of configuring your DSL connection as PPPoA (direct PPP into ATM without the intermediary Ethernet encapsulation), or PPPoE. PPPoA is superior to PPPoE in terms of lesser overhead and no MTU issues. However, whether you can use either PPPoE or PPPoA depends on your service provider; some of them support both modes while others support only one of these and you need to discuss with your service provider which mode should be used.

It may come off as surprising to learn that even with integrated DSL routers using their built-in DSL interface, running DSL in PPPoE mode will cause every IP packet routed over the DSL link to be encapsulated in Ethernet+PPPoE+PPP headers even though there is no Ethernet link involved on the WAN side. This is, however, done to meet the provider's expectations. Whenever PPPoE is used, the service provider expects that all data coming in from subscribers of the ATM virtual circuits are encapsulated in Ethernet+PPPoE+PPP frames. The service provider does not care where does the subscriber run his PPP driver - whether it is on his PC or on his integrated router. This gives the service provider the flexibility to communicate in the same way with any kind of customer, either those using simple DSL modems and running PPP software on their PCs, or those using integrated DSL routers.

So to sum it up:

• PPPoA encapsulates PPP frames right into ATM cells (after being handled by AAL5). There are no MTU issues with PPPoA and no MTU modification is required. However, this mode requires that PPP software must be run on the same device that has the DSL interface installed.
• PPPoE encapsulates PPP frames into Ethernet frames plus additional PPPoE headers (to provide specific PPPoE operations; I'm not going to discuss them at this point), and the Ethernet frames are subsequently AAL5-encapsulated and carried in ATM cells. Because the Ethernet payload size is limited to 1500 bytes, the resulting PPPoE+PPP+IP datagram must not exceed 1500 bytes, and with PPPoE+PPP consuming 8 bytes, the maximum size of IP packets needs to be decreased to 1492 bytes. PPPoE allows the user to run PPP software on his PC and use a simple DSL modem, or a DSL router configured in bridged mode, to communicate with the service provider.

More complex environments used dynamic helper protocols to set up these mappings automatically.

That protocol is NHRP?

Yes, among others. There were multiple protocols involved in ATM that dealt with addressing: ATMARP, NHRP, plus helper protocols such as ILMI and PNNI.

Best regards,
Peter