Chuong 2.html

ADSL, VDSL, and Multicarrier Modulation . John A. C. Bingham Copyright # 2000 John Wiley & Sons, Inc. Print ISBN 0-471-29099-8 Electronic ISBN 0-471-20072-7

2

ADSL NETWORK ARCHITECTURE, PROTOCOLS, AND EQUIPMENT

A. J. Weissberger P.O.Box 3441,Santa Clara,CA 95055-3441,E-mail: alan@lambdanetworks.com
2.1 ADSL ADVANTAGES AND APPLICATIONS
ADSL is attractive to both telcos and users, because it solves two problems simultaneously:

1. It provides a simple, affordable mechanism to get more bandwidth to end users: both residential and small-to medium-size business. This is increasingly important for Internet access, remote access to corporate servers, integrated voice /data access, and transparent LAN interconnection.

2. It enables carriers to offer value-added, high-speed networking services, without massive capital outlays, by “leveraging” the copper loop. Examples include access to frame relay or ATM networks, virtual private networks, video distribution, streaming, or video retrieval services.

In North America, the driving applications of ADSL are high-speed Internet access and remote access to corporate LANs. Other applications include video retrieval or streaming, interactive multimedia communications, video on demand, video catalog shopping, and digital telephony: either voice telephony over ATM or voice over IP (VToA and VoIP).

In Asia and parts of Europe (e.g., United Kingdom and Germany) video on demand (VoD) and audio playback are much more important than in the United States. Ironically, VoD was the ADSL application driver for North America in 1993 but has since been abandoned by most U.S. telcos. In Asia, however, where there is not as large an installed cable TV customer base, ADSL could be very important for video and audio distribution.

9
2.2 ADSL TRANSPORT MODES: STM OR ATM?

The original ADSL standard was designed to carry compressed digital video (i.e., MPEG2), n  64 kbit/s and DS1 dedicated circuits. This class of information transfer is known as synchronous transport mode (STM). With the redirection of ADSL to transport IP packets, there was a movement to support variable-length frames (e.g., HDLC or Ethernet MAC) as part of STM. Since 1997 ATM, or cell-based transport, has been favored over STM (in order to support IP packets as well as compressed video and other realtime or QOS-based applications), and G.992.2 (G.lite) supports only ATM transport.

Since the majority of telco networks now have ATM backbones, the extension of ATM over the subscriber enables the telco to take advantage of economies of scale. It also dispenses with protocol conversion at the access-network-to-corenetwork-interface. Finally, an ATM network can more easily scale up to accommodate more subscribers and/or higher access speeds. This would make it easy for a carrier to accommodate growth in both the numbers and downstream bit rates of ADSL lines and to build the infrastructure for VDSL (see the discussion on network architecture in Section 2.3).

With ATM over ADSL, users are connected to a network service provider (NSP) via virtual circuits¹. Currently, both a PPP over ATM stack (for Internet and secure corporate server access) and a native-mode ATM protocol stack (for real-time and multimedia applications) are used in conjunction with PVCs. In the future ATM SVC signaling (a.k.a. ATM Forum UNI or ITU Q.2931 signaling) and ATM network management (ATM Forum ILMI) messages will be supported in the access node and the ATM over ADSL CPE.

For ATM over ADSL as de®ned in T1.413 or G.992.2, user data is segmented into cells, which are then transmitted and received over the subscriber loop by the pair of ADSL modems (the NT on the customer premises and the access node in the networkÐtypically on a line card within a DSLAM or ATM edge switch).

The ATM network supports various traf®c classes to realize the desired user service. These are speci®ed on a virtual circuit basis, along with subordinate traf®c class /QOS parameters. From highest to lowest priority, these traf®c classes are:

