From owner-ietf-ppp-outgoing@merit.edu Fri Dec 1 16:33:54 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA27902 for ; Fri, 1 Dec 2000 16:33:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 747A95DDC2; Fri, 1 Dec 2000 16:32:53 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5EEF05DDBE; Fri, 1 Dec 2000 16:32:53 -0500 (EST) Received: from mail.via-net.net (unknown [208.46.234.15]) by segue.merit.edu (Postfix) with ESMTP id 1E4B35DDB1 for ; Fri, 1 Dec 2000 16:32:52 -0500 (EST) Received: from karl.xc.org (ppp048.via-net.net [208.46.234.175]) by mail.via-net.net (Post.Office MTA v3.5.3 release 223 ID# 0-52517U2500L250S0V35) with ESMTP id net; Fri, 1 Dec 2000 16:33:15 -0500 Message-Id: <4.3.2.7.2.20001201161702.057c5850@127.0.0.1> X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 01 Dec 2000 16:32:50 -0500 To: agenda@ietf.org From: Karl Fox Subject: PPPEXT Working Group Agenda -- 49th IETF Cc: ietf-ppp@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Point-to-Point Extensions (PPPEXT) Working Group Tuesday, December 12, 1700-1800 PST 49th IETF, San Diego Agenda PPP Multiplexing draft-ietf-pppext-pppmux-01.txt Craig Fox 10 minutes Extending PPP over SONET/SDH with virtual concatenation draft-ietf-pppext-posvcholo-02.txt Nevin Jones 15 minutes Always On Dynamic ISDN (AODI) draft-ietf-pppext-aodi-00.txt Matt Holdrege 5 minutes PPPEXT Document Status and Call for Questionnaire Authors Karl Fox 30 minutes Karl Fox Key fingerprint = 4159 B4AD 339D 4E2A 255F 9CC4 9DA9 CB4B B16D E2B1 From owner-ietf-ppp-outgoing@merit.edu Fri Dec 1 16:38:20 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28714 for ; Fri, 1 Dec 2000 16:38:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6C32B5DDCE; Fri, 1 Dec 2000 16:37:56 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5B2725DDBE; Fri, 1 Dec 2000 16:37:56 -0500 (EST) Received: from mail.via-net.net (unknown [208.46.234.15]) by segue.merit.edu (Postfix) with ESMTP id 359E55DDB1 for ; Fri, 1 Dec 2000 16:37:55 -0500 (EST) Received: from karl.xc.org (ppp048.via-net.net [208.46.234.175]) by mail.via-net.net (Post.Office MTA v3.5.3 release 223 ID# 0-52517U2500L250S0V35) with ESMTP id net; Fri, 1 Dec 2000 16:38:18 -0500 Message-Id: <4.3.2.7.2.20001201163341.057cb720@127.0.0.1> X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 01 Dec 2000 16:37:53 -0500 To: agenda@ietf.org From: Karl Fox Subject: PPPEXT Working Group Agenda -- 49th IETF (corrected) Cc: ietf-ppp@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu [Please ignore the previous PPPEXT agenda. This is the real one.] Point-to-Point Extensions (PPPEXT) Working Group Tuesday, December 12, 1700-1800 PST 49th IETF, San Diego Agenda PPP Multiplexing draft-ietf-pppext-pppmux-01.txt Craig Fox 10 minutes Extending PPP over SONET/SDH with virtual concatenation draft-ietf-pppext-posvcholo-02.txt Nevin Jones 15 minutes Always On Dynamic ISDN (AODI) draft-ietf-pppext-aodi-00.txt Matt Holdrege 5 minutes IP/UDP/RTP Header Compression over AAL2 draft-buffam-avt-crtp-over-aal2-01.txt Bruce A Thompson 10 minutes PPPEXT Document Status and Call for Questionnaire Authors Karl Fox 20 minutes Karl Fox Key fingerprint = 4159 B4AD 339D 4E2A 255F 9CC4 9DA9 CB4B B16D E2B1 From owner-ietf-ppp-outgoing@merit.edu Fri Dec 1 16:57:08 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01788 for ; Fri, 1 Dec 2000 16:57:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1AF585DDB1; Fri, 1 Dec 2000 16:56:44 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 068E35DDBE; Fri, 1 Dec 2000 16:56:43 -0500 (EST) Received: from sapphire.int.ipverse.com (w067.z208037018.sjc-ca.dsl.cnc.net [208.37.18.67]) by segue.merit.edu (Postfix) with ESMTP id 7FB505DDB1 for ; Fri, 1 Dec 2000 16:56:42 -0500 (EST) Received: from matt.ipverse.com (lsanca1-ar5-208-116.dsl.gtei.net [4.33.208.116]) by sapphire.int.ipverse.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id XNX7NS2J; Fri, 1 Dec 2000 13:56:43 -0800 Message-Id: <5.0.2.1.2.20001201135540.02165170@pop3.ipverse.com> X-Sender: matt@ipverse.com@pop3.ipverse.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 01 Dec 2000 13:56:32 -0800 To: Karl Fox From: Matt Holdrege Subject: Re: PPPEXT Working Group Agenda -- 49th IETF (corrected) Cc: agenda@ietf.org, ietf-ppp@merit.edu In-Reply-To: <4.3.2.7.2.20001201163341.057cb720@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu At 04:37 PM 12/1/2000 -0500, Karl Fox wrote: >Always On Dynamic ISDN (AODI) >draft-ietf-pppext-aodi-00.txt That should be draft-ietf-pppext-aodi-02.txt From owner-ietf-ppp-outgoing@merit.edu Fri Dec 1 17:07:01 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03621 for ; Fri, 1 Dec 2000 17:07:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id E75F85DDBE; Fri, 1 Dec 2000 17:06:34 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id CE2515DDCF; Fri, 1 Dec 2000 17:06:34 -0500 (EST) Received: from mail.via-net.net (unknown [208.46.234.15]) by segue.merit.edu (Postfix) with ESMTP id A44905DDBE for ; Fri, 1 Dec 2000 17:06:33 -0500 (EST) Received: from karl.xc.org (ppp048.via-net.net [208.46.234.175]) by mail.via-net.net (Post.Office MTA v3.5.3 release 223 ID# 0-52517U2500L250S0V35) with ESMTP id net; Fri, 1 Dec 2000 17:06:57 -0500 Message-Id: <4.3.2.7.2.20001201170552.05270cb0@127.0.0.1> X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 01 Dec 2000 17:06:31 -0500 To: Matt Holdrege From: Karl Fox Subject: Re: PPPEXT Working Group Agenda -- 49th IETF (corrected) Cc: agenda@ietf.org, ietf-ppp@merit.edu In-Reply-To: <5.0.2.1.2.20001201135540.02165170@pop3.ipverse.com> References: <4.3.2.7.2.20001201163341.057cb720@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Oops--sorry, Matt. Karl At 04:56 PM 12/1/00, Matt Holdrege wrote: >At 04:37 PM 12/1/2000 -0500, Karl Fox wrote: >>Always On Dynamic ISDN (AODI) >>draft-ietf-pppext-aodi-00.txt > >That should be draft-ietf-pppext-aodi-02.txt Karl Fox Key fingerprint = 4159 B4AD 339D 4E2A 255F 9CC4 9DA9 CB4B B16D E2B1 From owner-ietf-ppp-outgoing@merit.edu Mon Dec 4 11:34:10 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12154 for ; Mon, 4 Dec 2000 11:34:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 722255DDD9; Mon, 4 Dec 2000 11:33:33 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 59C455DDDF; Mon, 4 Dec 2000 11:33:33 -0500 (EST) Received: from cisco.com (sigma.cisco.com [171.69.63.142]) by segue.merit.edu (Postfix) with ESMTP id 58D675DDD9 for ; Mon, 4 Dec 2000 11:33:31 -0500 (EST) Received: from brucet-nt3.cisco.com (brucet-dsl3.cisco.com [10.19.64.188]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id IAA11450; Mon, 4 Dec 2000 08:31:52 -0800 (PST) Message-Id: <4.3.1.0.20001204082537.018a94c8@sigma.cisco.com> X-Sender: brucet@sigma.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 04 Dec 2000 08:33:31 -0800 To: Karl Fox , agenda@ietf.org From: Bruce A Thompson Subject: Re: PPPEXT Working Group Agenda -- 49th IETF (corrected) Cc: ietf-ppp@merit.edu In-Reply-To: <4.3.2.7.2.20001201163341.057cb720@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu The title for is actually "PPP (and IP/UDP/RTP Header Compression) over AAL2". We have generalized the original contribution to AVT which was "IP/UDP/RTP Header Compression over AAL2" into "PPP over AAL2". Bruce T At 04:37 PM 12/01/2000 -0500, Karl Fox wrote: >[Please ignore the previous PPPEXT agenda. This is the real one.] > >Point-to-Point Extensions (PPPEXT) Working Group >Tuesday, December 12, 1700-1800 PST >49th IETF, San Diego > >Agenda > >PPP Multiplexing >draft-ietf-pppext-pppmux-01.txt >Craig Fox >10 minutes > >Extending PPP over SONET/SDH with virtual concatenation >draft-ietf-pppext-posvcholo-02.txt >Nevin Jones >15 minutes > >Always On Dynamic ISDN (AODI) >draft-ietf-pppext-aodi-00.txt >Matt Holdrege >5 minutes > >IP/UDP/RTP Header Compression over AAL2 >draft-buffam-avt-crtp-over-aal2-01.txt >Bruce A Thompson >10 minutes > >PPPEXT Document Status and Call for Questionnaire Authors >Karl Fox >20 minutes > >Karl Fox >Key fingerprint = 4159 B4AD 339D 4E2A 255F 9CC4 9DA9 CB4B B16D E2B1 > Bruce Thompson Cisco Systems : IOS Products email: brucet@cisco.com office: (408)527-0446 home office: (408)868-0112 San Jose, CA From owner-ietf-ppp-outgoing@merit.edu Wed Dec 6 09:50:50 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA23498 for ; Wed, 6 Dec 2000 09:50:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id 78AF35DDAF; Wed, 6 Dec 2000 09:50:16 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5B88F5DDB9; Wed, 6 Dec 2000 09:50:16 -0500 (EST) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by segue.merit.edu (Postfix) with ESMTP id 9CFDB5DDAF for ; Wed, 6 Dec 2000 09:50:14 -0500 (EST) Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA25503 for ; Wed, 6 Dec 2000 09:50:13 -0500 (EST) Received: from pai820exch001h.wins.lucent.com (h135-14-3-59.lucent.com [135.14.3.59]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA25487 for ; Wed, 6 Dec 2000 09:50:13 -0500 (EST) Received: by pai820exch001h.micro.lucent.com with Internet Mail Service (5.5.2650.21) id ; Wed, 6 Dec 2000 09:50:12 -0500 Message-ID: <2723E6389F55D311BDC200508B129547017E2178@pai820exch003u.micro.lucent.com> From: "Jones, Nevin R (Nevin)" To: ietf-ppp@merit.edu Cc: "'chris murton'" , "Jones, Nevin R (Nevin)" Subject: I-D draft-ietf-pppext-posvcholo-3.txt Date: Wed, 6 Dec 2000 09:50:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu All: A New Internet-Draft has been made at ftp://standards.nortelnetworks.com/PPP_extn/ Title : Extending PPP over SONET/SDH with virtual concatenation, high order and low order payloads Author(s) : N. Jones & C. Murton Filename : draft-ietf-pppext-posvcholo-03.txt Pages : 8 Date : 29-Nov-00 This document proposes an extension to the mapping of PPP into SONET/SDH defined in RFC 2615 PPP over SONET/SDH (POS) [3], to include use of SONET/SDH SPE/VC virtual concatenation and use of both high order and low order payloads A URL for this Internet-Draft is: ftp://standards.nortelnetworks.com/PPP_extn/draft-ietf-pppext-posvcholo-03.t xt Nevin R. Jones Lucent Microelectronics Broadband IC System Architecture Rm 7E-321 600 Mountain Avenue Murray Hill, NJ 07974 Ph: 908-582-5343 Fax: 908-582-4185 nrjones@lucent.com From owner-ietf-ppp-outgoing@merit.edu Wed Dec 6 16:08:31 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21230 for ; Wed, 6 Dec 2000 16:08:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 096285DDFB; Wed, 6 Dec 2000 16:05:24 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 986785DE20; Wed, 6 Dec 2000 16:05:22 -0500 (EST) Received: from cisco.com (sigma.cisco.com [171.69.63.142]) by segue.merit.edu (Postfix) with ESMTP id 1A9505DDFB for ; Wed, 6 Dec 2000 16:05:18 -0500 (EST) Received: from brucet-nt3.cisco.com (brucet-dsl3.cisco.com [10.19.64.188]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA25002; Wed, 6 Dec 2000 11:32:56 -0800 (PST) Message-Id: <4.3.1.0.20001206110620.018ce1d0@sigma.cisco.com> X-Sender: brucet@sigma.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 06 Dec 2000 11:34:35 -0800 To: "Hari Krishna Vuppaladhadiam" , , , From: Bruce A Thompson Subject: Re: Comments on AAL Type 2 Signalling Cc: , , , , , , , In-Reply-To: <007901c05fb0$75af9d20$03000004@hariv.domain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu At 10:15 AM 12/06/2000 -0800, Hari Krishna Vuppaladhadiam wrote: > >Hello, > > I have a few doubts regarding signalling/tones data transfer on AAL-2. ITU has suggested several tones like the following: >Dial, Recall Dial, Ringing, Busy, Congestion, Special information, Warning and Record tone (apart from PBX tones). >How are these carried over by AAL-2? I think you are talking about I.366.2 (AAL Type 2 Service Specific Convergence Sublayer for Trunking). The message above has nothing to do with I.366.2. It is about I.366.1 (Segmentation and Reassembly Service Specific Convergence Sublayer for the AAL type 2). This message is the result of a mtg we had with ITU SG13 to address issues we had in making draft-buffam-avt-crtp-over-aal2-01.txt work with I.366.1. The message is just stating what is being done in SG13 and SG11 to address the issues raised by this draft. Draft-buffam-avt-crtp-over-aal2-01.txt has generalized the original contribution draft-buffam-avt-crtp-over-aal2-00.txt which was called "IP/UDP/RTP Header Compression over AAL2" into "PPP over AAL2". Because of this change, we are presenting draft-buffam-avt-crtp-over-aal2-01.txt in PPPEXT and not in AVT. While the generalization from "IP/UDP/RTP Header Compression" to "PPP" was straight forward in the draft, it caused the draft to move from one working group to another. Sorry for any confusion caused by this. Note that no action will be taken on this draft in the ITU unless it moves forward. We are presenting draft-buffam-avt-crtp-over-aal2-01.txt in PPPEXT to determine whether it does indeed move forward. Bruce T > >Regards >Hari V > >>-----Original Message----- >>From: Greg Ratta <gratta@lucent.com> >>To: ietf-ppp@merit.edu <ietf-ppp@merit.edu>; rem-conf@es.net <rem-conf@es.net> >>Cc: ian.rytina@ericsson.com <ian.rytina@ericsson.com>; mmcloughlin@asc.com <mmcloughlin@asc.com>; hiramatsu.yukio@lab.ntt.co.jp <hiramatsu.yukio@lab.ntt.co.jp>; arshey.odedra@itu.int <arshey.odedra@itu.int>; sob@harvard.edu <sob@harvard.edu>; mankin@east.isi.edu <mankin@east.isi.edu>; narten@raleigh.ibm.com <narten@raleigh.ibm.com>; nordmark@eng.sun.com <nordmark@eng.sun.com> >>Date: Wednesday, December 06, 2000 9:59 AM >>Subject: Comments on AAL Type 2 Signalling >> >>This message represents a communication to the IETF AVT and PPPEXT WGs that was approved by ITU-T SG 11 at its December 6, 2000 meeting. For followup technical discussions, please correspond with Mr. Ian Rytina, Q15/11 Rapporteur ({ HYPERLINK mailto:ian.rytina@ericsson.com }ian.rytina@ericsson.com), and Mr. Mike McLoughlin (mmcloughlin@asc.com) >> >>1. Introduction >>This communication has been generated by ITU- T SG11 as a result of information received from ITU-T SG13 related to the transport of PPP and/or CRTP over AAL type 2. >> >> >> >>2. Request for Signalling of I.366.1 Applications >>It has been brought to the attention of SG11 that the IETF is planning to use the SSSAR service of ITU-T Recommendation I.366.1. It is the understanding of the participants of SG 11 that the IETF is going to use particular UUI code points to distinguish among different forms of PDUs. In addition, more than one application may use this SSSAR. >> >> >> >>It has been communicated that SG13 initiated the definition of an SSCF to SSSAR (as a new Annex to ITU-T Recommendation I.366.1). In addition to this new SSCF, there is a need to signal what application is making use of this new Annex. >> >> >> >>SG11 have noted that communication has been initiated between SG13 and the IETF. SG 11 anticipate that there may be a future request to provide a signalling mechanism for such applications, once the IETF indicate which applications are required to be supported (e.g. PPP over AAL type 2 and/or CRTP over AAL type 2, similar to that outlined in draft-buffam-avt- crtp-over- aal2-01.txt). SG11 note that these are valid applications of AAL type 2 and are happy to provide the necessary signalling support. >> >> >> >>The participants in SG 11 would like to point out that ITU-T Recommendations Q.2630.1 and Q.2630.2 already include a parameter entitled Served User Transport, which may be used to carry such application information; however, it is not clear whether this meets the proposed requirements of the IETF. As such, SG11 is awaiting further information from the IETF. >> >> >> >> >>Greg Ratta, Vice Chairman, ITU-T SG 11, Signalling requirements and protocols >>Lucent Technologies Tel: +1 732 332 5174, Fax: +1 732 949 1196, gratta@lucent.com Bruce Thompson Cisco Systems : IOS Products email: brucet@cisco.com office: (408)527-0446 home office: (408)868-0112 San Jose, CA From owner-ietf-ppp-outgoing@merit.edu Thu Dec 7 10:30:29 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03727 for ; Thu, 7 Dec 2000 10:30:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id 125D25DDCE; Thu, 7 Dec 2000 10:29:45 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id EFBA65DDD0; Thu, 7 Dec 2000 10:29:44 -0500 (EST) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by segue.merit.edu (Postfix) with ESMTP id 7369B5DDCE for ; Thu, 7 Dec 2000 10:29:43 -0500 (EST) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e2.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA166694 for ; Thu, 7 Dec 2000 10:29:00 -0500 Received: from RCHASA28.RCHLAND.IBM.COM (d27ml103.rchland.ibm.com [9.5.39.110]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id KAA41156 for ; Thu, 7 Dec 2000 10:27:54 -0500 Importance: Normal To: ietf-ppp Subject: 16 byte CHAP Challenge length REQUIRED? X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Martz" Date: Thu, 7 Dec 2000 10:31:15 -0500 X-MIMETrack: Serialize by Router on d27ml103/27/M/IBM(Release 5.0.5 |September 22, 2000) at 12/07/2000 09:31:16 AM, Serialize complete at 12/07/2000 09:31:16 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 00549DD6852569AE_=" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu This is a multipart message in MIME format. --=_alternative 00549DD6852569AE_= Content-Type: text/plain; charset="us-ascii" Good folk of the PPP mailing list: I have noticed in the past that quite often the CHAP challenge sent from other PPP implementations is always exactly 16 bytes (128 bits) in length. On the other hand, our implementation generates a CHAP challenge with a length which varies between 16 and 64 bytes. The length is picked "at random" each time a challenge is generated. I never thought much about this implementation difference before since my understanding of the RFC allows either method. But it appears that the Acess-Request packets we send to a Microsoft Windows 2000 Server Radius implementation succeed only when the length of the CHAP challenge provided in an Access-Request is exactly 16 bytes long. It is VERY hard to believe that Win2K RADIUS really only supports 16 byte CHAP challenges. So we're trying to figure out what we might doing wrong. Perhaps we made an error when setting up the Win2K RADIUS server? Or perhaps there is something wrong with the requests our NAS is sending to Win2K RADIUS? But if we are in error, we have not been able to determine what we are doing wrong. Also, our RADIUS authentication requests which specify a non-16 byte CHAP Challenge are accepted when we use a different (non-Win2K) RADIUS server. I'm not aware of any restriction in the Radius RFC on the length of a CHAP challenge provided by a NAS beyond saying that 16 bytes is "preferable". (BTW, can anyone tell me/speculate on why a 128 bit CHAP challenge length is viewed as preferable?) I was hoping I might be able to get confirmation one way or another from this list. I would appreciate it if anyone else who has tried sending an Access-Request to a Win2K RADIUS with a non-16 byte CHAP challenge length could let me know if it worked for them. -john martz, 8-852-5539, jmartz@us.ibm.com IBM AS/400 TCP/IP PPP development (and stuff) --=_alternative 00549DD6852569AE_= Content-Type: text/html; charset="us-ascii"
Good folk of the PPP mailing list:

I have noticed in the past that quite often the CHAP challenge sent from other PPP implementations is always exactly 16 bytes (128 bits) in length.  On the other hand, our implementation generates a CHAP challenge with a length which varies between 16 and 64 bytes. The length is picked "at random" each time a challenge is generated.

I never thought much about this implementation difference before since my understanding of the RFC allows either method. But it appears that the Acess-Request packets we send to a Microsoft Windows 2000 Server Radius implementation succeed only when the length of the CHAP challenge provided in an Access-Request is exactly 16 bytes long.  

It is VERY hard to believe that Win2K RADIUS really only supports 16 byte CHAP challenges. So  we're trying to figure out what we might doing wrong. Perhaps we made an error when setting up the Win2K RADIUS server? Or perhaps there is something wrong with the requests our NAS is sending to Win2K RADIUS?  But if we are in error, we have not been able to determine what we are doing wrong. Also, our RADIUS authentication requests which specify a non-16 byte CHAP Challenge are accepted when we use a different (non-Win2K) RADIUS server.

I'm not aware of any restriction in the Radius RFC on the length of a CHAP challenge provided by a NAS beyond saying that 16 bytes is "preferable".   (BTW, can anyone tell me/speculate on why a 128 bit CHAP challenge length is viewed as preferable?)

I was hoping I might be able to get confirmation one way or another from this list. I would appreciate it if anyone else who has tried sending an Access-Request to a Win2K RADIUS with a non-16 byte CHAP challenge length could let me know if it worked for them.

-john martz, 8-852-5539,  jmartz@us.ibm.com
IBM AS/400 TCP/IP PPP development (and stuff)
 --=_alternative 00549DD6852569AE_=-- From owner-ietf-ppp-outgoing@merit.edu Thu Dec 7 10:40:17 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04964 for ; Thu, 7 Dec 2000 10:40:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 55DD85DE0F; Thu, 7 Dec 2000 10:39:45 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 42E665DE08; Thu, 7 Dec 2000 10:39:45 -0500 (EST) Received: from h006008986325.ne.mediaone.net (h006008986325.ne.mediaone.net [24.218.16.153]) by segue.merit.edu (Postfix) with ESMTP id 81A235DE0D for ; Thu, 7 Dec 2000 10:39:43 -0500 (EST) Received: (from carlson@localhost) by h006008986325.ne.mediaone.net (8.11.0/8.11.0) id eB7FdfF06698; Thu, 7 Dec 2000 10:39:41 -0500 From: James Carlson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14895.44860.920388.489446@h006008986325.ne.mediaone.net> Date: Thu, 7 Dec 2000 10:39:40 -0500 (EST) To: "John Martz" Cc: ietf-ppp Subject: Re: 16 byte CHAP Challenge length REQUIRED? In-Reply-To: John Martz's message of 7 December 2000 10:31:15 References: X-Mailer: VM 6.75 under Emacs 20.6.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit John Martz writes: > I have noticed in the past that quite often the CHAP challenge sent from > other PPP implementations is always exactly 16 bytes (128 bits) in length. > On the other hand, our implementation generates a CHAP challenge with a > length which varies between 16 and 64 bytes. The length is picked "at > random" each time a challenge is generated. That's a reasonable thing to do. > I never thought much about this implementation difference before since my > understanding of the RFC allows either method. But it appears that the > Acess-Request packets we send to a Microsoft Windows 2000 Server Radius > implementation succeed only when the length of the CHAP challenge provided > in an Access-Request is exactly 16 bytes long. Well, an obvious issue is that there's a bit of RADIUS oddity about a Challenge value of exactly 16 octets. See RFC 2865 section 2.2 -- if the challenge is exactly 16 octets, then it "can be" placed in the Request Authenticator field of the Access-Request packet, rather than in a separate CHAP-Challenge attribute. Perhaps either the RADIUS server or the NAS has bugs in dealing with the CHAP-Challenge attribute. > I'm not aware of any restriction in the Radius RFC on the length of a CHAP > challenge provided by a NAS beyond saying that 16 bytes is "preferable". > (BTW, can anyone tell me/speculate on why a 128 bit CHAP challenge length > is viewed as preferable?) You don't need the extra attribute if it's exactly that length. (Perhaps this would be more appropriate in the nasreq wg ... ?) -- James Carlson "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Thu Dec 7 10:46:58 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05751 for ; Thu, 7 Dec 2000 10:46:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id F23655DE59; Thu, 7 Dec 2000 10:45:09 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B80145DE30; Thu, 7 Dec 2000 10:45:09 -0500 (EST) Received: from mx.databus.com (p101-44.acedsl.com [160.79.101.44]) by segue.merit.edu (Postfix) with ESMTP id 451905DE59 for ; Thu, 7 Dec 2000 10:45:06 -0500 (EST) Received: (from barney@localhost) by mx.databus.com (8.11.1/8.11.1) id eB7FiYR98765; Thu, 7 Dec 2000 10:44:34 -0500 (EST) (envelope-from barney) Date: Thu, 7 Dec 2000 10:44:34 -0500 From: Barney Wolff To: John Martz Cc: ietf-ppp Subject: Re: 16 byte CHAP Challenge length REQUIRED? Message-ID: <20001207104434.A98723@mx.databus.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from jmartz@us.ibm.com on Thu, Dec 07, 2000 at 10:31:15AM -0500 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu By RFC, there is no such requirement. But as a pragmatic issue, there is no value in a longer challenge, since the computed hash will also be 16 bytes. The chap-challenge attribute was added to RADIUS late in its development - originally the challenge was simply put into the Authenticator, which is fixed at 16 bytes. Some early RADIUS servers don't support the attribute - my RADIUS proxy implementation moves the challenge to the authenticator if it is 16 bytes, to aid interoperability. It is a suprise to find a recent server implementation that does not support it - perhaps the MS-CHAP challenge is always 16 - but that's pure speculation. With no particular value to a longer challenge, and danger of duplication in a shorter one, why not just give in and use 16? Barney Wolff From owner-ietf-ppp-outgoing@merit.edu Thu Dec 7 10:58:08 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07186 for ; Thu, 7 Dec 2000 10:58:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id EE3305DDD0; Thu, 7 Dec 2000 10:57:41 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DB0C55DDBE; Thu, 7 Dec 2000 10:57:41 -0500 (EST) Received: from h006008986325.ne.mediaone.net (h006008986325.ne.mediaone.net [24.218.16.153]) by segue.merit.edu (Postfix) with ESMTP id 3867D5DDB4 for ; Thu, 7 Dec 2000 10:57:40 -0500 (EST) Received: (from carlson@localhost) by h006008986325.ne.mediaone.net (8.11.0/8.11.0) id eB7FvSw20680; Thu, 7 Dec 2000 10:57:28 -0500 From: James Carlson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14895.45928.322510.508085@h006008986325.ne.mediaone.net> Date: Thu, 7 Dec 2000 10:57:28 -0500 (EST) To: Barney Wolff Cc: John Martz , ietf-ppp Subject: Re: 16 byte CHAP Challenge length REQUIRED? In-Reply-To: Barney Wolff's message of 7 December 2000 10:44:34 References: <20001207104434.A98723@mx.databus.com> X-Mailer: VM 6.75 under Emacs 20.6.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Barney Wolff writes: [...] > if it is 16 bytes, to aid interoperability. It is a suprise to > find a recent server implementation that does not support it - > perhaps the MS-CHAP challenge is always 16 - but that's pure > speculation. Good point. MS-CHAPv1 and v2 both force the challenge to exactly 16 octets by the use of a decidedly un-PPP-like fixed-size data structure. That would be a good explanation. > With no particular value to a longer challenge, and danger of > duplication in a shorter one, why not just give in and use 16? Well, for one thing, RFCs 1994 and 2865 are on Standards Track, and both permit variable-length challenges. The only fixed-size challenge ones are RFCs 2433 and 2759, both of which are Informational. (One might also argue that intentionally causing failures in non-compliant implementations is a worthwhile value in using a longer challenge. ;-}) -- James Carlson "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Thu Dec 7 11:04:04 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07950 for ; Thu, 7 Dec 2000 11:04:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 439235DDB4; Thu, 7 Dec 2000 11:01:08 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2765D5DDBE; Thu, 7 Dec 2000 11:01:08 -0500 (EST) Received: from h006008986325.ne.mediaone.net (h006008986325.ne.mediaone.net [24.218.16.153]) by segue.merit.edu (Postfix) with ESMTP id 620A95DDB4 for ; Thu, 7 Dec 2000 11:01:06 -0500 (EST) Received: (from carlson@localhost) by h006008986325.ne.mediaone.net (8.11.0/8.11.0) id eB7G15g20232; Thu, 7 Dec 2000 11:01:05 -0500 From: James Carlson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14895.46145.438650.170245@h006008986325.ne.mediaone.net> Date: Thu, 7 Dec 2000 11:01:05 -0500 (EST) To: ietf-ppp Subject: Re: 16 byte CHAP Challenge length REQUIRED? In-Reply-To: James Carlson's message of 7 December 2000 10:57:28 References: <20001207104434.A98723@mx.databus.com> <14895.45928.322510.508085@h006008986325.ne.mediaone.net> X-Mailer: VM 6.75 under Emacs 20.6.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit James Carlson writes: > Good point. MS-CHAPv1 and v2 both force the challenge to exactly 16 > octets by the use of a decidedly un-PPP-like fixed-size data > structure. That would be a good explanation. Um. 8 octets for v1 and 16 for v2, of course. -- James Carlson "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Thu Dec 7 23:26:00 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA06992 for ; Thu, 7 Dec 2000 23:26:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 82C945E1AC; Thu, 7 Dec 2000 23:18:38 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 344555DEFE; Thu, 7 Dec 2000 23:16:50 -0500 (EST) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id B9D725DF35 for ; Thu, 7 Dec 2000 23:10:07 -0500 (EST) Received: from gwzpc (sj-dial-4-82.cisco.com [171.68.181.211]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id UAA17485; Thu, 7 Dec 2000 20:09:50 -0800 (PST) Reply-To: From: "Glen Zorn" To: "James Carlson" , "Barney Wolff" Cc: "John Martz" , "ietf-ppp" Subject: RE: 16 byte CHAP Challenge length REQUIRED? Date: Thu, 7 Dec 2000 20:10:41 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <14895.45928.322510.508085@h006008986325.ne.mediaone.net> Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit James Carlson [mailto:carlson@workingcode.com] writes: > Barney Wolff writes: > [...] > > if it is 16 bytes, to aid interoperability. It is a suprise to > > find a recent server implementation that does not support it - > > perhaps the MS-CHAP challenge is always 16 - but that's pure > > speculation. > > Good point. MS-CHAPv1 and v2 both force the challenge to exactly 16 > octets by the use of a decidedly un-PPP-like fixed-size data > structure. That would be a good explanation. Hmm. 'Decidedly un-PPP-like'? From RFC 2759: 3. Challenge Packet The MS-CHAP-V2 Challenge packet is identical in format to the standard CHAP Challenge packet. MS-CHAP-V2 authenticators send an 16-octet challenge Value field. Peers need not duplicate Microsoft's algorithm for selecting the 16- octet value, but the standard guidelines on randomness [1,2,7] SHOULD be observed. Microsoft authenticators do not currently provide information in the Name field. This may change in the future. BTW, I seem to recall that the MSFT RADIUS client never puts the challenge (CHAP or MS-CHAP) in the Request-Authenticator, but uses the CHAP-Challenge or MS-CHAP-Challenge attributes, respectively. Sounds like a bug in the RADIUS server to me... > > > With no particular value to a longer challenge, and danger of > > duplication in a shorter one, why not just give in and use 16? > > Well, for one thing, RFCs 1994 and 2865 are on Standards Track, and > both permit variable-length challenges. The only fixed-size challenge > ones are RFCs 2433 and 2759, both of which are Informational. > > (One might also argue that intentionally causing failures in > non-compliant implementations is a worthwhile value in using a longer > challenge. ;-}) How true. > > -- > James Carlson > "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp > > From owner-ietf-ppp-outgoing@merit.edu Fri Dec 8 07:45:32 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA06124 for ; Fri, 8 Dec 2000 07:45:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id EC3675DDA3; Fri, 8 Dec 2000 07:44:51 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id CB48D5DD9C; Fri, 8 Dec 2000 07:44:51 -0500 (EST) Received: from h006008986325.ne.mediaone.net (h006008986325.ne.mediaone.net [24.218.16.153]) by segue.merit.edu (Postfix) with ESMTP id 1438E5DD96 for ; Fri, 8 Dec 2000 07:44:50 -0500 (EST) Received: (from carlson@localhost) by h006008986325.ne.mediaone.net (8.11.0/8.11.0) id eB8Cimg23898; Fri, 8 Dec 2000 07:44:48 -0500 From: James Carlson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14896.55231.510732.34073@h006008986325.ne.mediaone.net> Date: Fri, 8 Dec 2000 07:44:47 -0500 (EST) To: Cc: "ietf-ppp" Subject: RE: 16 byte CHAP Challenge length REQUIRED? In-Reply-To: Glen Zorn's message of 7 December 2000 20:10:41 References: <14895.45928.322510.508085@h006008986325.ne.mediaone.net> X-Mailer: VM 6.75 under Emacs 20.6.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Glen Zorn writes: > Hmm. 'Decidedly un-PPP-like'? From RFC 2759: The MS-CHAPv2 Challenge packet does have its un-PPP characteristics. For example, section 3 of RFC 2759 indicates that the Value field is 16 octets. MS-CHAP-V2 authenticators send an 16-octet challenge Value field. In contrast, RFC 1994 defines a CHAP Challenge Value to be a variable-length field: Value The Value field is one or more octets. The most significant octet is transmitted first. The Challenge Value is a variable stream of octets. The The MS-CHAPv2 Response is even stranger and more un-PPP-like: 16 octets: Peer-Challenge 8 octets: Reserved, must be zero 24 octets: NT-Response 1 octet : Flags > BTW, I seem to recall that the MSFT RADIUS client never puts the challenge > (CHAP or MS-CHAP) in the Request-Authenticator, but uses the CHAP-Challenge > or MS-CHAP-Challenge attributes, respectively. Sounds like a bug in the > RADIUS server to me... Entirely possible. That part was just a guess based on the original poster's observation that 16 octets seems to be a magic number. -- James Carlson "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Fri Dec 8 13:05:19 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA28244 for ; Fri, 8 Dec 2000 13:05:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4F7755DE18; Fri, 8 Dec 2000 13:04:27 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3CB6B5DE13; Fri, 8 Dec 2000 13:04:27 -0500 (EST) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id 7F8C25DDC5 for ; Fri, 8 Dec 2000 13:04:25 -0500 (EST) Received: from gwzpc (sj-dial-3-159.cisco.com [171.68.180.160]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id KAA05043; Fri, 8 Dec 2000 10:04:16 -0800 (PST) Reply-To: From: "Glen Zorn" To: "James Carlson" Cc: "ietf-ppp" Subject: RE: 16 byte CHAP Challenge length REQUIRED? Date: Fri, 8 Dec 2000 10:05:07 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <14896.55231.510732.34073@h006008986325.ne.mediaone.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit James Carlson [mailto:carlson@workingcode.com] writes: > Glen Zorn writes: > > Hmm. 'Decidedly un-PPP-like'? From RFC 2759: > > The MS-CHAPv2 Challenge packet does have its un-PPP characteristics. > For example, section 3 of RFC 2759 indicates that the Value field is > 16 octets. > > MS-CHAP-V2 authenticators send an 16-octet challenge Value field. True, but I read (and wrote) that more as a statement of implementation fact then a prescription; since the format of the MS-CHAP-Challenge packet is stolen by reference from RFC 1994, the Value is variable length by definition. It just happens that all (Microsoft) MS-CHAP v2 authenticators send 16 octets. Looking at it now, that could be a little clearer but it probably doesn't matter in practice. > > In contrast, RFC 1994 defines a CHAP Challenge Value to be a > variable-length field: > > Value > > The Value field is one or more octets. The most significant octet > is transmitted first. > > The Challenge Value is a variable stream of octets. The > > The MS-CHAPv2 Response is even stranger and more un-PPP-like: > > 16 octets: Peer-Challenge > 8 octets: Reserved, must be zero > 24 octets: NT-Response > 1 octet : Flags > > > BTW, I seem to recall that the MSFT RADIUS client never puts > the challenge > > (CHAP or MS-CHAP) in the Request-Authenticator, but uses the > CHAP-Challenge > > or MS-CHAP-Challenge attributes, respectively. Sounds like a bug in the > > RADIUS server to me... > > Entirely possible. That part was just a guess based on the original > poster's observation that 16 octets seems to be a magic number. > > -- > James Carlson > "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp > From owner-ietf-ppp-outgoing@merit.edu Tue Dec 12 12:53:52 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06075 for ; Tue, 12 Dec 2000 12:53:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id F2BBB5DDCD; Tue, 12 Dec 2000 12:53:15 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id CD1FD5DDE4; Tue, 12 Dec 2000 12:53:15 -0500 (EST) Received: from mail-scanner.mci.co.uk (mail-scanner.mci.co.uk [213.38.168.26]) by segue.merit.edu (Postfix) with ESMTP id 0AC7B5DDCD for ; Tue, 12 Dec 2000 12:53:14 -0500 (EST) Received: from openmail.mci.co.uk (unverified) by mail-scanner.mci.co.uk (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Tue, 12 Dec 2000 17:53:10 +0000 Received: from localhost (root@localhost) by openmail.mci.co.uk (8.9.3 (PHNE_18979)/8.8.6) with ESMTP id RAA19279 for ; Tue, 12 Dec 2000 17:48:32 GMT X-OpenMail-Hops: 1 Date: Tue, 12 Dec 2000 17:48:30 +0000 Message-Id: Subject: Nullmodem MIME-Version: 1.0 From: richard.northcott@mci.co.uk To: ietf-ppp@merit.edu Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline ;Creation-Date="Tue, 12 Dec 2000 17:40:55 +0000" ;Modification-Date="Tue, 12 Dec 2000 17:48:29 +0000" Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Hi all I am looking for a Microsoft DUN nullmodem.inf modem info file. I am trying to use MS DUN to start a PPP session without using the usual ATD commands to connect. Does anyone know where I might find this file?? thanks Richard Northcott (Divisional Manager) ********************************************** Teleca, 88/89 High Street, Winchester, Hants SO23 9AP Tel: 01962-622662 Fax: 01962-622663 Mobile: 07771-640291 Richard.Northcott@Teleca.com http://www.teleca.com From owner-ietf-ppp-outgoing@merit.edu Tue Dec 12 12:58:15 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07477 for ; Tue, 12 Dec 2000 12:58:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 87D405DDE5; Tue, 12 Dec 2000 12:57:49 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7044F5DDE4; Tue, 12 Dec 2000 12:57:49 -0500 (EST) Received: from h006008986325.ne.mediaone.net (h006008986325.ne.mediaone.net [24.218.16.153]) by segue.merit.edu (Postfix) with ESMTP id F28EE5DDE2 for ; Tue, 12 Dec 2000 12:57:47 -0500 (EST) Received: (from carlson@localhost) by h006008986325.ne.mediaone.net (8.11.0/8.11.0) id eBCHvjr24976; Tue, 12 Dec 2000 12:57:45 -0500 From: James Carlson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14902.26393.209392.709090@h006008986325.ne.mediaone.net> Date: Tue, 12 Dec 2000 12:57:45 -0500 (EST) To: richard.northcott@mci.co.uk Cc: ietf-ppp@merit.edu Subject: Re: Nullmodem In-Reply-To: richard.northcott@mci.co.uk's message of 12 December 2000 17:48:30 References: X-Mailer: VM 6.75 under Emacs 20.6.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit richard.northcott@mci.co.uk writes: > I am looking for a Microsoft DUN nullmodem.inf modem info file. > I am trying to use MS DUN to start a PPP session without using the > usual ATD commands to connect. > > Does anyone know where I might find this file?? A quick web search gives this: http://www.cisco.com/warp/public/471/103.html -- James Carlson "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Tue Dec 12 21:31:45 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA12506 for ; Tue, 12 Dec 2000 21:31:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7E91E5E0F6; Tue, 12 Dec 2000 21:24:14 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id F0F505DF3C; Tue, 12 Dec 2000 21:21:57 -0500 (EST) Received: from sapphire.int.ipverse.com (w067.z208037018.sjc-ca.dsl.cnc.net [208.37.18.67]) by segue.merit.edu (Postfix) with ESMTP id D6C655DEC1 for ; Tue, 12 Dec 2000 21:16:47 -0500 (EST) Received: from matt.ipverse.com (ietf.207.137.72.159.tx.verio.net [207.137.72.159]) by sapphire.int.ipverse.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id XNX7NZFZ; Tue, 12 Dec 2000 18:16:46 -0800 Message-Id: <5.0.2.1.2.20001212181124.01eab470@pop3.ipverse.com> X-Sender: matt@ipverse.com@pop3.ipverse.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 12 Dec 2000 18:16:47 -0800 To: ietf-ppp@merit.edu From: Matt Holdrege Subject: Draft minutes from the San Diego meeting Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Here are the minutes. Please comment if I made any mistakes... Point-to-Point Extensions (PPPEXT) Working Group Tuesday, December 12, 1700-1800 PST 49th IETF, San Diego Chair: Karl Fox (karl@xc.org) Reported by Matt Holdrege (matt@ipverse.com) 63 people signed the blue sheet Agenda PPP Multiplexing draft-ietf-pppext-pppmux-01.txt Craig Fox There is a linux implementation that will be shared sometime soon. That was the only known implementation. Extending PPP over SONET/SDH with virtual concatenation draft-ietf-pppext-posvcholo-02.txt Nevin Jones The draft is ready to move ahead and will go to WG last call. Always On Dynamic ISDN (AODI) draft-ietf-pppext-aodi-02.txt Matt Holdrege The draft has passed WG last call and will go forward to the IESG. There will be a disclaimer noting architectural complaints which resulted in an Informational RFC rather than Standards-track. PPP over AAL2 Draft-buffam-avt-crtp-over-aal2-01.txt Bruce Thompson (brucet@cisco.com) (see presentation) This reflects new AAL2 work in the ITU. PPP over AAL2 is more efficient that AAL5 for packets smaller than 440 bytes. Carsten Bormann (cabo@tzi.org) on Robust Header Compression (ROHC) Carsten summarized the outcome of the ROHC meeting earlier today. PPPEXT Document Status and Call for Questionnaire Authors Karl Fox Tasks and status: Advance AODI to Informational Will be sent to the IESG Advance CHAP to Full Standard Document Review needed Advance MP to Full Standard Document Review needed Advance LQM to Full Standard Document Review needed Advance IPCP to Draft Standard Document rewrite and interoperability survey needed Advance CCP to Draft Standard Interoperability survey needed Advance ECP to Draft Standard Interoperability survey needed Advance PPP over ISDN to Draft Standard Interoperability survey needed Advance LCP MIB to Draft Standard Interoperability survey needed Advance CHAP MIB to Draft Standard Interoperability survey needed Advance IPCP MIB to Draft Standard Interoperability survey needed Uri Blumenthal (uri.blumenthal@lucent.com) of Lucent talked on wireless security. They are concerned about key derivation using the results of CHAP and they are working on a new draft for submission. From owner-ietf-ppp-outgoing@merit.edu Wed Dec 13 02:38:35 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA11383 for ; Wed, 13 Dec 2000 02:38:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 817695DDF7; Wed, 13 Dec 2000 02:37:56 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6F6E75DDE6; Wed, 13 Dec 2000 02:37:56 -0500 (EST) Received: from cisco.com (sigma.cisco.com [171.69.63.142]) by segue.merit.edu (Postfix) with ESMTP id A84405DDB6 for ; Wed, 13 Dec 2000 02:37:54 -0500 (EST) Received: from brucet-nt3.cisco.com (sj-dial-4-125.cisco.com [171.68.181.254]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id XAA03155; Tue, 12 Dec 2000 23:37:52 -0800 (PST) Message-Id: <4.3.1.0.20001212233154.0194a1d8@sigma.cisco.com> X-Sender: brucet@sigma.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 12 Dec 2000 23:39:38 -0800 To: Matt Holdrege , ietf-ppp@merit.edu From: Bruce A Thompson Subject: Re: Draft minutes from the San Diego meeting In-Reply-To: <5.0.2.1.2.20001212181124.01eab470@pop3.ipverse.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu At 06:16 PM 12/12/2000 -0800, Matt Holdrege wrote: >Here are the minutes. Please comment if I made any mistakes... > >Point-to-Point Extensions (PPPEXT) Working Group >Tuesday, December 12, 1700-1800 PST >49th IETF, San Diego >Chair: Karl Fox (karl@xc.org) >Reported by Matt Holdrege (matt@ipverse.com) >63 people signed the blue sheet > > >Agenda > >PPP Multiplexing >draft-ietf-pppext-pppmux-01.txt >Craig Fox > >There is a linux implementation that will be shared sometime soon. That was the only known implementation. > > >Extending PPP over SONET/SDH with virtual concatenation >draft-ietf-pppext-posvcholo-02.txt >Nevin Jones > >The draft is ready to move ahead and will go to WG last call. > > >Always On Dynamic ISDN (AODI) >draft-ietf-pppext-aodi-02.txt >Matt Holdrege > >The draft has passed WG last call and will go forward to the IESG. There will be a disclaimer noting architectural complaints which resulted in an Informational RFC rather than Standards-track. > >PPP over AAL2 >Draft-buffam-avt-crtp-over-aal2-01.txt >Bruce Thompson (brucet@cisco.com) >(see presentation) >This reflects new AAL2 work in the ITU. >PPP over AAL2 is more efficient that AAL5 for packets smaller than 440 bytes. This is a draft to the IETF, not the ITU. This draft reflects new work in the IETF. We need to get this draft accepted as a working group item in PPPEXT. We have had meetings to the ITU to determine what was needed from AAL2 to support PPP over AAL2. This draft will not be evaluated in the ITU. The ITU will take no action to support this draft unless it is accepted as a work item in PPPEXT. We need to determine whether this draft will be accepted as a work item in PPPEXT. I am sending an email asking for the PPPEXT working group's members either supporting or opposing PPP over AAL2 being a work item in PPPEXT. Bruce T >Carsten Bormann (cabo@tzi.org) on Robust Header Compression (ROHC) >Carsten summarized the outcome of the ROHC meeting earlier today. > >PPPEXT Document Status and Call for Questionnaire Authors >Karl Fox > >Tasks and status: > >Advance AODI to Informational >Will be sent to the IESG > >Advance CHAP to Full Standard >Document Review needed > >Advance MP to Full Standard >Document Review needed > >Advance LQM to Full Standard >Document Review needed > >Advance IPCP to Draft Standard >Document rewrite and interoperability survey needed > >Advance CCP to Draft Standard >Interoperability survey needed > >Advance ECP to Draft Standard >Interoperability survey needed > >Advance PPP over ISDN to Draft Standard >Interoperability survey needed > >Advance LCP MIB to Draft Standard >Interoperability survey needed > >Advance CHAP MIB to Draft Standard >Interoperability survey needed > >Advance IPCP MIB to Draft Standard >Interoperability survey needed > >Uri Blumenthal (uri.blumenthal@lucent.com) of Lucent talked on wireless security. They are concerned about key derivation using the results of CHAP and they are working on a new draft for submission. > > > > Bruce Thompson Cisco Systems : IOS Products email: brucet@cisco.com office: (408)527-0446 home office: (408)868-0112 San Jose, CA From owner-ietf-ppp-outgoing@merit.edu Wed Dec 13 15:49:14 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19957 for ; Wed, 13 Dec 2000 15:49:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id A3DFF5DE1E; Wed, 13 Dec 2000 15:46:18 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 912FF5DE1D; Wed, 13 Dec 2000 15:46:18 -0500 (EST) Received: from cisco.com (sigma.cisco.com [171.69.63.142]) by segue.merit.edu (Postfix) with ESMTP id 081C75DE18 for ; Wed, 13 Dec 2000 15:46:17 -0500 (EST) Received: from brucet-nt3.cisco.com (sj-dial-3-200.cisco.com [171.68.180.201]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA11084 for ; Wed, 13 Dec 2000 12:46:15 -0800 (PST) Message-Id: <4.3.1.0.20001213124217.017f72c0@sigma.cisco.com> X-Sender: brucet@sigma.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 13 Dec 2000 12:48:02 -0800 To: ietf-ppp@merit.edu From: Bruce A Thompson Subject: Request to accept PPP over AAL2 as a PPPEXT Work Group Item Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu We presented PPP over AAL2 (draft-buffam-avt-crtp-over-aal2-01.txt) in the PPPEXT working group in IETF San Diego. The presentation we gave gives an overview of the draft and the benefits of running PPP over AAL2 as opposed to PPP over AAL5 and PPP/PPPMUX/AAL5. As was stated in the presentation, PPP over AAL2 is more efficient than PPP over AAL5 when the average packet size for the PPP session is less than 440 bytes. We are proposing PPP over AAL2 as a transport encapsulation for ATM networks. It is being proposed as an alternative to PPP over AAL5. The main reason for the proposal is to gain bandwidth efficiency for PPP links that will be used predominately for small packet traffic (like RTP encapsulated voice). We are requesting that this draft becomes a working group item in PPPEXT. Thanks greatly, Bruce T Bruce Thompson Cisco Systems : IOS Products email: brucet@cisco.com office: (408)527-0446 home office: (408)868-0112 San Jose, CA From owner-ietf-ppp-outgoing@merit.edu Fri Dec 15 12:50:15 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11361 for ; Fri, 15 Dec 2000 12:50:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 45E2C5DE16; Fri, 15 Dec 2000 12:48:14 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2F3005DE32; Fri, 15 Dec 2000 12:48:14 -0500 (EST) Received: from cisco.com (sigma.cisco.com [171.69.63.142]) by segue.merit.edu (Postfix) with ESMTP id 5E6515DE16 for ; Fri, 15 Dec 2000 12:48:12 -0500 (EST) Received: from brucet-nt3.cisco.com (dhcp-128-107-142-39.cisco.com [128.107.142.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id JAA18291 for ; Fri, 15 Dec 2000 09:48:11 -0800 (PST) Message-Id: <4.3.1.0.20001215094505.017a79a0@sigma.cisco.com> X-Sender: brucet@sigma.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 15 Dec 2000 09:50:01 -0800 To: ietf-ppp@merit.edu From: Bruce A Thompson Subject: Powerpoint presentation for PPP over AAL2 available Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu The presentation I made at the PPPEXT working group meeting in San Diego is now available at the following URL. http://www.net-standards.org/ppp-over-aal2-01-00.ppt I also haven't seen any response to my email requesting that PPP over AAL2 be accepted as a PPPEXT work group item. Does no one have an opinion on this? Bruce T Bruce Thompson Cisco Systems email: brucet@cisco.com office: (408)527-0446 home office: (408)868-0112 San Jose, CA From owner-ietf-ppp-outgoing@merit.edu Sun Dec 17 23:06:46 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA21600 for ; Sun, 17 Dec 2000 23:06:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id 233B05DDBD; Sun, 17 Dec 2000 23:06:19 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id F075C5DDBF; Sun, 17 Dec 2000 23:06:18 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id D0F425DDBD for ; Sun, 17 Dec 2000 23:06:16 -0500 (EST) Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id eBI46FG14768; Mon, 18 Dec 2000 05:06:15 +0100 (MET) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id FAA29897; Mon, 18 Dec 2000 05:06:14 +0100 (MET) Received: from ericsson.com.au (mc2dh207.epa.ericsson.se [146.11.87.207]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id FAA10726; Mon, 18 Dec 2000 05:06:11 +0100 (MET) Message-ID: <3A3D8D32.ABBE7A1@ericsson.com.au> Date: Mon, 18 Dec 2000 15:06:10 +1100 From: Ian Rytina X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ppp@merit.edu Cc: Bruce A Thompson , mmcloughlin@asc.com Subject: Re: Request to accept PPP over AAL2 as a PPPEXT Work Group Item References: <4.3.1.0.20001213124217.017f72c0@sigma.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Hi Bruce, To me, this seems to be a good solution for running IP applications on AAL2. I support your view that this should be a work item in PPPext. Please note that if you require an impact on Q.2630.2, this will have to be a Proposed/Draft Standard RFC in order for ITU-T to be able to reference the RFC in normative text. If it is accepted as such an RFC by PPPext then there should be no problem in getting this work also included in SG11 (via contributions, of course). Regards, Ian. Bruce A Thompson wrote: > We presented PPP over AAL2 (draft-buffam-avt-crtp-over-aal2-01.txt) in the PPPEXT working group in IETF San Diego. > > The presentation we gave gives an overview of the draft and the benefits of running PPP over AAL2 as opposed to PPP over AAL5 and PPP/PPPMUX/AAL5. As was stated in the presentation, PPP over AAL2 is more efficient than PPP over AAL5 when the average packet size for the PPP session is less than 440 bytes. > > We are proposing PPP over AAL2 as a transport encapsulation for ATM networks. It is being proposed as an alternative to PPP over AAL5. The main reason for the proposal is to gain bandwidth efficiency for PPP links that will be used predominately for small packet traffic (like RTP encapsulated voice). > > We are requesting that this draft becomes a working group item in PPPEXT. > > Thanks greatly, > > Bruce T > Bruce Thompson > Cisco Systems : IOS Products > email: brucet@cisco.com > office: (408)527-0446 > home office: (408)868-0112 > San Jose, CA From owner-ietf-ppp-outgoing@merit.edu Tue Dec 19 10:19:27 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA15771 for ; Tue, 19 Dec 2000 10:19:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id B08915DDFF; Tue, 19 Dec 2000 10:18:00 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 984C35DE04; Tue, 19 Dec 2000 10:18:00 -0500 (EST) Received: from asc_exch.asc.com (outlook.asc.com [63.82.128.45]) by segue.merit.edu (Postfix) with ESMTP id 0E4C95DDFF for ; Tue, 19 Dec 2000 10:17:59 -0500 (EST) Received: by ASC_EXCH with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Dec 2000 10:16:06 -0500 Message-ID: <4AA0C69EF2C3D411B94600B0D04931BD1FE84A@ASC_EXCH> From: Mike McLoughlin To: "'Pietro Schicker'" , Bruce A Thompson , ietf-ppp@merit.edu Cc: Thomas Narten , Erik Nordmark , Karl Fox , Allison Mankin , bbuffam@cisco.com Subject: RE: Should PPP over AAL2 be a PPPEXT Work Group Item? Date: Tue, 19 Dec 2000 10:16:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C069CE.9B43B8A0" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C069CE.9B43B8A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree with Bruce and Pietro that PPP over AAL2 should be a working = group item for it is valid work, and adds efficiencies not afforded by PPP = over AAL5. As Bruce presented at the pppext meeting on Tuesday, the ITU-T has also added this AAL2 application to the work of Question 2/13 that is = responsible for ATM and AALs. Q2/13 will develop an SSCF above the I.366.1 SSCS = for a more generic interface with PPP. Mike McLoughlin Advanced Switching Communications Vienna, Va. 22182 Tel: 703-288-8022 FaX: 703-448-5590 -----Original Message----- From: Pietro Schicker [mailto:schicker@scicon.ch] Sent: Tuesday, December 19, 2000 8:32 AM To: Bruce A Thompson; ietf-ppp@merit.edu Cc: Thomas Narten; Erik Nordmark; Karl Fox; Allison Mankin; bbuffam@cisco.com; mmcloughlin@asc.com Subject: Re: Should PPP over AAL2 be a PPPEXT Work Group Item? As Bruce has pointed out, transport of small PPP (such as RTP = encapsulated voice) over AAL type 5 carries a heavy overhead burden. This burden is = much relieved by utilizing AAL type 2 which has been defined (in addition to = AAL type 5) just for the purpose of small frame transport. As bandwidth preservation is -- in many instances -- a non-negigable concern, I strongly support the development of a PPP over AAL type 2 as = a transport encapsulation for ATM networks. Regards - Pietro At 19:36 2000-12-12 -0800, Bruce A Thompson wrote: >I am sending this email to the PPPEXT working group as an action from = the working group meeting this evening in San Diego. > >We need the members of the PPPEXT working group to decide whether or = not to include draft-buffam-avt-crtp-over-aal2-01.txt as a working group = item for PPPEXT. > >We are proposing PPP over AAL2 as a transport encapsulation for ATM networks. It is being proposed as an alternative to PPP over AAL5. The = main reason for the proposal is to gain bandwidth efficiency for PPP links = that will be used predominately for small packet traffic (like RTP = encapsulated voice). > >I have attached the presentation I made this afternoon to the PPPEXT working group. The presentation gives an overview of the draft and the benefits of running PPP over AAL2 as opposed to PPP over AAL5 and PPP/PPPMUX/AAL5. > >Please respond to this email with whether you support or oppose = including PPP over AAL2 as a PPPEXT work group item along with the reasoning why. > >Thanks greatly, > > Bruce T=20 >Attachment Converted: "G:\TEMP\Mime-Scicon\ppp-over-aal2-01-001.ppt" >Bruce Thompson >Cisco Systems : IOS Products >email: brucet@cisco.com >office: (408)527-0446 >home office: (408)868-0112 >San Jose, CA --------------------- Dr. Pietro Schicker Scientific Consulting Oberh=F6he CH-8340 Ringwil Tf: +41 1 938 1555 Fx: +41 1 938 1557 ------_=_NextPart_001_01C069CE.9B43B8A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Should PPP over AAL2 be a PPPEXT Work Group Item?

I agree with Bruce and Pietro that PPP over AAL2 = should be a working group item for it is valid work, and adds = efficiencies not afforded by PPP over AAL5.

As Bruce presented at the pppext meeting on Tuesday, = the ITU-T has also added this AAL2 application to the work of Question = 2/13 that is responsible for ATM and AALs.  Q2/13 will develop an = SSCF above the I.366.1 SSCS for a more generic interface with = PPP.

Mike McLoughlin
Advanced Switching Communications
Vienna, Va. 22182
Tel: 703-288-8022
FaX: 703-448-5590


-----Original Message-----
From: Pietro Schicker [mailto:schicker@scicon.ch]=
Sent: Tuesday, December 19, 2000 8:32 AM
To: Bruce A Thompson; ietf-ppp@merit.edu
Cc: Thomas Narten; Erik Nordmark; Karl Fox; Allison = Mankin;
bbuffam@cisco.com; mmcloughlin@asc.com
Subject: Re: Should PPP over AAL2 be a PPPEXT Work = Group Item?


As Bruce has pointed out, transport of small PPP = (such as RTP encapsulated
voice) over AAL type 5 carries a heavy overhead = burden. This burden is much
relieved by utilizing AAL type 2 which has been = defined (in addition to AAL
type 5) just for the purpose of small frame = transport.

As bandwidth preservation is -- in many instances -- = a non-negigable
concern, I strongly support the development of a PPP = over AAL type 2 as a
transport encapsulation for ATM networks.

Regards  -  Pietro

At 19:36 2000-12-12 -0800, Bruce A Thompson = wrote:
>I am sending this email to the PPPEXT working = group as an action from the
working group meeting this evening in San = Diego.
>
>We need the members of the PPPEXT working group = to decide whether or not
to include draft-buffam-avt-crtp-over-aal2-01.txt as = a working group item
for PPPEXT.
>
>We are proposing PPP over AAL2 as a transport = encapsulation for ATM
networks. It is being proposed as an alternative to = PPP over AAL5. The main
reason for the proposal is to gain bandwidth = efficiency for PPP links that
will be used predominately for small packet traffic = (like RTP encapsulated
voice).
>
>I have attached the presentation I made this = afternoon to the PPPEXT
working group. The presentation gives an overview of = the draft and the
benefits of running PPP over AAL2 as opposed to PPP = over AAL5 and
PPP/PPPMUX/AAL5.
>
>Please respond to this email with whether you = support or oppose including
PPP over AAL2 as a PPPEXT work group item along with = the reasoning why.
>
>Thanks greatly,
>
>       Bruce T =
>Attachment Converted: = "G:\TEMP\Mime-Scicon\ppp-over-aal2-01-001.ppt"
>Bruce Thompson
>Cisco Systems : IOS Products
>email: brucet@cisco.com
>office: (408)527-0446
>home office: (408)868-0112
>San Jose, CA


---------------------
Dr. Pietro Schicker
Scientific Consulting
Oberh=F6he
CH-8340 Ringwil
Tf: +41 1 938 1555
Fx: +41 1 938 1557

------_=_NextPart_001_01C069CE.9B43B8A0-- From owner-ietf-ppp-outgoing@merit.edu Wed Dec 20 17:33:59 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17959 for ; Wed, 20 Dec 2000 17:33:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id BAD605DDBA; Wed, 20 Dec 2000 17:31:00 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9878A5DE1E; Wed, 20 Dec 2000 17:31:00 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 7C4D65DDBA for ; Wed, 20 Dec 2000 17:30:58 -0500 (EST) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA15158; Wed, 20 Dec 2000 14:30:56 -0800 (PST) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA03537; Wed, 20 Dec 2000 17:30:56 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.1+Sun/8.11.1) id eBKMV9F116276; Wed, 20 Dec 2000 17:31:09 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14913.13101.252495.985110@gargle.gargle.HOWL> Date: Wed, 20 Dec 2000 17:31:09 -0500 (EST) From: James Carlson To: Bruce A Thompson Cc: ietf-ppp@merit.edu Subject: Re: Request to accept PPP over AAL2 as a PPPEXT Work Group Item In-Reply-To: Bruce A Thompson's message of 13 December 2000 12:48:02 References: <4.3.1.0.20001213124217.017f72c0@sigma.cisco.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Bruce A Thompson writes: > We are requesting that this draft becomes a working group item in PPPEXT. I think that the AAL2 mapping, at least, should become a pppext wg item. I'm not so sure about the split CID usage, though. As I read the usage of the CID values in this draft, this is intended to split the underlying physical link into a "fast" and "slow" path. This appears to me to be orthogonal to the rest of the draft. You could just as easily specify this type of split over AAL5 (using multiple VCs) or over any other medium with multiple channels. In fact, taking advantage of this split in a well-designed system would appear to require more effort than described in the draft. (For instance, one would not want to put *all* small packets on a separate channel. Just those that aren't PPP control protocols and don't relate to any flow over the large packet channel.) The rest of the draft appears to stand well on its own in defining the use of PPP on AAL2. If you agree, could you submit just that part as a draft-ietf-pppext-* document? I'm not sure where the multiple-physical-layer proposal belongs. I suspect that it falls in a crack between the pppext working group and one of the other groups. (pilc? issll? diff-serv?) (I have several comments on the rest of the draft, but I'll hold those for a new version.) -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 Second Edition now available - http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Wed Dec 20 19:22:57 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA20504 for ; Wed, 20 Dec 2000 19:22:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id 611815DE1D; Wed, 20 Dec 2000 19:22:31 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 501BC5DE27; Wed, 20 Dec 2000 19:22:31 -0500 (EST) Received: from cisco.com (sigma.cisco.com [171.69.63.142]) by segue.merit.edu (Postfix) with ESMTP id 6CD475DE1D for ; Wed, 20 Dec 2000 19:22:28 -0500 (EST) Received: from brucet-nt3.cisco.com (dhcp-128-107-142-39.cisco.com [128.107.142.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA14924; Wed, 20 Dec 2000 16:22:27 -0800 (PST) Message-Id: <4.3.1.0.20001220160622.01cf27b0@sigma.cisco.com> X-Sender: brucet@sigma.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 20 Dec 2000 16:24:20 -0800 To: James Carlson From: Bruce A Thompson Subject: Re: Request to accept PPP over AAL2 as a PPPEXT Work Group Item Cc: ietf-ppp@merit.edu In-Reply-To: <14913.13101.252495.985110@gargle.gargle.HOWL> References: <4.3.1.0.20001213124217.017f72c0@sigma.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu At 05:31 PM 12/20/2000 -0500, James Carlson wrote: >Bruce A Thompson writes: > > We are requesting that this draft becomes a working group item in PPPEXT. > >I think that the AAL2 mapping, at least, should become a pppext wg >item. I'm not so sure about the split CID usage, though. Great comments. I appreciate the detailed feedback. >As I read the usage of the CID values in this draft, this is intended >to split the underlying physical link into a "fast" and "slow" path. >This appears to me to be orthogonal to the rest of the draft. You >could just as easily specify this type of split over AAL5 (using >multiple VCs) or over any other medium with multiple channels. In >fact, taking advantage of this split in a well-designed system would >appear to require more effort than described in the draft. (For >instance, one would not want to put *all* small packets on a separate >channel. Just those that aren't PPP control protocols and don't >relate to any flow over the large packet channel.) Note that this part of the draft is "should" vs. "must". I thought I worded the draft so that am implementation of PPP over AAL2 could use a single CID and still be compliant. If I didn't do this, then it was a mistake. The reason that an implementation of PPP over AAL2 "should" use 2 CIDs is that it gives you an link fragmentation mechanism over a single ATM VC. I.366.1 does fragmentation and the CID scheduler in the AAL2 CPS layer will do the interleaving between CIDs. Most AAL2 SAR chips do this already. With PPP over AAL5, you only get a link fragmentation mechanism if you run traffic over different ATM VCs, so I think it's a bit different. The multiple CID usage is definitely an implementation optimization rather than an essential part of the draft. However, I still want to include multiple CID usage in the draft since an implementation that uses multiple CIDs will definitely have better latency characteristics over low speed links. I would be glad to move info on multiple CID usage to an appendix instead of the main body of the draft. Does this seem reasonable? >The rest of the draft appears to stand well on its own in defining the >use of PPP on AAL2. If you agree, could you submit just that part as >a draft-ietf-pppext-* document? > >I'm not sure where the multiple-physical-layer proposal belongs. I >suspect that it falls in a crack between the pppext working group and >one of the other groups. (pilc? issll? diff-serv?) With the multiple encapsulation proposal, I was more asking the group if it was even worthwhile pursuing. It would save 1-2 bytes per PPP payload from things like RTP encapsulated voice with RTP header compression (RFC 2508). If people thought it was worthwhile pursuing, then I guess we would move to the next step of how it should be presented. Bruce T >(I have several comments on the rest of the draft, but I'll hold those >for a new version.) > >-- >James Carlson, Internet Engineering >SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 >MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 >Second Edition now available - http://people.ne.mediaone.net/carlson/ppp Bruce Thompson Cisco Systems email: brucet@cisco.com office: (408)527-0446 home office: (408)868-0112 San Jose, CA From owner-ietf-ppp-outgoing@merit.edu Thu Dec 21 06:51:23 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA15250 for ; Thu, 21 Dec 2000 06:51:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id D74D45DDB3; Thu, 21 Dec 2000 06:50:47 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id BF3725DE2D; Thu, 21 Dec 2000 06:50:47 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id DBC455DDB3 for ; Thu, 21 Dec 2000 06:50:45 -0500 (EST) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA07560; Thu, 21 Dec 2000 03:50:43 -0800 (PST) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA17653; Thu, 21 Dec 2000 06:50:43 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.1+Sun/8.11.1) id eBLBouf118433; Thu, 21 Dec 2000 06:50:56 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14913.61087.625345.864277@gargle.gargle.HOWL> Date: Thu, 21 Dec 2000 06:50:55 -0500 (EST) From: James Carlson To: Bruce A Thompson Cc: ietf-ppp@merit.edu Subject: Re: Request to accept PPP over AAL2 as a PPPEXT Work Group Item In-Reply-To: Bruce A Thompson's message of 20 December 2000 16:24:20 References: <4.3.1.0.20001213124217.017f72c0@sigma.cisco.com> <4.3.1.0.20001220160622.01cf27b0@sigma.cisco.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Bruce A Thompson writes: > Note that this part of the draft is "should" vs. "must". I thought I > worded the draft so that am implementation of PPP over AAL2 could > use a single CID and still be compliant. If I didn't do this, then > it was a mistake. Yes, I did note that. The problem is that the solution offered is too specific to one domain. Leaving in a note that CID can be used to split up the streams for any desired purpose between consenting peers is probably sufficient. This could be the equivalent of RFC 2686 for AAL2 users. > The reason that an implementation of PPP over AAL2 "should" use 2 > CIDs is that it gives you an link fragmentation mechanism over a > single ATM VC. I.366.1 does fragmentation and the CID scheduler in > the AAL2 CPS layer will do the interleaving between CIDs. Most AAL2 > SAR chips do this already. Right. Again, a handy mechanism, but I think the draft presupposes too much of the problem to be solved. What I'd rather see is a more generic AAL2 draft that says, in effect, "here's how you run PPP over AAL2 and here are some of the extra physical layer features available." You'd then have a second draft specifying how to use the CIDs in PPP over AAL2 in the specific context of (say) voice over IP. This makes the draft more application-neutral and frees up the CID mechanism for folks who might do different things with it. For instance, in the spirit of RFC 2686, it could be used for supporting Integrated Services over PPP/AAL2. In that case, you would not specifically be segregating packets based on length. > With PPP over AAL5, you only get a link fragmentation mechanism if > you run traffic over different ATM VCs, so I think it's a bit > different. It's different in specific mechanism and TM consequences, but otherwise I think it's very similar. > The multiple CID usage is definitely an implementation optimization > rather than an essential part of the draft. However, I still want to > include multiple CID usage in the draft since an implementation that > uses multiple CIDs will definitely have better latency > characteristics over low speed links. I would be glad to move info > on multiple CID usage to an appendix instead of the main body of the > draft. Does this seem reasonable? I think the multiple CID usage is an important feature of the implementation. Some reference to it should stay. I don't think the draft needs the stream splitting based on packet length language, though; even in an appendix. > With the multiple encapsulation proposal, I was more asking the > group if it was even worthwhile pursuing. It would save 1-2 bytes > per PPP payload from things like RTP encapsulated voice with RTP > header compression (RFC 2508). If people thought it was worthwhile > pursuing, then I guess we would move to the next step of how it > should be presented. Are you talking about the distinguished types for selecting CRC-16 versus CRC-32, or about further extensions to 2508? If you're talking about the variable CRC scheme, I think the consequences of this might be fairly serious, and that's the part of my comment that I was holding until later to see where the dust settled. For both software and hardware, the implication is that both CRC-16 and CRC-32 must be run in parallel on all data received on a given CID. For hardware implementations, it means that two pipelines are required. For software implementations (think 860SAR on a T1 line), it means that the inner loop does twice as work. For both, this bumps up the intermediate state storage requirement for each of these streams and the I/O rate to that storage. I'm not an AAL2 expert, and I don't know the restrictions on UUI values (why is 27 'continue' and what are 28-31?), but it certainly would be nice to alert the receiver about the CRC mode in use before the first chunk has to be processed rather than as the last one is. As a slightly simpler way of accomplishing the same thing, why not just nail down the CRC choice on a per-CID basis? For your proposed VoIP usage, you'd have one CRC-16 only stream for C-RTP data, and another CRC-32 only stream for regular IP. -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 Second Edition now available - http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Fri Dec 22 16:35:37 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14944 for ; Fri, 22 Dec 2000 16:35:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 676BE5DDB2; Fri, 22 Dec 2000 16:34:52 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 46EA15DDB8; Fri, 22 Dec 2000 16:34:52 -0500 (EST) Received: from cisco.com (sigma.cisco.com [171.69.63.142]) by segue.merit.edu (Postfix) with ESMTP id 84D185DDB2 for ; Fri, 22 Dec 2000 16:34:50 -0500 (EST) Received: from brucet-nt3.cisco.com (rtp-dial-1-81.cisco.com [10.83.97.81]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id NAA09794; Fri, 22 Dec 2000 13:34:41 -0800 (PST) Message-Id: <4.3.1.0.20001222093736.0126ca38@sigma.cisco.com> X-Sender: brucet@sigma.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 22 Dec 2000 10:16:03 -0800 To: James Carlson From: Bruce A Thompson Subject: Re: Request to accept PPP over AAL2 as a PPPEXT Work Group Item Cc: ietf-ppp@merit.edu In-Reply-To: <14913.61087.625345.864277@gargle.gargle.HOWL> References: <4.3.1.0.20001213124217.017f72c0@sigma.cisco.com> <4.3.1.0.20001220160622.01cf27b0@sigma.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu At 06:50 AM 12/21/2000 -0500, James Carlson wrote: >Bruce A Thompson writes: > > Note that this part of the draft is "should" vs. "must". I thought I > > worded the draft so that am implementation of PPP over AAL2 could > > use a single CID and still be compliant. If I didn't do this, then > > it was a mistake. > >Yes, I did note that. The problem is that the solution offered is too >specific to one domain. Leaving in a note that CID can be used to >split up the streams for any desired purpose between consenting peers >is probably sufficient. This could be the equivalent of RFC 2686 for >AAL2 users. > > > The reason that an implementation of PPP over AAL2 "should" use 2 > > CIDs is that it gives you an link fragmentation mechanism over a > > single ATM VC. I.366.1 does fragmentation and the CID scheduler in > > the AAL2 CPS layer will do the interleaving between CIDs. Most AAL2 > > SAR chips do this already. > >Right. Again, a handy mechanism, but I think the draft presupposes >too much of the problem to be solved. > >What I'd rather see is a more generic AAL2 draft that says, in effect, >"here's how you run PPP over AAL2 and here are some of the extra >physical layer features available." You'd then have a second draft >specifying how to use the CIDs in PPP over AAL2 in the specific >context of (say) voice over IP. > >This makes the draft more application-neutral and frees up the CID >mechanism for folks who might do different things with it. For >instance, in the spirit of RFC 2686, it could be used for supporting >Integrated Services over PPP/AAL2. In that case, you would not >specifically be segregating packets based on length. OK, I understand your point. It sounds like you are recommending splitting PPP over AAL2 into 2 drafts. One would be the generic "PPP over AAL2" which would describe the basic encapsulation and allow the use of one or more CIDs but not describe the application of multiple CIDs. The second would be "Integrated Services using PPP over AAL2". It would describe the usage of multiple CIDs for LFI when multiple classes of delay sensitive traffic are carried over an AAL2 link. I don't have a problem with doing this if this is the right thing to do. I would note though the RFC 2686 actually describes an extension to the encapsulation format described by RFC 1990. I thought this may be why it was created as a separate RFC and not a different version of RFC 1990. Does anyone else have an opinion as to whether PPP over AAL2 should be split into different drafts? One more question. I noticed that RFC 2686 has some new LCP options for negotiating the number of classes that will be used between peers. I wondering whether a method like this should also be used for the multi CID usage of PPP over AAL2. You could have single CID usage by default for PPP over AAL2 and then have an LCP option for negotiating the usage of multiple CIDs by PPP over AAL2. One complication here is that this signaling is somewhat redundant to Q.2630.2 signaling that allows you to allocate multiple CIDs to an application. Any opinions on this? > > With the multiple encapsulation proposal, I was more asking the > > group if it was even worthwhile pursuing. It would save 1-2 bytes > > per PPP payload from things like RTP encapsulated voice with RTP > > header compression (RFC 2508). If people thought it was worthwhile > > pursuing, then I guess we would move to the next step of how it > > should be presented. > >Are you talking about the distinguished types for selecting CRC-16 >versus CRC-32, or about further extensions to 2508? > >If you're talking about the variable CRC scheme, I think the >consequences of this might be fairly serious, and that's the part of >my comment that I was holding until later to see where the dust >settled. For both software and hardware, the implication is that both >CRC-16 and CRC-32 must be run in parallel on all data received on a >given CID. For hardware implementations, it means that two pipelines >are required. For software implementations (think 860SAR on a T1 >line), it means that the inner loop does twice as work. For both, >this bumps up the intermediate state storage requirement for each of >these streams and the I/O rate to that storage. > >I'm not an AAL2 expert, and I don't know the restrictions on UUI >values (why is 27 'continue' and what are 28-31?), but it certainly >would be nice to alert the receiver about the CRC mode in use before >the first chunk has to be processed rather than as the last one is. This is a good point. I didn't think of this. You're right. On the receiver you couldn't run the CRC check algorithm until you received the entire packet. I agree that doing a dynamic CRC based on packet length doesn't sound like a good idea. >As a slightly simpler way of accomplishing the same thing, why not >just nail down the CRC choice on a per-CID basis? For your proposed >VoIP usage, you'd have one CRC-16 only stream for C-RTP data, and >another CRC-32 only stream for regular IP. This seems like a reasonable alternative. However, I'm not sure it's even necessary to use different CRC lengths for different CIDs. Another alternative that was suggested by one of the other authors was to do CRC-16 only in the base protocol and allow CRC-32 as an optional negotiated format. The number of CRC bits used only limits your maximum payload size. As an example, PPP over HDLC runs with a 16 bit FCS with an optionally negotiated 32 bit FCS. What do you think about this method? Bruce T >-- >James Carlson, Internet Engineering >SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 >MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 >Second Edition now available - http://people.ne.mediaone.net/carlson/ppp Bruce Thompson Cisco Systems email: brucet@cisco.com office: (408)527-0446 home office: (408)868-0112 San Jose, CA From owner-ietf-ppp-outgoing@merit.edu Fri Dec 22 17:05:08 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15308 for ; Fri, 22 Dec 2000 17:05:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 37D805DDF5; Fri, 22 Dec 2000 17:00:48 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 806965DE58; Fri, 22 Dec 2000 17:00:47 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id A33F75DDF5 for ; Fri, 22 Dec 2000 16:58:38 -0500 (EST) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA01474; Fri, 22 Dec 2000 13:58:36 -0800 (PST) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA00305; Fri, 22 Dec 2000 16:58:35 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.1+Sun/8.11.1) id eBMLwnR129541; Fri, 22 Dec 2000 16:58:49 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14915.52889.392906.7357@gargle.gargle.HOWL> Date: Fri, 22 Dec 2000 16:58:49 -0500 (EST) From: James Carlson To: Bruce A Thompson Cc: ietf-ppp@merit.edu Subject: Re: Request to accept PPP over AAL2 as a PPPEXT Work Group Item In-Reply-To: Bruce A Thompson's message of 22 December 2000 10:16:03 References: <4.3.1.0.20001213124217.017f72c0@sigma.cisco.com> <4.3.1.0.20001220160622.01cf27b0@sigma.cisco.com> <4.3.1.0.20001222093736.0126ca38@sigma.cisco.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Bruce A Thompson writes: > OK, I understand your point. It sounds like you are recommending > splitting PPP over AAL2 into 2 drafts. Yes. > One would be the generic "PPP over AAL2" which would describe the > basic encapsulation and allow the use of one or more CIDs but not > describe the application of multiple CIDs. The second would be > "Integrated Services using PPP over AAL2". It would describe the > usage of multiple CIDs for LFI when multiple classes of delay > sensitive traffic are carried over an AAL2 link. Or perhaps "Multiple Service Classes using PPP over AAL2" or even "Mapping VoIP using PPP over AAL2." Yes, that's the idea. > I don't have a problem with doing this if this is the right thing to > do. I would note though the RFC 2686 actually describes an extension > to the encapsulation format described by RFC 1990. I thought this > may be why it was created as a separate RFC and not a different > version of RFC 1990. That's true; I just referenced that as an example way to describe the mechanism without assuming a particular service to be delivered. > One more question. I noticed that RFC 2686 has some new LCP options > for negotiating the number of classes that will be used between > peers. Right. Other than static configuration, there's no way to do this. > I wondering whether a method like this should also be used > for the multi CID usage of PPP over AAL2. You could have single CID > usage by default for PPP over AAL2 and then have an LCP option for > negotiating the usage of multiple CIDs by PPP over AAL2. One > complication here is that this signaling is somewhat redundant to > Q.2630.2 signaling that allows you to allocate multiple CIDs to an > application. Any opinions on this? If the ATM UNI signaling already buys you this, then I don't see a reason for PPP to mirror the same features. Simply specify that the number of CIDs in use must be negotiated by standard ATM signaling, and that PPP implementations must abide by what ATM has negotiated. At best, if you allowed LCP to negotiate, you'd duplicate what's already there. More likely, you'd set up new failure modes where one part negotiates something different from the other. For things that don't *have* to be negotiated, we do try to avoid negotiating. > This is a good point. I didn't think of this. You're right. On the > receiver you couldn't run the CRC check algorithm until you received > the entire packet. I agree that doing a dynamic CRC based on packet > length doesn't sound like a good idea. Actually, it can (as I suggest) also run both CRCs in parallel and select the right one at the end. Either way, it's a complication. > >As a slightly simpler way of accomplishing the same thing, why not > >just nail down the CRC choice on a per-CID basis? For your proposed > >VoIP usage, you'd have one CRC-16 only stream for C-RTP data, and > >another CRC-32 only stream for regular IP. > > This seems like a reasonable alternative. However, I'm not sure it's > even necessary to use different CRC lengths for different CIDs. Well, I was trying to preserve this since I didn't want to argue (yet) about the necessity of it. Yes, I would generally say that this is an unnecessary complication. If ATM were to be carried over PDH links where bit flips rather than bursts are arguably more likely in some deployment, I might see a reason for this complication. (But, then, I can't say I'm an expert in ATM deployment or, for that matter, error control theory.) > Another alternative that was suggested by one of the other authors > was to do CRC-16 only in the base protocol and allow CRC-32 as an > optional negotiated format. The number of CRC bits used only limits > your maximum payload size. Not exactly. It just changes the probability of undetected error and, for a given error distribution, the probability versus packet size. There's no actual payload limit. > As an example, PPP over HDLC runs with a 16 bit FCS with an > optionally negotiated 32 bit FCS. What do you think about this > method? RFC 1570 is a clumsy method at best, but it's hard to see how to do better for a negotiated feature. The problem is that since you have sublinks below PPP (rather than individual parallel PPP links) over those CID channels, you can't negotiate the parameters separately. One thing you could do would be to negotiate PPP separately on each CID and use LBD to tie them together. That would give you the FCS flexibility at the cost of a single extra LCP negotiation per CID. If ATM signaling can carry additional information to indicate the FCS type to be used on each CID, then you could use that instead and retain the original sublink model. Finally, in your second draft you could just establish conventions for CID usage, such as lowest-numbered CID in use is CRC-32, and any others are CRC-16. -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 Second Edition now available - http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Sat Dec 23 12:24:26 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05552 for ; Sat, 23 Dec 2000 12:24:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id BAC005DDA6; Sat, 23 Dec 2000 12:23:48 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 973A05DDCB; Sat, 23 Dec 2000 12:23:48 -0500 (EST) Received: from cisco.com (sigma.cisco.com [171.69.63.142]) by segue.merit.edu (Postfix) with ESMTP id A9A365DDA6 for ; Sat, 23 Dec 2000 12:23:46 -0500 (EST) Received: from brucet-nt3.cisco.com (rtp-dial-1-8.cisco.com [10.83.97.8]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id JAA19178; Sat, 23 Dec 2000 09:23:44 -0800 (PST) Message-Id: <4.3.1.0.20001223075248.0126a128@sigma.cisco.com> X-Sender: brucet@sigma.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sat, 23 Dec 2000 08:20:40 -0800 To: James Carlson From: Bruce A Thompson Subject: Re: Request to accept PPP over AAL2 as a PPPEXT Work Group Item Cc: ietf-ppp@merit.edu In-Reply-To: <14915.52889.392906.7357@gargle.gargle.HOWL> References: <4.3.1.0.20001213124217.017f72c0@sigma.cisco.com> <4.3.1.0.20001220160622.01cf27b0@sigma.cisco.com> <4.3.1.0.20001222093736.0126ca38@sigma.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu At 04:58 PM 12/22/2000 -0500, James Carlson wrote: >Bruce A Thompson writes: > > > Another alternative that was suggested by one of the other authors > > was to do CRC-16 only in the base protocol and allow CRC-32 as an > > optional negotiated format. The number of CRC bits used only limits > > your maximum payload size. > >Not exactly. It just changes the probability of undetected error and, >for a given error distribution, the probability versus packet size. >There's no actual payload limit. Right. The probability of an undetected error goes up as the packet size increases. The packet size limit is where the probability of an undetected error increases past some predefined acceptable limit. I thought this was obvious, so I didn't state it. I'm also not an error control theory expert. It would be great if we could get someone who was an error control theory expert with knowledge of error distribution on typical ATM physical links to propose a CRC strategy. > > As an example, PPP over HDLC runs with a 16 bit FCS with an > > optionally negotiated 32 bit FCS. What do you think about this > > method? > >RFC 1570 is a clumsy method at best, but it's hard to see how to do >better for a negotiated feature. > >The problem is that since you have sublinks below PPP (rather than >individual parallel PPP links) over those CID channels, you can't >negotiate the parameters separately. > >One thing you could do would be to negotiate PPP separately on each >CID and use LBD to tie them together. That would give you the FCS >flexibility at the cost of a single extra LCP negotiation per CID. I don't know what "LBD" stands for. Can you expand this TLA? >If ATM signaling can carry additional information to indicate the FCS >type to be used on each CID, then you could use that instead and >retain the original sublink model. This could be done. However, PPP over AAL2 will often run over statically configured PVCs. Many (most) AAL2 deployments do not use Q.2630 at all. This would also be an argument for using PPP to negotiate the number of CIDs. The PPP negotiation could be used when Q.2630 was not used to establish the CIDs and usage of the CIDs >Finally, in your second draft you could just establish conventions for >CID usage, such as lowest-numbered CID in use is CRC-32, and any >others are CRC-16. Seems like we need to have CRC expert decide the CRC strategy before we go too much further down any of these paths. It's still not clear to me when a CRC-32 might really be necessary vs. just CRC (or FCS) 16. I don't know the acceptable undetected error rate orthe error distributions for likely ATM physical layers. Because of this I don't know that max packet size where a CRC-16 can be used. If it's above 1500 bytes, then it seems like going to a static CRC size for the PPP session would be just fine. Bruce T >-- >James Carlson, Internet Engineering >SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 >MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 >Second Edition now available - http://people.ne.mediaone.net/carlson/ppp Bruce Thompson Cisco Systems email: brucet@cisco.com office: (408)527-0446 home office: (408)868-0112 San Jose, CA From owner-ietf-ppp-outgoing@merit.edu Sat Dec 23 13:40:22 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05945 for ; Sat, 23 Dec 2000 13:40:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id C83D35DE33; Sat, 23 Dec 2000 13:37:31 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B65BD5DE31; Sat, 23 Dec 2000 13:37:31 -0500 (EST) Received: from h006008986325.ne.mediaone.net (h006008986325.ne.mediaone.net [24.218.16.153]) by segue.merit.edu (Postfix) with ESMTP id E497E5DDCB for ; Sat, 23 Dec 2000 13:37:29 -0500 (EST) Received: (from carlson@localhost) by h006008986325.ne.mediaone.net (8.11.0/8.11.0) id eBNIbMF06412; Sat, 23 Dec 2000 13:37:22 -0500 From: James Carlson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14916.61665.927798.617961@h006008986325.ne.mediaone.net> Date: Sat, 23 Dec 2000 13:37:21 -0500 (EST) To: Bruce A Thompson Cc: ietf-ppp@merit.edu Subject: Re: Request to accept PPP over AAL2 as a PPPEXT Work Group Item In-Reply-To: Bruce A Thompson's message of 23 December 2000 08:20:40 References: <4.3.1.0.20001213124217.017f72c0@sigma.cisco.com> <4.3.1.0.20001220160622.01cf27b0@sigma.cisco.com> <4.3.1.0.20001222093736.0126ca38@sigma.cisco.com> <4.3.1.0.20001223075248.0126a128@sigma.cisco.com> X-Mailer: VM 6.75 under Emacs 20.6.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Bruce A Thompson writes: > I'm also not an error control theory expert. It would be great if we > could get someone who was an error control theory expert with > knowledge of error distribution on typical ATM physical links to > propose a CRC strategy. Maybe one of the Lucent guys who lurks here will speak up ... > >One thing you could do would be to negotiate PPP separately on each > >CID and use LBD to tie them together. That would give you the FCS > >flexibility at the cost of a single extra LCP negotiation per CID. > > I don't know what "LBD" stands for. Can you expand this TLA? http://www.ietf.org/internet-drafts/draft-ietf-pppext-lbd-02.txt The idea is that you use MP-style negotiation, but you don't actually fragment or reassemble. Thus, each member link needs to do LCP (and authentication, if used), but the NCPs are held in common. > Seems like we need to have CRC expert decide the CRC strategy before > we go too much further down any of these paths. It's still not clear > to me when a CRC-32 might really be necessary vs. just CRC (or FCS) > 16. Nor to me. (For what it's worth, the "FCS" term comes from the ISO 3309 name for that field. CRC-16 and CRC-32 are two possible check values that can be used for the PPP FCS. There's also a CRC-48, but that's patented by DEC and not generally used.) > I don't know the acceptable undetected error rate orthe error > distributions for likely ATM physical layers. Because of this I > don't know that max packet size where a CRC-16 can be used. If it's > above 1500 bytes, then it seems like going to a static CRC size for > the PPP session would be just fine. That would certainly be the simplest and most commonly-used strategy. -- James Carlson "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp