From exim@www1.ietf.org Thu Oct 2 02:58:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05186 for ; Thu, 2 Oct 2003 02:58:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4xPZ-0002S6-PU for gsmp-archive@odin.ietf.org; Thu, 02 Oct 2003 02:58:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h926w5Eh009426 for gsmp-archive@odin.ietf.org; Thu, 2 Oct 2003 02:58:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4xPZ-0002Rx-GH for gsmp-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 02:58:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05176 for ; Thu, 2 Oct 2003 02:57:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4xPV-0003ml-00 for gsmp-web-archive@ietf.org; Thu, 02 Oct 2003 02:58:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4xPV-0003mh-00 for gsmp-web-archive@ietf.org; Thu, 02 Oct 2003 02:58:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4xPU-0002RX-JZ; Thu, 02 Oct 2003 02:58:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4xP1-0002Ox-A5 for gsmp@optimus.ietf.org; Thu, 02 Oct 2003 02:57:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05155 for ; Thu, 2 Oct 2003 02:57:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4xOx-0003mL-00 for gsmp@ietf.org; Thu, 02 Oct 2003 02:57:27 -0400 Received: from cubinlab.ee.mu.oz.au ([128.250.80.33] helo=fw.cubinlab.ee.mu.oz.au) by ietf-mx with esmtp (Exim 4.12) id 1A4xOw-0003mB-00 for gsmp@ietf.org; Thu, 02 Oct 2003 02:57:26 -0400 Received: from passjay (vpn-6.cubinlab.ee.mu.oz.au [10.0.2.6]) by fw.cubinlab.ee.mu.oz.au (8.12.3/8.12.3) with ESMTP id h926wFbA052966; Thu, 2 Oct 2003 16:58:16 +1000 (EST) (envelope-from passjay@icu.ac.kr) From: "passjay" To: "'Avri Doria'" , Subject: RE: [GSMP] update of base draft Date: Thu, 2 Oct 2003 15:56:34 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <9F749D66-EF6A-11D7-81AB-000393CC2112@acm.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: gsmp-admin@ietf.org Errors-To: gsmp-admin@ietf.org X-BeenThere: gsmp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: General Switch Management Protocol WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit There are some typing errors in base draft(03). - page 23, line 1; 0x1 --> 0x2 - page 83, line 24; && --> && AND more, In "draft-ietf-gsmp-reqs-06.txt" referred switch configuration in section 2.3. for layer switching identification. But the base spec(03) does not specify this function. In optical spec section 8.1 we proposed one way of identification of optical switch spec block. However, this block should be carefully taken into consideration in base spec to support general form of switch configuration. According to the requirements, base spec should provide a guideline to extend and modify switch configuration for general purpose. -----Original Message----- From: gsmp-admin@ietf.org [mailto:gsmp-admin@ietf.org] On Behalf Of Avri Doria Sent: Friday, September 26, 2003 12:11 AM To: gsmp@ietf.org Subject: [GSMP] update of base draft Hi, I just submitted an update of the base spec. It should show up fairly soon. While I have still not met all of the requirements in the requirements spec, I have made many of the required structural changes. Now we need to discuss these changes, see if they work for the technology specific needs, and reach group consensus. A list of changes is: 16.4 Changes since draft-ietf-gsmpv3-base-02 1. Modified transacton identifier to indicate whether it originates in the controller or the swtich. 2. Per 3.1.1 of the requirements spec deprecated the More result flag 3. Per 2.9 of the requirements steps removed restriction against use of the Replace bit with the Multicast of bi-drectional bit. Altered the requirement for Diagnostic message 37 from a MUST to a MAY. This will allow backward compatibility with swtiches that do not support simultaneous use of the R flag with either the M or B flag. 4. Per 2.7.2 of the requirements spec added Bulk Transaction meesage 13. 5. Per 2.8 of the requirements doc added reservation semantics to the connection messages, the port management message. Added a recovery alarm message. I don't think this is finished yet, but wanted to get opinions and wanted to give editors of the technology specifc docs a chance to beging to work with the new structures. One thing that has not been added yet are error messages. Also a recovery status function probably needs to be added. But there were so many changes already at this point I did not want to hold up issueing the draft while working on those issues. 6. Added reservation set message 7. Further defined delete reservation behavior to discuss deletion of sets 8. Modified port management message to use extended technology specific functions Things I have not yet done include: - Add text to explain some of the additions in details. - Add the clarifications requested by the requirements spec. - Add new diagnostics messages for the new functionality - Dealt with recovery status and statistics I am looking for comments and discussion. I am also hoping that the editors of the technology specific docs will review the structure and come out with updates (or first draft in the case of TDM) that use this structure. I plan to get another update out by the deadline for IETF58. a. _______________________________________________ GSMP mailing list GSMP@ietf.org https://www1.ietf.org/mailman/listinfo/gsmp _______________________________________________ GSMP mailing list GSMP@ietf.org https://www1.ietf.org/mailman/listinfo/gsmp From exim@www1.ietf.org Thu Oct 2 03:41:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06313 for ; Thu, 2 Oct 2003 03:41:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4y5F-0004nM-Mn for gsmp-archive@odin.ietf.org; Thu, 02 Oct 2003 03:41:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h927f9Mr018426 for gsmp-archive@odin.ietf.org; Thu, 2 Oct 2003 03:41:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4y5E-0004n7-Rj for gsmp-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 03:41:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06298 for ; Thu, 2 Oct 2003 03:41:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4y5C-0004BY-00 for gsmp-web-archive@ietf.org; Thu, 02 Oct 2003 03:41:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4y5B-0004BV-00 for gsmp-web-archive@ietf.org; Thu, 02 Oct 2003 03:41:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4y5A-0004lr-0t; Thu, 02 Oct 2003 03:41:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4y52-0004lR-O3 for gsmp@optimus.ietf.org; Thu, 02 Oct 2003 03:40:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06292 for ; Thu, 2 Oct 2003 03:40:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4y50-0004BL-00 for gsmp@ietf.org; Thu, 02 Oct 2003 03:40:54 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1A4y4z-0004BI-00 for gsmp@ietf.org; Thu, 02 Oct 2003 03:40:53 -0400 Received: from [147.28.0.62] (helo=acm.org) by psg.com with esmtp (Exim 4.22) id 1A4y4z-000FbI-ML for gsmp@ietf.org; Thu, 02 Oct 2003 07:40:53 +0000 Date: Thu, 2 Oct 2003 16:40:16 +0900 Subject: Re: [GSMP] update of base draft Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Avri Doria To: gsmp@ietf.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: gsmp-admin@ietf.org Errors-To: gsmp-admin@ietf.org X-BeenThere: gsmp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: General Switch Management Protocol WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, thanks for your comments. On torsdag, okt 2, 2003, at 15:56 Asia/Seoul, passjay wrote: > There are some typing errors in base draft(03). > > - page 23, line 1; 0x1 --> 0x2 > - page 83, line 24; && --> && thanks > > AND more, > In "draft-ietf-gsmp-reqs-06.txt" referred switch configuration in > section 2.3. for layer switching identification. But the base spec(03) > does not specify this function. In optical spec section 8.1 we proposed > one way of identification of optical switch spec block. However, this > block should be carefully taken into consideration in base spec to > support general form of switch configuration. According to the > requirements, base spec should provide a guideline to extend and modify > switch configuration for general purpose. Yes, I missed that. I will look into adding either the technology specific block or a specific, but general purpose, layering field/block to the configuration message. This will show up in the next draft though i will send the list a proposal next week. Which reminds me that I am still waiting for a contribution (perhaps part of the TDM spec) that discusses layering in detail and proposes methods for handling it beyond this configuration message. a. _______________________________________________ GSMP mailing list GSMP@ietf.org https://www1.ietf.org/mailman/listinfo/gsmp From exim@www1.ietf.org Mon Oct 6 08:28:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27362 for ; Mon, 6 Oct 2003 08:28:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6UT6-0003NA-TL for gsmp-archive@odin.ietf.org; Mon, 06 Oct 2003 08:28:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h96CS4rJ012963 for gsmp-archive@odin.ietf.org; Mon, 6 Oct 2003 08:28:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6UT6-0003N0-QA for gsmp-web-archive@optimus.ietf.org; Mon, 06 Oct 2003 08:28:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27339 for ; Mon, 6 Oct 2003 08:27:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6UT5-0004Yd-00 for gsmp-web-archive@ietf.org; Mon, 06 Oct 2003 08:28:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A6UT5-0004YZ-00 for gsmp-web-archive@ietf.org; Mon, 06 Oct 2003 08:28:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6UT3-0003MX-Qm; Mon, 06 Oct 2003 08:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6USy-0003MA-AO for gsmp@optimus.ietf.org; Mon, 06 Oct 2003 08:27:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27327 for ; Mon, 6 Oct 2003 08:27:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6USx-0004Xl-00 for gsmp@ietf.org; Mon, 06 Oct 2003 08:27:55 -0400 Received: from cubinlab.ee.mu.oz.au ([128.250.80.33] helo=fw.cubinlab.ee.mu.oz.au) by ietf-mx with esmtp (Exim 4.12) id 1A6USv-0004XM-00 for gsmp@ietf.org; Mon, 06 Oct 2003 08:27:54 -0400 Received: from passjay (vpn-39.cubinlab.ee.mu.oz.au [10.0.2.39]) by fw.cubinlab.ee.mu.oz.au (8.12.3/8.12.3) with ESMTP id h96CT9bA002332 for ; Mon, 6 Oct 2003 22:29:10 +1000 (EST) (envelope-from passjay@icu.ac.kr) From: "passjay" To: Subject: [GSMP] optical service model.. Date: Mon, 6 Oct 2003 21:27:12 +0900 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01C38C50.9B843130" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: gsmp-admin@ietf.org Errors-To: gsmp-admin@ietf.org X-BeenThere: gsmp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: General Switch Management Protocol WG List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C38C50.9B843130 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear all.. In gsmp document, chapter 10, service model for each technology is said to be based on documents in standardization organization, such as itu-t, ietf, atm forum. If anyone who knows good references for optical service model, please tell me them. Jay. ------------------------------------------------------------------------ ----------- JungYul Choi ( passjay@icu.ac.kr, Ph.D student) Optical Internet Lab ( http://oil.icu.ac.kr) Information and Communications University (ICU) 58-4 Hwaam-dong, Yusong-gu, Daejon, 305-732, KOREA Tel)+82-42-866-6208, 011-9099-7773 Fax)+82-42-866-6230 ------------------------------------------------------------------------ - ------=_NextPart_000_000C_01C38C50.9B843130 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all..

 

In gsmp = document, chapter 10, service model for each technology is said to be based on = documents in standardization organization, such as itu-t, ietf, atm forum. =

If anyone who = knows good references for optical service model, please tell me = them.

 

 

Jay.

 

 

------------------------------------------------= -----------------------------------
JungYul Choi (passjay@icu.ac.kr, Ph.D student)
Optical Internet Lab (http://oil.icu.ac.kr)
Information and = Communications = Uni= versity = (ICU)
58-4 Hwaam-dong, Yusong-gu, Daejon, 305-732, = KOREA
Tel)+82-42-866-6208, 011-9099-7773 Fax)+82-42-866-6230
-------------------------------------------------------------------------=

 

------=_NextPart_000_000C_01C38C50.9B843130-- _______________________________________________ GSMP mailing list GSMP@ietf.org https://www1.ietf.org/mailman/listinfo/gsmp From exim@www1.ietf.org Wed Oct 8 03:05:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04405 for ; Wed, 8 Oct 2003 03:05:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A78Ne-0002tR-4w for gsmp-archive@odin.ietf.org; Wed, 08 Oct 2003 03:05:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98756EH011122 for gsmp-archive@odin.ietf.org; Wed, 8 Oct 2003 03:05:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A78Nc-0002tJ-Tg for gsmp-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 03:05:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04398 for ; Wed, 8 Oct 2003 03:04:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A78NY-0001Nq-00 for gsmp-web-archive@ietf.org; Wed, 08 Oct 2003 03:05:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A78NY-0001Nm-00 for gsmp-web-archive@ietf.org; Wed, 08 Oct 2003 03:05:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A78NZ-0002su-9Z; Wed, 08 Oct 2003 03:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6wIp-0007Je-Hn for gsmp@optimus.ietf.org; Tue, 07 Oct 2003 14:11:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14649; Tue, 7 Oct 2003 14:11:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6wIm-0001g8-00; Tue, 07 Oct 2003 14:11:16 -0400 Received: from gamma.isi.edu ([128.9.144.145]) by ietf-mx with esmtp (Exim 4.12) id 1A6wIm-0001g5-00; Tue, 07 Oct 2003 14:11:16 -0400 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id h97IBFO07165; Tue, 7 Oct 2003 11:11:15 -0700 (PDT) Message-Id: <200310071811.h97IBFO07165@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, gsmp@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 07 Oct 2003 11:11:15 -0700 Subject: [GSMP] RFC 3604 on Requirements for Adding Optical Support to the General Switch Management Protocol version 3 (GSMPv3) Sender: gsmp-admin@ietf.org Errors-To: gsmp-admin@ietf.org X-BeenThere: gsmp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: General Switch Management Protocol WG List-Post: List-Help: List-Subscribe: , --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3604 Title: Requirements for Adding Optical Support to the General Switch Management Protocol version 3 (GSMPv3) Author(s): H. Khosravi, G. Kullgren, S. Shew, J. Sadler, A. Watanabe Status: Informational Date: October 2003 Mailbox: hormuzd.m.khosravi@intel.com, geku@nortelnetworks.com, sdshew@nortelnetworks.com, Jonathan.Sadler@tellabs.com, atsushi@exa.onlab.ntt.co.jp Pages: 16 Characters: 30805 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-gsmp-reqs-06.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3604.txt This memo provides requirements for adding optical switching support to the General Switch Management Protocol (GSMP). It also contains clarifications and suggested changes to the GSMPv3 specification. This document is a product of the General Switch Management Protocol Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <031007110941.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3604 --OtherAccess Content-Type: Message/External-body; name="rfc3604.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <031007110941.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ GSMP mailing list GSMP@ietf.org https://www1.ietf.org/mailman/listinfo/gsmp From exim@www1.ietf.org Fri Oct 10 22:09:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04496 for ; Fri, 10 Oct 2003 22:09:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A89Bp-0004ui-5u for gsmp-archive@odin.ietf.org; Fri, 10 Oct 2003 22:09:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9B295js018885 for gsmp-archive@odin.ietf.org; Fri, 10 Oct 2003 22:09:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A89Bp-0004uW-0v for gsmp-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 22:09:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04493 for ; Fri, 10 Oct 2003 22:08:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A89Bl-0006Sg-00 for gsmp-web-archive@ietf.org; Fri, 10 Oct 2003 22:09:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A89Bl-0006Sc-00 for gsmp-web-archive@ietf.org; Fri, 10 Oct 2003 22:09:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A89Bk-0004tg-Rx; Fri, 10 Oct 2003 22:09:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A89BX-0004tM-Ci for gsmp@optimus.ietf.org; Fri, 10 Oct 2003 22:08:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04485 for ; Fri, 10 Oct 2003 22:08:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A89BU-0006ST-00 for gsmp@ietf.org; Fri, 10 Oct 2003 22:08:44 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1A89BT-0006SO-00 for gsmp@ietf.org; Fri, 10 Oct 2003 22:08:43 -0400 Received: from [147.28.0.62] (helo=acm.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A89BS-000Oob-W6 for gsmp@ietf.org; Sat, 11 Oct 2003 02:08:43 +0000 Date: Sat, 11 Oct 2003 11:07:54 +0900 Subject: Re: [GSMP] optical service model.. Content-Type: multipart/alternative; boundary=Apple-Mail-12--515954654 Mime-Version: 1.0 (Apple Message framework v552) From: Avri Doria To: gsmp@ietf.org In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.552) Sender: gsmp-admin@ietf.org Errors-To: gsmp-admin@ietf.org X-BeenThere: gsmp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: General Switch Management Protocol WG List-Post: List-Help: List-Subscribe: , --Apple-Mail-12--515954654 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On m=E5ndag, okt 6, 2003, at 21:27 Asia/Seoul, passjay wrote: > Dear all.. > > =A0 > > In gsmp document, chapter 10, service model for each technology is=20 > said to be based on documents in standardization organization, such as=20= > itu-t, ietf, atm forum. the ietf should probably be the first choice. and if there is no other reliable source for the service model, then a=20= basic default one should be defined in the tech specific draft as is=20 done in the packet spec. in fact defining a simple default model is=20 probably a good idea in any case. a. --Apple-Mail-12--515954654 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On m=E5ndag, okt 6, 2003, at 21:27 Asia/Seoul, passjay wrote: Dear all.. =A0 In gsmp document, chapter 10, service model for each technology is said to be based on documents in standardization organization, such as itu-t, ietf, atm forum. the ietf should probably be the first choice. and if there is no other reliable source for the service model, then a basic default one should be defined in the tech specific draft as is done in the packet spec. in fact defining a simple default model is probably a good idea in any case. a. --Apple-Mail-12--515954654-- _______________________________________________ GSMP mailing list GSMP@ietf.org https://www1.ietf.org/mailman/listinfo/gsmp From exim@www1.ietf.org Sun Oct 12 21:22:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05122 for ; Sun, 12 Oct 2003 21:22:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8rPP-00058B-Vc for gsmp-archive@odin.ietf.org; Sun, 12 Oct 2003 21:22:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9D1M3FL019717 for gsmp-archive@odin.ietf.org; Sun, 12 Oct 2003 21:22:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8rPP-00057w-S3 for gsmp-web-archive@optimus.ietf.org; Sun, 12 Oct 2003 21:22:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05111 for ; Sun, 12 Oct 2003 21:21:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8rPN-0004lG-00 for gsmp-web-archive@ietf.org; Sun, 12 Oct 2003 21:22:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A8rPM-0004lC-00 for gsmp-web-archive@ietf.org; Sun, 12 Oct 2003 21:22:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8rPM-00057P-Qd; Sun, 12 Oct 2003 21:22:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8rPE-000571-OT for gsmp@optimus.ietf.org; Sun, 12 Oct 2003 21:21:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05102 for ; Sun, 12 Oct 2003 21:21:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8rPC-0004kv-00 for gsmp@ietf.org; Sun, 12 Oct 2003 21:21:50 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1A8rPB-0004ks-00 for gsmp@ietf.org; Sun, 12 Oct 2003 21:21:49 -0400 Received: from [147.28.0.62] (helo=acm.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A8rPB-000GAr-Rf for gsmp@ietf.org; Mon, 13 Oct 2003 01:21:50 +0000 Date: Mon, 13 Oct 2003 10:20:57 +0900 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Avri Doria To: gsmp@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <7FB8D107-FD1B-11D7-897E-000393CC2112@acm.org> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [GSMP] base spec Sender: gsmp-admin@ietf.org Errors-To: gsmp-admin@ietf.org X-BeenThere: gsmp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: General Switch Management Protocol WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hi, i plan to update the spec and put out a new version by the end of the week. please let me know of any issues , especially those that have not been brought up so far on this list. thanks a. _______________________________________________ GSMP mailing list GSMP@ietf.org https://www1.ietf.org/mailman/listinfo/gsmp From exim@www1.ietf.org Sun Oct 12 21:28:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05254 for ; Sun, 12 Oct 2003 21:28:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8rVC-0005HA-DF for gsmp-archive@odin.ietf.org; Sun, 12 Oct 2003 21:28:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9D1S2we020274 for gsmp-archive@odin.ietf.org; Sun, 12 Oct 2003 21:28:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8rVC-0005Gv-89 for gsmp-web-archive@optimus.ietf.org; Sun, 12 Oct 2003 21:28:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05251 for ; Sun, 12 Oct 2003 21:27:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8rV9-0004oh-00 for gsmp-web-archive@ietf.org; Sun, 12 Oct 2003 21:27:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A8rV9-0004oe-00 for gsmp-web-archive@ietf.org; Sun, 12 Oct 2003 21:27:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8rVB-0005GR-3e; Sun, 12 Oct 2003 21:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8rUb-0005FJ-QK for gsmp@optimus.ietf.org; Sun, 12 Oct 2003 21:27:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05227 for ; Sun, 12 Oct 2003 21:27:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8rUY-0004nq-00 for gsmp@ietf.org; Sun, 12 Oct 2003 21:27:22 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1A8rUY-0004nn-00 for gsmp@ietf.org; Sun, 12 Oct 2003 21:27:22 -0400 Received: from [147.28.0.62] (helo=acm.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A8rUY-000GiH-NT for gsmp@ietf.org; Mon, 13 Oct 2003 01:27:22 +0000 Date: Mon, 13 Oct 2003 10:26:30 +0900 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Avri Doria To: gsmp@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <461B933C-FD1C-11D7-897E-000393CC2112@acm.org> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [GSMP] Reminder Sender: gsmp-admin@ietf.org Errors-To: gsmp-admin@ietf.org X-BeenThere: gsmp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: General Switch Management Protocol WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Today is the deadline for WG chairs to submit the names of new WG drafts; i.e. draft-ietf-gsmp-xxx-00.txt . If you are planning to submit a new draft; i.e. an -00 that you believe is a chartered work item, please let me know today. I have already submitted the name of the TDM spec in the hope that it will show up in time. Also, the deadline for any -00 draft is 20 October at 9.00 ET and the deadline for all drafts is 27 October 9.00 ET . Kenneth and I have not yet requested a meeting slot since we don't know if enough work has been done and enough issue raised to warrant a meeting. If you have agenda items that you think should be discussed in a meeting, please raise them on the list. thanks a. _______________________________________________ GSMP mailing list GSMP@ietf.org https://www1.ietf.org/mailman/listinfo/gsmp From exim@www1.ietf.org Fri Oct 17 20:58:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02130 for ; Fri, 17 Oct 2003 20:58:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAfPv-0004JV-UN for gsmp-archive@odin.ietf.org; Fri, 17 Oct 2003 20:58:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9I0w3Ea016575 for gsmp-archive@odin.ietf.org; Fri, 17 Oct 2003 20:58:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAfPv-0004JG-PC for gsmp-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 20:58:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02108 for ; Fri, 17 Oct 2003 20:57:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAfPt-0003mC-00 for gsmp-web-archive@ietf.org; Fri, 17 Oct 2003 20:58:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAfPs-0003m8-00 for gsmp-web-archive@ietf.org; Fri, 17 Oct 2003 20:58:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAfPt-0004It-92; Fri, 17 Oct 2003 20:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAfPc-0004HQ-C4 for gsmp@optimus.ietf.org; Fri, 17 Oct 2003 20:57:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02091 for ; Fri, 17 Oct 2003 20:57:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAfPV-0003lj-00 for gsmp@ietf.org; Fri, 17 Oct 2003 20:57:37 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AAfPU-0003lf-00 for gsmp@ietf.org; Fri, 17 Oct 2003 20:57:36 -0400 Received: from [147.28.0.62] (helo=acm.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AAfPT-000J2I-8F for gsmp@ietf.org; Sat, 18 Oct 2003 00:57:36 +0000 Date: Sat, 18 Oct 2003 09:57:47 +0900 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=ISO-8859-1; format=flowed From: Avri Doria To: gsmp@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <1700C291-0106-11D8-94DA-000393CC2112@acm.org> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: quoted-printable Subject: [GSMP] IETF58 and other issues Sender: gsmp-admin@ietf.org Errors-To: gsmp-admin@ietf.org X-BeenThere: gsmp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: General Switch Management Protocol WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, While there has been a bit more traffic on the list and the work seems=20= to be moving forward, I am still not sure whether there is enough=20 activity at the moment to warrant a WG meeting in Minneapolis. I would like to hear, on the list, from anyone who has an issue that=20 they feel should be discussed at the meeting. I would also like to=20 hear from anyone who is submitting a draft and feels the need to=20 discuss it in the face to face forum. I will be submitting an update to the base draft later today or=20 tomorrow that includes fixes to the issues that Jay brought up in his=20 message. Basically I fixed the typos and added the extension block to=20= the configuration message. I also made some changes to the capability=20= set block. QAs the addition of the general extension block there did=20 not seem to work as well as it should i made the extension more=20 specific to the capability set functionality. I don't expect anyone=20 had tried to use it yet since they would have screamed, figuratively,=20 at me if they had. As usual, i will be looking for comments and issues=20= once it comes out. Finally, Kenneth and I are working on a rework of our schedule. We=20 have, obviously missed our remaining milestones by a long way. One of=20= the ideas we have had is to break the major milestone: > Dec 02 > =A0=A0 > Submit GSMPv3 extensions to include control of switches supporting=20 > optical, TDM and other CCAMP features and any updates of the base=20 > spec for Proposed Standard Into 3 milestones: - submit rewritten base and packet specification to the IESG for PS=20 consideration - submit optical spec to the IESG for PS consideration - submit tdm spec to the IESG for PS consideration the reason for subdividing them are: -the work of dividing up the spec as we have done was not planned when=20= the milestone where first written, it was the result of looking at the=20= effect of adding all of the TDM and Optical content to RFC 3292 and=20 realizing that it would be too cumbersome and insufficiently versatile.=20= It has also taken more effort then was originally thought as the=20 packet and base were so intimately intertwined in the original. -the base and packet specs together essentially reproduce the=20 functionality of current RFC 3292 and are, in my estimation, the=20 closest to being done. With a little bit of focus, they could be ready=20= for WG last call before IETF59. Additionally the current MIB,=20 RFC3295, covers this functionality and should need little or no=20 revision. -the optical spec and the tdm spec are individual documents and each=20 requires a supporting MIB. While the optical spec is in progress,=20 neither the TDM spec nor the MIBS are as of yet. So reasonable=20 schedules for these need to be worked out. Opinions? discussion? thanks a.= _______________________________________________ GSMP mailing list GSMP@ietf.org https://www1.ietf.org/mailman/listinfo/gsmp From exim@www1.ietf.org Mon Oct 20 03:51:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16516 for ; Mon, 20 Oct 2003 03:51:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABUon-0008Gv-QZ for gsmp-archive@odin.ietf.org; Mon, 20 Oct 2003 03:51:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9K7p9gf031793 for gsmp-archive@odin.ietf.org; Mon, 20 Oct 2003 03:51:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABUon-0008Gi-Jp for gsmp-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 03:51:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16498 for ; Mon, 20 Oct 2003 03:50:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABUoj-0005L3-00 for gsmp-web-archive@ietf.org; Mon, 20 Oct 2003 03:51:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABUoj-0005Kz-00 for gsmp-web-archive@ietf.org; Mon, 20 Oct 2003 03:51:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABUof-0008El-AD; Mon, 20 Oct 2003 03:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABCX7-0005dk-5O for gsmp@optimus.ietf.org; Sun, 19 Oct 2003 08:19:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06454 for ; Sun, 19 Oct 2003 08:19:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABCX5-0004so-00 for gsmp@ietf.org; Sun, 19 Oct 2003 08:19:39 -0400 Received: from cubinlab.ee.mu.oz.au ([128.250.80.33] helo=fw.cubinlab.ee.mu.oz.au) by ietf-mx with esmtp (Exim 4.12) id 1ABCX2-0004sl-00 for gsmp@ietf.org; Sun, 19 Oct 2003 08:19:37 -0400 Received: from passjay (vpn-11.cubinlab.ee.mu.oz.au [10.0.2.11]) by fw.cubinlab.ee.mu.oz.au (8.12.3/8.12.3) with ESMTP id h9JCLibA047365 for ; Sun, 19 Oct 2003 22:21:45 +1000 (EST) (envelope-from passjay@icu.ac.kr) From: "passjay" To: Subject: [gsmp] the initial version of GSMPv3 for optical support (03 version) Date: Sun, 19 Oct 2003 21:18:51 +0900 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0005_01C39686.9A1CD230" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: gsmp-admin@ietf.org Errors-To: gsmp-admin@ietf.org X-BeenThere: gsmp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: General Switch Management Protocol WG List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C39686.9A1CD230 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0006_01C39686.9A25F9F0" ------=_NextPart_001_0006_01C39686.9A25F9F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear all. I have just finished the initial version of GSMPv3 for optical support (03 version). In this version of document, we modify optical specific sections(tech spec TLV) based on the base spec (03). Would you examine this document and give your opinion on it before this Wednesday (22) ? I will submit it after reflecting wg opinions before the submission deadline. Regards. JungYul Choi. ------------------------------------------------------------------------ ----------- JungYul Choi ( passjay@icu.ac.kr, Ph.D student) Optical Internet Lab ( http://oil.icu.ac.kr) Information and Communications University (ICU) 58-4 Hwaam-dong, Yusong-gu, Daejon, 305-732, KOREA Tel)+82-42-866-6208, 011-9099-7773 Fax)+82-42-866-6230 ------------------------------------------------------------------------ - ------=_NextPart_001_0006_01C39686.9A25F9F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all.

 