1. Constant bit rate (CBR)
2. Real-time and non-real-time variable bit rate (VBR)
3. Available bit rate (ABR)
4. Unspeci®ed bit rate (UBR)
Today, most ADSL networks use only UBR, but those supporting high-quality video or audio also use CBR. Those ADSL modems that support both these traf®c classes must implement multiclass queuing and traf®c scheduling, so as always to give priority to CBR traf®c.
All three ADSL-DMT standards specify the same cell TC for mapping ATM cells into the user data ®eld of an ADSL physical layer frame. There are separate cell TCs for the interleave and fast paths: corresponding to the ADSL channels (AS0 and AS1 downstream and LS1 and LS2 upstream) in use. Only one channel, in each direction of transmission, exists for G.992.2, but up to two upstream and downstream channels are optional in T1.413-II and G.992.1². Hence for dual latency in a given direction of transmission, the cell TC appears as two physical layers to the ATM layer. An example of this would be the concurrent use of video retrieval on the interleave path and Internet access or digital telephony (e.g., VToA) on the fast path.
In addition to cell delineation, the cell TC performs other functions:

¹ Today these are private virtual circuits (PVCs), but carriers plan to offer switched virtual circuits (SVCs) in the future. In the meantime two techniquesÐsoft PVCs, which are effectively PVCs that have been set up but never taken down, and auto-con®guration extensions to the ILMI MIBÐcan be used for more ¯exible provisioning.

1. It inserts and removes idle cells from the ADSL physical layer user data.
2. It scrambles/descrambles the cell payload.
3. It checks for HEC violations on each received cell and discards cells with HEC errors.
4. It performs sublayer bit timing ordering.
5. It reports both the inability of the receiver to acquire cell delineation (no cell delineation) and the loss of cell delineation after it had been acquired. These anomalies are reported in indicator bits within the ADSL superframe.

The ATU-R is required to maintain three cell TC counters to monitor cell TC performance.

Sublayer interfaces for the cell TC are de®ned in a T1.413-II Annex for the ATM layer above (nominally, the UTOPIA or UTOPIA 2 interface from the ATM Forum) and the sync/control multiplexing PHY sublayer below. Again, one cell TC is required for each latency path/ADSL channel.

2.3 ATM END-TO-END NETWORK ARCHITECTURES AND PROTOCOL STACKS

Initially, ATM over ADSL modems used PVCs and IETF RFC 1483 bridging to encapsulate user data into AAL5 packets and then into ATM cells. The modems were transparent to the higher layer protocols (e.g., TCP/IP, IPX, Appletalk, etc). Each customer was preassigned a local label in the ATM cell header (VPI.VCI) to correspond to the NSP with which the customer wanted to communicate. For example, one PVC could be assigned for an ISP and another to communicate with corporate headquarters. However, higher layer protocols used by NSPs could not effectively be overlaid on top of the RFC 1483±based protocol stack.

² Sometimes called G. regular to distinguish it from G.lite!

For Internet access and remote access to corporate servers it was highly desirable to use the same “legacy” programs for authentication, billing, and encryption/security that are used by NSPs today. These are all operational over the Internet engineering task force (IETF)’s point-to-point protocol (PPP). To facilitate the PPP over ATM over ADSL capability, the ADSL Forum has completed TR-0012: an end-to-end architecture for the transport of PPP over ATM over ADSL. This is likely to be implemented by the majority of ADSL equipment vendors. In this scheme, the entire ATM network is reduced to a set of virtual point-to-point leased lines, and all traf®c is sent on a “best effort basis” using the ATM unspeci®ed bit rate (UBR) traf®c class.

Whereas today, only PVCs are used with ADSL, a catalyst for SVCs will be widespread use of Microsoft’s ATM protocol stack, including SVC signaling, in Windows 98 and Windows 2000 (formerly known as Windows NT). This will encourage use of SVCs end to end, which are much easier than PVCs to maintain in a large network. A potential problem for SVCs is that the ATM address plans of telcos differ, creating nonunique ATM addresses, which may be either E.164 public network addresses or private network service access points (NSAPs). Another issue is mapping SVC UNI signaling messages to/from the ADSL facilities and the ATM network behind the access node (see the discussion of DSLAM in Section 2.3.1).

Since there is no quality of service (QoS) capability or multicasting with the PPP over ATM architecture, vendors desiring to provide video/high-quality audio on demand, VToA/VoIP, or real-time video conferencing over ADSL, must chose a classical ATM protocol stack. These stacks have been well de®ned by the ATM Forum and ITU-T and include:

