From internet-drafts@ietf.org Thu Dec 1 19:43:45 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE7D11E808C; Thu, 1 Dec 2011 19:43:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ol5gaXyWNddZ; Thu, 1 Dec 2011 19:43:44 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC3FF11E807F; Thu, 1 Dec 2011 19:43:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64 Message-ID: <20111202034343.7383.77895.idtracker@ietfa.amsl.com> Date: Thu, 01 Dec 2011 19:43:43 -0800 Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-vendor-constraints-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 03:43:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Path Computation Element Working Grou= p of the IETF. Title : Conveying Vendor-Specific Constraints in the Path Comput= ation Element Protocol Author(s) : Fatai Zhang Adrian Farrel Greg Bernstein Filename : draft-ietf-pce-vendor-constraints-05.txt Pages : 13 Date : 2011-12-01 The Path Computation Element Protocol (PCEP) is used to convey path computation requests and responses between Path Computation Clients (PCCs) and Path Computation Elements (PCEs), and also between cooperating PCEs. In PCEP the path computation requests carry details of the constraints and objective functions that the PCC wishes the PCE to apply in its computation. The mechanisms defined for indicating objective functions include the capability to convey vendor-specific objective functions. This document defines a facility to carry vendor-specific constraints in PCEP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-vendor-constraints-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pce-vendor-constraints-05.txt From zhangfatai@huawei.com Thu Dec 1 19:53:47 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDE4C21F930F for ; Thu, 1 Dec 2011 19:53:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rXKQzrilxtJg for ; Thu, 1 Dec 2011 19:53:47 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF1D21F9321 for ; Thu, 1 Dec 2011 19:53:47 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LVK00FUY5HH3O@szxga04-in.huawei.com> for pce@ietf.org; Fri, 02 Dec 2011 11:53:41 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LVK00C9L5H1U2@szxga04-in.huawei.com> for pce@ietf.org; Fri, 02 Dec 2011 11:53:41 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFM61457; Fri, 02 Dec 2011 11:53:41 +0800 Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 02 Dec 2011 11:53:35 +0800 Received: from SZXEML520-MBX.china.huawei.com ([169.254.1.92]) by szxeml411-hub.china.huawei.com ([10.82.67.138]) with mapi id 14.01.0323.003; Fri, 02 Dec 2011 11:53:35 +0800 Date: Fri, 02 Dec 2011 03:53:33 +0000 From: Zhangfatai In-reply-to: <20111202034344.7383.75020.idtracker@ietfa.amsl.com> X-Originating-IP: [10.70.76.157] To: "pce@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: New Version Notification for draft-ietf-pce-vendor-constraints-05.txt Thread-index: AQHMsKSbzHH9QzApx0SQ5TilVzQczZXH6YSw X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <20111202034344.7383.75020.idtracker@ietfa.amsl.com> Subject: Re: [Pce] New Version Notification for draft-ietf-pce-vendor-constraints-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 03:53:48 -0000 SGkgYWxsLA0KDQpXZSBqdXN0IHN1Ym1pdHRlZCBhIG5ldyByZXZpc2lvbiBvZiB0aGlzIGRyYWZ0 IHRvIGFkZHJlc3Mgc29tZSBjb21tZW50cyBpbiB0aGUgbGlzdCBieSBpbnRyb2R1Y2luZyBWRU5E T1ItQ09OU1RSQUlOVCBUTFYuDQoNClRoZSBhdXRob3JzIHRoaW5rIHRoYXQgdGhpcyBkcmFmdCBp cyByZWFkeSBmb3IgV0cgTEMuDQoNCg0KDQoNClRoYW5rcw0KwqANCkZhdGFpDQoNCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFp bHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiAyMDEx5bm0MTLmnIgy5pelIDEx OjQ0DQpUbzogWmhhbmdmYXRhaQ0KQ2M6IGFkcmlhbkBvbGRkb2cuY28udWs7IFpoYW5nZmF0YWk7 IGdyZWdiQGdyb3R0by1uZXR3b3JraW5nLmNvbQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC1pZXRmLXBjZS12ZW5kb3ItY29uc3RyYWludHMtMDUudHh0DQoNCkEg bmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1pZXRmLXBjZS12ZW5kb3ItY29uc3RyYWludHMtMDUu dHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgRmF0YWkgWmhhbmcgYW5kIHBv c3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LWlldGYtcGNl LXZlbmRvci1jb25zdHJhaW50cw0KUmV2aXNpb246CSAwNQ0KVGl0bGU6CQkgQ29udmV5aW5nIFZl bmRvci1TcGVjaWZpYyBDb25zdHJhaW50cyBpbiB0aGUgUGF0aCBDb21wdXRhdGlvbiBFbGVtZW50 IFByb3RvY29sDQpDcmVhdGlvbiBkYXRlOgkgMjAxMS0xMi0wMg0KV0cgSUQ6CQkgcGNlDQpOdW1i ZXIgb2YgcGFnZXM6IDEzDQoNCkFic3RyYWN0Og0KICAgVGhlIFBhdGggQ29tcHV0YXRpb24gRWxl bWVudCBQcm90b2NvbCAoUENFUCkgaXMgdXNlZCB0byBjb252ZXkgcGF0aA0KICAgY29tcHV0YXRp b24gcmVxdWVzdHMgYW5kIHJlc3BvbnNlcyBiZXR3ZWVuIFBhdGggQ29tcHV0YXRpb24gQ2xpZW50 cw0KICAgKFBDQ3MpIGFuZCBQYXRoIENvbXB1dGF0aW9uIEVsZW1lbnRzIChQQ0VzKSwgYW5kIGFs c28gYmV0d2Vlbg0KICAgY29vcGVyYXRpbmcgUENFcy4gSW4gUENFUCB0aGUgcGF0aCBjb21wdXRh dGlvbiByZXF1ZXN0cyBjYXJyeQ0KICAgZGV0YWlscyBvZiB0aGUgY29uc3RyYWludHMgYW5kIG9i amVjdGl2ZSBmdW5jdGlvbnMgdGhhdCB0aGUgUENDDQogICB3aXNoZXMgdGhlIFBDRSB0byBhcHBs eSBpbiBpdHMgY29tcHV0YXRpb24uDQoNCiAgIFRoZSBtZWNoYW5pc21zIGRlZmluZWQgZm9yIGlu ZGljYXRpbmcgb2JqZWN0aXZlIGZ1bmN0aW9ucyBpbmNsdWRlDQogICB0aGUgY2FwYWJpbGl0eSB0 byBjb252ZXkgdmVuZG9yLXNwZWNpZmljIG9iamVjdGl2ZSBmdW5jdGlvbnMuIFRoaXMNCiAgIGRv Y3VtZW50IGRlZmluZXMgYSBmYWNpbGl0eSB0byBjYXJyeSB2ZW5kb3Itc3BlY2lmaWMgY29uc3Ry YWludHMgaW4NCiAgIFBDRVAuDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClRo ZSBJRVRGIFNlY3JldGFyaWF0DQo= From wwwrun@rfc-editor.org Fri Dec 2 16:21:55 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4368611E80D1; Fri, 2 Dec 2011 16:21:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.957 X-Spam-Level: X-Spam-Status: No, score=-101.957 tagged_above=-999 required=5 tests=[AWL=0.643, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Utx03gspnlGm; Fri, 2 Dec 2011 16:21:54 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 4717A11E80C8; Fri, 2 Dec 2011 16:21:54 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 6039172E010; Fri, 2 Dec 2011 16:21:37 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20111203002137.6039172E010@rfc-editor.org> Date: Fri, 2 Dec 2011 16:21:37 -0800 (PST) Cc: pce@ietf.org, rfc-editor@rfc-editor.org Subject: [Pce] RFC 6457 on PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2011 00:21:55 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6457 Title: PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering Author: T. Takeda, Ed., A. Farrel Status: Informational Stream: IETF Date: December 2011 Mailbox: takeda.tomonori@lab.ntt.co.jp, adrian@olddog.co.uk Pages: 12 Characters: 29107 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pce-inter-layer-req-15.txt URL: http://www.rfc-editor.org/rfc/rfc6457.txt The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering in networks controlled by Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS). MPLS and GMPLS networks may be constructed from layered client/server networks. It is advantageous for overall network efficiency to provide end-to-end traffic engineering across multiple network layers. PCE is a candidate solution for such requirements. Generic requirements for a communication protocol between Path Computation Clients (PCCs) and PCEs are presented in RFC 4657, "Path Computation Element (PCE) Communication Protocol Generic Requirements". Generic requirements for a PCE discovery protocol are presented in RFC 4674, "Requirements for Path Computation Element (PCE) Discovery". This document complements the generic requirements and presents detailed sets of PCC-PCE communication protocol requirements and PCE discovery protocol requirements for inter-layer traffic engineering. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Path Computation Element Working Group of the IETF. INFORMATIONAL: 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-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From julien.meuric@orange.com Tue Dec 6 08:09:04 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E411C21F8C08; Tue, 6 Dec 2011 08:09:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJUfHX2PR0nl; Tue, 6 Dec 2011 08:09:00 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 91E4721F8C00; Tue, 6 Dec 2011 08:08:59 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5A3F08C0002; Tue, 6 Dec 2011 17:10:05 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 5231B8B8001; Tue, 6 Dec 2011 17:10:05 +0100 (CET) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Dec 2011 17:08:58 +0100 Received: from [10.193.71.161] ([10.193.71.161]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Dec 2011 17:08:58 +0100 Message-ID: <4EDE3E19.6010303@orange.com> Date: Tue, 06 Dec 2011 17:08:57 +0100 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: Zhangfatai References: <4ED64A32.8060707@labn.net> <5E893DB832F57341992548CDBB333163A4B54CA99D@EMBX01-HQ.jnpr.net> <4ED65D2D.2040400@labn.net> <5E893DB832F57341992548CDBB333163A4B54CADAB@EMBX01-HQ.jnpr.net> <4ED69B7D.409@labn.net> <5E893DB832F57341992548CDBB333163A4B54CAEE5@EMBX01-HQ.jnpr.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 06 Dec 2011 16:08:58.0255 (UTC) FILETIME=[5C57B1F0:01CCB431] Cc: CCAMP , "pce@ietf.org" Subject: Re: [Pce] [CCAMP] R: OSPF OTN considerations post IETF 82 (Issue 1/2) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 16:09:05 -0000 Hi Fatai. As co-author of draft-ietf-pce-inter-layer-ext, I believe you will agree on the fact that having a Switching Capability per ODUk layer would make the use of objects including a Switching Cap field rather straightforward and enables a fine-grained resource description, e.g. in: - REQ-ADAP-CAP object, to precisely identify the type of adaptation requested by a higher layer, or to get a clear feedback on the missing adaptation for unsuccessful path computations; - SERVER_LAYER_INFO sub-object, to precisely identify the type of server layer within the ERO. Do not you think that summarizing G.709 by a single Switching Cap value would take some capabilities away? What would you suggest so as to achieve the same level of details in that scenario? Regards, Julien Le 02/12/2011 09:51, Zhangfatai a écrit : > Hi all, > > I agree that there is no need to overload Switching Cap. > > > > > > Thanks > > Fatai > > > -----Original Message----- From: ccamp-bounces@ietf.org > [mailto:ccamp-bounces@ietf.org] On Behalf Of BELOTTI, SERGIO > (SERGIO) > > John, as co-authors, we shared completely your thoughts. > > Thanks Sergio and Pietro > > SERGIO BELOTTI > > ALCATEL-LUCENT Terrestrial System Architect Optics Portfolio > Evolution > > via Trento 30 , Vimercate(MI) Italy T: +39 0396863033 > Sergio.Belotti@alcatel-lucent.com > > > > -----Messaggio originale----- Da: ccamp-bounces@ietf.org > [mailto:ccamp-bounces@ietf.org] Per conto di John E Drake Inviato: > mercoledì 30 novembre 2011 22.37 A: Lou Berger Cc: CCAMP Oggetto: > Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue 1/2) > > Comments inline. I still think this is a terrible idea and I would > like to see what the rest of the WG thinks. > > > -----Original Message----- From: Lou Berger > > [mailto:lberger@labn.net] Sent: Wednesday, November 30, 2011 1:09 > > PM To: John E Drake Cc: Daniele Ceccarelli; CCAMP Subject: Re: > > [CCAMP] OSPF OTN considerations post IETF 82 (Issue 1/2) > > > > > > John, > > > > see below > > > > > > On 11/30/2011 2:59 PM, John E Drake wrote: > >> Using Switching Capability to indicate link bandwidth seems > >> ill-considered at best, especially since this information is > >> carried in other fields, and as Daniele noted, it significantly > >> overloads to intended meaning of Switching Capability. > > > > I agree with the point on BW, but my point was related to the > > layer&hierarchy implications of the different ODUk values. I'd > > think that using values that are TDM-1 -> TDM-n should make this > > clear and remove any ambiguity related to bandwidth. It is also > > completely consistent with the base GMPLS definition, i.e., PSC-1 > > -> PSC-n. > > [JD] You are simply asserting that this is a good idea and further > asserting that there is "ambiguity related to bandwidth', without > providing any evidence. > > To the best of my knowledge no one ever implemented or deployed the > PSC-1 -> PSC-4 hierarchy, simply because no one could figure out > what it meant. To quote from you, below, "Well hopefully we have a > better understanding of the technologies involved than we had in the > past.". I.e., we should all understand that PSC-1 -> PSC-4 was a bad > idea (tm) and move on. > > > > >> It also is inconsistent with the usage of Switching Capability > >> in SDH/SONET. > > > > Well hopefully we have a better understanding of the technologies > > involved than we had in the past. > > [JD] I think we had a very good understanding of SDH/SONET then and > we have a very good understanding of OTN now, and in both cases the > authors saw no requirement to overload switching capability in the > manner you are suggesting. > > > > >> > >> A more extensive quote from RFC4202 is the following, which seems > >> clear enough to me: > >> > >> "In the context of this document we say that a link is connected > >> to a node by an interface. In the context of GMPLS interfaces > >> may have different switching capabilities. For example an > >> interface that connects a given link to a node may not be able > >> to switch individual packets, but it may be able to switch > >> channels within an SDH payload. Interfaces at each end of a link > >> need not have the same switching capabilities. Interfaces on the > >> same node need not have the same switching capabilities." > > > > Not sure how this helps clarify anything... > > [JD] I think it clarifies that switching capabilities is meant to > describe how a given interface switches the information with which > it is provided. This has nothing to do with the interface's > bandwidth. > > > > > Lou > >> > >>> -----Original Message----- From: Lou Berger > >>> [mailto:lberger@labn.net] Sent: Wednesday, November 30, 2011 > >>> 8:43 AM To: John E Drake Cc: Daniele Ceccarelli; CCAMP > >>> Subject: Re: [CCAMP] OSPF OTN considerations post IETF 82 > >>> (Issue > > 1/2) > >>> > >>> Great. Care to substantiate your point? > >>> > >>> On 11/30/2011 11:14 AM, John E Drake wrote: > >>>> I completely disagree. > >>>> > >>>>> -----Original Message----- From: ccamp-bounces@ietf.org > >>>>> [mailto:ccamp-bounces@ietf.org] On > >>> Behalf > >>>>> Of Lou Berger Sent: Wednesday, November 30, 2011 7:22 AM > >>>>> To: Daniele Ceccarelli Cc: CCAMP Subject: Re: [CCAMP] OSPF > >>>>> OTN considerations post IETF 82 (Issue > >>> 1/2) > >>>>> > >>>>> Hi Daniele, Since I raised the point, I guess I need to > >>>>> champion it! (With chair hat off.) > >>>>> > >>>>> All, > >>>>> > >>>>> Daniele said: > >>>>>> WRT issue 1: the proposal was to indicate the bottom > >>>>>> most ODUk of > >>> the > >>>>>> muxing hiearachy in the Switching Capability field of > >>>>>> the ISCD. > >>> After > >>>>>> a quick talk with the other authors of the ID, the idea > >>>>>> was to > >>> reject > >>>>>> the proposal as it would lead to an overloading of the > >>>>>> meaning of > >>> the > >>>>>> Switching Capability field. (even if the definition of > >>>>>> PSC1-2-3-4 already overloads the meaning of the > >>>>>> switching capability field) > >>>>> > >>>>> This really goes to the interpretation of the intent of > >>>>> Switching Capability Types. So we have a few definitions: > >>>>> 3471 says "the > > type > >>> of > >>>>> switching that should be performed", 4202 says "describes > > switching > >>>>> capability of an interface." 3945 doesn't really define > >>>>> the term > > (it > >>>>> just references 4202), but does equate it with a "layer". > >>>>> While it allows for hierarchy within a "layer" it also > >>>>> says hierarchy > > occurs > >>>>> "between interface types". > >>>>> > >>>>> So I interpret Switching Capability Types to represent (a) > > different > >>>>> switching/technology layers and (b) different levels of > >>>>> hierarchy > > -- > >>>>> even within a layer. I think (a) is identifiable in the > > definition > >>> of > >>>>> the original GMPLS supported technologies (i.e., PSC, > >>>>> L2SC, TDM > > LSC, > >>>>> and FSC), and (b) is identifiable in the original types > >>>>> plus the > >>> definition > >>>>> of PSC-1 through PSC-4. > >>>>> > >>>>> So how does this apply to our current OTN work? > >>>>> > >>>>> To me, the first question to ask relates to (a), and is > >>>>> should > > each > >>>>> ODUk be modeled as a separate layer? > >>>>> > >>>>> I know this has been a much debated point, and it seems to > >>>>> me that > >>> they > >>>>> are, but more for the perspective of switching layers than > >>> technology > >>>>> layers (i.e., they are clearly the same technology but are > > different > >>>>> granularity of swicthing.) So this is a yes for me. > >>>>> > >>>>> I think the second question to ask relates to (b), and is > >>>>> does > > each > >>>>> ODUk represent a different level of hierarchy? > >>>>> > >>>>> I see this as simply yes, and no different than what has > >>>>> been done > >>> more > >>>>> recently with Ethernet or, even if we do continue to model > >>>>> OTN as > > a > >>>>> single layer, no different than PSC-1 -> PSC-4. > >>>>> > >>>>> There's also a minor processing efficiency gained by this > >>>>> approach > >>> for > >>>>> nodes that support a smaller set of ODUks than are > >>>>> advertised > > within > >>> an > >>>>> IGP. > >>>>> > >>>>> Based on all this, I believe different ODUk's should use > >>>>> different Switching Types. In particular, I'm proposing: > >>>>> (1) that either the framework or info documents identify > >>>>> that a per-OTUk Switching Capability Types will be used to > >>>>> support G.709v3. (2) that > >>>>> draft-ietf-ccamp-gmpls-ospf-g709v3 define a different > >>>>> Switching Cap field value for each ODUk, and that it state > >>>>> that the value corresponding to the signal type > >>>>> identified in the #stages=0 of the ISCP be set. (Without > >>>>> any other changes to the current definition of ISCD.) (3) > >>>>> that draft-ietf-ccamp-gmpls-signaling-g709v3 be updated to > >>>>> match above. > >>>>> > >>>>> To keep thinks generic, we probably should use TDM-1 > >>>>> through TDM-n > >>> as > >>>>> the new Switching Capability Types, but this is a > >>>>> secondary > >>> discussion. > >>>>> > >>>>> Comments? > >>>>> > >>>>> Lou > >>>>> > >>>>> PS While the above is an important change, it doesn't > > significantly > >>>>> impact encoding and won't take much text to make the > >>>>> actual > > change, > >>> so > >>>>> this is a discussion that can continue until Paris if we > >>>>> really > > need > >>> a > >>>>> face to face to resolve the discussion. > >>>>> > >>>>> On 11/23/2011 1:18 PM, Daniele Ceccarelli wrote: > >>>>>> Hi CCAMP, > >>>>>> > >>>>>> > >>>>>> > >>>>>> During the OTN OSPF draft presentation at the IETF > >>>>>> meeting in > >>> Taipei > >>>>> two > >>>>>> comments were raised with respect to the following > >>>>>> issues: > >>>>>> > >>>>>> > >>>>>> > >>>>>> - Issue 1: Using different switching caps for each ODU > >>>>>> type > >>>>>> > >>>>>> - Issue 2: Type 2 (unres bandwidth for variable > >>>>>> containers) and > >>> Type > >>>>> 3 > >>>>>> (MAX LSP bandwidth foe variable containers always used > >>>>>> in tandem? > >>>>>> > >>>>>> > >>>>>> > >>>>>> WRT issue 1: the proposal was to indicate the bottom > >>>>>> most ODUk of > >>> the > >>>>>> muxing hiearachy in the Switching Capability field of > >>>>>> the ISCD. > >>> After > >>>>> a > >>>>>> quick talk with the other authors of the ID, the idea > >>>>>> was to > > reject > >>>>> the > >>>>>> proposal as it would lead to an overloading of the > >>>>>> meaning of the Switching Capability field. (even if the > >>>>>> definition of PSC1-2-3-4 already overloads the meaning > >>>>>> of the switching capability field) > >>>>>> > >>>>>> > >>>>>> > >>>>>> WRT issue 2: it is analyzed in section 5.3 of the draft > >>>>>> (version > > - > >>>>> 00). > >>>>>> I'm copying it below for your convenience > >>>>>> > >>>>>> > >>>>>> > >>>>>> In this example the advertisement of an ODUflex->ODU3 > > hierarchy > >>> is > >>>>>> > >>>>>> shown. In case of ODUflex advertisement the MAX LSP > >>>>>> bandwidth > >>>>> needs > >>>>>> > >>>>>> to be advertised but in some cases also information > >>>>>> about the > >>>>>> > >>>>>> Unreserved bandwidth could be useful. The amount of > > Unreserved > >>>>>> > >>>>>> bandwidth does not give a clear indication of how many > >>>>>> ODUflex > >>> LSP > >>>>>> > >>>>>> can be set up either at the MAX LSP Bandwidth or at > >>>>>> different > >>>>> rates, > >>>>>> > >>>>>> as it gives no information about the spatial allocation > >>>>>> of the > >>>>> free > >>>>>> > >>>>>> TSs. > >>>>>> > >>>>>> > >>>>>> > >>>>>> An indication of the amount of Unreserved bandwidth > >>>>>> could be > >>>>> useful > >>>>>> > >>>>>> during the path computation process, as shown in the > >>>>>> following > >>>>>> > >>>>>> example. Supposing there are two TE-links (A and B) > >>>>>> with MAX > >>> LSP > >>>>>> > >>>>>> Bandwidth equal to 10 Gbps each. In case 50Gbps of > >>>>>> Unreserved > >>>>>> > >>>>>> Bandwidth are available on Link A, 10Gbps on Link B and > >>>>>> 3 > >>> ODUflex > >>>>>> > >>>>>> LSPs of 10 GBps each, have to be restored, for sure only > >>>>>> one > > can > >>>>> be > >>>>>> > >>>>>> restored along Link B and it is probable (but not sure) > >>>>>> that > > two > >>>>> of > >>>>>> > >>>>>> them can be restored along Link A. > >>>>>> > >>>>>> > >>>>>> > >>>>>> Early proposal was to have, in the case of variable > >>>>>> containers advertisements (i.e. ODUflex), the MAX LSP > >>>>>> bandwidth TLV (Type 3) > >>> as > >>>>> a > >>>>>> mandatory piece of information and the Unreserved > >>>>>> bandiwdth TLV > >>> (Type > >>>>> 2) > >>>>>> as an optional piece of information. > >>>>>> > >>>>>> The comment received is that optional information can > >>>>>> lead to interworking issues and the counter proposal was > >>>>>> to have both > >>> pieces > >>>>> of > >>>>>> information as mandatory and, as a consequence, merge > >>>>>> the two > > TLVs > >>>>> into > >>>>>> a single one. > >>>>>> > >>>>>> > >>>>>> > >>>>>> We'd like to hear the opinion of the WG on both issues > >>>>>> before > >>>>> proceeding > >>>>>> with any modification to the document. > >>>>>> > >>>>>> > >>>>>> > >>>>>> Thanks, > >>>>>> > >>>>>> Daniele > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> *DANIELE CECCARELLI * *System & Technology - DU IP & > >>>>>> Broadband* > >>>>>> > >>>>>> > >>>>>> Via L.Calda, 5 Genova, Italy Phone +390106002512 Mobile > >>>>>> +393346725750 daniele.ceccarelli@ericsson.com > >>>>>> www.ericsson.com > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> This Communication is Confidential. We only send and > >>>>>> receive > > email > >>> on > >>>>>> the basis of the term set out at > > www.ericsson.com/email_disclaimer > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > > _______________________________________________ CCAMP mailing list > CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From zhangfatai@huawei.com Tue Dec 6 11:21:26 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A588821F8B94; Tue, 6 Dec 2011 11:21:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.475 X-Spam-Level: X-Spam-Status: No, score=-1.475 tagged_above=-999 required=5 tests=[AWL=-5.124, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_38=0.6, J_CHICKENPOX_46=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UojJlnfU7tvI; Tue, 6 Dec 2011 11:21:24 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id C080121F84A9; Tue, 6 Dec 2011 11:21:23 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LVS00G46R3H9N@szxga04-in.huawei.com>; Wed, 07 Dec 2011 03:21:17 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LVS0081FR3HO8@szxga04-in.huawei.com>; Wed, 07 Dec 2011 03:21:17 +0800 (CST) Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFP29065; Wed, 07 Dec 2011 03:21:17 +0800 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 07 Dec 2011 03:21:12 +0800 Received: from SZXEML520-MBS.china.huawei.com ([169.254.2.240]) by szxeml401-hub.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0323.003; Wed, 07 Dec 2011 03:21:13 +0800 Date: Tue, 06 Dec 2011 19:21:12 +0000 From: Zhangfatai In-reply-to: <4EDE3E19.6010303@orange.com> X-Originating-IP: [172.24.1.69] To: Julien Meuric Message-id: MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [CCAMP] R: OSPF OTN considerations post IETF 82 (Issue 1/2) Thread-index: AQHMsMyIiDQ2ZQ5qCU2IIpJar2pMIZXIPN2wgAY+JICAALLxeg== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4ED64A32.8060707@labn.net> <5E893DB832F57341992548CDBB333163A4B54CA99D@EMBX01-HQ.jnpr.net> <4ED65D2D.2040400@labn.net> <5E893DB832F57341992548CDBB333163A4B54CADAB@EMBX01-HQ.jnpr.net> <4ED69B7D.409@labn.net> <5E893DB832F57341992548CDBB333163A4B54CAEE5@EMBX01-HQ.jnpr.net> <4EDE3E19.6010303@orange.com> Cc: CCAMP , "pce@ietf.org" Subject: [Pce] =?gb2312?b?tPC4tDogW0NDQU1QXSBSOiAgT1NQRiBPVE4gY29uc2lkZXJh?= =?gb2312?b?dGlvbnMgcG9zdCBJRVRGIDgyIChJc3N1ZSAxLzIp?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 19:21:26 -0000 SGkgSnVsaWVuLA0KDQpJIGFncmVlIHRoZSByZXF1aXJlbWVudCB0aGF0IHlvdSBtZW50aW9uZWQs IGJ1dCBpdCBjYW4gYmUgcmVzb3ZsZWQgd2l0aG91dCBleHRlbmRpbmcgU3dpdGNoaW5nIENhcC4N Cg0KSXQgaXMga25vd24gdGhhdCB0aGVyZSBhcmUgdHdvIGNhc2VzIGRlc2NyaWJlZCBpbiBSRkM1 MjEyIGFuZCBSRkM1MzM5LCBvbmUgaXMgTVJOLCBhbm90aGVyIG9uZSBpcyBNTE4uIEluIFJGQzUy MTIsIGl0IHNheXM6DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpUaHVzLCBhIGNvbnRyb2wgcGxh bmUgcmVnaW9uLCBpZGVudGlmaWVkIGJ5IGl0cyBzd2l0Y2hpbmcgdHlwZSB2YWx1ZSAoZS5nLiwg VERNKSwgY2FuIGJlIHN1Yi1kaXZpZGVkIGludG8gc21hbGxlci1ncmFudWxhcml0eSBjb21wb25l bnQgbmV0d29ya3MgYmFzZWQgb24gImRhdGEgcGxhbmUgc3dpdGNoaW5nIGxheWVycyIuICBUaGUg IEludGVyZmFjZSBTd2l0Y2hpbmcgQ2FwYWJpbGl0eSBEZXNjcmlwdG9yIChJU0NEKSBbUkZDNDIw Ml0sICBpZGVudGlmeWluZyB0aGUgaW50ZXJmYWNlIHN3aXRjaGluZyBjYXBhYmlsaXR5IChJU0Mp LCB0aGUgZW5jb2RpbmcgdHlwZSwgYW5kIHRoZSBzd2l0Y2hpbmcgYmFuZHdpZHRoIGdyYW51bGFy aXR5LCBlbmFibGVzIHRoZSBjaGFyYWN0ZXJpemF0aW9uIG9mIHRoZSBhc3NvY2lhdGVkIGxheWVy cy4NCg0KIEluIHRoaXMgZG9jdW1lbnQsIHdlIGRlZmluZSBhIG11bHRpLWxheWVyIG5ldHdvcmsg KE1MTikgdG8gYmUgYSBUcmFmZmljIEVuZ2luZWVyaW5nIChURSkgZG9tYWluIGNvbXByaXNpbmcg bXVsdGlwbGUgZGF0YSBwbGFuZSBzd2l0Y2hpbmcgbGF5ZXJzIGVpdGhlciBvZiB0aGUgc2FtZSBJ U0MgKGUuZy4sIFRETSkgb3IgZGlmZmVyZW50IElTQyAoZS5nLiwgVERNIGFuZCBQU0MpIGFuZCBj b250cm9sbGVkIGJ5IGEgc2luZ2xlIEdNUExTIGNvbnRyb2wgcGxhbmUgIGluc3RhbmNlLiAgV2Ug ZnVydGhlciBkZWZpbmUgYSBwYXJ0aWN1bGFyIGNhc2Ugb2YgTUxOcy4gIEEgbXVsdGktIHJlZ2lv biBuZXR3b3JrIChNUk4pIGlzIGRlZmluZWQgYXMgYSBURSBkb21haW4gc3VwcG9ydGluZyBhdCBs ZWFzdCB0d28gZGlmZmVyZW50IHN3aXRjaGluZyB0eXBlcyAoZS5nLiwgUFNDIGFuZCBURE0pLCBl aXRoZXIgaG9zdGVkIG9uIHRoZSBzYW1lIGRldmljZSBvciBvbiBkaWZmZXJlbnQgb25lcywgYW5k IHVuZGVyIHRoZSBjb250cm9sIG9mIGEgc2luZ2xlIEdNUExTIGNvbnRyb2wgcGxhbmUgaW5zdGFu Y2UuDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpUaGVyZWZvcmUsIGZvciBNUk4gY2Fz ZSwgd2UgY2FuIHVzZSBTd2l0Y2hpbmcgQ2FwIHRvIGRpZmZlcmVudGlhdGUgdGhlIGRpZmZlcmVu dCAibGF5ZXJzIjsgZm9yIE1MTiBjYXNlIChzYW1lIElTQyB3aXRoIGRpZmZlcmVudCBncmFudWxh cml0eSksIHdlIGNhbiB1c2UgU3dpdGNoaW5nIENhcCAmIFNpZ25hbCBUeXBlICgmIEVuY29kaW5n IFR5cGUgYXMgd2VsbCkgdG8gZGlmZmVyZW50aWF0ZSB0aGUgZGlmZmVyZW50IGdyYW51bGFyaXR5 Lg0KDQpTbywgY29tZSBiYWNrIHRvIHlvdXIgcXVlc3Rpb24sIGl0IGNhbiBiZSBhY2hpdmVkIGJ5 IHVzaW5nIFN3aXRjaGluZyBDYXAmRW5jb2RpbmcgVHlwZSZTaWduYWwgVHlwZSB0byBpZGVudGlm eSB0aGUgZ3JhbnVsYXJpdHkgcmVxdWVzdGVkIGluIE9UTiBuZXR3b3JrcyhlLmcuLCB0aGlzIGlu Zm9ybWF0aW9uIGNhbiBiZSBjYXJyaWVkIGluIFNFUlZFUl9MQVlFUl9JTkZPIHN1Yi1vYmplY3Qp IC4NCg0KTGFzdGx5LCBpbiBteSBvcGluaW9uLCAgaWYgdGhlcmUgaXMgbm8gaXNzdWUgYmFzZWQg b24gdGhlIGV4aXN0aW5nIG1lY2huaXNtIG9yIGRlZmluaXRpb24gd2l0aG91dCBleHRlbmRpbmcg U3dpdGNoaW5nIENhcCwgSSBkb24ndCB0aGluayB3ZSBuZWVkIHRvIGV4dGVuZCBTd2l0Y2hpbmcg Q2FwLg0KDQoNClRoYW5rcw0KDQpGYXRhaQ0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0Kt6K8/sjLOiBKdWxpZW4gTWV1cmljIFtqdWxpZW4ubWV1cmljQG9y YW5nZS5jb21dDQq3osvNyrG85DogMjAxMcTqMTLUwjfI1SAwOjA4DQq1vTogWmhhbmdmYXRhaQ0K Q2M6IENDQU1QOyBwY2VAaWV0Zi5vcmcNCtb3zOI6IFJlOiBbQ0NBTVBdIFI6ICBPU1BGIE9UTiBj b25zaWRlcmF0aW9ucyBwb3N0IElFVEYgODIgKElzc3VlIDEvMikNCg0KSGkgRmF0YWkuDQoNCkFz IGNvLWF1dGhvciBvZiBkcmFmdC1pZXRmLXBjZS1pbnRlci1sYXllci1leHQsIEkgYmVsaWV2ZSB5 b3Ugd2lsbCBhZ3JlZQ0Kb24gdGhlIGZhY3QgdGhhdCBoYXZpbmcgYSBTd2l0Y2hpbmcgQ2FwYWJp bGl0eSBwZXIgT0RVayBsYXllciB3b3VsZCBtYWtlDQp0aGUgdXNlIG9mIG9iamVjdHMgaW5jbHVk aW5nIGEgU3dpdGNoaW5nIENhcCBmaWVsZCByYXRoZXINCnN0cmFpZ2h0Zm9yd2FyZCBhbmQgZW5h YmxlcyBhIGZpbmUtZ3JhaW5lZCByZXNvdXJjZSBkZXNjcmlwdGlvbiwgZS5nLiBpbjoNCi0gUkVR LUFEQVAtQ0FQIG9iamVjdCwgdG8gcHJlY2lzZWx5IGlkZW50aWZ5IHRoZSB0eXBlIG9mIGFkYXB0 YXRpb24NCnJlcXVlc3RlZCBieSBhIGhpZ2hlciBsYXllciwgb3IgdG8gZ2V0IGEgY2xlYXIgZmVl ZGJhY2sgb24gdGhlIG1pc3NpbmcNCmFkYXB0YXRpb24gZm9yIHVuc3VjY2Vzc2Z1bCBwYXRoIGNv bXB1dGF0aW9uczsNCi0gU0VSVkVSX0xBWUVSX0lORk8gc3ViLW9iamVjdCwgdG8gcHJlY2lzZWx5 IGlkZW50aWZ5IHRoZSB0eXBlIG9mIHNlcnZlcg0KbGF5ZXIgd2l0aGluIHRoZSBFUk8uDQoNCkRv IG5vdCB5b3UgdGhpbmsgdGhhdCBzdW1tYXJpemluZyBHLjcwOSBieSBhIHNpbmdsZSBTd2l0Y2hp bmcgQ2FwIHZhbHVlDQp3b3VsZCB0YWtlIHNvbWUgY2FwYWJpbGl0aWVzIGF3YXk/IFdoYXQgd291 bGQgeW91IHN1Z2dlc3Qgc28gYXMgdG8NCmFjaGlldmUgdGhlIHNhbWUgbGV2ZWwgb2YgZGV0YWls cyBpbiB0aGF0IHNjZW5hcmlvPw0KDQpSZWdhcmRzLA0KDQpKdWxpZW4NCg0KDQpMZSAwMi8xMi8y MDExIDA5OjUxLCBaaGFuZ2ZhdGFpIGEgqKZjcml0IDoNCj4gIEhpIGFsbCwNCj4NCj4gIEkgYWdy ZWUgdGhhdCB0aGVyZSBpcyBubyBuZWVkIHRvIG92ZXJsb2FkIFN3aXRjaGluZyBDYXAuDQo+DQo+ DQo+DQo+DQo+DQo+ICBUaGFua3MNCj4NCj4gIEZhdGFpDQo+DQo+DQo+ICAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLSBGcm9tOiBjY2FtcC1ib3VuY2VzQGlldGYub3JnDQo+ICBbbWFpbHRvOmNj YW1wLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCRUxPVFRJLCBTRVJHSU8NCj4gIChT RVJHSU8pDQo+DQo+ICBKb2huLCBhcyBjby1hdXRob3JzLCB3ZSBzaGFyZWQgY29tcGxldGVseSB5 b3VyIHRob3VnaHRzLg0KPg0KPiAgVGhhbmtzIFNlcmdpbyBhbmQgUGlldHJvDQo+DQo+ICBTRVJH SU8gQkVMT1RUSQ0KPg0KPiAgQUxDQVRFTC1MVUNFTlQgVGVycmVzdHJpYWwgU3lzdGVtIEFyY2hp dGVjdCBPcHRpY3MgUG9ydGZvbGlvDQo+ICBFdm9sdXRpb24NCj4NCj4gIHZpYSBUcmVudG8gMzAg LCBWaW1lcmNhdGUoTUkpIEl0YWx5IFQ6ICszOSAwMzk2ODYzMDMzDQo+ICBTZXJnaW8uQmVsb3R0 aUBhbGNhdGVsLWx1Y2VudC5jb20NCj4NCj4NCj4NCj4gIC0tLS0tTWVzc2FnZ2lvIG9yaWdpbmFs ZS0tLS0tIERhOiBjY2FtcC1ib3VuY2VzQGlldGYub3JnDQo+ICBbbWFpbHRvOmNjYW1wLWJvdW5j ZXNAaWV0Zi5vcmddIFBlciBjb250byBkaSBKb2huIEUgRHJha2UgSW52aWF0bzoNCj4gIG1lcmNv bGVkqKwgMzAgbm92ZW1icmUgMjAxMSAyMi4zNyBBOiBMb3UgQmVyZ2VyIENjOiBDQ0FNUCBPZ2dl dHRvOg0KPiAgUmU6IFtDQ0FNUF0gT1NQRiBPVE4gY29uc2lkZXJhdGlvbnMgcG9zdCBJRVRGIDgy IChJc3N1ZSAxLzIpDQo+DQo+ICBDb21tZW50cyBpbmxpbmUuIEkgc3RpbGwgdGhpbmsgdGhpcyBp cyBhIHRlcnJpYmxlIGlkZWEgYW5kIEkgd291bGQNCj4gIGxpa2UgdG8gc2VlIHdoYXQgdGhlIHJl c3Qgb2YgdGhlIFdHIHRoaW5rcy4NCj4NCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSBG cm9tOiBMb3UgQmVyZ2VyDQo+ID4gW21haWx0bzpsYmVyZ2VyQGxhYm4ubmV0XSBTZW50OiBXZWRu ZXNkYXksIE5vdmVtYmVyIDMwLCAyMDExIDE6MDkNCj4gPiBQTSBUbzogSm9obiBFIERyYWtlIENj OiBEYW5pZWxlIENlY2NhcmVsbGk7IENDQU1QIFN1YmplY3Q6IFJlOg0KPiA+IFtDQ0FNUF0gT1NQ RiBPVE4gY29uc2lkZXJhdGlvbnMgcG9zdCBJRVRGIDgyIChJc3N1ZSAxLzIpDQo+ID4NCj4gPg0K PiA+IEpvaG4sDQo+ID4NCj4gPiBzZWUgYmVsb3cNCj4gPg0KPiA+DQo+ID4gT24gMTEvMzAvMjAx MSAyOjU5IFBNLCBKb2huIEUgRHJha2Ugd3JvdGU6DQo+ID4+IFVzaW5nIFN3aXRjaGluZyBDYXBh YmlsaXR5IHRvIGluZGljYXRlIGxpbmsgYmFuZHdpZHRoIHNlZW1zDQo+ID4+IGlsbC1jb25zaWRl cmVkIGF0IGJlc3QsIGVzcGVjaWFsbHkgc2luY2UgdGhpcyBpbmZvcm1hdGlvbiBpcw0KPiA+PiBj YXJyaWVkIGluIG90aGVyIGZpZWxkcywgYW5kIGFzIERhbmllbGUgbm90ZWQsIGl0IHNpZ25pZmlj YW50bHkNCj4gPj4gb3ZlcmxvYWRzIHRvIGludGVuZGVkIG1lYW5pbmcgb2YgU3dpdGNoaW5nIENh cGFiaWxpdHkuDQo+ID4NCj4gPiBJIGFncmVlIHdpdGggdGhlIHBvaW50IG9uIEJXLCBidXQgbXkg cG9pbnQgd2FzIHJlbGF0ZWQgdG8gdGhlDQo+ID4gbGF5ZXImaGllcmFyY2h5IGltcGxpY2F0aW9u cyBvZiB0aGUgZGlmZmVyZW50IE9EVWsgdmFsdWVzLiBJJ2QNCj4gPiB0aGluayB0aGF0IHVzaW5n IHZhbHVlcyB0aGF0IGFyZSBURE0tMSAtPiBURE0tbiBzaG91bGQgbWFrZSB0aGlzDQo+ID4gY2xl YXIgYW5kIHJlbW92ZSBhbnkgYW1iaWd1aXR5IHJlbGF0ZWQgdG8gYmFuZHdpZHRoLiBJdCBpcyBh bHNvDQo+ID4gY29tcGxldGVseSBjb25zaXN0ZW50IHdpdGggdGhlIGJhc2UgR01QTFMgZGVmaW5p dGlvbiwgaS5lLiwgUFNDLTENCj4gPiAtPiBQU0Mtbi4NCj4NCj4gIFtKRF0gWW91IGFyZSBzaW1w bHkgYXNzZXJ0aW5nIHRoYXQgdGhpcyBpcyBhIGdvb2QgaWRlYSBhbmQgZnVydGhlcg0KPiAgYXNz ZXJ0aW5nIHRoYXQgdGhlcmUgaXMgImFtYmlndWl0eSByZWxhdGVkIHRvIGJhbmR3aWR0aCcsIHdp dGhvdXQNCj4gIHByb3ZpZGluZyBhbnkgZXZpZGVuY2UuDQo+DQo+ICBUbyB0aGUgYmVzdCBvZiBt eSBrbm93bGVkZ2Ugbm8gb25lIGV2ZXIgaW1wbGVtZW50ZWQgb3IgZGVwbG95ZWQgdGhlDQo+ICBQ U0MtMSAtPiBQU0MtNCBoaWVyYXJjaHksIHNpbXBseSBiZWNhdXNlIG5vIG9uZSBjb3VsZCBmaWd1 cmUgb3V0DQo+ICB3aGF0IGl0IG1lYW50LiBUbyBxdW90ZSBmcm9tIHlvdSwgYmVsb3csICJXZWxs IGhvcGVmdWxseSB3ZSBoYXZlIGENCj4gIGJldHRlciB1bmRlcnN0YW5kaW5nIG9mIHRoZSB0ZWNo bm9sb2dpZXMgaW52b2x2ZWQgdGhhbiB3ZSBoYWQgaW4gdGhlDQo+ICBwYXN0LiIuIEkuZS4sIHdl IHNob3VsZCBhbGwgdW5kZXJzdGFuZCB0aGF0IFBTQy0xIC0+IFBTQy00IHdhcyBhIGJhZA0KPiAg aWRlYSAodG0pIGFuZCBtb3ZlIG9uLg0KPg0KPiA+DQo+ID4+IEl0IGFsc28gaXMgaW5jb25zaXN0 ZW50IHdpdGggdGhlIHVzYWdlIG9mIFN3aXRjaGluZyBDYXBhYmlsaXR5DQo+ID4+IGluIFNESC9T T05FVC4NCj4gPg0KPiA+IFdlbGwgaG9wZWZ1bGx5IHdlIGhhdmUgYSBiZXR0ZXIgdW5kZXJzdGFu ZGluZyBvZiB0aGUgdGVjaG5vbG9naWVzDQo+ID4gaW52b2x2ZWQgdGhhbiB3ZSBoYWQgaW4gdGhl IHBhc3QuDQo+DQo+ICBbSkRdIEkgdGhpbmsgd2UgaGFkIGEgdmVyeSBnb29kIHVuZGVyc3RhbmRp bmcgb2YgU0RIL1NPTkVUIHRoZW4gYW5kDQo+ICB3ZSBoYXZlIGEgdmVyeSBnb29kIHVuZGVyc3Rh bmRpbmcgb2YgT1ROIG5vdywgYW5kIGluIGJvdGggY2FzZXMgdGhlDQo+ICBhdXRob3JzIHNhdyBu byByZXF1aXJlbWVudCB0byBvdmVybG9hZCBzd2l0Y2hpbmcgY2FwYWJpbGl0eSBpbiB0aGUNCj4g IG1hbm5lciB5b3UgYXJlIHN1Z2dlc3RpbmcuDQo+DQo+ID4NCj4gPj4NCj4gPj4gQSBtb3JlIGV4 dGVuc2l2ZSBxdW90ZSBmcm9tIFJGQzQyMDIgaXMgdGhlIGZvbGxvd2luZywgd2hpY2ggc2VlbXMN Cj4gPj4gY2xlYXIgZW5vdWdoIHRvIG1lOg0KPiA+Pg0KPiA+PiAiSW4gdGhlIGNvbnRleHQgb2Yg dGhpcyBkb2N1bWVudCB3ZSBzYXkgdGhhdCBhIGxpbmsgaXMgY29ubmVjdGVkDQo+ID4+IHRvIGEg bm9kZSBieSBhbiBpbnRlcmZhY2UuIEluIHRoZSBjb250ZXh0IG9mIEdNUExTIGludGVyZmFjZXMN Cj4gPj4gbWF5IGhhdmUgZGlmZmVyZW50IHN3aXRjaGluZyBjYXBhYmlsaXRpZXMuIEZvciBleGFt cGxlIGFuDQo+ID4+IGludGVyZmFjZSB0aGF0IGNvbm5lY3RzIGEgZ2l2ZW4gbGluayB0byBhIG5v ZGUgbWF5IG5vdCBiZSBhYmxlDQo+ID4+IHRvIHN3aXRjaCBpbmRpdmlkdWFsIHBhY2tldHMsIGJ1 dCBpdCBtYXkgYmUgYWJsZSB0byBzd2l0Y2gNCj4gPj4gY2hhbm5lbHMgd2l0aGluIGFuIFNESCBw YXlsb2FkLiBJbnRlcmZhY2VzIGF0IGVhY2ggZW5kIG9mIGEgbGluaw0KPiA+PiBuZWVkIG5vdCBo YXZlIHRoZSBzYW1lIHN3aXRjaGluZyBjYXBhYmlsaXRpZXMuIEludGVyZmFjZXMgb24gdGhlDQo+ ID4+IHNhbWUgbm9kZSBuZWVkIG5vdCBoYXZlIHRoZSBzYW1lIHN3aXRjaGluZyBjYXBhYmlsaXRp ZXMuIg0KPiA+DQo+ID4gTm90IHN1cmUgaG93IHRoaXMgaGVscHMgY2xhcmlmeSBhbnl0aGluZy4u Lg0KPg0KPiAgW0pEXSBJIHRoaW5rIGl0IGNsYXJpZmllcyB0aGF0IHN3aXRjaGluZyBjYXBhYmls aXRpZXMgaXMgbWVhbnQgdG8NCj4gIGRlc2NyaWJlIGhvdyBhIGdpdmVuIGludGVyZmFjZSBzd2l0 Y2hlcyB0aGUgaW5mb3JtYXRpb24gd2l0aCB3aGljaA0KPiAgaXQgaXMgcHJvdmlkZWQuIFRoaXMg aGFzIG5vdGhpbmcgdG8gZG8gd2l0aCB0aGUgaW50ZXJmYWNlJ3MNCj4gIGJhbmR3aWR0aC4NCj4N Cj4gPg0KPiA+IExvdQ0KPiA+Pg0KPiA+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gRnJv bTogTG91IEJlcmdlcg0KPiA+Pj4gW21haWx0bzpsYmVyZ2VyQGxhYm4ubmV0XSBTZW50OiBXZWRu ZXNkYXksIE5vdmVtYmVyIDMwLCAyMDExDQo+ID4+PiA4OjQzIEFNIFRvOiBKb2huIEUgRHJha2Ug Q2M6IERhbmllbGUgQ2VjY2FyZWxsaTsgQ0NBTVANCj4gPj4+IFN1YmplY3Q6IFJlOiBbQ0NBTVBd IE9TUEYgT1ROIGNvbnNpZGVyYXRpb25zIHBvc3QgSUVURiA4Mg0KPiA+Pj4gKElzc3VlDQo+ID4g MS8yKQ0KPiA+Pj4NCj4gPj4+IEdyZWF0LiBDYXJlIHRvIHN1YnN0YW50aWF0ZSB5b3VyIHBvaW50 Pw0KPiA+Pj4NCj4gPj4+IE9uIDExLzMwLzIwMTEgMTE6MTQgQU0sIEpvaG4gRSBEcmFrZSB3cm90 ZToNCj4gPj4+PiBJIGNvbXBsZXRlbHkgZGlzYWdyZWUuDQo+ID4+Pj4NCj4gPj4+Pj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0gRnJvbTogY2NhbXAtYm91bmNlc0BpZXRmLm9yZw0KPiA+Pj4+ PiBbbWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+ID4+PiBCZWhhbGYNCj4gPj4+ Pj4gT2YgTG91IEJlcmdlciBTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDMwLCAyMDExIDc6MjIg QU0NCj4gPj4+Pj4gVG86IERhbmllbGUgQ2VjY2FyZWxsaSBDYzogQ0NBTVAgU3ViamVjdDogUmU6 IFtDQ0FNUF0gT1NQRg0KPiA+Pj4+PiBPVE4gY29uc2lkZXJhdGlvbnMgcG9zdCBJRVRGIDgyIChJ c3N1ZQ0KPiA+Pj4gMS8yKQ0KPiA+Pj4+Pg0KPiA+Pj4+PiBIaSBEYW5pZWxlLCBTaW5jZSBJIHJh aXNlZCB0aGUgcG9pbnQsIEkgZ3Vlc3MgSSBuZWVkIHRvDQo+ID4+Pj4+IGNoYW1waW9uIGl0ISAo V2l0aCBjaGFpciBoYXQgb2ZmLikNCj4gPj4+Pj4NCj4gPj4+Pj4gQWxsLA0KPiA+Pj4+Pg0KPiA+ Pj4+PiBEYW5pZWxlIHNhaWQ6DQo+ID4+Pj4+PiBXUlQgaXNzdWUgMTogdGhlIHByb3Bvc2FsIHdh cyB0byBpbmRpY2F0ZSB0aGUgYm90dG9tDQo+ID4+Pj4+PiBtb3N0IE9EVWsgb2YNCj4gPj4+IHRo ZQ0KPiA+Pj4+Pj4gbXV4aW5nIGhpZWFyYWNoeSBpbiB0aGUgU3dpdGNoaW5nIENhcGFiaWxpdHkg ZmllbGQgb2YNCj4gPj4+Pj4+IHRoZSBJU0NELg0KPiA+Pj4gQWZ0ZXINCj4gPj4+Pj4+IGEgcXVp Y2sgdGFsayB3aXRoIHRoZSBvdGhlciBhdXRob3JzIG9mIHRoZSBJRCwgdGhlIGlkZWENCj4gPj4+ Pj4+IHdhcyB0bw0KPiA+Pj4gcmVqZWN0DQo+ID4+Pj4+PiB0aGUgcHJvcG9zYWwgYXMgaXQgd291 bGQgbGVhZCB0byBhbiBvdmVybG9hZGluZyBvZiB0aGUNCj4gPj4+Pj4+IG1lYW5pbmcgb2YNCj4g Pj4+IHRoZQ0KPiA+Pj4+Pj4gU3dpdGNoaW5nIENhcGFiaWxpdHkgZmllbGQuIChldmVuIGlmIHRo ZSBkZWZpbml0aW9uIG9mDQo+ID4+Pj4+PiBQU0MxLTItMy00IGFscmVhZHkgb3ZlcmxvYWRzIHRo ZSBtZWFuaW5nIG9mIHRoZQ0KPiA+Pj4+Pj4gc3dpdGNoaW5nIGNhcGFiaWxpdHkgZmllbGQpDQo+ ID4+Pj4+DQo+ID4+Pj4+IFRoaXMgcmVhbGx5IGdvZXMgdG8gdGhlIGludGVycHJldGF0aW9uIG9m IHRoZSBpbnRlbnQgb2YNCj4gPj4+Pj4gU3dpdGNoaW5nIENhcGFiaWxpdHkgVHlwZXMuIFNvIHdl IGhhdmUgYSBmZXcgZGVmaW5pdGlvbnM6DQo+ID4+Pj4+IDM0NzEgc2F5cyAidGhlDQo+ID4gdHlw ZQ0KPiA+Pj4gb2YNCj4gPj4+Pj4gc3dpdGNoaW5nIHRoYXQgc2hvdWxkIGJlIHBlcmZvcm1lZCIs IDQyMDIgc2F5cyAiZGVzY3JpYmVzDQo+ID4gc3dpdGNoaW5nDQo+ID4+Pj4+IGNhcGFiaWxpdHkg b2YgYW4gaW50ZXJmYWNlLiIgMzk0NSBkb2Vzbid0IHJlYWxseSBkZWZpbmUNCj4gPj4+Pj4gdGhl IHRlcm0NCj4gPiAoaXQNCj4gPj4+Pj4ganVzdCByZWZlcmVuY2VzIDQyMDIpLCBidXQgZG9lcyBl cXVhdGUgaXQgd2l0aCBhICJsYXllciIuDQo+ID4+Pj4+IFdoaWxlIGl0IGFsbG93cyBmb3IgaGll cmFyY2h5IHdpdGhpbiBhICJsYXllciIgaXQgYWxzbw0KPiA+Pj4+PiBzYXlzIGhpZXJhcmNoeQ0K PiA+IG9jY3Vycw0KPiA+Pj4+PiAiYmV0d2VlbiBpbnRlcmZhY2UgdHlwZXMiLg0KPiA+Pj4+Pg0K PiA+Pj4+PiBTbyBJIGludGVycHJldCBTd2l0Y2hpbmcgQ2FwYWJpbGl0eSBUeXBlcyB0byByZXBy ZXNlbnQgKGEpDQo+ID4gZGlmZmVyZW50DQo+ID4+Pj4+IHN3aXRjaGluZy90ZWNobm9sb2d5IGxh eWVycyBhbmQgKGIpIGRpZmZlcmVudCBsZXZlbHMgb2YNCj4gPj4+Pj4gaGllcmFyY2h5DQo+ID4g LS0NCj4gPj4+Pj4gZXZlbiB3aXRoaW4gYSBsYXllci4gSSB0aGluayAoYSkgaXMgaWRlbnRpZmlh YmxlIGluIHRoZQ0KPiA+IGRlZmluaXRpb24NCj4gPj4+IG9mDQo+ID4+Pj4+IHRoZSBvcmlnaW5h bCBHTVBMUyBzdXBwb3J0ZWQgdGVjaG5vbG9naWVzIChpLmUuLCBQU0MsDQo+ID4+Pj4+IEwyU0Ms IFRETQ0KPiA+IExTQywNCj4gPj4+Pj4gYW5kIEZTQyksIGFuZCAoYikgaXMgaWRlbnRpZmlhYmxl IGluIHRoZSBvcmlnaW5hbCB0eXBlcw0KPiA+Pj4+PiBwbHVzIHRoZQ0KPiA+Pj4gZGVmaW5pdGlv bg0KPiA+Pj4+PiBvZiBQU0MtMSB0aHJvdWdoIFBTQy00Lg0KPiA+Pj4+Pg0KPiA+Pj4+PiBTbyBo b3cgZG9lcyB0aGlzIGFwcGx5IHRvIG91ciBjdXJyZW50IE9UTiB3b3JrPw0KPiA+Pj4+Pg0KPiA+ Pj4+PiBUbyBtZSwgdGhlIGZpcnN0IHF1ZXN0aW9uIHRvIGFzayByZWxhdGVzIHRvIChhKSwgYW5k IGlzDQo+ID4+Pj4+IHNob3VsZA0KPiA+IGVhY2gNCj4gPj4+Pj4gT0RVayBiZSBtb2RlbGVkIGFz IGEgc2VwYXJhdGUgbGF5ZXI/DQo+ID4+Pj4+DQo+ID4+Pj4+IEkga25vdyB0aGlzIGhhcyBiZWVu IGEgbXVjaCBkZWJhdGVkIHBvaW50LCBhbmQgaXQgc2VlbXMgdG8NCj4gPj4+Pj4gbWUgdGhhdA0K PiA+Pj4gdGhleQ0KPiA+Pj4+PiBhcmUsIGJ1dCBtb3JlIGZvciB0aGUgcGVyc3BlY3RpdmUgb2Yg c3dpdGNoaW5nIGxheWVycyB0aGFuDQo+ID4+PiB0ZWNobm9sb2d5DQo+ID4+Pj4+IGxheWVycyAo aS5lLiwgdGhleSBhcmUgY2xlYXJseSB0aGUgc2FtZSB0ZWNobm9sb2d5IGJ1dCBhcmUNCj4gPiBk aWZmZXJlbnQNCj4gPj4+Pj4gZ3JhbnVsYXJpdHkgb2Ygc3dpY3RoaW5nLikgU28gdGhpcyBpcyBh IHllcyBmb3IgbWUuDQo+ID4+Pj4+DQo+ID4+Pj4+IEkgdGhpbmsgdGhlIHNlY29uZCBxdWVzdGlv biB0byBhc2sgcmVsYXRlcyB0byAoYiksIGFuZCBpcw0KPiA+Pj4+PiBkb2VzDQo+ID4gZWFjaA0K PiA+Pj4+PiBPRFVrIHJlcHJlc2VudCBhIGRpZmZlcmVudCBsZXZlbCBvZiBoaWVyYXJjaHk/DQo+ ID4+Pj4+DQo+ID4+Pj4+IEkgc2VlIHRoaXMgYXMgc2ltcGx5IHllcywgYW5kIG5vIGRpZmZlcmVu dCB0aGFuIHdoYXQgaGFzDQo+ID4+Pj4+IGJlZW4gZG9uZQ0KPiA+Pj4gbW9yZQ0KPiA+Pj4+PiBy ZWNlbnRseSB3aXRoIEV0aGVybmV0IG9yLCBldmVuIGlmIHdlIGRvIGNvbnRpbnVlIHRvIG1vZGVs DQo+ID4+Pj4+IE9UTiBhcw0KPiA+IGENCj4gPj4+Pj4gc2luZ2xlIGxheWVyLCBubyBkaWZmZXJl bnQgdGhhbiBQU0MtMSAtPiBQU0MtNC4NCj4gPj4+Pj4NCj4gPj4+Pj4gVGhlcmUncyBhbHNvIGEg bWlub3IgcHJvY2Vzc2luZyBlZmZpY2llbmN5IGdhaW5lZCBieSB0aGlzDQo+ID4+Pj4+IGFwcHJv YWNoDQo+ID4+PiBmb3INCj4gPj4+Pj4gbm9kZXMgdGhhdCBzdXBwb3J0IGEgc21hbGxlciBzZXQg b2YgT0RVa3MgdGhhbiBhcmUNCj4gPj4+Pj4gYWR2ZXJ0aXNlZA0KPiA+IHdpdGhpbg0KPiA+Pj4g YW4NCj4gPj4+Pj4gSUdQLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBCYXNlZCBvbiBhbGwgdGhpcywgSSBi ZWxpZXZlIGRpZmZlcmVudCBPRFVrJ3Mgc2hvdWxkIHVzZQ0KPiA+Pj4+PiBkaWZmZXJlbnQgU3dp dGNoaW5nIFR5cGVzLiBJbiBwYXJ0aWN1bGFyLCBJJ20gcHJvcG9zaW5nOg0KPiA+Pj4+PiAoMSkg dGhhdCBlaXRoZXIgdGhlIGZyYW1ld29yayBvciBpbmZvIGRvY3VtZW50cyBpZGVudGlmeQ0KPiA+ Pj4+PiB0aGF0IGEgcGVyLU9UVWsgU3dpdGNoaW5nIENhcGFiaWxpdHkgVHlwZXMgd2lsbCBiZSB1 c2VkIHRvDQo+ID4+Pj4+IHN1cHBvcnQgRy43MDl2My4gKDIpIHRoYXQNCj4gPj4+Pj4gZHJhZnQt aWV0Zi1jY2FtcC1nbXBscy1vc3BmLWc3MDl2MyBkZWZpbmUgYSBkaWZmZXJlbnQNCj4gPj4+Pj4g U3dpdGNoaW5nIENhcCBmaWVsZCB2YWx1ZSBmb3IgZWFjaCBPRFVrLCBhbmQgdGhhdCBpdCBzdGF0 ZQ0KPiA+Pj4+PiB0aGF0IHRoZSB2YWx1ZSBjb3JyZXNwb25kaW5nIHRvIHRoZSBzaWduYWwgdHlw ZQ0KPiA+Pj4+PiBpZGVudGlmaWVkIGluIHRoZSAjc3RhZ2VzPTAgb2YgdGhlIElTQ1AgYmUgc2V0 LiAoV2l0aG91dA0KPiA+Pj4+PiBhbnkgb3RoZXIgY2hhbmdlcyB0byB0aGUgY3VycmVudCBkZWZp bml0aW9uIG9mIElTQ0QuKSAoMykNCj4gPj4+Pj4gdGhhdCBkcmFmdC1pZXRmLWNjYW1wLWdtcGxz LXNpZ25hbGluZy1nNzA5djMgYmUgdXBkYXRlZCB0bw0KPiA+Pj4+PiBtYXRjaCBhYm92ZS4NCj4g Pj4+Pj4NCj4gPj4+Pj4gVG8ga2VlcCB0aGlua3MgZ2VuZXJpYywgd2UgcHJvYmFibHkgc2hvdWxk IHVzZSBURE0tMQ0KPiA+Pj4+PiB0aHJvdWdoIFRETS1uDQo+ID4+PiBhcw0KPiA+Pj4+PiB0aGUg bmV3IFN3aXRjaGluZyBDYXBhYmlsaXR5IFR5cGVzLCBidXQgdGhpcyBpcyBhDQo+ID4+Pj4+IHNl Y29uZGFyeQ0KPiA+Pj4gZGlzY3Vzc2lvbi4NCj4gPj4+Pj4NCj4gPj4+Pj4gQ29tbWVudHM/DQo+ ID4+Pj4+DQo+ID4+Pj4+IExvdQ0KPiA+Pj4+Pg0KPiA+Pj4+PiBQUyBXaGlsZSB0aGUgYWJvdmUg aXMgYW4gaW1wb3J0YW50IGNoYW5nZSwgaXQgZG9lc24ndA0KPiA+IHNpZ25pZmljYW50bHkNCj4g Pj4+Pj4gaW1wYWN0IGVuY29kaW5nIGFuZCB3b24ndCB0YWtlIG11Y2ggdGV4dCB0byBtYWtlIHRo ZQ0KPiA+Pj4+PiBhY3R1YWwNCj4gPiBjaGFuZ2UsDQo+ID4+PiBzbw0KPiA+Pj4+PiB0aGlzIGlz IGEgZGlzY3Vzc2lvbiB0aGF0IGNhbiBjb250aW51ZSB1bnRpbCBQYXJpcyBpZiB3ZQ0KPiA+Pj4+ PiByZWFsbHkNCj4gPiBuZWVkDQo+ID4+PiBhDQo+ID4+Pj4+IGZhY2UgdG8gZmFjZSB0byByZXNv bHZlIHRoZSBkaXNjdXNzaW9uLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBPbiAxMS8yMy8yMDExIDE6MTgg UE0sIERhbmllbGUgQ2VjY2FyZWxsaSB3cm90ZToNCj4gPj4+Pj4+IEhpIENDQU1QLA0KPiA+Pj4+ Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gRHVyaW5nIHRoZSBPVE4gT1NQRiBkcmFm dCBwcmVzZW50YXRpb24gYXQgdGhlIElFVEYNCj4gPj4+Pj4+IG1lZXRpbmcgaW4NCj4gPj4+IFRh aXBlaQ0KPiA+Pj4+PiB0d28NCj4gPj4+Pj4+IGNvbW1lbnRzIHdlcmUgcmFpc2VkIHdpdGggcmVz cGVjdCB0byB0aGUgZm9sbG93aW5nDQo+ID4+Pj4+PiBpc3N1ZXM6DQo+ID4+Pj4+Pg0KPiA+Pj4+ Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiAtIElzc3VlIDE6IFVzaW5nIGRpZmZlcmVudCBzd2l0Y2hp bmcgY2FwcyBmb3IgZWFjaCBPRFUNCj4gPj4+Pj4+IHR5cGUNCj4gPj4+Pj4+DQo+ID4+Pj4+PiAt IElzc3VlIDI6IFR5cGUgMiAodW5yZXMgYmFuZHdpZHRoIGZvciB2YXJpYWJsZQ0KPiA+Pj4+Pj4g Y29udGFpbmVycykgYW5kDQo+ID4+PiBUeXBlDQo+ID4+Pj4+IDMNCj4gPj4+Pj4+IChNQVggTFNQ IGJhbmR3aWR0aCBmb2UgdmFyaWFibGUgY29udGFpbmVycyBhbHdheXMgdXNlZA0KPiA+Pj4+Pj4g aW4gdGFuZGVtPw0KPiA+Pj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gV1JUIGlz c3VlIDE6IHRoZSBwcm9wb3NhbCB3YXMgdG8gaW5kaWNhdGUgdGhlIGJvdHRvbQ0KPiA+Pj4+Pj4g bW9zdCBPRFVrIG9mDQo+ID4+PiB0aGUNCj4gPj4+Pj4+IG11eGluZyBoaWVhcmFjaHkgaW4gdGhl IFN3aXRjaGluZyBDYXBhYmlsaXR5IGZpZWxkIG9mDQo+ID4+Pj4+PiB0aGUgSVNDRC4NCj4gPj4+ IEFmdGVyDQo+ID4+Pj4+IGENCj4gPj4+Pj4+IHF1aWNrIHRhbGsgd2l0aCB0aGUgb3RoZXIgYXV0 aG9ycyBvZiB0aGUgSUQsIHRoZSBpZGVhDQo+ID4+Pj4+PiB3YXMgdG8NCj4gPiByZWplY3QNCj4g Pj4+Pj4gdGhlDQo+ID4+Pj4+PiBwcm9wb3NhbCBhcyBpdCB3b3VsZCBsZWFkIHRvIGFuIG92ZXJs b2FkaW5nIG9mIHRoZQ0KPiA+Pj4+Pj4gbWVhbmluZyBvZiB0aGUgU3dpdGNoaW5nIENhcGFiaWxp dHkgZmllbGQuIChldmVuIGlmIHRoZQ0KPiA+Pj4+Pj4gZGVmaW5pdGlvbiBvZiBQU0MxLTItMy00 IGFscmVhZHkgb3ZlcmxvYWRzIHRoZSBtZWFuaW5nDQo+ID4+Pj4+PiBvZiB0aGUgc3dpdGNoaW5n IGNhcGFiaWxpdHkgZmllbGQpDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+ PiBXUlQgaXNzdWUgMjogaXQgaXMgYW5hbHl6ZWQgaW4gc2VjdGlvbiA1LjMgb2YgdGhlIGRyYWZ0 DQo+ID4+Pj4+PiAodmVyc2lvbg0KPiA+IC0NCj4gPj4+Pj4gMDApLg0KPiA+Pj4+Pj4gSSdtIGNv cHlpbmcgaXQgYmVsb3cgZm9yIHlvdXIgY29udmVuaWVuY2UNCj4gPj4+Pj4+DQo+ID4+Pj4+Pg0K PiA+Pj4+Pj4NCj4gPj4+Pj4+IEluIHRoaXMgZXhhbXBsZSB0aGUgYWR2ZXJ0aXNlbWVudCBvZiBh biBPRFVmbGV4LT5PRFUzDQo+ID4gaGllcmFyY2h5DQo+ID4+PiBpcw0KPiA+Pj4+Pj4NCj4gPj4+ Pj4+IHNob3duLiBJbiBjYXNlIG9mIE9EVWZsZXggYWR2ZXJ0aXNlbWVudCB0aGUgTUFYIExTUA0K PiA+Pj4+Pj4gYmFuZHdpZHRoDQo+ID4+Pj4+IG5lZWRzDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gdG8g YmUgYWR2ZXJ0aXNlZCBidXQgaW4gc29tZSBjYXNlcyBhbHNvIGluZm9ybWF0aW9uDQo+ID4+Pj4+ PiBhYm91dCB0aGUNCj4gPj4+Pj4+DQo+ID4+Pj4+PiBVbnJlc2VydmVkIGJhbmR3aWR0aCBjb3Vs ZCBiZSB1c2VmdWwuIFRoZSBhbW91bnQgb2YNCj4gPiBVbnJlc2VydmVkDQo+ID4+Pj4+Pg0KPiA+ Pj4+Pj4gYmFuZHdpZHRoIGRvZXMgbm90IGdpdmUgYSBjbGVhciBpbmRpY2F0aW9uIG9mIGhvdyBt YW55DQo+ID4+Pj4+PiBPRFVmbGV4DQo+ID4+PiBMU1ANCj4gPj4+Pj4+DQo+ID4+Pj4+PiBjYW4g YmUgc2V0IHVwIGVpdGhlciBhdCB0aGUgTUFYIExTUCBCYW5kd2lkdGggb3IgYXQNCj4gPj4+Pj4+ IGRpZmZlcmVudA0KPiA+Pj4+PiByYXRlcywNCj4gPj4+Pj4+DQo+ID4+Pj4+PiBhcyBpdCBnaXZl cyBubyBpbmZvcm1hdGlvbiBhYm91dCB0aGUgc3BhdGlhbCBhbGxvY2F0aW9uDQo+ID4+Pj4+PiBv ZiB0aGUNCj4gPj4+Pj4gZnJlZQ0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IFRTcy4NCj4gPj4+Pj4+DQo+ ID4+Pj4+Pg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IEFuIGluZGljYXRpb24gb2YgdGhlIGFtb3VudCBv ZiBVbnJlc2VydmVkIGJhbmR3aWR0aA0KPiA+Pj4+Pj4gY291bGQgYmUNCj4gPj4+Pj4gdXNlZnVs DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gZHVyaW5nIHRoZSBwYXRoIGNvbXB1dGF0aW9uIHByb2Nlc3Ms IGFzIHNob3duIGluIHRoZQ0KPiA+Pj4+Pj4gZm9sbG93aW5nDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4g ZXhhbXBsZS4gU3VwcG9zaW5nIHRoZXJlIGFyZSB0d28gVEUtbGlua3MgKEEgYW5kIEIpDQo+ID4+ Pj4+PiB3aXRoIE1BWA0KPiA+Pj4gTFNQDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gQmFuZHdpZHRoIGVx dWFsIHRvIDEwIEdicHMgZWFjaC4gSW4gY2FzZSA1MEdicHMgb2YNCj4gPj4+Pj4+IFVucmVzZXJ2 ZWQNCj4gPj4+Pj4+DQo+ID4+Pj4+PiBCYW5kd2lkdGggYXJlIGF2YWlsYWJsZSBvbiBMaW5rIEEs IDEwR2JwcyBvbiBMaW5rIEIgYW5kDQo+ID4+Pj4+PiAzDQo+ID4+PiBPRFVmbGV4DQo+ID4+Pj4+ Pg0KPiA+Pj4+Pj4gTFNQcyBvZiAxMCBHQnBzIGVhY2gsIGhhdmUgdG8gYmUgcmVzdG9yZWQsIGZv ciBzdXJlIG9ubHkNCj4gPj4+Pj4+IG9uZQ0KPiA+IGNhbg0KPiA+Pj4+PiBiZQ0KPiA+Pj4+Pj4N Cj4gPj4+Pj4+IHJlc3RvcmVkIGFsb25nIExpbmsgQiBhbmQgaXQgaXMgcHJvYmFibGUgKGJ1dCBu b3Qgc3VyZSkNCj4gPj4+Pj4+IHRoYXQNCj4gPiB0d28NCj4gPj4+Pj4gb2YNCj4gPj4+Pj4+DQo+ ID4+Pj4+PiB0aGVtIGNhbiBiZSByZXN0b3JlZCBhbG9uZyBMaW5rIEEuDQo+ID4+Pj4+Pg0KPiA+ Pj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBFYXJseSBwcm9wb3NhbCB3YXMgdG8gaGF2ZSwgaW4g dGhlIGNhc2Ugb2YgdmFyaWFibGUNCj4gPj4+Pj4+IGNvbnRhaW5lcnMgYWR2ZXJ0aXNlbWVudHMg KGkuZS4gT0RVZmxleCksIHRoZSBNQVggTFNQDQo+ID4+Pj4+PiBiYW5kd2lkdGggVExWIChUeXBl IDMpDQo+ID4+PiBhcw0KPiA+Pj4+PiBhDQo+ID4+Pj4+PiBtYW5kYXRvcnkgcGllY2Ugb2YgaW5m b3JtYXRpb24gYW5kIHRoZSBVbnJlc2VydmVkDQo+ID4+Pj4+PiBiYW5kaXdkdGggVExWDQo+ID4+ PiAoVHlwZQ0KPiA+Pj4+PiAyKQ0KPiA+Pj4+Pj4gYXMgYW4gb3B0aW9uYWwgcGllY2Ugb2YgaW5m b3JtYXRpb24uDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gVGhlIGNvbW1lbnQgcmVjZWl2ZWQgaXMgdGhh dCBvcHRpb25hbCBpbmZvcm1hdGlvbiBjYW4NCj4gPj4+Pj4+IGxlYWQgdG8gaW50ZXJ3b3JraW5n IGlzc3VlcyBhbmQgdGhlIGNvdW50ZXIgcHJvcG9zYWwgd2FzDQo+ID4+Pj4+PiB0byBoYXZlIGJv dGgNCj4gPj4+IHBpZWNlcw0KPiA+Pj4+PiBvZg0KPiA+Pj4+Pj4gaW5mb3JtYXRpb24gYXMgbWFu ZGF0b3J5IGFuZCwgYXMgYSBjb25zZXF1ZW5jZSwgbWVyZ2UNCj4gPj4+Pj4+IHRoZSB0d28NCj4g PiBUTFZzDQo+ID4+Pj4+IGludG8NCj4gPj4+Pj4+IGEgc2luZ2xlIG9uZS4NCj4gPj4+Pj4+DQo+ ID4+Pj4+Pg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IFdlJ2QgbGlrZSB0byBoZWFyIHRoZSBvcGluaW9u IG9mIHRoZSBXRyBvbiBib3RoIGlzc3Vlcw0KPiA+Pj4+Pj4gYmVmb3JlDQo+ID4+Pj4+IHByb2Nl ZWRpbmcNCj4gPj4+Pj4+IHdpdGggYW55IG1vZGlmaWNhdGlvbiB0byB0aGUgZG9jdW1lbnQuDQo+ ID4+Pj4+Pg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBUaGFua3MsDQo+ID4+Pj4+Pg0K PiA+Pj4+Pj4gRGFuaWVsZQ0KPiA+Pj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4N Cj4gPj4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gKkRBTklFTEUgQ0VDQ0FSRUxMSSAqICpTeXN0 ZW0gJiBUZWNobm9sb2d5IC0gRFUgSVAgJg0KPiA+Pj4+Pj4gQnJvYWRiYW5kKg0KPiA+Pj4+Pj4N Cj4gPj4+Pj4+DQo+ID4+Pj4+PiBWaWEgTC5DYWxkYSwgNSBHZW5vdmEsIEl0YWx5IFBob25lICsz OTAxMDYwMDI1MTIgTW9iaWxlDQo+ID4+Pj4+PiArMzkzMzQ2NzI1NzUwIGRhbmllbGUuY2VjY2Fy ZWxsaUBlcmljc3Nvbi5jb20NCj4gPj4+Pj4+IHd3dy5lcmljc3Nvbi5jb20NCj4gPj4+Pj4+DQo+ ID4+Pj4+Pg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IDxodHRwOi8vd3d3LmVyaWNzc29uLmNvbS8+DQo+ ID4+Pj4+Pg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IFRoaXMgQ29tbXVuaWNhdGlvbiBpcyBDb25maWRl bnRpYWwuIFdlIG9ubHkgc2VuZCBhbmQNCj4gPj4+Pj4+IHJlY2VpdmUNCj4gPiBlbWFpbA0KPiA+ Pj4gb24NCj4gPj4+Pj4+IHRoZSBiYXNpcyBvZiB0aGUgdGVybSBzZXQgb3V0IGF0DQo+ID4gd3d3 LmVyaWNzc29uLmNvbS9lbWFpbF9kaXNjbGFpbWVyDQo+ID4+Pj4+PiA8aHR0cDovL3d3dy5lcmlj c3Nvbi5jb20vZW1haWxfZGlzY2xhaW1lcj4NCj4gPj4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4N Cj4gPj4+Pj4+DQo+ID4+Pj4+Pg0KPg0KPiAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18gQ0NBTVAgbWFpbGluZyBsaXN0DQo+ICBDQ0FNUEBpZXRmLm9yZyBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1w From harai@nict.go.jp Thu Dec 8 09:01:25 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB44021F8B63; Thu, 8 Dec 2011 09:01:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.598 X-Spam-Level: * X-Spam-Status: No, score=1.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, J_CHICKENPOX_13=0.6, J_CHICKENPOX_21=0.6, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nEHPw19xurLV; Thu, 8 Dec 2011 09:01:25 -0800 (PST) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:df0:232:300::1]) by ietfa.amsl.com (Postfix) with ESMTP id C10F621F8B61; Thu, 8 Dec 2011 09:01:24 -0800 (PST) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id pB8H1Nhb005098; Fri, 9 Dec 2011 02:01:23 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id pB8H1NAI021616; Fri, 9 Dec 2011 02:01:23 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id pB8H1Nsv021613; Fri, 9 Dec 2011 02:01:23 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 503B02137; Fri, 9 Dec 2011 02:01:23 +0900 (JST) Received: from localhost (skigoggle.nict.go.jp [133.243.146.51]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 49DB7205A; Fri, 9 Dec 2011 02:01:23 +0900 (JST) Date: Fri, 09 Dec 2011 02:01:12 +0900 (JST) Message-Id: <20111209.020112.1568838937885766362.harai@nict.go.jp> To: ccamp@ietf.org, pce@ietf.org, mpls@ietf.org, mpls-tp@ietf.org From: Hiroaki Harai X-Mailer: Mew version 6.3 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-7 Content-Transfer-Encoding: base64 Cc: iPOP2011-tpc-sec@pilab.jp Subject: [Pce] iPOP2012 Call for Presentation X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 17:01:26 -0000 KEFwb2xvZ2llcyBpZiB5b3UgcmVjZWl2ZWQgbXVsdGlwbGUgY29waWVzIG9mIHRoaXMgbWVzc2Fn ZS4pDQoNCkRlYXIgQ0NBTVAsIFBDRSwgTVBMUyBhbmQgTVBMUy1UUCBzdWJzY3JpYmVycywNCg0K aVBPUDIwMTIgQ2FsbCBmb3IgUHJlc2VudGF0aW9uIGlzIG5vdyBvcGVuIGFzIGZvbGxvd3MuDQpU aGUgZGVhZGxpbmUgZm9yIHN1Ym1pdHRpbmcgcHJlc2VudGF0aW9uIHByb3Bvc2FsIGlzIEZlYnJ1 YXJ5IDE1dGgsIDIwMTIuDQoNCkJlc3QgUmVnYXJkcywNCkhpcm9ha2kgSGFyYWkNCg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQogICAgICAgICAgICAgICAgICAgICBDYWxsIGZvciBQcmVzZW50YXRpb24NCg0KOHRo IEludGVybmF0aW9uYWwgQ29uZmVyZW5jZSBvbiBJUCArIE9wdGljYWwgTmV0d29yayAoaVBPUCAy MDEyKQ0KICAgICAgICAgICAgICAgICAgICAgICAgIE1heSAzMSAtIEp1bmUgMSwgMjAxMg0KICAg ICBIaXlvc2hpIENhbXB1cywgS2VpbyBVbml2ZXJzaXR5LCBZb2tvaGFtYS1zaGksIEthbmFnYXdh LCBKYXBhbg0KICAgICAgICAgICAgICAgICAgaHR0cDovL3d3dy5waWxhYi5qcC9pcG9wMjAxMi8N Cg0KVGhlIGNvbmZlcmVuY2UgaXMgaW50ZW5kZWQgdG8gc2hhcmUgYW1vbmcgdGhlIGluZHVzdHJ5 IGFuZCB0aGUgYWNhZGVtaWEsDQp0aGUga25vd2xlZGdlLCBuZXcgZmluZGluZ3MsIGFuZCBleHBl cmllbmNlIG9uIHRoZSBzdGF0ZS1vZi10aGUgYXJ0IG9mDQpJUCBhbmQgb3B0aWNhbCBuZXR3b3Jr aW5nIHRlY2hub2xvZ2llcy4gSXQgZmVhdHVyZXMgdGVjaG5pY2FsIHNlc3Npb25zDQphbmQgcGxh bm5lZCBleGhpYml0aW9ucy4gVGhlIG9wcG9ydHVuaXR5IHRvIHBhcnRpY2lwYXRlIGlzIG9wZW4g dG8gYWxsLg0KDQpJbXBvcnRhbnQgRGF0ZXM6DQpTdWJtaXNzaW9uIGRlYWRsaW5lIG9mIG9uZS1w YWdlIGFic3RyYWN0OiBGZWJydWFyeSAxNSwgMjAxMiANCk5vdGlmaWNhdGlvbiBvZiBhY2NlcHRh bmNlOiBNYXJjaCAzMCwgMjAxMg0KU3VibWlzc2lvbiBkZWFkbGluZSBvZiBmaW5hbCBwcmVzZW50 YXRpb24gc2xpZGVzOiBBcHJpbCAyMCwgMjAxMg0KDQpUaGUgVGVjaG5pY2FsIFByb2dyYW0gQ29t bWl0dGVlIGZvciBpUE9QIDIwMTIgaXMgc29saWNpdGluZyBwcmVzZW50YXRpb24gDQpwcm9wb3Nh bHMgZm9yIHRoaXMgY29uZmVyZW5jZS4gUHJvdG9jb2wgZGVzaWduLCBleHBlcmltZW50LCB0aGVv cnksIA0KaW1wbGVtZW50YXRpb24sIGFuZCBvcGVyYXRpb25hbCBleHBlcmllbmNlcyBhcmUgc29s aWNpdGVkLg0KVGhlIHRvcGljcyBvZiB0aGUgY29uZmVyZW5jZSB3aWxsIGluY2x1ZGUgYnV0IG5v dCBiZSBsaW1pdGVkIHRvIHRoZSBmb2xsb3dpbmc6DQoNCiogUGhvdG9uaWMgTmV0d29yayBmb3Ig TnhHTiBhbmQgTndHTg0KKiBNdWx0aS1sYXllciBuZXR3b3JrIChNTE4pIC8gTXVsdGktcmVnaW9u IG5ldHdvcmsgKE1STikNCiogSW50ZXItYXJlYS9JbnRlci1BUyBuZXR3b3JrDQoqIFdhdmVsZW5n dGggU3dpdGNoZWQgT3B0aWNhbCBOZXR3b3JrcyAoV1NPTiksIFJvdXRpbmcgd2F2ZWxlbmd0aCBh c3NpZ25tZW50LA0KICBJbXBhaXJtZW50IG1hbmFnZW1lbnQNCiogR01QTFMvQVNPTiB0ZWNobm9s b2dpZXMNCiogR01QTFMgTmV0d29yayBtYW5hZ2VtZW50LCBPQSZNDQoqIEdNUExTLWNvbnRyb2xs ZWQgRXRoZXJuZXQgTGFiZWwgU3dpdGNoaW5nIChHRUxTKSBhbmQgcmVsYXRlZCBFdGhlcm5ldA0K ICB0cmFuc3BvcnQgdGVjaG5vbG9naWVzDQoqIFBhdGggQ29tcHV0YXRpb24gRWxlbWVudCAoUENF KSwgVHJhZmZpYyBlbmdpbmVlcmluZw0KKiBBcHBsaWNhdGlvbiB3aXRoIGhpZ2gtYmFuZHdpZHRo IGRlbWFuZA0KKiBMMVZQTiwgQmFuZHdpZHRoIG9uIERlbWFuZCwgYW5kIFBob3RvbmljIEdyaWQN CiogTVBMUyBhbmQgRXRoZXJuZXQgbmV0d29ya2luZyBmb3IgSW50ZXItZGF0YSBjZW50ZXIgY29u bmVjdGl2aXR5IGZvciBjbG91ZA0KICBjb21wdXRpbmcNCiogQ2FycmllciBFdGhlcm5ldCBhbmQg TVBMUy1UUCBmb3IgYmFja2hhdWxpbmcNCiogVGVzdGJlZCwgZmllbGQgdHJpYWwNCg0KDQpJZiB5 b3Ugd2lzaCB0byBzdWJtaXQgYSB0b3BpYyBmb3IgY29uc2lkZXJhdGlvbiwgcGxlYXNlIHNlbmQg YW4gRXh0ZW5kZWQgDQpBYnN0cmFjdHMgb2YgNDAwIHdvcmRzIGFuZCBhIG1heGltdW0gb2YgMSBw YWdlLCBpbmNsdWRpbmcgZmlndXJlcyBhbmQgDQpkaWFncmFtcywgc3BlYWtlcqJzIG5hbWUsIGFm ZmlsaWF0aW9uLCBhbmQgY29udGFjdCBpbmZvcm1hdGlvbiANCnRvIHRoZSBUZWNobmljYWwgUHJv Z3JhbSBDb21taXR0ZWUgYXQgaXBvcDIwMTItQ0ZQQHBpbGFiLmpwLg0KUGxlYXNlIHNlZSBodHRw Oi8vd3d3LnBpbGFiLmpwL2lwb3AyMDEyLyBmb3IgbW9yZSBkZXRhaWxzLg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cg0K From dhruv.dhody@huawei.com Wed Dec 14 21:07:03 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 239F321F8AD2 for ; Wed, 14 Dec 2011 21:07:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XYVcvikmU1PL for ; Wed, 14 Dec 2011 21:07:01 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id C368C21F8ABD for ; Wed, 14 Dec 2011 21:07:00 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LW800ELGBHT79@szxga05-in.huawei.com> for pce@ietf.org; Thu, 15 Dec 2011 13:05:54 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LW8007YQBHTZX@szxga05-in.huawei.com> for pce@ietf.org; Thu, 15 Dec 2011 13:05:53 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFV45166; Thu, 15 Dec 2011 13:05:52 +0800 Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 15 Dec 2011 13:05:34 +0800 Received: from BLRNSHTIPL1NC (10.18.1.31) by szxeml411-hub.china.huawei.com (10.82.67.138) with Microsoft SMTP Server id 14.1.323.3; Thu, 15 Dec 2011 13:05:37 +0800 Date: Thu, 15 Dec 2011 10:35:36 +0530 From: Dhruv Dhody In-reply-to: <20111215045356.7420.61238.idtracker@ietfa.amsl.com> X-Originating-IP: [10.18.1.31] To: pce@ietf.org Message-id: Organization: HTIPL MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.4862 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_pLslg108+OFYUAKM1M051Q)" Thread-index: Acy65Y842vrJeE8oQ0KIqt4l9dqm9gAAIuwg X-CFilter-Loop: Reflected References: <20111215045356.7420.61238.idtracker@ietfa.amsl.com> Cc: vishwas.manral@hp.com Subject: Re: [Pce] New Version Notification for draft-dhody-pce-pcep-service-aware-02.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dhruv.dhody@huawei.com List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2011 05:07:03 -0000 --Boundary_(ID_pLslg108+OFYUAKM1M051Q) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi PCErs, We have updated the draft for Service Aware PCEP. [http://www.ietf.org/id/draft-dhody-pce-pcep-service-aware-02.txt] Main Changes - (1) Details added for a. inter-domain b. inter-layer c. re-optimization (2) Updated Reference (3) Editorial changes Differences: [http://tools.ietf.org/rfcdiff?url1=draft-dhody-pce-pcep-service-aware-01&di fftype=--html&submit=Go%21&url2=draft-dhody-pce-pcep-service-aware-02] Request WG to provide comments. Regards, Dhruv **************************************************************************** *********** Dhruv Dhody, Senior Technical Leader, Huawei Technologies, Bangalore, India, Ph. +91-9845062422 This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Thursday, December 15, 2011 10:24 AM To: dhruv.dhody@huawei.com Cc: vishwas.manral@hp.com; dhruv.dhody@huawei.com Subject: New Version Notification for draft-dhody-pce-pcep-service-aware-02.txt A new version of I-D, draft-dhody-pce-pcep-service-aware-02.txt has been successfully submitted by Dhruv Dhody and posted to the IETF repository. Filename: draft-dhody-pce-pcep-service-aware Revision: 02 Title: Extensions to the Path Computation Element Communication Protocol (PCEP) to compute service aware Label Switched Path (LSP). Creation date: 2011-12-15 WG ID: Individual Submission Number of pages: 12 Abstract: In certain networks like financial information network (stock/ commodity trading) and enterprises using cloud based applications, Latency (delay), Latency-Variation (jitter) and Packet loss is becoming a key requirement for path computation along with other constraints and metrics. Latency, Latency-Variation and Packet Loss is associated with the Service Level Agreement (SLA) between customers and service providers. [MPLS-DELAY-FWK] describes MPLS architecture to allow latency, loss and jittering as properties. [OSPF-TE-EXPRESS] and [ISIS-TE-EXPRESS] describes mechanisms with which network performance information is distributed via OSPF and ISIS respectivily. This document describes the extension to PCEP to carry Latency, Latency-Variation and Loss as constraints for end to end path computation. The IETF Secretariat --Boundary_(ID_pLslg108+OFYUAKM1M051Q) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi PCErs,

 

We have updated the draft for Service Aware PCEP. [http://www.ietf.org/id/draft-dhody-pce-pcep-service-aware-02.txt]

 

Main Changes –

(1)         Details added for

a.       inter-domain

b.      inter-layer

c.       re-optimization

(2)        Updated Reference

(3)        Editorial changes

 

Differences:

[http://tools.ietf.org/rfcdiff?url1=draft-dhody-pce-pcep-service-aware-01&difftype=--html&submit=Go%21&url2=draft-dhody-pce-pcep-service-aware-02]

 

Request WG to provide comments…

 

Regards,

Dhruv

 

***************************************************************************************

Dhruv Dhody, Senior Technical Leader, Huawei Technologies, Bangalore, India, Ph. +91-9845062422

 

This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

 

-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Thursday, December 15, 2011 10:24 AM
To: dhruv.dhody@huawei.com
Cc: vishwas.manral@hp.com; dhruv.dhody@huawei.com
Subject: New Version Notification for draft-dhody-pce-pcep-service-aware-02.txt

 

A new version of I-D, draft-dhody-pce-pcep-service-aware-02.txt has been successfully submitted by Dhruv Dhody and posted to the IETF repository.

 

Filename:   draft-dhody-pce-pcep-service-aware

Revision:   02

Title:            Extensions to the Path Computation Element Communication Protocol (PCEP) to compute service aware Label Switched Path (LSP).

Creation date:    2011-12-15

WG ID:            Individual Submission

Number of pages: 12

 

Abstract:

   In certain networks like financial information network (stock/

   commodity trading) and enterprises using cloud based applications,

   Latency (delay), Latency-Variation (jitter) and Packet loss is

   becoming a key requirement for path computation along with other

   constraints and metrics.  Latency, Latency-Variation and Packet Loss

   is associated with the Service Level Agreement (SLA) between

   customers and service providers.

 

   [MPLS-DELAY-FWK] describes MPLS architecture to allow latency, loss

   and jittering as properties.  [OSPF-TE-EXPRESS] and [ISIS-TE-EXPRESS]

   describes mechanisms with which network performance information is

   distributed via OSPF and ISIS respectivily.  This document describes

   the extension to PCEP to carry Latency, Latency-Variation and Loss as

   constraints for end to end path computation.

 

                                                                                 

 

 

The IETF Secretariat

--Boundary_(ID_pLslg108+OFYUAKM1M051Q)-- From leeyoung@huawei.com Wed Dec 21 15:58:09 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74AEB11E80D0 for ; Wed, 21 Dec 2011 15:58:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYE6hbs1j9PN for ; Wed, 21 Dec 2011 15:58:06 -0800 (PST) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB9311E8096 for ; Wed, 21 Dec 2011 15:58:06 -0800 (PST) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id ABZ91777; Wed, 21 Dec 2011 18:58:06 -0500 (EST) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 21 Dec 2011 15:56:26 -0800 Received: from DFWEML508-MBS.china.huawei.com ([169.254.9.237]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0270.001; Wed, 21 Dec 2011 15:56:29 -0800 From: Leeyoung To: "pce@ietf.org" Thread-Topic: Call for Papers for the "International Workshop on Cross-Stratum Optimization for Cloud Computing and Distributed Networked Applications" Thread-Index: AczAIDG58OQ3/aJORk+S8Eiy29vosgAG6YuQAAAQBJA= Date: Wed, 21 Dec 2011 23:56:28 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1718B3FE72@dfweml508-mbs.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.153.240] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E1718B3FE72dfweml508mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [Pce] Call for Papers for the "International Workshop on Cross-Stratum Optimization for Cloud Computing and Distributed Networked Applications" X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 23:58:09 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E1718B3FE72dfweml508mbschi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [Apologies if you receive multiple copies of this message] First Call for Papers for the "International Workshop on Cross-Stratum Opti= mization for Cloud Computing and Distributed Networked Applications" http://cccso.net/ Co-located with the 10th IEEE International Symposium on Parallel and Distr= ibuted Processing with Applications, ISPA 2012 http://www.arcos.inf.uc3m.es/ispa12/index.shtml July 10-13, 2012 Leganes, Madrid, Spain Aims and Scope =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The current lack of interaction between networked applications and the unde= rlying network during service provisioning cause inefficiencies on the use = of network resources which can negatively impact the quality expectations o= f the final consumers of those applications. Typical networked applications are offered through Information Technology (= IT) resources (as computing and storage facilities) residing in data center= s. Data centers then provide the physical and virtual infrastructure in whi= ch applications and services are provided. Since the data centers are usual= ly distributed geographically around a network, many decisions made in the = control and management of application services, such as where to instantiat= e another service instance, or which data center out of several is assigned= to a new customer, can have a significant impact on the state of the netwo= rk. In the same way, the capabilities and state of the network can have a m= ajor impact on application performance. Cross-stratum optimization (CSO) is referred to the combined optimization o= f both the application and the network components that aims to provide join= t resource optimization, responsiveness to quickly changing demands from/to= application to/from network, enhanced service resilience using cooperative= recovery techniques, and quality of experience assurance by a better use o= f existing network and application resources, among others. The CSO involves the overall optimization of application layer and network = resources by envisioning next generation architecture for interactions and = exchanges between the two layers to improve service continuity, performance= guarantees, scalability and manageability. The goal of this workshop is to= promote the research interest on the optimal integration of application an= d network resources. This workshop aims to explore the challenges and issues faced by cloud comp= uting and data center integration with networks. Among the key areas of inv= estigation to be discussed in the workshop are as follows: .- Application/network integration architectures and subsystems .- Use cases, business models and requirements for application/network inte= gration .- Control/management issues for application/network integration .- Network virtualization and its impact for application/network integratio= n .- Network-aware application/cloud computing .- Flexible and scalable networking solutions for distributed Data Centers .- Joint application/network reliability and security .- Experimental/trial experience .- Scalability .- Joint/shared performance and fault monitoring .- Multi-domain issues Important Dates =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Paper Submission Deadline: 03 February 2012 Paper Acceptance Notification: 30 March 2012 Camera-ready Paper Submissions: 13 April 2012 Tentative workshop day: 10 July 2012 (to be confirmed) Venue =3D=3D=3D=3D=3D Universidad Carlos III de Madrid, Leganes, Spain Submision guidelines =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Target papers should describe original and unpublished work. The submission= process will be done online by using EasyChair submission system: http://www.easychair.org/conferences/?conf=3Dispa2012 choosing this workshop among the various workshops held in conjunction with= ISPA-2012 Details on the paper format and length will be provided soon. Technical Program Committee =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Richard Alimi (Google, USA) Greg Bernstein (Grotto Networking, USA) TaeSang Choi (ETRI, Korea) Nicola Ciulli (Nextworks, Italy) Oscar Gonzalez de Dios (Telef=F3nica I+D, Spain) Volker Hilt (Bell Labs, USA) Giada Landi (Nextworks, Italy) Dan Li (Huawei, China) Thomas D. Nadeau (CA Technologies, USA) Kohei Shiomoto (NTT, Japan) Ning So (Verizon, USA) Hui Yang (Beijing University Post and Telecommunication (BUPT), China) Yang Richard Yang (Yale University, USA) Workshop Organizing Committee =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Young Lee, Huawei Technologies (leeyoung (at) huawei.com) Luis M. Contreras, Telef=F3nica I+D (lmcm (at) tid.es) Andrea Fumagalli, The University of Texas at Dallas (andreaf (at) utdallas.= edu) ______________ Young Lee Huawei Technologies --_000_7AEB3D6833318045B4AE71C2C87E8E1718B3FE72dfweml508mbschi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

[Apologies if you receive multiple copies of this me= ssage]

 

First Call for Papers for the “International W= orkshop on Cross-Stratum Optimization for Cloud Computing and Distributed N= etworked Applications”

http://cccso.net/

 

Co-located with the 10th IEEE International Symposiu= m on Parallel and Distributed Processing with Applications, ISPA 2012<= /o:p>

http://www.arcos.inf.uc3m.es/ispa12/index.shtml=

July 10-13, 2012

Leganes, Madrid, Spain

 

Aims and Scope

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The current lack of interaction between networked ap= plications and the underlying network during service provisioning cause ine= fficiencies on the use of network resources which can negatively impact the= quality expectations of the final consumers of those applications.

 

Typical networked applications are offered through I= nformation Technology (IT) resources (as computing and storage facilities) = residing in data centers. Data centers then provide the physical and virtua= l infrastructure in which applications and services are provided. Since the data centers are usually distributed = geographically around a network, many decisions made in the control and man= agement of application services, such as where to instantiate another servi= ce instance, or which data center out of several is assigned to a new customer, can have a significant impac= t on the state of the network. In the same way, the capabilities and state = of the network can have a major impact on application performance.

 

Cross-stratum optimization (CSO) is referred to the = combined optimization of both the application and the network components th= at aims to provide joint resource optimization, responsiveness to quickly c= hanging demands from/to application to/from network, enhanced service resilience using cooperative recovery te= chniques, and quality of experience assurance by a better use of existing n= etwork and application resources, among others.

 

The CSO involves the overall optimization of applica= tion layer and network resources by envisioning next generation architectur= e for interactions and exchanges between the two layers to improve service = continuity, performance guarantees, scalability and manageability. The goal of this workshop is to promote the= research interest on the optimal integration of application and network re= sources.

 

This workshop aims to explore the challenges and iss= ues faced by cloud computing and data center integration with networks. Amo= ng the key areas of investigation to be discussed in the workshop are as fo= llows:           &nb= sp; 

 

.- Application/network integration architectures and= subsystems

.- Use cases, business models and requirements for a= pplication/network integration

.- Control/management issues for application/network= integration

.- Network virtualization and its impact for applica= tion/network integration

.- Network-aware application/cloud computing

.- Flexible and scalable networking solutions for di= stributed Data Centers

.- Joint application/network reliability and securit= y

.- Experimental/trial experience

.- Scalability

.- Joint/shared performance and fault monitoring

.- Multi-domain issues

 

Important Dates

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Paper Submission Deadline: 03 February 2012

Paper Acceptance Notification: 30 March 2012

Camera-ready Paper Submissions: 13 April 2012

Tentative workshop day: 10 July 2012 (to be confirme= d)

 

Venue

=3D=3D=3D=3D=3D<= /p>

Universidad Carlos III de Madrid, = Leganes, Spain

 

Submision guidelines

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

Target papers should describe original and unpublish= ed work. The submission process will be done online by using EasyChair subm= ission system:

http://www.easychair.org/conferences/?conf=3Dispa201= 2

choosing this workshop among the various workshops h= eld in conjunction with ISPA-2012

Details on the paper format and length will be provi= ded soon.

 

Technical Program Committee

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Richard Alimi (Google, USA)

Greg Bernstein (Grotto Networking, USA)

TaeSang Choi (ETRI, Korea)

Nicola Ciulli (Nextworks, Italy)

Oscar Gonzalez de Dios (Telef=F3ni= ca I+D, Spain)

Volker Hilt (Bell Labs, USA)

Giada Landi (Nextworks, Italy)

Dan Li (Huawei, China)

Thomas D. Nadeau (CA Technologies, USA)

Kohei Shiomoto (NTT, Japan)

Ning So (Verizon, USA)

Hui Yang (Beijing University Post and Telecommunicat= ion (BUPT), China)

Yang Richard Yang (Yale University, USA)<= /p>

 

Workshop Organizing Committee

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Young Lee, Huawei Technologies (leeyoung (at) huawei= .com)

Luis M. Contreras, Telef=F3nica I&= #43;D (lmcm (at) tid.es)

Andrea Fumagalli, The University of Texas at Dallas = (andreaf (at) utdallas.edu)

 

______________

Young Lee<= o:p>

Huawei Tec= hnologies

--_000_7AEB3D6833318045B4AE71C2C87E8E1718B3FE72dfweml508mbschi_--