(mirror)

Technology Solutions

Product & Infrastructure Integration

Product and Service Description

DC.030

Telstra Service Interface Specification

(TSIS) for ADSL Access

End User Interface, Issue 3.8

Approved by:

Boris Corluka

New Products Manager

Telstra Retail

Approved by:

David Ives

Principal Product Manager

Telstra Retail

Process Owner:

Denis Mullane

General Manager

Telstra Retail

Approved by:

David Gibson

Group Product Manager

Infrastructure Services &

Wholesale

Implementation: August, 2000

Issue 3.8, 17 October, 2000

Page 1 of 29

Telstra Corporation Limited, ACN 051 775 556, ABN 33 051 775 556

Telstra Service Interface Specification (TSIS) for ADSL Access

DC.030

TABLE OF CONTENTS

1.....PURPOSE .................................................................................................................................3

2.....SCOPE......................................................................................................................................3

3.....SERVICE DESCRIPTION ........................................................................................................3

4.....PERFORMANCE OBJECTIVES..............................................................................................5

5.....END USER INTERFACE..........................................................................................................5

5.1.

Customer Cabling Configurations .......................................................................................5

5.2.

ADSL Access Service - Maximum ADSL Line Rate Options ..........................................10

5.3.

Physical and Electrical Interface .......................................................................................10

5.4.

Protocol Description........................................................................................................11

5.4.1. ADSL Access Protocol Support

5.4.2. Standards Compliance – End User Protocols over ATM

,

11

12

5.4.3. Standards Compliance - ATM Layer 13

5.5.

Service Testing/Verification..............................................................................................16

5.6.

Customer Obligations ......................................................................................................17

5.6.1. Client Software Required for the Customer or (Third Party) End-User Personal Computer

(PC) 17

5.6.2. General Requirements for Customer Premises Equipment (CPE) 17

5.6.3. Requirements for ADSL Modems, Routers, and Network Interface Cards Connected to

Telstra’s ADSL Access Network 17

5.7.

Conditions for ADSL Access Service Activation and Assurance.......................................19

6.....REFERENCES ........................................................................................................................20

7.....DEFINITIONS ........................................................................................................................21

8.....ATTACHMENT 1: Non-Mandatory Clauses that are (or are not) Supported in the RFC’s and

ITU-T Recommendations, Applicable to Telstra’s ADSL Access Service .........................................22

8.1.

Introduction.....................................................................................................................22

8.2.

Definitions .......................................................................................................................22

8.3.

Non-mandatory Clauses ..................................................................................................23

8.4.

Differences between RFC 2684 and RFC 1483...............................................................27

9.....DOCUMENT CONTROL SHEET..........................................................................................28


DC.030


Page 2 of 29

1. PURPOSE

ADSL Access will enable customers with access to Telstra’s Public Switched

Telephone Network (PSTN) to make and receive calls in the usual manner, while simultaneously accessing high speed data applications, such as Internet access. This service access is based on ADSL modem technology which enables existing twisted pair telephone lines to support broadband data applications concurrently with narrowband PSTN Basic Access.

The following products and services are available via ADSL Access:

Big Pond

Advance (ADSL) service,

FlexStream



(Wholesale ADSL Access), and



HyperConnect



(Remote Network Access).

The purpose of this Telstra Service Interface Specification (TSIS) is to describe the service interface that will be provided for ADSL (End User) Access for a range of

Telstra products, including the physical and electrical interface, and higher level protocols that will be supported for these services.

While care has been taken in compiling this TSIS, Telstra does not warrant that it is accurate or complete. This TSIS is for information purposes only and independent enquiries should be made to confirm the information it contains.

For more information on ADSL Access, contact a Telstra Sales Consultant,

Communications Consultant or Account Executive.

2. SCOPE

This Service Interface Specification defines the physical and electrical characteristics of the service interface for products available via ADSL (End User) Access. The higher level protocols that are supported are also defined, as well as maximum ADSL data rates. The requirements for interfacing with Customer Premises Equipment (CPE), ie modems, routers and Network Interface Cards (NIC) for customer personal computers

(PC), to interwork with Telstra’s network equipment (DSLAM/CMUX) will be defined by referencing the Telstra document IP 1149 “The Telstra ADSL Network – Listing

Requirements for CPE”, Issue 2.

General requirements are also provided for Customer Premises Equipment (CPE) including modems, routers and Network Interface Cards (NIC) for customer PCs, that are to be connected to Telstra’s network.

For more information on the availability of ADSL Access, contact a Telstra Sales

Consultant, Communications Consultant, or Account Executive.

3. SERVICE DESCRIPTION





Registered trade mark in Australia of Telstra Corporation Limited

Trade mark in Australia of Telstra Corporation Limited


Page 3 of 29


DC.030

ADSL is an access technology which enables existing twisted pair telephone lines to support high speed broadband data applications concurrently with narrowband

PSTN telephony service. The ADSL Access service diagram is shown in Figure 1.

Figure 1. ADSL Access Service Diagram

ADSL Access Maximum Line Rate Options (Note 1, 2):

(1) Up to 256 kbit/s downstream (from the exchange to the End User) and Up to 64 kbit/s upstream (from the End User to the exchange).

(2) Up to 512 kbit/s downstream (from the exchange to the End User) and Up to 128 kbit/s upstream (from the End User to the exchange).

(3) Up to 1.5Mbit/s downstream (from the exchange to the End User) and Up to 256 kbit/s upstream (from the End User to the exchange).

Access

Concentrator

Corporate

Intranet

Tesltra

DSLAM or CMUX