^* MPEG2 over ATM (using AAL 5)
^* Structured circuit emulation service³ (for n  64 kbit/s circuits) ^* VToA desktop³ (using AAL 5 or AAL2)
^* Video conferencing over AAL 5 or AAL 1

Thus there are three ATM protocol stacks for ATM over ADSL:

^* RFC 1483 encapsulation/bridging
^* PPP over ATM as in ADSLF TR-0012
^* Classical ATM (ATMF and ITU-T for real-time, interactive applications

such as VoD, video streaming, VToA, conferencing, etc.)
2.3.1 New Equipment Needed for ADSL

³These applications may use the network timing reference (see Section 8.2.1).

In addition to the ADSL central site and remote site modems, the key new network infrastructure equipment required to make ADSL a commercial reality is the digital subscriber-line access multiplexer (DSLAM). This equipment aggregates a large number of ADSL subscribers into one or a few uplink ports to a frame relay or ATM backbone network (edge switch or router). The uplink interface is formally known as the V reference point. It is typically a DS3/E3 facility, but could also be n  DS1/E1 with inverse multiplexing, or even SONET OC3c/STM-1 (155 Mbit/s).

NOTE: The architecture of the DSLAM may determine the entire design of the ADSL network. Some DSLAMs handle only ATM over ADSL (e.g., Alcatel); others support a variety of DSLs with both ATM and frame-based transport (e.g., Ascend).

The DSLAM acts as a VPI/VCI cross-connect for PVCs (the VPI/VCI “labels” have only local signi®cance for a particular point-to-point ATM link). It must aggregate traf®c from ADSL links and map to uplink. Conversely, the DSLAM must distribute traf®c from the uplink to the appropriate ADSL port (more than one, if multipoint virtual circuits are supported). UPC/policing of ATM traf®c contracts will also be required in the DSLAM.

For SVCs, UNI signaling messages could be passed transparently through the DSLAM in con®gurations known as virtual UNI and SVC tunneling. However, there are major problems with these methods that will greatly restrict their use. More likely, the DSLAM will terminate UNI signaling messages (as the network side of the UNI) and map them over the V reference point, as either the user side of the UNI or an access node-to-node interface (ANNI). In this scenario, there are independent signaling state machines, each of which has intimate knowledge of the link(s) to which they are connected. Hence connection admission control (CAC) and QoS parameter negotiation can be done properly at call setup time.

With the great interest in PPP over ATM, there is a perceived need for new adjunct equipment (behind the DSLAM) for concentrating or terminating PPP sessions at the boundary between the network service provider (NSP) and the access network: for example, either an L2 access concentrator (LAC) or a broadband access server (BAS). The LAC concentrates multiple PPP sessions into a smaller number of PVCs to the NSP’s broadband network. The BAS terminates the PPP sessions and probably handles authentication, billing, and security functions (if needed). The LAC and BAS may be colocated with the DSLAM in a central of®ce, or many DSLAMs can be connected to a single LAC/ BAS. It is expected that one or the other of these adjuncts will be deployed in either an access provider or ISP network.

The formal speci®cation of these and other network equipment adjuncts will be done by the ADSL Forum under core network architecture.
NOTE: Since so much of the ADSL network architecture will be reusable by VDSL, it is imperative for ADSL to be successful if VDSL is to leverage off it. This includes DSLAMs, access multiplexers, ATM over ADSL NTs, standardized protocol stack and network management, and so on. Hopefully, the ATM access network being developed for ADSL will be fully operational and reliable by the time telcos are able to deploy VDSL in a big way. This will greatly increase VDSL’s chances of success.

2.4 MAPPING DIGITAL INFORMATION TO ADSL USER DATA
2.4.1 Premises Architecture and DTE-to-DCE Interface The method to map user data to ADSL PHY will depend on the customer premises con®guration. This is likely to be one of the following:

