Sunday, May 27, 2007

PPPoE Circuit ID tagging feature in DSLAM

This is the latest Issue I am dealing with - I am suppose test this feature in the DSLAM project I am working in !!!

In an Ethernet access network, there is no unique mapping between the subscriber and the ADSL port. This cause problems in RADIUS access and accouting because the RADIUS server expect the BRAS to send information about the ADSL port it is authenticating and accoring for.

How this work - During the authentication phase the BRAS includes the NAS-Port-Id attribute(Radius attribute 87) in RADIUS authentication and RADIUS Accounting request that identifies the DSL line of the subscriber.

To over come this problem DSL Forum TR-101 proposes that the DSLAM sends the DSL Line-Id in the PPP over Ethernet (PPPoE) discovery phase pkts.








RFC 2516 – Defines A Method for Transmitting PPP Over Ethernet (PPPoE) ,

TR – 101 specifies that the Vender specific TAG 0x0105 in PPPoE Discovery pkts should be added by the DSLAM :

----------------------------------------------------------------
0x0105 Vendor-Specific
This TAG is used to pass vendor proprietary information. The first four octets of the TAG_VALUE contain the vendor id and the remainder is unspecified. The high-order octet of the vendor id is 0 and the low-order 3 octets are the SMI Network Management Private Enterprise Code of the Vendor in network byte order, as defined in the Assigned Numbers RFC [4]. Use of this TAG is NOT RECOMMENDED. To ensure inter-operability, an implementation MAY silently ignore a Vendor-Specific TAG.
----------------------------------------------------------------

Vender specific TAG 0x0105 will look like this after DSLAM TAG the PPPoE pkt with the Circuit-ID













This Tag will be Identified by the BRAS (PPPoE server) and send to the RADIUS server with Authentication request and the Accounting request as RADIUS attribute 87 (in rfc2869)

-------------------------------------------------------------
5.17. NAS-Port-Id Description
This Attribute contains a text string which identifies the port of the NAS which is authenticating the user. It is only used in Access-Request and Accounting-Request packets. Note that this is using "port" in its sense of a physical connection on the NAS, not in the sense of a TCP or UDP port number. Either NAS-Port or NAS-Port-Id SHOULD be present in an Access- Request packet, if the NAS differentiates among its ports. NAS- Port-Id is intended for use by NASes which cannot conveniently number their ports. A summary of the NAS-Port-Id Attribute format is shown below. The fields are transmitted from left to right.
Type 87 for NAS-Port-Id.
--------------------------------------------------------------

to come up with above content I referred the documents given below :

rfc4679 - Vendor-Specific RADIUS Attributes
rfc2865 – RADIUS Authentication
rfc2866 - RADIUS Accounting
rfc2869 - RADIUS Extensions
rfc2516 - A Method for Transmitting PPP Over Ethernet (PPPoE)
TR-101 - Migration to Ethernet-Based DSL Aggregation
http://www.cisco.com/en/US/products/ps6441/products_feature_guide09186a00804fc456.html

Sunday, May 20, 2007

ADSL ???

One thing that was not thought about ADSL at University (atleast in my case)was that the data communication between the DSLAM and the Modem is ATM ,










this is the case when you are using an IP DSLAM , but if you are using a DSLAM with ATM uplink the communication from Modem to the aggregater can be over ATM or even from PC to the aggregate cab be ATM , but the now many ISPs are using IP DSLAMs .

DHCP relay & Option 82

I had a major time searching for a DHCP serve which supports DHCP relay function as well as DHCP option82:

DHCP option 82 - provides a method to send relay agent information and the DHCP client's port information to the DHCP server, according to my experience this feature is quite popular in IP DSLAMs .

well , I tried few DHCP servers :


Windows 2000 advanced server - DHCP option 82 not available originally but when the service pack 4 was installed DHCP option 82 was available due to lack of explanation about how to set up the option 82 I could not still setup option 82 in win 2000 advanced server.

Linux , Fedora core 4 - By default the DHCP server supports DHCP option 82 , I did not have to configure anything . When received a DHCP discovery with the option 82 the FC4 server reply with the Option 82.

DHCP turbo - I downloaded DHCP Turbo form Internet (trial version) , well this software support option 82 but the sofware was not that stable , after some time it stops responding to any DHCP discovery ... then I had to restart my PC to make the DHCP server work again. Hope they will fix the stability issues . Anyway it was very easy to configure and don't need any special server platform to work , so it was very useful.
http://www.weird-solutions.com/weirdSolutions/pages/02products/02turbo/dhcpTurbo/index.php

will write more about DHCP , special my experience with DHCP server responding unicast or Broadcast !!!


Ruwan Indika