End User

Unit or

Modem

Location of ADSL

End User

Copper pair

Telstra

Switched Data

Network

Telstra PSTN

Service

Provider

Note 1. Actual ADSL line rate depends on cable length and condition.

Note 2. Actual throughput speed of customer data depends on cable length and condition, end-to-end latency, protocol overheads, traffic load conditions, and Service Provider interconnect speeds.

DW14MA0A.PPT

(

Telstra’s ADSL Access service will provide broadband access for applications such as

High Speed Internet (

Big Pond



ADSL), and Remote Network Access

HyperConnect



) for access to corporate LANs (eg for business executives).








DC.030


Page 4 of 29

The customers will be able to make and receive phone calls in the usual manner, at the same time that ADSL Access is being used for high speed data applications, eg Internet access.

The customers using ADSL for access to broadband data applications will also have access to a slightly reduced range of PSTN features associated with the phone service.

For more information on the PSTN features that are available for ADSL customers, contact a Telstra Sales Consultant, Communications Consultant or Account Executive.

1

ADSL Access will be available within

Telstra designated Service Areas only

.

ADSL Access will only be provided

subject to the availability of suitable metallic pairs for ADSL

. ADSL Access will

not be provided on pairs with loading coils or pair gain systems.

For information on the availability of the ADSL Access service, in your area, refer to the web site http://www.telstra.com.au/adsl/.

ADSL Access does not include any Customer Premises Equipment (CPE) including

ADSL modems, routers, Network Interface Cards (NIC) for customer PC, or the customer PC itself as part of an ADSL Access service. ADSL Access does not include in-line Low Pass Filters or Central Filters that may be required for use with

PSTN devices (eg telephone).

Customers (eg. service providers, or corporate networks) will have virtual connections to their ADSL (end user) customers or ADSL enabled staff, via Telstra’s Switched

Data Network (SDN).

4. PERFORMANCE OBJECTIVES

Any performance objectives, service activation targets, restoration targets, and service level agreements will only be applicable, where these are defined for a product that is implemented using ADSL Access, eg

Big Pond



Advance (ADSL) service,

FlexStream



(Wholesale ADSL Access), and

HyperConnect



(Remote Network Access).

5. END USER INTERFACE

5.1. Customer Cabling Configurations

To obtain an ADSL Access service, there must be an existing telephone service on

Telstra’s PSTN, that is compliant with Telstra’s ADSL service qualification requirements.

There are two possible configurations for customer cabling and connection of the ADSL modem and existing CPE (eg telephone).

1

Currently, the following products and services will

not

be available for customers on the same cable pair with ADSL access:

OnRamp

TM

services, ANT1, Payphones,

12 kHz metering, 50 Hz metering,

Faxstream



Siteline

Duet



Products, Satellite IPSTS services,

CustomNet

services, Multiple Number,

InContact

TM



services,

services, and any leased analogue services.








Page 5 of 29


DC.030

In the first configuration, in-line Low Pass Filters (LPF) are required for insertion between the telephone socket and customer non-ADSL device (eg telephone). The

ADSL modem is connected directly (without an in-line filter) to a spare telephone socket. In some cases, an additional socket will need to be installed. Figures 2 shows the customer cabling for the ‘in-line Low Pass Filter configuration’.

For the alternative configuration, a central filter is required on the customer-side of the network boundary to split the internal wiring into separate voice and data pairs. All sockets used for PSTN services (eg telephone, answering machines etc) must be connected through this filter. The network boundary may be at a cabling distributor, a network termination device or a socket near the building entry point. Figures 3A, 3B and 3C have been prepared to show some typical cabling arrangements for the ‘central filter' option.

Lead-in

Cable

Building

Entry

Point

(BEP)

DW3AP0B.PPT

Network

Boundary

Point (NBP)

TO-1

(First

Socket)

In-Line Low

Pass Filter (LPF)

Telephone

TO-2

(2nd

Socket)

ADSL

Modem

CPE, etc

Customer PC

TO-n

(Additional

Sockets, etc)

Notes:

(1) An additional socket may be required for ADSL modem.

(2) This configuration is not suitable for Mode 3 installations & hard-wired (without plug and socket) installations

(3) Where a Cabling Distributer (ie MDF) is installed in the customer premises, this is the Network Boundary Point

Figure 2. ADSL Access Cabling - Configuration 1, In-Line Low Pass Filters (LPF)


DC.030


Page 6 of 29

DW28AU0A.PPT

Lead-in

Cable

Note 4

Central

Filter

N

T

D

Line

ADSL

Phone

Network

Boundary

Point (NBP)

ADSL

Modem

TO-1

(Socket for data)

Customer PC

TO-2

(Socket for voice)

Telephone

TO-n

(Additional Voice Sockets, etc)

Notes:

(1) An additional socket will be required for ADSL modem.

(2) This configuration is suitable for Mode 3 installations & hard-wired (without plug and socket) installations

(3) Where a Cabling Distributer (ie MDF) is installed in lieu of a Network

Termination Device (NTD), it is Network Boundary.

(4) In some cases, the Network Termination Device (NTD) and Central Filter may be in the same enclosure.

Figure 3A. ADSL Access Cabling - Configuration 2, Central Filter


Page 7 of 29


DC.030

Lead-in

Cable

DW31AU0B.PPT

Network

Boundary

Point (NBP)

TO-1 First Socket

(alternative data socket)

Building

Entry

Point

(BEP)

Central

Filter

Phone

ADSL

Modem

TO-2

(Socket for data)

Customer PC

TO-3

(Socket for voice)

Telephone