^* Integrated network interface card (NIC): especially for G.992.2 ^* Single user (via bridging): 10BaseT, universal serial bus (USB), ATM25 ^* Multiple users (via routing): twisted-pair and wireless home networks, 10

Base T, IEEE 1394

In the last two con®gurations a speci®c DTE-to-DCE interface (e.g., PC to ADSL NT) will be required. This interface is currently not standardized. However, there are several candidates for premises architectures. These include:

^* Broadband media access protocol (BMAP) in ADSL Forum and USB

Interoperability Group
^* PPP over Ethernet (PPPOE) in ADSL Forum
^* Frame-based UNI (FUNI) over Ethernet in ATM Forum
^* Layer 2 tunneling protocol (L2TP), which is an IETF draft (note that

PPTP is Microsoft’s version of this)

BMAP and PPPOE extend the PPP session to the client PC, while FUNI is independent of PPP. Both BMAP and FUNI take advantage of an ATM protocol stack in the PC (e.g., from Microsoft), which effectively enables “ATM to the desktop” without an ATM premises PHY. PPPOE assumes an IEEE 802.3/ Ethernet interface with no ATM stack in the PC.

When supporting PPP to the client PC, the ADSL NT must be able to map a PPP session to the associated virtual circuit label (i.e., VPI/VCI). Each of the premises architectures noted above has a different procedure to do that.

NOTE: It is interesting that none of the ATM bridging/routing speci®cations de®ned previously (e.g., LAN Emulation, MPOA, RFC 1577) is being seriously considered for ATM over ADSL.

MAPPING DIGITAL INFORMATION TO ADSL USER DATA 15
2.4.2 Traf®c Shaping

Once the bridging/routing technique is ®xed within the ADSL NT, its next concern is traf®c shaping of the ATM cells from the DTE to the US ADSL channel (LS0 or LS1). This will prevent user-generated data, arriving at 10 Mbit/s over a 10 Base T link, from exceeding the ADSL US channel rate of perhaps 384 kbit/s. Traf®c shaping smooths out cell transmissions so as not to exceed a prede®ned peak cell rate (PCR) for a given virtual circuit. The sum of all active PCRs should not greatly exceed the PHY layer bandwidth; otherwise, cells will be lost during busy traf®c periods. While traf®c shaping for UBR class is optional in ATM Forum and ITU-T speci®cations, it will be mandatory for ADSL according to ADSL Forum WT-21⁴ (revision to TR-0002).

2.4.3 Single or Dual Latency at the ATM Layer

If all ADSL communications are over a single ADSL channel (e.g., G.992.2 using the interleave path), then each ATM endpoint (e.g., ISP, corporate HQ, partner company site, etc.) has an ATM address (for SVCs) or preassigned VPIVCI for each PVC. The ambiguity comes in an SVC when there are two ADSL channels (fast and interleave paths). Where is it decided to which latency path (i.e., ADSL channel) the requested SVC should be assigned? Note that because SVCs are set up and cleared dynamically, this information cannot be provisioned! Remember that the latency path is chosen independently for each direction of transmission. Also, the ADSL channels for ATM (AS0, AS1 DS and LS0, LS1 US) are unidirectional (simplex) and correspond one-to-one to the latency path.

For dual latency downstream, an “intelligent” ADSL access node (usually in a DSLAM) may be able to select a latency path based on QOS parameters/ information elements in the setup message, (e.g., CLR, CTD, CDV, etc.). The ADSL NT or DTE terminating UNI signaling messages would simply accept that VPI/VCI mapping to the latency path selected. Many telcos originally thought that dual latency would be needed only for downstream (e.g., for motion video on interleave and real-time applications or Internet/Intranet access on fast path). In this case, the ADSL facility would be con®gured for dual latency downstream and single latency upstream. Some telcos, however, are now saying they would like to have dual latency upstream as well: for burst-error-protected Internet/ Intranet and SVC signaling on the interleave path and real-time applications (VoIP or VToA or video conferencing) on the fast path. Note that there is only a single size for the interleave buffer for all VPI/VCIs that use that path. The buffer depth is chosen to be commensurate with the maximum impulse noise burst expected. It may be on the order of 40 or 50 ms per ADSL link. Therefore, there needs to be a new mechanism to specify the latency path to VPI/VCI mapping for SVCs. Whether this is to be done by a new information element in the UNI signaling message or by convention (e.g., odd VPI/VCI for fast path; even for interleave path) has yet to be determined by the ADSL or ATM Forums.

