Subject: Re: [ANCP] IETF 69 ANCP meeting minutes

From: Lloyd Wood <[email-masked]>
Date: Fri, 10 Aug 2007 20:07:32 +0100

I've archived a copy of the slides and draft for extending ANCP at:
http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/internet-drafts/draft-floreani-ancp-wireless/

ANCP could be one way to communicate a modem's varying speed to the router a hop along via simple information reports, but, given that this applies ANCP outside of its trusted headend domain, there are probably a lot of (unfounded?) security concerns about crossing the divide of ownership

I suppose that the problem of communicating varying link speeds to a connected upstream/downstream router needs to be solved for DSL in general somehow by the DSL forum -- and then that method, whatever it is, could then be generalised beyond DSL to work for other modem technologies. It's certainly not a problem central to ANCP or this workgroup.

cheers,

L.

[..]
>15 mins - Extension of ANCP for Satellite and Terrestrial Wireless Modem
>Networks - Lloyd Wood ([email-masked])
>http://www.ietf.org/internet-drafts/draft-floreani-ancp-wireless-00.txt 
>
>Been dealing with problem with which ANCP can help
>Smart adaptive modems need to update routers with current satellite
>modem speed. Similar to DSL.
>
>Looking at adding wireless class extension to ANCP.
>
>Point-multipoint and point-point cases. Eventually moving to point to
>point.
>
>Use ethernet between modem and router because of cost. Serial would be
>best option, but not going to happen.
>
>ANCP works across TCP. Given that satellite delay is an issue, doing
>ANCP local looks like the answer.
>
>Multicast CAC use-case also of interest to satellite.
>
>Interested in comments and whether this is something for ANCP.
>
>Francois : Seems to match what ANCP does.  But isn't it overkill to use
>GSMP based protocol just to sync line rate?
>
>Lloyd : This may be overkill, but we have working code and it will work.
>Just software. However a lot of framework is not used. But in deployment
>scenarios the fuller framework may get used to cover other access types.
>
>Sanjay: ANCP between NAS and modem - ok. But ANCP between CPE and modem
>raises questions. Is CPE trusted device? ANCP is typically contained to
>trusted domain
>
>Discussion on managed CPE options. Are CPE and NAS operated by different
>companies.
>
>Lloyd: Depends on provider. 50/50 case in satellite industry; some
>provide router+modem, others only modem.
>
>Lloyd: Modems turning to L3 device, part of the problem. Is ANCP
>suitable.
>
>Woj: Do you have specific issues with the protocol spec for satellite
>use?
>
>Lloyd: ANCP is an overkill, but it has all we need. Fine for our use.
>
>More discussion on CPE side aspect of modem and router.
>In DSL case there appears to be the same problem on the home side,
>between router and modem. Problem seems to be applicable to DSL too.
>
>Woj: So far we focused on the service provider side, not the home. Home
>is an un-explored area for us.
>
>Wojciech : Broader question is how do we ensure extensibility of ANCP to
>other technologies?  Current text protocol spec to be very DSL tech type
>centric. Need to decouple function from tech type so that it can be
>re-used by other tech types.
>Also need to define extensibility path for TLVs.
>
>Sanjay: For each tech type do we need enumerate the TLVs?
>
>Woj: No.
>
>Usual search for blue sheets...

_______________________________________________
ANCP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ancp