Telephone

TO-n

(Additional Sockets, etc)

Notes:

(1) Additional sockets may be required for new First Socket (TO-1) and for ADSL modem.

(2) This configuration is suitable for Mode 3 installations & hard-wired (without plug and socket) installations

(3) Where a Cabling Distributer (ie MDF) is installed in the customer premises, it is the Network Boundary Point.

Figure 3B. ADSL Access Cabling - Configuration 3, Central Filter


DC.030


Page 8 of 29

DW9SE0A.PPT

Customer cabling

Central

Filter

M

D

F

IDF

Line

ADSL

Phone

Network

Boundary

Point (NBP)

ADSL

Modem

TO-1

(Socket for data)

Customer PC

Telephone

TO-2

(Socket for voice)

TO-n

(Additional Voice Sockets, etc)

Notes:

(1) An additional socket will be required for ADSL modem.

(2) This configuration is suitable for Mode 3 installations & hard-wired

(without plug and socket) installations

(3) Where a Cabling Distributer (ie MDF) is installed Fig 3A or Fig 3B could apply in the Customer’s tenancy area

Figure 3C. ADSL Access Cabling - Configuration 4, Central Filter


Page 9 of 29


DC.030

5.2. ADSL Access Service - Maximum ADSL Line Rate

Options

ADSL Access

will provide the following maximum ADSL Line Rate options

2

:-

(1) Up to 256 kbit/s downstream (from the exchange to the End User) and

Up to 64 kbit/s upstream (from the End User to the exchange).

(2) Up to 512 kbit/s downstream (from the exchange to the End User) and


(3) Up to 1.5Mbit/s downstream (from the exchange to the End User) and


5.3. Physical and Electrical Interface

The Service Delivery Point (SDP) for the ADSL Access service will be via a telecommunications outlet (TO) socket, as shown for the standard configurations given in Figures 2 and 3. Where this socket has been installed by Telstra, the socket pin connections will be as shown in Figure 4.

The Physical and Electrical characteristics of the ADSL Access service provided via the

TO socket conform with the following ANSI specification and ITU-T

Recommendations:-

ANSI Specification T1.413, Network and Customer Installation Interfaces –

ADSL, Metallic Interface, Issue 2

ITU-T G.992.1 (7/99) Asymmetrical Digital Subscriber Line (ADSL)

Transceivers


Transceivers

In addition, modems, routers and Network Interface Cards connected to Telstra’s

ADSL Access service must comply with the following Telstra specification, available on the website at

http://www.telstra.com.au/adsl/

:-

IP 1149 “The Telstra ADSL Network – Listing Requirements for CPE”,

Issue 2

Note

that currently Telstra only supports G.DMT for connection of modems, routers and Network Interface Cards.

2

The actual ADSL line rate will depend on cable length and condition. Actual Customer Data throughput rate may vary and depends on local cable length and condition, end-to-end latency, protocol overheads, network traffic conditions, and Service Provider interconnect speeds.


DC.030


Page 10 of 29

Blu/Wh

Blue

FCC Type

68, 8-Way

Socket

4

5

FCC Type

68, 8-Way

4

Plug

5

ADSL

Modem

Figure 4. Pin Connections for FCC Type 68, 8-Way Connectors installed by Telstra for ADSL Access Service

DW3AP0A.PPT

5.4. Protocol Description

5.4.1. ADSL Access Protocol Support

The ADSL Access service will support the following protocols for end user, customer equipment:-

(1) PPP over Ethernet

3

IP/PPP/PPPoE/AAL5/ATM

See Figure 5 for an example of the protocol stack that will be supported with a standalone modem.

(2) PPP over ATM

4

IP/PPP/AAL5/ATM

See Figure 6 for an example of the protocol stack that will be supported with a PC NIC card.

(3) IP Bridged

5

IP/Ethernet

6

/1483B/AAL5/ATM

See Figure 7 for an example of the protocol stack that will be supported.

(4) IP Routed

3

IP/1483R/AAL5/ATM

See Figure 8 for an example of the protocol stack that will be supported.

3

For PPP over Ethernet, a maximum of up to eight (8) simultaneous PPP sessions may be supported per ADSL

Access service, subject to network traffic conditions, Service Provider interconnect speeds and end to end latency.

For PPP over Ethernet, one (1) PPP session will be supported per end user PC.

4

For PPP over ATM, a single user only (ie single PPP Session) is supported per ADSL Access service, at any given time.

5

For Bridged networks using IP Bridged protocol one (only) subnetwork is supported. Where a router is used as the gateway to ADSL Access (ie all traffic to/from the ADSL Access service is via this router), then one to five subnetworks are supported for IP Bridged and IP Routed protocols.

6

Ethernet, or any other bridged protocol specified in RFC 1483, can be encapsulated for IP Bridged protocol support.


Page 11 of 29


DC.030

5.4.2. Standards Compliance – End User Protocols over ATM

7, 8

The protocols supported by this service comply with the following ITU-T

Recommendation and IETF RFCs:-

Informational RFC 2516: A Method for Transmitting PPP Over Ethernet

(PPPoE), February 1999

RFC 1483 Multiprotocol Encapsulation over ATM Adaptation Layer 5, July

1993

RFC 2364 PPP Over AAL5, July 1998

ITU-T Recommendation I.363.5, “B-ISDN ATM Adaption Layer (AAL) Type 5

Specification, August 1996

STD0051 (RFC1661) The Point-to-Point Protocol (PPP), 1994, STD

RFC1332 The PPP Internet Protocol Control Protocol (IPCP), 1992,