⁴ See Appendix B.5 for information on ADSL Forum documents.

Once the latency path mapping has been determined, a new ATM layer function must assign each cell to be transmitted to the designated latency path. The VPI/VCI in each cell becomes an index to a 1-bit lookup table that speci®es the correct path (ADSL channel).⁵In addition to selecting a latency path for user data, one must also be assigned for both signaling and ILMI (ATM access via SNMP) messages. If we have dual latency downstream and single latency upstream, which downstream path should be selected for these control and management protocols? This assignment has yet to be standardized.

In a dual latency environment, the ability to reassign bandwidth from one latency path to another after modem startup is known as rate repartitioning (RR). Since bandwidth usage is not static, RR would be highly desirable. It is optional in T1.413-II, and speci®ed in informative Annex K. However, the means for the ATM layer to request RR and notify of its completion has yet to be standardized (see WT-21 open issues in Section 2.6).

2.5 UNIQUE ADSL REQUIREMENTS FOR ATM
Many of the ATM over ADSL issues are addressed in ADSL Forum WT-21 [ADSLF, 1998]:

^* Speci®c reference models: functional blocks and interfaces ^* Transport of ATM over ADSL, including the problems presented by dynamic rate change:
^* DRA and RR (dual latency mode) for full-rate ADSL (T1.413 and G.992.1)
^* Fast retrains and full retrains/restart for G.992.2
^* QOS and traf®c management
^* Functional block de®nitions
^* ATM Forum and ITU-T signaling (for SVCs)
^* Management: including use of OAM cells according to ITU Recommendation I.610
^* ATM virtual circuit assignment
^* Annexes on:
^* Relationship to other reference models
^* Standards work cross reference
^* SVC call load analysis
^* ATM VP/VC assignment in dual latency mode

⁵None of the commercially available ATM SAR chips has this capability today; they will need to be modi®ed for dual latency full-rate ADSL.
ADSL NETWORK MANAGEMENT AND MANAGEMENT INFORMATION BUSSES 17
Still more issues, however, remain unresolved; these include:

^* Effects of G.992.2 power management, which may put the modems into a “sleep mode”, where they would not be able to accept incoming calls, respond to OAM cells, or acknowledge ILMI “keep alive” messages. One simple solution would be to disable the G.992.2 power-down mode, but that would defeat one of the primary purposes of the recommendation for customer premise equipment!

^* Can any ATM traf®c class other than UBR be supported by G.992.2? If there is no splitter or mini®lter, then whenever a phone/fax machine goes off hook⁶, a G.992.2 modem may need to do a fast retrain to a lower upstream rate with lower transmit power⁷, to prevent degradation of the voice quality (see Section 9.1.3). Even worse, if the ring trip or dial pulsing transients cause a loss of synchronization, a full retrain will be needed. Fast and full retrains, as presently de®ned, take 2 to 3 and 10 to 12 seconds, respectively, and they “take down” the PHY layer, thus breaking a traf®c contract. Thus bandwidth for CBR and real-time VBR cannot be guaranteed, and only UBR traf®c would be possible.

NOTE: This makes a strong case for the use of mini®lters, as described in Section 9.1.6.

^* SNMP as an ADSL facility network management protocol? Note that G.997 and Annex L of T1.413 specify use of SNMP over a “clear” embedded operations channel for both regular and lite.

^* New ATM UNI signaling (information elements?) for dual latency path selection and RR between the fast and interleave paths.
^* Autoprovisioning of PVCs and SVCs to permit:
^* New PVCs to be created or modi®ed
^* ADSL NT self-discovery of con®guration parameters
^* ATM addresses of potential destinations (for SVCs)

2.6 ADSL NETWORK MANAGEMENT AND MANAGEMENT INFORMATION BUSSES