I have just finished the initial = version of GSMPv3 for optical support (03 version).

In this version of document, we modify = optical specific sections(tech spec TLV) based on the = base spec (03).

Would you examine this document and = give your opinion on it before this Wednesday (22) ?

I will submit it after reflecting = wg opinions before the submission = deadline.

 

Regards.

JungYul Choi.

 

 

------------------------------------------------= -----------------------------------
JungYul Choi (passjay@icu.ac.kr, Ph.D student)
Optical Internet Lab (http://oil.icu.ac.kr)
Information and = Communications = Uni= versity = (ICU)
58-4 Hwaam-dong, Yusong-gu, Daejon, 305-732, = KOREA
Tel)+82-42-866-6208, 011-9099-7773 Fax)+82-42-866-6230
-------------------------------------------------------------------------=

 

------=_NextPart_001_0006_01C39686.9A25F9F0-- ------=_NextPart_000_0005_01C39686.9A1CD230 Content-Type: text/plain; name="draft-ietf-gsmp-optical-spec-03.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-gsmp-optical-spec-03.txt" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable GSMP Working Group Internet Draft Jun Kyun = Choi(ICU) Document: draft-ietf-gsmp-optical-spec-03.txt Jung Yul = Choi(ICU) Expiration Date: April 2004 Min Ho = Kang(ICU) Gyu Myoung = Lee(ICU) Young Wook = Cha(ANU) October = 2003 =20 =20 =20 General Switch Management Protocol (GSMP) v3 for Optical Support=20 =20 =20 Status of this Memo=20 =20 This document is an Internet-Draft and is in full conformance with=20 all provisions of Section 10 of RFC-2026. =20 =20 Internet-Drafts are working documents of the Internet Engineering=20 Task Force (IETF), its areas, and its working groups. Note that = other=20 groups MAY also distribute working documents as Internet-Drafts. =20 =20 Internet-Drafts are draft documents valid for a maximum of six = months=20 and MAY be updated, replaced, or obsolete by other documents at any = time. It is inappropriate to use Internet- Drafts as reference=20 material or to cite them other than as "work in progress." =20 =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt =20 =20 The list of Internet-Draft Shadow Directories can be accessed at=20 http://www.ietf.org/shadow.html.=20 =20 =20 Abstract=20 =20 This document describes the General Switch Management Protocol = version 3=20 (GSMPv3) for the support of optical switching. GSMPv3 controller = SHOULD=20 control optical label switches and manage optical resources on them.=20 This document describes the extended functions of GSMPv3 for optical=20 switching and explains operational mechanisms to implement them. It=20 SHOULD be referred with [1] for the complete implementation. =20 =20 =20 Conventions=20 =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", = "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in = this=20 document are to be interpreted as described in RFC-2119.=20 =20 =20 =20 =20 =20 =20 Choi, et. al. Expires - April 2004 [Page = 1]=20 =0C GSMPv3 for Optical Support October = 2003=20 =20 Table of Contents=20 =20 1. = Introduction.....................................................2=20 2. GSMP Packet = Encapsulation........................................3=20 3. Common Definitions and Procedures for Optical = Support............3=20 3.1 = Labels..........................................................3=20 3.1.1 Labels for = Fiber..............................................5=20 3.1.2 Labels for = Waveband...........................................5=20 3.1.3 Labels for = Wavelength.........................................6=20 3.1.4 Labels for optical = burst......................................6=20 4. Connection Management = Messages...................................7=20 5. Reservation Management = Messages..................................7=20 5.1 Reservation Request Message: Optical Burst = specific.............7=20 6. Management = Message...............................................8=20 6.1 Port Management = Message.........................................8=20 6.2 Label Range = Message.............................................9=20 6.2.1 Optical = Label................................................10=20 7. Statistics Messages: Optical Switching = Specific.................11=20 8. Configuration = Messages..........................................12=20 8.1 Switch Configuration Message: Optical Switching Specific = Block.12=20 8.2 Port Configuration = Message.....................................13=20 8.2.1 PortType Specific Data for Optical = Switching.................13=20 9. Event = Messages..................................................17=20 9.1 Recovery Completion = Message....................................17=20 9.2 Fault Notification = Message.....................................18=20 10. Service Model = Definition.......................................19=20 11. Failure Response = Codes.........................................20=20 12. Security = Considerations........................................20=20 13. Change = Log.....................................................21=20 13.1 Changes since = draft-ieft-gsmp-optical-spec-00.................21=20 13.2 Changes since = draft-ietf-gsmp-optical-spec-01.................21=20 13.2 Changes since = draft-ietf-gsmp-optical-spec-02.................22=20 Appendix I. Protection and Restoration Capability in = GSMPv3........22=20 1.1 1+1 dedicated recovery = mechanism...............................23=20 1.2 1:1 dedicated recovery = mechanism...............................23=20 1.3 1:N/M:N shared recovery mechanism (M, N > 1, M <=3D = N)...........24=20 Appendix II. GSMPv3 support for optical cross-connect = systems......24=20 = References.........................................................25=20 = Acknowledgement....................................................26=20 Author's = Addresses.................................................26=20 Full Copyright = Statement...........................................27=20 =20 =20 =20 1. Introduction=20 =20 =20 =20 Choi, et. al. Expires - April 2004 [Page = 2]=20 =0C GSMPv3 for Optical Support October = 2003=20 =20 This document describes the extended functions and their mechanisms = of the General Switch Management Protocol version 3 (GSMPv3) for = the=20 support of optical switching. GSMPv3 is an asymmetric protocol to=20 control and manage label switch. The label switches that are used = for=20 optical switching are all optical cross-connects (optical-optical- optical), transparent optical cross connects (optical-electrical- optical, frame independent), and opaque optical cross connects=20 (optical-electrical-optical, SONET/SDH frames).These optical cross=20 connect (OXC) systems can be IP-based optical routers which are=20 dynamic wavelength routers, optical label switches, or = burst/packet- based optical cross connects [2]. In this draft, we do not limit=20 specific OXC systems, but aim to provide the general functions of=20 optical switching and services for connections in general optical=20 switches. =20 =20 GSMPv3 is a label switch controller and provides a control = interface=20 to optical switches. The optical resources used in connection setup = are different from those used in legacy networks. In optical=20 switching, basic connection units are a fiber, a wavelength, or a=20 burst and they are assumed to be processed in optical domain = without=20 optical/electrical/optical conversion. This draft defines several=20 sub-TLVs, parameters, and new messages to support optical services=20 and optical connection management. This draft mainly describes=20 optical switching specific technology in order to complement the = base=20 specification of the GSMPv3, including reservation request, port=20 configuration, switch configuration, and event messages.=20 =20 [Note] For the complete implementation this document MUST be = referred=20 with [1]. =20 =20 =20 =20 2. GSMP Packet Encapsulation=20 =20 GSMP Packets may be transported via any suitable medium. GSMP = packet=20 encapsulation for optical support will be defined in separate=20 documents. =20 =20 =20 =20 3. Common Definitions and Procedures for Optical Support.=20 =20 3.1 Labels=20 =20 Labels are the basic identifiers for connections. In order to setup = connections in optical switch, new labels MUST be defined. Newly=20 defined labels identify entities that are to be switched in optical = switches. Generalized Multi-Protocol Label Switching (GMPLS) = defines=20 packet switching capable (PSC), Time-Division Multiplex Capable = (TDM),=20 lambda switching capable (LSC), fiber switching capable (FSC)=20 interfaces, and it introduces needs of generalized labels to = support=20 =20 =20 Choi, et. al. Expires - April 2004 [Page = 3]=20 =0C GSMPv3 for Optical Support October = 2003=20 =20 them [3][4]. The following list is the labels to be supported in=20 GSMPv3 for optical support [2][3][4][7][8][10]. =20 =20 - a single fiber in a bundle=20 - a single waveband within a waveband (or )fiber=20 - a single wavelength within a fiber=20 - an optical burst within a wavelength =20 =20 All labels are encoded in a common structure composed of three = fields,=20 a Type, a Length, and a Value [1]. A label TLV is encoded as a 2- octet field that uses 12 bits to specify a Type and four bits to=20 specify certain behavior specified below, followed by 2-octec = Length=20 field, and followed by a variable length Value field. =20 =20 A summary of TLV labels supported by the GSMPv3 extensions for=20 optical support defined in this document is listed below:=20 =20 TLV Label Label Type=20 -------------------- -----------=20 Fiber Label 0x300=20 Waveband Label 0x301=20 Wavelength Label 0x302 =20 Optical burst Label 0x303 =20 =20 All labels will be designated as follow:=20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 = = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 |x|S|x|x| Label Type | Label Length = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | = |=20 ~ Label Value = ~=20 | = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 =20 X: Reserved Flags=20 These are generally used by specific messages and will be defined = in=20 those messages.=20 =20 S=20 Stacked Label Indicator=20 =20 Label Type =20 A 12-bit field indicating the type of label.=20 =20 Label Length=20 A 16-bit field indicating the length of the Label Value field in=20 bytes.=20 =20 Label value: Variable=20 =20 =20 Choi, et. al. Expires - April 2004 [Page = 4]=20 =0C GSMPv3 for Optical Support October = 2003=20 =20 A variable length field that is an integer number of 32 bit words=20 long. The interpretation of this field depends on the Label Type as = described in the following sections. =20 =20 =20 3.1.1 Labels for Fiber =20 =20 This label indicates a fiber to be used for a connection=20 establishment in optical switching. The label value only has=20 significance between two neighbors, and the receiver MAY need to=20 convert the received value into a value that has local = significance. =20 =20 If the label type =3D labels for fiber, the label MUST be = interpreted=20 as labels for fiber and it has the following format:=20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 = = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Label = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 Label: 32 bits=20 Indicates a label for fiber to be used. =20 =20 =20 3.1.2 Labels for Waveband =20 =20 A waveband is a set of contiguous wavelengths which can be switched = together to a new waveband [3][4]. It MAY be desirable for an = optical=20 cross connect to optically switch multiple wavelengths as a unit=20 since it MAY reduce distortion on individual wavelengths and MAY=20 allow tighter separation of individual wavelengths. Waveband=20 switching introduces another level of label hierarchy and as such = the=20 waveband is treated the same way all other upper layer labels are=20 treated. The waveband label is defined to support such a waveband=20 switching. The waveband label can be encoded in three parts; = waveband=20 ID, start label, and end label. The start label and the end label=20 represent the lowest value of wavelength and the highest value of=20 wavelength. =20 =20 If the label type =3D labels for waveband, the label MUST be=20 interpreted as labels for waveband and it has the following format: = =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 = = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Waveband Id = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Start Label = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | End Label = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 =20 Choi, et. al. Expires - April 2004 [Page = 5]=20 =0C GSMPv3 for Optical Support October = 2003=20 =20 =20 Waveband Id: 32 bits=20 A waveband identifier. The value is selected by a sender and reused = in all subsequent related messages.=20 =20 Start Label: 32 bits=20 Indicates the lowest value of wavelength in the waveband.=20 =20 End Label: 32 bits=20 Indicates the highest value wavelength in the waveband.=20 =20 The start/end label are established either by configuration or by =20 means of a protocol such as LMP [6]. They are normally used in the = =20 label parameter of the Generalized Label one PSC and LSC [3][4].=20 =20 =20 3.1.3 Labels for Wavelength =20 =20 The label indicates a single wavelength to be used for a connection = establishment in optical switching. The label value only has=20 significance between two neighbors, and the receiver MAY need to=20 convert the received value into a value that has local = significance. =20 =20 If the label type =3D labels for wavelength, the label MUST be=20 interpreted as labels for wavelength and a format of the label for=20 wavelength is given as the below:=20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 = = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Label = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 Label: 32 bits=20 Indicates label for wavelength to be used. =20 =20 =20 3.1.4 Labels for optical burst=20 =20 The label for optical burst represents a label for switching data=20 burst in optical domain. =20 =20 Optical data burst switching, which utilizes finer granularity in=20 time domain in a coarse granularity such as a wavelength, is a new=20 connection entity in optical domain [7][8]. Connection setup for=20 optical burst includes reserving time on the transport medium for = the=20 client. =20 =20 This time is characterized by two parameters: start time and = duration=20 of data burst. These values define a fast one-way reservation. Upon = a=20 request for a connection setup for data burst, the GSMP controller=20 MUST perform appropriate Connection Admission Control for the start = =20 =20 Choi, et. al. Expires - April 2004 [Page = 6]=20 =0C GSMPv3 for Optical Support October = 2003=20 =20 time and duration of data burst specified. If the connection is=20 allowed, it MUST signal these parameters to the burst switching=20 device to reserve the exact bandwidth required [7][8]. The burst=20 switch MUST perform switching operation autonomously, using=20 synchronization methods prescribed for the burst network it is=20 operating in. =20 =20 If the label type =3D labels for optical burst, the label MUST be=20 interpreted as labels for burst switching and a format of the label = for optical burst is given as the below:=20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 = = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Label = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 Label: 32 bits=20 Indicates label for a burst level connection. =20 =20 =20 =20 4. Connection Management Messages=20 =20 Connection management messages, which are used to establish, = release,=20 modify, and verify connections across the switch by the controller, = SHOULD operate for optical switching. Connection entities are data=20 burst, wavelength, waveband, fiber in optical switching. Each = entity=20 can be identified by labels for them. In order to support data = burst=20 which provides finer granularity than other connections, Triggered=20 Add message can be used with Reservation Request message. The = general=20 message definition and semantics and other connection management=20 messages follow the base specification of the GSMPv3 [1]. =20 =20 =20 =20 5. Reservation Management Messages=20 =20 The GSMPv3 allows a switch to reserve resources for connections=20 before establishing them through Reservation Management messages.=20 Reservable resources are bandwidth, buffers, queues, labels and = etc.=20 In this draft the resources imply optical resources, such as data=20 burst, wavelengths, fibers, and so on. =20 =20 =20 5.1 Reservation Request Message: Optical Burst specific =20 =20 Reservation Request message supports a new connection per data = burst=20 in optical domain. Data burst is very short in huge bandwidth of a=20 wavelength and needs to process just in time. However, it takes = much=20 time to reserve resource and setup a connection per data burst by=20 using the Reservation Request message. Therefore, a short form of=20 =20 =20 Choi, et. al. Expires - April 2004 [Page = 7]=20 =0C GSMPv3 for Optical Support October = 2003=20 =20 Reservation Request message is used to support data burst. The=20 original Reservation Request message tries to reserve resource for=20 data burst and the short form of the message is used to trigger the = resource to switch and transmit the data burst. This message only=20 contains information to identify the reservation as well as the=20 original message. In order to configure a connection per burst, two = parameters, offset time and burst length, are added on the message. = When a controller receives a request for a connection setup for = data=20 burst it sends the message. According to the different switching=20 mechanisms for optical burst [7][8], the value of two fields in the = message are assigned. That is, by applying them, connection setup = and=20 release are performed explicitly or implicitly. This draft does not = limit the usage of the block in a specific switching technology. =20 The following message is the short form of Reservation Request=20 message to support data burst.=20 =20 Message type =3D TBA=20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 = = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Vers | Sub | Message Type | Result| Code = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Partition ID | Transaction Identifier = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 |I| SubMessage Number | Length = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 |X| Reservation ID = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Offset Time (T) = | =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 | Burst Length (L) = | =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 =20 NOTE: Fields and parameters that have not been explained = follow=20 [1].=20 =20 Offset Time (T)=20 This field is the time between a connection request reception and = the=20 start of the connection for the data burst. =20 =20 Burst Length (L) =20 This field is the time duration of data burst=20 =20 =20 =20 6. Management Message=20 =20 6.1 Port Management Message=20 =20 The Port Management message allows a port to be brought into = service,=20 to be taken out of service, to be set to loop back, reset, or to=20 =20 =20 Choi, et. al. Expires - April 2004 [Page = 8]=20 =0C GSMPv3 for Optical Support October = 2003=20 =20 change the transmit data rate. The port Management message for=20 optical switching has the following format for the request and=20 success response messages: =20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Vers | Sub | Message Type | Result| Code = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Partition ID | Transaction Identifier = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 |I| SubMessage Number | Length = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Port = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Port Session Number = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Event Sequence Number = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 |R|x|x|x|x|x|x|x| Duration | Function | X-Function = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Event Flags | Flow Control Flags = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 |x|x|x|x|x|x|x|x| Message Type | Tech Type | Block Length = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Transmit Data Rate = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 Note: Fields and Parameters that have not been explained follow = [1]=20 =20 Message Type: =20 Port Management message for optical switching=20 =20 Tech Type; 0x30 =20 optical switching=20 =20 Block Length; =20 It indicates the length of extension values (lists of failed port = and=20 failed label) of Port Management messages for optical switching. =20 =20 Transmit Data Rate=20 This field is only used in request and success response messages = with=20 the Function field set to "Set Transmit Data Rate". It is used to = set=20 the output data rate of the output port. =20 =20 =20 6.2 Label Range Message=20 =20 The label range, which is specified for each port by the Port=20 Configuration or the All Ports Configuration message, can be=20 specified to the range of label supported by a specified port and = to=20 =20 =20 Choi, et. al. Expires - April 2004 [Page = 9]=20 =0C GSMPv3 for Optical Support October = 2003=20 =20 be changed by using Label Range message. Since the granularity of=20 each connection is different in optical domain each port SHOULD = allow=20 the label range changeable in ports. In addition, a port MAY have=20 wavelength converters with full or limited capability so that each=20 port MAY have different limited labels. In case of waveband = switching,=20 a single label for waveband connection is used for a set of=20 wavelengths in the band. To support these cases, the Label Range=20 message is used. =20 =20 The general usage and the format of this message follow [1].=20 =20 =20 6.2.1 Optical Label=20 =20 If the Label Type is equal to optical label, the label range = message=20 MUST be interpreted as shown:=20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 = = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 |x|x|V|C| Optical Label | Label Length = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Min Label = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Max Label = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Remaining Labels = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 V: Label=20 The Label flag is not used. =20 =20 C: Multipoint Capable=20 Indicates label range that can be used for multipoint connections.=20 This field is not used in this document.=20 =20 Optical Label=20 The optical label indicates the type of label for optical support = and=20 is referred to the section 3.1 of this document.=20 =20 Min Label: =20 The minimum label value in the range.=20 =20 Max Label: =20 The maximum label value in the range.=20 =20 Remaining Labels: =20 The maximum number of remaining labels that could be requested for=20 allocation on the specified port.=20 =20 =20 =20 =20 =20 Choi, et. al. Expires - April 2004 [Page = 10]=20 =0C GSMPv3 for Optical Support October = 2003=20 =20 7. Statistics Messages: Optical Switching Specific=20 =20 The statistics messages are used to query the performance = statistics=20 related to ports and connections for optical transmission. The=20 statistics contain optical transmission characteristics which = specify=20 transmission quality of connections. Transmission performance is=20 typically defined in terms of signal performance with reference to=20 noise level, or by the signal-to-noise ratio (SNR), and spectral=20 occupancy requirement or signal power level [14]. The success=20 response for the Statistics message for optical switching has the=20 following form with optical switching specific TLV. This field=20 implies quality of transmission signal in a connection so that it=20 informs a controller signal degradation or loss of signal. This=20 information MAY result in an alarm of link failure.=20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 = = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Vers | Sub | Message Type | Result| Code = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Partition ID | Transaction Identifier = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 |I| SubMessage Number | Length = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Port = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 |x|S|x|x| = |=20 +-+-+-+-+ Label = |=20 ~ = ~=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 |x|x|x|x|x|x|x|x| Message Type | Tech Type | Block Length = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Signal to Noise Ratio = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Bit Error Rate = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Extinction Ratio = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Input Signal Power Level = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Output Signal Power Level = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 NOTE: Fields and parameters that have not been explained = follow=20 [1].=20 =20 Message Type; TBA =20 Statistics message for optical switching=20 =20 Tech Type; 0x30 =20 optical switching=20 =20 =20 =20 Choi, et. al. Expires - April 2004 [Page = 11]=20 =0C GSMPv3 for Optical Support October = 2003=20 =20 Block Length; =20 It indicates the length of extension values (lists of failed port = and=20 failed label) of Statistics message for optical switching.=20 =20 Signal to Noise Ratio (SNR): 32 bit =20 SNR is the ratio of the signal power to the noise power. It is a=20 function of both the amount of noise and the signal power.=20 =20 Bit Error Rate (BER): 32 bit=20 BER is the number of error bits received as a portion of the number = of good bits.=20 =20 Extinction Ratio: 32 bit=20 The Extinction ratio is the ratio of the power level representing a = 1=20 bit to the power level representing a 0 bit. It is quoted in = decibels=20 (dB). =20 =20 Input Signal Power Level: 32bit=20 The value of the average received power. =20 =20 Output Signal Power Level: 32 bit=20 The value of the average power of a pseudorandom data sequence=20 coupled into fiber by the transmitter. =20 =20 =20 =20 8. Configuration Messages=20 =20 The configuration messages allow a controller to discover =20 capabilities of optical switch. Switch configuration, port=20 configuration, and service configuration messages are defined for=20 these functions. =20 =20 =20 8.1 Switch Configuration Message: Optical Switching Specific Block=20 =20 Since optical switches MAY be able to provide connection services = at=20 multiple transport layers, and all switches are not expected to=20 support the same transport layers, the switch will need to notify = the=20 controller of the specific layers it can support. Therefore, the=20 switch configuration message MUST be extended to provide a list of=20 the transport layers for which an optical switch can perform=20 switching. For supporting various types of switching capable=20 interfaces, the following optical switch configuration blocks = SHOULD=20 be added in the Switch Configuration message. =20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 = = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | SW capable | Reserved = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 =20 =20 Choi, et. al. Expires - April 2004 [Page = 12]=20 =0C GSMPv3 for Optical Support October = 2003=20 =20 Switching Capable Layer : 8 bits=20 This field indicates the supported switching capable layers in an=20 optical switch. It has three flags which indicate the layers. The=20 flags can be set at the same time when the optical switch contains=20 multiple transport layers. =20 =20 X X X X X X F B L=20 -------------------=20 =20 X: reserved field=20 F: indicates the switching capable layer per a fiber=20 B: indicates the switching capable layer per a waveband=20 L: indicates the switching capable layer per a wavelength=20 =20 =20 8.2 Port Configuration Message=20 =20 The port configuration message informs a controller configuration=20 information related to a single port. Ports in optical switches are = connected to fibers or wavelength which is multiplexed in a fiber. = In=20 order to identity port in optical switches, the following new port=20 types are defined. The basic format and usage of Port Configuration = message follow [1]. =20 =20 Value PortType=20 ------ ---------=20 10 optical switching=20 =20 8.2.1 PortType Specific Data for Optical Switching=20 =20 If PortType is equal to Optical Switching, the following PortType=20 Specific Data block is used to identify ports of optical switches.=20 The format and usage of Port Specific Data for Optical Switching in = Port Configuration message is given as following. =20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 = = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 |X|M|L|R|Q| Label Range Count | Label Range Length = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | = |=20 ~ Default Label Range Block = ~=20 | = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Input Channel Data Rate = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Output Channel Data Rate = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Port Status | Line Type | Line Status | Priorities = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Physical Slot Number | Physical Port Number = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 =20 Choi, et. al. Expires - April 2004 [Page = 13]=20 =0C GSMPv3 for Optical Support October = 2003=20 =20 =20 Note: Fields and Parameters that have not been explained in = the=20 Subsection follow [1].=20 =20 Where each of the ranges in the Default Label Range Blocks will = have=20 the following format:=20 =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 |x|x|V|C| = |=20 +-+-+-+-+ Min Label = |=20 ~ = ~=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 |x|x|x|x| = |=20 +-+-+-+-+ Max Label = |=20 ~ = ~=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 Flags=20 =20 M: Multicast Labels=20 The Multicast Labels flag, if set, indicates that this output=20 port is capable of labelling each output branch of a point-to- multipoint tree with a different label. If zero, it indicates=20 that this output port is not able to label each output branch = of=20 a point-to-multipoint tree with a different label.=20 =20 L: Logical Multicast=20 The Logical Multicast flag, if set, indicates that this output = port is capable of supporting more than a single branch from = any=20 point-to-multipoint connection. This capability is often=20 referred to as logical multicast. If zero, it indicates that=20 this output port can only support a single output branch from=20 each point-to-multipoint connection.=20 =20 R: Label Range=20 The Label Range flag, if set, indicates that this switch port = is=20 capable of reallocating its label range and therefore accepts=20 the Label Range message. Else, if zero, it indicates that = this=20 port does not accept Label Range messages.=20 =20 Q: QoS=20 The QoS flag, if set, indicates that this switch port is = capable=20 of handling the Quality of Service messages defined in section = 9=20 of this specification. Else, if zero, it indicates that this=20 port does not accept the Quality of Service messages.=20 =20 V: Label=20 The Label flag is port type specific.=20 =20 C: Multipoint Capable=20 This flag indicates that the label range may be used for=20 multipoint connections.=20 =20 =20 Choi, et. al. Expires - April 2004 [Page = 14]=20 =0C GSMPv3 for Optical Support October = 2003=20 =20 =20 Label Range Count=20 The total number of Default Label Range elements contained in the=20 Default Label Range Block.=20 =20 Label Range Length=20 Byte count in the Default Label Range Block.=20 =20 Min Label=20 The specification of the Min Label field for each defined PortType=20 value is given in the subsequent subsections. The default minimum=20 value of a dynamically assigned incoming label that the connection=20 table on the input port supports and that may be controlled by = GSMP. =20 This value is not changed as a result of the Label Range message.=20 =20 Max Label=20 The specification of the Max Label field for each defined PortType=20 value is given in the subsequent subsections. The default maximum=20 value of a dynamically assigned incoming label that the connection=20 table on the input port supports and that may be controlled by = GSMP. =20 This value is not changed as a result of the Label Range message. =20 =20 Input Channel Data Rate=20 The maximum rate of data that may arrive at the input port=20 (interface) in;=20 =20 Bits/sec for PortType =3D Optical Switching=20 =20 Output Channel Data Rate=20 The maximum rate of data that may depart from the output port=20 (interface) in;=20 =20 Bits/sec for PortType =3D Optical Switching=20 =20 Port Status=20 Give the administrative state of the port. The defined values of = the=20 Port Status field are:=20 =20 Available: Port Status =3D 1. =20 The port is available to both send and receive cells or frames. = When a port changes to the Available state from any other=20 administrative state, all dynamically assigned connections MUST = be=20 cleared and a new Port Session Number MUST be generated.=20 =20 Unavailable: Port Status =3D 2. =20 The port has intentionally been taken out of service. No cells = or=20 frames will be transmitted from this port. No cells or frames = will=20 be received by this port.=20 =20 Internal Loopback: Port Status =3D 3. =20 The port has intentionally been taken out of service and is in=20 internal loopback: cells or frames arriving at the output port=20 =20 =20 Choi, et. al. Expires - April 2004 [Page = 15]=20 =0C GSMPv3 for Optical Support October = 2003=20 =20 from the switch fabric are looped through to the input port to=20 return to the switch fabric. All of the functions of the input=20 port above the physical layer, e.g., header translation, are=20 performed upon the looped back cells or frames.=20 =20 External Loopback: Port Status =3D 4. =20 The port has intentionally been taken out of service and is in=20 external loopback: cells or frames arriving at the input port=20 from the external communications link are immediately looped = back=20 to the communications link at the physical layer without = entering=20 the input port. None of the functions of the input port above = the=20 physical layer are performed upon the looped back cells or = frames.=20 =20 Bothway Loopback: Port Status =3D 5. =20 The port has intentionally been taken out of service and is in=20 both internal and external loopback.=20 =20 Recovery: Port Status =3D 6. =20 The port is reserved for recovery support. For 1+1 dedicated=20 protection, this port is configured to transmit traffic as a=20 backup. On the other hand, for 1:1 protection, this port is just = configured to reserve the connection without transmitting = traffic. =20 =20 The Port Status of the port over which the GSMP session controlling = the switch is running MUST be declared Available. The controller = will=20 ignore any other Port status for this port. The Port Status of = switch=20 ports after power-on initialization is not defined by GSMP.=20 =20 Line Type=20 The type of physical transmission interface for this port. The line = type for optical switching depends on switching interface for each=20 switching entity. The value to identify PortType of optical = switching=20 is not defined yet. =20 =20 Physical Slot Number=20 The physical location of the slot in optical switching (or OXC).=20 Since the OXC systems can have many bays which contain hundreds of=20 shelf which have tens of thousands of port this field SHLOULD=20 identify the slot. For doing so, the field MAY be partitioned into=20 several sub-fields to define bay, shelf, and slot.=20 =20 The default label range block for optical switching has the = following=20 format. =20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 = = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 |x|x|x|x| Label Type | Label Length = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | = |=20 ~ Label Value = ~=20 | = |=20 =20 =20 Choi, et. al. Expires - April 2004 [Page = 16]=20 =0C GSMPv3 for Optical Support October = 2003=20 =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 Label Type: 12 bit =20 Label type for optical support. Each encoding type of the labels is = TBD.=20 =20 Label value: Variable =20 Carries label information. The interpretation of this field depends = on the type of the link (or the type of connection) over which the=20 label is used. Min Label and Max label value imply the range of=20 available optical labels. Each encoding type of the labels is TBD.=20 =20 =20 =20 9. Event Messages=20 =20 The Event messages allow a switch to inform a controller of certain = asynchronous events. This draft deals with recovery-related events. = The indication of these asynchronous events related to ports and=20 labels can inform failure of them to the controller and it can=20 initiate a fault recovery mechanism. In the following sub-sections, = two messages, Recovery Completion message and Fault Notification=20 message, are used to notify a controller fault-related events of a=20 switch. =20 =20 =20 9.1 Recovery Completion Message=20 =20 This message is used to notify the recovery completion to the=20 controller by the switch after the failed elements are restored. = This=20 message contains restored connection information. Restored = Connection=20 information implies restored Port IDs and Label IDs. By using this=20 message, the recovery completion of several failed connections, = which=20 consist of port and label, are notified to the controller at one = time. =20 =20 The following extension TLV is for Recovery Completion in Event=20 messages in order to notify the recovery completion of all failed=20 ports and all fault-affected labels to the controller.=20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 = = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 |x|x|x|x|x|x|x|x| Message Type | Tech Type | Block Length = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Restored Port ID 1 = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Restored Label ID 1 = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | . . . = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | . . . = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 =20 Choi, et. al. Expires - April 2004 [Page = 17]=20 =0C GSMPv3 for Optical Support October = 2003=20 =20 | Restored Port ID N = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Restored Label ID N = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 Message Type; TBA =20 Recovery completion message=20 =20 Tech Type; 0x30 =20 optical switch =20 =20 Block Length; =20 It indicates the length of extension values(lists of restored port=20 and restored label) of Recovery Completion messages. =20 =20 Restored Port ID list; variable=20 This field describes the restored port IDs which contain different=20 types of port which indicate wavelength-related port, fiber-related = port, or fiber bundle-related port. =20 =20 Restored Label ID list; variable=20 This field describes the restored label ID which comes to be used=20 again from a fault. =20 =20 =20 9.2 Fault Notification Message=20 =20 This message is used to inform a controller a fault occurring in a=20 switch. The possible faults are link failure from cutting off=20 (affecting wavelengths, fibers, fiber bundles), port failure, or=20 switch modules. For the notification purpose, the following = extension=20 TLV for Fault Notification blocks is added in Event message. It=20 notifies all fault-affected ports and labels in a switch to a=20 controller.=20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 = = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 |x|x|x|x|x|x|x|x| Message Type | Tech Type | Block Length = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Failed Port ID 1 = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Failed Label ID 1 = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | . . . = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | . . . = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Failed Port ID N = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Failed Label ID N = |=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 =20 Choi, et. al. Expires - April 2004 [Page = 18]=20 =0C GSMPv3 for Optical Support October = 2003=20 =20 =20 Message Type; TBA =20 Fault Notification message=20 =20 Tech Type; 0x30 =20 optical switch=20 =20 Block Length; =20 It indicates the length of extension values(lists of failed port = and=20 failed label) of Fault Notification messages. =20 =20 Failed Port ID list; variable=20 This field describes the failed port ID which contains different=20 types of port which indicate wavelength-related port, fiber-related = port, or fiber bundle-related port. =20 =20 Failed Label ID list; variable=20 This field describes the failed label ID which comes to not be used = from a connection failed. =20 =20 =20 =20 10. Service Model Definition=20 =20 In the GSMP Service Model a controller may request the switch to=20 establish a connection with a given Service. The requested Service = is=20 identified by including a Service ID in the Add Branch message or = the=20 Reservation message. The Service ID refers to a Service Definition=20 (defined in chapter 10 of [1]). Service model for optical switch is = not defined yet in the standards or implementation agreements=20 published by organizations. This draft will follow the service = model=20 of standard documents of standardization organizations. =20 =20 The following Service Identifiers are defined for optical support.=20 =20 ID Range Service Type=20 -------- ------------=20 128 - - 191 Optical Switch Services=20 =20 Service Identifier=20 The reference number used to identify the Service in GSMP.=20 =20 Service Characteristics=20 A definition of the Service=20 =20 Traffic Parameters=20 A definition of the Traffic Parameters used in connection = management=20 messages.=20 =20 QoS parameters=20 A definition of the QoS Parameters that are included in the=20 Capability Set for instances of the Service.=20 =20 =20 Choi, et. al. Expires - April 2004 [Page = 19]=20 =0C GSMPv3 for Optical Support October = 2003=20 =20 =20 Traffic Controls=20 A definition of the Traffic Controls that may be supported by an=20 instance of the Service.=20 =20 =20 =20 11. Failure Response Codes=20 =20 This chapter describes the failure and warning states which can = occur=20 in setup optical connections. The following lists are the codes = that=20 SHOULD be defined and added in the Failure Response messages. These = codes MAY be added more when the services for optical switching are = defined. =20 =20 If the switch issues a failure response it MUST choose the most=20 specific failure code according to the following precedence. The = code=20 numbers will be assigned in IANA.=20 =20 Optical Connection Failure=20 =20 - recovery failure=20 Due the limitation of available resource for recovery = connection,=20 for example, multiple links failure, the switch can not be=20 succeeded the recovery procedure for shared protected = connection.=20 =20 - waveband connection setup failure=20 There are not available wavelengths which belong to the range = of=20 min and max limits of the waveband=20 =20 - reservation failure for optical burst=20 In case of delayed reservation in time is not exactly matched,=20 the reservation of optical burst can be failed. =20 =20 The following list gives a summary of the failure codes defined for = failure response messages:=20 =20 - no available label for shortage of available wavelengths=20 =20 - no available resource for recovery =20 =20 - no available resource for waveband connection setup=20 =20 - no match for the delayed reservation for optical burst connection = =20 =20 =20 12. Security Considerations=20 =20 This document does not have any security concerns. The security=20 requirements using this document are described in the referenced=20 documents.=20 =20 =20 Choi, et. al. Expires - April 2004 [Page = 20]=20 =0C GSMPv3 for Optical Support October = 2003=20 =20 =20 =20 =20 13. Change Log=20 =20 13.1 Changes since draft-ieft-gsmp-optical-spec-00=20 =20 - Add label formats for optical switching in section 2.1 Labels.=20 =20 - Delete section 2.2 Protection and Restoration Capability in GSMP. = =20 - Delete section 2.3 GSMP support for optical switching systems.=20 =20 - Add section 4.1 Reservation Request Message for optical burst=20 =20 - Add section 5. Management message including Label Range message=20 for optical label.=20 =20 - Add section 6.2.1 Optical signal statistics Message.=20 =20 - Modify section 7.1 Switch Configuration Message for optical=20 switching=20 =20 - Add section 7.2.1 PortType Specific Data for Optical Switching=20 =20 - Add section 8.1 Recovery Completion Message.=20 =20 - Add section 8.2 Recovery Notification Message.=20 =20 =20 13.2 Changes since draft-ietf-gsmp-optical-spec-01=20 =20 - Assign label number in section 3.1=20 =20 - Delete duplicated section with the base document: 2.1.5, 3.2~3.7, = 4.2, 4.3, 5.1, 6.1, 6.3, 7.3=20 =20 - Add section 2 GSMP packet encapsulation.=20 =20 - Add section 4.1 Add Branch message: Recovery Specific Block=20 =20 - Add section 5.1 Reservation Request message: Recovery Specific=20 Block.=20 =20 - Modify section 5.2 Reservation Request message: Optical Burst=20 Specific.=20 =20 - Modify section 8.2.1 PortType Specific Data over Optical = Switching.=20 =20 - Modify section 9.1 Recovery Completion message.=20 =20 - Modify section 9.2 Recovery Notification message.=20 =20 =20 Choi, et. al. Expires - April 2004 [Page = 21]=20 =0C GSMPv3 for Optical Support October = 2003=20 =20 =20 =20 13.2 Changes since draft-ietf-gsmp-optical-spec-02=20 =20 - Delete section 4.1 Add Branch message: Recovery Specific Block=20 =20 - Delete section 5.1 Reservation Request message: Recovery Specific = Block=20 =20 - Add section 6.1 Port Management message including optical=20 switching specific TLV=20 =20 - Add specific fields to get statistics of optical switches in=20 section 7 Statistics message: Optical Switching Specific.=20 =20 - Modify section 8.2.1 PortType Sepcific Data for optical switching = and add description about the message format.=20 =20 - Modify section 9.1 Recovery Completion message and section 9.2=20 Recovery Notification message.=20 =20 =20 =20 Appendix I. Protection and Restoration Capability in GSMPv3=20 =20 The GSMP controller MUST support the protection and restoration=20 capabilities because the optical switch delivers several Gbps data=20 traffic in a single wavelength. To achieve fast protection and=20 restoration, the optical switch MAY be capable of taking an action=20 independent of the GSMP controller, then it informs the controller=20 after completing the restoration [2]. This differs from the master- slave relationship in GSMP. =20 =20 Recovery mechanisms do not distinguish path (end-to-end) and link=20 recovery in GSMPv3. The difference of them is considered in = signaling=20 protocol. In case of dynamically calculating the recovery = connection=20 after a fault occurs, GSMPv3 establishes a new recovery connection = by=20 using the existing Add Branch message. Therefore, this draft=20 considers pre-planned recovery mechanisms, such as 1+1 dedicated=20 recovery, 1:1 dedicated recovery with/without extra traffic, and=20 1:N/M:N shared recovery. =20 =20 The label switch SHOULD provide the protection and restoration=20 capabilities in order to provide the recovery mechanisms. For = example,=20 an ingress/egress node reserves backup resources according the each = recovery mechanism, and setup the switch fabric. Then, GSMPv3 is = used=20 to control the switch. =20 =20 In this section, the recovery mechanisms which can be provided by=20 GSMPv3 are specified with an included fault notification, and=20 restoration, and related required messages. For example, the port=20 configuration command MUST be extended to allow autonomous = protection=20 =20 =20 Choi, et. al. Expires - April 2004 [Page = 22]=20 =0C GSMPv3 for Optical Support October = 2003=20 =20 mechanism. The current GSMP connection management also MUST be=20 extended to support this function. In the following subsections, = the=20 supported recovery mechanisms in GSMPv3 are introduced.=20 =20 =20 1.1 1+1 dedicated recovery mechanism=20 =20 =20 - Recovery connection configuration=20 All nodes on a working connection use Add Branch message(P) to=20 configure a recovery connection. The ingress node transmits traffic = through the working connection as well as the recovery connection. = An=20 egress only chooses traffic from the working connection with = ignoring=20 them from the recovery connection. In order to support this type of = recovery mechanism, the optical switch SHOULD support it = physically.=20 =20 - Recovery procedure=20 When a failure occurs, a fault-affected working connection is=20 switched over a 1+1 dedicated recovery connection without notifying = the controller. The recovery process is performed at the physical=20 layer automatically. After the recovery is completed, the switch=20 notifies the recovery completion to the controller by using Event=20 message. =20 =20 =20 1.2 1:1 dedicated recovery mechanism=20 =20 1) 1:1 protection =20 =20 - Recovery connection configuration=20 All nodes on a working connection configure a recovery connection = by=20 using Add Branch message. However, the ingress node does not = transmit=20 any traffic through the reserved recovery connection since the = switch=20 does not cross connect for the recovery connection. =20 =20 - Recovery procedure=20 When an ingress node detects a fault it switches over the fault- affected working connection to the reserved recovery connection. = This=20 type of recovery does not require configuring additional connection = configuration because the recovery connection has been already=20 established by using Add Branch message(P). Then, an egress node=20 switches over the recovery connection to receive traffic.=20 =20 =20 2) 1:1 restoration =20 =20 - Recovery connection configuration=20 An ingress node and an egress node both configure a recovery=20 connection by using the Reservation Request message(P), and core=20 nodes also use it to reserve recovery connection. Extra traffic can = be delivered through the recovery connection. =20 =20 =20 =20 Choi, et. al. Expires - April 2004 [Page = 23]=20 =0C GSMPv3 for Optical Support October = 2003=20 =20 - Recovery procedure=20 The ingress node and the egress node use Add Branch message in = order=20 to configure a recovery connection. Other core nodes also configure = the recovery connection with Add Branch message(P) with the = reserved=20 resource. =20 =20 =20 1.3 1:N/M:N shared recovery mechanism (M, N > 1, M <=3D N)=20 =20 - Recovery connection configuration=20 Reservation Request message(P) is used to configure a recovery=20 connection. Since several working connections (=3D N) share one=20 recovery connection (1:N) or several recovery connections (M:N)=20 GSMPv3 SHUOLD know the sharing working connection IDs for the=20 recovery connections. =20 =20 - Recovery procedure=20 When the GSMPv3 controller is notified a fault, it uses Add Branch=20 message(P) to configure a new working connection by using reserved=20 recovery connection. The Add Branch message(P) SHOULD contain the=20 information about the reserved recovery connection.=20 =20 =20 =20 Appendix II. GSMPv3 support for optical cross-connect systems=20 =20 The GSMPv3 controls and manages the optical cross-connect systems = as=20 label switches. The optical cross-connect (OXC) is a space division = switch that can switch an optical data stream on an input port to = an=20 output port. The OXCs are all optical cross-connects (optical- optical-optical), transparent optical cross connects (optical- electrical-optical, frame independent), and opaque optical cross=20 connects (optical-electrical-optical, SONET/SDH frames).These OXC=20 (optical cross connect) systems can be IP-based optical routers = which=20 are dynamic wavelength routers, optical label switches, or=20 burst/packet-based optical cross connects, and so on[2].=20 =20 The OXC system consists of switching fabric, multiplexer/=20 demultiplexer, wavelength converter, and optical-electrical/=20 electrical-optical converter. Multiple wavelengths are multiplexed = or=20 demultiplexed into a fiber. Multiple fibers belong to a fiber = bundle.=20 A wavelength, a waveband, and a fiber can be used to establish a=20 connection in an optical switch. They SHOULD be recognized at a = port=20 in the OXC since they are connection entities. When the OXC has=20 optical-electrical conversion at the input port and electrical- optical conversion at the output port it is called as opaque OXC. = Or,=20 when it processes optical data stream all optically it is called as = transparent OXC. Wavelength converter SHOULD be used to resolve=20 output port contention when two different connections try to be=20 established in a same output port. Since the wavelength converter = can=20 work only within a limited operating range, the limited numbers of=20 =20 =20 Choi, et. al. Expires - April 2004 [Page = 24]=20 =0C GSMPv3 for Optical Support October = 2003=20 =20 wavelengths are used at the output port. It limits the available=20 wavelengths at the output port. =20 =20 If OXCs perform protection and restoration functions they SHOULD = have=20 suitable switch structure to support them. In case of 1+1 dedicated = recovery, input ports and output ports MUST be duplicated in a = switch.=20 The switch transmits optical signal through two ports (one for=20 working connection and another for recovery connection)=20 simultaneously. When a fault happens the switch switches over from=20 failed working connection to dedicated recovery connection without=20 noticing a controller. =20 =20 =20 =20 References=20 =20 [1] Doria, A, "GSMPv3 Base Specification", = draft-ietf-gsmp-base-spec- 02.txt (work in progress), June 2003. =20 =20 [2] Georg Kullgren, et. al., "Requirements For Adding Optical = Support=20 To GSMPv3",draft-ietf-gsmp-reqs-06.txt (work in progress), June = 2003. =20 =20 [3] Mannie, E., et. al., "Generalized Multi-Protocol Label = Switching=20 (GMPLS) Architecture", draft-ietf-ccamp-gmpls-architecture-07.txt=20 (work in progress), May 2003. =20 =20 [4] Ashwood-Smith, D., et. al., "Generalized MPLS - Signaling=20 Functional Description", RFC3471, Jan. 2003.=20 =20 [5] Rajagopalan, B., et. al., "IP over Optical Networks: A = Framework",=20 draft-ietf-ipo-framework-04.txt (work in progress), April 2003.=20 =20 [6] J. Lang, et. at. "Link Management Protocol (LMP) ", draft-ietf- ccamp-lmp-09.txt (work in progress), April 2003. =20 =20 [7] C. Qiao, M. Yoo, "Choice, and Feature and Issues in Optical = Burst =20 Switching", Optical Net. Mag., vol.1, No.2, Apr.2000, pp.36-44.=20 =20 [8] Ilia Baldine, George N. Rouskas, Harry G. Perros, Dan = Stevension,=20 "JumpStart: A Just-in-time Signaling Architecture for WDM Burst- Switching Networks", IEEE Comm. Mag., Feb. 2002.=20 =20 [9] Angela Chiu, John Strans, et. al., "Impairments And Other=20 Constraints On Optical Layer Routing", draft-ietf-ipo-impairments- 05.txt (work in progress), May 2003.=20 =20 [10] Daniel Awduche, WYakov Rekhter, "Multiprotocol Lambda = Switching:=20 Combining MPLS Traffic Engineering Control with Optical=20 Crossconnects", IEEE Comm. Mag., March 2001.=20 =20 [11] Doria, A. and K. Sundell, "General Switch Management Protocol = =20 Applicability", RFC 3294, June 2002.=20 =20 =20 Choi, et. al. Expires - April 2004 [Page = 25]=20 =0C GSMPv3 for Optical Support October = 2003=20 =20 =20 [12] Mannie, E., et. al., "Recovery (Protection and Restoration)=20 Terminology for GMPLS", = draft-ietf-ccamp-gmpls-recovery-terminology- 02.txt (work in progress), May 2003.=20 =20 [13] Vishal Sharma, et. at., "Framework for MPLS-based Recovery", = RFC=20 3469, February 2003=20 =20 [14] ITU-T Recommendation G.959.1, Optical Transport Network = Physical=20 Layer Interfaces, February 2001.=20 =20 =20 =20 Acknowledgement=20 =20 This work was supported in part by the Korean Science and = Engineering=20 Foundation (KOSEF) through OIRC project=20 =20 =20 Author's Addresses=20 =20 Jun Kyun Choi=20 Information and Communications University (ICU)=20 58-4 Hwa Ahm Dong, Yusong, Daejon =20 Korea 305-732=20 Phone: +82-42-866-6122=20 Email: jkchoi@icu.ac.kr=20 =20 Jung Yul Choi=20 Information and Communications University (ICU)=20 58-4 Hwa Ahm Dong, Yusong, Daejon =20 Korea 305-732=20 Phone: +82-42-866-6208=20 Email: passjay@icu.ac.kr=20 =20 Min Ho Kang=20 Information and Communications University (ICU)=20 58-4 Hwa Ahm Dong, Yusong, Daejon =20 Korea 305-732=20 Phone: +82-42-866-6136=20 Email: mhkang@icu.ac.kr=20 =20 =20 Gyu Myung Lee=20 Information and Communications University (ICU)=20 58-4 Hwa Ahm Dong, Yusong, Daejon =20 Korea 305-732=20 Phone: +82-42-866-6231=20 Email: gmlee@icu.ac.kr=20 =20 Young Wook Cha=20 Andong National University (ANU)=20 =20 =20 Choi, et. al. Expires - April 2004 [Page = 26]=20 =0C GSMPv3 for Optical Support October = 2003=20 =20 388 Song-Chon Dong, Andong, Kyungsangbuk-do=20 Korea 760-749=20 Phone: +82-54-820-5714=20 Email: ywcha@andong.ac.kr=20 =20 =20 =20 Full Copyright Statement=20 =20 Copyright (C) The Internet Society (2002). All Rights Reserved. = This=20 document and translations of it MAY be copied and furnished to = others,=20 and derivative works that comment on or otherwise explain it or=20 assist in its implementation MAY be prepared, copied, published and = distributed, in whole or in part, without restriction of any kind,=20 provided that the above copyright notice and this paragraph are=20 included on all such copies and derivative works. However, this=20 document itself MAY not be modified in any way, such as by removing = the copyright notice or references to the Internet Society or other = =20 Internet organizations, except as needed for the purpose of=20 developing Internet standards in which case the procedures for =20 copyrights defined in the Internet Standards process MUST be =20 followed, or as required to translate it into languages other than = =20 English. =20 =20 The limited permissions granted above are perpetual and will not be = revoked by the Internet Society or its successors or assigns. =20 =20 This document and the information contained herein is provided on = an =20 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING = =20 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING = =20 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION =20 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF = MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=20 =20 =20 =20 Choi, et. al. Expires - April 2004 [Page = 27] =0C ------=_NextPart_000_0005_01C39686.9A1CD230-- _______________________________________________ GSMP mailing list GSMP@ietf.org https://www1.ietf.org/mailman/listinfo/gsmp From exim@www1.ietf.org Mon Oct 20 15:40:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20405 for ; Mon, 20 Oct 2003 15:40:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABfsv-0008Ni-1h for gsmp-archive@odin.ietf.org; Mon, 20 Oct 2003 15:40:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KJe80p032212 for gsmp-archive@odin.ietf.org; Mon, 20 Oct 2003 15:40:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABfst-0008Ly-KL for gsmp-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 15:40:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20216 for ; Mon, 20 Oct 2003 15:39:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABfss-0005Do-00 for gsmp-web-archive@ietf.org; Mon, 20 Oct 2003 15:40:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABfsr-0005Dl-00 for gsmp-web-archive@ietf.org; Mon, 20 Oct 2003 15:40:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABfsq-0008Kc-Ce; Mon, 20 Oct 2003 15:40:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABfsg-0008Ie-BV for gsmp@optimus.ietf.org; Mon, 20 Oct 2003 15:39:54 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20117; Mon, 20 Oct 2003 15:39:44 -0400 (EDT) Message-Id: <200310201939.PAA20117@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: gsmp@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 20 Oct 2003 15:39:44 -0400 Subject: [GSMP] I-D ACTION:draft-ietf-gsmp-v3-base-spec-04.txt Sender: gsmp-admin@ietf.org Errors-To: gsmp-admin@ietf.org X-BeenThere: gsmp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: General Switch Management Protocol WG List-Post: List-Help: List-Subscribe: , --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 : GSMPv3 Base Specification Author(s) : A. Doria Filename : draft-ietf-gsmp-v3-base-spec-04.txt Pages : 109 Date : 2003-10-20 This document describes the base General Switch Management Protocol Version 3 (GSMPv3). The GSMPv3 is an asymmetric protocol that allows one or more external switch controllers to establish and maintain the state of a label switch. The GSMPv3 allows control of both unicast and multicast switch connection state as well as control of switch system resources and QoS features. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-gsmp-v3-base-spec-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-v3-base-spec-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-gsmp-v3-base-spec-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-20144413.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-gsmp-v3-base-spec-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-gsmp-v3-base-spec-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-20144413.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ GSMP mailing list GSMP@ietf.org https://www1.ietf.org/mailman/listinfo/gsmp From exim@www1.ietf.org Tue Oct 28 15:26:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23080 for ; Tue, 28 Oct 2003 15:26:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEaPl-0006Cs-U9 for gsmp-archive@odin.ietf.org; Tue, 28 Oct 2003 15:26:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SKQ5Vs023852 for gsmp-archive@odin.ietf.org; Tue, 28 Oct 2003 15:26:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEaPl-0006Cd-QY for gsmp-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 15:26:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22900 for ; Tue, 28 Oct 2003 15:25:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEaPk-000675-00 for gsmp-web-archive@ietf.org; Tue, 28 Oct 2003 15:26:04 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEaPk-000671-00 for gsmp-web-archive@ietf.org; Tue, 28 Oct 2003 15:26:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEaPi-0006BB-Oq; Tue, 28 Oct 2003 15:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEaPC-00066y-Ja for gsmp@optimus.ietf.org; Tue, 28 Oct 2003 15:25:30 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22707; Tue, 28 Oct 2003 15:25:19 -0500 (EST) Message-Id: <200310282025.PAA22707@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: gsmp@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 28 Oct 2003 15:25:19 -0500 Subject: [GSMP] I-D ACTION:draft-ietf-gsmp-packet-spec-02.txt Sender: gsmp-admin@ietf.org Errors-To: gsmp-admin@ietf.org X-BeenThere: gsmp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: General Switch Management Protocol WG List-Post: List-Help: List-Subscribe: , --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 : GSMPv3 Packet Capable Switch Support Author(s) : K. Sundell Filename : draft-ietf-gsmp-packet-spec-02.txt Pages : 50 Date : 2003-10-28 The General Switch Management Protocol version 3 (GSMPv3) has been divided into a base specification (describing the semantics of the protocol) together with a set of documents describing protocol extensions to the base. Such extension could be to support switches capable for optical transport. This document adds extensions to the base GSMPv3 specification for controlling MPLS, ATM and Frame Relay capable switches. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-gsmp-packet-spec-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-packet-spec-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-gsmp-packet-spec-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-28151421.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-gsmp-packet-spec-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-gsmp-packet-spec-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-28151421.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ GSMP mailing list GSMP@ietf.org https://www1.ietf.org/mailman/listinfo/gsmp