PROPOSED STANDARD

RFC1994 PPP Challenge Handshake Authentication Protocol (CHAP)

RFC1334 PPP Authentication Protocols, October 1992

The ADSL Access service complies with the following RFC for the Dynamic Host

Configuration Protocol (DHCP) Relay Agent function:-

RFC1542 Clarifications and Extensions for the Bootstrap Protocol, October

1993

For more information regarding non-mandatory clauses that may or may not be supported in the above RFCs and ITU-T Recommendation, for the End User

Protocols, see Attachment 2.

7

Customers and (third party) end users should check with their Service Provider, whether Challenge Handshake

Authentication Protocol (CHAP) and/or Password Authentication Protocol (PAP) authentication is supported and any conditions that apply to authentication procedures. If the client software rejects CHAP, ADSL Access will support PAP authentication with a password of up to 15 characters.

8

Big Pond



ADSL services support CHAP authentication only and there is a user name and password limit of 8 characters.





DC.030


Page 12 of 29

5.4.3. Standards Compliance - ATM Layer

The ATM protocol layer supported by this service complies with the following ANSI specification and ITU-T Recommendations:-

ANSI Specification T1.413, Network and Customer Installation Interfaces –

ADSL, Metallic Interface, Issue 2


Transceivers


Transceivers

In addition, modems, routers and Network Interface Cards connected to Telstra’s

ADSL Access service must comply with the following Telstra specification, available on the website at

http://www.telstra.com.au/adsl/

:-

IP 1149 “The Telstra ADSL Network – Listing Requirements for CPE”, Issue

2

Note:

(1) The ADSL Access service supports a single ATM virtual circuit for the end user interface.


Page 13 of 29


DC.030

Customer

PC

ADSL modem

PPP

DSLAM or CMUX

Access

Concentrator

IP

PPP

PPPoE

LLC/SNAP

10BaseT

IP

PPP

PPPoE

1483-LLC/SNAP-B

AAL 5

ATM

ADSL

IP

PPP

PPPoE

1483-LLC/SNAP-B

AAL 5

ATM

Telstra Network Transmission

Figure 5. Protocols for ADSL Access Service:

PPP over Ethernet

DW6MA0A.PPT

ADSL NIC

PPP

DSLAM

(CMUX)

Access

Concentrator

IP

PPP

PPPoAAL5*

AAL5

ATM

ADSL

PPP over ATM

*

PPPoAAL5 as per RFC2364

IP

PPP

PPPoAAL5*

AAL5

ATM


Figure 6. Protocols for ADSL Access: PPP over ATM

DW21MA0A.PPT


DC.030


Page 14 of 29

End User PC or Network

ADSL modem

DSLAM

(CMUX)

Access

Concentrator

IP

Ethernet*

10BaseT

IP

Ethernet

1483-LLC/SNAP-B

AAL5

ATM

ADSL

IP

Ethernet

1483-LLC/SNAP-B

AAL5

ATM


* =

Ethernet is shown here, but this could be any bridged protocol specified

in RFC 1483.

DW22MA0A.PPT

Figure 7. Protocols for ADSL Access: IP Bridged

End User PC or Network

Router with

ADSL interface

DSLAM

(CMUX)

Access

Concentrator

IP

Ethernet*

10BaseT

IP

1483-LLC/SNAP-R

AAL5

ATM

ADSL

IP

1483-LLC/SNAP-R

AAL5

ATM


* =

Ethernet is shown here, but this could be any bridged protocol

Figure 8. Protocols for ADSL Access: IP Routed

DW22MA0B.PPT


Page 15 of 29


DC.030

5.5. Service Testing/Verification

The following Service Verification Test has been developed by Telstra for ADSL

Access, and will be employed by Telstra to determine whether the ADSL Access service is operating satisfactorily at the time the test is conducted.

