From ancp-bounces@ietf.org Fri Jun 15 08:48:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzBDg-0000lc-IP; Fri, 15 Jun 2007 08:48:04 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1HzBDf-0000io-3F for ancp-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 08:48:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzBDe-0000ia-PY for ancp@ietf.org; Fri, 15 Jun 2007 08:48:02 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzBDd-0000mv-BY for ancp@ietf.org; Fri, 15 Jun 2007 08:48:02 -0400 Received: from gbmail02.netfr.alcatel.fr (gbmail02.netfr.alcatel.fr [155.132.251.26]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l5FCm3rS020497 for ; Fri, 15 Jun 2007 14:48:03 +0200 To: ancp@ietf.org X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Matthew.Bocci@alcatel-lucent.co.uk Date: Fri, 15 Jun 2007 13:46:55 +0100 X-MIMETrack: Serialize by Router on GBMAIL02/GB/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 06/15/2007 13:47:58 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [ANCP] Call for Slots in Chicago X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org We have a 2 hour session for ANCP on Tuesday, July 24th at 1pm. Please can you let me know, by Friday 10th July, if you would like a slot. As usual, please let me know the relevant draft (if any), a summary of what you want to talk about, and the time you require. Best regards, Matthew ----------------------------------------- Matthew Bocci IP Division, Alcatel-Lucent Telecom Limited, Registered Office: Christchurch Way, Greenwich, London SE10 0AG. Registered in England & Wales number 02650571 ----------------------------------------- _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Mon Jun 18 14:57:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0MPM-0006kv-04; Mon, 18 Jun 2007 14:57:00 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1I0MPK-0006kh-10 for ancp-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 14:56:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0MPJ-0006kQ-Mq for ancp@ietf.org; Mon, 18 Jun 2007 14:56:57 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0MPI-0000zd-Bo for ancp@ietf.org; Mon, 18 Jun 2007 14:56:57 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 18 Jun 2007 20:56:56 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5IIutVS024242; Mon, 18 Jun 2007 20:56:55 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5IIupDR023094; Mon, 18 Jun 2007 18:56:51 GMT Received: from lwood-wxp01.cisco.com (ams3-vpn-dhcp4.cisco.com [10.61.64.4]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id TAA26564; Mon, 18 Jun 2007 19:56:50 +0100 (BST) Message-Id: <200706181856.TAA26564@cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 18 Jun 2007 19:56:18 +0100 To: ancp@ietf.org From: Lloyd Wood Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Authentication-Results: ams-dkim-1; header.From=L.Wood@surrey.ac.uk; dkim=neutral X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: danielf@cisco.com Subject: [ANCP] ANCP use for smart adaptive modems? X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org We have been looking at the problem of routers talking to smart adaptive wireless modems - modems that can vary their output from say 16kbps to 512kbps, or 1-6Mbps, depending on channel conditions. These modems often have ethernet ports, because ethernet is cheap, and they're connected to a router the next hop along. (There are hundreds of custom modems, so they're not built into the router directly.) But you need to rate-limit and set QoS on the router's Ethernet interface to match the modem output - and when the modem rate varies, your static QoS config is rendered useless. You can't usefully let 100Mbps go over Ethernet to the modem. So, we would need a way for the modem to signal that its output/input wireless speeds have changed, so that the router dynamically updates its QoS/rate-limiting configuration to match. So, could ANCP communication over Ethernet between modem and router be one way to solve this? is there any wider interest in using ANCP in this way, generalising from the managed DSL space? thanks, L. _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Tue Jun 19 10:36:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0eoT-0008GL-Ae; Tue, 19 Jun 2007 10:36:09 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1I0eoR-0008G7-Gw for ancp-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 10:36:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0eoQ-0008Fz-LY for ancp@ietf.org; Tue, 19 Jun 2007 10:36:07 -0400 Received: from smail5.alcatel.fr ([64.208.49.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0eoO-0002Pl-63 for ancp@ietf.org; Tue, 19 Jun 2007 10:36:06 -0400 Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.ad2.ad.alcatel.com [155.132.6.77]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l5JEYCwX021110; Tue, 19 Jun 2007 16:34:27 +0200 Received: from [172.31.131.236] ([172.31.131.236]) by FRVELSBHS05.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Tue, 19 Jun 2007 16:35:52 +0200 Message-ID: <4677E9C8.7070601@alcatel-lucent.be> Date: Tue, 19 Jun 2007 16:35:52 +0200 From: Stefaan DE CNODDER User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bwijnen@alcatel-lucent.com Subject: Re: [ANCP] ANCP MIB and Partition-ID Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jun 2007 14:35:52.0805 (UTC) FILETIME=[23696950:01C7B27F] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Hi Bert, For this very late reply on the mail below. An ANCP session is managing all the access lines that belongs to a particular partition. Therefore partitioning is just a grouping of DSL lines and 1 SNMP agent is managing all the partitions. So there is only need to have 1 instance of the MIB in an access node. regards, Stefaan To: Subject: [ANCP] ANCP MIB and Partition-ID From: "Wijnen, Bert \(Bert\)" Date: Tue, 20 Mar 2007 14:43:58 +0100 In-reply-to: <45F7B3CD.5070806@alcatel-lucent.be> List-archive: List-help: List-id: Access Node Control Protocol working group mailing list List-post: List-subscribe: , List-unsubscribe: , References: <45F7B3CD.5070806@alcatel-lucent.be> Thread-index: AcdmE/T2YouUQo/YQNOxQssnPj/0ZQE4S0xA Thread-topic: ANCP MIB and Partition-ID -------------------------------------------------------------------------------- During the ANCP session today I listened to the discussion about PartionID and the question if it is more than just a number. There was talk about that possibly they could be multiple partitions in the same device, maybe even virtual partitions? That triggered me to wonder - will multiple partitions on the same device be supported (repersented) by a single SNMP agent or by multiple SNMP agents? - If so, do we need to consider that the particionID becomes part of the indexing scheme, so that you implicitly support multiple instances of this MIB module The WG better thinks this through BEFORE the MIB module gets finalized, because if we find out later (afte rthe MIB document has been approved), then it can only be changed with incompatible changes (i.e. re-indexing), and so that means obsoleting most (if not all) of what we define today. Bert _______________________________________________ ANCP mailing list ANCP at ietf.org https://www1.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Wed Jun 20 10:57:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I11cz-0000II-O8; Wed, 20 Jun 2007 10:57:49 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1I11cy-0000Gk-Ma for ancp-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 10:57:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I11cy-0000Gc-D7 for ancp@ietf.org; Wed, 20 Jun 2007 10:57:48 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I11cv-0003Ye-Hj for ancp@ietf.org; Wed, 20 Jun 2007 10:57:48 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 20 Jun 2007 16:57:43 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5KEvgFT019535; Wed, 20 Jun 2007 16:57:42 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5KEvcDR008785; Wed, 20 Jun 2007 14:57:42 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 16:57:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ANCP] ANCP use for smart adaptive modems? Date: Wed, 20 Jun 2007 16:57:33 +0200 Message-ID: In-Reply-To: <200706181856.TAA26564@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP use for smart adaptive modems? Thread-Index: Acex2n5tsUCVPaKySxSITrDVBR127ABbuezQ From: "Wojciech Dec \(wdec\)" To: "Lloyd Wood" , X-OriginalArrivalTime: 20 Jun 2007 14:57:38.0469 (UTC) FILETIME=[580FAD50:01C7B34B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2123; t=1182351462; x=1183215462; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20\(wdec\)=22=20 |Subject:=20RE=3A=20[ANCP]=20ANCP=20use=20for=20smart=20adaptive=20modems ? |Sender:=20; bh=xUPFp1LLVLYOjnHi2yBlnFMJ83KmNUfNPBbIv9gBELo=; b=IbAvNIiiV/NrKdpwyCEt+upbrJOplDaFBSf0UCz0kJbTzkFsj+AaQXYeox3o6DTEXQLMyXsy BEe/YolI97gAmBhzBAQvxvPLjs1dmCY7hGy8h8puD319JNFoMYzZxgEm; Authentication-Results: ams-dkim-1; header.From=wdec@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: "Daniel Floreani \(danielf\)" X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Hi Lloyd, Your application would seem to fit in nicely with the modem train rate reporting functionality already defined in ANCP. Would be interesting to know whether the smart adaptive wireless modem application would require additional info to what's define in the protocol spec so far. While the WG has been focusing on DSL service providers as the primary adopters of ANCP, it would seem reasonable for the WG to look into a generic extensibility scheme for the protocol.=20 Regards, Woj. > -----Original Message----- > From: Lloyd Wood [mailto:L.Wood@surrey.ac.uk]=20 > Sent: 18 June 2007 20:56 > To: ancp@ietf.org > Cc: Daniel Floreani (danielf) > Subject: [ANCP] ANCP use for smart adaptive modems? >=20 > We have been looking at the problem of routers talking to=20 > smart adaptive wireless modems - modems that can vary their=20 > output from say 16kbps to 512kbps, or 1-6Mbps, depending on=20 > channel conditions. These modems often have ethernet ports,=20 > because ethernet is cheap, and they're connected to a router=20 > the next hop along. (There are hundreds of custom modems, so=20 > they're not built into the router directly.) But you need to=20 > rate-limit and set QoS on the router's Ethernet interface to=20 > match the modem output - and when the modem rate varies, your=20 > static QoS config is rendered useless. You can't usefully let=20 > 100Mbps go over Ethernet to the modem. >=20 > So, we would need a way for the modem to signal that its=20 > output/input wireless speeds have changed, so that the router=20 > dynamically updates its QoS/rate-limiting configuration to match. >=20 > So, could ANCP communication over Ethernet between modem and=20 > router be one way to solve this? is there any wider interest=20 > in using ANCP in this way, generalising from the managed DSL space? >=20 > thanks, >=20 > L. >=20 > =20 >=20 >=20 > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www1.ietf.org/mailman/listinfo/ancp >=20 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Wed Jun 20 15:32:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I15uS-0002Oa-3m; Wed, 20 Jun 2007 15:32:08 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1I15uQ-0002OV-O9 for ancp-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 15:32:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I15uQ-0002ON-Eh for ancp@ietf.org; Wed, 20 Jun 2007 15:32:06 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I15uP-0003Jw-1V for ancp@ietf.org; Wed, 20 Jun 2007 15:32:06 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 20 Jun 2007 21:32:05 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5KJW41F004374; Wed, 20 Jun 2007 21:32:04 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5KJW3DR008986; Wed, 20 Jun 2007 19:32:03 GMT Received: from lwood-wxp01.cisco.com (che-vpn-cluster-1-141.cisco.com [10.86.240.141]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id UAA24406; Wed, 20 Jun 2007 20:32:01 +0100 (BST) Message-Id: <200706201932.UAA24406@cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 20 Jun 2007 20:31:29 +0100 To: ancp@ietf.org From: Lloyd Wood Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Authentication-Results: ams-dkim-2; header.From=L.Wood@surrey.ac.uk; dkim=neutral X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: danielf@cisco.com Subject: [ANCP] Why does ANCP use GSMP? X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org How does ANCP work? What is the plumbing, and how are messages communicated? I understand that ANCP depends on GSMPv3, though you have to dig pretty deep into the protocol specification to discover this fact. (I find it interesting that the framework document skips nicely over the whole GSMP dependency, and that the only reason given in the charter for using GSMP is that early implementations in this space use it.) Current specification of ANCP seems to be all high-level stuff; how the plumbing actually works is glossed over with a handwave, and there's a long trail of document dependencies. Though ANCP depends on GSMP, it's stated in http://www.ietf.org/internet-drafts/draft-ietf-ancp-protocol-00.txt (which, btw, is filled with "smart quotes" _ I see a lot of questionmarks, which is appropriate) that only TCP is used for ANCP. A detailed example of a message exchange or two would be useful to see to grok how the protocol is intended to work. I don't see how ANCP can both be an extension to an existing protocol, and yet also try to restrict how that existing protocol is used. This is called 'having your cake and eating it'. Given that GSMP was ATM-only before version 3, and that ANCP is only using version 3 and only running IP, while ATM remains the core of GSMP -- why is ANCP using GSMP at all? It seems like an unnatural fit, rather than a logical extension of GSMP. (And overloading TCP's RST/ACK for ANCP's purposes when there's a capability mismatch - seriously? Communicating _how_ there's a mismatch would be more useful. If that's the only way you can communicate this in GSMP, GSMP is obviously the wrong thing to use.) The framework document discusses ATM a _lot_, which makes ANCP's TCP-only protocol restriction on GSMP more curious. Is GSMP the right choice to base ANCP on? Is TCP even the right choice for small messages, or is it overkill? If ANCP is leveraging the GSMP framework, ANCP is leveraging everything that GSMP comes with, including over-ATM, over Ethernet, over-TCP. Is that baggage desirable? (I'm playing devil's advocate here, as requested by Woj in his capacity as wg chair. We have a problem I described previously that we thought ANCP could be adapted to be a solution for - but adapting the entire complexity of GSMP to solve a point problem strikes me as increasingly wrong even for ANCP itself, given how ANCP is using GSMP. So the solution to our problem would be an extension of ANCP, which is an extension of GSMP, but only in some preferred ways?) Why is GSMP use a good idea for ANCP? thanks, L. _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Wed Jun 20 15:33:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I15vt-0002rm-Jy; Wed, 20 Jun 2007 15:33:37 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1I15vs-0002rh-Bv for ancp-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 15:33:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I15vs-0002rZ-2T for ancp@ietf.org; Wed, 20 Jun 2007 15:33:36 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I15vr-0003Yb-NL for ancp@ietf.org; Wed, 20 Jun 2007 15:33:36 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 20 Jun 2007 21:33:36 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5KJXZLu004538; Wed, 20 Jun 2007 21:33:35 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5KJXYDR009145; Wed, 20 Jun 2007 19:33:34 GMT Received: from lwood-wxp01.cisco.com (che-vpn-cluster-1-141.cisco.com [10.86.240.141]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id UAA24609; Wed, 20 Jun 2007 20:33:32 +0100 (BST) Message-Id: <200706201933.UAA24609@cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 20 Jun 2007 20:30:41 +0100 To: ancp@ietf.org From: Lloyd Wood Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Authentication-Results: ams-dkim-2; header.From=L.Wood@surrey.ac.uk; dkim=neutral X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: danielf@cisco.com Subject: [ANCP] Why does ANCP use GSMP? X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org How does ANCP work? What is the plumbing, and how are messages communicated? I understand that ANCP depends on GSMPv3, though you have to dig pretty deep into the protocol specification to discover this fact. (I find it interesting that the framework document skips nicely over the whole GSMP dependency, and that the only reason given in the charter for using GSMP is that early implementations in this space use it.) Current specification of ANCP seems to be all high-level stuff; how the plumbing actually works is glossed over with a handwave, and there's a long trail of document dependencies. Though ANCP depends on GSMP, it's stated in http://www.ietf.org/internet-drafts/draft-ietf-ancp-protocol-00.txt (which, btw, is filled with "smart quotes" _ I see a lot of questionmarks, which is appropriate.) that only TCP is used for ANCP. A detailed example of a message exchange or two would be useful to see. I don't see how ANCP can both be an extension to an existing protocol, and yet also try to restrict how that existing protocol is used. This is called 'having your cake and eating it'. Given that GSMP was ATM-only before version 3, and that ANCP is only using version 3 and only running IP, while ATM remains the core of GSMP -- why is ANCP using GSMP at all? It seems like an unnatural fit, rather than a logical extension of GSMP. (And overloading TCP's RST/ACK for ANCP's purposes when there's a capability mismatch - seriously? Communicating how there's a mismatch would be more useful. If that's the only way you can communicate this in GSMP, GSMP would be the wrong thing to use.) The framework document discusses ATM a _lot_, which makes ANCP's TCP-only protocol restriction on GSMP more curious. Is GSMP the right choice to base ANCP on? Is TCP even the right choice for small messages, or is it overkill? If ANCP is leveraging the GSMP framework, ANCP is leveraging everything that GSMP comes with, including over-ATM, over Ethernet, over-TCP. Is that baggage desirable? (I'm playing devil's advocate here, as requested by Woj in his capacity as wg chair. We have a problem I described previously that we thought ANCP could be adapted to be a solution for - but adapting the entire complexity of GSMP to solve a point problem strikes me as increasingly wrong even for ANCP itself, given how ANCP is using GSMP. So the solution to our problem would be an extension of ANCP, which is an extension of GSMP, but only in some preferred ways?) Why is GSMP use a good idea for ANCP? thanks, L. _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Thu Jun 21 13:28:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1QSQ-00031d-JZ; Thu, 21 Jun 2007 13:28:34 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1I1QSP-00031Y-50 for ancp-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 13:28:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1QSO-00031Q-RZ for ancp@ietf.org; Thu, 21 Jun 2007 13:28:32 -0400 Received: from kremlin.juniper.net ([207.17.137.120] helo=smtpa.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1QSN-0004cQ-BE for ancp@ietf.org; Thu, 21 Jun 2007 13:28:32 -0400 Received: from unknown (HELO emailfeemea1.jnpr.net) ([172.26.192.140]) by smtpa.juniper.net with ESMTP; 21 Jun 2007 10:28:30 -0700 X-IronPort-AV: i="4.16,448,1175497200"; d="scan'208"; a="22848938:sNHT59286536" Received: from emailemea5.jnpr.net ([172.26.192.134]) by emailfeemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 18:28:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7235.2 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [ANCP] Why does ANCP use GSMP? Date: Thu, 21 Jun 2007 18:28:11 +0100 Message-ID: In-Reply-To: <200706201933.UAA24609@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Why does ANCP use GSMP? Thread-Index: AcezcfWeE249Pd/nR82GCiBT+DiUCgAswpfQ From: "Derek Harkness" To: "Lloyd Wood" , X-OriginalArrivalTime: 21 Jun 2007 17:28:28.0747 (UTC) FILETIME=[94DC41B0:01C7B429] X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: danielf@cisco.com X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org =20 Hi, Some background you are maybe missing is that there was a long discussion in the DSL Forum which described the problem scenario / use cases in WT-147 and then examined a number of protocols ( DSLF tries not to invent new protocols if a suitable one is available ) and found GSMP the most suitable basis for doing so - if you dont have access to the DSLF WT-147 documents I'm sure we can get someone to unicast the relevant docs to you.=20 My purely personal take/paraphrase is that GSMP was developed for a L3 aware thing to control and be informed of the e.g. port status of a l2 switching entity. The NAS is a l3 aware thing which wants to control and be informed of the e.g. port status of an access node, which is primarily a l2 switching entity. ( My terminology is deliberately loose here as I don't wish to get into a discussion on l3 awareness processing in access nodes again). End personal take.=20 The DSL Forum then handed the work to the IETF to standardise the protocol, which is when the ANCP WG was founded.=20 Regarding your concern that we discuss ATM a lot in the framework but use only the IP/TCP transport of ANCP, I see these as 2 different things. ANCP is part of the control plane between NAS and AN, and all ANs and NAS use IP as the basis of their control plane ( be it telnet, ssh, snmp ) - at least all I have ever come across. Therefore transporting ANCP over IP between NAS and AN seems the only sensible option and therefore the other options ( GSMP direct on ATM ) seem no longer relevant.=20 The ATM referred to in the framework is on the local loop in the case of certain DSL technologies (e.g. ADSL, ADSL2+ ) and is some cases as the aggregation network between AN and NAS. Given that there are over 100 Mio such DSL lines with ATM on the local loop, then a NAS knowing about DSL ports an AN with ATM on the local loop and knowing the BW of that local loop to adjust NAS shapers, remotely controlling OAM on that local loop is a very very useful thing. For this reason I see nothing disturbing in transporting ANCP over IP to the AN but using ANCP to convey information about an ATM port of that AN. To repeat myself, I don't see anybody saying that telnet/ssh/SNMP for managing a ADSL AN should be transported over ATM without IP. Maybe this answers why I'm not sure why you "don't see how ANCP can both be an extension to an existing protocol, and yet also try to restrict how that existing protocol is used." =20 Hopefully that helps, Derek. +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D+ Derek Harkness Juniper Networks=20 Nymphenburger Strasse 13-15 80335 Munich Germany Tel: +49 89 5529 4916 Mobile: +49 172 843 6621 Email: DHarkness@juniper.net +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D+=20 -----Original Message----- From: Lloyd Wood [mailto:L.Wood@surrey.ac.uk]=20 Sent: 20 June 2007 21:31 To: ancp@ietf.org Cc: danielf@cisco.com Subject: [ANCP] Why does ANCP use GSMP? How does ANCP work? What is the plumbing, and how are messages communicated? I understand that ANCP depends on GSMPv3, though you have to dig pretty deep into the protocol specification to discover this fact. (I find it interesting that the framework document skips nicely over the whole GSMP dependency, and that the only reason given in the charter for using GSMP is that early implementations in this space use it.) Current specification of ANCP seems to be all high-level stuff; how the plumbing actually works is glossed over with a handwave, and there's a long trail of document dependencies. Though ANCP depends on GSMP, it's stated in http://www.ietf.org/internet-drafts/draft-ietf-ancp-protocol-00.txt (which, btw, is filled with "smart quotes" _ I see a lot of questionmarks, which is appropriate.) that only TCP is used for ANCP. A detailed example of a message exchange or two would be useful to see. I don't see how ANCP can both be an extension to an existing protocol, and yet also try to restrict how that existing protocol is used. This is called 'having your cake and eating it'. Given that GSMP was ATM-only before version 3, and that ANCP is only using version 3 and only running IP, while ATM remains the core of GSMP -- why is ANCP using GSMP at all? It seems like an unnatural fit, rather than a logical extension of GSMP. (And overloading TCP's RST/ACK for ANCP's purposes when there's a capability mismatch - seriously? Communicating how there's a mismatch would be more useful. If that's the only way you can communicate this in GSMP, GSMP would be the wrong thing to use.) The framework document discusses ATM a _lot_, which makes ANCP's TCP-only protocol restriction on GSMP more curious. Is GSMP the right choice to base ANCP on? Is TCP even the right choice for small messages, or is it overkill? If ANCP is leveraging the GSMP framework, ANCP is leveraging everything that GSMP comes with, including over-ATM, over Ethernet, over-TCP. Is that baggage desirable? (I'm playing devil's advocate here, as requested by Woj in his capacity as wg chair. We have a problem I described previously that we thought ANCP could be adapted to be a solution for - but adapting the entire complexity of GSMP to solve a point problem strikes me as increasingly wrong even for ANCP itself, given how ANCP is using GSMP. So the solution to our problem would be an extension of ANCP, which is an extension of GSMP, but only in some preferred ways?) Why is GSMP use a good idea for ANCP? thanks, L. _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Fri Jun 22 04:02:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1e5r-0007RW-F6; Fri, 22 Jun 2007 04:02:11 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1I1SfM-0003dO-0d for ancp-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 15:50:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1SfL-0003ct-9J; Thu, 21 Jun 2007 15:50:03 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1SfK-0001aH-W4; Thu, 21 Jun 2007 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 98EF226EA0; Thu, 21 Jun 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I1SfK-0000t0-BF; Thu, 21 Jun 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 21 Jun 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 386e0819b1192672467565a524848168 X-Mailman-Approved-At: Fri, 22 Jun 2007 04:02:09 -0400 Cc: ancp@ietf.org Subject: [ANCP] I-D ACTION:draft-ietf-ancp-security-threats-01.txt X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Access Node Control Protocol Working Group of the IETF. Title : Security Threats and Security Requirements for the Access Node Control Protocol (ANCP) Author(s) : H. Moustafa, et al. Filename : draft-ietf-ancp-security-threats-01.txt Pages : 15 Date : 2007-6-21 The Access Node Control Protocol (ANCP) aims to communicate QoS-, service- and subscriber-related configurations and operations between a Network Access Server (NAS) and an Access Node (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)). The main goal of this protocol is to configure and manage access equipments and allow them to report information to the NAS in order to enable and optimize configuration. This document investigates security threats that all ANCP nodes could encounter. This document develops a threat model for ANCP security aiming to decide which security functions are required. Based on this, security requirements regarding the Access Node Control Protocol are defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ancp-security-threats-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ancp-security-threats-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ancp-security-threats-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-6-21120541.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ancp-security-threats-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ancp-security-threats-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-21120541.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp --NextPart-- From ancp-bounces@ietf.org Fri Jun 22 09:20:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1j3V-0002vp-Rm; Fri, 22 Jun 2007 09:20:05 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1I1j3U-0002vk-Jw for ancp-confirm+ok@megatron.ietf.org; Fri, 22 Jun 2007 09:20:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1j3U-0002vc-9V for ancp@ietf.org; Fri, 22 Jun 2007 09:20:04 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1j3S-0005Sn-Oz for ancp@ietf.org; Fri, 22 Jun 2007 09:20:04 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP for ancp@ietf.org; Fri, 22 Jun 2007 15:19:59 +0200 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Jun 2007 15:19:58 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 22 Jun 2007 15:19:53 +0200 Message-Id: <6439282641581441A36F7F6F83ED2ED2025C936C@S4DE8PSAAFQ.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ANCP / Redundancy Thread-Index: Ace00McnZVDSAR3AQSux+0Kz6L0kBQ== From: "Haag, T" To: X-OriginalArrivalTime: 22 Jun 2007 13:19:58.0668 (UTC) FILETIME=[082C80C0:01C7B4D0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 83e9494d829b08cc3f644ef6ac1b9bd4 Cc: "Busser, M" Subject: [ANCP] ANCP / Redundancy X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0407191201==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0407191201== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7B4D0.050E26AB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7B4D0.050E26AB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, =20 Considering framework of ANCP an IP connection between AN and NAS is required. Building high reliable Network architecture redundancy is an issue. =20 Redundancy can be considered on different levels. =20 1. Link redundancy (belongs to link AN - NAS) 2. Interface/port redundancy (related to network elements AN and NAS) 3. Network element related board redundancy (related to NAS and central unit of AN) 4. Network Element Redundancy (related mainly to NAS in case of 1+1 or/and load sharing) =20 >From my understanding "Link Redundancy" can be performed by IP Features (e.g. BFD), "Interface/Port Redundancy can be solved by interface related functions (e.g. LAC). =20 Handling of Network Element related board redundancy und network element redundancy itself (different ANCP controllers) should be an issue for investigation of ANCP. Progressing ANCP work by defining ANCP for high reliable architectures redundancy case 3 and 4 requirements need to be considered and discussed during upcoming meeting. =20 Regards =20 Thomas =20 ------_=_NextPart_001_01C7B4D0.050E26AB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

Considering framework of ANCP an IP connection between AN and NAS is required. Building high reliable Network = architecture redundancy is an issue.

 

Redundancy can be considered on different = levels.

 

  1. Link = redundancy           =             =             =             = (belongs to link AN – NAS)
  2. Interface/port redundancy          =             =             = (related to network elements AN and NAS)
  3. Network = element related board redundancy         = (related to NAS and central unit of AN)
  4. Network = Element Redundancy   =             =             = (related mainly to NAS in case of 1+1 or/and load = sharing)

 

From my understanding “Link = Redundancy” can be performed by IP Features (e.g. BFD), “Interface/Port = Redundancy can be solved by interface related functions (e.g. = LAC).

 

Handling of Network Element related board = redundancy und network element redundancy itself (different ANCP controllers) = should be an issue for investigation of ANCP.

Progressing ANCP work by defining ANCP for = high reliable architectures redundancy case 3 and 4 requirements need to be considered and discussed during upcoming = meeting.

 

Regards

 

Thomas

 

------_=_NextPart_001_01C7B4D0.050E26AB-- --===============0407191201== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp --===============0407191201==-- From ancp-bounces@ietf.org Fri Jun 22 15:50:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1p9T-0006oJ-AS; Fri, 22 Jun 2007 15:50:39 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1I1p8t-0005pu-8D for ancp-confirm+ok@megatron.ietf.org; Fri, 22 Jun 2007 15:50:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1p8s-0005pI-KX; Fri, 22 Jun 2007 15:50:02 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1p8s-0000E0-6Q; Fri, 22 Jun 2007 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 1A71132981; Fri, 22 Jun 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I1p8r-0008RA-UJ; Fri, 22 Jun 2007 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 22 Jun 2007 15:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: ancp@ietf.org Subject: [ANCP] I-D ACTION:draft-ietf-ancp-mib-an-00.txt X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Access Node Control Protocol Working Group of the IETF. Title : Access Node Control Protocol (ANCP) MIB module for Access Nodes Author(s) : S. De Cnodder, M. Morgenstern Filename : draft-ietf-ancp-mib-an-00.txt Pages : 31 Date : 2007-6-22 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing access nodes that are using the Access Node Control Protocol (ANCP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ancp-mib-an-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ancp-mib-an-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ancp-mib-an-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-6-22125301.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ancp-mib-an-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ancp-mib-an-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-22125301.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp --NextPart-- From ancp-bounces@ietf.org Sat Jun 30 06:17:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4a0q-0006L1-0T; Sat, 30 Jun 2007 06:17:08 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1I4a0n-0006Kq-Ey for ancp-confirm+ok@megatron.ietf.org; Sat, 30 Jun 2007 06:17:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4a0n-0006Ki-42 for ancp@ietf.org; Sat, 30 Jun 2007 06:17:05 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4a0j-00049n-KK for ancp@ietf.org; Sat, 30 Jun 2007 06:17:05 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 30 Jun 2007 12:17:01 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAHrKhUaQ/uCLh2dsb2JhbACPJAEBCQ4s X-IronPort-AV: i="4.16,479,1175464800"; d="scan'208"; a="146910192:sNHT26214428" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5UAH01S009076; Sat, 30 Jun 2007 12:17:00 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5UAH0TC009232; Sat, 30 Jun 2007 10:17:00 GMT Received: from lwood-wxp01.cisco.com (ams3-vpn-dhcp356.cisco.com [10.61.65.100]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA28185; Sat, 30 Jun 2007 11:16:57 +0100 (BST) Message-Id: <200706301016.LAA28185@cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 30 Jun 2007 11:16:26 +0100 To: "Wojciech Dec \(wdec\)" From: Lloyd Wood Subject: RE: [ANCP] ANCP use for smart adaptive modems? In-Reply-To: References: <200706181856.TAA26564@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Authentication-Results: ams-dkim-2; header.From=L.Wood@surrey.ac.uk; dkim=neutral X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org We've now written this satellite/wireless scenario up as a draft: http://www.ietf.org/internet-drafts/draft-floreani-ancp-wireless-00.txt (Thanks to Derek for details of the history of ANCP.) L. At Wednesday 20/06/2007 16:57 +0200, Wojciech Dec \(wdec\) wrote: >Hi Lloyd, > >Your application would seem to fit in nicely with the modem train rate >reporting functionality already defined in ANCP. Would be interesting to >know whether the smart adaptive wireless modem application would require >additional info to what's define in the protocol spec so far. While the >WG has been focusing on DSL service providers as the primary adopters of >ANCP, it would seem reasonable for the WG to look into a generic >extensibility scheme for the protocol. > >Regards, >Woj. > > >> -----Original Message----- >> From: Lloyd Wood [mailto:L.Wood@surrey.ac.uk] >> Sent: 18 June 2007 20:56 >> To: ancp@ietf.org >> Cc: Daniel Floreani (danielf) >> Subject: [ANCP] ANCP use for smart adaptive modems? >> >> We have been looking at the problem of routers talking to >> smart adaptive wireless modems - modems that can vary their >> output from say 16kbps to 512kbps, or 1-6Mbps, depending on >> channel conditions. These modems often have ethernet ports, >> because ethernet is cheap, and they're connected to a router >> the next hop along. (There are hundreds of custom modems, so >> they're not built into the router directly.) But you need to >> rate-limit and set QoS on the router's Ethernet interface to >> match the modem output - and when the modem rate varies, your >> static QoS config is rendered useless. You can't usefully let >> 100Mbps go over Ethernet to the modem. >> >> So, we would need a way for the modem to signal that its >> output/input wireless speeds have changed, so that the router >> dynamically updates its QoS/rate-limiting configuration to match. >> >> So, could ANCP communication over Ethernet between modem and >> router be one way to solve this? is there any wider interest >> in using ANCP in this way, generalising from the managed DSL space? >> >> thanks, >> >> L. >> >> >> >> >> _______________________________________________ >> ANCP mailing list >> ANCP@ietf.org >> https://www1.ietf.org/mailman/listinfo/ancp >> _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp