APNIC Home APNIC Home
Info & FAQ |  Resource services |  Training |  Meetings |  Membership |  Documents |  Whois & Search |  Internet community

You're here:  Home  Mailing Lists wg-bb 


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[WG-BB] Proposal of assignment policy for DSL service



We are a DSL whosaler in Japan.  Now Japanese DSL wholesalers 
and their partner ISPs need some different address assignment 
policies to provide their service smoothly.  Below I will propose 
3 modifications in regard to address assignment policy.

Summary:
-------------------
(1) Deffault assignment size should be as large at least as the 
    number of customers for always-on connections service.
    Besides, DSL wholesalers need additional address space because 
    of their network architecture.

(2) Assignment application should be able to start if the 
    applicant allocates less than 80% addresses.

(3) Deffault assignment size should be large enough for the 
    applicant's business plan at least 6 months ahead.


Explanation:
-------------------
(0) DSL expansion in Japan

These days IP address size which is needed for Internet service 
providers in Japan is drastically expanding.  The emergence of 
some DSL providers has made a substantial contribution to this 
situation.  The number of DSL customers has been increased from 
16,194 (Jan 2001) to 1.79 million (Jan 2002) (Statistics by 
Ministry of Public Management, Home Affairs, Posts and 
Telecommunications).

(1) Adequate assignment size for DSL service is larger than 
    that for other internet access services.

Most of DSL users connect to the internet 24 hours per a day.  
(This situation is similar to CATV internet users.)  Therefor, 
basically a DSL service provider requires IP addresses at least 
as many as the number of customers.

Adding to that, network architecture of DSL wholesaler needs 
additional address space(see figure below).  This architecture 
may be typical for DSL wholesalers in Japan now.  DSL 
wholesaler puts multiple LACs in their network to decentralize 
broadband traffic.  In this architecture every LAC needs to be 
allocated address blocks per every ISP.
Consequently total size for a DSL service is larger than 
that for a dial-up service or a leased line service.


Remote terminal--DSLAM(1)--+--LAC(1)--+   +--LNS--ISP--Internet 
                    .      |    .     |   |
                    .      |    .     |   |
                    .      |    .     +---+
Remote terminal--DSLAM(n)--+    .     |   |--LNS--ISP--Internet
                                .     |   |
                                .     +---+
                                .     |   |
                              LAC(n)--+   +--LNS--ISP--Internet

       <----------------PPP------------------->
                              <-----L2TP------>
*Remote terminal....Remote DSL modem(Customer premises modem)
*DSLAM....DSL Access Multiplexer(Central office equipment)
*LAC....L2TP Access Concentrator
*LNS....L2TP Network Server


 (2) 80% policy imposes severe constraints to DSL diffusion in 
     Japan.

The number of residential DSL users has exploded so abruptly 
that DSL service providers could not cope with it if they could 
not apply IP address assignment before they allocate addresses 
more than 80%, when application process takes 1 month at the 
soonest.


(3) Assignment size for 3 month ahead is too small for rapidly 
    expanding service.

Growing DSL service providers have a tendency to confront 
shortage of addresses within 3 months.  Though fortunately they 
do not confront shortage of address in the period of 
application, their network engineers must configure routers as 
rapidly as possible after assignment, which may overtask for 
them in some cases.
So it is very useful for DSL service providers to enable to be 
assigned address space enough for business plan at least 6 
months ahead.

We believe that this growing pace will continue for 2 or 3 
years in Japan.

Best Regards,

--
miharu jimbo, miharu@eaccess.net
-
- This list (wg-bb) is handled by majordomo@lists.apnic.net