Where the end user is a third party (ie a customer of Telstra's customer), the end user should contact their Service Provider to resolve all difficulties. Where the test described in Paragraph 3, below, is employed, the Service Provider is expected to be present and engage in all negotiations with the third party end user.

Remote Network Access customers should contact their Corporate Network Help

Desk to address any difficulties, in the first instance. The Corporate Network Help

Desk will contact Telstra, if the difficulty cannot be resolved.

(1) In the first instance, the end user will be requested by the Service

Provider or Corporate Network Help Desk to connect their ADSL modem or router, and synchronisation of the modem/router will be verified by the synchronisation LED on the modem/router (if available).

(2) If the above test (1) is passed, the end user will be able to further verify the service with the Service Provider or Corporate Network Help Desk by accessing a Home Page provided by the Service Provider or Corporate.

(3) Where the results of the above tests (1) and (2) are inconclusive, Telstra may require the service provider to arrange to connect their own ADSL modem and laptop PC with suitable client software to prove synchronisation and access to a test home page will not function.

Alternatively, for PPP over Ethernet and PPP over ATM services, Telstra may choose to connect their own ADSL modem and laptop PC with suitable client software to the service. Synchronisation of the modem and access to a test home page will be demonstrated directly with the customer in the case of a retail Telstra customer, or in the presence of a Service

Provider's representative if a Service Provider is the customer.

For IP Bridged and IP Routed services, Telstra may choose to connect their own ADSL modem and laptop PC to the service. Synchronisation of the modem and a successful “ping” (ICMP) test to the Service Provider’s router or corporate network router will be demonstrated. Theses tests will be demonstrated directly with the customer in the case of a retail

Telstra customer, or in the presence of a Service Provider's representative if a Service Provider is the customer.

Note that the above “ping” (ICMP) test will be performed to the customer router terminating the ADSL Service Provider Access ( ie Telstra’s service to allow Service Providers and Corporate Networks to connect to the ADSL network and access their end users or ADSL enabled staff.) The Service

Provider or corporate customer will need to configure the interface on this router associated with the end user service to respond to a “ping” test.


DC.030


Page 16 of 29

5.6. Customer Obligations

5.6.1. Client Software Required for the Customer or (Third Party) End-

User Personal Computer (PC)

A list of suitable Client Software for the customer’s or (third party) end user’s PC, for interworking with ADSL Access using PPP over Ethernet, will be made available by

Telstra on the website at http://www.telstra.com.au/adsl/.

5.6.2. General Requirements for Customer Premises Equipment (CPE)

The following customer obligations apply to equipment that is connected to Telstra’s

ADSL Access network:-

•

The customer should only use ADSL modems, routers, and network interface cards, which comply with industry standards. These modems, routers, and network interface cards should be labelled with the ACA compliance mark (‘A’ tick) or comply with ACIF Technical Standard S043 (when this standard has been finalised.)

•

The customer shall operate the modems, routers, and network interface cards, within the agreed operating range/instructions.

•

The customer shall comply with a carrier “Requests To Disconnect” if there are reasons to believe that the modems are causing interference to other services.

5.6.3. Requirements for ADSL Modems, Routers, and Network Interface

Cards Connected to Telstra’s ADSL Access Network

ADSL Access is intended for use with modems

,

routers, and network interface cards, conforming with protocols defined in ANSI Specification T1.413, Issue 2 and Telstra

Document IP 1149 “The Telstra ADSL Network – Listing Requirements for CPE”,

Issue 2.

Line Polarity and Line Conductor Polarisation:

ADSL modem equipment shall be independent of line conductor polarisation, ie. the connection of specific conductors of the line pair to specific line terminals of the modem, and will remain unaffected by, any reversal (momentary or otherwise) in line polarity which occurs or may occur while connected to ADSL Access.

Safety:


Page 17 of 29


DC.030

Any modems, routers, and network interface cards, or any other equipment connected to the Telstra network shall conform to the safety requirements of AS/NZS 3260

[9]

.

9

AS/NZS 3260:1993 Approval and test specification -Safety of information technology equipment including electrical business equipment


DC.030


Page 18 of 29

Emission of Electromagnetic Interference:

Any Modems, routers, network interface cards, or any other equipment connected to the Telstra network shall conform with the Class B requirements of AS/NZS 3548

[10] or equivalent, to show compliance with the ACA EMC Framework

[11]

5.7. Conditions for ADSL Access Service Activation and

Assurance

The following conditions for service activation and assurance apply to the ADSL

Access service:

•

Prior to an ADSL service order being submitted, it will be necessary to have a working Telstra PSTN Service (this includes a PSTN service supplied by another carrier or carriage service provider under a resale agreement between Telstra and the carrier or carriage service provider), or the telephone service must be ordered in conjunction with the ADSL service.

•

An ADSL Access service will be provided for

Telstra designated Servicing

Areas only.

Also, ADSL Access will only be provided subject to the availability of suitable metallic pairs for ADSL.

•

For information on any charges that may be associated with the installation of

ADSL Access (including the Central Filter, if required), contact your Telstra Sales

Consultant, Communications Consultant, or Account Executive.

•

The customer will be responsible for providing a suitable 240V Mains power outlet for the ADSL modem.

•

Telstra will not be responsible for either PC faults or PC configuration errors, or faults in customer owned wiring or caused by other CPE, or for splitters, 'in line' filters and ADSL modems sourced by customer or service provider unless there is an ongoing maintenance contract. This is also the case if Telstra performed the original installation and configuration work as the working service would have been demonstrated after installation.

•

If any of these customer owned or service provider sourced elements are suspected as being the source of a fault, or the fault can be isolated to any of these sources , then either the end user or the Service Provider or a contractor engaged for that purpose by the Service Provider or the Corporate (in the case of Remote Network

Access) will be responsible for rectifying the fault.

10

AS/NZS 3548:1995 Limits and methods of measurement of radio disturbance characteristics of information technology equipment (IEC/CISPR 22:1993)

11

ACA EMC Framework - http://www.aca.gov.au/standards/index.htm


Page 19 of 29


DC.030

6. REFERENCES

Document Number

Best Current Practice

RFC 2119

Informational RFC 2516

Title

Key Words for use in RFCs to Indicate Requirement Levels, March

1997.

A Method for Transmitting PPP Over Ethernet (PPPoE), February 99

RFC 1483

RFC 2364

STD0051 (RFC1661)

RFC1332

RFC1994

RFC1334

ITU-T Recommendation

I.363.5

Multiprotocol Encapsulation over ATM Adaptation Layer 5, July 1993

PPP Over AAL5, July 1998

The Point-to-Point Protocol (PPP), 1994, STD

The PPP Internet Protocol Control Protocol (IPCP), 1992, PROPOSED

STANDARD

PPP Challenge Handshake Authentication Protocol (CHAP)

PPP Authentication Protocols, October 1992

B-ISDN ATM Adaption Layer (AAL) Type 5 Specification, August 1996

ANSI Specification T1.413,

Issue 2

AS/NZS 3260:1993 and 1997

Supplement

Approval and test specification -Safety of information technology equipment including electrical business equipment

AS/NZS 3548:1995

Network and Customer Installation Interfaces – ADSL, Metallic

Interface

ACA EMC Framework

Limits and methods of measurement of radio disturbance characteristics of information technology equipment (IEC/CISPR

22:1993)

http://www.aca.gov.au/standards/index.htm


DC.030


Page 20 of 29

7. DEFINITIONS

The following words, acronyms and abbreviations are referred to in this document.

Term

BEP

CPE

LPF

NBP

PC

PSTN

SDP

ACA

Definition

Building Entry Point

Customer Premises Equipment

In-line Low Pass Filter

Network Boundary Point

Personal Computer

Public Switched Telephone Network

Service Delivery Point

The Australian Communications Authority


Page 21 of 29


DC.030

8. ATTACHMENT 1: Non-Mandatory Clauses that are (or are not)

Supported in the RFCs and ITU-T Recommendations,

Applicable to Telstra’s ADSL Access Service

8.1. Introduction

This document lists the clauses of RFC 2684, 1483, 2364, and 2516 that are nonmandatory. Non-mandatory clauses contain at least one of the following words: MAY,

SHOULD, OPTIONAL, and RECOMMENDED. The definitions of these clauses are defined in RFC 2119.

This document also highlights the differences between RFC 2684 and 1483.

Support for the non-mandatory clauses of STD0051, RFC1332, or RFC1994 is to be advised

8.2. Definitions

The following definitions were taken from RFC 2119.

SHOULD

. This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

SHOULD NOT

. This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behaviour is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behaviour described with this label.

Bradner, Best Current Practice [Page 1] _ RFC 2119 “Key Words for use in RFCs to

Indicate Requirement Levels”, March 1997.

MAY

. This word, or the adjective "OPTIONAL", mean that an item is truly optional.

One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)


