From ancp-bounces@ietf.org Mon Nov 05 04:36: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 1IoyNo-0006JU-EH; Mon, 05 Nov 2007 04:36:36 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IoyNm-0006Iy-SW for ancp-confirm+ok@megatron.ietf.org; Mon, 05 Nov 2007 04:36:35 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IoyNh-00069A-Pk for ancp@ietf.org; Mon, 05 Nov 2007 04:36:29 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IoyNg-0000tM-OG for ancp@ietf.org; Mon, 05 Nov 2007 04:36:29 -0500 X-IronPort-AV: E=Sophos;i="4.21,371,1188802800"; d="scan'208,217";a="246771708" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by sj-iport-6.cisco.com with ESMTP; 05 Nov 2007 01:36:27 -0800 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 lA59aQnT009152 for ; Mon, 5 Nov 2007 10:36:26 +0100 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 lA59aLqb011226 for ; Mon, 5 Nov 2007 09:36:26 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); Mon, 5 Nov 2007 10:36:12 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 5 Nov 2007 10:36:05 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PORT UP Data Rate? Thread-Index: Acgfj0lsR0JKUCfKQJCLErysQNwWPw== From: "Wojciech Dec (wdec)" To: X-OriginalArrivalTime: 05 Nov 2007 09:36:12.0359 (UTC) FILETIME=[4DA65570:01C81F8F] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15522.000 X-TM-AS-Result: No--9.513900-8.000000-2 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=11524; t=1194255386; x=1195119386; 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:=20PORT=20UP=20Data=20Rate? |Sender:=20; bh=Fb75MGSK+KtC5RkBxsd94bljcqduUuofoZEhQtdRuNc=; b=ZrtgaNn0NgQywJLsFSZJ5oIUdtQdjPpVGvZUx+jxrgsBpdsFXighwMmk78R0z147c9kd6WfM E2mkMQ6zSNL62PQ9Tlkb55egn5gQDwHd4lIgmDLBNjqf1akx3/D4iw8B; 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: 9cc83ac38bbbabacbf00f656311dd8d8 Subject: [ANCP] PORT UP Data Rate? 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="===============1555247470==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============1555247470== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C81F8F.4D62DAD3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C81F8F.4D62DAD3 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi All, Hopefully someone can clarify for me the meaning of the Actual data rate value in ANCP's PORT-UP messages, and also perhaps comment on their current implementations. Is this rate meant to be the rounded up effective transport capacity (deriving from various ADSL Transport Classes) or raw DSL modem speed? The difference between the two is primarily in the DSL PHY encoding overhead. The framework and protocol drafts are not too clear on this matter, but seem to point more towards the former if anything.=20 For example the framework 03 draft currently reads in Section 3.1 as follows : o The identification and speed (data rate) of the DSL Access Loop (also known as the "DSL sync rate") o The identification and speed (data rate) of the Remote Terminal(RT)/Access Node uplink (when relevant) The NAS can adjust downstream shaping to current Access Loop actual data rate, and more generally re-configure the appropriate nodes of its hierarchical scheduler (support of advanced capabilities according to TR-101). This use case may actually include more information than link identification and corresponding data rates. In case of DSL Access Loops, the following Access Loop characteristics can be sent to the NAS (cf. ITU-T Recommendation G.997.1 [G.997.1]): o DSL Type (e.g. ADSL1, ADSL2, SDSL, ADSL2+, VDSL, VDSL2) o Framing mode (e.g. ATM, ITU-T Packet Transfer Mode (PTM), IEEE 802.3 Ethernet in the First Mile (EFM)) o DSL port state (e.g. synchronized/showtime, low power, no power/ idle) o Actual net data rate (upstream/downstream) While the protocol draft says the following: Following sub-TLVs are currently defined :=20 . Type (DSL-Type =3D 0x91) : Defines the type of transmission system=20 in use. This is a mandatory TLV.=20 Length : (4 bytes) =20 Value : (Transmission system : ADSL1 =3D 0x01, ADSL2 =3D = 0x02, ADSL2+ =3D 0x03, VDSL1 =3D 0x04, VDSL2 =3D 0x05, SDSL =3D = 0x06, UNKNOWN=20 =3D 0x07).=20 . Type (Actual-Data-Rate-Upstream =3D 0x81) : Actual data rate = upstream of a synchronized DSL line. This is a mandatory TLV.=20 This rate value and all the subsequent ones account for the DSL=20 overhead (i.e. signify the net rate). =20 Length : (4 bytes)=20 Value : (Rate in Kb/sec)=20 . Type (Actual-Data-Rate-Downstream =3D 0x82) : Actual data = rate downstream of a synchronized DSL line. This is a mandatory TLV.=20 Length : (4 bytes)=20 Regards, Woj. ------_=_NextPart_001_01C81F8F.4D62DAD3 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable PORT UP Data Rate?

Hi = All,

Hopefully someone = can clarify for me the meaning of the Actual data rate value in ANCP's = PORT-UP messages, and also perhaps comment on their current = implementations. Is this rate meant to be the rounded up effective = transport capacity (deriving from various ADSL Transport Classes) or raw = DSL modem speed? The difference between the two is primarily in the DSL = PHY encoding overhead.

The framework and = protocol drafts are not too clear on this matter, but seem to point more = towards the former if anything.

For example the = framework 03 draft currently reads in Section 3.1 as follows = :

  o  The identification and speed (data rate) of the DSL = Access Loop
      (also known as the = "DSL sync rate")

   o  The identification and speed (data rate) of = the Remote
      Terminal(RT)/Access = Node uplink (when relevant)

   The NAS can adjust downstream shaping to current = Access Loop actual
   data rate, and more generally = re-configure the appropriate nodes of
   its hierarchical scheduler (support of = advanced capabilities
   according to TR-101).

   This use case may actually include more information = than link
   identification and corresponding data = rates.  In case of DSL Access
   Loops, the following Access Loop = characteristics can be sent to the
   NAS (cf. ITU-T Recommendation G.997.1 = [G.997.1]):

   o  DSL Type (e.g.  ADSL1, ADSL2, SDSL, = ADSL2+, VDSL, VDSL2)

   o  Framing mode (e.g.  ATM, ITU-T Packet = Transfer Mode (PTM), IEEE
      802.3 Ethernet in = the First Mile (EFM))

   o  DSL port state (e.g. synchronized/showtime, = low power, no power/
      idle)

   o  Actual net data rate = (upstream/downstream)


While the protocol = draft says the following:

         Following sub-TLVs = are currently defined :

          . Type = (DSL-Type =3D 0x91) : Defines the type of transmission system =
           &n= bsp; in use. This is a mandatory TLV.

           &n= bsp; Length :  (4 bytes)  

           &n= bsp; Value  : (Transmission system : ADSL1 =3D 0x01, ADSL2 =3D = 0x02,    
           &n= bsp; ADSL2+ =3D 0x03, VDSL1 =3D 0x04, VDSL2 =3D 0x05, SDSL =3D 0x06, = UNKNOWN
           &n= bsp; =3D 0x07).

          . Type = (Actual-Data-Rate-Upstream =3D 0x81) : Actual data rate
           &n= bsp; upstream of a synchronized DSL line. This is a mandatory TLV. =
           &n= bsp; This rate value and all the subsequent ones account for the DSL =
           &n= bsp; overhead (i.e. signify the net rate).  

            = Length  :  (4 bytes)

            = Value   : (Rate in Kb/sec)

          . Type = (Actual-Data-Rate-Downstream =3D 0x82) : Actual data rate
           &n= bsp; downstream of a synchronized DSL line. This is a mandatory TLV. =

           &n= bsp; Length :  (4 bytes)

Regards,
Woj.


------_=_NextPart_001_01C81F8F.4D62DAD3-- --===============1555247470== 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 --===============1555247470==-- From ancp-bounces@ietf.org Tue Nov 06 07:15: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 1IpNKo-0003L5-K6; Tue, 06 Nov 2007 07:15:10 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IpNKo-0003L0-0t for ancp-confirm+ok@megatron.ietf.org; Tue, 06 Nov 2007 07:15:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpNKn-0003Ks-Nc for ancp@ietf.org; Tue, 06 Nov 2007 07:15:09 -0500 Received: from smail5.alcatel.fr ([64.208.49.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpNKk-0000s2-6Q for ancp@ietf.org; Tue, 06 Nov 2007 07:15:09 -0500 Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.ad2.ad.alcatel.com [155.132.6.78]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id lA6CDnUk013989; Tue, 6 Nov 2007 13:13:49 +0100 Received: from FRVELSMBS14.ad2.ad.alcatel.com ([155.132.6.34]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 6 Nov 2007 13:15:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 6 Nov 2007 13:15:02 +0100 Message-ID: <2E17595838F96949AB1F0FD9A8EC5ED00B9DD6@FRVELSMBS14.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ANCP Vancouver meeting slot requests Thread-Index: AcggbqhLPtqVeD05ThyQEormCkj9bw== From: "BOCCI Matthew" To: X-OriginalArrivalTime: 06 Nov 2007 12:15:04.0064 (UTC) FILETIME=[A966D800:01C8206E] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: Subject: [ANCP] ANCP Vancouver meeting slot requests 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="===============1209429648==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============1209429648== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8206E.A8D7C2AF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8206E.A8D7C2AF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All,=20 Please can you send requests for a slot at the next ANCP meeting to myself and Woj by Monday 19th November.=20 Please also include a summary of what you want to talk about, and a pointer to the draft, if any.=20 Best regards,=20 Matthew=20 ------_=_NextPart_001_01C8206E.A8D7C2AF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ANCP Vancouver meeting slot requests

All,
Please can you send requests for a = slot at the next ANCP meeting to myself and Woj by Monday 19th = November.
Please also include a summary of what = you want to talk about, and a pointer to the draft, if any.
Best regards,
Matthew

------_=_NextPart_001_01C8206E.A8D7C2AF-- --===============1209429648== 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 --===============1209429648==-- From ancp-bounces@ietf.org Wed Nov 07 03:47:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpgZ9-0007E7-FW; Wed, 07 Nov 2007 03:47:15 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IpgZ9-0007Dp-44 for ancp-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 03:47:15 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpgZ2-0007Ae-Ph for ancp@ietf.org; Wed, 07 Nov 2007 03:47:08 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpgZ1-0004cv-D8 for ancp@ietf.org; Wed, 07 Nov 2007 03:47:08 -0500 X-IronPort-AV: E=Sophos;i="4.21,382,1188770400"; d="scan'208,217";a="157049643" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 07 Nov 2007 09:46:56 +0100 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 lA78kujw032554 for ; Wed, 7 Nov 2007 09:46:56 +0100 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 lA78kp8i016630 for ; Wed, 7 Nov 2007 08:46:56 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, 7 Nov 2007 09:46:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ANCP] PORT UP Data Rate? Date: Wed, 7 Nov 2007 09:46:50 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] PORT UP Data Rate? Thread-Index: Acgfj0lsR0JKUCfKQJCLErysQNwWPwBiVNWA References: From: "Wojciech Dec (wdec)" To: "Wojciech Dec (wdec)" , X-OriginalArrivalTime: 07 Nov 2007 08:46:51.0203 (UTC) FILETIME=[BD7D4930:01C8211A] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15530.001 X-TM-AS-Result: No--18.245600-8.000000-2 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=13095; t=1194425216; x=1195289216; 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]=20PORT=20UP=20Data=20Rate? |Sender:=20; bh=19RPUmAybJ+lMqH2htsfrgA4EEGqxLX2849G3QjvmcY=; b=GEQ4E/V07WRH8kGER215jam1gM3TMxWF3M1qn3U59pKijDT5IO9JZHjubiEm9N9d1t0Ye58f UkQn0ArsH/ZP7Voz+ac/p5cqzKt+kyuhxkQyWxKP/iGSpXMlr44073hb; 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: 32a65c0bf5eb4ec26489239c7cdd0636 Cc: 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="===============0753650979==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0753650979== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8211A.BD577ACB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8211A.BD577ACB Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Folks, =20 can anyone reply? To put the question in other words, if ANCP signals a line rate of downstream rate of 4Mbps, is this the effective ATM VC or Ethernet "circuit" data carrying capacity, or is it the raw modem rate which does not include DSL PHY overheads? The text should be *very* clear about this. =20 -Woj. ________________________________ From: Wojciech Dec (wdec)=20 Sent: 05 November 2007 10:36 To: ancp@ietf.org Subject: [ANCP] PORT UP Data Rate? =09 =09 Hi All,=20 Hopefully someone can clarify for me the meaning of the Actual data rate value in ANCP's PORT-UP messages, and also perhaps comment on their current implementations. Is this rate meant to be the rounded up effective transport capacity (deriving from various ADSL Transport Classes) or raw DSL modem speed? The difference between the two is primarily in the DSL PHY encoding overhead. The framework and protocol drafts are not too clear on this matter, but seem to point more towards the former if anything.=20 For example the framework 03 draft currently reads in Section 3.1 as follows :=20 o The identification and speed (data rate) of the DSL Access Loop=20 (also known as the "DSL sync rate")=20 o The identification and speed (data rate) of the Remote=20 Terminal(RT)/Access Node uplink (when relevant)=20 The NAS can adjust downstream shaping to current Access Loop actual=20 data rate, and more generally re-configure the appropriate nodes of=20 its hierarchical scheduler (support of advanced capabilities=20 according to TR-101).=20 This use case may actually include more information than link identification and corresponding data rates. In case of DSL Access=20 Loops, the following Access Loop characteristics can be sent to the=20 NAS (cf. ITU-T Recommendation G.997.1 [G.997.1]):=20 o DSL Type (e.g. ADSL1, ADSL2, SDSL, ADSL2+, VDSL, VDSL2)=20 o Framing mode (e.g. ATM, ITU-T Packet Transfer Mode (PTM), IEEE=20 802.3 Ethernet in the First Mile (EFM))=20 o DSL port state (e.g. synchronized/showtime, low power, no power/=20 idle)=20 o Actual net data rate (upstream/downstream)=20 While the protocol draft says the following:=20 Following sub-TLVs are currently defined :=20 . Type (DSL-Type =3D 0x91) : Defines the type of transmission system=20 in use. This is a mandatory TLV.=20 Length : (4 bytes) =20 Value : (Transmission system : ADSL1 =3D 0x01, ADSL2 =3D 0x02, =20 ADSL2+ =3D 0x03, VDSL1 =3D 0x04, VDSL2 =3D 0x05, SDSL =3D 0x06, UNKNOWN=20 =3D 0x07).=20 . Type (Actual-Data-Rate-Upstream =3D 0x81) : Actual data rate=20 upstream of a synchronized DSL line. This is a mandatory TLV.=20 This rate value and all the subsequent ones account for the DSL=20 overhead (i.e. signify the net rate). =20 Length : (4 bytes)=20 Value : (Rate in Kb/sec)=20 . Type (Actual-Data-Rate-Downstream =3D 0x82) : Actual data rate=20 downstream of a synchronized DSL line. This is a mandatory TLV.=20 Length : (4 bytes)=20 Regards,=20 Woj.=20 ------_=_NextPart_001_01C8211A.BD577ACB Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable PORT UP Data Rate?
Hi Folks,
 
can anyone reply? To put the question in other words, if ANCP = signals a=20 line rate of downstream rate of 4Mbps, is this the effective ATM VC or = Ethernet=20 "circuit" data carrying capacity, or is it the raw modem rate which = does=20 not include DSL PHY overheads? The text should be *very* clear about=20 this.
 
-Woj.

From: Wojciech Dec (wdec) =
Sent: 05=20 November 2007 10:36
To: ancp@ietf.org
Subject: = [ANCP] PORT=20 UP Data Rate?

Hi = All,

Hopefully someone = can clarify for=20 me the meaning of the Actual data rate value in ANCP's PORT-UP = messages, and=20 also perhaps comment on their current implementations. Is this rate = meant to=20 be the rounded up effective transport capacity (deriving from various = ADSL=20 Transport Classes) or raw DSL modem speed? The difference between the = two is=20 primarily in the DSL PHY encoding overhead.

The framework and = protocol drafts=20 are not too clear on this matter, but seem to point more towards the = former if=20 anything.

For example the = framework 03 draft=20 currently reads in Section 3.1 as follows :

  = o  The=20 identification and speed (data rate) of the DSL Access = Loop=20
      (also known as the "DSL sync=20 rate")

   = o  The=20 identification and speed (data rate) of the Remote =
     =20 Terminal(RT)/Access Node uplink (when relevant)

   = The NAS can=20 adjust downstream shaping to current Access Loop actual=20
   data rate,=20 and more generally re-configure the appropriate nodes of =
   its=20 hierarchical scheduler (support of advanced capabilities =
   according to=20 TR-101).

   = This use case=20 may actually include more information than link =
   = identification and=20 corresponding data rates.  In case of DSL Access =
   Loops, = the following=20 Access Loop characteristics can be sent to the
   NAS (cf. = ITU-T=20 Recommendation G.997.1 [G.997.1]):

   = o  DSL=20 Type (e.g.  ADSL1, ADSL2, SDSL, ADSL2+, VDSL, = VDSL2)

   = o =20 Framing mode (e.g.  ATM, ITU-T Packet Transfer Mode (PTM),=20 IEEE
      802.3 Ethernet in the First = Mile=20 (EFM))

   = o  DSL=20 port state (e.g. synchronized/showtime, low power, no = power/=20
      idle)

   = o =20 Actual net data rate (upstream/downstream)


While the protocol = draft says the=20 following:

         Following = sub-TLVs are=20 currently defined :

          . Type = (DSL-Type=20 =3D 0x91) : Defines the type of transmission system =
          &nbs= p; =20 in use. This is a mandatory TLV.

          &nbs= p; =20 Length :  (4 bytes)  

          &nbs= p; =20 Value  : (Transmission system : ADSL1 =3D 0x01, ADSL2 =3D=20 0x02,    
          &nbs= p; =20 ADSL2+ =3D 0x03, VDSL1 =3D 0x04, VDSL2 =3D 0x05, SDSL =3D 0x06, = UNKNOWN=20
          &nbs= p; =20 =3D 0x07).

          . Type = (Actual-Data-Rate-Upstream =3D 0x81) : Actual data rate =
          &nbs= p; =20 upstream of a synchronized DSL line. This is a mandatory TLV.=20
          &nbs= p; =20 This rate value and all the subsequent ones account for the DSL=20
          &nbs= p; =20 overhead (i.e. signify the net rate).  

          &nbs= p;=20 Length  :  (4 bytes)

          &nbs= p;=20 Value   : (Rate in Kb/sec)

          . Type = (Actual-Data-Rate-Downstream =3D 0x82) : Actual data rate=20
          &nbs= p; =20 downstream of a synchronized DSL line. This is a mandatory TLV.=20

          &nbs= p; =20 Length :  (4 bytes)

Regards,=20
Woj.=20


------_=_NextPart_001_01C8211A.BD577ACB-- --===============0753650979== 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 --===============0753650979==-- From ancp-bounces@ietf.org Wed Nov 07 04:24:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iph8y-0003tM-NV; Wed, 07 Nov 2007 04:24:16 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1Iph8y-0003t4-84 for ancp-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 04:24:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iph8x-0003sT-Bi for ancp@ietf.org; Wed, 07 Nov 2007 04:24:15 -0500 Received: from colt-na7.alcatel.fr ([62.23.212.7] helo=smail6.alcatel.fr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iph8w-00065N-Jq for ancp@ietf.org; Wed, 07 Nov 2007 04:24:15 -0500 Received: from FRVELSBHS07.ad2.ad.alcatel.com (frvelsbhs07.ad2.ad.alcatel.com [155.132.6.79]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id lA79Mwv0031756; Wed, 7 Nov 2007 10:22:58 +0100 Received: from [172.31.131.112] ([172.31.131.112]) by FRVELSBHS07.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Wed, 7 Nov 2007 10:24:11 +0100 Message-ID: <4731843A.30207@alcatel-lucent.be> Date: Wed, 07 Nov 2007 10:24:10 +0100 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: "Wojciech Dec (wdec)" Subject: Re: [ANCP] PORT UP Data Rate? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Nov 2007 09:24:11.0172 (UTC) FILETIME=[F49D6E40:01C8211F] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 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 Woj, It looks to me that the framework document is correct, and that the protocol draft has to replace "data rate" by "net data rate" to make it more accurate, i.e., for istance: Type (Actual-Data-Rate-Upstream = 0x81) : Actual data rate upstream of a synchronized DSL line... should be Type (Actual-Data-Rate-Upstream = 0x81) : Actual net data rate upstream of a synchronized DSL line... The term "net data rate" is accurately defined in section 1.2 of the framework document by referring to the ITU standard. I hope we all have the same understanding of the definition of the bandwidth advertised by ANCP. regards, Stefaan Wojciech Dec (wdec) wrote: > Hi All, > > Hopefully someone can clarify for me the meaning of the Actual data rate > value in ANCP's PORT-UP messages, and also perhaps comment on their > current implementations. Is this rate meant to be the rounded up > effective transport capacity (deriving from various ADSL Transport > Classes) or raw DSL modem speed? The difference between the two is > primarily in the DSL PHY encoding overhead. > > The framework and protocol drafts are not too clear on this matter, but > seem to point more towards the former if anything. > > For example the framework 03 draft currently reads in Section 3.1 as > follows : > > o The identification and speed (data rate) of the DSL Access Loop > (also known as the "DSL sync rate") > > o The identification and speed (data rate) of the Remote > Terminal(RT)/Access Node uplink (when relevant) > > The NAS can adjust downstream shaping to current Access Loop actual > data rate, and more generally re-configure the appropriate nodes of > its hierarchical scheduler (support of advanced capabilities > according to TR-101). > > This use case may actually include more information than link > identification and corresponding data rates. In case of DSL Access > Loops, the following Access Loop characteristics can be sent to the > NAS (cf. ITU-T Recommendation G.997.1 [G.997.1]): > > o DSL Type (e.g. ADSL1, ADSL2, SDSL, ADSL2+, VDSL, VDSL2) > > o Framing mode (e.g. ATM, ITU-T Packet Transfer Mode (PTM), IEEE > 802.3 Ethernet in the First Mile (EFM)) > > o DSL port state (e.g. synchronized/showtime, low power, no power/ > idle) > > o Actual net data rate (upstream/downstream) > > > While the protocol draft says the following: > > Following sub-TLVs are currently defined : > > . Type (DSL-Type = 0x91) : Defines the type of transmission > system > in use. This is a mandatory TLV. > > Length : (4 bytes) > > Value : (Transmission system : ADSL1 = 0x01, ADSL2 = > 0x02, > ADSL2+ = 0x03, VDSL1 = 0x04, VDSL2 = 0x05, SDSL = 0x06, > UNKNOWN > = 0x07). > > . Type (Actual-Data-Rate-Upstream = 0x81) : Actual data rate > upstream of a synchronized DSL line. This is a mandatory TLV. > This rate value and all the subsequent ones account for the > DSL > overhead (i.e. signify the net rate). > > Length : (4 bytes) > > Value : (Rate in Kb/sec) > > . Type (Actual-Data-Rate-Downstream = 0x82) : Actual data rate > downstream of a synchronized DSL line. This is a mandatory > TLV. > > Length : (4 bytes) > > Regards, > Woj. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Wed Nov 07 05:05:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IphnB-0003Mc-4J; Wed, 07 Nov 2007 05:05:49 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1Iphn9-0003MR-LC for ancp-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 05:05:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iphn9-0003Hi-21 for ancp@ietf.org; Wed, 07 Nov 2007 05:05:47 -0500 Received: from eci-iron.ecitele.com ([147.234.242.112] helo=iron.ecitele.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iphn5-0001Fg-CN for ancp@ietf.org; Wed, 07 Nov 2007 05:05:47 -0500 Received: from ilptexfe.ecitele.com (HELO ILPTEXFE02.ecitele.com) ([147.234.245.181]) by eci-iron-out.ecitele.com with ESMTP; 07 Nov 2007 12:06:55 +0200 Received: from ILPTMAIL01.ecitele.com ([147.234.245.211]) by ILPTEXFE02.ecitele.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Nov 2007 12:05:42 +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] PORT UP Data Rate? Date: Wed, 7 Nov 2007 12:05:41 +0200 Message-ID: <83153A1EB675AF4F82E134FA27F95F67023D8C21@ILPTEX02.ecitele.com> In-Reply-To: <4731843A.30207@alcatel-lucent.be> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] PORT UP Data Rate? Thread-Index: AcghIAWJwnDwJGQhRWuz7wGX2UTCaQABCIVg References: <4731843A.30207@alcatel-lucent.be> From: "Moti Morgenstern" To: "Stefaan DE CNODDER" , "Wojciech Dec \(wdec\)" X-OriginalArrivalTime: 07 Nov 2007 10:05:42.0251 (UTC) FILETIME=[C169EBB0:01C82125] X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f 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, May I comment that in DSLF WT-147 both terms are included and the relationship (sameness?) between them is described. Regards, Moti Morgenstern -----Original Message----- From: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be]=20 Sent: Wednesday, November 07, 2007 11:24 AM To: Wojciech Dec (wdec) Cc: ancp@ietf.org Subject: Re: [ANCP] PORT UP Data Rate? Woj, It looks to me that the framework document is correct, and that the=20 protocol draft has to replace "data rate" by "net data rate" to make it=20 more accurate, i.e., for istance: Type (Actual-Data-Rate-Upstream =3D 0x81) : Actual data rate upstream of = a synchronized DSL line... should be Type (Actual-Data-Rate-Upstream =3D 0x81) : Actual net data rate = upstream=20 of a synchronized DSL line... The term "net data rate" is accurately defined in section 1.2 of the=20 framework document by referring to the ITU standard. I hope we all have the same understanding of the definition of the=20 bandwidth advertised by ANCP. regards, Stefaan Wojciech Dec (wdec) wrote: > Hi All, >=20 > Hopefully someone can clarify for me the meaning of the Actual data rate=20 > value in ANCP's PORT-UP messages, and also perhaps comment on their=20 > current implementations. Is this rate meant to be the rounded up=20 > effective transport capacity (deriving from various ADSL Transport=20 > Classes) or raw DSL modem speed? The difference between the two is=20 > primarily in the DSL PHY encoding overhead. >=20 > The framework and protocol drafts are not too clear on this matter, but=20 > seem to point more towards the former if anything. >=20 > For example the framework 03 draft currently reads in Section 3.1 as=20 > follows : >=20 > o The identification and speed (data rate) of the DSL Access Loop > (also known as the "DSL sync rate") >=20 > o The identification and speed (data rate) of the Remote > Terminal(RT)/Access Node uplink (when relevant) >=20 > The NAS can adjust downstream shaping to current Access Loop actual > data rate, and more generally re-configure the appropriate nodes of > its hierarchical scheduler (support of advanced capabilities > according to TR-101). >=20 > This use case may actually include more information than link > identification and corresponding data rates. In case of DSL Access > Loops, the following Access Loop characteristics can be sent to the > NAS (cf. ITU-T Recommendation G.997.1 [G.997.1]): >=20 > o DSL Type (e.g. ADSL1, ADSL2, SDSL, ADSL2+, VDSL, VDSL2) >=20 > o Framing mode (e.g. ATM, ITU-T Packet Transfer Mode (PTM), IEEE > 802.3 Ethernet in the First Mile (EFM)) >=20 > o DSL port state (e.g. synchronized/showtime, low power, no power/ > idle) >=20 > o Actual net data rate (upstream/downstream) >=20 >=20 > While the protocol draft says the following: >=20 > Following sub-TLVs are currently defined : >=20 > . Type (DSL-Type =3D 0x91) : Defines the type of = transmission=20 > system > in use. This is a mandatory TLV. >=20 > Length : (4 bytes) =20 >=20 > Value : (Transmission system : ADSL1 =3D 0x01, ADSL2 =3D = > 0x02, =20 > ADSL2+ =3D 0x03, VDSL1 =3D 0x04, VDSL2 =3D 0x05, SDSL =3D = 0x06,=20 > UNKNOWN > =3D 0x07). >=20 > . Type (Actual-Data-Rate-Upstream =3D 0x81) : Actual data = rate > upstream of a synchronized DSL line. This is a mandatory TLV. > This rate value and all the subsequent ones account for the=20 > DSL > overhead (i.e. signify the net rate). =20 >=20 > Length : (4 bytes) >=20 > Value : (Rate in Kb/sec) >=20 > . Type (Actual-Data-Rate-Downstream =3D 0x82) : Actual data rate > downstream of a synchronized DSL line. This is a mandatory=20 > TLV. >=20 > Length : (4 bytes) >=20 > Regards, > Woj. >=20 >=20 >=20 > ------------------------------------------------------------------------ >=20 > _______________________________________________ > 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 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Wed Nov 07 05:09: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 1IphqG-0005x7-8I; Wed, 07 Nov 2007 05:09:00 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IphqE-0005wY-8S for ancp-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 05:08:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IphqD-0005wF-Sl for ancp@ietf.org; Wed, 07 Nov 2007 05:08:57 -0500 Received: from wip-cdc-wd.wipro.com ([203.91.201.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iphq8-0001KI-DU for ancp@ietf.org; Wed, 07 Nov 2007 05:08:57 -0500 Received: from wip-cdc-wd.wipro.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3D99118055 for ; Wed, 7 Nov 2007 15:38:50 +0530 (IST) Received: from blr-ec-bh01.wipro.com (blr-ec-bh01.wipro.com [10.201.50.91]) by wip-cdc-wd.wipro.com (Postfix) with ESMTP id 280D818051 for ; Wed, 7 Nov 2007 15:38:50 +0530 (IST) Received: from BLR-EC-MBX03.wipro.com ([10.201.50.164]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Nov 2007 15:38:50 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ANCP] PORT UP Data Rate? Date: Wed, 7 Nov 2007 15:38:47 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] PORT UP Data Rate? Thread-Index: Acgfj0lsR0JKUCfKQJCLErysQNwWPwBiVNWAAALZlhA= From: To: , X-OriginalArrivalTime: 07 Nov 2007 10:08:50.0017 (UTC) FILETIME=[3154BD10:01C82126] X-Spam-Score: 0.0 (/) X-Scan-Signature: 23336e92cd9b2f166f17126afcdd84ec Cc: 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="===============0293529021==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0293529021== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C82126.2FF7217D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C82126.2FF7217D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Woj, =20 It looks to me that the terminology used here is consistent with the = physical layer definitions of ITU-T G.997.1 (sec. 7.5.2.1). This is what = will be probably used by ANCP from MIB. Actual data rate is defined to = indicate the actual net data rate of the bearer channel, but this = excludes the rates in DSL line power saving states L1 and L2. ANCP needs = to include report rate reduction in L2 state as well. =20 With ATM transport over DSL, ITU-T has an illustration of what rate = includes overhead: 53 =D7 8 =D7 ATM cell rate =3D "Net data rate"=20 "Net data rate" + Frame overhead rate =3D "Aggregate data rate" =20 "Aggregate data rate" + RS Coding overhead rate =3D "Total data rate"=20 "Total data rate" + Trellis Coding overhead rate =3D Line rate But some implementations treat Net data rate + frame overhead rate as = the line rate. =20 For ANCP, it is probably the net data rate at all states of the line. =20 Thanks, Kirubaharan -----Original Message----- From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Sent: Wednesday, November 07, 2007 2:17 PM To: Wojciech Dec (wdec); ancp@ietf.org Subject: RE: [ANCP] PORT UP Data Rate? =09 =09 Hi Folks, =20 can anyone reply? To put the question in other words, if ANCP signals a = line rate of downstream rate of 4Mbps, is this the effective ATM VC or = Ethernet "circuit" data carrying capacity, or is it the raw modem rate = which does not include DSL PHY overheads? The text should be *very* = clear about this. =20 -Woj. ________________________________ From: Wojciech Dec (wdec)=20 Sent: 05 November 2007 10:36 To: ancp@ietf.org Subject: [ANCP] PORT UP Data Rate? =09 =09 Hi All,=20 Hopefully someone can clarify for me the meaning of the Actual data = rate value in ANCP's PORT-UP messages, and also perhaps comment on their = current implementations. Is this rate meant to be the rounded up = effective transport capacity (deriving from various ADSL Transport = Classes) or raw DSL modem speed? The difference between the two is = primarily in the DSL PHY encoding overhead. The framework and protocol drafts are not too clear on this matter, = but seem to point more towards the former if anything.=20 For example the framework 03 draft currently reads in Section 3.1 as = follows :=20 o The identification and speed (data rate) of the DSL Access Loop=20 (also known as the "DSL sync rate")=20 o The identification and speed (data rate) of the Remote=20 Terminal(RT)/Access Node uplink (when relevant)=20 The NAS can adjust downstream shaping to current Access Loop actual = data rate, and more generally re-configure the appropriate nodes of = its hierarchical scheduler (support of advanced capabilities=20 according to TR-101).=20 This use case may actually include more information than link=20 identification and corresponding data rates. In case of DSL Access = Loops, the following Access Loop characteristics can be sent to the = NAS (cf. ITU-T Recommendation G.997.1 [G.997.1]):=20 o DSL Type (e.g. ADSL1, ADSL2, SDSL, ADSL2+, VDSL, VDSL2)=20 o Framing mode (e.g. ATM, ITU-T Packet Transfer Mode (PTM), IEEE=20 802.3 Ethernet in the First Mile (EFM))=20 o DSL port state (e.g. synchronized/showtime, low power, no power/ = idle)=20 o Actual net data rate (upstream/downstream)=20 While the protocol draft says the following:=20 Following sub-TLVs are currently defined :=20 . Type (DSL-Type =3D 0x91) : Defines the type of = transmission system=20 in use. This is a mandatory TLV.=20 Length : (4 bytes) =20 Value : (Transmission system : ADSL1 =3D 0x01, ADSL2 =3D = 0x02, =20 ADSL2+ =3D 0x03, VDSL1 =3D 0x04, VDSL2 =3D 0x05, SDSL =3D = 0x06, UNKNOWN=20 =3D 0x07).=20 . Type (Actual-Data-Rate-Upstream =3D 0x81) : Actual data = rate=20 upstream of a synchronized DSL line. This is a mandatory = TLV.=20 This rate value and all the subsequent ones account for = the DSL=20 overhead (i.e. signify the net rate). =20 Length : (4 bytes)=20 Value : (Rate in Kb/sec)=20 . Type (Actual-Data-Rate-Downstream =3D 0x82) : Actual data = rate=20 downstream of a synchronized DSL line. This is a = mandatory TLV.=20 Length : (4 bytes)=20 Regards,=20 Woj.=20 ------_=_NextPart_001_01C82126.2FF7217D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Woj,
 
It=20 looks to me that the terminology used here is consistent with the = physical layer=20 definitions of ITU-T G.997.1 (sec. 7.5.2.1). This is what will be = probably used=20 by ANCP from MIB. Actual data rate is defined to indicate the = actual net data=20 rate of the bearer channel, but this excludes the rates in DSL line = power saving=20 states L1 and L2. ANCP needs to include report rate reduction in L2 = state as=20 well.
 
With=20 ATM transport over DSL, ITU-T has an illustration of what rate includes=20 overhead:
53 =D7 8=20 =D7 ATM cell rate =3D "Net data rate" 
"Net data rate" + Frame = overhead rate=20 =3D "Aggregate data rate" 
"Aggregate data rate" + RS Coding = overhead=20 rate =3D "Total data rate" 
"Total data rate" + Trellis Coding = overhead=20 rate =3D Line rate
But=20 some implementations treat Net data rate + frame overhead rate as the = line=20 rate.
 
For=20 ANCP, it is probably the net data rate at all states of the=20 line.
 
Thanks,
Kirubaharan
-----Original Message-----
From: = Wojciech Dec=20 (wdec) [mailto:wdec@cisco.com]
Sent: Wednesday, November = 07, 2007=20 2:17 PM
To: Wojciech Dec (wdec); = ancp@ietf.org
Subject:=20 RE: [ANCP] PORT UP Data Rate?

Hi Folks,
 
can anyone reply? To put the question in other words, if ANCP = signals a=20 line rate of downstream rate of 4Mbps, is this the effective ATM VC or = Ethernet "circuit" data carrying capacity, or is it the raw modem = rate=20 which does not include DSL PHY overheads? The text should be *very* = clear=20 about this.
 
-Woj.

From: Wojciech Dec (wdec) =
Sent:=20 05 November 2007 10:36
To: = ancp@ietf.org
Subject: [ANCP]=20 PORT UP Data Rate?

Hi = All,

Hopefully someone = can clarify=20 for me the meaning of the Actual data rate value in ANCP's PORT-UP = messages,=20 and also perhaps comment on their current implementations. Is this = rate=20 meant to be the rounded up effective transport capacity (deriving = from=20 various ADSL Transport Classes) or raw DSL modem speed? The = difference=20 between the two is primarily in the DSL PHY encoding=20 overhead.

The framework and = protocol=20 drafts are not too clear on this matter, but seem to point more = towards the=20 former if anything.

For example the = framework 03=20 draft currently reads in Section 3.1 as follows :

  = o  The=20 identification and speed (data rate) of the DSL Access = Loop=20
      (also known as the "DSL sync = rate")

   o  The=20 identification and speed (data rate) of the Remote =
     =20 Terminal(RT)/Access Node uplink (when relevant)

   The NAS can=20 adjust downstream shaping to current Access Loop = actual=20
   data rate,=20 and more generally re-configure the appropriate nodes = of=20
   its=20 hierarchical scheduler (support of advanced = capabilities=20
   according=20 to TR-101).

   This use=20 case may actually include more information than link =
   = identification and=20 corresponding data rates.  In case of DSL Access=20
   Loops, the=20 following Access Loop characteristics can be sent to = the=20
   NAS (cf.=20 ITU-T Recommendation G.997.1 [G.997.1]):

   o  DSL=20 Type (e.g.  ADSL1, ADSL2, SDSL, ADSL2+, VDSL, = VDSL2)

   o =20 Framing mode (e.g.  ATM, ITU-T Packet Transfer Mode (PTM),=20 IEEE
      802.3 Ethernet in the First = Mile=20 (EFM))

   o  DSL=20 port state (e.g. synchronized/showtime, low power, no = power/=20
      idle)

   o =20 Actual net data rate (upstream/downstream)


While the protocol = draft says=20 the following:

         Following = sub-TLVs=20 are currently defined :

          . = Type=20 (DSL-Type =3D 0x91) : Defines the type of transmission system=20
          &nbs= p; =20 in use. This is a mandatory TLV.

          &nbs= p; =20 Length :  (4 bytes)  

          &nbs= p; =20 Value  : (Transmission system : ADSL1 =3D 0x01, ADSL2 =3D=20 0x02,    
          &nbs= p; =20 ADSL2+ =3D 0x03, VDSL1 =3D 0x04, VDSL2 =3D 0x05, SDSL =3D 0x06, = UNKNOWN=20
          &nbs= p; =20 =3D 0x07).

          . = Type=20 (Actual-Data-Rate-Upstream =3D 0x81) : Actual data rate=20
          &nbs= p; =20 upstream of a synchronized DSL line. This is a mandatory TLV.=20
          &nbs= p; =20 This rate value and all the subsequent ones account for the DSL=20
          &nbs= p; =20 overhead (i.e. signify the net rate).  

          &nbs= p;=20 Length  :  (4 bytes)

          &nbs= p;=20 Value   : (Rate in Kb/sec)

          . = Type=20 (Actual-Data-Rate-Downstream =3D 0x82) : Actual data rate=20
          &nbs= p; =20 downstream of a synchronized DSL line. This is a mandatory TLV.=20

          &nbs= p; =20 Length :  (4 bytes)

Regards,=20
Woj.=20


------_=_NextPart_001_01C82126.2FF7217D-- --===============0293529021== 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 --===============0293529021==-- From ancp-bounces@ietf.org Wed Nov 07 07:13:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpjmK-0007zp-2M; Wed, 07 Nov 2007 07:13:04 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IpjmI-0007yU-Em for ancp-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 07:13:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpjmI-0007xk-18 for ancp@ietf.org; Wed, 07 Nov 2007 07:13:02 -0500 Received: from exprod7og111.obsmtp.com ([64.18.2.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpjmE-0005E9-DB for ancp@ietf.org; Wed, 07 Nov 2007 07:13:01 -0500 Received: from source ([66.129.224.36]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Wed, 07 Nov 2007 04:12:28 PST Received: from proton.jnpr.net ([10.10.2.37]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 04:12:43 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ANCP] PORT UP Data Rate? Date: Wed, 7 Nov 2007 07:12:35 -0500 Message-ID: <9BD5D7887235424FA97DFC223CAE3C280B65500C@proton.jnpr.net> In-Reply-To: <4731843A.30207@alcatel-lucent.be> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] PORT UP Data Rate? Thread-Index: AcghH/7GTW3zYySvTTOnYYLYBQQt3gAFbufQ From: "Sanjay Wadhwa" To: "Stefaan DE CNODDER" , "Wojciech Dec (wdec)" X-OriginalArrivalTime: 07 Nov 2007 12:12:43.0509 (UTC) FILETIME=[80099A50:01C82137] X-Spam-Score: -4.0 (----) X-Scan-Signature: 1b2066b7e944cd0f55ca6d7a2077c2e4 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: , Content-Type: multipart/mixed; boundary="===============0968055189==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0968055189== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C82137.7A9F2814" This is a multi-part message in MIME format. ------_=_NextPart_001_01C82137.7A9F2814 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable The reported rate is "net data rate" (includes DSL overhead). The protocol draft explicitly mentions it: =20 . Type (Actual-Data-Rate-Upstream =3D 0x81): Actual data rate upstream = of a synchronized DSL line. This is a mandatory TLV. This rate value and all the subsequent ones account for the DSL overhead (i.e. signify the net rate). =20 -Sanjay =20 -----Original Message----- From: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be]=20 Sent: Wednesday, November 07, 2007 4:24 AM To: Wojciech Dec (wdec) Cc: ancp@ietf.org Subject: Re: [ANCP] PORT UP Data Rate? =20 =20 Woj, =20 It looks to me that the framework document is correct, and that the=20 protocol draft has to replace "data rate" by "net data rate" to make it=20 more accurate, i.e., for istance: =20 Type (Actual-Data-Rate-Upstream =3D 0x81) : Actual data rate upstream of = a synchronized DSL line... =20 should be =20 Type (Actual-Data-Rate-Upstream =3D 0x81) : Actual net data rate = upstream=20 of a synchronized DSL line... =20 The term "net data rate" is accurately defined in section 1.2 of the=20 framework document by referring to the ITU standard. =20 I hope we all have the same understanding of the definition of the=20 bandwidth advertised by ANCP. =20 regards, Stefaan =20 =20 =20 Wojciech Dec (wdec) wrote: =20 > Hi All, >=20 > Hopefully someone can clarify for me the meaning of the Actual data rate=20 > value in ANCP's PORT-UP messages, and also perhaps comment on their=20 > current implementations. Is this rate meant to be the rounded up=20 > effective transport capacity (deriving from various ADSL Transport=20 > Classes) or raw DSL modem speed? The difference between the two is=20 > primarily in the DSL PHY encoding overhead. >=20 > The framework and protocol drafts are not too clear on this matter, but=20 > seem to point more towards the former if anything. >=20 > For example the framework 03 draft currently reads in Section 3.1 as=20 > follows : >=20 > o The identification and speed (data rate) of the DSL Access Loop > (also known as the "DSL sync rate") >=20 > o The identification and speed (data rate) of the Remote > Terminal(RT)/Access Node uplink (when relevant) >=20 > The NAS can adjust downstream shaping to current Access Loop actual > data rate, and more generally re-configure the appropriate nodes of > its hierarchical scheduler (support of advanced capabilities > according to TR-101). >=20 > This use case may actually include more information than link > identification and corresponding data rates. In case of DSL Access > Loops, the following Access Loop characteristics can be sent to the > NAS (cf. ITU-T Recommendation G.997.1 [G.997.1]): >=20 > o DSL Type (e.g. ADSL1, ADSL2, SDSL, ADSL2+, VDSL, VDSL2) >=20 > o Framing mode (e.g. ATM, ITU-T Packet Transfer Mode (PTM), IEEE > 802.3 Ethernet in the First Mile (EFM)) >=20 > o DSL port state (e.g. synchronized/showtime, low power, no power/ > idle) >=20 > o Actual net data rate (upstream/downstream) >=20 >=20 > While the protocol draft says the following: >=20 > Following sub-TLVs are currently defined : >=20 > . Type (DSL-Type =3D 0x91) : Defines the type of = transmission=20 > system > in use. This is a mandatory TLV. >=20 > Length : (4 bytes) =20 >=20 > Value : (Transmission system : ADSL1 =3D 0x01, ADSL2 =3D = > 0x02, =20 > ADSL2+ =3D 0x03, VDSL1 =3D 0x04, VDSL2 =3D 0x05, SDSL =3D = 0x06,=20 > UNKNOWN > =3D 0x07). >=20 > . Type (Actual-Data-Rate-Upstream =3D 0x81) : Actual data = rate > upstream of a synchronized DSL line. This is a mandatory TLV. > This rate value and all the subsequent ones account for the=20 > DSL > overhead (i.e. signify the net rate). =20 >=20 > Length : (4 bytes) >=20 > Value : (Rate in Kb/sec) >=20 > . Type (Actual-Data-Rate-Downstream =3D 0x82) : Actual data rate > downstream of a synchronized DSL line. This is a mandatory=20 > TLV. >=20 > Length : (4 bytes) >=20 > Regards, > Woj. >=20 >=20 >=20 > ------------------------------------------------------------------------ >=20 > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www1.ietf.org/mailman/listinfo/ancp =20 =20 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp ------_=_NextPart_001_01C82137.7A9F2814 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

The reported rate is "net data rate" (includes DSL = overhead). The protocol draft explicitly mentions it:

 

. Type (Actual-Data-Rate-Upstream =3D 0x81): Actual data rate = upstream of a synchronized DSL line. This is a mandatory = TLV.

This rate value and all the subsequent ones account for the DSL overhead (i.e. signify the net = rate).

 

-Sanjay

 

-----Original Message-----
From: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be] =
Sent: Wednesday, November 07, 2007 4:24 AM
To: Wojciech Dec (wdec)
Cc: ancp@ietf.org
Subject: Re: [ANCP] PORT UP Data Rate?

 

 

Woj,

 

It looks to me that the framework document is correct, and that = the

protocol draft has to replace "data rate" by "net = data rate" to make it

more accurate, i.e., for istance:

 

Type (Actual-Data-Rate-Upstream =3D 0x81) : Actual data rate = upstream of a

synchronized DSL line...

 

should be

 

Type (Actual-Data-Rate-Upstream =3D 0x81) : Actual net data rate = upstream

of a synchronized DSL line...

 

The term "net data rate" is accurately defined in = section 1.2 of the

framework document by referring to the ITU = standard.

 

I hope we all have the same understanding of the definition of = the

bandwidth advertised by ANCP.

 

regards,

Stefaan

 

 

 

Wojciech Dec (wdec) wrote:

 

> Hi All,

>

> Hopefully someone can clarify for me the meaning of the = Actual data rate

> value in ANCP's PORT-UP messages, and also perhaps comment = on their

> current implementations. Is this rate meant to be the = rounded up

> effective transport capacity (deriving from various ADSL = Transport

> Classes) or raw DSL modem speed? The difference between the = two is

> primarily in the DSL PHY encoding = overhead.

>

> The framework and protocol drafts are not too clear on this matter, but

> seem to point more towards the former if = anything.

>

> For example the framework 03 draft currently reads in = Section 3.1 as

> follows :

>

>   o  The identification and speed (data = rate) of the DSL Access Loop

>       (also known as the = "DSL sync rate")

>

>    o  The identification and speed = (data rate) of the Remote

>       Terminal(RT)/Access = Node uplink (when relevant)

>

>    The NAS can adjust downstream shaping to = current Access Loop actual

>    data rate, and more generally = re-configure the appropriate nodes of

>    its hierarchical scheduler (support of = advanced capabilities

>    according to = TR-101).

>

>    This use case may actually include more information than link

>    identification and corresponding data rates.  In case of DSL Access

>    Loops, the following Access Loop = characteristics can be sent to the

>    NAS (cf. ITU-T Recommendation G.997.1 [G.997.1]):

>

>    o  DSL Type (e.g.  ADSL1, = ADSL2, SDSL, ADSL2+, VDSL, VDSL2)

>

>    o  Framing mode (e.g.  ATM, = ITU-T Packet Transfer Mode (PTM), IEEE

>       802.3 Ethernet in the = First Mile (EFM))

>

>    o  DSL port state (e.g. synchronized/showtime, low power, no power/

>       = idle)

>

>    o  Actual net data rate (upstream/downstream)

>

>

> While the protocol draft says the = following:

>

>          = Following sub-TLVs are currently defined :

>

>           = . Type (DSL-Type =3D 0x91) : Defines the type of transmission =

> system

>          &= nbsp;   in use. This is a mandatory TLV.

>

>          &= nbsp;   Length :  (4 bytes) 

>

>          &= nbsp;   Value  : (Transmission system : ADSL1 =3D 0x01, ADSL2 =3D =

> 0x02,   

>          &= nbsp;   ADSL2+ =3D 0x03, VDSL1 =3D 0x04, VDSL2 =3D 0x05, SDSL =3D 0x06, =

> UNKNOWN

>          &= nbsp;   =3D 0x07).

>

>           = . Type (Actual-Data-Rate-Upstream =3D 0x81) : Actual data = rate

>          &= nbsp;   upstream of a synchronized DSL line. This is a mandatory = TLV.

>          &= nbsp;   This rate value and all the subsequent ones account for the =

> DSL

>          &= nbsp;   overhead (i.e. signify the net rate).  =

>

>          &= nbsp;  Length  :  (4 bytes)

>

>          &= nbsp;  Value   : (Rate in Kb/sec)

>

>           = . Type (Actual-Data-Rate-Downstream =3D 0x82) : Actual data = rate

>          &= nbsp;   downstream of a synchronized DSL line. This is a mandatory =

> TLV.

>

>          &= nbsp;   Length :  (4 bytes)

>

> Regards,

> Woj.

>

>

>

> ------------------------------------------------------------------------<= o:p>

>

> = _______________________________________________<= /p>

> 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

------_=_NextPart_001_01C82137.7A9F2814-- --===============0968055189== 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 --===============0968055189==-- From ancp-bounces@ietf.org Wed Nov 07 07:27:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipk0K-0007hB-RS; Wed, 07 Nov 2007 07:27:32 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1Ipk0K-0007h5-Bt for ancp-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 07:27:32 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipk0J-0007eF-UT for ancp@ietf.org; Wed, 07 Nov 2007 07:27:31 -0500 Received: from smail5.alcatel.fr ([62.23.212.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ipk0I-00043r-Ux for ancp@ietf.org; Wed, 07 Nov 2007 07:27:31 -0500 Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.ad2.ad.alcatel.com [155.132.6.78]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id lA7CQBSV028813; Wed, 7 Nov 2007 13:26:11 +0100 Received: from [172.31.131.112] ([172.31.131.112]) by FRVELSBHS06.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Wed, 7 Nov 2007 13:27:27 +0100 Message-ID: <4731AF2E.8060803@alcatel-lucent.be> Date: Wed, 07 Nov 2007 13:27:26 +0100 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: Sanjay Wadhwa Subject: Re: [ANCP] PORT UP Data Rate? References: <9BD5D7887235424FA97DFC223CAE3C280B65500C@proton.jnpr.net> In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C280B65500C@proton.jnpr.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Nov 2007 12:27:27.0183 (UTC) FILETIME=[8EBF8DF0:01C82139] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 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 net data rate does not include DSL overhead (I understand DSL overhead as being the overhead at PHY level, but not the ATM overhead or EFM overhead). See mail of Kirubaharan. So if net data rate is 4 Mbps, then ATM cells can be transported over the DSL line at a rate of 4 Mbps. regards, Stefaan Sanjay Wadhwa wrote: > The reported rate is "net data rate" (includes DSL overhead). The > protocol draft explicitly mentions it: > > > > . Type (Actual-Data-Rate-Upstream = 0x81): Actual data rate upstream of > a synchronized DSL line. This is a mandatory TLV. > > /This rate value and all the subsequent ones account for the DSL > overhead (i.e. signify the net rate)./ > > / / > > -Sanjay > > > > -----Original Message----- > From: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be] > Sent: Wednesday, November 07, 2007 4:24 AM > To: Wojciech Dec (wdec) > Cc: ancp@ietf.org > Subject: Re: [ANCP] PORT UP Data Rate? > > > > > > Woj, > > > > It looks to me that the framework document is correct, and that the > > protocol draft has to replace "data rate" by "net data rate" to make it > > more accurate, i.e., for istance: > > > > Type (Actual-Data-Rate-Upstream = 0x81) : Actual data rate upstream of a > > synchronized DSL line... > > > > should be > > > > Type (Actual-Data-Rate-Upstream = 0x81) : Actual net data rate upstream > > of a synchronized DSL line... > > > > The term "net data rate" is accurately defined in section 1.2 of the > > framework document by referring to the ITU standard. > > > > I hope we all have the same understanding of the definition of the > > bandwidth advertised by ANCP. > > > > regards, > > Stefaan > > > > > > > > Wojciech Dec (wdec) wrote: > > > >> Hi All, > >> > >> Hopefully someone can clarify for me the meaning of the Actual data rate > >> value in ANCP's PORT-UP messages, and also perhaps comment on their > >> current implementations. Is this rate meant to be the rounded up > >> effective transport capacity (deriving from various ADSL Transport > >> Classes) or raw DSL modem speed? The difference between the two is > >> primarily in the DSL PHY encoding overhead. > >> > >> The framework and protocol drafts are not too clear on this matter, but > >> seem to point more towards the former if anything. > >> > >> For example the framework 03 draft currently reads in Section 3.1 as > >> follows : > >> > >> o The identification and speed (data rate) of the DSL Access Loop > >> (also known as the "DSL sync rate") > >> > >> o The identification and speed (data rate) of the Remote > >> Terminal(RT)/Access Node uplink (when relevant) > >> > >> The NAS can adjust downstream shaping to current Access Loop actual > >> data rate, and more generally re-configure the appropriate nodes of > >> its hierarchical scheduler (support of advanced capabilities > >> according to TR-101). > >> > >> This use case may actually include more information than link > >> identification and corresponding data rates. In case of DSL Access > >> Loops, the following Access Loop characteristics can be sent to the > >> NAS (cf. ITU-T Recommendation G.997.1 [G.997.1]): > >> > >> o DSL Type (e.g. ADSL1, ADSL2, SDSL, ADSL2+, VDSL, VDSL2) > >> > >> o Framing mode (e.g. ATM, ITU-T Packet Transfer Mode (PTM), IEEE > >> 802.3 Ethernet in the First Mile (EFM)) > >> > >> o DSL port state (e.g. synchronized/showtime, low power, no power/ > >> idle) > >> > >> o Actual net data rate (upstream/downstream) > >> > >> > >> While the protocol draft says the following: > >> > >> Following sub-TLVs are currently defined : > >> > >> . Type (DSL-Type = 0x91) : Defines the type of transmission > >> system > >> in use. This is a mandatory TLV. > >> > >> Length : (4 bytes) > >> > >> Value : (Transmission system : ADSL1 = 0x01, ADSL2 = > >> 0x02, > >> ADSL2+ = 0x03, VDSL1 = 0x04, VDSL2 = 0x05, SDSL = 0x06, > >> UNKNOWN > >> = 0x07). > >> > >> . Type (Actual-Data-Rate-Upstream = 0x81) : Actual data rate > >> upstream of a synchronized DSL line. This is a mandatory TLV. > >> This rate value and all the subsequent ones account for the > >> DSL > >> overhead (i.e. signify the net rate). > >> > >> Length : (4 bytes) > >> > >> Value : (Rate in Kb/sec) > >> > >> . Type (Actual-Data-Rate-Downstream = 0x82) : Actual data rate > >> downstream of a synchronized DSL line. This is a mandatory > >> TLV. > >> > >> Length : (4 bytes) > >> > >> Regards, > >> Woj. > >> > >> > >> > >> ------------------------------------------------------------------------ > >> > >> _______________________________________________ > >> 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 > _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Wed Nov 07 08:03: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 1IpkZQ-0005Ed-Ll; Wed, 07 Nov 2007 08:03:48 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IpkZP-00059W-CH for ancp-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 08:03:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpkZO-00057q-R0 for ancp@ietf.org; Wed, 07 Nov 2007 08:03:46 -0500 Received: from mail1.telekom.de ([62.225.183.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpkZB-0007AQ-Vv for ancp@ietf.org; Wed, 07 Nov 2007 08:03:46 -0500 Received: from S4DE8PSAANQ.mitte.t-com.de by mail5.telekom.de with ESMTP; Wed, 7 Nov 2007 14:00:29 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Nov 2007 14:00:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: AW: [ANCP] PORT UP Data Rate? Date: Wed, 7 Nov 2007 14:00:26 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1C594C5C@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [ANCP] PORT UP Data Rate? thread-index: Acgfj0lsR0JKUCfKQJCLErysQNwWPwBiVNWAAAeOIIA= References: From: "Haag, T" To: , X-OriginalArrivalTime: 07 Nov 2007 13:00:28.0846 (UTC) FILETIME=[2BE954E0:01C8213E] X-Spam-Score: 1.4 (+) X-Scan-Signature: 1151ecb403865cbf3d4520d716cc1c0a Cc: "Freudenberger, Markus" 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="===============1857441070==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============1857441070== Content-class: urn:content-classes:message Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C8213E.2B46391A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8213E.2B46391A Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C8213E.2B46391A" ------_=_NextPart_002_01C8213E.2B46391A Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable Woj, =20 Referring to Table 1, WT147 DSLForum as well as TR-101 Table 3 the = definition looks like the following table.=20 =20 Both tables are the same to be consistent between requirements of PPPoE = intermediate/DHCP relay agent and Layer 2 Control. From my understanding = there should not be a range for interpretation because ITU G.99x defines = the meaning of the referred rates. =20 Pos. Message Type Information Reference=20 1 DSL Type: ADSL Transmission System Which DSL type is in use (e.g. ADSL1, ADSL2, SDSL, ADSL2+, VDSL, VDSL2...) This parameter defines the transmission system in use Not described=20 ITU-T G.997.1=20 Section 7.5.1.1 2 DSL Port State Port up (showtime)/ port down (idle or silent) ITU-T G.997.1 Section 7.5.1.5 3 Actual data rate Up- and Downstream Actual data rate upstream and downstream of a synchronized DSL port ITU-T G.997.1 Section 7.5.2.1 4 Attainable Data Rate Up- and Downstream Maximum data rate which can be achieved. ITU-T G.997.1 Section 7.5.1.19 and 7.5.1.20 =20 5 Minimum Data Rate minimum data rate desired by the operator in kbit/s (up/down) ITU-T G.997.1=20 Section 7.3.2.1.1 6 Maximum Data Rate maximum data rate desired by the operator in kbit/s. (up/down) ITU-T G.997.1 Section 7.3.2.1.3 7 Minimum Data Rate in low power state minimum data rate desired by the operator during the low power state = (L1/L2).=20 ITU-T G.997.1 Section 7.3.2.1.5 8 Maximum Interleaving Delay maximum one-way interleaving delay ITU-T G.997.1 Section 7.3.2.2 9 Actual interleaving Delay Value in milliseconds which corresponds to inter leaver setting. ITU-T G.997.1 section 7.5.2.3 =20 Referring now to the open question of: What does "data rate" mean? ITU-T = G.997.1 Section 7.5.2.1 gives the following definition: 7.5.2.1 Actual Data Rate This parameter reports the actual net data rate the bearer channel is = operating at excluding rate in L1 and L2 states. In L1 or L2 states, the = parameter contains the net data rate in the previous L0 state. The data = rate is coded in bit/s. =20 Now considering the meaning of net data rate: G.997.1 referres in chapter 3 Definitions to the relevant DSL standards: =20 3.5 net data rate: Net data rate is defined in = G.992.x-series Recommendations. =20 That means that the net data rate differs. =20 For ADSL2: G.992.3 3.28net data rate: The sum of all frame bearer data rates over all = latency paths in any one direction. Table 5-1/G.992.3 - Data rate terminology and definitions Data rate Equation (kbit/s) Reference point Net data rate =20 (see Table 7-7) =E1, =E2 Aggregate data rate =3D Net data rate + Frame overhead rate (see Table 7-7) A Total data rate =3D Aggregatedata rate + RS Coding overhead rate =20 (see Table 7-6) B, C, =E4 Line rate =3D Total data rate + Trellis Coding overhead rate =20 (see Table 8-4) U =20 =20 For VDSL2 G.993.2 provides appropriate definitions. These definitions = are dependent on the used TC layer. For more details G.993.2 is = recommended. =20 Regards =20 Thomas=20 ________________________________ Von: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Gesendet: Mittwoch, 7. November 2007 09:47 An: Wojciech Dec (wdec); ancp@ietf.org Betreff: RE: [ANCP] PORT UP Data Rate? =20 Hi Folks, =20 can anyone reply? To put the question in other words, if ANCP signals a = line rate of downstream rate of 4Mbps, is this the effective ATM VC or = Ethernet "circuit" data carrying capacity, or is it the raw modem rate = which does not include DSL PHY overheads? The text should be *very* = clear about this. =20 -Woj. =20 =09 ________________________________ From: Wojciech Dec (wdec)=20 Sent: 05 November 2007 10:36 To: ancp@ietf.org Subject: [ANCP] PORT UP Data Rate? Hi All,=20 Hopefully someone can clarify for me the meaning of the Actual data = rate value in ANCP's PORT-UP messages, and also perhaps comment on their = current implementations. Is this rate meant to be the rounded up = effective transport capacity (deriving from various ADSL Transport = Classes) or raw DSL modem speed? The difference between the two is = primarily in the DSL PHY encoding overhead. The framework and protocol drafts are not too clear on this matter, but = seem to point more towards the former if anything.=20 For example the framework 03 draft currently reads in Section 3.1 as = follows :=20 o The identification and speed (data rate) of the DSL Access Loop=20 (also known as the "DSL sync rate")=20 o The identification and speed (data rate) of the Remote=20 Terminal(RT)/Access Node uplink (when relevant)=20 The NAS can adjust downstream shaping to current Access Loop actual=20 data rate, and more generally re-configure the appropriate nodes of=20 its hierarchical scheduler (support of advanced capabilities=20 according to TR-101).=20 This use case may actually include more information than link=20 identification and corresponding data rates. In case of DSL Access=20 Loops, the following Access Loop characteristics can be sent to the=20 NAS (cf. ITU-T Recommendation G.997.1 [G.997.1]):=20 o DSL Type (e.g. ADSL1, ADSL2, SDSL, ADSL2+, VDSL, VDSL2)=20 o Framing mode (e.g. ATM, ITU-T Packet Transfer Mode (PTM), IEEE=20 802.3 Ethernet in the First Mile (EFM))=20 o DSL port state (e.g. synchronized/showtime, low power, no power/=20 idle)=20 o Actual net data rate (upstream/downstream)=20 =20 While the protocol draft says the following:=20 Following sub-TLVs are currently defined :=20 . Type (DSL-Type =3D 0x91) : Defines the type of transmission = system=20 in use. This is a mandatory TLV.=20 Length : (4 bytes) =20 Value : (Transmission system : ADSL1 =3D 0x01, ADSL2 =3D = 0x02, =20 ADSL2+ =3D 0x03, VDSL1 =3D 0x04, VDSL2 =3D 0x05, SDSL =3D = 0x06, UNKNOWN=20 =3D 0x07).=20 . Type (Actual-Data-Rate-Upstream =3D 0x81) : Actual data = rate=20 upstream of a synchronized DSL line. This is a mandatory = TLV.=20 This rate value and all the subsequent ones account for = the DSL=20 overhead (i.e. signify the net rate). =20 Length : (4 bytes)=20 Value : (Rate in Kb/sec)=20 . Type (Actual-Data-Rate-Downstream =3D 0x82) : Actual data = rate=20 downstream of a synchronized DSL line. This is a mandatory = TLV.=20 Length : (4 bytes)=20 Regards,=20 Woj.=20 =20 ------_=_NextPart_002_01C8213E.2B46391A Content-Type: text/html; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable PORT UP Data Rate?

Woj,

 

Referring to = Table 1, WT147 DSLForum as well as TR-101 Table 3 the definition looks like the following table.

 =

Both tables are = the same to be consistent between requirements of PPPoE intermediate/DHCP relay = agent and Layer 2 Control. From my understanding there should not be a range = for interpretation because ITU G.99x defines the meaning of the referred = rates.

 =

Pos.

Message Type

Information

Reference

1

DSL Type: ADSL Transmission = System

Which DSL type is in = use

(e.g. ADSL1, ADSL2, SDSL, ADSL2+, VDSL, = VDSL2…)

This parameter defines the transmission = system in use

Not described

ITU-T G.997.1

Section = 7.5.1.1

2

DSL Port State

Port up (showtime)/ port down (idle or = silent)

ITU-T G.997.1 Section = 7.5.1.5

3

Actual data rate Up- and = Downstream

Actual data rate upstream and downstream of = a synchronized DSL port

ITU-T G.997.1

Section = 7.5.2.1

4

Attainable Data Rate Up- and = Downstream

Maximum data rate which can be = achieved.

ITU-T G.997.1 Section = 7.5.1.19 and 7.5.1.20

 

5

Minimum Data = Rate

minimum data rate desired by the operator = in kbit/s (up/down)

ITU-T G.997.1

Section = 7.3.2.1.1

6

Maximum Data = Rate

maximum data rate desired by the operator = in kbit/s. (up/down)

ITU-T G.997.1

Section = 7.3.2.1.3

7

Minimum Data Rate in low power = state

minimum data rate=A0 desired by the = operator during the low power state (L1/L2).

ITU-T G.997.1

Section = 7.3.2.1.5

8

Maximum Interleaving = Delay

maximum one-way interleaving = delay

ITU-T G.997.1

Section = 7.3.2.2

9

Actual interleaving = Delay

Value in milliseconds which corresponds to = inter leaver setting.

ITU-T G.997.1

section = 7.5.2.3

 =

Referring now to = the open question of: What does “data rate” mean? ITU-T G.997.1 = Section 7.5.2.1 gives the following definition:

7.5.2.1  Actual Data Rate

This parameter reports the actual net data = rate the bearer channel is operating at excluding rate in L1 and L2 states. In L1 = or L2 states, the parameter contains the net data rate in the previous L0 = state. The data rate is coded in bit/s.

 

Now considering the meaning = of net data rate:

G.997.1 referres in chapter 3 Definitions to = the relevant DSL standards:

 

3.5           = ;   net data rate: Net data rate is defined in = G.992.x-series Recommendations.

 

That means that the net data rate = differs.

 

For ADSL2: = G.992.3

3.28net data = rate: The sum of all frame bearer data rates over all latency = paths in any one direction.

Table 5-1/G.992.3 – Data rate = terminology and definitions

Data rate

Equation = (kbit/s)

Reference = point

Net data = rate


(see Table 7-7)

=E1, =E2

Aggregate data = rate =3D Net data rate + Frame = overhead rate

(see Table 7-7)

A

Total data = rate =3D Aggregatedata rate + RS = Coding overhead rate


(see Table 7-6)

B, C, =E4

Line = rate =3D Total data rate + Trellis = Coding overhead rate


(see Table 8-4)

U

 

 

For VDSL2 G.993.2 provides appropriate = definitions. These definitions are dependent on the used TC layer. For more details G.993.2 = is recommended.

 =

= Regards

 =

= Thomas

Von: = Wojciech Dec (wdec) [mailto:wdec@cisco.com]
Gesendet: Mittwoch, 7. = November 2007 09:47
An: Wojciech Dec (wdec); ancp@ietf.org
Betreff: RE: [ANCP] PORT = UP Data Rate?

 

Hi Folks,

 

can anyone reply? To put the question in other words, = if ANCP signals a line rate of downstream rate of 4Mbps, is this the = effective ATM VC or Ethernet "circuit" data carrying capacity, or is it = the raw modem rate which does not include DSL PHY overheads? The text should = be *very* clear about this.

 

-Woj.

 

From: Wojciech Dec (wdec)
Sent: 05 November 2007 = 10:36
To: ancp@ietf.org
Subject: [ANCP] PORT UP = Data Rate?

Hi All,

Hopefully someone can clarify for me the meaning of the Actual = data rate value in ANCP's PORT-UP messages, and also perhaps comment on their = current implementations. Is this rate meant to be the rounded up effective = transport capacity (deriving from various ADSL Transport Classes) or raw DSL modem = speed? The difference between the two is primarily in the DSL PHY encoding = overhead.

The framework and protocol drafts are not too clear on this = matter, but seem to point more towards the former if anything. =

For example the framework 03 draft currently reads in Section 3.1 = as follows :

  o  The identification and speed = (data rate) of the DSL Access Loop
      (also known as = the "DSL sync rate") =

   o  The identification and = speed (data rate) of the Remote
      = Terminal(RT)/Access Node uplink (when relevant) =

   The NAS can adjust downstream = shaping to current Access Loop actual
   data rate, and more generally re-configure the appropriate nodes of
   its hierarchical scheduler = (support of advanced capabilities
   according to = TR-101).

   This use case may actually = include more information than link
   identification and corresponding = data rates.  In case of DSL Access
   Loops, the following Access Loop characteristics can be sent to the
   NAS (cf. ITU-T Recommendation = G.997.1 [G.997.1]):

   o  DSL Type (e.g.  = ADSL1, ADSL2, SDSL, ADSL2+, VDSL, VDSL2) =

   o  Framing mode (e.g.  = ATM, ITU-T Packet Transfer Mode (PTM), IEEE
      802.3 Ethernet = in the First Mile (EFM)) =

   o  DSL port state (e.g. synchronized/showtime, low power, no power/
      = idle)

   o  Actual net data rate (upstream/downstream) =

 

While the protocol draft says the following:

         Following sub-TLVs are currently defined :

          . Type (DSL-Type =3D 0x91) : Defines the type of transmission system =
           &= nbsp; in use. This is a mandatory TLV.

           &= nbsp; Length :  (4 bytes)  

           &= nbsp; Value  : (Transmission system : ADSL1 =3D 0x01, ADSL2 =3D 0x02,    
           &= nbsp; ADSL2+ =3D 0x03, VDSL1 =3D 0x04, VDSL2 =3D 0x05, SDSL =3D 0x06, UNKNOWN =
           &= nbsp; =3D 0x07).

          . Type (Actual-Data-Rate-Upstream =3D 0x81) : Actual data rate =
           &= nbsp; upstream of a synchronized DSL line. This is a mandatory TLV. =
           &= nbsp; This rate value and all the subsequent ones account for the DSL =
           &= nbsp; overhead (i.e. signify the net rate).   =

            Length  :  (4 bytes)

            Value   : (Rate in Kb/sec)

          . Type (Actual-Data-Rate-Downstream =3D 0x82) : Actual data rate =
           &= nbsp; downstream of a synchronized DSL line. This is a mandatory TLV. =

           &= nbsp; Length :  (4 bytes)

Regards,
Woj. =

 

------_=_NextPart_002_01C8213E.2B46391A-- ------_=_NextPart_001_01C8213E.2B46391A Content-Type: application/octet-stream; name="oledata.mso" Content-Transfer-Encoding: base64 Content-ID: Content-Description: oledata.mso Content-Location: oledata.mso ABYAAHic7dd3UFPb1gDw0JsgJXSkSBHpXSDSW0A6KL3JBZFQAwLSFQTpIlIFIihdBKQoEJogvUZ6 70GkSTEYhLzDvb43b97Mfd/1z/fNXWd+s5KdZK99ss9ZmQwP0SzmVbEsgf4jFEEEoDMcGYj438bw fvo9qEEg/J/Pz3A43D+HcX/H/1ScAs5+IgT2jwhwvuckAFIA2c/9/Tv+f4YxyBM4fEGcIA2QB5Dh oPv/2Qr+azAAV8w/58L/P97rNekuoMjVjUcAPFam/GPMDiQOkgBJA4ccSAogARxyv1CfCehC/34+ f/Vz2QR/Vl8SJPZr9fHOe+D5dH+1/kVAEOGf1xf/tfq/fP5cgOWf9c/Xjv9z/X92/5MDKAAXAOfb RgX6oycAPwEgGgAtgA4ABtCDzq8JEIjx97WBQMwAFgArgA1wCcAO4ABw/pznMpC5ATwAXgAf4AqA H3AVIAAQBAgBhAEiAFHA+T6df1cSAEmAFOjvXvWrcb6ZAdnbZjBoigNYcfdkAG7S55TuQHSDf6NO RNM1kt6JdlRAWsfk9nSHRmMxomdDS8Neg/YWeDlJir/ByDevWKySwihMgJ8fe1NFacvgFAr9UI4O XoCwMogLx7ZW5yigm7YU0EhIuudQ7vRCNvLp9zRiQ8W74BjLu+qz2YZuhvLJpitQKZYEPa3ozy35 ipUap1Ha5Ny4yUIHbJCpugrSF26MRxR+D8xuTh6qvXK1RAldz959BZWxK5Fu1rm7bW4uzh3Wy533 tYGh7CrsLuQ+SYFkrhuPBlIpJtRT6OOhaDQulLwtUWdaxuXU8QUCxok2zMfeD6t9Kl3gT+/RwpJ2 QUWJcjxMb6oPbNRiJbRbT+w1wEGmT2wVs5vBT5Rd+i3BWFYXp8TF4LQffgwNmVTwDoMtpUEoGmTk B03ZsryP/SwwfVkDzS5obBSK9uTzRGJSiAWCA2nZvBKhzOMiI/mNZP2MMPj115tjRF8ixhqqX9S1 vTx5iHenDvaGRkcw9gQdvxdLaT11KLfr6o7UMEihspldHawI2Go5WoUeNd1YgxRVuHoMWYGtW0d+ +I2MEzxwnElbmx/qgfjoiQp8Cf7qtbuGzI2fp4i7SDztuv7bauG2pczBGvKh/1L1p03yuUyKCYWW 5Oy5kHtwuplLfSSDN9i7aubVaWcjbiAIK7joakQ7DBRS4m8OgsvitZ3p7bWhig95072K65+dhZTA 371KduTUYxXPkkht9m2Whqa32kCV0qUkEzGvUCxJtia0VHnQqAtzdk5miLsOFIKpDNqfPzqEOXlB pEWcOITqJsrigliuhQ+ga+ujwqofZX46cG+63LX3LcS8FNtIlbpw42iyp6KjB29Ies3qx9xp7CRD NLPAhnztqDK7LztHqR0opLtcE0K7ST7INdoi5XX/Mivdq7ZN3KdDCHYgIJBOXEvzOk2XSczQbrl/ Q1PCYP6LBboXiK4UsScHEUEdwVIrxhRaqt1rJaixqcboAJmS6oT+9qlLH0TkULO2TbG13h6T0LHK UANUwqDG6N2O9CcSZbLWFUGn15c9M0N2T5QyORTEOXTTlOH2AiSyVBllXgxilLL0LrUZlry1szal O5K+DkKpjZ3Mb/ki+dxUnws5dLNf61GwrdSfdlG5mkHmsIof1Hqzk3zqa11RD18QwwnIRP7BxIP0 B+hw9IOi8KLwK+A6Akh4eavMIs0jrQddDwZaGexTPoS0Oi+KLF7rQjZxCuH/0ZQFgIwPZD4gEwL5 MpCJgcx+/jr17/cvo7sLm8bhtpuiaEzPkZpaDXxdyyXfn0+vsqc2Miqr5hFPobZ6uXBDzzavlb+/ TKNPDIyGNZLaSJVeeBlxy1DQUqOMVCfSvIAfamn4GFtG/4NG5VCLIpYH/Xxq7ot3p1fMWcmq8K7z +sBzTO1u01Sjr3jw9zEM7I0yVU3Ehb7Pxvy9+dqK5MX4nGeBcjn6JKuHxLOGlZHmiy3tqmFC+12U xzg1JcNgJvUXdLps7l4+Vm2lXpJgZ9dcDIGEAWHI4MxO77pCqMzUcGhX+tN+DMXDXDjHxos32ndk IsOhU2erQR4UhFhMPo7Y3KWLms2m+kyvGIFR3tFvxsqFoRB9zfMETKc8lm+pTitv4ZwWbKn6zoJW HIcJAk4ZudM40/CTxJWZb8vdJlrWe5zK+Qbk7UHndhjHSi/GqK2tH/rMzhx5D7sWkhQ8LYFRPsrk lqQcCoO7eDscOggrBIkdDdsfH3GUhtmUNmE/+gd1haXtDfRxiWJ8YDiGH59Hotw3h3nifBMLwIVG kig2GLjEd1c5ig8laN6RteQ6U1/lFifCMIg8sPc8Sa6IT0LbQXPDMHtVWIKhHNe4Twy5A2bLMXf6 0xP9akKbq7f7SV7jhrfeMeaGVmxPryvNz5++/t67MffcSjB3871PXsmBFmZAPsjOc0AhZCHYFIUM 8JgBv4MUk9imB19yEe68LJskQpO568DbnXLd2uv55Fqqsc7DzAmiY93L1oSIj69cEbfSlgSvdPW8 1EDe3owVyOuc6BK8S3XHk1Oz8sfmYzPv7CK2QLCM/IblJI9w3onB/jiK16Gd7M0zMHUxi1cCV2l7 BzsP8hYbtiFocbrj9PE8xvLlnqjAfekmbl+d6avIuR3aFtw3B7RZm4r+2erFsY36rZO0S41j4TMo zqADfaYIMH/AgcvkqS4yOvB0LMD2nepvl05F4wNkOTqvO5RjcbDja9iDniI7cjUKQXQKT+fC231X GB662F+hvih9qcF6EU4irXbvctOm+isESywZ7llRrnVPepBlltAqm7BHpSL0uGFmwud+TiB8G2cz LeyT2Jy6ZVcyuH5QG2bZsaZmtzOLcoWLzy+g71SoO6tfwq3uQ7L846iPbRQOPMo6bKjEBAOfqEO3 w7+IjS0Khgoc05KezZzOkVSYWkiVMGXtdMKqHfvuUct+ncpV7p4S3lvetvpomsZjQa59Pf8pMuHF To/HE0Fe/nYLRHG71/uHuo9gI7RwOORJyhG/uytet5SM37C0ydzRbxrQmCRYYudohw1Nl3G/eZIa xhFS442rEin94quqZxqpk0RpkjPtLehk1dBAQaYbkq1BtylW+7GJ1iCTzBtKWntM1p5npFalJSXZ W0x/05fBzDh+v11xalxT0wLpPUld82VL7Zm462tfVbOUTAJt17fFLxXyOp/7dbAIp+WVg3V0P1l6 ZO5VSU6/dAlkrKV8lGBiZaY5Wjje+lt0fQOLE1OEbFRbXmG+lvsYas76+6W6wo3sjUedpp02S0Fu LaU8Uj6v2rEUIAvNpgMvWTHuf/UfXaubh7MnLhTuDxgyBMXMl0jwGB6gOhOc2rgqKZ3i8WbYPuiW cfIO7xvZj8nGZlBxc4qwcvVdzvGRuCbtVtwDrt5PLrBiiBokzMm64Gs0yi/AI0IRMn+C7WVRRunj +r1s9XfrMTn+zTty6PlEu/QF+fuKt2kZVOTFFn8jUN6oigpYVSYO/16f4mSBkWgkvwjupztcwRi2 JqmGWj/CKYHDk6/zGarKMHWbk6x/LLfXCCAlpJA2OMFjb59tmDsKfH6lglcHkcG+onwhh3RWwYnR VCXTQF5B5QLTfezKtr/D4jhC+0dFFMvtaCqBkHEO1cNP7FBYt9Xps5bsImZbT6qYULmqVcXDiIoz SWQTOPtH88jIHIHLaRwplu4CiMURRKZytU35oQphxAMIvvJgGCt5mcKKCuHTuMkwo1CoqIFW3ZFb GNYkIQSRX1Ej+fUoKa7oikAuqjqikfUbY4/BgukPGQ4IBOvkvGLweEue22/tbHna7kao3yaiRHKc tU+vd2uauFzbU4p/TPuqtYATvchr789ruTwlDjLbquVFGhNEObsKmem2gQXY5cnk/SXMDVto991d vRm30WG33NkfW4JRjqnMzzVlCo8oM8hjSVrez04jZBgD0bNpZpRdgk/VrhHJ3HHLMHQyyBzqGHMf igvgwXVqnW1+pjC65fqukd3FBlVv9UXRmLS9o6CLGZtoiu+TFUUx7u15t4DQ/traJv4z1YzYF6a0 xnuwp0SKV+vsGzkjDb0/2D9ePBrReUu36f6Q4QNDtA291v1XlSawUn6JiSd8Fu2fm+OGBpN8ZHyN CiYvRrweti6XvKXy6dbbYRFqCjgFOusbte/chLEsjl3zTZY+PSY/IfvdV+d+zEIw6nvfi1wvVFeQ IfUQ8/y1oclywtE0+U6NO2rCUuFp2dcDUacXVtl6V+4k2OaQ955shElheefFAsmaN3EVSwsbGD6E uVJVwPdg1VnZlWQzzSg4T4YN3F3//RXG4tnLIfcsmiQqXmtb2L8eZ1lE7I/yMn6Fu2/AlHrzLPR3 4N90kNUTUYWyQUqLa9Nos6c3NnVWc5pI/eFH956nB8HabFdN2BhmThixVCZUp09lj/n87wa/84bf cw4c//SGm/jM17ybhtn/CohpNZD5g2zdsLWnQFmhJDb1i6b3rtKyMYc1b4Wlz7fby4iCnoQwZPHm vIaT4wbLdC/65bI1U7xmxZILMRdxDM0cV4e6gzJXubz9QxooaQF6hx1+n7Ou1zGG6D2E3csfP9k5 BzSrSUVMuqDAbOUWeG1bOdrEd1OybWll4frC6Eh66WnVyYjJZ+Z3Tty9WRbTgRdzj1+tt/YPe2mp eB2/5401SrK+bQAt89uYPihQFUpdX4eIJtvHI/ubvxnHt8bcpNUbPkvJ6n458jD5KLR0l9ldWdBj 7gnzXOorSEqqUG6bwNJ8hOfjxBh42EaVQcwzBCtbar8L/KA1V1iN6rMpbm+s0vmLPGwk2e5tJC9q 1i9a0tmzQslne9hHpk7R2u37vehBmpOxPKYZpPBNv0OvmegvCzoXkZYeTd99wn1tHYM+jCzMGHeU Srak2o9/a9zTc2fuqCaI1+EpM6i9gKmpUa/LFFaAzeyYBwYaxXB+xFXJVTU0Qa6bUF27raZhNk+m Gpt24DhBKOePI3YHGTf+tf/h/6vxDwXcrHE= ------_=_NextPart_001_01C8213E.2B46391A Content-Type: application/x-ms-wmz; name="image001.wmz" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.wmz Content-Location: image001.wmz H4sIAAAAAAACC7t+9tgsBghgb2D6zwFi5EUxMnAyMDD/ALKZGGTAkqxAzMkEYzExMkJZjEz///8H s/QYJaBi3HB1PEwNTAzsQkCWGhs/gxTDf5BiBgEg/wCQtQ6ID7ABdQLVc0PV8DD4JpZkhFQWpDIw FIDt/s104C/EgRNAljKxMDEIBFfmJuXnMJQ7AAX+s3Dd8gn+Wh4KxIxgdQYMLEBSF8gBeceI6yej OQNI5mklxLwH/5DMYwCZF5KZm1qs4JdarhCUn5uYx4DdPEYw/QEoyAU2l4EpkgXkywK9xOQSqFsb yDSbAWo2OOSBZi9gFGRiBrL8UkuSuaBhwwUOP4g+iG0CDOxg3h5wiDMyMSkFVxaXpOaCeCBdLGBZ RijG5hNmaOQzAABUKT1qCQIAAA== ------_=_NextPart_001_01C8213E.2B46391A Content-Type: image/gif; name="image002.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image002.gif Content-Location: image002.gif R0lGODlhSwAbAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAIABQBE ABQAgwAAAAAAAAYFBQoICQgHBwsJCgMDAwUEBAsKCgkHCAcGBgwKCwkICAECAwECAwECAwS3UIRJ awU46827/580hAFonuhHBIRXlBoVX2mtsh686Rlv/5tBQFCb7EA+4EdIRJV4yZgyVTAcECeYDmoE 0KYgRKCQ7WG2Zi8YlRiVz/AzLbrWDFpOKfpYV28QCkU7e1J9SQILgnx+fk9yXkldkE+SAApkTl+M kz1ccXGOjRptHwsGfRyEcqFpAHcgDIGohZtam36ApQwBCbMzn6K2fgcWxRNuvmqSWjLLAQrGxpjJ dMnWwNfZnEoRADs= ------_=_NextPart_001_01C8213E.2B46391A Content-Type: image/gif; name="image003.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image003.gif Content-Location: image003.gif R0lGODlhewAbAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAIAAQB3 ABcAgwAAAAAAAAwKCwoICQkICAgHBwsKCgYFBQsJCgcGBwcGBgUEBAMDAwkHCAECAwECAwT/EMhJ qwXo6s27/+CWhZcwkGiqrhMisAABz3Qdw4Wt72C+GjKecEghIA6BpHK5rBiJUCFChjxpkJXEKMql IRSSQsBnQQQqYEmSouymmGw4SLCYiMmVM4XBznP0bn2CaoMegAADAQcfh2sThxaQbpIAgI0hkImL HZeWcXpNQpSVF56PmGUMCwZ/gqCnhKREo5SWoWq3hRMGAVulrrGVoaMktBq1sJKmuhINVht8sKTL 0iyQTI7V0tSy3RPRFAN4GgovwcLa3WvZj7ZnbZHHv8HX6Wm79xwFW/X0hKCvkskKGE9eoUvt2ElA kKDCAXMdBoyAd45iNm5t+hU8lsuiI2IIV54BUOCLA5Aa1F5p7EKMAKtmIisIANcMJcGBOL1xIdZg gjgOBPLdoPHOVJOLxHZQdCLBgFAKAggE6Am1pIqkgVYMMLcAm9eYGIhm5TFCgVevVokqHFsjAgA7 ------_=_NextPart_001_01C8213E.2B46391A Content-Type: application/x-ms-wmz; name="image004.wmz" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image004.wmz Content-Location: image004.wmz H4sIAAAAAAACC7t+9tgsBjBIYGtgYuAEsT5GMYIYzI2MDAxMDDJgWVYg5mSCsZgYGaEsRqb///+D WXqMElAxbrg6HqYGpgQ2ISBLjY2fQYrhP0gxgwCQfwDIWgbECmxAOaB6bqgaHgbfxJKMkMqCVAaG ArDdv5lW/b0AdsMEkKVMLEwMAsGVuUn5OQzlDkCBJexcZ3yCv5aHAjEjWJ0BAwuQ1AVyOIC0Edd8 RnMGkIxGJTHmvWXluo7dPEYw/QHJXFEWkApNqLkL/jEgzGUAmRuSmZtarOCXWq4QlJ+bmMeAy50Q cxmh5i5gbGQFqTCphPEDmUB8H6g9D8i0B939PxhtmEEqArC5H1s4nyPW/R3gcNkCNffAXwb84X2T OPcyMvWB4/FpJRc0tXCBUxREF8QuAQZ2MG8POA0yMjEpBVcWl6TmgnggXSwMMIDLD8wwBQCHObrx GwMAAA== ------_=_NextPart_001_01C8213E.2B46391A Content-Type: image/gif; name="image005.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image005.gif Content-Location: image005.gif R0lGODlhRAAbAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAMAAQA+ ABcAgwAAAAAAAAwKCwoICQkICAgHBwsKCgYFBQsJCgcGBwcGBgUEBAMDAwkHCAECAwECAwTmEAAk q704a0u3F4MnjhgikBiBrqPKSsUrY/FruHNOdOsOHIGgcDjMXRA4VKIDDGmARo7iNa0UArVS4CJ8 CRarLeNyzXIxW1l6FASsK4PAAfUOk7b4THzOnuUrdW6CgRIIDAsGIoREGWmOaBJ/GQYBPBqEgpGQ kYFrYhsNTh6YnhhjmmhECicYA2YbdY+oFlVumJoFlhIGtYoWnl1HCai3WwO6P6yKRKUaCCFvpAA3 FwrIahsEiS8NFqEbAqd9Gt0yOK4eBL2wbRlJKwIUvOAEAeVGA8ovFAvM/qI5rq1Q4M+fwCgkIgAA Ow== ------_=_NextPart_001_01C8213E.2B46391A Content-Type: application/x-ms-wmz; name="image006.wmz" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image006.wmz Content-Location: image006.wmz H4sIAAAAAAACC7t+9tgsBjA4wNrA9J8DxFoXwcjAycDAvJSRgYGJQQYsywrEnEwwFhMjI5TFyPT/ /38wS49RAirGDVfHw9TAdIBVCMhSY+NnkGL4D1LMIACyDchaBsQNQGVqQPXcUDU8DL6JJRkhlQWp DAwFYLt/M636ewHshgkgS5lYmBgEgitzk/JzGModgAI9rFysPsFfy0OBmBGszoCBBUjqAjkg7xhx zWc0ZwDJaFQSY95/Fi4u7OYxgukPSObmM4NUaELNXfCPAWEuA8jckMzc1GIFv9RyhaD83MQ8Blzu hJjLCDV3AeNtFpAKE2zmYnMvN3HuXcD4COzeLVBzD/xlwB+u7MS5l5GpDxy+T6HmPoC7l5GkcEB3 7w/Gx0wgFZkY4cBIYfi6gc1NquSCpjoucMqE6ILYJcDADubtAadlRiYmpeDK4pLUXBAPpIsFLMsI xdj8wMwABQCRT7VAYwMAAA== ------_=_NextPart_001_01C8213E.2B46391A Content-Type: image/gif; name="image007.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image007.gif Content-Location: image007.gif R0lGODlhPQAbAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAMAAQA3 ABcAgwAAAAAAAAwKCwoICQkICAgHBwsKCgYFBQsJCgcGBwcGBgUEBAMDAwkHCAECAwECAwTdEAAk q704W6p7FYMneogwasSpYulqFW4Mx4DR0ifBuTpwBMCgUBhD3FYJzi+k+V2AJAVNWikEZhhEALPt CBauLeNixT65ou4Jqq4MAof1qO3Z2jPveBoA1XTbdHyCgRIIDAsGdX9+FYtngx0GATtojRJ0gIFq Yh0NTIyWGWOhT0MKJhgDZhmbfIFUl4SWBZQSBrCgrpcXCAmhsoIDtT6oioC8TMesNUcACsMqdASJ NA0Wnl6jyxfWODeqHgS4pRfNKwIUt14EAd0nA8U0FAtD9UCfI9AuCvb2+jgdIgAAOw== ------_=_NextPart_001_01C8213E.2B46391A-- --===============1857441070== 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 --===============1857441070==-- From ancp-bounces@ietf.org Wed Nov 07 08:13:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipkid-00067q-CG; Wed, 07 Nov 2007 08:13:19 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1Ipkib-00065U-FK for ancp-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 08:13:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipkib-00065M-3s for ancp@ietf.org; Wed, 07 Nov 2007 08:13:17 -0500 Received: from smail5.alcatel.fr ([64.208.49.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ipkia-0006SH-3x for ancp@ietf.org; Wed, 07 Nov 2007 08:13:16 -0500 Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.ad2.ad.alcatel.com [155.132.6.76]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id lA7DBv43020815; Wed, 7 Nov 2007 14:11:59 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.52]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 7 Nov 2007 14:13:14 +0100 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] PORT UP Data Rate? Date: Wed, 7 Nov 2007 14:13:21 +0100 Message-ID: <238382595265324EA50F6134BB42DCAF0101F272@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <4731AF2E.8060803@alcatel-lucent.be> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] PORT UP Data Rate? Thread-Index: AcghOZfn54hE9nanR6GSJ+A4oLB2pgAAc5pA References: <9BD5D7887235424FA97DFC223CAE3C280B65500C@proton.jnpr.net> <4731AF2E.8060803@alcatel-lucent.be> From: "PESCHI Robert" To: "DE CNODDER Stefaan" , "Sanjay Wadhwa" X-OriginalArrivalTime: 07 Nov 2007 13:13:14.0036 (UTC) FILETIME=[F4000F40:01C8213F] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ba0ec39a747b7612d6a8ae66d1a873c 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 Sanjay Wadhwa wrote: > The reported rate is "net data rate" (includes DSL overhead). The=20 > protocol draft explicitly mentions it: >=20 > =20 > . Type (Actual-Data-Rate-Upstream =3D 0x81): Actual data rate upstream = > of a synchronized DSL line. This is a mandatory TLV. >=20 > /This rate value and all the subsequent ones account for the DSL=20 > overhead (i.e. signify the net rate)./ Just unfortunate wording I would say... I think that "Accounting for DSL overhead" means "having substacted DSL overhead"; it does not mean "including DSL overhead". ("Including DSL overhead" cannot mean "DSL net rate") Regards, Robert -----Original Message----- From: DE CNODDER Stefaan=20 Sent: Wednesday, November 07, 2007 1:27 PM To: Sanjay Wadhwa Cc: ancp@ietf.org Subject: Re: [ANCP] PORT UP Data Rate? net data rate does not include DSL overhead (I understand DSL overhead as being the overhead at PHY level, but not the ATM overhead or EFM overhead). See mail of Kirubaharan. So if net data rate is 4 Mbps, then ATM cells can be transported over the DSL line at a rate of 4 Mbps. regards, Stefaan Sanjay Wadhwa wrote: > The reported rate is "net data rate" (includes DSL overhead). The=20 > protocol draft explicitly mentions it: >=20 > =20 >=20 > . Type (Actual-Data-Rate-Upstream =3D 0x81): Actual data rate upstream = > of a synchronized DSL line. This is a mandatory TLV. >=20 > /This rate value and all the subsequent ones account for the DSL=20 > overhead (i.e. signify the net rate)./ >=20 > / / >=20 > -Sanjay >=20 > =20 >=20 > -----Original Message----- > From: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be] > Sent: Wednesday, November 07, 2007 4:24 AM > To: Wojciech Dec (wdec) > Cc: ancp@ietf.org > Subject: Re: [ANCP] PORT UP Data Rate? >=20 > =20 >=20 > =20 >=20 > Woj, >=20 > =20 >=20 > It looks to me that the framework document is correct, and that the >=20 > protocol draft has to replace "data rate" by "net data rate" to make=20 > it >=20 > more accurate, i.e., for istance: >=20 > =20 >=20 > Type (Actual-Data-Rate-Upstream =3D 0x81) : Actual data rate upstream = of > a >=20 > synchronized DSL line... >=20 > =20 >=20 > should be >=20 > =20 >=20 > Type (Actual-Data-Rate-Upstream =3D 0x81) : Actual net data rate=20 > upstream >=20 > of a synchronized DSL line... >=20 > =20 >=20 > The term "net data rate" is accurately defined in section 1.2 of the >=20 > framework document by referring to the ITU standard. >=20 > =20 >=20 > I hope we all have the same understanding of the definition of the >=20 > bandwidth advertised by ANCP. >=20 > =20 >=20 > regards, >=20 > Stefaan >=20 > =20 >=20 > =20 >=20 > =20 >=20 > Wojciech Dec (wdec) wrote: >=20 > =20 >=20 >> Hi All, >=20 >> >=20 >> Hopefully someone can clarify for me the meaning of the Actual data=20 >> rate >=20 >> value in ANCP's PORT-UP messages, and also perhaps comment on their >=20 >> current implementations. Is this rate meant to be the rounded up >=20 >> effective transport capacity (deriving from various ADSL Transport >=20 >> Classes) or raw DSL modem speed? The difference between the two is >=20 >> primarily in the DSL PHY encoding overhead. >=20 >> >=20 >> The framework and protocol drafts are not too clear on this matter,=20 >> but >=20 >> seem to point more towards the former if anything. >=20 >> >=20 >> For example the framework 03 draft currently reads in Section 3.1 as >=20 >> follows : >=20 >> >=20 >> o The identification and speed (data rate) of the DSL Access Loop >=20 >> (also known as the "DSL sync rate") >=20 >> >=20 >> o The identification and speed (data rate) of the Remote >=20 >> Terminal(RT)/Access Node uplink (when relevant) >=20 >> >=20 >> The NAS can adjust downstream shaping to current Access Loop=20 >> actual >=20 >> data rate, and more generally re-configure the appropriate nodes=20 >> of >=20 >> its hierarchical scheduler (support of advanced capabilities >=20 >> according to TR-101). >=20 >> >=20 >> This use case may actually include more information than link >=20 >> identification and corresponding data rates. In case of DSL=20 >> Access >=20 >> Loops, the following Access Loop characteristics can be sent to=20 >> the >=20 >> NAS (cf. ITU-T Recommendation G.997.1 [G.997.1]): >=20 >> >=20 >> o DSL Type (e.g. ADSL1, ADSL2, SDSL, ADSL2+, VDSL, VDSL2) >=20 >> >=20 >> o Framing mode (e.g. ATM, ITU-T Packet Transfer Mode (PTM), IEEE >=20 >> 802.3 Ethernet in the First Mile (EFM)) >=20 >> >=20 >> o DSL port state (e.g. synchronized/showtime, low power, no=20 >> power/ >=20 >> idle) >=20 >> >=20 >> o Actual net data rate (upstream/downstream) >=20 >> >=20 >> >=20 >> While the protocol draft says the following: >=20 >> >=20 >> Following sub-TLVs are currently defined : >=20 >> >=20 >> . Type (DSL-Type =3D 0x91) : Defines the type of = transmission >=20 >> system >=20 >> in use. This is a mandatory TLV. >=20 >> >=20 >> Length : (4 bytes) >=20 >> >=20 >> Value : (Transmission system : ADSL1 =3D 0x01, ADSL2 = =3D >=20 >> 0x02, =20 >=20 >> ADSL2+ =3D 0x03, VDSL1 =3D 0x04, VDSL2 =3D 0x05, SDSL = =3D 0x06, >=20 >> UNKNOWN >=20 >> =3D 0x07). >=20 >> >=20 >> . Type (Actual-Data-Rate-Upstream =3D 0x81) : Actual data=20 >> rate >=20 >> upstream of a synchronized DSL line. This is a mandatory TLV. >=20 >> This rate value and all the subsequent ones account for=20 >> the >=20 >> DSL >=20 >> overhead (i.e. signify the net rate).=20 >=20 >> >=20 >> Length : (4 bytes) >=20 >> >=20 >> Value : (Rate in Kb/sec) >=20 >> >=20 >> . Type (Actual-Data-Rate-Downstream =3D 0x82) : Actual data = >> rate >=20 >> downstream of a synchronized DSL line. This is a=20 >> mandatory >=20 >> TLV. >=20 >> >=20 >> Length : (4 bytes) >=20 >> >=20 >> Regards, >=20 >> Woj. >=20 >> >=20 >> >=20 >> >=20 >> =20 >> --------------------------------------------------------------------- >> --- >=20 >> >=20 >> _______________________________________________ >=20 >> ANCP mailing list >=20 >> ANCP@ietf.org >=20 >> https://www1.ietf.org/mailman/listinfo/ancp >=20 > =20 >=20 > =20 >=20 > _______________________________________________ >=20 > ANCP mailing list >=20 > ANCP@ietf.org >=20 > https://www1.ietf.org/mailman/listinfo/ancp >=20 _______________________________________________ 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 Wed Nov 07 09:04:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IplWT-0003Kv-RH; Wed, 07 Nov 2007 09:04:49 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IplV3-0001h2-Fo for ancp-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 09:03:21 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IplV3-0001gu-5q for ancp@ietf.org; Wed, 07 Nov 2007 09:03:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpkfF-0003fW-Pl for ancp@ietf.org; Wed, 07 Nov 2007 08:09:49 -0500 Received: from smail5.alcatel.fr ([64.208.49.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ipkf9-0007a5-T6 for ancp@ietf.org; Wed, 07 Nov 2007 08:09:49 -0500 Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.ad2.ad.alcatel.com [155.132.6.75]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id lA7D8Iwb018897; Wed, 7 Nov 2007 14:08:22 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.52]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 7 Nov 2007 14:08:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ANCP] PORT UP Data Rate? Date: Wed, 7 Nov 2007 14:08:33 +0100 Message-ID: <238382595265324EA50F6134BB42DCAF0101F260@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C280B65500C@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] PORT UP Data Rate? Thread-Index: AcghH/7GTW3zYySvTTOnYYLYBQQt3gAFbufQAAHWziA= References: <4731843A.30207@alcatel-lucent.be> <9BD5D7887235424FA97DFC223CAE3C280B65500C@proton.jnpr.net> From: "REYNDERS Paul" To: "Sanjay Wadhwa" X-OriginalArrivalTime: 07 Nov 2007 13:08:35.0579 (UTC) FILETIME=[4E06E4B0:01C8213F] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: b360bd6cb019c35178e5cf9eeb747a5c X-TMDA-Confirmed: Wed, 07 Nov 2007 09:03:21 -0500 X-Mailman-Approved-At: Wed, 07 Nov 2007 09:04:48 -0500 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: , Content-Type: multipart/mixed; boundary="===============0253195727==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0253195727== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8213F.4D9173E8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8213F.4D9173E8 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable The DSL overhead is not transmitted between NAS and Access Node. As such, the DSL data rate that includes DSL overhead ("Sanjay's net data rate") must not be input for the Hierarchical Scheduling by NAS. For this HS, NAS needs DSL data rate that excluding DSL overhead ("Stefaan's net data rate"). The latter also decouples the access line technology (ADSL, EFM,...) from the aggregation network technology (ATM, Ethernet). Also consider the difficulties HS at NAS may have with evolving subsciber line transmission technologies if the data rate reported to NAS includes "DSL overhead". =20 Paul Reynders Alcatel-Lucent Bell NV=20 Copernicuslaan 50, 2018 Antwerp, Belgium ________________________________ From: Sanjay Wadhwa [mailto:swadhwa@juniper.net]=20 Sent: woensdag 7 november 2007 13:13 To: DE CNODDER Stefaan; Wojciech Dec (wdec) Cc: ancp@ietf.org Subject: RE: [ANCP] PORT UP Data Rate? The reported rate is "net data rate" (includes DSL overhead). The protocol draft explicitly mentions it: =20 . Type (Actual-Data-Rate-Upstream =3D 0x81): Actual data rate upstream = of a synchronized DSL line. This is a mandatory TLV. This rate value and all the subsequent ones account for the DSL overhead (i.e. signify the net rate). =20 -Sanjay =20 -----Original Message----- From: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be]=20 Sent: Wednesday, November 07, 2007 4:24 AM To: Wojciech Dec (wdec) Cc: ancp@ietf.org Subject: Re: [ANCP] PORT UP Data Rate? =20 =20 Woj, =20 It looks to me that the framework document is correct, and that the=20 protocol draft has to replace "data rate" by "net data rate" to make it=20 more accurate, i.e., for istance: =20 Type (Actual-Data-Rate-Upstream =3D 0x81) : Actual data rate upstream of = a synchronized DSL line... =20 should be =20 Type (Actual-Data-Rate-Upstream =3D 0x81) : Actual net data rate = upstream=20 of a synchronized DSL line... =20 The term "net data rate" is accurately defined in section 1.2 of the=20 framework document by referring to the ITU standard. =20 I hope we all have the same understanding of the definition of the=20 bandwidth advertised by ANCP. =20 regards, Stefaan =20 =20 =20 ------_=_NextPart_001_01C8213F.4D9173E8 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
The DSL overhead is not transmitted between = NAS and=20 Access Node. As such, the DSL data rate that includes DSL overhead = ("Sanjay's=20 net data rate") must not be input for the Hierarchical Scheduling by = NAS. For=20 this HS, NAS needs DSL data rate that excluding DSL overhead=20 ("Stefaan's net data rate"). The latter also decouples the access line=20 technology (ADSL, EFM,...) from the aggregation network technology (ATM, = Ethernet).
Also consider the difficulties HS at NAS may = have with=20 evolving subsciber line transmission technologies if the data rate = reported to=20 NAS includes "DSL overhead".
 
Paul Reynders

Alcatel-Lucent Bell=20 NV
Copernicuslaan 50,=20 2018 Antwerp, Belgium
From: Sanjay Wadhwa = [mailto:swadhwa@juniper.net]=20
Sent: woensdag 7 november 2007 13:13
To: DE CNODDER = Stefaan; Wojciech Dec (wdec)
Cc: = ancp@ietf.org
Subject: RE:=20 [ANCP] PORT UP Data Rate?

The reported rate is "net data rate" (includes = DSL=20 overhead). The protocol draft explicitly mentions=20 it:

 

. Type (Actual-Data-Rate-Upstream =3D 0x81): = Actual data=20 rate upstream of a synchronized DSL line. This is a mandatory=20 TLV.

This rate value and all = the=20 subsequent ones account for the DSL overhead (i.e. signify the net=20 rate).

 

-Sanjay

 

-----Original Message-----
From: Stefaan DE = CNODDER=20 [mailto:stefaan.de_cnodder@alcatel-lucent.be]
Sent: Wednesday, = November 07,=20 2007 4:24 AM
To: Wojciech Dec (wdec)
Cc: ancp@ietf.org
Subject: = Re:=20 [ANCP] PORT UP Data Rate?

 

 

Woj,

 

It looks to me that the framework document is = correct,=20 and that the

protocol draft has to replace "data rate" by = "net data=20 rate" to make it

more accurate, i.e., for=20 istance:

 

Type (Actual-Data-Rate-Upstream =3D 0x81) : = Actual data=20 rate upstream of a

synchronized DSL = line...

 

should be

 

Type (Actual-Data-Rate-Upstream =3D 0x81) : = Actual net=20 data rate upstream

of a synchronized DSL=20 line...

 

The term "net data rate" is accurately defined = in=20 section 1.2 of the

framework document by referring to the ITU=20 standard.

 

I hope we all have the same understanding of = the=20 definition of the

bandwidth advertised by=20 ANCP.

 

regards,

Stefaan

 

 

 

------_=_NextPart_001_01C8213F.4D9173E8-- --===============0253195727== 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 --===============0253195727==-- From ancp-bounces@ietf.org Wed Nov 07 09:24: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 1Iplp1-00050J-DE; Wed, 07 Nov 2007 09:23:59 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1Iploz-0004y4-Rf for ancp-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 09:23:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iploz-0004wQ-2y for ancp@ietf.org; Wed, 07 Nov 2007 09:23:57 -0500 Received: from exprod7og112.obsmtp.com ([64.18.2.177]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iploy-0001Rd-1J for ancp@ietf.org; Wed, 07 Nov 2007 09:23:56 -0500 Received: from source ([66.129.224.36]) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP; Wed, 07 Nov 2007 06:22:45 PST Received: from proton.jnpr.net ([10.10.2.37]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 06:23:41 -0800 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] PORT UP Data Rate? Date: Wed, 7 Nov 2007 09:23:38 -0500 Message-ID: <9BD5D7887235424FA97DFC223CAE3C280AB43678@proton.jnpr.net> In-Reply-To: <238382595265324EA50F6134BB42DCAF0101F272@FRVELSMBS22.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] PORT UP Data Rate? Thread-Index: AcghOZfn54hE9nanR6GSJ+A4oLB2pgAAc5pAAANF7dA= From: "Sanjay Wadhwa" To: "PESCHI Robert" , "DE CNODDER Stefaan" X-OriginalArrivalTime: 07 Nov 2007 14:23:41.0724 (UTC) FILETIME=[CBE60DC0:01C82149] X-Spam-Score: 0.0 (/) X-Scan-Signature: 17cf8eab1d6bbd2874a56f9e3554d91d 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 Steffan You are ignoring what the draft says. It clearly says "account for the DSL overhead" i.e. the value sent in the TLV has factored in the DSL overhead. I don't see any ambiguity here.=20 Use of "including" in the mail didn't mean expclitly sending in the overhead. It was meant as DSLAM sends the rate after including the DSL overhead in its calculation (i.e. accounting for it / subtracting it).=20 -Sanjay >-----Original Message----- >From: PESCHI Robert [mailto:Robert.Peschi@alcatel-lucent.be] >Sent: Wednesday, November 07, 2007 8:13 AM >To: DE CNODDER Stefaan; Sanjay Wadhwa >Cc: ancp@ietf.org >Subject: RE: [ANCP] PORT UP Data Rate? > > >Sanjay Wadhwa wrote: >> The reported rate is "net data rate" (includes DSL overhead). The=20 >> protocol draft explicitly mentions it: >>=20 >> =20 >> . Type (Actual-Data-Rate-Upstream =3D 0x81): Actual data rate = upstream=20 >> of a synchronized DSL line. This is a mandatory TLV. >>=20 >> /This rate value and all the subsequent ones account for the DSL=20 >> overhead (i.e. signify the net rate)./ > >Just unfortunate wording I would say... > >I think that "Accounting for DSL overhead" means "having substacted DSL >overhead"; >it does not mean "including DSL overhead". > >("Including DSL overhead" cannot mean "DSL net rate") > >Regards, >Robert > >-----Original Message----- >From: DE CNODDER Stefaan=20 >Sent: Wednesday, November 07, 2007 1:27 PM >To: Sanjay Wadhwa >Cc: ancp@ietf.org >Subject: Re: [ANCP] PORT UP Data Rate? > > >net data rate does not include DSL overhead (I understand DSL overhead >as being the overhead at PHY level, but not the ATM overhead or EFM >overhead). See mail of Kirubaharan. > >So if net data rate is 4 Mbps, then ATM cells can be transported over >the DSL line at a rate of 4 Mbps. > >regards, >Stefaan > >Sanjay Wadhwa wrote: >> The reported rate is "net data rate" (includes DSL overhead). The=20 >> protocol draft explicitly mentions it: >>=20 >> =20 >>=20 >> . Type (Actual-Data-Rate-Upstream =3D 0x81): Actual data rate = upstream=20 >> of a synchronized DSL line. This is a mandatory TLV. >>=20 >> /This rate value and all the subsequent ones account for the DSL=20 >> overhead (i.e. signify the net rate)./ >>=20 >> / / >>=20 >> -Sanjay >>=20 >> =20 >>=20 >> -----Original Message----- >> From: Stefaan DE CNODDER=20 >[mailto:stefaan.de_cnodder@alcatel-lucent.be] >> Sent: Wednesday, November 07, 2007 4:24 AM >> To: Wojciech Dec (wdec) >> Cc: ancp@ietf.org >> Subject: Re: [ANCP] PORT UP Data Rate? >>=20 >> =20 >>=20 >> =20 >>=20 >> Woj, >>=20 >> =20 >>=20 >> It looks to me that the framework document is correct, and that the >>=20 >> protocol draft has to replace "data rate" by "net data rate" to make=20 >> it >>=20 >> more accurate, i.e., for istance: >>=20 >> =20 >>=20 >> Type (Actual-Data-Rate-Upstream =3D 0x81) : Actual data rate=20 >upstream of > >> a >>=20 >> synchronized DSL line... >>=20 >> =20 >>=20 >> should be >>=20 >> =20 >>=20 >> Type (Actual-Data-Rate-Upstream =3D 0x81) : Actual net data rate=20 >> upstream >>=20 >> of a synchronized DSL line... >>=20 >> =20 >>=20 >> The term "net data rate" is accurately defined in section 1.2 of the >>=20 >> framework document by referring to the ITU standard. >>=20 >> =20 >>=20 >> I hope we all have the same understanding of the definition of the >>=20 >> bandwidth advertised by ANCP. >>=20 >> =20 >>=20 >> regards, >>=20 >> Stefaan >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> Wojciech Dec (wdec) wrote: >>=20 >> =20 >>=20 >>> Hi All, >>=20 >>> >>=20 >>> Hopefully someone can clarify for me the meaning of the=20 >Actual data=20 >>> rate >>=20 >>> value in ANCP's PORT-UP messages, and also perhaps comment on their >>=20 >>> current implementations. Is this rate meant to be the rounded up >>=20 >>> effective transport capacity (deriving from various ADSL Transport >>=20 >>> Classes) or raw DSL modem speed? The difference between the two is >>=20 >>> primarily in the DSL PHY encoding overhead. >>=20 >>> >>=20 >>> The framework and protocol drafts are not too clear on=20 >this matter,=20 >>> but >>=20 >>> seem to point more towards the former if anything. >>=20 >>> >>=20 >>> For example the framework 03 draft currently reads in=20 >Section 3.1 as >>=20 >>> follows : >>=20 >>> >>=20 >>> o The identification and speed (data rate) of the DSL Access Loop >>=20 >>> (also known as the "DSL sync rate") >>=20 >>> >>=20 >>> o The identification and speed (data rate) of the Remote >>=20 >>> Terminal(RT)/Access Node uplink (when relevant) >>=20 >>> >>=20 >>> The NAS can adjust downstream shaping to current Access Loop=20 >>> actual >>=20 >>> data rate, and more generally re-configure the appropriate nodes=20 >>> of >>=20 >>> its hierarchical scheduler (support of advanced capabilities >>=20 >>> according to TR-101). >>=20 >>> >>=20 >>> This use case may actually include more information than link >>=20 >>> identification and corresponding data rates. In case of DSL=20 >>> Access >>=20 >>> Loops, the following Access Loop characteristics can be sent to=20 >>> the >>=20 >>> NAS (cf. ITU-T Recommendation G.997.1 [G.997.1]): >>=20 >>> >>=20 >>> o DSL Type (e.g. ADSL1, ADSL2, SDSL, ADSL2+, VDSL, VDSL2) >>=20 >>> >>=20 >>> o Framing mode (e.g. ATM, ITU-T Packet Transfer Mode=20 >(PTM), IEEE >>=20 >>> 802.3 Ethernet in the First Mile (EFM)) >>=20 >>> >>=20 >>> o DSL port state (e.g. synchronized/showtime, low power, no=20 >>> power/ >>=20 >>> idle) >>=20 >>> >>=20 >>> o Actual net data rate (upstream/downstream) >>=20 >>> >>=20 >>> >>=20 >>> While the protocol draft says the following: >>=20 >>> >>=20 >>> Following sub-TLVs are currently defined : >>=20 >>> >>=20 >>> . Type (DSL-Type =3D 0x91) : Defines the type of=20 >transmission >>=20 >>> system >>=20 >>> in use. This is a mandatory TLV. >>=20 >>> >>=20 >>> Length : (4 bytes) >>=20 >>> >>=20 >>> Value : (Transmission system : ADSL1 =3D 0x01, ADSL2 = =3D >>=20 >>> 0x02, =20 >>=20 >>> ADSL2+ =3D 0x03, VDSL1 =3D 0x04, VDSL2 =3D 0x05, SDSL = =3D 0x06, >>=20 >>> UNKNOWN >>=20 >>> =3D 0x07). >>=20 >>> >>=20 >>> . Type (Actual-Data-Rate-Upstream =3D 0x81) : Actual data=20 >>> rate >>=20 >>> upstream of a synchronized DSL line. This is a=20 >mandatory >TLV. >>=20 >>> This rate value and all the subsequent ones=20 >account for=20 >>> the >>=20 >>> DSL >>=20 >>> overhead (i.e. signify the net rate).=20 >>=20 >>> >>=20 >>> Length : (4 bytes) >>=20 >>> >>=20 >>> Value : (Rate in Kb/sec) >>=20 >>> >>=20 >>> . Type (Actual-Data-Rate-Downstream =3D 0x82) : Actual = data=20 >>> rate >>=20 >>> downstream of a synchronized DSL line. This is a=20 >>> mandatory >>=20 >>> TLV. >>=20 >>> >>=20 >>> Length : (4 bytes) >>=20 >>> >>=20 >>> Regards, >>=20 >>> Woj. >>=20 >>> >>=20 >>> >>=20 >>> >>=20 >>> =20 >>>=20 >--------------------------------------------------------------------- >>> --- >>=20 >>> >>=20 >>> _______________________________________________ >>=20 >>> ANCP mailing list >>=20 >>> ANCP@ietf.org >>=20 >>> https://www1.ietf.org/mailman/listinfo/ancp >>=20 >> =20 >>=20 >> =20 >>=20 >> _______________________________________________ >>=20 >> ANCP mailing list >>=20 >> ANCP@ietf.org >>=20 >> https://www1.ietf.org/mailman/listinfo/ancp >>=20 > > >_______________________________________________ >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 Wed Nov 07 12:59:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IppBF-0003hA-Iu; Wed, 07 Nov 2007 12:59:09 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IppBE-0003gD-L6 for ancp-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 12:59:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IppBE-0003ev-2v for ancp@ietf.org; Wed, 07 Nov 2007 12:59:08 -0500 Received: from prattle.redback.com ([155.53.12.9]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IppBC-0001ol-Px for ancp@ietf.org; Wed, 07 Nov 2007 12:59:08 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id EE5112C836 for ; Wed, 7 Nov 2007 09:59:05 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11243-02 for ; Wed, 7 Nov 2007 09:59:05 -0800 (PST) Received: from [127.0.0.1] (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id A341C2C835 for ; Wed, 7 Nov 2007 09:59:05 -0800 (PST) Message-ID: <4731FCE9.8050102@redback.com> Date: Wed, 07 Nov 2007 09:59:05 -0800 From: Jakob Heitz User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ancp@ietf.org Subject: Re: [ANCP] PORT UP Data Rate? References: In-Reply-To: X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: e16ce0269ccb2f59707d16700199d13b 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="===============1830063164==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============1830063164== Content-Type: multipart/alternative; boundary="------------060206070306050500010800" This is a multi-part message in MIME format. --------------060206070306050500010800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Whatever it is, it needs to be constant in time. Then the BRAS needs to know all the encapsulations on top of it so that it can properly count data bits in the shaper/meter. If it is not constant in time, then the BRAS cannot do that. Examples of *not* constant in time o HDLC bit stuffing at lower layer. actual data rate depends on the bit pattern. o framing at lower layer. There are frame headers introduced between data bits that are unpredictable by the BRAS. For any of this to be useful, it is imperative that the shaper/meter in the BRAS can accurately track the time that bits are sent at the DSLAM. Wojciech Dec (wdec) wrote: > Hi Folks, > > can anyone reply? To put the question in other words, if ANCP signals > a line rate of downstream rate of 4Mbps, is this the effective ATM VC > or Ethernet "circuit" data carrying capacity, or is it the raw modem > rate which does not include DSL PHY overheads? The text should be > *very* clear about this. > > -Woj. > > ------------------------------------------------------------------------ > *From:* Wojciech Dec (wdec) > *Sent:* 05 November 2007 10:36 > *To:* ancp@ietf.org > *Subject:* [ANCP] PORT UP Data Rate? > > Hi All, > > Hopefully someone can clarify for me the meaning of the Actual > data rate value in ANCP's PORT-UP messages, and also perhaps > comment on their current implementations. Is this rate meant to be > the rounded up effective transport capacity (deriving from various > ADSL Transport Classes) or raw DSL modem speed? The difference > between the two is primarily in the DSL PHY encoding overhead. > > The framework and protocol drafts are not too clear on this > matter, but seem to point more towards the former if anything. > > For example the framework 03 draft currently reads in Section 3.1 > as follows : > > o The identification and speed (data rate) of the DSL Access Loop > (also known as the "DSL sync rate") > > o The identification and speed (data rate) of the Remote > Terminal(RT)/Access Node uplink (when relevant) > > The NAS can adjust downstream shaping to current Access Loop > actual > data rate, and more generally re-configure the appropriate > nodes of > its hierarchical scheduler (support of advanced capabilities > according to TR-101). > > This use case may actually include more information than link > identification and corresponding data rates. In case of DSL > Access > Loops, the following Access Loop characteristics can be sent to > the > NAS (cf. ITU-T Recommendation G.997.1 [G.997.1]): > > o DSL Type (e.g. ADSL1, ADSL2, SDSL, ADSL2+, VDSL, VDSL2) > > o Framing mode (e.g. ATM, ITU-T Packet Transfer Mode (PTM), IEEE > 802.3 Ethernet in the First Mile (EFM)) > > o DSL port state (e.g. synchronized/showtime, low power, no > power/ > idle) > > o Actual net data rate (upstream/downstream) > > > While the protocol draft says the following: > > Following sub-TLVs are currently defined : > > . Type (DSL-Type = 0x91) : Defines the type of > transmission system > in use. This is a mandatory TLV. > > Length : (4 bytes) > > Value : (Transmission system : ADSL1 = 0x01, ADSL2 = > 0x02, > ADSL2+ = 0x03, VDSL1 = 0x04, VDSL2 = 0x05, SDSL = > 0x06, UNKNOWN > = 0x07). > > . Type (Actual-Data-Rate-Upstream = 0x81) : Actual data > rate > upstream of a synchronized DSL line. This is a > mandatory TLV. > This rate value and all the subsequent ones account > for the DSL > overhead (i.e. signify the net rate). > > Length : (4 bytes) > > Value : (Rate in Kb/sec) > > . Type (Actual-Data-Rate-Downstream = 0x82) : Actual > data rate > downstream of a synchronized DSL line. This is a > mandatory TLV. > > Length : (4 bytes) > > Regards, > Woj. > > > ------------------------------------------------------------------------ > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www1.ietf.org/mailman/listinfo/ancp > -- Jakob Heitz. --------------060206070306050500010800 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Whatever it is, it needs to be constant in time.
Then the BRAS needs to know all the encapsulations
on top of it so that it can properly count data
bits in the shaper/meter.

If it is not constant in time, then the BRAS cannot
do that.

Examples of *not* constant in time
o HDLC bit stuffing at lower layer.
  actual data rate depends on the bit pattern.
o framing at lower layer.
  There are frame headers introduced between data
  bits that are unpredictable by the BRAS.

For any of this to be useful, it is imperative that the
shaper/meter in the BRAS can accurately track the time
that bits are sent at the DSLAM.

Wojciech Dec (wdec) wrote:
PORT UP Data Rate?
Hi Folks,
 
can anyone reply? To put the question in other words, if ANCP signals a line rate of downstream rate of 4Mbps, is this the effective ATM VC or Ethernet "circuit" data carrying capacity, or is it the raw modem rate which does not include DSL PHY overheads? The text should be *very* clear about this.
 
-Woj.

From: Wojciech Dec (wdec)
Sent: 05 November 2007 10:36
To: ancp@ietf.org
Subject: [ANCP] PORT UP Data Rate?

Hi All,

Hopefully someone can clarify for me the meaning of the Actual data rate value in ANCP's PORT-UP messages, and also perhaps comment on their current implementations. Is this rate meant to be the rounded up effective transport capacity (deriving from various ADSL Transport Classes) or raw DSL modem speed? The difference between the two is primarily in the DSL PHY encoding overhead.

The framework and protocol drafts are not too clear on this matter, but seem to point more towards the former if anything.

For example the framework 03 draft currently reads in Section 3.1 as follows :

  o  The identification and speed (data rate) of the DSL Access Loop
      (also known as the "DSL sync rate")

   o  The identification and speed (data rate) of the Remote
      Terminal(RT)/Access Node uplink (when relevant)

   The NAS can adjust downstream shaping to current Access Loop actual
   data rate, and more generally re-configure the appropriate nodes of
   its hierarchical scheduler (support of advanced capabilities
   according to TR-101).

   This use case may actually include more information than link
   identification and corresponding data rates.  In case of DSL Access
   Loops, the following Access Loop characteristics can be sent to the
   NAS (cf. ITU-T Recommendation G.997.1 [G.997.1]):

   o  DSL Type (e.g.  ADSL1, ADSL2, SDSL, ADSL2+, VDSL, VDSL2)

   o  Framing mode (e.g.  ATM, ITU-T Packet Transfer Mode (PTM), IEEE
      802.3 Ethernet in the First Mile (EFM))

   o  DSL port state (e.g. synchronized/showtime, low power, no power/
      idle)

   o  Actual net data rate (upstream/downstream)


While the protocol draft says the following:

         Following sub-TLVs are currently defined :

          . Type (DSL-Type = 0x91) : Defines the type of transmission system
             in use. This is a mandatory TLV.

             Length :  (4 bytes)  

             Value  : (Transmission system : ADSL1 = 0x01, ADSL2 = 0x02,    
             ADSL2+ = 0x03, VDSL1 = 0x04, VDSL2 = 0x05, SDSL = 0x06, UNKNOWN
             = 0x07).

          . Type (Actual-Data-Rate-Upstream = 0x81) : Actual data rate
             upstream of a synchronized DSL line. This is a mandatory TLV.
             This rate value and all the subsequent ones account for the DSL
             overhead (i.e. signify the net rate).  

            Length  :  (4 bytes)

            Value   : (Rate in Kb/sec)

          . Type (Actual-Data-Rate-Downstream = 0x82) : Actual data rate
             downstream of a synchronized DSL line. This is a mandatory TLV.

             Length :  (4 bytes)

Regards,
Woj. 



_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp
  

-- 
Jakob Heitz.
--------------060206070306050500010800-- --===============1830063164== 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 --===============1830063164==-- From ancp-bounces@ietf.org Thu Nov 08 04:12:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq3RN-0001h4-SN; Thu, 08 Nov 2007 04:12:45 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1Iq3RM-0001cK-Cp for ancp-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 04:12:44 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq3RH-0001Vq-BO for ancp@ietf.org; Thu, 08 Nov 2007 04:12:39 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iq3RF-0007CO-Qd for ancp@ietf.org; Thu, 08 Nov 2007 04:12:38 -0500 X-IronPort-AV: E=Sophos;i="4.21,388,1188770400"; d="scan'208,217";a="157130223" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 08 Nov 2007 10:12:35 +0100 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 lA89CYot011250; Thu, 8 Nov 2007 10:12:34 +0100 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 lA89CW8i009484; Thu, 8 Nov 2007 09:12:32 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); Thu, 8 Nov 2007 10:12:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ANCP] PORT UP Data Rate? Date: Thu, 8 Nov 2007 10:12:16 +0100 Message-ID: In-Reply-To: <238382595265324EA50F6134BB42DCAF0101F260@FRVELSMBS22.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] PORT UP Data Rate? Thread-Index: AcghH/7GTW3zYySvTTOnYYLYBQQt3gAFbufQAAHWziAAKmzQQA== References: <4731843A.30207@alcatel-lucent.be> <9BD5D7887235424FA97DFC223CAE3C280B65500C@proton.jnpr.net> <238382595265324EA50F6134BB42DCAF0101F260@FRVELSMBS22.ad2.ad.alcatel.com> From: "Wojciech Dec (wdec)" To: "REYNDERS Paul" , "Sanjay Wadhwa" X-OriginalArrivalTime: 08 Nov 2007 09:12:32.0066 (UTC) FILETIME=[7E541220:01C821E7] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15532.001 X-TM-AS-Result: No--12.597700-8.000000-2 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=14437; t=1194513154; x=1195377154; 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]=20PORT=20UP=20Data=20Rate? |Sender:=20; bh=qSCkahoSpNMXjlmM5UVKRRRskhRFOf/vPAa9H0kJePM=; b=oCkF9BybV/lUYU+JRRPm4xhASvX9oJEbR4aUvS9uUW5PNZX36XlooUvNhCLBiPBQEaLazy4z n+zCkDC+EjGk+28OBmdrwnSC9IpyfeNB2hGG5KGu6xovGxk4oseBvJtu; Authentication-Results: ams-dkim-1; header.From=wdec@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: df1883a27a831c1ea5e8cfe5eb3ad38e 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: , Content-Type: multipart/mixed; boundary="===============0920750060==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0920750060== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C821E7.7E18ECC9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C821E7.7E18ECC9 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Precisely. So we seem to agree that the appropriate edits need to be made in the protocol draft to clarify this? Section 3.1 of the framework draft should also see a minor edit to the term "DSL sync rate", and the use of the full "net data rate" term as introduced in the terminology section. =20 Regards, Woj. =20 =20 ________________________________ From: REYNDERS Paul [mailto:paul.reynders@alcatel-lucent.be]=20 Sent: 07 November 2007 14:09 To: Sanjay Wadhwa Cc: ancp@ietf.org; DE CNODDER Stefaan; Wojciech Dec (wdec) Subject: RE: [ANCP] PORT UP Data Rate? =09 =09 The DSL overhead is not transmitted between NAS and Access Node. As such, the DSL data rate that includes DSL overhead ("Sanjay's net data rate") must not be input for the Hierarchical Scheduling by NAS. For this HS, NAS needs DSL data rate that excluding DSL overhead ("Stefaan's net data rate"). The latter also decouples the access line technology (ADSL, EFM,...) from the aggregation network technology (ATM, Ethernet). Also consider the difficulties HS at NAS may have with evolving subsciber line transmission technologies if the data rate reported to NAS includes "DSL overhead". =20 Paul Reynders =09 =09 Alcatel-Lucent Bell NV=20 Copernicuslaan 50, 2018 Antwerp, Belgium ________________________________ From: Sanjay Wadhwa [mailto:swadhwa@juniper.net]=20 Sent: woensdag 7 november 2007 13:13 To: DE CNODDER Stefaan; Wojciech Dec (wdec) Cc: ancp@ietf.org Subject: RE: [ANCP] PORT UP Data Rate? =09 =09 The reported rate is "net data rate" (includes DSL overhead). The protocol draft explicitly mentions it: =20 . Type (Actual-Data-Rate-Upstream =3D 0x81): Actual data rate upstream of a synchronized DSL line. This is a mandatory TLV. This rate value and all the subsequent ones account for the DSL overhead (i.e. signify the net rate). =20 -Sanjay =20 -----Original Message----- From: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be]=20 Sent: Wednesday, November 07, 2007 4:24 AM To: Wojciech Dec (wdec) Cc: ancp@ietf.org Subject: Re: [ANCP] PORT UP Data Rate? =20 =20 Woj, =20 It looks to me that the framework document is correct, and that the=20 protocol draft has to replace "data rate" by "net data rate" to make it=20 more accurate, i.e., for istance: =20 Type (Actual-Data-Rate-Upstream =3D 0x81) : Actual data rate upstream of a=20 synchronized DSL line... =20 should be =20 Type (Actual-Data-Rate-Upstream =3D 0x81) : Actual net data rate upstream=20 of a synchronized DSL line... =20 The term "net data rate" is accurately defined in section 1.2 of the=20 framework document by referring to the ITU standard. =20 I hope we all have the same understanding of the definition of the=20 bandwidth advertised by ANCP. =20 regards, Stefaan =20 =20 =20 ------_=_NextPart_001_01C821E7.7E18ECC9 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Precisely. So we seem to agree that the appropriate edits = need to be=20 made in the protocol draft to clarify this? Section 3.1 of the framework = draft=20 should also see a minor edit to the term "DSL sync rate", and the use of = the=20 full "net data rate" term as introduced in the terminology=20 section.
 
Regards,
Woj.
 
 

From: REYNDERS Paul=20 [mailto:paul.reynders@alcatel-lucent.be]
Sent: 07 November = 2007=20 14:09
To: Sanjay Wadhwa
Cc: ancp@ietf.org; DE = CNODDER=20 Stefaan; Wojciech Dec (wdec)
Subject: RE: [ANCP] PORT UP = Data=20 Rate?

The DSL overhead is not transmitted between = NAS and=20 Access Node. As such, the DSL data rate that includes DSL overhead = ("Sanjay's=20 net data rate") must not be input for the Hierarchical Scheduling by = NAS. For=20 this HS, NAS needs DSL data rate that excluding DSL overhead = ("Stefaan's net data rate"). The latter also decouples the access line = technology (ADSL, EFM,...) from the aggregation network technology = (ATM,=20 Ethernet).
Also consider the difficulties HS at NAS = may have=20 with evolving subsciber line transmission technologies if the data = rate=20 reported to NAS includes "DSL overhead".
 
Paul Reynders

Alcatel-Lucent=20 Bell NV
Copernicuslaan=20 50, 2018 Antwerp, Belgium
From: Sanjay Wadhwa=20 [mailto:swadhwa@juniper.net]
Sent: woensdag 7 november 2007 = 13:13
To: DE CNODDER Stefaan; Wojciech Dec = (wdec)
Cc:=20 ancp@ietf.org
Subject: RE: [ANCP] PORT UP Data=20 Rate?

The reported rate is "net data rate" = (includes DSL=20 overhead). The protocol draft explicitly mentions=20 it:

 

. Type (Actual-Data-Rate-Upstream =3D 0x81): = Actual data=20 rate upstream of a synchronized DSL line. This is a mandatory=20 TLV.

This rate value and all = the=20 subsequent ones account for the DSL overhead (i.e. signify the net=20 rate).

 

-Sanjay

 

-----Original Message-----
From: Stefaan = DE CNODDER=20 [mailto:stefaan.de_cnodder@alcatel-lucent.be]
Sent: Wednesday, = November=20 07, 2007 4:24 AM
To: Wojciech Dec (wdec)
Cc: = ancp@ietf.org
Subject:=20 Re: [ANCP] PORT UP Data Rate?

 

 

Woj,

 

It looks to me that the framework document = is correct,=20 and that the

protocol draft has to replace "data rate" by = "net data=20 rate" to make it

more accurate, i.e., for=20 istance:

 

Type (Actual-Data-Rate-Upstream =3D 0x81) : = Actual data=20 rate upstream of a

synchronized DSL = line...

 

should be

 

Type (Actual-Data-Rate-Upstream =3D 0x81) : = Actual net=20 data rate upstream

of a synchronized DSL=20 line...

 

The term "net data rate" is accurately = defined in=20 section 1.2 of the

framework document by referring to the ITU=20 standard.

 

I hope we all have the same understanding of = the=20 definition of the

bandwidth advertised by=20 ANCP.

 

regards,

Stefaan

 

 

 

------_=_NextPart_001_01C821E7.7E18ECC9-- --===============0920750060== 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 --===============0920750060==-- From ancp-bounces@ietf.org Thu Nov 08 04:57:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq48K-0006Go-3c; Thu, 08 Nov 2007 04:57:08 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1Iq48J-0006FC-1Z for ancp-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 04:57:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq48I-0006Ek-O7 for ancp@ietf.org; Thu, 08 Nov 2007 04:57:06 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iq48I-0007fO-Hl for ancp@ietf.org; Thu, 08 Nov 2007 04:57:06 -0500 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns1.neustar.com (Postfix) with ESMTP id 61E5F26E3F; Thu, 8 Nov 2007 09:57:06 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1Iq48I-00053v-9y; Thu, 08 Nov 2007 04:57:06 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: moti.Morgenstern@ecitele.com From: IETF I-D Submission Tool Message-Id: Date: Thu, 08 Nov 2007 04:57:06 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: stefaan.de_cnodder@neustar.com, ancp@ietf.org Subject: [ANCP] New Version Notification for draft-ietf-ancp-mib-an-01 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 A new version of I-D, draft-ietf-ancp-mib-an-01.txt has been successfuly submitted by Moti Morgenstern and posted to the IETF repository. Filename: draft-ietf-ancp-mib-an Revision: 01 Title: Access Node Control Protocol (ANCP) MIB module for Access Nodes Creation_date: 2007-11-08 WG ID: ancp Number_of_pages: 31 Abstract: 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). The IETF Secretariat. _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Thu Nov 08 05:00:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq4Bf-0000qa-Fa; Thu, 08 Nov 2007 05:00:35 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1Iq4Be-0000qM-H1 for ancp-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 05:00:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq4Be-0000qB-5z; Thu, 08 Nov 2007 05:00:34 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iq4Bd-0000EE-QI; Thu, 08 Nov 2007 05:00:34 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 9A4BF2AC50; Thu, 8 Nov 2007 10:00:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Iq4B7-0001Nb-Ib; Thu, 08 Nov 2007 05:00:01 -0500 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, 08 Nov 2007 05:00:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: ancp@ietf.org Subject: [ANCP] I-D Action:draft-ietf-ancp-mib-an-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 : Access Node Control Protocol (ANCP) MIB module for Access Nodes Author(s) : S. Cnodder, M. Morgenstern Filename : draft-ietf-ancp-mib-an-01.txt Pages : 31 Date : 2007-11-08 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-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-mib-an-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-mib-an-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-11-08045703.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ancp-mib-an-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ancp-mib-an-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-08045703.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 Thu Nov 08 05:03:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq4EW-0005Dj-7q; Thu, 08 Nov 2007 05:03:32 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1Iq4EU-00059H-HQ for ancp-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 05:03:30 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq4EU-000593-3y for ancp@ietf.org; Thu, 08 Nov 2007 05:03:30 -0500 Received: from eci-iron.ecitele.com ([147.234.242.112] helo=iron.ecitele.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iq4ET-0000Jt-Ji for ancp@ietf.org; Thu, 08 Nov 2007 05:03:30 -0500 Received: from ilptexfe.ecitele.com (HELO ILPTEXFE02.ecitele.com) ([147.234.245.181]) by eci-iron-out.ecitele.com with ESMTP; 08 Nov 2007 12:04:55 +0200 Received: from ILPTMAIL01.ecitele.com ([147.234.245.211]) by ILPTEXFE02.ecitele.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Nov 2007 12:03:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 8 Nov 2007 12:03:26 +0200 Message-ID: <83153A1EB675AF4F82E134FA27F95F67023D917E@ILPTEX02.ecitele.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ancp-mib-an-01 was uploaded Thread-Index: Acgh7pruY0A0bTWaR8KQl4gjPvwNag== From: "Moti Morgenstern" To: X-OriginalArrivalTime: 08 Nov 2007 10:03:27.0973 (UTC) FILETIME=[9BCA7950:01C821EE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: matthew.bocci@alcatel-lucent.co.uk Subject: [ANCP] draft-ietf-ancp-mib-an-01 was uploaded 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="===============1965405299==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============1965405299== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C821EE.9BAA72B2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C821EE.9BAA72B2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 I've just sent the document in the subject to the Internet-Drafts and hope it will be uploaded shortly. =20 The main changes in this version are: 1) The syntax of ancpAnPartitionsUsed (global) object is more generic 2) Accordingly, changed the description of ancpAnSessionConfigPartitionId attribute 3) ancpAnSessionConfigSessionId description was revised. It is actually not a "system generated index". 4) improved the description of ancpAnSessionConfigNasIpAddress attribute.=20 5) The last two attributes in the ancpAnSessionConfigEntry are read-create rather than read-write. 6) ancpAnSessionConfigEncapPortNumber has a more detailed description and also cannot take the value 0. =20 Regards, Moti Morgenstern ------_=_NextPart_001_01C821EE.9BAA72B2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 all,
 
I've = just sent the=20 document in the subject to the Internet-Drafts and hope it will be = uploaded=20 shortly.
 
The = main changes in=20 this version are:
1) The = syntax of ancpAnPartitionsUsed (global) object is more=20 generic
2) = Accordingly,=20 changed the description of ancpAnSessionConfigPartitionId=20 attribute
3)=20 ancpAnSessionConfigSessionId description was revised. It is actually not = a=20 "system generated index".
4) = improved the=20 description of ancpAnSessionConfigNasIpAddress attribute.
5) The = last two=20 attributes in the ancpAnSessionConfigEntry are read-create rather than=20 read-write.
6) = ancpAnSessionConfigEncapPortNumber has a=20 more detailed description and also cannot take the value 0.
 
Regards,
Moti=20 Morgenstern
------_=_NextPart_001_01C821EE.9BAA72B2-- --===============1965405299== 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 --===============1965405299==-- From ancp-bounces@ietf.org Thu Nov 08 05:20:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq4Uw-0007UN-Tz; Thu, 08 Nov 2007 05:20:30 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1Iq4Uv-0007UH-VA for ancp-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 05:20:29 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq4Uv-0007SR-Fq for ancp@ietf.org; Thu, 08 Nov 2007 05:20:29 -0500 Received: from exprod7og108.obsmtp.com ([64.18.2.169]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iq4Uu-0000lO-54 for ancp@ietf.org; Thu, 08 Nov 2007 05:20:29 -0500 Received: from source ([66.129.224.36]) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP; Thu, 08 Nov 2007 02:18:35 PST Received: from proton.jnpr.net ([10.10.2.37]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Nov 2007 02:20:12 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ANCP] PORT UP Data Rate? Date: Thu, 8 Nov 2007 05:20:09 -0500 Message-ID: <9BD5D7887235424FA97DFC223CAE3C280AB4368B@proton.jnpr.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] PORT UP Data Rate? Thread-Index: AcghH/7GTW3zYySvTTOnYYLYBQQt3gAFbufQAAHWziAAKmzQQAABKV6A From: "Sanjay Wadhwa" To: "Wojciech Dec (wdec)" , "REYNDERS Paul" X-OriginalArrivalTime: 08 Nov 2007 10:20:12.0193 (UTC) FILETIME=[F25A4910:01C821F0] X-Spam-Score: 0.0 (/) X-Scan-Signature: ff67cea9f7df2d77f61a364cea0926e8 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: , Content-Type: multipart/mixed; boundary="===============1902978427==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============1902978427== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C821F0.F0D11BFC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C821F0.F0D11BFC Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable As I said in my previous mail, the protocol draft is quite explicit. The rate is reported from the DSLAM to the NAS, and the reported rate already has DSL overhead accounted for (as specified in the text in bold below). What exactly is the confusion ? =20 . Type (Actual-Data-Rate-Upstream =3D 0x81): Actual data rate upstream = of a synchronized DSL line. This is a mandatory TLV. This rate value and all the subsequent ones account for the DSL overhead (i.e. signify the net rate). =20 -Sanjay -----Original Message----- From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] Sent: Thursday, November 08, 2007 4:12 AM To: REYNDERS Paul; Sanjay Wadhwa Cc: ancp@ietf.org; DE CNODDER Stefaan Subject: RE: [ANCP] PORT UP Data Rate? Precisely. So we seem to agree that the appropriate edits need to be made in the protocol draft to clarify this? Section 3.1 of the framework draft should also see a minor edit to the term "DSL sync rate", and the use of the full "net data rate" term as introduced in the terminology section. =20 Regards, Woj. =20 =20 _____ =20 From: REYNDERS Paul [mailto:paul.reynders@alcatel-lucent.be]=20 Sent: 07 November 2007 14:09 To: Sanjay Wadhwa Cc: ancp@ietf.org; DE CNODDER Stefaan; Wojciech Dec (wdec) Subject: RE: [ANCP] PORT UP Data Rate? The DSL overhead is not transmitted between NAS and Access Node. As such, the DSL data rate that includes DSL overhead ("Sanjay's net data rate") must not be input for the Hierarchical Scheduling by NAS. For this HS, NAS needs DSL data rate that excluding DSL overhead ("Stefaan's net data rate"). The latter also decouples the access line technology (ADSL, EFM,...) from the aggregation network technology (ATM, Ethernet). Also consider the difficulties HS at NAS may have with evolving subsciber line transmission technologies if the data rate reported to NAS includes "DSL overhead". =20 Paul Reynders Alcatel-Lucent Bell NV=20 Copernicuslaan 50, 2018 Antwerp, Belgium _____ =20 From: Sanjay Wadhwa [mailto:swadhwa@juniper.net]=20 Sent: woensdag 7 november 2007 13:13 To: DE CNODDER Stefaan; Wojciech Dec (wdec) Cc: ancp@ietf.org Subject: RE: [ANCP] PORT UP Data Rate? The reported rate is "net data rate" (includes DSL overhead). The protocol draft explicitly mentions it: =20 . Type (Actual-Data-Rate-Upstream =3D 0x81): Actual data rate upstream = of a synchronized DSL line. This is a mandatory TLV. This rate value and all the subsequent ones account for the DSL overhead (i.e. signify the net rate). =20 -Sanjay =20 -----Original Message----- From: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be]=20 Sent: Wednesday, November 07, 2007 4:24 AM To: Wojciech Dec (wdec) Cc: ancp@ietf.org Subject: Re: [ANCP] PORT UP Data Rate? =20 =20 Woj, =20 It looks to me that the framework document is correct, and that the=20 protocol draft has to replace "data rate" by "net data rate" to make it=20 more accurate, i.e., for istance: =20 Type (Actual-Data-Rate-Upstream =3D 0x81) : Actual data rate upstream of = a synchronized DSL line... =20 should be =20 Type (Actual-Data-Rate-Upstream =3D 0x81) : Actual net data rate = upstream=20 of a synchronized DSL line... =20 The term "net data rate" is accurately defined in section 1.2 of the=20 framework document by referring to the ITU standard. =20 I hope we all have the same understanding of the definition of the=20 bandwidth advertised by ANCP. =20 regards, Stefaan =20 =20 =20 ------_=_NextPart_001_01C821F0.F0D11BFC Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
 As I said in my previous mail, the = protocol=20 draft is quite explicit. The rate is reported from the DSLAM to the NAS, = and the=20 reported rate already has DSL overhead accounted for (as specified in = the text=20 in bold below). What exactly is the confusion ?
 
. Type (Actual-Data-Rate-Upstream =3D = 0x81): Actual=20 data rate upstream  of a synchronized DSL line. This is a mandatory = TLV. This=20 rate value and all the subsequent ones account for the DSL overhead = (i.e.=20 signify the net rate).
 
-Sanjay

-----Original Message-----
From: Wojciech Dec (wdec)=20 [mailto:wdec@cisco.com]
Sent: Thursday, November 08, 2007 4:12 = AM
To: REYNDERS Paul; Sanjay Wadhwa
Cc: = ancp@ietf.org; DE=20 CNODDER Stefaan
Subject: RE: [ANCP] PORT UP Data=20 Rate?

Precisely. So we seem to agree that the appropriate = edits need to=20 be made in the protocol draft to clarify this? Section 3.1 of the = framework=20 draft should also see a minor edit to the term "DSL sync rate", and = the use of=20 the full "net data rate" term as introduced in the terminology=20 section.
 
Regards,
Woj.
 
 

From: REYNDERS Paul=20 [mailto:paul.reynders@alcatel-lucent.be]
Sent: 07 = November 2007=20 14:09
To: Sanjay Wadhwa
Cc: ancp@ietf.org; DE = CNODDER=20 Stefaan; Wojciech Dec (wdec)
Subject: RE: [ANCP] PORT UP = Data=20 Rate?

The DSL overhead is not transmitted = between NAS and=20 Access Node. As such, the DSL data rate that includes DSL overhead=20 ("Sanjay's net data rate") must not be input for the Hierarchical = Scheduling=20 by NAS. For this HS, NAS needs DSL data rate = that excluding DSL=20 overhead ("Stefaan's net data rate"). The latter also decouples the = access=20 line technology (ADSL, EFM,...) from the aggregation network = technology=20 (ATM, Ethernet).
Also consider the difficulties HS at NAS = may have=20 with evolving subsciber line transmission technologies if the data = rate=20 reported to NAS includes "DSL overhead".
 
Paul Reynders

Alcatel-Lucent=20 Bell NV
Copernicuslaan=20 50, 2018 Antwerp, Belgium
From: Sanjay Wadhwa=20 [mailto:swadhwa@juniper.net]
Sent: woensdag 7 november = 2007=20 13:13
To: DE CNODDER Stefaan; Wojciech Dec = (wdec)
Cc:=20 ancp@ietf.org
Subject: RE: [ANCP] PORT UP Data=20 Rate?

The reported rate is "net data rate" = (includes DSL=20 overhead). The protocol draft explicitly mentions=20 it:

 

. Type (Actual-Data-Rate-Upstream =3D = 0x81): Actual=20 data rate upstream of a synchronized DSL line. This is a mandatory=20 TLV.

This rate value and = all the=20 subsequent ones account for the DSL overhead (i.e. signify the net=20 rate).

 

-Sanjay

 

-----Original Message-----
From: = Stefaan DE=20 CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be]
Sent: = Wednesday,=20 November 07, 2007 4:24 AM
To: Wojciech Dec (wdec)
Cc:=20 ancp@ietf.org
Subject: Re: [ANCP] PORT UP Data = Rate?

 

 

Woj,

 

It looks to me that the framework document = is=20 correct, and that the

protocol draft has to replace "data rate" = by "net=20 data rate" to make it

more accurate, i.e., for=20 istance:

 

Type (Actual-Data-Rate-Upstream =3D 0x81) = : Actual=20 data rate upstream of a

synchronized DSL=20 line...

 

should be

 

Type (Actual-Data-Rate-Upstream =3D 0x81) = : Actual net=20 data rate upstream

of a synchronized DSL=20 line...

 

The term "net data rate" is accurately = defined in=20 section 1.2 of the

framework document by referring to the ITU = standard.

 

I hope we all have the same understanding = of the=20 definition of the

bandwidth advertised by=20 ANCP.

 

regards,

Stefaan

 

 

 

= ------_=_NextPart_001_01C821F0.F0D11BFC-- --===============1902978427== 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 --===============1902978427==-- From ancp-bounces@ietf.org Thu Nov 08 06:20:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq5Qg-0001hZ-IR; Thu, 08 Nov 2007 06:20:10 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1Iq58c-0000DK-Bw for ancp-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 06:01:30 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq58b-0000DC-Vq for ancp@ietf.org; Thu, 08 Nov 2007 06:01:30 -0500 Received: from colt-na7.alcatel.fr ([62.23.212.7] helo=smail6.alcatel.fr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iq58Z-00021R-Rj for ancp@ietf.org; Thu, 08 Nov 2007 06:01:29 -0500 Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.ad2.ad.alcatel.com [155.132.6.74]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id lA8B0BPv016079; Thu, 8 Nov 2007 12:00:11 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.52]) by FRVELSBHS02.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 8 Nov 2007 12:01:24 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ANCP] PORT UP Data Rate? Date: Thu, 8 Nov 2007 12:01:23 +0100 Message-ID: <238382595265324EA50F6134BB42DCAF0107133D@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C280AB4368B@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] PORT UP Data Rate? Thread-Index: AcghH/7GTW3zYySvTTOnYYLYBQQt3gAFbufQAAHWziAAKmzQQAABKV6AAAKv8QA= References: <9BD5D7887235424FA97DFC223CAE3C280AB4368B@proton.jnpr.net> From: "REYNDERS Paul" To: "Sanjay Wadhwa" X-OriginalArrivalTime: 08 Nov 2007 11:01:24.0851 (UTC) FILETIME=[B42BF430:01C821F6] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: b6435b1bfa5977f2eb96dc7e52434b6d X-Mailman-Approved-At: Thu, 08 Nov 2007 06:20:09 -0500 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: , Content-Type: multipart/mixed; boundary="===============1999455272==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============1999455272== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C821F6.B3B6622A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C821F6.B3B6622A Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Sanjay, =20 i think the confusion is about the wording "account for the DSL overhead". To my knowledge of the english language (i'm a dutch speaker), this can mean:=20 "make allowance for the DSL overhead". =20 Regards, Paul Reynders ________________________________ From: Sanjay Wadhwa [mailto:swadhwa@juniper.net]=20 Sent: donderdag 8 november 2007 11:20 To: Wojciech Dec (wdec); REYNDERS Paul Cc: ancp@ietf.org; DE CNODDER Stefaan Subject: RE: [ANCP] PORT UP Data Rate? As I said in my previous mail, the protocol draft is quite explicit. The rate is reported from the DSLAM to the NAS, and the reported rate already has DSL overhead accounted for (as specified in the text in bold below). What exactly is the confusion ? =20 . Type (Actual-Data-Rate-Upstream =3D 0x81): Actual data rate upstream = of a synchronized DSL line. This is a mandatory TLV. This rate value and all the subsequent ones account for the DSL overhead (i.e. signify the net rate). =20 -Sanjay -----Original Message----- From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] Sent: Thursday, November 08, 2007 4:12 AM To: REYNDERS Paul; Sanjay Wadhwa Cc: ancp@ietf.org; DE CNODDER Stefaan Subject: RE: [ANCP] PORT UP Data Rate? Precisely. So we seem to agree that the appropriate edits need to be made in the protocol draft to clarify this? Section 3.1 of the framework draft should also see a minor edit to the term "DSL sync rate", and the use of the full "net data rate" term as introduced in the terminology section. =20 Regards, Woj. =20 =20 ________________________________ From: REYNDERS Paul [mailto:paul.reynders@alcatel-lucent.be]=20 Sent: 07 November 2007 14:09 To: Sanjay Wadhwa Cc: ancp@ietf.org; DE CNODDER Stefaan; Wojciech Dec (wdec) Subject: RE: [ANCP] PORT UP Data Rate? =09 =09 The DSL overhead is not transmitted between NAS and Access Node. As such, the DSL data rate that includes DSL overhead ("Sanjay's net data rate") must not be input for the Hierarchical Scheduling by NAS. For this HS, NAS needs DSL data rate that excluding DSL overhead ("Stefaan's net data rate"). The latter also decouples the access line technology (ADSL, EFM,...) from the aggregation network technology (ATM, Ethernet). Also consider the difficulties HS at NAS may have with evolving subsciber line transmission technologies if the data rate reported to NAS includes "DSL overhead". =20 Paul Reynders =09 =09 Alcatel-Lucent Bell NV=20 Copernicuslaan 50, 2018 Antwerp, Belgium ________________________________ From: Sanjay Wadhwa [mailto:swadhwa@juniper.net]=20 Sent: woensdag 7 november 2007 13:13 To: DE CNODDER Stefaan; Wojciech Dec (wdec) Cc: ancp@ietf.org Subject: RE: [ANCP] PORT UP Data Rate? =09 =09 The reported rate is "net data rate" (includes DSL overhead). The protocol draft explicitly mentions it: =20 . Type (Actual-Data-Rate-Upstream =3D 0x81): Actual data rate upstream of a synchronized DSL line. This is a mandatory TLV. This rate value and all the subsequent ones account for the DSL overhead (i.e. signify the net rate). =20 -Sanjay =20 -----Original Message----- From: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be]=20 Sent: Wednesday, November 07, 2007 4:24 AM To: Wojciech Dec (wdec) Cc: ancp@ietf.org Subject: Re: [ANCP] PORT UP Data Rate? =20 =20 Woj, =20 It looks to me that the framework document is correct, and that the=20 protocol draft has to replace "data rate" by "net data rate" to make it=20 more accurate, i.e., for istance: =20 Type (Actual-Data-Rate-Upstream =3D 0x81) : Actual data rate upstream of a=20 synchronized DSL line... =20 should be =20 Type (Actual-Data-Rate-Upstream =3D 0x81) : Actual net data rate upstream=20 of a synchronized DSL line... =20 The term "net data rate" is accurately defined in section 1.2 of the=20 framework document by referring to the ITU standard. =20 I hope we all have the same understanding of the definition of the=20 bandwidth advertised by ANCP. =20 regards, Stefaan =20 =20 =20 ------_=_NextPart_001_01C821F6.B3B6622A Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi Sanjay,
 
i think the confusion is about the wording "account for the DSL = overhead".
To my knowledge of the english language (i'm a dutch speaker), = this=20 can mean:
"make allowance for the DSL overhead".
 
Regards,
Paul Reynders

From: Sanjay Wadhwa = [mailto:swadhwa@juniper.net]=20
Sent: donderdag 8 november 2007 11:20
To: Wojciech = Dec=20 (wdec); REYNDERS Paul
Cc: ancp@ietf.org; DE CNODDER=20 Stefaan
Subject: RE: [ANCP] PORT UP Data = Rate?

 As I said in my previous mail, the = protocol=20 draft is quite explicit. The rate is reported from the DSLAM to the NAS, = and the=20 reported rate already has DSL overhead accounted for (as specified in = the text=20 in bold below). What exactly is the confusion ?
 
. Type (Actual-Data-Rate-Upstream =3D = 0x81): Actual=20 data rate upstream  of a synchronized DSL line. This is a mandatory = TLV. This=20 rate value and all the subsequent ones account for the DSL overhead = (i.e.=20 signify the net rate).
 
-Sanjay

-----Original Message-----
From: Wojciech Dec (wdec)=20 [mailto:wdec@cisco.com]
Sent: Thursday, November 08, 2007 4:12 = AM
To: REYNDERS Paul; Sanjay Wadhwa
Cc: = ancp@ietf.org; DE=20 CNODDER Stefaan
Subject: RE: [ANCP] PORT UP Data=20 Rate?

Precisely. So we seem to agree that the appropriate = edits need to=20 be made in the protocol draft to clarify this? Section 3.1 of the = framework=20 draft should also see a minor edit to the term "DSL sync rate", and = the use of=20 the full "net data rate" term as introduced in the terminology=20 section.
 
Regards,
Woj.
 
 

From: REYNDERS Paul=20 [mailto:paul.reynders@alcatel-lucent.be]
Sent: 07 = November 2007=20 14:09
To: Sanjay Wadhwa
Cc: ancp@ietf.org; DE = CNODDER=20 Stefaan; Wojciech Dec (wdec)
Subject: RE: [ANCP] PORT UP = Data=20 Rate?

The DSL overhead is not transmitted = between NAS and=20 Access Node. As such, the DSL data rate that includes DSL overhead=20 ("Sanjay's net data rate") must not be input for the Hierarchical = Scheduling=20 by NAS. For this HS, NAS needs DSL data rate = that excluding DSL=20 overhead ("Stefaan's net data rate"). The latter also decouples the = access=20 line technology (ADSL, EFM,...) from the aggregation network = technology=20 (ATM, Ethernet).
Also consider the difficulties HS at NAS = may have=20 with evolving subsciber line transmission technologies if the data = rate=20 reported to NAS includes "DSL overhead".
 
Paul Reynders

Alcatel-Lucent=20 Bell NV
Copernicuslaan=20 50, 2018 Antwerp, Belgium
From: Sanjay Wadhwa=20 [mailto:swadhwa@juniper.net]
Sent: woensdag 7 november = 2007=20 13:13
To: DE CNODDER Stefaan; Wojciech Dec = (wdec)
Cc:=20 ancp@ietf.org
Subject: RE: [ANCP] PORT UP Data=20 Rate?

The reported rate is "net data rate" = (includes DSL=20 overhead). The protocol draft explicitly mentions=20 it:

 

. Type (Actual-Data-Rate-Upstream =3D = 0x81): Actual=20 data rate upstream of a synchronized DSL line. This is a mandatory=20 TLV.

This rate value and = all the=20 subsequent ones account for the DSL overhead (i.e. signify the net=20 rate).

 

-Sanjay

 

-----Original Message-----
From: = Stefaan DE=20 CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be]
Sent: = Wednesday,=20 November 07, 2007 4:24 AM
To: Wojciech Dec (wdec)
Cc:=20 ancp@ietf.org
Subject: Re: [ANCP] PORT UP Data = Rate?

 

 

Woj,

 

It looks to me that the framework document = is=20 correct, and that the

protocol draft has to replace "data rate" = by "net=20 data rate" to make it

more accurate, i.e., for=20 istance:

 

Type (Actual-Data-Rate-Upstream =3D 0x81) = : Actual=20 data rate upstream of a

synchronized DSL=20 line...

 

should be

 

Type (Actual-Data-Rate-Upstream =3D 0x81) = : Actual net=20 data rate upstream

of a synchronized DSL=20 line...

 

The term "net data rate" is accurately = defined in=20 section 1.2 of the

framework document by referring to the ITU = standard.

 

I hope we all have the same understanding = of the=20 definition of the

bandwidth advertised by=20 ANCP.

 

regards,

Stefaan

 

 

 

= ------_=_NextPart_001_01C821F6.B3B6622A-- --===============1999455272== 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 --===============1999455272==-- From ancp-bounces@ietf.org Thu Nov 08 06:20:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq5RD-0002Eq-Qi; Thu, 08 Nov 2007 06:20:43 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1Iq5RC-0002DP-HL for ancp-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 06:20:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq5RC-0002CN-3A for ancp@ietf.org; Thu, 08 Nov 2007 06:20:42 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iq5R6-0001Rm-UE for ancp@ietf.org; Thu, 08 Nov 2007 06:20:42 -0500 X-IronPort-AV: E=Sophos;i="4.21,388,1188770400"; d="scan'208,217";a="157153937" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 08 Nov 2007 12:19:40 +0100 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 lA8BJcOa002257; Thu, 8 Nov 2007 12:19:38 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lA8BJN8s014561; Thu, 8 Nov 2007 11:19:31 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Nov 2007 12:19:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ANCP] PORT UP Data Rate? Date: Thu, 8 Nov 2007 12:19:18 +0100 Message-ID: In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C280AB4368B@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] PORT UP Data Rate? Thread-Index: AcghH/7GTW3zYySvTTOnYYLYBQQt3gAFbufQAAHWziAAKmzQQAABKV6AAAMOhaA= References: <9BD5D7887235424FA97DFC223CAE3C280AB4368B@proton.jnpr.net> From: "Wojciech Dec (wdec)" To: "Sanjay Wadhwa" , "REYNDERS Paul" X-OriginalArrivalTime: 08 Nov 2007 11:19:25.0024 (UTC) FILETIME=[38014600:01C821F9] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15532.001 X-TM-AS-Result: No--19.640900-8.000000-2 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=23657; t=1194520778; x=1195384778; 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]=20PORT=20UP=20Data=20Rate? |Sender:=20; bh=9eQj2Y5vfJtaly0f9CLxohEZfdY9r7HO14SKbgyug+k=; b=X4trQndBXoW6jceMHpuK/CnlXslYzwXvH8dxszkUZ+i8hJ6bSDv8UheqKmpcd0zYDjbh1x4b zHUGh6sUEmwAiMleQUqFdXcepJrXFy9xjvpB3kxxrJhusLUvV+I71BG+; Authentication-Results: ams-dkim-1; header.From=wdec@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: d273fad2623d4a35a7bb17d92c76f399 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: , Content-Type: multipart/mixed; boundary="===============1869647481==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============1869647481== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C821F9.37B0DEB5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C821F9.37B0DEB5 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Please read these statements (from the mails in this thread), and let us know if it's the required minor change is still not clear. Also note that the net data rate term should be used in the description of both the upstream and downstream actual-rate TLVs. =20 --snip-- =20 The DSL overhead is not transmitted between NAS and Access Node. As such, the DSL data rate that includes DSL overhead ("Sanjay's net data rate") must not be input for the Hierarchical Scheduling by NAS. For this HS, NAS needs DSL data rate that excluding DSL overhead ("Stefaan's net data rate").=20 =20 And: =20 ---snip--- > . Type (Actual-Data-Rate-Upstream =3D 0x81): Actual data rate upstream = > of a synchronized DSL line. This is a mandatory TLV. >=20 > /This rate value and all the subsequent ones account for the DSL=20 > overhead (i.e. signify the net rate)./ Just unfortunate wording I would say... I think that "Accounting for DSL overhead" means "having substacted DSL overhead"; it does not mean "including DSL overhead". ("Including DSL overhead" cannot mean "DSL net rate") =20 ---snip--- Last but not least, a Terminology reference to the framework doc should be added, if not a terminology section outright. -Woj. =20 ________________________________ From: Sanjay Wadhwa [mailto:swadhwa@juniper.net]=20 Sent: 08 November 2007 11:20 To: Wojciech Dec (wdec); REYNDERS Paul Cc: ancp@ietf.org; DE CNODDER Stefaan Subject: RE: [ANCP] PORT UP Data Rate? =09 =09 As I said in my previous mail, the protocol draft is quite explicit. The rate is reported from the DSLAM to the NAS, and the reported rate already has DSL overhead accounted for (as specified in the text in bold below). What exactly is the confusion ? =20 . Type (Actual-Data-Rate-Upstream =3D 0x81): Actual data rate upstream of a synchronized DSL line. This is a mandatory TLV. This rate value and all the subsequent ones account for the DSL overhead (i.e. signify the net rate). =20 -Sanjay -----Original Message----- From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] Sent: Thursday, November 08, 2007 4:12 AM To: REYNDERS Paul; Sanjay Wadhwa Cc: ancp@ietf.org; DE CNODDER Stefaan Subject: RE: [ANCP] PORT UP Data Rate? =09 =09 Precisely. So we seem to agree that the appropriate edits need to be made in the protocol draft to clarify this? Section 3.1 of the framework draft should also see a minor edit to the term "DSL sync rate", and the use of the full "net data rate" term as introduced in the terminology section. =20 Regards, Woj. =20 =20 ________________________________ From: REYNDERS Paul [mailto:paul.reynders@alcatel-lucent.be]=20 Sent: 07 November 2007 14:09 To: Sanjay Wadhwa Cc: ancp@ietf.org; DE CNODDER Stefaan; Wojciech Dec (wdec) Subject: RE: [ANCP] PORT UP Data Rate? =09 =09 The DSL overhead is not transmitted between NAS and Access Node. As such, the DSL data rate that includes DSL overhead ("Sanjay's net data rate") must not be input for the Hierarchical Scheduling by NAS. For this HS, NAS needs DSL data rate that excluding DSL overhead ("Stefaan's net data rate"). The latter also decouples the access line technology (ADSL, EFM,...) from the aggregation network technology (ATM, Ethernet). Also consider the difficulties HS at NAS may have with evolving subsciber line transmission technologies if the data rate reported to NAS includes "DSL overhead". =20 Paul Reynders =09 =09 Alcatel-Lucent Bell NV=20 Copernicuslaan 50, 2018 Antwerp, Belgium ________________________________ From: Sanjay Wadhwa [mailto:swadhwa@juniper.net] Sent: woensdag 7 november 2007 13:13 To: DE CNODDER Stefaan; Wojciech Dec (wdec) Cc: ancp@ietf.org Subject: RE: [ANCP] PORT UP Data Rate? =09 =09 The reported rate is "net data rate" (includes DSL overhead). The protocol draft explicitly mentions it: =20 . Type (Actual-Data-Rate-Upstream =3D 0x81): Actual data rate upstream of a synchronized DSL line. This is a mandatory TLV. This rate value and all the subsequent ones account for the DSL overhead (i.e. signify the net rate). =20 -Sanjay =20 -----Original Message----- From: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be]=20 Sent: Wednesday, November 07, 2007 4:24 AM To: Wojciech Dec (wdec) Cc: ancp@ietf.org Subject: Re: [ANCP] PORT UP Data Rate? =20 =20 Woj, =20 It looks to me that the framework document is correct, and that the=20 protocol draft has to replace "data rate" by "net data rate" to make it=20 more accurate, i.e., for istance: =20 Type (Actual-Data-Rate-Upstream =3D 0x81) : Actual data rate upstream of a=20 synchronized DSL line... =20 should be =20 Type (Actual-Data-Rate-Upstream =3D 0x81) : Actual net data rate upstream=20 of a synchronized DSL line... =20 The term "net data rate" is accurately defined in section 1.2 of the=20 framework document by referring to the ITU standard. =20 I hope we all have the same understanding of the definition of the=20 bandwidth advertised by ANCP. =20 regards, Stefaan =20 =20 =20 ------_=_NextPart_001_01C821F9.37B0DEB5 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Please read = these=20 statements (from the mails in this thread), and let us know if it's the = required=20 minor change is still not clear. Also note that the net data rate = term=20 should be used in the description of both the upstream and downstream=20 actual-rate TLVs.
 
--snip--
 
The DSL overhead is not transmitted between = NAS and=20 Access Node. As such, the DSL data rate that includes DSL = overhead=20 ("Sanjay's net data rate") must not be input for the Hierarchical = Scheduling by=20 NAS. For this HS, NAS needs DSL data rate that excluding DSL = overhead=20 ("Stefaan's net data rate").
 
And:
 
---snip---

> . Type (Actual-Data-Rate-Upstream =3D 0x81): = Actual data rate=20 upstream

> of a synchronized DSL line. This is a mandatory=20 TLV.

>

> /This rate value and all the subsequent ones = account for=20 the DSL

> overhead (i.e. signify the net rate)./

Just unfortunate wording I would say...

I think that "Accounting for DSL overhead" means = "having=20 substacted DSL overhead"; it does not mean "including DSL = overhead".

("Including DSL overhead" cannot mean "DSL net = rate")

 

---snip---

Last but=20 not least, a Terminology reference to the framework doc should be added, = if not=20 a terminology section outright.

-Woj.

 


From: Sanjay Wadhwa=20 [mailto:swadhwa@juniper.net]
Sent: 08 November 2007=20 11:20
To: Wojciech Dec (wdec); REYNDERS Paul
Cc:=20 ancp@ietf.org; DE CNODDER Stefaan
Subject: RE: [ANCP] PORT = UP Data=20 Rate?

 As I said in my previous = mail, the=20 protocol draft is quite explicit. The rate is reported from the DSLAM = to the=20 NAS, and the reported rate already has DSL overhead accounted for (as=20 specified in the text in bold below). What exactly is the = confusion=20 ?
 
. Type (Actual-Data-Rate-Upstream =3D = 0x81): Actual=20 data rate upstream  of a synchronized DSL line. This is a = mandatory=20 TLV. This rate value and all the subsequent ones account = for the=20 DSL overhead (i.e. signify the net=20 rate).
 
-Sanjay

-----Original Message-----
From: = Wojciech Dec=20 (wdec) [mailto:wdec@cisco.com]
Sent: Thursday, November 08, = 2007=20 4:12 AM
To: REYNDERS Paul; Sanjay Wadhwa
Cc:=20 ancp@ietf.org; DE CNODDER Stefaan
Subject: RE: [ANCP] PORT = UP Data=20 Rate?

Precisely. So we seem to agree that the appropriate = edits need=20 to be made in the protocol draft to clarify this? Section 3.1 of the = framework draft should also see a minor edit to the term "DSL sync = rate",=20 and the use of the full "net data rate" term as introduced in the=20 terminology section.
 
Regards,
Woj.
 
 

From: REYNDERS Paul=20 [mailto:paul.reynders@alcatel-lucent.be]
Sent: 07 = November 2007=20 14:09
To: Sanjay Wadhwa
Cc: ancp@ietf.org; DE = CNODDER=20 Stefaan; Wojciech Dec (wdec)
Subject: RE: [ANCP] PORT UP = Data=20 Rate?

The DSL overhead is not transmitted = between NAS=20 and Access Node. As such, the DSL data rate that includes DSL = overhead=20 ("Sanjay's net data rate") must not be input for the Hierarchical=20 Scheduling by NAS. For this HS, NAS needs DSL data rate=20 that excluding DSL overhead ("Stefaan's net data rate"). The = latter=20 also decouples the access line technology (ADSL, EFM,...) from the = aggregation network technology (ATM, = Ethernet).
Also consider the difficulties HS at = NAS may have=20 with evolving subsciber line transmission technologies if the data = rate=20 reported to NAS includes "DSL overhead".
 
Paul Reynders

Alcatel-Lucent Bell NV=20
Copernicuslaan 50, 2018 = Antwerp,=20 Belgium
From: Sanjay Wadhwa=20 [mailto:swadhwa@juniper.net]
Sent: woensdag 7 november = 2007=20 13:13
To: DE CNODDER Stefaan; Wojciech Dec = (wdec)
Cc:=20 ancp@ietf.org
Subject: RE: [ANCP] PORT UP Data=20 Rate?

The reported rate is "net data rate" = (includes DSL=20 overhead). The protocol draft explicitly mentions=20 it:

 

. Type (Actual-Data-Rate-Upstream =3D = 0x81): Actual=20 data rate upstream of a synchronized DSL line. This is a mandatory = TLV.

This rate value and = all the=20 subsequent ones account for the DSL overhead (i.e. signify the net = rate).

 

-Sanjay

 

-----Original Message-----
From: = Stefaan DE=20 CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be]
Sent: = Wednesday,=20 November 07, 2007 4:24 AM
To: Wojciech Dec (wdec)
Cc:=20 ancp@ietf.org
Subject: Re: [ANCP] PORT UP Data = Rate?

 

 

Woj,

 

It looks to me that the framework = document is=20 correct, and that the

protocol draft has to replace "data = rate" by "net=20 data rate" to make it

more accurate, i.e., for=20 istance:

 

Type (Actual-Data-Rate-Upstream =3D = 0x81) : Actual=20 data rate upstream of a

synchronized DSL=20 line...

 

should be

 

Type (Actual-Data-Rate-Upstream =3D = 0x81) : Actual=20 net data rate upstream

of a synchronized DSL=20 line...

 

The term "net data rate" is accurately = defined in=20 section 1.2 of the

framework document by referring to the = ITU=20 standard.

 

I hope we all have the same = understanding of the=20 definition of the

bandwidth advertised by=20 ANCP.

 

regards,

Stefaan

 

 

 

=
------_=_NextPart_001_01C821F9.37B0DEB5-- --===============1869647481== 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 --===============1869647481==-- From ancp-bounces@ietf.org Thu Nov 08 06:43:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq5nc-0004wb-Ic; Thu, 08 Nov 2007 06:43:52 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1Iq5na-0004un-4A for ancp-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 06:43:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq5nZ-0004uN-Dx for ancp@ietf.org; Thu, 08 Nov 2007 06:43:49 -0500 Received: from exprod7og102.obsmtp.com ([64.18.2.157]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iq5nV-00028q-Jq for ancp@ietf.org; Thu, 08 Nov 2007 06:43:49 -0500 Received: from source ([66.129.224.36]) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP; Thu, 08 Nov 2007 03:43:16 PST Received: from proton.jnpr.net ([10.10.2.37]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Nov 2007 03:43:22 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ANCP] PORT UP Data Rate? Date: Thu, 8 Nov 2007 06:43:20 -0500 Message-ID: <9BD5D7887235424FA97DFC223CAE3C280AB4368E@proton.jnpr.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] PORT UP Data Rate? Thread-Index: AcghH/7GTW3zYySvTTOnYYLYBQQt3gAFbufQAAHWziAAKmzQQAABKV6AAAMOhaAAAJrr0A== From: "Sanjay Wadhwa" To: "Wojciech Dec (wdec)" , "REYNDERS Paul" X-OriginalArrivalTime: 08 Nov 2007 11:43:22.0601 (UTC) FILETIME=[90DE1D90:01C821FC] X-Spam-Score: -4.0 (----) X-Scan-Signature: b8a1197ccd66a793eeb911fe8a37f5bd 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: , Content-Type: multipart/mixed; boundary="===============1538472820==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============1538472820== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C821FC.8F953EDC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C821FC.8F953EDC Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable No, it is not clear to me from from the statements below that we need to change anything. Can you let me know where in the draft does it say that DSL overhead is transmitted between NAS and the Access Node (as mentioned by one of the statements below)? As Robert says (included his original mail below), the confusion came about when I used the word "include overhead" in my mail (note : this is not in the draft). I clarified that "include overhead" in my mail was meant as "DSLAM should include overhead in calcuation of the net rate".=20 =20 -Sanjay -----Original Message----- From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] Sent: Thursday, November 08, 2007 6:19 AM To: Sanjay Wadhwa; REYNDERS Paul Cc: ancp@ietf.org; DE CNODDER Stefaan Subject: RE: [ANCP] PORT UP Data Rate? Please read these statements (from the mails in this thread), and let us know if it's the required minor change is still not clear. Also note that the net data rate term should be used in the description of both the upstream and downstream actual-rate TLVs. =20 --snip-- =20 The DSL overhead is not transmitted between NAS and Access Node. As such, the DSL data rate that includes DSL overhead ("Sanjay's net data rate") must not be input for the Hierarchical Scheduling by NAS. For this HS, NAS needs DSL data rate that excluding DSL overhead ("Stefaan's net data rate").=20 =20 And: =20 ---snip--- [[SW]] =20 >-----Original Message----- >From: PESCHI Robert [mailto:Robert.Peschi@alcatel-lucent.be] >Sent: Wednesday, November 07, 2007 8:13 AM >To: DE CNODDER Stefaan; Sanjay Wadhwa >Cc: ancp@ietf.org >Subject: RE: [ANCP] PORT UP Data Rate? > > >Sanjay Wadhwa wrote: >> The reported rate is "net data rate" (includes DSL overhead). The protocol draft explicitly mentions it: >> . Type (Actual-Data-Rate-Upstream =3D 0x81): Actual data rate = upstream of a synchronized DSL line. This is a mandatory TLV. >> /This rate value and all the subsequent ones account for the DSL overhead (i.e. signify the net rate)./ > >Just unfortunate wording I would say... > >I think that "Accounting for DSL overhead" means "having substacted DSL >overhead"; >it does not mean "including DSL overhead". =20 =20 ---snip--- Last but not least, a Terminology reference to the framework doc should be added, if not a terminology section outright. -Woj. =20 _____ =20 From: Sanjay Wadhwa [mailto:swadhwa@juniper.net]=20 Sent: 08 November 2007 11:20 To: Wojciech Dec (wdec); REYNDERS Paul Cc: ancp@ietf.org; DE CNODDER Stefaan Subject: RE: [ANCP] PORT UP Data Rate? As I said in my previous mail, the protocol draft is quite explicit. The rate is reported from the DSLAM to the NAS, and the reported rate already has DSL overhead accounted for (as specified in the text in bold below). What exactly is the confusion ? =20 . Type (Actual-Data-Rate-Upstream =3D 0x81): Actual data rate upstream = of a synchronized DSL line. This is a mandatory TLV. This rate value and all the subsequent ones account for the DSL overhead (i.e. signify the net rate). =20 -Sanjay -----Original Message----- From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] Sent: Thursday, November 08, 2007 4:12 AM To: REYNDERS Paul; Sanjay Wadhwa Cc: ancp@ietf.org; DE CNODDER Stefaan Subject: RE: [ANCP] PORT UP Data Rate? Precisely. So we seem to agree that the appropriate edits need to be made in the protocol draft to clarify this? Section 3.1 of the framework draft should also see a minor edit to the term "DSL sync rate", and the use of the full "net data rate" term as introduced in the terminology section. =20 Regards, Woj. =20 =20 _____ =20 From: REYNDERS Paul [mailto:paul.reynders@alcatel-lucent.be]=20 Sent: 07 November 2007 14:09 To: Sanjay Wadhwa Cc: ancp@ietf.org; DE CNODDER Stefaan; Wojciech Dec (wdec) Subject: RE: [ANCP] PORT UP Data Rate? The DSL overhead is not transmitted between NAS and Access Node. As such, the DSL data rate that includes DSL overhead ("Sanjay's net data rate") must not be input for the Hierarchical Scheduling by NAS. For this HS, NAS needs DSL data rate that excluding DSL overhead ("Stefaan's net data rate"). The latter also decouples the access line technology (ADSL, EFM,...) from the aggregation network technology (ATM, Ethernet). Also consider the difficulties HS at NAS may have with evolving subsciber line transmission technologies if the data rate reported to NAS includes "DSL overhead". =20 Paul Reynders Alcatel-Lucent Bell NV=20 Copernicuslaan 50, 2018 Antwerp, Belgium _____ =20 From: Sanjay Wadhwa [mailto:swadhwa@juniper.net]=20 Sent: woensdag 7 november 2007 13:13 To: DE CNODDER Stefaan; Wojciech Dec (wdec) Cc: ancp@ietf.org Subject: RE: [ANCP] PORT UP Data Rate? The reported rate is "net data rate" (includes DSL overhead). The protocol draft explicitly mentions it: =20 . Type (Actual-Data-Rate-Upstream =3D 0x81): Actual data rate upstream = of a synchronized DSL line. This is a mandatory TLV. This rate value and all the subsequent ones account for the DSL overhead (i.e. signify the net rate). =20 -Sanjay =20 -----Original Message----- From: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be]=20 Sent: Wednesday, November 07, 2007 4:24 AM To: Wojciech Dec (wdec) Cc: ancp@ietf.org Subject: Re: [ANCP] PORT UP Data Rate? =20 =20 Woj, =20 It looks to me that the framework document is correct, and that the=20 protocol draft has to replace "data rate" by "net data rate" to make it=20 more accurate, i.e., for istance: =20 Type (Actual-Data-Rate-Upstream =3D 0x81) : Actual data rate upstream of = a synchronized DSL line... =20 should be =20 Type (Actual-Data-Rate-Upstream =3D 0x81) : Actual net data rate = upstream=20 of a synchronized DSL line... =20 The term "net data rate" is accurately defined in section 1.2 of the=20 framework document by referring to the ITU standard. =20 I hope we all have the same understanding of the definition of the=20 bandwidth advertised by ANCP. =20 regards, Stefaan =20 =20 =20 ------_=_NextPart_001_01C821FC.8F953EDC Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
No, it=20 is not clear to me from from the statements below that we need to change = anything. Can you let me know where in the draft does it say that = DSL=20 overhead is transmitted between NAS and the Access Node (as mentioned by = one of=20 the statements below)? As Robert says (included his original mail = below), the=20 confusion came about when I used the word "include overhead" in my mail = (note :=20 this is not in the draft). I clarified that "include overhead" in my = mail was=20 meant as "DSLAM should include overhead in calcuation = of the=20 net rate".
 
-Sanjay

 -----Original = Message-----
From:=20 Wojciech Dec (wdec) [mailto:wdec@cisco.com]
Sent: Thursday, = November=20 08, 2007 6:19 AM
To: Sanjay Wadhwa; REYNDERS = Paul
Cc:=20 ancp@ietf.org; DE CNODDER Stefaan
Subject: RE: [ANCP] PORT UP = Data=20 Rate?

Please = read these=20 statements (from the mails in this thread), and let us know if it's = the=20 required minor change is still not clear. Also note that the net = data=20 rate term should be used in the description of both the upstream and=20 downstream actual-rate TLVs.
 
--snip--
 
The DSL overhead is not transmitted between = NAS and=20 Access Node. As such, the DSL data rate that includes DSL = overhead=20 ("Sanjay's net data rate") must not be input for the Hierarchical = Scheduling=20 by NAS. For this HS, NAS needs DSL data rate that excluding = DSL=20 overhead ("Stefaan's net data rate").
 
And:
 
---snip---
[[SW]] 

>-----Original Message-----

>From: PESCHI Robert = [mailto:Robert.Peschi@alcatel-lucent.be]

>Sent: Wednesday, November 07, 2007 8:13 AM

>To: DE CNODDER Stefaan; Sanjay Wadhwa

>Cc: ancp@ietf.org

>Subject: RE: [ANCP] PORT UP Data Rate?

>

>

>Sanjay Wadhwa wrote:

>> The reported rate is "net data rate" (includes DSL = overhead).=20 The protocol draft explicitly mentions it:

>> . Type (Actual-Data-Rate-Upstream =3D 0x81): Actual data = rate=20 upstream of a synchronized DSL line. This is a mandatory TLV.

>>  /This rate value and all the subsequent ones account = for the=20 DSL  overhead (i.e. signify the net rate)./

>

>Just unfortunate wording I would say...

>

>I think that "Accounting for DSL overhead" means "having = substacted=20 DSL

>overhead";

>it does not mean "including DSL=20 overhead".

 

 

---snip---

Last=20 but not least, a Terminology reference to the framework doc should be = added,=20 if not a terminology section outright.

-Woj.

 


From: Sanjay Wadhwa=20 [mailto:swadhwa@juniper.net]
Sent: 08 November 2007=20 11:20
To: Wojciech Dec (wdec); REYNDERS Paul
Cc: = ancp@ietf.org; DE CNODDER Stefaan
Subject: RE: [ANCP] PORT = UP Data=20 Rate?

 As I said in my previous = mail, the=20 protocol draft is quite explicit. The rate is reported from the = DSLAM to the=20 NAS, and the reported rate already has DSL overhead accounted for = (as=20 specified in the text in bold below). What exactly is the = confusion=20 ?
 
. Type (Actual-Data-Rate-Upstream =3D = 0x81): Actual=20 data rate upstream  of a synchronized DSL line. This is a = mandatory=20 TLV. This rate value and all the subsequent ones account = for the=20 DSL overhead (i.e. signify the net=20 rate).
 
-Sanjay

-----Original Message-----
From: = Wojciech Dec=20 (wdec) [mailto:wdec@cisco.com]
Sent: Thursday, November = 08, 2007=20 4:12 AM
To: REYNDERS Paul; Sanjay Wadhwa
Cc:=20 ancp@ietf.org; DE CNODDER Stefaan
Subject: RE: [ANCP] PORT = UP Data=20 Rate?

Precisely. So we seem to agree that the appropriate = edits need=20 to be made in the protocol draft to clarify this? Section 3.1 of = the=20 framework draft should also see a minor edit to the term "DSL sync = rate",=20 and the use of the full "net data rate" term as introduced in the=20 terminology section.
 
Regards,
Woj.
 
 

From: REYNDERS Paul=20 [mailto:paul.reynders@alcatel-lucent.be]
Sent: 07 = November=20 2007 14:09
To: Sanjay Wadhwa
Cc: = ancp@ietf.org; DE=20 CNODDER Stefaan; Wojciech Dec (wdec)
Subject: RE: = [ANCP] PORT=20 UP Data Rate?

The DSL overhead is not transmitted = between NAS=20 and Access Node. As such, the DSL data rate that includes DSL = overhead=20 ("Sanjay's net data rate") must not be input for the = Hierarchical=20 Scheduling by NAS. For this HS, NAS needs DSL data rate=20 that excluding DSL overhead ("Stefaan's net data rate"). = The latter=20 also decouples the access line technology (ADSL, EFM,...) from = the=20 aggregation network technology (ATM, = Ethernet).
Also consider the difficulties HS at = NAS may=20 have with evolving subsciber line transmission technologies if = the data=20 rate reported to NAS includes "DSL = overhead".
 
Paul Reynders

Alcatel-Lucent Bell NV=20
Copernicuslaan 50, 2018 = Antwerp,=20 Belgium
From: Sanjay Wadhwa=20 [mailto:swadhwa@juniper.net]
Sent: woensdag 7 = november 2007=20 13:13
To: DE CNODDER Stefaan; Wojciech Dec=20 (wdec)
Cc: ancp@ietf.org
Subject: RE: [ANCP] = PORT UP=20 Data Rate?

The reported rate is "net data rate" = (includes=20 DSL overhead). The protocol draft explicitly mentions=20 it:

 

. Type (Actual-Data-Rate-Upstream =3D = 0x81):=20 Actual data rate upstream of a synchronized DSL line. This is a=20 mandatory TLV.

This rate value = and all the=20 subsequent ones account for the DSL overhead (i.e. signify the = net=20 rate).

 

-Sanjay

 

-----Original Message-----
From: = Stefaan DE=20 CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be]
Sent:=20 Wednesday, November 07, 2007 4:24 AM
To: Wojciech Dec = (wdec)
Cc:=20 ancp@ietf.org
Subject: Re: [ANCP] PORT UP Data=20 Rate?

 

 

Woj,

 

It looks to me that the framework = document is=20 correct, and that the

protocol draft has to replace "data = rate" by=20 "net data rate" to make it

more accurate, i.e., for=20 istance:

 

Type (Actual-Data-Rate-Upstream =3D = 0x81) : Actual=20 data rate upstream of a

synchronized DSL=20 line...

 

should be

 

Type (Actual-Data-Rate-Upstream =3D = 0x81) : Actual=20 net data rate upstream

of a synchronized DSL=20 line...

 

The term "net data rate" is accurately = defined=20 in section 1.2 of the

framework document by referring to the = ITU=20 standard.

 

I hope we all have the same = understanding of the=20 definition of the

bandwidth advertised by=20 ANCP.

 

regards,

Stefaan

 

 

 

=
------_=_NextPart_001_01C821FC.8F953EDC-- --===============1538472820== 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 --===============1538472820==-- From ancp-bounces@ietf.org Thu Nov 08 06:48:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq5sU-0002bY-1C; Thu, 08 Nov 2007 06:48:54 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1Iq5sQ-0002at-Ij for ancp-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 06:48:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq5sQ-0002al-8i for ancp@ietf.org; Thu, 08 Nov 2007 06:48:50 -0500 Received: from exprod7og111.obsmtp.com ([64.18.2.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iq5sI-0002LH-Vk for ancp@ietf.org; Thu, 08 Nov 2007 06:48:50 -0500 Received: from source ([66.129.224.36]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Thu, 08 Nov 2007 03:48:37 PST Received: from proton.jnpr.net ([10.10.2.37]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Nov 2007 03:48:31 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ANCP] PORT UP Data Rate? Date: Thu, 8 Nov 2007 06:48:29 -0500 Message-ID: <9BD5D7887235424FA97DFC223CAE3C280AB4368F@proton.jnpr.net> In-Reply-To: <238382595265324EA50F6134BB42DCAF0107133D@FRVELSMBS22.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] PORT UP Data Rate? Thread-Index: AcghH/7GTW3zYySvTTOnYYLYBQQt3gAFbufQAAHWziAAKmzQQAABKV6AAAKv8QAAAaS1gA== From: "Sanjay Wadhwa" To: "REYNDERS Paul" X-OriginalArrivalTime: 08 Nov 2007 11:48:31.0769 (UTC) FILETIME=[49256890:01C821FD] X-Spam-Score: -4.0 (----) X-Scan-Signature: 7a3b79fd9d7bf2ef1762376a62c51ec4 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: , Content-Type: multipart/mixed; boundary="===============2013180844==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============2013180844== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C821FD.47EA8298" This is a multi-part message in MIME format. ------_=_NextPart_001_01C821FD.47EA8298 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Would it be clearer if it said "Access Node reports the rate after accounting for the DSL overhead i.e. it reports the net rate" ? If not, please suggest suitable verbiage. =20 Thanks -Sanjay -----Original Message----- From: REYNDERS Paul [mailto:paul.reynders@alcatel-lucent.be] Sent: Thursday, November 08, 2007 6:01 AM To: Sanjay Wadhwa Cc: ancp@ietf.org Subject: RE: [ANCP] PORT UP Data Rate? Hi Sanjay, =20 i think the confusion is about the wording "account for the DSL overhead". To my knowledge of the english language (i'm a dutch speaker), this can mean:=20 "make allowance for the DSL overhead". =20 Regards, Paul Reynders _____ =20 From: Sanjay Wadhwa [mailto:swadhwa@juniper.net]=20 Sent: donderdag 8 november 2007 11:20 To: Wojciech Dec (wdec); REYNDERS Paul Cc: ancp@ietf.org; DE CNODDER Stefaan Subject: RE: [ANCP] PORT UP Data Rate? As I said in my previous mail, the protocol draft is quite explicit. The rate is reported from the DSLAM to the NAS, and the reported rate already has DSL overhead accounted for (as specified in the text in bold below). What exactly is the confusion ? =20 . Type (Actual-Data-Rate-Upstream =3D 0x81): Actual data rate upstream = of a synchronized DSL line. This is a mandatory TLV. This rate value and all the subsequent ones account for the DSL overhead (i.e. signify the net rate). =20 -Sanjay -----Original Message----- From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] Sent: Thursday, November 08, 2007 4:12 AM To: REYNDERS Paul; Sanjay Wadhwa Cc: ancp@ietf.org; DE CNODDER Stefaan Subject: RE: [ANCP] PORT UP Data Rate? Precisely. So we seem to agree that the appropriate edits need to be made in the protocol draft to clarify this? Section 3.1 of the framework draft should also see a minor edit to the term "DSL sync rate", and the use of the full "net data rate" term as introduced in the terminology section. =20 Regards, Woj. =20 =20 _____ =20 From: REYNDERS Paul [mailto:paul.reynders@alcatel-lucent.be]=20 Sent: 07 November 2007 14:09 To: Sanjay Wadhwa Cc: ancp@ietf.org; DE CNODDER Stefaan; Wojciech Dec (wdec) Subject: RE: [ANCP] PORT UP Data Rate? The DSL overhead is not transmitted between NAS and Access Node. As such, the DSL data rate that includes DSL overhead ("Sanjay's net data rate") must not be input for the Hierarchical Scheduling by NAS. For this HS, NAS needs DSL data rate that excluding DSL overhead ("Stefaan's net data rate"). The latter also decouples the access line technology (ADSL, EFM,...) from the aggregation network technology (ATM, Ethernet). Also consider the difficulties HS at NAS may have with evolving subsciber line transmission technologies if the data rate reported to NAS includes "DSL overhead". =20 Paul Reynders Alcatel-Lucent Bell NV=20 Copernicuslaan 50, 2018 Antwerp, Belgium _____ =20 From: Sanjay Wadhwa [mailto:swadhwa@juniper.net]=20 Sent: woensdag 7 november 2007 13:13 To: DE CNODDER Stefaan; Wojciech Dec (wdec) Cc: ancp@ietf.org Subject: RE: [ANCP] PORT UP Data Rate? The reported rate is "net data rate" (includes DSL overhead). The protocol draft explicitly mentions it: =20 . Type (Actual-Data-Rate-Upstream =3D 0x81): Actual data rate upstream = of a synchronized DSL line. This is a mandatory TLV. This rate value and all the subsequent ones account for the DSL overhead (i.e. signify the net rate). =20 -Sanjay =20 -----Original Message----- From: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be]=20 Sent: Wednesday, November 07, 2007 4:24 AM To: Wojciech Dec (wdec) Cc: ancp@ietf.org Subject: Re: [ANCP] PORT UP Data Rate? =20 =20 Woj, =20 It looks to me that the framework document is correct, and that the=20 protocol draft has to replace "data rate" by "net data rate" to make it=20 more accurate, i.e., for istance: =20 Type (Actual-Data-Rate-Upstream =3D 0x81) : Actual data rate upstream of = a synchronized DSL line... =20 should be =20 Type (Actual-Data-Rate-Upstream =3D 0x81) : Actual net data rate = upstream=20 of a synchronized DSL line... =20 The term "net data rate" is accurately defined in section 1.2 of the=20 framework document by referring to the ITU standard. =20 I hope we all have the same understanding of the definition of the=20 bandwidth advertised by ANCP. =20 regards, Stefaan =20 =20 =20 ------_=_NextPart_001_01C821FD.47EA8298 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Would=20 it be clearer if it said "Access Node reports the rate after accounting = for the=20 DSL overhead i.e. it reports the net rate" ? If not, please suggest = suitable verbiage.
 
Thanks
-Sanjay
-----Original Message-----
From: REYNDERS Paul=20 [mailto:paul.reynders@alcatel-lucent.be]
Sent: Thursday, = November=20 08, 2007 6:01 AM
To: Sanjay Wadhwa
Cc:=20 ancp@ietf.org
Subject: RE: [ANCP] PORT UP Data=20 Rate?

Hi Sanjay,
 
i think the confusion is about the wording "account for the = DSL=20 overhead".
To my knowledge of the english language (i'm a dutch = speaker), this=20 can mean:
"make allowance for the DSL overhead".
 
Regards,
Paul Reynders

From: Sanjay Wadhwa=20 [mailto:swadhwa@juniper.net]
Sent: donderdag 8 november = 2007=20 11:20
To: Wojciech Dec (wdec); REYNDERS Paul
Cc:=20 ancp@ietf.org; DE CNODDER Stefaan
Subject: RE: [ANCP] PORT = UP Data=20 Rate?

 As I said in my previous = mail, the=20 protocol draft is quite explicit. The rate is reported from the DSLAM = to the=20 NAS, and the reported rate already has DSL overhead accounted for (as=20 specified in the text in bold below). What exactly is the = confusion=20 ?
 
. Type (Actual-Data-Rate-Upstream =3D = 0x81): Actual=20 data rate upstream  of a synchronized DSL line. This is a = mandatory=20 TLV. This rate value and all the subsequent ones account = for the=20 DSL overhead (i.e. signify the net=20 rate).
 
-Sanjay

-----Original Message-----
From: = Wojciech Dec=20 (wdec) [mailto:wdec@cisco.com]
Sent: Thursday, November 08, = 2007=20 4:12 AM
To: REYNDERS Paul; Sanjay Wadhwa
Cc:=20 ancp@ietf.org; DE CNODDER Stefaan
Subject: RE: [ANCP] PORT = UP Data=20 Rate?

Precisely. So we seem to agree that the appropriate = edits need=20 to be made in the protocol draft to clarify this? Section 3.1 of the = framework draft should also see a minor edit to the term "DSL sync = rate",=20 and the use of the full "net data rate" term as introduced in the=20 terminology section.
 
Regards,
Woj.
 
 

From: REYNDERS Paul=20 [mailto:paul.reynders@alcatel-lucent.be]
Sent: 07 = November 2007=20 14:09
To: Sanjay Wadhwa
Cc: ancp@ietf.org; DE = CNODDER=20 Stefaan; Wojciech Dec (wdec)
Subject: RE: [ANCP] PORT UP = Data=20 Rate?

The DSL overhead is not transmitted = between NAS=20 and Access Node. As such, the DSL data rate that includes DSL = overhead=20 ("Sanjay's net data rate") must not be input for the Hierarchical=20 Scheduling by NAS. For this HS, NAS needs DSL data rate=20 that excluding DSL overhead ("Stefaan's net data rate"). The = latter=20 also decouples the access line technology (ADSL, EFM,...) from the = aggregation network technology (ATM, = Ethernet).
Also consider the difficulties HS at = NAS may have=20 with evolving subsciber line transmission technologies if the data = rate=20 reported to NAS includes "DSL overhead".
 
Paul Reynders

Alcatel-Lucent Bell NV=20
Copernicuslaan 50, 2018 = Antwerp,=20 Belgium
From: Sanjay Wadhwa=20 [mailto:swadhwa@juniper.net]
Sent: woensdag 7 november = 2007=20 13:13
To: DE CNODDER Stefaan; Wojciech Dec = (wdec)
Cc:=20 ancp@ietf.org
Subject: RE: [ANCP] PORT UP Data=20 Rate?

The reported rate is "net data rate" = (includes DSL=20 overhead). The protocol draft explicitly mentions=20 it:

 

. Type (Actual-Data-Rate-Upstream =3D = 0x81): Actual=20 data rate upstream of a synchronized DSL line. This is a mandatory = TLV.

This rate value and = all the=20 subsequent ones account for the DSL overhead (i.e. signify the net = rate).

 

-Sanjay

 

-----Original Message-----
From: = Stefaan DE=20 CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be]
Sent: = Wednesday,=20 November 07, 2007 4:24 AM
To: Wojciech Dec (wdec)
Cc:=20 ancp@ietf.org
Subject: Re: [ANCP] PORT UP Data = Rate?

 

 

Woj,

 

It looks to me that the framework = document is=20 correct, and that the

protocol draft has to replace "data = rate" by "net=20 data rate" to make it

more accurate, i.e., for=20 istance:

 

Type (Actual-Data-Rate-Upstream =3D = 0x81) : Actual=20 data rate upstream of a

synchronized DSL=20 line...

 

should be

 

Type (Actual-Data-Rate-Upstream =3D = 0x81) : Actual=20 net data rate upstream

of a synchronized DSL=20 line...

 

The term "net data rate" is accurately = defined in=20 section 1.2 of the

framework document by referring to the = ITU=20 standard.

 

I hope we all have the same = understanding of the=20 definition of the

bandwidth advertised by=20 ANCP.

 

regards,

Stefaan

 

 

 

=
------_=_NextPart_001_01C821FD.47EA8298-- --===============2013180844== 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 --===============2013180844==-- From ancp-bounces@ietf.org Thu Nov 08 07:00:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq63d-00077i-5h; Thu, 08 Nov 2007 07:00:25 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1Iq63b-00076s-Cn for ancp-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 07:00:23 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq63a-00076k-Jy for ancp@ietf.org; Thu, 08 Nov 2007 07:00:22 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iq63Y-0003rJ-3a for ancp@ietf.org; Thu, 08 Nov 2007 07:00:22 -0500 X-IronPort-AV: E=Sophos;i="4.21,389,1188770400"; d="scan'208,217";a="157158880" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 08 Nov 2007 13:00:19 +0100 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 lA8C0IHM015316; Thu, 8 Nov 2007 13:00:18 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lA8C0E8k000689; Thu, 8 Nov 2007 12:00:14 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Nov 2007 13:00:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ANCP] PORT UP Data Rate? Date: Thu, 8 Nov 2007 13:00:06 +0100 Message-ID: In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C280AB4368E@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] PORT UP Data Rate? Thread-Index: AcghH/7GTW3zYySvTTOnYYLYBQQt3gAFbufQAAHWziAAKmzQQAABKV6AAAMOhaAAAJrr0AAA1bxA References: <9BD5D7887235424FA97DFC223CAE3C280AB4368E@proton.jnpr.net> From: "Wojciech Dec (wdec)" To: "Sanjay Wadhwa" , "REYNDERS Paul" X-OriginalArrivalTime: 08 Nov 2007 12:00:14.0327 (UTC) FILETIME=[EBE74070:01C821FE] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15532.001 X-TM-AS-Result: No--23.487200-8.000000-2 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=32743; t=1194523218; x=1195387218; 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]=20PORT=20UP=20Data=20Rate? |Sender:=20; bh=4S3Qy6qCziDkbjB/p8xV9Snwj1SBPWJY9z5/P5S82qk=; b=wi1ioVPvxsw3jnYRwvyEEnYXZ2dh7i9Z5g4gsJyk8gmI/hJkiBcDUuMv5VxAh0KNkFYB9ZpI AB+GygsdbDLFmSiXmd/AfAdd0wfw/8/PosP7vXtDbgGV/CRBcFkt9V07; Authentication-Results: ams-dkim-1; header.From=wdec@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: d1330b60dd48fa5cb1958a0aa669d18b 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: , Content-Type: multipart/mixed; boundary="===============0387828763==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0387828763== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C821FE.EB984242" This is a multi-part message in MIME format. ------_=_NextPart_001_01C821FE.EB984242 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable The text currently has some rather unfortunate wording which leaves too much room for an incorrect interpretation (the data rate question I originally posted was in fact a result of a customer pointing out the issue). Instead the text should say: =20 (Actual-Data-Rate-Upstream =3D 0x81): ... specify it as NET DATA RATE... = + removing any mention of "accounting for the DSL overhead" (Actual-Data-Rate-Downstream=3D 0x82): ...specify it as NET DATA = RATE... For clarity one may also remove the term "synchronised DSL line" unless there a case of an unsynchronised DSL line for which the actual data rate would be transmitted. =20 Finally, a terminology reference needs to be made (likely a new section added, with appropriate cross reference to the terminology used in the framework draft). =20 Hopefully the above makes things clearer, otherwise please let us know. =20 -Woj. ________________________________ From: Sanjay Wadhwa [mailto:swadhwa@juniper.net]=20 Sent: 08 November 2007 12:43 To: Wojciech Dec (wdec); REYNDERS Paul Cc: ancp@ietf.org; DE CNODDER Stefaan Subject: RE: [ANCP] PORT UP Data Rate? =09 =09 No, it is not clear to me from from the statements below that we need to change anything. Can you let me know where in the draft does it say that DSL overhead is transmitted between NAS and the Access Node (as mentioned by one of the statements below)? As Robert says (included his original mail below), the confusion came about when I used the word "include overhead" in my mail (note : this is not in the draft). I clarified that "include overhead" in my mail was meant as "DSLAM should include overhead in calcuation of the net rate".=20 =20 -Sanjay =09 -----Original Message----- From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] Sent: Thursday, November 08, 2007 6:19 AM To: Sanjay Wadhwa; REYNDERS Paul Cc: ancp@ietf.org; DE CNODDER Stefaan Subject: RE: [ANCP] PORT UP Data Rate? =09 =09 Please read these statements (from the mails in this thread), and let us know if it's the required minor change is still not clear. Also note that the net data rate term should be used in the description of both the upstream and downstream actual-rate TLVs. =20 --snip-- =20 The DSL overhead is not transmitted between NAS and Access Node. As such, the DSL data rate that includes DSL overhead ("Sanjay's net data rate") must not be input for the Hierarchical Scheduling by NAS. For this HS, NAS needs DSL data rate that excluding DSL overhead ("Stefaan's net data rate").=20 =20 And: =20 ---snip--- [[SW]] =20 >-----Original Message----- >From: PESCHI Robert [mailto:Robert.Peschi@alcatel-lucent.be] >Sent: Wednesday, November 07, 2007 8:13 AM >To: DE CNODDER Stefaan; Sanjay Wadhwa >Cc: ancp@ietf.org >Subject: RE: [ANCP] PORT UP Data Rate? > > >Sanjay Wadhwa wrote: >> The reported rate is "net data rate" (includes DSL overhead). The protocol draft explicitly mentions it: >> . Type (Actual-Data-Rate-Upstream =3D 0x81): Actual data rate upstream of a synchronized DSL line. This is a mandatory TLV. >> /This rate value and all the subsequent ones account for the DSL overhead (i.e. signify the net rate)./ > >Just unfortunate wording I would say... > >I think that "Accounting for DSL overhead" means "having substacted DSL >overhead"; >it does not mean "including DSL overhead". =20 =09 =20 ---snip--- Last but not least, a Terminology reference to the framework doc should be added, if not a terminology section outright. -Woj. =20 ________________________________ From: Sanjay Wadhwa [mailto:swadhwa@juniper.net] Sent: 08 November 2007 11:20 To: Wojciech Dec (wdec); REYNDERS Paul Cc: ancp@ietf.org; DE CNODDER Stefaan Subject: RE: [ANCP] PORT UP Data Rate? =09 =09 As I said in my previous mail, the protocol draft is quite explicit. The rate is reported from the DSLAM to the NAS, and the reported rate already has DSL overhead accounted for (as specified in the text in bold below). What exactly is the confusion ? =20 . Type (Actual-Data-Rate-Upstream =3D 0x81): Actual data rate upstream of a synchronized DSL line. This is a mandatory TLV. This rate value and all the subsequent ones account for the DSL overhead (i.e. signify the net rate). =20 -Sanjay -----Original Message----- From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] Sent: Thursday, November 08, 2007 4:12 AM To: REYNDERS Paul; Sanjay Wadhwa Cc: ancp@ietf.org; DE CNODDER Stefaan Subject: RE: [ANCP] PORT UP Data Rate? =09 =09 Precisely. So we seem to agree that the appropriate edits need to be made in the protocol draft to clarify this? Section 3.1 of the framework draft should also see a minor edit to the term "DSL sync rate", and the use of the full "net data rate" term as introduced in the terminology section. =20 Regards, Woj. =20 =20 ________________________________ From: REYNDERS Paul [mailto:paul.reynders@alcatel-lucent.be]=20 Sent: 07 November 2007 14:09 To: Sanjay Wadhwa Cc: ancp@ietf.org; DE CNODDER Stefaan; Wojciech Dec (wdec) Subject: RE: [ANCP] PORT UP Data Rate? =09 =09 The DSL overhead is not transmitted between NAS and Access Node. As such, the DSL data rate that includes DSL overhead ("Sanjay's net data rate") must not be input for the Hierarchical Scheduling by NAS. For this HS, NAS needs DSL data rate that excluding DSL overhead ("Stefaan's net data rate"). The latter also decouples the access line technology (ADSL, EFM,...) from the aggregation network technology (ATM, Ethernet). Also consider the difficulties HS at NAS may have with evolving subsciber line transmission technologies if the data rate reported to NAS includes "DSL overhead". =20 Paul Reynders =09 =09 Alcatel-Lucent Bell NV=20 Copernicuslaan 50, 2018 Antwerp, Belgium ________________________________ From: Sanjay Wadhwa [mailto:swadhwa@juniper.net]=20 Sent: woensdag 7 november 2007 13:13 To: DE CNODDER Stefaan; Wojciech Dec (wdec) Cc: ancp@ietf.org Subject: RE: [ANCP] PORT UP Data Rate? =09 =09 The reported rate is "net data rate" (includes DSL overhead). The protocol draft explicitly mentions it: =20 . Type (Actual-Data-Rate-Upstream =3D 0x81): Actual data rate upstream of a synchronized DSL line. This is a mandatory TLV. This rate value and all the subsequent ones account for the DSL overhead (i.e. signify the net rate). =20 -Sanjay =20 -----Original Message----- From: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be]=20 Sent: Wednesday, November 07, 2007 4:24 AM To: Wojciech Dec (wdec) Cc: ancp@ietf.org Subject: Re: [ANCP] PORT UP Data Rate? =20 =20 Woj, =20 It looks to me that the framework document is correct, and that the=20 protocol draft has to replace "data rate" by "net data rate" to make it=20 more accurate, i.e., for istance: =20 Type (Actual-Data-Rate-Upstream =3D 0x81) : Actual data rate upstream of a=20 synchronized DSL line... =20 should be =20 Type (Actual-Data-Rate-Upstream =3D 0x81) : Actual net data rate upstream=20 of a synchronized DSL line... =20 The term "net data rate" is accurately defined in section 1.2 of the=20 framework document by referring to the ITU standard. =20 I hope we all have the same understanding of the definition of the=20 bandwidth advertised by ANCP. =20 regards, Stefaan =20 =20 =20 ------_=_NextPart_001_01C821FE.EB984242 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
The text currently has some rather unfortunate wording which = leaves too=20 much room for an incorrect interpretation  (the data rate = question I=20 originally posted was in fact a result of a customer pointing out the=20 issue).
Instead the text should say:
 
(Actual-Data-Rate-Upstream =3D 0x81): ... = specify it as=20 NET DATA RATE... + removing any mention of "accounting for the=20 DSL overhead"
(Actual-Data-Rate-Downstream=3D 0x82):  = ...specify=20 it as NET DATA RATE...
For clarity one may also remove the term = "synchronised=20 DSL line" unless there a case of an unsynchronised DSL line for = which the=20 actual data rate would be transmitted.
 
Finally, a = terminology=20 reference needs to be made (likely a new section added, with appropriate = cross=20 reference to the terminology used in the framework=20 draft).
 
Hopefully the = above makes=20 things clearer, otherwise please let us know.
 
-Woj.

From: Sanjay Wadhwa=20 [mailto:swadhwa@juniper.net]
Sent: 08 November 2007=20 12:43
To: Wojciech Dec (wdec); REYNDERS Paul
Cc:=20 ancp@ietf.org; DE CNODDER Stefaan
Subject: RE: [ANCP] PORT = UP Data=20 Rate?

No,=20 it is not clear to me from from the statements below that we need to = change=20 anything. Can you let me know where in the draft does it say that = DSL=20 overhead is transmitted between NAS and the Access Node (as mentioned = by one=20 of the statements below)? As Robert says (included his original mail = below),=20 the confusion came about when I used the word "include overhead" in my = mail=20 (note : this is not in the draft). I clarified that "include overhead" = in my=20 mail was meant as "DSLAM should include overhead in=20 calcuation of the net rate".
 
-Sanjay

 -----Original = Message-----
From:=20 Wojciech Dec (wdec) [mailto:wdec@cisco.com]
Sent: Thursday, = November=20 08, 2007 6:19 AM
To: Sanjay Wadhwa; REYNDERS = Paul
Cc:=20 ancp@ietf.org; DE CNODDER Stefaan
Subject: RE: [ANCP] PORT = UP Data=20 Rate?

Please = read these=20 statements (from the mails in this thread), and let us know if it's = the=20 required minor change is still not clear. Also note that the = net data=20 rate term should be used in the description of both the upstream and = downstream actual-rate TLVs.
 
--snip--
 
The DSL overhead is not transmitted = between NAS and=20 Access Node. As such, the DSL data rate that includes DSL = overhead=20 ("Sanjay's net data rate") must not be input for the Hierarchical = Scheduling=20 by NAS. For this HS, NAS needs DSL data rate = that excluding DSL=20 overhead ("Stefaan's net data rate").
 
And:
 
---snip---
[[SW]] =20

>-----Original Message-----

>From: PESCHI Robert = [mailto:Robert.Peschi@alcatel-lucent.be]

>Sent: Wednesday, November 07, 2007 8:13 AM

>To: DE CNODDER Stefaan; Sanjay Wadhwa

>Cc: ancp@ietf.org

>Subject: RE: [ANCP] PORT UP Data Rate?

>

>

>Sanjay Wadhwa wrote:

>> The reported rate is "net data rate" (includes DSL = overhead).=20 The protocol draft explicitly mentions it:

>> . Type (Actual-Data-Rate-Upstream =3D 0x81): Actual data = rate=20 upstream of a synchronized DSL line. This is a mandatory = TLV.

>>  /This rate value and all the subsequent ones = account for=20 the DSL  overhead (i.e. signify the net rate)./

>

>Just unfortunate wording I would say...

>

>I think that "Accounting for DSL overhead" means "having = substacted=20 DSL

>overhead";

>it does not mean "including DSL=20 overhead".

 

 

---snip---

Last=20 but not least, a Terminology reference to the framework doc should = be added,=20 if not a terminology section outright.

-Woj.

 


From: Sanjay Wadhwa=20 [mailto:swadhwa@juniper.net]
Sent: 08 November 2007=20 11:20
To: Wojciech Dec (wdec); REYNDERS = Paul
Cc:=20 ancp@ietf.org; DE CNODDER Stefaan
Subject: RE: [ANCP] = PORT UP=20 Data Rate?

 As I said in my previous = mail, the=20 protocol draft is quite explicit. The rate is reported from the = DSLAM to=20 the NAS, and the reported rate already has DSL overhead accounted = for (as=20 specified in the text in bold below). What exactly is the = confusion=20 ?
 
. Type (Actual-Data-Rate-Upstream = =3D 0x81):=20 Actual data rate upstream  of a synchronized DSL line. This = is a=20 mandatory TLV. This rate value and all the subsequent ones = account for the=20 DSL overhead (i.e. signify the net=20 rate).
 
-Sanjay

-----Original Message-----
From: = Wojciech Dec=20 (wdec) [mailto:wdec@cisco.com]
Sent: Thursday, November = 08, 2007=20 4:12 AM
To: REYNDERS Paul; Sanjay Wadhwa
Cc:=20 ancp@ietf.org; DE CNODDER Stefaan
Subject: RE: [ANCP] = PORT UP=20 Data Rate?

Precisely. So we seem to agree that the = appropriate edits=20 need to be made in the protocol draft to clarify this? Section = 3.1 of=20 the framework draft should also see a minor edit to the term = "DSL sync=20 rate", and the use of the full "net data rate" term as = introduced in the=20 terminology section.
 
Regards,
Woj.
 
 

From: REYNDERS Paul=20 [mailto:paul.reynders@alcatel-lucent.be]
Sent: 07 = November=20 2007 14:09
To: Sanjay Wadhwa
Cc: = ancp@ietf.org; DE=20 CNODDER Stefaan; Wojciech Dec (wdec)
Subject: RE: = [ANCP]=20 PORT UP Data Rate?

The DSL overhead is not transmitted = between=20 NAS and Access Node. As such, the DSL data rate that includes = DSL=20 overhead ("Sanjay's net data rate") must not be input for the=20 Hierarchical Scheduling by NAS. For this HS, NAS needs = DSL data=20 rate that excluding DSL overhead ("Stefaan's net data = rate"). The=20 latter also decouples the access line technology (ADSL, = EFM,...) from=20 the aggregation network technology (ATM,=20 Ethernet).
Also consider the difficulties HS = at NAS may=20 have with evolving subsciber line transmission technologies if = the=20 data rate reported to NAS includes "DSL = overhead".
 
Paul Reynders

Alcatel-Lucent Bell = NV=20
Copernicuslaan 50, = 2018=20 Antwerp, Belgium
From: Sanjay Wadhwa=20 [mailto:swadhwa@juniper.net]
Sent: woensdag 7 = november 2007=20 13:13
To: DE CNODDER Stefaan; Wojciech Dec=20 (wdec)
Cc: ancp@ietf.org
Subject: RE: = [ANCP] PORT=20 UP Data Rate?

The reported rate is "net data rate" = (includes=20 DSL overhead). The protocol draft explicitly mentions=20 it:

 

. Type (Actual-Data-Rate-Upstream = =3D 0x81):=20 Actual data rate upstream of a synchronized DSL line. This is = a=20 mandatory TLV.

This rate value = and all=20 the subsequent ones account for the DSL overhead (i.e. signify = the net=20 rate).

 

-Sanjay

 

-----Original Message-----
From: = Stefaan DE=20 CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be] =
Sent:=20 Wednesday, November 07, 2007 4:24 AM
To: Wojciech Dec = (wdec)
Cc:=20 ancp@ietf.org
Subject: Re: [ANCP] PORT UP Data=20 Rate?

 

 

Woj,

 

It looks to me that the framework = document is=20 correct, and that the

protocol draft has to replace "data = rate" by=20 "net data rate" to make it

more accurate, i.e., for=20 istance:

 

Type (Actual-Data-Rate-Upstream =3D = 0x81) :=20 Actual data rate upstream of a

synchronized DSL=20 line...

 

should = be

 

Type (Actual-Data-Rate-Upstream =3D = 0x81) :=20 Actual net data rate upstream

of a synchronized DSL=20 line...

 

The term "net data rate" is = accurately defined=20 in section 1.2 of the

framework document by referring to = the ITU=20 standard.

 

I hope we all have the same = understanding of=20 the definition of the

bandwidth advertised by=20 ANCP.

 

regards,

Stefaan

 

 

 

=
------_=_NextPart_001_01C821FE.EB984242-- --===============0387828763== 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 --===============0387828763==-- From ancp-bounces@ietf.org Thu Nov 08 07:01:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq64c-0008KA-Ce; Thu, 08 Nov 2007 07:01:26 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1Iq64a-0008Is-Tp for ancp-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 07:01:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq64a-0008Ie-Eh for ancp@ietf.org; Thu, 08 Nov 2007 07:01:24 -0500 Received: from eci-iron.ecitele.com ([147.234.242.112] helo=iron.ecitele.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iq64Y-0003tD-0b for ancp@ietf.org; Thu, 08 Nov 2007 07:01:24 -0500 Received: from ilptexfe.ecitele.com (HELO ILPTEXFE01.ecitele.com) ([172.31.244.40]) by eci-iron-out.ecitele.com with ESMTP; 08 Nov 2007 14:02:49 +0200 Received: from ILPTMAIL01.ecitele.com ([147.234.245.211]) by ILPTEXFE01.ecitele.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Nov 2007 14:01:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ANCP] PORT UP Data Rate? Date: Thu, 8 Nov 2007 14:01:18 +0200 Message-ID: <83153A1EB675AF4F82E134FA27F95F67023D9238@ILPTEX02.ecitele.com> In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C280AB4368F@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] PORT UP Data Rate? Thread-Index: AcghH/7GTW3zYySvTTOnYYLYBQQt3gAFbufQAAHWziAAKmzQQAABKV6AAAKv8QAAAaS1gAAAOtaw References: <238382595265324EA50F6134BB42DCAF0107133D@FRVELSMBS22.ad2.ad.alcatel.com> <9BD5D7887235424FA97DFC223CAE3C280AB4368F@proton.jnpr.net> From: "Moti Morgenstern" To: "Sanjay Wadhwa" , "REYNDERS Paul" X-OriginalArrivalTime: 08 Nov 2007 12:01:20.0247 (UTC) FILETIME=[1331D870:01C821FF] X-Spam-Score: 0.0 (/) X-Scan-Signature: ce2737a971e141e0457c8c1bf182367f 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: , Content-Type: multipart/mixed; boundary="===============0288448321==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0288448321== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C821FF.133D986D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C821FF.133D986D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 'Accounting' means you should 'take into account'. It does not explicitly say that you are supposed to subtract the overhead from the total rate. So I suggest: "Access Node reports the DSL line rate after deducting the DSL overhead from it i.e. it reports the net rate". =20 Regards, Moti ________________________________ From: Sanjay Wadhwa [mailto:swadhwa@juniper.net]=20 Sent: Thursday, November 08, 2007 1:48 PM To: REYNDERS Paul Cc: ancp@ietf.org Subject: RE: [ANCP] PORT UP Data Rate? Would it be clearer if it said "Access Node reports the rate after accounting for the DSL overhead i.e. it reports the net rate" ? If not, please suggest suitable verbiage. =20 Thanks -Sanjay -----Original Message----- From: REYNDERS Paul [mailto:paul.reynders@alcatel-lucent.be] Sent: Thursday, November 08, 2007 6:01 AM To: Sanjay Wadhwa Cc: ancp@ietf.org Subject: RE: [ANCP] PORT UP Data Rate? =09 =09 Hi Sanjay, =20 i think the confusion is about the wording "account for the DSL overhead". To my knowledge of the english language (i'm a dutch speaker), this can mean:=20 "make allowance for the DSL overhead". =20 Regards, Paul Reynders ________________________________ From: Sanjay Wadhwa [mailto:swadhwa@juniper.net]=20 Sent: donderdag 8 november 2007 11:20 To: Wojciech Dec (wdec); REYNDERS Paul Cc: ancp@ietf.org; DE CNODDER Stefaan Subject: RE: [ANCP] PORT UP Data Rate? =09 =09 As I said in my previous mail, the protocol draft is quite explicit. The rate is reported from the DSLAM to the NAS, and the reported rate already has DSL overhead accounted for (as specified in the text in bold below). What exactly is the confusion ? =20 . Type (Actual-Data-Rate-Upstream =3D 0x81): Actual data rate upstream of a synchronized DSL line. This is a mandatory TLV. This rate value and all the subsequent ones account for the DSL overhead (i.e. signify the net rate). =20 -Sanjay -----Original Message----- From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] Sent: Thursday, November 08, 2007 4:12 AM To: REYNDERS Paul; Sanjay Wadhwa Cc: ancp@ietf.org; DE CNODDER Stefaan Subject: RE: [ANCP] PORT UP Data Rate? =09 =09 Precisely. So we seem to agree that the appropriate edits need to be made in the protocol draft to clarify this? Section 3.1 of the framework draft should also see a minor edit to the term "DSL sync rate", and the use of the full "net data rate" term as introduced in the terminology section. =20 Regards, Woj. =20 =20 ________________________________ From: REYNDERS Paul [mailto:paul.reynders@alcatel-lucent.be]=20 Sent: 07 November 2007 14:09 To: Sanjay Wadhwa Cc: ancp@ietf.org; DE CNODDER Stefaan; Wojciech Dec (wdec) Subject: RE: [ANCP] PORT UP Data Rate? =09 =09 The DSL overhead is not transmitted between NAS and Access Node. As such, the DSL data rate that includes DSL overhead ("Sanjay's net data rate") must not be input for the Hierarchical Scheduling by NAS. For this HS, NAS needs DSL data rate that excluding DSL overhead ("Stefaan's net data rate"). The latter also decouples the access line technology (ADSL, EFM,...) from the aggregation network technology (ATM, Ethernet). Also consider the difficulties HS at NAS may have with evolving subsciber line transmission technologies if the data rate reported to NAS includes "DSL overhead". =20 Paul Reynders =09 =09 Alcatel-Lucent Bell NV=20 Copernicuslaan 50, 2018 Antwerp, Belgium ________________________________ From: Sanjay Wadhwa [mailto:swadhwa@juniper.net] Sent: woensdag 7 november 2007 13:13 To: DE CNODDER Stefaan; Wojciech Dec (wdec) Cc: ancp@ietf.org Subject: RE: [ANCP] PORT UP Data Rate? =09 =09 The reported rate is "net data rate" (includes DSL overhead). The protocol draft explicitly mentions it: =20 . Type (Actual-Data-Rate-Upstream =3D 0x81): Actual data rate upstream of a synchronized DSL line. This is a mandatory TLV. This rate value and all the subsequent ones account for the DSL overhead (i.e. signify the net rate). =20 -Sanjay =20 -----Original Message----- From: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be]=20 Sent: Wednesday, November 07, 2007 4:24 AM To: Wojciech Dec (wdec) Cc: ancp@ietf.org Subject: Re: [ANCP] PORT UP Data Rate? =20 =20 Woj, =20 It looks to me that the framework document is correct, and that the=20 protocol draft has to replace "data rate" by "net data rate" to make it=20 more accurate, i.e., for istance: =20 Type (Actual-Data-Rate-Upstream =3D 0x81) : Actual data rate upstream of a=20 synchronized DSL line... =20 should be =20 Type (Actual-Data-Rate-Upstream =3D 0x81) : Actual net data rate upstream=20 of a synchronized DSL line... =20 The term "net data rate" is accurately defined in section 1.2 of the=20 framework document by referring to the ITU standard. =20 I hope we all have the same understanding of the definition of the=20 bandwidth advertised by ANCP. =20 regards, Stefaan =20 =20 =20 ------_=_NextPart_001_01C821FF.133D986D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
'Accounting' means you should 'take into = account'.=20 It does not explicitly say that you are supposed to subtract the = overhead=20 from the total rate.
So = I suggest:=20 "Access Node reports the DSL line rate after deducting the DSL overhead = from=20 it i.e. it reports the net = rate".
 
Regards,
Moti

From: Sanjay Wadhwa = [mailto:swadhwa@juniper.net]=20
Sent: Thursday, November 08, 2007 1:48 PM
To: = REYNDERS=20 Paul
Cc: ancp@ietf.org
Subject: RE: [ANCP] PORT UP = Data=20 Rate?

Would=20 it be clearer if it said "Access Node reports the rate after accounting = for the=20 DSL overhead i.e. it reports the net rate" ? If not, please suggest = suitable verbiage.
 
Thanks
-Sanjay
-----Original Message-----
From: REYNDERS Paul=20 [mailto:paul.reynders@alcatel-lucent.be]
Sent: Thursday, = November=20 08, 2007 6:01 AM
To: Sanjay Wadhwa
Cc:=20 ancp@ietf.org
Subject: RE: [ANCP] PORT UP Data=20 Rate?

Hi Sanjay,
 
i think the confusion is about the wording "account for the = DSL=20 overhead".
To my knowledge of the english language (i'm a dutch = speaker), this=20 can mean:
"make allowance for the DSL overhead".
 
Regards,
Paul Reynders

From: Sanjay Wadhwa=20 [mailto:swadhwa@juniper.net]
Sent: donderdag 8 november = 2007=20 11:20
To: Wojciech Dec (wdec); REYNDERS Paul
Cc:=20 ancp@ietf.org; DE CNODDER Stefaan
Subject: RE: [ANCP] PORT = UP Data=20 Rate?

 As I said in my previous = mail, the=20 protocol draft is quite explicit. The rate is reported from the DSLAM = to the=20 NAS, and the reported rate already has DSL overhead accounted for (as=20 specified in the text in bold below). What exactly is the = confusion=20 ?
 
. Type (Actual-Data-Rate-Upstream =3D = 0x81): Actual=20 data rate upstream  of a synchronized DSL line. This is a = mandatory=20 TLV. This rate value and all the subsequent ones account = for the=20 DSL overhead (i.e. signify the net=20 rate).
 
-Sanjay

-----Original Message-----
From: = Wojciech Dec=20 (wdec) [mailto:wdec@cisco.com]
Sent: Thursday, November 08, = 2007=20 4:12 AM
To: REYNDERS Paul; Sanjay Wadhwa
Cc:=20 ancp@ietf.org; DE CNODDER Stefaan
Subject: RE: [ANCP] PORT = UP Data=20 Rate?

Precisely. So we seem to agree that the appropriate = edits need=20 to be made in the protocol draft to clarify this? Section 3.1 of the = framework draft should also see a minor edit to the term "DSL sync = rate",=20 and the use of the full "net data rate" term as introduced in the=20 terminology section.
 
Regards,
Woj.
 
 

From: REYNDERS Paul=20 [mailto:paul.reynders@alcatel-lucent.be]
Sent: 07 = November 2007=20 14:09
To: Sanjay Wadhwa
Cc: ancp@ietf.org; DE = CNODDER=20 Stefaan; Wojciech Dec (wdec)
Subject: RE: [ANCP] PORT UP = Data=20 Rate?

The DSL overhead is not transmitted = between NAS=20 and Access Node. As such, the DSL data rate that includes DSL = overhead=20 ("Sanjay's net data rate") must not be input for the Hierarchical=20 Scheduling by NAS. For this HS, NAS needs DSL data rate=20 that excluding DSL overhead ("Stefaan's net data rate"). The = latter=20 also decouples the access line technology (ADSL, EFM,...) from the = aggregation network technology (ATM, = Ethernet).
Also consider the difficulties HS at = NAS may have=20 with evolving subsciber line transmission technologies if the data = rate=20 reported to NAS includes "DSL overhead".
 
Paul Reynders

Alcatel-Lucent Bell NV=20
Copernicuslaan 50, 2018 = Antwerp,=20 Belgium
From: Sanjay Wadhwa=20 [mailto:swadhwa@juniper.net]
Sent: woensdag 7 november = 2007=20 13:13
To: DE CNODDER Stefaan; Wojciech Dec = (wdec)
Cc:=20 ancp@ietf.org
Subject: RE: [ANCP] PORT UP Data=20 Rate?

The reported rate is "net data rate" = (includes DSL=20 overhead). The protocol draft explicitly mentions=20 it:

 

. Type (Actual-Data-Rate-Upstream =3D = 0x81): Actual=20 data rate upstream of a synchronized DSL line. This is a mandatory = TLV.

This rate value and = all the=20 subsequent ones account for the DSL overhead (i.e. signify the net = rate).

 

-Sanjay

 

-----Original Message-----
From: = Stefaan DE=20 CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be]
Sent: = Wednesday,=20 November 07, 2007 4:24 AM
To: Wojciech Dec (wdec)
Cc:=20 ancp@ietf.org
Subject: Re: [ANCP] PORT UP Data = Rate?

 

 

Woj,

 

It looks to me that the framework = document is=20 correct, and that the

protocol draft has to replace "data = rate" by "net=20 data rate" to make it

more accurate, i.e., for=20 istance:

 

Type (Actual-Data-Rate-Upstream =3D = 0x81) : Actual=20 data rate upstream of a

synchronized DSL=20 line...

 

should be

 

Type (Actual-Data-Rate-Upstream =3D = 0x81) : Actual=20 net data rate upstream

of a synchronized DSL=20 line...

 

The term "net data rate" is accurately = defined in=20 section 1.2 of the

framework document by referring to the = ITU=20 standard.

 

I hope we all have the same = understanding of the=20 definition of the

bandwidth advertised by=20 ANCP.

 

regards,

Stefaan

 

 

 

=
------_=_NextPart_001_01C821FF.133D986D-- --===============0288448321== 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 --===============0288448321==-- From ancp-bounces@ietf.org Thu Nov 08 07:04:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq67P-00039F-6f; Thu, 08 Nov 2007 07:04:19 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1Iq67O-00038v-7p for ancp-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 07:04:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq67N-00038n-Rz for ancp@ietf.org; Thu, 08 Nov 2007 07:04:17 -0500 Received: from gc-na5.alcatel.fr ([64.208.49.5] helo=smail6.alcatel.fr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iq67M-0003xU-IR for ancp@ietf.org; Thu, 08 Nov 2007 07:04:17 -0500 Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.ad2.ad.alcatel.com [155.132.6.78]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id lA8C30L2002924; Thu, 8 Nov 2007 13:03:00 +0100 Received: from [135.248.40.185] ([135.248.40.185]) by FRVELSBHS06.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Thu, 8 Nov 2007 13:04:13 +0100 Message-ID: <4732FB37.3010500@alcatel-lucent.be> Date: Thu, 08 Nov 2007 13:04:07 +0100 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: Sanjay Wadhwa Subject: Re: [ANCP] PORT UP Data Rate? References: <9BD5D7887235424FA97DFC223CAE3C280AB4368E@proton.jnpr.net> In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C280AB4368E@proton.jnpr.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Nov 2007 12:04:13.0526 (UTC) FILETIME=[7A7A1F60:01C821FF] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8068004c042dabd7f1301bcc80e039df 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 It seems we all agree on what the bandwidth means and since these terms are defined accurately by the DSL Forum and ITU (see mail of Thomas) it looks to me that it is sufficient to add a reference to the DSLF or ITU documents. This should not be too difficult to do.... regards, Stefaan Sanjay Wadhwa wrote: > No, it is not clear to me from from the statements below that we need to > change anything. Can you let me know where in the draft does it say that > DSL overhead is transmitted between NAS and the Access Node (as > mentioned by one of the statements below)? As Robert says (included his > original mail below), the confusion came about when I used the word > "include overhead" in my mail (note : this is not in the draft). I > clarified that "include overhead" in my mail was meant as "DSLAM should > *include *overhead in calcuation of the net rate". > > -Sanjay > > -----Original Message----- > *From:* Wojciech Dec (wdec) [mailto:wdec@cisco.com] > *Sent:* Thursday, November 08, 2007 6:19 AM > *To:* Sanjay Wadhwa; REYNDERS Paul > *Cc:* ancp@ietf.org; DE CNODDER Stefaan > *Subject:* RE: [ANCP] PORT UP Data Rate? > > Please read these statements (from the mails in this thread), and > let us know if it's the required minor change is still not clear. > Also note that the net data rate term should be used in the > description of both the upstream and downstream actual-rate TLVs. > > --snip-- > > The DSL overhead is not transmitted between NAS and Access Node. *As > such, the DSL data rate that includes DSL overhead ("Sanjay's net > data rate") must not be input for the Hierarchical Scheduling by > NAS. For this HS, NAS needs DSL data rate that excluding DSL > overhead ("Stefaan's net data rate"). * > ** > And: > > ---snip--- > [[SW]] > >>-----Original Message----- > >>From: PESCHI Robert [mailto:Robert.Peschi@alcatel-lucent.be] > >>Sent: Wednesday, November 07, 2007 8:13 AM > >>To: DE CNODDER Stefaan; Sanjay Wadhwa > >>Cc: ancp@ietf.org > >>Subject: RE: [ANCP] PORT UP Data Rate? > >> > >> > >>Sanjay Wadhwa wrote: > >> > The reported rate is "net data rate" (includes DSL overhead). > The protocol draft explicitly mentions it: > >> > . Type (Actual-Data-Rate-Upstream = 0x81): Actual data rate > upstream of a synchronized DSL line. This is a mandatory TLV. > >> > /This rate value and all the subsequent ones account for the > DSL overhead (i.e. signify the net rate)./ > >> > >>Just unfortunate wording I would say... > >> > >>I think that "Accounting for DSL overhead" means "having substacted DSL > >>overhead"; > >>it does not mean "including DSL overhead". > > > > > > ---snip--- > > Last but not least, a Terminology reference to the framework doc > should be added, if not a terminology section outright. > > -Woj. > > > > > ------------------------------------------------------------------------ > *From:* Sanjay Wadhwa [mailto:swadhwa@juniper.net] > *Sent:* 08 November 2007 11:20 > *To:* Wojciech Dec (wdec); REYNDERS Paul > *Cc:* ancp@ietf.org; DE CNODDER Stefaan > *Subject:* RE: [ANCP] PORT UP Data Rate? > > As I said in my previous mail, the protocol draft is quite > explicit. The rate is reported from the DSLAM to the NAS, and > the reported rate already has DSL overhead accounted for (as > specified in the text in bold below). What exactly is the > confusion ? > > . Type (Actual-Data-Rate-Upstream = 0x81): Actual data rate > upstream of a synchronized DSL line. This is a mandatory > TLV. *This rate value and all the subsequent ones account for > the DSL overhead (i.e. signify the net rate).* > > *-Sanjay* > > **-----Original Message----- > *From:* Wojciech Dec (wdec) [mailto:wdec@cisco.com] > *Sent:* Thursday, November 08, 2007 4:12 AM > *To:* REYNDERS Paul; Sanjay Wadhwa > *Cc:* ancp@ietf.org; DE CNODDER Stefaan > *Subject:* RE: [ANCP] PORT UP Data Rate? > > Precisely. So we seem to agree that the appropriate edits > need to be made in the protocol draft to clarify this? > Section 3.1 of the framework draft should also see a minor > edit to the term "DSL sync rate", and the use of the full > "net data rate" term as introduced in the terminology section. > > Regards, > Woj. > > > > ------------------------------------------------------------------------ > *From:* REYNDERS Paul > [mailto:paul.reynders@alcatel-lucent.be] > *Sent:* 07 November 2007 14:09 > *To:* Sanjay Wadhwa > *Cc:* ancp@ietf.org; DE CNODDER Stefaan; Wojciech Dec (wdec) > *Subject:* RE: [ANCP] PORT UP Data Rate? > > The DSL overhead is not transmitted between NAS and > Access Node. As such, the DSL data rate that includes > DSL overhead ("Sanjay's net data rate") must not be > input for the Hierarchical Scheduling by NAS. For this > HS, NAS needs DSL data rate that excluding DSL overhead > ("Stefaan's net data rate"). The latter also decouples > the access line technology (ADSL, EFM,...) from the > aggregation network technology (ATM, Ethernet). > Also consider the difficulties HS at NAS may have with > evolving subsciber line transmission technologies if the > data rate reported to NAS includes "DSL overhead". > > Paul Reynders > > Alcatel-Lucent Bell NV > > Copernicuslaan 50, 2018 Antwerp, Belgium > > ------------------------------------------------------------------------ > *From:* Sanjay Wadhwa [mailto:swadhwa@juniper.net] > *Sent:* woensdag 7 november 2007 13:13 > *To:* DE CNODDER Stefaan; Wojciech Dec (wdec) > *Cc:* ancp@ietf.org > *Subject:* RE: [ANCP] PORT UP Data Rate? > > The reported rate is "net data rate" (includes DSL > overhead). The protocol draft explicitly mentions it: > > > > . Type (Actual-Data-Rate-Upstream = 0x81): Actual data > rate upstream of a synchronized DSL line. This is a > mandatory TLV. > > /This rate value and all the subsequent ones account for > the DSL overhead (i.e. signify the net rate)./ > > / / > > -Sanjay > > > > -----Original Message----- > From: Stefaan DE CNODDER > [mailto:stefaan.de_cnodder@alcatel-lucent.be] > Sent: Wednesday, November 07, 2007 4:24 AM > To: Wojciech Dec (wdec) > Cc: ancp@ietf.org > Subject: Re: [ANCP] PORT UP Data Rate? > > > > > > Woj, > > > > It looks to me that the framework document is correct, > and that the > > protocol draft has to replace "data rate" by "net data > rate" to make it > > more accurate, i.e., for istance: > > > > Type (Actual-Data-Rate-Upstream = 0x81) : Actual data > rate upstream of a > > synchronized DSL line... > > > > should be > > > > Type (Actual-Data-Rate-Upstream = 0x81) : Actual net > data rate upstream > > of a synchronized DSL line... > > > > The term "net data rate" is accurately defined in > section 1.2 of the > > framework document by referring to the ITU standard. > > > > I hope we all have the same understanding of the > definition of the > > bandwidth advertised by ANCP. > > > > regards, > > Stefaan > > > > > > > _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Thu Nov 08 07:23:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq6Pl-0004dJ-Ho; Thu, 08 Nov 2007 07:23:17 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1Iq6Pk-0004b3-4W for ancp-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 07:23:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq6Pj-0004au-Mk for ancp@ietf.org; Thu, 08 Nov 2007 07:23:15 -0500 Received: from exprod7og102.obsmtp.com ([64.18.2.157]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iq6Pe-0003BZ-DG for ancp@ietf.org; Thu, 08 Nov 2007 07:23:15 -0500 Received: from source ([66.129.224.36]) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP; Thu, 08 Nov 2007 04:22:54 PST Received: from proton.jnpr.net ([10.10.2.37]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Nov 2007 04:22:47 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ANCP] PORT UP Data Rate? Date: Thu, 8 Nov 2007 07:22:43 -0500 Message-ID: <9BD5D7887235424FA97DFC223CAE3C280AB43691@proton.jnpr.net> In-Reply-To: <83153A1EB675AF4F82E134FA27F95F67023D9238@ILPTEX02.ecitele.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] PORT UP Data Rate? Thread-Index: AcghH/7GTW3zYySvTTOnYYLYBQQt3gAFbufQAAHWziAAKmzQQAABKV6AAAKv8QAAAaS1gAAAOtawAADoppA= From: "Sanjay Wadhwa" To: "Moti Morgenstern" , "REYNDERS Paul" X-OriginalArrivalTime: 08 Nov 2007 12:22:47.0196 (UTC) FILETIME=[1246ADC0:01C82202] X-Spam-Score: -4.0 (----) X-Scan-Signature: a6ea8837e8866a83aa68ed7cf9155ec9 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: , Content-Type: multipart/mixed; boundary="===============1742485640==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============1742485640== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C82202.1039A281" This is a multi-part message in MIME format. ------_=_NextPart_001_01C82202.1039A281 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Moti This sounds reasonable, and will be reflected in the next rev. =20 Thanks -Sanjay -----Original Message----- From: Moti Morgenstern [mailto:Moti.Morgenstern@ecitele.com] Sent: Thursday, November 08, 2007 7:01 AM To: Sanjay Wadhwa; REYNDERS Paul Cc: ancp@ietf.org Subject: RE: [ANCP] PORT UP Data Rate? Hi, =20 'Accounting' means you should 'take into account'. It does not explicitly say that you are supposed to subtract the overhead from the total rate. So I suggest: "Access Node reports the DSL line rate after deducting the DSL overhead from it i.e. it reports the net rate". =20 Regards, Moti _____ =20 From: Sanjay Wadhwa [mailto:swadhwa@juniper.net]=20 Sent: Thursday, November 08, 2007 1:48 PM To: REYNDERS Paul Cc: ancp@ietf.org Subject: RE: [ANCP] PORT UP Data Rate? Would it be clearer if it said "Access Node reports the rate after accounting for the DSL overhead i.e. it reports the net rate" ? If not, please suggest suitable verbiage. =20 Thanks -Sanjay -----Original Message----- From: REYNDERS Paul [mailto:paul.reynders@alcatel-lucent.be] Sent: Thursday, November 08, 2007 6:01 AM To: Sanjay Wadhwa Cc: ancp@ietf.org Subject: RE: [ANCP] PORT UP Data Rate? Hi Sanjay, =20 i think the confusion is about the wording "account for the DSL overhead". To my knowledge of the english language (i'm a dutch speaker), this can mean:=20 "make allowance for the DSL overhead". =20 Regards, Paul Reynders _____ =20 From: Sanjay Wadhwa [mailto:swadhwa@juniper.net]=20 Sent: donderdag 8 november 2007 11:20 To: Wojciech Dec (wdec); REYNDERS Paul Cc: ancp@ietf.org; DE CNODDER Stefaan Subject: RE: [ANCP] PORT UP Data Rate? As I said in my previous mail, the protocol draft is quite explicit. The rate is reported from the DSLAM to the NAS, and the reported rate already has DSL overhead accounted for (as specified in the text in bold below). What exactly is the confusion ? =20 . Type (Actual-Data-Rate-Upstream =3D 0x81): Actual data rate upstream = of a synchronized DSL line. This is a mandatory TLV. This rate value and all the subsequent ones account for the DSL overhead (i.e. signify the net rate). =20 -Sanjay -----Original Message----- From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] Sent: Thursday, November 08, 2007 4:12 AM To: REYNDERS Paul; Sanjay Wadhwa Cc: ancp@ietf.org; DE CNODDER Stefaan Subject: RE: [ANCP] PORT UP Data Rate? Precisely. So we seem to agree that the appropriate edits need to be made in the protocol draft to clarify this? Section 3.1 of the framework draft should also see a minor edit to the term "DSL sync rate", and the use of the full "net data rate" term as introduced in the terminology section. =20 Regards, Woj. =20 =20 _____ =20 From: REYNDERS Paul [mailto:paul.reynders@alcatel-lucent.be]=20 Sent: 07 November 2007 14:09 To: Sanjay Wadhwa Cc: ancp@ietf.org; DE CNODDER Stefaan; Wojciech Dec (wdec) Subject: RE: [ANCP] PORT UP Data Rate? The DSL overhead is not transmitted between NAS and Access Node. As such, the DSL data rate that includes DSL overhead ("Sanjay's net data rate") must not be input for the Hierarchical Scheduling by NAS. For this HS, NAS needs DSL data rate that excluding DSL overhead ("Stefaan's net data rate"). The latter also decouples the access line technology (ADSL, EFM,...) from the aggregation network technology (ATM, Ethernet). Also consider the difficulties HS at NAS may have with evolving subsciber line transmission technologies if the data rate reported to NAS includes "DSL overhead". =20 Paul Reynders Alcatel-Lucent Bell NV=20 Copernicuslaan 50, 2018 Antwerp, Belgium _____ =20 From: Sanjay Wadhwa [mailto:swadhwa@juniper.net]=20 Sent: woensdag 7 november 2007 13:13 To: DE CNODDER Stefaan; Wojciech Dec (wdec) Cc: ancp@ietf.org Subject: RE: [ANCP] PORT UP Data Rate? The reported rate is "net data rate" (includes DSL overhead). The protocol draft explicitly mentions it: =20 . Type (Actual-Data-Rate-Upstream =3D 0x81): Actual data rate upstream = of a synchronized DSL line. This is a mandatory TLV. This rate value and all the subsequent ones account for the DSL overhead (i.e. signify the net rate). =20 -Sanjay =20 -----Original Message----- From: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be]=20 Sent: Wednesday, November 07, 2007 4:24 AM To: Wojciech Dec (wdec) Cc: ancp@ietf.org Subject: Re: [ANCP] PORT UP Data Rate? =20 =20 Woj, =20 It looks to me that the framework document is correct, and that the=20 protocol draft has to replace "data rate" by "net data rate" to make it=20 more accurate, i.e., for istance: =20 Type (Actual-Data-Rate-Upstream =3D 0x81) : Actual data rate upstream of = a synchronized DSL line... =20 should be =20 Type (Actual-Data-Rate-Upstream =3D 0x81) : Actual net data rate = upstream=20 of a synchronized DSL line... =20 The term "net data rate" is accurately defined in section 1.2 of the=20 framework document by referring to the ITU standard. =20 I hope we all have the same understanding of the definition of the=20 bandwidth advertised by ANCP. =20 regards, Stefaan =20 =20 =20 ------_=_NextPart_001_01C82202.1039A281 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Moti
 =20 This sounds reasonable, and will be reflected in the next=20 rev.
 
Thanks
-Sanjay
-----Original Message-----
From: Moti Morgenstern=20 [mailto:Moti.Morgenstern@ecitele.com]
Sent: Thursday, = November 08,=20 2007 7:01 AM
To: Sanjay Wadhwa; REYNDERS Paul
Cc:=20 ancp@ietf.org
Subject: RE: [ANCP] PORT UP Data=20 Rate?

Hi,
 
'Accounting' means you should 'take = into=20 account'. It does not explicitly say that you are supposed to = subtract=20 the overhead from the total rate.
So = I suggest:=20 "Access Node reports the DSL line rate after deducting the DSL = overhead from=20 it i.e. it reports the net=20 rate".
 
Regards,
Moti

From: Sanjay Wadhwa=20 [mailto:swadhwa@juniper.net]
Sent: Thursday, November 08, = 2007 1:48=20 PM
To: REYNDERS Paul
Cc: = ancp@ietf.org
Subject:=20 RE: [ANCP] PORT UP Data Rate?

Would it be clearer if it said "Access Node = reports=20 the rate after accounting for the DSL overhead i.e. it reports the net = rate" ? If not, please suggest suitable = verbiage.
 
Thanks
-Sanjay
-----Original Message-----
From: REYNDERS Paul=20 [mailto:paul.reynders@alcatel-lucent.be]
Sent: Thursday, = November=20 08, 2007 6:01 AM
To: Sanjay Wadhwa
Cc:=20 ancp@ietf.org
Subject: RE: [ANCP] PORT UP Data=20 Rate?

Hi Sanjay,
 
i think the confusion is about the wording "account for the = DSL=20 overhead".
To my knowledge of the english language (i'm a dutch = speaker), this=20 can mean:
"make allowance for the DSL overhead".
 
Regards,
Paul Reynders

From: Sanjay Wadhwa=20 [mailto:swadhwa@juniper.net]
Sent: donderdag 8 november = 2007=20 11:20
To: Wojciech Dec (wdec); REYNDERS Paul
Cc: = ancp@ietf.org; DE CNODDER Stefaan
Subject: RE: [ANCP] PORT = UP Data=20 Rate?

 As I said in my previous = mail, the=20 protocol draft is quite explicit. The rate is reported from the = DSLAM to the=20 NAS, and the reported rate already has DSL overhead accounted for = (as=20 specified in the text in bold below). What exactly is the = confusion=20 ?
 
. Type (Actual-Data-Rate-Upstream =3D = 0x81): Actual=20 data rate upstream  of a synchronized DSL line. This is a = mandatory=20 TLV. This rate value and all the subsequent ones account = for the=20 DSL overhead (i.e. signify the net=20 rate).
 
-Sanjay

-----Original Message-----
From: = Wojciech Dec=20 (wdec) [mailto:wdec@cisco.com]
Sent: Thursday, November = 08, 2007=20 4:12 AM
To: REYNDERS Paul; Sanjay Wadhwa
Cc:=20 ancp@ietf.org; DE CNODDER Stefaan
Subject: RE: [ANCP] PORT = UP Data=20 Rate?

Precisely. So we seem to agree that the appropriate = edits need=20 to be made in the protocol draft to clarify this? Section 3.1 of = the=20 framework draft should also see a minor edit to the term "DSL sync = rate",=20 and the use of the full "net data rate" term as introduced in the=20 terminology section.
 
Regards,
Woj.
 
 

From: REYNDERS Paul=20 [mailto:paul.reynders@alcatel-lucent.be]
Sent: 07 = November=20 2007 14:09
To: Sanjay Wadhwa
Cc: = ancp@ietf.org; DE=20 CNODDER Stefaan; Wojciech Dec (wdec)
Subject: RE: = [ANCP] PORT=20 UP Data Rate?

The DSL overhead is not transmitted = between NAS=20 and Access Node. As such, the DSL data rate that includes DSL = overhead=20 ("Sanjay's net data rate") must not be input for the = Hierarchical=20 Scheduling by NAS. For this HS, NAS needs DSL data rate=20 that excluding DSL overhead ("Stefaan's net data rate"). = The latter=20 also decouples the access line technology (ADSL, EFM,...) from = the=20 aggregation network technology (ATM, = Ethernet).
Also consider the difficulties HS at = NAS may=20 have with evolving subsciber line transmission technologies if = the data=20 rate reported to NAS includes "DSL = overhead".
 
Paul Reynders

Alcatel-Lucent Bell NV=20
Copernicuslaan 50, 2018 = Antwerp,=20 Belgium
From: Sanjay Wadhwa=20 [mailto:swadhwa@juniper.net]
Sent: woensdag 7 = november 2007=20 13:13
To: DE CNODDER Stefaan; Wojciech Dec=20 (wdec)
Cc: ancp@ietf.org
Subject: RE: [ANCP] = PORT UP=20 Data Rate?

The reported rate is "net data rate" = (includes=20 DSL overhead). The protocol draft explicitly mentions=20 it:

 

. Type (Actual-Data-Rate-Upstream =3D = 0x81):=20 Actual data rate upstream of a synchronized DSL line. This is a=20 mandatory TLV.

This rate value = and all the=20 subsequent ones account for the DSL overhead (i.e. signify the = net=20 rate).

 

-Sanjay

 

-----Original Message-----
From: = Stefaan DE=20 CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be]
Sent:=20 Wednesday, November 07, 2007 4:24 AM
To: Wojciech Dec = (wdec)
Cc:=20 ancp@ietf.org
Subject: Re: [ANCP] PORT UP Data=20 Rate?

 

 

Woj,

 

It looks to me that the framework = document is=20 correct, and that the

protocol draft has to replace "data = rate" by=20 "net data rate" to make it

more accurate, i.e., for=20 istance:

 

Type (Actual-Data-Rate-Upstream =3D = 0x81) : Actual=20 data rate upstream of a

synchronized DSL=20 line...

 

should be

 

Type (Actual-Data-Rate-Upstream =3D = 0x81) : Actual=20 net data rate upstream

of a synchronized DSL=20 line...

 

The term "net data rate" is accurately = defined=20 in section 1.2 of the

framework document by referring to the = ITU=20 standard.

 

I hope we all have the same = understanding of the=20 definition of the

bandwidth advertised by=20 ANCP.

 

regards,

Stefaan

 

 

 

=
------_=_NextPart_001_01C82202.1039A281-- --===============1742485640== 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 --===============1742485640==-- From ancp-bounces@ietf.org Thu Nov 08 07:43:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq6jA-0000Wx-S8; Thu, 08 Nov 2007 07:43:20 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1Iq6j9-0000Vn-Ec for ancp-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 07:43:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq6j8-0000TJ-Ml for ancp@ietf.org; Thu, 08 Nov 2007 07:43:18 -0500 Received: from exprod7og106.obsmtp.com ([64.18.2.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iq6j4-0003gU-LP for ancp@ietf.org; Thu, 08 Nov 2007 07:43:18 -0500 Received: from source ([66.129.224.36]) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP; Thu, 08 Nov 2007 04:43:05 PST Received: from proton.jnpr.net ([10.10.2.37]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Nov 2007 04:42:45 -0800 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] PORT UP Data Rate? Date: Thu, 8 Nov 2007 07:35:56 -0500 Message-ID: <9BD5D7887235424FA97DFC223CAE3C280AB43692@proton.jnpr.net> In-Reply-To: <4732FB37.3010500@alcatel-lucent.be> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] PORT UP Data Rate? Thread-Index: Acgh/4Ang0JulytRRT+H/Mx71iV/ygAAsMCA From: "Sanjay Wadhwa" To: "Stefaan DE CNODDER" X-OriginalArrivalTime: 08 Nov 2007 12:42:45.0712 (UTC) FILETIME=[DCA5B500:01C82204] X-Spam-Score: -4.0 (----) X-Scan-Signature: 52f402fbded34a6df606921f56b8bdd8 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 Yes. The framework draft defines the terminology (e.g "DSL overhead", and "Net-Data-Rate") and can make these references (e.g. to point the reader to technology dependent net-data-rate calculation on the AN). IMHO, the protcol draft should just refer to the framework draft for definition of baseline terminology, and not need to contain additional (re)defintions and references. Thanks -Sanjay >-----Original Message----- >From: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be] >Sent: Thursday, November 08, 2007 7:04 AM >To: Sanjay Wadhwa >Cc: Wojciech Dec (wdec); ancp@ietf.org >Subject: Re: [ANCP] PORT UP Data Rate? > > > >It seems we all agree on what the bandwidth means and since=20 >these terms=20 >are defined accurately by the DSL Forum and ITU (see mail of=20 >Thomas) it=20 >looks to me that it is sufficient to add a reference to the=20 >DSLF or ITU=20 >documents. This should not be too difficult to do.... > >regards, >Stefaan > > >Sanjay Wadhwa wrote: >> No, it is not clear to me from from the statements below=20 >that we need to=20 >> change anything. Can you let me know where in the draft does=20 >it say that=20 >> DSL overhead is transmitted between NAS and the Access Node (as=20 >> mentioned by one of the statements below)? As Robert says=20 >(included his=20 >> original mail below), the confusion came about when I used the word=20 >> "include overhead" in my mail (note : this is not in the draft). I=20 >> clarified that "include overhead" in my mail was meant as=20 >"DSLAM should=20 >> *include *overhead in calcuation of the net rate". >> =20 >> -Sanjay >>=20 >> -----Original Message----- >> *From:* Wojciech Dec (wdec) [mailto:wdec@cisco.com] >> *Sent:* Thursday, November 08, 2007 6:19 AM >> *To:* Sanjay Wadhwa; REYNDERS Paul >> *Cc:* ancp@ietf.org; DE CNODDER Stefaan >> *Subject:* RE: [ANCP] PORT UP Data Rate? >>=20 >> Please read these statements (from the mails in this thread), and >> let us know if it's the required minor change is still not clear. >> Also note that the net data rate term should be used in the >> description of both the upstream and downstream actual-rate TLVs. >> =20 >> --snip-- >> =20 >> The DSL overhead is not transmitted between NAS and=20 >Access Node. *As >> such, the DSL data rate that includes DSL overhead ("Sanjay's net >> data rate") must not be input for the Hierarchical Scheduling by >> NAS. For this HS, NAS needs DSL data rate that excluding DSL >> overhead ("Stefaan's net data rate"). * >> **=20 >> And: >> =20 >> ---snip--- >> [[SW]]=20 >>=20 >>>-----Original Message----- >>=20 >>>From: PESCHI Robert [mailto:Robert.Peschi@alcatel-lucent.be] >>=20 >>>Sent: Wednesday, November 07, 2007 8:13 AM >>=20 >>>To: DE CNODDER Stefaan; Sanjay Wadhwa >>=20 >>>Cc: ancp@ietf.org >>=20 >>>Subject: RE: [ANCP] PORT UP Data Rate? >>=20 >>> >>=20 >>> >>=20 >>>Sanjay Wadhwa wrote: >>=20 >>> > The reported rate is "net data rate" (includes DSL overhead). >> The protocol draft explicitly mentions it: >>=20 >>> > . Type (Actual-Data-Rate-Upstream =3D 0x81): Actual data rate >> upstream of a synchronized DSL line. This is a mandatory TLV. >>=20 >>> > /This rate value and all the subsequent ones account for the >> DSL overhead (i.e. signify the net rate)./ >>=20 >>> >>=20 >>>Just unfortunate wording I would say... >>=20 >>> >>=20 >>>I think that "Accounting for DSL overhead" means "having=20 >substacted DSL >>=20 >>>overhead"; >>=20 >>>it does not mean "including DSL overhead". >>=20 >> =20 >>=20 >> =20 >>=20 >> ---snip--- >>=20 >> Last but not least, a Terminology reference to the framework doc >> should be added, if not a terminology section outright. >>=20 >> -Woj. >>=20 >> =20 >>=20 >>=20 >> =20 >--------------------------------------------------------------- >--------- >> *From:* Sanjay Wadhwa [mailto:swadhwa@juniper.net] >> *Sent:* 08 November 2007 11:20 >> *To:* Wojciech Dec (wdec); REYNDERS Paul >> *Cc:* ancp@ietf.org; DE CNODDER Stefaan >> *Subject:* RE: [ANCP] PORT UP Data Rate? >>=20 >> As I said in my previous mail, the protocol draft is quite >> explicit. The rate is reported from the DSLAM to the NAS, and >> the reported rate already has DSL overhead accounted for (as >> specified in the text in bold below). What exactly is the >> confusion ? >> =20 >> . Type (Actual-Data-Rate-Upstream =3D 0x81): Actual data rate >> upstream of a synchronized DSL line. This is a mandatory >> TLV. *This rate value and all the subsequent ones account for >> the DSL overhead (i.e. signify the net rate).* >> =20 >> *-Sanjay* >>=20 >> **-----Original Message----- >> *From:* Wojciech Dec (wdec) [mailto:wdec@cisco.com] >> *Sent:* Thursday, November 08, 2007 4:12 AM >> *To:* REYNDERS Paul; Sanjay Wadhwa >> *Cc:* ancp@ietf.org; DE CNODDER Stefaan >> *Subject:* RE: [ANCP] PORT UP Data Rate? >>=20 >> Precisely. So we seem to agree that the appropriate edits >> need to be made in the protocol draft to clarify this? >> Section 3.1 of the framework draft should also=20 >see a minor >> edit to the term "DSL sync rate", and the use of the full >> "net data rate" term as introduced in the=20 >terminology section. >> =20 >> Regards, >> Woj. >> =20 >> =20 >>=20 >> =20 >--------------------------------------------------------------- >--------- >> *From:* REYNDERS Paul >> [mailto:paul.reynders@alcatel-lucent.be] >> *Sent:* 07 November 2007 14:09 >> *To:* Sanjay Wadhwa >> *Cc:* ancp@ietf.org; DE CNODDER Stefaan;=20 >Wojciech Dec (wdec) >> *Subject:* RE: [ANCP] PORT UP Data Rate? >>=20 >> The DSL overhead is not transmitted between NAS and >> Access Node. As such, the DSL data rate that includes >> DSL overhead ("Sanjay's net data rate") must not be >> input for the Hierarchical Scheduling by=20 >NAS. For this >> HS, NAS needs DSL data rate that excluding=20 >DSL overhead >> ("Stefaan's net data rate"). The latter also=20 >decouples >> the access line technology (ADSL, EFM,...) from the >> aggregation network technology (ATM, Ethernet). >> Also consider the difficulties HS at NAS may=20 >have with >> evolving subsciber line transmission=20 >technologies if the >> data rate reported to NAS includes "DSL overhead". >> =20 >> Paul Reynders >>=20 >> Alcatel-Lucent Bell NV >>=20 >> Copernicuslaan 50, 2018 Antwerp, Belgium >>=20 >> =20 >--------------------------------------------------------------- >--------- >> *From:* Sanjay Wadhwa [mailto:swadhwa@juniper.net] >> *Sent:* woensdag 7 november 2007 13:13 >> *To:* DE CNODDER Stefaan; Wojciech Dec (wdec) >> *Cc:* ancp@ietf.org >> *Subject:* RE: [ANCP] PORT UP Data Rate? >>=20 >> The reported rate is "net data rate" (includes DSL >> overhead). The protocol draft explicitly mentions it: >>=20 >> =20 >>=20 >> . Type (Actual-Data-Rate-Upstream =3D 0x81):=20 >Actual data >> rate upstream of a synchronized DSL line. This is a >> mandatory TLV. >>=20 >> /This rate value and all the subsequent ones=20 >account for >> the DSL overhead (i.e. signify the net rate)./ >>=20 >> / / >>=20 >> -Sanjay >>=20 >> =20 >>=20 >> -----Original Message----- >> From: Stefaan DE CNODDER >> [mailto:stefaan.de_cnodder@alcatel-lucent.be] >> Sent: Wednesday, November 07, 2007 4:24 AM >> To: Wojciech Dec (wdec) >> Cc: ancp@ietf.org >> Subject: Re: [ANCP] PORT UP Data Rate? >>=20 >> =20 >>=20 >> =20 >>=20 >> Woj, >>=20 >> =20 >>=20 >> It looks to me that the framework document=20 >is correct, >> and that the >>=20 >> protocol draft has to replace "data rate" by=20 >"net data >> rate" to make it >>=20 >> more accurate, i.e., for istance: >>=20 >> =20 >>=20 >> Type (Actual-Data-Rate-Upstream =3D 0x81) : Actual = data >> rate upstream of a >>=20 >> synchronized DSL line... >>=20 >> =20 >>=20 >> should be >>=20 >> =20 >>=20 >> Type (Actual-Data-Rate-Upstream =3D 0x81) : Actual = net >> data rate upstream >>=20 >> of a synchronized DSL line... >>=20 >> =20 >>=20 >> The term "net data rate" is accurately defined in >> section 1.2 of the >>=20 >> framework document by referring to the ITU standard. >>=20 >> =20 >>=20 >> I hope we all have the same understanding of the >> definition of the >>=20 >> bandwidth advertised by ANCP. >>=20 >> =20 >>=20 >> regards, >>=20 >> Stefaan >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 > _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Thu Nov 08 07:53:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq6tG-00053l-UC; Thu, 08 Nov 2007 07:53:46 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1Iq6tF-00053g-Ip for ancp-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 07:53:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq6tF-000539-6X for ancp@ietf.org; Thu, 08 Nov 2007 07:53:45 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iq6tE-0005Ek-0J for ancp@ietf.org; Thu, 08 Nov 2007 07:53:45 -0500 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Thu, 8 Nov 2007 13:53:42 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Nov 2007 13:53:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [ANCP] PORT UP Data Rate? Date: Thu, 8 Nov 2007 13:53:31 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1C59508E@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <4732FB37.3010500@alcatel-lucent.be> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] PORT UP Data Rate? thread-index: Acgh/5cDwZQMUf54SlyaRZxLuPoH/gABaKoQ References: <9BD5D7887235424FA97DFC223CAE3C280AB4368E@proton.jnpr.net> <4732FB37.3010500@alcatel-lucent.be> From: "Haag, T" To: X-OriginalArrivalTime: 08 Nov 2007 12:53:42.0474 (UTC) FILETIME=[641BA2A0:01C82206] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f402fbded34a6df606921f56b8bdd8 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 Thanks Stefaan, I fully agree. We have definitions already in use and agreed by several = bodies which should be used also to avoid the confusion we are = discussing about. Otherwise I don't understand the goal of this = discussion. Per definition a DSLAM does not account. Accounting rate is a BRAS = specific term which is dependent on an algorithm which may be dependent = from other factors e.g. encapsulation type. But all in common is the net data rate communicated via layer 2 control. = We have additional fields like DSL Type encapsulation type which give = information to the BRAS providing sufficient information for accounting = calculation.=20 Regards Thomas -----Urspr=FCngliche Nachricht----- Von: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be]=20 Gesendet: Donnerstag, 8. November 2007 13:04 An: Sanjay Wadhwa Cc: ancp@ietf.org Betreff: Re: [ANCP] PORT UP Data Rate? It seems we all agree on what the bandwidth means and since these terms=20 are defined accurately by the DSL Forum and ITU (see mail of Thomas) it=20 looks to me that it is sufficient to add a reference to the DSLF or ITU=20 documents. This should not be too difficult to do.... regards, Stefaan Sanjay Wadhwa wrote: > No, it is not clear to me from from the statements below that we need = to=20 > change anything. Can you let me know where in the draft does it say = that=20 > DSL overhead is transmitted between NAS and the Access Node (as=20 > mentioned by one of the statements below)? As Robert says (included = his=20 > original mail below), the confusion came about when I used the word=20 > "include overhead" in my mail (note : this is not in the draft). I=20 > clarified that "include overhead" in my mail was meant as "DSLAM = should=20 > *include *overhead in calcuation of the net rate". > =20 > -Sanjay >=20 > -----Original Message----- > *From:* Wojciech Dec (wdec) [mailto:wdec@cisco.com] > *Sent:* Thursday, November 08, 2007 6:19 AM > *To:* Sanjay Wadhwa; REYNDERS Paul > *Cc:* ancp@ietf.org; DE CNODDER Stefaan > *Subject:* RE: [ANCP] PORT UP Data Rate? >=20 > Please read these statements (from the mails in this thread), and > let us know if it's the required minor change is still not clear. > Also note that the net data rate term should be used in the > description of both the upstream and downstream actual-rate TLVs. > =20 > --snip-- > =20 > The DSL overhead is not transmitted between NAS and Access Node. = *As > such, the DSL data rate that includes DSL overhead ("Sanjay's net > data rate") must not be input for the Hierarchical Scheduling by > NAS. For this HS, NAS needs DSL data rate that excluding DSL > overhead ("Stefaan's net data rate"). * > **=20 > And: > =20 > ---snip--- > [[SW]]=20 >=20 >>-----Original Message----- >=20 >>From: PESCHI Robert [mailto:Robert.Peschi@alcatel-lucent.be] >=20 >>Sent: Wednesday, November 07, 2007 8:13 AM >=20 >>To: DE CNODDER Stefaan; Sanjay Wadhwa >=20 >>Cc: ancp@ietf.org >=20 >>Subject: RE: [ANCP] PORT UP Data Rate? >=20 >> >=20 >> >=20 >>Sanjay Wadhwa wrote: >=20 >> > The reported rate is "net data rate" (includes DSL overhead). > The protocol draft explicitly mentions it: >=20 >> > . Type (Actual-Data-Rate-Upstream =3D 0x81): Actual data rate > upstream of a synchronized DSL line. This is a mandatory TLV. >=20 >> > /This rate value and all the subsequent ones account for the > DSL overhead (i.e. signify the net rate)./ >=20 >> >=20 >>Just unfortunate wording I would say... >=20 >> >=20 >>I think that "Accounting for DSL overhead" means "having substacted = DSL >=20 >>overhead"; >=20 >>it does not mean "including DSL overhead". >=20 > =20 >=20 > =20 >=20 > ---snip--- >=20 > Last but not least, a Terminology reference to the framework doc > should be added, if not a terminology section outright. >=20 > -Woj. >=20 > =20 >=20 >=20 > = ------------------------------------------------------------------------ > *From:* Sanjay Wadhwa [mailto:swadhwa@juniper.net] > *Sent:* 08 November 2007 11:20 > *To:* Wojciech Dec (wdec); REYNDERS Paul > *Cc:* ancp@ietf.org; DE CNODDER Stefaan > *Subject:* RE: [ANCP] PORT UP Data Rate? >=20 > As I said in my previous mail, the protocol draft is quite > explicit. The rate is reported from the DSLAM to the NAS, and > the reported rate already has DSL overhead accounted for (as > specified in the text in bold below). What exactly is the > confusion ? > =20 > . Type (Actual-Data-Rate-Upstream =3D 0x81): Actual data rate > upstream of a synchronized DSL line. This is a mandatory > TLV. *This rate value and all the subsequent ones account for > the DSL overhead (i.e. signify the net rate).* > =20 > *-Sanjay* >=20 > **-----Original Message----- > *From:* Wojciech Dec (wdec) [mailto:wdec@cisco.com] > *Sent:* Thursday, November 08, 2007 4:12 AM > *To:* REYNDERS Paul; Sanjay Wadhwa > *Cc:* ancp@ietf.org; DE CNODDER Stefaan > *Subject:* RE: [ANCP] PORT UP Data Rate? >=20 > Precisely. So we seem to agree that the appropriate edits > need to be made in the protocol draft to clarify this? > Section 3.1 of the framework draft should also see a minor > edit to the term "DSL sync rate", and the use of the full > "net data rate" term as introduced in the terminology = section. > =20 > Regards, > Woj. > =20 > =20 >=20 > = ------------------------------------------------------------------------ > *From:* REYNDERS Paul > [mailto:paul.reynders@alcatel-lucent.be] > *Sent:* 07 November 2007 14:09 > *To:* Sanjay Wadhwa > *Cc:* ancp@ietf.org; DE CNODDER Stefaan; Wojciech Dec = (wdec) > *Subject:* RE: [ANCP] PORT UP Data Rate? >=20 > The DSL overhead is not transmitted between NAS and > Access Node. As such, the DSL data rate that includes > DSL overhead ("Sanjay's net data rate") must not be > input for the Hierarchical Scheduling by NAS. For this > HS, NAS needs DSL data rate that excluding DSL = overhead > ("Stefaan's net data rate"). The latter also decouples > the access line technology (ADSL, EFM,...) from the > aggregation network technology (ATM, Ethernet). > Also consider the difficulties HS at NAS may have with > evolving subsciber line transmission technologies if = the > data rate reported to NAS includes "DSL overhead". > =20 > Paul Reynders >=20 > Alcatel-Lucent Bell NV >=20 > Copernicuslaan 50, 2018 Antwerp, Belgium >=20 > = ------------------------------------------------------------------------ > *From:* Sanjay Wadhwa [mailto:swadhwa@juniper.net] > *Sent:* woensdag 7 november 2007 13:13 > *To:* DE CNODDER Stefaan; Wojciech Dec (wdec) > *Cc:* ancp@ietf.org > *Subject:* RE: [ANCP] PORT UP Data Rate? >=20 > The reported rate is "net data rate" (includes DSL > overhead). The protocol draft explicitly mentions it: >=20 > =20 >=20 > . Type (Actual-Data-Rate-Upstream =3D 0x81): Actual = data > rate upstream of a synchronized DSL line. This is a > mandatory TLV. >=20 > /This rate value and all the subsequent ones account = for > the DSL overhead (i.e. signify the net rate)./ >=20 > / / >=20 > -Sanjay >=20 > =20 >=20 > -----Original Message----- > From: Stefaan DE CNODDER > [mailto:stefaan.de_cnodder@alcatel-lucent.be] > Sent: Wednesday, November 07, 2007 4:24 AM > To: Wojciech Dec (wdec) > Cc: ancp@ietf.org > Subject: Re: [ANCP] PORT UP Data Rate? >=20 > =20 >=20 > =20 >=20 > Woj, >=20 > =20 >=20 > It looks to me that the framework document is correct, > and that the >=20 > protocol draft has to replace "data rate" by "net data > rate" to make it >=20 > more accurate, i.e., for istance: >=20 > =20 >=20 > Type (Actual-Data-Rate-Upstream =3D 0x81) : Actual = data > rate upstream of a >=20 > synchronized DSL line... >=20 > =20 >=20 > should be >=20 > =20 >=20 > Type (Actual-Data-Rate-Upstream =3D 0x81) : Actual net > data rate upstream >=20 > of a synchronized DSL line... >=20 > =20 >=20 > The term "net data rate" is accurately defined in > section 1.2 of the >=20 > framework document by referring to the ITU standard. >=20 > =20 >=20 > I hope we all have the same understanding of the > definition of the >=20 > bandwidth advertised by ANCP. >=20 > =20 >=20 > regards, >=20 > Stefaan >=20 > =20 >=20 > =20 >=20 > =20 >=20 _______________________________________________ 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 Thu Nov 08 09:31:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq8QC-00009C-Tr; Thu, 08 Nov 2007 09:31:52 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1Iq8QB-00008p-Kf for ancp-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 09:31:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq8QB-00008h-6d for ancp@ietf.org; Thu, 08 Nov 2007 09:31:51 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iq8Q6-0006tN-DP for ancp@ietf.org; Thu, 08 Nov 2007 09:31:50 -0500 X-IronPort-AV: E=Sophos;i="4.21,389,1188770400"; d="scan'208";a="157179858" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 08 Nov 2007 15:31:23 +0100 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 lA8EVNA9002815; Thu, 8 Nov 2007 15:31:23 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lA8EVK8q004114; Thu, 8 Nov 2007 14:31:22 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Nov 2007 15:31:20 +0100 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] PORT UP Data Rate? Date: Thu, 8 Nov 2007 15:29:26 +0100 Message-ID: In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C280AB43692@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] PORT UP Data Rate? Thread-Index: Acgh/4Ang0JulytRRT+H/Mx71iV/ygAAsMCAAAQoQFA= References: <4732FB37.3010500@alcatel-lucent.be> <9BD5D7887235424FA97DFC223CAE3C280AB43692@proton.jnpr.net> From: "Wojciech Dec (wdec)" To: "Sanjay Wadhwa" , "Stefaan DE CNODDER" X-OriginalArrivalTime: 08 Nov 2007 14:31:20.0543 (UTC) FILETIME=[07CA06F0:01C82214] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15532.001 X-TM-AS-Result: No--33.833600-8.000000-2 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=11416; t=1194532283; x=1195396283; 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]=20PORT=20UP=20Data=20Rate? |Sender:=20; bh=qYrHUW4w41I1FE7oVuQKGxI9qww8b8RnNGq3DjRUw08=; b=wCBXuCoBbFtG63oAivzZfOJBTrs8oOm8tgRfsK7E50BhLjEpkF1IE45ckX+RJQG1ZVWLXzev O9loe+PSuqv32RjJu7J0vce9iCjv+FHW1IZ1A0Dfvc+YTmmLT2nuRCU4; Authentication-Results: ams-dkim-1; header.From=wdec@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 2c12be3f3a8d57895fb9c003e1517c01 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 No one is suggesting re-definitions, rather use of consistent terminology and reference to where this terminology is defined (as needed). See it from the point of document readability. Currently the spec does not mention anything about terminology (implicitly assuming that the reader looks it up in the framework draft). -Woj. > -----Original Message----- > From: Sanjay Wadhwa [mailto:swadhwa@juniper.net]=20 > Sent: 08 November 2007 13:36 > To: Stefaan DE CNODDER > Cc: Wojciech Dec (wdec); ancp@ietf.org > Subject: RE: [ANCP] PORT UP Data Rate? >=20 > Yes. The framework draft defines the terminology (e.g "DSL=20 > overhead", and "Net-Data-Rate") and can make these references=20 > (e.g. to point the reader to technology dependent=20 > net-data-rate calculation on the AN). > IMHO, the protcol draft should just refer to the framework=20 > draft for definition of baseline terminology, and not need to=20 > contain additional (re)defintions and references. >=20 > Thanks > -Sanjay >=20 > >-----Original Message----- > >From: Stefaan DE CNODDER=20 > [mailto:stefaan.de_cnodder@alcatel-lucent.be] > >Sent: Thursday, November 08, 2007 7:04 AM > >To: Sanjay Wadhwa > >Cc: Wojciech Dec (wdec); ancp@ietf.org > >Subject: Re: [ANCP] PORT UP Data Rate? > > > > > > > >It seems we all agree on what the bandwidth means and since=20 > these terms=20 > >are defined accurately by the DSL Forum and ITU (see mail of > >Thomas) it > >looks to me that it is sufficient to add a reference to the=20 > DSLF or ITU=20 > >documents. This should not be too difficult to do.... > > > >regards, > >Stefaan > > > > > >Sanjay Wadhwa wrote: > >> No, it is not clear to me from from the statements below > >that we need to > >> change anything. Can you let me know where in the draft does > >it say that > >> DSL overhead is transmitted between NAS and the Access Node (as=20 > >> mentioned by one of the statements below)? As Robert says > >(included his > >> original mail below), the confusion came about when I used=20 > the word=20 > >> "include overhead" in my mail (note : this is not in the draft). I=20 > >> clarified that "include overhead" in my mail was meant as > >"DSLAM should > >> *include *overhead in calcuation of the net rate". > >> =20 > >> -Sanjay > >>=20 > >> -----Original Message----- > >> *From:* Wojciech Dec (wdec) [mailto:wdec@cisco.com] > >> *Sent:* Thursday, November 08, 2007 6:19 AM > >> *To:* Sanjay Wadhwa; REYNDERS Paul > >> *Cc:* ancp@ietf.org; DE CNODDER Stefaan > >> *Subject:* RE: [ANCP] PORT UP Data Rate? > >>=20 > >> Please read these statements (from the mails in this=20 > thread), and > >> let us know if it's the required minor change is still=20 > not clear. > >> Also note that the net data rate term should be used in the > >> description of both the upstream and downstream=20 > actual-rate TLVs. > >> =20 > >> --snip-- > >> =20 > >> The DSL overhead is not transmitted between NAS and > >Access Node. *As > >> such, the DSL data rate that includes DSL overhead=20 > ("Sanjay's net > >> data rate") must not be input for the Hierarchical=20 > Scheduling by > >> NAS. For this HS, NAS needs DSL data rate that excluding DSL > >> overhead ("Stefaan's net data rate"). * > >> **=20 > >> And: > >> =20 > >> ---snip--- > >> [[SW]] > >>=20 > >>>-----Original Message----- > >>=20 > >>>From: PESCHI Robert [mailto:Robert.Peschi@alcatel-lucent.be] > >>=20 > >>>Sent: Wednesday, November 07, 2007 8:13 AM > >>=20 > >>>To: DE CNODDER Stefaan; Sanjay Wadhwa > >>=20 > >>>Cc: ancp@ietf.org > >>=20 > >>>Subject: RE: [ANCP] PORT UP Data Rate? > >>=20 > >>> > >>=20 > >>> > >>=20 > >>>Sanjay Wadhwa wrote: > >>=20 > >>> > The reported rate is "net data rate" (includes DSL overhead). > >> The protocol draft explicitly mentions it: > >>=20 > >>> > . Type (Actual-Data-Rate-Upstream =3D 0x81): Actual data rate > >> upstream of a synchronized DSL line. This is a mandatory TLV. > >>=20 > >>> > /This rate value and all the subsequent ones account for the > >> DSL overhead (i.e. signify the net rate)./ > >>=20 > >>> > >>=20 > >>>Just unfortunate wording I would say... > >>=20 > >>> > >>=20 > >>>I think that "Accounting for DSL overhead" means "having > >substacted DSL > >>=20 > >>>overhead"; > >>=20 > >>>it does not mean "including DSL overhead". > >>=20 > >> =20 > >>=20 > >> =20 > >>=20 > >> ---snip--- > >>=20 > >> Last but not least, a Terminology reference to the=20 > framework doc > >> should be added, if not a terminology section outright. > >>=20 > >> -Woj. > >>=20 > >> =20 > >>=20 > >>=20 > >> =20 > >--------------------------------------------------------------- > >--------- > >> *From:* Sanjay Wadhwa [mailto:swadhwa@juniper.net] > >> *Sent:* 08 November 2007 11:20 > >> *To:* Wojciech Dec (wdec); REYNDERS Paul > >> *Cc:* ancp@ietf.org; DE CNODDER Stefaan > >> *Subject:* RE: [ANCP] PORT UP Data Rate? > >>=20 > >> As I said in my previous mail, the protocol draft is quite > >> explicit. The rate is reported from the DSLAM to=20 > the NAS, and > >> the reported rate already has DSL overhead=20 > accounted for (as > >> specified in the text in bold below). What exactly is the > >> confusion ? > >> =20 > >> . Type (Actual-Data-Rate-Upstream =3D 0x81): Actual data = rate > >> upstream of a synchronized DSL line. This is a mandatory > >> TLV. *This rate value and all the subsequent ones=20 > account for > >> the DSL overhead (i.e. signify the net rate).* > >> =20 > >> *-Sanjay* > >>=20 > >> **-----Original Message----- > >> *From:* Wojciech Dec (wdec) [mailto:wdec@cisco.com] > >> *Sent:* Thursday, November 08, 2007 4:12 AM > >> *To:* REYNDERS Paul; Sanjay Wadhwa > >> *Cc:* ancp@ietf.org; DE CNODDER Stefaan > >> *Subject:* RE: [ANCP] PORT UP Data Rate? > >>=20 > >> Precisely. So we seem to agree that the=20 > appropriate edits > >> need to be made in the protocol draft to clarify this? > >> Section 3.1 of the framework draft should also > >see a minor > >> edit to the term "DSL sync rate", and the use=20 > of the full > >> "net data rate" term as introduced in the > >terminology section. > >> =20 > >> Regards, > >> Woj. > >> =20 > >> =20 > >>=20 > >> =20 > >--------------------------------------------------------------- > >--------- > >> *From:* REYNDERS Paul > >> [mailto:paul.reynders@alcatel-lucent.be] > >> *Sent:* 07 November 2007 14:09 > >> *To:* Sanjay Wadhwa > >> *Cc:* ancp@ietf.org; DE CNODDER Stefaan; > >Wojciech Dec (wdec) > >> *Subject:* RE: [ANCP] PORT UP Data Rate? > >>=20 > >> The DSL overhead is not transmitted between NAS and > >> Access Node. As such, the DSL data rate=20 > that includes > >> DSL overhead ("Sanjay's net data rate") must not be > >> input for the Hierarchical Scheduling by > >NAS. For this > >> HS, NAS needs DSL data rate that excluding > >DSL overhead > >> ("Stefaan's net data rate"). The latter also > >decouples > >> the access line technology (ADSL, EFM,...) from the > >> aggregation network technology (ATM, Ethernet). > >> Also consider the difficulties HS at NAS may > >have with > >> evolving subsciber line transmission > >technologies if the > >> data rate reported to NAS includes "DSL overhead". > >> =20 > >> Paul Reynders > >>=20 > >> Alcatel-Lucent Bell NV > >>=20 > >> Copernicuslaan 50, 2018 Antwerp, Belgium > >>=20 > >> =20 > >--------------------------------------------------------------- > >--------- > >> *From:* Sanjay Wadhwa [mailto:swadhwa@juniper.net] > >> *Sent:* woensdag 7 november 2007 13:13 > >> *To:* DE CNODDER Stefaan; Wojciech Dec (wdec) > >> *Cc:* ancp@ietf.org > >> *Subject:* RE: [ANCP] PORT UP Data Rate? > >>=20 > >> The reported rate is "net data rate" (includes DSL > >> overhead). The protocol draft explicitly=20 > mentions it: > >>=20 > >> =20 > >>=20 > >> . Type (Actual-Data-Rate-Upstream =3D 0x81):=20 > >Actual data > >> rate upstream of a synchronized DSL line. This is a > >> mandatory TLV. > >>=20 > >> /This rate value and all the subsequent ones > >account for > >> the DSL overhead (i.e. signify the net rate)./ > >>=20 > >> / / > >>=20 > >> -Sanjay > >>=20 > >> =20 > >>=20 > >> -----Original Message----- > >> From: Stefaan DE CNODDER > >> [mailto:stefaan.de_cnodder@alcatel-lucent.be] > >> Sent: Wednesday, November 07, 2007 4:24 AM > >> To: Wojciech Dec (wdec) > >> Cc: ancp@ietf.org > >> Subject: Re: [ANCP] PORT UP Data Rate? > >>=20 > >> =20 > >>=20 > >> =20 > >>=20 > >> Woj, > >>=20 > >> =20 > >>=20 > >> It looks to me that the framework document > >is correct, > >> and that the > >>=20 > >> protocol draft has to replace "data rate" by > >"net data > >> rate" to make it > >>=20 > >> more accurate, i.e., for istance: > >>=20 > >> =20 > >>=20 > >> Type (Actual-Data-Rate-Upstream =3D 0x81) :=20 > Actual data > >> rate upstream of a > >>=20 > >> synchronized DSL line... > >>=20 > >> =20 > >>=20 > >> should be > >>=20 > >> =20 > >>=20 > >> Type (Actual-Data-Rate-Upstream =3D 0x81) :=20 > Actual net > >> data rate upstream > >>=20 > >> of a synchronized DSL line... > >>=20 > >> =20 > >>=20 > >> The term "net data rate" is accurately defined in > >> section 1.2 of the > >>=20 > >> framework document by referring to the ITU=20 > standard. > >>=20 > >> =20 > >>=20 > >> I hope we all have the same understanding of the > >> definition of the > >>=20 > >> bandwidth advertised by ANCP. > >>=20 > >> =20 > >>=20 > >> regards, > >>=20 > >> Stefaan > >>=20 > >> =20 > >>=20 > >> =20 > >>=20 > >> =20 > >>=20 > > >=20 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Thu Nov 08 14:44:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqDJ7-0003hT-D8; Thu, 08 Nov 2007 14:44:53 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IqDJ6-0003g5-1c for ancp-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 14:44:52 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqDJ5-0003eY-Ak for ancp@ietf.org; Thu, 08 Nov 2007 14:44:51 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqDJ3-0002k8-Pw for ancp@ietf.org; Thu, 08 Nov 2007 14:44:51 -0500 X-IronPort-AV: E=Sophos;i="4.21,391,1188770400"; d="scan'208";a="157209856" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 08 Nov 2007 20:44:47 +0100 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 lA8Jiltq021378; Thu, 8 Nov 2007 20:44:47 +0100 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 lA8Jig8i021488; Thu, 8 Nov 2007 19:44:44 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); Thu, 8 Nov 2007 20:44:42 +0100 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] PORT UP Data Rate? Date: Thu, 8 Nov 2007 20:44:42 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] PORT UP Data Rate? Thread-Index: Acgh/4Ang0JulytRRT+H/Mx71iV/ygAAsMCAAAQoQFAACmzg8A== References: <4732FB37.3010500@alcatel-lucent.be><9BD5D7887235424FA97DFC223CAE3C280AB43692@proton.jnpr.net> From: "Wojciech Dec (wdec)" To: "Sanjay Wadhwa" , "Stefaan DE CNODDER" X-OriginalArrivalTime: 08 Nov 2007 19:44:42.0743 (UTC) FILETIME=[CEC61070:01C8223F] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15532.001 X-TM-AS-Result: No--35.876800-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=12655; t=1194551087; x=1195415087; 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]=20PORT=20UP=20Data=20Rate? |Sender:=20; bh=L0P6kHr6F5Tz7728jxJ12q/PHWyotd05LPAzR0BRN48=; b=gqqapHDsNZBohvrd6DAvoy+Os4bPWuMQ/4iIvsd5OX84Qw2TLRwiz4tXtF4rxQC0bbh5zyI1 r5nK4EUUwzMzFLD8KBNZ+75W011br9GI6bGexgSirTN5R/kUacSJatMA; 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: fca7d4b87f391aa4d413f865ce6efe79 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 BTW This applies also to the framework draft, which appears to need a touch-up or two in Section 3.1 and 4.8.1 as well. (The term DSL sync rate is used) -Woj.=20 > -----Original Message----- > From: Wojciech Dec (wdec)=20 > Sent: 08 November 2007 15:29 > To: Sanjay Wadhwa; Stefaan DE CNODDER > Cc: ancp@ietf.org > Subject: RE: [ANCP] PORT UP Data Rate? >=20 > No one is suggesting re-definitions, rather use of consistent=20 > terminology and reference to where this terminology is=20 > defined (as needed). See it from the point of document=20 > readability. Currently the spec does not mention anything=20 > about terminology (implicitly assuming that the reader looks=20 > it up in the framework draft). >=20 > -Woj. >=20 > > -----Original Message----- > > From: Sanjay Wadhwa [mailto:swadhwa@juniper.net] > > Sent: 08 November 2007 13:36 > > To: Stefaan DE CNODDER > > Cc: Wojciech Dec (wdec); ancp@ietf.org > > Subject: RE: [ANCP] PORT UP Data Rate? > >=20 > > Yes. The framework draft defines the terminology (e.g "DSL=20 > overhead",=20 > > and "Net-Data-Rate") and can make these references (e.g. to=20 > point the=20 > > reader to technology dependent net-data-rate calculation on the AN). > > IMHO, the protcol draft should just refer to the framework=20 > draft for=20 > > definition of baseline terminology, and not need to contain=20 > additional=20 > > (re)defintions and references. > >=20 > > Thanks > > -Sanjay > >=20 > > >-----Original Message----- > > >From: Stefaan DE CNODDER > > [mailto:stefaan.de_cnodder@alcatel-lucent.be] > > >Sent: Thursday, November 08, 2007 7:04 AM > > >To: Sanjay Wadhwa > > >Cc: Wojciech Dec (wdec); ancp@ietf.org > > >Subject: Re: [ANCP] PORT UP Data Rate? > > > > > > > > > > > >It seems we all agree on what the bandwidth means and since > > these terms > > >are defined accurately by the DSL Forum and ITU (see mail of > > >Thomas) it > > >looks to me that it is sufficient to add a reference to the > > DSLF or ITU > > >documents. This should not be too difficult to do.... > > > > > >regards, > > >Stefaan > > > > > > > > >Sanjay Wadhwa wrote: > > >> No, it is not clear to me from from the statements below > > >that we need to > > >> change anything. Can you let me know where in the draft does > > >it say that > > >> DSL overhead is transmitted between NAS and the Access Node (as=20 > > >> mentioned by one of the statements below)? As Robert says > > >(included his > > >> original mail below), the confusion came about when I used > > the word > > >> "include overhead" in my mail (note : this is not in the=20 > draft). I=20 > > >> clarified that "include overhead" in my mail was meant as > > >"DSLAM should > > >> *include *overhead in calcuation of the net rate". > > >> =20 > > >> -Sanjay > > >>=20 > > >> -----Original Message----- > > >> *From:* Wojciech Dec (wdec) [mailto:wdec@cisco.com] > > >> *Sent:* Thursday, November 08, 2007 6:19 AM > > >> *To:* Sanjay Wadhwa; REYNDERS Paul > > >> *Cc:* ancp@ietf.org; DE CNODDER Stefaan > > >> *Subject:* RE: [ANCP] PORT UP Data Rate? > > >>=20 > > >> Please read these statements (from the mails in this > > thread), and > > >> let us know if it's the required minor change is still > > not clear. > > >> Also note that the net data rate term should be used in the > > >> description of both the upstream and downstream > > actual-rate TLVs. > > >> =20 > > >> --snip-- > > >> =20 > > >> The DSL overhead is not transmitted between NAS and > > >Access Node. *As > > >> such, the DSL data rate that includes DSL overhead > > ("Sanjay's net > > >> data rate") must not be input for the Hierarchical > > Scheduling by > > >> NAS. For this HS, NAS needs DSL data rate that excluding DSL > > >> overhead ("Stefaan's net data rate"). * > > >> **=20 > > >> And: > > >> =20 > > >> ---snip--- > > >> [[SW]] > > >>=20 > > >>>-----Original Message----- > > >>=20 > > >>>From: PESCHI Robert [mailto:Robert.Peschi@alcatel-lucent.be] > > >>=20 > > >>>Sent: Wednesday, November 07, 2007 8:13 AM > > >>=20 > > >>>To: DE CNODDER Stefaan; Sanjay Wadhwa > > >>=20 > > >>>Cc: ancp@ietf.org > > >>=20 > > >>>Subject: RE: [ANCP] PORT UP Data Rate? > > >>=20 > > >>> > > >>=20 > > >>> > > >>=20 > > >>>Sanjay Wadhwa wrote: > > >>=20 > > >>> > The reported rate is "net data rate" (includes DSL overhead). > > >> The protocol draft explicitly mentions it: > > >>=20 > > >>> > . Type (Actual-Data-Rate-Upstream =3D 0x81): Actual data rate > > >> upstream of a synchronized DSL line. This is a mandatory TLV. > > >>=20 > > >>> > /This rate value and all the subsequent ones account for the > > >> DSL overhead (i.e. signify the net rate)./ > > >>=20 > > >>> > > >>=20 > > >>>Just unfortunate wording I would say... > > >>=20 > > >>> > > >>=20 > > >>>I think that "Accounting for DSL overhead" means "having > > >substacted DSL > > >>=20 > > >>>overhead"; > > >>=20 > > >>>it does not mean "including DSL overhead". > > >>=20 > > >> =20 > > >>=20 > > >> =20 > > >>=20 > > >> ---snip--- > > >>=20 > > >> Last but not least, a Terminology reference to the > > framework doc > > >> should be added, if not a terminology section outright. > > >>=20 > > >> -Woj. > > >>=20 > > >> =20 > > >>=20 > > >>=20 > > >> =20 > > >--------------------------------------------------------------- > > >--------- > > >> *From:* Sanjay Wadhwa [mailto:swadhwa@juniper.net] > > >> *Sent:* 08 November 2007 11:20 > > >> *To:* Wojciech Dec (wdec); REYNDERS Paul > > >> *Cc:* ancp@ietf.org; DE CNODDER Stefaan > > >> *Subject:* RE: [ANCP] PORT UP Data Rate? > > >>=20 > > >> As I said in my previous mail, the protocol=20 > draft is quite > > >> explicit. The rate is reported from the DSLAM to > > the NAS, and > > >> the reported rate already has DSL overhead > > accounted for (as > > >> specified in the text in bold below). What exactly is the > > >> confusion ? > > >> =20 > > >> . Type (Actual-Data-Rate-Upstream =3D 0x81):=20 > Actual data rate > > >> upstream of a synchronized DSL line. This is a mandatory > > >> TLV. *This rate value and all the subsequent ones > > account for > > >> the DSL overhead (i.e. signify the net rate).* > > >> =20 > > >> *-Sanjay* > > >>=20 > > >> **-----Original Message----- > > >> *From:* Wojciech Dec (wdec) [mailto:wdec@cisco.com] > > >> *Sent:* Thursday, November 08, 2007 4:12 AM > > >> *To:* REYNDERS Paul; Sanjay Wadhwa > > >> *Cc:* ancp@ietf.org; DE CNODDER Stefaan > > >> *Subject:* RE: [ANCP] PORT UP Data Rate? > > >>=20 > > >> Precisely. So we seem to agree that the > > appropriate edits > > >> need to be made in the protocol draft to=20 > clarify this? > > >> Section 3.1 of the framework draft should also > > >see a minor > > >> edit to the term "DSL sync rate", and the use > > of the full > > >> "net data rate" term as introduced in the > > >terminology section. > > >> =20 > > >> Regards, > > >> Woj. > > >> =20 > > >> =20 > > >>=20 > > >> =20 > > >--------------------------------------------------------------- > > >--------- > > >> *From:* REYNDERS Paul > > >> [mailto:paul.reynders@alcatel-lucent.be] > > >> *Sent:* 07 November 2007 14:09 > > >> *To:* Sanjay Wadhwa > > >> *Cc:* ancp@ietf.org; DE CNODDER Stefaan; > > >Wojciech Dec (wdec) > > >> *Subject:* RE: [ANCP] PORT UP Data Rate? > > >>=20 > > >> The DSL overhead is not transmitted=20 > between NAS and > > >> Access Node. As such, the DSL data rate > > that includes > > >> DSL overhead ("Sanjay's net data rate")=20 > must not be > > >> input for the Hierarchical Scheduling by > > >NAS. For this > > >> HS, NAS needs DSL data rate that excluding > > >DSL overhead > > >> ("Stefaan's net data rate"). The latter also > > >decouples > > >> the access line technology (ADSL,=20 > EFM,...) from the > > >> aggregation network technology (ATM, Ethernet). > > >> Also consider the difficulties HS at NAS may > > >have with > > >> evolving subsciber line transmission > > >technologies if the > > >> data rate reported to NAS includes "DSL=20 > overhead". > > >> =20 > > >> Paul Reynders > > >>=20 > > >> Alcatel-Lucent Bell NV > > >>=20 > > >> Copernicuslaan 50, 2018 Antwerp, Belgium > > >>=20 > > >> =20 > > >--------------------------------------------------------------- > > >--------- > > >> *From:* Sanjay Wadhwa=20 > [mailto:swadhwa@juniper.net] > > >> *Sent:* woensdag 7 november 2007 13:13 > > >> *To:* DE CNODDER Stefaan; Wojciech Dec (wdec) > > >> *Cc:* ancp@ietf.org > > >> *Subject:* RE: [ANCP] PORT UP Data Rate? > > >>=20 > > >> The reported rate is "net data rate"=20 > (includes DSL > > >> overhead). The protocol draft explicitly > > mentions it: > > >>=20 > > >> =20 > > >>=20 > > >> . Type (Actual-Data-Rate-Upstream =3D 0x81):=20 > > >Actual data > > >> rate upstream of a synchronized DSL=20 > line. This is a > > >> mandatory TLV. > > >>=20 > > >> /This rate value and all the subsequent ones > > >account for > > >> the DSL overhead (i.e. signify the net rate)./ > > >>=20 > > >> / / > > >>=20 > > >> -Sanjay > > >>=20 > > >> =20 > > >>=20 > > >> -----Original Message----- > > >> From: Stefaan DE CNODDER > > >> [mailto:stefaan.de_cnodder@alcatel-lucent.be] > > >> Sent: Wednesday, November 07, 2007 4:24 AM > > >> To: Wojciech Dec (wdec) > > >> Cc: ancp@ietf.org > > >> Subject: Re: [ANCP] PORT UP Data Rate? > > >>=20 > > >> =20 > > >>=20 > > >> =20 > > >>=20 > > >> Woj, > > >>=20 > > >> =20 > > >>=20 > > >> It looks to me that the framework document > > >is correct, > > >> and that the > > >>=20 > > >> protocol draft has to replace "data rate" by > > >"net data > > >> rate" to make it > > >>=20 > > >> more accurate, i.e., for istance: > > >>=20 > > >> =20 > > >>=20 > > >> Type (Actual-Data-Rate-Upstream =3D 0x81) :=20 > > Actual data > > >> rate upstream of a > > >>=20 > > >> synchronized DSL line... > > >>=20 > > >> =20 > > >>=20 > > >> should be > > >>=20 > > >> =20 > > >>=20 > > >> Type (Actual-Data-Rate-Upstream =3D 0x81) :=20 > > Actual net > > >> data rate upstream > > >>=20 > > >> of a synchronized DSL line... > > >>=20 > > >> =20 > > >>=20 > > >> The term "net data rate" is accurately defined in > > >> section 1.2 of the > > >>=20 > > >> framework document by referring to the ITU > > standard. > > >>=20 > > >> =20 > > >>=20 > > >> I hope we all have the same understanding of the > > >> definition of the > > >>=20 > > >> bandwidth advertised by ANCP. > > >>=20 > > >> =20 > > >>=20 > > >> regards, > > >>=20 > > >> Stefaan > > >>=20 > > >> =20 > > >>=20 > > >> =20 > > >>=20 > > >> =20 > > >>=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 Fri Nov 09 04:46:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqQRw-0004yk-Ay; Fri, 09 Nov 2007 04:46:52 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IqQRu-0004vG-Ns for ancp-confirm+ok@megatron.ietf.org; Fri, 09 Nov 2007 04:46:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqQRu-0004ur-Dc for ancp@ietf.org; Fri, 09 Nov 2007 04:46:50 -0500 Received: from smail5.alcatel.fr ([62.23.212.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqQRo-0008L4-Pf for ancp@ietf.org; Fri, 09 Nov 2007 04:46:50 -0500 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 lA99jK2D026594; Fri, 9 Nov 2007 10:45:20 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.52]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 9 Nov 2007 10:46:37 +0100 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] PORT UP Data Rate? Date: Fri, 9 Nov 2007 10:46:36 +0100 Message-ID: <8144761F31F48D43AD53D09F5350E38001E0DE08@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] PORT UP Data Rate? Thread-Index: Acgh/4Ang0JulytRRT+H/Mx71iV/ygAAsMCAAAQoQFAACmzg8AAeGj5A References: <4732FB37.3010500@alcatel-lucent.be><9BD5D7887235424FA97DFC223CAE3C280AB43692@proton.jnpr.net> From: "OOGHE Sven" To: "Wojciech Dec (wdec)" , "Sanjay Wadhwa" , "DE CNODDER Stefaan" X-OriginalArrivalTime: 09 Nov 2007 09:46:37.0795 (UTC) FILETIME=[6C174B30:01C822B5] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: cd000eda3d43531d5b01b5d305410e3c 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 Woj, I will correct the references to "DSL sync rate" in the framework and refer to "net data rate". Regards, Sven=20 -----Original Message----- From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Sent: donderdag 8 november 2007 20:45 To: Sanjay Wadhwa; DE CNODDER Stefaan Cc: ancp@ietf.org Subject: RE: [ANCP] PORT UP Data Rate? BTW This applies also to the framework draft, which appears to need a touch-up or two in Section 3.1 and 4.8.1 as well. (The term DSL sync rate is used) -Woj.=20 > -----Original Message----- > From: Wojciech Dec (wdec) > Sent: 08 November 2007 15:29 > To: Sanjay Wadhwa; Stefaan DE CNODDER > Cc: ancp@ietf.org > Subject: RE: [ANCP] PORT UP Data Rate? >=20 > No one is suggesting re-definitions, rather use of consistent=20 > terminology and reference to where this terminology is defined (as=20 > needed). See it from the point of document readability. Currently the=20 > spec does not mention anything about terminology (implicitly assuming=20 > that the reader looks it up in the framework draft). >=20 > -Woj. >=20 > > -----Original Message----- > > From: Sanjay Wadhwa [mailto:swadhwa@juniper.net] > > Sent: 08 November 2007 13:36 > > To: Stefaan DE CNODDER > > Cc: Wojciech Dec (wdec); ancp@ietf.org > > Subject: RE: [ANCP] PORT UP Data Rate? > >=20 > > Yes. The framework draft defines the terminology (e.g "DSL > overhead", > > and "Net-Data-Rate") and can make these references (e.g. to > point the > > reader to technology dependent net-data-rate calculation on the AN). > > IMHO, the protcol draft should just refer to the framework > draft for > > definition of baseline terminology, and not need to contain > additional > > (re)defintions and references. > >=20 > > Thanks > > -Sanjay > >=20 > > >-----Original Message----- > > >From: Stefaan DE CNODDER > > [mailto:stefaan.de_cnodder@alcatel-lucent.be] > > >Sent: Thursday, November 08, 2007 7:04 AM > > >To: Sanjay Wadhwa > > >Cc: Wojciech Dec (wdec); ancp@ietf.org > > >Subject: Re: [ANCP] PORT UP Data Rate? > > > > > > > > > > > >It seems we all agree on what the bandwidth means and since > > these terms > > >are defined accurately by the DSL Forum and ITU (see mail of > > >Thomas) it > > >looks to me that it is sufficient to add a reference to the > > DSLF or ITU > > >documents. This should not be too difficult to do.... > > > > > >regards, > > >Stefaan > > > > > > > > >Sanjay Wadhwa wrote: > > >> No, it is not clear to me from from the statements below > > >that we need to > > >> change anything. Can you let me know where in the draft does > > >it say that > > >> DSL overhead is transmitted between NAS and the Access Node (as=20 > > >> mentioned by one of the statements below)? As Robert says > > >(included his > > >> original mail below), the confusion came about when I used > > the word > > >> "include overhead" in my mail (note : this is not in the > draft). I > > >> clarified that "include overhead" in my mail was meant as > > >"DSLAM should > > >> *include *overhead in calcuation of the net rate". > > >> =20 > > >> -Sanjay > > >>=20 > > >> -----Original Message----- > > >> *From:* Wojciech Dec (wdec) [mailto:wdec@cisco.com] > > >> *Sent:* Thursday, November 08, 2007 6:19 AM > > >> *To:* Sanjay Wadhwa; REYNDERS Paul > > >> *Cc:* ancp@ietf.org; DE CNODDER Stefaan > > >> *Subject:* RE: [ANCP] PORT UP Data Rate? > > >>=20 > > >> Please read these statements (from the mails in this > > thread), and > > >> let us know if it's the required minor change is still > > not clear. > > >> Also note that the net data rate term should be used in the > > >> description of both the upstream and downstream > > actual-rate TLVs. > > >> =20 > > >> --snip-- > > >> =20 > > >> The DSL overhead is not transmitted between NAS and > > >Access Node. *As > > >> such, the DSL data rate that includes DSL overhead > > ("Sanjay's net > > >> data rate") must not be input for the Hierarchical > > Scheduling by > > >> NAS. For this HS, NAS needs DSL data rate that excluding DSL > > >> overhead ("Stefaan's net data rate"). * > > >> **=20 > > >> And: > > >> =20 > > >> ---snip--- > > >> [[SW]] > > >>=20 > > >>>-----Original Message----- > > >>=20 > > >>>From: PESCHI Robert [mailto:Robert.Peschi@alcatel-lucent.be] > > >>=20 > > >>>Sent: Wednesday, November 07, 2007 8:13 AM > > >>=20 > > >>>To: DE CNODDER Stefaan; Sanjay Wadhwa > > >>=20 > > >>>Cc: ancp@ietf.org > > >>=20 > > >>>Subject: RE: [ANCP] PORT UP Data Rate? > > >>=20 > > >>> > > >>=20 > > >>> > > >>=20 > > >>>Sanjay Wadhwa wrote: > > >>=20 > > >>> > The reported rate is "net data rate" (includes DSL overhead). > > >> The protocol draft explicitly mentions it: > > >>=20 > > >>> > . Type (Actual-Data-Rate-Upstream =3D 0x81): Actual data rate > > >> upstream of a synchronized DSL line. This is a mandatory TLV. > > >>=20 > > >>> > /This rate value and all the subsequent ones account for the > > >> DSL overhead (i.e. signify the net rate)./ > > >>=20 > > >>> > > >>=20 > > >>>Just unfortunate wording I would say... > > >>=20 > > >>> > > >>=20 > > >>>I think that "Accounting for DSL overhead" means "having > > >substacted DSL > > >>=20 > > >>>overhead"; > > >>=20 > > >>>it does not mean "including DSL overhead". > > >>=20 > > >> =20 > > >>=20 > > >> =20 > > >>=20 > > >> ---snip--- > > >>=20 > > >> Last but not least, a Terminology reference to the > > framework doc > > >> should be added, if not a terminology section outright. > > >>=20 > > >> -Woj. > > >>=20 > > >> =20 > > >>=20 > > >>=20 > > >> =20 > > >--------------------------------------------------------------- > > >--------- > > >> *From:* Sanjay Wadhwa [mailto:swadhwa@juniper.net] > > >> *Sent:* 08 November 2007 11:20 > > >> *To:* Wojciech Dec (wdec); REYNDERS Paul > > >> *Cc:* ancp@ietf.org; DE CNODDER Stefaan > > >> *Subject:* RE: [ANCP] PORT UP Data Rate? > > >>=20 > > >> As I said in my previous mail, the protocol > draft is quite > > >> explicit. The rate is reported from the DSLAM to > > the NAS, and > > >> the reported rate already has DSL overhead > > accounted for (as > > >> specified in the text in bold below). What exactly is the > > >> confusion ? > > >> =20 > > >> . Type (Actual-Data-Rate-Upstream =3D 0x81):=20 > Actual data rate > > >> upstream of a synchronized DSL line. This is a mandatory > > >> TLV. *This rate value and all the subsequent ones > > account for > > >> the DSL overhead (i.e. signify the net rate).* > > >> =20 > > >> *-Sanjay* > > >>=20 > > >> **-----Original Message----- > > >> *From:* Wojciech Dec (wdec) [mailto:wdec@cisco.com] > > >> *Sent:* Thursday, November 08, 2007 4:12 AM > > >> *To:* REYNDERS Paul; Sanjay Wadhwa > > >> *Cc:* ancp@ietf.org; DE CNODDER Stefaan > > >> *Subject:* RE: [ANCP] PORT UP Data Rate? > > >>=20 > > >> Precisely. So we seem to agree that the > > appropriate edits > > >> need to be made in the protocol draft to > clarify this? > > >> Section 3.1 of the framework draft should also > > >see a minor > > >> edit to the term "DSL sync rate", and the use > > of the full > > >> "net data rate" term as introduced in the > > >terminology section. > > >> =20 > > >> Regards, > > >> Woj. > > >> =20 > > >> =20 > > >>=20 > > >> =20 > > >--------------------------------------------------------------- > > >--------- > > >> *From:* REYNDERS Paul > > >> [mailto:paul.reynders@alcatel-lucent.be] > > >> *Sent:* 07 November 2007 14:09 > > >> *To:* Sanjay Wadhwa > > >> *Cc:* ancp@ietf.org; DE CNODDER Stefaan; > > >Wojciech Dec (wdec) > > >> *Subject:* RE: [ANCP] PORT UP Data Rate? > > >>=20 > > >> The DSL overhead is not transmitted > between NAS and > > >> Access Node. As such, the DSL data rate > > that includes > > >> DSL overhead ("Sanjay's net data rate") > must not be > > >> input for the Hierarchical Scheduling by > > >NAS. For this > > >> HS, NAS needs DSL data rate that excluding > > >DSL overhead > > >> ("Stefaan's net data rate"). The latter also > > >decouples > > >> the access line technology (ADSL, > EFM,...) from the > > >> aggregation network technology (ATM, Ethernet). > > >> Also consider the difficulties HS at NAS may > > >have with > > >> evolving subsciber line transmission > > >technologies if the > > >> data rate reported to NAS includes "DSL > overhead". > > >> =20 > > >> Paul Reynders > > >>=20 > > >> Alcatel-Lucent Bell NV > > >>=20 > > >> Copernicuslaan 50, 2018 Antwerp, Belgium > > >>=20 > > >> =20 > > >--------------------------------------------------------------- > > >--------- > > >> *From:* Sanjay Wadhwa > [mailto:swadhwa@juniper.net] > > >> *Sent:* woensdag 7 november 2007 13:13 > > >> *To:* DE CNODDER Stefaan; Wojciech Dec (wdec) > > >> *Cc:* ancp@ietf.org > > >> *Subject:* RE: [ANCP] PORT UP Data Rate? > > >>=20 > > >> The reported rate is "net data rate"=20 > (includes DSL > > >> overhead). The protocol draft explicitly > > mentions it: > > >>=20 > > >> =20 > > >>=20 > > >> . Type (Actual-Data-Rate-Upstream =3D 0x81):=20 > > >Actual data > > >> rate upstream of a synchronized DSL > line. This is a > > >> mandatory TLV. > > >>=20 > > >> /This rate value and all the subsequent ones > > >account for > > >> the DSL overhead (i.e. signify the net rate)./ > > >>=20 > > >> / / > > >>=20 > > >> -Sanjay > > >>=20 > > >> =20 > > >>=20 > > >> -----Original Message----- > > >> From: Stefaan DE CNODDER > > >> [mailto:stefaan.de_cnodder@alcatel-lucent.be] > > >> Sent: Wednesday, November 07, 2007 4:24 AM > > >> To: Wojciech Dec (wdec) > > >> Cc: ancp@ietf.org > > >> Subject: Re: [ANCP] PORT UP Data Rate? > > >>=20 > > >> =20 > > >>=20 > > >> =20 > > >>=20 > > >> Woj, > > >>=20 > > >> =20 > > >>=20 > > >> It looks to me that the framework document > > >is correct, > > >> and that the > > >>=20 > > >> protocol draft has to replace "data rate" by > > >"net data > > >> rate" to make it > > >>=20 > > >> more accurate, i.e., for istance: > > >>=20 > > >> =20 > > >>=20 > > >> Type (Actual-Data-Rate-Upstream =3D 0x81) :=20 > > Actual data > > >> rate upstream of a > > >>=20 > > >> synchronized DSL line... > > >>=20 > > >> =20 > > >>=20 > > >> should be > > >>=20 > > >> =20 > > >>=20 > > >> Type (Actual-Data-Rate-Upstream =3D 0x81) :=20 > > Actual net > > >> data rate upstream > > >>=20 > > >> of a synchronized DSL line... > > >>=20 > > >> =20 > > >>=20 > > >> The term "net data rate" is accurately defined in > > >> section 1.2 of the > > >>=20 > > >> framework document by referring to the ITU > > standard. > > >>=20 > > >> =20 > > >>=20 > > >> I hope we all have the same understanding of the > > >> definition of the > > >>=20 > > >> bandwidth advertised by ANCP. > > >>=20 > > >> =20 > > >>=20 > > >> regards, > > >>=20 > > >> Stefaan > > >>=20 > > >> =20 > > >>=20 > > >> =20 > > >>=20 > > >> =20 > > >>=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 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Mon Nov 12 08:27:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrZKT-000853-UX; Mon, 12 Nov 2007 08:27:53 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IrZKT-00084x-E3 for ancp-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 08:27:53 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrZKT-00084p-2Y for ancp@ietf.org; Mon, 12 Nov 2007 08:27:53 -0500 Received: from exprod7og107.obsmtp.com ([64.18.2.167]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrZKR-00074m-NZ for ancp@ietf.org; Mon, 12 Nov 2007 08:27:52 -0500 Received: from source ([66.129.224.36]) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP; Mon, 12 Nov 2007 05:27:44 PST Received: from proton.jnpr.net ([10.10.2.37]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Nov 2007 05:27:36 -0800 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] PORT UP Data Rate? Date: Mon, 12 Nov 2007 08:27:31 -0500 Message-ID: <9BD5D7887235424FA97DFC223CAE3C280B777D16@proton.jnpr.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] PORT UP Data Rate? Thread-Index: Acgh/4Ang0JulytRRT+H/Mx71iV/ygAAsMCAAAQoQFAAxowFcA== From: "Sanjay Wadhwa" To: "Wojciech Dec (wdec)" , "Stefaan DE CNODDER" X-OriginalArrivalTime: 12 Nov 2007 13:27:36.0545 (UTC) FILETIME=[CA293D10:01C8252F] X-Spam-Score: 0.0 (/) X-Scan-Signature: a630332fa112280ecc4c4186b5c9ea83 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 will add explicit reference to section 1.2 of the framework draft for definitions/terminology. We need a few minor changes for consistency with the framework draft (including the agreed upon use of "net data rate"). I will send out an updated version of the protocol draft before 11/19 cutoff. -Sanjay -----Original Message----- From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Sent: Thursday, November 08, 2007 9:29 AM To: Sanjay Wadhwa; Stefaan DE CNODDER Cc: ancp@ietf.org Subject: RE: [ANCP] PORT UP Data Rate? No one is suggesting re-definitions, rather use of consistent terminology and reference to where this terminology is defined (as needed). See it from the point of document readability. Currently the spec does not mention anything about terminology (implicitly assuming that the reader looks it up in the framework draft). -Woj. > -----Original Message----- > From: Sanjay Wadhwa [mailto:swadhwa@juniper.net]=20 > Sent: 08 November 2007 13:36 > To: Stefaan DE CNODDER > Cc: Wojciech Dec (wdec); ancp@ietf.org > Subject: RE: [ANCP] PORT UP Data Rate? >=20 > Yes. The framework draft defines the terminology (e.g "DSL=20 > overhead", and "Net-Data-Rate") and can make these references=20 > (e.g. to point the reader to technology dependent=20 > net-data-rate calculation on the AN). > IMHO, the protcol draft should just refer to the framework=20 > draft for definition of baseline terminology, and not need to=20 > contain additional (re)defintions and references. >=20 > Thanks > -Sanjay >=20 > >-----Original Message----- > >From: Stefaan DE CNODDER=20 > [mailto:stefaan.de_cnodder@alcatel-lucent.be] > >Sent: Thursday, November 08, 2007 7:04 AM > >To: Sanjay Wadhwa > >Cc: Wojciech Dec (wdec); ancp@ietf.org > >Subject: Re: [ANCP] PORT UP Data Rate? > > > > > > > >It seems we all agree on what the bandwidth means and since=20 > these terms=20 > >are defined accurately by the DSL Forum and ITU (see mail of > >Thomas) it > >looks to me that it is sufficient to add a reference to the=20 > DSLF or ITU=20 > >documents. This should not be too difficult to do.... > > > >regards, > >Stefaan > > > > > >Sanjay Wadhwa wrote: > >> No, it is not clear to me from from the statements below > >that we need to > >> change anything. Can you let me know where in the draft does > >it say that > >> DSL overhead is transmitted between NAS and the Access Node (as=20 > >> mentioned by one of the statements below)? As Robert says > >(included his > >> original mail below), the confusion came about when I used=20 > the word=20 > >> "include overhead" in my mail (note : this is not in the draft). I=20 > >> clarified that "include overhead" in my mail was meant as > >"DSLAM should > >> *include *overhead in calcuation of the net rate". > >> =20 > >> -Sanjay > >>=20 > >> -----Original Message----- > >> *From:* Wojciech Dec (wdec) [mailto:wdec@cisco.com] > >> *Sent:* Thursday, November 08, 2007 6:19 AM > >> *To:* Sanjay Wadhwa; REYNDERS Paul > >> *Cc:* ancp@ietf.org; DE CNODDER Stefaan > >> *Subject:* RE: [ANCP] PORT UP Data Rate? > >>=20 > >> Please read these statements (from the mails in this=20 > thread), and > >> let us know if it's the required minor change is still=20 > not clear. > >> Also note that the net data rate term should be used in the > >> description of both the upstream and downstream=20 > actual-rate TLVs. > >> =20 > >> --snip-- > >> =20 > >> The DSL overhead is not transmitted between NAS and > >Access Node. *As > >> such, the DSL data rate that includes DSL overhead=20 > ("Sanjay's net > >> data rate") must not be input for the Hierarchical=20 > Scheduling by > >> NAS. For this HS, NAS needs DSL data rate that excluding DSL > >> overhead ("Stefaan's net data rate"). * > >> **=20 > >> And: > >> =20 > >> ---snip--- > >> [[SW]] > >>=20 > >>>-----Original Message----- > >>=20 > >>>From: PESCHI Robert [mailto:Robert.Peschi@alcatel-lucent.be] > >>=20 > >>>Sent: Wednesday, November 07, 2007 8:13 AM > >>=20 > >>>To: DE CNODDER Stefaan; Sanjay Wadhwa > >>=20 > >>>Cc: ancp@ietf.org > >>=20 > >>>Subject: RE: [ANCP] PORT UP Data Rate? > >>=20 > >>> > >>=20 > >>> > >>=20 > >>>Sanjay Wadhwa wrote: > >>=20 > >>> > The reported rate is "net data rate" (includes DSL overhead). > >> The protocol draft explicitly mentions it: > >>=20 > >>> > . Type (Actual-Data-Rate-Upstream =3D 0x81): Actual data rate > >> upstream of a synchronized DSL line. This is a mandatory TLV. > >>=20 > >>> > /This rate value and all the subsequent ones account for the > >> DSL overhead (i.e. signify the net rate)./ > >>=20 > >>> > >>=20 > >>>Just unfortunate wording I would say... > >>=20 > >>> > >>=20 > >>>I think that "Accounting for DSL overhead" means "having > >substacted DSL > >>=20 > >>>overhead"; > >>=20 > >>>it does not mean "including DSL overhead". > >>=20 > >> =20 > >>=20 > >> =20 > >>=20 > >> ---snip--- > >>=20 > >> Last but not least, a Terminology reference to the=20 > framework doc > >> should be added, if not a terminology section outright. > >>=20 > >> -Woj. > >>=20 > >> =20 > >>=20 > >>=20 > >> =20 > >--------------------------------------------------------------- > >--------- > >> *From:* Sanjay Wadhwa [mailto:swadhwa@juniper.net] > >> *Sent:* 08 November 2007 11:20 > >> *To:* Wojciech Dec (wdec); REYNDERS Paul > >> *Cc:* ancp@ietf.org; DE CNODDER Stefaan > >> *Subject:* RE: [ANCP] PORT UP Data Rate? > >>=20 > >> As I said in my previous mail, the protocol draft is quite > >> explicit. The rate is reported from the DSLAM to=20 > the NAS, and > >> the reported rate already has DSL overhead=20 > accounted for (as > >> specified in the text in bold below). What exactly is the > >> confusion ? > >> =20 > >> . Type (Actual-Data-Rate-Upstream =3D 0x81): Actual data = rate > >> upstream of a synchronized DSL line. This is a mandatory > >> TLV. *This rate value and all the subsequent ones=20 > account for > >> the DSL overhead (i.e. signify the net rate).* > >> =20 > >> *-Sanjay* > >>=20 > >> **-----Original Message----- > >> *From:* Wojciech Dec (wdec) [mailto:wdec@cisco.com] > >> *Sent:* Thursday, November 08, 2007 4:12 AM > >> *To:* REYNDERS Paul; Sanjay Wadhwa > >> *Cc:* ancp@ietf.org; DE CNODDER Stefaan > >> *Subject:* RE: [ANCP] PORT UP Data Rate? > >>=20 > >> Precisely. So we seem to agree that the=20 > appropriate edits > >> need to be made in the protocol draft to clarify this? > >> Section 3.1 of the framework draft should also > >see a minor > >> edit to the term "DSL sync rate", and the use=20 > of the full > >> "net data rate" term as introduced in the > >terminology section. > >> =20 > >> Regards, > >> Woj. > >> =20 > >> =20 > >>=20 > >> =20 > >--------------------------------------------------------------- > >--------- > >> *From:* REYNDERS Paul > >> [mailto:paul.reynders@alcatel-lucent.be] > >> *Sent:* 07 November 2007 14:09 > >> *To:* Sanjay Wadhwa > >> *Cc:* ancp@ietf.org; DE CNODDER Stefaan; > >Wojciech Dec (wdec) > >> *Subject:* RE: [ANCP] PORT UP Data Rate? > >>=20 > >> The DSL overhead is not transmitted between NAS and > >> Access Node. As such, the DSL data rate=20 > that includes > >> DSL overhead ("Sanjay's net data rate") must not be > >> input for the Hierarchical Scheduling by > >NAS. For this > >> HS, NAS needs DSL data rate that excluding > >DSL overhead > >> ("Stefaan's net data rate"). The latter also > >decouples > >> the access line technology (ADSL, EFM,...) from the > >> aggregation network technology (ATM, Ethernet). > >> Also consider the difficulties HS at NAS may > >have with > >> evolving subsciber line transmission > >technologies if the > >> data rate reported to NAS includes "DSL overhead". > >> =20 > >> Paul Reynders > >>=20 > >> Alcatel-Lucent Bell NV > >>=20 > >> Copernicuslaan 50, 2018 Antwerp, Belgium > >>=20 > >> =20 > >--------------------------------------------------------------- > >--------- > >> *From:* Sanjay Wadhwa [mailto:swadhwa@juniper.net] > >> *Sent:* woensdag 7 november 2007 13:13 > >> *To:* DE CNODDER Stefaan; Wojciech Dec (wdec) > >> *Cc:* ancp@ietf.org > >> *Subject:* RE: [ANCP] PORT UP Data Rate? > >>=20 > >> The reported rate is "net data rate" (includes DSL > >> overhead). The protocol draft explicitly=20 > mentions it: > >>=20 > >> =20 > >>=20 > >> . Type (Actual-Data-Rate-Upstream =3D 0x81):=20 > >Actual data > >> rate upstream of a synchronized DSL line. This is a > >> mandatory TLV. > >>=20 > >> /This rate value and all the subsequent ones > >account for > >> the DSL overhead (i.e. signify the net rate)./ > >>=20 > >> / / > >>=20 > >> -Sanjay > >>=20 > >> =20 > >>=20 > >> -----Original Message----- > >> From: Stefaan DE CNODDER > >> [mailto:stefaan.de_cnodder@alcatel-lucent.be] > >> Sent: Wednesday, November 07, 2007 4:24 AM > >> To: Wojciech Dec (wdec) > >> Cc: ancp@ietf.org > >> Subject: Re: [ANCP] PORT UP Data Rate? > >>=20 > >> =20 > >>=20 > >> =20 > >>=20 > >> Woj, > >>=20 > >> =20 > >>=20 > >> It looks to me that the framework document > >is correct, > >> and that the > >>=20 > >> protocol draft has to replace "data rate" by > >"net data > >> rate" to make it > >>=20 > >> more accurate, i.e., for istance: > >>=20 > >> =20 > >>=20 > >> Type (Actual-Data-Rate-Upstream =3D 0x81) :=20 > Actual data > >> rate upstream of a > >>=20 > >> synchronized DSL line... > >>=20 > >> =20 > >>=20 > >> should be > >>=20 > >> =20 > >>=20 > >> Type (Actual-Data-Rate-Upstream =3D 0x81) :=20 > Actual net > >> data rate upstream > >>=20 > >> of a synchronized DSL line... > >>=20 > >> =20 > >>=20 > >> The term "net data rate" is accurately defined in > >> section 1.2 of the > >>=20 > >> framework document by referring to the ITU=20 > standard. > >>=20 > >> =20 > >>=20 > >> I hope we all have the same understanding of the > >> definition of the > >>=20 > >> bandwidth advertised by ANCP. > >>=20 > >> =20 > >>=20 > >> regards, > >>=20 > >> Stefaan > >>=20 > >> =20 > >>=20 > >> =20 > >>=20 > >> =20 > >>=20 > > >=20 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Thu Nov 15 01:09:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsXui-0007Bj-C1; Thu, 15 Nov 2007 01:09:20 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IsXuh-0007BY-Es for ancp-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 01:09:19 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IsXuh-0007Aw-3T for ancp@ietf.org; Thu, 15 Nov 2007 01:09:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsXsq-0004aK-62 for ancp@ietf.org; Thu, 15 Nov 2007 01:07:24 -0500 Received: from msgbas1x.sgp.agilent.com ([192.25.42.26] helo=msgbas1x.net.asiapac.agilent.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsXsl-0006Dw-8I for ancp@ietf.org; Thu, 15 Nov 2007 01:07:24 -0500 Received: from relsgp1.sgp.agilent.com (relsgp1.sgp.agilent.com [141.183.100.45]) by msgbas1x.net.asiapac.agilent.com (Postfix) with ESMTP id CCDCA738 for ; Thu, 15 Nov 2007 14:07:17 +0800 (SGP) Received: from relsgp1.sgp.agilent.com (localhost.localdomain [127.0.0.1]) by post-av (Postfix) with ESMTP id B48CB27D95 for ; Thu, 15 Nov 2007 14:07:17 +0800 (SGT) Received: from sgp-sg-bh02.sgp.agilent.com (sgp-sg-bh02.sgp.agilent.com [141.183.6.36]) by relsgp1.sgp.agilent.com (Postfix) with ESMTP id A84D227D93 for ; Thu, 15 Nov 2007 14:07:17 +0800 (SGT) Received: from sgp-sg-mb02.sgp.agilent.com ([141.183.6.33]) by sgp-sg-bh02.sgp.agilent.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Nov 2007 14:07:17 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 15 Nov 2007 14:07:16 +0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Query about ANCP Thread-Index: AcgnTcX0dUTE19zOS/+7LYajpXJgLA== From: To: X-OriginalArrivalTime: 15 Nov 2007 06:07:17.0305 (UTC) FILETIME=[C64E6290:01C8274D] X-Virus-Scanned: Using ClamAV on relsgp1.sgp.agilent.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e X-TMDA-Confirmed: Thu, 15 Nov 2007 01:09:19 -0500 Subject: [ANCP] Query about ANCP 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="===============1742769864==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============1742769864== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8274D.C6632DAF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8274D.C6632DAF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The field X-Function which is sent in the Line Configuration Extension = block sent by NAS(Refer To section 5.4.3 in draft-ietf-ancp-protocol-01.txt) is not defined in = the=20 Draft. Where can this definition be found?=20 =20 Regards, Smita. ------_=_NextPart_001_01C8274D.C6632DAF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The field X-Function which is sent in the Line = Configuration Extension block sent by NAS(Refer

To section 5.4.3 in draft-ietf-ancp-protocol-01.txt) is not defined in the

Draft. Where can this definition be found? =

 

Regards,

Smita.

------_=_NextPart_001_01C8274D.C6632DAF-- --===============1742769864== 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 --===============1742769864==-- From ancp-bounces@ietf.org Thu Nov 15 04:19:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isat0-0003oO-P0; Thu, 15 Nov 2007 04:19:46 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1Isasy-0003io-FN for ancp-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 04:19:44 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isasy-0003ig-04 for ancp@ietf.org; Thu, 15 Nov 2007 04:19:44 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Isasx-000273-Na for ancp@ietf.org; Thu, 15 Nov 2007 04:19:43 -0500 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns4.neustar.com (Postfix) with ESMTP id 800CE2AC73; Thu, 15 Nov 2007 09:19:43 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1Isasx-0000O9-8o; Thu, 15 Nov 2007 04:19:43 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: sven.ooghe@alcatel-lucent.be From: IETF I-D Submission Tool Message-Id: Date: Thu, 15 Nov 2007 04:19:43 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ancp@ietf.org Subject: [ANCP] New Version Notification for draft-ietf-ancp-framework-04 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 A new version of I-D, draft-ietf-ancp-framework-04.txt has been successfuly submitted by Sven Ooghe and posted to the IETF repository. Filename: draft-ietf-ancp-framework Revision: 04 Title: Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks Creation_date: 2007-11-15 WG ID: ancp Number_of_pages: 41 Abstract: The purpose of this document is to define a framework for an Access Node Control Mechanism between a Network Access Server (NAS) and an Access Node (e.g. a Digital Subscriber Line Access Multiplexer (DSLAM)) in a multi-service reference architecture in order to perform QoS-related, service-related and Subscriber-related operations. The Access Node Control Mechanism will ensure that the transmission of the information does not need to go through distinct element managers but rather using a direct device-device communication. This allows for performing access link related operations within those network elements, while avoiding impact on the existing OSS systems. The IETF Secretariat. _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Thu Nov 15 04:20:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsatJ-0004UM-76; Thu, 15 Nov 2007 04:20:05 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IsatH-0004RH-Rx for ancp-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 04:20:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsatH-0004R7-G7; Thu, 15 Nov 2007 04:20:03 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsatH-00027s-2U; Thu, 15 Nov 2007 04:20:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id A7AD1175E1; Thu, 15 Nov 2007 09:20:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IsatG-0006P9-6s; Thu, 15 Nov 2007 04:20:02 -0500 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, 15 Nov 2007 04:20:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: ancp@ietf.org Subject: [ANCP] I-D Action:draft-ietf-ancp-framework-04.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 : Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks Author(s) : S. Ooghe, et al. Filename : draft-ietf-ancp-framework-04.txt Pages : 41 Date : 2007-11-15 The purpose of this document is to define a framework for an Access Node Control Mechanism between a Network Access Server (NAS) and an Access Node (e.g. a Digital Subscriber Line Access Multiplexer (DSLAM)) in a multi-service reference architecture in order to perform QoS-related, service-related and Subscriber-related operations. The Access Node Control Mechanism will ensure that the transmission of the information does not need to go through distinct element managers but rather using a direct device-device communication. This allows for performing access link related operations within those network elements, while avoiding impact on the existing OSS systems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ancp-framework-04.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-framework-04.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-framework-04.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-11-15041940.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ancp-framework-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ancp-framework-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-15041940.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 Thu Nov 15 08:35:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isesi-00023A-1P; Thu, 15 Nov 2007 08:35:44 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1Isesg-00020o-ON for ancp-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 08:35:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isesf-0001xY-Q4 for ancp@ietf.org; Thu, 15 Nov 2007 08:35:41 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Isesf-0003NQ-BI for ancp@ietf.org; Thu, 15 Nov 2007 08:35:41 -0500 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP for ancp@ietf.org; Thu, 15 Nov 2007 14:35:39 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Nov 2007 14:35:39 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 15 Nov 2007 14:35:38 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1C1066A6@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Splitting GSMP messages to different TCP packets Thread-Index: AcgnjGbhqd/+NxCtQH2SXDUVlwehGQ== From: "Busser, M" To: X-OriginalArrivalTime: 15 Nov 2007 13:35:39.0116 (UTC) FILETIME=[6908FAC0:01C8278C] X-Spam-Score: 0.0 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 Cc: "Troester, Stephan" , "Haag, T" , "Witschurke, Birgit" Subject: [ANCP] Splitting GSMP messages to different TCP packets 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="===============2138748411==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============2138748411== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8278C.68A6E8B7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8278C.68A6E8B7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all. =20 When the adjacency comes up, a bunch of PORT-STATUS messages will be = sent=20 by the DSLAM to the BRAS.=20 =20 If the amount of data (all the GSMP messages) exceeds the limit of one = TCP-Packet,=20 the next portion of data have to be sent with the next TCP packets. =20 The question now is: Do we have any requirements to make sure, that only complete GSMP = messages are sent in one TCP message? =20 >From my understanding, the stream of GSMP messages is a byte stream,=20 which is transported to the far end by TCP.=20 The application layer (e.g. the layer above TCP) do not have to take = care=20 about such details of transportation. So the answer is no. =20 Am i wrong? =20 Best Regards; Freundliche Gr=FC=DFe=20 Michael Busser T-Systems Enterprise Services GmbH=20 Production Line Network Centric Systems ICT-Systems Integration Network Integration Services =20 Br=FCckes 2 -8, 55545 Bad Kreuznach Postfach 9100, 55541 Bad Kreuznach +49 671 8333 8911 (Phone) +49 521 9210 3859 (Fax) +49 151 1211 9689 (Mobile) E-Mail: michael.busser@t-systems.com Internet: http://www.t-systems.com=20 =20 =20 T-Systems Enterprise Services GmbH Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) Executive Committee: Helmut Binder, Albert Henn, Olaf Heyden*, Katrin = Horstmann, Ulrich Kemp, Wilfried Peters*,=20 Dr. Herbert Schaaff*, Zvezdana Seeger* Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 Sitz der Gesellschaft: Frankfurt am Main WEEE-Reg.-Nr. DE87523644 *Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG=20 Notice: This transmittal and/or attachments may be privileged or = confidential. If you are not the intended recipient, you are hereby = notified that you have received this transmittal in error; any review, = dissemination, or copying is strictly prohibited. If you received this = transmittal in error, please notify us immediately by reply and = immediately delete this message and all its attachments. Thank you.=20 T-Systems - Business flexibility=20 =20 =20 ------_=_NextPart_001_01C8278C.68A6E8B7 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Nachricht
Hi all.
 
When the adjacency comes up, a bunch of PORT-STATUS messages will = be sent=20
by the DSLAM to the BRAS.
 
If the amount of data (all the GSMP messages) exceeds the limit of = one=20 TCP-Packet,
the next portion of data have to be sent with the next = TCP=20 packets.
 
The question now is:
Do we have any requirements to make sure, = that only=20 complete GSMP messages
are sent in one TCP message?
 
From my understanding, the stream of GSMP messages is a byte = stream,=20
which is transported to the far end by TCP.
The application = layer (e.g.=20 the layer above TCP) do not have to take care
about such details of=20 transportation.
So the answer is no.
 
Am i wrong?
 

Best Regards; Freundliche = Gr=FC=DFe=20

Michael Busser
T-Systems=20 Enterprise Services GmbH
Production Line Network Centric Systems
ICT-Systems Integration
Network Integration Services
 
Br=FCckes 2 -8,=20 55545 Bad Kreuznach
Postfach 9100, 55541 Bad Kreuznach
+49 671 = 8333 8911=20 (Phone)
+49 521 9210 3859 (Fax)
+49 151 1211 9689=20 (Mobile)
E-Mail: michael.busser@t-systems.com=
Internet:=20 http://www.t-systems.com
 
 =20
T-Systems Enterprise Services=20 GmbH
Aufsichtsrat: Ren=E9 Obermann (Vorsitzender)
Executive = Committee:=20 Helmut Binder, Albert Henn, Olaf Heyden*, Katrin Horstmann, Ulrich Kemp, = Wilfried Peters*,
Dr. Herbert Schaaff*, Zvezdana = Seeger*
Handelsregister:=20 Amtsgericht Frankfurt am Main HRB 55933
Sitz der Gesellschaft: = Frankfurt am=20 Main
WEEE-Reg.-Nr. DE87523644
*Gesch=E4ftsf=FChrer gem. =A7 35 = GmbHG=20

Notice: This transmittal and/or attachments may be = privileged or=20 confidential. If you are not the intended recipient, you are hereby = notified=20 that you have received this transmittal in error; any review, = dissemination, or=20 copying is strictly prohibited. If you received this transmittal in = error,=20 please notify us immediately by reply and immediately delete this = message and=20 all its attachments. Thank you.
T-Systems = – Business=20 flexibility

 
 
------_=_NextPart_001_01C8278C.68A6E8B7-- --===============2138748411== 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 --===============2138748411==-- From ancp-bounces@ietf.org Thu Nov 15 09:50:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isg2e-00048z-RG; Thu, 15 Nov 2007 09:50:04 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1Isg2d-00047I-JA for ancp-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 09:50:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isg2d-00046f-6S for ancp@ietf.org; Thu, 15 Nov 2007 09:50:03 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Isg2c-0007dt-2x for ancp@ietf.org; Thu, 15 Nov 2007 09:50:03 -0500 X-IronPort-AV: E=Sophos;i="4.21,420,1188770400"; d="scan'208,217";a="157825748" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 15 Nov 2007 15:50:01 +0100 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 lAFEo1r7015675; Thu, 15 Nov 2007 15:50:01 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAFEo1YS027054; Thu, 15 Nov 2007 14:50:01 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Nov 2007 15:50:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ANCP] Splitting GSMP messages to different TCP packets Date: Thu, 15 Nov 2007 15:49:56 +0100 Message-ID: In-Reply-To: <1B6169C658325341A3B8066E23919E1C1066A6@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Splitting GSMP messages to different TCP packets Thread-Index: AcgnjGbhqd/+NxCtQH2SXDUVlwehGQACcICw References: <1B6169C658325341A3B8066E23919E1C1066A6@S4DE8PSAANK.mitte.t-com.de> From: "Wojciech Dec (wdec)" To: "Busser, M" , X-OriginalArrivalTime: 15 Nov 2007 14:50:00.0890 (UTC) FILETIME=[CC75A9A0:01C82796] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15546.001 X-TM-AS-Result: No--29.115000-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=10140; t=1195138201; x=1196002201; 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]=20Splitting=20GSMP=20messages=20to=20different =20TCP=20packets |Sender:=20; bh=J1HPj3oUMg2o/kcFaqkv/FQO+JjwmJDpRgW7i7b+06o=; b=dbdn0hHDmSl9TmO1ES1mmb8FoiNl8cc7ooe13IwJL3gRSZG1PudGRD7+VV60O71RJiUkX34N lR6hS4X7dfYsJ3Ak5eOZwKmXZ9STv5yXm8sXlt4fuCKXRyvdTPKJFsdK; 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: 83e9494d829b08cc3f644ef6ac1b9bd4 Cc: "Troester, Stephan" , "Haag, T" , "Witschurke, Birgit" 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="===============1138667254==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============1138667254== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C82796.CC273015" This is a multi-part message in MIME format. ------_=_NextPart_001_01C82796.CC273015 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Michael, =20 your interpretation is correct with respect to ANCP over TCP. =20 -Woj. ________________________________ From: Busser, M [mailto:Michael.Busser@t-systems.com]=20 Sent: 15 November 2007 14:36 To: ancp@ietf.org Cc: Troester, Stephan; Haag,T; Witschurke,Birgit Subject: [ANCP] Splitting GSMP messages to different TCP packets =09 =09 Hi all. =20 =09 When the adjacency comes up, a bunch of PORT-STATUS messages will be = sent=20 by the DSLAM to the BRAS.=20 =20 If the amount of data (all the GSMP messages) exceeds the limit of one = TCP-Packet,=20 the next portion of data have to be sent with the next TCP packets. =20 The question now is: Do we have any requirements to make sure, that only complete GSMP = messages are sent in one TCP message? =20 From my understanding, the stream of GSMP messages is a byte stream,=20 which is transported to the far end by TCP.=20 The application layer (e.g. the layer above TCP) do not have to take = care=20 about such details of transportation. So the answer is no. =20 Am i wrong? =20 Best Regards; Freundliche Gr=FC=DFe=20 Michael Busser =09 T-Systems Enterprise Services GmbH=20 Production Line Network Centric Systems ICT-Systems Integration Network Integration Services =20 Br=FCckes 2 -8, 55545 Bad Kreuznach Postfach 9100, 55541 Bad Kreuznach +49 671 8333 8911 (Phone) +49 521 9210 3859 (Fax) +49 151 1211 9689 (Mobile) E-Mail: michael.busser@t-systems.com =09 Internet: http://www.t-systems.com =20 =09 =20 =20 T-Systems Enterprise Services GmbH Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) Executive Committee: Helmut Binder, Albert Henn, Olaf Heyden*, Katrin = Horstmann, Ulrich Kemp, Wilfried Peters*,=20 Dr. Herbert Schaaff*, Zvezdana Seeger* Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 Sitz der Gesellschaft: Frankfurt am Main WEEE-Reg.-Nr. DE87523644 *Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG=20 Notice: This transmittal and/or attachments may be privileged or = confidential. If you are not the intended recipient, you are hereby = notified that you have received this transmittal in error; any review, = dissemination, or copying is strictly prohibited. If you received this = transmittal in error, please notify us immediately by reply and = immediately delete this message and all its attachments. Thank you.=20 T-Systems - Business flexibility=20 =20 =20 ------_=_NextPart_001_01C82796.CC273015 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Nachricht</TIT= LE> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR></HEAD> <BODY> <DIV dir=3Dltr align=3Dleft><SPAN class=3D558264514-15112007><FONT = face=3DArial=20 size=3D2>Hi Michael,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D558264514-15112007><FONT = face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D558264514-15112007><FONT = face=3DArial=20 size=3D2>your interpretation is correct with respect to ANCP = over=20 TCP.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D558264514-15112007><FONT = face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D558264514-15112007><FONT = face=3DArial=20 size=3D2>-Woj.</FONT></SPAN></DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px = solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> Busser, M=20 [mailto:Michael.Busser@t-systems.com] <BR><B>Sent:</B> 15 November = 2007=20 14:36<BR><B>To:</B> ancp@ietf.org<BR><B>Cc:</B> Troester, Stephan; = Haag,T;=20 Witschurke,Birgit<BR><B>Subject:</B> [ANCP] Splitting GSMP messages to = different TCP packets<BR></FONT><BR></DIV> <DIV></DIV> <DIV><FONT face=3DArial size=3D2>Hi all.</FONT></DIV> <DIV> </DIV><FONT face=3DArial size=3D2> <DIV>When the adjacency comes up, a bunch of PORT-STATUS messages will = be sent=20 <BR>by the DSLAM to the BRAS. </DIV> <DIV> </DIV> <DIV>If the amount of data (all the GSMP messages) exceeds the limit = of one=20 TCP-Packet, <BR>the next portion of data have to be sent with the next = TCP=20 packets.</DIV> <DIV> </DIV> <DIV>The question now is:<BR>Do we have any requirements to make sure, = that=20 only complete GSMP messages<BR>are sent in one TCP message?</DIV> <DIV> </DIV> <DIV>From my understanding, the stream of GSMP messages is a byte = stream,=20 <BR>which is transported to the far end by TCP. <BR>The application = layer=20 (e.g. the layer above TCP) do not have to take care <BR>about such = details of=20 transportation.<BR>So the answer is no.</DIV> <DIV> </DIV> <DIV>Am i wrong?</DIV> <DIV> </DIV> <DIV><BR></FONT><FONT color=3D#000080 size=3D2>Best Regards; = Freundliche Gr=FC=DFe=20 </DIV> <DIV align=3Dleft></FONT><B><FONT color=3D#000080> <P>Michael Busser</P></B></FONT><FONT size=3D1> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt">T-Systems=20 Enterprise Services GmbH </SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><FONT=20 size=3D1>Production Line Network Centric Systems</FONT></SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><FONT=20 size=3D1>ICT-Systems Integration</FONT></SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><FONT=20 size=3D1>Network Integration Services</FONT></SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><FONT=20 size=3D1></FONT><SPAN style=3D"COLOR: navy"></SPAN><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy"><FONT face=3DArial = color=3D#000000=20 size=3D2></FONT></SPAN></SPAN> </DIV> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: navy"><FONT color=3D#000000 = size=3D1>Br=FCckes 2 -8,=20 55545 Bad Kreuznach<BR>Postfach 9100, 55541 Bad Kreuznach<BR>+49 671 = 8333 8911=20 (Phone)<BR>+49 521 9210 3859 (Fax)<BR>+49 151 1211 9689 = (Mobile)<BR>E-Mail: <A=20 = href=3D"mailto:michael.busser@t-systems.com">michael.busser@t-systems.com= </A></FONT></SPAN></DIV></SPAN> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"> <DIV class=3DO style=3D"mso-line-spacing: '75 0 0'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN=20 style=3D"FONT-SIZE: 8pt"></SPAN></DIV><SPAN style=3D"FONT-SIZE: = 8pt">Internet:=20 </SPAN><SPAN style=3D"FONT-SIZE: 8pt"><p:onmouseclick = hyperlinktype=3D"url"=20 href=3D"http://www.t-systems.com/"></p:onmouseclick><A=20 onclick=3Dwindow.event.cancelBubble=3Dtrue; = href=3D"http://www.t-systems.com/"=20 target=3D_parent><FONT=20 color=3D#6699ff>http://www.t-systems.com</FONT></A></SPAN><SPAN=20 style=3D"FONT-SIZE: 8pt"> </SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '90 0 50'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"></SPAN></DIV> <DIV class=3DO style=3D"mso-line-spacing: '90 0 50'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN=20 style=3D"FONT-SIZE: 8pt"></SPAN> </DIV> <DIV class=3DO style=3D"mso-line-spacing: '90 0 50'; = mso-margin-left-alt: 169"=20 align=3Dleft v:shape=3D"_x0000_s1026"><SPAN style=3D"FONT-SIZE: = 8pt"><FONT=20 size=3D3> </FONT>=20 <DIV class=3DO v:shape=3D"_x0000_s1026"> <DIV style=3D"mso-line-spacing: '90 0 50'; mso-margin-left-alt: = 169"><SPAN=20 style=3D"FONT-SIZE: 8pt"><FONT size=3D1>T-Systems Enterprise Services=20 GmbH<BR>Aufsichtsrat: Ren=E9 Obermann (Vorsitzender)<BR>Executive = Committee:=20 Helmut Binder, Albert Henn, Olaf Heyden*, Katrin Horstmann, Ulrich = Kemp,=20 Wilfried Peters*, <BR>Dr. Herbert Schaaff*, Zvezdana=20 Seeger*<BR>Handelsregister: Amtsgericht Frankfurt am Main HRB = 55933<BR>Sitz=20 der Gesellschaft: Frankfurt am Main<BR>WEEE-Reg.-Nr.=20 DE87523644<BR>*Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG</FONT>=20 <P><FONT size=3D1>Notice: This transmittal and/or attachments may be = privileged=20 or confidential. If you are not the intended recipient, you are hereby = notified that you have received this transmittal in error; any review, = dissemination, or copying is strictly prohibited. If you received this = transmittal in error, please notify us immediately by reply and = immediately=20 delete this message and all its attachments. Thank you. </FONT><FONT=20 size=3D1><BR>T-Systems =96 Business flexibility=20 </FONT></P></SPAN></DIV></DIV></SPAN></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV></FONT></DIV> <DIV> </DIV></BLOCKQUOTE></BODY></HTML> ------_=_NextPart_001_01C82796.CC273015-- --===============1138667254== 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 --===============1138667254==-- From ancp-bounces@ietf.org Thu Nov 15 10:37:01 2007 Return-path: <ancp-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isgm5-0005na-KZ; Thu, 15 Nov 2007 10:37:01 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1Isgm4-0005nI-Gp for ancp-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 10:37:00 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isgm4-0005n9-4Q for ancp@ietf.org; Thu, 15 Nov 2007 10:37:00 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Isgm3-0001IO-BP for ancp@ietf.org; Thu, 15 Nov 2007 10:37:00 -0500 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Thu, 15 Nov 2007 16:36:53 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Nov 2007 16:36:53 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: AW: [ANCP] Splitting GSMP messages to different TCP packets Date: Thu, 15 Nov 2007 16:36:55 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1C679938@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <D9872168DBD43A41BD71FFC4713274D40432C4D9@xmb-ams-33b.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Splitting GSMP messages to different TCP packets Thread-Index: AcgnjGbhqd/+NxCtQH2SXDUVlwehGQACcICwAACL3+A= References: <1B6169C658325341A3B8066E23919E1C1066A6@S4DE8PSAANK.mitte.t-com.de> <D9872168DBD43A41BD71FFC4713274D40432C4D9@xmb-ams-33b.emea.cisco.com> From: "Haag, T" <Thomas.Haag@t-systems.com> To: <wdec@cisco.com>, <ancp@ietf.org> X-OriginalArrivalTime: 15 Nov 2007 15:36:53.0006 (UTC) FILETIME=[589C82E0:01C8279D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0aa23132abbc731e36938583486affe0 Cc: "Troester, Stephan" <Stephan.Troester@t-com.net>, "Busser, M" <Michael.Busser@t-systems.com>, "Witschurke, Birgit" <Birgit.Witschurke@t-systems.com> X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list <ancp.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ancp>, <mailto:ancp-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/ancp> List-Post: <mailto:ancp@ietf.org> List-Help: <mailto:ancp-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ancp>, <mailto:ancp-request@ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="===============0311894425==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0311894425== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8279D.58120147" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8279D.58120147 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Wojciech, =20 Assuming that GSMP und layer above don't care about Does ANCP provide a = kind of handshake mechanism to enforce the near end sending only port = specific messages again if the application layer at the far end receives = inconclusive messages? =20 Regards Thomas ________________________________ Von: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Gesendet: Donnerstag, 15. November 2007 15:50 An: Busser, Michael; ancp@ietf.org Cc: Tr=F6ster, Stephan; Haag, Thomas; Witschurke, Birgit Betreff: RE: [ANCP] Splitting GSMP messages to different TCP packets =20 Hi Michael, =20 your interpretation is correct with respect to ANCP over TCP. =20 -Woj. =20 =09 ________________________________ From: Busser, M [mailto:Michael.Busser@t-systems.com]=20 Sent: 15 November 2007 14:36 To: ancp@ietf.org Cc: Troester, Stephan; Haag,T; Witschurke,Birgit Subject: [ANCP] Splitting GSMP messages to different TCP packets Hi all. =20 When the adjacency comes up, a bunch of PORT-STATUS messages will be = sent=20 by the DSLAM to the BRAS.=20 =20 If the amount of data (all the GSMP messages) exceeds the limit of one = TCP-Packet,=20 the next portion of data have to be sent with the next TCP packets. =20 The question now is: Do we have any requirements to make sure, that only complete GSMP = messages are sent in one TCP message? =20 From my understanding, the stream of GSMP messages is a byte stream,=20 which is transported to the far end by TCP.=20 The application layer (e.g. the layer above TCP) do not have to take = care=20 about such details of transportation. So the answer is no. =20 Am i wrong? =20 =09 Best Regards; Freundliche Gr=FC=DFe=20 Michael Busser T-Systems Enterprise Services GmbH=20 Production Line Network Centric Systems ICT-Systems Integration Network Integration Services =20 Br=FCckes 2 -8, 55545 Bad Kreuznach Postfach 9100, 55541 Bad Kreuznach +49 671 8333 8911 (Phone) +49 521 9210 3859 (Fax) +49 151 1211 9689 (Mobile) E-Mail: michael.busser@t-systems.com Internet: http://www.t-systems.com <http://www.t-systems.com/> =20 =20 =20 T-Systems Enterprise Services GmbH Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) Executive Committee: Helmut Binder, Albert Henn, Olaf Heyden*, Katrin = Horstmann, Ulrich Kemp, Wilfried Peters*,=20 Dr. Herbert Schaaff*, Zvezdana Seeger* Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 Sitz der Gesellschaft: Frankfurt am Main WEEE-Reg.-Nr. DE87523644 *Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG=20 Notice: This transmittal and/or attachments may be privileged or = confidential. If you are not the intended recipient, you are hereby = notified that you have received this transmittal in error; any review, = dissemination, or copying is strictly prohibited. If you received this = transmittal in error, please notify us immediately by reply and = immediately delete this message and all its attachments. Thank you.=20 T-Systems - Business flexibility=20 =20 =20 ------_=_NextPart_001_01C8279D.58120147 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:p=3D"urn:schemas-microsoft-com:office:powerpoint" = xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" = xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)"> <!--[if !mso]> <style> v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </style> <![endif]--> <title>Nachricht

Hi = Wojciech,

 

Assuming that = GSMP und layer above don’t care about Does ANCP provide a kind of handshake = mechanism to enforce the near end sending only port specific messages again if the = application layer at the far end receives inconclusive = messages?

 =

Regards

Thomas=

Von: = Wojciech Dec (wdec) [mailto:wdec@cisco.com]
Gesendet: Donnerstag, 15. = November 2007 15:50
An: Busser, Michael; ancp@ietf.org
Cc: Tr=F6ster, Stephan; = Haag, Thomas; Witschurke, Birgit
Betreff: RE: [ANCP] = Splitting GSMP messages to different TCP packets

 

Hi Michael,

 

your interpretation is correct with respect = to ANCP over TCP.

 

-Woj.

 

From: Busser, M [mailto:Michael.Busser@t-systems.com]
Sent: 15 November 2007 = 14:36
To: ancp@ietf.org
Cc: Troester, Stephan; = Haag,T; Witschurke,Birgit
Subject: [ANCP] Splitting = GSMP messages to different TCP packets

Hi all.

 

When the adjacency comes up, a bunch of PORT-STATUS = messages will be sent
by the DSLAM to the BRAS.

 

If the amount of data (all the GSMP messages) exceeds = the limit of one TCP-Packet,
the next portion of data have to be sent with the next TCP = packets.

 

The question now is:
Do we have any requirements to make sure, that only complete GSMP = messages
are sent in one TCP message?

 

From my understanding, the stream of GSMP messages is = a byte stream,
which is transported to the far end by TCP.
The application layer (e.g. the layer above TCP) do not have to take = care
about such details of transportation.
So the answer is no.

 

Am i wrong?

 


Best Regards; Freundliche Gr=FC=DFe

Michael = Busser

T-Systems Enterprise Services GmbH

Production Line Network Centric = Systems

ICT-Systems Integration

Network Integration Services

 

Br=FCckes 2 -8, 55545 Bad = Kreuznach
Postfach 9100, 55541 Bad Kreuznach
+49 671 8333 8911 (Phone)
+49 521 9210 3859 (Fax)
+49 151 1211 9689 (Mobile)
E-Mail: michael.busser@t-systems.com=

Internet: http://www.t-systems.com

 

 

T-Systems Enterprise Services GmbH
Aufsichtsrat: Ren=E9 Obermann (Vorsitzender)
Executive Committee: Helmut Binder, Albert Henn, Olaf Heyden*, Katrin Horstmann, Ulrich Kemp, Wilfried Peters*,
Dr. Herbert Schaaff*, Zvezdana Seeger*
Handelsregister: Amtsgericht Frankfurt am Main HRB 55933
Sitz der Gesellschaft: Frankfurt am Main
WEEE-Reg.-Nr. DE87523644
*Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG

Notice: This transmittal and/or attachments may be privileged or confidential. = If you are not the intended recipient, you are hereby notified that you have = received this transmittal in error; any review, dissemination, or copying is = strictly prohibited. If you received this transmittal in error, please notify us immediately by reply and immediately delete this message and all its attachments. Thank you.
T-Systems – Business flexibility

 

 

------_=_NextPart_001_01C8279D.58120147-- --===============0311894425== 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 --===============0311894425==-- From ancp-bounces@ietf.org Thu Nov 15 12:54:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsivB-00064e-KL; Thu, 15 Nov 2007 12:54:33 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IsivA-00063i-SX for ancp-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 12:54:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsivA-000630-Hs for ancp@ietf.org; Thu, 15 Nov 2007 12:54:32 -0500 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Isiv6-0008Ta-Mw for ancp@ietf.org; Thu, 15 Nov 2007 12:54:32 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 39BBE8F0AF; Thu, 15 Nov 2007 09:54:28 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28493-08; Thu, 15 Nov 2007 09:54:28 -0800 (PST) Received: from [127.0.0.1] (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id DA27A8F0AD; Thu, 15 Nov 2007 09:54:27 -0800 (PST) Message-ID: <473C87D3.70008@redback.com> Date: Thu, 15 Nov 2007 09:54:27 -0800 From: Jakob Heitz User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Haag, T" Subject: Re: AW: [ANCP] Splitting GSMP messages to different TCP packets References: <1B6169C658325341A3B8066E23919E1C1066A6@S4DE8PSAANK.mitte.t-com.de> <1B6169C658325341A3B8066E23919E1C679938@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <1B6169C658325341A3B8066E23919E1C679938@S4DE8PSAANK.mitte.t-com.de> Content-Type: text/plain; charset=windows-1252; format=flowed X-Virus-Scanned: by amavisd-new at redback.com Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: "Troester, Stephan" , "Busser, M" , ancp@ietf.org, "Witschurke, Birgit" 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 Yes, there is such a handshake mechanism. If received data is dropped or corrupted or in the wrong order, the sender will retransmit and the receiver will maintain proper order. This is the function of TCP. Haag, T wrote: > Hi Wojciech, >=20 > =20 >=20 > Assuming that GSMP und layer above don=92t care about Does ANCP provide= a=20 > kind of handshake mechanism to enforce the near end sending only port=20 > specific messages again if the application layer at the far end receive= s=20 > inconclusive messages? >=20 > =20 >=20 > Regards >=20 > Thomas >=20 > -----------------------------------------------------------------------= - >=20 > *Von:* Wojciech Dec (wdec) [mailto:wdec@cisco.com] > *Gesendet:* Donnerstag, 15. November 2007 15:50 > *An:* Busser, Michael; ancp@ietf.org > *Cc:* Tr=F6ster, Stephan; Haag, Thomas; Witschurke, Birgit > *Betreff:* RE: [ANCP] Splitting GSMP messages to different TCP packets >=20 > =20 >=20 > Hi Michael, >=20 > =20 >=20 > your interpretation is correct with respect to ANCP over TCP. >=20 > =20 >=20 > -Woj. >=20 > =20 >=20 > -------------------------------------------------------------------= ----- >=20 > *From:* Busser, M [mailto:Michael.Busser@t-systems.com] > *Sent:* 15 November 2007 14:36 > *To:* ancp@ietf.org > *Cc:* Troester, Stephan; Haag,T; Witschurke,Birgit > *Subject:* [ANCP] Splitting GSMP messages to different TCP packets >=20 > Hi all. >=20 > =20 >=20 > When the adjacency comes up, a bunch of PORT-STATUS messages will b= e > sent > by the DSLAM to the BRAS. >=20 > =20 >=20 > If the amount of data (all the GSMP messages) exceeds the limit of > one TCP-Packet, > the next portion of data have to be sent with the next TCP packets. >=20 > =20 >=20 > The question now is: > Do we have any requirements to make sure, that only complete GSMP > messages > are sent in one TCP message? >=20 > =20 >=20 > From my understanding, the stream of GSMP messages is a byte strea= m, > which is transported to the far end by TCP. > The application layer (e.g. the layer above TCP) do not have to tak= e > care > about such details of transportation. > So the answer is no. >=20 > =20 >=20 > Am i wrong? >=20 > =20 >=20 >=20 > Best Regards; Freundliche Gr=FC=DFe >=20 > *Michael Busser* >=20 > T-Systems Enterprise Services GmbH >=20 > Production Line Network Centric Systems >=20 > ICT-Systems Integration >=20 > Network Integration Services >=20 > =20 >=20 > Br=FCckes 2 -8, 55545 Bad Kreuznach > Postfach 9100, 55541 Bad Kreuznach > +49 671 8333 8911 (Phone) > +49 521 9210 3859 (Fax) > +49 151 1211 9689 (Mobile) > E-Mail: michael.busser@t-systems.com > >=20 > Internet: http://www.t-systems.com >=20 > =20 >=20 > =20 >=20 > T-Systems Enterprise Services GmbH > Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) > Executive Committee: Helmut Binder, Albert Henn, Olaf Heyden*, > Katrin Horstmann, Ulrich Kemp, Wilfried Peters*, > Dr. Herbert Schaaff*, Zvezdana Seeger* > Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 > Sitz der Gesellschaft: Frankfurt am Main > WEEE-Reg.-Nr. DE87523644 > *Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG >=20 > Notice: This transmittal and/or attachments may be privileged or > confidential. If you are not the intended recipient, you are hereby > notified that you have received this transmittal in error; any > review, dissemination, or copying is strictly prohibited. If you > received this transmittal in error, please notify us immediately by > reply and immediately delete this message and all its attachments. > Thank you. > T-Systems =96 Business flexibility >=20 > =20 >=20 > =20 >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > 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 Nov 16 03:05:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IswCg-0002L3-Il; Fri, 16 Nov 2007 03:05:30 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IswCf-0002Kf-3C for ancp-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 03:05:29 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IswCZ-0002Is-Uq for ancp@ietf.org; Fri, 16 Nov 2007 03:05:24 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IswCZ-00050C-5b for ancp@ietf.org; Fri, 16 Nov 2007 03:05:23 -0500 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Fri, 16 Nov 2007 09:05:19 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Nov 2007 09:05:18 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: AW: [ANCP] Splitting GSMP messages to different TCP packets Date: Fri, 16 Nov 2007 09:05:23 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1C679A2C@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <473C87D3.70008@redback.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [ANCP] Splitting GSMP messages to different TCP packets Thread-Index: AcgnsLX5XS3Ns04wQyiPfkAVxJpEcQAdNcIw References: <1B6169C658325341A3B8066E23919E1C1066A6@S4DE8PSAANK.mitte.t-com.de> <1B6169C658325341A3B8066E23919E1C679938@S4DE8PSAANK.mitte.t-com.de> <473C87D3.70008@redback.com> From: "Haag, T" To: X-OriginalArrivalTime: 16 Nov 2007 08:05:18.0771 (UTC) FILETIME=[6D9A1830:01C82827] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: "Troester, Stephan" , "Busser, M" , ancp@ietf.org, "Witschurke, Birgit" 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 I think it is a misunderstanding. That TCP has such a mechanism is quite = clear.=20 But the question was if GSMP on top of TCP has a handshake mechanism? There is need for a mechanism which provides a retransmission of = dedicated DSL port information, if the BRAS could not interpret a single = message. Regards Thomas -----Urspr=FCngliche Nachricht----- Von: Jakob Heitz [mailto:jheitz@redback.com]=20 Gesendet: Donnerstag, 15. November 2007 18:54 An: Haag, Thomas Cc: Tr=F6ster, Stephan; Busser, Michael; ancp@ietf.org; Witschurke, = Birgit Betreff: Re: AW: [ANCP] Splitting GSMP messages to different TCP packets Yes, there is such a handshake mechanism. If received data is dropped or corrupted or in the wrong order, the sender will retransmit and the receiver will maintain proper order. This is the function of TCP. Haag, T wrote: > Hi Wojciech, >=20 > =20 >=20 > Assuming that GSMP und layer above don't care about Does ANCP provide = a=20 > kind of handshake mechanism to enforce the near end sending only port=20 > specific messages again if the application layer at the far end = receives=20 > inconclusive messages? >=20 > =20 >=20 > Regards >=20 > Thomas >=20 > = ------------------------------------------------------------------------ >=20 > *Von:* Wojciech Dec (wdec) [mailto:wdec@cisco.com] > *Gesendet:* Donnerstag, 15. November 2007 15:50 > *An:* Busser, Michael; ancp@ietf.org > *Cc:* Tr=F6ster, Stephan; Haag, Thomas; Witschurke, Birgit > *Betreff:* RE: [ANCP] Splitting GSMP messages to different TCP packets >=20 > =20 >=20 > Hi Michael, >=20 > =20 >=20 > your interpretation is correct with respect to ANCP over TCP. >=20 > =20 >=20 > -Woj. >=20 > =20 >=20 > = ------------------------------------------------------------------------ >=20 > *From:* Busser, M [mailto:Michael.Busser@t-systems.com] > *Sent:* 15 November 2007 14:36 > *To:* ancp@ietf.org > *Cc:* Troester, Stephan; Haag,T; Witschurke,Birgit > *Subject:* [ANCP] Splitting GSMP messages to different TCP packets >=20 > Hi all. >=20 > =20 >=20 > When the adjacency comes up, a bunch of PORT-STATUS messages will = be > sent > by the DSLAM to the BRAS. >=20 > =20 >=20 > If the amount of data (all the GSMP messages) exceeds the limit of > one TCP-Packet, > the next portion of data have to be sent with the next TCP = packets. >=20 > =20 >=20 > The question now is: > Do we have any requirements to make sure, that only complete GSMP > messages > are sent in one TCP message? >=20 > =20 >=20 > From my understanding, the stream of GSMP messages is a byte = stream, > which is transported to the far end by TCP. > The application layer (e.g. the layer above TCP) do not have to = take > care > about such details of transportation. > So the answer is no. >=20 > =20 >=20 > Am i wrong? >=20 > =20 >=20 >=20 > Best Regards; Freundliche Gr=FC=DFe >=20 > *Michael Busser* >=20 > T-Systems Enterprise Services GmbH >=20 > Production Line Network Centric Systems >=20 > ICT-Systems Integration >=20 > Network Integration Services >=20 > =20 >=20 > Br=FCckes 2 -8, 55545 Bad Kreuznach > Postfach 9100, 55541 Bad Kreuznach > +49 671 8333 8911 (Phone) > +49 521 9210 3859 (Fax) > +49 151 1211 9689 (Mobile) > E-Mail: michael.busser@t-systems.com > >=20 > Internet: http://www.t-systems.com >=20 > =20 >=20 > =20 >=20 > T-Systems Enterprise Services GmbH > Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) > Executive Committee: Helmut Binder, Albert Henn, Olaf Heyden*, > Katrin Horstmann, Ulrich Kemp, Wilfried Peters*, > Dr. Herbert Schaaff*, Zvezdana Seeger* > Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 > Sitz der Gesellschaft: Frankfurt am Main > WEEE-Reg.-Nr. DE87523644 > *Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG >=20 > Notice: This transmittal and/or attachments may be privileged or > confidential. If you are not the intended recipient, you are = hereby > notified that you have received this transmittal in error; any > review, dissemination, or copying is strictly prohibited. If you > received this transmittal in error, please notify us immediately = by > reply and immediately delete this message and all its attachments. > Thank you. > T-Systems - Business flexibility >=20 > =20 >=20 > =20 >=20 >=20 > = ------------------------------------------------------------------------ >=20 > _______________________________________________ > 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 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Fri Nov 16 03:24:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IswVO-0000qR-Ou; Fri, 16 Nov 2007 03:24:50 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IswVN-0000nR-6d for ancp-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 03:24:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IswVM-0000jR-Mg for ancp@ietf.org; Fri, 16 Nov 2007 03:24:48 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IswVL-00069D-L3 for ancp@ietf.org; Fri, 16 Nov 2007 03:24:48 -0500 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Fri, 16 Nov 2007 09:24:45 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Nov 2007 09:24:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C8282A.24580AF3" Date: Fri, 16 Nov 2007 09:24:44 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1C1066AF@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Which GSMP document? Thread-Index: AcgnTcX0dUTE19zOS/+7LYajpXJgLAARZtxAACQ/03A= From: "Busser, M" To: X-OriginalArrivalTime: 16 Nov 2007 08:24:45.0325 (UTC) FILETIME=[24EC1BD0:01C8282A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9cc83ac38bbbabacbf00f656311dd8d8 Cc: Subject: [ANCP] Which GSMP document? 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 This is a multi-part message in MIME format. ------_=_NextPart_001_01C8282A.24580AF3 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C8282A.24580AF3" ------_=_NextPart_002_01C8282A.24580AF3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Smita, all =20 The actual version of the ANCP draft refeers to:=20 [4] Doria, A. et al, "General Switch Management Protocol- V3" = (GSMPv3), RFC 3292, June 2002. =20 The first figure in section 5.4.3 fits to some later revisions of the = GSMP document=20 (e.g. draft-ietf-gsmp-v3-base-spec-06.txt or = draft-ietf-gsmp-v3-base-spec-08.txt). =20 There are some differences between this both documents, we should take = into account: =20 GSMPv3:=20 - The document does not have a field X-Function in the PORT MANAGEMENT = message It only contains a field Function wich is 16 bits long.=20 - The field "Transmit Data Rate" does exist - action code 0x8 is already defined as "Set Transmit Data Rate" =20 =20 A later revisions of the GSMP document (e.g. = draft-ietf-gsmp-v3-base-spec-06.txt or = draft-ietf-gsmp-v3-base-spec-08.txt): - The 16 bit field Function is splitted up into two 8 bit fields named = Function and X-Funtion=20 - The field "Transmit Data Rate" does not exist - action code 8 is not defined =20 =20 Shouldn't we describe the changes of the GSMP messages, which we need = for ANCP according to GSMPv3 RFC ? All later revisions of the GSMP document are already expired, as far as = i know. =20 =20 Best regard=20 =20 Michael Busser T-Systems Enterprise Services GmbH=20 Production Line Network Centric Systems ICT-Systems Integration Network Integration Services =20 =20 -----Urspr=FCngliche Nachricht----- Von: smita_selot@agilent.com [mailto:smita_selot@agilent.com]=20 Gesendet: Donnerstag, 15. November 2007 07:07 An: ancp@ietf.org Betreff: [ANCP] Query about ANCP The field X-Function which is sent in the Line Configuration Extension = block sent by NAS(Refer To section 5.4.3 in draft-ietf-ancp-protocol-01.txt) is not defined in = the=20 Draft. Where can this definition be found?=20 =20 Regards, Smita. ------_=_NextPart_002_01C8282A.24580AF3 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Nachricht
Hello Smita,=20 all
 
The=20 actual version of the ANCP draft refeers to:
[4]   Doria, = A. et al,=20 "General Switch Management Protocol- V3" (GSMPv3), RFC 3292, June=20 2002.
 
The=20 first figure in section 5.4.3 fits to some later revisions of the GSMP = document=20
(e.g. draft-ietf-gsmp-v3-base-spec-06.txt  or  = draft-ietf-gsmp-v3-base-spec-08.txt).
 
There=20 are some differences between this both documents, we should take into=20 account:
 
GSMPv3: 
- The=20 document does not have a field X-Function in the PORT MANAGEMENT=20 message
  It only=20 contains a field Function wich is 16 bits = long. 
- The field "Transmit Data Rate" does=20 exist
- action code 0x8 is already defined as "Set = Transmit=20 Data Rate"
 
 
A=20 later revisions of the GSMP document (e.g.=20 draft-ietf-gsmp-v3-base-spec-06.txt  or =20 draft-ietf-gsmp-v3-base-spec-08.txt):
- The = 16 bit field=20 Function is splitted up into two 8 bit fields named Function = and X-Funtion=20
- The = field=20 "Transmit Data Rate" does not exist
- = action code 8 is=20 not defined
 
 
Shouldn't we=20 describe the changes of the GSMP messages, which we need for ANCP = according to=20 GSMPv3 =20 RFC ?
All = later revisions=20 of the GSMP document are already expired, as far as i = know.
 
 
Best = regard=20
 
Michael Busser
T-Systems=20 Enterprise Services GmbH
Production Line Network Centric Systems
ICT-Systems Integration
Network Integration Services
 
 
-----Urspr=FCngliche Nachricht-----
Von: = smita_selot@agilent.com=20 [mailto:smita_selot@agilent.com]
Gesendet: Donnerstag, 15. = November=20 2007 07:07
An: ancp@ietf.org
Betreff: [ANCP] Query = about=20 ANCP

The field X-Function which = is sent=20 in the Line Configuration Extension block sent by=20 NAS(Refer

To section 5.4.3 in=20 draft-ietf-ancp-protocol-01.txt)=20 is not defined in the

Draft. Where can = this=20 definition be found?

 

Regards,

Smita.

------_=_NextPart_002_01C8282A.24580AF3-- ------_=_NextPart_001_01C8282A.24580AF3 Content-Type: text/plain; name="ATT181650.txt" Content-Transfer-Encoding: base64 Content-Description: ATT181650.txt Content-Disposition: inline; filename="ATT181650.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkFOQ1AgbWFp bGluZyBsaXN0DQpBTkNQQGlldGYub3JnDQpodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9hbmNwDQo= ------_=_NextPart_001_01C8282A.24580AF3 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_001_01C8282A.24580AF3-- From ancp-bounces@ietf.org Fri Nov 16 04:01:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isx4w-0006b4-N8; Fri, 16 Nov 2007 04:01:34 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1Isx4v-0006am-3I for ancp-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 04:01:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isx4u-0006aB-Ox for ancp@ietf.org; Fri, 16 Nov 2007 04:01:32 -0500 Received: from smail5.alcatel.fr ([64.208.49.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Isx4p-000435-Eu for ancp@ietf.org; Fri, 16 Nov 2007 04:01:32 -0500 Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.ad2.ad.alcatel.com [155.132.6.78]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id lAG903ZH022785; Fri, 16 Nov 2007 10:00:04 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.52]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 16 Nov 2007 10:01:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: AW: [ANCP] Splitting GSMP messages to different TCP packets Date: Fri, 16 Nov 2007 10:01:24 +0100 Message-ID: <238382595265324EA50F6134BB42DCAF0112C1F6@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <1B6169C658325341A3B8066E23919E1C679A2C@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [ANCP] Splitting GSMP messages to different TCP packets Thread-Index: AcgnsLX5XS3Ns04wQyiPfkAVxJpEcQAdNcIwAAFY5hA= References: <1B6169C658325341A3B8066E23919E1C1066A6@S4DE8PSAANK.mitte.t-com.de> <1B6169C658325341A3B8066E23919E1C679938@S4DE8PSAANK.mitte.t-com.de><473C87D3.70008@redback.com> <1B6169C658325341A3B8066E23919E1C679A2C@S4DE8PSAANK.mitte.t-com.de> From: "PESCHI Robert" To: "Haag, T" , X-OriginalArrivalTime: 16 Nov 2007 09:01:25.0255 (UTC) FILETIME=[442EC970:01C8282F] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: 89a1e35b8763fad584ad8e0b42e66144 Cc: "Troester, Stephan" , "Busser, M" , ancp@ietf.org, "Witschurke, Birgit" 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="===============2111757296==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============2111757296== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8282F.43D2D0B7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8282F.43D2D0B7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thomas, The genuine "General Switch Management Protocol (GSMP) V3" (RFC 3292) = foresees some=20 optional rudimentary mechanism to acknowledge GSMP messages: >From RFC3292: "3. Common Definitions and Procedures GSMP is a master-slave protocol. The controller issues request messages to the switch. Each request message indicates whether a response is required from the switch and contains a transaction identifier to enable the response to be associated with the request. The switch replies with a response message indicating either a successful result or a failure. There are six classes of GSMP request-response message: Connection Management, Reservation Management, Port Management, State and Statistics, Configuration, and Quality of Service. The switch may also generate asynchronous Event messages to inform the controller of asynchronous events. The controller can be required to acknowledge event messages, but by default does not do so. There is also an adjacency protocol message used to establish synchronisation across the link and maintain a handshake." and further:=20 "3.1 GSMP Packet Format=20 ReturnReceipt is a result field used in Events to indicate that=20 an acknowledgement is required for the message. The default for=20 Events Messages is that the controller will not acknowledge = Events.=20 In the case where a switch requires acknowledgement, it will set=20 the Result Field to ReturnReceipt in the header of the Event = Message."=20 This (optional) mechanism has been kept by default in = http://www.ietf.org/internet-drafts/draft-ietf-ancp-protocol-01.txt. Of course, as long as TCP is used, this mechanism has no added value I = would say. Kind regards, Robert Robert Peschi DSL Product Architect, Access Network Division Tel.: +32 3 240 8926 GSM: +32 477 29 78 07 Alcatel-Lucent Bell NV Copernicuslaan 50, 2018 Antwerp, Belgium Fortis 220-0002334-42 VAT BE 0404 621 642 Register of Legal Entities Antwerp This message (including any attachments) contains confidential = information intended for a specific individual and purpose, and is = protected by law. If you are not the intended recipient, you should = delete this message. Any disclosure, copying, or distribution of this = message, or the taking of any action based on it, is strictly prohibited = without the prior consent of its author. -----Original Message----- From: Haag, T [mailto:Thomas.Haag@t-systems.com]=20 Sent: Friday, November 16, 2007 9:05 AM To: jheitz@redback.com Cc: Troester, Stephan; Busser,M; ancp@ietf.org; Witschurke,Birgit Subject: AW: AW: [ANCP] Splitting GSMP messages to different TCP packets I think it is a misunderstanding. That TCP has such a mechanism is quite = clear.=20 But the question was if GSMP on top of TCP has a handshake mechanism? There is need for a mechanism which provides a retransmission of = dedicated DSL port information, if the BRAS could not interpret a single = message. Regards Thomas -----Urspr=FCngliche Nachricht----- Von: Jakob Heitz [mailto:jheitz@redback.com] Gesendet: Donnerstag, 15. November 2007 18:54 An: Haag, Thomas Cc: Tr=F6ster, Stephan; Busser, Michael; ancp@ietf.org; Witschurke, = Birgit Betreff: Re: AW: [ANCP] Splitting GSMP messages to different TCP packets Yes, there is such a handshake mechanism. If received data is dropped or = corrupted or in the wrong order, the sender will retransmit and the = receiver will maintain proper order. This is the function of TCP. Haag, T wrote: > Hi Wojciech, >=20 > =20 >=20 > Assuming that GSMP und layer above don't care about Does ANCP provide=20 > a kind of handshake mechanism to enforce the near end sending only=20 > port specific messages again if the application layer at the far end=20 > receives inconclusive messages? >=20 > =20 >=20 > Regards >=20 > Thomas >=20 > ---------------------------------------------------------------------- > -- >=20 > *Von:* Wojciech Dec (wdec) [mailto:wdec@cisco.com] > *Gesendet:* Donnerstag, 15. November 2007 15:50 > *An:* Busser, Michael; ancp@ietf.org > *Cc:* Tr=F6ster, Stephan; Haag, Thomas; Witschurke, Birgit > *Betreff:* RE: [ANCP] Splitting GSMP messages to different TCP packets >=20 > =20 >=20 > Hi Michael, >=20 > =20 >=20 > your interpretation is correct with respect to ANCP over TCP. >=20 > =20 >=20 > -Woj. >=20 > =20 >=20 > =20 > ---------------------------------------------------------------------- > -- >=20 > *From:* Busser, M [mailto:Michael.Busser@t-systems.com] > *Sent:* 15 November 2007 14:36 > *To:* ancp@ietf.org > *Cc:* Troester, Stephan; Haag,T; Witschurke,Birgit > *Subject:* [ANCP] Splitting GSMP messages to different TCP packets >=20 > Hi all. >=20 > =20 >=20 > When the adjacency comes up, a bunch of PORT-STATUS messages will = be > sent > by the DSLAM to the BRAS. >=20 > =20 >=20 > If the amount of data (all the GSMP messages) exceeds the limit of > one TCP-Packet, > the next portion of data have to be sent with the next TCP = packets. >=20 > =20 >=20 > The question now is: > Do we have any requirements to make sure, that only complete GSMP > messages > are sent in one TCP message? >=20 > =20 >=20 > From my understanding, the stream of GSMP messages is a byte = stream, > which is transported to the far end by TCP. > The application layer (e.g. the layer above TCP) do not have to = take > care > about such details of transportation. > So the answer is no. >=20 > =20 >=20 > Am i wrong? >=20 > =20 >=20 >=20 > Best Regards; Freundliche Gr=FC=DFe >=20 > *Michael Busser* >=20 > T-Systems Enterprise Services GmbH >=20 > Production Line Network Centric Systems >=20 > ICT-Systems Integration >=20 > Network Integration Services >=20 > =20 >=20 > Br=FCckes 2 -8, 55545 Bad Kreuznach > Postfach 9100, 55541 Bad Kreuznach > +49 671 8333 8911 (Phone) > +49 521 9210 3859 (Fax) > +49 151 1211 9689 (Mobile) > E-Mail: michael.busser@t-systems.com > >=20 > Internet: http://www.t-systems.com >=20 > =20 >=20 > =20 >=20 > T-Systems Enterprise Services GmbH > Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) > Executive Committee: Helmut Binder, Albert Henn, Olaf Heyden*, > Katrin Horstmann, Ulrich Kemp, Wilfried Peters*, > Dr. Herbert Schaaff*, Zvezdana Seeger* > Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 > Sitz der Gesellschaft: Frankfurt am Main > WEEE-Reg.-Nr. DE87523644 > *Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG >=20 > Notice: This transmittal and/or attachments may be privileged or > confidential. If you are not the intended recipient, you are = hereby > notified that you have received this transmittal in error; any > review, dissemination, or copying is strictly prohibited. If you > received this transmittal in error, please notify us immediately = by > reply and immediately delete this message and all its attachments. > Thank you. > T-Systems - Business flexibility >=20 > =20 >=20 > =20 >=20 >=20 > ---------------------------------------------------------------------- > -- >=20 > _______________________________________________ > 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 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp ------_=_NextPart_001_01C8282F.43D2D0B7 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: AW: [ANCP] Splitting GSMP messages to different TCP = packets

Thomas,

The genuine = "General Switch Management Protocol (GSMP) V3" (RFC 3292) = foresees some
optional = rudimentary mechanism to acknowledge GSMP messages:

From = RFC3292:

        "3.  Common Definitions and = Procedures

        GSMP is a master-slave protocol.  The = controller issues request
        = messages to the switch.  Each request message indicates = whether a
        = response is required = from the switch and contains a transaction
        = identifier to enable the = response to be associated with the request.
        = The switch replies with a response message = indicating either a
        = successful result or a failure.  = There are six classes of GSMP
        = request-response message: Connection = Management, Reservation
        = Management, Port Management, State and = Statistics, Configuration, and
        = Quality of Service.  The switch may also generate = asynchronous Event
        = messages to inform the = controller of asynchronous events.  The
        = controller can be = required to acknowledge event messages, but by
        = default does not do = so.  There is also an = adjacency protocol message
        = used to establish synchronisation across = the link and maintain a
        = handshake."

 and further: =

        "3.1 GSMP Packet Format

        ReturnReceipt is a result = field used in Events to indicate that
      an acknowledgement is = required for the message. The = default for
      Events Messages is that = the controller will not acknowledge Events.
      In the case where a switch = requires acknowledgement, it will set
      the Result Field to = ReturnReceipt in the header of the Event Message."

This (optional) = mechanism has been kept by default in http://www.ietf.org/internet-drafts/draft-ietf-ancp-protoc= ol-01.txt.

Of course, as long = as TCP is used, this mechanism has no added value I would = say.

Kind = regards,
Robert

Robert = Peschi
DSL Product = Architect,
Access Network = Division
Tel.: +32 3 240 = 8926
GSM: +32 477 29 = 78 07

Alcatel-Lucent = Bell NV
Copernicuslaan = 50, 2018 Antwerp, Belgium
Fortis = 220-0002334-42
VAT BE 0404 621 = 642 Register of Legal Entities Antwerp

This message = (including any attachments) contains confidential information intended = for a specific individual and purpose, and is protected by law.  If = you are not the intended recipient, you should delete this = message.  Any disclosure, copying, or distribution of this message, = or the taking of any action based on it, is strictly prohibited without = the prior consent of its author.

-----Original = Message-----
From: Haag, T = [mailto:Thomas.Haag@t-systems.com]
Sent: Friday, = November 16, 2007 9:05 AM
To: = jheitz@redback.com
Cc: Troester, = Stephan; Busser,M; ancp@ietf.org; Witschurke,Birgit
Subject: AW: AW: = [ANCP] Splitting GSMP messages to different TCP packets

I think it is a = misunderstanding. That TCP has such a mechanism is quite clear. =

But the question = was if GSMP on top of TCP has a handshake mechanism?

There is need for = a mechanism which provides a retransmission of dedicated DSL port = information, if the BRAS could not interpret a single = message.

Regards
Thomas

-----Urspr=FCngliche Nachricht-----
Von: Jakob Heitz = [mailto:jheitz@redback.com]
Gesendet: = Donnerstag, 15. November 2007 18:54
An: Haag, = Thomas
Cc: Tr=F6ster, = Stephan; Busser, Michael; ancp@ietf.org; Witschurke, = Birgit
Betreff: Re: AW: = [ANCP] Splitting GSMP messages to different TCP packets

Yes, there is such = a handshake mechanism. If received data is dropped or corrupted or in = the wrong order, the sender will retransmit and the receiver will = maintain proper order.

This is the = function of TCP.

Haag, T = wrote:
> Hi = Wojciech,
> =
>  =
> =
> Assuming = that GSMP und layer above don't care about Does ANCP provide =
> a kind of = handshake mechanism to enforce the near end sending only
> port = specific messages again if the application layer at the far end =
> receives = inconclusive messages?
> =
>  =
> =
> = Regards
> =
> = Thomas
> =
> = ----------------------------------------------------------------------
> = --
> =
> *Von:* = Wojciech Dec (wdec) [mailto:wdec@cisco.com]
> *Gesendet:* = Donnerstag, 15. November 2007 15:50
> *An:* = Busser, Michael; ancp@ietf.org
> *Cc:* = Tr=F6ster, Stephan; Haag, Thomas; Witschurke, Birgit
> *Betreff:* = RE: [ANCP] Splitting GSMP messages to different TCP = packets
> =
>  =
> =
> Hi = Michael,
> =
>  =
> =
> your = interpretation is correct with respect to ANCP over TCP.
> =
>  =
> =
> = -Woj.
> =
>     
> =
>    
> = ----------------------------------------------------------------------
> = --
> =
>     *From:* Busser, M = [mailto:Michael.Busser@t-systems.com<= SPAN LANG=3D"en-us">]
>     *Sent:* 15 November 2007 = 14:36
>     *To:* = ancp@ietf.org
>     *Cc:* Troester, Stephan; = Haag,T; Witschurke,Birgit
>     *Subject:* [ANCP] Splitting = GSMP messages to different TCP packets
> =
>     Hi all.
> =
>     
> =
>     When the adjacency comes up, = a bunch of PORT-STATUS messages will be
>     sent
>     by the DSLAM to the = BRAS.
> =
>     
> =
>     If the amount of data (all = the GSMP messages) exceeds the limit of
>     one = TCP-Packet,
>     the next portion of data = have to be sent with the next TCP packets.
> =
>     
> =
>     The question now = is:
>     Do we have any requirements = to make sure, that only complete GSMP
>     messages
>     are sent in one TCP = message?
> =
>     
> =
>      From my understanding, = the stream of GSMP messages is a byte stream,
>     which is transported to the = far end by TCP.
>     The application layer (e.g. = the layer above TCP) do not have to take
>     care
>     about such details of = transportation.
>     So the answer is = no.
> =
>     
> =
>     Am i wrong?
> =
>     
> =
> =
>     Best Regards; Freundliche = Gr=FC=DFe
> =
>     *Michael = Busser*
> =
>     T-Systems Enterprise = Services GmbH
> =
>     Production Line Network = Centric Systems
> =
>     ICT-Systems = Integration
> =
>     Network Integration = Services
> =
>     
> =
>     Br=FCckes 2 -8, 55545 Bad = Kreuznach
>     Postfach 9100, 55541 Bad = Kreuznach
>     +49 671 8333 8911 = (Phone)
>     +49 521 9210 3859 = (Fax)
>     +49 151 1211 9689 = (Mobile)
>     E-Mail: = michael.busser@t-systems.com
>     <mailto:michael.busser@t-systems.com<= SPAN LANG=3D"en-us">>
> =
>     Internet: http://www.t-systems.com <http://www.t-systems.com/>
> =
>     
> =
>     
> =
>     T-Systems Enterprise = Services GmbH
>     Aufsichtsrat: Ren=E9 = Obermann (Vorsitzender)
>     Executive Committee: Helmut = Binder, Albert Henn, Olaf Heyden*,
>     Katrin Horstmann, Ulrich = Kemp, Wilfried Peters*,
>     Dr. Herbert Schaaff*, = Zvezdana Seeger*
>     Handelsregister: Amtsgericht = Frankfurt am Main HRB 55933
>     Sitz der Gesellschaft: = Frankfurt am Main
>     WEEE-Reg.-Nr. = DE87523644
>     *Gesch=E4ftsf=FChrer gem. = =A7 35 GmbHG
> =
>     Notice: This transmittal = and/or attachments may be privileged or
>     confidential. If you are not = the intended recipient, you are hereby
>     notified that you have = received this transmittal in error; any
>     review, dissemination, or = copying is strictly prohibited. If you
>     received this transmittal in = error, please notify us immediately by
>     reply and immediately delete = this message and all its attachments.
>     Thank you.
>     T-Systems - Business = flexibility
> =
>     
> =
>     
> =
> =
> = ----------------------------------------------------------------------
> = --
> =
> = _______________________________________________
> 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


_______________________________________________
ANCP mailing = list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp

------_=_NextPart_001_01C8282F.43D2D0B7-- --===============2111757296== 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 --===============2111757296==-- From ancp-bounces@ietf.org Fri Nov 16 04:07:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsxAS-0005Kv-TV; Fri, 16 Nov 2007 04:07:16 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IsxAS-0005Kn-9y for ancp-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 04:07:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsxAR-0005Jz-VM for ancp@ietf.org; Fri, 16 Nov 2007 04:07:15 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsxAN-0004Re-Lw for ancp@ietf.org; Fri, 16 Nov 2007 04:07:15 -0500 X-IronPort-AV: E=Sophos;i="4.21,425,1188770400"; d="scan'208,217";a="157886286" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 16 Nov 2007 10:07:09 +0100 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 lAG978up012286; Fri, 16 Nov 2007 10:07:08 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAG976YS025528; Fri, 16 Nov 2007 09:07:08 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 10:07:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 16 Nov 2007 10:06:29 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Depreciate Port-Up message TLV 0x02 Thread-Index: AcgoL/nPygJ+XoSST5WEyFZan7jXqg== From: "Wojciech Dec (wdec)" To: "Sanjay Wadhwa" X-OriginalArrivalTime: 16 Nov 2007 09:07:03.0495 (UTC) FILETIME=[0DCA1D70:01C82830] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15548.001 X-TM-AS-Result: No--6.343400-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3255; t=1195204029; x=1196068029; c=relaxed/simple; s=amsdkim2001; 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:=20Depreciate=20Port-Up=20message=20TLV=200x02=20 |Sender:=20; bh=3CxteFh8OZJ0Rwkg7XsL7HnZ+Rf8jZIGoExRX3Pssqg=; b=VJ9/6eg6GnIkcbhYMo3J5x/a34UrBAtg0o0MaIRzkVyL/NCm8QF6UUpXOxLPOPAa7Azzws3y 1+vMlAJoFp14M+O9ovod7W8S003TDpqus9e+pV6jjvekiNRUWkxcmr/1; Authentication-Results: ams-dkim-2; header.From=wdec@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: ancp@ietf.org Subject: [ANCP] Depreciate Port-Up message TLV 0x02 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="===============0040208784==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0040208784== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C82830.0D7D7170" This is a multi-part message in MIME format. ------_=_NextPart_001_01C82830.0D7D7170 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Sanjay, in your next revision of the protocol spec could you please make sure to address the PENDING issue of depreciating conflicting TLVs? (This has been an open item since the beginning of the year) The full mail thread can be reviewed on the ANCP WG alias, but http://www1.ietf.org/mail-archive/web/ancp/current/msg00152.html contains a conclusion of sorts. This conclusion was discussed at IETF 68 and accepted by the WG. In summary: TLV and sub-TLV conflicts have appeared. Approach is to depreciate use of such conflicting items. PORT-UP TLV Type 0x02 (Access-Loop-Remote-Id). Should have a new TLV # ***PENDING*** =20 PORT-UP TLV 0x04 (DSL Line attributes) sub-TLV 0x90 (Access Loop Encapsulation) . Should have a new sub-TLV # ***DONE New sub-TLV is 0x91***=20 Thanks, Woj. ------_=_NextPart_001_01C82830.0D7D7170 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Depreciate Port-Up message TLV 0x02

Hi = Sanjay,

in your next = revision of the protocol spec could you please make sure to address the = PENDING issue of depreciating conflicting TLVs? (This has been an open = item since the beginning of the year)

The full mail = thread can be reviewed on the ANCP WG alias, but http://www1.ietf.org/mail-archive/web/ancp/current/msg0015= 2.html contains a conclusion of sorts. This conclusion was = discussed at IETF 68 and accepted by the WG.

In = summary:
TLV and sub-TLV = conflicts have appeared. Approach is to depreciate use of such = conflicting items.

PORT-UP TLV Type = 0x02 (Access-Loop-Remote-Id). Should have a new TLV #  = ***PENDING***  
PORT-UP TLV 0x04 = (DSL Line attributes) sub-TLV 0x90 (Access Loop Encapsulation) . Should = have a new sub-TLV #  ***DONE New sub-TLV is 0x91*** =

Thanks,
Woj.

------_=_NextPart_001_01C82830.0D7D7170-- --===============0040208784== 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 --===============0040208784==-- From ancp-bounces@ietf.org Fri Nov 16 04:18:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsxLY-0002hS-Al; Fri, 16 Nov 2007 04:18:44 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IsxLX-0002hJ-Bi for ancp-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 04:18:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsxLW-0002hB-Vw for ancp@ietf.org; Fri, 16 Nov 2007 04:18:43 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsxLV-0000t0-VJ for ancp@ietf.org; Fri, 16 Nov 2007 04:18:42 -0500 X-IronPort-AV: E=Sophos;i="4.21,425,1188770400"; d="scan'208";a="157887944" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 16 Nov 2007 10:18:41 +0100 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 lAG9IfWp016332; Fri, 16 Nov 2007 10:18:41 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAG9IaYS000257; Fri, 16 Nov 2007 09:18:36 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 10:18:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: [ANCP] Splitting GSMP messages to different TCP packets Date: Fri, 16 Nov 2007 10:18:24 +0100 Message-ID: In-Reply-To: <1B6169C658325341A3B8066E23919E1C679A2C@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [ANCP] Splitting GSMP messages to different TCP packets Thread-Index: AcgnsLX5XS3Ns04wQyiPfkAVxJpEcQAdNcIwAAK1VTA= References: <1B6169C658325341A3B8066E23919E1C1066A6@S4DE8PSAANK.mitte.t-com.de> <1B6169C658325341A3B8066E23919E1C679938@S4DE8PSAANK.mitte.t-com.de><473C87D3.70008@redback.com> <1B6169C658325341A3B8066E23919E1C679A2C@S4DE8PSAANK.mitte.t-com.de> From: "Wojciech Dec (wdec)" To: "Haag, T" , X-OriginalArrivalTime: 16 Nov 2007 09:18:33.0654 (UTC) FILETIME=[A9280560:01C82831] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15548.001 X-TM-AS-Result: No--37.468400-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6933; t=1195204721; x=1196068721; c=relaxed/simple; s=amsdkim2001; 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=20AW=3A=20[ANCP]=20Splitting=20GSMP=20messages=20to=20d ifferent=20TCP=20packets |Sender:=20; bh=4xYmrwxryx51m/qyKRXluG2KOHzDcd05u6EhubiSZVk=; b=vyD5BGrq+c9wv0VXLiR/WeD6bDqcFeAtmUMNa2naQd2iO+4IH+hNp9treL2RzXguzcxjKhwY QfbtWgCU7NRI7J4CcMhFPcv1qPcz6b7Wow69zuQP5DpvINCTyFVifJB8; Authentication-Results: ams-dkim-2; header.From=wdec@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 Cc: "Troester, Stephan" , "Busser, M" , ancp@ietf.org, "Witschurke, Birgit" 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 Thomas, the handshake you're looking for is a combination of ANCP version and = ANCP capability exchange. The latter is currently has a few shortcomings = that we'll hopefully get to address soon. In essence, TCP (currently) guarantees reliable and ordered delivery. If the BRAS, or DSLAM do not understand a message, then retransmitting = it won't help. This is a basic protocol issue that is addressed by the = two sides agreeing to use a commonly understood message set. This actually opens up another point: We have previously discussed (and = included in our charter) the possibility of using an alternative = transport protocol. The WG however has however not seen much follow-up = on this, especially in terms of laying out the reasons why, for example, = the rate-change information needs to be transmitted reliably and/or = acknowledged. This seems like a good time to have this discussion. Regards, Woj. > -----Original Message----- > From: Haag, T [mailto:Thomas.Haag@t-systems.com]=20 > Sent: 16 November 2007 09:05 > To: jheitz@redback.com > Cc: Troester, Stephan; Busser,M; ancp@ietf.org; Witschurke,Birgit > Subject: AW: AW: [ANCP] Splitting GSMP messages to different=20 > TCP packets >=20 > I think it is a misunderstanding. That TCP has such a=20 > mechanism is quite clear.=20 >=20 > But the question was if GSMP on top of TCP has a handshake mechanism? >=20 > There is need for a mechanism which provides a retransmission=20 > of dedicated DSL port information, if the BRAS could not=20 > interpret a single message. >=20 > Regards > Thomas >=20 > -----Urspr=FCngliche Nachricht----- > Von: Jakob Heitz [mailto:jheitz@redback.com] > Gesendet: Donnerstag, 15. November 2007 18:54 > An: Haag, Thomas > Cc: Tr=F6ster, Stephan; Busser, Michael; ancp@ietf.org;=20 > Witschurke, Birgit > Betreff: Re: AW: [ANCP] Splitting GSMP messages to different=20 > TCP packets >=20 > Yes, there is such a handshake mechanism. If received data is=20 > dropped or corrupted or in the wrong order, the sender will=20 > retransmit and the receiver will maintain proper order. >=20 > This is the function of TCP. >=20 > Haag, T wrote: > > Hi Wojciech, > >=20 > > =20 > >=20 > > Assuming that GSMP und layer above don't care about Does=20 > ANCP provide=20 > > a kind of handshake mechanism to enforce the near end sending only=20 > > port specific messages again if the application layer at=20 > the far end=20 > > receives inconclusive messages? > >=20 > > =20 > >=20 > > Regards > >=20 > > Thomas > >=20 > >=20 > ---------------------------------------------------------------------- > > -- > >=20 > > *Von:* Wojciech Dec (wdec) [mailto:wdec@cisco.com] > > *Gesendet:* Donnerstag, 15. November 2007 15:50 > > *An:* Busser, Michael; ancp@ietf.org > > *Cc:* Tr=F6ster, Stephan; Haag, Thomas; Witschurke, Birgit > > *Betreff:* RE: [ANCP] Splitting GSMP messages to different=20 > TCP packets > >=20 > > =20 > >=20 > > Hi Michael, > >=20 > > =20 > >=20 > > your interpretation is correct with respect to ANCP over TCP. > >=20 > > =20 > >=20 > > -Woj. > >=20 > > =20 > >=20 > > =20 > >=20 > ---------------------------------------------------------------------- > > -- > >=20 > > *From:* Busser, M [mailto:Michael.Busser@t-systems.com] > > *Sent:* 15 November 2007 14:36 > > *To:* ancp@ietf.org > > *Cc:* Troester, Stephan; Haag,T; Witschurke,Birgit > > *Subject:* [ANCP] Splitting GSMP messages to different=20 > TCP packets > >=20 > > Hi all. > >=20 > > =20 > >=20 > > When the adjacency comes up, a bunch of PORT-STATUS=20 > messages will be > > sent > > by the DSLAM to the BRAS. > >=20 > > =20 > >=20 > > If the amount of data (all the GSMP messages) exceeds=20 > the limit of > > one TCP-Packet, > > the next portion of data have to be sent with the next=20 > TCP packets. > >=20 > > =20 > >=20 > > The question now is: > > Do we have any requirements to make sure, that only=20 > complete GSMP > > messages > > are sent in one TCP message? > >=20 > > =20 > >=20 > > From my understanding, the stream of GSMP messages is=20 > a byte stream, > > which is transported to the far end by TCP. > > The application layer (e.g. the layer above TCP) do not=20 > have to take > > care > > about such details of transportation. > > So the answer is no. > >=20 > > =20 > >=20 > > Am i wrong? > >=20 > > =20 > >=20 > >=20 > > Best Regards; Freundliche Gr=FC=DFe > >=20 > > *Michael Busser* > >=20 > > T-Systems Enterprise Services GmbH > >=20 > > Production Line Network Centric Systems > >=20 > > ICT-Systems Integration > >=20 > > Network Integration Services > >=20 > > =20 > >=20 > > Br=FCckes 2 -8, 55545 Bad Kreuznach > > Postfach 9100, 55541 Bad Kreuznach > > +49 671 8333 8911 (Phone) > > +49 521 9210 3859 (Fax) > > +49 151 1211 9689 (Mobile) > > E-Mail: michael.busser@t-systems.com > > > >=20 > > Internet: http://www.t-systems.com > >=20 > > =20 > >=20 > > =20 > >=20 > > T-Systems Enterprise Services GmbH > > Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) > > Executive Committee: Helmut Binder, Albert Henn, Olaf Heyden*, > > Katrin Horstmann, Ulrich Kemp, Wilfried Peters*, > > Dr. Herbert Schaaff*, Zvezdana Seeger* > > Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 > > Sitz der Gesellschaft: Frankfurt am Main > > WEEE-Reg.-Nr. DE87523644 > > *Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG > >=20 > > Notice: This transmittal and/or attachments may be privileged or > > confidential. If you are not the intended recipient,=20 > you are hereby > > notified that you have received this transmittal in error; any > > review, dissemination, or copying is strictly prohibited. If you > > received this transmittal in error, please notify us=20 > immediately by > > reply and immediately delete this message and all its=20 > attachments. > > Thank you. > > T-Systems - Business flexibility > >=20 > > =20 > >=20 > > =20 > >=20 > >=20 > >=20 > ---------------------------------------------------------------------- > > -- > >=20 > > _______________________________________________ > > ANCP mailing list > > ANCP@ietf.org > > https://www1.ietf.org/mailman/listinfo/ancp >=20 >=20 > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www1.ietf.org/mailman/listinfo/ancp >=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 Mon Nov 19 12:02:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuA0o-0005l0-KT; Mon, 19 Nov 2007 12:02:18 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IuA0n-0005kf-IB for ancp-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 12:02:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuA0n-0005kU-6S for ancp@ietf.org; Mon, 19 Nov 2007 12:02:17 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuA0i-0001Pt-NJ for ancp@ietf.org; Mon, 19 Nov 2007 12:02:16 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 19 Nov 2007 09:02:12 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lAJH2C4Y017428; Mon, 19 Nov 2007 09:02:12 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAJH24V9022523; Mon, 19 Nov 2007 17:02:12 GMT Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 09:02:08 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: [ANCP] Splitting GSMP messages to different TCP packets Date: Mon, 19 Nov 2007 09:02:13 -0800 Message-ID: <48214755113BB04F84D958B4F0DE261C04ADF72C@xmb-sjc-222.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [ANCP] Splitting GSMP messages to different TCP packets Thread-Index: AcgnsLX5XS3Ns04wQyiPfkAVxJpEcQAdNcIwAAK1VTAApowOEA== References: <1B6169C658325341A3B8066E23919E1C1066A6@S4DE8PSAANK.mitte.t-com.de> <1B6169C658325341A3B8066E23919E1C679938@S4DE8PSAANK.mitte.t-com.de><473C87D3.70008@redback.com><1B6169C658325341A3B8066E23919E1C679A2C@S4DE8PSAANK.mitte.t-com.de> From: "Philippe Champagne (pchamp)" To: "Wojciech Dec (wdec)" , "Haag, T" , X-OriginalArrivalTime: 19 Nov 2007 17:02:08.0172 (UTC) FILETIME=[EB23E6C0:01C82ACD] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9304; t=1195491732; x=1196355732; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pchamp@cisco.com; z=From:=20=22Philippe=20Champagne=20(pchamp)=22=20 |Subject:=20RE=3A=20AW=3A=20[ANCP]=20Splitting=20GSMP=20messages=20to=20d ifferent=20TCP=20packets |Sender:=20; bh=kCTLd+PxwyrlViZCJDFLnBLIoFHWMUQaXWObzxyJSrY=; b=SIb7c9y3Rgkn+MpsNajIDgOU6VmsVtn36GMpeu1jtPrdMAu/53erdoD3q9tclCF5CH5+sYQB JD5ZlQq43ZBa6HCieNIMHOfSR5QWL2gSxVRDuw5dxmJkpPlPK7oB1E9u; Authentication-Results: sj-dkim-4; header.From=pchamp@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 96d3a783a4707f1ab458eb15058bb2d7 Cc: "Troester, Stephan" , "Busser, M" , ancp@ietf.org, "Witschurke, Birgit" 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 Woj Yes, TCP is cheap for the DSLAM who only has to handle a few of them = overall (only one to the BRAS) while the BRAS needs to support one for = all the DSLAM connected to it, meaning 5,000 or possibly more. In our case, we lose a lot of cpu and memory to handle all the luxury of = TCP which we might not require all of it. If we moved out of TCP and build some form of reliable protocol say over = UDP, it might be possible as long as the built-in functionality of TCP = are either implemented or arrange not to be required. 1) Reliability Can be done by having sequencing/acknowledgment of any messages sent = by each 2) stream oriented Instead of stream oriented, we make it message based (no messages are = split over 2 packets at that layer (IP frag could still be there)) (although still more than one message can be encapsulated in a single = packet) 3) congestion control et al more tricky The DSLAM isn't forwarding any huge file of information to the BRAS. = My assumption (I could be wrong) is there won't be more than a few CPEs = connected to any DSLAM (up to 10, 20?). If so, the traffic between a = given DSLAM and the BRAS are made of the "keepalive" and whatever Port = up/down and other events that might occur. If the DSLAM builts a self = throttle of bulk packets, (say limiting to 5 ANCP packets per seconds). What's your input Woj? > -----Original Message----- > From: Wojciech Dec (wdec)=20 > Sent: Friday, November 16, 2007 4:18 AM > To: Haag, T; jheitz@redback.com > Cc: Troester, Stephan; Busser,M; ancp@ietf.org; Witschurke,Birgit > Subject: RE: AW: [ANCP] Splitting GSMP messages to different=20 > TCP packets >=20 > Hi Thomas, >=20 > the handshake you're looking for is a combination of ANCP=20 > version and ANCP capability exchange. The latter is currently=20 > has a few shortcomings that we'll hopefully get to address soon. >=20 > In essence, TCP (currently) guarantees reliable and ordered delivery. > If the BRAS, or DSLAM do not understand a message, then=20 > retransmitting it won't help. This is a basic protocol issue=20 > that is addressed by the two sides agreeing to use a commonly=20 > understood message set. >=20 > This actually opens up another point: We have previously=20 > discussed (and included in our charter) the possibility of=20 > using an alternative transport protocol. The WG however has=20 > however not seen much follow-up on this, especially in terms=20 > of laying out the reasons why, for example, the rate-change=20 > information needs to be transmitted reliably and/or=20 > acknowledged. This seems like a good time to have this discussion. >=20 > Regards, > Woj. >=20 >=20 > > -----Original Message----- > > From: Haag, T [mailto:Thomas.Haag@t-systems.com] > > Sent: 16 November 2007 09:05 > > To: jheitz@redback.com > > Cc: Troester, Stephan; Busser,M; ancp@ietf.org; Witschurke,Birgit > > Subject: AW: AW: [ANCP] Splitting GSMP messages to different TCP=20 > > packets > >=20 > > I think it is a misunderstanding. That TCP has such a mechanism is=20 > > quite clear. > >=20 > > But the question was if GSMP on top of TCP has a handshake=20 > mechanism? > >=20 > > There is need for a mechanism which provides a retransmission of=20 > > dedicated DSL port information, if the BRAS could not interpret a=20 > > single message. > >=20 > > Regards > > Thomas > >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Jakob Heitz [mailto:jheitz@redback.com] > > Gesendet: Donnerstag, 15. November 2007 18:54 > > An: Haag, Thomas > > Cc: Tr=F6ster, Stephan; Busser, Michael; ancp@ietf.org; Witschurke,=20 > > Birgit > > Betreff: Re: AW: [ANCP] Splitting GSMP messages to different TCP=20 > > packets > >=20 > > Yes, there is such a handshake mechanism. If received data=20 > is dropped=20 > > or corrupted or in the wrong order, the sender will=20 > retransmit and the=20 > > receiver will maintain proper order. > >=20 > > This is the function of TCP. > >=20 > > Haag, T wrote: > > > Hi Wojciech, > > >=20 > > > =20 > > >=20 > > > Assuming that GSMP und layer above don't care about Does > > ANCP provide > > > a kind of handshake mechanism to enforce the near end=20 > sending only=20 > > > port specific messages again if the application layer at > > the far end > > > receives inconclusive messages? > > >=20 > > > =20 > > >=20 > > > Regards > > >=20 > > > Thomas > > >=20 > > >=20 > >=20 > ---------------------------------------------------------------------- > > > -- > > >=20 > > > *Von:* Wojciech Dec (wdec) [mailto:wdec@cisco.com] > > > *Gesendet:* Donnerstag, 15. November 2007 15:50 > > > *An:* Busser, Michael; ancp@ietf.org > > > *Cc:* Tr=F6ster, Stephan; Haag, Thomas; Witschurke, Birgit > > > *Betreff:* RE: [ANCP] Splitting GSMP messages to different > > TCP packets > > >=20 > > > =20 > > >=20 > > > Hi Michael, > > >=20 > > > =20 > > >=20 > > > your interpretation is correct with respect to ANCP over TCP. > > >=20 > > > =20 > > >=20 > > > -Woj. > > >=20 > > > =20 > > >=20 > > > =20 > > >=20 > >=20 > ---------------------------------------------------------------------- > > > -- > > >=20 > > > *From:* Busser, M [mailto:Michael.Busser@t-systems.com] > > > *Sent:* 15 November 2007 14:36 > > > *To:* ancp@ietf.org > > > *Cc:* Troester, Stephan; Haag,T; Witschurke,Birgit > > > *Subject:* [ANCP] Splitting GSMP messages to different > > TCP packets > > >=20 > > > Hi all. > > >=20 > > > =20 > > >=20 > > > When the adjacency comes up, a bunch of PORT-STATUS > > messages will be > > > sent > > > by the DSLAM to the BRAS. > > >=20 > > > =20 > > >=20 > > > If the amount of data (all the GSMP messages) exceeds > > the limit of > > > one TCP-Packet, > > > the next portion of data have to be sent with the next > > TCP packets. > > >=20 > > > =20 > > >=20 > > > The question now is: > > > Do we have any requirements to make sure, that only > > complete GSMP > > > messages > > > are sent in one TCP message? > > >=20 > > > =20 > > >=20 > > > From my understanding, the stream of GSMP messages is > > a byte stream, > > > which is transported to the far end by TCP. > > > The application layer (e.g. the layer above TCP) do not > > have to take > > > care > > > about such details of transportation. > > > So the answer is no. > > >=20 > > > =20 > > >=20 > > > Am i wrong? > > >=20 > > > =20 > > >=20 > > >=20 > > > Best Regards; Freundliche Gr=FC=DFe > > >=20 > > > *Michael Busser* > > >=20 > > > T-Systems Enterprise Services GmbH > > >=20 > > > Production Line Network Centric Systems > > >=20 > > > ICT-Systems Integration > > >=20 > > > Network Integration Services > > >=20 > > > =20 > > >=20 > > > Br=FCckes 2 -8, 55545 Bad Kreuznach > > > Postfach 9100, 55541 Bad Kreuznach > > > +49 671 8333 8911 (Phone) > > > +49 521 9210 3859 (Fax) > > > +49 151 1211 9689 (Mobile) > > > E-Mail: michael.busser@t-systems.com > > > > > >=20 > > > Internet: http://www.t-systems.com > > >=20 > > > =20 > > >=20 > > > =20 > > >=20 > > > T-Systems Enterprise Services GmbH > > > Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) > > > Executive Committee: Helmut Binder, Albert Henn, Olaf Heyden*, > > > Katrin Horstmann, Ulrich Kemp, Wilfried Peters*, > > > Dr. Herbert Schaaff*, Zvezdana Seeger* > > > Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 > > > Sitz der Gesellschaft: Frankfurt am Main > > > WEEE-Reg.-Nr. DE87523644 > > > *Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG > > >=20 > > > Notice: This transmittal and/or attachments may be=20 > privileged or > > > confidential. If you are not the intended recipient, > > you are hereby > > > notified that you have received this transmittal in error; any > > > review, dissemination, or copying is strictly=20 > prohibited. If you > > > received this transmittal in error, please notify us > > immediately by > > > reply and immediately delete this message and all its > > attachments. > > > Thank you. > > > T-Systems - Business flexibility > > >=20 > > > =20 > > >=20 > > > =20 > > >=20 > > >=20 > > >=20 > >=20 > ---------------------------------------------------------------------- > > > -- > > >=20 > > > _______________________________________________ > > > ANCP mailing list > > > ANCP@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ancp > >=20 > >=20 > > _______________________________________________ > > ANCP mailing list > > ANCP@ietf.org > > https://www1.ietf.org/mailman/listinfo/ancp > >=20 > >=20 > > _______________________________________________ > > ANCP mailing list > > ANCP@ietf.org > > https://www1.ietf.org/mailman/listinfo/ancp > >=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 Mon Nov 19 13:37:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuBUk-00039J-9W; Mon, 19 Nov 2007 13:37:18 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IuBUi-00037U-Nq for ancp-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 13:37:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuBUi-00037M-E8 for ancp@ietf.org; Mon, 19 Nov 2007 13:37:16 -0500 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuBUe-0002NO-Gl for ancp@ietf.org; Mon, 19 Nov 2007 13:37:16 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id E92108C10EF; Mon, 19 Nov 2007 10:37:11 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28561-01; Mon, 19 Nov 2007 10:37:11 -0800 (PST) Received: from [127.0.0.1] (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 4DE3A8C10EE; Mon, 19 Nov 2007 10:37:11 -0800 (PST) Message-ID: <4741D7D8.8080604@redback.com> Date: Mon, 19 Nov 2007 10:37:12 -0800 From: Jakob Heitz User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Philippe Champagne (pchamp)" Subject: Re: AW: [ANCP] Splitting GSMP messages to different TCP packets References: <1B6169C658325341A3B8066E23919E1C1066A6@S4DE8PSAANK.mitte.t-com.de> <1B6169C658325341A3B8066E23919E1C679938@S4DE8PSAANK.mitte.t-com.de><473C87D3.70008@redback.com><1B6169C658325341A3B8066E23919E1C679A2C@S4DE8PSAANK.mitte.t-com.de> <48214755113BB04F84D958B4F0DE261C04ADF72C@xmb-sjc-222.amer.cisco.com> In-Reply-To: <48214755113BB04F84D958B4F0DE261C04ADF72C@xmb-sjc-222.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Virus-Scanned: by amavisd-new at redback.com Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606 Cc: "Troester, Stephan" , "Busser, M" , "Witschurke, Birgit" , "Haag, T" , ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ancp@ietf.org 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 Congestion control is indeed tricky. At node startup, you want to get all the Port_Up messages as quickly as possible and every port will send one. Exactly like a huge file. Node startup is the busiest and most important time. Also, it is incorrect to assume DSLAMS are small. One scenario might have 5000 DSLAMs with 10 ports each, but another might have 5 DSLAMs with 10000 ports each. The standardized solution needs to work well for all possible scenarios. Philippe Champagne (pchamp) wrote: > Hi Woj >=20 > Yes, TCP is cheap for the DSLAM who only has to handle a few of them ov= erall (only one to the BRAS) while the BRAS needs to support one for all = the DSLAM connected to it, meaning 5,000 or possibly more. > In our case, we lose a lot of cpu and memory to handle all the luxury o= f TCP which we might not require all of it. >=20 > If we moved out of TCP and build some form of reliable protocol say ove= r UDP, it might be possible as long as the built-in functionality of TCP = are either implemented or arrange not to be required. >=20 > 1) Reliability > Can be done by having sequencing/acknowledgment of any messages sent= by each >=20 > 2) stream oriented > Instead of stream oriented, we make it message based (no messages ar= e split over 2 packets at that layer (IP frag could still be there)) > (although still more than one message can be encapsulated in a singl= e packet) >=20 > 3) congestion control et al > more tricky > The DSLAM isn't forwarding any huge file of information to the BRAS.= My assumption (I could be wrong) is there won't be more than a few CPEs = connected to any DSLAM (up to 10, 20?). If so, the traffic between a give= n DSLAM and the BRAS are made of the "keepalive" and whatever Port up/dow= n and other events that might occur. If the DSLAM builts a self throttle = of bulk packets, (say limiting to 5 ANCP packets per seconds). >=20 >=20 > What's your input Woj? >=20 >=20 >> -----Original Message----- >> From: Wojciech Dec (wdec)=20 >> Sent: Friday, November 16, 2007 4:18 AM >> To: Haag, T; jheitz@redback.com >> Cc: Troester, Stephan; Busser,M; ancp@ietf.org; Witschurke,Birgit >> Subject: RE: AW: [ANCP] Splitting GSMP messages to different=20 >> TCP packets >> >> Hi Thomas, >> >> the handshake you're looking for is a combination of ANCP=20 >> version and ANCP capability exchange. The latter is currently=20 >> has a few shortcomings that we'll hopefully get to address soon. >> >> In essence, TCP (currently) guarantees reliable and ordered delivery. >> If the BRAS, or DSLAM do not understand a message, then=20 >> retransmitting it won't help. This is a basic protocol issue=20 >> that is addressed by the two sides agreeing to use a commonly=20 >> understood message set. >> >> This actually opens up another point: We have previously=20 >> discussed (and included in our charter) the possibility of=20 >> using an alternative transport protocol. The WG however has=20 >> however not seen much follow-up on this, especially in terms=20 >> of laying out the reasons why, for example, the rate-change=20 >> information needs to be transmitted reliably and/or=20 >> acknowledged. This seems like a good time to have this discussion. >> >> Regards, >> Woj. >> >> >>> -----Original Message----- >>> From: Haag, T [mailto:Thomas.Haag@t-systems.com] >>> Sent: 16 November 2007 09:05 >>> To: jheitz@redback.com >>> Cc: Troester, Stephan; Busser,M; ancp@ietf.org; Witschurke,Birgit >>> Subject: AW: AW: [ANCP] Splitting GSMP messages to different TCP=20 >>> packets >>> >>> I think it is a misunderstanding. That TCP has such a mechanism is=20 >>> quite clear. >>> >>> But the question was if GSMP on top of TCP has a handshake=20 >> mechanism? >>> There is need for a mechanism which provides a retransmission of=20 >>> dedicated DSL port information, if the BRAS could not interpret a=20 >>> single message. >>> >>> Regards >>> Thomas >>> >>> -----Urspr=FCngliche Nachricht----- >>> Von: Jakob Heitz [mailto:jheitz@redback.com] >>> Gesendet: Donnerstag, 15. November 2007 18:54 >>> An: Haag, Thomas >>> Cc: Tr=F6ster, Stephan; Busser, Michael; ancp@ietf.org; Witschurke,=20 >>> Birgit >>> Betreff: Re: AW: [ANCP] Splitting GSMP messages to different TCP=20 >>> packets >>> >>> Yes, there is such a handshake mechanism. If received data=20 >> is dropped=20 >>> or corrupted or in the wrong order, the sender will=20 >> retransmit and the=20 >>> receiver will maintain proper order. >>> >>> This is the function of TCP. >>> >>> Haag, T wrote: >>>> Hi Wojciech, >>>> >>>> =20 >>>> >>>> Assuming that GSMP und layer above don't care about Does >>> ANCP provide >>>> a kind of handshake mechanism to enforce the near end=20 >> sending only=20 >>>> port specific messages again if the application layer at >>> the far end >>>> receives inconclusive messages? >>>> >>>> =20 >>>> >>>> Regards >>>> >>>> Thomas >>>> >>>> >> ---------------------------------------------------------------------- >>>> -- >>>> >>>> *Von:* Wojciech Dec (wdec) [mailto:wdec@cisco.com] >>>> *Gesendet:* Donnerstag, 15. November 2007 15:50 >>>> *An:* Busser, Michael; ancp@ietf.org >>>> *Cc:* Tr=F6ster, Stephan; Haag, Thomas; Witschurke, Birgit >>>> *Betreff:* RE: [ANCP] Splitting GSMP messages to different >>> TCP packets >>>> =20 >>>> >>>> Hi Michael, >>>> >>>> =20 >>>> >>>> your interpretation is correct with respect to ANCP over TCP. >>>> >>>> =20 >>>> >>>> -Woj. >>>> >>>> =20 >>>> >>>> =20 >>>> >> ---------------------------------------------------------------------- >>>> -- >>>> >>>> *From:* Busser, M [mailto:Michael.Busser@t-systems.com] >>>> *Sent:* 15 November 2007 14:36 >>>> *To:* ancp@ietf.org >>>> *Cc:* Troester, Stephan; Haag,T; Witschurke,Birgit >>>> *Subject:* [ANCP] Splitting GSMP messages to different >>> TCP packets >>>> Hi all. >>>> >>>> =20 >>>> >>>> When the adjacency comes up, a bunch of PORT-STATUS >>> messages will be >>>> sent >>>> by the DSLAM to the BRAS. >>>> >>>> =20 >>>> >>>> If the amount of data (all the GSMP messages) exceeds >>> the limit of >>>> one TCP-Packet, >>>> the next portion of data have to be sent with the next >>> TCP packets. >>>> =20 >>>> >>>> The question now is: >>>> Do we have any requirements to make sure, that only >>> complete GSMP >>>> messages >>>> are sent in one TCP message? >>>> >>>> =20 >>>> >>>> From my understanding, the stream of GSMP messages is >>> a byte stream, >>>> which is transported to the far end by TCP. >>>> The application layer (e.g. the layer above TCP) do not >>> have to take >>>> care >>>> about such details of transportation. >>>> So the answer is no. >>>> >>>> =20 >>>> >>>> Am i wrong? >>>> >>>> =20 >>>> >>>> >>>> Best Regards; Freundliche Gr=FC=DFe >>>> >>>> *Michael Busser* >>>> >>>> T-Systems Enterprise Services GmbH >>>> >>>> Production Line Network Centric Systems >>>> >>>> ICT-Systems Integration >>>> >>>> Network Integration Services >>>> >>>> =20 >>>> >>>> Br=FCckes 2 -8, 55545 Bad Kreuznach >>>> Postfach 9100, 55541 Bad Kreuznach >>>> +49 671 8333 8911 (Phone) >>>> +49 521 9210 3859 (Fax) >>>> +49 151 1211 9689 (Mobile) >>>> E-Mail: michael.busser@t-systems.com >>>> >>>> >>>> Internet: http://www.t-systems.com >>>> >>>> =20 >>>> >>>> =20 >>>> >>>> T-Systems Enterprise Services GmbH >>>> Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) >>>> Executive Committee: Helmut Binder, Albert Henn, Olaf Heyden*, >>>> Katrin Horstmann, Ulrich Kemp, Wilfried Peters*, >>>> Dr. Herbert Schaaff*, Zvezdana Seeger* >>>> Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 >>>> Sitz der Gesellschaft: Frankfurt am Main >>>> WEEE-Reg.-Nr. DE87523644 >>>> *Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG >>>> >>>> Notice: This transmittal and/or attachments may be=20 >> privileged or >>>> confidential. If you are not the intended recipient, >>> you are hereby >>>> notified that you have received this transmittal in error; any >>>> review, dissemination, or copying is strictly=20 >> prohibited. If you >>>> received this transmittal in error, please notify us >>> immediately by >>>> reply and immediately delete this message and all its >>> attachments. >>>> Thank you. >>>> T-Systems - Business flexibility _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Mon Nov 19 14:32: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 1IuCLr-0002WV-2e; Mon, 19 Nov 2007 14:32:11 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IuCLp-0002W6-Fn for ancp-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 14:32:09 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuCLp-0002Vy-3m for ancp@ietf.org; Mon, 19 Nov 2007 14:32:09 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuCLn-0006RW-R4 for ancp@ietf.org; Mon, 19 Nov 2007 14:32:09 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 19 Nov 2007 11:32:07 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lAJJW6Qu007705; Mon, 19 Nov 2007 11:32:06 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id lAJJW31U009329; Mon, 19 Nov 2007 19:32:06 GMT Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 11:32:05 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: [ANCP] Splitting GSMP messages to different TCP packets Date: Mon, 19 Nov 2007 11:32:11 -0800 Message-ID: <48214755113BB04F84D958B4F0DE261C04ADF840@xmb-sjc-222.amer.cisco.com> In-Reply-To: <4741D7D8.8080604@redback.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [ANCP] Splitting GSMP messages to different TCP packets Thread-Index: Acgq20GVoJo2MkmwQgWeMhrZRAqy3wABwNNA References: <1B6169C658325341A3B8066E23919E1C1066A6@S4DE8PSAANK.mitte.t-com.de> <1B6169C658325341A3B8066E23919E1C679938@S4DE8PSAANK.mitte.t-com.de><473C87D3.70008@redback.com><1B6169C658325341A3B8066E23919E1C679A2C@S4DE8PSAANK.mitte.t-com.de> <48214755113BB04F84D958B4F0DE261C04ADF72C@xmb-sjc-222.amer.cisco.com> <4741D7D8.8080604@redback.com> From: "Philippe Champagne (pchamp)" To: X-OriginalArrivalTime: 19 Nov 2007 19:32:05.0775 (UTC) FILETIME=[DE2129F0:01C82AE2] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=10062; t=1195500727; x=1196364727; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pchamp@cisco.com; z=From:=20=22Philippe=20Champagne=20(pchamp)=22=20 |Subject:=20RE=3A=20AW=3A=20[ANCP]=20Splitting=20GSMP=20messages=20to=20d ifferent=20TCP=20packets |Sender:=20; bh=BXe9WVFGw225AS++tc+hlUdMIePqp5CMvmtLsnm5jt0=; b=U8FUYPZW2E+nACOQB1uVTET/MK+e7nMM7XFCd/ytLdhJPw7DkkNB09QZchUOj6BPUoAk+hi5 9sLtVV179JyjpJr5gPolgVPD7wKdia1qeTaTNDZJnULFk4HXonYV5NEv; Authentication-Results: sj-dkim-4; header.From=pchamp@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4515df9441674711565101d9d5c4f63f Cc: "Troester, Stephan" , "Busser, M" , "Haag, T" , "Witschurke, Birgit" 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 Thanks Jakob. Wasn't sure about that. In this case, it has the potential to become chatty over that TCP = connection. In light of this, perhaps another solution might be to use an hybrid = version (configurable by the admin - either TCP or the light weight, = depending on the network topology) > -----Original Message----- > From: Jakob Heitz [mailto:jheitz@redback.com]=20 > Sent: Monday, November 19, 2007 1:37 PM > To: Philippe Champagne (pchamp) > Cc: Wojciech Dec (wdec); Haag, T; Troester, Stephan;=20 > Busser,M; ancp@ietf.org; Witschurke,Birgit > Subject: Re: AW: [ANCP] Splitting GSMP messages to different=20 > TCP packets >=20 > Congestion control is indeed tricky. > At node startup, you want to get all the Port_Up messages as=20 > quickly as possible and every port will send one. Exactly=20 > like a huge file. > Node startup is the busiest and most important time. >=20 > Also, it is incorrect to assume DSLAMS are small. > One scenario might have 5000 DSLAMs with 10 ports each, but=20 > another might have 5 DSLAMs with 10000 ports each. The=20 > standardized solution needs to work well for all possible scenarios. >=20 > Philippe Champagne (pchamp) wrote: > > Hi Woj > >=20 > > Yes, TCP is cheap for the DSLAM who only has to handle a=20 > few of them overall (only one to the BRAS) while the BRAS=20 > needs to support one for all the DSLAM connected to it,=20 > meaning 5,000 or possibly more. > > In our case, we lose a lot of cpu and memory to handle all=20 > the luxury of TCP which we might not require all of it. > >=20 > > If we moved out of TCP and build some form of reliable=20 > protocol say over UDP, it might be possible as long as the=20 > built-in functionality of TCP are either implemented or=20 > arrange not to be required. > >=20 > > 1) Reliability > > Can be done by having sequencing/acknowledgment of any messages=20 > > sent by each > >=20 > > 2) stream oriented > > Instead of stream oriented, we make it message based (no=20 > messages are split over 2 packets at that layer (IP frag=20 > could still be there)) > > (although still more than one message can be encapsulated in a=20 > > single packet) > >=20 > > 3) congestion control et al > > more tricky > > The DSLAM isn't forwarding any huge file of information=20 > to the BRAS. My assumption (I could be wrong) is there won't=20 > be more than a few CPEs connected to any DSLAM (up to 10,=20 > 20?). If so, the traffic between a given DSLAM and the BRAS=20 > are made of the "keepalive" and whatever Port up/down and=20 > other events that might occur. If the DSLAM builts a self=20 > throttle of bulk packets, (say limiting to 5 ANCP packets per=20 > seconds). > >=20 > >=20 > > What's your input Woj? > >=20 > >=20 > >> -----Original Message----- > >> From: Wojciech Dec (wdec) > >> Sent: Friday, November 16, 2007 4:18 AM > >> To: Haag, T; jheitz@redback.com > >> Cc: Troester, Stephan; Busser,M; ancp@ietf.org; Witschurke,Birgit > >> Subject: RE: AW: [ANCP] Splitting GSMP messages to different TCP=20 > >> packets > >> > >> Hi Thomas, > >> > >> the handshake you're looking for is a combination of ANCP=20 > version and=20 > >> ANCP capability exchange. The latter is currently has a few=20 > >> shortcomings that we'll hopefully get to address soon. > >> > >> In essence, TCP (currently) guarantees reliable and=20 > ordered delivery. > >> If the BRAS, or DSLAM do not understand a message, then=20 > >> retransmitting it won't help. This is a basic protocol=20 > issue that is=20 > >> addressed by the two sides agreeing to use a commonly understood=20 > >> message set. > >> > >> This actually opens up another point: We have previously discussed=20 > >> (and included in our charter) the possibility of using an=20 > alternative=20 > >> transport protocol. The WG however has however not seen much=20 > >> follow-up on this, especially in terms of laying out the=20 > reasons why,=20 > >> for example, the rate-change information needs to be transmitted=20 > >> reliably and/or acknowledged. This seems like a good time to have=20 > >> this discussion. > >> > >> Regards, > >> Woj. > >> > >> > >>> -----Original Message----- > >>> From: Haag, T [mailto:Thomas.Haag@t-systems.com] > >>> Sent: 16 November 2007 09:05 > >>> To: jheitz@redback.com > >>> Cc: Troester, Stephan; Busser,M; ancp@ietf.org; Witschurke,Birgit > >>> Subject: AW: AW: [ANCP] Splitting GSMP messages to different TCP=20 > >>> packets > >>> > >>> I think it is a misunderstanding. That TCP has such a=20 > mechanism is=20 > >>> quite clear. > >>> > >>> But the question was if GSMP on top of TCP has a handshake > >> mechanism? > >>> There is need for a mechanism which provides a retransmission of=20 > >>> dedicated DSL port information, if the BRAS could not interpret a=20 > >>> single message. > >>> > >>> Regards > >>> Thomas > >>> > >>> -----Urspr=FCngliche Nachricht----- > >>> Von: Jakob Heitz [mailto:jheitz@redback.com] > >>> Gesendet: Donnerstag, 15. November 2007 18:54 > >>> An: Haag, Thomas > >>> Cc: Tr=F6ster, Stephan; Busser, Michael; ancp@ietf.org; = Witschurke,=20 > >>> Birgit > >>> Betreff: Re: AW: [ANCP] Splitting GSMP messages to different TCP=20 > >>> packets > >>> > >>> Yes, there is such a handshake mechanism. If received data > >> is dropped > >>> or corrupted or in the wrong order, the sender will > >> retransmit and the > >>> receiver will maintain proper order. > >>> > >>> This is the function of TCP. > >>> > >>> Haag, T wrote: > >>>> Hi Wojciech, > >>>> > >>>> =20 > >>>> > >>>> Assuming that GSMP und layer above don't care about Does > >>> ANCP provide > >>>> a kind of handshake mechanism to enforce the near end > >> sending only > >>>> port specific messages again if the application layer at > >>> the far end > >>>> receives inconclusive messages? > >>>> > >>>> =20 > >>>> > >>>> Regards > >>>> > >>>> Thomas > >>>> > >>>> > >>=20 > --------------------------------------------------------------------- > >> - > >>>> -- > >>>> > >>>> *Von:* Wojciech Dec (wdec) [mailto:wdec@cisco.com] > >>>> *Gesendet:* Donnerstag, 15. November 2007 15:50 > >>>> *An:* Busser, Michael; ancp@ietf.org > >>>> *Cc:* Tr=F6ster, Stephan; Haag, Thomas; Witschurke, Birgit > >>>> *Betreff:* RE: [ANCP] Splitting GSMP messages to different > >>> TCP packets > >>>> =20 > >>>> > >>>> Hi Michael, > >>>> > >>>> =20 > >>>> > >>>> your interpretation is correct with respect to ANCP over TCP. > >>>> > >>>> =20 > >>>> > >>>> -Woj. > >>>> > >>>> =20 > >>>> > >>>> =20 > >>>> > >>=20 > --------------------------------------------------------------------- > >> - > >>>> -- > >>>> > >>>> *From:* Busser, M [mailto:Michael.Busser@t-systems.com] > >>>> *Sent:* 15 November 2007 14:36 > >>>> *To:* ancp@ietf.org > >>>> *Cc:* Troester, Stephan; Haag,T; Witschurke,Birgit > >>>> *Subject:* [ANCP] Splitting GSMP messages to different > >>> TCP packets > >>>> Hi all. > >>>> > >>>> =20 > >>>> > >>>> When the adjacency comes up, a bunch of PORT-STATUS > >>> messages will be > >>>> sent > >>>> by the DSLAM to the BRAS. > >>>> > >>>> =20 > >>>> > >>>> If the amount of data (all the GSMP messages) exceeds > >>> the limit of > >>>> one TCP-Packet, > >>>> the next portion of data have to be sent with the next > >>> TCP packets. > >>>> =20 > >>>> > >>>> The question now is: > >>>> Do we have any requirements to make sure, that only > >>> complete GSMP > >>>> messages > >>>> are sent in one TCP message? > >>>> > >>>> =20 > >>>> > >>>> From my understanding, the stream of GSMP messages is > >>> a byte stream, > >>>> which is transported to the far end by TCP. > >>>> The application layer (e.g. the layer above TCP) do not > >>> have to take > >>>> care > >>>> about such details of transportation. > >>>> So the answer is no. > >>>> > >>>> =20 > >>>> > >>>> Am i wrong? > >>>> > >>>> =20 > >>>> > >>>> > >>>> Best Regards; Freundliche Gr=FC=DFe > >>>> > >>>> *Michael Busser* > >>>> > >>>> T-Systems Enterprise Services GmbH > >>>> > >>>> Production Line Network Centric Systems > >>>> > >>>> ICT-Systems Integration > >>>> > >>>> Network Integration Services > >>>> > >>>> =20 > >>>> > >>>> Br=FCckes 2 -8, 55545 Bad Kreuznach > >>>> Postfach 9100, 55541 Bad Kreuznach > >>>> +49 671 8333 8911 (Phone) > >>>> +49 521 9210 3859 (Fax) > >>>> +49 151 1211 9689 (Mobile) > >>>> E-Mail: michael.busser@t-systems.com > >>>> > >>>> > >>>> Internet: http://www.t-systems.com=20 > > >>>> > >>>> =20 > >>>> > >>>> =20 > >>>> > >>>> T-Systems Enterprise Services GmbH > >>>> Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) > >>>> Executive Committee: Helmut Binder, Albert Henn,=20 > Olaf Heyden*, > >>>> Katrin Horstmann, Ulrich Kemp, Wilfried Peters*, > >>>> Dr. Herbert Schaaff*, Zvezdana Seeger* > >>>> Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 > >>>> Sitz der Gesellschaft: Frankfurt am Main > >>>> WEEE-Reg.-Nr. DE87523644 > >>>> *Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG > >>>> > >>>> Notice: This transmittal and/or attachments may be > >> privileged or > >>>> confidential. If you are not the intended recipient, > >>> you are hereby > >>>> notified that you have received this transmittal in=20 > error; any > >>>> review, dissemination, or copying is strictly > >> prohibited. If you > >>>> received this transmittal in error, please notify us > >>> immediately by > >>>> reply and immediately delete this message and all its > >>> attachments. > >>>> Thank you. > >>>> T-Systems - Business flexibility >=20 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Mon Nov 19 14:45:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuCYa-0002Ck-Oh; Mon, 19 Nov 2007 14:45:20 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IuCYa-0002Cb-5D for ancp-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 14:45:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuCYZ-0002CS-Rl for ancp@ietf.org; Mon, 19 Nov 2007 14:45:19 -0500 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuCYW-0008Uo-JD for ancp@ietf.org; Mon, 19 Nov 2007 14:45:19 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id DFED2266F98; Mon, 19 Nov 2007 11:45:15 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09235-08; Mon, 19 Nov 2007 11:45:15 -0800 (PST) Received: from [127.0.0.1] (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 79EFC266F91; Mon, 19 Nov 2007 11:45:15 -0800 (PST) Message-ID: <4741E7CC.2020609@redback.com> Date: Mon, 19 Nov 2007 11:45:16 -0800 From: Jakob Heitz User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Philippe Champagne (pchamp)" Subject: Re: AW: [ANCP] Splitting GSMP messages to different TCP packets References: <1B6169C658325341A3B8066E23919E1C1066A6@S4DE8PSAANK.mitte.t-com.de> <1B6169C658325341A3B8066E23919E1C679938@S4DE8PSAANK.mitte.t-com.de><473C87D3.70008@redback.com><1B6169C658325341A3B8066E23919E1C679A2C@S4DE8PSAANK.mitte.t-com.de> <48214755113BB04F84D958B4F0DE261C04ADF72C@xmb-sjc-222.amer.cisco.com> <4741D7D8.8080604@redback.com> <48214755113BB04F84D958B4F0DE261C04ADF840@xmb-sjc-222.amer.cisco.com> In-Reply-To: <48214755113BB04F84D958B4F0DE261C04ADF840@xmb-sjc-222.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Virus-Scanned: by amavisd-new at redback.com Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: e16ce0269ccb2f59707d16700199d13b Cc: "Troester, Stephan" , "Haag, T" , "Busser, M" , ancp@ietf.org, "Witschurke, Birgit" X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ancp@ietf.org 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 Just one request: If you add TCP-like functionality, such as 1. congestion control 2. in-order delivery 3. checksum 4. duplicate packet detection 5. retransmission of errored or lost packets, please make sure to add this in a separate layer. Do not run this layer when using TCP. If you run a congestion control algorithm in a time scale of the same order of magnitude as the one in TCP, together with TCP, they will interfere with each other. Multiple retransmission algorithms also interfere with each other. Philippe Champagne (pchamp) wrote: > Thanks Jakob. Wasn't sure about that. > In this case, it has the potential to become chatty over that TCP conne= ction. > In light of this, perhaps another solution might be to use an hybrid ve= rsion (configurable by the admin - either TCP or the light weight, depend= ing on the network topology) >=20 >=20 >=20 >> -----Original Message----- >> From: Jakob Heitz [mailto:jheitz@redback.com]=20 >> Sent: Monday, November 19, 2007 1:37 PM >> To: Philippe Champagne (pchamp) >> Cc: Wojciech Dec (wdec); Haag, T; Troester, Stephan;=20 >> Busser,M; ancp@ietf.org; Witschurke,Birgit >> Subject: Re: AW: [ANCP] Splitting GSMP messages to different=20 >> TCP packets >> >> Congestion control is indeed tricky. >> At node startup, you want to get all the Port_Up messages as=20 >> quickly as possible and every port will send one. Exactly=20 >> like a huge file. >> Node startup is the busiest and most important time. >> >> Also, it is incorrect to assume DSLAMS are small. >> One scenario might have 5000 DSLAMs with 10 ports each, but=20 >> another might have 5 DSLAMs with 10000 ports each. The=20 >> standardized solution needs to work well for all possible scenarios. >> >> Philippe Champagne (pchamp) wrote: >>> Hi Woj >>> >>> Yes, TCP is cheap for the DSLAM who only has to handle a=20 >> few of them overall (only one to the BRAS) while the BRAS=20 >> needs to support one for all the DSLAM connected to it,=20 >> meaning 5,000 or possibly more. >>> In our case, we lose a lot of cpu and memory to handle all=20 >> the luxury of TCP which we might not require all of it. >>> If we moved out of TCP and build some form of reliable=20 >> protocol say over UDP, it might be possible as long as the=20 >> built-in functionality of TCP are either implemented or=20 >> arrange not to be required. >>> 1) Reliability >>> Can be done by having sequencing/acknowledgment of any messages=20 >>> sent by each >>> >>> 2) stream oriented >>> Instead of stream oriented, we make it message based (no=20 >> messages are split over 2 packets at that layer (IP frag=20 >> could still be there)) >>> (although still more than one message can be encapsulated in a=20 >>> single packet) >>> >>> 3) congestion control et al >>> more tricky >>> The DSLAM isn't forwarding any huge file of information=20 >> to the BRAS. My assumption (I could be wrong) is there won't=20 >> be more than a few CPEs connected to any DSLAM (up to 10,=20 >> 20?). If so, the traffic between a given DSLAM and the BRAS=20 >> are made of the "keepalive" and whatever Port up/down and=20 >> other events that might occur. If the DSLAM builts a self=20 >> throttle of bulk packets, (say limiting to 5 ANCP packets per=20 >> seconds). >>> >>> What's your input Woj? >>> >>> >>>> -----Original Message----- >>>> From: Wojciech Dec (wdec) >>>> Sent: Friday, November 16, 2007 4:18 AM >>>> To: Haag, T; jheitz@redback.com >>>> Cc: Troester, Stephan; Busser,M; ancp@ietf.org; Witschurke,Birgit >>>> Subject: RE: AW: [ANCP] Splitting GSMP messages to different TCP=20 >>>> packets >>>> >>>> Hi Thomas, >>>> >>>> the handshake you're looking for is a combination of ANCP=20 >> version and=20 >>>> ANCP capability exchange. The latter is currently has a few=20 >>>> shortcomings that we'll hopefully get to address soon. >>>> >>>> In essence, TCP (currently) guarantees reliable and=20 >> ordered delivery. >>>> If the BRAS, or DSLAM do not understand a message, then=20 >>>> retransmitting it won't help. This is a basic protocol=20 >> issue that is=20 >>>> addressed by the two sides agreeing to use a commonly understood=20 >>>> message set. >>>> >>>> This actually opens up another point: We have previously discussed=20 >>>> (and included in our charter) the possibility of using an=20 >> alternative=20 >>>> transport protocol. The WG however has however not seen much=20 >>>> follow-up on this, especially in terms of laying out the=20 >> reasons why,=20 >>>> for example, the rate-change information needs to be transmitted=20 >>>> reliably and/or acknowledged. This seems like a good time to have=20 >>>> this discussion. >>>> >>>> Regards, >>>> Woj. >>>> >>>> >>>>> -----Original Message----- >>>>> From: Haag, T [mailto:Thomas.Haag@t-systems.com] >>>>> Sent: 16 November 2007 09:05 >>>>> To: jheitz@redback.com >>>>> Cc: Troester, Stephan; Busser,M; ancp@ietf.org; Witschurke,Birgit >>>>> Subject: AW: AW: [ANCP] Splitting GSMP messages to different TCP=20 >>>>> packets >>>>> >>>>> I think it is a misunderstanding. That TCP has such a=20 >> mechanism is=20 >>>>> quite clear. >>>>> >>>>> But the question was if GSMP on top of TCP has a handshake >>>> mechanism? >>>>> There is need for a mechanism which provides a retransmission of=20 >>>>> dedicated DSL port information, if the BRAS could not interpret a=20 >>>>> single message. >>>>> >>>>> Regards >>>>> Thomas >>>>> >>>>> -----Urspr=FCngliche Nachricht----- >>>>> Von: Jakob Heitz [mailto:jheitz@redback.com] >>>>> Gesendet: Donnerstag, 15. November 2007 18:54 >>>>> An: Haag, Thomas >>>>> Cc: Tr=F6ster, Stephan; Busser, Michael; ancp@ietf.org; Witschurke,= =20 >>>>> Birgit >>>>> Betreff: Re: AW: [ANCP] Splitting GSMP messages to different TCP=20 >>>>> packets >>>>> >>>>> Yes, there is such a handshake mechanism. If received data >>>> is dropped >>>>> or corrupted or in the wrong order, the sender will >>>> retransmit and the >>>>> receiver will maintain proper order. >>>>> >>>>> This is the function of TCP. >>>>> >>>>> Haag, T wrote: >>>>>> Hi Wojciech, >>>>>> >>>>>> =20 >>>>>> >>>>>> Assuming that GSMP und layer above don't care about Does >>>>> ANCP provide >>>>>> a kind of handshake mechanism to enforce the near end >>>> sending only >>>>>> port specific messages again if the application layer at >>>>> the far end >>>>>> receives inconclusive messages? >>>>>> >>>>>> =20 >>>>>> >>>>>> Regards >>>>>> >>>>>> Thomas >>>>>> >>>>>> >> --------------------------------------------------------------------- >>>> - >>>>>> -- >>>>>> >>>>>> *Von:* Wojciech Dec (wdec) [mailto:wdec@cisco.com] >>>>>> *Gesendet:* Donnerstag, 15. November 2007 15:50 >>>>>> *An:* Busser, Michael; ancp@ietf.org >>>>>> *Cc:* Tr=F6ster, Stephan; Haag, Thomas; Witschurke, Birgit >>>>>> *Betreff:* RE: [ANCP] Splitting GSMP messages to different >>>>> TCP packets >>>>>> =20 >>>>>> >>>>>> Hi Michael, >>>>>> >>>>>> =20 >>>>>> >>>>>> your interpretation is correct with respect to ANCP over TCP. >>>>>> >>>>>> =20 >>>>>> >>>>>> -Woj. >>>>>> >>>>>> =20 >>>>>> >>>>>> =20 >>>>>> >> --------------------------------------------------------------------- >>>> - >>>>>> -- >>>>>> >>>>>> *From:* Busser, M [mailto:Michael.Busser@t-systems.com] >>>>>> *Sent:* 15 November 2007 14:36 >>>>>> *To:* ancp@ietf.org >>>>>> *Cc:* Troester, Stephan; Haag,T; Witschurke,Birgit >>>>>> *Subject:* [ANCP] Splitting GSMP messages to different >>>>> TCP packets >>>>>> Hi all. >>>>>> >>>>>> =20 >>>>>> >>>>>> When the adjacency comes up, a bunch of PORT-STATUS >>>>> messages will be >>>>>> sent >>>>>> by the DSLAM to the BRAS. >>>>>> >>>>>> =20 >>>>>> >>>>>> If the amount of data (all the GSMP messages) exceeds >>>>> the limit of >>>>>> one TCP-Packet, >>>>>> the next portion of data have to be sent with the next >>>>> TCP packets. >>>>>> =20 >>>>>> >>>>>> The question now is: >>>>>> Do we have any requirements to make sure, that only >>>>> complete GSMP >>>>>> messages >>>>>> are sent in one TCP message? >>>>>> >>>>>> =20 >>>>>> >>>>>> From my understanding, the stream of GSMP messages is >>>>> a byte stream, >>>>>> which is transported to the far end by TCP. >>>>>> The application layer (e.g. the layer above TCP) do not >>>>> have to take >>>>>> care >>>>>> about such details of transportation. >>>>>> So the answer is no. >>>>>> >>>>>> =20 >>>>>> >>>>>> Am i wrong? >>>>>> >>>>>> =20 >>>>>> >>>>>> >>>>>> Best Regards; Freundliche Gr=FC=DFe >>>>>> >>>>>> *Michael Busser* >>>>>> >>>>>> T-Systems Enterprise Services GmbH >>>>>> >>>>>> Production Line Network Centric Systems >>>>>> >>>>>> ICT-Systems Integration >>>>>> >>>>>> Network Integration Services >>>>>> >>>>>> =20 >>>>>> >>>>>> Br=FCckes 2 -8, 55545 Bad Kreuznach >>>>>> Postfach 9100, 55541 Bad Kreuznach >>>>>> +49 671 8333 8911 (Phone) >>>>>> +49 521 9210 3859 (Fax) >>>>>> +49 151 1211 9689 (Mobile) >>>>>> E-Mail: michael.busser@t-systems.com >>>>>> >>>>>> >>>>>> Internet: http://www.t-systems.com=20 >> >>>>>> =20 >>>>>> >>>>>> =20 >>>>>> >>>>>> T-Systems Enterprise Services GmbH >>>>>> Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) >>>>>> Executive Committee: Helmut Binder, Albert Henn,=20 >> Olaf Heyden*, >>>>>> Katrin Horstmann, Ulrich Kemp, Wilfried Peters*, >>>>>> Dr. Herbert Schaaff*, Zvezdana Seeger* >>>>>> Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 >>>>>> Sitz der Gesellschaft: Frankfurt am Main >>>>>> WEEE-Reg.-Nr. DE87523644 >>>>>> *Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG >>>>>> >>>>>> Notice: This transmittal and/or attachments may be >>>> privileged or >>>>>> confidential. If you are not the intended recipient, >>>>> you are hereby >>>>>> notified that you have received this transmittal in=20 >> error; any >>>>>> review, dissemination, or copying is strictly >>>> prohibited. If you >>>>>> received this transmittal in error, please notify us >>>>> immediately by >>>>>> reply and immediately delete this message and all its >>>>> attachments. >>>>>> Thank you. >>>>>> T-Systems - Business flexibility _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Mon Nov 19 14:54:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuChL-0008TE-EQ; Mon, 19 Nov 2007 14:54:23 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IuChI-0008QY-UE for ancp-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 14:54:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuChI-0008QQ-KV for ancp@ietf.org; Mon, 19 Nov 2007 14:54:20 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuChE-0000RF-Ai for ancp@ietf.org; Mon, 19 Nov 2007 14:54:20 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 19 Nov 2007 11:54:15 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lAJJsF2I018847; Mon, 19 Nov 2007 11:54:15 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lAJJs64K014253; Mon, 19 Nov 2007 19:54:15 GMT Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 11:54:08 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: [ANCP] Splitting GSMP messages to different TCP packets Date: Mon, 19 Nov 2007 11:54:15 -0800 Message-ID: <48214755113BB04F84D958B4F0DE261C04ADF886@xmb-sjc-222.amer.cisco.com> In-Reply-To: <4741E7CC.2020609@redback.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [ANCP] Splitting GSMP messages to different TCP packets Thread-Index: Acgq5LZHYvmpRYQpQNaXQw6c6lprEgAAQ0FQ References: <1B6169C658325341A3B8066E23919E1C1066A6@S4DE8PSAANK.mitte.t-com.de> <1B6169C658325341A3B8066E23919E1C679938@S4DE8PSAANK.mitte.t-com.de><473C87D3.70008@redback.com><1B6169C658325341A3B8066E23919E1C679A2C@S4DE8PSAANK.mitte.t-com.de> <48214755113BB04F84D958B4F0DE261C04ADF72C@xmb-sjc-222.amer.cisco.com> <4741D7D8.8080604@redback.com> <48214755113BB04F84D958B4F0DE261C04ADF840@xmb-sjc-222.amer.cisco.com> <4741E7CC.2020609@redback.com> From: "Philippe Champagne (pchamp)" To: X-OriginalArrivalTime: 19 Nov 2007 19:54:08.0734 (UTC) FILETIME=[F2ACAFE0:01C82AE5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=11797; t=1195502055; x=1196366055; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pchamp@cisco.com; z=From:=20=22Philippe=20Champagne=20(pchamp)=22=20 |Subject:=20RE=3A=20AW=3A=20[ANCP]=20Splitting=20GSMP=20messages=20to=20d ifferent=20TCP=20packets |Sender:=20; bh=ufBt9nGrbIg3Y0qSbHRO/mZu6jZki51hbdGyCXyShC8=; b=eoZWwi2W+tFE5Mn0bYNsEJxq+XijPW84Xnyv3AnkEtLKsfmx8Fx3e5trh3CjCwE3LsKCxthp rsYXQGoPbPDyNaEWx1tA82uvVbkpc60nzDW+jANmFXd7z4XiaayTkU2g; Authentication-Results: sj-dkim-3; header.From=pchamp@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 79bb66f827e54e9d5c5c7f1f9d645608 Cc: "Troester, Stephan" , "Haag, T" , "Busser, M" , "Witschurke, Birgit" 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 Sorry, perhaps my use of the term "hybrid" was wrong. What I meant is either one or the other but certainly not overlapping = each other, (having them both together). > -----Original Message----- > From: Jakob Heitz [mailto:jheitz@redback.com]=20 > Sent: Monday, November 19, 2007 2:45 PM > To: Philippe Champagne (pchamp) > Cc: ancp@ietf.org; Troester, Stephan; Busser, M; Haag, T;=20 > Witschurke, Birgit > Subject: Re: AW: [ANCP] Splitting GSMP messages to different=20 > TCP packets >=20 > Just one request: > If you add TCP-like functionality, such as 1. congestion=20 > control 2. in-order delivery 3. checksum 4. duplicate packet=20 > detection 5. retransmission of errored or lost packets,=20 > please make sure to add this in a separate layer. > Do not run this layer when using TCP. >=20 > If you run a congestion control algorithm in a time scale of=20 > the same order of magnitude as the one in TCP, together with=20 > TCP, they will interfere with each other. >=20 > Multiple retransmission algorithms also interfere with each other. >=20 > Philippe Champagne (pchamp) wrote: > > Thanks Jakob. Wasn't sure about that. > > In this case, it has the potential to become chatty over=20 > that TCP connection. > > In light of this, perhaps another solution might be to use=20 > an hybrid=20 > > version (configurable by the admin - either TCP or the=20 > light weight,=20 > > depending on the network topology) > >=20 > >=20 > >=20 > >> -----Original Message----- > >> From: Jakob Heitz [mailto:jheitz@redback.com] > >> Sent: Monday, November 19, 2007 1:37 PM > >> To: Philippe Champagne (pchamp) > >> Cc: Wojciech Dec (wdec); Haag, T; Troester, Stephan; Busser,M;=20 > >> ancp@ietf.org; Witschurke,Birgit > >> Subject: Re: AW: [ANCP] Splitting GSMP messages to different TCP=20 > >> packets > >> > >> Congestion control is indeed tricky. > >> At node startup, you want to get all the Port_Up messages=20 > as quickly=20 > >> as possible and every port will send one. Exactly like a huge file. > >> Node startup is the busiest and most important time. > >> > >> Also, it is incorrect to assume DSLAMS are small. > >> One scenario might have 5000 DSLAMs with 10 ports each,=20 > but another=20 > >> might have 5 DSLAMs with 10000 ports each. The=20 > standardized solution=20 > >> needs to work well for all possible scenarios. > >> > >> Philippe Champagne (pchamp) wrote: > >>> Hi Woj > >>> > >>> Yes, TCP is cheap for the DSLAM who only has to handle a > >> few of them overall (only one to the BRAS) while the BRAS needs to=20 > >> support one for all the DSLAM connected to it, meaning 5,000 or=20 > >> possibly more. > >>> In our case, we lose a lot of cpu and memory to handle all > >> the luxury of TCP which we might not require all of it. > >>> If we moved out of TCP and build some form of reliable > >> protocol say over UDP, it might be possible as long as the=20 > built-in=20 > >> functionality of TCP are either implemented or arrange not to be=20 > >> required. > >>> 1) Reliability > >>> Can be done by having sequencing/acknowledgment of any=20 > messages=20 > >>> sent by each > >>> > >>> 2) stream oriented > >>> Instead of stream oriented, we make it message based (no > >> messages are split over 2 packets at that layer (IP frag=20 > could still=20 > >> be there)) > >>> (although still more than one message can be encapsulated in a=20 > >>> single packet) > >>> > >>> 3) congestion control et al > >>> more tricky > >>> The DSLAM isn't forwarding any huge file of information > >> to the BRAS. My assumption (I could be wrong) is there=20 > won't be more=20 > >> than a few CPEs connected to any DSLAM (up to 10, 20?). If so, the=20 > >> traffic between a given DSLAM and the BRAS are made of the=20 > >> "keepalive" and whatever Port up/down and other events that might=20 > >> occur. If the DSLAM builts a self throttle of bulk packets, (say=20 > >> limiting to 5 ANCP packets per seconds). > >>> > >>> What's your input Woj? > >>> > >>> > >>>> -----Original Message----- > >>>> From: Wojciech Dec (wdec) > >>>> Sent: Friday, November 16, 2007 4:18 AM > >>>> To: Haag, T; jheitz@redback.com > >>>> Cc: Troester, Stephan; Busser,M; ancp@ietf.org; Witschurke,Birgit > >>>> Subject: RE: AW: [ANCP] Splitting GSMP messages to different TCP=20 > >>>> packets > >>>> > >>>> Hi Thomas, > >>>> > >>>> the handshake you're looking for is a combination of ANCP > >> version and > >>>> ANCP capability exchange. The latter is currently has a few=20 > >>>> shortcomings that we'll hopefully get to address soon. > >>>> > >>>> In essence, TCP (currently) guarantees reliable and > >> ordered delivery. > >>>> If the BRAS, or DSLAM do not understand a message, then=20 > >>>> retransmitting it won't help. This is a basic protocol > >> issue that is > >>>> addressed by the two sides agreeing to use a commonly understood=20 > >>>> message set. > >>>> > >>>> This actually opens up another point: We have previously=20 > discussed=20 > >>>> (and included in our charter) the possibility of using an > >> alternative > >>>> transport protocol. The WG however has however not seen much=20 > >>>> follow-up on this, especially in terms of laying out the > >> reasons why, > >>>> for example, the rate-change information needs to be transmitted=20 > >>>> reliably and/or acknowledged. This seems like a good=20 > time to have=20 > >>>> this discussion. > >>>> > >>>> Regards, > >>>> Woj. > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Haag, T [mailto:Thomas.Haag@t-systems.com] > >>>>> Sent: 16 November 2007 09:05 > >>>>> To: jheitz@redback.com > >>>>> Cc: Troester, Stephan; Busser,M; ancp@ietf.org;=20 > Witschurke,Birgit > >>>>> Subject: AW: AW: [ANCP] Splitting GSMP messages to=20 > different TCP=20 > >>>>> packets > >>>>> > >>>>> I think it is a misunderstanding. That TCP has such a > >> mechanism is > >>>>> quite clear. > >>>>> > >>>>> But the question was if GSMP on top of TCP has a handshake > >>>> mechanism? > >>>>> There is need for a mechanism which provides a=20 > retransmission of=20 > >>>>> dedicated DSL port information, if the BRAS could not=20 > interpret a=20 > >>>>> single message. > >>>>> > >>>>> Regards > >>>>> Thomas > >>>>> > >>>>> -----Urspr=FCngliche Nachricht----- > >>>>> Von: Jakob Heitz [mailto:jheitz@redback.com] > >>>>> Gesendet: Donnerstag, 15. November 2007 18:54 > >>>>> An: Haag, Thomas > >>>>> Cc: Tr=F6ster, Stephan; Busser, Michael; ancp@ietf.org;=20 > Witschurke,=20 > >>>>> Birgit > >>>>> Betreff: Re: AW: [ANCP] Splitting GSMP messages to=20 > different TCP=20 > >>>>> packets > >>>>> > >>>>> Yes, there is such a handshake mechanism. If received data > >>>> is dropped > >>>>> or corrupted or in the wrong order, the sender will > >>>> retransmit and the > >>>>> receiver will maintain proper order. > >>>>> > >>>>> This is the function of TCP. > >>>>> > >>>>> Haag, T wrote: > >>>>>> Hi Wojciech, > >>>>>> > >>>>>> =20 > >>>>>> > >>>>>> Assuming that GSMP und layer above don't care about Does > >>>>> ANCP provide > >>>>>> a kind of handshake mechanism to enforce the near end > >>>> sending only > >>>>>> port specific messages again if the application layer at > >>>>> the far end > >>>>>> receives inconclusive messages? > >>>>>> > >>>>>> =20 > >>>>>> > >>>>>> Regards > >>>>>> > >>>>>> Thomas > >>>>>> > >>>>>> > >>=20 > --------------------------------------------------------------------- > >>>> - > >>>>>> -- > >>>>>> > >>>>>> *Von:* Wojciech Dec (wdec) [mailto:wdec@cisco.com] > >>>>>> *Gesendet:* Donnerstag, 15. November 2007 15:50 > >>>>>> *An:* Busser, Michael; ancp@ietf.org > >>>>>> *Cc:* Tr=F6ster, Stephan; Haag, Thomas; Witschurke, Birgit > >>>>>> *Betreff:* RE: [ANCP] Splitting GSMP messages to different > >>>>> TCP packets > >>>>>> =20 > >>>>>> > >>>>>> Hi Michael, > >>>>>> > >>>>>> =20 > >>>>>> > >>>>>> your interpretation is correct with respect to ANCP over TCP. > >>>>>> > >>>>>> =20 > >>>>>> > >>>>>> -Woj. > >>>>>> > >>>>>> =20 > >>>>>> > >>>>>> =20 > >>>>>> > >>=20 > --------------------------------------------------------------------- > >>>> - > >>>>>> -- > >>>>>> > >>>>>> *From:* Busser, M [mailto:Michael.Busser@t-systems.com] > >>>>>> *Sent:* 15 November 2007 14:36 > >>>>>> *To:* ancp@ietf.org > >>>>>> *Cc:* Troester, Stephan; Haag,T; Witschurke,Birgit > >>>>>> *Subject:* [ANCP] Splitting GSMP messages to different > >>>>> TCP packets > >>>>>> Hi all. > >>>>>> > >>>>>> =20 > >>>>>> > >>>>>> When the adjacency comes up, a bunch of PORT-STATUS > >>>>> messages will be > >>>>>> sent > >>>>>> by the DSLAM to the BRAS. > >>>>>> > >>>>>> =20 > >>>>>> > >>>>>> If the amount of data (all the GSMP messages) exceeds > >>>>> the limit of > >>>>>> one TCP-Packet, > >>>>>> the next portion of data have to be sent with the next > >>>>> TCP packets. > >>>>>> =20 > >>>>>> > >>>>>> The question now is: > >>>>>> Do we have any requirements to make sure, that only > >>>>> complete GSMP > >>>>>> messages > >>>>>> are sent in one TCP message? > >>>>>> > >>>>>> =20 > >>>>>> > >>>>>> From my understanding, the stream of GSMP messages is > >>>>> a byte stream, > >>>>>> which is transported to the far end by TCP. > >>>>>> The application layer (e.g. the layer above TCP) do not > >>>>> have to take > >>>>>> care > >>>>>> about such details of transportation. > >>>>>> So the answer is no. > >>>>>> > >>>>>> =20 > >>>>>> > >>>>>> Am i wrong? > >>>>>> > >>>>>> =20 > >>>>>> > >>>>>> > >>>>>> Best Regards; Freundliche Gr=FC=DFe > >>>>>> > >>>>>> *Michael Busser* > >>>>>> > >>>>>> T-Systems Enterprise Services GmbH > >>>>>> > >>>>>> Production Line Network Centric Systems > >>>>>> > >>>>>> ICT-Systems Integration > >>>>>> > >>>>>> Network Integration Services > >>>>>> > >>>>>> =20 > >>>>>> > >>>>>> Br=FCckes 2 -8, 55545 Bad Kreuznach > >>>>>> Postfach 9100, 55541 Bad Kreuznach > >>>>>> +49 671 8333 8911 (Phone) > >>>>>> +49 521 9210 3859 (Fax) > >>>>>> +49 151 1211 9689 (Mobile) > >>>>>> E-Mail: michael.busser@t-systems.com > >>>>>> > >>>>>> > >>>>>> Internet: http://www.t-systems.com > >> > >>>>>> =20 > >>>>>> > >>>>>> =20 > >>>>>> > >>>>>> T-Systems Enterprise Services GmbH > >>>>>> Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) > >>>>>> Executive Committee: Helmut Binder, Albert Henn, > >> Olaf Heyden*, > >>>>>> Katrin Horstmann, Ulrich Kemp, Wilfried Peters*, > >>>>>> Dr. Herbert Schaaff*, Zvezdana Seeger* > >>>>>> Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 > >>>>>> Sitz der Gesellschaft: Frankfurt am Main > >>>>>> WEEE-Reg.-Nr. DE87523644 > >>>>>> *Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG > >>>>>> > >>>>>> Notice: This transmittal and/or attachments may be > >>>> privileged or > >>>>>> confidential. If you are not the intended recipient, > >>>>> you are hereby > >>>>>> notified that you have received this transmittal in > >> error; any > >>>>>> review, dissemination, or copying is strictly > >>>> prohibited. If you > >>>>>> received this transmittal in error, please notify us > >>>>> immediately by > >>>>>> reply and immediately delete this message and all its > >>>>> attachments. > >>>>>> Thank you. > >>>>>> T-Systems - Business flexibility >=20 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Mon Nov 19 15:12:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuCyh-0000qY-Tt; Mon, 19 Nov 2007 15:12:19 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IuCyh-0000q8-7s for ancp-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 15:12:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuCyg-0000q0-U9 for ancp@ietf.org; Mon, 19 Nov 2007 15:12:18 -0500 Received: from exprod7og110.obsmtp.com ([64.18.2.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuCyd-0000zw-Ho for ancp@ietf.org; Mon, 19 Nov 2007 15:12:18 -0500 Received: from source ([66.129.224.36]) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP; Mon, 19 Nov 2007 12:11:46 PST Received: from proton.jnpr.net ([10.10.2.37]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 12:11:53 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: [ANCP] Splitting GSMP messages to different TCP packets Date: Mon, 19 Nov 2007 15:02:33 -0500 Message-ID: <9BD5D7887235424FA97DFC223CAE3C280AB436E0@proton.jnpr.net> In-Reply-To: <1B6169C658325341A3B8066E23919E1C679A2C@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [ANCP] Splitting GSMP messages to different TCP packets Thread-Index: AcgnsLX5XS3Ns04wQyiPfkAVxJpEcQAdNcIwAK2gblA= From: "Sanjay Wadhwa" To: "Haag, T" , X-OriginalArrivalTime: 19 Nov 2007 20:11:53.0025 (UTC) FILETIME=[6D0A9B10:01C82AE8] X-Spam-Score: -4.0 (----) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f Cc: "Troester, Stephan" , "Busser, M" , ancp@ietf.org, "Witschurke, Birgit" 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 It seems what you are asking for is the capability for the reciever to = selectively request retransmission of a specific message from the = sender. I don't think this helps. It is possible that TCP is happy (and = has ack'd) as it has receved everything in sequence and with right = checksum, but ANCP receives bad data from the TCP layer (due to internal = software issues such as memory corruption). In this case it is possible = that the receiver doesn't know what to request from the sender. In = certain cases the agreed upon behaviour should be for then receiver to = send out an error notification (a standalone ANCP message indicating = error that can not be recovered from), and restart the ANCP connection = with the peer.=20 As as aside, ANCP has the optional capability where a sender can request = the receiver to acknowledge a given message (we can build retransmission = logic on top). However, this doesn't guarantee recovery from all = scenarios (one outlined above is an example), and therefore doesn't buy = us much beyond reliability provided at TCP layer. -Sanjay >-----Original Message----- >From: Haag, T [mailto:Thomas.Haag@t-systems.com] >Sent: Friday, November 16, 2007 3:05 AM >To: jheitz@redback.com >Cc: Troester, Stephan; Busser,M; ancp@ietf.org; Witschurke,Birgit >Subject: AW: AW: [ANCP] Splitting GSMP messages to different=20 >TCP packets > > >I think it is a misunderstanding. That TCP has such a=20 >mechanism is quite clear.=20 > >But the question was if GSMP on top of TCP has a handshake mechanism? > >There is need for a mechanism which provides a retransmission=20 >of dedicated DSL port information, if the BRAS could not=20 >interpret a single message. > >Regards >Thomas > >-----Urspr=FCngliche Nachricht----- >Von: Jakob Heitz [mailto:jheitz@redback.com]=20 >Gesendet: Donnerstag, 15. November 2007 18:54 >An: Haag, Thomas >Cc: Tr=F6ster, Stephan; Busser, Michael; ancp@ietf.org;=20 >Witschurke, Birgit >Betreff: Re: AW: [ANCP] Splitting GSMP messages to different=20 >TCP packets > >Yes, there is such a handshake mechanism. If received data is >dropped or corrupted or in the wrong order, the sender will >retransmit and the receiver will maintain proper order. > >This is the function of TCP. > >Haag, T wrote: >> Hi Wojciech, >>=20 >> =20 >>=20 >> Assuming that GSMP und layer above don't care about Does=20 >ANCP provide a=20 >> kind of handshake mechanism to enforce the near end sending=20 >only port=20 >> specific messages again if the application layer at the far=20 >end receives=20 >> inconclusive messages? >>=20 >> =20 >>=20 >> Regards >>=20 >> Thomas >>=20 >>=20 >--------------------------------------------------------------- >--------- >>=20 >> *Von:* Wojciech Dec (wdec) [mailto:wdec@cisco.com] >> *Gesendet:* Donnerstag, 15. November 2007 15:50 >> *An:* Busser, Michael; ancp@ietf.org >> *Cc:* Tr=F6ster, Stephan; Haag, Thomas; Witschurke, Birgit >> *Betreff:* RE: [ANCP] Splitting GSMP messages to different=20 >TCP packets >>=20 >> =20 >>=20 >> Hi Michael, >>=20 >> =20 >>=20 >> your interpretation is correct with respect to ANCP over TCP. >>=20 >> =20 >>=20 >> -Woj. >>=20 >> =20 >>=20 >> =20 >--------------------------------------------------------------- >--------- >>=20 >> *From:* Busser, M [mailto:Michael.Busser@t-systems.com] >> *Sent:* 15 November 2007 14:36 >> *To:* ancp@ietf.org >> *Cc:* Troester, Stephan; Haag,T; Witschurke,Birgit >> *Subject:* [ANCP] Splitting GSMP messages to different=20 >TCP packets >>=20 >> Hi all. >>=20 >> =20 >>=20 >> When the adjacency comes up, a bunch of PORT-STATUS=20 >messages will be >> sent >> by the DSLAM to the BRAS. >>=20 >> =20 >>=20 >> If the amount of data (all the GSMP messages) exceeds=20 >the limit of >> one TCP-Packet, >> the next portion of data have to be sent with the next=20 >TCP packets. >>=20 >> =20 >>=20 >> The question now is: >> Do we have any requirements to make sure, that only complete GSMP >> messages >> are sent in one TCP message? >>=20 >> =20 >>=20 >> From my understanding, the stream of GSMP messages is a=20 >byte stream, >> which is transported to the far end by TCP. >> The application layer (e.g. the layer above TCP) do not=20 >have to take >> care >> about such details of transportation. >> So the answer is no. >>=20 >> =20 >>=20 >> Am i wrong? >>=20 >> =20 >>=20 >>=20 >> Best Regards; Freundliche Gr=FC=DFe >>=20 >> *Michael Busser* >>=20 >> T-Systems Enterprise Services GmbH >>=20 >> Production Line Network Centric Systems >>=20 >> ICT-Systems Integration >>=20 >> Network Integration Services >>=20 >> =20 >>=20 >> Br=FCckes 2 -8, 55545 Bad Kreuznach >> Postfach 9100, 55541 Bad Kreuznach >> +49 671 8333 8911 (Phone) >> +49 521 9210 3859 (Fax) >> +49 151 1211 9689 (Mobile) >> E-Mail: michael.busser@t-systems.com >> >>=20 >> Internet: http://www.t-systems.com >>=20 >> =20 >>=20 >> =20 >>=20 >> T-Systems Enterprise Services GmbH >> Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) >> Executive Committee: Helmut Binder, Albert Henn, Olaf Heyden*, >> Katrin Horstmann, Ulrich Kemp, Wilfried Peters*, >> Dr. Herbert Schaaff*, Zvezdana Seeger* >> Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 >> Sitz der Gesellschaft: Frankfurt am Main >> WEEE-Reg.-Nr. DE87523644 >> *Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG >>=20 >> Notice: This transmittal and/or attachments may be privileged or >> confidential. If you are not the intended recipient, you=20 >are hereby >> notified that you have received this transmittal in error; any >> review, dissemination, or copying is strictly prohibited. If you >> received this transmittal in error, please notify us=20 >immediately by >> reply and immediately delete this message and all its=20 >attachments. >> Thank you. >> T-Systems - Business flexibility >>=20 >> =20 >>=20 >> =20 >>=20 >>=20 >>=20 >--------------------------------------------------------------- >--------- >>=20 >> _______________________________________________ >> 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 > > >_______________________________________________ >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 Tue Nov 20 17:15:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IubNW-0003Hg-Ly; Tue, 20 Nov 2007 17:15:34 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IubNV-0003HT-At for ancp-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 17:15:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IubNU-0003HL-WD; Tue, 20 Nov 2007 17:15:33 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IubNU-0006rC-IX; Tue, 20 Nov 2007 17:15:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 756502AC5E; Tue, 20 Nov 2007 22:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IubN0-0003jG-7r; Tue, 20 Nov 2007 17:15:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 20 Nov 2007 17:15:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: ancp@ietf.org Subject: [ANCP] I-D ACTION:draft-ietf-ancp-protocol-02.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 : Protocol for Access Node Control Mechanism in Broadband Networks Author(s) : S. Wadhwa, et al. Filename : draft-ietf-ancp-protocol-02.txt Pages : 43 Date : 2007-11-20 This document describes proposed extensions to the GSMPv3 protocol to allow its use in a broadband environment, as a control plane between Access Nodes (e.g. DSLAM) and Broadband Network Gateways (e.g. NAS). These proposed extensions are required to realize a protocol for “Access Node Control” mechanism as described in [8]. The resulting protocol with the proposed extensions to GSMPv3 [4] is referred to as “Access Node Control Protocol” (ANCP). This document currently focuses on specific use cases of access node control mechanism for topology discovery, line configuration, and OAM as described in ANCP framework document [8]. It is intended to be augmented by additional protocol specification for future use cases considered in scope by the ANCP charter. ANCP framework document [8] describes the ANCP use-cases in detail. Illustrative text for the use-cases is included here to help the protocol implementer understand the greater context of ANCP protocol interactions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ancp-protocol-02.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-protocol-02.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-protocol-02.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-11-20164211.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ancp-protocol-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ancp-protocol-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-20164211.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 Wed Nov 21 07:06:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuoLr-0000SC-Rb; Wed, 21 Nov 2007 07:06:43 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IuoLp-0000S2-Gp for ancp-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 07:06:41 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuoLp-0000Rr-1D for ancp@ietf.org; Wed, 21 Nov 2007 07:06:41 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuoLo-0006H7-Cs for ancp@ietf.org; Wed, 21 Nov 2007 07:06:40 -0500 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP for ancp@ietf.org; Wed, 21 Nov 2007 13:06:38 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Nov 2007 13:06:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 21 Nov 2007 13:06:38 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1C1066C9@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Access Loop Encapsulation Thread-Index: AcgsNvWeoDZoDRDeSCCrXbkXhi0J9w== From: "Busser, M" To: X-OriginalArrivalTime: 21 Nov 2007 12:06:38.0404 (UTC) FILETIME=[F8338040:01C82C36] X-Spam-Score: 0.0 (/) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 Subject: [ANCP] Access Loop Encapsulation 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="===============1763036353==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============1763036353== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C82C36.F7FBCD93" This is a multi-part message in MIME format. ------_=_NextPart_001_01C82C36.F7FBCD93 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Sanjay, all =20 The actual document defines in TLV Access-Loop-Encapsulation: =20 Data Link { ATM AAL5 =3D 0 ETHERNET =3D 1} =20 Shouldn't we use Data Link { ATM AAL5 =3D 1 ETHERNET =3D 2} to be in line with Mammolitit-draft ? =20 Best Regards; Freundliche Gr=FC=DFe=20 Michael Busser T-Systems Enterprise Services GmbH=20 Production Line Network Centric Systems ICT-Systems Integration Network Integration Services =20 Br=FCckes 2 -8, 55545 Bad Kreuznach Postfach 9100, 55541 Bad Kreuznach +49 671 8333 8911 (Phone) +49 521 9210 3859 (Fax) +49 151 1211 9689 (Mobile) E-Mail: michael.busser@t-systems.com Internet: http://www.t-systems.com=20 =20 =20 T-Systems Enterprise Services GmbH Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) Executive Committee: Helmut Binder, Albert Henn, Olaf Heyden*, Katrin = Horstmann, Ulrich Kemp, Wilfried Peters*,=20 Dr. Herbert Schaaff*, Zvezdana Seeger* Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 Sitz der Gesellschaft: Frankfurt am Main WEEE-Reg.-Nr. DE87523644 *Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG=20 Notice: This transmittal and/or attachments may be privileged or = confidential. If you are not the intended recipient, you are hereby = notified that you have received this transmittal in error; any review, = dissemination, or copying is strictly prohibited. If you received this = transmittal in error, please notify us immediately by reply and = immediately delete this message and all its attachments. Thank you.=20 T-Systems - Business flexibility=20 =20 =20 ------_=_NextPart_001_01C82C36.F7FBCD93 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Nachricht
Hi = Sanjay,=20 all
 
The = actual document=20 defines in TLV  Access-Loop-Encapsulation:
 
Data = Link { =20 ATM AAL5 =3D 0        ETHERNET =3D=20 1}
 
Shouldn't we=20 use
Data = Link { =20 ATM AAL5 =3D 1        ETHERNET = =3D=20 2}
to be in line with = Mammolitit-draft=20 ?
 

Best Regards; Freundliche Gr=FC=DFe

Michael Busser
T-Systems=20 Enterprise Services GmbH
Production Line Network Centric Systems
ICT-Systems Integration
Network Integration Services
 
Br=FCckes 2 -8,=20 55545 Bad Kreuznach
Postfach 9100, 55541 Bad Kreuznach
+49 671 = 8333 8911=20 (Phone)
+49 521 9210 3859 (Fax)
+49 151 1211 9689=20 (Mobile)
E-Mail: michael.busser@t-systems.com=
Internet:=20 http://www.t-systems.com
 
 =20
T-Systems Enterprise Services=20 GmbH
Aufsichtsrat: Ren=E9 Obermann (Vorsitzender)
Executive = Committee:=20 Helmut Binder, Albert Henn, Olaf Heyden*, Katrin Horstmann, Ulrich Kemp, = Wilfried Peters*,
Dr. Herbert Schaaff*, Zvezdana = Seeger*
Handelsregister:=20 Amtsgericht Frankfurt am Main HRB 55933
Sitz der Gesellschaft: = Frankfurt am=20 Main
WEEE-Reg.-Nr. DE87523644
*Gesch=E4ftsf=FChrer gem. =A7 35 = GmbHG=20

Notice: This transmittal and/or attachments may be = privileged or=20 confidential. If you are not the intended recipient, you are hereby = notified=20 that you have received this transmittal in error; any review, = dissemination, or=20 copying is strictly prohibited. If you received this transmittal in = error,=20 please notify us immediately by reply and immediately delete this = message and=20 all its attachments. Thank you.
T-Systems = – Business=20 flexibility

 
 
------_=_NextPart_001_01C82C36.F7FBCD93-- --===============1763036353== 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 --===============1763036353==-- From ancp-bounces@ietf.org Wed Nov 21 08:59:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuq7G-0002ls-1h; Wed, 21 Nov 2007 08:59:46 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1Iuq7E-0002ln-Eg for ancp-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 08:59:44 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuq7E-0002le-1v for ancp@ietf.org; Wed, 21 Nov 2007 08:59:44 -0500 Received: from hen.cisco.com ([64.102.19.198] helo=av-tac-rtp.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iuq7D-0001Xi-Kt for ancp@ietf.org; Wed, 21 Nov 2007 08:59:43 -0500 X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost [127.0.0.1]) by av-tac-rtp.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id lALDxhg24812; Wed, 21 Nov 2007 08:59:43 -0500 (EST) Received: from [64.102.159.125] (dhcp-64-102-159-125.cisco.com [64.102.159.125]) by rooster.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id lALE02u06965; Wed, 21 Nov 2007 09:00:02 -0500 (EST) Message-ID: <474439CD.1040503@cisco.com> Date: Wed, 21 Nov 2007 08:59:41 -0500 From: Carlos Pignataro Organization: cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: "Busser, M" Subject: Re: [ANCP] Access Loop Encapsulation References: <1B6169C658325341A3B8066E23919E1C1066C9@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <1B6169C658325341A3B8066E23919E1C1066C9@S4DE8PSAANK.mitte.t-com.de> X-Enigmail-Version: 0.95.5 X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by av-tac-rtp.cisco.com id lALDxhg24812 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be 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 Michael, Please note that TR-101 Section 3.9.5 (page 57) says: Data link =E2=88=88 { ATM AAL5 =3D 0, Ethernet =3D 1 } draft-mammoliti-l2tp-accessline-avp also quotes: Data Link 0x00 ATM AAL5 0x01 Ethernet And there is an Errata item for RFC 4679 [From draft-mammoliti-radius-dsl-vsa] that corrects Access-Loop-Encapsulation: http://www.rfc-editor.org/errata_search.php?rfc=3D4679 Thanks, --Carlos. On 11/21/2007 7:06 AM, Busser, M said the following: > Hi Sanjay, all > =20 > The actual document defines in TLV Access-Loop-Encapsulation: > =20 > Data Link { ATM AAL5 =3D 0 ETHERNET =3D 1} > =20 > Shouldn't we use > Data Link { ATM AAL5 =3D 1 ETHERNET =3D 2} > to be in line with Mammolitit-draft ? > =20 >=20 > Best Regards; Freundliche Gr=C3=BC=C3=9Fe >=20 > * * >=20 > *Michael Busser* >=20 > T-Systems Enterprise Services GmbH > Production Line Network Centric Systems > ICT-Systems Integration > Network Integration Services > =20 > Br=C3=BCckes 2 -8, 55545 Bad Kreuznach > Postfach 9100, 55541 Bad Kreuznach > +49 671 8333 8911 (Phone) > +49 521 9210 3859 (Fax) > +49 151 1211 9689 (Mobile) > E-Mail: michael.busser@t-systems.com > Internet: http://www.t-systems.com > =20 > =20 > T-Systems Enterprise Services GmbH > Aufsichtsrat: Ren=C3=A9 Obermann (Vorsitzender) > Executive Committee: Helmut Binder, Albert Henn, Olaf Heyden*, Katrin > Horstmann, Ulrich Kemp, Wilfried Peters*, > Dr. Herbert Schaaff*, Zvezdana Seeger* > Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 > Sitz der Gesellschaft: Frankfurt am Main > WEEE-Reg.-Nr. DE87523644 > *Gesch=C3=A4ftsf=C3=BChrer gem. =C2=A7 35 GmbHG >=20 > Notice: This transmittal and/or attachments may be privileged or > confidential. If you are not the intended recipient, you are hereby > notified that you have received this transmittal in error; any review, > dissemination, or copying is strictly prohibited. If you received this > transmittal in error, please notify us immediately by reply and > immediately delete this message and all its attachments. Thank you. > T-Systems =E2=80=93 Business flexibility >=20 > =20 > =20 >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www1.ietf.org/mailman/listinfo/ancp --=20 --Carlos Pignataro. Escalation RTP - cisco Systems _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Wed Nov 21 09:09:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuqGs-0007Ce-KQ; Wed, 21 Nov 2007 09:09:42 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IuqGq-0007Aq-Vh for ancp-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 09:09:40 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuqGq-0007AA-JH for ancp@ietf.org; Wed, 21 Nov 2007 09:09:40 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuqGp-000207-VE for ancp@ietf.org; Wed, 21 Nov 2007 09:09:40 -0500 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Wed, 21 Nov 2007 15:09:35 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Nov 2007 15:09:34 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: AW: [ANCP] Access Loop Encapsulation Date: Wed, 21 Nov 2007 15:09:34 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1C1066D3@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <474439CD.1040503@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Access Loop Encapsulation Thread-Index: AcgsRt1iCv7nCR9PS/Wr7NR5J7UlRwAAQExA From: "Busser, M" To: X-OriginalArrivalTime: 21 Nov 2007 14:09:34.0989 (UTC) FILETIME=[24FD0BD0:01C82C48] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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: , Content-Type: multipart/mixed; boundary="===============0676890955==" Errors-To: ancp-bounces@ietf.org --===============0676890955== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgQ2FybG9zLg0KDQpUaGFua3MgZm9yIHRoZSBoaW50Lg0KDQpCZXN0IFJlZ2FyZHMNCk1pY2hh ZWwgQnVzc2VyDQoNCg0KIA0KDQoNCi0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0N ClZvbjogQ2FybG9zIFBpZ25hdGFybyBbbWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbV0gDQpHZXNl bmRldDogTWl0dHdvY2gsIDIxLiBOb3ZlbWJlciAyMDA3IDE1OjAwDQpBbjogQnVzc2VyLCBNaWNo YWVsDQpDYzogYW5jcEBpZXRmLm9yZw0KQmV0cmVmZjogUmU6IFtBTkNQXSBBY2Nlc3MgTG9vcCBF bmNhcHN1bGF0aW9uDQoNCg0KSGkgTWljaGFlbCwNCg0KUGxlYXNlIG5vdGUgdGhhdCBUUi0xMDEg U2VjdGlvbiAzLjkuNSAocGFnZSA1Nykgc2F5czoNCg0KRGF0YSBsaW5rIOKIiCB7DQpBVE0gQUFM NSA9IDAsDQpFdGhlcm5ldCA9IDEgfQ0KDQpkcmFmdC1tYW1tb2xpdGktbDJ0cC1hY2Nlc3NsaW5l LWF2cCBhbHNvIHF1b3RlczoNCiAgICAgIERhdGEgTGluaw0KICAgICAgICAgMHgwMCBBVE0gQUFM NQ0KICAgICAgICAgMHgwMSBFdGhlcm5ldA0KDQpBbmQgdGhlcmUgaXMgYW4gRXJyYXRhIGl0ZW0g Zm9yIFJGQyA0Njc5IFtGcm9tIGRyYWZ0LW1hbW1vbGl0aS1yYWRpdXMtZHNsLXZzYV0gdGhhdCBj b3JyZWN0cyBBY2Nlc3MtTG9vcC1FbmNhcHN1bGF0aW9uOg0KDQpodHRwOi8vd3d3LnJmYy1lZGl0 b3Iub3JnL2VycmF0YV9zZWFyY2gucGhwP3JmYz00Njc5DQoNClRoYW5rcywNCg0KLS1DYXJsb3Mu DQoNCk9uIDExLzIxLzIwMDcgNzowNiBBTSwgQnVzc2VyLCBNIHNhaWQgdGhlIGZvbGxvd2luZzoN Cj4gSGkgU2FuamF5LCBhbGwNCj4gIA0KPiBUaGUgYWN0dWFsIGRvY3VtZW50IGRlZmluZXMgaW4g VExWICBBY2Nlc3MtTG9vcC1FbmNhcHN1bGF0aW9uOg0KPiAgDQo+IERhdGEgTGluayB7ICBBVE0g QUFMNSA9IDAgICAgICAgIEVUSEVSTkVUID0gMX0NCj4gIA0KPiBTaG91bGRuJ3Qgd2UgdXNlDQo+ IERhdGEgTGluayB7ICBBVE0gQUFMNSA9IDEgICAgICAgIEVUSEVSTkVUID0gMn0NCj4gdG8gYmUg aW4gbGluZSB3aXRoIE1hbW1vbGl0aXQtZHJhZnQgPw0KPiAgDQo+IA0KPiBCZXN0IFJlZ2FyZHM7 IEZyZXVuZGxpY2hlIEdyw7zDn2UNCj4gDQo+ICogKg0KPiANCj4gKk1pY2hhZWwgQnVzc2VyKg0K PiANCj4gVC1TeXN0ZW1zIEVudGVycHJpc2UgU2VydmljZXMgR21iSA0KPiBQcm9kdWN0aW9uIExp bmUgTmV0d29yayBDZW50cmljIFN5c3RlbXMNCj4gSUNULVN5c3RlbXMgSW50ZWdyYXRpb24NCj4g TmV0d29yayBJbnRlZ3JhdGlvbiBTZXJ2aWNlcw0KPiAgDQo+IEJyw7xja2VzIDIgLTgsIDU1NTQ1 IEJhZCBLcmV1em5hY2gNCj4gUG9zdGZhY2ggOTEwMCwgNTU1NDEgQmFkIEtyZXV6bmFjaA0KPiAr NDkgNjcxIDgzMzMgODkxMSAoUGhvbmUpDQo+ICs0OSA1MjEgOTIxMCAzODU5IChGYXgpDQo+ICs0 OSAxNTEgMTIxMSA5Njg5IChNb2JpbGUpDQo+IEUtTWFpbDogbWljaGFlbC5idXNzZXJAdC1zeXN0 ZW1zLmNvbSANCj4gPG1haWx0bzptaWNoYWVsLmJ1c3NlckB0LXN5c3RlbXMuY29tPg0KPiBJbnRl cm5ldDogaHR0cDovL3d3dy50LXN5c3RlbXMuY29tIDxodHRwOi8vd3d3LnQtc3lzdGVtcy5jb20v Pg0KPiAgDQo+ICANCj4gVC1TeXN0ZW1zIEVudGVycHJpc2UgU2VydmljZXMgR21iSA0KPiBBdWZz aWNodHNyYXQ6IFJlbsOpIE9iZXJtYW5uIChWb3JzaXR6ZW5kZXIpDQo+IEV4ZWN1dGl2ZSBDb21t aXR0ZWU6IEhlbG11dCBCaW5kZXIsIEFsYmVydCBIZW5uLCBPbGFmIEhleWRlbiosIEthdHJpbiAN Cj4gSG9yc3RtYW5uLCBVbHJpY2ggS2VtcCwgV2lsZnJpZWQgUGV0ZXJzKiwgRHIuIEhlcmJlcnQg U2NoYWFmZiosIA0KPiBadmV6ZGFuYSBTZWVnZXIqDQo+IEhhbmRlbHNyZWdpc3RlcjogQW10c2dl cmljaHQgRnJhbmtmdXJ0IGFtIE1haW4gSFJCIDU1OTMzDQo+IFNpdHogZGVyIEdlc2VsbHNjaGFm dDogRnJhbmtmdXJ0IGFtIE1haW4NCj4gV0VFRS1SZWcuLU5yLiBERTg3NTIzNjQ0DQo+ICpHZXNj aMOkZnRzZsO8aHJlciBnZW0uIMKnIDM1IEdtYkhHDQo+IA0KPiBOb3RpY2U6IFRoaXMgdHJhbnNt aXR0YWwgYW5kL29yIGF0dGFjaG1lbnRzIG1heSBiZSBwcml2aWxlZ2VkIG9yIA0KPiBjb25maWRl bnRpYWwuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVy ZWJ5IA0KPiBub3RpZmllZCB0aGF0IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXR0YWwg aW4gZXJyb3I7IGFueSByZXZpZXcsIA0KPiBkaXNzZW1pbmF0aW9uLCBvciBjb3B5aW5nIGlzIHN0 cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSByZWNlaXZlZCB0aGlzIA0KPiB0cmFuc21pdHRhbCBp biBlcnJvciwgcGxlYXNlIG5vdGlmeSB1cyBpbW1lZGlhdGVseSBieSByZXBseSBhbmQgDQo+IGlt bWVkaWF0ZWx5IGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGFsbCBpdHMgYXR0YWNobWVudHMuIFRo YW5rIHlvdS4gDQo+IFQtU3lzdGVtcyDigJMgQnVzaW5lc3MgZmxleGliaWxpdHkNCj4gDQo+ICAN Cj4gIA0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLS0NCj4gDQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEFOQ1AgbWFpbGluZyBsaXN0DQo+ IEFOQ1BAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v YW5jcA0KDQotLSANCi0tQ2FybG9zIFBpZ25hdGFyby4NCkVzY2FsYXRpb24gUlRQIC0gY2lzY28g U3lzdGVtcw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpBTkNQIG1haWxpbmcgbGlzdA0KQU5DUEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vYW5jcA0K --===============0676890955== 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 --===============0676890955==-- From ancp-bounces@ietf.org Wed Nov 21 09:28:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuqYr-0006Je-TW; Wed, 21 Nov 2007 09:28:17 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IuqYp-000620-PM for ancp-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 09:28:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuqYo-0005z7-PE for ancp@ietf.org; Wed, 21 Nov 2007 09:28:14 -0500 Received: from smail5.alcatel.fr ([64.208.49.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuqYi-0006fY-Au for ancp@ietf.org; Wed, 21 Nov 2007 09:28:14 -0500 Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.ad2.ad.alcatel.com [155.132.6.74]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id lALEQfFU024309 for ; Wed, 21 Nov 2007 15:26:41 +0100 Received: from FRVELSMBS14.ad2.ad.alcatel.com ([155.132.6.34]) by FRVELSBHS02.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 21 Nov 2007 15:28:07 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 21 Nov 2007 15:28:06 +0100 Message-ID: <2E17595838F96949AB1F0FD9A8EC5ED017A3A3@FRVELSMBS14.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF70 ANCP agenda Thread-Index: AcgsSrs46YegRxI6R+uEitN71XyhqQ== From: "BOCCI Matthew" To: X-OriginalArrivalTime: 21 Nov 2007 14:28:07.0009 (UTC) FILETIME=[BBCDD510:01C82C4A] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Subject: [ANCP] IETF70 ANCP agenda 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="===============1864655829==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============1864655829== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C82C4A.BBA7D6DD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C82C4A.BBA7D6DD Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable All, Here is the draft agenda for the ANCP meeting in Vancouver. I have also uploaded this to the IETF meeting materials page. Please can presenters send me their slides by noon PST on Wednesday 5th December. Please can you let me know if you have any comments/corrections/additions. Best regards, Matthew Thursday, December 6th, 2007 - 13:00 - 15:00 ----------------------------------- CHAIRS: Wojciech Dec & Matthew Bocci 15 mins WG Status and Update - Chairs 10 mins - ANCP Framework and Requirements - Sven ooghe (sven.ooghe@alcatel-lucent.be) http://tools.ietf.org/html/draft-ietf-ancp-framework-04 15 mins - Multicast Issues - Roberta Maglione (roberta.maglione@telecomitalia.it) http://tools.ietf.org/html/draft-ietf-ancp-framework-04 http://tools.ietf.org/wg/ancp/draft-maglione-ancp-mcast-00.txt Discuss multicast open issues in the framework draft. 10 mins - ANCP Access Node MIB - Stefaan de Cnodder (stefaan.de_cnodder@alcatel-lucent.be) http://tools.ietf.org/html/draft-ietf-ancp-mib-an-01 15 mins - ANCP Protocol Draft - Sanjay Wadhwa (swadhwa@juniper.net) http://tools.ietf.org/html/draft-ietf-ancp-protocol-01 Discuss protocol draft updates and ANCP graceful restart. ------_=_NextPart_001_01C82C4A.BBA7D6DD Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable IETF70 ANCP agenda

All,

Here is the draft agenda for the ANCP = meeting in Vancouver. I have also uploaded this to the IETF meeting = materials page.

Please can presenters send me their = slides by noon PST on Wednesday 5th December.

Please can you let me know if you have = any comments/corrections/additions.

Best regards,

Matthew

Thursday, December 6th, 2007 = – 13:00 – = 15:00
-----------------------------------
CHAIRS: Wojciech Dec  & = Matthew Bocci

15 mins WG Status and Update - = Chairs


10 mins – ANCP = Framework and Requirements – Sven ooghe = (sven.ooghe@alcatel-lucent.be)
http://tools.ietf.org/html/draft-ietf-ancp-framework-04


15 mins – Multicast = Issues - Roberta Maglione (roberta.maglione@telecomitalia.it)
http://tools.ietf.org/html/draft-ietf-ancp-framework-04
<= U>http://tools.ietf.org/wg/ancp/draft-maglione-ancp-mcast-00= .txt
Discuss multicast open issues in the = framework draft.

10 mins – ANCP Access = Node MIB – Stefaan de Cnodder = (stefaan.de_cnodder@alcatel-lucent.be)
http://tools.ietf.org/html/draft-ietf-ancp-mib-an-01

15 mins – ANCP = Protocol Draft – Sanjay Wadhwa (swadhwa@juniper.net)
http://tools.ietf.org/html/draft-ietf-ancp-protocol-01
Discuss protocol draft updates and = ANCP graceful restart.

------_=_NextPart_001_01C82C4A.BBA7D6DD-- --===============1864655829== 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 --===============1864655829==-- From ancp-bounces@ietf.org Thu Nov 22 08:55:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvCWc-00031r-L5; Thu, 22 Nov 2007 08:55:26 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IvCWb-0002w9-Lp for ancp-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 08:55:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvCWb-0002w1-A2 for ancp@ietf.org; Thu, 22 Nov 2007 08:55:25 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvCWa-0007Uc-LC for ancp@ietf.org; Thu, 22 Nov 2007 08:55:25 -0500 X-IronPort-AV: E=Sophos;i="4.21,451,1188770400"; d="scan'208";a="158525095" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 22 Nov 2007 14:55:24 +0100 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 lAMDtNlg005054; Thu, 22 Nov 2007 14:55:23 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAMDspZr001708; Thu, 22 Nov 2007 13:55:16 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Nov 2007 14:55:03 +0100 Received: from [144.254.53.159] ([144.254.53.159]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Nov 2007 14:55:03 +0100 In-Reply-To: <54469D09-60CF-4AE8-8BAD-A26B9E256113@cisco.com> References: <9BD5D7887235424FA97DFC223CAE3C2803B76378@proton.jnpr.net> <54469D09-60CF-4AE8-8BAD-A26B9E256113@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Francois Le Faucheur IMAP Subject: Spontaneous Admission Response (was Re: [ANCP] ANCP WG follow-up) Date: Thu, 22 Nov 2007 14:54:58 +0100 To: Francois Le Faucheur IMAP X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 22 Nov 2007 13:55:03.0085 (UTC) FILETIME=[47B4CDD0:01C82D0F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3966; t=1195739723; x=1196603723; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Spontaneous=20Admission=20Response=20(was=20Re=3A=20[ANCP]=20 ANCP=20WG=20follow-up) |Sender:=20; bh=Rhy6grzY8sR6+H+oltYB9iFdNVFlcZfkjLO5VdhCbNs=; b=pGdI4BoOeH30MNE+2LnZqJxlQ9jW1Oj58AUJq/Udv2Ty9wE32yL/J9oc4Uh8DKKbQIV6m63F AjZcaLAYFCazYITsgbIPiEY1A022/mNcQlgInxslvu/FAXXRrThPP2hi; Authentication-Results: ams-dkim-1; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a 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 Hello, On 19 Sep 2007, at 15:56, Francois Le Faucheur IMAP wrote: > Sanjay and all, > > 2) you raise a valid point that there are ANCP deployment > variations whereby the replication on AN may be controlled by NAS > via ANCP, but where the "join/leave" information may not be > conveyed to NAS via ANCP. I agree the ANCP solution should allow > this. We will work on a revised proposal allowing this. > > Francois As agreed above, below is a proposal for modification to the text of draft-ietf-ancp-framework-04.txt in order to accommodate ANCP deployment models where the "join/leave" information may not be conveyed to NAS via ANCP. We'd appreciate feedback. Thanks Francois In section 3.4.4: ============ Replace: " 3.4.4. Multicast Termination" by: " 3.4.4. Spontaneous Admission Response" In second paragraph, replace: "This can be done with the Admission Response message." by "This can be achieved by the NAS sending a spontaneous Admission Response message (ie sent by NAS without prior receipt of a corresponding Admission Request)." At the end of 3.4.4: add a new paragraph: "In some deployment scenarios, the NAS may be made aware of end-users requests to join/leave a multicast flow by other means than ANCP Admission Requests sent by the AN (for example, the IGMP join/leave from the end-user might be somehow tunneled to the NAS). In such environments, the NAS can still control multicast replication to be performed by the AN via ANCP through the use of spontaneous Admission Responses (ie sent by NAS without prior receipt of a corresponding Admission Request)." In section 4.2: =========== replace: " o The ANCP MUST allow the AN to query the NAS to request an admission decision for replicating a multicast flow to a particular Access Port." by " o The ANCP MUST allow the AN to send an Admission Request to the NAS to request an admission decision for replicating a multicast flow to a particular Access Port." replace: " o The ANCP MUST allow the NAS to send an admission decision to the AN indicating whether or not a multicast flow may be replicated to a particular Access Port." by " o The ANCP MUST allow the NAS to send an Admission Response to the AN (e.g. indicating whether or not a multicast flow is to be replicated to a particular Access Port). o The ANCP MUST allow the NAS to send such an Admission Response either in response to an Admission Request received from the AN or spontaneously (i.e. without having received a corresponding Admission Request from AN). o In particular, the ANCP MUST allow the NAS to send such an Admission Response in order to revoke a decision to replicate a multicast flow to a particular Access Port, that had been conveyed earlier to an AN. o The ANCP MUST allow the AN to notify the NAS of the outcome (success/failure) of a join/leave instruction conveyed in an Admission Response from the NAS. " replace: " o The ANCP MUST allow the NAS, when replying to an AN request, to OPTIONALLY convey information on multiple multicast flows sharing the same conditional access rules. This allows the AN to take autonomous decisions for these flows later on." by: " o The ANCP MUST allow the NAS, when sending an Admission Response, to OPTIONALLY convey information on multiple multicast flows sharing the same conditional access and admission control rules. This allows the AN to take autonomous decisions for these flows later on." delete (this has been replaced by an equivalent requirement above)" " o The ANCP MUST allow the NAS to revoke a decision to replicate a multicast flow to a particular Access Port, which had been conveyed earlier to an AN." _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Fri Nov 23 02:35:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvT4k-0004Ie-M3; Fri, 23 Nov 2007 02:35:46 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IvT4j-0004FF-AK for ancp-confirm+ok@megatron.ietf.org; Fri, 23 Nov 2007 02:35:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvT4i-00047j-Jj for ancp@ietf.org; Fri, 23 Nov 2007 02:35:44 -0500 Received: from maile.telecomitalia.it ([156.54.233.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvT4h-0006d3-1S for ancp@ietf.org; Fri, 23 Nov 2007 02:35:44 -0500 Received: from ptpxch009ba020.idc.cww.telecomitalia.it ([156.54.240.52]) by maile.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Nov 2007 08:35:38 +0100 Received: from PTPEVS108BA020.idc.cww.telecomitalia.it ([156.54.241.228]) by ptpxch009ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Nov 2007 08:35:37 +0100 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2929 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Importance: normal Priority: normal Content-Transfer-Encoding: quoted-printable Subject: Introducing Mutlicast Grey-List (was RE: [ANCP] Comments on draft-maglione) Date: Fri, 23 Nov 2007 08:35:36 +0100 Message-ID: <9E577E61D0108D4F8CD482029B613F5C0181BF87@PTPEVS108BA020.idc.cww.telecomitalia.it> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Introducing Mutlicast Grey-List (was RE: [ANCP] Comments on draft-maglione) thread-index: AcfNPesp0+998lMLS6y94SJ58ITZqQA3eI51F+FoAgA= References: <8C253CB7-CF45-431D-94B6-4AC1A1653524@cisco.com> From: "Maglione Roberta" To: X-OriginalArrivalTime: 23 Nov 2007 07:35:37.0818 (UTC) FILETIME=[70F67BA0:01C82DA3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9cc83ac38bbbabacbf00f656311dd8d8 Cc: Ullio Mario , Michel Platnic 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 Hello, as we discussed during Chicago meeting below is a proposal for = modification to the text of draft-ietf-ancp-framework-04.txt in order to = introduce Multicast Grey List and leave Black List (i.e. deny) as = default behavior.=20 We'd appreciate feedback. Regards, Roberta Section 3.4.1 Replace: " Provisioning the conditional access information on the AN can be done = using a "White list" and/or a "Black list". A White list associated with an Access Port identifies the multicast = flows that are allowed to be replicated to that port. A Black list = associated with an Access Port identifies the multicast flows that are = not allowed to be replicated to that port." By: " Provisioning the conditional access information on the AN can be done = using a "White list", "Grey list", and/or a "Black list". A White list = associated with an Access Port identifies the multicast flows that are = allowed to be replicated to that port. A Black list associated with an = Access Port identifies the multicast flows that are not allowed to be = replicated to that port. A Grey list associated with an Access Port = identifies the multicast flows for which the AN on receiving a Join = message, before starting traffic replication queries NAS for further = authorization.=20 Each list contains zero, one or multiple entries and each entry may = specify a single flow or contain ranges (i.e. mask on Group address = and/or mask on Source address).=20 Replace: "Upon receiving a join message on an Access Port, the Access Node will = first check if the requested multicast flow is part of a White list or a = Black list associated with that Access Port. If it is part of a White = list, the AN can autonomously start replicating multicast traffic. If = it is part of a Black list, the AN can autonomously discard the message = because the request is not authorized"=20 By: "Upon receiving a join message on an Access Port, the Access Node will = first check if the requested multicast flow is part of a White, Grey or = a Black list associated with that Access Port. If it is part of a White = list, the AN can autonomously start replicating multicast traffic. If = it is part of a Black list, the AN can autonomously discard the message = because the request is not authorized. If it is part of a Grey list the = AN uses ANCP to query the NAS, that in turn will respond to the AN = indicating whether the join is to be honored (and hence replication = performed by the AN) or denied (and hence replication not performed by = the AN.) If a Join message is received by AN for a flow which is not on any list, = then it is rejected (i.e. the default behavior is to drop such = messages.) If a join is received by AN for a flow that matches multiple = lists, then a deterministic algorithm (to be specified in ancp-protocol) = is used by the AN to decide which list behavior takes precedence. Following are some example scenarios: Scenario 1: * no config: =3D=3D> any Join message gets rejected by AN Scenario 2: * White List =3D { , , ... = } =3D=3D> Join ( S=3D*,G=3DGi) gets honored by AN ( 1<=3Di<=3Dn ) =3D=3D> everything else gets rejected by AN Scenario 3: * White List =3D { , , ... = } * Grey List =3D { } m>n =3D=3D> Join ( S=3D*,G=3DGi) gets honored by AN ( 1<=3Di<=3Dn ) =3D=3D> Join ( S=3Ds,G=3DGm) triggers ANCP Admission Request to NAS =3D=3D> everything else gets rejected by AN Section 3.4.2 Replace: " One approach is for the AN to query the NAS so that both unicast and multicast CAC for the access line are performed by the NAS. In this case, the AN can use ANCP to query the NAS, that in turn performs multicast CAC and responds to the AN indicating whether the join is to be honored (and hence replication performed by the AN) or denied. In the process, the NAS may communicate with a Policy Server.=20 " With: " One approach is for the AN to query the NAS so that both unicast and multicast CAC for the access line are performed by the NAS. In this case, upon receiving a join to a multicast flow which = matches the Grey List, the AN can use ANCP to query the NAS, that in = turn performs multicast CAC and responds to the AN indicating whether the join is to be honored (and hence replication performed by the AN) or denied. In the process, the NAS may communicate with a Policy Server.=20 Section 4.2 Replace " The ANCP MUST support providing multicast conditional access information to Access Ports on an Access Node, using Black lists and White lists. " By " The ANCP MUST support providing multicast conditional access information to Access Ports on an Access Node, using Black, Grey and White lists. " Replace "The ANCP MUST support binding a particular Black list and White List to a given Access Port" By: " The ANCP MUST support binding a particular Black, Grey and White List to a given Access Port " Replace: The ANCP MUST support partial updates of the White lists and Black lists. by The ANCP MUST support partial updates of the White, Grey and Black lists. Replace: The ANCP MUST allow the AN to query the NAS to request an admission decision for replicating a multicast flow to a particular Access Port. By Upon receiving a join to a multicast flow which matches the Grey List = the ANCP MUST allow the AN to query the NAS to request an admission = decision for replicating that multicast flow to a particular Access = Port. Section 4.7.6 Replace and split in two " Upon receiving a join to a multicast flow which does not match any entry in the Black List nor in the White List for a specific Access Port, the AN must support using ANCP to query the NAS to receive a response indicating whether that join is to be honored or denied." By: " Upon receiving a join to a multicast flow which matches the Grey List = for a specific Access Port, the AN must support using ANCP to query the = NAS to receive a response indicating whether that join is to be honored = or denied. " " The AN must deny any join to a multicast flow that does not match any entry in the Black List nor in the White List nor Grey List for = the relevant Access Port" Adding the following requirements: "Upon receiving a join to a multicast flow which matches the Grey List, = AN is not allowed to propagate that join request, before the successful = authorization from the NAS is received." "Upon receiving a leave to a multicast flow which matches the Grey List, = AN SHOULD be able to autonomously stop replication and SHOULD be able to = advertise this event to the NAS."=20 Section 4.8.6 Adding: The NAS MUST support using ANCP to incrementally add, remove and modify = individual entries in White, Black and Grey lists. ------------------------------------------------------- Roberta Maglione - CCIE #18425 Telecom Italia Broadband Network Services Innovation -------------------------------------------------------=20 ________________________________________ From: Michel Platnic [mailto:Michel.Platnic@ecitele.com]=20 Sent: Tuesday, July 24, 2007 8:22 PM To: Francois Le Faucheur IMAP Cc: Garofalo Angelo; ancp@ietf.org Subject: RE: [ANCP] Comments on draft-maglione Hi Francois, Please see my comments inline, Regards, Michel. =20 ________________________________________ From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com] Sent: Mon 7/23/2007 6:23 PM To: Michel Platnic Cc: Francois Le Faucheur IMAP; OOGHE Sven; ancp@ietf.org; = angelo.garofalo@telecomitalia.it Subject: Re: [ANCP] Comments on draft-maglione Hi Michel,=20 =20 Using access control capabilities within the access network = provides the two main following benefits: - refrain from sending any content to a customer that was not paid for = (mostly relevant when Encryption is not used) - provides a filter against end-user applications/hackers that may send = IGMP requests with invalid IP address =20 A solution where all the IP addresses that are not part of either the = Black-list or the White-List are sent to a central policy server for = authorization gives me some concerns regarding the robustness of the = whole system. Same concern regarding the treatment of unknown IP source = addresses ('Everything else'). Agreed. We had these concerns in mind also. This is why the Black-Lists = and White-Lists include the ability to define arbitrarily large = ranges/masks. In particular, as an example, one can easily define a = Black-List which contains a single "catch-all" entry that matches any = Multicast address & Source. Then you can define a White-List with the = explicit channels you want to allow. This effectively implements a = policy whereby everything is blocked by AN, except the channels that = have been explicitly allowed in the White-List. In other words, the Black-List can be used for explicit listing of = channels, or it can easily be used as a "catch-all" (for all, or for = arbitrarily large ranges of channels). This should address your concern of making sure that the "default" = behavior for any non-explicitly defined channel is not to query = NAS/Central_server. See in draft-maglione: " The White List and Black List can contain entries allowing: o an exact match for a (*,G) ASM group (e.g. )=20 o an exact match for a (S,G) SSM channel (e.g. = =20 o a mask-based range match for a (*,G) ASM group (e.g.=20 )=20 o a mask-based range match for a (S,G) SSM channel (e.g.=20 =20 " Let me try to rephrase your proposal; there would be a default = state wherein any channel being neither part of White-list nor = Black-list would be discarded.=20 If its the case I agree with you that this solution solves the security = issue. =20 But what about when AN is not in this default state? If "Accept everything else" is used then again same problem of security = is encountered, and any hacker or application can overload the policy = server with requests.=20 To my understanding, the model proposed, where the NAS is getting the = customer request for authorization, requires this mode of operation. So we still have the same problem. Did I miss anything? =20 =20 _________________________________________________________________________= _____ I understand that some applications may require sophisticated policy = decision making and that, as a matter of fact, some AN/central policy = server synchronization mechanism should to be proposed, but the solution must be Robust and Scalable. For now I am not convinced that solution proposed is either Robust or = Scalable. Let us know if you have specific robustness/scalability concerns (beyond = the one discussed above)? Then we could work together on addressing those.=20 =20 Well, there is still this scalable issue when duplicating the = messages that need to be treated in real-time by the NAS. Sven already = made some counting regarding this topic. I believe this point could lead = to scalability issues. If we had the above described potential disaster, = then we end-up getting serious Robustness issues. =20 Thanks Francois =20 Regards, Michel. -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons = above and may contain confidential information. If you have received the = message in error, be informed that any use of the content hereof is = prohibited. Please return it immediately to the sender and delete the = message. Should you have any questions, please contact us by replying to = webmaster@telecomitalia.it. Thank you www.telecomitalia.it -------------------------------------------------------------------- =20 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Fri Nov 23 11:19:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvbFE-0004ro-HX; Fri, 23 Nov 2007 11:19:08 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IvbFD-0004rc-OU for ancp-confirm+ok@megatron.ietf.org; Fri, 23 Nov 2007 11:19:07 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvbFD-0004rU-CI for ancp@ietf.org; Fri, 23 Nov 2007 11:19:07 -0500 Received: from smail5.alcatel.fr ([64.208.49.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvbFB-00062Z-NU for ancp@ietf.org; Fri, 23 Nov 2007 11:19:07 -0500 Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.ad2.ad.alcatel.com [155.132.6.78]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id lANGF6HW025039; Fri, 23 Nov 2007 17:15:06 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.52]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 23 Nov 2007 17:16:33 +0100 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: Introducing Mutlicast Grey-List (was RE: [ANCP] Comments ondraft-maglione) Date: Fri, 23 Nov 2007 17:16:31 +0100 Message-ID: <8144761F31F48D43AD53D09F5350E38002069337@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <9E577E61D0108D4F8CD482029B613F5C0181BF87@PTPEVS108BA020.idc.cww.telecomitalia.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Introducing Mutlicast Grey-List (was RE: [ANCP] Comments ondraft-maglione) Thread-Index: AcfNPesp0+998lMLS6y94SJ58ITZqQA3eI51F+FoAgAADtulYA== References: <8C253CB7-CF45-431D-94B6-4AC1A1653524@cisco.com> <9E577E61D0108D4F8CD482029B613F5C0181BF87@PTPEVS108BA020.idc.cww.telecomitalia.it> From: "OOGHE Sven" To: "Maglione Roberta" , X-OriginalArrivalTime: 23 Nov 2007 16:16:33.0110 (UTC) FILETIME=[36918F60:01C82DEC] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: fca741f5016e6ff607eaed2fd431d10d Cc: Michel Platnic , Ullio Mario 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 Hello Roberta, Thinking a bit further about the default behavior, I am not sure that dropping would be the right approach. (cf. "If a Join message is received by AN for a flow which is not on any list, then it is rejected") Imagine any multicast flow out there on the Internet (e.g. Internet TV), then if it is not configured on the Access Node, it will be rejected. I don't think this is what an end-user would want. Instead, I would argue that if the flow is not part of any of the lists, that the behavior would be to accept it as best effort, i.e. accept without further admission control checks. What do you think? Regards, Sven =20 -----Original Message----- From: Maglione Roberta [mailto:roberta.maglione@telecomitalia.it]=20 Sent: vrijdag 23 november 2007 8:36 To: ancp@ietf.org Cc: Ullio Mario; Michel Platnic Subject: Introducing Mutlicast Grey-List (was RE: [ANCP] Comments ondraft-maglione) Hello, as we discussed during Chicago meeting below is a proposal for modification to the text of draft-ietf-ancp-framework-04.txt in order to introduce Multicast Grey List and leave Black List (i.e. deny) as default behavior.=20 We'd appreciate feedback. Regards, Roberta Section 3.4.1 Replace: " Provisioning the conditional access information on the AN can be done using a "White list" and/or a "Black list". A White list associated with an Access Port identifies the multicast flows that are allowed to be replicated to that port. A Black list associated with an Access Port identifies the multicast flows that are not allowed to be replicated to that port." By: " Provisioning the conditional access information on the AN can be done using a "White list", "Grey list", and/or a "Black list". A White list associated with an Access Port identifies the multicast flows that are allowed to be replicated to that port. A Black list associated with an Access Port identifies the multicast flows that are not allowed to be replicated to that port. A Grey list associated with an Access Port identifies the multicast flows for which the AN on receiving a Join message, before starting traffic replication queries NAS for further authorization.=20 Each list contains zero, one or multiple entries and each entry may specify a single flow or contain ranges (i.e. mask on Group address and/or mask on Source address).=20 Replace: "Upon receiving a join message on an Access Port, the Access Node will first check if the requested multicast flow is part of a White list or a Black list associated with that Access Port. If it is part of a White list, the AN can autonomously start replicating multicast traffic. If it is part of a Black list, the AN can autonomously discard the message because the request is not authorized"=20 By: "Upon receiving a join message on an Access Port, the Access Node will first check if the requested multicast flow is part of a White, Grey or a Black list associated with that Access Port. If it is part of a White list, the AN can autonomously start replicating multicast traffic. If it is part of a Black list, the AN can autonomously discard the message because the request is not authorized. If it is part of a Grey list the AN uses ANCP to query the NAS, that in turn will respond to the AN indicating whether the join is to be honored (and hence replication performed by the AN) or denied (and hence replication not performed by the AN.) If a Join message is received by AN for a flow which is not on any list, then it is rejected (i.e. the default behavior is to drop such messages.) If a join is received by AN for a flow that matches multiple lists, then a deterministic algorithm (to be specified in ancp-protocol) is used by the AN to decide which list behavior takes precedence. Following are some example scenarios: Scenario 1: * no config: =3D=3D> any Join message gets rejected by AN Scenario 2: * White List =3D { , , ... = } =3D=3D> Join ( S=3D*,G=3DGi) gets honored by AN ( 1<=3Di<=3Dn ) =3D=3D> everything else gets rejected by AN Scenario 3: * White List =3D { , , ... = } * Grey List =3D { } m>n =3D=3D> Join ( S=3D*,G=3DGi) gets honored by AN ( 1<=3Di<=3Dn ) =3D=3D> Join ( S=3Ds,G=3DGm) triggers ANCP Admission Request to NAS =3D=3D> everything else gets rejected by AN Section 3.4.2 Replace: " One approach is for the AN to query the NAS so that both unicast and multicast CAC for the access line are performed by the NAS. In this case, the AN can use ANCP to query the NAS, that in turn performs multicast CAC and responds to the AN indicating whether the join is to be honored (and hence replication performed by the AN) or denied. In the process, the NAS may communicate with a Policy Server.=20 " With: " One approach is for the AN to query the NAS so that both unicast and multicast CAC for the access line are performed by the NAS. In this case, upon receiving a join to a multicast flow which matches the Grey List, the AN can use ANCP to query the NAS, that in turn performs multicast CAC and responds to the AN indicating whether the join is to be honored (and hence replication performed by the AN) or denied. In the process, the NAS may communicate with a Policy Server.=20 Section 4.2 Replace " The ANCP MUST support providing multicast conditional access information to Access Ports on an Access Node, using Black lists and White lists. " By " The ANCP MUST support providing multicast conditional access information to Access Ports on an Access Node, using Black, Grey and White lists. " Replace "The ANCP MUST support binding a particular Black list and White List to a given Access Port" By: " The ANCP MUST support binding a particular Black, Grey and White List to a given Access Port " Replace: The ANCP MUST support partial updates of the White lists and Black lists. by The ANCP MUST support partial updates of the White, Grey and Black lists. Replace: The ANCP MUST allow the AN to query the NAS to request an admission decision for replicating a multicast flow to a particular Access Port. By Upon receiving a join to a multicast flow which matches the Grey List the ANCP MUST allow the AN to query the NAS to request an admission decision for replicating that multicast flow to a particular Access Port. Section 4.7.6 Replace and split in two " Upon receiving a join to a multicast flow which does not match any entry in the Black List nor in the White List for a specific Access Port, the AN must support using ANCP to query the NAS to receive a response indicating whether that join is to be honored or denied." By: " Upon receiving a join to a multicast flow which matches the Grey List for a specific Access Port, the AN must support using ANCP to query the NAS to receive a response indicating whether that join is to be honored or denied. " " The AN must deny any join to a multicast flow that does not match any entry in the Black List nor in the White List nor Grey List for the relevant Access Port" Adding the following requirements: "Upon receiving a join to a multicast flow which matches the Grey List, AN is not allowed to propagate that join request, before the successful authorization from the NAS is received." "Upon receiving a leave to a multicast flow which matches the Grey List, AN SHOULD be able to autonomously stop replication and SHOULD be able to advertise this event to the NAS."=20 Section 4.8.6 Adding: The NAS MUST support using ANCP to incrementally add, remove and modify individual entries in White, Black and Grey lists. ------------------------------------------------------- Roberta Maglione - CCIE #18425 Telecom Italia Broadband Network Services Innovation ------------------------------------------------------- ________________________________________ From: Michel Platnic [mailto:Michel.Platnic@ecitele.com] Sent: Tuesday, July 24, 2007 8:22 PM To: Francois Le Faucheur IMAP Cc: Garofalo Angelo; ancp@ietf.org Subject: RE: [ANCP] Comments on draft-maglione Hi Francois, Please see my comments inline, Regards, Michel. =20 ________________________________________ From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com] Sent: Mon 7/23/2007 6:23 PM To: Michel Platnic Cc: Francois Le Faucheur IMAP; OOGHE Sven; ancp@ietf.org; angelo.garofalo@telecomitalia.it Subject: Re: [ANCP] Comments on draft-maglione Hi Michel,=20 =20 Using access control capabilities within the access network provides the two main following benefits: - refrain from sending any content to a customer that was not paid for (mostly relevant when Encryption is not used) - provides a filter against end-user applications/hackers that may send IGMP requests with invalid IP address =20 A solution where all the IP addresses that are not part of either the Black-list or the White-List are sent to a central policy server for authorization gives me some concerns regarding the robustness of the whole system. Same concern regarding the treatment of unknown IP source addresses ('Everything else'). Agreed. We had these concerns in mind also. This is why the Black-Lists and White-Lists include the ability to define arbitrarily large ranges/masks. In particular, as an example, one can easily define a Black-List which contains a single "catch-all" entry that matches any Multicast address & Source. Then you can define a White-List with the explicit channels you want to allow. This effectively implements a policy whereby everything is blocked by AN, except the channels that have been explicitly allowed in the White-List. In other words, the Black-List can be used for explicit listing of channels, or it can easily be used as a "catch-all" (for all, or for arbitrarily large ranges of channels). This should address your concern of making sure that the "default" behavior for any non-explicitly defined channel is not to query NAS/Central_server. See in draft-maglione: " The White List and Black List can contain entries allowing: o an exact match for a (*,G) ASM group (e.g. )=20 o an exact match for a (S,G) SSM channel (e.g. = o a mask-based range match for a (*,G) ASM group (e.g.=20 )=20 o a mask-based range match for a (S,G) SSM channel (e.g.=20 " Let me try to rephrase your proposal; there would be a default state wherein any channel being neither part of White-list nor Black-list would be discarded.=20 If its the case I agree with you that this solution solves the security issue. =20 But what about when AN is not in this default state? If "Accept everything else" is used then again same problem of security is encountered, and any hacker or application can overload the policy server with requests.=20 To my understanding, the model proposed, where the NAS is getting the customer request for authorization, requires this mode of operation. So we still have the same problem. Did I miss anything? =20 =20 ________________________________________________________________________ ______ I understand that some applications may require sophisticated policy decision making and that, as a matter of fact, some AN/central policy server synchronization mechanism should to be proposed, but the solution must be Robust and Scalable. For now I am not convinced that solution proposed is either Robust or Scalable. Let us know if you have specific robustness/scalability concerns (beyond the one discussed above)? Then we could work together on addressing those.=20 =20 Well, there is still this scalable issue when duplicating the messages that need to be treated in real-time by the NAS. Sven already made some counting regarding this topic. I believe this point could lead to scalability issues. If we had the above described potential disaster, then we end-up getting serious Robustness issues. =20 Thanks Francois =20 Regards, Michel. -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to webmaster@telecomitalia.it. Thank you www.telecomitalia.it -------------------------------------------------------------------- =20 _______________________________________________ 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 Sun Nov 25 16:30:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwP3j-00052z-Fx; Sun, 25 Nov 2007 16:30:35 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IwP3j-00052u-0R for ancp-confirm+ok@megatron.ietf.org; Sun, 25 Nov 2007 16:30:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwP3i-00052m-Mx for ancp@ietf.org; Sun, 25 Nov 2007 16:30:34 -0500 Received: from maile.telecomitalia.it ([156.54.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwP3d-00084l-Of for ancp@ietf.org; Sun, 25 Nov 2007 16:30:34 -0500 Received: from ptpxch010ba020.idc.cww.telecomitalia.it ([156.54.240.53]) by maile.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Sun, 25 Nov 2007 22:30:28 +0100 Received: from PTPEVS108BA020.idc.cww.telecomitalia.it ([156.54.241.228]) by ptpxch010ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Sun, 25 Nov 2007 22:30:27 +0100 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2929 Content-Class: urn:content-classes:message MIME-Version: 1.0 Importance: normal Priority: normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Introducing Mutlicast Grey-List (was RE: [ANCP] Comments ondraft-maglione) Date: Sun, 25 Nov 2007 22:26:02 +0100 Message-ID: <9E577E61D0108D4F8CD482029B613F5C01A7CF5F@PTPEVS108BA020.idc.cww.telecomitalia.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Introducing Mutlicast Grey-List (was RE: [ANCP] Comments ondraft-maglione) thread-index: AcfNPesp0+998lMLS6y94SJ58ITZqQA3eI51F+FoAgAADtulYABzOvMF References: <8C253CB7-CF45-431D-94B6-4AC1A1653524@cisco.com> <9E577E61D0108D4F8CD482029B613F5C0181BF87@PTPEVS108BA020.idc.cww.telecomitalia.it> <8144761F31F48D43AD53D09F5350E38002069337@FRVELSMBS22.ad2.ad.alcatel.com> From: "Maglione Roberta" To: "OOGHE Sven" , X-OriginalArrivalTime: 25 Nov 2007 21:30:27.0321 (UTC) FILETIME=[65759690:01C82FAA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3dc828214e948ff35b815af10e94a823 Cc: Michel Platnic , Ullio Mario 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 Sven, thanks for your comments; your point makes sense to me, "accept as best effort" is a valid option = for default behavior. The basic idea for the default action is to avoid query the NAS for all=20 multicast flows that do not match any list: the reason why we selected = drop as the default behavior for unconfigured multicast flows=20 is in order to be consistent with the typical ACL behavior,=20 and also because this seemed to be the preferred action=20 according to the discussion we had in Chicago and on the mailing list,=20 but I open to modify the default behavior, according to Working group feedback.=20 Regards, Roberta =20 -----Original Message----- From: OOGHE Sven [mailto:Sven.Ooghe@alcatel-lucent.be] Sent: Fri 11/23/2007 5:16 PM To: Maglione Roberta; ancp@ietf.org Cc: Ullio Mario; Michel Platnic Subject: RE: Introducing Mutlicast Grey-List (was RE: [ANCP] Comments = ondraft-maglione) =20 Hello Roberta, Thinking a bit further about the default behavior, I am not sure that dropping would be the right approach. (cf. "If a Join message is received by AN for a flow which is not on any list, then it is rejected") Imagine any multicast flow out there on the Internet (e.g. Internet TV), then if it is not configured on the Access Node, it will be rejected. I don't think this is what an end-user would want. Instead, I would argue that if the flow is not part of any of the lists, that the behavior would be to accept it as best effort, i.e. accept without further admission control checks. What do you think? Regards, Sven =20 -----Original Message----- From: Maglione Roberta [mailto:roberta.maglione@telecomitalia.it]=20 Sent: vrijdag 23 november 2007 8:36 To: ancp@ietf.org Cc: Ullio Mario; Michel Platnic Subject: Introducing Mutlicast Grey-List (was RE: [ANCP] Comments ondraft-maglione) Hello, as we discussed during Chicago meeting below is a proposal for modification to the text of draft-ietf-ancp-framework-04.txt in order to introduce Multicast Grey List and leave Black List (i.e. deny) as default behavior.=20 We'd appreciate feedback. Regards, Roberta Section 3.4.1 Replace: " Provisioning the conditional access information on the AN can be done using a "White list" and/or a "Black list". A White list associated with an Access Port identifies the multicast flows that are allowed to be replicated to that port. A Black list associated with an Access Port identifies the multicast flows that are not allowed to be replicated to that port." By: " Provisioning the conditional access information on the AN can be done using a "White list", "Grey list", and/or a "Black list". A White list associated with an Access Port identifies the multicast flows that are allowed to be replicated to that port. A Black list associated with an Access Port identifies the multicast flows that are not allowed to be replicated to that port. A Grey list associated with an Access Port identifies the multicast flows for which the AN on receiving a Join message, before starting traffic replication queries NAS for further authorization.=20 Each list contains zero, one or multiple entries and each entry may specify a single flow or contain ranges (i.e. mask on Group address and/or mask on Source address).=20 Replace: "Upon receiving a join message on an Access Port, the Access Node will first check if the requested multicast flow is part of a White list or a Black list associated with that Access Port. If it is part of a White list, the AN can autonomously start replicating multicast traffic. If it is part of a Black list, the AN can autonomously discard the message because the request is not authorized"=20 By: "Upon receiving a join message on an Access Port, the Access Node will first check if the requested multicast flow is part of a White, Grey or a Black list associated with that Access Port. If it is part of a White list, the AN can autonomously start replicating multicast traffic. If it is part of a Black list, the AN can autonomously discard the message because the request is not authorized. If it is part of a Grey list the AN uses ANCP to query the NAS, that in turn will respond to the AN indicating whether the join is to be honored (and hence replication performed by the AN) or denied (and hence replication not performed by the AN.) If a Join message is received by AN for a flow which is not on any list, then it is rejected (i.e. the default behavior is to drop such messages.) If a join is received by AN for a flow that matches multiple lists, then a deterministic algorithm (to be specified in ancp-protocol) is used by the AN to decide which list behavior takes precedence. Following are some example scenarios: Scenario 1: * no config: =3D=3D> any Join message gets rejected by AN Scenario 2: * White List =3D { , , ... = } =3D=3D> Join ( S=3D*,G=3DGi) gets honored by AN ( 1<=3Di<=3Dn ) =3D=3D> everything else gets rejected by AN Scenario 3: * White List =3D { , , ... = } * Grey List =3D { } m>n =3D=3D> Join ( S=3D*,G=3DGi) gets honored by AN ( 1<=3Di<=3Dn ) =3D=3D> Join ( S=3Ds,G=3DGm) triggers ANCP Admission Request to NAS =3D=3D> everything else gets rejected by AN Section 3.4.2 Replace: " One approach is for the AN to query the NAS so that both unicast and multicast CAC for the access line are performed by the NAS. In this case, the AN can use ANCP to query the NAS, that in turn performs multicast CAC and responds to the AN indicating whether the join is to be honored (and hence replication performed by the AN) or denied. In the process, the NAS may communicate with a Policy Server.=20 " With: " One approach is for the AN to query the NAS so that both unicast and multicast CAC for the access line are performed by the NAS. In this case, upon receiving a join to a multicast flow which matches the Grey List, the AN can use ANCP to query the NAS, that in turn performs multicast CAC and responds to the AN indicating whether the join is to be honored (and hence replication performed by the AN) or denied. In the process, the NAS may communicate with a Policy Server.=20 Section 4.2 Replace " The ANCP MUST support providing multicast conditional access information to Access Ports on an Access Node, using Black lists and White lists. " By " The ANCP MUST support providing multicast conditional access information to Access Ports on an Access Node, using Black, Grey and White lists. " Replace "The ANCP MUST support binding a particular Black list and White List to a given Access Port" By: " The ANCP MUST support binding a particular Black, Grey and White List to a given Access Port " Replace: The ANCP MUST support partial updates of the White lists and Black lists. by The ANCP MUST support partial updates of the White, Grey and Black lists. Replace: The ANCP MUST allow the AN to query the NAS to request an admission decision for replicating a multicast flow to a particular Access Port. By Upon receiving a join to a multicast flow which matches the Grey List the ANCP MUST allow the AN to query the NAS to request an admission decision for replicating that multicast flow to a particular Access Port. Section 4.7.6 Replace and split in two " Upon receiving a join to a multicast flow which does not match any entry in the Black List nor in the White List for a specific Access Port, the AN must support using ANCP to query the NAS to receive a response indicating whether that join is to be honored or denied." By: " Upon receiving a join to a multicast flow which matches the Grey List for a specific Access Port, the AN must support using ANCP to query the NAS to receive a response indicating whether that join is to be honored or denied. " " The AN must deny any join to a multicast flow that does not match any entry in the Black List nor in the White List nor Grey List for the relevant Access Port" Adding the following requirements: "Upon receiving a join to a multicast flow which matches the Grey List, AN is not allowed to propagate that join request, before the successful authorization from the NAS is received." "Upon receiving a leave to a multicast flow which matches the Grey List, AN SHOULD be able to autonomously stop replication and SHOULD be able to advertise this event to the NAS."=20 Section 4.8.6 Adding: The NAS MUST support using ANCP to incrementally add, remove and modify individual entries in White, Black and Grey lists. ------------------------------------------------------- Roberta Maglione - CCIE #18425 Telecom Italia Broadband Network Services Innovation ------------------------------------------------------- ________________________________________ From: Michel Platnic [mailto:Michel.Platnic@ecitele.com] Sent: Tuesday, July 24, 2007 8:22 PM To: Francois Le Faucheur IMAP Cc: Garofalo Angelo; ancp@ietf.org Subject: RE: [ANCP] Comments on draft-maglione Hi Francois, Please see my comments inline, Regards, Michel. =20 ________________________________________ From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com] Sent: Mon 7/23/2007 6:23 PM To: Michel Platnic Cc: Francois Le Faucheur IMAP; OOGHE Sven; ancp@ietf.org; angelo.garofalo@telecomitalia.it Subject: Re: [ANCP] Comments on draft-maglione Hi Michel,=20 =20 Using access control capabilities within the access network provides the two main following benefits: - refrain from sending any content to a customer that was not paid for (mostly relevant when Encryption is not used) - provides a filter against end-user applications/hackers that may send IGMP requests with invalid IP address =20 A solution where all the IP addresses that are not part of either the Black-list or the White-List are sent to a central policy server for authorization gives me some concerns regarding the robustness of the whole system. Same concern regarding the treatment of unknown IP source addresses ('Everything else'). Agreed. We had these concerns in mind also. This is why the Black-Lists and White-Lists include the ability to define arbitrarily large ranges/masks. In particular, as an example, one can easily define a Black-List which contains a single "catch-all" entry that matches any Multicast address & Source. Then you can define a White-List with the explicit channels you want to allow. This effectively implements a policy whereby everything is blocked by AN, except the channels that have been explicitly allowed in the White-List. In other words, the Black-List can be used for explicit listing of channels, or it can easily be used as a "catch-all" (for all, or for arbitrarily large ranges of channels). This should address your concern of making sure that the "default" behavior for any non-explicitly defined channel is not to query NAS/Central_server. See in draft-maglione: " The White List and Black List can contain entries allowing: o an exact match for a (*,G) ASM group (e.g. )=20 o an exact match for a (S,G) SSM channel (e.g. = o a mask-based range match for a (*,G) ASM group (e.g.=20 )=20 o a mask-based range match for a (S,G) SSM channel (e.g.=20 " Let me try to rephrase your proposal; there would be a default state wherein any channel being neither part of White-list nor Black-list would be discarded.=20 If its the case I agree with you that this solution solves the security issue. =20 But what about when AN is not in this default state? If "Accept everything else" is used then again same problem of security is encountered, and any hacker or application can overload the policy server with requests.=20 To my understanding, the model proposed, where the NAS is getting the customer request for authorization, requires this mode of operation. So we still have the same problem. Did I miss anything? =20 =20 ________________________________________________________________________ ______ I understand that some applications may require sophisticated policy decision making and that, as a matter of fact, some AN/central policy server synchronization mechanism should to be proposed, but the solution must be Robust and Scalable. For now I am not convinced that solution proposed is either Robust or Scalable. Let us know if you have specific robustness/scalability concerns (beyond the one discussed above)? Then we could work together on addressing those.=20 =20 Well, there is still this scalable issue when duplicating the messages that need to be treated in real-time by the NAS. Sven already made some counting regarding this topic. I believe this point could lead to scalability issues. If we had the above described potential disaster, then we end-up getting serious Robustness issues. =20 Thanks Francois =20 Regards, Michel. -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to webmaster@telecomitalia.it. Thank you www.telecomitalia.it -------------------------------------------------------------------- =20 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons = above and may contain confidential information. If you have received the = message in error, be informed that any use of the content hereof is = prohibited. Please return it immediately to the sender and delete the = message. Should you have any questions, please contact us by replying to = webmaster@telecomitalia.it. Thank you www.telecomitalia.it -------------------------------------------------------------------- =20 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Mon Nov 26 03:34:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwZQH-0004j6-Ab; Mon, 26 Nov 2007 03:34:33 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IwZQF-0004il-Om for ancp-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 03:34:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwZQA-0004iK-En for ancp@ietf.org; Mon, 26 Nov 2007 03:34:26 -0500 Received: from smail5.alcatel.fr ([64.208.49.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwZQ2-000733-Ej for ancp@ietf.org; Mon, 26 Nov 2007 03:34:26 -0500 Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.ad2.ad.alcatel.com [155.132.6.78]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id lAQ8Wl5o005789; Mon, 26 Nov 2007 09:32:47 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.52]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 26 Nov 2007 09:34:15 +0100 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: Spontaneous Admission Response (was Re: [ANCP] ANCP WG follow-up) Date: Mon, 26 Nov 2007 09:34:14 +0100 Message-ID: <8144761F31F48D43AD53D09F5350E380020695B0@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Spontaneous Admission Response (was Re: [ANCP] ANCP WG follow-up) Thread-Index: AcgtD1sTSERtF6XYRWuORG2ykjk3RgC8pgLQ References: <9BD5D7887235424FA97DFC223CAE3C2803B76378@proton.jnpr.net><54469D09-60CF-4AE8-8BAD-A26B9E256113@cisco.com> From: "OOGHE Sven" To: "Francois Le Faucheur IMAP" , , "Maglione Roberta" X-OriginalArrivalTime: 26 Nov 2007 08:34:15.0780 (UTC) FILETIME=[21122240:01C83007] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Cc: 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 Francois, I agree with most of the changes, except one. If I recall correctly, the idea behind the proposed changes below is to have a scenario where the Access Node performs replication, but doesn't perform IGMP processing. In other words, all IGMP report messages (and likely also all IGMP leave messages) are sent to the NAS; the NAS instructs the Access Node how to perform the replication by means of ANCP messages. On the other hand, the thread issued by Roberta highlights the need to have mechanisms in place that offload the NAS from having to perform excessive IGMP and/or ANCP processing. This is done by introducing a default behavior, guided by filtering lists in the Access Node. In this solution, the Access Node performs IGMP processing and decides whether or not to send ANCP messages to the NAS. I agree with Roberta that a default behavior is in order. So I believe that IGMP report/leave processing in the Access Node is also a requirement to achieve a default behavior. Therefore, I would not add the new paragraph in section 3.4.4. Some more feedback is inline. -----Original Message----- From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com]=20 Sent: donderdag 22 november 2007 14:55 To: Francois Le Faucheur IMAP Cc: ancp@ietf.org Subject: Spontaneous Admission Response (was Re: [ANCP] ANCP WG follow-up) Hello, On 19 Sep 2007, at 15:56, Francois Le Faucheur IMAP wrote: > Sanjay and all, > > 2) you raise a valid point that there are ANCP deployment variations=20 > whereby the replication on AN may be controlled by NAS via ANCP, but=20 > where the "join/leave" information may not be conveyed to NAS via=20 > ANCP. I agree the ANCP solution should allow this. We will work on a=20 > revised proposal allowing this. > > Francois As agreed above, below is a proposal for modification to the text of draft-ietf-ancp-framework-04.txt in order to accommodate ANCP deployment models where the "join/leave" information may not be conveyed to NAS via ANCP. We'd appreciate feedback. Thanks Francois In section 3.4.4: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Replace: " 3.4.4. Multicast Termination" by: " 3.4.4. Spontaneous Admission Response" In second paragraph, replace: "This can be done with the Admission Response message." by "This can be achieved by the NAS sending a spontaneous Admission Response message (ie sent by NAS without prior receipt of a corresponding Admission Request)." I am ok with the paragraph text change, but would keep the title as-is. At the end of 3.4.4: add a new paragraph: "In some deployment scenarios, the NAS may be made aware of end-users requests to join/leave a multicast flow by other means than ANCP Admission Requests sent by the AN (for example, the IGMP join/leave from the end-user might be somehow tunneled to the NAS). In such environments, the NAS can still control multicast replication to be performed by the AN via ANCP through the use of spontaneous Admission Responses (ie sent by NAS without prior receipt of a corresponding Admission Request)." See above, I don't see a need for these changes. In section 4.2: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D replace: " o The ANCP MUST allow the AN to query the NAS to request an admission decision for replicating a multicast flow to a particular Access Port." by " o The ANCP MUST allow the AN to send an Admission Request to the =20 NAS to request an admission decision for replicating a multicast flow to a particular Access Port." I am ok with this change. replace: " o The ANCP MUST allow the NAS to send an admission decision to the AN indicating whether or not a multicast flow may be replicated to a particular Access Port." by " o The ANCP MUST allow the NAS to send an Admission Response to the AN (e.g. indicating whether or not a multicast flow is to be replicated to a particular Access Port). I am ok with this change. o The ANCP MUST allow the NAS to send such an Admission Response either in response to an Admission Request received from the AN or spontaneously (i.e. without having received a corresponding Admission Request from AN). o In particular, the ANCP MUST allow the NAS to send such an Admission Response in order to revoke a decision to replicate a multicast flow to a particular Access Port, that had been conveyed earlier to an AN. I would reword the above two bullets to: o The ANCP MUST allow the NAS to send the Admission Response in response to an Admission Request received from the AN o The ANCP MUST allow the NAS to send the Admission Response spontaneously (i.e. without having received a corresponding Admission Request from AN) in order to revoke a decision to replicate a multicast flow to a particular Access Port, that had been conveyed earlier to an AN. o The ANCP MUST allow the AN to notify the NAS of the outcome (success/failure) of a join/leave instruction conveyed in an Admission Response from the NAS. " I am ok with this addition replace: " o The ANCP MUST allow the NAS, when replying to an AN request, to OPTIONALLY convey information on multiple multicast flows sharing the same conditional access rules. This allows the AN to take autonomous decisions for these flows later on." by: " o The ANCP MUST allow the NAS, when sending an Admission =20 Response, to OPTIONALLY convey information on multiple multicast flows sharing the same conditional access and admission control rules. This allows the AN to take autonomous decisions for these flows later on." I am ok with this change delete (this has been replaced by an equivalent requirement above)" " o The ANCP MUST allow the NAS to revoke a decision to replicate a multicast flow to a particular Access Port, which had been conveyed earlier to an AN." I am ok with this removal Regards, Sven _______________________________________________ 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 Mon Nov 26 04:08:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwZxW-0000Yz-1U; Mon, 26 Nov 2007 04:08:54 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IwZxU-0000Yu-UE for ancp-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 04:08:52 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwZxU-0000Ym-Eq for ancp@ietf.org; Mon, 26 Nov 2007 04:08:52 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwZxS-0002uB-DM for ancp@ietf.org; Mon, 26 Nov 2007 04:08:52 -0500 X-IronPort-AV: E=Sophos;i="4.21,466,1188770400"; d="scan'208";a="158742378" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 26 Nov 2007 10:08:41 +0100 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 lAQ98f1M019116; Mon, 26 Nov 2007 10:08:41 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAQ98RZf008612; Mon, 26 Nov 2007 09:08:36 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 10:08:31 +0100 Received: from [10.0.0.19] ([10.61.80.1]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 10:08:30 +0100 In-Reply-To: <9E577E61D0108D4F8CD482029B613F5C01A7CF5F@PTPEVS108BA020.idc.cww.telecomitalia.it> References: <8C253CB7-CF45-431D-94B6-4AC1A1653524@cisco.com> <9E577E61D0108D4F8CD482029B613F5C0181BF87@PTPEVS108BA020.idc.cww.telecomitalia.it> <8144761F31F48D43AD53D09F5350E38002069337@FRVELSMBS22.ad2.ad.alcatel.com> <9E577E61D0108D4F8CD482029B613F5C01A7CF5F@PTPEVS108BA020.idc.cww.telecomitalia.it> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Francois Le Faucheur IMAP Subject: Re: Introducing Mutlicast Grey-List (was RE: [ANCP] Comments ondraft-maglione) Date: Mon, 26 Nov 2007 10:08:25 +0100 To: Maglione Roberta , OOGHE Sven X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 26 Nov 2007 09:08:30.0227 (UTC) FILETIME=[E99DDE30:01C8300B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=17554; t=1196068121; x=1196932121; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Re=3A=20Introducing=20Mutlicast=20Grey-List=20(was=20RE=3A=20 [ANCP]=20Comments=20ondraft-maglione) |Sender:=20; bh=YoHOEY9yc31TXcHAvCwkuOCTCxJ3UKY1kD2zmpF/Wwk=; b=WqeaQ0uFjxakZjr0eLT+Z9wsYKAp/8CVf7pl2OVjz5t5i3lwfacWtSNZ7pj1PNLSlKxXL8fa v6b3/KaQsZTRpXnFoeQddIIv/McZjXzDm/n8YiAFWjaMWCOKeV8yiVBX; Authentication-Results: ams-dkim-1; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f3b9db08b8c0fe2301a77f547096e31 Cc: Ullio Mario , ancp@ietf.org, Michel Platnic 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 Roberta, Sven, and all, It is worth noting that Roberta's proposal below allows the behavior described by Sven with very trivial extra config: simply add one "catch-all" entry () in the White List. Then any flow that doesn't match the Black or Grey list will be accepted by AN. For example, we could add: Scenario 4: * White-List = { } ==> any Join message gets accepted by AN Scenario 5: * White-List = { } * Black-List = { , , ... } ==> Join ( S=*,G=Gi) gets rejected by AN ( 1<=i<=n ) ==> everything else gets accepted by AN So the choice is between: * "Black-Default": proposal below where: - Default ==> everything that doesn't match Black/Grey gets blocked - add a single-entry catch-all in White-List==> everything that doesn't match Black/Grey gets accepted * "White-Default": modified proposal where: - Default ==> everything that doesn't match Black/Grey gets accepted - add a single-entry catch-all in Black-List==> everything that doesn't match Black/Grey gets blocked Both proposals can easily achieve both required behaviors (ie "block if doesn't match" _and_ "accept if doesn't match"). The only difference is about whether you need to add the single catch-all entry or not to achieve your favorite behavior. From previous discussion on that topic, it sounded to me like several folks were more comfortable with the conservative side (ie if there has not been a conscious decision to allow a flow, then better block it; it is easy enough to explicitly "allow-all" if operator is so inclined). So considering the above ... what do people prefer? Perhaps we could also poll the WG in Vancouver on that topic. Francois On 25 Nov 2007, at 22:26, Maglione Roberta wrote: > Hi Sven, > thanks for your comments; > your point makes sense to me, "accept as best effort" is a valid > option for default behavior. > The basic idea for the default action is to avoid query the NAS for > all > multicast flows that do not match any list: the reason why we > selected > drop as the default behavior for unconfigured multicast flows > is in order to be consistent with the typical ACL behavior, > and also because this seemed to be the preferred action > according to the discussion we had in Chicago and on the mailing list, > but I open to modify the default behavior, according to Working group > feedback. > > Regards, > Roberta > > > -----Original Message----- > From: OOGHE Sven [mailto:Sven.Ooghe@alcatel-lucent.be] > Sent: Fri 11/23/2007 5:16 PM > To: Maglione Roberta; ancp@ietf.org > Cc: Ullio Mario; Michel Platnic > Subject: RE: Introducing Mutlicast Grey-List (was RE: [ANCP] > Comments ondraft-maglione) > > Hello Roberta, > > Thinking a bit further about the default behavior, I am not sure that > dropping would be the right approach. (cf. "If a Join message is > received by AN for a flow which is not on any list, then it is > rejected") > > Imagine any multicast flow out there on the Internet (e.g. Internet > TV), > then if it is not configured on the Access Node, it will be > rejected. I > don't think this is what an end-user would want. > > Instead, I would argue that if the flow is not part of any of the > lists, > that the behavior would be to accept it as best effort, i.e. accept > without further admission control checks. > > What do you think? > > Regards, > Sven > > > -----Original Message----- > From: Maglione Roberta [mailto:roberta.maglione@telecomitalia.it] > Sent: vrijdag 23 november 2007 8:36 > To: ancp@ietf.org > Cc: Ullio Mario; Michel Platnic > Subject: Introducing Mutlicast Grey-List (was RE: [ANCP] Comments > ondraft-maglione) > > Hello, > as we discussed during Chicago meeting below is a proposal for > modification to the text of draft-ietf-ancp-framework-04.txt in > order to > introduce Multicast Grey List and leave Black List (i.e. deny) as > default behavior. > We'd appreciate feedback. > > Regards, > Roberta > > > Section 3.4.1 > Replace: > " Provisioning the conditional access information on the AN can be > done > using a "White list" and/or a "Black list". > A White list associated with an Access Port identifies the multicast > flows that are allowed to be replicated to that port. A Black list > associated with an Access Port identifies the multicast flows that are > not allowed to be replicated to that port." > > By: > " Provisioning the conditional access information on the AN can be > done > using a "White list", "Grey list", and/or a "Black list". A White > list > associated with an Access Port identifies the multicast flows that are > allowed to be replicated to that port. A Black list associated > with an > Access Port identifies the multicast flows that are not allowed to be > replicated to that port. A Grey list associated with an Access Port > identifies the multicast flows for which the AN on receiving a Join > message, before starting traffic replication queries NAS for further > authorization. > Each list contains zero, one or multiple entries and each entry may > specify a single flow or contain ranges (i.e. mask on Group address > and/or mask on Source address). > > > Replace: > "Upon receiving a join message on an Access Port, the Access Node will > first check if the requested multicast flow is part of a White list > or a > Black list associated with that Access Port. If it is part of a White > list, the AN can autonomously start replicating multicast > traffic. If > it is part of a Black list, the AN can autonomously discard the > message > because the request is not authorized" > > By: > > "Upon receiving a join message on an Access Port, the Access Node will > first check if the requested multicast flow is part of a White, > Grey or > a Black list associated with that Access Port. If it is part of a > White > list, the AN can autonomously start replicating multicast traffic. If > it is part of a Black list, the AN can autonomously discard the > message > because the request is not authorized. If it is part of a Grey list > the > AN uses ANCP to query the NAS, that in turn will respond to the AN > indicating whether the join is to be honored (and hence replication > performed by the AN) or denied (and hence replication not performed by > the AN.) If a Join message is received by AN for a flow which is > not on > any list, then it is rejected (i.e. the default behavior is to drop > such > messages.) If a join is received by AN for a flow that matches > multiple > lists, then a deterministic algorithm (to be specified in ancp- > protocol) > is used by the AN to decide which list behavior takes precedence. > Following are some example scenarios: > > Scenario 1: > * no config: > ==> any Join message gets rejected by AN > > Scenario 2: > * White List = { , , ... } > ==> Join ( S=*,G=Gi) gets honored by AN ( 1<=i<=n ) > ==> everything else gets rejected by AN > > Scenario 3: > * White List = { , , ... } > * Grey List = { } m>n > ==> Join ( S=*,G=Gi) gets honored by AN ( 1<=i<=n ) > ==> Join ( S=s,G=Gm) triggers ANCP Admission Request to NAS > ==> everything else gets rejected by AN > > > Section 3.4.2 > > Replace: > " One approach is for the AN to query the NAS so that both unicast > and multicast CAC for the access line are performed by the NAS. > In this case, the AN can use ANCP to query the NAS, that in turn > performs multicast CAC and responds to the AN indicating whether > the join is to be honored (and hence replication performed by > the > AN) or denied. In the process, the NAS may communicate with a > Policy Server. > " > With: > " One approach is for the AN to query the NAS so that both unicast > and multicast CAC for the access line are performed by the NAS. > In this case, upon receiving a join to a multicast flow which > matches the Grey List, the AN can use ANCP to query the NAS, that in > turn > performs multicast CAC and responds to the AN indicating whether > the join is to be honored (and hence replication performed by > the > AN) or denied. In the process, the NAS may communicate with a > Policy Server. > > > Section 4.2 > Replace > " The ANCP MUST support providing multicast conditional access > information to Access Ports on an Access Node, using Black lists > and White lists. " > By > " The ANCP MUST support providing multicast conditional access > information to Access Ports on an Access Node, using Black, Grey > and White lists. " > > Replace > > "The ANCP MUST support binding a particular Black list and White > List to a given Access Port" > By: > > " The ANCP MUST support binding a particular Black, Grey and White > List to a given Access Port > " > Replace: > > The ANCP MUST support partial updates of the White lists and Black > lists. > by > The ANCP MUST support partial updates of the White, Grey and Black > lists. > > Replace: > The ANCP MUST allow the AN to query the NAS to request an > admission decision for replicating a multicast flow to a > particular Access Port. > > By > Upon receiving a join to a multicast flow which matches the Grey List > the ANCP MUST allow the AN to query the NAS to request an admission > decision for replicating that multicast flow to a particular Access > Port. > > > > Section 4.7.6 > Replace and split in two > > " Upon receiving a join to a multicast flow which does not match any > entry in the Black List nor in the White List for a specific > Access Port, the AN must support using ANCP to query the NAS to > receive a response indicating whether that join is to be honored > or denied." > > By: > > " Upon receiving a join to a multicast flow which matches the Grey > List > for a specific Access Port, the AN must support using ANCP to > query the > NAS to receive a response indicating whether that join is to be > honored > or denied. > " > " The AN must deny any join to a multicast flow that does not match > any > entry in the Black List nor in the White List nor Grey List for > the relevant Access Port" > > > Adding the following requirements: > > "Upon receiving a join to a multicast flow which matches the Grey > List, > AN is not allowed to propagate that join request, before the > successful > authorization from the NAS is received." > > "Upon receiving a leave to a multicast flow which matches the Grey > List, > AN SHOULD be able to autonomously stop replication and SHOULD be > able to > advertise this event to the NAS." > > > Section 4.8.6 > Adding: > The NAS MUST support using ANCP to incrementally add, remove and > modify > individual entries in White, Black and Grey lists. > > > ------------------------------------------------------- > Roberta Maglione - CCIE #18425 > Telecom Italia > Broadband Network Services Innovation > ------------------------------------------------------- > ________________________________________ > From: Michel Platnic [mailto:Michel.Platnic@ecitele.com] > Sent: Tuesday, July 24, 2007 8:22 PM > To: Francois Le Faucheur IMAP > Cc: Garofalo Angelo; ancp@ietf.org > Subject: RE: [ANCP] Comments on draft-maglione > > Hi Francois, > Please see my comments inline, > Regards, > Michel. > > > ________________________________________ > From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com] > Sent: Mon 7/23/2007 6:23 PM > To: Michel Platnic > Cc: Francois Le Faucheur IMAP; OOGHE Sven; ancp@ietf.org; > angelo.garofalo@telecomitalia.it > Subject: Re: [ANCP] Comments on draft-maglione Hi Michel, > > > > Using access control capabilities within the access network > provides the two main following benefits: > - refrain from sending any content to a customer that was not paid for > (mostly relevant when Encryption is not used) > - provides a filter against end-user applications/hackers that may > send > IGMP requests with invalid IP address > > A solution where all the IP addresses that are not part of either the > Black-list or the White-List are sent to a central policy server for > authorization gives me some concerns regarding the robustness of the > whole system. Same concern regarding the treatment of unknown IP > source > addresses ('Everything else'). > > Agreed. We had these concerns in mind also. This is why the Black- > Lists > and White-Lists include the ability to define arbitrarily large > ranges/masks. In particular, as an example, one can easily define a > Black-List which contains a single "catch-all" entry that matches any > Multicast address & Source. Then you can define a White-List with the > explicit channels you want to allow. This effectively implements a > policy whereby everything is blocked by AN, except the channels that > have been explicitly allowed in the White-List. > In other words, the Black-List can be used for explicit listing of > channels, or it can easily be used as a "catch-all" (for all, or for > arbitrarily large ranges of channels). > > This should address your concern of making sure that the "default" > behavior for any non-explicitly defined channel is not to query > NAS/Central_server. > > See in draft-maglione: > " > The White List and Black List can contain entries allowing: > o an exact match for a (*,G) ASM group (e.g. ) > o an exact match for a (S,G) SSM channel (e.g. > > > o a mask-based range match for a (*,G) ASM group (e.g. > ) > o a mask-based range match for a (S,G) SSM channel (e.g. > > " > Let me try to rephrase your proposal; there would be a > default > state wherein any channel being neither part of White-list nor > Black-list would be discarded. > If its the case I agree with you that this solution solves the > security > issue. > > But what about when AN is not in this default state? > If "Accept everything else" is used then again same problem of > security > is encountered, and any hacker or application can overload the policy > server with requests. > To my understanding, the model proposed, where the NAS is getting the > customer request for authorization, requires this mode of operation. > So we still have the same problem. > Did I miss anything? > > > ______________________________________________________________________ > __ > ______ > I understand that some applications may require sophisticated policy > decision making and that, as a matter of fact, some AN/central policy > server synchronization mechanism should to be proposed, but the > solution > must be Robust and Scalable. > For now I am not convinced that solution proposed is either Robust or > Scalable. > > Let us know if you have specific robustness/scalability concerns > (beyond > the one discussed above)? > Then we could work together on addressing those. > > Well, there is still this scalable issue when duplicating > the > messages that need to be treated in real-time by the NAS. Sven already > made some counting regarding this topic. I believe this point could > lead > to scalability issues. If we had the above described potential > disaster, > then we end-up getting serious Robustness issues. > > > Thanks > > Francois > > > Regards, > Michel. > -------------------------------------------------------------------- > > CONFIDENTIALITY NOTICE > > This message and its attachments are addressed solely to the persons > above and may contain confidential information. If you have > received the > message in error, be informed that any use of the content hereof is > prohibited. Please return it immediately to the sender and delete the > message. Should you have any questions, please contact us by > replying to > webmaster@telecomitalia.it. > > Thank you > > www.telecomitalia.it > > -------------------------------------------------------------------- > > > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www1.ietf.org/mailman/listinfo/ancp > > -------------------------------------------------------------------- > > CONFIDENTIALITY NOTICE > > This message and its attachments are addressed solely to the > persons above and may contain confidential information. If you have > received the message in error, be informed that any use of the > content hereof is prohibited. Please return it immediately to the > sender and delete the message. Should you have any questions, > please contact us by replying to webmaster@telecomitalia.it. > > Thank you > > www.telecomitalia.it > > -------------------------------------------------------------------- > > > > _______________________________________________ > 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 Mon Nov 26 04:32:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwaKb-0002S3-9K; Mon, 26 Nov 2007 04:32:45 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IwaKZ-0002Rm-GT for ancp-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 04:32:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwaKZ-0002Re-4a for ancp@ietf.org; Mon, 26 Nov 2007 04:32:43 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwaKY-0003Qq-0o for ancp@ietf.org; Mon, 26 Nov 2007 04:32:43 -0500 X-IronPort-AV: E=Sophos;i="4.21,466,1188770400"; d="scan'208";a="158745834" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 26 Nov 2007 10:32:41 +0100 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 lAQ9WfQ1027725; Mon, 26 Nov 2007 10:32:41 +0100 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 lAQ9W3a3018462; Mon, 26 Nov 2007 09:32:41 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); Mon, 26 Nov 2007 10:32:36 +0100 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: Spontaneous Admission Response (was Re: [ANCP] ANCP WG follow-up) Date: Mon, 26 Nov 2007 10:32:30 +0100 Message-ID: In-Reply-To: <8144761F31F48D43AD53D09F5350E380020695B0@FRVELSMBS22.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Spontaneous Admission Response (was Re: [ANCP] ANCP WG follow-up) Thread-Index: AcgtD1sTSERtF6XYRWuORG2ykjk3RgC8pgLQAAMVzNA= References: <9BD5D7887235424FA97DFC223CAE3C2803B76378@proton.jnpr.net><54469D09-60CF-4AE8-8BAD-A26B9E256113@cisco.com> <8144761F31F48D43AD53D09F5350E380020695B0@FRVELSMBS22.ad2.ad.alcatel.com> From: "Wojciech Dec (wdec)" To: "OOGHE Sven" , "Francois Le Faucheur (flefauch)" , , "Maglione Roberta" X-OriginalArrivalTime: 26 Nov 2007 09:32:36.0335 (UTC) FILETIME=[47906FF0:01C8300F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7813; t=1196069561; x=1196933561; 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=20Spontaneous=20Admission=20Response=20(was=20Re=3A=20[ ANCP]=20ANCP=20WG=20follow-up) |Sender:=20; bh=vqcsLvNYtxSppHyu0kObTCaO2reOX5AXWNC5/wy969E=; b=ZCFXlH8HIH09Q/4PrIlXuKlMAH4SHwy7meRnw+ZhrB/Id0Z4y3Oi6GY8e8ALvbeG7Vf3bAry 6S1h/dVNUB+kAkyE6RQxo2FF/O8RyiHRcivnqGLwPRE6iZeNLf8taNoM; 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: 17e5edc4dfd335965c1d21372171c01c Cc: 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 Sven, just an observation; the current text in Section 3.4.4 does not quite reflect IMO the outcome of the discussion that's been had on the alias, and hence there is Francois' proposal to modify Section 3.4.4 in order to allow both spontaneous joins and leaves. Perhaps then, instead of changing Section 3.4.4 we could create a new section which covers explicitly the spontaneous join/leave case and includes the proposed changes? Regards, Woj.=20 > -----Original Message----- > From: OOGHE Sven [mailto:Sven.Ooghe@alcatel-lucent.be]=20 > Sent: 26 November 2007 09:34 > To: Francois Le Faucheur (flefauch); ancp@ietf.org; Maglione Roberta > Subject: RE: Spontaneous Admission Response (was Re: [ANCP]=20 > ANCP WG follow-up) >=20 > Hi Francois, >=20 > I agree with most of the changes, except one. >=20 > If I recall correctly, the idea behind the proposed changes=20 > below is to have a scenario where the Access Node performs=20 > replication, but doesn't perform IGMP processing. In other=20 > words, all IGMP report messages (and likely also all IGMP=20 > leave messages) are sent to the NAS; the NAS instructs the=20 > Access Node how to perform the replication by means of ANCP messages. >=20 > On the other hand, the thread issued by Roberta highlights=20 > the need to have mechanisms in place that offload the NAS=20 > from having to perform excessive IGMP and/or ANCP processing.=20 > This is done by introducing a default behavior, guided by=20 > filtering lists in the Access Node. In this solution, the=20 > Access Node performs IGMP processing and decides whether or=20 > not to send ANCP messages to the NAS. >=20 > I agree with Roberta that a default behavior is in order. So=20 > I believe that IGMP report/leave processing in the Access=20 > Node is also a requirement to achieve a default behavior.=20 > Therefore, I would not add the new paragraph in section 3.4.4. >=20 > Some more feedback is inline. >=20 > -----Original Message----- > From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com] > Sent: donderdag 22 november 2007 14:55 > To: Francois Le Faucheur IMAP > Cc: ancp@ietf.org > Subject: Spontaneous Admission Response (was Re: [ANCP] ANCP WG > follow-up) >=20 > Hello, >=20 > On 19 Sep 2007, at 15:56, Francois Le Faucheur IMAP wrote: >=20 > > Sanjay and all, > > > >=20 > > 2) you raise a valid point that there are ANCP deployment > variations=20 > > whereby the replication on AN may be controlled by NAS via=20 > ANCP, but=20 > > where the "join/leave" information may not be conveyed to NAS via=20 > > ANCP. I agree the ANCP solution should allow this. We will=20 > work on a=20 > > revised proposal allowing this. > > > > Francois >=20 > As agreed above, below is a proposal for modification to the=20 > text of draft-ietf-ancp-framework-04.txt in order to=20 > accommodate ANCP deployment models where the "join/leave"=20 > information may not be conveyed to NAS via ANCP. > We'd appreciate feedback. > Thanks > Francois >=20 >=20 >=20 >=20 > In section 3.4.4: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Replace: > " 3.4.4. Multicast Termination" > by: > " 3.4.4. Spontaneous Admission Response" >=20 > In second paragraph, replace: > "This can be done with the Admission Response message." > by > "This can be achieved by the NAS sending a spontaneous Admission > Response message (ie sent by NAS without prior receipt of=20 > a corresponding Admission Request)." >=20 > I am ok with the paragraph text change, but would keep=20 > the title as-is. >=20 > At the end of 3.4.4: > add a new paragraph: > "In some deployment scenarios, the NAS may be made aware of=20 > end-users requests to join/leave a multicast flow by other=20 > means than ANCP Admission Requests sent by the AN (for=20 > example, the IGMP join/leave from the end-user might be=20 > somehow tunneled to the NAS). In such environments, the NAS=20 > can still control multicast replication to be performed by=20 > the AN via ANCP through the use of spontaneous Admission=20 > Responses (ie sent by NAS without prior receipt of a=20 > corresponding Admission Request)." >=20 > See above, I don't see a need for these changes. >=20 >=20 > In section 4.2: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > replace: > " o The ANCP MUST allow the AN to query the NAS to request an > admission decision for replicating a multicast flow to a > particular Access Port." > by > " o The ANCP MUST allow the AN to send an Admission=20 > Request to the =20 > NAS to request an > admission decision for replicating a multicast flow to=20 > a particular Access Port." >=20 > I am ok with this change. >=20 > replace: > " o The ANCP MUST allow the NAS to send an admission=20 > decision to the > AN indicating whether or not a multicast flow may be=20 > replicated to > a particular Access Port." > by > " o The ANCP MUST allow the NAS to send an Admission=20 > Response to the > AN (e.g. indicating whether or not a multicast flow is=20 > to be replicated to > a particular Access Port). >=20 > I am ok with this change. >=20 > o The ANCP MUST allow the NAS to send such an Admission=20 > Response either in response to an Admission Request received=20 > from the AN or spontaneously (i.e. without having received a=20 > corresponding Admission Request from AN). > o In particular, the ANCP MUST allow the NAS to send=20 > such an Admission Response in order to revoke a decision to=20 > replicate a > multicast flow to a particular Access Port, that had=20 > been conveyed earlier to an AN. >=20 > I would reword the above two bullets to: >=20 > o The ANCP MUST allow the NAS to send the Admission=20 > Response in response to an Admission Request received from the AN > o The ANCP MUST allow the NAS to send the Admission=20 > Response spontaneously (i.e. without having received a=20 > corresponding Admission Request from AN) in order to revoke a=20 > decision to replicate a multicast flow to a particular Access=20 > Port, that had been conveyed earlier to an AN. >=20 > >=20 > o The ANCP MUST allow the AN to notify the NAS of the outcome > (success/failure) of a join/leave instruction conveyed in an=20 > Admission Response from the NAS. > " >=20 > I am ok with this addition >=20 > replace: > " o The ANCP MUST allow the NAS, when replying to an AN request, to > OPTIONALLY convey information on multiple multicast=20 > flows sharing > the same conditional access rules. This allows the AN to take > autonomous decisions for these flows later on." > by: > " o The ANCP MUST allow the NAS, when sending an Admission =20 > Response, to > OPTIONALLY convey information on multiple multicast=20 > flows sharing > the same conditional access and admission control=20 > rules. This allows the AN to take > autonomous decisions for these flows later on." >=20 > I am ok with this change >=20 > delete (this has been replaced by an equivalent requirement above)" > " o The ANCP MUST allow the NAS to revoke a decision to replicate a > multicast flow to a particular Access Port, which had been > conveyed earlier to an AN." >=20 > I am ok with this removal >=20 > Regards, > Sven > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www1.ietf.org/mailman/listinfo/ancp >=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 Mon Nov 26 05:06:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwar3-0003Re-Q0; Mon, 26 Nov 2007 05:06:17 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1Iwar2-0003RZ-Cd for ancp-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 05:06:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwar1-0003RR-Rk for ancp@ietf.org; Mon, 26 Nov 2007 05:06:16 -0500 Received: from colt-na7.alcatel.fr ([62.23.212.7] helo=smail6.alcatel.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwaqt-00018O-I2 for ancp@ietf.org; Mon, 26 Nov 2007 05:06:15 -0500 Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.ad2.ad.alcatel.com [155.132.6.78]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id lAQA4b96010655; Mon, 26 Nov 2007 11:04:37 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.52]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 26 Nov 2007 11:06:03 +0100 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: Spontaneous Admission Response (was Re: [ANCP] ANCP WG follow-up) Date: Mon, 26 Nov 2007 11:06:02 +0100 Message-ID: <8144761F31F48D43AD53D09F5350E38002069770@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Spontaneous Admission Response (was Re: [ANCP] ANCP WG follow-up) Thread-Index: AcgtD1sTSERtF6XYRWuORG2ykjk3RgC8pgLQAAMVzNAAAK5sUA== References: <9BD5D7887235424FA97DFC223CAE3C2803B76378@proton.jnpr.net><54469D09-60CF-4AE8-8BAD-A26B9E256113@cisco.com> <8144761F31F48D43AD53D09F5350E380020695B0@FRVELSMBS22.ad2.ad.alcatel.com> From: "OOGHE Sven" To: "Wojciech Dec (wdec)" , "Francois Le Faucheur (flefauch)" , , "Maglione Roberta" X-OriginalArrivalTime: 26 Nov 2007 10:06:03.0589 (UTC) FILETIME=[F3FB1750:01C83013] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: 65bc4909d78e8b10349def623cf7a1d1 Cc: 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 Woj, >From what I can find on the email list, the proposed change to section 3.4.4 is related to the following remark from Sanjay (mid September 2007): "The option I alluded to is IGMP from RG to BNG, and replication on the AN. The replication state on the AN created/controlled via ANCP by BNG. An optimization could be optional transparent snooping of IGMP on the AN to act on IGMP reports for leave only (to implement "fast leave")." Now, with the recent discussion on white/black/grey list filtering in the Access Node, it seems the WG agrees on having mechanisms in place that reduce the IGMP/ANCP message load on the NAS. A scenario where all IGMP report messages are sent to the NAS is IMHO in contradiction to the WG's desire to reduce the NAS load. The Access Node needs to be able to process IGMP report and leave messages and filter them. Perhaps Sanjay can explain the scenario in a bit more detail? That way we can better understand the resulting message load. Regards, Sven -----Original Message----- From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Sent: maandag 26 november 2007 10:33 To: OOGHE Sven; Francois Le Faucheur (flefauch); ancp@ietf.org; Maglione Roberta Subject: RE: Spontaneous Admission Response (was Re: [ANCP] ANCP WG follow-up) Hi Sven, just an observation; the current text in Section 3.4.4 does not quite reflect IMO the outcome of the discussion that's been had on the alias, and hence there is Francois' proposal to modify Section 3.4.4 in order to allow both spontaneous joins and leaves. Perhaps then, instead of changing Section 3.4.4 we could create a new section which covers explicitly the spontaneous join/leave case and includes the proposed changes? Regards, Woj.=20 > -----Original Message----- > From: OOGHE Sven [mailto:Sven.Ooghe@alcatel-lucent.be] > Sent: 26 November 2007 09:34 > To: Francois Le Faucheur (flefauch); ancp@ietf.org; Maglione Roberta > Subject: RE: Spontaneous Admission Response (was Re: [ANCP] ANCP WG=20 > follow-up) >=20 > Hi Francois, >=20 > I agree with most of the changes, except one. >=20 > If I recall correctly, the idea behind the proposed changes below is=20 > to have a scenario where the Access Node performs replication, but=20 > doesn't perform IGMP processing. In other words, all IGMP report=20 > messages (and likely also all IGMP leave messages) are sent to the=20 > NAS; the NAS instructs the Access Node how to perform the replication=20 > by means of ANCP messages. >=20 > On the other hand, the thread issued by Roberta highlights the need to > have mechanisms in place that offload the NAS from having to perform=20 > excessive IGMP and/or ANCP processing. > This is done by introducing a default behavior, guided by filtering=20 > lists in the Access Node. In this solution, the Access Node performs=20 > IGMP processing and decides whether or not to send ANCP messages to=20 > the NAS. >=20 > I agree with Roberta that a default behavior is in order. So I believe > that IGMP report/leave processing in the Access Node is also a=20 > requirement to achieve a default behavior. > Therefore, I would not add the new paragraph in section 3.4.4. >=20 > Some more feedback is inline. >=20 > -----Original Message----- > From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com] > Sent: donderdag 22 november 2007 14:55 > To: Francois Le Faucheur IMAP > Cc: ancp@ietf.org > Subject: Spontaneous Admission Response (was Re: [ANCP] ANCP WG > follow-up) >=20 > Hello, >=20 > On 19 Sep 2007, at 15:56, Francois Le Faucheur IMAP wrote: >=20 > > Sanjay and all, > > > >=20 > > 2) you raise a valid point that there are ANCP deployment > variations > > whereby the replication on AN may be controlled by NAS via > ANCP, but > > where the "join/leave" information may not be conveyed to NAS via=20 > > ANCP. I agree the ANCP solution should allow this. We will > work on a > > revised proposal allowing this. > > > > Francois >=20 > As agreed above, below is a proposal for modification to the text of=20 > draft-ietf-ancp-framework-04.txt in order to accommodate ANCP=20 > deployment models where the "join/leave" > information may not be conveyed to NAS via ANCP. > We'd appreciate feedback. > Thanks > Francois >=20 >=20 >=20 >=20 > In section 3.4.4: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Replace: > " 3.4.4. Multicast Termination" > by: > " 3.4.4. Spontaneous Admission Response" >=20 > In second paragraph, replace: > "This can be done with the Admission Response message." > by > "This can be achieved by the NAS sending a spontaneous Admission > Response message (ie sent by NAS without prior receipt of a=20 > corresponding Admission Request)." >=20 > I am ok with the paragraph text change, but would keep the=20 > title as-is. >=20 > At the end of 3.4.4: > add a new paragraph: > "In some deployment scenarios, the NAS may be made aware of end-users=20 > requests to join/leave a multicast flow by other means than ANCP=20 > Admission Requests sent by the AN (for example, the IGMP join/leave=20 > from the end-user might be somehow tunneled to the NAS). In such=20 > environments, the NAS can still control multicast replication to be=20 > performed by the AN via ANCP through the use of spontaneous Admission=20 > Responses (ie sent by NAS without prior receipt of a corresponding=20 > Admission Request)." >=20 > See above, I don't see a need for these changes. >=20 >=20 > In section 4.2: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > replace: > " o The ANCP MUST allow the AN to query the NAS to request an > admission decision for replicating a multicast flow to a > particular Access Port." > by > " o The ANCP MUST allow the AN to send an Admission=20 > Request to the > NAS to request an > admission decision for replicating a multicast flow to a=20 > particular Access Port." >=20 > I am ok with this change. >=20 > replace: > " o The ANCP MUST allow the NAS to send an admission=20 > decision to the > AN indicating whether or not a multicast flow may be replicated > to > a particular Access Port." > by > " o The ANCP MUST allow the NAS to send an Admission=20 > Response to the > AN (e.g. indicating whether or not a multicast flow is to be=20 > replicated to > a particular Access Port). >=20 > I am ok with this change. >=20 > o The ANCP MUST allow the NAS to send such an Admission Response=20 > either in response to an Admission Request received from the AN or=20 > spontaneously (i.e. without having received a corresponding Admission=20 > Request from AN). > o In particular, the ANCP MUST allow the NAS to send such an=20 > Admission Response in order to revoke a decision to replicate a > multicast flow to a particular Access Port, that had been=20 > conveyed earlier to an AN. >=20 > I would reword the above two bullets to: >=20 > o The ANCP MUST allow the NAS to send the Admission Response in=20 > response to an Admission Request received from the AN > o The ANCP MUST allow the NAS to send the Admission Response=20 > spontaneously (i.e. without having received a corresponding Admission=20 > Request from AN) in order to revoke a decision to replicate a=20 > multicast flow to a particular Access Port, that had been conveyed=20 > earlier to an AN. >=20 > >=20 > o The ANCP MUST allow the AN to notify the NAS of the outcome > (success/failure) of a join/leave instruction conveyed in an Admission > Response from the NAS. > " >=20 > I am ok with this addition >=20 > replace: > " o The ANCP MUST allow the NAS, when replying to an AN request, to > OPTIONALLY convey information on multiple multicast flows=20 > sharing > the same conditional access rules. This allows the AN to take > autonomous decisions for these flows later on." > by: > " o The ANCP MUST allow the NAS, when sending an Admission =20 > Response, to > OPTIONALLY convey information on multiple multicast flows=20 > sharing > the same conditional access and admission control rules. This=20 > allows the AN to take > autonomous decisions for these flows later on." >=20 > I am ok with this change >=20 > delete (this has been replaced by an equivalent requirement above)" > " o The ANCP MUST allow the NAS to revoke a decision to replicate a > multicast flow to a particular Access Port, which had been > conveyed earlier to an AN." >=20 > I am ok with this removal >=20 > Regards, > Sven > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www1.ietf.org/mailman/listinfo/ancp >=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 Mon Nov 26 05:42:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwbQF-0006Yr-O9; Mon, 26 Nov 2007 05:42:39 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IwbQE-0006Ym-3G for ancp-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 05:42:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwbQD-0006Yd-Pw for ancp@ietf.org; Mon, 26 Nov 2007 05:42:37 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwbQ5-000228-9w for ancp@ietf.org; Mon, 26 Nov 2007 05:42:37 -0500 X-IronPort-AV: E=Sophos;i="4.21,466,1188770400"; d="scan'208";a="158757774" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 26 Nov 2007 11:42:29 +0100 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 lAQAgSb9023620; Mon, 26 Nov 2007 11:42:28 +0100 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 lAQAgSZZ021033; Mon, 26 Nov 2007 10:42:28 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 11:42:28 +0100 Received: from [10.0.0.19] ([10.61.80.1]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 11:42:27 +0100 In-Reply-To: <8144761F31F48D43AD53D09F5350E38002069770@FRVELSMBS22.ad2.ad.alcatel.com> References: <9BD5D7887235424FA97DFC223CAE3C2803B76378@proton.jnpr.net><54469D09-60CF-4AE8-8BAD-A26B9E256113@cisco.com> <8144761F31F48D43AD53D09F5350E380020695B0@FRVELSMBS22.ad2.ad.alcatel.com> <8144761F31F48D43AD53D09F5350E38002069770@FRVELSMBS22.ad2.ad.alcatel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <26E82396-E20F-4248-B63E-6A82E14D0D65@cisco.com> Content-Transfer-Encoding: 7bit From: Francois Le Faucheur IMAP Subject: Re: Spontaneous Admission Response (was Re: [ANCP] ANCP WG follow-up) Date: Mon, 26 Nov 2007 11:42:22 +0100 To: "OOGHE Sven" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 26 Nov 2007 10:42:27.0582 (UTC) FILETIME=[09BDF9E0:01C83019] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=11289; t=1196073748; x=1196937748; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Re=3A=20Spontaneous=20Admission=20Response=20(was=20Re=3A=20[ ANCP]=20ANCP=20WG=20follow-up) |Sender:=20; bh=GXmRlmiBamdo3pufBjQFT707UqCrge7DOrX7dv7QOAs=; b=KmVyZJ1sQ4mJmkidSntaOfGCVpVhtKfffCS5x2fcUkqFA9but7B9XaHqBMZNrrQMcTmAVho6 oqYxmEz+tgw4446lAW5CMGNYL2oJqtFl8wV2ujKIdaIxK1xUQFnXslYi; Authentication-Results: ams-dkim-1; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: e16ce0269ccb2f59707d16700199d13b 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 Sven, On 26 Nov 2007, at 11:06, OOGHE Sven wrote: > Woj, > > From what I can find on the email list, the proposed change to section > 3.4.4 is related to the following remark from Sanjay (mid September > 2007): > > "The option I alluded to is IGMP from RG to BNG, and replication on > the > AN. The replication state on the AN created/controlled via ANCP by > BNG. > An optimization could be optional transparent snooping of IGMP on > the AN > to act on IGMP reports for leave only (to implement "fast leave")." Right. This is what initiated the thread. I am also aware of other planned deployments where the Multicast joins are processed by the device behaving as the ANCP-controller (as opposed to the AN). As these ANCP deployments will exist, the ANCP specs ought to recognize and allow them. Note that this has very little impact on the ANCP protocol anyways (since "spontaneous Admission Responses" are already explicitly allowed anyways for multicast termination) > > Now, with the recent discussion on white/black/grey list filtering in > the Access Node, it seems the WG agrees on having mechanisms in place > that reduce the IGMP/ANCP message load on the NAS. I fail to see the relationship between the recent discussion regarding a _default_ for white/black/grey and the ANCP deployment models various operators will select. When IGMP is processed by AN (which I agree is likely to be the common model), then we need to agree on a default in case of no-match in white/black/grey. This choice has no bearing on how operators will distribute functions across AN and NAS for different multicast flows. The only impact on selecting a default vs another is on configuration. And it is a very minor configuration impact since we are only talking about one extra single catch-all entry in one list. > A scenario where all > IGMP report messages are sent to the NAS is IMHO in contradiction > to the > WG's desire to reduce the NAS load. The WG has already concluded on the debate about perceived need "to reduce the NAS load" when considering the Grey List. I believe the conclusion was that while some perceive it is desirable to reduce the NAS load as much as possible, a significant part of the WG felt it is desirable to be able to take advantage of NAS capabilities for replication control. As a result, the WG decided that ANCP ought to : - allow operation where replication control is done in AN, - also allow operation where replication control is done by NAS (hence the notion of Grey lists). The current ANCP framework already allows replication control to be done by the NAS (where NAS is made aware of join/leave via ANCP Admission Requests). The proposal below only aims at allowing another deployment model where replication control is done by NAS (this time where NAS is made aware of join/leave by other means than ANCP) . Cheers Francois > The Access Node needs to be able to > process IGMP report and leave messages and filter them. > > Perhaps Sanjay can explain the scenario in a bit more detail? That way > we can better understand the resulting message load. > > Regards, > Sven > > -----Original Message----- > From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] > Sent: maandag 26 november 2007 10:33 > To: OOGHE Sven; Francois Le Faucheur (flefauch); ancp@ietf.org; > Maglione > Roberta > Subject: RE: Spontaneous Admission Response (was Re: [ANCP] ANCP WG > follow-up) > > Hi Sven, > > just an observation; the current text in Section 3.4.4 does not quite > reflect IMO the outcome of the discussion that's been had on the > alias, > and hence there is Francois' proposal to modify Section 3.4.4 in order > to allow both spontaneous joins and leaves. Perhaps then, instead of > changing Section 3.4.4 we could create a new section which covers > explicitly the spontaneous join/leave case and includes the proposed > changes? > > Regards, > Woj. > >> -----Original Message----- >> From: OOGHE Sven [mailto:Sven.Ooghe@alcatel-lucent.be] >> Sent: 26 November 2007 09:34 >> To: Francois Le Faucheur (flefauch); ancp@ietf.org; Maglione Roberta >> Subject: RE: Spontaneous Admission Response (was Re: [ANCP] ANCP WG >> follow-up) >> >> Hi Francois, >> >> I agree with most of the changes, except one. >> >> If I recall correctly, the idea behind the proposed changes below is >> to have a scenario where the Access Node performs replication, but >> doesn't perform IGMP processing. In other words, all IGMP report >> messages (and likely also all IGMP leave messages) are sent to the >> NAS; the NAS instructs the Access Node how to perform the replication >> by means of ANCP messages. >> >> On the other hand, the thread issued by Roberta highlights the >> need to > >> have mechanisms in place that offload the NAS from having to perform >> excessive IGMP and/or ANCP processing. >> This is done by introducing a default behavior, guided by filtering >> lists in the Access Node. In this solution, the Access Node performs >> IGMP processing and decides whether or not to send ANCP messages to >> the NAS. >> >> I agree with Roberta that a default behavior is in order. So I >> believe > >> that IGMP report/leave processing in the Access Node is also a >> requirement to achieve a default behavior. >> Therefore, I would not add the new paragraph in section 3.4.4. >> >> Some more feedback is inline. >> >> -----Original Message----- >> From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com] >> Sent: donderdag 22 november 2007 14:55 >> To: Francois Le Faucheur IMAP >> Cc: ancp@ietf.org >> Subject: Spontaneous Admission Response (was Re: [ANCP] ANCP WG >> follow-up) >> >> Hello, >> >> On 19 Sep 2007, at 15:56, Francois Le Faucheur IMAP wrote: >> >>> Sanjay and all, >>> >> >> >>> 2) you raise a valid point that there are ANCP deployment >> variations >>> whereby the replication on AN may be controlled by NAS via >> ANCP, but >>> where the "join/leave" information may not be conveyed to NAS via >>> ANCP. I agree the ANCP solution should allow this. We will >> work on a >>> revised proposal allowing this. >>> >>> Francois >> >> As agreed above, below is a proposal for modification to the text of >> draft-ietf-ancp-framework-04.txt in order to accommodate ANCP >> deployment models where the "join/leave" >> information may not be conveyed to NAS via ANCP. >> We'd appreciate feedback. >> Thanks >> Francois >> >> >> >> >> In section 3.4.4: >> ============ >> >> Replace: >> " 3.4.4. Multicast Termination" >> by: >> " 3.4.4. Spontaneous Admission Response" >> >> In second paragraph, replace: >> "This can be done with the Admission Response message." >> by >> "This can be achieved by the NAS sending a spontaneous Admission >> Response message (ie sent by NAS without prior receipt of a >> corresponding Admission Request)." >> >> I am ok with the paragraph text change, but would keep the >> title as-is. >> >> At the end of 3.4.4: >> add a new paragraph: >> "In some deployment scenarios, the NAS may be made aware of end-users >> requests to join/leave a multicast flow by other means than ANCP >> Admission Requests sent by the AN (for example, the IGMP join/leave >> from the end-user might be somehow tunneled to the NAS). In such >> environments, the NAS can still control multicast replication to be >> performed by the AN via ANCP through the use of spontaneous Admission >> Responses (ie sent by NAS without prior receipt of a corresponding >> Admission Request)." >> >> See above, I don't see a need for these changes. >> >> >> In section 4.2: >> =========== >> >> replace: >> " o The ANCP MUST allow the AN to query the NAS to request an >> admission decision for replicating a multicast flow to a >> particular Access Port." >> by >> " o The ANCP MUST allow the AN to send an Admission >> Request to the >> NAS to request an >> admission decision for replicating a multicast flow to a >> particular Access Port." >> >> I am ok with this change. >> >> replace: >> " o The ANCP MUST allow the NAS to send an admission >> decision to the >> AN indicating whether or not a multicast flow may be >> replicated > >> to >> a particular Access Port." >> by >> " o The ANCP MUST allow the NAS to send an Admission >> Response to the >> AN (e.g. indicating whether or not a multicast flow is to be >> replicated to >> a particular Access Port). >> >> I am ok with this change. >> >> o The ANCP MUST allow the NAS to send such an Admission Response >> either in response to an Admission Request received from the AN or >> spontaneously (i.e. without having received a corresponding Admission >> Request from AN). >> o In particular, the ANCP MUST allow the NAS to send such an >> Admission Response in order to revoke a decision to replicate a >> multicast flow to a particular Access Port, that had been >> conveyed earlier to an AN. >> >> I would reword the above two bullets to: >> >> o The ANCP MUST allow the NAS to send the Admission Response in >> response to an Admission Request received from the AN >> o The ANCP MUST allow the NAS to send the Admission Response >> spontaneously (i.e. without having received a corresponding Admission >> Request from AN) in order to revoke a decision to replicate a >> multicast flow to a particular Access Port, that had been conveyed >> earlier to an AN. >> >> >> >> o The ANCP MUST allow the AN to notify the NAS of the outcome >> (success/failure) of a join/leave instruction conveyed in an >> Admission > >> Response from the NAS. >> " >> >> I am ok with this addition >> >> replace: >> " o The ANCP MUST allow the NAS, when replying to an AN >> request, to >> OPTIONALLY convey information on multiple multicast flows >> sharing >> the same conditional access rules. This allows the AN to take >> autonomous decisions for these flows later on." >> by: >> " o The ANCP MUST allow the NAS, when sending an Admission >> Response, to >> OPTIONALLY convey information on multiple multicast flows >> sharing >> the same conditional access and admission control rules. This >> allows the AN to take >> autonomous decisions for these flows later on." >> >> I am ok with this change >> >> delete (this has been replaced by an equivalent requirement above)" >> " o The ANCP MUST allow the NAS to revoke a decision to >> replicate a >> multicast flow to a particular Access Port, which had been >> conveyed earlier to an AN." >> >> I am ok with this removal >> >> Regards, >> Sven >> _______________________________________________ >> 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 >> _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Mon Nov 26 07:10:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwcnZ-0000cv-Uu; Mon, 26 Nov 2007 07:10:49 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IwcnX-0000cq-Te for ancp-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 07:10:47 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwcnX-0000ci-HU for ancp@ietf.org; Mon, 26 Nov 2007 07:10:47 -0500 Received: from colt-na7.alcatel.fr ([62.23.212.7] helo=smail6.alcatel.fr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwcnV-00071B-QO for ancp@ietf.org; Mon, 26 Nov 2007 07:10:47 -0500 Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.ad2.ad.alcatel.com [155.132.6.74]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id lAQC9FDw028999; Mon, 26 Nov 2007 13:09:15 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.52]) by FRVELSBHS02.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 26 Nov 2007 13:10:41 +0100 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: Spontaneous Admission Response (was Re: [ANCP] ANCP WG follow-up) Date: Mon, 26 Nov 2007 13:10:39 +0100 Message-ID: <8144761F31F48D43AD53D09F5350E38002069932@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <26E82396-E20F-4248-B63E-6A82E14D0D65@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Spontaneous Admission Response (was Re: [ANCP] ANCP WG follow-up) Thread-Index: AcgwGQxUWwEB8TxjTyeiNdThc6W5EgACGphw References: <9BD5D7887235424FA97DFC223CAE3C2803B76378@proton.jnpr.net><54469D09-60CF-4AE8-8BAD-A26B9E256113@cisco.com> <8144761F31F48D43AD53D09F5350E380020695B0@FRVELSMBS22.ad2.ad.alcatel.com> <8144761F31F48D43AD53D09F5350E38002069770@FRVELSMBS22.ad2.ad.alcatel.com> <26E82396-E20F-4248-B63E-6A82E14D0D65@cisco.com> From: "OOGHE Sven" To: "Francois Le Faucheur IMAP" X-OriginalArrivalTime: 26 Nov 2007 12:10:41.0270 (UTC) FILETIME=[5D06A960:01C83025] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: c119f9923e40f08a1d7f390ce651ea92 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 Francois,=20 see inline. -----Original Message----- From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com]=20 Sent: maandag 26 november 2007 11:42 To: OOGHE Sven Cc: Francois Le Faucheur IMAP; Wojciech Dec (wdec); ancp@ietf.org; Maglione Roberta Subject: Re: Spontaneous Admission Response (was Re: [ANCP] ANCP WG follow-up) Hi Sven, On 26 Nov 2007, at 11:06, OOGHE Sven wrote: > Woj, > > From what I can find on the email list, the proposed change to section > 3.4.4 is related to the following remark from Sanjay (mid September > 2007): > > "The option I alluded to is IGMP from RG to BNG, and replication on=20 > the AN. The replication state on the AN created/controlled via ANCP by > BNG. > An optimization could be optional transparent snooping of IGMP on the=20 > AN to act on IGMP reports for leave only (to implement "fast leave")." Right. This is what initiated the thread. I am also aware of other planned deployments where the Multicast joins are processed by the device behaving as the ANCP-controller (as opposed to the AN). As these ANCP deployments will exist, the ANCP specs ought to recognize and allow them. Note that this has very little impact on the ANCP protocol anyways (since "spontaneous Admission Responses" =20 are already explicitly allowed anyways for multicast termination) > > Now, with the recent discussion on white/black/grey list filtering in=20 > the Access Node, it seems the WG agrees on having mechanisms in place=20 > that reduce the IGMP/ANCP message load on the NAS. I fail to see the relationship between the recent discussion regarding a _default_ for white/black/grey and the ANCP deployment models various operators will select. When IGMP is processed by AN (which I agree is likely to be the common model), then we need to agree on a default in case of no-match in white/black/grey.=20 This choice has no bearing on how operators will distribute functions across AN and NAS for different multicast flows. =20 The only impact on selecting a default vs another is on configuration. And it is a very minor configuration impact since we are only talking about one extra single catch-all entry in one list. I'm not disagreeing here. All I am saying is that based on the previous threads, I believe the conclusion was that we need some form of IGMP report message processing in the Access Node in order to reduce the load on the NAS. In other words, in a model where the Access Node would send IGMP messages to the NAS without processing - which is what you would like to add - one would still use ANCP to send information of other multicast groups to the AN, so that the AN can perform IGMP processing for subsequent reports. > A scenario where all > IGMP report messages are sent to the NAS is IMHO in contradiction to=20 > the WG's desire to reduce the NAS load. The WG has already concluded on the debate about perceived need "to reduce the NAS load" when considering the Grey List. I believe the conclusion was that while some perceive it is desirable to reduce the NAS load as much as possible, a significant part of the WG felt it is desirable to be able to take advantage of NAS capabilities for replication control. As a result, the WG decided that ANCP ought to : - allow operation where replication control is done in AN, - also allow operation where replication control is done by NAS (hence the notion of Grey lists). I understood the conclusion was that it is desirable to reduce the NAS load, while also supporting mechanisms for the NAS to control replication. Blindly forwarding all IGMP reports to the NAS, followed by ANCP to the AN seems to contradict this. There needs to be some way to reduce the load (see above remark). The current ANCP framework already allows replication control to be done by the NAS (where NAS is made aware of join/leave via ANCP Admission Requests). The proposal below only aims at allowing another deployment model where replication control is done by NAS (this time where NAS is made aware of join/leave by other means than ANCP) . Cheers Francois Regards, Sven > The Access Node needs to be able to > process IGMP report and leave messages and filter them. > > Perhaps Sanjay can explain the scenario in a bit more detail? That way > we can better understand the resulting message load. > > Regards, > Sven > > -----Original Message----- > From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] > Sent: maandag 26 november 2007 10:33 > To: OOGHE Sven; Francois Le Faucheur (flefauch); ancp@ietf.org;=20 > Maglione Roberta > Subject: RE: Spontaneous Admission Response (was Re: [ANCP] ANCP WG > follow-up) > > Hi Sven, > > just an observation; the current text in Section 3.4.4 does not quite=20 > reflect IMO the outcome of the discussion that's been had on the=20 > alias, and hence there is Francois' proposal to modify Section 3.4.4=20 > in order to allow both spontaneous joins and leaves. Perhaps then,=20 > instead of changing Section 3.4.4 we could create a new section which=20 > covers explicitly the spontaneous join/leave case and includes the=20 > proposed changes? > > Regards, > Woj. > >> -----Original Message----- >> From: OOGHE Sven [mailto:Sven.Ooghe@alcatel-lucent.be] >> Sent: 26 November 2007 09:34 >> To: Francois Le Faucheur (flefauch); ancp@ietf.org; Maglione Roberta >> Subject: RE: Spontaneous Admission Response (was Re: [ANCP] ANCP WG >> follow-up) >> >> Hi Francois, >> >> I agree with most of the changes, except one. >> >> If I recall correctly, the idea behind the proposed changes below is=20 >> to have a scenario where the Access Node performs replication, but=20 >> doesn't perform IGMP processing. In other words, all IGMP report=20 >> messages (and likely also all IGMP leave messages) are sent to the=20 >> NAS; the NAS instructs the Access Node how to perform the replication >> by means of ANCP messages. >> >> On the other hand, the thread issued by Roberta highlights the need=20 >> to > >> have mechanisms in place that offload the NAS from having to perform=20 >> excessive IGMP and/or ANCP processing. >> This is done by introducing a default behavior, guided by filtering=20 >> lists in the Access Node. In this solution, the Access Node performs=20 >> IGMP processing and decides whether or not to send ANCP messages to=20 >> the NAS. >> >> I agree with Roberta that a default behavior is in order. So I=20 >> believe > >> that IGMP report/leave processing in the Access Node is also a=20 >> requirement to achieve a default behavior. >> Therefore, I would not add the new paragraph in section 3.4.4. >> >> Some more feedback is inline. >> >> -----Original Message----- >> From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com] >> Sent: donderdag 22 november 2007 14:55 >> To: Francois Le Faucheur IMAP >> Cc: ancp@ietf.org >> Subject: Spontaneous Admission Response (was Re: [ANCP] ANCP WG >> follow-up) >> >> Hello, >> >> On 19 Sep 2007, at 15:56, Francois Le Faucheur IMAP wrote: >> >>> Sanjay and all, >>> >> >> >>> 2) you raise a valid point that there are ANCP deployment >> variations >>> whereby the replication on AN may be controlled by NAS via >> ANCP, but >>> where the "join/leave" information may not be conveyed to NAS via=20 >>> ANCP. I agree the ANCP solution should allow this. We will >> work on a >>> revised proposal allowing this. >>> >>> Francois >> >> As agreed above, below is a proposal for modification to the text of=20 >> draft-ietf-ancp-framework-04.txt in order to accommodate ANCP=20 >> deployment models where the "join/leave" >> information may not be conveyed to NAS via ANCP. >> We'd appreciate feedback. >> Thanks >> Francois >> >> >> >> >> In section 3.4.4: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> Replace: >> " 3.4.4. Multicast Termination" >> by: >> " 3.4.4. Spontaneous Admission Response" >> >> In second paragraph, replace: >> "This can be done with the Admission Response message." >> by >> "This can be achieved by the NAS sending a spontaneous Admission >> Response message (ie sent by NAS without prior receipt of a=20 >> corresponding Admission Request)." >> >> I am ok with the paragraph text change, but would keep the=20 >> title as-is. >> >> At the end of 3.4.4: >> add a new paragraph: >> "In some deployment scenarios, the NAS may be made aware of end-users >> requests to join/leave a multicast flow by other means than ANCP=20 >> Admission Requests sent by the AN (for example, the IGMP join/leave=20 >> from the end-user might be somehow tunneled to the NAS). In such=20 >> environments, the NAS can still control multicast replication to be=20 >> performed by the AN via ANCP through the use of spontaneous Admission >> Responses (ie sent by NAS without prior receipt of a corresponding=20 >> Admission Request)." >> >> See above, I don't see a need for these changes. >> >> >> In section 4.2: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> replace: >> " o The ANCP MUST allow the AN to query the NAS to request an >> admission decision for replicating a multicast flow to a >> particular Access Port." >> by >> " o The ANCP MUST allow the AN to send an Admission >> Request to the >> NAS to request an >> admission decision for replicating a multicast flow to a=20 >> particular Access Port." >> >> I am ok with this change. >> >> replace: >> " o The ANCP MUST allow the NAS to send an admission >> decision to the >> AN indicating whether or not a multicast flow may be=20 >> replicated > >> to >> a particular Access Port." >> by >> " o The ANCP MUST allow the NAS to send an Admission >> Response to the >> AN (e.g. indicating whether or not a multicast flow is to be=20 >> replicated to >> a particular Access Port). >> >> I am ok with this change. >> >> o The ANCP MUST allow the NAS to send such an Admission Response >> either in response to an Admission Request received from the AN or=20 >> spontaneously (i.e. without having received a corresponding Admission >> Request from AN). >> o In particular, the ANCP MUST allow the NAS to send such an=20 >> Admission Response in order to revoke a decision to replicate a >> multicast flow to a particular Access Port, that had been=20 >> conveyed earlier to an AN. >> >> I would reword the above two bullets to: >> >> o The ANCP MUST allow the NAS to send the Admission Response in=20 >> response to an Admission Request received from the AN >> o The ANCP MUST allow the NAS to send the Admission Response=20 >> spontaneously (i.e. without having received a corresponding Admission >> Request from AN) in order to revoke a decision to replicate a=20 >> multicast flow to a particular Access Port, that had been conveyed=20 >> earlier to an AN. >> >> >> >> o The ANCP MUST allow the AN to notify the NAS of the outcome >> (success/failure) of a join/leave instruction conveyed in an=20 >> Admission > >> Response from the NAS. >> " >> >> I am ok with this addition >> >> replace: >> " o The ANCP MUST allow the NAS, when replying to an AN =20 >> request, to >> OPTIONALLY convey information on multiple multicast flows=20 >> sharing >> the same conditional access rules. This allows the AN to take >> autonomous decisions for these flows later on." >> by: >> " o The ANCP MUST allow the NAS, when sending an Admission >> Response, to >> OPTIONALLY convey information on multiple multicast flows=20 >> sharing >> the same conditional access and admission control rules. This >> allows the AN to take >> autonomous decisions for these flows later on." >> >> I am ok with this change >> >> delete (this has been replaced by an equivalent requirement above)" >> " o The ANCP MUST allow the NAS to revoke a decision to =20 >> replicate a >> multicast flow to a particular Access Port, which had been >> conveyed earlier to an AN." >> >> I am ok with this removal >> >> Regards, >> Sven >> _______________________________________________ >> 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 >> _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Mon Nov 26 07:32:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwd8S-0000sL-LZ; Mon, 26 Nov 2007 07:32:24 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1Iwd8S-0000sF-2J for ancp-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 07:32:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwd8R-0000s2-On for ancp@ietf.org; Mon, 26 Nov 2007 07:32:23 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwd8J-0004VI-9U for ancp@ietf.org; Mon, 26 Nov 2007 07:32:23 -0500 X-IronPort-AV: E=Sophos;i="4.21,467,1188770400"; d="scan'208";a="158774077" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 26 Nov 2007 13:31:55 +0100 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 lAQCVt9d009575; Mon, 26 Nov 2007 13:31:55 +0100 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 lAQCVjZv009760; Mon, 26 Nov 2007 12:31:55 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); Mon, 26 Nov 2007 13:31:52 +0100 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: Spontaneous Admission Response (was Re: [ANCP] ANCP WG follow-up) Date: Mon, 26 Nov 2007 13:31:47 +0100 Message-ID: In-Reply-To: <8144761F31F48D43AD53D09F5350E38002069932@FRVELSMBS22.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Spontaneous Admission Response (was Re: [ANCP] ANCP WG follow-up) Thread-Index: AcgwGQxUWwEB8TxjTyeiNdThc6W5EgACGphwAAEnL4A= References: <9BD5D7887235424FA97DFC223CAE3C2803B76378@proton.jnpr.net><54469D09-60CF-4AE8-8BAD-A26B9E256113@cisco.com> <8144761F31F48D43AD53D09F5350E380020695B0@FRVELSMBS22.ad2.ad.alcatel.com> <8144761F31F48D43AD53D09F5350E38002069770@FRVELSMBS22.ad2.ad.alcatel.com> <26E82396-E20F-4248-B63E-6A82E14D0D65@cisco.com> <8144761F31F48D43AD53D09F5350E38002069932@FRVELSMBS22.ad2.ad.alcatel.com> From: "Wojciech Dec (wdec)" To: "OOGHE Sven" , "Francois Le Faucheur (flefauch)" X-OriginalArrivalTime: 26 Nov 2007 12:31:52.0656 (UTC) FILETIME=[52D4C500:01C83028] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=14840; t=1196080315; x=1196944315; c=relaxed/simple; s=amsdkim2001; 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=20Spontaneous=20Admission=20Response=20(was=20Re=3A=20[ ANCP]=20ANCP=20WG=20follow-up) |Sender:=20; bh=tHc1l35AzRyX0iwJSmtZyy0GniEVDs2NvN2FnaAmmbE=; b=RgQt33GGd9U1lA6uk6fTf6VKu1fjVG0MRFC46Vw6ai+qqt6EDUpElsoSkejnWpiUxF56eNX5 s716irtoNIuCXEk2M3LlgrKwoLc7MjlDJE8pPNW4PfImjKfIslzwzGvy; Authentication-Results: ams-dkim-2; header.From=wdec@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: bfef20db74c24e87b6dbcd42ea7ba67c 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 Sven, All, inline...=20 > -----Original Message----- > From: OOGHE Sven [mailto:Sven.Ooghe@alcatel-lucent.be]=20 > Sent: 26 November 2007 13:11 > To: Francois Le Faucheur (flefauch) > Cc: Wojciech Dec (wdec); ancp@ietf.org; Maglione Roberta > Subject: RE: Spontaneous Admission Response (was Re: [ANCP]=20 > ANCP WG follow-up) >=20 > Francois,=20 >=20 > see inline. >=20 > -----Original Message----- > From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com] > Sent: maandag 26 november 2007 11:42 > To: OOGHE Sven > Cc: Francois Le Faucheur IMAP; Wojciech Dec (wdec);=20 > ancp@ietf.org; Maglione Roberta > Subject: Re: Spontaneous Admission Response (was Re: [ANCP] ANCP WG > follow-up) >=20 > Hi Sven, >=20 > On 26 Nov 2007, at 11:06, OOGHE Sven wrote: >=20 > > Woj, > > > > From what I can find on the email list, the proposed change=20 > to section > > 3.4.4 is related to the following remark from Sanjay (mid September > > 2007): > > > > "The option I alluded to is IGMP from RG to BNG, and replication on=20 > > the AN. The replication state on the AN created/controlled=20 > via ANCP by >=20 > > BNG. > > An optimization could be optional transparent snooping of=20 > IGMP on the=20 > > AN to act on IGMP reports for leave only (to implement=20 > "fast leave")." >=20 > Right. This is what initiated the thread. >=20 > I am also aware of other planned deployments where the=20 > Multicast joins are processed by the device behaving as the=20 > ANCP-controller (as opposed to the AN). >=20 > As these ANCP deployments will exist, the ANCP specs ought to=20 > recognize and allow them. Note that this has very little=20 > impact on the ANCP protocol anyways (since "spontaneous=20 > Admission Responses" =20 > are already explicitly allowed anyways for multicast termination) >=20 > > > > Now, with the recent discussion on white/black/grey list=20 > filtering in=20 > > the Access Node, it seems the WG agrees on having=20 > mechanisms in place=20 > > that reduce the IGMP/ANCP message load on the NAS. >=20 > I fail to see the relationship between the recent discussion=20 > regarding a _default_ for white/black/grey and the ANCP=20 > deployment models various operators will select. >=20 > When IGMP is processed by AN (which I agree is likely to be=20 > the common model), then we need to agree on a default in case=20 > of no-match in white/black/grey.=20 > This choice has no bearing on how operators will distribute=20 > functions across AN and NAS for different multicast flows. =20 > The only impact on selecting a default vs another is on configuration. > And it is a very minor configuration impact since we are only=20 > talking about one extra single catch-all entry in one list. >=20 > I'm not disagreeing here. All I am saying is that=20 > based on the previous threads, I believe the conclusion was=20 > that we need some form of IGMP report message processing in=20 > the Access Node in order to reduce the load on the NAS. In=20 > other words, in a model where the Access Node would send IGMP=20 > messages to the NAS without processing - which is what you=20 > would like to add - one would still use ANCP to send=20 > information of other multicast groups to the AN, so that the=20 > AN can perform IGMP processing for subsequent reports. > Woj> Agreed, noting however that this refers a specific IGMP deployment scenario. >=20 > > A scenario where all > > IGMP report messages are sent to the NAS is IMHO in=20 > contradiction to=20 > > the WG's desire to reduce the NAS load. >=20 > The WG has already concluded on the debate about perceived=20 > need "to reduce the NAS load" when considering the Grey List.=20 > I believe the conclusion was that while some perceive it is=20 > desirable to reduce the NAS load as much as possible, a=20 > significant part of the WG felt it is desirable to be able to=20 > take advantage of NAS capabilities for replication control.=20 > As a result, the WG decided that ANCP ought to : > - allow operation where replication control is done in AN, > - also allow operation where replication control is=20 > done by NAS (hence the notion of Grey lists). >=20 > I understood the conclusion was that it is desirable=20 > to reduce the NAS load, while also supporting mechanisms for=20 > the NAS to control replication. Blindly forwarding all IGMP=20 > reports to the NAS, followed by ANCP to the AN seems to=20 > contradict this. There needs to be some way to reduce the=20 > load (see above remark). Woj> Sanjay's mail raised a valid observation about alternative deployment scenarios, where IGMP processing on the AN is disabled. One should generalise this argument further and totally decouple it from IGMP - the proposed spontaneous control mechanism provides such decoupling. The evaluation of what load can a NAS handle depends on numerous other factors than just IGMP processing, and should not be the only goal for laying down the requirements ANCP functionality. In terms of such functionality thus, ANCP should be capable of addressing multicast deployment scenarios decoupled from IGMP assumptions. I see the proposal as one filling this gap. -Woj. >=20 > The current ANCP framework already allows replication control=20 > to be done by the NAS (where NAS is made aware of join/leave=20 > via ANCP Admission Requests). > The proposal below only aims at allowing another deployment=20 > model where replication control is done by NAS (this time=20 > where NAS is made aware of join/leave by other means than ANCP) . >=20 > Cheers >=20 > Francois >=20 > Regards, > Sven >=20 > > The Access Node needs to be able to > > process IGMP report and leave messages and filter them. > > > > Perhaps Sanjay can explain the scenario in a bit more=20 > detail? That way >=20 > > we can better understand the resulting message load. > > > > Regards, > > Sven > > > > -----Original Message----- > > From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] > > Sent: maandag 26 november 2007 10:33 > > To: OOGHE Sven; Francois Le Faucheur (flefauch); ancp@ietf.org;=20 > > Maglione Roberta > > Subject: RE: Spontaneous Admission Response (was Re: [ANCP] ANCP WG > > follow-up) > > > > Hi Sven, > > > > just an observation; the current text in Section 3.4.4 does=20 > not quite=20 > > reflect IMO the outcome of the discussion that's been had on the=20 > > alias, and hence there is Francois' proposal to modify=20 > Section 3.4.4=20 > > in order to allow both spontaneous joins and leaves. Perhaps then,=20 > > instead of changing Section 3.4.4 we could create a new=20 > section which=20 > > covers explicitly the spontaneous join/leave case and includes the=20 > > proposed changes? > > > > Regards, > > Woj. > > > >> -----Original Message----- > >> From: OOGHE Sven [mailto:Sven.Ooghe@alcatel-lucent.be] > >> Sent: 26 November 2007 09:34 > >> To: Francois Le Faucheur (flefauch); ancp@ietf.org;=20 > Maglione Roberta > >> Subject: RE: Spontaneous Admission Response (was Re: [ANCP] ANCP WG > >> follow-up) > >> > >> Hi Francois, > >> > >> I agree with most of the changes, except one. > >> > >> If I recall correctly, the idea behind the proposed=20 > changes below is=20 > >> to have a scenario where the Access Node performs replication, but=20 > >> doesn't perform IGMP processing. In other words, all IGMP report=20 > >> messages (and likely also all IGMP leave messages) are sent to the=20 > >> NAS; the NAS instructs the Access Node how to perform the=20 > replication >=20 > >> by means of ANCP messages. > >> > >> On the other hand, the thread issued by Roberta highlights=20 > the need=20 > >> to > > > >> have mechanisms in place that offload the NAS from having=20 > to perform=20 > >> excessive IGMP and/or ANCP processing. > >> This is done by introducing a default behavior, guided by=20 > filtering=20 > >> lists in the Access Node. In this solution, the Access=20 > Node performs=20 > >> IGMP processing and decides whether or not to send ANCP=20 > messages to=20 > >> the NAS. > >> > >> I agree with Roberta that a default behavior is in order. So I=20 > >> believe > > > >> that IGMP report/leave processing in the Access Node is also a=20 > >> requirement to achieve a default behavior. > >> Therefore, I would not add the new paragraph in section 3.4.4. > >> > >> Some more feedback is inline. > >> > >> -----Original Message----- > >> From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com] > >> Sent: donderdag 22 november 2007 14:55 > >> To: Francois Le Faucheur IMAP > >> Cc: ancp@ietf.org > >> Subject: Spontaneous Admission Response (was Re: [ANCP] ANCP WG > >> follow-up) > >> > >> Hello, > >> > >> On 19 Sep 2007, at 15:56, Francois Le Faucheur IMAP wrote: > >> > >>> Sanjay and all, > >>> > >> > >> > >>> 2) you raise a valid point that there are ANCP deployment > >> variations > >>> whereby the replication on AN may be controlled by NAS via > >> ANCP, but > >>> where the "join/leave" information may not be conveyed to NAS via=20 > >>> ANCP. I agree the ANCP solution should allow this. We will > >> work on a > >>> revised proposal allowing this. > >>> > >>> Francois > >> > >> As agreed above, below is a proposal for modification to=20 > the text of=20 > >> draft-ietf-ancp-framework-04.txt in order to accommodate ANCP=20 > >> deployment models where the "join/leave" > >> information may not be conveyed to NAS via ANCP. > >> We'd appreciate feedback. > >> Thanks > >> Francois > >> > >> > >> > >> > >> In section 3.4.4: > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> > >> Replace: > >> " 3.4.4. Multicast Termination" > >> by: > >> " 3.4.4. Spontaneous Admission Response" > >> > >> In second paragraph, replace: > >> "This can be done with the Admission Response message." > >> by > >> "This can be achieved by the NAS sending a spontaneous Admission > >> Response message (ie sent by NAS without prior receipt of a=20 > >> corresponding Admission Request)." > >> > >> I am ok with the paragraph text change, but would keep the=20 > >> title as-is. > >> > >> At the end of 3.4.4: > >> add a new paragraph: > >> "In some deployment scenarios, the NAS may be made aware=20 > of end-users >=20 > >> requests to join/leave a multicast flow by other means than ANCP=20 > >> Admission Requests sent by the AN (for example, the IGMP=20 > join/leave=20 > >> from the end-user might be somehow tunneled to the NAS). In such=20 > >> environments, the NAS can still control multicast=20 > replication to be=20 > >> performed by the AN via ANCP through the use of=20 > spontaneous Admission >=20 > >> Responses (ie sent by NAS without prior receipt of a corresponding=20 > >> Admission Request)." > >> > >> See above, I don't see a need for these changes. > >> > >> > >> In section 4.2: > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> > >> replace: > >> " o The ANCP MUST allow the AN to query the NAS to request an > >> admission decision for replicating a multicast flow to a > >> particular Access Port." > >> by > >> " o The ANCP MUST allow the AN to send an Admission > >> Request to the > >> NAS to request an > >> admission decision for replicating a multicast flow to a=20 > >> particular Access Port." > >> > >> I am ok with this change. > >> > >> replace: > >> " o The ANCP MUST allow the NAS to send an admission > >> decision to the > >> AN indicating whether or not a multicast flow may be=20 > >> replicated > > > >> to > >> a particular Access Port." > >> by > >> " o The ANCP MUST allow the NAS to send an Admission > >> Response to the > >> AN (e.g. indicating whether or not a multicast flow=20 > is to be=20 > >> replicated to > >> a particular Access Port). > >> > >> I am ok with this change. > >> > >> o The ANCP MUST allow the NAS to send such an=20 > Admission Response >=20 > >> either in response to an Admission Request received from the AN or=20 > >> spontaneously (i.e. without having received a=20 > corresponding Admission >=20 > >> Request from AN). > >> o In particular, the ANCP MUST allow the NAS to send such an=20 > >> Admission Response in order to revoke a decision to replicate a > >> multicast flow to a particular Access Port, that had been=20 > >> conveyed earlier to an AN. > >> > >> I would reword the above two bullets to: > >> > >> o The ANCP MUST allow the NAS to send the Admission=20 > Response in=20 > >> response to an Admission Request received from the AN > >> o The ANCP MUST allow the NAS to send the Admission Response=20 > >> spontaneously (i.e. without having received a=20 > corresponding Admission >=20 > >> Request from AN) in order to revoke a decision to replicate a=20 > >> multicast flow to a particular Access Port, that had been conveyed=20 > >> earlier to an AN. > >> > >> > >> > >> o The ANCP MUST allow the AN to notify the NAS of the outcome > >> (success/failure) of a join/leave instruction conveyed in an=20 > >> Admission > > > >> Response from the NAS. > >> " > >> > >> I am ok with this addition > >> > >> replace: > >> " o The ANCP MUST allow the NAS, when replying to an AN =20 > >> request, to > >> OPTIONALLY convey information on multiple multicast flows=20 > >> sharing > >> the same conditional access rules. This allows the=20 > AN to take > >> autonomous decisions for these flows later on." > >> by: > >> " o The ANCP MUST allow the NAS, when sending an Admission > >> Response, to > >> OPTIONALLY convey information on multiple multicast flows=20 > >> sharing > >> the same conditional access and admission control=20 > rules. This >=20 > >> allows the AN to take > >> autonomous decisions for these flows later on." > >> > >> I am ok with this change > >> > >> delete (this has been replaced by an equivalent requirement above)" > >> " o The ANCP MUST allow the NAS to revoke a decision to =20 > >> replicate a > >> multicast flow to a particular Access Port, which had been > >> conveyed earlier to an AN." > >> > >> I am ok with this removal > >> > >> Regards, > >> Sven > >> _______________________________________________ > >> 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 > >> >=20 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Mon Nov 26 08:43:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IweF4-0005rA-R2; Mon, 26 Nov 2007 08:43:18 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IweF3-0005nD-8v for ancp-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 08:43:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IweF2-0005lU-Su for ancp@ietf.org; Mon, 26 Nov 2007 08:43:16 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IweF2-0000Zp-9U for ancp@ietf.org; Mon, 26 Nov 2007 08:43:16 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by sj-iport-5.cisco.com with ESMTP; 26 Nov 2007 05:43:14 -0800 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 lAQDhD50001710; Mon, 26 Nov 2007 14:43:13 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAQDhDZd009610; Mon, 26 Nov 2007 13:43:13 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 14:43:13 +0100 Received: from [10.0.0.19] ([10.61.82.75]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 14:43:12 +0100 In-Reply-To: References: <9BD5D7887235424FA97DFC223CAE3C2803B76378@proton.jnpr.net><54469D09-60CF-4AE8-8BAD-A26B9E256113@cisco.com> <8144761F31F48D43AD53D09F5350E380020695B0@FRVELSMBS22.ad2.ad.alcatel.com> <8144761F31F48D43AD53D09F5350E38002069770@FRVELSMBS22.ad2.ad.alcatel.com> <26E82396-E20F-4248-B63E-6A82E14D0D65@cisco.com> <8144761F31F48D43AD53D09F5350E38002069932@FRVELSMBS22.ad2.ad.alcatel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Francois Le Faucheur IMAP Subject: Re: Spontaneous Admission Response (was Re: [ANCP] ANCP WG follow-up) Date: Mon, 26 Nov 2007 14:43:07 +0100 To: OOGHE Sven , "Wojciech Dec (wdec)" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 26 Nov 2007 13:43:13.0027 (UTC) FILETIME=[4A218D30:01C83032] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3022; t=1196084593; x=1196948593; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Re=3A=20Spontaneous=20Admission=20Response=20(was=20Re=3A=20[ ANCP]=20ANCP=20WG=20follow-up) |Sender:=20; bh=Lx4FBOXJ9ZjUkMXeJxz2to11llbNeC57ygWpMJeg40g=; b=mGD5u7yvnPyOyrK2JLRUHgXagDuqxyj17Xt6vjWj0RTPY7CYXjjynrVd4kAIOsG8UE8zTVoq skvDqiuPAx0UV5ugPplv0iKNItpYnvtPhN9jO3nup7FZXh8y1GRIf5Zo; Authentication-Results: ams-dkim-2; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe 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 Sven, Woj, >> >> The WG has already concluded on the debate about perceived >> need "to reduce the NAS load" when considering the Grey List. >> I believe the conclusion was that while some perceive it is >> desirable to reduce the NAS load as much as possible, a >> significant part of the WG felt it is desirable to be able to >> take advantage of NAS capabilities for replication control. >> As a result, the WG decided that ANCP ought to : >> - allow operation where replication control is done in AN, >> - also allow operation where replication control is >> done by NAS (hence the notion of Grey lists). >> >> I understood the conclusion was that it is desirable >> to reduce the NAS load, while also supporting mechanisms for >> the NAS to control replication. Blindly forwarding all IGMP >> reports to the NAS, followed by ANCP to the AN seems to >> contradict this. There needs to be some way to reduce the >> load (see above remark). > > Woj> Sanjay's mail raised a valid observation about alternative > deployment scenarios, where IGMP processing on the AN is disabled. One > should generalise this argument further and totally decouple it from > IGMP - the proposed spontaneous control mechanism provides such > decoupling. The evaluation of what load can a NAS handle depends on > numerous other factors than just IGMP processing, and should not be > the > only goal for laying down the requirements ANCP functionality. In > terms > of such functionality thus, ANCP should be capable of addressing > multicast deployment scenarios decoupled from IGMP assumptions. I see > the proposal as one filling this gap. > The proposal submitted on the alias leaves it entirely open as to how the join/leave information is conveyed to NAS. It mentions tunneling IGMP joins/leaves to the NAS purely as an example. Alternatively, it could be done by sending IGMP Join/Leaves to both the NAS and the AN (and have NAS use this as a trigger to push to AN authorisation for a group of flows sharing same conditional/admission control rules - and then have AN do autonomous decision within the group and possibly also process leaves). Alternatively, it could be done using another protocol than IGMP. Is it not acceptable to leave this open so ANCP allows all these deployment models (particularly considering it does not seem to require any extra extensions to ANCP: all we need is the Spontaneous Admission Response). Why would we prevent some of these deployment models? Perhaps we could change the wording in order to: * make it very clear that tunneling IGMP join/leave to NAS is just an example deployment model * there are other deployment models * describe another deployment model along the lines of what Sven discussed (ie I think with NAS doing some initial processing and then AN doing subsequent processing, eg using the concept that we used to call "flow-group"). How does that sound? Francois _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Mon Nov 26 17:20:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwmJP-0006lh-NE; Mon, 26 Nov 2007 17:20:19 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IwmJO-0006lY-I1 for ancp-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 17:20:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwmJO-0006hr-7F for ancp@ietf.org; Mon, 26 Nov 2007 17:20:18 -0500 Received: from exprod7og103.obsmtp.com ([64.18.2.159]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwmJJ-0005DR-VB for ancp@ietf.org; Mon, 26 Nov 2007 17:20:17 -0500 Received: from source ([66.129.224.36]) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP; Mon, 26 Nov 2007 14:19:04 PST Received: from proton.jnpr.net ([10.10.2.37]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 14:20:06 -0800 Received: from emailwf1.jnpr.net ([10.10.2.33]) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 17:20:05 -0500 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: Spontaneous Admission Response (was Re: [ANCP] ANCP WG follow-up) Date: Mon, 26 Nov 2007 17:20:01 -0500 Message-ID: <3525C9833C09ED418C6FD6CD9514668C02CADF80@emailwf1.jnpr.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Spontaneous Admission Response (was Re: [ANCP] ANCP WG follow-up) Thread-Index: AcgwMlIK9AVBLW0RRreyQwn5J9oxAwAQxC1A References: <9BD5D7887235424FA97DFC223CAE3C2803B76378@proton.jnpr.net><54469D09-60CF-4AE8-8BAD-A26B9E256113@cisco.com><8144761F31F48D43AD53D09F5350E380020695B0@FRVELSMBS22.ad2.ad.alcatel.com><8144761F31F48D43AD53D09F5350E38002069770@FRVELSMBS22.ad2.ad.alcatel.com><26E82396-E20F-4248-B63E-6A82E14D0D65@cisco.com><8144761F31F48D43AD53D09F5350E38002069932@FRVELSMBS22.ad2.ad.alcatel.com> From: "Jerome Moisand" To: X-OriginalArrivalTime: 26 Nov 2007 22:20:05.0107 (UTC) FILETIME=[7EC56C30:01C8307A] X-Spam-Score: -4.0 (----) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede 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 A few comments from an "old ghost"... ;-) << The option I alluded to is IGMP from RG to BNG, and replication on the AN. The replication state on the AN created/controlled via ANCP by BNG. >> Just an historical reminder. The scenario where the BNG is the "ANCP controller" (i.e. processes all multicast join/leaves, and instructs the Access Node to establish replication rules) was the scenario which triggered the entire DSL-Forum L2-control initiative a few years ago... Then we collectively started to focus on other priorities, but this scenario remains very valid. There are multiple advantages to this scenario, like: 1. full flexibility and AN independence from the multicast control protocol and its encapsulation (could be IGMP over PPP, could be IGMP over IPSec, could be SIP Invites, could be an external app server driving the BNG to delegate replication, could be an IPv6 control protocol, could also be an ATM aggregation scenario -yes, this still exists!-, whatever) 2. full visibility by the BNG about the multicast changes in the proper subscriber context, so dynamically deciding to optimize multicast or not, adjusting hierarchical QoS or subscriber statistics, or making local CAC decisions becomes much easier for the BNG (as opposed to more contorted schemes discussed in the past) 3. overall behavior becoming 100% consistent with scenarios without multicast optimization. As to the BNG IGMP load, well, I believe this is up to BNG vendors reps to speak up here, and working for one such vendor, I have never seen it as an show stopper to address some major use cases, and never viewed L2C/ANCP as a necessary mean to 'reduce IGMP load'. This point was emphasized again & again in the DSL-Forum years ago. So... fully agreed with Francois and Woj, the "spontaneous admission response" scenario should definitely be covered. Low cost and high return on investment! ;-) Cheers, Jerome - back to ghost mode=20 -----Original Message----- From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com]=20 Sent: Monday, November 26, 2007 8:43 AM To: OOGHE Sven; Wojciech Dec (wdec) Cc: ancp@ietf.org Subject: Re: Spontaneous Admission Response (was Re: [ANCP] ANCP WG follow-up) Sven, Woj, >> >> The WG has already concluded on the debate about perceived >> need "to reduce the NAS load" when considering the Grey List. >> I believe the conclusion was that while some perceive it is >> desirable to reduce the NAS load as much as possible, a >> significant part of the WG felt it is desirable to be able to >> take advantage of NAS capabilities for replication control. >> As a result, the WG decided that ANCP ought to : >> - allow operation where replication control is done in AN, >> - also allow operation where replication control is >> done by NAS (hence the notion of Grey lists). >> >> I understood the conclusion was that it is desirable >> to reduce the NAS load, while also supporting mechanisms for >> the NAS to control replication. Blindly forwarding all IGMP >> reports to the NAS, followed by ANCP to the AN seems to >> contradict this. There needs to be some way to reduce the >> load (see above remark). > > Woj> Sanjay's mail raised a valid observation about alternative > deployment scenarios, where IGMP processing on the AN is disabled. One > should generalise this argument further and totally decouple it from > IGMP - the proposed spontaneous control mechanism provides such > decoupling. The evaluation of what load can a NAS handle depends on > numerous other factors than just IGMP processing, and should not be =20 > the > only goal for laying down the requirements ANCP functionality. In =20 > terms > of such functionality thus, ANCP should be capable of addressing > multicast deployment scenarios decoupled from IGMP assumptions. I see > the proposal as one filling this gap. > The proposal submitted on the alias leaves it entirely =20 open as to how the join/leave information is conveyed to NAS. It mentions tunneling IGMP joins/leaves to the NAS purely as an example. Alternatively, it could be done by sending IGMP Join/Leaves to both =20 the NAS and the AN (and have NAS use this as a trigger to push to AN =20 authorisation for a group of flows sharing same conditional/admission =20 control rules - and then have AN do autonomous decision within the =20 group and possibly also process leaves). Alternatively, it could be done using another protocol than IGMP. Is it not acceptable to leave this open so ANCP allows all these =20 deployment models (particularly considering it does not seem to =20 require any extra extensions to ANCP: all we need is the Spontaneous =20 Admission Response). Why would we prevent some of these deployment models? Perhaps we could change the wording in order to: * make it very clear that tunneling IGMP join/leave to NAS is just =20 an example deployment model * there are other deployment models * describe another deployment model along the lines of what Sven discussed (ie I think with NAS doing some initial processing and then =20 AN doing subsequent processing, eg using the concept that we used to =20 call "flow-group"). How does that sound? Francois _______________________________________________ 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 Tue Nov 27 08:29:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix0VG-0000sf-0c; Tue, 27 Nov 2007 08:29:30 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1Ix0VF-0000sN-27 for ancp-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 08:29:29 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix0VE-0000sA-Io for ancp@ietf.org; Tue, 27 Nov 2007 08:29:28 -0500 Received: from gc-na5.alcatel.fr ([64.208.49.5] helo=smail6.alcatel.fr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ix0VC-00046m-F4 for ancp@ietf.org; Tue, 27 Nov 2007 08:29:28 -0500 Received: from FRVELSBHS07.ad2.ad.alcatel.com (frvelsbhs07.ad2.ad.alcatel.com [155.132.6.79]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id lARDRsfc029909; Tue, 27 Nov 2007 14:27:54 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.52]) by FRVELSBHS07.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 27 Nov 2007 14:29:21 +0100 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: Introducing Mutlicast Grey-List (was RE: [ANCP] Comments ondraft-maglione) Date: Tue, 27 Nov 2007 14:29:20 +0100 Message-ID: <8144761F31F48D43AD53D09F5350E380020DEE4E@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Introducing Mutlicast Grey-List (was RE: [ANCP] Comments ondraft-maglione) Thread-Index: AcgwC/JfPZ6MmvR4TYies2mWcWFJCQA7HGrQ References: <8C253CB7-CF45-431D-94B6-4AC1A1653524@cisco.com> <9E577E61D0108D4F8CD482029B613F5C0181BF87@PTPEVS108BA020.idc.cww.telecomitalia.it> <8144761F31F48D43AD53D09F5350E38002069337@FRVELSMBS22.ad2.ad.alcatel.com> <9E577E61D0108D4F8CD482029B613F5C01A7CF5F@PTPEVS108BA020.idc.cww.telecomitalia.it> From: "OOGHE Sven" To: "Francois Le Faucheur IMAP" , "Maglione Roberta" X-OriginalArrivalTime: 27 Nov 2007 13:29:21.0543 (UTC) FILETIME=[84F0E970:01C830F9] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4bbdb236f788407ff689fcae8109fe34 Cc: Ullio Mario , ancp@ietf.org, Michel Platnic 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 Francois, I agree that a catch-all statement can be used to create either "accept all" or "reject all" behavior. Perhaps one nuance: it would make sense to indicate wheher such channels could be accepted as "best effort". That means that in case other premium channels are requested lateron, the best effort content (e.g. internet TV) would be the first to suffer. Perhaps the way forward is the following: - indicate in the framework that by default, all joins for a channel that is not in one of the configured lists, will be rejected. - the operator can override this behavior by configuring such a wildcard entry in one of the lists. It should be possible to indicate whether or not the channel is a best effort channel or premium content. Comments? Regards, Sven -----Original Message----- From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com]=20 Sent: maandag 26 november 2007 10:08 To: Maglione Roberta; OOGHE Sven Cc: Francois Le Faucheur IMAP; ancp@ietf.org; Michel Platnic; Ullio Mario Subject: Re: Introducing Mutlicast Grey-List (was RE: [ANCP] Comments ondraft-maglione) Roberta, Sven, and all, It is worth noting that Roberta's proposal below allows the behavior described by Sven with very trivial extra config: simply add one "catch-all" entry () in the White List. Then any flow that doesn't match the Black or Grey list will be accepted by AN. For example, we could add: Scenario 4: * White-List =3D { } =3D=3D> any Join message gets accepted by AN Scenario 5: * White-List =3D { } * Black-List =3D { , , ... = } =3D=3D> Join ( S=3D*,G=3DGi) gets rejected by AN ( 1<=3Di<=3Dn ) =3D=3D> everything else gets accepted by AN So the choice is between: * "Black-Default": proposal below where: - Default =3D=3D> everything that doesn't match Black/Grey gets blocked - add a single-entry catch-all in White-List=3D=3D> everything that doesn't match Black/Grey gets accepted * "White-Default": modified proposal where: - Default =3D=3D> everything that doesn't match Black/Grey gets accepted - add a single-entry catch-all in Black-List=3D=3D> everything that doesn't match Black/Grey gets blocked Both proposals can easily achieve both required behaviors (ie "block if doesn't match" _and_ "accept if doesn't match"). The only difference is about whether you need to add the single catch-all entry or not to achieve your favorite behavior. From previous discussion on that topic, it sounded to me like several folks were more comfortable with the conservative side (ie if there has not been a conscious decision to allow a flow, then better block it; it is easy enough to explicitly "allow-all" if operator is so inclined). So considering the above ... what do people prefer? Perhaps we could also poll the WG in Vancouver on that topic. Francois On 25 Nov 2007, at 22:26, Maglione Roberta wrote: > Hi Sven, > thanks for your comments; > your point makes sense to me, "accept as best effort" is a valid=20 > option for default behavior. > The basic idea for the default action is to avoid query the NAS for=20 > all multicast flows that do not match any list: the reason why we=20 > selected drop as the default behavior for unconfigured multicast flows > is in order to be consistent with the typical ACL behavior, and also=20 > because this seemed to be the preferred action according to the=20 > discussion we had in Chicago and on the mailing list, but I open to=20 > modify the default behavior, according to Working group feedback. > > Regards, > Roberta > > > -----Original Message----- > From: OOGHE Sven [mailto:Sven.Ooghe@alcatel-lucent.be] > Sent: Fri 11/23/2007 5:16 PM > To: Maglione Roberta; ancp@ietf.org > Cc: Ullio Mario; Michel Platnic > Subject: RE: Introducing Mutlicast Grey-List (was RE: [ANCP] Comments=20 > ondraft-maglione) > > Hello Roberta, > > Thinking a bit further about the default behavior, I am not sure that=20 > dropping would be the right approach. (cf. "If a Join message is=20 > received by AN for a flow which is not on any list, then it is > rejected") > > Imagine any multicast flow out there on the Internet (e.g. Internet=20 > TV), then if it is not configured on the Access Node, it will be=20 > rejected. I don't think this is what an end-user would want. > > Instead, I would argue that if the flow is not part of any of the=20 > lists, that the behavior would be to accept it as best effort, i.e.=20 > accept without further admission control checks. > > What do you think? > > Regards, > Sven > > > -----Original Message----- > From: Maglione Roberta [mailto:roberta.maglione@telecomitalia.it] > Sent: vrijdag 23 november 2007 8:36 > To: ancp@ietf.org > Cc: Ullio Mario; Michel Platnic > Subject: Introducing Mutlicast Grey-List (was RE: [ANCP] Comments > ondraft-maglione) > > Hello, > as we discussed during Chicago meeting below is a proposal for=20 > modification to the text of draft-ietf-ancp-framework-04.txt in order=20 > to introduce Multicast Grey List and leave Black List (i.e. deny) as=20 > default behavior. > We'd appreciate feedback. > > Regards, > Roberta > > > Section 3.4.1 > Replace: > " Provisioning the conditional access information on the AN can be=20 > done using a "White list" and/or a "Black list". > A White list associated with an Access Port identifies the multicast=20 > flows that are allowed to be replicated to that port. A Black list=20 > associated with an Access Port identifies the multicast flows that are > not allowed to be replicated to that port." > > By: > " Provisioning the conditional access information on the AN can be=20 > done using a "White list", "Grey list", and/or a "Black list". A=20 > White list associated with an Access Port identifies the multicast=20 > flows that are allowed to be replicated to that port. A Black list=20 > associated with an Access Port identifies the multicast flows that are > not allowed to be replicated to that port. A Grey list associated with > an Access Port identifies the multicast flows for which the AN on=20 > receiving a Join message, before starting traffic replication queries=20 > NAS for further authorization. > Each list contains zero, one or multiple entries and each entry may=20 > specify a single flow or contain ranges (i.e. mask on Group address=20 > and/or mask on Source address). > > > Replace: > "Upon receiving a join message on an Access Port, the Access Node will > first check if the requested multicast flow is part of a White list =20 > or a > Black list associated with that Access Port. If it is part of a White > list, the AN can autonomously start replicating multicast =20 > traffic. If > it is part of a Black list, the AN can autonomously discard the =20 > message > because the request is not authorized" > > By: > > "Upon receiving a join message on an Access Port, the Access Node will > first check if the requested multicast flow is part of a White, =20 > Grey or > a Black list associated with that Access Port. If it is part of a =20 > White > list, the AN can autonomously start replicating multicast traffic. If > it is part of a Black list, the AN can autonomously discard the =20 > message > because the request is not authorized. If it is part of a Grey list =20 > the > AN uses ANCP to query the NAS, that in turn will respond to the AN > indicating whether the join is to be honored (and hence replication > performed by the AN) or denied (and hence replication not performed by > the AN.) If a Join message is received by AN for a flow which is =20 > not on > any list, then it is rejected (i.e. the default behavior is to drop =20 > such > messages.) If a join is received by AN for a flow that matches =20 > multiple > lists, then a deterministic algorithm (to be specified in ancp-=20 > protocol) > is used by the AN to decide which list behavior takes precedence. > Following are some example scenarios: > > Scenario 1: > * no config: > =3D=3D> any Join message gets rejected by AN > > Scenario 2: > * White List =3D { , , ... = } > =3D=3D> Join ( S=3D*,G=3DGi) gets honored by AN ( 1<=3Di<=3Dn ) > =3D=3D> everything else gets rejected by AN > > Scenario 3: > * White List =3D { , , ... = } > * Grey List =3D { } m>n > =3D=3D> Join ( S=3D*,G=3DGi) gets honored by AN ( 1<=3Di<=3Dn ) > =3D=3D> Join ( S=3Ds,G=3DGm) triggers ANCP Admission Request to NAS > =3D=3D> everything else gets rejected by AN > > > Section 3.4.2 > > Replace: > " One approach is for the AN to query the NAS so that both unicast > and multicast CAC for the access line are performed by the NAS. > In this case, the AN can use ANCP to query the NAS, that in turn > performs multicast CAC and responds to the AN indicating whether > the join is to be honored (and hence replication performed by =20 > the > AN) or denied. In the process, the NAS may communicate with a > Policy Server. > " > With: > " One approach is for the AN to query the NAS so that both unicast > and multicast CAC for the access line are performed by the NAS. > In this case, upon receiving a join to a multicast flow which > matches the Grey List, the AN can use ANCP to query the NAS, that in > turn > performs multicast CAC and responds to the AN indicating whether > the join is to be honored (and hence replication performed by =20 > the > AN) or denied. In the process, the NAS may communicate with a > Policy Server. > > > Section 4.2 > Replace > " The ANCP MUST support providing multicast conditional access > information to Access Ports on an Access Node, using Black lists > and White lists. " > By > " The ANCP MUST support providing multicast conditional access > information to Access Ports on an Access Node, using Black, Grey > and White lists. " > > Replace > > "The ANCP MUST support binding a particular Black list and White > List to a given Access Port" > By: > > " The ANCP MUST support binding a particular Black, Grey and White > List to a given Access Port > " > Replace: > > The ANCP MUST support partial updates of the White lists and Black > lists. > by > The ANCP MUST support partial updates of the White, Grey and Black > lists. > > Replace: > The ANCP MUST allow the AN to query the NAS to request an > admission decision for replicating a multicast flow to a > particular Access Port. > > By > Upon receiving a join to a multicast flow which matches the Grey List > the ANCP MUST allow the AN to query the NAS to request an admission > decision for replicating that multicast flow to a particular Access > Port. > > > > Section 4.7.6 > Replace and split in two > > " Upon receiving a join to a multicast flow which does not match any > entry in the Black List nor in the White List for a specific > Access Port, the AN must support using ANCP to query the NAS to > receive a response indicating whether that join is to be honored > or denied." > > By: > > " Upon receiving a join to a multicast flow which matches the Grey =20 > List > for a specific Access Port, the AN must support using ANCP to =20 > query the > NAS to receive a response indicating whether that join is to be =20 > honored > or denied. > " > " The AN must deny any join to a multicast flow that does not match =20 > any > entry in the Black List nor in the White List nor Grey List for > the relevant Access Port" > > > Adding the following requirements: > > "Upon receiving a join to a multicast flow which matches the Grey =20 > List, > AN is not allowed to propagate that join request, before the =20 > successful > authorization from the NAS is received." > > "Upon receiving a leave to a multicast flow which matches the Grey =20 > List, > AN SHOULD be able to autonomously stop replication and SHOULD be =20 > able to > advertise this event to the NAS." > > > Section 4.8.6 > Adding: > The NAS MUST support using ANCP to incrementally add, remove and =20 > modify > individual entries in White, Black and Grey lists. > > > ------------------------------------------------------- > Roberta Maglione - CCIE #18425 > Telecom Italia > Broadband Network Services Innovation > ------------------------------------------------------- > ________________________________________ > From: Michel Platnic [mailto:Michel.Platnic@ecitele.com] > Sent: Tuesday, July 24, 2007 8:22 PM > To: Francois Le Faucheur IMAP > Cc: Garofalo Angelo; ancp@ietf.org > Subject: RE: [ANCP] Comments on draft-maglione > > Hi Francois, > Please see my comments inline, > Regards, > Michel. > > > ________________________________________ > From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com] > Sent: Mon 7/23/2007 6:23 PM > To: Michel Platnic > Cc: Francois Le Faucheur IMAP; OOGHE Sven; ancp@ietf.org; > angelo.garofalo@telecomitalia.it > Subject: Re: [ANCP] Comments on draft-maglione Hi Michel, > > > > Using access control capabilities within the access network > provides the two main following benefits: > - refrain from sending any content to a customer that was not paid for > (mostly relevant when Encryption is not used) > - provides a filter against end-user applications/hackers that may =20 > send > IGMP requests with invalid IP address > > A solution where all the IP addresses that are not part of either the > Black-list or the White-List are sent to a central policy server for > authorization gives me some concerns regarding the robustness of the > whole system. Same concern regarding the treatment of unknown IP =20 > source > addresses ('Everything else'). > > Agreed. We had these concerns in mind also. This is why the Black-=20 > Lists > and White-Lists include the ability to define arbitrarily large > ranges/masks. In particular, as an example, one can easily define a > Black-List which contains a single "catch-all" entry that matches any > Multicast address & Source. Then you can define a White-List with the > explicit channels you want to allow. This effectively implements a > policy whereby everything is blocked by AN, except the channels that > have been explicitly allowed in the White-List. > In other words, the Black-List can be used for explicit listing of > channels, or it can easily be used as a "catch-all" (for all, or for > arbitrarily large ranges of channels). > > This should address your concern of making sure that the "default" > behavior for any non-explicitly defined channel is not to query > NAS/Central_server. > > See in draft-maglione: > " > The White List and Black List can contain entries allowing: > o an exact match for a (*,G) ASM group (e.g. ) > o an exact match for a (S,G) SSM channel (e.g. =20 > > > o a mask-based range match for a (*,G) ASM group (e.g. > ) > o a mask-based range match for a (S,G) SSM channel (e.g. > > " > Let me try to rephrase your proposal; there would be a =20 > default > state wherein any channel being neither part of White-list nor > Black-list would be discarded. > If its the case I agree with you that this solution solves the =20 > security > issue. > > But what about when AN is not in this default state? > If "Accept everything else" is used then again same problem of =20 > security > is encountered, and any hacker or application can overload the policy > server with requests. > To my understanding, the model proposed, where the NAS is getting the > customer request for authorization, requires this mode of operation. > So we still have the same problem. > Did I miss anything? > > > ______________________________________________________________________ > __ > ______ > I understand that some applications may require sophisticated policy > decision making and that, as a matter of fact, some AN/central policy > server synchronization mechanism should to be proposed, but the =20 > solution > must be Robust and Scalable. > For now I am not convinced that solution proposed is either Robust or > Scalable. > > Let us know if you have specific robustness/scalability concerns =20 > (beyond > the one discussed above)? > Then we could work together on addressing those. > > Well, there is still this scalable issue when duplicating =20 > the > messages that need to be treated in real-time by the NAS. Sven already > made some counting regarding this topic. I believe this point could =20 > lead > to scalability issues. If we had the above described potential =20 > disaster, > then we end-up getting serious Robustness issues. > > > Thanks > > Francois > > > Regards, > Michel. > -------------------------------------------------------------------- > > CONFIDENTIALITY NOTICE > > This message and its attachments are addressed solely to the persons > above and may contain confidential information. If you have =20 > received the > message in error, be informed that any use of the content hereof is > prohibited. Please return it immediately to the sender and delete the > message. Should you have any questions, please contact us by =20 > replying to > webmaster@telecomitalia.it. > > Thank you > > www.telecomitalia.it > > -------------------------------------------------------------------- > > > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www1.ietf.org/mailman/listinfo/ancp > > -------------------------------------------------------------------- > > CONFIDENTIALITY NOTICE > > This message and its attachments are addressed solely to the =20 > persons above and may contain confidential information. If you have =20 > received the message in error, be informed that any use of the =20 > content hereof is prohibited. Please return it immediately to the =20 > sender and delete the message. Should you have any questions, =20 > please contact us by replying to webmaster@telecomitalia.it. > > Thank you > > www.telecomitalia.it > > -------------------------------------------------------------------- > > > > _______________________________________________ > 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 Tue Nov 27 08:54:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix0tU-0007i0-Cl; Tue, 27 Nov 2007 08:54:32 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1Ix0tT-0007hi-3w for ancp-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 08:54:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix0tS-0007hY-QR for ancp@ietf.org; Tue, 27 Nov 2007 08:54:30 -0500 Received: from smail5.alcatel.fr ([62.23.212.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix0tQ-0005Bh-VV for ancp@ietf.org; Tue, 27 Nov 2007 08:54:30 -0500 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 lARDqshp012224; Tue, 27 Nov 2007 14:52:56 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.52]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 27 Nov 2007 14:54:24 +0100 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: Spontaneous Admission Response (was Re: [ANCP] ANCP WG follow-up) Date: Tue, 27 Nov 2007 14:54:23 +0100 Message-ID: <8144761F31F48D43AD53D09F5350E380020DEE9E@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Spontaneous Admission Response (was Re: [ANCP] ANCP WG follow-up) Thread-Index: AcgwMk7bE1qJaT23R6+62Sh41FjgVAAx5Gig References: <9BD5D7887235424FA97DFC223CAE3C2803B76378@proton.jnpr.net><54469D09-60CF-4AE8-8BAD-A26B9E256113@cisco.com> <8144761F31F48D43AD53D09F5350E380020695B0@FRVELSMBS22.ad2.ad.alcatel.com> <8144761F31F48D43AD53D09F5350E38002069770@FRVELSMBS22.ad2.ad.alcatel.com> <26E82396-E20F-4248-B63E-6A82E14D0D65@cisco.com> <8144761F31F48D43AD53D09F5350E38002069932@FRVELSMBS22.ad2.ad.alcatel.com> From: "OOGHE Sven" To: "Francois Le Faucheur IMAP" , "Wojciech Dec (wdec)" X-OriginalArrivalTime: 27 Nov 2007 13:54:24.0751 (UTC) FILETIME=[04EC3FF0:01C830FD] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a 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 Francois, all, Ok, so how about we write the following paragraph at the end of section 3.4.4 (modified text from your proposal): "In some deployment scenarios, the NAS may be made aware of end-users requests to join/leave a multicast flow by other means than ANCP Admission Requests sent by the AN. One possible deployment scenario where this model applies is the case where the Access Node doesn't process the IGMP join/leave messages from the end-user (e.g. because they are tunneled), but forwards them to the NAS. In such environments, the NAS can control multicast replication on the AN via ANCP through the use of Spontaneous Admission Responses (i.e. sent by the NAS without prior receipt of a corresponding Admission Request)." How does that sound? Regards, Sven -----Original Message----- From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com]=20 Sent: maandag 26 november 2007 14:43 To: OOGHE Sven; Wojciech Dec (wdec) Cc: Francois Le Faucheur IMAP; ancp@ietf.org; Maglione Roberta Subject: Re: Spontaneous Admission Response (was Re: [ANCP] ANCP WG follow-up) Sven, Woj, >> >> The WG has already concluded on the debate about perceived need "to=20 >> reduce the NAS load" when considering the Grey List. >> I believe the conclusion was that while some perceive it is desirable >> to reduce the NAS load as much as possible, a significant part of the >> WG felt it is desirable to be able to take advantage of NAS=20 >> capabilities for replication control. >> As a result, the WG decided that ANCP ought to : >> - allow operation where replication control is done in AN, >> - also allow operation where replication control is done by NAS=20 >> (hence the notion of Grey lists). >> >> I understood the conclusion was that it is desirable to reduce >> the NAS load, while also supporting mechanisms for the NAS to control >> replication. Blindly forwarding all IGMP reports to the NAS, followed >> by ANCP to the AN seems to contradict this. There needs to be some=20 >> way to reduce the load (see above remark). > > Woj> Sanjay's mail raised a valid observation about alternative > deployment scenarios, where IGMP processing on the AN is disabled. One > should generalise this argument further and totally decouple it from=20 > IGMP - the proposed spontaneous control mechanism provides such=20 > decoupling. The evaluation of what load can a NAS handle depends on=20 > numerous other factors than just IGMP processing, and should not be=20 > the only goal for laying down the requirements ANCP functionality. In=20 > terms of such functionality thus, ANCP should be capable of addressing > multicast deployment scenarios decoupled from IGMP assumptions. I see=20 > the proposal as one filling this gap. > The proposal submitted on the alias leaves it entirely open as to how the join/leave information is conveyed to NAS. It mentions tunneling IGMP joins/leaves to the NAS purely as an example. Alternatively, it could be done by sending IGMP Join/Leaves to both the NAS and the AN (and have NAS use this as a trigger to push to AN authorisation for a group of flows sharing same conditional/admission control rules - and then have AN do autonomous decision within the group and possibly also process leaves). Alternatively, it could be done using another protocol than IGMP. Is it not acceptable to leave this open so ANCP allows all these deployment models (particularly considering it does not seem to require any extra extensions to ANCP: all we need is the Spontaneous Admission Response). Why would we prevent some of these deployment models? Perhaps we could change the wording in order to: * make it very clear that tunneling IGMP join/leave to NAS is just an example deployment model * there are other deployment models * describe another deployment model along the lines of what Sven discussed (ie I think with NAS doing some initial processing and then AN doing subsequent processing, eg using the concept that we used to call "flow-group"). How does that sound? Francois _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Tue Nov 27 10:04: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 1Ix1yp-0004Mg-DQ; Tue, 27 Nov 2007 10:04:07 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1Ix1yo-0004MY-Na for ancp-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 10:04:06 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix1yo-0004MO-Bw for ancp@ietf.org; Tue, 27 Nov 2007 10:04:06 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ix1yn-0003PQ-FA for ancp@ietf.org; Tue, 27 Nov 2007 10:04:06 -0500 X-IronPort-AV: E=Sophos;i="4.23,220,1194217200"; d="scan'208";a="158905826" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 27 Nov 2007 16:03:58 +0100 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 lARF3wd2012526; Tue, 27 Nov 2007 16:03:58 +0100 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 lARF3a3v015476; Tue, 27 Nov 2007 15:03:58 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 16:03:46 +0100 Received: from [144.254.53.159] ([144.254.53.159]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 16:03:45 +0100 In-Reply-To: <8144761F31F48D43AD53D09F5350E380020DEE9E@FRVELSMBS22.ad2.ad.alcatel.com> References: <9BD5D7887235424FA97DFC223CAE3C2803B76378@proton.jnpr.net><54469D09-60CF-4AE8-8BAD-A26B9E256113@cisco.com> <8144761F31F48D43AD53D09F5350E380020695B0@FRVELSMBS22.ad2.ad.alcatel.com> <8144761F31F48D43AD53D09F5350E38002069770@FRVELSMBS22.ad2.ad.alcatel.com> <26E82396-E20F-4248-B63E-6A82E14D0D65@cisco.com> <8144761F31F48D43AD53D09F5350E38002069932@FRVELSMBS22.ad2.ad.alcatel.com> <8144761F31F48D43AD53D09F5350E380020DEE9E@FRVELSMBS22.ad2.ad.alcatel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8A2252E0-6E9C-4566-BE8C-BFB96126B720@cisco.com> Content-Transfer-Encoding: 7bit From: Francois Le Faucheur IMAP Subject: Re: Spontaneous Admission Response (was Re: [ANCP] ANCP WG follow-up) Date: Tue, 27 Nov 2007 16:03:39 +0100 To: "OOGHE Sven" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 27 Nov 2007 15:03:45.0525 (UTC) FILETIME=[B4EFFA50:01C83106] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4546; t=1196175838; x=1197039838; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Re=3A=20Spontaneous=20Admission=20Response=20(was=20Re=3A=20[ ANCP]=20ANCP=20WG=20follow-up) |Sender:=20; bh=/CBDfgo9c1Axd/gL/VEvV2lOmX/peS720Jv55nwKQOU=; b=gwgao2gQ7+cY8re2CzoYAx2N/rIMdIJzyU/fTkJxGV3kx9ekiTldoFRmBYYPtUQ/JpRpmrnv paJJdffeCdwm49FW3DGVI0sBLQpz895c2yTK3XbmzhC7GJqkuedcL8YV; Authentication-Results: ams-dkim-2; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b 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 On 27 Nov 2007, at 14:54, OOGHE Sven wrote: > Francois, all, > > Ok, so how about we write the following paragraph at the end of > section > 3.4.4 (modified text from your proposal): > > "In some deployment scenarios, the NAS may be made aware of end-users > requests to join/leave a multicast flow by other means than ANCP > Admission Requests sent by the AN. One possible deployment scenario > where this model applies is the case where the Access Node doesn't > process the IGMP join/leave messages from the end-user (e.g. because > they are tunneled), but forwards them to the NAS. In such > environments, > the NAS can control multicast replication on the AN via ANCP > through the > use of Spontaneous Admission Responses (i.e. sent by the NAS without > prior receipt of a corresponding Admission Request)." > > How does that sound? That works for me. I assume 3.4.4 title would be changed accordingly to something like "3.4.4 Spontaneous Admission Responses". Cheers Francois > > Regards, > Sven > > -----Original Message----- > From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com] > Sent: maandag 26 november 2007 14:43 > To: OOGHE Sven; Wojciech Dec (wdec) > Cc: Francois Le Faucheur IMAP; ancp@ietf.org; Maglione Roberta > Subject: Re: Spontaneous Admission Response (was Re: [ANCP] ANCP WG > follow-up) > > Sven, Woj, > >>> >>> The WG has already concluded on the debate about perceived need "to >>> reduce the NAS load" when considering the Grey List. >>> I believe the conclusion was that while some perceive it is >>> desirable > >>> to reduce the NAS load as much as possible, a significant part of >>> the > >>> WG felt it is desirable to be able to take advantage of NAS >>> capabilities for replication control. >>> As a result, the WG decided that ANCP ought to : >>> - allow operation where replication control is done in AN, >>> - also allow operation where replication control is done by NAS >>> (hence the notion of Grey lists). >>> >>> I understood the conclusion was that it is desirable to >>> reduce > >>> the NAS load, while also supporting mechanisms for the NAS to >>> control > >>> replication. Blindly forwarding all IGMP reports to the NAS, >>> followed > >>> by ANCP to the AN seems to contradict this. There needs to be some >>> way to reduce the load (see above remark). >> >> Woj> Sanjay's mail raised a valid observation about alternative >> deployment scenarios, where IGMP processing on the AN is disabled. >> One > >> should generalise this argument further and totally decouple it from >> IGMP - the proposed spontaneous control mechanism provides such >> decoupling. The evaluation of what load can a NAS handle depends on >> numerous other factors than just IGMP processing, and should not be >> the only goal for laying down the requirements ANCP functionality. In >> terms of such functionality thus, ANCP should be capable of >> addressing > >> multicast deployment scenarios decoupled from IGMP assumptions. I see >> the proposal as one filling this gap. >> > > The proposal submitted on the alias leaves it entirely open > as to how the join/leave information is conveyed to NAS. > It mentions tunneling IGMP joins/leaves to the NAS purely as an > example. > Alternatively, it could be done by sending IGMP Join/Leaves to both > the > NAS and the AN (and have NAS use this as a trigger to push to AN > authorisation for a group of flows sharing same conditional/admission > control rules - and then have AN do autonomous decision within the > group > and possibly also process leaves). > Alternatively, it could be done using another protocol than IGMP. > > Is it not acceptable to leave this open so ANCP allows all these > deployment models (particularly considering it does not seem to > require > any extra extensions to ANCP: all we need is the Spontaneous Admission > Response). > Why would we prevent some of these deployment models? > > Perhaps we could change the wording in order to: > * make it very clear that tunneling IGMP join/leave to NAS is > just an example deployment model > * there are other deployment models > * describe another deployment model along the lines of what Sven > discussed (ie I think with NAS doing some initial processing and > then AN > doing subsequent processing, eg using the concept that we used to call > "flow-group"). > > How does that sound? > > Francois _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Tue Nov 27 10:20:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix2Ef-00013j-Rf; Tue, 27 Nov 2007 10:20:29 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1Ix2Ef-00013S-9j for ancp-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 10:20:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix2Ee-00013H-W7 for ancp@ietf.org; Tue, 27 Nov 2007 10:20:28 -0500 Received: from gc-na5.alcatel.fr ([64.208.49.5] helo=smail6.alcatel.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix2Ed-00044B-12 for ancp@ietf.org; Tue, 27 Nov 2007 10:20:28 -0500 Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.ad2.ad.alcatel.com [155.132.6.76]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id lARFIrbd012406; Tue, 27 Nov 2007 16:18:53 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.52]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 27 Nov 2007 16:20:19 +0100 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: Spontaneous Admission Response (was Re: [ANCP] ANCP WG follow-up) Date: Tue, 27 Nov 2007 16:20:18 +0100 Message-ID: <8144761F31F48D43AD53D09F5350E380020DEFB3@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <8A2252E0-6E9C-4566-BE8C-BFB96126B720@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Spontaneous Admission Response (was Re: [ANCP] ANCP WG follow-up) Thread-Index: AcgxBr9+LtMBT9pkSgWcCCgTV29ZogAAeVWA References: <9BD5D7887235424FA97DFC223CAE3C2803B76378@proton.jnpr.net><54469D09-60CF-4AE8-8BAD-A26B9E256113@cisco.com> <8144761F31F48D43AD53D09F5350E380020695B0@FRVELSMBS22.ad2.ad.alcatel.com> <8144761F31F48D43AD53D09F5350E38002069770@FRVELSMBS22.ad2.ad.alcatel.com> <26E82396-E20F-4248-B63E-6A82E14D0D65@cisco.com> <8144761F31F48D43AD53D09F5350E38002069932@FRVELSMBS22.ad2.ad.alcatel.com> <8144761F31F48D43AD53D09F5350E380020DEE9E@FRVELSMBS22.ad2.ad.alcatel.com> <8A2252E0-6E9C-4566-BE8C-BFB96126B720@cisco.com> From: "OOGHE Sven" To: "Francois Le Faucheur IMAP" X-OriginalArrivalTime: 27 Nov 2007 15:20:19.0991 (UTC) FILETIME=[05AF7270:01C83109] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 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 Francois, The title would need to be changed, correct.=20 Regards, Sven -----Original Message----- From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com]=20 Sent: dinsdag 27 november 2007 16:04 To: OOGHE Sven Cc: Francois Le Faucheur IMAP; Wojciech Dec (wdec); ancp@ietf.org; Maglione Roberta Subject: Re: Spontaneous Admission Response (was Re: [ANCP] ANCP WG follow-up) On 27 Nov 2007, at 14:54, OOGHE Sven wrote: > Francois, all, > > Ok, so how about we write the following paragraph at the end of=20 > section > 3.4.4 (modified text from your proposal): > > "In some deployment scenarios, the NAS may be made aware of end-users=20 > requests to join/leave a multicast flow by other means than ANCP=20 > Admission Requests sent by the AN. One possible deployment scenario=20 > where this model applies is the case where the Access Node doesn't=20 > process the IGMP join/leave messages from the end-user (e.g. because=20 > they are tunneled), but forwards them to the NAS. In such=20 > environments, the NAS can control multicast replication on the AN via=20 > ANCP through the use of Spontaneous Admission Responses (i.e. sent by=20 > the NAS without prior receipt of a corresponding Admission Request)." > > How does that sound? That works for me. I assume 3.4.4 title would be changed accordingly to something like "3.4.4 Spontaneous Admission Responses". Cheers Francois > > Regards, > Sven > > -----Original Message----- > From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com] > Sent: maandag 26 november 2007 14:43 > To: OOGHE Sven; Wojciech Dec (wdec) > Cc: Francois Le Faucheur IMAP; ancp@ietf.org; Maglione Roberta > Subject: Re: Spontaneous Admission Response (was Re: [ANCP] ANCP WG > follow-up) > > Sven, Woj, > >>> >>> The WG has already concluded on the debate about perceived need "to=20 >>> reduce the NAS load" when considering the Grey List. >>> I believe the conclusion was that while some perceive it is=20 >>> desirable > >>> to reduce the NAS load as much as possible, a significant part of=20 >>> the > >>> WG felt it is desirable to be able to take advantage of NAS=20 >>> capabilities for replication control. >>> As a result, the WG decided that ANCP ought to : >>> - allow operation where replication control is done in AN, >>> - also allow operation where replication control is done by NAS=20 >>> (hence the notion of Grey lists). >>> >>> I understood the conclusion was that it is desirable to=20 >>> reduce > >>> the NAS load, while also supporting mechanisms for the NAS to=20 >>> control > >>> replication. Blindly forwarding all IGMP reports to the NAS,=20 >>> followed > >>> by ANCP to the AN seems to contradict this. There needs to be some=20 >>> way to reduce the load (see above remark). >> >> Woj> Sanjay's mail raised a valid observation about alternative >> deployment scenarios, where IGMP processing on the AN is disabled. =20 >> One > >> should generalise this argument further and totally decouple it from=20 >> IGMP - the proposed spontaneous control mechanism provides such=20 >> decoupling. The evaluation of what load can a NAS handle depends on=20 >> numerous other factors than just IGMP processing, and should not be=20 >> the only goal for laying down the requirements ANCP functionality. In >> terms of such functionality thus, ANCP should be capable of=20 >> addressing > >> multicast deployment scenarios decoupled from IGMP assumptions. I see >> the proposal as one filling this gap. >> > > The proposal submitted on the alias leaves it entirely open > as to how the join/leave information is conveyed to NAS. > It mentions tunneling IGMP joins/leaves to the NAS purely as an=20 > example. > Alternatively, it could be done by sending IGMP Join/Leaves to both=20 > the NAS and the AN (and have NAS use this as a trigger to push to AN=20 > authorisation for a group of flows sharing same conditional/admission=20 > control rules - and then have AN do autonomous decision within the=20 > group and possibly also process leaves). > Alternatively, it could be done using another protocol than IGMP. > > Is it not acceptable to leave this open so ANCP allows all these=20 > deployment models (particularly considering it does not seem to=20 > require any extra extensions to ANCP: all we need is the Spontaneous=20 > Admission Response). > Why would we prevent some of these deployment models? > > Perhaps we could change the wording in order to: > * make it very clear that tunneling IGMP join/leave to NAS is just an=20 > example deployment model > * there are other deployment models > * describe another deployment model along the lines of what Sven > discussed (ie I think with NAS doing some initial processing and then=20 > AN doing subsequent processing, eg using the concept that we used to=20 > call "flow-group"). > > How does that sound? > > Francois _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Tue Nov 27 13:22:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix55G-0001qi-1C; Tue, 27 Nov 2007 13:22:58 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1Ix55F-0001qX-Eg for ancp-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 13:22:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix55F-0001qP-56 for ancp@ietf.org; Tue, 27 Nov 2007 13:22:57 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix55C-0000sT-PJ for ancp@ietf.org; Tue, 27 Nov 2007 13:22:57 -0500 X-IronPort-AV: E=Sophos;i="4.23,220,1194217200"; d="scan'208";a="158927886" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 27 Nov 2007 19:22:43 +0100 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 lARIMhF0028233; Tue, 27 Nov 2007 19:22:43 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lARIMc3Z029617; Tue, 27 Nov 2007 18:22:43 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 19:22:38 +0100 Received: from [144.254.53.159] ([144.254.53.159]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 19:22:38 +0100 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Francois Le Faucheur Date: Tue, 27 Nov 2007 19:22:32 +0100 To: ancp@ietf.org X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 27 Nov 2007 18:22:38.0418 (UTC) FILETIME=[7D7EF320:01C83122] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7577; t=1196187763; x=1197051763; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20 |Subject:=20Enhanced=20text=20on=20ANCP=20Accounting/Reporting=20(for=20A NCP=20Framework) |Sender:=20; bh=SP/ijxDJ41yx2fJP0UcAscohRJ6CkPlZLdureMy/XQI=; b=d/J/ItvgRNxf14JGbdATK/TkvWUfd9c1aGWb90wZ2P0hqhap6pnRm2zu2/VPLi1Nt9rohDG1 Ozcye28Ps6dENaakrsnp0xeojOZg5i7xZy7p3s1Ebgod+2QNQ6WESsdK; Authentication-Results: ams-dkim-1; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Cc: Subject: [ANCP] Enhanced text on ANCP Accounting/Reporting (for ANCP Framework) 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 Hello, The first part of this message proposes text changes in order to bring the accounting related text in line with recent discussions on Grey/White lists and Spontaneous Admission Response. The second part of this message proposes additional text to support a new Reporting capability whereby the NAS can query what multicast flows are currently being replicated on which AN ports (in particular for troubleshooting/monitoring purposes). We would like to solicit feedback on those two. Francois & Roberta ============================================================= text changes to bring the ANCP accounting text in line with recent discussions on Grey/White lists and Spontaneous Admission Response: in Section "3.4.3 Multicast Accounting" replace: " o The AN keeps track of when replication starts or stops, and reports this information to the NAS for further processing. In this case, ANCP can be used to send the information from the AN to the NAS. This can be done with the Information Report message. The NAS can then generate the appropriate time and/or volume accounting information per Access Loop and per multicast flow, to be sent to the accounting system. The ANCP requirements to support this approach are specified in this document. " by " o The AN keeps track of when replication for a given multicast flow starts or stops and then the AN can convey time and/or volume information to the NAS for further processing. This approach relies on ANCP and is discussed below. The NAS specifies if accounting is needed for a particular multicast flow; for Multicast flows whose replication is controlled by the NAS (eg those belonging to the Grey list) this can be conveyed in the ANCP Admission Response message sent from NAS to AN. For Multicast flows whose replication is controlled by the AN via the White list, the AN starts the multicast replication without querying the NAS and thus the NAS does not send Admission Response message; in this case the need for accounting is conveyed by the NAS in the White list during the White list provisioning phase. The AN communicates accounting information to the NAS using the Information Report message. In case of very fast channel changes, in order to reduce the number of Information Report messages sent from the AN to the NAS to convey accounting information, the AN can consolidate multiple sets of accounting information inside a single ANCP message. Upon receiving the Accounting information from the AN, the NAS can then generate the appropriate time and/or volume accounting information per Access port and per multicast flow, to be sent to the accounting system. The ANCP requirements to support this use case are specified below in this document. " in Section 4.2 Replace " The ANCP MUST allow the NAS to indicate to the AN when multicast accounting information is required for a multicast flow on a particular Access Port. " by " The ANCP MUST allow the NAS to indicate to the AN when multicast accounting is needed for a multicast flow on a particular Access Port. This information needs to be conveyed inside Admission Response for multicast flows whose replication is controlled by NAS, and be conveyed inside the White list for multicast flows whose replication is controlled by AN" in Section 4.7.6 Replace: "The AN must support using ANCP to send information to the NAS about when replication starts/stops for the port/multicast flow." by "When Accounting is needed for a multicast flow, the AN MUST support using ANCP to send Information Report to the NAS whenever replication starts/stops for the port/multicast flow. The accounting information sent on replication stop MUST indicate the duration of replication time for a multicast flow and the number of replicated octects/packets for a port/multicast flow. " in Section 4.8.6 Replace: "The NAS must support using ANCP to indicate to the AN whether or not multicast accounting information is required for a multicast flow on a particular Access Port." by "The NAS must support using ANCP to indicate to the AN (in White LIst and in Admission Response) whether multicast accounting information is required for a multicast flow on a particular Access Port and what type ." replace: " The NAS must support using ANCP to receive information about when replication starts/stops for a multicast flow on a particular Access Port." by " o The NAS must support using ANCP to receive accounting information for a multicast flow on a particular Access Port." ========================================================= additional text to support a Reporting capability whereby the NAS can query what multicast flow is current being replicated on which AN ports (in particular for troubleshooting/monitoring purposes). replace: "3.4.3 Multicast Accounting" by "3.4.3 Multicast Accounting and Reporting" At the end of section 3.4,3, add the following: " It is desirable for a NAS to have the capability to asynchronously query the AN to obtain an instantaneous report status related to multicast flows currently replicated by the AN. Such a reporting functionality could be useful for troubleshooting and monitoring purposes. Three different types of report-query from NAS to AN can be identified: o "Port Report-Query" in which the NAS queries the AN to know which flows are currently active on a specific port; o "Multicast Flow Report-Query" in which the NAS queries the AN to know on which ports the specified multicast flow is currently active; o "AN global Report-Query" in which the NAS queries the AN to know all multicast flows currently active on all AN ports. " In section 4.2, add the following: " o The ANCP MUST support the ability for the NAS to query the AN, and to obtain a reply, about what multicast flows are currently replicated on a given AN port, what AN ports are currently sent replication for a given multicast flow, or about what multicast flows are currently replicated on every AN port." In section 4.7.6, add the following: " o On receiving a "Port Report-Query" the AN must reply to the NAS providing the list of active multicast flows on that specific port and how long each flow has been replicated since the first IGMP membership report for that group was received o On receiving a " Multicast Flow Report-Query " the AN must reply to the NAS providing the list of ports where this multicast flow is currently replicated and how long that flow has been replicated on each port since the first IGMP membership report for that group was received. o On receiving a " AN global Report-Query " the AN must reply to the NAS providing the list of all multicast flows currently replicated on each port and how long each flow has been replicated since the first IGMP membership report for that group was received. " In section 4.8.6, add the following: " o The NAS must support using ANCP to query the AN to know which flows are currently active on a specific port; o The NAS must support using ANCP to query the AN to know on which ports a specific multicast flow is currently active; o The NAS must support using ANCP to query the AN to know all multicast flows currently active on all AN ports. " _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Thu Nov 29 05:30:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxgfR-0004Ka-Io; Thu, 29 Nov 2007 05:30:49 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IxgfQ-0004Fh-F2 for ancp-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 05:30:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxgfP-0004FX-Mz for ancp@ietf.org; Thu, 29 Nov 2007 05:30:48 -0500 Received: from smail5.alcatel.fr ([64.208.49.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxgfP-00022V-54 for ancp@ietf.org; Thu, 29 Nov 2007 05:30:47 -0500 Received: from FRVELSBHS07.ad2.ad.alcatel.com (frvelsbhs07.ad2.ad.alcatel.com [155.132.6.79]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id lATATE8l022684 for ; Thu, 29 Nov 2007 11:29:14 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.52]) by FRVELSBHS07.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 29 Nov 2007 11:30:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 29 Nov 2007 11:30:44 +0100 Message-ID: <8144761F31F48D43AD53D09F5350E3800212CA10@FRVELSMBS22.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Framework requirement Thread-Index: AcgycuXstDADZrOnRBW7Z254R1Qesg== From: "OOGHE Sven" To: X-OriginalArrivalTime: 29 Nov 2007 10:30:45.0312 (UTC) FILETIME=[E6655400:01C83272] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Subject: [ANCP] Framework requirement 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="===============0526993572==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0526993572== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C83272.E5FBBE70" This is a multi-part message in MIME format. ------_=_NextPart_001_01C83272.E5FBBE70 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, draft-ietf-ancp-framework-03.txt and 04 mention following requirement in section 4.8.6: "The NAS must support using ANCP to configure the Access Node with the=20 "maximum number of multicast streams" allowed to be received=20 concurrently per Access Port. " This requirements was not part of draft-maglione. I would like to check if people on this list are comfortable with this requirement. So far I have not heard anyone oppose this requirement. Regards, Sven ------_=_NextPart_001_01C83272.E5FBBE70 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Framework requirement

Hi,

draft-ietf-ancp-framework-03.txt and 04 = mention following requirement in section 4.8.6:

"The NAS must support using = ANCP to configure the Access Node with the
"maximum number of = multicast streams" allowed to be received
concurrently per Access Port. = "

This requirements was not part of = draft-maglione. I would like to check if people on this list are = comfortable with this requirement. So far I have not heard anyone oppose = this requirement.

Regards,
Sven

------_=_NextPart_001_01C83272.E5FBBE70-- --===============0526993572== 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 --===============0526993572==-- From ancp-bounces@ietf.org Fri Nov 30 01:31:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxzPN-0004n1-RI; Fri, 30 Nov 2007 01:31:29 -0500 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IxzPN-0004mp-8Q for ancp-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 01:31:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxzPM-0004ma-Oj for ancp@ietf.org; Fri, 30 Nov 2007 01:31:28 -0500 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxzPM-0008Ex-54 for ancp@ietf.org; Fri, 30 Nov 2007 01:31:28 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id A71F460B89; Thu, 29 Nov 2007 22:31:27 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25933-03; Thu, 29 Nov 2007 22:31:27 -0800 (PST) Received: from PARBETM2XP2 (unknown [172.31.253.158]) by prattle.redback.com (Postfix) with ESMTP id 4417560B85; Thu, 29 Nov 2007 22:31:27 -0800 (PST) From: "Peter Arberg" To: "'OOGHE Sven'" , Subject: RE: [ANCP] Framework requirement Date: Fri, 30 Nov 2007 07:30:53 +0100 Organization: Redback Networks Inc. Message-ID: <000701c8331a$90a46bc0$0a01a8c0@ad.redback.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcgycuXstDADZrOnRBW7Z254R1QesgAa9cSg In-Reply-To: <8144761F31F48D43AD53D09F5350E3800212CA10@FRVELSMBS22.ad2.ad.alcatel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: parberg@redback.com 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="===============0823034637==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0823034637== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C83322.F268D3C0" This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C83322.F268D3C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Sven, the requirement looks reasonable to me. cheers, Peter _____ From: OOGHE Sven [mailto:Sven.Ooghe@alcatel-lucent.be] Sent: 29. november 2007 11:31 To: ancp@ietf.org Subject: [ANCP] Framework requirement Hi, draft-ietf-ancp-framework-03.txt and 04 mention following requirement in section 4.8.6: "The NAS must support using ANCP to configure the Access Node with the "maximum number of multicast streams" allowed to be received concurrently per Access Port. " This requirements was not part of draft-maglione. I would like to check if people on this list are comfortable with this requirement. So far I have not heard anyone oppose this requirement. Regards, Sven ------=_NextPart_000_0008_01C83322.F268D3C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Framework requirement
Hi Sven,
 
the requirement looks reasonable to = me.
 
cheers,
Peter

From: OOGHE Sven=20 [mailto:Sven.Ooghe@alcatel-lucent.be]
Sent: 29. november = 2007=20 11:31
To: ancp@ietf.org
Subject: [ANCP] Framework=20 requirement

Hi,

draft-ietf-ancp-framework-03.txt and 04 = mention=20 following requirement in section 4.8.6:

"The NAS must support using = ANCP to=20 configure the Access Node with the
"maximum number of multicast streams" allowed to be received=20
concurrently per Access = Port.=20 "

This requirements was not part of = draft-maglione. I=20 would like to check if people on this list are comfortable with this=20 requirement. So far I have not heard anyone oppose this=20 requirement.

Regards,
Sven

------=_NextPart_000_0008_01C83322.F268D3C0-- --===============0823034637== 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 --===============0823034637==--