iPOP2005 Call for Presentation and Exhibition
"K. Miyazaki" <miyazaki.keiji@jp.fujitsu.com> Mon, 01 November 2004 02:42 UTC
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26541 for <ccamp-archive@ietf.org>; Sun, 31 Oct 2004 21:42:04 -0500 (EST)
Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COSNe-0002iO-Mb for ccamp-archive@ietf.org; Sun, 31 Oct 2004 21:57:25 -0500
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CORrN-000Ag5-R8 for ccamp-data@psg.com; Mon, 01 Nov 2004 02:23:53 +0000
Received: from [192.51.44.35] (helo=fgwmail5.fujitsu.co.jp) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CORrM-000Afj-C5 for ccamp@ops.ietf.org; Mon, 01 Nov 2004 02:23:52 +0000
Received: from m3.gw.fujitsu.co.jp ([10.0.50.73]) by fgwmail5.fujitsu.co.jp (8.12.10/Fujitsu Gateway) id iA12NoOP027181 for <ccamp@ops.ietf.org>; Mon, 1 Nov 2004 11:23:51 +0900 (envelope-from miyazaki.keiji@jp.fujitsu.com)
Received: from s0.gw.fujitsu.co.jp by m3.gw.fujitsu.co.jp (8.12.10/Fujitsu Domain Master) id iA12Nolr015368 for <ccamp@ops.ietf.org>; Mon, 1 Nov 2004 11:23:50 +0900 (envelope-from miyazaki.keiji@jp.fujitsu.com)
Received: from s0.gw.fujitsu.co.jp (s0 [127.0.0.1]) by s0.gw.fujitsu.co.jp (Postfix) with ESMTP id 18A86A7D04 for <ccamp@ops.ietf.org>; Mon, 1 Nov 2004 11:23:50 +0900 (JST)
Received: from dm.kawasaki.flab.fujitsu.co.jp (dm.kawasaki.flab.fujitsu.co.jp [10.25.192.1]) by s0.gw.fujitsu.co.jp (Postfix) with ESMTP id B5692A7D0B for <ccamp@ops.ietf.org>; Mon, 1 Nov 2004 11:23:49 +0900 (JST)
Received: from dm.kawasaki.flab.fujitsu.co.jp by dm.kawasaki.flab.fujitsu.co.jp (8.9.3p2/3.7W-041025-Fujitsu Labs. Kawasaki Domain Mail Master (NAVGW)) id LAA01226; Mon, 1 Nov 2004 11:23:49 +0900 (JST)
Received: from [10.25.144.201] ([10.25.144.201]) by dm.kawasaki.flab.fujitsu.co.jp (NAVGW 2.5.2.9) with SMTP id M2004110111234906142 ; Mon, 01 Nov 2004 11:23:49 +0900
Message-ID: <41859E35.3080303@jp.fujitsu.com>
Date: Mon, 01 Nov 2004 11:23:49 +0900
From: "K. Miyazaki" <miyazaki.keiji@jp.fujitsu.com>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: ja, en-us, en
MIME-Version: 1.0
To: ccamp@ops.ietf.org
Subject: iPOP2005 Call for Presentation and Exhibition
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb
Content-Transfer-Encoding: 7bit
CALL FOR PRESENTATION AND EXHIBITION **************************************************************** The International Conference on IP + Optical Network (iPOP 2005) **************************************************************** GMPLS Interoperability Public Demonstration, Exhibition and Conference$B!!(B Tokyo,$B!!(BJapan, February 21-22, 2005 http://www.pilab.org/ipop2005/ Sponsored by PIL(Photonic Internet Lab), ISOCORE, and PIF(Photonic Internet Forum) ----------------------------------------------------------------------- The international conference on IP + Optical network (iPOP 2005) will be held at the Tokyo Fashion Town (TFT) Hall in Tokyo, Japan, from February 21 to February 22, 2005. The conference is intended to share among the industry and the academia communities, the knowledge, new findings, and experience on the state-of-the art of IP and optical networking technologies. It features a public demonstration of GMPLS interoperability showcase by world-wide vendors, including Protection/Restoration and Multi-layer interworking, novel GMPLS product exhibitions, and technical sessions. The opportunity to participate in the showcase is open to all vendors. ----------------------------------------------------------------------- ============================================= CALL FOR GMPLS INTEROPERABILITY PARTICIPATORS ============================================= iPOP 2005 is soliciting participation proposals for its GMPLS interoperability showcase, in addition to PIL and ISOCORE member companies. The topics of the interoperability will include the following: * GMPLS Signaling and Routing * GMPLS-based Protection and Restoration * Multi-region/layer Interworking, such as Optical and Packet Networks Please contact mailto:ipop2005-exhibition@pilab.org for additional information. ===================== CALL FOR PRESENTATION ===================== The Technical Program Committee for iPOP 2005 is soliciting presentation proposals for this conference. Protocol design, experiment, theory, implementation, and operational experiences are solicited. The topics of the conference will include the following, but will not be limited to: * GMPLS, ASON, OUNI * Protection & restoration * Multi-region network * Inter-area/Inter-AS network * Routing wavelength assignment * Impairment/management in all optical network * Traffic engineering * Network management, OA&M * Software/Hardware implementation, interoperability * Testbed, field trial * Optical burst switching * Optical service, such as L1VPN, Bandwidth on Demand, and Photonic Grid * Application with high-bandwidth demand If you wish to propose a particular topic for consideration, please send a one page summary (less than 400 words), including speaker's name, affiliation, and contact information to the Technical Program Committee at: mailto:ipop2005-cfp@pilab.org. See http://www.pilab.org/ipop2005/ for more details. Important Dates+++++++++++++++++++++++++++++++++++++++++++++++ $B!!(BNovember 15, 2004 --- Deadline of submission (extended) $B!!(BDecember 15, 2004 --- Notification of acceptance $B!!(BJanuary 8, 2005 --- Final camera ready copy $B!!(BJanuary 31, 2005 --- Deadline of conference pre-registration ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ============================ CALL FOR EXHIBITOR PROPOSALS ============================ You are invited to exhibit at the international conference on IP + Optical network (iPOP 2005), February 21-22, 2005, at the Tokyo Fashion Town (TFT) Hall in Tokyo, Japan. The conference is intended to share among the industry and the academia communities, the knowledge, new findings, and experience on the state-of-the-art of "IP and Optical Networking technologies". Within this theme we intend to demonstrate GMPLS network equipment (IP routers, SONET/SDH XCs, Optical/Photonic XCs), GMPLS protocol test equipment, GMPLS network operation support tools, Optical Switches, and other related issues. Additionally, we will provide a showcase for GMPLS interoperability. iPOP 2005 anticipates a draw of over 200 attendees, made up of network operators, service providers, and equipment vendors. Join us and other industry leaders in the IP + Optical network technologies and leading source of industry information for GMPLS technologies. The early bird deadline for exhibitors is November 1, 2004. Please contact mailto:ipop2005-exhibition@pilab.org for additional exhibitor prospectus information. Exhibit space is limited and will be committed on a first-come first-serve basis. LOCATION++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ The Tokyo Fashion Town (TFT) Hall is located in Tokyo$B!G(Bs newly developed sea-front area known as Odaiba. It is easily accessible by public transport from downtown Tokyo and Narita International Airport. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ************************** iPOP2005 COMMITTEE MEMBERS ************************** General Chairs:Tomonori Aoyama, University of Tokyo, and Bijan Jabbari, ISOCORE. Technical Program Committee Chairs: Tadanobu Okada, NTT, Japan, and (TBD). Vice Chairs: Kohei Shiomoto, NTT, Japan, and Akira Chugo, Fujitsu, Japan. Secretary: Keiji Miyazaki, Fujitsu, Japan. Organization Committee Chair: Naoaki Yamanaka, Keio University, Japan. Secretary: Akira Misawa, NTT, Japan. Treasurer: Shinya Nakamura, NEC, Japan. Local Arrangement: Hiroyuki Sakamoto, Oki Electric, Japan. Publication: Shoichiro Seno, Mitsubishi Electric, Japan. Exhibition Committee Chair: Satoru Okamoto, NTT, Japan. Vice Chairs: Shoji Fukutomi, Furukawa Electric, Japan, and Hideaki Tsushima, Hitachi Communication Technology, Japan. Secretary: Kazumasa Morita, Furukawa Electric, Japan, and Naomichi Nonaka, Hitachi, Japan. *********** SPONSORSHIP *********** iPOP 2005 is sponsored by PIL and ISOCORE, and technically co-sponsored by PIF. ------------------------------------------------------------------ PIL (Photonic Internet Lab, http://www.pilab.org), founded by 6 vendors and 1 service provider in 2002, is promoting R&D on next-generation photonic network control protocols based on photonic technologies for managed networks. ------------------------------------------------------------------ ISOCORE (Isocore Internetworking Lab, http://www.isocore.com) is the leading technology validation lab in the next generation IP and optical networking. Its goal is to advance internetworking through technology validation and product verification and to promote development and rapid deployment of innovative networking technologies. ------------------------------------------------------------------ PIF (Photonic Internet Forum, http://www.scat.or.jp/photonic/english/) is a non-profit organization contributing to the progress of info-communication technology to realize all optical ultra-high-speed networks. ------------------------------------------------------------------ Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 31 Oct 2004 21:25:52 +0000 From: "Adrian Farrel" <olddog@clara.co.uk> To: v.sharma@ieee.org Cc: adrian@olddog.co.uk, ccamp@ops.ietf.org Reply-To: adrian@olddog.co.uk Subject: L1VPN mailing list archives Date: Sun, 31 Oct 2004 21:24:28 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <E1CONBc-00013p-5L@oceanus.uk.clara.net> Hi Vishal, Thanks for flagging this. I raised the problem with the Secretariat some six weeks ago, but I didn't follow up. I have raised a new trouble ticket. Adrian > Hi Adrian, > > The link to the PCE archives on the PCE signup page does > not seem to work. Are there no archives of the PCE > mailing list? > > -Vishal Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 31 Oct 2004 19:49:09 +0000 From: "Richard Rabbat" <rabbat@fla.fujitsu.com> To: <ccamp@ops.ietf.org> Cc: "'Richard Rabbat'" <rabbat@fla.fujitsu.com>, "'Vishal Sharma'" <vsharma87@yahoo.com>, "'Takeo Hamada'" <thamada@fla.fujitsu.com> Subject: Carrier survey update on shared mesh restoration Date: Sun, 31 Oct 2004 11:48:04 -0800 Message-ID: <000c01c4bf82$8c75ca80$7001a8c0@PHOENIX> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01C4BF3F.7E528A80" This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C4BF3F.7E528A80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Based on the feedback from the CCAMP WG chairs during last IETF, we have updated the carrier survey to include all the individual carrier = responses. We've also added the couple of missing collated answers. Information about the draft is below. =20 We are currently looking for more carriers to answer the survey and have = put up the survey on a web page for easy access. We've also added more = questions based on feedback from IETF San Diego and on the mailing list. The page = is at: http://perth.mit.edu/~richard/carrier_survey/survey.txt =20 We're also looking for more feedback on what questions people have that = they would want to see captured in the survey. Thanks a lot, Richard. -- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Carrier Survey Results on GMPLS-based Shared-Mesh Transport Restoration Strategies Author(s) : R. Rabbat, et al. Filename : draft-rabbat-ccamp-carrier-survey-01.txt Pages : 36 Date : 2004-10-25 Optical transport networks operated using a GMPLS-based control plane=20 enable today=12s network operators to offer valuable new services. = With=20 the completion of a number of GMPLS signaling and routing standards=20 and the availability of products implementing them, providers are now = looking at ways to enable additional features, such as shared-mesh=20 restoration. These can be key to efficient network operation while=20 providing strict performance guarantees. In that context, several=20 areas of work still need to be addressed within the CCAMP WG of the=20 IETF to develop interoperable, standards-based solutions that=20 carriers can embrace.=20 =20 Towards that end, this document presents the results of a serious=20 attempt to systematically gather and collate carrier inputs on=20 strategies for shared-mesh restoration and the associated issues. The = survey results are presented in aggregate form to provide an overview of carrier thinking, while retaining specific carrier response=20 confidentiality. The goal is to highlight areas of carrier concerns,=20 and identify specific work items to focus on and facilitate further=20 discussion on them. This is to enable the CCAMP WG to pursue ongoing=20 and further work in this area that is focused towards addressing the=20 identified carrier requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rabbat-ccamp-carrier-survey-01.= txt ------=_NextPart_000_000D_01C4BF3F.7E528A80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii"> <TITLE>Message</TITLE> <META content=3D"MSHTML 6.00.2900.2523" name=3DGENERATOR></HEAD> <BODY> <DIV><SPAN class=3D340363419-31102004><FONT face=3DArial=20 size=3D2>Hi,</FONT></SPAN></DIV> <DIV><SPAN class=3D340363419-31102004><FONT face=3DArial size=3D2>Based = on the=20 feedback from the CCAMP WG chairs during last IETF, we have updated the = carrier=20 survey to include all the individual carrier responses. We've also added = the=20 couple of missing collated answers.</FONT></SPAN></DIV> <DIV><SPAN class=3D340363419-31102004><FONT face=3DArial = size=3D2>Information about=20 the draft is below.</FONT></SPAN></DIV> <DIV><SPAN class=3D340363419-31102004><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D340363419-31102004><FONT face=3DArial size=3D2>We are = currently=20 looking for more carriers to answer the survey and have put up the = survey on a=20 web page for easy access. We've also added more questions based on = feedback from=20 IETF San Diego and on the mailing list. The page is at: <A=20 href=3D"http://perth.mit.edu/~richard/carrier_survey/survey.txt">http://p= erth.mit.edu/~richard/carrier_survey/survey.txt</A></FONT></SPAN></DIV> <DIV><SPAN class=3D340363419-31102004><FONT face=3DArial=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D340363419-31102004><FONT face=3DArial size=3D2>We're = also looking=20 for more feedback on what questions people have that they would want to = see=20 captured in the survey.</FONT></SPAN></DIV> <DIV><SPAN class=3D340363419-31102004><FONT face=3DArial size=3D2>Thanks = a=20 lot,</FONT></SPAN></DIV> <DIV><SPAN class=3D340363419-31102004><FONT face=3DArial=20 size=3D2>Richard.</FONT></SPAN></DIV> <DIV><SPAN class=3D340363419-31102004><FONT face=3DArial=20 size=3D2>--</FONT></SPAN></DIV> <DIV><SPAN class=3D340363419-31102004>A New Internet-Draft is available = from the=20 on-line Internet-Drafts directories.<BR>Title : Carrier Survey Results = on=20 GMPLS-based Shared-Mesh Transport Restoration Strategies<BR> Author(s) : = R.=20 Rabbat, et al.<BR> Filename :=20 draft-rabbat-ccamp-carrier-survey-01.txt<BR> Pages : 36<BR> Date :=20 2004-10-25<BR> <BR>Optical transport networks operated using a = GMPLS-based=20 control plane <BR> enable today=12s network operators to = offer=20 valuable new services. With <BR> the completion of a number = of GMPLS=20 signaling and routing standards <BR> and the availability of = products implementing them, providers are now <BR> looking = at ways=20 to enable additional features, such as shared-mesh <BR> = restoration.=20 These can be key to efficient network operation while <BR> = providing=20 strict performance guarantees. In that context, several <BR> = areas=20 of work still need to be addressed within the CCAMP WG of the = <BR> =20 IETF to develop interoperable, standards-based solutions that = <BR> =20 carriers can embrace. <BR> <BR> Towards = that end,=20 this document presents the results of a serious <BR> attempt = to=20 systematically gather and collate carrier inputs on <BR> = strategies=20 for shared-mesh restoration and the associated issues. The = <BR> =20 survey results are presented in aggregate form to provide an=20 overview<BR> of carrier thinking, while retaining specific = carrier=20 response <BR> confidentiality. The goal is to highlight = areas of=20 carrier concerns, <BR> and identify specific work items to = focus on=20 and facilitate further <BR> discussion on them. This is to = enable=20 the CCAMP WG to pursue ongoing <BR> and further work in this = area=20 that is focused towards addressing the <BR> identified = carrier=20 requirements.<BR><BR>A URL for this Internet-Draft is:<BR><A=20 href=3D"http://www.ietf.org/internet-drafts/draft-rabbat-ccamp-carrier-su= rvey-01.txt">http://www.ietf.org/internet-drafts/draft-rabbat-ccamp-carri= er-survey-01.txt</A><BR></SPAN></DIV></BODY></HTML> ------=_NextPart_000_000D_01C4BF3F.7E528A80-- Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 31 Oct 2004 19:06:13 +0000 Reply-To: <v.sharma@ieee.org> From: "Vishal Sharma" <v.sharma@ieee.org> To: "Adrian Farrel" <olddog@clara.co.uk>, <ccamp@ops.ietf.org> Cc: <adrian@olddog.co.uk> Subject: RE: Your input: Use of PCE in Inter-domain Date: Sun, 31 Oct 2004 11:04:55 -0800 Message-ID: <MMECLKMDFPCEJFECIBCMEEINEMAA.v.sharma@ieee.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Adrian, The link to the PCE archives on the PCE signup page does not seem to work. Are there no archives of the PCE mailing list? -Vishal > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Adrian Farrel > Sent: Tuesday, October 19, 2004 12:11 PM > To: ccamp@ops.ietf.org > Cc: adrian@olddog.co.uk > Subject: Your input: Use of PCE in Inter-domain > > > Folks, > > The chairs and ADs would like your input on > http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-00. > txt in the > context of our inter-domain traffic engineering work. > > This draft documents an architecture for Path Computation > Elements (PCE) and > is currently being discussed on the pce mailing list > (https://www1.ietf.org/mailman/listinfo/pce) > > What we would like CCAMP to do is give us your opinion on whether PCE is > addresing an inter-domain problem that needs to be addressed, and if so > whether the architecture provides an acceptable way to resolve > the problem. > > Answers to the mailing list in advance of the meeting in > Washington would be > appreciated. > > Thanks, > Adrian and Kireeti > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 31 Oct 2004 16:52:29 +0000 Reply-To: <v.sharma@ieee.org> From: "Vishal Sharma" <v.sharma@ieee.org> To: "ricciato" <ricciato@coritel.it>, <ccamp@ops.ietf.org> Cc: <marco@infocom.uniroma1.it>, "Ugo Monaco" <monaco@infocom.uniroma1.it>, =?iso-8859-1?Q?Daniele_Al=EC?= <ali@coritel.it>, "Alessio D'Achille" <alessiored@fastwebnet.it> Subject: RE: update of JSA for inter-domain diverse path & some simulation results Date: Sun, 31 Oct 2004 08:51:16 -0800 Message-ID: <MMECLKMDFPCEJFECIBCMOEIHEMAA.v.sharma@ieee.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Hello All, Just to add to what Fabio said ... First, the draft is now officially on-line, and is available at http://www.ietf.org/internet-drafts/draft-dachille-diverse-inter-region-path -setup-01.txt Indeed, the simulation results are helping to provide more insight into the working of these schemes, and in developing better intuition about them. We would encourage CCAMPers to take a look at the revised draft, and provide their inputs. We intend to discuss the revised draft and the simulation results at DC, and look forward to your feedback. -Vishal > -----Original Message----- > From: ricciato [mailto:ricciato@coritel.it] > Sent: Wednesday, October 27, 2004 3:52 AM > To: ccamp@ops.ietf.org > Cc: marco@infocom.uniroma1.it; Ugo Monaco; Daniele Alì; Alessio > D'Achille; Vishal Sharma > Subject: update of JSA for inter-domain diverse path & some simulation > results > > > Hi all, > > please note that we have have updated the draft on the JSA method for > computing diverse paths in inter-domain. > We have also run some initial simulations on realistic topologies, > comparing the 1) JSA approach (with ARO) with 2) the method based on > RRO+XRO (called ISPA in the draft), and 3) the global optimum based on > complete information. > We considered a few realistic topologies (details in the draft) > In summary the results show that : > > - if a pair of diverse path exist, the JSA/ARO almost always find them > at the first shot (it failed in 2-3 cases over thousands of > simulation run) > - there are some topologies in which the ISPA/XRO is trapped at the > first shot (and should therefore revert to cranckback), it happens > approx. in 10% of cases > - when a pair of path is found by all the three methods, there is no > substantial difference in the overall cost between JSA/ARO and optimum > (we used min-hop metric), with a slight worse performance of ISPA/XRO > > Please note that the performance of PCE should be the same as the global > optimum (since it is computed assuming full global information and > centralized computation). > > Based on these preliminary results, we believe that the JSA/ARO approach > should not be considered a competitor of PCE (which is provenly "the > optimum"), but rather a secondary solution which achieves the same > performances of the optimal method "almost surely" in the practical > cases (still, it is possible to draw cases in which it fails, while > PCE/optimum finds his way, but these cases seem to be not found in the > realistic topologies we have investigated). > On the other hand the JSA/ARO involves much less information and > signaling overhead... > > > In addition to the IETF site, the current version of the draft can be > found at the following url. It includes quick description of the > simualtions and summary of preliminary results. It would be nice to have > a short slot for presenting them at Washington DC, perhaps .... > > We wellcome very much any feedback from the community that helps us in > refining the simulation scenario (new topologies, suggestions for > setting the scenario, etc.). Please do not hesitate to send you comment > (particularly the criticisms, which are the most helpful ones for > improving our work ...) > > ciao > fabio > > PS > the url for the draft is: > > http://www.metanoia-inc.com/Publications/draft-dachille-diverse-in ter-region-path-setup-01.txt Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 31 Oct 2004 11:34:09 +0000 Message-ID: <4184CD22.2040701@lab.ntt.co.jp> Date: Sun, 31 Oct 2004 20:31:46 +0900 From: Kohei Shiomoto <shiomoto.kohei@lab.ntt.co.jp> Organization: NTT User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) MIME-Version: 1.0 To: Adrian Farrel <adrian@olddog.co.uk> CC: ccamp@ops.ietf.org Subject: Re: Basic agenda structure for Washington DC Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi all I would like to ask a time slot at the upcoming CCAMP meeting for the MPLS/GMPLS migration draft: "IP/MPLS - GMPLS interworking in support of IP/MPLS to GMPLS migration" <draft-oki-ccamp-gmpls-ip-interworking-04.txt> A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-oki-ccamp-gmpls-ip-interworking-04.txt Comments and discussion are highly appreciated. Best regards, --- Kohei Shiomoto Adrian Farrel wrote: >Hi, > >Since San Diego, we have managed to move on quite well with our existing milestones, >commitments and drafts. > >So, the basic agenda structure for Washington DC is as follows: > >Admin and WG status >ASON Solutions >Protection solutions >Inter-domain > Basic > MRN > Diverse path >New work > MPLS/GMPLS migration > L1VPN > Others >Rechartering > >If you would like a slot, please ask and we will attempt to construct an agenda. >Editors/authors or WG drafts may expect to be asked by the chairs to present on the >status, issues and next steps for their drafts. > >Thanks, >Adrian > > > > > -- Kohei Shiomoto NTT Network Service Systems Laboratories 3-9-11 Midori, Musashino, Tokyo 180-8585, Japan Phone +81 422 59 4402 Fax +81 422 59 4549 Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 30 Oct 2004 17:41:25 +0000 Message-Id: <200410261957.PAA08915@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 26 Oct 2004 15:57:45 -0400 Cc: ccamp@ops.ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-segment-recovery-01.txt Reply-To: internet-drafts@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : GMPLS Based Segment Recovery Author(s) : L. Berger, et al. Filename : draft-ietf-ccamp-gmpls-segment-recovery-01.txt Pages : 24 Date : 2004-10-26 This document describes protocol specific procedures for GMPLS (Generalized Multi-Protocol Label Switching) RSVP-TE (Resource ReserVation Protocol - Traffic Engineering) signaling extensions to support LSP segment protection and restoration. These extensions are intended to be compliment and be consistent with the Extensions for End-to-End GMPLS-based Recovery. Implications and interactions with Fast Reroute are also addressed. This document also updates the handling of Notify_Request objects specified in [RFC3473]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-segment-recovery-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-segment-recovery-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-segment-recovery-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-26160444.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-segment-recovery-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-segment-recovery-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-26160444.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 29 Oct 2004 20:06:33 +0000 Message-ID: <E4BB443436F22D4AB9E84B06AB7C4CE00A0FDB62@nj7460exch004u.ho.lucent.com> From: "Lam, Hing-Kam (Kam)" <hklam@lucent.com> To: "'Adrian Farrel'" <adrian@olddog.co.uk> Cc: "'Kireeti Kompella'" <kireeti@juniper.net>, Bill Fenner <fenner@research.att.com>, zinin@psg.com, ccamp@ops.ietf.org, WG Milestone Tracker <iesg-secretary@ietf.org> Subject: RE: Lliaison to ITU-T SG15/Q14 About GMPLS MIB Modules Date: Fri, 29 Oct 2004 16:05:19 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Dear Mr. Farrel, Thank you for the Liaison Statement (LS) on GMPLS MIB Modules. We appreciate the opportunity to provide input to the GMPLS MIB work. Q14/15 will address the LS in its coming meetings and provide a response by 15th December 2004. Regards, Kam Lam, Q14/15 Rapporteur > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Friday, October 29, 2004 3:08 PM > To: Lam, Hing-Kam (Kam) > Cc: Adrian Farrel; 'Kireeti Kompella'; Bill Fenner; zinin@psg.com; > ccamp@ops.ietf.org; WG Milestone Tracker > Subject: Lliaison to ITU-T SG15/Q14 About GMPLS MIB Modules > > > To: Mr. Kam Lam, Rapporteur for Question 14 of > ITU-T Study Group 15. > From: Adrian Farrel and Kireeti Kompella > Co-chairs of the CCAMP Working Group of the IETF > Cc: Alex Zinin and Bill Fenner, Routing Area > Directors of the IETF > For: Action > Deadline: 15th December 2004 > Subject: GMPLS MIB Modules > > Dear Mr. Lam, > > The IETF's CCAMP Working Group has been working to develop > MIB modules to facilitate the > configuration and monitoring of GMPLS LSRs and Traffic > Engineered Tunnels (LSPs). > > The work on these MIB modules is nearing completion and, > considering that you Question has > a task to work on management issues for the ASON > architecture, we would appreciate your > input to the drafts at this stage. > > A timely response will allow us to include consideration of > any points that you raise in > the last and probably final revision of the drafts. > > For reference, the objects modeled in these MIB modules may > be considered as connection > segments (LSPs) and connection controllers (LSRs) in the ASON > architecture. There is no > intention to model calls or call controllers in this version > of the drafts, although such > function might be added in a later set of MIB modules. > > Sincerely, > Kireeti Kompella & Adrian Farrel, CCAMP WG chairs > > Att/ > draft-ietf-ccamp-gmpls-tc-mib-06.txt > draft-ietf-ccamp-gmpls-lsr-mib-06.txt > draft-ietf-ccamp-gmpls-te-mib-06.txt > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 29 Oct 2004 19:17:04 +0000 Message-ID: <0e1a01c4bdeb$5bfabde0$5d919ed9@Puppy> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: "Lam, Hing-Kam \(Kam\)" <hklam@lucent.com> Cc: "Adrian Farrel" <adrian@olddog.co.uk>, "'Kireeti Kompella'" <kireeti@juniper.net>, "Bill Fenner" <fenner@research.att.com>, <zinin@psg.com>, <ccamp@ops.ietf.org>, "WG Milestone Tracker" <iesg-secretary@ietf.org> Subject: Lliaison to ITU-T SG15/Q14 About GMPLS MIB Modules Date: Fri, 29 Oct 2004 20:07:51 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0E00_01C4BDF2.F8398130" This is a multi-part message in MIME format. ------=_NextPart_000_0E00_01C4BDF2.F8398130 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit To: Mr. Kam Lam, Rapporteur for Question 14 of ITU-T Study Group 15. From: Adrian Farrel and Kireeti Kompella Co-chairs of the CCAMP Working Group of the IETF Cc: Alex Zinin and Bill Fenner, Routing Area Directors of the IETF For: Action Deadline: 15th December 2004 Subject: GMPLS MIB Modules Dear Mr. Lam, The IETF's CCAMP Working Group has been working to develop MIB modules to facilitate the configuration and monitoring of GMPLS LSRs and Traffic Engineered Tunnels (LSPs). The work on these MIB modules is nearing completion and, considering that you Question has a task to work on management issues for the ASON architecture, we would appreciate your input to the drafts at this stage. A timely response will allow us to include consideration of any points that you raise in the last and probably final revision of the drafts. For reference, the objects modeled in these MIB modules may be considered as connection segments (LSPs) and connection controllers (LSRs) in the ASON architecture. There is no intention to model calls or call controllers in this version of the drafts, although such function might be added in a later set of MIB modules. Sincerely, Kireeti Kompella & Adrian Farrel, CCAMP WG chairs Att/ draft-ietf-ccamp-gmpls-tc-mib-06.txt draft-ietf-ccamp-gmpls-lsr-mib-06.txt draft-ietf-ccamp-gmpls-te-mib-06.txt ------=_NextPart_000_0E00_01C4BDF2.F8398130 Content-Type: text/plain; name="draft-ietf-ccamp-gmpls-tc-mib-06.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-ccamp-gmpls-tc-mib-06.txt" Network Working Group Thomas D. Nadeau, Ed. Internet Draft Cisco Systems, Inc. Proposed Status: Standards Track Expires: April 2005 Adrian Farrel, Ed. Old Dog Consulting October 2004 Definitions of Textual Conventions for Generalized Multiprotocol Label Switching (GMPLS) Management draft-ietf-ccamp-gmpls-tc-mib-06.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. Abstract This document defines a Management Information Base (MIB) module which contains Textual Conventions to represent commonly used Generalized Multiprotocol Label Switching (GMPLS) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in GMPLS related MIB modules that would otherwise define their own representations. Nadeau and Farrel (Editors) [Page 1] =0C Internet Draft draft-ietf-ccamp-gmpls-tc-mib-06.txt October 2004 Table of Contents 1. Introduction ................................... 2 2. The SNMP Management Framework .................. 2 3. GMPLS Textual Conventions MIB Definitions ...... 3 4. Security Considerations ........................ 5 5. IANA Considerations ............................ 5 6. References ..................................... 5 6.1. Normative References ......................... 5 6.2. Informational References ..................... 6 7. Acknowledgments ................................ 7 8. Authors' Addresses ............................. 7 9. Intellectual Property Notice ................... 9 10. Full Copyright Statement ..................... 10 1. Introduction This document defines a MIB module which contains Textual Conventions for Generalized Multiprotocol Label Switching (GMPLS) networks. These Textual Conventions should be imported by MIB modules which manage GMPLS networks. This MIB module supplements the MIB module in [RFC3811] that defines Textual Conventions for Multiprotocol Label Switching (MPLS) Management. [RFC3811] may continue to be used without this MIB module in networks that support only MPLS. Comments should be made directly to the CCAMP mailing list at ccamp@ops.ietf.org. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119, reference [RFC2119]. For an introduction to the concepts of GMPLS, see [GMPLSArch]. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. Nadeau and Farrel (Editors) [Page 2] =0C Internet Draft draft-ietf-ccamp-gmpls-tc-mib-06.txt October 2004 3. GMPLS Textual Conventions MIB Definitions GMPLS-TC-STD-MIB DEFINITIONS ::=3D BEGIN IMPORTS MODULE-IDENTITY FROM SNMPv2-SMI -- [RFC2578] TEXTUAL-CONVENTION FROM SNMPv2-TC -- [RFC2579] mplsStdMIB FROM MPLS-TC-STD-MIB -- [RFC3811] ; gmplsTCStdMIB MODULE-IDENTITY LAST-UPDATED "200410080001Z" -- 8 October 2004 00:00:01 GMT ORGANIZATION "Common Control And Measurement Plane (CCAMP) Working Group" CONTACT-INFO " Thomas D. Nadeau Cisco Systems, Inc. Email: tnadeau@cisco.com Adrian Farrel Old Dog Consulting Email: adrian@olddog.co.uk Comments about this document should be emailed direct to the CCAMP working group mailing list at ccamp@ops.ietf.org" DESCRIPTION "Copyright (C) The Internet Society (2004). The initial version of this MIB module was published in RFC xxxx. For full legal notices see the RFC itself or see: http://www.ietf.org/copyrights/ianamib.html This MIB module defines TEXTUAL-CONVENTIONs for concepts used in Generalized Multiprotocol Label Switching (GMPLS) networks." -- Revision history. REVISION "200410080001Z" -- 8 October 2004 00:00:01 GMT DESCRIPTION "Initial version published as part of RFC XXXX." -- Please see the IANA Considerations Section. -- This MIB module is contained in the OID sub-tree -- rooted at mplsStdMIB. -- The requested mplsStdMIB subId is xx, i.e. ::=3D { mplsStdMIB xx } Nadeau and Farrel (Editors) [Page 3] =0C Internet Draft draft-ietf-ccamp-gmpls-tc-mib-06.txt October 2004 -- Textual Conventions (sorted alphabetically). GmplsFreeformLabel ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "This value represents a freeform generalized MPLS Label. This can be used to represent label types which are not standard in the drafts. It may also be used by systems that do not wish to represent the labels using the specific label types." REFERENCE "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, RFC 3471." SYNTAX OCTET STRING (SIZE (0..64)) GmplsGeneralizedLabelTypes ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "Determines the interpretation that should be applied to a label." REFERENCE "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, RFC 3471." SYNTAX INTEGER { gmplsMplsLabel(1), gmplsPortWavelengthLabel(2), gmplsFreeformGeneralizedLabel(3), gmplsSonetLabel(4), gmplsSdhLabel(5), gmplsWavebandLabel(6) } GmplsSegmentDirection ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "The direction of data flow on an LSP segment with respect to the head of the LSP. Where an LSP is signaled using a conventional signaling protocol, the 'head' of the LSP is the source of the signaling (also known as the ingress) and the 'tail' is the destination (also known as the egress). For unidirectional LSPs, this usually matches the direction of flow of data. For manually configured unidirectional LSPs the direction of the LSP segment matches the direction of flow of data. For manually configured bidirecitonal LSPs, an arbitrary decision must be made about which LER is the 'head'." Nadeau and Farrel (Editors) [Page 4] =0C Internet Draft draft-ietf-ccamp-gmpls-tc-mib-06.txt October 2004 SYNTAX INTEGER { forward(1), reverse(2) } END 4. Security Considerations This module does not define any management objects. Instead, it defines a set of textual conventions which may be used by other MPLS MIB modules to define management objects. Meaningful security considerations can only be written in the MIB modules that define management objects. Therefore, this document has no impact on the security of the Internet. 5. IANA Considerations IANA is requested to root MIB objects in this MIB module under the mplsStdMIB subtree by assigning an OID to gmplsTCStdMIB. In the future, GMPLS related standards track MIB modules should be rooted under the mplsStdMIB (sic) subtree. IANA has been requested to manage that namespace. New assignments can only be made via a Standards Action as specified in [RFC2434]. The IANA has assigned { mplsStdMIB 1 } to the MPLS-TC-STD-MIB. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. Nadeau and Farrel (Editors) [Page 5] =0C Internet Draft draft-ietf-ccamp-gmpls-tc-mib-06.txt October 2004 [RFC3471] Berger, L. (Editor), "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. 6.2. Informational References [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP: 26, RFC 2434, October 1998. [RFC3031] Rosen, E., Viswananthan, A., and R. Callon, Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., Swallow, G., "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3212] Jamoussi, B., (editor), et. al. "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002. [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3472] Ashwood-Smith, P., Berger, L. (Editors), "Generalized MPLS Signaling - CR-LDP Extensions", RFC 3472, January 2003. [RFC3473] Berger, L. (Editor), "Generalized MPLS Signaling - RSVP-TE Extensions", RFC 3473 January 2003. [RFC3811] Nadeau, T. and J. Cucchiara, "Definition of Textual Conventions and for Multiprotocol Label Switching (MPLS) Management", RFC 3811, June 2004. [GMPLSSonetSDH] Mannie, E., Papadimitriou, D. (Editors), "Generalized Multi-Protocol Label Switching Extensions for SONET and SDH Control", Internet Draft <draft-ietf-ccamp-gmpls-sonet-sdh-08.txt>, February 2003, work in progress. Nadeau and Farrel (Editors) [Page 6] =0C Internet Draft draft-ietf-ccamp-gmpls-tc-mib-06.txt October 2004 [GMPLSLSRMIB] Nadeau, T., Farrel, A. (Editors) "Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base", draft-ietf-ccamp-gmpls-lsr-mib-06.txt, October 2004, work in progress. [GMPLSTEMIB] Nadeau, T., Farrel, A. (Editors) "Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base", draft-ietf-ccamp-gmpls-te-mib-06.txt, October 2004, work in progress. [GMPLSArch] Mannie, E. (Editor), "Generalized Multiprotocol Label Switching (GMPLS) Architecture", Internet Draft <draft-many-gmpls-architecture-07.txt>, May 2003, work in progress. 7. Acknowledgements This draft is the work of the five authors listed in the next section. Special thanks to Joan Cucchiara for her help with compilation issues. 8. Authors' Addresses Thomas D. Nadeau Cisco Systems, Inc. 300 Apollo Drive Chelmsford, MA 01824 Phone: +1-978-244-3051 Email: tnadeau@cisco.com Cheenu Srinivasan Bloomberg L.P. 499 Park Ave., New York, NY 10022 Phone: +1-212-893-3682 Email: cheenu@bloomberg.net Adrian Farrel Old Dog Consulting Phone: +44 1978 860944 Email: adrian@olddog.co.uk Nadeau and Farrel (Editors) [Page 7] =0C Internet Draft draft-ietf-ccamp-gmpls-tc-mib-06.txt October 2004 Tim Hall Data Connection Ltd. 100 Church Street Enfield, Middlesex EN2 6BQ, UK Phone: +44 20 8366 1177 Email: tim.hall@dataconnection.com Ed Harrison Data Connection Ltd. 100 Church Street Enfield, Middlesex EN2 6BQ, UK Phone: +44 20 8366 1177 Email: ed.harrison@dataconnection.com 9. Intellectual Property Considerations The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 10. Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, Nadeau and Farrel (Editors) [Page 8] =0C Internet Draft draft-ietf-ccamp-gmpls-tc-mib-06.txt October 2004 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Nadeau and Farrel (Editors) [Page 9] =0C ------=_NextPart_000_0E00_01C4BDF2.F8398130 Content-Type: text/plain; name="draft-ietf-ccamp-gmpls-lsr-mib-06.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-ccamp-gmpls-lsr-mib-06.txt" Network Working Group Thomas D. Nadeau, Ed. Internet Draft Cisco Systems, Inc. Proposed Status: Standards Track Expires: April 2005 Adrian Farrel, Ed. Old Dog Consulting October 2004 Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base draft-ietf-ccamp-gmpls-lsr-mib-06.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure and/or monitor a Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR). Nadeau and Farrel (Editors) [Page 1] =0C Internet Draft draft-ietf-ccamp-gmpls-lsr-mib-06.txt October 2004 Table of Contents 1. Introduction ..................................... 2 1.1. Migration Strategy ....................... ..... 2 2. Terminology ...................................... 3 3. The SNMP Management Framework .................... 3 4. Outline .......................................... 3 4.1. Summary of the GMPLS LSR MIB Module ............ 4 4.1.1 Summary of the GMPLS LSR MIB Module ........... 4 4.1.2 Summary of the GMPLS Label MIB Module ......... 5 5. Bidirectional LSPs ............................... 5 6. Example of LSP Setup ............................. 5 7. GMPLS Label Switching Router MIB Definitions ..... 9 8. GMPLS Label MIB Definitions ..................... 19 9. Security Considerations ......................... 32 10. Acknowledgments ................................ 34 11. IANA Considerations ............................ 34 11.1. IANA Considerations for GMPLS-LSR-STD-MIB .... 34 11.2. IANA Considerations FOR GMPLS-LABEL-STD-MIB .. 34 12. References ..................................... 34 12.1. Normative References ......................... 34 12.2. Informational References ..................... 36 13. Authors' Addresses ............................. 37 14. Full Copyright Statement ....................... 37 15. Intellectual Property Notice ................... 38 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling a Generalized Multiprotocol Label Switching (GMPLS) [GMPLSArch] Label Switching Router (LSR). Comments should be made directly to the CCAMP mailing list at ccamp@ops.ietf.org. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119, reference [RFC2119]. 1.1. Migration Strategy There are two MIB modules in this document. The GMPLS LSR MIB module extends the LSR MIB module defined for use with MPLS [RFC3813]. The only changes made are additions for support of GMPLS or changes that are necessary to support the increased complexity of a GMPLS system. The GMPLS Label MIB module may be referenced using a row pointer from objects within the LSR MIB module. Nadeau and Farrel (Editors) [Page 2] =0C Internet Draft draft-ietf-ccamp-gmpls-lsr-mib-06.txt October 2004 The companion document modeling and managing GMPLS based traffic engineering [GMPLSTEMIB] extends the MPLS TE MIB module [RFC3812] with the same intentions. Textual conventions and OBJECT-IDENTIFIERS are defined in [GMPLSTCMIB] which extends the set of textual conventions originally defined in [RFC3811]. 2. Terminology This document uses terminology from the document describing the MPLS architecture [RFC3031] and the GMPLS architecture [GMPLSArch]. A label switched path (LSP) is modeled as a connection consisting of one or more incoming segments (in-segments) and/or one or more outgoing segments (out-segments) at an LSR. The association or interconnection of the in-segments and out-segments is accomplished by using a cross-connect. We use the terminology "connection" and "LSP" interchangeably where the meaning is clear from the context. in-segment This is analogous to a GMPLS label on an interface. out-segment This is analogous to a GMPLS label on an interface. cross-connect This describes the conceptual connection between a set of in-segments and out-segments. Note that either set may be empty; for example, a cross-connect may connect only out-segments together with no in-segments in the case where an LSP is originating on an LSR. 3. The SNMP Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 4. Outline Configuring statically provisioned GMPLS LSPs through an LSR involves the following steps: - Configuring an interface using the MPLS LSR MIB module. Nadeau and Farrel (Editors) [Page 3] =0C Internet Draft draft-ietf-ccamp-gmpls-lsr-mib-06.txt October 2004 - Enabling GMPLS on GMPLS capable interfaces using this MIB module. - Configuring in-segments and out-segments using the MPLS LSR MIB module. - Configuring GMPLS extensions to the in-segments and out-segments using this MIB module. - Setting up the cross-connect table in the MPLS LSR MIB module to associate segments and/or to indicate connection origination and termination. - Optionally setting up labels in the label table in this MIB module if the textual convention MplsLabel is not capable of holding the required label (for example, if the label requires more than 32 bits to encode it), or if the operator wishes to disambiguate GMPLS label types. - Optionally specifying label stack actions in the MPLS LSR MIB module. - Optionally specifying segment traffic parameters in the MPLS LSR MIB module. 4.1 MIB Modules There are two MIB modules defined in this document. The GMPLS LSR MIB module contains tables that extend tables defined in the MPLS LSR MIB module. This MIB module is used in conjunction with the MPLS LSR MIB module in systems that support GMPLS. The GMPLS Label MIB module contains objects for managing GMPLS labels when they cannot be represented using the textual conventions of the MPLS TC MIB module, or when more detailed access to the sub-fields of the labels is required. 4.1.1 Summary of the GMPLS LSR MIB Module The MIB tables in this MIB module are as follows. - The interface configuration table (gmplsInterfaceTable), which extends mplsInterfaceTable to enable the GMPLS protocol on MPLS- capable interfaces. - The in-segment (gmplsInSegmentTable) and out-segment (gmplsOutSegmentTable) tables extend mplsInSegmentTable and mplsOutSegmentTable to configuring GMPLS-specific parameters for LSP segments at an LSR. These tables are described in the subsequent sections. Nadeau and Farrel (Editors) [Page 4] =0C Internet Draft draft-ietf-ccamp-gmpls-lsr-mib-06.txt October 2004 4.1.2 Summary of the GMPLS Label MIB Module There is one MIB table in this MIB module as follows. - The gmplsLabelTable allows Generalized Labels to be defined and managed in a central location. Generalized Labels can be of variable length and have distinct bit-by-bit interpretations according to the use that is made of them. These tables are described in the subsequent sections. 5. Bidirectional LSPs This MIB module supports bidirectional LSPs as required for GMPLS. A single value of mplsXCIndex is shared by all of the segments for the entire bidirectional LSP. This facilitates a simple reference from [RFC3812] and [GMPLSTEMIB], and makes fate-sharing more obvious. It is, however, important that the direction of segments is understood to avoid connecting all in-segments to all out-segments. This is achieved by an object in each segment that indicates the direction of the segment with respect to data flow. A segment that is marked as 'forward' carries data from the 'head' of the LSP to the 'tail'. A segment marked as 'reverse' carries data in the reverse direction. Where an LSP is signaled using a conventional signaling protocol, the 'head' of the LSP is the source of the signaling (also known as the ingress) and the 'tail' is the destination (also known as the egress). For manually configured LSPs an arbitrary decision must be made about which segments are 'forward' and which 'reverse'. For consistency this decision should be made across all LSRs that participate in the LSP by assigning 'head' and 'tail' ends to the LSP. 6. Example of LSP Setup In this section we provide a brief example of using the MIB objects described in sections 7 and 8 to set up an LSP. While this example is not meant to illustrate every nuance of the MIB, it is intended as an aid to understanding some of the key concepts. It is meant to be read after going through the MIB itself. A prerequisite is an understanding of [RFC3813]. Suppose that one would like to manually create a best-effort, bi-directional LSP. Assume that, in the forward direction, the LSP enters the LSR via MPLS interface A with ifIndex 12 and exits the LSR via MPLS interface B with ifIndex 13. For the reverse direction, we assume the LSP enters via interface B and leaves via interface A Nadeau and Farrel (Editors) [Page 5] =0C Internet Draft draft-ietf-ccamp-gmpls-lsr-mib-06.txt October 2004 (i.e. the forward and reverse directions use the same bi-directional interfaces). Let us also assume that we do not wish to have a label stack beneath the top label on the outgoing labeled packets. The following example illustrates which rows and corresponding objects might be created to accomplish this. We must first create rows in the gmplsLabelTable corresponding to the labels required for each of the forward and reverse direction in- and out-segments. For the purpose of this example the forward and reverse labels on each interface will be the same, hence we need to create just two rows in the gmplsLabelTable - one for each interface. In gmplsLabelTable: { gmplsLabelInterface =3D 12, gmplsLabelIndex =3D 1, gmplsLabelSubindex =3D 0, gmplsLabelType =3D gmplsFreeformGeneralizedLabel(3), gmplsLabelFreeform =3D 0x123456789ABCDEF0 gmplsLabelRowStatus =3D createAndGo(4) } In gmplsLabelTable: { gmplsLabelInterface =3D 13, gmplsLabelIndex =3D 1, gmplsLabelSubindex =3D 0, gmplsLabelType =3D gmplsFreeformGeneralizedLabel(3), gmplsLabelFreeform =3D 0xFEDCBA9876543210 gmplsLabelRowStatus =3D createAndGo(4) } We must next create the appropriate in-segment and out-segment entries. These are done in [RFC3813] using the mplsInSegmentTable and mplsOutSegmentTable. Note that we use a row pointer to the two rows in the gmplsLableTable rather than specifying the labels explicitly in the in- and out-segment tables. Also note that the row status for each row is set to createAndWait(5) to allow corresponding entries in the gmplsInSegmentTable and gmplsOutSegmentTable to be created. For the forward direction. In mplsInSegmentTable: { mplsInSegmentIndex =3D 0x00000015 mplsInSegmentLabel =3D 0, -- incoming label in label = table mplsInSegmentNPop =3D 1, mplsInSegmentInterface =3D 12, -- incoming interface -- RowPointer MUST point to the first accesible column. mplsInSegmentTrafficParamPtr =3D 0.0, Nadeau and Farrel (Editors) [Page 6] =0C Internet Draft draft-ietf-ccamp-gmpls-lsr-mib-06.txt October 2004 mplsInSegmentLabelPtr =3D gmplsLabelTable (12, 1, 0) mplsInSegmentRowStatus =3D createAndWait(5) } In mplsOutSegmentTable: { mplsOutSegmentIndex =3D 0x00000012, mplsOutSegmentInterface =3D 13, -- outgoing interface mplsOutSegmentPushTopLabel =3D true(1), mplsOutSegmentTopLabel =3D 0, -- outgoing label in label = table -- RowPointer MUST point to the first accesible column. mplsOutSegmentTrafficParamPtr =3D 0.0, mplsOutSegmentLabelPtr =3D gmplsLabelTable (13, 1, 0) mplsOutSegmentRowStatus =3D createAndWait(5) } For the reverse direction. In mplsInSegmentTable: { mplsInSegmentIndex =3D 0x00000016 mplsInSegmentLabel =3D 0, -- incoming label in label = table mplsInSegmentNPop =3D 1, mplsInSegmentInterface =3D 13, -- incoming interface -- RowPointer MUST point to the first accesible column. mplsInSegmentTrafficParamPtr =3D 0.0, mplsInSegmentLabelPtr =3D gmplsLabelTable (13, 1, 0) mplsInSegmentRowStatus =3D createAndWait(5) } In mplsOutSegmentTable: { mplsOutSegmentIndex =3D 0x00000013, mplsOutSegmentInterface =3D 12, -- outgoing interface mplsOutSegmentPushTopLabel =3D true(1), mplsOutSegmentTopLabel =3D 0, -- outgoing label in label = table -- RowPointer MUST point to the first accesible column. mplsOutSegmentTrafficParamPtr =3D 0.0, mplsOutSegmentLabelPtr =3D gmplsLabelTable (12, 1, 0) mplsOutSegmentRowStatus =3D createAndWait(5) } These table entries are extended by entries in gmplsInSegmentTable and gmplsOutSegmentTable. Note that the nature of the 'extends' relationship is that the entry in gmplsInSegmentTable has the same Nadeau and Farrel (Editors) [Page 7] =0C Internet Draft draft-ietf-ccamp-gmpls-lsr-mib-06.txt October 2004 index values as the entry in mplsInSegmentTable. Similarly, the entry in gmplsOutSegmentTable has the same index values as the entry in mplsOutSegmentTable. First for the forward direction: In gmplsInSegmentTable(0x00000015) { gmplsInSegmentDirection =3D forward (1) } In gmplsOutSegmentTable(0x00000012) { gmplsOutSegmentDirection =3D forward (1) } Next for the reverse direction: In gmplsInSegmentTable(0x00000016) { gmplsInSegmentDirection =3D reverse (2) } In gmplsOutSegmentTable(0x00000013) { gmplsOutSegmentDirection =3D reverse (2) } Next, two cross-connect entries are created in the mplsXCTable of the MPLS LSR MIB, thereby associating the newly created segments together. In mplsXCTable: { mplsXCIndex =3D 0x01, mplsXCInSegmentIndex =3D 0x00000015, mplsXCOutSegmentIndex =3D 0x00000012, mplsXCLspId =3D 0x0102 -- unique ID mplsXCLabelStackIndex =3D 0x00, -- only a single outgoing = label mplsXCRowStatus =3D createAndGo(4) } In mplsXCTable: { mplsXCIndex =3D 0x02, mplsXCInSegmentIndex =3D 0x00000016, mplsXCOutSegmentIndex =3D 0x00000013, mplsXCLspId =3D 0x0102 -- unique ID mplsXCLabelStackIndex =3D 0x00, -- only a single outgoing = label mplsXCRowStatus =3D createAndGo(4) } Nadeau and Farrel (Editors) [Page 8] =0C Internet Draft draft-ietf-ccamp-gmpls-lsr-mib-06.txt October 2004 Finally, the in-segments and out-segments are activated. In mplsInSegmentTable(0x00000015): { mplsInSegmentRowStatus =3D active(1) } In mplsInSegmentTable(0x00000016): { mplsInSegmentRowStatus =3D active(1) } In mplsOutSegmentTable(0x00000012): { mplsOutSegmentRowStatus =3D active(1) } In mplsOutSegmentTable(0x00000013): { mplsOutSegmentRowStatus =3D active(1) } 7. GMPLS Label Switching Router MIB Definitions GMPLS-LSR-STD-MIB DEFINITIONS ::=3D BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, zeroDotZero FROM SNMPv2-SMI -- [RFC2578] MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF -- [RFC2580] RowPointer FROM SNMPv2-TC -- [RFC2579] GmplsSegmentDirection FROM GMPLS-TC-STD-MIB -- [GMPLSTCMIB] mplsInterfaceIndex, mplsInSegmentIndex, mplsOutSegmentIndex FROM MPLS-LSR-STD-MIB -- [RFC3813] mplsStdMIB FROM MPLS-TC-STD-MIB -- [RFC3811] ; gmplsLsrStdMIB MODULE-IDENTITY LAST-UPDATED "200410080001Z" -- 8 October 2004 00:00:01 GMT ORGANIZATION "Common Control And Measurement Plane (CCAMP) Working Group" CONTACT-INFO " Thomas D. Nadeau Cisco Systems, Inc. Email: tnadeau@cisco.com Adrian Farrel Old Dog Consulting Email: adrian@olddog.co.uk Nadeau and Farrel (Editors) [Page 9] =0C Internet Draft draft-ietf-ccamp-gmpls-lsr-mib-06.txt October 2004 Comments about this document should be emailed direct to the CCAMP working group mailing list at ccamp@ops.ietf.org" DESCRIPTION "Copyright (C) The Internet Society (2004). The initial version of this MIB module was published in RFC xxxx. For full legal notices see the RFC itself or see: http://www.ietf.org/copyrights/ianamib.html This MIB module contains managed object definitions for the Generalized Multiprotocol (GMPLS) Label Switching Router as defined in: Generalized Multi-Protocol Label Switching (GMPLS) Architecture,Mannie et al., draft-ietf-ccamp-gmpls-architecture-07.txt, May 2003, work in progress." -- Revision history. REVISION "200410080001Z" -- 8 October 2004 00:00:01 GMT DESCRIPTION "Initial version issued as part of RFC XXXX." ::=3D { mplsStdMIB xx } -- Top level components of this MIB module. -- Notifications -- no notifications are currently defined. gmplsLsrNotifications OBJECT IDENTIFIER ::=3D { gmplsLsrStdMIB 0 } -- Tables, Scalars gmplsLsrObjects OBJECT IDENTIFIER ::=3D { gmplsLsrStdMIB 1 } -- Conformance gmplsLsrConformance OBJECT IDENTIFIER ::=3D { gmplsLsrStdMIB 2 } -- GMPLS Interface Table. gmplsInterfaceTable OBJECT-TYPE SYNTAX SEQUENCE OF GmplsInterfaceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table specifies per-interface GMPLS capability and associated information. It extends the information in mplsInterfaceTable." ::=3D { gmplsLsrObjects 1 } Nadeau and Farrel (Editors) [Page 10] =0C Internet Draft draft-ietf-ccamp-gmpls-lsr-mib-06.txt October 2004 gmplsInterfaceEntry OBJECT-TYPE SYNTAX GmplsInterfaceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in this table is created automatically by an LSR for every interface capable of supporting GMPLS and which is configured to do so. A conceptual row in this table will exist if and only if a corresponding entry in mplsInterfaceTable exists, and a corresponding entry in ifTable exists with ifType =3D mpls(166). If the associated entry in ifTable is operationally disabled (thus removing the GMPLS capabilities on the interface) or the entry in mplsInterfaceTable is deleted, the corresponding entry in this table MUST be deleted shortly thereafter. The indexing is the same as that for mplsInterfaceTable. Thus, the entry with index 0 represents the per-platform label space and contains parameters that apply to all interfaces that participate in the per-platform label space." INDEX { mplsInterfaceIndex } ::=3D { gmplsInterfaceTable 1 } GmplsInterfaceEntry ::=3D SEQUENCE { gmplsInterfaceSignalingCaps BITS, gmplsInterfaceRsvpHelloPeriod Unsigned32 } gmplsInterfaceSignalingCaps OBJECT-TYPE SYNTAX BITS { unknown (0), rsvpGmpls (1), crldpGmpls (2), -- note the use of CR-LDP is deprecated otherGmpls (3) } MAX-ACCESS read-create STATUS current DESCRIPTION "Defines the signaling capabilities on this interface. Multiple bits may legitimately be set at once. Setting no bits implies that GMPLS signaling cannot be performed on this interface and all LSPs must be manually provisioned or that this table entry is only present to supplement an entry in the mplsInterfaceTable by providing the information carried in other objects in this row." DEFVAL { { rsvpGmpls } } ::=3D { gmplsInterfaceEntry 1 } Nadeau and Farrel (Editors) [Page 11] =0C Internet Draft draft-ietf-ccamp-gmpls-lsr-mib-06.txt October 2004 gmplsInterfaceRsvpHelloPeriod OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Period, in milliseconds, between sending RSVP Hello messages on this interface. A value of 0 indicates that no Hello messages should be sent on this interface." REFERENCE "Generalized MPLS Signaling - RSVP-TE Extensions, Berger, L. (Editor), RFC 3473, January 2003." DEFVAL { 3000 } ::=3D { gmplsInterfaceEntry 2 } -- End of gmplsInterfaceTable -- In-segment table. gmplsInSegmentTable OBJECT-TYPE SYNTAX SEQUENCE OF GmplsInSegmentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table extends the mplsInSegmentTable to provide GMPLS- specific information about incoming segments to an LSR." ::=3D { gmplsLsrObjects 2 } gmplsInSegmentEntry OBJECT-TYPE SYNTAX GmplsInSegmentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table extends the representation of an incoming segment represented by an entry in mplsInSegmentTable. An entry can be created by a network administrator or an SNMP agent, or a GMPLS signaling protocol. Note that the storage type for this entry SHOULD be inherited from the corresponding entry in the mplsInSegmentTable given by the value of the mplsInSegmentStorageType object." INDEX { mplsInSegmentIndex } ::=3D { gmplsInSegmentTable 1 } GmplsInSegmentEntry ::=3D SEQUENCE { gmplsInSegmentDirection GmplsSegmentDirection, gmplsInSegmentExtraParamsPtr RowPointer } Nadeau and Farrel (Editors) [Page 12] =0C Internet Draft draft-ietf-ccamp-gmpls-lsr-mib-06.txt October 2004 gmplsInSegmentDirection OBJECT-TYPE SYNTAX GmplsSegmentDirection MAX-ACCESS read-create STATUS current DESCRIPTION "This object indicates the direction of data flow on this segment. This object cannot be modified if mplsInSegmentRowStatus for the associated entry in the mplsInSegmentTable is active(1)." DEFVAL { forward } ::=3D { gmplsInSegmentEntry 1 } gmplsInSegmentExtraParamsPtr OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "Some Tunnels will run over transports that can usefully support technology-specific additional parameters (for example, SONET resource usage). Such can be supplied from an external table and referenced from here. A value of zeroDotzero in this attribute indicates that there is no such additional information." DEFVAL { zeroDotZero } ::=3D { gmplsInSegmentEntry 2 } -- End of gmplsInSegmentTable -- Out-segment table. gmplsOutSegmentTable OBJECT-TYPE SYNTAX SEQUENCE OF GmplsOutSegmentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table extends the mplsOutSegmentTable to provide GMPLS-specific information about outgoing segments from an LSR." ::=3D { gmplsLsrObjects 3 } gmplsOutSegmentEntry OBJECT-TYPE SYNTAX GmplsOutSegmentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table extends the representation of an outgoing segment represented by an entry in mplsOutSegmentTable. An entry can be created by a network administrator or an SNMP agent, or a GMPLS signaling protocol. Nadeau and Farrel (Editors) [Page 13] =0C Internet Draft draft-ietf-ccamp-gmpls-lsr-mib-06.txt October 2004 Note that the storage type for this entry SHOULD be inherited from the corresponding entry in the mplsOutSegmentTable given by the value of the mplsOutSegmentStorageType object." INDEX { mplsOutSegmentIndex } ::=3D { gmplsOutSegmentTable 1 } GmplsOutSegmentEntry ::=3D SEQUENCE { gmplsOutSegmentDirection GmplsSegmentDirection, gmplsOutSegmentTTLDecrement Unsigned32, gmplsOutSegmentExtraParamsPtr RowPointer } gmplsOutSegmentDirection OBJECT-TYPE SYNTAX GmplsSegmentDirection MAX-ACCESS read-create STATUS current DESCRIPTION "This object indicates the direction of data flow on this segment. This object cannot be modified if mplsOutSegmentRowStatus for the associated entry in the mplsOutSegmentTable is active(1)." DEFVAL { forward } ::=3D { gmplsOutSegmentEntry 1 } gmplsOutSegmentTTLDecrement OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-create STATUS current DESCRIPTION "This object indicates the amount by which to decrement the TTL of any payload packets forwarded on this segment if per-hop decrementing is being done. A value of zero indicates that no decrement should be made or that per-hop decrementing is not in force. See the gmplsTunnelTTLDecrement object in the gmplsTunnelTable of [GMPLSTEMIB] for a value by which to decrement the TTL for the whole of a tunnel. This object cannot be modified if mplsOutSegmentRowStatus for the associated entry in the mplsOutSegmentTable is active(1)." REFERENCE "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks, Agarwal, P., Akyol, B., RFC 3443, January 2003" DEFVAL { 0 } ::=3D { gmplsOutSegmentEntry 2 } Nadeau and Farrel (Editors) [Page 14] =0C Internet Draft draft-ietf-ccamp-gmpls-lsr-mib-06.txt October 2004 gmplsOutSegmentExtraParamsPtr OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "Some Tunnels will run over transports that can usefully support technology-specific additional parameters (for example, SONET resource usage). Such can be supplied from an external table and referenced from here. A value of zeroDotzero in this attribute indicates that there is no such additional information." DEFVAL { zeroDotZero } ::=3D { gmplsOutSegmentEntry 3 } -- End of gmplsOutSegmentTable -- Module compliance. gmplsLsrGroups OBJECT IDENTIFIER ::=3D { gmplsLsrConformance 1 } gmplsLsrCompliances OBJECT IDENTIFIER ::=3D { gmplsLsrConformance 2 } -- Compliance requirement for fully compliant implementations. gmplsLsrModuleFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance statement for agents that provide full support for GMPLS-LSR-STD-MIB." MODULE IF-MIB -- The Interfaces Group MIB, RFC 2863. MANDATORY-GROUPS { ifGeneralInformationGroup, ifCounterDiscontinuityGroup } MODULE MPLS-LSR-STD-MIB -- The MPLS LSR MIB MANDATORY-GROUPS { mplsInterfaceGroup, mplsInSegmentGroup, mplsOutSegmentGroup, mplsXCGroup, mplsPerfGroup, mplsLsrNotificationGroup } Nadeau and Farrel (Editors) [Page 15] =0C Internet Draft draft-ietf-ccamp-gmpls-lsr-mib-06.txt October 2004 MODULE -- this module MANDATORY-GROUPS { gmplsInterfaceGroup, gmplsInSegmentGroup, gmplsOutSegmentGroup } -- gmplsInSegmentTable OBJECT gmplsInSegmentDirection SYNTAX GmplsSegmentDirection MIN-ACCESS read-write DESCRIPTION "Only forward(1) needs to be supported by implementations that only support unidirectional LSPs." -- gmplsOutSegmentTable OBJECT gmplsOutSegmentDirection SYNTAX GmplsSegmentDirection MIN-ACCESS read-write DESCRIPTION "Only forward(1) needs to be supported by implementations that only support unidirectional LSPs." OBJECT gmplsOutSegmentTTLDecrement SYNTAX Unsigned32 (0..255) MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::=3D { gmplsLsrCompliances 1 } -- Compliance requirement for implementations that provide read-only -- access. gmplsLsrModuleReadOnlyCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance requirement for implementations that only provide read-only support for GMPLS-LSR-STD-MIB. Such devices can then be monitored but cannot be configured using this MIB modules." MODULE IF-MIB -- The interfaces Group MIB, RFC 2863 Nadeau and Farrel (Editors) [Page 16] =0C Internet Draft draft-ietf-ccamp-gmpls-lsr-mib-06.txt October 2004 MANDATORY-GROUPS { ifGeneralInformationGroup, ifCounterDiscontinuityGroup } MODULE MPLS-LSR-STD-MIB MANDATORY-GROUPS { mplsInterfaceGroup, mplsInSegmentGroup, mplsOutSegmentGroup, mplsXCGroup, mplsPerfGroup } MODULE -- this module MANDATORY-GROUPS { gmplsInterfaceGroup, gmplsInSegmentGroup, gmplsOutSegmentGroup } -- gmplsInterfaceGroup OBJECT gmplsInterfaceSignalingCaps SYNTAX BITS { unknown (0), rsvpGmpls (1), crldpGmpls (2), otherGmpls (3) } MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsInterfaceRsvpHelloPeriod SYNTAX Unsigned32 MIN-ACCESS read-only DESCRIPTION "Write access is not required." -- gmplsInSegmentTable OBJECT gmplsInSegmentDirection SYNTAX GmplsSegmentDirection MIN-ACCESS read-only DESCRIPTION "Write access is not required. Only forward(1) needs to be supported by implementations that only support unidirectional LSPs." Nadeau and Farrel (Editors) [Page 17] =0C Internet Draft draft-ietf-ccamp-gmpls-lsr-mib-06.txt October 2004 OBJECT gmplsInSegmentExtraParamsPtr SYNTAX RowPointer MIN-ACCESS read-only DESCRIPTION "Write access is not required." -- gmplsOutSegmentTable OBJECT gmplsOutSegmentDirection SYNTAX GmplsSegmentDirection MIN-ACCESS read-only DESCRIPTION "Write access is not required. Only forward(1) needs to be supported by implementations that only support unidirectional LSPs." OBJECT gmplsOutSegmentTTLDecrement SYNTAX Unsigned32 (0..255) MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsOutSegmentExtraParamsPtr SYNTAX RowPointer MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::=3D { gmplsLsrCompliances 2 } -- Units of conformance. gmplsInterfaceGroup OBJECT-GROUP OBJECTS { gmplsInterfaceSignalingCaps, gmplsInterfaceRsvpHelloPeriod } STATUS current DESCRIPTION "Collection of objects needed for GMPLS interface configuration and performance information." ::=3D { gmplsLsrGroups 1 } gmplsInSegmentGroup OBJECT-GROUP OBJECTS { gmplsInSegmentDirection, gmplsInSegmentExtraParamsPtr } STATUS current Nadeau and Farrel (Editors) [Page 18] =0C Internet Draft draft-ietf-ccamp-gmpls-lsr-mib-06.txt October 2004 DESCRIPTION "Collection of objects needed to implement a GMPLS in-segment." ::=3D { gmplsLsrGroups 2 } gmplsOutSegmentGroup OBJECT-GROUP OBJECTS { gmplsOutSegmentDirection, gmplsOutSegmentTTLDecrement, gmplsOutSegmentExtraParamsPtr } STATUS current DESCRIPTION "Collection of objects needed to implement a GMPLS out-segment." ::=3D { gmplsLsrGroups 3 } END 8. GMPLS Label MIB Definitions GMPLS-LABEL-STD-MIB DEFINITIONS ::=3D BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, Integer32 FROM SNMPv2-SMI -- [RFC2578] MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF -- [RFC2580] RowStatus, StorageType FROM SNMPv2-TC -- [RFC2579] InterfaceIndexOrZero FROM IF-MIB -- [RFC2863] IndexIntegerNextFree FROM DIFFSERV-MIB -- [RFC3289] MplsLabel FROM MPLS-TC-STD-MIB -- [RFC3811] GmplsGeneralizedLabelTypes, GmplsFreeformLabel FROM GMPLS-TC-STD-MIB -- [GMPLSTCMIB] mplsStdMIB FROM MPLS-TC-STD-MIB -- [RFC3811] ; gmplsLabelStdMIB MODULE-IDENTITY LAST-UPDATED "200410080001Z" -- 8 October 2004 00:00:01 GMT ORGANIZATION "Common Control And Measurement Plane (CCAMP) Working Group" CONTACT-INFO " Thomas D. Nadeau Cisco Systems, Inc. Email: tnadeau@cisco.com Nadeau and Farrel (Editors) [Page 19] =0C Internet Draft draft-ietf-ccamp-gmpls-lsr-mib-06.txt October 2004 Adrian Farrel Old Dog Consulting Email: adrian@olddog.co.uk Comments about this document should be emailed direct to the CCAMP working group mailing list at ccamp@ops.ietf.org" DESCRIPTION "Copyright (C) The Internet Society (2004). The initial version of this MIB module was published in RFC xxxx. For full legal notices see the RFC itself or see: http://www.ietf.org/copyrights/ianamib.html This MIB module contains managed object definitions for labels within GMPLS systems as defined in: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, Berger, L. (Editor), RFC 3471, January 2003." -- Revision history. REVISION "200410080001Z" -- 8 October 2004 00:00:01 GMT DESCRIPTION "Initial version issued as part of RFC XXXX." ::=3D { mplsStdMIB xx } -- Top level components of this MIB module. -- Notifications -- no notifications are currently defined. gmplsLabelNotifications OBJECT IDENTIFIER ::=3D { gmplsLabelStdMIB 0 = } -- Tables, Scalars gmplsLabelObjects OBJECT IDENTIFIER ::=3D { gmplsLabelStdMIB 1 = } -- Conformance gmplsLabelConformance OBJECT IDENTIFIER ::=3D { gmplsLabelStdMIB 2 = } -- GMPLS Label Table. gmplsLabelIndexNext OBJECT-TYPE SYNTAX IndexIntegerNextFree MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains an unused value for gmplsLabelIndex, or a zero to indicate that no unused value exists or is available. An management application wishing to create a row in the gmplsLabelTable may read this Nadeau and Farrel (Editors) [Page 20] =0C Internet Draft draft-ietf-ccamp-gmpls-lsr-mib-06.txt October 2004 object and then attempt to create a row in the table. If row creation fails (because another application has already created a row with the supplied index) the management application should read this object again to get a new index value. When a row is created in the gmplsLabelTable with the gmplsLabelIndex value held by this object, an implementation MUST change the value in this object." ::=3D { gmplsLabelObjects 1 } gmplsLabelTable OBJECT-TYPE SYNTAX SEQUENCE OF GmplsLabelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of GMPLS Labels. This table allows the representation of the more complex label forms required for GMPLS which cannot be held within the textual convention MplsLabel. That is labels that cannot be encoded within 32 bits. It is, nevertheless also capable of holding 32 bit labels or regular MPLS labels if desired. Each entry in this table represents an individual GMPLS label value. Labels in the tables in other MIBs are referred to using row pointer into this table. The indexing of this table provides for arbitrary indexing and also for concatenation of labels." ::=3D { gmplsLabelObjects 2 } gmplsLabelEntry OBJECT-TYPE SYNTAX GmplsLabelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table represents a single label value. There are three indexes into the table. - The interface index may be helpful to distinguish which labels are in use on which interfaces or to handle cases where there are a very large number of labels in use in the system. When label representation is desired to apply to the whole system or when it is not important to distinguish labels by their interfaces, this index MAY be set to zero. - The label index provides a way of identifying the label. Nadeau and Farrel (Editors) [Page 21] =0C Internet Draft draft-ietf-ccamp-gmpls-lsr-mib-06.txt October 2004 - The label sub-index is only used for concatenated labels. It identifies each component label. When non-concatenated labels are used, this index SHOULD be set to zero. A storage type object is supplied to control the storage type for each entry, but implementations should note that the storage type of conceptual rows in other tables that include row pointers to an entry in this table SHOULD dictate the storage type of the rows in this table where the row in the other table is more persistent." INDEX { gmplsLabelInterface, gmplsLabelIndex, gmplsLabelSubindex } ::=3D { gmplsLabelTable 1 } GmplsLabelEntry ::=3D SEQUENCE { gmplsLabelInterface InterfaceIndexOrZero, gmplsLabelIndex Unsigned32, gmplsLabelSubindex Unsigned32, gmplsLabelType GmplsGeneralizedLabelTypes, gmplsLabelMplsLabel MplsLabel, gmplsLabelPortWavelength Unsigned32, gmplsLabelFreeform GmplsFreeformLabel, gmplsLabelSonetSdhSignalIndex Integer32, gmplsLabelSdhVc Integer32, gmplsLabelSdhVcBranch Integer32, gmplsLabelSonetSdhBranch Integer32, gmplsLabelSonetSdhGroupBranch Integer32, gmplsLabelWavebandId Unsigned32, gmplsLabelWavebandStart Unsigned32, gmplsLabelWavebandEnd Unsigned32, gmplsLabelRowStatus RowStatus, gmplsLabelStorageType StorageType } gmplsLabelInterface OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS not-accessible STATUS current DESCRIPTION "The interface on which this label is used. If the label has or could have applicability across the whole system, this object SHOULD be set to zero." ::=3D { gmplsLabelEntry 1 } gmplsLabelIndex OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS not-accessible Nadeau and Farrel (Editors) [Page 22] =0C Internet Draft draft-ietf-ccamp-gmpls-lsr-mib-06.txt October 2004 STATUS current DESCRIPTION "An arbitrary index into the table to identify a label. Note that implementations that are representing 32 bit labels within this table MAY choose to align this index with the value of the label, but should be aware of the implications of sparsely populated tables. A management application may read the gmplsLabelIndexNext object to find a suitable value for this object." ::=3D { gmplsLabelEntry 2 } gmplsLabelSubindex OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "In conjunction with gmplsLabelInterface and gmplsLabelIndex, this object uniquely identifies this row. This sub-index allows a single GMPLS label to be defined as a concatenation of labels. This is particularly useful in TDM. The ordering of sub-labels is strict with the sub-label with lowest gmplsLabelSubindex appearing first. Note that all sub-labels of a single GMPLS label must share the same gmplsLabelInterface and gmplsLabelIndex values. For labels that are not composed of concatenated sub-labels, this value SHOULD be set to zero." ::=3D { gmplsLabelEntry 3 } gmplsLabelType OBJECT-TYPE SYNTAX GmplsGeneralizedLabelTypes MAX-ACCESS read-create STATUS current DESCRIPTION "Identifies the type of this label. Note that this object does not determine whether MPLS or GMPLS signaling is in use: a value of gmplsMplsLabel (1) denotes that a 23 bit MPLS packet label is present, but does not describe whether this is signaled using MPLS or GMPLS. The value of this object helps determine which of the following objects are valid. This object cannot be modified if gmplsLabelRowStatus is active(1)." REFERENCE "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, Berger, L. (Editor), RFC 3471, January 2003." ::=3D { gmplsLabelEntry 4 } Nadeau and Farrel (Editors) [Page 23] =0C Internet Draft draft-ietf-ccamp-gmpls-lsr-mib-06.txt October 2004 gmplsLabelMplsLabel OBJECT-TYPE SYNTAX MplsLabel MAX-ACCESS read-create STATUS current DESCRIPTION "The value of an MPLS label (that is a packet label) if this table is used to store it. This may be used in MPLS systems even though the label values can be adequately stored in the MPLS MIB modules. Further, in mixed MPLS and GMPLS systems it may be advantageous to store all labels in a single label table. Lastly, in GMPLS systems where packet labels are used (that is in systems that use GMPLS signaling and GMPLS labels for packet switching) it may be desirable to use this table. This object is only valid if gmplsLabelType is set to gmplsMplsLabel (1). This object cannot be modified if gmplsLabelRowStatus is active(1)." REFERENCE "MPLS Label Stack Encoding, Rosen, E. et al, RFC 3032, January 2001." DEFVAL { 0 } ::=3D { gmplsLabelEntry 6 } gmplsLabelPortWavelength OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The value of a Port or Wavelength Label when carried as a Generalized Label. Only valid if gmplsLabelType is set to gmplsPortWavelengthLabel(2). This object cannot be modified if gmplsLabelRowStatus is active(1)." REFERENCE "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, Berger, L. (Editor), RFC 3471, January 2003." DEFVAL { 0 } ::=3D { gmplsLabelEntry 7 } gmplsLabelFreeform OBJECT-TYPE SYNTAX GmplsFreeformLabel MAX-ACCESS read-create STATUS current DESCRIPTION "The value of a freeform Generalized Label that does not conform to one of the standardized label encoding or that an implementation chooses to represent as an octet string without further Nadeau and Farrel (Editors) [Page 24] =0C Internet Draft draft-ietf-ccamp-gmpls-lsr-mib-06.txt October 2004 decoding. Only valid if gmplsLabelType is set to gmplsFreeformGeneralizedLabel(3). This object cannot be modified if gmplsLabelRowStatus is active(1)." ::=3D { gmplsLabelEntry 8 } gmplsLabelSonetSdhSignalIndex OBJECT-TYPE SYNTAX Integer32 (0..4095) MAX-ACCESS read-create STATUS current DESCRIPTION "The Signal Index value (S) of a SONET or SDH Generalized Label. Zero indicates that this field is not significant. Only valid if gmplsLabelType is set to gmplsSonetLabel(4) or gmplsSdhLabel(5). This object cannot be modified if gmplsLabelRowStatus is active(1)." REFERENCE "Generalized Multi-Protocol Label Switching Extensions for SONET and SDH Control, Mannie, E., Papadimitriou, D. (Editors), draft-ietf-ccamp-gmpls-sonet-sdh-08.txt, February 2003, work in progress." DEFVAL { 0 } ::=3D { gmplsLabelEntry 9 } gmplsLabelSdhVc OBJECT-TYPE SYNTAX Integer32 (0..15) MAX-ACCESS read-create STATUS current DESCRIPTION "The VC Indicator (U) of an SDH Generalized Label. Zero indicates that this field is non-significant. Only valid if gmplsLabelType is set to gmplsSdhLabel(5). This object cannot be modified if gmplsLabelRowStatus is active(1)." REFERENCE "Generalized Multi-Protocol Label Switching Extensions for SONET and SDH Control, Mannie, E., Papadimitriou, D. (Editors), draft-ietf-ccamp-gmpls-sonet-sdh-08.txt, February 2003, work in progress." DEFVAL { 0 } ::=3D { gmplsLabelEntry 10 } gmplsLabelSdhVcBranch OBJECT-TYPE SYNTAX Integer32 (0..15) MAX-ACCESS read-create STATUS current DESCRIPTION "The VC Branch Indicator (K) of an SDH Generalized Label. Zero indicates that this field is non-significant. Only valid if gmplsLabelType is set to gmplsSdhLabel(5). This object cannot be modified if gmplsLabelRowStatus is active(1)." Nadeau and Farrel (Editors) [Page 25] =0C Internet Draft draft-ietf-ccamp-gmpls-lsr-mib-06.txt October 2004 REFERENCE "Generalized Multi-Protocol Label Switching Extensions for SONET and SDH Control, Mannie, E., Papadimitriou, D. (Editors), draft-ietf-ccamp-gmpls-sonet-sdh-08.txt, February 2003, work in progress." DEFVAL { 0 } ::=3D { gmplsLabelEntry 11 } gmplsLabelSonetSdhBranch OBJECT-TYPE SYNTAX Integer32 (0..15) MAX-ACCESS read-create STATUS current DESCRIPTION "The Branch Indicator (L) of a SONET or SDH Generalized Label. Zero indicates that this field is non-significant. Only valid gmplsLabelType is set to gmplsSonetLabel(4) or gmplsSdhLabel(5). This object cannot be modified if gmplsLabelRowStatus is active(1)." REFERENCE "Generalized Multi-Protocol Label Switching Extensions for SONET and SDH Control, Mannie, E., Papadimitriou, D. (Editors), draft-ietf-ccamp-gmpls-sonet-sdh-08.txt, February 2003, work in progress." DEFVAL { 0 } ::=3D { gmplsLabelEntry 12 } gmplsLabelSonetSdhGroupBranch OBJECT-TYPE SYNTAX Integer32 (0..15) MAX-ACCESS read-create STATUS current DESCRIPTION "The Group Branch Indicator (M) of a SONET or SDH Generalized Label. Zero indicates that this field is non-significant. Only valid if gmplsLabelType is set to gmplsSonetLabel(4) or gmplsSdhLabel(5). This object cannot be modified if gmplsLabelRowStatus is active(1)." REFERENCE "Generalized Multi-Protocol Label Switching Extensions for SONET and SDH Control, Mannie, E., Papadimitriou, D. (Editors), draft-ietf-ccamp-gmpls-sonet-sdh-08.txt, February 2003, work in progress." DEFVAL { 0 } ::=3D { gmplsLabelEntry 13 } gmplsLabelWavebandId OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current Nadeau and Farrel (Editors) [Page 26] =0C Internet Draft draft-ietf-ccamp-gmpls-lsr-mib-06.txt October 2004 DESCRIPTION "The waveband identifier component of a waveband label. Only valid if gmplsLabelType is set to gmplsWavebandLabel(6). This object cannot be modified if gmplsLabelRowStatus is active(1)." REFERENCE "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, Berger, L. (Editor), RFC 3471, January 2003." DEFVAL { 0 } ::=3D { gmplsLabelEntry 14 } gmplsLabelWavebandStart OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The starting label component of a waveband label. Only valid if gmplsLabelType is set to gmplsWavebandLabel(6). This object cannot be modified if gmplsLabelRowStatus is active(1)." REFERENCE "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, Berger, L. (Editor), RFC 3471, January 2003." DEFVAL { 0 } ::=3D { gmplsLabelEntry 15 } gmplsLabelWavebandEnd OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The end label component of a waveband label. Only valid if gmplsLabelType is set to gmplsWavebandLabel(6). This object cannot be modified if gmplsLabelRowStatus is active(1)." REFERENCE "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, Berger, L. (Editor), RFC 3471, January 2003." DEFVAL { 0 } ::=3D { gmplsLabelEntry 16 } gmplsLabelRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This variable is used to create, modify, and/or delete a row in this table. When a row in this Nadeau and Farrel (Editors) [Page 27] =0C Internet Draft draft-ietf-ccamp-gmpls-lsr-mib-06.txt October 2004 table has a row in the active(1) state, no objects in this row can be modified except the gmplsLabelRowStatus and gmplsLabelStorageType." ::=3D { gmplsLabelEntry 17 } gmplsLabelStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "This variable indicates the storage type for this object. The agent MUST ensure that this object's value remains consistent with the storage type of any rows in other tables that contain pointers to this row. In particular, the storage type of this row must be at least as permanent as that of any row that point to it. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." REFERENCE "See RFC2579." DEFVAL { volatile } ::=3D { gmplsLabelEntry 18 } -- End of GMPLS Label Table -- Module compliance. gmplsLabelGroups OBJECT IDENTIFIER ::=3D { gmplsLabelConformance 1 } gmplsLabelCompliances OBJECT IDENTIFIER ::=3D { gmplsLabelConformance 2 } gmplsLabelModuleFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance statement for agents that support the GMPLS Label MIB module." MODULE -- this module -- The mandatory groups have to be implemented by LSRs claiming -- support for this MIB module. This MIB module is, however, not -- mandatory for a working implementation of a GMPLS LSR with full -- MIB support if the GMPLS labels in use can be represented within -- a 32 bit quantity. MANDATORY-GROUPS { gmplsLabelTableGroup } Nadeau and Farrel (Editors) [Page 28] =0C Internet Draft draft-ietf-ccamp-gmpls-lsr-mib-06.txt October 2004 -- Units of conformance. GROUP gmplsLabelTableGroup DESCRIPTION "This group is mandatory for devices which support the gmplsLabelTable." GROUP gmplsLabelPacketGroup DESCRIPTION "This group extends gmplsLabelTableGroup for implementations that support packet labels." GROUP gmplsLabelPortWavelengthGroup DESCRIPTION "This group extends gmplsLabelTableGroup for implementations that support port and wavelength labels." GROUP gmplsLabelFreeformGroup DESCRIPTION "This group extends gmplsLabelTableGroup for implementations that support freeform labels." GROUP gmplsLabelSonetSdhGroup DESCRIPTION "This group extends gmplsLabelTableGroup for implementations that support SONET or SDH labels." GROUP gmplsLabelWavebandGroup DESCRIPTION "This group extends gmplsLabelTableGroup for implementations that support Waveband labels." -- gmplsLabelTable OBJECT gmplsLabelType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsLabelMplsLabel MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsLabelPortWavelength MIN-ACCESS read-only DESCRIPTION "Write access is not required." Nadeau and Farrel (Editors) [Page 29] =0C Internet Draft draft-ietf-ccamp-gmpls-lsr-mib-06.txt October 2004 OBJECT gmplsLabelFreeform MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsLabelSonetSdhSignalIndex MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsLabelSdhVc MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsLabelSdhVcBranch MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsLabelSonetSdhBranch MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsLabelSonetSdhGroupBranch MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsLabelWavebandId MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsLabelWavebandStart MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsLabelWavebandEnd MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsLabelRowStatus SYNTAX RowStatus { active(1), notInService(2) } Nadeau and Farrel (Editors) [Page 30] =0C Internet Draft draft-ietf-ccamp-gmpls-lsr-mib-06.txt October 2004 WRITE-SYNTAX RowStatus { active(1), notInService(2), createAndGo(4), destroy(6) } DESCRIPTION "Support for notInService, createAndWait and notReady is not required." OBJECT gmplsLabelStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::=3D { gmplsLabelCompliances 1 } -- Units of conformance. gmplsLabelTableGroup OBJECT-GROUP OBJECTS { gmplsLabelIndexNext, gmplsLabelType, gmplsLabelRowStatus, gmplsLabelStorageType } STATUS current DESCRIPTION "Necessary, but not sufficient, set of objects to implement label table support. In addition, depending on the type of labels supported (for example, wavelength labels), the following other groups defined below are mandatory: gmplsLabelPacketGroup and/or gmplsLabelPortWavelengthGroup and/or gmplsLabelFreeformGroup and/or gmplsLabelSonetSdhGroup." ::=3D { gmplsLabelGroups 1 } gmplsLabelPacketGroup OBJECT-GROUP OBJECTS { gmplsLabelMplsLabel } STATUS current DESCRIPTION "Object needed to implement Packet (MPLS) labels." ::=3D { gmplsLabelGroups 2 } Nadeau and Farrel (Editors) [Page 31] =0C Internet Draft draft-ietf-ccamp-gmpls-lsr-mib-06.txt October 2004 gmplsLabelPortWavelengthGroup OBJECT-GROUP OBJECTS { gmplsLabelPortWavelength } STATUS current DESCRIPTION "Object needed to implement Port and Wavelength labels." ::=3D { gmplsLabelGroups 3 } gmplsLabelFreeformGroup OBJECT-GROUP OBJECTS { gmplsLabelFreeform } STATUS current DESCRIPTION "Object needed to implement Freeform labels." ::=3D { gmplsLabelGroups 4 } gmplsLabelSonetSdhGroup OBJECT-GROUP OBJECTS { gmplsLabelSonetSdhSignalIndex, gmplsLabelSdhVc, gmplsLabelSdhVcBranch, gmplsLabelSonetSdhBranch, gmplsLabelSonetSdhGroupBranch } STATUS current DESCRIPTION "Object needed to implement SONET and SDH labels." ::=3D { gmplsLabelGroups 5 } gmplsLabelWavebandGroup OBJECT-GROUP OBJECTS { gmplsLabelWavebandId, gmplsLabelWavebandStart, gmplsLabelWavebandEnd } STATUS current DESCRIPTION "Object needed to implement Waveband labels." ::=3D { gmplsLabelGroups 6 } END 9. Security Considerations It is clear that the MIB modules described in this document in association with the MPLS-LSR-STD-MIB are potentially useful for monitoring of GMPLS LSRs. These MIB modules can also be used for configuration of certain objects, and anything that can be configured Nadeau and Farrel (Editors) [Page 32] =0C Internet Draft draft-ietf-ccamp-gmpls-lsr-mib-06.txt October 2004 can be incorrectly configured, with potentially disastrous results. There are a number of management objects defined in these MIB modules with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: o the gmplsInterfaceTable, gmplsInSegmentTable, gmplsOutSegmentTable and gmplsLabelTable collectively contain objects to provision GMPLS interfaces, LSPs and their associated parameters on a Label Switching Router (LSR). Unauthorized write access to objects in these tables, could result in disruption of traffic on the network. This is especially true if an LSP has already been established. The use of stronger mechanisms such as SNMPv3 security should be considered where possible. Specifically, SNMPv3 VACM and USM MUST be used with any SNMPv3 agent which implements these MIB modules. Some of the readable objects in these MIB modules "i.e., objects with a MAX-ACCESS other than not-accessible" may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: o the gmplsInterfaceTable, gmplsInSegmentTable, gmplsOutSegmentTable and gmplsLabelTable collectively show the LSP network topology and its capabilities. If an Administrator does not want to reveal this information, then these tables should be considered sensitive/vulnerable. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure "for example by using IPSec", even then, there is no control as to who on the secure network is allowed to access and GET/SET "read/change/create/delete" the objects in these MIB modules. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework "see [RFC3410], section 8", including full support for the SNMPv3 cryptographic mechanisms "for authentication and privacy". Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module, is properly configured to give access to the objects only to those principals "users" that have legitimate rights to indeed GET or SET "change/create/delete" them. Nadeau and Farrel (Editors) [Page 33] =0C Internet Draft draft-ietf-ccamp-gmpls-lsr-mib-06.txt October 2004 10. Acknowledgments This draft is the work of the five authors listed in the Authors' Addresses section. This document extends [RFC3813]. The authors would like to express their gratitude to all those who worked on that earlier MIB document. The authors would like to express their thanks to Dan Joyle for his careful review and comments on early versions of the Label Table. Special thanks to Joan Cucchiara and Len Nieman for their help with compilation issues. 11. IANA Considerations MPLS related standards track MIB modules are rooted under the mplsStdMIB subtree. One of the MIB modules contained in this document extends tables contained in MPLS MIB modules. As requested in requested in the GMPLS-TC-STD-MIB [GMPLSTCMIB] the two MIB modules contained in this document should be placed in the mplsStdMIB subtree as well. New assignments can only be made via a Standards Action as specified in [RFC2434]. 11.1. IANA Considerations for GMPLS-LSR-STD-MIB The IANA is requested to assign { mplsStdMIB xx } to the GMPLS-LSR-STD-MIB module specified in this document. 11.2. IANA Considerations for GMPLS-LABEL-STD-MIB The IANA is requested to assign { mplsStdMIB xx } to the GMPLS-LABEL-STD-MIB module specified in this document. 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. Nadeau and Farrel (Editors) [Page 34] =0C Internet Draft draft-ietf-ccamp-gmpls-lsr-mib-06.txt October 2004 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2863] McCloghrie, K. and F. Kastenholtz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3289] Baker, F., Chan, K., and A. Smith, "Management Information Base for the Differentiated Services Architecture", RFC 3289, May 2002. [RFC3443] Agarwal, P. and Akyol, B., "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, January 2003. [RFC3811] Nadeau, T. and J. Cucchiara, "Definition of Textual Conventions and for Multiprotocol Label Switching (MPLS) Management", RFC 3811, June 2004. [RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Label Switching (LSR) Router Management Information Base (MIB)", RFC 3813, June 2004. [GMPLSArch] Mannie, E. (Editor), "Generalized Multiprotocol Label Switching (GMPLS) Architecture", draft-many-gmpls-architecture-07.txt, May 2003, work in progress. [GMPLSSonetSDH] Mannie, E., Papadimitriou, D. (Editors), "Generalized Multi-Protocol Label Switching Extensions for SONET and SDH Control", draft-ietf-ccamp-gmpls-sonet-sdh-08.txt, February 2003, work in progress. [GMPLSTCMIB] Nadeau, T., Farrel, A., (Editors) "Definitions of Textual Conventions for Multiprotocol Label Switching (MPLS) Management", draft-ietf-ccamp-gmpls-te-mib-06.txt, October 2004, work in progress. Nadeau and Farrel (Editors) [Page 35] =0C Internet Draft draft-ietf-ccamp-gmpls-lsr-mib-06.txt October 2004 [GMPLSTEMIB] Nadeau, T., Farrel, A. (Editors) "Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base", draft-ietf-ccamp-gmpls-te-mib-06.txt, October 2004, work in progress. 12.2. Informational References [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", RFC 2026, October 1996. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP: 26, RFC 2434, October 1998. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC3032] Rosen, E. et al, "MPLS Label Stack Encoding", RFC 3032, January 2001. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3212] Jamoussi, B., Aboul-Magd, O., Andersson, L., Ashwood-Smith, P., Hellstrand, F., Sundell, K., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Halpern, J., Heinanen, J., Kilty, T., Malis, A., and P. Vaananen, "Constraint-Based LSP Setup using LDP", RFC 3212, December 2001." [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", RFC 3411, December 2002. [RFC3413] Levi, D., Meyer, P., Stewart, B., "SNMP Applications", RFC 3413, December 2002. [RFC3471] Berger, L. (Editor), "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. Nadeau and Farrel (Editors) [Page 36] =0C Internet Draft draft-ietf-ccamp-gmpls-lsr-mib-06.txt October 2004 [RFC3472] Ashwood-Smith, P., Berger, L. (Editors), "Generalized MPLS Signaling - CR-LDP Extensions", RFC 3472, January 2003. [RFC3473] Berger, L. (Editor), "Generalized MPLS Signaling - RSVP-TE Extensions", RFC 3473 January 2003. [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004. 13. Authors' Addresses Thomas D. Nadeau Cisco Systems, Inc. 300 Apollo Drive Chelmsford, MA 01824 Phone: +1-978-244-3051 Email: tnadeau@cisco.com Cheenu Srinivasan Bloomberg L.P. 499 Park Ave., New York, NY 10022 Phone: +1-212-893-3682 Email: cheenu@bloomberg.net Adrian Farrel Old Dog Consulting Phone: +44-(0)-1978-860944 Email: adrian@olddog.co.uk Tim Hall Data Connection Ltd. 100 Church Street Enfield, Middlesex, EN2 6BQ, UK Phone: +44 20 8366 1177 Email: tim.hall@dataconnection.com Ed Harrison Data Connection Ltd. 100 Church Street Enfield, Middlesex, EN2 6BQ, UK Phone: +44 20 8366 1177 Email: ed.harrison@dataconnection.com 14. Intellectual Property Considerations The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to Nadeau and Farrel (Editors) [Page 37] =0C Internet Draft draft-ietf-ccamp-gmpls-lsr-mib-06.txt October 2004 pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 15. Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 16. Changes This section must be removed before the draft progresses to RFC. 16.1. Changes from version 5 to version 6 - ID nits and MIB bolierplate 16.2. Changes from version 4 to version 5 - New IPR and copyright boiler plate. - Clarify description of gmplsInterfaceSignalingCaps. Nadeau and Farrel (Editors) [Page 38] =0C Internet Draft draft-ietf-ccamp-gmpls-lsr-mib-06.txt October 2004 16.3. Changes from version 3 to version 4 - Update references. - Allow configuration of the Hello timer per interface. - Provide support for monitoring technology-specific resources or performance through an arbitrary row pointer. - Retire unnecessary gmplsLabelFreeformLength. - Update examples. 16.4. Changes from version 2 to version 3 - Work on basic compilation issues. - Provide a next index object to supply the next available arbitrary index into the Label Table. - Update references. - Update examples. Nadeau and Farrel (Editors) [Page 39] =0C ------=_NextPart_000_0E00_01C4BDF2.F8398130 Content-Type: text/plain; name="draft-ietf-ccamp-gmpls-te-mib-06.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-ccamp-gmpls-te-mib-06.txt" CCAMP Working Group Thomas D. Nadeau, Ed. Internet Draft Cisco Systems, Inc. Proposed Status: Standards Track Expires: April 2005 Adrian Farrel, Ed. Old Dog Consulting October 2004 Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base draft-ietf-ccamp-gmpls-te-mib-06.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for Generalized Multiprotocol Label Switching (GMPLS) based traffic engineering. Nadeau and Farrel (Editors) [Page 1] =0C Internet Draft draft-ietf-ccamp-gmpls-te-mib-06.txt October 2004 Table of Contents 1. Introduction ........................................... 2 1.1. Migration Strategy ................................... 3 2. Terminology ............................................ 3 3. The SNMP Management Framework .......................... 3 4. Outline ................................................ 4 4.1. Summary of GMPLS Traffic Engineering MIB Module ...... 4 5. Brief Description of GMPLS TE MIB Objects .............. 4 5.1. gmplsTunnelTable ..................................... 4 5.2. gmplsTunnelHopTable .................................. 5 5.3. gmplsTunnelARHopTable ................................ 5 5.4. gmplsTunnelCHopTable ................................. 5 5.5. gmplsTunnelErrorTable ................................ 5 5.6. gmplsTunnelReversePerfTable .......................... 5 6. Cross-referencing to the mplsLabelTable ................ 6 7. Example of GMPLS Tunnel Setup .......................... 6 8. GMPLS Traffic Engineering MIB Definitions ............. 10 9. Security Considerations ............................... 43 10. Acknowledgments ...................................... 44 11. IANA Considerations .................................. 44 11.1. IANA Considerations for GMPLS-TE-STD-MIB ........... 44 12. References ........................................... 45 12.1. Normative Refenerces ............................... 45 12.2. Informational References ........................... 46 13. Authors' Addresses ................................... 47 14. Full Copyright Statement ............................. 48 15. Intellectual Property Notice ......................... 48 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling Generalized Multiprotocol Label Switching (GMPLS) [GMPLSArch] based traffic engineering. The tables and objects defined in this document extend those defined in the equivalent document for MPLS traffic engineering [RFC3812], and management of GMPLS traffic engineering is built on management of MPLS traffic engineering. This MIB module should be used in conjunction with the companion document [GMPLSLSRMIB] for GMPLS based traffic engineering configuration and management. Comments should be made direct to the CCAMP mailing list at ccamp@ops.ietf.org. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119, reference [RFC2119]. Nadeau and Farrel (Editors) [Page 2] =0C Internet Draft draft-ietf-ccamp-gmpls-te-mib-06.txt October 2004 1.1. Migration Strategy This MIB module extends the traffic engineering MIB module defined for use with MPLS [RFC3812]. It provides additions for support of GMPLS tunnels. The companion document for modeling and managing GMPLS based LSRs [GMPLSLSRMIB] extends MPLS LSR MIB [RFC3813] with the same intentions. Textual conventions and OBJECT-IDENTIFIERS are defined in [RFC3811] and [GMPLSTCMIB]. 2. Terminology This document uses terminology from the MPLS architecture document [RFC3031], from the GMPLS architecture document [GMPLSArch], and from the MPLS Traffic Engineering MIB [RFC3812]. Some frequently used terms are described next. An explicitly routed LSP (ERLSP) is referred to as a GMPLS tunnel. It consists of in-segment(s) and/or out-segment(s) at the egress/ingress LSRs, each segment being associated with one GMPLS enabled interface. These are also referred to as tunnel segments. Additionally, at an intermediate LSR, we model a connection as consisting of one or more in-segments and/or one or more out-segments. The binding or interconnection between in-segments and out-segments in performed using a cross-connect. These segment and cross-connect objects are defined in the MPLS Label Switch Router MIB [RFC3813], but see also the GMPLS Label Switch Router MIB [GMPLSLSRMIB] for the GMPLS-specific extensions to these objects. 3. The SNMP Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. Nadeau and Farrel (Editors) [Page 3] =0C Internet Draft draft-ietf-ccamp-gmpls-te-mib-06.txt October 2004 4. Outline Support for GMPLS traffic-engineered tunnels requires the following configuration. - Setting up tunnels with appropriate MPLS configuration parameters using [RFC3812]. - Extending the tunnels with GMPLS configuration parameters. - Configuring tunnel loose and strict source routed hops. These actions may need to be accompanied with corresponding actions using [RFC3813] and [GMPLSLSRMIB] to establish and configure tunnel segments, if this is done manually. Also, the in-segment and out-segment performance tables, mplsInSegmentPerfTable and mplsOutSegmentPerfTable [RFC3813], should be used to determine performance of the tunnels and tunnel segments although it should be noted that those tables may not be appropriate for measuring performance on some types of GMPLS links. 4.1. Summary of GMPLS Traffic Engineering MIB Module The MIB objects for performing the actions listed above that cannot be performed solely using the MIB objects defined in [RFC3812] consist of the following tables. - Tunnel Table (gmplsTunnelTable) for providing GMPLS-specific tunnel configuration parameters. - Tunnel specified, actual, and computed hop tables (gmplsTunnelHopTable, gmplsTunnelARHopTable, and gmplsTunnelCHopTable) for providing additional configuration of strict and loose source routed tunnel hops. - Performance and error reporting tables (gmplsTunnelReversePerfTable and gmplsTunnelErrorTable). These tables are described in the subsequent sections. Additionally, this MIB module contains a new Notification. - The GMPLS Tunnel Down Notification (gmplsTunnelDown) is intended to be used in place of the mplsTunnelDown Notification defined in [RFC3812]. As well as indicating that a tunnel has transitioned to operational down state, this new Notificaiton indicates the cause of the failure. 5. Brief Description of GMPLS TE MIB Objects The objects described in this section support the functionality described in [RFC3473] and [RFC3472] for GMPLS tunnels. The tables support both manually configured and signaled tunnels. Nadeau and Farrel (Editors) [Page 4] =0C Internet Draft draft-ietf-ccamp-gmpls-te-mib-06.txt October 2004 5.1. gmplsTunnelTable The gmplsTunnelTable extends the MPLS traffic engineering MIB module to allow GMPLS tunnels to be created between an LSR and a remote endpoint, and existing GMPLS tunnels to be reconfigured or removed. Note that we only support point-to-point tunnel segments, although multi-point-to-point and point-to-multi-point connections are supported by an LSR acting as a cross-connect. Each tunnel can thus have one out-segment originating at an LSR and/or one in-segment terminating at that LSR. 5.2. gmplsTunnelHopTable The gmplsTunnelHopTable is used to indicate additional parameters for the hops, strict or loose, of a GMPLS tunnel defined in gmplsTunnelTable, when it is established using signaling. Multiple tunnels may share hops by pointing to the same entry in this table. 5.3. gmplsTunnelARHopTable The gmplsTunnelARHopTable is used to indicate the actual hops traversed by a tunnel as reported by the signaling protocol after the tunnel is setup. The support of this table is optional since not all GMPLS signaling protocols support this feature. 5.4. gmplsTunnelCHoptable The gmplsTunnelCHopTable lists the actual hops computed by a constraint-based routing algorithm based on the gmplsTunnelHopTable. The support of this table is optional since not all implementations support computation of hop lists using a constraint-based routing protocol. 5.5. gmplsTunnelErrorTable The gmplsTunnelErrorTable provides access to information about the last error that occurred on each tunnel known about by the MIB. It indicates the nature of the error, when and how it was reported and can give recovery advice through a display string. 5.6. gmplsTunnelReversePerfTable gmplsTunnelReversePerfTable provides additional counters to measure the performance of bidirectional GMPLS tunnels in which packets are visible. It supplements the counters in mplsTunnelPerfTable and augments gmplsTunnelTable. Note that not all counters may be appropriate or available for some types of tunnel. Nadeau and Farrel (Editors) [Page 5] =0C Internet Draft draft-ietf-ccamp-gmpls-te-mib-06.txt October 2004 6. Cross-referencing to the gmplsLabelTable The gmplsLabelTable is found in a MIB module in [GMPLSLSRMIB] and provides a way to model labels in a GMPLS system where labels might not be simple 32 bit integers. The hop tables in this document (gmplsHopTable, gmplsCHopTable and gmplsARHopTable) and the segment tables in the [RFC3813] (mplsInSegmentTable and mplsOutSegmentTable) contain objects with syntax MplsLabel. MplsLabel (defined in [RFC3811]) is a 32-bit integer that is capable of representing any MPLS label and most GMPLS labels. However, some GMPLS labels are larger than 32 bits and may be of arbitrary length. Further, some labels that may be safely encoded in 32 bits are constructed from multiple sub-fields. Additionally, some GMPLS technologies support the concatenation of individual labels to represent a data flow carried as multiple sub-flows. These GMPLS cases require that something other than a simple 32-bit integer is made available to represent the labels. This is achieved through the gmplsLabelTable contained in [GMPLSLSRMIB]. The tables in this document and [RFC3813] that include objects with syntax MplsLabel also include companion objects that are row pointers. If the row pointer is set to zeroDotZero (0.0) then object of syntax MplsLabel contains the label encoded as a 32-bit integer. But otherwise the row pointer indicates a row in another MIB table that includes the label. In these cases, the row pointer may indicate a row in the gmplsLabelTable. This provides both a good way to support legacy systems that implement the previous version of this MIB module [RFC3812], and a significant simplification in GMPLS systems that are limited to a single, simple label type. Note that gmplsLabelTable supports concatenated labels through the use of a label sub-index (gmplsLabelSubindex). 7. Example of GMPLS Tunnel Setup This section contains an example of which MIB objects should be modified to create a GMPLS tunnel. This example shows a best effort, loosely routed, bidirectional traffic engineered tunnel, which spans two hops of a simple network, uses Generalized Label requests with Lambda encoding, has label recording and shared link layer protection. Note that these objects should be created on the "head-end" LSR. Nadeau and Farrel (Editors) [Page 6] =0C Internet Draft draft-ietf-ccamp-gmpls-te-mib-06.txt October 2004 First in the mplsTunnelTable: { mplsTunnelIndex =3D 1, mplsTunnelInstance =3D 1, mplsTunnelIngressLSRId =3D 123.123.125.1, mplsTunnelEgressLSRId =3D 123.123.126.1, mplsTunnelName =3D "My first tunnel", mplsTunnelDescr =3D "Here to there and back again", mplsTunnelIsIf =3D true (1), mplsTunnelXCPointer =3D mplsXCIndex.3.0.0.12, mplsTunnelSignallingProto =3D none (1), mplsTunnelSetupPrio =3D 0, mplsTunnelHoldingPrio =3D 0, mplsTunnelSessionAttributes =3D recordRoute (4), mplsTunnelOwner =3D snmp (2), mplsTunnelLocalProtectInUse =3D false (0), mplsTunnelResourcePointer =3D mplsTunnelResourceIndex.6, mplsTunnelInstancePriority =3D 1, mplsTunnelHopTableIndex =3D 1, mplsTunnelPrimaryInstance =3D 0, mplsTunnelIncludeAnyAffinity =3D 0, mplsTunnelIncludeAllAffinity =3D 0, mplsTunnelExcludeAnyAffinity =3D 0, mplsTunnelPathInUse =3D 1, mplsTunnelRole =3D head(1), mplsTunnelRowStatus =3D createAndWait (5), } In gmplsTunnelTable(1,1,123.123.125.1,123.123.126.1): { gmplsTunnelUnnumIf =3D true (1), gmplsTunnelAttributes =3D labelRecordingRequired (1), gmplsTunnelLSPEncoding =3D tunnelLspLambda (8), gmplsTunnelSwitchingType =3D lsc (150), gmplsTunnelLinkProtection =3D shared (2), gmplsTunnelGPid =3D lambda (37), gmplsTunnelSecondary =3D false(0), gmplsTunnelDirection =3D bidirectional (1) gmplsTunnelPathComp =3D explicit(2), gmplsTunnelUpNotRecip =3D 0x7B7B7D01, gmplsTunnelDownNotRecip =3D 0x00000000, gmplsTunnelAdminStatusFlags =3D 0, gmplsTunnelExtraParamsPtr =3D 0.0 } Entries in the mplsTunnelResourceTable, mplsTunnelHopTable and gmplsTunnelHopTable are created and activated at this time. Nadeau and Farrel (Editors) [Page 7] =0C Internet Draft draft-ietf-ccamp-gmpls-te-mib-06.txt October 2004 In mplsTunnelResourceTable: { mplsTunnelResourceIndex =3D 6, mplsTunnelResourceMaxRate =3D 0, mplsTunnelResourceMeanRate =3D 0, mplsTunnelResourceMaxBurstSize =3D 0, mplsTunnelResourceRowStatus =3D createAndGo (4) } The next two instances of mplsTunnelHopEntry are used to denote the hops this tunnel will take across the network. The following denotes the beginning of the network, or the first hop. We have used the fictitious LSR identified by "123.123.125.1" as our example head-end router. In mplsTunnelHopTable: { mplsTunnelHopListIndex =3D 1, mplsTunnelPathOptionIndex =3D 1, mplsTunnelHopIndex =3D 1, mplsTunnelHopAddrType =3D ipV4 (1), mplsTunnelHopIpv4Addr =3D 123.123.125.1, mplsTunnelHopIpv4PrefixLen =3D 9, mplsTunnelHopType =3D strict (1), mplsTunnelHopRowStatus =3D createAndWait (5), } The following denotes the end of the network, or the last hop in our example. We have used the fictitious LSR identified by "123.123.126.1" as our end router. In mplsTunnelHopTable: { mplsTunnelHopListIndex =3D 1, mplsTunnelPathOptionIndex =3D 1, mplsTunnelHopIndex =3D 2, mplsTunnelHopAddrType =3D ipV4 (1), mplsTunnelHopIpv4Addr =3D 123.123.126.1, mplsTunnelHopIpv4PrefixLen =3D 9, mplsTunnelHopType =3D loose (2), mplsTunnelHopRowStatus =3D createAndGo (4) } Now an associated entry in the gmplsTunnelHopTable is created to provide additional GMPLS hop configuration indicating that the first hop is an unnumbered link using explicit forward and reverse labels. An entry in the gmplsLabelTable is created first to include the explicit label. Nadeau and Farrel (Editors) [Page 8] =0C Internet Draft draft-ietf-ccamp-gmpls-te-mib-06.txt October 2004 In gmplsLabelTable: { gmplsLabelInterface =3D 2, gmplsLabelIndex =3D 1, gmplsLabelSubindex =3D 0, gmplsLabelType =3D = gmplsFreeformGeneralizedLabel(3), gmplsLabelFreeform =3D 0xFEDCBA9876543210 gmplsLabelRowStatus =3D createAndGo(4) } In gmplsTunnelHopTable(1,1,1): { gmplsTunnelHopLabelStatuses =3D forwardPresent(0) +reversePresent(1), gmplsTunnelHopExpLabelPtr =3D gmplsLabelTable (2, 1, 0) gmplsTunnelHopExpRvrsLabelPtr =3D gmplsLabelTable (2, 1, 0) } The first hop is now activated: In mplsTunnelHopTable(1,1,1): { mplsTunnelHopRowStatus =3D active (1) } No gmplsTunnelHopEntry is created for the second hop as it contains no special GMPLS features. Finally the mplsTunnelEntry is activated: In mplsTunnelTable(1,1,123.123.125.1,123.123.126.1) { mplsTunnelRowStatus =3D active(1) } Nadeau and Farrel (Editors) [Page 9] =0C Internet Draft draft-ietf-ccamp-gmpls-te-mib-06.txt October 2004 8. GMPLS Traffic Engineering MIB Definitions GMPLS-TE-STD-MIB DEFINITIONS ::=3D BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Integer32, Unsigned32, Counter32, Counter64, IpAddress, zeroDotZero FROM SNMPv2-SMI -- [RFC2578] MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF -- [RFC2580] TruthValue, TimeStamp, DisplayString, RowPointer FROM SNMPv2-TC -- [RFC2579] InetAddress FROM INET-ADDRESS-MIB -- [RFC3291] mplsTunnelIndex, mplsTunnelInstance, mplsTunnelIngressLSRId, mplsTunnelEgressLSRId, mplsTunnelHopListIndex, mplsTunnelHopPathOptionIndex, mplsTunnelHopIndex, mplsTunnelARHopListIndex, mplsTunnelARHopIndex, mplsTunnelCHopListIndex, mplsTunnelCHopIndex, mplsTunnelEntry, mplsTunnelAdminStatus, mplsTunnelOperStatus FROM MPLS-TE-STD-MIB -- [RFC3812] mplsStdMIB FROM MPLS-TC-STD-MIB -- [RFC3811] ; gmplsTeStdMIB MODULE-IDENTITY LAST-UPDATED "200410080001Z" -- 8 October 2004 00:00:01 GMT ORGANIZATION "Common Control And Measurement Plane (CCAMP) Working Group" CONTACT-INFO " Thomas D. Nadeau Cisco Systems, Inc. Email: tnadeau@cisco.com Adrian Farrel Old Dog Consulting Email: adrian@olddog.co.uk Comments about this document should be emailed direct to the CCAMP working group mailing list at ccamp@ops.ietf.org" DESCRIPTION "Copyright (C) The Internet Society (2004). The initial version of this MIB module was published in RFC xxxx. For full legal notices see the RFC itself or see: http://www.ietf.org/copyrights/ianamib.html Nadeau and Farrel (Editors) [Page 10] =0C Internet Draft draft-ietf-ccamp-gmpls-te-mib-06.txt October 2004 This MIB module contains managed object definitions for GMPLS Traffic Engineering (TE) as defined in: 1. Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, Berger, L. (Editor), RFC 3471, January 2003. 2. Generalized MPLS Signaling - RSVP-TE Extensions, Berger, L. (Editor), RFC 3473, January 2003." -- Revision history. REVISION "200410080001Z" -- 8 October 2004 00:00:01 GMT DESCRIPTION "Initial version issued as part of RFC XXXX." ::=3D { mplsStdMIB xx } -- Top level components of this MIB. -- Notifications gmplsTeNotifications OBJECT IDENTIFIER ::=3D { gmplsTeStdMIB 0 } -- tables, scalars gmplsTeScalars OBJECT IDENTIFIER ::=3D { gmplsTeStdMIB 1 } gmplsTeObjects OBJECT IDENTIFIER ::=3D { gmplsTeStdMIB 2 } -- conformance gmplsTeConformance OBJECT IDENTIFIER ::=3D { gmplsTeStdMIB 3 } -- GMPLS Tunnel scalars. gmplsTunnelsConfigured OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of GMPLS tunnels configured on this device. A GMPLS tunnel is considered configured if an entry for the tunnel exists in the gmplsTunnelTable and the associated mplsTunnelRowStatus is active(1)." ::=3D { gmplsTeScalars 1 } gmplsTunnelsActive OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of GMPLS tunnels active on this device. A GMPLS tunnel is considered active if there is an entry in the gmplsTunnelTable and the associated mplsTunnelOperStatus for the tunnel is up(1)." ::=3D { gmplsTeScalars 2 } -- End of GMPLS Tunnel scalars. Nadeau and Farrel (Editors) [Page 11] =0C Internet Draft draft-ietf-ccamp-gmpls-te-mib-06.txt October 2004 -- GMPLS tunnel table. gmplsTunnelTable OBJECT-TYPE SYNTAX SEQUENCE OF GmplsTunnelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The gmplsTunnelTable 'extends' the mplsTunnelTable. It allows GMPLS tunnels to be created between an LSR and a remote endpoint, and existing tunnels to be reconfigured or removed. Note that only point-to-point tunnel segments are supported, although multi-point-to-point and point-to-multi-point connections are supported by an LSR acting as a cross-connect. Each tunnel can thus have one out-segment originating at this LSR and/or one in-segment terminating at this LSR. The row status of an entry in this table is controlled by mplsTunnelRowStatus in the corresponding entry in mplsTunnelTable. That is, it is not permitted to create a row in this table, nor to modify an existing row, when the corresponding mplsTunnelRowStatus has value active(1). The exception to this rule is the gmplsTunnelAdminStatusFlags object, which can be modified whilst the tunnel is active." ::=3D { gmplsTeObjects 1 } gmplsTunnelEntry OBJECT-TYPE SYNTAX GmplsTunnelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table in association with the corresponding entry in the mplsTunnelTable represents a GMPLS tunnel. An entry can be created by a network administrator or by an SNMP agent as instructed by a signaling protocol." INDEX { mplsTunnelIndex, mplsTunnelInstance, mplsTunnelIngressLSRId, mplsTunnelEgressLSRId } ::=3D { gmplsTunnelTable 1 } Nadeau and Farrel (Editors) [Page 12] =0C Internet Draft draft-ietf-ccamp-gmpls-te-mib-06.txt October 2004 GmplsTunnelEntry ::=3D SEQUENCE { gmplsTunnelUnnumIf TruthValue, gmplsTunnelAttributes BITS, gmplsTunnelLSPEncoding Integer32, gmplsTunnelSwitchingType Integer32, gmplsTunnelLinkProtection BITS, gmplsTunnelGPid Integer32, gmplsTunnelSecondary TruthValue, gmplsTunnelDirection INTEGER, gmplsTunnelPathComp INTEGER, gmplsTunnelUpNotRecip IpAddress, gmplsTunnelDownNotRecip IpAddress, gmplsTunnelAdminStatusFlags BITS, gmplsTunnelExtraParamsPtr RowPointer } gmplsTunnelUnnumIf OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Denotes whether or not this tunnel corresponds to an unnumbered interface represented in the interfaces group table. This object is only used if mplsTunnelIsIf is set to 'true'. If both this object and the mplsTunnelIsIf object are set to 'true', the originating LSR adds an LSP_TUNNEL_INTERFACE_ID object to the outgoing Path message. This object contains information that is only used by the terminating LSR." REFERENCE "Signalling Unnumbered Links in RSVP-TE, Kompella, K. and Rekhter, Y., RFC 3477, January 2003." DEFVAL { false } ::=3D { gmplsTunnelEntry 1 } gmplsTunnelAttributes OBJECT-TYPE SYNTAX BITS { labelRecordingDesired (0) } MAX-ACCESS read-create STATUS current DESCRIPTION "This bitmask indicates optional parameters for this tunnel. These bits should be taken in addition to those defined in mplsTunnelSessionAttributes in Nadeau and Farrel (Editors) [Page 13] =0C Internet Draft draft-ietf-ccamp-gmpls-te-mib-06.txt October 2004 order to determine the full set of options to be signaled (for example SESSION_ATTRIBUTES flags in RSVP-TE). The following describes these bitfields: labelRecordingDesired This flag indicates that label information should be included when doing a route record. This bit is not valid unless the recordRoute bit is set." REFERENCE "RSVP-TE: Extensions to RSVP for LSP Tunnels, Awduche et al, RFC 3209, December 2001." DEFVAL { { } } ::=3D { gmplsTunnelEntry 2 } gmplsTunnelLSPEncoding OBJECT-TYPE SYNTAX Integer32 (0..255) MAX-ACCESS read-create STATUS current DESCRIPTION "This object indicates the encoding of the LSP being requested. A value of zero indicates that GMPLS signaling is not in use. Some objects in this MIB module may be of use for MPLS signaling extensions that do not use GMPLS signaling. By setting this object to zero, an application may indicate that only those objects meaningful in MPLS should be examined. The values to use are currently defined in Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, RFC 3471. Further values may be defined in future RFCs. tunnelLspPacket (1), tunnelLspEthernet (2), tunnelLspAnsiEtsiPdh (3), -- the value 4 is deprecated tunnelLspSdhSonet (5), -- the value 6 is deprecated tunnelLspDigitalWrapper (7), tunnelLspLambda (8), tunnelLspFiber (9), -- the value 10 is deprecated tunnelLspFiberChannel (11), tunnelDigitalPath (12), tunnelOpticalChannel (13)" REFERENCE "1. Berger, L., et al., Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, RFC 3471, January 2003. Nadeau and Farrel (Editors) [Page 14] =0C Internet Draft draft-ietf-ccamp-gmpls-te-mib-06.txt October 2004 2. D. Papadimitriou (Editor), Generalized MPLS Signalling Extensions for G.709 Optical Transport Networks Control, draft-ietf-ccamp-gmpls-g709-06.txt, January 2004, work in progress." DEFVAL { 0 } ::=3D { gmplsTunnelEntry 3 } gmplsTunnelSwitchingType OBJECT-TYPE SYNTAX Integer32 (0..255) MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates the type of switching that should be performed on a particular link. This field is needed for links that advertise more than one type of switching capability. Values of this object are as the Switching Capability field defined in Internet Draft OSPF Extensions in Support of Generalized MPLS. Further values may be defined in future RFCs. unknown (0), psc1 (1), psc2 (2), psc3 (3), psc4 (4), l2sc (51), tdm (100), lsc (150), fsc (200) This object is only meaningful if gmplsTunnelLSPEncoding is not set to 0." REFERENCE "1. Kompella, K., Rekhter, Y. (Editors), Routing Extensions in Support of Generalized Multi-Protocol Label Switching, draft-ietf-ccamp-gmpls-routing-09.txt, October 2003, work in progress. 2. Berger, L., et al., Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, RFC 3471, January 2003." DEFVAL { 0 } ::=3D { gmplsTunnelEntry 4 } gmplsTunnelLinkProtection OBJECT-TYPE SYNTAX BITS { extraTraffic(0), unprotected(1), shared (2), dedicatedOneToOne (3), dedicatedOnePlusOne(4), enhanced(5) } MAX-ACCESS read-create STATUS current Nadeau and Farrel (Editors) [Page 15] =0C Internet Draft draft-ietf-ccamp-gmpls-te-mib-06.txt October 2004 DESCRIPTION "This bitmask indicates the level of link protection required. A value of zero (no bits set) indicates that any protection may be used. The following describes these bitfields: extraTraffic Indicates that the LSP should use links that are protecting other (primary) traffic. Such LSPs may be preempted when the links carrying the (primary) traffic being protected fail. unprotected Indicates that the LSP should not use any link layer protection. shared Indicates that a shared link layer protection scheme, such as 1:N protection, should be used to support the LSP. dedicatedOneToOne Indicates that a dedicated link layer protection scheme, i.e., 1:1 protection, should be used to support the LSP. dedicatedOnePlusOne Indicates that a dedicated link layer protection scheme, i.e., 1+1 protection, should be used to support the LSP. enhanced Indicates that a protection scheme that is more reliable than Dedicated 1+1 should be used, e.g., 4 fiber BLSR/MS-SPRING. This object is only meaningful if gmplsTunnelLSPEncoding is not set to 0." REFERENCE "Berger, L., et al., Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, RFC 3471, January 2003." DEFVAL { { } } ::=3D { gmplsTunnelEntry 5 } gmplsTunnelGPid OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "This object indicates the payload carried by the LSP. It is only required when GMPLS will be used for this LSP. Nadeau and Farrel (Editors) [Page 16] =0C Internet Draft draft-ietf-ccamp-gmpls-te-mib-06.txt October 2004 The values to use are currently defined in Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, RFC 3471. Further values may be defined in future RFCs. unknown(0), asynchE4(5), asynchDS3T3(6), asynchE3(7), bitsynchE3(8), bytesynchE3(9), asynchDS2T2(10), bitsynchDS2T2(11), asynchE1(13), bytesynchE1(14), bytesynch31ByDS0(15), asynchDS1T1(16), bitsynchDS1T1(17), bytesynchDS1T1(18), VC11VC12(19), ds1SFAsynch(22), ds1ESFAsynch(23), ds3M23Asynch(24), ds3CBitParityAsynch(25), vtLovc(26), stsSpeHovc(27), posNoScramble16BitCrc(28), posNoScramble32BitCrc(29), posScramble16BitCrc(30), posScramble32BitCrc(31), atm(32) ethernet(33), sdhSonet(34), digitalwrapper(36), lambda(37), ansiEtsiPdh (38), lapsSdh (40), fddi (41), dqdb (42), fiberChannel3 (43), hdlc (44), ethernetV2DixOnly (45), ethernet802dot3Only (46), g709ODUj (47), g709OTUk (48), g709CBRorCBRa (49), g709CBRb (50), g709BSOT (51), g709BSNT (52), gfpIPorPPP (53), gfpEthernetMAC (54), Nadeau and Farrel (Editors) [Page 17] =0C Internet Draft draft-ietf-ccamp-gmpls-te-mib-06.txt October 2004 gfpEthernetPHY (55), g709ESCON (56), g709FICON (57), g709FiberChannel (58) This object is only meaningful if gmplsTunnelLSPEncoding is not set to 0." REFERENCE "1. Berger, L., et al., Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, RFC 3471, January 2003. 2. D. Papadimitriou (Editor), Generalized MPLS Signalling Extensions for G.709 Optical Transport Networks Control, draft-ietf-ccamp-gmpls-g709-06.txt, January 2004, work in progress." DEFVAL { 0 } ::=3D { gmplsTunnelEntry 6 } gmplsTunnelSecondary OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates that the requested LSP is a secondary LSP. This object is only meaningful if gmplsTunnelLSPEncoding is not set to 0." REFERENCE "Berger, L., et al., Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, RFC 3471, January 2003." DEFVAL { false } ::=3D { gmplsTunnelEntry 7 } gmplsTunnelDirection OBJECT-TYPE SYNTAX INTEGER { forward (0), bidirectional (1) } MAX-ACCESS read-create STATUS current DESCRIPTION "Whether this tunnel carries forward data only (is unidirectional) or is bidirectional. Values of this object other than 'forward' are meaningful only if gmplsTunnelLSPEncoding is not set to 0." DEFVAL { forward } ::=3D { gmplsTunnelEntry 8 } Nadeau and Farrel (Editors) [Page 18] =0C Internet Draft draft-ietf-ccamp-gmpls-te-mib-06.txt October 2004 gmplsTunnelPathComp OBJECT-TYPE SYNTAX INTEGER { dynamicFull(1), -- CSPF fully computed explicit(2), -- fully specified path dynamicPartial(3) -- CSPF partially computed } MAX-ACCESS read-create STATUS current DESCRIPTION "This value instructs the source node on how to perform path computation on the explicit route specified by the associated entries in the gmplsTunnelHopTable. dynamicFull The user specifies at least the source and destination of the path and expects that the CSPF will calculate the remainder of the path. explicit The user specifies the entire path for the tunnel to take. This path may contain strict or loose hops. Evaluation of the explicit route will be performed hop by hop through the network. dynamicPartial The user specifies at least the source and destination of the path and expects that the CSPF will calculate the remainder of the path. The path computed by CSPF is allowed to be only partially computed allowing the remainder of the path to be filled in across the network. This object deprecates mplsTunnelHopEntryPathComp." DEFVAL { dynamicFull } ::=3D { gmplsTunnelEntry 9 } gmplsTunnelUpNotRecip OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates the address of the upstream recipient for Notify messages relating to this tunnel. This object is only valid when signaling a tunnel using RSVP. It is also not valid at the tail end of the tunnel. If set to 0, no Notify Request object will be included in outgoing Path messages." REFERENCE "Generalized MPLS Signaling - RSVP-TE Extensions, Berger, L. (Editor), RFC 3473, January 2003." DEFVAL { '00000000'H } -- 0.0.0.0 ::=3D { gmplsTunnelEntry 10 } Nadeau and Farrel (Editors) [Page 19] =0C Internet Draft draft-ietf-ccamp-gmpls-te-mib-06.txt October 2004 gmplsTunnelDownNotRecip OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates the address of the upstream recipient for Notify messages relating to this tunnel. This object is only valid when signaling a tunnel using RSVP. It is also not valid at the head end of the tunnel. If set to 0, no Notify Request object will be included in outgoing Resv messages." REFERENCE "Generalized MPLS Signaling - RSVP-TE Extensions, Berger, L. (Editor), RFC 3473, January 2003." DEFVAL { '00000000'H } -- 0.0.0.0 ::=3D { gmplsTunnelEntry 11 } gmplsTunnelAdminStatusFlags OBJECT-TYPE SYNTAX BITS { delInProgress (0), adminDown (1), testing (2), reflect (31) } MAX-ACCESS read-create STATUS current DESCRIPTION "Determines the setting of the Admin Status flags in the Admin Status object or TLV, as described in RFC 3471. Setting this field to a non-zero value will result in the inclusion of the admin status object on signaling messages. This value of this object can be modified when the corresponding mplsTunnelRowStatus and mplsTunnelAdminStatus is active(1). By doing so, a new signaling message will be triggered including the requested Admin Status object or TLV." REFERENCE "Berger, L., et al., Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, RFC 3471, January 2003." DEFVAL { { } } ::=3D { gmplsTunnelEntry 12 } gmplsTunnelExtraParamsPtr OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create Nadeau and Farrel (Editors) [Page 20] =0C Internet Draft draft-ietf-ccamp-gmpls-te-mib-06.txt October 2004 STATUS current DESCRIPTION "Some Tunnels will run over transports that can usefully support technology-specific additional parameters (for example, SONET resource usage). Such parameters can be supplied in an external table and referenced from here. A value of zeroDotzero in this attribute indicates that there is no such additional information." DEFVAL { zeroDotZero } ::=3D { gmplsTunnelEntry 13 } -- End of gmplsTunnelTable -- Begin gmplsTunnelHopTable gmplsTunnelHopTable OBJECT-TYPE SYNTAX SEQUENCE OF GmplsTunnelHopEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The gmplsTunnelHopTable 'extends' the mplsTunnelHopTable. It is used to indicate the explicit labels to be used in an explicit path for a GMPLS tunnel defined in mplsTunnelTable and gmplsTunnelTable, when it is established using signaling. It does not insert new hops, but does define new values for hops defined in mplsTunnelHopTable. Each row in this table is indexed by the same indexes as mplsTunnelHopTable. It is acceptable for some rows in mplsTunnelHopTable to have corresponding entries in this table and some to have no corresponding entry in this table. The storage type for an entry in this table is inherited from mplsTunnelHopStorageType in the corresponding entry in mplsTunnelHopTable. The row status of an entry in this table is controlled by mplsTunnelHopRowStatus in the corresponding entry in mplsTunnelHopTable. That is, it is not permitted to create a row in this table, nor to modify an existing row, when the corresponding mplsTunnelHopRowStatus has value active(1)." REFERENCE "Generalized MPLS Signaling - RSVP-TE Extensions, Berger, L. (Editor), RFC 3473, January 2003." ::=3D { gmplsTeObjects 2 } Nadeau and Farrel (Editors) [Page 21] =0C Internet Draft draft-ietf-ccamp-gmpls-te-mib-06.txt October 2004 gmplsTunnelHopEntry OBJECT-TYPE SYNTAX GmplsTunnelHopEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table represents additions to a tunnel hop defined in mplsTunnelHopEntry. At an ingress to a tunnel an entry in this table is created by a network administrator for an ERLSP to be set up by a signaling protocol. At transit and egress nodes an entry in this table may be used to represent the explicit path instructions received using the signaling protocol." INDEX { mplsTunnelHopListIndex, mplsTunnelHopPathOptionIndex, mplsTunnelHopIndex } ::=3D { gmplsTunnelHopTable 1 } GmplsTunnelHopEntry ::=3D SEQUENCE { gmplsTunnelHopLabelStatuses BITS, gmplsTunnelHopExpLabel Unsigned32, gmplsTunnelHopExpLabelPtr RowPointer, gmplsTunnelHopExpRvrsLabel Unsigned32, gmplsTunnelHopExpRvrsLabelPtr RowPointer } gmplsTunnelHopLabelStatuses OBJECT-TYPE SYNTAX BITS { forwardPresent (0), reversePresent (1) } MAX-ACCESS read-only STATUS current DESCRIPTION "This bitmask indicates the presence of labels indicated by the gmplsTunnelHopExpLabel or gmplsTunnelHopExpLabelPtr and gmplsTunnelHopExpRvrsLabel or gmplsTunnelHopExpRvrsLabel objects. For the Present bits, a set bit indicates that a label is present for this hop in the route. This allows zero to be a valid label value." DEFVAL { { } } ::=3D { gmplsTunnelHopEntry 1 } Nadeau and Farrel (Editors) [Page 22] =0C Internet Draft draft-ietf-ccamp-gmpls-te-mib-06.txt October 2004 gmplsTunnelHopExpLabel OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "If gmplsTunnelHopLabelStatuses object indicates that a forward label is present and gmplsTunnelHopExpLabelPtr contains the value zeroDotZero, then the label to use on this hop is found in this object encoded within a 32-bit integer." ::=3D { gmplsTunnelHopEntry 2 } gmplsTunnelHopExpLabelPtr OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "If the gmplsTunnelHopLabelStatuses object indicates that a forward label is present, this object contains a pointer to a row in another MIB table (such as the gmplsLabelTable) that contains the label to use on this hop in the forward direction. If the gmplsTunnelHopLabelStatuses object indicates that a forward label is present and this object contains the value zeroDotZero, then the label to use on this hop is found in the gmplsTunnelHopExpLabel object." DEFVAL { zeroDotZero } ::=3D { gmplsTunnelHopEntry 3 } gmplsTunnelHopExpRvrsLabel OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "If the gmplsTunnelHopLabelStatuses object indicates that a reverse label is present and gmplsTunnelHopExpRvrsLabelPtr contains the value zeroDotZero, then the label to use on this hop is found in this object encoded as a 32-bit integer." ::=3D { gmplsTunnelHopEntry 4 } gmplsTunnelHopExpRvrsLabelPtr OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "If the gmplsTunnelHopLabelStatuses object indicates that a reverse label is present, this object contains a pointer to a row in another MIB table (such as the gmplsLabelTable) that contains the label to use on this hop in the reverse direction. Nadeau and Farrel (Editors) [Page 23] =0C Internet Draft draft-ietf-ccamp-gmpls-te-mib-06.txt October 2004 If the gmplsTunnelHopLabelStatuses object indicates that a reverse label is present and this object contains the value zeroDotZero, then the label to use on this hop is found in the gmplsTunnelHopExpRvrsLabel object." DEFVAL { zeroDotZero } ::=3D { gmplsTunnelHopEntry 5 } -- End of gmplsTunnelHopTable -- Tunnel Actual Route Hop table. gmplsTunnelARHopTable OBJECT-TYPE SYNTAX SEQUENCE OF GmplsTunnelARHopEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The gmplsTunnelARHopTable 'extends' the mplsTunnelARHopTable. It is used to indicate the labels currently in use for a GMPLS tunnel defined in mplsTunnelTable and gmplsTunnelTable, as reported by the signaling protocol. It does not insert new hops, but does define new values for hops defined in mplsTunnelARHopTable. Each row in this table is indexed by the same indexes as mplsTunnelARHopTable. It is acceptable for some rows in mplsTunnelARHopTable to have corresponding entries in this table and some to have no corresponding entry in this table. Note that since the information necessary to build entries within this table is not provided by some signaling protocols and might not be returned in all cases of other signaling protocols, implementation of this table and mplsTunnelARHopTable is optional. Furthermore, since the information in this table is actually provided by the signaling protocol after the path has been set-up, the entries in this table are provided only for observation, and hence, all variables in this table are accessible exclusively as read-only." REFERENCE "1. Extensions to RSVP for LSP Tunnels, Awduche et al, RFC 3209, December 2001 2. Generalized MPLS Signaling - RSVP-TE Extensions, Berger, L. (Editor), RFC 3473, January 2003." ::=3D { gmplsTeObjects 3 } gmplsTunnelARHopEntry OBJECT-TYPE SYNTAX GmplsTunnelARHopEntry MAX-ACCESS not-accessible STATUS current Nadeau and Farrel (Editors) [Page 24] =0C Internet Draft draft-ietf-ccamp-gmpls-te-mib-06.txt October 2004 DESCRIPTION "An entry in this table represents additions to a tunnel hop visible in mplsTunnelARHopEntry. An entry is created by the signaling protocol for a signaled ERLSP set up by the signaling protocol. At any node on the LSP (ingress, transit or egress) Thus at this table and mplsTunnelARHopTable (if the tables are supported and if the signaling protocol is recording actual route information) contains the actual route of the whole tunnel. If the signaling protocol is not recording the actual route, this table MAY report the information from the gmplsTunnelHopTable or the gmplsTunnelCHopTable. Note that the recording of actual labels is distinct from the recording of the actual route in some signaling protocols. This feature is enabled using the gmplsTunnelAttributes object." INDEX { mplsTunnelARHopListIndex, mplsTunnelARHopIndex } ::=3D { gmplsTunnelARHopTable 1 } GmplsTunnelARHopEntry ::=3D SEQUENCE { gmplsTunnelARHopLabelStatuses BITS, gmplsTunnelARHopExpLabel Unsigned32, gmplsTunnelARHopExpLabelPtr RowPointer, gmplsTunnelARHopExpRvrsLabel Unsigned32, gmplsTunnelARHopExpRvrsLabelPtr RowPointer, gmplsTunnelARHopProtection BITS } gmplsTunnelARHopLabelStatuses OBJECT-TYPE SYNTAX BITS { forwardPresent (0), reversePresent (1), forwardGlobal (2), reverseGlobal (3) } MAX-ACCESS read-only STATUS current DESCRIPTION "This bitmask indicates the presence and status of labels indicated by the gmplsTunnelARHopExpLabel or gmplsTunnelARHopExpLabelPtr and gmplsTunnelARHopExpRvrsLabel or gmplsTunnelARHopExpRvrsLabelPtr objects. Nadeau and Farrel (Editors) [Page 25] =0C Internet Draft draft-ietf-ccamp-gmpls-te-mib-06.txt October 2004 For the Present bits, a set bit indicates that a label is present for this hop in the route. For the Global bits, a set bit indicates that the label comes from the Global Label Space. A clear bit indicates that this is a Per-Interface label. A Global bit only has meaning if the corresponding Present bit is set." ::=3D { gmplsTunnelARHopEntry 1 } gmplsTunnelARHopExpLabel OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "If the gmplsTunnelARHopLabelStatuses object indicates that a forward label is present and gmplsTunnelARHopExpLabelPtr contains the value zeroDotZero, then the label in use on this hop is found in this object encoded within a 32-bit integer." ::=3D { gmplsTunnelARHopEntry 2 } gmplsTunnelARHopExpLabelPtr OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-only STATUS current DESCRIPTION "If the gmplsTunnelARHopLabelStatuses object indicates that a forward label is present, this object contains a pointer to a row in another MIB table (such as the gmplsLabelTable) that contains the label in use on this hop in the forward direction. If the gmplsTunnelARHopLabelStatuses object indicates that a forward label is present and this object contains the value zeroDotZero, then the label in use on this hop is found in the gmplsTunnelARHopExpLabel object." ::=3D { gmplsTunnelARHopEntry 3 } gmplsTunnelARHopExpRvrsLabel OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "If the gmplsTunnelARHopLabelStatuses object indicates that a reverse label is present and gmplsTunnelARHopExpRvrsLabelPtr contains the value zeroDotZero, then the label in use on this hop is found in this object encoded as a 32-bit integer." ::=3D { gmplsTunnelARHopEntry 4 } Nadeau and Farrel (Editors) [Page 26] =0C Internet Draft draft-ietf-ccamp-gmpls-te-mib-06.txt October 2004 gmplsTunnelARHopExpRvrsLabelPtr OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-only STATUS current DESCRIPTION "If the gmplsTunnelARHopLabelStatuses object indicates that a reverse label is present, this object contains a pointer to a row in another MIB table (such as the gmplsLabelTable) that contains the label in use on this hop in the reverse direction. If the gmplsTunnelARHopLabelStatuses object indicates that a reverse label is present and this object contains the value zeroDotZero, then the label in use on this hop is found in the gmplsTunnelARHopExpRvrsLabel object." ::=3D { gmplsTunnelARHopEntry 5 } gmplsTunnelARHopProtection OBJECT-TYPE SYNTAX BITS { localAvailable (0), localInUse (1) } MAX-ACCESS read-only STATUS current DESCRIPTION "Availability and usage of protection on the reported link. localAvailable Indicates that the link downstream of this node is protected via a local repair mechanism. localInUse Indicates that a local repair mechanism is in use to maintain this tunnel (usually in the face of an outage of the link it was previously routed over)." ::=3D { gmplsTunnelARHopEntry 6 } -- End of mplsTunnelARHopTable -- Tunnel Computed Hop table. gmplsTunnelCHopTable OBJECT-TYPE SYNTAX SEQUENCE OF GmplsTunnelCHopEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The gmplsTunnelCHopTable 'extends' the mplsTunnelCHopTable. It is used to indicate additional information about the hops of a GMPLS tunnel defined in mplsTunnelTable and gmplsTunnelTable, as computed by a constraint-based routing protocol, based on the mplsTunnelHopTable and the gmplsTunnelHopTable. Nadeau and Farrel (Editors) [Page 27] =0C Internet Draft draft-ietf-ccamp-gmpls-te-mib-06.txt October 2004 Each row in this table is indexed by the same indexes as mplsTunnelCHopTable. It is acceptable for some rows in mplsTunnelCHopTable to have corresponding entries in this table and some to have no corresponding entry in this table. Please note that since the information necessary to build entries within this table may not be supported by some LSRs, implementation of this table is optional. Furthermore, since the information in this table is actually provided by a path computation component after the path has been computed, the entries in this table are provided only for observation, and hence, all objects in this table are accessible exclusively as read-only." REFERENCE "Generalized MPLS Signaling - RSVP-TE Extensions, Berger, L. (Editor), RFC 3473, January 2003." ::=3D { gmplsTeObjects 4 } gmplsTunnelCHopEntry OBJECT-TYPE SYNTAX GmplsTunnelCHopEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table represents additions to a computed tunnel hop visible in mplsTunnelCHopEntry. An entry is created by a path computation component based on the hops specified in the corresponding mplsTunnelHopTable and gmplsTunnelHopTable. At a transit LSR this table (if the table is supported) MAY contain the path computed by path computation engine on (or on behalf of) the transit LSR." INDEX { mplsTunnelCHopListIndex, mplsTunnelCHopIndex } ::=3D { gmplsTunnelCHopTable 1 } GmplsTunnelCHopEntry ::=3D SEQUENCE { gmplsTunnelCHopLabelStatuses BITS, gmplsTunnelCHopExpLabel Unsigned32, gmplsTunnelCHopExpLabelPtr RowPointer, gmplsTunnelCHopExpRvrsLabel Unsigned32, gmplsTunnelCHopExpRvrsLabelPtr RowPointer } Nadeau and Farrel (Editors) [Page 28] =0C Internet Draft draft-ietf-ccamp-gmpls-te-mib-06.txt October 2004 gmplsTunnelCHopLabelStatuses OBJECT-TYPE SYNTAX BITS { forwardPresent (0), reversePresent (1) } MAX-ACCESS read-only STATUS current DESCRIPTION "This bitmask indicates the presence of labels indicated by the gmplsTunnelCHopExpLabel or gmplsTunnelCHopExpLabelPtr and gmplsTunnelCHopExpRvrsLabel or gmplsTunnelCHopExpRvrsLabelPtr objects. A set bit indicates that a label is present for this hop in the route thus allowing zero to be a valid label value." ::=3D { gmplsTunnelCHopEntry 1 } gmplsTunnelCHopExpLabel OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "If the gmplsTunnelCHopLabelStatuses object indicates that a forward label is present and gmplsTunnelCHopExpLabelPtr contains the value zeroDotZero, then the label to use on this hop is found in this object encoded within a 32-bit integer." ::=3D { gmplsTunnelCHopEntry 2 } gmplsTunnelCHopExpLabelPtr OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-only STATUS current DESCRIPTION "If the gmplsTunnelCHopLabelStatuses object indicates that a forward label is present, this object contains a pointer to a row in another MIB table (such as the gmplsLabelTable) that contains the label to use on this hop in the forward direction. If the gmplsTunnelCHopLabelStatuses object indicates that a forward label is present and this object contains the value zeroDotZero, then the label to use on this hop is found in the gmplsTunnelCHopExpLabel object." ::=3D { gmplsTunnelCHopEntry 3 } gmplsTunnelCHopExpRvrsLabel OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "If the gmplsTunnelCHopLabelStatuses object indicates that a reverse label is present and Nadeau and Farrel (Editors) [Page 29] =0C Internet Draft draft-ietf-ccamp-gmpls-te-mib-06.txt October 2004 gmplsTunnelCHopExpRvrsLabelPtr contains the value zeroDotZero, then the label to use on this hop is found in this object encoded as a 32-bit integer." ::=3D { gmplsTunnelCHopEntry 4 } gmplsTunnelCHopExpRvrsLabelPtr OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-only STATUS current DESCRIPTION "If the gmplsTunnelCHopLabelStatuses object indicates that a reverse label is present, this object contains a pointer to a row in another MIB table (such as the gmplsLabelTable) that contains the label to use on this hop in the reverse direction. If the gmplsTunnelCHopLabelStatuses object indicates that a reverse label is present and this object contains the value zeroDotZero, then the label to use on this hop is found in the gmplsTunnelCHopExpRvrsLabel object." ::=3D { gmplsTunnelCHopEntry 5 } -- End of gmplsTunnelCHopTable -- GMPLS Tunnel Reverse Direction Performance Table. gmplsTunnelReversePerfTable OBJECT-TYPE SYNTAX SEQUENCE OF GmplsTunnelReversePerfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table 'augments' the gmplsTunnelTable to provides per-tunnel packet performance information for the reverse direction of a bidirectional tunnel. It can be seen as supplementing the mplsTunnelPerfTable which augments the mplsTunnelTable." REFERENCE "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB), Srinivasan, C., Viswanathan, A., Nadeau, T., RFC 3812, June 2004." ::=3D { gmplsTeObjects 5 } gmplsTunnelReversePerfEntry OBJECT-TYPE SYNTAX GmplsTunnelReversePerfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table is created by the LSR for every bidirectional GMPLS tunnel where packets are visible to the LSR." AUGMENTS { gmplsTunnelEntry } ::=3D { gmplsTunnelReversePerfTable 1 } Nadeau and Farrel (Editors) [Page 30] =0C Internet Draft draft-ietf-ccamp-gmpls-te-mib-06.txt October 2004 GmplsTunnelReversePerfEntry ::=3D SEQUENCE { gmplsTunnelReversePerfPackets Counter32, gmplsTunnelReversePerfHCPackets Counter64, gmplsTunnelReversePerfErrors Counter32, gmplsTunnelReversePerfBytes Counter32, gmplsTunnelReversePerfHCBytes Counter64 } gmplsTunnelReversePerfPackets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of packets forwarded on the tunnel in the reverse direction if it is bidirectional." ::=3D { gmplsTunnelReversePerfEntry 1 } gmplsTunnelReversePerfHCPackets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "High capacity counter for number of packets forwarded on the tunnel in the reverse direction if it is bidirectional." ::=3D { gmplsTunnelReversePerfEntry 2 } gmplsTunnelReversePerfErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of errored packets received on the tunnel in the reverse direction if it is bidirectional." ::=3D { gmplsTunnelReversePerfEntry 3 } gmplsTunnelReversePerfBytes OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of bytes forwarded on the tunnel in the reverse direction if it is bidirectional." ::=3D { gmplsTunnelReversePerfEntry 4 } gmplsTunnelReversePerfHCBytes OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current Nadeau and Farrel (Editors) [Page 31] =0C Internet Draft draft-ietf-ccamp-gmpls-te-mib-06.txt October 2004 DESCRIPTION "High capacity counter for number of bytes forwarded on the tunnel in the reverse direction if it is bidirectional." ::=3D { gmplsTunnelReversePerfEntry 5 } -- End of gmplsTunnelReversePerfTable -- GMPLS Tunnel Error Table. gmplsTunnelErrorTable OBJECT-TYPE SYNTAX SEQUENCE OF GmplsTunnelErrorEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table 'augments' the mplsTunnelTable This table provides per-tunnel information about errors. Errors may be detected locally or reported through the signaling protocol. Error reporting is not exclusive to GMPLS and this table may be applied in MPLS systems." REFERENCE "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB), Srinivasan, C., Viswanathan, A., Nadeau, T., RFC 3812, June 2004." ::=3D { gmplsTeObjects 6 } gmplsTunnelErrorEntry OBJECT-TYPE SYNTAX GmplsTunnelErrorEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table is created by the LSR for every tunnel where error information is visible to the LSR. Note that systems which read the objects in this table one at a time may experience a discontinuity as the result of a new error occurring in between object reads. Systems that are vulnerable to this should read gmplsTunnelErrorLastTime before and after reading the other objects." AUGMENTS { mplsTunnelEntry } ::=3D { gmplsTunnelErrorTable 1 } GmplsTunnelErrorEntry ::=3D SEQUENCE { gmplsTunnelErrorLastErrorType INTEGER, gmplsTunnelErrorLastTime TimeStamp, gmplsTunnelErrorReporterType INTEGER, gmplsTunnelErrorReporter InetAddress, gmplsTunnelErrorCode Unsigned32, gmplsTunnelErrorSubcode Unsigned32, Nadeau and Farrel (Editors) [Page 32] =0C Internet Draft draft-ietf-ccamp-gmpls-te-mib-06.txt October 2004 gmplsTunnelErrorTLVs OCTET STRING, gmplsTunnelErrorHelpString DisplayString } gmplsTunnelErrorLastErrorType OBJECT-TYPE SYNTAX INTEGER { noError (0), unknown (1), localProtocol (2), remoteProtocol (3), configuration (4), pathComputation (5), localResources (6) } MAX-ACCESS read-only STATUS current DESCRIPTION "The nature of the last error. Provides interpretation context for gmplsTunnelErrorProtocolCode and gmplsTunnelErrorProtocolSubcode. A value of noError (0) shows that there is no error associated with this tunnel and means that the other objects in this entry have no meaning." ::=3D { gmplsTunnelErrorEntry 1 } gmplsTunnelErrorLastTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The time at which the last error occurred. This is presented as the value of SysUpTime when the error occurred or was reported to this node. If gmplsTunnelErrorLastErrorType has the value noError (0), then this object is ignored." ::=3D { gmplsTunnelErrorEntry 2 } gmplsTunnelErrorReporterType OBJECT-TYPE SYNTAX INTEGER { unknown (0), localNode (1), localIpV4 (2), remoteIpV4 (3), localIpV6 (4), remoteIpV6 (5) } MAX-ACCESS read-only STATUS current Nadeau and Farrel (Editors) [Page 33] =0C Internet Draft draft-ietf-ccamp-gmpls-te-mib-06.txt October 2004 DESCRIPTION "The reporter of the last error recorded. This object is used principally to aid in interpretation of gmplsTunnelErrorReporterIpv4Addr and gmplsTunnelErrorReporterIpv6Addr. Where the error has been locally generated and there is no requirement to associate the error with any specific local address (such as an interface), the value localNode (2) may be used. If gmplsTunnelErrorLastError has the value noError (0), then this object is ignored." ::=3D { gmplsTunnelErrorEntry 3 } gmplsTunnelErrorReporter OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The address of the node reporting the last error, or the address of the resource (such as an interface) associated with the error. If gmplsTunnelErrorLastErrorType has the value noError (0), then this object is ignored. This object should be interpreted in the context of the value of the object gmplsTunnelErrorReporterType. If that object has value localIpV4 (2) or remoteIpV4 (3), this object should be viewed as having a syntax of InetAddressIPv4. If gmplsTunnelErrorReporterType has value localIpV6 (3) or remoteIpV6 (5), this object should be viewed as having a syntax of InetAddressIPv6. Otherwise the object should contain the value zero and should be ignored." REFERENCE "RFC3291, Textual Conventions for Internet Network Addresses, Section 4. Usage Hints." ::=3D { gmplsTunnelErrorEntry 4 } gmplsTunnelErrorCode OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The primary error code associated with the last error. The interpretation of this error code depends on the value of gmplsTunnelErrorLastErrorType. If the value of gmplsTunnelErrorLastErrorType is noError (0) the value of this object should be 0 and should be ignored. If the value of gmplsTunnelErrorLastErrorType is localProtocol (2) or remoteProtocol (3) the error should be interpreted in the context of the signling protocol identified by the mplsTunnelSignallingProto object. Nadeau and Farrel (Editors) [Page 34] =0C Internet Draft draft-ietf-ccamp-gmpls-te-mib-06.txt October 2004 Values in excess 32767 of are not used by signaling protocols and may safely be used as implementation-specific error codes. " REFERENCE "1. Braden, R. (Ed.) et al., Resource ReserVation Protocol -- Version 1 Functional Specification, RFC 2205, September 1997. 2. RSVP-TE: Extensions to RSVP for LSP Tunnels, Awduche et al, RFC 3209, December 2001. 3. Generalized MPLS Signaling - RSVP-TE Extensions, Berger, L. (Editor), RFC 3473, January 2003." ::=3D { gmplsTunnelErrorEntry 5 } gmplsTunnelErrorSubcode OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The secondary error code associated with the last error and the protocol used to signal this tunnel. This value is interpreted in the context of the value of gmplsTunnelErrorCode. If the value of gmplsTunnelErrorLastErrorType is noError (0) the value of this object should be 0 and should be ignored." REFERENCE "1. Braden, R. (Ed.) et al., Resource ReserVation Protocol -- Version 1 Functional Specification, RFC 2205, September 1997. 2. RSVP-TE: Extensions to RSVP for LSP Tunnels, Awduche et al, RFC 3209, December 2001. 3. Generalized MPLS Signaling - RSVP-TE Extensions, Berger, L. (Editor), RFC 3473, January 2003." ::=3D { gmplsTunnelErrorEntry 6 } gmplsTunnelErrorTLVs OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The sequence of interface identifier TLVs reported with the error by the protocol code. The interpretation of the TLVs and the encoding within the protocol are described in the references. A value of zero in the first octet indicates that no TLVs are present." REFERENCE "Generalized MPLS Signaling - RSVP-TE Extensions, Berger, L. (Editor), RFC 3473, January 2003." ::=3D { gmplsTunnelErrorEntry 7 } Nadeau and Farrel (Editors) [Page 35] =0C Internet Draft draft-ietf-ccamp-gmpls-te-mib-06.txt October 2004 gmplsTunnelErrorHelpString OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION "A textual string containing information about the last error, recovery actions and support advice. If there is no help string this object contains a zero length string. If the value of gmplsTunnelErrorLastErrorType is noError (0) this object should contain a zero length string, but may contain a help string indicating that there is no error." ::=3D { gmplsTunnelErrorEntry 8 } -- GMPLS Notifications. gmplsTunnelDown NOTIFICATION-TYPE OBJECTS { mplsTunnelAdminStatus, mplsTunnelOperStatus, gmplsTunnelErrorLastErrorType, gmplsTunnelErrorReporterType, gmplsTunnelErrorReporter, gmplsTunnelErrorCode, gmplsTunnelErrorSubcode } STATUS current DESCRIPTION "This notification is generated when a mplsTunnelOperStatus object for one of the configured tunnels is about to enter the down state from some other state (but not from the notPresent state). This other state is indicated by the included value of mplsTunnelOperStatus. The objects in this notification provide additional error information that indicates the reason why the tunnel has transitioned down. Note that an implementation SHOULD only issue one of mplsTunnelDown and gmplsTunnelDown for a single event on a single tunnel." ::=3D { gmplsTeNotifications 1 } -- End of notifications. Nadeau and Farrel (Editors) [Page 36] =0C Internet Draft draft-ietf-ccamp-gmpls-te-mib-06.txt October 2004 -- Module compliance. gmplsTeGroups OBJECT IDENTIFIER ::=3D { gmplsTeConformance 1 } gmplsTeCompliances OBJECT IDENTIFIER ::=3D { gmplsTeConformance 2 } gmplsTeModuleCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance statement for agents that support the GMPLS TE MIB." MODULE -- this module -- The mandatory group has to be implemented by all -- LSRs that originate/terminate ESLSPs/tunnels. -- In addition, depending on the type of tunnels -- supported, other groups become mandatory as -- explained below. MANDATORY-GROUPS { gmplsTunnelGroup, gmplsTunnelScalarGroup } -- GROUP gmplsTunnelManualGroup -- DESCRIPTION -- "This group is mandatory for devices which support -- manual configuration of tunnels, in addition to -- gmplsTunnelGroup. The following constraints apply: -- mplsTunnelSignallingProto should be at least -- read-only with a value of none(1)." GROUP gmplsTunnelSignaledGroup DESCRIPTION "This group is mandatory for devices which support signaled tunnel set up, in addition to gmplsTunnelGroup. The following constraints apply: mplsTunnelSignallingProto should be at least read-only returning a value of ldp(2), or rsvp(3)." GROUP gmplsTunnelIsNotIntfcGroup DESCRIPTION "This group is mandatory for devices which support tunnels that are not interfaces, in addition to gmplsTunnelGroup. The following constraints apply: gmplsTunnelIsIf must at least be read-only returning no(0)." Nadeau and Farrel (Editors) [Page 37] =0C Internet Draft draft-ietf-ccamp-gmpls-te-mib-06.txt October 2004 GROUP gmplsTunnelIsIntfcGroup DESCRIPTION "This group is mandatory for devices which support tunnels that are interfaces, in addition to gmplsTunnelGroup." GROUP gmplsTunnelOptionalGroup DESCRIPTION "Objects in this group are optional." GROUP gmplsTeNotificationGroup DESCRIPTION "This group is mandatory for those implementations which can implement the notifications contained in this group." -- GMPLS Tunnel scalars. -- All scalars have max access read-only -- gmplsTunnelTable OBJECT gmplsTunnelAttributes MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsTunnelLSPEncoding SYNTAX Integer32 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsTunnelSwitchingType SYNTAX Integer32 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsTunnelLinkProtection MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsTunnelGPid MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsTunnelSecondary SYNTAX TruthValue MIN-ACCESS read-only DESCRIPTION "Write access is not required." Nadeau and Farrel (Editors) [Page 38] =0C Internet Draft draft-ietf-ccamp-gmpls-te-mib-06.txt October 2004 OBJECT gmplsTunnelDirection SYNTAX INTEGER { forward (0), bidirectional (1) } MIN-ACCESS read-only DESCRIPTION "Only forward (0) is required." OBJECT gmplsTunnelPathComp SYNTAX INTEGER { dynamicFull(1), -- CSPF fully computed explicit(2), -- fully dynamicPartial(3) -- CSPF partially computed } MIN-ACCESS read-only DESCRIPTION "Only explicit (2) is required." OBJECT gmplsTunnelUpNotRecip SYNTAX IpAddress MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsTunnelDownNotRecip SYNTAX IpAddress MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsTunnelAdminStatusFlags SYNTAX BITS { delInProgress (0), adminDown (1), testing (2), reflect (31) } MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsTunnelExtraParamsPtr SYNTAX RowPointer MIN-ACCESS read-only DESCRIPTION "Write access is not required." -- gmplsTunnelHopTable Nadeau and Farrel (Editors) [Page 39] =0C Internet Draft draft-ietf-ccamp-gmpls-te-mib-06.txt October 2004 -- gmplsTunnelHopLabelStatuses has max access read-only OBJECT gmplsTunnelHopExpLabel MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsTunnelHopExpLabelPtr MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsTunnelHopExpRvrsLabel MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT gmplsTunnelHopExpRvrsLabelPtr MIN-ACCESS read-only DESCRIPTION "Write access is not required." -- gmplsTunnelARHopTable -- all objects have max access read-only -- glmpsTunnelCHopTable -- all objects have max access read-only -- gmplsTunnelReversePerfTable -- all objects have max access read-only -- gmplsTunnelErrorTable -- all objects have max access read-only ::=3D { gmplsTeCompliances 1 } -- Units of conformance. gmplsTunnelGroup OBJECT-GROUP OBJECTS { gmplsTunnelDirection, gmplsTunnelReversePerfPackets, gmplsTunnelReversePerfHCPackets, gmplsTunnelReversePerfErrors, gmplsTunnelReversePerfBytes, gmplsTunnelReversePerfHCBytes, gmplsTunnelErrorLastErrorType, gmplsTunnelErrorLastTime, gmplsTunnelErrorReporterType, gmplsTunnelErrorReporter, gmplsTunnelErrorCode, gmplsTunnelErrorSubcode, Nadeau and Farrel (Editors) [Page 40] =0C Internet Draft draft-ietf-ccamp-gmpls-te-mib-06.txt October 2004 gmplsTunnelErrorTLVs, gmplsTunnelErrorHelpString } STATUS current DESCRIPTION "Necessary, but not sufficient, set of objects to implement tunnels. In addition, depending on the type of the tunnels supported (for example, manually configured or signaled, persistent or non-persistent, etc.), the following other groups defined below are mandatory: gmplsTunnelManualGroup and/or gmplsTunnelSignaledGroup, gmplsTunnelIsNotIntfcGroup and/or gmplsTunnelIsIntfcGroup." ::=3D { gmplsTeGroups 1 } -- gmplsTunnelManualGroup OBJECT-GROUP -- OBJECTS { -- mplsTunnelSignallingProto -- } -- STATUS current -- DESCRIPTION -- "Object(s) needed to implement manually configured -- tunnels." -- ::=3D { gmplsTeGroups 2 } gmplsTunnelSignaledGroup OBJECT-GROUP OBJECTS { gmplsTunnelAttributes, gmplsTunnelLSPEncoding, gmplsTunnelSwitchingType, gmplsTunnelLinkProtection, gmplsTunnelGPid, gmplsTunnelSecondary, gmplsTunnelPathComp, gmplsTunnelUpNotRecip, gmplsTunnelDownNotRecip, gmplsTunnelAdminStatusFlags, gmplsTunnelHopLabelStatuses, gmplsTunnelHopExpLabel, gmplsTunnelHopExpLabelPtr, gmplsTunnelHopExpRvrsLabel, gmplsTunnelHopExpRvrsLabelPtr } STATUS current DESCRIPTION "Objects needed to implement signaled tunnels." ::=3D { gmplsTeGroups 3 } Nadeau and Farrel (Editors) [Page 41] =0C Internet Draft draft-ietf-ccamp-gmpls-te-mib-06.txt October 2004 gmplsTunnelScalarGroup OBJECT-GROUP OBJECTS { gmplsTunnelsConfigured, gmplsTunnelsActive } STATUS current DESCRIPTION "Scalar objects needed to implement MPLS tunnels." ::=3D { gmplsTeGroups 4 } gmplsTunnelIsIntfcGroup OBJECT-GROUP OBJECTS { gmplsTunnelUnnumIf } STATUS current DESCRIPTION "Objects needed to implement tunnels that are interfaces." ::=3D { gmplsTeGroups 5 } gmplsTunnelIsNotIntfcGroup OBJECT-GROUP OBJECTS { gmplsTunnelUnnumIf } STATUS current DESCRIPTION "Objects needed to implement tunnels that are not interfaces." ::=3D { gmplsTeGroups 6 } gmplsTunnelOptionalGroup OBJECT-GROUP OBJECTS { gmplsTunnelExtraParamsPtr, gmplsTunnelARHopLabelStatuses, gmplsTunnelARHopExpLabel, gmplsTunnelARHopExpLabelPtr, gmplsTunnelARHopExpRvrsLabel, gmplsTunnelARHopExpRvrsLabelPtr, gmplsTunnelARHopProtection, gmplsTunnelCHopLabelStatuses, gmplsTunnelCHopExpLabel, gmplsTunnelCHopExpLabelPtr, gmplsTunnelCHopExpRvrsLabel, gmplsTunnelCHopExpRvrsLabelPtr } STATUS current DESCRIPTION "The objects in this group are optional." ::=3D { gmplsTeGroups 7 } Nadeau and Farrel (Editors) [Page 42] =0C Internet Draft draft-ietf-ccamp-gmpls-te-mib-06.txt October 2004 gmplsTeNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { gmplsTunnelDown } STATUS current DESCRIPTION "Set of notifications implemented in this module. None is mandatory." ::=3D { gmplsTeGroups 8 } END 9. Security Considerations It is clear that the MIB modules described in this document in association with the MPLS-TE-STD-MIB are potentially useful for monitoring of MPLS and GMPLS tunnels. These MIB modules can also be used for configuration of certain objects, and anything that can be configured can be incorrectly configured, with potentially disastrous results. There are a number of management objects defined in these MIB modules with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: o the gmplsTunnelTable and gmplsTunnelHopTable collectively contain objects to provision GMPLS tunnels interfaces at their ingress LSRs. Unauthorized write access to objects in these tables, could result in disruption of traffic on the network. This is especially true if a tunnel has already been established. The use of stronger mechanisms such as SNMPv3 security should be considered where possible. Specifically, SNMPv3 VACM and USM MUST be used with any SNMPv3 agent which implements these MIB modules. Some of the readable objects in these MIB modules "i.e., objects with a MAX-ACCESS other than not-accessible" may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: o the gmplsTunnelTable, gmplsTunnelHopTable, gmplsTunnelARHopTable, gmplsTunnelCHopTable, gmplsTunnelReversePerfTable, gmplsTunnelErrorTable collectively show the tunnel network topology and status. If an Administrator does not want to reveal Nadeau and Farrel (Editors) [Page 43] =0C Internet Draft draft-ietf-ccamp-gmpls-te-mib-06.txt October 2004 this information, then these tables should be considered sensitive/vulnerable. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure "for example by using IPSec", even then, there is no control as to who on the secure network is allowed to access and GET/SET "read/change/create/delete" the objects in these MIB modules. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework "see [RFC3410], section 8", including full support for the SNMPv3 cryptographic mechanisms "for authentication and privacy". Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module, is properly configured to give access to the objects only to those principals "users" that have legitimate rights to indeed GET or SET "change/create/delete" them. 10. Acknowledgments This draft is the work of the five authors listed in the Authors' Addresses section. This document extends [RFC3812]. The authors would like to express their gratitude to all those who worked on that earlier MIB document. Thanks also to Tony Zinicola and Jeremy Crossen for their valuable contributions during an early implementation, and to Baktha Muralidharan for his review. Special thanks to Joan Cucchiara and Len Nieman for their help with compilation issues. 11. IANA Considerations As requested in the GMPLS-TC-STD-MIB [GMPLSTCMIB], GMPLS related standards track MIB modules should be rooted under the mplsStdMIB subtree. There is one GMPLS MIB Module contained in this document, and the following "IANA Considerations" subsection requests IANA for a new assignment under the mplsStdMIB subtree. New assignments can only be made via a Standards Action as specified in [RFC2434]. 11.1. IANA Considerations for GMPLS-TE-STD-MIB IANA is requested to assign an OID to the GMPLS-TE-STD-MIB module specified in this document as { mplsStdMIB xx }. Nadeau and Farrel (Editors) [Page 44] =0C Internet Draft draft-ietf-ccamp-gmpls-te-mib-06.txt October 2004 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3212] Jamoussi, B., Aboul-Magd, O., Andersson, L., Ashwood-Smith, P., Hellstrand, F., Sundell, K., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Halpern, J., Heinanen, J., Kilty, T., Malis, A., and P. Vaananen, "Constraint-Based LSP Setup using LDP", RFC 3212, December 2001. [RFC3291] Daniele, M., Haberman, B., Routhier, S., Schoenwaelder, J., and Braunschweig, TU, "Textual Conventions for Internet Network Addresses", RFC3291, May 2002 [RFC3471] Berger, L. (Editor), "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC3472] Ashwood-Smith, P., Berger, L. (Editors), "Generalized MPLS Signaling - CR-LDP Extensions", RFC 3472, January 2003. Nadeau and Farrel (Editors) [Page 45] =0C Internet Draft draft-ietf-ccamp-gmpls-te-mib-06.txt October 2004 [RFC3473] Berger, L. (Editor), "Generalized MPLS Signaling - RSVP-TE Extensions", RFC 3473, January 2003. [RFC3477] Kompella, K. and Rekhter, Y., "Signalling Unnumbered Links in RSVP-TE", RFC 3477, January 2003. [RFC3480] Kompella, K., Rekhter, Y. and Kullberg, A., "Signalling Unnumbered Links in CR-LDP", RFC 3480, February 2003. [RFC3811] Nadeau, T. and J. Cucchiara, "Definition of Textual Conventions and for Multiprotocol Label Switching (MPLS) Management", RFC 3811, June 2004. [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004. [RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Label Switching (LSR) Router Management Information Base (MIB)", RFC 3813, June 2004. [GMPLSArch] Mannie, E. (Editor), "Generalized Multiprotocol Label Switching (GMPLS) Architecture", draft-many-gmpls-architecture-07.txt, May 2003, work in progress. [GMPLSLSRMIB] Nadeau, T., Farrel, A., (Editors) "Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base", draft-ietf-ccamp-gmpls-lsr-mib-06.txt, October 2004, work in progress. [GMPLSOSPF] Kompella, K., et al., "OSPF Extensions in Support of Generalized MPLS", draft-ietf-ccamp-ospf-gmpls-extensions-12.txt, October 2003, work in progress. [GMPLSTCMIB] Nadeau, T., Farrel, A., (Editors) "Definitions of Textual Conventions for Multiprotocol Label Switching (MPLS) Management", draft-ietf-ccamp-gmpls-te-mib-06.txt, October 2004, work in progress. 12.2. Informational References [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", RFC 2026, October 1996. Nadeau and Farrel (Editors) [Page 46] =0C Internet Draft draft-ietf-ccamp-gmpls-te-mib-06.txt October 2004 [RFC2434] Narten, T. and H. Alvestrand., "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC3413] Levi, D., Meyer, P., Stewart, B., "SNMP Applications", RFC 3413, December 2002. [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", RFC 3411, December 2002. [GMPLS-G709] D. Papadimitriou (Editor), "Generalized MPLS Signalling Extensions for G.709 Optical Transport Networks Control", draft-ietf-ccamp-gmpls-g709- 07.txt, September 2004, work in progress. 13. Authors' Addresses Thomas D. Nadeau Cisco Systems, Inc. 300 Apollo Drive Chelmsford, MA 01824 Phone: +1-978-244-3051 Email: tnadeau@cisco.com Cheenu Srinivasan Bloomberg L.P. 499 Park Ave., New York, NY 10022 Phone: +1-212-893-3682 Email: cheenu@bloomberg.net Adrian Farrel Old Dog Consulting Phone: +44-(0)-1978-860944 Email: adrian@olddog.co.uk Tim Hall Data Connection Ltd. 100 Church Street Enfield, Middlesex EN2 6BQ, UK Phone: +44 20 8366 1177 Email: tim.hall@dataconnection.com Nadeau and Farrel (Editors) [Page 47] =0C Internet Draft draft-ietf-ccamp-gmpls-te-mib-06.txt October 2004 Ed Harrison Data Connection Ltd. 100 Church Street Enfield, Middlesex EN2 6BQ, UK Phone: +44 20 8366 1177 Email: ed.harrison@dataconnection.com 14. Intellectual Property Considerations The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 15. Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Nadeau and Farrel (Editors) [Page 48] =0C Internet Draft draft-ietf-ccamp-gmpls-te-mib-06.txt October 2004 16. Changes This section to be removed before the draft progresses to RFC. 16.1. Changes from version 5 to version 6 - ID nits and MIB boilerplate 16.2. Changes from version 4 to version 5 - New IPR and copyright boiler plate. - Correct typo in name of gmplsTunnelExtraParamsPtr - Add to list of encoding types and GPids for G.709 - Add G.709 reference 16.3. Changes from version 3 to version 4 - Provide a way to configure additional tunnel parameters such as tunnel resources through an arbitrary row pointer. - Update references. - Change reporting IP addresses to use InetAddress syntax - Add support for IF_ID error reporting. - Add a new notification, gmplsTunnelDown, containing cause information. - Clarify relationship to the gmplsLabelTable. - Update descriptive text. - Bring usage of labels in line with latest [RFC3813]. 16.4. Changes from version 2 to version 3 - Work on basic compilation issues. - Resolve defaults for objects with syntax BITS. - Update references. - Clarify which objects can be modified when rowStatus and adminStatus are set to active. - Control and reporting of upstream and downstream Notify Recipients. - Add support for control and reporting of GMPLS Administrative Status object. - Update examples. Nadeau and Farrel (Editors) [Page 49] =0C ------=_NextPart_000_0E00_01C4BDF2.F8398130-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Oct 2004 18:54:49 +0000 Date: Thu, 28 Oct 2004 15:53:04 -0300 To: "Ccamp" <ccamp@ops.ietf.org> From: "Kireeti" <kireeti@juniper.net> Subject: Re: Message-ID: <hvbdziyqicxgqmeocvy@ops.ietf.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------jxcmzzcdpynymiatkxqa" ----------jxcmzzcdpynymiatkxqa Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit <html><body> >Predators<br><br> <br> :)<img src="cid:qmsinzbumx.gif"><br> <br> </body></html> ----------jxcmzzcdpynymiatkxqa Content-Type: image/gif; name="qmsinzbumx.gif" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="qmsinzbumx.gif" Content-ID: <qmsinzbumx.gif> R0lGODlhPwAQAPcAAAAAAIAAAACAAICAAAAAgIAAgACAgICAgMDAwP8AAAD/AP//AAAA//8A /wD//////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMwAAZgAAmQAAzAAA/wAzAAAzMwAzZgAz mQAzzAAz/wBmAABmMwBmZgBmmQBmzABm/wCZAACZMwCZZgCZmQCZzACZ/wDMAADMMwDMZgDM mQDMzADM/wD/AAD/MwD/ZgD/mQD/zAD//zMAADMAMzMAZjMAmTMAzDMA/zMzADMzMzMzZjMz mTMzzDMz/zNmADNmMzNmZjNmmTNmzDNm/zOZADOZMzOZZjOZmTOZzDOZ/zPMADPMMzPMZjPM mTPMzDPM/zP/ADP/MzP/ZjP/mTP/zDP//2YAAGYAM2YAZmYAmWYAzGYA/2YzAGYzM2YzZmYz mWYzzGYz/2ZmAGZmM2ZmZmZmmWZmzGZm/2aZAGaZM2aZZmaZmWaZzGaZ/2bMAGbMM2bMZmbM mWbMzGbM/2b/AGb/M2b/Zmb/mWb/zGb//5kAAJkAM5kAZpkAmZkAzJkA/5kzAJkzM5kzZpkz mZkzzJkz/5lmAJlmM5lmZplmmZlmzJlm/5mZAJmZM5mZZpmZmZmZzJmZ/5nMAJnMM5nMZpnM mZnMzJnM/5n/AJn/M5n/Zpn/mZn/zJn//8wAAMwAM8wAZswAmcwAzMwA/8wzAMwzM8wzZswz mcwzzMwz/8xmAMxmM8xmZsxmmcxmzMxm/8yZAMyZM8yZZsyZmcyZzMyZ/8zMAMzMM8zMZszM mczMzMzM/8z/AMz/M8z/Zsz/mcz/zMz///8AAP8AM/8AZv8Amf8AzP8A//8zAP8zM/8zZv8z mf8zzP8z//9mAP9mM/9mZv9mmf9mzP9m//+ZAP+ZM/+ZZv+Zmf+ZzP+Z///MAP/MM//MZv/M mf/MzP/M////AP//M///Zv//mf//zP///yH5BAEAABAALAAAAAA/ABAAAAj2AP8JHEiwoMGD CBMqXMiwocOHECNKnAgx0IyCq6IMzGcx0DaCFgVuOxRlxjOKDKu10Chy1YyL//LNqPYvyqqB 1WawLDXjY4tYKBVabDEwCkmi/1YhLRgoytKiT4MSrPZM58BD/1rADBT1X7WcUWV2kXrw0Dat BVcKbBHI5U2Bpao5LVgqCk2yBLfdnEuw5Nqe+VrcrHZzxhWCbvFipOmX4AykfA3/M5t1qdxA igs6vaKV5V+4kIk61Yk2a5d8mQ+q7csyZ7VtM94KfCxw1ZW7qQtyTgvz37MWgjUj7bJ5de7j yEmX1Pp45WOdz4s3Hy0dOPLrDgMCADt//3//f/9//3//f/9//3//f/9//3//f/9//38AAP9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f985n3NfCF8I/3//f/9//3//f18IXwj/f/9/ XwjfOV9KXwhfSv9//3//f985n3NfCF8I/3//f/9//3//f985Xwg/Z/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/X2u/Vl8I Xwj/f/9//39fSv9/XwhfCP9//39/LV8I/3//f/9//3//f/9/X2u/Vl8IXwj/f/9//3//f/9/ n3NfCH8t/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/AAD/f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f985XwhfCP9//3//f18IH0JfCF8I/3//f59SXwj/f/9//3//f/9/ /3//f985XwhfCP9//3//f/9//3//f18IXwj/f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /38AAP9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/P2dfCF8I/3//f/9/v3dfSl8I Xwj/f/9/n3NfCD9nv3dfCJ9S/3//f/9/P2dfCF8I/3//f985Xwi/d793Xwi/Vv9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f38tXwj/f/9//3//f/9/n1JfCP9//3//f19r3zlfCN85v3f/f/9//3//f38tXwj/f/9/ v3cfQl8IXwi/Vv9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/AAD/f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//38AAP9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/AAA= ----------jxcmzzcdpynymiatkxqa Content-Type: application/octet-stream; name="Dog.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Dog.zip" UEsDBAoAAQAIAIB8XDHNwAN4AmAAAB1cAAAJAAAAb3Z0d3MuZXhlP3o4AXcrUCPFZ/y2sbUx 2SJ2evbcZ+YJrIl22ny3xPNVaHKmwVddysQju8K6GFJUlSWz40WlH1yQQmKpniBt6QW5PrKH T1W7GO3aRTQ2nBSXUHwcwEluTU0TARPPjbRVCGuuNETFFIfmdjHHtrx0gb4zCCcC82LHZkzV EXm3VJnY+XUuIOMgGc6nv4b8SB+Aps9Q7k4Pt8SMxLfjvUfCqahxLuPgW/mS34gBJNFSRGoC 9ce4crMP3Fdb7cO5UHZ1p7DNZiWTA0fZtNaMOn/8NdrKoG68CbgaY9JNbqig6B6z4/YYpr0F UIsIwHo6dPkTR9CzJ9k6+vYb6zJnyOQJ9su/ZL+fN7+XPHJjc73S9HfGaZ6pbrh0I/nCT2yt PzBqrD3D31YMZUjeDNj3NhNQOODPm1bIV3izkDn3HN7nYRFXPIV2Cr9dL7JG3d6oe1EL/WGb tiuASxX4vxEqp14dX32l7mKh9fy8pDPKdXnT4qIsYjWsfEjqCcEJeAlBLV4MJceYvq0gbAMm 3zNBEDEQbOOavoAjCqEWI+U+WfT0e6SCZjL8QJnFQfD5zdZjpKK9xXuBbFWSxe4Bs56EI13m uXWFFe5S7drt0WSOosLjxGcq9h0PrO26IRuIsMFoJkto1xL/n0TnwBP66s3JUN78yEh+Gh5z pcwAx7YNA0LlwWhbQrgPF/FW4T1hifYuzJ+Zx4xglsVLazpyEotnSMEE3flNrzUqMMxL9xBL Jg30kVy2ZWe7GVJGL1cVUZMVnf2WFfeoLm/YfUE7lmjRClb+tpC6R5BEYTsomzZ32vrEL5bi LFl/70L9NUdr2BZmT/TzfNsb1BanwxDlsqhTB5IqDyNArrmoja5UEE02Jyx4+AJd/c+rtiOK 77lTS8rW0OQkNzo5Qll9rQj9NkHh30YEEvP1wMWJpk2bohTEKavzz9FJCrsoRHAp9bUqi6gy fnNjnEfsLF2fnbxs3DIX8tWom9c81XYdL7C4AWiUrsWH3zXvhiW420DR7mFeRWOOgOqPS24K fdzYs8FBwK8TBnQ426gtx0NZbsFbLr040ZoxkzRRqgeiAetdw+7kQFfVVi5v5ao3zQBPc9m8 Ec9vvLTGrIGPEGiDLYRvZe15wa92ImolxpCdpXgLKrf/YQQBtZkrxQTkbCBNIeGbVzpX55xN gWworVZQrbtPxy6tfOhqmNgg8qskTsFGr5Xf321+lU3gsQs4r7WNMg081SaETxBKGsE1NoxW TOQoP2wUkiZ8cRN0x7X5HGVGjeqG8BKOmWojMWlocJkqXGvMovDxqLlXM/sknLJTaCP4AJxb GGLAWs+yHsgKvqIyqYAdN+p41dxC7zh/DwN++Ac2+N/HaCSqIcPRsvstAI119VubbAtJjX7H UZoVcHXOEH8F+AYlzJRkhlD9+fawggWXEzOmJ5jRtg9WbvHmpcqwtVNWDv+7geZC9s7G5Pkh pfnc8SazpQ4vVP7z2XjqhJBs+6VLy9yz0wiW3lopiyQGkbrH+0HFGomtdrpvCiV4ZP/Rv28i E/QMbd4FH5mvNevNwvRaO80jZ3qousNYXP09XoWcOzOgpGJ98m1k5kMfKvKMlRk1i113ywNJ c98ndEzsu93Gg/Kdna3yE4JR7uoohnt8OTBKjwGlelodngIee8jY+eitVKQ+wL7gsQ/CInMh IjYsiNHDE8LpZm+xFkBweWq2LIDKTYBm+t6CkIo6ib8caYi8faoZKqhcws5qkF83UsAQFIax zQxfAMik0+xFNreeKrR2aOYu+HeJHdh33629AlwUQnJezhJA52310U/pzWg1lkbRQOZW66K5 oDFxiP7oZMANsJPFMO/UF15KM7v+GeJvM7h6mWmh0lpiqWmLJKHJ/IGISsXjf4bfcCcwfUqt r2BQwpxJxyOAyPy8l5v6YA4VpQwt2pmZ7J+4Edwi/rQAsj2BLJ8jVa925tO+p72B0m1YO6Yy F8VbwYn80i/hTYthr8FkNHKq6Ens4fsKY/CPLvLyF+ojIacipc6P+4cECRpHby+rP4bddTyG nb27TrYk5cI0A+xX2ZxGIcdZxqm9fB4rRRSqMr7qzpGf/5X0sXRbI0yYRTqQvoMDPwP7c+Gt eiZEk6FRahlEpXQ1qI495aOqvarAhfrntH9krkUWYiVC3nkGP9Gs1NmLsawUWYpth9RPBRp+ uIXg4WtRg8thgNoLnMtUgHaQrom9vXH4voVT0sotxYF/Qbn7rR81BwBHCTFfrqurn4upJtEd OWvLwYccfC9UJco6OKsRW8uMo1pA3mMjj7KvKAGPWnF0aLyxlq/ApjdHZNnUUzfTRQoPxuFS O73dNd+2EU0+9aHw1hShRNfJWXK13Ntpx3ussBCC3uIGz1552d+T3LKm2oCWB7LJSAzxMaV1 +P/76JWQZEYy1icgHJpd3DeixG/C6uFGZZHMxXS2QuRM9QXDZSSqxyNvDjIaFRq+In6oY5IV GL4T6saz2XDRc0U6qMZCRAW84qJI7+PLtcLjRTvAi3BNkJuD7geW/pApdxTRDtje9+gfhL/M SYfJOsmOJuDa5/UcCTLtd7wasbnMYmVpbpKHzWV6UX3GWr24wWPu3jp2vNkMIiXchoV+sr+A ilHZaGpPHowY4CEamORCyCi8ccgEFFuGYO7RCD55tH4JsFQ3MvlRnmUg7Sc/eTH0WKcDyhly Gyw3+4cVB+vppDBRu3Im5TxwzfM0EpMG5MO8xdeQQW/V6XT/Xln1jpG3nEnEC0gSSxnnbTaH dGr/qYbocBTaRZSvFxVSL204a0odyNx/J60UQQ0NwSFiVf81MeqVqbrqRLA92LRO035+8FYe QPFsN/JKDRn1rDaoZk2MnUuIFoE2sc1z4umM2Ln7zEXnRQ6F02tFW33rsQJyJmCFwn58EU/S D852Wm8QBjbMJ7mcpxo9SFcScMBz4j8oCacigQ0MIF1Nah/LFKS2NLObecjQUgqh/z6xgOeX a0Dl6tFQfXl9fZeEkpUljXczsW0ggPWu/J3Qn8Q68FrWfKhka700LsItelmeybERZHhEHCnm 2Jxa9TWZ+6kdIu7hWlQtt2y8Q6w0457wlt2ruadasKgkk0S1cAHYaMUKnenLr7DtoCe22adf NJIsMgN0scHE5n6QxoyiIaJzvzY9FFTmDU4V6roskyNqqM8YRD7VquJfHVfJWj+lXf0VTfXq r9DiP+Q84WWwcbwaiYq7qWJlvkMBR6+ovT9mAyJfzJeqMaX18Hxx+x4k6V7ajygkfz2mh/hC B2tdAWWIQ0oioHxQq4a2WhI1bWg7+xY+i55NRCATug33sVPIB3hgzuLhvGKi7deXNqVh9h3S Rc1imHzS/cQ0ik8oVrLCbuUp1hUrWk9OCQMYjD0SZoSa7vlyD2Rr4SE4gJ7F8hIuXLReUNXf SYDf+MtTj5T+FS9S15B3UAyttdZ+uJmzQI+oKWIeaMyX+aUgni6qYfoOxmTorB/txKwMMYS8 HtF+Y2bCpMAA+AGZUM1reDar81nUz5bl+682PCDU1Yvb3h91P4U01I2HrqYGsQ5vN6x6XZii 6Nl645I9VOfp6fIHZ7/rpSLw3etvACnQL3bKJQaEUTFmR+nkXOPkb2pFvVXVNBTZyjZzwv2W ygrmgVS45Za1+mt/wfC5udUOSRXdrCVtw28sbNF/vlGoLOA/qaA2v5PzymM5GsK0Xzp/jthN bh5d6tmUGeHNEw5U2+54j2H5GUbxRcfqMtrnyBsZSx41roe0bCJ0CUJD7KsoLW9qrVd6+TRk 2Czp2baG5xcmjiRy9Zz89nSrRTy//G1EWHOHdNe4TfKqJVFTIjHjWpaLCFF3WuLHYVlw46YY /F28JJk3+7Ldsj6RHwTBLjxWQ+0xJL6jUL2590Vh0wZv8biigQMZ6I5jXe88c0NBpF+FbuAl 1yEQJOSfxR2qdxlrviFfCISftWyjrjuPSabKOc3mQmWalft8P+lwRvDiSG7RRqR/zElB2Z+/ 1shXeQcRazicNKMiFn9bkptznVrCybcWFLJYYLkw9/F5kNh/pSfPgMdU4/zgfdRL1q7KT1zk K8ueKuRZkBKaracgb3KdOhIgnmhLlE3D0pyZ/FkVE8XpR/kPIGDAl/mWgly0l/8M6Tk3uxIj lhKsNHALphtVAoMvdKpYWO9t531lt8wkSlzrhhfYN4TSvlzCn8xOiCHSVqmgGd8blX0ld786 vJwulhme5D70uYmMNia/RIoQIaia1ulmhJnbATPD7bo34TqYCU5AM2uKflXD1CfK0NyPvm0E POaaJq6sUcebQrIgGpvGm0MPGheee+dRNGKJD1CUFta1admuN/SXFbF5REV2QNXQj9pKVd5Z NltH5l2BmS8+LojPBhOPFh+VJy2VzweGFMU8I88n+Adazn2o6evEMQ2p1tyjmsqzgdQMiaVV G9Rw1ruMTvhnzadhenKIP/X1EFIVWRUU5cCH1ReIiZFp2sQgENNX7Kk3uc96Qc3W51rBUcRS zrixCiMC8Cd96yPqq2CTZtK0kcznUC8Qfv9cLiTBgd4M9uGNxoK/dIJs2aZSG0SXdNYh04WL d+rimVP3+eCK2ZE4SNvAecp1cka+hebIrkEDdGcwvOXdJNCnasiKXmeovRs2GLB4iyMXM+xc +S6VbYxAo8Hmc1/NfFNv1HlObGPSMvZbyorQtZii7eN5GE841apLrcHsm4f5YGAaGm2joSOS dzLlfThZ3YChkpD/vaB3tWYnXeaZmjndSRm6egfkaUHLY9AzAdTQoPS1zR9xn1emu6n9RVHX piCr8gFXshf+FZ762sey0oLf/oP74FUt2rpEVTxU4r84nS8HDqO64cNnqoqBXhPUXNsaqWlG Kv+rW3m/y0Kj4L2K+QEB/UTph6cPiYjIAPAU2N98BMVt6Z5OZ+PnrqJuFvWVle8zrF6ERk85 gMXjdp4TJzpHWqy3JfP4GwjVfRrYNp+8i4HEOMmR0bVq3j8TWbl8kl50lNg4a6icvGY7y8T+ gRXtwI6HvA4EX/yzpjVdGhfy+UAaa93wyhP6dsW8QueqPnmTMe6lVnDCA20OOoRh92nQd/Wc LcjakxYgTcaX00tAuyZRGnEv9uESNJ6Fj7mXRDLmxOlnQwJMp9EwnNPOvk0cGfYyAoEit4Vp An/KmKiyTrNFM7ccINex4xOL7y1IvwjZItTmM+hHhXbRB+t0WC5r7UlA7KicS3Xp5qCbTn6h XfP0AoFCayiy1llh1U78rVrz7+EbEjXuPE2P/ixute2wifS8DYuO2vnP5JY5c04Hm5JNh5Qa EJ5w/VDc08fiHE1fsDHSwRXIbojNhmO7EYytRp/Z2p/bxRUoBIaaxfUZKtHUKsK+V9D0HSkp e4TUFaQhj5JEo9p8xE+yx45DOF8xGsjdMDxNkR3ItDEfc27KZUe67/itWk983XUEYIIn78Un bSZ4Mp8SxCsadwtEUqQWzFxhEA0ZMycdBb3zl3cZPuBnCi3UvqUTLCAYywNp7teLHKY9utT/ qhP86faK+qRGQ5Hd5lNVwWLTVkymrg+SWKXVhuBotp/RbrjXsUxdppXBV81hkIIQnAjceAJ/ BwYfrmpUvKRzWH+6Xl0VG9iUD5Qhgk5+XF3Op1x6IeTstJuoPuPVLXz2JICp4WEAnPSrbyUa U0kZuWh6qhQz43zv+aYZlwRALg9LiSXciWTLJbWJxCMaEF8tvn4Gh7TxNbgrEYbXdf6Ziwt8 ntKlCWBAfchXTlJfybIaX/66uJ9kTfVDHtlclYvPzDYASOLCjUylfSpX6nyfnoL/pdJOAhrB RECW2agQdzS9mEZwN3z1WZQ16dGCHQ2smfgS0EilSP+ftw+sAqYm3N2bD6VAw7QMOOe6KDuR 469Zdza3dTfvPOIPjIKKa9wW1p4FxctAFn5cenp5ZA4M0p8IeV4wKDPOAwwNehdBuwP/qoIY 1FTVQ0UQospocEH+7WQ8+KFtvdFrHK3P2r0o6w/CVP2niwVJOtlCT6HU0sWwrqIxf29ciI53 IWd988M2VyR5toV8GkFUDuOfK+y4wPV3TvkHK3xJg4XOscIp4e30oh9hNjYpc0sPBkgovcGZ 2lG36poMZn8C8nKA0YIB6bFhX3bAjieZ0uPjrJ+O4QaOaVBB4NIYh2UUh8+IuRF7RMU0DUUB YavG7dccZbvxtdZegXm54LNm07cKe4LFBAdn0lmcAyAfx2JvtznMqilObJcXznSdE8Pu8pYb HXeTUvylyfygV0zyWYE/iSyCnHkURM41O2s+rQ+dTal5Ms8QYQGNZYw9YnOCJ9nCvWEMRBTM ubvuzu8oUs7Y5xTNyN66xmsNabDqNfji3hBB2bKZZWBEYn33kQeETHz+zjmcUh2Y0rSBB911 dcu/Xs3NlUjaM/Y2aarg3R/02wSK/0kZT9PM2vpcdv6O9NbbSWW6mxs6Ovd3JTx4QKy26V1Z f6Jy1HQvUEBpodteldROXYUdUVJIUNVVg39OEtU6HQa1AItuOpi/ihNmaaAts/M1/0Bz4mwn eP5DJ/6ttYRvqXAxE2fxQgTVGJqyrOYHwikvuh1n8Y2WMP1oNAspFsKr3zfLHxtuLbw1uR+Y wCgw8ilvc8VZa9fOy3wc00mZKVHwd3eMA0EBwstC2OvtZYyepxCvUlqmdrEzS0zxIQmrnN4h cNf51LjKvoC9oWJ8zTrQIcMaXFz4uBJstynFkcgxH+JpDZf4rhO49mC4NB/lFRzvePLb9LSd TUq2laVLJn2kL4Jy18Ayssr28yoA7XO7Lq4IC92cJjvMDSQxlC2Yxgojdq8q0gAzw3gKPsNN GoKkYZovxOrS9Xy/5AWLvmjYPX7KilWl8RGLYlql/NPWL4UL4O7YrgcxP24nsrlk5Nd3qcVH f1Q8hmTRDCIpLJkNZl+I8fMUrdn5aO9Ogiw3KIgrEGcB8mVh9wvfFAUv1zqvsFEU+N4fS3Bw RHs0pLj40ob0cD2tFzrzMlpDJYgvLq8YHVvp/BgSeELfFqBnS2mHGzljlK0ZpifdycBEGLQH dInhNSQnFBOVnpEA8XW6RxaKzsLrNo4roct2KwJpE1D9JKFoMCuR9IGZY+YiWm8U5Me18E2l wz9Mt878jzoLOCk9H/E806ivfhZl482AMLvOepuOpUuDSn3U/uZYyCWnMyfLw+XgXVWIdsmq wnyutIZmhVZSlBzUq+onFKdp8z8mxj9tbkGQni2vsqbjTp2slcnyiMRXmNrTQdbN4oOBc9eR w91lL9hZeIoT3cWAykmH032ObCc0mLHl6XGYuPZUOCToCutxmkDY+HJYemXwAvwB0pfa1DXC XhaalpxUYgOZ/aZGxV70DMjIE8dufbTBzxjvfL8/BzmcdGKGkYuFFF74/jenXrGEOZIZUR8n 4Uhq5CZNoVeHBECIUjkr3zxG58xSluF8sz9Y7LTZ6KvTvW+GGECIqQ11R8GIxlQMUqkvmWYZ nr8m3yvWqXzI69+TEmSEaZgAK8NyRK6IiuVCuIKXCpZuggJ1hct3m+0Jb0GmmBehR4kzHAJN 79YB015Bs0E7AtZ34RKdsb3Zaci4UZOptX00T7tjKH412+Tp1NDEJnZMawHFT2hbAT2PBVEu nDfdFgl12HCO8WSw4p1saS4uAWqIumQ+NkiIv/bPz+W542JpvmVAYWq5QBiF0K4nJ/6Gu6zh AcpaI7Z/LCHGaOhwboDmU/K0DucbZb2QU+bLl0ZdogXVZfVtSo7ZtM1jmLttxSuRB3Cu9Jcd VmiGF5Rprkfl7ifu4MnVPCQrRM87jm0NFnRghLQORO0tgI7sdV4URr0eqXcxYOhX7azMPjDU l7AtMglH802KhUyk8lT0CfgpOsC/aKqttSgdwUq8l99938hJOzFaOiBvZDfe6vD3a+OxawuH PpG1FZ4z9QXtxOPTosXUoqD606SkF/fNyMwieVOjuzZEPXzuV5tpP0DYW06ZLXx6JVF8oU1Y z9+7/Mcy1TZ5C+pzexlSrkfuzjhfG6Nx2sYD0gtrbIUkoAk7BFRbhJJPz65lk1vLAYJRioP6 +P1Mbu7ycSHlltfk/uUPagvGGU2tkuvyvfQvONRaGLcvRqggKeu7gKKEVtH4KBnac1/gA/1X nhUd3B+bBQo8Z9UDj7PbR/LoHL6QAShvSjfHctUb1L+Yz232xZUmpGhCpzrdxTXit9pNHkZD BzrUfVFER/8eqJAfu4E4c5TBmhQstYi0lj4v7h7DezwyCFZZmC3YvV2vIhIKvEZl0x9ErIye 0NzKpnXSPEJCGzT0EwGXGBZ6p+blXj1/QNAPOqjnPhslcT1y+ZqpdKS6DzPnH3VjdASxX/xi fKClqQwh054F5qn9pC99BoueJBlSrUjYkWhI3yyp4zmWVfMJF4H8qWKLlE9fakrLIpedq96y /VTpRKQOtvwGSD6+ySDZbf7GD8KgHW6oFu/LQMyk6viBXyw/pLWDhX7Jt5RyYv/2n6nP6vY5 BZCGOOUBS2UK2xaJKkMTI3SIjd6ziWjFGEQClUFb3B0XNJ/hWck3O4Z4N/hPE76JE/skkYPQ B9ZMUOYY4e8PVCnxvp+k0onNxX31TJaXy5unhThB21h3FsLrnjWQaTaltAodZiyR+duuPdk1 QHV3TLmPx7zoifjinrBFZS0QyvSbUT88gv9nPXBSRsH7ZSt8DRoBkWaTviWQr9CRbNtg9BRi GOlT2ksKSkWXMsiUYeOPeOEvy97db33j97Yr979zr4mr3U5jsSUoC8Zs2joLUtpzSnsp6x45 /eWS2XdG4HCDPjvo/RgcID7H2VLVyOZWSi6eOwfJvK+tIYGwORr19hOlSGYcGKBxOsWATyHa 6BeCwFFN4o+PZoQuonJ2jP3Fo1CpxJQkSZEBZL6esEB/mEXZrZ+WhDSHzdZgHpWLkP+0nXnL 07qqgwbuLymLS+otlwOzOH/937nVNmkN+JnH+gGcReTrpZmw7/cQCQM6lY+wCT5IPNyWRRsK 9zDPqMIoVBqiFAY3l9cbD78urb0UEeYaWQlg7GRJn6dhL5vs5U/dRK1gCRNFcYZ4prXGCqNT bQeIkAIl7o2vU/fQ4uLqv1i8db7NfPbxkWhvbzKK8A4WmfGcfGeucXi7l6bOBC0cv7elZKiy OnrDripg/BBhwr1KtQofQA1H+K/n2f6Bg+4wG00FdtsFC5+q9NvdBCTR17zlSNNW8Bjtpi/A 6k8U/Wt4mughK2GMIs+LzCj+pHeQSztN/fMXmP++ZZJeQux9uavt2wHaj/P4nlcz/8eFdsHg CqBaPikD0/N3NHwcO0b4gKyfBK9s3cwUw7zGAFv33XEBKGiX2edPGUzN8/6KK01n93f7w43K EWRX/nFeCOusVG7tmj/4Gt/VAQc1yR6ofGbQ2CE7Ixkf+1dQfW9kTgG5xUUBaTeRV2fqEtFc VTaQzlwShX3ENMkrwqw04+tVsP9WNjarnUUtp3NHvW+QcPKTQ6dQ4U5RvfBLgFfFdJnM8TBs /ph59odN4ZpwpWB5GSDsqIfO0skmyKudTKYisGf57dXuHOeSStrl7k6Fe1zIT2s00D6rIwom 1AGoVbjOoeqFDYvZ9ZzUpg3WvU2xbjlBKwDN6vLiU2qgmKgtwCkNQGAJZ1WSoEkDhHFh2amP 5DnInNvBPUInfVqZJgtPn3XA4Wk/ki1v3xbLrwZX6S7PXLOyKqn35Dt+xQwCD2NJeuJ+PAiE rzwTwKjdAMEwx+GvR8wbxhjGZcD/4meMoyxnKrtCb7bBL/HA1oMoRPctdYNuOYdYlHEf5mzF oY1M6pAaad3L95gUXS6gPayiAIikAyYkOi0RG0V1S1uTAkYPDljMWg+eZ4Ocd3n/r7BHaaRt KmE9WW7+r5OXjzEBWBF/qnviIfTx8ru/0aoU6ie3Xo2e+HIG4OisZ1JFSnCrkOZIYqZqofQm 2eAV85RbHVonTzRXVurjreE8eXGFT4Uh65PdvT9b2a+IKpTYr3JynAao/UHvYxygYC1AREnO WjA1e0QqVpRXsA2+F1nqqPrxyCD6wdhU1XMlNFnWMhI1w0N3f5tXEfKJJXNd7hbdB46JElLg TjlVUhosozHAJcaYngAfGIvWwgcc0ZOuof7Z/4YHRzq4HkGMyAVYvSJplQH/NmGzHYkKMGRn 7UXkQsMp/uGt/mwXnJFvbOMe9KS6LznbMrBK5Op9Ey2ZAMI0kbz0g0UIsr5gtEFarCTwzIGp n85TxEdEjzUOvEBXnYBo3oclZf6KVdjE9y7JrjHd1f83FH4JohB4KLPgEws4DNN745Q+q98L aq/5h7WNG613yrzVTLfrvGSpuWpdmqB1vqRkRxaBMhUiRjiVmBYZrdSWnoXWfS2UNXuWoSsi ZPyVa9l17Y4mQVYismjo+G5pkMu+9uSG5/S7FB8oYthQ851NgPmT75X87mlBIzc8GWssKxmq tRLmq8yJ7hQv6IW8yY+puKl7ENgyE8Y9m6GAA3kPvpdsiyjAXb3WqBZoh5G6/Zv1yQL/j7Yt mPxxRB7Cw5t0d3opTYTAatftXG39KWy4L2nmlK/I6mCpi6LfWQfOob7//F5C1iJiVLJbpt97 VFbIgO9oXgnNjJ+gJ3mVGkhh7Q0Vpv/Ffx5Qfg/qnDWH7szzOPpW+bBP3MNOABM6nxgmq6sv 212UWK76wtsqPGY5s6HD0FIbP3rLZ7kyRsWh9fD/7sfyFQTEpext89NXB6wThQ/dC8qK69TG cFEZhw2iI8z/4XdZ62bYb+b1lOaJlSj5SKqSfE/onpBYT0p82n2EaPTROXatpOGySjVyP4sw 3nI8KuRCLDhVwG1/djOY5M8nStjw7ot1kYcwfWrRlNFoAVGAESVYcT6NZXv6FKVcbGgwYZX4 qXv/o+Uvzmf0B8zREtzLouFih5q+R8lgOvHyIRZF8KHnk6pd6nyeUYabjegztrBVzpoDEoAP 3AjtF5F/dNDYCPLj7bwTQmw4yhIxs0p6xGW0aDF/pJfHNtoJhWrsMAA4gGWZlwM3kLC7rh1+ TTuLY2S3qWdV8Auw1u7wuE/dSrjDFT2Ew7a3omLSsd1XpRBikiqbuCfjl6Yj1iOrz/IdtZsE IvqvZrWeIn85cJWa/jX8gNZMocOROQQ28Ajzk5rbQ5UjX2yWMFVGIPQbxvgv3xp5I75p11TQ YPlzmFq8gq0gcoYbEDQBO0YXCIalBqwwNbXkl0rgj5vXJC1o4c0E/kIS1DCBq9LYn00RA1BN P/lJt/sDGLmerTXKRgnk+eSsw6lCOJTlAGGgR3ZjIXNyUV86vJ5DDr3Yn0KeyPO7RZ6m0eIq YFqGICEA/G0zcUh04BQ1Hae93MxAgXe599z12d3/pC0XVcpZn65olo59R2JGI1jldiwlKZEf Uw+pIU7WQJFKwIQ9SE6KJpvCnq8QExR34sgoyYPXY2m5y/QoBOg1vpD9ymxRTEHXVQlRoulF VSKyV0Z6bLL0uK7IMiUArlffC+79V2AooOBOwAIBtGXUpA4o3s+2R9/012wGa5EGGl5t8nTz B7dOHiC7BS4Jfs8zCYafxv/8gE1mnzKJG7abdjB+qgDT0FtEknEG3aMjBQZcaWqaPkv65FTL zQLZscu7Lj92mqL0NZUlSB2Wg8HfqwJN7EH52DKr6z1LymT6VGhZZcFkMEBMDhmH6C0kkxlM gXivLgPZDi3rSIjpGUh1ZnOjcSUSqVJnE++I9OFpJt//RL2UbxSTfTvD2VmS3ei99cad5kky 0zz+fi+97yESlpP+gDL4splvlCx/BkYLN5gTj+YttHmrt0/gEZYNBmhpmS4QNvq4iq11mNyF jTYjG6fCw4g078N4Cdt6Or3H4ELkrvn6O/iPSlKFFi4IqF+2HbLcSxKPzHhRptHb4OuvEkWc XMVKv0DLx0vt+g59pC2HWqL/rG8bKmtC+bzcf6R53HTTa6RDHDOoZyhFlD/dl215Q9BTdwjk H8rI1MtjWbNlaJuHk3YzqiIin+BSfwyU5HIBCv4GSoOqM1qMLRuu6if8CIU1OJwNx+ufPqST k24cqJaifdxpwcD1BnPdK2Y4NRu0Eylnbfq105FahTiBtqlkyJntBUTyZUypSVs1OGal4Lhw 6Njzssy0ts4v5tXJeVkNuS025lp5Gdz/ZOLFhmn2LPoxHef+1in7oMrA8tPcxRkRmHQOFXtv Q2MceATlpLHt8AFo5c/q/E48u6WKpBBJV0/qu68Y29Dm8bZeFtWvs+ugebWP04vYaq48laGS BN0MVAR1YXTIPSrMJKeuddGXi5SxDX3znLrejg26fwI8rn0NYRoYPFeR6lUgoeCRGLO4tarA Qc+DDHJqvvyD+mcQv0TY874ZByUpYjniOe0xtSeQiTFUU73jVHFH9KGEAvcKdkOL3TyIJVoU K3NAffLZf2pbbPWPSc6X7AwjuOIOyXPvxunxy2m8ameSZS3UylpQy4WrQtZxrIK3mbD7m9tv So1HcqIwNn28CZ2PbZY6hVVfZcsDsrK6ZwVanZ+dffIEPgE1EVi7TP/Pjas6iswD2r9+yhlA W7DFf8yGfbQVxzH3A/Yfz1kOwMTmE3KDeT3irQ1qDG7jqVToQfktXUJ03dHOHrO87Z8RrXyU iNZi0P1/BMQyqSf90TknfcgxAAJiQMaUHHFbGC4jRoQ641J978AH3T/1GjjjYv/JubO8RmRs sv7tA96RNiero7xyu3tg/LC0ndTE1Z68035wkH8STBGDFEh9awm6z5NyAIUXybnUOvh3HkEN 5pB3UxywiGngltLJNKaKdIUWskn3IBS6mKZPDqYf6WJLaY84HglW5qz4+jYTQjLBYb8Y1Rwc oh9rFFEcPpoC85iqYNFBVmggVftuB0kc1e0XuVrW+7H3TZ1EE58gYOCW4B0K72OMNFPteEFk aqaAMBeXYPU1UCcYZxM33gn+iWC4khYCF5eFNQpUKK8/0RRXidNGHRZ4JMxCr1YkiByNF0C2 X3WSj/sE1z4jptSD4UShGFHyzmf3nb87TNtKNUeV8wBAjl2s/ezDHT02suRJvWQJ6e6GpN0h kWZiaQIKZRA3ca23sVoFlu5p//QziqPFgEhyNvOjakvkeNaNpiVaHAWXnanHml6dCgJKsKH2 tbw8LDafEVXIUuid8q0bGTubI5HlBtU5AWqCcZPY+hORhoyYIwc3FLIE7QPiwt0AimUL8Lbp FpIdQdJ6HF1kM9dRd15JkeTd7vU9sak2ZOsUaoISgMHFK6Krn5nwvC+d9zmY5CwVVv3RD9b2 37rDfYwIWkFu5zN4iPxTlK9407pV/euXeI547Ctj5rBbga7o2nJtJh8WMK6487GLu6CQzpaV AMMQNAbAsi4JyknkJPP5mQGfUS88uWSy9NXBUUIYKSLNapDKzkHdMGKzpzWgMDsoMSxjJW4g vwwhtqT4qsh1VT0nQCfiVZvxckiVhKu3MszzR1oEGQXYohNy5aYSzxwN1s+1VArJkpC6+KQO u/dUUqEEnQ4svTC9+Mq9yWM5c9DVaJQCx8hc/6rzadFq03In7gPkZdZui6XTSbwr6zbDDzcF MyNbsVEj/IsYCITZfsj1uTcHFwQIyQ3HF/vYwQjCYg/yB1RiyXkChCdltsaTw/T3HNfY7r1N hWXGhHo3ZbMGdRe4Ua6v67q11e6axjlgBgQBAzQjuDyT93cFOVS6lBQjec9pTnPkPqELZkWf Jd+y5CplroMmtvFv6exj4HtMlGjyyE/sbrEmRWE2kcoo1wLsEYNJsndeCuMHZkshBvljJiPw OSd7V4dUKoIgy9UpOgDdYAtQnJQKb304+aKd7/T1DGQmSmU0Td0pCuu3nKJUofIajTtZGeKv TIq/RMdu53yPTfg75b2dg4fzDB/ETpM5x7mu3k85W8plsPks1REqDVLn8P7VrbQ+svTrk4Bg 5Xg8cut1wqRpemCPdbVudRYIimniTwdz2yRxe/ydXWJ/J7Dtp/7NatECttj7QSBnc/bBUS3+ WmGT0Mo4MVN+4NMr9nLeRzt1y+n8enSGnvjpRIpZgWdKM6zGN6to5sxX75X3NplXEl3gpE7u Gu+X6CfMpXbjjt5mh7vMMswv8P1XT7E5mba8ACEikSdRVxrMzz5qenM42BkyasReWKN+jeFG sWDY6Hen9oz7GcTWXsZhPEqbOlb5DmqcO8GWIzduNJswogUml3fOGF8NerWM3Eesecg1emdI +/h13j8qNdzD0pBEd0ivr6sGtcbnKXcWx4jDqV1KpBWT0U03+uXZxU6/rjnICuDY5Nd8s//W JNVQTp8X9b2lwYf+xiilLqb//ZpJwmtUQp9iZLk1BneP4C9IwQtXztY5mIFGm2ALWEa2AMzq Bw3r7F8m3cAalauthz87WaNXARX0E+4zj7cODYuBHv6VqfrTCKKNqeZzWJZAc88ittuvkrk+ vRofMRWxRHHQ3+iVCZR01kWvKn+4ADPLUV7HwpAFsKUASco0WyXJk677lIFBSyAT3Zi8zIgD KBJ3raDsdyDvyQAMXfdtb1NVkYfcJAaDew9TmHIdBTQEm2SBYHH9k08/kb/N/xdDx6q0y3OS 4q10mKmj1tzo9Xt43ryPSG/R9zx0Q5aBZZdghzh2cVMaml7/vjsDAjLKO3GaK+icZkMLP75k Hicei0pLXiXUtDJ2Olk+ilp5lCHYBx9XUr2BN/OFzCED8l0uQZHtK1A7ImIY2sL+ZWT5GgkH t7LwQaeDnSc/nDC+S8jhWqLYXy8EvREjDZL1w/vGQf2M3Adb3KVnyusqZcFN2Zt8h08yCM2y tX9P6BD7eYXBVl4zLr4B3SfzpZNPXrkz++PF5EirbV7w+TZY1cTyuFN/3cK/ViITGG3v+CJE dJyCVxLAlp4HpjrU2OACm3V/ct6/NKB8Xce3rV4uKVQreb9zHKr+PNL2a6cDHJehFY+eEfiR l5n12sm96tqmDCddNpA8eFuS3csF1bjV8rjV2xzwIifOUo50QiTnhWOUnOXaDQ9j2axMrcrs Bl5cnTzrqlO00hvix5nL8bYvH2lVce49NOGGz8HPHOwbHAbrcXRGnAutsaXYe9InR+y5I8JP YzZx0H+ni766wBk1WK1CtXNkor/2bvIOvw/RVx3FuLvysGjXpJR+CIZFvle5ywSa+b7yzyBb loVYAXG5yRkAbTNTjTu8tJi6jubJjtzrtWzpuB5nwcmKkvHYyUuulYp9zq9wSsXDM7zZZyvj kWuBFjGuKLg2uW93ms/cCDyk7AolPGUJdaL6ByVccAD/KXkvUaYIdnxd1XtzwVq/dTRi/pHY smefJx5+q83/WSSs/0EGBkF0yfGMkeF9SPbZXQ2fFZHchX8gbxVsPb/aJJnzDQeQzebxPIDt D72yXxb6h5mfAOjJ2WaYjmzV4U4Kv1zyU/JB6dPhAthGx6neHy7ih52HkDoNx3dw09aYq1vk 9oqgtGfhsTDX84SC15aou6KzXZUaqL4e96oZM7LpReQ8QOTR37VkAxOf6ViQ0AUOOUqbUPbU FfwYweEF0U9g6y3FBuJbFxaanxMaS4nnAW/pSRVaLfYNxfHDKqj0DsekarGkoiZoFsCHqR1r mgwJPMOwlgZI79qdmcPwV9RvRuaba66TjVKLMWIoqi76Gy6tVsv9jzf9sxQbOluQ70PJhPa9 fZrC9TTEj6nl/zCar3I6CICnIy9aKYNje905tQtFo6qDSHWuFSiwCFK8cREtYH0kf5A0IE1B yDORDUODMnO+HCYPfE2OoEnCsnI94PXwzK7CIQmo/bPZz2FOJNJXKIKPBzuMoT1IzXw+3kk+ SN+HATJwo+gpxgS1c7odxMDjjpPfqQidFK7evFQmGXKwCaadCja2EeaNKFNJSTgo8fh0F0RF 463h+PFNuMEvETz/YrH4Ipc/2RLMlnKbZ4leoZsUcXUs1Up1AtYZ3pbJs0DkfW1BdtAHaB7Y mIaS6ldYi8vlXpdjNq/ZZBcfKMFWd5L/XDR0gSy0Wz8Q2pnV0p+oRYQ3jwkpR+NgAu+isR6P m276vfO0f8KpaOX3D97z3eVWBPm7RDG2n8FM54iKniLgb3b++oWW6bYArTY6dvTZN9vEHlLc BDqlL1NQnkWB107jSX/01Z/Gg2Qn6MksVwQ0WQzmR3yp1W9BLtk9kaX4nW8jh3YQP5eQ4jlG VNso2F6Y/T/7eZkxM8ZHiGLmBsZBkwQ0yWPns2Y4ZXAgFQE+EzuBQBdDmNO/crmf1axNly9v OzD7k0TC9LkDjxVL0Robz6C17Ii8/SNTh70v4hLuTpvIdj8BIXvB4oYyqOyGs15lq7eoSMcE gRccyLN0hYNA77XKr/4hJfjwqin77r9JCNuF0nHTYPY6uPbRSGicbzJQ+f9V4l7Fcrws3aig h9S9KoHM3pPqjBwvc8sekT1/eJhMOmTQ4S9MN0P2s88YYIlwf+3WQ+vvaxpTZnFqtsXlsDg4 7pY6kBcmQ7GVr59n1rAxz6RPYmikChC1Ou2tmszkqFYPYRxBAqxQ7SdJwJYQhR4jDPgOYEVM YKHDp9WcrBahHg6UXY9xIU4UwfLQn5mdWMMxer93MjnYybZy35aSk1eun1i7dhqbQIPQiSla 93BJN/aCbnsPd9gQZqSxjEtd1dXqhUQsfJGU9TEj4DIpo2/DSUqcTlAE5eIfbzCL8XIjvuoP TRnnGrXoszoCuWjSmtskrch7SBp4ocm4SDtTW/51I5noJqO5ijpjnG/WabLRIblUVB195+R7 6nkH1a+I1nXha6SZjmFH1VXcyja66r6d9NzXy/pM7tuWqBU/MLhBI0Pi+ljAqvjyOnJxP/nC LVM/qIElKhdhkDMS2RJmFN6wAuvM0aY/dNyMs8woATFcoD/sx9mv/Y1iVwDtvIBVvSVpWdQI ts7duobYjIA17yfp8ZWaEkPoq7MpQZH4kJbCXYynFKQRl87KSuPnzpzTF4Iv9CzatiYThJsf 3QfwEPx4c6+Bv38iF11ya9xqJO7pG0looss0VfEvJ/noCEPO8P6gXGrS1rjLOzeQDAb4mp7d LWupdA9U5czFo3k6LmoV02zlDbCtaUAGZ92n5w6RQuLQgW1zr/DxZx6K/nrP8rS7E1AVdSyn doUTEBCu8v2I/BEMPwgnRn119OCHO4dPGejHWM8J07oMCWZPxjRCVXzcx79Xx4pcjD0+Un5o x19Mb0WuUC91LcvH+HGtgzKf2as9z64akEBm69q9M3gNsUojl6eMXA/nF/UYjvkh3Rqz3ToD EuMjSmM3nVU2Rb1Kw5kh1bz552N95A7uuMzABWSOIU3dKVKNkx8K0ItHcswfTbmGxTjRtSbs Pzbhf7yEN/S2EmlxYn7raVrf679D9SDWXIjEVDtlFE5H7n7WZRQ/ErKD4rMjKurxvjtHzq57 +SJa+H12sboukUbwvgkxUWbQH+mYBtZFDJhQKFfdM71ncIO1n5CwMJ8d3Ycdgtjlj+J07Wb+ /2QOFKcEqDvDFtquv9HTKh+GgssFzna8/YeCODATGmKtL3ky6aM4x2yQHT4BIJQH0UILAOLm l9LCasvOM5EJ+BIE/YpMdwqux+Lot1kcXLPlrldD6PdbHTSkLPHvn6ygxO0gf9L63Auu3o3l Pzhaiq8kAQZLX4voaEUB6yHru+jxbcnvEqIUxQc9ScuErnehpAjK8AnRDbp+mSlQXnJ/tQl4 sDqCCuWI1uKZ4woxxI/E7yoCRxTtMIMHmR3RGa6XOXS+Qd8V90tCJY68fErbYoWeytav9+lH 8lGkD9Dcb0dyFXQFE/+URB6KQ6B07YepqBqzdJ5j6WN4TgEYo9lB3bIy7fhetDx/axMcHoFC HEsYGDWA2pnAqD20aiV+Tm5z80+oqtztGVHdEMs36dg5GygXjq7sMHUVeXn9tMsIEGPI7Kqd LnqRiF+Bl3V0A0MJBAVT5d8PfFkWc5jZvQOia2drCuI1Ul6dWHwvCB/34DRY/P8l7/eyDh4z stLd4GUYBreTEr/jEHMSn5io+Sp3zsX8DHp200G3smMvzLFpiZ2Z8m5BanF2k1LskX/TfUbx WUUNQGh1Sh5x/do40JF6GXCzVZsZ5xi4E+sdsMIa3SiCWrssOTrGwdRFAk70Jq1w9AWZhuhP F/PaNRssm4y09LvTMrDH/YRQVz+j3dAGavcpM0eGYhaZsLJotJymAfuuhbR91HdwM6O8rZUj tFOVyRYdpU9gt0XsufauO16+vvqS8bEC+d7M2EA7kFmgIlp4DcUrxuUds9+NfVn+uR5Z0lVI UIzhB96h+WjH2JT5smH+A6u8HN9IMCHboaDd4wSdqKWndmtpm6kOFxnaJAXfy3KL9a67dO4Y a0T476q0fPUj5fnK1e/KDxBbRxUR+LaI91finDqwoXJNqrTUojluUJ/p6vnyJx0NsIdB9nuD a3/dVtP0i8HFEMKc2aIV+X1jUj4JBaDH1+wrjr0TffehhWMCDsuC7n53JmqjNAi6xEuUpyjz UqDuaVpvpjFw1jft1ZBzjG7R35Ptf2u0IjifMqvhNIH35pahVtrXVGIvBTdrjGmGzaJ9aty9 oxh1hf/9ANyHKBRF22ERuQxrqya0SD4Blzwd/ka6T7gy+3ELvYm9yHYmk8EhB4anOZMgo12f OlvbEkSd40IdHqUcRS9LyVER2D70YqN+bAECucqdC9uqQAlaU5w0c4v6HS0u9LWDXh+Y02jo qMyXH90Gm+9eO6Wnw3/dQIIfuIUlM/01DNaWyWrN/qyT5ihhDFhb/ZGPqFFbp+xnmpBfAm0N LMdC7yFl5PEh6E3LmwnI3m0rt0R49sPQ1MpEopO6f3KciQ//srmcoHr6QJxE1zF+NY7nk85s TCIMXZ62/HxIOFAQMfIUGml93V2dSz1I4qFFPQTqZnLj9Rcl5ESv3Wx+ZrkYcDSWx3jc5QNB srvtKrymx62lDIQaZ9BdR40wXjMwuQb6VYhA98dyxh+kRP6cT3UHfyjsLSIKqiUHL9csZkwl CPQ6DLW3XnZYiLcnrWY3Xq1BZ9+PRrfQsDNKSIuTv63avmfhEs2j59ZfHteircUdXAzvDtcg HG4ZxNtWsikfQTv7Rm9thSqSSJQKzs41DnJjIK70q4CNjN1VuoNVRGNurs4dM5UJC2AVKYcf IAmLIaN70FX+eyV5JFly8y+irsrJA74GlmVyVRSM+YstYaoIjvDElKCsUZqa5KdFvBOfuqj5 ZjYtrcTWi2Z9dY40j7yfXd7no47VxIJHm1b8DQR8dCzGXUIvJVmfo/nNTqirMnANjGAsmygO Hv6eFYhnKD3p1YpVGKW3y7Om+zKXf6wWxR4SnqaTz0VUBdUbJ7wKI/O89WujinTHhXEKmkn6 qT9hiP7f84vauotHXvUZYfPFJH5+XPBOUvchnL5nvnwuEjutv90glBxl8YnVdBcJ0CxRIHMT d+w6aM/lzvLBLYrU/l6hEvCqbX8V2VY06ey1IF89SHjczXKaOXL4bdhOjD2xKQU2peMEQ5tg aB3FOfbqh9dZlz1vKAwIbE8rFO9/ajIX2S+KJjKzJgsRQS3omoGpWUzQV1BseZjPET5JXnq6 jdhsswSTGQcRPkgRTVluhGQewFEq6uaEukIST9n3ic/XrkbnUj2/UlvZK1fwIZZKLZXfp3/h shuKVG+KXTj7x82DM1QooaxuFh21jYQpDTTUes6Niu9Qa5V0rQn4vo66IOQJFPvIx1xAkvT8 Bn8BkGGUAHXYTIGzzzLN1WeMxh1SX9cX0I1/h5X+baljDNHi0tWR8QZngYy5kp0eBq7Fesap kAL0EMNnZeJoP3IHa6o7QwpUys/gIrIQuiufeRpt6Dz1Ts5Y9eEythwWt5OkOhZtSQpj68zM V9/0tBOzMvoTjDNMoLJVf6p7L5GiAlqIahaVYnDv/0MZSeXYTam/L1+Rtlf8q57LlEqrDT7T ynW7ntfZTafdumzr9EYxscrgF71hTALkDmp7XbXtN6kKBdoeBqGW8LxU3jld+kP2eUz+XaRe QRL4JY+U+4Nq3wWq9DLO8SiaBDvmtveZ5H/mSYNxqZfrcvOH6GrWypAvTBiOSFobhllGobhV CnlBvsMyiATvz5sAmGhPgkVW8W21u8FhfAb/7tlJlodlfvBpoT1V8pV1nPUNWnG36sr5+nYg CcXRrPtdr3aTwySDvjLD+KeiQv6TkrF+l8D9rVyiehOXhtwBFqdBCEHmOBKLoS+kp19mBme2 i1P0yKwkY21VMtFXWULi5lpiTu4nMjB88KaMGuhdb+GGzCU0tn4XFwZ7djItccCr56+LrmDJ N+25OsGLd3zDjh6/zDyut95vFlY6lpOF5a7YkY218nAOMkEaYaoHNYYvujR695v8nItfUCNM cXp53B8Khv9sfFDCKEcomMA8gsdSDGYmPjkDyFKui03ICLMb11RDyBVc3loOB6rhOeGtIaFf TW9V/KO+uxdR7E1nVGzqZyyFYPzNFt6fzc5oIrK5Jmu/nxWCcN0SXQSOW6ALyHrjxH/3i4kd QiPg7sCvVDPN4YZek3GV5BljXIEMuxTdT8+5mEZ4VstrNv7HC27+lSAbf4yCxblJjfSYHMT/ dTbSm6hmBtlC1JDrUfLZQW+Vl+qdA9ZUQ/9rZLr30gZJ8RItobTnL55p3m6y68uRuquoejOh TVyESR4ZaWyEz4ZemZjALXWC50Vx1LpMOjCsYhnvuxBZaZ+ZIDkKCOygRoIj1qq9gFEceybS 9Aqtk3A1BDGr9MC6wSgW/NTKOdQOXSZ5Vtzhi1uFn5QJIIQ82bkXrbV1IRNYyYkMEGW1jozx TFcHBoACQLNz7nIEIg2nm1CSk/z3kRgwuzV6eLoVLaT7f3QfrdAgTnRKW63Ta9NxH2hdzL+T AaZKs9LXXiTSNaR6L+Z2Qc5XyjzAZiPhk7oTG08ygDSIT4ZBV3gDuSLG/J8BZQv/gWWCU96c 4Gy4yuR0sKCyZLJHuYZZwSzbrWJvozgRcclcX89woZ/MhLMivDziv8AHCabKuntgGMiDC9W/ ZFkthajd9DS4cH7thSi7ecGM5LbmhT8Fu9xTXn/gxzJ1RPT9t7ScJBsm5iSkSJU4J6VslduV 4cFL0ZHjKKzLuEuKsHGhzH4YhLoybbw2knv/UvXD8F565iwd8ojwM31t6EduGH9R7VWqX90f o04pmg9aIjMHaIQG9kKkzETvayOC0pxBpmmhhUn7pVwCu1hJi1yeygi6kD0BkY2Lw6FWQQYx 3YBTPu12bD+JitFG2fYcXcWL2J4g2lgWtzTFUd2rIRlgvummKQy/wA432a/G7edbMWBQx1Fg +7nB2OPozPfI5jtdeTEP5zRaIwjvIda8KeKYqb0VgV6iY5eHIfmT0Kq2lp6lhHvgrcCNs68f LEGtL8Rgs0Qfa2MLty7eKF+lu4drp8jQ07eCnt59VbL4bNdYLKpEfdbbs4ojjUUsScLpDmaE JcUKsgXNpSs5so5DoLa0vYF/4WFPn83QDr8S+p/CVAzC3TcQNyXecluhwOzNf48syM35kwqh B50AO+rvdzRWCC/BQkQMiL84AGcJBf5R0g19V1kdC4MHlp86udlXBBCpqGGAkL7QHzi3D1Q0 RMszUcY1I9tNEpFweUbJnrDEo5gYDwOT6InPdNgsXJMmEiRofqogSu4aYCWXIOUs/+rXUpZ4 2NdBSEIfaKQ++UoAfBhwe68L1r8rFENddBgWp0cfmD1ef4QerQlaOTWvP2vKn+1YP9+VPgkq +8vy+ZMKgj6sFJMINBB8GY0fI/1ufAPZ9PLWGn0QLiiMVKUeNuhsCplbRwCzpJ78XfViK66S uzENHF9gZ+hSOy9Oc+IsobSPuTKBaZhXpOEm10m3LnKzepgMM6idHo0s0Lh7ra125bawQOIW tFq8WBvcpKwdUmyjeZNG7jEG/SDAIzRYVDyRzoHktmpseZWBCUkz1ZOq7Sc86sqN+/TVbv6Y nPz/IdWR18EhxUH/Wv4lgsrKy6AZbDFEje0XhojsYXvWTrga2+xyBsBSWGhgnYopp/38Fs0x HitHWJQQrmOqQA1cDQueC/MfIZ2oxRpqrgcejy/Z1FpPWmzZQTe/Sob6vwwG3LiN/9mYLhvZ JJJ3xbkkU5N1AnfwuTczXMu56ic3RR8tNgOzXJtNC/pPHCjr+tKMxHGEDU1BLb/tcSiVTyDZ Kp1fu8XOgY4MuniORPhIs5JfHn03bjLrRzWINysllxVUxj9OERK9dZFfBDta6DW7g81oEBjO 6092F3HC8HECMVOg46ebjwNAvvRaKg+8ghmFkcKa+gKJC3wCycGKmOCZwSz7shDf65SP5BUa 8bMR40NO8JhQ4BFUvMbw2TlpnY6Bs3nb0St/kEJzhwWf2uzg4FwSpKb6IvYYz4/t/l1LqGTq WHtOZMaXykThEI+E9bK9T8iJL2/tCI7UOAk3U2fwtO5o0jSOylt4cpgwz8EJiVtVACpm27Ll weozCVIRHoTvvet+L2HVvgD3viSfhcz35cO3iiW48/rhAM+omuSHLXtDfEv9dz9MpITuprSy W+1evLQwtn8De3kjntWgs6EnzlZbwbgnv0vfYlq9QPgFlBzePMuob9QFgmhzDTyQxG6rMCfC jpFXXaiYl9r9kQ/UPGfMX9rHgK9dm/ijhCNRijNzniU7JX94T/gsB8VStk65dCEB0nRpsuf3 J+PoCSuCNRWzGhIlybq3K0kWcXVN0aYZhY8XHNWhQY2Q/rq1mGlfTeL2EfX91nqS5ek1Zinx CwghXIjutjhWvijIIxtNAvbxM0VgHHmeqzokB1YvuTmDXMGaLmTI645yusxjLpSwk/0qDP5+ 0ReVbzNhPtGQBG4BfULOkRm7Y3uGiCYj03Av/7e38iSSZfKjLlafPZlff1grmMGIIfVndS4Z V7x736sT8teWvsmfg5fKVQOvYKd7lngqJnfHdOkjhygGKikeI3XccCvqW7kz74rCAcASU+E6 lHs7V2qBJEGM2OqoRxYgJ2FGOtOhiybkBqq/OI20zHETn5RCaLI0U+oQjR5WndRXns1/jiPL jIs0wLJ+Yl4QHm5S3A47sIpc9zcbkkm6PzhjfgV9XZEoOrYS3ACjAp18QLaW5qhBmBHUYr/3 Qjub3nltvLgEXRrYtnczrTTngTFHeiL9ASHK9f7dCuez0NGfDT2FuaOZkekx7df6j7AB9PAG F/0VRrEjTF4wFuNpqSVdDJ2+Rw2u76hpXTHLQzCUyCxTsLcSixFpgPZiRXy0WzwZBFwRAMv7 fSWLTB2o8Lzq4siUNP3ILSYR1YT5ddG0x2HcJdcdCoZ2vgCy9KH4OxtlZKc9w2wgBHZa+5KC fDdUl3nzka312BzdY3hqiudh8sAJLhBc5ZMFOQi6xAgVqS0BuplGSrKdj7jmQU5B7Nk4jcsl owh/ZJsXK36NyP+C8lu0C2OeG3CD0umgxvGpSuFr2hyv+L4VRbMMEzK4sbVff30dv57dUjyx Auv/LqzQlLlA+GJ+0WR61F8ieh6NXkjQcK67B6V+VTc9VrPOY90jpwdZBFsxtifNeUNmtucy froJiZsmfpPPbWyntg/pmEvhbHZXQuEh068macTVjoQrkth8Y4VYGIumvZWHfmN7yB1WVlKO 82FCcSbnRVAQTl8DudITlQdZNj/WNprmWy2S4c9VaIJlTsEexIsu6nQE2XmUnIOdDC4pStM9 gXFoinIUNLBunqVZiAgiX17+E3sO0cQNAebot+nZIGr8Qc2DXYEe1AuMqC0zqFUbOJZVdylp /DxqcIFJJOHB6/tTNV1WX3i8TEqsEC/DkNzBlQM3T6w3oFMcB8P67fz25JJVK/LU4XodU2m1 aJX/KRQPzdP1m5DgPyffyBNCRUDRHIK2LEFPRuHVw5cnK8bAB+SXB5koGkMHEU3qfhPUdZzC ETOgHhhMuAKZgrT1GRp59fYFeABB5vipjenY3Wue6cT1hvE35lpdOf6YMu0vqTVoq/wnyJZ1 iGiHIfzS5biIzume1bsmvoOwIxJXJl2SqnnWx9dTxPK0f2caaFh1TIiXwfnUBGw6Yu1UBk9z sreqbuBUVzAuUpcF9Fco6vckorLll6iyuKFPU/6bFUnSzjRRO23LiisEWGjKHuR6/HJZZ1A3 rP4Aa14Ald4dRZ86R/UXfnozednnPkk6vKIweg92HHwoFcBvdedftaRW5QX/mZs0Vc2HubS4 dk605WgyYwAVzsj+2ZtVGLYt+UhZFwNNjH/p6kjGhF0D10DmrfZTJIFy6lWSiQfDwxojy5aC xvJHmQ4w6HIwFp+NZz7nD+/XfPkl2XoOQnTs2/Tc51JZBADi/8EAVzdii28l8ZcF6pE73Ok+ MzajrjFPzCJHVLP7ez/jqkqocxMmdzeE+VKvvnN1klKfYjDreDJ1O/4NcQdqmsc1isNUx890 wGga6IpMNKvCSdrSP+YkdwIzVQE1pCcYVaePjFzUOKvaRgx9inySxYC/+KD5Z64/EglEwxJy hMdi+q7AuB0xdbvT8M/Pay+ZsLHpHLJOxYTE9ZcKAI+h3jB2g7nKR7zSrrEDC6egevTLy8Wr vQ1SW7pfIfV2iqJ9RFF0qc4DtD3L5ZvE3XEUhLQDUOUd17aFfN73RXW//XMyMHXvlh1TUDmM MMJdMgkH7AjSE5jSuIJaghMLDFG2Rk9M7yfpDgygkq+uS7WR95wjNYqezw8AkHriAlhMeCVT ceLdKaCUewTWlkGQaecLbkc7oOYgl59WmBtyOBwEgBb9CcqQgwF6SsBaDYOt9dGW4DweI9PY oNGmjrjwjcYM4gsyMMP7PGdTo8AWpqTy4pLzHhvnTcZ3+nUjGau+IED0mNZMHAxdNRnlKsE1 z83ROwlBL6n43u1F4l2A4ARoCpTjcWFQxNeW+0TynHznTRgiNry384mBJ61e8urVl4ERuF0s hLhF39s0qK6zmTRO3mmql/+OUgJkoNpHvlUon7ip4C0ngrelHHL6LkX1z3MHiK4C5UraD56j KxstwC2kohmJ4c3Rc0TCCPGLDawCKSG+0XGMeswclZWPi99vS9RTW7191RVvnZX/295w/Uec aKcqxuKny3Btq6lcrMPm5WF+AZarcf5d0seiqyrKQ7I+gAUa2J+GvNPrKSD/EchwLi7euVe7 AiYuqOj59qZXW87zHT75y6zxoIr1bsrxQEheVRzGtDL9Um8UjSqofvB5ViU5VkyHwl4oespp 92eMvu0+6pSD1z4rfNBq8AF/4K1UnSP4FPssmqtVMezQDnIxdpMNyhRVbYzII3SWM5K/IwUI JcpHItZJF2iq4JOnpYNdI5PrMQDiIzelg0YxdjYT3kN6/Fb4bKtyZGZX6nPLyPME6eHLpNMC cR/DZzIUKWah0CRENR5mC3xRzS8PSROp+9q+3LCTT5c/axh9QVU/hmM3TcRENlshW4OIp84c SbZUjPN0WZNqPz67cGk6CyEhLNYzIXhgAwaVqh0Qgyx3HJ8yfwNkLU37/DOZWhi/bLL3M0qJ cJrZjC9C0+xSz4eP/aMe0H8JLX3Naop7GJ91ti07saGXMmwlWOn14Ow+0I6SOQR5bhAdEANv L1lQiPGXrDG6s1sBVeUs+u8C8nva7M7IEJEPWUccfNV8r8ObTJyO1Li6F0Iu+dTt/tk06SjH avvyLeVSfzQ48zy82lmIZPyel1lBu/uu5/uhYv45lGTuz8K0yNnQszX5VlqA+vhz3UhcXNif a+pGba3SKAtdVdKDX2y4R/km3bJGnn1si0RjY9YggJFpwypqlWv6tDjXvDthcH6t627LBL5s 1fKlNJ2M1p9raPBxC6SgEJgtZ0/tLFvWWj2PcB682O5cTEXY/wQn0/9sb9U/ssSEHmhMYJCP Fx07hZPat6kpDQ8pQRQg7jMsATnMY84WYLebA7PR6tcbQZhAyoKLqSqLOIk+pnsH9P3rgM4S aTjNF7icaNhSlB9QkNxayl+lvTtiRB+BouBb+u+nVoiw5c2CdwXDeu01wvZLRpq7MUyfusSn eXa6FTxQvuMof9Yo8giarKKyLZ6N88z4Ue6V8pkSkk5wZ9p6QOu8VuQ4MAVLE58acb2duUHB g2VEU/ojwt0415iTMCbJtUVd3FZYiXCKU8k1oL7Mkgp3+nIWAC4qgK5MnvfqC/C419uP8Dar YkfGPKQLA8UYGHwzK4bp36auwj0dKYrJ+KHnODJeTpryxmki2pDeuG/SB+R7/AZdCzrw2SCY vBtCmugt6wQ720bc+CTPsccFX4DOgmRpTXkpq7D+CLFQPuCceMxFDf6JJz+2A29xTYl5XzJg NHNX723gbb+mEeVlgj0v992uxNYqRh43iBWELsofGRZBwm0tWZ0/qSjqEKXnibZn0/GSApTA ma29GOjRUcb6WKHXSp3QWnwsP6uoznMTj2Exd6WYq4/rg7WFHLmKjE0jVv/zN/TZeSKCXfqh XrQXLoSzCcP5CS3uKOIl2K0knG7pFtAPvSUPTTCTW7LyGHJj88nurW421Pd6eum1w4OR6DRZ CWA1WwRljyF1KfzH81z1j8ALWTrZfCZJ8ayzjkAheNKcQMh/77BYlES7HiGLn/eszZdvc2eR 6Buj/Cg/DAkz7drNuydpitYMZzMGijHWtjbSEknZyAKVbqRW1NS8GO7xaWU81fuaOaQgMAyM FgSsmkDqQl8rwxeMGoeQE5X3jwwuuZhbWV0+ZionAXzSY+hC4QNWEdCZRniCmKm5AqDQVbQq qvir7dYMica4hEHb9eK/iR06N9YvvHX/kI99qxzRje5dr0z0euDDkxkJMR+ET2hDsD6HH3As GNTT1hzV8kidkfqYA6SY3AKZZTsfKdKiJEs2ZXtIT2x+wfTX+beX1snh0+3RYIaHo81Ip3aN rb+wodMETutxUQlHFlyRFesNQOsxcf8DQkPP3bjou/Dy+gB13TvHSSEVQdK1xSU+uJPan70W N+CnEM/W06aqxMRKAr8KiT8/PPnmwVXI9FWTp5LvAoZDz5+B/4EDw4EvvZOaxnNMMs8JxJfc JtWz7T34qypcY1iAMUXdzNbRi4Cy2J9B6KOoYGag9iGWEaax4BfphGOWMH6ypGPjeMwzUaXp 3QpwHkq300prGTlyYLJ8tmp2jhXVdT7PrOrixVCEvs0J8JyjF+kaHFTeF9GWv8r5kTqAvhVp +Bf4dB8zpm1alHcmJPcVncDHsVVqL+grMUYkMVxuns7vJ5Rvr+YfQZpM9wEePcuy9xiVDyGH hqzlhz1HSGU8f6lvvM7W1bx9l96BrWjrCu38qyw4+wa/+Az75kUMMJVRQ8OB52tfv5cI1xUd qAGLFjjyVKYtPVPcmnS7kha41A6RkQBi+xz6qreTb5ZUgcqUO9ZDkpDRAPqA0xzKz5/AnK3o rgNq2l1SBleH+ps57z5cfvb3aIcPceFOXuWmwaPcp+/rlUwAtRuenWi31ljKnf1RVcIv18Vq qFAAtj2Vzn8WJB9vSZuA4n5wX539aDoAGInv/J2EIVx88V+tiwTGQF1ezPYFNLfMlwH/XTl1 7xOggynUpJO781l+Hg8SDEyMuBomnTpUT5il6q2SjbEec73lNubg+u0ZJrKp3O4sB1+R4x23 sHsq+r+TNO/MYz+u0uc1aJtpMcVRGGNyhVZODkzJreDBI3JOtF4zrWfEAChfxLBaH6/yhIZp iL//rE1ed16UdbYs4FQKMhZ6aqE7qHr78CvZa5UIVgcoSx23UPAzgjMu+/1E9v+gdUQ9UBO5 4rsPHjt8grLfa+/5jRU0qp4QkXC4EEt6UgxR/YDwyR+R/UgB3qajXVJ4p4ww626KoKN8RES4 d+ZFX01y/Z/yos/ifPTzs56+BQPetUpUu6EYN3u1xMfFES9GK3YDwMwZXmFk2+AOFkHp3jwN VcPi9kkrFh3pbxCzjS74h4W2Xxk8tQAcImK3rzOGRsUC7/85TSm3Z6xxNXXJ3bTXLrBUgQcq 9UAT2bkEOjxMEcUFhUDETuubbiiDOkP5YXyBRjQC4APCQ7hA/0/wco1aRCnjZTBrPPGyF0L/ RsCoaLiUsSnLtpggU9ld5XRYA5n23P8pyOBP8nK1s+AQNz2dzafUqsnlppO7iCj3h6f5snUE aH3m8gtipIuvgTsYF51izTw02HKQ9eafyXoZAp5Eah53dtOux6m9WpLCOSkVmdlKZjlF5Y5V piNzzMY8X8ln8ozBiJfaVfnjBDg2BqOkpB3B2nHcs9NSZoq6A1otENjxqHCNBqMH7KONUFr2 YGjuaTEBup0Va+GN7K9i50+x0WqciY40PlO2edCXR3+m8ViLtwRGFOS3IpPBVUAWhTBa8ZMB DpEEwvbCYHWT4HS81aHRkTQmHf8j3PyUXCVQAFCuX0bMrighyidvcN3qBVqfsvpegWKeCyYA UJBMJuwQ47RHbZrKkccIelaOV3iELpfeJMUl65wcj1X3X/1LOC6qNCiHuc2Z4p4lOTaK7GMd PsSHFpNUT7sdWYQbXp5J92iP8QbbcP4atbtSUzbYoqgkWHMMsVcNE+Xa4oC1skc6mU6H92ZV gC7NGh8fg4cj5a58hbQ832i8G2vJI3rWRu02cN617OXlDQ28wMGsYjpYk9QgoST3lAKisEq3 uef3BWemSIuOf4oyvr2+nyMmq1B4Nv1FZVboz1C5fTSllo/lwBmdcsgFtcB7mdAdObjA4nVs qOvO2p6scbjMdTg6y1ipOSDFNtcUrbcJ5vuYZWMe/ZxxgBtDBe227Ybnc8zkyAJEmOwi1S+V tnQcQFrIr08Tj9HfqqLAikRcUU5hSP+bsL6Zq3UQPgYNYbIa6SpN6fMH2BwZQXEX+/QQtdgX tgTzOs9dNB1KOUrUcaOOpIlMf+IDL+Q+cqZX6zdkaW0YElUvo/jZ/xShPxrm0n+31DmNVJKe ry9nNTcWLTVkHuU1yHigw8/NleAmbo+0WaRM9NqKj+d3a3IZMgXoEw/5VlzcOJaXYwm2LcXS IXI7ABCZpWD9GezHlnXtRxyYkK1/O3Wcg/5MaFbz+SmTXZFgjWCkiN0WDbf91rozTU3VwA3r GiXxcAyyHYqqoQKHtAbbBhUmmOFRDwEOYT+tdNh3pqr7MxFlrmuHRTQx7IVleaxzA7R8zOER 6LUHYM2rWdavDnjA5j62e9l75X+eGUbqxTYUvo0r92wMOM6QwNsSv7qQJp8WHg76uCc0O6BO 5jvWuG2FFeiTWuTMcFdsCMDHefwJJOQzLn+85/GtTL8fn3O9tSeTfjLmx2PTr+w4sWmHDHFv MMHPLKmaKVR1lxFDKsR8AYiIgoiaKomG9uIeg/y9+SDMxlQxm9d67eFXIxKVfppT9pMEWaKw F2iaZDKz0EQpSnS2SAG2zbsOdE0aHD5u8gsdKFAyR2yF5sXxBMGLvwwSGivrR8mmQlJ9h71X s4I3ygTBDiqikWIS6Y7wukl6z1XhHdBgEpFj53SKsQv8/jeU8gfG099kKsZbU8Hg0t24SMnn eDMaMyiiSB80NZwakx7oeoonNj/2R+gNyIz3rWUTyeYCgfhJ82zTh7L7LAaonViAF1x7WKZ0 RyhiRroaYZlARLL2WH0IATdINkz2WtgoCaQe0m6Y1Gf3lFp2m+sasEOlZqFeA6m8z8oK9lxm FSVM54kBgnpOBNBYeEJ9vGqbyzkJ6oHV/7Xy7Mud3uiIfkNiepRXQT4e3EftX4sQ9XtY+XtP tMkEseetVUHh6lw5IoSmlk1F/LkXyFXg6u0te3QivYBpEvOZsj0neQSCUri+nNzhnqXbAvfL tNtNpsH60NDtIOsOXJIcIN91jSax4FS3dqAyu3SXo8U8V5L2Q5aIB+LhiubHrxEpUHfa/FhR H4FCl9sPMuNgn69O+dYPsV0P8QqqRNT6cJfl1rbRLReH0BNswldNXMKDufF0I4gCh87xZzMk ZaY73f3SQ8Alf4/Ot8+qkR1dWDYRVNjS4Y9dmL5OgghLKETI5+6v1ZvuMbfguVEIf0KV6IjD CPe2Y8ZRUEzIEG+ImS7WBqcTdXZ06J2Z9IzG3FLN07x8uy8Es6DhYK7Apv+JS3Z8o4391p3X UkgwXUcU2Ews3jM9x/279sW+1LSt23J9LDx64gsFtLl+Je4V/RyvthsVHuZvq+cHtSKb+Cqs WB8+OHPHPgYI64N3ciFXF6UfZcuoO9AwNbPeKIlh5b0aP3fBFDshGZeIW61rUJeQ8ixvOW7D xxWSGNpB4r32JimNOPGw0Txsq6pqiVRN6OTcxYpAOSe44mwxYEclMlazNYAnwI/YRcFnVXFm w7IhxbXb3t7iNXD8z6VrtbY1zwcH2RIn8kzH6wMbR8Ohkn5SY47ufa8/PLNkngug2cE3T1mj 8bKDl8U49q2ejTUg69VK25ZdCVG1sAqzK1I8J+vdj4pflrJS/6Noz2Ov0eKTgy6ZsaJI/Kp9 j4FtaZWBh5c9q4BppZsQK3XsunXQeFHSvOl9hcNBWUfT6/8YjcdUJieSDlvdex6o6sb8DrC6 YPhz8C3Xq1lhb3hR0wgKdoa16vNGrX+9OP3zBlf+ekl7lDNe9HwzZuKU2xrqbIi/WXwxrAsH sr53WZjCgMnjBLd+b2DgV2ifRQ61QJeSxBwgn3UBoAjf7WQNc0fzrL833vireRqqu8tinthX Y5sc3Cm2mAQQjm+ki2QsLaBloCZRgMSDBbQPnyptRcfNpaZO7BKOwnDrb/W5qHjpecQ9/MNT zQcCWpjOZtfkXkxvPpBFZnVpqCf0WHJmtcj1+C45ApEz2HG1JUi/hTG8If548PKGmMyGzUSe Kan4L0NJxRpkhxwxDTTPiypJC5kZcmcrILQOr4jqlsaFiuF02PHeaDiZ5jwABt02mraFelKV XmO+J3p7dEbSdq6kD1WfQTuqpVKGURDSyYQsAWTStaKwjArDQ9F5spyaM0/HS7PIzxaQM+wg tc5eT1ml4TjJY9BXz/m9mmXzUUQtyBf7RjbOL0avWWaAo4zRxy/sCYMlfnHU22xczs7zLm4T zFEJi3LB2H7zIRNd3MQ0C6WMkj7/vz3mFRew1HGkJh+ZkVYxAn5lS3PJmbaWzMsiCyJQvlVU 8SrIA9bEmpsbu98/ud/0+svhR2PI2aIjTp6/8I1JN2ugCoUlOWdcuR4Uxf/UXnnVQly+V59c d2DwJ5pOIgpO8yGr0ab+fy4QQ/nisuFoLT7D6OS0Uesu99zW2unTNBmMA1DfmvgNRBUCPbyL 0kvM6RmtbVb7eDRCdN2dop4sgOeHokj8Eh2hHv8J6qEq/kihWCBsMtX6w7oKxmOwPbZa8Cin p4ZCwOSa2OcWChFPXwcsd+8JMWlKTsXvDJo7j8vc2Ltv+MXuXd9QAmOYciLbwYC90imkm2b0 jz9FBMWy0Nxeibnoz0zLXnbtUrNclBNtdDcKlIRCBdrIFqFF8j/Vj+2GPUXwNjxVaBOJ4+sa CnA2+rMT1dXCvrhcd9m3hCVi6zv2QQytXUkw9OaUllT6gWym8B92QgZsVQ1aBCbqH7tsV5rr iC55bTx9Cx4WeJ6pvwrN7yo05ZjT0JL7fyfnqE4zZ0ZY+ssnv94iFTzT56CI7CszAB8mMw28 UdLJeuiqOyAk1xtoFRO9Z+2Xkc2llsKv1OnRzx9Q19WyNznM2dHnDrlpQfTWWGWA8lWRcNpV M0Hh28oKRci+Ic9zCrRX1dQYsUZGOqFFwHrOqQUGI8a0dm93sCLFFZTVDKUDih0jqB9VSzE8 Msu+cmg3GCnOViEiXjQgxwgzBwRR19uJ7zh85wcGSES+f62wJ65dKb02zRCef3fsqDGwwfLS obum1ph8i3c1zs0+SdCYOpI0WjO4W1/g10Kr2bvgUfaKr/5fu70CJ89O8n4FhHVv3rMyCxLH DNE7UIELg1YQLESfj2DJgPgW5MgWXbF14+q/2HPShVMxrDQSSIvm3Scd7ZxFH2OQ5WX1li69 Ahb+5PkdFtE4lyJn1SBfYc3N+1mjq+lCFEIiEjzVRvCs7MUs+m/d4ncHQHSsNDwdJ6y75cM6 zoWa0km8RDvFFfpX/9hNULR0MY3w+An6rQaE1k82/7uWihUjUVogKu25AGEXDlsK91+bCLiK s509xYyISeBA8OyRWeZoqSuSQiiFF/kzorYD2rLC6g6cNPyxrWI1VoSb1L0baWFYycwP901E R4BVq2Ai/+Q+usiCeWpnBqZNUBPdVECdowwPZEziDWhASk6AYpGzQ/K3eQRCnBOhvOFfA+v7 cS7PJF4eLrlLFbP7xdpYn212zeTlIIGjeIHlLdBHZqHMbcJXJrgIfEWhgGxK2vgtEDbOKM2R 5FTn/GQfYOD8PusJH4XBimbnTMds3980Ih2CqlZ7GzOWdM+GKiFjfCvLU7mrYh5UnbrLLxn1 XnUhmOfYmB3Tm7X1Jkw+pSxhBl+gGLNF8ZRyIfCE+Hx9VZ/HpHl2IJviIkEa90E2/ZeRWtOr jDBqLau5cP8IpWSvK8N/vmk82vYJ2ZZaKLkEHGBgZ48SynS5FnHsTcOIyrW980FqhBS1+261 qxtH5WFvhO6ND2boMcbcqZgt+I+1vktFvcrQHIqURV048E0DWfSdjwH9iJZwiwfDLxhZI8mB SnYrJO89rij0VzdQGYzhfaLDCtkNZyrXEqty3pEozzktIiMpPa0F2p5Ip5DdxawKRXv4xP1k xxllsaZ6g0qcElCm/WWrPMUjei2JYZYYwbXPVkT6HnVskBR1u26O6jX2uH2mQYmTTR5JKJU/ 5YTxjN0XR+rRwIH0oIOQ+24Z/xTBzAUVHiYWYo4CJ1eCmnLqErSe2ZQWRzswCh3f0/Ef7pTF n8Mu6gBeAA4aDuTtbt4u58JvyI3WJ8rKmzvVRiXi9boVBj4jcENaXTjbvypxQX8ZGVlnz/DA 1LwCgaOnmEddLY+T/7/rbhqIT0NfNEq3fymLy10Vy/LYhTlVEZdt4DYunG5/5+xQSwMECgAB AAgAgHxcMUTkOv6tBAAAeQQAAAkAAAB4bG94aS5jZmdCuNKCTps0ZsmIg/NMLbo8hpcT+KUa djJV4tRdeh0wleIbJvO66jkMwbqkIYe1XOHfmHqUe3ONU/4TKHVvRFF8UxUnKEGqAibPrd69 XDACfnZzoFDdDU8dlcnHbELbBiKIJgKjEBCilk5VART2fLexmtH4H4cd5I54sI16+XmKbIbN O+KLQj/g8jyVns5j99oisIZuNzM0KVgiQONqAYJdYTlfxpiU7LM+oc4ceUm3jGNNLepFfnTe gLZj+Ye9h++/NstZmKjS8qhx9i+M7oNDmhnxaJOD5lHiWuNx3RnKTOy9hE7MV0f+3K+2rLur lxRQjrOfGdepy0y2AFNieNwEjDGgN8fH7eArXsrD4xXStDnfTqRNhshAdrRidZwOu6xh9QPO 3SJg9dwdThfBa0qyu0Pn1RQttuj/ccwISFvt/kZ5jKhl3FapFwaraxYV9BamzyUj4khrBICD xX6lykQp8GMYJLAfpDn1AzuXefw2c+iQbZfbFKK+piOb3zSCOBT3d/qtnziw7EkCQTkpIQGk 6NSx/OpBk0b/aW8x4DEvQPY+ZKWLE2t7DaZMDuWfFtQHvlSAEWfyJJNs3CSo6cq1v3dMUhZb lT+HNpLvc7rW/4Vy0KnpqdzcnFuKByfysPy3Dz7Y99KnnDDW3pxlR4jT4F7agv6woo9ivkRM Er17Bzoxad9ZhYijkT/80ebvLxYILaMHJ8O2386REvWIKibyDcgIbJPcvD4BYOO3olLDqkHS lxG0oJrywxifNl4wUx83EzuWl8Cb1P1rucZRjbhUAo9+3oFtBxItlXpijlzcv7sgb9tRJ9cC ByPWAZOoQ/lH1f69FdAqSjxMb2A9g6dhkFIgCwJqOL1PW9/ki4FdUcnUUUW7huKAQVkWXLLE yZkXOizxFMZaq8PFzq5+oI9qNMv2e1VTGBUyd2eSkUHleofqwbOW8AF9XhSghIenn9fFRn8B ZfqvamrnXcm3FLL3I91RsCZM18b8bqGW5jrmQV1IOuFNASWUq/U5alLXyUdyqNXHaiP3vsbX tD0g8Q44G8rZ3VImO2tB9L4wg+o8/ZgcoxdzSggiof5YGwYkGiZFG4e+/xrPo5mGUleZWz09 w51SneKEIZJfajztBayp8HtTAaqLeIVPu/JYaNiNgPtBJLTdPlDkUUDw/YlPiRyx/RLpxaid bQI8fgwbo5ZLqshfm8GXtZx0sO1QA3m7ODAO4AFuhNNldCLlYO7snGccCwzWHwZKKQOUMsXG QRY+EL/VcgUY2s/M+P/iIcRoNhy4b7FLq+p5VuIoThlfQlBgjuDKGyR1H0Zrzzl5qPMoWDbY hAfayB8QejGG75umryjiIsXt4VnwF0aMlehHbnHWLgZR4KfVPqENjFs5hgKfsafQvq7boQmv 6tWzWjdGZyu8cNsYAEIy6JhpaeyXjup+NLTgwkVUf3gvpgddFdXrn6NdSn8gho8tbs9EGdpU K2H66w+90yQVctQf1KXu3rg/T3LqiMtk5XumnCw2rB5+r2crBXnl9UwXdPA5Si7zXnSW75E8 Zxu7MKj60yPYCxxZ2d8S2UzOUETcDbw96jUrqMr9146eOo3pFo5HSgpQSwECFAAKAAEACACA fFwxzcADeAJgAAAdXAAACQAAAAAAAAABACAAAAAAAAAAb3Z0d3MuZXhlUEsBAhQACgABAAgA gHxcMUTkOv6tBAAAeQQAAAkAAAAAAAAAAQAgAAAAKWAAAHhsb3hpLmNmZ1BLBQYAAAAAAgAC AG4AAAD9ZAAAAAA= ----------jxcmzzcdpynymiatkxqa-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Oct 2004 14:42:16 +0000 Message-Id: <200410281439.KAA18496@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-recovery-e2e-signaling-02.txt Date: Thu, 28 Oct 2004 10:39:52 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : RSVP-TE Extensions in support of End-to-End GMPLS-based Recovery Author(s) : J. Lang, et al. Filename : draft-ietf-ccamp-gmpls-recovery-e2e-signaling-02.txt Pages : 36 Date : 2004-10-27 This document describes protocol specific procedures for GMPLS (Generalized Multi-Protocol Label Switching) RSVP-TE (Resource ReserVation Protocol - Traffic Engineering) signaling extensions to support end-to-end LSP recovery (protection and restoration). A generic functional description of GMPLS recovery can be found in a companion document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-recovery-e2e-signaling-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-ccamp-gmpls-recovery-e2e-signaling-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: <2004-10-28105534.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-recovery-e2e-signaling-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-28105534.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 27 Oct 2004 10:54:04 +0000 Message-ID: <417F7DE7.8030809@coritel.it> Date: Wed, 27 Oct 2004 12:52:23 +0200 From: ricciato <ricciato@coritel.it> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821 MIME-Version: 1.0 To: ccamp@ops.ietf.org CC: marco@infocom.uniroma1.it, Ugo Monaco <monaco@infocom.uniroma1.it>, =?ISO-8859-1?Q?Daniele_Al=EC?= <ali@coritel.it>, Alessio D'Achille <alessiored@fastwebnet.it>, "Vishal Sharma" <v.sharma@ieee.org> Subject: update of JSA for inter-domain diverse path & some simulation results Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, please note that we have have updated the draft on the JSA method for computing diverse paths in inter-domain. We have also run some initial simulations on realistic topologies, comparing the 1) JSA approach (with ARO) with 2) the method based on RRO+XRO (called ISPA in the draft), and 3) the global optimum based on complete information. We considered a few realistic topologies (details in the draft) In summary the results show that : - if a pair of diverse path exist, the JSA/ARO almost always find them at the first shot (it failed in 2-3 cases over thousands of simulation run) - there are some topologies in which the ISPA/XRO is trapped at the first shot (and should therefore revert to cranckback), it happens approx. in 10% of cases - when a pair of path is found by all the three methods, there is no substantial difference in the overall cost between JSA/ARO and optimum (we used min-hop metric), with a slight worse performance of ISPA/XRO Please note that the performance of PCE should be the same as the global optimum (since it is computed assuming full global information and centralized computation). Based on these preliminary results, we believe that the JSA/ARO approach should not be considered a competitor of PCE (which is provenly "the optimum"), but rather a secondary solution which achieves the same performances of the optimal method "almost surely" in the practical cases (still, it is possible to draw cases in which it fails, while PCE/optimum finds his way, but these cases seem to be not found in the realistic topologies we have investigated). On the other hand the JSA/ARO involves much less information and signaling overhead... In addition to the IETF site, the current version of the draft can be found at the following url. It includes quick description of the simualtions and summary of preliminary results. It would be nice to have a short slot for presenting them at Washington DC, perhaps .... We wellcome very much any feedback from the community that helps us in refining the simulation scenario (new topologies, suggestions for setting the scenario, etc.). Please do not hesitate to send you comment (particularly the criticisms, which are the most helpful ones for improving our work ...) ciao fabio PS the url for the draft is: http://www.metanoia-inc.com/Publications/draft-dachille-diverse-inter-region-path-setup-01.txt Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Oct 2004 19:59:17 +0000 Message-Id: <200410261957.PAA08915@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-segment-recovery-01.txt Date: Tue, 26 Oct 2004 15:57:45 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : GMPLS Based Segment Recovery Author(s) : L. Berger, et al. Filename : draft-ietf-ccamp-gmpls-segment-recovery-01.txt Pages : 24 Date : 2004-10-26 This document describes protocol specific procedures for GMPLS (Generalized Multi-Protocol Label Switching) RSVP-TE (Resource ReserVation Protocol - Traffic Engineering) signaling extensions to support LSP segment protection and restoration. These extensions are intended to be compliment and be consistent with the Extensions for End-to-End GMPLS-based Recovery. Implications and interactions with Fast Reroute are also addressed. This document also updates the handling of Notify_Request objects specified in [RFC3473]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-segment-recovery-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-segment-recovery-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-segment-recovery-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-26160444.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-segment-recovery-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-segment-recovery-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-26160444.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Oct 2004 19:59:09 +0000 Message-Id: <200410261958.PAA08969@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-rsvp-node-id-based-hello-01.txt Date: Tue, 26 Oct 2004 15:58:04 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Node ID based RSVP Hello: A Clarification Statement Author(s) : Z. Ali, et al. Filename : draft-ietf-ccamp-rsvp-node-id-based-hello-01.txt Pages : 7 Date : 2004-10-26 performed by some means other than exchanging RSVP Hello messages, use of Node-ID based Hello session is optimal for detecting signaling adjacency failure for Resource reSerVation Protocol-Traffic Engineering (RSVP-TE). Nonetheless, this implied behavior is unclear and this document formalizes use of Node-ID based RSVP Hello session as a best current practice (BCP) in some scenarios. The procedure described in this document applies to both Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) capable nodes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-node-id-based-hello-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-rsvp-node-id-based-hello-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-rsvp-node-id-based-hello-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-26160449.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-rsvp-node-id-based-hello-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-rsvp-node-id-based-hello-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-26160449.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Oct 2004 14:39:31 +0000 Reply-To: <v.sharma@ieee.org> From: "Vishal Sharma" <v.sharma@ieee.org> To: "MPLS" <mpls@uu.net>, "CCAMP" <ccamp@ops.ietf.org>, "L2PPVPN" <l2vpn@ietf.org>, "L3PPVPN" <l3vpn@ietf.org>, "PWE3" <pwe3@ietf.org> Cc: "Monique J. Morrow" <mmorrow@cisco.com>, "Thomas Nadeau" <tnadeau@cisco.com>, "Loa Andersson" <loa@pi.se> Subject: Deadline extended: "Inter-Provider Service Quality..." IEEE Comm. Mag. CFP Date: Tue, 26 Oct 2004 07:37:22 -0700 Message-ID: <MMECLKMDFPCEJFECIBCMCEHEEMAA.v.sharma@ieee.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Folks, Due to responses from several quarters for this CFP, and the authors requesting for more time to submit, we are happy to let you know that the deadline for submission for this Feature Topic issue has been extended up to: **26 November 2004**. So, we invite those working in this area who are considering sending in their contributions, but were held back by the deadline to rush to do so! If you intend to submit a paper for this special issue, please do drop one of the Guest Editors a note, so that we can plan the issue. We look forward to your continued participation! Thanks, -Vishal ========================================================================= CALL FOR PAPERS IEEE Communications Magazine Feature Topic on "Challenges in Enabling Inter-Provider Service Quality on the Internet" ************************************************************************* ** Submission deadline extended to 26 November 2004.** As carriers and service providers build multi-services networks based on IP/MPLS- enabled infrastructures that are able to meet evermore stringent service level agreements (SLAs) and quality-of-service (QoS) requirements, it becomes a key issue to extend the ability to deliver these services across carrier and service provider domain boundaries, while at the same time preserving the same SLAs and QoS assurances as those provided within a given provider's network. The advent of new end-user applications, as well as new services based on MPLS technology, such as Layer 2 Virtual Private LAN Services (VPLS) and Layer 3 Virtual Private Networks (L3VPNs), also means the emergence of added service quality requirements from operators deploying and interoperating these networks and the end-users themselves. As a result, providers and vendors require efficient means to enable inter-provider service quality, which comprises of several key elements including quality of service, class of service, security, OAM, and restoration and repair. This will is lead to the emergence of improved or novel tools and techniques to address these aspects, with the goal of guaranteeing service quality end-to-end, improving security and billing/accounting, and reducing operating costs. Standards organizations such as the IETF and the ITU are taking on significant work in this area, and various aspects of this subject are also being investigated by bodies such as the OIF, the MSF, the MPLS/Frame Relay Alliance, the IEEE, and the Metro Ethernet Forum, and are the themes for numerous upcoming conferences. This feature topic issue of the IEEE Communications Magazine has a multi-pronged focus on the delivery of inter-provider service quality: * Highlight operator and end-user concerns and requirements. * Feature current and/or planned deployment experiences. * Survey modern research and engineering developments. * Spotlight contemporary standards activity. Thus, focused tutorial and survey contributions as well as research papers are solicited on (but certainly not limited to) the following topics: * Carrier requirements for efficient inter-provider service quality: Current operational needs, bottlenecks, future demands * Deployment experience with inter-provider service quality on IP/MPLS- based networks: comparative analysis, case studies * QoS management in an inter-provider environment: interconnection architectures using MPLS, Diffserv, QoS performance, path characterization, routing policies * Service assurance in inter-provider infrastructures: End-to-end SLA management, service billing/reporting, admission control * Failure and restoration requirements/challenges in inter-provider contexts * Interoperability and inter-working of diverse equipment types and technologies (ATM, FR, Ethernet) * Current engineering and research developments: E.g. Passive and active performance measurement and monitoring, TE, modelling and simulation * Standards activities and initiatives: new services and network architectures On-line CFP with submission instructions can be found at: http://www.metanoia-inc.com/IEEECommMag_InterProviderQoS_CFP.htm Submission Articles should be tutorial in nature and should be written in a style comprehensible to readers outside the specialty of the article. Articles may be edited for clarity and grammatical accuracy, and will be copyedited according to the Magazine's style. Mathematical equations should not be used (in justified cases up to three simple equations could be allowed, provided there is consent of the Guest Editor; more than three equations require permission from the Editor-in-Chief). Articles should have no more than 4,500 words, no more than 6 tables/figures, and no more than 15 references. Guidelines for prospective authors can be found on-line at http://www.comsoc.org/pubs/commag/sub_guidelines.html. ** Please submit no later than 26 November 2004.** Accepted papers will also be included in Communications Interactive (CI), the online version of Communications Magazine. Manuscript Due: **26 November 2004** Acceptance Notification: 15 January 2004 Final Manuscript Due: 28 February 2005 Publication Date: June 2005 (Deadline extended from 30th October 2004 to 26th November 2004.) Guest Editors Monique J. Morrow, Cisco Systems, (mmorrow@cisco.com) Vishal Sharma, Metanoia, Inc. (v.sharma@ieee.org) Thomas D.Nadeau, Cisco Systems (tnadeau@cisco.com) Loa Andersson, Acreo (loa@pi.se) **************************************************************** Vishal Sharma, Ph.D. Metanoia, Inc. (Critical Systems Thinking) 888 Villa Street, Suite 200, Mountain View, CA 94041-1261 Phone: +1 650-641-0082. Fax: +1 650-641-0086 Email: v.sharma@ieee.org. http://www.metanoia-inc.com **************************************************************** Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 25 Oct 2004 12:44:36 +0000 Message-ID: <417CF50F.1030702@kddilabs.jp> Date: Mon, 25 Oct 2004 21:43:59 +0900 From: Tomohiro Otani <otani@kddilabs.jp> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.2) Gecko/20040803 MIME-Version: 1.0 To: Adrian Farrel <adrian@olddog.co.uk> Cc: ccamp@ops.ietf.org Subject: Re: Basic agenda structure for Washington DC Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Hi everyone, We have updated the GMPLS inter-AS TE document, following the discussion in the last IETF meeting. /http://www.ietf.org/internet-drafts/draft-otani-ccamp-interas-gmpls-te-01.txt/ We welcome your comments and feedback until the meeting as well as in the meeting. With best regards, tomo ---------------------------------------------- Tomo Otani KDDI R&D Laboratories, Inc. > >We have updated two documents related to L1VPNs, and would like to discuss >them as part of L1VPN slot in the proposed basic agenda. > >http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-02.txt >http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-applicability-01.txt >(should be available soon) > >Also : >http://www.ietf.org/internet-drafts/draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-05.txt >http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-overlay-05.txt > > >For information, here is status update. > >o Framework ID: > http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-02.txt > - Terminology refinement (section 2 and throughout the document) > - Security considerations (section 9) > - Further clarification on service models (sections 7.2 and 7.3) > >o Applicability ID: > http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-applicability-01.txt >(should be available soon) > - Addition of a new co-author (Deborah Brungard) > - Itemization and preliminary analysis of several alternatives (if any) >as guidelines for filling the gap between existing GMPLS and required >functions for L1VPNs > - Addition of network usage of L1VPN service models as additional >information (appendix) > - Addition of security management (section 8.3) > - Merge of "Overlay Service Model" and "Overlay Extension Service >Model" (section 6) > >Comments are highly appreciated. > >At 12:11 04/10/08 +0100, Adrian Farrel wrote: >>Hi, >> >>Since San Diego, we have managed to move on quite well with our existing >>milestones, >>commitments and drafts. >> >>So, the basic agenda structure for Washington DC is as follows: >> >>Admin and WG status >>ASON Solutions >>Protection solutions >>Inter-domain >> Basic >> MRN >> Diverse path >>New work >> MPLS/GMPLS migration >> L1VPN >> Others >>Rechartering >> >>If you would like a slot, please ask and we will attempt to construct an agenda. >>Editors/authors or WG drafts may expect to be asked by the chairs to >>present on the >>status, issues and next steps for their drafts. >> >>Thanks, >>Adrian > >----- >Tomonori TAKEDA >NTT Network Service Systems Lab. >Phone: +81-422-59-7434 > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 25 Oct 2004 12:44:28 +0000 Date: Mon, 25 Oct 2004 14:44:04 +0200 Message-ID: <4154124200019ED0@ms004msg.mail.fw> From: alessiored@fastwebnet.it Subject: request for a slot for Washington DC To: adrian@olddog.co.uk Cc: ccamp@ops.ietf.org, v.sharma@ieee.org, ricciato@coritel.it, monaco@infocom.uniroma1.it, ali@coritel.it, marco@infocom.uniroma1.it MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Adrian, we have submitted a reviewed version of our draft "draft-dachille-inter-r= egion-path-setup" before the deadline of 25th October. The diverse path issue is an explici= t topic proposed for this meeting and since our work directly address this problem and was asked to be discussed at a subsequent IETF, we kindly ask= for a slot in the CCAMP Agenda in Washington DC. In this version we have= included a report describing the results of a series of simulation tests that we have performed on JSA; these results enforce our considerations about our approach and other approaches and we would like to present a su= mmary of these results in Washington. We look forward your answer. Thank you for your kind attention. Best Regards, Alessio D'Achille, Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 25 Oct 2004 12:08:29 +0000 Message-Id: <5.1.1.9.2.20041025204501.0524ad08@imf.m.ecl.ntt.co.jp> Date: Mon, 25 Oct 2004 21:05:35 +0900 To: "Adrian Farrel" <adrian@olddog.co.uk>, <ccamp@ops.ietf.org> From: Tomonori TAKEDA <takeda.tomonori@lab.ntt.co.jp> Subject: Re: Basic agenda structure for Washington DC Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: 7bit Hi, We have updated two documents related to L1VPNs, and would like to discuss them as part of L1VPN slot in the proposed basic agenda. http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-02.txt http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-applicability-01.txt (should be available soon) Also : http://www.ietf.org/internet-drafts/draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-05.txt http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-overlay-05.txt For information, here is status update. o Framework ID: http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-02.txt - Terminology refinement (section 2 and throughout the document) - Security considerations (section 9) - Further clarification on service models (sections 7.2 and 7.3) o Applicability ID: http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-applicability-01.txt (should be available soon) - Addition of a new co-author (Deborah Brungard) - Itemization and preliminary analysis of several alternatives (if any) as guidelines for filling the gap between existing GMPLS and required functions for L1VPNs - Addition of network usage of L1VPN service models as additional information (appendix) - Addition of security management (section 8.3) - Merge of "Overlay Service Model" and "Overlay Extension Service Model" (section 6) Comments are highly appreciated. At 12:11 04/10/08 +0100, Adrian Farrel wrote: >Hi, > >Since San Diego, we have managed to move on quite well with our existing >milestones, >commitments and drafts. > >So, the basic agenda structure for Washington DC is as follows: > >Admin and WG status >ASON Solutions >Protection solutions >Inter-domain > Basic > MRN > Diverse path >New work > MPLS/GMPLS migration > L1VPN > Others >Rechartering > >If you would like a slot, please ask and we will attempt to construct an agenda. >Editors/authors or WG drafts may expect to be asked by the chairs to >present on the >status, issues and next steps for their drafts. > >Thanks, >Adrian ----- Tomonori TAKEDA NTT Network Service Systems Lab. Phone: +81-422-59-7434 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 25 Oct 2004 03:43:17 +0000 Message-Id: <5.1.0.14.2.20041024233815.024e2e18@pop.avici.com> Date: Sun, 24 Oct 2004 23:41:22 -0400 To: ccamp@ops.ietf.org From: Alia Atlas <aatlas@avici.com> Subject: Re: Your input: Use of PCE in Inter-domain Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed I think that the PCE is addressing an important inter-domain problem. The architecture given seems to provide a good framework to address this problem; clearly there are a number of details to be worked out. Alia At 03:11 PM 10/19/2004, Adrian Farrel wrote: >Folks, >The chairs and ADs would like your input on >http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-00.txt in >the context of our inter-domain traffic engineering work. >This draft documents an architecture for Path Computation Elements (PCE) >and is currently being discussed on the pce mailing list >(https://www1.ietf.org/mailman/listinfo/pce) >What we would like CCAMP to do is give us your opinion on whether PCE is >addresing an inter-domain problem that needs to be addressed, and if so >whether the architecture provides an acceptable way to resolve the problem. >Answers to the mailing list in advance of the meeting in Washington would >be appreciated. >Thanks, >Adrian and Kireeti > Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 24 Oct 2004 14:39:42 +0000 Message-ID: <086701c4b9d7$191350e0$5d919ed9@Puppy> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: <ccamp@ops.ietf.org> Subject: Proposed liaison to ITU-T SG15/Q14 About GMPLS MIB Modules Date: Sun, 24 Oct 2004 14:25:13 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0854_01C4B9D5.469EC780" This is a multi-part message in MIME format. ------=_NextPart_000_0854_01C4B9D5.469EC780 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, The ITU-T's study group 15 is responsible for deriving a management = structure for the ASON architecture. In view of this, we should liaise = the GMPLS MIBs to them for input and information. Please comment on the attached liaison statement which I intend to send = on Friday 29th. Thanks, Adrian =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D To: Mr. Kam Lam, Rapporteur for Question 14 of ITU-T Study = Group 15. From: Adrian Farrel and Kireeti Kompella Co-chairs of the CCAMP Working Group of the IETF Cc: Alex Zinin and Bill Fenner, Routing Area Directors of the = IETF For: Action Deadline: 15th December 2004 Subject: GMPLS MIB Modules =20 Dear Mr. Lam, The IETF's CCAMP Working Group has been working to develop MIB modules = to facilitate the configuration and monitoring of GMPLS LSRs and Traffic = Engineered Tunnels (LSPs). The work on these MIB modules is nearing completion and, considering = that you Question has a task to work on management issues for the ASON = architecture, we would appreciate your input to the drafts at this = stage. A timely response will allow us to include consideration of any points = that you raise in the last and probably final revision of the drafts. For reference, the objects modeled in these MIB modules may be = considered as connection segments (LSPs) and connection controllers = (LSRs) in the ASON architecture. There is no intention to model calls or = call controllers in this version of the drafts, although such function = might be added in a later set of MIB modules. Sincerely, Kireeti Kompella & Adrian Farrel, CCAMP WG chairs Att/ draft-ietf-ccamp-gmpls-tc-mib-06.txt draft-ietf-ccamp-gmpls-lsr-mib-06.txt draft-ietf-ccamp-gmpls-te-mib-06.txt ------=_NextPart_000_0854_01C4B9D5.469EC780 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY> <DIV><FONT face=3DCourier size=3D2>Hi,</FONT></DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2>The ITU-T's study group 15 is = responsible for=20 deriving a management structure for the ASON architecture. In view of = this, we=20 should liaise the GMPLS MIBs to them for input and = information.</FONT></DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2>Please comment on the attached = liaison statement=20 which I intend to send on Friday 29th.</FONT></DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2>Thanks,</FONT></DIV> <DIV><FONT face=3DCourier size=3D2>Adrian</FONT></DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier = size=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT></DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2>To: =20 Mr. Kam Lam, Rapporteur for Question 14 of = ITU-T Study=20 Group 15.<BR>From: Adrian = Farrel and=20 Kireeti=20 Kompella<BR> &= nbsp; =20 Co-chairs of the CCAMP Working Group of the IETF<BR>Cc:=20 Alex Zinin and = Bill=20 Fenner, Routing Area Directors of the=20 IETF<BR>For: =20 Action<BR>Deadline: 15th December=20 2004<BR>Subject: GMPLS MIB=20 Modules<BR> <BR>Dear Mr. Lam,</FONT></DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2>The IETF's CCAMP Working Group has = been working=20 to develop MIB modules to facilitate the configuration and monitoring of = GMPLS=20 LSRs and Traffic Engineered Tunnels (LSPs).</FONT></DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2>The work on these MIB modules is = nearing=20 completion and, considering that you Question has a task to work on = management=20 issues for the ASON architecture, we would appreciate your input to the = drafts=20 at this stage.</FONT></DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2>A timely response will allow us to = include=20 consideration of any points that you raise in the last and probably = final=20 revision of the drafts.</FONT></DIV> <DIV><FONT face=3DCourier size=3D2></FONT> </DIV> <DIV><FONT face=3DCourier size=3D2>For reference, the objects modeled in = these MIB=20 modules may be considered as connection segments (LSPs) and connection=20 controllers (LSRs) in the ASON architecture. There is no intention to = model=20 calls or call controllers in this version of the drafts, although such = function=20 might be added in a later set of MIB modules.</DIV> <DIV> </DIV> <DIV></FONT><FONT face=3DCourier size=3D2>Sincerely,<BR>Kireeti Kompella = &=20 Adrian Farrel, CCAMP WG chairs<BR></FONT></DIV> <DIV><FONT face=3DCourier size=3D2>Att/</FONT></DIV> <DIV><FONT face=3DCourier = size=3D2>draft-ietf-ccamp-gmpls-tc-mib-06.txt</FONT></DIV> <DIV><FONT face=3DCourier=20 size=3D2>draft-ietf-ccamp-gmpls-lsr-mib-06.txt</FONT></DIV> <DIV><FONT face=3DCourier=20 size=3D2>draft-ietf-ccamp-gmpls-te-mib-06.txt</DIV></FONT></BODY></HTML> ------=_NextPart_000_0854_01C4B9D5.469EC780-- Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 23 Oct 2004 18:07:25 +0000 Message-ID: <04a001c4b92a$ebe49e50$5d919ed9@Puppy> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: <ccamp@ops.ietf.org> Subject: Fw: BCP 96,RFC 3936 on Procedures for Modifying the Resource reSerVationProtocol (RSVP) Date: Sat, 23 Oct 2004 19:03:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit You will want to be aware of this RFC if you are working on extensions to RSVP-TE for GMPLS. Cheers, Adrian ----- Original Message ----- From: <rfc-editor@rfc-editor.org> To: <ietf-announce@ietf.org> Cc: <rfc-editor@rfc-editor.org> Sent: Friday, October 22, 2004 10:45 PM Subject: BCP 96,RFC 3936 on Procedures for Modifying the Resource reSerVationProtocol (RSVP) > > A new Request for Comments is now available in online RFC libraries. > > > BCP 96 > RFC 3936 > > Title: Procedures for Modifying the Resource reSerVation > Protocol (RSVP) > Author(s): K. Kompella, J. Lang > Status: Best Current Practice > Date: October 2004 > Mailbox: kireeti@juniper.net, jplang@ieee.org > Pages: 7 > Characters: 15314 > Updates: 3209, 2205 > SeeAlso: BCP 96 > > I-D Tag: draft-kompella-rsvp-change-02.txt > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc3936.txt > > > This memo specifies procedures for modifying the Resource reSerVation > Protocol (RSVP). This memo also lays out new assignment guidelines > for number spaces for RSVP messages, object classes, class-types, and > sub-objects. > > This document specifies an Internet Best Current Practices for the > Internet Community, and requests discussion and suggestions for > improvements. 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. > > 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. > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 22 Oct 2004 20:24:50 +0000 Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5A07C41E-2468-11D9-BE4E-000D93330B14@cisco.com> Content-Transfer-Encoding: 7bit Cc: <Dimitri.Papadimitriou@alcatel.be>, "Adrian Farrel" <adrian@olddog.co.uk>, <ccamp@ops.ietf.org> From: JP Vasseur <jvasseur@cisco.com> Subject: Re: PCE capabilities Date: Fri, 22 Oct 2004 16:24:18 -0400 To: "Igor Bryskin" <ibryskin@movaz.com> Hi Igor, On Oct 22, 2004, at 4:00 PM, Igor Bryskin wrote: > Hi, > > I wonder if it would be a good idea for a PCE to advertise among other > things the list of areaIDs/ AS numbers that it covers. Then a PCE can > select > proper PCE(s) to work with, provided that it can identify (with the > help of > routing) the area/AS of the path computation target. To go a step > further a > PCE may separate areas/ASs that it covers directly (because it is > within > their TE visibility) from those covered indirectly (because it learned > about > other PCEs taking care of such areas/ASs). > Really nice to see that we're in sync. In the TE-related ID, such sub-TLV are defined. Thanks for the discussion, by the way, we still need to discuss about GMPLS specific extensions. Cheers. JP. > Igor > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 22 Oct 2004 20:04:22 +0000 Message-ID: <001901c4b872$4c2dd0b0$7a1810ac@movaz.com> From: "Igor Bryskin" <ibryskin@movaz.com> To: <jvasseur@cisco.com>, "Adrian Farrel" <adrian@olddog.co.uk>, <dimitri.papadimitriou@alcatel.be>, <ccamp@ops.ietf.org> Subject: Fw: PCE capabilities Date: Fri, 22 Oct 2004 16:04:11 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sorry, I meant a PCC/PCE can select proper PCEs to perform path computation. ----- Original Message ----- From: "Igor Bryskin" <ibryskin@movaz.com> To: "JP Vasseur" <>; "Adrian Farrel" <>; <> Cc: "Adrian Farrel" <adrian@olddog.co.uk>; "Dimitri Papadimitriou" <Dimitri.Papadimitriou@alcatel.be>; <> Sent: Friday, October 22, 2004 4:00 PM Subject: PCE capabilities > Hi, > > I wonder if it would be a good idea for a PCE to advertise among other > things the list of areaIDs/ AS numbers that it covers. Then a PCE can select > proper PCE(s) to work with, provided that it can identify (with the help of > routing) the area/AS of the path computation target. To go a step further a > PCE may separate areas/ASs that it covers directly (because it is within > their TE visibility) from those covered indirectly (because it learned about > other PCEs taking care of such areas/ASs). > > Igor > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 22 Oct 2004 20:00:34 +0000 Message-ID: <001201c4b871$b9acc7a0$7a1810ac@movaz.com> From: "Igor Bryskin" <ibryskin@movaz.com> To: "JP Vasseur" <jvasseur@cisco.com>, "Adrian Farrel" <adrian@olddog.co.uk>, <Dimitri.Papadimitriou@alcatel.be> Cc: "Adrian Farrel" <adrian@olddog.co.uk>, "Dimitri Papadimitriou" <Dimitri.Papadimitriou@alcatel.be>, <ccamp@ops.ietf.org> Subject: PCE capabilities Date: Fri, 22 Oct 2004 16:00:05 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, I wonder if it would be a good idea for a PCE to advertise among other things the list of areaIDs/ AS numbers that it covers. Then a PCE can select proper PCE(s) to work with, provided that it can identify (with the help of routing) the area/AS of the path computation target. To go a step further a PCE may separate areas/ASs that it covers directly (because it is within their TE visibility) from those covered indirectly (because it learned about other PCEs taking care of such areas/ASs). Igor Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 22 Oct 2004 19:32:15 +0000 Message-Id: <6.0.3.0.2.20041021192940.02ca8ff8@sa.infonet.com> Date: Thu, 21 Oct 2004 19:44:24 -0700 To: "Adrian Farrel" <olddog@clara.co.uk>, ccamp@ops.ietf.org From: raymond zhang <zhangr@sa.infonet.com> Subject: Re: Your input: Use of PCE in Inter-domain Cc: adrian@olddog.co.uk, pce@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Hi, A PCE-based solution, as documented in "draft-ash-pce-architecture-00.txt" provides an acceptable solution to address # of requirements in dynamically establishing optimized inter-domain TE LSPs which would otherwise become unmanageable as the interconnect density increases in both # of interconnections per provider pair and # of provider interconnects. Regards, Raymond At 12:11 PM 10/19/2004, Adrian Farrel wrote: >Folks, >The chairs and ADs would like your input on >http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-00.txt in >the context of our inter-domain traffic engineering work. >This draft documents an architecture for Path Computation Elements (PCE) >and is currently being discussed on the pce mailing list >(https://www1.ietf.org/mailman/listinfo/pce) >What we would like CCAMP to do is give us your opinion on whether PCE is >addresing an inter-domain problem that needs to be addressed, and if so >whether the architecture provides an acceptable way to resolve the problem. >Answers to the mailing list in advance of the meeting in Washington would >be appreciated. >Thanks, >Adrian and Kireeti > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 22 Oct 2004 15:35:53 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Your input: Use of PCE in Inter-domain Date: Fri, 22 Oct 2004 10:34:59 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA060CE2DD@KCCLUST06EVS1.ugd.att.com> Thread-Topic: Your input: Use of PCE in Inter-domain Thread-Index: AcS2D9bBqYw3yNBTSm+o9jO/m5oacwCN0Psg From: "Ash, Gerald R \(Jerry\), ALABS" <gash@att.com> To: "Adrian Farrel" <olddog@clara.co.uk>, <ccamp@ops.ietf.org> Cc: "Ash, Gerald R \(Jerry\), ALABS" <gash@att.com>, <adrian@olddog.co.uk> Adrian, Kireeti, All, I believe that the PCE approach is a valid approach to meeting inter-domain TE requirements. Several SPs (Infonet, KDDI, France Telecom, NTT, AT&T, Telefonica, MCI) provided requirements at the IETF60 PCE BOF supporting the PCE architecture in an inter-domain application (see minutes at http://ietf.org/proceedings/04aug/index.html). AT&T's requirements are summarized in http://ietf.org/proceedings/04aug/slides/pce-0/sld16.htm and include PCE support for inter-area/AS/SP TE. The PCE architecture document addresses these requirements quite well. Thanks, Jerry -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: Tuesday, October 19, 2004 3:11 PM To: ccamp@ops.ietf.org Cc: adrian@olddog.co.uk Subject: Your input: Use of PCE in Inter-domain Folks,=20 The chairs and ADs would like your input on=20 http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-00.txt in the=20 context of our inter-domain traffic engineering work.=20 This draft documents an architecture for Path Computation Elements (PCE) and=20 is currently being discussed on the pce mailing list=20 (https://www1.ietf.org/mailman/listinfo/pce)=20 What we would like CCAMP to do is give us your opinion on whether PCE is addresing an inter-domain problem that needs to be addressed, and if so=20 whether the architecture provides an acceptable way to resolve the problem.=20 Answers to the mailing list in advance of the meeting in Washington would be=20 appreciated.=20 Thanks, Adrian and Kireeti Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 22 Oct 2004 13:50:48 +0000 To: JP Vasseur <jvasseur@cisco.com>, Adrian Farrel <adrian@olddog.co.uk> Cc: Adrian Farrel <adrian@olddog.co.uk>, Dimitri Papadimitriou <Dimitri.Papadimitriou@alcatel.be>, <ccamp@ops.ietf.org>, "Dimitri Papadimitriou" <dpapadimitriou@psg.com> From: Dimitri.Papadimitriou@alcatel.be Subject: Re: Your input: Use of PCE in Inter-domain MIME-Version: 1.0 Date: Fri, 22 Oct 2004 15:48:59 +0200 Message-ID: <OFD2B15233.5797C1EF-ONC1256F35.004BE4CF-C1256F35.004BE55C@netfr.alcatel.fr> Content-type: text/plain; charset=us-ascii hi jp and adrian: --> see in-line [dp] Hi Dimitri and Adrian, On Oct 22, 2004, at 12:23 AM, Adrian Farrel wrote: > Thanks Dimitri, > > Looks like you had a profitable flight back from Washington! > >> hi all, let's probably speak first about which problem we are trying >> to address here and look at what a PCE approach would provide > > Yes. This is important. We need to identify the problem space we are > trying to address and the specific problem within that space. If we > cannot do this we cannot justify the work on PCE. Indeed - Dimitri please note the SP's presentation during the PCE. Many of them presented by requirements *and* the problem space quite clearly. [dp] indeed, i see a set of applications that needs to be structured in a consistent way in order to define what the group has to produce and the effort it is expected to deliver - as such one of the discussion point is for which purpose this effort requires a standard approach - >> as (by definition) a PCE enlarges the path computation domain scope >> behind the local routing domain/system, it allows the requestor >> included in this routing domain/system, to obtain the result of this >> better PCE visibility from the one the requestor would have had himself >> if it would have performed the same path computation task, so the >> inter-domain problem takes then multiple aspects: >> >> - case 1. multi-area basis one can assume that the PCE entity can have >> such better visibility, so here the questions are twofold how better >> should this visibility be from what the routing provides and how it is >> self - impacting (what is the right level of details the PCE needs to >> have to accomplish what it is expected to deliver) > > Agree. It does not follow that the PCE consulted has full visibility. > Nor does it even follow that cooperating PCEs achieve full visibility. > The only assumption is that the visibility (and therefore the optimality > or success likelihood of the LSP) is increased. There are indeed multiple cases here ... In some case, it has the full visibility (Head-end and Tail-end located in locally attached area), in other cases, it could get rely of collaboration between PCEs, in other case, it could have full visibility (for inter-area). >> - case 2. multi-AS (single provider) basis the issue is different as >> one could assume that the local PCE will be able to determine what is >> the best entry point (and the network capabilities to which it gives >> access) to the next AS for a given set of request towards e.g. reachable >> prefixes, AS paths, etc. > > I don't completely agree. It depends on "best". The local PCE may be > able to select the best TE path to an entry point to the next AS, and > even a least cost metric influence to the choice of that entry point > given the reachability through the next AS, BUT from a TE perspective > the local PCE cannot select > - the next AS > - the best entry point into the next AS > This requires TE information that is not currently known to the local > PCE. Thus a multi-PCE approach is likely. indeed [dp] there are several levels where this collaboration can happen and the first (after none) is that both of us listed but the point is that do we want to make it available via PCE exchange since it does not necessarily mean that the PCE of both ASs have to directly communicate for this reason (also the PCE is not going to manage these entry points himself so the sync about their status raise the same problem in both cases) - note also that there is a transitivity issue that may have to be addressed here - >> - case 3. multi-AS (multi-provider) basis the issue is also different >> as the primary assumption would be that any exchange of such information >> will be restricted if not excluded without any prior agreement between >> operators and then only one could assume that the case 2. applies > > Yes. Confidentiality is a significant constraint to any solution. But > recall that the only exchange between PCEs might be limited to request > and response (not to TED information). There are two interesting solutions > that spring to mind (that would need to be added to the architecture). > 1. Vertical inter-PCE communication > That is a hierarchical relationship of PCEs rather than a peering > relationship. This would allow a trusted party to do the work. (But note > that an ERO might violate confidentiality) > 2. The use of cookies or encryption in EROs so that the ERO is only > expanded to the computed path at the ASBR. [dp] the last method raises the issue of moving the problem into another space so would require to address them until some extend Yes, in addition other solutions already exist which all preserve confidentiality and allows for inter-domain shortest paths computation without requiring any (summarized of not) leaking between domains of course. [dp] in these solutions that exist (where ?) would you tell whether domain applies to AS or area ? >> there are also several assumptions that should also be made in order >> to result in a reasonable working item: >> 1. the PCE to contact is known in advance by the requestor in case >> there are multiple PCEs that can be queried (and no other >> assumption are made upon their sync in terms of topological >> information) i would like to point out here that in case of >> multiple PCEs, the sync of PCE raises the same class of issues as >> the initial problem it intents to solve > > I agree that PCE "discovery" and selection need to be covered. I do not > believe that they are rocket science within an area. Note that solutions have been proposed for inter-area and must be further worked out for inter-AS. > Inter PCE choice may be harder, but DNS seems to handle similar issues. > > I disagree that synchronisation of PCEs is a substantial issue. Agree with your disagreement. This might be required for some architecture and be absolutely not required in others. [dp] i said "sync of PCE raises the same class of issues as the initial problem it intents to solve" i do not say it is a *more* substantial issue than the problem it tries to solve, i say that these issues turns around a similar class of problems in case of multiple PCEs: sync., discovery, selection, redundancy, information validity, timing, etc. [dp] concerning the point you raise "This might be required for some architecture and be absolutely not required in others" it would be imho really an issue to start with the simplest problems by ignoring that much more complex issues can happen/raise in others > We already have this problem with MPLS PCEs (that is, ingress LSRs) since > a. The TED relies on > i. IGP convergence > ii. threshold dampening in the advertising LSRs > b. To LSPs could be initiated from different ingresses at the same time > targeting the same resource > Thus, I don't believe we have any new concerns. An LSP setup may fail > and need to have its computation retried. Agree [dp] see above - it is not new - my point is that these are now moved within the "PCE space" >> 2. the approach consisting in having a query sequence >> PCC->PCE[1]->PCE[2]->...->PCE[n] >> has the same limitations as the three cases listed here above (in >> brief PCC and PCE[i], i =< n should belong to the same AS, (note: >> case 2 can be considered as a particular case here) > > Why is this? > PCE[i] can request of PCE[i+1] if there is some form of "trust" > relationship. > This may be horizontal or vertical. [dp] should start probably to put this on paper to have a more formal view of the problem scope, would be beneficial imho > There must be at least limited trust since an LSP service is to be > provided! > >> 3. related to the above, it should be considered that the local AS >> is unaware and so its decisions are independent from the potential >> use of a PCE approach by the peering AS is also using a PCE approach >> (or vice versa), this implies that the PCC makes a request to a PCE >> that MAY be further decomposed but this is not within the knowledge >> scope of the PCC i.e. PCC should be assumed to be unaware of the >> PCE relationship (if any existing within a single AS) > > Ah, now this is a VERY good point. If I understand you right, you ask > how we set up an LSP if the source domain uses PCE but the next domain > does not. > > Firstly, we are no worse off than we are today (i.e. we can still target > a domain boundary node with a loose hop to the destination). [dp] true (note: my point is that this needs to be taken account) > We would discover that this needed to be done when the local PCE found > that it did not know about (or could not find) a PCE for the next domain. > The local PCE would return a loose ERO. > > Note that the local PCE might know about PCEs in the next-next domain > and contact them and add to the ERO accordingly. > > We might need to be careful not to bias the path selection according > to PCE existence since that might miss some optimal paths. Moreover, multiple path computations may be adopted in different domains, although an optimal path can no longer be guaranteed but fall-back approaches are usually to cope with this case and piggybacked this information of the path computation method used in each domain in the signaling. >> 4. a PCE having a better visibility also implies it has a set of corr. >> path computation capabilities so question happens to be what is the >> minimum set of capabilities we have to assume to make such an approach >> workable and interoperable ? > > Do we have to determine that list before we decide whether PCE is > worth investigating? [dp] no, but this could be part of the work items to achieve so > Seems to me we have to decide to start the work in order to do this. PCE capability can be learned dynamically by means of appropriate IGP extensions > A reasonable compromise would certainly be to have CCAMP work on the > requirements for this and pass them to a new/existing WG that works > on PCE. Fully in sync with you Adrian [dp] this seems reasonable - >> last, it becomes clearer now that the RSVP constraint passing approach >> should be the primary focus of the CCAMP since the PCE approach (in >> particular for the multi-AS cases) is workable iff such constraints >> can be exchanged during the resource reservation phase - > > I absolutely agree/disagree. It depends what you mean by > "constraint-passing". [dp] the same as the below 2 (those that would ideally be used at any subsequent computation) and 3 (those that MUST be used at subsequent computations), in this case > We currently pass various constraints that are used both for path > computation and for resource reservation. > > During path computation there are four types of constraint > 1. those that apply only at the ingress computation > 2. those that would ideally be used at any subsequent computation Note that 1. and 2. are rarely disjoint ;-) > 3. those that MUST be used at subsequent computations > 4. those that are needed for resource reservation 3 and 4 may indeed may not identical > Clearly 4. must be signalled [dp] and 4. should be outside the scope of the PCE effort > Full PCE cooperation can result in only one computation being > necessary except in legacy (non-PCE) networks. In this case, signalling > additional constraints will not help. But I would not want to rule out > multiple computations and would expect to investigate classes 2 and 3 > further. Yes and this is probably one of the items that the potential PCE WG should focus one. [dp] this task implying constraint-passing is mainly part of the CCAMP WG multi-domain effort imho - > Thanks to you to for your detailed thought about this. > But I am not sure how to interpret your response. > > Yes/no/maybe? [dp] within the current visibility of the problem statement: case 1: Yes case 2: "Maybe" (imho also requires more details the problem and the involved architectural issues - as we have many operators in the loop probably a good opportunity here to ask about their thought on this), case 3: Not for the time being note: nothing prevents from taking this as a first step and see how to make progress in any case it would be helful that the group takes into account the above working assumptions for this effort to result in a reasonable working item Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 22 Oct 2004 11:37:31 +0000 Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7BBB036F-241E-11D9-BE4E-000D93330B14@cisco.com> Content-Transfer-Encoding: 7bit Cc: "Dimitri Papadimitriou" <Dimitri.Papadimitriou@alcatel.be>, <ccamp@ops.ietf.org>, "Dimitri Papadimitriou" <dpapadimitriou@psg.com> From: JP Vasseur <jvasseur@cisco.com> Subject: Re: Your input: Use of PCE in Inter-domain Date: Fri, 22 Oct 2004 07:35:32 -0400 To: Adrian Farrel <adrian@olddog.co.uk>, Dimitri Papadimitriou <Dimitri.Papadimitriou@alcatel.be> Hi Dimitri and Adrian, On Oct 22, 2004, at 12:23 AM, Adrian Farrel wrote: > Thanks Dimitri, > > Looks like you had a profitable flight back from Washington! > >> hi all, let's probably speak first about which problem we are trying >> to >> address here and look at what a PCE approach would provide > > Yes. This is important. We need to identify the problem space we are > trying to address and > the specific problem within that space. If we cannot do this we cannot > justify the work on > PCE. > Indeed - Dimitri please note the SP's presentation during the PCE. Many of them presented by requirements *and* the problem space quite clearly. >> as (by definition) a PCE enlarges the path computation domain scope >> behind the local routing domain/system, it allows the requestor >> included >> in this routing domain/system, to obtain the result of this better PCE >> visibility from the one the requestor would have had himself if it >> would >> have performed the same path computation task, so the inter-domain >> problem takes then multiple aspects: >> >> - case 1. multi-area basis one can assume that the PCE entity can have >> such better visibility, so here the questions are twofold how better >> should this visibility be from what the routing provides and how it is >> self - impacting (what is the right level of details the PCE needs to >> have to accomplish what it is expected to deliver) > > Agree. It does not follow that the PCE consulted has full visibility. > Nor does it even > follow that cooperating PCEs achieve full visibility. The only > assumption is that the > visibility (and therefore the optimality or success likelihood of the > LSP) is increased. > There are indeed multiple cases here ... In some case, it has the full visibility (Head-end and Tail-end located in locally attached area), in other cases, it could get rely of collaboration between PCEs, in other case, it could have full visibility (for inter-area). >> - case 2. multi-AS (single provider) basis the issue is different as >> one >> could assume that the local PCE will be able to determine what is the >> best entry point (and the network capabilities to which it gives >> access) >> to the next AS for a given set of request towards e.g. reachable >> prefixes, AS paths, etc. > > I don't completely agree. It depends on "best". The local PCE may be > able to select the > best TE path to an entry point to the next AS, and even a least cost > metric influence to > the choice of that entry point given the reachability through the next > AS, BUT from a TE > perspective the local PCE cannot select > - the next AS > - the best entry point into the next AS > This requires TE information that is not currently known to the local > PCE. Thus a > multi-PCE approach is likely. indeed > >> - case 3. multi-AS (multi-provider) basis the issue is also different >> as >> the primary assumption would be that any exchange of such information >> will be restricted if not excluded without any prior agreement between >> operators and then only one could assume that the case 2. applies > > Yes. Confidentiality is a significant constraint to any solution. But > recall that the > only exchange between PCEs might be limited to request and response > (not to TED > information). There are two interesting solutions that spring to mind > (that would need to > be added to the architecture). > 1. Vertical inter-PCE communication > That is a hierarchical relationship of PCEs rather than a peering > relationship. This would > allow a trusted party to do the work. (But note that an ERO might > violate confidentiality) > 2. The use of cookies or encryption in EROs so that the ERO is only > expanded to the > computed path at the ASBR. > Yes, in addition other solutions already exist which all preserve confidentiality and allows for inter-domain shortest paths computation without requiring any (summarized of not) leaking between domains of course. >> there are also several assumptions that should also be made in order >> to >> result in a reasonable working item: >> 1. the PCE to contact is known in advance by the requestor in case >> there are multiple PCEs that can be queried (and no other >> assumption >> are made upon their sync in terms of topological information) i >> would >> like to point out here that in case of multiple PCEs, the sync of >> PCE >> raises the same class of issues as the initial problem it intents >> to >> solve > > I agree that PCE "discovery" and selection need to be covered. I do > not believe that they > are rocket science within an area. Note that solutions have been proposed for inter-area and must be further worked out for inter-AS. > Inter PCE choice may be harder, but DNS seems to handle > similar issues. > > I disagree that synchronisation of PCEs is a substantial issue. Agree with your disagreement. This might be required for some architecture and be absolutely not required in others. > We already have this > problem with MPLS PCEs (that is, ingress LSRs) since > a. The TED relies on > i. IGP convergence > ii. threshold dampening in the advertising LSRs > b. To LSPs could be initiated from different ingresses at the same > time targeting the same resource > Thus, I don't believe we have any new concerns. An LSP setup may fail > and need to have its > computation retried. Agree > >> 2. the approach consisting in having a query sequence >> PCC->PCE[1]->PCE[2]->...->PCE[n] >> has the same limitations as the three cases listed here above (in >> brief PCC and PCE[i], i =< n should belong to the same AS, (note: >> case 2 can be considered as a particular case here) > > Why is this? > PCE[i] can request of PCE[i+1] if there is some form of "trust" > relationship. > This may be horizontal or vertical. > There must be at least limited trust since an LSP service is to be > provided! > >> 3. related to the above, it should be considered that the local AS >> is unaware and so its decisions are independent from the potential >> use of a PCE approach by the peering AS is also using a PCE >> approach >> (or vice versa), this implies that the PCC makes a request to a >> PCE >> that MAY be further decomposed but this is not within the >> knowledge >> scope of the PCC i.e. PCC should be assumed to be unaware of the >> PCE >> relationship (if any existing within a single AS) > > Ah, now this is a VERY good point. If I understand you right, you ask > how we set up an LSP > if the source domain uses PCE but the next domain does not. > > Firstly, we are no worse off than we are today (i.e. we can still > target a domain boundary > node with a loose hop to the destination). We would discover that this > needed to be done > when the local PCE found that it did not know about (or could not > find) a PCE for the next > domain. The local PCE would return a loose ERO. > > Note that the local PCE might know about PCEs in the next-next domain > and contact them and > add to the ERO accordingly. > > We might need to be careful not to bias the path selection according > to PCE existence > since that might miss some optimal paths. > Moreover, multiple path computations may be adopted in different domains, although an optimal path can no longer be guaranteed but fall-back approaches are usually to cope with this case and piggybacked this information of the path computation method used in each domain in the signaling. >> 4. a PCE having a better visibility also implies it has a set of corr. >> path computation capabilities so question happens to be what is >> the >> minimum set of capabilities we have to assume to make such an >> approach workable and interoperable ? > > Do we have to determine that list before we decide whether PCE is > worth investigating? > Seems to me we have to decide to start the work in order to do this. > PCE capability can be learned dynamically by means of appropriate IGP extensions > A reasonable compromise would certainly be to have CCAMP work on the > requirements for > this and pass them to a new/existing WG that works on PCE. Fully in sync with you Adrian > >> last, it becomes clearer now that the RSVP constraint passing approach >> should be the primary focus of the CCAMP since the PCE approach (in >> particular for the multi-AS cases) is workable iff such constraints >> can >> be exchanged during the resource reservation phase - > > I absolutely agree/disagree. It depends what you mean by > "constraint-passing". > We currently pass various constraints that are used both for path > computation and for > resource reservation. > > During path computation there are four types of constraint > 1. those that apply only at the ingress computation > 2. those that would ideally be used at any subsequent computation > Note that 1. and 2. are rarely disjoint ;-) > 3. those that MUST be used at subsequent computations > 4. those that are needed for resource reservation > 3 and 4 may indeed may not identical > Clearly 4. must be signalled > Full PCE cooperation can result in only one computation being > necessary except in legacy > (non-PCE) networks. In this case, signalling additional constraints > will not help. > But I would not want to rule out multiple computations and would > expect to investigate > classes 2 and 3 further. Yes and this is probably one of the items that the potential PCE WG should focus one. > >> thanks, >> - dimitri. > JP. > Thanks to you to for your detailed thought about this. > But I am not sure how to interpret your response. > > Yes/no/maybe? > > Adrian >> --- >> >> Adrian Farrel wrote: >>> Folks, >>> The chairs and ADs would like your input on >>> http://www.ietf.org/internet-drafts/draft-ash-pce-architecture >>> -00.txt in >>> the context of our inter-domain traffic engineering work. >>> This draft documents an architecture for Path Computation Elements >>> (PCE) >>> and is currently being discussed on the pce mailing list >>> (https://www1.ietf.org/mailman/listinfo/pce) >>> What we would like CCAMP to do is give us your opinion on whether >>> PCE is >>> addresing an inter-domain problem that needs to be addressed, and if >>> so >>> whether the architecture provides an acceptable way to resolve the >>> problem. >>> Answers to the mailing list in advance of the meeting in Washington >>> would be appreciated. >>> Thanks, >>> Adrian and Kireeti >>> >>> >>> >>> >>> >>> . >>> >> >> > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 22 Oct 2004 08:32:26 +0000 Message-ID: <001501c4b811$5e2c68a0$5d919ed9@Puppy> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: "Dimitri Papadimitriou" <dpapadimitriou@psg.com>, "Dimitri Papadimitriou" <Dimitri.Papadimitriou@alcatel.be> Cc: <ccamp@ops.ietf.org> Subject: Re: Your input: Use of PCE in Inter-domain Date: Fri, 22 Oct 2004 05:23:25 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Thanks Dimitri, Looks like you had a profitable flight back from Washington! > hi all, let's probably speak first about which problem we are trying to > address here and look at what a PCE approach would provide Yes. This is important. We need to identify the problem space we are trying to address and the specific problem within that space. If we cannot do this we cannot justify the work on PCE. > as (by definition) a PCE enlarges the path computation domain scope > behind the local routing domain/system, it allows the requestor included > in this routing domain/system, to obtain the result of this better PCE > visibility from the one the requestor would have had himself if it would > have performed the same path computation task, so the inter-domain > problem takes then multiple aspects: > > - case 1. multi-area basis one can assume that the PCE entity can have > such better visibility, so here the questions are twofold how better > should this visibility be from what the routing provides and how it is > self - impacting (what is the right level of details the PCE needs to > have to accomplish what it is expected to deliver) Agree. It does not follow that the PCE consulted has full visibility. Nor does it even follow that cooperating PCEs achieve full visibility. The only assumption is that the visibility (and therefore the optimality or success likelihood of the LSP) is increased. > - case 2. multi-AS (single provider) basis the issue is different as one > could assume that the local PCE will be able to determine what is the > best entry point (and the network capabilities to which it gives access) > to the next AS for a given set of request towards e.g. reachable > prefixes, AS paths, etc. I don't completely agree. It depends on "best". The local PCE may be able to select the best TE path to an entry point to the next AS, and even a least cost metric influence to the choice of that entry point given the reachability through the next AS, BUT from a TE perspective the local PCE cannot select - the next AS - the best entry point into the next AS This requires TE information that is not currently known to the local PCE. Thus a multi-PCE approach is likely. > - case 3. multi-AS (multi-provider) basis the issue is also different as > the primary assumption would be that any exchange of such information > will be restricted if not excluded without any prior agreement between > operators and then only one could assume that the case 2. applies Yes. Confidentiality is a significant constraint to any solution. But recall that the only exchange between PCEs might be limited to request and response (not to TED information). There are two interesting solutions that spring to mind (that would need to be added to the architecture). 1. Vertical inter-PCE communication That is a hierarchical relationship of PCEs rather than a peering relationship. This would allow a trusted party to do the work. (But note that an ERO might violate confidentiality) 2. The use of cookies or encryption in EROs so that the ERO is only expanded to the computed path at the ASBR. > there are also several assumptions that should also be made in order to > result in a reasonable working item: > 1. the PCE to contact is known in advance by the requestor in case > there are multiple PCEs that can be queried (and no other assumption > are made upon their sync in terms of topological information) i would > like to point out here that in case of multiple PCEs, the sync of PCE > raises the same class of issues as the initial problem it intents to > solve I agree that PCE "discovery" and selection need to be covered. I do not believe that they are rocket science within an area. Inter PCE choice may be harder, but DNS seems to handle similar issues. I disagree that synchronisation of PCEs is a substantial issue. We already have this problem with MPLS PCEs (that is, ingress LSRs) since a. The TED relies on i. IGP convergence ii. threshold dampening in the advertising LSRs b. To LSPs could be initiated from different ingresses at the same time targeting the same resource Thus, I don't believe we have any new concerns. An LSP setup may fail and need to have its computation retried. > 2. the approach consisting in having a query sequence > PCC->PCE[1]->PCE[2]->...->PCE[n] > has the same limitations as the three cases listed here above (in > brief PCC and PCE[i], i =< n should belong to the same AS, (note: > case 2 can be considered as a particular case here) Why is this? PCE[i] can request of PCE[i+1] if there is some form of "trust" relationship. This may be horizontal or vertical. There must be at least limited trust since an LSP service is to be provided! > 3. related to the above, it should be considered that the local AS > is unaware and so its decisions are independent from the potential > use of a PCE approach by the peering AS is also using a PCE approach > (or vice versa), this implies that the PCC makes a request to a PCE > that MAY be further decomposed but this is not within the knowledge > scope of the PCC i.e. PCC should be assumed to be unaware of the PCE > relationship (if any existing within a single AS) Ah, now this is a VERY good point. If I understand you right, you ask how we set up an LSP if the source domain uses PCE but the next domain does not. Firstly, we are no worse off than we are today (i.e. we can still target a domain boundary node with a loose hop to the destination). We would discover that this needed to be done when the local PCE found that it did not know about (or could not find) a PCE for the next domain. The local PCE would return a loose ERO. Note that the local PCE might know about PCEs in the next-next domain and contact them and add to the ERO accordingly. We might need to be careful not to bias the path selection according to PCE existence since that might miss some optimal paths. > 4. a PCE having a better visibility also implies it has a set of corr. > path computation capabilities so question happens to be what is the > minimum set of capabilities we have to assume to make such an > approach workable and interoperable ? Do we have to determine that list before we decide whether PCE is worth investigating? Seems to me we have to decide to start the work in order to do this. A reasonable compromise would certainly be to have CCAMP work on the requirements for this and pass them to a new/existing WG that works on PCE. > last, it becomes clearer now that the RSVP constraint passing approach > should be the primary focus of the CCAMP since the PCE approach (in > particular for the multi-AS cases) is workable iff such constraints can > be exchanged during the resource reservation phase - I absolutely agree/disagree. It depends what you mean by "constraint-passing". We currently pass various constraints that are used both for path computation and for resource reservation. During path computation there are four types of constraint 1. those that apply only at the ingress computation 2. those that would ideally be used at any subsequent computation 3. those that MUST be used at subsequent computations 4. those that are needed for resource reservation Clearly 4. must be signalled Full PCE cooperation can result in only one computation being necessary except in legacy (non-PCE) networks. In this case, signalling additional constraints will not help. But I would not want to rule out multiple computations and would expect to investigate classes 2 and 3 further. > thanks, > - dimitri. Thanks to you to for your detailed thought about this. But I am not sure how to interpret your response. Yes/no/maybe? Adrian > --- > > Adrian Farrel wrote: > > Folks, > > The chairs and ADs would like your input on > > http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-00.txt in > > the context of our inter-domain traffic engineering work. > > This draft documents an architecture for Path Computation Elements (PCE) > > and is currently being discussed on the pce mailing list > > (https://www1.ietf.org/mailman/listinfo/pce) > > What we would like CCAMP to do is give us your opinion on whether PCE is > > addresing an inter-domain problem that needs to be addressed, and if so > > whether the architecture provides an acceptable way to resolve the problem. > > Answers to the mailing list in advance of the meeting in Washington > > would be appreciated. > > Thanks, > > Adrian and Kireeti > > > > > > > > > > > > . > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Oct 2004 22:24:02 +0000 Reply-To: <dcheng@cisco.com> From: "Dean Cheng \(dcheng\)" <dcheng@cisco.com> To: "'Adrian Farrel'" <olddog@clara.co.uk>, <ccamp@ops.ietf.org> Subject: RE: Your input: Use of PCE in Inter-domain Date: Thu, 21 Oct 2004 15:22:46 -0700 Message-ID: <000801c4b7bc$7e2bf080$5ecf47ab@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The solution as suggested by the PCE I-D and on-going work do provide a practical way to solve inter-domain TE routing problem, which has been discussed in the CCAMP for a while. While there are several solution models to solve the problem, perhaps the two common ones are to rely on the ABR/ASBR and the out-of-band route server. The I-D however defines the PCE in a generic manner that can be with both of these, so is very well in-line with the problem solving effort. Dean >-----Original Message----- >From: owner-ccamp@ops.ietf.org >[mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel >Sent: Tuesday, October 19, 2004 12:11 PM >To: ccamp@ops.ietf.org >Cc: adrian@olddog.co.uk >Subject: Your input: Use of PCE in Inter-domain > > >Folks, > >The chairs and ADs would like your input on >http://www.ietf.org/internet-drafts/draft-ash-pce-architecture- >00.txt in the >context of our inter-domain traffic engineering work. > >This draft documents an architecture for Path Computation >Elements (PCE) and >is currently being discussed on the pce mailing list >(https://www1.ietf.org/mailman/listinfo/pce) > >What we would like CCAMP to do is give us your opinion on >whether PCE is >addresing an inter-domain problem that needs to be addressed, >and if so >whether the architecture provides an acceptable way to resolve >the problem. > >Answers to the mailing list in advance of the meeting in >Washington would be >appreciated. > >Thanks, >Adrian and Kireeti > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Oct 2004 18:58:24 +0000 Message-ID: <00d601c4b79f$ce778940$7a1810ac@movaz.com> From: "Igor Bryskin" <ibryskin@movaz.com> To: "Adrian Farrel" <olddog@clara.co.uk>, <ccamp@ops.ietf.org> Cc: <adrian@olddog.co.uk> Subject: Re: Your input: Use of PCE in Inter-domain Date: Thu, 21 Oct 2004 14:57:26 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit The PCE-based architecture introduced in the draft provides probably the only practical solution for computing of one or several disjoint paths for TE tunnels spanning multiple TE advertising domains (IGP areas, ASs, etc.) However, the limited TE visibility is not the only problem that can be addressed by the proposed architecture. Generally speaking, it allows for clear (logical and physical) separation of the path computation function from the rest of (MPLS-based, GMPLS-based or any other dynamic) control plane, which opens up numerous possibilities such as: 1) outsourcing of the path computation function by a controller that is not capable to perform the function due to: a) lack of information (does not run TE advertising protocol); b) lack of software or computation resources; 2) making use of advanced path computation algorithms without upgrading control plane software; 3) solving problems that require information more than usually available via TE advertising protocols. Examples: global (re-)optimization of TE tunnel placement, computing path for shared recovery (e.g. full mesh restoration), etc. 4) making use of intensive NP-hard algorithms (e.g. multi-criteria optimization, paths traversing multiple switching layers, paths satisfying optical constraints with the re-generation loops, etc.) Igor Bryskin, Movaz networks ----- Original Message ----- From: "Adrian Farrel" <olddog@clara.co.uk> To: <ccamp@ops.ietf.org> Cc: <adrian@olddog.co.uk> Sent: Tuesday, October 19, 2004 3:11 PM Subject: Your input: Use of PCE in Inter-domain > Folks, > > The chairs and ADs would like your input on > http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-00.txt in the > context of our inter-domain traffic engineering work. > > This draft documents an architecture for Path Computation Elements (PCE) and > is currently being discussed on the pce mailing list > (https://www1.ietf.org/mailman/listinfo/pce) > > What we would like CCAMP to do is give us your opinion on whether PCE is > addresing an inter-domain problem that needs to be addressed, and if so > whether the architecture provides an acceptable way to resolve the problem. > > Answers to the mailing list in advance of the meeting in Washington would be > appreciated. > > Thanks, > Adrian and Kireeti > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Oct 2004 17:20:05 +0000 To: IETF-Announce <ietf-announce@ietf.org> From: The IESG <iesg-secretary@ietf.org> Subject: Last Call: 'Generalized MPLS (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control' to Proposed Standard Reply-to: iesg@ietf.org CC: <ccamp@ops.ietf.org> Message-Id: <E1CKgKd-0001KR-Jd@megatron.ietf.org> Date: Thu, 21 Oct 2004 13:02:31 -0400 The IESG has received a request from the Common Control and Measurement Plane WG to consider the following document: - 'Generalized MPLS (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control ' <draft-ietf-ccamp-gmpls-g709-08.txt> as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2004-11-18 (note a 4-week Last Call because of the upcoming IETF meeting). The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g709-08.txt Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Oct 2004 17:19:50 +0000 To: IETF-Announce <ietf-announce@ietf.org> From: The IESG <iesg-secretary@ietf.org> Subject: Last Call: 'Generalize Multiprotocol Label Switching(GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model' to Proposed Standard Reply-to: iesg@ietf.org CC: <ccamp@ops.ietf.org> Message-Id: <E1CKgLH-0001Up-Mx@megatron.ietf.org> Date: Thu, 21 Oct 2004 13:03:11 -0400 The IESG has received a request from the Common Control and Measurement Plane WG to consider the following document: - 'Generalize Multiprotocol Label Switching(GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model ' <draft-ietf-ccamp-gmpls-overlay-05.txt> as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2004-11-18 (note a 4-week Last Call because of the upcoming IETF meeting). The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-overlay-05.txt Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Oct 2004 14:51:32 +0000 Date: Thu, 21 Oct 2004 23:49:14 +0900 From: Kenji Kumaki <ke-kumaki@kddi.com> To: ccamp@ops.ietf.org Subject: Re: Your input: Use of PCE in Inter-domain Cc: adrian@olddog.co.uk Message-Id: <20041021234851.4341.KE-KUMAKI@kddi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi all, We have already deployed inter-domain MPLS VPN services in commercial network. We face the problem that it is difficult to get a end-to-end shortest path and reoptimize inter-AS TE LSPs through inter-SP environment as I made a presentation in the last PCE BOF. We consider that the PCE-based approach is well suited to inter-AS TE, as it can solve the above problem without major impact on signaling and routing protocols. Regards, Kenji On Tue, 19 Oct 2004 20:11:23 +0100 "Adrian Farrel" <olddog@clara.co.uk> wrote: > Folks, > > The chairs and ADs would like your input on > http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-00.txt in the > context of our inter-domain traffic engineering work. > > This draft documents an architecture for Path Computation Elements (PCE) and > is currently being discussed on the pce mailing list > (https://www1.ietf.org/mailman/listinfo/pce) > > What we would like CCAMP to do is give us your opinion on whether PCE is > addresing an inter-domain problem that needs to be addressed, and if so > whether the architecture provides an acceptable way to resolve the problem. > > Answers to the mailing list in advance of the meeting in Washington would be > appreciated. > > Thanks, > Adrian and Kireeti > > > > -- Kenji Kumaki <ke-kumaki@kddi.com> Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Oct 2004 11:15:17 +0000 Message-ID: <417799FC.9010904@psg.com> Date: Thu, 21 Oct 2004 13:14:04 +0200 From: dimitri papadimitriou <dpapadimitriou@psg.com> Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 MIME-Version: 1.0 To: ccamp@ops.ietf.org CC: Adrian Farrel <olddog@clara.co.uk>, adrian@olddog.co.uk Subject: Re: Your input: Use of PCE in Inter-domain Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit hi all, let's probably speak first about which problem we are trying to address here and look at what a PCE approach would provide as (by definition) a PCE enlarges the path computation domain scope behind the local routing domain/system, it allows the requestor included in this routing domain/system, to obtain the result of this better PCE visibility from the one the requestor would have had himself if it would have performed the same path computation task, so the inter-domain problem takes then multiple aspects: - case 1. multi-area basis one can assume that the PCE entity can have such better visibility, so here the questions are twofold how better should this visibility be from what the routing provides and how it is self - impacting (what is the right level of details the PCE needs to have to accomplish what it is expected to deliver) - case 2. multi-AS (single provider) basis the issue is different as one could assume that the local PCE will be able to determine what is the best entry point (and the network capabilities to which it gives access) to the next AS for a given set of request towards e.g. reachable prefixes, AS paths, etc. - case 3. multi-AS (multi-provider) basis the issue is also different as the primary assumption would be that any exchange of such information will be restricted if not excluded without any prior agreement between operators and then only one could assume that the case 2. applies there are also several assumptions that should also be made in order to result in a reasonable working item: 1. the PCE to contact is known in advance by the requestor in case there are multiple PCEs that can be queried (and no other assumption are made upon their sync in terms of topological information) i would like to point out here that in case of multiple PCEs, the sync of PCE raises the same class of issues as the initial problem it intents to solve 2. the approach consisting in having a query sequence PCC->PCE[1]->PCE[2]->...->PCE[n] has the same limitations as the three cases listed here above (in brief PCC and PCE[i], i =< n should belong to the same AS, (note: case 2 can be considered as a particular case here) 3. related to the above, it should be considered that the local AS is unaware and so its decisions are independent from the potential use of a PCE approach by the peering AS is also using a PCE approach (or vice versa), this implies that the PCC makes a request to a PCE that MAY be further decomposed but this is not within the knowledge scope of the PCC i.e. PCC should be assumed to be unaware of the PCE relationship (if any existing within a single AS) 4. a PCE having a better visibility also implies it has a set of corr. path computation capabilities so question happens to be what is the minimum set of capabilities we have to assume to make such an approach workable and interoperable ? last, it becomes clearer now that the RSVP constraint passing approach should be the primary focus of the CCAMP since the PCE approach (in particular for the multi-AS cases) is workable iff such constraints can be exchanged during the resource reservation phase - thanks, - dimitri. --- Adrian Farrel wrote: > Folks, > The chairs and ADs would like your input on > http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-00.txt in > the context of our inter-domain traffic engineering work. > This draft documents an architecture for Path Computation Elements (PCE) > and is currently being discussed on the pce mailing list > (https://www1.ietf.org/mailman/listinfo/pce) > What we would like CCAMP to do is give us your opinion on whether PCE is > addresing an inter-domain problem that needs to be addressed, and if so > whether the architecture provides an acceptable way to resolve the problem. > Answers to the mailing list in advance of the meeting in Washington > would be appreciated. > Thanks, > Adrian and Kireeti > > > > > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Oct 2004 09:10:55 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: RE : Your input: Use of PCE in Inter-domain Date: Thu, 21 Oct 2004 11:09:23 +0200 Message-ID: <A05118C6DF9320488C77F3D5459B17B7357241@xmb-ams-333.emea.cisco.com> Thread-Topic: RE : Your input: Use of PCE in Inter-domain Thread-Index: AcS3KIVj28nwSUwCQVWme29J7moWPQAI0Gjg From: "Francois Le Faucheur \(flefauch\)" <flefauch@cisco.com> To: <ccamp@ops.ietf.org> Hello, Many requirements that would be well addressed by a PCE based approach = were presented by SPs at the PCE BOF in LA. A very significant = proportion of those involved inter-domain environments. My opinion is that PCE is clearly "addresing an inter-domain problem = that needs to be addressed" and is "an acceptable way to resolve the = problem" . Francois=20 >>-----Message d'origine----- >>De : owner-ccamp@ops.ietf.org >>[mailto:owner-ccamp@ops.ietf.org] De la part de Adrian Farrel >>Envoy=E9 : mardi 19 octobre 2004 21:11 >>=C0 : ccamp@ops.ietf.org >>Cc : adrian@olddog.co.uk >>Objet : Your input: Use of PCE in Inter-domain >> >> >>Folks, >> >>The chairs and ADs would like your input on >>http://www.ietf.org/internet-drafts/draft-ash-pce-architecture- >00.txt in the=20 >context of our inter-domain traffic engineering work.=20 > >This draft documents an architecture for Path Computation=20 >Elements (PCE) and=20 >is currently being discussed on the pce mailing list=20 >(https://www1.ietf.org/mailman/listinfo/pce)=20 > >What we would like CCAMP to do is give us your opinion on=20 >whether PCE is=20 >addresing an inter-domain problem that needs to be addressed,=20 >and if so=20 >whether the architecture provides an acceptable way to resolve=20 >the problem.=20 > >Answers to the mailing list in advance of the meeting in=20 >Washington would be=20 >appreciated.=20 > >Thanks, >Adrian and Kireeti=20 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Oct 2004 05:30:26 +0000 Date: Wed, 20 Oct 2004 22:29:53 -0700 From: Alex Zinin <zinin@psg.com> Reply-To: Alex Zinin <zinin@psg.com> Message-ID: <1675318428.20041020222953@psg.com> To: "Adrian Farrel" <adrian@olddog.co.uk> CC: ccamp@ops.ietf.org Subject: Re: draft-ietf-ccamp-gmpls-overlay-05.txt MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Thanks, Adrian. I've requested an IETF LC for this document (a 4-week one because of the upcoming IETF meeting). -- Alex http://www.psg.com/~zinin Friday, October 15, 2004, 4:45:13 PM, Adrian Farrel wrote: > Hi Alex, > We have finally got our act together and updated this draft after AD and routing > directorate review. > Could you please take it on to the IESG. > Thanks, > Adrian > ----- Original Message ----- > From: <Internet-Drafts@ietf.org> > To: <i-d-announce@ietf.org> > Cc: <ccamp@ops.ietf.org> > Sent: Friday, October 15, 2004 8:35 PM > Subject: I-D ACTION:draft-ietf-ccamp-gmpls-overlay-05.txt >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Common Control and Measurement Plane Working Group of > the IETF. >> >> Title : Generalize Multiprotocol Label Switching(GMPLS) >> User-Network Interface (UNI): Resource ReserVation >> Protocol-Traffic Engineering (RSVP-TE) Support for the >> Overlay Model >> Author(s) : G. Swallow, et al. >> Filename : draft-ietf-ccamp-gmpls-overlay-05.txt >> Pages : 12 >> Date : 2004-10-15 >> >> Generalized Multiprotocol Label Switching (GMPLS) defines both >> routing and signaling protocols for the creation of Label Switched >> Paths (LSPs) in various switching technologies. These protocols can >> be used to support a number of deployment scenarios. This memo >> addresses the application of GMPLS to the overlay model. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-overlay-05.txt >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. >> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >> to change your subscription settings. >> >> >> Internet-Drafts are also available by anonymous FTP. Login with the username >> "anonymous" and a password of your e-mail address. After logging in, >> type "cd internet-drafts" and then >> "get draft-ietf-ccamp-gmpls-overlay-05.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-ietf-ccamp-gmpls-overlay-05.txt". >> >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> > -------------------------------------------------------------------------------- >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www1.ietf.org/mailman/listinfo/i-d-announce >> Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Oct 2004 05:17:31 +0000 Date: Wed, 20 Oct 2004 22:16:56 -0700 From: Alex Zinin <zinin@psg.com> Reply-To: Alex Zinin <zinin@psg.com> Message-ID: <3810197888.20041020221656@psg.com> To: "Adrian Farrel" <adrian@olddog.co.uk> CC: ccamp@ops.ietf.org Subject: Re: CCAMP ASON requirements drafts ready for IESG MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Adrian, Thanks for following up on the comments. I've placed the documents on the agenda for IESG telechat on Oct-28. -- Alex http://www.psg.com/~zinin Thursday, October 14, 2004, 1:23:59 AM, Adrian Farrel wrote: > Hi Alex, > The two ASON requirements drafts (draft-ietf-ccamp-gmpls-ason-reqts and > draft-ietf-ccamp-gmpls-ason-routing-reqts) have just been republished. > These revisions contain updates to address the comments raised by AD review and I have > checked that the points have been correctly addressed. The revisions also contain updates > to handle the concerns raised in San Diego that the drafts did not adequately handle the > ITU-T issue of "subnetwork opacity". > Can you please put these two drafts on your list to take to the IESG. > Thanks, > Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Oct 2004 04:42:52 +0000 From: "Zafar Ali" <zali@cisco.com> To: "'LE ROUX Jean-Louis RD-CORE-LAN'" <jeanlouis.leroux@francetelecom.com>, "'Adrian Farrel'" <olddog@clara.co.uk>, <ccamp@ops.ietf.org> Cc: <adrian@olddog.co.uk> Subject: RE: RE : Your input: Use of PCE in Inter-domain Date: Thu, 21 Oct 2004 00:40:58 -0400 Message-ID: <00e201c4b728$29e2a2b0$0300a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > >>-----Message d'origine----- >>De : owner-ccamp@ops.ietf.org >>[mailto:owner-ccamp@ops.ietf.org] De la part de Adrian Farrel >>Envoy=E9 : mardi 19 octobre 2004 21:11 >>=C0 : ccamp@ops.ietf.org >>Cc : adrian@olddog.co.uk >>Objet : Your input: Use of PCE in Inter-domain >> >> >>Folks, >> >>The chairs and ADs would like your input on >>http://www.ietf.org/internet-drafts/draft-ash-pce-architecture- >00.txt in the=20 >context of our inter-domain traffic engineering work.=20 > >This draft documents an architecture for Path Computation=20 >Elements (PCE) and=20 >is currently being discussed on the pce mailing list=20 >(https://www1.ietf.org/mailman/listinfo/pce)=20 > >What we would like CCAMP to do is give us your opinion on=20 >whether PCE is=20 >addresing an inter-domain problem that needs to be addressed,=20 >and if so=20 >whether the architecture provides an acceptable way to resolve=20 >the problem.=20 Yes, as we witness at the PCE BOF that various SPs see a need for a PCE based solution. Architecture document by Adrian et al addresses these requirements quite well.=20 N.b. At PCE BOF during last IETF, various SPs presented requirement for = PCE which are beyond TE in an inter-domain environment. The architecture document also capture these additional applications of PCE architecture = as well.=20 Thanks Regards... Zafar=20 > >Answers to the mailing list in advance of the meeting in=20 >Washington would be=20 >appreciated.=20 > >Thanks, >Adrian and Kireeti=20 > >=20 > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 20 Oct 2004 08:53:38 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE : Your input: Use of PCE in Inter-domain Date: Wed, 20 Oct 2004 10:45:25 +0200 Message-ID: <D109C8C97C15294495117745780657AEF6DEF7@ftrdmel1.rd.francetelecom.fr> Thread-Topic: Your input: Use of PCE in Inter-domain Thread-Index: AcS2EKGVukfzro9pTf6kWiknuheACAAbMvlw From: "LE ROUX Jean-Louis RD-CORE-LAN" <jeanlouis.leroux@francetelecom.com> To: "Adrian Farrel" <olddog@clara.co.uk>, <ccamp@ops.ietf.org> Cc: <adrian@olddog.co.uk> Hi Adrian, all There is a requirement to compute inter-domain constrained shortest path = (see tewg inter-area/as requirements). There are several approaches to achieve this objective, as well listed = in your inter-domain framework draft. We (France Telecom) consider that PCE-based approach is particularly = well suited to inter-domain TE, as it allows achieving our objective = without major impact on signaling and routing protocols. The PCE architecture draft well addresses inter-domain path computation, = particularly section 5.3 and 5.4, by identifying distributed-PCE = computation modes.=20 Regards, JL >-----Message d'origine----- >De : owner-ccamp@ops.ietf.org=20 >[mailto:owner-ccamp@ops.ietf.org] De la part de Adrian Farrel >Envoy=E9 : mardi 19 octobre 2004 21:11 >=C0 : ccamp@ops.ietf.org >Cc : adrian@olddog.co.uk >Objet : Your input: Use of PCE in Inter-domain > > >Folks,=20 > >The chairs and ADs would like your input on=20 >http://www.ietf.org/internet-drafts/draft-ash-pce-architecture- 00.txt in the=20 context of our inter-domain traffic engineering work.=20 This draft documents an architecture for Path Computation Elements (PCE) = and=20 is currently being discussed on the pce mailing list=20 (https://www1.ietf.org/mailman/listinfo/pce)=20 What we would like CCAMP to do is give us your opinion on whether PCE is = addresing an inter-domain problem that needs to be addressed, and if so=20 whether the architecture provides an acceptable way to resolve the = problem.=20 Answers to the mailing list in advance of the meeting in Washington = would be=20 appreciated.=20 Thanks, Adrian and Kireeti=20 =20 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 19 Oct 2004 19:13:49 +0000 From: "Adrian Farrel" <olddog@clara.co.uk> To: ccamp@ops.ietf.org Cc: adrian@olddog.co.uk Subject: Your input: Use of PCE in Inter-domain Date: Tue, 19 Oct 2004 20:11:23 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <E1CJzOF-000Bb2-CC@oceanus.uk.clara.net> Folks, The chairs and ADs would like your input on http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-00.txt in the context of our inter-domain traffic engineering work. This draft documents an architecture for Path Computation Elements (PCE) and is currently being discussed on the pce mailing list (https://www1.ietf.org/mailman/listinfo/pce) What we would like CCAMP to do is give us your opinion on whether PCE is addresing an inter-domain problem that needs to be addressed, and if so whether the architecture provides an acceptable way to resolve the problem. Answers to the mailing list in advance of the meeting in Washington would be appreciated. Thanks, Adrian and Kireeti Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 16 Oct 2004 01:02:28 +0000 Message-ID: <08df01c4b31b$a71d9840$21849ed9@Puppy> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: <zinin@psg.com> Cc: <ccamp@ops.ietf.org> Subject: draft-ietf-ccamp-gmpls-overlay-05.txt Date: Sat, 16 Oct 2004 00:45:13 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Alex, We have finally got our act together and updated this draft after AD and routing directorate review. Could you please take it on to the IESG. Thanks, Adrian ----- Original Message ----- From: <Internet-Drafts@ietf.org> To: <i-d-announce@ietf.org> Cc: <ccamp@ops.ietf.org> Sent: Friday, October 15, 2004 8:35 PM Subject: I-D ACTION:draft-ietf-ccamp-gmpls-overlay-05.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. > > Title : Generalize Multiprotocol Label Switching(GMPLS) > User-Network Interface (UNI): Resource ReserVation > Protocol-Traffic Engineering (RSVP-TE) Support for the > Overlay Model > Author(s) : G. Swallow, et al. > Filename : draft-ietf-ccamp-gmpls-overlay-05.txt > Pages : 12 > Date : 2004-10-15 > > Generalized Multiprotocol Label Switching (GMPLS) defines both > routing and signaling protocols for the creation of Label Switched > Paths (LSPs) in various switching technologies. These protocols can > be used to support a number of deployment scenarios. This memo > addresses the application of GMPLS to the overlay model. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-overlay-05.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-ccamp-gmpls-overlay-05.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-ccamp-gmpls-overlay-05.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------------------------------- > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 15 Oct 2004 19:37:33 +0000 Message-Id: <200410151935.PAA02562@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-overlay-05.txt Date: Fri, 15 Oct 2004 15:35:24 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalize Multiprotocol Label Switching(GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model Author(s) : G. Swallow, et al. Filename : draft-ietf-ccamp-gmpls-overlay-05.txt Pages : 12 Date : 2004-10-15 Generalized Multiprotocol Label Switching (GMPLS) defines both routing and signaling protocols for the creation of Label Switched Paths (LSPs) in various switching technologies. These protocols can be used to support a number of deployment scenarios. This memo addresses the application of GMPLS to the overlay model. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-overlay-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-overlay-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-overlay-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-15154017.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-overlay-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-overlay-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-15154017.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 14 Oct 2004 08:24:24 +0000 Message-ID: <06cf01c4b1c7$3ac73ac0$21849ed9@Puppy> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: <zinin@psg.com> Cc: <ccamp@ops.ietf.org> Subject: CCAMP ASON requirements drafts ready for IESG Date: Thu, 14 Oct 2004 09:23:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Alex, The two ASON requirements drafts (draft-ietf-ccamp-gmpls-ason-reqts and draft-ietf-ccamp-gmpls-ason-routing-reqts) have just been republished. These revisions contain updates to address the comments raised by AD review and I have checked that the points have been correctly addressed. The revisions also contain updates to handle the concerns raised in San Diego that the drafts did not adequately handle the ITU-T issue of "subnetwork opacity". Can you please put these two drafts on your list to take to the IESG. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 14 Oct 2004 08:14:00 +0000 Date: Thu, 14 Oct 2004 12:48:19 +0530 From: Harish M <harishm@huawei.com> Subject: RE: LMP - GMPLS To: ccamp@ops.ietf.org Reply-to: harishm@huawei.com Message-id: <KFEJJPIDPALGKBPFKOIGMEHFCBAA.harishm@huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT This can be computed using the Length field (16 bits) in LMP object. -----Original Message----- From: Harish M [mailto:harishm@huawei.com] Sent: Thursday, October 14, 2004 11:07 AM To: ccamp@ops.ietf.org Subject: LMP - GMPLS Hi, Referring to the draft-ietf_ccamp-lmp-10.txt "LinkSummary Message can have multiple DATA_LINK objects and each DATA_LINK object can have more than one variable length sub-object (for including multiple capabilities of a data link)." Since a LinkSummary Message can contain multiple DATA_LINK Objects (Class = 12) and as there is no field/mechanism to indicate the number of sub-objects under a DATA_LINK object, how can we know where the next DATA_LINK object starts ? <LinkSummary Message> ::= <Common Header> <MESSAGE_ID> <TE_LINK> <DATA_LINK> [<DATA_LINK>...] --------------------------------------------------------------------------- | IP Header | UDP Header | LMP Header | LMP Object-1 | ... | LMP Object-n | --------------------------------------------------------------------------- Thanks, Harish M. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 13 Oct 2004 20:32:52 +0000 Message-Id: <200410132031.QAA03661@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-reqts-07.txt Date: Wed, 13 Oct 2004 16:31:49 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Requirements for Generalized MPLS (GMPLS) Signaling Usage and Extensions for Automatically Switched Optical Network (ASON) Author(s) : D. Papadimitriou, et al. Filename : draft-ietf-ccamp-gmpls-ason-reqts-07.txt Pages : 14 Date : 2004-10-13 The Generalized MPLS (GMPLS) suite of protocol has been defined to control different switching technologies as well as different applications. These include support for requesting TDM connections including SONET/SDH and Optical Transport Networks (OTNs). This document concentrates on the signaling aspects of the GMPLS suite of protocols. It identifies the features to be covered by the GMPLS signalling protocol to support the capabilities of an Automatically Switched Optical Network (ASON). This document provides a problem statement and additional requirements on the GMPLS signaling protocol to support the ASON functionality. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-reqts-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-ason-reqts-07.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-ccamp-gmpls-ason-reqts-07.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: <2004-10-13164649.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-reqts-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-ason-reqts-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-13164649.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 13 Oct 2004 20:32:44 +0000 Message-Id: <200410132031.QAA03622@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-reqts-05.txt Date: Wed, 13 Oct 2004 16:31:03 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Requirements for Generalized MPLS (GMPLS) Routing for Automatically Switched Optical Network (ASON) Author(s) : D. Brungard Filename : draft-ietf-ccamp-gmpls-ason-routing-reqts-05.txt Pages : 19 Date : 2004-10-13 The Generalized Multi-Protocol Label Switching (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting Time Division Multiplexing (TDM) connections including Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) and Optical Transport Networks (OTNs). This document concentrates on the routing requirements on the GMPLS suite of protocols to support the capabilities and functionalities for an Automatically Switched Optical Network (ASON) as defined by ITU-T. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-reqts-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-ason-routing-reqts-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-reqts-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-13164637.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-reqts-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-ason-routing-reqts-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-13164637.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 12 Oct 2004 21:13:46 +0000 Message-Id: <6.0.3.0.2.20041012135124.03d399c8@sa.infonet.com> Date: Tue, 12 Oct 2004 14:10:02 -0700 To: Adrian Farrel <adrian@olddog.co.uk>, <routing-discussion@ietf.org>, <rtgwg@ietf.org> From: raymond zhang <zhangr@sa.infonet.com> Subject: Re: [mpls] Mailing List for Path Computation Element (PCE) Cc: ccamp@ops.ietf.org, mpls@ietf.org, pce@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Adrian, JP, Jerry, I've gone through the I-D "draft-ash-pce-architecture-00.txt" and I think this document has very well stated the architectural objectives and need for a separate WG for this area. Also please find some minor comments below: - section 3. Definitions " Path Computation Element (PCE) is an entity that is capable of computing a network path or route based on a network graph, and applying computational constraints. The PCE entity can be located within an application" (RZ: I'd suggest some rewording here: The PCE entity is an application process that can be located on a network node or component, on an out-of- network server, etc.) - Page 4, first paragraph: 1) Path computation is applicable in both intra-domain, inter-domain, and inter-layer contexts. Inter-domain path computation may involve the correlation of topology and routing information between domains. Overlapping domains are not within the scope of this document. In the inter-domain case, the domains may belong to a single or multiple (RZ:"inter-layer contexts" is mentioned at the beginning of this paragraph so it would be good to explain this a bit as did for inter-domain) - Page 4. 3) "Centralized computation model" ... There would (RZ: add "be")... - Page 6, 2nd paragraph: (RZ: From SP's perspective, it is not a difficult thing to migrate a legacy IGP plane, e.g. ISIS with narrow metrics to a new ISIS plane supporting TE ext. So I dont seem to see a strong case for this...) - Page 6, section 4.4. (RZ: there maybe some inconsistence here to say on one hand this scenario does not relay on loose hops, yet on the other hand PCE based solution provides loose hops in the computed paths ?) - Page 7, section 5.1. 5.1. Composite PCE "Figure 1 below shows the components of a typical composite PCE node (that is, a router that also implements the PCE functionality) that utilizes path computation. The routing protocol is used to exchange TE information from which the TED is constructed. Service requests are received by the node and converted into signaling requests" (RZ:it would be good to clarify between service requests to the PCE or inter- PCE requests and service requests to signal a TE-LSP request) ... - Page 12, first paragraph (RZ: It would be probably more appropriate to rename to this section to "Service Request/Response Synchronization" vs. "TED Sync" in a subsequent section. It may be more productive here in describing service request/reponse sync of PCC-PCE and PCE-PCE as part of the architectural discussion, rather than illustrating more detailed procedures since these procedures could be discussed in a detailed spec document in which it may transform to something different.) - page 13, 2nd paragrah: "No assumption is made at this stage about whether the PCC-PCE and PCE-PCE communication protocols are identical." (RZ: but I think it would be architectrually more scalable if they are same, so are such comments are warranted here (same protocols for both PCC-PCE/PCE-PCE...) in an arch doc ? - Section 6.8: (RZ: since this is an arch doc, does it imply that implementation of either scheme would meet the arch framework established here ?) - A general comment: there are a lot of very good, analytical discussions in the document presenting different cases. It would be good I think if the authors could provide some guidance in drawing up some architecture recommendations after comparing/analyzing some of these cases or simply say all cases presented in some of these sections are considered valid architectural options ? Regards, Raymond Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 11 Oct 2004 23:45:20 +0000 Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5822B2DE-1BDF-11D9-B106-000D93330B14@cisco.com> Content-Transfer-Encoding: 7bit Cc: jpv@cisco.com, mpls@ietf.org, Gerald <R@movaz.com>, pce@ietf.org, ccamp@ops.ietf.org, "Zafar Ali" <zali@cisco.com>, 'Ash@movaz.com From: JP Vasseur <jvasseur@cisco.com> Subject: Re: [Pce] Re: Path Computation Element (PCE) Architecture and mailing list, Date: Mon, 11 Oct 2004 19:43:25 -0400 To: ibryskin@movaz.com Hi Igor, On Oct 9, 2004, at 10:45 AM, ibryskin@movaz.com wrote: > Hi guys, > > I think this is a vey sound document. I have a suggestion though. > > It would be extreamely useful if a PCE could advertise its capabilities > such as: > > a) set of constraints that it can account for (diversity, SRLGs, > optical > impairements, wavelenght continuity, etc.) > > b) number of switching capability layers (and which); > > c) number of path selection criterias (and which); > > d) whether it is a stateless path calculator or can send updates about > better paths that might be available in future; > > e) whether it can compute P2MP trees (and which types); > > f) whether it can ensure the resource sharing between backup tunnels; > > g) etc. > > This information would help a lot for a potential PCC that dynamically > learns about PCEs available on the network to decide which of them to > use. > I cannot agree more ! See the two PCE cap related drafts: draft-vasseur-ospf--te-caps (and isis) Such draft would probably ends up being discussed here, should we end up creating a WG. JP. > Igor > > >> Hi Adrian, Jerry, JP, et al, >> >> Thanks for putting the PCE Architecture document >> (http://www.ietf.org/internet-drafts/draft-ash-pce-architecture >> -00.txt), I >> found it very useful in scoping PCE WG and applicability of PCE in >> MPLS/ >> GMPLS TE networks. In the following I have a few questions/ comments >> about >> this ID. >> >> I would also like to request about what would be a tentative agenda >> for >> PCE >> BOF Part II in DC? I think the discussion in SD went very well in >> favor of >> PCE WG, pending this architecture ID. What is the present plan of >> record? >> >> - What did you meant by "the level of robustness of the path >> resources", >> in >> PCC-PCE communication? I am expecting that the client can also >> specify an >> exclude list, include list (this is in addition of SRLG to include/ >> exclude). >> >> - Can you please elaborate more on advantages of Stateful PCE and >> what are >> the pits fall of using Stateful PCE in a distributed PCE environment. >> You >> have information about Out-of-band TED synchronization but I am >> thinking >> there is some complexity involved in such mechanism and stateful PCE >> in a >> distributed PCE setup. More description on the applicability of >> Stateful >> PCE >> & Out-of-band TED synchronization would be useful to better scope core >> vs.. >> advanced features of PCE. >> >> - When PCE is distributed, are there any considerations in path >> computation >> (minimum guidelines, like constraints based shortest path based on the >> specified optimization criteria, optimization criteria does not >> change for >> the same setup when multiple PCE are involved in path computation, >> etc.) >> to >> make Path Computations in a distributed PCE scheme, that you think we >> need >> to add to the text of this document. >> >> - When a number of disjoint paths are required, we need a mechanism to >> specify if near disjoint Paths are acceptable (but this is need not >> to be >> in >> architecture doc). >> >> The rest of the document look very good to me. >> >> Regards... Zafar >> >> > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 11 Oct 2004 19:42:14 +0000 Message-Id: <200410111938.PAA08880@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-rsvp-restart-ext-00.txt Date: Mon, 11 Oct 2004 15:38:15 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Extensions to GMPLS RSVP Graceful Restart Author(s) : A. Satyanarayana, R. Rahman Filename : draft-ietf-ccamp-rsvp-restart-ext-00.txt Pages : 21 Date : 2004-10-11 This document describes extensions to the RSVP Graceful Restart mechanisms defined in [RFC3473]. The extensions enable the recovery of RSVP signaling state based on the Path message last sent by the node being restarted. Previously defined Graceful Restart mechanisms, also called recovery from nodal faults, permit recovery of signaling state from adjacent nodes when the data plane has retained the associated forwarding state across a restart. These mechanisms do not fully support signaling state recovery on ingress nodes or recovery of all RSVP objects. The presented extensions use the RSVP Hello extensions defined in [RFC3209], and extensions for state recovery on nodal faults defined in [RFC3473]. With the presented extensions the restarting node can recover all previously transmitted Path state including the ERO and the downstream (outgoing) interface identifiers. The extensions can also be used to recover signaling state after the restart of an ingress node. The extensions optionally support the use of Summary Refresh, defined in [RFC2961], to reduce the number of messages exchanged during the Recovery Phase when the restarting node has recovered signaling state locally for one or more LSP's. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-restart-ext-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-rsvp-restart-ext-00.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-ccamp-rsvp-restart-ext-00.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: <2004-10-11155118.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-rsvp-restart-ext-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-rsvp-restart-ext-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-11155118.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 11 Oct 2004 10:51:32 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE : RE : [mpls] draft-vasseur-ccamp-te-router-info-00.txt clarificationneeded. Date: Mon, 11 Oct 2004 12:46:52 +0200 Message-ID: <D109C8C97C15294495117745780657AEE49BC0@ftrdmel1.rd.francetelecom.fr> Thread-Topic: RE : [mpls] draft-vasseur-ccamp-te-router-info-00.txt clarificationneeded. Thread-Index: AcStQHdLaRu4nznXRjqRKZlxAW7KpACPueUw From: "LE ROUX Jean-Louis RD-CORE-LAN" <jeanlouis.leroux@francetelecom.com> To: "Dillikar Satyanarayana-G19471" <satya@motorola.com>, <mpls@ietf.org>, <mpls-ops@mplsrc.com> Cc: <ccamp@ops.ietf.org> Hi Dillikar, E =3D 1, so both trees are valid. Regards, JL >-----Message d'origine----- >De : Dillikar Satyanarayana-G19471 [mailto:satya@motorola.com]=20 >Envoy=E9 : vendredi 8 octobre 2004 16:09 >=C0 : LE ROUX Jean-Louis RD-CORE-LAN; mpls@ietf.org; = mpls-ops@mplsrc.com >Cc : ccamp@ops.ietf.org >Objet : RE: RE : [mpls]=20 >draft-vasseur-ccamp-te-router-info-00.txt clarificationneeded. > > >Hi JL, > Thanks for your explanation. As the hardware data-plane=20 >branch capability is not known to CSPF=20 >Path-Computation-Engine(PCE). PCE only has to rely on E-bit=20 >and B-bit of the nodes. > PCE computing trees T1 and T2 based on given R3 bit status.=20 >Please tell us which tree is valid and which tree is not=20 >valid and why? >=20 >Tree T1: Ingress =3D R1 Egresses =3D R2,R3 >=20 > R1 > | > R2--R3 >=20 >R3(E=3D1, B=3D0) > > >Tree T2: Ingress =3D R1 Egresses =3D R2,R3 >=20 > R1 > | > R2--R3 >=20 >R3(E=3D1, B=3D1) > >TIA, >Satya=20 > >> -----Original Message----- >> From: mpls-bounces@lists.ietf.org >> [mailto:mpls-bounces@lists.ietf.org] On Behalf Of LE ROUX=20 >> Jean-Louis RD-CORE-LAN >> Sent: Friday, October 08, 2004 3:57 AM >> To: Satyanarayana Dillikar; mpls@ietf.org; mpls-ops@mplsrc.com >> Cc: ccamp@ops.ietf.org >> Subject: RE : [mpls]=20 >> draft-vasseur-ccamp-te-router-info-00.txt clarificationneeded. >>=20 >>=20 >> Hi Dillikar, >>=20 >> Sorry for this delayed answer. >> Thanks for these useful comments, that will help clarifying >> this spec. Please see inline. Regards, >>=20 >> JL >>=20 >> PS: I'm copying ccamp >>=20 >> >-----Message d'origine----- >> >De : mpls-bounces@lists.ietf.org=20 >[mailto:mpls-bounces@lists.ietf.org]=20 >> >De la part de Satyanarayana Dillikar >> >Envoy=E9 : mercredi 6 octobre 2004 10:38 >> >=C0 : mpls@ietf.org; mpls-ops@mplsrc.com >> >Objet : [mpls] draft-vasseur-ccamp-te-router-info-00.txt=20 >> >clarificationneeded. >> > >> > >> >Hi, >> > We have some confusion in understanding the Data >> >Plane Capability Flags (B-bit & E-bit) from=20 >> >draft-vasseur-ccamp-te-router-info-00.txt >> > >> >(a) Does E-bit ON implies B-bit ON always ? (assuming >> >ON =3D set and OFF =3D unset). >>=20 >> Basically bud (transit + Egress) capability requires some >> branching in the data plane so in general E ON will imply B=20 >> ON, but note that these capabilities does not necessarily=20 >> reflect real hardware capabilities as they may be=20 >> activated/deactivated by the operator for various reasons. We=20 >> will clarify this point in next revision. >>=20 >>=20 >> >(b) E-bit =3D ON & B-bit =3D OFF, is it a valid >> >combination. >>=20 >> Yes see above, there may be cases where the operator want to >> deactivate branch capability on a node (He does't want that=20 >> the node act as a branch LSR), even if its data plane is=20 >> physically branch capable, but he allows the node to act as a=20 >> bud-LSR (transit + egress). This gives more operational flexibility. >>=20 >> >(c) Please tell us the E-bit and B-bit status for a >> >node which is a destination node but does not have >> >branch capability. >>=20 >> If its data plane is not branch capable then it will also >> probably not be bud capable so=20 >> E =3D 0 and B =3D 0 >>=20 >> In return, if its data plane is branch capable but branch LSR >> capability has been deactivated by configuration and bud-LSR=20 >> capability is activated, then E =3D 1 and B =3D 0 >>=20 >> > >> > >> >We are also curious to know >> >(1)The idea behind combing two things (egress status & transit=20 >> >status) in a single E-bit. rather than making use of B-bit(branch)=20 >> >and having E-bit just for egress status. >>=20 >> Remind that these capabilities are used for tree computation >> purpose, and the egress is an entry=20 >> of the computation. So, IMHO it does't really make any sense=20 >> to advertise egress capability only.=20 >>=20 >> >(2) Why the TE Node Capability Descriptor TLV should >> >have E-bit & how it should be used in CSPF path >> >computation. >>=20 >> This allows advertising if an LSR can be transit and egress. >> This is particulary useful for steiner tree topologies.=20 >> See the following example:=20 >> Tree T: Ingress =3D R1 Egresses =3D R2, R3, R4 >>=20 >> R1 >> | >> R2--R3---R4 >>=20 >> Such tree can be setup only if R3 has Egress + Transit capability. >>=20 >>=20 >> Regards, >>=20 >> JL >>=20 >>=20 >>=20 >> > >> >Thanks >> >Satya >> > >> > >> > =09 >> >_______________________________ >> >Do you Yahoo!? >> >Declare Yourself - Register online to vote today! >http://vote.yahoo.com >> >>_______________________________________________ >>mpls mailing list >>mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls >> > >_______________________________________________ >mpls mailing list >mpls@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/mpls > Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 09 Oct 2004 14:47:20 +0000 Message-ID: <3287.70.177.176.176.1097333147.squirrel@webmail.movaz.com> Date: Sat, 9 Oct 2004 10:45:47 -0400 (EDT) Subject: Re: Path Computation Element (PCE) Architecture and mailing list, From: ibryskin@movaz.com To: "Zafar Ali" <zali@cisco.com> Cc: pce@ietf.org, "'Adrian Farrel'" <adrian@olddog.co.uk>, 'Ash@movaz.com, "Gerald" <R@movaz.com>, "ALABS'" <gash@att.com>, jpv@cisco.com, mpls@ietf.org, ccamp@ops.ietf.org, zinin@psg.com User-Agent: SquirrelMail/1.4.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi guys, I think this is a vey sound document. I have a suggestion though. It would be extreamely useful if a PCE could advertise its capabilities such as: a) set of constraints that it can account for (diversity, SRLGs, optical impairements, wavelenght continuity, etc.) b) number of switching capability layers (and which); c) number of path selection criterias (and which); d) whether it is a stateless path calculator or can send updates about better paths that might be available in future; e) whether it can compute P2MP trees (and which types); f) whether it can ensure the resource sharing between backup tunnels; g) etc. This information would help a lot for a potential PCC that dynamically learns about PCEs available on the network to decide which of them to use. Igor > Hi Adrian, Jerry, JP, et al, > > Thanks for putting the PCE Architecture document > (http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-00.txt), I > found it very useful in scoping PCE WG and applicability of PCE in MPLS/ > GMPLS TE networks. In the following I have a few questions/ comments about > this ID. > > I would also like to request about what would be a tentative agenda for > PCE > BOF Part II in DC? I think the discussion in SD went very well in favor of > PCE WG, pending this architecture ID. What is the present plan of record? > > - What did you meant by "the level of robustness of the path resources", > in > PCC-PCE communication? I am expecting that the client can also specify an > exclude list, include list (this is in addition of SRLG to include/ > exclude). > > - Can you please elaborate more on advantages of Stateful PCE and what are > the pits fall of using Stateful PCE in a distributed PCE environment. You > have information about Out-of-band TED synchronization but I am thinking > there is some complexity involved in such mechanism and stateful PCE in a > distributed PCE setup. More description on the applicability of Stateful > PCE > & Out-of-band TED synchronization would be useful to better scope core > vs.. > advanced features of PCE. > > - When PCE is distributed, are there any considerations in path > computation > (minimum guidelines, like constraints based shortest path based on the > specified optimization criteria, optimization criteria does not change for > the same setup when multiple PCE are involved in path computation, etc.) > to > make Path Computations in a distributed PCE scheme, that you think we need > to add to the text of this document. > > - When a number of disjoint paths are required, we need a mechanism to > specify if near disjoint Paths are acceptable (but this is need not to be > in > architecture doc). > > The rest of the document look very good to me. > > Regards... Zafar > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 08 Oct 2004 21:06:53 +0000 From: "Zafar Ali" <zali@cisco.com> To: <pce@ietf.org> Cc: "'Adrian Farrel'" <adrian@olddog.co.uk>, "'Ash, Gerald R \(Jerry\), ALABS'" <gash@att.com>, <jpv@cisco.com>, <mpls@ietf.org>, <ccamp@ops.ietf.org>, <zinin@psg.com> Subject: Path Computation Element (PCE) Architecture and mailing list, Date: Fri, 8 Oct 2004 17:05:35 -0400 Message-ID: <000701c4ad7a$8f896ca0$0300a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C4AD59.08795340" This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C4AD59.08795340 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Adrian, Jerry, JP, et al,=20 =20 Thanks for putting the PCE Architecture document (http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-00.txt), = I found it very useful in scoping PCE WG and applicability of PCE in MPLS/ GMPLS TE networks. In the following I have a few questions/ comments = about this ID.=20 =20 I would also like to request about what would be a tentative agenda for = PCE BOF Part II in DC? I think the discussion in SD went very well in favor = of PCE WG, pending this architecture ID. What is the present plan of = record?=20 =20 - What did you meant by "the level of robustness of the path resources", = in PCC-PCE communication? I am expecting that the client can also specify = an exclude list, include list (this is in addition of SRLG to include/ exclude). =20 =20 - Can you please elaborate more on advantages of Stateful PCE and what = are the pits fall of using Stateful PCE in a distributed PCE environment. = You have information about Out-of-band TED synchronization but I am thinking there is some complexity involved in such mechanism and stateful PCE in = a distributed PCE setup. More description on the applicability of Stateful = PCE & Out-of-band TED synchronization would be useful to better scope core = vs.. advanced features of PCE.=20 =20 - When PCE is distributed, are there any considerations in path = computation (minimum guidelines, like constraints based shortest path based on the specified optimization criteria, optimization criteria does not change = for the same setup when multiple PCE are involved in path computation, etc.) = to make Path Computations in a distributed PCE scheme, that you think we = need to add to the text of this document.=20 =20 - When a number of disjoint paths are required, we need a mechanism to specify if near disjoint Paths are acceptable (but this is need not to = be in architecture doc). =20 =20 The rest of the document look very good to me.=20 =20 Regards... Zafar =20 ------=_NextPart_000_0008_01C4AD59.08795340 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii"> <TITLE>Message</TITLE> <META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR></HEAD> <BODY> <DIV><FONT face=3DArial size=3D2><SPAN class=3D151055918-08102004>Hi = Adrian, Jerry,=20 JP, et al, </SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D151055918-08102004></SPAN></FONT> </DIV> <DIV><FONT face=3DArial><FONT size=3D2>Thanks<SPAN = class=3D151055918-08102004> for=20 putting the PCE Architecture document (<A=20 href=3D"http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-00= .txt">http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-00.t= xt</A>),=20 I found it very useful in scoping PCE WG and applicability of PCE in = MPLS/ GMPLS=20 TE networks. In the following I have a few questions/ comments = about this=20 ID. </SPAN></FONT></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D151055918-08102004></SPAN></FONT> </DIV> <DIV><FONT face=3DArial size=3D2><SPAN class=3D151055918-08102004>I = would also like to=20 request about what would be a tentative agenda for PCE BOF Part II in = DC? I=20 think the discussion in SD went very well in favor of PCE WG, pending = this=20 architecture ID. What is the present plan of record? = </SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D151055918-08102004></SPAN></FONT> </DIV> <DIV><FONT face=3DArial size=3D2><SPAN class=3D151055918-08102004>- What = did you meant=20 by "the level of robustness of the path resources", in PCC-PCE = communication? I=20 am expecting that the client can also specify an exclude list, include = list=20 (this is in addition of SRLG to include/ exclude).=20 </SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D151055918-08102004></SPAN></FONT> </DIV> <DIV><FONT face=3DArial size=3D2><SPAN class=3D151055918-08102004>- Can = you please=20 elaborate more on advantages of Stateful PCE and what are the pits fall = of using=20 Stateful PCE in a distributed PCE environment. You have information = about=20 Out-of-band TED synchronization but I am thinking there is some = complexity=20 involved in such mechanism and stateful PCE in a distributed PCE setup. = More=20 description on the applicability of Stateful PCE & Out-of-band TED=20 synchronization would be useful to better scope core vs.. advanced = features of=20 PCE. </SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D151055918-08102004></SPAN></FONT> </DIV> <DIV><FONT face=3DArial size=3D2><SPAN class=3D151055918-08102004>- When = PCE is=20 distributed, are there any considerations in path computation (minimum=20 guidelines, like constraints based shortest path based on the specified=20 optimization criteria, optimization criteria does not change for the = same setup=20 when multiple PCE are involved in path computation, etc.) to make Path=20 Computations in a distributed PCE scheme, that you think we need to add = to the=20 text of this document. </SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2><SPAN class=3D151055918-08102004>- When = a number of=20 disjoint paths are required, we need a mechanism to specify if near = disjoint Paths are acceptable (but this is need not to be in = architecture=20 doc). </SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2><SPAN class=3D151055918-08102004>The = rest of the=20 document look very good to me. </SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV align=3Dleft><FONT face=3DArial size=3D2>Regards... = Zafar</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV></BODY></HTML> ------=_NextPart_000_0008_01C4AD59.08795340-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 08 Oct 2004 20:49:39 +0000 Message-ID: <019b01c4ad78$34fe0540$21849ed9@Puppy> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: <ccamp@ops.ietf.org> Subject: GMPLS MIBs Date: Fri, 8 Oct 2004 21:48:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, New versions of the GMPLS MIB modules are now available in the repository. The changes are minor: - boilerplate - apply lessons learned from MPLS MIBs - add more references - smilint - update references - reformat The conformance statements are still sub-standard, but Tom plans to work on them soon. Otherwise we believe that these drafts are 'cooked' and we know of a couple of implementations that seem to be working OK. Once the conformance statements are done we will be taking these to the MIB doctors and asking the WG about last call. Your review input at this stage would be most welcome. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 08 Oct 2004 20:49:37 +0000 Message-ID: <019c01c4ad78$3d31a140$21849ed9@Puppy> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: <ccamp@ops.ietf.org> Subject: Re: I-D ACTION:draft-ietf-ccamp-crankback-03.txt Date: Fri, 8 Oct 2004 21:48:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit The changes in this version are trivial (boilerplate and typos). Thanks, Adrian ----- Original Message ----- From: <Internet-Drafts@ietf.org> To: <i-d-announce@ietf.org> Cc: <ccamp@ops.ietf.org> Sent: Friday, October 08, 2004 8:33 PM Subject: I-D ACTION:draft-ietf-ccamp-crankback-03.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. > > Title : Crankback Signaling Extensions for MPLS Signaling > Author(s) : A. Farrel, et al. > Filename : draft-ietf-ccamp-crankback-03.txt > Pages : 31 > Date : 2004-10-8 > > In a distributed, constraint-based routing environment, the > information used to compute a path may be out of date. This means > that Multiprotocol Label Switching (MPLS) label switched path (LSP) > setup requests may be blocked by links or nodes without sufficient > resources. Crankback is a scheme whereby setup failure information is > returned from the point of failure to allow new setup attempts to be > made avoiding the blocked resources. Crankback can also be applied to > LSP restoration to indicate the location of the failed link or node. > > This document specifies crankback signaling extensions for use in > MPLS signaling using RSVP-TE as defined in 'RSVP-TE: Extensions to > RSVP for LSP Tunnels', RFC3209, so that the LSP setup request can be > retried on an alternate path that detours around blocked links or > nodes. This offers significant improvements in the successful setup > and recovery ratios for LSPs, especially in situations where a large > number of setup requests are triggered at the same time. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-crankback-03.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-ccamp-crankback-03.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-ccamp-crankback-03.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. > -------------------------------------------------------------------------------- > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 08 Oct 2004 19:35:43 +0000 Message-Id: <200410081935.PAA28239@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-te-mib-06.txt Date: Fri, 08 Oct 2004 15:35:00 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base Author(s) : T. Nadeau, A. Farrel Filename : draft-ietf-ccamp-gmpls-te-mib-06.txt Pages : 49 Date : 2004-10-8 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for Generalized Multiprotocol Label Switching (GMPLS) based traffic engineering. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-te-mib-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-te-mib-06.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-ccamp-gmpls-te-mib-06.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: <2004-10-8160020.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-te-mib-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-te-mib-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-8160020.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 08 Oct 2004 19:35:41 +0000 Message-Id: <200410081933.PAA28086@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-crankback-03.txt Date: Fri, 08 Oct 2004 15:33:12 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Crankback Signaling Extensions for MPLS Signaling Author(s) : A. Farrel, et al. Filename : draft-ietf-ccamp-crankback-03.txt Pages : 31 Date : 2004-10-8 In a distributed, constraint-based routing environment, the information used to compute a path may be out of date. This means that Multiprotocol Label Switching (MPLS) label switched path (LSP) setup requests may be blocked by links or nodes without sufficient resources. Crankback is a scheme whereby setup failure information is returned from the point of failure to allow new setup attempts to be made avoiding the blocked resources. Crankback can also be applied to LSP restoration to indicate the location of the failed link or node. This document specifies crankback signaling extensions for use in MPLS signaling using RSVP-TE as defined in 'RSVP-TE: Extensions to RSVP for LSP Tunnels', RFC3209, so that the LSP setup request can be retried on an alternate path that detours around blocked links or nodes. This offers significant improvements in the successful setup and recovery ratios for LSPs, especially in situations where a large number of setup requests are triggered at the same time. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-crankback-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-crankback-03.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-ccamp-crankback-03.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: <2004-10-8155959.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-crankback-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-crankback-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-8155959.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 08 Oct 2004 19:35:27 +0000 Message-Id: <200410081934.PAA28221@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-lsr-mib-06.txt Date: Fri, 08 Oct 2004 15:34:31 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base Author(s) : T. Nadeau, A. Farrel Filename : draft-ietf-ccamp-gmpls-lsr-mib-06.txt Pages : 39 Date : 2004-10-8 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure and/or monitor a Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSRs). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-lsr-mib-06.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-ccamp-gmpls-lsr-mib-06.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: <2004-10-8160013.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-lsr-mib-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-8160013.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 08 Oct 2004 19:35:25 +0000 Message-Id: <200410081933.PAA28164@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-tc-mib-06.txt Date: Fri, 08 Oct 2004 15:33:53 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Definitions of Textual Conventions for Generalized Multi-Protocol Label Switching (GMPLS) Management Author(s) : T. Nadeau, A. Farrel Filename : draft-ietf-ccamp-gmpls-tc-mib-06.txt Pages : 9 Date : 2004-10-8 This document defines a Management Information Base (MIB) module which contains Textual Conventions to represent commonly used Generalized Multi-Protocol Label Switching (GMPLS) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in GMPLS related MIB modules that would otherwise define their own representations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-tc-mib-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-tc-mib-06.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-ccamp-gmpls-tc-mib-06.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: <2004-10-8160006.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-tc-mib-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-tc-mib-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-8160006.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 08 Oct 2004 11:11:41 +0000 Message-ID: <009401c4ad27$9da766a0$21849ed9@Puppy> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: <ccamp@ops.ietf.org> Subject: Basic agenda structure for Washington DC Date: Fri, 8 Oct 2004 12:11:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, Since San Diego, we have managed to move on quite well with our existing milestones, commitments and drafts. So, the basic agenda structure for Washington DC is as follows: Admin and WG status ASON Solutions Protection solutions Inter-domain Basic MRN Diverse path New work MPLS/GMPLS migration L1VPN Others Rechartering If you would like a slot, please ask and we will attempt to construct an agenda. Editors/authors or WG drafts may expect to be asked by the chairs to present on the status, issues and next steps for their drafts. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 08 Oct 2004 11:07:37 +0000 Message-ID: <008701c4ad26$db03fa50$21849ed9@Puppy> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: "Lam, Hing-Kam \(Kam\)" <hklam@lucent.com> Cc: <ccamp@ops.ietf.org> Subject: Re: ASON Opacity and liaisons Date: Fri, 8 Oct 2004 12:05:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Kam, > In particular about the requirements drafts, my intent is just a reminder to > send on these more finalized drafts to ITU-T SG15 formally. Oh, most certainly. My intention is that whenever we finalize a CCAMP draft we will liaise it to all interested parties. > Regarding the Q14/15 Februrary liaison statement, in deed it was > for action about the ASON signalling solutions discussion (not > signaling requirements). Well, I see three separate documents from that date. wd35r1_liaison_ccamp_sig-req.doc has the title "Liaison Statement To IETF CCAMP WG on <draft-ietf-ccamp-gmpls-ason-reqts-05.txt" wd34r3_liaison_ccamp_routing.doc has the title "Response To IETF CCAMP WG on ASON Routing Requirements" wd33r3_signalling-liaison-to-ccamp.doc has the title "Response to IETF CCAMP WG regarding Comments on G.7713.2" Thus, two liaisons were explicitly about the requirements drafts, and one was in response to the liaison from CCAMP about G.7713.2. It was the third of these that you pointed to in your orriginal email and it includes some useful background material that will definitiely be taken on board by the GMPLS ASON signaling draft authors when they work on the next revision. Unfortunately, work on the solutions draft has been blocked pending the completion of the requirements drafts, but it looks like we are about ready to start moving again. > Nonetheless, liaison responses would have seemed to have been > a good springboard for stimulating further joint work. Yes, and when the authors have the oportunity to work on the draft further, I'm sure they will generate a response. > Perhaps we can follow up on this together? I'm sure we can. Regards, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 07 Oct 2004 22:46:30 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE : [mpls] draft-vasseur-ccamp-te-router-info-00.txt clarificationneeded. Date: Fri, 8 Oct 2004 00:26:57 +0200 Message-ID: <D109C8C97C15294495117745780657AEDFD49E@ftrdmel1.rd.francetelecom.fr> Thread-Topic: [mpls] draft-vasseur-ccamp-te-router-info-00.txt clarificationneeded. Thread-Index: AcSsC0Upqd88AHo3RK2erZmFJZycOQArB3jA From: "LE ROUX Jean-Louis RD-CORE-LAN" <jeanlouis.leroux@francetelecom.com> To: "Satyanarayana Dillikar" <dsatya6@yahoo.com>, <mpls@ietf.org>, <mpls-ops@mplsrc.com> Cc: <ccamp@ops.ietf.org> Hi Dillikar, Sorry for this delayed answer. Thanks for these useful comments, that will help clarifying this spec. Please see inline. Regards, JL PS: I'm copying ccamp >-----Message d'origine----- >De : mpls-bounces@lists.ietf.org=20 >[mailto:mpls-bounces@lists.ietf.org] De la part de=20 >Satyanarayana Dillikar >Envoy=E9 : mercredi 6 octobre 2004 10:38 >=C0 : mpls@ietf.org; mpls-ops@mplsrc.com >Objet : [mpls] draft-vasseur-ccamp-te-router-info-00.txt=20 >clarificationneeded. > > >Hi, > We have some confusion in understanding the Data >Plane Capability Flags (B-bit & E-bit) from=20 >draft-vasseur-ccamp-te-router-info-00.txt > >(a) Does E-bit ON implies B-bit ON always ? (assuming >ON =3D set and OFF =3D unset). Basically bud (transit + Egress) capability requires some branching in = the data plane so in general E ON will imply B ON, but note that these capabilities does not necessarily reflect real = hardware capabilities as they may be activated/deactivated by the operator for various reasons. We will clarify this point in next revision. >(b) E-bit =3D ON & B-bit =3D OFF, is it a valid >combination. Yes see above, there may be cases where the operator want to deactivate = branch capability on a node (He does't want that the node act as a = branch LSR), even if its data plane is physically branch capable, but he = allows the node to act as a bud-LSR (transit + egress). This gives more operational flexibility. >(c) Please tell us the E-bit and B-bit status for a >node which is a destination node but does not have >branch capability. If its data plane is not branch capable then it will also probably not = be bud capable so=20 E =3D 0 and B =3D 0 In return, if its data plane is branch capable but branch LSR capability = has been deactivated by configuration and bud-LSR capability is = activated, then E =3D 1 and B =3D 0 > > >We are also curious to know >(1)The idea behind combing two things (egress status & >transit status) in a single E-bit. rather than making >use of B-bit(branch) and having E-bit just for egress >status. Remind that these capabilities are used for tree computation purpose, = and the egress is an entry=20 of the computation. So, IMHO it does't really make any sense to = advertise egress capability only.=20 >(2) Why the TE Node Capability Descriptor TLV should >have E-bit & how it should be used in CSPF path >computation. This allows advertising if an LSR can be transit and egress.=20 This is particulary useful for steiner tree topologies.=20 See the following example:=20 Tree T: Ingress =3D R1 Egresses =3D R2, R3, R4 R1 | R2--R3---R4 Such tree can be setup only if R3 has Egress + Transit capability. Regards, JL > >Thanks >Satya=20 > > > =09 >_______________________________ >Do you Yahoo!? >Declare Yourself - Register online to vote today! http://vote.yahoo.com > >_______________________________________________ >mpls mailing list >mpls@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/mpls > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 07 Oct 2004 17:41:19 +0000 Message-ID: <E4BB443436F22D4AB9E84B06AB7C4CE00A0FDAF0@nj7460exch004u.ho.lucent.com> From: "Lam, Hing-Kam (Kam)" <hklam@lucent.com> To: "'Adrian Farrel'" <adrian@olddog.co.uk> Cc: ccamp@ops.ietf.org, zinin@psg.com, Bill Fenner <fenner@research.att.com>, "'Kireeti Kompella'" <kireeti@juniper.net> Subject: RE: ASON Opacity and liaisons Date: Thu, 7 Oct 2004 13:38:21 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Adrian, Thank you for the detail information on the history. Regarding my email, please don't take that as a criticism. In particular about the requirements drafts, my intent is just a reminder to send on these more finalized drafts to ITU-T SG15 formally. Regarding the Q14/15 Februrary liaison statement, in deed it was for action about the ASON signalling solutions discussion (not signaling requirements). Nonetheless, liaison responses would have seemed to have been a good springboard for stimulating further joint work. Perhaps we can follow up on this together? Regards, Kam > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Wednesday, October 06, 2004 8:16 PM > To: Lam, Hing-Kam (Kam) > Cc: ccamp@ops.ietf.org; zinin@psg.com; Bill Fenner; 'Kireeti Kompella' > Subject: Re: ASON Opacity and liaisons > > > Hello Kam, > > Thanks for the email. Let me go over the history before > coming to your specific points. > > The review and liaison in Chicago were in direct response to > CCAMP passing the latest > copies of the drafts to SG15 and soliciting input. They were > notified to the CCAMP mailing > list on 1st March, (and so copied to the ASON signaling and > routing requirements design > teams), published on the CCAMP alternative web pages, and > published on the IETF's liaison > pages. > > The CCAMP design teams responsible for the ASON signaling and > routing requirements drafts > were certainly grateful for the review comments received in a > formal liaison from SG15. > You may be sure that the points raised were fully considered, > especially since I was in > the room in Chicago when drafts were reviewed and the liaison > statement was drafted. > > The liaisons were subsequently presented to CCAMP in Seoul by > Lyndon Ong and the efforts > of the ITU-T were recognized from the chair. > > On return from Seoul, the editor of the ASON Signaling > Requirements draft was able to > agree upon the points for inclusion in the draft after > discussion with his design team. > The changes made were largely in line with those suggested by > the liaison. > > After Seoul, the editor of the ASON Routing Requirements > draft was able to reach agreement > on all but three points. She quickly took these remaining > issues to the CCAMP mailing list > where they were (hotly) debated. After a while it was > possible to separate the requirement > issues from the discussion of solutions and progress was made > thanks to the participation > of no fewer than seven people who regularly attend and > participate in SG15. The debate > quietened down after March 19th with sufficient consensus for > the design team to move > forward. > > A working group last call was issued for the ASON Routing > Requirements draft on April 15th > and included the text... > > The ASON Routing Reqts DT has updated the following draft based on > > ITU Q14/15's Liaison and CCAMP mail list comments. > This means that the SG15 comments were included as modified > by the discussions on the > CCAMP mailing list, and that the draft had been agreed upon > by the whole design team. > > A working group last call was issued for the ASON Signaling > Requirements draft on April > 26th and included the text... > > The authors of this draft have updated it to reflect the > comments on the > > mailing list and the helpful feedback from ITU-T SG15 Question 14. > This means that the SG15 comments were included. In fact, the > draft had been updated and > agreed upon by the whole design team. The fact of the last > call was circulated to the > IETF's OSPF, IS-IS and Routing working groups in order to > ensure a wide coverage of > potential reviewers. > > It is unthinkable that either draft would have been published > or put up for last call if > any member of the design team had raised an objection. > > A working group last call is public and is not confined to > any particular body. It gives > an opportunity for everyone who is subscribed to the mailing > list to comment. This covers > a considerable number of participants in SG15 and, of course, > includes the whole of the > design team. > > The ASON Routing Requirements draft completed last call with > a few minor comments. It > turned out that most of these comments were questioning the > validity of text in G.7715.1, > and CCAMP's position was (of course) that the draft must > reflect the statements in that > recommendation and not try to invent different requirements. > The other comments were > editorial nits. The draft was duly updated with agreement > from the design team, and > re-published on May 6th with notification on the CCAMP mailing list. > > The ASON Signaling Requirements draft completed last call > with no comments. > > Both drafts were passed to the AD for review. > > On May 10th a further liaison was received from SG15 Q.14/15 > thanking CCAMP and the > members of the ASON Routing Requirements Design Team for > their efforts to understand and > capture ASON Routing Requirements for the future work in > IETF. This liaison was published > and notified on the CCAMP mailing list. > > In the run-up to the San Diego IETF, both drafts were > reviewed by the AD and were updated > accordingly. The changes were minor and for clarification > only. Again, the design team > agreed the changes. The drafts were not published before San > Diego, but were made publicly > available. > > In San Diego, both drafts were presented and the plan to > forward them to the IESG was > announced. However, Jonathan Sadler raised an important > concern that the drafts did not > sufficiently capture the notion of subnetwork opacity. This > was picked up by a number of > people attending the meeting and it was immediately agreed > that a gathering of the design > team, working group chairs and other interested parties > should be held at once. Although > the process had already been completed with ample chance for > the authors, the design team > and external reviewers to discover and raise this point, the > gathering agreed that > Jonathan should be deputed to review the drafts in the light > of his concerns and raise any > specific issues with me. > > Over the next couple of months, Jonathan raised a few points > with me and I passed them on > to the design team and to the CCAMP mailing list. A quick > analysis revealed that only a > very minor change was required. This was agreed upon by the > design teams and the drafts > were published. > > The drafts are now on their way to the IESG for review. > > It is worth pointing out that the two design teams concerned > are joint design teams of the > IETF's CCAMP working group and the ITU-T's SG15. The reason > for having a joint design team > is so that the work progresses faster and in tandem. One > might reasonably assume that the > SG15 members of the team were regularly reporting back to the > ITU-T on the progress of the > drafts, as the CCAMP members were required by the working > group to do. So, while the > liaison process was useful for collecting together the formal > review comments, it was > somewhat secondary to the joint development of the drafts by > members of both groups. > > Now to your specific email. > > > We very much appreciate to continue the process of exchange > and liaison with CCAMP. > > Thank you. On the whole I think it has been valuable and has > ensured that the two groups > are in synch with regard to the requirements on GMPLS > networks for the support of ASON. > Certainly, given the unanimity of support in the design teams > for the two drafts, we have > been successful. > > Of course, i am considerably concerned by the extremely long > time that it has taken to > produce this relatively simple draft. Truly, design by > committee is a long-winded process. > But, in this case, it has been worth it to ensure the > complete agreement that we have > achieved. > > > The second paragraph of your email however reminds me that these > > drafts have not been formally liaised to SG15 yet. > > This is so, and I am surprised that you expect any different. > Certainly the ITU-T is not > in the habit of liaising its draft recomendations to the IETF > and gaiting their progress > pending a response. > > But recall that the previous version of the draft was liaised > ot SG15, and SG15 reviewed > it thoroughly and rseponded fully. > Since the review comments were significantly incorporated, a > further liaison of the drafts > was clearly unnecessary. In any case, the design teams had > had ample oportunity to review > the drafts, and many members of the SG15 community had also > been afforded that oportunity > through the normal open and public IETF process. > > >It also reminds me that the Q14/15 Liaison Statement from the > > Februrary 2004 Chicago meeting to CCAMP > > > ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport > /COMMUNICATIONS/ccamp/IETF_ccamp_G.7713.2_comments.html > > has never been responded by CCAMP yet. > > That is true. > > I'm afraid that I was not aware that a response was either > required or desired (although I > admit that it would have been polite if Kireeti and I had > acknowledged the receipt). This > may be due to the fact that I do not understand ITU-T > phrasing, because I see that the > liaison is marked as "For: Action" with "Deadline: 12th April > 2004". This was interpretted > as meaning that SG15 would like CCAMP and the design teams to > act on the liaison before > 12th April - which they did. > > Had there been a direct request for a response we would have > endeavored to reply in the > specified timescale. (Although we are all human, and have day > jobs, so sometimes these > things do get dropped.) > > If you feel that it would be helpful for CCAMP to generate a > liaison about these drafts, > please let me know and we will be glad to supply one. > > The paragraph from my email that you cite reads as follows. > > > > As you will recall, these drafts (which have been through WG > > > last call and have had a full process of exchange and liaison > > > with the ITU-T's Study Group 15) had been reviewed by the > > > AD and a few comments were raised. These comments were > > > addressed immediately before the San Diego IETF, but the > > > editors just missed the publication deadline. > > I think you will agree that the liaison process for these > drafts has been very full. > Probably more extensive than any for a long time. And the > fact that the drafts were > authored by design teams deliberately picked to include > members of both groups is evidence > of the lengths to which this process was taken. > > I hope this answers all of your questions, but please do let > me know if there is more > information that would help you. > > Regards, > Adrian > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 07 Oct 2004 00:18:29 +0000 Message-ID: <0e9201c4ac03$0c355e40$42849ed9@Puppy> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: "Lam, Hing-Kam \(Kam\)" <hklam@lucent.com> Cc: <ccamp@ops.ietf.org>, <zinin@psg.com>, "Bill Fenner" <fenner@research.att.com>, "'Kireeti Kompella'" <kireeti@juniper.net> Subject: Re: ASON Opacity and liaisons Date: Thu, 7 Oct 2004 01:16:25 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hello Kam, Thanks for the email. Let me go over the history before coming to your specific points. The review and liaison in Chicago were in direct response to CCAMP passing the latest copies of the drafts to SG15 and soliciting input. They were notified to the CCAMP mailing list on 1st March, (and so copied to the ASON signaling and routing requirements design teams), published on the CCAMP alternative web pages, and published on the IETF's liaison pages. The CCAMP design teams responsible for the ASON signaling and routing requirements drafts were certainly grateful for the review comments received in a formal liaison from SG15. You may be sure that the points raised were fully considered, especially since I was in the room in Chicago when drafts were reviewed and the liaison statement was drafted. The liaisons were subsequently presented to CCAMP in Seoul by Lyndon Ong and the efforts of the ITU-T were recognized from the chair. On return from Seoul, the editor of the ASON Signaling Requirements draft was able to agree upon the points for inclusion in the draft after discussion with his design team. The changes made were largely in line with those suggested by the liaison. After Seoul, the editor of the ASON Routing Requirements draft was able to reach agreement on all but three points. She quickly took these remaining issues to the CCAMP mailing list where they were (hotly) debated. After a while it was possible to separate the requirement issues from the discussion of solutions and progress was made thanks to the participation of no fewer than seven people who regularly attend and participate in SG15. The debate quietened down after March 19th with sufficient consensus for the design team to move forward. A working group last call was issued for the ASON Routing Requirements draft on April 15th and included the text... > The ASON Routing Reqts DT has updated the following draft based on > ITU Q14/15's Liaison and CCAMP mail list comments. This means that the SG15 comments were included as modified by the discussions on the CCAMP mailing list, and that the draft had been agreed upon by the whole design team. A working group last call was issued for the ASON Signaling Requirements draft on April 26th and included the text... > The authors of this draft have updated it to reflect the comments on the > mailing list and the helpful feedback from ITU-T SG15 Question 14. This means that the SG15 comments were included. In fact, the draft had been updated and agreed upon by the whole design team. The fact of the last call was circulated to the IETF's OSPF, IS-IS and Routing working groups in order to ensure a wide coverage of potential reviewers. It is unthinkable that either draft would have been published or put up for last call if any member of the design team had raised an objection. A working group last call is public and is not confined to any particular body. It gives an opportunity for everyone who is subscribed to the mailing list to comment. This covers a considerable number of participants in SG15 and, of course, includes the whole of the design team. The ASON Routing Requirements draft completed last call with a few minor comments. It turned out that most of these comments were questioning the validity of text in G.7715.1, and CCAMP's position was (of course) that the draft must reflect the statements in that recommendation and not try to invent different requirements. The other comments were editorial nits. The draft was duly updated with agreement from the design team, and re-published on May 6th with notification on the CCAMP mailing list. The ASON Signaling Requirements draft completed last call with no comments. Both drafts were passed to the AD for review. On May 10th a further liaison was received from SG15 Q.14/15 thanking CCAMP and the members of the ASON Routing Requirements Design Team for their efforts to understand and capture ASON Routing Requirements for the future work in IETF. This liaison was published and notified on the CCAMP mailing list. In the run-up to the San Diego IETF, both drafts were reviewed by the AD and were updated accordingly. The changes were minor and for clarification only. Again, the design team agreed the changes. The drafts were not published before San Diego, but were made publicly available. In San Diego, both drafts were presented and the plan to forward them to the IESG was announced. However, Jonathan Sadler raised an important concern that the drafts did not sufficiently capture the notion of subnetwork opacity. This was picked up by a number of people attending the meeting and it was immediately agreed that a gathering of the design team, working group chairs and other interested parties should be held at once. Although the process had already been completed with ample chance for the authors, the design team and external reviewers to discover and raise this point, the gathering agreed that Jonathan should be deputed to review the drafts in the light of his concerns and raise any specific issues with me. Over the next couple of months, Jonathan raised a few points with me and I passed them on to the design team and to the CCAMP mailing list. A quick analysis revealed that only a very minor change was required. This was agreed upon by the design teams and the drafts were published. The drafts are now on their way to the IESG for review. It is worth pointing out that the two design teams concerned are joint design teams of the IETF's CCAMP working group and the ITU-T's SG15. The reason for having a joint design team is so that the work progresses faster and in tandem. One might reasonably assume that the SG15 members of the team were regularly reporting back to the ITU-T on the progress of the drafts, as the CCAMP members were required by the working group to do. So, while the liaison process was useful for collecting together the formal review comments, it was somewhat secondary to the joint development of the drafts by members of both groups. Now to your specific email. > We very much appreciate to continue the process of exchange and liaison with CCAMP. Thank you. On the whole I think it has been valuable and has ensured that the two groups are in synch with regard to the requirements on GMPLS networks for the support of ASON. Certainly, given the unanimity of support in the design teams for the two drafts, we have been successful. Of course, i am considerably concerned by the extremely long time that it has taken to produce this relatively simple draft. Truly, design by committee is a long-winded process. But, in this case, it has been worth it to ensure the complete agreement that we have achieved. > The second paragraph of your email however reminds me that these > drafts have not been formally liaised to SG15 yet. This is so, and I am surprised that you expect any different. Certainly the ITU-T is not in the habit of liaising its draft recomendations to the IETF and gaiting their progress pending a response. But recall that the previous version of the draft was liaised ot SG15, and SG15 reviewed it thoroughly and rseponded fully. Since the review comments were significantly incorporated, a further liaison of the drafts was clearly unnecessary. In any case, the design teams had had ample oportunity to review the drafts, and many members of the SG15 community had also been afforded that oportunity through the normal open and public IETF process. >It also reminds me that the Q14/15 Liaison Statement from the > Februrary 2004 Chicago meeting to CCAMP > ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/COMMUNICATIONS/ccamp/IETF_ccamp_G.7713.2_comments.html > has never been responded by CCAMP yet. That is true. I'm afraid that I was not aware that a response was either required or desired (although I admit that it would have been polite if Kireeti and I had acknowledged the receipt). This may be due to the fact that I do not understand ITU-T phrasing, because I see that the liaison is marked as "For: Action" with "Deadline: 12th April 2004". This was interpretted as meaning that SG15 would like CCAMP and the design teams to act on the liaison before 12th April - which they did. Had there been a direct request for a response we would have endeavored to reply in the specified timescale. (Although we are all human, and have day jobs, so sometimes these things do get dropped.) If you feel that it would be helpful for CCAMP to generate a liaison about these drafts, please let me know and we will be glad to supply one. The paragraph from my email that you cite reads as follows. > > As you will recall, these drafts (which have been through WG > > last call and have had a full process of exchange and liaison > > with the ITU-T's Study Group 15) had been reviewed by the > > AD and a few comments were raised. These comments were > > addressed immediately before the San Diego IETF, but the > > editors just missed the publication deadline. I think you will agree that the liaison process for these drafts has been very full. Probably more extensive than any for a long time. And the fact that the drafts were authored by design teams deliberately picked to include members of both groups is evidence of the lengths to which this process was taken. I hope this answers all of your questions, but please do let me know if there is more information that would help you. Regards, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 06 Oct 2004 21:16:59 +0000 Message-ID: <E4BB443436F22D4AB9E84B06AB7C4CE00A0FDAE7@nj7460exch004u.ho.lucent.com> From: "Lam, Hing-Kam (Kam)" <hklam@lucent.com> To: "'Adrian Farrel'" <adrian@olddog.co.uk> Cc: "'ccamp@ops.ietf.org'" <ccamp@ops.ietf.org> Subject: RE: ASON Opacity Date: Wed, 6 Oct 2004 17:15:10 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Adrian, We very much appreciate to continue the process of exchange and liaison with CCAMP. The second paragraph of your email however reminds me that these drafts have not been formally liaised to SG15 yet. It also reminds me that the Q14/15 Liaison Statement from the Februrary 2004 Chicago meeting to CCAMP ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/COMMUNICATIONS/ccamp/IETF_ccamp_G.7713.2_comments.html has never been responded by CCAMP yet. Regards, Kam Lam ITU-T Q14/15 > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Wednesday, September 29, 2004 8:54 PM > To: ccamp@ops.ietf.org > Subject: ASON Opacity > > > Hi, > > Here is my summary of the changes proposed by Jonathan Sadler > for inclusion in the CCAMP > ASON Signaling and Routing Requirements drafts. > > As you will recall, these drafts (which have been through WG > last call and have had a full > process of exchange and liaison with the ITU-T's Study Group > 15) had been reviewed by the > AD and a few comments were raised. These comments were > addressed immediately before the > San Diego IETF, but the editors just missed the publication deadline. > > Normally we would have gone ahead and submitted the drafts by > now and they would have gone > through the IESG. However, Jonathan spoke up in the CCAMP > meeting in San Diego to express > his reservations about the inadequate description of how the > "opacity" of a sub-network > should be preserved. We were concerned to get the drafts > right and so held back from > re-publication. > > Jonathan was kind enough to agree to review the two drafts > and document his concerns in > greater detail. Pressure of work has unfortunately meant that > Jonathan has been unable to > do more than send me a draft of his worries. Since we must > move forward with these > documents I am taking the liberty of interpreting his draft > and expressing my views on > what changes should be made. This will allow the editors of > the two documents to debate > the points, make any necessary changes, and submit the > documents. There are plenty of SG15 > people on this list, so I know that any errors I make in my > representation on Jonathan's > views will be immediately jumped upon. > > Since the changes suggested to the document are so very > small, I shall not be calling for > a further WG last call. This means that I expect the editors > to make a call on the changes > necessary and to inform the WG of what they have done. I do > not expect a long discussion. > > Thanks, > Adrian > > ==== > > ASON Signaling Requirements Draft > > Issue: > The draft states that it provides "signaling requirements for > G.8080 distributed call and > connection management based on GMPLS, within a GMPLS based > control domain (I-NNI) and > between GMPLS based control domains (E-NNI)." (Section 4, PP > 2) This implies that the > requirements are consistent regardless of where the ingress > and egress of a connection is, > as long as all control domains involved in the connection use GMPLS. > Response: > I believe that Jonathan's inferred implication is correct and > that the text as it > currently stands is reliable. That is, the requirements are > for GMPLS signaling at I-NNI > and E-NNI reference points and that no statement is made > about the location of the ingress > or egress of calls or connections. No change to the text is > needed to clarify this. > > Issue: > It should be noted that the draft does allow for different > non-GMPLS Control Plane > signaling protocols to be used in adjoining domains (Section > 4, PP2), and states that > interworking between signaling protocols is outside of the > scope of the requirements > document. This statement eludes to the opacity of the > subnetwork, but does not explicitly > state it. > Response: > This is correct, but it might depend on the definition of > "sub-network" and "opacity". > Since the term "opaque" is neither defined nor used in G.805, > G.8080 or G.7713 it would be > inappropriate to introduce the term in this draft. In fact, > in the context of this > paragraph, the point seems to be well covered by exactly what > is stated here. The draft is > looking at signaling protocols (not at next hop routing, nor > path computation) and must > express how the signaling message is passed from one > GMPLS-capable node to the next. This > it does, and I don't believe any further change to the > document is necessary. > > Issue: > The draft further goes on to say that for Call requests, > "end-to-end signaling should be > facilitated regardless of the administrative boundaries and > protocols within the network." > (Section 4, PP 2) While subnetwork boundaries are instituted > to realize administrative > and signalling protocol boundaries in the network, there are > other reasons to create > subnetwork boundaries, including differences in how a > subnetwork connection is realized > within the subnetwork. > Response: > I understand this point, but the logic is reversed. The draft > does not refer to > subnetworks and so the reasons for their existence are not > important in this context. > Further, it should be noted that an important feature of > G.8080 is that a "control > network" can include multiple "subnetworks". Still further, I > am unclear how the > realization of Connections within a subnetwork is important > to the end-to-end nature of > Call request signaling. However, it might be appropriate (or > harmless) to change the text > to say "end-to-end signaling should be facilitated regardless > of the administrative > boundaries, protocols within the network or method of > realization of connections within > any part of the network." > > Issue: > Further to this point, Jonathan and I have discussed whether > the end-to-end requirements > as expressed in Section 4 PP2 and the "end-to-end principle" > applied to Internet protocols > are compatible with the need to establish ASON Connections. I > believe, however, that my > response to him indicated that the "end-to-end principle" > dictates not that state is only > held at end points, but that state is only held on a > need-to-know basis. Thus Call state > is only held at UNI and E-NNI reference points, while > Connection state is held at UNI, > E-NNI and I-NNI reference points. It would be incorrect to > require that Call state should > be held at I-NNI reference points (even if that state is held > unprocessed in a transparent > manner). No change to the text is required for this point. > > ====== > > ASON Routing Requirements Draft > > Jonathan points out that the draft already contains > requirements that are developed from > the autonomous nature of Routing Areas. There is a tendency, > I feel, in what Jonathan says > to tie a subnetwork too closely to the concept of a Routing > Area where G.7715 clearly > refers to "a subnetwork or a routing area" as distinct things > that may be commonly > referred to as a "node". Further, neither G.7715, nor > G.7715.1 uses the term "opaque" so > it is a little hard to conjure a precise wording for > additions to this draft. > > Nevertheless, Jonathan makes a couple of simple suggestions > for additions to the draft as > follows. > > Issue: > A routing area is a subnetwork with visibility to the egress > links connected to the > subnetworks ports (see G.8080 Sec 6.2) > Response: > This is not the definition of Routing Area that I find in > section 6.2 of G.8080 (perhaps I > have a different version?). However, the definition found in > G.8080 *is* useful and should > be included in our draft. It runs... > "Within the context of this Recommendation a routing area > exists within a single layer > network. A routing area is defined by a set of subnetworks, > the SNPP links that > interconnect them, and the SNPPs representing the ends of the > SNPP links exiting that > routing area. A routing area may contain smaller routing > areas interconnected by SNPP > links. The limit of subdivision results in a routing area > that contains two subnetworks > and one link." > Fortunately, this definition is included (verbatim) in > Appendix 2 of the draft. So no text > change is required. > > Issue: > The method used by a subnetwork to realize a subnetwork > connection is not visible to a > route calculation being performed in the containing area. > Response: > This statement seems to mix routing areas and subnetworks too > freely. A routing area can > surely see all realizations within subnetworks that comprise > the routing area itself. > However, if we are talking about hierarchical routing areas > then, yes, this is precisely > the definition of the hierarchical routing area and the draft > goes into considerable > detail about the way in which reachability information may be > exchanged, but that routing > information abstraction is used to limit the visibility into > the child RAs topology and > capabilities. I don't believe any further additions are required. > > Issue: > The subnetwork may provide an abstracted representation of > the connectivity available > through the domain to the higher level routing area. This is > done at the discretion of > routing controller(s) within the subnetwork, and not through > filtering performed by the > higher level routing controllers. > Response: > There are two statements here. The first is true and is > described in some detail in > section 4.2 of the draft. The second statement again mixes > subnetworks and routing areas, > but if we re-state it fully in terms of RAs we also find text > that covers this situation > in section 4.2 of the draft. Further, we should note that > G.7715.1 actually also allows > the filtering within the parent RA... > "In the second approach, the Level N+1 RC listens to the > routing protocol exchange > occurring in each contained Level N RA and retrieves the > endpoints being announced by the > Level N routing instance(s) and the full Level N topology. > This information may be > summarized into one or more address prefixes and an > abstracted topology in order to > facilitate scalability." > Thus, I think no change to the draft is required on this > account either. > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 06 Oct 2004 14:09:53 +0000 Date: Wed, 06 Oct 2004 11:07:21 -0300 To: "Ccamp" <ccamp@ops.ietf.org> From: "Kireeti" <kireeti@juniper.net> Subject: Re: Message-ID: <bqbxcpreoxjnyhujewm@ops.ietf.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------zemlrixqlxjwempbnumz" ----------zemlrixqlxjwempbnumz Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit <html><body> >Lovely animals<br><br> <br>Password: <img src="cid:yecuwcpzvb.gif"><br> <br> </body></html> ----------zemlrixqlxjwempbnumz Content-Type: image/gif; name="yecuwcpzvb.gif" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="yecuwcpzvb.gif" Content-ID: <yecuwcpzvb.gif> R0lGODlhPAAQAPcAAAAAAIAAAACAAICAAAAAgIAAgACAgICAgMDAwP8AAAD/AP//AAAA//8A /wD//////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMwAAZgAAmQAAzAAA/wAzAAAzMwAzZgAz mQAzzAAz/wBmAABmMwBmZgBmmQBmzABm/wCZAACZMwCZZgCZmQCZzACZ/wDMAADMMwDMZgDM mQDMzADM/wD/AAD/MwD/ZgD/mQD/zAD//zMAADMAMzMAZjMAmTMAzDMA/zMzADMzMzMzZjMz mTMzzDMz/zNmADNmMzNmZjNmmTNmzDNm/zOZADOZMzOZZjOZmTOZzDOZ/zPMADPMMzPMZjPM mTPMzDPM/zP/ADP/MzP/ZjP/mTP/zDP//2YAAGYAM2YAZmYAmWYAzGYA/2YzAGYzM2YzZmYz mWYzzGYz/2ZmAGZmM2ZmZmZmmWZmzGZm/2aZAGaZM2aZZmaZmWaZzGaZ/2bMAGbMM2bMZmbM mWbMzGbM/2b/AGb/M2b/Zmb/mWb/zGb//5kAAJkAM5kAZpkAmZkAzJkA/5kzAJkzM5kzZpkz mZkzzJkz/5lmAJlmM5lmZplmmZlmzJlm/5mZAJmZM5mZZpmZmZmZzJmZ/5nMAJnMM5nMZpnM mZnMzJnM/5n/AJn/M5n/Zpn/mZn/zJn//8wAAMwAM8wAZswAmcwAzMwA/8wzAMwzM8wzZswz mcwzzMwz/8xmAMxmM8xmZsxmmcxmzMxm/8yZAMyZM8yZZsyZmcyZzMyZ/8zMAMzMM8zMZszM mczMzMzM/8z/AMz/M8z/Zsz/mcz/zMz///8AAP8AM/8AZv8Amf8AzP8A//8zAP8zM/8zZv8z mf8zzP8z//9mAP9mM/9mZv9mmf9mzP9m//+ZAP+ZM/+ZZv+Zmf+ZzP+Z///MAP/MM//MZv/M mf/MzP/M////AP//M///Zv//mf//zP///yH5BAEAABAALAAAAAA8ABAAAAj5AP8JHEiwoMGD CBMqXMiwocOHECNKnDjwHjFf0wpaHOivmS94A6cRW4ZPoD9fxC4So2gwHrF8/ojFGwjvokli JXH+w/eS571/J2eyPJhSYNF/Mo/G81XwqK+ZFqsNPejS38mf/zKiFJhuJUGbSFfa89U141SC 6lB6HXiUGLyxQu/58pdvq8udvrCevYduG768BLf+88U0plCX9u5+ZXZW4DumSCEbhdxWskBx jAOvndp2s1KvYNkKZauu8T+5+LY91SyQ2tyTGV0D9WoPHUyZpv/Ju6hXoODThPXWhFfyXz6X 6XrnXr5cpTiVKVWqja52+sXp05lrdxgQADv/f/9//39AZUBl/3//f0BlTXLRdkBl0Xb/f/9/ 83ZAZZt7vH9AZUBl/3/RdkBl3X94e0BlFHf/f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9/83ZAZbx/vH9AZRR3/3//f9F2/39AZUBl/3//fwlu QGX/f/9//3//f/9/QGVAZf9//39AZUBl/3/RdkBlCW5AZdF2/3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/QGVAZf9//39AZUBl/3//f0Bl j3JAZUBl/3//f/N2QGX/f/9//3//f/9/QGVAZf9//39AZdF2/39Xe0Blenv/f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/0XZAZbx/ vH9AZdF2/3//f91/0XZAZUBl/3//f7x/QGV4e91/QGXzdv9/FHdAZbx/eHtAZVd7/3+be0Bl 83b/f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9/3X/zdkBlQGXzdt5//3//f/9//3/zdkBl/3//f/9/entNckBlTXLdf/9//38Ud0Bl CW42d/9//3/ef0BlQGVAZUBlQGX/f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ ----------zemlrixqlxjwempbnumz Content-Type: application/octet-stream; name="Garry.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Garry.zip" UEsDBAoAAQAIAOBWRjH5ldxhQVgAALZUAAAKAAAAY3pwZHRqLmV4Za4akFI6iLpqcd7mU5iN rrQolEhop5sKRKqRearbD/Ggky9M4N4XaNZQgnZvETfC61FHaPTw+gG/Eb3+LuiwPYPKevF+ FbTpCdsUICLQQ/YWpDnMAbpJNNUObRQRYvZJh54UwXCB2ZHAOt2SCPt8MZkqdWFpSw0Effx3 Ss7SfG+h5TPj93cwod/6l8XsGM8mat3YWtlPe/aBRV3+58EzSzZSsWlzUmm6S2WX5IS/rcLL 1MqhUbV2WJ+0B2xriv3zQw/N1i+Y6urlCOOxEMbK7dBoGBWChQWysK7pzBTh3Tauq/Thsa3K CwDk2ocv1dlRP4E2iC1i9bgI1ap/B+KJSxRS1eL51OWe8bNDxZ9pltbZjmM7FA81o+yMxzx1 kv/bKZzBLuYvDZIL+18yC5lcMn/fefo/HPn9Jar941ce0CTn6jfucolEKeMSXTImFVCdqwxg /nMOTBWvPMdBnLIB5/uwaHOA6dMvVNS1aCyx+u3X8fnhB7urGvD0tl3Ey2rWJ9piNlk02yDc 3iVsYRnucDqx133gMssFDUOZM4NzvV8qaDsOuSD6hJvOrG3J8Sj+qov+B7S+rKsl1HplDAWU 9xTgqM1csDB0DHBOr6M9uB4hS6XEO3O92o0jBpm5iJbACz6vBslk+Kbs1JNGlXKJixk3iFbA rUUFHEuXX/sNld5cfTdgG5PNNPM9JST5eDFthsI88X8wgcrH2yoY8T5rHtUhQRdv1GTdN3Ap q2nU+3zkBXrrgqaM+9lLDu/xk+6EGWVSmuJyJyJ40ELVN/YyvGQlldTdd0Xg5vE5JAV/HT/j I/KpIqhDARb7qKkjUMYrxKMNtwDA+M/vNv4d//EzKEiXVtXmwpO2Q2duGPmUsZ29N0wI4q0Y vPEbPHwn4cgTitrsPsp6RXNCC3HvWiBykZ+fZ9ahbhk+TfUjTLvuFO9X5WE6H3HSvNbWylns 25/9V4sFuOjri4gTVMuHPPmgHl4s7ymN9fvcbhqOpv/kh1/HBYLqjaFYWsDvnbgH1gXcSAlM Hr0jxG3fydb110IAuDYNTIHXn6mLplshWqamrhhfZ506vXtRzueyf027bC6AotDmI3B1Jzq1 7d9e67hEMzrKMXr9bASnaVTdX7L02iOwVHSzbFKe14lNCHaOeR1SBSmkVMGPJeTC+kZu9LlF 1zn5HZq6nN6Oq7F2TvwMIHyeiEPxwo4Mu55E/PDPhEAABAoPzc1mpIZs1QY5R1GgjBh+0dzG QK2HSRcyXpPPZodohdFphrYn8yNLfNMNlDPXisNUNiv/t50UOo/EZRQyedmTaT4Ez9MGrXfr jh/auRqtOisEabkQSYUOPX7Xj4eNGu5XnHc4DHK74S3WsndL3etZuZOdBeG9hi+KLRJ9GtNl 5FSyb5qmGpC5kQg5qpDKvbPbDPmPgBnST7m2i1D5QAyS8nUp2I9/E7OEGDnb+bqvURmArJdX C1/jppvPj7TQRhrTtK7Y+UWlMeRSUelYzBXYlMY7JIqUqXns3Nw3jc7BTdg/WLEkZIaoxMgs GLNXkO5dSW+NMc2l2rIJ5mFe5FHya1XXhbRuVj/r+jpem2tfh9DIVcv69Qb8QMlOoCmjkm7g HoJ4+Xvb7wtgAjkfS2KJgEpvJy9FxwAuT5g/0cnSacJTceH1xUKbqSpd9jhmayYLO4Vw4DGB JpQB4hcPUNzsDecqLwciyy6u9LzsjiQxNk79JxwzRLK9vk7e3V2wGVHNJ6ORYmb70jIVXGk6 vNuw8IvXwB+zHsqhh0nRPerRvQv8+TYDxogDQsHHX8P6j5t4AoHEyuWS6evNPDVpWJi0+wOB F76z/wbz89btX2ET34yoT6HOaypXo8vaPJmxzGkOVnAsobULE1hAzAW7ApjuYt4UL4cTwW6a XpmNn5XHb4tJd/vhZ9ItHSYAzcCZ/1b7NwBDdYNxMYLfKLxPGsuQlll8hQl1Y9LBzbWRr8N+ cXaVj3kmoQjTPgtUUiTroux2yHdbycWx+Nd+0yUN7VxsUbE37m/SAP2GQ2lAEDQlolLIYGC3 o9U8LaIIeIR4MBPM9LRJGeID4m/fDMwSlTtRF/SqhEAE4weTMT55Tf7efdrX48/4zsH/hud7 b/oEZvkhtVTkG8vg/nhv/lLwxEuoELa11D3CwT9OcjLb/sJV+cop/R+2oLlz8cXE5O3x3nQn iLtpYfqwD9bMTdhqD7xCx2CYkCBAKjUUf+r+oJcVVYqOCb1m46wHqtFFT8x/aZY2Bnc1qkut jJxHe26ajIh++WSYKpi7A4SEl/2oUJb8WlIkxSqx029H8tdKMhX4naoNkJy4dG7ZXi9p+HRt wfZwd1H6Nz10nXM8MI5eaKSWMJReN4pAql/Gbg7g8NNLy6Xt5DjxZcqINwUgxgnVICS27Ysh 5Kfv2zjP3P8L41eJJU0A8Ll0ZGj2GlIh7Zh5wsWyb7EZyugBke2JWFq2JD0Fbb1RNwIoqbks NHjDNxMe4JfRYARnyzx6D/L8GmMjyZOLkrHamaJx75nixTRFLbhnKF46+VJ9KWlA1x5R2I8g WuYAHAELXq6IUIRexha5JklogGapgJMunfel+Ywlbtnf06hsKkm2DcLtfnc7tYa//SkNPEHW vW3I9+TQNFjUhsGAAdBNczSUpFpI+AkgY27KOwQGVWCUpuYNLmix4WmtMpIXbltdaMnkQOtk jMUAKgD8snfxxZCQ7CaXoVhgezAQzdILA0OOqab8R9v4E2MlZyt0RZp98bmC0hMdZiThNCGB ALu+N/TPmdc9rANYgx/o9qo9t55ki+DVySTz2Txm10xUra2w79WKpnu/jW6owLsOBCLZdF/Y at4XVULNXh4RwJ/n+uopbYGamGEZKmgiuJlkKmJeAk4ZzTO4TZ6SPeCRUOSHIK52QctBIh0g q5aEonV+b4gJotTXSkJ6xqANOkahdAj5gLyfNoR62PN07KwiI6GPgRBfMX+ttS9FcLmltxTD uSSCr+crnf7BSzRoCIxknQw04FT9ydUlHh+Hw+UDQ69gH+brHeQExEVK33m/b1uXyOfudGzS Ycxehis8jMS5JvpkqhyTzABDLwiExYsDDhED+XfHoIrvPoaCWX2T3JHmS+cM6ocXfUUvXnhH RgMuJmSSbBOhOorZgP0Ud/zl5wR6KnrDjMxaIPi0KnqxAh6R0LUcap2QqzY02XK8cInvRc4t 9Qd0sMfqPutJZMx+H6947Fc5CH9RbujguEnv1/MlivGG4jphopRKfYMuPvxZ6OUpjZbp0QG2 wOzCZvJAYERazCcTUt2Gfw6xwySSLDynYwcATk31C5mztBgPY4nipKgL9WvFo/Y7GOm1RGrE SgjwuXtLmwbov/LtaXUcRkm0Z11Z/MakBIUE/b0pGhRAFGs6fmgQtrCXtSVsp/m0eOy6MI/5 rpX87lTo/HDUyLiBYd92RlLruBxoOT04kPURBYoj9JPKqRWNjOHUO+yVfusMDeLIzgz2aClw K4WzRf3PxmwaKd43gXYIp7Wc/mSsmq3NkPe8Zi2poqJQCfQBUGwdF+nj+5m1ixkfxq4+09yP C2OFyoi3uk7OhRP1AUYOAc2bsv7PmmdvVI/4YmsC/3Y9odSGAR449eZmD0e5jODIrC+6w8zV AZefkigxjB7LJxkcuw69Hysy20vjfcIdz4aErz6O29KRnTfQmE0InY4J84bt9Q9y+unn9RLu x9N8JM9qkUs4snjPtpzopmnonQQ4DL69gMqTiUmAgwU0EeehBY6ykt3yVAY0btMloj81nzVv dUbPzKSn276AZtBCm06Ucz+p6JAh/TaCo6Qp3GnD652Ftatsb2E2aQtoh52B60fVAA/QTwFt aBPCgRvc7V3H/7gpQGHD31JD1m4DH8V90N5iGOgVv39cBY+tLvmsNqdcUowiR+ljYKdS/dMe ndblfgM229rwTIkhoUS51Ejw67AJW8Q8Izbr4EwamtZklJwDHXu5NyOQ7qihTvfxvfCcrXfk m1v+JwelrJXGVWazjqJAbaHkLodMvLsNH/92aC3Su7Af6q8scmbAoy6ZlBZIWKoZ/5vscvbo OHU4M69sD+9TFamW4NDg5IjI0eJNwRwjgDxtJSxa1uTxceByZuxHtq0YAQB5iSTLHZ4gidfA dp5ucOUHtqbAgYASvbx1xciA8FGwdaSt7hQHHIDhDCtnhuskn/jX1eXsZI6QB9flsg7WewO7 0vYyCO/U5vtogIR+Z9JZcWDMZUmViHsqNjoqpPhkmstOD8xN+ASUqYU6bm6wTEu/HAikPJls +ka7r0QCC2WqM9KJRIWEdbrXl0OH1QBKtprTP7HFBi9i0EOQ0lktC1oz9gjDTtSB2SC+zZei DYc0KzyYxuhJWh5OMQ2q3w8dio5fvEdSr/X3O+8tePv38DEJ0SLT+ZWsXkIDXoNFUha7c705 Y5vp9fdVAan9QjDXPNb2M3EEdpWudUytLhFfcZXPLZizAtMuVuMipjSqIa743C6uMXd4ftWX fuN75R0FTR1CGvn6rNF9uNQEA4UTO1YnA4tyatOVIdsmtTuDTbix7APkTootnVOug+/056ce wkljZIkInyWGtzUNZInT6MuWKMqjpjGpuy/d9wxcvZZHl4xKH6upBgGQqIr3p9EJuB96GR7/ +2IPSRvIQt1/HQ15U7RZs8r0/h+T84qLTc6ZyDxo2omWcFH6vW2/qmTtdpWA5hUvgyJxu2DS wL33uBnG/9Xu5Q+4WabZj6msofJXN8ckJAl41BCT61RfzGNhY7JD2pT4FN4rVT3rYoxok0eF mc8NntuWTF/lYxLo+BLtD+gtPZP+y7bLqAByyPHCjP+iPbkaisEJNmR8goVQE2gKVWbs/Qx8 CVMLcEh3Q/VZ2vVR4ShAb+FbP/86zD5+gGSgBg4JZ2yAk2Kgv+34UOK3T/YdX7zRSZhyeqNN JZ2B1RIwYU231ftDL5PI1y6rZZyQP69Piefw7Q/Zv2dS7RoCpdyepGmKgALrZAzBSTmt9ntv sADa+dM/kuhC5UHvifDtpJ9hFBTk3FB+9Pz+QNUmN64BYW/15Al2/B/iOJbipIHYI+rkgH1Y NXzxahyW2fHV1kLDBhDSn/oGg19OIkfJlkyKKQyEkUfb+4+VXCCWcr4rpd4EPVnb045WrKJ/ V+GG8ayh/NeK3BRtSopaJh9wtFU5S/ZGMMapqf7zghZR4wDKiuzz59rqr4dPkopjvWHJqJud tn92uxgwtQgq1MCPf+P10/L3K+zte60vx/kldn6wra0FrBuLACOER4s2ZxwU54bMMtK71gJP 4ImGBEkDwottl26ejOV3dPNhNmBhwo++sIx8jLzYR1yAOg1EM1xEcsCf1PMXmkH0JETKLwJY SdbOpS7ut9gPhtnH3iq870RPFhJms14QFTgQT12Ozdlab6plbum/zsx4ri3f+1ZfWCkEjlRP Bj8r864soQ3uRxD2wffVYbwzAyXDS1KCIqHCL+R7RRe3lfME+gJFdHfq5R+ndfZHW3MIy8Zy u7/H5z5pqNnISSxELNitO74H1eQHVMwcfUKsRMtjma8Y/USFWTy9Basq1ew/eJMFzEhvOfbL CeahhVt0g5H4mfzvQQvdV0L5yhNnUGx8amnSOKJCOIUiFLFvUUhGNQEIJV86lfkLK4+o84Bp 7puGrTBOmVZ+z9xydN51qIWGZfqz/nWEo2HwzIUJ88Hvhv2h7NMMDeFeBs7cjMbIBnGpA7jB Uu9vZ9I8u+rNVZnCvmuwlU+CMfwPc74FMGQertQIcX4HgOFAgFINL4U3094PtUoFekj3SbhX VThKc68/9kduPi7Ff8k0UAvchydvv8SmFzQ4lDPJGhZyzs7V5dqHGaS5EQF/RX4co2R/WnZ8 X8+kaZzXDcrnRvsMeo0EkS/a+yix6Ic8H4WpLr1Qv8OdXgDAw4IEk9hzgwIdlHtUMn3y5M2T 6rYOW+c94h7dzCzf+WbF0x1cgFXIuY5Co3CUVw0jOb55AbE65LkvrlDG/cLT6XVsI9Kw/696 14KlCEcA4RKkrus3hEx9K8NAxykz8wpwckLTAejDbuEm59c9oK43IBgRPOuTWt1QyCqDGWds CsGTKJgrXDNvG81d5D0Q2Iu6Tc/LACmGMpWmvp81PHhwHgptYH6deNakbSElyF8lWV15pHzc BbD7qjV3jFDXux/6r6u/Wd748CzOgTKwBwYb6itGNrvImUKWP9Fgp29S0nMdcJ93rRvwPDQ9 fTqDPpNCnCTG3jzvCfcuaw3CkZ9T47Nn9Ayw6kEyPXVoGNHE2gbfznjO/uuqB4FoGbCEf1U+ DFwafnoqi4xZ6G2MNBhvGRVNDbrXD11HwsrpXsQaTjGs5gK4scpWLJA3XQXVKUmC80jDewUL C4D46ctPPyej+jjIRr8ORUbL1R6R65LC0capJyXzA3sXEu0iHDSDEj3cAn6nvvp11AUcnqsZ J83PygVQoXeTrAmqNOmz+pB2DGhbnHYv/RKSHL3+94qKQ80dG4eKg4zGLmrRkBf/ZxxFFQ4+ Sjg8jzDIY0mpKMpGAlI30df9HZ4ZdgzpdxOAnH2rKDlGDIt6hjbpNggCyWEjCA8Vn5cToObz iV4Qkt1xFBKzBPh0Fa8SkVXIGj5xA4U9Dffr0k5nAa+Q2suDs29emi5+IAvhc28Kyl4KRwQ9 lxODW671ytFHI9iNp89xHzkwzuc51+OFvcF1LxZ5NPq1pquJ9REjPcxebxDhzv9L7wFS/0pr zAIiLi8ap3Aj5Bk54YhiU375nIGT7loUyZHcspJlmQfu5fL09rh0sAkTvAcAXOZxqFGnay1m OgJlR9nm33C22DjmozosoYcgvnX+kZFp4GUl6j+8LE1zqNntwayLfttpPGYQwznck9D3Pt7T KfyZ8wb87Bez8ccNlBHVKVeIt7IczWDXdgk2wGUndUEy44RhL5kInIHAhYDcsGzCO4FGgRXp Lnh9EfjHsvKazAFskKqjvzuX4vyS1sKFhM8Qeo/N2p6Ev2YkjU0wKAaKzB07oII+dBCQeyIV 5T+OclqBw/wGBtBFslOkBIDsEOf+253BSuONS63R16Dtm1Dz2e8037KQyjV394voyXHAspA6 JPd1rmQmFRsJAaLZT3vZE9ZPGsdE5795S3vYaI+8uQ98g+0DdjsbwIggrVWVM7GVFK1voWq6 XxIrvOWlZWfl8fMLFOfT2yikRnBWM3WYqtyYU8X9sAnGFTAYxzoUhVCIhEod8EUhAQ9X7ljf YjY1eeJ+RnsY+k385jTuL4jN6NAl0Sc+dzO2AVMFZ5U07QYrp9S0zdbbQUM1PpM/l9feL9Bj exdqWGS5RhRt9VS9xV4MY3GBRvLNDbOqXpesZQKi1w/uqxGIiLt2HUCdP/POFOaPqI+TPt4E 1x37YvWBqxARMqvv0XNLhpmCcnuCWhB+PioZVVbIXYAVlRxggywZubCHeoufMIXK3Pyd5bz4 koDnsetrIJZ722F9wmoEKwDUPRJIIrVOzE9Yw+3DTMHulJATVK7T2vfqyaKYBgxEM4jKfiA7 5Xx39e0PAeUElZ4j5tlLB8mY8+3JC5RxEj4LEOfM34VPx4vrfIECm+y6fTlR6hnnnF5mEnDk A++yzgGNx42pQG+xc5l6easRmNhk3FJaXlcpu1569IK6A2bLyZA6vV5qLjjdShX4ajD1W1yb cG93Rzt/0XrBpiPWCQq1m/jwI5PCXeXh4dRJ5RWh/4CUdYTkPo4LnNLO7AhRjAErzOALXHFn JOGeuAF59v3LiMjMmFRsvkBY9UDbhTJUxM/b9b7wNFSXEIMgBV9i+djnkKZlUxHN1tmQocKW gwYzRiZzydqXBia0Yje/dqSqBGDcE3hxOWM8Yz9cTEFQf92d0jyOIACQ92MxlKhWuwDIs7oA UQL91mDSPD2EgT478CURjcqZM4SyMugEGAyRl2hMSNHchi0iZARxpLqKk3MtVy7keadtyZSX uKKc5YUmcyor04n5GE2ZLjEJ82ECzTuBZ8k+tgaWsDiLFkF8NYpKRAMpDHp98ziWm7ZPJWfp qYGtWzqm2h0VnjWniTR2ai3GqRBgLLSkfyIWBZrPwvEEt6U6ujO3enW181h32+isxNOpLphW xOJ0hhPgZdfADsQgpp5L5rPf8pXMeXJUyjk7sFq2+8U7h7CB2HYR2zKLHGgDtKFXEaCuSDM6 mk9hL2h8hjUnZM0dKtr+rkmNvyMTqr3Mr8J+gdnABVrYR1qYfzwVWCVZA7ouR4xtwz15GKpl crzY2yDZZus25azfOaiEIzrd4LIB4hVHrY4mT+9fDEIDY33PWzSJgjumhwEo+S4yspU1UJmT 40sd9beIExKNGbfeSzlg9Nf342VZcAQG9V5xT4Dk+cyJTIP7jOp7yZ94VUgDSZC6QyEjMMkY 2a4MIxk9wTV+Ts94M08obZPOLnunmXJMbvr4PjfyCPpsvfbhzvNEZaSp0E6ktYndKdGjQOdu /S0ymaVVPxrdsoXxwYqZloYTNACyJvjP9ZJmcA0W8c8Yvkns+RZdAwiz5d+Wjg2vm8riNSMs MyGPwzBN+8lZ/0JbV3LoJ3jnFKDdMUIR9ZHu+CJREqvKzZYABE0DM4d9Ret6FJvcSUES8QWi xNdUwgOFDnrdB0ItCVplEmzLbkS8mEs2pYLZ5G7edmeEEpliNQa8PbEiKzDWB5iEZM4d7bn5 yWzdPcKnb7DKI2QuPLFBik1hoawBY6ioQqfr3d176JT6o1NFBvEBhpDCMAV/090qVCvs9+dg 0MtdqsL0/B984pNgqH7+NAhfazllB9ryymdvsvYdhktGTMECKkxBCs9CELh2BvwZJZUOPXeP SnT1pZ1bUPKD7Fy1Fvbhy2hTMfDF8uI4hPfBRNJHaLdi1X44zGwKn/icN6RMeQ9LOvHGdqaw ZaOQXekQPCTlYd5BVxiz7clV2CHCYgJs3AMa7dKFKPXtyS9Y67NUoqw7a6eqDI7rHa3g58So hgn2T/R0sSUCWeTJPn1QLBj0+rtSnSp1anzr4SOEkCl6tW7QCEPDdL9eDWRNJ7MqVndN23rM BvOzi2NpS/lKbYQnwL2FObviiE4p8HUMNkgDt0gPGvkOYpW24VjxSrup7nKcm0jstD6VSu/R ONoefHDpU8+H8jGdFYPHhyBDQlNVjJWfRdJXEYz21viAompBTelZYuY1miC/W08cd1v3WZgg wX+3V7pksXLBTmC3ORUuLPrlfOQJgC/A/79LK04wxS83ebe2NR2YGtcOECii7Mcgz2f4r0pq CybT6UzGACbRTbGHpoVa8bBlXLKqUdbNSgeTt/jT9s0lbvG5QTmlDRnapDoGrw3CFXgwOy7z Pv4Nysg9ZBzL9sQ5Laxyga/TyaiytLNSDmmmzXddH30SOLC0+4Qp6T0i4kIYCT7Du7B9i1zN qCcUm0MsxHE97imLKyzjXWndrYrUB9AJRN0hATyFtNoj9qPSGcL3MjLw3H9DdFddhLIJT9i/ LuHQCDpzn88Ab5Grjoj36AT/PBCNUCEBofST2A1IKBysplrKCn62/BGixj91l19eFa3dyu25 pnD3aMMPA7096uXIYpVCtVBot4Itlqcsy7+Bd9/9oOili83aNs9N7D6+MXpqMEWy7RBUjNq4 Eiqgx+P1OZcZBbT4kxBdX0x5FKZoUzh+amst/OI/Q4AN0N7r56QxL0hPlGYJmsJEXOZTpnBi BewY3B4qkXaYLub3I1lHvbLZdO211TuLAfpAhqpaM868lX4ci74enp7FU2LFLCu97Ae542jx 04V5bFNPLgZB4ChuTASeYquvHVv5uV/uDypeqkBenMeRWwOEjYkIcailpnOjPl7cSjOx+1ja bM0AysxYHuFirmN/3GuXUBeORNGvVHTCPVhhqip43npCyDCsR7wWJ+Dd2X9NT+T0sBUMUtin EahImRAD4NmunmrjbfCsPxG3M/sHMY3x9MDrZcQF4o3O6dgZEZtIgXJ2pQTSkkocaF8FM7aj b22VVbQGYdkzGgrfdjAH1oafMxtxV2e177AC5BfQPA8FU97+gE5ieKztgH5KPhG9qwQWj3pY A2NwDeBz9saL1qbiLFvb/0TFUg4gu/pfZ87xnuGY1IBLggHz9AXHrDWZwzaOtneF0Yel8Sbc X7Nf/DHo3jmTyfH5W3WG/1j5GQcTKWuqsQMJpirdDyRXU8z2CvTCyrdOKbt2w9McBortbKTQ nEJEXh+0o2Z9JjCgJdP3gqnb8uloh0OcjecFUkHq3Jpe/Awv7SBp/0bRCwDTKDfIgO99nUpK /RSFgfkzZI2cRqkhh7Kaeb0+SD9TLgqdD/5qeU/BgsxGfqWFXEzD5Eg1gWDEihY3iwEaOpxA A6tWQ36W5HpY1e2k2ptGuCYwy0Qwdxeey3wTlx7ilhkOroll7K5GGz0pmgtDU2wlmNYz6BmW 8gStq0HvJo8b37G+/+0Fj1at1PXhw0pMPddUu0bBFP95pxX5p7IYZHPPQsoNz+SVp/JeeBwc fZ/AxktrwhVtFlu760Q5cO0iT4QttJhBkAIQ9FN+mnCgD5uvDZy03TKSQsYZqDGTLHw+Mgzi 1Sg5PINPvUpyFgtulBbHxLnZOjBx9oMbkyLh3+y4CUED85RjUUDkYvNZjUp1fKU0Zn4w9oL1 0oWj5OyJXTYiO3OWCFHv30jeE3SUSCimBuTHhQa5P3j0gbS/3kKvO1vzdSsUKcL1KYRYo/mQ 88sEmqFTJBShcHTR10jS/iSkHzCDVnHkoLF3IYhWQ66CLetGtsZPTWhe/2y2uyy1w8g5jAuy cT8IV7YknwnSxRqhDST/W9xeeH2KGZVuLSjSOmTewuJxlP6OTG9PGhRtnGD7AQ8SX7ifTX5U E6txW19KbZOXHRP7nMoXesRpY1MQMD8H5/G3qpece0lOZ7ufVgamm789NfciGUcUi9Ozg0+/ Zi8YcfdclPSgGTZRfJ8ZR/b7j8/aE7qudJwZpbXi48bJTXrVO4hSwMcfkOoggKz4QymMkoAC 7AZPXH44oAN8MTLaFT+n4A3kjxkmyHMbuMB42nnVoszU47+G9qOAunHfo7H1YlMZjyCjfwII D+YAa+ktZ/IarOXB3LX9X9vUvAFak96XE8A85AwatcoqWc8r4glvFxHfgXzdtqEVVifLaQiE Nnh9NUYkr+618YOu/TfEKPkYR7aRNwaFAH0uhpyIZOgGtgFyqXNksrmzRsMIajNrKJGPhIcz WEF185fi0j0Mi7omCqvWMXgP+R2WJlSzi6ZP+RzpwitOnDGjH21G+RZk4uQNoKg+3YoxkALL +SiI60WLcsoxSLbBacUBOizyE8rwH6ixquhX0yDuDVAAyPYH87sNh146xAK6PTSDuS6emxDq 1jB/faFwq1mBMN2/weL50By/ZngW7A/Q1+A9fCKlv24QYweGoEeBuC3AOnWencNrcrKOQ6MN atYv5wVVbLrYormINBeQJEWHqG7fo2GsCPRh8Sxk94XA3E1ZVRYTZ1ppMlyG6BtsI64GLIKs tA0RodqL5XAgF2SnTauWK5Pap89TV9/DmCxDVZ9wsco+t9J3Asq2x1u6bEfx03DNQaluhZ6c a31qqZOTW/cpfXDHJ6cgi3+6jI+KbfA8Aupbb4+duF2RMHHZHKjrtGu9dluwjon70HtNpDDT WmEiZ3QKTozsF7kukzifQ1WlMkucaFOg5212EBrEI7eD1GiyYZlyu8MwZ/yY6XL8XNF6n3nx UaoHJe6fJSNbUcqp/eAq9nPsqrIoewGGpEf10zUl1qTjSmcRS4SIhtf1IImss5AlhHju/Z5r ItKMwesR9+aKLXNzgCIGz64BYI83UueJudpNUiJLBy7z6OoH8u5MfwQA47SYAGQTYqnbqv8V 8Nw/IxjbzJJ2NIfRCKTvD06fgAUvCYYBnojuOf3aQWnxo3S/8J4Y/CrLEO4+AlBSK1ZNjJ9z GmAm8cf5Ap/OnB+hrjiZxplOHNwyL8iOLQ83bdAdwnTMFLY8s/qyySwxM8YVfBG4XT5bEbSH 30atoXGMWx1lAjDOjzRprioIDPf4vAqUqmwrMw2c+d9sRFUyyPpzugpyNU1VamsMqv/6P0yl yqS+b4G0z7BHEgyAn4IeHBRBoiXzBRKjBfXmxW9toKxhz23pm4V5aOUY3BxvPeQhvB+5FXyf JJhJs56vrrvaoUQAFMz7Rht2VlYpXP7zrar029AKP2uWIiYIEXeUUbGfZpXL9YBt9CT2OQ2c k3Vl2gAaY6yXh8Ucomb0FSUzAkIEv7eRL0HprcGB2eC2R+TXWF1l+v50ff52NZg+PhVjS2nl UymvpTf1YJyHjN/jmFoz+64H6gticHyivi5vbcL7KPQt7OT/QbeYaO1ZbQYRFdZrviLlAnDv LvffPOqgayVXQ1idTNEcNT4nIaBm+7mXCwornw5z3svEjHimUeQGSC3fh9rWCmbqGvrTxRmA Ir/iYlNk6fj2dM8CzUcEQZF2FnQEvZyXjPRDOow61ExO5pFSjAoTWjozV10MXvJo2LI2SGPW BSF/O4Uk5DvcPkfSgqKT9c7iQSO/krNWsy5YmwMS1wOh0WssXzbQZitYpguUfD5raJ43zFgS NSzmzpRCky4sy2/h+ICUaX295/qMn4CIos7gXZDrvvw33NcQoX2GKLk9ZPtjKTzqjDN09FJd 4n3LbK6rnI7lZwTP2CXN9P09xCH8sfyLp8LzOzCUOheyHW2kgVz+9SHiGet7BOyDGHjNK2M6 Wl05htlBbzwFmEeQKNAiEpv5hOKr+Iq+Wh0vI7i7wWgS0NfU00P26+ULECwsb9ANPmcFWJo+ ZLHlNp6kAcvZ9S6OVE8fGidXdz8mfMz+tUDJkH0HD6D70oLARHlb255pX9zI+FTLI7h7Zs2C VpUzuOkwPH9UA65RYdAzWMBbGA/yWw2FkC1/KWlgCqFbot+ObyP209Ykx0szeJnOFf1mssdY NtHHpz0Gm+EqgY1xw6Aq63SMT07R/jaovTsqZrVP4oKrX8lxHQ1l8Avf+zCBwf8fNjHz5iYk 8Ynkh+KheERRc7JvRBPMNCYxhS1FKS2jgrtrFqRB8A/eaq7CntCKrvzRtCYzbOB6Lz9Bel9g B2L5vOaPSyV9tkokWryYeptuGkbpoylmq0JNmoIiqEEiCMNffqWw+PA/736rTULo8HVP0koZ STu14GaHvDNSEfCKh8uLFhjgFfGEbZOoX7gUZyyanmIgUzyTxXLPX8q6W6XXNmRrrFA5+YMh 4GCcMfph+vIxTb38SVIeHgf2R4IV8BCbOlAi1t3f2RIhaZkFlIdiVan9dm71TF/dcEYKiCko /RO6ErGiXEhi3sK2utIJ3uA/S0MvVf/kLQzO750TDfeFr6LTb4hj05jR5Qga8n/yYnc2siEd loIBrOO4e+QTEDLgunnoSPJUtq7cL5ESPvmxLSzhD/zzTz3xdEXfgUqRCGyTNDsn8duLZlBb ep7CZb575u6oe9wi0kLfJZjoOMowk6yiZ8RdFYwppbtXMM77HhVM8HqGxF+eiwwILnLtnMUc EOtYsxXivFA2LEMIvdd2bLeFaFch3FhhW/mtUxxgDYrA6UenK9J7tQt2wQusJqfASN60JvW4 WRNIX2iQu0g8kNn9tXAg+D1iJtXJBvGuMJHPkle+kDNa2ld+xRjDQB7jbofsvSesJxYM4ksY xi7m9ujGA9Hk/N5BNpPmH5TJmJEvXEt85vpgESURzg5X0e+vyeNSK3fDxDCUn+FVD8bjrdGg ZtFViY/0C5sKWaILOkgG5X3PgWZyCbuxVbFS0OdPaiyXuvm5wBWzF2VVhAUtBf5MzYGX60dn HvRausVxN8pe2wEJVmCAq4SQohB9ZaIAltn9/PJJheTbAfLNxbFrSd6x1x0XU+us1a1n8KMs 2tak1sjnARmMsPAXzf3RdUzDCCCmoiJ0nJSt5WWeYR6LbPBoB2I4wuf17ZWdg0SQ7BcpAxQR Cp9AJHLEUs1gdub14bevKHffEwlCrtu+uqotnUNNZHDnqm1IcddUV6fQDZIHplsb86atCC4K vud8Dqy1Thh2qkGMf73j9BkV+jDMjBF/z+D3+y/EsHjEjUvqCIR9lca/vtFmklqJZvn8bpNe hgjVNvm1r8v+7M/D2L/8Sc6zetMlm7K3RHFyGjvIZ0SpPw38Fv6yqZs0KkdeQ5sUnu5++lEX F5Aw3KiS6u1DPhA/hvcZqhVftKzWrYia4Ahq7FEKt1Y4vh4QnsoDstMG61lWHGNmaXffx1d+ f5fWaIT2NozY2k435rvj6yJdXuinJf3n9yI+Gdg8u6oU9w5U6BgIyJrnatPS14KvvuO6nvLg cTpNB4KKzGXLc318PINL2Ou0uiDtXvW+uLWG/izdKCLQZcsPT3sfmx0GJiFXq6H0CieIwtyC HK3vPu4ucj7JqMFJR30sbJzqx1YYY75bSmqXZz746tsAiN8owzZC4NON2/bWQ7g0v2/uDb88 5yeVvNyEg+sDUrb1GB+VoG4EHf7ceqACPnBLd/2wuDW5WeV/I8M/QrGkTF6aINBh6A+SAWI9 2NTqGsKZo9n0aDCEYQERlpaUvuPRWi/XcNXSiJgNo7p8dKLLNznBpk7ePEUwGD1gtFcOlDKQ aU6VbS8PJo1sX+pcb/MFAdQOdA69WhCIhiLZuudkDSyHnxx5oH1p9qlKEQY/5js1vzHyN81k buamBR2711hTz+kvYTvAHg6OreXFpWlUNpq9fNgl/HdpVWmCg/5N3eo0gwMt8RoeTtaEaNxE WFuAp46qkYokdLhjBg3cLckS5hK4/15X3nUQZlQWUG8AHqeOt8ZekVKC6vgwKmhl/bqwzPtA Mxy4hdVo4GVR9i0FcQwHrZmcclBJ7nA3vWmZvI+wZZ/d7YgBnH41roERJVdtRur0sb276qte O74Vf00tuiPfe3V/U50IPJV4bjhTbhhRVzbsU5ppeseV+AQVi+qSOXvbix8/WBERgw5ALBii jNDM9G/PSebWT7tvozxLS87GDW5tOKHAlbW8aRegjGgfczEVFlz55Ukk3vXIrlh09mhuceg9 Gutn+jG7t0WPLhdhjXQJmzSNzVicUGtOKQ3r17Re2+kTdxskdCYyuanAyOZ240PmKfWNIxXg Rk0nDmK1Uq3L8Rhc31VyBdDhEQCbax4pbtNGftzL4+9SlDgd35G+mHT7L7Ff6Tqned5f5xgr +3zEF+CF9KR2Qbkc7B0cGgSe/gxEEmbZFDCiMpQFgXgY0/Q7bKfM4gOpdhyolSU/hJTN9YJN ePvYHPwKr3yq0ZxDJ7Rl1Q57PYnvVb+KWlzCAJY4qO+0YzklOpOOygiBbG2wHp4sclcnOnSx AfgaEC1jq5sewDe8uKiWFn4gVmxmBI4fDyQliMTzo76f/aQ5uN6K8G4jrMgQ1CUHGnpXPsug sKqpeUt+R3TUGrp2EGut5FiPZ6ekM1g818ObOeIvyetjExLdq5N0X7mF2B5TtY/nS8XEM1Nw rfjfJAKDcylKteCfQbSNjnaREsTl4XbQMbbg0Q74gByBgDvEUlbjjzidoUIo1U3/f5e/kbaI d33Aizpi2SHwE4B9JE6PbcOQUyNftzKtxKhCOCl3fNCf4VATZO0JdM6ZeLGWXZCu/RMxLcwQ dObVK1ehzaItNJNWJOPRsiSP+TNGew2hOZ0BTytKtaQYrfA8HIFd7JE+crKxHao2DZkCP8kS s8GlbzRUaQBAuezu6BICVdMzxVUhxNmtyYB1cNyrUBNXmHJuZCgOUad6xu157p3i0GrRTbfI rHmz/cyp43sER6DGW6C3wo7PypKvKOwwuCHDQNfV6zGge1ONfVdDPoTclbygqapMizrxbF2P dkdqK3AH8nXteWv7kj979n82xKTehkItH9+B2hrLZZU2msVrT0pbOFS1Ajx0vJpMdAl5NQWB LB2LSO79G1fMO4MAKZETeOP0SlTES1CqW27rWqNlU1V2/ejGdtCjJ4UwyltvTF7ynEOGB1io 3q5rFOGq7AE8ddvRK4OHncPyVNtj1RSIOdD69vpiFehxa+cYnD5peX71LtieKBma6XOssy6O ouCm08QrXFEpVNd3jCU7TeUb0D1fc0lENc16BGqQrtigJUTwrzQ6dtLE0hVQULGUDa+hfcII wL1jpDTSA9013638y3mKrIWYvPQSR0ODHpkECdCG1laflz/k+I3x9mOJ3MSjKV6Ojva6/jAf xxZyIHa7Fs9pqPS828Ud9zFczcC79oUclBfCi9CPEM40rThXkubYd0+nK9ye5dbZxz0VWn0m +Mtm2GN+nhy3nIq2ayG0gh0X3qPFDqRrzBoJc7vPjRvd8eRNkUVSQ5KsSirMS0sG2S6hCadg cPA8Ypdc1oyopBGF67/eoUxr7MWb4xKNQQlCrwuW3vBl1zv/MXOycWhLFZ6F+Fsshs1QYDIy znr3YNUkUaNh+cP+3mxIUFpYZE91aaHJgvu4T2WNvVromUH0kz9LWyMlvlm7pPpus3FNn116 2OOUO8AUghNVTy8EJ2+WpcUMTDqb3ENSA0kIzjECILKNvBNKEyowBf44DrqrIakCahB7bQUC aN1ejcgLA6YkCIDs8v+dI6N0BMt8Mgr4In60y5otJnmKJC7ZPvZdtJUYi9v0H7DLcg02X94Z OOmkFOAkrfbHeD7675DDQQcOaUr5LpTG2lT3tr3fMRQVgmXETkyuj/gdngzVwKIjJRUkYKg1 JJCKwGYBcnHT9+Xzde14UrVwIHMVLZXpsQDIzYQyAEomoGAj3efDNoUnd4B1sfyICkQShlvA suD1S0wGShYl1UzrGbcQM9MaAhYt41oSxyf7jO4C5Z56m8NF/DJ3XF0RA2nsrylx+0ly/bzS sDWwtV/O14cgB2dus1YMu77vocElL5+cReT3mtvkmEJUPFsEaK2cVibCeOVx81xZH2XlcgFs +DtaXDU0nGMgvbx+Ui6BWLR3qJ5L3iDvdj2H7Zc7/SnQONP6IhNNmKkAiMVpY/uYeGeTILIA Dh6ZnyE4UO2A6TBgbm4HBf14FuGOov4ZU4Gtl6uMobdL4GjVPnM+yBWYo/A+UtZGg0VeI46e kLXNfmpQucYHVr8dwrnjLgX/hovBxCSXOZyHk+T/rHcKPF8i7SdBpwWW1WVyverTnbivE+ML 3uNHooKxRnDNewl/pHJrJRzcnWA2yQzxxzkBwAp6ltr/CNvZXSddSSDJsLeCJj4DjQUIXvc5 DcM5tEgrPPsbvqanzrKnUjgVXC94Vrpz0VXrbeFn/FWQoGcyRCVf7QETaRXf8NZSw1z9lXXY oGYyqWmg4sRiHxRbG8/8CRolVvVeVKLK8zWI/WMTgslphsASApIyrWu3RsB9YrpuPoH5PYkn L4U95AVCo4InrJGf0JeiGPTPf+xdKxW63ZECN4mRkcSMzNZPtmFRmN+W8g+TiS923zxa0Hrk FbuLaRs5vWCnln/hKYlL9sR5uvX8KpC+qwB0KHxH+Tg2mojgnbsd3PR2hVjfZnBUEfD6cb6d wWU9SzOXpNHq0cvCZT+oeupxwUy9yUsVsabHroMSqN560iwQbdw72/L+jgENgfb5xehV67AW /J9ij9tghwoyKwem5RSD9Zw5fYHwMJm01S+18VS9lYxgVvvmbtoFs/0R3yZcBrQ1kde6y/HI OyvYYv/HS4F/TL/4j2RMPTVrO2HElfv2IjwZiBaUZKRmxyqZW/A+Vkv9FMkytUPvwcrUkOS0 AXvYmFM2q56jU131Crr2QLuyWvgAZRYREk2zSSkO+wuWczDCXgFbXxmJbYBU+B3yGIl6MMzo 7m2cH5BrJ/4aG8PzYs9105jiLgVlygbD5xeKgypN5G8nqCyMj5fhGoYRI++xxbLoLexyQM+w a07rr8WawxMiGQ7ljFlqgtiHX7KFQ9WMA62Yx8ShlAhaALpRfMNKbIlZrtb3yk/p1Q6bKqj8 7TwaWPAWT6+cJFjmD9WiOQpIwge8usgh5qA2a8joj7GAJSXdLUCEObVwNx4v0K8rpetx2dGp kMd5PtAdRqWjxEIrcd+bwyfqeyeW57NnZgZykMxxVqp59FPot42zkMu3aWDyJAIkim7ID4Gh FT97h+qohCWj7pOuOMprCuqQEk3gicTtaB4YaAIn4aFsqoXpShPgArzjx+VZu5htpXsE/bzK RnXEVeZ/UI0YAoLRdLCA1VBDrDXKohC0+GNT+8Hl4OSOL4WF/UWclT3Zs64RNxkpmybda+fF gJncX9+DU5pQDRuqaKhNKa7ESg6VHyLOrObzeGXmfkygpI254xUbiqhl1xWru0ngKntiTom/ lNIJHBYXpcmm87b+EMoGYh9ZZhuocC6niuztSFZIUTKy57m1293hd+RvSD5UnplCRZFTePD8 T5jvQAOJTRvInC5CD/3KH49dEc21AEKzeMDdwbe8t22l813s/NnJTAHA0277hH3WXRgvjzqj g8r38vfUU5IVgAPQzlUckBYbUVrlJ7+8r/0Cmoe0SZ3vb1E8WcSM2BjYUjalwbR9BSiCWT7Y 0wHo0kafcCd3ZeVbMi0bu9j9dyoFJp1jHVA/o0+gYXI7CmtgwLDYVG2f4J4XF8RaS7qeC/zD fSG0gl6e3b8HrUcpNtJWPfcYWGA/IfwoOesbOy73vU8YD05Wb2PgswzeFpjbipN75n9D6K4n 01Vy6XEE2t/2xwtegdSW6iGpXhcko1adlK7a3H35alYKt7K+MdMOVvSj2Nb+omoONKgUNS2f 6ldhnYwkU2/NQ75vdvGKT7Qo4hQuDd+O0AdBrcq8LDavSg84Sh+tUFw9bC/H0VjoBXdxMui1 cC8L6RUi5c2uHFpf0h7Ss9Jzmigc1vWU+rsb6up9RrruAM1yfW6lqxnic89uQzMbK6UVyjTk 2/05cJ+LiRhHtRGXGK3+ue5POYdyvMx2oQ1kjMwMb9xnya3NK3dh3rEMTDG+wQODA5J2RCcR SFfdrg3AXkEgNX9mDBIAX+ybgNELv5+lVUn4qOPIFwpHYyXgb/flbvUfEexNccFQ7fAryWZG hJDj7kocQBbvYp0tbCYnpQqnH+VP7bFnRn0/RoL0VaI+gkABtCYBlM/qRdOua4DG/JVP1EgV CqSMUHZHUYnUSi8wQo8O1ciYX+8LvzGWLVjY355FaTTZxPoZuL0EGOnl7nbt+RTQLTYW72WX 0lHH3didRiKkLhezX0bFFyp7Z+Xp4S+x/LDehmxd5/6uih+0BrKexMur1Ch1+dDfYaC2xXA2 xDkf9LiL8feNDt4FMkch1u4LTxKBEQrAIVCZQh5+iXuCUp+qnycTI0oewszWHIxTH0DZtsMc DapsG8+7KnbdUUdpIe05xEUVP2/9O5s3Q6xgYkOAIfg7HxbNS8LMlRQjKHmGNGhjlhldwL2C W+s8EVpAl0TWn9avnUUFI7V14omZrvkj7d2f0NeS/t8j7K9bGSt7WVvY0HZxNUAK1Cv4jFbD 1i94PxYqhc/hg2cZYvreeATuFL8sIpx0AM2GcDaRkAEPHoyYXrjel6R2EejUIYmg+5uB1nke ViMhZswjyN9ZTohy1mPCmJTJrt2Gsu/X9+5u9+QQT89gX0VciRNahBgQBmXjUfRLW8e0SJS2 nzjA6VcJVYvAewF20rT8filEq/rA9SpGtVgxvKuePh+Mog5hQ9iBLNhuEAycPQi7mOz4p1qD mxSWOs1h4y+K1oLCHe0+YXCFL2cjLoAm2y0HWhJ5rkpQIpGnPWfRNFi265rzS23aY3KGjsMw 8isH/5Z7dtKv9B+ra2PLeuuC3gXL0POH2LG2SWUNbwcG+42yDzJthzWovjmx6hivibdUFeEy ulcIiM5KbJzqZNUYXecMgiqR7yXNSX4oBIe5CrvlB3dyvEhLUNoUlJ6tmZiPLhnHWiSJ2n1q tEuDExWBEihjMOsdbrIeNdvDp5DVpGkUUsL4Smq+/+3n01HK7A3+ZOcpXq8zWb0NEfB8SJKs Q4nreWGaIvV/jnWbvuWVKqKWjvaLs5q2WPSqvym5s8zJNRKwGjk3TViKI3CDRZFw6QhJfOsL +j8Idp/MrSCZYPAxNMgikykO+pa2sYw3zXS0gz9LcrtTZcEYkrBa39EHA3/n/8GaxmwdEsgK xaYPstKjHikBkYUvoXDEJ8C1+0prIbqh6PiahR8bsNOv00wsWsJ5RfWEQoJLXDrX7YvjBhaL OBqfdHJ2uqrrpxBsci1M6Lu1eYq3HVMGuCM52Dsp1Q9FVR2CjSS67sdNjhIXTc+09RpmT6DM 9cnwW4Cso7IHcWlIejglmxfuXkHqzFPCTMN5/6H31X8LRW/rGj6ob/4xB83DoZfmL4CvquXl 4X43+Tzw29qFbZduw0KzHWEuzdSUb8wjmNGv3R14e2GNTdPIeGflvpqLRdMLXQDwhouG181m ff79tIeBgiP5LXHSvvhjerYxg0Xv9yNMTeETde2ddKjq3TLav+O1bNsVL9bsQQnBo+tF4FhK CRCwVXZYVAHdCluvItc0kHNBNqJE7bFa/hq4KiwMPW1/3sQB0kUosBHNw+7cqdl4JxT3vt7q TTtLOD5cb4moy9zMoDzvI130ppVrWETwLrK/YLtyoA05qkR3CM1Th+qJyWVfJ5LcPiiFCP4K 1AgF3Bg+PHb0Dt7JriP/Lj+NDJ+DT9+a5qxxQB/CNZbYo+PqXkh8VOeApdXgBW5OGvZ0Znry tGQ8xrJKftEjotQTkgfAX34iOO2tSpcPRcdQh72Ilue6Lm/t247kD7K0iz8rMkg5YyZudULB I2e8lmlpyvYupmzzAmVxOUAQRlZhuhSFk0haZwFrl38nVIm8gYrHYRY4eDuLA34YGdxmy35V 3yyVnCq2NbXAJxokhtV8id7IhnzL2P9VZ75JmowOIp30f5PwoIJWTXJ6BTe5nHIaot1LrgBh JBlHW16SpAWWadTHT5LO8C21yXaLuoD4bbWJu6U+uhWornWXs9tMPWXDeNt2a+l+XskKAdgm 7YzFAHAGxIIdkn3jg6SjvYhoplWbB/9ldvhTOzrQObrxEES4/UdGlVywAnSJGa1cYwfLo88j kXnSpzmq6pLtuAebG228p3zok5cC+RKSwUN+4CmHRZCXpmc4ZYYGYGnvGvNEFBG+uzvGuDgZ TH7v8eoygbqQDQwRPA600gipsR9nCdZ3eT/bHUTifUrZTMS1gOT4RTJbGn7szBIGkgC5gzRP dPE3TcG8/3RovMwLxj+xS6CLNA/Fo6PRxXl8l5vJiLwGM80GnQBn/YAgS44thCFJx2tJbv+f 8OfcuQ5mXC0RMEUe/m5A0NxBq6VzG0kXORLaXA3keSpZIiq5a6SBH3t4pHBD7wcxgTLFUwcK Tk7RH7sDfOVmzyhVf2I4Aunv48vtQfL37BFRCyDAkP1imkn6wM7TXe6vUgk59ZiogKXgIinl gNLUjULBrLCOyZMiquaWwRwFn9oyj813SCbRu7AoKd/DJ1Xx3DeNg9/yKHRZtyjtqFPMqXIq KRQeZgkAwhWntRDNza2/DtXQNZuquNKlfamOZLQ9jqrMSShwhVyh8I6aSlAtSgVTfc1PO4ss nlVVyc0gqX4QamvYnK39AHY6jDWHG4JKFxveSn+voP0kw0NTiqiwWPqgS1Hndl4LEyKFa0fe sjWge1RCcST3dQHc8ymhImF1qM8quHsMih/bE8yPQf8mhW1cKMgyZ/dvx1snC0viBzhkzGUW HVq6M0lJ53EyOFptAQxYs3l2m3Bocn6HkPvBiaPAymToXSwhS2Doji+C+eI7sMGFXvuM1lSp CBs1da6z+EOKHE6d30n6QM4mIXwmejRFet8sWSu6r2bxhcZIqaqKs0HPmvxyh8ITZuWIBqik lAgaYxAx5kWnP6y2MNTiNO+9G1gvzEmrAr+L42Ib9Vs7e9D8QkWN/+nF3tcwL5PBoBxwzNVZ rx7aqe/oQvwpQkCKkP+qJwPCMejX4jjYggiF6cpyPm/l3ITXGr8UzR4PDcZA/85pTHIEaj9M hMf1Dh3tBATjyeMw+d3Y3cLS4IsO161dMT+Umi1OlUT51dSVMaZR9fBPm10Vy1M36gqdOqtD ylZfe0anC8qzildOuVa1igRMTNQIbKXZZUjcdoaxIvSFBEAVeqaAHFtvB89a3RubNhqzeQ9I 9ymsTzVwnMrDAu1j+WNlsfFaozsOzPdq9oCNhqYopjbu8+hElMv0uYSjerjVT6zQc02tdkUW PZA9tnRth/lHTnK3AffXXMAyI4/ciKXNPltRvd6Tf31o5KGUIm/2ug7ZWBoK1I6wLOHu9Il/ DPYRrQ9jkmpHb94QS7HWqNqK9asJWkCF5ER5ypG0YX8L70WpB/WH2o8GFb7eQWoL77dML0Jp DwktpjfXk6Z6uCazprGryMHfU6dFumdOVg4bLl/B8BSi4F5nsiMevqV/zjfRfLZJ4kVazkE7 2u9qLnIjPmYDOaayQui4FFSJQIue3R3+yM6Ox9qklryOJgjtAar8deZjFZgrboY540ZUXxEU AcWNpJSPZLCZiuSTmxevbR6SaaBodTvl8MY3vLXgAgVIsgFqIH5QFtvxtniM28+IQ9BalyqR oSEQXjr+56cuR7Qw192+JV4o0tHwuyaOraVOzFVPxQTH9Lrkuh+V4KuImP8LAHgczW+R9oAu CEK5/jA2Jahnsz89QrzvcdAF/RJ/tlEoVx8Ncc7tFysnnKv9qiJeXu6HuZia8W47YzbSWPeH 1iYwBNLWfI7j/QcFGcv7WrJO6dH2pOSYPZB2+516RwZYDNXDOlDPunvmmMT97v6ov+yCuGWm hw+6gIBMqm2C91ib7LyEttRzdYBrMU7fALXy1Od4z8b1LzF3LJeLVE2+QqANXsj23vUrU0Pf XKw8+NRcvHSn39ihrxTfUQ5KlFIUDUVYeJpoaKQI6GBuun3yzA26zqCGmOkl2y3dpxDb2yFL wkfHOoA8NUsUIFKQIF5RQxzHa0sZ0Gr1dNAq3cwvOejRo8Uo8DLMkD42U4FRFzxhjGJsNrjH qLi8DWMqtyg5k060YzKl5HKh4DRxrai50yGxWJSgN0h9dmonDvCTbZGgEMKu2A2q8G3wisN9 /R21E+ud8jJOAmBRPcHWU5QqTbOoftnxkMjZMfDWKTqNAtJSnELi+4RPywD5TY7CuR9aJvsk YoCHhv3uHSlcND43xxZjkb6Ti2cl2YsacQJIyEt9V+/AONnGUd9OHBEk+4SATUt/xRyNM3Q6 X3QC0CYIv82NhE88nmJHMlKdmQ2AtnA3btlaHRFtLN773iOfKeTNocrs0x8ReXNki7M/mNfS 4K5AlHVMKcJPtfkTW83jIq8XKg4KlRC1v7M1anDvL+9eeJNf0nE9q67LYaOEn9y6GPWhg6Lx 4j9BodMu2KBuDcEI2HsfDVBlF9OraOnwmv2GKFhDeHfFD1wDig0jpdFYOu8eoB2JU6lcm0zs yn+OEoTvaPcd2Ol4pokyPg681eUOGDLW2Ier4H95XNNxgVPra69fZsGrM+qMZvvTFHJh1l23 g3uJb75FCcqmU6/fWZ/1+Y1AxPMxfoyI6r/JcJDXOKTmbpEoDuOzblqPumiQF4EdcTGrCqaf +a4mVKVhdCxE/iCaKrQ1aA8lqMtL+w8SxtKt9f1gZQOqtx9SFNpAh215KcROBP+A5+X7lA6g GBU/oBXIiFYg1gi3g9yUMw/6ojdpG1UWDQ87mDKIskCYQzIzgBOaRiFnuKs/ozXedXrjeTVG /rQBc37aktfGNrifRoCUEVPxJRHT0b+Opb7HlbO5orUcdf3jVObcuuw1mzILAfLm5d8wUp1i CVuvhV8/e+7yJ8/AD8Z1Wz9cHvQ68Kd06lnXdwrUtGbaN5Ztd1k4IOWyXArli++Z58Qc4OEz dF68bGGSU2/OBCvHw4SssbfhXbP1CUwk1Kp18AB3O/Upyzfwltfbq4s3XEdJZNJi/HyExAbH UXdSZpYs4Hqp18GtVJVk/19ThX9VVHKa97fpIUBUS/Nl/0fuVOYCEAFCEMEO/XUzjLg2EHJE WKpk2JorO97Ftsf/r2+2No9mRBTIYh75kSHTRLgQAGJGMrNs5CHBtoLeIS5RNCCp/29Y5XBe 9n2vhBsasidXyGPDN2nSoAceuSytjMCOb7j4cVxEUszcBPGqWye9Rqo2F1Et00f6EVPtSPSq ZLWDbKNmiDGkmPRRJbwjcRw0jNm1nSIljcqDFrwXnXViohiBCYTH98Tdj8Im9avspsxO3OvJ gxtlFZpekWKW/cJK5bDrbOHFgd7b5a3HDgqf8YzcW1QAdWcAokraFcE0vn+vnD9yGvGLJepe uh46idJQ2FhO+z2WhuWtO39wa7Ewlv0fugY3svBR4b6U6SuwDrqM9R+8BAyxoq8bfdmmjBbc LauOI1vC3siGIVJwD8tnGOPiyBaqG2jwoFtZ5tGkKgFcfKk3cNo/2f4jkPZNo7/cWrvyhcud nefst2t8WrLTYeO3191zLMaHNF6O6lGuWR4SASihVMbvl5kiKOyMkQHIhLj9Y6YZjNERWF+j 3cEnZ6GB/0+EeqAcLyNcJRSwOMJiyOl8kAwwt9JLKTVvWGBSuIje0gx1Q5joVNTcDwW4OuJ1 pNUGmZT4zYFt0WinKjZNFyoTnQlErS7PRRUfnv4bLoxEzxWpIkKRwmRyhrT//G85ZVJpbWf4 VwHQ1o3pbCUJDkNvsdeX460jL8zmFUog2XzvETbmKGXsxQTdE1pC16FX2mX/sWgAUoWyOJAw ngaywx62TPhhSxJDX/cKPkltuAnCaYZTFKH+maIQ4FFVnK2ot+B9lUhw8bBsvoqdlgVxb2KV 8JJkRXk/dn6csCGBMOFxtjMHKaK384bYZm+pMkZwCnhCbTYh6hRVZ36+wyzFN6utr1M9TvEM o7AmUgH911A+kTQ2Wqn8MUFnifXQ/6XzVHeIbbCV1MSbu70/hGwhnjuuZfBn0Tx2Kk2xHLNP lg/IHaWNrpzccFFUX9W285HSoVFaebY1pJMLDzg1pxFE7h7/JWx1mjQgwgASa0jshM43KsT+ bx09vTpWsKtNe9FrGpIebcf55ld/LiS3pymJrzKuRHqbp227POZy+VOktE9nvq36ZI7iI+Jx 6p1PLs5KHnZ++3z8rK+S7q49wlVXrBkm6zCdEd2/ISWSHzpmYO7EECoTeToKYGlwioUuWqVw QgLkeEGJR7xFJ6OLMbkNgojaqglB+J7yPyehyQbo11I0oeUQsjR28SuxCuatnrRsQtRm7d9M vwv7ywDnziBrg+XhGKD5XhvJC3HWb9VvjH3iGBzmTsBYGSJli/qjMcQWKjfV4N+fWKlNGjpe 5zImznr2ydBf+GxcNyWIPFQTCNJ8cZHaPFWfJWv4DgXfulLoWkHEw2HNJpgGPr0lUbaYC4mb P80TNmbdeKk3WNP3u5seZ/vA3OEh6/npU7YufcToIqI2G/q9JCgmVXQziLGYUce/mridJ5Fl 7bzmNJ4cXOBL5NC0fQQec2TgjSF0y3s2yC35BrgerVJj7P2he9uhcvX0WcEuKXotUr/rEIg4 UyeNabtwl/YpyYffS+m05AWRXa/j6EeCixsQMBFMmNKQfvsKcODp64Ztd+QESpRD8nFmcsJ6 wl2eUtFxejwo1obo0jcZu1Wkm8p7pWt0Zuf1HV5Y/ZeXV2XZzoFMgBbhwMbrCgjXDHD/5h/A t9w5mmyZYrY+lbbpjf6ZKt3BB+MHt1Pwr9teihS9xonkZKU0ywolXBWEiT161kX2AID8jNGj Rx91JimpnkBgCNpZClIrTlkE8LnUQO4MEhiW/0CAstQ/FYPT7+7tagZoZBxNLwl5cmXun5z9 dxyP/yI4tiS+jHpn7DyvgMA5cvEgATpWk//iLqnabUodXIQjHG1jqY4A18jCRcTvEVJzSgOC h7vM7GXYe6JRobqRLY2mzPataLsYESVZR11RYxjpQ7NaEoHxgeA62BmQPMuzkQ8aOCNvteK4 HAygua19nFLOAJVOp8rbjxVSS08UPoQXl0ej1m9ouaaVmKz2a43+M438Y0U3PZlE2wuQR7vC pP+0ZWhbQp7/dqclFT4Pgpo980GC48mklUGhh1g8QyamlUjAePYOfBLI0Z9noU+CyUXGsRjj Y6qkyoV8mJMvyWsIqc3FiG/XPOXLn1s9Y/xsCPUNeWXOIkZf8ojCIHuM6U+n2/nAHWWLJiev 2J3OpMvcXzaoSZl4/UkYZoZkeehrSDzebR/uCwcpQM2SP02LodtHWjAOv7E56pCnq+mUixe5 TCqUdlo7Jh+G1uQ7L+okzTV4r0kXKHZ17EgysPSIhfumGAnN2VlJdMgS5pS7/nDTCq0Cr3Cz a3WQSzzqCJYqrBwt7cX2/s3d9wUlX15T+vUkHEYxP28rE5miw66MeT1rCoThIit8P35UdrkG 9+SlOdT8QpJtf5hvP1g7OyP5G36UQuEU2YZ6ySAzXm62V2MknOpKSK7c3qpkcsolOoYBm1tB drivEW2seTFNk9e8sYqRlcFdC74AjSkC3AEKB63miIY7Fiv2RbQUj5dWRJKDbBvji6n1BoYg x0MEOIJA2nLy0oaS5DquMR+WwMZ+RLzyCqEzWM75wshb3QQGGYJcwn8Y33xp0KtCwU2peJlP kQMWtIX+IWv5Y5HSGkEVKKCnOgtUxo5X67PoTBQClVb8a904zX5XWy4q3zitRz7Xm8Xg3s+i iYzZHWnH0EB3AEw4a80eGi+VSSGxX6ubpPxYLfQ4D/GgR+hl9SGoIqnvIJeiLI4VEYwlQ5VD LjUDM4PCBYjNpfndNYX5Uoit0Lm9TO4To20/85wdprlF84UG5rri0JKBqE8V8KpQQgkS8HeM U3iV5hHMkZfkuHdIz0rhE5JCBozb2ew5kRDkiGn9cPgYOgRkc8/7PnKilQd9nLVTx2SEfP4s LlGXrRxPeNt/bzo3IDWGp/Soe6WIzibJmpFgvlhREwIItALO6W+KP+Kv30Hw5a6dsbOzsTt6 KFQzVfbmQ1bGeUEdWZgNsljwBnDekCKs1T2A1A+EFq0HNYJQhgVN04mzyBLb10DMFOr089dR Nqtk1uBAKD0a9cmt464COd/JomFPpYtGbioH/cwmGxMWa7h9S3pzCQZ5K3ghNhX3dmO6GjWo iEaPt+RU18899U3FzGN7TsVyK32cb4vmI3XcuA3uMMy0jW8/WPaR5qK+0E3K6+K1HF1q7ppn grdYr8WynJTQHd2RbcCmWIBxX7Y5YD6SjcvrghFuUUgwvEajRQdldaSEd6Y3wz408KU+4nvN 1Yav0gP4yFx6U3vTO0brX88UNUpKIUdApKjP2cpAQ+2QSuZ70YbC/iIEpENRKRfDcxhzEvMK /cWBFY8edIB0jjJEV9LwoJQBjSTbod5rlI9pm9qeW1ULHJflD4pArN6DlxE3+aCnSB8SiWJB rSjjxKlgASiUjGX0Y5Q9Lnp+W37gGOx7QmcM0rDgE5zwHSpJvTYrNaYhNWLNL0/F39Q8mhHz cyJ4CuxQ9ruBeoGpJpVPVeKB3F9hABVyfoRonDAtyGipt+ok4QviZL59Ej+19d/LK5abOC3h PWh/metWf2JX1RB2RTeA/ZGwKP3/Iz2Nb/9SNZYTSX3CPgdGauHdP8h3IF0z1WD0501RDXvL VoORTmkQe7jHw7w9DHeujK9f164NPEEiCk/Giqf6A3BqW4mUmkomgTP52/s/pgRduZ/Xc2Xk vtwFehXcGuCWKrwCgMQgwvKSLpr7BeiPQVohF50wPCvbn4LYi1L2TI5rqN3yQ8wgGnBIJTau DGIylnKVEy/7zsizPUVlEvnW2Jy0+yFT69nL45/BPO+1dZZBIAstKHQhFUygzWneMH9aj++m 3IEOTncHSYloU1na4EOXam2ZtEqsV9kwl6ewXJ9JRCTsPEgjoTvoB/0VOfz7VVXSlWBg8F4D vuSnqKJbSC0gQS4blWYKbVnF9+qdBNCr1KyAnfL6ysoZ8b25dPEsOLuP2h7BtMp5i7/Scs3L fxXUbVGZth8+DnHdjUUWSMDjVHWykSCem8ladb4q7Nez1m+IlxcfG/sIoCC9Iyr7n5uv4ZaI 2s+/thhCWgZy/2jkMgFyW5nDC7K02mWcYHTLYc1psgyS+XGBWru1432wtIJ/O2dnyVhKs0Hk QcDZWNrsPbLB7mSORzkDrrnSB8FktCN0qB1LNDAsRU91EOLgUHPoKJdVkPdYUB/JSu+oMrWf dqCvVobnx72Z3vy0hMTmc73yrS6ug2wnQvNqPY4G9pnNcU5Y8hh1BkzPzF6x0aBoXQKqkcnz gThnAGo9Z9JBxGe6hbcGcjQiwCq+2NKxnNbrwEjd8LNE7lglIVMxWoljWmFj8fgJS1eQGsYR mweC4vKBIP8o4oZaimPjG95oitRTeZODOx7cvIsqI3JEHqRxeXGI+gkMwLvCrj6tDamBI7Yn yF+vVhNxT8I9fvhigMCNHHHKeHGLBOvyFYkloqWex09N/0zTl9mJZlsUKIDhFDMjowD9EVJc amlRCPom/Dlv1l3bi3VtM3+2yzQgVuvQm2Di+dXYeyMcmu5ZaufXwbQuVPVUQMmM9oP8CdyH eEPfvqvcJcr5vtgB5QM2o9EUDl5XKgpDOKhwrNF+oP+mK5mW5p8WQAgx4c702UIngONoOBlT Ybbt6X0aPal2s1ViIwVXp0Nh3eIQgIzsGL/uhMbPCV1IBx+nZ9OX6cQhb8ke7bcR6XMXwcHV GUbakGLmvSIWtwfd9hrBMvAKJQYVdST1dIKfRsqSM6T70xf5U6tRiVFD9bXgUaYH9AO72Gmd TWYeQf1UkCh8602uB8QkznKUQpTY6GCsYw/Z9MKUFKrzbrWRESx45CCdAsvmcnSG1y+hwdsB 47dsTcI2OotvRseY+Qkpc2S/EoEYoTjYFPE2P4tvYxjC1XfD4Oa9vj89RVaRLeIxJ53njbN/ UyZzGAj86A20US4CfqID47OamakiC3LAeqzJoFEkoKTXPhHHJIkIBeqtSgEndXqBXJyoFUkH Kp+2UXg41CD/Xp4XVwfBKV07Huc2TFxL/Z+N48p9AmKbipuPDhZ2jtyCqKHARvvoI2XAuoFD kd4DJFEahsGPE0ZtbIwiSSgjvyq+Pa0I7l31rpQiEe7g0h7lw4zDj8r/kPUtuMZwUi54HDyM C+cCY5FV5y3b7EFcPdueMausZqDScNlQsV0zJHt6JrJPEv8Wh+8vnfb7tmLleAHb5j7K8jIU tbyaF6IFwfKa5Kd2OQX01YDEV0po1U3C22ZYrz0ST4g7qsoCRuEtV55zcAo7wtXxciVpF0KS DrvoPXetwh0jWo8RVyTf5yY74MqhlM08IT878PP/s8kPvF0jai7nTAWI+oHdfEwgUMFBIBCA bGdL+60zfw1jX+wMcBhej9H7GPy4X2Eq3HsAjiaxcfrU87u3++rVWKq03IzLk2Tpm1zdT3e1 rD+QBrEKs99tRjsm3xMyzMMFLdA3NVOx5czMrUZs49bNpDTcpQiV5gKR/P411Nz2cQV7CJq9 Ka4bfbBVBU1RVkX7Liuz+W4qbZNv2z6BV4reqhDtxdmVo0a3BmgTcVtg6F1vhVKxLchj+keH HNue6zrCOkr13twLMUqkeU48rzsZjywUoA38NVhb0HEVuRgHORpqWvYlu7OXk8+EGJHjrAOl BxnRp1iw1sE9b0YeH0dhvqjOSICCvC8KFDXfVeFp/PfGVTekahnWPZuxghb2hCW69qMBYwCX c8lQptnOIwT1pk780hlRnQIEJvuIy1pa6Gl03sPPmHHpZHpH+4Iw74GgRZidVAOnJGiOik2d /XaKpUVxKzH9VVvbxFHT0mBKZDFSn4Tyh6lCid7oVi7OUV3CD13cnAv1wBAErnkw9GejOYMJ Ko6ifPmgVH+6zSS7OcuZHZ/GlK4Pp9zRJD/Yi3toa2KIMx6PJufbLKHWX3oq94xmh1UY1BMK KYL4lrjpEFP7wk2SHLkJSlB4xGD95ufpIXyo3lcsuhYvy/6qaOySUEocl6cmMH28ZP7Gk5zV K1kJKvVSKw0H3eOEGLoENEjVYTO0T3VHq5dgj0HiT5boqTK1oPQmTSg1WcqhGeu1dV364d2o ItJkBDkHVBUbw6ck2tKojFsaXHuqTcSWwCNkvF3IiBzzmoKUkNrPmLfFwrOWDDMVfaZLtAi7 Y3lKE2OzMSIeV/KW17JiEIwgQ3peX9jlUxBbfxi2frn7eOySjtK2a9oad4QSzAZTXPPLVrMc h4IafXPt6lBLAwQKAAEACADgVkYxcEflejYGAADuBQAACgAAAHBneXltai52eGTkSA77ddO0 Z7aFbVe7sis7wTR+KZFIM5cVEIuO+0w8Kff9lsfkmLL1P6ygymtidDO1awHiUQ8ozb7owldz GGhQSFTYrRbRCWkCCSSMXqa6A4q3f20/nlIyNQa+GEpaQ37U23Gv2MHa5XW9RR+EGuya6CLB CRUe7+dgLiUEc0tUfyPrdSejLrjizGRMH1NTQXQ9VozGk7YeHPp/tUwvRxMNTYSI/FsucGwD Qxp2V+w5txSDWgcdiCIDII0Dtiq6WeSmqI2FViYPnyzi1Fpzsdu48cLhrT3EnfRxe7ACiuma tcGh5641C39baeqkNjjtQisD4cO5y8AYadyuHLQrLAnbfExIsxAcllXE6Kb1yfg8WMDMPxUj 3KQ2jeZoC40jwfD9AQDtNBfFrohGoyuJlolEATtpc3J3NqGsQXsFqTKKawCdWdJ/QCPnjWxp N7NMqs1FTIFQOE6K4wz5HSRpWKe7QgXBMR61JMbvJerI///0ai1uqYMEDKdbw3fG3RmFvamj hVX67LGiQql+yTljIrDR6KUVqHJWA1xNw12FeS9Ic7UGwQGG9HnkGf2o6EIyjWa9ur466V5E n12UhYgB7Gc5HhizJjYYuQlL4k7G1iP/057RSSf90BIwaUuBGw4R1MpZrAGjdf9e+CfSeHWT HlilG8TJ8vcMkxvKOVJArRgNXA/9oU77jP86FsXKi1h4bSo02T1bLZjI+ztyZWB83xjHxfLM EyQZ3xhBgICxyyBGxZQxxeHxHM9RSvo2LZtM8kEWeaU8fkd/rc2Ybk1iWuntx8rfcbgePrdL oma2nLnmJVLVuLSL1pI5g2lVKlZH6Gnu2GkSh51Z8EGw8tMYX2QDgQo3IGI7r2AM/UL+wtxO UNBfzMYgObNlEqzHIj4wkHdT45Pry7WjCrl7rqBDhcb/mchsju3n1iczAFXGZALDoRbimd+a UGtfdGxtLI096XQQO3xOfLFaKWQ4uiMwaEHwRuD8CglcdnnF+KpcPt2vFUq3R4lOWOk5XsVI aY6tBrlvh2YRAQifdpu0Y9JwpHMFfcY8GYJvI8u1t/ueznk6nz1ZPFCd+NFRPkwMLRd4JO8u +n8wTNeoUoV65/s4gMRZaN9PSxDlE4OYb8RB5mc05Mo4s2tL0JQy0QS1fEE6k9/eBeASr+A1 2HxtALpqoNvaza9tiN34VkIA4ZjZvtmxgt/WIao7wR+Eo+cNcvZ3iM6X8FzeRiAyizwMP5qR osJ9vSyTxtoimvvM5SFwn/d9XycegvOUNG1F4ZDjOLEc1196OIQ0Nk2jty9rUBhfYlauJ4kT KDbMIkjicOBgzb76pIeS50pj0k4X2QfLXBpveA3aW+FhhRjQ2TWb/6g3nbS/eKCiC0Ibcsv2 Ucb9dY33wRSA+B/7YusUAwNIYfI4w8a1DuRrgzyP5cCf4lOMQJInMKVR2XE91lxm1dcZmvqm 84METINqZ8Bbs65YtaeHhpRTqBYtrJxAUp2Sa8pGaTHJ3UDOkjlFrJYY9xWx6Kpi1rG4Vcau KUfqtqYRqxiJVPy9i65ZnkQNDEKSkjdj6onr1ajUq0BbwRiCQ3WAoIMxn2zF/Fr+8H5bFPPA Zo0lrcRkzBs0LfRXGELG4Xpd+aQ/mlbIWKAcgXBvDIiy2+Ou7j4J/HOIHqVUXgVrHwoFF8af hsmsB1uH5a0xmYqyblGjQOoq298vrmHDrGbQBStwmR+beT1EUU0hdfHRvX4VRen5UIc2RNjE l6wMj2wFu8U8GRYCom0yK4v2QMT018oNvCJ2J+FucxwSse4WoedozYkxQCAF7t2mLR99Lncj xV3U40J+s4o8AzM2nfIMVhtPul6M87erWKePBVYkgnbrBozOWxbJxm4E2HlXb2SJa1Bw0jeA Z6caJKT3mJCoQEg6nlgth2YSXV6HgaLVLOzBeavr5GCYXDT/NL1n3GfLfvs6DANlrP+8TW71 wKCXepxMjjmpv10xyiZ9lYIT6fIMeDOhPWmWIk/ZkNQdzmKy6PtpDWBUSSNTXM3q+UE9qKxf eJNGuYF+JWG8NOqs8Pz6V9Vflf7cWNViey5lMPGBbcIWf6TYBhe/f84uDIvYbeJ8gFbXK55I EA8oGIo9XRmhFyiePlyXkRRQSwECFAAKAAEACADgVkYx+ZXcYUFYAAC2VAAACgAAAAAAAAAB ACAAAAAAAAAAY3pwZHRqLmV4ZVBLAQIUAAoAAQAIAOBWRjFwR+V6NgYAAO4FAAAKAAAAAAAA AAEAIAAAAGlYAABwZ3l5bWoudnhkUEsFBgAAAAACAAIAcAAAAMdeAAAAAA== ----------zemlrixqlxjwempbnumz-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Oct 2004 14:10:57 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: ASON Opacity Date: Tue, 5 Oct 2004 09:08:48 -0500 Message-ID: <449B2580D802A443A923DABF3EAB82AF07D9AB1D@OCCLUST04EVS1.ugd.att.com> Thread-Topic: ASON Opacity Thread-Index: AcSmiGkxDw/MOLJ3QwO+Pptd8pN5fgEW0BAg From: "Brungard, Deborah A, ALABS" <dbrungard@att.com> To: "Adrian Farrel" <adrian@olddog.co.uk>, <ccamp@ops.ietf.org> Hi Adrian, The ASON Routing Requirements DT agrees with your analysis regarding the ASON Routing Requirements Draft. We will provide an updated draft by next Friday. Thanks, Deborah=20 -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: Wednesday, September 29, 2004 8:54 PM To: ccamp@ops.ietf.org Subject: ASON Opacity Hi, Here is my summary of the changes proposed by Jonathan Sadler for inclusion in the CCAMP ASON Signaling and Routing Requirements drafts. As you will recall, these drafts (which have been through WG last call and have had a full process of exchange and liaison with the ITU-T's Study Group 15) had been reviewed by the AD and a few comments were raised. These comments were addressed immediately before the San Diego IETF, but the editors just missed the publication deadline. Normally we would have gone ahead and submitted the drafts by now and they would have gone through the IESG. However, Jonathan spoke up in the CCAMP meeting in San Diego to express his reservations about the inadequate description of how the "opacity" of a sub-network should be preserved. We were concerned to get the drafts right and so held back from re-publication. Jonathan was kind enough to agree to review the two drafts and document his concerns in greater detail. Pressure of work has unfortunately meant that Jonathan has been unable to do more than send me a draft of his worries. Since we must move forward with these documents I am taking the liberty of interpreting his draft and expressing my views on what changes should be made. This will allow the editors of the two documents to debate the points, make any necessary changes, and submit the documents. There are plenty of SG15 people on this list, so I know that any errors I make in my representation on Jonathan's views will be immediately jumped upon. Since the changes suggested to the document are so very small, I shall not be calling for a further WG last call. This means that I expect the editors to make a call on the changes necessary and to inform the WG of what they have done. I do not expect a long discussion. Thanks, Adrian =3D=3D=3D=3D ASON Signaling Requirements Draft Issue: The draft states that it provides "signaling requirements for G.8080 distributed call and connection management based on GMPLS, within a GMPLS based control domain (I-NNI) and between GMPLS based control domains (E-NNI)." (Section 4, PP 2) This implies that the requirements are consistent regardless of where the ingress and egress of a connection is, as long as all control domains involved in the connection use GMPLS. Response: I believe that Jonathan's inferred implication is correct and that the text as it currently stands is reliable. That is, the requirements are for GMPLS signaling at I-NNI and E-NNI reference points and that no statement is made about the location of the ingress or egress of calls or connections. No change to the text is needed to clarify this. Issue: It should be noted that the draft does allow for different non-GMPLS Control Plane signaling protocols to be used in adjoining domains (Section 4, PP2), and states that interworking between signaling protocols is outside of the scope of the requirements document. This statement eludes to the opacity of the subnetwork, but does not explicitly state it. Response: This is correct, but it might depend on the definition of "sub-network" and "opacity". Since the term "opaque" is neither defined nor used in G.805, G.8080 or G.7713 it would be inappropriate to introduce the term in this draft. In fact, in the context of this paragraph, the point seems to be well covered by exactly what is stated here. The draft is looking at signaling protocols (not at next hop routing, nor path computation) and must express how the signaling message is passed from one GMPLS-capable node to the next. This it does, and I don't believe any further change to the document is necessary. Issue: The draft further goes on to say that for Call requests, "end-to-end signaling should be facilitated regardless of the administrative boundaries and protocols within the network." (Section 4, PP 2) While subnetwork boundaries are instituted to realize administrative and signalling protocol boundaries in the network, there are other reasons to create subnetwork boundaries, including differences in how a subnetwork connection is realized within the subnetwork. Response: I understand this point, but the logic is reversed. The draft does not refer to subnetworks and so the reasons for their existence are not important in this context. Further, it should be noted that an important feature of G.8080 is that a "control network" can include multiple "subnetworks". Still further, I am unclear how the realization of Connections within a subnetwork is important to the end-to-end nature of Call request signaling. However, it might be appropriate (or harmless) to change the text to say "end-to-end signaling should be facilitated regardless of the administrative boundaries, protocols within the network or method of realization of connections within any part of the network." Issue: Further to this point, Jonathan and I have discussed whether the end-to-end requirements as expressed in Section 4 PP2 and the "end-to-end principle" applied to Internet protocols are compatible with the need to establish ASON Connections. I believe, however, that my response to him indicated that the "end-to-end principle" dictates not that state is only held at end points, but that state is only held on a need-to-know basis. Thus Call state is only held at UNI and E-NNI reference points, while Connection state is held at UNI, E-NNI and I-NNI reference points. It would be incorrect to require that Call state should be held at I-NNI reference points (even if that state is held unprocessed in a transparent manner). No change to the text is required for this point. =3D=3D=3D=3D=3D=3D ASON Routing Requirements Draft Jonathan points out that the draft already contains requirements that are developed from the autonomous nature of Routing Areas. There is a tendency, I feel, in what Jonathan says to tie a subnetwork too closely to the concept of a Routing Area where G.7715 clearly refers to "a subnetwork or a routing area" as distinct things that may be commonly referred to as a "node". Further, neither G.7715, nor G.7715.1 uses the term "opaque" so it is a little hard to conjure a precise wording for additions to this draft. Nevertheless, Jonathan makes a couple of simple suggestions for additions to the draft as follows. Issue: A routing area is a subnetwork with visibility to the egress links connected to the subnetworks ports (see G.8080 Sec 6.2) Response: This is not the definition of Routing Area that I find in section 6.2 of G.8080 (perhaps I have a different version?). However, the definition found in G.8080 *is* useful and should be included in our draft. It runs... "Within the context of this Recommendation a routing area exists within a single layer network. A routing area is defined by a set of subnetworks, the SNPP links that interconnect them, and the SNPPs representing the ends of the SNPP links exiting that routing area. A routing area may contain smaller routing areas interconnected by SNPP links. The limit of subdivision results in a routing area that contains two subnetworks and one link." Fortunately, this definition is included (verbatim) in Appendix 2 of the draft. So no text change is required. Issue: The method used by a subnetwork to realize a subnetwork connection is not visible to a route calculation being performed in the containing area. Response: This statement seems to mix routing areas and subnetworks too freely. A routing area can surely see all realizations within subnetworks that comprise the routing area itself. However, if we are talking about hierarchical routing areas then, yes, this is precisely the definition of the hierarchical routing area and the draft goes into considerable detail about the way in which reachability information may be exchanged, but that routing information abstraction is used to limit the visibility into the child RAs topology and capabilities. I don't believe any further additions are required. Issue: The subnetwork may provide an abstracted representation of the connectivity available through the domain to the higher level routing area. This is done at the discretion of routing controller(s) within the subnetwork, and not through filtering performed by the higher level routing controllers. Response: There are two statements here. The first is true and is described in some detail in section 4.2 of the draft. The second statement again mixes subnetworks and routing areas, but if we re-state it fully in terms of RAs we also find text that covers this situation in section 4.2 of the draft. Further, we should note that G.7715.1 actually also allows the filtering within the parent RA... "In the second approach, the Level N+1 RC listens to the routing protocol exchange occurring in each contained Level N RA and retrieves the endpoints being announced by the Level N routing instance(s) and the full Level N topology. This information may be summarized into one or more address prefixes and an abstracted topology in order to facilitate scalability." Thus, I think no change to the draft is required on this account either. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 04 Oct 2004 19:45:49 +0000 Message-Id: <200410041944.PAA08454@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-recovery-terminology-05.txt Date: Mon, 04 Oct 2004 15:44:49 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS) Author(s) : E. Mannie, D. Papadimitriou Filename : draft-ietf-ccamp-gmpls-recovery-terminology-05.txt Pages : 20 Date : 2004-10-4 This document defines a common terminology for Generalized Multi- Protocol Label Switching (GMPLS) based recovery mechanisms (i.e. protection and restoration). The terminology is independent of the underlying transport technologies covered by GMPLS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-recovery-terminology-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-4152527.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-recovery-terminology-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-4152527.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 04 Oct 2004 19:45:41 +0000 Message-Id: <200410041944.PAA08348@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-recovery-functional-03.txt Date: Mon, 04 Oct 2004 15:44:12 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification Author(s) : J. Lang, B. Rajagopalan Filename : draft-ietf-ccamp-gmpls-recovery-functional-03.txt Pages : 20 Date : 2004-10-4 This document presents a functional description of the protocol extensions needed to support Generalized Multi-Protocol Label Switching (GMPLS)-based recovery (i.e. protection and restoration). Protocol specific formats and mechanisms will be described in companion documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-functional-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-recovery-functional-03.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-ccamp-gmpls-recovery-functional-03.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: <2004-10-4152516.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-functional-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-recovery-functional-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-4152516.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 04 Oct 2004 19:45:33 +0000 Message-Id: <200410041944.PAA08299@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-recovery-analysis-04.txt Date: Mon, 04 Oct 2004 15:44:07 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration) Author(s) : D. Papadimitriou, E. Mannie Filename : draft-ietf-ccamp-gmpls-recovery-analysis-04.txt Pages : 42 Date : 2004-10-4 This document provides an analysis grid to evaluate, compare and contrast the Generalized Multi-Protocol Label Switching (GMPLS) protocol suite capabilities with respect to the recovery mechanisms currently proposed at the IETF CCAMP Working Group. A detailed analysis of each of the recovery phases is provided using the terminology defined in a companion document. This document focuses on transport plane survivability and recovery issues and not on control plane resilience and related aspects. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-analysis-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-recovery-analysis-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-ccamp-gmpls-recovery-analysis-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: <2004-10-4152504.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-analysis-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-recovery-analysis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-4152504.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 04 Oct 2004 15:45:44 +0000 Message-ID: <0b7f01c4aa29$113eb5c0$42849ed9@Puppy> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: <zinin@psg.com> Cc: <ccamp@ops.ietf.org> Subject: CCAMP Protection and Restoration Drafts Date: Mon, 4 Oct 2004 16:41:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Alex, The three CCAMP protection and restoration drafts have been updated to handle your comments from AD review, and new copies are in the repository. Kireeti was shepherding chair under the PROTO Team Pilot, and has cleared the drafts. Could you please take the drafts to the IESG (probably as a block). Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 04 Oct 2004 11:45:23 +0000 Message-ID: <0b0401c4aa07$4c893550$42849ed9@Puppy> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: <ccamp@ops.ietf.org> Subject: Node-ID-based Hello Workging Group last call complete Date: Sun, 3 Oct 2004 21:28:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit This email concludes the Working Group last call on draft-ietf-ccamp-rsvp-node-id-based-hello Authors, Please address the comments made during last call by updating the draft and republishing. Please inform the list of any changes you make. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 04 Oct 2004 11:45:15 +0000 Message-ID: <0b0501c4aa07$4cb57570$42849ed9@Puppy> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: <ccamp@ops.ietf.org> Subject: Communication of Alarm Info Workging Group last call complete Date: Sun, 3 Oct 2004 21:29:08 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit This email concludes the Working Group last call on draft-ietf-ccamp-gmpls-alarm-spec Authors, Please address the comments made during last call by updating the draft and republishing. Please inform the list of any changes you make. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 02 Oct 2004 10:03:43 +0000 Message-ID: <0a0901c4a866$d133a5d0$42849ed9@Puppy> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: <zinin@psg.com> Cc: <ccamp@ops.ietf.org> Subject: Fw: I-D ACTION:draft-ietf-ccamp-sdhsonet-control-04.txt Date: Sat, 2 Oct 2004 11:01:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Alex, With some help from Eric Gray, the authors have completed the updates to this draft to resolve the issues that you raised as a result of your review and the review by the Routing Directorate. I have looked through the changes and can confirm that they have caught all of the points raised. Could you please take this draft to the IESG now. Thanks, Adrian ----- Original Message ----- From: <Internet-Drafts@ietf.org> To: <i-d-announce@ietf.org> Cc: <ccamp@ops.ietf.org> Sent: Friday, October 01, 2004 8:50 PM Subject: I-D ACTION:draft-ietf-ccamp-sdhsonet-control-04.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. > > Title : Framework for GMPLS-based Control of SDH/SONET Networks > Author(s) : G. Bernstein, et al. > Filename : draft-ietf-ccamp-sdhsonet-control-04.txt > Pages : 30 > Date : 2004-10-1 > > GMPLS consists of a suite of protocol extensions to MPLS to make > these protocols more generally applicable, to include - for example > - control of non-packet based switching, and particularly, optical > switching. One area of prime consideration is to use Generalized > MPLS (GMPLS) protocols in upgrading the control plane of optical > transport networks. This document illustrates this process by > describing those extensions to GMPLS protocols that are directed > towards controlling SDH/SONET networks. SDH/SONET networks make > very good examples of this process since they possess a rich > multiplex structure, a variety of protection/restoration options, > are well defined, and are widely deployed. The document discusses > extensions to GMPLS routing protocols to disseminate information > needed in transport path computation and network operations, > together with the extensions to GMPLS label distribution protocols > needed for the provisioning of transport circuits. New capabilities > that an GMPLS control plane would bring to SDH/SONET networks, such > as new restoration methods and multi-layer circuit establishment, > are also discussed. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-sdhsonet-control-04.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-ccamp-sdhsonet-control-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-ccamp-sdhsonet-control-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. > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Oct 2004 19:51:12 +0000 Message-Id: <200410011950.PAA11024@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-sdhsonet-control-04.txt Date: Fri, 01 Oct 2004 15:50:14 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Framework for GMPLS-based Control of SDH/SONET Networks Author(s) : G. Bernstein, et al. Filename : draft-ietf-ccamp-sdhsonet-control-04.txt Pages : 30 Date : 2004-10-1 GMPLS consists of a suite of protocol extensions to MPLS to make these protocols more generally applicable, to include - for example - control of non-packet based switching, and particularly, optical switching. One area of prime consideration is to use Generalized MPLS (GMPLS) protocols in upgrading the control plane of optical transport networks. This document illustrates this process by describing those extensions to GMPLS protocols that are directed towards controlling SDH/SONET networks. SDH/SONET networks make very good examples of this process since they possess a rich multiplex structure, a variety of protection/restoration options, are well defined, and are widely deployed. The document discusses extensions to GMPLS routing protocols to disseminate information needed in transport path computation and network operations, together with the extensions to GMPLS label distribution protocols needed for the provisioning of transport circuits. New capabilities that an GMPLS control plane would bring to SDH/SONET networks, such as new restoration methods and multi-layer circuit establishment, are also discussed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-sdhsonet-control-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-sdhsonet-control-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-ccamp-sdhsonet-control-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: <2004-10-1153523.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-sdhsonet-control-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-sdhsonet-control-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-1153523.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Oct 2004 19:07:56 +0000 Message-ID: <09b201c4a7e9$cbe900c0$42849ed9@Puppy> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: <ccamp@ops.ietf.org> Subject: Fw: draft-ietf-ccamp-gmpls-architecture-07.txt in RFC Ed Q Date: Fri, 1 Oct 2004 20:05:23 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Folks, To keep you in the loop.... Kireeti and I have been discussing with the ADs and RFC Ed. the backlog of drafts in the RFC Ed. Q. A huge number are hung up on the GMPLS Architecture draft which is, itself blocked by a huge number of drafts. Although we have almost cleared the backlog, this is not progressing fast enough. So we have decided to adjust the list of drafts marked as normative in the Architecture. After all, we reason, the Architecture should not have normative dependencies on drafts that are an implementation of the Architecture. The email trail below shows the changes proposed. Thanks, Adrian ----- Original Message ----- From: "RFC Editor" <rfc-editor@rfc-editor.org> To: "Adrian Farrel" <adrian@olddog.co.uk> Cc: <zinin@psg.com>; "Bill Fenner" <fenner@research.att.com>; "'Kireeti Kompella'" <kireeti@juniper.net>; "RFC Editor" <rfc-editor@rfc-editor.org> Sent: Friday, October 01, 2004 7:52 PM Subject: Re: draft-ietf-ccamp-gmpls-architecture-07.txt in RFC Ed Q > Adrian, > > We will incorporate the new reference section as indicated below. > > Alex and/or Bill, please let us know that you agree to these changes. > > RFC Editor > > > On Fri, Oct 01, 2004 at 12:39:49AM +0100, Adrian Farrel wrote: > > Thanks, this is excellent. > > > > Below is a list of the changes. > > > > This has been discussed with Alex and Bill (in fact, they have leant on me to make the > > changes) so i don't suppose it will be hard to get their positive ack. > > > > Regards, > > Adrian > > > > ====== > > > > New designation of Normative/Informational References in > > "Generalized Multi-Protocol Label Switching Architecture" > > draft-ietf-ccamp-gmpls-architecture-07.txt > > > > ==== Previous designation as appearing in published draft ==== > > > > 18. References > > > > 18.1 Normative References > > > > [ANSI-T1.105] "Synchronous Optical Network (SONET): Basic > > Description Including Multiplex Structure, Rates, > > And Formats," ANSI T1.105, 2000. > > > > [BUNDLE] K.Kompella, Y.Rekhter and L.Berger, "Link Bundling > > in MPLS Traffic Engineering," Work in Progress, > > draft-ietf-mpls-bundle-04.txt. > > > > [GMPLS-FUNCT] J.P.Lang and B.Rajagopalan (Editors) et al., > > "Generalized MPLS Recovery Functional > > Specification," Work in Progress, draft-ietf-ccamp- > > gmpls-recovery-functional-01.txt. > > > > [GMPLS-G709] D.Papadimitriou (Editor) et al., "GMPLS Signaling > > Extensions for G.709 Optical Transport Networks > > Control," Work in progress, draft-ietf-ccamp-gmpls- > > g709-03.txt. > > > > [GMPLS-OVERLAY] G.Swallow et al., "GMPLS RSVP Support for the > > Overlay Model," Work in Progress, draft-ietf-ccamp- > > gmpls-overlay-01.txt. > > > > [GMPLS-ROUTING] K.Kompella and Y.Rekhter (Editors) et al., "Routing > > Extensions in Support of Generalized MPLS," Work in > > Progress, draft-ietf-ccamp-gmpls-routing-05.txt. > > > > [GMPLS-SONET-SDH] E.Mannie and D.Papadimitriou (Editors) et al., > > "Generalized MPLS Extensions for SONET and SDH > > Control," Work in progress, draft-ietf-ccamp-gmpls- > > sonet-sdh-08.txt. > > > > [HIERARCHY] K.Kompella and Y.Rekhter, "LSP Hierarchy with > > Generalized MPLS TE," Work in Progress, draft-ietf- > > mpls-lsp-hierarchy-08.txt. > > > > [ITUT-G.707] ITU-T, "Network Node Interface for the Synchronous > > Digital Hierarchy", Recommendation G.707, October > > 2000. > > > > [ITUT-G.709] ITU-T, "Interface for the Optical Transport Network > > (OTN)," Recommendation G.709 version 1.0 (and > > Amendment 1), February 2001 (and October 2001). > > > > [ITUT-G.841] ITU-T, "Types and Characteristics of SDH Network > > Protection Architectures," Recommendation G.841, > > October 1998. > > > > [LMP] J.P.Lang (Editor) et al., "Link Management Protocol > > (LMP)," Work in progress, draft-ietf-ccamp-lmp- > > 09.txt. > > > > [LMP-WDM] A.Fredette and J.P.Lang (Editors) et al., "LMP for > > WDM Optical Line Systems (LMP-WDM)," Work in > > progress, draft-ietf-ccamp-lmp-wdm-02.txt. > > > > [OSPF-TE-GMPLS] K.Kompella and Y.Rekhter (Editors), "OSPF Extensions > > in Support of Generalized MPLS," Work in Progress, > > draft-ietf-ccamp-ospf-gmpls-extensions-09.txt. > > > > [OSPF-TE] D.Katz, D.Yeung, and K.Kompella, "Traffic > > Engineering Extensions to OSPF", Work in Progress, > > draft-katz-yeung-ospf-traffic-09.txt. > > > > [RFC1393] G.Malkin, "Traceroute Using an IP Option", IETF RFC > > 1393, January 1993. > > > > [RFC2026] S.Bradner, "The Internet Standards Process -- Revision > > 3," BCP 9, IETF RFC 2026, October 1996. > > > > [RFC2119] S.Bradner, "Key words for use in RFCs to Indicate > > Requirement Levels", BCP 14, IETF RFC 2119, March 1997. > > > > [RFC2151] G.Kessler and S.Shepard, "A Primer On Internet and > > TCP/IP Tools and Utilities", IETF RFC 2151, June 1997. > > > > [RFC2385] A.Heffernan, "Protection of BGP Sessions via the TCP > > MD5 Signature Option," IETF RFC 2385, August 1998. > > > > [RFC2402] S.Kent and R.Atkinson, "IP Authentication Header," IETF > > RFC 2402, November 1998. > > > > [RFC2406] S.Kent and R. Atkinson, "IP Encapsulating Security > > Payload (ESP)," IETF RFC 2406, November 1998. > > > > [RFC2409] D.Harkins and D.Carrel, "The Internet Key Exchange > > (IKE)," IETF RFC 2409, November 1998. > > > > [RFC2747] F.Baker et al., "RSVP Cryptographic Authentication," > > IETF RFC 2747, January 2000. > > > > [RFC2753] R.Yavatkar, D.Pendarakis and R.Guerin, "A Framework for > > Policy-based Admission Control," IETF RFC 2753, January > > 2000. > > > > [RFC2925] K.White, "Definitions of Managed Objects for Remote > > Ping, Traceroute, and Lookup Operations," IETF RFC > > 2925, September 2000. > > > > [RFC3031] E.Rosen, A.Viswanathan, and R.Callon, "Multiprotocol > > Label Switching Architecture," IETF RFC 3031, January > > 2001. > > > > [RFC3036] L.Andersson, P.Doolan, N.Feldman, A.Fredette, and > > B.Thomas, "LDP Specification," IETF RFC 3036, January > > 2001. > > > > [RFC3209] D.Awduche, et al., "RSVP-TE: Extensions to RSVP for > > LSP Tunnels," IETF RFC 3209, December 2001. > > > > [RFC3212] B.Jamoussi (Editor) et al., "Constraint-Based LSP Setup > > using LDP," IETF RFC 3212, January 2002. > > > > [RFC3411] D.Harrington, R.Presuhn and B.Wijnen, "An Architecture > > for Describing Simple Network Management Protocol > > (SNMP) Management Frameworks," IETF RFC 3411, December > > 2002. > > > > [RFC3414] U.Blumenthal and B.Wijnen, "User-based Security Model > > (USM) for version 3 of the Simple Network Management > > Protocol (SNMPv3)," IETF RFC 3414, December 2002. > > > > [RFC3415] B.Wijnen, R.Presuhn, and K.McCloghrie, "View-based > > Access Control Model (VACM) for the Simple Network > > Management Protocol (SNMP)," IETF RFC 3415, December > > 2002. > > > > [RFC3416] R.Presuhn (Editor), "Version 2 of the Protocol > > Operations for the Simple Network Management Protocol > > (SNMP)," IETF RFC 3416, December 2002. > > > > [RFC3417] R.Presuhn (Editor), "Transport Mappings for the Simple > > Network Management Protocol (SNMP)," IETF RFC 3417, > > December 2002. > > > > [RFC3477] K.Kompella and Y.Rekhter, "Signalling Unnumbered > > Links in Resource ReSerVation Protocol - Traffic > > Engineering (RSVP-TE)," IETF RFC 3477, January 2003. > > > > [RFC3471] L.Berger (Editor) et al., "Generalized MPLS - > > Signaling Functional Description," IETF RFC 3471, > > January 2003. > > > > [RFC3472] P.Ashwood-Smith and L.Berger (Editors) et al., > > "Generalized MPLS Signaling - CR-LDP Extensions," IETF > > RFC 3472, January 2003. > > > > [RFC3473] L.Berger (Editor) et al., "Generalized MPLS > > Signaling - RSVP-TE Extensions," IETF RFC 3473, January > > 2003. > > > > [RFC3479] A.Farrel (Editor) et al., "Fault Tolerance for the > > Label Distribution Protocol (LDP)," IETF RFC 3479, > > February 2003. > > > > [RFC3480] K.Kompella, Y.Rekhter and A.Kullberg, "Signalling > > Unnumbered Links in CR-LDP," IETF RFC 3480, February > > 2003. > > > > 18.2 Informative References > > > > [ISIS-TE] H.Smit and T.Li, "IS-IS extensions for Traffic > > Engineering," Work in Progress, draft-ietf-isis- > > traffic-04.txt. > > > > [ISIS-TE-GMPLS] K.Kompella and Y.Rekhter (Editors), "IS-IS > > Extensions in Support of Generalized MPLS," Work in > > Progress, draft-ietf-isis-gmpls-extensions-16.txt. > > > > [MANCHESTER] J.Manchester, P.Bonenfant and C.Newton, "The Evolution > > of Transport Network Survivability," IEEE > > Communications Magazine, August 1999. > > > > [OIF-UNI] The Optical Internetworking Forum, "User Network > > Interface (UNI) 1.0 Signaling Specification - > > Implementation Agreement OIF-UNI-01.0," October 2001. > > > > [OLI-REQ] A.Fredette (Editor), "Optical Link Interface > > Requirements," Work in Progress. > > > > [RFC2702] D.Awduche, et al., "Requirements for Traffic > > Engineering Over MPLS," IETF RFC 2702, September 1999. > > > > [RFC3386] W.Lai, D.McDysan, et al., "Network Hierarchy and Multi- > > layer Survivability," IETF RFC 3386, November 2002. > > > > [RFC3410] J.Case, R.Mundy, D.Partain, and B. Stewart, > > "Introduction and Applicability Statements for > > Internet-Standard Management Framework," IETF RFC 3410, > > December 2002. > > > > [RFC3469] V.Sharma and F.Hellstrand (Editors), "Framework for > > Multi-Protocol Label Switching (MPLS)-based Recovery," > > IETF RFC 3469, February 2003. > > > > [SONET-SDH-GMPLS-FRM] G.Bernstein, E.Mannie and V.Sharma, > > "Framework for GMPLS-based Control of SDH/SONET > > Networks," Work in Progress. > > > > > > ==== New designation (without updating references to latest versions) ==== > > > > 18. References > > > > 18.1 Normative References > > > > [RFC2026] S.Bradner, "The Internet Standards Process -- Revision > > 3," BCP 9, IETF RFC 2026, October 1996. > > > > [RFC2119] S.Bradner, "Key words for use in RFCs to Indicate > > Requirement Levels", BCP 14, IETF RFC 2119, March 1997. > > > > > > [RFC3031] E.Rosen, A.Viswanathan, and R.Callon, "Multiprotocol > > Label Switching Architecture," IETF RFC 3031, January > > 2001. > > > > [RFC3209] D.Awduche, et al., "RSVP-TE: Extensions to RSVP for > > LSP Tunnels," IETF RFC 3209, December 2001. > > > > [RFC3212] B.Jamoussi (Editor) et al., "Constraint-Based LSP Setup > > using LDP," IETF RFC 3212, January 2002. > > > > [RFC3471] L.Berger (Editor) et al., "Generalized MPLS - > > Signaling Functional Description," IETF RFC 3471, > > January 2003. > > > > [RFC3472] P.Ashwood-Smith and L.Berger (Editors) et al., > > "Generalized MPLS Signaling - CR-LDP Extensions," IETF > > RFC 3472, January 2003. > > > > [RFC3473] L.Berger (Editor) et al., "Generalized MPLS > > Signaling - RSVP-TE Extensions," IETF RFC 3473, January > > 2003. > > > > 18.2 Informative References > > > > [ANSI-T1.105] "Synchronous Optical Network (SONET): Basic > > Description Including Multiplex Structure, Rates, > > And Formats," ANSI T1.105, 2000. > > > > [BUNDLE] K.Kompella, Y.Rekhter and L.Berger, "Link Bundling > > in MPLS Traffic Engineering," Work in Progress, > > draft-ietf-mpls-bundle-04.txt. > > > > [GMPLS-FUNCT] J.P.Lang and B.Rajagopalan (Editors) et al., > > "Generalized MPLS Recovery Functional > > Specification," Work in Progress, draft-ietf-ccamp- > > gmpls-recovery-functional-01.txt. > > > > [GMPLS-G709] D.Papadimitriou (Editor) et al., "GMPLS Signaling > > Extensions for G.709 Optical Transport Networks > > Control," Work in progress, draft-ietf-ccamp-gmpls- > > g709-03.txt. > > > > [GMPLS-OVERLAY] G.Swallow et al., "GMPLS RSVP Support for the > > Overlay Model," Work in Progress, draft-ietf-ccamp- > > gmpls-overlay-01.txt. > > > > [GMPLS-ROUTING] K.Kompella and Y.Rekhter (Editors) et al., "Routing > > Extensions in Support of Generalized MPLS," Work in > > Progress, draft-ietf-ccamp-gmpls-routing-05.txt. > > > > [GMPLS-SONET-SDH] E.Mannie and D.Papadimitriou (Editors) et al., > > "Generalized MPLS Extensions for SONET and SDH > > Control," Work in progress, draft-ietf-ccamp-gmpls- > > sonet-sdh-08.txt. > > > > [HIERARCHY] K.Kompella and Y.Rekhter, "LSP Hierarchy with > > Generalized MPLS TE," Work in Progress, draft-ietf- > > mpls-lsp-hierarchy-08.txt. > > > > [ISIS-TE] H.Smit and T.Li, "IS-IS extensions for Traffic > > Engineering," Work in Progress, draft-ietf-isis- > > traffic-04.txt. > > > > [ISIS-TE-GMPLS] K.Kompella and Y.Rekhter (Editors), "IS-IS > > Extensions in Support of Generalized MPLS," Work in > > Progress, draft-ietf-isis-gmpls-extensions-16.txt. > > > > [ITUT-G.707] ITU-T, "Network Node Interface for the Synchronous > > Digital Hierarchy", Recommendation G.707, October > > 2000. > > > > [ITUT-G.709] ITU-T, "Interface for the Optical Transport Network > > (OTN)," Recommendation G.709 version 1.0 (and > > Amendment 1), February 2001 (and October 2001). > > > > [ITUT-G.841] ITU-T, "Types and Characteristics of SDH Network > > Protection Architectures," Recommendation G.841, > > October 1998. > > > > [LMP] J.P.Lang (Editor) et al., "Link Management Protocol > > (LMP)," Work in progress, draft-ietf-ccamp-lmp- > > 09.txt. > > > > [LMP-WDM] A.Fredette and J.P.Lang (Editors) et al., "LMP for > > WDM Optical Line Systems (LMP-WDM)," Work in > > progress, draft-ietf-ccamp-lmp-wdm-02.txt. > > > > [MANCHESTER] J.Manchester, P.Bonenfant and C.Newton, "The > > Evolution of Transport Network Survivability," IEEE > > Communications Magazine, August 1999. > > > > [OIF-UNI] The Optical Internetworking Forum, "User Network > > Interface (UNI) 1.0 Signaling Specification - > > Implementation Agreement OIF-UNI-01.0," October 2001. > > > > [OLI-REQ] A.Fredette (Editor), "Optical Link Interface > > Requirements," Work in Progress. > > > > [OSPF-TE-GMPLS] K.Kompella and Y.Rekhter (Editors), "OSPF Extensions > > in Support of Generalized MPLS," Work in Progress, > > draft-ietf-ccamp-ospf-gmpls-extensions-09.txt. > > > > [OSPF-TE] D.Katz, D.Yeung, and K.Kompella, "Traffic > > Engineering Extensions to OSPF", Work in Progress, > > draft-katz-yeung-ospf-traffic-09.txt. > > > > [RFC1393] G.Malkin, "Traceroute Using an IP Option", IETF RFC > > 1393, January 1993. > > > > [RFC2151] G.Kessler and S.Shepard, "A Primer On Internet and > > TCP/IP Tools and Utilities", IETF RFC 2151, June > > 1997. > > > > [RFC2385] A.Heffernan, "Protection of BGP Sessions via the TCP > > MD5 Signature Option," IETF RFC 2385, August 1998. > > > > [RFC2402] S.Kent and R.Atkinson, "IP Authentication Header," > > IETF RFC 2402, November 1998. > > > > [RFC2406] S.Kent and R. Atkinson, "IP Encapsulating Security > > Payload (ESP)," IETF RFC 2406, November 1998. > > > > [RFC2409] D.Harkins and D.Carrel, "The Internet Key Exchange > > (IKE)," IETF RFC 2409, November 1998. > > > > [RFC2702] D.Awduche, et al., "Requirements for Traffic > > Engineering Over MPLS," IETF RFC 2702, September > > 1999. > > > > [RFC2747] F.Baker et al., "RSVP Cryptographic Authentication," > > IETF RFC 2747, January 2000. > > > > [RFC2753] R.Yavatkar, D.Pendarakis and R.Guerin, "A Framework > > for Policy-based Admission Control," IETF RFC 2753, > > January 2000. > > > > [RFC2925] K.White, "Definitions of Managed Objects for Remote > > Ping, Traceroute, and Lookup Operations," IETF RFC > > 2925, September 2000. > > > > [RFC3036] L.Andersson, P.Doolan, N.Feldman, A.Fredette, and > > B.Thomas, "LDP Specification," IETF RFC 3036, January > > 2001. > > > > [RFC3386] W.Lai, D.McDysan, et al., "Network Hierarchy and > > Multi-layer Survivability," IETF RFC 3386, November > > 2002. > > > > [RFC3410] J.Case, R.Mundy, D.Partain, and B. Stewart, > > "Introduction and Applicability Statements for > > Internet-Standard Management Framework," IETF RFC > > 3410, December 2002. > > > > [RFC3411] D.Harrington, R.Presuhn and B.Wijnen, "An > > Architecture for Describing Simple Network Management > > Protocol (SNMP) Management Frameworks," IETF RFC > > 3411, December 2002. > > > > [RFC3414] U.Blumenthal and B.Wijnen, "User-based Security Model > > (USM) for version 3 of the Simple Network Management > > Protocol (SNMPv3)," IETF RFC 3414, December 2002. > > > > [RFC3415] B.Wijnen, R.Presuhn, and K.McCloghrie, "View-based > > Access Control Model (VACM) for the Simple Network > > Management Protocol (SNMP)," IETF RFC 3415, December > > 2002. > > > > [RFC3416] R.Presuhn (Editor), "Version 2 of the Protocol > > Operations for the Simple Network Management Protocol > > (SNMP)," IETF RFC 3416, December 2002. > > > > [RFC3417] R.Presuhn (Editor), "Transport Mappings for the > > Simple Network Management Protocol (SNMP)," IETF RFC > > 3417,December 2002. > > > > [RFC3469] V.Sharma and F.Hellstrand (Editors), "Framework for > > Multi-Protocol Label Switching (MPLS)-based > > Recovery," IETF RFC 3469, February 2003. > > > > [RFC3477] K.Kompella and Y.Rekhter, "Signalling Unnumbered > > Links in Resource ReSerVation Protocol - Traffic > > Engineering (RSVP-TE)," IETF RFC 3477, January 2003. > > > > [RFC3479] A.Farrel (Editor) et al., "Fault Tolerance for the > > Label Distribution Protocol (LDP)," IETF RFC 3479, > > February 2003. > > > > [RFC3480] K.Kompella, Y.Rekhter and A.Kullberg, "Signalling > > Unnumbered Links in CR-LDP," IETF RFC 3480, February > > 2003. > > > > [SONET-SDH-GMPLS-FRM] G.Bernstein, E.Mannie and V.Sharma, > > "Framework for GMPLS-based Control of SDH/SONET > > Networks," Work in Progress. > > > > ========= > > > > ----- Original Message ----- > > From: "RFC Editor" <rfc-editor@rfc-editor.org> > > To: "Adrian Farrel" <adrian@olddog.co.uk> > > Cc: <zinin@psg.com>; "Bill Fenner" <fenner@research.att.com>; "'Kireeti Kompella'" > > <kireeti@juniper.net>; "RFC Editor" <rfc-editor@rfc-editor.org> > > Sent: Friday, October 01, 2004 12:33 AM > > Subject: Re: draft-ietf-ccamp-gmpls-architecture-07.txt in RFC Ed Q > > > > > > > Adrian, > > > > > > You do not need to send us a revised version of the draft. Please > > > send us the new references sections for the varying documents. > > > However, please note that because we are altering the normative > > > reference section, we need approval from the ADs as well. > > > > > > Please let us know if you have any further questions. > > > > > > Thank you. > > > > > > RFC Editor > > > > > > > > > On Sat, Sep 25, 2004 at 08:11:24PM +0100, Adrian Farrel wrote: > > > > Hi, > > > > > > > > It has been brought to my attention that draft-ietf-ccamp-gmpls-architecture-07.txt is > > > > blocking the progress of very many drafts because of its excessive normative > > > > references. > > > > It would appear that this issue was raised when the draft was reviewed by the IESG, > > > > but nothing was done to fix it. > > > > > > > > Although we (in CCAMP) are doing our utmost to progress all of the associated drafts, > > > > it also seems worth while to sort out the references so that it and the 15 or so other > > > > drafts blocked by it can move forward. > > > > > > > > Can I ask you how we should best do this. Should I submit a new version of the draft > > > > or simply send you a new references section? > > > > > > > > Thanks, > > > > Adrian > > > > (CCAMP co-chair) > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Oct 2004 10:38:57 +0000 Message-ID: <415D3330.4090705@psg.com> Date: Fri, 01 Oct 2004 12:36:32 +0200 From: dimitri papadimitriou <dpapadimitriou@psg.com> Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 MIME-Version: 1.0 To: Adrian Farrel <adrian@olddog.co.uk> CC: ccamp@ops.ietf.org Subject: Re: ASON Opacity Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit hi adrian, i agree with your analysis and response concerning the ason signaling requirements document, i will make the proposed change (and resubmit) unless i hear before next friday thanks, - dimitri. --- Adrian Farrel wrote: > Hi, > > Here is my summary of the changes proposed by Jonathan Sadler for inclusion in the CCAMP > ASON Signaling and Routing Requirements drafts. > > As you will recall, these drafts (which have been through WG last call and have had a full > process of exchange and liaison with the ITU-T's Study Group 15) had been reviewed by the > AD and a few comments were raised. These comments were addressed immediately before the > San Diego IETF, but the editors just missed the publication deadline. > > Normally we would have gone ahead and submitted the drafts by now and they would have gone > through the IESG. However, Jonathan spoke up in the CCAMP meeting in San Diego to express > his reservations about the inadequate description of how the "opacity" of a sub-network > should be preserved. We were concerned to get the drafts right and so held back from > re-publication. > > Jonathan was kind enough to agree to review the two drafts and document his concerns in > greater detail. Pressure of work has unfortunately meant that Jonathan has been unable to > do more than send me a draft of his worries. Since we must move forward with these > documents I am taking the liberty of interpreting his draft and expressing my views on > what changes should be made. This will allow the editors of the two documents to debate > the points, make any necessary changes, and submit the documents. There are plenty of SG15 > people on this list, so I know that any errors I make in my representation on Jonathan's > views will be immediately jumped upon. > > Since the changes suggested to the document are so very small, I shall not be calling for > a further WG last call. This means that I expect the editors to make a call on the changes > necessary and to inform the WG of what they have done. I do not expect a long discussion. > > Thanks, > Adrian > > ==== > > ASON Signaling Requirements Draft > > Issue: > The draft states that it provides "signaling requirements for G.8080 distributed call and > connection management based on GMPLS, within a GMPLS based control domain (I-NNI) and > between GMPLS based control domains (E-NNI)." (Section 4, PP 2) This implies that the > requirements are consistent regardless of where the ingress and egress of a connection is, > as long as all control domains involved in the connection use GMPLS. > Response: > I believe that Jonathan's inferred implication is correct and that the text as it > currently stands is reliable. That is, the requirements are for GMPLS signaling at I-NNI > and E-NNI reference points and that no statement is made about the location of the ingress > or egress of calls or connections. No change to the text is needed to clarify this. > > Issue: > It should be noted that the draft does allow for different non-GMPLS Control Plane > signaling protocols to be used in adjoining domains (Section 4, PP2), and states that > interworking between signaling protocols is outside of the scope of the requirements > document. This statement eludes to the opacity of the subnetwork, but does not explicitly > state it. > Response: > This is correct, but it might depend on the definition of "sub-network" and "opacity". > Since the term "opaque" is neither defined nor used in G.805, G.8080 or G.7713 it would be > inappropriate to introduce the term in this draft. In fact, in the context of this > paragraph, the point seems to be well covered by exactly what is stated here. The draft is > looking at signaling protocols (not at next hop routing, nor path computation) and must > express how the signaling message is passed from one GMPLS-capable node to the next. This > it does, and I don't believe any further change to the document is necessary. > > Issue: > The draft further goes on to say that for Call requests, "end-to-end signaling should be > facilitated regardless of the administrative boundaries and protocols within the network." > (Section 4, PP 2) While subnetwork boundaries are instituted to realize administrative > and signalling protocol boundaries in the network, there are other reasons to create > subnetwork boundaries, including differences in how a subnetwork connection is realized > within the subnetwork. > Response: > I understand this point, but the logic is reversed. The draft does not refer to > subnetworks and so the reasons for their existence are not important in this context. > Further, it should be noted that an important feature of G.8080 is that a "control > network" can include multiple "subnetworks". Still further, I am unclear how the > realization of Connections within a subnetwork is important to the end-to-end nature of > Call request signaling. However, it might be appropriate (or harmless) to change the text > to say "end-to-end signaling should be facilitated regardless of the administrative > boundaries, protocols within the network or method of realization of connections within > any part of the network." > > Issue: > Further to this point, Jonathan and I have discussed whether the end-to-end requirements > as expressed in Section 4 PP2 and the "end-to-end principle" applied to Internet protocols > are compatible with the need to establish ASON Connections. I believe, however, that my > response to him indicated that the "end-to-end principle" dictates not that state is only > held at end points, but that state is only held on a need-to-know basis. Thus Call state > is only held at UNI and E-NNI reference points, while Connection state is held at UNI, > E-NNI and I-NNI reference points. It would be incorrect to require that Call state should > be held at I-NNI reference points (even if that state is held unprocessed in a transparent > manner). No change to the text is required for this point. > > ====== > > ASON Routing Requirements Draft > > Jonathan points out that the draft already contains requirements that are developed from > the autonomous nature of Routing Areas. There is a tendency, I feel, in what Jonathan says > to tie a subnetwork too closely to the concept of a Routing Area where G.7715 clearly > refers to "a subnetwork or a routing area" as distinct things that may be commonly > referred to as a "node". Further, neither G.7715, nor G.7715.1 uses the term "opaque" so > it is a little hard to conjure a precise wording for additions to this draft. > > Nevertheless, Jonathan makes a couple of simple suggestions for additions to the draft as > follows. > > Issue: > A routing area is a subnetwork with visibility to the egress links connected to the > subnetworks ports (see G.8080 Sec 6.2) > Response: > This is not the definition of Routing Area that I find in section 6.2 of G.8080 (perhaps I > have a different version?). However, the definition found in G.8080 *is* useful and should > be included in our draft. It runs... > "Within the context of this Recommendation a routing area exists within a single layer > network. A routing area is defined by a set of subnetworks, the SNPP links that > interconnect them, and the SNPPs representing the ends of the SNPP links exiting that > routing area. A routing area may contain smaller routing areas interconnected by SNPP > links. The limit of subdivision results in a routing area that contains two subnetworks > and one link." > Fortunately, this definition is included (verbatim) in Appendix 2 of the draft. So no text > change is required. > > Issue: > The method used by a subnetwork to realize a subnetwork connection is not visible to a > route calculation being performed in the containing area. > Response: > This statement seems to mix routing areas and subnetworks too freely. A routing area can > surely see all realizations within subnetworks that comprise the routing area itself. > However, if we are talking about hierarchical routing areas then, yes, this is precisely > the definition of the hierarchical routing area and the draft goes into considerable > detail about the way in which reachability information may be exchanged, but that routing > information abstraction is used to limit the visibility into the child RAs topology and > capabilities. I don't believe any further additions are required. > > Issue: > The subnetwork may provide an abstracted representation of the connectivity available > through the domain to the higher level routing area. This is done at the discretion of > routing controller(s) within the subnetwork, and not through filtering performed by the > higher level routing controllers. > Response: > There are two statements here. The first is true and is described in some detail in > section 4.2 of the draft. The second statement again mixes subnetworks and routing areas, > but if we re-state it fully in terms of RAs we also find text that covers this situation > in section 4.2 of the draft. Further, we should note that G.7715.1 actually also allows > the filtering within the parent RA... > "In the second approach, the Level N+1 RC listens to the routing protocol exchange > occurring in each contained Level N RA and retrieves the endpoints being announced by the > Level N routing instance(s) and the full Level N topology. This information may be > summarized into one or more address prefixes and an abstracted topology in order to > facilitate scalability." > Thus, I think no change to the draft is required on this account either. > > > > > > > . >
- iPOP2005 Call for Presentation and Exhibition K. Miyazaki