DC.030


Page 22 of 29

8.3. Non-mandatory Clauses

For RFC 2516

A Method for Transmitting PPP Over Ethernet (PPPoE)

, the nonmandatory clauses are given in the following table.

Table 2 RFC 2516 Non-Mandatory Clauses

Clause Identifier

[5.5] The PPPoE Active

Discovery Terminate

(PADT) packet

[8]. Other

Considerations

[9]. Security

Considerations

[9]. Security

Considerations

[9]. Security

Considerations

Non-mandatory statement from RFC 2516

A PPP peer

SHOULD

use the PPP protocol itself to bring down a PPPoE session, but the PADT

MAY

be used when PPP can not be used.

When a host does not receive a PADO packet within a specified amount of time, it

SHOULD

resend its PADI packet and double the waiting period. If the Host is waiting to receive a PADS packet, a similar timeout mechanism

SHOULD

be used, with the Host re-sending the PADR. After a specified number of retries, the Host

SHOULD

then resend a PADI packet.

To help protect against Denial of Service (DOS) attacks, the Access Concentrator can employ the

AC-Cookie TAG. The Access Concentrator

SHOULD

be able to uniquely regenerate the

TAG_VALUE based on the PADR SOURCE_ADDR.

While the AC-Cookie is useful against some DOS attacks, it can not protect against all DOS attacks and an Access Concentrator

MAY

employ other means to protect resources

[The Access Concentrator]

SHOULD

never refuse a request based on the Service-Name TAG, and always return the TAG_VALUE that was sent to it.

Or it

SHOULD

only accept requests with a Service-

Name TAG with a zero TAG_LENGTH (indicating any service). The former solution is

RECOMMENDED

.

Telstra Implementation

Supported

Supported

Not supported

Not supported

Supported

Appendix A

TAG_TYPES and

TAG_VALUES

0x0103 Host-Uniq

0x0104 AC-Cookie

The Host

MAY

include a Host-Uniq TAG in a PADI or PADR.

The Access Concentrator

MAY

include this TAG in a PADO packet.

0x0105 Vendor-Specific Use of this TAG is

NOT RECOMMENDED

. To ensure inter-operability, an implementation MAY silently ignore a Vendor-Specific TAG.

0x0110 Relay-Session-Id This TAG

MAY

be added to any discovery packet by an intermediate agent that is relaying traffic.

0x0202 AC-System-Error This TAG indicates that the Access Concentrator experienced some error in performing the Host request. It

MAY

be included in PADS packets.

Supported

Supported

No vendor-specific tag

Not supported

Supported

For RFC 2364

PPP Over AAL5

, the non-mandatory clauses are given in the following table.


Page 23 of 29


DC.030

Table 3 RFC 2364 Non-mandatory Clauses


[3]. AAL5 Layer Service

Interface

[6]. LLC Encapsulated PPP

Over AAL5

[6]. LLC Encapsulated PPP

Over AAL5

[8]. Detection And Recovery

From Unsolicited PPP

Encapsulation Transitions


The PPP layer treats the underlying ATM AAL5 layer service as a bit-synchronous point-to-point link. In this context, the PPP link corresponds to an ATM AAL5 virtual connection. The virtual connection MUST be full-duplex, point to point, and it

MAY

be either dedicated (i.e.

permanent, set up by provisioning) or switched (set up on demand).

The end points

MAY

be bi-laterally provisioned to send other LLC-encapsulated protocols besides PPP across the same virtual connection. However, they MUST NOT send packets belonging to any protocol that has an active NCP within the PPP session.

Implementations

SHOULD

do packet scheduling that minimises the performance impact on the quality of service commitments associated with both the LLC-encapsulated

PPP and non-PPP protocol flows.

Once PPP has entered the Network-layer Protocol phase, and successfully negotiated a particular NCP for a PPP

Protocol, if a frame arrives using an alternate but equivalent data encapsulation as defined in [4], then the PPP Link

MUST:

For a SVC, immediately clear the call with the cause value 111, "protocol error, unspecified".

