-
Amazon Deals - ToS - Warp
Hayai Broadband Hardware Details
- Thread starter Sushubh
- Start date
- Replies 279
- Views 75,111
- Status
Have the Alcatel CPEs arrived in your office yet? If yes, great, awesome. Could you post pictures? If not, when are they due?
Are you sure that the model number is I-120G-P for home users? I found a lot of models, including I-240G-P, but not I-120G-P in a 'leaked' PDF at www.scribd.com/doc/61247860/I-240G-B-manual . Unfortunately, this PDF seems to have a lot of info taken out, such as the data sheet of I-240G-P. It would be great if you could post the user manual of the CPEs you provide to your customers on your website (preferably in a public area) as Alcatel seems to be severely lacking in that aspect.
I couldn't find anything on Google related to I-120G-P except that Hayai will be using these CPEs for home users. Maybe my Google skills are lacking.
Weirdly, there is no information on these models on the Alcatel Lucent website for the public. It's as if they don't recognise the product. I guess there is loads of stuff on them on the support website which is not accessible publicly.
BTW, Alcatel says in page 1-11 of the above linked scribd document:
"Packet loss occurs in 1G wirespeed. Due to the additional 4-byte routing tag, throughput is less than 1G for all packet lengths"
So it's not just our NICs that don't give a full throughput of 1Gbit/s, your CPEs don't give full throughput either. 🙂
Are you sure that the model number is I-120G-P for home users? I found a lot of models, including I-240G-P, but not I-120G-P in a 'leaked' PDF at www.scribd.com/doc/61247860/I-240G-B-manual . Unfortunately, this PDF seems to have a lot of info taken out, such as the data sheet of I-240G-P. It would be great if you could post the user manual of the CPEs you provide to your customers on your website (preferably in a public area) as Alcatel seems to be severely lacking in that aspect.
I couldn't find anything on Google related to I-120G-P except that Hayai will be using these CPEs for home users. Maybe my Google skills are lacking.
Weirdly, there is no information on these models on the Alcatel Lucent website for the public. It's as if they don't recognise the product. I guess there is loads of stuff on them on the support website which is not accessible publicly.
BTW, Alcatel says in page 1-11 of the above linked scribd document:
"Packet loss occurs in 1G wirespeed. Due to the additional 4-byte routing tag, throughput is less than 1G for all packet lengths"
So it's not just our NICs that don't give a full throughput of 1Gbit/s, your CPEs don't give full throughput either. 🙂
mgcarley
Founder, Hayai Broadband
Have the Alcatel CPEs arrived in your office yet? If yes, great, awesome. Could you post pictures? If not, when are they due?
Soon.
Are you sure that the model number is I-120G-P for home users? I found a lot of models, including I-240G-P, but not I-120G-P in a 'leaked' PDF at www.scribd.com/doc/61247860/I-240G-B-manual . Unfortunately, this PDF seems to have a lot of info taken out, such as the data sheet of I-240G-P. It would be great if you could post the user manual of the CPEs you provide to your customers on your website (preferably in a public area) as Alcatel seems to be severely lacking in that aspect.
Yes, I'm sure of the model number. The devices are more or less the same, just different configurations. The 120G-P has one Ethernet port only and 2 FXS ports. The 240 has 4 ethernet ports. etc.
I couldn't find anything on Google related to I-120G-P except that Hayai will be using these CPEs for home users. Maybe my Google skills are lacking.
Weirdly, there is no information on these models on the Alcatel Lucent website for the public. It's as if they don't recognise the product. I guess there is loads of stuff on them on the support website which is not accessible publicly.
It's not really a consumer device - Unlike xDSL equipment, FTTx stuff usually has a tendency to remain property of the company that issues them, and FTTH gear can't usually be purchased on the open market, mostly because it's often not inter-operable between one platform and another.
BTW, Alcatel says in page 1-11 of the above linked scribd document:
"Packet loss occurs in 1G wirespeed. Due to the additional 4-byte routing tag, throughput is less than 1G for all packet lengths"
So it's not just our NICs that don't give a full throughput of 1Gbit/s, your CPEs don't give full throughput either. 🙂
These were the best of the available options. Motorola also came very close and would be a happy alternative - both scored well above 900mbit/s in field tests on operational networks which isn't far short of awesome in any case.
Even the best NICs with close to 100% throughput offer just that: close to 100%, and the likelihood is far more that it'll be your NIC than our CPE. The only way to really get a full 1G would be to design the equipment to do about 1.1G.
However, the point is still being missed. Whether you can obtain 100% or 95% or 75% of 1G, we are not artificially limiting the line - only the equipment is, and until the next generation of gear comes out commercially, that's where the limitation will remain (10/10 symmetrical isn't too far away - I'd like to start building out 10G to residential subscribers around 2015 or so).
Soon.
Are you sure that the model number is I-120G-P for home users? I found a lot of models, including I-240G-P, but not I-120G-P in a 'leaked' PDF at www.scribd.com/doc/61247860/I-240G-B-manual . Unfortunately, this PDF seems to have a lot of info taken out, such as the data sheet of I-240G-P. It would be great if you could post the user manual of the CPEs you provide to your customers on your website (preferably in a public area) as Alcatel seems to be severely lacking in that aspect.
Yes, I'm sure of the model number. The devices are more or less the same, just different configurations. The 120G-P has one Ethernet port only and 2 FXS ports. The 240 has 4 ethernet ports. etc.
I couldn't find anything on Google related to I-120G-P except that Hayai will be using these CPEs for home users. Maybe my Google skills are lacking.
Weirdly, there is no information on these models on the Alcatel Lucent website for the public. It's as if they don't recognise the product. I guess there is loads of stuff on them on the support website which is not accessible publicly.
It's not really a consumer device - Unlike xDSL equipment, FTTx stuff usually has a tendency to remain property of the company that issues them, and FTTH gear can't usually be purchased on the open market, mostly because it's often not inter-operable between one platform and another.
BTW, Alcatel says in page 1-11 of the above linked scribd document:
"Packet loss occurs in 1G wirespeed. Due to the additional 4-byte routing tag, throughput is less than 1G for all packet lengths"
So it's not just our NICs that don't give a full throughput of 1Gbit/s, your CPEs don't give full throughput either. 🙂
These were the best of the available options. Motorola also came very close and would be a happy alternative - both scored well above 900mbit/s in field tests on operational networks which isn't far short of awesome in any case.
Even the best NICs with close to 100% throughput offer just that: close to 100%, and the likelihood is far more that it'll be your NIC than our CPE. The only way to really get a full 1G would be to design the equipment to do about 1.1G.
However, the point is still being missed. Whether you can obtain 100% or 95% or 75% of 1G, we are not artificially limiting the line - only the equipment is, and until the next generation of gear comes out commercially, that's where the limitation will remain (10/10 symmetrical isn't too far away - I'd like to start building out 10G to residential subscribers around 2015 or so).
Soon.
8 days to go!
Yes, I'm sure of the model number. The devices are more or less the same, just different configurations. The 120G-P has one Ethernet port only and 2 FXS ports. The 240 has 4 ethernet ports. etc.
According to the model number naming scheme in the scribd PDF I linked to in my previous post, I-120G-P should have one POTS port, two GigE ports and no RF ports. I don't know what P signifies.
It's not really a consumer device - Unlike xDSL equipment, FTTx stuff usually has a tendency to remain property of the company that issues them, and FTTH gear can't usually be purchased on the open market, mostly because it's often not inter-operable between one platform and another.
Damn lock-in. When it bites, the pain is significant.
The only way to really get a full 1G would be to design the equipment to do about 1.1G.
True. The difference between the typical throughput at full utilisation and the maximum throughput at full utilisation is significant. I guess that in some very specific lab conditions (including conditions like there be no noise, no EMI, no crosstalk, etc) GigE equipment can perform sufficiently near 1Gbit/s and that outside the lab it doesn't perform as near to 1Gbit/s as it does in the lab conditions it likes. So although the absolute maximum throughput might be 1Gbit/s, in the real world it falls somewhat short of that due to non-ideal conditions.
However, the point is still being missed. Whether you can obtain 100% or 95% or 75% of 1G, we are not artificially limiting the line - only the equipment is, and until the next generation of gear comes out commercially, that's where the limitation will remain (10/10 symmetrical isn't too far away - I'd like to start building out 10G to residential subscribers around 2015 or so).
I didn't miss the point -- the data plans with 1Gbit/s speed is awesome; I was just being pedantic/nitpicking. :-/
It's a bit surprising that although 10GBASE equipment has been available since 2002, 10G-PON equipment started to come out much later in 2010, 8 years after 10GBASE.
8 days to go!
Yes, I'm sure of the model number. The devices are more or less the same, just different configurations. The 120G-P has one Ethernet port only and 2 FXS ports. The 240 has 4 ethernet ports. etc.
According to the model number naming scheme in the scribd PDF I linked to in my previous post, I-120G-P should have one POTS port, two GigE ports and no RF ports. I don't know what P signifies.
It's not really a consumer device - Unlike xDSL equipment, FTTx stuff usually has a tendency to remain property of the company that issues them, and FTTH gear can't usually be purchased on the open market, mostly because it's often not inter-operable between one platform and another.
Damn lock-in. When it bites, the pain is significant.
The only way to really get a full 1G would be to design the equipment to do about 1.1G.
True. The difference between the typical throughput at full utilisation and the maximum throughput at full utilisation is significant. I guess that in some very specific lab conditions (including conditions like there be no noise, no EMI, no crosstalk, etc) GigE equipment can perform sufficiently near 1Gbit/s and that outside the lab it doesn't perform as near to 1Gbit/s as it does in the lab conditions it likes. So although the absolute maximum throughput might be 1Gbit/s, in the real world it falls somewhat short of that due to non-ideal conditions.
However, the point is still being missed. Whether you can obtain 100% or 95% or 75% of 1G, we are not artificially limiting the line - only the equipment is, and until the next generation of gear comes out commercially, that's where the limitation will remain (10/10 symmetrical isn't too far away - I'd like to start building out 10G to residential subscribers around 2015 or so).
I didn't miss the point -- the data plans with 1Gbit/s speed is awesome; I was just being pedantic/nitpicking. :-/
It's a bit surprising that although 10GBASE equipment has been available since 2002, 10G-PON equipment started to come out much later in 2010, 8 years after 10GBASE.
mgcarley
Founder, Hayai Broadband
8 days to go!
Yes, we can count too.
According to the model number naming scheme in the scribd PDF I linked to in my previous post, I-120G-P should have one POTS port, two GigE ports and no RF ports. I don't know what P signifies.
I have the definitions somewhere.
Damn lock-in. When it bites, the pain is significant.
It's not complete lock-in, it's just locked in enough that consumers could too easily purchase the wrong device and potentially cause problems or face it simply not working.
True. The difference between the typical throughput at full utilisation and the maximum throughput at full utilisation is significant. I guess that in some very specific lab conditions (including conditions like there be no noise, no EMI, no crosstalk, etc) GigE equipment can perform sufficiently near 1Gbit/s and that outside the lab it doesn't perform as near to 1Gbit/s as it does in the lab conditions it likes. So although the absolute maximum throughput might be 1Gbit/s, in the real world it falls somewhat short of that due to non-ideal conditions.
Noise, EMI and crosstalk don't apply to fiber, but otherwise, yeah. And somewhat short still depends on the equipment and the quality of the copper cable. A user with a shoddy NIC could get 500mbit/s (this I would expect on most laptops too, because of things like hard drives and stuff being a bit slower); where a user with a great system and SSDs and super-high quality NIC could get closer to 970mbit/s. It's very very difficult to predict.
I didn't miss the point -- the data plans with 1Gbit/s speed is awesome; I was just being pedantic/nitpicking. :-/
Uh huh.
It's a bit surprising that although 10GBASE equipment has been available since 2002, 10G-PON equipment started to come out much later in 2010, 8 years after 10GBASE.
10G equipment has been around for plenty of time yes, but it has not been a last-mile technology. That first equipment, and some modern stuff is designed to work of super-short distances (a few meters, max), whereas PON last-miles have to be able to deal with distances up to 80KM. Very very different kettles of fish.
Yes, we can count too.
According to the model number naming scheme in the scribd PDF I linked to in my previous post, I-120G-P should have one POTS port, two GigE ports and no RF ports. I don't know what P signifies.
I have the definitions somewhere.
Damn lock-in. When it bites, the pain is significant.
It's not complete lock-in, it's just locked in enough that consumers could too easily purchase the wrong device and potentially cause problems or face it simply not working.
True. The difference between the typical throughput at full utilisation and the maximum throughput at full utilisation is significant. I guess that in some very specific lab conditions (including conditions like there be no noise, no EMI, no crosstalk, etc) GigE equipment can perform sufficiently near 1Gbit/s and that outside the lab it doesn't perform as near to 1Gbit/s as it does in the lab conditions it likes. So although the absolute maximum throughput might be 1Gbit/s, in the real world it falls somewhat short of that due to non-ideal conditions.
Noise, EMI and crosstalk don't apply to fiber, but otherwise, yeah. And somewhat short still depends on the equipment and the quality of the copper cable. A user with a shoddy NIC could get 500mbit/s (this I would expect on most laptops too, because of things like hard drives and stuff being a bit slower); where a user with a great system and SSDs and super-high quality NIC could get closer to 970mbit/s. It's very very difficult to predict.
I didn't miss the point -- the data plans with 1Gbit/s speed is awesome; I was just being pedantic/nitpicking. :-/
Uh huh.
It's a bit surprising that although 10GBASE equipment has been available since 2002, 10G-PON equipment started to come out much later in 2010, 8 years after 10GBASE.
10G equipment has been around for plenty of time yes, but it has not been a last-mile technology. That first equipment, and some modern stuff is designed to work of super-short distances (a few meters, max), whereas PON last-miles have to be able to deal with distances up to 80KM. Very very different kettles of fish.
It's not complete lock-in, it's just locked in enough that consumers could too easily purchase the wrong device and potentially cause problems or face it simply not working.
How do you mean? From what I have read in this forum, you are using standard G.984 GPON with I presume the recommended wavelengths (1310 nm for upstream data, 1490 nm for downstream data, 1550 nm for video). So any ONT compatible with G.984 and using the same wavelengths should work, right? At most I will have to copy from the previous ONT the SLID and the MAC address and the username/password if you're using PPPoE. Or maybe I'll have to give you the serial number of the new ONT so you can authenticate it from your side. This discussion has also tempted me to ask these questions:
1. What are you using to allocate IPs to the CPE? PPPoE? DHCPv6?
2. Can I bridge the connection so as to "dial" from my own Linux gateway?
3. Does the CPE support sending syslog messages to remote server so I can keep track of the connections and disconnections? (I mean syslog messages such as the ones in Oct 18 10:21:07 192.168.2.2 pppd[400]: rcvd [LCP EchoRep id=0xd5 magic=0x1e7ccb - Pastebin.com )
My ultimate point is, like the ADSL modems today, eventually ONTs should also become available on the open market for consumers and I should be able to plug in any compatible ONT to the ISP supplied fiber and use it for data.
10G equipment has been around for plenty of time yes, but it has not been a last-mile technology. That first equipment, and some modern stuff is designed to work of super-short distances (a few meters, max), whereas PON last-miles have to be able to deal with distances up to 80KM. Very very different kettles of fish.
Let me timeline GigE and GPON here:
1998: IEEE 802.3z (GigE on fiber) ratified
1999: IEEE 802.3ab (GigE on UTP) ratified
2003: ITU-T G.984 GPON (2.5/1.2 Gbit/s on fiber) ratified
And 10GigE and XG-PON2:
2002: IEEE 802.3ae-2002 (10GigE on fiber) ratified
2006: IEEE 802.3an-2006 (10GigE on UTP) ratified
2010: ITU-T G.987 XG-PON2 (10/10 Gbit/s on fiber) ratified
As you say, very very different kettles of fish.
BTW, do vendors provide incentives for doing field trials of new equipment considering that the first batch of equipment made to very new standards will be (i am guessing) very expensive?
How do you mean? From what I have read in this forum, you are using standard G.984 GPON with I presume the recommended wavelengths (1310 nm for upstream data, 1490 nm for downstream data, 1550 nm for video). So any ONT compatible with G.984 and using the same wavelengths should work, right? At most I will have to copy from the previous ONT the SLID and the MAC address and the username/password if you're using PPPoE. Or maybe I'll have to give you the serial number of the new ONT so you can authenticate it from your side. This discussion has also tempted me to ask these questions:
1. What are you using to allocate IPs to the CPE? PPPoE? DHCPv6?
2. Can I bridge the connection so as to "dial" from my own Linux gateway?
3. Does the CPE support sending syslog messages to remote server so I can keep track of the connections and disconnections? (I mean syslog messages such as the ones in Oct 18 10:21:07 192.168.2.2 pppd[400]: rcvd [LCP EchoRep id=0xd5 magic=0x1e7ccb - Pastebin.com )
My ultimate point is, like the ADSL modems today, eventually ONTs should also become available on the open market for consumers and I should be able to plug in any compatible ONT to the ISP supplied fiber and use it for data.
10G equipment has been around for plenty of time yes, but it has not been a last-mile technology. That first equipment, and some modern stuff is designed to work of super-short distances (a few meters, max), whereas PON last-miles have to be able to deal with distances up to 80KM. Very very different kettles of fish.
Let me timeline GigE and GPON here:
1998: IEEE 802.3z (GigE on fiber) ratified
1999: IEEE 802.3ab (GigE on UTP) ratified
2003: ITU-T G.984 GPON (2.5/1.2 Gbit/s on fiber) ratified
And 10GigE and XG-PON2:
2002: IEEE 802.3ae-2002 (10GigE on fiber) ratified
2006: IEEE 802.3an-2006 (10GigE on UTP) ratified
2010: ITU-T G.987 XG-PON2 (10/10 Gbit/s on fiber) ratified
As you say, very very different kettles of fish.
BTW, do vendors provide incentives for doing field trials of new equipment considering that the first batch of equipment made to very new standards will be (i am guessing) very expensive?
mgcarley
Founder, Hayai Broadband
How do you mean? From what I have read in this forum, you are using standard G.984 GPON with I presume the recommended wavelengths (1310 nm for upstream data, 1490 nm for downstream data, 1550 nm for video). So any ONT compatible with G.984 and using the same wavelengths should work, right? At most I will have to copy from the previous ONT the SLID and the MAC address and the username/password if you're using PPPoE. Or maybe I'll have to give you the serial number of the new ONT so you can authenticate it from your side.
Those specs are standard, however the authentication and connectivity mechanisms are not, as in, it's a software thing - some platforms play nicely with each other, some do not. The connection for each service on the CPE is dealt with separately, and is encrypted between the CPE and the OLT with a key (such as AES) which allows either 1 or multiple service providers to offer services over the same cables/hardware. Copying the MAC address and so on shouldn't work because of this and PPPoE essentially becomes unnecessary. If you were to purchase your own ONT you could give us the serial number of your unit but we still couldn't guarantee that it would work - it may cause issues on that PON tree or it may simply refuse to connect, or, if it did correct, the system may end up corrupting the device in case there are some settings unique to the service provider that it tries to update your ONT's config file on service startup and whoops, there's a setting that's not supported or the format is not supported.
In many ways this sort of thing is beneficial to both us and the customer as it allows easier provisioning, better security, better and more reliable service monitoring and a few other things even if it is at the expense of consumer choice.
This discussion has also tempted me to ask these questions:
1. What are you using to allocate IPs to the CPE? PPPoE? DHCPv6?
2. Can I bridge the connection so as to "dial" from my own Linux gateway?
3. Does the CPE support sending syslog messages to remote server so I can keep track of the connections and disconnections? (I mean syslog messages such as the ones in Oct 18 10:21:07 192.168.2.2 pppd[400]: rcvd [LCP EchoRep id=0xd5 magic=0x1e7ccb - Pastebin.com )
1. 802.1x with DHCPv6
2. Technically you could but it wouldn't be recommended. The service is designed to be "always on".
3. I'm not 100% sure. Probably it can do something like that. But as it is, the service is designed to be "always on".
My ultimate point is, like the ADSL modems today, eventually ONTs should also become available on the open market for consumers and I should be able to plug in any compatible ONT to the ISP supplied fiber and use it for data.
Probably not. GPON isn't exactly new, and it hasn't happened anywhere else.
Let me timeline GigE and GPON here:
1998: IEEE 802.3z (GigE on fiber) ratified
1999: IEEE 802.3ab (GigE on UTP) ratified
2003: ITU-T G.984 GPON (2.5/1.2 Gbit/s on fiber) ratified
And 10GigE and XG-PON2:
2002: IEEE 802.3ae-2002 (10GigE on fiber) ratified
2006: IEEE 802.3an-2006 (10GigE on UTP) ratified
2010: ITU-T G.987 XG-PON2 (10/10 Gbit/s on fiber) ratified
As you say, very very different kettles of fish.
Not even relevant to each other, really.
BTW, do vendors provide incentives for doing field trials of new equipment considering that the first batch of equipment made to very new standards will be (i am guessing) very expensive?
We've asked if Alcatel would like to use us as test monkeys in India for 10G. I don't know that there's an incentive except for that it'll be awesome for us to test 🙂
Those specs are standard, however the authentication and connectivity mechanisms are not, as in, it's a software thing - some platforms play nicely with each other, some do not. The connection for each service on the CPE is dealt with separately, and is encrypted between the CPE and the OLT with a key (such as AES) which allows either 1 or multiple service providers to offer services over the same cables/hardware. Copying the MAC address and so on shouldn't work because of this and PPPoE essentially becomes unnecessary. If you were to purchase your own ONT you could give us the serial number of your unit but we still couldn't guarantee that it would work - it may cause issues on that PON tree or it may simply refuse to connect, or, if it did correct, the system may end up corrupting the device in case there are some settings unique to the service provider that it tries to update your ONT's config file on service startup and whoops, there's a setting that's not supported or the format is not supported.
In many ways this sort of thing is beneficial to both us and the customer as it allows easier provisioning, better security, better and more reliable service monitoring and a few other things even if it is at the expense of consumer choice.
This discussion has also tempted me to ask these questions:
1. What are you using to allocate IPs to the CPE? PPPoE? DHCPv6?
2. Can I bridge the connection so as to "dial" from my own Linux gateway?
3. Does the CPE support sending syslog messages to remote server so I can keep track of the connections and disconnections? (I mean syslog messages such as the ones in Oct 18 10:21:07 192.168.2.2 pppd[400]: rcvd [LCP EchoRep id=0xd5 magic=0x1e7ccb - Pastebin.com )
1. 802.1x with DHCPv6
2. Technically you could but it wouldn't be recommended. The service is designed to be "always on".
3. I'm not 100% sure. Probably it can do something like that. But as it is, the service is designed to be "always on".
My ultimate point is, like the ADSL modems today, eventually ONTs should also become available on the open market for consumers and I should be able to plug in any compatible ONT to the ISP supplied fiber and use it for data.
Probably not. GPON isn't exactly new, and it hasn't happened anywhere else.
Let me timeline GigE and GPON here:
1998: IEEE 802.3z (GigE on fiber) ratified
1999: IEEE 802.3ab (GigE on UTP) ratified
2003: ITU-T G.984 GPON (2.5/1.2 Gbit/s on fiber) ratified
And 10GigE and XG-PON2:
2002: IEEE 802.3ae-2002 (10GigE on fiber) ratified
2006: IEEE 802.3an-2006 (10GigE on UTP) ratified
2010: ITU-T G.987 XG-PON2 (10/10 Gbit/s on fiber) ratified
As you say, very very different kettles of fish.
Not even relevant to each other, really.
BTW, do vendors provide incentives for doing field trials of new equipment considering that the first batch of equipment made to very new standards will be (i am guessing) very expensive?
We've asked if Alcatel would like to use us as test monkeys in India for 10G. I don't know that there's an incentive except for that it'll be awesome for us to test 🙂
Those specs are standard, however the authentication and connectivity mechanisms are not, as in, it's a software thing - some platforms play nicely with each other, some do not. The connection for each service on the CPE is dealt with separately, and is encrypted between the CPE and the OLT with a key (such as AES) which allows either 1 or multiple service providers to offer services over the same cables/hardware. Copying the MAC address and so on shouldn't work because of this and PPPoE essentially becomes unnecessary. If you were to purchase your own ONT you could give us the serial number of your unit but we still couldn't guarantee that it would work - it may cause issues on that PON tree or it may simply refuse to connect, or, if it did correct, the system may end up corrupting the device in case there are some settings unique to the service provider that it tries to update your ONT's config file on service startup and whoops, there's a setting that's not supported or the format is not supported.
I don't want a guarantee from you; I just like to have a reasonable expectation that any other GPON CPE should work.
If a data type format or setting is not supported, shouldn't the CPE just ignore that bit from the config file instead of corrupting itself? 😀 That's, well, common sense. If the config file format itself isn't supported, the CPE should refuse to update itself with that config file. I suppose the CPE stores all the config variables in the NVRAM, and the CPE can easily reset the NVRAM at startup if the bootloader is intelligent enough. That's a big if though.
In many ways this sort of thing is beneficial to both us and the customer as it allows easier provisioning, better security, better and more reliable service monitoring and a few other things even if it is at the expense of consumer choice.
On the other hand, it allows Alcatel to artificially inflate prices just for you when it's time to buy some more CPEs and only Alcatel CPEs will work. Alcatel can then easily dictate their own prices. At that point, you can threaten to switch to Motorola completely but there's nothing stopping Motorola from inflating prices either after a while.
1. 802.1x with DHCPv6
Great. No PPPoE!
2. Technically you could but it wouldn't be recommended. The service is designed to be "always on".
Great. Even if it is not recommended, I like having the flexibility and playing with networks.
3. I'm not 100% sure. Probably it can do something like that. But as it is, the service is designed to be "always on".
Well, it doesn't seem to be running Linux; that reduces the chances of it having remote syslog.
Probably not. GPON isn't exactly new, and it hasn't happened anywhere else.
While GPON itself isn't new, the number of GPON deployments (to the home) are far fewer than the number of ADSL deployments.
I don't want a guarantee from you; I just like to have a reasonable expectation that any other GPON CPE should work.
If a data type format or setting is not supported, shouldn't the CPE just ignore that bit from the config file instead of corrupting itself? 😀 That's, well, common sense. If the config file format itself isn't supported, the CPE should refuse to update itself with that config file. I suppose the CPE stores all the config variables in the NVRAM, and the CPE can easily reset the NVRAM at startup if the bootloader is intelligent enough. That's a big if though.
In many ways this sort of thing is beneficial to both us and the customer as it allows easier provisioning, better security, better and more reliable service monitoring and a few other things even if it is at the expense of consumer choice.
On the other hand, it allows Alcatel to artificially inflate prices just for you when it's time to buy some more CPEs and only Alcatel CPEs will work. Alcatel can then easily dictate their own prices. At that point, you can threaten to switch to Motorola completely but there's nothing stopping Motorola from inflating prices either after a while.
1. 802.1x with DHCPv6
Great. No PPPoE!
2. Technically you could but it wouldn't be recommended. The service is designed to be "always on".
Great. Even if it is not recommended, I like having the flexibility and playing with networks.
3. I'm not 100% sure. Probably it can do something like that. But as it is, the service is designed to be "always on".
Well, it doesn't seem to be running Linux; that reduces the chances of it having remote syslog.
Probably not. GPON isn't exactly new, and it hasn't happened anywhere else.
While GPON itself isn't new, the number of GPON deployments (to the home) are far fewer than the number of ADSL deployments.
mgcarley
Founder, Hayai Broadband
I don't want a guarantee from you; I just like to have a reasonable expectation that any other GPON CPE should work.
It's hit or miss and unfortunately, not a reasonable expectation. It's not just with us, it's with any provider anywhere in the world.
Either it will work or it won't, and if it doesn't, it may end up screwing things up for others. If it does work, it's at your own risk, and no support would be provided. Even if you were able to buy a CPE, we would have to ensure that it was compatible with our OLT before allowing you to plug it in.
If a data type format or setting is not supported, shouldn't the CPE just ignore that bit from the config file instead of corrupting itself? 😀 That's, well, common sense. If the config file format itself isn't supported, the CPE should refuse to update itself with that config file. I suppose the CPE stores all the config variables in the NVRAM, and the CPE can easily reset the NVRAM at startup if the bootloader is intelligent enough. That's a big if though.
It probably would ignore that, but in that event it would simply fail to work when plugged in to our network - if it can't talk to the OLT there's not much you can do.
On the other hand, it allows Alcatel to artificially inflate prices just for you when it's time to buy some more CPEs and only Alcatel CPEs will work. Alcatel can then easily dictate their own prices. At that point, you can threaten to switch to Motorola completely but there's nothing stopping Motorola from inflating prices either after a while.
Alcatel's price per subscriber for Gigabit-capable equipment was less than the price per subscriber for Fast-Ethernet-capable equipment from UTStarCom. 'nuff said?
Great. No PPPoE!
Yay.
Great. Even if it is not recommended, I like having the flexibility and playing with networks.
In order to dial, would you not need us to provision you with PPPoE?
Well, it doesn't seem to be running Linux; that reduces the chances of it having remote syslog.
The Motorola devices are based on F/OSS (or so they claim). As I recall, you can either log in to the CPE remotely, but I would have to check if it can upload something to somewhere when it reconnects.
While GPON itself isn't new, the number of GPON deployments (to the home) are far fewer than the number of ADSL deployments.
That's beside the point, really. With copper-based media, you can twist the cables together and expect it to get a signal of some kind. Even with ADSL, you still get cases where mixing and matching causes problems and some manufacturers DSL modems work better on the same line than another. I've seen cases where there might be a choice of say, a Nortel DSLAM and a Lucent DSLAM in the same cabinet, and one manufacturers device will be very problematic when terminated on the Nortel one but fantastic when terminated on the Lucent one (or vice versa).
With fiber, the possibility of mixing and matching just isn't the same, and even in markets with significant established FTTH networks the CPEs are not readily available on the open market. Sometimes you might see them being sold on eBay and such but usually as replacement devices for the customers on the same network. Otherwise, if you want to buy FTTH CPEs, you have to buy them in large quantities and in reality, the only ones inclined to do that are the ISP with the FTTH network.
As mentioned before, this does have it's pros and cons, but from the service provider's perspective, I feel the pros outweigh the cons, and at best I think we could offer a selection of CPEs from a few different manufacturers if and when we come to know that they operate on the network correctly.
It's hit or miss and unfortunately, not a reasonable expectation. It's not just with us, it's with any provider anywhere in the world.
Either it will work or it won't, and if it doesn't, it may end up screwing things up for others. If it does work, it's at your own risk, and no support would be provided. Even if you were able to buy a CPE, we would have to ensure that it was compatible with our OLT before allowing you to plug it in.
If a data type format or setting is not supported, shouldn't the CPE just ignore that bit from the config file instead of corrupting itself? 😀 That's, well, common sense. If the config file format itself isn't supported, the CPE should refuse to update itself with that config file. I suppose the CPE stores all the config variables in the NVRAM, and the CPE can easily reset the NVRAM at startup if the bootloader is intelligent enough. That's a big if though.
It probably would ignore that, but in that event it would simply fail to work when plugged in to our network - if it can't talk to the OLT there's not much you can do.
On the other hand, it allows Alcatel to artificially inflate prices just for you when it's time to buy some more CPEs and only Alcatel CPEs will work. Alcatel can then easily dictate their own prices. At that point, you can threaten to switch to Motorola completely but there's nothing stopping Motorola from inflating prices either after a while.
Alcatel's price per subscriber for Gigabit-capable equipment was less than the price per subscriber for Fast-Ethernet-capable equipment from UTStarCom. 'nuff said?
Great. No PPPoE!
Yay.
Great. Even if it is not recommended, I like having the flexibility and playing with networks.
In order to dial, would you not need us to provision you with PPPoE?
Well, it doesn't seem to be running Linux; that reduces the chances of it having remote syslog.
The Motorola devices are based on F/OSS (or so they claim). As I recall, you can either log in to the CPE remotely, but I would have to check if it can upload something to somewhere when it reconnects.
While GPON itself isn't new, the number of GPON deployments (to the home) are far fewer than the number of ADSL deployments.
That's beside the point, really. With copper-based media, you can twist the cables together and expect it to get a signal of some kind. Even with ADSL, you still get cases where mixing and matching causes problems and some manufacturers DSL modems work better on the same line than another. I've seen cases where there might be a choice of say, a Nortel DSLAM and a Lucent DSLAM in the same cabinet, and one manufacturers device will be very problematic when terminated on the Nortel one but fantastic when terminated on the Lucent one (or vice versa).
With fiber, the possibility of mixing and matching just isn't the same, and even in markets with significant established FTTH networks the CPEs are not readily available on the open market. Sometimes you might see them being sold on eBay and such but usually as replacement devices for the customers on the same network. Otherwise, if you want to buy FTTH CPEs, you have to buy them in large quantities and in reality, the only ones inclined to do that are the ISP with the FTTH network.
As mentioned before, this does have it's pros and cons, but from the service provider's perspective, I feel the pros outweigh the cons, and at best I think we could offer a selection of CPEs from a few different manufacturers if and when we come to know that they operate on the network correctly.
It's hit or miss and unfortunately, not a reasonable expectation. It's not just with us, it's with any provider anywhere in the world.
Either it will work or it won't, and if it doesn't, it may end up screwing things up for others. If it does work, it's at your own risk, and no support would be provided. Even if you were able to buy a CPE, we would have to ensure that it was compatible with our OLT before allowing you to plug it in.
It probably would ignore that, but in that event it would simply fail to work when plugged in to our network - if it can't talk to the OLT there's not much you can do.
I thought the point of standards was to ensure interoperability between various devices. The GPON standard and other standards related to FTTH seem to have fallen short of that here.
In order to dial, would you not need us to provision you with PPPoE?
I guess if I bridge the fiber Internet VLAN with the LAN interface in the CPE and then send DHCPv6 requests from the gateway in the LAN, it should work. I am not at all sure because I've no hands-on experience with fiber. I am very tempted to get some hands on experience with IPv6 and fiber; it would suck if I don't get a hayai connection for at least a few weeks before I leave Pune. Sometimes I wanted to try IPv6 in my LAN with tunneling etc but there's no sense in that if there is no IPv6 connectivity from upstream.
The Motorola devices are based on F/OSS (or so they claim). As I recall, you can either log in to the CPE remotely, but I would have to check if it can upload something to somewhere when it reconnects.
I searched for a few Motorola CPE model numbers (taken from Motorola phones and accessories - Motorola, Inc. USA ) along with linux or open source and didn't get any good results. That indicates that Motorola hasn't posted the source code of these CPEs publicly so well maybe they only send the source code to customers. 😛
If the GPON CPEs and OLTs were all F/OSS and didn't have locked in bootloaders, compatibility issues might have been resolved by quite a good extent. 🙂
With fiber, the possibility of mixing and matching just isn't the same, and even in markets with significant established FTTH networks the CPEs are not readily available on the open market. Sometimes you might see them being sold on eBay and such but usually as replacement devices for the customers on the same network. Otherwise, if you want to buy FTTH CPEs, you have to buy them in large quantities and in reality, the only ones inclined to do that are the ISP with the FTTH network.
I guess this is because FTTH devices are not very interoperable.
As mentioned before, this does have it's pros and cons, but from the service provider's perspective, I feel the pros outweigh the cons, and at best I think we could offer a selection of CPEs from a few different manufacturers if and when we come to know that they operate on the network correctly.
Okay.
Either it will work or it won't, and if it doesn't, it may end up screwing things up for others. If it does work, it's at your own risk, and no support would be provided. Even if you were able to buy a CPE, we would have to ensure that it was compatible with our OLT before allowing you to plug it in.
It probably would ignore that, but in that event it would simply fail to work when plugged in to our network - if it can't talk to the OLT there's not much you can do.
I thought the point of standards was to ensure interoperability between various devices. The GPON standard and other standards related to FTTH seem to have fallen short of that here.
In order to dial, would you not need us to provision you with PPPoE?
I guess if I bridge the fiber Internet VLAN with the LAN interface in the CPE and then send DHCPv6 requests from the gateway in the LAN, it should work. I am not at all sure because I've no hands-on experience with fiber. I am very tempted to get some hands on experience with IPv6 and fiber; it would suck if I don't get a hayai connection for at least a few weeks before I leave Pune. Sometimes I wanted to try IPv6 in my LAN with tunneling etc but there's no sense in that if there is no IPv6 connectivity from upstream.
The Motorola devices are based on F/OSS (or so they claim). As I recall, you can either log in to the CPE remotely, but I would have to check if it can upload something to somewhere when it reconnects.
I searched for a few Motorola CPE model numbers (taken from Motorola phones and accessories - Motorola, Inc. USA ) along with linux or open source and didn't get any good results. That indicates that Motorola hasn't posted the source code of these CPEs publicly so well maybe they only send the source code to customers. 😛
If the GPON CPEs and OLTs were all F/OSS and didn't have locked in bootloaders, compatibility issues might have been resolved by quite a good extent. 🙂
With fiber, the possibility of mixing and matching just isn't the same, and even in markets with significant established FTTH networks the CPEs are not readily available on the open market. Sometimes you might see them being sold on eBay and such but usually as replacement devices for the customers on the same network. Otherwise, if you want to buy FTTH CPEs, you have to buy them in large quantities and in reality, the only ones inclined to do that are the ISP with the FTTH network.
I guess this is because FTTH devices are not very interoperable.
As mentioned before, this does have it's pros and cons, but from the service provider's perspective, I feel the pros outweigh the cons, and at best I think we could offer a selection of CPEs from a few different manufacturers if and when we come to know that they operate on the network correctly.
Okay.
mgcarley
Founder, Hayai Broadband
I thought the point of standards was to ensure interoperability between various devices. The GPON standard and other standards related to FTTH seem to have fallen short of that here.
The GPON standard is fixed and that is not the issue. The issue is more along the lines of authentication and security, which is not really part of any standard.
I guess if I bridge the fiber Internet VLAN with the LAN interface in the CPE and then send DHCPv6 requests from the gateway in the LAN, it should work. I am not at all sure because I've no hands-on experience with fiber. I am very tempted to get some hands on experience with IPv6 and fiber; it would suck if I don't get a hayai connection for at least a few weeks before I leave Pune. Sometimes I wanted to try IPv6 in my LAN with tunneling etc but there's no sense in that if there is no IPv6 connectivity from upstream.
I'm reasonably certain you can do that. IPv6 is online and working right now - Test your IPv6. shows that I do indeed have a public IPv6 address
Your IPv6 address on the public Internet appears to be 2002:cb73:46ba:4:b957:ea47:1f08:9749World IPv6 day is June 8th, 2011. No problems are anticipated for you with this browser, at this location.Congratulations! You appear to have both IPv4 and IPv6 Internet working. If a publisher publishes to IPv6, your browser will connect using IPv6.
I searched for a few Motorola CPE model numbers (taken from Motorola phones and accessories - Motorola, Inc. USA ) along with linux or open source and didn't get any good results. That indicates that Motorola hasn't posted the source code of these CPEs publicly so well maybe they only send the source code to customers. 😛
I guess it depends on the license of whatever code they're using as to what/how much is shared and with who.
If the GPON CPEs and OLTs were all F/OSS and didn't have locked in bootloaders, compatibility issues might have been resolved by quite a good extent. 🙂
Maybe.
I guess this is because FTTH devices are not very interoperable.
I would say it has more to do with control of the network. As I alluded to in a previous post, it's very beneficial for the service provider to own and control the equipment and allows for much more flexibility on our side for doing all sorts of wonderful things and significantly better diagnostics.
The GPON standard is fixed and that is not the issue. The issue is more along the lines of authentication and security, which is not really part of any standard.
I guess if I bridge the fiber Internet VLAN with the LAN interface in the CPE and then send DHCPv6 requests from the gateway in the LAN, it should work. I am not at all sure because I've no hands-on experience with fiber. I am very tempted to get some hands on experience with IPv6 and fiber; it would suck if I don't get a hayai connection for at least a few weeks before I leave Pune. Sometimes I wanted to try IPv6 in my LAN with tunneling etc but there's no sense in that if there is no IPv6 connectivity from upstream.
I'm reasonably certain you can do that. IPv6 is online and working right now - Test your IPv6. shows that I do indeed have a public IPv6 address
Your IPv6 address on the public Internet appears to be 2002:cb73:46ba:4:b957:ea47:1f08:9749World IPv6 day is June 8th, 2011. No problems are anticipated for you with this browser, at this location.Congratulations! You appear to have both IPv4 and IPv6 Internet working. If a publisher publishes to IPv6, your browser will connect using IPv6.
I searched for a few Motorola CPE model numbers (taken from Motorola phones and accessories - Motorola, Inc. USA ) along with linux or open source and didn't get any good results. That indicates that Motorola hasn't posted the source code of these CPEs publicly so well maybe they only send the source code to customers. 😛
I guess it depends on the license of whatever code they're using as to what/how much is shared and with who.
If the GPON CPEs and OLTs were all F/OSS and didn't have locked in bootloaders, compatibility issues might have been resolved by quite a good extent. 🙂
Maybe.
I guess this is because FTTH devices are not very interoperable.
I would say it has more to do with control of the network. As I alluded to in a previous post, it's very beneficial for the service provider to own and control the equipment and allows for much more flexibility on our side for doing all sorts of wonderful things and significantly better diagnostics.
- Status