From owner-gsmp@psyton.com Fri Apr 7 07:55:42 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06379 for ; Fri, 7 Apr 2000 07:55:41 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id HAA26862 for gsmp-list; Fri, 7 Apr 2000 07:32:13 -0400 Received: from etri.re.kr (mail.etri.re.kr [129.254.113.113]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id HAA26859 for ; Fri, 7 Apr 2000 07:32:11 -0400 Received: from hyryu (ipswitch1.etri.re.kr [129.254.193.226]) by etri.re.kr (8.9.3/8.9.3) with SMTP id UAA29982 for ; Fri, 7 Apr 2000 20:28:40 +0900 (KST) Message-ID: <004a01bfa0d0$78b17240$e2c1fe81@etri.re.kr> From: =?ks_c_5601-1987?B?t/nIo7/r?= To: "gsmp" Subject: Encapsulation Method Date: Fri, 7 Apr 2000 20:32:54 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0047_01BFA0D0.73AFB540" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com This is a multi-part message in MIME format. ------=_NextPart_000_0047_01BFA0D0.73AFB540 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGkgQWxsLg0KDQpJIGhhdmUgYSBxdWVzdGlvbnMgZm9yIEdTTVAgdjMuMChkcmFmdC1pZXRmLWdz bXAtbzQudHh0KQ0KDQpXaGF0IGlzIEVuY2Fwc3VsYXRpb24gbWV0aG9kIGluIEdTTVAgQ29ubmVj dGlvbiBNZXNzYWdlID8NCg0KDQoNCg0KDQo= ------=_NextPart_000_0047_01BFA0D0.73AFB540 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtz X2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjAwLjIzMTQuMTAwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkhpIEFsbC48 L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+SSBoYXZl IGEgcXVlc3Rpb25zIGZvciBHU01QIA0KdjMuMChkcmFmdC1pZXRmLWdzbXAtbzQudHh0KTwvRk9O VD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZP TlQgc2l6ZT0yPldoYXQgaXMgRW5jYXBzdWxhdGlvbiBtZXRob2QgaW4gR1NNUCBDb25uZWN0aW9u IE1lc3NhZ2UgDQo/PC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7 PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7 PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0047_01BFA0D0.73AFB540-- From owner-gsmp@psyton.com Fri Apr 7 08:44:58 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07018 for ; Fri, 7 Apr 2000 08:44:57 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id IAA27111 for gsmp-list; Fri, 7 Apr 2000 08:36:33 -0400 Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id IAA27108 for ; Fri, 7 Apr 2000 08:36:29 -0400 From: avri.doria@nokia.com Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id PAA21398 for ; Fri, 7 Apr 2000 15:36:28 +0300 (EETDST) Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com [172.18.242.182]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id PAA22800 for ; Fri, 7 Apr 2000 15:36:26 +0300 (EETDST) Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id ; Fri, 7 Apr 2000 07:35:17 -0500 Message-ID: To: gsmp@psyton.com Subject: RE: Encapsulation Method Date: Fri, 7 Apr 2000 07:34:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="KS_C_5601-1987" Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Hi, There are 3 encapsulations defined so far: IP, ATM and raw Ethernet. These are documented in draft-ietf-gsmp-encaps-00.txt Regards, a. ----------------------------------- avri doria GSM: +1 781 308 7680 From owner-gsmp@psyton.com Fri Apr 7 23:35:17 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25366 for ; Fri, 7 Apr 2000 23:35:17 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id XAA29827 for gsmp-list; Fri, 7 Apr 2000 23:26:36 -0400 Received: from etri.re.kr (mail.etri.re.kr [129.254.113.113]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id XAA29824 for ; Fri, 7 Apr 2000 23:26:34 -0400 Received: from hyryu (ipswitch1.etri.re.kr [129.254.193.226]) by etri.re.kr (8.9.3/8.9.3) with SMTP id MAA01526 for ; Sat, 8 Apr 2000 12:23:13 +0900 (KST) Message-ID: <000d01bfa155$cef4b920$e2c1fe81@etri.re.kr> From: =?ks_c_5601-1987?B?t/nIo7/r?= To: References: Subject: Re: Encapsulation Method Date: Sat, 8 Apr 2000 12:27:29 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nighthawk.psyton.com id XAA29825 Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Content-Transfer-Encoding: 8bit Thank for your reply. I see 3 GSMP message encapsulation method.(TCP, Ethernet and ATM Encapsulation) but I want to Encapsulation Method field in GSMP connection message. (page 26 in draft-ietf-gsmp-04.txt) Best Regards. Hoyong, Ryu. ----- Original Message ----- 보낸 사람: 받는 사람: 보낸 날짜: 2000년 4월 7일 금요일 제목: RE: Encapsulation Method > Hi, > > There are 3 encapsulations defined so far: IP, ATM and raw Ethernet. > > These are documented in draft-ietf-gsmp-encaps-00.txt > > Regards, > > a. > ----------------------------------- > avri doria > GSM: +1 781 308 7680 > From owner-gsmp@psyton.com Fri Apr 7 23:48:52 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25483 for ; Fri, 7 Apr 2000 23:48:52 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id XAA29935 for gsmp-list; Fri, 7 Apr 2000 23:43:46 -0400 Received: from etri.re.kr (mail.etri.re.kr [129.254.113.113]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id XAA29932 for ; Fri, 7 Apr 2000 23:43:44 -0400 Received: from hyryu (ipswitch1.etri.re.kr [129.254.193.226]) by etri.re.kr (8.9.3/8.9.3) with SMTP id MAA02001 for ; Sat, 8 Apr 2000 12:40:24 +0900 (KST) Message-ID: <002001bfa158$35964de0$e2c1fe81@etri.re.kr> From: =?ks_c_5601-1987?B?t/nIo7/r?= To: References: Subject: Re: Encapsulation Method Date: Sat, 8 Apr 2000 12:44:41 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nighthawk.psyton.com id XAA29933 Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Content-Transfer-Encoding: 8bit Thank for your reply. I see 3 GSMP message encapsulation method.(TCP, Ethernet and ATM Encapsulation) but I want to know Encapsulation Method field in GSMP connection message. (page 26 in draft-ietf-gsmp-04.txt) Best Regards. ----- Original Message ----- 보낸 사람: 받는 사람: 보낸 날짜: 2000년 4월 7일 금요일 제목: RE: Encapsulation Method > Hi, > > There are 3 encapsulations defined so far: IP, ATM and raw Ethernet. > > These are documented in draft-ietf-gsmp-encaps-00.txt > > Regards, > > a. > ----------------------------------- > avri doria > GSM: +1 781 308 7680 > From owner-gsmp@psyton.com Tue Apr 11 15:17:10 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17789 for ; Tue, 11 Apr 2000 15:17:10 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id OAA09919 for gsmp-list; Tue, 11 Apr 2000 14:52:19 -0400 Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id OAA09916 for ; Tue, 11 Apr 2000 14:52:15 -0400 From: avri.doria@nokia.com Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id VAA28651; Tue, 11 Apr 2000 21:52:07 +0300 (EETDST) Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com [172.18.242.182]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id VAA09810; Tue, 11 Apr 2000 21:51:42 +0300 (EETDST) Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id ; Tue, 11 Apr 2000 13:50:31 -0500 Message-ID: To: gsmp@psyton.com, hyryu@etri.re.kr Cc: clint.bishard@wcom.com Subject: Adaptation framing was RE: Encapsulation Method Date: Tue, 11 Apr 2000 13:49:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="KS_C_5601-1987" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nighthawk.psyton.com id OAA09917 Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Content-Transfer-Encoding: 8bit Hi, Sorry for answering the wrong question. Then again that is one of the reasons we decided to rename the encapsulation field to the adaptation field at the last meeting - I, for one, kept getting confused. And yes, you are right, that is a field I neglected to document in the 04 revision of the spec. Following is a draft of the documentation for that field. Please send comments on this text. I would also appreciate recommendations for more adaptations methods to include in the list of adaptations. ------------- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |IQS|OQS|P|N|x|O| Adaptation Method | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ O Flag The Opaque flag indicates whether the adaptation field is opaque, or whether it refers to a method defined by the protocol. Adaptation Method The adaptation method is used to define the adaptation framing that in use when moving traffic from one port type to another port type; e.g. from a frame relay port to an ATM port. If no adaptation framing is used the field must be zero. This interpretation of this field is controlled by the Opaque flag. If the Opaque flag is set, then this field is defined by the switch manufacturer and is not defined in this protocol. If the opaque flag is not set, then the field is divided into 2 12 bit fields as shown below: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |IQS|OQS|P|N|x|O| Input Adaptation | Output Adaptation | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Input Adaptation Adaptation framing method used on incoming connections. Output Adaptation Adaptation framing method used on outgoing connections. Adaptation Types: 0x100 PPP 0x200 FRF.5 0x201 FRF.8 ... ... --------------------------------------------------------------------------- thanks a. ----------------------------------- avri doria GSM: +1 781 308 7680 > -----Original Message----- > From: hyryu@etri.re.kr [mailto:hyryu@etri.re.kr] > Sent: 08 April, 2000 8:45 AM > To: gsmp@psyton.com > Subject: Re: Encapsulation Method > > > Thank for your reply. > > I see 3 GSMP message encapsulation method.(TCP, Ethernet and > ATM Encapsulation) > > but I want to know Encapsulation Method field in GSMP > connection message. (page 26 in draft-ietf-gsmp-04.txt) > > Best Regards. > > > ----- Original Message ----- > 보낸 사람: > 받는 사람: > 보낸 날짜: 2000년 4월 7일 금요일 > 제목: RE: Encapsulation Method > > > > Hi, > > > > There are 3 encapsulations defined so far: IP, ATM and raw Ethernet. > > > > These are documented in draft-ietf-gsmp-encaps-00.txt > > > > Regards, > > > > a. > > ----------------------------------- > > avri doria > > GSM: +1 781 308 7680 > > > From owner-gsmp@psyton.com Mon Apr 17 05:19:36 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27849 for ; Mon, 17 Apr 2000 05:19:32 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id EAA28775 for gsmp-list; Mon, 17 Apr 2000 04:55:45 -0400 Received: from qhars002.nortel.com (qhars002.NortelNetworks.com [192.100.101.19]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id EAA28772 for ; Mon, 17 Apr 2000 04:55:44 -0400 Received: from zhard00d.europe.nortel.com (actually zhard00d) by qhars002.nortel.com; Mon, 17 Apr 2000 09:54:50 +0100 Received: from zvb1c002.corpemea.baynetworks.com ([141.251.160.82]) by zhard00d.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 22FBXJX3; Mon, 17 Apr 2000 09:54:50 +0100 Received: from europem01.nt.com (KSUNDELL [141.251.192.207]) by zvb1c002.corpemea.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id JAD8K3CY; Mon, 17 Apr 2000 10:54:48 +0200 Message-ID: <38FAD1CA.6B373F56@europem01.nt.com> Date: Mon, 17 Apr 2000 10:56:42 +0200 X-Sybari-Space: 00000000 00000000 00000000 From: "Kenneth Sundell" X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: gsmp-list Subject: draft GSMP WG minutes Content-Type: multipart/alternative; boundary="------------3E13A2F7E17F720B7FA8CD5C" Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com --------------3E13A2F7E17F720B7FA8CD5C Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Folks, draft GSMP WG minutes from Adelaide attached. Regards, Ken Minutes GSMP Working Group, Adelaide 3/30/00 -------------------------------------------- The meeting was co-chaired by Avri Doria and Kenneth Sundell and was divided into two sections; the review of current documentation and the discussion about future work items for the working group. Changes to the three standards track documents currently being worked on were discussed. While there were several editorial and minor technical comments on the drafts, there were no major technical objections. The plan is to update the documents, fixing known problems by the end of April and then to have a WG last call during May. 1. Review of draft-ietf-gsmp-04 Avri presented the changes since revision �02. Revision �03 was issued before the editing session in New Orleans (Feb 3), while revision -04 was released after that session. Since the differences between �02 and �03 has not been presented at an IETF meeting, though they had been presented on the mailing list, the co-chairs decided to present all changes from �02 to �04 in this session. There will be at least a revision �05 before the document will proceed to working group last call. The encapsulation section was, as previously agreed, moved to a separate document, draft-ietf-gsmp-encaps-00.txt. All failure response messages were gathered and moved to appendix A. The �04 introduced the notion of TLV Labels, i.e. labels that are longer than 28 bits. For clarity, the notion of extended label has changed to stacked label. The �03 introduced the reservation message which allows for resources to be reserved for a connection before the actual label mapping is known. Revision -03 also included support for redundant adjacencies. A proposal for adding output/input service selectors in the Add Branch message had been discussed on the list and also proposed at the New Orleans editing session. The capability was added to �04. Other additions to �04 included: a simple mechanism for turning of the flow control, a way to do multicast queries in order to support those switches that have dedicated ranges of labels for multipoint connections, support for discontinuous label ranges, the addition of event sequence numbers and event flags to the port configuration message. Additionally, the service model was updated to include support for Circuit Emulation Services (-04). 2. Review of draft-ietf-gsmp-mib-01 (15) Joachim Buerkle presented the updated GSMP MIB that is co- authored by Hans Sjostrand and Balaji Srinivasan. The GSMP MIB was totally rewritten. The GSMP MIB is focused on the protocol and not covering partition issues. Joachim pointed at work done in MSF where they are producing a protocol independent partition MIB. He went through the different GSMP MIB objects (slides will be available in the proceedings). There was a question about whether the structure of multiple controller to a single switch partition should be represented in the MIB. The answer was yes. The document will be updated during April. Updates in the next version will be mainly changes in wordings, some new tables and maybe addition of statistics into the MIB. 3. Review of draft-ietf-gsmp-applicability-00.txt Avri presented the applicability draft. There is a minor set of documents that are needed before we can proceed to IESG group last call. Apart from the GSMP specification, GSMP MIB and GSMP Encapsulation documents, an informational RFC for GSMP applicability is needed. The document introduces the reader to concepts and notions that are used within GSMP e.g. switch partitioning, controller/switch interaction and service support. A question about the MSF's role in relation to GSMP was raised, i.e. where they defining their own version of GSMP. Avri answered that IETF is defining the protocol and MSF will be referencing the RFC in its implementation agreement. Joachim clarified that MSF draft applicability documents are not publicly available until they have been approved for release by the membership. The minimal set of messages needed to support MPLS was discussed. The applicability document list the messages required for minimal MPLS support. 4. Security issues in draft-ietf-gsmp-encaps-00 The main content of the encapsulation draft was moved from draft-ietf-gsmp-02.txt. A security section has been added to the document. A change that needs to be made to that draft involves requiring the support of IPsec when the IP encapsulation is used. 5. Working Group Last Call Text revision of the GSMP spec will be due in approximately 3 weeks. The GSMP MIB co-authors will try to make a new revision within the next 3-4 weeks. It is very important that people read the documents and send appropriate comments on the list. Non technical editorial changes should be sent to the authors directly. A two weeks WG Last Call will be issued in the beginning of May. 6. Implementation Experience Joachim Buerkle of Marconi communications (wireline access system) presented on their work with GSMP. They have produced I-Ds on resource reservation, move output branch and GSMP MIB. In their implementation they are using the ATM encapsulation and implementing the ATM specific features. There were questions about interoperability. A lot of people say that they are implementing GSMP, but only a few have done this in public. Service providers are soliciting products. 7. Discussion of charter update The group then spoke about future activities. Unless the charter is redefined, the working group will go dormant after the last call until implementations and implementation issues crop up. A discussion was held to determine whether there was real interest in adding additional features to GSMP beyond those currently planned. Several different possibilities where discussed. 7.1 Requirements for GSMP support of Optical switching A presentation was made on using GSMP for controlling Edge nodes, and optical interconnects within an IP over optics environment. This presentation was essentially a repetition of one given earlier in the week at the IPO BOF, though it did focus more on the changes required in GSMP then on the possibilities for optical network control. Basically, a controller/router could control an OXC over GSMP, either through use of an out of bound network or via a dedicated "control" wavelength. New label TLVs were introduced to handle label types such as fiber bundle, arbitrary number fibers in that bundle, a single fiber, arbitrary lambdas in that fiber, a single lambda etc. Several questions were raised; whether we need a raw optical encapsulation for GSMP messages or if we should require use of the IP encapsulation, whether we need one single TLV or several for accommodating the different types of optical labels and whether there was an existing service model for optical switches which GSMP could use or would the group need to define one. 7.2 Future Requirements for GSMP Several other proposals for new work were discussed: - Add support for SDH port types. - Investigate a rework of the flow control mechanisms in GSMP. - Add support for switching IP packets (L3 switching). Part of the support for this already exists in the protocol, but many of the elements which would be required, are still lacking. This effort would probably require a requirements effort first. - Continue tracking work on QoS service models. 7.3 Conclusion There was definite interest in continuing the work of the WG. In fact instead of having a passive (i.e. does anyone object to continuing work on these and similar items), we had an active show of hands on whether folks thought these issues were worth pursuing. Of those voting, and approximately 2/3 voted, there was a clear consensus for continuing the group. The intention is the chairs discuss a specific charter amendment on the list before making the formal request to the IESG. In terms of vendors and service providers interested in seeing the work continuing, there was positive interest from several companies. --------------3E13A2F7E17F720B7FA8CD5C Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
Folks,
draft GSMP WG minutes from Adelaide attached.

Regards,
Ken
 

Minutes GSMP Working Group, Adelaide 3/30/00
--------------------------------------------

   The meeting was co-chaired by Avri Doria and Kenneth
   Sundell and was divided into two sections; the review of
   current documentation and the discussion about future work
   items for the working group.

   Changes to the three standards track documents currently
   being worked on were discussed. While there were several
   editorial and minor technical comments on the drafts, there
   were no major technical objections. The plan is to update
   the documents, fixing known problems by the end of April
   and then to have a WG last call during May.
 

1.  Review of draft-ietf-gsmp-04

   Avri presented the changes since revision ­02. Revision ­03
   was issued before the editing session in New Orleans (Feb
   3), while revision -04 was released after that session.
   Since the differences between ­02 and ­03 has not been
   presented at an IETF meeting, though they had been
   presented on the mailing list, the co-chairs decided to
   present all changes from ­02 to ­04 in this session. There
   will be at least a revision ­05 before the document will
   proceed to working group last call.

   The encapsulation section was, as previously agreed, moved
   to a separate document, draft-ietf-gsmp-encaps-00.txt.

   All failure response messages were gathered and moved to
   appendix A.

   The ­04 introduced the notion of TLV Labels, i.e. labels
   that are longer than 28 bits. For clarity, the notion of
   extended label has changed to stacked label.

   The ­03 introduced the reservation message which allows for
   resources to be reserved for a connection before the actual
   label mapping is known. Revision -03 also included support
   for redundant adjacencies.

   A proposal for adding output/input service selectors in the
   Add Branch message had been discussed on the list and also
   proposed at the New Orleans editing session. The capability
   was added to ­04.

   Other additions to ­04 included: a simple mechanism for
   turning of the flow control, a way to do multicast queries
   in order to support those switches that have dedicated
   ranges of labels for multipoint connections, support for
   discontinuous label ranges, the addition of event sequence
   numbers and event flags to the port configuration message.

   Additionally, the service model was updated to include
   support for Circuit Emulation Services (-04).
 

2.  Review of draft-ietf-gsmp-mib-01 (15)

   Joachim Buerkle presented the updated GSMP MIB that is co-
   authored by Hans Sjostrand and Balaji Srinivasan.

   The GSMP MIB was totally rewritten. The GSMP MIB is focused
   on the protocol and not covering partition issues. Joachim
   pointed at work done in MSF where they are producing a
   protocol independent partition MIB. He went through the
   different GSMP MIB objects (slides will be available in the
   proceedings).

   There was a question about whether the structure of
   multiple controller to a single switch partition should be
   represented in the MIB.  The answer was yes.

   The document will be updated during April. Updates in the
   next version will be mainly changes in wordings, some new
   tables and maybe addition of statistics into the MIB.
 

3.  Review of draft-ietf-gsmp-applicability-00.txt

   Avri presented the applicability draft. There is a minor
   set of documents that are needed before we can proceed to
   IESG group last call. Apart from the GSMP specification,
   GSMP MIB and GSMP Encapsulation documents, an informational
   RFC for GSMP applicability is needed. The document
   introduces the reader to concepts and notions that are used
   within GSMP e.g. switch partitioning, controller/switch
   interaction and service support.

   A question about the MSF's role in relation to GSMP was
   raised, i.e. where they defining their own version of GSMP.
   Avri answered that IETF is defining the protocol and MSF
   will be referencing the RFC in its implementation
   agreement. Joachim clarified that MSF draft applicability
   documents are not publicly available until they have been
   approved for release by the membership.

   The minimal set of messages needed to support MPLS was
   discussed. The applicability document list the messages
   required for minimal MPLS support.

4.  Security issues in draft-ietf-gsmp-encaps-00

   The main content of the encapsulation draft was moved from
   draft-ietf-gsmp-02.txt. A security section has been added
   to the document. A change that needs to be made to that
   draft involves requiring the support of IPsec when the IP
   encapsulation is used.
 

5.  Working Group Last Call

   Text revision of the GSMP spec will be due in approximately
   3 weeks. The GSMP MIB co-authors will try to make a new
   revision within the next 3-4 weeks. It is very important
   that people read the documents and send appropriate
   comments on the list. Non technical editorial changes
   should be sent to the authors directly.

   A two weeks WG Last Call will be issued in the beginning of
   May.
 

6.  Implementation Experience

   Joachim Buerkle of Marconi communications (wireline access
   system) presented on their work with GSMP. They have
   produced I-Ds on resource reservation, move output branch
   and GSMP MIB. In their implementation they are using the
   ATM encapsulation and  implementing the  ATM specific
   features.

   There were questions about interoperability. A lot of
   people say that they are implementing GSMP, but only a few
   have done this in public. Service providers are soliciting
   products.
 

7.  Discussion of charter update

   The group then spoke about future activities.  Unless the
   charter is redefined, the working group will go dormant
   after the last call until implementations and
   implementation issues crop up. A discussion was held to
   determine whether there was real interest in adding
   additional features to GSMP beyond those currently planned.
   Several different possibilities where discussed.

7.1  Requirements for GSMP support of Optical switching

   A presentation was made on using GSMP for controlling Edge
   nodes, and optical interconnects within an IP over optics
   environment.  This presentation was essentially a
   repetition of one given earlier in the week at the IPO BOF,
   though it did focus more on the changes required in GSMP
   then on the possibilities for optical network control.
   Basically, a controller/router could control an OXC over
   GSMP, either through use of an out of bound network or via
   a dedicated "control" wavelength.

   New label TLVs were introduced to handle label types such
   as fiber bundle, arbitrary number fibers in that bundle, a
   single fiber, arbitrary lambdas in that fiber, a single
   lambda etc.

   Several questions were raised; whether we need a raw
   optical encapsulation for GSMP messages or if we should
   require use of the IP encapsulation, whether we need one
   single TLV or several for accommodating the different types
   of optical labels and whether there was an existing service
   model for optical switches which GSMP could use or would
   the group need to define one.

7.2  Future Requirements for GSMP

   Several other proposals for new work were discussed:

   -  Add support for SDH port types.

   -  Investigate a rework of the flow control mechanisms in
      GSMP.

   -  Add support for switching IP packets (L3 switching).
      Part of the support for this already exists in the
      protocol, but many of the elements which would be
      required, are still lacking. This effort would probably
      require a requirements effort first.

   -  Continue tracking work on QoS service models.
 

7.3  Conclusion

   There was definite interest in continuing the work of the
   WG. In fact instead of having a passive (i.e. does anyone
   object to continuing work on these and similar items), we
   had an active show of hands on whether folks thought these
   issues were worth pursuing. Of those voting, and
   approximately 2/3 voted, there was a clear consensus for
   continuing the group. The intention is the chairs discuss a
   specific charter amendment on the list before making the
   formal request to the IESG.

   In terms of vendors and service providers interested in
   seeing the work continuing, there was positive interest
   from several companies.
  --------------3E13A2F7E17F720B7FA8CD5C-- From owner-gsmp@psyton.com Mon Apr 17 16:26:40 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09198 for ; Mon, 17 Apr 2000 16:26:40 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id QAA30281 for gsmp-list; Mon, 17 Apr 2000 16:17:16 -0400 Received: from exchange.ensim.com (dnai-216-15-53-162.cust.dnai.com [216.15.53.162]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id QAA30278 for ; Mon, 17 Apr 2000 16:17:15 -0400 Received: from ethel (dhcp-10-4-3-7.dhcp.ensim.com [10.4.3.7]) by exchange.ensim.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HGNYVFC1; Mon, 17 Apr 2000 13:16:27 -0700 Message-Id: <4.2.2.20000417130544.00d747a0@exchange.ensim.com> X-Sender: pn@exchange.ensim.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 17 Apr 2000 13:07:53 -0700 To: gsmp@psyton.com From: Peter Newman Subject: Re: draft GSMP WG minutes In-Reply-To: <38FAD1CA.6B373F56@europem01.nt.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com I often get asked (well, occasionally) about public implementations of GSMP. Could anyone give me any pointers that I could pass on? --Peter > > >6. Implementation Experience > > Joachim Buerkle of Marconi communications (wireline access > system) presented on their work with GSMP. They have > produced I-Ds on resource reservation, move output branch > and GSMP MIB. In their implementation they are using the > ATM encapsulation and implementing the ATM specific > features. > > There were questions about interoperability. A lot of > people say that they are implementing GSMP, but only a few > have done this in public. Service providers are soliciting > products. > --------- ****** New Location and Phone Numbers ****** ------------ Peter Newman direct: +1 408-745-3303 Chief Scientific Officer front desk: +1 408 745 3300 Ensim fax: +1 408 745 3399 1366 Borregas Drive email: pn@ensim.com Sunnyvale, CA 94089, USA web: http://www.ensim.com/~pn From owner-gsmp@psyton.com Wed Apr 19 07:38:38 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03829 for ; Wed, 19 Apr 2000 07:38:38 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id HAA03358 for gsmp-list; Wed, 19 Apr 2000 07:21:49 -0400 Received: from apocalypse.org (IDENT:root@apocalypse.org [192.48.232.17]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id HAA03355 for ; Wed, 19 Apr 2000 07:21:48 -0400 Received: from localhost (avri@localhost) by apocalypse.org (8.9.3/8.9.3) with ESMTP id HAA14850 for ; Wed, 19 Apr 2000 07:16:47 -0400 Date: Wed, 19 Apr 2000 07:16:47 -0400 (EDT) From: ad To: gsmp@psyton.com Subject: I-D ACTION:draft-ietf-gsmp-encaps-01.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the General Switch Management Protocol Working Group of the IETF. Title : GSMP Packet Encapsulations for ATM, Ethernet and TCP Author(s) : T. Worster, A. Doria Filename : draft-ietf-gsmp-encaps-01.txt Pages : 7 Date : 18-Apr-00 This memo specifies the encapsulation of GSMP packets in ATM, Ethernet and TCP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-gsmp-encaps-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-gsmp-encaps-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-gsmp-encaps-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000418080555.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-gsmp-encaps-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-gsmp-encaps-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000418080555.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-gsmp@psyton.com Thu Apr 20 10:27:43 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11542 for ; Thu, 20 Apr 2000 10:27:43 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id KAA07343 for gsmp-list; Thu, 20 Apr 2000 10:05:29 -0400 Received: from apocalypse.org (IDENT:root@apocalypse.org [192.48.232.17]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id KAA07340 for ; Thu, 20 Apr 2000 10:05:26 -0400 Received: from pavilion (IDENT:root@asylum [192.48.232.17]) by apocalypse.org (8.9.3/8.9.3) with SMTP id JAA30247 for ; Thu, 20 Apr 2000 09:59:29 -0400 Message-ID: <001f01bfaad1$7eefe140$6d21fea9@pavilion> From: "avri" To: Subject: I-D ACTION:draft-ietf-gsmp-05.txt Date: Thu, 20 Apr 2000 10:05:29 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Content-Transfer-Encoding: 7bit Hi, Just to let people know. The reason I forward these to the list instead of them coming directly is because we have turned off non-member submissions to try and prevent the spam that was becoming rampant. And as list admin, I can assure you spam continues. This revision is NOT the final one before working group last call. There will be at least one more. This revsion does contain the edits that were discussed in Adelaide. There will be a MSF meeting in Paris the first week of May. At this time, the specification will be discussed in the light of the requested changes document that was submitted by the MSF to the IETF. After that meeting, another revsion will be submitted to the group. Of course any changes will need to be discussed on this list. Other things that still need to be done before last call include completing the IANA considerations appendix. Also, there is one section of the document which still needs content. In the service model chapter, the diff serv capability set is still not defined. If any of the group participants who are diff serv knowledgable wishes to contribute text for this section, it will be greatly appreciated. Also there are still typos and other minor errors that need to be found and corrected. Finally, the abstract will be re-writen. As alwasy the comments of readers are greatly appreciated. The editors are trying to make sure that the document is consistent and clean, but the more reviewers the better. And obviously it is preferable to get substantive comments in before the last call, though they will be welcome then too. Thanks a. ------- avri doria +1 781 308 7680 > To: IETF-Announce: ; > Cc: gsmp@psyton.com > From: Internet-Drafts@ietf.org > Reply-to: Internet-Drafts@ietf.org > Subject: I-D ACTION:draft-ietf-gsmp-05.txt > Date: Thu, 20 Apr 2000 06:43:11 -0400 > Sender: nsyracus@cnri.reston.va.us > > --NextPart > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the General Switch Management Protocol Working Group of the IETF. > > Title : General Switch Management Protocol V3 > Author(s) : A. Doria, F. Hellstrand, K. Sundell, T. Worster > Filename : draft-ietf-gsmp-05.txt > Pages : 150 > Date : 19-Apr-00 > > This memo provides the fourth draft of the standards track > specification of GSMP. It is a revision of draft-worster-gsmp-00 > which itself was based on GSMP V2 [7]. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-gsmp-05.txt > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-gsmp-05.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-gsmp-05.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > --NextPart > Content-Type: Multipart/Alternative; Boundary="OtherAccess" > > --OtherAccess > Content-Type: Message/External-body; > access-type="mail-server"; > server="mailserv@ietf.org" > > Content-Type: text/plain > Content-ID: <20000419115816.I-D@ietf.org> > > ENCODING mime > FILE /internet-drafts/draft-ietf-gsmp-05.txt > > --OtherAccess > Content-Type: Message/External-body; > name="draft-ietf-gsmp-05.txt"; > site="ftp.ietf.org"; > access-type="anon-ftp"; > directory="internet-drafts" > > Content-Type: text/plain > Content-ID: <20000419115816.I-D@ietf.org> > > --OtherAccess-- > > --NextPart-- > >