For a PVC: tear down the active NCPs,

SHOULD

generate an error message, enter the Termination state, and silently drop all received packets.


Supported

Supported

Supported

No SVC support

[8]. Detection And Recovery

From Unsolicited PPP

Encapsulation Transitions

[9]. LCP Configuration

Options

[9]. LCP Configuration

Options

Implementation Note

An implementation which requires PPP link configuration, and other PPP negotiated features (such as authentication),

MAY

enter Termination state when configuration fails.

The Magic Number LCP configuration option is

RECOMMENDED

, and the Protocol Field Compression

(PFC) option is

NOT RECOMMENDED

.

When an ATM AAL5 PVC is in the "Stopped" state, it is

RECOMMENDED

that the implementation wait for

Configure-Requests.

Implementation does not require configuration

Supported

Supported


DC.030


Page 24 of 29

For RFC 1483

Multiprotocol Encapsulation over ATM Adaptation Layer 5


Table 4 RFC 1483 “SHALL” Clauses


[3] AAL5 Frame Format


No matter which multiplexing method is selected, routed and bridged PDUs shall be encapsulated within the Payload field of

AAL5 CPCS-PDU.


Supported

[4.1] LLC Encapsulation for

Routed Protocols

Conformance to payload format for Routed ISO

PDUs. See “Payload Format for Routed ISO

PDUs” diagram in RFC1483

Supported


Routed Protocols


Routed Protocols

Conformance to payload format for Routed non-

ISO PDUs (use of LLC/SNAP)

See “Payload Format for Routed non-ISO


Supported

Conformance to payload format for Routed IP

PDUs (use of LLC/SNAP)

See “Payload Format for Routed IP


Supported


Bridged Protocols


Bridged Protocols

(p.9)

Conformance to payload format for Bridged

PDUs: 802.3, 802.4, 802.5, FDDI and 802.6.

See relevant diagrams in RFC1483 (pp 7-9)

Supported

Note that the Common PDU Header and

Trailer of the encapsulated frame should not be simply copied to the outgoing 802.6

subnetwork because the encapsulated

BEtag value may conflict with the previous

BEtag value transmitted by that bridge.

Supported

[5] VC Based Multiplexing

(p.10)

[5.1] VC Based Multiplexing of Routed Protocols (p.10)

[5.2] VC Based

Multiplexing of Bridged

Protocols (pp.11-12)

The carried protocol can be either manually configured or negotiated dynamically during call establishment using signalling procedures.

PDUs of routed protocols shall be carried as such in the Payload of the AAL5

CPCS-PDU.

Conformance to VC-MUX payload format for

Bridged PDUs: 802.3, 802.4, 802.5, FDDI and

802.6. See relevant diagrams in RFC1483 (pp 11-

12)

Supported

Supported

Supported


Page 25 of 29


DC.030

For RFC 2684

Multiprotocol Encapsulation over ATM Adaptation Layer 5


Table 5 RFC 2684 Non-mandatory Clauses

Clause Identifier Non-mandatory statement from RFC 2684

[4]. AAL5 PDU Format A reassembly timer

MAY

be used.

[5.2]. LLC

Encapsulation for

Bridged Protocols

A bridge that uses the Bridged Ethernet/802.3

encapsulation format without the preserved LAN

FCS

MAY

either include padding, or omit it.

[5.2]. LLC

Encapsulation for

Bridged Protocols

[8.3] VC multiplexing of routed or bridged PDUs within a VPN

Since the 802.5 Access Control (AC) field has no significance outside the local 802.5 subnetwork, it is treated by this encapsulation as the last octet of the three octet PAD field. It

MAY

be set to any value by the sending bridge and MUST be ignored by the receiving bridge.

When a routed or bridged PDU is sent within a VPN using VC multiplexing, the VPN identifier

MAY

either be specified a priori, using ATM connection control signalling or administrative assignment to an ATM interface, or it MAY be indicated using an encapsulation header.



If a PDU is received containing a VPN encapsulation header when the VPN has been identified using

ATM signalling, the receiver

MAY

drop it and/or take other actions which are implementation specific.

If a PDU is received containing a VPN encapsulation header when the VPN identifier has been administratively assigned, the receiver

MAY

drop it and/or take other actions which are implementation specific.


Supported

Supported

Supported

Supported

Supported

Supported


DC.030


Page 26 of 29

8.4. Differences between RFC 2684 and RFC 1483

The following table highlights the differences between RFC 2684 and RFC 1483, sourced from RFC 2684 Appendix E Differences from RFC 1483

Table 6 Differences of RFC 2684 and 1483

Usage of NLPID encapsulation is clarified in terms of the RFC 2119 conventions

A pointer to RFC 2364 is added to cover the case of PPP over ATM

RFC 1755 and RFC 2331 are referenced to describe how encapsulations are negotiated, rather than a long-obsolete CCITT (now ITU-T) working document and references to work then in progress

Usage of AAL5 is now a reference to ITU-T I.363.5. Options created in AAL5 since the publication of

RFC 1483 are selected

Formatting of routed NLPID-formatted PDUs (which are called "routed ISO PDUs" in RFC 1483) is clarified

Clarification is provided concerning the use of padding between the PID and MAC destination address in bridged PDUs and the bit ordering of the MAC address.

Clarification is provided concerning the use of padding of Ethernet/802.3 frames

A new encapsulation for VPNs is added – substantive security considerations were added

A new appendix D provides a summary of applications of multiprotocol over ATM


Page 27 of 29


DC.030

9. DOCUMENT CONTROL SHEET