All three ADSL standards and recommendations (T1.413 and G.992.1 and.2) de®ne physical layer management capabilities. These include a parameter exchange at modem startup (discrete tones for T1.413, and G.994 for G.992); bidirectional indicator bits, which report receiver status every superframe (17 ms); and an embedded operations channel (eoc) for in-service testing and selected measurements. The indicator bits, eoc and an ADSL overhead channel (aoc), are contained within each superframe. Performance monitoring (PM) is also speci®ed in these standards; it is mandatory for the ATU-C and optional for the ATU-R. The detailed PM aspects of ADSL in general and G.992.2 in particular will be covered in an appendix to a revision of T1.231 [ANSI, 1993a]. Near-end PM is de®ned as what the receiver observes and detects; far-end PM is what the (remote) far end detects and sends back via indicator bits. Both near-and far-end PM are mandatory at the ATU-C.

⁶ The channel will also change (improve) when a phone goes back on hook, but it is unlikely that protocols will be developed in the near future to take advantage of increased channel capacity.
⁷This power cutback needs to be performed autonomously, because the higher layers cannot know when a phone goes off hook. Methods of detecting a change of impedance of the line have been proposed.

The ADSL Forum has standardized TR-006±ADSL Line MIB [ADSLF, 1998] for exchange of SNMP messages between an EMS (SNMP manager) and a DSLAM (SNMP agent), at the Q reference point. There is a modi®ed version of that MIB speci®ed in G.997 for use over the G.992 facility. The NM protocols for G.997 are SNMP over byte-oriented HDLC frames over a “clear eoc”. No UDP or TCP/IP is required. However, the de®nitive ADSL MIB is likely to come from the IETF, which is the guardian of SNMP MIBs. A draft IETF MIB for ADSL is currently being reviewed.⁸

Other ADSL Forum NM speci®cations include:

^* WT-022 (DMT line code-speci®c MIB)
^* WT-023 (CAP line code-speci®c MIB)
^* WT-025 (CMIP-based network management framework)

While WT-22 is essentially an extension of TR-006 ADSL line MIB, it is not clear either how or if the latter two ADSL Forum NM speci®cations will be used. The ATM Forum’s ILMI (SNMP over AAL5) MIB will also be needed for ATM over ADSL, but the managed objects de®ned will not be speci®c to ADSL. A proposal to extend ILMI for autoprovisioning of PVCs will probably be accepted.

Summary. The ADSL facility is managed using ADSL PHY layer management (G.997 for G.9.992). The ATM aspects over ADSL will be managed by OAM cells (I.610) and the ILMI (SNMP). The EMS-to-DSLAM NM will be via either the ADSL Forum’s line and DMT MIBs (SNMP) or, when completed, the IETF’s ADSL MIB.

⁸ This document de®nes a standard SNMP MIB for ADSL lines based on the ADSL Forum standard data model. The ADSL standard describes ATU-C and ATU-R as two sides of the ADSL line. This MIB covers both ATU-C and ATU-R agents’ perspectives. Each instance de®ned in the MIB represents a single ADSL line. It should be noted that much of the content for the ®rst version of this document came from work completed by the ADSL Forum’s network management working group and documented in [ADSLF, 1998].

OBSERVATIONS 19
2.7 OBSERVATIONS

ADSL, both regular and lite, has the potential to provide very cost-effective high-speed Internet and remote access for residential and SOHO users. For this objective to be realized, new interfaces, equipment, and protocols will be needed. Standardized network management tools must be in place for con®guration/ auto provisioning, fault detection, and performance monitoring. Further, we ®rmly believe that SVCs, in conjunction with both PPP and classical ATM protocol stacks, will be necessary to achieve scalable networks. QOS and point-to-multipoint virtual circuits would permit ADSL to be an enabling technology for video retrieval, video streaming, digital voice (VToA and VoIP), and multimedia conferencing. Let us hope that the ADSL and ATM Forums can work together to resolve many of the open issues identi®ed here. Doing so will greatly increase ADSL’s commercial success and viability.