Contact for Enquiries and Proposed Changes

If you have any questions regarding this document contact:

Name: John M. Norman

Designation: P3, Integration Specialist

Phone:

Fax:

(03) 9634 5670

(03) 9634 6903

If you have a suggestion for improving this document, complete and forward a copy of

Suggestions for Improvements to Documentation

(form 000 001-F01).

Issue No

DRAFT

2.3

3.1

3.2

3.3

3.4

3.5

2.7

2.8

2.9

3.0

DRAFT

2.4

DRAFT

2.5

3.6

3.7

3.8

Issue Date

20 March, 2000

3 April, 2000

3 April, 2000

Nature of Amendment

Document Updated to include additional End User protocols, including

PPP/ATM, IP Bridged and IP Routed.

Details of Protocol Stacks, including optional clauses supported in RFCs provided by Rajiv Chaudhuri and Architecture Team.

Changes made as revisions, following comments from the project teams and product managers, business units, Regulatory, etc

Changes accepted and submitted for legal review.

26 April, 2000

27 April, 2000

28 April, 2000

4 May, 2000

Updated to describe End User Interface only

Changes Accepted

Minor technical changes

Minor changes following Legal Review.

16 May, 2000

19 May, 2000

25 May, 2000

17 August, 2000




Minor product details changed.

8 September, 2000 Changes to Section 5.1 Customer Cabling Configurations, Section 5.5

Service Verification Test, inclusion of

HyperConnect



product name.

6 October, 2000 Changes to Section 5.1 Customer Cabling Configurations, including Figures

2, 3A and 3B, and addition of Figure 3C. Removal of information regarding

Customer Trials. Notes 3 and 4 added for Section 5.4.1. Updated Section

5.5 Service Testing/Verification. Revised Section 5.6.2 General

Requirements for Customer Premises Equipment (CPE). Minor textual and formatting changes.

10 October, 2000 Revisions accepted.

17 October, 2000 Typographical Corrections





DC.030


Page 28 of 29

ACKNOWLEDGMENTS

This document refers to the following Requests for Comment (RFC) as defined by the Internet Engineering Task

Force: Best Current Practice RFC 2119, Informational RFC 2516, RFC 1483, RFC 2364, STD0051 (RFC1661), RFC1332,

RFC1994, RFC1334

This document refers to the following recommendations from the International Telecommunications Union,

Telecommunication Standardization Sector (ITU-T):- G.992.1 (7/99), G.992.2 (7/99), I.363.5.

This document refers to the following specifications from the American National Standards Institute:- ANSI

Specification T1.413, Issue 2.

This document refers to the following Australian Standards:- AS/NZS 3260:1993 and 1997 Supplement,

AS/NZS 3548:1995

This document refers to the Australian Communications Authority, Electromagnetic Compatibility (EMC) Framework

(

http://www.aca.gov.au/standards/index.htm)

CONDITIONS OF USE OF THIS SPECIFICATION

This publication has been prepared and written by Telstra Corporation Limited (ACN 051 775 556), and is copyright.

Other than for the purposes of and subject to the conditions prescribed under the Copyright Act, no part of it may in any form or by any means (electronic, mechanical, microcopying, photocopying, recording or otherwise) be reproduced, stored in a retrieval system or transmitted without prior written permission from the Senior Manager,

Product & Infrastructure Integration, Network Technology Group, Telstra Corporation. Product or company names are trademarks or registered trademarks of their respective holders.

Note for non-Telstra readers: The contents of this publication are subject to change without notice. All efforts have been made to ensure the accuracy of this publication. Notwithstanding, Telstra Corporation Limited does not assume responsibility for any errors nor for any consequences arising from any errors in this publication.

Disclaimer

Telstra reserves the right to revise this document for any reason, including but not limited to reasons relating to conformity with relevant international and national standards, application of advances in technology, the commercial availability of communications systems or changing customer demands.


Page 29 of 29


DC.030

(mirror)

Technology Solutions

Product & Infrastructure Integration

Product and Service Description

DC.030

Telstra Service Interface Specification

(TSIS) for ADSL Access

End User Interface, Issue 3.8

Implementation: August, 2000

TABLE OF CONTENTS

1. PURPOSE

2. SCOPE

3. SERVICE DESCRIPTION

Figure 1. ADSL Access Service Diagram

4. PERFORMANCE OBJECTIVES

5. END USER INTERFACE

5.1. Customer Cabling Configurations

5.2. ADSL Access Service - Maximum ADSL Line Rate

Options

5.3. Physical and Electrical Interface

5.4. Protocol Description

ADSL NIC

ADSL modem

5.5. Service Testing/Verification

5.6. Customer Obligations

5.7. Conditions for ADSL Access Service Activation and

Assurance

6. REFERENCES

7. DEFINITIONS

8. ATTACHMENT 1: Non-Mandatory Clauses that are (or are not)

Supported in the RFCs and ITU-T Recommendations,

Applicable to Telstra’s ADSL Access Service

8.1. Introduction

8.2. Definitions

8.3. Non-mandatory Clauses

8.4. Differences between RFC 2684 and RFC 1483

9. DOCUMENT CONTROL SHEET

Contact for Enquiries and Proposed Changes

Related manuals

Cisco

SRP527W

Billion

BiPAC 7300GX

Billion

BiPAC 7404VGOX

Netcomm

NB1300

Billion

BiPAC 7402X Series

Traverse

Pulsar

Atlantis

WebShare 3G 244WN

D-Link

502G - DSL Router - EN

Netcomm

NB2

Avaya

BCM50