From mpls-interop-bounces@ietf.org Mon Jun 2 13:50:58 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CEBF3A6952; Mon, 2 Jun 2008 13:50:58 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D01D93A691E for ; Mon, 2 Jun 2008 13:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rv1ZS7pikrzK for ; Mon, 2 Jun 2008 13:50:56 -0700 (PDT) Received: from fw.testbed.se (smtp.testbed.se [80.86.78.228]) by core3.amsl.com (Postfix) with ESMTP id BE2EB3A6AC2 for ; Mon, 2 Jun 2008 13:50:04 -0700 (PDT) Received: from MailerDaemon by fw.testbed.se with local-bsmtp (Exim 4.63) (envelope-from ) id 1K3Gyg-0001FM-I3 for mpls-interop@ietf.org; Mon, 02 Jun 2008 22:50:02 +0200 Received: from h133n2fls33o883.telia.com ([217.208.62.133]:62323 helo=[192.168.0.100]) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1K3Gye-0001F1-7B for mpls-interop@ietf.org; Mon, 02 Jun 2008 22:50:00 +0200 Message-ID: <48445CE5.9080901@pi.nu> Date: Mon, 02 Jun 2008 22:49:41 +0200 From: Loa Andersson User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: mpls-interop@ietf.org Subject: [Mpls-interop] MEAF team meeting Tuesday X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org All, I've decided to cancel the MEAD team call tomorrow, and schedule a joint MEAD team / editors meeting next Tuesday. Until then I want to straighten out the missing issues and have every editor team respond to the scheduling issues; I also plan to use that meeting to start planning the MPLS TP meeting in Dublin. /Loa -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.nu _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop From mpls-interop-bounces@ietf.org Mon Jun 9 03:50:48 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DFD63A6A13; Mon, 9 Jun 2008 03:50:48 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB2523A6A82 for ; Mon, 9 Jun 2008 03:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.474 X-Spam-Level: X-Spam-Status: No, score=-6.474 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23urdlOJ13nS for ; Mon, 9 Jun 2008 03:50:46 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 65C763A6A13 for ; Mon, 9 Jun 2008 03:50:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,612,1204498800"; d="ics'?eml'208?scan'208,208,217";a="11126542" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 09 Jun 2008 12:50:54 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m59AorU2001673; Mon, 9 Jun 2008 12:50:53 +0200 Received: from stewart-bryants-computer.local (ams3-vpn-dhcp4654.cisco.com [10.61.82.45]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m59AorOv028739; Mon, 9 Jun 2008 10:50:53 GMT Message-ID: <484D0B15.8020402@cisco.com> Date: Mon, 09 Jun 2008 11:51:01 +0100 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: mpls-interop@ietf.org Content-Type: multipart/mixed; boundary="------------010701060901050309090907" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=19830; t=1213008653; x=1213872653; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20[Fwd=3A=20Meeting=3A=20Bryant=20{Meeting=20ID=3 A=20310271828}] |Sender:=20; bh=fP3BPpA0cnrA7D3nIykB/55A5a29MM4aFfYlKrTIgx4=; b=WOoB9CFLSgmfq1JLtP2tkkD4f7fnnIRYdRxv5u64H9OOG6V/bcIEXL7/ZD SUlcsKeRdZZVLxU5yOi8t1W79Oqm9sIYVOqvlNWmTnc44RAWw+6RH/A1qKJi GZ8Y2cVij/; Authentication-Results: ams-dkim-2; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [Mpls-interop] [Fwd: Meeting: Bryant {Meeting ID: 310271828}] X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org This is a multi-part message in MIME format. --------------010701060901050309090907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Loa asked me to schedule a MEAD conf call for tomorrow. It is the usual time 5pm UK, 6pm Sweden, 12noon East Coast and 9am California. Usual dialin - see attached Stewart --------------010701060901050309090907 Content-Type: message/rfc822; name="Meeting: Bryant {Meeting ID: 310271828}.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Meeting: Bryant {Meeting ID: 310271828}.eml" X-Account-Key: account3 X-Mozilla-Keys: Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m59AU3Z10147 for ; Mon, 9 Jun 2008 11:30:04 +0100 (BST) X-IronPort-AV: E=Sophos;i="4.27,611,1204498800"; d="ics'?scan'208,217";a="11123984" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 09 Jun 2008 12:30:02 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m59AU2Ka022837 for ; Mon, 9 Jun 2008 12:30:02 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m59AU2Tr019954 for ; Mon, 9 Jun 2008 10:30:02 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jun 2008 12:30:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:calendarmessage MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8CA1B.C695E2B9" Subject: Meeting: Bryant {Meeting ID: 310271828} Date: Mon, 9 Jun 2008 12:30:02 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Index: AcjKG8aVNX2gBonxSlKNa6jubGkxVw== From: "mp-ams-c1-olk.svc" To: "Stewart Bryant (stbryant)" X-OriginalArrivalTime: 09 Jun 2008 10:30:02.0676 (UTC) FILETIME=[C6B55740:01C8CA1B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=16641; t=1213007402; x=1213871402; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mp-ams-c1-olk.svc@cisco.com; z=From:=20=22mp-ams-c1-olk.svc=22=20 |Subject:=20Meeting=3A=20Bryant=20{Meeting=20ID=3A=20310271 828} |Sender:=20; bh=XlQwsBZD+AzsRKqTKCyRV573FYJ6OuqWiq45jlG31cs=; b=MducBxeb6Zw9d3Aym6/FmCI0qGAPmh3zQyFZDUxO1mXA6kqYfXiHPtEsqj lOAWZtJMfKJ+Z9i4CuuytaqiFvBJyOExA1sUZPW/HYJfXCBIIAEkz/s2GxGh ERH7Uq5zrf; Authentication-Results: ams-dkim-1; header.From=mp-ams-c1-olk.svc@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); This is a multi-part message in MIME format. ------_=_NextPart_001_01C8CA1B.C695E2B9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stewart Bryant has invited you to a Cisco Unified MeetingPlace = Conference Date/Time: June 10, 2008 at 05:00PM Europe/London Length: 60 Frequency: once Meeting ID: 310271828 Meeting Password: =20 Global Access Numbers: http://cisco.com/en/US/about/doing_business/conferencing/index.html San Jose, CA: +408.525.6800 RTP: +919.392.3330 =20 US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 India: +91.80.4103.3979 Germany: +49.619.6773.9002 Japan: +81.3.5763.9394 China: +86.10.8515.5666 TO ATTEND A WEB AND VOICE CONFERENCE: CISCO INTRANET ATTENDEES Join the Web & Voice Conference* 1. Go to http://meetingplaceinternal.cisco.com/join.asp?310271828 2. Enter your CEC User ID & Password then click OK - Accept any security warnings you receive and wait for the Meeting Room = to initialize** 3. Click on CONNECT from the Meeting Room to join the Voice Conference = portion of the meeting EXTERNAL ATTENDEES - Outside the Cisco Intranet Join the Web & Voice Conference* 1. Go to http://meetingplace.cisco.com/join.asp?310271828 2. Fill in the My Name is field then click Attend Meeting - If you have a CEC User ID, click on the Cisco icon - Accept any security warnings you receive and wait for the Meeting Room = to initialize** 3. Click on CONNECT from the Meeting Room to join the Voice Conference = portion of the meeting - Note: Guest users will see a link to the Global Access Numbers. *If this is your first time attending a Web Conference, disable any = pop-up blockers and visit = http://meetingplace.cisco.com/mpweb/scripts/browsertestupper.asp to test = your web browser for compatibility with the Web Conference. **The meeting will not start until the Host of the meeting arrives - if = you'd like to start the meeting with your Profile, please review the = steps below to attend a Voice Only Conference as a Guest then follow the = system prompts. TO ATTEND A RESERVATIONLESS VOICE ONLY CONFERENCE AS THE HOST 1. Dial into Cisco Unified MeetingPlace (view the Access Numbers and = link above) 2. Press 1 to attend the meeting 3. Enter the Meeting ID 310271828 followed by # key 4. Follow the prompts to record your name and enter the waiting room 5. Press 2 then enter your Profile Password to initiate your meeting AS A GUEST 1. Follow steps 1-4 above to access the meeting 2. You will be placed in a waiting room until the Host initiates the = meeting SUPPORT Information about this Conference: Contact Stewart Bryant, 442088248828 Cisco IT Support Center: Attend the Voice Conference and then press #0 = on your phone keypad ------_=_NextPart_001_01C8CA1B.C695E2B9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Meeting: Bryant {Meeting ID: 310271828}

Stewart Bryant has invited you = to a Cisco Unified MeetingPlace Conference

Date/Time:           &n= bsp;   June 10, 2008 at 05:00PM Europe/London
Length:           &n= bsp;      60
Frequency:           &n= bsp;   once
Meeting ID:           &n= bsp;  310271828
Meeting = Password:       

Global Access = Numbers:
http://cisco.com/en/US/about/doing_business/conferencing/index.html

    San Jose, CA: +408.525.6800    = RTP:           &n= bsp;  +919.392.3330     =20
    = US/Canada:  = +1.866.432.9903    United Kingdom:   +44.20.8824.0117
    = India:      = +91.80.4103.3979   Germany:          = +49.619.6773.9002
    = Japan:      = +81.3.5763.9394    China:            = +86.10.8515.5666

TO ATTEND A WEB AND VOICE = CONFERENCE:

CISCO = INTRANET ATTENDEES
Join the Web & Voice = Conference*
1. Go to http://= meetingplaceinternal.cisco.com/join.asp?310271828
2. Enter your CEC User ID & Password then click OK
- Accept any security warnings = you receive and wait for the Meeting Room to initialize**
3. Click on CONNECT from the Meeting Room to join the Voice Conference = portion of the meeting

EXTERNAL = ATTENDEES - Outside the Cisco Intranet
Join the Web & Voice = Conference*
1. Go to http://meetingp= lace.cisco.com/join.asp?310271828
2. Fill in the My Name is field then click Attend Meeting
- If you have a CEC User ID, = click on the Cisco icon
- Accept any security warnings = you receive and wait for the Meeting Room to initialize**
3. Click on CONNECT from the Meeting Room to join the Voice Conference = portion of the meeting
- Note: Guest users will see a link to the Global Access Numbers.

*If this is your = first time attending a Web Conference, disable any pop-up blockers and = visit http://meetingplace.cisco.com/mpweb/scripts/browsertestupper.asp to test your web browser for = compatibility with the Web Conference.

**The meeting will = not start until the Host of the meeting arrives - if you'd like to start = the meeting with your Profile, please review the steps below to attend a = Voice Only Conference as a Guest then follow the system = prompts.

TO ATTEND A RESERVATIONLESS VOICE = ONLY CONFERENCE

AS THE = HOST
1. Dial into Cisco Unified = MeetingPlace (view the Access Numbers and link above)
2. Press 1 to attend the meeting
3. Enter the Meeting = ID 310271828 followed = by # key
4. Follow the prompts to record = your name and enter the waiting room
5. Press 2 then enter your Profile Password to = initiate your meeting

AS A = GUEST
1. Follow steps 1-4 above to = access the meeting
2. You will be placed in a = waiting room until the Host initiates the meeting

SUPPORT
Information about this = Conference: Contact = Stewart Bryant, 442088248828
Cisco IT Support = Center: Attend the Voice = Conference and then press #0 on your phone keypad

------_=_NextPart_001_01C8CA1B.C695E2B9 Content-class: urn:content-classes:calendarmessage Content-Type: text/calendar; method=REQUEST; name="meeting.ics" Content-Transfer-Encoding: 8bit BEGIN:VCALENDAR METHOD:REQUEST PRODID:Microsoft CDO for Microsoft Exchange VERSION:2.0 BEGIN:VEVENT DTSTAMP:20080609T103002Z DTSTART:20080610T160000Z SUMMARY:Meeting: Bryant {Meeting ID: 310271828} UID:040000008200E00074C5B7101A82E00800000000C0C451C41BCAC801000000000000000 0100000005E11448497E6B447B1BA79191310D9BA ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Stewart B ryant (stbryant)":MAILTO:stbryant@cisco.com ORGANIZER;CN="mp-ams-c1-olk.svc":MAILTO:mp-ams-c1-olk.svc@cisco.com LOCATION: DTEND:20080610T170000Z DESCRIPTION:Stewart Bryant has invited you to a Cisco Unified MeetingPlace Conference\N\NDate/Time: June 10\, 2008 at 05:00PM Europe/Lo ndon\NLength: 60\NFrequency: once\NMeeting ID: 310271828\NMeeting Password: \N\NGlobal Access Num bers:\Nhttp://cisco.com/en/US/about/doing_business/conferencing/index.html \N\N San Jose\, CA: +408.525.6800 RTP: +919.392.3330 \N US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 \N India: +91.80.4103.3979 Germany: +49.619.6773.9002\N Japan: +81.3.5763.9394 China: +86.10.8515.5666\N\NT O ATTEND A WEB AND VOICE CONFERENCE:\N\NCISCO INTRANET ATTENDEES\NJoin the Web & Voice Conference*\N1. Go to http://meetingplaceinternal.cisco.com/j oin.asp?310271828\N2. Enter your CEC User ID & Password then click OK\N- A ccept any security warnings you receive and wait for the Meeting Room to i nitialize**\N3. Click on CONNECT from the Meeting Room to join the Voice C onference portion of the meeting\N\NEXTERNAL ATTENDEES - Outside the Cisco Intranet\NJoin the Web & Voice Conference*\N1. Go to http://meetingplace. cisco.com/join.asp?310271828\N2. Fill in the My Name is field then click A ttend Meeting\N- If you have a CEC User ID\, click on the Cisco icon\N- Ac cept any security warnings you receive and wait for the Meeting Room to in itialize**\N3. Click on CONNECT from the Meeting Room to join the Voice Co nference portion of the meeting\N- Note: Guest users will see a link to th e Global Access Numbers.\N\N*If this is your first time attending a Web Co nference\, disable any pop-up blockers and visit http://meetingplace.cisco .com/mpweb/scripts/browsertestupper.asp to test your web browser for compa tibility with the Web Conference.\N**The meeting will not start until the Host of the meeting arrives - if you'd like to start the meeting with your Profile\, please review the steps below to attend a Voice Only Conference as a Guest then follow the system prompts.\N\NTO ATTEND A RESERVATIONLESS VOICE ONLY CONFERENCE\N\NAS THE HOST\N1. Dial into Cisco Unified MeetingP lace (view the Access Numbers and link above)\N2. Press 1 to attend the me eting\N3. Enter the Meeting ID 310271828 followed by # key\N4. Follow the prompts to record your name and enter the waiting room\N5. Press 2 then en ter your Profile Password to initiate your meeting\N\NAS A GUEST\N1. Follo w steps 1-4 above to access the meeting\N2. You will be placed in a waitin g room until the Host initiates the meeting\N\NSUPPORT\NInformation about this Conference: Contact Stewart Bryant\, 442088248828\NCisco IT Support C enter: Attend the Voice Conference and then press #0 on your phone keypad\ N\N SEQUENCE:0 PRIORITY:5 CLASS: CREATED:20080609T103002Z LAST-MODIFIED:20080609T103002Z STATUS:CONFIRMED TRANSP:OPAQUE X-MICROSOFT-CDO-BUSYSTATUS:BUSY X-MICROSOFT-CDO-INSTTYPE:0 X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY X-MICROSOFT-CDO-ALLDAYEVENT:FALSE X-MICROSOFT-CDO-IMPORTANCE:1 X-MICROSOFT-CDO-OWNERAPPTID:-1 X-MICROSOFT-CDO-ATTENDEE-CRITICAL-CHANGE:20080609T103002Z X-MICROSOFT-CDO-OWNER-CRITICAL-CHANGE:20080609T103002Z BEGIN:VALARM ACTION:DISPLAY DESCRIPTION:REMINDER TRIGGER;RELATED=START:-PT00H15M00S END:VALARM END:VEVENT END:VCALENDAR ------_=_NextPart_001_01C8CA1B.C695E2B9-- --------------010701060901050309090907 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop --------------010701060901050309090907-- From mpls-interop-bounces@ietf.org Mon Jun 9 22:20:20 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F2853A67A2; Mon, 9 Jun 2008 22:20:19 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 965573A6940 for ; Mon, 9 Jun 2008 22:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FpIDagBNB8w9 for ; Mon, 9 Jun 2008 22:20:14 -0700 (PDT) Received: from fw.testbed.se (smtp.testbed.se [80.86.78.228]) by core3.amsl.com (Postfix) with ESMTP id 776983A67A2 for ; Mon, 9 Jun 2008 22:20:10 -0700 (PDT) Received: from MailerDaemon by fw.testbed.se with local-bsmtp (Exim 4.63) (envelope-from ) id 1K5wHS-0002uH-5Z for mpls-interop@ietf.org; Tue, 10 Jun 2008 07:20:26 +0200 Received: from h133n2fls33o883.telia.com ([217.208.62.133]:62279 helo=[192.168.0.100]) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1K5wHP-0002u6-GK for mpls-interop@ietf.org; Tue, 10 Jun 2008 07:20:23 +0200 Message-ID: <484E0EED.1080309@pi.nu> Date: Tue, 10 Jun 2008 07:19:41 +0200 From: Loa Andersson User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: mpls-interop@ietf.org Subject: [Mpls-interop] merging MEAD team and MPLS TP editors X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org All, sorry for this late mail mail, I'd an extended week-end that became a bit more extended than planned ;). Blame on delayed flights! I've done some re-org to the MEAD team. Since very much of the work the coming period will be on the MPLS TP drafts I've merged the document editors into the MEAD team. The result is a rather large team, but I hope that will result in less admin overhead and quicker turn around. You should all received an invitation for a MEAD team am meeting today from Stewart Bryant. Plan for that meeting is to go through all the proposed drafts. And talk a bit about the +plans for Dublin, I'd like to see at least one draft that is possible to poll for wg status coming out of Dublin. Some info on the team: Team name: MEAD team Team Mailing list: mpls-interop@ietf.org Charter: http://www.tla-group.com/~loa/mead-team-charter.pdf /Loa -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.nu _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop From mpls-interop-bounces@ietf.org Tue Jun 10 05:49:53 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B4053A6918; Tue, 10 Jun 2008 05:49:53 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E0223A6AC0 for ; Tue, 10 Jun 2008 05:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANMHi9NfYGKR for ; Tue, 10 Jun 2008 05:49:51 -0700 (PDT) Received: from fw.testbed.se (smtp.testbed.se [80.86.78.228]) by core3.amsl.com (Postfix) with ESMTP id 6C9CF3A68BD for ; Tue, 10 Jun 2008 05:49:50 -0700 (PDT) Received: from MailerDaemon by fw.testbed.se with local-bsmtp (Exim 4.63) (envelope-from ) id 1K63Ig-0005Nt-L0 for mpls-interop@ietf.org; Tue, 10 Jun 2008 14:50:10 +0200 Received: from h133n2fls33o883.telia.com ([217.208.62.133]:62413 helo=[192.168.0.100]) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1K63Ie-0005Nn-L3 for mpls-interop@ietf.org; Tue, 10 Jun 2008 14:50:08 +0200 Message-ID: <484E7873.6070701@pi.nu> Date: Tue, 10 Jun 2008 14:49:55 +0200 From: Loa Andersson User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: mpls-interop@ietf.org Content-Type: multipart/mixed; boundary="------------050009050803010407010205" Subject: [Mpls-interop] [Fwd: [Fwd: Meeting: Bryant {Meeting ID: 310271828}]] X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org This is a multi-part message in MIME format. --------------050009050803010407010205 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit All, since this seems to have been sent just slightly before the new memebers were subscribed to the MEAD team list, I sending it again. Sorry for the confusion. /Loa -------- Original Message -------- Subject: [Mpls-interop] [Fwd: Meeting: Bryant {Meeting ID: 310271828}] Date: Mon, 09 Jun 2008 11:51:01 +0100 From: Stewart Bryant Reply-To: stbryant@cisco.com To: mpls-interop@ietf.org Loa asked me to schedule a MEAD conf call for tomorrow. It is the usual time 5pm UK, 6pm Sweden, 12noon East Coast and 9am California. Usual dialin - see attached Stewart -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.nu --------------050009050803010407010205 Content-Type: message/rfc822; name="Meeting: Bryant {Meeting ID: 310271828}.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Meeting: Bryant {Meeting ID: 310271828}.eml" X-Account-Key: account3 X-Mozilla-Keys: Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m59AU3Z10147 for ; Mon, 9 Jun 2008 11:30:04 +0100 (BST) X-IronPort-AV: E=Sophos;i="4.27,611,1204498800"; d="ics'?scan'208,217";a="11123984" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 09 Jun 2008 12:30:02 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m59AU2Ka022837 for ; Mon, 9 Jun 2008 12:30:02 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m59AU2Tr019954 for ; Mon, 9 Jun 2008 10:30:02 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jun 2008 12:30:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:calendarmessage MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8CA1B.C695E2B9" Subject: Meeting: Bryant {Meeting ID: 310271828} Date: Mon, 9 Jun 2008 12:30:02 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Index: AcjKG8aVNX2gBonxSlKNa6jubGkxVw== From: "mp-ams-c1-olk.svc" To: "Stewart Bryant (stbryant)" X-OriginalArrivalTime: 09 Jun 2008 10:30:02.0676 (UTC) FILETIME=[C6B55740:01C8CA1B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=16641; t=1213007402; x=1213871402; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mp-ams-c1-olk.svc@cisco.com; z=From:=20=22mp-ams-c1-olk.svc=22=20 |Subject:=20Meeting=3A=20Bryant=20{Meeting=20ID=3A=20310271 828} |Sender:=20; bh=XlQwsBZD+AzsRKqTKCyRV573FYJ6OuqWiq45jlG31cs=; b=MducBxeb6Zw9d3Aym6/FmCI0qGAPmh3zQyFZDUxO1mXA6kqYfXiHPtEsqj lOAWZtJMfKJ+Z9i4CuuytaqiFvBJyOExA1sUZPW/HYJfXCBIIAEkz/s2GxGh ERH7Uq5zrf; Authentication-Results: ams-dkim-1; header.From=mp-ams-c1-olk.svc@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); This is a multi-part message in MIME format. ------_=_NextPart_001_01C8CA1B.C695E2B9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stewart Bryant has invited you to a Cisco Unified MeetingPlace = Conference Date/Time: June 10, 2008 at 05:00PM Europe/London Length: 60 Frequency: once Meeting ID: 310271828 Meeting Password: =20 Global Access Numbers: http://cisco.com/en/US/about/doing_business/conferencing/index.html San Jose, CA: +408.525.6800 RTP: +919.392.3330 =20 US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 India: +91.80.4103.3979 Germany: +49.619.6773.9002 Japan: +81.3.5763.9394 China: +86.10.8515.5666 TO ATTEND A WEB AND VOICE CONFERENCE: CISCO INTRANET ATTENDEES Join the Web & Voice Conference* 1. Go to http://meetingplaceinternal.cisco.com/join.asp?310271828 2. Enter your CEC User ID & Password then click OK - Accept any security warnings you receive and wait for the Meeting Room = to initialize** 3. Click on CONNECT from the Meeting Room to join the Voice Conference = portion of the meeting EXTERNAL ATTENDEES - Outside the Cisco Intranet Join the Web & Voice Conference* 1. Go to http://meetingplace.cisco.com/join.asp?310271828 2. Fill in the My Name is field then click Attend Meeting - If you have a CEC User ID, click on the Cisco icon - Accept any security warnings you receive and wait for the Meeting Room = to initialize** 3. Click on CONNECT from the Meeting Room to join the Voice Conference = portion of the meeting - Note: Guest users will see a link to the Global Access Numbers. *If this is your first time attending a Web Conference, disable any = pop-up blockers and visit = http://meetingplace.cisco.com/mpweb/scripts/browsertestupper.asp to test = your web browser for compatibility with the Web Conference. **The meeting will not start until the Host of the meeting arrives - if = you'd like to start the meeting with your Profile, please review the = steps below to attend a Voice Only Conference as a Guest then follow the = system prompts. TO ATTEND A RESERVATIONLESS VOICE ONLY CONFERENCE AS THE HOST 1. Dial into Cisco Unified MeetingPlace (view the Access Numbers and = link above) 2. Press 1 to attend the meeting 3. Enter the Meeting ID 310271828 followed by # key 4. Follow the prompts to record your name and enter the waiting room 5. Press 2 then enter your Profile Password to initiate your meeting AS A GUEST 1. Follow steps 1-4 above to access the meeting 2. You will be placed in a waiting room until the Host initiates the = meeting SUPPORT Information about this Conference: Contact Stewart Bryant, 442088248828 Cisco IT Support Center: Attend the Voice Conference and then press #0 = on your phone keypad ------_=_NextPart_001_01C8CA1B.C695E2B9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Meeting: Bryant {Meeting ID: 310271828}

Stewart Bryant has invited you = to a Cisco Unified MeetingPlace Conference

Date/Time:           &n= bsp;   June 10, 2008 at 05:00PM Europe/London
Length:           &n= bsp;      60
Frequency:           &n= bsp;   once
Meeting ID:           &n= bsp;  310271828
Meeting = Password:       

Global Access = Numbers:
http://cisco.com/en/US/about/doing_business/conferencing/index.html

    San Jose, CA: +408.525.6800    = RTP:           &n= bsp;  +919.392.3330     =20
    = US/Canada:  = +1.866.432.9903    United Kingdom:   +44.20.8824.0117
    = India:      = +91.80.4103.3979   Germany:          = +49.619.6773.9002
    = Japan:      = +81.3.5763.9394    China:            = +86.10.8515.5666

TO ATTEND A WEB AND VOICE = CONFERENCE:

CISCO = INTRANET ATTENDEES
Join the Web & Voice = Conference*
1. Go to http://= meetingplaceinternal.cisco.com/join.asp?310271828
2. Enter your CEC User ID & Password then click OK
- Accept any security warnings = you receive and wait for the Meeting Room to initialize**
3. Click on CONNECT from the Meeting Room to join the Voice Conference = portion of the meeting

EXTERNAL = ATTENDEES - Outside the Cisco Intranet
Join the Web & Voice = Conference*
1. Go to http://meetingp= lace.cisco.com/join.asp?310271828
2. Fill in the My Name is field then click Attend Meeting
- If you have a CEC User ID, = click on the Cisco icon
- Accept any security warnings = you receive and wait for the Meeting Room to initialize**
3. Click on CONNECT from the Meeting Room to join the Voice Conference = portion of the meeting
- Note: Guest users will see a link to the Global Access Numbers.

*If this is your = first time attending a Web Conference, disable any pop-up blockers and = visit http://meetingplace.cisco.com/mpweb/scripts/browsertestupper.asp to test your web browser for = compatibility with the Web Conference.

**The meeting will = not start until the Host of the meeting arrives - if you'd like to start = the meeting with your Profile, please review the steps below to attend a = Voice Only Conference as a Guest then follow the system = prompts.

TO ATTEND A RESERVATIONLESS VOICE = ONLY CONFERENCE

AS THE = HOST
1. Dial into Cisco Unified = MeetingPlace (view the Access Numbers and link above)
2. Press 1 to attend the meeting
3. Enter the Meeting = ID 310271828 followed = by # key
4. Follow the prompts to record = your name and enter the waiting room
5. Press 2 then enter your Profile Password to = initiate your meeting

AS A = GUEST
1. Follow steps 1-4 above to = access the meeting
2. You will be placed in a = waiting room until the Host initiates the meeting

SUPPORT
Information about this = Conference: Contact = Stewart Bryant, 442088248828
Cisco IT Support = Center: Attend the Voice = Conference and then press #0 on your phone keypad

------_=_NextPart_001_01C8CA1B.C695E2B9 Content-class: urn:content-classes:calendarmessage Content-Type: text/calendar; method=REQUEST; name="meeting.ics" Content-Transfer-Encoding: 8bit BEGIN:VCALENDAR METHOD:REQUEST PRODID:Microsoft CDO for Microsoft Exchange VERSION:2.0 BEGIN:VEVENT DTSTAMP:20080609T103002Z DTSTART:20080610T160000Z SUMMARY:Meeting: Bryant {Meeting ID: 310271828} UID:040000008200E00074C5B7101A82E00800000000C0C451C41BCAC801000000000000000 0100000005E11448497E6B447B1BA79191310D9BA ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Stewart B ryant (stbryant)":MAILTO:stbryant@cisco.com ORGANIZER;CN="mp-ams-c1-olk.svc":MAILTO:mp-ams-c1-olk.svc@cisco.com LOCATION: DTEND:20080610T170000Z DESCRIPTION:Stewart Bryant has invited you to a Cisco Unified MeetingPlace Conference\N\NDate/Time: June 10\, 2008 at 05:00PM Europe/Lo ndon\NLength: 60\NFrequency: once\NMeeting ID: 310271828\NMeeting Password: \N\NGlobal Access Num bers:\Nhttp://cisco.com/en/US/about/doing_business/conferencing/index.html \N\N San Jose\, CA: +408.525.6800 RTP: +919.392.3330 \N US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 \N India: +91.80.4103.3979 Germany: +49.619.6773.9002\N Japan: +81.3.5763.9394 China: +86.10.8515.5666\N\NT O ATTEND A WEB AND VOICE CONFERENCE:\N\NCISCO INTRANET ATTENDEES\NJoin the Web & Voice Conference*\N1. Go to http://meetingplaceinternal.cisco.com/j oin.asp?310271828\N2. Enter your CEC User ID & Password then click OK\N- A ccept any security warnings you receive and wait for the Meeting Room to i nitialize**\N3. Click on CONNECT from the Meeting Room to join the Voice C onference portion of the meeting\N\NEXTERNAL ATTENDEES - Outside the Cisco Intranet\NJoin the Web & Voice Conference*\N1. Go to http://meetingplace. cisco.com/join.asp?310271828\N2. Fill in the My Name is field then click A ttend Meeting\N- If you have a CEC User ID\, click on the Cisco icon\N- Ac cept any security warnings you receive and wait for the Meeting Room to in itialize**\N3. Click on CONNECT from the Meeting Room to join the Voice Co nference portion of the meeting\N- Note: Guest users will see a link to th e Global Access Numbers.\N\N*If this is your first time attending a Web Co nference\, disable any pop-up blockers and visit http://meetingplace.cisco .com/mpweb/scripts/browsertestupper.asp to test your web browser for compa tibility with the Web Conference.\N**The meeting will not start until the Host of the meeting arrives - if you'd like to start the meeting with your Profile\, please review the steps below to attend a Voice Only Conference as a Guest then follow the system prompts.\N\NTO ATTEND A RESERVATIONLESS VOICE ONLY CONFERENCE\N\NAS THE HOST\N1. Dial into Cisco Unified MeetingP lace (view the Access Numbers and link above)\N2. Press 1 to attend the me eting\N3. Enter the Meeting ID 310271828 followed by # key\N4. Follow the prompts to record your name and enter the waiting room\N5. Press 2 then en ter your Profile Password to initiate your meeting\N\NAS A GUEST\N1. Follo w steps 1-4 above to access the meeting\N2. You will be placed in a waitin g room until the Host initiates the meeting\N\NSUPPORT\NInformation about this Conference: Contact Stewart Bryant\, 442088248828\NCisco IT Support C enter: Attend the Voice Conference and then press #0 on your phone keypad\ N\N SEQUENCE:0 PRIORITY:5 CLASS: CREATED:20080609T103002Z LAST-MODIFIED:20080609T103002Z STATUS:CONFIRMED TRANSP:OPAQUE X-MICROSOFT-CDO-BUSYSTATUS:BUSY X-MICROSOFT-CDO-INSTTYPE:0 X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY X-MICROSOFT-CDO-ALLDAYEVENT:FALSE X-MICROSOFT-CDO-IMPORTANCE:1 X-MICROSOFT-CDO-OWNERAPPTID:-1 X-MICROSOFT-CDO-ATTENDEE-CRITICAL-CHANGE:20080609T103002Z X-MICROSOFT-CDO-OWNER-CRITICAL-CHANGE:20080609T103002Z BEGIN:VALARM ACTION:DISPLAY DESCRIPTION:REMINDER TRIGGER;RELATED=START:-PT00H15M00S END:VALARM END:VEVENT END:VCALENDAR ------_=_NextPart_001_01C8CA1B.C695E2B9-- --------------050009050803010407010205 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Attached Message Part" _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop --------------050009050803010407010205 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop --------------050009050803010407010205-- From mpls-interop-bounces@ietf.org Tue Jun 10 07:21:24 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FD423A6908; Tue, 10 Jun 2008 07:21:24 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A9303A6908 for ; Tue, 10 Jun 2008 07:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8VKXCRxYNO6 for ; Tue, 10 Jun 2008 07:21:19 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 39D353A6873 for ; Tue, 10 Jun 2008 07:21:19 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m5AELeSn006498 for ; Tue, 10 Jun 2008 09:21:41 -0500 Received: from eusrcmw720.eamcs.ericsson.se ([138.85.77.20]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jun 2008 09:21:44 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 10 Jun 2008 09:21:44 -0500 Message-ID: <8ECB099B6E0A044695BD93961F349882074251FB@eusrcmw720.eamcs.ericsson.se> In-Reply-To: <484E7873.6070701@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Wiki Thread-Index: AcjK+I4YOJOXj5GZQEWx99hNr+VYfAACu6Cg References: <484E7873.6070701@pi.nu> From: "David Sinicrope" To: X-OriginalArrivalTime: 10 Jun 2008 14:21:44.0618 (UTC) FILETIME=[4F5318A0:01C8CB05] Subject: [Mpls-interop] Wiki X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org Hi All, Just to remind folks that in addition to the email list we also have a wiki. http://www3.tools.ietf.org/misc/mpls-interop/ I usually post Stewarts call information to the wiki as well as the meeting dates, notes, and other information. Please let me know if you would like to see any other information posted or feel free to edit the pages on your own. Information for obtaining a password is below. Cheers, David Sinicrope To get a password to access the MEAD Team wiki (and other tools.ietf.org facilities): If you don't already have an ietf-tools password, go to ietf-tools http://tools.ietf.org/ find the "Get Passwd" link (upper left hand), click it and get a password Once the password is emailed to you, you should be able to use it to log into the wiki link above. _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop From mpls-interop-bounces@ietf.org Tue Jun 10 08:54:02 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 248C33A67E2; Tue, 10 Jun 2008 08:54:02 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 655173A6812 for ; Tue, 10 Jun 2008 08:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dul+S+hjdR1M for ; Tue, 10 Jun 2008 08:53:59 -0700 (PDT) Received: from fw.testbed.se (smtp.testbed.se [80.86.78.228]) by core3.amsl.com (Postfix) with ESMTP id 6A3E53A6801 for ; Tue, 10 Jun 2008 08:53:59 -0700 (PDT) Received: from MailerDaemon by fw.testbed.se with local-bsmtp (Exim 4.63) (envelope-from ) id 1K66Ar-000668-TG for mpls-interop@ietf.org; Tue, 10 Jun 2008 17:54:17 +0200 Received: from h133n2fls33o883.telia.com ([217.208.62.133]:63182 helo=[192.168.0.100]) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1K66Ap-000662-Uv for mpls-interop@ietf.org; Tue, 10 Jun 2008 17:54:16 +0200 Message-ID: <484EA399.80309@pi.nu> Date: Tue, 10 Jun 2008 17:54:01 +0200 From: Loa Andersson User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: mpls-interop@ietf.org Subject: [Mpls-interop] updated version of the editors and documents document X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org All, I've put an updated document at: http://www.tla-group.com/~loa/editor-doc-list.pdf I will use this for todays meeting. /Loa -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.nu _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop From mpls-interop-bounces@ietf.org Thu Jun 19 07:59:54 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D13A53A6A4B; Thu, 19 Jun 2008 07:59:54 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6419D3A6A4B for ; Thu, 19 Jun 2008 07:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GyZjgRo3Jcmx for ; Thu, 19 Jun 2008 07:59:48 -0700 (PDT) Received: from fw.testbed.se (smtp.testbed.se [80.86.78.228]) by core3.amsl.com (Postfix) with ESMTP id EC2933A68DE for ; Thu, 19 Jun 2008 07:59:44 -0700 (PDT) Received: from MailerDaemon by fw.testbed.se with local-bsmtp (Exim 4.63) (envelope-from ) id 1K9Lck-00087O-U3 for mpls-interop@ietf.org; Thu, 19 Jun 2008 17:00:30 +0200 Received: from h133n2fls33o883.telia.com ([217.208.62.133]:61710 helo=[192.168.0.100]) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1K9Lci-00087I-Qr for mpls-interop@ietf.org; Thu, 19 Jun 2008 17:00:28 +0200 Message-ID: <485A7485.9090205@pi.nu> Date: Thu, 19 Jun 2008 17:00:21 +0200 From: Loa Andersson User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: MEAD team Subject: [Mpls-interop] next MEAD team meeting X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org All, the MEAD team will have the next meeting on Tuesday 24, at 6pm i.e. 12am east coast and 9am California. Again I plan the meeting to last an hour, and focus will be on the document status. Stewart will send out dial in details as usual. /Loa -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.nu _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop From mpls-interop-bounces@ietf.org Thu Jun 19 10:20:20 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 405843A6829; Thu, 19 Jun 2008 10:20:20 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A95F3A6829 for ; Thu, 19 Jun 2008 10:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.482 X-Spam-Level: * X-Spam-Status: No, score=1.482 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gt8Su8xkdwJk for ; Thu, 19 Jun 2008 10:20:10 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 25E243A6919 for ; Thu, 19 Jun 2008 10:20:08 -0700 (PDT) Received: from E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jun 2008 18:20:58 +0100 Received: from 217.32.164.184 ([217.32.164.184]) by E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.60]) via Exchange Front-End Server mail.bt.com ([193.113.197.28]) with Microsoft Exchange Server HTTP-DAV ; Thu, 19 Jun 2008 17:20:57 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Thu, 19 Jun 2008 18:20:54 +0100 From: Ben Niven-Jenkins To: Loa Andersson , MEAD team Message-ID: Thread-Topic: [Mpls-interop] next MEAD team meeting Thread-Index: AcjSMNQsx4BuurjX8EeQxIcfmO8exA== In-Reply-To: <485A7485.9090205@pi.nu> Mime-version: 1.0 Content-type: multipart/mixed; boundary="B_3296744455_4187096" X-OriginalArrivalTime: 19 Jun 2008 17:20:58.0062 (UTC) FILETIME=[D6982EE0:01C8D230] Subject: Re: [Mpls-interop] next MEAD team meeting X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3296744455_4187096 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Colleagues, FYI see attached for the latest draft of the MPLS-TP requirements draft. Ben On 19/06/2008 16:00, "Loa Andersson" wrote: > All, > > the MEAD team will have the next meeting on Tuesday 24, at 6pm > i.e. 12am east coast and 9am California. > > Again I plan the meeting to last an hour, and focus will be on the > document status. > > Stewart will send out dial in details as usual. > > /Loa --B_3296744455_4187096 Content-type: text/plain; name="draft-jenkins-mpls-mpls-tp-requirements-00pre5.txt"; x-mac-creator="74657874"; x-mac-type="54455854" Content-disposition: attachment; filename="draft-jenkins-mpls-mpls-tp-requirements-00pre5.txt" Content-transfer-encoding: base64 CgoKTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Qi4gTml2ZW4tSmVua2lucywgRWQuCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBCVApJbnRlbmRlZCBzdGF0 dXM6IEluZm9ybWF0aW9uYWwgICAgICAgICAgICAgICAgICAgICAgICAgIEQuIEJydW5nYXJk LCBFZC4KRXhwaXJlczogSmFudWFyeSAyLCAyMDA5ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBBVCZUCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTS4gQmV0dHMsIEVkLgogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBOb3J0ZWwg TmV0d29ya3MKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIE4uIFNwcmVjaGVyCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgTm9raWEgU2llbWVucyBOZXR3b3JrcwogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEp1 bHkgMDEsIDIwMDgKCgogICAgICAgICAgICAgICAgICAgICAgICAgIE1QTFMtVFAgUmVxdWly ZW1lbnRzCiAgICAgICAgICAgICAgIGRyYWZ0LWplbmtpbnMtbXBscy1tcGxzdHAtcmVxdWly ZW1lbnRzLTAwCgpTdGF0dXMgb2YgdGhpcyBNZW1vCgogICBCeSBzdWJtaXR0aW5nIHRoaXMg SW50ZXJuZXQtRHJhZnQsIGVhY2ggYXV0aG9yIHJlcHJlc2VudHMgdGhhdCBhbnkKICAgYXBw bGljYWJsZSBwYXRlbnQgb3Igb3RoZXIgSVBSIGNsYWltcyBvZiB3aGljaCBoZSBvciBzaGUg aXMgYXdhcmUKICAgaGF2ZSBiZWVuIG9yIHdpbGwgYmUgZGlzY2xvc2VkLCBhbmQgYW55IG9m IHdoaWNoIGhlIG9yIHNoZSBiZWNvbWVzCiAgIGF3YXJlIHdpbGwgYmUgZGlzY2xvc2VkLCBp biBhY2NvcmRhbmNlIHdpdGggU2VjdGlvbiA2IG9mIEJDUCA3OS4KCiAgIEludGVybmV0LURy YWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5n CiAgIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91 cHMuICBOb3RlIHRoYXQKICAgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29y a2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtCiAgIERyYWZ0cy4KCiAgIEludGVybmV0LURy YWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1v bnRocwogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkg b3RoZXIgZG9jdW1lbnRzIGF0IGFueQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0 byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQogICBtYXRlcmlhbCBvciB0byBj aXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iCgogICBUaGUgbGlz dCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQKICAgaHR0 cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0LgoKICAgVGhlIGxpc3Qg b2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBh dAogICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sLgoKICAgVGhpcyBJbnRlcm5l dC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBKYW51YXJ5IDIsIDIwMDkuCgpBYnN0cmFjdAoKICAg VGhpcyBkb2N1bWVudCB3aWxsIG91dGxpbmUgdGhlIHJlcXVpcmVtZW50cyBmb3IgTVBMUy1U UC4KClJlcXVpcmVtZW50cyBMYW5ndWFnZQoKICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJN VVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLAogICAiU0hPVUxE IiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIg aW4gdGhpcwogICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVk IGluIFtSRkMyMTE5XS4KCgoKTml2ZW4tSmVua2lucywgZXQgYWwuICAgIEV4cGlyZXMgSmFu dWFyeSAyLCAyMDA5ICAgICAgICAgICAgICAgIFtQYWdlIDFdCgwKSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgICBNUExTLVRQIFJlcXVpcmVtZW50cyAgICAgICAgICAgICAgICAgSnVseSAy MDA4CgoKVGFibGUgb2YgQ29udGVudHMKCiAgIDEuICBJbnRyb2R1Y3Rpb24gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMwogICAyLiAgTVBM Uy1UUCBSZXF1aXJlbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gIDUKICAgICAyLjEuICBHZW5lcmFsIHJlcXVpcmVtZW50cyAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA1CiAgICAgMi4yLiAgTGF5ZXJpbmcgcmVxdWly ZW1lbnRzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNgogICAgIDIu My4gIERhdGEgcGxhbmUgcmVxdWlyZW1lbnRzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gIDcKICAgICAyLjQuICBDb250cm9sIHBsYW5lIHJlcXVpcmVtZW50cyAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA4CiAgICAgMi41LiAgTmV0d29yayBNYW5h Z2VtZW50IChOTSkgcmVxdWlyZW1lbnRzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMQogICAg IDIuNi4gIE9BTSByZXF1aXJlbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gMTEKICAgICAyLjcuICBOZXR3b3JrIHBlcmZvcm1hbmNlIG1hbmFnZW1l bnQgKFBNKSByZXF1aXJlbWVudHMgLiAuIC4gLiAuIDExCiAgICAgMi44LiAgUHJvdGVjdGlv biAmIFN1cnZpdmFiaWxpdHkgcmVxdWlyZW1lbnRzICAuIC4gLiAuIC4gLiAuIC4gLiAxMgog ICAgIDIuOS4gIFFvUyByZXF1aXJlbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gMTQKICAgICAyLjEwLiBTZWN1cml0eSByZXF1aXJlbWVudHMgIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE1CiAgIDMuICBJQU5BIENvbnNp ZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAx NQogICA0LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gMTYKICAgNS4gIEFja25vd2xlZGdlbWVudHMgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE2CiAgIDYuICBJbmZvcm1h dGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAxNgogICBBdXRob3JzJyBBZGRyZXNzZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gMTYKICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5IGFuZCBD b3B5cmlnaHQgU3RhdGVtZW50cyAuIC4gLiAuIC4gLiAuIC4gLiAuIDE4CgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgpOaXZlbi1KZW5raW5zLCBldCBhbC4gICAgRXhwaXJlcyBK YW51YXJ5IDIsIDIwMDkgICAgICAgICAgICAgICAgW1BhZ2UgMl0KDApJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgIE1QTFMtVFAgUmVxdWlyZW1lbnRzICAgICAgICAgICAgICAgICBKdWx5 IDIwMDgKCgoxLiAgSW50cm9kdWN0aW9uCgogICBGb3IgbWFueSB5ZWFycywgU09ORVQvU0RI IGhhcyBwcm92aWRlZCBzZXJ2aWNlIHByb3ZpZGVycyB3aXRoIGEgaGlnaAogICBiZW5jaG1h cmsgZm9yIHJlbGlhYmlsaXR5IGFuZCBvcGVyYXRpb25hbCBzaW1wbGljaXR5LiAgV2l0aCB0 aGUKICAgYWNjZWxlcmF0aW5nIGdyb3d0aCBvZiBwYWNrZXQtYmFzZWQgc2VydmljZXMgKHN1 Y2ggYXMgRXRoZXJuZXQsIFZvSVAsCiAgIEwyL0wzIFZQTiwgSVBUViwgUkFOIGJhY2toYXVs aW5nLCBldGMuKSwgc2VydmljZSBwcm92aWRlcnMgYXJlIGluCiAgIG5lZWQgb2YgY2FwYWJp bGl0aWVzIHRvIGVmZmljaWVudGx5IHN1cHBvcnQgcGFja2V0LWJhc2VkIHNlcnZpY2VzIG9u CiAgIHRoZWlyIHRyYW5zcG9ydCBuZXR3b3Jrcy4gIFRoZSBuZWVkIHRvIGluY3JlYXNlIHRo ZWlyIHJldmVudWUgd2hpbGUKICAgcmVtYWluaW5nIGNvbXBldGl0aXZlIGZvcmNlcyBvcGVy YXRvcnMgdG8gbG9vayBmb3IgdGhlIGxvd2VzdCBuZXR3b3JrCiAgIFRvdGFsIENvc3Qgb2Yg T3duZXJzaGlwIChUQ08pLiAgSW52ZXN0bWVudCBpbiBib3RoIENhcGl0YWwKICAgRXhwZW5k aXR1cmUgKENBUEVYKSBhbmQgT3BlcmF0aW9uYWwgRXhwZW5zZSAoT1BFWCkgc2hvdWxkIGJl IG1pbmltYWwuCgogICBDYXJyaWVycyBhcmUgY29uc2lkZXJpbmcgbWlncmF0aW5nIHRvIHBh Y2tldCB0cmFuc3BvcnQgbmV0d29ya3MgaW4KICAgb3JkZXIgdG8gcmVkdWNlIHRoZWlyIGNv c3RzIGFuZCB0byBpbXByb3ZlIHRoZWlyIGFiaWxpdHkgdG8gc3VwcG9ydAogICBzZXJ2aWNl cyB3aXRoIGd1YXJhbnRlZWQgU0xBcy4gIE1pZ3JhdGluZyBmcm9tIFNPTkVUL1NESCB0byBw YWNrZXQKICAgdHJhbnNwb3J0IG5ldHdvcmtzIHNob3VsZCBub3QgaW52b2x2ZSBkcmFtYXRp YyBjaGFuZ2VzIGluIG5ldHdvcmsKICAgb3BlcmF0aW9uLCBzaG91bGQgbm90IG5lY2Vzc2l0 YXRlIGV4dGVuc2l2ZSByZXRyYWluaW5nLCBhbmQgc2hvdWxkCiAgIG5vdCByZXF1aXJlIG1h am9yIGNoYW5nZXMgdG8gZXhpc3Rpbmcgd29yayBwcmFjdGljZXMuICBUaGUgYWltIGlzIHRv CiAgIHByZXNlcnZlIHRoZSBsb29rLWFuZC1mZWVsIHRvIHdoaWNoIGNhcnJpZXJzIGhhdmUg YmVjb21lIGFjY3VzdG9tZWQKICAgaW4gZGVwbG95aW5nIHRoZWlyIFNPTkVUL1NESCBuZXR3 b3Jrcywgd2hpbGUgcHJvdmlkaW5nIGNvbW1vbiwgbXVsdGktCiAgIGxheWVyIG9wZXJhdGlv bnMsIHJlc2lsaWVuY3ksIGNvbnRyb2wgYW5kIG1hbmFnZW1lbnQgZm9yIHBhY2tldCwKICAg Y2lyY3VpdCBhbmQgbGFtYmRhIHRyYW5zcG9ydCBuZXR3b3Jrcy4KCiAgIEFuIGltcG9ydGFu dCBhdHRyaWJ1dGUgb2YgYSB0cmFuc3BvcnQgbmV0d29yayBpcyBpdHMgYWJpbGl0eSB0bwog ICBmdW5jdGlvbiBpbmRlcGVuZGVudGx5IGZyb20gYm90aCBpdHMgY2xpZW50IGFuZCBzZXJ2 ZXIgKHRyYW5zbWlzc2lvbgogICBtZWRpYSkgbGF5ZXIgbmV0d29ya3MuICBJdCBzaG91bGQg YmUgY2FwYWJsZSBvZiB0cmFuc21pdHRpbmcgb3ZlciBhbnkKICAgbWVkaWEuICBBbm90aGVy IGtleSBjaGFyYWN0ZXJpc3RpYyBvZiB0cmFuc3BvcnQgbmV0d29ya3MgaXMgdGhlCiAgIGNh cGFiaWxpdHkgdG8gbWFpbnRhaW4gdGhlIGludGVncml0eSBvZiB0aGUgY2xpZW50IHNpZ25h bCBiZXR3ZWVuIGl0cwogICBpbmdyZXNzIGFuZCBlZ3Jlc3MgcG9ydHMuICBBIHRyYW5zcG9y dCBuZXR3b3JrIG11c3QgcHJvdmlkZSB0aGUgbWVhbnMKICAgdG8gY29tbWl0IHF1YWxpdHkg b2Ygc2VydmljZSBvYmplY3RpdmVzIHRvIGNsaWVudHMuICBUaGlzIGlzIGFjaGlldmVkCiAg IGJ5IHByb3ZpZGluZyBhIG1lY2hhbmlzbSBmb3IgY2xpZW50IG5ldHdvcmsgc2VydmljZSBk ZW1hcmNhdGlvbiBmb3IKICAgdGhlIG5ldHdvcmsgcGF0aCB0b2dldGhlciB3aXRoIGFuIGFz c29jaWF0ZWQgbmV0d29yayByZXNpbGllbmN5CiAgIG1lY2hhbmlzbS4gIEEgdHJhbnNwb3J0 IG5ldHdvcmsgbXVzdCBhbHNvIHByb3ZpZGUgYSBtZXRob2Qgb2Ygc2VydmljZQogICBtb25p dG9yaW5nIGluIG9yZGVyIHRvIHZlcmlmeSB0aGUgZGVsaXZlcnkgb2YgYW4gYWdyZWVkIHF1 YWxpdHkgb2YKICAgc2VydmljZS4gIFRoaXMgaXMgZW5hYmxlZCBieSBtZWFucyBvZiBjYXJy aWVyLWdyYWRlIE9BTSB0b29scy4KCiAgIFRoZSBjb25uZWN0aXZpdHkgc2VydmljZSBpcyB0 aGUgYmFzaWMgc2VydmljZSBwcm92aWRlZCBieSBhIHRyYW5zcG9ydAogICBuZXR3b3JrLiAg VGhlIHB1cnBvc2Ugb2YgYSB0cmFuc3BvcnQgbmV0d29yayBpcyB0byB0cmFuc3BhcmVudGx5 CiAgIGNhcnJ5IGNsaWVudCBzaWduYWxzIChpLmUuIHRoZSBzdHJlYW0gb2YgY2xpZW50IFBE VXMgb3IgY2xpZW50IGJpdHMpCiAgIGJldHdlZW4gZW5kcG9pbnRzIGluIHRoZSBuZXR3b3Jr ICh0eXBpY2FsbHkgb3ZlciBzZXZlcmFsIGludGVybWVkaWF0ZQogICBub2RlcykuICBUaGVz ZSBlbmRwb2ludHMgbWF5IGJlIHNlcnZpY2Ugc3dpdGNoaW5nIHBvaW50cyBvciBzZXJ2aWNl CiAgIHRlcm1pbmF0aW5nIHBvaW50cy4gIFRoZSBjb25uZWN0aXZpdHkgc2VydmljZXMgb2Zm ZXJlZCB0byBjdXN0b21lcnMKICAgYXJlIGFnZ3JlZ2F0ZWQgaW50byBsYXJnZSwgbG9uZy1o b2xkaW5nIHRpbWUgcGlwZXMvdHJ1bmtzIHdoaWNoCiAgIGVuYWJsZSB0aGUgZWZmaWNpZW50 IGFuZCByZWxpYWJsZSBvcGVyYXRpb24gb2YgdGhlIHRyYW5zcG9ydCBuZXR3b3JrLgogICBU aGVzZSB0cnVua3MgYXJlIG1vZGlmaWVkIGluZnJlcXVlbnRseS4KCiAgIEFnZ3JlZ2F0aW9u IGFuZCBoaWVyYXJjaHkgYXJlIGJlbmVmaWNpYWwgZm9yIGFjaGlldmluZyBzY2FsYWJpbGl0 eQogICBhbmQgc2VjdXJpdHkgc2luY2U6CgoKCk5pdmVuLUplbmtpbnMsIGV0IGFsLiAgICBF eHBpcmVzIEphbnVhcnkgMiwgMjAwOSAgICAgICAgICAgICAgICBbUGFnZSAzXQoMCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgTVBMUy1UUCBSZXF1aXJlbWVudHMgICAgICAgICAgICAg ICAgIEp1bHkgMjAwOAoKCiAgIDEuICBUaGV5IHJlZHVjZSB0aGUgbnVtYmVyIG9mIHByb3Zp c2lvbmluZyBhbmQgZm9yd2FyZGluZyBzdGF0ZXMgaW4KICAgICAgIHRoZSBuZXR3b3JrIGNv cmUuCgogICAyLiAgVGhleSByZWR1Y2UgbG9hZCBhbmQgdGhlIGNvc3Qgb2YgaW1wbGVtZW50 aW5nIHNlcnZpY2UgYXNzdXJhbmNlCiAgICAgICBhbmQgZmF1bHQgbWFuYWdlbWVudC4KCiAg IDMuICBDbGllbnQgc2lnbmFscyBhcmUgY29tcGxldGVseSBlbmNhcHN1bGF0ZWQgYW5kIGlz b2xhdGVkIGZyb20gZWFjaAogICAgICAgb3RoZXIuICBUaGlzIGFsc28gYWxsb3dzIGNvbXBs ZXRlIGlzb2xhdGlvbiBvZiBjdXN0b21lciB0cmFmZmljCiAgICAgICBmcm9tIGNhcnJpZXIg b3BlcmF0aW9ucy4KCiAgIENsaWVudCBzaWduYWxzIGFyZSBmaXJzdCB0cmFuc3BhcmVudGx5 IGVuY2Fwc3VsYXRlZC4gIFRoZXNlCiAgIGVuY2Fwc3VsYXRlZCBjbGllbnQgc2lnbmFscyBh cmUgdGhlbiBhZ2dyZWdhdGVkIGZvciB0cmFuc3BvcnQgdGhyb3VnaAogICB0aGUgbmV0d29y ayBpbiBvcmRlciB0byBvcHRpbWl6ZSBuZXR3b3JrIG1hbmFnZW1lbnQuICBTZXJ2ZXIgbGF5 ZXIKICAgT0FNIGlzIHVzZWQgdG8gbW9uaXRvciB0aGUgdHJhbnNwb3J0IGludGVncml0eSBv ZiB0aGUgY2xpZW50IGxheWVyCiAgIGFnZ3JlZ2F0ZS4gIEF0IGFueSBob3AsIHRoZSBhZ2dy ZWdhdGVkIHNpZ25hbHMgbWF5IGJlIGZ1cnRoZXIKICAgYWdncmVnYXRlZCBpbiBsb3dlciBs YXllciB0cmFuc3BvcnQgbmV0d29yayBwYXRocyBmb3IgdHJhbnNwb3J0CiAgIGFjcm9zcyBp bnRlcm1lZGlhdGUgc2hhcmVkIGxpbmtzLiAgVGhlIGVuY2Fwc3VsYXRlZCBjbGllbnQgc2ln bmFscwogICBhcmUgZXh0cmFjdGVkIGF0IHRoZSBlZGdlcyBvZiBhZ2dyZWdhdGlvbiBkb21h aW5zLCBhbmQgYXJlIGVpdGhlcgogICBkZWxpdmVyZWQgdG8gdGhlIGNsaWVudCBvciBmb3J3 YXJkZWQgdG8gYW5vdGhlciBkb21haW4uICBJbiB0aGUgY29yZQogICBvZiB0aGUgbmV0d29y aywgb25seSB0aGUgc2VydmVyIGxheWVyIGFnZ3JlZ2F0ZWQgc2lnbmFscyBhcmUKICAgbW9u aXRvcmVkOyBpbmRpdmlkdWFsIGNsaWVudCBzaWduYWxzIGFyZSBtb25pdG9yZWQgYXQgdGhl IG5ldHdvcmsKICAgYm91bmRhcnkgaW4gdGhlIGNsaWVudCBsYXllciBuZXR3b3JrLgoKICAg UXVhbGl0eS1vZi1zZXJ2aWNlIG1lY2hhbmlzbXMgYXJlIHJlcXVpcmVkIGluIHRoZSBwYWNr ZXQgdHJhbnNwb3J0CiAgIG5ldHdvcmsgdG8gZW5zdXJlIHRoZSBwcmlvcml0aXphdGlvbiBv ZiBjcml0aWNhbCBzZXJ2aWNlcywgdG8KICAgZ3VhcmFudGVlIEJXIGFuZCB0byBjb250cm9s IGppdHRlciBhbmQgZGVsYXkuCgogICBTZXJ2aWNlIHByb3ZpZGVycyByZXF1aXJlIGNvbnRy b2wgYW5kIGRldGVybWluaXN0aWMgdXNhZ2Ugb2YgbmV0d29yawogICByZXNvdXJjZXMuICBU aGV5IG5lZWQgZW5kLXRvLWVuZCBjb250cm9sIHRvIGVuZ2luZWVyIG5ldHdvcmsgcGF0aHMK ICAgYW5kIHRvIGVmZmljaWVudGx5IHV0aWxpemUgbmV0d29yayByZXNvdXJjZXMuICBUaGV5 IHJlcXVpcmUKICAgY2FwYWJpbGl0aWVzIHRvIHN0YXRpY2FsbHkgKE9TUyBiYXNlZCkgcHJv dmlzaW9uIGRldGVybWluaXN0aWMsCiAgIHByb3RlY3RlZCBhbmQgc2VjdXJlZCBzZXJ2aWNl cyBhbmQgdGhlaXIgYXNzb2NpYXRlZCByZXNvdXJjZXMgYXMgd2VsbAogICBhcyBhbHRlcm5h dGl2ZSBjb250cm9sLXBsYW5lIG9wdGlvbnMuCgogICBUaGUgdHJhbnNwb3J0IG5ldHdvcmsg bXVzdCBiZSBjYXBhYmxlIG9mIHRyYW5zcG9ydGluZyBtdWx0aXBsZQogICBzZXJ2aWNlcyBp biBhIHNjYWxhYmxlIG1hbm5lci4KCiAgIENhcnJpZXJzIHdpbGwgc3RpbGwgbmVlZCB0byBj b3BlIHdpdGggbGVnYWN5IG5ldHdvcmtzICh3aGljaCBhcmUKICAgY29tcG9zZWQgb2YgbWFu eSBsYXllcnMgYW5kIHRlY2hub2xvZ2llcyksIHRodXMgdGhlIHBhY2tldCB0cmFuc3BvcnQK ICAgbmV0d29yayBzaG91bGQgaW50ZXJ3b3JrIHdpdGggb3RoZXIgcGFja2V0IGFuZCB0cmFu c3BvcnQgbmV0d29ya3MKICAgKGJvdGggaG9yaXpvbnRhbGx5IGFuZCB2ZXJ0aWNhbGx5KS4g IFZlcnRpY2FsIGludGVyd29ya2luZyBpcyBhbHNvCiAgIGtub3duIGFzIGNsaWVudC9zZXJ2 ZXIgb3IgbmV0d29yayBpbnRlcndvcmtpbmcuICBIb3Jpem9udGFsCiAgIGludGVyd29ya2lu ZyBpcyBhbHNvIGtub3duIGFzIHBlZXItcGFydGl0aW9uIG9yIHNlcnZpY2UgaW50ZXJ3b3Jr aW5nLgogICBGb3IgbW9yZSBkZXRhaWxzIG9uIGVhY2ggdHlwZSBvZiBpbnRlcndvcmtpbmcg YW5kIHNvbWUgb2YgdGhlIGlzc3VlcwogICB0aGF0IG1heSBhcmlzZSAoZXNwZWNpYWxseSB3 aXRoIGhvcml6b250YWwgaW50ZXJ3b3JraW5nKSBzZWUKICAgW0lUVS5ZMTQwMS4yMDA4XS4K CiAgIE1QTFMgaXMgYSBtYXR1cmluZyBwYWNrZXQgdGVjaG5vbG9neSBhbmQgaXQgaXMgYWxy ZWFkeSBwbGF5aW5nIGFuCgoKCk5pdmVuLUplbmtpbnMsIGV0IGFsLiAgICBFeHBpcmVzIEph bnVhcnkgMiwgMjAwOSAgICAgICAgICAgICAgICBbUGFnZSA0XQoMCkludGVybmV0LURyYWZ0 ICAgICAgICAgICAgTVBMUy1UUCBSZXF1aXJlbWVudHMgICAgICAgICAgICAgICAgIEp1bHkg MjAwOAoKCiAgIGltcG9ydGFudCByb2xlIGluIHRyYW5zcG9ydCBuZXR3b3JrcyBhbmQgc2Vy dmljZXMuICBIb3dldmVyLCBub3QgYWxsCiAgIG9mIE1QTFMncyBjYXBhYmlsaXRpZXMgYW5k IG1lY2huaXNtcyBhcmUgbmVlZGVkIGFuZC9vciBjb25zaXN0ZW50CiAgIHdpdGggdHJhbnNw b3J0IG5ldHdvcmsgb3BlcmF0aW9ucy4gIFRoaXMgZG9jdW1lbnQgaWRlbnRpZmllcyB0aGUK ICAgcmVxdWlyZWQgY2FwYWJpbGl0aWVzIGZvciBNUExTIHNvIHRoYXQgaXQgY2FuIGJldHRl ciBmaXQgYSB0cmFuc3BvcnQKICAgcm9sZS4KCiAgIENvbWJpbmluZyB0aGUgcGFja2V0IGV4 cGVyaWVuY2Ugb2YgTVBMUyB3aXRoIHRoZSBvcGVyYXRpb25hbAogICBleHBlcmllbmNlIG9m IFNPTkVUL1NESCBjb25zdGl0dXRlcyBhIHBhY2tldCB0cmFuc3BvcnQgdGVjaG5vbG9neQog ICBuYW1lZCBNUExTLVRQLiAgTVBMUy1UUCB3aWxsIGVuYWJsZSB0aGUgbWlncmF0aW9uIG9m IFNPTkVUL1NESAogICBuZXR3b3JrcyB0byBhIHBhY2tldC1iYXNlZCBuZXR3b3JrIHRoYXQg d2lsbCBlYXNpbHkgc2NhbGUgdG8gc3VwcG9ydAogICBwYWNrZXQgc2VydmljZXMgaW4gYSBz aW1wbGUgYW5kIGNvc3QgZWZmZWN0aXZlIHdheS4KCiAgIE1QTFMtVFAgbmVlZHMgdG8gY29t YmluZSB0aGUgbmVjZXNzYXJ5IGV4aXN0aW5nIGNhcGFiaWxpdGllcyBvZiBNUExTCiAgIHdp dGggYWRkaXRpb25hbCBtaW5pbWFsIG1lY2hhbmlzbXMgaW4gb3JkZXIgdG8gbWVldCB0aGUg cmVxdWlyZW1lbnRzCiAgIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50LgoKICAgVGhlIHJl cXVpcmVtZW50cyBvZiBhbiBNUExTIHRyYW5zcG9ydCBwcm9maWxlIGFyZSBwcm92aWRlZCBi ZWxvdy4KCgoyLiAgTVBMUy1UUCBSZXF1aXJlbWVudHMKCjIuMS4gIEdlbmVyYWwgcmVxdWly ZW1lbnRzCgogICBvICBNUExTLVRQIE1VU1Qgb2ZmZXIgYXMgbXVjaCBjb21tb25hbGl0eSBh cyBwb3NzaWJsZSB3aXRoIHRoZSBNUExTCiAgICAgIHVzZXIgcGxhbmUgYXMgZGVmaW5lZCBi eSBJRVRGLiAgV2hlbiBNUExTIG9mZmVycyBtdWx0aXBsZSBvcHRpb25zCiAgICAgIGluIHRo aXMgcmVzcGVjdCwgTVBMUy1UUCBTSE9VTEQgc2VsZWN0IHRoZSBtaW5pbXVtIHN1Yi1zZXQK ICAgICAgKG5lY2Vzc2FyeSBhbmQgc3VmZmljaWVudCBzdWJzZXQpIGFwcGxpY2FibGUgdG8g YSB0cmFuc3BvcnQKICAgICAgbmV0d29yayBhcHBsaWNhdGlvbi4KCiAgIG8gIEFueSBuZXcg ZnVuY3Rpb25hbGl0eSB0aGF0IGlzIGRlZmluZWQgdG8gZnVsZmlsIHRoZSByZXF1aXJlbWVu dHMKICAgICAgZm9yIE1QTFMtVFAgTVVTVCBiZSBhZ3JlZWQgd2l0aGluIElFVEYgYW5kIHJl LXVzZSAoYXMgZmFyIGFzCiAgICAgIHByYWN0aWNhbGx5IHBvc3NpYmxlKSBleGlzdGluZyBN UExTIHN0YW5kYXJkcy4KCiAgIG8gIE1lY2hhbmlzbXMgYW5kIGNhcGFiaWxpdGllcyBNVVNU IGJlIGFibGUgdG8gaW50ZXJvcGVyYXRlIHdpdGgKICAgICAgZXhpc3RpbmcgTVBMUyBhbmQg UFdFIGNvbnRyb2wgYW5kIGRhdGEgcGxhbmVzIHdoZXJlIGFwcHJvcHJpYXRlLgoKICAgbyAg TVBMUy1UUCBNVVNUIHN1cHBvcnQgdHJhZmZpYyBlbmdpbmVlcmluZyBjYXBhYmlsaXRpZXMg dGhhdCBhbGxvdwogICAgICBkZXRlcm1pbmlzdGljIGNvbnRyb2wgb2YgdGhlIHVzZSBvZiBu ZXR3b3JrIHJlc291cmNlcy4KCiAgIG8gIE1QTFMtVFAgTVVTVCBzdXBwb3J0IHRoZSBsb2dp Y2FsIHNlcGFyYXRpb24gb2YgdGhlIGNvbnRyb2wgYW5kCiAgICAgIG1hbmFnZW1lbnQgcGxh bmVzIGZyb20gdGhlIHVzZXIgcGxhbmUuCgogICBvICBNUExTLVRQIFNIT1VMRCBzdXBwb3J0 IHRoZSBwaHlzaWNhbCBzZXBhcmF0aW9uIG9mIHRoZSBjb250cm9sIGFuZAogICAgICBtYW5h Z2VtZW50IHBsYW5lcyBmcm9tIHRoZSB1c2VyIHBsYW5lLgoKICAgbyAgTVBMUy1UUCBNVVNU IHN1cHBvcnQgcG9pbnQgdG8gcG9pbnQgKFAyUCkgb3IgcG9pbnQgdG8gbXVsdGlwb2ludAog ICAgICAoUDJNUCkgY29ubmVjdGlvbnMuCgoKCgpOaXZlbi1KZW5raW5zLCBldCBhbC4gICAg RXhwaXJlcyBKYW51YXJ5IDIsIDIwMDkgICAgICAgICAgICAgICAgW1BhZ2UgNV0KDApJbnRl cm5ldC1EcmFmdCAgICAgICAgICAgIE1QTFMtVFAgUmVxdWlyZW1lbnRzICAgICAgICAgICAg ICAgICBKdWx5IDIwMDgKCgogICBvICBNUExTLVRQIE1VU1Qgc3VwcG9ydCBzdGF0aWMgcHJv dmlzaW9uaW5nIG9mIGNvbm5lY3Rpb25zIHZpYSBhbgogICAgICBOTVMvT1NTIChpLmUuIHZp YSB0aGUgbWFuYWdlbWVudCBwbGFuZSkuCgogICBvICBTdGF0aWMgcHJvdmlzaW9uaW5nIE1V U1Qgbm90IGRlcGVuZCBvbiByb3V0aW5nIG9yIHNpZ25hbGluZwogICAgICBwcm90b2NvbHMg KGUuZy4gIEdNUExTLCBPU1BGLCBJUy1JUywgUlNWUCwgQkdQLCBMRFAgZXRjLikuCgogICBv ICBNUExTLVRQIGNvbm5lY3Rpb25zIE1BWSBiZSBhYmxlIHRvIGJlIHByb3Zpc2lvbmVkIGR5 bmFtaWNhbGx5IHZpYQogICAgICBhIGNvbnRyb2wgcGxhbmUuCgogICBvICBUaGUgTVBMUy1U UCBkYXRhIHBsYW5lIE1VU1QgYmUgY2FwYWJsZSBvZiBmdW5jdGlvbmluZwogICAgICBpbmRl cGVuZGVudGx5IG9mIHRoZSBjb250cm9sIG9yIG1hbmFnZW1lbnQgcGxhbmUgdXNlZCB0byBv cGVyYXRlCiAgICAgIHRoZSBNUExTLVRQIGxheWVyIG5ldHdvcmsuICBUaGF0IGlzIHRoZSBN UExTLVRQIGRhdGEgcGxhbmUKICAgICAgb3BlcmF0aW9uIE1VU1QgY29udGludWUgdG8gb3Bl cmF0ZSBub3JtYWxseSBpZiB0aGUgbWFuYWdlbWVudAogICAgICBwbGFuZSBvciBjb250cm9s IHBsYW5lIHRoYXQgY29uZmlndXJlZCB0aGUgY29ubmVjdGlvbnMgZmFpbHMuCgogICBvICBN UExTLVRQIE1VU1Qgc3VwcG9ydCBhbnkgbmV0d29yayB0b3BvbG9neSBhbmQgYmUgYWJsZSB0 byBzdXBwb3J0CiAgICAgIGluY3JlYXNpbmcgYmFuZHdpZHRoIGRlbWFuZHMsIHRvcG9sb2d5 LCBudW1iZXIgb2YgY3VzdG9tZXJzIG9yCiAgICAgIG51bWJlciBvZiBzZXJ2aWNlcyBpbmNy ZW1lbnRhbGx5LgoKMi4yLiAgTGF5ZXJpbmcgcmVxdWlyZW1lbnRzCgogICBvICBBbiBNUExT LVRQIG5ldHdvcmsgTVVTVCBvcGVyYXRlIGluIGEgbXVsdGlwbGUgbGF5ZXIgbmV0d29yawog ICAgICBlbnZpcm9ubWVudCBjb25zaXN0aW5nIG9mIHRoZSBmb2xsb3dpbmcgaW5kZXBlbmRl bnQgbGF5ZXJzOgoKICAgICAgMS4gIEEgInNlcnZpY2UgbGF5ZXIiIGluc3RhbmNlIGluIHdo aWNoIHRoZSBjb25uZWN0aW9ucyBjYXJyeSB0aGUKICAgICAgICAgIGN1c3RvbWVyJ3MgKGlu ZGl2aWR1YWwgb3IgYnVuZGxlZCkgc2VydmljZSAobWF5IGJlIHBvaW50LXRvLQogICAgICAg ICAgcG9pbnQsIHBvaW50LXRvLW11bHRpcG9pbnQgb3IgbXVsdGlwb2ludC10by1tdWx0aXBv aW50CiAgICAgICAgICBzZXJ2aWNlcyk7CgogICAgICAyLiAgQSAidHJ1bmsgbGF5ZXIiIHdp dGggcG9pbnQtdG8tcG9pbnQgb3IgcG9pbnQtdG8tbXVsdGlwb2ludAogICAgICAgICAgY29u bmVjdGlvbnMgd2hpY2ggYXJlIHVzZWQgdG8gY2FycnkgYWdncmVnYXRlcyBvZiB0aGUgbmV0 d29yawogICAgICAgICAgInNlcnZpY2UgbGF5ZXIiIGNvbm5lY3Rpb25zOyBhbmQKCiAgICAg IDMuICBBICJ0cmFuc21pc3Npb24gbWVkaWEgbGF5ZXIiIHdoaWNoIHByb3ZpZGVzIHNlY3Rp b25zICh0d28tcG9ydAogICAgICAgICAgcG9pbnQtdG8tcG9pbnQgY29ubmVjdGlvbnMpIHRv IGNhcnJ5IHRoZSBhZ2dyZWdhdGUgb2YgbmV0d29yawogICAgICAgICAgdHJ1bmsgb3IgbmV0 d29yayBzZXJ2aWNlIGNvbm5lY3Rpb25zIG9uIHZhcmlvdXMgcGh5c2ljYWwKICAgICAgICAg IG1lZGlhLgoKICAgTVBMUy1UUCBtYXkgcHJvdmlkZSB0aGUgInNlcnZpY2UgbGF5ZXIiIChm b3IgUDJQIGFuZCBQMk1QIHNlcnZpY2VzKQogICBhbmQvb3IgdGhlICJ0cnVuayBsYXllciIg d2l0aGluIGEgbGF5ZXIgbmV0d29yayBlbnZpcm9ubWVudC4KCiAgIG8gIEFuIE1QTFMtVFAg bGF5ZXIgbmV0d29yayBNVVNUIHN1cHBvcnQgdGhlIHRyYW5zcGFyZW50IHRyYW5zcG9ydCBv ZgogICAgICBNUExTLVRQIGFuZCBub24gTVBMUy1UUCBjbGllbnQgbGF5ZXIgbmV0d29ya3Mu CgogICBvICBBbiBNUExTLVRQIGxheWVyIG5ldHdvcmsgTVVTVCBiZSBhYmxlIHRvIGJlIHRy YW5zcGFyZW50bHkgY2FycmllZAogICAgICBvdmVyIE1QTFMtVFAgYW5kIG5vbiBNUExTLVRQ IHNlcnZlciBsYXllciBuZXR3b3JrcyAoc3VjaCBhcwogICAgICBFdGhlcm5ldCwgT1ROLCBl dGMuKQoKCgoKTml2ZW4tSmVua2lucywgZXQgYWwuICAgIEV4cGlyZXMgSmFudWFyeSAyLCAy MDA5ICAgICAgICAgICAgICAgIFtQYWdlIDZdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICBNUExTLVRQIFJlcXVpcmVtZW50cyAgICAgICAgICAgICAgICAgSnVseSAyMDA4CgoKICAg byAgSXQgTVVTVCBiZSBwb3NzaWJsZSB0byBvcGVyYXRlIHRoZSBNUExTLVRQIGxheWVyIG5l dHdvcmsKICAgICAgaW5kZXBlbmRlbnRseSBvZiBvdGhlciBsYXllciBuZXR3b3JrcyAoZWl0 aGVyIE1QTFMtVFAgb3Igbm9uCiAgICAgIE1QTFMtVFApLgoKICAgVGhpcyBpcyBub3Qgb25s eSBhIHRlY2hub2xvZ3kgcmVxdWlyZW1lbnQsIGRpZmZlcmVudCBhZG1pbmlzdHJhdGl2ZQog ICBncm91cHMgbWF5IGJlIHJlc3BvbnNpYmxlIGZvciBkaWZmZXJlbnQgbGF5ZXIgbmV0d29y a3MgKGV2ZW4gd2hlbgogICB0aGV5IGFyZSBvZiB0aGUgc2FtZSB0eXBlKSksIGFuZCByZXF1 aXJlIHRoZSBjYXBhYmlsaXR5IHRvCiAgIG9wZXJhdGlvbmFsbHkgc3VwcG9ydCB0aGUgZGlm ZmVyZW50IGxheWVycy4KCiAgIG8gIEl0IE1VU1QgYmUgcG9zc2libGUgdG8gaGlkZSBNUExT LVRQIGxheWVyIG5ldHdvcmsgYWRkcmVzc2luZyBhbmQKICAgICAgb3RoZXIgaW5mb3JtYXRp b24gKGUuZy4gdG9wb2xvZ3kpIGZyb20gY2xpZW50IGxheWVycy4KCjIuMy4gIERhdGEgcGxh bmUgcmVxdWlyZW1lbnRzCgogICBvICBUaGUgaWRlbnRpZmljYXRpb24gb2YgZWFjaCBjb25u ZWN0aW9uIHdpdGhpbiBpdHMgYWdncmVnYXRlIE1VU1QgYmUKICAgICAgc3VwcG9ydGVkLgoK ICAgbyAgQSBsYWJlbCBpbiBhIHBhcnRpY3VsYXIgc2VjdGlvbiBNVVNUIHVuaXF1ZWx5IGlk ZW50aWZ5IHRoZQogICAgICBjb25uZWN0aW9uLgoKICAgbyAgQSBjb25uZWN0aW9uJ3Mgc291 cmNlIE1VU1QgYmUgaWRlbnRpZmlhYmxlIGF0IGl0cyBkZXN0aW5hdGlvbi4KCiAgIENvbm5l Y3Rpb25zIGNhbiBiZSBhZ2dyZWdhdGVkIGludG8gdHJ1bmtzIGJ5IHB1c2hpbmcgYW5kIGRl LQogICBhZ2dyZWdhdGVkIGJ5IHBvcHBpbmcgbGFiZWxzLiAgTVBMUy1UUCBsYWJlbHMgbWF5 IGJlIHN3YXBwZWQgd2l0aGluIGEKICAgY29ubmVjdGlvbiBpbiBhIGxheWVyIG5ldHdvcmsg aW5zdGFuY2Ugd2hlbiB0aGUgdHJhZmZpYyBpcyBmb3J3YXJkZWQKICAgZnJvbSBvbmUgTVBM Uy1UUCBsaW5rIGNvbm5lY3Rpb24gdG8gYW5vdGhlciBNUExTLVRQIGxpbmsgY29ubmVjdGlv bi4KCiAgIG8gIExhYmVsbGluZyBNVVNUIG1ha2UgdXNlIG9mIHRoZSBNUExTIGxhYmVsIGFu ZCBsYWJlbCBzdGFjayBlbnRyeSBhcwogICAgICBkZWZpbmVkIGluIFJGQzMwMzIuCgogICBv ICBJdCBNVVNUIGJlIHBvc3NpYmxlIHRvIG9wZXJhdGUgYW5kIGNvbmZpZ3VyZSB0aGUgTVBM Uy1UUCBkYXRhCiAgICAgICh0cmFuc3BvcnQpIHBsYW5lIHdpdGhvdXQgYW55IElQIGZ1bmN0 aW9uYWxpdHkuCgogICBvICBNUExTLVRQIE1VU1Qgc3VwcG9ydCBib3RoIHVuaWRpcmVjdGlv bmFsIGFuZCBiaS1kaXJlY3Rpb25hbCBwb2ludC0KICAgICAgdG8tcG9pbnQgY29ubmVjdGlv bnMuCgogICBvICBUaGUgZm9yd2FyZCBhbmQgYmFja3dhcmQgZGlyZWN0aW9ucyBvZiBhIGJp LWRpcmVjdGlvbmFsIGNvbm5lY3Rpb24KICAgICAgU0hPVUxEIGZvbGxvdyB0aGUgc2FtZSBw YXRoIHdpdGhpbiB0aGUgTVBMUy1UUCBuZXR3b3JrLgoKICAgbyAgVGhlIGludGVybWVkaWF0 ZSBub2RlcyBTSE9VTEQgYmUgYXdhcmUgYWJvdXQgdGhlIGJpbmRpbmcgb2YgdGhlCiAgICAg IGZvcndhcmQgYW5kIHRoZSBiYWNrd2FyZCBkaXJlY3Rpb25zIGJlbG9uZ2luZyB0byB0aGUg c2FtZSBiaS0KICAgICAgZGlyZWN0aW9uYWwgY29ubmVjdGlvbi4KCiAgIG8gIE1QTFMtVFAg U0hPVUxEIHN1cHBvcnQgdW5pZGlyZWN0aW9uYWwgcG9pbnQtdG8tbXVsdGlwb2ludAogICAg ICBjb25uZWN0aW9ucy4KCiAgIG8gIE1QTFMtVFAgY29ubmVjdGlvbnMgTVVTVCBOT1QgcGVy Zm9ybSBtZXJnaW5nIGluIGEgd2F5IHRoYXQKICAgICAgcHJldmVudHMgdGhlIHVuaXF1ZSBp ZGVudGlmaWNhdGlvbiBvZiB0aGUgc291cmNlIGF0IHRoZQoKCgpOaXZlbi1KZW5raW5zLCBl dCBhbC4gICAgRXhwaXJlcyBKYW51YXJ5IDIsIDIwMDkgICAgICAgICAgICAgICAgW1BhZ2Ug N10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIE1QTFMtVFAgUmVxdWlyZW1lbnRzICAg ICAgICAgICAgICAgICBKdWx5IDIwMDgKCgogICAgICBkZXN0aW5hdGlvbiAoZS5nLiBubyB1 c2Ugb2YgTERQIG1wMnAgc2lnbmFsaW5nIGluIG9yZGVyIHRvIGF2b2lkCiAgICAgIGxvc2lu ZyBMU1AgaGVhZC1lbmQgaW5mb3JtYXRpb24sIG5vIHVzZSBvZiBQSFAsIGV0YykuCgogICBv ICBNUExTLVRQIFNIT1VMRCBzdXBwb3J0IHRyYW5zcG9ydCBhbmQgUW9TIG1lY2hhbmlzbXMg dGhhdCBjYW4KICAgICAgZGVsaXZlciBzdGF0aXN0aWNhbCBtdWx0aXBsZXhpbmcgZ2Fpbi4g IFBhY2tldHMgZXhjZWVkaW5nIHRoZQogICAgICBhZ3JlZWQgdHJhZmZpYyBwcm9maWxlIG1h eSBiZSBtYXJrZWQgb3IgZGlzY2FyZGVkIGJ5IHRoZSB0cmFmZmljCiAgICAgIGNvbmRpdGlv bmluZyBhdCB0aGUgaW5ncmVzcyBvZiB0aGUgTVBMUy1UUCBuZXR3b3JrLgoKICAgbyAgTVBM Uy1UUCBNVVNUIHN1cHBvcnQgY29ubmVjdGlvbnMgdGhyb3VnaCBhIHNpbmdsZSBkb21haW4u CgogICBvICBNUExTLVRQIFNIT1VMRCBzdXBwb3J0IGNvbm5lY3Rpb25zIHRocm91Z2ggbXVs dGlwbGUgZG9tYWlucy4KCiAgIG8gIE1QTFMtVFAgTVVTVCBiZSBhYmxlIHRvIGFjY29tbW9k YXRlIG5ldyB0cmFmZmljIHR5cGVzLgoKICAgbyAgTVBMUy1UUCBTSE9VTEQgc3VwcG9ydCBt ZWNoYW5pc21zIHRvIHNhZmVndWFyZCBhZ2FpbnN0IHRoZQogICAgICBwcm92aXNpb25pbmcg b2YgY29ubmVjdGlvbnMgd2hpY2ggY29udGFpbiBmb3J3YXJkaW5nIGxvb3BzLgoKICAgbyAg TVBMUy1UUCBTSE9VTEQgc3VwcG9ydCBtZWNoYW5pc21zIHRvIG1pbmltaXplIHRyYWZmaWMg aW1wYWN0CiAgICAgIGR1cmluZyBuZXR3b3JrIHJlY29uZmlndXJhdGlvbi4KCiAgIG8gIE1Q TFMtVFAgU0hPVUxEIHN1cHBvcnQgbWVjaGFuaXNtcyB3aGljaCBlbnN1cmUgdGhlIGludGVn cml0eSBvZgogICAgICB0aGUgYWRhcHRlZCBpbmZvcm1hdGlvbi4KCiAgIG8gIE1QTFMtVFAg TVVTVCBzdXBwb3J0IGFuIHVuYW1iaWd1b3VzIGFuZCByZWxpYWJsZSBtZWFucyBvZgogICAg ICBkaXN0aW5ndWlzaGluZyB1c2VycycgKGNsaWVudCkgcGFja2V0cyBmcm9tIE1QTFMtVFAg Y29udHJvbCBwbGFuZQogICAgICBhbmQgbWFuYWdlbWVudCBwbGFuZSBwYWNrZXRzLgoKMi40 LiAgQ29udHJvbCBwbGFuZSByZXF1aXJlbWVudHMKCiAgIG8gIEEgZGlzdHJpYnV0ZWQgY29u dHJvbCBwbGFuZSBNQVkgYmUgc3VwcG9ydGVkIHRvIGVuYWJsZSBmYXN0LAogICAgICBkeW5h bWljIGFuZCByZWxpYWJsZSBzZXJ2aWNlIHByb3Zpc2lvbmluZyBpbiBtdWx0aS12ZW5kb3Ig YW5kCiAgICAgIG11bHRpLWRvbWFpbiBlbnZpcm9ubWVudHMgdXNpbmcgc3RhbmRhcmRpemVk IHByb3RvY29scyB0aGF0CiAgICAgIGd1YXJhbnRlZSBpbnRlcm9wZXJhYmlsaXR5LgoKICAg byAgSWYgYSBjb250cm9sIHBsYW5lIGlzIHVzZWQgZm9yIGNvbmZpZ3VyYXRpb24gb2YgTVBM Uy1UUAogICAgICBjb25uZWN0aW9ucyB0aGVuOgoKICAgICAgKiAgRmFpbHVyZSBhbmQgcmVj b3Zlcnkgb2YgdGhlIGNvbnRyb2wgcGxhbmUgTVVTVCBOT1QgaW1wYWN0IHRoZQogICAgICAg ICBNUExTLVRQIGZvcndhcmRpbmcgcGxhbmUuCgogICAgICAqICBJdCBNVVNUIHN1cHBvcnQg dGhlIHNldHVwLCBtb2RpZmljYXRpb24sIGFuZCByZWxlYXNlIG9mIE1QTFMtVFAKICAgICAg ICAgY29ubmVjdGlvbnMgYW5kIHByb3RlY3Rpb24gY29ubmVjdGlvbnMuCgogICAgICAqICBJ dCBNVVNUIHN1cHBvcnQgbWVjaGFuaXNtcyB0byBwcm92aWRlIHRyYWZmaWMgZW5naW5lZXJp bmcsCiAgICAgICAgIGNvbnN0cmFpbnQtYmFzZWQgcm91dGluZyBhbmQgZXhwbGljaXQgcGF0 aCBjb250cm9sLgoKICAgICAgKiAgSXQgTVVTVCBwcm92aWRlIG1lY2hhbmlzbXMgdG8gYWRk cmVzcyBRb1MgYW5kIHBlcmZvcm1hbmNlCiAgICAgICAgIHJlcXVpcmVtZW50cyAoc3VjaCBh cyB0aHJvdWdocHV0LCBkZWxheSwgcGFja2V0IGxvc3MsIGV0Yy4pCgoKCk5pdmVuLUplbmtp bnMsIGV0IGFsLiAgICBFeHBpcmVzIEphbnVhcnkgMiwgMjAwOSAgICAgICAgICAgICAgICBb UGFnZSA4XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgTVBMUy1UUCBSZXF1aXJlbWVu dHMgICAgICAgICAgICAgICAgIEp1bHkgMjAwOAoKCiAgICAgICAgIHdoaWxlIHV0aWxpemlu ZyBuZXR3b3JrIHJlc291cmNlcyBlZmZpY2llbnRseSBhbmQgcmVsaWFibHkuCgogICBvICBN UExTLVRQIFNIT1VMRCBzdXBwb3J0IG9mZi1wYXRoIChvdXQtb2YtYmFuZCkgY29udHJvbCBh bmQKICAgICAgbWFuYWdlbWVudCBwbGFuZXMuCgogICBvICBUaGUgTVBMUy1UUCBjb250cm9s IHBsYW5lIE1VU1QgYmUgaW5kZXBlbmRlbnQgb2YgYW55IHBhcnRpY3VsYXIKICAgICAgY2xp ZW50IG9yIHNlcnZlciBsYXllciBjb250cm9sIHBsYW5lLgoKICAgbyAgVGhlIGNvbnRyb2wg cGxhbmUgU0hPVUxEIGZhY2lsaXRhdGUgdGhlIGltcGxlbWVudGF0aW9uIG9mIHRoZQogICAg ICBzZXJ2aWNlIGJ5IHByb3ZpZGluZyBlbmQtdG8tZW5kIHNlYW1sZXNzIGNvbm5lY3Rpdml0 eSBhbmQgc2VydmljZQogICAgICBhc3N1cmFuY2UuCgogICBvICBUaGUgTVBMUy1UUCBjb250 cm9sIHBsYW5lIE1VU1Qgc3VwcG9ydCBlc3RhYmxpc2hpbmcgYWxsIHRoZQogICAgICBjb25u ZWN0aXZpdHkgcGF0dGVybnMgZGVmaW5lZCBmb3IgdGhlIE1QTFMtVFAgdHJhbnNwb3J0IHBs YW5lCiAgICAgIChlLmcuLCB1bmktZGlyZWN0aW9uYWwgYW5kIGJpZGlyZWN0aW9uYWwgUDJQ LCB1bmktZGlyZWN0aW9uYWwKICAgICAgUDJNUCwgZXRjLikgaW5jbHVkaW5nIGNvbmZpZ3Vy YXRpb24gb2YgcHJvdGVjdGlvbiBmdW5jdGlvbnMgYW5kCiAgICAgIGFueSBhc3NvY2lhdGVk IG1haW50ZW5hbmNlIGZ1bmN0aW9ucy4KCiAgIG8gIFRoZSBNUExTLVRQIGNvbnRyb2wgcGFu ZSBtdXN0IHN1cHBvcnQgdGhlIGNvbmZpZ3VyYXRpb24gYW5kCiAgICAgIG1vZGlmaWNhdGlv biBvZiBPQU0gbWFpbnRlbmFuY2UgcG9pbnRzIGFzIHdlbGwgYXMgdGhlIGFjdGl2YXRpb24v CiAgICAgIGRlYWN0aXZhdGlvbiBvZiBPQU0gd2hlbiB0aGUgY29ubmVjdGlvbiBpcyBlc3Rh Ymxpc2hlZCBvcgogICAgICBtb2RpZmllZC4KCiAgIG8gIEFuIE1QTFMtVFAgY29udHJvbCBw bGFuZSBNVVNUIHN1cHBvcnQgdG9wb2xvZ3kgaGlkaW5nIGFuZCBhZGRyZXNzCiAgICAgIGlu ZGVwZW5kZW5jZSBiZXR3ZWVuIGRvbWFpbnMuCgogICBvICBBdCB0aGUgYm91bmRhcnkgb2Yg YSBkb21haW4gYW4gTVBMUy1UUCBjb250cm9sIHBsYW5lIE1VU1Qgc3VwcG9ydAogICAgICB1 bmlxdWUgbmFtZXMgb3IgYWRkcmVzc2VzIGlkZW50aWZ5aW5nIGJvdW5kYXJ5IHBvaW50cyB0 byBiZQogICAgICBpbnRlcmNvbm5lY3RlZC4KCiAgIG8gIEF0IHRoZSBib3VuZGFyeSBvZiBh IGRvbWFpbiBhbiBNUExTLVRQIGNvbnRyb2wgcGxhbmUgbXVzdCBzdXBwb3J0CiAgICAgIGdy b3VwIG5hbWVzIG9yIGFkZHJlc3NlcyBpZGVudGlmeWluZyBzZXRzIG9mIGJvdW5kYXJ5IHBv aW50cyB0byBiZQogICAgICBpbnRlcmNvbm5lY3RlZC4KCiAgIG8gIE1QTFMtVFAgbGF5ZXIg bmV0d29yayBhY2Nlc3MgcG9pbnRzIChvciBjb25uZWN0aW9uIHBvaW50cyB0aGF0CiAgICAg IHByb3h5IGZvciBhY2Nlc3MgcG9pbnRzKSBTSE9VTEQgYmUgYWJsZSB0byBiZSBhc3NpZ25l ZCBuYW1lcyB3aGljaAogICAgICBhcmUgYXZhaWxhYmxlIHRvIGNsaWVudHMgdG8gaWRlbnRp ZnkgZW5kcG9pbnRzIGluIGNhbGwgb3IKICAgICAgY29ubmVjdGlvbiByZXF1ZXN0cy4KCiAg IG8gIEFuIE1QTFMtVFAgY29udHJvbCBwbGFuZSBNVVNUIHN1cHBvcnQgdHJhbnNsYXRpb24g YmV0d2VlbgogICAgICBleHRlcm5hbGx5IHZpc2libGUgZW5kcG9pbnQgbmFtZXMgYW5kIGlu dGVybmFsIG5ldHdvcmsgYWRkcmVzc2VzLgoKICAgbyAgQW4gTVBMUy1UUCBjb250cm9sIHBs YW5lIE1VU1Qgc3VwcG9ydCBjb25zdHJhaW50LWJhc2VkIHJvdXRlCiAgICAgIGNhbGN1bGF0 aW9uLgoKICAgbyAgQW4gTVBMUy1UUCBjb250cm9sIHBsYW5lIE1VU1Qgc3VwcG9ydCBwcm92 aXNpb25pbmcgYW5kIGFwcGxpY2F0aW9uCiAgICAgIG9mIHJvdXRpbmcgY29uc3RyYWludCBw b2xpY2llcy4KCgoKCk5pdmVuLUplbmtpbnMsIGV0IGFsLiAgICBFeHBpcmVzIEphbnVhcnkg MiwgMjAwOSAgICAgICAgICAgICAgICBbUGFnZSA5XQoMCkludGVybmV0LURyYWZ0ICAgICAg ICAgICAgTVBMUy1UUCBSZXF1aXJlbWVudHMgICAgICAgICAgICAgICAgIEp1bHkgMjAwOAoK CiAgIG8gIEFuIE1QTFMtVFAgY29udHJvbCBwbGFuZSBNVVNUIHN1cHBvcnQgcHJlLXByb3Zp c2lvbmVkIGNvbm5lY3Rpb24KICAgICAgcHJvdGVjdGlvbi4KCiAgIEluIHNvbWUgc2l0dWF0 aW9ucyBpdCBpcyBpbXByYWN0aWNhbCB0byBleHBlY3QgYWNjZXB0YWJsZSByZWNvdmVyeQog ICBwZXJmb3JtYW5jZSB0byBiZSBhY2hpZXZlZCB1c2luZyBkeW5hbWljIHJlY2FsY3VsYXRp b24gb2YgY29ubmVjdGlvbgogICByb3V0ZXMuICBGb3IgdGhpcyByZWFzb24sIGl0IGlzIG5l Y2Vzc2FyeSB0byBhbGxvdyBmb3IgcHJlLXBsYW5uaW5nCiAgIG9mIHByb3RlY3Rpb24gcm91 dGVzIGZvciBzZWxlY3RlZCBjb25uZWN0aW9ucy4KCiAgIG8gIFRoZSBNUExTLVRQIGNvbnRy b2wgcGxhbmUgTVVTVCBzdXBwb3J0IGZhc3QgcmVzdG9yYXRpb24uCgogICBvICBBbiBNUExT LVRQIGNvbnRyb2wgcGxhbmUgTVVTVCBzY2FsZSBncmFjZWZ1bGx5IHRvIHN1cHBvcnQgYSBs YXJnZQogICAgICBudW1iZXIgb2YgY29ubmVjdGlvbnMuCgogICBbSW5jbHVkZSBzb21lIG51 bWJlcnMgdG8gaW5kaWNhdGUgaG93IGxhcmdlIHRoZSBDUCBpcyBleHBlY3RlZCB0bwogICBz Y2FsZSB0bz9dCgogICBvICBBbiBNUExTLVRQIGNvbnRyb2wgcGxhbmUgTVVTVCBjbGVhcmx5 IGRpc3Rpbmd1aXNoIHJlc291cmNlcwogICAgICBiZWxvbmdpbmcgdG8gdGhlIE1QTFMtVFAg bGF5ZXIgbmV0d29yayBmcm9tIHRob3NlIGluIG90aGVyIGxheWVyCiAgICAgIG5ldHdvcmtz IHRoYXQgbWF5IGFsc28gYmUgdW5kZXIgY29udHJvbCBwbGFuZSBjb250cm9sLgoKICAgbyAg QW4gTVBMUy1UUCBjb250cm9sIHBsYW5lIE1VU1Qgc3VwcG9ydCB0aGUgaW5kZXBlbmRlbnQK ICAgICAgaWRlbnRpZmljYXRpb24gb2YgbG9naWNhbGx5IGRpc3RpbmN0IGNvbnRyb2wgcGxh bmUgZWxlbWVudHMuCgogICBvICBJdCBNVVNUIGJlIHBvc3NpYmxlIHRvIGlkZW50aWZ5IGFu ZCBwcm92aXNpb24gdGhlc2UgZWxlbWVudHMKICAgICAgaW5kZXBlbmRlbnRseSwgaW4gb3Jk ZXIgdG8gcmVvcmdhbml6ZSB0aGUgY29udHJvbCBwbGFuZSBjb21wb25lbnRzCiAgICAgIHdp dGhvdXQgaW1wYWN0aW5nIHRoZSBkYXRhIHBsYW5lIHNlcnZpY2VzIGFuZCB2aWNlLXZlcnNh LgoKICAgQXJjaGl0ZWN0dXJhbGx5IGRpc3RpbmN0IGVsZW1lbnRzIGluIGEgY29udHJvbCBw bGFuZSBpbmNsdWRlOiBub2RlcwogICBhbmQgbGlua3MsIGNvbnRyb2wgcGxhbmUgZnVuY3Rp b25hbCBjb21wb25lbnRzLCBwcm90b2NvbCBjb250cm9sbGVycywKICAgZXRjLgoKICAgbyAg QW4gTVBMUy1UUCBjb250cm9sIHBsYW5lIFNIT1VMRCBwcm92aWRlIGEgY29tbW9uIGNvbnRy b2wgbWVjaGFuaXNtCiAgICAgIGZvciBhcmNoaXRlY3R1cmFsbHkgc2ltaWxhciBvcGVyYXRp b25zLgoKICAgbyAgQW4gTVBMUy1UUCBjb250cm9sIHBsYW5lIE1VU1Qgc3VwcG9ydCBtZWNo YW5pc21zIGZvciBwYXJ0aXRpb25pbmcKICAgICAgdGhlIG5ldHdvcmsgdW5kZXIgY29udHJv bCBpbnRvIHNlcGFyYXRlIHBlZXIgb3IgaGllcmFyY2hpY2FsCiAgICAgIGNvbnRyb2wgZG9t YWlucy4KCiAgIG8gIFRvIGVuYWJsZSB0aGUgZGVwbG95bWVudCBvZiBhIHVuaWZpZWQgY29u dHJvbCBwbGFuZSBhaW1lZCBhdAogICAgICBjb250cm9sbGluZyB0aGUgc2V0IG9mIHRyYW5z cG9ydCB0ZWNobm9sb2dpZXMgdXNlZCBpbiBhIHRyYW5zcG9ydAogICAgICBuZXR3b3JrLCB0 aGUgTVBMUy1UUCBjb250cm9sIHBsYW5lIE1VU1QgYWxzbyBiZSBhcHBsaWNhYmxlIHRvCiAg ICAgIG90aGVyIHRyYW5zcG9ydCBsYXllciBuZXR3b3JrcyBhbmQgcHJvdmlkZSBjb21tb24g b3BlcmF0aW9ucwogICAgICBhY3Jvc3MgbXVsdGlwbGUgbGF5ZXJzLiAgSW4gb3JkZXIgdG8g bWFpbnRhaW4gaW5kZXBlbmRlbmNlIGJldHdlZW4KICAgICAgTVBMUy1UUCBhbmQgaXRzIHJl c3BlY3RpdmUgY2xpZW50IGFuZCBzZXJ2ZXIgbGF5ZXIgbmV0d29yawogICAgICBzZXBhcmF0 ZSBjb250cm9sIHBsYW5lIGluc3RhbmNlcyBTSE9VTEQgYmUgdXNlZCB0byBjb250cm9sIGEg c2V0CiAgICAgIG9mIHRyYW5zcG9ydCBsYXllciBuZXR3b3Jrcy4KCgoKCgpOaXZlbi1KZW5r aW5zLCBldCBhbC4gICAgRXhwaXJlcyBKYW51YXJ5IDIsIDIwMDkgICAgICAgICAgICAgICBb UGFnZSAxMF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIE1QTFMtVFAgUmVxdWlyZW1l bnRzICAgICAgICAgICAgICAgICBKdWx5IDIwMDgKCgogICBvICBNUExTLVRQIFNIT1VMRCBk ZXRlY3QgYW5kIHJlY292ZXIgZnJvbSBjb250cm9sIHBsYW5lIGZhaWx1cmVzIGFuZAogICAg ICBkZWdyYWRhdGlvbnMgdXNpbmcgZ3JhY2VmdWwgb3BlcmF0aW9ucy4KCjIuNS4gIE5ldHdv cmsgTWFuYWdlbWVudCAoTk0pIHJlcXVpcmVtZW50cwoKICAgbyAgTVBMUy1UUCBNVVNUIG9w ZXJhdGUgdW5kZXIgYSBjb21tb24gb3BlcmF0aW9uLCBjb250cm9sIGFuZAogICAgICBtYW5h Z2VtZW50IHBhcmFkaWdtIHdpdGggcmVzcGVjdCB0byBvdGhlciB0cmFuc3BvcnQgdGVjaG5v bG9naWVzCiAgICAgIChlLmcuICBTREgsIE9UTiBvciBXRE0pLgoKICAgbyAgQW4gTVBMUy1U UCBuZXR3b3JrIE1VU1QgYmUgYWJsZSB0byBiZSBvcGVyYXRlZCB3aXRoIGEgY2VudHJhbGl6 ZWQKICAgICAgTk1TIHN5c3RlbS4KCiAgIG8gIEFuIE1QTFMtVFAgbmV0d29yayBTSE9VTEQg YmUgYWJsZSB0byBiZSBvcGVyYXRlZCBieSBhIGNlbnRyYWxpemVkCiAgICAgIE5NUyBzeXN0 ZW0gd2l0aCB0aGUgc3VwcG9ydCBvZiBhIGRpc3RyaWJ1dGVkIGNvbnRyb2wgcGxhbmUuCgog ICBvICBUaGUgTVBMUy1UUCBtYW5hZ2VtZW50IHBsYW5lIE1VU1QgTk9UIGRlcGVuZCBvbiBh IHNwZWNpZmljIGNsaWVudAogICAgICBsYXllciBtYW5hZ2VtZW50IHBsYW5lLgoKICAgbyAg VGhlIE1QTFMtVFAgbWFuYWdlbWVudCBwbGFuZSBNVVNUIHN1cHBvcnQgdGhlIGNvbmZpZ3Vy YXRpb24gYW5kCiAgICAgIG1vZGlmaWNhdGlvbiBvZiBPQU0gbWFpbnRlbmFuY2UgcG9pbnRz IGFzIHdlbGwgYXMgdGhlIGFjdGl2YXRpb24vCiAgICAgIGRlYWN0aXZhdGlvbiBvZiBPQU0g d2hlbiB0aGUgY29ubmVjdGlvbiBpcyBlc3RhYmxpc2hlZCBvcgogICAgICBtb2RpZmllZC4K CiAgIEZvciB0aGUgY29tcGxldGUgc2V0IG9mIHJlcXVpcmVtZW50cyByZWxhdGVkIHRvIE5N IGZ1bmN0aW9uYWxpdHkgZm9yCiAgIE1QTFMtVFAsIHNlZSB0aGUgTVBMUy1UUCBOTSByZXF1 aXJlbWVudHMgZG9jdW1lbnQgW1JFRl0uCgoyLjYuICBPQU0gcmVxdWlyZW1lbnRzCgogICBv ICBNUExTLVRQIFNIT1VMRCBwcm92aWRlIGEgY29tcHJlaGVuc2l2ZSBzZXQgb2YgY2FwYWJp bGl0aWVzICh0aGF0CiAgICAgIGFyZSBpbmRlcGVuZGVudCBvZiBhbmQgYWdub3N0aWMgdG8g dGhlIHRyYW5zbWl0dGVkIGNsaWVudAogICAgICBzZXJ2aWNlcykgdG8gc3VwcG9ydCBmYXVs dCBtYW5hZ2VtZW50LCBwZXJmb3JtYW5jZSBtb25pdG9yaW5nIChvZgogICAgICB0aGUgTVBM Uy1UUCBuZXR3b3JrIGFuZCB0aGUgc2VydmljZXMpLCBwcm90ZWN0aW9uIHN3aXRjaGluZywg ZmF1bHQKICAgICAgbG9jYWxpemF0aW9uLCBzaWduYWwgcXVhbGl0eSBtZWFzdXJlbWVudCwg ZXRjLgoKICAgbyAgQSBtZWNoYW5pc20gU0hPVUxEIGJlIHN1cHBvcnRlZCB0byBkZXRlY3Qs IGRpYWdub3NlIGFuZCBlbmFibGUKICAgICAgcmVjb3ZlcnkgZnJvbSBmYWNpbGl0eSBhbmQg ZXF1aXBtZW50IGZhaWx1cmVzIGFuZCBwZXJmb3JtYW5jZQogICAgICBkZWdyYWRhdGlvbnMg YWNjb3JkaW5nIHRvIHRoZSByZXF1aXJlbWVudHMgb2YgdGhlIHNlcnZpY2UuCgogICBvICBN UExTLVRQIE9BTSBNVVNUIGJlIGFibGUgdG8gb3BlcmF0ZSB3aXRob3V0IElQIGZ1bmN0aW9u YWxpdHkgYW5kCiAgICAgIHdpdGhvdXQgcmVseWluZyBvbiBjb250cm9sIGFuZC9vciBtYW5h Z2VtZW50IHBsYW5lcy4KCiAgIEZvciB0aGUgY29tcGxldGUgc2V0IG9mIHJlcXVpcmVtZW50 cyByZWxhdGVkIHRvIE9BTSBmdW5jdGlvbmFsaXR5IGZvcgogICBNUExTLVRQLCBzZWUgdGhl IE1QTFMtVFAgT0FNIHJlcXVpcmVtZW50cyBkb2N1bWVudCBbUkVGXS4KCjIuNy4gIE5ldHdv cmsgcGVyZm9ybWFuY2UgbWFuYWdlbWVudCAoUE0pIHJlcXVpcmVtZW50cwoKCgoKCgpOaXZl bi1KZW5raW5zLCBldCBhbC4gICAgRXhwaXJlcyBKYW51YXJ5IDIsIDIwMDkgICAgICAgICAg ICAgICBbUGFnZSAxMV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIE1QTFMtVFAgUmVx dWlyZW1lbnRzICAgICAgICAgICAgICAgICBKdWx5IDIwMDgKCgogICBvICBNUExTLVRQIE1V U1Qgc3VwcG9ydCB0cmFmZmljLWVuZ2luZWVyaW5nIGNhcGFiaWxpdGllcyB3aXRoCiAgICAg IHRyYWZmaWMtIGFuZC9vciByZXNvdXJjZS1vcmllbnRlZCBwZXJmb3JtYW5jZSBvYmplY3Rp dmVzLgoKICAgbyAgTVBMUy1UUCBNVVNUIHN1cHBvcnQgYSBtZXRob2QgdG8gb2ZmZXIgcGFj a2V0IGxvc3Mgb2JqZWN0aXZlcwogICAgICBjb21wYXJhYmxlIHRvIHRob3NlIGluIFRETSB0 cmFuc3BvcnQgbmV0d29ya3MgKG9ubHkgZHVlIHRvIGJpdAogICAgICBlcnJvcnMpLgoKICAg Rm9yIHRoZSBjb21wbGV0ZSBzZXQgb2YgcmVxdWlyZW1lbnRzIHJlbGF0ZWQgdG8gUE0gZnVu Y3Rpb25hbGl0eSBmb3IKICAgTVBMUy1UUCwgc2VlIHRoZSBNUExTLVRQIE9BTSByZXF1aXJl bWVudHMgZG9jdW1lbnQgW1JFRl0uCgoyLjguICBQcm90ZWN0aW9uICYgU3Vydml2YWJpbGl0 eSByZXF1aXJlbWVudHMKCiAgIE5ldHdvcmsgc3Vydml2YWJpbGl0eSBwbGF5cyBhIGNyaXRp Y2FsIGZhY3RvciBpbiB0aGUgZGVsaXZlcnkgb2YKICAgcmVsaWFibGUgc2VydmljZXMuICBO ZXR3b3JrIGF2YWlsYWJpbGl0eSBpcyBhIHNpZ25pZmljYW50IGNvbnRyaWJ1dG9yCiAgIHRv IHJldmVudWUgYW5kIHByb2ZpdC4gIFNlcnZpY2UgZ3VhcmFudGVlcyBpbiB0aGUgZm9ybSBv ZiBTTEFzCiAgIHJlcXVpcmUgYSByZXNpbGllbnQgbmV0d29yayB0aGF0IHJhcGlkbHkgZGV0 ZWN0cyBmYWNpbGl0eSBvciBub2RlCiAgIGZhaWx1cmVzIGFuZCByZXN0b3JlcyBuZXR3b3Jr IG9wZXJhdGlvbiBpbiBhY2NvcmRhbmNlIHdpdGggdGhlIHRlcm1zCiAgIG9mIHRoZSBTTEEu CgogICBUaGUgcmVxdWlyZW1lbnRzIGluIHRoaXMgc2VjdGlvbiB1c2Ugb2YgdGhlIHJlY292 ZXJ5IHRlcm1pbm9sb2d5CiAgIGRlZmluZWQgaW4gUkZDIDQ0MjdbUkZDNDQyN10uCgogICBv ICBNUExTLVRQIFNIT1VMRCBzdXBwb3J0IHRyYW5zcG9ydCBuZXR3b3JrIHN0eWxlIHByb3Rl Y3Rpb24KICAgICAgc3dpdGNoaW5nIG1lY2hhbmlzbXMgKHRhbmRlbSBuZXR3b3JrIGNvbm5l Y3Rpb24gcHJvdGVjdGlvbiwgTFNQCiAgICAgIHByb3RlY3Rpb24gYW5kIFBXIHByb3RlY3Rp b24pIHRvIHByb3ZpZGUgdGhlIHN1Yi01MG1zIHJlY292ZXJ5CiAgICAgIHRpbWUgcmVxdWly ZWQgdG8gbWFpbnRhaW4gY3VzdG9tZXIgdHJhbnNwYXJlbmN5LCBldmVuIHdoZW4KICAgICAg dGhvdXNhbmRzIG9mIHNlcnZpY2VzIGFyZSBzaW11bHRhbmVvdXNseSBhZmZlY3RlZCBieSBh IGZhaWx1cmUuCiAgICAgIFtJcyBzdWItNTBtcyByZWFsbHkgYSByZXF1aXJlbWVudCwgZG8g d2Ugd2FudCB0byBjbGFyaWZ5IHRoaXMKICAgICAgZnVydGhlciAtIGlzIGl0IHN1Yi01MG1z IGVuZCB0byBlbmQsIG9yIHBlciBsaW5rP10KCiAgIG8KCiAgICAgICogIE1QTFMtVFAgcmVj b3ZlcnkgbWVjaGFuaXNtcyBTSE9VTEQgYmUgYXBwbGljYWJsZSBhdCB2YXJpb3VzCiAgICAg ICAgIGxldmVscyB0aHJvdWdob3V0IHRoZSBuZXR3b3JrLCBTUEFOLCB0YW5kZW0gY29ubmVj dGlvbiBhbmQgZW5kLQogICAgICAgICB0by1lbmQuICBBbnkgcmVjb3ZlcnkgbWVjaGFuaXNt IHVzZWQgaW4gYSB0YW5kZW0gY29ubmVjdGlvbgogICAgICAgICBNVVNUIGJlIGluZGVwZW5k ZW50IG9mIG90aGVyIHRhbmRlbSBjb25uZWN0aW9ucy4KCiAgICAgICogIE1QTFMtVFAgU0hP VUxEIHN1cHBvcnQgbWVjaGFuaXNtcyB0aGF0IGtlZXAgdHJhZmZpYyBmbG93aW5nCiAgICAg ICAgIHdoaWxlIHRoZSBuZXR3b3JrIHJlY292ZXJzIGZyb20gZmFpbHVyZXMuCgogICAgICAq ICBNUExTLVRQIFNIT1VMRCBzdXBwb3J0IG5ldHdvcmsgcmVzdG9yYXRpb24gbWVjaGFuaXNt cwogICAgICAgICBjb250cm9sbGVkIGJ5IGEgZGlzdHJpYnV0ZWQgY29udHJvbCBwbGFuZSBh bmQvb3IgYnkgYQogICAgICAgICBtYW5hZ2VtZW50IHBsYW5lIGJhc2VkLgoKICAgICAgKgoK ICAgICAgICAgKyAgVGhlIHJlc3RvcmF0aW9uIHJlc291cmNlcyBNQVkgYmUgcHJlLXBsYW5u ZWQgYW5kIHNlbGVjdGVkIGEKICAgICAgICAgICAgcHJpb3JpLCBvciBjb21wdXRlZCBhZnRl ciBmYWlsdXJlIG9jY3VycmVuY2UuCgoKCk5pdmVuLUplbmtpbnMsIGV0IGFsLiAgICBFeHBp cmVzIEphbnVhcnkgMiwgMjAwOSAgICAgICAgICAgICAgIFtQYWdlIDEyXQoMCkludGVybmV0 LURyYWZ0ICAgICAgICAgICAgTVBMUy1UUCBSZXF1aXJlbWVudHMgICAgICAgICAgICAgICAg IEp1bHkgMjAwOAoKCiAgICAgICAgICsgIE1QTFMtVFAgTUFZIHN1cHBvcnQgc2hhcmVkLW1l c2ggcmVzdG9yYXRpb24uCgogICAgICAgICArICBNUExTLVRQIFNIT1VEIHN1cHBvcnQgc29m dCBMU1AgcmVzdG9yYXRpb24uCgogICAgICAgICArICBNUExTLVRQIE1BWSBzdXBwb3J0IGhh cmQgTFNQIHJlc3RvcmF0aW9uLgoKICAgICAgICAgKyAgVGhlIHJlc3RvcmF0aW9uIG1lY2hh bmlzbSBNVVNUIGJlIGFwcGxpY2FibGUgdG8gYW55CiAgICAgICAgICAgIHRvcG9sb2d5LgoK ICAgICAgICAgKyAgUmVzdG9yYXRpb24gcHJpb3JpdHkgTUFZIGJlIGltcGxlbWVudGVkIHRv IGRldGVybWluZSB0aGUKICAgICAgICAgICAgb3JkZXIgaW4gd2hpY2ggY29ubmVjdGlvbnMg c2hvdWxkIGJlIHJlc3RvcmVkICh0byBtaW5pbWl6ZQogICAgICAgICAgICBzZXJ2aWNlIHJl c3RvcmF0aW9uIHRpbWUgYXMgd2VsbCBhcyB0byBnYWluIGFjY2VzcyB0bwogICAgICAgICAg ICBhdmFpbGFibGUgc3BhcmUgY2FwYWNpdHkgb24gdGhlIGJlc3QgcGF0aHMpLiAgUHJlZW1w dGlvbgogICAgICAgICAgICBwcmlvcml0eSBNQVkgYmUgdXNlZCBpbiB0aGUgZXZlbnQgdGhh dCBub3QgYWxsIGNvbm5lY3Rpb25zCiAgICAgICAgICAgIGNhbiBiZSByZXN0b3JlZCwgaW4g d2hpY2ggY2FzZSBjb25uZWN0aW9ucyB3aXRoIGxvd2VyCiAgICAgICAgICAgIHByZWVtcHRp b24gcHJpb3JpdHkgc2hvdWxkIGJlIHJlbGVhc2VkLgoKICAgICAgICAgKyAgVGhlIHJlc3Rv cmF0aW9uIG1lY2hhbmlzbSBTSE9VTEQgb3BlcmF0ZSBpbiBzeW5lcmd5IHdpdGgKICAgICAg ICAgICAgb3RoZXIgdHJhbnNwb3J0IG5ldHdvcmsgdGVjaG5vbG9naWVzIChTREgsIE9UTiwg V0RNKS4KCiAgICAgICogIE1QTFMtVFAgU0hPVUxEIHN1cHBvcnQgZGF0YSBwbGFuZSBkcml2 ZW4gcHJvdGVjdGlvbiBtZWNoYW5pc21zCiAgICAgICAgICh3aXRob3V0IGFueSBkZXBlbmRl bmN5IG9uIGEgY29udHJvbCBwbGFuZSBvciBJUCBwcm90b2NvbHMpIHRvCiAgICAgICAgIGVu YWJsZSBmYXN0IHJlY292ZXJ5IGZyb20gZmFpbHVyZSwgYW5kIHRoZXJlYnkgdG8gZW5oYW5j ZSB0aGUKICAgICAgICAgcmVsaWFiaWxpdHkgYW5kIGF2YWlsYWJpbGl0eSBwZXJmb3JtYW5j ZSBvZiBNUExTLVRQIG5ldHdvcmtzLgoKICAgICAgKgoKICAgICAgICAgKyAgTVBMUy1UUCBw cm90ZWN0aW9uIG1lY2hhbmlzbXMgU0hPVUxEIGJlIGFwcGxpZWQgdG8gTFNQcyBhbmQKICAg ICAgICAgICAgUFdzLgoKICAgICAgICAgKyAgTVBMUy1UUCBNVVNUIHN1cHBvcnQgbWVjaGFu aXNtcyB0aGF0IHJhcGlkbHkgZGV0ZWN0LCBsb2NhdGUsCiAgICAgICAgICAgIG5vdGlmeSBh bmQgcmVtZWR5IG5ldHdvcmsgZmF1bHRzLgoKICAgICAgICAgKyAgTVBMUy1UUCBNVVNUIHN1 cHBvcnQgMToxIGJpZGlyZWN0aW9uYWwgcHJvdGVjdGlvbiBzd2l0Y2hpbmcuCiAgICAgICAg ICAgIFRoZSBwcm90ZWN0aW9uIHN0YXRlIG9mIGJvdGggZW5kcyBvZiB0aGUgcHJvdGVjdGVk IGVudGl0eQogICAgICAgICAgICBNVVNUIGJlIHN5bmNocm9uaXplZC4KCiAgICAgICAgICsg IE1QTFMtVFAgTUFZIHN1cHBvcnQgMSsxIHVuaWRpcmVjdGlvbmFsIHByb3RlY3Rpb24gc3dp dGNoaW5nLgoKICAgICAgICAgKyAgTVBMUy1UUCBwcm90ZWN0aW9uIG1lY2hhbmlzbXMgTVVT VCBiZSBhcHBsaWNhYmxlIHRvIGJvdGgKICAgICAgICAgICAgcG9pbnQtdG8tcG9pbnQgYW5k IHBvaW50LXRvLW11bHRpcG9pbnQgY29ubmVjdGlvbnMuCgogICAgICAgICArICBJdCBTSE9V TEQgYmUgcG9zc2libGUgdG8gYWNoaWV2ZSBwcm90ZWN0aW9uIGF0IHRoZSBNUExTLVRQCiAg ICAgICAgICAgIGxheWVyIGFzIGZhc3QgYXMgcG9zc2libGUgKHN1YmplY3QgdG8gdGhlIHRl bXBvcmFsCiAgICAgICAgICAgIHJlc29sdXRpb24gb2YgdGhlIGRlZmVjdCBkZXRlY3Rpb24g bWVjaGFuaXNtKS4KCiAgICAgICAgICsgIFByb3RlY3Rpb24gcmF0aW8gTVVTVCBiZSBvZiAx MDAlLCBpLmUuLCAxMDAlIG9mIGltcGFpcmVkCiAgICAgICAgICAgIHdvcmtpbmcgdHJhZmZp YyBNVVNUIGJlIHByb3RlY3RlZCBmb3IgYSBmYWlsdXJlIG9uIGEgc2luZ2xlCgoKCk5pdmVu LUplbmtpbnMsIGV0IGFsLiAgICBFeHBpcmVzIEphbnVhcnkgMiwgMjAwOSAgICAgICAgICAg ICAgIFtQYWdlIDEzXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgTVBMUy1UUCBSZXF1 aXJlbWVudHMgICAgICAgICAgICAgICAgIEp1bHkgMjAwOAoKCiAgICAgICAgICAgIHdvcmtp bmcgTFNQLgoKICAgICAgICAgKyAgT3BlcmF0b3IgcmVxdWVzdHMgZm9yIG1hbnVhbCBjb250 cm9sIG9mIHByb3RlY3Rpb24gc3dpdGNoaW5nCiAgICAgICAgICAgIHN1Y2ggYXMgY2xlYXIs IGxvY2tvdXQgb2YgcHJvdGVjdGlvbiwgZm9yY2VkLXN3aXRjaCBhbmQKICAgICAgICAgICAg bWFudWFsLXN3aXRjaCBjb21tYW5kcyBNVVNUIGJlIHN1cHBvcnRlZC4gIFByaW9yaXRpemVk CiAgICAgICAgICAgIHByb3RlY3Rpb24gYmV0d2VlbiBTaWduYWwgRmFpbCAoU0YpLCBTaWdu YWwgRGVncmFkYXRpb24gKFNEKQogICAgICAgICAgICBhbmQgb3BlcmF0b3Igc3dpdGNoIHJl cXVlc3RzIE1VU1QgYmUgc3VwcG9ydGVkLgoKICAgICAgICAgKyAgTVBMUy1UUCBwcm90ZWN0 aW9uIG1lY2hhbmlzbXMgTVVTVCBzdXBwb3J0IHJldmVydGl2ZSBhbmQKICAgICAgICAgICAg bm9uLXJldmVydGl2ZSBiZWhhdmlvdXIuIG8gQW4gZXh0cmEgdHJhZmZpYyBjYXBhYmlsaXR5 CiAgICAgICAgICAgIFNIT1VMRCBiZSBzdXBwb3J0ZWQgd2hlbiBwb3NzaWJsZS4KCiAgICAg ICAgICsgIE1QTFMtVFAgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgbWVjaGFuaXNtcyBNVVNUIHBy ZXZlbnQKICAgICAgICAgICAgZnJlcXVlbnQgb3BlcmF0aW9uIG9mIHRoZSBwcm90ZWN0aW9u IHN3aXRjaCBkdWUgdG8gYW4KICAgICAgICAgICAgaW50ZXJtaXR0ZW50IGRlZmVjdC4KCiAg ICAgICAgICsgIE1QTFMtVFAgcHJvdGVjdGlvbiBtZWNoYW5pc21zIE1VU1QgZW5zdXJlIGNv LW9yZGluYXRpb24gb2YKICAgICAgICAgICAgdGltaW5nIG9mIHByb3RlY3Rpb24gc3dpdGNo ZXMgYXQgbXVsdGlwbGUgbGF5ZXJzIHRvIGF2b2lkCiAgICAgICAgICAgIHJhY2VzIGFuZCB0 byBhbGxvdyB0aGUgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgbWVjaGFuaXNtIG9mIHRoZQogICAg ICAgICAgICBzZXJ2ZXIgbGF5ZXIgdG8gZml4IHRoZSBwcm9ibGVtIGJlZm9yZSBzd2l0Y2hp bmcgYXQgdGhlCiAgICAgICAgICAgIE1QTFMtVFAgbGF5ZXIuCgogICAgICAgICArICBNUExT LVRQIE1BWSBzdXBwb3J0IG1lY2hhbmlzbXMgdGhhdCBhcmUgb3B0aW1pemVkIGZvcgogICAg ICAgICAgICBzcGVjaWZpYyBuZXR3b3JrIHRvcG9sb2dpZXMgKFJpbmcsIE1lc2gpIGluIG9y ZGVyIHRvIGhhbmRsZQogICAgICAgICAgICBwcm90ZWN0aW9uIHN3aXRjaGluZyBpbiBhIGNv c3QtZWZmaWNpZW50IG1hbm5lci4KCjIuOS4gIFFvUyByZXF1aXJlbWVudHMKCiAgIFNlcnZp Y2UgcHJvdmlkZXJzIHJlcXVpcmUgYWR2YW5jZWQgdHJhZmZpYyBtYW5hZ2VtZW50IGNhcGFi aWxpdGllcyB0bwogICBlbmZvcmNlIGFuZCBndWFyYW50ZWUgdGhlIFFvUyBwYXJhbWV0ZXJz IG9mIGN1c3RvbWVycycgU0xBcy4KCiAgIFF1YWxpdHkgb2Ygc2VydmljZSBtZWNoYW5pc21z IGFyZSByZXF1aXJlZCB0byBlbnN1cmU6CgogICBvICBTdXBwb3J0IGZvciBkaWZmZXJlbnRp YXRlZCBzZXJ2aWNlcyBhbmQgZGlmZmVyZW50IHRyYWZmaWMgdHlwZXMKICAgICAgd2l0aCB0 cmFmZmljIGNsYXNzIHNlcGFyYXRpb24gYXNzb2NpYXRlZCB3aXRoIGRpZmZlcmVudCB0cmFm ZmljLgoKICAgbyAgUHJpb3JpdGl6YXRpb24gb2YgY3JpdGljYWwgc2VydmljZXMuCgogICBv ICBFbmFibGluZyB0aGUgcHJvdmlzaW9uaW5nIGFuZCB0aGUgZ3VhcmFudGVlIG9mIFNlcnZp Y2UgTGV2ZWwKICAgICAgU3BlY2lmaWNhdGlvbnMgKFNMUyksIHdpdGggc3VwcG9ydCBmb3Ig aGFyZCBhbmQgcmVsYXRpdmUgZW5kLXRvLQogICAgICBlbmQgQlcgZ3VhcmFudGVlZC4KCiAg IG8gIENvbnRyb2xsZWQgaml0dGVyIGFuZCBkZWxheS4KCiAgIG8gIEd1YXJhbnRlZSBvZiBm YWlyIGFjY2VzcyB0byBzaGFyZWQgcmVzb3VyY2VzIGluIGFuIE1QTFMtVFAKICAgICAgbmV0 d29yay4KCgoKCgpOaXZlbi1KZW5raW5zLCBldCBhbC4gICAgRXhwaXJlcyBKYW51YXJ5IDIs IDIwMDkgICAgICAgICAgICAgICBbUGFnZSAxNF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgIE1QTFMtVFAgUmVxdWlyZW1lbnRzICAgICAgICAgICAgICAgICBKdWx5IDIwMDgKCgog ICBvICBBYmlsaXR5IGZvciBPQU0gYW5kIGRhdGEgdG8gc2hhcmUgdGhlIHNhbWUgZmF0ZS4K CiAgIG8gIFJlc291cmNlcyBmb3IgY29udHJvbCBhbmQgbWFuYWdlbWVudCBwbGFuZSBwYWNr ZXRzIHNvIHRoYXQgdXNlcgogICAgICBwbGFuZSB0cmFmZmljLCByZWdhcmRsZXNzIG9mIHRo ZSBhbW91bnQsIHdpbGwgbm90IGNhdXNlIGNvbnRyb2wKICAgICAgYW5kIG1hbmFnZW1lbnQg ZnVuY3Rpb25zIHRvIGJlY29tZSBpbm9wZXJhdGl2ZS4KCiAgIFRoZSBmb2xsb3dpbmcgUW9T IHJlcXVpcmVtZW50cyBhcHBseSB0byBNUExTLVRQOgoKICAgbyAgTVBMUy1UUCBNVVNUIGJl IGFibGUgdG8gZGVsaXZlciB0aGUgc2FtZSBkZWdyZWUgb2YgUW9TIHRoYXQgaGFzCiAgICAg IGJlZW4gZGVsaXZlcmVkIGJ5IFNESC9TT05FVCBzeXN0ZW1zLgoKICAgbyAgTVBMUy1UUCBN VVNUIHN1cHBvcnQgdHJhbnNwb3J0IGJhbmR3aWR0aCBhbGxvY2F0aW9uIHRvIGFueQogICAg ICBncmFudWxhcml0eSB3aXRob3V0IGFueSByZXN0cmljdGlvbnMgYmFzZWQgb24gYSBjaXJj dWl0LXN3aXRjaGVkCiAgICAgIG11bHRpcGxleGluZyBoaWVyYXJjaHkuICBUaGlzIGF0dHJp YnV0ZSB3aWxsIHByb3ZpZGUgc2VydmljZQogICAgICBwcm92aWRlcnMgd2l0aCB0aGUgY2Fw YWJpbGl0eSB0byByb3V0ZSBtb3JlIGN1c3RvbWVyIHNlcnZpY2UKICAgICAgZGVtYW5kcyBv dmVyIHRoZSBNUExTLVRQIG5ldHdvcmsuCgogICBbU2hvdWxkIHdlIHJlZmVyIGhlcmUgdG8g dGhlIHJlcXVpcmVtZW50cyBzcGVjaWZpZWQgaW4gUkZDIDI3MDI/XQoKMi4xMC4gIFNlY3Vy aXR5IHJlcXVpcmVtZW50cwoKICAgbyAgTVBMUy1UUCBNVVNUIGVuc3VyZSB0aGF0IHRoZSBu ZXR3b3JrIGFuZCBzZXJ2aWNlcyBhcmUgc2VjdXJlZC4KCiAgIG8gIFRyYWZmaWMgZmxvd3Mg ZnJvbSBkaWZmZXJlbnQgdXNlcnMgTVVTVCBOT1QgYmUgaW50ZXJtaW5nbGVkLCBidXQKICAg ICAgaWYgdGhpcyBkb2VzIG9jY3VyIHRoZW4gdGhpcyBNVVNUIGJlIGRldGVjdGFibGUgYW5k IHRoZQogICAgICBhcHByb3ByaWF0ZSBjb25zZXF1ZW50IGFjdGlvbnMgdGFrZW4uCgogICBv ICBNUExTLVRQIE1VU1QgZW5zdXJlIHRoZSBzZXBhcmF0aW9uIG9mIGN1c3RvbWVyIChjbGll bnQpIGFuZAogICAgICBwcm92aWRlciAoc2VydmVyIGFuZCBwZWVyIG5ldHdvcmspIGFkZHJl c3NpbmcgYW5kIG90aGVyCiAgICAgIGluZm9ybWF0aW9uLgoKICAgbyAgTVBMUy1UUCBNVVNU IGVuc3VyZSB0aGF0IHRoZSBjb250cm9sIGFuZCBtYW5hZ2VtZW50IHBsYW5lcyBhcyB3ZWxs CiAgICAgIGFzIE9BTSB0cmFmZmljIGFyZSBzZWN1cmUgZnJvbSBleHRlcm5hbCBhdHRhY2su CgogICBvICBNUExTLVRQIE1VU1QgcHJvdmlkZSBtZWNoYW5pc21zIHRvIGVuc3VyZSB0aGF0 IHRoZSBNUExTLVRQIG5ldHdvcmsKICAgICAgcmVtYWlucyBzZWN1cmUgYW5kIHN0YWJsZSB1 bmRlciBzaXR1YXRpb25zIG9mIGV4dHJlbWUgc3RyZXNzLgoKICAgRXhhbXBsZXMgb2YgYXR0 YWNrcyBhbmQgc2l0dWF0aW9ucyBvZiBleHRyZW1lIHN0cmVzcyBpbmNsdWRlIChidXQgYXJl CiAgIG5vdCBsaW1pdGVkIHRvKSBjbGFzc2ljYWwgc2VjdXJpdHkgYXR0YWNrcyAoZS5nLiwg aGlqYWNraW5nLCBwcml2YWN5LAogICBub24tcmVwdWRpYXRpb24sIGV0Yy4pIGFuZCBhdHRh Y2tzIG9uIG5ldHdvcmsgYXZhaWxhYmlsaXR5IChlLmcuLAogICBkZW5pYWwgb2Ygc2Vydmlj ZSAoRG9TKSBhdHRhY2tzKS4KCgozLiAgSUFOQSBDb25zaWRlcmF0aW9ucwoKICAgVGhpcyBk b2N1bWVudCBtYWtlcyBubyByZXF1ZXN0IG9mIElBTkEuCgogICBOb3RlIHRvIFJGQyBFZGl0 b3I6IHRoaXMgc2VjdGlvbiBtYXkgYmUgcmVtb3ZlZCBvbiBwdWJsaWNhdGlvbiBhcyBhbgoK CgpOaXZlbi1KZW5raW5zLCBldCBhbC4gICAgRXhwaXJlcyBKYW51YXJ5IDIsIDIwMDkgICAg ICAgICAgICAgICBbUGFnZSAxNV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIE1QTFMt VFAgUmVxdWlyZW1lbnRzICAgICAgICAgICAgICAgICBKdWx5IDIwMDgKCgogICBSRkMuCgoK NC4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zCgogICBUaGlzIGRvY3VtZW50IGRvZXMgbm90 IGJ5IGl0c2VsZiByYWlzZSBhbnkgcGFydGljdWxhciBzZWN1cml0eQogICBjb25zaWRlcmF0 aW9ucy4KCgo1LiAgQWNrbm93bGVkZ2VtZW50cwoKICAgVGhlIGF1dGhvcnMgd2lzaCB0byB0 aGFuayBOZWlsIEhhcnJpc29uIGFuZCBUb21vbm9yaSBUYWtlZGEgZm9yIHRoZWlyCiAgIHJl dmlldyBhbmQgZW5oYW5jZW1lbnRzIHRvIHRoZSB0ZXh0LgoKCjYuICBJbmZvcm1hdGl2ZSBS ZWZlcmVuY2VzCgogICBbUkZDMjExOV0gIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1 c2UgaW4gUkZDcyB0byBJbmRpY2F0ZQogICAgICAgICAgICAgIFJlcXVpcmVtZW50IExldmVs cyIsIEJDUCAxNCwgUkZDIDIxMTksIE1hcmNoIDE5OTcuCgogICBbUkZDNDQyN10gIE1hbm5p ZSwgRS4gYW5kIEQuIFBhcGFkaW1pdHJpb3UsICJSZWNvdmVyeSAoUHJvdGVjdGlvbiBhbmQK ICAgICAgICAgICAgICBSZXN0b3JhdGlvbikgVGVybWlub2xvZ3kgZm9yIEdlbmVyYWxpemVk IE11bHRpLVByb3RvY29sCiAgICAgICAgICAgICAgTGFiZWwgU3dpdGNoaW5nIChHTVBMUyki LCBSRkMgNDQyNywgTWFyY2ggMjAwNi4KCiAgIFtJVFUuWTE0MDEuMjAwOF0KICAgICAgICAg ICAgICBJbnRlcm5hdGlvbmFsIFRlbGVjb21tdW5pY2F0aW9ucyBVbmlvbiwgIlByaW5jaXBs ZXMgb2YKICAgICAgICAgICAgICBpbnRlcndvcmtpbmciLCBJVFUtVCBSZWNvbW1lbmRhdGlv biBZLjE0MDEsIEZlYnJ1YXJ5IDIwMDguCgoKQXV0aG9ycycgQWRkcmVzc2VzCgogICBCZW4g Tml2ZW4tSmVua2lucyAoZWRpdG9yKQogICBCVAogICAyMDggQ2FsbGlzdG8gSG91c2UsIEFk YXN0cmFsIFBhcmsKICAgSXBzd2ljaCwgU3VmZm9sayAgSVA1IDNSRQogICBVSwoKICAgRW1h aWw6IGJlbmphbWluLm5pdmVuLWplbmtpbnNAYnQuY29tCgoKICAgRGVib3JhaCBCcnVuZ2Fy ZCAoZWRpdG9yKQogICBBVCZUCiAgIFJtLiBEMS0zQzIyIC0gMjAwIFMuIExhdXJlbCBBdmUu CiAgIE1pZGRsZXRvd24sIE5KICAwNzc0OAogICBVU0EKCiAgIEVtYWlsOiBkYnJ1bmdhcmRA YXR0LmNvbQoKCgoKTml2ZW4tSmVua2lucywgZXQgYWwuICAgIEV4cGlyZXMgSmFudWFyeSAy LCAyMDA5ICAgICAgICAgICAgICAgW1BhZ2UgMTZdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgICBNUExTLVRQIFJlcXVpcmVtZW50cyAgICAgICAgICAgICAgICAgSnVseSAyMDA4CgoK ICAgTWFsY29sbSBCZXR0cyAoZWRpdG9yKQogICBOb3J0ZWwgTmV0d29ya3MKICAgMzUwMCBD YXJsaW5nIEF2ZW51ZQogICBPdHRhd2EsIE9udGFyaW8gIEsySCA4RTkKICAgQ2FuYWRhCgog ICBFbWFpbDogYmV0dHMwMUBub3J0ZWwuY29tCgoKICAgTnVyaXQgU3ByZWNoZXIKICAgTm9r aWEgU2llbWVucyBOZXR3b3JrcwogICAzIEhhbmFnYXIgU3QuIE5ldmUgTmUnZW1hbiBCCiAg IEhvZCBIYXNoYXJvbiwgICA0NTI0MQogICBJc3JhZWwKCiAgIEVtYWlsOiBudXJpdC5zcHJl Y2hlckBuc24uY29tCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKTml2ZW4t SmVua2lucywgZXQgYWwuICAgIEV4cGlyZXMgSmFudWFyeSAyLCAyMDA5ICAgICAgICAgICAg ICAgW1BhZ2UgMTddCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICBNUExTLVRQIFJlcXVp cmVtZW50cyAgICAgICAgICAgICAgICAgSnVseSAyMDA4CgoKRnVsbCBDb3B5cmlnaHQgU3Rh dGVtZW50CgogICBDb3B5cmlnaHQgKEMpIFRoZSBJRVRGIFRydXN0ICgyMDA4KS4KCiAgIFRo aXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byB0aGUgcmlnaHRzLCBsaWNlbnNlcyBhbmQgcmVz dHJpY3Rpb25zCiAgIGNvbnRhaW5lZCBpbiBCQ1AgNzgsIGFuZCBleGNlcHQgYXMgc2V0IGZv cnRoIHRoZXJlaW4sIHRoZSBhdXRob3JzCiAgIHJldGFpbiBhbGwgdGhlaXIgcmlnaHRzLgoK ICAgVGhpcyBkb2N1bWVudCBhbmQgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4g YXJlIHByb3ZpZGVkIG9uIGFuCiAgICJBUyBJUyIgYmFzaXMgYW5kIFRIRSBDT05UUklCVVRP UiwgVEhFIE9SR0FOSVpBVElPTiBIRS9TSEUgUkVQUkVTRU5UUwogICBPUiBJUyBTUE9OU09S RUQgQlkgKElGIEFOWSksIFRIRSBJTlRFUk5FVCBTT0NJRVRZLCBUSEUgSUVURiBUUlVTVCBB TkQKICAgVEhFIElOVEVSTkVUIEVOR0lORUVS SU5HIFRBU0sgRk9SQ0UgRElTQ0xBSU0gQUxM IFdBUlJBTlRJRVMsIEVYUFJFU1MKICAgT1IgSU1QTElFRCwgSU5DTFVESU5HIEJVVCBOT1Qg TElNSVRFRCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9GCiAgIFRIRSBJTkZPUk1B VElPTiBIRVJFSU4gV0lMTCBOT1QgSU5GUklOR0UgQU5ZIFJJR0hUUyBPUiBBTlkgSU1QTElF RAogICBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBPUiBGSVRORVNTIEZPUiBBIFBB UlRJQ1VMQVIgUFVSUE9TRS4KCgpJbnRlbGxlY3R1YWwgUHJvcGVydHkKCiAgIFRoZSBJRVRG IHRha2VzIG5vIHBvc2l0aW9uIHJlZ2FyZGluZyB0aGUgdmFsaWRpdHkgb3Igc2NvcGUgb2Yg YW55CiAgIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBSaWdodHMgb3Igb3RoZXIgcmlnaHRzIHRo YXQgbWlnaHQgYmUgY2xhaW1lZCB0bwogICBwZXJ0YWluIHRvIHRoZSBpbXBsZW1lbnRhdGlv biBvciB1c2Ugb2YgdGhlIHRlY2hub2xvZ3kgZGVzY3JpYmVkIGluCiAgIHRoaXMgZG9jdW1l bnQgb3IgdGhlIGV4dGVudCB0byB3aGljaCBhbnkgbGljZW5zZSB1bmRlciBzdWNoIHJpZ2h0 cwogICBtaWdodCBvciBtaWdodCBub3QgYmUgYXZhaWxhYmxlOyBub3IgZG9lcyBpdCByZXBy ZXNlbnQgdGhhdCBpdCBoYXMKICAgbWFkZSBhbnkgaW5kZXBlbmRlbnQgZWZmb3J0IHRvIGlk ZW50aWZ5IGFueSBzdWNoIHJpZ2h0cy4gIEluZm9ybWF0aW9uCiAgIG9uIHRoZSBwcm9jZWR1 cmVzIHdpdGggcmVzcGVjdCB0byByaWdodHMgaW4gUkZDIGRvY3VtZW50cyBjYW4gYmUKICAg Zm91bmQgaW4gQkNQIDc4IGFuZCBCQ1AgNzkuCgogICBDb3BpZXMgb2YgSVBSIGRpc2Nsb3N1 cmVzIG1hZGUgdG8gdGhlIElFVEYgU2VjcmV0YXJpYXQgYW5kIGFueQogICBhc3N1cmFuY2Vz IG9mIGxpY2Vuc2VzIHRvIGJlIG1hZGUgYXZhaWxhYmxlLCBvciB0aGUgcmVzdWx0IG9mIGFu CiAgIGF0dGVtcHQgbWFkZSB0byBvYnRhaW4gYSBnZW5lcmFsIGxpY2Vuc2Ugb3IgcGVybWlz c2lvbiBmb3IgdGhlIHVzZSBvZgogICBzdWNoIHByb3ByaWV0YXJ5IHJpZ2h0cyBieSBpbXBs ZW1lbnRlcnMgb3IgdXNlcnMgb2YgdGhpcwogICBzcGVjaWZpY2F0aW9uIGNhbiBiZSBvYnRh aW5lZCBmcm9tIHRoZSBJRVRGIG9uLWxpbmUgSVBSIHJlcG9zaXRvcnkgYXQKICAgaHR0cDov L3d3dy5pZXRmLm9yZy9pcHIuCgogICBUaGUgSUVURiBpbnZpdGVzIGFueSBpbnRlcmVzdGVk IHBhcnR5IHRvIGJyaW5nIHRvIGl0cyBhdHRlbnRpb24gYW55CiAgIGNvcHlyaWdodHMsIHBh dGVudHMgb3IgcGF0ZW50IGFwcGxpY2F0aW9ucywgb3Igb3RoZXIgcHJvcHJpZXRhcnkKICAg cmlnaHRzIHRoYXQgbWF5IGNvdmVyIHRlY2hub2xvZ3kgdGhhdCBtYXkgYmUgcmVxdWlyZWQg dG8gaW1wbGVtZW50CiAgIHRoaXMgc3RhbmRhcmQuICBQbGVhc2UgYWRkcmVzcyB0aGUgaW5m b3JtYXRpb24gdG8gdGhlIElFVEYgYXQKICAgaWV0Zi1pcHJAaWV0Zi5vcmcuCgoKCgoKCgoK CgoKTml2ZW4tSmVua2lucywgZXQgYWwuICAgIEV4cGlyZXMgSmFudWFyeSAyLCAyMDA5ICAg ICAgICAgICAgICAgW1BhZ2UgMThdCgwKCg== --B_3296744455_4187096 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop --B_3296744455_4187096-- From mpls-interop-bounces@ietf.org Thu Jun 19 11:10:34 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C0033A67A5; Thu, 19 Jun 2008 11:10:34 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C08373A6817 for ; Thu, 19 Jun 2008 11:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.967 X-Spam-Level: X-Spam-Status: No, score=-105.967 tagged_above=-999 required=5 tests=[AWL=0.632, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EruRRbJAP1N7 for ; Thu, 19 Jun 2008 11:10:31 -0700 (PDT) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.245.115]) by core3.amsl.com (Postfix) with ESMTP id 327373A67A5 for ; Thu, 19 Jun 2008 11:10:31 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-10.tower-121.messagelabs.com!1213899080!21802984!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 23418 invoked from network); 19 Jun 2008 18:11:20 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-10.tower-121.messagelabs.com with AES256-SHA encrypted SMTP; 19 Jun 2008 18:11:20 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m5JIBKLu012546 for ; Thu, 19 Jun 2008 14:11:20 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m5JIBC4a012374 for ; Thu, 19 Jun 2008 14:11:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 19 Jun 2008 14:11:11 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mpls-interop] next MEAD team meeting Thread-Index: AcjSMNQsx4BuurjX8EeQxIcfmO8exAABA9GA References: <485A7485.9090205@pi.nu> From: "BRUNGARD, DEBORAH A, ATTLABS" To: "MEAD team" Subject: Re: [Mpls-interop] next MEAD team meeting X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org Colleagues, I was thinking for the requirements we should include a sentence in the abstract to scope the MPLS-TP work as being part of a joint ITU-IETF effort. Not all readers (now and future) will be aware of why this is being done. In ccamp, we had done this for our ASON work. Maybe a similar sentence will be needed in the other documents? Should we have a common sentence? How about for the abstract: This document summarizes the ITU-T requirements for MPLS-TP in order to support capabilities and functionalities as needed by the ITU-T. It does not address IETF protocol applicability or capabilities. This document is a product of a joint ITU-IETF effort. Deborah -----Original Message----- From: mpls-interop-bounces@ietf.org [mailto:mpls-interop-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins Sent: Thursday, June 19, 2008 1:21 PM To: Loa Andersson; MEAD team Subject: Re: [Mpls-interop] next MEAD team meeting Colleagues, FYI see attached for the latest draft of the MPLS-TP requirements draft. Ben On 19/06/2008 16:00, "Loa Andersson" wrote: > All, > > the MEAD team will have the next meeting on Tuesday 24, at 6pm > i.e. 12am east coast and 9am California. > > Again I plan the meeting to last an hour, and focus will be on the > document status. > > Stewart will send out dial in details as usual. > > /Loa _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop From mpls-interop-bounces@ietf.org Thu Jun 19 12:09:53 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 743683A67D0; Thu, 19 Jun 2008 12:09:53 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9708128C0CE for ; Thu, 19 Jun 2008 12:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abWt2AK6apif for ; Thu, 19 Jun 2008 12:09:51 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id D3E843A6909 for ; Thu, 19 Jun 2008 12:09:47 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m5JJ9gCI021143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jun 2008 21:09:42 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m5JJ9gph016812; Thu, 19 Jun 2008 21:09:42 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Jun 2008 21:09:42 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 19 Jun 2008 21:09:41 +0200 Message-ID: <9FF5BDAD88B9D84881609E89AC92FB83EBD0FC@DEMUEXC014.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mpls-interop] next MEAD team meeting Thread-Index: AcjSMNQsx4BuurjX8EeQxIcfmO8exAABA9GAAAFOJGA= From: "Sprecher, Nurit (NSN - IL/Israel - MiniMD)" To: "ext BRUNGARD, DEBORAH A, ATTLABS" , "MEAD team" X-OriginalArrivalTime: 19 Jun 2008 19:09:42.0088 (UTC) FILETIME=[07378C80:01C8D240] Subject: Re: [Mpls-interop] next MEAD team meeting X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0238110080==" Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org This is a multi-part message in MIME format. --===============0238110080== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8D240.070FF525" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8D240.070FF525 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Deborah, I have a few comments regarding the proposed abstract: * I think we should say "This document specifies the requirements for MPLS-TP in order to support capabilities and functionalities as needed in transport environments (or networks). * I do not understand the sentence: It does not address IETF protocol applicability or capabilities. Do you mean applicability or capability of the current IETF documents? As IMO it will be of the documents we generate for MPLS-TP.=20 * I think it is important to indicate that " This document is a product of a joint ITU-IETF effort". Best regards, Nurit =20 -----Original Message----- From: mpls-interop-bounces@ietf.org [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext BRUNGARD, DEBORAH A, ATTLABS Sent: Thursday, June 19, 2008 21:11 To: MEAD team Subject: Re: [Mpls-interop] next MEAD team meeting =20 Colleagues, =20 I was thinking for the requirements we should include a sentence in the abstract to scope the MPLS-TP work as being part of a joint ITU-IETF effort. Not all readers (now and future) will be aware of why this is being done. In ccamp, we had done this for our ASON work. Maybe a similar sentence will be needed in the other documents? Should we have a common sentence? =20 How about for the abstract: This document summarizes the ITU-T requirements for MPLS-TP in order to support capabilities and functionalities as needed by the ITU-T. It does not address IETF protocol applicability or capabilities. This document is a product of a joint ITU-IETF effort. =20 Deborah =20 =20 -----Original Message----- From: mpls-interop-bounces@ietf.org [mailto:mpls-interop-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins Sent: Thursday, June 19, 2008 1:21 PM To: Loa Andersson; MEAD team Subject: Re: [Mpls-interop] next MEAD team meeting =20 Colleagues, =20 FYI see attached for the latest draft of the MPLS-TP requirements draft. =20 Ben =20 =20 =20 On 19/06/2008 16:00, "Loa Andersson" wrote: =20 > All, >=20 > the MEAD team will have the next meeting on Tuesday 24, at 6pm > i.e. 12am east coast and 9am California. >=20 > Again I plan the meeting to last an hour, and focus will be on the > document status. >=20 > Stewart will send out dial in details as usual. >=20 > /Loa =20 _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop ------_=_NextPart_001_01C8D240.070FF525 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Deborah,

I have a few comments regarding the proposed = abstract:

·         I think we = should say "This document specifies the requirements for MPLS-TP in order to = support capabilities and functionalities as needed in transport environments (or networks).

·         I do not = understand the sentence: It does not address IETF protocol applicability or = capabilities. Do you mean applicability or capability of the current IETF documents? As = IMO it will be of the documents we generate for MPLS-TP.

·         I think it = is important to indicate that " This document is a product of a joint ITU-IETF effort".

Best regards,

Nurit

 

-----Original Message-----
From: mpls-interop-bounces@ietf.org = [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext BRUNGARD, DEBORAH A, ATTLABS
Sent: Thursday, June 19, 2008 21:11
To: MEAD team
Subject: Re: [Mpls-interop] next MEAD team meeting

 

Colleagues,

 

I was thinking for the requirements we should = include a sentence in the

abstract to scope the MPLS-TP work as being = part of a joint ITU-IETF

effort. Not all readers (now and future) will = be aware of why this is

being done. In ccamp, we had done this for = our ASON work. Maybe a

similar sentence will be needed in the other documents? Should we have a

common sentence?

 

How about for the = abstract:

This document summarizes the ITU-T = requirements for MPLS-TP in order to

support capabilities and functionalities as = needed by the ITU-T. It does

not address IETF protocol applicability or capabilities. This document

is a product of a joint ITU-IETF = effort.

 

Deborah 

 

-----Original = Message-----

From: = mpls-interop-bounces@ietf.org

[mailto:mpls-interop-bounces@ietf.org] On = Behalf Of Ben Niven-Jenkins

Sent: Thursday, June 19, 2008 1:21 = PM

To: Loa Andersson; MEAD = team

Subject: Re: [Mpls-interop] next MEAD team = meeting

 

Colleagues,

 

FYI see attached for the latest draft of the = MPLS-TP requirements draft.

 

Ben

 

 

 

On 19/06/2008 16:00, "Loa = Andersson" <loa@pi.nu> wrote:

 

> All,

>

> the MEAD team will have the next meeting = on Tuesday 24, at 6pm

> i.e. 12am east coast and 9am California.<= /p>

>

> Again I plan the meeting to last an = hour, and focus will be on the

> document = status.

>

> Stewart will send out dial in details as = usual.

>

> /Loa

 

______________________________________________= _

Mpls-interop mailing = list

Mpls-interop@ietf.org=

https://www.ietf.org/mailman/listinfo/mpls-int= erop

------_=_NextPart_001_01C8D240.070FF525-- --===============0238110080== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop --===============0238110080==-- From mpls-interop-bounces@ietf.org Thu Jun 19 13:04:23 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A76E3A6832; Thu, 19 Jun 2008 13:04:23 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 679193A6832 for ; Thu, 19 Jun 2008 13:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.999 X-Spam-Level: X-Spam-Status: No, score=-103.999 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGuRmaulTVpE for ; Thu, 19 Jun 2008 13:04:20 -0700 (PDT) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.245.3]) by core3.amsl.com (Postfix) with ESMTP id AC2EA3A6992 for ; Thu, 19 Jun 2008 13:04:19 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-3.tower-146.messagelabs.com!1213905856!3495411!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 8668 invoked from network); 19 Jun 2008 20:04:16 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-3.tower-146.messagelabs.com with AES256-SHA encrypted SMTP; 19 Jun 2008 20:04:16 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m5JK4FRQ002975 for ; Thu, 19 Jun 2008 16:04:16 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m5JK48lF002889 for ; Thu, 19 Jun 2008 16:04:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 19 Jun 2008 16:04:08 -0400 Message-ID: In-Reply-To: <9FF5BDAD88B9D84881609E89AC92FB83EBD0FC@DEMUEXC014.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mpls-interop] next MEAD team meeting Thread-Index: AcjSMNQsx4BuurjX8EeQxIcfmO8exAABA9GAAAFOJGAAAq68cA== References: <9FF5BDAD88B9D84881609E89AC92FB83EBD0FC@DEMUEXC014.nsn-intra.net> From: "BRUNGARD, DEBORAH A, ATTLABS" To: "Sprecher, Nurit (NSN - IL/Israel - MiniMD)" , "MEAD team" Subject: Re: [Mpls-interop] next MEAD team meeting X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0397817701==" Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org This is a multi-part message in MIME format. --===============0397817701== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8D247.A263434B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8D247.A263434B Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Nurit, =20 I would prefer to clearly say the requirements are ITU requirements for MPLS in a transport environment. I think among some operators the line between transport equipment and packet equipment has already blurred. For many operators, the preference may be to align with MPLS operations vs. transport. I think there are many differing opinions on what MPLS/packet transport needs to support in a transport environment. So I prefer to clearly say these are ITU requirements, they do not necessarily reflect the operators contributing to this document. =20 On the 2nd bullet, the requirements document has many statements/requirements which may be interpreted by a reader as gaps in MPLS/IETF protocols. I was trying to say with this sentence the document is not addressing/identifying IETF protocol applicability or lack of capabilities e.g. the sentence: "Quality-of-service mechanisms are required in the packet transport network to ensure the prioritization of critical services, to guarantee BW and to control jitter and delay." QoS is not a new requirement for IETF protocols. Packet transport networks (and this requirement document) are not the first time that QoS mechanisms are identified as needed. This requirement is not intending to identify a gap in the current IETF protocol set. This was what I was trying to say. =20 Suggestions? Deborah =20 =20 ________________________________ From: Sprecher, Nurit (NSN - IL/Israel - MiniMD) [mailto:nurit.sprecher@nsn.com]=20 Sent: Thursday, June 19, 2008 3:10 PM To: BRUNGARD, DEBORAH A, ATTLABS; MEAD team Cc: Sprecher, Nurit (NSN - IL/Israel - MiniMD) Subject: RE: [Mpls-interop] next MEAD team meeting Hi Deborah, I have a few comments regarding the proposed abstract: * I think we should say "This document specifies the requirements for MPLS-TP in order to support capabilities and functionalities as needed in transport environments (or networks). * I do not understand the sentence: It does not address IETF protocol applicability or capabilities. Do you mean applicability or capability of the current IETF documents? As IMO it will be of the documents we generate for MPLS-TP.=20 * I think it is important to indicate that " This document is a product of a joint ITU-IETF effort". Best regards, Nurit =20 -----Original Message----- From: mpls-interop-bounces@ietf.org [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext BRUNGARD, DEBORAH A, ATTLABS Sent: Thursday, June 19, 2008 21:11 To: MEAD team Subject: Re: [Mpls-interop] next MEAD team meeting =20 Colleagues, =20 I was thinking for the requirements we should include a sentence in the abstract to scope the MPLS-TP work as being part of a joint ITU-IETF effort. Not all readers (now and future) will be aware of why this is being done. In ccamp, we had done this for our ASON work. Maybe a similar sentence will be needed in the other documents? Should we have a common sentence? =20 How about for the abstract: This document summarizes the ITU-T requirements for MPLS-TP in order to support capabilities and functionalities as needed by the ITU-T. It does not address IETF protocol applicability or capabilities. This document is a product of a joint ITU-IETF effort. =20 Deborah =20 =20 -----Original Message----- From: mpls-interop-bounces@ietf.org [mailto:mpls-interop-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins Sent: Thursday, June 19, 2008 1:21 PM To: Loa Andersson; MEAD team Subject: Re: [Mpls-interop] next MEAD team meeting =20 Colleagues, =20 FYI see attached for the latest draft of the MPLS-TP requirements draft. =20 Ben =20 =20 =20 On 19/06/2008 16:00, "Loa Andersson" wrote: =20 > All, >=20 > the MEAD team will have the next meeting on Tuesday 24, at 6pm > i.e. 12am east coast and 9am California. >=20 > Again I plan the meeting to last an hour, and focus will be on the > document status. >=20 > Stewart will send out dial in details as usual. >=20 > /Loa =20 _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop ------_=_NextPart_001_01C8D247.A263434B Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi Nurit,
 
I would prefer to clearly say the requirements = are ITU=20 requirements for MPLS in a transport environment. I think = among some=20 operators the line between transport equipment and packet equipment has = already=20 blurred. For many operators, the preference may be to align = with MPLS=20 operations vs. transport. I think there are many differing = opinions on=20 what MPLS/packet transport needs to support in a transport=20 environment. So I prefer to clearly say these are ITU=20 requirements, they do not necessarily reflect the operators contributing = to this=20 document.
 
On the 2nd bullet,  the requirements document has many=20 statements/requirements which may be interpreted by a reader as = gaps in=20 MPLS/IETF protocols. I was trying to say with this sentence the = document is=20 not addressing/identifying IETF protocol applicability or lack of=20 capabilities e.g. the sentence:
"Quality-of-service mechanisms are required in the packet=20 transport
   network to ensure the prioritization of = critical=20 services, to
   guarantee BW and to control jitter and=20 delay."

QoS is not a new requirement = for IETF=20 protocols. Packet transport networks (and this requirement = document) are=20 not the first time that QoS mechanisms are identified as = needed. This=20 requirement is not intending to identify a gap in the current = IETF=20 protocol set. This was what I was trying to=20 say.
 
Suggestions?
Deborah
 
 

From: Sprecher, Nurit (NSN - = IL/Israel - MiniMD)=20 [mailto:nurit.sprecher@nsn.com]
Sent: Thursday, June 19, 2008 = 3:10=20 PM
To: BRUNGARD, DEBORAH A, ATTLABS; MEAD team
Cc: = Sprecher,=20 Nurit (NSN - IL/Israel - MiniMD)
Subject: RE: [Mpls-interop] = next MEAD=20 team meeting

Hi Deborah,

I have a few comments regarding the proposed=20 abstract:

·        =20 I think we = should say=20 "This document specifies the requirements for MPLS-TP in order to = support=20 capabilities and functionalities as needed in transport environments (or = networks).

·        =20 I do not = understand=20 the sentence: It does not address IETF protocol applicability or = capabilities.=20 Do you mean applicability or capability of the current IETF documents? = As IMO it=20 will be of the documents we generate for MPLS-TP.

·        =20 I think it = is=20 important to indicate that " This document is a product of a joint = ITU-IETF=20 effort".

Best regards,

Nurit

 

-----Original Message-----
From:=20 mpls-interop-bounces@ietf.org [mailto:mpls-interop-bounces@ietf.org] On = Behalf=20 Of ext BRUNGARD, DEBORAH A, ATTLABS
Sent: Thursday, June 19, 2008=20 21:11
To: MEAD team
Subject: Re: [Mpls-interop] next MEAD team=20 meeting

 

Colleagues,

 

I was thinking for the requirements we should = include a=20 sentence in the

abstract to scope the MPLS-TP work as being = part of a=20 joint ITU-IETF

effort. Not all readers (now and future) will = be aware=20 of why this is

being done. In ccamp, we had done this for our = ASON=20 work. Maybe a

similar sentence will be needed in the other = documents?=20 Should we have a

common sentence?

 

How about for the = abstract:

This document summarizes the ITU-T = requirements for=20 MPLS-TP in order to

support capabilities and functionalities as = needed by=20 the ITU-T. It does

not address IETF protocol applicability or = capabilities.=20 This document

is a product of a joint ITU-IETF=20 effort.

 

Deborah 

 

-----Original = Message-----

From:=20 mpls-interop-bounces@ietf.org

[mailto:mpls-interop-bounces@ietf.org] On = Behalf Of Ben=20 Niven-Jenkins

Sent: Thursday, June 19, 2008 1:21=20 PM

To: Loa Andersson; MEAD=20 team

Subject: Re: [Mpls-interop] next MEAD team=20 meeting

 

Colleagues,

 

FYI see attached for the latest draft of the = MPLS-TP=20 requirements draft.

 

Ben

 

 

 

On 19/06/2008 16:00, "Loa Andersson" = <loa@pi.nu>=20 wrote:

 

> All,

>

> the MEAD team will have the next meeting = on Tuesday=20 24, at 6pm

> i.e. 12am east coast and 9am California.<= /P>

>

> Again I plan the meeting to last an hour, = and focus=20 will be on the

> document = status.

>

> Stewart will send out dial in details as=20 usual.

>

> /Loa

 

_______________________________________________

Mpls-interop mailing = list

Mpls-interop@ietf.org

https://www.ietf.org/mailman/listinfo/mpls-interop

------_=_NextPart_001_01C8D247.A263434B-- --===============0397817701== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop --===============0397817701==-- From mpls-interop-bounces@ietf.org Thu Jun 19 14:57:51 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CA1728C117; Thu, 19 Jun 2008 14:57:51 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBC0628C119 for ; Thu, 19 Jun 2008 14:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZU+QyDfBVaD for ; Thu, 19 Jun 2008 14:57:50 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id 2EDB328C117 for ; Thu, 19 Jun 2008 14:57:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 8E3A9CF98C6 for ; Thu, 19 Jun 2008 14:57:49 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01337-07 for ; Thu, 19 Jun 2008 14:57:49 -0700 (PDT) Received: from rbsjx.ad.redback.com (rbsjxh1.redback.com [155.53.14.105]) by prattle.redback.com (Postfix) with ESMTP id 77634CF98C5 for ; Thu, 19 Jun 2008 14:57:49 -0700 (PDT) Received: from RBSJX.ad.redback.com ([155.53.14.103]) by rbsjxh1.ad.redback.com ([155.53.14.105]) with mapi; Thu, 19 Jun 2008 14:57:49 -0700 From: David Sinicrope To: "mpls-interop@ietf.org" Date: Thu, 19 Jun 2008 14:58:07 -0700 Thread-Topic: [Mpls-interop] next MEAD team meeting Thread-Index: AcjSHV+baA3PhWi8SNuu8g8aFnYZOwALczVAAAAmMSAAAvBUQA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at redback.com Subject: Re: [Mpls-interop] next MEAD team meeting X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org Hi All, I'll be chairing a WG meeting at the IP/MPLS Forum in Vancouver at the same time as the call. Could I impose on a volunteer to take notes for this call? Thanks, David -----Original Message----- From: mpls-interop-bounces@ietf.org [mailto:mpls-interop-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Thursday, June 19, 2008 11:00 AM To: MEAD team Subject: [Mpls-interop] next MEAD team meeting All, the MEAD team will have the next meeting on Tuesday 24, at 6pm i.e. 12am east coast and 9am California. Again I plan the meeting to last an hour, and focus will be on the document status. Stewart will send out dial in details as usual. /Loa -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.nu _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop From mpls-interop-bounces@ietf.org Fri Jun 20 01:48:05 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D3EB3A69E1; Fri, 20 Jun 2008 01:48:05 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38D363A69E1 for ; Fri, 20 Jun 2008 01:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9AeQsThwl9H for ; Fri, 20 Jun 2008 01:48:02 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 510EE3A68D0 for ; Fri, 20 Jun 2008 01:48:01 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m5K8lvhx026150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Jun 2008 10:47:57 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m5K8lvuB023451; Fri, 20 Jun 2008 10:47:57 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Jun 2008 10:47:57 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 20 Jun 2008 10:47:52 +0200 Message-ID: <9FF5BDAD88B9D84881609E89AC92FB83EBD1D2@DEMUEXC014.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mpls-interop] next MEAD team meeting Thread-Index: AcjSMNQsx4BuurjX8EeQxIcfmO8exAABA9GAAAFOJGAAAq68cAAac6LA From: "Sprecher, Nurit (NSN - IL/Israel - MiniMD)" To: "ext BRUNGARD, DEBORAH A, ATTLABS" , "MEAD team" X-OriginalArrivalTime: 20 Jun 2008 08:47:57.0426 (UTC) FILETIME=[56519D20:01C8D2B2] Subject: Re: [Mpls-interop] next MEAD team meeting X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0997463917==" Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org This is a multi-part message in MIME format. --===============0997463917== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8D2B2.562D8987" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8D2B2.562D8987 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Deborah, I understand the intention, so how about the following (as we also indicated in the introduction): This document specifies the ITU-T requirements for MPLS-TP in order to support capabilities and functionalities of MPLS as needed in transport environments.=20 MPLS is a maturing packet technology and it is already playing an important role in transport networks and services. However, not all of MPLS's capabilities and mechnisms are needed and/or consistent with transport network operations. This document identifies the required capabilities for MPLS so that it can better fit a transport role. Please advise. Best regards, Nurit ________________________________ From: ext BRUNGARD, DEBORAH A, ATTLABS [mailto:dbrungard@att.com]=20 Sent: Thursday, June 19, 2008 23:04 To: Sprecher, Nurit (NSN - IL/Israel - MiniMD); MEAD team Subject: RE: [Mpls-interop] next MEAD team meeting Hi Nurit, =20 I would prefer to clearly say the requirements are ITU requirements for MPLS in a transport environment. I think among some operators the line between transport equipment and packet equipment has already blurred. For many operators, the preference may be to align with MPLS operations vs. transport. I think there are many differing opinions on what MPLS/packet transport needs to support in a transport environment. So I prefer to clearly say these are ITU requirements, they do not necessarily reflect the operators contributing to this document. =20 On the 2nd bullet, the requirements document has many statements/requirements which may be interpreted by a reader as gaps in MPLS/IETF protocols. I was trying to say with this sentence the document is not addressing/identifying IETF protocol applicability or lack of capabilities e.g. the sentence: "Quality-of-service mechanisms are required in the packet transport network to ensure the prioritization of critical services, to guarantee BW and to control jitter and delay." QoS is not a new requirement for IETF protocols. Packet transport networks (and this requirement document) are not the first time that QoS mechanisms are identified as needed. This requirement is not intending to identify a gap in the current IETF protocol set. This was what I was trying to say. =20 Suggestions? Deborah =20 =20 ________________________________ From: Sprecher, Nurit (NSN - IL/Israel - MiniMD) [mailto:nurit.sprecher@nsn.com]=20 Sent: Thursday, June 19, 2008 3:10 PM To: BRUNGARD, DEBORAH A, ATTLABS; MEAD team Cc: Sprecher, Nurit (NSN - IL/Israel - MiniMD) Subject: RE: [Mpls-interop] next MEAD team meeting Hi Deborah, I have a few comments regarding the proposed abstract: * I think we should say "This document specifies the requirements for MPLS-TP in order to support capabilities and functionalities as needed in transport environments (or networks). * I do not understand the sentence: It does not address IETF protocol applicability or capabilities. Do you mean applicability or capability of the current IETF documents? As IMO it will be of the documents we generate for MPLS-TP.=20 * I think it is important to indicate that " This document is a product of a joint ITU-IETF effort". Best regards, Nurit =20 -----Original Message----- From: mpls-interop-bounces@ietf.org [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext BRUNGARD, DEBORAH A, ATTLABS Sent: Thursday, June 19, 2008 21:11 To: MEAD team Subject: Re: [Mpls-interop] next MEAD team meeting =20 Colleagues, =20 I was thinking for the requirements we should include a sentence in the abstract to scope the MPLS-TP work as being part of a joint ITU-IETF effort. Not all readers (now and future) will be aware of why this is being done. In ccamp, we had done this for our ASON work. Maybe a similar sentence will be needed in the other documents? Should we have a common sentence? =20 How about for the abstract: This document summarizes the ITU-T requirements for MPLS-TP in order to support capabilities and functionalities as needed by the ITU-T. It does not address IETF protocol applicability or capabilities. This document is a product of a joint ITU-IETF effort. =20 Deborah =20 =20 -----Original Message----- From: mpls-interop-bounces@ietf.org [mailto:mpls-interop-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins Sent: Thursday, June 19, 2008 1:21 PM To: Loa Andersson; MEAD team Subject: Re: [Mpls-interop] next MEAD team meeting =20 Colleagues, =20 FYI see attached for the latest draft of the MPLS-TP requirements draft. =20 Ben =20 =20 =20 On 19/06/2008 16:00, "Loa Andersson" wrote: =20 > All, >=20 > the MEAD team will have the next meeting on Tuesday 24, at 6pm > i.e. 12am east coast and 9am California. >=20 > Again I plan the meeting to last an hour, and focus will be on the > document status. >=20 > Stewart will send out dial in details as usual. >=20 > /Loa =20 _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop ------_=_NextPart_001_01C8D2B2.562D8987 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Deborah,
I understand the intention, so how about the = following (as=20 we also indicated in the introduction):
This document specifies = the ITU-T=20 requirements for MPLS-TP in order = to support=20 capabilities and functionalities of MPLS as needed in transport = environments.=20
MPLS is a maturing packet technology and = it is=20 already playing an important role in transport networks and services. = However,=20 not all of MPLS's capabilities and mechnisms are needed and/or = consistent with=20 transport network operations. This document identifies the required = capabilities=20 for MPLS so that it can better fit a transport=20 role.
Please=20 advise.
Best=20 regards,
Nurit

From: ext BRUNGARD, DEBORAH A, = ATTLABS=20 [mailto:dbrungard@att.com]
Sent: Thursday, June 19, 2008=20 23:04
To: Sprecher, Nurit (NSN - IL/Israel - MiniMD); MEAD=20 team
Subject: RE: [Mpls-interop] next MEAD team=20 meeting

Hi Nurit,
 
I would prefer to clearly say the requirements = are ITU=20 requirements for MPLS in a transport environment. I think = among some=20 operators the line between transport equipment and packet equipment has = already=20 blurred. For many operators, the preference may be to align = with MPLS=20 operations vs. transport. I think there are many differing = opinions on=20 what MPLS/packet transport needs to support in a transport=20 environment. So I prefer to clearly say these are ITU=20 requirements, they do not necessarily reflect the operators contributing = to this=20 document.
 
On the 2nd bullet,  the requirements document has many=20 statements/requirements which may be interpreted by a reader as = gaps in=20 MPLS/IETF protocols. I was trying to say with this sentence the = document is=20 not addressing/identifying IETF protocol applicability or lack of=20 capabilities e.g. the sentence:
"Quality-of-service mechanisms are required in the packet=20 transport
   network to ensure the prioritization of = critical=20 services, to
   guarantee BW and to control jitter and=20 delay."

QoS is not a new requirement = for IETF=20 protocols. Packet transport networks (and this requirement = document) are=20 not the first time that QoS mechanisms are identified as = needed. This=20 requirement is not intending to identify a gap in the current = IETF=20 protocol set. This was what I was trying to=20 say.
 
Suggestions?
Deborah
 
 

From: Sprecher, Nurit (NSN - = IL/Israel - MiniMD)=20 [mailto:nurit.sprecher@nsn.com]
Sent: Thursday, June 19, 2008 = 3:10=20 PM
To: BRUNGARD, DEBORAH A, ATTLABS; MEAD team
Cc: = Sprecher,=20 Nurit (NSN - IL/Israel - MiniMD)
Subject: RE: [Mpls-interop] = next MEAD=20 team meeting

Hi Deborah,

I have a few comments regarding the proposed=20 abstract:

·        =20 I think we = should say=20 "This document specifies the requirements for MPLS-TP in order to = support=20 capabilities and functionalities as needed in transport environments (or = networks).

·        =20 I do not = understand=20 the sentence: It does not address IETF protocol applicability or = capabilities.=20 Do you mean applicability or capability of the current IETF documents? = As IMO it=20 will be of the documents we generate for MPLS-TP.

·        =20 I think it = is=20 important to indicate that " This document is a product of a joint = ITU-IETF=20 effort".

Best regards,

Nurit

 

-----Original Message-----
From:=20 mpls-interop-bounces@ietf.org [mailto:mpls-interop-bounces@ietf.org] On = Behalf=20 Of ext BRUNGARD, DEBORAH A, ATTLABS
Sent: Thursday, June 19, 2008=20 21:11
To: MEAD team
Subject: Re: [Mpls-interop] next MEAD team=20 meeting

 

Colleagues,

 

I was thinking for the requirements we should = include a=20 sentence in the

abstract to scope the MPLS-TP work as being = part of a=20 joint ITU-IETF

effort. Not all readers (now and future) will = be aware=20 of why this is

being done. In ccamp, we had done this for our = ASON=20 work. Maybe a

similar sentence will be needed in the other = documents?=20 Should we have a

common sentence?

 

How about for the = abstract:

This document summarizes the ITU-T = requirements for=20 MPLS-TP in order to

support capabilities and functionalities as = needed by=20 the ITU-T. It does

not address IETF protocol applicability or = capabilities.=20 This document

is a product of a joint ITU-IETF=20 effort.

 

Deborah 

 

-----Original = Message-----

From:=20 mpls-interop-bounces@ietf.org

[mailto:mpls-interop-bounces@ietf.org] On = Behalf Of Ben=20 Niven-Jenkins

Sent: Thursday, June 19, 2008 1:21=20 PM

To: Loa Andersson; MEAD=20 team

Subject: Re: [Mpls-interop] next MEAD team=20 meeting

 

Colleagues,

 

FYI see attached for the latest draft of the = MPLS-TP=20 requirements draft.

 

Ben

 

 

 

On 19/06/2008 16:00, "Loa Andersson" = <loa@pi.nu>=20 wrote:

 

> All,

>

> the MEAD team will have the next meeting = on Tuesday=20 24, at 6pm

> i.e. 12am east coast and 9am California.<= /P>

>

> Again I plan the meeting to last an hour, = and focus=20 will be on the

> document = status.

>

> Stewart will send out dial in details as=20 usual.

>

> /Loa

 

_______________________________________________

Mpls-interop mailing = list

Mpls-interop@ietf.org

https://www.ietf.org/mailman/listinfo/mpls-interop

------_=_NextPart_001_01C8D2B2.562D8987-- --===============0997463917== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop --===============0997463917==-- From mpls-interop-bounces@ietf.org Fri Jun 20 01:56:39 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCB203A69E1; Fri, 20 Jun 2008 01:56:39 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19D713A69F5 for ; Fri, 20 Jun 2008 01:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6I3Z4433wzpd for ; Fri, 20 Jun 2008 01:56:38 -0700 (PDT) Received: from fw.testbed.se (smtp.testbed.se [80.86.78.228]) by core3.amsl.com (Postfix) with ESMTP id C1DE93A69F3 for ; Fri, 20 Jun 2008 01:56:37 -0700 (PDT) Received: from MailerDaemon by fw.testbed.se with local-bsmtp (Exim 4.63) (envelope-from ) id 1K9cQ9-0003te-Cq for mpls-interop@ietf.org; Fri, 20 Jun 2008 10:56:37 +0200 Received: from h133n2fls33o883.telia.com ([217.208.62.133]:63337 helo=[192.168.0.100]) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1K9cQ8-0003tQ-Cl; Fri, 20 Jun 2008 10:56:36 +0200 Message-ID: <485B70C2.3010405@pi.nu> Date: Fri, 20 Jun 2008 10:56:34 +0200 From: Loa Andersson User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: "Sprecher, Nurit (NSN - IL/Israel - MiniMD)" References: <9FF5BDAD88B9D84881609E89AC92FB83EBD1D2@DEMUEXC014.nsn-intra.net> In-Reply-To: <9FF5BDAD88B9D84881609E89AC92FB83EBD1D2@DEMUEXC014.nsn-intra.net> Cc: MEAD team Subject: Re: [Mpls-interop] next MEAD team meeting X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org All, just a few comments. Sprecher, Nurit (NSN - IL/Israel - MiniMD) wrote: > Hi Deborah, > I understand the intention, so how about the following (as we also > indicated in the introduction): > This document specifies I wonder if "specifies" is the right word - one way would be to say "validates" indicating that this how we (IETF) understands these requirements the ITU-T requirements for MPLS-TP in order to > support capabilities and functionalities of MPLS as needed in transport > environments. this indicates that there is nothing but ITU-T requirements in the document, is that true? /Loa > MPLS is a maturing packet technology and it is already playing an > important role in transport networks and services. However, not all of > MPLS's capabilities and mechnisms are needed and/or consistent with > transport network operations. This document identifies the required > capabilities for MPLS so that it can better fit a transport role. > Please advise. > Best regards, > Nurit > > ________________________________ > > From: ext BRUNGARD, DEBORAH A, ATTLABS [mailto:dbrungard@att.com] > Sent: Thursday, June 19, 2008 23:04 > To: Sprecher, Nurit (NSN - IL/Israel - MiniMD); MEAD team > Subject: RE: [Mpls-interop] next MEAD team meeting > > > Hi Nurit, > > I would prefer to clearly say the requirements are ITU requirements for > MPLS in a transport environment. I think among some operators the line > between transport equipment and packet equipment has already blurred. > For many operators, the preference may be to align with MPLS operations > vs. transport. I think there are many differing opinions on what > MPLS/packet transport needs to support in a transport environment. So I > prefer to clearly say these are ITU requirements, they do not > necessarily reflect the operators contributing to this document. > > On the 2nd bullet, the requirements document has many > statements/requirements which may be interpreted by a reader as gaps in > MPLS/IETF protocols. I was trying to say with this sentence the document > is not addressing/identifying IETF protocol applicability or lack of > capabilities e.g. the sentence: > "Quality-of-service mechanisms are required in the packet transport > network to ensure the prioritization of critical services, to > guarantee BW and to control jitter and delay." > > QoS is not a new requirement for IETF protocols. Packet transport > networks (and this requirement document) are not the first time that QoS > mechanisms are identified as needed. This requirement is not intending > to identify a gap in the current IETF protocol set. This was what I was > trying to say. > > Suggestions? > Deborah > > > > ________________________________ > > From: Sprecher, Nurit (NSN - IL/Israel - MiniMD) > [mailto:nurit.sprecher@nsn.com] > Sent: Thursday, June 19, 2008 3:10 PM > To: BRUNGARD, DEBORAH A, ATTLABS; MEAD team > Cc: Sprecher, Nurit (NSN - IL/Israel - MiniMD) > Subject: RE: [Mpls-interop] next MEAD team meeting > > > > Hi Deborah, > > I have a few comments regarding the proposed abstract: > > * I think we should say "This document specifies the > requirements for MPLS-TP in order to support capabilities and > functionalities as needed in transport environments (or networks). > > * I do not understand the sentence: It does not address IETF > protocol applicability or capabilities. Do you mean applicability or > capability of the current IETF documents? As IMO it will be of the > documents we generate for MPLS-TP. > > * I think it is important to indicate that " This document is a > product of a joint ITU-IETF effort". > > Best regards, > > Nurit > > > > -----Original Message----- > From: mpls-interop-bounces@ietf.org > [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext BRUNGARD, > DEBORAH A, ATTLABS > Sent: Thursday, June 19, 2008 21:11 > To: MEAD team > Subject: Re: [Mpls-interop] next MEAD team meeting > > > > Colleagues, > > > > I was thinking for the requirements we should include a sentence in the > > abstract to scope the MPLS-TP work as being part of a joint ITU-IETF > > effort. Not all readers (now and future) will be aware of why this is > > being done. In ccamp, we had done this for our ASON work. Maybe a > > similar sentence will be needed in the other documents? Should we have a > > common sentence? > > > > How about for the abstract: > > This document summarizes the ITU-T requirements for MPLS-TP in order to > > support capabilities and functionalities as needed by the ITU-T. It does > > not address IETF protocol applicability or capabilities. This document > > is a product of a joint ITU-IETF effort. > > > > Deborah > > > > -----Original Message----- > > From: mpls-interop-bounces@ietf.org > > [mailto:mpls-interop-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins > > Sent: Thursday, June 19, 2008 1:21 PM > > To: Loa Andersson; MEAD team > > Subject: Re: [Mpls-interop] next MEAD team meeting > > > > Colleagues, > > > > FYI see attached for the latest draft of the MPLS-TP requirements draft. > > > > Ben > > > > > > > > On 19/06/2008 16:00, "Loa Andersson" wrote: > > > >> All, > > >> the MEAD team will have the next meeting on Tuesday 24, at 6pm > >> i.e. 12am east coast and 9am California. > > >> Again I plan the meeting to last an hour, and focus will be on the > >> document status. > > >> Stewart will send out dial in details as usual. > > >> /Loa > > > > _______________________________________________ > > Mpls-interop mailing list > > Mpls-interop@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-interop > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Mpls-interop mailing list > Mpls-interop@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-interop -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.nu _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop From mpls-interop-bounces@ietf.org Fri Jun 20 02:23:09 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C05813A6815; Fri, 20 Jun 2008 02:23:09 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BF083A68F4 for ; Fri, 20 Jun 2008 02:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id maic56tYYDW9 for ; Fri, 20 Jun 2008 02:23:07 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 65C103A6815 for ; Fri, 20 Jun 2008 02:23:07 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m5K9N53D012697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Jun 2008 11:23:05 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m5K9MxTj008928; Fri, 20 Jun 2008 11:23:01 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Jun 2008 11:22:55 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 20 Jun 2008 11:22:49 +0200 Message-ID: <9FF5BDAD88B9D84881609E89AC92FB83EBD1F7@DEMUEXC014.nsn-intra.net> In-Reply-To: <485B70C2.3010405@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mpls-interop] next MEAD team meeting Thread-Index: AcjSs5fKoweXPT/DRf68hWhC9uXvNAAArYbQ From: "Sprecher, Nurit (NSN - IL/Israel - MiniMD)" To: "ext Loa Andersson" X-OriginalArrivalTime: 20 Jun 2008 09:22:55.0361 (UTC) FILETIME=[38C91710:01C8D2B7] Cc: MEAD team Subject: Re: [Mpls-interop] next MEAD team meeting X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org Hi, 1. I agree that validates may be a good option. 2. IMO, these requirements are not only the ITU-T view. I got these requirements from different SPs. As I indicated in the beginning of the mail exchanges I would prefer to say: "This document specifies the requirements for MPLS-TP in order to support capabilities and functionalities as needed in transport environments (or networks)." But this is something that we need the SPs to agree on. Please note also that in the proposal just below I forgot to include the indication that this is a joint work of ITU-T and IETF. Best regards, Nurit -----Original Message----- From: ext Loa Andersson [mailto:loa@pi.nu] Sent: Friday, June 20, 2008 11:57 To: Sprecher, Nurit (NSN - IL/Israel - MiniMD) Cc: ext BRUNGARD, DEBORAH A, ATTLABS; MEAD team Subject: Re: [Mpls-interop] next MEAD team meeting All, just a few comments. Sprecher, Nurit (NSN - IL/Israel - MiniMD) wrote: > Hi Deborah, > I understand the intention, so how about the following (as we also > indicated in the introduction): > This document specifies I wonder if "specifies" is the right word - one way would be to say "validates" indicating that this how we (IETF) understands these requirements the ITU-T requirements for MPLS-TP in order to > support capabilities and functionalities of MPLS as needed in > transport environments. this indicates that there is nothing but ITU-T requirements in the document, is that true? /Loa > MPLS is a maturing packet technology and it is already playing an > important role in transport networks and services. However, not all of > MPLS's capabilities and mechnisms are needed and/or consistent with > transport network operations. This document identifies the required > capabilities for MPLS so that it can better fit a transport role. > Please advise. > Best regards, > Nurit > > ________________________________ > > From: ext BRUNGARD, DEBORAH A, ATTLABS [mailto:dbrungard@att.com] > Sent: Thursday, June 19, 2008 23:04 > To: Sprecher, Nurit (NSN - IL/Israel - MiniMD); MEAD team > Subject: RE: [Mpls-interop] next MEAD team meeting > > > Hi Nurit, > > I would prefer to clearly say the requirements are ITU requirements > for MPLS in a transport environment. I think among some operators the > line between transport equipment and packet equipment has already blurred. > For many operators, the preference may be to align with MPLS > operations vs. transport. I think there are many differing opinions on > what MPLS/packet transport needs to support in a transport > environment. So I prefer to clearly say these are ITU requirements, > they do not necessarily reflect the operators contributing to this document. > > On the 2nd bullet, the requirements document has many > statements/requirements which may be interpreted by a reader as gaps > in MPLS/IETF protocols. I was trying to say with this sentence the > document is not addressing/identifying IETF protocol applicability or > lack of capabilities e.g. the sentence: > "Quality-of-service mechanisms are required in the packet transport > network to ensure the prioritization of critical services, to > guarantee BW and to control jitter and delay." > > QoS is not a new requirement for IETF protocols. Packet transport > networks (and this requirement document) are not the first time that > QoS mechanisms are identified as needed. This requirement is not > intending to identify a gap in the current IETF protocol set. This was > what I was trying to say. > > Suggestions? > Deborah > > > > ________________________________ > > From: Sprecher, Nurit (NSN - IL/Israel - MiniMD) > [mailto:nurit.sprecher@nsn.com] > Sent: Thursday, June 19, 2008 3:10 PM > To: BRUNGARD, DEBORAH A, ATTLABS; MEAD team > Cc: Sprecher, Nurit (NSN - IL/Israel - MiniMD) > Subject: RE: [Mpls-interop] next MEAD team meeting > > > > Hi Deborah, > > I have a few comments regarding the proposed abstract: > > * I think we should say "This document specifies the > requirements for MPLS-TP in order to support capabilities and > functionalities as needed in transport environments (or networks). > > * I do not understand the sentence: It does not address IETF > protocol applicability or capabilities. Do you mean applicability or > capability of the current IETF documents? As IMO it will be of the > documents we generate for MPLS-TP. > > * I think it is important to indicate that " This document is a > product of a joint ITU-IETF effort". > > Best regards, > > Nurit > > > > -----Original Message----- > From: mpls-interop-bounces@ietf.org > [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext BRUNGARD, > DEBORAH A, ATTLABS > Sent: Thursday, June 19, 2008 21:11 > To: MEAD team > Subject: Re: [Mpls-interop] next MEAD team meeting > > > > Colleagues, > > > > I was thinking for the requirements we should include a sentence in > the > > abstract to scope the MPLS-TP work as being part of a joint ITU-IETF > > effort. Not all readers (now and future) will be aware of why this is > > being done. In ccamp, we had done this for our ASON work. Maybe a > > similar sentence will be needed in the other documents? Should we have > a > > common sentence? > > > > How about for the abstract: > > This document summarizes the ITU-T requirements for MPLS-TP in order > to > > support capabilities and functionalities as needed by the ITU-T. It > does > > not address IETF protocol applicability or capabilities. This document > > is a product of a joint ITU-IETF effort. > > > > Deborah > > > > -----Original Message----- > > From: mpls-interop-bounces@ietf.org > > [mailto:mpls-interop-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins > > Sent: Thursday, June 19, 2008 1:21 PM > > To: Loa Andersson; MEAD team > > Subject: Re: [Mpls-interop] next MEAD team meeting > > > > Colleagues, > > > > FYI see attached for the latest draft of the MPLS-TP requirements draft. > > > > Ben > > > > > > > > On 19/06/2008 16:00, "Loa Andersson" wrote: > > > >> All, > > >> the MEAD team will have the next meeting on Tuesday 24, at 6pm > >> i.e. 12am east coast and 9am California. > > >> Again I plan the meeting to last an hour, and focus will be on the > >> document status. > > >> Stewart will send out dial in details as usual. > > >> /Loa > > > > _______________________________________________ > > Mpls-interop mailing list > > Mpls-interop@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-interop > > > > > ---------------------------------------------------------------------- > -- > > _______________________________________________ > Mpls-interop mailing list > Mpls-interop@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-interop -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.nu _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop From mpls-interop-bounces@ietf.org Fri Jun 20 03:21:02 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C92813A6A14; Fri, 20 Jun 2008 03:21:02 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2783B3A6913 for ; Fri, 20 Jun 2008 03:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6YqmTrvGEeR for ; Fri, 20 Jun 2008 03:20:59 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 93A1B3A6A15 for ; Fri, 20 Jun 2008 03:20:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,678,1204498800"; d="ics'?eml'208?scan'208,208,217";a="12221903" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 20 Jun 2008 12:20:58 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5KAKwfn005235; Fri, 20 Jun 2008 12:20:58 +0200 Received: from dhcp-64-103-102-184.cisco.com (dhcp-64-103-102-184.cisco.com [64.103.102.184]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5KAKw7Q002706; Fri, 20 Jun 2008 10:20:58 GMT Message-ID: <485B848A.1000903@cisco.com> Date: Fri, 20 Jun 2008 11:20:58 +0100 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: mpls-interop@ietf.org Content-Type: multipart/mixed; boundary="------------090506000105000107000403" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=19711; t=1213957258; x=1214821258; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20[Fwd=3A=20Meeting=3A=20Bryant=20{Meeting=20ID=3 A=20310271828}] |Sender:=20; bh=r4jewH3Y+HvMV/aD7STePNdj88IxPRLcjQu8TWnbRbs=; b=rrtRdv1IrrvW2kAXXyFH3IveqsamPFcVvxDfq1J6++KISUGLfT2hERSBSZ WLda5kBDZQwS7a0Hwg3NEVWMaa7JOTps2z7bjgGh6Xixvmo8MOIT/HKPkn2P GzVimJ0IXZ; Authentication-Results: ams-dkim-2; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [Mpls-interop] [Fwd: Meeting: Bryant {Meeting ID: 310271828}] X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org This is a multi-part message in MIME format. --------------090506000105000107000403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit MEAD team dialing for Tuesday 24 June @ 5pm UK Stewart --------------090506000105000107000403 Content-Type: message/rfc822; name="Meeting: Bryant {Meeting ID: 310271828}.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Meeting: Bryant {Meeting ID: 310271828}.eml" X-Account-Key: account3 X-Mozilla-Keys: Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m5KAJb406946 for ; Fri, 20 Jun 2008 11:19:37 +0100 (BST) X-IronPort-AV: E=Sophos;i="4.27,678,1204498800"; d="ics'?scan'208,217";a="12221739" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 20 Jun 2008 12:19:37 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5KAJbxm003204 for ; Fri, 20 Jun 2008 12:19:37 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5KAJbgA002121 for ; Fri, 20 Jun 2008 10:19:37 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Jun 2008 12:19:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:calendarmessage MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8D2BF.24942EB2" Subject: Meeting: Bryant {Meeting ID: 310271828} Date: Fri, 20 Jun 2008 12:19:37 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Index: AcjSvySUj7p79DZ6SC+UOcpb9mAP4w== From: "mp-ams-c1-olk.svc" To: "Stewart Bryant (stbryant)" X-OriginalArrivalTime: 20 Jun 2008 10:19:37.0546 (UTC) FILETIME=[24A552A0:01C8D2BF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=16641; t=1213957177; x=1214821177; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mp-ams-c1-olk.svc@cisco.com; z=From:=20=22mp-ams-c1-olk.svc=22=20 |Subject:=20Meeting=3A=20Bryant=20{Meeting=20ID=3A=20310271 828} |Sender:=20; bh=mKbro+DqsvDBsE6fHArGXpcTrNJCtyuWXPt5YlZv4vE=; b=FW6QbCgaXCGKopA7gEvoAUDgfuaEeYRK/VVUldhNSgHVtkWcs95N+Jtyrd KD1QxuvDTcPzSEtbWqZG/b/hey9C/asuH9R84AtoWzTerSRpA8fQFSe25R7M 3/yxH0fWeh; Authentication-Results: ams-dkim-1; header.From=mp-ams-c1-olk.svc@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); This is a multi-part message in MIME format. ------_=_NextPart_001_01C8D2BF.24942EB2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stewart Bryant has invited you to a Cisco Unified MeetingPlace = Conference Date/Time: June 24, 2008 at 05:00PM Europe/London Length: 60 Frequency: once Meeting ID: 310271828 Meeting Password: =20 Global Access Numbers: http://cisco.com/en/US/about/doing_business/conferencing/index.html San Jose, CA: +408.525.6800 RTP: +919.392.3330 =20 US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 India: +91.80.4103.3979 Germany: +49.619.6773.9002 Japan: +81.3.5763.9394 China: +86.10.8515.5666 TO ATTEND A WEB AND VOICE CONFERENCE: CISCO INTRANET ATTENDEES Join the Web & Voice Conference* 1. Go to http://meetingplaceinternal.cisco.com/join.asp?310271828 2. Enter your CEC User ID & Password then click OK - Accept any security warnings you receive and wait for the Meeting Room = to initialize** 3. Click on CONNECT from the Meeting Room to join the Voice Conference = portion of the meeting EXTERNAL ATTENDEES - Outside the Cisco Intranet Join the Web & Voice Conference* 1. Go to http://meetingplace.cisco.com/join.asp?310271828 2. Fill in the My Name is field then click Attend Meeting - If you have a CEC User ID, click on the Cisco icon - Accept any security warnings you receive and wait for the Meeting Room = to initialize** 3. Click on CONNECT from the Meeting Room to join the Voice Conference = portion of the meeting - Note: Guest users will see a link to the Global Access Numbers. *If this is your first time attending a Web Conference, disable any = pop-up blockers and visit = http://meetingplace.cisco.com/mpweb/scripts/browsertestupper.asp to test = your web browser for compatibility with the Web Conference. **The meeting will not start until the Host of the meeting arrives - if = you'd like to start the meeting with your Profile, please review the = steps below to attend a Voice Only Conference as a Guest then follow the = system prompts. TO ATTEND A RESERVATIONLESS VOICE ONLY CONFERENCE AS THE HOST 1. Dial into Cisco Unified MeetingPlace (view the Access Numbers and = link above) 2. Press 1 to attend the meeting 3. Enter the Meeting ID 310271828 followed by # key 4. Follow the prompts to record your name and enter the waiting room 5. Press 2 then enter your Profile Password to initiate your meeting AS A GUEST 1. Follow steps 1-4 above to access the meeting 2. You will be placed in a waiting room until the Host initiates the = meeting SUPPORT Information about this Conference: Contact Stewart Bryant, 442088248828 Cisco IT Support Center: Attend the Voice Conference and then press #0 = on your phone keypad ------_=_NextPart_001_01C8D2BF.24942EB2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Meeting: Bryant {Meeting ID: 310271828}

Stewart Bryant has invited you = to a Cisco Unified MeetingPlace Conference

Date/Time:           &n= bsp;   June 24, 2008 at 05:00PM Europe/London
Length:           &n= bsp;      60
Frequency:           &n= bsp;   once
Meeting ID:           &n= bsp;  310271828
Meeting = Password:       

Global Access = Numbers:
http://cisco.com/en/US/about/doing_business/conferencing/index.html

    San Jose, CA: +408.525.6800    = RTP:           &n= bsp;  +919.392.3330     =20
    = US/Canada:  = +1.866.432.9903    United Kingdom:   +44.20.8824.0117
    = India:      = +91.80.4103.3979   Germany:          = +49.619.6773.9002
    = Japan:      = +81.3.5763.9394    China:            = +86.10.8515.5666

TO ATTEND A WEB AND VOICE = CONFERENCE:

CISCO = INTRANET ATTENDEES
Join the Web & Voice = Conference*
1. Go to http://= meetingplaceinternal.cisco.com/join.asp?310271828
2. Enter your CEC User ID & Password then click OK
- Accept any security warnings = you receive and wait for the Meeting Room to initialize**
3. Click on CONNECT from the Meeting Room to join the Voice Conference = portion of the meeting

EXTERNAL = ATTENDEES - Outside the Cisco Intranet
Join the Web & Voice = Conference*
1. Go to http://meetingp= lace.cisco.com/join.asp?310271828
2. Fill in the My Name is field then click Attend Meeting
- If you have a CEC User ID, = click on the Cisco icon
- Accept any security warnings = you receive and wait for the Meeting Room to initialize**
3. Click on CONNECT from the Meeting Room to join the Voice Conference = portion of the meeting
- Note: Guest users will see a link to the Global Access Numbers.

*If this is your = first time attending a Web Conference, disable any pop-up blockers and = visit http://meetingplace.cisco.com/mpweb/scripts/browsertestupper.asp to test your web browser for = compatibility with the Web Conference.

**The meeting will = not start until the Host of the meeting arrives - if you'd like to start = the meeting with your Profile, please review the steps below to attend a = Voice Only Conference as a Guest then follow the system = prompts.

TO ATTEND A RESERVATIONLESS VOICE = ONLY CONFERENCE

AS THE = HOST
1. Dial into Cisco Unified = MeetingPlace (view the Access Numbers and link above)
2. Press 1 to attend the meeting
3. Enter the Meeting = ID 310271828 followed = by # key
4. Follow the prompts to record = your name and enter the waiting room
5. Press 2 then enter your Profile Password to = initiate your meeting

AS A = GUEST
1. Follow steps 1-4 above to = access the meeting
2. You will be placed in a = waiting room until the Host initiates the meeting

SUPPORT
Information about this = Conference: Contact = Stewart Bryant, 442088248828
Cisco IT Support = Center: Attend the Voice = Conference and then press #0 on your phone keypad

------_=_NextPart_001_01C8D2BF.24942EB2 Content-class: urn:content-classes:calendarmessage Content-Type: text/calendar; method=REQUEST; name="meeting.ics" Content-Transfer-Encoding: 8bit BEGIN:VCALENDAR METHOD:REQUEST PRODID:Microsoft CDO for Microsoft Exchange VERSION:2.0 BEGIN:VEVENT DTSTAMP:20080620T101937Z DTSTART:20080624T160000Z SUMMARY:Meeting: Bryant {Meeting ID: 310271828} UID:040000008200E00074C5B7101A82E00800000000A0548722BFD2C801000000000000000 0100000002E6C453236213544ABC01776041A80D6 ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Stewart B ryant (stbryant)":MAILTO:stbryant@cisco.com ORGANIZER;CN="mp-ams-c1-olk.svc":MAILTO:mp-ams-c1-olk.svc@cisco.com LOCATION: DTEND:20080624T170000Z DESCRIPTION:Stewart Bryant has invited you to a Cisco Unified MeetingPlace Conference\N\NDate/Time: June 24\, 2008 at 05:00PM Europe/Lo ndon\NLength: 60\NFrequency: once\NMeeting ID: 310271828\NMeeting Password: \N\NGlobal Access Num bers:\Nhttp://cisco.com/en/US/about/doing_business/conferencing/index.html \N\N San Jose\, CA: +408.525.6800 RTP: +919.392.3330 \N US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 \N India: +91.80.4103.3979 Germany: +49.619.6773.9002\N Japan: +81.3.5763.9394 China: +86.10.8515.5666\N\NT O ATTEND A WEB AND VOICE CONFERENCE:\N\NCISCO INTRANET ATTENDEES\NJoin the Web & Voice Conference*\N1. Go to http://meetingplaceinternal.cisco.com/j oin.asp?310271828\N2. Enter your CEC User ID & Password then click OK\N- A ccept any security warnings you receive and wait for the Meeting Room to i nitialize**\N3. Click on CONNECT from the Meeting Room to join the Voice C onference portion of the meeting\N\NEXTERNAL ATTENDEES - Outside the Cisco Intranet\NJoin the Web & Voice Conference*\N1. Go to http://meetingplace. cisco.com/join.asp?310271828\N2. Fill in the My Name is field then click A ttend Meeting\N- If you have a CEC User ID\, click on the Cisco icon\N- Ac cept any security warnings you receive and wait for the Meeting Room to in itialize**\N3. Click on CONNECT from the Meeting Room to join the Voice Co nference portion of the meeting\N- Note: Guest users will see a link to th e Global Access Numbers.\N\N*If this is your first time attending a Web Co nference\, disable any pop-up blockers and visit http://meetingplace.cisco .com/mpweb/scripts/browsertestupper.asp to test your web browser for compa tibility with the Web Conference.\N**The meeting will not start until the Host of the meeting arrives - if you'd like to start the meeting with your Profile\, please review the steps below to attend a Voice Only Conference as a Guest then follow the system prompts.\N\NTO ATTEND A RESERVATIONLESS VOICE ONLY CONFERENCE\N\NAS THE HOST\N1. Dial into Cisco Unified MeetingP lace (view the Access Numbers and link above)\N2. Press 1 to attend the me eting\N3. Enter the Meeting ID 310271828 followed by # key\N4. Follow the prompts to record your name and enter the waiting room\N5. Press 2 then en ter your Profile Password to initiate your meeting\N\NAS A GUEST\N1. Follo w steps 1-4 above to access the meeting\N2. You will be placed in a waitin g room until the Host initiates the meeting\N\NSUPPORT\NInformation about this Conference: Contact Stewart Bryant\, 442088248828\NCisco IT Support C enter: Attend the Voice Conference and then press #0 on your phone keypad\ N\N SEQUENCE:0 PRIORITY:5 CLASS: CREATED:20080620T101937Z LAST-MODIFIED:20080620T101937Z STATUS:CONFIRMED TRANSP:OPAQUE X-MICROSOFT-CDO-BUSYSTATUS:BUSY X-MICROSOFT-CDO-INSTTYPE:0 X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY X-MICROSOFT-CDO-ALLDAYEVENT:FALSE X-MICROSOFT-CDO-IMPORTANCE:1 X-MICROSOFT-CDO-OWNERAPPTID:-1 X-MICROSOFT-CDO-ATTENDEE-CRITICAL-CHANGE:20080620T101937Z X-MICROSOFT-CDO-OWNER-CRITICAL-CHANGE:20080620T101937Z BEGIN:VALARM ACTION:DISPLAY DESCRIPTION:REMINDER TRIGGER;RELATED=START:-PT00H15M00S END:VALARM END:VEVENT END:VCALENDAR ------_=_NextPart_001_01C8D2BF.24942EB2-- --------------090506000105000107000403 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop --------------090506000105000107000403-- From mpls-interop-bounces@ietf.org Fri Jun 20 03:28:15 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEED328C127; Fri, 20 Jun 2008 03:28:15 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A466328C127 for ; Fri, 20 Jun 2008 03:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ElC3M-wHtJTQ for ; Fri, 20 Jun 2008 03:28:14 -0700 (PDT) Received: from fw.testbed.se (smtp.testbed.se [80.86.78.228]) by core3.amsl.com (Postfix) with ESMTP id C3EB428C12B for ; Fri, 20 Jun 2008 03:28:13 -0700 (PDT) Received: from MailerDaemon by fw.testbed.se with local-bsmtp (Exim 4.63) (envelope-from ) id 1K9dqn-0004Es-1K for mpls-interop@ietf.org; Fri, 20 Jun 2008 12:28:13 +0200 Received: from h133n2fls33o883.telia.com ([217.208.62.133]:63760 helo=[192.168.0.100]) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1K9dql-0004Em-MZ for mpls-interop@ietf.org; Fri, 20 Jun 2008 12:28:11 +0200 Message-ID: <485B8638.8050301@pi.nu> Date: Fri, 20 Jun 2008 12:28:08 +0200 From: Loa Andersson User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: MEAD team Subject: [Mpls-interop] instruction on how to handle editors and authors in the MPLS-TP documents X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org All, I've been asked from several directions on how to handle the editors and contributing authors in the MPLS-TP documents. I've discussed this with the RFC Editor and taken some advice from others. This what we will do: 1. If the total number of editors and contributing authors are five or less, you may put all of them on the first page. You don't even ned to put the "(Ed)" after the editors, since "editor" don't carry any special semantics in IETF. And then you put the rest of the information about the authors and editors in a section called "Authors addresses" 2. If the total number of editors and contributing authors is more than 5, you need to do the following: - have the three editors on the front page, (Ed) after the names - create a section "1.1 Contributing Authors" and list everybody there in alphabetic order on their last name (no affiliation) - Have the normal Authors Address section at its normal place, starting with the editors (alphabetic order) and with (Ed) after their names, and then list contributing authors in alphabetic order In AUTH48 the RFC Ed will ask the people on the front page to sign off for the RFC, but in this case the editors will need to check with contributing authors before signing of. /Loa -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.nu _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop From mpls-interop-bounces@ietf.org Fri Jun 20 07:07:12 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 895EF3A6A6E; Fri, 20 Jun 2008 07:07:12 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22EC63A6A6B for ; Fri, 20 Jun 2008 07:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.299 X-Spam-Level: X-Spam-Status: No, score=-105.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5bN9S4dH4qY8 for ; Fri, 20 Jun 2008 07:07:09 -0700 (PDT) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.245.115]) by core3.amsl.com (Postfix) with ESMTP id 909073A6A6E for ; Fri, 20 Jun 2008 07:07:09 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-4.tower-121.messagelabs.com!1213970828!15699217!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 28493 invoked from network); 20 Jun 2008 14:07:08 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-4.tower-121.messagelabs.com with AES256-SHA encrypted SMTP; 20 Jun 2008 14:07:08 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m5KE77cW013469 for ; Fri, 20 Jun 2008 10:07:07 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m5KE6vNq013268 for ; Fri, 20 Jun 2008 10:07:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 20 Jun 2008 10:06:54 -0400 Message-ID: In-Reply-To: <9FF5BDAD88B9D84881609E89AC92FB83EBD1F7@DEMUEXC014.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mpls-interop] next MEAD team meeting Thread-Index: AcjSs5fKoweXPT/DRf68hWhC9uXvNAAArYbQAAlI1pA= References: <485B70C2.3010405@pi.nu> <9FF5BDAD88B9D84881609E89AC92FB83EBD1F7@DEMUEXC014.nsn-intra.net> From: "BRUNGARD, DEBORAH A, ATTLABS" To: "Sprecher, Nurit (NSN - IL/Israel - MiniMD)" , "ext Loa Andersson" Cc: MEAD team Subject: Re: [Mpls-interop] next MEAD team meeting X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org Hi, Thanks Loa for the hint. My understanding of the charter was to capture the ITU requirements? What is the MEAD development work covering - both ITU requirements and "other (anonymous) SPs requirements"? Deborah -----Original Message----- From: Sprecher, Nurit (NSN - IL/Israel - MiniMD) [mailto:nurit.sprecher@nsn.com] Sent: Friday, June 20, 2008 5:23 AM To: ext Loa Andersson Cc: BRUNGARD, DEBORAH A, ATTLABS; MEAD team; Sprecher, Nurit (NSN - IL/Israel - MiniMD) Subject: RE: [Mpls-interop] next MEAD team meeting Hi, 1. I agree that validates may be a good option. 2. IMO, these requirements are not only the ITU-T view. I got these requirements from different SPs. As I indicated in the beginning of the mail exchanges I would prefer to say: "This document specifies the requirements for MPLS-TP in order to support capabilities and functionalities as needed in transport environments (or networks)." But this is something that we need the SPs to agree on. Please note also that in the proposal just below I forgot to include the indication that this is a joint work of ITU-T and IETF. Best regards, Nurit -----Original Message----- From: ext Loa Andersson [mailto:loa@pi.nu] Sent: Friday, June 20, 2008 11:57 To: Sprecher, Nurit (NSN - IL/Israel - MiniMD) Cc: ext BRUNGARD, DEBORAH A, ATTLABS; MEAD team Subject: Re: [Mpls-interop] next MEAD team meeting All, just a few comments. Sprecher, Nurit (NSN - IL/Israel - MiniMD) wrote: > Hi Deborah, > I understand the intention, so how about the following (as we also > indicated in the introduction): > This document specifies I wonder if "specifies" is the right word - one way would be to say "validates" indicating that this how we (IETF) understands these requirements the ITU-T requirements for MPLS-TP in order to > support capabilities and functionalities of MPLS as needed in > transport environments. this indicates that there is nothing but ITU-T requirements in the document, is that true? /Loa > MPLS is a maturing packet technology and it is already playing an > important role in transport networks and services. However, not all of > MPLS's capabilities and mechnisms are needed and/or consistent with > transport network operations. This document identifies the required > capabilities for MPLS so that it can better fit a transport role. > Please advise. > Best regards, > Nurit > > ________________________________ > > From: ext BRUNGARD, DEBORAH A, ATTLABS [mailto:dbrungard@att.com] > Sent: Thursday, June 19, 2008 23:04 > To: Sprecher, Nurit (NSN - IL/Israel - MiniMD); MEAD team > Subject: RE: [Mpls-interop] next MEAD team meeting > > > Hi Nurit, > > I would prefer to clearly say the requirements are ITU requirements > for MPLS in a transport environment. I think among some operators the > line between transport equipment and packet equipment has already blurred. > For many operators, the preference may be to align with MPLS > operations vs. transport. I think there are many differing opinions on > what MPLS/packet transport needs to support in a transport > environment. So I prefer to clearly say these are ITU requirements, > they do not necessarily reflect the operators contributing to this document. > > On the 2nd bullet, the requirements document has many > statements/requirements which may be interpreted by a reader as gaps > in MPLS/IETF protocols. I was trying to say with this sentence the > document is not addressing/identifying IETF protocol applicability or > lack of capabilities e.g. the sentence: > "Quality-of-service mechanisms are required in the packet transport > network to ensure the prioritization of critical services, to > guarantee BW and to control jitter and delay." > > QoS is not a new requirement for IETF protocols. Packet transport > networks (and this requirement document) are not the first time that > QoS mechanisms are identified as needed. This requirement is not > intending to identify a gap in the current IETF protocol set. This was > what I was trying to say. > > Suggestions? > Deborah > > > > ________________________________ > > From: Sprecher, Nurit (NSN - IL/Israel - MiniMD) > [mailto:nurit.sprecher@nsn.com] > Sent: Thursday, June 19, 2008 3:10 PM > To: BRUNGARD, DEBORAH A, ATTLABS; MEAD team > Cc: Sprecher, Nurit (NSN - IL/Israel - MiniMD) > Subject: RE: [Mpls-interop] next MEAD team meeting > > > > Hi Deborah, > > I have a few comments regarding the proposed abstract: > > * I think we should say "This document specifies the > requirements for MPLS-TP in order to support capabilities and > functionalities as needed in transport environments (or networks). > > * I do not understand the sentence: It does not address IETF > protocol applicability or capabilities. Do you mean applicability or > capability of the current IETF documents? As IMO it will be of the > documents we generate for MPLS-TP. > > * I think it is important to indicate that " This document is a > product of a joint ITU-IETF effort". > > Best regards, > > Nurit > > > > -----Original Message----- > From: mpls-interop-bounces@ietf.org > [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext BRUNGARD, > DEBORAH A, ATTLABS > Sent: Thursday, June 19, 2008 21:11 > To: MEAD team > Subject: Re: [Mpls-interop] next MEAD team meeting > > > > Colleagues, > > > > I was thinking for the requirements we should include a sentence in > the > > abstract to scope the MPLS-TP work as being part of a joint ITU-IETF > > effort. Not all readers (now and future) will be aware of why this is > > being done. In ccamp, we had done this for our ASON work. Maybe a > > similar sentence will be needed in the other documents? Should we have > a > > common sentence? > > > > How about for the abstract: > > This document summarizes the ITU-T requirements for MPLS-TP in order > to > > support capabilities and functionalities as needed by the ITU-T. It > does > > not address IETF protocol applicability or capabilities. This document > > is a product of a joint ITU-IETF effort. > > > > Deborah > > > > -----Original Message----- > > From: mpls-interop-bounces@ietf.org > > [mailto:mpls-interop-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins > > Sent: Thursday, June 19, 2008 1:21 PM > > To: Loa Andersson; MEAD team > > Subject: Re: [Mpls-interop] next MEAD team meeting > > > > Colleagues, > > > > FYI see attached for the latest draft of the MPLS-TP requirements draft. > > > > Ben > > > > > > > > On 19/06/2008 16:00, "Loa Andersson" wrote: > > > >> All, > > >> the MEAD team will have the next meeting on Tuesday 24, at 6pm > >> i.e. 12am east coast and 9am California. > > >> Again I plan the meeting to last an hour, and focus will be on the > >> document status. > > >> Stewart will send out dial in details as usual. > > >> /Loa > > > > _______________________________________________ > > Mpls-interop mailing list > > Mpls-interop@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-interop > > > > > ---------------------------------------------------------------------- > -- > > _______________________________________________ > Mpls-interop mailing list > Mpls-interop@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-interop -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.nu _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop From mpls-interop-bounces@ietf.org Fri Jun 20 10:24:45 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B8CA3A63EC; Fri, 20 Jun 2008 10:24:45 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A5663A685A for ; Fri, 20 Jun 2008 10:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id py9xk1Hq2HJm for ; Fri, 20 Jun 2008 10:24:43 -0700 (PDT) Received: from fw.testbed.se (smtp.testbed.se [80.86.78.228]) by core3.amsl.com (Postfix) with ESMTP id B7F913A63EC for ; Fri, 20 Jun 2008 10:24:42 -0700 (PDT) Received: from MailerDaemon by fw.testbed.se with local-bsmtp (Exim 4.63) (envelope-from ) id 1K9kLo-0005o7-3i for mpls-interop@ietf.org; Fri, 20 Jun 2008 19:24:40 +0200 Received: from h133n2fls33o883.telia.com ([217.208.62.133]:61420 helo=[192.168.0.100]) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1K9kLn-0005nu-7k; Fri, 20 Jun 2008 19:24:39 +0200 Message-ID: <485BE7D3.1040808@pi.nu> Date: Fri, 20 Jun 2008 19:24:35 +0200 From: Loa Andersson User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: "BRUNGARD, DEBORAH A, ATTLABS" References: <485B70C2.3010405@pi.nu> <9FF5BDAD88B9D84881609E89AC92FB83EBD1F7@DEMUEXC014.nsn-intra.net> In-Reply-To: Cc: MEAD team Subject: Re: [Mpls-interop] next MEAD team meeting X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org BRUNGARD, DEBORAH A, ATTLABS wrote: > Hi, > > Thanks Loa for the hint. My understanding of the charter was to capture > the ITU requirements? yes - that is true... but we also need to capture all requirements for the MPLS-TP whether they are in the captured by the ITU-T or not. > > What is the MEAD development work covering - both ITU requirements and > "other (anonymous) SPs requirements"? if there is "only" requirements that originates from ITU-T this is not a problem. I am not looking for anonymous requirements, if there is a requirement that is not from ITU-T we should make clear where it came form /Loa > > Deborah > > > -----Original Message----- > From: Sprecher, Nurit (NSN - IL/Israel - MiniMD) > [mailto:nurit.sprecher@nsn.com] > Sent: Friday, June 20, 2008 5:23 AM > To: ext Loa Andersson > Cc: BRUNGARD, DEBORAH A, ATTLABS; MEAD team; Sprecher, Nurit (NSN - > IL/Israel - MiniMD) > Subject: RE: [Mpls-interop] next MEAD team meeting > > Hi, > 1. I agree that validates may be a good option. > 2. IMO, these requirements are not only the ITU-T view. I got these > requirements from different SPs. As I indicated in the beginning of the > mail exchanges I would prefer to say: "This document specifies the > requirements for MPLS-TP in order to support capabilities and > functionalities as needed in transport environments (or networks)." But > this is something that we need the SPs to agree on. > Please note also that in the proposal just below I forgot to include the > indication that this is a joint work of ITU-T and IETF. > Best regards, > Nurit > > > -----Original Message----- > From: ext Loa Andersson [mailto:loa@pi.nu] > Sent: Friday, June 20, 2008 11:57 > To: Sprecher, Nurit (NSN - IL/Israel - MiniMD) > Cc: ext BRUNGARD, DEBORAH A, ATTLABS; MEAD team > Subject: Re: [Mpls-interop] next MEAD team meeting > > All, > > just a few comments. > > Sprecher, Nurit (NSN - IL/Israel - MiniMD) wrote: >> Hi Deborah, >> I understand the intention, so how about the following (as we also >> indicated in the introduction): >> This document specifies > > I wonder if "specifies" is the right word - one way would be to say > "validates" indicating that this how we (IETF) understands these > requirements > > the ITU-T requirements for MPLS-TP in order to >> support capabilities and functionalities of MPLS as needed in >> transport environments. > > this indicates that there is nothing but ITU-T requirements in the > document, is that true? > > /Loa > >> MPLS is a maturing packet technology and it is already playing an >> important role in transport networks and services. However, not all of > >> MPLS's capabilities and mechnisms are needed and/or consistent with >> transport network operations. This document identifies the required >> capabilities for MPLS so that it can better fit a transport role. > >> Please advise. >> Best regards, >> Nurit >> >> ________________________________ >> >> From: ext BRUNGARD, DEBORAH A, ATTLABS [mailto:dbrungard@att.com] >> Sent: Thursday, June 19, 2008 23:04 >> To: Sprecher, Nurit (NSN - IL/Israel - MiniMD); MEAD team >> Subject: RE: [Mpls-interop] next MEAD team meeting >> >> >> Hi Nurit, >> >> I would prefer to clearly say the requirements are ITU requirements >> for MPLS in a transport environment. I think among some operators the >> line between transport equipment and packet equipment has already > blurred. >> For many operators, the preference may be to align with MPLS >> operations vs. transport. I think there are many differing opinions on > >> what MPLS/packet transport needs to support in a transport >> environment. So I prefer to clearly say these are ITU requirements, >> they do not necessarily reflect the operators contributing to this > document. >> >> On the 2nd bullet, the requirements document has many >> statements/requirements which may be interpreted by a reader as gaps >> in MPLS/IETF protocols. I was trying to say with this sentence the >> document is not addressing/identifying IETF protocol applicability or >> lack of capabilities e.g. the sentence: >> "Quality-of-service mechanisms are required in the packet transport >> network to ensure the prioritization of critical services, to >> guarantee BW and to control jitter and delay." >> >> QoS is not a new requirement for IETF protocols. Packet transport >> networks (and this requirement document) are not the first time that >> QoS mechanisms are identified as needed. This requirement is not >> intending to identify a gap in the current IETF protocol set. This was > >> what I was trying to say. >> >> Suggestions? >> Deborah >> >> >> >> ________________________________ >> >> From: Sprecher, Nurit (NSN - IL/Israel - MiniMD) >> [mailto:nurit.sprecher@nsn.com] >> Sent: Thursday, June 19, 2008 3:10 PM >> To: BRUNGARD, DEBORAH A, ATTLABS; MEAD team >> Cc: Sprecher, Nurit (NSN - IL/Israel - MiniMD) >> Subject: RE: [Mpls-interop] next MEAD team meeting >> >> >> >> Hi Deborah, >> >> I have a few comments regarding the proposed abstract: >> >> * I think we should say "This document specifies the >> requirements for MPLS-TP in order to support capabilities and >> functionalities as needed in transport environments (or networks). >> >> * I do not understand the sentence: It does not address IETF >> protocol applicability or capabilities. Do you mean applicability or >> capability of the current IETF documents? As IMO it will be of the >> documents we generate for MPLS-TP. >> >> * I think it is important to indicate that " This document is > a >> product of a joint ITU-IETF effort". >> >> Best regards, >> >> Nurit >> >> >> >> -----Original Message----- >> From: mpls-interop-bounces@ietf.org >> [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext BRUNGARD, >> DEBORAH A, ATTLABS >> Sent: Thursday, June 19, 2008 21:11 >> To: MEAD team >> Subject: Re: [Mpls-interop] next MEAD team meeting >> >> >> >> Colleagues, >> >> >> >> I was thinking for the requirements we should include a sentence in >> the >> >> abstract to scope the MPLS-TP work as being part of a joint ITU-IETF >> >> effort. Not all readers (now and future) will be aware of why this is >> >> being done. In ccamp, we had done this for our ASON work. Maybe a >> >> similar sentence will be needed in the other documents? Should we have > >> a >> >> common sentence? >> >> >> >> How about for the abstract: >> >> This document summarizes the ITU-T requirements for MPLS-TP in order >> to >> >> support capabilities and functionalities as needed by the ITU-T. It >> does >> >> not address IETF protocol applicability or capabilities. This document >> >> is a product of a joint ITU-IETF effort. >> >> >> >> Deborah >> >> >> >> -----Original Message----- >> >> From: mpls-interop-bounces@ietf.org >> >> [mailto:mpls-interop-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins >> >> Sent: Thursday, June 19, 2008 1:21 PM >> >> To: Loa Andersson; MEAD team >> >> Subject: Re: [Mpls-interop] next MEAD team meeting >> >> >> >> Colleagues, >> >> >> >> FYI see attached for the latest draft of the MPLS-TP requirements > draft. >> >> >> Ben >> >> >> >> >> >> >> >> On 19/06/2008 16:00, "Loa Andersson" wrote: >> >> >> >>> All, >> >>> the MEAD team will have the next meeting on Tuesday 24, at 6pm >>> i.e. 12am east coast and 9am California. >> >>> Again I plan the meeting to last an hour, and focus will be on the >>> document status. >> >>> Stewart will send out dial in details as usual. >> >>> /Loa >> >> >> _______________________________________________ >> >> Mpls-interop mailing list >> >> Mpls-interop@ietf.org >> >> https://www.ietf.org/mailman/listinfo/mpls-interop >> >> >> >> >> ---------------------------------------------------------------------- >> -- >> >> _______________________________________________ >> Mpls-interop mailing list >> Mpls-interop@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-interop > > > -- > Loa Andersson > > Principal Networking Architect > Acreo AB phone: +46 8 632 77 14 > Isafjordsgatan 22 mobile: +46 739 81 21 64 > Kista, Sweden email: loa.andersson@acreo.se > loa@pi.nu -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.nu _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop From mpls-interop-bounces@ietf.org Sat Jun 21 04:11:41 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF6ED3A681E; Sat, 21 Jun 2008 04:11:41 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BAC73A681E for ; Sat, 21 Jun 2008 04:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.66 X-Spam-Level: ** X-Spam-Status: No, score=2.66 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DATE_IN_PAST_12_24=0.992, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nr2RgQgfUYlj for ; Sat, 21 Jun 2008 04:11:38 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 386DE3A6924 for ; Sat, 21 Jun 2008 04:11:36 -0700 (PDT) Received: from E03MVZ2-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Jun 2008 12:11:39 +0100 Received: from 217.32.164.184 ([217.32.164.184]) by E03MVZ2-UKDY.domain1.systemhost.net ([193.113.30.120]) via Exchange Front-End Server mail.bt.com ([193.113.197.28]) with Microsoft Exchange Server HTTP-DAV ; Sat, 21 Jun 2008 11:11:38 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Fri, 20 Jun 2008 14:38:08 -0400 From: Thomas Nadeau To: Ben Niven-Jenkins , Loa Andersson , MEAD team Message-ID: Thread-Topic: [Mpls-interop] next MEAD team meeting Thread-Index: AcjSMNQsx4BuurjX8EeQxIcfmO8exAA0/R+V In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 21 Jun 2008 11:11:39.0277 (UTC) FILETIME=[93C16BD0:01C8D38F] Subject: Re: [Mpls-interop] next MEAD team meeting X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org Comments on the document inline start with "TOM:" In general, please review the document and put more of an emphasis on the use of "MUST" rather than "MAY" or "SHOULD". The IETG frowns on requirements documents that are too optional. --Tom Network Working Group B. Niven-Jenkins, Ed. Internet-Draft BT Intended status: Informational D. Brungard, Ed. Expires: January 2, 2009 AT&T M. Betts, Ed. Nortel Networks N. Sprecher Nokia Siemens Networks July 01, 2008 MPLS-TP Requirements draft-jenkins-mpls-mplstp-requirements-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on January 2, 2009. Abstract This document will outline the requirements for MPLS-TP. Requirements Language 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 [RFC2119]. Niven-Jenkins, et al. Expires January 2, 2009 [Page 1] Internet-Draft MPLS-TP Requirements July 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. MPLS-TP Requirements . . . . . . . . . . . . . . . . . . . . . 5 2.1. General requirements . . . . . . . . . . . . . . . . . . . 5 2.2. Layering requirements . . . . . . . . . . . . . . . . . . 6 2.3. Data plane requirements . . . . . . . . . . . . . . . . . 7 2.4. Control plane requirements . . . . . . . . . . . . . . . . 8 2.5. Network Management (NM) requirements . . . . . . . . . . . 11 2.6. OAM requirements . . . . . . . . . . . . . . . . . . . . . 11 2.7. Network performance management (PM) requirements . . . . . 11 2.8. Protection & Survivability requirements . . . . . . . . . 12 2.9. QoS requirements . . . . . . . . . . . . . . . . . . . . . 14 2.10. Security requirements . . . . . . . . . . . . . . . . . . 15 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 6. Informative References . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 18 Niven-Jenkins, et al. Expires January 2, 2009 [Page 2] Internet-Draft MPLS-TP Requirements July 2008 1. Introduction For many years, SONET/SDH has provided service providers with a high benchmark for reliability and operational simplicity. With the accelerating growth of packet-based services (such as Ethernet, VoIP, L2/L3 VPN, IPTV, RAN backhauling, etc.), service providers are in need of capabilities to efficiently support packet-based services on their transport networks. The need to increase their revenue while remaining competitive forces operators to look for the lowest network Total Cost of Ownership (TCO). Investment in both Capital Expenditure (CAPEX) and Operational Expense (OPEX) should be minimal. Carriers are considering migrating to packet transport networks in order to reduce their costs and to improve their ability to support services with guaranteed SLAs. Migrating from SONET/SDH to packet transport networks should not involve dramatic changes in network operation, should not necessitate extensive retraining, and should not require major changes to existing work practices. The aim is to preserve the look-and-feel to which carriers have become accustomed in deploying their SONET/SDH networks, while providing common, multi- layer operations, resiliency, control and management for packet, circuit and lambda transport networks. An important attribute of a transport network is its ability to function independently from both its client and server (transmission media) layer networks. It should be capable of transmitting over any media. Another key characteristic of transport networks is the capability to maintain the integrity of the client signal between its ingress and egress ports. TOM: I would use something other than "client signal" here. Something like "client path" or something is what I think you mean. A transport network must provide the means to commit quality of service objectives to clients. This is achieved by providing a mechanism for client network service demarcation for the network path together with an associated network resiliency mechanism. A transport network must also provide a method of service monitoring in order to verify the delivery of an agreed quality of service. This is enabled by means of carrier-grade OAM tools. The connectivity service is the basic service provided by a transport network. TOM: Is it? Does the transport really provide connections or does it provide transport paths? I am sensitive to the terms used here. We don't want this to become a connect-fest. Seems to me that you explain this better in the next sentence anyhow. The purpose of a transport network is to transparently carry client signals (i.e. the stream of client PDUs or client bits) TOM: Again, I don't like the term "signals" here. Use "client data" or something. between endpoints in the network (typically over several intermediate nodes). These endpoints may be service switching points or service terminating points. The connectivity services offered to customers are aggregated into large, long-holding time pipes/trunks which TOM: Do you really mean to call these "time pipes"? Sounds too futuristic even for this work. *) I think you mean "...into relatively large, long-lasting paths..." enable the efficient and reliable operation of the transport network. These trunks are modified infrequently. TOM: Keep the terminology consistent here too. There is the use of "trunks", "pipes", etc... Aggregation and hierarchy are beneficial for achieving scalability and security since: Niven-Jenkins, et al. Expires January 2, 2009 [Page 3] Internet-Draft MPLS-TP Requirements July 2008 1. They reduce the number of provisioning and forwarding states in the network core. 2. They reduce load and the cost of implementing service assurance and fault management. TOM: Do they really reduce load? This is one of those fluffy, open-ended terms like "scaleability" that I don't like used unless it is clearly defined. 3. Client signals are completely encapsulated and isolated from each other. This also allows complete isolation of customer traffic from carrier operations. TOM: Does this really happen at the data or control plane or both? Or do we care? Client signals are first transparently encapsulated. These encapsulated client signals are then aggregated for transport through the network in order to optimize network management. Server layer OAM is used to monitor the transport integrity of the client layer aggregate. At any hop, the aggregated signals may be further aggregated in lower layer transport network paths for transport across intermediate shared links. The encapsulated client signals are extracted at the edges of aggregation domains, and are either delivered to the client or forwarded to another domain. In the core of the network, only the server layer aggregated signals are monitored; individual client signals are monitored at the network boundary in the client layer network. TOM: I am not sure the above is appropriate for a requirements document. It sounds like you are spelling out an algorithm for how a solution should work. Quality-of-service mechanisms are required in the packet transport network to ensure the prioritization of critical services, to guarantee BW and to control jitter and delay. TOM: Are they required everywhere the service exists, or say just at the ingress/egress for policing/marking functions? While we are on the subject, do we want to be more specific about QoS requirements? Service providers require control and deterministic usage of network resources. They need end-to-end control to engineer network paths and to efficiently utilize network resources. They require capabilities to statically (OSS based) provision deterministic, protected and secured services and their associated resources as well as alternative control-plane options. TOM: They also require dynamic ones. Please put that in. I don't want to be asking for only a completely static system. The transport network must be capable of transporting multiple services in a scalable manner. TOM: Again, this use of "scalable" offends me. Please be more specific or take the sentence out as it is meaningless as stated. Carriers will still need to cope with legacy networks (which are composed of many layers and technologies), thus the packet transport network should interwork with other packet and transport networks (both horizontally and vertically). Vertical interworking is also known as client/server or network interworking. Horizontal interworking is also known as peer-partition or service interworking. TOM: Didn't you just say that vertical interworking was client interworking in the first sentence? How can horizontal be service interworking as well? For more details on each type of interworking and some of the issues that may arise (especially with horizontal interworking) see [ITU.Y1401.2008]. MPLS is a maturing packet technology and it is already playing an Niven-Jenkins, et al. Expires January 2, 2009 [Page 4] Internet-Draft MPLS-TP Requirements July 2008 important role in transport networks and services. However, not all of MPLS's capabilities and mechnisms are needed and/or consistent with transport network operations. This document identifies the required capabilities for MPLS so that it can better fit a transport role. TOM: I think you want to say "identifies the required sub-set of capabilities..." and later "potentially new ons specific for transport networks" which it seems you say two paragraphs later. Combining the packet experience of MPLS with the operational experience of SONET/SDH constitutes a packet transport technology named MPLS-TP. MPLS-TP will enable the migration of SONET/SDH networks to a packet-based network that will easily scale to support packet services in a simple and cost effective way. MPLS-TP needs to combine the necessary existing capabilities of MPLS with additional minimal mechanisms in order to meet the requirements described in this document. The requirements of an MPLS transport profile are provided below. TOM: There is a terminology issue in the use of "MPLS-TP" or "an MPLS transport profile". That is, on the one hand you refer to a technology, but on the other hand you are referring to a specific profile. Which is it? 2. MPLS-TP Requirements 2.1. General requirements o MPLS-TP MUST offer as much commonality as possible with the MPLS user plane as defined by IETF. When MPLS offers multiple options in this respect, MPLS-TP SHOULD select the minimum sub-set (necessary and sufficient subset) applicable to a transport network application. o Any new functionality that is defined to fulfil the requirements for MPLS-TP MUST be agreed within IETF and re-use (as far as practically possible) existing MPLS standards. o Mechanisms and capabilities MUST be able to interoperate with existing MPLS and PWE control and data planes where appropriate. TOM: Change PWE to "IETF PWE3" and "MPLS" to "IETF MPLS". There also need to be references here to the PWE3 architecture and MPLS architectures. o MPLS-TP MUST support traffic engineering capabilities that allow deterministic control of the use of network resources. o MPLS-TP MUST support the logical separation of the control and management planes from the user plane. o MPLS-TP SHOULD support the physical separation of the control and management planes from the user plane. o MPLS-TP MUST support point to point (P2P) or point to multipoint (P2MP) connections. TOM: Are we avoiding MP2MP consciously or was it left out? Niven-Jenkins, et al. Expires January 2, 2009 [Page 5] Internet-Draft MPLS-TP Requirements July 2008 o MPLS-TP MUST support static provisioning of connections via an NMS/OSS (i.e. via the management plane). o Static provisioning MUST not depend on routing or signaling protocols (e.g. GMPLS, OSPF, IS-IS, RSVP, BGP, LDP etc.). o MPLS-TP connections MAY be able to be provisioned dynamically via a control plane. TOM: I insist that we change the MAY above to MUST. I want a dynamic version of this as much as a static one. o The MPLS-TP data plane MUST be capable of functioning independently of the control or management plane used to operate the MPLS-TP layer network. That is the MPLS-TP data plane operation MUST continue to operate normally if the management plane or control plane that configured the connections fails. o MPLS-TP MUST support any network topology and be able to support increasing bandwidth demands, topology, number of customers or number of services incrementally. TOM: I think it is imperative that although an MPLS-TP is defined to play nicely with an MPLS one, it is imperative that one can distinguish between both, at least at the control plane, but perhaps at the data plane as well. 2.2. Layering requirements o An MPLS-TP network MUST operate in a multiple layer network environment consisting of the following independent layers: 1. A "service layer" instance in which the connections carry the customer's (individual or bundled) service (may be point-to- point, point-to-multipoint or multipoint-to-multipoint services); 2. A "trunk layer" with point-to-point or point-to-multipoint connections which are used to carry aggregates of the network "service layer" connections; and 3. A "transmission media layer" which provides sections (two-port point-to-point connections) to carry the aggregate of network trunk or network service connections on various physical media. TOM: This stuff belongs in the Terminology section at the top. MPLS-TP may provide the "service layer" (for P2P and P2MP services) and/or the "trunk layer" within a layer network environment. o An MPLS-TP layer network MUST support the transparent transport of MPLS-TP and non MPLS-TP client layer networks. o An MPLS-TP layer network MUST be able to be transparently carried over MPLS-TP and non MPLS-TP server layer networks (such as Ethernet, OTN, etc.) Niven-Jenkins, et al. Expires January 2, 2009 [Page 6] Internet-Draft MPLS-TP Requirements July 2008 o It MUST be possible to operate the MPLS-TP layer network independently of other layer networks (either MPLS-TP or non MPLS-TP). This is not only a technology requirement, different administrative groups may be responsible for different layer networks (even when they are of the same type)), and require the capability to operationally support the different layers. o It MUST be possible to hide MPLS-TP layer network addressing and other information (e.g. topology) from client layers. 2.3. Data plane requirements o The identification of each connection within its aggregate MUST be supported. o A label in a particular section MUST uniquely identify the connection. o A connection's source MUST be identifiable at its destination. Connections can be aggregated into trunks by pushing and de- aggregated by popping labels. MPLS-TP labels may be swapped within a connection in a layer network instance when the traffic is forwarded from one MPLS-TP link connection to another MPLS-TP link connection. o Labelling MUST make use of the MPLS label and label stack entry as defined in RFC3032. o It MUST be possible to operate and configure the MPLS-TP data (transport) plane without any IP functionality. o MPLS-TP MUST support both unidirectional and bi-directional point- to-point connections. o The forward and backward directions of a bi-directional connection SHOULD follow the same path within the MPLS-TP network. TOM: I am not sure if we say that they SHOULD as much as "they MUST be capable of". o The intermediate nodes SHOULD be aware about the binding of the forward and the backward directions belonging to the same bi- directional connection. TOM: Again, "SHOULD be capable of" seems better. o MPLS-TP SHOULD support unidirectional point-to-multipoint connections. o MPLS-TP connections MUST NOT perform merging in a way that prevents the unique identification of the source at the Niven-Jenkins, et al. Expires January 2, 2009 [Page 7] Internet-Draft MPLS-TP Requirements July 2008 destination (e.g. no use of LDP mp2p signaling in order to avoid losing LSP head-end information, no use of PHP, etc). o MPLS-TP SHOULD support transport and QoS mechanisms that can deliver statistical multiplexing gain. Packets exceeding the agreed traffic profile may be marked or discarded by the traffic conditioning at the ingress of the MPLS-TP network. TOM: How about egress policing + marking? o MPLS-TP MUST support connections through a single domain. o MPLS-TP SHOULD support connections through multiple domains. o MPLS-TP MUST be able to accommodate new traffic types. TOM: New traffic types other than those supported by MPLS? This doesn't make sense to me as this will result in MPLS-TP not being a subset of MPLS. o MPLS-TP SHOULD support mechanisms to safeguard against the provisioning of connections which contain forwarding loops. o MPLS-TP SHOULD support mechanisms to minimize traffic impact during network reconfiguration. o MPLS-TP SHOULD support mechanisms which ensure the integrity of the adapted information. o MPLS-TP MUST support an unambiguous and reliable means of distinguishing users' (client) packets from MPLS-TP control plane and management plane packets. 2.4. Control plane requirements o A distributed control plane MAY be supported to enable fast, dynamic and reliable service provisioning in multi-vendor and multi-domain environments using standardized protocols that guarantee interoperability. o If a control plane is used for configuration of MPLS-TP connections then: * Failure and recovery of the control plane MUST NOT impact the MPLS-TP forwarding plane. TOM: This is difficult, as this really is handled in practice at both data and control planes, depending on how this is configured/designed, and the re-signaling can impact the data plane. * It MUST support the setup, modification, and release of MPLS-TP connections and protection connections. * It MUST support mechanisms to provide traffic engineering, constraint-based routing and explicit path control. * It MUST provide mechanisms to address QoS and performance requirements (such as throughput, delay, packet loss, etc.) Niven-Jenkins, et al. Expires January 2, 2009 [Page 8] Internet-Draft MPLS-TP Requirements July 2008 while utilizing network resources efficiently and reliably. o MPLS-TP SHOULD support off-path (out-of-band) control and management planes. o The MPLS-TP control plane MUST be independent of any particular client or server layer control plane. o The control plane SHOULD facilitate the implementation of the service by providing end-to-end seamless connectivity and service assurance. o The MPLS-TP control plane MUST support establishing all the connectivity patterns defined for the MPLS-TP transport plane (e.g., uni-directional and bidirectional P2P, uni-directional P2MP, etc.) including configuration of protection functions and any associated maintenance functions. o The MPLS-TP control pane must support the configuration and modification of OAM maintenance points as well as the activation/ deactivation of OAM when the connection is established or modified. o An MPLS-TP control plane MUST support topology hiding and address independence between domains. o At the boundary of a domain an MPLS-TP control plane MUST support unique names or addresses identifying boundary points to be interconnected. o At the boundary of a domain an MPLS-TP control plane must support group names or addresses identifying sets of boundary points to be interconnected. o MPLS-TP layer network access points (or connection points that proxy for access points) SHOULD be able to be assigned names which are available to clients to identify endpoints in call or connection requests. o An MPLS-TP control plane MUST support translation between externally visible endpoint names and internal network addresses. o An MPLS-TP control plane MUST support constraint-based route calculation. o An MPLS-TP control plane MUST support provisioning and application of routing constraint policies. Niven-Jenkins, et al. Expires January 2, 2009 [Page 9] Internet-Draft MPLS-TP Requirements July 2008 o An MPLS-TP control plane MUST support pre-provisioned connection protection. In some situations it is impractical to expect acceptable recovery performance to be achieved using dynamic recalculation of connection routes. For this reason, it is necessary to allow for pre-planning of protection routes for selected connections. o The MPLS-TP control plane MUST support fast restoration. TOM: Define what "fast" means? o An MPLS-TP control plane MUST scale gracefully to support a large number of connections. TOM: Define "large" and "scale" here? [Include some numbers to indicate how large the CP is expected to scale to?] o An MPLS-TP control plane MUST clearly distinguish resources belonging to the MPLS-TP layer network from those in other layer networks that may also be under control plane control. TOM: Do you mean under the same control plane or a different one (or both)? o An MPLS-TP control plane MUST support the independent identification of logically distinct control plane elements. o It MUST be possible to identify and provision these elements independently, in order to reorganize the control plane components without impacting the data plane services and vice-versa. Architecturally distinct elements in a control plane include: nodes and links, control plane functional components, protocol controllers, etc. o An MPLS-TP control plane SHOULD provide a common control mechanism for architecturally similar operations. o An MPLS-TP control plane MUST support mechanisms for partitioning the network under control into separate peer or hierarchical control domains. o To enable the deployment of a unified control plane aimed at controlling the set of transport technologies used in a transport network, the MPLS-TP control plane MUST also be applicable to other transport layer networks and provide common operations across multiple layers. In order to maintain independence between MPLS-TP and its respective client and server layer network separate control plane instances SHOULD be used to control a set of transport layer networks. Niven-Jenkins, et al. Expires January 2, 2009 [Page 10] Internet-Draft MPLS-TP Requirements July 2008 o MPLS-TP SHOULD detect and recover from control plane failures and degradations using graceful operations. 2.5. Network Management (NM) requirements o MPLS-TP MUST operate under a common operation, control and management paradigm with respect to other transport technologies (e.g. SDH, OTN or WDM). o An MPLS-TP network MUST be able to be operated with a centralized NMS system. o An MPLS-TP network SHOULD be able to be operated by a centralized NMS system with the support of a distributed control plane. TOM: I don't know what this means or the one above it, or how this requirement would translate into anything tangible in the MPLS-TP protocol designs. I suggest it be removed. o The MPLS-TP management plane MUST NOT depend on a specific client layer management plane. TOM: This is a non-sequitur if you ask me; please strike it. o The MPLS-TP management plane MUST support the configuration and modification of OAM maintenance points as well as the activation/ deactivation of OAM when the connection is established or modified. For the complete set of requirements related to NM functionality for MPLS-TP, see the MPLS-TP NM requirements document [REF]. 2.6. OAM requirements o MPLS-TP SHOULD provide a comprehensive set of capabilities (that are independent of and agnostic to the transmitted client services) to support fault management, performance monitoring (of the MPLS-TP network and the services), protection switching, fault localization, signal quality measurement, etc. o A mechanism SHOULD be supported to detect, diagnose and enable recovery from facility and equipment failures and performance degradations according to the requirements of the service. o MPLS-TP OAM MUST be able to operate without IP functionality and without relying on control and/or management planes. For the complete set of requirements related to OAM functionality for MPLS-TP, see the MPLS-TP OAM requirements document [REF]. TOM: I suggest you just remove these two sections and refer to the OAM/Managemetn documents. 2.7. Network performance management (PM) requirements Niven-Jenkins, et al. Expires January 2, 2009 [Page 11] Internet-Draft MPLS-TP Requirements July 2008 o MPLS-TP MUST support traffic-engineering capabilities with traffic- and/or resource-oriented performance objectives. TOM: What are performance objectives? Do you mean traffic profiles such as QoS/bandwidth? o MPLS-TP MUST support a method to offer packet loss objectives comparable to those in TDM transport networks (only due to bit errors). For the complete set of requirements related to PM functionality for MPLS-TP, see the MPLS-TP OAM requirements document [REF]. TOM: Again, I suggest you punt on this entire section and move it to the OAM doc. 2.8. Protection & Survivability requirements Network survivability plays a critical factor in the delivery of reliable services. Network availability is a significant contributor to revenue and profit. Service guarantees in the form of SLAs require a resilient network that rapidly detects facility or node failures and restores network operation in accordance with the terms of the SLA. The requirements in this section use of the recovery terminology defined in RFC 4427[RFC4427]. o MPLS-TP SHOULD support transport network style protection TOM: I would make this a MUST. switching mechanisms (tandem network connection protection, LSP protection and PW protection) to provide the sub-50ms recovery time required to maintain customer transparency, even when thousands of services are simultaneously affected by a failure. [Is sub-50ms really a requirement, do we want to clarify this further - is it sub-50ms end to end, or per link?] o * MPLS-TP recovery mechanisms SHOULD be applicable at various levels throughout the network, SPAN, tandem connection and end- to-end. TOM: This sentence doesn't parse. Please re-write. Any recovery mechanism used in a tandem connection MUST be independent of other tandem connections. * MPLS-TP SHOULD support mechanisms that keep traffic flowing while the network recovers from failures. TOM: I would say this is a MUST. * MPLS-TP SHOULD support network restoration mechanisms controlled by a distributed control plane and/or by a management plane based. TOM: I would say this is a MUST. * + The restoration resources MAY be pre-planned and selected a priori, or computed after failure occurrence. Niven-Jenkins, et al. Expires January 2, 2009 [Page 12] Internet-Draft MPLS-TP Requirements July 2008 + MPLS-TP MAY support shared-mesh restoration. + MPLS-TP SHOUD support soft LSP restoration. + MPLS-TP MAY support hard LSP restoration. + The restoration mechanism MUST be applicable to any topology. + Restoration priority MAY be implemented to determine the order in which connections should be restored (to minimize service restoration time as well as to gain access to available spare capacity on the best paths). Preemption priority MAY be used in the event that not all connections can be restored, in which case connections with lower preemption priority should be released. + The restoration mechanism SHOULD operate in synergy with other transport network technologies (SDH, OTN, WDM). * MPLS-TP SHOULD support data plane driven protection mechanisms (without any dependency on a control plane or IP protocols) to enable fast recovery from failure, and thereby to enhance the reliability and availability performance of MPLS-TP networks. * + MPLS-TP protection mechanisms SHOULD be applied to LSPs and PWs. + MPLS-TP MUST support mechanisms that rapidly detect, locate, notify and remedy network faults. + MPLS-TP MUST support 1:1 bidirectional protection switching. The protection state of both ends of the protected entity MUST be synchronized. + MPLS-TP MAY support 1+1 unidirectional protection switching. + MPLS-TP protection mechanisms MUST be applicable to both point-to-point and point-to-multipoint connections. + It SHOULD be possible to achieve protection at the MPLS-TP layer as fast as possible (subject to the temporal resolution of the defect detection mechanism). + Protection ratio MUST be of 100%, i.e., 100% of impaired working traffic MUST be protected for a failure on a single Niven-Jenkins, et al. Expires January 2, 2009 [Page 13] Internet-Draft MPLS-TP Requirements July 2008 working LSP. + Operator requests for manual control of protection switching such as clear, lockout of protection, forced-switch and manual-switch commands MUST be supported. Prioritized protection between Signal Fail (SF), Signal Degradation (SD) and operator switch requests MUST be supported. + MPLS-TP protection mechanisms MUST support revertive and non-revertive behaviour. o An extra traffic capability SHOULD be supported when possible. + MPLS-TP protection switching mechanisms MUST prevent frequent operation of the protection switch due to an intermittent defect. + MPLS-TP protection mechanisms MUST ensure co-ordination of timing of protection switches at multiple layers to avoid races and to allow the protection switching mechanism of the server layer to fix the problem before switching at the MPLS-TP layer. + MPLS-TP MAY support mechanisms that are optimized for specific network topologies (Ring, Mesh) in order to handle protection switching in a cost-efficient manner. 2.9. QoS requirements Service providers require advanced traffic management capabilities to enforce and guarantee the QoS parameters of customers' SLAs. Quality of service mechanisms are required to ensure: o Support for differentiated services and different traffic types with traffic class separation associated with different traffic. o Prioritization of critical services. o Enabling the provisioning and the guarantee of Service Level Specifications (SLS), with support for hard and relative end-to- end BW guaranteed. o Controlled jitter and delay. o Guarantee of fair access to shared resources in an MPLS-TP network. Niven-Jenkins, et al. Expires January 2, 2009 [Page 14] Internet-Draft MPLS-TP Requirements July 2008 o Ability for OAM and data to share the same fate. TOM: This belongs in the OAM document. o Resources for control and management plane packets so that user plane traffic, regardless of the amount, will not cause control and management functions to become inoperative. The following QoS requirements apply to MPLS-TP: o MPLS-TP MUST be able to deliver the same degree of QoS that has been delivered by SDH/SONET systems. TOM: We can save on a lot of text and remove the "MPLS-TE MUST" or "MPLS-TP SHOULD" bits and simply say "MUST X" or "SHOULD Y". The MPLS-TP bit is implicit I think. o MPLS-TP MUST support transport bandwidth allocation to any granularity without any restrictions based on a circuit-switched multiplexing hierarchy. This attribute will provide service providers with the capability to route more customer service demands over the MPLS-TP network. [Should we refer here to the requirements specified in RFC 2702?] 2.10. Security requirements o MPLS-TP MUST ensure that the network and services are secured. o Traffic flows from different users MUST NOT be intermingled, but if this does occur then this MUST be detectable and the appropriate consequent actions taken. o MPLS-TP MUST ensure the separation of customer (client) and provider (server and peer network) addressing and other information. TOM: This requirement is stated above. o MPLS-TP MUST ensure that the control and management planes as well as OAM traffic are secure from external attack. o MPLS-TP MUST provide mechanisms to ensure that the MPLS-TP network remains secure and stable under situations of extreme stress. Examples of attacks and situations of extreme stress include (but are not limited to) classical security attacks (e.g., hijacking, privacy, non-repudiation, etc.) and attacks on network availability (e.g., denial of service (DoS) attacks). 3. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an Niven-Jenkins, et al. Expires January 2, 2009 [Page 15] Internet-Draft MPLS-TP Requirements July 2008 RFC. 4. Security Considerations This document does not by itself raise any particular security considerations. 5. Acknowledgements The authors wish to thank Neil Harrison and Tomonori Takeda for their review and enhancements to the text. 6. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4427, March 2006. [ITU.Y1401.2008] International Telecommunications Union, "Principles of interworking", ITU-T Recommendation Y.1401, February 2008. Authors' Addresses Ben Niven-Jenkins (editor) BT 208 Callisto House, Adastral Park Ipswich, Suffolk IP5 3RE UK Email: benjamin.niven-jenkins@bt.com Deborah Brungard (editor) AT&T Rm. D1-3C22 - 200 S. Laurel Ave. Middletown, NJ 07748 USA Email: dbrungard@att.com Niven-Jenkins, et al. Expires January 2, 2009 [Page 16] Internet-Draft MPLS-TP Requirements July 2008 Malcolm Betts (editor) Nortel Networks 3500 Carling Avenue Ottawa, Ontario K2H 8E9 Canada Email: betts01@nortel.com Nurit Sprecher Nokia Siemens Networks 3 Hanagar St. Neve Ne'eman B Hod Hasharon, 45241 Israel Email: nurit.sprecher@nsn.com Niven-Jenkins, et al. Expires January 2, 2009 [Page 17] Internet-Draft MPLS-TP Requirements July 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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, THE IETF TRUST 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. Intellectual Property 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. Niven-Jenkins, et al. Expires January 2, 2009 [Page 18] _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop From mpls-interop-bounces@ietf.org Sun Jun 22 02:46:05 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC79A3A67D4; Sun, 22 Jun 2008 02:46:04 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDE353A693D for ; Sun, 22 Jun 2008 02:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.834, BAYES_50=0.001, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21HseW3+6R89 for ; Sun, 22 Jun 2008 02:45:59 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 14ACB3A67D4 for ; Sun, 22 Jun 2008 02:45:57 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m5M9jxsP017929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Jun 2008 11:45:59 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m5M9jvYP008291; Sun, 22 Jun 2008 11:45:57 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 22 Jun 2008 11:45:57 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 22 Jun 2008 11:45:49 +0200 Message-ID: <9FF5BDAD88B9D84881609E89AC92FB83EBD380@DEMUEXC014.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mpls-interop] next MEAD team meeting Thread-Index: AcjSMNQsx4BuurjX8EeQxIcfmO8exAA0/R+VAEuIunA= From: "Sprecher, Nurit (NSN - IL/Israel - MiniMD)" To: "ext Thomas Nadeau" , "Ben Niven-Jenkins" , "Loa Andersson" , "MEAD team" X-OriginalArrivalTime: 22 Jun 2008 09:45:57.0046 (UTC) FILETIME=[C528FD60:01C8D44C] Cc: "Weingarten, Yaacov \(NSN - IL/Israel - MiniMD\)" Subject: Re: [Mpls-interop] next MEAD team meeting X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org Hi Thomas, Thanks for your comments. I still need to get into the details and meanings of your comments, but in the meantime I have one basic concern on your comment on " MPLS-TP connections MAY be able to be provisioned dynamically via a control plane. TOM: I insist that we change the MAY above to MUST. I want a dynamic version of this as much as a static one." This is one of the fundamental principles of the MPLS-TP, that the presence of a distributed control plane in support of network operations is optional (as in other transport technologies, like in SDH, etc.). This is also the trigger for the definition of OAM capabilities which are independent of a control plane, as well as of the protection switching, etc. This is also addressed by the slides of the JW: "Desire to statically configure LSPs and PWEs via the management plane... Transport OAM capabilities don't exist for LSP and PWE independent of configuration mechanism (management plane or GMPLS or PWE control plane)...With static provisioning, no dependency on routing or signaling (e.g. GMPLS or, IGP, RSVP, BGP, LDP)", etc. Best regards, Nurit -----Original Message----- From: mpls-interop-bounces@ietf.org [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext Thomas Nadeau Sent: Friday, June 20, 2008 21:38 To: Ben Niven-Jenkins; Loa Andersson; MEAD team Subject: Re: [Mpls-interop] next MEAD team meeting Comments on the document inline start with "TOM:" In general, please review the document and put more of an emphasis on the use of "MUST" rather than "MAY" or "SHOULD". The IETG frowns on requirements documents that are too optional. --Tom Network Working Group B. Niven-Jenkins, Ed. Internet-Draft BT Intended status: Informational D. Brungard, Ed. Expires: January 2, 2009 AT&T M. Betts, Ed. Nortel Networks N. Sprecher Nokia Siemens Networks July 01, 2008 MPLS-TP Requirements draft-jenkins-mpls-mplstp-requirements-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on January 2, 2009. Abstract This document will outline the requirements for MPLS-TP. Requirements Language 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 [RFC2119]. Niven-Jenkins, et al. Expires January 2, 2009 [Page 1] Internet-Draft MPLS-TP Requirements July 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. MPLS-TP Requirements . . . . . . . . . . . . . . . . . . . . . 5 2.1. General requirements . . . . . . . . . . . . . . . . . . . 5 2.2. Layering requirements . . . . . . . . . . . . . . . . . . 6 2.3. Data plane requirements . . . . . . . . . . . . . . . . . 7 2.4. Control plane requirements . . . . . . . . . . . . . . . . 8 2.5. Network Management (NM) requirements . . . . . . . . . . . 11 2.6. OAM requirements . . . . . . . . . . . . . . . . . . . . . 11 2.7. Network performance management (PM) requirements . . . . . 11 2.8. Protection & Survivability requirements . . . . . . . . . 12 2.9. QoS requirements . . . . . . . . . . . . . . . . . . . . . 14 2.10. Security requirements . . . . . . . . . . . . . . . . . . 15 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 6. Informative References . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 18 Niven-Jenkins, et al. Expires January 2, 2009 [Page 2] Internet-Draft MPLS-TP Requirements July 2008 1. Introduction For many years, SONET/SDH has provided service providers with a high benchmark for reliability and operational simplicity. With the accelerating growth of packet-based services (such as Ethernet, VoIP, L2/L3 VPN, IPTV, RAN backhauling, etc.), service providers are in need of capabilities to efficiently support packet-based services on their transport networks. The need to increase their revenue while remaining competitive forces operators to look for the lowest network Total Cost of Ownership (TCO). Investment in both Capital Expenditure (CAPEX) and Operational Expense (OPEX) should be minimal. Carriers are considering migrating to packet transport networks in order to reduce their costs and to improve their ability to support services with guaranteed SLAs. Migrating from SONET/SDH to packet transport networks should not involve dramatic changes in network operation, should not necessitate extensive retraining, and should not require major changes to existing work practices. The aim is to preserve the look-and-feel to which carriers have become accustomed in deploying their SONET/SDH networks, while providing common, multi- layer operations, resiliency, control and management for packet, circuit and lambda transport networks. An important attribute of a transport network is its ability to function independently from both its client and server (transmission media) layer networks. It should be capable of transmitting over any media. Another key characteristic of transport networks is the capability to maintain the integrity of the client signal between its ingress and egress ports. TOM: I would use something other than "client signal" here. Something like "client path" or something is what I think you mean. A transport network must provide the means to commit quality of service objectives to clients. This is achieved by providing a mechanism for client network service demarcation for the network path together with an associated network resiliency mechanism. A transport network must also provide a method of service monitoring in order to verify the delivery of an agreed quality of service. This is enabled by means of carrier-grade OAM tools. The connectivity service is the basic service provided by a transport network. TOM: Is it? Does the transport really provide connections or does it provide transport paths? I am sensitive to the terms used here. We don't want this to become a connect-fest. Seems to me that you explain this better in the next sentence anyhow. The purpose of a transport network is to transparently carry client signals (i.e. the stream of client PDUs or client bits) TOM: Again, I don't like the term "signals" here. Use "client data" or something. between endpoints in the network (typically over several intermediate nodes). These endpoints may be service switching points or service terminating points. The connectivity services offered to customers are aggregated into large, long-holding time pipes/trunks which TOM: Do you really mean to call these "time pipes"? Sounds too futuristic even for this work. *) I think you mean "...into relatively large, long-lasting paths..." enable the efficient and reliable operation of the transport network. These trunks are modified infrequently. TOM: Keep the terminology consistent here too. There is the use of "trunks", "pipes", etc... Aggregation and hierarchy are beneficial for achieving scalability and security since: Niven-Jenkins, et al. Expires January 2, 2009 [Page 3] Internet-Draft MPLS-TP Requirements July 2008 1. They reduce the number of provisioning and forwarding states in the network core. 2. They reduce load and the cost of implementing service assurance and fault management. TOM: Do they really reduce load? This is one of those fluffy, open-ended terms like "scaleability" that I don't like used unless it is clearly defined. 3. Client signals are completely encapsulated and isolated from each other. This also allows complete isolation of customer traffic from carrier operations. TOM: Does this really happen at the data or control plane or both? Or do we care? Client signals are first transparently encapsulated. These encapsulated client signals are then aggregated for transport through the network in order to optimize network management. Server layer OAM is used to monitor the transport integrity of the client layer aggregate. At any hop, the aggregated signals may be further aggregated in lower layer transport network paths for transport across intermediate shared links. The encapsulated client signals are extracted at the edges of aggregation domains, and are either delivered to the client or forwarded to another domain. In the core of the network, only the server layer aggregated signals are monitored; individual client signals are monitored at the network boundary in the client layer network. TOM: I am not sure the above is appropriate for a requirements document. It sounds like you are spelling out an algorithm for how a solution should work. Quality-of-service mechanisms are required in the packet transport network to ensure the prioritization of critical services, to guarantee BW and to control jitter and delay. TOM: Are they required everywhere the service exists, or say just at the ingress/egress for policing/marking functions? While we are on the subject, do we want to be more specific about QoS requirements? Service providers require control and deterministic usage of network resources. They need end-to-end control to engineer network paths and to efficiently utilize network resources. They require capabilities to statically (OSS based) provision deterministic, protected and secured services and their associated resources as well as alternative control-plane options. TOM: They also require dynamic ones. Please put that in. I don't want to be asking for only a completely static system. The transport network must be capable of transporting multiple services in a scalable manner. TOM: Again, this use of "scalable" offends me. Please be more specific or take the sentence out as it is meaningless as stated. Carriers will still need to cope with legacy networks (which are composed of many layers and technologies), thus the packet transport network should interwork with other packet and transport networks (both horizontally and vertically). Vertical interworking is also known as client/server or network interworking. Horizontal interworking is also known as peer-partition or service interworking. TOM: Didn't you just say that vertical interworking was client interworking in the first sentence? How can horizontal be service interworking as well? For more details on each type of interworking and some of the issues that may arise (especially with horizontal interworking) see [ITU.Y1401.2008]. MPLS is a maturing packet technology and it is already playing an Niven-Jenkins, et al. Expires January 2, 2009 [Page 4] Internet-Draft MPLS-TP Requirements July 2008 important role in transport networks and services. However, not all of MPLS's capabilities and mechnisms are needed and/or consistent with transport network operations. This document identifies the required capabilities for MPLS so that it can better fit a transport role. TOM: I think you want to say "identifies the required sub-set of capabilities..." and later "potentially new ons specific for transport networks" which it seems you say two paragraphs later. Combining the packet experience of MPLS with the operational experience of SONET/SDH constitutes a packet transport technology named MPLS-TP. MPLS-TP will enable the migration of SONET/SDH networks to a packet-based network that will easily scale to support packet services in a simple and cost effective way. MPLS-TP needs to combine the necessary existing capabilities of MPLS with additional minimal mechanisms in order to meet the requirements described in this document. The requirements of an MPLS transport profile are provided below. TOM: There is a terminology issue in the use of "MPLS-TP" or "an MPLS transport profile". That is, on the one hand you refer to a technology, but on the other hand you are referring to a specific profile. Which is it? 2. MPLS-TP Requirements 2.1. General requirements o MPLS-TP MUST offer as much commonality as possible with the MPLS user plane as defined by IETF. When MPLS offers multiple options in this respect, MPLS-TP SHOULD select the minimum sub-set (necessary and sufficient subset) applicable to a transport network application. o Any new functionality that is defined to fulfil the requirements for MPLS-TP MUST be agreed within IETF and re-use (as far as practically possible) existing MPLS standards. o Mechanisms and capabilities MUST be able to interoperate with existing MPLS and PWE control and data planes where appropriate. TOM: Change PWE to "IETF PWE3" and "MPLS" to "IETF MPLS". There also need to be references here to the PWE3 architecture and MPLS architectures. o MPLS-TP MUST support traffic engineering capabilities that allow deterministic control of the use of network resources. o MPLS-TP MUST support the logical separation of the control and management planes from the user plane. o MPLS-TP SHOULD support the physical separation of the control and management planes from the user plane. o MPLS-TP MUST support point to point (P2P) or point to multipoint (P2MP) connections. TOM: Are we avoiding MP2MP consciously or was it left out? Niven-Jenkins, et al. Expires January 2, 2009 [Page 5] Internet-Draft MPLS-TP Requirements July 2008 o MPLS-TP MUST support static provisioning of connections via an NMS/OSS (i.e. via the management plane). o Static provisioning MUST not depend on routing or signaling protocols (e.g. GMPLS, OSPF, IS-IS, RSVP, BGP, LDP etc.). o MPLS-TP connections MAY be able to be provisioned dynamically via a control plane. TOM: I insist that we change the MAY above to MUST. I want a dynamic version of this as much as a static one. o The MPLS-TP data plane MUST be capable of functioning independently of the control or management plane used to operate the MPLS-TP layer network. That is the MPLS-TP data plane operation MUST continue to operate normally if the management plane or control plane that configured the connections fails. o MPLS-TP MUST support any network topology and be able to support increasing bandwidth demands, topology, number of customers or number of services incrementally. TOM: I think it is imperative that although an MPLS-TP is defined to play nicely with an MPLS one, it is imperative that one can distinguish between both, at least at the control plane, but perhaps at the data plane as well. 2.2. Layering requirements o An MPLS-TP network MUST operate in a multiple layer network environment consisting of the following independent layers: 1. A "service layer" instance in which the connections carry the customer's (individual or bundled) service (may be point-to- point, point-to-multipoint or multipoint-to-multipoint services); 2. A "trunk layer" with point-to-point or point-to-multipoint connections which are used to carry aggregates of the network "service layer" connections; and 3. A "transmission media layer" which provides sections (two-port point-to-point connections) to carry the aggregate of network trunk or network service connections on various physical media. TOM: This stuff belongs in the Terminology section at the top. MPLS-TP may provide the "service layer" (for P2P and P2MP services) and/or the "trunk layer" within a layer network environment. o An MPLS-TP layer network MUST support the transparent transport of MPLS-TP and non MPLS-TP client layer networks. o An MPLS-TP layer network MUST be able to be transparently carried over MPLS-TP and non MPLS-TP server layer networks (such as Ethernet, OTN, etc.) Niven-Jenkins, et al. Expires January 2, 2009 [Page 6] Internet-Draft MPLS-TP Requirements July 2008 o It MUST be possible to operate the MPLS-TP layer network independently of other layer networks (either MPLS-TP or non MPLS-TP). This is not only a technology requirement, different administrative groups may be responsible for different layer networks (even when they are of the same type)), and require the capability to operationally support the different layers. o It MUST be possible to hide MPLS-TP layer network addressing and other information (e.g. topology) from client layers. 2.3. Data plane requirements o The identification of each connection within its aggregate MUST be supported. o A label in a particular section MUST uniquely identify the connection. o A connection's source MUST be identifiable at its destination. Connections can be aggregated into trunks by pushing and de- aggregated by popping labels. MPLS-TP labels may be swapped within a connection in a layer network instance when the traffic is forwarded from one MPLS-TP link connection to another MPLS-TP link connection. o Labelling MUST make use of the MPLS label and label stack entry as defined in RFC3032. o It MUST be possible to operate and configure the MPLS-TP data (transport) plane without any IP functionality. o MPLS-TP MUST support both unidirectional and bi-directional point- to-point connections. o The forward and backward directions of a bi-directional connection SHOULD follow the same path within the MPLS-TP network. TOM: I am not sure if we say that they SHOULD as much as "they MUST be capable of". o The intermediate nodes SHOULD be aware about the binding of the forward and the backward directions belonging to the same bi- directional connection. TOM: Again, "SHOULD be capable of" seems better. o MPLS-TP SHOULD support unidirectional point-to-multipoint connections. o MPLS-TP connections MUST NOT perform merging in a way that prevents the unique identification of the source at the Niven-Jenkins, et al. Expires January 2, 2009 [Page 7] Internet-Draft MPLS-TP Requirements July 2008 destination (e.g. no use of LDP mp2p signaling in order to avoid losing LSP head-end information, no use of PHP, etc). o MPLS-TP SHOULD support transport and QoS mechanisms that can deliver statistical multiplexing gain. Packets exceeding the agreed traffic profile may be marked or discarded by the traffic conditioning at the ingress of the MPLS-TP network. TOM: How about egress policing + marking? o MPLS-TP MUST support connections through a single domain. o MPLS-TP SHOULD support connections through multiple domains. o MPLS-TP MUST be able to accommodate new traffic types. TOM: New traffic types other than those supported by MPLS? This doesn't make sense to me as this will result in MPLS-TP not being a subset of MPLS. o MPLS-TP SHOULD support mechanisms to safeguard against the provisioning of connections which contain forwarding loops. o MPLS-TP SHOULD support mechanisms to minimize traffic impact during network reconfiguration. o MPLS-TP SHOULD support mechanisms which ensure the integrity of the adapted information. o MPLS-TP MUST support an unambiguous and reliable means of distinguishing users' (client) packets from MPLS-TP control plane and management plane packets. 2.4. Control plane requirements o A distributed control plane MAY be supported to enable fast, dynamic and reliable service provisioning in multi-vendor and multi-domain environments using standardized protocols that guarantee interoperability. o If a control plane is used for configuration of MPLS-TP connections then: * Failure and recovery of the control plane MUST NOT impact the MPLS-TP forwarding plane. TOM: This is difficult, as this really is handled in practice at both data and control planes, depending on how this is configured/designed, and the re-signaling can impact the data plane. * It MUST support the setup, modification, and release of MPLS-TP connections and protection connections. * It MUST support mechanisms to provide traffic engineering, constraint-based routing and explicit path control. * It MUST provide mechanisms to address QoS and performance requirements (such as throughput, delay, packet loss, etc.) Niven-Jenkins, et al. Expires January 2, 2009 [Page 8] Internet-Draft MPLS-TP Requirements July 2008 while utilizing network resources efficiently and reliably. o MPLS-TP SHOULD support off-path (out-of-band) control and management planes. o The MPLS-TP control plane MUST be independent of any particular client or server layer control plane. o The control plane SHOULD facilitate the implementation of the service by providing end-to-end seamless connectivity and service assurance. o The MPLS-TP control plane MUST support establishing all the connectivity patterns defined for the MPLS-TP transport plane (e.g., uni-directional and bidirectional P2P, uni-directional P2MP, etc.) including configuration of protection functions and any associated maintenance functions. o The MPLS-TP control pane must support the configuration and modification of OAM maintenance points as well as the activation/ deactivation of OAM when the connection is established or modified. o An MPLS-TP control plane MUST support topology hiding and address independence between domains. o At the boundary of a domain an MPLS-TP control plane MUST support unique names or addresses identifying boundary points to be interconnected. o At the boundary of a domain an MPLS-TP control plane must support group names or addresses identifying sets of boundary points to be interconnected. o MPLS-TP layer network access points (or connection points that proxy for access points) SHOULD be able to be assigned names which are available to clients to identify endpoints in call or connection requests. o An MPLS-TP control plane MUST support translation between externally visible endpoint names and internal network addresses. o An MPLS-TP control plane MUST support constraint-based route calculation. o An MPLS-TP control plane MUST support provisioning and application of routing constraint policies. Niven-Jenkins, et al. Expires January 2, 2009 [Page 9] Internet-Draft MPLS-TP Requirements July 2008 o An MPLS-TP control plane MUST support pre-provisioned connection protection. In some situations it is impractical to expect acceptable recovery performance to be achieved using dynamic recalculation of connection routes. For this reason, it is necessary to allow for pre-planning of protection routes for selected connections. o The MPLS-TP control plane MUST support fast restoration. TOM: Define what "fast" means? o An MPLS-TP control plane MUST scale gracefully to support a large number of connections. TOM: Define "large" and "scale" here? [Include some numbers to indicate how large the CP is expected to scale to?] o An MPLS-TP control plane MUST clearly distinguish resources belonging to the MPLS-TP layer network from those in other layer networks that may also be under control plane control. TOM: Do you mean under the same control plane or a different one (or both)? o An MPLS-TP control plane MUST support the independent identification of logically distinct control plane elements. o It MUST be possible to identify and provision these elements independently, in order to reorganize the control plane components without impacting the data plane services and vice-versa. Architecturally distinct elements in a control plane include: nodes and links, control plane functional components, protocol controllers, etc. o An MPLS-TP control plane SHOULD provide a common control mechanism for architecturally similar operations. o An MPLS-TP control plane MUST support mechanisms for partitioning the network under control into separate peer or hierarchical control domains. o To enable the deployment of a unified control plane aimed at controlling the set of transport technologies used in a transport network, the MPLS-TP control plane MUST also be applicable to other transport layer networks and provide common operations across multiple layers. In order to maintain independence between MPLS-TP and its respective client and server layer network separate control plane instances SHOULD be used to control a set of transport layer networks. Niven-Jenkins, et al. Expires January 2, 2009 [Page 10] Internet-Draft MPLS-TP Requirements July 2008 o MPLS-TP SHOULD detect and recover from control plane failures and degradations using graceful operations. 2.5. Network Management (NM) requirements o MPLS-TP MUST operate under a common operation, control and management paradigm with respect to other transport technologies (e.g. SDH, OTN or WDM). o An MPLS-TP network MUST be able to be operated with a centralized NMS system. o An MPLS-TP network SHOULD be able to be operated by a centralized NMS system with the support of a distributed control plane. TOM: I don't know what this means or the one above it, or how this requirement would translate into anything tangible in the MPLS-TP protocol designs. I suggest it be removed. o The MPLS-TP management plane MUST NOT depend on a specific client layer management plane. TOM: This is a non-sequitur if you ask me; please strike it. o The MPLS-TP management plane MUST support the configuration and modification of OAM maintenance points as well as the activation/ deactivation of OAM when the connection is established or modified. For the complete set of requirements related to NM functionality for MPLS-TP, see the MPLS-TP NM requirements document [REF]. 2.6. OAM requirements o MPLS-TP SHOULD provide a comprehensive set of capabilities (that are independent of and agnostic to the transmitted client services) to support fault management, performance monitoring (of the MPLS-TP network and the services), protection switching, fault localization, signal quality measurement, etc. o A mechanism SHOULD be supported to detect, diagnose and enable recovery from facility and equipment failures and performance degradations according to the requirements of the service. o MPLS-TP OAM MUST be able to operate without IP functionality and without relying on control and/or management planes. For the complete set of requirements related to OAM functionality for MPLS-TP, see the MPLS-TP OAM requirements document [REF]. TOM: I suggest you just remove these two sections and refer to the OAM/Managemetn documents. 2.7. Network performance management (PM) requirements Niven-Jenkins, et al. Expires January 2, 2009 [Page 11] Internet-Draft MPLS-TP Requirements July 2008 o MPLS-TP MUST support traffic-engineering capabilities with traffic- and/or resource-oriented performance objectives. TOM: What are performance objectives? Do you mean traffic profiles such as QoS/bandwidth? o MPLS-TP MUST support a method to offer packet loss objectives comparable to those in TDM transport networks (only due to bit errors). For the complete set of requirements related to PM functionality for MPLS-TP, see the MPLS-TP OAM requirements document [REF]. TOM: Again, I suggest you punt on this entire section and move it to the OAM doc. 2.8. Protection & Survivability requirements Network survivability plays a critical factor in the delivery of reliable services. Network availability is a significant contributor to revenue and profit. Service guarantees in the form of SLAs require a resilient network that rapidly detects facility or node failures and restores network operation in accordance with the terms of the SLA. The requirements in this section use of the recovery terminology defined in RFC 4427[RFC4427]. o MPLS-TP SHOULD support transport network style protection TOM: I would make this a MUST. switching mechanisms (tandem network connection protection, LSP protection and PW protection) to provide the sub-50ms recovery time required to maintain customer transparency, even when thousands of services are simultaneously affected by a failure. [Is sub-50ms really a requirement, do we want to clarify this further - is it sub-50ms end to end, or per link?] o * MPLS-TP recovery mechanisms SHOULD be applicable at various levels throughout the network, SPAN, tandem connection and end- to-end. TOM: This sentence doesn't parse. Please re-write. Any recovery mechanism used in a tandem connection MUST be independent of other tandem connections. * MPLS-TP SHOULD support mechanisms that keep traffic flowing while the network recovers from failures. TOM: I would say this is a MUST. * MPLS-TP SHOULD support network restoration mechanisms controlled by a distributed control plane and/or by a management plane based. TOM: I would say this is a MUST. * + The restoration resources MAY be pre-planned and selected a priori, or computed after failure occurrence. Niven-Jenkins, et al. Expires January 2, 2009 [Page 12] Internet-Draft MPLS-TP Requirements July 2008 + MPLS-TP MAY support shared-mesh restoration. + MPLS-TP SHOUD support soft LSP restoration. + MPLS-TP MAY support hard LSP restoration. + The restoration mechanism MUST be applicable to any topology. + Restoration priority MAY be implemented to determine the order in which connections should be restored (to minimize service restoration time as well as to gain access to available spare capacity on the best paths). Preemption priority MAY be used in the event that not all connections can be restored, in which case connections with lower preemption priority should be released. + The restoration mechanism SHOULD operate in synergy with other transport network technologies (SDH, OTN, WDM). * MPLS-TP SHOULD support data plane driven protection mechanisms (without any dependency on a control plane or IP protocols) to enable fast recovery from failure, and thereby to enhance the reliability and availability performance of MPLS-TP networks. * + MPLS-TP protection mechanisms SHOULD be applied to LSPs and PWs. + MPLS-TP MUST support mechanisms that rapidly detect, locate, notify and remedy network faults. + MPLS-TP MUST support 1:1 bidirectional protection switching. The protection state of both ends of the protected entity MUST be synchronized. + MPLS-TP MAY support 1+1 unidirectional protection switching. + MPLS-TP protection mechanisms MUST be applicable to both point-to-point and point-to-multipoint connections. + It SHOULD be possible to achieve protection at the MPLS-TP layer as fast as possible (subject to the temporal resolution of the defect detection mechanism). + Protection ratio MUST be of 100%, i.e., 100% of impaired working traffic MUST be protected for a failure on a single Niven-Jenkins, et al. Expires January 2, 2009 [Page 13] Internet-Draft MPLS-TP Requirements July 2008 working LSP. + Operator requests for manual control of protection switching such as clear, lockout of protection, forced-switch and manual-switch commands MUST be supported. Prioritized protection between Signal Fail (SF), Signal Degradation (SD) and operator switch requests MUST be supported. + MPLS-TP protection mechanisms MUST support revertive and non-revertive behaviour. o An extra traffic capability SHOULD be supported when possible. + MPLS-TP protection switching mechanisms MUST prevent frequent operation of the protection switch due to an intermittent defect. + MPLS-TP protection mechanisms MUST ensure co-ordination of timing of protection switches at multiple layers to avoid races and to allow the protection switching mechanism of the server layer to fix the problem before switching at the MPLS-TP layer. + MPLS-TP MAY support mechanisms that are optimized for specific network topologies (Ring, Mesh) in order to handle protection switching in a cost-efficient manner. 2.9. QoS requirements Service providers require advanced traffic management capabilities to enforce and guarantee the QoS parameters of customers' SLAs. Quality of service mechanisms are required to ensure: o Support for differentiated services and different traffic types with traffic class separation associated with different traffic. o Prioritization of critical services. o Enabling the provisioning and the guarantee of Service Level Specifications (SLS), with support for hard and relative end-to- end BW guaranteed. o Controlled jitter and delay. o Guarantee of fair access to shared resources in an MPLS-TP network. Niven-Jenkins, et al. Expires January 2, 2009 [Page 14] Internet-Draft MPLS-TP Requirements July 2008 o Ability for OAM and data to share the same fate. TOM: This belongs in the OAM document. o Resources for control and management plane packets so that user plane traffic, regardless of the amount, will not cause control and management functions to become inoperative. The following QoS requirements apply to MPLS-TP: o MPLS-TP MUST be able to deliver the same degree of QoS that has been delivered by SDH/SONET systems. TOM: We can save on a lot of text and remove the "MPLS-TE MUST" or "MPLS-TP SHOULD" bits and simply say "MUST X" or "SHOULD Y". The MPLS-TP bit is implicit I think. o MPLS-TP MUST support transport bandwidth allocation to any granularity without any restrictions based on a circuit-switched multiplexing hierarchy. This attribute will provide service providers with the capability to route more customer service demands over the MPLS-TP network. [Should we refer here to the requirements specified in RFC 2702?] 2.10. Security requirements o MPLS-TP MUST ensure that the network and services are secured. o Traffic flows from different users MUST NOT be intermingled, but if this does occur then this MUST be detectable and the appropriate consequent actions taken. o MPLS-TP MUST ensure the separation of customer (client) and provider (server and peer network) addressing and other information. TOM: This requirement is stated above. o MPLS-TP MUST ensure that the control and management planes as well as OAM traffic are secure from external attack. o MPLS-TP MUST provide mechanisms to ensure that the MPLS-TP network remains secure and stable under situations of extreme stress. Examples of attacks and situations of extreme stress include (but are not limited to) classical security attacks (e.g., hijacking, privacy, non-repudiation, etc.) and attacks on network availability (e.g., denial of service (DoS) attacks). 3. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an Niven-Jenkins, et al. Expires January 2, 2009 [Page 15] Internet-Draft MPLS-TP Requirements July 2008 RFC. 4. Security Considerations This document does not by itself raise any particular security considerations. 5. Acknowledgements The authors wish to thank Neil Harrison and Tomonori Takeda for their review and enhancements to the text. 6. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4427, March 2006. [ITU.Y1401.2008] International Telecommunications Union, "Principles of interworking", ITU-T Recommendation Y.1401, February 2008. Authors' Addresses Ben Niven-Jenkins (editor) BT 208 Callisto House, Adastral Park Ipswich, Suffolk IP5 3RE UK Email: benjamin.niven-jenkins@bt.com Deborah Brungard (editor) AT&T Rm. D1-3C22 - 200 S. Laurel Ave. Middletown, NJ 07748 USA Email: dbrungard@att.com Niven-Jenkins, et al. Expires January 2, 2009 [Page 16] Internet-Draft MPLS-TP Requirements July 2008 Malcolm Betts (editor) Nortel Networks 3500 Carling Avenue Ottawa, Ontario K2H 8E9 Canada Email: betts01@nortel.com Nurit Sprecher Nokia Siemens Networks 3 Hanagar St. Neve Ne'eman B Hod Hasharon, 45241 Israel Email: nurit.sprecher@nsn.com Niven-Jenkins, et al. Expires January 2, 2009 [Page 17] Internet-Draft MPLS-TP Requirements July 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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, THE IETF TRUST 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. Intellectual Property 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. Niven-Jenkins, et al. Expires January 2, 2009 [Page 18] _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop From mpls-interop-bounces@ietf.org Sun Jun 22 04:17:08 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 106903A685E; Sun, 22 Jun 2008 04:17:08 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C08EE3A6892 for ; Sun, 22 Jun 2008 04:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.932 X-Spam-Level: X-Spam-Status: No, score=-0.932 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqg2Jrmvly4f for ; Sun, 22 Jun 2008 04:17:03 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 14F9F3A685E for ; Sun, 22 Jun 2008 04:17:02 -0700 (PDT) Received: from E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.109]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Jun 2008 12:17:07 +0100 Received: from 217.32.164.184 ([217.32.164.184]) by E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.60]) via Exchange Front-End Server mail.bt.com ([193.113.197.28]) with Microsoft Exchange Server HTTP-DAV ; Sun, 22 Jun 2008 11:17:06 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Sun, 22 Jun 2008 12:17:05 +0100 From: Ben Niven-Jenkins To: Thomas Nadeau , Loa Andersson , MEAD team Message-ID: Thread-Topic: [Mpls-interop] next MEAD team meeting Thread-Index: AcjSMNQsx4BuurjX8EeQxIcfmO8exAA0/R+VAFUt6qo= In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 22 Jun 2008 11:17:07.0465 (UTC) FILETIME=[81C8AF90:01C8D459] Subject: Re: [Mpls-interop] next MEAD team meeting X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org Tom, We still need to go through the draft and align the language better with that which is familiar to the IETF. I've incorporated your comments, also see below for some responses. On 20/06/2008 19:38, "Thomas Nadeau" wrote: > An important attribute of a transport network is its ability to > function independently from both its client and server (transmission > media) layer networks. It should be capable of transmitting over any > media. Another key characteristic of transport networks is the > capability to maintain the integrity of the client signal between its > ingress and egress ports. > > TOM: I would use something other than "client signal" here. Something like > "client path" or something is what I think you mean. Changed to "maintain the integrity of the client across the transport network" > The connectivity service is the basic service provided by a transport > network. > > TOM: Is it? Yes. > Does the transport really provide connections or does it provide > transport paths? It provides connections in "transport speak". Connections have specific attributes that the term path does not convey but for the purpose of expressing the requirements in "IETF speak" 'transport path' is probably sufficient. > I am sensitive to the terms used here. We don't want this > to become a connect-fest. You call it a tomayto, I call it a tomarto... > The purpose of a transport network is to transparently > carry client signals (i.e. the stream of client PDUs or client bits) > > TOM: Again, I don't like the term "signals" here. Use "client data" or > something. Changed to " The purpose of a transport network is to transparently carry its clients (i.e. the stream of client PDUs or client bits)" > between endpoints in the network (typically over several intermediate > nodes). These endpoints may be service switching points or service > terminating points. The connectivity services offered to customers > are aggregated into large, long-holding time pipes/trunks which > > TOM: Do you really mean to call these "time pipes"? Sounds too futuristic > even for this work. *) I think you mean "...into relatively large, > long-lasting paths..." Changed to " aggregated into large transport paths with long-holding times, which enable" > enable the efficient and reliable operation of the transport network. > These trunks are modified infrequently. > > TOM: Keep the terminology consistent here too. There is the use of "trunks", > "pipes", etc... Changed to "transport paths" > 2. They reduce load and the cost of implementing service assurance > and fault management. > > TOM: Do they really reduce load? This is one of those fluffy, open-ended > terms like "scaleability" that I don't like used unless it is clearly > defined. Yes as you only have to monitor the transport path itself and not each individual client path within the transport path. > 3. Client signals are completely encapsulated and isolated from each > other. This also allows complete isolation of customer traffic > from carrier operations. > > TOM: Does this really happen at the data or control plane or both? Or do we > care? Both. All client planes are isolated from the transport plane and all the planes of one client are isolated from the planes of any other client. > Client signals are first transparently encapsulated. These > encapsulated client signals are then aggregated for transport through > the network in order to optimize network management. Server layer > OAM is used to monitor the transport integrity of the client layer > aggregate. At any hop, the aggregated signals may be further > aggregated in lower layer transport network paths for transport > across intermediate shared links. The encapsulated client signals > are extracted at the edges of aggregation domains, and are either > delivered to the client or forwarded to another domain. In the core > of the network, only the server layer aggregated signals are > monitored; individual client signals are monitored at the network > boundary in the client layer network. > > TOM: I am not sure the above is appropriate for a requirements document. It > sounds like you are spelling out an algorithm for how a solution should > work. This is a description of how a transport network operates. I included it as I assumed not all readers would be familiar with transport network operation but if we are comfortable assuming they are I can remove it. > Quality-of-service mechanisms are required in the packet transport > network to ensure the prioritization of critical services, to > guarantee BW and to control jitter and delay. > > TOM: Are they required everywhere the service exists, or say just at the > ingress/egress for policing/marking functions? While we are on the subject, > do we want to be more specific about QoS requirements? A connection has the constraint that all the link connection resources have been reserved for a specific communication, ergo it is implicit that some QoS is required within a transport network itself. > Service providers require control and deterministic usage of network > resources. They need end-to-end control to engineer network paths > and to efficiently utilize network resources. They require > capabilities to statically (OSS based) provision deterministic, > protected and secured services and their associated resources as well > as alternative control-plane options. > > TOM: They also require dynamic ones. Please put that in. I don't want to be > asking for only a completely static system. ITU requirement is that only static is a MUST but we can expand to make dynamic a MUST too. Changed to " They require capabilities to statically (OSS based) and dynamically provision" > The transport network must be capable of transporting multiple > services in a scalable manner. > > TOM: Again, this use of "scalable" offends me. Please be more specific or > take the sentence out as it is meaningless as stated. Agreed it does not add anything and we can implicitly assume any solution should be "scalable", I've removed it. > Carriers will still need to cope with legacy networks (which are > composed of many layers and technologies), thus the packet transport > network should interwork with other packet and transport networks > (both horizontally and vertically). Vertical interworking is also > known as client/server or network interworking. Horizontal > interworking is also known as peer-partition or service interworking. > > TOM: Didn't you just say that vertical interworking was client interworking > in the first sentence? How can horizontal be service interworking as well? Vertical interworking is where a client is encapsulated into a server transparently (e.g. Ethernet over ATM), horizontal interowkring is where a client is "interworked" with another network ala FRF.8. TBH I am not convinced there is a real requirement for horizontal interworking in transport networks and if we all agree that to be the case then we can remove the above paragraph. > MPLS is a maturing packet technology and it is already playing an > > > > Niven-Jenkins, et al. Expires January 2, 2009 [Page 4] > > Internet-Draft MPLS-TP Requirements July 2008 > > > important role in transport networks and services. However, not all > of MPLS's capabilities and mechnisms are needed and/or consistent > with transport network operations. This document identifies the > required capabilities for MPLS so that it can better fit a transport > role. > > TOM: I think you want to say "identifies the required sub-set of > capabilities..." and later "potentially new ons specific for transport > networks" which it seems you say two paragraphs later. > > Combining the packet experience of MPLS with the operational > experience of SONET/SDH constitutes a packet transport technology > named MPLS-TP. MPLS-TP will enable the migration of SONET/SDH > networks to a packet-based network that will easily scale to support > packet services in a simple and cost effective way. > > MPLS-TP needs to combine the necessary existing capabilities of MPLS > with additional minimal mechanisms in order to meet the requirements > described in this document. > > The requirements of an MPLS transport profile are provided below. > > TOM: There is a terminology issue in the use of "MPLS-TP" or "an MPLS > transport profile". That is, on the one hand you refer to a technology, but > on the other hand you are referring to a specific profile. Which is it? > > > 2. MPLS-TP Requirements > > 2.1. General requirements > > o MPLS-TP MUST offer as much commonality as possible with the MPLS > user plane as defined by IETF. When MPLS offers multiple options > in this respect, MPLS-TP SHOULD select the minimum sub-set > (necessary and sufficient subset) applicable to a transport > network application. > > o Any new functionality that is defined to fulfil the requirements > for MPLS-TP MUST be agreed within IETF and re-use (as far as > practically possible) existing MPLS standards. > > o Mechanisms and capabilities MUST be able to interoperate with > existing MPLS and PWE control and data planes where appropriate. > > TOM: Change PWE to "IETF PWE3" and "MPLS" to "IETF MPLS". There also need to > be references here to the PWE3 architecture and MPLS architectures. > > o MPLS-TP MUST support traffic engineering capabilities that allow > deterministic control of the use of network resources. > > o MPLS-TP MUST support the logical separation of the control and > management planes from the user plane. > > o MPLS-TP SHOULD support the physical separation of the control and > management planes from the user plane. > > o MPLS-TP MUST support point to point (P2P) or point to multipoint > (P2MP) connections. > > TOM: Are we avoiding MP2MP consciously or was it left out? > > > Niven-Jenkins, et al. Expires January 2, 2009 [Page 5] > > Internet-Draft MPLS-TP Requirements July 2008 > > > o MPLS-TP MUST support static provisioning of connections via an > NMS/OSS (i.e. via the management plane). > > o Static provisioning MUST not depend on routing or signaling > protocols (e.g. GMPLS, OSPF, IS-IS, RSVP, BGP, LDP etc.). > > o MPLS-TP connections MAY be able to be provisioned dynamically via > a control plane. > > TOM: I insist that we change the MAY above to MUST. I want a dynamic version > of this as much as a static one. > > > o The MPLS-TP data plane MUST be capable of functioning > independently of the control or management plane used to operate > the MPLS-TP layer network. That is the MPLS-TP data plane > operation MUST continue to operate normally if the management > plane or control plane that configured the connections fails. > > o MPLS-TP MUST support any network topology and be able to support > increasing bandwidth demands, topology, number of customers or > number of services incrementally. > > > TOM: I think it is imperative that although an MPLS-TP is defined to play > nicely with an MPLS one, it is imperative that one can distinguish between > both, at least at the control plane, but perhaps at the data plane as well. > > 2.2. Layering requirements > > o An MPLS-TP network MUST operate in a multiple layer network > environment consisting of the following independent layers: > > 1. A "service layer" instance in which the connections carry the > customer's (individual or bundled) service (may be point-to- > point, point-to-multipoint or multipoint-to-multipoint > services); > > 2. A "trunk layer" with point-to-point or point-to-multipoint > connections which are used to carry aggregates of the network > "service layer" connections; and > > 3. A "transmission media layer" which provides sections (two-port > point-to-point connections) to carry the aggregate of network > trunk or network service connections on various physical > media. > > TOM: This stuff belongs in the Terminology section at the top. > > MPLS-TP may provide the "service layer" (for P2P and P2MP services) > and/or the "trunk layer" within a layer network environment. > > o An MPLS-TP layer network MUST support the transparent transport of > MPLS-TP and non MPLS-TP client layer networks. > > o An MPLS-TP layer network MUST be able to be transparently carried > over MPLS-TP and non MPLS-TP server layer networks (such as > Ethernet, OTN, etc.) > > > > > Niven-Jenkins, et al. Expires January 2, 2009 [Page 6] > > Internet-Draft MPLS-TP Requirements July 2008 > > > o It MUST be possible to operate the MPLS-TP layer network > independently of other layer networks (either MPLS-TP or non > MPLS-TP). > > This is not only a technology requirement, different administrative > groups may be responsible for different layer networks (even when > they are of the same type)), and require the capability to > operationally support the different layers. > > o It MUST be possible to hide MPLS-TP layer network addressing and > other information (e.g. topology) from client layers. > > 2.3. Data plane requirements > > o The identification of each connection within its aggregate MUST be > supported. > > o A label in a particular section MUST uniquely identify the > connection. > > o A connection's source MUST be identifiable at its destination. > > Connections can be aggregated into trunks by pushing and de- > aggregated by popping labels. MPLS-TP labels may be swapped within a > connection in a layer network instance when the traffic is forwarded > from one MPLS-TP link connection to another MPLS-TP link connection. > > o Labelling MUST make use of the MPLS label and label stack entry as > defined in RFC3032. > > o It MUST be possible to operate and configure the MPLS-TP data > (transport) plane without any IP functionality. > > o MPLS-TP MUST support both unidirectional and bi-directional point- > to-point connections. > > o The forward and backward directions of a bi-directional connection > SHOULD follow the same path within the MPLS-TP network. > > TOM: I am not sure if we say that they SHOULD as much as "they MUST be > capable of". > > o The intermediate nodes SHOULD be aware about the binding of the > forward and the backward directions belonging to the same bi- > directional connection. > > TOM: Again, "SHOULD be capable of" seems better. > > o MPLS-TP SHOULD support unidirectional point-to-multipoint > connections. > > o MPLS-TP connections MUST NOT perform merging in a way that > prevents the unique identification of the source at the > > > > Niven-Jenkins, et al. Expires January 2, 2009 [Page 7] > > Internet-Draft MPLS-TP Requirements July 2008 > > > destination (e.g. no use of LDP mp2p signaling in order to avoid > losing LSP head-end information, no use of PHP, etc). > > o MPLS-TP SHOULD support transport and QoS mechanisms that can > deliver statistical multiplexing gain. Packets exceeding the > agreed traffic profile may be marked or discarded by the traffic > conditioning at the ingress of the MPLS-TP network. > > TOM: How about egress policing + marking? > > > o MPLS-TP MUST support connections through a single domain. > > o MPLS-TP SHOULD support connections through multiple domains. > > o MPLS-TP MUST be able to accommodate new traffic types. > > TOM: New traffic types other than those supported by MPLS? This doesn't make > sense to me as this will result in MPLS-TP not being a subset of MPLS. > > o MPLS-TP SHOULD support mechanisms to safeguard against the > provisioning of connections which contain forwarding loops. > > o MPLS-TP SHOULD support mechanisms to minimize traffic impact > during network reconfiguration. > > o MPLS-TP SHOULD support mechanisms which ensure the integrity of > the adapted information. > > o MPLS-TP MUST support an unambiguous and reliable means of > distinguishing users' (client) packets from MPLS-TP control plane > and management plane packets. > > 2.4. Control plane requirements > > o A distributed control plane MAY be supported to enable fast, > dynamic and reliable service provisioning in multi-vendor and > multi-domain environments using standardized protocols that > guarantee interoperability. > > o If a control plane is used for configuration of MPLS-TP > connections then: > > * Failure and recovery of the control plane MUST NOT impact the > MPLS-TP forwarding plane. > > TOM: This is difficult, as this really is handled in practice at both data > and control planes, depending on how this is configured/designed, and the > re-signaling can impact the data plane. > > * It MUST support the setup, modification, and release of MPLS-TP > connections and protection connections. > > * It MUST support mechanisms to provide traffic engineering, > constraint-based routing and explicit path control. > > * It MUST provide mechanisms to address QoS and performance > requirements (such as throughput, delay, packet loss, etc.) > > > > Niven-Jenkins, et al. Expires January 2, 2009 [Page 8] > > Internet-Draft MPLS-TP Requirements July 2008 > > > while utilizing network resources efficiently and reliably. > > o MPLS-TP SHOULD support off-path (out-of-band) control and > management planes. > > o The MPLS-TP control plane MUST be independent of any particular > client or server layer control plane. > > o The control plane SHOULD facilitate the implementation of the > service by providing end-to-end seamless connectivity and service > assurance. > > o The MPLS-TP control plane MUST support establishing all the > connectivity patterns defined for the MPLS-TP transport plane > (e.g., uni-directional and bidirectional P2P, uni-directional > P2MP, etc.) including configuration of protection functions and > any associated maintenance functions. > > o The MPLS-TP control pane must support the configuration and > modification of OAM maintenance points as well as the activation/ > deactivation of OAM when the connection is established or > modified. > > o An MPLS-TP control plane MUST support topology hiding and address > independence between domains. > > o At the boundary of a domain an MPLS-TP control plane MUST support > unique names or addresses identifying boundary points to be > interconnected. > > o At the boundary of a domain an MPLS-TP control plane must support > group names or addresses identifying sets of boundary points to be > interconnected. > > o MPLS-TP layer network access points (or connection points that > proxy for access points) SHOULD be able to be assigned names which > are available to clients to identify endpoints in call or > connection requests. > > o An MPLS-TP control plane MUST support translation between > externally visible endpoint names and internal network addresses. > > o An MPLS-TP control plane MUST support constraint-based route > calculation. > > o An MPLS-TP control plane MUST support provisioning and application > of routing constraint policies. > > > > > Niven-Jenkins, et al. Expires January 2, 2009 [Page 9] > > Internet-Draft MPLS-TP Requirements July 2008 > > > o An MPLS-TP control plane MUST support pre-provisioned connection > protection. > > In some situations it is impractical to expect acceptable recovery > performance to be achieved using dynamic recalculation of connection > routes. For this reason, it is necessary to allow for pre-planning > of protection routes for selected connections. > > o The MPLS-TP control plane MUST support fast restoration. > > TOM: Define what "fast" means? > > o An MPLS-TP control plane MUST scale gracefully to support a large > number of connections. > > TOM: Define "large" and "scale" here? > > [Include some numbers to indicate how large the CP is expected to > scale to?] > > o An MPLS-TP control plane MUST clearly distinguish resources > belonging to the MPLS-TP layer network from those in other layer > networks that may also be under control plane control. > > TOM: Do you mean under the same control plane or a different one (or both)? > > o An MPLS-TP control plane MUST support the independent > identification of logically distinct control plane elements. > > o It MUST be possible to identify and provision these elements > independently, in order to reorganize the control plane components > without impacting the data plane services and vice-versa. > > Architecturally distinct elements in a control plane include: nodes > and links, control plane functional components, protocol controllers, > etc. > > o An MPLS-TP control plane SHOULD provide a common control mechanism > for architecturally similar operations. > > o An MPLS-TP control plane MUST support mechanisms for partitioning > the network under control into separate peer or hierarchical > control domains. > > o To enable the deployment of a unified control plane aimed at > controlling the set of transport technologies used in a transport > network, the MPLS-TP control plane MUST also be applicable to > other transport layer networks and provide common operations > across multiple layers. In order to maintain independence between > MPLS-TP and its respective client and server layer network > separate control plane instances SHOULD be used to control a set > of transport layer networks. > > > > > > Niven-Jenkins, et al. Expires January 2, 2009 [Page 10] > > Internet-Draft MPLS-TP Requirements July 2008 > > > o MPLS-TP SHOULD detect and recover from control plane failures and > degradations using graceful operations. > > 2.5. Network Management (NM) requirements > > o MPLS-TP MUST operate under a common operation, control and > management paradigm with respect to other transport technologies > (e.g. SDH, OTN or WDM). > > o An MPLS-TP network MUST be able to be operated with a centralized > NMS system. > > o An MPLS-TP network SHOULD be able to be operated by a centralized > NMS system with the support of a distributed control plane. > > TOM: I don't know what this means or the one above it, or how this > requirement would translate into anything tangible in the MPLS-TP protocol > designs. I suggest it be removed. > > o The MPLS-TP management plane MUST NOT depend on a specific client > layer management plane. > > TOM: This is a non-sequitur if you ask me; please strike it. > > o The MPLS-TP management plane MUST support the configuration and > modification of OAM maintenance points as well as the activation/ > deactivation of OAM when the connection is established or > modified. > > For the complete set of requirements related to NM functionality for > MPLS-TP, see the MPLS-TP NM requirements document [REF]. > > 2.6. OAM requirements > > o MPLS-TP SHOULD provide a comprehensive set of capabilities (that > are independent of and agnostic to the transmitted client > services) to support fault management, performance monitoring (of > the MPLS-TP network and the services), protection switching, fault > localization, signal quality measurement, etc. > > o A mechanism SHOULD be supported to detect, diagnose and enable > recovery from facility and equipment failures and performance > degradations according to the requirements of the service. > > o MPLS-TP OAM MUST be able to operate without IP functionality and > without relying on control and/or management planes. > > For the complete set of requirements related to OAM functionality for > MPLS-TP, see the MPLS-TP OAM requirements document [REF]. > > TOM: I suggest you just remove these two sections and refer to the > OAM/Managemetn documents. > > 2.7. Network performance management (PM) requirements > > > > > > > Niven-Jenkins, et al. Expires January 2, 2009 [Page 11] > > Internet-Draft MPLS-TP Requirements July 2008 > > > o MPLS-TP MUST support traffic-engineering capabilities with > traffic- and/or resource-oriented performance objectives. > > TOM: What are performance objectives? Do you mean traffic profiles such as > QoS/bandwidth? > > o MPLS-TP MUST support a method to offer packet loss objectives > comparable to those in TDM transport networks (only due to bit > errors). > > For the complete set of requirements related to PM functionality for > MPLS-TP, see the MPLS-TP OAM requirements document [REF]. > > TOM: Again, I suggest you punt on this entire section and move it to the OAM > doc. > > 2.8. Protection & Survivability requirements > > Network survivability plays a critical factor in the delivery of > reliable services. Network availability is a significant contributor > to revenue and profit. Service guarantees in the form of SLAs > require a resilient network that rapidly detects facility or node > failures and restores network operation in accordance with the terms > of the SLA. > > The requirements in this section use of the recovery terminology > defined in RFC 4427[RFC4427]. > > o MPLS-TP SHOULD support transport network style protection > > TOM: I would make this a MUST. > > switching mechanisms (tandem network connection protection, LSP > protection and PW protection) to provide the sub-50ms recovery > time required to maintain customer transparency, even when > thousands of services are simultaneously affected by a failure. > [Is sub-50ms really a requirement, do we want to clarify this > further - is it sub-50ms end to end, or per link?] > > o > > * MPLS-TP recovery mechanisms SHOULD be applicable at various > levels throughout the network, SPAN, tandem connection and end- > to-end. > > TOM: This sentence doesn't parse. Please re-write. > > Any recovery mechanism used in a tandem connection > MUST be independent of other tandem connections. > > * MPLS-TP SHOULD support mechanisms that keep traffic flowing > while the network recovers from failures. > > TOM: I would say this is a MUST. > > * MPLS-TP SHOULD support network restoration mechanisms > controlled by a distributed control plane and/or by a > management plane based. > > TOM: I would say this is a MUST. > > > * > > + The restoration resources MAY be pre-planned and selected a > priori, or computed after failure occurrence. > > > > Niven-Jenkins, et al. Expires January 2, 2009 [Page 12] > > Internet-Draft MPLS-TP Requirements July 2008 > > > + MPLS-TP MAY support shared-mesh restoration. > > + MPLS-TP SHOUD support soft LSP restoration. > > + MPLS-TP MAY support hard LSP restoration. > > + The restoration mechanism MUST be applicable to any > topology. > > + Restoration priority MAY be implemented to determine the > order in which connections should be restored (to minimize > service restoration time as well as to gain access to > available spare capacity on the best paths). Preemption > priority MAY be used in the event that not all connections > can be restored, in which case connections with lower > preemption priority should be released. > > + The restoration mechanism SHOULD operate in synergy with > other transport network technologies (SDH, OTN, WDM). > > * MPLS-TP SHOULD support data plane driven protection mechanisms > (without any dependency on a control plane or IP protocols) to > enable fast recovery from failure, and thereby to enhance the > reliability and availability performance of MPLS-TP networks. > > * > > + MPLS-TP protection mechanisms SHOULD be applied to LSPs and > PWs. > > + MPLS-TP MUST support mechanisms that rapidly detect, locate, > notify and remedy network faults. > > + MPLS-TP MUST support 1:1 bidirectional protection switching. > The protection state of both ends of the protected entity > MUST be synchronized. > > + MPLS-TP MAY support 1+1 unidirectional protection switching. > > + MPLS-TP protection mechanisms MUST be applicable to both > point-to-point and point-to-multipoint connections. > > + It SHOULD be possible to achieve protection at the MPLS-TP > layer as fast as possible (subject to the temporal > resolution of the defect detection mechanism). > > + Protection ratio MUST be of 100%, i.e., 100% of impaired > working traffic MUST be protected for a failure on a single > > > > Niven-Jenkins, et al. Expires January 2, 2009 [Page 13] > > Internet-Draft MPLS-TP Requirements July 2008 > > > working LSP. > > + Operator requests for manual control of protection switching > such as clear, lockout of protection, forced-switch and > manual-switch commands MUST be supported. Prioritized > protection between Signal Fail (SF), Signal Degradation (SD) > and operator switch requests MUST be supported. > > + MPLS-TP protection mechanisms MUST support revertive and > non-revertive behaviour. o An extra traffic capability > SHOULD be supported when possible. > > + MPLS-TP protection switching mechanisms MUST prevent > frequent operation of the protection switch due to an > intermittent defect. > > + MPLS-TP protection mechanisms MUST ensure co-ordination of > timing of protection switches at multiple layers to avoid > races and to allow the protection switching mechanism of the > server layer to fix the problem before switching at the > MPLS-TP layer. > > + MPLS-TP MAY support mechanisms that are optimized for > specific network topologies (Ring, Mesh) in order to handle > protection switching in a cost-efficient manner. > > 2.9. QoS requirements > > Service providers require advanced traffic management capabilities to > enforce and guarantee the QoS parameters of customers' SLAs. > > Quality of service mechanisms are required to ensure: > > o Support for differentiated services and different traffic types > with traffic class separation associated with different traffic. > > o Prioritization of critical services. > > o Enabling the provisioning and the guarantee of Service Level > Specifications (SLS), with support for hard and relative end-to- > end BW guaranteed. > > o Controlled jitter and delay. > > o Guarantee of fair access to shared resources in an MPLS-TP > network. > > > > > > Niven-Jenkins, et al. Expires January 2, 2009 [Page 14] > > Internet-Draft MPLS-TP Requirements July 2008 > > > o Ability for OAM and data to share the same fate. > > TOM: This belongs in the OAM document. > > > o Resources for control and management plane packets so that user > plane traffic, regardless of the amount, will not cause control > and management functions to become inoperative. > > The following QoS requirements apply to MPLS-TP: > > o MPLS-TP MUST be able to deliver the same degree of QoS that has > been delivered by SDH/SONET systems. > > TOM: We can save on a lot of text and remove the "MPLS-TE MUST" or "MPLS-TP > SHOULD" bits and simply say "MUST X" or "SHOULD Y". The MPLS-TP bit is > implicit I think. > > o MPLS-TP MUST support transport bandwidth allocation to any > granularity without any restrictions based on a circuit-switched > multiplexing hierarchy. This attribute will provide service > providers with the capability to route more customer service > demands over the MPLS-TP network. > > [Should we refer here to the requirements specified in RFC 2702?] > > 2.10. Security requirements > > o MPLS-TP MUST ensure that the network and services are secured. > > o Traffic flows from different users MUST NOT be intermingled, but > if this does occur then this MUST be detectable and the > appropriate consequent actions taken. > > o MPLS-TP MUST ensure the separation of customer (client) and > provider (server and peer network) addressing and other > information. > > TOM: This requirement is stated above. > > o MPLS-TP MUST ensure that the control and management planes as well > as OAM traffic are secure from external attack. > > o MPLS-TP MUST provide mechanisms to ensure that the MPLS-TP network > remains secure and stable under situations of extreme stress. > > Examples of attacks and situations of extreme stress include (but are > not limited to) classical security attacks (e.g., hijacking, privacy, > non-repudiation, etc.) and attacks on network availability (e.g., > denial of service (DoS) attacks). > > > 3. IANA Considerations > > This document makes no request of IANA. > > Note to RFC Editor: this section may be removed on publication as an > > > > Niven-Jenkins, et al. Expires January 2, 2009 [Page 15] > > Internet-Draft MPLS-TP Requirements July 2008 > > > RFC. > > > 4. Security Considerations > > This document does not by itself raise any particular security > considerations. > > > 5. Acknowledgements > > The authors wish to thank Neil Harrison and Tomonori Takeda for their > review and enhancements to the text. > > > 6. Informative References > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. > > [RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and > Restoration) Terminology for Generalized Multi-Protocol > Label Switching (GMPLS)", RFC 4427, March 2006. > > [ITU.Y1401.2008] > International Telecommunications Union, "Principles of > interworking", ITU-T Recommendation Y.1401, February 2008. > > > Authors' Addresses > > Ben Niven-Jenkins (editor) > BT > 208 Callisto House, Adastral Park > Ipswich, Suffolk IP5 3RE > UK > > Email: benjamin.niven-jenkins@bt.com > > > Deborah Brungard (editor) > AT&T > Rm. D1-3C22 - 200 S. Laurel Ave. > Middletown, NJ 07748 > USA > > Email: dbrungard@att.com > > > > > Niven-Jenkins, et al. Expires January 2, 2009 [Page 16] > > Internet-Draft MPLS-TP Requirements July 2008 > > > Malcolm Betts (editor) > Nortel Networks > 3500 Carling Avenue > Ottawa, Ontario K2H 8E9 > Canada > > Email: betts01@nortel.com > > > Nurit Sprecher > Nokia Siemens Networks > 3 Hanagar St. Neve Ne'eman B > Hod Hasharon, 45241 > Israel > > Email: nurit.sprecher@nsn.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Niven-Jenkins, et al. Expires January 2, 2009 [Page 17] > > Internet-Draft MPLS-TP Requirements July 2008 > > > Full Copyright Statement > > Copyright (C) The IETF Trust (2008). > > 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, THE IETF TRUST 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. > > > Intellectual Property > > 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. > > > > > > > > > > > > Niven-Jenkins, et al. Expires January 2, 2009 [Page 18] > > > _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop From mpls-interop-bounces@ietf.org Sun Jun 22 04:51:52 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C8913A67B6; Sun, 22 Jun 2008 04:51:52 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D4B93A695C for ; Sun, 22 Jun 2008 04:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.864 X-Spam-Level: X-Spam-Status: No, score=0.864 tagged_above=-999 required=5 tests=[AWL=1.796, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5q2iV4fOwsEh for ; Sun, 22 Jun 2008 04:51:48 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 482CF3A67B6 for ; Sun, 22 Jun 2008 04:51:46 -0700 (PDT) Received: from E03MVZ2-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Jun 2008 12:51:51 +0100 Received: from 217.32.164.184 ([217.32.164.184]) by E03MVZ2-UKDY.domain1.systemhost.net ([193.113.30.120]) via Exchange Front-End Server mail.bt.com ([193.113.197.28]) with Microsoft Exchange Server HTTP-DAV ; Sun, 22 Jun 2008 11:51:50 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Sun, 22 Jun 2008 07:51:48 -0400 From: Thomas Nadeau To: "Sprecher, Nurit (NSN - IL/Israel - MiniMD)" , Ben Niven-Jenkins , Loa Andersson , MEAD team Message-ID: Thread-Topic: [Mpls-interop] next MEAD team meeting Thread-Index: AcjSMNQsx4BuurjX8EeQxIcfmO8exAA0/R+VAEuIunAACtuUpA== In-Reply-To: <9FF5BDAD88B9D84881609E89AC92FB83EBD380@DEMUEXC014.nsn-intra.net> Mime-version: 1.0 X-OriginalArrivalTime: 22 Jun 2008 11:51:51.0930 (UTC) FILETIME=[5C38CDA0:01C8D45E] Cc: "Weingarten, Yaacov \(NSN - IL/Israel - MiniMD\)" Subject: Re: [Mpls-interop] next MEAD team meeting X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org On 6/22/08 5:45 AM, "Sprecher, Nurit (NSN - IL/Israel - MiniMD)" wrote: > Hi Thomas, > Thanks for your comments. > I still need to get into the details and meanings of your comments, but > in the meantime I have one basic concern on your comment on " MPLS-TP > connections MAY be able to be provisioned dynamically via a control > plane. TOM: I insist that we change the MAY above to MUST. I want a > dynamic version of this as much as a static one." > This is one of the fundamental principles of the MPLS-TP, that the > presence of a distributed control plane in support of network operations > is optional (as in other transport technologies, like in SDH, etc.). I agree it is optional. What I want to make sure is that it is not so optional that it is completely removed from the design. The language in the document now seems to be headed in that direction. > This is also the trigger for the definition of OAM capabilities which > are independent of a control plane, as well as of the protection > switching, etc. > This is also addressed by the slides of the JW: "Desire to statically > configure LSPs and PWEs via the management plane... I am not arguing against static; I am arguing for dynamic to be in there as well. > Transport OAM capabilities don't exist for LSP and PWE independent of > configuration mechanism (management plane or GMPLS or PWE control > plane)... It depends on how you look at what "transport OAM capabilities". From my perspective at BT, I definitely think there is a dynamic flavor of this for sure. Again, I am not advocating removal of the static parts, just the addition of the dynamic ones. And since they are already there in large part, as part of the base MPLS specification, I don't see any harm in specifying this. --Tom > With static provisioning, no dependency on routing or signaling > (e.g. GMPLS or, IGP, RSVP, BGP, LDP)", etc. > Best regards, > Nurit > > -----Original Message----- > From: mpls-interop-bounces@ietf.org > [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext Thomas Nadeau > Sent: Friday, June 20, 2008 21:38 > To: Ben Niven-Jenkins; Loa Andersson; MEAD team > Subject: Re: [Mpls-interop] next MEAD team meeting > > > Comments on the document inline start with "TOM:" > In general, please review the document and put more of an emphasis on > the use of "MUST" rather than "MAY" or "SHOULD". The IETG frowns on > requirements documents that are too optional. > > --Tom > > > > > > Network Working Group B. Niven-Jenkins, Ed. > Internet-Draft BT > Intended status: Informational D. Brungard, Ed. > Expires: January 2, 2009 AT&T > M. Betts, Ed. > Nortel Networks > N. Sprecher > Nokia Siemens Networks > July 01, 2008 > > > MPLS-TP Requirements > draft-jenkins-mpls-mplstp-requirements-00 > > Status of this Memo > > By submitting this Internet-Draft, each author represents that any > applicable patent or other IPR claims of which he or she is aware > have been or will be disclosed, and any of which he or she becomes > aware will be disclosed, in accordance with Section 6 of BCP 79. > > 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. > > This Internet-Draft will expire on January 2, 2009. > > Abstract > > This document will outline the requirements for MPLS-TP. > > Requirements Language > > 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 [RFC2119]. > > > > Niven-Jenkins, et al. Expires January 2, 2009 [Page 1] > > Internet-Draft MPLS-TP Requirements July 2008 > > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 2. MPLS-TP Requirements . . . . . . . . . . . . . . . . . . . . . 5 > 2.1. General requirements . . . . . . . . . . . . . . . . . . . 5 > 2.2. Layering requirements . . . . . . . . . . . . . . . . . . 6 > 2.3. Data plane requirements . . . . . . . . . . . . . . . . . 7 > 2.4. Control plane requirements . . . . . . . . . . . . . . . . 8 > 2.5. Network Management (NM) requirements . . . . . . . . . . . 11 > 2.6. OAM requirements . . . . . . . . . . . . . . . . . . . . . 11 > 2.7. Network performance management (PM) requirements . . . . . 11 > 2.8. Protection & Survivability requirements . . . . . . . . . 12 > 2.9. QoS requirements . . . . . . . . . . . . . . . . . . . . . 14 > 2.10. Security requirements . . . . . . . . . . . . . . . . . . 15 > 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 > 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 > 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 > 6. Informative References . . . . . . . . . . . . . . . . . . . . 16 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 > Intellectual Property and Copyright Statements . . . . . . . . . . 18 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Niven-Jenkins, et al. Expires January 2, 2009 [Page 2] > > Internet-Draft MPLS-TP Requirements July 2008 > > > 1. Introduction > > For many years, SONET/SDH has provided service providers with a high > benchmark for reliability and operational simplicity. With the > accelerating growth of packet-based services (such as Ethernet, VoIP, > L2/L3 VPN, IPTV, RAN backhauling, etc.), service providers are in > need of capabilities to efficiently support packet-based services on > their transport networks. The need to increase their revenue while > remaining competitive forces operators to look for the lowest network > Total Cost of Ownership (TCO). Investment in both Capital > Expenditure (CAPEX) and Operational Expense (OPEX) should be minimal. > > Carriers are considering migrating to packet transport networks in > order to reduce their costs and to improve their ability to support > services with guaranteed SLAs. Migrating from SONET/SDH to packet > transport networks should not involve dramatic changes in network > operation, should not necessitate extensive retraining, and should > not require major changes to existing work practices. The aim is to > preserve the look-and-feel to which carriers have become accustomed > in deploying their SONET/SDH networks, while providing common, multi- > layer operations, resiliency, control and management for packet, > circuit and lambda transport networks. > > An important attribute of a transport network is its ability to > function independently from both its client and server (transmission > media) layer networks. It should be capable of transmitting over any > media. Another key characteristic of transport networks is the > capability to maintain the integrity of the client signal between its > ingress and egress ports. > > TOM: I would use something other than "client signal" here. Something > like "client path" or something is what I think you mean. > > A transport network must provide the means > to commit quality of service objectives to clients. This is achieved > by providing a mechanism for client network service demarcation for > the network path together with an associated network resiliency > mechanism. A transport network must also provide a method of service > monitoring in order to verify the delivery of an agreed quality of > service. This is enabled by means of carrier-grade OAM tools. > > The connectivity service is the basic service provided by a transport > network. > > TOM: Is it? Does the transport really provide connections or does it > provide transport paths? I am sensitive to the terms used here. We > don't want this to become a connect-fest. Seems to me that you explain > this better in the next sentence anyhow. > > The purpose of a transport network is to transparently > carry client signals (i.e. the stream of client PDUs or client bits) > > TOM: Again, I don't like the term "signals" here. Use "client data" or > something. > > between endpoints in the network (typically over several intermediate > nodes). These endpoints may be service switching points or service > terminating points. The connectivity services offered to customers > are aggregated into large, long-holding time pipes/trunks which > > TOM: Do you really mean to call these "time pipes"? Sounds too > futuristic even for this work. *) I think you mean "...into relatively > large, long-lasting paths..." > > enable the efficient and reliable operation of the transport network. > These trunks are modified infrequently. > > TOM: Keep the terminology consistent here too. There is the use of > "trunks", "pipes", etc... > > Aggregation and hierarchy are beneficial for achieving scalability > and security since: > > > > Niven-Jenkins, et al. Expires January 2, 2009 [Page 3] > > Internet-Draft MPLS-TP Requirements July 2008 > > > 1. They reduce the number of provisioning and forwarding states in > the network core. > > 2. They reduce load and the cost of implementing service assurance > and fault management. > > TOM: Do they really reduce load? This is one of those fluffy, open-ended > terms like "scaleability" that I don't like used unless it is clearly > defined. > > 3. Client signals are completely encapsulated and isolated from each > other. This also allows complete isolation of customer traffic > from carrier operations. > > TOM: Does this really happen at the data or control plane or both? Or do > we care? > > > Client signals are first transparently encapsulated. These > encapsulated client signals are then aggregated for transport through > the network in order to optimize network management. Server layer > OAM is used to monitor the transport integrity of the client layer > aggregate. At any hop, the aggregated signals may be further > aggregated in lower layer transport network paths for transport > across intermediate shared links. The encapsulated client signals > are extracted at the edges of aggregation domains, and are either > delivered to the client or forwarded to another domain. In the core > of the network, only the server layer aggregated signals are > monitored; individual client signals are monitored at the network > boundary in the client layer network. > > TOM: I am not sure the above is appropriate for a requirements document. > It sounds like you are spelling out an algorithm for how a solution > should work. > > Quality-of-service mechanisms are required in the packet transport > network to ensure the prioritization of critical services, to > guarantee BW and to control jitter and delay. > > TOM: Are they required everywhere the service exists, or say just at the > ingress/egress for policing/marking functions? While we are on the > subject, do we want to be more specific about QoS requirements? > > Service providers require control and deterministic usage of network > resources. They need end-to-end control to engineer network paths > and to efficiently utilize network resources. They require > capabilities to statically (OSS based) provision deterministic, > protected and secured services and their associated resources as well > as alternative control-plane options. > > TOM: They also require dynamic ones. Please put that in. I don't want > to be asking for only a completely static system. > > The transport network must be capable of transporting multiple > services in a scalable manner. > > TOM: Again, this use of "scalable" offends me. Please be more specific > or take the sentence out as it is meaningless as stated. > > Carriers will still need to cope with legacy networks (which are > composed of many layers and technologies), thus the packet transport > network should interwork with other packet and transport networks > (both horizontally and vertically). Vertical interworking is also > known as client/server or network interworking. Horizontal > interworking is also known as peer-partition or service interworking. > > TOM: Didn't you just say that vertical interworking was client > interworking in the first sentence? How can horizontal be service > interworking as well? > > For more details on each type of interworking and some of the issues > that may arise (especially with horizontal interworking) see > [ITU.Y1401.2008]. > > MPLS is a maturing packet technology and it is already playing an > > > > Niven-Jenkins, et al. Expires January 2, 2009 [Page 4] > > Internet-Draft MPLS-TP Requirements July 2008 > > > important role in transport networks and services. However, not all > of MPLS's capabilities and mechnisms are needed and/or consistent > with transport network operations. This document identifies the > required capabilities for MPLS so that it can better fit a transport > role. > > TOM: I think you want to say "identifies the required sub-set of > capabilities..." and later "potentially new ons specific for transport > networks" which it seems you say two paragraphs later. > > Combining the packet experience of MPLS with the operational > experience of SONET/SDH constitutes a packet transport technology > named MPLS-TP. MPLS-TP will enable the migration of SONET/SDH > networks to a packet-based network that will easily scale to support > packet services in a simple and cost effective way. > > MPLS-TP needs to combine the necessary existing capabilities of MPLS > with additional minimal mechanisms in order to meet the requirements > described in this document. > > The requirements of an MPLS transport profile are provided below. > > TOM: There is a terminology issue in the use of "MPLS-TP" or "an MPLS > transport profile". That is, on the one hand you refer to a technology, > but on the other hand you are referring to a specific profile. Which is > it? > > > 2. MPLS-TP Requirements > > 2.1. General requirements > > o MPLS-TP MUST offer as much commonality as possible with the MPLS > user plane as defined by IETF. When MPLS offers multiple options > in this respect, MPLS-TP SHOULD select the minimum sub-set > (necessary and sufficient subset) applicable to a transport > network application. > > o Any new functionality that is defined to fulfil the requirements > for MPLS-TP MUST be agreed within IETF and re-use (as far as > practically possible) existing MPLS standards. > > o Mechanisms and capabilities MUST be able to interoperate with > existing MPLS and PWE control and data planes where appropriate. > > TOM: Change PWE to "IETF PWE3" and "MPLS" to "IETF MPLS". There also > need to be references here to the PWE3 architecture and MPLS > architectures. > > o MPLS-TP MUST support traffic engineering capabilities that allow > deterministic control of the use of network resources. > > o MPLS-TP MUST support the logical separation of the control and > management planes from the user plane. > > o MPLS-TP SHOULD support the physical separation of the control and > management planes from the user plane. > > o MPLS-TP MUST support point to point (P2P) or point to multipoint > (P2MP) connections. > > TOM: Are we avoiding MP2MP consciously or was it left out? > > > Niven-Jenkins, et al. Expires January 2, 2009 [Page 5] > > Internet-Draft MPLS-TP Requirements July 2008 > > > o MPLS-TP MUST support static provisioning of connections via an > NMS/OSS (i.e. via the management plane). > > o Static provisioning MUST not depend on routing or signaling > protocols (e.g. GMPLS, OSPF, IS-IS, RSVP, BGP, LDP etc.). > > o MPLS-TP connections MAY be able to be provisioned dynamically via > a control plane. > > TOM: I insist that we change the MAY above to MUST. I want a dynamic > version of this as much as a static one. > > > o The MPLS-TP data plane MUST be capable of functioning > independently of the control or management plane used to operate > the MPLS-TP layer network. That is the MPLS-TP data plane > operation MUST continue to operate normally if the management > plane or control plane that configured the connections fails. > > o MPLS-TP MUST support any network topology and be able to support > increasing bandwidth demands, topology, number of customers or > number of services incrementally. > > > TOM: I think it is imperative that although an MPLS-TP is defined to > play nicely with an MPLS one, it is imperative that one can distinguish > between both, at least at the control plane, but perhaps at the data > plane as well. > > 2.2. Layering requirements > > o An MPLS-TP network MUST operate in a multiple layer network > environment consisting of the following independent layers: > > 1. A "service layer" instance in which the connections carry the > customer's (individual or bundled) service (may be point-to- > point, point-to-multipoint or multipoint-to-multipoint > services); > > 2. A "trunk layer" with point-to-point or point-to-multipoint > connections which are used to carry aggregates of the network > "service layer" connections; and > > 3. A "transmission media layer" which provides sections (two-port > point-to-point connections) to carry the aggregate of network > trunk or network service connections on various physical > media. > > TOM: This stuff belongs in the Terminology section at the top. > > MPLS-TP may provide the "service layer" (for P2P and P2MP services) > and/or the "trunk layer" within a layer network environment. > > o An MPLS-TP layer network MUST support the transparent transport of > MPLS-TP and non MPLS-TP client layer networks. > > o An MPLS-TP layer network MUST be able to be transparently carried > over MPLS-TP and non MPLS-TP server layer networks (such as > Ethernet, OTN, etc.) > > > > > Niven-Jenkins, et al. Expires January 2, 2009 [Page 6] > > Internet-Draft MPLS-TP Requirements July 2008 > > > o It MUST be possible to operate the MPLS-TP layer network > independently of other layer networks (either MPLS-TP or non > MPLS-TP). > > This is not only a technology requirement, different administrative > groups may be responsible for different layer networks (even when > they are of the same type)), and require the capability to > operationally support the different layers. > > o It MUST be possible to hide MPLS-TP layer network addressing and > other information (e.g. topology) from client layers. > > 2.3. Data plane requirements > > o The identification of each connection within its aggregate MUST be > supported. > > o A label in a particular section MUST uniquely identify the > connection. > > o A connection's source MUST be identifiable at its destination. > > Connections can be aggregated into trunks by pushing and de- > aggregated by popping labels. MPLS-TP labels may be swapped within a > connection in a layer network instance when the traffic is forwarded > from one MPLS-TP link connection to another MPLS-TP link connection. > > o Labelling MUST make use of the MPLS label and label stack entry as > defined in RFC3032. > > o It MUST be possible to operate and configure the MPLS-TP data > (transport) plane without any IP functionality. > > o MPLS-TP MUST support both unidirectional and bi-directional point- > to-point connections. > > o The forward and backward directions of a bi-directional connection > SHOULD follow the same path within the MPLS-TP network. > > TOM: I am not sure if we say that they SHOULD as much as "they MUST be > capable of". > > o The intermediate nodes SHOULD be aware about the binding of the > forward and the backward directions belonging to the same bi- > directional connection. > > TOM: Again, "SHOULD be capable of" seems better. > > o MPLS-TP SHOULD support unidirectional point-to-multipoint > connections. > > o MPLS-TP connections MUST NOT perform merging in a way that > prevents the unique identification of the source at the > > > > Niven-Jenkins, et al. Expires January 2, 2009 [Page 7] > > Internet-Draft MPLS-TP Requirements July 2008 > > > destination (e.g. no use of LDP mp2p signaling in order to avoid > losing LSP head-end information, no use of PHP, etc). > > o MPLS-TP SHOULD support transport and QoS mechanisms that can > deliver statistical multiplexing gain. Packets exceeding the > agreed traffic profile may be marked or discarded by the traffic > conditioning at the ingress of the MPLS-TP network. > > TOM: How about egress policing + marking? > > > o MPLS-TP MUST support connections through a single domain. > > o MPLS-TP SHOULD support connections through multiple domains. > > o MPLS-TP MUST be able to accommodate new traffic types. > > TOM: New traffic types other than those supported by MPLS? This doesn't > make sense to me as this will result in MPLS-TP not being a subset of > MPLS. > > o MPLS-TP SHOULD support mechanisms to safeguard against the > provisioning of connections which contain forwarding loops. > > o MPLS-TP SHOULD support mechanisms to minimize traffic impact > during network reconfiguration. > > o MPLS-TP SHOULD support mechanisms which ensure the integrity of > the adapted information. > > o MPLS-TP MUST support an unambiguous and reliable means of > distinguishing users' (client) packets from MPLS-TP control plane > and management plane packets. > > 2.4. Control plane requirements > > o A distributed control plane MAY be supported to enable fast, > dynamic and reliable service provisioning in multi-vendor and > multi-domain environments using standardized protocols that > guarantee interoperability. > > o If a control plane is used for configuration of MPLS-TP > connections then: > > * Failure and recovery of the control plane MUST NOT impact the > MPLS-TP forwarding plane. > > TOM: This is difficult, as this really is handled in practice at both > data and control planes, depending on how this is configured/designed, > and the re-signaling can impact the data plane. > > * It MUST support the setup, modification, and release of MPLS-TP > connections and protection connections. > > * It MUST support mechanisms to provide traffic engineering, > constraint-based routing and explicit path control. > > * It MUST provide mechanisms to address QoS and performance > requirements (such as throughput, delay, packet loss, etc.) > > > > Niven-Jenkins, et al. Expires January 2, 2009 [Page 8] > > Internet-Draft MPLS-TP Requirements July 2008 > > > while utilizing network resources efficiently and reliably. > > o MPLS-TP SHOULD support off-path (out-of-band) control and > management planes. > > o The MPLS-TP control plane MUST be independent of any particular > client or server layer control plane. > > o The control plane SHOULD facilitate the implementation of the > service by providing end-to-end seamless connectivity and service > assurance. > > o The MPLS-TP control plane MUST support establishing all the > connectivity patterns defined for the MPLS-TP transport plane > (e.g., uni-directional and bidirectional P2P, uni-directional > P2MP, etc.) including configuration of protection functions and > any associated maintenance functions. > > o The MPLS-TP control pane must support the configuration and > modification of OAM maintenance points as well as the activation/ > deactivation of OAM when the connection is established or > modified. > > o An MPLS-TP control plane MUST support topology hiding and address > independence between domains. > > o At the boundary of a domain an MPLS-TP control plane MUST support > unique names or addresses identifying boundary points to be > interconnected. > > o At the boundary of a domain an MPLS-TP control plane must support > group names or addresses identifying sets of boundary points to be > interconnected. > > o MPLS-TP layer network access points (or connection points that > proxy for access points) SHOULD be able to be assigned names which > are available to clients to identify endpoints in call or > connection requests. > > o An MPLS-TP control plane MUST support translation between > externally visible endpoint names and internal network addresses. > > o An MPLS-TP control plane MUST support constraint-based route > calculation. > > o An MPLS-TP control plane MUST support provisioning and application > of routing constraint policies. > > > > > Niven-Jenkins, et al. Expires January 2, 2009 [Page 9] > > Internet-Draft MPLS-TP Requirements July 2008 > > > o An MPLS-TP control plane MUST support pre-provisioned connection > protection. > > In some situations it is impractical to expect acceptable recovery > performance to be achieved using dynamic recalculation of connection > routes. For this reason, it is necessary to allow for pre-planning > of protection routes for selected connections. > > o The MPLS-TP control plane MUST support fast restoration. > > TOM: Define what "fast" means? > > o An MPLS-TP control plane MUST scale gracefully to support a large > number of connections. > > TOM: Define "large" and "scale" here? > > [Include some numbers to indicate how large the CP is expected to > scale to?] > > o An MPLS-TP control plane MUST clearly distinguish resources > belonging to the MPLS-TP layer network from those in other layer > networks that may also be under control plane control. > > TOM: Do you mean under the same control plane or a different one (or > both)? > > o An MPLS-TP control plane MUST support the independent > identification of logically distinct control plane elements. > > o It MUST be possible to identify and provision these elements > independently, in order to reorganize the control plane components > without impacting the data plane services and vice-versa. > > Architecturally distinct elements in a control plane include: nodes > and links, control plane functional components, protocol controllers, > etc. > > o An MPLS-TP control plane SHOULD provide a common control mechanism > for architecturally similar operations. > > o An MPLS-TP control plane MUST support mechanisms for partitioning > the network under control into separate peer or hierarchical > control domains. > > o To enable the deployment of a unified control plane aimed at > controlling the set of transport technologies used in a transport > network, the MPLS-TP control plane MUST also be applicable to > other transport layer networks and provide common operations > across multiple layers. In order to maintain independence between > MPLS-TP and its respective client and server layer network > separate control plane instances SHOULD be used to control a set > of transport layer networks. > > > > > > Niven-Jenkins, et al. Expires January 2, 2009 [Page 10] > > Internet-Draft MPLS-TP Requirements July 2008 > > > o MPLS-TP SHOULD detect and recover from control plane failures and > degradations using graceful operations. > > 2.5. Network Management (NM) requirements > > o MPLS-TP MUST operate under a common operation, control and > management paradigm with respect to other transport technologies > (e.g. SDH, OTN or WDM). > > o An MPLS-TP network MUST be able to be operated with a centralized > NMS system. > > o An MPLS-TP network SHOULD be able to be operated by a centralized > NMS system with the support of a distributed control plane. > > TOM: I don't know what this means or the one above it, or how this > requirement would translate into anything tangible in the MPLS-TP > protocol designs. I suggest it be removed. > > o The MPLS-TP management plane MUST NOT depend on a specific client > layer management plane. > > TOM: This is a non-sequitur if you ask me; please strike it. > > o The MPLS-TP management plane MUST support the configuration and > modification of OAM maintenance points as well as the activation/ > deactivation of OAM when the connection is established or > modified. > > For the complete set of requirements related to NM functionality for > MPLS-TP, see the MPLS-TP NM requirements document [REF]. > > 2.6. OAM requirements > > o MPLS-TP SHOULD provide a comprehensive set of capabilities (that > are independent of and agnostic to the transmitted client > services) to support fault management, performance monitoring (of > the MPLS-TP network and the services), protection switching, fault > localization, signal quality measurement, etc. > > o A mechanism SHOULD be supported to detect, diagnose and enable > recovery from facility and equipment failures and performance > degradations according to the requirements of the service. > > o MPLS-TP OAM MUST be able to operate without IP functionality and > without relying on control and/or management planes. > > For the complete set of requirements related to OAM functionality for > MPLS-TP, see the MPLS-TP OAM requirements document [REF]. > > TOM: I suggest you just remove these two sections and refer to the > OAM/Managemetn documents. > > 2.7. Network performance management (PM) requirements > > > > > > > Niven-Jenkins, et al. Expires January 2, 2009 [Page 11] > > Internet-Draft MPLS-TP Requirements July 2008 > > > o MPLS-TP MUST support traffic-engineering capabilities with > traffic- and/or resource-oriented performance objectives. > > TOM: What are performance objectives? Do you mean traffic profiles such > as QoS/bandwidth? > > o MPLS-TP MUST support a method to offer packet loss objectives > comparable to those in TDM transport networks (only due to bit > errors). > > For the complete set of requirements related to PM functionality for > MPLS-TP, see the MPLS-TP OAM requirements document [REF]. > > TOM: Again, I suggest you punt on this entire section and move it to the > OAM doc. > > 2.8. Protection & Survivability requirements > > Network survivability plays a critical factor in the delivery of > reliable services. Network availability is a significant contributor > to revenue and profit. Service guarantees in the form of SLAs > require a resilient network that rapidly detects facility or node > failures and restores network operation in accordance with the terms > of the SLA. > > The requirements in this section use of the recovery terminology > defined in RFC 4427[RFC4427]. > > o MPLS-TP SHOULD support transport network style protection > > TOM: I would make this a MUST. > > switching mechanisms (tandem network connection protection, LSP > protection and PW protection) to provide the sub-50ms recovery > time required to maintain customer transparency, even when > thousands of services are simultaneously affected by a failure. > [Is sub-50ms really a requirement, do we want to clarify this > further - is it sub-50ms end to end, or per link?] > > o > > * MPLS-TP recovery mechanisms SHOULD be applicable at various > levels throughout the network, SPAN, tandem connection and end- > to-end. > > TOM: This sentence doesn't parse. Please re-write. > > Any recovery mechanism used in a tandem connection > MUST be independent of other tandem connections. > > * MPLS-TP SHOULD support mechanisms that keep traffic flowing > while the network recovers from failures. > > TOM: I would say this is a MUST. > > * MPLS-TP SHOULD support network restoration mechanisms > controlled by a distributed control plane and/or by a > management plane based. > > TOM: I would say this is a MUST. > > > * > > + The restoration resources MAY be pre-planned and selected a > priori, or computed after failure occurrence. > > > > Niven-Jenkins, et al. Expires January 2, 2009 [Page 12] > > Internet-Draft MPLS-TP Requirements July 2008 > > > + MPLS-TP MAY support shared-mesh restoration. > > + MPLS-TP SHOUD support soft LSP restoration. > > + MPLS-TP MAY support hard LSP restoration. > > + The restoration mechanism MUST be applicable to any > topology. > > + Restoration priority MAY be implemented to determine the > order in which connections should be restored (to minimize > service restoration time as well as to gain access to > available spare capacity on the best paths). Preemption > priority MAY be used in the event that not all connections > can be restored, in which case connections with lower > preemption priority should be released. > > + The restoration mechanism SHOULD operate in synergy with > other transport network technologies (SDH, OTN, WDM). > > * MPLS-TP SHOULD support data plane driven protection mechanisms > (without any dependency on a control plane or IP protocols) to > enable fast recovery from failure, and thereby to enhance the > reliability and availability performance of MPLS-TP networks. > > * > > + MPLS-TP protection mechanisms SHOULD be applied to LSPs and > PWs. > > + MPLS-TP MUST support mechanisms that rapidly detect, locate, > notify and remedy network faults. > > + MPLS-TP MUST support 1:1 bidirectional protection switching. > The protection state of both ends of the protected entity > MUST be synchronized. > > + MPLS-TP MAY support 1+1 unidirectional protection switching. > > + MPLS-TP protection mechanisms MUST be applicable to both > point-to-point and point-to-multipoint connections. > > + It SHOULD be possible to achieve protection at the MPLS-TP > layer as fast as possible (subject to the temporal > resolution of the defect detection mechanism). > > + Protection ratio MUST be of 100%, i.e., 100% of impaired > working traffic MUST be protected for a failure on a single > > > > Niven-Jenkins, et al. Expires January 2, 2009 [Page 13] > > Internet-Draft MPLS-TP Requirements July 2008 > > > working LSP. > > + Operator requests for manual control of protection switching > such as clear, lockout of protection, forced-switch and > manual-switch commands MUST be supported. Prioritized > protection between Signal Fail (SF), Signal Degradation (SD) > and operator switch requests MUST be supported. > > + MPLS-TP protection mechanisms MUST support revertive and > non-revertive behaviour. o An extra traffic capability > SHOULD be supported when possible. > > + MPLS-TP protection switching mechanisms MUST prevent > frequent operation of the protection switch due to an > intermittent defect. > > + MPLS-TP protection mechanisms MUST ensure co-ordination of > timing of protection switches at multiple layers to avoid > races and to allow the protection switching mechanism of the > server layer to fix the problem before switching at the > MPLS-TP layer. > > + MPLS-TP MAY support mechanisms that are optimized for > specific network topologies (Ring, Mesh) in order to handle > protection switching in a cost-efficient manner. > > 2.9. QoS requirements > > Service providers require advanced traffic management capabilities to > enforce and guarantee the QoS parameters of customers' SLAs. > > Quality of service mechanisms are required to ensure: > > o Support for differentiated services and different traffic types > with traffic class separation associated with different traffic. > > o Prioritization of critical services. > > o Enabling the provisioning and the guarantee of Service Level > Specifications (SLS), with support for hard and relative end-to- > end BW guaranteed. > > o Controlled jitter and delay. > > o Guarantee of fair access to shared resources in an MPLS-TP > network. > > > > > > Niven-Jenkins, et al. Expires January 2, 2009 [Page 14] > > Internet-Draft MPLS-TP Requirements July 2008 > > > o Ability for OAM and data to share the same fate. > > TOM: This belongs in the OAM document. > > > o Resources for control and management plane packets so that user > plane traffic, regardless of the amount, will not cause control > and management functions to become inoperative. > > The following QoS requirements apply to MPLS-TP: > > o MPLS-TP MUST be able to deliver the same degree of QoS that has > been delivered by SDH/SONET systems. > > TOM: We can save on a lot of text and remove the "MPLS-TE MUST" or > "MPLS-TP SHOULD" bits and simply say "MUST X" or "SHOULD Y". The MPLS-TP > bit is implicit I think. > > o MPLS-TP MUST support transport bandwidth allocation to any > granularity without any restrictions based on a circuit-switched > multiplexing hierarchy. This attribute will provide service > providers with the capability to route more customer service > demands over the MPLS-TP network. > > [Should we refer here to the requirements specified in RFC 2702?] > > 2.10. Security requirements > > o MPLS-TP MUST ensure that the network and services are secured. > > o Traffic flows from different users MUST NOT be intermingled, but > if this does occur then this MUST be detectable and the > appropriate consequent actions taken. > > o MPLS-TP MUST ensure the separation of customer (client) and > provider (server and peer network) addressing and other > information. > > TOM: This requirement is stated above. > > o MPLS-TP MUST ensure that the control and management planes as well > as OAM traffic are secure from external attack. > > o MPLS-TP MUST provide mechanisms to ensure that the MPLS-TP network > remains secure and stable under situations of extreme stress. > > Examples of attacks and situations of extreme stress include (but are > not limited to) classical security attacks (e.g., hijacking, privacy, > non-repudiation, etc.) and attacks on network availability (e.g., > denial of service (DoS) attacks). > > > 3. IANA Considerations > > This document makes no request of IANA. > > Note to RFC Editor: this section may be removed on publication as an > > > > Niven-Jenkins, et al. Expires January 2, 2009 [Page 15] > > Internet-Draft MPLS-TP Requirements July 2008 > > > RFC. > > > 4. Security Considerations > > This document does not by itself raise any particular security > considerations. > > > 5. Acknowledgements > > The authors wish to thank Neil Harrison and Tomonori Takeda for their > review and enhancements to the text. > > > 6. Informative References > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. > > [RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and > Restoration) Terminology for Generalized Multi-Protocol > Label Switching (GMPLS)", RFC 4427, March 2006. > > [ITU.Y1401.2008] > International Telecommunications Union, "Principles of > interworking", ITU-T Recommendation Y.1401, February 2008. > > > Authors' Addresses > > Ben Niven-Jenkins (editor) > BT > 208 Callisto House, Adastral Park > Ipswich, Suffolk IP5 3RE > UK > > Email: benjamin.niven-jenkins@bt.com > > > Deborah Brungard (editor) > AT&T > Rm. D1-3C22 - 200 S. Laurel Ave. > Middletown, NJ 07748 > USA > > Email: dbrungard@att.com > > > > > Niven-Jenkins, et al. Expires January 2, 2009 [Page 16] > > Internet-Draft MPLS-TP Requirements July 2008 > > > Malcolm Betts (editor) > Nortel Networks > 3500 Carling Avenue > Ottawa, Ontario K2H 8E9 > Canada > > Email: betts01@nortel.com > > > Nurit Sprecher > Nokia Siemens Networks > 3 Hanagar St. Neve Ne'eman B > Hod Hasharon, 45241 > Israel > > Email: nurit.sprecher@nsn.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Niven-Jenkins, et al. Expires January 2, 2009 [Page 17] > > Internet-Draft MPLS-TP Requirements July 2008 > > > Full Copyright Statement > > Copyright (C) The IETF Trust (2008). > > 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, THE IETF TRUST 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. > > > Intellectual Property > > 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. > > > > > > > > > > > > Niven-Jenkins, et al. Expires January 2, 2009 [Page 18] > > > > _______________________________________________ > Mpls-interop mailing list > Mpls-interop@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-interop _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop From mpls-interop-bounces@ietf.org Sun Jun 22 05:22:37 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6828328C0EF; Sun, 22 Jun 2008 05:22:37 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F4173A69D2 for ; Sun, 22 Jun 2008 05:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.074 X-Spam-Level: X-Spam-Status: No, score=-4.074 tagged_above=-999 required=5 tests=[AWL=1.925, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TLwoniY7hask for ; Sun, 22 Jun 2008 05:22:32 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 7B4B63A68D8 for ; Sun, 22 Jun 2008 05:22:31 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m5MCMVNL001447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Jun 2008 14:22:31 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m5MCMVLX009681; Sun, 22 Jun 2008 14:22:31 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 22 Jun 2008 14:22:31 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 22 Jun 2008 14:22:30 +0200 Message-ID: <9FF5BDAD88B9D84881609E89AC92FB83EBD38C@DEMUEXC014.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mpls-interop] next MEAD team meeting Thread-Index: AcjSMNQsx4BuurjX8EeQxIcfmO8exAA0/R+VAEuIunAACtuUpAABBM4g From: "Sprecher, Nurit (NSN - IL/Israel - MiniMD)" To: "ext Thomas Nadeau" , "Ben Niven-Jenkins" , "Loa Andersson" , "MEAD team" X-OriginalArrivalTime: 22 Jun 2008 12:22:31.0062 (UTC) FILETIME=[A46E1360:01C8D462] Cc: "Weingarten, Yaacov \(NSN - IL/Israel - MiniMD\)" Subject: Re: [Mpls-interop] next MEAD team meeting X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org Hi Tom, Thanks for your response. If you agree that the control plane in MPLS-TP is optional, then we cannot say MUST. To make it stronger, we may think of changing the "MAY" to "SHOULD". Best regards, Nurit -----Original Message----- From: ext Thomas Nadeau [mailto:tom.nadeau@bt.com] Sent: Sunday, June 22, 2008 14:52 To: Sprecher, Nurit (NSN - IL/Israel - MiniMD); Ben Niven-Jenkins; Loa Andersson; MEAD team Cc: Weingarten, Yaacov (NSN - IL/Israel - MiniMD) Subject: Re: [Mpls-interop] next MEAD team meeting On 6/22/08 5:45 AM, "Sprecher, Nurit (NSN - IL/Israel - MiniMD)" wrote: > Hi Thomas, > Thanks for your comments. > I still need to get into the details and meanings of your comments, > but in the meantime I have one basic concern on your comment on " > MPLS-TP connections MAY be able to be provisioned dynamically via a > control plane. TOM: I insist that we change the MAY above to MUST. I > want a dynamic version of this as much as a static one." > This is one of the fundamental principles of the MPLS-TP, that the > presence of a distributed control plane in support of network > operations is optional (as in other transport technologies, like in SDH, etc.). I agree it is optional. What I want to make sure is that it is not so optional that it is completely removed from the design. The language in the document now seems to be headed in that direction. > This is also the trigger for the definition of OAM capabilities which > are independent of a control plane, as well as of the protection > switching, etc. > This is also addressed by the slides of the JW: "Desire to statically > configure LSPs and PWEs via the management plane... I am not arguing against static; I am arguing for dynamic to be in there as well. > Transport OAM capabilities don't exist for LSP and PWE independent of > configuration mechanism (management plane or GMPLS or PWE control > plane)... It depends on how you look at what "transport OAM capabilities". >From my perspective at BT, I definitely think there is a dynamic flavor of this for sure. Again, I am not advocating removal of the static parts, just the addition of the dynamic ones. And since they are already there in large part, as part of the base MPLS specification, I don't see any harm in specifying this. --Tom > With static provisioning, no dependency on routing or signaling (e.g. > GMPLS or, IGP, RSVP, BGP, LDP)", etc. > Best regards, > Nurit > > -----Original Message----- > From: mpls-interop-bounces@ietf.org > [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext Thomas Nadeau > Sent: Friday, June 20, 2008 21:38 > To: Ben Niven-Jenkins; Loa Andersson; MEAD team > Subject: Re: [Mpls-interop] next MEAD team meeting > > > Comments on the document inline start with "TOM:" > In general, please review the document and put more of an emphasis on > the use of "MUST" rather than "MAY" or "SHOULD". The IETG frowns on > requirements documents that are too optional. > > --Tom > > > > > > Network Working Group B. Niven-Jenkins, Ed. > Internet-Draft BT > Intended status: Informational D. Brungard, Ed. > Expires: January 2, 2009 AT&T > M. Betts, Ed. > Nortel Networks > N. Sprecher > Nokia Siemens Networks > July 01, > 2008 > > > MPLS-TP Requirements > draft-jenkins-mpls-mplstp-requirements-00 > > Status of this Memo > > By submitting this Internet-Draft, each author represents that any > applicable patent or other IPR claims of which he or she is aware > have been or will be disclosed, and any of which he or she becomes > aware will be disclosed, in accordance with Section 6 of BCP 79. > > 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. > > This Internet-Draft will expire on January 2, 2009. > > Abstract > > This document will outline the requirements for MPLS-TP. > > Requirements Language > > 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 [RFC2119]. > > > > Niven-Jenkins, et al. Expires January 2, 2009 [Page 1] > > Internet-Draft MPLS-TP Requirements July 2008 > > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 2. MPLS-TP Requirements . . . . . . . . . . . . . . . . . . . . . 5 > 2.1. General requirements . . . . . . . . . . . . . . . . . . . 5 > 2.2. Layering requirements . . . . . . . . . . . . . . . . . . 6 > 2.3. Data plane requirements . . . . . . . . . . . . . . . . . 7 > 2.4. Control plane requirements . . . . . . . . . . . . . . . . 8 > 2.5. Network Management (NM) requirements . . . . . . . . . . . 11 > 2.6. OAM requirements . . . . . . . . . . . . . . . . . . . . . 11 > 2.7. Network performance management (PM) requirements . . . . . 11 > 2.8. Protection & Survivability requirements . . . . . . . . . 12 > 2.9. QoS requirements . . . . . . . . . . . . . . . . . . . . . 14 > 2.10. Security requirements . . . . . . . . . . . . . . . . . . 15 > 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 > 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 > 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 > 6. Informative References . . . . . . . . . . . . . . . . . . . . 16 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 > Intellectual Property and Copyright Statements . . . . . . . . . . > 18 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Niven-Jenkins, et al. Expires January 2, 2009 [Page 2] > > Internet-Draft MPLS-TP Requirements July 2008 > > > 1. Introduction > > For many years, SONET/SDH has provided service providers with a high > benchmark for reliability and operational simplicity. With the > accelerating growth of packet-based services (such as Ethernet, VoIP, > L2/L3 VPN, IPTV, RAN backhauling, etc.), service providers are in > need of capabilities to efficiently support packet-based services on > their transport networks. The need to increase their revenue while > remaining competitive forces operators to look for the lowest network > Total Cost of Ownership (TCO). Investment in both Capital > Expenditure (CAPEX) and Operational Expense (OPEX) should be minimal. > > Carriers are considering migrating to packet transport networks in > order to reduce their costs and to improve their ability to support > services with guaranteed SLAs. Migrating from SONET/SDH to packet > transport networks should not involve dramatic changes in network > operation, should not necessitate extensive retraining, and should > not require major changes to existing work practices. The aim is to > preserve the look-and-feel to which carriers have become accustomed > in deploying their SONET/SDH networks, while providing common, multi- > layer operations, resiliency, control and management for packet, > circuit and lambda transport networks. > > An important attribute of a transport network is its ability to > function independently from both its client and server (transmission > media) layer networks. It should be capable of transmitting over any > media. Another key characteristic of transport networks is the > capability to maintain the integrity of the client signal between its > ingress and egress ports. > > TOM: I would use something other than "client signal" here. Something > like "client path" or something is what I think you mean. > > A transport network must provide the means > to commit quality of service objectives to clients. This is achieved > by providing a mechanism for client network service demarcation for > the network path together with an associated network resiliency > mechanism. A transport network must also provide a method of service > monitoring in order to verify the delivery of an agreed quality of > service. This is enabled by means of carrier-grade OAM tools. > > The connectivity service is the basic service provided by a transport > network. > > TOM: Is it? Does the transport really provide connections or does it > provide transport paths? I am sensitive to the terms used here. We > don't want this to become a connect-fest. Seems to me that you explain > this better in the next sentence anyhow. > > The purpose of a transport network is to transparently > carry client signals (i.e. the stream of client PDUs or client > bits) > > TOM: Again, I don't like the term "signals" here. Use "client data" or > something. > > between endpoints in the network (typically over several intermediate > nodes). These endpoints may be service switching points or service > terminating points. The connectivity services offered to customers > are aggregated into large, long-holding time pipes/trunks which > > TOM: Do you really mean to call these "time pipes"? Sounds too > futuristic even for this work. *) I think you mean "...into > relatively large, long-lasting paths..." > > enable the efficient and reliable operation of the transport network. > These trunks are modified infrequently. > > TOM: Keep the terminology consistent here too. There is the use of > "trunks", "pipes", etc... > > Aggregation and hierarchy are beneficial for achieving scalability > and security since: > > > > Niven-Jenkins, et al. Expires January 2, 2009 [Page 3] > > Internet-Draft MPLS-TP Requirements July 2008 > > > 1. They reduce the number of provisioning and forwarding states in > the network core. > > 2. They reduce load and the cost of implementing service assurance > and fault management. > > TOM: Do they really reduce load? This is one of those fluffy, > open-ended terms like "scaleability" that I don't like used unless it > is clearly defined. > > 3. Client signals are completely encapsulated and isolated from each > other. This also allows complete isolation of customer traffic > from carrier operations. > > TOM: Does this really happen at the data or control plane or both? Or > do we care? > > > Client signals are first transparently encapsulated. These > encapsulated client signals are then aggregated for transport through > the network in order to optimize network management. Server layer > OAM is used to monitor the transport integrity of the client layer > aggregate. At any hop, the aggregated signals may be further > aggregated in lower layer transport network paths for transport > across intermediate shared links. The encapsulated client signals > are extracted at the edges of aggregation domains, and are either > delivered to the client or forwarded to another domain. In the core > of the network, only the server layer aggregated signals are > monitored; individual client signals are monitored at the network > boundary in the client layer network. > > TOM: I am not sure the above is appropriate for a requirements document. > It sounds like you are spelling out an algorithm for how a solution > should work. > > Quality-of-service mechanisms are required in the packet transport > network to ensure the prioritization of critical services, to > guarantee BW and to control jitter and delay. > > TOM: Are they required everywhere the service exists, or say just at > the ingress/egress for policing/marking functions? While we are on > the subject, do we want to be more specific about QoS requirements? > > Service providers require control and deterministic usage of network > resources. They need end-to-end control to engineer network paths > and to efficiently utilize network resources. They require > capabilities to statically (OSS based) provision deterministic, > protected and secured services and their associated resources as well > as alternative control-plane options. > > TOM: They also require dynamic ones. Please put that in. I don't want > to be asking for only a completely static system. > > The transport network must be capable of transporting multiple > services in a scalable manner. > > TOM: Again, this use of "scalable" offends me. Please be more specific > or take the sentence out as it is meaningless as stated. > > Carriers will still need to cope with legacy networks (which are > composed of many layers and technologies), thus the packet transport > network should interwork with other packet and transport networks > (both horizontally and vertically). Vertical interworking is also > known as client/server or network interworking. Horizontal > interworking is also known as peer-partition or service interworking. > > TOM: Didn't you just say that vertical interworking was client > interworking in the first sentence? How can horizontal be service > interworking as well? > > For more details on each type of interworking and some of the issues > that may arise (especially with horizontal interworking) see > [ITU.Y1401.2008]. > > MPLS is a maturing packet technology and it is already playing an > > > > Niven-Jenkins, et al. Expires January 2, 2009 [Page 4] > > Internet-Draft MPLS-TP Requirements July 2008 > > > important role in transport networks and services. However, not all > of MPLS's capabilities and mechnisms are needed and/or consistent > with transport network operations. This document identifies the > required capabilities for MPLS so that it can better fit a transport > role. > > TOM: I think you want to say "identifies the required sub-set of > capabilities..." and later "potentially new ons specific for > transport networks" which it seems you say two paragraphs later. > > Combining the packet experience of MPLS with the operational > experience of SONET/SDH constitutes a packet transport technology > named MPLS-TP. MPLS-TP will enable the migration of SONET/SDH > networks to a packet-based network that will easily scale to support > packet services in a simple and cost effective way. > > MPLS-TP needs to combine the necessary existing capabilities of MPLS > with additional minimal mechanisms in order to meet the requirements > described in this document. > > The requirements of an MPLS transport profile are provided below. > > TOM: There is a terminology issue in the use of "MPLS-TP" or "an MPLS > transport profile". That is, on the one hand you refer to a > technology, but on the other hand you are referring to a specific > profile. Which is it? > > > 2. MPLS-TP Requirements > > 2.1. General requirements > > o MPLS-TP MUST offer as much commonality as possible with the MPLS > user plane as defined by IETF. When MPLS offers multiple options > in this respect, MPLS-TP SHOULD select the minimum sub-set > (necessary and sufficient subset) applicable to a transport > network application. > > o Any new functionality that is defined to fulfil the requirements > for MPLS-TP MUST be agreed within IETF and re-use (as far as > practically possible) existing MPLS standards. > > o Mechanisms and capabilities MUST be able to interoperate with > existing MPLS and PWE control and data planes where appropriate. > > TOM: Change PWE to "IETF PWE3" and "MPLS" to "IETF MPLS". There also > need to be references here to the PWE3 architecture and MPLS > architectures. > > o MPLS-TP MUST support traffic engineering capabilities that allow > deterministic control of the use of network resources. > > o MPLS-TP MUST support the logical separation of the control and > management planes from the user plane. > > o MPLS-TP SHOULD support the physical separation of the control and > management planes from the user plane. > > o MPLS-TP MUST support point to point (P2P) or point to multipoint > (P2MP) connections. > > TOM: Are we avoiding MP2MP consciously or was it left out? > > > Niven-Jenkins, et al. Expires January 2, 2009 [Page 5] > > Internet-Draft MPLS-TP Requirements July 2008 > > > o MPLS-TP MUST support static provisioning of connections via an > NMS/OSS (i.e. via the management plane). > > o Static provisioning MUST not depend on routing or signaling > protocols (e.g. GMPLS, OSPF, IS-IS, RSVP, BGP, LDP etc.). > > o MPLS-TP connections MAY be able to be provisioned dynamically via > a control plane. > > TOM: I insist that we change the MAY above to MUST. I want a dynamic > version of this as much as a static one. > > > o The MPLS-TP data plane MUST be capable of functioning > independently of the control or management plane used to operate > the MPLS-TP layer network. That is the MPLS-TP data plane > operation MUST continue to operate normally if the management > plane or control plane that configured the connections fails. > > o MPLS-TP MUST support any network topology and be able to support > increasing bandwidth demands, topology, number of customers or > number of services incrementally. > > > TOM: I think it is imperative that although an MPLS-TP is defined to > play nicely with an MPLS one, it is imperative that one can > distinguish between both, at least at the control plane, but perhaps > at the data plane as well. > > 2.2. Layering requirements > > o An MPLS-TP network MUST operate in a multiple layer network > environment consisting of the following independent layers: > > 1. A "service layer" instance in which the connections carry the > customer's (individual or bundled) service (may be point-to- > point, point-to-multipoint or multipoint-to-multipoint > services); > > 2. A "trunk layer" with point-to-point or point-to-multipoint > connections which are used to carry aggregates of the network > "service layer" connections; and > > 3. A "transmission media layer" which provides sections (two-port > point-to-point connections) to carry the aggregate of network > trunk or network service connections on various physical > media. > > TOM: This stuff belongs in the Terminology section at the top. > > MPLS-TP may provide the "service layer" (for P2P and P2MP services) > and/or the "trunk layer" within a layer network environment. > > o An MPLS-TP layer network MUST support the transparent transport of > MPLS-TP and non MPLS-TP client layer networks. > > o An MPLS-TP layer network MUST be able to be transparently carried > over MPLS-TP and non MPLS-TP server layer networks (such as > Ethernet, OTN, etc.) > > > > > Niven-Jenkins, et al. Expires January 2, 2009 [Page 6] > > Internet-Draft MPLS-TP Requirements July 2008 > > > o It MUST be possible to operate the MPLS-TP layer network > independently of other layer networks (either MPLS-TP or non > MPLS-TP). > > This is not only a technology requirement, different administrative > groups may be responsible for different layer networks (even when > they are of the same type)), and require the capability to > operationally support the different layers. > > o It MUST be possible to hide MPLS-TP layer network addressing and > other information (e.g. topology) from client layers. > > 2.3. Data plane requirements > > o The identification of each connection within its aggregate MUST be > supported. > > o A label in a particular section MUST uniquely identify the > connection. > > o A connection's source MUST be identifiable at its destination. > > Connections can be aggregated into trunks by pushing and de- > aggregated by popping labels. MPLS-TP labels may be swapped within a > connection in a layer network instance when the traffic is forwarded > from one MPLS-TP link connection to another MPLS-TP link connection. > > o Labelling MUST make use of the MPLS label and label stack entry as > defined in RFC3032. > > o It MUST be possible to operate and configure the MPLS-TP data > (transport) plane without any IP functionality. > > o MPLS-TP MUST support both unidirectional and bi-directional point- > to-point connections. > > o The forward and backward directions of a bi-directional connection > SHOULD follow the same path within the MPLS-TP network. > > TOM: I am not sure if we say that they SHOULD as much as "they MUST be > capable of". > > o The intermediate nodes SHOULD be aware about the binding of the > forward and the backward directions belonging to the same bi- > directional connection. > > TOM: Again, "SHOULD be capable of" seems better. > > o MPLS-TP SHOULD support unidirectional point-to-multipoint > connections. > > o MPLS-TP connections MUST NOT perform merging in a way that > prevents the unique identification of the source at the > > > > Niven-Jenkins, et al. Expires January 2, 2009 [Page 7] > > Internet-Draft MPLS-TP Requirements July 2008 > > > destination (e.g. no use of LDP mp2p signaling in order to avoid > losing LSP head-end information, no use of PHP, etc). > > o MPLS-TP SHOULD support transport and QoS mechanisms that can > deliver statistical multiplexing gain. Packets exceeding the > agreed traffic profile may be marked or discarded by the traffic > conditioning at the ingress of the MPLS-TP network. > > TOM: How about egress policing + marking? > > > o MPLS-TP MUST support connections through a single domain. > > o MPLS-TP SHOULD support connections through multiple domains. > > o MPLS-TP MUST be able to accommodate new traffic types. > > TOM: New traffic types other than those supported by MPLS? This > doesn't make sense to me as this will result in MPLS-TP not being a > subset of MPLS. > > o MPLS-TP SHOULD support mechanisms to safeguard against the > provisioning of connections which contain forwarding loops. > > o MPLS-TP SHOULD support mechanisms to minimize traffic impact > during network reconfiguration. > > o MPLS-TP SHOULD support mechanisms which ensure the integrity of > the adapted information. > > o MPLS-TP MUST support an unambiguous and reliable means of > distinguishing users' (client) packets from MPLS-TP control plane > and management plane packets. > > 2.4. Control plane requirements > > o A distributed control plane MAY be supported to enable fast, > dynamic and reliable service provisioning in multi-vendor and > multi-domain environments using standardized protocols that > guarantee interoperability. > > o If a control plane is used for configuration of MPLS-TP > connections then: > > * Failure and recovery of the control plane MUST NOT impact the > MPLS-TP forwarding plane. > > TOM: This is difficult, as this really is handled in practice at both > data and control planes, depending on how this is configured/designed, > and the re-signaling can impact the data plane. > > * It MUST support the setup, modification, and release of MPLS-TP > connections and protection connections. > > * It MUST support mechanisms to provide traffic engineering, > constraint-based routing and explicit path control. > > * It MUST provide mechanisms to address QoS and performance > requirements (such as throughput, delay, packet loss, etc.) > > > > Niven-Jenkins, et al. Expires January 2, 2009 [Page 8] > > Internet-Draft MPLS-TP Requirements July 2008 > > > while utilizing network resources efficiently and reliably. > > o MPLS-TP SHOULD support off-path (out-of-band) control and > management planes. > > o The MPLS-TP control plane MUST be independent of any particular > client or server layer control plane. > > o The control plane SHOULD facilitate the implementation of the > service by providing end-to-end seamless connectivity and service > assurance. > > o The MPLS-TP control plane MUST support establishing all the > connectivity patterns defined for the MPLS-TP transport plane > (e.g., uni-directional and bidirectional P2P, uni-directional > P2MP, etc.) including configuration of protection functions and > any associated maintenance functions. > > o The MPLS-TP control pane must support the configuration and > modification of OAM maintenance points as well as the activation/ > deactivation of OAM when the connection is established or > modified. > > o An MPLS-TP control plane MUST support topology hiding and address > independence between domains. > > o At the boundary of a domain an MPLS-TP control plane MUST support > unique names or addresses identifying boundary points to be > interconnected. > > o At the boundary of a domain an MPLS-TP control plane must support > group names or addresses identifying sets of boundary points to be > interconnected. > > o MPLS-TP layer network access points (or connection points that > proxy for access points) SHOULD be able to be assigned names which > are available to clients to identify endpoints in call or > connection requests. > > o An MPLS-TP control plane MUST support translation between > externally visible endpoint names and internal network addresses. > > o An MPLS-TP control plane MUST support constraint-based route > calculation. > > o An MPLS-TP control plane MUST support provisioning and application > of routing constraint policies. > > > > > Niven-Jenkins, et al. Expires January 2, 2009 [Page 9] > > Internet-Draft MPLS-TP Requirements July 2008 > > > o An MPLS-TP control plane MUST support pre-provisioned connection > protection. > > In some situations it is impractical to expect acceptable recovery > performance to be achieved using dynamic recalculation of connection > routes. For this reason, it is necessary to allow for pre-planning > of protection routes for selected connections. > > o The MPLS-TP control plane MUST support fast restoration. > > TOM: Define what "fast" means? > > o An MPLS-TP control plane MUST scale gracefully to support a large > number of connections. > > TOM: Define "large" and "scale" here? > > [Include some numbers to indicate how large the CP is expected to > scale to?] > > o An MPLS-TP control plane MUST clearly distinguish resources > belonging to the MPLS-TP layer network from those in other layer > networks that may also be under control plane control. > > TOM: Do you mean under the same control plane or a different one (or > both)? > > o An MPLS-TP control plane MUST support the independent > identification of logically distinct control plane elements. > > o It MUST be possible to identify and provision these elements > independently, in order to reorganize the control plane components > without impacting the data plane services and vice-versa. > > Architecturally distinct elements in a control plane include: nodes > and links, control plane functional components, protocol controllers, > etc. > > o An MPLS-TP control plane SHOULD provide a common control mechanism > for architecturally similar operations. > > o An MPLS-TP control plane MUST support mechanisms for partitioning > the network under control into separate peer or hierarchical > control domains. > > o To enable the deployment of a unified control plane aimed at > controlling the set of transport technologies used in a transport > network, the MPLS-TP control plane MUST also be applicable to > other transport layer networks and provide common operations > across multiple layers. In order to maintain independence between > MPLS-TP and its respective client and server layer network > separate control plane instances SHOULD be used to control a set > of transport layer networks. > > > > > > Niven-Jenkins, et al. Expires January 2, 2009 [Page 10] > > Internet-Draft MPLS-TP Requirements July 2008 > > > o MPLS-TP SHOULD detect and recover from control plane failures and > degradations using graceful operations. > > 2.5. Network Management (NM) requirements > > o MPLS-TP MUST operate under a common operation, control and > management paradigm with respect to other transport technologies > (e.g. SDH, OTN or WDM). > > o An MPLS-TP network MUST be able to be operated with a centralized > NMS system. > > o An MPLS-TP network SHOULD be able to be operated by a centralized > NMS system with the support of a distributed control plane. > > TOM: I don't know what this means or the one above it, or how this > requirement would translate into anything tangible in the MPLS-TP > protocol designs. I suggest it be removed. > > o The MPLS-TP management plane MUST NOT depend on a specific client > layer management plane. > > TOM: This is a non-sequitur if you ask me; please strike it. > > o The MPLS-TP management plane MUST support the configuration and > modification of OAM maintenance points as well as the activation/ > deactivation of OAM when the connection is established or > modified. > > For the complete set of requirements related to NM functionality for > MPLS-TP, see the MPLS-TP NM requirements document [REF]. > > 2.6. OAM requirements > > o MPLS-TP SHOULD provide a comprehensive set of capabilities (that > are independent of and agnostic to the transmitted client > services) to support fault management, performance monitoring (of > the MPLS-TP network and the services), protection switching, fault > localization, signal quality measurement, etc. > > o A mechanism SHOULD be supported to detect, diagnose and enable > recovery from facility and equipment failures and performance > degradations according to the requirements of the service. > > o MPLS-TP OAM MUST be able to operate without IP functionality and > without relying on control and/or management planes. > > For the complete set of requirements related to OAM functionality for > MPLS-TP, see the MPLS-TP OAM requirements document [REF]. > > TOM: I suggest you just remove these two sections and refer to the > OAM/Managemetn documents. > > 2.7. Network performance management (PM) requirements > > > > > > > Niven-Jenkins, et al. Expires January 2, 2009 [Page 11] > > Internet-Draft MPLS-TP Requirements July 2008 > > > o MPLS-TP MUST support traffic-engineering capabilities with > traffic- and/or resource-oriented performance objectives. > > TOM: What are performance objectives? Do you mean traffic profiles > such as QoS/bandwidth? > > o MPLS-TP MUST support a method to offer packet loss objectives > comparable to those in TDM transport networks (only due to bit > errors). > > For the complete set of requirements related to PM functionality for > MPLS-TP, see the MPLS-TP OAM requirements document [REF]. > > TOM: Again, I suggest you punt on this entire section and move it to > the OAM doc. > > 2.8. Protection & Survivability requirements > > Network survivability plays a critical factor in the delivery of > reliable services. Network availability is a significant contributor > to revenue and profit. Service guarantees in the form of SLAs > require a resilient network that rapidly detects facility or node > failures and restores network operation in accordance with the terms > of the SLA. > > The requirements in this section use of the recovery terminology > defined in RFC 4427[RFC4427]. > > o MPLS-TP SHOULD support transport network style protection > > TOM: I would make this a MUST. > > switching mechanisms (tandem network connection protection, LSP > protection and PW protection) to provide the sub-50ms recovery > time required to maintain customer transparency, even when > thousands of services are simultaneously affected by a failure. > [Is sub-50ms really a requirement, do we want to clarify this > further - is it sub-50ms end to end, or per link?] > > o > > * MPLS-TP recovery mechanisms SHOULD be applicable at various > levels throughout the network, SPAN, tandem connection and end- > to-end. > > TOM: This sentence doesn't parse. Please re-write. > > Any recovery mechanism used in a tandem connection > MUST be independent of other tandem connections. > > * MPLS-TP SHOULD support mechanisms that keep traffic flowing > while the network recovers from failures. > > TOM: I would say this is a MUST. > > * MPLS-TP SHOULD support network restoration mechanisms > controlled by a distributed control plane and/or by a > management plane based. > > TOM: I would say this is a MUST. > > > * > > + The restoration resources MAY be pre-planned and selected a > priori, or computed after failure occurrence. > > > > Niven-Jenkins, et al. Expires January 2, 2009 [Page 12] > > Internet-Draft MPLS-TP Requirements July 2008 > > > + MPLS-TP MAY support shared-mesh restoration. > > + MPLS-TP SHOUD support soft LSP restoration. > > + MPLS-TP MAY support hard LSP restoration. > > + The restoration mechanism MUST be applicable to any > topology. > > + Restoration priority MAY be implemented to determine the > order in which connections should be restored (to minimize > service restoration time as well as to gain access to > available spare capacity on the best paths). Preemption > priority MAY be used in the event that not all connections > can be restored, in which case connections with lower > preemption priority should be released. > > + The restoration mechanism SHOULD operate in synergy with > other transport network technologies (SDH, OTN, WDM). > > * MPLS-TP SHOULD support data plane driven protection mechanisms > (without any dependency on a control plane or IP protocols) to > enable fast recovery from failure, and thereby to enhance the > reliability and availability performance of MPLS-TP networks. > > * > > + MPLS-TP protection mechanisms SHOULD be applied to LSPs and > PWs. > > + MPLS-TP MUST support mechanisms that rapidly detect, locate, > notify and remedy network faults. > > + MPLS-TP MUST support 1:1 bidirectional protection switching. > The protection state of both ends of the protected entity > MUST be synchronized. > > + MPLS-TP MAY support 1+1 unidirectional protection switching. > > + MPLS-TP protection mechanisms MUST be applicable to both > point-to-point and point-to-multipoint connections. > > + It SHOULD be possible to achieve protection at the MPLS-TP > layer as fast as possible (subject to the temporal > resolution of the defect detection mechanism). > > + Protection ratio MUST be of 100%, i.e., 100% of impaired > working traffic MUST be protected for a failure on a > single > > > > Niven-Jenkins, et al. Expires January 2, 2009 [Page 13] > > Internet-Draft MPLS-TP Requirements July 2008 > > > working LSP. > > + Operator requests for manual control of protection switching > such as clear, lockout of protection, forced-switch and > manual-switch commands MUST be supported. Prioritized > protection between Signal Fail (SF), Signal Degradation (SD) > and operator switch requests MUST be supported. > > + MPLS-TP protection mechanisms MUST support revertive and > non-revertive behaviour. o An extra traffic capability > SHOULD be supported when possible. > > + MPLS-TP protection switching mechanisms MUST prevent > frequent operation of the protection switch due to an > intermittent defect. > > + MPLS-TP protection mechanisms MUST ensure co-ordination of > timing of protection switches at multiple layers to avoid > races and to allow the protection switching mechanism of the > server layer to fix the problem before switching at the > MPLS-TP layer. > > + MPLS-TP MAY support mechanisms that are optimized for > specific network topologies (Ring, Mesh) in order to handle > protection switching in a cost-efficient manner. > > 2.9. QoS requirements > > Service providers require advanced traffic management capabilities to > enforce and guarantee the QoS parameters of customers' SLAs. > > Quality of service mechanisms are required to ensure: > > o Support for differentiated services and different traffic types > with traffic class separation associated with different traffic. > > o Prioritization of critical services. > > o Enabling the provisioning and the guarantee of Service Level > Specifications (SLS), with support for hard and relative end-to- > end BW guaranteed. > > o Controlled jitter and delay. > > o Guarantee of fair access to shared resources in an MPLS-TP > network. > > > > > > Niven-Jenkins, et al. Expires January 2, 2009 [Page 14] > > Internet-Draft MPLS-TP Requirements July 2008 > > > o Ability for OAM and data to share the same fate. > > TOM: This belongs in the OAM document. > > > o Resources for control and management plane packets so that user > plane traffic, regardless of the amount, will not cause control > and management functions to become inoperative. > > The following QoS requirements apply to MPLS-TP: > > o MPLS-TP MUST be able to deliver the same degree of QoS that has > been delivered by SDH/SONET systems. > > TOM: We can save on a lot of text and remove the "MPLS-TE MUST" or > "MPLS-TP SHOULD" bits and simply say "MUST X" or "SHOULD Y". The > MPLS-TP bit is implicit I think. > > o MPLS-TP MUST support transport bandwidth allocation to any > granularity without any restrictions based on a circuit-switched > multiplexing hierarchy. This attribute will provide service > providers with the capability to route more customer service > demands over the MPLS-TP network. > > [Should we refer here to the requirements specified in RFC 2702?] > > 2.10. Security requirements > > o MPLS-TP MUST ensure that the network and services are secured. > > o Traffic flows from different users MUST NOT be intermingled, but > if this does occur then this MUST be detectable and the > appropriate consequent actions taken. > > o MPLS-TP MUST ensure the separation of customer (client) and > provider (server and peer network) addressing and other > information. > > TOM: This requirement is stated above. > > o MPLS-TP MUST ensure that the control and management planes as well > as OAM traffic are secure from external attack. > > o MPLS-TP MUST provide mechanisms to ensure that the MPLS-TP network > remains secure and stable under situations of extreme stress. > > Examples of attacks and situations of extreme stress include (but are > not limited to) classical security attacks (e.g., hijacking, privacy, > non-repudiation, etc.) and attacks on network availability (e.g., > denial of service (DoS) attacks). > > > 3. IANA Considerations > > This document makes no request of IANA. > > Note to RFC Editor: this section may be removed on publication as > an > > > > Niven-Jenkins, et al. Expires January 2, 2009 [Page 15] > > Internet-Draft MPLS-TP Requirements July 2008 > > > RFC. > > > 4. Security Considerations > > This document does not by itself raise any particular security > considerations. > > > 5. Acknowledgements > > The authors wish to thank Neil Harrison and Tomonori Takeda for their > review and enhancements to the text. > > > 6. Informative References > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. > > [RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and > Restoration) Terminology for Generalized Multi-Protocol > Label Switching (GMPLS)", RFC 4427, March 2006. > > [ITU.Y1401.2008] > International Telecommunications Union, "Principles of > interworking", ITU-T Recommendation Y.1401, February 2008. > > > Authors' Addresses > > Ben Niven-Jenkins (editor) > BT > 208 Callisto House, Adastral Park > Ipswich, Suffolk IP5 3RE > UK > > Email: benjamin.niven-jenkins@bt.com > > > Deborah Brungard (editor) > AT&T > Rm. D1-3C22 - 200 S. Laurel Ave. > Middletown, NJ 07748 > USA > > Email: dbrungard@att.com > > > > > Niven-Jenkins, et al. Expires January 2, 2009 [Page 16] > > Internet-Draft MPLS-TP Requirements July 2008 > > > Malcolm Betts (editor) > Nortel Networks > 3500 Carling Avenue > Ottawa, Ontario K2H 8E9 > Canada > > Email: betts01@nortel.com > > > Nurit Sprecher > Nokia Siemens Networks > 3 Hanagar St. Neve Ne'eman B > Hod Hasharon, 45241 > Israel > > Email: nurit.sprecher@nsn.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Niven-Jenkins, et al. Expires January 2, 2009 [Page 17] > > Internet-Draft MPLS-TP Requirements July 2008 > > > Full Copyright Statement > > Copyright (C) The IETF Trust (2008). > > 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, THE IETF TRUST 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. > > > Intellectual Property > > 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. > > > > > > > > > > > > Niven-Jenkins, et al. Expires January 2, 2009 [Page 18] > > > > _______________________________________________ > Mpls-interop mailing list > Mpls-interop@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-interop _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop From mpls-interop-bounces@ietf.org Sun Jun 22 05:39:55 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ABB73A67B6; Sun, 22 Jun 2008 05:39:55 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 646A63A69BD for ; Sun, 22 Jun 2008 05:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.932 X-Spam-Level: X-Spam-Status: No, score=-0.932 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ysYkwsnyj+pT for ; Sun, 22 Jun 2008 05:39:50 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 17DB23A67B6 for ; Sun, 22 Jun 2008 05:39:49 -0700 (PDT) Received: from E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.109]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Jun 2008 13:39:54 +0100 Received: from 217.32.164.184 ([217.32.164.184]) by E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.60]) via Exchange Front-End Server mail.bt.com ([193.113.197.28]) with Microsoft Exchange Server HTTP-DAV ; Sun, 22 Jun 2008 12:39:53 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Sun, 22 Jun 2008 13:39:51 +0100 From: Ben Niven-Jenkins To: Thomas Nadeau , "Sprecher, Nurit (NSN - IL/Israel - MiniMD)" , Loa Andersson , MEAD team Message-ID: Thread-Topic: [Mpls-interop] next MEAD team meeting Thread-Index: AcjSMNQsx4BuurjX8EeQxIcfmO8exAA0/R+VAEuIunAACtuUpAABrZoI In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 22 Jun 2008 12:39:54.0795 (UTC) FILETIME=[128B17B0:01C8D465] Cc: "Weingarten, Yaacov \(NSN - IL/Israel - MiniMD\)" Subject: Re: [Mpls-interop] next MEAD team meeting X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org I think the key thing is that MPLS-TP must be able to operate (including OAM) in the absence of a control plane. The option is then down to whether we say both static & dynamic are MUSTs (from an implementation perspective) and the operator is then free to choose whether they operate their network statically or dynamically. Or whether only static is a MUST and dynamic is optional (for implementation). I believe the work in ITU intended to extend to dynamic at some point and static was just a first step in the T-MPLS work. It only take one operator to demand dynamic from their vendors for it to be present in equipment anyway even if it is not used by other operators. So I think we can make both static & dynamic MUSTs and then clarify that when operating in a static mode MPLS-TP must not rely on any dynamic protocols. We cover this (at least to some extent) already with requirements such as " Static provisioning MUST not depend on routing or signaling protocols (e.g. GMPLS, OSPF, IS-IS, RSVP, BGP, LDP etc.)." Ben On 22/06/2008 12:51, "Thomas Nadeau" wrote: > > > > On 6/22/08 5:45 AM, "Sprecher, Nurit (NSN - IL/Israel - MiniMD)" > wrote: > >> Hi Thomas, >> Thanks for your comments. >> I still need to get into the details and meanings of your comments, but >> in the meantime I have one basic concern on your comment on " MPLS-TP >> connections MAY be able to be provisioned dynamically via a control >> plane. TOM: I insist that we change the MAY above to MUST. I want a >> dynamic version of this as much as a static one." >> This is one of the fundamental principles of the MPLS-TP, that the >> presence of a distributed control plane in support of network operations >> is optional (as in other transport technologies, like in SDH, etc.). > > I agree it is optional. What I want to make sure is that it is not so > optional that it is completely removed from the design. The language in the > document now seems to be headed in that direction. > >> This is also the trigger for the definition of OAM capabilities which >> are independent of a control plane, as well as of the protection >> switching, etc. >> This is also addressed by the slides of the JW: "Desire to statically >> configure LSPs and PWEs via the management plane... > > I am not arguing against static; I am arguing for dynamic to be in there > as well. > >> Transport OAM capabilities don't exist for LSP and PWE independent of >> configuration mechanism (management plane or GMPLS or PWE control >> plane)... > > It depends on how you look at what "transport OAM capabilities". From my > perspective at BT, I definitely think there is a dynamic flavor of this for > sure. Again, I am not advocating removal of the static parts, just the > addition of the dynamic ones. And since they are already there in large > part, as part of the base MPLS specification, I don't see any harm in > specifying this. > > --Tom > > > >> With static provisioning, no dependency on routing or signaling >> (e.g. GMPLS or, IGP, RSVP, BGP, LDP)", etc. >> Best regards, >> Nurit >> >> -----Original Message----- >> From: mpls-interop-bounces@ietf.org >> [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext Thomas Nadeau >> Sent: Friday, June 20, 2008 21:38 >> To: Ben Niven-Jenkins; Loa Andersson; MEAD team >> Subject: Re: [Mpls-interop] next MEAD team meeting >> >> >> Comments on the document inline start with "TOM:" >> In general, please review the document and put more of an emphasis on >> the use of "MUST" rather than "MAY" or "SHOULD". The IETG frowns on >> requirements documents that are too optional. >> >> --Tom >> >> >> >> >> >> Network Working Group B. Niven-Jenkins, Ed. >> Internet-Draft BT >> Intended status: Informational D. Brungard, Ed. >> Expires: January 2, 2009 AT&T >> M. Betts, Ed. >> Nortel Networks >> N. Sprecher >> Nokia Siemens Networks >> July 01, 2008 >> >> >> MPLS-TP Requirements >> draft-jenkins-mpls-mplstp-requirements-00 >> >> Status of this Memo >> >> By submitting this Internet-Draft, each author represents that any >> applicable patent or other IPR claims of which he or she is aware >> have been or will be disclosed, and any of which he or she becomes >> aware will be disclosed, in accordance with Section 6 of BCP 79. >> >> 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. >> >> This Internet-Draft will expire on January 2, 2009. >> >> Abstract >> >> This document will outline the requirements for MPLS-TP. >> >> Requirements Language >> >> 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 [RFC2119]. >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page 1] >> >> Internet-Draft MPLS-TP Requirements July 2008 >> >> >> Table of Contents >> >> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 >> 2. MPLS-TP Requirements . . . . . . . . . . . . . . . . . . . . . 5 >> 2.1. General requirements . . . . . . . . . . . . . . . . . . . 5 >> 2.2. Layering requirements . . . . . . . . . . . . . . . . . . 6 >> 2.3. Data plane requirements . . . . . . . . . . . . . . . . . 7 >> 2.4. Control plane requirements . . . . . . . . . . . . . . . . 8 >> 2.5. Network Management (NM) requirements . . . . . . . . . . . 11 >> 2.6. OAM requirements . . . . . . . . . . . . . . . . . . . . . 11 >> 2.7. Network performance management (PM) requirements . . . . . 11 >> 2.8. Protection & Survivability requirements . . . . . . . . . 12 >> 2.9. QoS requirements . . . . . . . . . . . . . . . . . . . . . 14 >> 2.10. Security requirements . . . . . . . . . . . . . . . . . . 15 >> 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 >> 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 >> 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 >> 6. Informative References . . . . . . . . . . . . . . . . . . . . 16 >> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 >> Intellectual Property and Copyright Statements . . . . . . . . . . 18 >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page 2] >> >> Internet-Draft MPLS-TP Requirements July 2008 >> >> >> 1. Introduction >> >> For many years, SONET/SDH has provided service providers with a high >> benchmark for reliability and operational simplicity. With the >> accelerating growth of packet-based services (such as Ethernet, VoIP, >> L2/L3 VPN, IPTV, RAN backhauling, etc.), service providers are in >> need of capabilities to efficiently support packet-based services on >> their transport networks. The need to increase their revenue while >> remaining competitive forces operators to look for the lowest network >> Total Cost of Ownership (TCO). Investment in both Capital >> Expenditure (CAPEX) and Operational Expense (OPEX) should be minimal. >> >> Carriers are considering migrating to packet transport networks in >> order to reduce their costs and to improve their ability to support >> services with guaranteed SLAs. Migrating from SONET/SDH to packet >> transport networks should not involve dramatic changes in network >> operation, should not necessitate extensive retraining, and should >> not require major changes to existing work practices. The aim is to >> preserve the look-and-feel to which carriers have become accustomed >> in deploying their SONET/SDH networks, while providing common, multi- >> layer operations, resiliency, control and management for packet, >> circuit and lambda transport networks. >> >> An important attribute of a transport network is its ability to >> function independently from both its client and server (transmission >> media) layer networks. It should be capable of transmitting over any >> media. Another key characteristic of transport networks is the >> capability to maintain the integrity of the client signal between its >> ingress and egress ports. >> >> TOM: I would use something other than "client signal" here. Something >> like "client path" or something is what I think you mean. >> >> A transport network must provide the means >> to commit quality of service objectives to clients. This is achieved >> by providing a mechanism for client network service demarcation for >> the network path together with an associated network resiliency >> mechanism. A transport network must also provide a method of service >> monitoring in order to verify the delivery of an agreed quality of >> service. This is enabled by means of carrier-grade OAM tools. >> >> The connectivity service is the basic service provided by a transport >> network. >> >> TOM: Is it? Does the transport really provide connections or does it >> provide transport paths? I am sensitive to the terms used here. We >> don't want this to become a connect-fest. Seems to me that you explain >> this better in the next sentence anyhow. >> >> The purpose of a transport network is to transparently >> carry client signals (i.e. the stream of client PDUs or client bits) >> >> TOM: Again, I don't like the term "signals" here. Use "client data" or >> something. >> >> between endpoints in the network (typically over several intermediate >> nodes). These endpoints may be service switching points or service >> terminating points. The connectivity services offered to customers >> are aggregated into large, long-holding time pipes/trunks which >> >> TOM: Do you really mean to call these "time pipes"? Sounds too >> futuristic even for this work. *) I think you mean "...into relatively >> large, long-lasting paths..." >> >> enable the efficient and reliable operation of the transport network. >> These trunks are modified infrequently. >> >> TOM: Keep the terminology consistent here too. There is the use of >> "trunks", "pipes", etc... >> >> Aggregation and hierarchy are beneficial for achieving scalability >> and security since: >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page 3] >> >> Internet-Draft MPLS-TP Requirements July 2008 >> >> >> 1. They reduce the number of provisioning and forwarding states in >> the network core. >> >> 2. They reduce load and the cost of implementing service assurance >> and fault management. >> >> TOM: Do they really reduce load? This is one of those fluffy, open-ended >> terms like "scaleability" that I don't like used unless it is clearly >> defined. >> >> 3. Client signals are completely encapsulated and isolated from each >> other. This also allows complete isolation of customer traffic >> from carrier operations. >> >> TOM: Does this really happen at the data or control plane or both? Or do >> we care? >> >> >> Client signals are first transparently encapsulated. These >> encapsulated client signals are then aggregated for transport through >> the network in order to optimize network management. Server layer >> OAM is used to monitor the transport integrity of the client layer >> aggregate. At any hop, the aggregated signals may be further >> aggregated in lower layer transport network paths for transport >> across intermediate shared links. The encapsulated client signals >> are extracted at the edges of aggregation domains, and are either >> delivered to the client or forwarded to another domain. In the core >> of the network, only the server layer aggregated signals are >> monitored; individual client signals are monitored at the network >> boundary in the client layer network. >> >> TOM: I am not sure the above is appropriate for a requirements document. >> It sounds like you are spelling out an algorithm for how a solution >> should work. >> >> Quality-of-service mechanisms are required in the packet transport >> network to ensure the prioritization of critical services, to >> guarantee BW and to control jitter and delay. >> >> TOM: Are they required everywhere the service exists, or say just at the >> ingress/egress for policing/marking functions? While we are on the >> subject, do we want to be more specific about QoS requirements? >> >> Service providers require control and deterministic usage of network >> resources. They need end-to-end control to engineer network paths >> and to efficiently utilize network resources. They require >> capabilities to statically (OSS based) provision deterministic, >> protected and secured services and their associated resources as well >> as alternative control-plane options. >> >> TOM: They also require dynamic ones. Please put that in. I don't want >> to be asking for only a completely static system. >> >> The transport network must be capable of transporting multiple >> services in a scalable manner. >> >> TOM: Again, this use of "scalable" offends me. Please be more specific >> or take the sentence out as it is meaningless as stated. >> >> Carriers will still need to cope with legacy networks (which are >> composed of many layers and technologies), thus the packet transport >> network should interwork with other packet and transport networks >> (both horizontally and vertically). Vertical interworking is also >> known as client/server or network interworking. Horizontal >> interworking is also known as peer-partition or service interworking. >> >> TOM: Didn't you just say that vertical interworking was client >> interworking in the first sentence? How can horizontal be service >> interworking as well? >> >> For more details on each type of interworking and some of the issues >> that may arise (especially with horizontal interworking) see >> [ITU.Y1401.2008]. >> >> MPLS is a maturing packet technology and it is already playing an >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page 4] >> >> Internet-Draft MPLS-TP Requirements July 2008 >> >> >> important role in transport networks and services. However, not all >> of MPLS's capabilities and mechnisms are needed and/or consistent >> with transport network operations. This document identifies the >> required capabilities for MPLS so that it can better fit a transport >> role. >> >> TOM: I think you want to say "identifies the required sub-set of >> capabilities..." and later "potentially new ons specific for transport >> networks" which it seems you say two paragraphs later. >> >> Combining the packet experience of MPLS with the operational >> experience of SONET/SDH constitutes a packet transport technology >> named MPLS-TP. MPLS-TP will enable the migration of SONET/SDH >> networks to a packet-based network that will easily scale to support >> packet services in a simple and cost effective way. >> >> MPLS-TP needs to combine the necessary existing capabilities of MPLS >> with additional minimal mechanisms in order to meet the requirements >> described in this document. >> >> The requirements of an MPLS transport profile are provided below. >> >> TOM: There is a terminology issue in the use of "MPLS-TP" or "an MPLS >> transport profile". That is, on the one hand you refer to a technology, >> but on the other hand you are referring to a specific profile. Which is >> it? >> >> >> 2. MPLS-TP Requirements >> >> 2.1. General requirements >> >> o MPLS-TP MUST offer as much commonality as possible with the MPLS >> user plane as defined by IETF. When MPLS offers multiple options >> in this respect, MPLS-TP SHOULD select the minimum sub-set >> (necessary and sufficient subset) applicable to a transport >> network application. >> >> o Any new functionality that is defined to fulfil the requirements >> for MPLS-TP MUST be agreed within IETF and re-use (as far as >> practically possible) existing MPLS standards. >> >> o Mechanisms and capabilities MUST be able to interoperate with >> existing MPLS and PWE control and data planes where appropriate. >> >> TOM: Change PWE to "IETF PWE3" and "MPLS" to "IETF MPLS". There also >> need to be references here to the PWE3 architecture and MPLS >> architectures. >> >> o MPLS-TP MUST support traffic engineering capabilities that allow >> deterministic control of the use of network resources. >> >> o MPLS-TP MUST support the logical separation of the control and >> management planes from the user plane. >> >> o MPLS-TP SHOULD support the physical separation of the control and >> management planes from the user plane. >> >> o MPLS-TP MUST support point to point (P2P) or point to multipoint >> (P2MP) connections. >> >> TOM: Are we avoiding MP2MP consciously or was it left out? >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page 5] >> >> Internet-Draft MPLS-TP Requirements July 2008 >> >> >> o MPLS-TP MUST support static provisioning of connections via an >> NMS/OSS (i.e. via the management plane). >> >> o Static provisioning MUST not depend on routing or signaling >> protocols (e.g. GMPLS, OSPF, IS-IS, RSVP, BGP, LDP etc.). >> >> o MPLS-TP connections MAY be able to be provisioned dynamically via >> a control plane. >> >> TOM: I insist that we change the MAY above to MUST. I want a dynamic >> version of this as much as a static one. >> >> >> o The MPLS-TP data plane MUST be capable of functioning >> independently of the control or management plane used to operate >> the MPLS-TP layer network. That is the MPLS-TP data plane >> operation MUST continue to operate normally if the management >> plane or control plane that configured the connections fails. >> >> o MPLS-TP MUST support any network topology and be able to support >> increasing bandwidth demands, topology, number of customers or >> number of services incrementally. >> >> >> TOM: I think it is imperative that although an MPLS-TP is defined to >> play nicely with an MPLS one, it is imperative that one can distinguish >> between both, at least at the control plane, but perhaps at the data >> plane as well. >> >> 2.2. Layering requirements >> >> o An MPLS-TP network MUST operate in a multiple layer network >> environment consisting of the following independent layers: >> >> 1. A "service layer" instance in which the connections carry the >> customer's (individual or bundled) service (may be point-to- >> point, point-to-multipoint or multipoint-to-multipoint >> services); >> >> 2. A "trunk layer" with point-to-point or point-to-multipoint >> connections which are used to carry aggregates of the network >> "service layer" connections; and >> >> 3. A "transmission media layer" which provides sections (two-port >> point-to-point connections) to carry the aggregate of network >> trunk or network service connections on various physical >> media. >> >> TOM: This stuff belongs in the Terminology section at the top. >> >> MPLS-TP may provide the "service layer" (for P2P and P2MP services) >> and/or the "trunk layer" within a layer network environment. >> >> o An MPLS-TP layer network MUST support the transparent transport of >> MPLS-TP and non MPLS-TP client layer networks. >> >> o An MPLS-TP layer network MUST be able to be transparently carried >> over MPLS-TP and non MPLS-TP server layer networks (such as >> Ethernet, OTN, etc.) >> >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page 6] >> >> Internet-Draft MPLS-TP Requirements July 2008 >> >> >> o It MUST be possible to operate the MPLS-TP layer network >> independently of other layer networks (either MPLS-TP or non >> MPLS-TP). >> >> This is not only a technology requirement, different administrative >> groups may be responsible for different layer networks (even when >> they are of the same type)), and require the capability to >> operationally support the different layers. >> >> o It MUST be possible to hide MPLS-TP layer network addressing and >> other information (e.g. topology) from client layers. >> >> 2.3. Data plane requirements >> >> o The identification of each connection within its aggregate MUST be >> supported. >> >> o A label in a particular section MUST uniquely identify the >> connection. >> >> o A connection's source MUST be identifiable at its destination. >> >> Connections can be aggregated into trunks by pushing and de- >> aggregated by popping labels. MPLS-TP labels may be swapped within a >> connection in a layer network instance when the traffic is forwarded >> from one MPLS-TP link connection to another MPLS-TP link connection. >> >> o Labelling MUST make use of the MPLS label and label stack entry as >> defined in RFC3032. >> >> o It MUST be possible to operate and configure the MPLS-TP data >> (transport) plane without any IP functionality. >> >> o MPLS-TP MUST support both unidirectional and bi-directional point- >> to-point connections. >> >> o The forward and backward directions of a bi-directional connection >> SHOULD follow the same path within the MPLS-TP network. >> >> TOM: I am not sure if we say that they SHOULD as much as "they MUST be >> capable of". >> >> o The intermediate nodes SHOULD be aware about the binding of the >> forward and the backward directions belonging to the same bi- >> directional connection. >> >> TOM: Again, "SHOULD be capable of" seems better. >> >> o MPLS-TP SHOULD support unidirectional point-to-multipoint >> connections. >> >> o MPLS-TP connections MUST NOT perform merging in a way that >> prevents the unique identification of the source at the >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page 7] >> >> Internet-Draft MPLS-TP Requirements July 2008 >> >> >> destination (e.g. no use of LDP mp2p signaling in order to avoid >> losing LSP head-end information, no use of PHP, etc). >> >> o MPLS-TP SHOULD support transport and QoS mechanisms that can >> deliver statistical multiplexing gain. Packets exceeding the >> agreed traffic profile may be marked or discarded by the traffic >> conditioning at the ingress of the MPLS-TP network. >> >> TOM: How about egress policing + marking? >> >> >> o MPLS-TP MUST support connections through a single domain. >> >> o MPLS-TP SHOULD support connections through multiple domains. >> >> o MPLS-TP MUST be able to accommodate new traffic types. >> >> TOM: New traffic types other than those supported by MPLS? This doesn't >> make sense to me as this will result in MPLS-TP not being a subset of >> MPLS. >> >> o MPLS-TP SHOULD support mechanisms to safeguard against the >> provisioning of connections which contain forwarding loops. >> >> o MPLS-TP SHOULD support mechanisms to minimize traffic impact >> during network reconfiguration. >> >> o MPLS-TP SHOULD support mechanisms which ensure the integrity of >> the adapted information. >> >> o MPLS-TP MUST support an unambiguous and reliable means of >> distinguishing users' (client) packets from MPLS-TP control plane >> and management plane packets. >> >> 2.4. Control plane requirements >> >> o A distributed control plane MAY be supported to enable fast, >> dynamic and reliable service provisioning in multi-vendor and >> multi-domain environments using standardized protocols that >> guarantee interoperability. >> >> o If a control plane is used for configuration of MPLS-TP >> connections then: >> >> * Failure and recovery of the control plane MUST NOT impact the >> MPLS-TP forwarding plane. >> >> TOM: This is difficult, as this really is handled in practice at both >> data and control planes, depending on how this is configured/designed, >> and the re-signaling can impact the data plane. >> >> * It MUST support the setup, modification, and release of MPLS-TP >> connections and protection connections. >> >> * It MUST support mechanisms to provide traffic engineering, >> constraint-based routing and explicit path control. >> >> * It MUST provide mechanisms to address QoS and performance >> requirements (such as throughput, delay, packet loss, etc.) >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page 8] >> >> Internet-Draft MPLS-TP Requirements July 2008 >> >> >> while utilizing network resources efficiently and reliably. >> >> o MPLS-TP SHOULD support off-path (out-of-band) control and >> management planes. >> >> o The MPLS-TP control plane MUST be independent of any particular >> client or server layer control plane. >> >> o The control plane SHOULD facilitate the implementation of the >> service by providing end-to-end seamless connectivity and service >> assurance. >> >> o The MPLS-TP control plane MUST support establishing all the >> connectivity patterns defined for the MPLS-TP transport plane >> (e.g., uni-directional and bidirectional P2P, uni-directional >> P2MP, etc.) including configuration of protection functions and >> any associated maintenance functions. >> >> o The MPLS-TP control pane must support the configuration and >> modification of OAM maintenance points as well as the activation/ >> deactivation of OAM when the connection is established or >> modified. >> >> o An MPLS-TP control plane MUST support topology hiding and address >> independence between domains. >> >> o At the boundary of a domain an MPLS-TP control plane MUST support >> unique names or addresses identifying boundary points to be >> interconnected. >> >> o At the boundary of a domain an MPLS-TP control plane must support >> group names or addresses identifying sets of boundary points to be >> interconnected. >> >> o MPLS-TP layer network access points (or connection points that >> proxy for access points) SHOULD be able to be assigned names which >> are available to clients to identify endpoints in call or >> connection requests. >> >> o An MPLS-TP control plane MUST support translation between >> externally visible endpoint names and internal network addresses. >> >> o An MPLS-TP control plane MUST support constraint-based route >> calculation. >> >> o An MPLS-TP control plane MUST support provisioning and application >> of routing constraint policies. >> >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page 9] >> >> Internet-Draft MPLS-TP Requirements July 2008 >> >> >> o An MPLS-TP control plane MUST support pre-provisioned connection >> protection. >> >> In some situations it is impractical to expect acceptable recovery >> performance to be achieved using dynamic recalculation of connection >> routes. For this reason, it is necessary to allow for pre-planning >> of protection routes for selected connections. >> >> o The MPLS-TP control plane MUST support fast restoration. >> >> TOM: Define what "fast" means? >> >> o An MPLS-TP control plane MUST scale gracefully to support a large >> number of connections. >> >> TOM: Define "large" and "scale" here? >> >> [Include some numbers to indicate how large the CP is expected to >> scale to?] >> >> o An MPLS-TP control plane MUST clearly distinguish resources >> belonging to the MPLS-TP layer network from those in other layer >> networks that may also be under control plane control. >> >> TOM: Do you mean under the same control plane or a different one (or >> both)? >> >> o An MPLS-TP control plane MUST support the independent >> identification of logically distinct control plane elements. >> >> o It MUST be possible to identify and provision these elements >> independently, in order to reorganize the control plane components >> without impacting the data plane services and vice-versa. >> >> Architecturally distinct elements in a control plane include: nodes >> and links, control plane functional components, protocol controllers, >> etc. >> >> o An MPLS-TP control plane SHOULD provide a common control mechanism >> for architecturally similar operations. >> >> o An MPLS-TP control plane MUST support mechanisms for partitioning >> the network under control into separate peer or hierarchical >> control domains. >> >> o To enable the deployment of a unified control plane aimed at >> controlling the set of transport technologies used in a transport >> network, the MPLS-TP control plane MUST also be applicable to >> other transport layer networks and provide common operations >> across multiple layers. In order to maintain independence between >> MPLS-TP and its respective client and server layer network >> separate control plane instances SHOULD be used to control a set >> of transport layer networks. >> >> >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page 10] >> >> Internet-Draft MPLS-TP Requirements July 2008 >> >> >> o MPLS-TP SHOULD detect and recover from control plane failures and >> degradations using graceful operations. >> >> 2.5. Network Management (NM) requirements >> >> o MPLS-TP MUST operate under a common operation, control and >> management paradigm with respect to other transport technologies >> (e.g. SDH, OTN or WDM). >> >> o An MPLS-TP network MUST be able to be operated with a centralized >> NMS system. >> >> o An MPLS-TP network SHOULD be able to be operated by a centralized >> NMS system with the support of a distributed control plane. >> >> TOM: I don't know what this means or the one above it, or how this >> requirement would translate into anything tangible in the MPLS-TP >> protocol designs. I suggest it be removed. >> >> o The MPLS-TP management plane MUST NOT depend on a specific client >> layer management plane. >> >> TOM: This is a non-sequitur if you ask me; please strike it. >> >> o The MPLS-TP management plane MUST support the configuration and >> modification of OAM maintenance points as well as the activation/ >> deactivation of OAM when the connection is established or >> modified. >> >> For the complete set of requirements related to NM functionality for >> MPLS-TP, see the MPLS-TP NM requirements document [REF]. >> >> 2.6. OAM requirements >> >> o MPLS-TP SHOULD provide a comprehensive set of capabilities (that >> are independent of and agnostic to the transmitted client >> services) to support fault management, performance monitoring (of >> the MPLS-TP network and the services), protection switching, fault >> localization, signal quality measurement, etc. >> >> o A mechanism SHOULD be supported to detect, diagnose and enable >> recovery from facility and equipment failures and performance >> degradations according to the requirements of the service. >> >> o MPLS-TP OAM MUST be able to operate without IP functionality and >> without relying on control and/or management planes. >> >> For the complete set of requirements related to OAM functionality for >> MPLS-TP, see the MPLS-TP OAM requirements document [REF]. >> >> TOM: I suggest you just remove these two sections and refer to the >> OAM/Managemetn documents. >> >> 2.7. Network performance management (PM) requirements >> >> >> >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page 11] >> >> Internet-Draft MPLS-TP Requirements July 2008 >> >> >> o MPLS-TP MUST support traffic-engineering capabilities with >> traffic- and/or resource-oriented performance objectives. >> >> TOM: What are performance objectives? Do you mean traffic profiles such >> as QoS/bandwidth? >> >> o MPLS-TP MUST support a method to offer packet loss objectives >> comparable to those in TDM transport networks (only due to bit >> errors). >> >> For the complete set of requirements related to PM functionality for >> MPLS-TP, see the MPLS-TP OAM requirements document [REF]. >> >> TOM: Again, I suggest you punt on this entire section and move it to the >> OAM doc. >> >> 2.8. Protection & Survivability requirements >> >> Network survivability plays a critical factor in the delivery of >> reliable services. Network availability is a significant contributor >> to revenue and profit. Service guarantees in the form of SLAs >> require a resilient network that rapidly detects facility or node >> failures and restores network operation in accordance with the terms >> of the SLA. >> >> The requirements in this section use of the recovery terminology >> defined in RFC 4427[RFC4427]. >> >> o MPLS-TP SHOULD support transport network style protection >> >> TOM: I would make this a MUST. >> >> switching mechanisms (tandem network connection protection, LSP >> protection and PW protection) to provide the sub-50ms recovery >> time required to maintain customer transparency, even when >> thousands of services are simultaneously affected by a failure. >> [Is sub-50ms really a requirement, do we want to clarify this >> further - is it sub-50ms end to end, or per link?] >> >> o >> >> * MPLS-TP recovery mechanisms SHOULD be applicable at various >> levels throughout the network, SPAN, tandem connection and end- >> to-end. >> >> TOM: This sentence doesn't parse. Please re-write. >> >> Any recovery mechanism used in a tandem connection >> MUST be independent of other tandem connections. >> >> * MPLS-TP SHOULD support mechanisms that keep traffic flowing >> while the network recovers from failures. >> >> TOM: I would say this is a MUST. >> >> * MPLS-TP SHOULD support network restoration mechanisms >> controlled by a distributed control plane and/or by a >> management plane based. >> >> TOM: I would say this is a MUST. >> >> >> * >> >> + The restoration resources MAY be pre-planned and selected a >> priori, or computed after failure occurrence. >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page 12] >> >> Internet-Draft MPLS-TP Requirements July 2008 >> >> >> + MPLS-TP MAY support shared-mesh restoration. >> >> + MPLS-TP SHOUD support soft LSP restoration. >> >> + MPLS-TP MAY support hard LSP restoration. >> >> + The restoration mechanism MUST be applicable to any >> topology. >> >> + Restoration priority MAY be implemented to determine the >> order in which connections should be restored (to minimize >> service restoration time as well as to gain access to >> available spare capacity on the best paths). Preemption >> priority MAY be used in the event that not all connections >> can be restored, in which case connections with lower >> preemption priority should be released. >> >> + The restoration mechanism SHOULD operate in synergy with >> other transport network technologies (SDH, OTN, WDM). >> >> * MPLS-TP SHOULD support data plane driven protection mechanisms >> (without any dependency on a control plane or IP protocols) to >> enable fast recovery from failure, and thereby to enhance the >> reliability and availability performance of MPLS-TP networks. >> >> * >> >> + MPLS-TP protection mechanisms SHOULD be applied to LSPs and >> PWs. >> >> + MPLS-TP MUST support mechanisms that rapidly detect, locate, >> notify and remedy network faults. >> >> + MPLS-TP MUST support 1:1 bidirectional protection switching. >> The protection state of both ends of the protected entity >> MUST be synchronized. >> >> + MPLS-TP MAY support 1+1 unidirectional protection switching. >> >> + MPLS-TP protection mechanisms MUST be applicable to both >> point-to-point and point-to-multipoint connections. >> >> + It SHOULD be possible to achieve protection at the MPLS-TP >> layer as fast as possible (subject to the temporal >> resolution of the defect detection mechanism). >> >> + Protection ratio MUST be of 100%, i.e., 100% of impaired >> working traffic MUST be protected for a failure on a single >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page 13] >> >> Internet-Draft MPLS-TP Requirements July 2008 >> >> >> working LSP. >> >> + Operator requests for manual control of protection switching >> such as clear, lockout of protection, forced-switch and >> manual-switch commands MUST be supported. Prioritized >> protection between Signal Fail (SF), Signal Degradation (SD) >> and operator switch requests MUST be supported. >> >> + MPLS-TP protection mechanisms MUST support revertive and >> non-revertive behaviour. o An extra traffic capability >> SHOULD be supported when possible. >> >> + MPLS-TP protection switching mechanisms MUST prevent >> frequent operation of the protection switch due to an >> intermittent defect. >> >> + MPLS-TP protection mechanisms MUST ensure co-ordination of >> timing of protection switches at multiple layers to avoid >> races and to allow the protection switching mechanism of the >> server layer to fix the problem before switching at the >> MPLS-TP layer. >> >> + MPLS-TP MAY support mechanisms that are optimized for >> specific network topologies (Ring, Mesh) in order to handle >> protection switching in a cost-efficient manner. >> >> 2.9. QoS requirements >> >> Service providers require advanced traffic management capabilities to >> enforce and guarantee the QoS parameters of customers' SLAs. >> >> Quality of service mechanisms are required to ensure: >> >> o Support for differentiated services and different traffic types >> with traffic class separation associated with different traffic. >> >> o Prioritization of critical services. >> >> o Enabling the provisioning and the guarantee of Service Level >> Specifications (SLS), with support for hard and relative end-to- >> end BW guaranteed. >> >> o Controlled jitter and delay. >> >> o Guarantee of fair access to shared resources in an MPLS-TP >> network. >> >> >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page 14] >> >> Internet-Draft MPLS-TP Requirements July 2008 >> >> >> o Ability for OAM and data to share the same fate. >> >> TOM: This belongs in the OAM document. >> >> >> o Resources for control and management plane packets so that user >> plane traffic, regardless of the amount, will not cause control >> and management functions to become inoperative. >> >> The following QoS requirements apply to MPLS-TP: >> >> o MPLS-TP MUST be able to deliver the same degree of QoS that has >> been delivered by SDH/SONET systems. >> >> TOM: We can save on a lot of text and remove the "MPLS-TE MUST" or >> "MPLS-TP SHOULD" bits and simply say "MUST X" or "SHOULD Y". The MPLS-TP >> bit is implicit I think. >> >> o MPLS-TP MUST support transport bandwidth allocation to any >> granularity without any restrictions based on a circuit-switched >> multiplexing hierarchy. This attribute will provide service >> providers with the capability to route more customer service >> demands over the MPLS-TP network. >> >> [Should we refer here to the requirements specified in RFC 2702?] >> >> 2.10. Security requirements >> >> o MPLS-TP MUST ensure that the network and services are secured. >> >> o Traffic flows from different users MUST NOT be intermingled, but >> if this does occur then this MUST be detectable and the >> appropriate consequent actions taken. >> >> o MPLS-TP MUST ensure the separation of customer (client) and >> provider (server and peer network) addressing and other >> information. >> >> TOM: This requirement is stated above. >> >> o MPLS-TP MUST ensure that the control and management planes as well >> as OAM traffic are secure from external attack. >> >> o MPLS-TP MUST provide mechanisms to ensure that the MPLS-TP network >> remains secure and stable under situations of extreme stress. >> >> Examples of attacks and situations of extreme stress include (but are >> not limited to) classical security attacks (e.g., hijacking, privacy, >> non-repudiation, etc.) and attacks on network availability (e.g., >> denial of service (DoS) attacks). >> >> >> 3. IANA Considerations >> >> This document makes no request of IANA. >> >> Note to RFC Editor: this section may be removed on publication as an >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page 15] >> >> Internet-Draft MPLS-TP Requirements July 2008 >> >> >> RFC. >> >> >> 4. Security Considerations >> >> This document does not by itself raise any particular security >> considerations. >> >> >> 5. Acknowledgements >> >> The authors wish to thank Neil Harrison and Tomonori Takeda for their >> review and enhancements to the text. >> >> >> 6. Informative References >> >> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate >> Requirement Levels", BCP 14, RFC 2119, March 1997. >> >> [RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and >> Restoration) Terminology for Generalized Multi-Protocol >> Label Switching (GMPLS)", RFC 4427, March 2006. >> >> [ITU.Y1401.2008] >> International Telecommunications Union, "Principles of >> interworking", ITU-T Recommendation Y.1401, February 2008. >> >> >> Authors' Addresses >> >> Ben Niven-Jenkins (editor) >> BT >> 208 Callisto House, Adastral Park >> Ipswich, Suffolk IP5 3RE >> UK >> >> Email: benjamin.niven-jenkins@bt.com >> >> >> Deborah Brungard (editor) >> AT&T >> Rm. D1-3C22 - 200 S. Laurel Ave. >> Middletown, NJ 07748 >> USA >> >> Email: dbrungard@att.com >> >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page 16] >> >> Internet-Draft MPLS-TP Requirements July 2008 >> >> >> Malcolm Betts (editor) >> Nortel Networks >> 3500 Carling Avenue >> Ottawa, Ontario K2H 8E9 >> Canada >> >> Email: betts01@nortel.com >> >> >> Nurit Sprecher >> Nokia Siemens Networks >> 3 Hanagar St. Neve Ne'eman B >> Hod Hasharon, 45241 >> Israel >> >> Email: nurit.sprecher@nsn.com >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page 17] >> >> Internet-Draft MPLS-TP Requirements July 2008 >> >> >> Full Copyright Statement >> >> Copyright (C) The IETF Trust (2008). >> >> 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, THE IETF TRUST 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. >> >> >> Intellectual Property >> >> 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. >> >> >> >> >> >> >> >> >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page 18] >> >> >> >> _______________________________________________ >> Mpls-interop mailing list >> Mpls-interop@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-interop > _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop From mpls-interop-bounces@ietf.org Sun Jun 22 05:49:43 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2128D3A69A9; Sun, 22 Jun 2008 05:49:43 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D17C828C0E9 for ; Sun, 22 Jun 2008 05:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BnOKjH7T2Omt for ; Sun, 22 Jun 2008 05:49:35 -0700 (PDT) Received: from sacmail2.verizon.com (sacmail2.verizon.com [192.76.84.41]) by core3.amsl.com (Postfix) with ESMTP id 90A253A69DD for ; Sun, 22 Jun 2008 05:49:35 -0700 (PDT) Received: from smtptpa4.verizon.com (smtptpa4.verizon.com [138.83.71.177]) by sacmail2.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id m5MCnMaI011833; Sun, 22 Jun 2008 08:49:23 -0400 (EDT) Received: from ftwintrmemf2.verizon.com (ftwintrmemf2.verizon.com [138.83.131.184]) by smtptpa4.verizon.com (8.13.3/8.13.3) with ESMTP id m5MCnLeN019160; Sun, 22 Jun 2008 08:49:21 -0400 (EDT) Received: from ftwintrmemf2.verizon.com (unknown [127.0.0.1]) by ftwintrmemf2.verizon.com (Symantec Mail Security) with ESMTP id 7AE52528002; Sun, 22 Jun 2008 08:49:21 -0400 (EDT) X-AuditID: 8a5383b8-a36bbbb000000647-42-485e4a50a6a5 Received: from smtptpa3.verizon.com (unknown [138.83.71.176]) by ftwintrmemf2.verizon.com (EMF) with ESMTP id 8FA764E4002; Sun, 22 Jun 2008 08:49:20 -0400 (EDT) Received: from FHDP1CCMXCG02.us.one.verizon.com ([166.68.240.34]) by smtptpa3.verizon.com (8.13.3/8.13.3) with ESMTP id m5MCnJ34006735; Sun, 22 Jun 2008 08:49:20 -0400 (EDT) Received: from FHDP1CCMXCV01.us.one.verizon.com ([166.68.240.11]) by FHDP1CCMXCG02.us.one.verizon.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 22 Jun 2008 08:49:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 22 Jun 2008 08:49:18 -0400 Message-ID: <03EF010917EC4F46975DE0B94C51B1C205B8EE@FHDP1CCMXCV01.us.one.verizon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mpls-interop] next MEAD team meeting Thread-Index: AcjSMNQsx4BuurjX8EeQxIcfmO8exAA0/R+VAEuIunAACtuUpAABrZoIAABUpbY= From: To: , , , , X-OriginalArrivalTime: 22 Jun 2008 12:49:20.0196 (UTC) FILETIME=[638C7040:01C8D466] X-Brightmail-Tracker: AAAAAA== Cc: yaacov.weingarten@nsn.com Subject: Re: [Mpls-interop] next MEAD team meeting X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0062514461==" Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org This is a multi-part message in MIME format. --===============0062514461== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8D466.62AC98CB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8D466.62AC98CB Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SSB3YW50IHRvIHNlY29uZCBCZW4gaGVyZSAtIGEgZHluYW1pYyBjb250cm9sIHBsYW5lIE1VU1Qg YmUgYXZhaWxhYmxlIGZvciB0aGUgU1AgdG8gY2hvb3NlIHRvIHVzZSAtIGlmIGl0IGlzIG9wdGlv bmFsIGZvciBpbXBsZW1lbnRhdGlvbiwgdGhlbiBpdCB3aWxsIGJlIGxlZnQgZm9yICJ0aGUgbmV4 dCByZWxlYXNlIi4gIA0KDQpDaGVlcnMsDQpBbmR5IA0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdl IC0tLS0tDQpGcm9tOiBtcGxzLWludGVyb3AtYm91bmNlc0BpZXRmLm9yZyA8bXBscy1pbnRlcm9w LWJvdW5jZXNAaWV0Zi5vcmc+DQpUbzogVGhvbWFzIE5hZGVhdSA8dG9tLm5hZGVhdUBidC5jb20+ OyBTcHJlY2hlciwgTnVyaXQgKE5TTiAtIElML0lzcmFlbCAtIE1pbmlNRCkgPG51cml0LnNwcmVj aGVyQG5zbi5jb20+OyBMb2EgQW5kZXJzc29uIDxsb2FAcGkubnU+OyBNRUFEIHRlYW0gPG1wbHMt aW50ZXJvcEBpZXRmLm9yZz4NCkNjOiBXZWluZ2FydGVuLFlhYWNvdiAoTlNOIC0gSUwvSXNyYWVs IC0gTWluaU1EKSA8eWFhY292LndlaW5nYXJ0ZW5AbnNuLmNvbT4NClNlbnQ6IFN1biBKdW4gMjIg MDg6Mzk6NTEgMjAwOA0KU3ViamVjdDogUmU6IFtNcGxzLWludGVyb3BdIG5leHQgTUVBRCB0ZWFt IG1lZXRpbmcNCg0KSSB0aGluayB0aGUga2V5IHRoaW5nIGlzIHRoYXQgTVBMUy1UUCBtdXN0IGJl IGFibGUgdG8gb3BlcmF0ZSAoaW5jbHVkaW5nDQpPQU0pIGluIHRoZSBhYnNlbmNlIG9mIGEgY29u dHJvbCBwbGFuZS4NCg0KVGhlIG9wdGlvbiBpcyB0aGVuIGRvd24gdG8gd2hldGhlciB3ZSBzYXkg Ym90aCBzdGF0aWMgJiBkeW5hbWljIGFyZSBNVVNUcw0KKGZyb20gYW4gaW1wbGVtZW50YXRpb24g cGVyc3BlY3RpdmUpIGFuZCB0aGUgb3BlcmF0b3IgaXMgdGhlbiBmcmVlIHRvIGNob29zZQ0Kd2hl dGhlciB0aGV5IG9wZXJhdGUgdGhlaXIgbmV0d29yayBzdGF0aWNhbGx5IG9yIGR5bmFtaWNhbGx5 LiAgT3Igd2hldGhlcg0Kb25seSBzdGF0aWMgaXMgYSBNVVNUIGFuZCBkeW5hbWljIGlzIG9wdGlv bmFsIChmb3IgaW1wbGVtZW50YXRpb24pLg0KDQpJIGJlbGlldmUgdGhlIHdvcmsgaW4gSVRVIGlu dGVuZGVkIHRvIGV4dGVuZCB0byBkeW5hbWljIGF0IHNvbWUgcG9pbnQgYW5kDQpzdGF0aWMgd2Fz IGp1c3QgYSBmaXJzdCBzdGVwIGluIHRoZSBULU1QTFMgd29yay4NCg0KSXQgb25seSB0YWtlIG9u ZSBvcGVyYXRvciB0byBkZW1hbmQgZHluYW1pYyBmcm9tIHRoZWlyIHZlbmRvcnMgZm9yIGl0IHRv IGJlDQpwcmVzZW50IGluIGVxdWlwbWVudCBhbnl3YXkgZXZlbiBpZiBpdCBpcyBub3QgdXNlZCBi eSBvdGhlciBvcGVyYXRvcnMuDQoNClNvIEkgdGhpbmsgd2UgY2FuIG1ha2UgYm90aCBzdGF0aWMg JiBkeW5hbWljIE1VU1RzIGFuZCB0aGVuIGNsYXJpZnkgdGhhdA0Kd2hlbiBvcGVyYXRpbmcgaW4g YSBzdGF0aWMgbW9kZSBNUExTLVRQIG11c3Qgbm90IHJlbHkgb24gYW55IGR5bmFtaWMNCnByb3Rv Y29scy4NCg0KV2UgY292ZXIgdGhpcyAoYXQgbGVhc3QgdG8gc29tZSBleHRlbnQpIGFscmVhZHkg d2l0aCByZXF1aXJlbWVudHMgc3VjaCBhcyAiDQpTdGF0aWMgcHJvdmlzaW9uaW5nIE1VU1Qgbm90 IGRlcGVuZCBvbiByb3V0aW5nIG9yIHNpZ25hbGluZyBwcm90b2NvbHMgKGUuZy4NCkdNUExTLCBP U1BGLCBJUy1JUywgUlNWUCwgQkdQLCBMRFAgZXRjLikuIg0KDQpCZW4NCg0KT24gMjIvMDYvMjAw OCAxMjo1MSwgIlRob21hcyBOYWRlYXUiIDx0b20ubmFkZWF1QGJ0LmNvbT4gd3JvdGU6DQoNCj4g DQo+IA0KPiANCj4gT24gNi8yMi8wOCA1OjQ1IEFNLCAiU3ByZWNoZXIsIE51cml0IChOU04gLSBJ TC9Jc3JhZWwgLSBNaW5pTUQpIg0KPiA8bnVyaXQuc3ByZWNoZXJAbnNuLmNvbT4gd3JvdGU6DQo+ IA0KPj4gSGkgVGhvbWFzLA0KPj4gVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLg0KPj4gSSBzdGls bCBuZWVkIHRvIGdldCBpbnRvIHRoZSBkZXRhaWxzIGFuZCBtZWFuaW5ncyBvZiB5b3VyIGNvbW1l bnRzLCBidXQNCj4+IGluIHRoZSBtZWFudGltZSBJIGhhdmUgb25lIGJhc2ljIGNvbmNlcm4gb24g eW91ciBjb21tZW50IG9uICIgTVBMUy1UUA0KPj4gY29ubmVjdGlvbnMgTUFZIGJlIGFibGUgdG8g YmUgcHJvdmlzaW9uZWQgZHluYW1pY2FsbHkgdmlhIGEgY29udHJvbA0KPj4gcGxhbmUuIFRPTTog SSBpbnNpc3QgdGhhdCB3ZSBjaGFuZ2UgdGhlIE1BWSBhYm92ZSB0byBNVVNULiBJIHdhbnQgYQ0K Pj4gZHluYW1pYyB2ZXJzaW9uIG9mIHRoaXMgYXMgbXVjaCBhcyBhIHN0YXRpYyBvbmUuIg0KPj4g VGhpcyBpcyBvbmUgb2YgdGhlIGZ1bmRhbWVudGFsIHByaW5jaXBsZXMgb2YgdGhlIE1QTFMtVFAs IHRoYXQgdGhlDQo+PiBwcmVzZW5jZSBvZiBhIGRpc3RyaWJ1dGVkIGNvbnRyb2wgcGxhbmUgaW4g c3VwcG9ydCBvZiBuZXR3b3JrIG9wZXJhdGlvbnMNCj4+IGlzIG9wdGlvbmFsIChhcyBpbiBvdGhl ciB0cmFuc3BvcnQgdGVjaG5vbG9naWVzLCBsaWtlIGluIFNESCwgZXRjLikuDQo+IA0KPiAgICAg SSBhZ3JlZSBpdCBpcyBvcHRpb25hbC4gV2hhdCBJIHdhbnQgdG8gbWFrZSBzdXJlIGlzIHRoYXQg aXQgaXMgbm90IHNvDQo+IG9wdGlvbmFsIHRoYXQgaXQgaXMgY29tcGxldGVseSByZW1vdmVkIGZy b20gdGhlIGRlc2lnbi4gIFRoZSBsYW5ndWFnZSBpbiB0aGUNCj4gZG9jdW1lbnQgbm93IHNlZW1z IHRvIGJlIGhlYWRlZCBpbiB0aGF0IGRpcmVjdGlvbi4NCj4gDQo+PiBUaGlzIGlzIGFsc28gdGhl IHRyaWdnZXIgZm9yIHRoZSBkZWZpbml0aW9uIG9mIE9BTSBjYXBhYmlsaXRpZXMgd2hpY2gNCj4+ IGFyZSBpbmRlcGVuZGVudCBvZiBhIGNvbnRyb2wgcGxhbmUsIGFzIHdlbGwgYXMgb2YgdGhlIHBy b3RlY3Rpb24NCj4+IHN3aXRjaGluZywgZXRjLiANCj4+IFRoaXMgaXMgYWxzbyBhZGRyZXNzZWQg YnkgdGhlIHNsaWRlcyBvZiB0aGUgSlc6ICJEZXNpcmUgdG8gc3RhdGljYWxseQ0KPj4gY29uZmln dXJlIExTUHMgYW5kIFBXRXMgdmlhIHRoZSBtYW5hZ2VtZW50IHBsYW5lLi4uDQo+IA0KPiAgICAg SSBhbSBub3QgYXJndWluZyBhZ2FpbnN0IHN0YXRpYzsgSSBhbSBhcmd1aW5nIGZvciBkeW5hbWlj IHRvIGJlIGluIHRoZXJlDQo+IGFzIHdlbGwuDQo+IA0KPj4gVHJhbnNwb3J0IE9BTSBjYXBhYmls aXRpZXMgZG9uJ3QgZXhpc3QgZm9yIExTUCBhbmQgUFdFIGluZGVwZW5kZW50IG9mDQo+PiBjb25m aWd1cmF0aW9uIG1lY2hhbmlzbSAobWFuYWdlbWVudCBwbGFuZSBvciBHTVBMUyBvciBQV0UgY29u dHJvbA0KPj4gcGxhbmUpLi4uDQo+IA0KPiAgICAgSXQgZGVwZW5kcyBvbiBob3cgeW91IGxvb2sg YXQgd2hhdCAidHJhbnNwb3J0IE9BTSBjYXBhYmlsaXRpZXMiLiBGcm9tIG15DQo+IHBlcnNwZWN0 aXZlIGF0IEJULCBJIGRlZmluaXRlbHkgdGhpbmsgdGhlcmUgaXMgYSBkeW5hbWljIGZsYXZvciBv ZiB0aGlzIGZvcg0KPiBzdXJlLiAgQWdhaW4sIEkgYW0gbm90IGFkdm9jYXRpbmcgcmVtb3ZhbCBv ZiB0aGUgc3RhdGljIHBhcnRzLCBqdXN0IHRoZQ0KPiBhZGRpdGlvbiBvZiB0aGUgZHluYW1pYyBv bmVzLiBBbmQgc2luY2UgdGhleSBhcmUgYWxyZWFkeSB0aGVyZSBpbiBsYXJnZQ0KPiBwYXJ0LCBh cyBwYXJ0IG9mIHRoZSBiYXNlIE1QTFMgc3BlY2lmaWNhdGlvbiwgSSBkb24ndCBzZWUgYW55IGhh cm0gaW4NCj4gc3BlY2lmeWluZyB0aGlzLg0KPiANCj4gICAgIC0tVG9tDQo+IA0KPiANCj4gDQo+ PiBXaXRoIHN0YXRpYyBwcm92aXNpb25pbmcsIG5vIGRlcGVuZGVuY3kgb24gcm91dGluZyBvciBz aWduYWxpbmcNCj4+IChlLmcuIEdNUExTIG9yLCBJR1AsIFJTVlAsIEJHUCwgTERQKSIsIGV0Yy4N Cj4+IEJlc3QgcmVnYXJkcywNCj4+IE51cml0DQo+PiANCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+PiBGcm9tOiBtcGxzLWludGVyb3AtYm91bmNlc0BpZXRmLm9yZw0KPj4gW21haWx0 bzptcGxzLWludGVyb3AtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGV4dCBUaG9tYXMg TmFkZWF1DQo+PiBTZW50OiBGcmlkYXksIEp1bmUgMjAsIDIwMDggMjE6MzgNCj4+IFRvOiBCZW4g Tml2ZW4tSmVua2luczsgTG9hIEFuZGVyc3NvbjsgTUVBRCB0ZWFtDQo+PiBTdWJqZWN0OiBSZTog W01wbHMtaW50ZXJvcF0gbmV4dCBNRUFEIHRlYW0gbWVldGluZw0KPj4gDQo+PiANCj4+ICAgICBD b21tZW50cyBvbiB0aGUgZG9jdW1lbnQgaW5saW5lIHN0YXJ0IHdpdGggIlRPTToiDQo+PiBJbiBn ZW5lcmFsLCBwbGVhc2UgcmV2aWV3IHRoZSBkb2N1bWVudCBhbmQgcHV0IG1vcmUgb2YgYW4gZW1w aGFzaXMgb24NCj4+IHRoZSB1c2Ugb2YgIk1VU1QiIHJhdGhlciB0aGFuICJNQVkiIG9yICJTSE9V TEQiLiBUaGUgSUVURyBmcm93bnMgb24NCj4+IHJlcXVpcmVtZW50cyBkb2N1bWVudHMgdGhhdCBh cmUgdG9vIG9wdGlvbmFsLg0KPj4gDQo+PiAgICAgLS1Ub20NCj4+IA0KPj4gDQo+PiANCj4+IA0K Pj4gDQo+PiBOZXR3b3JrIFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBCLiBOaXZlbi1KZW5raW5zLCBFZC4NCj4+IEludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBCVA0KPj4gSW50ZW5kZWQg c3RhdHVzOiBJbmZvcm1hdGlvbmFsICAgICAgICAgICAgICAgICAgICAgICAgICBELiBCcnVuZ2Fy ZCwgRWQuDQo+PiBFeHBpcmVzOiBKYW51YXJ5IDIsIDIwMDkgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIEFUJlQNCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTS4gQmV0dHMsIEVkLg0KPj4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTm9ydGVs IE5ldHdvcmtzDQo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgTi4gU3ByZWNoZXINCj4+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgTm9raWEgU2llbWVucyBOZXR3b3Jrcw0KPj4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBK dWx5IDAxLCAyMDA4DQo+PiANCj4+IA0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgICBNUExT LVRQIFJlcXVpcmVtZW50cw0KPj4gICAgICAgICAgICAgICAgZHJhZnQtamVua2lucy1tcGxzLW1w bHN0cC1yZXF1aXJlbWVudHMtMDANCj4+IA0KPj4gU3RhdHVzIG9mIHRoaXMgTWVtbw0KPj4gDQo+ PiAgICBCeSBzdWJtaXR0aW5nIHRoaXMgSW50ZXJuZXQtRHJhZnQsIGVhY2ggYXV0aG9yIHJlcHJl c2VudHMgdGhhdCBhbnkNCj4+ICAgIGFwcGxpY2FibGUgcGF0ZW50IG9yIG90aGVyIElQUiBjbGFp bXMgb2Ygd2hpY2ggaGUgb3Igc2hlIGlzIGF3YXJlDQo+PiAgICBoYXZlIGJlZW4gb3Igd2lsbCBi ZSBkaXNjbG9zZWQsIGFuZCBhbnkgb2Ygd2hpY2ggaGUgb3Igc2hlIGJlY29tZXMNCj4+ICAgIGF3 YXJlIHdpbGwgYmUgZGlzY2xvc2VkLCBpbiBhY2NvcmRhbmNlIHdpdGggU2VjdGlvbiA2IG9mIEJD UCA3OS4NCj4+IA0KPj4gICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBv ZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcNCj4+ICAgIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMg YXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91cHMuICBOb3RlIHRoYXQNCj4+ICAgIG90aGVyIGdy b3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LQ0K Pj4gICAgRHJhZnRzLg0KPj4gDQo+PiAgICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3Vt ZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMNCj4+ICAgIGFuZCBtYXkgYmUg dXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55 DQo+PiAgICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRz IGFzIHJlZmVyZW5jZQ0KPj4gICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4g YXMgIndvcmsgaW4gcHJvZ3Jlc3MuIg0KPj4gDQo+PiAgICBUaGUgbGlzdCBvZiBjdXJyZW50IElu dGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQNCj4+ICAgIGh0dHA6Ly93d3cuaWV0Zi5v cmcvaWV0Zi8xaWQtYWJzdHJhY3RzLnR4dC4NCj4+IA0KPj4gICAgVGhlIGxpc3Qgb2YgSW50ZXJu ZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KPj4gICAgaHR0 cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbC4NCj4+IA0KPj4gICAgVGhpcyBJbnRlcm5ldC1E cmFmdCB3aWxsIGV4cGlyZSBvbiBKYW51YXJ5IDIsIDIwMDkuDQo+PiANCj4+IEFic3RyYWN0DQo+ PiANCj4+ICAgIFRoaXMgZG9jdW1lbnQgd2lsbCBvdXRsaW5lIHRoZSByZXF1aXJlbWVudHMgZm9y IE1QTFMtVFAuDQo+PiANCj4+IFJlcXVpcmVtZW50cyBMYW5ndWFnZQ0KPj4gDQo+PiAgICBUaGUg a2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxM IE5PVCIsDQo+PiAgICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZ IiwgYW5kICJPUFRJT05BTCIgaW4gdGhpcw0KPj4gICAgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVy cHJldGVkIGFzIGRlc2NyaWJlZCBpbiBbUkZDMjExOV0uDQo+PiANCj4+IA0KPj4gDQo+PiBOaXZl bi1KZW5raW5zLCBldCBhbC4gICAgRXhwaXJlcyBKYW51YXJ5IDIsIDIwMDkgICAgICAgICAgICAg ICAgW1BhZ2UgMV0NCj4+IAwNCj4+IEludGVybmV0LURyYWZ0ICAgICAgICAgICAgTVBMUy1UUCBS ZXF1aXJlbWVudHMgICAgICAgICAgICAgICAgIEp1bHkgMjAwOA0KPj4gDQo+PiANCj4+IFRhYmxl IG9mIENvbnRlbnRzDQo+PiANCj4+ICAgIDEuICBJbnRyb2R1Y3Rpb24gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMw0KPj4gICAgMi4gIE1QTFMtVFAg UmVxdWlyZW1lbnRzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA1 DQo+PiAgICAgIDIuMS4gIEdlbmVyYWwgcmVxdWlyZW1lbnRzIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDUNCj4+ICAgICAgMi4yLiAgTGF5ZXJpbmcgcmVxdWlyZW1lbnRz ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNg0KPj4gICAgICAyLjMuICBE YXRhIHBsYW5lIHJlcXVpcmVtZW50cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICA3DQo+PiAgICAgIDIuNC4gIENvbnRyb2wgcGxhbmUgcmVxdWlyZW1lbnRzIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDgNCj4+ICAgICAgMi41LiAgTmV0d29yayBNYW5hZ2VtZW50 IChOTSkgcmVxdWlyZW1lbnRzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMQ0KPj4gICAgICAyLjYu ICBPQU0gcmVxdWlyZW1lbnRzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDExDQo+PiAgICAgIDIuNy4gIE5ldHdvcmsgcGVyZm9ybWFuY2UgbWFuYWdlbWVudCAoUE0p IHJlcXVpcmVtZW50cyAuIC4gLiAuIC4gMTENCj4+ICAgICAgMi44LiAgUHJvdGVjdGlvbiAmIFN1 cnZpdmFiaWxpdHkgcmVxdWlyZW1lbnRzICAuIC4gLiAuIC4gLiAuIC4gLiAxMg0KPj4gICAgICAy LjkuICBRb1MgcmVxdWlyZW1lbnRzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIDE0DQo+PiAgICAgIDIuMTAuIFNlY3VyaXR5IHJlcXVpcmVtZW50cyAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTUNCj4+ICAgIDMuICBJQU5BIENvbnNpZGVyYXRp b25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNQ0KPj4gICAg NC4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDE2DQo+PiAgICA1LiAgQWNrbm93bGVkZ2VtZW50cyAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTYNCj4+ICAgIDYuICBJbmZvcm1hdGl2ZSBS ZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNg0KPj4g ICAgQXV0aG9ycycgQWRkcmVzc2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDE2DQo+PiAgICBJbnRlbGxlY3R1YWwgUHJvcGVydHkgYW5kIENvcHlyaWdo dCBTdGF0ZW1lbnRzIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTgNCj4+IA0KPj4gDQo+PiANCj4+IA0K Pj4gDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+ IA0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiAN Cj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gTml2ZW4tSmVua2lucywgZXQgYWwuICAgIEV4cGlyZXMg SmFudWFyeSAyLCAyMDA5ICAgICAgICAgICAgICAgIFtQYWdlIDJdDQo+PiAMDQo+PiBJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgIE1QTFMtVFAgUmVxdWlyZW1lbnRzICAgICAgICAgICAgICAgICBK dWx5IDIwMDgNCj4+IA0KPj4gDQo+PiAxLiAgSW50cm9kdWN0aW9uDQo+PiANCj4+ICAgIEZvciBt YW55IHllYXJzLCBTT05FVC9TREggaGFzIHByb3ZpZGVkIHNlcnZpY2UgcHJvdmlkZXJzIHdpdGgg YSBoaWdoDQo+PiAgICBiZW5jaG1hcmsgZm9yIHJlbGlhYmlsaXR5IGFuZCBvcGVyYXRpb25hbCBz aW1wbGljaXR5LiAgV2l0aCB0aGUNCj4+ICAgIGFjY2VsZXJhdGluZyBncm93dGggb2YgcGFja2V0 LWJhc2VkIHNlcnZpY2VzIChzdWNoIGFzIEV0aGVybmV0LCBWb0lQLA0KPj4gICAgTDIvTDMgVlBO LCBJUFRWLCBSQU4gYmFja2hhdWxpbmcsIGV0Yy4pLCBzZXJ2aWNlIHByb3ZpZGVycyBhcmUgaW4N Cj4+ICAgIG5lZWQgb2YgY2FwYWJpbGl0aWVzIHRvIGVmZmljaWVudGx5IHN1cHBvcnQgcGFja2V0 LWJhc2VkIHNlcnZpY2VzIG9uDQo+PiAgICB0aGVpciB0cmFuc3BvcnQgbmV0d29ya3MuICBUaGUg bmVlZCB0byBpbmNyZWFzZSB0aGVpciByZXZlbnVlIHdoaWxlDQo+PiAgICByZW1haW5pbmcgY29t cGV0aXRpdmUgZm9yY2VzIG9wZXJhdG9ycyB0byBsb29rIGZvciB0aGUgbG93ZXN0IG5ldHdvcmsN Cj4+ICAgIFRvdGFsIENvc3Qgb2YgT3duZXJzaGlwIChUQ08pLiAgSW52ZXN0bWVudCBpbiBib3Ro IENhcGl0YWwNCj4+ICAgIEV4cGVuZGl0dXJlIChDQVBFWCkgYW5kIE9wZXJhdGlvbmFsIEV4cGVu c2UgKE9QRVgpIHNob3VsZCBiZSBtaW5pbWFsLg0KPj4gDQo+PiAgICBDYXJyaWVycyBhcmUgY29u c2lkZXJpbmcgbWlncmF0aW5nIHRvIHBhY2tldCB0cmFuc3BvcnQgbmV0d29ya3MgaW4NCj4+ICAg IG9yZGVyIHRvIHJlZHVjZSB0aGVpciBjb3N0cyBhbmQgdG8gaW1wcm92ZSB0aGVpciBhYmlsaXR5 IHRvIHN1cHBvcnQNCj4+ICAgIHNlcnZpY2VzIHdpdGggZ3VhcmFudGVlZCBTTEFzLiAgTWlncmF0 aW5nIGZyb20gU09ORVQvU0RIIHRvIHBhY2tldA0KPj4gICAgdHJhbnNwb3J0IG5ldHdvcmtzIHNo b3VsZCBub3QgaW52b2x2ZSBkcmFtYXRpYyBjaGFuZ2VzIGluIG5ldHdvcmsNCj4+ICAgIG9wZXJh dGlvbiwgc2hvdWxkIG5vdCBuZWNlc3NpdGF0ZSBleHRlbnNpdmUgcmV0cmFpbmluZywgYW5kIHNo b3VsZA0KPj4gICAgbm90IHJlcXVpcmUgbWFqb3IgY2hhbmdlcyB0byBleGlzdGluZyB3b3JrIHBy YWN0aWNlcy4gIFRoZSBhaW0gaXMgdG8NCj4+ICAgIHByZXNlcnZlIHRoZSBsb29rLWFuZC1mZWVs IHRvIHdoaWNoIGNhcnJpZXJzIGhhdmUgYmVjb21lIGFjY3VzdG9tZWQNCj4+ICAgIGluIGRlcGxv eWluZyB0aGVpciBTT05FVC9TREggbmV0d29ya3MsIHdoaWxlIHByb3ZpZGluZyBjb21tb24sIG11 bHRpLQ0KPj4gICAgbGF5ZXIgb3BlcmF0aW9ucywgcmVzaWxpZW5jeSwgY29udHJvbCBhbmQgbWFu YWdlbWVudCBmb3IgcGFja2V0LA0KPj4gICAgY2lyY3VpdCBhbmQgbGFtYmRhIHRyYW5zcG9ydCBu ZXR3b3Jrcy4NCj4+IA0KPj4gICAgQW4gaW1wb3J0YW50IGF0dHJpYnV0ZSBvZiBhIHRyYW5zcG9y dCBuZXR3b3JrIGlzIGl0cyBhYmlsaXR5IHRvDQo+PiAgICBmdW5jdGlvbiBpbmRlcGVuZGVudGx5 IGZyb20gYm90aCBpdHMgY2xpZW50IGFuZCBzZXJ2ZXIgKHRyYW5zbWlzc2lvbg0KPj4gICAgbWVk aWEpIGxheWVyIG5ldHdvcmtzLiAgSXQgc2hvdWxkIGJlIGNhcGFibGUgb2YgdHJhbnNtaXR0aW5n IG92ZXIgYW55DQo+PiAgICBtZWRpYS4gIEFub3RoZXIga2V5IGNoYXJhY3RlcmlzdGljIG9mIHRy YW5zcG9ydCBuZXR3b3JrcyBpcyB0aGUNCj4+ICAgIGNhcGFiaWxpdHkgdG8gbWFpbnRhaW4gdGhl IGludGVncml0eSBvZiB0aGUgY2xpZW50IHNpZ25hbCBiZXR3ZWVuIGl0cw0KPj4gICAgaW5ncmVz cyBhbmQgZWdyZXNzIHBvcnRzLg0KPj4gDQo+PiBUT006IEkgd291bGQgdXNlIHNvbWV0aGluZyBv dGhlciB0aGFuICJjbGllbnQgc2lnbmFsIiBoZXJlLiBTb21ldGhpbmcNCj4+IGxpa2UgImNsaWVu dCBwYXRoIiBvciBzb21ldGhpbmcgaXMgd2hhdCBJIHRoaW5rIHlvdSBtZWFuLg0KPj4gDQo+PiBB IHRyYW5zcG9ydCBuZXR3b3JrIG11c3QgcHJvdmlkZSB0aGUgbWVhbnMNCj4+ICAgIHRvIGNvbW1p dCBxdWFsaXR5IG9mIHNlcnZpY2Ugb2JqZWN0aXZlcyB0byBjbGllbnRzLiAgVGhpcyBpcyBhY2hp ZXZlZA0KPj4gICAgYnkgcHJvdmlkaW5nIGEgbWVjaGFuaXNtIGZvciBjbGllbnQgbmV0d29yayBz ZXJ2aWNlIGRlbWFyY2F0aW9uIGZvcg0KPj4gICAgdGhlIG5ldHdvcmsgcGF0aCB0b2dldGhlciB3 aXRoIGFuIGFzc29jaWF0ZWQgbmV0d29yayByZXNpbGllbmN5DQo+PiAgICBtZWNoYW5pc20uICBB IHRyYW5zcG9ydCBuZXR3b3JrIG11c3QgYWxzbyBwcm92aWRlIGEgbWV0aG9kIG9mIHNlcnZpY2UN Cj4+ICAgIG1vbml0b3JpbmcgaW4gb3JkZXIgdG8gdmVyaWZ5IHRoZSBkZWxpdmVyeSBvZiBhbiBh Z3JlZWQgcXVhbGl0eSBvZg0KPj4gICAgc2VydmljZS4gIFRoaXMgaXMgZW5hYmxlZCBieSBtZWFu cyBvZiBjYXJyaWVyLWdyYWRlIE9BTSB0b29scy4NCj4+IA0KPj4gICAgVGhlIGNvbm5lY3Rpdml0 eSBzZXJ2aWNlIGlzIHRoZSBiYXNpYyBzZXJ2aWNlIHByb3ZpZGVkIGJ5IGEgdHJhbnNwb3J0DQo+ PiAgICBuZXR3b3JrLiANCj4+IA0KPj4gVE9NOiBJcyBpdD8gRG9lcyB0aGUgdHJhbnNwb3J0IHJl YWxseSBwcm92aWRlIGNvbm5lY3Rpb25zIG9yIGRvZXMgaXQNCj4+IHByb3ZpZGUgdHJhbnNwb3J0 IHBhdGhzPyAgSSBhbSBzZW5zaXRpdmUgdG8gdGhlIHRlcm1zIHVzZWQgaGVyZS4gV2UNCj4+IGRv bid0IHdhbnQgdGhpcyB0byBiZWNvbWUgYSBjb25uZWN0LWZlc3QuIFNlZW1zIHRvIG1lIHRoYXQg eW91IGV4cGxhaW4NCj4+IHRoaXMgYmV0dGVyIGluIHRoZSBuZXh0IHNlbnRlbmNlIGFueWhvdy4N Cj4+IA0KPj4gIFRoZSBwdXJwb3NlIG9mIGEgdHJhbnNwb3J0IG5ldHdvcmsgaXMgdG8gdHJhbnNw YXJlbnRseQ0KPj4gICAgY2FycnkgY2xpZW50IHNpZ25hbHMgKGkuZS4gdGhlIHN0cmVhbSBvZiBj bGllbnQgUERVcyBvciBjbGllbnQgYml0cykNCj4+IA0KPj4gVE9NOiBBZ2FpbiwgSSBkb24ndCBs aWtlIHRoZSB0ZXJtICJzaWduYWxzIiBoZXJlLiBVc2UgImNsaWVudCBkYXRhIiBvcg0KPj4gc29t ZXRoaW5nLg0KPj4gDQo+PiAgICBiZXR3ZWVuIGVuZHBvaW50cyBpbiB0aGUgbmV0d29yayAodHlw aWNhbGx5IG92ZXIgc2V2ZXJhbCBpbnRlcm1lZGlhdGUNCj4+ICAgIG5vZGVzKS4gIFRoZXNlIGVu ZHBvaW50cyBtYXkgYmUgc2VydmljZSBzd2l0Y2hpbmcgcG9pbnRzIG9yIHNlcnZpY2UNCj4+ICAg IHRlcm1pbmF0aW5nIHBvaW50cy4gIFRoZSBjb25uZWN0aXZpdHkgc2VydmljZXMgb2ZmZXJlZCB0 byBjdXN0b21lcnMNCj4+ICAgIGFyZSBhZ2dyZWdhdGVkIGludG8gbGFyZ2UsIGxvbmctaG9sZGlu ZyB0aW1lIHBpcGVzL3RydW5rcyB3aGljaA0KPj4gDQo+PiBUT006IERvIHlvdSByZWFsbHkgbWVh biB0byBjYWxsIHRoZXNlICJ0aW1lIHBpcGVzIj8gIFNvdW5kcyB0b28NCj4+IGZ1dHVyaXN0aWMg ZXZlbiBmb3IgdGhpcyB3b3JrLiAqKSAgSSB0aGluayB5b3UgbWVhbiAiLi4uaW50byByZWxhdGl2 ZWx5DQo+PiBsYXJnZSwgbG9uZy1sYXN0aW5nIHBhdGhzLi4uIg0KPj4gDQo+PiAgICBlbmFibGUg dGhlIGVmZmljaWVudCBhbmQgcmVsaWFibGUgb3BlcmF0aW9uIG9mIHRoZSB0cmFuc3BvcnQgbmV0 d29yay4NCj4+ICAgIFRoZXNlIHRydW5rcyBhcmUgbW9kaWZpZWQgaW5mcmVxdWVudGx5Lg0KPj4g DQo+PiBUT006IEtlZXAgdGhlIHRlcm1pbm9sb2d5IGNvbnNpc3RlbnQgaGVyZSB0b28uIFRoZXJl IGlzIHRoZSB1c2Ugb2YNCj4+ICJ0cnVua3MiLCAicGlwZXMiLCBldGMuLi4NCj4+IA0KPj4gICAg QWdncmVnYXRpb24gYW5kIGhpZXJhcmNoeSBhcmUgYmVuZWZpY2lhbCBmb3IgYWNoaWV2aW5nIHNj YWxhYmlsaXR5DQo+PiAgICBhbmQgc2VjdXJpdHkgc2luY2U6DQo+PiANCj4+IA0KPj4gDQo+PiBO aXZlbi1KZW5raW5zLCBldCBhbC4gICAgRXhwaXJlcyBKYW51YXJ5IDIsIDIwMDkgICAgICAgICAg ICAgICAgW1BhZ2UgM10NCj4+IAwNCj4+IEludGVybmV0LURyYWZ0ICAgICAgICAgICAgTVBMUy1U UCBSZXF1aXJlbWVudHMgICAgICAgICAgICAgICAgIEp1bHkgMjAwOA0KPj4gDQo+PiANCj4+ICAg IDEuICBUaGV5IHJlZHVjZSB0aGUgbnVtYmVyIG9mIHByb3Zpc2lvbmluZyBhbmQgZm9yd2FyZGlu ZyBzdGF0ZXMgaW4NCj4+ICAgICAgICB0aGUgbmV0d29yayBjb3JlLg0KPj4gDQo+PiAgICAyLiAg VGhleSByZWR1Y2UgbG9hZCBhbmQgdGhlIGNvc3Qgb2YgaW1wbGVtZW50aW5nIHNlcnZpY2UgYXNz dXJhbmNlDQo+PiAgICAgICAgYW5kIGZhdWx0IG1hbmFnZW1lbnQuDQo+PiANCj4+IFRPTTogRG8g dGhleSByZWFsbHkgcmVkdWNlIGxvYWQ/IFRoaXMgaXMgb25lIG9mIHRob3NlIGZsdWZmeSwgb3Bl bi1lbmRlZA0KPj4gdGVybXMgbGlrZSAic2NhbGVhYmlsaXR5IiB0aGF0IEkgZG9uJ3QgbGlrZSB1 c2VkIHVubGVzcyBpdCBpcyBjbGVhcmx5DQo+PiBkZWZpbmVkLiANCj4+IA0KPj4gICAgMy4gIENs aWVudCBzaWduYWxzIGFyZSBjb21wbGV0ZWx5IGVuY2Fwc3VsYXRlZCBhbmQgaXNvbGF0ZWQgZnJv bSBlYWNoDQo+PiAgICAgICAgb3RoZXIuICBUaGlzIGFsc28gYWxsb3dzIGNvbXBsZXRlIGlzb2xh dGlvbiBvZiBjdXN0b21lciB0cmFmZmljDQo+PiAgICAgICAgZnJvbSBjYXJyaWVyIG9wZXJhdGlv bnMuDQo+PiANCj4+IFRPTTogRG9lcyB0aGlzIHJlYWxseSBoYXBwZW4gYXQgdGhlIGRhdGEgb3Ig Y29udHJvbCBwbGFuZSBvciBib3RoPyBPciBkbw0KPj4gd2UgY2FyZT8NCj4+IA0KPj4gDQo+PiAg ICBDbGllbnQgc2lnbmFscyBhcmUgZmlyc3QgdHJhbnNwYXJlbnRseSBlbmNhcHN1bGF0ZWQuICBU aGVzZQ0KPj4gICAgZW5jYXBzdWxhdGVkIGNsaWVudCBzaWduYWxzIGFyZSB0aGVuIGFnZ3JlZ2F0 ZWQgZm9yIHRyYW5zcG9ydCB0aHJvdWdoDQo+PiAgICB0aGUgbmV0d29yayBpbiBvcmRlciB0byBv cHRpbWl6ZSBuZXR3b3JrIG1hbmFnZW1lbnQuICBTZXJ2ZXIgbGF5ZXINCj4+ICAgIE9BTSBpcyB1 c2VkIHRvIG1vbml0b3IgdGhlIHRyYW5zcG9ydCBpbnRlZ3JpdHkgb2YgdGhlIGNsaWVudCBsYXll cg0KPj4gICAgYWdncmVnYXRlLiAgQXQgYW55IGhvcCwgdGhlIGFnZ3JlZ2F0ZWQgc2lnbmFscyBt YXkgYmUgZnVydGhlcg0KPj4gICAgYWdncmVnYXRlZCBpbiBsb3dlciBsYXllciB0cmFuc3BvcnQg bmV0d29yayBwYXRocyBmb3IgdHJhbnNwb3J0DQo+PiAgICBhY3Jvc3MgaW50ZXJtZWRpYXRlIHNo YXJlZCBsaW5rcy4gIFRoZSBlbmNhcHN1bGF0ZWQgY2xpZW50IHNpZ25hbHMNCj4+ICAgIGFyZSBl eHRyYWN0ZWQgYXQgdGhlIGVkZ2VzIG9mIGFnZ3JlZ2F0aW9uIGRvbWFpbnMsIGFuZCBhcmUgZWl0 aGVyDQo+PiAgICBkZWxpdmVyZWQgdG8gdGhlIGNsaWVudCBvciBmb3J3YXJkZWQgdG8gYW5vdGhl ciBkb21haW4uICBJbiB0aGUgY29yZQ0KPj4gICAgb2YgdGhlIG5ldHdvcmssIG9ubHkgdGhlIHNl cnZlciBsYXllciBhZ2dyZWdhdGVkIHNpZ25hbHMgYXJlDQo+PiAgICBtb25pdG9yZWQ7IGluZGl2 aWR1YWwgY2xpZW50IHNpZ25hbHMgYXJlIG1vbml0b3JlZCBhdCB0aGUgbmV0d29yaw0KPj4gICAg Ym91bmRhcnkgaW4gdGhlIGNsaWVudCBsYXllciBuZXR3b3JrLg0KPj4gDQo+PiBUT006IEkgYW0g bm90IHN1cmUgdGhlIGFib3ZlIGlzIGFwcHJvcHJpYXRlIGZvciBhIHJlcXVpcmVtZW50cyBkb2N1 bWVudC4NCj4+IEl0IHNvdW5kcyBsaWtlIHlvdSBhcmUgc3BlbGxpbmcgb3V0IGFuIGFsZ29yaXRo bSBmb3IgaG93IGEgc29sdXRpb24NCj4+IHNob3VsZCB3b3JrLg0KPj4gDQo+PiAgICBRdWFsaXR5 LW9mLXNlcnZpY2UgbWVjaGFuaXNtcyBhcmUgcmVxdWlyZWQgaW4gdGhlIHBhY2tldCB0cmFuc3Bv cnQNCj4+ICAgIG5ldHdvcmsgdG8gZW5zdXJlIHRoZSBwcmlvcml0aXphdGlvbiBvZiBjcml0aWNh bCBzZXJ2aWNlcywgdG8NCj4+ICAgIGd1YXJhbnRlZSBCVyBhbmQgdG8gY29udHJvbCBqaXR0ZXIg YW5kIGRlbGF5Lg0KPj4gDQo+PiBUT006IEFyZSB0aGV5IHJlcXVpcmVkIGV2ZXJ5d2hlcmUgdGhl IHNlcnZpY2UgZXhpc3RzLCBvciBzYXkganVzdCBhdCB0aGUNCj4+IGluZ3Jlc3MvZWdyZXNzIGZv ciBwb2xpY2luZy9tYXJraW5nIGZ1bmN0aW9ucz8gIFdoaWxlIHdlIGFyZSBvbiB0aGUNCj4+IHN1 YmplY3QsIGRvIHdlIHdhbnQgdG8gYmUgbW9yZSBzcGVjaWZpYyBhYm91dCBRb1MgcmVxdWlyZW1l bnRzPw0KPj4gDQo+PiAgICBTZXJ2aWNlIHByb3ZpZGVycyByZXF1aXJlIGNvbnRyb2wgYW5kIGRl dGVybWluaXN0aWMgdXNhZ2Ugb2YgbmV0d29yaw0KPj4gICAgcmVzb3VyY2VzLiAgVGhleSBuZWVk IGVuZC10by1lbmQgY29udHJvbCB0byBlbmdpbmVlciBuZXR3b3JrIHBhdGhzDQo+PiAgICBhbmQg dG8gZWZmaWNpZW50bHkgdXRpbGl6ZSBuZXR3b3JrIHJlc291cmNlcy4gIFRoZXkgcmVxdWlyZQ0K Pj4gICAgY2FwYWJpbGl0aWVzIHRvIHN0YXRpY2FsbHkgKE9TUyBiYXNlZCkgcHJvdmlzaW9uIGRl dGVybWluaXN0aWMsDQo+PiAgICBwcm90ZWN0ZWQgYW5kIHNlY3VyZWQgc2VydmljZXMgYW5kIHRo ZWlyIGFzc29jaWF0ZWQgcmVzb3VyY2VzIGFzIHdlbGwNCj4+ICAgIGFzIGFsdGVybmF0aXZlIGNv bnRyb2wtcGxhbmUgb3B0aW9ucy4NCj4+IA0KPj4gVE9NOiBUaGV5IGFsc28gcmVxdWlyZSBkeW5h bWljIG9uZXMuIFBsZWFzZSBwdXQgdGhhdCBpbi4gIEkgZG9uJ3Qgd2FudA0KPj4gdG8gYmUgYXNr aW5nIGZvciBvbmx5IGEgY29tcGxldGVseSBzdGF0aWMgc3lzdGVtLg0KPj4gDQo+PiAgICBUaGUg dHJhbnNwb3J0IG5ldHdvcmsgbXVzdCBiZSBjYXBhYmxlIG9mIHRyYW5zcG9ydGluZyBtdWx0aXBs ZQ0KPj4gICAgc2VydmljZXMgaW4gYSBzY2FsYWJsZSBtYW5uZXIuDQo+PiANCj4+IFRPTTogQWdh aW4sIHRoaXMgdXNlIG9mICJzY2FsYWJsZSIgb2ZmZW5kcyBtZS4gUGxlYXNlIGJlIG1vcmUgc3Bl Y2lmaWMNCj4+IG9yIHRha2UgdGhlIHNlbnRlbmNlIG91dCBhcyBpdCBpcyBtZWFuaW5nbGVzcyBh cyBzdGF0ZWQuDQo+PiANCj4+ICAgIENhcnJpZXJzIHdpbGwgc3RpbGwgbmVlZCB0byBjb3BlIHdp dGggbGVnYWN5IG5ldHdvcmtzICh3aGljaCBhcmUNCj4+ICAgIGNvbXBvc2VkIG9mIG1hbnkgbGF5 ZXJzIGFuZCB0ZWNobm9sb2dpZXMpLCB0aHVzIHRoZSBwYWNrZXQgdHJhbnNwb3J0DQo+PiAgICBu ZXR3b3JrIHNob3VsZCBpbnRlcndvcmsgd2l0aCBvdGhlciBwYWNrZXQgYW5kIHRyYW5zcG9ydCBu ZXR3b3Jrcw0KPj4gICAgKGJvdGggaG9yaXpvbnRhbGx5IGFuZCB2ZXJ0aWNhbGx5KS4gIFZlcnRp Y2FsIGludGVyd29ya2luZyBpcyBhbHNvDQo+PiAgICBrbm93biBhcyBjbGllbnQvc2VydmVyIG9y IG5ldHdvcmsgaW50ZXJ3b3JraW5nLiAgSG9yaXpvbnRhbA0KPj4gICAgaW50ZXJ3b3JraW5nIGlz IGFsc28ga25vd24gYXMgcGVlci1wYXJ0aXRpb24gb3Igc2VydmljZSBpbnRlcndvcmtpbmcuDQo+ PiANCj4+IFRPTTogRGlkbid0IHlvdSBqdXN0IHNheSB0aGF0IHZlcnRpY2FsIGludGVyd29ya2lu ZyB3YXMgY2xpZW50DQo+PiBpbnRlcndvcmtpbmcgaW4gdGhlIGZpcnN0IHNlbnRlbmNlPyBIb3cg Y2FuIGhvcml6b250YWwgYmUgc2VydmljZQ0KPj4gaW50ZXJ3b3JraW5nIGFzIHdlbGw/DQo+PiAN Cj4+ICAgIEZvciBtb3JlIGRldGFpbHMgb24gZWFjaCB0eXBlIG9mIGludGVyd29ya2luZyBhbmQg c29tZSBvZiB0aGUgaXNzdWVzDQo+PiAgICB0aGF0IG1heSBhcmlzZSAoZXNwZWNpYWxseSB3aXRo IGhvcml6b250YWwgaW50ZXJ3b3JraW5nKSBzZWUNCj4+ICAgIFtJVFUuWTE0MDEuMjAwOF0uDQo+ PiANCj4+ICAgIE1QTFMgaXMgYSBtYXR1cmluZyBwYWNrZXQgdGVjaG5vbG9neSBhbmQgaXQgaXMg YWxyZWFkeSBwbGF5aW5nIGFuDQo+PiANCj4+IA0KPj4gDQo+PiBOaXZlbi1KZW5raW5zLCBldCBh bC4gICAgRXhwaXJlcyBKYW51YXJ5IDIsIDIwMDkgICAgICAgICAgICAgICAgW1BhZ2UgNF0NCj4+ IAwNCj4+IEludGVybmV0LURyYWZ0ICAgICAgICAgICAgTVBMUy1UUCBSZXF1aXJlbWVudHMgICAg ICAgICAgICAgICAgIEp1bHkgMjAwOA0KPj4gDQo+PiANCj4+ICAgIGltcG9ydGFudCByb2xlIGlu IHRyYW5zcG9ydCBuZXR3b3JrcyBhbmQgc2VydmljZXMuICBIb3dldmVyLCBub3QgYWxsDQo+PiAg ICBvZiBNUExTJ3MgY2FwYWJpbGl0aWVzIGFuZCBtZWNobmlzbXMgYXJlIG5lZWRlZCBhbmQvb3Ig Y29uc2lzdGVudA0KPj4gICAgd2l0aCB0cmFuc3BvcnQgbmV0d29yayBvcGVyYXRpb25zLiAgVGhp cyBkb2N1bWVudCBpZGVudGlmaWVzIHRoZQ0KPj4gICAgcmVxdWlyZWQgY2FwYWJpbGl0aWVzIGZv ciBNUExTIHNvIHRoYXQgaXQgY2FuIGJldHRlciBmaXQgYSB0cmFuc3BvcnQNCj4+ICAgIHJvbGUu DQo+PiANCj4+IFRPTTogSSB0aGluayB5b3Ugd2FudCB0byBzYXkgImlkZW50aWZpZXMgdGhlIHJl cXVpcmVkIHN1Yi1zZXQgb2YNCj4+IGNhcGFiaWxpdGllcy4uLiIgIGFuZCBsYXRlciAicG90ZW50 aWFsbHkgbmV3IG9ucyBzcGVjaWZpYyBmb3IgdHJhbnNwb3J0DQo+PiBuZXR3b3JrcyIgd2hpY2gg aXQgc2VlbXMgeW91IHNheSB0d28gcGFyYWdyYXBocyBsYXRlci4NCj4+IA0KPj4gICAgQ29tYmlu aW5nIHRoZSBwYWNrZXQgZXhwZXJpZW5jZSBvZiBNUExTIHdpdGggdGhlIG9wZXJhdGlvbmFsDQo+ PiAgICBleHBlcmllbmNlIG9mIFNPTkVUL1NESCBjb25zdGl0dXRlcyBhIHBhY2tldCB0cmFuc3Bv cnQgdGVjaG5vbG9neQ0KPj4gICAgbmFtZWQgTVBMUy1UUC4gIE1QTFMtVFAgd2lsbCBlbmFibGUg dGhlIG1pZ3JhdGlvbiBvZiBTT05FVC9TREgNCj4+ICAgIG5ldHdvcmtzIHRvIGEgcGFja2V0LWJh c2VkIG5ldHdvcmsgdGhhdCB3aWxsIGVhc2lseSBzY2FsZSB0byBzdXBwb3J0DQo+PiAgICBwYWNr ZXQgc2VydmljZXMgaW4gYSBzaW1wbGUgYW5kIGNvc3QgZWZmZWN0aXZlIHdheS4NCj4+IA0KPj4g ICAgTVBMUy1UUCBuZWVkcyB0byBjb21iaW5lIHRoZSBuZWNlc3NhcnkgZXhpc3RpbmcgY2FwYWJp bGl0aWVzIG9mIE1QTFMNCj4+ICAgIHdpdGggYWRkaXRpb25hbCBtaW5pbWFsIG1lY2hhbmlzbXMg aW4gb3JkZXIgdG8gbWVldCB0aGUgcmVxdWlyZW1lbnRzDQo+PiAgICBkZXNjcmliZWQgaW4gdGhp cyBkb2N1bWVudC4NCj4+IA0KPj4gICAgVGhlIHJlcXVpcmVtZW50cyBvZiBhbiBNUExTIHRyYW5z cG9ydCBwcm9maWxlIGFyZSBwcm92aWRlZCBiZWxvdy4NCj4+IA0KPj4gVE9NOiBUaGVyZSBpcyBh IHRlcm1pbm9sb2d5IGlzc3VlIGluIHRoZSB1c2Ugb2YgIk1QTFMtVFAiIG9yICJhbiBNUExTDQo+ PiB0cmFuc3BvcnQgcHJvZmlsZSIuIFRoYXQgaXMsIG9uIHRoZSBvbmUgaGFuZCB5b3UgcmVmZXIg dG8gYSB0ZWNobm9sb2d5LA0KPj4gYnV0IG9uIHRoZSBvdGhlciBoYW5kIHlvdSBhcmUgcmVmZXJy aW5nIHRvIGEgc3BlY2lmaWMgcHJvZmlsZS4gV2hpY2ggaXMNCj4+IGl0Pw0KPj4gDQo+PiANCj4+ IDIuICBNUExTLVRQIFJlcXVpcmVtZW50cw0KPj4gDQo+PiAyLjEuICBHZW5lcmFsIHJlcXVpcmVt ZW50cw0KPj4gDQo+PiAgICBvICBNUExTLVRQIE1VU1Qgb2ZmZXIgYXMgbXVjaCBjb21tb25hbGl0 eSBhcyBwb3NzaWJsZSB3aXRoIHRoZSBNUExTDQo+PiAgICAgICB1c2VyIHBsYW5lIGFzIGRlZmlu ZWQgYnkgSUVURi4gIFdoZW4gTVBMUyBvZmZlcnMgbXVsdGlwbGUgb3B0aW9ucw0KPj4gICAgICAg aW4gdGhpcyByZXNwZWN0LCBNUExTLVRQIFNIT1VMRCBzZWxlY3QgdGhlIG1pbmltdW0gc3ViLXNl dA0KPj4gICAgICAgKG5lY2Vzc2FyeSBhbmQgc3VmZmljaWVudCBzdWJzZXQpIGFwcGxpY2FibGUg dG8gYSB0cmFuc3BvcnQNCj4+ICAgICAgIG5ldHdvcmsgYXBwbGljYXRpb24uDQo+PiANCj4+ICAg IG8gIEFueSBuZXcgZnVuY3Rpb25hbGl0eSB0aGF0IGlzIGRlZmluZWQgdG8gZnVsZmlsIHRoZSBy ZXF1aXJlbWVudHMNCj4+ICAgICAgIGZvciBNUExTLVRQIE1VU1QgYmUgYWdyZWVkIHdpdGhpbiBJ RVRGIGFuZCByZS11c2UgKGFzIGZhciBhcw0KPj4gICAgICAgcHJhY3RpY2FsbHkgcG9zc2libGUp IGV4aXN0aW5nIE1QTFMgc3RhbmRhcmRzLg0KPj4gDQo+PiAgICBvICBNZWNoYW5pc21zIGFuZCBj YXBhYmlsaXRpZXMgTVVTVCBiZSBhYmxlIHRvIGludGVyb3BlcmF0ZSB3aXRoDQo+PiAgICAgICBl eGlzdGluZyBNUExTIGFuZCBQV0UgY29udHJvbCBhbmQgZGF0YSBwbGFuZXMgd2hlcmUgYXBwcm9w cmlhdGUuDQo+PiANCj4+IFRPTTogQ2hhbmdlIFBXRSB0byAiSUVURiBQV0UzIiBhbmQgIk1QTFMi IHRvICJJRVRGIE1QTFMiLiBUaGVyZSBhbHNvDQo+PiBuZWVkIHRvIGJlIHJlZmVyZW5jZXMgaGVy ZSB0byB0aGUgUFdFMyBhcmNoaXRlY3R1cmUgYW5kIE1QTFMNCj4+IGFyY2hpdGVjdHVyZXMuDQo+ PiANCj4+ICAgIG8gIE1QTFMtVFAgTVVTVCBzdXBwb3J0IHRyYWZmaWMgZW5naW5lZXJpbmcgY2Fw YWJpbGl0aWVzIHRoYXQgYWxsb3cNCj4+ICAgICAgIGRldGVybWluaXN0aWMgY29udHJvbCBvZiB0 aGUgdXNlIG9mIG5ldHdvcmsgcmVzb3VyY2VzLg0KPj4gDQo+PiAgICBvICBNUExTLVRQIE1VU1Qg c3VwcG9ydCB0aGUgbG9naWNhbCBzZXBhcmF0aW9uIG9mIHRoZSBjb250cm9sIGFuZA0KPj4gICAg ICAgbWFuYWdlbWVudCBwbGFuZXMgZnJvbSB0aGUgdXNlciBwbGFuZS4NCj4+IA0KPj4gICAgbyAg TVBMUy1UUCBTSE9VTEQgc3VwcG9ydCB0aGUgcGh5c2ljYWwgc2VwYXJhdGlvbiBvZiB0aGUgY29u dHJvbCBhbmQNCj4+ICAgICAgIG1hbmFnZW1lbnQgcGxhbmVzIGZyb20gdGhlIHVzZXIgcGxhbmUu DQo+PiANCj4+ICAgIG8gIE1QTFMtVFAgTVVTVCBzdXBwb3J0IHBvaW50IHRvIHBvaW50IChQMlAp IG9yIHBvaW50IHRvIG11bHRpcG9pbnQNCj4+ICAgICAgIChQMk1QKSBjb25uZWN0aW9ucy4NCj4+ IA0KPj4gVE9NOiBBcmUgd2UgYXZvaWRpbmcgTVAyTVAgY29uc2Npb3VzbHkgb3Igd2FzIGl0IGxl ZnQgb3V0Pw0KPj4gDQo+PiANCj4+IE5pdmVuLUplbmtpbnMsIGV0IGFsLiAgICBFeHBpcmVzIEph bnVhcnkgMiwgMjAwOSAgICAgICAgICAgICAgICBbUGFnZSA1XQ0KPj4gDA0KPj4gSW50ZXJuZXQt RHJhZnQgICAgICAgICAgICBNUExTLVRQIFJlcXVpcmVtZW50cyAgICAgICAgICAgICAgICAgSnVs eSAyMDA4DQo+PiANCj4+IA0KPj4gICAgbyAgTVBMUy1UUCBNVVNUIHN1cHBvcnQgc3RhdGljIHBy b3Zpc2lvbmluZyBvZiBjb25uZWN0aW9ucyB2aWEgYW4NCj4+ICAgICAgIE5NUy9PU1MgKGkuZS4g dmlhIHRoZSBtYW5hZ2VtZW50IHBsYW5lKS4NCj4+IA0KPj4gICAgbyAgU3RhdGljIHByb3Zpc2lv bmluZyBNVVNUIG5vdCBkZXBlbmQgb24gcm91dGluZyBvciBzaWduYWxpbmcNCj4+ICAgICAgIHBy b3RvY29scyAoZS5nLiAgR01QTFMsIE9TUEYsIElTLUlTLCBSU1ZQLCBCR1AsIExEUCBldGMuKS4N Cj4+IA0KPj4gICAgbyAgTVBMUy1UUCBjb25uZWN0aW9ucyBNQVkgYmUgYWJsZSB0byBiZSBwcm92 aXNpb25lZCBkeW5hbWljYWxseSB2aWENCj4+ICAgICAgIGEgY29udHJvbCBwbGFuZS4NCj4+IA0K Pj4gVE9NOiBJIGluc2lzdCB0aGF0IHdlIGNoYW5nZSB0aGUgTUFZIGFib3ZlIHRvIE1VU1QuIEkg d2FudCBhIGR5bmFtaWMNCj4+IHZlcnNpb24gb2YgdGhpcyBhcyBtdWNoIGFzIGEgc3RhdGljIG9u ZS4NCj4+IA0KPj4gDQo+PiAgICBvICBUaGUgTVBMUy1UUCBkYXRhIHBsYW5lIE1VU1QgYmUgY2Fw YWJsZSBvZiBmdW5jdGlvbmluZw0KPj4gICAgICAgaW5kZXBlbmRlbnRseSBvZiB0aGUgY29udHJv bCBvciBtYW5hZ2VtZW50IHBsYW5lIHVzZWQgdG8gb3BlcmF0ZQ0KPj4gICAgICAgdGhlIE1QTFMt VFAgbGF5ZXIgbmV0d29yay4gIFRoYXQgaXMgdGhlIE1QTFMtVFAgZGF0YSBwbGFuZQ0KPj4gICAg ICAgb3BlcmF0aW9uIE1VU1QgY29udGludWUgdG8gb3BlcmF0ZSBub3JtYWxseSBpZiB0aGUgbWFu YWdlbWVudA0KPj4gICAgICAgcGxhbmUgb3IgY29udHJvbCBwbGFuZSB0aGF0IGNvbmZpZ3VyZWQg dGhlIGNvbm5lY3Rpb25zIGZhaWxzLg0KPj4gDQo+PiAgICBvICBNUExTLVRQIE1VU1Qgc3VwcG9y dCBhbnkgbmV0d29yayB0b3BvbG9neSBhbmQgYmUgYWJsZSB0byBzdXBwb3J0DQo+PiAgICAgICBp bmNyZWFzaW5nIGJhbmR3aWR0aCBkZW1hbmRzLCB0b3BvbG9neSwgbnVtYmVyIG9mIGN1c3RvbWVy cyBvcg0KPj4gICAgICAgbnVtYmVyIG9mIHNlcnZpY2VzIGluY3JlbWVudGFsbHkuDQo+PiANCj4+ IA0KPj4gVE9NOiBJIHRoaW5rIGl0IGlzIGltcGVyYXRpdmUgdGhhdCBhbHRob3VnaCBhbiBNUExT LVRQIGlzIGRlZmluZWQgdG8NCj4+IHBsYXkgbmljZWx5IHdpdGggYW4gTVBMUyBvbmUsIGl0IGlz IGltcGVyYXRpdmUgdGhhdCBvbmUgY2FuIGRpc3Rpbmd1aXNoDQo+PiBiZXR3ZWVuIGJvdGgsIGF0 IGxlYXN0IGF0IHRoZSBjb250cm9sIHBsYW5lLCBidXQgcGVyaGFwcyBhdCB0aGUgZGF0YQ0KPj4g cGxhbmUgYXMgd2VsbC4NCj4+IA0KPj4gMi4yLiAgTGF5ZXJpbmcgcmVxdWlyZW1lbnRzDQo+PiAN Cj4+ICAgIG8gIEFuIE1QTFMtVFAgbmV0d29yayBNVVNUIG9wZXJhdGUgaW4gYSBtdWx0aXBsZSBs YXllciBuZXR3b3JrDQo+PiAgICAgICBlbnZpcm9ubWVudCBjb25zaXN0aW5nIG9mIHRoZSBmb2xs b3dpbmcgaW5kZXBlbmRlbnQgbGF5ZXJzOg0KPj4gDQo+PiAgICAgICAxLiAgQSAic2VydmljZSBs YXllciIgaW5zdGFuY2UgaW4gd2hpY2ggdGhlIGNvbm5lY3Rpb25zIGNhcnJ5IHRoZQ0KPj4gICAg ICAgICAgIGN1c3RvbWVyJ3MgKGluZGl2aWR1YWwgb3IgYnVuZGxlZCkgc2VydmljZSAobWF5IGJl IHBvaW50LXRvLQ0KPj4gICAgICAgICAgIHBvaW50LCBwb2ludC10by1tdWx0aXBvaW50IG9yIG11 bHRpcG9pbnQtdG8tbXVsdGlwb2ludA0KPj4gICAgICAgICAgIHNlcnZpY2VzKTsNCj4+IA0KPj4g ICAgICAgMi4gIEEgInRydW5rIGxheWVyIiB3aXRoIHBvaW50LXRvLXBvaW50IG9yIHBvaW50LXRv LW11bHRpcG9pbnQNCj4+ICAgICAgICAgICBjb25uZWN0aW9ucyB3aGljaCBhcmUgdXNlZCB0byBj YXJyeSBhZ2dyZWdhdGVzIG9mIHRoZSBuZXR3b3JrDQo+PiAgICAgICAgICAgInNlcnZpY2UgbGF5 ZXIiIGNvbm5lY3Rpb25zOyBhbmQNCj4+IA0KPj4gICAgICAgMy4gIEEgInRyYW5zbWlzc2lvbiBt ZWRpYSBsYXllciIgd2hpY2ggcHJvdmlkZXMgc2VjdGlvbnMgKHR3by1wb3J0DQo+PiAgICAgICAg ICAgcG9pbnQtdG8tcG9pbnQgY29ubmVjdGlvbnMpIHRvIGNhcnJ5IHRoZSBhZ2dyZWdhdGUgb2Yg bmV0d29yaw0KPj4gICAgICAgICAgIHRydW5rIG9yIG5ldHdvcmsgc2VydmljZSBjb25uZWN0aW9u cyBvbiB2YXJpb3VzIHBoeXNpY2FsDQo+PiAgICAgICAgICAgbWVkaWEuDQo+PiANCj4+IFRPTTog VGhpcyBzdHVmZiBiZWxvbmdzIGluIHRoZSBUZXJtaW5vbG9neSBzZWN0aW9uIGF0IHRoZSB0b3Au DQo+PiANCj4+ICAgIE1QTFMtVFAgbWF5IHByb3ZpZGUgdGhlICJzZXJ2aWNlIGxheWVyIiAoZm9y IFAyUCBhbmQgUDJNUCBzZXJ2aWNlcykNCj4+ICAgIGFuZC9vciB0aGUgInRydW5rIGxheWVyIiB3 aXRoaW4gYSBsYXllciBuZXR3b3JrIGVudmlyb25tZW50Lg0KPj4gDQo+PiAgICBvICBBbiBNUExT LVRQIGxheWVyIG5ldHdvcmsgTVVTVCBzdXBwb3J0IHRoZSB0cmFuc3BhcmVudCB0cmFuc3BvcnQg b2YNCj4+ICAgICAgIE1QTFMtVFAgYW5kIG5vbiBNUExTLVRQIGNsaWVudCBsYXllciBuZXR3b3Jr cy4NCj4+IA0KPj4gICAgbyAgQW4gTVBMUy1UUCBsYXllciBuZXR3b3JrIE1VU1QgYmUgYWJsZSB0 byBiZSB0cmFuc3BhcmVudGx5IGNhcnJpZWQNCj4+ICAgICAgIG92ZXIgTVBMUy1UUCBhbmQgbm9u IE1QTFMtVFAgc2VydmVyIGxheWVyIG5ldHdvcmtzIChzdWNoIGFzDQo+PiAgICAgICBFdGhlcm5l dCwgT1ROLCBldGMuKQ0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiBOaXZlbi1KZW5raW5zLCBldCBh bC4gICAgRXhwaXJlcyBKYW51YXJ5IDIsIDIwMDkgICAgICAgICAgICAgICAgW1BhZ2UgNl0NCj4+ IAwNCj4+IEludGVybmV0LURyYWZ0ICAgICAgICAgICAgTVBMUy1UUCBSZXF1aXJlbWVudHMgICAg ICAgICAgICAgICAgIEp1bHkgMjAwOA0KPj4gDQo+PiANCj4+ICAgIG8gIEl0IE1VU1QgYmUgcG9z c2libGUgdG8gb3BlcmF0ZSB0aGUgTVBMUy1UUCBsYXllciBuZXR3b3JrDQo+PiAgICAgICBpbmRl cGVuZGVudGx5IG9mIG90aGVyIGxheWVyIG5ldHdvcmtzIChlaXRoZXIgTVBMUy1UUCBvciBub24N Cj4+ICAgICAgIE1QTFMtVFApLg0KPj4gDQo+PiAgICBUaGlzIGlzIG5vdCBvbmx5IGEgdGVjaG5v bG9neSByZXF1aXJlbWVudCwgZGlmZmVyZW50IGFkbWluaXN0cmF0aXZlDQo+PiAgICBncm91cHMg bWF5IGJlIHJlc3BvbnNpYmxlIGZvciBkaWZmZXJlbnQgbGF5ZXIgbmV0d29ya3MgKGV2ZW4gd2hl bg0KPj4gICAgdGhleSBhcmUgb2YgdGhlIHNhbWUgdHlwZSkpLCBhbmQgcmVxdWlyZSB0aGUgY2Fw YWJpbGl0eSB0bw0KPj4gICAgb3BlcmF0aW9uYWxseSBzdXBwb3J0IHRoZSBkaWZmZXJlbnQgbGF5 ZXJzLg0KPj4gDQo+PiAgICBvICBJdCBNVVNUIGJlIHBvc3NpYmxlIHRvIGhpZGUgTVBMUy1UUCBs YXllciBuZXR3b3JrIGFkZHJlc3NpbmcgYW5kDQo+PiAgICAgICBvdGhlciBpbmZvcm1hdGlvbiAo ZS5nLiB0b3BvbG9neSkgZnJvbSBjbGllbnQgbGF5ZXJzLg0KPj4gDQo+PiAyLjMuICBEYXRhIHBs YW5lIHJlcXVpcmVtZW50cw0KPj4gDQo+PiAgICBvICBUaGUgaWRlbnRpZmljYXRpb24gb2YgZWFj aCBjb25uZWN0aW9uIHdpdGhpbiBpdHMgYWdncmVnYXRlIE1VU1QgYmUNCj4+ICAgICAgIHN1cHBv cnRlZC4NCj4+IA0KPj4gICAgbyAgQSBsYWJlbCBpbiBhIHBhcnRpY3VsYXIgc2VjdGlvbiBNVVNU IHVuaXF1ZWx5IGlkZW50aWZ5IHRoZQ0KPj4gICAgICAgY29ubmVjdGlvbi4NCj4+IA0KPj4gICAg byAgQSBjb25uZWN0aW9uJ3Mgc291cmNlIE1VU1QgYmUgaWRlbnRpZmlhYmxlIGF0IGl0cyBkZXN0 aW5hdGlvbi4NCj4+IA0KPj4gICAgQ29ubmVjdGlvbnMgY2FuIGJlIGFnZ3JlZ2F0ZWQgaW50byB0 cnVua3MgYnkgcHVzaGluZyBhbmQgZGUtDQo+PiAgICBhZ2dyZWdhdGVkIGJ5IHBvcHBpbmcgbGFi ZWxzLiAgTVBMUy1UUCBsYWJlbHMgbWF5IGJlIHN3YXBwZWQgd2l0aGluIGENCj4+ICAgIGNvbm5l Y3Rpb24gaW4gYSBsYXllciBuZXR3b3JrIGluc3RhbmNlIHdoZW4gdGhlIHRyYWZmaWMgaXMgZm9y d2FyZGVkDQo+PiAgICBmcm9tIG9uZSBNUExTLVRQIGxpbmsgY29ubmVjdGlvbiB0byBhbm90aGVy IE1QTFMtVFAgbGluayBjb25uZWN0aW9uLg0KPj4gDQo+PiAgICBvICBMYWJlbGxpbmcgTVVTVCBt YWtlIHVzZSBvZiB0aGUgTVBMUyBsYWJlbCBhbmQgbGFiZWwgc3RhY2sgZW50cnkgYXMNCj4+ICAg ICAgIGRlZmluZWQgaW4gUkZDMzAzMi4NCj4+IA0KPj4gICAgbyAgSXQgTVVTVCBiZSBwb3NzaWJs ZSB0byBvcGVyYXRlIGFuZCBjb25maWd1cmUgdGhlIE1QTFMtVFAgZGF0YQ0KPj4gICAgICAgKHRy YW5zcG9ydCkgcGxhbmUgd2l0aG91dCBhbnkgSVAgZnVuY3Rpb25hbGl0eS4NCj4+IA0KPj4gICAg byAgTVBMUy1UUCBNVVNUIHN1cHBvcnQgYm90aCB1bmlkaXJlY3Rpb25hbCBhbmQgYmktZGlyZWN0 aW9uYWwgcG9pbnQtDQo+PiAgICAgICB0by1wb2ludCBjb25uZWN0aW9ucy4NCj4+IA0KPj4gICAg byAgVGhlIGZvcndhcmQgYW5kIGJhY2t3YXJkIGRpcmVjdGlvbnMgb2YgYSBiaS1kaXJlY3Rpb25h bCBjb25uZWN0aW9uDQo+PiAgICAgICBTSE9VTEQgZm9sbG93IHRoZSBzYW1lIHBhdGggd2l0aGlu IHRoZSBNUExTLVRQIG5ldHdvcmsuDQo+PiANCj4+IFRPTTogSSBhbSBub3Qgc3VyZSBpZiB3ZSBz YXkgdGhhdCB0aGV5IFNIT1VMRCBhcyBtdWNoIGFzICJ0aGV5IE1VU1QgYmUNCj4+IGNhcGFibGUg b2YiLiANCj4+IA0KPj4gICAgbyAgVGhlIGludGVybWVkaWF0ZSBub2RlcyBTSE9VTEQgYmUgYXdh cmUgYWJvdXQgdGhlIGJpbmRpbmcgb2YgdGhlDQo+PiAgICAgICBmb3J3YXJkIGFuZCB0aGUgYmFj a3dhcmQgZGlyZWN0aW9ucyBiZWxvbmdpbmcgdG8gdGhlIHNhbWUgYmktDQo+PiAgICAgICBkaXJl Y3Rpb25hbCBjb25uZWN0aW9uLg0KPj4gDQo+PiBUT006IEFnYWluLCAiU0hPVUxEIGJlIGNhcGFi bGUgb2YiIHNlZW1zIGJldHRlci4NCj4+IA0KPj4gICAgbyAgTVBMUy1UUCBTSE9VTEQgc3VwcG9y dCB1bmlkaXJlY3Rpb25hbCBwb2ludC10by1tdWx0aXBvaW50DQo+PiAgICAgICBjb25uZWN0aW9u cy4NCj4+IA0KPj4gICAgbyAgTVBMUy1UUCBjb25uZWN0aW9ucyBNVVNUIE5PVCBwZXJmb3JtIG1l cmdpbmcgaW4gYSB3YXkgdGhhdA0KPj4gICAgICAgcHJldmVudHMgdGhlIHVuaXF1ZSBpZGVudGlm aWNhdGlvbiBvZiB0aGUgc291cmNlIGF0IHRoZQ0KPj4gDQo+PiANCj4+IA0KPj4gTml2ZW4tSmVu a2lucywgZXQgYWwuICAgIEV4cGlyZXMgSmFudWFyeSAyLCAyMDA5ICAgICAgICAgICAgICAgIFtQ YWdlIDddDQo+PiAMDQo+PiBJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIE1QTFMtVFAgUmVxdWly ZW1lbnRzICAgICAgICAgICAgICAgICBKdWx5IDIwMDgNCj4+IA0KPj4gDQo+PiAgICAgICBkZXN0 aW5hdGlvbiAoZS5nLiBubyB1c2Ugb2YgTERQIG1wMnAgc2lnbmFsaW5nIGluIG9yZGVyIHRvIGF2 b2lkDQo+PiAgICAgICBsb3NpbmcgTFNQIGhlYWQtZW5kIGluZm9ybWF0aW9uLCBubyB1c2Ugb2Yg UEhQLCBldGMpLg0KPj4gDQo+PiAgICBvICBNUExTLVRQIFNIT1VMRCBzdXBwb3J0IHRyYW5zcG9y dCBhbmQgUW9TIG1lY2hhbmlzbXMgdGhhdCBjYW4NCj4+ICAgICAgIGRlbGl2ZXIgc3RhdGlzdGlj YWwgbXVsdGlwbGV4aW5nIGdhaW4uICBQYWNrZXRzIGV4Y2VlZGluZyB0aGUNCj4+ICAgICAgIGFn cmVlZCB0cmFmZmljIHByb2ZpbGUgbWF5IGJlIG1hcmtlZCBvciBkaXNjYXJkZWQgYnkgdGhlIHRy YWZmaWMNCj4+ICAgICAgIGNvbmRpdGlvbmluZyBhdCB0aGUgaW5ncmVzcyBvZiB0aGUgTVBMUy1U UCBuZXR3b3JrLg0KPj4gDQo+PiBUT006IEhvdyBhYm91dCBlZ3Jlc3MgcG9saWNpbmcgKyBtYXJr aW5nPw0KPj4gDQo+PiANCj4+ICAgIG8gIE1QTFMtVFAgTVVTVCBzdXBwb3J0IGNvbm5lY3Rpb25z IHRocm91Z2ggYSBzaW5nbGUgZG9tYWluLg0KPj4gDQo+PiAgICBvICBNUExTLVRQIFNIT1VMRCBz dXBwb3J0IGNvbm5lY3Rpb25zIHRocm91Z2ggbXVsdGlwbGUgZG9tYWlucy4NCj4+IA0KPj4gICAg byAgTVBMUy1UUCBNVVNUIGJlIGFibGUgdG8gYWNjb21tb2RhdGUgbmV3IHRyYWZmaWMgdHlwZXMu DQo+PiANCj4+IFRPTTogTmV3IHRyYWZmaWMgdHlwZXMgb3RoZXIgdGhhbiB0aG9zZSBzdXBwb3J0 ZWQgYnkgTVBMUz8gVGhpcyBkb2Vzbid0DQo+PiBtYWtlIHNlbnNlIHRvIG1lIGFzIHRoaXMgd2ls bCByZXN1bHQgaW4gTVBMUy1UUCBub3QgYmVpbmcgYSBzdWJzZXQgb2YNCj4+IE1QTFMuDQo+PiAN Cj4+ICAgIG8gIE1QTFMtVFAgU0hPVUxEIHN1cHBvcnQgbWVjaGFuaXNtcyB0byBzYWZlZ3VhcmQg YWdhaW5zdCB0aGUNCj4+ICAgICAgIHByb3Zpc2lvbmluZyBvZiBjb25uZWN0aW9ucyB3aGljaCBj b250YWluIGZvcndhcmRpbmcgbG9vcHMuDQo+PiANCj4+ICAgIG8gIE1QTFMtVFAgU0hPVUxEIHN1 cHBvcnQgbWVjaGFuaXNtcyB0byBtaW5pbWl6ZSB0cmFmZmljIGltcGFjdA0KPj4gICAgICAgZHVy aW5nIG5ldHdvcmsgcmVjb25maWd1cmF0aW9uLg0KPj4gDQo+PiAgICBvICBNUExTLVRQIFNIT1VM RCBzdXBwb3J0IG1lY2hhbmlzbXMgd2hpY2ggZW5zdXJlIHRoZSBpbnRlZ3JpdHkgb2YNCj4+ICAg ICAgIHRoZSBhZGFwdGVkIGluZm9ybWF0aW9uLg0KPj4gDQo+PiAgICBvICBNUExTLVRQIE1VU1Qg c3VwcG9ydCBhbiB1bmFtYmlndW91cyBhbmQgcmVsaWFibGUgbWVhbnMgb2YNCj4+ICAgICAgIGRp c3Rpbmd1aXNoaW5nIHVzZXJzJyAoY2xpZW50KSBwYWNrZXRzIGZyb20gTVBMUy1UUCBjb250cm9s IHBsYW5lDQo+PiAgICAgICBhbmQgbWFuYWdlbWVudCBwbGFuZSBwYWNrZXRzLg0KPj4gDQo+PiAy LjQuICBDb250cm9sIHBsYW5lIHJlcXVpcmVtZW50cw0KPj4gDQo+PiAgICBvICBBIGRpc3RyaWJ1 dGVkIGNvbnRyb2wgcGxhbmUgTUFZIGJlIHN1cHBvcnRlZCB0byBlbmFibGUgZmFzdCwNCj4+ICAg ICAgIGR5bmFtaWMgYW5kIHJlbGlhYmxlIHNlcnZpY2UgcHJvdmlzaW9uaW5nIGluIG11bHRpLXZl bmRvciBhbmQNCj4+ICAgICAgIG11bHRpLWRvbWFpbiBlbnZpcm9ubWVudHMgdXNpbmcgc3RhbmRh cmRpemVkIHByb3RvY29scyB0aGF0DQo+PiAgICAgICBndWFyYW50ZWUgaW50ZXJvcGVyYWJpbGl0 eS4NCj4+IA0KPj4gICAgbyAgSWYgYSBjb250cm9sIHBsYW5lIGlzIHVzZWQgZm9yIGNvbmZpZ3Vy YXRpb24gb2YgTVBMUy1UUA0KPj4gICAgICAgY29ubmVjdGlvbnMgdGhlbjoNCj4+IA0KPj4gICAg ICAgKiAgRmFpbHVyZSBhbmQgcmVjb3Zlcnkgb2YgdGhlIGNvbnRyb2wgcGxhbmUgTVVTVCBOT1Qg aW1wYWN0IHRoZQ0KPj4gICAgICAgICAgTVBMUy1UUCBmb3J3YXJkaW5nIHBsYW5lLg0KPj4gDQo+ PiBUT006IFRoaXMgaXMgZGlmZmljdWx0LCBhcyB0aGlzIHJlYWxseSBpcyBoYW5kbGVkIGluIHBy YWN0aWNlIGF0IGJvdGgNCj4+IGRhdGEgYW5kIGNvbnRyb2wgcGxhbmVzLCBkZXBlbmRpbmcgb24g aG93IHRoaXMgaXMgY29uZmlndXJlZC9kZXNpZ25lZCwNCj4+IGFuZCB0aGUgcmUtc2lnbmFsaW5n IGNhbiBpbXBhY3QgdGhlIGRhdGEgcGxhbmUuDQo+PiANCj4+ICAgICAgICogIEl0IE1VU1Qgc3Vw cG9ydCB0aGUgc2V0dXAsIG1vZGlmaWNhdGlvbiwgYW5kIHJlbGVhc2Ugb2YgTVBMUy1UUA0KPj4g ICAgICAgICAgY29ubmVjdGlvbnMgYW5kIHByb3RlY3Rpb24gY29ubmVjdGlvbnMuDQo+PiANCj4+ ICAgICAgICogIEl0IE1VU1Qgc3VwcG9ydCBtZWNoYW5pc21zIHRvIHByb3ZpZGUgdHJhZmZpYyBl bmdpbmVlcmluZywNCj4+ICAgICAgICAgIGNvbnN0cmFpbnQtYmFzZWQgcm91dGluZyBhbmQgZXhw bGljaXQgcGF0aCBjb250cm9sLg0KPj4gDQo+PiAgICAgICAqICBJdCBNVVNUIHByb3ZpZGUgbWVj aGFuaXNtcyB0byBhZGRyZXNzIFFvUyBhbmQgcGVyZm9ybWFuY2UNCj4+ICAgICAgICAgIHJlcXVp cmVtZW50cyAoc3VjaCBhcyB0aHJvdWdocHV0LCBkZWxheSwgcGFja2V0IGxvc3MsIGV0Yy4pDQo+ PiANCj4+IA0KPj4gDQo+PiBOaXZlbi1KZW5raW5zLCBldCBhbC4gICAgRXhwaXJlcyBKYW51YXJ5 IDIsIDIwMDkgICAgICAgICAgICAgICAgW1BhZ2UgOF0NCj4+IAwNCj4+IEludGVybmV0LURyYWZ0 ICAgICAgICAgICAgTVBMUy1UUCBSZXF1aXJlbWVudHMgICAgICAgICAgICAgICAgIEp1bHkgMjAw OA0KPj4gDQo+PiANCj4+ICAgICAgICAgIHdoaWxlIHV0aWxpemluZyBuZXR3b3JrIHJlc291cmNl cyBlZmZpY2llbnRseSBhbmQgcmVsaWFibHkuDQo+PiANCj4+ICAgIG8gIE1QTFMtVFAgU0hPVUxE IHN1cHBvcnQgb2ZmLXBhdGggKG91dC1vZi1iYW5kKSBjb250cm9sIGFuZA0KPj4gICAgICAgbWFu YWdlbWVudCBwbGFuZXMuDQo+PiANCj4+ICAgIG8gIFRoZSBNUExTLVRQIGNvbnRyb2wgcGxhbmUg TVVTVCBiZSBpbmRlcGVuZGVudCBvZiBhbnkgcGFydGljdWxhcg0KPj4gICAgICAgY2xpZW50IG9y IHNlcnZlciBsYXllciBjb250cm9sIHBsYW5lLg0KPj4gDQo+PiAgICBvICBUaGUgY29udHJvbCBw bGFuZSBTSE9VTEQgZmFjaWxpdGF0ZSB0aGUgaW1wbGVtZW50YXRpb24gb2YgdGhlDQo+PiAgICAg ICBzZXJ2aWNlIGJ5IHByb3ZpZGluZyBlbmQtdG8tZW5kIHNlYW1sZXNzIGNvbm5lY3Rpdml0eSBh bmQgc2VydmljZQ0KPj4gICAgICAgYXNzdXJhbmNlLg0KPj4gDQo+PiAgICBvICBUaGUgTVBMUy1U UCBjb250cm9sIHBsYW5lIE1VU1Qgc3VwcG9ydCBlc3RhYmxpc2hpbmcgYWxsIHRoZQ0KPj4gICAg ICAgY29ubmVjdGl2aXR5IHBhdHRlcm5zIGRlZmluZWQgZm9yIHRoZSBNUExTLVRQIHRyYW5zcG9y dCBwbGFuZQ0KPj4gICAgICAgKGUuZy4sIHVuaS1kaXJlY3Rpb25hbCBhbmQgYmlkaXJlY3Rpb25h bCBQMlAsIHVuaS1kaXJlY3Rpb25hbA0KPj4gICAgICAgUDJNUCwgZXRjLikgaW5jbHVkaW5nIGNv bmZpZ3VyYXRpb24gb2YgcHJvdGVjdGlvbiBmdW5jdGlvbnMgYW5kDQo+PiAgICAgICBhbnkgYXNz b2NpYXRlZCBtYWludGVuYW5jZSBmdW5jdGlvbnMuDQo+PiANCj4+ICAgIG8gIFRoZSBNUExTLVRQ IGNvbnRyb2wgcGFuZSBtdXN0IHN1cHBvcnQgdGhlIGNvbmZpZ3VyYXRpb24gYW5kDQo+PiAgICAg ICBtb2RpZmljYXRpb24gb2YgT0FNIG1haW50ZW5hbmNlIHBvaW50cyBhcyB3ZWxsIGFzIHRoZSBh Y3RpdmF0aW9uLw0KPj4gICAgICAgZGVhY3RpdmF0aW9uIG9mIE9BTSB3aGVuIHRoZSBjb25uZWN0 aW9uIGlzIGVzdGFibGlzaGVkIG9yDQo+PiAgICAgICBtb2RpZmllZC4NCj4+IA0KPj4gICAgbyAg QW4gTVBMUy1UUCBjb250cm9sIHBsYW5lIE1VU1Qgc3VwcG9ydCB0b3BvbG9neSBoaWRpbmcgYW5k IGFkZHJlc3MNCj4+ICAgICAgIGluZGVwZW5kZW5jZSBiZXR3ZWVuIGRvbWFpbnMuDQo+PiANCj4+ ICAgIG8gIEF0IHRoZSBib3VuZGFyeSBvZiBhIGRvbWFpbiBhbiBNUExTLVRQIGNvbnRyb2wgcGxh bmUgTVVTVCBzdXBwb3J0DQo+PiAgICAgICB1bmlxdWUgbmFtZXMgb3IgYWRkcmVzc2VzIGlkZW50 aWZ5aW5nIGJvdW5kYXJ5IHBvaW50cyB0byBiZQ0KPj4gICAgICAgaW50ZXJjb25uZWN0ZWQuDQo+ PiANCj4+ICAgIG8gIEF0IHRoZSBib3VuZGFyeSBvZiBhIGRvbWFpbiBhbiBNUExTLVRQIGNvbnRy b2wgcGxhbmUgbXVzdCBzdXBwb3J0DQo+PiAgICAgICBncm91cCBuYW1lcyBvciBhZGRyZXNzZXMg aWRlbnRpZnlpbmcgc2V0cyBvZiBib3VuZGFyeSBwb2ludHMgdG8gYmUNCj4+ICAgICAgIGludGVy Y29ubmVjdGVkLg0KPj4gDQo+PiAgICBvICBNUExTLVRQIGxheWVyIG5ldHdvcmsgYWNjZXNzIHBv aW50cyAob3IgY29ubmVjdGlvbiBwb2ludHMgdGhhdA0KPj4gICAgICAgcHJveHkgZm9yIGFjY2Vz cyBwb2ludHMpIFNIT1VMRCBiZSBhYmxlIHRvIGJlIGFzc2lnbmVkIG5hbWVzIHdoaWNoDQo+PiAg ICAgICBhcmUgYXZhaWxhYmxlIHRvIGNsaWVudHMgdG8gaWRlbnRpZnkgZW5kcG9pbnRzIGluIGNh bGwgb3INCj4+ICAgICAgIGNvbm5lY3Rpb24gcmVxdWVzdHMuDQo+PiANCj4+ICAgIG8gIEFuIE1Q TFMtVFAgY29udHJvbCBwbGFuZSBNVVNUIHN1cHBvcnQgdHJhbnNsYXRpb24gYmV0d2Vlbg0KPj4g ICAgICAgZXh0ZXJuYWxseSB2aXNpYmxlIGVuZHBvaW50IG5hbWVzIGFuZCBpbnRlcm5hbCBuZXR3 b3JrIGFkZHJlc3Nlcy4NCj4+IA0KPj4gICAgbyAgQW4gTVBMUy1UUCBjb250cm9sIHBsYW5lIE1V U1Qgc3VwcG9ydCBjb25zdHJhaW50LWJhc2VkIHJvdXRlDQo+PiAgICAgICBjYWxjdWxhdGlvbi4N Cj4+IA0KPj4gICAgbyAgQW4gTVBMUy1UUCBjb250cm9sIHBsYW5lIE1VU1Qgc3VwcG9ydCBwcm92 aXNpb25pbmcgYW5kIGFwcGxpY2F0aW9uDQo+PiAgICAgICBvZiByb3V0aW5nIGNvbnN0cmFpbnQg cG9saWNpZXMuDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IE5pdmVuLUplbmtpbnMsIGV0IGFsLiAg ICBFeHBpcmVzIEphbnVhcnkgMiwgMjAwOSAgICAgICAgICAgICAgICBbUGFnZSA5XQ0KPj4gDA0K Pj4gSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICBNUExTLVRQIFJlcXVpcmVtZW50cyAgICAgICAg ICAgICAgICAgSnVseSAyMDA4DQo+PiANCj4+IA0KPj4gICAgbyAgQW4gTVBMUy1UUCBjb250cm9s IHBsYW5lIE1VU1Qgc3VwcG9ydCBwcmUtcHJvdmlzaW9uZWQgY29ubmVjdGlvbg0KPj4gICAgICAg cHJvdGVjdGlvbi4NCj4+IA0KPj4gICAgSW4gc29tZSBzaXR1YXRpb25zIGl0IGlzIGltcHJhY3Rp Y2FsIHRvIGV4cGVjdCBhY2NlcHRhYmxlIHJlY292ZXJ5DQo+PiAgICBwZXJmb3JtYW5jZSB0byBi ZSBhY2hpZXZlZCB1c2luZyBkeW5hbWljIHJlY2FsY3VsYXRpb24gb2YgY29ubmVjdGlvbg0KPj4g ICAgcm91dGVzLiAgRm9yIHRoaXMgcmVhc29uLCBpdCBpcyBuZWNlc3NhcnkgdG8gYWxsb3cgZm9y IHByZS1wbGFubmluZw0KPj4gICAgb2YgcHJvdGVjdGlvbiByb3V0ZXMgZm9yIHNlbGVjdGVkIGNv bm5lY3Rpb25zLg0KPj4gDQo+PiAgICBvICBUaGUgTVBMUy1UUCBjb250cm9sIHBsYW5lIE1VU1Qg c3VwcG9ydCBmYXN0IHJlc3RvcmF0aW9uLg0KPj4gDQo+PiBUT006IERlZmluZSB3aGF0ICJmYXN0 IiBtZWFucz8NCj4+IA0KPj4gICAgbyAgQW4gTVBMUy1UUCBjb250cm9sIHBsYW5lIE1VU1Qgc2Nh bGUgZ3JhY2VmdWxseSB0byBzdXBwb3J0IGEgbGFyZ2UNCj4+ICAgICAgIG51bWJlciBvZiBjb25u ZWN0aW9ucy4NCj4+IA0KPj4gVE9NOiBEZWZpbmUgImxhcmdlIiBhbmQgInNjYWxlIiBoZXJlPw0K Pj4gDQo+PiAgICBbSW5jbHVkZSBzb21lIG51bWJlcnMgdG8gaW5kaWNhdGUgaG93IGxhcmdlIHRo ZSBDUCBpcyBleHBlY3RlZCB0bw0KPj4gICAgc2NhbGUgdG8/XQ0KPj4gDQo+PiAgICBvICBBbiBN UExTLVRQIGNvbnRyb2wgcGxhbmUgTVVTVCBjbGVhcmx5IGRpc3Rpbmd1aXNoIHJlc291cmNlcw0K Pj4gICAgICAgYmVsb25naW5nIHRvIHRoZSBNUExTLVRQIGxheWVyIG5ldHdvcmsgZnJvbSB0aG9z ZSBpbiBvdGhlciBsYXllcg0KPj4gICAgICAgbmV0d29ya3MgdGhhdCBtYXkgYWxzbyBiZSB1bmRl ciBjb250cm9sIHBsYW5lIGNvbnRyb2wuDQo+PiANCj4+IFRPTTogRG8geW91IG1lYW4gdW5kZXIg dGhlIHNhbWUgY29udHJvbCBwbGFuZSBvciBhIGRpZmZlcmVudCBvbmUgKG9yDQo+PiBib3RoKT8N Cj4+IA0KPj4gICAgbyAgQW4gTVBMUy1UUCBjb250cm9sIHBsYW5lIE1VU1Qgc3VwcG9ydCB0aGUg aW5kZXBlbmRlbnQNCj4+ICAgICAgIGlkZW50aWZpY2F0aW9uIG9mIGxvZ2ljYWxseSBkaXN0aW5j dCBjb250cm9sIHBsYW5lIGVsZW1lbnRzLg0KPj4gDQo+PiAgICBvICBJdCBNVVNUIGJlIHBvc3Np YmxlIHRvIGlkZW50aWZ5IGFuZCBwcm92aXNpb24gdGhlc2UgZWxlbWVudHMNCj4+ICAgICAgIGlu ZGVwZW5kZW50bHksIGluIG9yZGVyIHRvIHJlb3JnYW5pemUgdGhlIGNvbnRyb2wgcGxhbmUgY29t cG9uZW50cw0KPj4gICAgICAgd2l0aG91dCBpbXBhY3RpbmcgdGhlIGRhdGEgcGxhbmUgc2Vydmlj ZXMgYW5kIHZpY2UtdmVyc2EuDQo+PiANCj4+ICAgIEFyY2hpdGVjdHVyYWxseSBkaXN0aW5jdCBl bGVtZW50cyBpbiBhIGNvbnRyb2wgcGxhbmUgaW5jbHVkZTogbm9kZXMNCj4+ICAgIGFuZCBsaW5r cywgY29udHJvbCBwbGFuZSBmdW5jdGlvbmFsIGNvbXBvbmVudHMsIHByb3RvY29sIGNvbnRyb2xs ZXJzLA0KPj4gICAgZXRjLg0KPj4gDQo+PiAgICBvICBBbiBNUExTLVRQIGNvbnRyb2wgcGxhbmUg U0hPVUxEIHByb3ZpZGUgYSBjb21tb24gY29udHJvbCBtZWNoYW5pc20NCj4+ICAgICAgIGZvciBh cmNoaXRlY3R1cmFsbHkgc2ltaWxhciBvcGVyYXRpb25zLg0KPj4gDQo+PiAgICBvICBBbiBNUExT LVRQIGNvbnRyb2wgcGxhbmUgTVVTVCBzdXBwb3J0IG1lY2hhbmlzbXMgZm9yIHBhcnRpdGlvbmlu Zw0KPj4gICAgICAgdGhlIG5ldHdvcmsgdW5kZXIgY29udHJvbCBpbnRvIHNlcGFyYXRlIHBlZXIg b3IgaGllcmFyY2hpY2FsDQo+PiAgICAgICBjb250cm9sIGRvbWFpbnMuDQo+PiANCj4+ICAgIG8g IFRvIGVuYWJsZSB0aGUgZGVwbG95bWVudCBvZiBhIHVuaWZpZWQgY29udHJvbCBwbGFuZSBhaW1l ZCBhdA0KPj4gICAgICAgY29udHJvbGxpbmcgdGhlIHNldCBvZiB0cmFuc3BvcnQgdGVjaG5vbG9n aWVzIHVzZWQgaW4gYSB0cmFuc3BvcnQNCj4+ICAgICAgIG5ldHdvcmssIHRoZSBNUExTLVRQIGNv bnRyb2wgcGxhbmUgTVVTVCBhbHNvIGJlIGFwcGxpY2FibGUgdG8NCj4+ICAgICAgIG90aGVyIHRy YW5zcG9ydCBsYXllciBuZXR3b3JrcyBhbmQgcHJvdmlkZSBjb21tb24gb3BlcmF0aW9ucw0KPj4g ICAgICAgYWNyb3NzIG11bHRpcGxlIGxheWVycy4gIEluIG9yZGVyIHRvIG1haW50YWluIGluZGVw ZW5kZW5jZSBiZXR3ZWVuDQo+PiAgICAgICBNUExTLVRQIGFuZCBpdHMgcmVzcGVjdGl2ZSBjbGll bnQgYW5kIHNlcnZlciBsYXllciBuZXR3b3JrDQo+PiAgICAgICBzZXBhcmF0ZSBjb250cm9sIHBs YW5lIGluc3RhbmNlcyBTSE9VTEQgYmUgdXNlZCB0byBjb250cm9sIGEgc2V0DQo+PiAgICAgICBv ZiB0cmFuc3BvcnQgbGF5ZXIgbmV0d29ya3MuDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4g Tml2ZW4tSmVua2lucywgZXQgYWwuICAgIEV4cGlyZXMgSmFudWFyeSAyLCAyMDA5ICAgICAgICAg ICAgICAgW1BhZ2UgMTBdDQo+PiAMDQo+PiBJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIE1QTFMt VFAgUmVxdWlyZW1lbnRzICAgICAgICAgICAgICAgICBKdWx5IDIwMDgNCj4+IA0KPj4gDQo+PiAg ICBvICBNUExTLVRQIFNIT1VMRCBkZXRlY3QgYW5kIHJlY292ZXIgZnJvbSBjb250cm9sIHBsYW5l IGZhaWx1cmVzIGFuZA0KPj4gICAgICAgZGVncmFkYXRpb25zIHVzaW5nIGdyYWNlZnVsIG9wZXJh dGlvbnMuDQo+PiANCj4+IDIuNS4gIE5ldHdvcmsgTWFuYWdlbWVudCAoTk0pIHJlcXVpcmVtZW50 cw0KPj4gDQo+PiAgICBvICBNUExTLVRQIE1VU1Qgb3BlcmF0ZSB1bmRlciBhIGNvbW1vbiBvcGVy YXRpb24sIGNvbnRyb2wgYW5kDQo+PiAgICAgICBtYW5hZ2VtZW50IHBhcmFkaWdtIHdpdGggcmVz cGVjdCB0byBvdGhlciB0cmFuc3BvcnQgdGVjaG5vbG9naWVzDQo+PiAgICAgICAoZS5nLiAgU0RI LCBPVE4gb3IgV0RNKS4NCj4+IA0KPj4gICAgbyAgQW4gTVBMUy1UUCBuZXR3b3JrIE1VU1QgYmUg YWJsZSB0byBiZSBvcGVyYXRlZCB3aXRoIGEgY2VudHJhbGl6ZWQNCj4+ICAgICAgIE5NUyBzeXN0 ZW0uDQo+PiANCj4+ICAgIG8gIEFuIE1QTFMtVFAgbmV0d29yayBTSE9VTEQgYmUgYWJsZSB0byBi ZSBvcGVyYXRlZCBieSBhIGNlbnRyYWxpemVkDQo+PiAgICAgICBOTVMgc3lzdGVtIHdpdGggdGhl IHN1cHBvcnQgb2YgYSBkaXN0cmlidXRlZCBjb250cm9sIHBsYW5lLg0KPj4gDQo+PiBUT006IEkg ZG9uJ3Qga25vdyB3aGF0IHRoaXMgbWVhbnMgb3IgdGhlIG9uZSBhYm92ZSBpdCwgb3IgaG93IHRo aXMNCj4+IHJlcXVpcmVtZW50IHdvdWxkIHRyYW5zbGF0ZSBpbnRvIGFueXRoaW5nIHRhbmdpYmxl IGluIHRoZSBNUExTLVRQDQo+PiBwcm90b2NvbCBkZXNpZ25zLiAgSSBzdWdnZXN0IGl0IGJlIHJl bW92ZWQuDQo+PiANCj4+ICAgIG8gIFRoZSBNUExTLVRQIG1hbmFnZW1lbnQgcGxhbmUgTVVTVCBO T1QgZGVwZW5kIG9uIGEgc3BlY2lmaWMgY2xpZW50DQo+PiAgICAgICBsYXllciBtYW5hZ2VtZW50 IHBsYW5lLg0KPj4gDQo+PiBUT006IFRoaXMgaXMgYSBub24tc2VxdWl0dXIgaWYgeW91IGFzayBt ZTsgcGxlYXNlIHN0cmlrZSBpdC4NCj4+IA0KPj4gICAgbyAgVGhlIE1QTFMtVFAgbWFuYWdlbWVu dCBwbGFuZSBNVVNUIHN1cHBvcnQgdGhlIGNvbmZpZ3VyYXRpb24gYW5kDQo+PiAgICAgICBtb2Rp ZmljYXRpb24gb2YgT0FNIG1haW50ZW5hbmNlIHBvaW50cyBhcyB3ZWxsIGFzIHRoZSBhY3RpdmF0 aW9uLw0KPj4gICAgICAgZGVhY3RpdmF0aW9uIG9mIE9BTSB3aGVuIHRoZSBjb25uZWN0aW9uIGlz IGVzdGFibGlzaGVkIG9yDQo+PiAgICAgICBtb2RpZmllZC4NCj4+IA0KPj4gICAgRm9yIHRoZSBj b21wbGV0ZSBzZXQgb2YgcmVxdWlyZW1lbnRzIHJlbGF0ZWQgdG8gTk0gZnVuY3Rpb25hbGl0eSBm b3INCj4+ICAgIE1QTFMtVFAsIHNlZSB0aGUgTVBMUy1UUCBOTSByZXF1aXJlbWVudHMgZG9jdW1l bnQgW1JFRl0uDQo+PiANCj4+IDIuNi4gIE9BTSByZXF1aXJlbWVudHMNCj4+IA0KPj4gICAgbyAg TVBMUy1UUCBTSE9VTEQgcHJvdmlkZSBhIGNvbXByZWhlbnNpdmUgc2V0IG9mIGNhcGFiaWxpdGll cyAodGhhdA0KPj4gICAgICAgYXJlIGluZGVwZW5kZW50IG9mIGFuZCBhZ25vc3RpYyB0byB0aGUg dHJhbnNtaXR0ZWQgY2xpZW50DQo+PiAgICAgICBzZXJ2aWNlcykgdG8gc3VwcG9ydCBmYXVsdCBt YW5hZ2VtZW50LCBwZXJmb3JtYW5jZSBtb25pdG9yaW5nIChvZg0KPj4gICAgICAgdGhlIE1QTFMt VFAgbmV0d29yayBhbmQgdGhlIHNlcnZpY2VzKSwgcHJvdGVjdGlvbiBzd2l0Y2hpbmcsIGZhdWx0 DQo+PiAgICAgICBsb2NhbGl6YXRpb24sIHNpZ25hbCBxdWFsaXR5IG1lYXN1cmVtZW50LCBldGMu DQo+PiANCj4+ICAgIG8gIEEgbWVjaGFuaXNtIFNIT1VMRCBiZSBzdXBwb3J0ZWQgdG8gZGV0ZWN0 LCBkaWFnbm9zZSBhbmQgZW5hYmxlDQo+PiAgICAgICByZWNvdmVyeSBmcm9tIGZhY2lsaXR5IGFu ZCBlcXVpcG1lbnQgZmFpbHVyZXMgYW5kIHBlcmZvcm1hbmNlDQo+PiAgICAgICBkZWdyYWRhdGlv bnMgYWNjb3JkaW5nIHRvIHRoZSByZXF1aXJlbWVudHMgb2YgdGhlIHNlcnZpY2UuDQo+PiANCj4+ ICAgIG8gIE1QTFMtVFAgT0FNIE1VU1QgYmUgYWJsZSB0byBvcGVyYXRlIHdpdGhvdXQgSVAgZnVu Y3Rpb25hbGl0eSBhbmQNCj4+ICAgICAgIHdpdGhvdXQgcmVseWluZyBvbiBjb250cm9sIGFuZC9v ciBtYW5hZ2VtZW50IHBsYW5lcy4NCj4+IA0KPj4gICAgRm9yIHRoZSBjb21wbGV0ZSBzZXQgb2Yg cmVxdWlyZW1lbnRzIHJlbGF0ZWQgdG8gT0FNIGZ1bmN0aW9uYWxpdHkgZm9yDQo+PiAgICBNUExT LVRQLCBzZWUgdGhlIE1QTFMtVFAgT0FNIHJlcXVpcmVtZW50cyBkb2N1bWVudCBbUkVGXS4NCj4+ IA0KPj4gVE9NOiBJIHN1Z2dlc3QgeW91IGp1c3QgcmVtb3ZlIHRoZXNlIHR3byBzZWN0aW9ucyBh bmQgcmVmZXIgdG8gdGhlDQo+PiBPQU0vTWFuYWdlbWV0biBkb2N1bWVudHMuDQo+PiANCj4+IDIu Ny4gIE5ldHdvcmsgcGVyZm9ybWFuY2UgbWFuYWdlbWVudCAoUE0pIHJlcXVpcmVtZW50cw0KPj4g DQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gTml2ZW4tSmVua2lucywgZXQgYWwuICAgIEV4 cGlyZXMgSmFudWFyeSAyLCAyMDA5ICAgICAgICAgICAgICAgW1BhZ2UgMTFdDQo+PiAMDQo+PiBJ bnRlcm5ldC1EcmFmdCAgICAgICAgICAgIE1QTFMtVFAgUmVxdWlyZW1lbnRzICAgICAgICAgICAg ICAgICBKdWx5IDIwMDgNCj4+IA0KPj4gDQo+PiAgICBvICBNUExTLVRQIE1VU1Qgc3VwcG9ydCB0 cmFmZmljLWVuZ2luZWVyaW5nIGNhcGFiaWxpdGllcyB3aXRoDQo+PiAgICAgICB0cmFmZmljLSBh bmQvb3IgcmVzb3VyY2Utb3JpZW50ZWQgcGVyZm9ybWFuY2Ugb2JqZWN0aXZlcy4NCj4+IA0KPj4g VE9NOiBXaGF0IGFyZSBwZXJmb3JtYW5jZSBvYmplY3RpdmVzPyAgRG8geW91IG1lYW4gdHJhZmZp YyBwcm9maWxlcyBzdWNoDQo+PiBhcyBRb1MvYmFuZHdpZHRoPw0KPj4gDQo+PiAgICBvICBNUExT LVRQIE1VU1Qgc3VwcG9ydCBhIG1ldGhvZCB0byBvZmZlciBwYWNrZXQgbG9zcyBvYmplY3RpdmVz DQo+PiAgICAgICBjb21wYXJhYmxlIHRvIHRob3NlIGluIFRETSB0cmFuc3BvcnQgbmV0d29ya3Mg KG9ubHkgZHVlIHRvIGJpdA0KPj4gICAgICAgZXJyb3JzKS4NCj4+IA0KPj4gICAgRm9yIHRoZSBj b21wbGV0ZSBzZXQgb2YgcmVxdWlyZW1lbnRzIHJlbGF0ZWQgdG8gUE0gZnVuY3Rpb25hbGl0eSBm b3INCj4+ICAgIE1QTFMtVFAsIHNlZSB0aGUgTVBMUy1UUCBPQU0gcmVxdWlyZW1lbnRzIGRvY3Vt ZW50IFtSRUZdLg0KPj4gDQo+PiBUT006IEFnYWluLCBJIHN1Z2dlc3QgeW91IHB1bnQgb24gdGhp cyBlbnRpcmUgc2VjdGlvbiBhbmQgbW92ZSBpdCB0byB0aGUNCj4+IE9BTSBkb2MuDQo+PiANCj4+ IDIuOC4gIFByb3RlY3Rpb24gJiBTdXJ2aXZhYmlsaXR5IHJlcXVpcmVtZW50cw0KPj4gDQo+PiAg ICBOZXR3b3JrIHN1cnZpdmFiaWxpdHkgcGxheXMgYSBjcml0aWNhbCBmYWN0b3IgaW4gdGhlIGRl bGl2ZXJ5IG9mDQo+PiAgICByZWxpYWJsZSBzZXJ2aWNlcy4gIE5ldHdvcmsgYXZhaWxhYmlsaXR5 IGlzIGEgc2lnbmlmaWNhbnQgY29udHJpYnV0b3INCj4+ICAgIHRvIHJldmVudWUgYW5kIHByb2Zp dC4gIFNlcnZpY2UgZ3VhcmFudGVlcyBpbiB0aGUgZm9ybSBvZiBTTEFzDQo+PiAgICByZXF1aXJl IGEgcmVzaWxpZW50IG5ldHdvcmsgdGhhdCByYXBpZGx5IGRldGVjdHMgZmFjaWxpdHkgb3Igbm9k ZQ0KPj4gICAgZmFpbHVyZXMgYW5kIHJlc3RvcmVzIG5ldHdvcmsgb3BlcmF0aW9uIGluIGFjY29y ZGFuY2Ugd2l0aCB0aGUgdGVybXMNCj4+ICAgIG9mIHRoZSBTTEEuDQo+PiANCj4+ICAgIFRoZSBy ZXF1aXJlbWVudHMgaW4gdGhpcyBzZWN0aW9uIHVzZSBvZiB0aGUgcmVjb3ZlcnkgdGVybWlub2xv Z3kNCj4+ICAgIGRlZmluZWQgaW4gUkZDIDQ0MjdbUkZDNDQyN10uDQo+PiANCj4+ICAgIG8gIE1Q TFMtVFAgU0hPVUxEIHN1cHBvcnQgdHJhbnNwb3J0IG5ldHdvcmsgc3R5bGUgcHJvdGVjdGlvbg0K Pj4gDQo+PiBUT006IEkgd291bGQgbWFrZSB0aGlzIGEgTVVTVC4NCj4+IA0KPj4gICAgICAgc3dp dGNoaW5nIG1lY2hhbmlzbXMgKHRhbmRlbSBuZXR3b3JrIGNvbm5lY3Rpb24gcHJvdGVjdGlvbiwg TFNQDQo+PiAgICAgICBwcm90ZWN0aW9uIGFuZCBQVyBwcm90ZWN0aW9uKSB0byBwcm92aWRlIHRo ZSBzdWItNTBtcyByZWNvdmVyeQ0KPj4gICAgICAgdGltZSByZXF1aXJlZCB0byBtYWludGFpbiBj dXN0b21lciB0cmFuc3BhcmVuY3ksIGV2ZW4gd2hlbg0KPj4gICAgICAgdGhvdXNhbmRzIG9mIHNl cnZpY2VzIGFyZSBzaW11bHRhbmVvdXNseSBhZmZlY3RlZCBieSBhIGZhaWx1cmUuDQo+PiAgICAg ICBbSXMgc3ViLTUwbXMgcmVhbGx5IGEgcmVxdWlyZW1lbnQsIGRvIHdlIHdhbnQgdG8gY2xhcmlm eSB0aGlzDQo+PiAgICAgICBmdXJ0aGVyIC0gaXMgaXQgc3ViLTUwbXMgZW5kIHRvIGVuZCwgb3Ig cGVyIGxpbms/XQ0KPj4gDQo+PiAgICBvDQo+PiANCj4+ICAgICAgICogIE1QTFMtVFAgcmVjb3Zl cnkgbWVjaGFuaXNtcyBTSE9VTEQgYmUgYXBwbGljYWJsZSBhdCB2YXJpb3VzDQo+PiAgICAgICAg ICBsZXZlbHMgdGhyb3VnaG91dCB0aGUgbmV0d29yaywgU1BBTiwgdGFuZGVtIGNvbm5lY3Rpb24g YW5kIGVuZC0NCj4+ICAgICAgICAgIHRvLWVuZC4gDQo+PiANCj4+IFRPTTogVGhpcyBzZW50ZW5j ZSBkb2Vzbid0IHBhcnNlLiBQbGVhc2UgcmUtd3JpdGUuDQo+PiANCj4+ICBBbnkgcmVjb3Zlcnkg bWVjaGFuaXNtIHVzZWQgaW4gYSB0YW5kZW0gY29ubmVjdGlvbg0KPj4gICAgICAgICAgTVVTVCBi ZSBpbmRlcGVuZGVudCBvZiBvdGhlciB0YW5kZW0gY29ubmVjdGlvbnMuDQo+PiANCj4+ICAgICAg ICogIE1QTFMtVFAgU0hPVUxEIHN1cHBvcnQgbWVjaGFuaXNtcyB0aGF0IGtlZXAgdHJhZmZpYyBm bG93aW5nDQo+PiAgICAgICAgICB3aGlsZSB0aGUgbmV0d29yayByZWNvdmVycyBmcm9tIGZhaWx1 cmVzLg0KPj4gDQo+PiBUT006IEkgd291bGQgc2F5IHRoaXMgaXMgYSBNVVNULg0KPj4gDQo+PiAg ICAgICAqICBNUExTLVRQIFNIT1VMRCBzdXBwb3J0IG5ldHdvcmsgcmVzdG9yYXRpb24gbWVjaGFu aXNtcw0KPj4gICAgICAgICAgY29udHJvbGxlZCBieSBhIGRpc3RyaWJ1dGVkIGNvbnRyb2wgcGxh bmUgYW5kL29yIGJ5IGENCj4+ICAgICAgICAgIG1hbmFnZW1lbnQgcGxhbmUgYmFzZWQuDQo+PiAN Cj4+IFRPTTogSSB3b3VsZCBzYXkgdGhpcyBpcyBhIE1VU1QuDQo+PiANCj4+IA0KPj4gICAgICAg Kg0KPj4gDQo+PiAgICAgICAgICArICBUaGUgcmVzdG9yYXRpb24gcmVzb3VyY2VzIE1BWSBiZSBw cmUtcGxhbm5lZCBhbmQgc2VsZWN0ZWQgYQ0KPj4gICAgICAgICAgICAgcHJpb3JpLCBvciBjb21w dXRlZCBhZnRlciBmYWlsdXJlIG9jY3VycmVuY2UuDQo+PiANCj4+IA0KPj4gDQo+PiBOaXZlbi1K ZW5raW5zLCBldCBhbC4gICAgRXhwaXJlcyBKYW51YXJ5IDIsIDIwMDkgICAgICAgICAgICAgICBb UGFnZSAxMl0NCj4+IAwNCj4+IEludGVybmV0LURyYWZ0ICAgICAgICAgICAgTVBMUy1UUCBSZXF1 aXJlbWVudHMgICAgICAgICAgICAgICAgIEp1bHkgMjAwOA0KPj4gDQo+PiANCj4+ICAgICAgICAg ICsgIE1QTFMtVFAgTUFZIHN1cHBvcnQgc2hhcmVkLW1lc2ggcmVzdG9yYXRpb24uDQo+PiANCj4+ ICAgICAgICAgICsgIE1QTFMtVFAgU0hPVUQgc3VwcG9ydCBzb2Z0IExTUCByZXN0b3JhdGlvbi4N Cj4+IA0KPj4gICAgICAgICAgKyAgTVBMUy1UUCBNQVkgc3VwcG9ydCBoYXJkIExTUCByZXN0b3Jh dGlvbi4NCj4+IA0KPj4gICAgICAgICAgKyAgVGhlIHJlc3RvcmF0aW9uIG1lY2hhbmlzbSBNVVNU IGJlIGFwcGxpY2FibGUgdG8gYW55DQo+PiAgICAgICAgICAgICB0b3BvbG9neS4NCj4+IA0KPj4g ICAgICAgICAgKyAgUmVzdG9yYXRpb24gcHJpb3JpdHkgTUFZIGJlIGltcGxlbWVudGVkIHRvIGRl dGVybWluZSB0aGUNCj4+ICAgICAgICAgICAgIG9yZGVyIGluIHdoaWNoIGNvbm5lY3Rpb25zIHNo b3VsZCBiZSByZXN0b3JlZCAodG8gbWluaW1pemUNCj4+ICAgICAgICAgICAgIHNlcnZpY2UgcmVz dG9yYXRpb24gdGltZSBhcyB3ZWxsIGFzIHRvIGdhaW4gYWNjZXNzIHRvDQo+PiAgICAgICAgICAg ICBhdmFpbGFibGUgc3BhcmUgY2FwYWNpdHkgb24gdGhlIGJlc3QgcGF0aHMpLiAgUHJlZW1wdGlv bg0KPj4gICAgICAgICAgICAgcHJpb3JpdHkgTUFZIGJlIHVzZWQgaW4gdGhlIGV2ZW50IHRoYXQg bm90IGFsbCBjb25uZWN0aW9ucw0KPj4gICAgICAgICAgICAgY2FuIGJlIHJlc3RvcmVkLCBpbiB3 aGljaCBjYXNlIGNvbm5lY3Rpb25zIHdpdGggbG93ZXINCj4+ICAgICAgICAgICAgIHByZWVtcHRp b24gcHJpb3JpdHkgc2hvdWxkIGJlIHJlbGVhc2VkLg0KPj4gDQo+PiAgICAgICAgICArICBUaGUg cmVzdG9yYXRpb24gbWVjaGFuaXNtIFNIT1VMRCBvcGVyYXRlIGluIHN5bmVyZ3kgd2l0aA0KPj4g ICAgICAgICAgICAgb3RoZXIgdHJhbnNwb3J0IG5ldHdvcmsgdGVjaG5vbG9naWVzIChTREgsIE9U TiwgV0RNKS4NCj4+IA0KPj4gICAgICAgKiAgTVBMUy1UUCBTSE9VTEQgc3VwcG9ydCBkYXRhIHBs YW5lIGRyaXZlbiBwcm90ZWN0aW9uIG1lY2hhbmlzbXMNCj4+ICAgICAgICAgICh3aXRob3V0IGFu eSBkZXBlbmRlbmN5IG9uIGEgY29udHJvbCBwbGFuZSBvciBJUCBwcm90b2NvbHMpIHRvDQo+PiAg ICAgICAgICBlbmFibGUgZmFzdCByZWNvdmVyeSBmcm9tIGZhaWx1cmUsIGFuZCB0aGVyZWJ5IHRv IGVuaGFuY2UgdGhlDQo+PiAgICAgICAgICByZWxpYWJpbGl0eSBhbmQgYXZhaWxhYmlsaXR5IHBl cmZvcm1hbmNlIG9mIE1QTFMtVFAgbmV0d29ya3MuDQo+PiANCj4+ICAgICAgICoNCj4+IA0KPj4g ICAgICAgICAgKyAgTVBMUy1UUCBwcm90ZWN0aW9uIG1lY2hhbmlzbXMgU0hPVUxEIGJlIGFwcGxp ZWQgdG8gTFNQcyBhbmQNCj4+ICAgICAgICAgICAgIFBXcy4NCj4+IA0KPj4gICAgICAgICAgKyAg TVBMUy1UUCBNVVNUIHN1cHBvcnQgbWVjaGFuaXNtcyB0aGF0IHJhcGlkbHkgZGV0ZWN0LCBsb2Nh dGUsDQo+PiAgICAgICAgICAgICBub3RpZnkgYW5kIHJlbWVkeSBuZXR3b3JrIGZhdWx0cy4NCj4+ IA0KPj4gICAgICAgICAgKyAgTVBMUy1UUCBNVVNUIHN1cHBvcnQgMToxIGJpZGlyZWN0aW9uYWwg cHJvdGVjdGlvbiBzd2l0Y2hpbmcuDQo+PiAgICAgICAgICAgICBUaGUgcHJvdGVjdGlvbiBzdGF0 ZSBvZiBib3RoIGVuZHMgb2YgdGhlIHByb3RlY3RlZCBlbnRpdHkNCj4+ICAgICAgICAgICAgIE1V U1QgYmUgc3luY2hyb25pemVkLg0KPj4gDQo+PiAgICAgICAgICArICBNUExTLVRQIE1BWSBzdXBw b3J0IDErMSB1bmlkaXJlY3Rpb25hbCBwcm90ZWN0aW9uIHN3aXRjaGluZy4NCj4+IA0KPj4gICAg ICAgICAgKyAgTVBMUy1UUCBwcm90ZWN0aW9uIG1lY2hhbmlzbXMgTVVTVCBiZSBhcHBsaWNhYmxl IHRvIGJvdGgNCj4+ICAgICAgICAgICAgIHBvaW50LXRvLXBvaW50IGFuZCBwb2ludC10by1tdWx0 aXBvaW50IGNvbm5lY3Rpb25zLg0KPj4gDQo+PiAgICAgICAgICArICBJdCBTSE9VTEQgYmUgcG9z c2libGUgdG8gYWNoaWV2ZSBwcm90ZWN0aW9uIGF0IHRoZSBNUExTLVRQDQo+PiAgICAgICAgICAg ICBsYXllciBhcyBmYXN0IGFzIHBvc3NpYmxlIChzdWJqZWN0IHRvIHRoZSB0ZW1wb3JhbA0KPj4g ICAgICAgICAgICAgcmVzb2x1dGlvbiBvZiB0aGUgZGVmZWN0IGRldGVjdGlvbiBtZWNoYW5pc20p Lg0KPj4gDQo+PiAgICAgICAgICArICBQcm90ZWN0aW9uIHJhdGlvIE1VU1QgYmUgb2YgMTAwJSwg aS5lLiwgMTAwJSBvZiBpbXBhaXJlZA0KPj4gICAgICAgICAgICAgd29ya2luZyB0cmFmZmljIE1V U1QgYmUgcHJvdGVjdGVkIGZvciBhIGZhaWx1cmUgb24gYSBzaW5nbGUNCj4+IA0KPj4gDQo+PiAN Cj4+IE5pdmVuLUplbmtpbnMsIGV0IGFsLiAgICBFeHBpcmVzIEphbnVhcnkgMiwgMjAwOSAgICAg ICAgICAgICAgIFtQYWdlIDEzXQ0KPj4gDA0KPj4gSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICBN UExTLVRQIFJlcXVpcmVtZW50cyAgICAgICAgICAgICAgICAgSnVseSAyMDA4DQo+PiANCj4+IA0K Pj4gICAgICAgICAgICAgd29ya2luZyBMU1AuDQo+PiANCj4+ICAgICAgICAgICsgIE9wZXJhdG9y IHJlcXVlc3RzIGZvciBtYW51YWwgY29udHJvbCBvZiBwcm90ZWN0aW9uIHN3aXRjaGluZw0KPj4g ICAgICAgICAgICAgc3VjaCBhcyBjbGVhciwgbG9ja291dCBvZiBwcm90ZWN0aW9uLCBmb3JjZWQt c3dpdGNoIGFuZA0KPj4gICAgICAgICAgICAgbWFudWFsLXN3aXRjaCBjb21tYW5kcyBNVVNUIGJl IHN1cHBvcnRlZC4gIFByaW9yaXRpemVkDQo+PiAgICAgICAgICAgICBwcm90ZWN0aW9uIGJldHdl ZW4gU2lnbmFsIEZhaWwgKFNGKSwgU2lnbmFsIERlZ3JhZGF0aW9uIChTRCkNCj4+ICAgICAgICAg ICAgIGFuZCBvcGVyYXRvciBzd2l0Y2ggcmVxdWVzdHMgTVVTVCBiZSBzdXBwb3J0ZWQuDQo+PiAN Cj4+ICAgICAgICAgICsgIE1QTFMtVFAgcHJvdGVjdGlvbiBtZWNoYW5pc21zIE1VU1Qgc3VwcG9y dCByZXZlcnRpdmUgYW5kDQo+PiAgICAgICAgICAgICBub24tcmV2ZXJ0aXZlIGJlaGF2aW91ci4g byBBbiBleHRyYSB0cmFmZmljIGNhcGFiaWxpdHkNCj4+ICAgICAgICAgICAgIFNIT1VMRCBiZSBz dXBwb3J0ZWQgd2hlbiBwb3NzaWJsZS4NCj4+IA0KPj4gICAgICAgICAgKyAgTVBMUy1UUCBwcm90 ZWN0aW9uIHN3aXRjaGluZyBtZWNoYW5pc21zIE1VU1QgcHJldmVudA0KPj4gICAgICAgICAgICAg ZnJlcXVlbnQgb3BlcmF0aW9uIG9mIHRoZSBwcm90ZWN0aW9uIHN3aXRjaCBkdWUgdG8gYW4NCj4+ ICAgICAgICAgICAgIGludGVybWl0dGVudCBkZWZlY3QuDQo+PiANCj4+ICAgICAgICAgICsgIE1Q TFMtVFAgcHJvdGVjdGlvbiBtZWNoYW5pc21zIE1VU1QgZW5zdXJlIGNvLW9yZGluYXRpb24gb2YN Cj4+ICAgICAgICAgICAgIHRpbWluZyBvZiBwcm90ZWN0aW9uIHN3aXRjaGVzIGF0IG11bHRpcGxl IGxheWVycyB0byBhdm9pZA0KPj4gICAgICAgICAgICAgcmFjZXMgYW5kIHRvIGFsbG93IHRoZSBw cm90ZWN0aW9uIHN3aXRjaGluZyBtZWNoYW5pc20gb2YgdGhlDQo+PiAgICAgICAgICAgICBzZXJ2 ZXIgbGF5ZXIgdG8gZml4IHRoZSBwcm9ibGVtIGJlZm9yZSBzd2l0Y2hpbmcgYXQgdGhlDQo+PiAg ICAgICAgICAgICBNUExTLVRQIGxheWVyLg0KPj4gDQo+PiAgICAgICAgICArICBNUExTLVRQIE1B WSBzdXBwb3J0IG1lY2hhbmlzbXMgdGhhdCBhcmUgb3B0aW1pemVkIGZvcg0KPj4gICAgICAgICAg ICAgc3BlY2lmaWMgbmV0d29yayB0b3BvbG9naWVzIChSaW5nLCBNZXNoKSBpbiBvcmRlciB0byBo YW5kbGUNCj4+ICAgICAgICAgICAgIHByb3RlY3Rpb24gc3dpdGNoaW5nIGluIGEgY29zdC1lZmZp Y2llbnQgbWFubmVyLg0KPj4gDQo+PiAyLjkuICBRb1MgcmVxdWlyZW1lbnRzDQo+PiANCj4+ICAg IFNlcnZpY2UgcHJvdmlkZXJzIHJlcXVpcmUgYWR2YW5jZWQgdHJhZmZpYyBtYW5hZ2VtZW50IGNh cGFiaWxpdGllcyB0bw0KPj4gICAgZW5mb3JjZSBhbmQgZ3VhcmFudGVlIHRoZSBRb1MgcGFyYW1l dGVycyBvZiBjdXN0b21lcnMnIFNMQXMuDQo+PiANCj4+ICAgIFF1YWxpdHkgb2Ygc2VydmljZSBt ZWNoYW5pc21zIGFyZSByZXF1aXJlZCB0byBlbnN1cmU6DQo+PiANCj4+ICAgIG8gIFN1cHBvcnQg Zm9yIGRpZmZlcmVudGlhdGVkIHNlcnZpY2VzIGFuZCBkaWZmZXJlbnQgdHJhZmZpYyB0eXBlcw0K Pj4gICAgICAgd2l0aCB0cmFmZmljIGNsYXNzIHNlcGFyYXRpb24gYXNzb2NpYXRlZCB3aXRoIGRp ZmZlcmVudCB0cmFmZmljLg0KPj4gDQo+PiAgICBvICBQcmlvcml0aXphdGlvbiBvZiBjcml0aWNh bCBzZXJ2aWNlcy4NCj4+IA0KPj4gICAgbyAgRW5hYmxpbmcgdGhlIHByb3Zpc2lvbmluZyBhbmQg dGhlIGd1YXJhbnRlZSBvZiBTZXJ2aWNlIExldmVsDQo+PiAgICAgICBTcGVjaWZpY2F0aW9ucyAo U0xTKSwgd2l0aCBzdXBwb3J0IGZvciBoYXJkIGFuZCByZWxhdGl2ZSBlbmQtdG8tDQo+PiAgICAg ICBlbmQgQlcgZ3VhcmFudGVlZC4NCj4+IA0KPj4gICAgbyAgQ29udHJvbGxlZCBqaXR0ZXIgYW5k IGRlbGF5Lg0KPj4gDQo+PiAgICBvICBHdWFyYW50ZWUgb2YgZmFpciBhY2Nlc3MgdG8gc2hhcmVk IHJlc291cmNlcyBpbiBhbiBNUExTLVRQDQo+PiAgICAgICBuZXR3b3JrLg0KPj4gDQo+PiANCj4+ IA0KPj4gDQo+PiANCj4+IE5pdmVuLUplbmtpbnMsIGV0IGFsLiAgICBFeHBpcmVzIEphbnVhcnkg MiwgMjAwOSAgICAgICAgICAgICAgIFtQYWdlIDE0XQ0KPj4gDA0KPj4gSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgICBNUExTLVRQIFJlcXVpcmVtZW50cyAgICAgICAgICAgICAgICAgSnVseSAyMDA4 DQo+PiANCj4+IA0KPj4gICAgbyAgQWJpbGl0eSBmb3IgT0FNIGFuZCBkYXRhIHRvIHNoYXJlIHRo ZSBzYW1lIGZhdGUuDQo+PiANCj4+IFRPTTogVGhpcyBiZWxvbmdzIGluIHRoZSBPQU0gZG9jdW1l bnQuDQo+PiANCj4+IA0KPj4gICAgbyAgUmVzb3VyY2VzIGZvciBjb250cm9sIGFuZCBtYW5hZ2Vt ZW50IHBsYW5lIHBhY2tldHMgc28gdGhhdCB1c2VyDQo+PiAgICAgICBwbGFuZSB0cmFmZmljLCBy ZWdhcmRsZXNzIG9mIHRoZSBhbW91bnQsIHdpbGwgbm90IGNhdXNlIGNvbnRyb2wNCj4+ICAgICAg IGFuZCBtYW5hZ2VtZW50IGZ1bmN0aW9ucyB0byBiZWNvbWUgaW5vcGVyYXRpdmUuDQo+PiANCj4+ ICAgIFRoZSBmb2xsb3dpbmcgUW9TIHJlcXVpcmVtZW50cyBhcHBseSB0byBNUExTLVRQOg0KPj4g DQo+PiAgICBvICBNUExTLVRQIE1VU1QgYmUgYWJsZSB0byBkZWxpdmVyIHRoZSBzYW1lIGRlZ3Jl ZSBvZiBRb1MgdGhhdCBoYXMNCj4+ICAgICAgIGJlZW4gZGVsaXZlcmVkIGJ5IFNESC9TT05FVCBz eXN0ZW1zLg0KPj4gDQo+PiBUT006IFdlIGNhbiBzYXZlIG9uIGEgbG90IG9mIHRleHQgYW5kIHJl bW92ZSB0aGUgIk1QTFMtVEUgTVVTVCIgb3INCj4+ICJNUExTLVRQIFNIT1VMRCIgYml0cyBhbmQg c2ltcGx5IHNheSAiTVVTVCBYIiBvciAiU0hPVUxEIFkiLiBUaGUgTVBMUy1UUA0KPj4gYml0IGlz IGltcGxpY2l0IEkgdGhpbmsuDQo+PiANCj4+ICAgIG8gIE1QTFMtVFAgTVVTVCBzdXBwb3J0IHRy YW5zcG9ydCBiYW5kd2lkdGggYWxsb2NhdGlvbiB0byBhbnkNCj4+ICAgICAgIGdyYW51bGFyaXR5 IHdpdGhvdXQgYW55IHJlc3RyaWN0aW9ucyBiYXNlZCBvbiBhIGNpcmN1aXQtc3dpdGNoZWQNCj4+ ICAgICAgIG11bHRpcGxleGluZyBoaWVyYXJjaHkuICBUaGlzIGF0dHJpYnV0ZSB3aWxsIHByb3Zp ZGUgc2VydmljZQ0KPj4gICAgICAgcHJvdmlkZXJzIHdpdGggdGhlIGNhcGFiaWxpdHkgdG8gcm91 dGUgbW9yZSBjdXN0b21lciBzZXJ2aWNlDQo+PiAgICAgICBkZW1hbmRzIG92ZXIgdGhlIE1QTFMt VFAgbmV0d29yay4NCj4+IA0KPj4gICAgW1Nob3VsZCB3ZSByZWZlciBoZXJlIHRvIHRoZSByZXF1 aXJlbWVudHMgc3BlY2lmaWVkIGluIFJGQyAyNzAyP10NCj4+IA0KPj4gMi4xMC4gIFNlY3VyaXR5 IHJlcXVpcmVtZW50cw0KPj4gDQo+PiAgICBvICBNUExTLVRQIE1VU1QgZW5zdXJlIHRoYXQgdGhl IG5ldHdvcmsgYW5kIHNlcnZpY2VzIGFyZSBzZWN1cmVkLg0KPj4gDQo+PiAgICBvICBUcmFmZmlj IGZsb3dzIGZyb20gZGlmZmVyZW50IHVzZXJzIE1VU1QgTk9UIGJlIGludGVybWluZ2xlZCwgYnV0 DQo+PiAgICAgICBpZiB0aGlzIGRvZXMgb2NjdXIgdGhlbiB0aGlzIE1VU1QgYmUgZGV0ZWN0YWJs ZSBhbmQgdGhlDQo+PiAgICAgICBhcHByb3ByaWF0ZSBjb25zZXF1ZW50IGFjdGlvbnMgdGFrZW4u DQo+PiANCj4+ICAgIG8gIE1QTFMtVFAgTVVTVCBlbnN1cmUgdGhlIHNlcGFyYXRpb24gb2YgY3Vz dG9tZXIgKGNsaWVudCkgYW5kDQo+PiAgICAgICBwcm92aWRlciAoc2VydmVyIGFuZCBwZWVyIG5l dHdvcmspIGFkZHJlc3NpbmcgYW5kIG90aGVyDQo+PiAgICAgICBpbmZvcm1hdGlvbi4NCj4+IA0K Pj4gVE9NOiBUaGlzIHJlcXVpcmVtZW50IGlzIHN0YXRlZCBhYm92ZS4NCj4+IA0KPj4gICAgbyAg TVBMUy1UUCBNVVNUIGVuc3VyZSB0aGF0IHRoZSBjb250cm9sIGFuZCBtYW5hZ2VtZW50IHBsYW5l cyBhcyB3ZWxsDQo+PiAgICAgICBhcyBPQU0gdHJhZmZpYyBhcmUgc2VjdXJlIGZyb20gZXh0ZXJu YWwgYXR0YWNrLg0KPj4gDQo+PiAgICBvICBNUExTLVRQIE1VU1QgcHJvdmlkZSBtZWNoYW5pc21z IHRvIGVuc3VyZSB0aGF0IHRoZSBNUExTLVRQIG5ldHdvcmsNCj4+ICAgICAgIHJlbWFpbnMgc2Vj dXJlIGFuZCBzdGFibGUgdW5kZXIgc2l0dWF0aW9ucyBvZiBleHRyZW1lIHN0cmVzcy4NCj4+IA0K Pj4gICAgRXhhbXBsZXMgb2YgYXR0YWNrcyBhbmQgc2l0dWF0aW9ucyBvZiBleHRyZW1lIHN0cmVz cyBpbmNsdWRlIChidXQgYXJlDQo+PiAgICBub3QgbGltaXRlZCB0bykgY2xhc3NpY2FsIHNlY3Vy aXR5IGF0dGFja3MgKGUuZy4sIGhpamFja2luZywgcHJpdmFjeSwNCj4+ICAgIG5vbi1yZXB1ZGlh dGlvbiwgZXRjLikgYW5kIGF0dGFja3Mgb24gbmV0d29yayBhdmFpbGFiaWxpdHkgKGUuZy4sDQo+ PiAgICBkZW5pYWwgb2Ygc2VydmljZSAoRG9TKSBhdHRhY2tzKS4NCj4+IA0KPj4gDQo+PiAzLiAg SUFOQSBDb25zaWRlcmF0aW9ucw0KPj4gDQo+PiAgICBUaGlzIGRvY3VtZW50IG1ha2VzIG5vIHJl cXVlc3Qgb2YgSUFOQS4NCj4+IA0KPj4gICAgTm90ZSB0byBSRkMgRWRpdG9yOiB0aGlzIHNlY3Rp b24gbWF5IGJlIHJlbW92ZWQgb24gcHVibGljYXRpb24gYXMgYW4NCj4+IA0KPj4gDQo+PiANCj4+ IE5pdmVuLUplbmtpbnMsIGV0IGFsLiAgICBFeHBpcmVzIEphbnVhcnkgMiwgMjAwOSAgICAgICAg ICAgICAgIFtQYWdlIDE1XQ0KPj4gDA0KPj4gSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICBNUExT LVRQIFJlcXVpcmVtZW50cyAgICAgICAgICAgICAgICAgSnVseSAyMDA4DQo+PiANCj4+IA0KPj4g ICAgUkZDLg0KPj4gDQo+PiANCj4+IDQuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KPj4gDQo+ PiAgICBUaGlzIGRvY3VtZW50IGRvZXMgbm90IGJ5IGl0c2VsZiByYWlzZSBhbnkgcGFydGljdWxh ciBzZWN1cml0eQ0KPj4gICAgY29uc2lkZXJhdGlvbnMuDQo+PiANCj4+IA0KPj4gNS4gIEFja25v d2xlZGdlbWVudHMNCj4+IA0KPj4gICAgVGhlIGF1dGhvcnMgd2lzaCB0byB0aGFuayBOZWlsIEhh cnJpc29uIGFuZCBUb21vbm9yaSBUYWtlZGEgZm9yIHRoZWlyDQo+PiAgICByZXZpZXcgYW5kIGVu aGFuY2VtZW50cyB0byB0aGUgdGV4dC4NCj4+IA0KPj4gDQo+PiA2LiAgSW5mb3JtYXRpdmUgUmVm ZXJlbmNlcw0KPj4gDQo+PiAgICBbUkZDMjExOV0gIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZv ciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZQ0KPj4gICAgICAgICAgICAgICBSZXF1aXJlbWVudCBM ZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LCBNYXJjaCAxOTk3Lg0KPj4gDQo+PiAgICBbUkZDNDQy N10gIE1hbm5pZSwgRS4gYW5kIEQuIFBhcGFkaW1pdHJpb3UsICJSZWNvdmVyeSAoUHJvdGVjdGlv biBhbmQNCj4+ICAgICAgICAgICAgICAgUmVzdG9yYXRpb24pIFRlcm1pbm9sb2d5IGZvciBHZW5l cmFsaXplZCBNdWx0aS1Qcm90b2NvbA0KPj4gICAgICAgICAgICAgICBMYWJlbCBTd2l0Y2hpbmcg KEdNUExTKSIsIFJGQyA0NDI3LCBNYXJjaCAyMDA2Lg0KPj4gDQo+PiAgICBbSVRVLlkxNDAxLjIw MDhdDQo+PiAgICAgICAgICAgICAgIEludGVybmF0aW9uYWwgVGVsZWNvbW11bmljYXRpb25zIFVu aW9uLCAiUHJpbmNpcGxlcyBvZg0KPj4gICAgICAgICAgICAgICBpbnRlcndvcmtpbmciLCBJVFUt VCBSZWNvbW1lbmRhdGlvbiBZLjE0MDEsIEZlYnJ1YXJ5IDIwMDguDQo+PiANCj4+IA0KPj4gQXV0 aG9ycycgQWRkcmVzc2VzDQo+PiANCj4+ICAgIEJlbiBOaXZlbi1KZW5raW5zIChlZGl0b3IpDQo+ PiAgICBCVA0KPj4gICAgMjA4IENhbGxpc3RvIEhvdXNlLCBBZGFzdHJhbCBQYXJrDQo+PiAgICBJ cHN3aWNoLCBTdWZmb2xrICBJUDUgM1JFDQo+PiAgICBVSw0KPj4gDQo+PiAgICBFbWFpbDogYmVu amFtaW4ubml2ZW4tamVua2luc0BidC5jb20NCj4+IA0KPj4gDQo+PiAgICBEZWJvcmFoIEJydW5n YXJkIChlZGl0b3IpDQo+PiAgICBBVCZUDQo+PiAgICBSbS4gRDEtM0MyMiAtIDIwMCBTLiBMYXVy ZWwgQXZlLg0KPj4gICAgTWlkZGxldG93biwgTkogIDA3NzQ4DQo+PiAgICBVU0ENCj4+IA0KPj4g ICAgRW1haWw6IGRicnVuZ2FyZEBhdHQuY29tDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IE5pdmVu LUplbmtpbnMsIGV0IGFsLiAgICBFeHBpcmVzIEphbnVhcnkgMiwgMjAwOSAgICAgICAgICAgICAg IFtQYWdlIDE2XQ0KPj4gDA0KPj4gSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICBNUExTLVRQIFJl cXVpcmVtZW50cyAgICAgICAgICAgICAgICAgSnVseSAyMDA4DQo+PiANCj4+IA0KPj4gICAgTWFs Y29sbSBCZXR0cyAoZWRpdG9yKQ0KPj4gICAgTm9ydGVsIE5ldHdvcmtzDQo+PiAgICAzNTAwIENh cmxpbmcgQXZlbnVlDQo+PiAgICBPdHRhd2EsIE9udGFyaW8gIEsySCA4RTkNCj4+ICAgIENhbmFk YQ0KPj4gDQo+PiAgICBFbWFpbDogYmV0dHMwMUBub3J0ZWwuY29tDQo+PiANCj4+IA0KPj4gICAg TnVyaXQgU3ByZWNoZXINCj4+ICAgIE5va2lhIFNpZW1lbnMgTmV0d29ya3MNCj4+ICAgIDMgSGFu YWdhciBTdC4gTmV2ZSBOZSdlbWFuIEINCj4+ICAgIEhvZCBIYXNoYXJvbiwgICA0NTI0MQ0KPj4g ICAgSXNyYWVsDQo+PiANCj4+ICAgIEVtYWlsOiBudXJpdC5zcHJlY2hlckBuc24uY29tDQo+PiAN Cj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gDQo+ PiANCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4g DQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IA0K Pj4gTml2ZW4tSmVua2lucywgZXQgYWwuICAgIEV4cGlyZXMgSmFudWFyeSAyLCAyMDA5ICAgICAg ICAgICAgICAgW1BhZ2UgMTddDQo+PiAMDQo+PiBJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIE1Q TFMtVFAgUmVxdWlyZW1lbnRzICAgICAgICAgICAgICAgICBKdWx5IDIwMDgNCj4+IA0KPj4gDQo+ PiBGdWxsIENvcHlyaWdodCBTdGF0ZW1lbnQNCj4+IA0KPj4gICAgQ29weXJpZ2h0IChDKSBUaGUg SUVURiBUcnVzdCAoMjAwOCkuDQo+PiANCj4+ICAgIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0 byB0aGUgcmlnaHRzLCBsaWNlbnNlcyBhbmQgcmVzdHJpY3Rpb25zDQo+PiAgICBjb250YWluZWQg aW4gQkNQIDc4LCBhbmQgZXhjZXB0IGFzIHNldCBmb3J0aCB0aGVyZWluLCB0aGUgYXV0aG9ycw0K Pj4gICAgcmV0YWluIGFsbCB0aGVpciByaWdodHMuDQo+PiANCj4+ICAgIFRoaXMgZG9jdW1lbnQg YW5kIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGFyZSBwcm92aWRlZCBvbiBhbg0K Pj4gICAgIkFTIElTIiBiYXNpcyBhbmQgVEhFIENPTlRSSUJVVE9SLCBUSEUgT1JHQU5JWkFUSU9O IEhFL1NIRSBSRVBSRVNFTlRTDQo+PiAgICBPUiBJUyBTUE9OU09SRUQgQlkgKElGIEFOWSksIFRI RSBJTlRFUk5FVCBTT0NJRVRZLCBUSEUgSUVURiBUUlVTVCBBTkQNCj4+ICAgIFRIRSBJTlRFUk5F VCBFTkdJTkVFUklORyBUQVNLIEZPUkNFIERJU0NMQUlNIEFMTCBXQVJSQU5USUVTLCBFWFBSRVNT DQo+PiAgICBPUiBJTVBMSUVELCBJTkNMVURJTkcgQlVUIE5PVCBMSU1JVEVEIFRPIEFOWSBXQVJS QU5UWSBUSEFUIFRIRSBVU0UgT0YNCj4+ICAgIFRIRSBJTkZPUk1BVElPTiBIRVJFSU4gV0lMTCBO T1QgSU5GUklOR0UgQU5ZIFJJR0hUUyBPUiBBTlkgSU1QTElFRA0KPj4gICAgV0FSUkFOVElFUyBP RiBNRVJDSEFOVEFCSUxJVFkgT1IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuDQo+ PiANCj4+IA0KPj4gSW50ZWxsZWN0dWFsIFByb3BlcnR5DQo+PiANCj4+ICAgIFRoZSBJRVRGIHRh a2VzIG5vIHBvc2l0aW9uIHJlZ2FyZGluZyB0aGUgdmFsaWRpdHkgb3Igc2NvcGUgb2YgYW55DQo+ PiAgICBJbnRlbGxlY3R1YWwgUHJvcGVydHkgUmlnaHRzIG9yIG90aGVyIHJpZ2h0cyB0aGF0IG1p Z2h0IGJlIGNsYWltZWQgdG8NCj4+ICAgIHBlcnRhaW4gdG8gdGhlIGltcGxlbWVudGF0aW9uIG9y IHVzZSBvZiB0aGUgdGVjaG5vbG9neSBkZXNjcmliZWQgaW4NCj4+ICAgIHRoaXMgZG9jdW1lbnQg b3IgdGhlIGV4dGVudCB0byB3aGljaCBhbnkgbGljZW5zZSB1bmRlciBzdWNoIHJpZ2h0cw0KPj4g ICAgbWlnaHQgb3IgbWlnaHQgbm90IGJlIGF2YWlsYWJsZTsgbm9yIGRvZXMgaXQgcmVwcmVzZW50 IHRoYXQgaXQgaGFzDQo+PiAgICBtYWRlIGFueSBpbmRlcGVuZGVudCBlZmZvcnQgdG8gaWRlbnRp ZnkgYW55IHN1Y2ggcmlnaHRzLiAgSW5mb3JtYXRpb24NCj4+ICAgIG9uIHRoZSBwcm9jZWR1cmVz IHdpdGggcmVzcGVjdCB0byByaWdodHMgaW4gUkZDIGRvY3VtZW50cyBjYW4gYmUNCj4+ICAgIGZv dW5kIGluIEJDUCA3OCBhbmQgQkNQIDc5Lg0KPj4gDQo+PiAgICBDb3BpZXMgb2YgSVBSIGRpc2Ns b3N1cmVzIG1hZGUgdG8gdGhlIElFVEYgU2VjcmV0YXJpYXQgYW5kIGFueQ0KPj4gICAgYXNzdXJh bmNlcyBvZiBsaWNlbnNlcyB0byBiZSBtYWRlIGF2YWlsYWJsZSwgb3IgdGhlIHJlc3VsdCBvZiBh bg0KPj4gICAgYXR0ZW1wdCBtYWRlIHRvIG9idGFpbiBhIGdlbmVyYWwgbGljZW5zZSBvciBwZXJt aXNzaW9uIGZvciB0aGUgdXNlIG9mDQo+PiAgICBzdWNoIHByb3ByaWV0YXJ5IHJpZ2h0cyBieSBp bXBsZW1lbnRlcnMgb3IgdXNlcnMgb2YgdGhpcw0KPj4gICAgc3BlY2lmaWNhdGlvbiBjYW4gYmUg b2J0YWluZWQgZnJvbSB0aGUgSUVURiBvbi1saW5lIElQUiByZXBvc2l0b3J5IGF0DQo+PiAgICBo dHRwOi8vd3d3LmlldGYub3JnL2lwci4NCj4+IA0KPj4gICAgVGhlIElFVEYgaW52aXRlcyBhbnkg aW50ZXJlc3RlZCBwYXJ0eSB0byBicmluZyB0byBpdHMgYXR0ZW50aW9uIGFueQ0KPj4gICAgY29w eXJpZ2h0cywgcGF0ZW50cyBvciBwYXRlbnQgYXBwbGljYXRpb25zLCBvciBvdGhlciBwcm9wcmll dGFyeQ0KPj4gICAgcmlnaHRzIHRoYXQgbWF5IGNvdmVyIHRlY2hub2xvZ3kgdGhhdCBtYXkgYmUg cmVxdWlyZWQgdG8gaW1wbGVtZW50DQo+PiAgICB0aGlzIHN0YW5kYXJkLiAgUGxlYXNlIGFkZHJl c3MgdGhlIGluZm9ybWF0aW9uIHRvIHRoZSBJRVRGIGF0DQo+PiAgICBpZXRmLWlwckBpZXRmLm9y Zy4NCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4g DQo+PiBOaXZlbi1KZW5raW5zLCBldCBhbC4gICAgRXhwaXJlcyBKYW51YXJ5IDIsIDIwMDkgICAg ICAgICAgICAgICBbUGFnZSAxOF0NCj4+IAwNCj4+IA0KPj4gDQo+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gTXBscy1pbnRlcm9wIG1haWxpbmcg bGlzdA0KPj4gTXBscy1pbnRlcm9wQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21wbHMtaW50ZXJvcA0KPiANCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCk1wbHMtaW50ZXJvcCBtYWlsaW5nIGxpc3QNCk1w bHMtaW50ZXJvcEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tcGxzLWludGVyb3ANCg== ------_=_NextPart_001_01C8D466.62AC98CB Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMg RXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNi41Ljc2NTIuMjQiPg0KPFRJVExFPlJlOiBbTXBscy1p bnRlcm9wXSBuZXh0IE1FQUQgdGVhbSBtZWV0aW5nPC9USVRMRT4NCjwvSEVBRD4NCjxCT0RZPg0K PCEtLSBDb252ZXJ0ZWQgZnJvbSB0ZXh0L3BsYWluIGZvcm1hdCAtLT4NCg0KPFA+PEZPTlQgU0la RT0yPkkgd2FudCB0byBzZWNvbmQgQmVuIGhlcmUgLSBhIGR5bmFtaWMgY29udHJvbCBwbGFuZSBN VVNUIGJlIGF2YWlsYWJsZSBmb3IgdGhlIFNQIHRvIGNob29zZSB0byB1c2UgLSBpZiBpdCBpcyBv cHRpb25hbCBmb3IgaW1wbGVtZW50YXRpb24sIHRoZW4gaXQgd2lsbCBiZSBsZWZ0IGZvciAmcXVv dDt0aGUgbmV4dCByZWxlYXNlJnF1b3Q7LiZuYnNwOzxCUj4NCjxCUj4NCkNoZWVycyw8QlI+DQpB bmR5PEJSPg0KPEJSPg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLTxCUj4NCkZyb206IG1w bHMtaW50ZXJvcC1ib3VuY2VzQGlldGYub3JnICZsdDttcGxzLWludGVyb3AtYm91bmNlc0BpZXRm Lm9yZyZndDs8QlI+DQpUbzogVGhvbWFzIE5hZGVhdSAmbHQ7dG9tLm5hZGVhdUBidC5jb20mZ3Q7 OyBTcHJlY2hlciwgTnVyaXQgKE5TTiAtIElML0lzcmFlbCAtIE1pbmlNRCkgJmx0O251cml0LnNw cmVjaGVyQG5zbi5jb20mZ3Q7OyBMb2EgQW5kZXJzc29uICZsdDtsb2FAcGkubnUmZ3Q7OyBNRUFE IHRlYW0gJmx0O21wbHMtaW50ZXJvcEBpZXRmLm9yZyZndDs8QlI+DQpDYzogV2VpbmdhcnRlbixZ YWFjb3YgKE5TTiAtIElML0lzcmFlbCAtIE1pbmlNRCkgJmx0O3lhYWNvdi53ZWluZ2FydGVuQG5z bi5jb20mZ3Q7PEJSPg0KU2VudDogU3VuIEp1biAyMiAwODozOTo1MSAyMDA4PEJSPg0KU3ViamVj dDogUmU6IFtNcGxzLWludGVyb3BdIG5leHQgTUVBRCB0ZWFtIG1lZXRpbmc8QlI+DQo8QlI+DQpJ IHRoaW5rIHRoZSBrZXkgdGhpbmcgaXMgdGhhdCBNUExTLVRQIG11c3QgYmUgYWJsZSB0byBvcGVy YXRlIChpbmNsdWRpbmc8QlI+DQpPQU0pIGluIHRoZSBhYnNlbmNlIG9mIGEgY29udHJvbCBwbGFu ZS48QlI+DQo8QlI+DQpUaGUgb3B0aW9uIGlzIHRoZW4gZG93biB0byB3aGV0aGVyIHdlIHNheSBi b3RoIHN0YXRpYyAmYW1wOyBkeW5hbWljIGFyZSBNVVNUczxCUj4NCihmcm9tIGFuIGltcGxlbWVu dGF0aW9uIHBlcnNwZWN0aXZlKSBhbmQgdGhlIG9wZXJhdG9yIGlzIHRoZW4gZnJlZSB0byBjaG9v c2U8QlI+DQp3aGV0aGVyIHRoZXkgb3BlcmF0ZSB0aGVpciBuZXR3b3JrIHN0YXRpY2FsbHkgb3Ig ZHluYW1pY2FsbHkuJm5ic3A7IE9yIHdoZXRoZXI8QlI+DQpvbmx5IHN0YXRpYyBpcyBhIE1VU1Qg YW5kIGR5bmFtaWMgaXMgb3B0aW9uYWwgKGZvciBpbXBsZW1lbnRhdGlvbikuPEJSPg0KPEJSPg0K SSBiZWxpZXZlIHRoZSB3b3JrIGluIElUVSBpbnRlbmRlZCB0byBleHRlbmQgdG8gZHluYW1pYyBh dCBzb21lIHBvaW50IGFuZDxCUj4NCnN0YXRpYyB3YXMganVzdCBhIGZpcnN0IHN0ZXAgaW4gdGhl IFQtTVBMUyB3b3JrLjxCUj4NCjxCUj4NCkl0IG9ubHkgdGFrZSBvbmUgb3BlcmF0b3IgdG8gZGVt YW5kIGR5bmFtaWMgZnJvbSB0aGVpciB2ZW5kb3JzIGZvciBpdCB0byBiZTxCUj4NCnByZXNlbnQg aW4gZXF1aXBtZW50IGFueXdheSBldmVuIGlmIGl0IGlzIG5vdCB1c2VkIGJ5IG90aGVyIG9wZXJh dG9ycy48QlI+DQo8QlI+DQpTbyBJIHRoaW5rIHdlIGNhbiBtYWtlIGJvdGggc3RhdGljICZhbXA7 IGR5bmFtaWMgTVVTVHMgYW5kIHRoZW4gY2xhcmlmeSB0aGF0PEJSPg0Kd2hlbiBvcGVyYXRpbmcg aW4gYSBzdGF0aWMgbW9kZSBNUExTLVRQIG11c3Qgbm90IHJlbHkgb24gYW55IGR5bmFtaWM8QlI+ DQpwcm90b2NvbHMuPEJSPg0KPEJSPg0KV2UgY292ZXIgdGhpcyAoYXQgbGVhc3QgdG8gc29tZSBl eHRlbnQpIGFscmVhZHkgd2l0aCByZXF1aXJlbWVudHMgc3VjaCBhcyAmcXVvdDs8QlI+DQpTdGF0 aWMgcHJvdmlzaW9uaW5nIE1VU1Qgbm90IGRlcGVuZCBvbiByb3V0aW5nIG9yIHNpZ25hbGluZyBw cm90b2NvbHMgKGUuZy48QlI+DQpHTVBMUywgT1NQRiwgSVMtSVMsIFJTVlAsIEJHUCwgTERQIGV0 Yy4pLiZxdW90OzxCUj4NCjxCUj4NCkJlbjxCUj4NCjxCUj4NCk9uIDIyLzA2LzIwMDggMTI6NTEs ICZxdW90O1Rob21hcyBOYWRlYXUmcXVvdDsgJmx0O3RvbS5uYWRlYXVAYnQuY29tJmd0OyB3cm90 ZTo8QlI+DQo8QlI+DQomZ3Q7PEJSPg0KJmd0OzxCUj4NCiZndDs8QlI+DQomZ3Q7IE9uIDYvMjIv MDggNTo0NSBBTSwgJnF1b3Q7U3ByZWNoZXIsIE51cml0IChOU04gLSBJTC9Jc3JhZWwgLSBNaW5p TUQpJnF1b3Q7PEJSPg0KJmd0OyAmbHQ7bnVyaXQuc3ByZWNoZXJAbnNuLmNvbSZndDsgd3JvdGU6 PEJSPg0KJmd0OzxCUj4NCiZndDsmZ3Q7IEhpIFRob21hcyw8QlI+DQomZ3Q7Jmd0OyBUaGFua3Mg Zm9yIHlvdXIgY29tbWVudHMuPEJSPg0KJmd0OyZndDsgSSBzdGlsbCBuZWVkIHRvIGdldCBpbnRv IHRoZSBkZXRhaWxzIGFuZCBtZWFuaW5ncyBvZiB5b3VyIGNvbW1lbnRzLCBidXQ8QlI+DQomZ3Q7 Jmd0OyBpbiB0aGUgbWVhbnRpbWUgSSBoYXZlIG9uZSBiYXNpYyBjb25jZXJuIG9uIHlvdXIgY29t bWVudCBvbiAmcXVvdDsgTVBMUy1UUDxCUj4NCiZndDsmZ3Q7IGNvbm5lY3Rpb25zIE1BWSBiZSBh YmxlIHRvIGJlIHByb3Zpc2lvbmVkIGR5bmFtaWNhbGx5IHZpYSBhIGNvbnRyb2w8QlI+DQomZ3Q7 Jmd0OyBwbGFuZS4gVE9NOiBJIGluc2lzdCB0aGF0IHdlIGNoYW5nZSB0aGUgTUFZIGFib3ZlIHRv IE1VU1QuIEkgd2FudCBhPEJSPg0KJmd0OyZndDsgZHluYW1pYyB2ZXJzaW9uIG9mIHRoaXMgYXMg bXVjaCBhcyBhIHN0YXRpYyBvbmUuJnF1b3Q7PEJSPg0KJmd0OyZndDsgVGhpcyBpcyBvbmUgb2Yg dGhlIGZ1bmRhbWVudGFsIHByaW5jaXBsZXMgb2YgdGhlIE1QTFMtVFAsIHRoYXQgdGhlPEJSPg0K Jmd0OyZndDsgcHJlc2VuY2Ugb2YgYSBkaXN0cmlidXRlZCBjb250cm9sIHBsYW5lIGluIHN1cHBv cnQgb2YgbmV0d29yayBvcGVyYXRpb25zPEJSPg0KJmd0OyZndDsgaXMgb3B0aW9uYWwgKGFzIGlu IG90aGVyIHRyYW5zcG9ydCB0ZWNobm9sb2dpZXMsIGxpa2UgaW4gU0RILCBldGMuKS48QlI+DQom Z3Q7PEJSPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJIGFncmVlIGl0IGlzIG9wdGlv bmFsLiBXaGF0IEkgd2FudCB0byBtYWtlIHN1cmUgaXMgdGhhdCBpdCBpcyBub3Qgc288QlI+DQom Z3Q7IG9wdGlvbmFsIHRoYXQgaXQgaXMgY29tcGxldGVseSByZW1vdmVkIGZyb20gdGhlIGRlc2ln bi4mbmJzcDsgVGhlIGxhbmd1YWdlIGluIHRoZTxCUj4NCiZndDsgZG9jdW1lbnQgbm93IHNlZW1z IHRvIGJlIGhlYWRlZCBpbiB0aGF0IGRpcmVjdGlvbi48QlI+DQomZ3Q7PEJSPg0KJmd0OyZndDsg VGhpcyBpcyBhbHNvIHRoZSB0cmlnZ2VyIGZvciB0aGUgZGVmaW5pdGlvbiBvZiBPQU0gY2FwYWJp bGl0aWVzIHdoaWNoPEJSPg0KJmd0OyZndDsgYXJlIGluZGVwZW5kZW50IG9mIGEgY29udHJvbCBw bGFuZSwgYXMgd2VsbCBhcyBvZiB0aGUgcHJvdGVjdGlvbjxCUj4NCiZndDsmZ3Q7IHN3aXRjaGlu ZywgZXRjLjxCUj4NCiZndDsmZ3Q7IFRoaXMgaXMgYWxzbyBhZGRyZXNzZWQgYnkgdGhlIHNsaWRl cyBvZiB0aGUgSlc6ICZxdW90O0Rlc2lyZSB0byBzdGF0aWNhbGx5PEJSPg0KJmd0OyZndDsgY29u ZmlndXJlIExTUHMgYW5kIFBXRXMgdmlhIHRoZSBtYW5hZ2VtZW50IHBsYW5lLi4uPEJSPg0KJmd0 OzxCUj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSSBhbSBub3QgYXJndWluZyBhZ2Fp bnN0IHN0YXRpYzsgSSBhbSBhcmd1aW5nIGZvciBkeW5hbWljIHRvIGJlIGluIHRoZXJlPEJSPg0K Jmd0OyBhcyB3ZWxsLjxCUj4NCiZndDs8QlI+DQomZ3Q7Jmd0OyBUcmFuc3BvcnQgT0FNIGNhcGFi aWxpdGllcyBkb24ndCBleGlzdCBmb3IgTFNQIGFuZCBQV0UgaW5kZXBlbmRlbnQgb2Y8QlI+DQom Z3Q7Jmd0OyBjb25maWd1cmF0aW9uIG1lY2hhbmlzbSAobWFuYWdlbWVudCBwbGFuZSBvciBHTVBM UyBvciBQV0UgY29udHJvbDxCUj4NCiZndDsmZ3Q7IHBsYW5lKS4uLjxCUj4NCiZndDs8QlI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEl0IGRlcGVuZHMgb24gaG93IHlvdSBsb29rIGF0 IHdoYXQgJnF1b3Q7dHJhbnNwb3J0IE9BTSBjYXBhYmlsaXRpZXMmcXVvdDsuIEZyb20gbXk8QlI+ DQomZ3Q7IHBlcnNwZWN0aXZlIGF0IEJULCBJIGRlZmluaXRlbHkgdGhpbmsgdGhlcmUgaXMgYSBk eW5hbWljIGZsYXZvciBvZiB0aGlzIGZvcjxCUj4NCiZndDsgc3VyZS4mbmJzcDsgQWdhaW4sIEkg YW0gbm90IGFkdm9jYXRpbmcgcmVtb3ZhbCBvZiB0aGUgc3RhdGljIHBhcnRzLCBqdXN0IHRoZTxC Uj4NCiZndDsgYWRkaXRpb24gb2YgdGhlIGR5bmFtaWMgb25lcy4gQW5kIHNpbmNlIHRoZXkgYXJl IGFscmVhZHkgdGhlcmUgaW4gbGFyZ2U8QlI+DQomZ3Q7IHBhcnQsIGFzIHBhcnQgb2YgdGhlIGJh c2UgTVBMUyBzcGVjaWZpY2F0aW9uLCBJIGRvbid0IHNlZSBhbnkgaGFybSBpbjxCUj4NCiZndDsg c3BlY2lmeWluZyB0aGlzLjxCUj4NCiZndDs8QlI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IC0tVG9tPEJSPg0KJmd0OzxCUj4NCiZndDs8QlI+DQomZ3Q7PEJSPg0KJmd0OyZndDsgV2l0 aCBzdGF0aWMgcHJvdmlzaW9uaW5nLCBubyBkZXBlbmRlbmN5IG9uIHJvdXRpbmcgb3Igc2lnbmFs aW5nPEJSPg0KJmd0OyZndDsgKGUuZy4gR01QTFMgb3IsIElHUCwgUlNWUCwgQkdQLCBMRFApJnF1 b3Q7LCBldGMuPEJSPg0KJmd0OyZndDsgQmVzdCByZWdhcmRzLDxCUj4NCiZndDsmZ3Q7IE51cml0 PEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxC Uj4NCiZndDsmZ3Q7IEZyb206IG1wbHMtaW50ZXJvcC1ib3VuY2VzQGlldGYub3JnPEJSPg0KJmd0 OyZndDsgWzxBIEhSRUY9Im1haWx0bzptcGxzLWludGVyb3AtYm91bmNlc0BpZXRmLm9yZyI+bWFp bHRvOm1wbHMtaW50ZXJvcC1ib3VuY2VzQGlldGYub3JnPC9BPl0gT24gQmVoYWxmIE9mIGV4dCBU aG9tYXMgTmFkZWF1PEJSPg0KJmd0OyZndDsgU2VudDogRnJpZGF5LCBKdW5lIDIwLCAyMDA4IDIx OjM4PEJSPg0KJmd0OyZndDsgVG86IEJlbiBOaXZlbi1KZW5raW5zOyBMb2EgQW5kZXJzc29uOyBN RUFEIHRlYW08QlI+DQomZ3Q7Jmd0OyBTdWJqZWN0OiBSZTogW01wbHMtaW50ZXJvcF0gbmV4dCBN RUFEIHRlYW0gbWVldGluZzxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBDb21tZW50cyBvbiB0aGUgZG9jdW1lbnQgaW5saW5l IHN0YXJ0IHdpdGggJnF1b3Q7VE9NOiZxdW90OzxCUj4NCiZndDsmZ3Q7IEluIGdlbmVyYWwsIHBs ZWFzZSByZXZpZXcgdGhlIGRvY3VtZW50IGFuZCBwdXQgbW9yZSBvZiBhbiBlbXBoYXNpcyBvbjxC Uj4NCiZndDsmZ3Q7IHRoZSB1c2Ugb2YgJnF1b3Q7TVVTVCZxdW90OyByYXRoZXIgdGhhbiAmcXVv dDtNQVkmcXVvdDsgb3IgJnF1b3Q7U0hPVUxEJnF1b3Q7LiBUaGUgSUVURyBmcm93bnMgb248QlI+ DQomZ3Q7Jmd0OyByZXF1aXJlbWVudHMgZG9jdW1lbnRzIHRoYXQgYXJlIHRvbyBvcHRpb25hbC48 QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tVG9t PEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDs8 QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7IE5ldHdvcmsgV29ya2luZyBHcm91cCZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBCLiBO aXZlbi1KZW5raW5zLCBFZC48QlI+DQomZ3Q7Jmd0OyBJbnRlcm5ldC1EcmFmdCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBCVDxCUj4NCiZndDsmZ3Q7IEludGVu ZGVkIHN0YXR1czogSW5mb3JtYXRpb25hbCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBELiBCcnVuZ2FyZCwgRWQuPEJSPg0KJmd0OyZndDsgRXhwaXJlczogSmFudWFyeSAyLCAy MDA5Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFUJmFtcDtUPEJSPg0KJmd0OyZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgTS4gQmV0dHMsIEVkLjxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE5vcnRlbCBOZXR3b3JrczxC Uj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE4uIFNwcmVjaGVyPEJSPg0KJmd0 OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgTm9raWEgU2llbWVucyBOZXR3b3JrczxCUj4NCiZndDsmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IEp1bHkgMDEsIDIwMDg8QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7PEJS Pg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTVBM Uy1UUCBSZXF1aXJlbWVudHM8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBkcmFmdC1qZW5raW5zLW1wbHMtbXBsc3RwLXJlcXVpcmVtZW50cy0wMDxCUj4NCiZn dDsmZ3Q7PEJSPg0KJmd0OyZndDsgU3RhdHVzIG9mIHRoaXMgTWVtbzxCUj4NCiZndDsmZ3Q7PEJS Pg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgQnkgc3VibWl0dGluZyB0aGlzIEludGVybmV0 LURyYWZ0LCBlYWNoIGF1dGhvciByZXByZXNlbnRzIHRoYXQgYW55PEJSPg0KJmd0OyZndDsmbmJz cDsmbmJzcDsmbmJzcDsgYXBwbGljYWJsZSBwYXRlbnQgb3Igb3RoZXIgSVBSIGNsYWltcyBvZiB3 aGljaCBoZSBvciBzaGUgaXMgYXdhcmU8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBo YXZlIGJlZW4gb3Igd2lsbCBiZSBkaXNjbG9zZWQsIGFuZCBhbnkgb2Ygd2hpY2ggaGUgb3Igc2hl IGJlY29tZXM8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBhd2FyZSB3aWxsIGJlIGRp c2Nsb3NlZCwgaW4gYWNjb3JkYW5jZSB3aXRoIFNlY3Rpb24gNiBvZiBCQ1AgNzkuPEJSPg0KJmd0 OyZndDs8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBJbnRlcm5ldC1EcmFmdHMgYXJl IHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZzxCUj4NCiZndDsm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBp dHMgd29ya2luZyBncm91cHMuJm5ic3A7IE5vdGUgdGhhdDxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7IG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlIHdvcmtpbmcgZG9jdW1l bnRzIGFzIEludGVybmV0LTxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IERyYWZ0cy48 QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEludGVybmV0LURy YWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRo czxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVw bGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55PEJSPg0KJmd0OyZn dDsmbmJzcDsmbmJzcDsmbmJzcDsgdGltZS4mbmJzcDsgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1 c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZTxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICZxdW90O3dvcmsg aW4gcHJvZ3Jlc3MuJnF1b3Q7PEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNz ZWQgYXQ8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyA8QSBIUkVGPSJodHRwOi8vd3d3 LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaWV0 Zi8xaWQtYWJzdHJhY3RzLnR4dDwvQT4uPEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyBUaGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3Jp ZXMgY2FuIGJlIGFjY2Vzc2VkIGF0PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgPEEg SFJFRj0iaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbCI+aHR0cDovL3d3dy5pZXRmLm9y Zy9zaGFkb3cuaHRtbDwvQT4uPEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIEphbnVhcnkgMiwgMjAw OS48QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7IEFic3RyYWN0PEJSPg0KJmd0OyZndDs8QlI+ DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBUaGlzIGRvY3VtZW50IHdpbGwgb3V0bGluZSB0 aGUgcmVxdWlyZW1lbnRzIGZvciBNUExTLVRQLjxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsg UmVxdWlyZW1lbnRzIExhbmd1YWdlPEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyBUaGUga2V5IHdvcmRzICZxdW90O01VU1QmcXVvdDssICZxdW90O01VU1QgTk9U JnF1b3Q7LCAmcXVvdDtSRVFVSVJFRCZxdW90OywgJnF1b3Q7U0hBTEwmcXVvdDssICZxdW90O1NI QUxMIE5PVCZxdW90Oyw8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtTSE9V TEQmcXVvdDssICZxdW90O1NIT1VMRCBOT1QmcXVvdDssICZxdW90O1JFQ09NTUVOREVEJnF1b3Q7 LCAmcXVvdDtNQVkmcXVvdDssIGFuZCAmcXVvdDtPUFRJT05BTCZxdW90OyBpbiB0aGlzPEJSPg0K Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVk IGFzIGRlc2NyaWJlZCBpbiBbUkZDMjExOV0uPEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OzxC Uj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsgTml2ZW4tSmVua2lucywgZXQgYWwuJm5ic3A7Jm5i c3A7Jm5ic3A7IEV4cGlyZXMgSmFudWFyeSAyLCAyMDA5Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IFtQYWdlIDFdPEJSPg0KJmd0OyZndDsgDDxCUj4NCiZndDsmZ3Q7IEludGVybmV0 LURyYWZ0Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IE1QTFMtVFAgUmVxdWlyZW1lbnRzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IEp1bHkgMjAwODxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDs8 QlI+DQomZ3Q7Jmd0OyBUYWJsZSBvZiBDb250ZW50czxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZn dDsmbmJzcDsmbmJzcDsmbmJzcDsgMS4mbmJzcDsgSW50cm9kdWN0aW9uIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4mbmJzcDsgMzxCUj4NCiZndDsmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDIuJm5ic3A7IE1QTFMtVFAgUmVxdWlyZW1lbnRzIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuJm5ic3A7IDU8QlI+DQomZ3Q7Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAyLjEuJm5ic3A7IEdlbmVyYWwgcmVxdWlyZW1l bnRzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4mbmJzcDsgNTxCUj4NCiZn dDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDIuMi4mbmJzcDsgTGF5ZXJpbmcg cmVxdWlyZW1lbnRzJm5ic3A7IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuJm5i c3A7IDY8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAyLjMuJm5i c3A7IERhdGEgcGxhbmUgcmVxdWlyZW1lbnRzJm5ic3A7IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiZuYnNwOyA3PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgMi40LiZuYnNwOyBDb250cm9sIHBsYW5lIHJlcXVpcmVtZW50cyAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuJm5ic3A7IDg8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAyLjUuJm5ic3A7IE5ldHdvcmsgTWFuYWdlbWVudCAoTk0pIHJlcXVpcmVt ZW50cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTE8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAyLjYuJm5ic3A7IE9BTSByZXF1aXJlbWVudHMgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTE8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAyLjcuJm5ic3A7IE5ldHdvcmsgcGVyZm9ybWFuY2UgbWFuYWdl bWVudCAoUE0pIHJlcXVpcmVtZW50cyAuIC4gLiAuIC4gMTE8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAyLjguJm5ic3A7IFByb3RlY3Rpb24gJmFtcDsgU3Vydml2 YWJpbGl0eSByZXF1aXJlbWVudHMmbmJzcDsgLiAuIC4gLiAuIC4gLiAuIC4gMTI8QlI+DQomZ3Q7 Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAyLjkuJm5ic3A7IFFvUyByZXF1aXJl bWVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTQ8QlI+DQom Z3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAyLjEwLiBTZWN1cml0eSByZXF1 aXJlbWVudHMmbmJzcDsgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTU8QlI+ DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyAzLiZuYnNwOyBJQU5BIENvbnNpZGVyYXRpb25z Jm5ic3A7IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE1PEJSPg0K Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgNC4mbmJzcDsgU2VjdXJpdHkgQ29uc2lkZXJhdGlv bnMmbmJzcDsgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNjxCUj4NCiZn dDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDUuJm5ic3A7IEFja25vd2xlZGdlbWVudHMgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE2PEJSPg0KJmd0OyZndDsm bmJzcDsmbmJzcDsmbmJzcDsgNi4mbmJzcDsgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTY8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyBBdXRob3JzJyBBZGRyZXNzZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gMTY8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBJ bnRlbGxlY3R1YWwgUHJvcGVydHkgYW5kIENvcHlyaWdodCBTdGF0ZW1lbnRzIC4gLiAuIC4gLiAu IC4gLiAuIC4gMTg8QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDs8QlI+ DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OzxCUj4N CiZndDsmZ3Q7PEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7PEJSPg0K Jmd0OyZndDs8QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDs8QlI+DQom Z3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OzxCUj4NCiZn dDsmZ3Q7PEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0 OyZndDs8QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7 Jmd0OzxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsm Z3Q7IE5pdmVuLUplbmtpbnMsIGV0IGFsLiZuYnNwOyZuYnNwOyZuYnNwOyBFeHBpcmVzIEphbnVh cnkgMiwgMjAwOSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBbUGFnZSAyXTxCUj4N CiZndDsmZ3Q7IAw8QlI+DQomZ3Q7Jmd0OyBJbnRlcm5ldC1EcmFmdCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBNUExTLVRQ IFJlcXVpcmVtZW50cyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBKdWx5 IDIwMDg8QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsgMS4mbmJzcDsg SW50cm9kdWN0aW9uPEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyBGb3IgbWFueSB5ZWFycywgU09ORVQvU0RIIGhhcyBwcm92aWRlZCBzZXJ2aWNlIHByb3ZpZGVy cyB3aXRoIGEgaGlnaDxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJlbmNobWFyayBm b3IgcmVsaWFiaWxpdHkgYW5kIG9wZXJhdGlvbmFsIHNpbXBsaWNpdHkuJm5ic3A7IFdpdGggdGhl PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgYWNjZWxlcmF0aW5nIGdyb3d0aCBvZiBw YWNrZXQtYmFzZWQgc2VydmljZXMgKHN1Y2ggYXMgRXRoZXJuZXQsIFZvSVAsPEJSPg0KJmd0OyZn dDsmbmJzcDsmbmJzcDsmbmJzcDsgTDIvTDMgVlBOLCBJUFRWLCBSQU4gYmFja2hhdWxpbmcsIGV0 Yy4pLCBzZXJ2aWNlIHByb3ZpZGVycyBhcmUgaW48QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyBuZWVkIG9mIGNhcGFiaWxpdGllcyB0byBlZmZpY2llbnRseSBzdXBwb3J0IHBhY2tldC1i YXNlZCBzZXJ2aWNlcyBvbjxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZWlyIHRy YW5zcG9ydCBuZXR3b3Jrcy4mbmJzcDsgVGhlIG5lZWQgdG8gaW5jcmVhc2UgdGhlaXIgcmV2ZW51 ZSB3aGlsZTxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlbWFpbmluZyBjb21wZXRp dGl2ZSBmb3JjZXMgb3BlcmF0b3JzIHRvIGxvb2sgZm9yIHRoZSBsb3dlc3QgbmV0d29yazxCUj4N CiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRvdGFsIENvc3Qgb2YgT3duZXJzaGlwIChUQ08p LiZuYnNwOyBJbnZlc3RtZW50IGluIGJvdGggQ2FwaXRhbDxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7IEV4cGVuZGl0dXJlIChDQVBFWCkgYW5kIE9wZXJhdGlvbmFsIEV4cGVuc2UgKE9Q RVgpIHNob3VsZCBiZSBtaW5pbWFsLjxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmbmJzcDsm bmJzcDsmbmJzcDsgQ2FycmllcnMgYXJlIGNvbnNpZGVyaW5nIG1pZ3JhdGluZyB0byBwYWNrZXQg dHJhbnNwb3J0IG5ldHdvcmtzIGluPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgb3Jk ZXIgdG8gcmVkdWNlIHRoZWlyIGNvc3RzIGFuZCB0byBpbXByb3ZlIHRoZWlyIGFiaWxpdHkgdG8g c3VwcG9ydDxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNlcnZpY2VzIHdpdGggZ3Vh cmFudGVlZCBTTEFzLiZuYnNwOyBNaWdyYXRpbmcgZnJvbSBTT05FVC9TREggdG8gcGFja2V0PEJS Pg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgdHJhbnNwb3J0IG5ldHdvcmtzIHNob3VsZCBu b3QgaW52b2x2ZSBkcmFtYXRpYyBjaGFuZ2VzIGluIG5ldHdvcms8QlI+DQomZ3Q7Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyBvcGVyYXRpb24sIHNob3VsZCBub3QgbmVjZXNzaXRhdGUgZXh0ZW5zaXZl IHJldHJhaW5pbmcsIGFuZCBzaG91bGQ8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBu b3QgcmVxdWlyZSBtYWpvciBjaGFuZ2VzIHRvIGV4aXN0aW5nIHdvcmsgcHJhY3RpY2VzLiZuYnNw OyBUaGUgYWltIGlzIHRvPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgcHJlc2VydmUg dGhlIGxvb2stYW5kLWZlZWwgdG8gd2hpY2ggY2FycmllcnMgaGF2ZSBiZWNvbWUgYWNjdXN0b21l ZDxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluIGRlcGxveWluZyB0aGVpciBTT05F VC9TREggbmV0d29ya3MsIHdoaWxlIHByb3ZpZGluZyBjb21tb24sIG11bHRpLTxCUj4NCiZndDsm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxheWVyIG9wZXJhdGlvbnMsIHJlc2lsaWVuY3ksIGNvbnRy b2wgYW5kIG1hbmFnZW1lbnQgZm9yIHBhY2tldCw8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyBjaXJjdWl0IGFuZCBsYW1iZGEgdHJhbnNwb3J0IG5ldHdvcmtzLjxCUj4NCiZndDsmZ3Q7 PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgQW4gaW1wb3J0YW50IGF0dHJpYnV0ZSBv ZiBhIHRyYW5zcG9ydCBuZXR3b3JrIGlzIGl0cyBhYmlsaXR5IHRvPEJSPg0KJmd0OyZndDsmbmJz cDsmbmJzcDsmbmJzcDsgZnVuY3Rpb24gaW5kZXBlbmRlbnRseSBmcm9tIGJvdGggaXRzIGNsaWVu dCBhbmQgc2VydmVyICh0cmFuc21pc3Npb248QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyBtZWRpYSkgbGF5ZXIgbmV0d29ya3MuJm5ic3A7IEl0IHNob3VsZCBiZSBjYXBhYmxlIG9mIHRy YW5zbWl0dGluZyBvdmVyIGFueTxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1lZGlh LiZuYnNwOyBBbm90aGVyIGtleSBjaGFyYWN0ZXJpc3RpYyBvZiB0cmFuc3BvcnQgbmV0d29ya3Mg aXMgdGhlPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgY2FwYWJpbGl0eSB0byBtYWlu dGFpbiB0aGUgaW50ZWdyaXR5IG9mIHRoZSBjbGllbnQgc2lnbmFsIGJldHdlZW4gaXRzPEJSPg0K Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgaW5ncmVzcyBhbmQgZWdyZXNzIHBvcnRzLjxCUj4N CiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsgVE9NOiBJIHdvdWxkIHVzZSBzb21ldGhpbmcgb3RoZXIg dGhhbiAmcXVvdDtjbGllbnQgc2lnbmFsJnF1b3Q7IGhlcmUuIFNvbWV0aGluZzxCUj4NCiZndDsm Z3Q7IGxpa2UgJnF1b3Q7Y2xpZW50IHBhdGgmcXVvdDsgb3Igc29tZXRoaW5nIGlzIHdoYXQgSSB0 aGluayB5b3UgbWVhbi48QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7IEEgdHJhbnNwb3J0IG5l dHdvcmsgbXVzdCBwcm92aWRlIHRoZSBtZWFuczxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHRvIGNvbW1pdCBxdWFsaXR5IG9mIHNlcnZpY2Ugb2JqZWN0aXZlcyB0byBjbGllbnRzLiZu YnNwOyBUaGlzIGlzIGFjaGlldmVkPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgYnkg cHJvdmlkaW5nIGEgbWVjaGFuaXNtIGZvciBjbGllbnQgbmV0d29yayBzZXJ2aWNlIGRlbWFyY2F0 aW9uIGZvcjxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSBuZXR3b3JrIHBhdGgg dG9nZXRoZXIgd2l0aCBhbiBhc3NvY2lhdGVkIG5ldHdvcmsgcmVzaWxpZW5jeTxCUj4NCiZndDsm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1lY2hhbmlzbS4mbmJzcDsgQSB0cmFuc3BvcnQgbmV0d29y ayBtdXN0IGFsc28gcHJvdmlkZSBhIG1ldGhvZCBvZiBzZXJ2aWNlPEJSPg0KJmd0OyZndDsmbmJz cDsmbmJzcDsmbmJzcDsgbW9uaXRvcmluZyBpbiBvcmRlciB0byB2ZXJpZnkgdGhlIGRlbGl2ZXJ5 IG9mIGFuIGFncmVlZCBxdWFsaXR5IG9mPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsg c2VydmljZS4mbmJzcDsgVGhpcyBpcyBlbmFibGVkIGJ5IG1lYW5zIG9mIGNhcnJpZXItZ3JhZGUg T0FNIHRvb2xzLjxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsg VGhlIGNvbm5lY3Rpdml0eSBzZXJ2aWNlIGlzIHRoZSBiYXNpYyBzZXJ2aWNlIHByb3ZpZGVkIGJ5 IGEgdHJhbnNwb3J0PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgbmV0d29yay48QlI+ DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7IFRPTTogSXMgaXQ/IERvZXMgdGhlIHRyYW5zcG9ydCBy ZWFsbHkgcHJvdmlkZSBjb25uZWN0aW9ucyBvciBkb2VzIGl0PEJSPg0KJmd0OyZndDsgcHJvdmlk ZSB0cmFuc3BvcnQgcGF0aHM/Jm5ic3A7IEkgYW0gc2Vuc2l0aXZlIHRvIHRoZSB0ZXJtcyB1c2Vk IGhlcmUuIFdlPEJSPg0KJmd0OyZndDsgZG9uJ3Qgd2FudCB0aGlzIHRvIGJlY29tZSBhIGNvbm5l Y3QtZmVzdC4gU2VlbXMgdG8gbWUgdGhhdCB5b3UgZXhwbGFpbjxCUj4NCiZndDsmZ3Q7IHRoaXMg YmV0dGVyIGluIHRoZSBuZXh0IHNlbnRlbmNlIGFueWhvdy48QlI+DQomZ3Q7Jmd0OzxCUj4NCiZn dDsmZ3Q7Jm5ic3A7IFRoZSBwdXJwb3NlIG9mIGEgdHJhbnNwb3J0IG5ldHdvcmsgaXMgdG8gdHJh bnNwYXJlbnRseTxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNhcnJ5IGNsaWVudCBz aWduYWxzIChpLmUuIHRoZSBzdHJlYW0gb2YgY2xpZW50IFBEVXMgb3IgY2xpZW50IGJpdHMpPEJS Pg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyBUT006IEFnYWluLCBJIGRvbid0IGxpa2UgdGhlIHRl cm0gJnF1b3Q7c2lnbmFscyZxdW90OyBoZXJlLiBVc2UgJnF1b3Q7Y2xpZW50IGRhdGEmcXVvdDsg b3I8QlI+DQomZ3Q7Jmd0OyBzb21ldGhpbmcuPEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyBiZXR3ZWVuIGVuZHBvaW50cyBpbiB0aGUgbmV0d29yayAodHlwaWNh bGx5IG92ZXIgc2V2ZXJhbCBpbnRlcm1lZGlhdGU8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyBub2RlcykuJm5ic3A7IFRoZXNlIGVuZHBvaW50cyBtYXkgYmUgc2VydmljZSBzd2l0Y2hp bmcgcG9pbnRzIG9yIHNlcnZpY2U8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyB0ZXJt aW5hdGluZyBwb2ludHMuJm5ic3A7IFRoZSBjb25uZWN0aXZpdHkgc2VydmljZXMgb2ZmZXJlZCB0 byBjdXN0b21lcnM8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBhcmUgYWdncmVnYXRl ZCBpbnRvIGxhcmdlLCBsb25nLWhvbGRpbmcgdGltZSBwaXBlcy90cnVua3Mgd2hpY2g8QlI+DQom Z3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7IFRPTTogRG8geW91IHJlYWxseSBtZWFuIHRvIGNhbGwgdGhl c2UgJnF1b3Q7dGltZSBwaXBlcyZxdW90Oz8mbmJzcDsgU291bmRzIHRvbzxCUj4NCiZndDsmZ3Q7 IGZ1dHVyaXN0aWMgZXZlbiBmb3IgdGhpcyB3b3JrLiAqKSZuYnNwOyBJIHRoaW5rIHlvdSBtZWFu ICZxdW90Oy4uLmludG8gcmVsYXRpdmVseTxCUj4NCiZndDsmZ3Q7IGxhcmdlLCBsb25nLWxhc3Rp bmcgcGF0aHMuLi4mcXVvdDs8QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGVuYWJsZSB0aGUgZWZmaWNpZW50IGFuZCByZWxpYWJsZSBvcGVyYXRpb24gb2YgdGhl IHRyYW5zcG9ydCBuZXR3b3JrLjxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZXNl IHRydW5rcyBhcmUgbW9kaWZpZWQgaW5mcmVxdWVudGx5LjxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0 OyZndDsgVE9NOiBLZWVwIHRoZSB0ZXJtaW5vbG9neSBjb25zaXN0ZW50IGhlcmUgdG9vLiBUaGVy ZSBpcyB0aGUgdXNlIG9mPEJSPg0KJmd0OyZndDsgJnF1b3Q7dHJ1bmtzJnF1b3Q7LCAmcXVvdDtw aXBlcyZxdW90OywgZXRjLi4uPEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyBBZ2dyZWdhdGlvbiBhbmQgaGllcmFyY2h5IGFyZSBiZW5lZmljaWFsIGZvciBhY2hp ZXZpbmcgc2NhbGFiaWxpdHk8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBhbmQgc2Vj dXJpdHkgc2luY2U6PEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7PEJS Pg0KJmd0OyZndDsgTml2ZW4tSmVua2lucywgZXQgYWwuJm5ic3A7Jm5ic3A7Jm5ic3A7IEV4cGly ZXMgSmFudWFyeSAyLCAyMDA5Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFtQYWdl IDNdPEJSPg0KJmd0OyZndDsgDDxCUj4NCiZndDsmZ3Q7IEludGVybmV0LURyYWZ0Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IE1QTFMtVFAgUmVxdWlyZW1lbnRzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IEp1bHkgMjAwODxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyAxLiZuYnNwOyBUaGV5IHJlZHVjZSB0aGUgbnVtYmVyIG9mIHByb3Zp c2lvbmluZyBhbmQgZm9yd2FyZGluZyBzdGF0ZXMgaW48QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgbmV0d29yayBjb3JlLjxCUj4NCiZn dDsmZ3Q7PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgMi4mbmJzcDsgVGhleSByZWR1 Y2UgbG9hZCBhbmQgdGhlIGNvc3Qgb2YgaW1wbGVtZW50aW5nIHNlcnZpY2UgYXNzdXJhbmNlPEJS Pg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYW5k IGZhdWx0IG1hbmFnZW1lbnQuPEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyBUT006IERvIHRo ZXkgcmVhbGx5IHJlZHVjZSBsb2FkPyBUaGlzIGlzIG9uZSBvZiB0aG9zZSBmbHVmZnksIG9wZW4t ZW5kZWQ8QlI+DQomZ3Q7Jmd0OyB0ZXJtcyBsaWtlICZxdW90O3NjYWxlYWJpbGl0eSZxdW90OyB0 aGF0IEkgZG9uJ3QgbGlrZSB1c2VkIHVubGVzcyBpdCBpcyBjbGVhcmx5PEJSPg0KJmd0OyZndDsg ZGVmaW5lZC48QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDMu Jm5ic3A7IENsaWVudCBzaWduYWxzIGFyZSBjb21wbGV0ZWx5IGVuY2Fwc3VsYXRlZCBhbmQgaXNv bGF0ZWQgZnJvbSBlYWNoPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgb3RoZXIuJm5ic3A7IFRoaXMgYWxzbyBhbGxvd3MgY29tcGxldGUgaXNv bGF0aW9uIG9mIGN1c3RvbWVyIHRyYWZmaWM8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBmcm9tIGNhcnJpZXIgb3BlcmF0aW9ucy48QlI+DQom Z3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7IFRPTTogRG9lcyB0aGlzIHJlYWxseSBoYXBwZW4gYXQgdGhl IGRhdGEgb3IgY29udHJvbCBwbGFuZSBvciBib3RoPyBPciBkbzxCUj4NCiZndDsmZ3Q7IHdlIGNh cmU/PEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IENsaWVudCBzaWduYWxzIGFyZSBmaXJzdCB0cmFuc3BhcmVudGx5IGVuY2Fwc3VsYXRl ZC4mbmJzcDsgVGhlc2U8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBlbmNhcHN1bGF0 ZWQgY2xpZW50IHNpZ25hbHMgYXJlIHRoZW4gYWdncmVnYXRlZCBmb3IgdHJhbnNwb3J0IHRocm91 Z2g8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgbmV0d29yayBpbiBvcmRlciB0 byBvcHRpbWl6ZSBuZXR3b3JrIG1hbmFnZW1lbnQuJm5ic3A7IFNlcnZlciBsYXllcjxCUj4NCiZn dDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9BTSBpcyB1c2VkIHRvIG1vbml0b3IgdGhlIHRyYW5z cG9ydCBpbnRlZ3JpdHkgb2YgdGhlIGNsaWVudCBsYXllcjxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGFnZ3JlZ2F0ZS4mbmJzcDsgQXQgYW55IGhvcCwgdGhlIGFnZ3JlZ2F0ZWQgc2ln bmFscyBtYXkgYmUgZnVydGhlcjxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFnZ3Jl Z2F0ZWQgaW4gbG93ZXIgbGF5ZXIgdHJhbnNwb3J0IG5ldHdvcmsgcGF0aHMgZm9yIHRyYW5zcG9y dDxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFjcm9zcyBpbnRlcm1lZGlhdGUgc2hh cmVkIGxpbmtzLiZuYnNwOyBUaGUgZW5jYXBzdWxhdGVkIGNsaWVudCBzaWduYWxzPEJSPg0KJmd0 OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgYXJlIGV4dHJhY3RlZCBhdCB0aGUgZWRnZXMgb2YgYWdn cmVnYXRpb24gZG9tYWlucywgYW5kIGFyZSBlaXRoZXI8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyBkZWxpdmVyZWQgdG8gdGhlIGNsaWVudCBvciBmb3J3YXJkZWQgdG8gYW5vdGhlciBk b21haW4uJm5ic3A7IEluIHRoZSBjb3JlPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsg b2YgdGhlIG5ldHdvcmssIG9ubHkgdGhlIHNlcnZlciBsYXllciBhZ2dyZWdhdGVkIHNpZ25hbHMg YXJlPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgbW9uaXRvcmVkOyBpbmRpdmlkdWFs IGNsaWVudCBzaWduYWxzIGFyZSBtb25pdG9yZWQgYXQgdGhlIG5ldHdvcms8QlI+DQomZ3Q7Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyBib3VuZGFyeSBpbiB0aGUgY2xpZW50IGxheWVyIG5ldHdvcmsu PEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyBUT006IEkgYW0gbm90IHN1cmUgdGhlIGFib3Zl IGlzIGFwcHJvcHJpYXRlIGZvciBhIHJlcXVpcmVtZW50cyBkb2N1bWVudC48QlI+DQomZ3Q7Jmd0 OyBJdCBzb3VuZHMgbGlrZSB5b3UgYXJlIHNwZWxsaW5nIG91dCBhbiBhbGdvcml0aG0gZm9yIGhv dyBhIHNvbHV0aW9uPEJSPg0KJmd0OyZndDsgc2hvdWxkIHdvcmsuPEJSPg0KJmd0OyZndDs8QlI+ DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBRdWFsaXR5LW9mLXNlcnZpY2UgbWVjaGFuaXNt cyBhcmUgcmVxdWlyZWQgaW4gdGhlIHBhY2tldCB0cmFuc3BvcnQ8QlI+DQomZ3Q7Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyBuZXR3b3JrIHRvIGVuc3VyZSB0aGUgcHJpb3JpdGl6YXRpb24gb2YgY3Jp dGljYWwgc2VydmljZXMsIHRvPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgZ3VhcmFu dGVlIEJXIGFuZCB0byBjb250cm9sIGppdHRlciBhbmQgZGVsYXkuPEJSPg0KJmd0OyZndDs8QlI+ DQomZ3Q7Jmd0OyBUT006IEFyZSB0aGV5IHJlcXVpcmVkIGV2ZXJ5d2hlcmUgdGhlIHNlcnZpY2Ug ZXhpc3RzLCBvciBzYXkganVzdCBhdCB0aGU8QlI+DQomZ3Q7Jmd0OyBpbmdyZXNzL2VncmVzcyBm b3IgcG9saWNpbmcvbWFya2luZyBmdW5jdGlvbnM/Jm5ic3A7IFdoaWxlIHdlIGFyZSBvbiB0aGU8 QlI+DQomZ3Q7Jmd0OyBzdWJqZWN0LCBkbyB3ZSB3YW50IHRvIGJlIG1vcmUgc3BlY2lmaWMgYWJv dXQgUW9TIHJlcXVpcmVtZW50cz88QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7IFNlcnZpY2UgcHJvdmlkZXJzIHJlcXVpcmUgY29udHJvbCBhbmQgZGV0ZXJtaW5p c3RpYyB1c2FnZSBvZiBuZXR3b3JrPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVz b3VyY2VzLiZuYnNwOyBUaGV5IG5lZWQgZW5kLXRvLWVuZCBjb250cm9sIHRvIGVuZ2luZWVyIG5l dHdvcmsgcGF0aHM8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBhbmQgdG8gZWZmaWNp ZW50bHkgdXRpbGl6ZSBuZXR3b3JrIHJlc291cmNlcy4mbmJzcDsgVGhleSByZXF1aXJlPEJSPg0K Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgY2FwYWJpbGl0aWVzIHRvIHN0YXRpY2FsbHkgKE9T UyBiYXNlZCkgcHJvdmlzaW9uIGRldGVybWluaXN0aWMsPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJz cDsmbmJzcDsgcHJvdGVjdGVkIGFuZCBzZWN1cmVkIHNlcnZpY2VzIGFuZCB0aGVpciBhc3NvY2lh dGVkIHJlc291cmNlcyBhcyB3ZWxsPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgYXMg YWx0ZXJuYXRpdmUgY29udHJvbC1wbGFuZSBvcHRpb25zLjxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0 OyZndDsgVE9NOiBUaGV5IGFsc28gcmVxdWlyZSBkeW5hbWljIG9uZXMuIFBsZWFzZSBwdXQgdGhh dCBpbi4mbmJzcDsgSSBkb24ndCB3YW50PEJSPg0KJmd0OyZndDsgdG8gYmUgYXNraW5nIGZvciBv bmx5IGEgY29tcGxldGVseSBzdGF0aWMgc3lzdGVtLjxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZn dDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlIHRyYW5zcG9ydCBuZXR3b3JrIG11c3QgYmUgY2FwYWJs ZSBvZiB0cmFuc3BvcnRpbmcgbXVsdGlwbGU8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyBzZXJ2aWNlcyBpbiBhIHNjYWxhYmxlIG1hbm5lci48QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsm Z3Q7IFRPTTogQWdhaW4sIHRoaXMgdXNlIG9mICZxdW90O3NjYWxhYmxlJnF1b3Q7IG9mZmVuZHMg bWUuIFBsZWFzZSBiZSBtb3JlIHNwZWNpZmljPEJSPg0KJmd0OyZndDsgb3IgdGFrZSB0aGUgc2Vu dGVuY2Ugb3V0IGFzIGl0IGlzIG1lYW5pbmdsZXNzIGFzIHN0YXRlZC48QlI+DQomZ3Q7Jmd0OzxC Uj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IENhcnJpZXJzIHdpbGwgc3RpbGwgbmVlZCB0 byBjb3BlIHdpdGggbGVnYWN5IG5ldHdvcmtzICh3aGljaCBhcmU8QlI+DQomZ3Q7Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyBjb21wb3NlZCBvZiBtYW55IGxheWVycyBhbmQgdGVjaG5vbG9naWVzKSwg dGh1cyB0aGUgcGFja2V0IHRyYW5zcG9ydDxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IG5ldHdvcmsgc2hvdWxkIGludGVyd29yayB3aXRoIG90aGVyIHBhY2tldCBhbmQgdHJhbnNwb3J0 IG5ldHdvcmtzPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgKGJvdGggaG9yaXpvbnRh bGx5IGFuZCB2ZXJ0aWNhbGx5KS4mbmJzcDsgVmVydGljYWwgaW50ZXJ3b3JraW5nIGlzIGFsc288 QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBrbm93biBhcyBjbGllbnQvc2VydmVyIG9y IG5ldHdvcmsgaW50ZXJ3b3JraW5nLiZuYnNwOyBIb3Jpem9udGFsPEJSPg0KJmd0OyZndDsmbmJz cDsmbmJzcDsmbmJzcDsgaW50ZXJ3b3JraW5nIGlzIGFsc28ga25vd24gYXMgcGVlci1wYXJ0aXRp b24gb3Igc2VydmljZSBpbnRlcndvcmtpbmcuPEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyBU T006IERpZG4ndCB5b3UganVzdCBzYXkgdGhhdCB2ZXJ0aWNhbCBpbnRlcndvcmtpbmcgd2FzIGNs aWVudDxCUj4NCiZndDsmZ3Q7IGludGVyd29ya2luZyBpbiB0aGUgZmlyc3Qgc2VudGVuY2U/IEhv dyBjYW4gaG9yaXpvbnRhbCBiZSBzZXJ2aWNlPEJSPg0KJmd0OyZndDsgaW50ZXJ3b3JraW5nIGFz IHdlbGw/PEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBGb3Ig bW9yZSBkZXRhaWxzIG9uIGVhY2ggdHlwZSBvZiBpbnRlcndvcmtpbmcgYW5kIHNvbWUgb2YgdGhl IGlzc3VlczxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoYXQgbWF5IGFyaXNlIChl c3BlY2lhbGx5IHdpdGggaG9yaXpvbnRhbCBpbnRlcndvcmtpbmcpIHNlZTxCUj4NCiZndDsmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IFtJVFUuWTE0MDEuMjAwOF0uPEJSPg0KJmd0OyZndDs8QlI+DQom Z3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBNUExTIGlzIGEgbWF0dXJpbmcgcGFja2V0IHRlY2hu b2xvZ3kgYW5kIGl0IGlzIGFscmVhZHkgcGxheWluZyBhbjxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0 OyZndDs8QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7IE5pdmVuLUplbmtpbnMsIGV0IGFsLiZu YnNwOyZuYnNwOyZuYnNwOyBFeHBpcmVzIEphbnVhcnkgMiwgMjAwOSZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBbUGFnZSA0XTxCUj4NCiZndDsmZ3Q7IAw8QlI+DQomZ3Q7Jmd0OyBJ bnRlcm5ldC1EcmFmdCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBNUExTLVRQIFJlcXVpcmVtZW50cyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBKdWx5IDIwMDg8QlI+DQomZ3Q7Jmd0OzxCUj4NCiZn dDsmZ3Q7PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgaW1wb3J0YW50IHJvbGUgaW4g dHJhbnNwb3J0IG5ldHdvcmtzIGFuZCBzZXJ2aWNlcy4mbmJzcDsgSG93ZXZlciwgbm90IGFsbDxC Uj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9mIE1QTFMncyBjYXBhYmlsaXRpZXMgYW5k IG1lY2huaXNtcyBhcmUgbmVlZGVkIGFuZC9vciBjb25zaXN0ZW50PEJSPg0KJmd0OyZndDsmbmJz cDsmbmJzcDsmbmJzcDsgd2l0aCB0cmFuc3BvcnQgbmV0d29yayBvcGVyYXRpb25zLiZuYnNwOyBU aGlzIGRvY3VtZW50IGlkZW50aWZpZXMgdGhlPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJz cDsgcmVxdWlyZWQgY2FwYWJpbGl0aWVzIGZvciBNUExTIHNvIHRoYXQgaXQgY2FuIGJldHRlciBm aXQgYSB0cmFuc3BvcnQ8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyByb2xlLjxCUj4N CiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsgVE9NOiBJIHRoaW5rIHlvdSB3YW50IHRvIHNheSAmcXVv dDtpZGVudGlmaWVzIHRoZSByZXF1aXJlZCBzdWItc2V0IG9mPEJSPg0KJmd0OyZndDsgY2FwYWJp bGl0aWVzLi4uJnF1b3Q7Jm5ic3A7IGFuZCBsYXRlciAmcXVvdDtwb3RlbnRpYWxseSBuZXcgb25z IHNwZWNpZmljIGZvciB0cmFuc3BvcnQ8QlI+DQomZ3Q7Jmd0OyBuZXR3b3JrcyZxdW90OyB3aGlj aCBpdCBzZWVtcyB5b3Ugc2F5IHR3byBwYXJhZ3JhcGhzIGxhdGVyLjxCUj4NCiZndDsmZ3Q7PEJS Pg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgQ29tYmluaW5nIHRoZSBwYWNrZXQgZXhwZXJp ZW5jZSBvZiBNUExTIHdpdGggdGhlIG9wZXJhdGlvbmFsPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJz cDsmbmJzcDsgZXhwZXJpZW5jZSBvZiBTT05FVC9TREggY29uc3RpdHV0ZXMgYSBwYWNrZXQgdHJh bnNwb3J0IHRlY2hub2xvZ3k8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBuYW1lZCBN UExTLVRQLiZuYnNwOyBNUExTLVRQIHdpbGwgZW5hYmxlIHRoZSBtaWdyYXRpb24gb2YgU09ORVQv U0RIPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgbmV0d29ya3MgdG8gYSBwYWNrZXQt YmFzZWQgbmV0d29yayB0aGF0IHdpbGwgZWFzaWx5IHNjYWxlIHRvIHN1cHBvcnQ8QlI+DQomZ3Q7 Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBwYWNrZXQgc2VydmljZXMgaW4gYSBzaW1wbGUgYW5kIGNv c3QgZWZmZWN0aXZlIHdheS48QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IE1QTFMtVFAgbmVlZHMgdG8gY29tYmluZSB0aGUgbmVjZXNzYXJ5IGV4aXN0aW5nIGNh cGFiaWxpdGllcyBvZiBNUExTPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgd2l0aCBh ZGRpdGlvbmFsIG1pbmltYWwgbWVjaGFuaXNtcyBpbiBvcmRlciB0byBtZWV0IHRoZSByZXF1aXJl bWVudHM8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBkZXNjcmliZWQgaW4gdGhpcyBk b2N1bWVudC48QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRo ZSByZXF1aXJlbWVudHMgb2YgYW4gTVBMUyB0cmFuc3BvcnQgcHJvZmlsZSBhcmUgcHJvdmlkZWQg YmVsb3cuPEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyBUT006IFRoZXJlIGlzIGEgdGVybWlu b2xvZ3kgaXNzdWUgaW4gdGhlIHVzZSBvZiAmcXVvdDtNUExTLVRQJnF1b3Q7IG9yICZxdW90O2Fu IE1QTFM8QlI+DQomZ3Q7Jmd0OyB0cmFuc3BvcnQgcHJvZmlsZSZxdW90Oy4gVGhhdCBpcywgb24g dGhlIG9uZSBoYW5kIHlvdSByZWZlciB0byBhIHRlY2hub2xvZ3ksPEJSPg0KJmd0OyZndDsgYnV0 IG9uIHRoZSBvdGhlciBoYW5kIHlvdSBhcmUgcmVmZXJyaW5nIHRvIGEgc3BlY2lmaWMgcHJvZmls ZS4gV2hpY2ggaXM8QlI+DQomZ3Q7Jmd0OyBpdD88QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7 PEJSPg0KJmd0OyZndDsgMi4mbmJzcDsgTVBMUy1UUCBSZXF1aXJlbWVudHM8QlI+DQomZ3Q7Jmd0 OzxCUj4NCiZndDsmZ3Q7IDIuMS4mbmJzcDsgR2VuZXJhbCByZXF1aXJlbWVudHM8QlI+DQomZ3Q7 Jmd0OzxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgTVBMUy1UUCBNVVNU IG9mZmVyIGFzIG11Y2ggY29tbW9uYWxpdHkgYXMgcG9zc2libGUgd2l0aCB0aGUgTVBMUzxCUj4N CiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVzZXIgcGxhbmUg YXMgZGVmaW5lZCBieSBJRVRGLiZuYnNwOyBXaGVuIE1QTFMgb2ZmZXJzIG11bHRpcGxlIG9wdGlv bnM8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpbiB0 aGlzIHJlc3BlY3QsIE1QTFMtVFAgU0hPVUxEIHNlbGVjdCB0aGUgbWluaW11bSBzdWItc2V0PEJS Pg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKG5lY2Vzc2Fy eSBhbmQgc3VmZmljaWVudCBzdWJzZXQpIGFwcGxpY2FibGUgdG8gYSB0cmFuc3BvcnQ8QlI+DQom Z3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBuZXR3b3JrIGFwcGxp Y2F0aW9uLjxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgbyZu YnNwOyBBbnkgbmV3IGZ1bmN0aW9uYWxpdHkgdGhhdCBpcyBkZWZpbmVkIHRvIGZ1bGZpbCB0aGUg cmVxdWlyZW1lbnRzPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgZm9yIE1QTFMtVFAgTVVTVCBiZSBhZ3JlZWQgd2l0aGluIElFVEYgYW5kIHJlLXVzZSAo YXMgZmFyIGFzPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgcHJhY3RpY2FsbHkgcG9zc2libGUpIGV4aXN0aW5nIE1QTFMgc3RhbmRhcmRzLjxCUj4NCiZn dDsmZ3Q7PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgbyZuYnNwOyBNZWNoYW5pc21z IGFuZCBjYXBhYmlsaXRpZXMgTVVTVCBiZSBhYmxlIHRvIGludGVyb3BlcmF0ZSB3aXRoPEJSPg0K Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZXhpc3RpbmcgTVBM UyBhbmQgUFdFIGNvbnRyb2wgYW5kIGRhdGEgcGxhbmVzIHdoZXJlIGFwcHJvcHJpYXRlLjxCUj4N CiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsgVE9NOiBDaGFuZ2UgUFdFIHRvICZxdW90O0lFVEYgUFdF MyZxdW90OyBhbmQgJnF1b3Q7TVBMUyZxdW90OyB0byAmcXVvdDtJRVRGIE1QTFMmcXVvdDsuIFRo ZXJlIGFsc288QlI+DQomZ3Q7Jmd0OyBuZWVkIHRvIGJlIHJlZmVyZW5jZXMgaGVyZSB0byB0aGUg UFdFMyBhcmNoaXRlY3R1cmUgYW5kIE1QTFM8QlI+DQomZ3Q7Jmd0OyBhcmNoaXRlY3R1cmVzLjxC Uj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgbyZuYnNwOyBNUExT LVRQIE1VU1Qgc3VwcG9ydCB0cmFmZmljIGVuZ2luZWVyaW5nIGNhcGFiaWxpdGllcyB0aGF0IGFs bG93PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGV0 ZXJtaW5pc3RpYyBjb250cm9sIG9mIHRoZSB1c2Ugb2YgbmV0d29yayByZXNvdXJjZXMuPEJSPg0K Jmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBvJm5ic3A7IE1QTFMtVFAg TVVTVCBzdXBwb3J0IHRoZSBsb2dpY2FsIHNlcGFyYXRpb24gb2YgdGhlIGNvbnRyb2wgYW5kPEJS Pg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbWFuYWdlbWVu dCBwbGFuZXMgZnJvbSB0aGUgdXNlciBwbGFuZS48QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgTVBMUy1UUCBTSE9VTEQgc3VwcG9ydCB0aGUgcGh5 c2ljYWwgc2VwYXJhdGlvbiBvZiB0aGUgY29udHJvbCBhbmQ8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBtYW5hZ2VtZW50IHBsYW5lcyBmcm9tIHRoZSB1 c2VyIHBsYW5lLjxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsg byZuYnNwOyBNUExTLVRQIE1VU1Qgc3VwcG9ydCBwb2ludCB0byBwb2ludCAoUDJQKSBvciBwb2lu dCB0byBtdWx0aXBvaW50PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgKFAyTVApIGNvbm5lY3Rpb25zLjxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsg VE9NOiBBcmUgd2UgYXZvaWRpbmcgTVAyTVAgY29uc2Npb3VzbHkgb3Igd2FzIGl0IGxlZnQgb3V0 PzxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyBOaXZlbi1KZW5raW5z LCBldCBhbC4mbmJzcDsmbmJzcDsmbmJzcDsgRXhwaXJlcyBKYW51YXJ5IDIsIDIwMDkmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgW1BhZ2UgNV08QlI+DQomZ3Q7Jmd0OyAMPEJSPg0K Jmd0OyZndDsgSW50ZXJuZXQtRHJhZnQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTVBMUy1UUCBSZXF1aXJlbWVudHMmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSnVseSAyMDA4PEJSPg0KJmd0OyZn dDs8QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG8mbmJzcDsg TVBMUy1UUCBNVVNUIHN1cHBvcnQgc3RhdGljIHByb3Zpc2lvbmluZyBvZiBjb25uZWN0aW9ucyB2 aWEgYW48QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBO TVMvT1NTIChpLmUuIHZpYSB0aGUgbWFuYWdlbWVudCBwbGFuZSkuPEJSPg0KJmd0OyZndDs8QlI+ DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBvJm5ic3A7IFN0YXRpYyBwcm92aXNpb25pbmcg TVVTVCBub3QgZGVwZW5kIG9uIHJvdXRpbmcgb3Igc2lnbmFsaW5nPEJSPg0KJmd0OyZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcHJvdG9jb2xzIChlLmcuJm5ic3A7IEdN UExTLCBPU1BGLCBJUy1JUywgUlNWUCwgQkdQLCBMRFAgZXRjLikuPEJSPg0KJmd0OyZndDs8QlI+ DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBvJm5ic3A7IE1QTFMtVFAgY29ubmVjdGlvbnMg TUFZIGJlIGFibGUgdG8gYmUgcHJvdmlzaW9uZWQgZHluYW1pY2FsbHkgdmlhPEJSPg0KJmd0OyZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYSBjb250cm9sIHBsYW5lLjxC Uj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsgVE9NOiBJIGluc2lzdCB0aGF0IHdlIGNoYW5nZSB0 aGUgTUFZIGFib3ZlIHRvIE1VU1QuIEkgd2FudCBhIGR5bmFtaWM8QlI+DQomZ3Q7Jmd0OyB2ZXJz aW9uIG9mIHRoaXMgYXMgbXVjaCBhcyBhIHN0YXRpYyBvbmUuPEJSPg0KJmd0OyZndDs8QlI+DQom Z3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgVGhlIE1QTFMt VFAgZGF0YSBwbGFuZSBNVVNUIGJlIGNhcGFibGUgb2YgZnVuY3Rpb25pbmc8QlI+DQomZ3Q7Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpbmRlcGVuZGVudGx5IG9mIHRo ZSBjb250cm9sIG9yIG1hbmFnZW1lbnQgcGxhbmUgdXNlZCB0byBvcGVyYXRlPEJSPg0KJmd0OyZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlIE1QTFMtVFAgbGF5ZXIg bmV0d29yay4mbmJzcDsgVGhhdCBpcyB0aGUgTVBMUy1UUCBkYXRhIHBsYW5lPEJSPg0KJmd0OyZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb3BlcmF0aW9uIE1VU1QgY29u dGludWUgdG8gb3BlcmF0ZSBub3JtYWxseSBpZiB0aGUgbWFuYWdlbWVudDxCUj4NCiZndDsmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBsYW5lIG9yIGNvbnRyb2wgcGxh bmUgdGhhdCBjb25maWd1cmVkIHRoZSBjb25uZWN0aW9ucyBmYWlscy48QlI+DQomZ3Q7Jmd0OzxC Uj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgTVBMUy1UUCBNVVNUIHN1cHBv cnQgYW55IG5ldHdvcmsgdG9wb2xvZ3kgYW5kIGJlIGFibGUgdG8gc3VwcG9ydDxCUj4NCiZndDsm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluY3JlYXNpbmcgYmFuZHdp ZHRoIGRlbWFuZHMsIHRvcG9sb2d5LCBudW1iZXIgb2YgY3VzdG9tZXJzIG9yPEJSPg0KJmd0OyZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbnVtYmVyIG9mIHNlcnZpY2Vz IGluY3JlbWVudGFsbHkuPEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7 IFRPTTogSSB0aGluayBpdCBpcyBpbXBlcmF0aXZlIHRoYXQgYWx0aG91Z2ggYW4gTVBMUy1UUCBp cyBkZWZpbmVkIHRvPEJSPg0KJmd0OyZndDsgcGxheSBuaWNlbHkgd2l0aCBhbiBNUExTIG9uZSwg aXQgaXMgaW1wZXJhdGl2ZSB0aGF0IG9uZSBjYW4gZGlzdGluZ3Vpc2g8QlI+DQomZ3Q7Jmd0OyBi ZXR3ZWVuIGJvdGgsIGF0IGxlYXN0IGF0IHRoZSBjb250cm9sIHBsYW5lLCBidXQgcGVyaGFwcyBh dCB0aGUgZGF0YTxCUj4NCiZndDsmZ3Q7IHBsYW5lIGFzIHdlbGwuPEJSPg0KJmd0OyZndDs8QlI+ DQomZ3Q7Jmd0OyAyLjIuJm5ic3A7IExheWVyaW5nIHJlcXVpcmVtZW50czxCUj4NCiZndDsmZ3Q7 PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgbyZuYnNwOyBBbiBNUExTLVRQIG5ldHdv cmsgTVVTVCBvcGVyYXRlIGluIGEgbXVsdGlwbGUgbGF5ZXIgbmV0d29yazxCUj4NCiZndDsmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVudmlyb25tZW50IGNvbnNpc3Rp bmcgb2YgdGhlIGZvbGxvd2luZyBpbmRlcGVuZGVudCBsYXllcnM6PEJSPg0KJmd0OyZndDs8QlI+ DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxLiZuYnNwOyBB ICZxdW90O3NlcnZpY2UgbGF5ZXImcXVvdDsgaW5zdGFuY2UgaW4gd2hpY2ggdGhlIGNvbm5lY3Rp b25zIGNhcnJ5IHRoZTxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGN1c3RvbWVyJ3MgKGluZGl2aWR1YWwgb3Ig YnVuZGxlZCkgc2VydmljZSAobWF5IGJlIHBvaW50LXRvLTxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBvaW50 LCBwb2ludC10by1tdWx0aXBvaW50IG9yIG11bHRpcG9pbnQtdG8tbXVsdGlwb2ludDxCUj4NCiZn dDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHNlcnZpY2VzKTs8QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDIuJm5ic3A7IEEgJnF1b3Q7dHJ1bmsgbGF5ZXIm cXVvdDsgd2l0aCBwb2ludC10by1wb2ludCBvciBwb2ludC10by1tdWx0aXBvaW50PEJSPg0KJmd0 OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgY29ubmVjdGlvbnMgd2hpY2ggYXJlIHVzZWQgdG8gY2FycnkgYWdncmVnYXRlcyBv ZiB0aGUgbmV0d29yazxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O3NlcnZpY2UgbGF5ZXImcXVvdDsg Y29ubmVjdGlvbnM7IGFuZDxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMy4mbmJzcDsgQSAmcXVvdDt0cmFuc21pc3Npb24gbWVk aWEgbGF5ZXImcXVvdDsgd2hpY2ggcHJvdmlkZXMgc2VjdGlvbnMgKHR3by1wb3J0PEJSPg0KJmd0 OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgcG9pbnQtdG8tcG9pbnQgY29ubmVjdGlvbnMpIHRvIGNhcnJ5IHRoZSBhZ2dyZWdh dGUgb2YgbmV0d29yazxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRydW5rIG9yIG5ldHdvcmsgc2VydmljZSBj b25uZWN0aW9ucyBvbiB2YXJpb3VzIHBoeXNpY2FsPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbWVkaWEuPEJS Pg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyBUT006IFRoaXMgc3R1ZmYgYmVsb25ncyBpbiB0aGUg VGVybWlub2xvZ3kgc2VjdGlvbiBhdCB0aGUgdG9wLjxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZn dDsmbmJzcDsmbmJzcDsmbmJzcDsgTVBMUy1UUCBtYXkgcHJvdmlkZSB0aGUgJnF1b3Q7c2Vydmlj ZSBsYXllciZxdW90OyAoZm9yIFAyUCBhbmQgUDJNUCBzZXJ2aWNlcyk8QlI+DQomZ3Q7Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyBhbmQvb3IgdGhlICZxdW90O3RydW5rIGxheWVyJnF1b3Q7IHdpdGhp biBhIGxheWVyIG5ldHdvcmsgZW52aXJvbm1lbnQuPEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyBvJm5ic3A7IEFuIE1QTFMtVFAgbGF5ZXIgbmV0d29yayBNVVNU IHN1cHBvcnQgdGhlIHRyYW5zcGFyZW50IHRyYW5zcG9ydCBvZjxCUj4NCiZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE1QTFMtVFAgYW5kIG5vbiBNUExTLVRQIGNs aWVudCBsYXllciBuZXR3b3Jrcy48QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7IG8mbmJzcDsgQW4gTVBMUy1UUCBsYXllciBuZXR3b3JrIE1VU1QgYmUgYWJsZSB0 byBiZSB0cmFuc3BhcmVudGx5IGNhcnJpZWQ8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBvdmVyIE1QTFMtVFAgYW5kIG5vbiBNUExTLVRQIHNlcnZlciBs YXllciBuZXR3b3JrcyAoc3VjaCBhczxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IEV0aGVybmV0LCBPVE4sIGV0Yy4pPEJSPg0KJmd0OyZndDs8QlI+DQom Z3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyBOaXZlbi1K ZW5raW5zLCBldCBhbC4mbmJzcDsmbmJzcDsmbmJzcDsgRXhwaXJlcyBKYW51YXJ5IDIsIDIwMDkm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgW1BhZ2UgNl08QlI+DQomZ3Q7Jmd0OyAM PEJSPg0KJmd0OyZndDsgSW50ZXJuZXQtRHJhZnQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTVBMUy1UUCBSZXF1aXJlbWVu dHMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSnVseSAyMDA4PEJSPg0K Jmd0OyZndDs8QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG8m bmJzcDsgSXQgTVVTVCBiZSBwb3NzaWJsZSB0byBvcGVyYXRlIHRoZSBNUExTLVRQIGxheWVyIG5l dHdvcms8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBp bmRlcGVuZGVudGx5IG9mIG90aGVyIGxheWVyIG5ldHdvcmtzIChlaXRoZXIgTVBMUy1UUCBvciBu b248QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBNUExT LVRQKS48QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoaXMg aXMgbm90IG9ubHkgYSB0ZWNobm9sb2d5IHJlcXVpcmVtZW50LCBkaWZmZXJlbnQgYWRtaW5pc3Ry YXRpdmU8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBncm91cHMgbWF5IGJlIHJlc3Bv bnNpYmxlIGZvciBkaWZmZXJlbnQgbGF5ZXIgbmV0d29ya3MgKGV2ZW4gd2hlbjxCUj4NCiZndDsm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZXkgYXJlIG9mIHRoZSBzYW1lIHR5cGUpKSwgYW5kIHJl cXVpcmUgdGhlIGNhcGFiaWxpdHkgdG88QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBv cGVyYXRpb25hbGx5IHN1cHBvcnQgdGhlIGRpZmZlcmVudCBsYXllcnMuPEJSPg0KJmd0OyZndDs8 QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBvJm5ic3A7IEl0IE1VU1QgYmUgcG9zc2li bGUgdG8gaGlkZSBNUExTLVRQIGxheWVyIG5ldHdvcmsgYWRkcmVzc2luZyBhbmQ8QlI+DQomZ3Q7 Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBvdGhlciBpbmZvcm1hdGlv biAoZS5nLiB0b3BvbG9neSkgZnJvbSBjbGllbnQgbGF5ZXJzLjxCUj4NCiZndDsmZ3Q7PEJSPg0K Jmd0OyZndDsgMi4zLiZuYnNwOyBEYXRhIHBsYW5lIHJlcXVpcmVtZW50czxCUj4NCiZndDsmZ3Q7 PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgbyZuYnNwOyBUaGUgaWRlbnRpZmljYXRp b24gb2YgZWFjaCBjb25uZWN0aW9uIHdpdGhpbiBpdHMgYWdncmVnYXRlIE1VU1QgYmU8QlI+DQom Z3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzdXBwb3J0ZWQuPEJS Pg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBvJm5ic3A7IEEgbGFi ZWwgaW4gYSBwYXJ0aWN1bGFyIHNlY3Rpb24gTVVTVCB1bmlxdWVseSBpZGVudGlmeSB0aGU8QlI+ DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjb25uZWN0aW9u LjxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgbyZuYnNwOyBB IGNvbm5lY3Rpb24ncyBzb3VyY2UgTVVTVCBiZSBpZGVudGlmaWFibGUgYXQgaXRzIGRlc3RpbmF0 aW9uLjxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgQ29ubmVj dGlvbnMgY2FuIGJlIGFnZ3JlZ2F0ZWQgaW50byB0cnVua3MgYnkgcHVzaGluZyBhbmQgZGUtPEJS Pg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgYWdncmVnYXRlZCBieSBwb3BwaW5nIGxhYmVs cy4mbmJzcDsgTVBMUy1UUCBsYWJlbHMgbWF5IGJlIHN3YXBwZWQgd2l0aGluIGE8QlI+DQomZ3Q7 Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBjb25uZWN0aW9uIGluIGEgbGF5ZXIgbmV0d29yayBpbnN0 YW5jZSB3aGVuIHRoZSB0cmFmZmljIGlzIGZvcndhcmRlZDxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGZyb20gb25lIE1QTFMtVFAgbGluayBjb25uZWN0aW9uIHRvIGFub3RoZXIgTVBM Uy1UUCBsaW5rIGNvbm5lY3Rpb24uPEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyBvJm5ic3A7IExhYmVsbGluZyBNVVNUIG1ha2UgdXNlIG9mIHRoZSBNUExTIGxh YmVsIGFuZCBsYWJlbCBzdGFjayBlbnRyeSBhczxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRlZmluZWQgaW4gUkZDMzAzMi48QlI+DQomZ3Q7Jmd0OzxC Uj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgSXQgTVVTVCBiZSBwb3NzaWJs ZSB0byBvcGVyYXRlIGFuZCBjb25maWd1cmUgdGhlIE1QTFMtVFAgZGF0YTxCUj4NCiZndDsmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICh0cmFuc3BvcnQpIHBsYW5lIHdp dGhvdXQgYW55IElQIGZ1bmN0aW9uYWxpdHkuPEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyBvJm5ic3A7IE1QTFMtVFAgTVVTVCBzdXBwb3J0IGJvdGggdW5pZGly ZWN0aW9uYWwgYW5kIGJpLWRpcmVjdGlvbmFsIHBvaW50LTxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRvLXBvaW50IGNvbm5lY3Rpb25zLjxCUj4NCiZn dDsmZ3Q7PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgbyZuYnNwOyBUaGUgZm9yd2Fy ZCBhbmQgYmFja3dhcmQgZGlyZWN0aW9ucyBvZiBhIGJpLWRpcmVjdGlvbmFsIGNvbm5lY3Rpb248 QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTSE9VTEQg Zm9sbG93IHRoZSBzYW1lIHBhdGggd2l0aGluIHRoZSBNUExTLVRQIG5ldHdvcmsuPEJSPg0KJmd0 OyZndDs8QlI+DQomZ3Q7Jmd0OyBUT006IEkgYW0gbm90IHN1cmUgaWYgd2Ugc2F5IHRoYXQgdGhl eSBTSE9VTEQgYXMgbXVjaCBhcyAmcXVvdDt0aGV5IE1VU1QgYmU8QlI+DQomZ3Q7Jmd0OyBjYXBh YmxlIG9mJnF1b3Q7LjxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJz cDsgbyZuYnNwOyBUaGUgaW50ZXJtZWRpYXRlIG5vZGVzIFNIT1VMRCBiZSBhd2FyZSBhYm91dCB0 aGUgYmluZGluZyBvZiB0aGU8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBmb3J3YXJkIGFuZCB0aGUgYmFja3dhcmQgZGlyZWN0aW9ucyBiZWxvbmdpbmcg dG8gdGhlIHNhbWUgYmktPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgZGlyZWN0aW9uYWwgY29ubmVjdGlvbi48QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsm Z3Q7IFRPTTogQWdhaW4sICZxdW90O1NIT1VMRCBiZSBjYXBhYmxlIG9mJnF1b3Q7IHNlZW1zIGJl dHRlci48QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG8mbmJz cDsgTVBMUy1UUCBTSE9VTEQgc3VwcG9ydCB1bmlkaXJlY3Rpb25hbCBwb2ludC10by1tdWx0aXBv aW50PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY29u bmVjdGlvbnMuPEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBv Jm5ic3A7IE1QTFMtVFAgY29ubmVjdGlvbnMgTVVTVCBOT1QgcGVyZm9ybSBtZXJnaW5nIGluIGEg d2F5IHRoYXQ8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBwcmV2ZW50cyB0aGUgdW5pcXVlIGlkZW50aWZpY2F0aW9uIG9mIHRoZSBzb3VyY2UgYXQgdGhl PEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsg Tml2ZW4tSmVua2lucywgZXQgYWwuJm5ic3A7Jm5ic3A7Jm5ic3A7IEV4cGlyZXMgSmFudWFyeSAy LCAyMDA5Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFtQYWdlIDddPEJSPg0KJmd0 OyZndDsgDDxCUj4NCiZndDsmZ3Q7IEludGVybmV0LURyYWZ0Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE1QTFMtVFAgUmVx dWlyZW1lbnRzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEp1bHkgMjAw ODxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZXN0aW5hdGlvbiAoZS5nLiBubyB1c2Ugb2YgTERQIG1w MnAgc2lnbmFsaW5nIGluIG9yZGVyIHRvIGF2b2lkPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbG9zaW5nIExTUCBoZWFkLWVuZCBpbmZvcm1hdGlvbiwg bm8gdXNlIG9mIFBIUCwgZXRjKS48QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7IG8mbmJzcDsgTVBMUy1UUCBTSE9VTEQgc3VwcG9ydCB0cmFuc3BvcnQgYW5kIFFv UyBtZWNoYW5pc21zIHRoYXQgY2FuPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgZGVsaXZlciBzdGF0aXN0aWNhbCBtdWx0aXBsZXhpbmcgZ2Fpbi4mbmJz cDsgUGFja2V0cyBleGNlZWRpbmcgdGhlPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgYWdyZWVkIHRyYWZmaWMgcHJvZmlsZSBtYXkgYmUgbWFya2VkIG9y IGRpc2NhcmRlZCBieSB0aGUgdHJhZmZpYzxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvbmRpdGlvbmluZyBhdCB0aGUgaW5ncmVzcyBvZiB0aGUgTVBM Uy1UUCBuZXR3b3JrLjxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsgVE9NOiBIb3cgYWJvdXQg ZWdyZXNzIHBvbGljaW5nICsgbWFya2luZz88QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7PEJS Pg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgbyZuYnNwOyBNUExTLVRQIE1VU1Qgc3VwcG9y dCBjb25uZWN0aW9ucyB0aHJvdWdoIGEgc2luZ2xlIGRvbWFpbi48QlI+DQomZ3Q7Jmd0OzxCUj4N CiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgTVBMUy1UUCBTSE9VTEQgc3VwcG9y dCBjb25uZWN0aW9ucyB0aHJvdWdoIG11bHRpcGxlIGRvbWFpbnMuPEJSPg0KJmd0OyZndDs8QlI+ DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBvJm5ic3A7IE1QTFMtVFAgTVVTVCBiZSBhYmxl IHRvIGFjY29tbW9kYXRlIG5ldyB0cmFmZmljIHR5cGVzLjxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0 OyZndDsgVE9NOiBOZXcgdHJhZmZpYyB0eXBlcyBvdGhlciB0aGFuIHRob3NlIHN1cHBvcnRlZCBi eSBNUExTPyBUaGlzIGRvZXNuJ3Q8QlI+DQomZ3Q7Jmd0OyBtYWtlIHNlbnNlIHRvIG1lIGFzIHRo aXMgd2lsbCByZXN1bHQgaW4gTVBMUy1UUCBub3QgYmVpbmcgYSBzdWJzZXQgb2Y8QlI+DQomZ3Q7 Jmd0OyBNUExTLjxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsg byZuYnNwOyBNUExTLVRQIFNIT1VMRCBzdXBwb3J0IG1lY2hhbmlzbXMgdG8gc2FmZWd1YXJkIGFn YWluc3QgdGhlPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgcHJvdmlzaW9uaW5nIG9mIGNvbm5lY3Rpb25zIHdoaWNoIGNvbnRhaW4gZm9yd2FyZGluZyBs b29wcy48QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG8mbmJz cDsgTVBMUy1UUCBTSE9VTEQgc3VwcG9ydCBtZWNoYW5pc21zIHRvIG1pbmltaXplIHRyYWZmaWMg aW1wYWN0PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg ZHVyaW5nIG5ldHdvcmsgcmVjb25maWd1cmF0aW9uLjxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZn dDsmbmJzcDsmbmJzcDsmbmJzcDsgbyZuYnNwOyBNUExTLVRQIFNIT1VMRCBzdXBwb3J0IG1lY2hh bmlzbXMgd2hpY2ggZW5zdXJlIHRoZSBpbnRlZ3JpdHkgb2Y8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgYWRhcHRlZCBpbmZvcm1hdGlvbi48QlI+ DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgTVBMUy1U UCBNVVNUIHN1cHBvcnQgYW4gdW5hbWJpZ3VvdXMgYW5kIHJlbGlhYmxlIG1lYW5zIG9mPEJSPg0K Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGlzdGluZ3Vpc2hp bmcgdXNlcnMnIChjbGllbnQpIHBhY2tldHMgZnJvbSBNUExTLVRQIGNvbnRyb2wgcGxhbmU8QlI+ DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhbmQgbWFuYWdl bWVudCBwbGFuZSBwYWNrZXRzLjxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsgMi40LiZuYnNw OyBDb250cm9sIHBsYW5lIHJlcXVpcmVtZW50czxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsm bmJzcDsmbmJzcDsmbmJzcDsgbyZuYnNwOyBBIGRpc3RyaWJ1dGVkIGNvbnRyb2wgcGxhbmUgTUFZ IGJlIHN1cHBvcnRlZCB0byBlbmFibGUgZmFzdCw8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkeW5hbWljIGFuZCByZWxpYWJsZSBzZXJ2aWNlIHByb3Zp c2lvbmluZyBpbiBtdWx0aS12ZW5kb3IgYW5kPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgbXVsdGktZG9tYWluIGVudmlyb25tZW50cyB1c2luZyBzdGFu ZGFyZGl6ZWQgcHJvdG9jb2xzIHRoYXQ8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBndWFyYW50ZWUgaW50ZXJvcGVyYWJpbGl0eS48QlI+DQomZ3Q7Jmd0 OzxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgSWYgYSBjb250cm9sIHBs YW5lIGlzIHVzZWQgZm9yIGNvbmZpZ3VyYXRpb24gb2YgTVBMUy1UUDxCUj4NCiZndDsmZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvbm5lY3Rpb25zIHRoZW46PEJSPg0K Jmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAqJm5ic3A7IEZhaWx1cmUgYW5kIHJlY292ZXJ5IG9mIHRoZSBjb250cm9sIHBsYW5lIE1VU1Qg Tk9UIGltcGFjdCB0aGU8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBNUExTLVRQIGZvcndhcmRpbmcgcGxhbmUuPEJSPg0K Jmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyBUT006IFRoaXMgaXMgZGlmZmljdWx0LCBhcyB0aGlzIHJl YWxseSBpcyBoYW5kbGVkIGluIHByYWN0aWNlIGF0IGJvdGg8QlI+DQomZ3Q7Jmd0OyBkYXRhIGFu ZCBjb250cm9sIHBsYW5lcywgZGVwZW5kaW5nIG9uIGhvdyB0aGlzIGlzIGNvbmZpZ3VyZWQvZGVz aWduZWQsPEJSPg0KJmd0OyZndDsgYW5kIHRoZSByZS1zaWduYWxpbmcgY2FuIGltcGFjdCB0aGUg ZGF0YSBwbGFuZS48QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICombmJzcDsgSXQgTVVTVCBzdXBwb3J0IHRoZSBzZXR1cCwgbW9k aWZpY2F0aW9uLCBhbmQgcmVsZWFzZSBvZiBNUExTLVRQPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY29ubmVjdGlvbnMg YW5kIHByb3RlY3Rpb24gY29ubmVjdGlvbnMuPEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAqJm5ic3A7IEl0IE1VU1Qgc3VwcG9y dCBtZWNoYW5pc21zIHRvIHByb3ZpZGUgdHJhZmZpYyBlbmdpbmVlcmluZyw8QlI+DQomZ3Q7Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBj b25zdHJhaW50LWJhc2VkIHJvdXRpbmcgYW5kIGV4cGxpY2l0IHBhdGggY29udHJvbC48QlI+DQom Z3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICombmJzcDsgSXQgTVVTVCBwcm92aWRlIG1lY2hhbmlzbXMgdG8gYWRkcmVzcyBRb1MgYW5kIHBl cmZvcm1hbmNlPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVxdWlyZW1lbnRzIChzdWNoIGFzIHRocm91Z2hwdXQsIGRl bGF5LCBwYWNrZXQgbG9zcywgZXRjLik8QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7PEJSPg0K Jmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyBOaXZlbi1KZW5raW5zLCBldCBhbC4mbmJzcDsmbmJzcDsm bmJzcDsgRXhwaXJlcyBKYW51YXJ5IDIsIDIwMDkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgW1BhZ2UgOF08QlI+DQomZ3Q7Jmd0OyAMPEJSPg0KJmd0OyZndDsgSW50ZXJuZXQtRHJh ZnQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgTVBMUy1UUCBSZXF1aXJlbWVudHMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgSnVseSAyMDA4PEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OzxCUj4N CiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHdoaWxlIHV0aWxpemluZyBuZXR3b3JrIHJlc291cmNlcyBlZmZpY2llbnRseSBhbmQg cmVsaWFibHkuPEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBv Jm5ic3A7IE1QTFMtVFAgU0hPVUxEIHN1cHBvcnQgb2ZmLXBhdGggKG91dC1vZi1iYW5kKSBjb250 cm9sIGFuZDxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IG1hbmFnZW1lbnQgcGxhbmVzLjxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJz cDsmbmJzcDsgbyZuYnNwOyBUaGUgTVBMUy1UUCBjb250cm9sIHBsYW5lIE1VU1QgYmUgaW5kZXBl bmRlbnQgb2YgYW55IHBhcnRpY3VsYXI8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBjbGllbnQgb3Igc2VydmVyIGxheWVyIGNvbnRyb2wgcGxhbmUuPEJS Pg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBvJm5ic3A7IFRoZSBj b250cm9sIHBsYW5lIFNIT1VMRCBmYWNpbGl0YXRlIHRoZSBpbXBsZW1lbnRhdGlvbiBvZiB0aGU8 QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzZXJ2aWNl IGJ5IHByb3ZpZGluZyBlbmQtdG8tZW5kIHNlYW1sZXNzIGNvbm5lY3Rpdml0eSBhbmQgc2Vydmlj ZTxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFzc3Vy YW5jZS48QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG8mbmJz cDsgVGhlIE1QTFMtVFAgY29udHJvbCBwbGFuZSBNVVNUIHN1cHBvcnQgZXN0YWJsaXNoaW5nIGFs bCB0aGU8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBj b25uZWN0aXZpdHkgcGF0dGVybnMgZGVmaW5lZCBmb3IgdGhlIE1QTFMtVFAgdHJhbnNwb3J0IHBs YW5lPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKGUu Zy4sIHVuaS1kaXJlY3Rpb25hbCBhbmQgYmlkaXJlY3Rpb25hbCBQMlAsIHVuaS1kaXJlY3Rpb25h bDxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFAyTVAs IGV0Yy4pIGluY2x1ZGluZyBjb25maWd1cmF0aW9uIG9mIHByb3RlY3Rpb24gZnVuY3Rpb25zIGFu ZDxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFueSBh c3NvY2lhdGVkIG1haW50ZW5hbmNlIGZ1bmN0aW9ucy48QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgVGhlIE1QTFMtVFAgY29udHJvbCBwYW5lIG11 c3Qgc3VwcG9ydCB0aGUgY29uZmlndXJhdGlvbiBhbmQ8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBtb2RpZmljYXRpb24gb2YgT0FNIG1haW50ZW5hbmNl IHBvaW50cyBhcyB3ZWxsIGFzIHRoZSBhY3RpdmF0aW9uLzxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRlYWN0aXZhdGlvbiBvZiBPQU0gd2hlbiB0aGUg Y29ubmVjdGlvbiBpcyBlc3RhYmxpc2hlZCBvcjxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1vZGlmaWVkLjxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZn dDsmbmJzcDsmbmJzcDsmbmJzcDsgbyZuYnNwOyBBbiBNUExTLVRQIGNvbnRyb2wgcGxhbmUgTVVT VCBzdXBwb3J0IHRvcG9sb2d5IGhpZGluZyBhbmQgYWRkcmVzczxCUj4NCiZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluZGVwZW5kZW5jZSBiZXR3ZWVuIGRvbWFp bnMuPEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBvJm5ic3A7 IEF0IHRoZSBib3VuZGFyeSBvZiBhIGRvbWFpbiBhbiBNUExTLVRQIGNvbnRyb2wgcGxhbmUgTVVT VCBzdXBwb3J0PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgdW5pcXVlIG5hbWVzIG9yIGFkZHJlc3NlcyBpZGVudGlmeWluZyBib3VuZGFyeSBwb2ludHMg dG8gYmU8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBp bnRlcmNvbm5lY3RlZC48QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7IG8mbmJzcDsgQXQgdGhlIGJvdW5kYXJ5IG9mIGEgZG9tYWluIGFuIE1QTFMtVFAgY29udHJv bCBwbGFuZSBtdXN0IHN1cHBvcnQ8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBncm91cCBuYW1lcyBvciBhZGRyZXNzZXMgaWRlbnRpZnlpbmcgc2V0cyBv ZiBib3VuZGFyeSBwb2ludHMgdG8gYmU8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBpbnRlcmNvbm5lY3RlZC48QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgTVBMUy1UUCBsYXllciBuZXR3b3JrIGFjY2Vz cyBwb2ludHMgKG9yIGNvbm5lY3Rpb24gcG9pbnRzIHRoYXQ8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwcm94eSBmb3IgYWNjZXNzIHBvaW50cykgU0hP VUxEIGJlIGFibGUgdG8gYmUgYXNzaWduZWQgbmFtZXMgd2hpY2g8QlI+DQomZ3Q7Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhcmUgYXZhaWxhYmxlIHRvIGNsaWVudHMg dG8gaWRlbnRpZnkgZW5kcG9pbnRzIGluIGNhbGwgb3I8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjb25uZWN0aW9uIHJlcXVlc3RzLjxCUj4NCiZndDsm Z3Q7PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgbyZuYnNwOyBBbiBNUExTLVRQIGNv bnRyb2wgcGxhbmUgTVVTVCBzdXBwb3J0IHRyYW5zbGF0aW9uIGJldHdlZW48QlI+DQomZ3Q7Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBleHRlcm5hbGx5IHZpc2libGUg ZW5kcG9pbnQgbmFtZXMgYW5kIGludGVybmFsIG5ldHdvcmsgYWRkcmVzc2VzLjxCUj4NCiZndDsm Z3Q7PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgbyZuYnNwOyBBbiBNUExTLVRQIGNv bnRyb2wgcGxhbmUgTVVTVCBzdXBwb3J0IGNvbnN0cmFpbnQtYmFzZWQgcm91dGU8QlI+DQomZ3Q7 Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjYWxjdWxhdGlvbi48QlI+ DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgQW4gTVBM Uy1UUCBjb250cm9sIHBsYW5lIE1VU1Qgc3VwcG9ydCBwcm92aXNpb25pbmcgYW5kIGFwcGxpY2F0 aW9uPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb2Yg cm91dGluZyBjb25zdHJhaW50IHBvbGljaWVzLjxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDs8 QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsgTml2ZW4tSmVua2lucywg ZXQgYWwuJm5ic3A7Jm5ic3A7Jm5ic3A7IEV4cGlyZXMgSmFudWFyeSAyLCAyMDA5Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFtQYWdlIDldPEJSPg0KJmd0OyZndDsgDDxCUj4NCiZn dDsmZ3Q7IEludGVybmV0LURyYWZ0Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE1QTFMtVFAgUmVxdWlyZW1lbnRzJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEp1bHkgMjAwODxCUj4NCiZndDsmZ3Q7 PEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBvJm5ic3A7IEFu IE1QTFMtVFAgY29udHJvbCBwbGFuZSBNVVNUIHN1cHBvcnQgcHJlLXByb3Zpc2lvbmVkIGNvbm5l Y3Rpb248QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBw cm90ZWN0aW9uLjxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsg SW4gc29tZSBzaXR1YXRpb25zIGl0IGlzIGltcHJhY3RpY2FsIHRvIGV4cGVjdCBhY2NlcHRhYmxl IHJlY292ZXJ5PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgcGVyZm9ybWFuY2UgdG8g YmUgYWNoaWV2ZWQgdXNpbmcgZHluYW1pYyByZWNhbGN1bGF0aW9uIG9mIGNvbm5lY3Rpb248QlI+ DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyByb3V0ZXMuJm5ic3A7IEZvciB0aGlzIHJlYXNv biwgaXQgaXMgbmVjZXNzYXJ5IHRvIGFsbG93IGZvciBwcmUtcGxhbm5pbmc8QlI+DQomZ3Q7Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyBvZiBwcm90ZWN0aW9uIHJvdXRlcyBmb3Igc2VsZWN0ZWQgY29u bmVjdGlvbnMuPEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBv Jm5ic3A7IFRoZSBNUExTLVRQIGNvbnRyb2wgcGxhbmUgTVVTVCBzdXBwb3J0IGZhc3QgcmVzdG9y YXRpb24uPEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyBUT006IERlZmluZSB3aGF0ICZxdW90 O2Zhc3QmcXVvdDsgbWVhbnM/PEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyBvJm5ic3A7IEFuIE1QTFMtVFAgY29udHJvbCBwbGFuZSBNVVNUIHNjYWxlIGdyYWNl ZnVsbHkgdG8gc3VwcG9ydCBhIGxhcmdlPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgbnVtYmVyIG9mIGNvbm5lY3Rpb25zLjxCUj4NCiZndDsmZ3Q7PEJS Pg0KJmd0OyZndDsgVE9NOiBEZWZpbmUgJnF1b3Q7bGFyZ2UmcXVvdDsgYW5kICZxdW90O3NjYWxl JnF1b3Q7IGhlcmU/PEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyBbSW5jbHVkZSBzb21lIG51bWJlcnMgdG8gaW5kaWNhdGUgaG93IGxhcmdlIHRoZSBDUCBpcyBl eHBlY3RlZCB0bzxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNjYWxlIHRvP108QlI+ DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgQW4gTVBM Uy1UUCBjb250cm9sIHBsYW5lIE1VU1QgY2xlYXJseSBkaXN0aW5ndWlzaCByZXNvdXJjZXM8QlI+ DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBiZWxvbmdpbmcg dG8gdGhlIE1QTFMtVFAgbGF5ZXIgbmV0d29yayBmcm9tIHRob3NlIGluIG90aGVyIGxheWVyPEJS Pg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbmV0d29ya3Mg dGhhdCBtYXkgYWxzbyBiZSB1bmRlciBjb250cm9sIHBsYW5lIGNvbnRyb2wuPEJSPg0KJmd0OyZn dDs8QlI+DQomZ3Q7Jmd0OyBUT006IERvIHlvdSBtZWFuIHVuZGVyIHRoZSBzYW1lIGNvbnRyb2wg cGxhbmUgb3IgYSBkaWZmZXJlbnQgb25lIChvcjxCUj4NCiZndDsmZ3Q7IGJvdGgpPzxCUj4NCiZn dDsmZ3Q7PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgbyZuYnNwOyBBbiBNUExTLVRQ IGNvbnRyb2wgcGxhbmUgTVVTVCBzdXBwb3J0IHRoZSBpbmRlcGVuZGVudDxCUj4NCiZndDsmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlkZW50aWZpY2F0aW9uIG9mIGxv Z2ljYWxseSBkaXN0aW5jdCBjb250cm9sIHBsYW5lIGVsZW1lbnRzLjxCUj4NCiZndDsmZ3Q7PEJS Pg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgbyZuYnNwOyBJdCBNVVNUIGJlIHBvc3NpYmxl IHRvIGlkZW50aWZ5IGFuZCBwcm92aXNpb24gdGhlc2UgZWxlbWVudHM8QlI+DQomZ3Q7Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpbmRlcGVuZGVudGx5LCBpbiBvcmRl ciB0byByZW9yZ2FuaXplIHRoZSBjb250cm9sIHBsYW5lIGNvbXBvbmVudHM8QlI+DQomZ3Q7Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB3aXRob3V0IGltcGFjdGluZyB0 aGUgZGF0YSBwbGFuZSBzZXJ2aWNlcyBhbmQgdmljZS12ZXJzYS48QlI+DQomZ3Q7Jmd0OzxCUj4N CiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFyY2hpdGVjdHVyYWxseSBkaXN0aW5jdCBlbGVt ZW50cyBpbiBhIGNvbnRyb2wgcGxhbmUgaW5jbHVkZTogbm9kZXM8QlI+DQomZ3Q7Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyBhbmQgbGlua3MsIGNvbnRyb2wgcGxhbmUgZnVuY3Rpb25hbCBjb21wb25l bnRzLCBwcm90b2NvbCBjb250cm9sbGVycyw8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyBldGMuPEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBvJm5i c3A7IEFuIE1QTFMtVFAgY29udHJvbCBwbGFuZSBTSE9VTEQgcHJvdmlkZSBhIGNvbW1vbiBjb250 cm9sIG1lY2hhbmlzbTxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGZvciBhcmNoaXRlY3R1cmFsbHkgc2ltaWxhciBvcGVyYXRpb25zLjxCUj4NCiZndDsm Z3Q7PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgbyZuYnNwOyBBbiBNUExTLVRQIGNv bnRyb2wgcGxhbmUgTVVTVCBzdXBwb3J0IG1lY2hhbmlzbXMgZm9yIHBhcnRpdGlvbmluZzxCUj4N CiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSBuZXR3b3Jr IHVuZGVyIGNvbnRyb2wgaW50byBzZXBhcmF0ZSBwZWVyIG9yIGhpZXJhcmNoaWNhbDxCUj4NCiZn dDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvbnRyb2wgZG9tYWlu cy48QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG8mbmJzcDsg VG8gZW5hYmxlIHRoZSBkZXBsb3ltZW50IG9mIGEgdW5pZmllZCBjb250cm9sIHBsYW5lIGFpbWVk IGF0PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY29u dHJvbGxpbmcgdGhlIHNldCBvZiB0cmFuc3BvcnQgdGVjaG5vbG9naWVzIHVzZWQgaW4gYSB0cmFu c3BvcnQ8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBu ZXR3b3JrLCB0aGUgTVBMUy1UUCBjb250cm9sIHBsYW5lIE1VU1QgYWxzbyBiZSBhcHBsaWNhYmxl IHRvPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb3Ro ZXIgdHJhbnNwb3J0IGxheWVyIG5ldHdvcmtzIGFuZCBwcm92aWRlIGNvbW1vbiBvcGVyYXRpb25z PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYWNyb3Nz IG11bHRpcGxlIGxheWVycy4mbmJzcDsgSW4gb3JkZXIgdG8gbWFpbnRhaW4gaW5kZXBlbmRlbmNl IGJldHdlZW48QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBNUExTLVRQIGFuZCBpdHMgcmVzcGVjdGl2ZSBjbGllbnQgYW5kIHNlcnZlciBsYXllciBuZXR3 b3JrPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2Vw YXJhdGUgY29udHJvbCBwbGFuZSBpbnN0YW5jZXMgU0hPVUxEIGJlIHVzZWQgdG8gY29udHJvbCBh IHNldDxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9m IHRyYW5zcG9ydCBsYXllciBuZXR3b3Jrcy48QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7PEJS Pg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsgTml2 ZW4tSmVua2lucywgZXQgYWwuJm5ic3A7Jm5ic3A7Jm5ic3A7IEV4cGlyZXMgSmFudWFyeSAyLCAy MDA5Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFtQYWdlIDEwXTxCUj4NCiZndDsmZ3Q7IAw8 QlI+DQomZ3Q7Jmd0OyBJbnRlcm5ldC1EcmFmdCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBNUExTLVRQIFJlcXVpcmVtZW50 cyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBKdWx5IDIwMDg8QlI+DQom Z3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgbyZu YnNwOyBNUExTLVRQIFNIT1VMRCBkZXRlY3QgYW5kIHJlY292ZXIgZnJvbSBjb250cm9sIHBsYW5l IGZhaWx1cmVzIGFuZDxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGRlZ3JhZGF0aW9ucyB1c2luZyBncmFjZWZ1bCBvcGVyYXRpb25zLjxCUj4NCiZndDsm Z3Q7PEJSPg0KJmd0OyZndDsgMi41LiZuYnNwOyBOZXR3b3JrIE1hbmFnZW1lbnQgKE5NKSByZXF1 aXJlbWVudHM8QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG8m bmJzcDsgTVBMUy1UUCBNVVNUIG9wZXJhdGUgdW5kZXIgYSBjb21tb24gb3BlcmF0aW9uLCBjb250 cm9sIGFuZDxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IG1hbmFnZW1lbnQgcGFyYWRpZ20gd2l0aCByZXNwZWN0IHRvIG90aGVyIHRyYW5zcG9ydCB0ZWNo bm9sb2dpZXM8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAoZS5nLiZuYnNwOyBTREgsIE9UTiBvciBXRE0pLjxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZn dDsmbmJzcDsmbmJzcDsmbmJzcDsgbyZuYnNwOyBBbiBNUExTLVRQIG5ldHdvcmsgTVVTVCBiZSBh YmxlIHRvIGJlIG9wZXJhdGVkIHdpdGggYSBjZW50cmFsaXplZDxCUj4NCiZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE5NUyBzeXN0ZW0uPEJSPg0KJmd0OyZndDs8 QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBvJm5ic3A7IEFuIE1QTFMtVFAgbmV0d29y ayBTSE9VTEQgYmUgYWJsZSB0byBiZSBvcGVyYXRlZCBieSBhIGNlbnRyYWxpemVkPEJSPg0KJmd0 OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTk1TIHN5c3RlbSB3aXRo IHRoZSBzdXBwb3J0IG9mIGEgZGlzdHJpYnV0ZWQgY29udHJvbCBwbGFuZS48QlI+DQomZ3Q7Jmd0 OzxCUj4NCiZndDsmZ3Q7IFRPTTogSSBkb24ndCBrbm93IHdoYXQgdGhpcyBtZWFucyBvciB0aGUg b25lIGFib3ZlIGl0LCBvciBob3cgdGhpczxCUj4NCiZndDsmZ3Q7IHJlcXVpcmVtZW50IHdvdWxk IHRyYW5zbGF0ZSBpbnRvIGFueXRoaW5nIHRhbmdpYmxlIGluIHRoZSBNUExTLVRQPEJSPg0KJmd0 OyZndDsgcHJvdG9jb2wgZGVzaWducy4mbmJzcDsgSSBzdWdnZXN0IGl0IGJlIHJlbW92ZWQuPEJS Pg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBvJm5ic3A7IFRoZSBN UExTLVRQIG1hbmFnZW1lbnQgcGxhbmUgTVVTVCBOT1QgZGVwZW5kIG9uIGEgc3BlY2lmaWMgY2xp ZW50PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbGF5 ZXIgbWFuYWdlbWVudCBwbGFuZS48QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7IFRPTTogVGhp cyBpcyBhIG5vbi1zZXF1aXR1ciBpZiB5b3UgYXNrIG1lOyBwbGVhc2Ugc3RyaWtlIGl0LjxCUj4N CiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgbyZuYnNwOyBUaGUgTVBM Uy1UUCBtYW5hZ2VtZW50IHBsYW5lIE1VU1Qgc3VwcG9ydCB0aGUgY29uZmlndXJhdGlvbiBhbmQ8 QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBtb2RpZmlj YXRpb24gb2YgT0FNIG1haW50ZW5hbmNlIHBvaW50cyBhcyB3ZWxsIGFzIHRoZSBhY3RpdmF0aW9u LzxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRlYWN0 aXZhdGlvbiBvZiBPQU0gd2hlbiB0aGUgY29ubmVjdGlvbiBpcyBlc3RhYmxpc2hlZCBvcjxCUj4N CiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1vZGlmaWVkLjxC Uj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgRm9yIHRoZSBjb21w bGV0ZSBzZXQgb2YgcmVxdWlyZW1lbnRzIHJlbGF0ZWQgdG8gTk0gZnVuY3Rpb25hbGl0eSBmb3I8 QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBNUExTLVRQLCBzZWUgdGhlIE1QTFMtVFAg Tk0gcmVxdWlyZW1lbnRzIGRvY3VtZW50IFtSRUZdLjxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZn dDsgMi42LiZuYnNwOyBPQU0gcmVxdWlyZW1lbnRzPEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyBvJm5ic3A7IE1QTFMtVFAgU0hPVUxEIHByb3ZpZGUgYSBjb21w cmVoZW5zaXZlIHNldCBvZiBjYXBhYmlsaXRpZXMgKHRoYXQ8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhcmUgaW5kZXBlbmRlbnQgb2YgYW5kIGFnbm9z dGljIHRvIHRoZSB0cmFuc21pdHRlZCBjbGllbnQ8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzZXJ2aWNlcykgdG8gc3VwcG9ydCBmYXVsdCBtYW5hZ2Vt ZW50LCBwZXJmb3JtYW5jZSBtb25pdG9yaW5nIChvZjxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSBNUExTLVRQIG5ldHdvcmsgYW5kIHRoZSBzZXJ2 aWNlcyksIHByb3RlY3Rpb24gc3dpdGNoaW5nLCBmYXVsdDxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxvY2FsaXphdGlvbiwgc2lnbmFsIHF1YWxpdHkg bWVhc3VyZW1lbnQsIGV0Yy48QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IG8mbmJzcDsgQSBtZWNoYW5pc20gU0hPVUxEIGJlIHN1cHBvcnRlZCB0byBkZXRlY3Qs IGRpYWdub3NlIGFuZCBlbmFibGU8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyByZWNvdmVyeSBmcm9tIGZhY2lsaXR5IGFuZCBlcXVpcG1lbnQgZmFpbHVy ZXMgYW5kIHBlcmZvcm1hbmNlPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgZGVncmFkYXRpb25zIGFjY29yZGluZyB0byB0aGUgcmVxdWlyZW1lbnRzIG9m IHRoZSBzZXJ2aWNlLjxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJz cDsgbyZuYnNwOyBNUExTLVRQIE9BTSBNVVNUIGJlIGFibGUgdG8gb3BlcmF0ZSB3aXRob3V0IElQ IGZ1bmN0aW9uYWxpdHkgYW5kPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgd2l0aG91dCByZWx5aW5nIG9uIGNvbnRyb2wgYW5kL29yIG1hbmFnZW1lbnQg cGxhbmVzLjxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgRm9y IHRoZSBjb21wbGV0ZSBzZXQgb2YgcmVxdWlyZW1lbnRzIHJlbGF0ZWQgdG8gT0FNIGZ1bmN0aW9u YWxpdHkgZm9yPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgTVBMUy1UUCwgc2VlIHRo ZSBNUExTLVRQIE9BTSByZXF1aXJlbWVudHMgZG9jdW1lbnQgW1JFRl0uPEJSPg0KJmd0OyZndDs8 QlI+DQomZ3Q7Jmd0OyBUT006IEkgc3VnZ2VzdCB5b3UganVzdCByZW1vdmUgdGhlc2UgdHdvIHNl Y3Rpb25zIGFuZCByZWZlciB0byB0aGU8QlI+DQomZ3Q7Jmd0OyBPQU0vTWFuYWdlbWV0biBkb2N1 bWVudHMuPEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyAyLjcuJm5ic3A7IE5ldHdvcmsgcGVy Zm9ybWFuY2UgbWFuYWdlbWVudCAoUE0pIHJlcXVpcmVtZW50czxCUj4NCiZndDsmZ3Q7PEJSPg0K Jmd0OyZndDs8QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDs8QlI+DQom Z3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7IE5pdmVuLUplbmtpbnMsIGV0IGFsLiZuYnNwOyZuYnNwOyZu YnNwOyBFeHBpcmVzIEphbnVhcnkgMiwgMjAwOSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBb UGFnZSAxMV08QlI+DQomZ3Q7Jmd0OyAMPEJSPg0KJmd0OyZndDsgSW50ZXJuZXQtRHJhZnQmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgTVBMUy1UUCBSZXF1aXJlbWVudHMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgSnVseSAyMDA4PEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgTVBMUy1UUCBNVVNUIHN1cHBvcnQgdHJhZmZp Yy1lbmdpbmVlcmluZyBjYXBhYmlsaXRpZXMgd2l0aDxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRyYWZmaWMtIGFuZC9vciByZXNvdXJjZS1vcmllbnRl ZCBwZXJmb3JtYW5jZSBvYmplY3RpdmVzLjxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsgVE9N OiBXaGF0IGFyZSBwZXJmb3JtYW5jZSBvYmplY3RpdmVzPyZuYnNwOyBEbyB5b3UgbWVhbiB0cmFm ZmljIHByb2ZpbGVzIHN1Y2g8QlI+DQomZ3Q7Jmd0OyBhcyBRb1MvYmFuZHdpZHRoPzxCUj4NCiZn dDsmZ3Q7PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgbyZuYnNwOyBNUExTLVRQIE1V U1Qgc3VwcG9ydCBhIG1ldGhvZCB0byBvZmZlciBwYWNrZXQgbG9zcyBvYmplY3RpdmVzPEJSPg0K Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY29tcGFyYWJsZSB0 byB0aG9zZSBpbiBURE0gdHJhbnNwb3J0IG5ldHdvcmtzIChvbmx5IGR1ZSB0byBiaXQ8QlI+DQom Z3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBlcnJvcnMpLjxCUj4N CiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgRm9yIHRoZSBjb21wbGV0 ZSBzZXQgb2YgcmVxdWlyZW1lbnRzIHJlbGF0ZWQgdG8gUE0gZnVuY3Rpb25hbGl0eSBmb3I8QlI+ DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBNUExTLVRQLCBzZWUgdGhlIE1QTFMtVFAgT0FN IHJlcXVpcmVtZW50cyBkb2N1bWVudCBbUkVGXS48QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7 IFRPTTogQWdhaW4sIEkgc3VnZ2VzdCB5b3UgcHVudCBvbiB0aGlzIGVudGlyZSBzZWN0aW9uIGFu ZCBtb3ZlIGl0IHRvIHRoZTxCUj4NCiZndDsmZ3Q7IE9BTSBkb2MuPEJSPg0KJmd0OyZndDs8QlI+ DQomZ3Q7Jmd0OyAyLjguJm5ic3A7IFByb3RlY3Rpb24gJmFtcDsgU3Vydml2YWJpbGl0eSByZXF1 aXJlbWVudHM8QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE5l dHdvcmsgc3Vydml2YWJpbGl0eSBwbGF5cyBhIGNyaXRpY2FsIGZhY3RvciBpbiB0aGUgZGVsaXZl cnkgb2Y8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyByZWxpYWJsZSBzZXJ2aWNlcy4m bmJzcDsgTmV0d29yayBhdmFpbGFiaWxpdHkgaXMgYSBzaWduaWZpY2FudCBjb250cmlidXRvcjxC Uj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRvIHJldmVudWUgYW5kIHByb2ZpdC4mbmJz cDsgU2VydmljZSBndWFyYW50ZWVzIGluIHRoZSBmb3JtIG9mIFNMQXM8QlI+DQomZ3Q7Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyByZXF1aXJlIGEgcmVzaWxpZW50IG5ldHdvcmsgdGhhdCByYXBpZGx5 IGRldGVjdHMgZmFjaWxpdHkgb3Igbm9kZTxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGZhaWx1cmVzIGFuZCByZXN0b3JlcyBuZXR3b3JrIG9wZXJhdGlvbiBpbiBhY2NvcmRhbmNlIHdp dGggdGhlIHRlcm1zPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgb2YgdGhlIFNMQS48 QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZSByZXF1aXJl bWVudHMgaW4gdGhpcyBzZWN0aW9uIHVzZSBvZiB0aGUgcmVjb3ZlcnkgdGVybWlub2xvZ3k8QlI+ DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBkZWZpbmVkIGluIFJGQyA0NDI3W1JGQzQ0Mjdd LjxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgbyZuYnNwOyBN UExTLVRQIFNIT1VMRCBzdXBwb3J0IHRyYW5zcG9ydCBuZXR3b3JrIHN0eWxlIHByb3RlY3Rpb248 QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7IFRPTTogSSB3b3VsZCBtYWtlIHRoaXMgYSBNVVNU LjxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgc3dpdGNoaW5nIG1lY2hhbmlzbXMgKHRhbmRlbSBuZXR3b3JrIGNvbm5lY3Rpb24g cHJvdGVjdGlvbiwgTFNQPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgcHJvdGVjdGlvbiBhbmQgUFcgcHJvdGVjdGlvbikgdG8gcHJvdmlkZSB0aGUgc3Vi LTUwbXMgcmVjb3Zlcnk8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB0aW1lIHJlcXVpcmVkIHRvIG1haW50YWluIGN1c3RvbWVyIHRyYW5zcGFyZW5jeSwg ZXZlbiB3aGVuPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgdGhvdXNhbmRzIG9mIHNlcnZpY2VzIGFyZSBzaW11bHRhbmVvdXNseSBhZmZlY3RlZCBieSBh IGZhaWx1cmUuPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgW0lzIHN1Yi01MG1zIHJlYWxseSBhIHJlcXVpcmVtZW50LCBkbyB3ZSB3YW50IHRvIGNsYXJp ZnkgdGhpczxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGZ1cnRoZXIgLSBpcyBpdCBzdWItNTBtcyBlbmQgdG8gZW5kLCBvciBwZXIgbGluaz9dPEJSPg0K Jmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBvPEJSPg0KJmd0OyZndDs8 QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAqJm5ic3A7 IE1QTFMtVFAgcmVjb3ZlcnkgbWVjaGFuaXNtcyBTSE9VTEQgYmUgYXBwbGljYWJsZSBhdCB2YXJp b3VzPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgbGV2ZWxzIHRocm91Z2hvdXQgdGhlIG5ldHdvcmssIFNQQU4sIHRhbmRl bSBjb25uZWN0aW9uIGFuZCBlbmQtPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdG8tZW5kLjxCUj4NCiZndDsmZ3Q7PEJS Pg0KJmd0OyZndDsgVE9NOiBUaGlzIHNlbnRlbmNlIGRvZXNuJ3QgcGFyc2UuIFBsZWFzZSByZS13 cml0ZS48QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jm5ic3A7IEFueSByZWNvdmVyeSBtZWNo YW5pc20gdXNlZCBpbiBhIHRhbmRlbSBjb25uZWN0aW9uPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTVVTVCBiZSBpbmRl cGVuZGVudCBvZiBvdGhlciB0YW5kZW0gY29ubmVjdGlvbnMuPEJSPg0KJmd0OyZndDs8QlI+DQom Z3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAqJm5ic3A7IE1QTFMt VFAgU0hPVUxEIHN1cHBvcnQgbWVjaGFuaXNtcyB0aGF0IGtlZXAgdHJhZmZpYyBmbG93aW5nPEJS Pg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgd2hpbGUgdGhlIG5ldHdvcmsgcmVjb3ZlcnMgZnJvbSBmYWlsdXJlcy48QlI+DQom Z3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7IFRPTTogSSB3b3VsZCBzYXkgdGhpcyBpcyBhIE1VU1QuPEJS Pg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAqJm5ic3A7IE1QTFMtVFAgU0hPVUxEIHN1cHBvcnQgbmV0d29yayByZXN0b3JhdGlvbiBt ZWNoYW5pc21zPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgY29udHJvbGxlZCBieSBhIGRpc3RyaWJ1dGVkIGNvbnRyb2wg cGxhbmUgYW5kL29yIGJ5IGE8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBtYW5hZ2VtZW50IHBsYW5lIGJhc2VkLjxCUj4N CiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsgVE9NOiBJIHdvdWxkIHNheSB0aGlzIGlzIGEgTVVTVC48 QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgKjxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKyZuYnNwOyBU aGUgcmVzdG9yYXRpb24gcmVzb3VyY2VzIE1BWSBiZSBwcmUtcGxhbm5lZCBhbmQgc2VsZWN0ZWQg YTxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHByaW9yaSwgb3IgY29tcHV0ZWQgYWZ0ZXIg ZmFpbHVyZSBvY2N1cnJlbmNlLjxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7 Jmd0OzxCUj4NCiZndDsmZ3Q7IE5pdmVuLUplbmtpbnMsIGV0IGFsLiZuYnNwOyZuYnNwOyZuYnNw OyBFeHBpcmVzIEphbnVhcnkgMiwgMjAwOSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBbUGFn ZSAxMl08QlI+DQomZ3Q7Jmd0OyAMPEJSPg0KJmd0OyZndDsgSW50ZXJuZXQtRHJhZnQmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgTVBMUy1UUCBSZXF1aXJlbWVudHMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgSnVseSAyMDA4PEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICsm bmJzcDsgTVBMUy1UUCBNQVkgc3VwcG9ydCBzaGFyZWQtbWVzaCByZXN0b3JhdGlvbi48QlI+DQom Z3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICsmbmJzcDsgTVBMUy1UUCBTSE9VRCBzdXBwb3J0IHNvZnQgTFNQ IHJlc3RvcmF0aW9uLjxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKyZuYnNwOyBNUExTLVRQIE1B WSBzdXBwb3J0IGhhcmQgTFNQIHJlc3RvcmF0aW9uLjxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg KyZuYnNwOyBUaGUgcmVzdG9yYXRpb24gbWVjaGFuaXNtIE1VU1QgYmUgYXBwbGljYWJsZSB0byBh bnk8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0b3BvbG9neS48QlI+DQomZ3Q7Jmd0OzxC Uj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICsmbmJzcDsgUmVzdG9yYXRpb24gcHJpb3JpdHkgTUFZIGJlIGltcGxlbWVudGVk IHRvIGRldGVybWluZSB0aGU8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBvcmRlciBpbiB3 aGljaCBjb25uZWN0aW9ucyBzaG91bGQgYmUgcmVzdG9yZWQgKHRvIG1pbmltaXplPEJSPg0KJmd0 OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgc2VydmljZSByZXN0b3JhdGlvbiB0aW1lIGFzIHdlbGwgYXMg dG8gZ2FpbiBhY2Nlc3MgdG88QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhdmFpbGFibGUg c3BhcmUgY2FwYWNpdHkgb24gdGhlIGJlc3QgcGF0aHMpLiZuYnNwOyBQcmVlbXB0aW9uPEJSPg0K Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcHJpb3JpdHkgTUFZIGJlIHVzZWQgaW4gdGhlIGV2ZW50 IHRoYXQgbm90IGFsbCBjb25uZWN0aW9uczxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNh biBiZSByZXN0b3JlZCwgaW4gd2hpY2ggY2FzZSBjb25uZWN0aW9ucyB3aXRoIGxvd2VyPEJSPg0K Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcHJlZW1wdGlvbiBwcmlvcml0eSBzaG91bGQgYmUgcmVs ZWFzZWQuPEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyArJm5ic3A7IFRoZSByZXN0b3JhdGlvbiBt ZWNoYW5pc20gU0hPVUxEIG9wZXJhdGUgaW4gc3luZXJneSB3aXRoPEJSPg0KJmd0OyZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgb3RoZXIgdHJhbnNwb3J0IG5ldHdvcmsgdGVjaG5vbG9naWVzIChTREgsIE9U TiwgV0RNKS48QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICombmJzcDsgTVBMUy1UUCBTSE9VTEQgc3VwcG9ydCBkYXRhIHBsYW5l IGRyaXZlbiBwcm90ZWN0aW9uIG1lY2hhbmlzbXM8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAod2l0aG91dCBhbnkgZGVw ZW5kZW5jeSBvbiBhIGNvbnRyb2wgcGxhbmUgb3IgSVAgcHJvdG9jb2xzKSB0bzxCUj4NCiZndDsm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGVuYWJsZSBmYXN0IHJlY292ZXJ5IGZyb20gZmFpbHVyZSwgYW5kIHRoZXJlYnkgdG8gZW5oYW5j ZSB0aGU8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyByZWxpYWJpbGl0eSBhbmQgYXZhaWxhYmlsaXR5IHBlcmZvcm1hbmNl IG9mIE1QTFMtVFAgbmV0d29ya3MuPEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAqPEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAr Jm5ic3A7IE1QTFMtVFAgcHJvdGVjdGlvbiBtZWNoYW5pc21zIFNIT1VMRCBiZSBhcHBsaWVkIHRv IExTUHMgYW5kPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUFdzLjxCUj4NCiZndDsmZ3Q7 PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgKyZuYnNwOyBNUExTLVRQIE1VU1Qgc3VwcG9ydCBtZWNoYW5pc21zIHRoYXQg cmFwaWRseSBkZXRlY3QsIGxvY2F0ZSw8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBub3Rp ZnkgYW5kIHJlbWVkeSBuZXR3b3JrIGZhdWx0cy48QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICsm bmJzcDsgTVBMUy1UUCBNVVNUIHN1cHBvcnQgMToxIGJpZGlyZWN0aW9uYWwgcHJvdGVjdGlvbiBz d2l0Y2hpbmcuPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlIHByb3RlY3Rpb24gc3Rh dGUgb2YgYm90aCBlbmRzIG9mIHRoZSBwcm90ZWN0ZWQgZW50aXR5PEJSPg0KJmd0OyZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgTVVTVCBiZSBzeW5jaHJvbml6ZWQuPEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7 Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyArJm5ic3A7IE1QTFMtVFAgTUFZIHN1cHBvcnQgMSsxIHVuaWRpcmVjdGlvbmFsIHByb3RlY3Rp b24gc3dpdGNoaW5nLjxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKyZuYnNwOyBNUExTLVRQIHBy b3RlY3Rpb24gbWVjaGFuaXNtcyBNVVNUIGJlIGFwcGxpY2FibGUgdG8gYm90aDxCUj4NCiZndDsm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBvaW50LXRvLXBvaW50IGFuZCBwb2ludC10by1tdWx0aXBvaW50 IGNvbm5lY3Rpb25zLjxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKyZuYnNwOyBJdCBTSE9VTEQg YmUgcG9zc2libGUgdG8gYWNoaWV2ZSBwcm90ZWN0aW9uIGF0IHRoZSBNUExTLVRQPEJSPg0KJmd0 OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgbGF5ZXIgYXMgZmFzdCBhcyBwb3NzaWJsZSAoc3ViamVjdCB0 byB0aGUgdGVtcG9yYWw8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZXNvbHV0aW9uIG9m IHRoZSBkZWZlY3QgZGV0ZWN0aW9uIG1lY2hhbmlzbSkuPEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7 Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyArJm5ic3A7IFByb3RlY3Rpb24gcmF0aW8gTVVTVCBiZSBvZiAxMDAlLCBpLmUuLCAxMDAlIG9m IGltcGFpcmVkPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgd29ya2luZyB0cmFmZmljIE1V U1QgYmUgcHJvdGVjdGVkIGZvciBhIGZhaWx1cmUgb24gYSBzaW5nbGU8QlI+DQomZ3Q7Jmd0OzxC Uj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyBOaXZlbi1KZW5raW5zLCBl dCBhbC4mbmJzcDsmbmJzcDsmbmJzcDsgRXhwaXJlcyBKYW51YXJ5IDIsIDIwMDkmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgW1BhZ2UgMTNdPEJSPg0KJmd0OyZndDsgDDxCUj4NCiZndDsmZ3Q7 IEludGVybmV0LURyYWZ0Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE1QTFMtVFAgUmVxdWlyZW1lbnRzJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEp1bHkgMjAwODxCUj4NCiZndDsmZ3Q7PEJSPg0K Jmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB3b3JraW5nIExTUC48QlI+DQom Z3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICsmbmJzcDsgT3BlcmF0b3IgcmVxdWVzdHMgZm9yIG1hbnVhbCBj b250cm9sIG9mIHByb3RlY3Rpb24gc3dpdGNoaW5nPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgc3VjaCBhcyBjbGVhciwgbG9ja291dCBvZiBwcm90ZWN0aW9uLCBmb3JjZWQtc3dpdGNoIGFu ZDxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1hbnVhbC1zd2l0Y2ggY29tbWFuZHMgTVVT VCBiZSBzdXBwb3J0ZWQuJm5ic3A7IFByaW9yaXRpemVkPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgcHJvdGVjdGlvbiBiZXR3ZWVuIFNpZ25hbCBGYWlsIChTRiksIFNpZ25hbCBEZWdyYWRh dGlvbiAoU0QpPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYW5kIG9wZXJhdG9yIHN3aXRj aCByZXF1ZXN0cyBNVVNUIGJlIHN1cHBvcnRlZC48QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICsm bmJzcDsgTVBMUy1UUCBwcm90ZWN0aW9uIG1lY2hhbmlzbXMgTVVTVCBzdXBwb3J0IHJldmVydGl2 ZSBhbmQ8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBub24tcmV2ZXJ0aXZlIGJlaGF2aW91 ci4gbyBBbiBleHRyYSB0cmFmZmljIGNhcGFiaWxpdHk8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBTSE9VTEQgYmUgc3VwcG9ydGVkIHdoZW4gcG9zc2libGUuPEJSPg0KJmd0OyZndDs8QlI+ DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyArJm5ic3A7IE1QTFMtVFAgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgbWVjaGFuaXNtcyBN VVNUIHByZXZlbnQ8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBmcmVxdWVudCBvcGVyYXRp b24gb2YgdGhlIHByb3RlY3Rpb24gc3dpdGNoIGR1ZSB0byBhbjxCUj4NCiZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGludGVybWl0dGVudCBkZWZlY3QuPEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAr Jm5ic3A7IE1QTFMtVFAgcHJvdGVjdGlvbiBtZWNoYW5pc21zIE1VU1QgZW5zdXJlIGNvLW9yZGlu YXRpb24gb2Y8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aW1pbmcgb2YgcHJvdGVjdGlv biBzd2l0Y2hlcyBhdCBtdWx0aXBsZSBsYXllcnMgdG8gYXZvaWQ8QlI+DQomZ3Q7Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyByYWNlcyBhbmQgdG8gYWxsb3cgdGhlIHByb3RlY3Rpb24gc3dpdGNoaW5nIG1l Y2hhbmlzbSBvZiB0aGU8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzZXJ2ZXIgbGF5ZXIg dG8gZml4IHRoZSBwcm9ibGVtIGJlZm9yZSBzd2l0Y2hpbmcgYXQgdGhlPEJSPg0KJmd0OyZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgTVBMUy1UUCBsYXllci48QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICsm bmJzcDsgTVBMUy1UUCBNQVkgc3VwcG9ydCBtZWNoYW5pc21zIHRoYXQgYXJlIG9wdGltaXplZCBm b3I8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzcGVjaWZpYyBuZXR3b3JrIHRvcG9sb2dp ZXMgKFJpbmcsIE1lc2gpIGluIG9yZGVyIHRvIGhhbmRsZTxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHByb3RlY3Rpb24gc3dpdGNoaW5nIGluIGEgY29zdC1lZmZpY2llbnQgbWFubmVyLjxC Uj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsgMi45LiZuYnNwOyBRb1MgcmVxdWlyZW1lbnRzPEJS Pg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBTZXJ2aWNlIHByb3Zp ZGVycyByZXF1aXJlIGFkdmFuY2VkIHRyYWZmaWMgbWFuYWdlbWVudCBjYXBhYmlsaXRpZXMgdG88 QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBlbmZvcmNlIGFuZCBndWFyYW50ZWUgdGhl IFFvUyBwYXJhbWV0ZXJzIG9mIGN1c3RvbWVycycgU0xBcy48QlI+DQomZ3Q7Jmd0OzxCUj4NCiZn dDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFF1YWxpdHkgb2Ygc2VydmljZSBtZWNoYW5pc21zIGFy ZSByZXF1aXJlZCB0byBlbnN1cmU6PEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyBvJm5ic3A7IFN1cHBvcnQgZm9yIGRpZmZlcmVudGlhdGVkIHNlcnZpY2VzIGFu ZCBkaWZmZXJlbnQgdHJhZmZpYyB0eXBlczxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdpdGggdHJhZmZpYyBjbGFzcyBzZXBhcmF0aW9uIGFzc29jaWF0 ZWQgd2l0aCBkaWZmZXJlbnQgdHJhZmZpYy48QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgUHJpb3JpdGl6YXRpb24gb2YgY3JpdGljYWwgc2Vydmlj ZXMuPEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBvJm5ic3A7 IEVuYWJsaW5nIHRoZSBwcm92aXNpb25pbmcgYW5kIHRoZSBndWFyYW50ZWUgb2YgU2VydmljZSBM ZXZlbDxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNw ZWNpZmljYXRpb25zIChTTFMpLCB3aXRoIHN1cHBvcnQgZm9yIGhhcmQgYW5kIHJlbGF0aXZlIGVu ZC10by08QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBl bmQgQlcgZ3VhcmFudGVlZC48QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IG8mbmJzcDsgQ29udHJvbGxlZCBqaXR0ZXIgYW5kIGRlbGF5LjxCUj4NCiZndDsmZ3Q7 PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgbyZuYnNwOyBHdWFyYW50ZWUgb2YgZmFp ciBhY2Nlc3MgdG8gc2hhcmVkIHJlc291cmNlcyBpbiBhbiBNUExTLVRQPEJSPg0KJmd0OyZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbmV0d29yay48QlI+DQomZ3Q7Jmd0 OzxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7 PEJSPg0KJmd0OyZndDsgTml2ZW4tSmVua2lucywgZXQgYWwuJm5ic3A7Jm5ic3A7Jm5ic3A7IEV4 cGlyZXMgSmFudWFyeSAyLCAyMDA5Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFtQYWdlIDE0 XTxCUj4NCiZndDsmZ3Q7IAw8QlI+DQomZ3Q7Jmd0OyBJbnRlcm5ldC1EcmFmdCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBN UExTLVRQIFJlcXVpcmVtZW50cyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBKdWx5IDIwMDg8QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmbmJz cDsmbmJzcDsmbmJzcDsgbyZuYnNwOyBBYmlsaXR5IGZvciBPQU0gYW5kIGRhdGEgdG8gc2hhcmUg dGhlIHNhbWUgZmF0ZS48QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7IFRPTTogVGhpcyBiZWxv bmdzIGluIHRoZSBPQU0gZG9jdW1lbnQuPEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OzxCUj4N CiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgUmVzb3VyY2VzIGZvciBjb250cm9s IGFuZCBtYW5hZ2VtZW50IHBsYW5lIHBhY2tldHMgc28gdGhhdCB1c2VyPEJSPg0KJmd0OyZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcGxhbmUgdHJhZmZpYywgcmVnYXJk bGVzcyBvZiB0aGUgYW1vdW50LCB3aWxsIG5vdCBjYXVzZSBjb250cm9sPEJSPg0KJmd0OyZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYW5kIG1hbmFnZW1lbnQgZnVuY3Rp b25zIHRvIGJlY29tZSBpbm9wZXJhdGl2ZS48QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7IFRoZSBmb2xsb3dpbmcgUW9TIHJlcXVpcmVtZW50cyBhcHBseSB0byBN UExTLVRQOjxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgbyZu YnNwOyBNUExTLVRQIE1VU1QgYmUgYWJsZSB0byBkZWxpdmVyIHRoZSBzYW1lIGRlZ3JlZSBvZiBR b1MgdGhhdCBoYXM8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBiZWVuIGRlbGl2ZXJlZCBieSBTREgvU09ORVQgc3lzdGVtcy48QlI+DQomZ3Q7Jmd0OzxC Uj4NCiZndDsmZ3Q7IFRPTTogV2UgY2FuIHNhdmUgb24gYSBsb3Qgb2YgdGV4dCBhbmQgcmVtb3Zl IHRoZSAmcXVvdDtNUExTLVRFIE1VU1QmcXVvdDsgb3I8QlI+DQomZ3Q7Jmd0OyAmcXVvdDtNUExT LVRQIFNIT1VMRCZxdW90OyBiaXRzIGFuZCBzaW1wbHkgc2F5ICZxdW90O01VU1QgWCZxdW90OyBv ciAmcXVvdDtTSE9VTEQgWSZxdW90Oy4gVGhlIE1QTFMtVFA8QlI+DQomZ3Q7Jmd0OyBiaXQgaXMg aW1wbGljaXQgSSB0aGluay48QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IG8mbmJzcDsgTVBMUy1UUCBNVVNUIHN1cHBvcnQgdHJhbnNwb3J0IGJhbmR3aWR0aCBh bGxvY2F0aW9uIHRvIGFueTxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGdyYW51bGFyaXR5IHdpdGhvdXQgYW55IHJlc3RyaWN0aW9ucyBiYXNlZCBvbiBh IGNpcmN1aXQtc3dpdGNoZWQ8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBtdWx0aXBsZXhpbmcgaGllcmFyY2h5LiZuYnNwOyBUaGlzIGF0dHJpYnV0ZSB3 aWxsIHByb3ZpZGUgc2VydmljZTxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHByb3ZpZGVycyB3aXRoIHRoZSBjYXBhYmlsaXR5IHRvIHJvdXRlIG1vcmUg Y3VzdG9tZXIgc2VydmljZTxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGRlbWFuZHMgb3ZlciB0aGUgTVBMUy1UUCBuZXR3b3JrLjxCUj4NCiZndDsmZ3Q7 PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgW1Nob3VsZCB3ZSByZWZlciBoZXJlIHRv IHRoZSByZXF1aXJlbWVudHMgc3BlY2lmaWVkIGluIFJGQyAyNzAyP108QlI+DQomZ3Q7Jmd0OzxC Uj4NCiZndDsmZ3Q7IDIuMTAuJm5ic3A7IFNlY3VyaXR5IHJlcXVpcmVtZW50czxCUj4NCiZndDsm Z3Q7PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgbyZuYnNwOyBNUExTLVRQIE1VU1Qg ZW5zdXJlIHRoYXQgdGhlIG5ldHdvcmsgYW5kIHNlcnZpY2VzIGFyZSBzZWN1cmVkLjxCUj4NCiZn dDsmZ3Q7PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgbyZuYnNwOyBUcmFmZmljIGZs b3dzIGZyb20gZGlmZmVyZW50IHVzZXJzIE1VU1QgTk9UIGJlIGludGVybWluZ2xlZCwgYnV0PEJS Pg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaWYgdGhpcyBk b2VzIG9jY3VyIHRoZW4gdGhpcyBNVVNUIGJlIGRldGVjdGFibGUgYW5kIHRoZTxCUj4NCiZndDsm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFwcHJvcHJpYXRlIGNvbnNl cXVlbnQgYWN0aW9ucyB0YWtlbi48QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7IG8mbmJzcDsgTVBMUy1UUCBNVVNUIGVuc3VyZSB0aGUgc2VwYXJhdGlvbiBvZiBj dXN0b21lciAoY2xpZW50KSBhbmQ8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBwcm92aWRlciAoc2VydmVyIGFuZCBwZWVyIG5ldHdvcmspIGFkZHJlc3Np bmcgYW5kIG90aGVyPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgaW5mb3JtYXRpb24uPEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyBUT006IFRoaXMg cmVxdWlyZW1lbnQgaXMgc3RhdGVkIGFib3ZlLjxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsm bmJzcDsmbmJzcDsmbmJzcDsgbyZuYnNwOyBNUExTLVRQIE1VU1QgZW5zdXJlIHRoYXQgdGhlIGNv bnRyb2wgYW5kIG1hbmFnZW1lbnQgcGxhbmVzIGFzIHdlbGw8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhcyBPQU0gdHJhZmZpYyBhcmUgc2VjdXJlIGZy b20gZXh0ZXJuYWwgYXR0YWNrLjxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJz cDsmbmJzcDsgbyZuYnNwOyBNUExTLVRQIE1VU1QgcHJvdmlkZSBtZWNoYW5pc21zIHRvIGVuc3Vy ZSB0aGF0IHRoZSBNUExTLVRQIG5ldHdvcms8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyByZW1haW5zIHNlY3VyZSBhbmQgc3RhYmxlIHVuZGVyIHNpdHVh dGlvbnMgb2YgZXh0cmVtZSBzdHJlc3MuPEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyBFeGFtcGxlcyBvZiBhdHRhY2tzIGFuZCBzaXR1YXRpb25zIG9mIGV4dHJl bWUgc3RyZXNzIGluY2x1ZGUgKGJ1dCBhcmU8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyBub3QgbGltaXRlZCB0bykgY2xhc3NpY2FsIHNlY3VyaXR5IGF0dGFja3MgKGUuZy4sIGhpamFj a2luZywgcHJpdmFjeSw8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBub24tcmVwdWRp YXRpb24sIGV0Yy4pIGFuZCBhdHRhY2tzIG9uIG5ldHdvcmsgYXZhaWxhYmlsaXR5IChlLmcuLDxC Uj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRlbmlhbCBvZiBzZXJ2aWNlIChEb1MpIGF0 dGFja3MpLjxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyAzLiZuYnNw OyBJQU5BIENvbnNpZGVyYXRpb25zPEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyBUaGlzIGRvY3VtZW50IG1ha2VzIG5vIHJlcXVlc3Qgb2YgSUFOQS48QlI+DQom Z3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE5vdGUgdG8gUkZDIEVkaXRv cjogdGhpcyBzZWN0aW9uIG1heSBiZSByZW1vdmVkIG9uIHB1YmxpY2F0aW9uIGFzIGFuPEJSPg0K Jmd0OyZndDs8QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsgTml2ZW4t SmVua2lucywgZXQgYWwuJm5ic3A7Jm5ic3A7Jm5ic3A7IEV4cGlyZXMgSmFudWFyeSAyLCAyMDA5 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFtQYWdlIDE1XTxCUj4NCiZndDsmZ3Q7IAw8QlI+ DQomZ3Q7Jmd0OyBJbnRlcm5ldC1EcmFmdCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBNUExTLVRQIFJlcXVpcmVtZW50cyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBKdWx5IDIwMDg8QlI+DQomZ3Q7 Jmd0OzxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgUkZDLjxC Uj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyA0LiZuYnNwOyBTZWN1cml0 eSBDb25zaWRlcmF0aW9uczxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsm bmJzcDsgVGhpcyBkb2N1bWVudCBkb2VzIG5vdCBieSBpdHNlbGYgcmFpc2UgYW55IHBhcnRpY3Vs YXIgc2VjdXJpdHk8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBjb25zaWRlcmF0aW9u cy48QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsgNS4mbmJzcDsgQWNr bm93bGVkZ2VtZW50czxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJz cDsgVGhlIGF1dGhvcnMgd2lzaCB0byB0aGFuayBOZWlsIEhhcnJpc29uIGFuZCBUb21vbm9yaSBU YWtlZGEgZm9yIHRoZWlyPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgcmV2aWV3IGFu ZCBlbmhhbmNlbWVudHMgdG8gdGhlIHRleHQuPEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OzxC Uj4NCiZndDsmZ3Q7IDYuJm5ic3A7IEluZm9ybWF0aXZlIFJlZmVyZW5jZXM8QlI+DQomZ3Q7Jmd0 OzxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFtSRkMyMTE5XSZuYnNwOyBCcmFkbmVy LCBTLiwgJnF1b3Q7S2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZTxCUj4NCiZn dDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJlcXVpcmVtZW50IExldmVscyZxdW90 OywgQkNQIDE0LCBSRkMgMjExOSwgTWFyY2ggMTk5Ny48QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFtSRkM0NDI3XSZuYnNwOyBNYW5uaWUsIEUuIGFuZCBELiBQ YXBhZGltaXRyaW91LCAmcXVvdDtSZWNvdmVyeSAoUHJvdGVjdGlvbiBhbmQ8QlI+DQomZ3Q7Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSZXN0b3JhdGlvbikgVGVybWlub2xvZ3kgZm9y IEdlbmVyYWxpemVkIE11bHRpLVByb3RvY29sPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgTGFiZWwgU3dpdGNoaW5nIChHTVBMUykmcXVvdDssIFJGQyA0NDI3LCBNYXJj aCAyMDA2LjxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgW0lU VS5ZMTQwMS4yMDA4XTxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElu dGVybmF0aW9uYWwgVGVsZWNvbW11bmljYXRpb25zIFVuaW9uLCAmcXVvdDtQcmluY2lwbGVzIG9m PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW50ZXJ3b3JraW5nJnF1 b3Q7LCBJVFUtVCBSZWNvbW1lbmRhdGlvbiBZLjE0MDEsIEZlYnJ1YXJ5IDIwMDguPEJSPg0KJmd0 OyZndDs8QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7IEF1dGhvcnMnIEFkZHJlc3NlczxCUj4N CiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgQmVuIE5pdmVuLUplbmtp bnMgKGVkaXRvcik8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBCVDxCUj4NCiZndDsm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDIwOCBDYWxsaXN0byBIb3VzZSwgQWRhc3RyYWwgUGFyazxC Uj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElwc3dpY2gsIFN1ZmZvbGsmbmJzcDsgSVA1 IDNSRTxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFVLPEJSPg0KJmd0OyZndDs8QlI+ DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBFbWFpbDogYmVuamFtaW4ubml2ZW4tamVua2lu c0BidC5jb208QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmbmJzcDsm bmJzcDsmbmJzcDsgRGVib3JhaCBCcnVuZ2FyZCAoZWRpdG9yKTxCUj4NCiZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IEFUJmFtcDtUPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgUm0u IEQxLTNDMjIgLSAyMDAgUy4gTGF1cmVsIEF2ZS48QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyBNaWRkbGV0b3duLCBOSiZuYnNwOyAwNzc0ODxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IFVTQTxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsg RW1haWw6IGRicnVuZ2FyZEBhdHQuY29tPEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OzxCUj4N CiZndDsmZ3Q7PEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyBOaXZlbi1KZW5raW5zLCBldCBh bC4mbmJzcDsmbmJzcDsmbmJzcDsgRXhwaXJlcyBKYW51YXJ5IDIsIDIwMDkmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgW1BhZ2UgMTZdPEJSPg0KJmd0OyZndDsgDDxCUj4NCiZndDsmZ3Q7IElu dGVybmV0LURyYWZ0Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE1QTFMtVFAgUmVxdWlyZW1lbnRzJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEp1bHkgMjAwODxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0 OyZndDs8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBNYWxjb2xtIEJldHRzIChlZGl0 b3IpPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgTm9ydGVsIE5ldHdvcmtzPEJSPg0K Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgMzUwMCBDYXJsaW5nIEF2ZW51ZTxCUj4NCiZndDsm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE90dGF3YSwgT250YXJpbyZuYnNwOyBLMkggOEU5PEJSPg0K Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgQ2FuYWRhPEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7 Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBFbWFpbDogYmV0dHMwMUBub3J0ZWwuY29tPEJSPg0KJmd0 OyZndDs8QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE51cml0 IFNwcmVjaGVyPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgTm9raWEgU2llbWVucyBO ZXR3b3JrczxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDMgSGFuYWdhciBTdC4gTmV2 ZSBOZSdlbWFuIEI8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBIb2QgSGFzaGFyb24s Jm5ic3A7Jm5ic3A7IDQ1MjQxPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgSXNyYWVs PEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBFbWFpbDogbnVy aXQuc3ByZWNoZXJAbnNuLmNvbTxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7 Jmd0OzxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsm Z3Q7PEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZn dDs8QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0 OzxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7 PEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDs8 QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OzxC Uj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7PEJS Pg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDs8QlI+ DQomZ3Q7Jmd0OyBOaXZlbi1KZW5raW5zLCBldCBhbC4mbmJzcDsmbmJzcDsmbmJzcDsgRXhwaXJl cyBKYW51YXJ5IDIsIDIwMDkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgW1BhZ2UgMTddPEJS Pg0KJmd0OyZndDsgDDxCUj4NCiZndDsmZ3Q7IEludGVybmV0LURyYWZ0Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE1QTFMt VFAgUmVxdWlyZW1lbnRzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEp1 bHkgMjAwODxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyBGdWxsIENv cHlyaWdodCBTdGF0ZW1lbnQ8QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IENvcHlyaWdodCAoQykgVGhlIElFVEYgVHJ1c3QgKDIwMDgpLjxCUj4NCiZndDsmZ3Q7 PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0 IHRvIHRoZSByaWdodHMsIGxpY2Vuc2VzIGFuZCByZXN0cmljdGlvbnM8QlI+DQomZ3Q7Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyBjb250YWluZWQgaW4gQkNQIDc4LCBhbmQgZXhjZXB0IGFzIHNldCBm b3J0aCB0aGVyZWluLCB0aGUgYXV0aG9yczxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHJldGFpbiBhbGwgdGhlaXIgcmlnaHRzLjxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmbmJz cDsmbmJzcDsmbmJzcDsgVGhpcyBkb2N1bWVudCBhbmQgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5l ZCBoZXJlaW4gYXJlIHByb3ZpZGVkIG9uIGFuPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJz cDsgJnF1b3Q7QVMgSVMmcXVvdDsgYmFzaXMgYW5kIFRIRSBDT05UUklCVVRPUiwgVEhFIE9SR0FO SVpBVElPTiBIRS9TSEUgUkVQUkVTRU5UUzxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IE9SIElTIFNQT05TT1JFRCBCWSAoSUYgQU5ZKSwgVEhFIElOVEVSTkVUIFNPQ0lFVFksIFRIRSBJ RVRGIFRSVVNUIEFORDxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRIRSBJTlRFUk5F VCBFTkdJTkVFUklORyBUQVNLIEZPUkNFIERJU0NMQUlNIEFMTCBXQVJSQU5USUVTLCBFWFBSRVNT PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgT1IgSU1QTElFRCwgSU5DTFVESU5HIEJV VCBOT1QgTElNSVRFRCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9GPEJSPg0KJmd0OyZn dDsmbmJzcDsmbmJzcDsmbmJzcDsgVEhFIElORk9STUFUSU9OIEhFUkVJTiBXSUxMIE5PVCBJTkZS SU5HRSBBTlkgUklHSFRTIE9SIEFOWSBJTVBMSUVEPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsm bmJzcDsgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgT1IgRklUTkVTUyBGT1IgQSBQQVJU SUNVTEFSIFBVUlBPU0UuPEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7 IEludGVsbGVjdHVhbCBQcm9wZXJ0eTxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmbmJzcDsm bmJzcDsmbmJzcDsgVGhlIElFVEYgdGFrZXMgbm8gcG9zaXRpb24gcmVnYXJkaW5nIHRoZSB2YWxp ZGl0eSBvciBzY29wZSBvZiBhbnk8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBJbnRl bGxlY3R1YWwgUHJvcGVydHkgUmlnaHRzIG9yIG90aGVyIHJpZ2h0cyB0aGF0IG1pZ2h0IGJlIGNs YWltZWQgdG88QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBwZXJ0YWluIHRvIHRoZSBp bXBsZW1lbnRhdGlvbiBvciB1c2Ugb2YgdGhlIHRlY2hub2xvZ3kgZGVzY3JpYmVkIGluPEJSPg0K Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhpcyBkb2N1bWVudCBvciB0aGUgZXh0ZW50IHRv IHdoaWNoIGFueSBsaWNlbnNlIHVuZGVyIHN1Y2ggcmlnaHRzPEJSPg0KJmd0OyZndDsmbmJzcDsm bmJzcDsmbmJzcDsgbWlnaHQgb3IgbWlnaHQgbm90IGJlIGF2YWlsYWJsZTsgbm9yIGRvZXMgaXQg cmVwcmVzZW50IHRoYXQgaXQgaGFzPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgbWFk ZSBhbnkgaW5kZXBlbmRlbnQgZWZmb3J0IHRvIGlkZW50aWZ5IGFueSBzdWNoIHJpZ2h0cy4mbmJz cDsgSW5mb3JtYXRpb248QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBvbiB0aGUgcHJv Y2VkdXJlcyB3aXRoIHJlc3BlY3QgdG8gcmlnaHRzIGluIFJGQyBkb2N1bWVudHMgY2FuIGJlPEJS Pg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgZm91bmQgaW4gQkNQIDc4IGFuZCBCQ1AgNzku PEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBDb3BpZXMgb2Yg SVBSIGRpc2Nsb3N1cmVzIG1hZGUgdG8gdGhlIElFVEYgU2VjcmV0YXJpYXQgYW5kIGFueTxCUj4N CiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFzc3VyYW5jZXMgb2YgbGljZW5zZXMgdG8gYmUg bWFkZSBhdmFpbGFibGUsIG9yIHRoZSByZXN1bHQgb2YgYW48QlI+DQomZ3Q7Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyBhdHRlbXB0IG1hZGUgdG8gb2J0YWluIGEgZ2VuZXJhbCBsaWNlbnNlIG9yIHBl cm1pc3Npb24gZm9yIHRoZSB1c2Ugb2Y8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBz dWNoIHByb3ByaWV0YXJ5IHJpZ2h0cyBieSBpbXBsZW1lbnRlcnMgb3IgdXNlcnMgb2YgdGhpczxC Uj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNwZWNpZmljYXRpb24gY2FuIGJlIG9idGFp bmVkIGZyb20gdGhlIElFVEYgb24tbGluZSBJUFIgcmVwb3NpdG9yeSBhdDxCUj4NCiZndDsmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxBIEhSRUY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaXByIj5odHRw Oi8vd3d3LmlldGYub3JnL2lwcjwvQT4uPEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyBUaGUgSUVURiBpbnZpdGVzIGFueSBpbnRlcmVzdGVkIHBhcnR5IHRvIGJy aW5nIHRvIGl0cyBhdHRlbnRpb24gYW55PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsg Y29weXJpZ2h0cywgcGF0ZW50cyBvciBwYXRlbnQgYXBwbGljYXRpb25zLCBvciBvdGhlciBwcm9w cmlldGFyeTxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJpZ2h0cyB0aGF0IG1heSBj b3ZlciB0ZWNobm9sb2d5IHRoYXQgbWF5IGJlIHJlcXVpcmVkIHRvIGltcGxlbWVudDxCUj4NCiZn dDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoaXMgc3RhbmRhcmQuJm5ic3A7IFBsZWFzZSBhZGRy ZXNzIHRoZSBpbmZvcm1hdGlvbiB0byB0aGUgSUVURiBhdDxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGlldGYtaXByQGlldGYub3JnLjxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDs8 QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OzxC Uj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7PEJS Pg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyBOaXZlbi1KZW5raW5zLCBldCBhbC4mbmJzcDsmbmJz cDsmbmJzcDsgRXhwaXJlcyBKYW51YXJ5IDIsIDIwMDkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgW1BhZ2UgMThdPEJSPg0KJmd0OyZndDsgDDxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDs8 QlI+DQomZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxCUj4NCiZndDsmZ3Q7IE1wbHMtaW50ZXJvcCBtYWlsaW5nIGxpc3Q8QlI+DQomZ3Q7Jmd0 OyBNcGxzLWludGVyb3BAaWV0Zi5vcmc8QlI+DQomZ3Q7Jmd0OyA8QSBIUkVGPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtaW50ZXJvcCI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLWludGVyb3A8L0E+PEJSPg0KJmd0OzxCUj4NCjxC Uj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPg0K TXBscy1pbnRlcm9wIG1haWxpbmcgbGlzdDxCUj4NCk1wbHMtaW50ZXJvcEBpZXRmLm9yZzxCUj4N CjxBIEhSRUY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscy1pbnRl cm9wIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtaW50ZXJvcDwv QT48QlI+DQo8L0ZPTlQ+DQo8L1A+DQoNCjwvQk9EWT4NCjwvSFRNTD4= ------_=_NextPart_001_01C8D466.62AC98CB-- --===============0062514461== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop --===============0062514461==-- From mpls-interop-bounces@ietf.org Sun Jun 22 06:05:22 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A4603A69B7; Sun, 22 Jun 2008 06:05:22 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C8C33A69DE for ; Sun, 22 Jun 2008 06:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=-0.460, BAYES_00=-2.599, J_CHICKENPOX_24=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7gajjncKLCbd for ; Sun, 22 Jun 2008 06:05:17 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id C0EFC3A69B7 for ; Sun, 22 Jun 2008 06:05:16 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m5MD5JRt005435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Jun 2008 15:05:19 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m5MD5Jws022953; Sun, 22 Jun 2008 15:05:19 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 22 Jun 2008 15:05:18 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 22 Jun 2008 15:05:17 +0200 Message-ID: <9FF5BDAD88B9D84881609E89AC92FB83EBD390@DEMUEXC014.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mpls-interop] next MEAD team meeting Thread-Index: AcjSMNQsx4BuurjX8EeQxIcfmO8exAA0/R+VAEuIunAACtuUpAABrZoIAAC3RqA= From: "Sprecher, Nurit (NSN - IL/Israel - MiniMD)" To: "ext Ben Niven-Jenkins" , "Thomas Nadeau" , "Loa Andersson" , "MEAD team" X-OriginalArrivalTime: 22 Jun 2008 13:05:18.0906 (UTC) FILETIME=[9EFBF9A0:01C8D468] Cc: "Weingarten, Yaacov \(NSN - IL/Israel - MiniMD\)" Subject: Re: [Mpls-interop] next MEAD team meeting X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org I believe it may confuse the readers. I think we should require that static is a MUST and dynamic is optional (for implementation). That was also the intention in T-MPLS that argued to have the same look-and-feel as SDH. They defined static provisioning and the intended to have an optional control plane (based on GMPLS). -----Original Message----- From: ext Ben Niven-Jenkins [mailto:benjamin.niven-jenkins@bt.com] Sent: Sunday, June 22, 2008 15:40 To: Thomas Nadeau; Sprecher, Nurit (NSN - IL/Israel - MiniMD); Loa Andersson; MEAD team Cc: Weingarten, Yaacov (NSN - IL/Israel - MiniMD) Subject: Re: [Mpls-interop] next MEAD team meeting I think the key thing is that MPLS-TP must be able to operate (including OAM) in the absence of a control plane. The option is then down to whether we say both static & dynamic are MUSTs (from an implementation perspective) and the operator is then free to choose whether they operate their network statically or dynamically. Or whether only static is a MUST and dynamic is optional (for implementation). I believe the work in ITU intended to extend to dynamic at some point and static was just a first step in the T-MPLS work. It only take one operator to demand dynamic from their vendors for it to be present in equipment anyway even if it is not used by other operators. So I think we can make both static & dynamic MUSTs and then clarify that when operating in a static mode MPLS-TP must not rely on any dynamic protocols. We cover this (at least to some extent) already with requirements such as " Static provisioning MUST not depend on routing or signaling protocols (e.g. GMPLS, OSPF, IS-IS, RSVP, BGP, LDP etc.)." Ben On 22/06/2008 12:51, "Thomas Nadeau" wrote: > > > > On 6/22/08 5:45 AM, "Sprecher, Nurit (NSN - IL/Israel - MiniMD)" > wrote: > >> Hi Thomas, >> Thanks for your comments. >> I still need to get into the details and meanings of your comments, >> but in the meantime I have one basic concern on your comment on " >> MPLS-TP connections MAY be able to be provisioned dynamically via a >> control plane. TOM: I insist that we change the MAY above to MUST. I >> want a dynamic version of this as much as a static one." >> This is one of the fundamental principles of the MPLS-TP, that the >> presence of a distributed control plane in support of network >> operations is optional (as in other transport technologies, like in SDH, etc.). > > I agree it is optional. What I want to make sure is that it is not > so optional that it is completely removed from the design. The > language in the document now seems to be headed in that direction. > >> This is also the trigger for the definition of OAM capabilities which >> are independent of a control plane, as well as of the protection >> switching, etc. >> This is also addressed by the slides of the JW: "Desire to statically >> configure LSPs and PWEs via the management plane... > > I am not arguing against static; I am arguing for dynamic to be in > there as well. > >> Transport OAM capabilities don't exist for LSP and PWE independent of >> configuration mechanism (management plane or GMPLS or PWE control >> plane)... > > It depends on how you look at what "transport OAM capabilities". > From my perspective at BT, I definitely think there is a dynamic > flavor of this for sure. Again, I am not advocating removal of the > static parts, just the addition of the dynamic ones. And since they > are already there in large part, as part of the base MPLS > specification, I don't see any harm in specifying this. > > --Tom > > > >> With static provisioning, no dependency on routing or signaling (e.g. >> GMPLS or, IGP, RSVP, BGP, LDP)", etc. >> Best regards, >> Nurit >> >> -----Original Message----- >> From: mpls-interop-bounces@ietf.org >> [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext Thomas Nadeau >> Sent: Friday, June 20, 2008 21:38 >> To: Ben Niven-Jenkins; Loa Andersson; MEAD team >> Subject: Re: [Mpls-interop] next MEAD team meeting >> >> >> Comments on the document inline start with "TOM:" >> In general, please review the document and put more of an emphasis on >> the use of "MUST" rather than "MAY" or "SHOULD". The IETG frowns on >> requirements documents that are too optional. >> >> --Tom >> >> >> >> >> >> Network Working Group B. Niven-Jenkins, Ed. >> Internet-Draft BT >> Intended status: Informational D. Brungard, Ed. >> Expires: January 2, 2009 AT&T >> M. Betts, Ed. >> Nortel Networks >> N. Sprecher >> Nokia Siemens Networks >> July 01, >> 2008 >> >> >> MPLS-TP Requirements >> draft-jenkins-mpls-mplstp-requirements-00 >> >> Status of this Memo >> >> By submitting this Internet-Draft, each author represents that any >> applicable patent or other IPR claims of which he or she is aware >> have been or will be disclosed, and any of which he or she becomes >> aware will be disclosed, in accordance with Section 6 of BCP 79. >> >> 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. >> >> This Internet-Draft will expire on January 2, 2009. >> >> Abstract >> >> This document will outline the requirements for MPLS-TP. >> >> Requirements Language >> >> 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 [RFC2119]. >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page 1] >> >> Internet-Draft MPLS-TP Requirements July 2008 >> >> >> Table of Contents >> >> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 >> 2. MPLS-TP Requirements . . . . . . . . . . . . . . . . . . . . . 5 >> 2.1. General requirements . . . . . . . . . . . . . . . . . . . 5 >> 2.2. Layering requirements . . . . . . . . . . . . . . . . . . 6 >> 2.3. Data plane requirements . . . . . . . . . . . . . . . . . 7 >> 2.4. Control plane requirements . . . . . . . . . . . . . . . . 8 >> 2.5. Network Management (NM) requirements . . . . . . . . . . . 11 >> 2.6. OAM requirements . . . . . . . . . . . . . . . . . . . . . 11 >> 2.7. Network performance management (PM) requirements . . . . . 11 >> 2.8. Protection & Survivability requirements . . . . . . . . . 12 >> 2.9. QoS requirements . . . . . . . . . . . . . . . . . . . . . 14 >> 2.10. Security requirements . . . . . . . . . . . . . . . . . . 15 >> 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 >> 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 >> 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 >> 6. Informative References . . . . . . . . . . . . . . . . . . . . 16 >> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 >> Intellectual Property and Copyright Statements . . . . . . . . . . >> 18 >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page 2] >> >> Internet-Draft MPLS-TP Requirements July 2008 >> >> >> 1. Introduction >> >> For many years, SONET/SDH has provided service providers with a high >> benchmark for reliability and operational simplicity. With the >> accelerating growth of packet-based services (such as Ethernet, VoIP, >> L2/L3 VPN, IPTV, RAN backhauling, etc.), service providers are in >> need of capabilities to efficiently support packet-based services on >> their transport networks. The need to increase their revenue while >> remaining competitive forces operators to look for the lowest network >> Total Cost of Ownership (TCO). Investment in both Capital >> Expenditure (CAPEX) and Operational Expense (OPEX) should be minimal. >> >> Carriers are considering migrating to packet transport networks in >> order to reduce their costs and to improve their ability to support >> services with guaranteed SLAs. Migrating from SONET/SDH to packet >> transport networks should not involve dramatic changes in network >> operation, should not necessitate extensive retraining, and should >> not require major changes to existing work practices. The aim is to >> preserve the look-and-feel to which carriers have become accustomed >> in deploying their SONET/SDH networks, while providing common, multi- >> layer operations, resiliency, control and management for packet, >> circuit and lambda transport networks. >> >> An important attribute of a transport network is its ability to >> function independently from both its client and server (transmission >> media) layer networks. It should be capable of transmitting over any >> media. Another key characteristic of transport networks is the >> capability to maintain the integrity of the client signal between its >> ingress and egress ports. >> >> TOM: I would use something other than "client signal" here. Something >> like "client path" or something is what I think you mean. >> >> A transport network must provide the means >> to commit quality of service objectives to clients. This is achieved >> by providing a mechanism for client network service demarcation for >> the network path together with an associated network resiliency >> mechanism. A transport network must also provide a method of service >> monitoring in order to verify the delivery of an agreed quality of >> service. This is enabled by means of carrier-grade OAM tools. >> >> The connectivity service is the basic service provided by a transport >> network. >> >> TOM: Is it? Does the transport really provide connections or does it >> provide transport paths? I am sensitive to the terms used here. We >> don't want this to become a connect-fest. Seems to me that you >> explain this better in the next sentence anyhow. >> >> The purpose of a transport network is to transparently >> carry client signals (i.e. the stream of client PDUs or client >> bits) >> >> TOM: Again, I don't like the term "signals" here. Use "client data" >> or something. >> >> between endpoints in the network (typically over several intermediate >> nodes). These endpoints may be service switching points or service >> terminating points. The connectivity services offered to customers >> are aggregated into large, long-holding time pipes/trunks which >> >> TOM: Do you really mean to call these "time pipes"? Sounds too >> futuristic even for this work. *) I think you mean "...into >> relatively large, long-lasting paths..." >> >> enable the efficient and reliable operation of the transport network. >> These trunks are modified infrequently. >> >> TOM: Keep the terminology consistent here too. There is the use of >> "trunks", "pipes", etc... >> >> Aggregation and hierarchy are beneficial for achieving scalability >> and security since: >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page 3] >> >> Internet-Draft MPLS-TP Requirements July 2008 >> >> >> 1. They reduce the number of provisioning and forwarding states in >> the network core. >> >> 2. They reduce load and the cost of implementing service assurance >> and fault management. >> >> TOM: Do they really reduce load? This is one of those fluffy, >> open-ended terms like "scaleability" that I don't like used unless it >> is clearly defined. >> >> 3. Client signals are completely encapsulated and isolated from each >> other. This also allows complete isolation of customer traffic >> from carrier operations. >> >> TOM: Does this really happen at the data or control plane or both? Or >> do we care? >> >> >> Client signals are first transparently encapsulated. These >> encapsulated client signals are then aggregated for transport through >> the network in order to optimize network management. Server layer >> OAM is used to monitor the transport integrity of the client layer >> aggregate. At any hop, the aggregated signals may be further >> aggregated in lower layer transport network paths for transport >> across intermediate shared links. The encapsulated client signals >> are extracted at the edges of aggregation domains, and are either >> delivered to the client or forwarded to another domain. In the core >> of the network, only the server layer aggregated signals are >> monitored; individual client signals are monitored at the network >> boundary in the client layer network. >> >> TOM: I am not sure the above is appropriate for a requirements document. >> It sounds like you are spelling out an algorithm for how a solution >> should work. >> >> Quality-of-service mechanisms are required in the packet transport >> network to ensure the prioritization of critical services, to >> guarantee BW and to control jitter and delay. >> >> TOM: Are they required everywhere the service exists, or say just at >> the ingress/egress for policing/marking functions? While we are on >> the subject, do we want to be more specific about QoS requirements? >> >> Service providers require control and deterministic usage of network >> resources. They need end-to-end control to engineer network paths >> and to efficiently utilize network resources. They require >> capabilities to statically (OSS based) provision deterministic, >> protected and secured services and their associated resources as well >> as alternative control-plane options. >> >> TOM: They also require dynamic ones. Please put that in. I don't >> want to be asking for only a completely static system. >> >> The transport network must be capable of transporting multiple >> services in a scalable manner. >> >> TOM: Again, this use of "scalable" offends me. Please be more >> specific or take the sentence out as it is meaningless as stated. >> >> Carriers will still need to cope with legacy networks (which are >> composed of many layers and technologies), thus the packet transport >> network should interwork with other packet and transport networks >> (both horizontally and vertically). Vertical interworking is also >> known as client/server or network interworking. Horizontal >> interworking is also known as peer-partition or service interworking. >> >> TOM: Didn't you just say that vertical interworking was client >> interworking in the first sentence? How can horizontal be service >> interworking as well? >> >> For more details on each type of interworking and some of the issues >> that may arise (especially with horizontal interworking) see >> [ITU.Y1401.2008]. >> >> MPLS is a maturing packet technology and it is already playing an >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page 4] >> >> Internet-Draft MPLS-TP Requirements July 2008 >> >> >> important role in transport networks and services. However, not all >> of MPLS's capabilities and mechnisms are needed and/or consistent >> with transport network operations. This document identifies the >> required capabilities for MPLS so that it can better fit a transport >> role. >> >> TOM: I think you want to say "identifies the required sub-set of >> capabilities..." and later "potentially new ons specific for >> transport networks" which it seems you say two paragraphs later. >> >> Combining the packet experience of MPLS with the operational >> experience of SONET/SDH constitutes a packet transport technology >> named MPLS-TP. MPLS-TP will enable the migration of SONET/SDH >> networks to a packet-based network that will easily scale to support >> packet services in a simple and cost effective way. >> >> MPLS-TP needs to combine the necessary existing capabilities of MPLS >> with additional minimal mechanisms in order to meet the requirements >> described in this document. >> >> The requirements of an MPLS transport profile are provided below. >> >> TOM: There is a terminology issue in the use of "MPLS-TP" or "an MPLS >> transport profile". That is, on the one hand you refer to a >> technology, but on the other hand you are referring to a specific >> profile. Which is it? >> >> >> 2. MPLS-TP Requirements >> >> 2.1. General requirements >> >> o MPLS-TP MUST offer as much commonality as possible with the MPLS >> user plane as defined by IETF. When MPLS offers multiple options >> in this respect, MPLS-TP SHOULD select the minimum sub-set >> (necessary and sufficient subset) applicable to a transport >> network application. >> >> o Any new functionality that is defined to fulfil the requirements >> for MPLS-TP MUST be agreed within IETF and re-use (as far as >> practically possible) existing MPLS standards. >> >> o Mechanisms and capabilities MUST be able to interoperate with >> existing MPLS and PWE control and data planes where appropriate. >> >> TOM: Change PWE to "IETF PWE3" and "MPLS" to "IETF MPLS". There also >> need to be references here to the PWE3 architecture and MPLS >> architectures. >> >> o MPLS-TP MUST support traffic engineering capabilities that allow >> deterministic control of the use of network resources. >> >> o MPLS-TP MUST support the logical separation of the control and >> management planes from the user plane. >> >> o MPLS-TP SHOULD support the physical separation of the control and >> management planes from the user plane. >> >> o MPLS-TP MUST support point to point (P2P) or point to multipoint >> (P2MP) connections. >> >> TOM: Are we avoiding MP2MP consciously or was it left out? >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page 5] >> >> Internet-Draft MPLS-TP Requirements July 2008 >> >> >> o MPLS-TP MUST support static provisioning of connections via an >> NMS/OSS (i.e. via the management plane). >> >> o Static provisioning MUST not depend on routing or signaling >> protocols (e.g. GMPLS, OSPF, IS-IS, RSVP, BGP, LDP etc.). >> >> o MPLS-TP connections MAY be able to be provisioned dynamically via >> a control plane. >> >> TOM: I insist that we change the MAY above to MUST. I want a dynamic >> version of this as much as a static one. >> >> >> o The MPLS-TP data plane MUST be capable of functioning >> independently of the control or management plane used to operate >> the MPLS-TP layer network. That is the MPLS-TP data plane >> operation MUST continue to operate normally if the management >> plane or control plane that configured the connections fails. >> >> o MPLS-TP MUST support any network topology and be able to support >> increasing bandwidth demands, topology, number of customers or >> number of services incrementally. >> >> >> TOM: I think it is imperative that although an MPLS-TP is defined to >> play nicely with an MPLS one, it is imperative that one can >> distinguish between both, at least at the control plane, but perhaps >> at the data plane as well. >> >> 2.2. Layering requirements >> >> o An MPLS-TP network MUST operate in a multiple layer network >> environment consisting of the following independent layers: >> >> 1. A "service layer" instance in which the connections carry the >> customer's (individual or bundled) service (may be point-to- >> point, point-to-multipoint or multipoint-to-multipoint >> services); >> >> 2. A "trunk layer" with point-to-point or point-to-multipoint >> connections which are used to carry aggregates of the network >> "service layer" connections; and >> >> 3. A "transmission media layer" which provides sections (two-port >> point-to-point connections) to carry the aggregate of network >> trunk or network service connections on various physical >> media. >> >> TOM: This stuff belongs in the Terminology section at the top. >> >> MPLS-TP may provide the "service layer" (for P2P and P2MP services) >> and/or the "trunk layer" within a layer network environment. >> >> o An MPLS-TP layer network MUST support the transparent transport of >> MPLS-TP and non MPLS-TP client layer networks. >> >> o An MPLS-TP layer network MUST be able to be transparently carried >> over MPLS-TP and non MPLS-TP server layer networks (such as >> Ethernet, OTN, etc.) >> >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page 6] >> >> Internet-Draft MPLS-TP Requirements July 2008 >> >> >> o It MUST be possible to operate the MPLS-TP layer network >> independently of other layer networks (either MPLS-TP or non >> MPLS-TP). >> >> This is not only a technology requirement, different administrative >> groups may be responsible for different layer networks (even when >> they are of the same type)), and require the capability to >> operationally support the different layers. >> >> o It MUST be possible to hide MPLS-TP layer network addressing and >> other information (e.g. topology) from client layers. >> >> 2.3. Data plane requirements >> >> o The identification of each connection within its aggregate MUST be >> supported. >> >> o A label in a particular section MUST uniquely identify the >> connection. >> >> o A connection's source MUST be identifiable at its destination. >> >> Connections can be aggregated into trunks by pushing and de- >> aggregated by popping labels. MPLS-TP labels may be swapped within a >> connection in a layer network instance when the traffic is forwarded >> from one MPLS-TP link connection to another MPLS-TP link connection. >> >> o Labelling MUST make use of the MPLS label and label stack entry as >> defined in RFC3032. >> >> o It MUST be possible to operate and configure the MPLS-TP data >> (transport) plane without any IP functionality. >> >> o MPLS-TP MUST support both unidirectional and bi-directional point- >> to-point connections. >> >> o The forward and backward directions of a bi-directional connection >> SHOULD follow the same path within the MPLS-TP network. >> >> TOM: I am not sure if we say that they SHOULD as much as "they MUST >> be capable of". >> >> o The intermediate nodes SHOULD be aware about the binding of the >> forward and the backward directions belonging to the same bi- >> directional connection. >> >> TOM: Again, "SHOULD be capable of" seems better. >> >> o MPLS-TP SHOULD support unidirectional point-to-multipoint >> connections. >> >> o MPLS-TP connections MUST NOT perform merging in a way that >> prevents the unique identification of the source at the >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page 7] >> >> Internet-Draft MPLS-TP Requirements July 2008 >> >> >> destination (e.g. no use of LDP mp2p signaling in order to avoid >> losing LSP head-end information, no use of PHP, etc). >> >> o MPLS-TP SHOULD support transport and QoS mechanisms that can >> deliver statistical multiplexing gain. Packets exceeding the >> agreed traffic profile may be marked or discarded by the traffic >> conditioning at the ingress of the MPLS-TP network. >> >> TOM: How about egress policing + marking? >> >> >> o MPLS-TP MUST support connections through a single domain. >> >> o MPLS-TP SHOULD support connections through multiple domains. >> >> o MPLS-TP MUST be able to accommodate new traffic types. >> >> TOM: New traffic types other than those supported by MPLS? This >> doesn't make sense to me as this will result in MPLS-TP not being a >> subset of MPLS. >> >> o MPLS-TP SHOULD support mechanisms to safeguard against the >> provisioning of connections which contain forwarding loops. >> >> o MPLS-TP SHOULD support mechanisms to minimize traffic impact >> during network reconfiguration. >> >> o MPLS-TP SHOULD support mechanisms which ensure the integrity of >> the adapted information. >> >> o MPLS-TP MUST support an unambiguous and reliable means of >> distinguishing users' (client) packets from MPLS-TP control plane >> and management plane packets. >> >> 2.4. Control plane requirements >> >> o A distributed control plane MAY be supported to enable fast, >> dynamic and reliable service provisioning in multi-vendor and >> multi-domain environments using standardized protocols that >> guarantee interoperability. >> >> o If a control plane is used for configuration of MPLS-TP >> connections then: >> >> * Failure and recovery of the control plane MUST NOT impact the >> MPLS-TP forwarding plane. >> >> TOM: This is difficult, as this really is handled in practice at both >> data and control planes, depending on how this is >> configured/designed, and the re-signaling can impact the data plane. >> >> * It MUST support the setup, modification, and release of MPLS-TP >> connections and protection connections. >> >> * It MUST support mechanisms to provide traffic engineering, >> constraint-based routing and explicit path control. >> >> * It MUST provide mechanisms to address QoS and performance >> requirements (such as throughput, delay, packet loss, etc.) >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page 8] >> >> Internet-Draft MPLS-TP Requirements July 2008 >> >> >> while utilizing network resources efficiently and reliably. >> >> o MPLS-TP SHOULD support off-path (out-of-band) control and >> management planes. >> >> o The MPLS-TP control plane MUST be independent of any particular >> client or server layer control plane. >> >> o The control plane SHOULD facilitate the implementation of the >> service by providing end-to-end seamless connectivity and service >> assurance. >> >> o The MPLS-TP control plane MUST support establishing all the >> connectivity patterns defined for the MPLS-TP transport plane >> (e.g., uni-directional and bidirectional P2P, uni-directional >> P2MP, etc.) including configuration of protection functions and >> any associated maintenance functions. >> >> o The MPLS-TP control pane must support the configuration and >> modification of OAM maintenance points as well as the activation/ >> deactivation of OAM when the connection is established or >> modified. >> >> o An MPLS-TP control plane MUST support topology hiding and address >> independence between domains. >> >> o At the boundary of a domain an MPLS-TP control plane MUST support >> unique names or addresses identifying boundary points to be >> interconnected. >> >> o At the boundary of a domain an MPLS-TP control plane must support >> group names or addresses identifying sets of boundary points to be >> interconnected. >> >> o MPLS-TP layer network access points (or connection points that >> proxy for access points) SHOULD be able to be assigned names which >> are available to clients to identify endpoints in call or >> connection requests. >> >> o An MPLS-TP control plane MUST support translation between >> externally visible endpoint names and internal network addresses. >> >> o An MPLS-TP control plane MUST support constraint-based route >> calculation. >> >> o An MPLS-TP control plane MUST support provisioning and application >> of routing constraint policies. >> >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page 9] >> >> Internet-Draft MPLS-TP Requirements July 2008 >> >> >> o An MPLS-TP control plane MUST support pre-provisioned connection >> protection. >> >> In some situations it is impractical to expect acceptable recovery >> performance to be achieved using dynamic recalculation of connection >> routes. For this reason, it is necessary to allow for pre-planning >> of protection routes for selected connections. >> >> o The MPLS-TP control plane MUST support fast restoration. >> >> TOM: Define what "fast" means? >> >> o An MPLS-TP control plane MUST scale gracefully to support a large >> number of connections. >> >> TOM: Define "large" and "scale" here? >> >> [Include some numbers to indicate how large the CP is expected to >> scale to?] >> >> o An MPLS-TP control plane MUST clearly distinguish resources >> belonging to the MPLS-TP layer network from those in other layer >> networks that may also be under control plane control. >> >> TOM: Do you mean under the same control plane or a different one (or >> both)? >> >> o An MPLS-TP control plane MUST support the independent >> identification of logically distinct control plane elements. >> >> o It MUST be possible to identify and provision these elements >> independently, in order to reorganize the control plane components >> without impacting the data plane services and vice-versa. >> >> Architecturally distinct elements in a control plane include: nodes >> and links, control plane functional components, protocol controllers, >> etc. >> >> o An MPLS-TP control plane SHOULD provide a common control mechanism >> for architecturally similar operations. >> >> o An MPLS-TP control plane MUST support mechanisms for partitioning >> the network under control into separate peer or hierarchical >> control domains. >> >> o To enable the deployment of a unified control plane aimed at >> controlling the set of transport technologies used in a transport >> network, the MPLS-TP control plane MUST also be applicable to >> other transport layer networks and provide common operations >> across multiple layers. In order to maintain independence between >> MPLS-TP and its respective client and server layer network >> separate control plane instances SHOULD be used to control a set >> of transport layer networks. >> >> >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page 10] >> >> Internet-Draft MPLS-TP Requirements July 2008 >> >> >> o MPLS-TP SHOULD detect and recover from control plane failures and >> degradations using graceful operations. >> >> 2.5. Network Management (NM) requirements >> >> o MPLS-TP MUST operate under a common operation, control and >> management paradigm with respect to other transport technologies >> (e.g. SDH, OTN or WDM). >> >> o An MPLS-TP network MUST be able to be operated with a centralized >> NMS system. >> >> o An MPLS-TP network SHOULD be able to be operated by a centralized >> NMS system with the support of a distributed control plane. >> >> TOM: I don't know what this means or the one above it, or how this >> requirement would translate into anything tangible in the MPLS-TP >> protocol designs. I suggest it be removed. >> >> o The MPLS-TP management plane MUST NOT depend on a specific client >> layer management plane. >> >> TOM: This is a non-sequitur if you ask me; please strike it. >> >> o The MPLS-TP management plane MUST support the configuration and >> modification of OAM maintenance points as well as the activation/ >> deactivation of OAM when the connection is established or >> modified. >> >> For the complete set of requirements related to NM functionality for >> MPLS-TP, see the MPLS-TP NM requirements document [REF]. >> >> 2.6. OAM requirements >> >> o MPLS-TP SHOULD provide a comprehensive set of capabilities (that >> are independent of and agnostic to the transmitted client >> services) to support fault management, performance monitoring (of >> the MPLS-TP network and the services), protection switching, fault >> localization, signal quality measurement, etc. >> >> o A mechanism SHOULD be supported to detect, diagnose and enable >> recovery from facility and equipment failures and performance >> degradations according to the requirements of the service. >> >> o MPLS-TP OAM MUST be able to operate without IP functionality and >> without relying on control and/or management planes. >> >> For the complete set of requirements related to OAM functionality for >> MPLS-TP, see the MPLS-TP OAM requirements document [REF]. >> >> TOM: I suggest you just remove these two sections and refer to the >> OAM/Managemetn documents. >> >> 2.7. Network performance management (PM) requirements >> >> >> >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page 11] >> >> Internet-Draft MPLS-TP Requirements July 2008 >> >> >> o MPLS-TP MUST support traffic-engineering capabilities with >> traffic- and/or resource-oriented performance objectives. >> >> TOM: What are performance objectives? Do you mean traffic profiles >> such as QoS/bandwidth? >> >> o MPLS-TP MUST support a method to offer packet loss objectives >> comparable to those in TDM transport networks (only due to bit >> errors). >> >> For the complete set of requirements related to PM functionality for >> MPLS-TP, see the MPLS-TP OAM requirements document [REF]. >> >> TOM: Again, I suggest you punt on this entire section and move it to >> the OAM doc. >> >> 2.8. Protection & Survivability requirements >> >> Network survivability plays a critical factor in the delivery of >> reliable services. Network availability is a significant contributor >> to revenue and profit. Service guarantees in the form of SLAs >> require a resilient network that rapidly detects facility or node >> failures and restores network operation in accordance with the terms >> of the SLA. >> >> The requirements in this section use of the recovery terminology >> defined in RFC 4427[RFC4427]. >> >> o MPLS-TP SHOULD support transport network style protection >> >> TOM: I would make this a MUST. >> >> switching mechanisms (tandem network connection protection, LSP >> protection and PW protection) to provide the sub-50ms recovery >> time required to maintain customer transparency, even when >> thousands of services are simultaneously affected by a failure. >> [Is sub-50ms really a requirement, do we want to clarify this >> further - is it sub-50ms end to end, or per link?] >> >> o >> >> * MPLS-TP recovery mechanisms SHOULD be applicable at various >> levels throughout the network, SPAN, tandem connection and end- >> to-end. >> >> TOM: This sentence doesn't parse. Please re-write. >> >> Any recovery mechanism used in a tandem connection >> MUST be independent of other tandem connections. >> >> * MPLS-TP SHOULD support mechanisms that keep traffic flowing >> while the network recovers from failures. >> >> TOM: I would say this is a MUST. >> >> * MPLS-TP SHOULD support network restoration mechanisms >> controlled by a distributed control plane and/or by a >> management plane based. >> >> TOM: I would say this is a MUST. >> >> >> * >> >> + The restoration resources MAY be pre-planned and selected a >> priori, or computed after failure occurrence. >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page 12] >> >> Internet-Draft MPLS-TP Requirements July 2008 >> >> >> + MPLS-TP MAY support shared-mesh restoration. >> >> + MPLS-TP SHOUD support soft LSP restoration. >> >> + MPLS-TP MAY support hard LSP restoration. >> >> + The restoration mechanism MUST be applicable to any >> topology. >> >> + Restoration priority MAY be implemented to determine the >> order in which connections should be restored (to minimize >> service restoration time as well as to gain access to >> available spare capacity on the best paths). Preemption >> priority MAY be used in the event that not all connections >> can be restored, in which case connections with lower >> preemption priority should be released. >> >> + The restoration mechanism SHOULD operate in synergy with >> other transport network technologies (SDH, OTN, WDM). >> >> * MPLS-TP SHOULD support data plane driven protection mechanisms >> (without any dependency on a control plane or IP protocols) to >> enable fast recovery from failure, and thereby to enhance the >> reliability and availability performance of MPLS-TP networks. >> >> * >> >> + MPLS-TP protection mechanisms SHOULD be applied to LSPs and >> PWs. >> >> + MPLS-TP MUST support mechanisms that rapidly detect, locate, >> notify and remedy network faults. >> >> + MPLS-TP MUST support 1:1 bidirectional protection switching. >> The protection state of both ends of the protected entity >> MUST be synchronized. >> >> + MPLS-TP MAY support 1+1 unidirectional protection switching. >> >> + MPLS-TP protection mechanisms MUST be applicable to both >> point-to-point and point-to-multipoint connections. >> >> + It SHOULD be possible to achieve protection at the MPLS-TP >> layer as fast as possible (subject to the temporal >> resolution of the defect detection mechanism). >> >> + Protection ratio MUST be of 100%, i.e., 100% of impaired >> working traffic MUST be protected for a failure on a >> single >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page 13] >> >> Internet-Draft MPLS-TP Requirements July 2008 >> >> >> working LSP. >> >> + Operator requests for manual control of protection switching >> such as clear, lockout of protection, forced-switch and >> manual-switch commands MUST be supported. Prioritized >> protection between Signal Fail (SF), Signal Degradation (SD) >> and operator switch requests MUST be supported. >> >> + MPLS-TP protection mechanisms MUST support revertive and >> non-revertive behaviour. o An extra traffic capability >> SHOULD be supported when possible. >> >> + MPLS-TP protection switching mechanisms MUST prevent >> frequent operation of the protection switch due to an >> intermittent defect. >> >> + MPLS-TP protection mechanisms MUST ensure co-ordination of >> timing of protection switches at multiple layers to avoid >> races and to allow the protection switching mechanism of the >> server layer to fix the problem before switching at the >> MPLS-TP layer. >> >> + MPLS-TP MAY support mechanisms that are optimized for >> specific network topologies (Ring, Mesh) in order to handle >> protection switching in a cost-efficient manner. >> >> 2.9. QoS requirements >> >> Service providers require advanced traffic management capabilities to >> enforce and guarantee the QoS parameters of customers' SLAs. >> >> Quality of service mechanisms are required to ensure: >> >> o Support for differentiated services and different traffic types >> with traffic class separation associated with different traffic. >> >> o Prioritization of critical services. >> >> o Enabling the provisioning and the guarantee of Service Level >> Specifications (SLS), with support for hard and relative end-to- >> end BW guaranteed. >> >> o Controlled jitter and delay. >> >> o Guarantee of fair access to shared resources in an MPLS-TP >> network. >> >> >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page 14] >> >> Internet-Draft MPLS-TP Requirements July 2008 >> >> >> o Ability for OAM and data to share the same fate. >> >> TOM: This belongs in the OAM document. >> >> >> o Resources for control and management plane packets so that user >> plane traffic, regardless of the amount, will not cause control >> and management functions to become inoperative. >> >> The following QoS requirements apply to MPLS-TP: >> >> o MPLS-TP MUST be able to deliver the same degree of QoS that has >> been delivered by SDH/SONET systems. >> >> TOM: We can save on a lot of text and remove the "MPLS-TE MUST" or >> "MPLS-TP SHOULD" bits and simply say "MUST X" or "SHOULD Y". The >> MPLS-TP bit is implicit I think. >> >> o MPLS-TP MUST support transport bandwidth allocation to any >> granularity without any restrictions based on a circuit-switched >> multiplexing hierarchy. This attribute will provide service >> providers with the capability to route more customer service >> demands over the MPLS-TP network. >> >> [Should we refer here to the requirements specified in RFC 2702?] >> >> 2.10. Security requirements >> >> o MPLS-TP MUST ensure that the network and services are secured. >> >> o Traffic flows from different users MUST NOT be intermingled, but >> if this does occur then this MUST be detectable and the >> appropriate consequent actions taken. >> >> o MPLS-TP MUST ensure the separation of customer (client) and >> provider (server and peer network) addressing and other >> information. >> >> TOM: This requirement is stated above. >> >> o MPLS-TP MUST ensure that the control and management planes as well >> as OAM traffic are secure from external attack. >> >> o MPLS-TP MUST provide mechanisms to ensure that the MPLS-TP network >> remains secure and stable under situations of extreme stress. >> >> Examples of attacks and situations of extreme stress include (but are >> not limited to) classical security attacks (e.g., hijacking, privacy, >> non-repudiation, etc.) and attacks on network availability (e.g., >> denial of service (DoS) attacks). >> >> >> 3. IANA Considerations >> >> This document makes no request of IANA. >> >> Note to RFC Editor: this section may be removed on publication as >> an >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page 15] >> >> Internet-Draft MPLS-TP Requirements July 2008 >> >> >> RFC. >> >> >> 4. Security Considerations >> >> This document does not by itself raise any particular security >> considerations. >> >> >> 5. Acknowledgements >> >> The authors wish to thank Neil Harrison and Tomonori Takeda for their >> review and enhancements to the text. >> >> >> 6. Informative References >> >> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate >> Requirement Levels", BCP 14, RFC 2119, March 1997. >> >> [RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and >> Restoration) Terminology for Generalized Multi-Protocol >> Label Switching (GMPLS)", RFC 4427, March 2006. >> >> [ITU.Y1401.2008] >> International Telecommunications Union, "Principles of >> interworking", ITU-T Recommendation Y.1401, February 2008. >> >> >> Authors' Addresses >> >> Ben Niven-Jenkins (editor) >> BT >> 208 Callisto House, Adastral Park >> Ipswich, Suffolk IP5 3RE >> UK >> >> Email: benjamin.niven-jenkins@bt.com >> >> >> Deborah Brungard (editor) >> AT&T >> Rm. D1-3C22 - 200 S. Laurel Ave. >> Middletown, NJ 07748 >> USA >> >> Email: dbrungard@att.com >> >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page 16] >> >> Internet-Draft MPLS-TP Requirements July 2008 >> >> >> Malcolm Betts (editor) >> Nortel Networks >> 3500 Carling Avenue >> Ottawa, Ontario K2H 8E9 >> Canada >> >> Email: betts01@nortel.com >> >> >> Nurit Sprecher >> Nokia Siemens Networks >> 3 Hanagar St. Neve Ne'eman B >> Hod Hasharon, 45241 >> Israel >> >> Email: nurit.sprecher@nsn.com >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page 17] >> >> Internet-Draft MPLS-TP Requirements July 2008 >> >> >> Full Copyright Statement >> >> Copyright (C) The IETF Trust (2008). >> >> 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, THE IETF TRUST 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. >> >> >> Intellectual Property >> >> 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. >> >> >> >> >> >> >> >> >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page 18] >> >> >> >> _______________________________________________ >> Mpls-interop mailing list >> Mpls-interop@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-interop > _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop From mpls-interop-bounces@ietf.org Sun Jun 22 07:37:17 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D1823A68C0; Sun, 22 Jun 2008 07:37:17 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EC443A68C0 for ; Sun, 22 Jun 2008 07:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.382 X-Spam-Level: X-Spam-Status: No, score=-4.382 tagged_above=-999 required=5 tests=[AWL=1.617, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nh6AZSs4l5iu for ; Sun, 22 Jun 2008 07:37:13 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 099AC3A69CE for ; Sun, 22 Jun 2008 07:37:11 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m5MEbESX012070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Jun 2008 16:37:14 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m5MEbEVD017160; Sun, 22 Jun 2008 16:37:14 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 22 Jun 2008 16:37:14 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 22 Jun 2008 16:37:14 +0200 Message-ID: <9FF5BDAD88B9D84881609E89AC92FB83EBD397@DEMUEXC014.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mpls-interop] next MEAD team meeting Thread-Index: AcjSMNQsx4BuurjX8EeQxIcfmO8exAA0/R+VAEuIunAACtuUpAABrZoIAAOpdbA= From: "Sprecher, Nurit (NSN - IL/Israel - MiniMD)" To: "ext Ben Niven-Jenkins" , "Thomas Nadeau" , "Loa Andersson" , "MEAD team" X-OriginalArrivalTime: 22 Jun 2008 14:37:14.0515 (UTC) FILETIME=[768B1E30:01C8D475] Cc: "Weingarten, Yaacov \(NSN - IL/Israel - MiniMD\)" Subject: Re: [Mpls-interop] next MEAD team meeting X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org Thanks Ben for clarifying this. I see the point (also reading Andy's response). -----Original Message----- From: ext Ben Niven-Jenkins [mailto:benjamin.niven-jenkins@bt.com] Sent: Sunday, June 22, 2008 15:40 To: Thomas Nadeau; Sprecher, Nurit (NSN - IL/Israel - MiniMD); Loa Andersson; MEAD team Cc: Weingarten, Yaacov (NSN - IL/Israel - MiniMD) Subject: Re: [Mpls-interop] next MEAD team meeting I think the key thing is that MPLS-TP must be able to operate (including OAM) in the absence of a control plane. The option is then down to whether we say both static & dynamic are MUSTs (from an implementation perspective) and the operator is then free to choose whether they operate their network statically or dynamically. Or whether only static is a MUST and dynamic is optional (for implementation). I believe the work in ITU intended to extend to dynamic at some point and static was just a first step in the T-MPLS work. It only take one operator to demand dynamic from their vendors for it to be present in equipment anyway even if it is not used by other operators. So I think we can make both static & dynamic MUSTs and then clarify that when operating in a static mode MPLS-TP must not rely on any dynamic protocols. We cover this (at least to some extent) already with requirements such as " Static provisioning MUST not depend on routing or signaling protocols (e.g. GMPLS, OSPF, IS-IS, RSVP, BGP, LDP etc.)." Ben On 22/06/2008 12:51, "Thomas Nadeau" wrote: > > > > On 6/22/08 5:45 AM, "Sprecher, Nurit (NSN - IL/Israel - MiniMD)" > wrote: > >> Hi Thomas, >> Thanks for your comments. >> I still need to get into the details and meanings of your comments, >> but in the meantime I have one basic concern on your comment on " >> MPLS-TP connections MAY be able to be provisioned dynamically via a >> control plane. TOM: I insist that we change the MAY above to MUST. I >> want a dynamic version of this as much as a static one." >> This is one of the fundamental principles of the MPLS-TP, that the >> presence of a distributed control plane in support of network >> operations is optional (as in other transport technologies, like in SDH, etc.). > > I agree it is optional. What I want to make sure is that it is not > so optional that it is completely removed from the design. The > language in the document now seems to be headed in that direction. > >> This is also the trigger for the definition of OAM capabilities which >> are independent of a control plane, as well as of the protection >> switching, etc. >> This is also addressed by the slides of the JW: "Desire to statically >> configure LSPs and PWEs via the management plane... > > I am not arguing against static; I am arguing for dynamic to be in > there as well. > >> Transport OAM capabilities don't exist for LSP and PWE independent of >> configuration mechanism (management plane or GMPLS or PWE control >> plane)... > > It depends on how you look at what "transport OAM capabilities". > From my perspective at BT, I definitely think there is a dynamic > flavor of this for sure. Again, I am not advocating removal of the > static parts, just the addition of the dynamic ones. And since they > are already there in large part, as part of the base MPLS > specification, I don't see any harm in specifying this. > > --Tom > > > >> With static provisioning, no dependency on routing or signaling (e.g. >> GMPLS or, IGP, RSVP, BGP, LDP)", etc. >> Best regards, >> Nurit >> >> -----Original Message----- >> From: mpls-interop-bounces@ietf.org >> [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext Thomas Nadeau >> Sent: Friday, June 20, 2008 21:38 >> To: Ben Niven-Jenkins; Loa Andersson; MEAD team >> Subject: Re: [Mpls-interop] next MEAD team meeting >> >> >> Comments on the document inline start with "TOM:" >> In general, please review the document and put more of an emphasis on >> the use of "MUST" rather than "MAY" or "SHOULD". The IETG frowns on >> requirements documents that are too optional. >> >> --Tom >> >> >> >> >> >> Network Working Group B. Niven-Jenkins, Ed. >> Internet-Draft BT >> Intended status: Informational D. Brungard, Ed. >> Expires: January 2, 2009 AT&T >> M. Betts, Ed. >> Nortel Networks >> N. Sprecher >> Nokia Siemens Networks >> July 01, >> 2008 >> >> >> MPLS-TP Requirements >> draft-jenkins-mpls-mplstp-requirements-00 >> >> Status of this Memo >> >> By submitting this Internet-Draft, each author represents that any >> applicable patent or other IPR claims of which he or she is aware >> have been or will be disclosed, and any of which he or she becomes >> aware will be disclosed, in accordance with Section 6 of BCP 79. >> >> 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. >> >> This Internet-Draft will expire on January 2, 2009. >> >> Abstract >> >> This document will outline the requirements for MPLS-TP. >> >> Requirements Language >> >> 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 [RFC2119]. >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page 1] >> >> Internet-Draft MPLS-TP Requirements July 2008 >> >> >> Table of Contents >> >> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 >> 2. MPLS-TP Requirements . . . . . . . . . . . . . . . . . . . . . 5 >> 2.1. General requirements . . . . . . . . . . . . . . . . . . . 5 >> 2.2. Layering requirements . . . . . . . . . . . . . . . . . . 6 >> 2.3. Data plane requirements . . . . . . . . . . . . . . . . . 7 >> 2.4. Control plane requirements . . . . . . . . . . . . . . . . 8 >> 2.5. Network Management (NM) requirements . . . . . . . . . . . 11 >> 2.6. OAM requirements . . . . . . . . . . . . . . . . . . . . . 11 >> 2.7. Network performance management (PM) requirements . . . . . 11 >> 2.8. Protection & Survivability requirements . . . . . . . . . 12 >> 2.9. QoS requirements . . . . . . . . . . . . . . . . . . . . . 14 >> 2.10. Security requirements . . . . . . . . . . . . . . . . . . 15 >> 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 >> 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 >> 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 >> 6. Informative References . . . . . . . . . . . . . . . . . . . . 16 >> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 >> Intellectual Property and Copyright Statements . . . . . . . . . . >> 18 >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page 2] >> >> Internet-Draft MPLS-TP Requirements July 2008 >> >> >> 1. Introduction >> >> For many years, SONET/SDH has provided service providers with a high >> benchmark for reliability and operational simplicity. With the >> accelerating growth of packet-based services (such as Ethernet, VoIP, >> L2/L3 VPN, IPTV, RAN backhauling, etc.), service providers are in >> need of capabilities to efficiently support packet-based services on >> their transport networks. The need to increase their revenue while >> remaining competitive forces operators to look for the lowest network >> Total Cost of Ownership (TCO). Investment in both Capital >> Expenditure (CAPEX) and Operational Expense (OPEX) should be minimal. >> >> Carriers are considering migrating to packet transport networks in >> order to reduce their costs and to improve their ability to support >> services with guaranteed SLAs. Migrating from SONET/SDH to packet >> transport networks should not involve dramatic changes in network >> operation, should not necessitate extensive retraining, and should >> not require major changes to existing work practices. The aim is to >> preserve the look-and-feel to which carriers have become accustomed >> in deploying their SONET/SDH networks, while providing common, multi- >> layer operations, resiliency, control and management for packet, >> circuit and lambda transport networks. >> >> An important attribute of a transport network is its ability to >> function independently from both its client and server (transmission >> media) layer networks. It should be capable of transmitting over any >> media. Another key characteristic of transport networks is the >> capability to maintain the integrity of the client signal between its >> ingress and egress ports. >> >> TOM: I would use something other than "client signal" here. Something >> like "client path" or something is what I think you mean. >> >> A transport network must provide the means >> to commit quality of service objectives to clients. This is achieved >> by providing a mechanism for client network service demarcation for >> the network path together with an associated network resiliency >> mechanism. A transport network must also provide a method of service >> monitoring in order to verify the delivery of an agreed quality of >> service. This is enabled by means of carrier-grade OAM tools. >> >> The connectivity service is the basic service provided by a transport >> network. >> >> TOM: Is it? Does the transport really provide connections or does it >> provide transport paths? I am sensitive to the terms used here. We >> don't want this to become a connect-fest. Seems to me that you >> explain this better in the next sentence anyhow. >> >> The purpose of a transport network is to transparently >> carry client signals (i.e. the stream of client PDUs or client >> bits) >> >> TOM: Again, I don't like the term "signals" here. Use "client data" >> or something. >> >> between endpoints in the network (typically over several intermediate >> nodes). These endpoints may be service switching points or service >> terminating points. The connectivity services offered to customers >> are aggregated into large, long-holding time pipes/trunks which >> >> TOM: Do you really mean to call these "time pipes"? Sounds too >> futuristic even for this work. *) I think you mean "...into >> relatively large, long-lasting paths..." >> >> enable the efficient and reliable operation of the transport network. >> These trunks are modified infrequently. >> >> TOM: Keep the terminology consistent here too. There is the use of >> "trunks", "pipes", etc... >> >> Aggregation and hierarchy are beneficial for achieving scalability >> and security since: >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page 3] >> >> Internet-Draft MPLS-TP Requirements July 2008 >> >> >> 1. They reduce the number of provisioning and forwarding states in >> the network core. >> >> 2. They reduce load and the cost of implementing service assurance >> and fault management. >> >> TOM: Do they really reduce load? This is one of those fluffy, >> open-ended terms like "scaleability" that I don't like used unless it >> is clearly defined. >> >> 3. Client signals are completely encapsulated and isolated from each >> other. This also allows complete isolation of customer traffic >> from carrier operations. >> >> TOM: Does this really happen at the data or control plane or both? Or >> do we care? >> >> >> Client signals are first transparently encapsulated. These >> encapsulated client signals are then aggregated for transport through >> the network in order to optimize network management. Server layer >> OAM is used to monitor the transport integrity of the client layer >> aggregate. At any hop, the aggregated signals may be further >> aggregated in lower layer transport network paths for transport >> across intermediate shared links. The encapsulated client signals >> are extracted at the edges of aggregation domains, and are either >> delivered to the client or forwarded to another domain. In the core >> of the network, only the server layer aggregated signals are >> monitored; individual client signals are monitored at the network >> boundary in the client layer network. >> >> TOM: I am not sure the above is appropriate for a requirements document. >> It sounds like you are spelling out an algorithm for how a solution >> should work. >> >> Quality-of-service mechanisms are required in the packet transport >> network to ensure the prioritization of critical services, to >> guarantee BW and to control jitter and delay. >> >> TOM: Are they required everywhere the service exists, or say just at >> the ingress/egress for policing/marking functions? While we are on >> the subject, do we want to be more specific about QoS requirements? >> >> Service providers require control and deterministic usage of network >> resources. They need end-to-end control to engineer network paths >> and to efficiently utilize network resources. They require >> capabilities to statically (OSS based) provision deterministic, >> protected and secured services and their associated resources as well >> as alternative control-plane options. >> >> TOM: They also require dynamic ones. Please put that in. I don't >> want to be asking for only a completely static system. >> >> The transport network must be capable of transporting multiple >> services in a scalable manner. >> >> TOM: Again, this use of "scalable" offends me. Please be more >> specific or take the sentence out as it is meaningless as stated. >> >> Carriers will still need to cope with legacy networks (which are >> composed of many layers and technologies), thus the packet transport >> network should interwork with other packet and transport networks >> (both horizontally and vertically). Vertical interworking is also >> known as client/server or network interworking. Horizontal >> interworking is also known as peer-partition or service interworking. >> >> TOM: Didn't you just say that vertical interworking was client >> interworking in the first sentence? How can horizontal be service >> interworking as well? >> >> For more details on each type of interworking and some of the issues >> that may arise (especially with horizontal interworking) see >> [ITU.Y1401.2008]. >> >> MPLS is a maturing packet technology and it is already playing an >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page 4] >> >> Internet-Draft MPLS-TP Requirements July 2008 >> >> >> important role in transport networks and services. However, not all >> of MPLS's capabilities and mechnisms are needed and/or consistent >> with transport network operations. This document identifies the >> required capabilities for MPLS so that it can better fit a transport >> role. >> >> TOM: I think you want to say "identifies the required sub-set of >> capabilities..." and later "potentially new ons specific for >> transport networks" which it seems you say two paragraphs later. >> >> Combining the packet experience of MPLS with the operational >> experience of SONET/SDH constitutes a packet transport technology >> named MPLS-TP. MPLS-TP will enable the migration of SONET/SDH >> networks to a packet-based network that will easily scale to support >> packet services in a simple and cost effective way. >> >> MPLS-TP needs to combine the necessary existing capabilities of MPLS >> with additional minimal mechanisms in order to meet the requirements >> described in this document. >> >> The requirements of an MPLS transport profile are provided below. >> >> TOM: There is a terminology issue in the use of "MPLS-TP" or "an MPLS >> transport profile". That is, on the one hand you refer to a >> technology, but on the other hand you are referring to a specific >> profile. Which is it? >> >> >> 2. MPLS-TP Requirements >> >> 2.1. General requirements >> >> o MPLS-TP MUST offer as much commonality as possible with the MPLS >> user plane as defined by IETF. When MPLS offers multiple options >> in this respect, MPLS-TP SHOULD select the minimum sub-set >> (necessary and sufficient subset) applicable to a transport >> network application. >> >> o Any new functionality that is defined to fulfil the requirements >> for MPLS-TP MUST be agreed within IETF and re-use (as far as >> practically possible) existing MPLS standards. >> >> o Mechanisms and capabilities MUST be able to interoperate with >> existing MPLS and PWE control and data planes where appropriate. >> >> TOM: Change PWE to "IETF PWE3" and "MPLS" to "IETF MPLS". There also >> need to be references here to the PWE3 architecture and MPLS >> architectures. >> >> o MPLS-TP MUST support traffic engineering capabilities that allow >> deterministic control of the use of network resources. >> >> o MPLS-TP MUST support the logical separation of the control and >> management planes from the user plane. >> >> o MPLS-TP SHOULD support the physical separation of the control and >> management planes from the user plane. >> >> o MPLS-TP MUST support point to point (P2P) or point to multipoint >> (P2MP) connections. >> >> TOM: Are we avoiding MP2MP consciously or was it left out? >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page 5] >> >> Internet-Draft MPLS-TP Requirements July 2008 >> >> >> o MPLS-TP MUST support static provisioning of connections via an >> NMS/OSS (i.e. via the management plane). >> >> o Static provisioning MUST not depend on routing or signaling >> protocols (e.g. GMPLS, OSPF, IS-IS, RSVP, BGP, LDP etc.). >> >> o MPLS-TP connections MAY be able to be provisioned dynamically via >> a control plane. >> >> TOM: I insist that we change the MAY above to MUST. I want a dynamic >> version of this as much as a static one. >> >> >> o The MPLS-TP data plane MUST be capable of functioning >> independently of the control or management plane used to operate >> the MPLS-TP layer network. That is the MPLS-TP data plane >> operation MUST continue to operate normally if the management >> plane or control plane that configured the connections fails. >> >> o MPLS-TP MUST support any network topology and be able to support >> increasing bandwidth demands, topology, number of customers or >> number of services incrementally. >> >> >> TOM: I think it is imperative that although an MPLS-TP is defined to >> play nicely with an MPLS one, it is imperative that one can >> distinguish between both, at least at the control plane, but perhaps >> at the data plane as well. >> >> 2.2. Layering requirements >> >> o An MPLS-TP network MUST operate in a multiple layer network >> environment consisting of the following independent layers: >> >> 1. A "service layer" instance in which the connections carry the >> customer's (individual or bundled) service (may be point-to- >> point, point-to-multipoint or multipoint-to-multipoint >> services); >> >> 2. A "trunk layer" with point-to-point or point-to-multipoint >> connections which are used to carry aggregates of the network >> "service layer" connections; and >> >> 3. A "transmission media layer" which provides sections (two-port >> point-to-point connections) to carry the aggregate of network >> trunk or network service connections on various physical >> media. >> >> TOM: This stuff belongs in the Terminology section at the top. >> >> MPLS-TP may provide the "service layer" (for P2P and P2MP services) >> and/or the "trunk layer" within a layer network environment. >> >> o An MPLS-TP layer network MUST support the transparent transport of >> MPLS-TP and non MPLS-TP client layer networks. >> >> o An MPLS-TP layer network MUST be able to be transparently carried >> over MPLS-TP and non MPLS-TP server layer networks (such as >> Ethernet, OTN, etc.) >> >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page 6] >> >> Internet-Draft MPLS-TP Requirements July 2008 >> >> >> o It MUST be possible to operate the MPLS-TP layer network >> independently of other layer networks (either MPLS-TP or non >> MPLS-TP). >> >> This is not only a technology requirement, different administrative >> groups may be responsible for different layer networks (even when >> they are of the same type)), and require the capability to >> operationally support the different layers. >> >> o It MUST be possible to hide MPLS-TP layer network addressing and >> other information (e.g. topology) from client layers. >> >> 2.3. Data plane requirements >> >> o The identification of each connection within its aggregate MUST be >> supported. >> >> o A label in a particular section MUST uniquely identify the >> connection. >> >> o A connection's source MUST be identifiable at its destination. >> >> Connections can be aggregated into trunks by pushing and de- >> aggregated by popping labels. MPLS-TP labels may be swapped within a >> connection in a layer network instance when the traffic is forwarded >> from one MPLS-TP link connection to another MPLS-TP link connection. >> >> o Labelling MUST make use of the MPLS label and label stack entry as >> defined in RFC3032. >> >> o It MUST be possible to operate and configure the MPLS-TP data >> (transport) plane without any IP functionality. >> >> o MPLS-TP MUST support both unidirectional and bi-directional point- >> to-point connections. >> >> o The forward and backward directions of a bi-directional connection >> SHOULD follow the same path within the MPLS-TP network. >> >> TOM: I am not sure if we say that they SHOULD as much as "they MUST >> be capable of". >> >> o The intermediate nodes SHOULD be aware about the binding of the >> forward and the backward directions belonging to the same bi- >> directional connection. >> >> TOM: Again, "SHOULD be capable of" seems better. >> >> o MPLS-TP SHOULD support unidirectional point-to-multipoint >> connections. >> >> o MPLS-TP connections MUST NOT perform merging in a way that >> prevents the unique identification of the source at the >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page 7] >> >> Internet-Draft MPLS-TP Requirements July 2008 >> >> >> destination (e.g. no use of LDP mp2p signaling in order to avoid >> losing LSP head-end information, no use of PHP, etc). >> >> o MPLS-TP SHOULD support transport and QoS mechanisms that can >> deliver statistical multiplexing gain. Packets exceeding the >> agreed traffic profile may be marked or discarded by the traffic >> conditioning at the ingress of the MPLS-TP network. >> >> TOM: How about egress policing + marking? >> >> >> o MPLS-TP MUST support connections through a single domain. >> >> o MPLS-TP SHOULD support connections through multiple domains. >> >> o MPLS-TP MUST be able to accommodate new traffic types. >> >> TOM: New traffic types other than those supported by MPLS? This >> doesn't make sense to me as this will result in MPLS-TP not being a >> subset of MPLS. >> >> o MPLS-TP SHOULD support mechanisms to safeguard against the >> provisioning of connections which contain forwarding loops. >> >> o MPLS-TP SHOULD support mechanisms to minimize traffic impact >> during network reconfiguration. >> >> o MPLS-TP SHOULD support mechanisms which ensure the integrity of >> the adapted information. >> >> o MPLS-TP MUST support an unambiguous and reliable means of >> distinguishing users' (client) packets from MPLS-TP control plane >> and management plane packets. >> >> 2.4. Control plane requirements >> >> o A distributed control plane MAY be supported to enable fast, >> dynamic and reliable service provisioning in multi-vendor and >> multi-domain environments using standardized protocols that >> guarantee interoperability. >> >> o If a control plane is used for configuration of MPLS-TP >> connections then: >> >> * Failure and recovery of the control plane MUST NOT impact the >> MPLS-TP forwarding plane. >> >> TOM: This is difficult, as this really is handled in practice at both >> data and control planes, depending on how this is >> configured/designed, and the re-signaling can impact the data plane. >> >> * It MUST support the setup, modification, and release of MPLS-TP >> connections and protection connections. >> >> * It MUST support mechanisms to provide traffic engineering, >> constraint-based routing and explicit path control. >> >> * It MUST provide mechanisms to address QoS and performance >> requirements (such as throughput, delay, packet loss, etc.) >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page 8] >> >> Internet-Draft MPLS-TP Requirements July 2008 >> >> >> while utilizing network resources efficiently and reliably. >> >> o MPLS-TP SHOULD support off-path (out-of-band) control and >> management planes. >> >> o The MPLS-TP control plane MUST be independent of any particular >> client or server layer control plane. >> >> o The control plane SHOULD facilitate the implementation of the >> service by providing end-to-end seamless connectivity and service >> assurance. >> >> o The MPLS-TP control plane MUST support establishing all the >> connectivity patterns defined for the MPLS-TP transport plane >> (e.g., uni-directional and bidirectional P2P, uni-directional >> P2MP, etc.) including configuration of protection functions and >> any associated maintenance functions. >> >> o The MPLS-TP control pane must support the configuration and >> modification of OAM maintenance points as well as the activation/ >> deactivation of OAM when the connection is established or >> modified. >> >> o An MPLS-TP control plane MUST support topology hiding and address >> independence between domains. >> >> o At the boundary of a domain an MPLS-TP control plane MUST support >> unique names or addresses identifying boundary points to be >> interconnected. >> >> o At the boundary of a domain an MPLS-TP control plane must support >> group names or addresses identifying sets of boundary points to be >> interconnected. >> >> o MPLS-TP layer network access points (or connection points that >> proxy for access points) SHOULD be able to be assigned names which >> are available to clients to identify endpoints in call or >> connection requests. >> >> o An MPLS-TP control plane MUST support translation between >> externally visible endpoint names and internal network addresses. >> >> o An MPLS-TP control plane MUST support constraint-based route >> calculation. >> >> o An MPLS-TP control plane MUST support provisioning and application >> of routing constraint policies. >> >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page 9] >> >> Internet-Draft MPLS-TP Requirements July 2008 >> >> >> o An MPLS-TP control plane MUST support pre-provisioned connection >> protection. >> >> In some situations it is impractical to expect acceptable recovery >> performance to be achieved using dynamic recalculation of connection >> routes. For this reason, it is necessary to allow for pre-planning >> of protection routes for selected connections. >> >> o The MPLS-TP control plane MUST support fast restoration. >> >> TOM: Define what "fast" means? >> >> o An MPLS-TP control plane MUST scale gracefully to support a large >> number of connections. >> >> TOM: Define "large" and "scale" here? >> >> [Include some numbers to indicate how large the CP is expected to >> scale to?] >> >> o An MPLS-TP control plane MUST clearly distinguish resources >> belonging to the MPLS-TP layer network from those in other layer >> networks that may also be under control plane control. >> >> TOM: Do you mean under the same control plane or a different one (or >> both)? >> >> o An MPLS-TP control plane MUST support the independent >> identification of logically distinct control plane elements. >> >> o It MUST be possible to identify and provision these elements >> independently, in order to reorganize the control plane components >> without impacting the data plane services and vice-versa. >> >> Architecturally distinct elements in a control plane include: nodes >> and links, control plane functional components, protocol controllers, >> etc. >> >> o An MPLS-TP control plane SHOULD provide a common control mechanism >> for architecturally similar operations. >> >> o An MPLS-TP control plane MUST support mechanisms for partitioning >> the network under control into separate peer or hierarchical >> control domains. >> >> o To enable the deployment of a unified control plane aimed at >> controlling the set of transport technologies used in a transport >> network, the MPLS-TP control plane MUST also be applicable to >> other transport layer networks and provide common operations >> across multiple layers. In order to maintain independence between >> MPLS-TP and its respective client and server layer network >> separate control plane instances SHOULD be used to control a set >> of transport layer networks. >> >> >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page 10] >> >> Internet-Draft MPLS-TP Requirements July 2008 >> >> >> o MPLS-TP SHOULD detect and recover from control plane failures and >> degradations using graceful operations. >> >> 2.5. Network Management (NM) requirements >> >> o MPLS-TP MUST operate under a common operation, control and >> management paradigm with respect to other transport technologies >> (e.g. SDH, OTN or WDM). >> >> o An MPLS-TP network MUST be able to be operated with a centralized >> NMS system. >> >> o An MPLS-TP network SHOULD be able to be operated by a centralized >> NMS system with the support of a distributed control plane. >> >> TOM: I don't know what this means or the one above it, or how this >> requirement would translate into anything tangible in the MPLS-TP >> protocol designs. I suggest it be removed. >> >> o The MPLS-TP management plane MUST NOT depend on a specific client >> layer management plane. >> >> TOM: This is a non-sequitur if you ask me; please strike it. >> >> o The MPLS-TP management plane MUST support the configuration and >> modification of OAM maintenance points as well as the activation/ >> deactivation of OAM when the connection is established or >> modified. >> >> For the complete set of requirements related to NM functionality for >> MPLS-TP, see the MPLS-TP NM requirements document [REF]. >> >> 2.6. OAM requirements >> >> o MPLS-TP SHOULD provide a comprehensive set of capabilities (that >> are independent of and agnostic to the transmitted client >> services) to support fault management, performance monitoring (of >> the MPLS-TP network and the services), protection switching, fault >> localization, signal quality measurement, etc. >> >> o A mechanism SHOULD be supported to detect, diagnose and enable >> recovery from facility and equipment failures and performance >> degradations according to the requirements of the service. >> >> o MPLS-TP OAM MUST be able to operate without IP functionality and >> without relying on control and/or management planes. >> >> For the complete set of requirements related to OAM functionality for >> MPLS-TP, see the MPLS-TP OAM requirements document [REF]. >> >> TOM: I suggest you just remove these two sections and refer to the >> OAM/Managemetn documents. >> >> 2.7. Network performance management (PM) requirements >> >> >> >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page 11] >> >> Internet-Draft MPLS-TP Requirements July 2008 >> >> >> o MPLS-TP MUST support traffic-engineering capabilities with >> traffic- and/or resource-oriented performance objectives. >> >> TOM: What are performance objectives? Do you mean traffic profiles >> such as QoS/bandwidth? >> >> o MPLS-TP MUST support a method to offer packet loss objectives >> comparable to those in TDM transport networks (only due to bit >> errors). >> >> For the complete set of requirements related to PM functionality for >> MPLS-TP, see the MPLS-TP OAM requirements document [REF]. >> >> TOM: Again, I suggest you punt on this entire section and move it to >> the OAM doc. >> >> 2.8. Protection & Survivability requirements >> >> Network survivability plays a critical factor in the delivery of >> reliable services. Network availability is a significant contributor >> to revenue and profit. Service guarantees in the form of SLAs >> require a resilient network that rapidly detects facility or node >> failures and restores network operation in accordance with the terms >> of the SLA. >> >> The requirements in this section use of the recovery terminology >> defined in RFC 4427[RFC4427]. >> >> o MPLS-TP SHOULD support transport network style protection >> >> TOM: I would make this a MUST. >> >> switching mechanisms (tandem network connection protection, LSP >> protection and PW protection) to provide the sub-50ms recovery >> time required to maintain customer transparency, even when >> thousands of services are simultaneously affected by a failure. >> [Is sub-50ms really a requirement, do we want to clarify this >> further - is it sub-50ms end to end, or per link?] >> >> o >> >> * MPLS-TP recovery mechanisms SHOULD be applicable at various >> levels throughout the network, SPAN, tandem connection and end- >> to-end. >> >> TOM: This sentence doesn't parse. Please re-write. >> >> Any recovery mechanism used in a tandem connection >> MUST be independent of other tandem connections. >> >> * MPLS-TP SHOULD support mechanisms that keep traffic flowing >> while the network recovers from failures. >> >> TOM: I would say this is a MUST. >> >> * MPLS-TP SHOULD support network restoration mechanisms >> controlled by a distributed control plane and/or by a >> management plane based. >> >> TOM: I would say this is a MUST. >> >> >> * >> >> + The restoration resources MAY be pre-planned and selected a >> priori, or computed after failure occurrence. >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page 12] >> >> Internet-Draft MPLS-TP Requirements July 2008 >> >> >> + MPLS-TP MAY support shared-mesh restoration. >> >> + MPLS-TP SHOUD support soft LSP restoration. >> >> + MPLS-TP MAY support hard LSP restoration. >> >> + The restoration mechanism MUST be applicable to any >> topology. >> >> + Restoration priority MAY be implemented to determine the >> order in which connections should be restored (to minimize >> service restoration time as well as to gain access to >> available spare capacity on the best paths). Preemption >> priority MAY be used in the event that not all connections >> can be restored, in which case connections with lower >> preemption priority should be released. >> >> + The restoration mechanism SHOULD operate in synergy with >> other transport network technologies (SDH, OTN, WDM). >> >> * MPLS-TP SHOULD support data plane driven protection mechanisms >> (without any dependency on a control plane or IP protocols) to >> enable fast recovery from failure, and thereby to enhance the >> reliability and availability performance of MPLS-TP networks. >> >> * >> >> + MPLS-TP protection mechanisms SHOULD be applied to LSPs and >> PWs. >> >> + MPLS-TP MUST support mechanisms that rapidly detect, locate, >> notify and remedy network faults. >> >> + MPLS-TP MUST support 1:1 bidirectional protection switching. >> The protection state of both ends of the protected entity >> MUST be synchronized. >> >> + MPLS-TP MAY support 1+1 unidirectional protection switching. >> >> + MPLS-TP protection mechanisms MUST be applicable to both >> point-to-point and point-to-multipoint connections. >> >> + It SHOULD be possible to achieve protection at the MPLS-TP >> layer as fast as possible (subject to the temporal >> resolution of the defect detection mechanism). >> >> + Protection ratio MUST be of 100%, i.e., 100% of impaired >> working traffic MUST be protected for a failure on a >> single >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page 13] >> >> Internet-Draft MPLS-TP Requirements July 2008 >> >> >> working LSP. >> >> + Operator requests for manual control of protection switching >> such as clear, lockout of protection, forced-switch and >> manual-switch commands MUST be supported. Prioritized >> protection between Signal Fail (SF), Signal Degradation (SD) >> and operator switch requests MUST be supported. >> >> + MPLS-TP protection mechanisms MUST support revertive and >> non-revertive behaviour. o An extra traffic capability >> SHOULD be supported when possible. >> >> + MPLS-TP protection switching mechanisms MUST prevent >> frequent operation of the protection switch due to an >> intermittent defect. >> >> + MPLS-TP protection mechanisms MUST ensure co-ordination of >> timing of protection switches at multiple layers to avoid >> races and to allow the protection switching mechanism of the >> server layer to fix the problem before switching at the >> MPLS-TP layer. >> >> + MPLS-TP MAY support mechanisms that are optimized for >> specific network topologies (Ring, Mesh) in order to handle >> protection switching in a cost-efficient manner. >> >> 2.9. QoS requirements >> >> Service providers require advanced traffic management capabilities to >> enforce and guarantee the QoS parameters of customers' SLAs. >> >> Quality of service mechanisms are required to ensure: >> >> o Support for differentiated services and different traffic types >> with traffic class separation associated with different traffic. >> >> o Prioritization of critical services. >> >> o Enabling the provisioning and the guarantee of Service Level >> Specifications (SLS), with support for hard and relative end-to- >> end BW guaranteed. >> >> o Controlled jitter and delay. >> >> o Guarantee of fair access to shared resources in an MPLS-TP >> network. >> >> >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page 14] >> >> Internet-Draft MPLS-TP Requirements July 2008 >> >> >> o Ability for OAM and data to share the same fate. >> >> TOM: This belongs in the OAM document. >> >> >> o Resources for control and management plane packets so that user >> plane traffic, regardless of the amount, will not cause control >> and management functions to become inoperative. >> >> The following QoS requirements apply to MPLS-TP: >> >> o MPLS-TP MUST be able to deliver the same degree of QoS that has >> been delivered by SDH/SONET systems. >> >> TOM: We can save on a lot of text and remove the "MPLS-TE MUST" or >> "MPLS-TP SHOULD" bits and simply say "MUST X" or "SHOULD Y". The >> MPLS-TP bit is implicit I think. >> >> o MPLS-TP MUST support transport bandwidth allocation to any >> granularity without any restrictions based on a circuit-switched >> multiplexing hierarchy. This attribute will provide service >> providers with the capability to route more customer service >> demands over the MPLS-TP network. >> >> [Should we refer here to the requirements specified in RFC 2702?] >> >> 2.10. Security requirements >> >> o MPLS-TP MUST ensure that the network and services are secured. >> >> o Traffic flows from different users MUST NOT be intermingled, but >> if this does occur then this MUST be detectable and the >> appropriate consequent actions taken. >> >> o MPLS-TP MUST ensure the separation of customer (client) and >> provider (server and peer network) addressing and other >> information. >> >> TOM: This requirement is stated above. >> >> o MPLS-TP MUST ensure that the control and management planes as well >> as OAM traffic are secure from external attack. >> >> o MPLS-TP MUST provide mechanisms to ensure that the MPLS-TP network >> remains secure and stable under situations of extreme stress. >> >> Examples of attacks and situations of extreme stress include (but are >> not limited to) classical security attacks (e.g., hijacking, privacy, >> non-repudiation, etc.) and attacks on network availability (e.g., >> denial of service (DoS) attacks). >> >> >> 3. IANA Considerations >> >> This document makes no request of IANA. >> >> Note to RFC Editor: this section may be removed on publication as >> an >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page 15] >> >> Internet-Draft MPLS-TP Requirements July 2008 >> >> >> RFC. >> >> >> 4. Security Considerations >> >> This document does not by itself raise any particular security >> considerations. >> >> >> 5. Acknowledgements >> >> The authors wish to thank Neil Harrison and Tomonori Takeda for their >> review and enhancements to the text. >> >> >> 6. Informative References >> >> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate >> Requirement Levels", BCP 14, RFC 2119, March 1997. >> >> [RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and >> Restoration) Terminology for Generalized Multi-Protocol >> Label Switching (GMPLS)", RFC 4427, March 2006. >> >> [ITU.Y1401.2008] >> International Telecommunications Union, "Principles of >> interworking", ITU-T Recommendation Y.1401, February 2008. >> >> >> Authors' Addresses >> >> Ben Niven-Jenkins (editor) >> BT >> 208 Callisto House, Adastral Park >> Ipswich, Suffolk IP5 3RE >> UK >> >> Email: benjamin.niven-jenkins@bt.com >> >> >> Deborah Brungard (editor) >> AT&T >> Rm. D1-3C22 - 200 S. Laurel Ave. >> Middletown, NJ 07748 >> USA >> >> Email: dbrungard@att.com >> >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page 16] >> >> Internet-Draft MPLS-TP Requirements July 2008 >> >> >> Malcolm Betts (editor) >> Nortel Networks >> 3500 Carling Avenue >> Ottawa, Ontario K2H 8E9 >> Canada >> >> Email: betts01@nortel.com >> >> >> Nurit Sprecher >> Nokia Siemens Networks >> 3 Hanagar St. Neve Ne'eman B >> Hod Hasharon, 45241 >> Israel >> >> Email: nurit.sprecher@nsn.com >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page 17] >> >> Internet-Draft MPLS-TP Requirements July 2008 >> >> >> Full Copyright Statement >> >> Copyright (C) The IETF Trust (2008). >> >> 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, THE IETF TRUST 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. >> >> >> Intellectual Property >> >> 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. >> >> >> >> >> >> >> >> >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page 18] >> >> >> >> _______________________________________________ >> Mpls-interop mailing list >> Mpls-interop@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-interop > _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop From mpls-interop-bounces@ietf.org Sun Jun 22 13:50:47 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 084D33A684B; Sun, 22 Jun 2008 13:50:47 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0EB63A68C2 for ; Sun, 22 Jun 2008 13:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.034 X-Spam-Level: X-Spam-Status: No, score=-0.034 tagged_above=-999 required=5 tests=[AWL=0.898, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pU-kEO2ykxIg for ; Sun, 22 Jun 2008 13:50:43 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 38FC23A684B for ; Sun, 22 Jun 2008 13:50:41 -0700 (PDT) Received: from E03MVZ2-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Jun 2008 21:50:45 +0100 Received: from 217.32.164.184 ([217.32.164.184]) by E03MVZ2-UKDY.domain1.systemhost.net ([193.113.30.120]) via Exchange Front-End Server mail.bt.com ([193.113.197.28]) with Microsoft Exchange Server HTTP-DAV ; Sun, 22 Jun 2008 20:50:44 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Sun, 22 Jun 2008 16:50:29 -0400 From: Thomas Nadeau To: Ben Niven-Jenkins , "Sprecher, Nurit (NSN - IL/Israel - MiniMD)" , Loa Andersson , MEAD team Message-ID: Thread-Topic: [Mpls-interop] next MEAD team meeting Thread-Index: AcjSMNQsx4BuurjX8EeQxIcfmO8exAA0/R+VAEuIunAACtuUpAABrZoIABEimhI= In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 22 Jun 2008 20:50:45.0934 (UTC) FILETIME=[A4CA44E0:01C8D4A9] Cc: "Weingarten, Yaacov \(NSN - IL/Israel - MiniMD\)" Subject: Re: [Mpls-interop] next MEAD team meeting X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org On 6/22/08 8:39 AM, "Ben Niven-Jenkins" wrote: > I think the key thing is that MPLS-TP must be able to operate (including > OAM) in the absence of a control plane. Again, I am not advocating for it to not work without a control plane. All I am saying is that it MUST work WITH a control plane too. > The option is then down to whether we say both static & dynamic are MUSTs > (from an implementation perspective) and the operator is then free to choose > whether they operate their network statically or dynamically. Or whether > only static is a MUST and dynamic is optional (for implementation). Yes, and I think it is a MUST in both cases. > I believe the work in ITU intended to extend to dynamic at some point and > static was just a first step in the T-MPLS work. > It only take one operator to demand dynamic from their vendors for it to be > present in equipment anyway even if it is not used by other operators. > > So I think we can make both static & dynamic MUSTs and then clarify that > when operating in a static mode MPLS-TP must not rely on any dynamic > protocols. Agreed. > We cover this (at least to some extent) already with requirements such as " > Static provisioning MUST not depend on routing or signaling protocols (e.g. > GMPLS, OSPF, IS-IS, RSVP, BGP, LDP etc.)." Yes. What I was asking is that the other SHOULDs be changed to MUSTs. Requirements documents that have lots of MAY or SHOULDS are not so useful IMHO. --Tom > Ben > > On 22/06/2008 12:51, "Thomas Nadeau" wrote: > >> >> >> >> On 6/22/08 5:45 AM, "Sprecher, Nurit (NSN - IL/Israel - MiniMD)" >> wrote: >> >>> Hi Thomas, >>> Thanks for your comments. >>> I still need to get into the details and meanings of your comments, but >>> in the meantime I have one basic concern on your comment on " MPLS-TP >>> connections MAY be able to be provisioned dynamically via a control >>> plane. TOM: I insist that we change the MAY above to MUST. I want a >>> dynamic version of this as much as a static one." >>> This is one of the fundamental principles of the MPLS-TP, that the >>> presence of a distributed control plane in support of network operations >>> is optional (as in other transport technologies, like in SDH, etc.). >> >> I agree it is optional. What I want to make sure is that it is not so >> optional that it is completely removed from the design. The language in the >> document now seems to be headed in that direction. >> >>> This is also the trigger for the definition of OAM capabilities which >>> are independent of a control plane, as well as of the protection >>> switching, etc. >>> This is also addressed by the slides of the JW: "Desire to statically >>> configure LSPs and PWEs via the management plane... >> >> I am not arguing against static; I am arguing for dynamic to be in there >> as well. >> >>> Transport OAM capabilities don't exist for LSP and PWE independent of >>> configuration mechanism (management plane or GMPLS or PWE control >>> plane)... >> >> It depends on how you look at what "transport OAM capabilities". From my >> perspective at BT, I definitely think there is a dynamic flavor of this for >> sure. Again, I am not advocating removal of the static parts, just the >> addition of the dynamic ones. And since they are already there in large >> part, as part of the base MPLS specification, I don't see any harm in >> specifying this. >> >> --Tom >> >> >> >>> With static provisioning, no dependency on routing or signaling >>> (e.g. GMPLS or, IGP, RSVP, BGP, LDP)", etc. >>> Best regards, >>> Nurit >>> >>> -----Original Message----- >>> From: mpls-interop-bounces@ietf.org >>> [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext Thomas Nadeau >>> Sent: Friday, June 20, 2008 21:38 >>> To: Ben Niven-Jenkins; Loa Andersson; MEAD team >>> Subject: Re: [Mpls-interop] next MEAD team meeting >>> >>> >>> Comments on the document inline start with "TOM:" >>> In general, please review the document and put more of an emphasis on >>> the use of "MUST" rather than "MAY" or "SHOULD". The IETG frowns on >>> requirements documents that are too optional. >>> >>> --Tom >>> >>> >>> >>> >>> >>> Network Working Group B. Niven-Jenkins, Ed. >>> Internet-Draft BT >>> Intended status: Informational D. Brungard, Ed. >>> Expires: January 2, 2009 AT&T >>> M. Betts, Ed. >>> Nortel Networks >>> N. Sprecher >>> Nokia Siemens Networks >>> July 01, 2008 >>> >>> >>> MPLS-TP Requirements >>> draft-jenkins-mpls-mplstp-requirements-00 >>> >>> Status of this Memo >>> >>> By submitting this Internet-Draft, each author represents that any >>> applicable patent or other IPR claims of which he or she is aware >>> have been or will be disclosed, and any of which he or she becomes >>> aware will be disclosed, in accordance with Section 6 of BCP 79. >>> >>> 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. >>> >>> This Internet-Draft will expire on January 2, 2009. >>> >>> Abstract >>> >>> This document will outline the requirements for MPLS-TP. >>> >>> Requirements Language >>> >>> 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 [RFC2119]. >>> >>> >>> >>> Niven-Jenkins, et al. Expires January 2, 2009 [Page 1] >>> >>> Internet-Draft MPLS-TP Requirements July 2008 >>> >>> >>> Table of Contents >>> >>> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 >>> 2. MPLS-TP Requirements . . . . . . . . . . . . . . . . . . . . . 5 >>> 2.1. General requirements . . . . . . . . . . . . . . . . . . . 5 >>> 2.2. Layering requirements . . . . . . . . . . . . . . . . . . 6 >>> 2.3. Data plane requirements . . . . . . . . . . . . . . . . . 7 >>> 2.4. Control plane requirements . . . . . . . . . . . . . . . . 8 >>> 2.5. Network Management (NM) requirements . . . . . . . . . . . 11 >>> 2.6. OAM requirements . . . . . . . . . . . . . . . . . . . . . 11 >>> 2.7. Network performance management (PM) requirements . . . . . 11 >>> 2.8. Protection & Survivability requirements . . . . . . . . . 12 >>> 2.9. QoS requirements . . . . . . . . . . . . . . . . . . . . . 14 >>> 2.10. Security requirements . . . . . . . . . . . . . . . . . . 15 >>> 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 >>> 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 >>> 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 >>> 6. Informative References . . . . . . . . . . . . . . . . . . . . 16 >>> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 >>> Intellectual Property and Copyright Statements . . . . . . . . . . 18 >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Niven-Jenkins, et al. Expires January 2, 2009 [Page 2] >>> >>> Internet-Draft MPLS-TP Requirements July 2008 >>> >>> >>> 1. Introduction >>> >>> For many years, SONET/SDH has provided service providers with a high >>> benchmark for reliability and operational simplicity. With the >>> accelerating growth of packet-based services (such as Ethernet, VoIP, >>> L2/L3 VPN, IPTV, RAN backhauling, etc.), service providers are in >>> need of capabilities to efficiently support packet-based services on >>> their transport networks. The need to increase their revenue while >>> remaining competitive forces operators to look for the lowest network >>> Total Cost of Ownership (TCO). Investment in both Capital >>> Expenditure (CAPEX) and Operational Expense (OPEX) should be minimal. >>> >>> Carriers are considering migrating to packet transport networks in >>> order to reduce their costs and to improve their ability to support >>> services with guaranteed SLAs. Migrating from SONET/SDH to packet >>> transport networks should not involve dramatic changes in network >>> operation, should not necessitate extensive retraining, and should >>> not require major changes to existing work practices. The aim is to >>> preserve the look-and-feel to which carriers have become accustomed >>> in deploying their SONET/SDH networks, while providing common, multi- >>> layer operations, resiliency, control and management for packet, >>> circuit and lambda transport networks. >>> >>> An important attribute of a transport network is its ability to >>> function independently from both its client and server (transmission >>> media) layer networks. It should be capable of transmitting over any >>> media. Another key characteristic of transport networks is the >>> capability to maintain the integrity of the client signal between its >>> ingress and egress ports. >>> >>> TOM: I would use something other than "client signal" here. Something >>> like "client path" or something is what I think you mean. >>> >>> A transport network must provide the means >>> to commit quality of service objectives to clients. This is achieved >>> by providing a mechanism for client network service demarcation for >>> the network path together with an associated network resiliency >>> mechanism. A transport network must also provide a method of service >>> monitoring in order to verify the delivery of an agreed quality of >>> service. This is enabled by means of carrier-grade OAM tools. >>> >>> The connectivity service is the basic service provided by a transport >>> network. >>> >>> TOM: Is it? Does the transport really provide connections or does it >>> provide transport paths? I am sensitive to the terms used here. We >>> don't want this to become a connect-fest. Seems to me that you explain >>> this better in the next sentence anyhow. >>> >>> The purpose of a transport network is to transparently >>> carry client signals (i.e. the stream of client PDUs or client bits) >>> >>> TOM: Again, I don't like the term "signals" here. Use "client data" or >>> something. >>> >>> between endpoints in the network (typically over several intermediate >>> nodes). These endpoints may be service switching points or service >>> terminating points. The connectivity services offered to customers >>> are aggregated into large, long-holding time pipes/trunks which >>> >>> TOM: Do you really mean to call these "time pipes"? Sounds too >>> futuristic even for this work. *) I think you mean "...into relatively >>> large, long-lasting paths..." >>> >>> enable the efficient and reliable operation of the transport network. >>> These trunks are modified infrequently. >>> >>> TOM: Keep the terminology consistent here too. There is the use of >>> "trunks", "pipes", etc... >>> >>> Aggregation and hierarchy are beneficial for achieving scalability >>> and security since: >>> >>> >>> >>> Niven-Jenkins, et al. Expires January 2, 2009 [Page 3] >>> >>> Internet-Draft MPLS-TP Requirements July 2008 >>> >>> >>> 1. They reduce the number of provisioning and forwarding states in >>> the network core. >>> >>> 2. They reduce load and the cost of implementing service assurance >>> and fault management. >>> >>> TOM: Do they really reduce load? This is one of those fluffy, open-ended >>> terms like "scaleability" that I don't like used unless it is clearly >>> defined. >>> >>> 3. Client signals are completely encapsulated and isolated from each >>> other. This also allows complete isolation of customer traffic >>> from carrier operations. >>> >>> TOM: Does this really happen at the data or control plane or both? Or do >>> we care? >>> >>> >>> Client signals are first transparently encapsulated. These >>> encapsulated client signals are then aggregated for transport through >>> the network in order to optimize network management. Server layer >>> OAM is used to monitor the transport integrity of the client layer >>> aggregate. At any hop, the aggregated signals may be further >>> aggregated in lower layer transport network paths for transport >>> across intermediate shared links. The encapsulated client signals >>> are extracted at the edges of aggregation domains, and are either >>> delivered to the client or forwarded to another domain. In the core >>> of the network, only the server layer aggregated signals are >>> monitored; individual client signals are monitored at the network >>> boundary in the client layer network. >>> >>> TOM: I am not sure the above is appropriate for a requirements document. >>> It sounds like you are spelling out an algorithm for how a solution >>> should work. >>> >>> Quality-of-service mechanisms are required in the packet transport >>> network to ensure the prioritization of critical services, to >>> guarantee BW and to control jitter and delay. >>> >>> TOM: Are they required everywhere the service exists, or say just at the >>> ingress/egress for policing/marking functions? While we are on the >>> subject, do we want to be more specific about QoS requirements? >>> >>> Service providers require control and deterministic usage of network >>> resources. They need end-to-end control to engineer network paths >>> and to efficiently utilize network resources. They require >>> capabilities to statically (OSS based) provision deterministic, >>> protected and secured services and their associated resources as well >>> as alternative control-plane options. >>> >>> TOM: They also require dynamic ones. Please put that in. I don't want >>> to be asking for only a completely static system. >>> >>> The transport network must be capable of transporting multiple >>> services in a scalable manner. >>> >>> TOM: Again, this use of "scalable" offends me. Please be more specific >>> or take the sentence out as it is meaningless as stated. >>> >>> Carriers will still need to cope with legacy networks (which are >>> composed of many layers and technologies), thus the packet transport >>> network should interwork with other packet and transport networks >>> (both horizontally and vertically). Vertical interworking is also >>> known as client/server or network interworking. Horizontal >>> interworking is also known as peer-partition or service interworking. >>> >>> TOM: Didn't you just say that vertical interworking was client >>> interworking in the first sentence? How can horizontal be service >>> interworking as well? >>> >>> For more details on each type of interworking and some of the issues >>> that may arise (especially with horizontal interworking) see >>> [ITU.Y1401.2008]. >>> >>> MPLS is a maturing packet technology and it is already playing an >>> >>> >>> >>> Niven-Jenkins, et al. Expires January 2, 2009 [Page 4] >>> >>> Internet-Draft MPLS-TP Requirements July 2008 >>> >>> >>> important role in transport networks and services. However, not all >>> of MPLS's capabilities and mechnisms are needed and/or consistent >>> with transport network operations. This document identifies the >>> required capabilities for MPLS so that it can better fit a transport >>> role. >>> >>> TOM: I think you want to say "identifies the required sub-set of >>> capabilities..." and later "potentially new ons specific for transport >>> networks" which it seems you say two paragraphs later. >>> >>> Combining the packet experience of MPLS with the operational >>> experience of SONET/SDH constitutes a packet transport technology >>> named MPLS-TP. MPLS-TP will enable the migration of SONET/SDH >>> networks to a packet-based network that will easily scale to support >>> packet services in a simple and cost effective way. >>> >>> MPLS-TP needs to combine the necessary existing capabilities of MPLS >>> with additional minimal mechanisms in order to meet the requirements >>> described in this document. >>> >>> The requirements of an MPLS transport profile are provided below. >>> >>> TOM: There is a terminology issue in the use of "MPLS-TP" or "an MPLS >>> transport profile". That is, on the one hand you refer to a technology, >>> but on the other hand you are referring to a specific profile. Which is >>> it? >>> >>> >>> 2. MPLS-TP Requirements >>> >>> 2.1. General requirements >>> >>> o MPLS-TP MUST offer as much commonality as possible with the MPLS >>> user plane as defined by IETF. When MPLS offers multiple options >>> in this respect, MPLS-TP SHOULD select the minimum sub-set >>> (necessary and sufficient subset) applicable to a transport >>> network application. >>> >>> o Any new functionality that is defined to fulfil the requirements >>> for MPLS-TP MUST be agreed within IETF and re-use (as far as >>> practically possible) existing MPLS standards. >>> >>> o Mechanisms and capabilities MUST be able to interoperate with >>> existing MPLS and PWE control and data planes where appropriate. >>> >>> TOM: Change PWE to "IETF PWE3" and "MPLS" to "IETF MPLS". There also >>> need to be references here to the PWE3 architecture and MPLS >>> architectures. >>> >>> o MPLS-TP MUST support traffic engineering capabilities that allow >>> deterministic control of the use of network resources. >>> >>> o MPLS-TP MUST support the logical separation of the control and >>> management planes from the user plane. >>> >>> o MPLS-TP SHOULD support the physical separation of the control and >>> management planes from the user plane. >>> >>> o MPLS-TP MUST support point to point (P2P) or point to multipoint >>> (P2MP) connections. >>> >>> TOM: Are we avoiding MP2MP consciously or was it left out? >>> >>> >>> Niven-Jenkins, et al. Expires January 2, 2009 [Page 5] >>> >>> Internet-Draft MPLS-TP Requirements July 2008 >>> >>> >>> o MPLS-TP MUST support static provisioning of connections via an >>> NMS/OSS (i.e. via the management plane). >>> >>> o Static provisioning MUST not depend on routing or signaling >>> protocols (e.g. GMPLS, OSPF, IS-IS, RSVP, BGP, LDP etc.). >>> >>> o MPLS-TP connections MAY be able to be provisioned dynamically via >>> a control plane. >>> >>> TOM: I insist that we change the MAY above to MUST. I want a dynamic >>> version of this as much as a static one. >>> >>> >>> o The MPLS-TP data plane MUST be capable of functioning >>> independently of the control or management plane used to operate >>> the MPLS-TP layer network. That is the MPLS-TP data plane >>> operation MUST continue to operate normally if the management >>> plane or control plane that configured the connections fails. >>> >>> o MPLS-TP MUST support any network topology and be able to support >>> increasing bandwidth demands, topology, number of customers or >>> number of services incrementally. >>> >>> >>> TOM: I think it is imperative that although an MPLS-TP is defined to >>> play nicely with an MPLS one, it is imperative that one can distinguish >>> between both, at least at the control plane, but perhaps at the data >>> plane as well. >>> >>> 2.2. Layering requirements >>> >>> o An MPLS-TP network MUST operate in a multiple layer network >>> environment consisting of the following independent layers: >>> >>> 1. A "service layer" instance in which the connections carry the >>> customer's (individual or bundled) service (may be point-to- >>> point, point-to-multipoint or multipoint-to-multipoint >>> services); >>> >>> 2. A "trunk layer" with point-to-point or point-to-multipoint >>> connections which are used to carry aggregates of the network >>> "service layer" connections; and >>> >>> 3. A "transmission media layer" which provides sections (two-port >>> point-to-point connections) to carry the aggregate of network >>> trunk or network service connections on various physical >>> media. >>> >>> TOM: This stuff belongs in the Terminology section at the top. >>> >>> MPLS-TP may provide the "service layer" (for P2P and P2MP services) >>> and/or the "trunk layer" within a layer network environment. >>> >>> o An MPLS-TP layer network MUST support the transparent transport of >>> MPLS-TP and non MPLS-TP client layer networks. >>> >>> o An MPLS-TP layer network MUST be able to be transparently carried >>> over MPLS-TP and non MPLS-TP server layer networks (such as >>> Ethernet, OTN, etc.) >>> >>> >>> >>> >>> Niven-Jenkins, et al. Expires January 2, 2009 [Page 6] >>> >>> Internet-Draft MPLS-TP Requirements July 2008 >>> >>> >>> o It MUST be possible to operate the MPLS-TP layer network >>> independently of other layer networks (either MPLS-TP or non >>> MPLS-TP). >>> >>> This is not only a technology requirement, different administrative >>> groups may be responsible for different layer networks (even when >>> they are of the same type)), and require the capability to >>> operationally support the different layers. >>> >>> o It MUST be possible to hide MPLS-TP layer network addressing and >>> other information (e.g. topology) from client layers. >>> >>> 2.3. Data plane requirements >>> >>> o The identification of each connection within its aggregate MUST be >>> supported. >>> >>> o A label in a particular section MUST uniquely identify the >>> connection. >>> >>> o A connection's source MUST be identifiable at its destination. >>> >>> Connections can be aggregated into trunks by pushing and de- >>> aggregated by popping labels. MPLS-TP labels may be swapped within a >>> connection in a layer network instance when the traffic is forwarded >>> from one MPLS-TP link connection to another MPLS-TP link connection. >>> >>> o Labelling MUST make use of the MPLS label and label stack entry as >>> defined in RFC3032. >>> >>> o It MUST be possible to operate and configure the MPLS-TP data >>> (transport) plane without any IP functionality. >>> >>> o MPLS-TP MUST support both unidirectional and bi-directional point- >>> to-point connections. >>> >>> o The forward and backward directions of a bi-directional connection >>> SHOULD follow the same path within the MPLS-TP network. >>> >>> TOM: I am not sure if we say that they SHOULD as much as "they MUST be >>> capable of". >>> >>> o The intermediate nodes SHOULD be aware about the binding of the >>> forward and the backward directions belonging to the same bi- >>> directional connection. >>> >>> TOM: Again, "SHOULD be capable of" seems better. >>> >>> o MPLS-TP SHOULD support unidirectional point-to-multipoint >>> connections. >>> >>> o MPLS-TP connections MUST NOT perform merging in a way that >>> prevents the unique identification of the source at the >>> >>> >>> >>> Niven-Jenkins, et al. Expires January 2, 2009 [Page 7] >>> >>> Internet-Draft MPLS-TP Requirements July 2008 >>> >>> >>> destination (e.g. no use of LDP mp2p signaling in order to avoid >>> losing LSP head-end information, no use of PHP, etc). >>> >>> o MPLS-TP SHOULD support transport and QoS mechanisms that can >>> deliver statistical multiplexing gain. Packets exceeding the >>> agreed traffic profile may be marked or discarded by the traffic >>> conditioning at the ingress of the MPLS-TP network. >>> >>> TOM: How about egress policing + marking? >>> >>> >>> o MPLS-TP MUST support connections through a single domain. >>> >>> o MPLS-TP SHOULD support connections through multiple domains. >>> >>> o MPLS-TP MUST be able to accommodate new traffic types. >>> >>> TOM: New traffic types other than those supported by MPLS? This doesn't >>> make sense to me as this will result in MPLS-TP not being a subset of >>> MPLS. >>> >>> o MPLS-TP SHOULD support mechanisms to safeguard against the >>> provisioning of connections which contain forwarding loops. >>> >>> o MPLS-TP SHOULD support mechanisms to minimize traffic impact >>> during network reconfiguration. >>> >>> o MPLS-TP SHOULD support mechanisms which ensure the integrity of >>> the adapted information. >>> >>> o MPLS-TP MUST support an unambiguous and reliable means of >>> distinguishing users' (client) packets from MPLS-TP control plane >>> and management plane packets. >>> >>> 2.4. Control plane requirements >>> >>> o A distributed control plane MAY be supported to enable fast, >>> dynamic and reliable service provisioning in multi-vendor and >>> multi-domain environments using standardized protocols that >>> guarantee interoperability. >>> >>> o If a control plane is used for configuration of MPLS-TP >>> connections then: >>> >>> * Failure and recovery of the control plane MUST NOT impact the >>> MPLS-TP forwarding plane. >>> >>> TOM: This is difficult, as this really is handled in practice at both >>> data and control planes, depending on how this is configured/designed, >>> and the re-signaling can impact the data plane. >>> >>> * It MUST support the setup, modification, and release of MPLS-TP >>> connections and protection connections. >>> >>> * It MUST support mechanisms to provide traffic engineering, >>> constraint-based routing and explicit path control. >>> >>> * It MUST provide mechanisms to address QoS and performance >>> requirements (such as throughput, delay, packet loss, etc.) >>> >>> >>> >>> Niven-Jenkins, et al. Expires January 2, 2009 [Page 8] >>> >>> Internet-Draft MPLS-TP Requirements July 2008 >>> >>> >>> while utilizing network resources efficiently and reliably. >>> >>> o MPLS-TP SHOULD support off-path (out-of-band) control and >>> management planes. >>> >>> o The MPLS-TP control plane MUST be independent of any particular >>> client or server layer control plane. >>> >>> o The control plane SHOULD facilitate the implementation of the >>> service by providing end-to-end seamless connectivity and service >>> assurance. >>> >>> o The MPLS-TP control plane MUST support establishing all the >>> connectivity patterns defined for the MPLS-TP transport plane >>> (e.g., uni-directional and bidirectional P2P, uni-directional >>> P2MP, etc.) including configuration of protection functions and >>> any associated maintenance functions. >>> >>> o The MPLS-TP control pane must support the configuration and >>> modification of OAM maintenance points as well as the activation/ >>> deactivation of OAM when the connection is established or >>> modified. >>> >>> o An MPLS-TP control plane MUST support topology hiding and address >>> independence between domains. >>> >>> o At the boundary of a domain an MPLS-TP control plane MUST support >>> unique names or addresses identifying boundary points to be >>> interconnected. >>> >>> o At the boundary of a domain an MPLS-TP control plane must support >>> group names or addresses identifying sets of boundary points to be >>> interconnected. >>> >>> o MPLS-TP layer network access points (or connection points that >>> proxy for access points) SHOULD be able to be assigned names which >>> are available to clients to identify endpoints in call or >>> connection requests. >>> >>> o An MPLS-TP control plane MUST support translation between >>> externally visible endpoint names and internal network addresses. >>> >>> o An MPLS-TP control plane MUST support constraint-based route >>> calculation. >>> >>> o An MPLS-TP control plane MUST support provisioning and application >>> of routing constraint policies. >>> >>> >>> >>> >>> Niven-Jenkins, et al. Expires January 2, 2009 [Page 9] >>> >>> Internet-Draft MPLS-TP Requirements July 2008 >>> >>> >>> o An MPLS-TP control plane MUST support pre-provisioned connection >>> protection. >>> >>> In some situations it is impractical to expect acceptable recovery >>> performance to be achieved using dynamic recalculation of connection >>> routes. For this reason, it is necessary to allow for pre-planning >>> of protection routes for selected connections. >>> >>> o The MPLS-TP control plane MUST support fast restoration. >>> >>> TOM: Define what "fast" means? >>> >>> o An MPLS-TP control plane MUST scale gracefully to support a large >>> number of connections. >>> >>> TOM: Define "large" and "scale" here? >>> >>> [Include some numbers to indicate how large the CP is expected to >>> scale to?] >>> >>> o An MPLS-TP control plane MUST clearly distinguish resources >>> belonging to the MPLS-TP layer network from those in other layer >>> networks that may also be under control plane control. >>> >>> TOM: Do you mean under the same control plane or a different one (or >>> both)? >>> >>> o An MPLS-TP control plane MUST support the independent >>> identification of logically distinct control plane elements. >>> >>> o It MUST be possible to identify and provision these elements >>> independently, in order to reorganize the control plane components >>> without impacting the data plane services and vice-versa. >>> >>> Architecturally distinct elements in a control plane include: nodes >>> and links, control plane functional components, protocol controllers, >>> etc. >>> >>> o An MPLS-TP control plane SHOULD provide a common control mechanism >>> for architecturally similar operations. >>> >>> o An MPLS-TP control plane MUST support mechanisms for partitioning >>> the network under control into separate peer or hierarchical >>> control domains. >>> >>> o To enable the deployment of a unified control plane aimed at >>> controlling the set of transport technologies used in a transport >>> network, the MPLS-TP control plane MUST also be applicable to >>> other transport layer networks and provide common operations >>> across multiple layers. In order to maintain independence between >>> MPLS-TP and its respective client and server layer network >>> separate control plane instances SHOULD be used to control a set >>> of transport layer networks. >>> >>> >>> >>> >>> >>> Niven-Jenkins, et al. Expires January 2, 2009 [Page 10] >>> >>> Internet-Draft MPLS-TP Requirements July 2008 >>> >>> >>> o MPLS-TP SHOULD detect and recover from control plane failures and >>> degradations using graceful operations. >>> >>> 2.5. Network Management (NM) requirements >>> >>> o MPLS-TP MUST operate under a common operation, control and >>> management paradigm with respect to other transport technologies >>> (e.g. SDH, OTN or WDM). >>> >>> o An MPLS-TP network MUST be able to be operated with a centralized >>> NMS system. >>> >>> o An MPLS-TP network SHOULD be able to be operated by a centralized >>> NMS system with the support of a distributed control plane. >>> >>> TOM: I don't know what this means or the one above it, or how this >>> requirement would translate into anything tangible in the MPLS-TP >>> protocol designs. I suggest it be removed. >>> >>> o The MPLS-TP management plane MUST NOT depend on a specific client >>> layer management plane. >>> >>> TOM: This is a non-sequitur if you ask me; please strike it. >>> >>> o The MPLS-TP management plane MUST support the configuration and >>> modification of OAM maintenance points as well as the activation/ >>> deactivation of OAM when the connection is established or >>> modified. >>> >>> For the complete set of requirements related to NM functionality for >>> MPLS-TP, see the MPLS-TP NM requirements document [REF]. >>> >>> 2.6. OAM requirements >>> >>> o MPLS-TP SHOULD provide a comprehensive set of capabilities (that >>> are independent of and agnostic to the transmitted client >>> services) to support fault management, performance monitoring (of >>> the MPLS-TP network and the services), protection switching, fault >>> localization, signal quality measurement, etc. >>> >>> o A mechanism SHOULD be supported to detect, diagnose and enable >>> recovery from facility and equipment failures and performance >>> degradations according to the requirements of the service. >>> >>> o MPLS-TP OAM MUST be able to operate without IP functionality and >>> without relying on control and/or management planes. >>> >>> For the complete set of requirements related to OAM functionality for >>> MPLS-TP, see the MPLS-TP OAM requirements document [REF]. >>> >>> TOM: I suggest you just remove these two sections and refer to the >>> OAM/Managemetn documents. >>> >>> 2.7. Network performance management (PM) requirements >>> >>> >>> >>> >>> >>> >>> Niven-Jenkins, et al. Expires January 2, 2009 [Page 11] >>> >>> Internet-Draft MPLS-TP Requirements July 2008 >>> >>> >>> o MPLS-TP MUST support traffic-engineering capabilities with >>> traffic- and/or resource-oriented performance objectives. >>> >>> TOM: What are performance objectives? Do you mean traffic profiles such >>> as QoS/bandwidth? >>> >>> o MPLS-TP MUST support a method to offer packet loss objectives >>> comparable to those in TDM transport networks (only due to bit >>> errors). >>> >>> For the complete set of requirements related to PM functionality for >>> MPLS-TP, see the MPLS-TP OAM requirements document [REF]. >>> >>> TOM: Again, I suggest you punt on this entire section and move it to the >>> OAM doc. >>> >>> 2.8. Protection & Survivability requirements >>> >>> Network survivability plays a critical factor in the delivery of >>> reliable services. Network availability is a significant contributor >>> to revenue and profit. Service guarantees in the form of SLAs >>> require a resilient network that rapidly detects facility or node >>> failures and restores network operation in accordance with the terms >>> of the SLA. >>> >>> The requirements in this section use of the recovery terminology >>> defined in RFC 4427[RFC4427]. >>> >>> o MPLS-TP SHOULD support transport network style protection >>> >>> TOM: I would make this a MUST. >>> >>> switching mechanisms (tandem network connection protection, LSP >>> protection and PW protection) to provide the sub-50ms recovery >>> time required to maintain customer transparency, even when >>> thousands of services are simultaneously affected by a failure. >>> [Is sub-50ms really a requirement, do we want to clarify this >>> further - is it sub-50ms end to end, or per link?] >>> >>> o >>> >>> * MPLS-TP recovery mechanisms SHOULD be applicable at various >>> levels throughout the network, SPAN, tandem connection and end- >>> to-end. >>> >>> TOM: This sentence doesn't parse. Please re-write. >>> >>> Any recovery mechanism used in a tandem connection >>> MUST be independent of other tandem connections. >>> >>> * MPLS-TP SHOULD support mechanisms that keep traffic flowing >>> while the network recovers from failures. >>> >>> TOM: I would say this is a MUST. >>> >>> * MPLS-TP SHOULD support network restoration mechanisms >>> controlled by a distributed control plane and/or by a >>> management plane based. >>> >>> TOM: I would say this is a MUST. >>> >>> >>> * >>> >>> + The restoration resources MAY be pre-planned and selected a >>> priori, or computed after failure occurrence. >>> >>> >>> >>> Niven-Jenkins, et al. Expires January 2, 2009 [Page 12] >>> >>> Internet-Draft MPLS-TP Requirements July 2008 >>> >>> >>> + MPLS-TP MAY support shared-mesh restoration. >>> >>> + MPLS-TP SHOUD support soft LSP restoration. >>> >>> + MPLS-TP MAY support hard LSP restoration. >>> >>> + The restoration mechanism MUST be applicable to any >>> topology. >>> >>> + Restoration priority MAY be implemented to determine the >>> order in which connections should be restored (to minimize >>> service restoration time as well as to gain access to >>> available spare capacity on the best paths). Preemption >>> priority MAY be used in the event that not all connections >>> can be restored, in which case connections with lower >>> preemption priority should be released. >>> >>> + The restoration mechanism SHOULD operate in synergy with >>> other transport network technologies (SDH, OTN, WDM). >>> >>> * MPLS-TP SHOULD support data plane driven protection mechanisms >>> (without any dependency on a control plane or IP protocols) to >>> enable fast recovery from failure, and thereby to enhance the >>> reliability and availability performance of MPLS-TP networks. >>> >>> * >>> >>> + MPLS-TP protection mechanisms SHOULD be applied to LSPs and >>> PWs. >>> >>> + MPLS-TP MUST support mechanisms that rapidly detect, locate, >>> notify and remedy network faults. >>> >>> + MPLS-TP MUST support 1:1 bidirectional protection switching. >>> The protection state of both ends of the protected entity >>> MUST be synchronized. >>> >>> + MPLS-TP MAY support 1+1 unidirectional protection switching. >>> >>> + MPLS-TP protection mechanisms MUST be applicable to both >>> point-to-point and point-to-multipoint connections. >>> >>> + It SHOULD be possible to achieve protection at the MPLS-TP >>> layer as fast as possible (subject to the temporal >>> resolution of the defect detection mechanism). >>> >>> + Protection ratio MUST be of 100%, i.e., 100% of impaired >>> working traffic MUST be protected for a failure on a single >>> >>> >>> >>> Niven-Jenkins, et al. Expires January 2, 2009 [Page 13] >>> >>> Internet-Draft MPLS-TP Requirements July 2008 >>> >>> >>> working LSP. >>> >>> + Operator requests for manual control of protection switching >>> such as clear, lockout of protection, forced-switch and >>> manual-switch commands MUST be supported. Prioritized >>> protection between Signal Fail (SF), Signal Degradation (SD) >>> and operator switch requests MUST be supported. >>> >>> + MPLS-TP protection mechanisms MUST support revertive and >>> non-revertive behaviour. o An extra traffic capability >>> SHOULD be supported when possible. >>> >>> + MPLS-TP protection switching mechanisms MUST prevent >>> frequent operation of the protection switch due to an >>> intermittent defect. >>> >>> + MPLS-TP protection mechanisms MUST ensure co-ordination of >>> timing of protection switches at multiple layers to avoid >>> races and to allow the protection switching mechanism of the >>> server layer to fix the problem before switching at the >>> MPLS-TP layer. >>> >>> + MPLS-TP MAY support mechanisms that are optimized for >>> specific network topologies (Ring, Mesh) in order to handle >>> protection switching in a cost-efficient manner. >>> >>> 2.9. QoS requirements >>> >>> Service providers require advanced traffic management capabilities to >>> enforce and guarantee the QoS parameters of customers' SLAs. >>> >>> Quality of service mechanisms are required to ensure: >>> >>> o Support for differentiated services and different traffic types >>> with traffic class separation associated with different traffic. >>> >>> o Prioritization of critical services. >>> >>> o Enabling the provisioning and the guarantee of Service Level >>> Specifications (SLS), with support for hard and relative end-to- >>> end BW guaranteed. >>> >>> o Controlled jitter and delay. >>> >>> o Guarantee of fair access to shared resources in an MPLS-TP >>> network. >>> >>> >>> >>> >>> >>> Niven-Jenkins, et al. Expires January 2, 2009 [Page 14] >>> >>> Internet-Draft MPLS-TP Requirements July 2008 >>> >>> >>> o Ability for OAM and data to share the same fate. >>> >>> TOM: This belongs in the OAM document. >>> >>> >>> o Resources for control and management plane packets so that user >>> plane traffic, regardless of the amount, will not cause control >>> and management functions to become inoperative. >>> >>> The following QoS requirements apply to MPLS-TP: >>> >>> o MPLS-TP MUST be able to deliver the same degree of QoS that has >>> been delivered by SDH/SONET systems. >>> >>> TOM: We can save on a lot of text and remove the "MPLS-TE MUST" or >>> "MPLS-TP SHOULD" bits and simply say "MUST X" or "SHOULD Y". The MPLS-TP >>> bit is implicit I think. >>> >>> o MPLS-TP MUST support transport bandwidth allocation to any >>> granularity without any restrictions based on a circuit-switched >>> multiplexing hierarchy. This attribute will provide service >>> providers with the capability to route more customer service >>> demands over the MPLS-TP network. >>> >>> [Should we refer here to the requirements specified in RFC 2702?] >>> >>> 2.10. Security requirements >>> >>> o MPLS-TP MUST ensure that the network and services are secured. >>> >>> o Traffic flows from different users MUST NOT be intermingled, but >>> if this does occur then this MUST be detectable and the >>> appropriate consequent actions taken. >>> >>> o MPLS-TP MUST ensure the separation of customer (client) and >>> provider (server and peer network) addressing and other >>> information. >>> >>> TOM: This requirement is stated above. >>> >>> o MPLS-TP MUST ensure that the control and management planes as well >>> as OAM traffic are secure from external attack. >>> >>> o MPLS-TP MUST provide mechanisms to ensure that the MPLS-TP network >>> remains secure and stable under situations of extreme stress. >>> >>> Examples of attacks and situations of extreme stress include (but are >>> not limited to) classical security attacks (e.g., hijacking, privacy, >>> non-repudiation, etc.) and attacks on network availability (e.g., >>> denial of service (DoS) attacks). >>> >>> >>> 3. IANA Considerations >>> >>> This document makes no request of IANA. >>> >>> Note to RFC Editor: this section may be removed on publication as an >>> >>> >>> >>> Niven-Jenkins, et al. Expires January 2, 2009 [Page 15] >>> >>> Internet-Draft MPLS-TP Requirements July 2008 >>> >>> >>> RFC. >>> >>> >>> 4. Security Considerations >>> >>> This document does not by itself raise any particular security >>> considerations. >>> >>> >>> 5. Acknowledgements >>> >>> The authors wish to thank Neil Harrison and Tomonori Takeda for their >>> review and enhancements to the text. >>> >>> >>> 6. Informative References >>> >>> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate >>> Requirement Levels", BCP 14, RFC 2119, March 1997. >>> >>> [RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and >>> Restoration) Terminology for Generalized Multi-Protocol >>> Label Switching (GMPLS)", RFC 4427, March 2006. >>> >>> [ITU.Y1401.2008] >>> International Telecommunications Union, "Principles of >>> interworking", ITU-T Recommendation Y.1401, February 2008. >>> >>> >>> Authors' Addresses >>> >>> Ben Niven-Jenkins (editor) >>> BT >>> 208 Callisto House, Adastral Park >>> Ipswich, Suffolk IP5 3RE >>> UK >>> >>> Email: benjamin.niven-jenkins@bt.com >>> >>> >>> Deborah Brungard (editor) >>> AT&T >>> Rm. D1-3C22 - 200 S. Laurel Ave. >>> Middletown, NJ 07748 >>> USA >>> >>> Email: dbrungard@att.com >>> >>> >>> >>> >>> Niven-Jenkins, et al. Expires January 2, 2009 [Page 16] >>> >>> Internet-Draft MPLS-TP Requirements July 2008 >>> >>> >>> Malcolm Betts (editor) >>> Nortel Networks >>> 3500 Carling Avenue >>> Ottawa, Ontario K2H 8E9 >>> Canada >>> >>> Email: betts01@nortel.com >>> >>> >>> Nurit Sprecher >>> Nokia Siemens Networks >>> 3 Hanagar St. Neve Ne'eman B >>> Hod Hasharon, 45241 >>> Israel >>> >>> Email: nurit.sprecher@nsn.com >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Niven-Jenkins, et al. Expires January 2, 2009 [Page 17] >>> >>> Internet-Draft MPLS-TP Requirements July 2008 >>> >>> >>> Full Copyright Statement >>> >>> Copyright (C) The IETF Trust (2008). >>> >>> 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, THE IETF TRUST 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. >>> >>> >>> Intellectual Property >>> >>> 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. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Niven-Jenkins, et al. Expires January 2, 2009 [Page 18] >>> >>> >>> >>> _______________________________________________ >>> Mpls-interop mailing list >>> Mpls-interop@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls-interop >> > _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop From mpls-interop-bounces@ietf.org Sun Jun 22 13:51:23 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E42323A67D8; Sun, 22 Jun 2008 13:51:23 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B48773A6832 for ; Sun, 22 Jun 2008 13:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[AWL=0.599, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y909VRB5WHb3 for ; Sun, 22 Jun 2008 13:51:19 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 9CC503A684B for ; Sun, 22 Jun 2008 13:51:18 -0700 (PDT) Received: from E03MVZ2-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Jun 2008 21:51:24 +0100 Received: from 217.32.164.184 ([217.32.164.184]) by E03MVZ2-UKDY.domain1.systemhost.net ([193.113.30.120]) via Exchange Front-End Server mail.bt.com ([193.113.197.28]) with Microsoft Exchange Server HTTP-DAV ; Sun, 22 Jun 2008 20:51:23 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Sun, 22 Jun 2008 16:51:09 -0400 From: Thomas Nadeau To: "Sprecher, Nurit (NSN - IL/Israel - MiniMD)" , Ben Niven-Jenkins , Loa Andersson , MEAD team Message-ID: Thread-Topic: [Mpls-interop] next MEAD team meeting Thread-Index: AcjSMNQsx4BuurjX8EeQxIcfmO8exAA0/R+VAEuIunAACtuUpAABBM4gABHRXI0= In-Reply-To: <9FF5BDAD88B9D84881609E89AC92FB83EBD38C@DEMUEXC014.nsn-intra.net> Mime-version: 1.0 X-OriginalArrivalTime: 22 Jun 2008 20:51:24.0613 (UTC) FILETIME=[BBD83750:01C8D4A9] Cc: "Weingarten, Yaacov \(NSN - IL/Israel - MiniMD\)" Subject: Re: [Mpls-interop] next MEAD team meeting X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org On 6/22/08 8:22 AM, "Sprecher, Nurit (NSN - IL/Israel - MiniMD)" wrote: > Hi Tom, > Thanks for your response. > If you agree that the control plane in MPLS-TP is optional, then we > cannot say MUST. To make it stronger, we may think of changing the "MAY" > to "SHOULD". I DO NOT agree that it is optional. There are two different modes if you will, to run MPLS-TP; dynamic or static. Both are important. --Tom > Best regards, > Nurit > > -----Original Message----- > From: ext Thomas Nadeau [mailto:tom.nadeau@bt.com] > Sent: Sunday, June 22, 2008 14:52 > To: Sprecher, Nurit (NSN - IL/Israel - MiniMD); Ben Niven-Jenkins; Loa > Andersson; MEAD team > Cc: Weingarten, Yaacov (NSN - IL/Israel - MiniMD) > Subject: Re: [Mpls-interop] next MEAD team meeting > > > > > On 6/22/08 5:45 AM, "Sprecher, Nurit (NSN - IL/Israel - MiniMD)" > wrote: > >> Hi Thomas, >> Thanks for your comments. >> I still need to get into the details and meanings of your comments, >> but in the meantime I have one basic concern on your comment on " >> MPLS-TP connections MAY be able to be provisioned dynamically via a >> control plane. TOM: I insist that we change the MAY above to MUST. I >> want a dynamic version of this as much as a static one." >> This is one of the fundamental principles of the MPLS-TP, that the >> presence of a distributed control plane in support of network >> operations is optional (as in other transport technologies, like in > SDH, etc.). > > I agree it is optional. What I want to make sure is that it is not > so optional that it is completely removed from the design. The language > in the document now seems to be headed in that direction. > >> This is also the trigger for the definition of OAM capabilities which >> are independent of a control plane, as well as of the protection >> switching, etc. >> This is also addressed by the slides of the JW: "Desire to statically >> configure LSPs and PWEs via the management plane... > > I am not arguing against static; I am arguing for dynamic to be in > there as well. > >> Transport OAM capabilities don't exist for LSP and PWE independent of >> configuration mechanism (management plane or GMPLS or PWE control >> plane)... > > It depends on how you look at what "transport OAM capabilities". > From my perspective at BT, I definitely think there is a dynamic flavor > of this for sure. Again, I am not advocating removal of the static > parts, just the addition of the dynamic ones. And since they are already > there in large part, as part of the base MPLS specification, I don't see > any harm in specifying this. > > --Tom > > > >> With static provisioning, no dependency on routing or signaling (e.g. >> GMPLS or, IGP, RSVP, BGP, LDP)", etc. >> Best regards, >> Nurit >> >> -----Original Message----- >> From: mpls-interop-bounces@ietf.org >> [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext Thomas Nadeau >> Sent: Friday, June 20, 2008 21:38 >> To: Ben Niven-Jenkins; Loa Andersson; MEAD team >> Subject: Re: [Mpls-interop] next MEAD team meeting >> >> >> Comments on the document inline start with "TOM:" >> In general, please review the document and put more of an emphasis on >> the use of "MUST" rather than "MAY" or "SHOULD". The IETG frowns on >> requirements documents that are too optional. >> >> --Tom >> >> >> >> >> >> Network Working Group B. Niven-Jenkins, > Ed. >> Internet-Draft > BT >> Intended status: Informational D. Brungard, > Ed. >> Expires: January 2, 2009 > AT&T >> M. Betts, > Ed. >> Nortel > Networks >> N. > Sprecher >> Nokia Siemens > Networks >> July 01, >> 2008 >> >> >> MPLS-TP Requirements >> draft-jenkins-mpls-mplstp-requirements-00 >> >> Status of this Memo >> >> By submitting this Internet-Draft, each author represents that any >> applicable patent or other IPR claims of which he or she is aware >> have been or will be disclosed, and any of which he or she becomes >> aware will be disclosed, in accordance with Section 6 of BCP 79. >> >> 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. >> >> This Internet-Draft will expire on January 2, 2009. >> >> Abstract >> >> This document will outline the requirements for MPLS-TP. >> >> Requirements Language >> >> 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 [RFC2119]. >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page > 1] >> >> Internet-Draft MPLS-TP Requirements July > 2008 >> >> >> Table of Contents >> >> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . > 3 >> 2. MPLS-TP Requirements . . . . . . . . . . . . . . . . . . . . . > 5 >> 2.1. General requirements . . . . . . . . . . . . . . . . . . . > 5 >> 2.2. Layering requirements . . . . . . . . . . . . . . . . . . > 6 >> 2.3. Data plane requirements . . . . . . . . . . . . . . . . . > 7 >> 2.4. Control plane requirements . . . . . . . . . . . . . . . . > 8 >> 2.5. Network Management (NM) requirements . . . . . . . . . . . > 11 >> 2.6. OAM requirements . . . . . . . . . . . . . . . . . . . . . > 11 >> 2.7. Network performance management (PM) requirements . . . . . > 11 >> 2.8. Protection & Survivability requirements . . . . . . . . . > 12 >> 2.9. QoS requirements . . . . . . . . . . . . . . . . . . . . . > 14 >> 2.10. Security requirements . . . . . . . . . . . . . . . . . . > 15 >> 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . > 15 >> 4. Security Considerations . . . . . . . . . . . . . . . . . . . > 16 >> 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . > 16 >> 6. Informative References . . . . . . . . . . . . . . . . . . . . > 16 >> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . > 16 >> Intellectual Property and Copyright Statements . . . . . . . . . . >> 18 >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page > 2] >> >> Internet-Draft MPLS-TP Requirements July > 2008 >> >> >> 1. Introduction >> >> For many years, SONET/SDH has provided service providers with a > high >> benchmark for reliability and operational simplicity. With the >> accelerating growth of packet-based services (such as Ethernet, > VoIP, >> L2/L3 VPN, IPTV, RAN backhauling, etc.), service providers are in >> need of capabilities to efficiently support packet-based services > on >> their transport networks. The need to increase their revenue while >> remaining competitive forces operators to look for the lowest > network >> Total Cost of Ownership (TCO). Investment in both Capital >> Expenditure (CAPEX) and Operational Expense (OPEX) should be > minimal. >> >> Carriers are considering migrating to packet transport networks in >> order to reduce their costs and to improve their ability to support >> services with guaranteed SLAs. Migrating from SONET/SDH to packet >> transport networks should not involve dramatic changes in network >> operation, should not necessitate extensive retraining, and should >> not require major changes to existing work practices. The aim is > to >> preserve the look-and-feel to which carriers have become accustomed >> in deploying their SONET/SDH networks, while providing common, > multi- >> layer operations, resiliency, control and management for packet, >> circuit and lambda transport networks. >> >> An important attribute of a transport network is its ability to >> function independently from both its client and server > (transmission >> media) layer networks. It should be capable of transmitting over > any >> media. Another key characteristic of transport networks is the >> capability to maintain the integrity of the client signal between > its >> ingress and egress ports. >> >> TOM: I would use something other than "client signal" here. Something >> like "client path" or something is what I think you mean. >> >> A transport network must provide the means >> to commit quality of service objectives to clients. This is > achieved >> by providing a mechanism for client network service demarcation for >> the network path together with an associated network resiliency >> mechanism. A transport network must also provide a method of > service >> monitoring in order to verify the delivery of an agreed quality of >> service. This is enabled by means of carrier-grade OAM tools. >> >> The connectivity service is the basic service provided by a > transport >> network. >> >> TOM: Is it? Does the transport really provide connections or does it >> provide transport paths? I am sensitive to the terms used here. We >> don't want this to become a connect-fest. Seems to me that you explain > >> this better in the next sentence anyhow. >> >> The purpose of a transport network is to transparently >> carry client signals (i.e. the stream of client PDUs or client >> bits) >> >> TOM: Again, I don't like the term "signals" here. Use "client data" or > >> something. >> >> between endpoints in the network (typically over several > intermediate >> nodes). These endpoints may be service switching points or service >> terminating points. The connectivity services offered to customers >> are aggregated into large, long-holding time pipes/trunks which >> >> TOM: Do you really mean to call these "time pipes"? Sounds too >> futuristic even for this work. *) I think you mean "...into >> relatively large, long-lasting paths..." >> >> enable the efficient and reliable operation of the transport > network. >> These trunks are modified infrequently. >> >> TOM: Keep the terminology consistent here too. There is the use of >> "trunks", "pipes", etc... >> >> Aggregation and hierarchy are beneficial for achieving scalability >> and security since: >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page > 3] >> >> Internet-Draft MPLS-TP Requirements July > 2008 >> >> >> 1. They reduce the number of provisioning and forwarding states in >> the network core. >> >> 2. They reduce load and the cost of implementing service assurance >> and fault management. >> >> TOM: Do they really reduce load? This is one of those fluffy, >> open-ended terms like "scaleability" that I don't like used unless it >> is clearly defined. >> >> 3. Client signals are completely encapsulated and isolated from > each >> other. This also allows complete isolation of customer traffic >> from carrier operations. >> >> TOM: Does this really happen at the data or control plane or both? Or >> do we care? >> >> >> Client signals are first transparently encapsulated. These >> encapsulated client signals are then aggregated for transport > through >> the network in order to optimize network management. Server layer >> OAM is used to monitor the transport integrity of the client layer >> aggregate. At any hop, the aggregated signals may be further >> aggregated in lower layer transport network paths for transport >> across intermediate shared links. The encapsulated client signals >> are extracted at the edges of aggregation domains, and are either >> delivered to the client or forwarded to another domain. In the > core >> of the network, only the server layer aggregated signals are >> monitored; individual client signals are monitored at the network >> boundary in the client layer network. >> >> TOM: I am not sure the above is appropriate for a requirements > document. >> It sounds like you are spelling out an algorithm for how a solution >> should work. >> >> Quality-of-service mechanisms are required in the packet transport >> network to ensure the prioritization of critical services, to >> guarantee BW and to control jitter and delay. >> >> TOM: Are they required everywhere the service exists, or say just at >> the ingress/egress for policing/marking functions? While we are on >> the subject, do we want to be more specific about QoS requirements? >> >> Service providers require control and deterministic usage of > network >> resources. They need end-to-end control to engineer network paths >> and to efficiently utilize network resources. They require >> capabilities to statically (OSS based) provision deterministic, >> protected and secured services and their associated resources as > well >> as alternative control-plane options. >> >> TOM: They also require dynamic ones. Please put that in. I don't want > >> to be asking for only a completely static system. >> >> The transport network must be capable of transporting multiple >> services in a scalable manner. >> >> TOM: Again, this use of "scalable" offends me. Please be more specific > >> or take the sentence out as it is meaningless as stated. >> >> Carriers will still need to cope with legacy networks (which are >> composed of many layers and technologies), thus the packet > transport >> network should interwork with other packet and transport networks >> (both horizontally and vertically). Vertical interworking is also >> known as client/server or network interworking. Horizontal >> interworking is also known as peer-partition or service > interworking. >> >> TOM: Didn't you just say that vertical interworking was client >> interworking in the first sentence? How can horizontal be service >> interworking as well? >> >> For more details on each type of interworking and some of the > issues >> that may arise (especially with horizontal interworking) see >> [ITU.Y1401.2008]. >> >> MPLS is a maturing packet technology and it is already playing an >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page > 4] >> >> Internet-Draft MPLS-TP Requirements July > 2008 >> >> >> important role in transport networks and services. However, not > all >> of MPLS's capabilities and mechnisms are needed and/or consistent >> with transport network operations. This document identifies the >> required capabilities for MPLS so that it can better fit a > transport >> role. >> >> TOM: I think you want to say "identifies the required sub-set of >> capabilities..." and later "potentially new ons specific for >> transport networks" which it seems you say two paragraphs later. >> >> Combining the packet experience of MPLS with the operational >> experience of SONET/SDH constitutes a packet transport technology >> named MPLS-TP. MPLS-TP will enable the migration of SONET/SDH >> networks to a packet-based network that will easily scale to > support >> packet services in a simple and cost effective way. >> >> MPLS-TP needs to combine the necessary existing capabilities of > MPLS >> with additional minimal mechanisms in order to meet the > requirements >> described in this document. >> >> The requirements of an MPLS transport profile are provided below. >> >> TOM: There is a terminology issue in the use of "MPLS-TP" or "an MPLS >> transport profile". That is, on the one hand you refer to a >> technology, but on the other hand you are referring to a specific >> profile. Which is it? >> >> >> 2. MPLS-TP Requirements >> >> 2.1. General requirements >> >> o MPLS-TP MUST offer as much commonality as possible with the MPLS >> user plane as defined by IETF. When MPLS offers multiple > options >> in this respect, MPLS-TP SHOULD select the minimum sub-set >> (necessary and sufficient subset) applicable to a transport >> network application. >> >> o Any new functionality that is defined to fulfil the requirements >> for MPLS-TP MUST be agreed within IETF and re-use (as far as >> practically possible) existing MPLS standards. >> >> o Mechanisms and capabilities MUST be able to interoperate with >> existing MPLS and PWE control and data planes where appropriate. >> >> TOM: Change PWE to "IETF PWE3" and "MPLS" to "IETF MPLS". There also >> need to be references here to the PWE3 architecture and MPLS >> architectures. >> >> o MPLS-TP MUST support traffic engineering capabilities that allow >> deterministic control of the use of network resources. >> >> o MPLS-TP MUST support the logical separation of the control and >> management planes from the user plane. >> >> o MPLS-TP SHOULD support the physical separation of the control > and >> management planes from the user plane. >> >> o MPLS-TP MUST support point to point (P2P) or point to multipoint >> (P2MP) connections. >> >> TOM: Are we avoiding MP2MP consciously or was it left out? >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page > 5] >> >> Internet-Draft MPLS-TP Requirements July > 2008 >> >> >> o MPLS-TP MUST support static provisioning of connections via an >> NMS/OSS (i.e. via the management plane). >> >> o Static provisioning MUST not depend on routing or signaling >> protocols (e.g. GMPLS, OSPF, IS-IS, RSVP, BGP, LDP etc.). >> >> o MPLS-TP connections MAY be able to be provisioned dynamically > via >> a control plane. >> >> TOM: I insist that we change the MAY above to MUST. I want a dynamic >> version of this as much as a static one. >> >> >> o The MPLS-TP data plane MUST be capable of functioning >> independently of the control or management plane used to operate >> the MPLS-TP layer network. That is the MPLS-TP data plane >> operation MUST continue to operate normally if the management >> plane or control plane that configured the connections fails. >> >> o MPLS-TP MUST support any network topology and be able to support >> increasing bandwidth demands, topology, number of customers or >> number of services incrementally. >> >> >> TOM: I think it is imperative that although an MPLS-TP is defined to >> play nicely with an MPLS one, it is imperative that one can >> distinguish between both, at least at the control plane, but perhaps >> at the data plane as well. >> >> 2.2. Layering requirements >> >> o An MPLS-TP network MUST operate in a multiple layer network >> environment consisting of the following independent layers: >> >> 1. A "service layer" instance in which the connections carry > the >> customer's (individual or bundled) service (may be point-to- >> point, point-to-multipoint or multipoint-to-multipoint >> services); >> >> 2. A "trunk layer" with point-to-point or point-to-multipoint >> connections which are used to carry aggregates of the > network >> "service layer" connections; and >> >> 3. A "transmission media layer" which provides sections > (two-port >> point-to-point connections) to carry the aggregate of > network >> trunk or network service connections on various physical >> media. >> >> TOM: This stuff belongs in the Terminology section at the top. >> >> MPLS-TP may provide the "service layer" (for P2P and P2MP services) >> and/or the "trunk layer" within a layer network environment. >> >> o An MPLS-TP layer network MUST support the transparent transport > of >> MPLS-TP and non MPLS-TP client layer networks. >> >> o An MPLS-TP layer network MUST be able to be transparently > carried >> over MPLS-TP and non MPLS-TP server layer networks (such as >> Ethernet, OTN, etc.) >> >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page > 6] >> >> Internet-Draft MPLS-TP Requirements July > 2008 >> >> >> o It MUST be possible to operate the MPLS-TP layer network >> independently of other layer networks (either MPLS-TP or non >> MPLS-TP). >> >> This is not only a technology requirement, different administrative >> groups may be responsible for different layer networks (even when >> they are of the same type)), and require the capability to >> operationally support the different layers. >> >> o It MUST be possible to hide MPLS-TP layer network addressing and >> other information (e.g. topology) from client layers. >> >> 2.3. Data plane requirements >> >> o The identification of each connection within its aggregate MUST > be >> supported. >> >> o A label in a particular section MUST uniquely identify the >> connection. >> >> o A connection's source MUST be identifiable at its destination. >> >> Connections can be aggregated into trunks by pushing and de- >> aggregated by popping labels. MPLS-TP labels may be swapped within > a >> connection in a layer network instance when the traffic is > forwarded >> from one MPLS-TP link connection to another MPLS-TP link > connection. >> >> o Labelling MUST make use of the MPLS label and label stack entry > as >> defined in RFC3032. >> >> o It MUST be possible to operate and configure the MPLS-TP data >> (transport) plane without any IP functionality. >> >> o MPLS-TP MUST support both unidirectional and bi-directional > point- >> to-point connections. >> >> o The forward and backward directions of a bi-directional > connection >> SHOULD follow the same path within the MPLS-TP network. >> >> TOM: I am not sure if we say that they SHOULD as much as "they MUST be > >> capable of". >> >> o The intermediate nodes SHOULD be aware about the binding of the >> forward and the backward directions belonging to the same bi- >> directional connection. >> >> TOM: Again, "SHOULD be capable of" seems better. >> >> o MPLS-TP SHOULD support unidirectional point-to-multipoint >> connections. >> >> o MPLS-TP connections MUST NOT perform merging in a way that >> prevents the unique identification of the source at the >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page > 7] >> >> Internet-Draft MPLS-TP Requirements July > 2008 >> >> >> destination (e.g. no use of LDP mp2p signaling in order to avoid >> losing LSP head-end information, no use of PHP, etc). >> >> o MPLS-TP SHOULD support transport and QoS mechanisms that can >> deliver statistical multiplexing gain. Packets exceeding the >> agreed traffic profile may be marked or discarded by the traffic >> conditioning at the ingress of the MPLS-TP network. >> >> TOM: How about egress policing + marking? >> >> >> o MPLS-TP MUST support connections through a single domain. >> >> o MPLS-TP SHOULD support connections through multiple domains. >> >> o MPLS-TP MUST be able to accommodate new traffic types. >> >> TOM: New traffic types other than those supported by MPLS? This >> doesn't make sense to me as this will result in MPLS-TP not being a >> subset of MPLS. >> >> o MPLS-TP SHOULD support mechanisms to safeguard against the >> provisioning of connections which contain forwarding loops. >> >> o MPLS-TP SHOULD support mechanisms to minimize traffic impact >> during network reconfiguration. >> >> o MPLS-TP SHOULD support mechanisms which ensure the integrity of >> the adapted information. >> >> o MPLS-TP MUST support an unambiguous and reliable means of >> distinguishing users' (client) packets from MPLS-TP control > plane >> and management plane packets. >> >> 2.4. Control plane requirements >> >> o A distributed control plane MAY be supported to enable fast, >> dynamic and reliable service provisioning in multi-vendor and >> multi-domain environments using standardized protocols that >> guarantee interoperability. >> >> o If a control plane is used for configuration of MPLS-TP >> connections then: >> >> * Failure and recovery of the control plane MUST NOT impact the >> MPLS-TP forwarding plane. >> >> TOM: This is difficult, as this really is handled in practice at both >> data and control planes, depending on how this is configured/designed, > >> and the re-signaling can impact the data plane. >> >> * It MUST support the setup, modification, and release of > MPLS-TP >> connections and protection connections. >> >> * It MUST support mechanisms to provide traffic engineering, >> constraint-based routing and explicit path control. >> >> * It MUST provide mechanisms to address QoS and performance >> requirements (such as throughput, delay, packet loss, etc.) >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page > 8] >> >> Internet-Draft MPLS-TP Requirements July > 2008 >> >> >> while utilizing network resources efficiently and reliably. >> >> o MPLS-TP SHOULD support off-path (out-of-band) control and >> management planes. >> >> o The MPLS-TP control plane MUST be independent of any particular >> client or server layer control plane. >> >> o The control plane SHOULD facilitate the implementation of the >> service by providing end-to-end seamless connectivity and > service >> assurance. >> >> o The MPLS-TP control plane MUST support establishing all the >> connectivity patterns defined for the MPLS-TP transport plane >> (e.g., uni-directional and bidirectional P2P, uni-directional >> P2MP, etc.) including configuration of protection functions and >> any associated maintenance functions. >> >> o The MPLS-TP control pane must support the configuration and >> modification of OAM maintenance points as well as the > activation/ >> deactivation of OAM when the connection is established or >> modified. >> >> o An MPLS-TP control plane MUST support topology hiding and > address >> independence between domains. >> >> o At the boundary of a domain an MPLS-TP control plane MUST > support >> unique names or addresses identifying boundary points to be >> interconnected. >> >> o At the boundary of a domain an MPLS-TP control plane must > support >> group names or addresses identifying sets of boundary points to > be >> interconnected. >> >> o MPLS-TP layer network access points (or connection points that >> proxy for access points) SHOULD be able to be assigned names > which >> are available to clients to identify endpoints in call or >> connection requests. >> >> o An MPLS-TP control plane MUST support translation between >> externally visible endpoint names and internal network > addresses. >> >> o An MPLS-TP control plane MUST support constraint-based route >> calculation. >> >> o An MPLS-TP control plane MUST support provisioning and > application >> of routing constraint policies. >> >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page > 9] >> >> Internet-Draft MPLS-TP Requirements July > 2008 >> >> >> o An MPLS-TP control plane MUST support pre-provisioned connection >> protection. >> >> In some situations it is impractical to expect acceptable recovery >> performance to be achieved using dynamic recalculation of > connection >> routes. For this reason, it is necessary to allow for pre-planning >> of protection routes for selected connections. >> >> o The MPLS-TP control plane MUST support fast restoration. >> >> TOM: Define what "fast" means? >> >> o An MPLS-TP control plane MUST scale gracefully to support a > large >> number of connections. >> >> TOM: Define "large" and "scale" here? >> >> [Include some numbers to indicate how large the CP is expected to >> scale to?] >> >> o An MPLS-TP control plane MUST clearly distinguish resources >> belonging to the MPLS-TP layer network from those in other layer >> networks that may also be under control plane control. >> >> TOM: Do you mean under the same control plane or a different one (or >> both)? >> >> o An MPLS-TP control plane MUST support the independent >> identification of logically distinct control plane elements. >> >> o It MUST be possible to identify and provision these elements >> independently, in order to reorganize the control plane > components >> without impacting the data plane services and vice-versa. >> >> Architecturally distinct elements in a control plane include: nodes >> and links, control plane functional components, protocol > controllers, >> etc. >> >> o An MPLS-TP control plane SHOULD provide a common control > mechanism >> for architecturally similar operations. >> >> o An MPLS-TP control plane MUST support mechanisms for > partitioning >> the network under control into separate peer or hierarchical >> control domains. >> >> o To enable the deployment of a unified control plane aimed at >> controlling the set of transport technologies used in a > transport >> network, the MPLS-TP control plane MUST also be applicable to >> other transport layer networks and provide common operations >> across multiple layers. In order to maintain independence > between >> MPLS-TP and its respective client and server layer network >> separate control plane instances SHOULD be used to control a set >> of transport layer networks. >> >> >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page > 10] >> >> Internet-Draft MPLS-TP Requirements July > 2008 >> >> >> o MPLS-TP SHOULD detect and recover from control plane failures > and >> degradations using graceful operations. >> >> 2.5. Network Management (NM) requirements >> >> o MPLS-TP MUST operate under a common operation, control and >> management paradigm with respect to other transport technologies >> (e.g. SDH, OTN or WDM). >> >> o An MPLS-TP network MUST be able to be operated with a > centralized >> NMS system. >> >> o An MPLS-TP network SHOULD be able to be operated by a > centralized >> NMS system with the support of a distributed control plane. >> >> TOM: I don't know what this means or the one above it, or how this >> requirement would translate into anything tangible in the MPLS-TP >> protocol designs. I suggest it be removed. >> >> o The MPLS-TP management plane MUST NOT depend on a specific > client >> layer management plane. >> >> TOM: This is a non-sequitur if you ask me; please strike it. >> >> o The MPLS-TP management plane MUST support the configuration and >> modification of OAM maintenance points as well as the > activation/ >> deactivation of OAM when the connection is established or >> modified. >> >> For the complete set of requirements related to NM functionality > for >> MPLS-TP, see the MPLS-TP NM requirements document [REF]. >> >> 2.6. OAM requirements >> >> o MPLS-TP SHOULD provide a comprehensive set of capabilities (that >> are independent of and agnostic to the transmitted client >> services) to support fault management, performance monitoring > (of >> the MPLS-TP network and the services), protection switching, > fault >> localization, signal quality measurement, etc. >> >> o A mechanism SHOULD be supported to detect, diagnose and enable >> recovery from facility and equipment failures and performance >> degradations according to the requirements of the service. >> >> o MPLS-TP OAM MUST be able to operate without IP functionality and >> without relying on control and/or management planes. >> >> For the complete set of requirements related to OAM functionality > for >> MPLS-TP, see the MPLS-TP OAM requirements document [REF]. >> >> TOM: I suggest you just remove these two sections and refer to the >> OAM/Managemetn documents. >> >> 2.7. Network performance management (PM) requirements >> >> >> >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page > 11] >> >> Internet-Draft MPLS-TP Requirements July > 2008 >> >> >> o MPLS-TP MUST support traffic-engineering capabilities with >> traffic- and/or resource-oriented performance objectives. >> >> TOM: What are performance objectives? Do you mean traffic profiles >> such as QoS/bandwidth? >> >> o MPLS-TP MUST support a method to offer packet loss objectives >> comparable to those in TDM transport networks (only due to bit >> errors). >> >> For the complete set of requirements related to PM functionality > for >> MPLS-TP, see the MPLS-TP OAM requirements document [REF]. >> >> TOM: Again, I suggest you punt on this entire section and move it to >> the OAM doc. >> >> 2.8. Protection & Survivability requirements >> >> Network survivability plays a critical factor in the delivery of >> reliable services. Network availability is a significant > contributor >> to revenue and profit. Service guarantees in the form of SLAs >> require a resilient network that rapidly detects facility or node >> failures and restores network operation in accordance with the > terms >> of the SLA. >> >> The requirements in this section use of the recovery terminology >> defined in RFC 4427[RFC4427]. >> >> o MPLS-TP SHOULD support transport network style protection >> >> TOM: I would make this a MUST. >> >> switching mechanisms (tandem network connection protection, LSP >> protection and PW protection) to provide the sub-50ms recovery >> time required to maintain customer transparency, even when >> thousands of services are simultaneously affected by a failure. >> [Is sub-50ms really a requirement, do we want to clarify this >> further - is it sub-50ms end to end, or per link?] >> >> o >> >> * MPLS-TP recovery mechanisms SHOULD be applicable at various >> levels throughout the network, SPAN, tandem connection and > end- >> to-end. >> >> TOM: This sentence doesn't parse. Please re-write. >> >> Any recovery mechanism used in a tandem connection >> MUST be independent of other tandem connections. >> >> * MPLS-TP SHOULD support mechanisms that keep traffic flowing >> while the network recovers from failures. >> >> TOM: I would say this is a MUST. >> >> * MPLS-TP SHOULD support network restoration mechanisms >> controlled by a distributed control plane and/or by a >> management plane based. >> >> TOM: I would say this is a MUST. >> >> >> * >> >> + The restoration resources MAY be pre-planned and selected > a >> priori, or computed after failure occurrence. >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page > 12] >> >> Internet-Draft MPLS-TP Requirements July > 2008 >> >> >> + MPLS-TP MAY support shared-mesh restoration. >> >> + MPLS-TP SHOUD support soft LSP restoration. >> >> + MPLS-TP MAY support hard LSP restoration. >> >> + The restoration mechanism MUST be applicable to any >> topology. >> >> + Restoration priority MAY be implemented to determine the >> order in which connections should be restored (to minimize >> service restoration time as well as to gain access to >> available spare capacity on the best paths). Preemption >> priority MAY be used in the event that not all connections >> can be restored, in which case connections with lower >> preemption priority should be released. >> >> + The restoration mechanism SHOULD operate in synergy with >> other transport network technologies (SDH, OTN, WDM). >> >> * MPLS-TP SHOULD support data plane driven protection > mechanisms >> (without any dependency on a control plane or IP protocols) > to >> enable fast recovery from failure, and thereby to enhance the >> reliability and availability performance of MPLS-TP networks. >> >> * >> >> + MPLS-TP protection mechanisms SHOULD be applied to LSPs > and >> PWs. >> >> + MPLS-TP MUST support mechanisms that rapidly detect, > locate, >> notify and remedy network faults. >> >> + MPLS-TP MUST support 1:1 bidirectional protection > switching. >> The protection state of both ends of the protected entity >> MUST be synchronized. >> >> + MPLS-TP MAY support 1+1 unidirectional protection > switching. >> >> + MPLS-TP protection mechanisms MUST be applicable to both >> point-to-point and point-to-multipoint connections. >> >> + It SHOULD be possible to achieve protection at the MPLS-TP >> layer as fast as possible (subject to the temporal >> resolution of the defect detection mechanism). >> >> + Protection ratio MUST be of 100%, i.e., 100% of impaired >> working traffic MUST be protected for a failure on a >> single >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page > 13] >> >> Internet-Draft MPLS-TP Requirements July > 2008 >> >> >> working LSP. >> >> + Operator requests for manual control of protection > switching >> such as clear, lockout of protection, forced-switch and >> manual-switch commands MUST be supported. Prioritized >> protection between Signal Fail (SF), Signal Degradation > (SD) >> and operator switch requests MUST be supported. >> >> + MPLS-TP protection mechanisms MUST support revertive and >> non-revertive behaviour. o An extra traffic capability >> SHOULD be supported when possible. >> >> + MPLS-TP protection switching mechanisms MUST prevent >> frequent operation of the protection switch due to an >> intermittent defect. >> >> + MPLS-TP protection mechanisms MUST ensure co-ordination of >> timing of protection switches at multiple layers to avoid >> races and to allow the protection switching mechanism of > the >> server layer to fix the problem before switching at the >> MPLS-TP layer. >> >> + MPLS-TP MAY support mechanisms that are optimized for >> specific network topologies (Ring, Mesh) in order to > handle >> protection switching in a cost-efficient manner. >> >> 2.9. QoS requirements >> >> Service providers require advanced traffic management capabilities > to >> enforce and guarantee the QoS parameters of customers' SLAs. >> >> Quality of service mechanisms are required to ensure: >> >> o Support for differentiated services and different traffic types >> with traffic class separation associated with different traffic. >> >> o Prioritization of critical services. >> >> o Enabling the provisioning and the guarantee of Service Level >> Specifications (SLS), with support for hard and relative end-to- >> end BW guaranteed. >> >> o Controlled jitter and delay. >> >> o Guarantee of fair access to shared resources in an MPLS-TP >> network. >> >> >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page > 14] >> >> Internet-Draft MPLS-TP Requirements July > 2008 >> >> >> o Ability for OAM and data to share the same fate. >> >> TOM: This belongs in the OAM document. >> >> >> o Resources for control and management plane packets so that user >> plane traffic, regardless of the amount, will not cause control >> and management functions to become inoperative. >> >> The following QoS requirements apply to MPLS-TP: >> >> o MPLS-TP MUST be able to deliver the same degree of QoS that has >> been delivered by SDH/SONET systems. >> >> TOM: We can save on a lot of text and remove the "MPLS-TE MUST" or >> "MPLS-TP SHOULD" bits and simply say "MUST X" or "SHOULD Y". The >> MPLS-TP bit is implicit I think. >> >> o MPLS-TP MUST support transport bandwidth allocation to any >> granularity without any restrictions based on a circuit-switched >> multiplexing hierarchy. This attribute will provide service >> providers with the capability to route more customer service >> demands over the MPLS-TP network. >> >> [Should we refer here to the requirements specified in RFC 2702?] >> >> 2.10. Security requirements >> >> o MPLS-TP MUST ensure that the network and services are secured. >> >> o Traffic flows from different users MUST NOT be intermingled, but >> if this does occur then this MUST be detectable and the >> appropriate consequent actions taken. >> >> o MPLS-TP MUST ensure the separation of customer (client) and >> provider (server and peer network) addressing and other >> information. >> >> TOM: This requirement is stated above. >> >> o MPLS-TP MUST ensure that the control and management planes as > well >> as OAM traffic are secure from external attack. >> >> o MPLS-TP MUST provide mechanisms to ensure that the MPLS-TP > network >> remains secure and stable under situations of extreme stress. >> >> Examples of attacks and situations of extreme stress include (but > are >> not limited to) classical security attacks (e.g., hijacking, > privacy, >> non-repudiation, etc.) and attacks on network availability (e.g., >> denial of service (DoS) attacks). >> >> >> 3. IANA Considerations >> >> This document makes no request of IANA. >> >> Note to RFC Editor: this section may be removed on publication as >> an >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page > 15] >> >> Internet-Draft MPLS-TP Requirements July > 2008 >> >> >> RFC. >> >> >> 4. Security Considerations >> >> This document does not by itself raise any particular security >> considerations. >> >> >> 5. Acknowledgements >> >> The authors wish to thank Neil Harrison and Tomonori Takeda for > their >> review and enhancements to the text. >> >> >> 6. Informative References >> >> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate >> Requirement Levels", BCP 14, RFC 2119, March 1997. >> >> [RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection > and >> Restoration) Terminology for Generalized Multi-Protocol >> Label Switching (GMPLS)", RFC 4427, March 2006. >> >> [ITU.Y1401.2008] >> International Telecommunications Union, "Principles of >> interworking", ITU-T Recommendation Y.1401, February > 2008. >> >> >> Authors' Addresses >> >> Ben Niven-Jenkins (editor) >> BT >> 208 Callisto House, Adastral Park >> Ipswich, Suffolk IP5 3RE >> UK >> >> Email: benjamin.niven-jenkins@bt.com >> >> >> Deborah Brungard (editor) >> AT&T >> Rm. D1-3C22 - 200 S. Laurel Ave. >> Middletown, NJ 07748 >> USA >> >> Email: dbrungard@att.com >> >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page > 16] >> >> Internet-Draft MPLS-TP Requirements July > 2008 >> >> >> Malcolm Betts (editor) >> Nortel Networks >> 3500 Carling Avenue >> Ottawa, Ontario K2H 8E9 >> Canada >> >> Email: betts01@nortel.com >> >> >> Nurit Sprecher >> Nokia Siemens Networks >> 3 Hanagar St. Neve Ne'eman B >> Hod Hasharon, 45241 >> Israel >> >> Email: nurit.sprecher@nsn.com >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page > 17] >> >> Internet-Draft MPLS-TP Requirements July > 2008 >> >> >> Full Copyright Statement >> >> Copyright (C) The IETF Trust (2008). >> >> 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, THE IETF TRUST > 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. >> >> >> Intellectual Property >> >> 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. >> >> >> >> >> >> >> >> >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page > 18] >> >> >> >> _______________________________________________ >> Mpls-interop mailing list >> Mpls-interop@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-interop > _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop From mpls-interop-bounces@ietf.org Sun Jun 22 14:41:02 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B97953A67F3; Sun, 22 Jun 2008 14:41:02 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B202C3A67F3 for ; Sun, 22 Jun 2008 14:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.613 X-Spam-Level: X-Spam-Status: No, score=-2.613 tagged_above=-999 required=5 tests=[AWL=-0.614, BAYES_00=-2.599, J_CHICKENPOX_24=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMYBlMxhduOt for ; Sun, 22 Jun 2008 14:40:57 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 62D9F3A681A for ; Sun, 22 Jun 2008 14:40:56 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m5MLex6E022732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Jun 2008 23:40:59 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m5MLexuF010007; Sun, 22 Jun 2008 23:40:59 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 22 Jun 2008 23:40:58 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 22 Jun 2008 23:40:34 +0200 Message-ID: <9FF5BDAD88B9D84881609E89AC92FB83EBD3AF@DEMUEXC014.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mpls-interop] next MEAD team meeting Thread-Index: AcjSMNQsx4BuurjX8EeQxIcfmO8exAA0/R+VAEuIunAACtuUpAABBM4gABHRXI0AAaDF0A== From: "Sprecher, Nurit (NSN - IL/Israel - MiniMD)" To: "ext Thomas Nadeau" , "Ben Niven-Jenkins" , "Loa Andersson" , "MEAD team" X-OriginalArrivalTime: 22 Jun 2008 21:40:58.0875 (UTC) FILETIME=[A8A494B0:01C8D4B0] Cc: "Weingarten, Yaacov \(NSN - IL/Israel - MiniMD\)" Subject: Re: [Mpls-interop] next MEAD team meeting X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org Hi Tom, Personally I agree that both are the dynamic and the static options are important. You sais below: "> I agree it is optional. What I want to make sure is that it is not > so optional that it is completely removed from the design. The > language in the document now seems to be headed in that direction. > " I think I can live with tBEn's recommendation, the one that was supported also by Andy, that we can make both static & dynamic MUSTs and then clarify that when operating in a static mode MPLS-TP must not rely on any dynamic protocols. Best regards, Nurit -----Original Message----- From: ext Thomas Nadeau [mailto:tom.nadeau@bt.com] Sent: Sunday, June 22, 2008 23:51 To: Sprecher, Nurit (NSN - IL/Israel - MiniMD); Ben Niven-Jenkins; Loa Andersson; MEAD team Cc: Weingarten, Yaacov (NSN - IL/Israel - MiniMD) Subject: Re: [Mpls-interop] next MEAD team meeting On 6/22/08 8:22 AM, "Sprecher, Nurit (NSN - IL/Israel - MiniMD)" wrote: > Hi Tom, > Thanks for your response. > If you agree that the control plane in MPLS-TP is optional, then we > cannot say MUST. To make it stronger, we may think of changing the "MAY" > to "SHOULD". I DO NOT agree that it is optional. There are two different modes if you will, to run MPLS-TP; dynamic or static. Both are important. --Tom > Best regards, > Nurit > > -----Original Message----- > From: ext Thomas Nadeau [mailto:tom.nadeau@bt.com] > Sent: Sunday, June 22, 2008 14:52 > To: Sprecher, Nurit (NSN - IL/Israel - MiniMD); Ben Niven-Jenkins; Loa > Andersson; MEAD team > Cc: Weingarten, Yaacov (NSN - IL/Israel - MiniMD) > Subject: Re: [Mpls-interop] next MEAD team meeting > > > > > On 6/22/08 5:45 AM, "Sprecher, Nurit (NSN - IL/Israel - MiniMD)" > wrote: > >> Hi Thomas, >> Thanks for your comments. >> I still need to get into the details and meanings of your comments, >> but in the meantime I have one basic concern on your comment on " >> MPLS-TP connections MAY be able to be provisioned dynamically via a >> control plane. TOM: I insist that we change the MAY above to MUST. I >> want a dynamic version of this as much as a static one." >> This is one of the fundamental principles of the MPLS-TP, that the >> presence of a distributed control plane in support of network >> operations is optional (as in other transport technologies, like in > SDH, etc.). > > I agree it is optional. What I want to make sure is that it is not > so optional that it is completely removed from the design. The > language in the document now seems to be headed in that direction. > >> This is also the trigger for the definition of OAM capabilities which >> are independent of a control plane, as well as of the protection >> switching, etc. >> This is also addressed by the slides of the JW: "Desire to statically >> configure LSPs and PWEs via the management plane... > > I am not arguing against static; I am arguing for dynamic to be in > there as well. > >> Transport OAM capabilities don't exist for LSP and PWE independent of >> configuration mechanism (management plane or GMPLS or PWE control >> plane)... > > It depends on how you look at what "transport OAM capabilities". > From my perspective at BT, I definitely think there is a dynamic > flavor of this for sure. Again, I am not advocating removal of the > static parts, just the addition of the dynamic ones. And since they > are already there in large part, as part of the base MPLS > specification, I don't see any harm in specifying this. > > --Tom > > > >> With static provisioning, no dependency on routing or signaling (e.g. >> GMPLS or, IGP, RSVP, BGP, LDP)", etc. >> Best regards, >> Nurit >> >> -----Original Message----- >> From: mpls-interop-bounces@ietf.org >> [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext Thomas Nadeau >> Sent: Friday, June 20, 2008 21:38 >> To: Ben Niven-Jenkins; Loa Andersson; MEAD team >> Subject: Re: [Mpls-interop] next MEAD team meeting >> >> >> Comments on the document inline start with "TOM:" >> In general, please review the document and put more of an emphasis on >> the use of "MUST" rather than "MAY" or "SHOULD". The IETG frowns on >> requirements documents that are too optional. >> >> --Tom >> >> >> >> >> >> Network Working Group B. Niven-Jenkins, > Ed. >> Internet-Draft > BT >> Intended status: Informational D. Brungard, > Ed. >> Expires: January 2, 2009 > AT&T >> M. Betts, > Ed. >> Nortel > Networks >> N. > Sprecher >> Nokia Siemens > Networks >> July 01, >> 2008 >> >> >> MPLS-TP Requirements >> draft-jenkins-mpls-mplstp-requirements-00 >> >> Status of this Memo >> >> By submitting this Internet-Draft, each author represents that any >> applicable patent or other IPR claims of which he or she is aware >> have been or will be disclosed, and any of which he or she becomes >> aware will be disclosed, in accordance with Section 6 of BCP 79. >> >> 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. >> >> This Internet-Draft will expire on January 2, 2009. >> >> Abstract >> >> This document will outline the requirements for MPLS-TP. >> >> Requirements Language >> >> 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 [RFC2119]. >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page > 1] >> >> Internet-Draft MPLS-TP Requirements July > 2008 >> >> >> Table of Contents >> >> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . > 3 >> 2. MPLS-TP Requirements . . . . . . . . . . . . . . . . . . . . . > 5 >> 2.1. General requirements . . . . . . . . . . . . . . . . . . . > 5 >> 2.2. Layering requirements . . . . . . . . . . . . . . . . . . > 6 >> 2.3. Data plane requirements . . . . . . . . . . . . . . . . . > 7 >> 2.4. Control plane requirements . . . . . . . . . . . . . . . . > 8 >> 2.5. Network Management (NM) requirements . . . . . . . . . . . > 11 >> 2.6. OAM requirements . . . . . . . . . . . . . . . . . . . . . > 11 >> 2.7. Network performance management (PM) requirements . . . . . > 11 >> 2.8. Protection & Survivability requirements . . . . . . . . . > 12 >> 2.9. QoS requirements . . . . . . . . . . . . . . . . . . . . . > 14 >> 2.10. Security requirements . . . . . . . . . . . . . . . . . . > 15 >> 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . > 15 >> 4. Security Considerations . . . . . . . . . . . . . . . . . . . > 16 >> 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . > 16 >> 6. Informative References . . . . . . . . . . . . . . . . . . . . > 16 >> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . > 16 >> Intellectual Property and Copyright Statements . . . . . . . . . . >> 18 >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page > 2] >> >> Internet-Draft MPLS-TP Requirements July > 2008 >> >> >> 1. Introduction >> >> For many years, SONET/SDH has provided service providers with a > high >> benchmark for reliability and operational simplicity. With the >> accelerating growth of packet-based services (such as Ethernet, > VoIP, >> L2/L3 VPN, IPTV, RAN backhauling, etc.), service providers are in >> need of capabilities to efficiently support packet-based services > on >> their transport networks. The need to increase their revenue while >> remaining competitive forces operators to look for the lowest > network >> Total Cost of Ownership (TCO). Investment in both Capital >> Expenditure (CAPEX) and Operational Expense (OPEX) should be > minimal. >> >> Carriers are considering migrating to packet transport networks in >> order to reduce their costs and to improve their ability to support >> services with guaranteed SLAs. Migrating from SONET/SDH to packet >> transport networks should not involve dramatic changes in network >> operation, should not necessitate extensive retraining, and should >> not require major changes to existing work practices. The aim is > to >> preserve the look-and-feel to which carriers have become accustomed >> in deploying their SONET/SDH networks, while providing common, > multi- >> layer operations, resiliency, control and management for packet, >> circuit and lambda transport networks. >> >> An important attribute of a transport network is its ability to >> function independently from both its client and server > (transmission >> media) layer networks. It should be capable of transmitting over > any >> media. Another key characteristic of transport networks is the >> capability to maintain the integrity of the client signal between > its >> ingress and egress ports. >> >> TOM: I would use something other than "client signal" here. Something >> like "client path" or something is what I think you mean. >> >> A transport network must provide the means >> to commit quality of service objectives to clients. This is > achieved >> by providing a mechanism for client network service demarcation for >> the network path together with an associated network resiliency >> mechanism. A transport network must also provide a method of > service >> monitoring in order to verify the delivery of an agreed quality of >> service. This is enabled by means of carrier-grade OAM tools. >> >> The connectivity service is the basic service provided by a > transport >> network. >> >> TOM: Is it? Does the transport really provide connections or does it >> provide transport paths? I am sensitive to the terms used here. We >> don't want this to become a connect-fest. Seems to me that you >> explain > >> this better in the next sentence anyhow. >> >> The purpose of a transport network is to transparently >> carry client signals (i.e. the stream of client PDUs or client >> bits) >> >> TOM: Again, I don't like the term "signals" here. Use "client data" >> or > >> something. >> >> between endpoints in the network (typically over several > intermediate >> nodes). These endpoints may be service switching points or service >> terminating points. The connectivity services offered to customers >> are aggregated into large, long-holding time pipes/trunks which >> >> TOM: Do you really mean to call these "time pipes"? Sounds too >> futuristic even for this work. *) I think you mean "...into >> relatively large, long-lasting paths..." >> >> enable the efficient and reliable operation of the transport > network. >> These trunks are modified infrequently. >> >> TOM: Keep the terminology consistent here too. There is the use of >> "trunks", "pipes", etc... >> >> Aggregation and hierarchy are beneficial for achieving scalability >> and security since: >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page > 3] >> >> Internet-Draft MPLS-TP Requirements July > 2008 >> >> >> 1. They reduce the number of provisioning and forwarding states in >> the network core. >> >> 2. They reduce load and the cost of implementing service assurance >> and fault management. >> >> TOM: Do they really reduce load? This is one of those fluffy, >> open-ended terms like "scaleability" that I don't like used unless it >> is clearly defined. >> >> 3. Client signals are completely encapsulated and isolated from > each >> other. This also allows complete isolation of customer traffic >> from carrier operations. >> >> TOM: Does this really happen at the data or control plane or both? Or >> do we care? >> >> >> Client signals are first transparently encapsulated. These >> encapsulated client signals are then aggregated for transport > through >> the network in order to optimize network management. Server layer >> OAM is used to monitor the transport integrity of the client layer >> aggregate. At any hop, the aggregated signals may be further >> aggregated in lower layer transport network paths for transport >> across intermediate shared links. The encapsulated client signals >> are extracted at the edges of aggregation domains, and are either >> delivered to the client or forwarded to another domain. In the > core >> of the network, only the server layer aggregated signals are >> monitored; individual client signals are monitored at the network >> boundary in the client layer network. >> >> TOM: I am not sure the above is appropriate for a requirements > document. >> It sounds like you are spelling out an algorithm for how a solution >> should work. >> >> Quality-of-service mechanisms are required in the packet transport >> network to ensure the prioritization of critical services, to >> guarantee BW and to control jitter and delay. >> >> TOM: Are they required everywhere the service exists, or say just at >> the ingress/egress for policing/marking functions? While we are on >> the subject, do we want to be more specific about QoS requirements? >> >> Service providers require control and deterministic usage of > network >> resources. They need end-to-end control to engineer network paths >> and to efficiently utilize network resources. They require >> capabilities to statically (OSS based) provision deterministic, >> protected and secured services and their associated resources as > well >> as alternative control-plane options. >> >> TOM: They also require dynamic ones. Please put that in. I don't >> want > >> to be asking for only a completely static system. >> >> The transport network must be capable of transporting multiple >> services in a scalable manner. >> >> TOM: Again, this use of "scalable" offends me. Please be more >> specific > >> or take the sentence out as it is meaningless as stated. >> >> Carriers will still need to cope with legacy networks (which are >> composed of many layers and technologies), thus the packet > transport >> network should interwork with other packet and transport networks >> (both horizontally and vertically). Vertical interworking is also >> known as client/server or network interworking. Horizontal >> interworking is also known as peer-partition or service > interworking. >> >> TOM: Didn't you just say that vertical interworking was client >> interworking in the first sentence? How can horizontal be service >> interworking as well? >> >> For more details on each type of interworking and some of the > issues >> that may arise (especially with horizontal interworking) see >> [ITU.Y1401.2008]. >> >> MPLS is a maturing packet technology and it is already playing an >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page > 4] >> >> Internet-Draft MPLS-TP Requirements July > 2008 >> >> >> important role in transport networks and services. However, not > all >> of MPLS's capabilities and mechnisms are needed and/or consistent >> with transport network operations. This document identifies the >> required capabilities for MPLS so that it can better fit a > transport >> role. >> >> TOM: I think you want to say "identifies the required sub-set of >> capabilities..." and later "potentially new ons specific for >> transport networks" which it seems you say two paragraphs later. >> >> Combining the packet experience of MPLS with the operational >> experience of SONET/SDH constitutes a packet transport technology >> named MPLS-TP. MPLS-TP will enable the migration of SONET/SDH >> networks to a packet-based network that will easily scale to > support >> packet services in a simple and cost effective way. >> >> MPLS-TP needs to combine the necessary existing capabilities of > MPLS >> with additional minimal mechanisms in order to meet the > requirements >> described in this document. >> >> The requirements of an MPLS transport profile are provided below. >> >> TOM: There is a terminology issue in the use of "MPLS-TP" or "an MPLS >> transport profile". That is, on the one hand you refer to a >> technology, but on the other hand you are referring to a specific >> profile. Which is it? >> >> >> 2. MPLS-TP Requirements >> >> 2.1. General requirements >> >> o MPLS-TP MUST offer as much commonality as possible with the MPLS >> user plane as defined by IETF. When MPLS offers multiple > options >> in this respect, MPLS-TP SHOULD select the minimum sub-set >> (necessary and sufficient subset) applicable to a transport >> network application. >> >> o Any new functionality that is defined to fulfil the requirements >> for MPLS-TP MUST be agreed within IETF and re-use (as far as >> practically possible) existing MPLS standards. >> >> o Mechanisms and capabilities MUST be able to interoperate with >> existing MPLS and PWE control and data planes where appropriate. >> >> TOM: Change PWE to "IETF PWE3" and "MPLS" to "IETF MPLS". There also >> need to be references here to the PWE3 architecture and MPLS >> architectures. >> >> o MPLS-TP MUST support traffic engineering capabilities that allow >> deterministic control of the use of network resources. >> >> o MPLS-TP MUST support the logical separation of the control and >> management planes from the user plane. >> >> o MPLS-TP SHOULD support the physical separation of the control > and >> management planes from the user plane. >> >> o MPLS-TP MUST support point to point (P2P) or point to multipoint >> (P2MP) connections. >> >> TOM: Are we avoiding MP2MP consciously or was it left out? >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page > 5] >> >> Internet-Draft MPLS-TP Requirements July > 2008 >> >> >> o MPLS-TP MUST support static provisioning of connections via an >> NMS/OSS (i.e. via the management plane). >> >> o Static provisioning MUST not depend on routing or signaling >> protocols (e.g. GMPLS, OSPF, IS-IS, RSVP, BGP, LDP etc.). >> >> o MPLS-TP connections MAY be able to be provisioned dynamically > via >> a control plane. >> >> TOM: I insist that we change the MAY above to MUST. I want a dynamic >> version of this as much as a static one. >> >> >> o The MPLS-TP data plane MUST be capable of functioning >> independently of the control or management plane used to operate >> the MPLS-TP layer network. That is the MPLS-TP data plane >> operation MUST continue to operate normally if the management >> plane or control plane that configured the connections fails. >> >> o MPLS-TP MUST support any network topology and be able to support >> increasing bandwidth demands, topology, number of customers or >> number of services incrementally. >> >> >> TOM: I think it is imperative that although an MPLS-TP is defined to >> play nicely with an MPLS one, it is imperative that one can >> distinguish between both, at least at the control plane, but perhaps >> at the data plane as well. >> >> 2.2. Layering requirements >> >> o An MPLS-TP network MUST operate in a multiple layer network >> environment consisting of the following independent layers: >> >> 1. A "service layer" instance in which the connections carry > the >> customer's (individual or bundled) service (may be point-to- >> point, point-to-multipoint or multipoint-to-multipoint >> services); >> >> 2. A "trunk layer" with point-to-point or point-to-multipoint >> connections which are used to carry aggregates of the > network >> "service layer" connections; and >> >> 3. A "transmission media layer" which provides sections > (two-port >> point-to-point connections) to carry the aggregate of > network >> trunk or network service connections on various physical >> media. >> >> TOM: This stuff belongs in the Terminology section at the top. >> >> MPLS-TP may provide the "service layer" (for P2P and P2MP services) >> and/or the "trunk layer" within a layer network environment. >> >> o An MPLS-TP layer network MUST support the transparent transport > of >> MPLS-TP and non MPLS-TP client layer networks. >> >> o An MPLS-TP layer network MUST be able to be transparently > carried >> over MPLS-TP and non MPLS-TP server layer networks (such as >> Ethernet, OTN, etc.) >> >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page > 6] >> >> Internet-Draft MPLS-TP Requirements July > 2008 >> >> >> o It MUST be possible to operate the MPLS-TP layer network >> independently of other layer networks (either MPLS-TP or non >> MPLS-TP). >> >> This is not only a technology requirement, different administrative >> groups may be responsible for different layer networks (even when >> they are of the same type)), and require the capability to >> operationally support the different layers. >> >> o It MUST be possible to hide MPLS-TP layer network addressing and >> other information (e.g. topology) from client layers. >> >> 2.3. Data plane requirements >> >> o The identification of each connection within its aggregate MUST > be >> supported. >> >> o A label in a particular section MUST uniquely identify the >> connection. >> >> o A connection's source MUST be identifiable at its destination. >> >> Connections can be aggregated into trunks by pushing and de- >> aggregated by popping labels. MPLS-TP labels may be swapped >> within > a >> connection in a layer network instance when the traffic is > forwarded >> from one MPLS-TP link connection to another MPLS-TP link > connection. >> >> o Labelling MUST make use of the MPLS label and label stack entry > as >> defined in RFC3032. >> >> o It MUST be possible to operate and configure the MPLS-TP data >> (transport) plane without any IP functionality. >> >> o MPLS-TP MUST support both unidirectional and bi-directional > point- >> to-point connections. >> >> o The forward and backward directions of a bi-directional > connection >> SHOULD follow the same path within the MPLS-TP network. >> >> TOM: I am not sure if we say that they SHOULD as much as "they MUST >> be > >> capable of". >> >> o The intermediate nodes SHOULD be aware about the binding of the >> forward and the backward directions belonging to the same bi- >> directional connection. >> >> TOM: Again, "SHOULD be capable of" seems better. >> >> o MPLS-TP SHOULD support unidirectional point-to-multipoint >> connections. >> >> o MPLS-TP connections MUST NOT perform merging in a way that >> prevents the unique identification of the source at the >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page > 7] >> >> Internet-Draft MPLS-TP Requirements July > 2008 >> >> >> destination (e.g. no use of LDP mp2p signaling in order to avoid >> losing LSP head-end information, no use of PHP, etc). >> >> o MPLS-TP SHOULD support transport and QoS mechanisms that can >> deliver statistical multiplexing gain. Packets exceeding the >> agreed traffic profile may be marked or discarded by the traffic >> conditioning at the ingress of the MPLS-TP network. >> >> TOM: How about egress policing + marking? >> >> >> o MPLS-TP MUST support connections through a single domain. >> >> o MPLS-TP SHOULD support connections through multiple domains. >> >> o MPLS-TP MUST be able to accommodate new traffic types. >> >> TOM: New traffic types other than those supported by MPLS? This >> doesn't make sense to me as this will result in MPLS-TP not being a >> subset of MPLS. >> >> o MPLS-TP SHOULD support mechanisms to safeguard against the >> provisioning of connections which contain forwarding loops. >> >> o MPLS-TP SHOULD support mechanisms to minimize traffic impact >> during network reconfiguration. >> >> o MPLS-TP SHOULD support mechanisms which ensure the integrity of >> the adapted information. >> >> o MPLS-TP MUST support an unambiguous and reliable means of >> distinguishing users' (client) packets from MPLS-TP control > plane >> and management plane packets. >> >> 2.4. Control plane requirements >> >> o A distributed control plane MAY be supported to enable fast, >> dynamic and reliable service provisioning in multi-vendor and >> multi-domain environments using standardized protocols that >> guarantee interoperability. >> >> o If a control plane is used for configuration of MPLS-TP >> connections then: >> >> * Failure and recovery of the control plane MUST NOT impact the >> MPLS-TP forwarding plane. >> >> TOM: This is difficult, as this really is handled in practice at both >> data and control planes, depending on how this is >> configured/designed, > >> and the re-signaling can impact the data plane. >> >> * It MUST support the setup, modification, and release of > MPLS-TP >> connections and protection connections. >> >> * It MUST support mechanisms to provide traffic engineering, >> constraint-based routing and explicit path control. >> >> * It MUST provide mechanisms to address QoS and performance >> requirements (such as throughput, delay, packet loss, etc.) >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page > 8] >> >> Internet-Draft MPLS-TP Requirements July > 2008 >> >> >> while utilizing network resources efficiently and reliably. >> >> o MPLS-TP SHOULD support off-path (out-of-band) control and >> management planes. >> >> o The MPLS-TP control plane MUST be independent of any particular >> client or server layer control plane. >> >> o The control plane SHOULD facilitate the implementation of the >> service by providing end-to-end seamless connectivity and > service >> assurance. >> >> o The MPLS-TP control plane MUST support establishing all the >> connectivity patterns defined for the MPLS-TP transport plane >> (e.g., uni-directional and bidirectional P2P, uni-directional >> P2MP, etc.) including configuration of protection functions and >> any associated maintenance functions. >> >> o The MPLS-TP control pane must support the configuration and >> modification of OAM maintenance points as well as the > activation/ >> deactivation of OAM when the connection is established or >> modified. >> >> o An MPLS-TP control plane MUST support topology hiding and > address >> independence between domains. >> >> o At the boundary of a domain an MPLS-TP control plane MUST > support >> unique names or addresses identifying boundary points to be >> interconnected. >> >> o At the boundary of a domain an MPLS-TP control plane must > support >> group names or addresses identifying sets of boundary points to > be >> interconnected. >> >> o MPLS-TP layer network access points (or connection points that >> proxy for access points) SHOULD be able to be assigned names > which >> are available to clients to identify endpoints in call or >> connection requests. >> >> o An MPLS-TP control plane MUST support translation between >> externally visible endpoint names and internal network > addresses. >> >> o An MPLS-TP control plane MUST support constraint-based route >> calculation. >> >> o An MPLS-TP control plane MUST support provisioning and > application >> of routing constraint policies. >> >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page > 9] >> >> Internet-Draft MPLS-TP Requirements July > 2008 >> >> >> o An MPLS-TP control plane MUST support pre-provisioned connection >> protection. >> >> In some situations it is impractical to expect acceptable recovery >> performance to be achieved using dynamic recalculation of > connection >> routes. For this reason, it is necessary to allow for pre-planning >> of protection routes for selected connections. >> >> o The MPLS-TP control plane MUST support fast restoration. >> >> TOM: Define what "fast" means? >> >> o An MPLS-TP control plane MUST scale gracefully to support a > large >> number of connections. >> >> TOM: Define "large" and "scale" here? >> >> [Include some numbers to indicate how large the CP is expected to >> scale to?] >> >> o An MPLS-TP control plane MUST clearly distinguish resources >> belonging to the MPLS-TP layer network from those in other layer >> networks that may also be under control plane control. >> >> TOM: Do you mean under the same control plane or a different one (or >> both)? >> >> o An MPLS-TP control plane MUST support the independent >> identification of logically distinct control plane elements. >> >> o It MUST be possible to identify and provision these elements >> independently, in order to reorganize the control plane > components >> without impacting the data plane services and vice-versa. >> >> Architecturally distinct elements in a control plane include: nodes >> and links, control plane functional components, protocol > controllers, >> etc. >> >> o An MPLS-TP control plane SHOULD provide a common control > mechanism >> for architecturally similar operations. >> >> o An MPLS-TP control plane MUST support mechanisms for > partitioning >> the network under control into separate peer or hierarchical >> control domains. >> >> o To enable the deployment of a unified control plane aimed at >> controlling the set of transport technologies used in a > transport >> network, the MPLS-TP control plane MUST also be applicable to >> other transport layer networks and provide common operations >> across multiple layers. In order to maintain independence > between >> MPLS-TP and its respective client and server layer network >> separate control plane instances SHOULD be used to control a set >> of transport layer networks. >> >> >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page > 10] >> >> Internet-Draft MPLS-TP Requirements July > 2008 >> >> >> o MPLS-TP SHOULD detect and recover from control plane failures > and >> degradations using graceful operations. >> >> 2.5. Network Management (NM) requirements >> >> o MPLS-TP MUST operate under a common operation, control and >> management paradigm with respect to other transport technologies >> (e.g. SDH, OTN or WDM). >> >> o An MPLS-TP network MUST be able to be operated with a > centralized >> NMS system. >> >> o An MPLS-TP network SHOULD be able to be operated by a > centralized >> NMS system with the support of a distributed control plane. >> >> TOM: I don't know what this means or the one above it, or how this >> requirement would translate into anything tangible in the MPLS-TP >> protocol designs. I suggest it be removed. >> >> o The MPLS-TP management plane MUST NOT depend on a specific > client >> layer management plane. >> >> TOM: This is a non-sequitur if you ask me; please strike it. >> >> o The MPLS-TP management plane MUST support the configuration and >> modification of OAM maintenance points as well as the > activation/ >> deactivation of OAM when the connection is established or >> modified. >> >> For the complete set of requirements related to NM functionality > for >> MPLS-TP, see the MPLS-TP NM requirements document [REF]. >> >> 2.6. OAM requirements >> >> o MPLS-TP SHOULD provide a comprehensive set of capabilities (that >> are independent of and agnostic to the transmitted client >> services) to support fault management, performance monitoring > (of >> the MPLS-TP network and the services), protection switching, > fault >> localization, signal quality measurement, etc. >> >> o A mechanism SHOULD be supported to detect, diagnose and enable >> recovery from facility and equipment failures and performance >> degradations according to the requirements of the service. >> >> o MPLS-TP OAM MUST be able to operate without IP functionality and >> without relying on control and/or management planes. >> >> For the complete set of requirements related to OAM functionality > for >> MPLS-TP, see the MPLS-TP OAM requirements document [REF]. >> >> TOM: I suggest you just remove these two sections and refer to the >> OAM/Managemetn documents. >> >> 2.7. Network performance management (PM) requirements >> >> >> >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page > 11] >> >> Internet-Draft MPLS-TP Requirements July > 2008 >> >> >> o MPLS-TP MUST support traffic-engineering capabilities with >> traffic- and/or resource-oriented performance objectives. >> >> TOM: What are performance objectives? Do you mean traffic profiles >> such as QoS/bandwidth? >> >> o MPLS-TP MUST support a method to offer packet loss objectives >> comparable to those in TDM transport networks (only due to bit >> errors). >> >> For the complete set of requirements related to PM functionality > for >> MPLS-TP, see the MPLS-TP OAM requirements document [REF]. >> >> TOM: Again, I suggest you punt on this entire section and move it to >> the OAM doc. >> >> 2.8. Protection & Survivability requirements >> >> Network survivability plays a critical factor in the delivery of >> reliable services. Network availability is a significant > contributor >> to revenue and profit. Service guarantees in the form of SLAs >> require a resilient network that rapidly detects facility or node >> failures and restores network operation in accordance with the > terms >> of the SLA. >> >> The requirements in this section use of the recovery terminology >> defined in RFC 4427[RFC4427]. >> >> o MPLS-TP SHOULD support transport network style protection >> >> TOM: I would make this a MUST. >> >> switching mechanisms (tandem network connection protection, LSP >> protection and PW protection) to provide the sub-50ms recovery >> time required to maintain customer transparency, even when >> thousands of services are simultaneously affected by a failure. >> [Is sub-50ms really a requirement, do we want to clarify this >> further - is it sub-50ms end to end, or per link?] >> >> o >> >> * MPLS-TP recovery mechanisms SHOULD be applicable at various >> levels throughout the network, SPAN, tandem connection and > end- >> to-end. >> >> TOM: This sentence doesn't parse. Please re-write. >> >> Any recovery mechanism used in a tandem connection >> MUST be independent of other tandem connections. >> >> * MPLS-TP SHOULD support mechanisms that keep traffic flowing >> while the network recovers from failures. >> >> TOM: I would say this is a MUST. >> >> * MPLS-TP SHOULD support network restoration mechanisms >> controlled by a distributed control plane and/or by a >> management plane based. >> >> TOM: I would say this is a MUST. >> >> >> * >> >> + The restoration resources MAY be pre-planned and selected > a >> priori, or computed after failure occurrence. >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page > 12] >> >> Internet-Draft MPLS-TP Requirements July > 2008 >> >> >> + MPLS-TP MAY support shared-mesh restoration. >> >> + MPLS-TP SHOUD support soft LSP restoration. >> >> + MPLS-TP MAY support hard LSP restoration. >> >> + The restoration mechanism MUST be applicable to any >> topology. >> >> + Restoration priority MAY be implemented to determine the >> order in which connections should be restored (to minimize >> service restoration time as well as to gain access to >> available spare capacity on the best paths). Preemption >> priority MAY be used in the event that not all connections >> can be restored, in which case connections with lower >> preemption priority should be released. >> >> + The restoration mechanism SHOULD operate in synergy with >> other transport network technologies (SDH, OTN, WDM). >> >> * MPLS-TP SHOULD support data plane driven protection > mechanisms >> (without any dependency on a control plane or IP protocols) > to >> enable fast recovery from failure, and thereby to enhance the >> reliability and availability performance of MPLS-TP networks. >> >> * >> >> + MPLS-TP protection mechanisms SHOULD be applied to LSPs > and >> PWs. >> >> + MPLS-TP MUST support mechanisms that rapidly detect, > locate, >> notify and remedy network faults. >> >> + MPLS-TP MUST support 1:1 bidirectional protection > switching. >> The protection state of both ends of the protected entity >> MUST be synchronized. >> >> + MPLS-TP MAY support 1+1 unidirectional protection > switching. >> >> + MPLS-TP protection mechanisms MUST be applicable to both >> point-to-point and point-to-multipoint connections. >> >> + It SHOULD be possible to achieve protection at the MPLS-TP >> layer as fast as possible (subject to the temporal >> resolution of the defect detection mechanism). >> >> + Protection ratio MUST be of 100%, i.e., 100% of impaired >> working traffic MUST be protected for a failure on a >> single >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page > 13] >> >> Internet-Draft MPLS-TP Requirements July > 2008 >> >> >> working LSP. >> >> + Operator requests for manual control of protection > switching >> such as clear, lockout of protection, forced-switch and >> manual-switch commands MUST be supported. Prioritized >> protection between Signal Fail (SF), Signal Degradation > (SD) >> and operator switch requests MUST be supported. >> >> + MPLS-TP protection mechanisms MUST support revertive and >> non-revertive behaviour. o An extra traffic capability >> SHOULD be supported when possible. >> >> + MPLS-TP protection switching mechanisms MUST prevent >> frequent operation of the protection switch due to an >> intermittent defect. >> >> + MPLS-TP protection mechanisms MUST ensure co-ordination of >> timing of protection switches at multiple layers to avoid >> races and to allow the protection switching mechanism of > the >> server layer to fix the problem before switching at the >> MPLS-TP layer. >> >> + MPLS-TP MAY support mechanisms that are optimized for >> specific network topologies (Ring, Mesh) in order to > handle >> protection switching in a cost-efficient manner. >> >> 2.9. QoS requirements >> >> Service providers require advanced traffic management capabilities > to >> enforce and guarantee the QoS parameters of customers' SLAs. >> >> Quality of service mechanisms are required to ensure: >> >> o Support for differentiated services and different traffic types >> with traffic class separation associated with different traffic. >> >> o Prioritization of critical services. >> >> o Enabling the provisioning and the guarantee of Service Level >> Specifications (SLS), with support for hard and relative end-to- >> end BW guaranteed. >> >> o Controlled jitter and delay. >> >> o Guarantee of fair access to shared resources in an MPLS-TP >> network. >> >> >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page > 14] >> >> Internet-Draft MPLS-TP Requirements July > 2008 >> >> >> o Ability for OAM and data to share the same fate. >> >> TOM: This belongs in the OAM document. >> >> >> o Resources for control and management plane packets so that user >> plane traffic, regardless of the amount, will not cause control >> and management functions to become inoperative. >> >> The following QoS requirements apply to MPLS-TP: >> >> o MPLS-TP MUST be able to deliver the same degree of QoS that has >> been delivered by SDH/SONET systems. >> >> TOM: We can save on a lot of text and remove the "MPLS-TE MUST" or >> "MPLS-TP SHOULD" bits and simply say "MUST X" or "SHOULD Y". The >> MPLS-TP bit is implicit I think. >> >> o MPLS-TP MUST support transport bandwidth allocation to any >> granularity without any restrictions based on a circuit-switched >> multiplexing hierarchy. This attribute will provide service >> providers with the capability to route more customer service >> demands over the MPLS-TP network. >> >> [Should we refer here to the requirements specified in RFC 2702?] >> >> 2.10. Security requirements >> >> o MPLS-TP MUST ensure that the network and services are secured. >> >> o Traffic flows from different users MUST NOT be intermingled, but >> if this does occur then this MUST be detectable and the >> appropriate consequent actions taken. >> >> o MPLS-TP MUST ensure the separation of customer (client) and >> provider (server and peer network) addressing and other >> information. >> >> TOM: This requirement is stated above. >> >> o MPLS-TP MUST ensure that the control and management planes as > well >> as OAM traffic are secure from external attack. >> >> o MPLS-TP MUST provide mechanisms to ensure that the MPLS-TP > network >> remains secure and stable under situations of extreme stress. >> >> Examples of attacks and situations of extreme stress include (but > are >> not limited to) classical security attacks (e.g., hijacking, > privacy, >> non-repudiation, etc.) and attacks on network availability (e.g., >> denial of service (DoS) attacks). >> >> >> 3. IANA Considerations >> >> This document makes no request of IANA. >> >> Note to RFC Editor: this section may be removed on publication as >> an >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page > 15] >> >> Internet-Draft MPLS-TP Requirements July > 2008 >> >> >> RFC. >> >> >> 4. Security Considerations >> >> This document does not by itself raise any particular security >> considerations. >> >> >> 5. Acknowledgements >> >> The authors wish to thank Neil Harrison and Tomonori Takeda for > their >> review and enhancements to the text. >> >> >> 6. Informative References >> >> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate >> Requirement Levels", BCP 14, RFC 2119, March 1997. >> >> [RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection > and >> Restoration) Terminology for Generalized Multi-Protocol >> Label Switching (GMPLS)", RFC 4427, March 2006. >> >> [ITU.Y1401.2008] >> International Telecommunications Union, "Principles of >> interworking", ITU-T Recommendation Y.1401, February > 2008. >> >> >> Authors' Addresses >> >> Ben Niven-Jenkins (editor) >> BT >> 208 Callisto House, Adastral Park >> Ipswich, Suffolk IP5 3RE >> UK >> >> Email: benjamin.niven-jenkins@bt.com >> >> >> Deborah Brungard (editor) >> AT&T >> Rm. D1-3C22 - 200 S. Laurel Ave. >> Middletown, NJ 07748 >> USA >> >> Email: dbrungard@att.com >> >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page > 16] >> >> Internet-Draft MPLS-TP Requirements July > 2008 >> >> >> Malcolm Betts (editor) >> Nortel Networks >> 3500 Carling Avenue >> Ottawa, Ontario K2H 8E9 >> Canada >> >> Email: betts01@nortel.com >> >> >> Nurit Sprecher >> Nokia Siemens Networks >> 3 Hanagar St. Neve Ne'eman B >> Hod Hasharon, 45241 >> Israel >> >> Email: nurit.sprecher@nsn.com >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page > 17] >> >> Internet-Draft MPLS-TP Requirements July > 2008 >> >> >> Full Copyright Statement >> >> Copyright (C) The IETF Trust (2008). >> >> 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, THE IETF TRUST > 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. >> >> >> Intellectual Property >> >> 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. >> >> >> >> >> >> >> >> >> >> >> >> Niven-Jenkins, et al. Expires January 2, 2009 [Page > 18] >> >> >> >> _______________________________________________ >> Mpls-interop mailing list >> Mpls-interop@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-interop > _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop From mpls-interop-bounces@ietf.org Mon Jun 23 01:38:13 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33D543A692D; Mon, 23 Jun 2008 01:38:13 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE8F03A6955 for ; Mon, 23 Jun 2008 01:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thSRvUHWf8cs for ; Mon, 23 Jun 2008 01:38:10 -0700 (PDT) Received: from smail6.alcatel.fr (colt-na5.alcatel.fr [62.23.212.5]) by core3.amsl.com (Postfix) with ESMTP id A23873A6959 for ; Mon, 23 Jun 2008 01:38:06 -0700 (PDT) Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.ad2.ad.alcatel.com [155.132.6.74]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m5N8c2ij009584; Mon, 23 Jun 2008 10:38:02 +0200 Received: from itvimn0i34082 ([151.98.71.76]) by FRVELSBHS02.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Mon, 23 Jun 2008 10:38:02 +0200 From: "Italo Busi" To: "'Loa Andersson'" , "'BRUNGARD, DEBORAH A, ATTLABS'" References: <485B70C2.3010405@pi.nu><9FF5BDAD88B9D84881609E89AC92FB83EBD1F7@DEMUEXC014.nsn-intra.net> <485BE7D3.1040808@pi.nu> Date: Mon, 23 Jun 2008 10:38:21 +0200 Message-ID: <00ed01c8d50c$7ec172b0$4c476297@vim.tlt.alcatel.it> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjS+oxykpiCiEFrSKaGeg3ms5bIkgCEBNYg In-Reply-To: <485BE7D3.1040808@pi.nu> X-OriginalArrivalTime: 23 Jun 2008 08:38:02.0619 (UTC) FILETIME=[730684B0:01C8D50C] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: 'MEAD team' Subject: [Mpls-interop] MPLS-TP Requirements Abstract (was RE: next MEAD team meeting) X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org If I understand properly the arguments in this discussion, it seems quite important to clarify in the scope that these requirements are SP requirements as well as the fact that the source of most of them (if not all) is ITU-T. What about the following abstract? " This document specifies the requirements for an MPLS Transport Profile (MPLS-TP) in order to support capabilities and functionalities as needed for packet transport network services and network operations. Unless explicitly mentioned, these requirements are derived from the set of requirements specified by ITU-T. This document is a product of a joint ITU-IETF effort. " Thanks, Italo > -----Original Message----- > From: mpls-interop-bounces@ietf.org > [mailto:mpls-interop-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Friday, June 20, 2008 7:25 PM > To: BRUNGARD, DEBORAH A, ATTLABS > Cc: MEAD team > Subject: Re: [Mpls-interop] next MEAD team meeting > > > > BRUNGARD, DEBORAH A, ATTLABS wrote: > > Hi, > > > > Thanks Loa for the hint. My understanding of the charter > was to capture > > the ITU requirements? > > yes - that is true... > > but we also need to capture all requirements for the MPLS-TP whether > they are in the captured by the ITU-T or not. > > > > What is the MEAD development work covering - both ITU > requirements and > > "other (anonymous) SPs requirements"? > > if there is "only" requirements that originates from ITU-T this is > not a problem. I am not looking for anonymous requirements, if there > is a requirement that is not from ITU-T we should make clear where it > came form > > /Loa > > > > Deborah > > > > > > -----Original Message----- > > From: Sprecher, Nurit (NSN - IL/Israel - MiniMD) > > [mailto:nurit.sprecher@nsn.com] > > Sent: Friday, June 20, 2008 5:23 AM > > To: ext Loa Andersson > > Cc: BRUNGARD, DEBORAH A, ATTLABS; MEAD team; Sprecher, Nurit (NSN - > > IL/Israel - MiniMD) > > Subject: RE: [Mpls-interop] next MEAD team meeting > > > > Hi, > > 1. I agree that validates may be a good option. > > 2. IMO, these requirements are not only the ITU-T view. I got these > > requirements from different SPs. As I indicated in the > beginning of the > > mail exchanges I would prefer to say: "This document specifies the > > requirements for MPLS-TP in order to support capabilities and > > functionalities as needed in transport environments (or > networks)." But > > this is something that we need the SPs to agree on. > > Please note also that in the proposal just below I forgot > to include the > > indication that this is a joint work of ITU-T and IETF. > > Best regards, > > Nurit > > > > > > -----Original Message----- > > From: ext Loa Andersson [mailto:loa@pi.nu] > > Sent: Friday, June 20, 2008 11:57 > > To: Sprecher, Nurit (NSN - IL/Israel - MiniMD) > > Cc: ext BRUNGARD, DEBORAH A, ATTLABS; MEAD team > > Subject: Re: [Mpls-interop] next MEAD team meeting > > > > All, > > > > just a few comments. > > > > Sprecher, Nurit (NSN - IL/Israel - MiniMD) wrote: > >> Hi Deborah, > >> I understand the intention, so how about the following (as we also > >> indicated in the introduction): > >> This document specifies > > > > I wonder if "specifies" is the right word - one way would be to say > > "validates" indicating that this how we (IETF) understands these > > requirements > > > > the ITU-T requirements for MPLS-TP in order to > >> support capabilities and functionalities of MPLS as needed in > >> transport environments. > > > > this indicates that there is nothing but ITU-T requirements in the > > document, is that true? > > > > /Loa > > > >> MPLS is a maturing packet technology and it is already playing an > >> important role in transport networks and services. > However, not all of > > > >> MPLS's capabilities and mechnisms are needed and/or > consistent with > >> transport network operations. This document identifies the > required > >> capabilities for MPLS so that it can better fit a transport role. > > > >> Please advise. > >> Best regards, > >> Nurit > >> > >> ________________________________ > >> > >> From: ext BRUNGARD, DEBORAH A, ATTLABS [mailto:dbrungard@att.com] > >> Sent: Thursday, June 19, 2008 23:04 > >> To: Sprecher, Nurit (NSN - IL/Israel - MiniMD); MEAD team > >> Subject: RE: [Mpls-interop] next MEAD team meeting > >> > >> > >> Hi Nurit, > >> > >> I would prefer to clearly say the requirements are ITU > requirements > >> for MPLS in a transport environment. I think among some > operators the > >> line between transport equipment and packet equipment has already > > blurred. > >> For many operators, the preference may be to align with MPLS > >> operations vs. transport. I think there are many differing > opinions on > > > >> what MPLS/packet transport needs to support in a transport > >> environment. So I prefer to clearly say these are ITU > requirements, > >> they do not necessarily reflect the operators contributing to this > > document. > >> > >> On the 2nd bullet, the requirements document has many > >> statements/requirements which may be interpreted by a > reader as gaps > >> in MPLS/IETF protocols. I was trying to say with this sentence the > >> document is not addressing/identifying IETF protocol > applicability or > >> lack of capabilities e.g. the sentence: > >> "Quality-of-service mechanisms are required in the packet transport > >> network to ensure the prioritization of critical services, to > >> guarantee BW and to control jitter and delay." > >> > >> QoS is not a new requirement for IETF protocols. Packet transport > >> networks (and this requirement document) are not the first > time that > >> QoS mechanisms are identified as needed. This requirement is not > >> intending to identify a gap in the current IETF protocol > set. This was > > > >> what I was trying to say. > >> > >> Suggestions? > >> Deborah > >> > >> > >> > >> ________________________________ > >> > >> From: Sprecher, Nurit (NSN - IL/Israel - MiniMD) > >> [mailto:nurit.sprecher@nsn.com] > >> Sent: Thursday, June 19, 2008 3:10 PM > >> To: BRUNGARD, DEBORAH A, ATTLABS; MEAD team > >> Cc: Sprecher, Nurit (NSN - IL/Israel - MiniMD) > >> Subject: RE: [Mpls-interop] next MEAD team meeting > >> > >> > >> > >> Hi Deborah, > >> > >> I have a few comments regarding the proposed abstract: > >> > >> * I think we should say "This document specifies the > >> requirements for MPLS-TP in order to support capabilities and > >> functionalities as needed in transport environments (or networks). > >> > >> * I do not understand the sentence: It does not > address IETF > >> protocol applicability or capabilities. Do you mean > applicability or > >> capability of the current IETF documents? As IMO it will be of the > >> documents we generate for MPLS-TP. > >> > >> * I think it is important to indicate that " This > document is > > a > >> product of a joint ITU-IETF effort". > >> > >> Best regards, > >> > >> Nurit > >> > >> > >> > >> -----Original Message----- > >> From: mpls-interop-bounces@ietf.org > >> [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext BRUNGARD, > >> DEBORAH A, ATTLABS > >> Sent: Thursday, June 19, 2008 21:11 > >> To: MEAD team > >> Subject: Re: [Mpls-interop] next MEAD team meeting > >> > >> > >> > >> Colleagues, > >> > >> > >> > >> I was thinking for the requirements we should include a > sentence in > >> the > >> > >> abstract to scope the MPLS-TP work as being part of a > joint ITU-IETF > >> > >> effort. Not all readers (now and future) will be aware of > why this is > >> > >> being done. In ccamp, we had done this for our ASON work. Maybe a > >> > >> similar sentence will be needed in the other documents? > Should we have > > > >> a > >> > >> common sentence? > >> > >> > >> > >> How about for the abstract: > >> > >> This document summarizes the ITU-T requirements for > MPLS-TP in order > >> to > >> > >> support capabilities and functionalities as needed by the > ITU-T. It > >> does > >> > >> not address IETF protocol applicability or capabilities. > This document > >> > >> is a product of a joint ITU-IETF effort. > >> > >> > >> > >> Deborah > >> > >> > >> > >> -----Original Message----- > >> > >> From: mpls-interop-bounces@ietf.org > >> > >> [mailto:mpls-interop-bounces@ietf.org] On Behalf Of Ben > Niven-Jenkins > >> > >> Sent: Thursday, June 19, 2008 1:21 PM > >> > >> To: Loa Andersson; MEAD team > >> > >> Subject: Re: [Mpls-interop] next MEAD team meeting > >> > >> > >> > >> Colleagues, > >> > >> > >> > >> FYI see attached for the latest draft of the MPLS-TP requirements > > draft. > >> > >> > >> Ben > >> > >> > >> > >> > >> > >> > >> > >> On 19/06/2008 16:00, "Loa Andersson" wrote: > >> > >> > >> > >>> All, > >> > >>> the MEAD team will have the next meeting on Tuesday 24, at 6pm > >>> i.e. 12am east coast and 9am California. > >> > >>> Again I plan the meeting to last an hour, and focus will be on the > >>> document status. > >> > >>> Stewart will send out dial in details as usual. > >> > >>> /Loa > >> > >> > >> _______________________________________________ > >> > >> Mpls-interop mailing list > >> > >> Mpls-interop@ietf.org > >> > >> https://www.ietf.org/mailman/listinfo/mpls-interop > >> > >> > >> > >> > >> > ---------------------------------------------------------------------- > >> -- > >> > >> _______________________________________________ > >> Mpls-interop mailing list > >> Mpls-interop@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls-interop > > > > > > -- > > Loa Andersson > > > > Principal Networking Architect > > Acreo AB phone: +46 8 632 77 14 > > Isafjordsgatan 22 mobile: +46 739 81 21 64 > > Kista, Sweden email: loa.andersson@acreo.se > > loa@pi.nu > > > -- > Loa Andersson > > Principal Networking Architect > Acreo AB phone: +46 8 632 77 14 > Isafjordsgatan 22 mobile: +46 739 81 21 64 > Kista, Sweden email: loa.andersson@acreo.se > loa@pi.nu > _______________________________________________ > Mpls-interop mailing list > Mpls-interop@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-interop > _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop From mpls-interop-bounces@ietf.org Mon Jun 23 01:47:38 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C5C53A6811; Mon, 23 Jun 2008 01:47:38 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3001A3A6909 for ; Mon, 23 Jun 2008 01:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.836 X-Spam-Level: X-Spam-Status: No, score=-2.836 tagged_above=-999 required=5 tests=[AWL=-0.237, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSksNaSJmayD for ; Mon, 23 Jun 2008 01:47:35 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 7ED503A6811 for ; Mon, 23 Jun 2008 01:46:38 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m5N8kQUm028965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jun 2008 10:46:26 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m5N8kCV9032587; Mon, 23 Jun 2008 10:46:22 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Jun 2008 10:46:20 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 23 Jun 2008 10:46:19 +0200 Message-ID: <9FF5BDAD88B9D84881609E89AC92FB83EBD4DE@DEMUEXC014.nsn-intra.net> In-Reply-To: <00ed01c8d50c$7ec172b0$4c476297@vim.tlt.alcatel.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mpls-interop] MPLS-TP Requirements Abstract (was RE: next MEADteam meeting) Thread-Index: AcjS+oxykpiCiEFrSKaGeg3ms5bIkgCEBNYgAAC8lTA= From: "Sprecher, Nurit (NSN - IL/Israel - MiniMD)" To: "ext Italo Busi" , "Loa Andersson" , "BRUNGARD, DEBORAH A, ATTLABS" X-OriginalArrivalTime: 23 Jun 2008 08:46:20.0290 (UTC) FILETIME=[9BA91620:01C8D50D] Cc: MEAD team Subject: Re: [Mpls-interop] MPLS-TP Requirements Abstract (was RE: next MEADteam meeting) X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org I support this. -----Original Message----- From: mpls-interop-bounces@ietf.org [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext Italo Busi Sent: Monday, June 23, 2008 11:38 To: 'Loa Andersson'; 'BRUNGARD, DEBORAH A, ATTLABS' Cc: 'MEAD team' Subject: [Mpls-interop] MPLS-TP Requirements Abstract (was RE: next MEADteam meeting) If I understand properly the arguments in this discussion, it seems quite important to clarify in the scope that these requirements are SP requirements as well as the fact that the source of most of them (if not all) is ITU-T. What about the following abstract? " This document specifies the requirements for an MPLS Transport Profile (MPLS-TP) in order to support capabilities and functionalities as needed for packet transport network services and network operations. Unless explicitly mentioned, these requirements are derived from the set of requirements specified by ITU-T. This document is a product of a joint ITU-IETF effort. " Thanks, Italo > -----Original Message----- > From: mpls-interop-bounces@ietf.org > [mailto:mpls-interop-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Friday, June 20, 2008 7:25 PM > To: BRUNGARD, DEBORAH A, ATTLABS > Cc: MEAD team > Subject: Re: [Mpls-interop] next MEAD team meeting > > > > BRUNGARD, DEBORAH A, ATTLABS wrote: > > Hi, > > > > Thanks Loa for the hint. My understanding of the charter > was to capture > > the ITU requirements? > > yes - that is true... > > but we also need to capture all requirements for the MPLS-TP whether > they are in the captured by the ITU-T or not. > > > > What is the MEAD development work covering - both ITU > requirements and > > "other (anonymous) SPs requirements"? > > if there is "only" requirements that originates from ITU-T this is > not a problem. I am not looking for anonymous requirements, if there > is a requirement that is not from ITU-T we should make clear where it > came form > > /Loa > > > > Deborah > > > > > > -----Original Message----- > > From: Sprecher, Nurit (NSN - IL/Israel - MiniMD) > > [mailto:nurit.sprecher@nsn.com] > > Sent: Friday, June 20, 2008 5:23 AM > > To: ext Loa Andersson > > Cc: BRUNGARD, DEBORAH A, ATTLABS; MEAD team; Sprecher, Nurit (NSN - > > IL/Israel - MiniMD) > > Subject: RE: [Mpls-interop] next MEAD team meeting > > > > Hi, > > 1. I agree that validates may be a good option. > > 2. IMO, these requirements are not only the ITU-T view. I got these > > requirements from different SPs. As I indicated in the > beginning of the > > mail exchanges I would prefer to say: "This document specifies the > > requirements for MPLS-TP in order to support capabilities and > > functionalities as needed in transport environments (or > networks)." But > > this is something that we need the SPs to agree on. > > Please note also that in the proposal just below I forgot > to include the > > indication that this is a joint work of ITU-T and IETF. > > Best regards, > > Nurit > > > > > > -----Original Message----- > > From: ext Loa Andersson [mailto:loa@pi.nu] > > Sent: Friday, June 20, 2008 11:57 > > To: Sprecher, Nurit (NSN - IL/Israel - MiniMD) > > Cc: ext BRUNGARD, DEBORAH A, ATTLABS; MEAD team > > Subject: Re: [Mpls-interop] next MEAD team meeting > > > > All, > > > > just a few comments. > > > > Sprecher, Nurit (NSN - IL/Israel - MiniMD) wrote: > >> Hi Deborah, > >> I understand the intention, so how about the following (as we also > >> indicated in the introduction): > >> This document specifies > > > > I wonder if "specifies" is the right word - one way would be to say > > "validates" indicating that this how we (IETF) understands these > > requirements > > > > the ITU-T requirements for MPLS-TP in order to > >> support capabilities and functionalities of MPLS as needed in > >> transport environments. > > > > this indicates that there is nothing but ITU-T requirements in the > > document, is that true? > > > > /Loa > > > >> MPLS is a maturing packet technology and it is already playing an > >> important role in transport networks and services. > However, not all of > > > >> MPLS's capabilities and mechnisms are needed and/or > consistent with > >> transport network operations. This document identifies the > required > >> capabilities for MPLS so that it can better fit a transport role. > > > >> Please advise. > >> Best regards, > >> Nurit > >> > >> ________________________________ > >> > >> From: ext BRUNGARD, DEBORAH A, ATTLABS [mailto:dbrungard@att.com] > >> Sent: Thursday, June 19, 2008 23:04 > >> To: Sprecher, Nurit (NSN - IL/Israel - MiniMD); MEAD team > >> Subject: RE: [Mpls-interop] next MEAD team meeting > >> > >> > >> Hi Nurit, > >> > >> I would prefer to clearly say the requirements are ITU > requirements > >> for MPLS in a transport environment. I think among some > operators the > >> line between transport equipment and packet equipment has already > > blurred. > >> For many operators, the preference may be to align with MPLS > >> operations vs. transport. I think there are many differing > opinions on > > > >> what MPLS/packet transport needs to support in a transport > >> environment. So I prefer to clearly say these are ITU > requirements, > >> they do not necessarily reflect the operators contributing to this > > document. > >> > >> On the 2nd bullet, the requirements document has many > >> statements/requirements which may be interpreted by a > reader as gaps > >> in MPLS/IETF protocols. I was trying to say with this sentence the > >> document is not addressing/identifying IETF protocol > applicability or > >> lack of capabilities e.g. the sentence: > >> "Quality-of-service mechanisms are required in the packet transport > >> network to ensure the prioritization of critical services, to > >> guarantee BW and to control jitter and delay." > >> > >> QoS is not a new requirement for IETF protocols. Packet transport > >> networks (and this requirement document) are not the first > time that > >> QoS mechanisms are identified as needed. This requirement is not > >> intending to identify a gap in the current IETF protocol > set. This was > > > >> what I was trying to say. > >> > >> Suggestions? > >> Deborah > >> > >> > >> > >> ________________________________ > >> > >> From: Sprecher, Nurit (NSN - IL/Israel - MiniMD) > >> [mailto:nurit.sprecher@nsn.com] > >> Sent: Thursday, June 19, 2008 3:10 PM > >> To: BRUNGARD, DEBORAH A, ATTLABS; MEAD team > >> Cc: Sprecher, Nurit (NSN - IL/Israel - MiniMD) > >> Subject: RE: [Mpls-interop] next MEAD team meeting > >> > >> > >> > >> Hi Deborah, > >> > >> I have a few comments regarding the proposed abstract: > >> > >> * I think we should say "This document specifies the > >> requirements for MPLS-TP in order to support capabilities and > >> functionalities as needed in transport environments (or networks). > >> > >> * I do not understand the sentence: It does not > address IETF > >> protocol applicability or capabilities. Do you mean > applicability or > >> capability of the current IETF documents? As IMO it will be of the > >> documents we generate for MPLS-TP. > >> > >> * I think it is important to indicate that " This > document is > > a > >> product of a joint ITU-IETF effort". > >> > >> Best regards, > >> > >> Nurit > >> > >> > >> > >> -----Original Message----- > >> From: mpls-interop-bounces@ietf.org > >> [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext BRUNGARD, > >> DEBORAH A, ATTLABS > >> Sent: Thursday, June 19, 2008 21:11 > >> To: MEAD team > >> Subject: Re: [Mpls-interop] next MEAD team meeting > >> > >> > >> > >> Colleagues, > >> > >> > >> > >> I was thinking for the requirements we should include a > sentence in > >> the > >> > >> abstract to scope the MPLS-TP work as being part of a > joint ITU-IETF > >> > >> effort. Not all readers (now and future) will be aware of > why this is > >> > >> being done. In ccamp, we had done this for our ASON work. Maybe a > >> > >> similar sentence will be needed in the other documents? > Should we have > > > >> a > >> > >> common sentence? > >> > >> > >> > >> How about for the abstract: > >> > >> This document summarizes the ITU-T requirements for > MPLS-TP in order > >> to > >> > >> support capabilities and functionalities as needed by the > ITU-T. It > >> does > >> > >> not address IETF protocol applicability or capabilities. > This document > >> > >> is a product of a joint ITU-IETF effort. > >> > >> > >> > >> Deborah > >> > >> > >> > >> -----Original Message----- > >> > >> From: mpls-interop-bounces@ietf.org > >> > >> [mailto:mpls-interop-bounces@ietf.org] On Behalf Of Ben > Niven-Jenkins > >> > >> Sent: Thursday, June 19, 2008 1:21 PM > >> > >> To: Loa Andersson; MEAD team > >> > >> Subject: Re: [Mpls-interop] next MEAD team meeting > >> > >> > >> > >> Colleagues, > >> > >> > >> > >> FYI see attached for the latest draft of the MPLS-TP requirements > > draft. > >> > >> > >> Ben > >> > >> > >> > >> > >> > >> > >> > >> On 19/06/2008 16:00, "Loa Andersson" wrote: > >> > >> > >> > >>> All, > >> > >>> the MEAD team will have the next meeting on Tuesday 24, at 6pm > >>> i.e. 12am east coast and 9am California. > >> > >>> Again I plan the meeting to last an hour, and focus will be on the > >>> document status. > >> > >>> Stewart will send out dial in details as usual. > >> > >>> /Loa > >> > >> > >> _______________________________________________ > >> > >> Mpls-interop mailing list > >> > >> Mpls-interop@ietf.org > >> > >> https://www.ietf.org/mailman/listinfo/mpls-interop > >> > >> > >> > >> > >> > ---------------------------------------------------------------------- > >> -- > >> > >> _______________________________________________ > >> Mpls-interop mailing list > >> Mpls-interop@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls-interop > > > > > > -- > > Loa Andersson > > > > Principal Networking Architect > > Acreo AB phone: +46 8 632 77 14 > > Isafjordsgatan 22 mobile: +46 739 81 21 64 > > Kista, Sweden email: loa.andersson@acreo.se > > loa@pi.nu > > > -- > Loa Andersson > > Principal Networking Architect > Acreo AB phone: +46 8 632 77 14 > Isafjordsgatan 22 mobile: +46 739 81 21 64 > Kista, Sweden email: loa.andersson@acreo.se > loa@pi.nu > _______________________________________________ > Mpls-interop mailing list > Mpls-interop@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-interop > _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop From mpls-interop-bounces@ietf.org Mon Jun 23 06:34:11 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B6913A6996; Mon, 23 Jun 2008 06:34:11 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D26EC3A69AF for ; Mon, 23 Jun 2008 06:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.483 X-Spam-Level: X-Spam-Status: No, score=-0.483 tagged_above=-999 required=5 tests=[AWL=0.449, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+VOWlihYvae for ; Mon, 23 Jun 2008 06:34:07 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id B28D63A6996 for ; Mon, 23 Jun 2008 06:34:06 -0700 (PDT) Received: from E03MVZ2-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jun 2008 14:34:05 +0100 Received: from 217.32.164.184 ([217.32.164.184]) by E03MVZ2-UKDY.domain1.systemhost.net ([193.113.30.120]) via Exchange Front-End Server mail.bt.com ([193.113.197.28]) with Microsoft Exchange Server HTTP-DAV ; Mon, 23 Jun 2008 13:34:03 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Mon, 23 Jun 2008 09:33:48 -0400 From: Thomas Nadeau To: "Sprecher, Nurit (NSN - IL/Israel - MiniMD)" , Ben Niven-Jenkins , Loa Andersson , MEAD team Message-ID: Thread-Topic: [Mpls-interop] next MEAD team meeting Thread-Index: AcjSMNQsx4BuurjX8EeQxIcfmO8exAA0/R+VAEuIunAACtuUpAABBM4gABHRXI0AAaDF0AAhY58Q In-Reply-To: <9FF5BDAD88B9D84881609E89AC92FB83EBD3AF@DEMUEXC014.nsn-intra.net> Mime-version: 1.0 X-OriginalArrivalTime: 23 Jun 2008 13:34:05.0709 (UTC) FILETIME=[CEA6F3D0:01C8D535] Cc: "Weingarten, Yaacov \(NSN - IL/Israel - MiniMD\)" Subject: Re: [Mpls-interop] next MEAD team meeting X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org Cool On 6/22/08 5:40 PM, "Sprecher, Nurit (NSN - IL/Israel - MiniMD)" wrote: > Hi Tom, > Personally I agree that both are the dynamic and the static options are > important. > You sais below: "> I agree it is optional. What I want to make sure > is that it is not >> so optional that it is completely removed from the design. The >> language in the document now seems to be headed in that direction. >> " > I think I can live with tBEn's recommendation, the one that was > supported also by Andy, that we can make both static & dynamic MUSTs and > then clarify that > when operating in a static mode MPLS-TP must not rely on any dynamic > protocols. > Best regards, > Nurit > > -----Original Message----- > From: ext Thomas Nadeau [mailto:tom.nadeau@bt.com] > Sent: Sunday, June 22, 2008 23:51 > To: Sprecher, Nurit (NSN - IL/Israel - MiniMD); Ben Niven-Jenkins; Loa > Andersson; MEAD team > Cc: Weingarten, Yaacov (NSN - IL/Israel - MiniMD) > Subject: Re: [Mpls-interop] next MEAD team meeting > > > > > On 6/22/08 8:22 AM, "Sprecher, Nurit (NSN - IL/Israel - MiniMD)" > wrote: > >> Hi Tom, >> Thanks for your response. >> If you agree that the control plane in MPLS-TP is optional, then we >> cannot say MUST. To make it stronger, we may think of changing the > "MAY" >> to "SHOULD". > > I DO NOT agree that it is optional. There are two different modes if > you will, to run MPLS-TP; dynamic or static. Both are important. > > --Tom > > >> Best regards, >> Nurit >> >> -----Original Message----- >> From: ext Thomas Nadeau [mailto:tom.nadeau@bt.com] >> Sent: Sunday, June 22, 2008 14:52 >> To: Sprecher, Nurit (NSN - IL/Israel - MiniMD); Ben Niven-Jenkins; Loa > >> Andersson; MEAD team >> Cc: Weingarten, Yaacov (NSN - IL/Israel - MiniMD) >> Subject: Re: [Mpls-interop] next MEAD team meeting >> >> >> >> >> On 6/22/08 5:45 AM, "Sprecher, Nurit (NSN - IL/Israel - MiniMD)" >> wrote: >> >>> Hi Thomas, >>> Thanks for your comments. >>> I still need to get into the details and meanings of your comments, >>> but in the meantime I have one basic concern on your comment on " >>> MPLS-TP connections MAY be able to be provisioned dynamically via a >>> control plane. TOM: I insist that we change the MAY above to MUST. I >>> want a dynamic version of this as much as a static one." >>> This is one of the fundamental principles of the MPLS-TP, that the >>> presence of a distributed control plane in support of network >>> operations is optional (as in other transport technologies, like in >> SDH, etc.). >> >> I agree it is optional. What I want to make sure is that it is not > >> so optional that it is completely removed from the design. The >> language in the document now seems to be headed in that direction. >> >>> This is also the trigger for the definition of OAM capabilities which > >>> are independent of a control plane, as well as of the protection >>> switching, etc. >>> This is also addressed by the slides of the JW: "Desire to statically > >>> configure LSPs and PWEs via the management plane... >> >> I am not arguing against static; I am arguing for dynamic to be in > >> there as well. >> >>> Transport OAM capabilities don't exist for LSP and PWE independent of > >>> configuration mechanism (management plane or GMPLS or PWE control >>> plane)... >> >> It depends on how you look at what "transport OAM capabilities". >> From my perspective at BT, I definitely think there is a dynamic >> flavor of this for sure. Again, I am not advocating removal of the >> static parts, just the addition of the dynamic ones. And since they >> are already there in large part, as part of the base MPLS >> specification, I don't see any harm in specifying this. >> >> --Tom >> >> >> >>> With static provisioning, no dependency on routing or signaling (e.g. >>> GMPLS or, IGP, RSVP, BGP, LDP)", etc. >>> Best regards, >>> Nurit >>> >>> -----Original Message----- >>> From: mpls-interop-bounces@ietf.org >>> [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext Thomas Nadeau >>> Sent: Friday, June 20, 2008 21:38 >>> To: Ben Niven-Jenkins; Loa Andersson; MEAD team >>> Subject: Re: [Mpls-interop] next MEAD team meeting >>> >>> >>> Comments on the document inline start with "TOM:" >>> In general, please review the document and put more of an emphasis on > >>> the use of "MUST" rather than "MAY" or "SHOULD". The IETG frowns on >>> requirements documents that are too optional. >>> >>> --Tom >>> >>> >>> >>> >>> >>> Network Working Group B. Niven-Jenkins, >> Ed. >>> Internet-Draft >> BT >>> Intended status: Informational D. Brungard, >> Ed. >>> Expires: January 2, 2009 >> AT&T >>> M. Betts, >> Ed. >>> Nortel >> Networks >>> N. >> Sprecher >>> Nokia Siemens >> Networks >>> July 01, >>> 2008 >>> >>> >>> MPLS-TP Requirements >>> draft-jenkins-mpls-mplstp-requirements-00 >>> >>> Status of this Memo >>> >>> By submitting this Internet-Draft, each author represents that any >>> applicable patent or other IPR claims of which he or she is aware >>> have been or will be disclosed, and any of which he or she becomes >>> aware will be disclosed, in accordance with Section 6 of BCP 79. >>> >>> 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. >>> >>> This Internet-Draft will expire on January 2, 2009. >>> >>> Abstract >>> >>> This document will outline the requirements for MPLS-TP. >>> >>> Requirements Language >>> >>> 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 [RFC2119]. >>> >>> >>> >>> Niven-Jenkins, et al. Expires January 2, 2009 [Page >> 1] >>> >>> Internet-Draft MPLS-TP Requirements July >> 2008 >>> >>> >>> Table of Contents >>> >>> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . >> 3 >>> 2. MPLS-TP Requirements . . . . . . . . . . . . . . . . . . . . . >> 5 >>> 2.1. General requirements . . . . . . . . . . . . . . . . . . . >> 5 >>> 2.2. Layering requirements . . . . . . . . . . . . . . . . . . >> 6 >>> 2.3. Data plane requirements . . . . . . . . . . . . . . . . . >> 7 >>> 2.4. Control plane requirements . . . . . . . . . . . . . . . . >> 8 >>> 2.5. Network Management (NM) requirements . . . . . . . . . . . >> 11 >>> 2.6. OAM requirements . . . . . . . . . . . . . . . . . . . . . >> 11 >>> 2.7. Network performance management (PM) requirements . . . . . >> 11 >>> 2.8. Protection & Survivability requirements . . . . . . . . . >> 12 >>> 2.9. QoS requirements . . . . . . . . . . . . . . . . . . . . . >> 14 >>> 2.10. Security requirements . . . . . . . . . . . . . . . . . . >> 15 >>> 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . >> 15 >>> 4. Security Considerations . . . . . . . . . . . . . . . . . . . >> 16 >>> 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . >> 16 >>> 6. Informative References . . . . . . . . . . . . . . . . . . . . >> 16 >>> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . >> 16 >>> Intellectual Property and Copyright Statements . . . . . . . . . . >>> 18 >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Niven-Jenkins, et al. Expires January 2, 2009 [Page >> 2] >>> >>> Internet-Draft MPLS-TP Requirements July >> 2008 >>> >>> >>> 1. Introduction >>> >>> For many years, SONET/SDH has provided service providers with a >> high >>> benchmark for reliability and operational simplicity. With the >>> accelerating growth of packet-based services (such as Ethernet, >> VoIP, >>> L2/L3 VPN, IPTV, RAN backhauling, etc.), service providers are in >>> need of capabilities to efficiently support packet-based services >> on >>> their transport networks. The need to increase their revenue > while >>> remaining competitive forces operators to look for the lowest >> network >>> Total Cost of Ownership (TCO). Investment in both Capital >>> Expenditure (CAPEX) and Operational Expense (OPEX) should be >> minimal. >>> >>> Carriers are considering migrating to packet transport networks in >>> order to reduce their costs and to improve their ability to > support >>> services with guaranteed SLAs. Migrating from SONET/SDH to packet >>> transport networks should not involve dramatic changes in network >>> operation, should not necessitate extensive retraining, and should >>> not require major changes to existing work practices. The aim is >> to >>> preserve the look-and-feel to which carriers have become > accustomed >>> in deploying their SONET/SDH networks, while providing common, >> multi- >>> layer operations, resiliency, control and management for packet, >>> circuit and lambda transport networks. >>> >>> An important attribute of a transport network is its ability to >>> function independently from both its client and server >> (transmission >>> media) layer networks. It should be capable of transmitting over >> any >>> media. Another key characteristic of transport networks is the >>> capability to maintain the integrity of the client signal between >> its >>> ingress and egress ports. >>> >>> TOM: I would use something other than "client signal" here. Something > >>> like "client path" or something is what I think you mean. >>> >>> A transport network must provide the means >>> to commit quality of service objectives to clients. This is >> achieved >>> by providing a mechanism for client network service demarcation > for >>> the network path together with an associated network resiliency >>> mechanism. A transport network must also provide a method of >> service >>> monitoring in order to verify the delivery of an agreed quality of >>> service. This is enabled by means of carrier-grade OAM tools. >>> >>> The connectivity service is the basic service provided by a >> transport >>> network. >>> >>> TOM: Is it? Does the transport really provide connections or does it >>> provide transport paths? I am sensitive to the terms used here. We >>> don't want this to become a connect-fest. Seems to me that you >>> explain >> >>> this better in the next sentence anyhow. >>> >>> The purpose of a transport network is to transparently >>> carry client signals (i.e. the stream of client PDUs or client >>> bits) >>> >>> TOM: Again, I don't like the term "signals" here. Use "client data" >>> or >> >>> something. >>> >>> between endpoints in the network (typically over several >> intermediate >>> nodes). These endpoints may be service switching points or > service >>> terminating points. The connectivity services offered to > customers >>> are aggregated into large, long-holding time pipes/trunks which >>> >>> TOM: Do you really mean to call these "time pipes"? Sounds too >>> futuristic even for this work. *) I think you mean "...into >>> relatively large, long-lasting paths..." >>> >>> enable the efficient and reliable operation of the transport >> network. >>> These trunks are modified infrequently. >>> >>> TOM: Keep the terminology consistent here too. There is the use of >>> "trunks", "pipes", etc... >>> >>> Aggregation and hierarchy are beneficial for achieving scalability >>> and security since: >>> >>> >>> >>> Niven-Jenkins, et al. Expires January 2, 2009 [Page >> 3] >>> >>> Internet-Draft MPLS-TP Requirements July >> 2008 >>> >>> >>> 1. They reduce the number of provisioning and forwarding states > in >>> the network core. >>> >>> 2. They reduce load and the cost of implementing service > assurance >>> and fault management. >>> >>> TOM: Do they really reduce load? This is one of those fluffy, >>> open-ended terms like "scaleability" that I don't like used unless it > >>> is clearly defined. >>> >>> 3. Client signals are completely encapsulated and isolated from >> each >>> other. This also allows complete isolation of customer > traffic >>> from carrier operations. >>> >>> TOM: Does this really happen at the data or control plane or both? Or > >>> do we care? >>> >>> >>> Client signals are first transparently encapsulated. These >>> encapsulated client signals are then aggregated for transport >> through >>> the network in order to optimize network management. Server layer >>> OAM is used to monitor the transport integrity of the client layer >>> aggregate. At any hop, the aggregated signals may be further >>> aggregated in lower layer transport network paths for transport >>> across intermediate shared links. The encapsulated client signals >>> are extracted at the edges of aggregation domains, and are either >>> delivered to the client or forwarded to another domain. In the >> core >>> of the network, only the server layer aggregated signals are >>> monitored; individual client signals are monitored at the network >>> boundary in the client layer network. >>> >>> TOM: I am not sure the above is appropriate for a requirements >> document. >>> It sounds like you are spelling out an algorithm for how a solution >>> should work. >>> >>> Quality-of-service mechanisms are required in the packet transport >>> network to ensure the prioritization of critical services, to >>> guarantee BW and to control jitter and delay. >>> >>> TOM: Are they required everywhere the service exists, or say just at >>> the ingress/egress for policing/marking functions? While we are on >>> the subject, do we want to be more specific about QoS requirements? >>> >>> Service providers require control and deterministic usage of >> network >>> resources. They need end-to-end control to engineer network paths >>> and to efficiently utilize network resources. They require >>> capabilities to statically (OSS based) provision deterministic, >>> protected and secured services and their associated resources as >> well >>> as alternative control-plane options. >>> >>> TOM: They also require dynamic ones. Please put that in. I don't >>> want >> >>> to be asking for only a completely static system. >>> >>> The transport network must be capable of transporting multiple >>> services in a scalable manner. >>> >>> TOM: Again, this use of "scalable" offends me. Please be more >>> specific >> >>> or take the sentence out as it is meaningless as stated. >>> >>> Carriers will still need to cope with legacy networks (which are >>> composed of many layers and technologies), thus the packet >> transport >>> network should interwork with other packet and transport networks >>> (both horizontally and vertically). Vertical interworking is also >>> known as client/server or network interworking. Horizontal >>> interworking is also known as peer-partition or service >> interworking. >>> >>> TOM: Didn't you just say that vertical interworking was client >>> interworking in the first sentence? How can horizontal be service >>> interworking as well? >>> >>> For more details on each type of interworking and some of the >> issues >>> that may arise (especially with horizontal interworking) see >>> [ITU.Y1401.2008]. >>> >>> MPLS is a maturing packet technology and it is already playing an >>> >>> >>> >>> Niven-Jenkins, et al. Expires January 2, 2009 [Page >> 4] >>> >>> Internet-Draft MPLS-TP Requirements July >> 2008 >>> >>> >>> important role in transport networks and services. However, not >> all >>> of MPLS's capabilities and mechnisms are needed and/or consistent >>> with transport network operations. This document identifies the >>> required capabilities for MPLS so that it can better fit a >> transport >>> role. >>> >>> TOM: I think you want to say "identifies the required sub-set of >>> capabilities..." and later "potentially new ons specific for >>> transport networks" which it seems you say two paragraphs later. >>> >>> Combining the packet experience of MPLS with the operational >>> experience of SONET/SDH constitutes a packet transport technology >>> named MPLS-TP. MPLS-TP will enable the migration of SONET/SDH >>> networks to a packet-based network that will easily scale to >> support >>> packet services in a simple and cost effective way. >>> >>> MPLS-TP needs to combine the necessary existing capabilities of >> MPLS >>> with additional minimal mechanisms in order to meet the >> requirements >>> described in this document. >>> >>> The requirements of an MPLS transport profile are provided below. >>> >>> TOM: There is a terminology issue in the use of "MPLS-TP" or "an MPLS > >>> transport profile". That is, on the one hand you refer to a >>> technology, but on the other hand you are referring to a specific >>> profile. Which is it? >>> >>> >>> 2. MPLS-TP Requirements >>> >>> 2.1. General requirements >>> >>> o MPLS-TP MUST offer as much commonality as possible with the > MPLS >>> user plane as defined by IETF. When MPLS offers multiple >> options >>> in this respect, MPLS-TP SHOULD select the minimum sub-set >>> (necessary and sufficient subset) applicable to a transport >>> network application. >>> >>> o Any new functionality that is defined to fulfil the > requirements >>> for MPLS-TP MUST be agreed within IETF and re-use (as far as >>> practically possible) existing MPLS standards. >>> >>> o Mechanisms and capabilities MUST be able to interoperate with >>> existing MPLS and PWE control and data planes where > appropriate. >>> >>> TOM: Change PWE to "IETF PWE3" and "MPLS" to "IETF MPLS". There also >>> need to be references here to the PWE3 architecture and MPLS >>> architectures. >>> >>> o MPLS-TP MUST support traffic engineering capabilities that > allow >>> deterministic control of the use of network resources. >>> >>> o MPLS-TP MUST support the logical separation of the control and >>> management planes from the user plane. >>> >>> o MPLS-TP SHOULD support the physical separation of the control >> and >>> management planes from the user plane. >>> >>> o MPLS-TP MUST support point to point (P2P) or point to > multipoint >>> (P2MP) connections. >>> >>> TOM: Are we avoiding MP2MP consciously or was it left out? >>> >>> >>> Niven-Jenkins, et al. Expires January 2, 2009 [Page >> 5] >>> >>> Internet-Draft MPLS-TP Requirements July >> 2008 >>> >>> >>> o MPLS-TP MUST support static provisioning of connections via an >>> NMS/OSS (i.e. via the management plane). >>> >>> o Static provisioning MUST not depend on routing or signaling >>> protocols (e.g. GMPLS, OSPF, IS-IS, RSVP, BGP, LDP etc.). >>> >>> o MPLS-TP connections MAY be able to be provisioned dynamically >> via >>> a control plane. >>> >>> TOM: I insist that we change the MAY above to MUST. I want a dynamic >>> version of this as much as a static one. >>> >>> >>> o The MPLS-TP data plane MUST be capable of functioning >>> independently of the control or management plane used to > operate >>> the MPLS-TP layer network. That is the MPLS-TP data plane >>> operation MUST continue to operate normally if the management >>> plane or control plane that configured the connections fails. >>> >>> o MPLS-TP MUST support any network topology and be able to > support >>> increasing bandwidth demands, topology, number of customers or >>> number of services incrementally. >>> >>> >>> TOM: I think it is imperative that although an MPLS-TP is defined to >>> play nicely with an MPLS one, it is imperative that one can >>> distinguish between both, at least at the control plane, but perhaps >>> at the data plane as well. >>> >>> 2.2. Layering requirements >>> >>> o An MPLS-TP network MUST operate in a multiple layer network >>> environment consisting of the following independent layers: >>> >>> 1. A "service layer" instance in which the connections carry >> the >>> customer's (individual or bundled) service (may be > point-to- >>> point, point-to-multipoint or multipoint-to-multipoint >>> services); >>> >>> 2. A "trunk layer" with point-to-point or point-to-multipoint >>> connections which are used to carry aggregates of the >> network >>> "service layer" connections; and >>> >>> 3. A "transmission media layer" which provides sections >> (two-port >>> point-to-point connections) to carry the aggregate of >> network >>> trunk or network service connections on various physical >>> media. >>> >>> TOM: This stuff belongs in the Terminology section at the top. >>> >>> MPLS-TP may provide the "service layer" (for P2P and P2MP > services) >>> and/or the "trunk layer" within a layer network environment. >>> >>> o An MPLS-TP layer network MUST support the transparent transport >> of >>> MPLS-TP and non MPLS-TP client layer networks. >>> >>> o An MPLS-TP layer network MUST be able to be transparently >> carried >>> over MPLS-TP and non MPLS-TP server layer networks (such as >>> Ethernet, OTN, etc.) >>> >>> >>> >>> >>> Niven-Jenkins, et al. Expires January 2, 2009 [Page >> 6] >>> >>> Internet-Draft MPLS-TP Requirements July >> 2008 >>> >>> >>> o It MUST be possible to operate the MPLS-TP layer network >>> independently of other layer networks (either MPLS-TP or non >>> MPLS-TP). >>> >>> This is not only a technology requirement, different > administrative >>> groups may be responsible for different layer networks (even when >>> they are of the same type)), and require the capability to >>> operationally support the different layers. >>> >>> o It MUST be possible to hide MPLS-TP layer network addressing > and >>> other information (e.g. topology) from client layers. >>> >>> 2.3. Data plane requirements >>> >>> o The identification of each connection within its aggregate MUST >> be >>> supported. >>> >>> o A label in a particular section MUST uniquely identify the >>> connection. >>> >>> o A connection's source MUST be identifiable at its destination. >>> >>> Connections can be aggregated into trunks by pushing and de- >>> aggregated by popping labels. MPLS-TP labels may be swapped >>> within >> a >>> connection in a layer network instance when the traffic is >> forwarded >>> from one MPLS-TP link connection to another MPLS-TP link >> connection. >>> >>> o Labelling MUST make use of the MPLS label and label stack entry >> as >>> defined in RFC3032. >>> >>> o It MUST be possible to operate and configure the MPLS-TP data >>> (transport) plane without any IP functionality. >>> >>> o MPLS-TP MUST support both unidirectional and bi-directional >> point- >>> to-point connections. >>> >>> o The forward and backward directions of a bi-directional >> connection >>> SHOULD follow the same path within the MPLS-TP network. >>> >>> TOM: I am not sure if we say that they SHOULD as much as "they MUST >>> be >> >>> capable of". >>> >>> o The intermediate nodes SHOULD be aware about the binding of the >>> forward and the backward directions belonging to the same bi- >>> directional connection. >>> >>> TOM: Again, "SHOULD be capable of" seems better. >>> >>> o MPLS-TP SHOULD support unidirectional point-to-multipoint >>> connections. >>> >>> o MPLS-TP connections MUST NOT perform merging in a way that >>> prevents the unique identification of the source at the >>> >>> >>> >>> Niven-Jenkins, et al. Expires January 2, 2009 [Page >> 7] >>> >>> Internet-Draft MPLS-TP Requirements July >> 2008 >>> >>> >>> destination (e.g. no use of LDP mp2p signaling in order to > avoid >>> losing LSP head-end information, no use of PHP, etc). >>> >>> o MPLS-TP SHOULD support transport and QoS mechanisms that can >>> deliver statistical multiplexing gain. Packets exceeding the >>> agreed traffic profile may be marked or discarded by the > traffic >>> conditioning at the ingress of the MPLS-TP network. >>> >>> TOM: How about egress policing + marking? >>> >>> >>> o MPLS-TP MUST support connections through a single domain. >>> >>> o MPLS-TP SHOULD support connections through multiple domains. >>> >>> o MPLS-TP MUST be able to accommodate new traffic types. >>> >>> TOM: New traffic types other than those supported by MPLS? This >>> doesn't make sense to me as this will result in MPLS-TP not being a >>> subset of MPLS. >>> >>> o MPLS-TP SHOULD support mechanisms to safeguard against the >>> provisioning of connections which contain forwarding loops. >>> >>> o MPLS-TP SHOULD support mechanisms to minimize traffic impact >>> during network reconfiguration. >>> >>> o MPLS-TP SHOULD support mechanisms which ensure the integrity of >>> the adapted information. >>> >>> o MPLS-TP MUST support an unambiguous and reliable means of >>> distinguishing users' (client) packets from MPLS-TP control >> plane >>> and management plane packets. >>> >>> 2.4. Control plane requirements >>> >>> o A distributed control plane MAY be supported to enable fast, >>> dynamic and reliable service provisioning in multi-vendor and >>> multi-domain environments using standardized protocols that >>> guarantee interoperability. >>> >>> o If a control plane is used for configuration of MPLS-TP >>> connections then: >>> >>> * Failure and recovery of the control plane MUST NOT impact > the >>> MPLS-TP forwarding plane. >>> >>> TOM: This is difficult, as this really is handled in practice at both > >>> data and control planes, depending on how this is >>> configured/designed, >> >>> and the re-signaling can impact the data plane. >>> >>> * It MUST support the setup, modification, and release of >> MPLS-TP >>> connections and protection connections. >>> >>> * It MUST support mechanisms to provide traffic engineering, >>> constraint-based routing and explicit path control. >>> >>> * It MUST provide mechanisms to address QoS and performance >>> requirements (such as throughput, delay, packet loss, etc.) >>> >>> >>> >>> Niven-Jenkins, et al. Expires January 2, 2009 [Page >> 8] >>> >>> Internet-Draft MPLS-TP Requirements July >> 2008 >>> >>> >>> while utilizing network resources efficiently and reliably. >>> >>> o MPLS-TP SHOULD support off-path (out-of-band) control and >>> management planes. >>> >>> o The MPLS-TP control plane MUST be independent of any particular >>> client or server layer control plane. >>> >>> o The control plane SHOULD facilitate the implementation of the >>> service by providing end-to-end seamless connectivity and >> service >>> assurance. >>> >>> o The MPLS-TP control plane MUST support establishing all the >>> connectivity patterns defined for the MPLS-TP transport plane >>> (e.g., uni-directional and bidirectional P2P, uni-directional >>> P2MP, etc.) including configuration of protection functions and >>> any associated maintenance functions. >>> >>> o The MPLS-TP control pane must support the configuration and >>> modification of OAM maintenance points as well as the >> activation/ >>> deactivation of OAM when the connection is established or >>> modified. >>> >>> o An MPLS-TP control plane MUST support topology hiding and >> address >>> independence between domains. >>> >>> o At the boundary of a domain an MPLS-TP control plane MUST >> support >>> unique names or addresses identifying boundary points to be >>> interconnected. >>> >>> o At the boundary of a domain an MPLS-TP control plane must >> support >>> group names or addresses identifying sets of boundary points to >> be >>> interconnected. >>> >>> o MPLS-TP layer network access points (or connection points that >>> proxy for access points) SHOULD be able to be assigned names >> which >>> are available to clients to identify endpoints in call or >>> connection requests. >>> >>> o An MPLS-TP control plane MUST support translation between >>> externally visible endpoint names and internal network >> addresses. >>> >>> o An MPLS-TP control plane MUST support constraint-based route >>> calculation. >>> >>> o An MPLS-TP control plane MUST support provisioning and >> application >>> of routing constraint policies. >>> >>> >>> >>> >>> Niven-Jenkins, et al. Expires January 2, 2009 [Page >> 9] >>> >>> Internet-Draft MPLS-TP Requirements July >> 2008 >>> >>> >>> o An MPLS-TP control plane MUST support pre-provisioned > connection >>> protection. >>> >>> In some situations it is impractical to expect acceptable recovery >>> performance to be achieved using dynamic recalculation of >> connection >>> routes. For this reason, it is necessary to allow for > pre-planning >>> of protection routes for selected connections. >>> >>> o The MPLS-TP control plane MUST support fast restoration. >>> >>> TOM: Define what "fast" means? >>> >>> o An MPLS-TP control plane MUST scale gracefully to support a >> large >>> number of connections. >>> >>> TOM: Define "large" and "scale" here? >>> >>> [Include some numbers to indicate how large the CP is expected to >>> scale to?] >>> >>> o An MPLS-TP control plane MUST clearly distinguish resources >>> belonging to the MPLS-TP layer network from those in other > layer >>> networks that may also be under control plane control. >>> >>> TOM: Do you mean under the same control plane or a different one (or >>> both)? >>> >>> o An MPLS-TP control plane MUST support the independent >>> identification of logically distinct control plane elements. >>> >>> o It MUST be possible to identify and provision these elements >>> independently, in order to reorganize the control plane >> components >>> without impacting the data plane services and vice-versa. >>> >>> Architecturally distinct elements in a control plane include: > nodes >>> and links, control plane functional components, protocol >> controllers, >>> etc. >>> >>> o An MPLS-TP control plane SHOULD provide a common control >> mechanism >>> for architecturally similar operations. >>> >>> o An MPLS-TP control plane MUST support mechanisms for >> partitioning >>> the network under control into separate peer or hierarchical >>> control domains. >>> >>> o To enable the deployment of a unified control plane aimed at >>> controlling the set of transport technologies used in a >> transport >>> network, the MPLS-TP control plane MUST also be applicable to >>> other transport layer networks and provide common operations >>> across multiple layers. In order to maintain independence >> between >>> MPLS-TP and its respective client and server layer network >>> separate control plane instances SHOULD be used to control a > set >>> of transport layer networks. >>> >>> >>> >>> >>> >>> Niven-Jenkins, et al. Expires January 2, 2009 [Page >> 10] >>> >>> Internet-Draft MPLS-TP Requirements July >> 2008 >>> >>> >>> o MPLS-TP SHOULD detect and recover from control plane failures >> and >>> degradations using graceful operations. >>> >>> 2.5. Network Management (NM) requirements >>> >>> o MPLS-TP MUST operate under a common operation, control and >>> management paradigm with respect to other transport > technologies >>> (e.g. SDH, OTN or WDM). >>> >>> o An MPLS-TP network MUST be able to be operated with a >> centralized >>> NMS system. >>> >>> o An MPLS-TP network SHOULD be able to be operated by a >> centralized >>> NMS system with the support of a distributed control plane. >>> >>> TOM: I don't know what this means or the one above it, or how this >>> requirement would translate into anything tangible in the MPLS-TP >>> protocol designs. I suggest it be removed. >>> >>> o The MPLS-TP management plane MUST NOT depend on a specific >> client >>> layer management plane. >>> >>> TOM: This is a non-sequitur if you ask me; please strike it. >>> >>> o The MPLS-TP management plane MUST support the configuration and >>> modification of OAM maintenance points as well as the >> activation/ >>> deactivation of OAM when the connection is established or >>> modified. >>> >>> For the complete set of requirements related to NM functionality >> for >>> MPLS-TP, see the MPLS-TP NM requirements document [REF]. >>> >>> 2.6. OAM requirements >>> >>> o MPLS-TP SHOULD provide a comprehensive set of capabilities > (that >>> are independent of and agnostic to the transmitted client >>> services) to support fault management, performance monitoring >> (of >>> the MPLS-TP network and the services), protection switching, >> fault >>> localization, signal quality measurement, etc. >>> >>> o A mechanism SHOULD be supported to detect, diagnose and enable >>> recovery from facility and equipment failures and performance >>> degradations according to the requirements of the service. >>> >>> o MPLS-TP OAM MUST be able to operate without IP functionality > and >>> without relying on control and/or management planes. >>> >>> For the complete set of requirements related to OAM functionality >> for >>> MPLS-TP, see the MPLS-TP OAM requirements document [REF]. >>> >>> TOM: I suggest you just remove these two sections and refer to the >>> OAM/Managemetn documents. >>> >>> 2.7. Network performance management (PM) requirements >>> >>> >>> >>> >>> >>> >>> Niven-Jenkins, et al. Expires January 2, 2009 [Page >> 11] >>> >>> Internet-Draft MPLS-TP Requirements July >> 2008 >>> >>> >>> o MPLS-TP MUST support traffic-engineering capabilities with >>> traffic- and/or resource-oriented performance objectives. >>> >>> TOM: What are performance objectives? Do you mean traffic profiles >>> such as QoS/bandwidth? >>> >>> o MPLS-TP MUST support a method to offer packet loss objectives >>> comparable to those in TDM transport networks (only due to bit >>> errors). >>> >>> For the complete set of requirements related to PM functionality >> for >>> MPLS-TP, see the MPLS-TP OAM requirements document [REF]. >>> >>> TOM: Again, I suggest you punt on this entire section and move it to >>> the OAM doc. >>> >>> 2.8. Protection & Survivability requirements >>> >>> Network survivability plays a critical factor in the delivery of >>> reliable services. Network availability is a significant >> contributor >>> to revenue and profit. Service guarantees in the form of SLAs >>> require a resilient network that rapidly detects facility or node >>> failures and restores network operation in accordance with the >> terms >>> of the SLA. >>> >>> The requirements in this section use of the recovery terminology >>> defined in RFC 4427[RFC4427]. >>> >>> o MPLS-TP SHOULD support transport network style protection >>> >>> TOM: I would make this a MUST. >>> >>> switching mechanisms (tandem network connection protection, LSP >>> protection and PW protection) to provide the sub-50ms recovery >>> time required to maintain customer transparency, even when >>> thousands of services are simultaneously affected by a failure. >>> [Is sub-50ms really a requirement, do we want to clarify this >>> further - is it sub-50ms end to end, or per link?] >>> >>> o >>> >>> * MPLS-TP recovery mechanisms SHOULD be applicable at various >>> levels throughout the network, SPAN, tandem connection and >> end- >>> to-end. >>> >>> TOM: This sentence doesn't parse. Please re-write. >>> >>> Any recovery mechanism used in a tandem connection >>> MUST be independent of other tandem connections. >>> >>> * MPLS-TP SHOULD support mechanisms that keep traffic flowing >>> while the network recovers from failures. >>> >>> TOM: I would say this is a MUST. >>> >>> * MPLS-TP SHOULD support network restoration mechanisms >>> controlled by a distributed control plane and/or by a >>> management plane based. >>> >>> TOM: I would say this is a MUST. >>> >>> >>> * >>> >>> + The restoration resources MAY be pre-planned and selected >> a >>> priori, or computed after failure occurrence. >>> >>> >>> >>> Niven-Jenkins, et al. Expires January 2, 2009 [Page >> 12] >>> >>> Internet-Draft MPLS-TP Requirements July >> 2008 >>> >>> >>> + MPLS-TP MAY support shared-mesh restoration. >>> >>> + MPLS-TP SHOUD support soft LSP restoration. >>> >>> + MPLS-TP MAY support hard LSP restoration. >>> >>> + The restoration mechanism MUST be applicable to any >>> topology. >>> >>> + Restoration priority MAY be implemented to determine the >>> order in which connections should be restored (to > minimize >>> service restoration time as well as to gain access to >>> available spare capacity on the best paths). Preemption >>> priority MAY be used in the event that not all > connections >>> can be restored, in which case connections with lower >>> preemption priority should be released. >>> >>> + The restoration mechanism SHOULD operate in synergy with >>> other transport network technologies (SDH, OTN, WDM). >>> >>> * MPLS-TP SHOULD support data plane driven protection >> mechanisms >>> (without any dependency on a control plane or IP protocols) >> to >>> enable fast recovery from failure, and thereby to enhance > the >>> reliability and availability performance of MPLS-TP > networks. >>> >>> * >>> >>> + MPLS-TP protection mechanisms SHOULD be applied to LSPs >> and >>> PWs. >>> >>> + MPLS-TP MUST support mechanisms that rapidly detect, >> locate, >>> notify and remedy network faults. >>> >>> + MPLS-TP MUST support 1:1 bidirectional protection >> switching. >>> The protection state of both ends of the protected entity >>> MUST be synchronized. >>> >>> + MPLS-TP MAY support 1+1 unidirectional protection >> switching. >>> >>> + MPLS-TP protection mechanisms MUST be applicable to both >>> point-to-point and point-to-multipoint connections. >>> >>> + It SHOULD be possible to achieve protection at the > MPLS-TP >>> layer as fast as possible (subject to the temporal >>> resolution of the defect detection mechanism). >>> >>> + Protection ratio MUST be of 100%, i.e., 100% of impaired >>> working traffic MUST be protected for a failure on a >>> single >>> >>> >>> >>> Niven-Jenkins, et al. Expires January 2, 2009 [Page >> 13] >>> >>> Internet-Draft MPLS-TP Requirements July >> 2008 >>> >>> >>> working LSP. >>> >>> + Operator requests for manual control of protection >> switching >>> such as clear, lockout of protection, forced-switch and >>> manual-switch commands MUST be supported. Prioritized >>> protection between Signal Fail (SF), Signal Degradation >> (SD) >>> and operator switch requests MUST be supported. >>> >>> + MPLS-TP protection mechanisms MUST support revertive and >>> non-revertive behaviour. o An extra traffic capability >>> SHOULD be supported when possible. >>> >>> + MPLS-TP protection switching mechanisms MUST prevent >>> frequent operation of the protection switch due to an >>> intermittent defect. >>> >>> + MPLS-TP protection mechanisms MUST ensure co-ordination > of >>> timing of protection switches at multiple layers to avoid >>> races and to allow the protection switching mechanism of >> the >>> server layer to fix the problem before switching at the >>> MPLS-TP layer. >>> >>> + MPLS-TP MAY support mechanisms that are optimized for >>> specific network topologies (Ring, Mesh) in order to >> handle >>> protection switching in a cost-efficient manner. >>> >>> 2.9. QoS requirements >>> >>> Service providers require advanced traffic management capabilities >> to >>> enforce and guarantee the QoS parameters of customers' SLAs. >>> >>> Quality of service mechanisms are required to ensure: >>> >>> o Support for differentiated services and different traffic types >>> with traffic class separation associated with different > traffic. >>> >>> o Prioritization of critical services. >>> >>> o Enabling the provisioning and the guarantee of Service Level >>> Specifications (SLS), with support for hard and relative > end-to- >>> end BW guaranteed. >>> >>> o Controlled jitter and delay. >>> >>> o Guarantee of fair access to shared resources in an MPLS-TP >>> network. >>> >>> >>> >>> >>> >>> Niven-Jenkins, et al. Expires January 2, 2009 [Page >> 14] >>> >>> Internet-Draft MPLS-TP Requirements July >> 2008 >>> >>> >>> o Ability for OAM and data to share the same fate. >>> >>> TOM: This belongs in the OAM document. >>> >>> >>> o Resources for control and management plane packets so that user >>> plane traffic, regardless of the amount, will not cause control >>> and management functions to become inoperative. >>> >>> The following QoS requirements apply to MPLS-TP: >>> >>> o MPLS-TP MUST be able to deliver the same degree of QoS that has >>> been delivered by SDH/SONET systems. >>> >>> TOM: We can save on a lot of text and remove the "MPLS-TE MUST" or >>> "MPLS-TP SHOULD" bits and simply say "MUST X" or "SHOULD Y". The >>> MPLS-TP bit is implicit I think. >>> >>> o MPLS-TP MUST support transport bandwidth allocation to any >>> granularity without any restrictions based on a > circuit-switched >>> multiplexing hierarchy. This attribute will provide service >>> providers with the capability to route more customer service >>> demands over the MPLS-TP network. >>> >>> [Should we refer here to the requirements specified in RFC 2702?] >>> >>> 2.10. Security requirements >>> >>> o MPLS-TP MUST ensure that the network and services are secured. >>> >>> o Traffic flows from different users MUST NOT be intermingled, > but >>> if this does occur then this MUST be detectable and the >>> appropriate consequent actions taken. >>> >>> o MPLS-TP MUST ensure the separation of customer (client) and >>> provider (server and peer network) addressing and other >>> information. >>> >>> TOM: This requirement is stated above. >>> >>> o MPLS-TP MUST ensure that the control and management planes as >> well >>> as OAM traffic are secure from external attack. >>> >>> o MPLS-TP MUST provide mechanisms to ensure that the MPLS-TP >> network >>> remains secure and stable under situations of extreme stress. >>> >>> Examples of attacks and situations of extreme stress include (but >> are >>> not limited to) classical security attacks (e.g., hijacking, >> privacy, >>> non-repudiation, etc.) and attacks on network availability (e.g., >>> denial of service (DoS) attacks). >>> >>> >>> 3. IANA Considerations >>> >>> This document makes no request of IANA. >>> >>> Note to RFC Editor: this section may be removed on publication as >>> an >>> >>> >>> >>> Niven-Jenkins, et al. Expires January 2, 2009 [Page >> 15] >>> >>> Internet-Draft MPLS-TP Requirements July >> 2008 >>> >>> >>> RFC. >>> >>> >>> 4. Security Considerations >>> >>> This document does not by itself raise any particular security >>> considerations. >>> >>> >>> 5. Acknowledgements >>> >>> The authors wish to thank Neil Harrison and Tomonori Takeda for >> their >>> review and enhancements to the text. >>> >>> >>> 6. Informative References >>> >>> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate >>> Requirement Levels", BCP 14, RFC 2119, March 1997. >>> >>> [RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection >> and >>> Restoration) Terminology for Generalized Multi-Protocol >>> Label Switching (GMPLS)", RFC 4427, March 2006. >>> >>> [ITU.Y1401.2008] >>> International Telecommunications Union, "Principles of >>> interworking", ITU-T Recommendation Y.1401, February >> 2008. >>> >>> >>> Authors' Addresses >>> >>> Ben Niven-Jenkins (editor) >>> BT >>> 208 Callisto House, Adastral Park >>> Ipswich, Suffolk IP5 3RE >>> UK >>> >>> Email: benjamin.niven-jenkins@bt.com >>> >>> >>> Deborah Brungard (editor) >>> AT&T >>> Rm. D1-3C22 - 200 S. Laurel Ave. >>> Middletown, NJ 07748 >>> USA >>> >>> Email: dbrungard@att.com >>> >>> >>> >>> >>> Niven-Jenkins, et al. Expires January 2, 2009 [Page >> 16] >>> >>> Internet-Draft MPLS-TP Requirements July >> 2008 >>> >>> >>> Malcolm Betts (editor) >>> Nortel Networks >>> 3500 Carling Avenue >>> Ottawa, Ontario K2H 8E9 >>> Canada >>> >>> Email: betts01@nortel.com >>> >>> >>> Nurit Sprecher >>> Nokia Siemens Networks >>> 3 Hanagar St. Neve Ne'eman B >>> Hod Hasharon, 45241 >>> Israel >>> >>> Email: nurit.sprecher@nsn.com >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Niven-Jenkins, et al. Expires January 2, 2009 [Page >> 17] >>> >>> Internet-Draft MPLS-TP Requirements July >> 2008 >>> >>> >>> Full Copyright Statement >>> >>> Copyright (C) The IETF Trust (2008). >>> >>> 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, THE IETF TRUST >> 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. >>> >>> >>> Intellectual Property >>> >>> 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. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Niven-Jenkins, et al. Expires January 2, 2009 [Page >> 18] >>> >>> >>> >>> _______________________________________________ >>> Mpls-interop mailing list >>> Mpls-interop@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls-interop >> > _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop From mpls-interop-bounces@ietf.org Mon Jun 23 18:24:57 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2231A3A67A7; Mon, 23 Jun 2008 18:24:57 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F0BA3A67B2 for ; Mon, 23 Jun 2008 18:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0GFq3noBKguS for ; Mon, 23 Jun 2008 18:24:54 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id 68CFE3A67A7 for ; Mon, 23 Jun 2008 18:24:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 2C7FB3B942B for ; Mon, 23 Jun 2008 18:24:55 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09892-04 for ; Mon, 23 Jun 2008 18:24:55 -0700 (PDT) Received: from rbsjx.ad.redback.com (rbsjxh2.redback.com [155.53.14.106]) by prattle.redback.com (Postfix) with ESMTP id 110AF3B942A for ; Mon, 23 Jun 2008 18:24:55 -0700 (PDT) Received: from RBSJX.ad.redback.com ([155.53.14.103]) by rbsjxh2.ad.redback.com ([155.53.14.106]) with mapi; Mon, 23 Jun 2008 18:24:55 -0700 From: David Sinicrope To: "mpls-interop@ietf.org" Date: Mon, 23 Jun 2008 18:25:19 -0700 Thread-Topic: [Mpls-interop] next MEAD team meeting Thread-Index: AcjSHV+baA3PhWi8SNuu8g8aFnYZOwALczVAAAAmMSAA01LM8A== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at redback.com Subject: Re: [Mpls-interop] next MEAD team meeting X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org Nevermind, we rearranged the agenda so that Matthew, Andy and I can attend this call. Thanks, David -----Original Message----- From: David Sinicrope Sent: Thursday, June 19, 2008 4:34 PM To: 'mpls-interop@ietf.org' Subject: RE: [Mpls-interop] next MEAD team meeting Hi All, I'll be chairing a WG meeting at the IP/MPLS Forum in Vancouver at the same time as the call. Could I impose on a volunteer to take notes for this call? Thanks, David -----Original Message----- From: mpls-interop-bounces@ietf.org [mailto:mpls-interop-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Thursday, June 19, 2008 11:00 AM To: MEAD team Subject: [Mpls-interop] next MEAD team meeting All, the MEAD team will have the next meeting on Tuesday 24, at 6pm i.e. 12am east coast and 9am California. Again I plan the meeting to last an hour, and focus will be on the document status. Stewart will send out dial in details as usual. /Loa -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.nu _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop From mpls-interop-bounces@ietf.org Tue Jun 24 01:06:21 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB2FB3A68EB; Tue, 24 Jun 2008 01:06:21 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8E1F3A69AA for ; Tue, 24 Jun 2008 01:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gsx+eh6mX4mg for ; Tue, 24 Jun 2008 01:06:15 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id BC7843A68EB for ; Tue, 24 Jun 2008 01:06:14 -0700 (PDT) Received: from E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.109]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jun 2008 09:06:12 +0100 Received: from 10.215.40.109 ([10.215.40.109]) by E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.60]) via Exchange Front-End Server mail.bt.com ([193.113.197.32]) with Microsoft Exchange Server HTTP-DAV ; Tue, 24 Jun 2008 08:06:11 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Tue, 24 Jun 2008 09:06:09 +0100 From: Ben Niven-Jenkins To: Thomas Nadeau , Loa Andersson , MEAD team Message-ID: Thread-Topic: [Mpls-interop] next MEAD team meeting Thread-Index: AcjSMNQsx4BuurjX8EeQxIcfmO8exAA0/R+VALMYC8w= In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 24 Jun 2008 08:06:12.0916 (UTC) FILETIME=[2B2AB740:01C8D5D1] Subject: Re: [Mpls-interop] next MEAD team meeting X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org More responses...I will also go through the document and replace "connection/trunk/pipe" with "transport path" and replace "user/forwarding plane" with "data plane". Ben On 20/06/2008 19:38, "Thomas Nadeau" wrote: > MPLS is a maturing packet technology and it is already playing an > > > > Niven-Jenkins, et al. Expires January 2, 2009 [Page 4] > > Internet-Draft MPLS-TP Requirements July 2008 > > > important role in transport networks and services. However, not all > of MPLS's capabilities and mechnisms are needed and/or consistent > with transport network operations. This document identifies the > required capabilities for MPLS so that it can better fit a transport > role. > > TOM: I think you want to say "identifies the required sub-set of > capabilities..." and later "potentially new ons specific for transport > networks" which it seems you say two paragraphs later. I combined this para with the one two paragraphs later & did some editing to come up with " MPLS is a maturing packet technology and it is already playing an important role in transport networks and services. However, not all of MPLS's capabilities and mechanisms are needed and/or consistent with transport network operations. MPLS-TP needs to combine the necessary existing capabilities of MPLS with additional minimal mechanisms in order that it can be used in a transport role." > Combining the packet experience of MPLS with the operational > experience of SONET/SDH constitutes a packet transport technology > named MPLS-TP. MPLS-TP will enable the migration of SONET/SDH > networks to a packet-based network that will easily scale to support > packet services in a simple and cost effective way. > > MPLS-TP needs to combine the necessary existing capabilities of MPLS > with additional minimal mechanisms in order to meet the requirements > described in this document. > > The requirements of an MPLS transport profile are provided below. > > TOM: There is a terminology issue in the use of "MPLS-TP" or "an MPLS > transport profile". That is, on the one hand you refer to a technology, but > on the other hand you are referring to a specific profile. Which is it? Changed to MPLS-TP > o Mechanisms and capabilities MUST be able to interoperate with > existing MPLS and PWE control and data planes where appropriate. > > TOM: Change PWE to "IETF PWE3" and "MPLS" to "IETF MPLS". There also need to > be references here to the PWE3 architecture and MPLS architectures. Done. I have referenced RFC3031 & RFC3985, should I reference any others? > o MPLS-TP MUST support point to point (P2P) or point to multipoint > (P2MP) connections. > > TOM: Are we avoiding MP2MP consciously or was it left out? We are consciously avoiding MP2MP, one of the attributes of a connection is that it has a single source. MP2MP is not a feature of transport networks. > o MPLS-TP connections MAY be able to be provisioned dynamically via > a control plane. > > TOM: I insist that we change the MAY above to MUST. I want a dynamic version > of this as much as a static one. Done. I have also added the para below to the introduction to try and clarify the position we agreed over the weekend. " Although both static and dynamic configuration of MPLS-TP transport paths (including OAM) is required by this document, it MUST be possible for operators to be able to completely operate (including OAM) an MPLS-TP network in the absence of any control plane or dynamic protocols. " > TOM: I think it is imperative that although an MPLS-TP is defined to play > nicely with an MPLS one, it is imperative that one can distinguish between > both, at least at the control plane, but perhaps at the data plane as well. Can you suggest some wording for those requirements? > > 2.2. Layering requirements > > o An MPLS-TP network MUST operate in a multiple layer network > environment consisting of the following independent layers: > > 1. A "service layer" instance in which the connections carry the > customer's (individual or bundled) service (may be point-to- > point, point-to-multipoint or multipoint-to-multipoint > services); > > 2. A "trunk layer" with point-to-point or point-to-multipoint > connections which are used to carry aggregates of the network > "service layer" connections; and > > 3. A "transmission media layer" which provides sections (two-port > point-to-point connections) to carry the aggregate of network > trunk or network service connections on various physical > media. > > TOM: This stuff belongs in the Terminology section at the top. Reworded to " An MPLS-TP network MUST operate in a multiple layer network environment consisting of independent service, transport path and transmission media layers. " and moved the 3 bullets of definition to a terminology section. > o The forward and backward directions of a bi-directional connection > SHOULD follow the same path within the MPLS-TP network. > > TOM: I am not sure if we say that they SHOULD as much as "they MUST be > capable of". Done. Nurit - to address your comment that we should not restrict bi-directional connections to using the same path, I don't believe changing this to a "MUST be capable of" makes that restriction. It states that equipment MUST have the capability but it does not state that they must always use that capability (e.g. We could say a piece of equipment MUST support QoS marking but that does not mean it has to apply QoS markings to all connections) > o The intermediate nodes SHOULD be aware about the binding of the > forward and the backward directions belonging to the same bi- > directional connection. > > TOM: Again, "SHOULD be capable of" seems better. I can't find a way to put SHOULD be capable of in this requirement and still parse it. The intent of the requirement is that when a bi-directional connection traverses an intermediate node, that intermediate node should have knowledge that both directions belong to the same connection and aren't in fact two independent connections running in opposite directions. > o MPLS-TP SHOULD support transport and QoS mechanisms that can > deliver statistical multiplexing gain. Packets exceeding the > agreed traffic profile may be marked or discarded by the traffic > conditioning at the ingress of the MPLS-TP network. > > TOM: How about egress policing + marking? I guess this depends how you think about it. If you think of a connection as a regular water pipe then you can restrict the amount water that you can put in the pipe by restricting the diameter of the pipe. You can't however restrict what comes out of the other end of the pipe. IF we think egress policing & marking is important for connections I can add it in but I am not convinced that it is as I believe in a transport network policing is done on ingress and the egress just "spits" out what it gets. It is then the next transport connection (or a higher layer) that does policing of what comes out on ingress to that connection/layer. > o MPLS-TP MUST be able to accommodate new traffic types. > > TOM: New traffic types other than those supported by MPLS? This doesn't make > sense to me as this will result in MPLS-TP not being a subset of MPLS. Two things: 1) MPLS-TP is a subset + minimal necessary additional capabilities 2) If MPLS evolves to support a new traffic type and MPLS-TP automatically inherits that capability too as a result of being derived from MPLS then this requirement is met. > o If a control plane is used for configuration of MPLS-TP > connections then: > > * Failure and recovery of the control plane MUST NOT impact the > MPLS-TP forwarding plane. > > TOM: This is difficult, as this really is handled in practice at both data > and control planes, depending on how this is configured/designed, and the > re-signaling can impact the data plane. I think this is sort of hinting at NSR type functionality - e.g. Just because your control plane has failed does not mean that your data plane should also go down. However as you state recovery of the control plane may have some impact on the data plane so I've split it into two requirements as follows (comments welcome): " Failure of the control plane MUST NOT impact the MPLS-TP forwarding plane. And Recovery of the control plane MUST NOT impact the MPLS-TP forwarding plane any more than is necessary to re-establish the control plane." > o The MPLS-TP control plane MUST support fast restoration. > > TOM: Define what "fast" means? I'm not convinced that including arbitrary numbers is overly useful. I guess the intent is that MPLS-TP needs to support mechanisms that are faster than say IGP re-convergence. Maybe we can reword the requirement to make it more useful without including specific numbers. Any suggestions for text welcomed. > o An MPLS-TP control plane MUST scale gracefully to support a large > number of connections. > > TOM: Define "large" and "scale" here? Again I don't think arbitrary numbers are particularly useful (it is analogous to saying 640K is all the memory a PC will ever need). The intent is that MPLS-TP should not be "set in stone" but capable of scaling in the future to accommodate numbers of connections that may not be possible today. > o An MPLS-TP control plane MUST clearly distinguish resources > belonging to the MPLS-TP layer network from those in other layer > networks that may also be under control plane control. > > TOM: Do you mean under the same control plane or a different one (or both)? I don't know TBH - what do the others think? > o An MPLS-TP network MUST be able to be operated with a centralized > NMS system. > > o An MPLS-TP network SHOULD be able to be operated by a centralized > NMS system with the support of a distributed control plane. > > TOM: I don't know what this means or the one above it, or how this > requirement would translate into anything tangible in the MPLS-TP protocol > designs. I suggest it be removed. This requirements means that it must be possible to use both control & management planes to operate an MPLS-TP network. An example of this would be that the network is provisioned using only the management plane, but under failure it uses control plane driven recovery/restoration mechanisms giving the operator the advantage that they do not need to deploy capacity to protect every path in their network in case of a failure. The requirement above it is basically saying MPLS-TP must be able to be operated in a static mode. > o The MPLS-TP management plane MUST NOT depend on a specific client > layer management plane. > > TOM: This is a non-sequitur if you ask me; please strike it. This is stating that the MPLS-TP management plane must be independent from client management planes (in the same way the MPLS-TP data & control planes must be independent from client data & control planes). I have reworded it along those lines to " The MPLS-TP management plane MUST be independent of any particular client or server layer management plane." > 2.6. OAM requirements > > o MPLS-TP SHOULD provide a comprehensive set of capabilities (that > are independent of and agnostic to the transmitted client > services) to support fault management, performance monitoring (of > the MPLS-TP network and the services), protection switching, fault > localization, signal quality measurement, etc. > > o A mechanism SHOULD be supported to detect, diagnose and enable > recovery from facility and equipment failures and performance > degradations according to the requirements of the service. > > o MPLS-TP OAM MUST be able to operate without IP functionality and > without relying on control and/or management planes. > > For the complete set of requirements related to OAM functionality for > MPLS-TP, see the MPLS-TP OAM requirements document [REF]. > > TOM: I suggest you just remove these two sections and refer to the > OAM/Managemetn documents. OK. I haven't seen either of those documents & the outline requirements above are important so I suggest we leave them as-is for the first draft and when we have all the requirements documents side by side we can incorprate the above into the OAM & NM documents. > 2.7. Network performance management (PM) requirements > > o MPLS-TP MUST support traffic-engineering capabilities with > traffic- and/or resource-oriented performance objectives. > > TOM: What are performance objectives? Do you mean traffic profiles such as > QoS/bandwidth? I'll have to refer this to the ITU folks. > > o MPLS-TP MUST support a method to offer packet loss objectives > comparable to those in TDM transport networks (only due to bit > errors). > > For the complete set of requirements related to PM functionality for > MPLS-TP, see the MPLS-TP OAM requirements document [REF]. > > TOM: Again, I suggest you punt on this entire section and move it to the OAM > doc. See my suggestion above. > 2.8. Protection & Survivability requirements > > Network survivability plays a critical factor in the delivery of > reliable services. Network availability is a significant contributor > to revenue and profit. Service guarantees in the form of SLAs > require a resilient network that rapidly detects facility or node > failures and restores network operation in accordance with the terms > of the SLA. > > The requirements in this section use of the recovery terminology > defined in RFC 4427[RFC4427]. > > o MPLS-TP SHOULD support transport network style protection > > TOM: I would make this a MUST. Done. > > * MPLS-TP recovery mechanisms SHOULD be applicable at various > levels throughout the network, SPAN, tandem connection and end- > to-end. > > TOM: This sentence doesn't parse. Please re-write. I've changed it to " MPLS-TP recovery mechanisms SHOULD be applicable at various levels throughout the network including support for span, tandem connection and end-to-end recovery." which I hope makes more sense. I've also added Nurit's definitiosn of span & tandem connection to the terminology section. > * MPLS-TP SHOULD support mechanisms that keep traffic flowing > while the network recovers from failures. > > TOM: I would say this is a MUST. Done. > * MPLS-TP SHOULD support network restoration mechanisms > controlled by a distributed control plane and/or by a > management plane based. > > TOM: I would say this is a MUST. Done. I also split it out into two requirements - one for management plane & one for control plane. > o Ability for OAM and data to share the same fate. > > TOM: This belongs in the OAM document. See suggestion above. > The following QoS requirements apply to MPLS-TP: > > o MPLS-TP MUST be able to deliver the same degree of QoS that has > been delivered by SDH/SONET systems. > > TOM: We can save on a lot of text and remove the "MPLS-TE MUST" or "MPLS-TP > SHOULD" bits and simply say "MUST X" or "SHOULD Y". The MPLS-TP bit is > implicit I think. Done. > o Traffic flows from different users MUST NOT be intermingled, but > if this does occur then this MUST be detectable and the > appropriate consequent actions taken. > > o MPLS-TP MUST ensure the separation of customer (client) and > provider (server and peer network) addressing and other > information. > > TOM: This requirement is stated above. I don't believe it is. The first is saying that data flows must not be intermingled. The second is saying that addresses must be independent. _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop From mpls-interop-bounces@ietf.org Tue Jun 24 01:30:06 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 333163A6768; Tue, 24 Jun 2008 01:30:06 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2617B3A689F for ; Tue, 24 Jun 2008 01:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJsqsJ+RJQ3k for ; Tue, 24 Jun 2008 01:30:03 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 479D03A6768 for ; Tue, 24 Jun 2008 01:30:02 -0700 (PDT) Received: from E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.109]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jun 2008 09:30:03 +0100 Received: from 10.215.40.109 ([10.215.40.109]) by E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.60]) via Exchange Front-End Server mail.bt.com ([193.113.197.32]) with Microsoft Exchange Server HTTP-DAV ; Tue, 24 Jun 2008 08:30:01 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Tue, 24 Jun 2008 09:30:00 +0100 From: Ben Niven-Jenkins To: Italo Busi , 'Loa Andersson' , "'BRUNGARD, DEBORAH A, ATTLABS'" Message-ID: Thread-Topic: [Mpls-interop] MPLS-TP Requirements Abstract (was RE: next MEAD team meeting) Thread-Index: AcjS+oxykpiCiEFrSKaGeg3ms5bIkgCEBNYgADJ3f0I= In-Reply-To: <00ed01c8d50c$7ec172b0$4c476297@vim.tlt.alcatel.it> Mime-version: 1.0 X-OriginalArrivalTime: 24 Jun 2008 08:30:03.0418 (UTC) FILETIME=[7FCFFFA0:01C8D5D4] Cc: 'MEAD team' Subject: Re: [Mpls-interop] MPLS-TP Requirements Abstract (was RE: next MEAD team meeting) X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org I don't like this. I'm not clear why ITU-T has to be the only organisation drawn out as the source of the requirements and I don't like the idea of having to somehow identify/tag all requirements that are not from the ITU-T as I believe this to be an unnecessary editorial overhead which will only get worse as the document evolves. How about this? " This document specifies the requirements for an MPLS Transport Profile (MPLS-TP) in order to support the capabilities and functionalities needed for packet transport network services and packet transport network operations. These requirements are a combination of those derived from the set of requirements specified by ITU-T and requirements received directly from Service Providers. This document is a product of a joint ITU-IETF effort. " Ben On 23/06/2008 09:38, "Italo Busi" wrote: > If I understand properly the arguments in this discussion, it seems quite > important to clarify in the scope that these requirements are SP requirements > as > well as the fact that the source of most of them (if not all) is ITU-T. > > What about the following abstract? > > " > This document specifies the requirements for an MPLS Transport Profile > (MPLS-TP) > in order to support capabilities and functionalities as needed for packet > transport network services and network operations. > > Unless explicitly mentioned, these requirements are derived from the set of > requirements specified by ITU-T. > > This document is a product of a joint ITU-IETF effort. > " > > Thanks, Italo > >> -----Original Message----- >> From: mpls-interop-bounces@ietf.org >> [mailto:mpls-interop-bounces@ietf.org] On Behalf Of Loa Andersson >> Sent: Friday, June 20, 2008 7:25 PM >> To: BRUNGARD, DEBORAH A, ATTLABS >> Cc: MEAD team >> Subject: Re: [Mpls-interop] next MEAD team meeting >> >> >> >> BRUNGARD, DEBORAH A, ATTLABS wrote: >>> Hi, >>> >>> Thanks Loa for the hint. My understanding of the charter >> was to capture >>> the ITU requirements? >> >> yes - that is true... >> >> but we also need to capture all requirements for the MPLS-TP whether >> they are in the captured by the ITU-T or not. >>> >>> What is the MEAD development work covering - both ITU >> requirements and >>> "other (anonymous) SPs requirements"? >> >> if there is "only" requirements that originates from ITU-T this is >> not a problem. I am not looking for anonymous requirements, if there >> is a requirement that is not from ITU-T we should make clear where it >> came form >> >> /Loa >>> >>> Deborah >>> >>> >>> -----Original Message----- >>> From: Sprecher, Nurit (NSN - IL/Israel - MiniMD) >>> [mailto:nurit.sprecher@nsn.com] >>> Sent: Friday, June 20, 2008 5:23 AM >>> To: ext Loa Andersson >>> Cc: BRUNGARD, DEBORAH A, ATTLABS; MEAD team; Sprecher, Nurit (NSN - >>> IL/Israel - MiniMD) >>> Subject: RE: [Mpls-interop] next MEAD team meeting >>> >>> Hi, >>> 1. I agree that validates may be a good option. >>> 2. IMO, these requirements are not only the ITU-T view. I got these >>> requirements from different SPs. As I indicated in the >> beginning of the >>> mail exchanges I would prefer to say: "This document specifies the >>> requirements for MPLS-TP in order to support capabilities and >>> functionalities as needed in transport environments (or >> networks)." But >>> this is something that we need the SPs to agree on. >>> Please note also that in the proposal just below I forgot >> to include the >>> indication that this is a joint work of ITU-T and IETF. >>> Best regards, >>> Nurit >>> >>> >>> -----Original Message----- >>> From: ext Loa Andersson [mailto:loa@pi.nu] >>> Sent: Friday, June 20, 2008 11:57 >>> To: Sprecher, Nurit (NSN - IL/Israel - MiniMD) >>> Cc: ext BRUNGARD, DEBORAH A, ATTLABS; MEAD team >>> Subject: Re: [Mpls-interop] next MEAD team meeting >>> >>> All, >>> >>> just a few comments. >>> >>> Sprecher, Nurit (NSN - IL/Israel - MiniMD) wrote: >>>> Hi Deborah, >>>> I understand the intention, so how about the following (as we also >>>> indicated in the introduction): >>>> This document specifies >>> >>> I wonder if "specifies" is the right word - one way would be to say >>> "validates" indicating that this how we (IETF) understands these >>> requirements >>> >>> the ITU-T requirements for MPLS-TP in order to >>>> support capabilities and functionalities of MPLS as needed in >>>> transport environments. >>> >>> this indicates that there is nothing but ITU-T requirements in the >>> document, is that true? >>> >>> /Loa >>> >>>> MPLS is a maturing packet technology and it is already playing an >>>> important role in transport networks and services. >> However, not all of >>> >>>> MPLS's capabilities and mechnisms are needed and/or >> consistent with >>>> transport network operations. This document identifies the >> required >>>> capabilities for MPLS so that it can better fit a transport role. >>> >>>> Please advise. >>>> Best regards, >>>> Nurit >>>> >>>> ________________________________ >>>> >>>> From: ext BRUNGARD, DEBORAH A, ATTLABS [mailto:dbrungard@att.com] >>>> Sent: Thursday, June 19, 2008 23:04 >>>> To: Sprecher, Nurit (NSN - IL/Israel - MiniMD); MEAD team >>>> Subject: RE: [Mpls-interop] next MEAD team meeting >>>> >>>> >>>> Hi Nurit, >>>> >>>> I would prefer to clearly say the requirements are ITU >> requirements >>>> for MPLS in a transport environment. I think among some >> operators the >>>> line between transport equipment and packet equipment has already >>> blurred. >>>> For many operators, the preference may be to align with MPLS >>>> operations vs. transport. I think there are many differing >> opinions on >>> >>>> what MPLS/packet transport needs to support in a transport >>>> environment. So I prefer to clearly say these are ITU >> requirements, >>>> they do not necessarily reflect the operators contributing to this >>> document. >>>> >>>> On the 2nd bullet, the requirements document has many >>>> statements/requirements which may be interpreted by a >> reader as gaps >>>> in MPLS/IETF protocols. I was trying to say with this sentence the >>>> document is not addressing/identifying IETF protocol >> applicability or >>>> lack of capabilities e.g. the sentence: >>>> "Quality-of-service mechanisms are required in the packet transport >>>> network to ensure the prioritization of critical services, to >>>> guarantee BW and to control jitter and delay." >>>> >>>> QoS is not a new requirement for IETF protocols. Packet transport >>>> networks (and this requirement document) are not the first >> time that >>>> QoS mechanisms are identified as needed. This requirement is not >>>> intending to identify a gap in the current IETF protocol >> set. This was >>> >>>> what I was trying to say. >>>> >>>> Suggestions? >>>> Deborah >>>> >>>> >>>> >>>> ________________________________ >>>> >>>> From: Sprecher, Nurit (NSN - IL/Israel - MiniMD) >>>> [mailto:nurit.sprecher@nsn.com] >>>> Sent: Thursday, June 19, 2008 3:10 PM >>>> To: BRUNGARD, DEBORAH A, ATTLABS; MEAD team >>>> Cc: Sprecher, Nurit (NSN - IL/Israel - MiniMD) >>>> Subject: RE: [Mpls-interop] next MEAD team meeting >>>> >>>> >>>> >>>> Hi Deborah, >>>> >>>> I have a few comments regarding the proposed abstract: >>>> >>>> * I think we should say "This document specifies the >>>> requirements for MPLS-TP in order to support capabilities and >>>> functionalities as needed in transport environments (or networks). >>>> >>>> * I do not understand the sentence: It does not >> address IETF >>>> protocol applicability or capabilities. Do you mean >> applicability or >>>> capability of the current IETF documents? As IMO it will be of the >>>> documents we generate for MPLS-TP. >>>> >>>> * I think it is important to indicate that " This >> document is >>> a >>>> product of a joint ITU-IETF effort". >>>> >>>> Best regards, >>>> >>>> Nurit >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: mpls-interop-bounces@ietf.org >>>> [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext BRUNGARD, >>>> DEBORAH A, ATTLABS >>>> Sent: Thursday, June 19, 2008 21:11 >>>> To: MEAD team >>>> Subject: Re: [Mpls-interop] next MEAD team meeting >>>> >>>> >>>> >>>> Colleagues, >>>> >>>> >>>> >>>> I was thinking for the requirements we should include a >> sentence in >>>> the >>>> >>>> abstract to scope the MPLS-TP work as being part of a >> joint ITU-IETF >>>> >>>> effort. Not all readers (now and future) will be aware of >> why this is >>>> >>>> being done. In ccamp, we had done this for our ASON work. Maybe a >>>> >>>> similar sentence will be needed in the other documents? >> Should we have >>> >>>> a >>>> >>>> common sentence? >>>> >>>> >>>> >>>> How about for the abstract: >>>> >>>> This document summarizes the ITU-T requirements for >> MPLS-TP in order >>>> to >>>> >>>> support capabilities and functionalities as needed by the >> ITU-T. It >>>> does >>>> >>>> not address IETF protocol applicability or capabilities. >> This document >>>> >>>> is a product of a joint ITU-IETF effort. >>>> >>>> >>>> >>>> Deborah >>>> >>>> >>>> >>>> -----Original Message----- >>>> >>>> From: mpls-interop-bounces@ietf.org >>>> >>>> [mailto:mpls-interop-bounces@ietf.org] On Behalf Of Ben >> Niven-Jenkins >>>> >>>> Sent: Thursday, June 19, 2008 1:21 PM >>>> >>>> To: Loa Andersson; MEAD team >>>> >>>> Subject: Re: [Mpls-interop] next MEAD team meeting >>>> >>>> >>>> >>>> Colleagues, >>>> >>>> >>>> >>>> FYI see attached for the latest draft of the MPLS-TP requirements >>> draft. >>>> >>>> >>>> Ben >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 19/06/2008 16:00, "Loa Andersson" wrote: >>>> >>>> >>>> >>>>> All, >>>> >>>>> the MEAD team will have the next meeting on Tuesday 24, at 6pm >>>>> i.e. 12am east coast and 9am California. >>>> >>>>> Again I plan the meeting to last an hour, and focus will be on the >>>>> document status. >>>> >>>>> Stewart will send out dial in details as usual. >>>> >>>>> /Loa >>>> >>>> >>>> _______________________________________________ >>>> >>>> Mpls-interop mailing list >>>> >>>> Mpls-interop@ietf.org >>>> >>>> https://www.ietf.org/mailman/listinfo/mpls-interop >>>> >>>> >>>> >>>> >>>> >> ---------------------------------------------------------------------- >>>> -- >>>> >>>> _______________________________________________ >>>> Mpls-interop mailing list >>>> Mpls-interop@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls-interop >>> >>> >>> -- >>> Loa Andersson >>> >>> Principal Networking Architect >>> Acreo AB phone: +46 8 632 77 14 >>> Isafjordsgatan 22 mobile: +46 739 81 21 64 >>> Kista, Sweden email: loa.andersson@acreo.se >>> loa@pi.nu >> >> >> -- >> Loa Andersson >> >> Principal Networking Architect >> Acreo AB phone: +46 8 632 77 14 >> Isafjordsgatan 22 mobile: +46 739 81 21 64 >> Kista, Sweden email: loa.andersson@acreo.se >> loa@pi.nu >> _______________________________________________ >> Mpls-interop mailing list >> Mpls-interop@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-interop >> > > _______________________________________________ > Mpls-interop mailing list > Mpls-interop@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-interop _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop From mpls-interop-bounces@ietf.org Tue Jun 24 02:17:36 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5FD73A6768; Tue, 24 Jun 2008 02:17:36 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 410663A6845 for ; Tue, 24 Jun 2008 02:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.81 X-Spam-Level: X-Spam-Status: No, score=-2.81 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xJkScOaJVdx for ; Tue, 24 Jun 2008 02:17:33 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id D67B23A6768 for ; Tue, 24 Jun 2008 02:17:32 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m5O8j7bQ018176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Jun 2008 10:45:07 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m5O8j1ON027687; Tue, 24 Jun 2008 10:45:07 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Jun 2008 10:45:06 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Jun 2008 10:45:03 +0200 Message-ID: <9FF5BDAD88B9D84881609E89AC92FB83EBD83B@DEMUEXC014.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mpls-interop] MPLS-TP Requirements Abstract (was RE: next MEAD team meeting) Thread-Index: AcjS+oxykpiCiEFrSKaGeg3ms5bIkgCEBNYgADJ3f0IAAITR4A== From: "Sprecher, Nurit (NSN - IL/Israel - MiniMD)" To: "ext Ben Niven-Jenkins" , "Italo Busi" , "Loa Andersson" , "BRUNGARD, DEBORAH A, ATTLABS" X-OriginalArrivalTime: 24 Jun 2008 08:45:06.0749 (UTC) FILETIME=[9A3D5ED0:01C8D5D6] Cc: MEAD team Subject: Re: [Mpls-interop] MPLS-TP Requirements Abstract (was RE: next MEAD team meeting) X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org Even better. I support this version. -----Original Message----- From: mpls-interop-bounces@ietf.org [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext Ben Niven-Jenkins Sent: Tuesday, June 24, 2008 11:30 To: Italo Busi; 'Loa Andersson'; 'BRUNGARD, DEBORAH A, ATTLABS' Cc: 'MEAD team' Subject: Re: [Mpls-interop] MPLS-TP Requirements Abstract (was RE: next MEAD team meeting) I don't like this. I'm not clear why ITU-T has to be the only organisation drawn out as the source of the requirements and I don't like the idea of having to somehow identify/tag all requirements that are not from the ITU-T as I believe this to be an unnecessary editorial overhead which will only get worse as the document evolves. How about this? " This document specifies the requirements for an MPLS Transport Profile (MPLS-TP) in order to support the capabilities and functionalities needed for packet transport network services and packet transport network operations. These requirements are a combination of those derived from the set of requirements specified by ITU-T and requirements received directly from Service Providers. This document is a product of a joint ITU-IETF effort. " Ben On 23/06/2008 09:38, "Italo Busi" wrote: > If I understand properly the arguments in this discussion, it seems > quite important to clarify in the scope that these requirements are SP > requirements as well as the fact that the source of most of them (if > not all) is ITU-T. > > What about the following abstract? > > " > This document specifies the requirements for an MPLS Transport Profile > (MPLS-TP) > in order to support capabilities and functionalities as needed for > packet transport network services and network operations. > > Unless explicitly mentioned, these requirements are derived from the > set of requirements specified by ITU-T. > > This document is a product of a joint ITU-IETF effort. > " > > Thanks, Italo > >> -----Original Message----- >> From: mpls-interop-bounces@ietf.org >> [mailto:mpls-interop-bounces@ietf.org] On Behalf Of Loa Andersson >> Sent: Friday, June 20, 2008 7:25 PM >> To: BRUNGARD, DEBORAH A, ATTLABS >> Cc: MEAD team >> Subject: Re: [Mpls-interop] next MEAD team meeting >> >> >> >> BRUNGARD, DEBORAH A, ATTLABS wrote: >>> Hi, >>> >>> Thanks Loa for the hint. My understanding of the charter >> was to capture >>> the ITU requirements? >> >> yes - that is true... >> >> but we also need to capture all requirements for the MPLS-TP whether >> they are in the captured by the ITU-T or not. >>> >>> What is the MEAD development work covering - both ITU >> requirements and >>> "other (anonymous) SPs requirements"? >> >> if there is "only" requirements that originates from ITU-T this is >> not a problem. I am not looking for anonymous requirements, if there >> is a requirement that is not from ITU-T we should make clear where it >> came form >> >> /Loa >>> >>> Deborah >>> >>> >>> -----Original Message----- >>> From: Sprecher, Nurit (NSN - IL/Israel - MiniMD) >>> [mailto:nurit.sprecher@nsn.com] >>> Sent: Friday, June 20, 2008 5:23 AM >>> To: ext Loa Andersson >>> Cc: BRUNGARD, DEBORAH A, ATTLABS; MEAD team; Sprecher, Nurit (NSN - >>> IL/Israel - MiniMD) >>> Subject: RE: [Mpls-interop] next MEAD team meeting >>> >>> Hi, >>> 1. I agree that validates may be a good option. >>> 2. IMO, these requirements are not only the ITU-T view. I got these >>> requirements from different SPs. As I indicated in the >> beginning of the >>> mail exchanges I would prefer to say: "This document specifies the >>> requirements for MPLS-TP in order to support capabilities and >>> functionalities as needed in transport environments (or >> networks)." But >>> this is something that we need the SPs to agree on. >>> Please note also that in the proposal just below I forgot >> to include the >>> indication that this is a joint work of ITU-T and IETF. >>> Best regards, >>> Nurit >>> >>> >>> -----Original Message----- >>> From: ext Loa Andersson [mailto:loa@pi.nu] >>> Sent: Friday, June 20, 2008 11:57 >>> To: Sprecher, Nurit (NSN - IL/Israel - MiniMD) >>> Cc: ext BRUNGARD, DEBORAH A, ATTLABS; MEAD team >>> Subject: Re: [Mpls-interop] next MEAD team meeting >>> >>> All, >>> >>> just a few comments. >>> >>> Sprecher, Nurit (NSN - IL/Israel - MiniMD) wrote: >>>> Hi Deborah, >>>> I understand the intention, so how about the following (as we also >>>> indicated in the introduction): >>>> This document specifies >>> >>> I wonder if "specifies" is the right word - one way would be to say >>> "validates" indicating that this how we (IETF) understands these >>> requirements >>> >>> the ITU-T requirements for MPLS-TP in order to >>>> support capabilities and functionalities of MPLS as needed in >>>> transport environments. >>> >>> this indicates that there is nothing but ITU-T requirements in the >>> document, is that true? >>> >>> /Loa >>> >>>> MPLS is a maturing packet technology and it is already playing an >>>> important role in transport networks and services. >> However, not all of >>> >>>> MPLS's capabilities and mechnisms are needed and/or >> consistent with >>>> transport network operations. This document identifies the >> required >>>> capabilities for MPLS so that it can better fit a transport role. >>> >>>> Please advise. >>>> Best regards, >>>> Nurit >>>> >>>> ________________________________ >>>> >>>> From: ext BRUNGARD, DEBORAH A, ATTLABS [mailto:dbrungard@att.com] >>>> Sent: Thursday, June 19, 2008 23:04 >>>> To: Sprecher, Nurit (NSN - IL/Israel - MiniMD); MEAD team >>>> Subject: RE: [Mpls-interop] next MEAD team meeting >>>> >>>> >>>> Hi Nurit, >>>> >>>> I would prefer to clearly say the requirements are ITU >> requirements >>>> for MPLS in a transport environment. I think among some >> operators the >>>> line between transport equipment and packet equipment has already >>> blurred. >>>> For many operators, the preference may be to align with MPLS >>>> operations vs. transport. I think there are many differing >> opinions on >>> >>>> what MPLS/packet transport needs to support in a transport >>>> environment. So I prefer to clearly say these are ITU >> requirements, >>>> they do not necessarily reflect the operators contributing to this >>> document. >>>> >>>> On the 2nd bullet, the requirements document has many >>>> statements/requirements which may be interpreted by a >> reader as gaps >>>> in MPLS/IETF protocols. I was trying to say with this sentence the >>>> document is not addressing/identifying IETF protocol >> applicability or >>>> lack of capabilities e.g. the sentence: >>>> "Quality-of-service mechanisms are required in the packet transport >>>> network to ensure the prioritization of critical services, to >>>> guarantee BW and to control jitter and delay." >>>> >>>> QoS is not a new requirement for IETF protocols. Packet transport >>>> networks (and this requirement document) are not the first >> time that >>>> QoS mechanisms are identified as needed. This requirement is not >>>> intending to identify a gap in the current IETF protocol >> set. This was >>> >>>> what I was trying to say. >>>> >>>> Suggestions? >>>> Deborah >>>> >>>> >>>> >>>> ________________________________ >>>> >>>> From: Sprecher, Nurit (NSN - IL/Israel - MiniMD) >>>> [mailto:nurit.sprecher@nsn.com] >>>> Sent: Thursday, June 19, 2008 3:10 PM >>>> To: BRUNGARD, DEBORAH A, ATTLABS; MEAD team >>>> Cc: Sprecher, Nurit (NSN - IL/Israel - MiniMD) >>>> Subject: RE: [Mpls-interop] next MEAD team meeting >>>> >>>> >>>> >>>> Hi Deborah, >>>> >>>> I have a few comments regarding the proposed abstract: >>>> >>>> * I think we should say "This document specifies the >>>> requirements for MPLS-TP in order to support capabilities and >>>> functionalities as needed in transport environments (or networks). >>>> >>>> * I do not understand the sentence: It does not >> address IETF >>>> protocol applicability or capabilities. Do you mean >> applicability or >>>> capability of the current IETF documents? As IMO it will be of the >>>> documents we generate for MPLS-TP. >>>> >>>> * I think it is important to indicate that " This >> document is >>> a >>>> product of a joint ITU-IETF effort". >>>> >>>> Best regards, >>>> >>>> Nurit >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: mpls-interop-bounces@ietf.org >>>> [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext BRUNGARD, >>>> DEBORAH A, ATTLABS >>>> Sent: Thursday, June 19, 2008 21:11 >>>> To: MEAD team >>>> Subject: Re: [Mpls-interop] next MEAD team meeting >>>> >>>> >>>> >>>> Colleagues, >>>> >>>> >>>> >>>> I was thinking for the requirements we should include a >> sentence in >>>> the >>>> >>>> abstract to scope the MPLS-TP work as being part of a >> joint ITU-IETF >>>> >>>> effort. Not all readers (now and future) will be aware of >> why this is >>>> >>>> being done. In ccamp, we had done this for our ASON work. Maybe a >>>> >>>> similar sentence will be needed in the other documents? >> Should we have >>> >>>> a >>>> >>>> common sentence? >>>> >>>> >>>> >>>> How about for the abstract: >>>> >>>> This document summarizes the ITU-T requirements for >> MPLS-TP in order >>>> to >>>> >>>> support capabilities and functionalities as needed by the >> ITU-T. It >>>> does >>>> >>>> not address IETF protocol applicability or capabilities. >> This document >>>> >>>> is a product of a joint ITU-IETF effort. >>>> >>>> >>>> >>>> Deborah >>>> >>>> >>>> >>>> -----Original Message----- >>>> >>>> From: mpls-interop-bounces@ietf.org >>>> >>>> [mailto:mpls-interop-bounces@ietf.org] On Behalf Of Ben >> Niven-Jenkins >>>> >>>> Sent: Thursday, June 19, 2008 1:21 PM >>>> >>>> To: Loa Andersson; MEAD team >>>> >>>> Subject: Re: [Mpls-interop] next MEAD team meeting >>>> >>>> >>>> >>>> Colleagues, >>>> >>>> >>>> >>>> FYI see attached for the latest draft of the MPLS-TP requirements >>> draft. >>>> >>>> >>>> Ben >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 19/06/2008 16:00, "Loa Andersson" wrote: >>>> >>>> >>>> >>>>> All, >>>> >>>>> the MEAD team will have the next meeting on Tuesday 24, at 6pm >>>>> i.e. 12am east coast and 9am California. >>>> >>>>> Again I plan the meeting to last an hour, and focus will be on the >>>>> document status. >>>> >>>>> Stewart will send out dial in details as usual. >>>> >>>>> /Loa >>>> >>>> >>>> _______________________________________________ >>>> >>>> Mpls-interop mailing list >>>> >>>> Mpls-interop@ietf.org >>>> >>>> https://www.ietf.org/mailman/listinfo/mpls-interop >>>> >>>> >>>> >>>> >>>> >> --------------------------------------------------------------------- >> - >>>> -- >>>> >>>> _______________________________________________ >>>> Mpls-interop mailing list >>>> Mpls-interop@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls-interop >>> >>> >>> -- >>> Loa Andersson >>> >>> Principal Networking Architect >>> Acreo AB phone: +46 8 632 77 14 >>> Isafjordsgatan 22 mobile: +46 739 81 21 64 >>> Kista, Sweden email: loa.andersson@acreo.se >>> loa@pi.nu >> >> >> -- >> Loa Andersson >> >> Principal Networking Architect >> Acreo AB phone: +46 8 632 77 14 >> Isafjordsgatan 22 mobile: +46 739 81 21 64 >> Kista, Sweden email: loa.andersson@acreo.se >> loa@pi.nu >> _______________________________________________ >> Mpls-interop mailing list >> Mpls-interop@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-interop >> > > _______________________________________________ > Mpls-interop mailing list > Mpls-interop@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-interop _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop From mpls-interop-bounces@ietf.org Tue Jun 24 02:36:45 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A5223A68F8; Tue, 24 Jun 2008 02:36:45 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 463F23A69C2 for ; Tue, 24 Jun 2008 02:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.232 X-Spam-Level: X-Spam-Status: No, score=-1.232 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWYJe91sxW1y for ; Tue, 24 Jun 2008 02:36:43 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id B83263A68F5 for ; Tue, 24 Jun 2008 02:36:42 -0700 (PDT) Received: from E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.109]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jun 2008 10:36:35 +0100 Received: from 217.32.164.184 ([217.32.164.184]) by E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.60]) via Exchange Front-End Server mail.bt.com ([193.113.197.28]) with Microsoft Exchange Server HTTP-DAV ; Tue, 24 Jun 2008 09:36:34 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Tue, 24 Jun 2008 10:34:45 +0100 From: Ben Niven-Jenkins To: MEAD team Message-ID: Thread-Topic: MPLS-TP requirements draft-pre6 Thread-Index: AcjSMNQsx4BuurjX8EeQxIcfmO8exAA0/R+VAEuIunAACtuUpAABBM4gABHRXI0AAaDF0AAhY58QACnxVPo= In-Reply-To: Mime-version: 1.0 Content-type: multipart/mixed; boundary="B_3297148594_639816" X-OriginalArrivalTime: 24 Jun 2008 09:36:35.0662 (UTC) FILETIME=[CB6016E0:01C8D5DD] Subject: [Mpls-interop] MPLS-TP requirements draft-pre6 X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3297148594_639816 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Folks, See attached for the latest spin of the MPLS-TP requirements document. I think I've incorporated all the comments received so far. I haven't included the boiler plate IETF-ITU joint effort text as we haven't reached consensus on what it should say yet. Ben --B_3297148594_639816 Content-type: application/octet-stream; name="draft-jenkins-mpls-mpls-tp-requirements-00pre6.txt" Content-disposition: attachment; filename="draft-jenkins-mpls-mpls-tp-requirements-00pre6.txt" Content-transfer-encoding: base64 CgoKTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Qi4gTml2ZW4tSmVua2lucywgRWQuCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBCVApJbnRlbmRlZCBzdGF0 dXM6IEluZm9ybWF0aW9uYWwgICAgICAgICAgICAgICAgICAgICAgICAgIEQuIEJydW5nYXJk LCBFZC4KRXhwaXJlczogSmFudWFyeSAyLCAyMDA5ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBBVCZUCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTS4gQmV0dHMsIEVkLgogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBOb3J0ZWwg TmV0d29ya3MKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIE4uIFNwcmVjaGVyCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgTm9raWEgU2llbWVucyBOZXR3b3JrcwogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEp1 bHkgMDEsIDIwMDgKCgogICAgICAgICAgICAgICAgICAgICAgICAgIE1QTFMtVFAgUmVxdWly ZW1lbnRzCiAgICAgICAgICAgICAgIGRyYWZ0LWplbmtpbnMtbXBscy1tcGxzdHAtcmVxdWly ZW1lbnRzLTAwCgpTdGF0dXMgb2YgdGhpcyBNZW1vCgogICBCeSBzdWJtaXR0aW5nIHRoaXMg SW50ZXJuZXQtRHJhZnQsIGVhY2ggYXV0aG9yIHJlcHJlc2VudHMgdGhhdCBhbnkKICAgYXBw bGljYWJsZSBwYXRlbnQgb3Igb3RoZXIgSVBSIGNsYWltcyBvZiB3aGljaCBoZSBvciBzaGUg aXMgYXdhcmUKICAgaGF2ZSBiZWVuIG9yIHdpbGwgYmUgZGlzY2xvc2VkLCBhbmQgYW55IG9m IHdoaWNoIGhlIG9yIHNoZSBiZWNvbWVzCiAgIGF3YXJlIHdpbGwgYmUgZGlzY2xvc2VkLCBp biBhY2NvcmRhbmNlIHdpdGggU2VjdGlvbiA2IG9mIEJDUCA3OS4KCiAgIEludGVybmV0LURy YWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5n CiAgIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91 cHMuICBOb3RlIHRoYXQKICAgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29y a2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtCiAgIERyYWZ0cy4KCiAgIEludGVybmV0LURy YWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1v bnRocwogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkg b3RoZXIgZG9jdW1lbnRzIGF0IGFueQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0 byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQogICBtYXRlcmlhbCBvciB0byBj aXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iCgogICBUaGUgbGlz dCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQKICAgaHR0 cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0LgoKICAgVGhlIGxpc3Qg b2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBh dAogICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sLgoKICAgVGhpcyBJbnRlcm5l dC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBKYW51YXJ5IDIsIDIwMDkuCgpBYnN0cmFjdAoKICAg VGhpcyBkb2N1bWVudCB3aWxsIG91dGxpbmUgdGhlIHJlcXVpcmVtZW50cyBmb3IgTVBMUy1U UC4KClJlcXVpcmVtZW50cyBMYW5ndWFnZQoKICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJN VVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLAogICAiU0hPVUxE IiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIg aW4gdGhpcwogICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVk IGluIFtSRkMyMTE5XS4KCgoKTml2ZW4tSmVua2lucywgZXQgYWwuICAgIEV4cGlyZXMgSmFu dWFyeSAyLCAyMDA5ICAgICAgICAgICAgICAgIFtQYWdlIDFdCgwKSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgICBNUExTLVRQIFJlcXVpcmVtZW50cyAgICAgICAgICAgICAgICAgSnVseSAy MDA4CgoKVGFibGUgb2YgQ29udGVudHMKCiAgIDEuICBJbnRyb2R1Y3Rpb24gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMwogICAgIDEuMS4g IFRlcm1pbm9sb2d5ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gIDUKICAgMi4gIE1QTFMtVFAgUmVxdWlyZW1lbnRzIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA1CiAgICAgMi4xLiAgR2VuZXJhbCByZXF1aXJl bWVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNQogICAgIDIu Mi4gIExheWVyaW5nIHJlcXVpcmVtZW50cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gIDYKICAgICAyLjMuICBEYXRhIHBsYW5lIHJlcXVpcmVtZW50cyAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA3CiAgICAgMi40LiAgQ29udHJvbCBwbGFu ZSByZXF1aXJlbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOAogICAg IDIuNS4gIE5ldHdvcmsgTWFuYWdlbWVudCAoTk0pIHJlcXVpcmVtZW50cyAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gMTEKICAgICAyLjYuICBPQU0gcmVxdWlyZW1lbnRzIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDExCiAgICAgMi43LiAgTmV0d29yayBw ZXJmb3JtYW5jZSBtYW5hZ2VtZW50IChQTSkgcmVxdWlyZW1lbnRzIC4gLiAuIC4gLiAxMgog ICAgIDIuOC4gIFByb3RlY3Rpb24gJiBTdXJ2aXZhYmlsaXR5IHJlcXVpcmVtZW50cyAgLiAu IC4gLiAuIC4gLiAuIC4gMTIKICAgICAyLjkuICBRb1MgcmVxdWlyZW1lbnRzIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE0CiAgICAgMi4xMC4gU2VjdXJp dHkgcmVxdWlyZW1lbnRzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAx NQogICAzLiAgSUFOQSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gMTYKICAgNC4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zICAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE2CiAgIDUuICBBY2tub3ds ZWRnZW1lbnRzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAxNgogICA2LiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gMTYKICAgQXV0aG9ycycgQWRkcmVzc2VzIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE2CiAgIEludGVsbGVj dHVhbCBQcm9wZXJ0eSBhbmQgQ29weXJpZ2h0IFN0YXRlbWVudHMgLiAuIC4gLiAuIC4gLiAu IC4gLiAxOAoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpOaXZlbi1KZW5raW5zLCBl dCBhbC4gICAgRXhwaXJlcyBKYW51YXJ5IDIsIDIwMDkgICAgICAgICAgICAgICAgW1BhZ2Ug Ml0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIE1QTFMtVFAgUmVxdWlyZW1lbnRzICAg ICAgICAgICAgICAgICBKdWx5IDIwMDgKCgoxLiAgSW50cm9kdWN0aW9uCgogICBGb3IgbWFu eSB5ZWFycywgU09ORVQvU0RIIGhhcyBwcm92aWRlZCBzZXJ2aWNlIHByb3ZpZGVycyB3aXRo IGEgaGlnaAogICBiZW5jaG1hcmsgZm9yIHJlbGlhYmlsaXR5IGFuZCBvcGVyYXRpb25hbCBz aW1wbGljaXR5LiAgV2l0aCB0aGUKICAgYWNjZWxlcmF0aW5nIGdyb3d0aCBvZiBwYWNrZXQt YmFzZWQgc2VydmljZXMgKHN1Y2ggYXMgRXRoZXJuZXQsIFZvSVAsCiAgIEwyL0wzIFZQTiwg SVBUViwgUkFOIGJhY2toYXVsaW5nLCBldGMuKSwgc2VydmljZSBwcm92aWRlcnMgYXJlIGlu CiAgIG5lZWQgb2YgY2FwYWJpbGl0aWVzIHRvIGVmZmljaWVudGx5IHN1cHBvcnQgcGFja2V0 LWJhc2VkIHNlcnZpY2VzIG9uCiAgIHRoZWlyIHRyYW5zcG9ydCBuZXR3b3Jrcy4gIFRoZSBu ZWVkIHRvIGluY3JlYXNlIHRoZWlyIHJldmVudWUgd2hpbGUKICAgcmVtYWluaW5nIGNvbXBl dGl0aXZlIGZvcmNlcyBvcGVyYXRvcnMgdG8gbG9vayBmb3IgdGhlIGxvd2VzdCBuZXR3b3Jr CiAgIFRvdGFsIENvc3Qgb2YgT3duZXJzaGlwIChUQ08pLiAgSW52ZXN0bWVudCBpbiBib3Ro IENhcGl0YWwKICAgRXhwZW5kaXR1cmUgKENBUEVYKSBhbmQgT3BlcmF0aW9uYWwgRXhwZW5z ZSAoT1BFWCkgc2hvdWxkIGJlIG1pbmltYWwuCgogICBDYXJyaWVycyBhcmUgY29uc2lkZXJp bmcgbWlncmF0aW5nIHRvIHBhY2tldCB0cmFuc3BvcnQgbmV0d29ya3MgaW4KICAgb3JkZXIg dG8gcmVkdWNlIHRoZWlyIGNvc3RzIGFuZCB0byBpbXByb3ZlIHRoZWlyIGFiaWxpdHkgdG8g c3VwcG9ydAogICBzZXJ2aWNlcyB3aXRoIGd1YXJhbnRlZWQgU0xBcy4gIE1pZ3JhdGluZyBm cm9tIFNPTkVUL1NESCB0byBwYWNrZXQKICAgdHJhbnNwb3J0IG5ldHdvcmtzIHNob3VsZCBu b3QgaW52b2x2ZSBkcmFtYXRpYyBjaGFuZ2VzIGluIG5ldHdvcmsKICAgb3BlcmF0aW9uLCBz aG91bGQgbm90IG5lY2Vzc2l0YXRlIGV4dGVuc2l2ZSByZXRyYWluaW5nLCBhbmQgc2hvdWxk CiAgIG5vdCByZXF1aXJlIG1ham9yIGNoYW5nZXMgdG8gZXhpc3Rpbmcgd29yayBwcmFjdGlj ZXMuICBUaGUgYWltIGlzIHRvCiAgIHByZXNlcnZlIHRoZSBsb29rLWFuZC1mZWVsIHRvIHdo aWNoIGNhcnJpZXJzIGhhdmUgYmVjb21lIGFjY3VzdG9tZWQKICAgaW4gZGVwbG95aW5nIHRo ZWlyIFNPTkVUL1NESCBuZXR3b3Jrcywgd2hpbGUgcHJvdmlkaW5nIGNvbW1vbiwgbXVsdGkt CiAgIGxheWVyIG9wZXJhdGlvbnMsIHJlc2lsaWVuY3ksIGNvbnRyb2wgYW5kIG1hbmFnZW1l bnQgZm9yIHBhY2tldCwKICAgY2lyY3VpdCBhbmQgbGFtYmRhIHRyYW5zcG9ydCBuZXR3b3Jr cy4KCiAgIEFuIGltcG9ydGFudCBhdHRyaWJ1dGUgb2YgYSB0cmFuc3BvcnQgbmV0d29yayBp cyBpdHMgYWJpbGl0eSB0bwogICBmdW5jdGlvbiBpbmRlcGVuZGVudGx5IGZyb20gYm90aCBp dHMgY2xpZW50IGFuZCBzZXJ2ZXIgKHRyYW5zbWlzc2lvbgogICBtZWRpYSkgbGF5ZXIgbmV0 d29ya3MuICBJdCBzaG91bGQgYmUgY2FwYWJsZSBvZiB0cmFuc21pdHRpbmcgb3ZlciBhbnkK ICAgbWVkaWEuICBBbm90aGVyIGtleSBjaGFyYWN0ZXJpc3RpYyBvZiB0cmFuc3BvcnQgbmV0 d29ya3MgaXMgdGhlCiAgIGNhcGFiaWxpdHkgdG8gbWFpbnRhaW4gdGhlIGludGVncml0eSBv ZiB0aGUgY2xpZW50IGFjcm9zcyB0aGUKICAgdHJhbnNwb3J0IG5ldHdvcmsuICBBIHRyYW5z cG9ydCBuZXR3b3JrIG11c3QgcHJvdmlkZSB0aGUgbWVhbnMgdG8KICAgY29tbWl0IHF1YWxp dHkgb2Ygc2VydmljZSBvYmplY3RpdmVzIHRvIGNsaWVudHMuICBUaGlzIGlzIGFjaGlldmVk IGJ5CiAgIHByb3ZpZGluZyBhIG1lY2hhbmlzbSBmb3IgY2xpZW50IG5ldHdvcmsgc2Vydmlj ZSBkZW1hcmNhdGlvbiBmb3IgdGhlCiAgIG5ldHdvcmsgcGF0aCB0b2dldGhlciB3aXRoIGFu IGFzc29jaWF0ZWQgbmV0d29yayByZXNpbGllbmN5CiAgIG1lY2hhbmlzbS4gIEEgdHJhbnNw b3J0IG5ldHdvcmsgbXVzdCBhbHNvIHByb3ZpZGUgYSBtZXRob2Qgb2Ygc2VydmljZQogICBt b25pdG9yaW5nIGluIG9yZGVyIHRvIHZlcmlmeSB0aGUgZGVsaXZlcnkgb2YgYW4gYWdyZWVk IHF1YWxpdHkgb2YKICAgc2VydmljZS4gIFRoaXMgaXMgZW5hYmxlZCBieSBtZWFucyBvZiBj YXJyaWVyLWdyYWRlIE9BTSB0b29scy4KCiAgIFRoZSBjb25uZWN0aXZpdHkgc2VydmljZSBp cyB0aGUgYmFzaWMgc2VydmljZSBwcm92aWRlZCBieSBhIHRyYW5zcG9ydAogICBuZXR3b3Jr LiAgVGhlIHB1cnBvc2Ugb2YgYSB0cmFuc3BvcnQgbmV0d29yayBpcyB0byB0cmFuc3BhcmVu dGx5CiAgIGNhcnJ5IGl0cyBjbGllbnRzIChpLmUuIHRoZSBzdHJlYW0gb2YgY2xpZW50IFBE VXMgb3IgY2xpZW50IGJpdHMpCiAgIGJldHdlZW4gZW5kcG9pbnRzIGluIHRoZSBuZXR3b3Jr ICh0eXBpY2FsbHkgb3ZlciBzZXZlcmFsIGludGVybWVkaWF0ZQogICBub2RlcykuICBUaGVz ZSBlbmRwb2ludHMgbWF5IGJlIHNlcnZpY2Ugc3dpdGNoaW5nIHBvaW50cyBvciBzZXJ2aWNl CiAgIHRlcm1pbmF0aW5nIHBvaW50cy4gIFRoZSBjb25uZWN0aXZpdHkgc2VydmljZXMgb2Zm ZXJlZCB0byBjdXN0b21lcnMKICAgYXJlIGFnZ3JlZ2F0ZWQgaW50byBsYXJnZSB0cmFuc3Bv cnQgcGF0aHMgd2l0aCBsb25nLWhvbGRpbmcgdGltZXMsCiAgIHdoaWNoIGVuYWJsZSB0aGUg ZWZmaWNpZW50IGFuZCByZWxpYWJsZSBvcGVyYXRpb24gb2YgdGhlIHRyYW5zcG9ydAogICBu ZXR3b3JrLiAgVGhlc2UgdHJhbnNwb3J0IHBhdGhzIGFyZSBtb2RpZmllZCBpbmZyZXF1ZW50 bHkuCgogICBBZ2dyZWdhdGlvbiBhbmQgaGllcmFyY2h5IGFyZSBiZW5lZmljaWFsIGZvciBh Y2hpZXZpbmcgc2NhbGFiaWxpdHkKICAgYW5kIHNlY3VyaXR5IHNpbmNlOgoKCgpOaXZlbi1K ZW5raW5zLCBldCBhbC4gICAgRXhwaXJlcyBKYW51YXJ5IDIsIDIwMDkgICAgICAgICAgICAg ICAgW1BhZ2UgM10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIE1QTFMtVFAgUmVxdWly ZW1lbnRzICAgICAgICAgICAgICAgICBKdWx5IDIwMDgKCgogICAxLiAgVGhleSByZWR1Y2Ug dGhlIG51bWJlciBvZiBwcm92aXNpb25pbmcgYW5kIGZvcndhcmRpbmcgc3RhdGVzIGluCiAg ICAgICB0aGUgbmV0d29yayBjb3JlLgoKICAgMi4gIFRoZXkgcmVkdWNlIGxvYWQgYW5kIHRo ZSBjb3N0IG9mIGltcGxlbWVudGluZyBzZXJ2aWNlIGFzc3VyYW5jZQogICAgICAgYW5kIGZh dWx0IG1hbmFnZW1lbnQuCgogICAzLiAgQ2xpZW50IHNpZ25hbHMgYXJlIGNvbXBsZXRlbHkg ZW5jYXBzdWxhdGVkIGFuZCBpc29sYXRlZCBmcm9tIGVhY2gKICAgICAgIG90aGVyLiAgVGhp cyBhbHNvIGFsbG93cyBjb21wbGV0ZSBpc29sYXRpb24gb2YgY3VzdG9tZXIgdHJhZmZpYwog ICAgICAgZnJvbSBjYXJyaWVyIG9wZXJhdGlvbnMuCgogICBDbGllbnQgc2lnbmFscyBhcmUg Zmlyc3QgdHJhbnNwYXJlbnRseSBlbmNhcHN1bGF0ZWQuICBUaGVzZQogICBlbmNhcHN1bGF0 ZWQgY2xpZW50IHNpZ25hbHMgYXJlIHRoZW4gYWdncmVnYXRlZCBmb3IgdHJhbnNwb3J0IHRo cm91Z2gKICAgdGhlIG5ldHdvcmsgaW4gb3JkZXIgdG8gb3B0aW1pemUgbmV0d29yayBtYW5h Z2VtZW50LiAgU2VydmVyIGxheWVyCiAgIE9BTSBpcyB1c2VkIHRvIG1vbml0b3IgdGhlIHRy YW5zcG9ydCBpbnRlZ3JpdHkgb2YgdGhlIGNsaWVudCBsYXllcgogICBhZ2dyZWdhdGUuICBB dCBhbnkgaG9wLCB0aGUgYWdncmVnYXRlZCBzaWduYWxzIG1heSBiZSBmdXJ0aGVyCiAgIGFn Z3JlZ2F0ZWQgaW4gbG93ZXIgbGF5ZXIgdHJhbnNwb3J0IG5ldHdvcmsgcGF0aHMgZm9yIHRy YW5zcG9ydAogICBhY3Jvc3MgaW50ZXJtZWRpYXRlIHNoYXJlZCBsaW5rcy4gIFRoZSBlbmNh cHN1bGF0ZWQgY2xpZW50IHNpZ25hbHMKICAgYXJlIGV4dHJhY3RlZCBhdCB0aGUgZWRnZXMg b2YgYWdncmVnYXRpb24gZG9tYWlucywgYW5kIGFyZSBlaXRoZXIKICAgZGVsaXZlcmVkIHRv IHRoZSBjbGllbnQgb3IgZm9yd2FyZGVkIHRvIGFub3RoZXIgZG9tYWluLiAgSW4gdGhlIGNv cmUKICAgb2YgdGhlIG5ldHdvcmssIG9ubHkgdGhlIHNlcnZlciBsYXllciBhZ2dyZWdhdGVk IHNpZ25hbHMgYXJlCiAgIG1vbml0b3JlZDsgaW5kaXZpZHVhbCBjbGllbnQgc2lnbmFscyBh cmUgbW9uaXRvcmVkIGF0IHRoZSBuZXR3b3JrCiAgIGJvdW5kYXJ5IGluIHRoZSBjbGllbnQg bGF5ZXIgbmV0d29yay4KCiAgIFF1YWxpdHktb2Ytc2VydmljZSBtZWNoYW5pc21zIGFyZSBy ZXF1aXJlZCBpbiB0aGUgcGFja2V0IHRyYW5zcG9ydAogICBuZXR3b3JrIHRvIGVuc3VyZSB0 aGUgcHJpb3JpdGl6YXRpb24gb2YgY3JpdGljYWwgc2VydmljZXMsIHRvCiAgIGd1YXJhbnRl ZSBCVyBhbmQgdG8gY29udHJvbCBqaXR0ZXIgYW5kIGRlbGF5LgoKICAgU2VydmljZSBwcm92 aWRlcnMgcmVxdWlyZSBjb250cm9sIGFuZCBkZXRlcm1pbmlzdGljIHVzYWdlIG9mIG5ldHdv cmsKICAgcmVzb3VyY2VzLiAgVGhleSBuZWVkIGVuZC10by1lbmQgY29udHJvbCB0byBlbmdp bmVlciBuZXR3b3JrIHBhdGhzCiAgIGFuZCB0byBlZmZpY2llbnRseSB1dGlsaXplIG5ldHdv cmsgcmVzb3VyY2VzLiAgVGhleSByZXF1aXJlCiAgIGNhcGFiaWxpdGllcyB0byBzdGF0aWNh bGx5IChPU1MgYmFzZWQpIGFuZCBkeW5hbWljYWxseSBwcm92aXNpb24KICAgZGV0ZXJtaW5p c3RpYywgcHJvdGVjdGVkIGFuZCBzZWN1cmVkIHNlcnZpY2VzIGFuZCB0aGVpciBhc3NvY2lh dGVkCiAgIHJlc291cmNlcyBhcyB3ZWxsIGFzIGFsdGVybmF0aXZlIGNvbnRyb2wtcGxhbmUg b3B0aW9ucy4KCiAgIENhcnJpZXJzIHdpbGwgc3RpbGwgbmVlZCB0byBjb3BlIHdpdGggbGVn YWN5IG5ldHdvcmtzICh3aGljaCBhcmUKICAgY29tcG9zZWQgb2YgbWFueSBsYXllcnMgYW5k IHRlY2hub2xvZ2llcyksIHRodXMgdGhlIHBhY2tldCB0cmFuc3BvcnQKICAgbmV0d29yayBz aG91bGQgaW50ZXJ3b3JrIHdpdGggb3RoZXIgcGFja2V0IGFuZCB0cmFuc3BvcnQgbmV0d29y a3MKICAgKGJvdGggaG9yaXpvbnRhbGx5IGFuZCB2ZXJ0aWNhbGx5KS4gIFZlcnRpY2FsIGlu dGVyd29ya2luZyBpcyBhbHNvCiAgIGtub3duIGFzIGNsaWVudC9zZXJ2ZXIgb3IgbmV0d29y ayBpbnRlcndvcmtpbmcuICBIb3Jpem9udGFsCiAgIGludGVyd29ya2luZyBpcyBhbHNvIGtu b3duIGFzIHBlZXItcGFydGl0aW9uIG9yIHNlcnZpY2UgaW50ZXJ3b3JraW5nLgogICBGb3Ig bW9yZSBkZXRhaWxzIG9uIGVhY2ggdHlwZSBvZiBpbnRlcndvcmtpbmcgYW5kIHNvbWUgb2Yg dGhlIGlzc3VlcwogICB0aGF0IG1heSBhcmlzZSAoZXNwZWNpYWxseSB3aXRoIGhvcml6b250 YWwgaW50ZXJ3b3JraW5nKSBzZWUKICAgW0lUVS5ZMTQwMS4yMDA4XS4KCiAgIE1QTFMgaXMg YSBtYXR1cmluZyBwYWNrZXQgdGVjaG5vbG9neSBhbmQgaXQgaXMgYWxyZWFkeSBwbGF5aW5n IGFuCiAgIGltcG9ydGFudCByb2xlIGluIHRyYW5zcG9ydCBuZXR3b3JrcyBhbmQgc2Vydmlj ZXMuICBIb3dldmVyLCBub3QgYWxsCiAgIG9mIE1QTFMncyBjYXBhYmlsaXRpZXMgYW5kIG1l Y2hhbmlzbXMgYXJlIG5lZWRlZCBhbmQvb3IgY29uc2lzdGVudAogICB3aXRoIHRyYW5zcG9y dCBuZXR3b3JrIG9wZXJhdGlvbnMuICBNUExTLVRQIG5lZWRzIHRvIGNvbWJpbmUgdGhlCgoK Ck5pdmVuLUplbmtpbnMsIGV0IGFsLiAgICBFeHBpcmVzIEphbnVhcnkgMiwgMjAwOSAgICAg ICAgICAgICAgICBbUGFnZSA0XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgTVBMUy1U UCBSZXF1aXJlbWVudHMgICAgICAgICAgICAgICAgIEp1bHkgMjAwOAoKCiAgIG5lY2Vzc2Fy eSBleGlzdGluZyBjYXBhYmlsaXRpZXMgb2YgTVBMUyB3aXRoIGFkZGl0aW9uYWwgbWluaW1h bAogICBtZWNoYW5pc21zIGluIG9yZGVyIHRoYXQgaXQgY2FuIGJlIHVzZWQgaW4gYSB0cmFu c3BvcnQgcm9sZS4KCiAgIENvbWJpbmluZyB0aGUgcGFja2V0IGV4cGVyaWVuY2Ugb2YgTVBM UyB3aXRoIHRoZSBvcGVyYXRpb25hbAogICBleHBlcmllbmNlIG9mIFNPTkVUL1NESCBjb25z dGl0dXRlcyBhIHBhY2tldCB0cmFuc3BvcnQgdGVjaG5vbG9neQogICBuYW1lZCBNUExTLVRQ LiAgTVBMUy1UUCB3aWxsIGVuYWJsZSB0aGUgbWlncmF0aW9uIG9mIFNPTkVUL1NESAogICBu ZXR3b3JrcyB0byBhIHBhY2tldC1iYXNlZCBuZXR3b3JrIHRoYXQgd2lsbCBlYXNpbHkgc2Nh bGUgdG8gc3VwcG9ydAogICBwYWNrZXQgc2VydmljZXMgaW4gYSBzaW1wbGUgYW5kIGNvc3Qg ZWZmZWN0aXZlIHdheS4KCiAgIFRoZSByZXF1aXJlbWVudHMgb2YgTVBMUy1UUCBhcmUgcHJv dmlkZWQgYmVsb3cuICBBbHRob3VnaCBib3RoIHN0YXRpYwogICBhbmQgZHluYW1pYyBjb25m aWd1cmF0aW9uIG9mIE1QTFMtVFAgdHJhbnNwb3J0IHBhdGhzIChpbmNsdWRpbmcgT0FNKQog ICBpcyByZXF1aXJlZCBieSB0aGlzIGRvY3VtZW50LCBpdCBNVVNUIGJlIHBvc3NpYmxlIGZv ciBvcGVyYXRvcnMgdG8gYmUKICAgYWJsZSB0byBjb21wbGV0ZWx5IG9wZXJhdGUgKGluY2x1 ZGluZyBPQU0pIGFuIE1QTFMtVFAgbmV0d29yayBpbiB0aGUKICAgYWJzZW5jZSBvZiBhbnkg Y29udHJvbCBwbGFuZSBvciBkeW5hbWljIHByb3RvY29scy4KCjEuMS4gIFRlcm1pbm9sb2d5 CgogICBTZWN0aW9uOiBBIHNlY3Rpb24gaXMgYSBuZXR3b3JrIHNlZ21lbnQgYmV0d2VlbiB0 d28gTFNScyB0aGF0IGFyZQogICBpbW1lZGlhdGVseSBhZGphY2VudCBhdCB0aGUgTVBMUy1U UCBsYXllci4KCiAgIFNlcnZpY2UgbGF5ZXI6IEEgbmV0d29yayBsYXllciBpbiB3aGljaCB0 cmFuc3BvcnQgcGF0aHMgYXJlIHVzZWQgdG8KICAgY2FycnkgYSBjdXN0b21lcidzIChpbmRp dmlkdWFsIG9yIGJ1bmRsZWQpIHNlcnZpY2UgKG1heSBiZSBwb2ludC10by0KICAgcG9pbnQs IHBvaW50LXRvLW11bHRpcG9pbnQgb3IgbXVsdGlwb2ludC10by1tdWx0aXBvaW50IHNlcnZp Y2VzKS4KCiAgIFRhbmRlbSBDb25uZWN0aW9uOiBBIHRhbmRlbSBjb25uZWN0aW9uIGNvcnJl c3BvbmRzIHRvIGEgc2VnbWVudCBvZiBhCiAgIHBhdGguICBUaGlzIG1heSBiZSBlaXRoZXIg YSBzZWdtZW50IG9mIGFuIExTUCAoaS5lLiBhIHN1Yi1wYXRoKSwgb3IKICAgb25lIG9yIG1v cmUgc2VnbWVudChzKSBvZiBhIFBXLgoKICAgVHJhbnNwb3J0IHBhdGg6IEEgY29ubmVjdGlv biBhcyBkZWZpbmUgaW4gRy44MDAgW0lUVS5HODAwLjIwMDddLgoKICAgVHJhbnNwb3J0IHBh dGggbGF5ZXI6IEEgbmV0d29yayBsYXllciB3aGljaCBwcm92aWRlcyBwb2ludC10by1wb2lu dAogICBvciBwb2ludC10by1tdWx0aXBvaW50IHRyYW5zcG9ydCBwYXRocyB3aGljaCBhcmUg dXNlZCB0byBjYXJyeQogICBhZ2dyZWdhdGVzIG9mIHRoZSBuZXR3b3JrIHNlcnZpY2UgbGF5 ZXIuCgogICBUcmFuc21pc3Npb24gbWVkaWEgbGF5ZXI6IEEgbmV0d29yayBsYXllciB3aGlj aCBwcm92aWRlcyBzZWN0aW9ucwogICAodHdvLXBvcnQgcG9pbnQtdG8tcG9pbnQgY29ubmVj dGlvbnMpIHRvIGNhcnJ5IHRoZSBhZ2dyZWdhdGUgb2YKICAgbmV0d29yayB0cmFuc3BvcnQg cGF0aCBvciBuZXR3b3JrIHNlcnZpY2UgbGF5ZXJzIG9uIHZhcmlvdXMgcGh5c2ljYWwKICAg bWVkaWEuCgoKMi4gIE1QTFMtVFAgUmVxdWlyZW1lbnRzCgoyLjEuICBHZW5lcmFsIHJlcXVp cmVtZW50cwoKICAgbyAgTVBMUy1UUCBNVVNUIG9mZmVyIGFzIG11Y2ggY29tbW9uYWxpdHkg YXMgcG9zc2libGUgd2l0aCB0aGUgTVBMUwogICAgICBkYXRhIHBsYW5lIGFzIGRlZmluZWQg YnkgSUVURi4gIFdoZW4gTVBMUyBvZmZlcnMgbXVsdGlwbGUgb3B0aW9ucwogICAgICBpbiB0 aGlzIHJlc3BlY3QsIE1QTFMtVFAgU0hPVUxEIHNlbGVjdCB0aGUgbWluaW11bSBzdWItc2V0 CiAgICAgIChuZWNlc3NhcnkgYW5kIHN1ZmZpY2llbnQgc3Vic2V0KSBhcHBsaWNhYmxlIHRv IGEgdHJhbnNwb3J0CgoKCk5pdmVuLUplbmtpbnMsIGV0IGFsLiAgICBFeHBpcmVzIEphbnVh cnkgMiwgMjAwOSAgICAgICAgICAgICAgICBbUGFnZSA1XQoMCkludGVybmV0LURyYWZ0ICAg ICAgICAgICAgTVBMUy1UUCBSZXF1aXJlbWVudHMgICAgICAgICAgICAgICAgIEp1bHkgMjAw OAoKCiAgICAgIG5ldHdvcmsgYXBwbGljYXRpb24uCgogICBvICBBbnkgbmV3IGZ1bmN0aW9u YWxpdHkgdGhhdCBpcyBkZWZpbmVkIHRvIGZ1bGZpbCB0aGUgcmVxdWlyZW1lbnRzCiAgICAg IGZvciBNUExTLVRQIE1VU1QgYmUgYWdyZWVkIHdpdGhpbiBJRVRGIGFuZCByZS11c2UgKGFz IGZhciBhcwogICAgICBwcmFjdGljYWxseSBwb3NzaWJsZSkgZXhpc3RpbmcgTVBMUyBzdGFu ZGFyZHMuCgogICBvICBNZWNoYW5pc21zIGFuZCBjYXBhYmlsaXRpZXMgTVVTVCBiZSBhYmxl IHRvIGludGVyb3BlcmF0ZSB3aXRoCiAgICAgIGV4aXN0aW5nIElFVEYgTVBMUyBbUkZDMzAz MV0gYW5kIElFVEYgUFdFMyBbUkZDMzk4NV0gY29udHJvbCBhbmQKICAgICAgZGF0YSBwbGFu ZXMgd2hlcmUgYXBwcm9wcmlhdGUuCgogICBvICBNUExTLVRQIE1VU1Qgc3VwcG9ydCB0cmFm ZmljIGVuZ2luZWVyaW5nIGNhcGFiaWxpdGllcyB0aGF0IGFsbG93CiAgICAgIGRldGVybWlu aXN0aWMgY29udHJvbCBvZiB0aGUgdXNlIG9mIG5ldHdvcmsgcmVzb3VyY2VzLgoKICAgbyAg TVBMUy1UUCBNVVNUIHN1cHBvcnQgdGhlIGxvZ2ljYWwgc2VwYXJhdGlvbiBvZiB0aGUgY29u dHJvbCBhbmQKICAgICAgbWFuYWdlbWVudCBwbGFuZXMgZnJvbSB0aGUgZGF0YSBwbGFuZS4K CiAgIG8gIE1QTFMtVFAgTVVTVCBhbGxvdyB0aGUgcGh5c2ljYWwgc2VwYXJhdGlvbiBvZiB0 aGUgY29udHJvbCBhbmQKICAgICAgbWFuYWdlbWVudCBwbGFuZXMgZnJvbSB0aGUgZGF0YSBw bGFuZS4KCiAgIG8gIE1QTFMtVFAgTVVTVCBzdXBwb3J0IHBvaW50IHRvIHBvaW50IChQMlAp IG9yIHBvaW50IHRvIG11bHRpcG9pbnQKICAgICAgKFAyTVApIHRyYW5zcG9ydCBwYXRocy4K CiAgIG8gIE1QTFMtVFAgTVVTVCBzdXBwb3J0IHN0YXRpYyBwcm92aXNpb25pbmcgb2YgdHJh bnNwb3J0IHBhdGhzIHZpYSBhbgogICAgICBOTVMvT1NTIChpLmUuIHZpYSB0aGUgbWFuYWdl bWVudCBwbGFuZSkuCgogICBvICBTdGF0aWMgcHJvdmlzaW9uaW5nIE1VU1Qgbm90IGRlcGVu ZCBvbiByb3V0aW5nIG9yIHNpZ25hbGluZwogICAgICBwcm90b2NvbHMgKGUuZy4gIEdNUExT LCBPU1BGLCBJUy1JUywgUlNWUCwgQkdQLCBMRFAgZXRjLikuCgogICBvICBNUExTLVRQIE1V U1Qgc3VwcG9ydCBkeW5hbWljIHByb3Zpc2lvbmluZyBvZiB0cmFuc3BvcnQgcGF0aHMgdmlh IGEKICAgICAgY29udHJvbCBwbGFuZS4KCiAgIG8gIFRoZSBNUExTLVRQIGRhdGEgcGxhbmUg TVVTVCBiZSBjYXBhYmxlIG9mIGZ1bmN0aW9uaW5nCiAgICAgIGluZGVwZW5kZW50bHkgb2Yg dGhlIGNvbnRyb2wgb3IgbWFuYWdlbWVudCBwbGFuZSB1c2VkIHRvIG9wZXJhdGUKICAgICAg dGhlIE1QTFMtVFAgbGF5ZXIgbmV0d29yay4gIFRoYXQgaXMgdGhlIE1QTFMtVFAgZGF0YSBw bGFuZQogICAgICBvcGVyYXRpb24gTVVTVCBjb250aW51ZSB0byBvcGVyYXRlIG5vcm1hbGx5 IGlmIHRoZSBtYW5hZ2VtZW50CiAgICAgIHBsYW5lIG9yIGNvbnRyb2wgcGxhbmUgdGhhdCBj b25maWd1cmVkIHRoZSB0cmFuc3BvcnQgcGF0aHMgZmFpbHMuCgogICBvICBNUExTLVRQIE1V U1Qgc3VwcG9ydCBhbnkgbmV0d29yayB0b3BvbG9neSBhbmQgYmUgYWJsZSB0byBzdXBwb3J0 CiAgICAgIGluY3JlYXNpbmcgYmFuZHdpZHRoIGRlbWFuZHMsIHRvcG9sb2d5LCBudW1iZXIg b2YgY3VzdG9tZXJzIG9yCiAgICAgIG51bWJlciBvZiBzZXJ2aWNlcyBpbmNyZW1lbnRhbGx5 LgoKMi4yLiAgTGF5ZXJpbmcgcmVxdWlyZW1lbnRzCgogICBvICBBbiBNUExTLVRQIG5ldHdv cmsgTVVTVCBvcGVyYXRlIGluIGEgbXVsdGlwbGUgbGF5ZXIgbmV0d29yawogICAgICBlbnZp cm9ubWVudCBjb25zaXN0aW5nIG9mIGluZGVwZW5kZW50IHNlcnZpY2UsIHRyYW5zcG9ydCBw YXRoIGFuZAogICAgICB0cmFuc21pc3Npb24gbWVkaWEgbGF5ZXJzLgoKICAgTVBMUy1UUCBt YXkgcHJvdmlkZSB0aGUgc2VydmljZSBsYXllciAoZm9yIFAyUCBhbmQgUDJNUCBzZXJ2aWNl cykKCgoKTml2ZW4tSmVua2lucywgZXQgYWwuICAgIEV4cGlyZXMgSmFudWFyeSAyLCAyMDA5 ICAgICAgICAgICAgICAgIFtQYWdlIDZdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICBN UExTLVRQIFJlcXVpcmVtZW50cyAgICAgICAgICAgICAgICAgSnVseSAyMDA4CgoKICAgYW5k L29yIHRoZSB0cmFuc3BvcnQgcGF0aCBsYXllciB3aXRoaW4gYSBsYXllciBuZXR3b3JrIGVu dmlyb25tZW50LgoKICAgbyAgQW4gTVBMUy1UUCBsYXllciBuZXR3b3JrIE1VU1Qgc3VwcG9y dCB0aGUgdHJhbnNwYXJlbnQgdHJhbnNwb3J0IG9mCiAgICAgIE1QTFMtVFAgYW5kIG5vbiBN UExTLVRQIGNsaWVudCBsYXllciBuZXR3b3Jrcy4KCiAgIG8gIEFuIE1QTFMtVFAgbGF5ZXIg bmV0d29yayBNVVNUIGJlIGFibGUgdG8gYmUgdHJhbnNwYXJlbnRseSBjYXJyaWVkCiAgICAg IG92ZXIgTVBMUy1UUCBhbmQgbm9uIE1QTFMtVFAgc2VydmVyIGxheWVyIG5ldHdvcmtzIChz dWNoIGFzCiAgICAgIEV0aGVybmV0LCBPVE4sIGV0Yy4pCgogICBvICBJdCBNVVNUIGJlIHBv c3NpYmxlIHRvIG9wZXJhdGUgdGhlIE1QTFMtVFAgbGF5ZXIgbmV0d29yawogICAgICBpbmRl cGVuZGVudGx5IG9mIG90aGVyIGxheWVyIG5ldHdvcmtzIChlaXRoZXIgTVBMUy1UUCBvciBu b24KICAgICAgTVBMUy1UUCkuCgogICBUaGlzIGlzIG5vdCBvbmx5IGEgdGVjaG5vbG9neSBy ZXF1aXJlbWVudCwgZGlmZmVyZW50IGFkbWluaXN0cmF0aXZlCiAgIGdyb3VwcyBtYXkgYmUg cmVzcG9uc2libGUgZm9yIGRpZmZlcmVudCBsYXllciBuZXR3b3JrcyAoZXZlbiB3aGVuCiAg IHRoZXkgYXJlIG9mIHRoZSBzYW1lIHR5cGUpLCBhbmQgcmVxdWlyZSB0aGUgY2FwYWJpbGl0 eSB0bwogICBvcGVyYXRpb25hbGx5IHN1cHBvcnQgdGhlIGRpZmZlcmVudCBsYXllcnMuCgog ICBvICBJdCBNVVNUIGJlIHBvc3NpYmxlIHRvIGhpZGUgTVBMUy1UUCBsYXllciBuZXR3b3Jr IGFkZHJlc3NpbmcgYW5kCiAgICAgIG90aGVyIGluZm9ybWF0aW9uIChlLmcuIHRvcG9sb2d5 KSBmcm9tIGNsaWVudCBsYXllcnMuCgoyLjMuICBEYXRhIHBsYW5lIHJlcXVpcmVtZW50cwoK ICAgbyAgVGhlIGlkZW50aWZpY2F0aW9uIG9mIGVhY2ggdHJhbnNwb3J0IHBhdGggd2l0aGlu IGl0cyBhZ2dyZWdhdGUKICAgICAgTVVTVCBiZSBzdXBwb3J0ZWQuCgogICBvICBBIGxhYmVs IGluIGEgcGFydGljdWxhciBzZWN0aW9uIE1VU1QgdW5pcXVlbHkgaWRlbnRpZnkgdGhlCiAg ICAgIHRyYW5zcG9ydCBwYXRoLgoKICAgbyAgQSB0cmFuc3BvcnQgcGF0aCdzIHNvdXJjZSBN VVNUIGJlIGlkZW50aWZpYWJsZSBhdCBpdHMgZGVzdGluYXRpb24uCgogICBUcmFuc3BvcnQg cGF0aHMgY2FuIGJlIGFnZ3JlZ2F0ZWQgaW50byB0cnVua3MgYnkgcHVzaGluZyBhbmQgZGUt CiAgIGFnZ3JlZ2F0ZWQgYnkgcG9wcGluZyBsYWJlbHMuICBNUExTLVRQIGxhYmVscyBtYXkg YmUgc3dhcHBlZCB3aXRoaW4gYQogICB0cmFuc3BvcnQgcGF0aCBpbiBhIGxheWVyIG5ldHdv cmsgaW5zdGFuY2Ugd2hlbiB0aGUgdHJhZmZpYyBpcwogICBmb3J3YXJkZWQgZnJvbSBvbmUg TVBMUy1UUCBsaW5rIHRvIGFub3RoZXIgTVBMUy1UUCBsaW5rLgoKICAgbyAgTGFiZWxsaW5n IE1VU1QgbWFrZSB1c2Ugb2YgdGhlIE1QTFMgbGFiZWwgYW5kIGxhYmVsIHN0YWNrIGVudHJ5 IGFzCiAgICAgIGRlZmluZWQgaW4gUkZDMzAzMi4KCiAgIG8gIEl0IE1VU1QgYmUgcG9zc2li bGUgdG8gb3BlcmF0ZSBhbmQgY29uZmlndXJlIHRoZSBNUExTLVRQIGRhdGEKICAgICAgKHRy YW5zcG9ydCkgcGxhbmUgd2l0aG91dCBhbnkgSVAgZnVuY3Rpb25hbGl0eS4KCiAgIG8gIE1Q TFMtVFAgTVVTVCBzdXBwb3J0IGJvdGggdW5pZGlyZWN0aW9uYWwgYW5kIGJpLWRpcmVjdGlv bmFsIHBvaW50LQogICAgICB0by1wb2ludCB0cmFuc3BvcnQgcGF0aHMuCgogICBvICBUaGUg Zm9yd2FyZCBhbmQgYmFja3dhcmQgZGlyZWN0aW9ucyBvZiBhIGJpLWRpcmVjdGlvbmFsIHRy YW5zcG9ydAogICAgICBwYXRoIE1VU1QgYmUgY2FwYWJsZSBvZiBmb2xsb3dpbmcgdGhlIHNh bWUgcGF0aCB3aXRoaW4gdGhlIE1QTFMtVFAKICAgICAgbmV0d29yay4KCgoKTml2ZW4tSmVu a2lucywgZXQgYWwuICAgIEV4cGlyZXMgSmFudWFyeSAyLCAyMDA5ICAgICAgICAgICAgICAg IFtQYWdlIDddCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICBNUExTLVRQIFJlcXVpcmVt ZW50cyAgICAgICAgICAgICAgICAgSnVseSAyMDA4CgoKICAgbyAgVGhlIGludGVybWVkaWF0 ZSBub2RlcyBTSE9VTEQgYmUgYXdhcmUgYWJvdXQgdGhlIGJpbmRpbmcgb2YgdGhlCiAgICAg IGZvcndhcmQgYW5kIHRoZSBiYWNrd2FyZCBkaXJlY3Rpb25zIGJlbG9uZ2luZyB0byB0aGUg c2FtZSBiaS0KICAgICAgZGlyZWN0aW9uYWwgdHJhbnNwb3J0IHBhdGguCgogICBvICBNUExT LVRQIFNIT1VMRCBzdXBwb3J0IHVuaWRpcmVjdGlvbmFsIHBvaW50LXRvLW11bHRpcG9pbnQK ICAgICAgdHJhbnNwb3J0IHBhdGhzLgoKICAgbyAgTVBMUy1UUCB0cmFuc3BvcnQgcGF0aHMg TVVTVCBOT1QgcGVyZm9ybSBtZXJnaW5nIGluIGEgd2F5IHRoYXQKICAgICAgcHJldmVudHMg dGhlIHVuaXF1ZSBpZGVudGlmaWNhdGlvbiBvZiB0aGUgc291cmNlIGF0IHRoZQogICAgICBk ZXN0aW5hdGlvbiAoZS5nLiBubyB1c2Ugb2YgTERQIG1wMnAgc2lnbmFsaW5nIGluIG9yZGVy IHRvIGF2b2lkCiAgICAgIGxvc2luZyBMU1AgaGVhZC1lbmQgaW5mb3JtYXRpb24sIG5vIHVz ZSBvZiBQSFAsIGV0YykuCgogICBvICBNUExTLVRQIFNIT1VMRCBzdXBwb3J0IHRyYW5zcG9y dCBhbmQgUW9TIG1lY2hhbmlzbXMgdGhhdCBjYW4KICAgICAgZGVsaXZlciBzdGF0aXN0aWNh bCBtdWx0aXBsZXhpbmcgZ2Fpbi4gIFBhY2tldHMgZXhjZWVkaW5nIHRoZQogICAgICBhZ3Jl ZWQgdHJhZmZpYyBwcm9maWxlIG1heSBiZSBtYXJrZWQgb3IgZGlzY2FyZGVkIGJ5IHRoZSB0 cmFmZmljCiAgICAgIGNvbmRpdGlvbmluZyBhdCB0aGUgaW5ncmVzcyBvZiB0aGUgTVBMUy1U UCBuZXR3b3JrLgoKICAgbyAgTVBMUy1UUCBNVVNUIHN1cHBvcnQgdHJhbnNwb3J0IHBhdGhz IHRocm91Z2ggYSBzaW5nbGUgZG9tYWluLgoKICAgbyAgTVBMUy1UUCBTSE9VTEQgc3VwcG9y dCB0cmFuc3BvcnQgcGF0aHMgdGhyb3VnaCBtdWx0aXBsZSBkb21haW5zLgoKICAgbyAgTVBM Uy1UUCBNVVNUIGJlIGFibGUgdG8gYWNjb21tb2RhdGUgbmV3IHRyYWZmaWMgdHlwZXMuCgog ICBvICBNUExTLVRQIFNIT1VMRCBzdXBwb3J0IG1lY2hhbmlzbXMgdG8gc2FmZWd1YXJkIGFn YWluc3QgdGhlCiAgICAgIHByb3Zpc2lvbmluZyBvZiB0cmFuc3BvcnQgcGF0aHMgd2hpY2gg Y29udGFpbiBmb3J3YXJkaW5nIGxvb3BzLgoKICAgbyAgTVBMUy1UUCBTSE9VTEQgc3VwcG9y dCBtZWNoYW5pc21zIHRvIG1pbmltaXplIHRyYWZmaWMgaW1wYWN0CiAgICAgIGR1cmluZyBu ZXR3b3JrIHJlY29uZmlndXJhdGlvbi4KCiAgIG8gIE1QTFMtVFAgU0hPVUxEIHN1cHBvcnQg bWVjaGFuaXNtcyB3aGljaCBlbnN1cmUgdGhlIGludGVncml0eSBvZgogICAgICB0aGUgYWRh cHRlZCBpbmZvcm1hdGlvbi4KCiAgIG8gIE1QTFMtVFAgTVVTVCBzdXBwb3J0IGFuIHVuYW1i aWd1b3VzIGFuZCByZWxpYWJsZSBtZWFucyBvZgogICAgICBkaXN0aW5ndWlzaGluZyB1c2Vy cycgKGNsaWVudCkgcGFja2V0cyBmcm9tIE1QTFMtVFAgY29udHJvbCBwbGFuZQogICAgICBh bmQgbWFuYWdlbWVudCBwbGFuZSBwYWNrZXRzLgoKMi40LiAgQ29udHJvbCBwbGFuZSByZXF1 aXJlbWVudHMKCiAgIG8gIEEgZGlzdHJpYnV0ZWQgY29udHJvbCBwbGFuZSBNQVkgYmUgc3Vw cG9ydGVkIHRvIGVuYWJsZSBmYXN0LAogICAgICBkeW5hbWljIGFuZCByZWxpYWJsZSBzZXJ2 aWNlIHByb3Zpc2lvbmluZyBpbiBtdWx0aS12ZW5kb3IgYW5kCiAgICAgIG11bHRpLWRvbWFp biBlbnZpcm9ubWVudHMgdXNpbmcgc3RhbmRhcmRpemVkIHByb3RvY29scyB0aGF0CiAgICAg IGd1YXJhbnRlZSBpbnRlcm9wZXJhYmlsaXR5LgoKICAgbyAgSWYgYSBjb250cm9sIHBsYW5l IGlzIHVzZWQgZm9yIGNvbmZpZ3VyYXRpb24gb2YgTVBMUy1UUCB0cmFuc3BvcnQKICAgICAg cGF0aHMgdGhlbjoKCiAgICAgICogIEZhaWx1cmUgb2YgdGhlIGNvbnRyb2wgcGxhbmUgTVVT VCBOT1QgaW1wYWN0IHRoZSBNUExTLVRQIGRhdGEKICAgICAgICAgcGxhbmUuCgoKCk5pdmVu LUplbmtpbnMsIGV0IGFsLiAgICBFeHBpcmVzIEphbnVhcnkgMiwgMjAwOSAgICAgICAgICAg ICAgICBbUGFnZSA4XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgTVBMUy1UUCBSZXF1 aXJlbWVudHMgICAgICAgICAgICAgICAgIEp1bHkgMjAwOAoKCiAgICAgICogIFJlY292ZXJ5 IG9mIHRoZSBjb250cm9sIHBsYW5lIE1VU1QgTk9UIGltcGFjdCB0aGUgTVBMUy1UUCBkYXRh CiAgICAgICAgIHBsYW5lIGFueSBtb3JlIHRoYW4gaXMgbmVjZXNzYXJ5IHRvIHJlLWVzdGFi bGlzaCB0aGUgY29udHJvbAogICAgICAgICBwbGFuZS4KCiAgICAgICogIEl0IE1VU1Qgc3Vw cG9ydCB0aGUgc2V0dXAsIG1vZGlmaWNhdGlvbiwgYW5kIHJlbGVhc2Ugb2YgTVBMUy1UUAog ICAgICAgICB0cmFuc3BvcnQgcGF0aHMgYW5kIHByb3RlY3Rpb24gcGF0aHMuCgogICAgICAq ICBJdCBNVVNUIHN1cHBvcnQgbWVjaGFuaXNtcyB0byBwcm92aWRlIHRyYWZmaWMgZW5naW5l ZXJpbmcsCiAgICAgICAgIGNvbnN0cmFpbnQtYmFzZWQgcm91dGluZyBhbmQgZXhwbGljaXQg cGF0aCBjb250cm9sLgoKICAgICAgKiAgSXQgTVVTVCBwcm92aWRlIG1lY2hhbmlzbXMgdG8g YWRkcmVzcyBRb1MgYW5kIHBlcmZvcm1hbmNlCiAgICAgICAgIHJlcXVpcmVtZW50cyAoc3Vj aCBhcyB0aHJvdWdocHV0LCBkZWxheSwgcGFja2V0IGxvc3MsIGV0Yy4pCiAgICAgICAgIHdo aWxlIHV0aWxpemluZyBuZXR3b3JrIHJlc291cmNlcyBlZmZpY2llbnRseSBhbmQgcmVsaWFi bHkuCgogICBvICBNUExTLVRQIFNIT1VMRCBzdXBwb3J0IG9mZi1wYXRoIChvdXQtb2YtYmFu ZCkgY29udHJvbCBhbmQKICAgICAgbWFuYWdlbWVudCBwbGFuZXMuCgogICBvICBUaGUgTVBM Uy1UUCBjb250cm9sIHBsYW5lIE1VU1QgYmUgaW5kZXBlbmRlbnQgb2YgYW55IHBhcnRpY3Vs YXIKICAgICAgY2xpZW50IG9yIHNlcnZlciBsYXllciBjb250cm9sIHBsYW5lLgoKICAgbyAg VGhlIGNvbnRyb2wgcGxhbmUgU0hPVUxEIGZhY2lsaXRhdGUgdGhlIGltcGxlbWVudGF0aW9u IG9mIHRoZQogICAgICBzZXJ2aWNlIGJ5IHByb3ZpZGluZyBlbmQtdG8tZW5kIHNlYW1sZXNz IGNvbm5lY3Rpdml0eSBhbmQgc2VydmljZQogICAgICBhc3N1cmFuY2UuCgogICBvICBUaGUg TVBMUy1UUCBjb250cm9sIHBsYW5lIE1VU1Qgc3VwcG9ydCBlc3RhYmxpc2hpbmcgYWxsIHRo ZQogICAgICBjb25uZWN0aXZpdHkgcGF0dGVybnMgZGVmaW5lZCBmb3IgdGhlIE1QTFMtVFAg ZGF0YSBwbGFuZSAoZS5nLiwKICAgICAgdW5pLWRpcmVjdGlvbmFsIGFuZCBiaWRpcmVjdGlv bmFsIFAyUCwgdW5pLWRpcmVjdGlvbmFsIFAyTVAsIGV0Yy4pCiAgICAgIGluY2x1ZGluZyBj b25maWd1cmF0aW9uIG9mIHByb3RlY3Rpb24gZnVuY3Rpb25zIGFuZCBhbnkgYXNzb2NpYXRl ZAogICAgICBtYWludGVuYW5jZSBmdW5jdGlvbnMuCgogICBvICBUaGUgTVBMUy1UUCBjb250 cm9sIHBhbmUgbXVzdCBzdXBwb3J0IHRoZSBjb25maWd1cmF0aW9uIGFuZAogICAgICBtb2Rp ZmljYXRpb24gb2YgT0FNIG1haW50ZW5hbmNlIHBvaW50cyBhcyB3ZWxsIGFzIHRoZSBhY3Rp dmF0aW9uLwogICAgICBkZWFjdGl2YXRpb24gb2YgT0FNIHdoZW4gdGhlIHRyYW5zcG9ydCBw YXRoIGlzIGVzdGFibGlzaGVkIG9yCiAgICAgIG1vZGlmaWVkLgoKICAgbyAgQW4gTVBMUy1U UCBjb250cm9sIHBsYW5lIE1VU1Qgc3VwcG9ydCB0b3BvbG9neSBoaWRpbmcgYW5kIGFkZHJl c3MKICAgICAgaW5kZXBlbmRlbmNlIGJldHdlZW4gZG9tYWlucy4KCiAgIG8gIEF0IHRoZSBi b3VuZGFyeSBvZiBhIGRvbWFpbiBhbiBNUExTLVRQIGNvbnRyb2wgcGxhbmUgTVVTVCBzdXBw b3J0CiAgICAgIHVuaXF1ZSBuYW1lcyBvciBhZGRyZXNzZXMgaWRlbnRpZnlpbmcgYm91bmRh cnkgcG9pbnRzIHRvIGJlCiAgICAgIGludGVyY29ubmVjdGVkLgoKICAgbyAgQXQgdGhlIGJv dW5kYXJ5IG9mIGEgZG9tYWluIGFuIE1QTFMtVFAgY29udHJvbCBwbGFuZSBNVVNUIHN1cHBv cnQKICAgICAgZ3JvdXAgbmFtZXMgb3IgYWRkcmVzc2VzIGlkZW50aWZ5aW5nIHNldHMgb2Yg Ym91bmRhcnkgcG9pbnRzIHRvIGJlCiAgICAgIGludGVyY29ubmVjdGVkLgoKICAgbyAgTVBM Uy1UUCBsYXllciBuZXR3b3JrIGFjY2VzcyBwb2ludHMgKG9yIGNvbm5lY3Rpb24gcG9pbnRz IHRoYXQKICAgICAgcHJveHkgZm9yIGFjY2VzcyBwb2ludHMpIFNIT1VMRCBiZSBhYmxlIHRv IGJlIGFzc2lnbmVkIG5hbWVzIHdoaWNoCgoKCk5pdmVuLUplbmtpbnMsIGV0IGFsLiAgICBF eHBpcmVzIEphbnVhcnkgMiwgMjAwOSAgICAgICAgICAgICAgICBbUGFnZSA5XQoMCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgTVBMUy1UUCBSZXF1aXJlbWVudHMgICAgICAgICAgICAg ICAgIEp1bHkgMjAwOAoKCiAgICAgIGFyZSBhdmFpbGFibGUgdG8gY2xpZW50cyB0byBpZGVu dGlmeSBlbmRwb2ludHMgaW4gY2FsbCBvcgogICAgICBjb25uZWN0aW9uIHJlcXVlc3RzLgoK ICAgbyAgQW4gTVBMUy1UUCBjb250cm9sIHBsYW5lIE1VU1Qgc3VwcG9ydCB0cmFuc2xhdGlv biBiZXR3ZWVuCiAgICAgIGV4dGVybmFsbHkgdmlzaWJsZSBlbmRwb2ludCBuYW1lcyBhbmQg aW50ZXJuYWwgbmV0d29yayBhZGRyZXNzZXMuCgogICBvICBBbiBNUExTLVRQIGNvbnRyb2wg cGxhbmUgTVVTVCBzdXBwb3J0IGNvbnN0cmFpbnQtYmFzZWQgcm91dGUKICAgICAgY2FsY3Vs YXRpb24uCgogICBvICBBbiBNUExTLVRQIGNvbnRyb2wgcGxhbmUgTVVTVCBzdXBwb3J0IHBy b3Zpc2lvbmluZyBhbmQgYXBwbGljYXRpb24KICAgICAgb2Ygcm91dGluZyBjb25zdHJhaW50 IHBvbGljaWVzLgoKICAgbyAgQW4gTVBMUy1UUCBjb250cm9sIHBsYW5lIE1VU1Qgc3VwcG9y dCBwcmUtcHJvdmlzaW9uZWQgcGF0aAogICAgICBwcm90ZWN0aW9uLgoKICAgSW4gc29tZSBz aXR1YXRpb25zIGl0IGlzIGltcHJhY3RpY2FsIHRvIGV4cGVjdCBhY2NlcHRhYmxlIHJlY292 ZXJ5CiAgIHBlcmZvcm1hbmNlIHRvIGJlIGFjaGlldmVkIHVzaW5nIGR5bmFtaWMgcmVjYWxj dWxhdGlvbiBvZiB0cmFuc3BvcnQKICAgcGF0aCByb3V0ZXMuICBGb3IgdGhpcyByZWFzb24s IGl0IGlzIG5lY2Vzc2FyeSB0byBhbGxvdyBmb3IgcHJlLQogICBwbGFubmluZyBvZiBwcm90 ZWN0aW9uIHJvdXRlcyBmb3Igc2VsZWN0ZWQgdHJhbnNwb3J0IHBhdGhzLgoKICAgbyAgVGhl IE1QTFMtVFAgY29udHJvbCBwbGFuZSBNVVNUIHN1cHBvcnQgZmFzdCByZXN0b3JhdGlvbi4K CiAgIG8gIEFuIE1QTFMtVFAgY29udHJvbCBwbGFuZSBNVVNUIHNjYWxlIGdyYWNlZnVsbHkg dG8gc3VwcG9ydCBhIGxhcmdlCiAgICAgIG51bWJlciBvZiB0cmFuc3BvcnQgcGF0aHMuCgog ICBbSW5jbHVkZSBzb21lIG51bWJlcnMgdG8gaW5kaWNhdGUgaG93IGxhcmdlIHRoZSBDUCBp cyBleHBlY3RlZCB0bwogICBzY2FsZSB0bz9dCgogICBvICBBbiBNUExTLVRQIGNvbnRyb2wg cGxhbmUgTVVTVCBjbGVhcmx5IGRpc3Rpbmd1aXNoIHJlc291cmNlcwogICAgICBiZWxvbmdp bmcgdG8gdGhlIE1QTFMtVFAgbGF5ZXIgbmV0d29yayBmcm9tIHRob3NlIGluIG90aGVyIGxh eWVyCiAgICAgIG5ldHdvcmtzIHRoYXQgbWF5IGFsc28gYmUgdW5kZXIgY29udHJvbCBwbGFu ZSBjb250cm9sLgoKICAgbyAgQW4gTVBMUy1UUCBjb250cm9sIHBsYW5lIE1VU1Qgc3VwcG9y dCB0aGUgaW5kZXBlbmRlbnQKICAgICAgaWRlbnRpZmljYXRpb24gb2YgbG9naWNhbGx5IGRp c3RpbmN0IGNvbnRyb2wgcGxhbmUgZWxlbWVudHMuCgogICBvICBJdCBNVVNUIGJlIHBvc3Np YmxlIHRvIGlkZW50aWZ5IGFuZCBwcm92aXNpb24gdGhlc2UgZWxlbWVudHMKICAgICAgaW5k ZXBlbmRlbnRseSwgaW4gb3JkZXIgdG8gcmVvcmdhbml6ZSB0aGUgY29udHJvbCBwbGFuZSBj b21wb25lbnRzCiAgICAgIHdpdGhvdXQgaW1wYWN0aW5nIHRoZSBkYXRhIHBsYW5lIHNlcnZp Y2VzIGFuZCB2aWNlLXZlcnNhLgoKICAgQXJjaGl0ZWN0dXJhbGx5IGRpc3RpbmN0IGVsZW1l bnRzIGluIGEgY29udHJvbCBwbGFuZSBpbmNsdWRlOiBub2RlcwogICBhbmQgbGlua3MsIGNv bnRyb2wgcGxhbmUgZnVuY3Rpb25hbCBjb21wb25lbnRzLCBwcm90b2NvbCBjb250cm9sbGVy cywKICAgZXRjLgoKICAgbyAgQW4gTVBMUy1UUCBjb250cm9sIHBsYW5lIFNIT1VMRCBwcm92 aWRlIGEgY29tbW9uIGNvbnRyb2wgbWVjaGFuaXNtCiAgICAgIGZvciBhcmNoaXRlY3R1cmFs bHkgc2ltaWxhciBvcGVyYXRpb25zLgoKICAgbyAgQW4gTVBMUy1UUCBjb250cm9sIHBsYW5l IE1VU1Qgc3VwcG9ydCBtZWNoYW5pc21zIGZvciBwYXJ0aXRpb25pbmcKICAgICAgdGhlIG5l dHdvcmsgdW5kZXIgY29udHJvbCBpbnRvIHNlcGFyYXRlIHBlZXIgb3IgaGllcmFyY2hpY2Fs CgoKCk5pdmVuLUplbmtpbnMsIGV0IGFsLiAgICBFeHBpcmVzIEphbnVhcnkgMiwgMjAwOSAg ICAgICAgICAgICAgIFtQYWdlIDEwXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgTVBM Uy1UUCBSZXF1aXJlbWVudHMgICAgICAgICAgICAgICAgIEp1bHkgMjAwOAoKCiAgICAgIGNv bnRyb2wgZG9tYWlucy4KCiAgIG8gIFRvIGVuYWJsZSB0aGUgZGVwbG95bWVudCBvZiBhIHVu aWZpZWQgY29udHJvbCBwbGFuZSBhaW1lZCBhdAogICAgICBjb250cm9sbGluZyB0aGUgc2V0 IG9mIHRyYW5zcG9ydCB0ZWNobm9sb2dpZXMgdXNlZCBpbiBhIHRyYW5zcG9ydAogICAgICBu ZXR3b3JrLCB0aGUgTVBMUy1UUCBjb250cm9sIHBsYW5lIE1VU1QgYWxzbyBiZSBhcHBsaWNh YmxlIHRvCiAgICAgIG90aGVyIHRyYW5zcG9ydCBsYXllciBuZXR3b3JrcyBhbmQgcHJvdmlk ZSBjb21tb24gb3BlcmF0aW9ucwogICAgICBhY3Jvc3MgbXVsdGlwbGUgbGF5ZXJzLiAgSW4g b3JkZXIgdG8gbWFpbnRhaW4gaW5kZXBlbmRlbmNlIGJldHdlZW4KICAgICAgTVBMUy1UUCBh bmQgaXRzIHJlc3BlY3RpdmUgY2xpZW50IGFuZCBzZXJ2ZXIgbGF5ZXIgbmV0d29yawogICAg ICBzZXBhcmF0ZSBjb250cm9sIHBsYW5lIGluc3RhbmNlcyBTSE9VTEQgYmUgdXNlZCB0byBj b250cm9sIGEgc2V0CiAgICAgIG9mIHRyYW5zcG9ydCBsYXllciBuZXR3b3Jrcy4KCiAgIG8g IE1QTFMtVFAgU0hPVUxEIGRldGVjdCBhbmQgcmVjb3ZlciBmcm9tIGNvbnRyb2wgcGxhbmUg ZmFpbHVyZXMgYW5kCiAgICAgIGRlZ3JhZGF0aW9ucyB1c2luZyBncmFjZWZ1bCBvcGVyYXRp b25zLgoKMi41LiAgTmV0d29yayBNYW5hZ2VtZW50IChOTSkgcmVxdWlyZW1lbnRzCgogICBv ICBNUExTLVRQIE1VU1Qgb3BlcmF0ZSB1bmRlciBhIGNvbW1vbiBvcGVyYXRpb24sIGNvbnRy b2wgYW5kCiAgICAgIG1hbmFnZW1lbnQgcGFyYWRpZ20gd2l0aCByZXNwZWN0IHRvIG90aGVy IHRyYW5zcG9ydCB0ZWNobm9sb2dpZXMKICAgICAgKGUuZy4gIFNESCwgT1ROIG9yIFdETSku CgogICBvICBBbiBNUExTLVRQIG5ldHdvcmsgTVVTVCBiZSBhYmxlIHRvIGJlIG9wZXJhdGVk IHdpdGggYSBjZW50cmFsaXplZAogICAgICBOTVMgc3lzdGVtLgoKICAgbyAgQW4gTVBMUy1U UCBuZXR3b3JrIFNIT1VMRCBiZSBhYmxlIHRvIGJlIG9wZXJhdGVkIGJ5IGEgY2VudHJhbGl6 ZWQKICAgICAgTk1TIHN5c3RlbSB3aXRoIHRoZSBzdXBwb3J0IG9mIGEgZGlzdHJpYnV0ZWQg Y29udHJvbCBwbGFuZS4KCiAgIG8gIFRoZSBNUExTLVRQIG1hbmFnZW1lbnQgcGxhbmUgTVVT VCBiZSBpbmRlcGVuZGVudCBvZiBhbnkgcGFydGljdWxhcgogICAgICBjbGllbnQgb3Igc2Vy dmVyIGxheWVyIG1hbmFnZW1lbnQgcGxhbmUuCgogICBvICBUaGUgTVBMUy1UUCBtYW5hZ2Vt ZW50IHBsYW5lIE1VU1Qgc3VwcG9ydCB0aGUgY29uZmlndXJhdGlvbiBhbmQKICAgICAgbW9k aWZpY2F0aW9uIG9mIE9BTSBtYWludGVuYW5jZSBwb2ludHMgYXMgd2VsbCBhcyB0aGUgYWN0 aXZhdGlvbi8KICAgICAgZGVhY3RpdmF0aW9uIG9mIE9BTSB3aGVuIHRoZSB0cmFuc3BvcnQg cGF0aCBpcyBlc3RhYmxpc2hlZCBvcgogICAgICBtb2RpZmllZC4KCiAgIEZvciB0aGUgY29t cGxldGUgc2V0IG9mIHJlcXVpcmVtZW50cyByZWxhdGVkIHRvIE5NIGZ1bmN0aW9uYWxpdHkg Zm9yCiAgIE1QTFMtVFAsIHNlZSB0aGUgTVBMUy1UUCBOTSByZXF1aXJlbWVudHMgZG9jdW1l bnQgW1JFRl0uCgoyLjYuICBPQU0gcmVxdWlyZW1lbnRzCgogICBvICBNUExTLVRQIFNIT1VM RCBwcm92aWRlIGEgY29tcHJlaGVuc2l2ZSBzZXQgb2YgY2FwYWJpbGl0aWVzICh0aGF0CiAg ICAgIGFyZSBpbmRlcGVuZGVudCBvZiBhbmQgYWdub3N0aWMgdG8gdGhlIHRyYW5zbWl0dGVk IGNsaWVudAogICAgICBzZXJ2aWNlcykgdG8gc3VwcG9ydCBmYXVsdCBtYW5hZ2VtZW50LCBw ZXJmb3JtYW5jZSBtb25pdG9yaW5nIChvZgogICAgICB0aGUgTVBMUy1UUCBuZXR3b3JrIGFu ZCB0aGUgc2VydmljZXMpLCBwcm90ZWN0aW9uIHN3aXRjaGluZywgZmF1bHQKICAgICAgbG9j YWxpemF0aW9uLCBzaWduYWwgcXVhbGl0eSBtZWFzdXJlbWVudCwgZXRjLgoKICAgbyAgQSBt ZWNoYW5pc20gU0hPVUxEIGJlIHN1cHBvcnRlZCB0byBkZXRlY3QsIGRpYWdub3NlIGFuZCBl bmFibGUKICAgICAgcmVjb3ZlcnkgZnJvbSBmYWNpbGl0eSBhbmQgZXF1aXBtZW50IGZhaWx1 cmVzIGFuZCBwZXJmb3JtYW5jZQogICAgICBkZWdyYWRhdGlvbnMgYWNjb3JkaW5nIHRvIHRo ZSByZXF1aXJlbWVudHMgb2YgdGhlIHNlcnZpY2UuCgoKCk5pdmVuLUplbmtpbnMsIGV0IGFs LiAgICBFeHBpcmVzIEphbnVhcnkgMiwgMjAwOSAgICAgICAgICAgICAgIFtQYWdlIDExXQoM CkludGVybmV0LURyYWZ0ICAgICAgICAgICAgTVBMUy1UUCBSZXF1aXJlbWVudHMgICAgICAg ICAgICAgICAgIEp1bHkgMjAwOAoKCiAgIG8gIE1QTFMtVFAgT0FNIGFuZCBkYXRhIE1VU1Qg c2hhcmUgdGhlIHNhbWUgZmF0ZS4KCiAgIG8gIE1QTFMtVFAgT0FNIE1VU1QgYmUgYWJsZSB0 byBvcGVyYXRlIHdpdGhvdXQgSVAgZnVuY3Rpb25hbGl0eSBhbmQKICAgICAgd2l0aG91dCBy ZWx5aW5nIG9uIGNvbnRyb2wgYW5kL29yIG1hbmFnZW1lbnQgcGxhbmVzLiAgV2hlbiBNUExT LVRQCiAgICAgIGlzIHJ1biB3aXRoIElQIGZ1bmN0aW9uYWxpdHkgYWxsIGV4aXN0aW5nIElQ LU1QTFMgT0FNCiAgICAgIGZ1bmN0aW9uYWxpdHksIGUuZy4gIExTUC1QaW5nLCBCRkQgYW5k IFZDQ1YsIE1VU1QgYmUgYWJsZSB0bwogICAgICBvcGVyYXRlIHNlZW1sZXNzbHkuCgogICBG b3IgdGhlIGNvbXBsZXRlIHNldCBvZiByZXF1aXJlbWVudHMgcmVsYXRlZCB0byBPQU0gZnVu Y3Rpb25hbGl0eSBmb3IKICAgTVBMUy1UUCwgc2VlIHRoZSBNUExTLVRQIE9BTSByZXF1aXJl bWVudHMgZG9jdW1lbnQgW1JFRl0uCgoyLjcuICBOZXR3b3JrIHBlcmZvcm1hbmNlIG1hbmFn ZW1lbnQgKFBNKSByZXF1aXJlbWVudHMKCiAgIG8gIE1QTFMtVFAgTVVTVCBzdXBwb3J0IHRy YWZmaWMtZW5naW5lZXJpbmcgY2FwYWJpbGl0aWVzIHdpdGgKICAgICAgdHJhZmZpYy0gYW5k L29yIHJlc291cmNlLW9yaWVudGVkIHBlcmZvcm1hbmNlIG9iamVjdGl2ZXMuCgogICBvICBN UExTLVRQIE1VU1Qgc3VwcG9ydCBhIG1ldGhvZCB0byBvZmZlciBwYWNrZXQgbG9zcyBvYmpl Y3RpdmVzCiAgICAgIGNvbXBhcmFibGUgdG8gdGhvc2UgaW4gVERNIHRyYW5zcG9ydCBuZXR3 b3JrcyAob25seSBkdWUgdG8gYml0CiAgICAgIGVycm9ycykuCgogICBGb3IgdGhlIGNvbXBs ZXRlIHNldCBvZiByZXF1aXJlbWVudHMgcmVsYXRlZCB0byBQTSBmdW5jdGlvbmFsaXR5IGZv cgogICBNUExTLVRQLCBzZWUgdGhlIE1QTFMtVFAgT0FNIHJlcXVpcmVtZW50cyBkb2N1bWVu dCBbUkVGXS4KCjIuOC4gIFByb3RlY3Rpb24gJiBTdXJ2aXZhYmlsaXR5IHJlcXVpcmVtZW50 cwoKICAgTmV0d29yayBzdXJ2aXZhYmlsaXR5IHBsYXlzIGEgY3JpdGljYWwgZmFjdG9yIGlu IHRoZSBkZWxpdmVyeSBvZgogICByZWxpYWJsZSBzZXJ2aWNlcy4gIE5ldHdvcmsgYXZhaWxh YmlsaXR5IGlzIGEgc2lnbmlmaWNhbnQgY29udHJpYnV0b3IKICAgdG8gcmV2ZW51ZSBhbmQg cHJvZml0LiAgU2VydmljZSBndWFyYW50ZWVzIGluIHRoZSBmb3JtIG9mIFNMQXMKICAgcmVx dWlyZSBhIHJlc2lsaWVudCBuZXR3b3JrIHRoYXQgcmFwaWRseSBkZXRlY3RzIGZhY2lsaXR5 IG9yIG5vZGUKICAgZmFpbHVyZXMgYW5kIHJlc3RvcmVzIG5ldHdvcmsgb3BlcmF0aW9uIGlu IGFjY29yZGFuY2Ugd2l0aCB0aGUgdGVybXMKICAgb2YgdGhlIFNMQS4KCiAgIFRoZSByZXF1 aXJlbWVudHMgaW4gdGhpcyBzZWN0aW9uIHVzZSBvZiB0aGUgcmVjb3ZlcnkgdGVybWlub2xv Z3kKICAgZGVmaW5lZCBpbiBSRkMgNDQyN1tSRkM0NDI3XS4KCiAgIG8gIE1QTFMtVFAgTVVT VCBzdXBwb3J0IHRyYW5zcG9ydCBuZXR3b3JrIHN0eWxlIHByb3RlY3Rpb24gc3dpdGNoaW5n CiAgICAgIG1lY2hhbmlzbXMgKHRhbmRlbSBuZXR3b3JrIGNvbm5lY3Rpb24gcHJvdGVjdGlv biwgTFNQIHByb3RlY3Rpb24KICAgICAgYW5kIFBXIHByb3RlY3Rpb24pIHRvIHByb3ZpZGUg dGhlIHN1Yi01MG1zIHJlY292ZXJ5IHRpbWUgcmVxdWlyZWQKICAgICAgdG8gbWFpbnRhaW4g Y3VzdG9tZXIgdHJhbnNwYXJlbmN5LCBldmVuIHdoZW4gdGhvdXNhbmRzIG9mIHNlcnZpY2Vz CiAgICAgIGFyZSBzaW11bHRhbmVvdXNseSBhZmZlY3RlZCBieSBhIGZhaWx1cmUuICBbSXMg c3ViLTUwbXMgcmVhbGx5IGEKICAgICAgcmVxdWlyZW1lbnQsIGRvIHdlIHdhbnQgdG8gY2xh cmlmeSB0aGlzIGZ1cnRoZXIgLSBpcyBpdCBzdWItNTBtcwogICAgICBlbmQgdG8gZW5kLCBv ciBwZXIgbGluaz9dCgogICBvICBNUExTLVRQIHJlY292ZXJ5IG1lY2hhbmlzbXMgU0hPVUxE IGJlIGFwcGxpY2FibGUgYXQgdmFyaW91cyBsZXZlbHMKICAgICAgdGhyb3VnaG91dCB0aGUg bmV0d29yayBpbmNsdWRpbmcgc3VwcG9ydCBmb3Igc3BhbiwgdGFuZGVtCiAgICAgIGNvbm5l Y3Rpb24gYW5kIGVuZC10by1lbmQgcmVjb3ZlcnkuICBBbnkgcmVjb3ZlcnkgbWVjaGFuaXNt IHVzZWQKICAgICAgaW4gYSB0YW5kZW0gY29ubmVjdGlvbiBNVVNUIGJlIGluZGVwZW5kZW50 IG9mIG90aGVyIHRhbmRlbQogICAgICBjb25uZWN0aW9ucy4KCgoKTml2ZW4tSmVua2lucywg ZXQgYWwuICAgIEV4cGlyZXMgSmFudWFyeSAyLCAyMDA5ICAgICAgICAgICAgICAgW1BhZ2Ug MTJdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICBNUExTLVRQIFJlcXVpcmVtZW50cyAg ICAgICAgICAgICAgICAgSnVseSAyMDA4CgoKICAgbyAgTVBMUy1UUCBNVVNUIHN1cHBvcnQg bWVjaGFuaXNtcyB0aGF0IGtlZXAgdHJhZmZpYyBmbG93aW5nIHdoaWxlCiAgICAgIHRoZSBu ZXR3b3JrIHJlY292ZXJzIGZyb20gZmFpbHVyZXMuCgogICBvICBNUExTLVRQIE1VU1Qgc3Vw cG9ydCBuZXR3b3JrIHJlc3RvcmF0aW9uIG1lY2hhbmlzbXMgY29udHJvbGxlZCBieQogICAg ICBhIGRpc3RyaWJ1dGVkIGNvbnRyb2wgcGxhbmUgYW5kIE1VU1Qgc3VwcG9ydCBuZXR3b3Jr IHJlc3RvcmF0aW9uCiAgICAgIG1lY2hhbmlzbXMgY29udHJvbGxlZCBieSBhIG1hbmFnZW1l bnQgcGxhbmUuCgogICAgICAqICBUaGUgcmVzdG9yYXRpb24gcmVzb3VyY2VzIE1BWSBiZSBw cmUtcGxhbm5lZCBhbmQgc2VsZWN0ZWQgYQogICAgICAgICBwcmlvcmksIG9yIGNvbXB1dGVk IGFmdGVyIGZhaWx1cmUgb2NjdXJyZW5jZS4KCiAgICAgICogIE1QTFMtVFAgTUFZIHN1cHBv cnQgc2hhcmVkLW1lc2ggcmVzdG9yYXRpb24uCgogICAgICAqICBNUExTLVRQIFNIT1VMRCBz dXBwb3J0IHNvZnQgTFNQIHJlc3RvcmF0aW9uLgoKICAgICAgKiAgTVBMUy1UUCBNQVkgc3Vw cG9ydCBoYXJkIExTUCByZXN0b3JhdGlvbi4KCiAgICAgICogIFRoZSByZXN0b3JhdGlvbiBt ZWNoYW5pc20gTVVTVCBiZSBhcHBsaWNhYmxlIHRvIGFueSB0b3BvbG9neS4KCiAgICAgICog IFJlc3RvcmF0aW9uIHByaW9yaXR5IE1BWSBiZSBpbXBsZW1lbnRlZCB0byBkZXRlcm1pbmUg dGhlIG9yZGVyCiAgICAgICAgIGluIHdoaWNoIHRyYW5zcG9ydCBwYXRocyBzaG91bGQgYmUg cmVzdG9yZWQgKHRvIG1pbmltaXplCiAgICAgICAgIHNlcnZpY2UgcmVzdG9yYXRpb24gdGlt ZSBhcyB3ZWxsIGFzIHRvIGdhaW4gYWNjZXNzIHRvIGF2YWlsYWJsZQogICAgICAgICBzcGFy ZSBjYXBhY2l0eSBvbiB0aGUgYmVzdCBwYXRocykuICBQcmVlbXB0aW9uIHByaW9yaXR5IE1B WSBiZQogICAgICAgICB1c2VkIGluIHRoZSBldmVudCB0aGF0IG5vdCBhbGwgdHJhbnNwb3J0 IHBhdGhzIGNhbiBiZSByZXN0b3JlZCwKICAgICAgICAgaW4gd2hpY2ggY2FzZSB0cmFuc3Bv cnQgcGF0aHMgd2l0aCBsb3dlciBwcmVlbXB0aW9uIHByaW9yaXR5CiAgICAgICAgIHNob3Vs ZCBiZSByZWxlYXNlZC4KCiAgICAgICogIFRoZSByZXN0b3JhdGlvbiBtZWNoYW5pc20gU0hP VUxEIG9wZXJhdGUgaW4gc3luZXJneSB3aXRoIG90aGVyCiAgICAgICAgIHRyYW5zcG9ydCBu ZXR3b3JrIHRlY2hub2xvZ2llcyAoU0RILCBPVE4sIFdETSkuCgogICBvICBNUExTLVRQIFNI T1VMRCBzdXBwb3J0IGRhdGEgcGxhbmUgZHJpdmVuIHByb3RlY3Rpb24gbWVjaGFuaXNtcwog ICAgICAod2l0aG91dCBhbnkgZGVwZW5kZW5jeSBvbiBhIGNvbnRyb2wgcGxhbmUgb3IgSVAg cHJvdG9jb2xzKSB0bwogICAgICBlbmFibGUgZmFzdCByZWNvdmVyeSBmcm9tIGZhaWx1cmUs IGFuZCB0aGVyZWJ5IHRvIGVuaGFuY2UgdGhlCiAgICAgIHJlbGlhYmlsaXR5IGFuZCBhdmFp bGFiaWxpdHkgcGVyZm9ybWFuY2Ugb2YgTVBMUy1UUCBuZXR3b3Jrcy4KCiAgIG8gIElmIHBy b3RlY3Rpb24gaXMgc3VwcG9ydGVkIHRoZW46CgogICAgICAqICBNUExTLVRQIHByb3RlY3Rp b24gbWVjaGFuaXNtcyBTSE9VTEQgYmUgYXBwbGllZCB0byBMU1BzIGFuZAogICAgICAgICBQ V3MuCgogICAgICAqICBNUExTLVRQIE1VU1Qgc3VwcG9ydCBtZWNoYW5pc21zIHRoYXQgcmFw aWRseSBkZXRlY3QsIGxvY2F0ZSwKICAgICAgICAgbm90aWZ5IGFuZCByZW1lZHkgbmV0d29y ayBmYXVsdHMuCgogICAgICAqICBNUExTLVRQIE1VU1Qgc3VwcG9ydCAxOjEgYmlkaXJlY3Rp b25hbCBwcm90ZWN0aW9uIHN3aXRjaGluZy4KICAgICAgICAgSWYgYmktZGlyZWN0aW9uYWwg MToxIHByb3RlY3Rpb24gc3dpdGNoaW5nIGlzIGFjdGl2YXRlZCB0aGVuCiAgICAgICAgIHRo ZSBwcm90ZWN0aW9uIHN0YXRlIG9mIGJvdGggZW5kcyBvZiB0aGUgcHJvdGVjdGVkIGVudGl0 eSBNVVNUCiAgICAgICAgIGJlIHN5bmNocm9uaXplZC4KCgoKCgpOaXZlbi1KZW5raW5zLCBl dCBhbC4gICAgRXhwaXJlcyBKYW51YXJ5IDIsIDIwMDkgICAgICAgICAgICAgICBbUGFnZSAx M10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIE1QTFMtVFAgUmVxdWlyZW1lbnRzICAg ICAgICAgICAgICAgICBKdWx5IDIwMDgKCgogICAgICAqICBNUExTLVRQIE1BWSBzdXBwb3J0 IDErMSB1bmlkaXJlY3Rpb25hbCBwcm90ZWN0aW9uIHN3aXRjaGluZy4KCiAgICAgICogIE1Q TFMtVFAgcHJvdGVjdGlvbiBtZWNoYW5pc21zIE1VU1QgYmUgYXBwbGljYWJsZSB0byBib3Ro IHBvaW50LQogICAgICAgICB0by1wb2ludCBhbmQgTUFZIGJlIGFwcGxpY2FibGUgdG8gcG9p bnQtdG8tbXVsdGlwb2ludCB0cmFuc3BvcnQKICAgICAgICAgcGF0aHMuCgogICAgICAqICBQ cm90ZWN0aW9uIHJhdGlvIE1VU1QgYmUgb2YgMTAwJSwgaS5lLiwgMTAwJSBvZiBpbXBhaXJl ZAogICAgICAgICB3b3JraW5nIHRyYWZmaWMgTVVTVCBiZSBwcm90ZWN0ZWQgZm9yIGEgZmFp bHVyZSBvbiBhIHNpbmdsZQogICAgICAgICB3b3JraW5nIExTUC4KCiAgICAgICogIE9wZXJh dG9yIHJlcXVlc3RzIGZvciBtYW51YWwgY29udHJvbCBvZiBwcm90ZWN0aW9uIHN3aXRjaGlu ZwogICAgICAgICBzdWNoIGFzIGNsZWFyLCBsb2Nrb3V0IG9mIHByb3RlY3Rpb24sIGZvcmNl ZC1zd2l0Y2ggYW5kIG1hbnVhbC0KICAgICAgICAgc3dpdGNoIGNvbW1hbmRzIE1VU1QgYmUg c3VwcG9ydGVkLiAgUHJpb3JpdGl6ZWQgcHJvdGVjdGlvbgogICAgICAgICBiZXR3ZWVuIFNp Z25hbCBGYWlsIChTRiksIFNpZ25hbCBEZWdyYWRhdGlvbiAoU0QpIGFuZCBvcGVyYXRvcgog ICAgICAgICBzd2l0Y2ggcmVxdWVzdHMgTVVTVCBiZSBzdXBwb3J0ZWQuCgogICAgICAqICBN UExTLVRQIHByb3RlY3Rpb24gbWVjaGFuaXNtcyBNVVNUIHN1cHBvcnQgcmV2ZXJ0aXZlIGFu ZCBub24tCiAgICAgICAgIHJldmVydGl2ZSBiZWhhdmlvdXIuIG8gQW4gZXh0cmEgdHJhZmZp YyBjYXBhYmlsaXR5IFNIT1VMRCBiZQogICAgICAgICBzdXBwb3J0ZWQgd2hlbiBwb3NzaWJs ZS4KCiAgICAgICogIE1QTFMtVFAgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgbWVjaGFuaXNtcyBN VVNUIHByZXZlbnQgZnJlcXVlbnQKICAgICAgICAgb3BlcmF0aW9uIG9mIHRoZSBwcm90ZWN0 aW9uIHN3aXRjaCBkdWUgdG8gYW4gaW50ZXJtaXR0ZW50CiAgICAgICAgIGRlZmVjdC4KCiAg ICAgICogIE1QTFMtVFAgcHJvdGVjdGlvbiBtZWNoYW5pc21zIE1VU1QgZW5zdXJlIGNvLW9y ZGluYXRpb24gb2YKICAgICAgICAgdGltaW5nIG9mIHByb3RlY3Rpb24gc3dpdGNoZXMgYXQg bXVsdGlwbGUgbGF5ZXJzIHRvIGF2b2lkIHJhY2VzCiAgICAgICAgIGFuZCB0byBhbGxvdyB0 aGUgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgbWVjaGFuaXNtIG9mIHRoZSBzZXJ2ZXIKICAgICAg ICAgbGF5ZXIgdG8gZml4IHRoZSBwcm9ibGVtIGJlZm9yZSBzd2l0Y2hpbmcgYXQgdGhlIE1Q TFMtVFAgbGF5ZXIuCgogICAgICAqICBNUExTLVRQIE1BWSBzdXBwb3J0IG1lY2hhbmlzbXMg dGhhdCBhcmUgb3B0aW1pemVkIGZvciBzcGVjaWZpYwogICAgICAgICBuZXR3b3JrIHRvcG9s b2dpZXMgKFJpbmcsIE1lc2gpIGluIG9yZGVyIHRvIGhhbmRsZSBwcm90ZWN0aW9uCiAgICAg ICAgIHN3aXRjaGluZyBpbiBhIGNvc3QtZWZmaWNpZW50IG1hbm5lci4KCjIuOS4gIFFvUyBy ZXF1aXJlbWVudHMKCiAgIFNlcnZpY2UgcHJvdmlkZXJzIHJlcXVpcmUgYWR2YW5jZWQgdHJh ZmZpYyBtYW5hZ2VtZW50IGNhcGFiaWxpdGllcyB0bwogICBlbmZvcmNlIGFuZCBndWFyYW50 ZWUgdGhlIFFvUyBwYXJhbWV0ZXJzIG9mIGN1c3RvbWVycycgU0xBcy4KCiAgIFF1YWxpdHkg b2Ygc2VydmljZSBtZWNoYW5pc21zIGFyZSByZXF1aXJlZCB0byBlbnN1cmU6CgogICBvICBT dXBwb3J0IGZvciBkaWZmZXJlbnRpYXRlZCBzZXJ2aWNlcyBhbmQgZGlmZmVyZW50IHRyYWZm aWMgdHlwZXMKICAgICAgd2l0aCB0cmFmZmljIGNsYXNzIHNlcGFyYXRpb24gYXNzb2NpYXRl ZCB3aXRoIGRpZmZlcmVudCB0cmFmZmljLgoKICAgbyAgUHJpb3JpdGl6YXRpb24gb2YgY3Jp dGljYWwgc2VydmljZXMuCgogICBvICBFbmFibGluZyB0aGUgcHJvdmlzaW9uaW5nIGFuZCB0 aGUgZ3VhcmFudGVlIG9mIFNlcnZpY2UgTGV2ZWwKICAgICAgU3BlY2lmaWNhdGlvbnMgKFNM UyksIHdpdGggc3VwcG9ydCBmb3IgaGFyZCBhbmQgcmVsYXRpdmUgZW5kLXRvLQogICAgICBl bmQgQlcgZ3VhcmFudGVlZC4KCgoKTml2ZW4tSmVua2lucywgZXQgYWwuICAgIEV4cGlyZXMg SmFudWFyeSAyLCAyMDA5ICAgICAgICAgICAgICAgW1BhZ2UgMTRdCgwKSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICBNUExTLVRQIFJlcXVpcmVtZW50cyAgICAgICAgICAgICAgICAgSnVs eSAyMDA4CgoKICAgbyAgQ29udHJvbGxlZCBqaXR0ZXIgYW5kIGRlbGF5LgoKICAgbyAgR3Vh cmFudGVlIG9mIGZhaXIgYWNjZXNzIHRvIHNoYXJlZCByZXNvdXJjZXMgaW4gYW4gTVBMUy1U UAogICAgICBuZXR3b3JrLgoKICAgbyAgUmVzb3VyY2VzIGZvciBjb250cm9sIGFuZCBtYW5h Z2VtZW50IHBsYW5lIHBhY2tldHMgc28gdGhhdCBkYXRhCiAgICAgIHBsYW5lIHRyYWZmaWMs IHJlZ2FyZGxlc3Mgb2YgdGhlIGFtb3VudCwgd2lsbCBub3QgY2F1c2UgY29udHJvbAogICAg ICBhbmQgbWFuYWdlbWVudCBmdW5jdGlvbnMgdG8gYmVjb21lIGlub3BlcmF0aXZlLgoKICAg TVBMUy1UUCBNVVNUOgoKICAgbyAgQmUgYWJsZSB0byBkZWxpdmVyIHRoZSBzYW1lIGRlZ3Jl ZSBvZiBRb1MgdGhhdCBoYXMgYmVlbiBkZWxpdmVyZWQKICAgICAgYnkgU0RIL1NPTkVUIHN5 c3RlbXMuCgogICBvICBTdXBwb3J0IHRyYW5zcG9ydCBiYW5kd2lkdGggYWxsb2NhdGlvbiB0 byBhbnkgZ3JhbnVsYXJpdHkgd2l0aG91dAogICAgICBhbnkgcmVzdHJpY3Rpb25zIGJhc2Vk IG9uIGEgY2lyY3VpdC1zd2l0Y2hlZCBtdWx0aXBsZXhpbmcKICAgICAgaGllcmFyY2h5LiAg VGhpcyBhdHRyaWJ1dGUgd2lsbCBwcm92aWRlIHNlcnZpY2UgcHJvdmlkZXJzIHdpdGggdGhl CiAgICAgIGNhcGFiaWxpdHkgdG8gcm91dGUgbW9yZSBjdXN0b21lciBzZXJ2aWNlIGRlbWFu ZHMgb3ZlciB0aGUgTVBMUy1UUAogICAgICBuZXR3b3JrLgoKICAgW1Nob3VsZCB3ZSByZWZl ciBoZXJlIHRvIHRoZSByZXF1aXJlbWVudHMgc3BlY2lmaWVkIGluIFJGQyAyNzAyP10KCjIu MTAuICBTZWN1cml0eSByZXF1aXJlbWVudHMKCiAgIG8gIE1QTFMtVFAgTVVTVCBlbnN1cmUg dGhhdCB0aGUgbmV0d29yayBhbmQgc2VydmljZXMgYXJlIHNlY3VyZWQuCgogICBvICBUcmFm ZmljIGZsb3dzIGZyb20gZGlmZmVyZW50IHVzZXJzIE1VU1QgTk9UIGJlIGludGVybWluZ2xl ZCwgYnV0CiAgICAgIGlmIHRoaXMgZG9lcyBvY2N1ciB0aGVuIHRoaXMgTVVTVCBiZSBkZXRl Y3RhYmxlIGFuZCB0aGUKICAgICAgYXBwcm9wcmlhdGUgY29uc2VxdWVudCBhY3Rpb25zIHRh a2VuLgoKICAgbyAgTVBMUy1UUCBNVVNUIGVuc3VyZSB0aGUgc2VwYXJhdGlvbiBvZiBjdXN0 b21lciAoY2xpZW50KSBhbmQKICAgICAgcHJvdmlkZXIgKHNlcnZlciBhbmQgcGVlciBuZXR3 b3JrKSBhZGRyZXNzaW5nIGFuZCBvdGhlcgogICAgICBpbmZvcm1hdGlvbi4KCiAgIG8gIE1Q TFMtVFAgTVVTVCBlbnN1cmUgdGhhdCB0aGUgY29udHJvbCBhbmQgbWFuYWdlbWVudCBwbGFu ZXMgYXMgd2VsbAogICAgICBhcyBPQU0gdHJhZmZpYyBhcmUgc2VjdXJlIGZyb20gZXh0ZXJu YWwgYXR0YWNrLgoKICAgbyAgTVBMUy1UUCBNVVNUIHByb3ZpZGUgbWVjaGFuaXNtcyB0byBl bnN1cmUgdGhhdCB0aGUgTVBMUy1UUCBuZXR3b3JrCiAgICAgIHJlbWFpbnMgc2VjdXJlIGFu ZCBzdGFibGUgdW5kZXIgc2l0dWF0aW9ucyBvZiBleHRyZW1lIHN0cmVzcy4KCiAgIEV4YW1w bGVzIG9mIGF0dGFja3MgYW5kIHNpdHVhdGlvbnMgb2YgZXh0cmVtZSBzdHJlc3MgaW5jbHVk ZSAoYnV0IGFyZQogICBub3QgbGltaXRlZCB0bykgY2xhc3NpY2FsIHNlY3VyaXR5IGF0dGFj a3MgKGUuZy4sIGhpamFja2luZywgcHJpdmFjeSwKICAgbm9uLXJlcHVkaWF0aW9uLCBldGMu KSBhbmQgYXR0YWNrcyBvbiBuZXR3b3JrIGF2YWlsYWJpbGl0eSAoZS5nLiwKICAgZGVuaWFs IG9mIHNlcnZpY2UgKERvUykgYXR0YWNrcykuCgoKCgoKCgpOaXZlbi1KZW5raW5zLCBldCBh bC4gICAgRXhwaXJlcyBKYW51YXJ5IDIsIDIwMDkgICAgICAgICAgICAgICBbUGFnZSAxNV0K DApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIE1QTFMtVFAgUmVxdWlyZW1lbnRzICAgICAg ICAgICAgICAgICBKdWx5IDIwMDgKCgozLiAgSUFOQSBDb25zaWRlcmF0aW9ucwoKICAgVGhp cyBkb2N1bWVudCBtYWtlcyBubyByZXF1ZXN0IG9mIElBTkEuCgogICBOb3RlIHRvIFJGQyBF ZGl0b3I6IHRoaXMgc2VjdGlvbiBtYXkgYmUgcmVtb3ZlZCBvbiBwdWJsaWNhdGlvbiBhcyBh bgogICBSRkMuCgoKNC4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zCgogICBUaGlzIGRvY3Vt ZW50IGRvZXMgbm90IGJ5IGl0c2VsZiByYWlzZSBhbnkgcGFydGljdWxhciBzZWN1cml0eQog ICBjb25zaWRlcmF0aW9ucy4KCgo1LiAgQWNrbm93bGVkZ2VtZW50cwoKICAgVGhlIGF1dGhv cnMgd2lzaCB0byB0aGFuayBOZWlsIEhhcnJpc29uLCBUb20gTmFkZWF1LCBIaXJvc2hpIE9o dGEgYW5kCiAgIFRvbW9ub3JpIFRha2VkYSBmb3IgdGhlaXIgcmV2aWV3IGFuZCBlbmhhbmNl bWVudHMgdG8gdGhlIHRleHQuCgoKNi4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMKCiAgIFtS RkMyMTE5XSAgQnJhZG5lciwgUy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIElu ZGljYXRlCiAgICAgICAgICAgICAgUmVxdWlyZW1lbnQgTGV2ZWxzIiwgQkNQIDE0LCBSRkMg MjExOSwgTWFyY2ggMTk5Ny4KCiAgIFtSRkM0NDI3XSAgTWFubmllLCBFLiBhbmQgRC4gUGFw YWRpbWl0cmlvdSwgIlJlY292ZXJ5IChQcm90ZWN0aW9uIGFuZAogICAgICAgICAgICAgIFJl c3RvcmF0aW9uKSBUZXJtaW5vbG9neSBmb3IgR2VuZXJhbGl6ZWQgTXVsdGktUHJvdG9jb2wK ICAgICAgICAgICAgICBMYWJlbCBTd2l0Y2hpbmcgKEdNUExTKSIsIFJGQyA0NDI3LCBNYXJj aCAyMDA2LgoKICAgW1JGQzMwMzFdICBSb3NlbiwgRS4sIFZpc3dhbmF0aGFuLCBBLiwgYW5k IFIuIENhbGxvbiwgIk11bHRpcHJvdG9jb2wKICAgICAgICAgICAgICBMYWJlbCBTd2l0Y2hp bmcgQXJjaGl0ZWN0dXJlIiwgUkZDIDMwMzEsIEphbnVhcnkgMjAwMS4KCiAgIFtSRkMzOTg1 XSAgQnJ5YW50LCBTLiBhbmQgUC4gUGF0ZSwgIlBzZXVkbyBXaXJlIEVtdWxhdGlvbiBFZGdl LXRvLQogICAgICAgICAgICAgIEVkZ2UgKFBXRTMpIEFyY2hpdGVjdHVyZSIsIFJGQyAzOTg1 LCBNYXJjaCAyMDA1LgoKICAgW0lUVS5ZMTQwMS4yMDA4XQogICAgICAgICAgICAgIEludGVy bmF0aW9uYWwgVGVsZWNvbW11bmljYXRpb25zIFVuaW9uLCAiUHJpbmNpcGxlcyBvZgogICAg ICAgICAgICAgIGludGVyd29ya2luZyIsIElUVS1UIFJlY29tbWVuZGF0aW9uIFkuMTQwMSwg RmVicnVhcnkgMjAwOC4KCiAgIFtJVFUuRzgwMC4yMDA3XQogICAgICAgICAgICAgIEludGVy bmF0aW9uYWwgVGVsZWNvbW11bmljYXRpb25zIFVuaW9uLCAiVW5pZmllZAogICAgICAgICAg ICAgIGZ1bmN0aW9uYWwgYXJjaGl0ZWN0dXJlIG9mIHRyYW5zcG9ydCBuZXR3b3JrcyIsIElU VS0KICAgICAgICAgICAgICBUIFJlY29tbWVuZGF0aW9uIEcuODAwLCBTZXB0ZW1iZXIgMjAw Ny4KCgoKCgoKCgpOaXZlbi1KZW5raW5zLCBldCBhbC4gICAgRXhwaXJlcyBKYW51YXJ5IDIs IDIwMDkgICAgICAgICAgICAgICBbUGFnZSAxNl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgIE1QTFMtVFAgUmVxdWlyZW1lbnRzICAgICAgICAgICAgICAgICBKdWx5IDIwMDgKCgpB dXRob3JzJyBBZGRyZXNzZXMKCiAgIEJlbiBO aXZlbi1KZW5raW5zIChlZGl0b3IpCiAgIEJU CiAgIDIwOCBDYWxsaXN0byBIb3VzZSwgQWRhc3RyYWwgUGFyawogICBJcHN3aWNoLCBTdWZm b2xrICBJUDUgM1JFCiAgIFVLCgogICBFbWFpbDogYmVuamFtaW4ubml2ZW4tamVua2luc0Bi dC5jb20KCgogICBEZWJvcmFoIEJydW5nYXJkIChlZGl0b3IpCiAgIEFUJlQKICAgUm0uIEQx LTNDMjIgLSAyMDAgUy4gTGF1cmVsIEF2ZS4KICAgTWlkZGxldG93biwgTkogIDA3NzQ4CiAg IFVTQQoKICAgRW1haWw6IGRicnVuZ2FyZEBhdHQuY29tCgoKICAgTWFsY29sbSBCZXR0cyAo ZWRpdG9yKQogICBOb3J0ZWwgTmV0d29ya3MKICAgMzUwMCBDYXJsaW5nIEF2ZW51ZQogICBP dHRhd2EsIE9udGFyaW8gIEsySCA4RTkKICAgQ2FuYWRhCgogICBFbWFpbDogYmV0dHMwMUBu b3J0ZWwuY29tCgoKICAgTnVyaXQgU3ByZWNoZXIKICAgTm9raWEgU2llbWVucyBOZXR3b3Jr cwogICAzIEhhbmFnYXIgU3QuIE5ldmUgTmUnZW1hbiBCCiAgIEhvZCBIYXNoYXJvbiwgICA0 NTI0MQogICBJc3JhZWwKCiAgIEVtYWlsOiBudXJpdC5zcHJlY2hlckBuc24uY29tCgoKCgoK CgoKCgoKCgoKCk5pdmVuLUplbmtpbnMsIGV0IGFsLiAgICBFeHBpcmVzIEphbnVhcnkgMiwg MjAwOSAgICAgICAgICAgICAgIFtQYWdlIDE3XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAg ICAgTVBMUy1UUCBSZXF1aXJlbWVudHMgICAgICAgICAgICAgICAgIEp1bHkgMjAwOAoKCkZ1 bGwgQ29weXJpZ2h0IFN0YXRlbWVudAoKICAgQ29weXJpZ2h0IChDKSBUaGUgSUVURiBUcnVz dCAoMjAwOCkuCgogICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gdGhlIHJpZ2h0cywg bGljZW5zZXMgYW5kIHJlc3RyaWN0aW9ucwogICBjb250YWluZWQgaW4gQkNQIDc4LCBhbmQg ZXhjZXB0IGFzIHNldCBmb3J0aCB0aGVyZWluLCB0aGUgYXV0aG9ycwogICByZXRhaW4gYWxs IHRoZWlyIHJpZ2h0cy4KCiAgIFRoaXMgZG9jdW1lbnQgYW5kIHRoZSBpbmZvcm1hdGlvbiBj b250YWluZWQgaGVyZWluIGFyZSBwcm92aWRlZCBvbiBhbgogICAiQVMgSVMiIGJhc2lzIGFu ZCBUSEUgQ09OVFJJQlVUT1IsIFRIRSBPUkdBTklaQVRJT04gSEUvU0hFIFJFUFJFU0VOVFMK ICAgT1IgSVMgU1BPTlNPUkVEIEJZIChJRiBBTlkpLCBUSEUgSU5URVJORVQgU09DSUVUWSwg VEhFIElFVEYgVFJVU1QgQU5ECiAgIFRIRSBJTlRFUk5FVCBFTkdJTkVFUklORyBUQVNLIEZP UkNFIERJU0NMQUlNIEFMTCBXQVJSQU5USUVTLCBFWFBSRVNTCiAgIE9SIElNUExJRUQsIElO Q0xVRElORyBCVVQgTk9UIExJTUlURUQgVE8gQU5ZIFdBUlJBTlRZIFRIQVQgVEhFIFVTRSBP RgogICBUSEUgSU5GT1JNQVRJT04gSEVSRUlOIFdJTEwgTk9UIElORlJJTkdFIEFOWSBSSUdI VFMgT1IgQU5ZIElNUExJRUQKICAgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgT1Ig RklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuCgoKSW50ZWxsZWN0dWFsIFByb3Bl cnR5CgogICBUaGUgSUVURiB0YWtlcyBubyBwb3NpdGlvbiByZWdhcmRpbmcgdGhlIHZhbGlk aXR5IG9yIHNjb3BlIG9mIGFueQogICBJbnRlbGxlY3R1YWwgUHJvcGVydHkgUmlnaHRzIG9y IG90aGVyIHJpZ2h0cyB0aGF0IG1pZ2h0IGJlIGNsYWltZWQgdG8KICAgcGVydGFpbiB0byB0 aGUgaW1wbGVtZW50YXRpb24gb3IgdXNlIG9mIHRoZSB0ZWNobm9sb2d5IGRlc2NyaWJlZCBp bgogICB0aGlzIGRvY3VtZW50IG9yIHRoZSBleHRlbnQgdG8gd2hpY2ggYW55IGxpY2Vuc2Ug dW5kZXIgc3VjaCByaWdodHMKICAgbWlnaHQgb3IgbWlnaHQgbm90IGJlIGF2YWlsYWJsZTsg bm9yIGRvZXMgaXQgcmVwcmVzZW50IHRoYXQgaXQgaGFzCiAgIG1hZGUgYW55IGluZGVwZW5k ZW50IGVmZm9ydCB0byBpZGVudGlmeSBhbnkgc3VjaCByaWdodHMuICBJbmZvcm1hdGlvbgog ICBvbiB0aGUgcHJvY2VkdXJlcyB3aXRoIHJlc3BlY3QgdG8gcmlnaHRzIGluIFJGQyBkb2N1 bWVudHMgY2FuIGJlCiAgIGZvdW5kIGluIEJDUCA3OCBhbmQgQkNQIDc5LgoKICAgQ29waWVz IG9mIElQUiBkaXNjbG9zdXJlcyBtYWRlIHRvIHRoZSBJRVRGIFNlY3JldGFyaWF0IGFuZCBh bnkKICAgYXNzdXJhbmNlcyBvZiBsaWNlbnNlcyB0byBiZSBtYWRlIGF2YWlsYWJsZSwgb3Ig dGhlIHJlc3VsdCBvZiBhbgogICBhdHRlbXB0IG1hZGUgdG8gb2J0YWluIGEgZ2VuZXJhbCBs aWNlbnNlIG9yIHBlcm1pc3Npb24gZm9yIHRoZSB1c2Ugb2YKICAgc3VjaCBwcm9wcmlldGFy eSByaWdodHMgYnkgaW1wbGVtZW50ZXJzIG9yIHVzZXJzIG9mIHRoaXMKICAgc3BlY2lmaWNh dGlvbiBjYW4gYmUgb2J0YWluZWQgZnJvbSB0aGUgSUVURiBvbi1saW5lIElQUiByZXBvc2l0 b3J5IGF0CiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaXByLgoKICAgVGhlIElFVEYgaW52aXRl cyBhbnkgaW50ZXJlc3RlZCBwYXJ0eSB0byBicmluZyB0byBpdHMgYXR0ZW50aW9uIGFueQog ICBjb3B5cmlnaHRzLCBwYXRlbnRzIG9yIHBhdGVudCBhcHBsaWNhdGlvbnMsIG9yIG90aGVy IHByb3ByaWV0YXJ5CiAgIHJpZ2h0cyB0aGF0IG1heSBjb3ZlciB0ZWNobm9sb2d5IHRoYXQg bWF5IGJlIHJlcXVpcmVkIHRvIGltcGxlbWVudAogICB0aGlzIHN0YW5kYXJkLiAgUGxlYXNl IGFkZHJlc3MgdGhlIGluZm9ybWF0aW9uIHRvIHRoZSBJRVRGIGF0CiAgIGlldGYtaXByQGll dGYub3JnLgoKCgoKCgoKCgoKCk5pdmVuLUplbmtpbnMsIGV0IGFsLiAgICBFeHBpcmVzIEph bnVhcnkgMiwgMjAwOSAgICAgICAgICAgICAgIFtQYWdlIDE4XQoMCgo= --B_3297148594_639816 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop --B_3297148594_639816-- From mpls-interop-bounces@ietf.org Tue Jun 24 04:00:45 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 723223A689D; Tue, 24 Jun 2008 04:00:45 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73FCE3A697F for ; Tue, 24 Jun 2008 04:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Yn4v24-dIpV for ; Tue, 24 Jun 2008 04:00:43 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by core3.amsl.com (Postfix) with ESMTP id AC8A53A689D for ; Tue, 24 Jun 2008 04:00:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by lucidvision.com (Postfix) with ESMTP id E73B9476F89; Tue, 24 Jun 2008 07:01:09 -0400 (EDT) Received: from lucidvision.com ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09948-01; Tue, 24 Jun 2008 07:00:39 -0400 (EDT) Received: from [192.168.1.120] (static-72-71-250-36.cncdnh.fios.verizon.net [72.71.250.36]) by lucidvision.com (Postfix) with ESMTP id 330B5476F5D; Tue, 24 Jun 2008 07:00:39 -0400 (EDT) Message-Id: From: Thomas Nadeau To: Ben Niven-Jenkins In-Reply-To: Mime-Version: 1.0 (Apple Message framework v924) Date: Tue, 24 Jun 2008 06:59:57 -0400 References: X-Mailer: Apple Mail (2.924) X-Virus-Scanned: by amavisd-new at lucidvision.com Cc: Italo Busi , 'MEAD team' Subject: Re: [Mpls-interop] MPLS-TP Requirements Abstract (was RE: next MEAD team meeting) X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org On Jun 24, 2008, at 4:30 AM, Ben Niven-Jenkins wrote: > I don't like this. I'm not clear why ITU-T has to be the only > organisation > drawn out as the source of the requirements and I don't like the > idea of > having to somehow identify/tag all requirements that are not from > the ITU-T > as I believe this to be an unnecessary editorial overhead which will > only > get worse as the document evolves. > > How about this? > > " > This document specifies the requirements for an MPLS Transport Profile > (MPLS-TP) in order to support the capabilities and functionalities > needed > for packet transport network services and packet transport network > operations. > > These requirements are a combination of those derived from the set of > requirements specified by ITU-T and requirements received directly > from > Service Providers. > > This document is a product of a joint ITU-IETF effort. I totally agree with you. I would say that the last statement is the only place to spell out the ITU (or IETF for that matter), and of course, the reference to the ITU document at the end. --Tom > > " > > Ben > > > On 23/06/2008 09:38, "Italo Busi" > wrote: > >> If I understand properly the arguments in this discussion, it seems >> quite >> important to clarify in the scope that these requirements are SP >> requirements >> as >> well as the fact that the source of most of them (if not all) is >> ITU-T. >> >> What about the following abstract? >> >> " >> This document specifies the requirements for an MPLS Transport >> Profile >> (MPLS-TP) >> in order to support capabilities and functionalities as needed for >> packet >> transport network services and network operations. >> >> Unless explicitly mentioned, these requirements are derived from >> the set of >> requirements specified by ITU-T. >> >> This document is a product of a joint ITU-IETF effort. >> " >> >> Thanks, Italo >> >>> -----Original Message----- >>> From: mpls-interop-bounces@ietf.org >>> [mailto:mpls-interop-bounces@ietf.org] On Behalf Of Loa Andersson >>> Sent: Friday, June 20, 2008 7:25 PM >>> To: BRUNGARD, DEBORAH A, ATTLABS >>> Cc: MEAD team >>> Subject: Re: [Mpls-interop] next MEAD team meeting >>> >>> >>> >>> BRUNGARD, DEBORAH A, ATTLABS wrote: >>>> Hi, >>>> >>>> Thanks Loa for the hint. My understanding of the charter >>> was to capture >>>> the ITU requirements? >>> >>> yes - that is true... >>> >>> but we also need to capture all requirements for the MPLS-TP whether >>> they are in the captured by the ITU-T or not. >>>> >>>> What is the MEAD development work covering - both ITU >>> requirements and >>>> "other (anonymous) SPs requirements"? >>> >>> if there is "only" requirements that originates from ITU-T this is >>> not a problem. I am not looking for anonymous requirements, if there >>> is a requirement that is not from ITU-T we should make clear where >>> it >>> came form >>> >>> /Loa >>>> >>>> Deborah >>>> >>>> >>>> -----Original Message----- >>>> From: Sprecher, Nurit (NSN - IL/Israel - MiniMD) >>>> [mailto:nurit.sprecher@nsn.com] >>>> Sent: Friday, June 20, 2008 5:23 AM >>>> To: ext Loa Andersson >>>> Cc: BRUNGARD, DEBORAH A, ATTLABS; MEAD team; Sprecher, Nurit (NSN - >>>> IL/Israel - MiniMD) >>>> Subject: RE: [Mpls-interop] next MEAD team meeting >>>> >>>> Hi, >>>> 1. I agree that validates may be a good option. >>>> 2. IMO, these requirements are not only the ITU-T view. I got these >>>> requirements from different SPs. As I indicated in the >>> beginning of the >>>> mail exchanges I would prefer to say: "This document specifies the >>>> requirements for MPLS-TP in order to support capabilities and >>>> functionalities as needed in transport environments (or >>> networks)." But >>>> this is something that we need the SPs to agree on. >>>> Please note also that in the proposal just below I forgot >>> to include the >>>> indication that this is a joint work of ITU-T and IETF. >>>> Best regards, >>>> Nurit >>>> >>>> >>>> -----Original Message----- >>>> From: ext Loa Andersson [mailto:loa@pi.nu] >>>> Sent: Friday, June 20, 2008 11:57 >>>> To: Sprecher, Nurit (NSN - IL/Israel - MiniMD) >>>> Cc: ext BRUNGARD, DEBORAH A, ATTLABS; MEAD team >>>> Subject: Re: [Mpls-interop] next MEAD team meeting >>>> >>>> All, >>>> >>>> just a few comments. >>>> >>>> Sprecher, Nurit (NSN - IL/Israel - MiniMD) wrote: >>>>> Hi Deborah, >>>>> I understand the intention, so how about the following (as we also >>>>> indicated in the introduction): >>>>> This document specifies >>>> >>>> I wonder if "specifies" is the right word - one way would be to say >>>> "validates" indicating that this how we (IETF) understands these >>>> requirements >>>> >>>> the ITU-T requirements for MPLS-TP in order to >>>>> support capabilities and functionalities of MPLS as needed in >>>>> transport environments. >>>> >>>> this indicates that there is nothing but ITU-T requirements in the >>>> document, is that true? >>>> >>>> /Loa >>>> >>>>> MPLS is a maturing packet technology and it is already playing an >>>>> important role in transport networks and services. >>> However, not all of >>>> >>>>> MPLS's capabilities and mechnisms are needed and/or >>> consistent with >>>>> transport network operations. This document identifies the >>> required >>>>> capabilities for MPLS so that it can better fit a transport role. >>>> >>>>> Please advise. >>>>> Best regards, >>>>> Nurit >>>>> >>>>> ________________________________ >>>>> >>>>> From: ext BRUNGARD, DEBORAH A, ATTLABS [mailto:dbrungard@att.com] >>>>> Sent: Thursday, June 19, 2008 23:04 >>>>> To: Sprecher, Nurit (NSN - IL/Israel - MiniMD); MEAD team >>>>> Subject: RE: [Mpls-interop] next MEAD team meeting >>>>> >>>>> >>>>> Hi Nurit, >>>>> >>>>> I would prefer to clearly say the requirements are ITU >>> requirements >>>>> for MPLS in a transport environment. I think among some >>> operators the >>>>> line between transport equipment and packet equipment has already >>>> blurred. >>>>> For many operators, the preference may be to align with MPLS >>>>> operations vs. transport. I think there are many differing >>> opinions on >>>> >>>>> what MPLS/packet transport needs to support in a transport >>>>> environment. So I prefer to clearly say these are ITU >>> requirements, >>>>> they do not necessarily reflect the operators contributing to this >>>> document. >>>>> >>>>> On the 2nd bullet, the requirements document has many >>>>> statements/requirements which may be interpreted by a >>> reader as gaps >>>>> in MPLS/IETF protocols. I was trying to say with this sentence the >>>>> document is not addressing/identifying IETF protocol >>> applicability or >>>>> lack of capabilities e.g. the sentence: >>>>> "Quality-of-service mechanisms are required in the packet >>>>> transport >>>>> network to ensure the prioritization of critical services, to >>>>> guarantee BW and to control jitter and delay." >>>>> >>>>> QoS is not a new requirement for IETF protocols. Packet transport >>>>> networks (and this requirement document) are not the first >>> time that >>>>> QoS mechanisms are identified as needed. This requirement is not >>>>> intending to identify a gap in the current IETF protocol >>> set. This was >>>> >>>>> what I was trying to say. >>>>> >>>>> Suggestions? >>>>> Deborah >>>>> >>>>> >>>>> >>>>> ________________________________ >>>>> >>>>> From: Sprecher, Nurit (NSN - IL/Israel - MiniMD) >>>>> [mailto:nurit.sprecher@nsn.com] >>>>> Sent: Thursday, June 19, 2008 3:10 PM >>>>> To: BRUNGARD, DEBORAH A, ATTLABS; MEAD team >>>>> Cc: Sprecher, Nurit (NSN - IL/Israel - MiniMD) >>>>> Subject: RE: [Mpls-interop] next MEAD team meeting >>>>> >>>>> >>>>> >>>>> Hi Deborah, >>>>> >>>>> I have a few comments regarding the proposed abstract: >>>>> >>>>> * I think we should say "This document specifies the >>>>> requirements for MPLS-TP in order to support capabilities and >>>>> functionalities as needed in transport environments (or networks). >>>>> >>>>> * I do not understand the sentence: It does not >>> address IETF >>>>> protocol applicability or capabilities. Do you mean >>> applicability or >>>>> capability of the current IETF documents? As IMO it will be of the >>>>> documents we generate for MPLS-TP. >>>>> >>>>> * I think it is important to indicate that " This >>> document is >>>> a >>>>> product of a joint ITU-IETF effort". >>>>> >>>>> Best regards, >>>>> >>>>> Nurit >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: mpls-interop-bounces@ietf.org >>>>> [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext BRUNGARD, >>>>> DEBORAH A, ATTLABS >>>>> Sent: Thursday, June 19, 2008 21:11 >>>>> To: MEAD team >>>>> Subject: Re: [Mpls-interop] next MEAD team meeting >>>>> >>>>> >>>>> >>>>> Colleagues, >>>>> >>>>> >>>>> >>>>> I was thinking for the requirements we should include a >>> sentence in >>>>> the >>>>> >>>>> abstract to scope the MPLS-TP work as being part of a >>> joint ITU-IETF >>>>> >>>>> effort. Not all readers (now and future) will be aware of >>> why this is >>>>> >>>>> being done. In ccamp, we had done this for our ASON work. Maybe a >>>>> >>>>> similar sentence will be needed in the other documents? >>> Should we have >>>> >>>>> a >>>>> >>>>> common sentence? >>>>> >>>>> >>>>> >>>>> How about for the abstract: >>>>> >>>>> This document summarizes the ITU-T requirements for >>> MPLS-TP in order >>>>> to >>>>> >>>>> support capabilities and functionalities as needed by the >>> ITU-T. It >>>>> does >>>>> >>>>> not address IETF protocol applicability or capabilities. >>> This document >>>>> >>>>> is a product of a joint ITU-IETF effort. >>>>> >>>>> >>>>> >>>>> Deborah >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> >>>>> From: mpls-interop-bounces@ietf.org >>>>> >>>>> [mailto:mpls-interop-bounces@ietf.org] On Behalf Of Ben >>> Niven-Jenkins >>>>> >>>>> Sent: Thursday, June 19, 2008 1:21 PM >>>>> >>>>> To: Loa Andersson; MEAD team >>>>> >>>>> Subject: Re: [Mpls-interop] next MEAD team meeting >>>>> >>>>> >>>>> >>>>> Colleagues, >>>>> >>>>> >>>>> >>>>> FYI see attached for the latest draft of the MPLS-TP requirements >>>> draft. >>>>> >>>>> >>>>> Ben >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 19/06/2008 16:00, "Loa Andersson" wrote: >>>>> >>>>> >>>>> >>>>>> All, >>>>> >>>>>> the MEAD team will have the next meeting on Tuesday 24, at 6pm >>>>>> i.e. 12am east coast and 9am California. >>>>> >>>>>> Again I plan the meeting to last an hour, and focus will be on >>>>>> the >>>>>> document status. >>>>> >>>>>> Stewart will send out dial in details as usual. >>>>> >>>>>> /Loa >>>>> >>>>> >>>>> _______________________________________________ >>>>> >>>>> Mpls-interop mailing list >>>>> >>>>> Mpls-interop@ietf.org >>>>> >>>>> https://www.ietf.org/mailman/listinfo/mpls-interop >>>>> >>>>> >>>>> >>>>> >>>>> >>> ---------------------------------------------------------------------- >>>>> -- >>>>> >>>>> _______________________________________________ >>>>> Mpls-interop mailing list >>>>> Mpls-interop@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mpls-interop >>>> >>>> >>>> -- >>>> Loa Andersson >>>> >>>> Principal Networking Architect >>>> Acreo AB phone: +46 8 632 77 14 >>>> Isafjordsgatan 22 mobile: +46 739 81 21 64 >>>> Kista, Sweden email: loa.andersson@acreo.se >>>> loa@pi.nu >>> >>> >>> -- >>> Loa Andersson >>> >>> Principal Networking Architect >>> Acreo AB phone: +46 8 632 77 14 >>> Isafjordsgatan 22 mobile: +46 739 81 21 64 >>> Kista, Sweden email: loa.andersson@acreo.se >>> loa@pi.nu >>> _______________________________________________ >>> Mpls-interop mailing list >>> Mpls-interop@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls-interop >>> >> >> _______________________________________________ >> Mpls-interop mailing list >> Mpls-interop@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-interop > > _______________________________________________ > Mpls-interop mailing list > Mpls-interop@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-interop > _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop From mpls-interop-bounces@ietf.org Tue Jun 24 05:35:06 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E092B3A6808; Tue, 24 Jun 2008 05:35:06 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F25633A68FB for ; Tue, 24 Jun 2008 05:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.873 X-Spam-Level: X-Spam-Status: No, score=-0.873 tagged_above=-999 required=5 tests=[AWL=0.659, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZO0JwXsbXxW for ; Tue, 24 Jun 2008 05:35:05 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id ADF603A6808 for ; Tue, 24 Jun 2008 05:35:04 -0700 (PDT) Received: from E03MVZ2-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jun 2008 13:35:02 +0100 Received: from 217.32.164.184 ([217.32.164.184]) by E03MVZ2-UKDY.domain1.systemhost.net ([193.113.30.120]) via Exchange Front-End Server mail.bt.com ([193.113.197.28]) with Microsoft Exchange Server HTTP-DAV ; Tue, 24 Jun 2008 12:35:01 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Tue, 24 Jun 2008 08:34:45 -0400 From: Thomas Nadeau To: MEAD team Message-ID: Thread-Topic: MPLS OAM Analysis Document Thread-Index: AcjSMNQsx4BuurjX8EeQxIcfmO8exAA0/R+VAEuIunAACtuUpAABrZoIAGRnm6Y= In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 24 Jun 2008 12:35:02.0588 (UTC) FILETIME=[B93357C0:01C8D5F6] Cc: David Ward , hhelvoort@chello.nl Subject: [Mpls-interop] MPLS OAM Analysis Document X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org The OAM Analysis Team (Nurit, Huub and myself) met today and agreed on the following: 1) The goals of the team are to analyze the OAM requirements and existing solutions and map them to each other. 2) Indicate the gaps where they exist in the document. 3) Feed the gaps back into the existing solution/requirements work. 4) Work via email on a TOC and fill in as much of this as possible by the deadline. We will publish whatever is ready at that point. Open questions were: 1) MPLS-TP Chairs: Do we need to produce any slides for the next IETF meeting? --Tom _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop From mpls-interop-bounces@ietf.org Tue Jun 24 06:19:37 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94B223A684C; Tue, 24 Jun 2008 06:19:37 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FAE63A6861 for ; Tue, 24 Jun 2008 06:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UlfPuRKRFlIT for ; Tue, 24 Jun 2008 06:19:35 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 4CA503A684C for ; Tue, 24 Jun 2008 06:19:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,696,1204531200"; d="scan'208";a="117657543" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 24 Jun 2008 06:19:36 -0700 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m5ODJZ6G024074; Tue, 24 Jun 2008 06:19:36 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5ODJZDi000611; Tue, 24 Jun 2008 13:19:35 GMT Received: from xmb-rtp-202.amer.cisco.com ([64.102.31.52]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jun 2008 09:19:27 -0400 Received: from [127.0.0.1] ([171.68.225.134]) by xmb-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jun 2008 09:18:57 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <32E6AA49-F2E5-45B1-A57D-9F8C8BD90BF8@cisco.com> From: David Ward Date: Tue, 24 Jun 2008 08:18:54 -0500 To: Thomas Nadeau X-Mailer: Apple Mail (2.753.1) X-OriginalArrivalTime: 24 Jun 2008 13:18:57.0571 (UTC) FILETIME=[DBC5D730:01C8D5FC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=773; t=1214313576; x=1215177576; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dward@cisco.com; z=From:=20David=20Ward=20 |Subject:=20Re=3A=20MPLS=20OAM=20Analysis=20Document |Sender:=20; bh=ea0FpZ5brYikx+//mT4yz2/nl17Ryt6RvuLz/oSYty4=; b=P6GOGszcQ+EXiqdOvtR9Ov3fjmSjXFfvnfioWzy9wGIXuDhKT/NFxL0D6Q q12oGxFxdEq87crSrxecdTSmD0WCwZjc2vp9hdz0glMc6egGO/6Ljc552D7x 7vM4feEk4s; Authentication-Results: sj-dkim-3; header.From=dward@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: hhelvoort@chello.nl, David Ward , MEAD team Subject: Re: [Mpls-interop] MPLS OAM Analysis Document X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org I'd expect that you do. -DWard On Jun 24, 2008, at 7:34 AM, Thomas Nadeau wrote: > > The OAM Analysis Team (Nurit, Huub and myself) met today and > agreed on > the following: > > 1) The goals of the team are to analyze the OAM requirements and > existing solutions and map them to each other. > > 2) Indicate the gaps where they exist in the document. > > 3) Feed the gaps back into the existing solution/requirements > work. > > 4) Work via email on a TOC and fill in as much of this as > possible by > the deadline. We will publish whatever is ready at that point. > > > Open questions were: > > 1) MPLS-TP Chairs: Do we need to produce any slides for the > next IETF > meeting? > > --Tom > > _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop From mpls-interop-bounces@ietf.org Tue Jun 24 06:57:12 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 308E93A67E6; Tue, 24 Jun 2008 06:57:12 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F1683A67E6 for ; Tue, 24 Jun 2008 06:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BCQuyGOMi6p7 for ; Tue, 24 Jun 2008 06:57:08 -0700 (PDT) Received: from tpamail4.verizon.com (tpamail4.verizon.com [192.76.82.161]) by core3.amsl.com (Postfix) with ESMTP id D00DF3A68F5 for ; Tue, 24 Jun 2008 06:56:46 -0700 (PDT) Received: from smtptpa4.verizon.com (smtptpa4.verizon.com [138.83.71.177]) by tpamail4.verizon.com (8.13.6/8.13.3) with ESMTP id m5ODpbLg002304; Tue, 24 Jun 2008 09:51:47 -0400 (EDT) Received: from ftwintrmemf2.verizon.com (ftwintrmemf2.verizon.com [138.83.131.184]) by smtptpa4.verizon.com (8.13.3/8.13.3) with ESMTP id m5ODuOgI029265; Tue, 24 Jun 2008 09:56:24 -0400 (EDT) Received: from ftwintrmemf2.verizon.com (unknown [127.0.0.1]) by ftwintrmemf2.verizon.com (Symantec Mail Security) with ESMTP id 686F2528002; Tue, 24 Jun 2008 09:56:24 -0400 (EDT) X-AuditID: 8a5383b8-a5ec0bb000000647-d8-4860fd08a4fc Received: from smtptpa3.verizon.com (unknown [138.83.71.176]) by ftwintrmemf2.verizon.com (EMF) with ESMTP id 1E1F94E4002; Tue, 24 Jun 2008 09:56:24 -0400 (EDT) Received: from FHDP1CCMXCG02.us.one.verizon.com ([166.68.240.34]) by smtptpa3.verizon.com (8.13.3/8.13.3) with ESMTP id m5ODuN2Z008654; Tue, 24 Jun 2008 09:56:23 -0400 (EDT) Received: from FHDP1CCMXCV01.us.one.verizon.com ([166.68.240.11]) by FHDP1CCMXCG02.us.one.verizon.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Jun 2008 09:56:23 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Jun 2008 09:56:22 -0400 Message-ID: <03EF010917EC4F46975DE0B94C51B1C205B8F9@FHDP1CCMXCV01.us.one.verizon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mpls-interop] MPLS-TP Requirements Abstract (was RE: next MEADteam meeting) Thread-Index: AcjS+oxykpiCiEFrSKaGeg3ms5bIkgCEBNYgADJ3f0IAC2YJFg== From: To: , , , X-OriginalArrivalTime: 24 Jun 2008 13:56:23.0521 (UTC) FILETIME=[16769D10:01C8D602] X-Brightmail-Tracker: AAAAAA== Cc: mpls-interop@ietf.org Subject: Re: [Mpls-interop] MPLS-TP Requirements Abstract (was RE: next MEAD team meeting) X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1151961814==" Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org This is a multi-part message in MIME format. --===============1151961814== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8D602.1602CF33" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8D602.1602CF33 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 IEJlbiwNCg0KSSBhZ3JlZSwgdGhhdCdzIG11Y2ggYmV0dGVyLiANCg0KQ2hlZXJzLA0KQW5keSAN Cg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogbXBscy1pbnRlcm9wLWJvdW5j ZXNAaWV0Zi5vcmcgPG1wbHMtaW50ZXJvcC1ib3VuY2VzQGlldGYub3JnPg0KVG86IEl0YWxvIEJ1 c2kgPEl0YWxvLkJ1c2lAYWxjYXRlbC1sdWNlbnQuaXQ+OyAnTG9hIEFuZGVyc3NvbicgPGxvYUBw aS5udT47ICdCUlVOR0FSRCwgREVCT1JBSCBBLCBBVFRMQUJTJyA8ZGJydW5nYXJkQGF0dC5jb20+ DQpDYzogJ01FQUQgdGVhbScgPG1wbHMtaW50ZXJvcEBpZXRmLm9yZz4NClNlbnQ6IFR1ZSBKdW4g MjQgMDQ6MzA6MDAgMjAwOA0KU3ViamVjdDogUmU6IFtNcGxzLWludGVyb3BdIE1QTFMtVFAgUmVx dWlyZW1lbnRzIEFic3RyYWN0ICh3YXMgUkU6IG5leHQgTUVBRCB0ZWFtIG1lZXRpbmcpDQoNCkkg ZG9uJ3QgbGlrZSB0aGlzLiAgSSdtIG5vdCBjbGVhciB3aHkgSVRVLVQgaGFzIHRvIGJlIHRoZSBv bmx5IG9yZ2FuaXNhdGlvbg0KZHJhd24gb3V0IGFzIHRoZSBzb3VyY2Ugb2YgdGhlIHJlcXVpcmVt ZW50cyBhbmQgSSBkb24ndCBsaWtlIHRoZSBpZGVhIG9mDQpoYXZpbmcgdG8gc29tZWhvdyBpZGVu dGlmeS90YWcgYWxsIHJlcXVpcmVtZW50cyB0aGF0IGFyZSBub3QgZnJvbSB0aGUgSVRVLVQNCmFz IEkgYmVsaWV2ZSB0aGlzIHRvIGJlIGFuIHVubmVjZXNzYXJ5IGVkaXRvcmlhbCBvdmVyaGVhZCB3 aGljaCB3aWxsIG9ubHkNCmdldCB3b3JzZSBhcyB0aGUgZG9jdW1lbnQgZXZvbHZlcy4NCg0KSG93 IGFib3V0IHRoaXM/DQoNCiINClRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIHRoZSByZXF1aXJlbWVu dHMgZm9yIGFuIE1QTFMgVHJhbnNwb3J0IFByb2ZpbGUNCihNUExTLVRQKSBpbiBvcmRlciB0byBz dXBwb3J0IHRoZSBjYXBhYmlsaXRpZXMgYW5kIGZ1bmN0aW9uYWxpdGllcyBuZWVkZWQNCmZvciBw YWNrZXQgdHJhbnNwb3J0IG5ldHdvcmsgc2VydmljZXMgYW5kIHBhY2tldCB0cmFuc3BvcnQgbmV0 d29yaw0Kb3BlcmF0aW9ucy4NCg0KVGhlc2UgcmVxdWlyZW1lbnRzIGFyZSBhIGNvbWJpbmF0aW9u IG9mIHRob3NlIGRlcml2ZWQgZnJvbSB0aGUgc2V0IG9mDQpyZXF1aXJlbWVudHMgc3BlY2lmaWVk IGJ5IElUVS1UIGFuZCByZXF1aXJlbWVudHMgcmVjZWl2ZWQgZGlyZWN0bHkgZnJvbQ0KU2Vydmlj ZSBQcm92aWRlcnMuDQoNClRoaXMgZG9jdW1lbnQgaXMgYSBwcm9kdWN0IG9mIGEgam9pbnQgSVRV LUlFVEYgZWZmb3J0Lg0KIg0KDQpCZW4NCg0KDQpPbiAyMy8wNi8yMDA4IDA5OjM4LCAiSXRhbG8g QnVzaSIgPEl0YWxvLkJ1c2lAYWxjYXRlbC1sdWNlbnQuaXQ+IHdyb3RlOg0KDQo+IElmIEkgdW5k ZXJzdGFuZCBwcm9wZXJseSB0aGUgYXJndW1lbnRzIGluIHRoaXMgZGlzY3Vzc2lvbiwgaXQgc2Vl bXMgcXVpdGUNCj4gaW1wb3J0YW50IHRvIGNsYXJpZnkgaW4gdGhlIHNjb3BlIHRoYXQgdGhlc2Ug cmVxdWlyZW1lbnRzIGFyZSBTUCByZXF1aXJlbWVudHMNCj4gYXMNCj4gd2VsbCBhcyB0aGUgZmFj dCB0aGF0IHRoZSBzb3VyY2Ugb2YgbW9zdCBvZiB0aGVtIChpZiBub3QgYWxsKSBpcyBJVFUtVC4N Cj4gDQo+IFdoYXQgYWJvdXQgdGhlIGZvbGxvd2luZyBhYnN0cmFjdD8NCj4gDQo+ICINCj4gVGhp cyBkb2N1bWVudCBzcGVjaWZpZXMgdGhlIHJlcXVpcmVtZW50cyBmb3IgYW4gTVBMUyBUcmFuc3Bv cnQgUHJvZmlsZQ0KPiAoTVBMUy1UUCkNCj4gaW4gb3JkZXIgdG8gc3VwcG9ydCBjYXBhYmlsaXRp ZXMgYW5kIGZ1bmN0aW9uYWxpdGllcyBhcyBuZWVkZWQgZm9yIHBhY2tldA0KPiB0cmFuc3BvcnQg bmV0d29yayBzZXJ2aWNlcyBhbmQgbmV0d29yayBvcGVyYXRpb25zLg0KPiANCj4gVW5sZXNzIGV4 cGxpY2l0bHkgbWVudGlvbmVkLCB0aGVzZSByZXF1aXJlbWVudHMgYXJlIGRlcml2ZWQgZnJvbSB0 aGUgc2V0IG9mDQo+IHJlcXVpcmVtZW50cyBzcGVjaWZpZWQgYnkgSVRVLVQuDQo+IA0KPiBUaGlz IGRvY3VtZW50IGlzIGEgcHJvZHVjdCBvZiBhIGpvaW50IElUVS1JRVRGIGVmZm9ydC4NCj4gIg0K PiANCj4gVGhhbmtzLCBJdGFsbw0KPiANCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ PiBGcm9tOiBtcGxzLWludGVyb3AtYm91bmNlc0BpZXRmLm9yZw0KPj4gW21haWx0bzptcGxzLWlu dGVyb3AtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExvYSBBbmRlcnNzb24NCj4+IFNl bnQ6IEZyaWRheSwgSnVuZSAyMCwgMjAwOCA3OjI1IFBNDQo+PiBUbzogQlJVTkdBUkQsIERFQk9S QUggQSwgQVRUTEFCUw0KPj4gQ2M6IE1FQUQgdGVhbQ0KPj4gU3ViamVjdDogUmU6IFtNcGxzLWlu dGVyb3BdIG5leHQgTUVBRCB0ZWFtIG1lZXRpbmcNCj4+IA0KPj4gDQo+PiANCj4+IEJSVU5HQVJE LCBERUJPUkFIIEEsIEFUVExBQlMgd3JvdGU6DQo+Pj4gSGksDQo+Pj4gDQo+Pj4gVGhhbmtzIExv YSBmb3IgdGhlIGhpbnQuIE15IHVuZGVyc3RhbmRpbmcgb2YgdGhlIGNoYXJ0ZXINCj4+IHdhcyB0 byBjYXB0dXJlDQo+Pj4gdGhlIElUVSByZXF1aXJlbWVudHM/DQo+PiANCj4+IHllcyAtIHRoYXQg aXMgdHJ1ZS4uLg0KPj4gDQo+PiBidXQgd2UgYWxzbyBuZWVkIHRvIGNhcHR1cmUgYWxsIHJlcXVp cmVtZW50cyBmb3IgdGhlIE1QTFMtVFAgd2hldGhlcg0KPj4gdGhleSBhcmUgaW4gdGhlIGNhcHR1 cmVkIGJ5IHRoZSBJVFUtVCBvciBub3QuDQo+Pj4gDQo+Pj4gV2hhdCBpcyB0aGUgTUVBRCBkZXZl bG9wbWVudCB3b3JrIGNvdmVyaW5nIC0gYm90aCBJVFUNCj4+IHJlcXVpcmVtZW50cyBhbmQNCj4+ PiAib3RoZXIgKGFub255bW91cykgU1BzIHJlcXVpcmVtZW50cyI/DQo+PiANCj4+IGlmIHRoZXJl IGlzICJvbmx5IiByZXF1aXJlbWVudHMgdGhhdCBvcmlnaW5hdGVzIGZyb20gSVRVLVQgdGhpcyBp cw0KPj4gbm90IGEgcHJvYmxlbS4gSSBhbSBub3QgbG9va2luZyBmb3IgYW5vbnltb3VzIHJlcXVp cmVtZW50cywgaWYgdGhlcmUNCj4+IGlzIGEgcmVxdWlyZW1lbnQgdGhhdCBpcyBub3QgZnJvbSBJ VFUtVCB3ZSBzaG91bGQgbWFrZSBjbGVhciB3aGVyZSBpdA0KPj4gY2FtZSBmb3JtDQo+PiANCj4+ IC9Mb2ENCj4+PiANCj4+PiBEZWJvcmFoIA0KPj4+ICANCj4+PiANCj4+PiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPj4+IEZyb206IFNwcmVjaGVyLCBOdXJpdCAoTlNOIC0gSUwvSXNyYWVs IC0gTWluaU1EKQ0KPj4+IFttYWlsdG86bnVyaXQuc3ByZWNoZXJAbnNuLmNvbV0NCj4+PiBTZW50 OiBGcmlkYXksIEp1bmUgMjAsIDIwMDggNToyMyBBTQ0KPj4+IFRvOiBleHQgTG9hIEFuZGVyc3Nv bg0KPj4+IENjOiBCUlVOR0FSRCwgREVCT1JBSCBBLCBBVFRMQUJTOyBNRUFEIHRlYW07IFNwcmVj aGVyLCBOdXJpdCAoTlNOIC0NCj4+PiBJTC9Jc3JhZWwgLSBNaW5pTUQpDQo+Pj4gU3ViamVjdDog UkU6IFtNcGxzLWludGVyb3BdIG5leHQgTUVBRCB0ZWFtIG1lZXRpbmcNCj4+PiANCj4+PiBIaSwg DQo+Pj4gMS4gSSBhZ3JlZSB0aGF0IHZhbGlkYXRlcyBtYXkgYmUgYSBnb29kIG9wdGlvbi4NCj4+ PiAyLiBJTU8sIHRoZXNlIHJlcXVpcmVtZW50cyBhcmUgbm90IG9ubHkgdGhlIElUVS1UIHZpZXcu IEkgZ290IHRoZXNlDQo+Pj4gcmVxdWlyZW1lbnRzIGZyb20gZGlmZmVyZW50IFNQcy4gQXMgSSBp bmRpY2F0ZWQgaW4gdGhlDQo+PiBiZWdpbm5pbmcgb2YgdGhlDQo+Pj4gbWFpbCBleGNoYW5nZXMg SSB3b3VsZCBwcmVmZXIgdG8gc2F5OiAiVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgdGhlDQo+Pj4g cmVxdWlyZW1lbnRzIGZvciBNUExTLVRQIGluIG9yZGVyIHRvIHN1cHBvcnQgY2FwYWJpbGl0aWVz IGFuZA0KPj4+IGZ1bmN0aW9uYWxpdGllcyBhcyBuZWVkZWQgaW4gdHJhbnNwb3J0IGVudmlyb25t ZW50cyAob3INCj4+IG5ldHdvcmtzKS4iIEJ1dA0KPj4+IHRoaXMgaXMgc29tZXRoaW5nIHRoYXQg d2UgbmVlZCB0aGUgU1BzIHRvIGFncmVlIG9uLg0KPj4+IFBsZWFzZSBub3RlIGFsc28gdGhhdCBp biB0aGUgcHJvcG9zYWwganVzdCBiZWxvdyBJIGZvcmdvdA0KPj4gdG8gaW5jbHVkZSB0aGUNCj4+ PiBpbmRpY2F0aW9uIHRoYXQgdGhpcyBpcyBhIGpvaW50IHdvcmsgb2YgSVRVLVQgYW5kIElFVEYu DQo+Pj4gQmVzdCByZWdhcmRzLA0KPj4+IE51cml0DQo+Pj4gDQo+Pj4gDQo+Pj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBleHQgTG9hIEFuZGVyc3NvbiBbbWFpbHRvOmxv YUBwaS5udV0NCj4+PiBTZW50OiBGcmlkYXksIEp1bmUgMjAsIDIwMDggMTE6NTcNCj4+PiBUbzog U3ByZWNoZXIsIE51cml0IChOU04gLSBJTC9Jc3JhZWwgLSBNaW5pTUQpDQo+Pj4gQ2M6IGV4dCBC UlVOR0FSRCwgREVCT1JBSCBBLCBBVFRMQUJTOyBNRUFEIHRlYW0NCj4+PiBTdWJqZWN0OiBSZTog W01wbHMtaW50ZXJvcF0gbmV4dCBNRUFEIHRlYW0gbWVldGluZw0KPj4+IA0KPj4+IEFsbCwNCj4+ PiANCj4+PiBqdXN0IGEgZmV3IGNvbW1lbnRzLg0KPj4+IA0KPj4+IFNwcmVjaGVyLCBOdXJpdCAo TlNOIC0gSUwvSXNyYWVsIC0gTWluaU1EKSB3cm90ZToNCj4+Pj4gSGkgRGVib3JhaCwNCj4+Pj4g SSB1bmRlcnN0YW5kIHRoZSBpbnRlbnRpb24sIHNvIGhvdyBhYm91dCB0aGUgZm9sbG93aW5nIChh cyB3ZSBhbHNvDQo+Pj4+IGluZGljYXRlZCBpbiB0aGUgaW50cm9kdWN0aW9uKToNCj4+Pj4gVGhp cyBkb2N1bWVudCBzcGVjaWZpZXMNCj4+PiANCj4+PiBJIHdvbmRlciBpZiAic3BlY2lmaWVzIiBp cyB0aGUgcmlnaHQgd29yZCAtIG9uZSB3YXkgd291bGQgYmUgdG8gc2F5DQo+Pj4gInZhbGlkYXRl cyIgaW5kaWNhdGluZyB0aGF0IHRoaXMgaG93IHdlIChJRVRGKSB1bmRlcnN0YW5kcyB0aGVzZQ0K Pj4+IHJlcXVpcmVtZW50cw0KPj4+IA0KPj4+IHRoZSBJVFUtVCByZXF1aXJlbWVudHMgZm9yIE1Q TFMtVFAgaW4gb3JkZXIgdG8NCj4+Pj4gc3VwcG9ydCBjYXBhYmlsaXRpZXMgYW5kIGZ1bmN0aW9u YWxpdGllcyBvZiBNUExTIGFzIG5lZWRlZCBpbg0KPj4+PiB0cmFuc3BvcnQgZW52aXJvbm1lbnRz Lg0KPj4+IA0KPj4+IHRoaXMgaW5kaWNhdGVzIHRoYXQgdGhlcmUgaXMgbm90aGluZyBidXQgSVRV LVQgcmVxdWlyZW1lbnRzIGluIHRoZQ0KPj4+IGRvY3VtZW50LCBpcyB0aGF0IHRydWU/DQo+Pj4g DQo+Pj4gL0xvYQ0KPj4+IA0KPj4+PiBNUExTIGlzIGEgbWF0dXJpbmcgcGFja2V0IHRlY2hub2xv Z3kgYW5kIGl0IGlzIGFscmVhZHkgcGxheWluZyBhbg0KPj4+PiBpbXBvcnRhbnQgcm9sZSBpbiB0 cmFuc3BvcnQgbmV0d29ya3MgYW5kIHNlcnZpY2VzLg0KPj4gSG93ZXZlciwgbm90IGFsbCBvZg0K Pj4+IA0KPj4+PiBNUExTJ3MgY2FwYWJpbGl0aWVzIGFuZCBtZWNobmlzbXMgYXJlIG5lZWRlZCBh bmQvb3INCj4+IGNvbnNpc3RlbnQgd2l0aCANCj4+Pj4gdHJhbnNwb3J0IG5ldHdvcmsgb3BlcmF0 aW9ucy4gVGhpcyBkb2N1bWVudCBpZGVudGlmaWVzIHRoZQ0KPj4gcmVxdWlyZWQgDQo+Pj4+IGNh cGFiaWxpdGllcyBmb3IgTVBMUyBzbyB0aGF0IGl0IGNhbiBiZXR0ZXIgZml0IGEgdHJhbnNwb3J0 IHJvbGUuDQo+Pj4gDQo+Pj4+IFBsZWFzZSBhZHZpc2UuDQo+Pj4+IEJlc3QgcmVnYXJkcywNCj4+ Pj4gTnVyaXQNCj4+Pj4gDQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ Pj4+IA0KPj4+PiBGcm9tOiBleHQgQlJVTkdBUkQsIERFQk9SQUggQSwgQVRUTEFCUyBbbWFpbHRv OmRicnVuZ2FyZEBhdHQuY29tXQ0KPj4+PiBTZW50OiBUaHVyc2RheSwgSnVuZSAxOSwgMjAwOCAy MzowNA0KPj4+PiBUbzogU3ByZWNoZXIsIE51cml0IChOU04gLSBJTC9Jc3JhZWwgLSBNaW5pTUQp OyBNRUFEIHRlYW0NCj4+Pj4gU3ViamVjdDogUkU6IFtNcGxzLWludGVyb3BdIG5leHQgTUVBRCB0 ZWFtIG1lZXRpbmcNCj4+Pj4gDQo+Pj4+IA0KPj4+PiBIaSBOdXJpdCwNCj4+Pj4gIA0KPj4+PiBJ IHdvdWxkIHByZWZlciB0byBjbGVhcmx5IHNheSB0aGUgcmVxdWlyZW1lbnRzIGFyZSBJVFUNCj4+ IHJlcXVpcmVtZW50cyANCj4+Pj4gZm9yIE1QTFMgaW4gYSB0cmFuc3BvcnQgZW52aXJvbm1lbnQu IEkgdGhpbmsgYW1vbmcgc29tZQ0KPj4gb3BlcmF0b3JzIHRoZSANCj4+Pj4gbGluZSBiZXR3ZWVu IHRyYW5zcG9ydCBlcXVpcG1lbnQgYW5kIHBhY2tldCBlcXVpcG1lbnQgaGFzIGFscmVhZHkNCj4+ PiBibHVycmVkLg0KPj4+PiBGb3IgbWFueSBvcGVyYXRvcnMsIHRoZSBwcmVmZXJlbmNlIG1heSBi ZSB0byBhbGlnbiB3aXRoIE1QTFMNCj4+Pj4gb3BlcmF0aW9ucyB2cy4gdHJhbnNwb3J0LiBJIHRo aW5rIHRoZXJlIGFyZSBtYW55IGRpZmZlcmluZw0KPj4gb3BpbmlvbnMgb24NCj4+PiANCj4+Pj4g d2hhdCBNUExTL3BhY2tldCB0cmFuc3BvcnQgbmVlZHMgdG8gc3VwcG9ydCBpbiBhIHRyYW5zcG9y dA0KPj4+PiBlbnZpcm9ubWVudC4gU28gSSBwcmVmZXIgdG8gY2xlYXJseSBzYXkgdGhlc2UgYXJl IElUVQ0KPj4gcmVxdWlyZW1lbnRzLCANCj4+Pj4gdGhleSBkbyBub3QgbmVjZXNzYXJpbHkgcmVm bGVjdCB0aGUgb3BlcmF0b3JzIGNvbnRyaWJ1dGluZyB0byB0aGlzDQo+Pj4gZG9jdW1lbnQuDQo+ Pj4+ICANCj4+Pj4gT24gdGhlIDJuZCBidWxsZXQsICB0aGUgcmVxdWlyZW1lbnRzIGRvY3VtZW50 IGhhcyBtYW55DQo+Pj4+IHN0YXRlbWVudHMvcmVxdWlyZW1lbnRzIHdoaWNoIG1heSBiZSBpbnRl cnByZXRlZCBieSBhDQo+PiByZWFkZXIgYXMgZ2FwcyANCj4+Pj4gaW4gTVBMUy9JRVRGIHByb3Rv Y29scy4gSSB3YXMgdHJ5aW5nIHRvIHNheSB3aXRoIHRoaXMgc2VudGVuY2UgdGhlDQo+Pj4+IGRv Y3VtZW50IGlzIG5vdCBhZGRyZXNzaW5nL2lkZW50aWZ5aW5nIElFVEYgcHJvdG9jb2wNCj4+IGFw cGxpY2FiaWxpdHkgb3INCj4+Pj4gbGFjayBvZiBjYXBhYmlsaXRpZXMgZS5nLiB0aGUgc2VudGVu Y2U6DQo+Pj4+ICJRdWFsaXR5LW9mLXNlcnZpY2UgbWVjaGFuaXNtcyBhcmUgcmVxdWlyZWQgaW4g dGhlIHBhY2tldCB0cmFuc3BvcnQNCj4+Pj4gICAgbmV0d29yayB0byBlbnN1cmUgdGhlIHByaW9y aXRpemF0aW9uIG9mIGNyaXRpY2FsIHNlcnZpY2VzLCB0bw0KPj4+PiAgICBndWFyYW50ZWUgQlcg YW5kIHRvIGNvbnRyb2wgaml0dGVyIGFuZCBkZWxheS4iDQo+Pj4+IA0KPj4+PiBRb1MgaXMgbm90 IGEgbmV3IHJlcXVpcmVtZW50IGZvciBJRVRGIHByb3RvY29scy4gUGFja2V0IHRyYW5zcG9ydA0K Pj4+PiBuZXR3b3JrcyAoYW5kIHRoaXMgcmVxdWlyZW1lbnQgZG9jdW1lbnQpIGFyZSBub3QgdGhl IGZpcnN0DQo+PiB0aW1lIHRoYXQgDQo+Pj4+IFFvUyBtZWNoYW5pc21zIGFyZSBpZGVudGlmaWVk IGFzIG5lZWRlZC4gVGhpcyByZXF1aXJlbWVudCBpcyBub3QNCj4+Pj4gaW50ZW5kaW5nIHRvIGlk ZW50aWZ5IGEgZ2FwIGluIHRoZSBjdXJyZW50IElFVEYgcHJvdG9jb2wNCj4+IHNldC4gVGhpcyB3 YXMNCj4+PiANCj4+Pj4gd2hhdCBJIHdhcyB0cnlpbmcgdG8gc2F5Lg0KPj4+PiAgDQo+Pj4+IFN1 Z2dlc3Rpb25zPw0KPj4+PiBEZWJvcmFoDQo+Pj4+ICANCj4+Pj4gIA0KPj4+PiANCj4+Pj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gDQo+Pj4+IEZyb206IFNwcmVjaGVy LCBOdXJpdCAoTlNOIC0gSUwvSXNyYWVsIC0gTWluaU1EKQ0KPj4+PiBbbWFpbHRvOm51cml0LnNw cmVjaGVyQG5zbi5jb21dDQo+Pj4+IFNlbnQ6IFRodXJzZGF5LCBKdW5lIDE5LCAyMDA4IDM6MTAg UE0NCj4+Pj4gVG86IEJSVU5HQVJELCBERUJPUkFIIEEsIEFUVExBQlM7IE1FQUQgdGVhbQ0KPj4+ PiBDYzogU3ByZWNoZXIsIE51cml0IChOU04gLSBJTC9Jc3JhZWwgLSBNaW5pTUQpDQo+Pj4+IFN1 YmplY3Q6IFJFOiBbTXBscy1pbnRlcm9wXSBuZXh0IE1FQUQgdGVhbSBtZWV0aW5nDQo+Pj4+IA0K Pj4+PiANCj4+Pj4gDQo+Pj4+IEhpIERlYm9yYWgsDQo+Pj4+IA0KPj4+PiBJIGhhdmUgYSBmZXcg Y29tbWVudHMgcmVnYXJkaW5nIHRoZSBwcm9wb3NlZCBhYnN0cmFjdDoNCj4+Pj4gDQo+Pj4+ICog ICAgICAgICBJIHRoaW5rIHdlIHNob3VsZCBzYXkgIlRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIHRo ZQ0KPj4+PiByZXF1aXJlbWVudHMgZm9yIE1QTFMtVFAgaW4gb3JkZXIgdG8gc3VwcG9ydCBjYXBh YmlsaXRpZXMgYW5kDQo+Pj4+IGZ1bmN0aW9uYWxpdGllcyBhcyBuZWVkZWQgaW4gdHJhbnNwb3J0 IGVudmlyb25tZW50cyAob3IgbmV0d29ya3MpLg0KPj4+PiANCj4+Pj4gKiAgICAgICAgIEkgZG8g bm90IHVuZGVyc3RhbmQgdGhlIHNlbnRlbmNlOiBJdCBkb2VzIG5vdA0KPj4gYWRkcmVzcyBJRVRG DQo+Pj4+IHByb3RvY29sIGFwcGxpY2FiaWxpdHkgb3IgY2FwYWJpbGl0aWVzLiBEbyB5b3UgbWVh bg0KPj4gYXBwbGljYWJpbGl0eSBvcg0KPj4+PiBjYXBhYmlsaXR5IG9mIHRoZSBjdXJyZW50IElF VEYgZG9jdW1lbnRzPyBBcyBJTU8gaXQgd2lsbCBiZSBvZiB0aGUNCj4+Pj4gZG9jdW1lbnRzIHdl IGdlbmVyYXRlIGZvciBNUExTLVRQLg0KPj4+PiANCj4+Pj4gKiAgICAgICAgIEkgdGhpbmsgaXQg aXMgaW1wb3J0YW50IHRvIGluZGljYXRlIHRoYXQgIiBUaGlzDQo+PiBkb2N1bWVudCBpcw0KPj4+ IGENCj4+Pj4gcHJvZHVjdCBvZiBhIGpvaW50IElUVS1JRVRGIGVmZm9ydCIuDQo+Pj4+IA0KPj4+ PiBCZXN0IHJlZ2FyZHMsDQo+Pj4+IA0KPj4+PiBOdXJpdA0KPj4+PiANCj4+Pj4gIA0KPj4+PiAN Cj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4gRnJvbTogbXBscy1pbnRlcm9w LWJvdW5jZXNAaWV0Zi5vcmcNCj4+Pj4gW21haWx0bzptcGxzLWludGVyb3AtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIGV4dCBCUlVOR0FSRCwNCj4+Pj4gREVCT1JBSCBBLCBBVFRMQUJT DQo+Pj4+IFNlbnQ6IFRodXJzZGF5LCBKdW5lIDE5LCAyMDA4IDIxOjExDQo+Pj4+IFRvOiBNRUFE IHRlYW0NCj4+Pj4gU3ViamVjdDogUmU6IFtNcGxzLWludGVyb3BdIG5leHQgTUVBRCB0ZWFtIG1l ZXRpbmcNCj4+Pj4gDQo+Pj4+ICANCj4+Pj4gDQo+Pj4+IENvbGxlYWd1ZXMsDQo+Pj4+IA0KPj4+ PiAgDQo+Pj4+IA0KPj4+PiBJIHdhcyB0aGlua2luZyBmb3IgdGhlIHJlcXVpcmVtZW50cyB3ZSBz aG91bGQgaW5jbHVkZSBhDQo+PiBzZW50ZW5jZSBpbiANCj4+Pj4gdGhlDQo+Pj4+IA0KPj4+PiBh YnN0cmFjdCB0byBzY29wZSB0aGUgTVBMUy1UUCB3b3JrIGFzIGJlaW5nIHBhcnQgb2YgYQ0KPj4g am9pbnQgSVRVLUlFVEYNCj4+Pj4gDQo+Pj4+IGVmZm9ydC4gTm90IGFsbCByZWFkZXJzIChub3cg YW5kIGZ1dHVyZSkgd2lsbCBiZSBhd2FyZSBvZg0KPj4gd2h5IHRoaXMgaXMNCj4+Pj4gDQo+Pj4+ IGJlaW5nIGRvbmUuIEluIGNjYW1wLCB3ZSBoYWQgZG9uZSB0aGlzIGZvciBvdXIgQVNPTiB3b3Jr LiBNYXliZSBhDQo+Pj4+IA0KPj4+PiBzaW1pbGFyIHNlbnRlbmNlIHdpbGwgYmUgbmVlZGVkIGlu IHRoZSBvdGhlciBkb2N1bWVudHM/DQo+PiBTaG91bGQgd2UgaGF2ZQ0KPj4+IA0KPj4+PiBhDQo+ Pj4+IA0KPj4+PiBjb21tb24gc2VudGVuY2U/DQo+Pj4+IA0KPj4+PiAgDQo+Pj4+IA0KPj4+PiBI b3cgYWJvdXQgZm9yIHRoZSBhYnN0cmFjdDoNCj4+Pj4gDQo+Pj4+IFRoaXMgZG9jdW1lbnQgc3Vt bWFyaXplcyB0aGUgSVRVLVQgcmVxdWlyZW1lbnRzIGZvcg0KPj4gTVBMUy1UUCBpbiBvcmRlcg0K Pj4+PiB0bw0KPj4+PiANCj4+Pj4gc3VwcG9ydCBjYXBhYmlsaXRpZXMgYW5kIGZ1bmN0aW9uYWxp dGllcyBhcyBuZWVkZWQgYnkgdGhlDQo+PiBJVFUtVC4gSXQgDQo+Pj4+IGRvZXMNCj4+Pj4gDQo+ Pj4+IG5vdCBhZGRyZXNzIElFVEYgcHJvdG9jb2wgYXBwbGljYWJpbGl0eSBvciBjYXBhYmlsaXRp ZXMuDQo+PiBUaGlzIGRvY3VtZW50DQo+Pj4+IA0KPj4+PiBpcyBhIHByb2R1Y3Qgb2YgYSBqb2lu dCBJVFUtSUVURiBlZmZvcnQuDQo+Pj4+IA0KPj4+PiAgDQo+Pj4+IA0KPj4+PiBEZWJvcmFoDQo+ Pj4+IA0KPj4+PiAgDQo+Pj4+IA0KPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+ PiANCj4+Pj4gRnJvbTogbXBscy1pbnRlcm9wLWJvdW5jZXNAaWV0Zi5vcmcNCj4+Pj4gDQo+Pj4+ IFttYWlsdG86bXBscy1pbnRlcm9wLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCZW4N Cj4+IE5pdmVuLUplbmtpbnMNCj4+Pj4gDQo+Pj4+IFNlbnQ6IFRodXJzZGF5LCBKdW5lIDE5LCAy MDA4IDE6MjEgUE0NCj4+Pj4gDQo+Pj4+IFRvOiBMb2EgQW5kZXJzc29uOyBNRUFEIHRlYW0NCj4+ Pj4gDQo+Pj4+IFN1YmplY3Q6IFJlOiBbTXBscy1pbnRlcm9wXSBuZXh0IE1FQUQgdGVhbSBtZWV0 aW5nDQo+Pj4+IA0KPj4+PiAgDQo+Pj4+IA0KPj4+PiBDb2xsZWFndWVzLA0KPj4+PiANCj4+Pj4g IA0KPj4+PiANCj4+Pj4gRllJIHNlZSBhdHRhY2hlZCBmb3IgdGhlIGxhdGVzdCBkcmFmdCBvZiB0 aGUgTVBMUy1UUCByZXF1aXJlbWVudHMNCj4+PiBkcmFmdC4NCj4+Pj4gIA0KPj4+PiANCj4+Pj4g QmVuDQo+Pj4+IA0KPj4+PiAgDQo+Pj4+IA0KPj4+PiAgDQo+Pj4+IA0KPj4+PiAgDQo+Pj4+IA0K Pj4+PiBPbiAxOS8wNi8yMDA4IDE2OjAwLCAiTG9hIEFuZGVyc3NvbiIgPGxvYUBwaS5udT4gd3Jv dGU6DQo+Pj4+IA0KPj4+PiAgDQo+Pj4+IA0KPj4+Pj4gQWxsLA0KPj4+PiANCj4+Pj4+IHRoZSBN RUFEIHRlYW0gd2lsbCBoYXZlIHRoZSBuZXh0IG1lZXRpbmcgb24gVHVlc2RheSAyNCwgYXQgNnBt DQo+Pj4+PiBpLmUuIDEyYW0gZWFzdCBjb2FzdCBhbmQgOWFtIENhbGlmb3JuaWEuDQo+Pj4+IA0K Pj4+Pj4gQWdhaW4gSSBwbGFuIHRoZSBtZWV0aW5nIHRvIGxhc3QgYW4gaG91ciwgYW5kIGZvY3Vz IHdpbGwgYmUgb24gdGhlDQo+Pj4+PiBkb2N1bWVudCBzdGF0dXMuDQo+Pj4+IA0KPj4+Pj4gU3Rl d2FydCB3aWxsIHNlbmQgb3V0IGRpYWwgaW4gZGV0YWlscyBhcyB1c3VhbC4NCj4+Pj4gDQo+Pj4+ PiAvTG9hDQo+Pj4+ICANCj4+Pj4gDQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+Pj4+IA0KPj4+PiBNcGxzLWludGVyb3AgbWFpbGluZyBsaXN0 DQo+Pj4+IA0KPj4+PiBNcGxzLWludGVyb3BAaWV0Zi5vcmcNCj4+Pj4gDQo+Pj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscy1pbnRlcm9wDQo+Pj4+IA0KPj4+PiAN Cj4+Pj4gDQo+Pj4+IA0KPj4+PiANCj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4gLS0NCj4+Pj4gDQo+ Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+ IE1wbHMtaW50ZXJvcCBtYWlsaW5nIGxpc3QNCj4+Pj4gTXBscy1pbnRlcm9wQGlldGYub3JnDQo+ Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscy1pbnRlcm9wDQo+ Pj4gDQo+Pj4gDQo+Pj4gLS0NCj4+PiBMb2EgQW5kZXJzc29uDQo+Pj4gDQo+Pj4gUHJpbmNpcGFs IE5ldHdvcmtpbmcgQXJjaGl0ZWN0DQo+Pj4gQWNyZW8gQUIgICAgICAgICAgICAgICAgICAgICAg ICAgICBwaG9uZTogICs0NiA4IDYzMiA3NyAxNA0KPj4+IElzYWZqb3Jkc2dhdGFuIDIyICAgICAg ICAgICAgICAgICAgbW9iaWxlOiArNDYgNzM5IDgxIDIxIDY0DQo+Pj4gS2lzdGEsIFN3ZWRlbiAg ICAgICAgICAgICAgICAgICAgICBlbWFpbDogIGxvYS5hbmRlcnNzb25AYWNyZW8uc2UNCj4+PiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGxvYUBwaS5udQ0KPj4g DQo+PiANCj4+IC0tIA0KPj4gTG9hIEFuZGVyc3Nvbg0KPj4gDQo+PiBQcmluY2lwYWwgTmV0d29y a2luZyBBcmNoaXRlY3QNCj4+IEFjcmVvIEFCICAgICAgICAgICAgICAgICAgICAgICAgICAgcGhv bmU6ICArNDYgOCA2MzIgNzcgMTQNCj4+IElzYWZqb3Jkc2dhdGFuIDIyICAgICAgICAgICAgICAg ICAgbW9iaWxlOiArNDYgNzM5IDgxIDIxIDY0DQo+PiBLaXN0YSwgU3dlZGVuICAgICAgICAgICAg ICAgICAgICAgIGVtYWlsOiAgbG9hLmFuZGVyc3NvbkBhY3Jlby5zZQ0KPj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsb2FAcGkubnUNCj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBNcGxzLWludGVyb3AgbWFp bGluZyBsaXN0DQo+PiBNcGxzLWludGVyb3BAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbXBscy1pbnRlcm9wDQo+PiANCj4gDQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE1wbHMtaW50ZXJvcCBtYWls aW5nIGxpc3QNCj4gTXBscy1pbnRlcm9wQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbXBscy1pbnRlcm9wDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpNcGxzLWludGVyb3AgbWFpbGluZyBsaXN0DQpNcGxz LWludGVyb3BAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bXBscy1pbnRlcm9wDQo= ------_=_NextPart_001_01C8D602.1602CF33 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMg RXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNi41Ljc2NTIuMjQiPg0KPFRJVExFPlJlOiBbTXBscy1p bnRlcm9wXSBNUExTLVRQIFJlcXVpcmVtZW50cyBBYnN0cmFjdCAod2FzIFJFOiBuZXh0IE1FQUQg dGVhbSBtZWV0aW5nKTwvVElUTEU+DQo8L0hFQUQ+DQo8Qk9EWT4NCjwhLS0gQ29udmVydGVkIGZy b20gdGV4dC9wbGFpbiBmb3JtYXQgLS0+DQoNCjxQPjxGT05UIFNJWkU9Mj4mbmJzcDtCZW4sPEJS Pg0KPEJSPg0KSSBhZ3JlZSwgdGhhdCdzIG11Y2ggYmV0dGVyLjxCUj4NCjxCUj4NCkNoZWVycyw8 QlI+DQpBbmR5PEJSPg0KPEJSPg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLTxCUj4NCkZy b206IG1wbHMtaW50ZXJvcC1ib3VuY2VzQGlldGYub3JnICZsdDttcGxzLWludGVyb3AtYm91bmNl c0BpZXRmLm9yZyZndDs8QlI+DQpUbzogSXRhbG8gQnVzaSAmbHQ7SXRhbG8uQnVzaUBhbGNhdGVs LWx1Y2VudC5pdCZndDs7ICdMb2EgQW5kZXJzc29uJyAmbHQ7bG9hQHBpLm51Jmd0OzsgJ0JSVU5H QVJELCBERUJPUkFIIEEsIEFUVExBQlMnICZsdDtkYnJ1bmdhcmRAYXR0LmNvbSZndDs8QlI+DQpD YzogJ01FQUQgdGVhbScgJmx0O21wbHMtaW50ZXJvcEBpZXRmLm9yZyZndDs8QlI+DQpTZW50OiBU dWUgSnVuIDI0IDA0OjMwOjAwIDIwMDg8QlI+DQpTdWJqZWN0OiBSZTogW01wbHMtaW50ZXJvcF0g TVBMUy1UUCBSZXF1aXJlbWVudHMgQWJzdHJhY3QgKHdhcyBSRTogbmV4dCBNRUFEIHRlYW0gbWVl dGluZyk8QlI+DQo8QlI+DQpJIGRvbid0IGxpa2UgdGhpcy4mbmJzcDsgSSdtIG5vdCBjbGVhciB3 aHkgSVRVLVQgaGFzIHRvIGJlIHRoZSBvbmx5IG9yZ2FuaXNhdGlvbjxCUj4NCmRyYXduIG91dCBh cyB0aGUgc291cmNlIG9mIHRoZSByZXF1aXJlbWVudHMgYW5kIEkgZG9uJ3QgbGlrZSB0aGUgaWRl YSBvZjxCUj4NCmhhdmluZyB0byBzb21laG93IGlkZW50aWZ5L3RhZyBhbGwgcmVxdWlyZW1lbnRz IHRoYXQgYXJlIG5vdCBmcm9tIHRoZSBJVFUtVDxCUj4NCmFzIEkgYmVsaWV2ZSB0aGlzIHRvIGJl IGFuIHVubmVjZXNzYXJ5IGVkaXRvcmlhbCBvdmVyaGVhZCB3aGljaCB3aWxsIG9ubHk8QlI+DQpn ZXQgd29yc2UgYXMgdGhlIGRvY3VtZW50IGV2b2x2ZXMuPEJSPg0KPEJSPg0KSG93IGFib3V0IHRo aXM/PEJSPg0KPEJSPg0KJnF1b3Q7PEJSPg0KVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgdGhlIHJl cXVpcmVtZW50cyBmb3IgYW4gTVBMUyBUcmFuc3BvcnQgUHJvZmlsZTxCUj4NCihNUExTLVRQKSBp biBvcmRlciB0byBzdXBwb3J0IHRoZSBjYXBhYmlsaXRpZXMgYW5kIGZ1bmN0aW9uYWxpdGllcyBu ZWVkZWQ8QlI+DQpmb3IgcGFja2V0IHRyYW5zcG9ydCBuZXR3b3JrIHNlcnZpY2VzIGFuZCBwYWNr ZXQgdHJhbnNwb3J0IG5ldHdvcms8QlI+DQpvcGVyYXRpb25zLjxCUj4NCjxCUj4NClRoZXNlIHJl cXVpcmVtZW50cyBhcmUgYSBjb21iaW5hdGlvbiBvZiB0aG9zZSBkZXJpdmVkIGZyb20gdGhlIHNl dCBvZjxCUj4NCnJlcXVpcmVtZW50cyBzcGVjaWZpZWQgYnkgSVRVLVQgYW5kIHJlcXVpcmVtZW50 cyByZWNlaXZlZCBkaXJlY3RseSBmcm9tPEJSPg0KU2VydmljZSBQcm92aWRlcnMuPEJSPg0KPEJS Pg0KVGhpcyBkb2N1bWVudCBpcyBhIHByb2R1Y3Qgb2YgYSBqb2ludCBJVFUtSUVURiBlZmZvcnQu PEJSPg0KJnF1b3Q7PEJSPg0KPEJSPg0KQmVuPEJSPg0KPEJSPg0KPEJSPg0KT24gMjMvMDYvMjAw OCAwOTozOCwgJnF1b3Q7SXRhbG8gQnVzaSZxdW90OyAmbHQ7SXRhbG8uQnVzaUBhbGNhdGVsLWx1 Y2VudC5pdCZndDsgd3JvdGU6PEJSPg0KPEJSPg0KJmd0OyBJZiBJIHVuZGVyc3RhbmQgcHJvcGVy bHkgdGhlIGFyZ3VtZW50cyBpbiB0aGlzIGRpc2N1c3Npb24sIGl0IHNlZW1zIHF1aXRlPEJSPg0K Jmd0OyBpbXBvcnRhbnQgdG8gY2xhcmlmeSBpbiB0aGUgc2NvcGUgdGhhdCB0aGVzZSByZXF1aXJl bWVudHMgYXJlIFNQIHJlcXVpcmVtZW50czxCUj4NCiZndDsgYXM8QlI+DQomZ3Q7IHdlbGwgYXMg dGhlIGZhY3QgdGhhdCB0aGUgc291cmNlIG9mIG1vc3Qgb2YgdGhlbSAoaWYgbm90IGFsbCkgaXMg SVRVLVQuPEJSPg0KJmd0OzxCUj4NCiZndDsgV2hhdCBhYm91dCB0aGUgZm9sbG93aW5nIGFic3Ry YWN0PzxCUj4NCiZndDs8QlI+DQomZ3Q7ICZxdW90OzxCUj4NCiZndDsgVGhpcyBkb2N1bWVudCBz cGVjaWZpZXMgdGhlIHJlcXVpcmVtZW50cyBmb3IgYW4gTVBMUyBUcmFuc3BvcnQgUHJvZmlsZTxC Uj4NCiZndDsgKE1QTFMtVFApPEJSPg0KJmd0OyBpbiBvcmRlciB0byBzdXBwb3J0IGNhcGFiaWxp dGllcyBhbmQgZnVuY3Rpb25hbGl0aWVzIGFzIG5lZWRlZCBmb3IgcGFja2V0PEJSPg0KJmd0OyB0 cmFuc3BvcnQgbmV0d29yayBzZXJ2aWNlcyBhbmQgbmV0d29yayBvcGVyYXRpb25zLjxCUj4NCiZn dDs8QlI+DQomZ3Q7IFVubGVzcyBleHBsaWNpdGx5IG1lbnRpb25lZCwgdGhlc2UgcmVxdWlyZW1l bnRzIGFyZSBkZXJpdmVkIGZyb20gdGhlIHNldCBvZjxCUj4NCiZndDsgcmVxdWlyZW1lbnRzIHNw ZWNpZmllZCBieSBJVFUtVC48QlI+DQomZ3Q7PEJSPg0KJmd0OyBUaGlzIGRvY3VtZW50IGlzIGEg cHJvZHVjdCBvZiBhIGpvaW50IElUVS1JRVRGIGVmZm9ydC48QlI+DQomZ3Q7ICZxdW90OzxCUj4N CiZndDs8QlI+DQomZ3Q7IFRoYW5rcywgSXRhbG88QlI+DQomZ3Q7PEJSPg0KJmd0OyZndDsgLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08QlI+DQomZ3Q7Jmd0OyBGcm9tOiBtcGxzLWludGVyb3At Ym91bmNlc0BpZXRmLm9yZzxCUj4NCiZndDsmZ3Q7IFs8QSBIUkVGPSJtYWlsdG86bXBscy1pbnRl cm9wLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzptcGxzLWludGVyb3AtYm91bmNlc0BpZXRmLm9y ZzwvQT5dIE9uIEJlaGFsZiBPZiBMb2EgQW5kZXJzc29uPEJSPg0KJmd0OyZndDsgU2VudDogRnJp ZGF5LCBKdW5lIDIwLCAyMDA4IDc6MjUgUE08QlI+DQomZ3Q7Jmd0OyBUbzogQlJVTkdBUkQsIERF Qk9SQUggQSwgQVRUTEFCUzxCUj4NCiZndDsmZ3Q7IENjOiBNRUFEIHRlYW08QlI+DQomZ3Q7Jmd0 OyBTdWJqZWN0OiBSZTogW01wbHMtaW50ZXJvcF0gbmV4dCBNRUFEIHRlYW0gbWVldGluZzxCUj4N CiZndDsmZ3Q7PEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7IEJSVU5H QVJELCBERUJPUkFIIEEsIEFUVExBQlMgd3JvdGU6PEJSPg0KJmd0OyZndDsmZ3Q7IEhpLDxCUj4N CiZndDsmZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jmd0OyBUaGFua3MgTG9hIGZvciB0aGUgaGludC4g TXkgdW5kZXJzdGFuZGluZyBvZiB0aGUgY2hhcnRlcjxCUj4NCiZndDsmZ3Q7IHdhcyB0byBjYXB0 dXJlPEJSPg0KJmd0OyZndDsmZ3Q7IHRoZSBJVFUgcmVxdWlyZW1lbnRzPzxCUj4NCiZndDsmZ3Q7 PEJSPg0KJmd0OyZndDsgeWVzIC0gdGhhdCBpcyB0cnVlLi4uPEJSPg0KJmd0OyZndDs8QlI+DQom Z3Q7Jmd0OyBidXQgd2UgYWxzbyBuZWVkIHRvIGNhcHR1cmUgYWxsIHJlcXVpcmVtZW50cyBmb3Ig dGhlIE1QTFMtVFAgd2hldGhlcjxCUj4NCiZndDsmZ3Q7IHRoZXkgYXJlIGluIHRoZSBjYXB0dXJl ZCBieSB0aGUgSVRVLVQgb3Igbm90LjxCUj4NCiZndDsmZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jmd0 OyBXaGF0IGlzIHRoZSBNRUFEIGRldmVsb3BtZW50IHdvcmsgY292ZXJpbmcgLSBib3RoIElUVTxC Uj4NCiZndDsmZ3Q7IHJlcXVpcmVtZW50cyBhbmQ8QlI+DQomZ3Q7Jmd0OyZndDsgJnF1b3Q7b3Ro ZXIgKGFub255bW91cykgU1BzIHJlcXVpcmVtZW50cyZxdW90Oz88QlI+DQomZ3Q7Jmd0OzxCUj4N CiZndDsmZ3Q7IGlmIHRoZXJlIGlzICZxdW90O29ubHkmcXVvdDsgcmVxdWlyZW1lbnRzIHRoYXQg b3JpZ2luYXRlcyBmcm9tIElUVS1UIHRoaXMgaXM8QlI+DQomZ3Q7Jmd0OyBub3QgYSBwcm9ibGVt LiBJIGFtIG5vdCBsb29raW5nIGZvciBhbm9ueW1vdXMgcmVxdWlyZW1lbnRzLCBpZiB0aGVyZTxC Uj4NCiZndDsmZ3Q7IGlzIGEgcmVxdWlyZW1lbnQgdGhhdCBpcyBub3QgZnJvbSBJVFUtVCB3ZSBz aG91bGQgbWFrZSBjbGVhciB3aGVyZSBpdDxCUj4NCiZndDsmZ3Q7IGNhbWUgZm9ybTxCUj4NCiZn dDsmZ3Q7PEJSPg0KJmd0OyZndDsgL0xvYTxCUj4NCiZndDsmZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7 Jmd0OyBEZWJvcmFoPEJSPg0KJmd0OyZndDsmZ3Q7Jm5ic3A7PEJSPg0KJmd0OyZndDsmZ3Q7PEJS Pg0KJmd0OyZndDsmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPEJSPg0KJmd0OyZndDsm Z3Q7IEZyb206IFNwcmVjaGVyLCBOdXJpdCAoTlNOIC0gSUwvSXNyYWVsIC0gTWluaU1EKTxCUj4N CiZndDsmZ3Q7Jmd0OyBbPEEgSFJFRj0ibWFpbHRvOm51cml0LnNwcmVjaGVyQG5zbi5jb20iPm1h aWx0bzpudXJpdC5zcHJlY2hlckBuc24uY29tPC9BPl08QlI+DQomZ3Q7Jmd0OyZndDsgU2VudDog RnJpZGF5LCBKdW5lIDIwLCAyMDA4IDU6MjMgQU08QlI+DQomZ3Q7Jmd0OyZndDsgVG86IGV4dCBM b2EgQW5kZXJzc29uPEJSPg0KJmd0OyZndDsmZ3Q7IENjOiBCUlVOR0FSRCwgREVCT1JBSCBBLCBB VFRMQUJTOyBNRUFEIHRlYW07IFNwcmVjaGVyLCBOdXJpdCAoTlNOIC08QlI+DQomZ3Q7Jmd0OyZn dDsgSUwvSXNyYWVsIC0gTWluaU1EKTxCUj4NCiZndDsmZ3Q7Jmd0OyBTdWJqZWN0OiBSRTogW01w bHMtaW50ZXJvcF0gbmV4dCBNRUFEIHRlYW0gbWVldGluZzxCUj4NCiZndDsmZ3Q7Jmd0OzxCUj4N CiZndDsmZ3Q7Jmd0OyBIaSw8QlI+DQomZ3Q7Jmd0OyZndDsgMS4gSSBhZ3JlZSB0aGF0IHZhbGlk YXRlcyBtYXkgYmUgYSBnb29kIG9wdGlvbi48QlI+DQomZ3Q7Jmd0OyZndDsgMi4gSU1PLCB0aGVz ZSByZXF1aXJlbWVudHMgYXJlIG5vdCBvbmx5IHRoZSBJVFUtVCB2aWV3LiBJIGdvdCB0aGVzZTxC Uj4NCiZndDsmZ3Q7Jmd0OyByZXF1aXJlbWVudHMgZnJvbSBkaWZmZXJlbnQgU1BzLiBBcyBJIGlu ZGljYXRlZCBpbiB0aGU8QlI+DQomZ3Q7Jmd0OyBiZWdpbm5pbmcgb2YgdGhlPEJSPg0KJmd0OyZn dDsmZ3Q7IG1haWwgZXhjaGFuZ2VzIEkgd291bGQgcHJlZmVyIHRvIHNheTogJnF1b3Q7VGhpcyBk b2N1bWVudCBzcGVjaWZpZXMgdGhlPEJSPg0KJmd0OyZndDsmZ3Q7IHJlcXVpcmVtZW50cyBmb3Ig TVBMUy1UUCBpbiBvcmRlciB0byBzdXBwb3J0IGNhcGFiaWxpdGllcyBhbmQ8QlI+DQomZ3Q7Jmd0 OyZndDsgZnVuY3Rpb25hbGl0aWVzIGFzIG5lZWRlZCBpbiB0cmFuc3BvcnQgZW52aXJvbm1lbnRz IChvcjxCUj4NCiZndDsmZ3Q7IG5ldHdvcmtzKS4mcXVvdDsgQnV0PEJSPg0KJmd0OyZndDsmZ3Q7 IHRoaXMgaXMgc29tZXRoaW5nIHRoYXQgd2UgbmVlZCB0aGUgU1BzIHRvIGFncmVlIG9uLjxCUj4N CiZndDsmZ3Q7Jmd0OyBQbGVhc2Ugbm90ZSBhbHNvIHRoYXQgaW4gdGhlIHByb3Bvc2FsIGp1c3Qg YmVsb3cgSSBmb3Jnb3Q8QlI+DQomZ3Q7Jmd0OyB0byBpbmNsdWRlIHRoZTxCUj4NCiZndDsmZ3Q7 Jmd0OyBpbmRpY2F0aW9uIHRoYXQgdGhpcyBpcyBhIGpvaW50IHdvcmsgb2YgSVRVLVQgYW5kIElF VEYuPEJSPg0KJmd0OyZndDsmZ3Q7IEJlc3QgcmVnYXJkcyw8QlI+DQomZ3Q7Jmd0OyZndDsgTnVy aXQ8QlI+DQomZ3Q7Jmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZndDsg LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08QlI+DQomZ3Q7Jmd0OyZndDsgRnJvbTogZXh0IExv YSBBbmRlcnNzb24gWzxBIEhSRUY9Im1haWx0bzpsb2FAcGkubnUiPm1haWx0bzpsb2FAcGkubnU8 L0E+XTxCUj4NCiZndDsmZ3Q7Jmd0OyBTZW50OiBGcmlkYXksIEp1bmUgMjAsIDIwMDggMTE6NTc8 QlI+DQomZ3Q7Jmd0OyZndDsgVG86IFNwcmVjaGVyLCBOdXJpdCAoTlNOIC0gSUwvSXNyYWVsIC0g TWluaU1EKTxCUj4NCiZndDsmZ3Q7Jmd0OyBDYzogZXh0IEJSVU5HQVJELCBERUJPUkFIIEEsIEFU VExBQlM7IE1FQUQgdGVhbTxCUj4NCiZndDsmZ3Q7Jmd0OyBTdWJqZWN0OiBSZTogW01wbHMtaW50 ZXJvcF0gbmV4dCBNRUFEIHRlYW0gbWVldGluZzxCUj4NCiZndDsmZ3Q7Jmd0OzxCUj4NCiZndDsm Z3Q7Jmd0OyBBbGwsPEJSPg0KJmd0OyZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmZ3Q7IGp1c3QgYSBm ZXcgY29tbWVudHMuPEJSPg0KJmd0OyZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmZ3Q7IFNwcmVjaGVy LCBOdXJpdCAoTlNOIC0gSUwvSXNyYWVsIC0gTWluaU1EKSB3cm90ZTo8QlI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7IEhpIERlYm9yYWgsPEJSPg0KJmd0OyZndDsmZ3Q7Jmd0OyBJIHVuZGVyc3RhbmQgdGhl IGludGVudGlvbiwgc28gaG93IGFib3V0IHRoZSBmb2xsb3dpbmcgKGFzIHdlIGFsc288QlI+DQom Z3Q7Jmd0OyZndDsmZ3Q7IGluZGljYXRlZCBpbiB0aGUgaW50cm9kdWN0aW9uKTo8QlI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7IFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzPEJSPg0KJmd0OyZndDsmZ3Q7PEJS Pg0KJmd0OyZndDsmZ3Q7IEkgd29uZGVyIGlmICZxdW90O3NwZWNpZmllcyZxdW90OyBpcyB0aGUg cmlnaHQgd29yZCAtIG9uZSB3YXkgd291bGQgYmUgdG8gc2F5PEJSPg0KJmd0OyZndDsmZ3Q7ICZx dW90O3ZhbGlkYXRlcyZxdW90OyBpbmRpY2F0aW5nIHRoYXQgdGhpcyBob3cgd2UgKElFVEYpIHVu ZGVyc3RhbmRzIHRoZXNlPEJSPg0KJmd0OyZndDsmZ3Q7IHJlcXVpcmVtZW50czxCUj4NCiZndDsm Z3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jmd0OyB0aGUgSVRVLVQgcmVxdWlyZW1lbnRzIGZvciBNUExT LVRQIGluIG9yZGVyIHRvPEJSPg0KJmd0OyZndDsmZ3Q7Jmd0OyBzdXBwb3J0IGNhcGFiaWxpdGll cyBhbmQgZnVuY3Rpb25hbGl0aWVzIG9mIE1QTFMgYXMgbmVlZGVkIGluPEJSPg0KJmd0OyZndDsm Z3Q7Jmd0OyB0cmFuc3BvcnQgZW52aXJvbm1lbnRzLjxCUj4NCiZndDsmZ3Q7Jmd0OzxCUj4NCiZn dDsmZ3Q7Jmd0OyB0aGlzIGluZGljYXRlcyB0aGF0IHRoZXJlIGlzIG5vdGhpbmcgYnV0IElUVS1U IHJlcXVpcmVtZW50cyBpbiB0aGU8QlI+DQomZ3Q7Jmd0OyZndDsgZG9jdW1lbnQsIGlzIHRoYXQg dHJ1ZT88QlI+DQomZ3Q7Jmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZndDsgL0xvYTxCUj4NCiZndDsm Z3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jmd0OyZndDsgTVBMUyBpcyBhIG1hdHVyaW5nIHBhY2tldCB0 ZWNobm9sb2d5IGFuZCBpdCBpcyBhbHJlYWR5IHBsYXlpbmcgYW48QlI+DQomZ3Q7Jmd0OyZndDsm Z3Q7IGltcG9ydGFudCByb2xlIGluIHRyYW5zcG9ydCBuZXR3b3JrcyBhbmQgc2VydmljZXMuPEJS Pg0KJmd0OyZndDsgSG93ZXZlciwgbm90IGFsbCBvZjxCUj4NCiZndDsmZ3Q7Jmd0OzxCUj4NCiZn dDsmZ3Q7Jmd0OyZndDsgTVBMUydzIGNhcGFiaWxpdGllcyBhbmQgbWVjaG5pc21zIGFyZSBuZWVk ZWQgYW5kL29yPEJSPg0KJmd0OyZndDsgY29uc2lzdGVudCB3aXRoPEJSPg0KJmd0OyZndDsmZ3Q7 Jmd0OyB0cmFuc3BvcnQgbmV0d29yayBvcGVyYXRpb25zLiBUaGlzIGRvY3VtZW50IGlkZW50aWZp ZXMgdGhlPEJSPg0KJmd0OyZndDsgcmVxdWlyZWQ8QlI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IGNhcGFi aWxpdGllcyBmb3IgTVBMUyBzbyB0aGF0IGl0IGNhbiBiZXR0ZXIgZml0IGEgdHJhbnNwb3J0IHJv bGUuPEJSPg0KJmd0OyZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmZ3Q7Jmd0OyBQbGVhc2UgYWR2aXNl LjxCUj4NCiZndDsmZ3Q7Jmd0OyZndDsgQmVzdCByZWdhcmRzLDxCUj4NCiZndDsmZ3Q7Jmd0OyZn dDsgTnVyaXQ8QlI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmZ3Q7Jmd0OyBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj4NCiZndDsmZ3Q7Jmd0OyZndDs8QlI+DQom Z3Q7Jmd0OyZndDsmZ3Q7IEZyb206IGV4dCBCUlVOR0FSRCwgREVCT1JBSCBBLCBBVFRMQUJTIFs8 QSBIUkVGPSJtYWlsdG86ZGJydW5nYXJkQGF0dC5jb20iPm1haWx0bzpkYnJ1bmdhcmRAYXR0LmNv bTwvQT5dPEJSPg0KJmd0OyZndDsmZ3Q7Jmd0OyBTZW50OiBUaHVyc2RheSwgSnVuZSAxOSwgMjAw OCAyMzowNDxCUj4NCiZndDsmZ3Q7Jmd0OyZndDsgVG86IFNwcmVjaGVyLCBOdXJpdCAoTlNOIC0g SUwvSXNyYWVsIC0gTWluaU1EKTsgTUVBRCB0ZWFtPEJSPg0KJmd0OyZndDsmZ3Q7Jmd0OyBTdWJq ZWN0OiBSRTogW01wbHMtaW50ZXJvcF0gbmV4dCBNRUFEIHRlYW0gbWVldGluZzxCUj4NCiZndDsm Z3Q7Jmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmZ3Q7Jmd0OyBI aSBOdXJpdCw8QlI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7PEJSPg0KJmd0OyZndDsmZ3Q7Jmd0 OyBJIHdvdWxkIHByZWZlciB0byBjbGVhcmx5IHNheSB0aGUgcmVxdWlyZW1lbnRzIGFyZSBJVFU8 QlI+DQomZ3Q7Jmd0OyByZXF1aXJlbWVudHM8QlI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IGZvciBNUExT IGluIGEgdHJhbnNwb3J0IGVudmlyb25tZW50LiBJIHRoaW5rIGFtb25nIHNvbWU8QlI+DQomZ3Q7 Jmd0OyBvcGVyYXRvcnMgdGhlPEJSPg0KJmd0OyZndDsmZ3Q7Jmd0OyBsaW5lIGJldHdlZW4gdHJh bnNwb3J0IGVxdWlwbWVudCBhbmQgcGFja2V0IGVxdWlwbWVudCBoYXMgYWxyZWFkeTxCUj4NCiZn dDsmZ3Q7Jmd0OyBibHVycmVkLjxCUj4NCiZndDsmZ3Q7Jmd0OyZndDsgRm9yIG1hbnkgb3BlcmF0 b3JzLCB0aGUgcHJlZmVyZW5jZSBtYXkgYmUgdG8gYWxpZ24gd2l0aCBNUExTPEJSPg0KJmd0OyZn dDsmZ3Q7Jmd0OyBvcGVyYXRpb25zIHZzLiB0cmFuc3BvcnQuIEkgdGhpbmsgdGhlcmUgYXJlIG1h bnkgZGlmZmVyaW5nPEJSPg0KJmd0OyZndDsgb3BpbmlvbnMgb248QlI+DQomZ3Q7Jmd0OyZndDs8 QlI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IHdoYXQgTVBMUy9wYWNrZXQgdHJhbnNwb3J0IG5lZWRzIHRv IHN1cHBvcnQgaW4gYSB0cmFuc3BvcnQ8QlI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IGVudmlyb25tZW50 LiBTbyBJIHByZWZlciB0byBjbGVhcmx5IHNheSB0aGVzZSBhcmUgSVRVPEJSPg0KJmd0OyZndDsg cmVxdWlyZW1lbnRzLDxCUj4NCiZndDsmZ3Q7Jmd0OyZndDsgdGhleSBkbyBub3QgbmVjZXNzYXJp bHkgcmVmbGVjdCB0aGUgb3BlcmF0b3JzIGNvbnRyaWJ1dGluZyB0byB0aGlzPEJSPg0KJmd0OyZn dDsmZ3Q7IGRvY3VtZW50LjxCUj4NCiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8QlI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7IE9uIHRoZSAybmQgYnVsbGV0LCZuYnNwOyB0aGUgcmVxdWlyZW1lbnRzIGRvY3Vt ZW50IGhhcyBtYW55PEJSPg0KJmd0OyZndDsmZ3Q7Jmd0OyBzdGF0ZW1lbnRzL3JlcXVpcmVtZW50 cyB3aGljaCBtYXkgYmUgaW50ZXJwcmV0ZWQgYnkgYTxCUj4NCiZndDsmZ3Q7IHJlYWRlciBhcyBn YXBzPEJSPg0KJmd0OyZndDsmZ3Q7Jmd0OyBpbiBNUExTL0lFVEYgcHJvdG9jb2xzLiBJIHdhcyB0 cnlpbmcgdG8gc2F5IHdpdGggdGhpcyBzZW50ZW5jZSB0aGU8QlI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 IGRvY3VtZW50IGlzIG5vdCBhZGRyZXNzaW5nL2lkZW50aWZ5aW5nIElFVEYgcHJvdG9jb2w8QlI+ DQomZ3Q7Jmd0OyBhcHBsaWNhYmlsaXR5IG9yPEJSPg0KJmd0OyZndDsmZ3Q7Jmd0OyBsYWNrIG9m IGNhcGFiaWxpdGllcyBlLmcuIHRoZSBzZW50ZW5jZTo8QlI+DQomZ3Q7Jmd0OyZndDsmZ3Q7ICZx dW90O1F1YWxpdHktb2Ytc2VydmljZSBtZWNoYW5pc21zIGFyZSByZXF1aXJlZCBpbiB0aGUgcGFj a2V0IHRyYW5zcG9ydDxCUj4NCiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgbmV0 d29yayB0byBlbnN1cmUgdGhlIHByaW9yaXRpemF0aW9uIG9mIGNyaXRpY2FsIHNlcnZpY2VzLCB0 bzxCUj4NCiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgZ3VhcmFudGVlIEJXIGFu ZCB0byBjb250cm9sIGppdHRlciBhbmQgZGVsYXkuJnF1b3Q7PEJSPg0KJmd0OyZndDsmZ3Q7Jmd0 OzxCUj4NCiZndDsmZ3Q7Jmd0OyZndDsgUW9TIGlzIG5vdCBhIG5ldyByZXF1aXJlbWVudCBmb3Ig SUVURiBwcm90b2NvbHMuIFBhY2tldCB0cmFuc3BvcnQ8QlI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IG5l dHdvcmtzIChhbmQgdGhpcyByZXF1aXJlbWVudCBkb2N1bWVudCkgYXJlIG5vdCB0aGUgZmlyc3Q8 QlI+DQomZ3Q7Jmd0OyB0aW1lIHRoYXQ8QlI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IFFvUyBtZWNoYW5p c21zIGFyZSBpZGVudGlmaWVkIGFzIG5lZWRlZC4gVGhpcyByZXF1aXJlbWVudCBpcyBub3Q8QlI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7IGludGVuZGluZyB0byBpZGVudGlmeSBhIGdhcCBpbiB0aGUgY3Vy cmVudCBJRVRGIHByb3RvY29sPEJSPg0KJmd0OyZndDsgc2V0LiBUaGlzIHdhczxCUj4NCiZndDsm Z3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jmd0OyZndDsgd2hhdCBJIHdhcyB0cnlpbmcgdG8gc2F5LjxC Uj4NCiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8QlI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IFN1Z2dlc3Rp b25zPzxCUj4NCiZndDsmZ3Q7Jmd0OyZndDsgRGVib3JhaDxCUj4NCiZndDsmZ3Q7Jmd0OyZndDsm bmJzcDs8QlI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7PEJSPg0KJmd0OyZndDsmZ3Q7Jmd0OzxC Uj4NCiZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmZ3Q7Jmd0OyBGcm9tOiBTcHJlY2hlciwg TnVyaXQgKE5TTiAtIElML0lzcmFlbCAtIE1pbmlNRCk8QlI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IFs8 QSBIUkVGPSJtYWlsdG86bnVyaXQuc3ByZWNoZXJAbnNuLmNvbSI+bWFpbHRvOm51cml0LnNwcmVj aGVyQG5zbi5jb208L0E+XTxCUj4NCiZndDsmZ3Q7Jmd0OyZndDsgU2VudDogVGh1cnNkYXksIEp1 bmUgMTksIDIwMDggMzoxMCBQTTxCUj4NCiZndDsmZ3Q7Jmd0OyZndDsgVG86IEJSVU5HQVJELCBE RUJPUkFIIEEsIEFUVExBQlM7IE1FQUQgdGVhbTxCUj4NCiZndDsmZ3Q7Jmd0OyZndDsgQ2M6IFNw cmVjaGVyLCBOdXJpdCAoTlNOIC0gSUwvSXNyYWVsIC0gTWluaU1EKTxCUj4NCiZndDsmZ3Q7Jmd0 OyZndDsgU3ViamVjdDogUkU6IFtNcGxzLWludGVyb3BdIG5leHQgTUVBRCB0ZWFtIG1lZXRpbmc8 QlI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7 Jmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IEhpIERlYm9yYWgsPEJSPg0KJmd0OyZndDsm Z3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jmd0OyZndDsgSSBoYXZlIGEgZmV3IGNvbW1lbnRzIHJlZ2Fy ZGluZyB0aGUgcHJvcG9zZWQgYWJzdHJhY3Q6PEJSPg0KJmd0OyZndDsmZ3Q7Jmd0OzxCUj4NCiZn dDsmZ3Q7Jmd0OyZndDsgKiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBJIHRoaW5rIHdlIHNob3VsZCBzYXkgJnF1b3Q7VGhpcyBkb2N1bWVudCBzcGVjaWZp ZXMgdGhlPEJSPg0KJmd0OyZndDsmZ3Q7Jmd0OyByZXF1aXJlbWVudHMgZm9yIE1QTFMtVFAgaW4g b3JkZXIgdG8gc3VwcG9ydCBjYXBhYmlsaXRpZXMgYW5kPEJSPg0KJmd0OyZndDsmZ3Q7Jmd0OyBm dW5jdGlvbmFsaXRpZXMgYXMgbmVlZGVkIGluIHRyYW5zcG9ydCBlbnZpcm9ubWVudHMgKG9yIG5l dHdvcmtzKS48QlI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmZ3Q7Jmd0OyAqJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEkgZG8gbm90IHVu ZGVyc3RhbmQgdGhlIHNlbnRlbmNlOiBJdCBkb2VzIG5vdDxCUj4NCiZndDsmZ3Q7IGFkZHJlc3Mg SUVURjxCUj4NCiZndDsmZ3Q7Jmd0OyZndDsgcHJvdG9jb2wgYXBwbGljYWJpbGl0eSBvciBjYXBh YmlsaXRpZXMuIERvIHlvdSBtZWFuPEJSPg0KJmd0OyZndDsgYXBwbGljYWJpbGl0eSBvcjxCUj4N CiZndDsmZ3Q7Jmd0OyZndDsgY2FwYWJpbGl0eSBvZiB0aGUgY3VycmVudCBJRVRGIGRvY3VtZW50 cz8gQXMgSU1PIGl0IHdpbGwgYmUgb2YgdGhlPEJSPg0KJmd0OyZndDsmZ3Q7Jmd0OyBkb2N1bWVu dHMgd2UgZ2VuZXJhdGUgZm9yIE1QTFMtVFAuPEJSPg0KJmd0OyZndDsmZ3Q7Jmd0OzxCUj4NCiZn dDsmZ3Q7Jmd0OyZndDsgKiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBJIHRoaW5rIGl0IGlzIGltcG9ydGFudCB0byBpbmRpY2F0ZSB0aGF0ICZxdW90OyBU aGlzPEJSPg0KJmd0OyZndDsgZG9jdW1lbnQgaXM8QlI+DQomZ3Q7Jmd0OyZndDsgYTxCUj4NCiZn dDsmZ3Q7Jmd0OyZndDsgcHJvZHVjdCBvZiBhIGpvaW50IElUVS1JRVRGIGVmZm9ydCZxdW90Oy48 QlI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmZ3Q7Jmd0OyBCZXN0IHJlZ2FyZHMs PEJSPg0KJmd0OyZndDsmZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jmd0OyZndDsgTnVyaXQ8QlI+DQom Z3Q7Jmd0OyZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzxCUj4NCiZndDsmZ3Q7 Jmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t PEJSPg0KJmd0OyZndDsmZ3Q7Jmd0OyBGcm9tOiBtcGxzLWludGVyb3AtYm91bmNlc0BpZXRmLm9y ZzxCUj4NCiZndDsmZ3Q7Jmd0OyZndDsgWzxBIEhSRUY9Im1haWx0bzptcGxzLWludGVyb3AtYm91 bmNlc0BpZXRmLm9yZyI+bWFpbHRvOm1wbHMtaW50ZXJvcC1ib3VuY2VzQGlldGYub3JnPC9BPl0g T24gQmVoYWxmIE9mIGV4dCBCUlVOR0FSRCw8QlI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IERFQk9SQUgg QSwgQVRUTEFCUzxCUj4NCiZndDsmZ3Q7Jmd0OyZndDsgU2VudDogVGh1cnNkYXksIEp1bmUgMTks IDIwMDggMjE6MTE8QlI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IFRvOiBNRUFEIHRlYW08QlI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBbTXBscy1pbnRlcm9wXSBuZXh0IE1FQUQgdGVhbSBt ZWV0aW5nPEJSPg0KJmd0OyZndDsmZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8 QlI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmZ3Q7Jmd0OyBDb2xsZWFndWVzLDxC Uj4NCiZndDsmZ3Q7Jmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7PEJSPg0KJmd0 OyZndDsmZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jmd0OyZndDsgSSB3YXMgdGhpbmtpbmcgZm9yIHRo ZSByZXF1aXJlbWVudHMgd2Ugc2hvdWxkIGluY2x1ZGUgYTxCUj4NCiZndDsmZ3Q7IHNlbnRlbmNl IGluPEJSPg0KJmd0OyZndDsmZ3Q7Jmd0OyB0aGU8QlI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PEJSPg0K Jmd0OyZndDsmZ3Q7Jmd0OyBhYnN0cmFjdCB0byBzY29wZSB0aGUgTVBMUy1UUCB3b3JrIGFzIGJl aW5nIHBhcnQgb2YgYTxCUj4NCiZndDsmZ3Q7IGpvaW50IElUVS1JRVRGPEJSPg0KJmd0OyZndDsm Z3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jmd0OyZndDsgZWZmb3J0LiBOb3QgYWxsIHJlYWRlcnMgKG5v dyBhbmQgZnV0dXJlKSB3aWxsIGJlIGF3YXJlIG9mPEJSPg0KJmd0OyZndDsgd2h5IHRoaXMgaXM8 QlI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmZ3Q7Jmd0OyBiZWluZyBkb25lLiBJ biBjY2FtcCwgd2UgaGFkIGRvbmUgdGhpcyBmb3Igb3VyIEFTT04gd29yay4gTWF5YmUgYTxCUj4N CiZndDsmZ3Q7Jmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IHNpbWlsYXIgc2VudGVuY2Ug d2lsbCBiZSBuZWVkZWQgaW4gdGhlIG90aGVyIGRvY3VtZW50cz88QlI+DQomZ3Q7Jmd0OyBTaG91 bGQgd2UgaGF2ZTxCUj4NCiZndDsmZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jmd0OyZndDsgYTxCUj4N CiZndDsmZ3Q7Jmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IGNvbW1vbiBzZW50ZW5jZT88 QlI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzxCUj4NCiZn dDsmZ3Q7Jmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IEhvdyBhYm91dCBmb3IgdGhlIGFi c3RyYWN0OjxCUj4NCiZndDsmZ3Q7Jmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IFRoaXMg ZG9jdW1lbnQgc3VtbWFyaXplcyB0aGUgSVRVLVQgcmVxdWlyZW1lbnRzIGZvcjxCUj4NCiZndDsm Z3Q7IE1QTFMtVFAgaW4gb3JkZXI8QlI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IHRvPEJSPg0KJmd0OyZn dDsmZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jmd0OyZndDsgc3VwcG9ydCBjYXBhYmlsaXRpZXMgYW5k IGZ1bmN0aW9uYWxpdGllcyBhcyBuZWVkZWQgYnkgdGhlPEJSPg0KJmd0OyZndDsgSVRVLVQuIEl0 PEJSPg0KJmd0OyZndDsmZ3Q7Jmd0OyBkb2VzPEJSPg0KJmd0OyZndDsmZ3Q7Jmd0OzxCUj4NCiZn dDsmZ3Q7Jmd0OyZndDsgbm90IGFkZHJlc3MgSUVURiBwcm90b2NvbCBhcHBsaWNhYmlsaXR5IG9y IGNhcGFiaWxpdGllcy48QlI+DQomZ3Q7Jmd0OyBUaGlzIGRvY3VtZW50PEJSPg0KJmd0OyZndDsm Z3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jmd0OyZndDsgaXMgYSBwcm9kdWN0IG9mIGEgam9pbnQgSVRV LUlFVEYgZWZmb3J0LjxCUj4NCiZndDsmZ3Q7Jmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jm5ic3A7PEJSPg0KJmd0OyZndDsmZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jmd0OyZndDsgRGVib3Jh aDxCUj4NCiZndDsmZ3Q7Jmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7PEJSPg0K Jmd0OyZndDsmZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS08QlI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmZ3Q7Jmd0OyBGcm9t OiBtcGxzLWludGVyb3AtYm91bmNlc0BpZXRmLm9yZzxCUj4NCiZndDsmZ3Q7Jmd0OyZndDs8QlI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7IFs8QSBIUkVGPSJtYWlsdG86bXBscy1pbnRlcm9wLWJvdW5jZXNA aWV0Zi5vcmciPm1haWx0bzptcGxzLWludGVyb3AtYm91bmNlc0BpZXRmLm9yZzwvQT5dIE9uIEJl aGFsZiBPZiBCZW48QlI+DQomZ3Q7Jmd0OyBOaXZlbi1KZW5raW5zPEJSPg0KJmd0OyZndDsmZ3Q7 Jmd0OzxCUj4NCiZndDsmZ3Q7Jmd0OyZndDsgU2VudDogVGh1cnNkYXksIEp1bmUgMTksIDIwMDgg MToyMSBQTTxCUj4NCiZndDsmZ3Q7Jmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IFRvOiBM b2EgQW5kZXJzc29uOyBNRUFEIHRlYW08QlI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PEJSPg0KJmd0OyZn dDsmZ3Q7Jmd0OyBTdWJqZWN0OiBSZTogW01wbHMtaW50ZXJvcF0gbmV4dCBNRUFEIHRlYW0gbWVl dGluZzxCUj4NCiZndDsmZ3Q7Jmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7PEJS Pg0KJmd0OyZndDsmZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jmd0OyZndDsgQ29sbGVhZ3Vlcyw8QlI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzxCUj4NCiZndDsm Z3Q7Jmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IEZZSSBzZWUgYXR0YWNoZWQgZm9yIHRo ZSBsYXRlc3QgZHJhZnQgb2YgdGhlIE1QTFMtVFAgcmVxdWlyZW1lbnRzPEJSPg0KJmd0OyZndDsm Z3Q7IGRyYWZ0LjxCUj4NCiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8QlI+DQomZ3Q7Jmd0OyZndDsm Z3Q7PEJSPg0KJmd0OyZndDsmZ3Q7Jmd0OyBCZW48QlI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PEJSPg0K Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzxCUj4NCiZndDsmZ3Q7Jmd0OyZndDs8QlI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jm5ic3A7PEJSPg0KJmd0OyZndDsmZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jmd0OyZn dDsmbmJzcDs8QlI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmZ3Q7Jmd0OyBPbiAx OS8wNi8yMDA4IDE2OjAwLCAmcXVvdDtMb2EgQW5kZXJzc29uJnF1b3Q7ICZsdDtsb2FAcGkubnUm Z3Q7IHdyb3RlOjxCUj4NCiZndDsmZ3Q7Jmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jm5i c3A7PEJSPg0KJmd0OyZndDsmZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEFsbCw8 QlI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhlIE1FQUQg dGVhbSB3aWxsIGhhdmUgdGhlIG5leHQgbWVldGluZyBvbiBUdWVzZGF5IDI0LCBhdCA2cG08QlI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpLmUuIDEyYW0gZWFzdCBjb2FzdCBhbmQgOWFtIENhbGlm b3JuaWEuPEJSPg0KJmd0OyZndDsmZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEFn YWluIEkgcGxhbiB0aGUgbWVldGluZyB0byBsYXN0IGFuIGhvdXIsIGFuZCBmb2N1cyB3aWxsIGJl IG9uIHRoZTxCUj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRvY3VtZW50IHN0YXR1cy48QlI+DQom Z3Q7Jmd0OyZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgU3Rld2FydCB3aWxsIHNl bmQgb3V0IGRpYWwgaW4gZGV0YWlscyBhcyB1c3VhbC48QlI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PEJS Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgL0xvYTxCUj4NCiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8 QlI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj4NCiZndDsmZ3Q7Jmd0OyZndDs8 QlI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IE1wbHMtaW50ZXJvcCBtYWlsaW5nIGxpc3Q8QlI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmZ3Q7Jmd0OyBNcGxzLWludGVyb3BAaWV0Zi5vcmc8 QlI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmZ3Q7Jmd0OyA8QSBIUkVGPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtaW50ZXJvcCI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLWludGVyb3A8L0E+PEJSPg0KJmd0OyZn dDsmZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PEJS Pg0KJmd0OyZndDsmZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPEJSPg0KJmd0OyZndDsmZ3Q7Jmd0OyAtLTxCUj4NCiZndDsmZ3Q7Jmd0OyZn dDs8QlI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPEJSPg0KJmd0OyZndDsmZ3Q7Jmd0OyBNcGxzLWludGVyb3AgbWFpbGlu ZyBsaXN0PEJSPg0KJmd0OyZndDsmZ3Q7Jmd0OyBNcGxzLWludGVyb3BAaWV0Zi5vcmc8QlI+DQom Z3Q7Jmd0OyZndDsmZ3Q7IDxBIEhSRUY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbXBscy1pbnRlcm9wIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21wbHMtaW50ZXJvcDwvQT48QlI+DQomZ3Q7Jmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZndDs8QlI+ DQomZ3Q7Jmd0OyZndDsgLS08QlI+DQomZ3Q7Jmd0OyZndDsgTG9hIEFuZGVyc3NvbjxCUj4NCiZn dDsmZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jmd0OyBQcmluY2lwYWwgTmV0d29ya2luZyBBcmNoaXRl Y3Q8QlI+DQomZ3Q7Jmd0OyZndDsgQWNyZW8gQUImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgcGhvbmU6Jm5ic3A7ICs0NiA4IDYzMiA3NyAxNDxCUj4NCiZndDsmZ3Q7 Jmd0OyBJc2Fmam9yZHNnYXRhbiAyMiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBtb2JpbGU6ICs0NiA3MzkgODEgMjEgNjQ8QlI+DQomZ3Q7Jmd0OyZndDsgS2lz dGEsIFN3ZWRlbiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBlbWFpbDombmJzcDsgbG9hLmFuZGVyc3NvbkBhY3Jlby5z ZTxCUj4NCiZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBs b2FAcGkubnU8QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsgLS08QlI+ DQomZ3Q7Jmd0OyBMb2EgQW5kZXJzc29uPEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyBQcmlu Y2lwYWwgTmV0d29ya2luZyBBcmNoaXRlY3Q8QlI+DQomZ3Q7Jmd0OyBBY3JlbyBBQiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwaG9uZTombmJzcDsgKzQ2IDggNjMy IDc3IDE0PEJSPg0KJmd0OyZndDsgSXNhZmpvcmRzZ2F0YW4gMjImbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbW9iaWxlOiArNDYgNzM5IDgxIDIxIDY0PEJSPg0K Jmd0OyZndDsgS2lzdGEsIFN3ZWRlbiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBlbWFpbDombmJzcDsgbG9hLmFuZGVy c3NvbkBhY3Jlby5zZTxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGxvYUBwaS5udTxCUj4NCiZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPEJSPg0KJmd0OyZndDsgTXBscy1pbnRlcm9wIG1haWxpbmcg bGlzdDxCUj4NCiZndDsmZ3Q7IE1wbHMtaW50ZXJvcEBpZXRmLm9yZzxCUj4NCiZndDsmZ3Q7IDxB IEhSRUY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscy1pbnRlcm9w Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtaW50ZXJvcDwvQT48 QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDs8QlI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPEJSPg0KJmd0OyBNcGxzLWludGVyb3AgbWFpbGluZyBs aXN0PEJSPg0KJmd0OyBNcGxzLWludGVyb3BAaWV0Zi5vcmc8QlI+DQomZ3Q7IDxBIEhSRUY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscy1pbnRlcm9wIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtaW50ZXJvcDwvQT48QlI+DQo8QlI+ DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj4NCk1w bHMtaW50ZXJvcCBtYWlsaW5nIGxpc3Q8QlI+DQpNcGxzLWludGVyb3BAaWV0Zi5vcmc8QlI+DQo8 QSBIUkVGPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtaW50ZXJv cCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLWludGVyb3A8L0E+ PEJSPg0KPC9GT05UPg0KPC9QPg0KDQo8L0JPRFk+DQo8L0hUTUw+ ------_=_NextPart_001_01C8D602.1602CF33-- --===============1151961814== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop --===============1151961814==-- From mpls-interop-bounces@ietf.org Tue Jun 24 07:21:33 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAC5D3A6891; Tue, 24 Jun 2008 07:21:33 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AA3D3A688A for ; Tue, 24 Jun 2008 07:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ipuCsawKZHPC for ; Tue, 24 Jun 2008 07:21:30 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 2A4D73A684C for ; Tue, 24 Jun 2008 07:21:30 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m5OELPL04293; Tue, 24 Jun 2008 14:21:25 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Jun 2008 10:21:19 -0400 Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D513267B65@zcarhxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mpls-interop] MPLS-TP Requirements Abstract (was RE: next MEAD team meeting) Thread-Index: AcjS+oxykpiCiEFrSKaGeg3ms5bIkgCEBNYgADJ3f0IADAEoQA== References: <00ed01c8d50c$7ec172b0$4c476297@vim.tlt.alcatel.it> From: "Malcolm Betts" To: "Ben Niven-Jenkins" , "Italo Busi" , "Loa Andersson" , "BRUNGARD, DEBORAH A, ATTLABS" Cc: MEAD team Subject: Re: [Mpls-interop] MPLS-TP Requirements Abstract (was RE: next MEAD team meeting) X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org Ben, much better, I suggest rewording the second paragraph as below: " > This document specifies the requirements for an MPLS Transport Profile > (MPLS-TP) in order to support the capabilities and > functionalities needed for packet transport network services > and packet transport network operations. > > This document incorporates requirements identified by ITU-T. > > This document is a product of a joint ITU-IETF effort. > " The current text implies that only ITU-T and service provider requirements are included. Maybe we should just delete the second paragraph since we do not need to identify the source of the requirements as long as the connection to the work in the ITU is clear. Malcolm Betts Nortel Networks Phone: +1 613 763 7860 (ESN 393) email: betts01@nortel.com Confidentiality Notice: This message and any attachments may contain information that is privileged and confidential. If you have reason to believe that you are not the intended recipient or a person responsible for delivering this message to an intended recipient, you are hereby notified that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have reason to believe that you are not the intended recipient or a person responsible for delivering this message to an intended recipient, please contact the sender immediately by reply email and destroy all copies of the original message. > -----Original Message----- > From: mpls-interop-bounces@ietf.org > [mailto:mpls-interop-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins > Sent: Tuesday, June 24, 2008 4:30 AM > To: Italo Busi; 'Loa Andersson'; 'BRUNGARD, DEBORAH A, ATTLABS' > Cc: 'MEAD team' > Subject: Re: [Mpls-interop] MPLS-TP Requirements Abstract > (was RE: next MEAD team meeting) > > I don't like this. I'm not clear why ITU-T has to be the > only organisation drawn out as the source of the requirements > and I don't like the idea of having to somehow identify/tag > all requirements that are not from the ITU-T as I believe > this to be an unnecessary editorial overhead which will only > get worse as the document evolves. > > How about this? > > " > This document specifies the requirements for an MPLS Transport Profile > (MPLS-TP) in order to support the capabilities and > functionalities needed for packet transport network services > and packet transport network operations. > > These requirements are a combination of those derived from > the set of requirements specified by ITU-T and requirements > received directly from Service Providers. > > This document is a product of a joint ITU-IETF effort. > " > > Ben > > > On 23/06/2008 09:38, "Italo Busi" > wrote: > > > If I understand properly the arguments in this discussion, it seems > > quite important to clarify in the scope that these > requirements are SP > > requirements as well as the fact that the source of most of > them (if > > not all) is ITU-T. > > > > What about the following abstract? > > > > " > > This document specifies the requirements for an MPLS > Transport Profile > > (MPLS-TP) > > in order to support capabilities and functionalities as needed for > > packet transport network services and network operations. > > > > Unless explicitly mentioned, these requirements are derived > from the > > set of requirements specified by ITU-T. > > > > This document is a product of a joint ITU-IETF effort. > > " > > > > Thanks, Italo > > > >> -----Original Message----- > >> From: mpls-interop-bounces@ietf.org > >> [mailto:mpls-interop-bounces@ietf.org] On Behalf Of Loa Andersson > >> Sent: Friday, June 20, 2008 7:25 PM > >> To: BRUNGARD, DEBORAH A, ATTLABS > >> Cc: MEAD team > >> Subject: Re: [Mpls-interop] next MEAD team meeting > >> > >> > >> > >> BRUNGARD, DEBORAH A, ATTLABS wrote: > >>> Hi, > >>> > >>> Thanks Loa for the hint. My understanding of the charter > >> was to capture > >>> the ITU requirements? > >> > >> yes - that is true... > >> > >> but we also need to capture all requirements for the > MPLS-TP whether > >> they are in the captured by the ITU-T or not. > >>> > >>> What is the MEAD development work covering - both ITU > >> requirements and > >>> "other (anonymous) SPs requirements"? > >> > >> if there is "only" requirements that originates from ITU-T this is > >> not a problem. I am not looking for anonymous > requirements, if there > >> is a requirement that is not from ITU-T we should make > clear where it > >> came form > >> > >> /Loa > >>> > >>> Deborah > >>> > >>> > >>> -----Original Message----- > >>> From: Sprecher, Nurit (NSN - IL/Israel - MiniMD) > >>> [mailto:nurit.sprecher@nsn.com] > >>> Sent: Friday, June 20, 2008 5:23 AM > >>> To: ext Loa Andersson > >>> Cc: BRUNGARD, DEBORAH A, ATTLABS; MEAD team; Sprecher, > Nurit (NSN - > >>> IL/Israel - MiniMD) > >>> Subject: RE: [Mpls-interop] next MEAD team meeting > >>> > >>> Hi, > >>> 1. I agree that validates may be a good option. > >>> 2. IMO, these requirements are not only the ITU-T view. I > got these > >>> requirements from different SPs. As I indicated in the > >> beginning of the > >>> mail exchanges I would prefer to say: "This document > specifies the > >>> requirements for MPLS-TP in order to support capabilities and > >>> functionalities as needed in transport environments (or > >> networks)." But > >>> this is something that we need the SPs to agree on. > >>> Please note also that in the proposal just below I forgot > >> to include the > >>> indication that this is a joint work of ITU-T and IETF. > >>> Best regards, > >>> Nurit > >>> > >>> > >>> -----Original Message----- > >>> From: ext Loa Andersson [mailto:loa@pi.nu] > >>> Sent: Friday, June 20, 2008 11:57 > >>> To: Sprecher, Nurit (NSN - IL/Israel - MiniMD) > >>> Cc: ext BRUNGARD, DEBORAH A, ATTLABS; MEAD team > >>> Subject: Re: [Mpls-interop] next MEAD team meeting > >>> > >>> All, > >>> > >>> just a few comments. > >>> > >>> Sprecher, Nurit (NSN - IL/Israel - MiniMD) wrote: > >>>> Hi Deborah, > >>>> I understand the intention, so how about the following > (as we also > >>>> indicated in the introduction): > >>>> This document specifies > >>> > >>> I wonder if "specifies" is the right word - one way would > be to say > >>> "validates" indicating that this how we (IETF) understands these > >>> requirements > >>> > >>> the ITU-T requirements for MPLS-TP in order to > >>>> support capabilities and functionalities of MPLS as needed in > >>>> transport environments. > >>> > >>> this indicates that there is nothing but ITU-T > requirements in the > >>> document, is that true? > >>> > >>> /Loa > >>> > >>>> MPLS is a maturing packet technology and it is already > playing an > >>>> important role in transport networks and services. > >> However, not all of > >>> > >>>> MPLS's capabilities and mechnisms are needed and/or > >> consistent with > >>>> transport network operations. This document identifies the > >> required > >>>> capabilities for MPLS so that it can better fit a transport role. > >>> > >>>> Please advise. > >>>> Best regards, > >>>> Nurit > >>>> > >>>> ________________________________ > >>>> > >>>> From: ext BRUNGARD, DEBORAH A, ATTLABS [mailto:dbrungard@att.com] > >>>> Sent: Thursday, June 19, 2008 23:04 > >>>> To: Sprecher, Nurit (NSN - IL/Israel - MiniMD); MEAD team > >>>> Subject: RE: [Mpls-interop] next MEAD team meeting > >>>> > >>>> > >>>> Hi Nurit, > >>>> > >>>> I would prefer to clearly say the requirements are ITU > >> requirements > >>>> for MPLS in a transport environment. I think among some > >> operators the > >>>> line between transport equipment and packet equipment has already > >>> blurred. > >>>> For many operators, the preference may be to align with MPLS > >>>> operations vs. transport. I think there are many differing > >> opinions on > >>> > >>>> what MPLS/packet transport needs to support in a transport > >>>> environment. So I prefer to clearly say these are ITU > >> requirements, > >>>> they do not necessarily reflect the operators > contributing to this > >>> document. > >>>> > >>>> On the 2nd bullet, the requirements document has many > >>>> statements/requirements which may be interpreted by a > >> reader as gaps > >>>> in MPLS/IETF protocols. I was trying to say with this > sentence the > >>>> document is not addressing/identifying IETF protocol > >> applicability or > >>>> lack of capabilities e.g. the sentence: > >>>> "Quality-of-service mechanisms are required in the > packet transport > >>>> network to ensure the prioritization of critical services, to > >>>> guarantee BW and to control jitter and delay." > >>>> > >>>> QoS is not a new requirement for IETF protocols. Packet > transport > >>>> networks (and this requirement document) are not the first > >> time that > >>>> QoS mechanisms are identified as needed. This requirement is not > >>>> intending to identify a gap in the current IETF protocol > >> set. This was > >>> > >>>> what I was trying to say. > >>>> > >>>> Suggestions? > >>>> Deborah > >>>> > >>>> > >>>> > >>>> ________________________________ > >>>> > >>>> From: Sprecher, Nurit (NSN - IL/Israel - MiniMD) > >>>> [mailto:nurit.sprecher@nsn.com] > >>>> Sent: Thursday, June 19, 2008 3:10 PM > >>>> To: BRUNGARD, DEBORAH A, ATTLABS; MEAD team > >>>> Cc: Sprecher, Nurit (NSN - IL/Israel - MiniMD) > >>>> Subject: RE: [Mpls-interop] next MEAD team meeting > >>>> > >>>> > >>>> > >>>> Hi Deborah, > >>>> > >>>> I have a few comments regarding the proposed abstract: > >>>> > >>>> * I think we should say "This document specifies the > >>>> requirements for MPLS-TP in order to support capabilities and > >>>> functionalities as needed in transport environments (or > networks). > >>>> > >>>> * I do not understand the sentence: It does not > >> address IETF > >>>> protocol applicability or capabilities. Do you mean > >> applicability or > >>>> capability of the current IETF documents? As IMO it will > be of the > >>>> documents we generate for MPLS-TP. > >>>> > >>>> * I think it is important to indicate that " This > >> document is > >>> a > >>>> product of a joint ITU-IETF effort". > >>>> > >>>> Best regards, > >>>> > >>>> Nurit > >>>> > >>>> > >>>> > >>>> -----Original Message----- > >>>> From: mpls-interop-bounces@ietf.org > >>>> [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext > BRUNGARD, > >>>> DEBORAH A, ATTLABS > >>>> Sent: Thursday, June 19, 2008 21:11 > >>>> To: MEAD team > >>>> Subject: Re: [Mpls-interop] next MEAD team meeting > >>>> > >>>> > >>>> > >>>> Colleagues, > >>>> > >>>> > >>>> > >>>> I was thinking for the requirements we should include a > >> sentence in > >>>> the > >>>> > >>>> abstract to scope the MPLS-TP work as being part of a > >> joint ITU-IETF > >>>> > >>>> effort. Not all readers (now and future) will be aware of > >> why this is > >>>> > >>>> being done. In ccamp, we had done this for our ASON work. Maybe a > >>>> > >>>> similar sentence will be needed in the other documents? > >> Should we have > >>> > >>>> a > >>>> > >>>> common sentence? > >>>> > >>>> > >>>> > >>>> How about for the abstract: > >>>> > >>>> This document summarizes the ITU-T requirements for > >> MPLS-TP in order > >>>> to > >>>> > >>>> support capabilities and functionalities as needed by the > >> ITU-T. It > >>>> does > >>>> > >>>> not address IETF protocol applicability or capabilities. > >> This document > >>>> > >>>> is a product of a joint ITU-IETF effort. > >>>> > >>>> > >>>> > >>>> Deborah > >>>> > >>>> > >>>> > >>>> -----Original Message----- > >>>> > >>>> From: mpls-interop-bounces@ietf.org > >>>> > >>>> [mailto:mpls-interop-bounces@ietf.org] On Behalf Of Ben > >> Niven-Jenkins > >>>> > >>>> Sent: Thursday, June 19, 2008 1:21 PM > >>>> > >>>> To: Loa Andersson; MEAD team > >>>> > >>>> Subject: Re: [Mpls-interop] next MEAD team meeting > >>>> > >>>> > >>>> > >>>> Colleagues, > >>>> > >>>> > >>>> > >>>> FYI see attached for the latest draft of the MPLS-TP requirements > >>> draft. > >>>> > >>>> > >>>> Ben > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> On 19/06/2008 16:00, "Loa Andersson" wrote: > >>>> > >>>> > >>>> > >>>>> All, > >>>> > >>>>> the MEAD team will have the next meeting on Tuesday 24, at 6pm > >>>>> i.e. 12am east coast and 9am California. > >>>> > >>>>> Again I plan the meeting to last an hour, and focus > will be on the > >>>>> document status. > >>>> > >>>>> Stewart will send out dial in details as usual. > >>>> > >>>>> /Loa > >>>> > >>>> > >>>> _______________________________________________ > >>>> > >>>> Mpls-interop mailing list > >>>> > >>>> Mpls-interop@ietf.org > >>>> > >>>> https://www.ietf.org/mailman/listinfo/mpls-interop > >>>> > >>>> > >>>> > >>>> > >>>> > >> > --------------------------------------------------------------------- > >> - > >>>> -- > >>>> > >>>> _______________________________________________ > >>>> Mpls-interop mailing list > >>>> Mpls-interop@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mpls-interop > >>> > >>> > >>> -- > >>> Loa Andersson > >>> > >>> Principal Networking Architect > >>> Acreo AB phone: +46 8 632 77 14 > >>> Isafjordsgatan 22 mobile: +46 739 81 21 64 > >>> Kista, Sweden email: loa.andersson@acreo.se > >>> loa@pi.nu > >> > >> > >> -- > >> Loa Andersson > >> > >> Principal Networking Architect > >> Acreo AB phone: +46 8 632 77 14 > >> Isafjordsgatan 22 mobile: +46 739 81 21 64 > >> Kista, Sweden email: loa.andersson@acreo.se > >> loa@pi.nu > >> _______________________________________________ > >> Mpls-interop mailing list > >> Mpls-interop@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls-interop > >> > > > > _______________________________________________ > > Mpls-interop mailing list > > Mpls-interop@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-interop > > _______________________________________________ > Mpls-interop mailing list > Mpls-interop@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-interop > _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop From mpls-interop-bounces@ietf.org Tue Jun 24 07:21:40 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C2BD3A67E7; Tue, 24 Jun 2008 07:21:40 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B2D53A6994 for ; Tue, 24 Jun 2008 07:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n+VDDTzNCsw2 for ; Tue, 24 Jun 2008 07:21:37 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 694F13A6891 for ; Tue, 24 Jun 2008 07:21:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,696,1204520400"; d="scan'208,217";a="12042683" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 24 Jun 2008 10:21:37 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5OELbkv009981; Tue, 24 Jun 2008 10:21:37 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m5OELbuV010539; Tue, 24 Jun 2008 14:21:37 GMT Received: from xmb-rtp-206.amer.cisco.com ([64.102.31.32]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jun 2008 10:21:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Jun 2008 10:21:11 -0400 Message-ID: <735F40E0DE95EE4B9AF8DADC87E73EA9011D8D91@xmb-rtp-206.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mpls-interop] MPLS OAM Analysis Document Thread-Index: AcjV/PYHSaaR/8fXTEOBNxlExvTejQACJdh/ References: <32E6AA49-F2E5-45B1-A57D-9F8C8BD90BF8@cisco.com> From: "George Swallow (swallow)" To: "David Ward" , "Thomas Nadeau" X-OriginalArrivalTime: 24 Jun 2008 14:21:37.0862 (UTC) FILETIME=[9D14B660:01C8D605] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3719; t=1214317297; x=1215181297; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=swallow@cisco.com; z=From:=20=22George=20Swallow=20(swallow)=22=20 |Subject:=20RE=3A=20[Mpls-interop]=20MPLS=20OAM=20Analysis= 20Document |Sender:=20 |To:=20=22David=20Ward=22=20,=20=22Thomas= 20Nadeau=22=20; bh=Fe8C5k8AfDDZuQCU//nd3btCcAu8G1Fa46Fd2Llt6Yk=; b=FxGKP/8B6DwVDshA1vFVybGq7HaJfin7DbwFEDxa+k/8YKUuadAf21t2rF uQY06tlu0Y3CbCfsPq3qDTm8Ds0YDbxFaiSSKWUu9VVf/V9WZ2jhC4TJymvI 1kOpUjG52y; Authentication-Results: rtp-dkim-2; header.From=swallow@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: "David Ward \(wardd\)" , MEAD team , hhelvoort@chello.nl Subject: Re: [Mpls-interop] MPLS OAM Analysis Document X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1527541278==" Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org This is a multi-part message in MIME format. --===============1527541278== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8D605.9CC8E9EF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8D605.9CC8E9EF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes! Please do so. ...George -----Original Message----- From: mpls-interop-bounces@ietf.org on behalf of David Ward Sent: Tue 6/24/2008 9:18 AM To: Thomas Nadeau Cc: hhelvoort@chello.nl; David Ward (wardd); MEAD team Subject: Re: [Mpls-interop] MPLS OAM Analysis Document =20 I'd expect that you do. -DWard On Jun 24, 2008, at 7:34 AM, Thomas Nadeau wrote: > > The OAM Analysis Team (Nurit, Huub and myself) met today and =20 > agreed on > the following: > > 1) The goals of the team are to analyze the OAM requirements and > existing solutions and map them to each other. > > 2) Indicate the gaps where they exist in the document. > > 3) Feed the gaps back into the existing solution/requirements =20 > work. > > 4) Work via email on a TOC and fill in as much of this as =20 > possible by > the deadline. We will publish whatever is ready at that point. > > > Open questions were: > > 1) MPLS-TP Chairs: Do we need to produce any slides for the =20 > next IETF > meeting? > > --Tom > > _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop ------_=_NextPart_001_01C8D605.9CC8E9EF Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Mpls-interop] MPLS OAM Analysis Document

Yes!  Please do so.

...George


-----Original Message-----
From: mpls-interop-bounces@ietf.org on behalf of David Ward
Sent: Tue 6/24/2008 9:18 AM
To: Thomas Nadeau
Cc: hhelvoort@chello.nl; David Ward (wardd); MEAD team
Subject: Re: [Mpls-interop] MPLS OAM Analysis Document

I'd expect that you do.


-DWard

On Jun 24, 2008, at 7:34 AM, Thomas Nadeau wrote:

>
>     The OAM Analysis Team (Nurit, Huub and = myself) met today and 
> agreed on
> the following:
>
>     1) The goals of the team are to analyze the = OAM requirements and
> existing solutions and map them to each other.
>
>     2) Indicate the gaps where they exist in = the document.
>
>     3) Feed the gaps back into the existing = solution/requirements 
> work.
>
>     4) Work via email on a TOC and fill in as = much of this as 
> possible by
> the deadline. We will publish whatever is ready at that point.
>
>
>     Open questions were:
>
>     1) MPLS-TP Chairs: Do we need to produce = any slides for the 
> next IETF
> meeting?
>
>     --Tom
>
>

_______________________________________________
Mpls-interop mailing list
Mpls-interop@ietf.org
https://www.i= etf.org/mailman/listinfo/mpls-interop

------_=_NextPart_001_01C8D605.9CC8E9EF-- --===============1527541278== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop --===============1527541278==-- From mpls-interop-bounces@ietf.org Tue Jun 24 07:26:43 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9190E3A698B; Tue, 24 Jun 2008 07:26:43 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF5E43A69B2 for ; Tue, 24 Jun 2008 07:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.332 X-Spam-Level: X-Spam-Status: No, score=-1.332 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZuMgznYG-Y1Q for ; Tue, 24 Jun 2008 07:26:41 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 855553A698B for ; Tue, 24 Jun 2008 07:26:40 -0700 (PDT) Received: from E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.109]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jun 2008 15:26:35 +0100 Received: from 217.32.164.184 ([217.32.164.184]) by E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.60]) via Exchange Front-End Server mail.bt.com ([193.113.197.28]) with Microsoft Exchange Server HTTP-DAV ; Tue, 24 Jun 2008 14:26:34 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Tue, 24 Jun 2008 15:26:32 +0100 From: Ben Niven-Jenkins To: Malcolm Betts , Italo Busi , Loa Andersson , "BRUNGARD, DEBORAH A, ATTLABS" Message-ID: Thread-Topic: [Mpls-interop] MPLS-TP Requirements Abstract (was RE: next MEAD team meeting) Thread-Index: AcjS+oxykpiCiEFrSKaGeg3ms5bIkgCEBNYgADJ3f0IADAEoQAAAcoDV In-Reply-To: <0BDFFF51DC89434FA33F8B37FCE363D513267B65@zcarhxm2.corp.nortel.com> Mime-version: 1.0 X-OriginalArrivalTime: 24 Jun 2008 14:26:35.0853 (UTC) FILETIME=[4EB287D0:01C8D606] Cc: MEAD team Subject: Re: [Mpls-interop] MPLS-TP Requirements Abstract (was RE: next MEAD team meeting) X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org Good point. I'm fine with the text you propose. Ben On 24/06/2008 15:21, "Malcolm Betts" wrote: > Ben, much better, I suggest rewording the second paragraph as below: > > " >> This document specifies the requirements for an MPLS Transport Profile >> (MPLS-TP) in order to support the capabilities and >> functionalities needed for packet transport network services >> and packet transport network operations. >> >> This document incorporates requirements identified by ITU-T. >> >> This document is a product of a joint ITU-IETF effort. >> " > > The current text implies that only ITU-T and service provider > requirements are included. Maybe we should just delete the second > paragraph since we do not need to identify the source of the > requirements as long as the connection to the work in the ITU is clear. > > > Malcolm Betts > Nortel Networks > Phone: +1 613 763 7860 (ESN 393) > email: betts01@nortel.com > > Confidentiality Notice: This message and any attachments may contain > information that is privileged and confidential. If you have reason to > believe that you are not the intended recipient or a person responsible > for delivering this message to an intended recipient, you are hereby > notified that any review, dissemination, distribution, or copying of > this message is strictly prohibited. If you have reason to believe that > you are not the intended recipient or a person responsible for > delivering this message to an intended recipient, please contact the > sender immediately by reply email and destroy all copies of the original > message. > > >> -----Original Message----- >> From: mpls-interop-bounces@ietf.org >> [mailto:mpls-interop-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins >> Sent: Tuesday, June 24, 2008 4:30 AM >> To: Italo Busi; 'Loa Andersson'; 'BRUNGARD, DEBORAH A, ATTLABS' >> Cc: 'MEAD team' >> Subject: Re: [Mpls-interop] MPLS-TP Requirements Abstract >> (was RE: next MEAD team meeting) >> >> I don't like this. I'm not clear why ITU-T has to be the >> only organisation drawn out as the source of the requirements >> and I don't like the idea of having to somehow identify/tag >> all requirements that are not from the ITU-T as I believe >> this to be an unnecessary editorial overhead which will only >> get worse as the document evolves. >> >> How about this? >> >> " >> This document specifies the requirements for an MPLS Transport Profile >> (MPLS-TP) in order to support the capabilities and >> functionalities needed for packet transport network services >> and packet transport network operations. >> >> These requirements are a combination of those derived from >> the set of requirements specified by ITU-T and requirements >> received directly from Service Providers. >> >> This document is a product of a joint ITU-IETF effort. >> " >> >> Ben >> >> >> On 23/06/2008 09:38, "Italo Busi" >> wrote: >> >>> If I understand properly the arguments in this discussion, it seems >>> quite important to clarify in the scope that these >> requirements are SP >>> requirements as well as the fact that the source of most of >> them (if >>> not all) is ITU-T. >>> >>> What about the following abstract? >>> >>> " >>> This document specifies the requirements for an MPLS >> Transport Profile >>> (MPLS-TP) >>> in order to support capabilities and functionalities as needed for >>> packet transport network services and network operations. >>> >>> Unless explicitly mentioned, these requirements are derived >> from the >>> set of requirements specified by ITU-T. >>> >>> This document is a product of a joint ITU-IETF effort. >>> " >>> >>> Thanks, Italo >>> >>>> -----Original Message----- >>>> From: mpls-interop-bounces@ietf.org >>>> [mailto:mpls-interop-bounces@ietf.org] On Behalf Of Loa Andersson >>>> Sent: Friday, June 20, 2008 7:25 PM >>>> To: BRUNGARD, DEBORAH A, ATTLABS >>>> Cc: MEAD team >>>> Subject: Re: [Mpls-interop] next MEAD team meeting >>>> >>>> >>>> >>>> BRUNGARD, DEBORAH A, ATTLABS wrote: >>>>> Hi, >>>>> >>>>> Thanks Loa for the hint. My understanding of the charter >>>> was to capture >>>>> the ITU requirements? >>>> >>>> yes - that is true... >>>> >>>> but we also need to capture all requirements for the >> MPLS-TP whether >>>> they are in the captured by the ITU-T or not. >>>>> >>>>> What is the MEAD development work covering - both ITU >>>> requirements and >>>>> "other (anonymous) SPs requirements"? >>>> >>>> if there is "only" requirements that originates from ITU-T this is >>>> not a problem. I am not looking for anonymous >> requirements, if there >>>> is a requirement that is not from ITU-T we should make >> clear where it >>>> came form >>>> >>>> /Loa >>>>> >>>>> Deborah >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Sprecher, Nurit (NSN - IL/Israel - MiniMD) >>>>> [mailto:nurit.sprecher@nsn.com] >>>>> Sent: Friday, June 20, 2008 5:23 AM >>>>> To: ext Loa Andersson >>>>> Cc: BRUNGARD, DEBORAH A, ATTLABS; MEAD team; Sprecher, >> Nurit (NSN - >>>>> IL/Israel - MiniMD) >>>>> Subject: RE: [Mpls-interop] next MEAD team meeting >>>>> >>>>> Hi, >>>>> 1. I agree that validates may be a good option. >>>>> 2. IMO, these requirements are not only the ITU-T view. I >> got these >>>>> requirements from different SPs. As I indicated in the >>>> beginning of the >>>>> mail exchanges I would prefer to say: "This document >> specifies the >>>>> requirements for MPLS-TP in order to support capabilities and >>>>> functionalities as needed in transport environments (or >>>> networks)." But >>>>> this is something that we need the SPs to agree on. >>>>> Please note also that in the proposal just below I forgot >>>> to include the >>>>> indication that this is a joint work of ITU-T and IETF. >>>>> Best regards, >>>>> Nurit >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: ext Loa Andersson [mailto:loa@pi.nu] >>>>> Sent: Friday, June 20, 2008 11:57 >>>>> To: Sprecher, Nurit (NSN - IL/Israel - MiniMD) >>>>> Cc: ext BRUNGARD, DEBORAH A, ATTLABS; MEAD team >>>>> Subject: Re: [Mpls-interop] next MEAD team meeting >>>>> >>>>> All, >>>>> >>>>> just a few comments. >>>>> >>>>> Sprecher, Nurit (NSN - IL/Israel - MiniMD) wrote: >>>>>> Hi Deborah, >>>>>> I understand the intention, so how about the following >> (as we also >>>>>> indicated in the introduction): >>>>>> This document specifies >>>>> >>>>> I wonder if "specifies" is the right word - one way would >> be to say >>>>> "validates" indicating that this how we (IETF) understands these >>>>> requirements >>>>> >>>>> the ITU-T requirements for MPLS-TP in order to >>>>>> support capabilities and functionalities of MPLS as needed in >>>>>> transport environments. >>>>> >>>>> this indicates that there is nothing but ITU-T >> requirements in the >>>>> document, is that true? >>>>> >>>>> /Loa >>>>> >>>>>> MPLS is a maturing packet technology and it is already >> playing an >>>>>> important role in transport networks and services. >>>> However, not all of >>>>> >>>>>> MPLS's capabilities and mechnisms are needed and/or >>>> consistent with >>>>>> transport network operations. This document identifies the >>>> required >>>>>> capabilities for MPLS so that it can better fit a transport role. >>>>> >>>>>> Please advise. >>>>>> Best regards, >>>>>> Nurit >>>>>> >>>>>> ________________________________ >>>>>> >>>>>> From: ext BRUNGARD, DEBORAH A, ATTLABS [mailto:dbrungard@att.com] >>>>>> Sent: Thursday, June 19, 2008 23:04 >>>>>> To: Sprecher, Nurit (NSN - IL/Israel - MiniMD); MEAD team >>>>>> Subject: RE: [Mpls-interop] next MEAD team meeting >>>>>> >>>>>> >>>>>> Hi Nurit, >>>>>> >>>>>> I would prefer to clearly say the requirements are ITU >>>> requirements >>>>>> for MPLS in a transport environment. I think among some >>>> operators the >>>>>> line between transport equipment and packet equipment has already >>>>> blurred. >>>>>> For many operators, the preference may be to align with MPLS >>>>>> operations vs. transport. I think there are many differing >>>> opinions on >>>>> >>>>>> what MPLS/packet transport needs to support in a transport >>>>>> environment. So I prefer to clearly say these are ITU >>>> requirements, >>>>>> they do not necessarily reflect the operators >> contributing to this >>>>> document. >>>>>> >>>>>> On the 2nd bullet, the requirements document has many >>>>>> statements/requirements which may be interpreted by a >>>> reader as gaps >>>>>> in MPLS/IETF protocols. I was trying to say with this >> sentence the >>>>>> document is not addressing/identifying IETF protocol >>>> applicability or >>>>>> lack of capabilities e.g. the sentence: >>>>>> "Quality-of-service mechanisms are required in the >> packet transport >>>>>> network to ensure the prioritization of critical services, to >>>>>> guarantee BW and to control jitter and delay." >>>>>> >>>>>> QoS is not a new requirement for IETF protocols. Packet >> transport >>>>>> networks (and this requirement document) are not the first >>>> time that >>>>>> QoS mechanisms are identified as needed. This requirement is not >>>>>> intending to identify a gap in the current IETF protocol >>>> set. This was >>>>> >>>>>> what I was trying to say. >>>>>> >>>>>> Suggestions? >>>>>> Deborah >>>>>> >>>>>> >>>>>> >>>>>> ________________________________ >>>>>> >>>>>> From: Sprecher, Nurit (NSN - IL/Israel - MiniMD) >>>>>> [mailto:nurit.sprecher@nsn.com] >>>>>> Sent: Thursday, June 19, 2008 3:10 PM >>>>>> To: BRUNGARD, DEBORAH A, ATTLABS; MEAD team >>>>>> Cc: Sprecher, Nurit (NSN - IL/Israel - MiniMD) >>>>>> Subject: RE: [Mpls-interop] next MEAD team meeting >>>>>> >>>>>> >>>>>> >>>>>> Hi Deborah, >>>>>> >>>>>> I have a few comments regarding the proposed abstract: >>>>>> >>>>>> * I think we should say "This document specifies the >>>>>> requirements for MPLS-TP in order to support capabilities and >>>>>> functionalities as needed in transport environments (or >> networks). >>>>>> >>>>>> * I do not understand the sentence: It does not >>>> address IETF >>>>>> protocol applicability or capabilities. Do you mean >>>> applicability or >>>>>> capability of the current IETF documents? As IMO it will >> be of the >>>>>> documents we generate for MPLS-TP. >>>>>> >>>>>> * I think it is important to indicate that " This >>>> document is >>>>> a >>>>>> product of a joint ITU-IETF effort". >>>>>> >>>>>> Best regards, >>>>>> >>>>>> Nurit >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: mpls-interop-bounces@ietf.org >>>>>> [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext >> BRUNGARD, >>>>>> DEBORAH A, ATTLABS >>>>>> Sent: Thursday, June 19, 2008 21:11 >>>>>> To: MEAD team >>>>>> Subject: Re: [Mpls-interop] next MEAD team meeting >>>>>> >>>>>> >>>>>> >>>>>> Colleagues, >>>>>> >>>>>> >>>>>> >>>>>> I was thinking for the requirements we should include a >>>> sentence in >>>>>> the >>>>>> >>>>>> abstract to scope the MPLS-TP work as being part of a >>>> joint ITU-IETF >>>>>> >>>>>> effort. Not all readers (now and future) will be aware of >>>> why this is >>>>>> >>>>>> being done. In ccamp, we had done this for our ASON work. Maybe a >>>>>> >>>>>> similar sentence will be needed in the other documents? >>>> Should we have >>>>> >>>>>> a >>>>>> >>>>>> common sentence? >>>>>> >>>>>> >>>>>> >>>>>> How about for the abstract: >>>>>> >>>>>> This document summarizes the ITU-T requirements for >>>> MPLS-TP in order >>>>>> to >>>>>> >>>>>> support capabilities and functionalities as needed by the >>>> ITU-T. It >>>>>> does >>>>>> >>>>>> not address IETF protocol applicability or capabilities. >>>> This document >>>>>> >>>>>> is a product of a joint ITU-IETF effort. >>>>>> >>>>>> >>>>>> >>>>>> Deborah >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> >>>>>> From: mpls-interop-bounces@ietf.org >>>>>> >>>>>> [mailto:mpls-interop-bounces@ietf.org] On Behalf Of Ben >>>> Niven-Jenkins >>>>>> >>>>>> Sent: Thursday, June 19, 2008 1:21 PM >>>>>> >>>>>> To: Loa Andersson; MEAD team >>>>>> >>>>>> Subject: Re: [Mpls-interop] next MEAD team meeting >>>>>> >>>>>> >>>>>> >>>>>> Colleagues, >>>>>> >>>>>> >>>>>> >>>>>> FYI see attached for the latest draft of the MPLS-TP requirements >>>>> draft. >>>>>> >>>>>> >>>>>> Ben >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 19/06/2008 16:00, "Loa Andersson" wrote: >>>>>> >>>>>> >>>>>> >>>>>>> All, >>>>>> >>>>>>> the MEAD team will have the next meeting on Tuesday 24, at 6pm >>>>>>> i.e. 12am east coast and 9am California. >>>>>> >>>>>>> Again I plan the meeting to last an hour, and focus >> will be on the >>>>>>> document status. >>>>>> >>>>>>> Stewart will send out dial in details as usual. >>>>>> >>>>>>> /Loa >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> >>>>>> Mpls-interop mailing list >>>>>> >>>>>> Mpls-interop@ietf.org >>>>>> >>>>>> https://www.ietf.org/mailman/listinfo/mpls-interop >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> >> --------------------------------------------------------------------- >>>> - >>>>>> -- >>>>>> >>>>>> _______________________________________________ >>>>>> Mpls-interop mailing list >>>>>> Mpls-interop@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mpls-interop >>>>> >>>>> >>>>> -- >>>>> Loa Andersson >>>>> >>>>> Principal Networking Architect >>>>> Acreo AB phone: +46 8 632 77 14 >>>>> Isafjordsgatan 22 mobile: +46 739 81 21 64 >>>>> Kista, Sweden email: loa.andersson@acreo.se >>>>> loa@pi.nu >>>> >>>> >>>> -- >>>> Loa Andersson >>>> >>>> Principal Networking Architect >>>> Acreo AB phone: +46 8 632 77 14 >>>> Isafjordsgatan 22 mobile: +46 739 81 21 64 >>>> Kista, Sweden email: loa.andersson@acreo.se >>>> loa@pi.nu >>>> _______________________________________________ >>>> Mpls-interop mailing list >>>> Mpls-interop@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls-interop >>>> >>> >>> _______________________________________________ >>> Mpls-interop mailing list >>> Mpls-interop@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls-interop >> >> _______________________________________________ >> Mpls-interop mailing list >> Mpls-interop@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-interop >> _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop From mpls-interop-bounces@ietf.org Tue Jun 24 08:08:48 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08C593A6821; Tue, 24 Jun 2008 08:08:48 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF1BD3A6982 for ; Tue, 24 Jun 2008 08:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.789 X-Spam-Level: X-Spam-Status: No, score=-2.789 tagged_above=-999 required=5 tests=[AWL=-0.190, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OyFiyr9vwc3A for ; Tue, 24 Jun 2008 08:08:44 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 2E4123A6920 for ; Tue, 24 Jun 2008 08:08:43 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m5OF8ZPk001847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Jun 2008 17:08:35 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m5OF8XDJ007903; Tue, 24 Jun 2008 17:08:35 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Jun 2008 17:08:33 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Jun 2008 17:08:30 +0200 Message-ID: <9FF5BDAD88B9D84881609E89AC92FB83EBDA4C@DEMUEXC014.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mpls-interop] MPLS-TP Requirements Abstract (was RE: next MEAD team meeting) Thread-Index: AcjS+oxykpiCiEFrSKaGeg3ms5bIkgCEBNYgADJ3f0IADAEoQAAAcoDVAAFJCKA= From: "Sprecher, Nurit (NSN - IL/Israel - MiniMD)" To: "ext Ben Niven-Jenkins" , "Malcolm Betts" , "Italo Busi" , "Loa Andersson" , "BRUNGARD, DEBORAH A, ATTLABS" X-OriginalArrivalTime: 24 Jun 2008 15:08:33.0659 (UTC) FILETIME=[2B6D3CB0:01C8D60C] Cc: MEAD team Subject: Re: [Mpls-interop] MPLS-TP Requirements Abstract (was RE: next MEAD team meeting) X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org Agree (and we get to the point where we started :-)) -----Original Message----- From: mpls-interop-bounces@ietf.org [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext Ben Niven-Jenkins Sent: Tuesday, June 24, 2008 17:27 To: Malcolm Betts; Italo Busi; Loa Andersson; BRUNGARD, DEBORAH A, ATTLABS Cc: MEAD team Subject: Re: [Mpls-interop] MPLS-TP Requirements Abstract (was RE: next MEAD team meeting) Good point. I'm fine with the text you propose. Ben On 24/06/2008 15:21, "Malcolm Betts" wrote: > Ben, much better, I suggest rewording the second paragraph as below: > > " >> This document specifies the requirements for an MPLS Transport >> Profile >> (MPLS-TP) in order to support the capabilities and functionalities >> needed for packet transport network services and packet transport >> network operations. >> >> This document incorporates requirements identified by ITU-T. >> >> This document is a product of a joint ITU-IETF effort. >> " > > The current text implies that only ITU-T and service provider > requirements are included. Maybe we should just delete the second > paragraph since we do not need to identify the source of the > requirements as long as the connection to the work in the ITU is clear. > > > Malcolm Betts > Nortel Networks > Phone: +1 613 763 7860 (ESN 393) > email: betts01@nortel.com > > Confidentiality Notice: This message and any attachments may contain > information that is privileged and confidential. If you have reason to > believe that you are not the intended recipient or a person > responsible for delivering this message to an intended recipient, you > are hereby notified that any review, dissemination, distribution, or > copying of this message is strictly prohibited. If you have reason to > believe that you are not the intended recipient or a person > responsible for delivering this message to an intended recipient, > please contact the sender immediately by reply email and destroy all > copies of the original message. > > >> -----Original Message----- >> From: mpls-interop-bounces@ietf.org >> [mailto:mpls-interop-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins >> Sent: Tuesday, June 24, 2008 4:30 AM >> To: Italo Busi; 'Loa Andersson'; 'BRUNGARD, DEBORAH A, ATTLABS' >> Cc: 'MEAD team' >> Subject: Re: [Mpls-interop] MPLS-TP Requirements Abstract (was RE: >> next MEAD team meeting) >> >> I don't like this. I'm not clear why ITU-T has to be the only >> organisation drawn out as the source of the requirements and I don't >> like the idea of having to somehow identify/tag all requirements that >> are not from the ITU-T as I believe this to be an unnecessary >> editorial overhead which will only get worse as the document evolves. >> >> How about this? >> >> " >> This document specifies the requirements for an MPLS Transport >> Profile >> (MPLS-TP) in order to support the capabilities and functionalities >> needed for packet transport network services and packet transport >> network operations. >> >> These requirements are a combination of those derived from the set of >> requirements specified by ITU-T and requirements received directly >> from Service Providers. >> >> This document is a product of a joint ITU-IETF effort. >> " >> >> Ben >> >> >> On 23/06/2008 09:38, "Italo Busi" >> wrote: >> >>> If I understand properly the arguments in this discussion, it seems >>> quite important to clarify in the scope that these >> requirements are SP >>> requirements as well as the fact that the source of most of >> them (if >>> not all) is ITU-T. >>> >>> What about the following abstract? >>> >>> " >>> This document specifies the requirements for an MPLS >> Transport Profile >>> (MPLS-TP) >>> in order to support capabilities and functionalities as needed for >>> packet transport network services and network operations. >>> >>> Unless explicitly mentioned, these requirements are derived >> from the >>> set of requirements specified by ITU-T. >>> >>> This document is a product of a joint ITU-IETF effort. >>> " >>> >>> Thanks, Italo >>> >>>> -----Original Message----- >>>> From: mpls-interop-bounces@ietf.org >>>> [mailto:mpls-interop-bounces@ietf.org] On Behalf Of Loa Andersson >>>> Sent: Friday, June 20, 2008 7:25 PM >>>> To: BRUNGARD, DEBORAH A, ATTLABS >>>> Cc: MEAD team >>>> Subject: Re: [Mpls-interop] next MEAD team meeting >>>> >>>> >>>> >>>> BRUNGARD, DEBORAH A, ATTLABS wrote: >>>>> Hi, >>>>> >>>>> Thanks Loa for the hint. My understanding of the charter >>>> was to capture >>>>> the ITU requirements? >>>> >>>> yes - that is true... >>>> >>>> but we also need to capture all requirements for the >> MPLS-TP whether >>>> they are in the captured by the ITU-T or not. >>>>> >>>>> What is the MEAD development work covering - both ITU >>>> requirements and >>>>> "other (anonymous) SPs requirements"? >>>> >>>> if there is "only" requirements that originates from ITU-T this is >>>> not a problem. I am not looking for anonymous >> requirements, if there >>>> is a requirement that is not from ITU-T we should make >> clear where it >>>> came form >>>> >>>> /Loa >>>>> >>>>> Deborah >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Sprecher, Nurit (NSN - IL/Israel - MiniMD) >>>>> [mailto:nurit.sprecher@nsn.com] >>>>> Sent: Friday, June 20, 2008 5:23 AM >>>>> To: ext Loa Andersson >>>>> Cc: BRUNGARD, DEBORAH A, ATTLABS; MEAD team; Sprecher, >> Nurit (NSN - >>>>> IL/Israel - MiniMD) >>>>> Subject: RE: [Mpls-interop] next MEAD team meeting >>>>> >>>>> Hi, >>>>> 1. I agree that validates may be a good option. >>>>> 2. IMO, these requirements are not only the ITU-T view. I >> got these >>>>> requirements from different SPs. As I indicated in the >>>> beginning of the >>>>> mail exchanges I would prefer to say: "This document >> specifies the >>>>> requirements for MPLS-TP in order to support capabilities and >>>>> functionalities as needed in transport environments (or >>>> networks)." But >>>>> this is something that we need the SPs to agree on. >>>>> Please note also that in the proposal just below I forgot >>>> to include the >>>>> indication that this is a joint work of ITU-T and IETF. >>>>> Best regards, >>>>> Nurit >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: ext Loa Andersson [mailto:loa@pi.nu] >>>>> Sent: Friday, June 20, 2008 11:57 >>>>> To: Sprecher, Nurit (NSN - IL/Israel - MiniMD) >>>>> Cc: ext BRUNGARD, DEBORAH A, ATTLABS; MEAD team >>>>> Subject: Re: [Mpls-interop] next MEAD team meeting >>>>> >>>>> All, >>>>> >>>>> just a few comments. >>>>> >>>>> Sprecher, Nurit (NSN - IL/Israel - MiniMD) wrote: >>>>>> Hi Deborah, >>>>>> I understand the intention, so how about the following >> (as we also >>>>>> indicated in the introduction): >>>>>> This document specifies >>>>> >>>>> I wonder if "specifies" is the right word - one way would >> be to say >>>>> "validates" indicating that this how we (IETF) understands these >>>>> requirements >>>>> >>>>> the ITU-T requirements for MPLS-TP in order to >>>>>> support capabilities and functionalities of MPLS as needed in >>>>>> transport environments. >>>>> >>>>> this indicates that there is nothing but ITU-T >> requirements in the >>>>> document, is that true? >>>>> >>>>> /Loa >>>>> >>>>>> MPLS is a maturing packet technology and it is already >> playing an >>>>>> important role in transport networks and services. >>>> However, not all of >>>>> >>>>>> MPLS's capabilities and mechnisms are needed and/or >>>> consistent with >>>>>> transport network operations. This document identifies the >>>> required >>>>>> capabilities for MPLS so that it can better fit a transport role. >>>>> >>>>>> Please advise. >>>>>> Best regards, >>>>>> Nurit >>>>>> >>>>>> ________________________________ >>>>>> >>>>>> From: ext BRUNGARD, DEBORAH A, ATTLABS [mailto:dbrungard@att.com] >>>>>> Sent: Thursday, June 19, 2008 23:04 >>>>>> To: Sprecher, Nurit (NSN - IL/Israel - MiniMD); MEAD team >>>>>> Subject: RE: [Mpls-interop] next MEAD team meeting >>>>>> >>>>>> >>>>>> Hi Nurit, >>>>>> >>>>>> I would prefer to clearly say the requirements are ITU >>>> requirements >>>>>> for MPLS in a transport environment. I think among some >>>> operators the >>>>>> line between transport equipment and packet equipment has already >>>>> blurred. >>>>>> For many operators, the preference may be to align with MPLS >>>>>> operations vs. transport. I think there are many differing >>>> opinions on >>>>> >>>>>> what MPLS/packet transport needs to support in a transport >>>>>> environment. So I prefer to clearly say these are ITU >>>> requirements, >>>>>> they do not necessarily reflect the operators >> contributing to this >>>>> document. >>>>>> >>>>>> On the 2nd bullet, the requirements document has many >>>>>> statements/requirements which may be interpreted by a >>>> reader as gaps >>>>>> in MPLS/IETF protocols. I was trying to say with this >> sentence the >>>>>> document is not addressing/identifying IETF protocol >>>> applicability or >>>>>> lack of capabilities e.g. the sentence: >>>>>> "Quality-of-service mechanisms are required in the >> packet transport >>>>>> network to ensure the prioritization of critical services, to >>>>>> guarantee BW and to control jitter and delay." >>>>>> >>>>>> QoS is not a new requirement for IETF protocols. Packet >> transport >>>>>> networks (and this requirement document) are not the first >>>> time that >>>>>> QoS mechanisms are identified as needed. This requirement is not >>>>>> intending to identify a gap in the current IETF protocol >>>> set. This was >>>>> >>>>>> what I was trying to say. >>>>>> >>>>>> Suggestions? >>>>>> Deborah >>>>>> >>>>>> >>>>>> >>>>>> ________________________________ >>>>>> >>>>>> From: Sprecher, Nurit (NSN - IL/Israel - MiniMD) >>>>>> [mailto:nurit.sprecher@nsn.com] >>>>>> Sent: Thursday, June 19, 2008 3:10 PM >>>>>> To: BRUNGARD, DEBORAH A, ATTLABS; MEAD team >>>>>> Cc: Sprecher, Nurit (NSN - IL/Israel - MiniMD) >>>>>> Subject: RE: [Mpls-interop] next MEAD team meeting >>>>>> >>>>>> >>>>>> >>>>>> Hi Deborah, >>>>>> >>>>>> I have a few comments regarding the proposed abstract: >>>>>> >>>>>> * I think we should say "This document specifies the >>>>>> requirements for MPLS-TP in order to support capabilities and >>>>>> functionalities as needed in transport environments (or >> networks). >>>>>> >>>>>> * I do not understand the sentence: It does not >>>> address IETF >>>>>> protocol applicability or capabilities. Do you mean >>>> applicability or >>>>>> capability of the current IETF documents? As IMO it will >> be of the >>>>>> documents we generate for MPLS-TP. >>>>>> >>>>>> * I think it is important to indicate that " This >>>> document is >>>>> a >>>>>> product of a joint ITU-IETF effort". >>>>>> >>>>>> Best regards, >>>>>> >>>>>> Nurit >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: mpls-interop-bounces@ietf.org >>>>>> [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext >> BRUNGARD, >>>>>> DEBORAH A, ATTLABS >>>>>> Sent: Thursday, June 19, 2008 21:11 >>>>>> To: MEAD team >>>>>> Subject: Re: [Mpls-interop] next MEAD team meeting >>>>>> >>>>>> >>>>>> >>>>>> Colleagues, >>>>>> >>>>>> >>>>>> >>>>>> I was thinking for the requirements we should include a >>>> sentence in >>>>>> the >>>>>> >>>>>> abstract to scope the MPLS-TP work as being part of a >>>> joint ITU-IETF >>>>>> >>>>>> effort. Not all readers (now and future) will be aware of >>>> why this is >>>>>> >>>>>> being done. In ccamp, we had done this for our ASON work. Maybe a >>>>>> >>>>>> similar sentence will be needed in the other documents? >>>> Should we have >>>>> >>>>>> a >>>>>> >>>>>> common sentence? >>>>>> >>>>>> >>>>>> >>>>>> How about for the abstract: >>>>>> >>>>>> This document summarizes the ITU-T requirements for >>>> MPLS-TP in order >>>>>> to >>>>>> >>>>>> support capabilities and functionalities as needed by the >>>> ITU-T. It >>>>>> does >>>>>> >>>>>> not address IETF protocol applicability or capabilities. >>>> This document >>>>>> >>>>>> is a product of a joint ITU-IETF effort. >>>>>> >>>>>> >>>>>> >>>>>> Deborah >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> >>>>>> From: mpls-interop-bounces@ietf.org >>>>>> >>>>>> [mailto:mpls-interop-bounces@ietf.org] On Behalf Of Ben >>>> Niven-Jenkins >>>>>> >>>>>> Sent: Thursday, June 19, 2008 1:21 PM >>>>>> >>>>>> To: Loa Andersson; MEAD team >>>>>> >>>>>> Subject: Re: [Mpls-interop] next MEAD team meeting >>>>>> >>>>>> >>>>>> >>>>>> Colleagues, >>>>>> >>>>>> >>>>>> >>>>>> FYI see attached for the latest draft of the MPLS-TP requirements >>>>> draft. >>>>>> >>>>>> >>>>>> Ben >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 19/06/2008 16:00, "Loa Andersson" wrote: >>>>>> >>>>>> >>>>>> >>>>>>> All, >>>>>> >>>>>>> the MEAD team will have the next meeting on Tuesday 24, at 6pm >>>>>>> i.e. 12am east coast and 9am California. >>>>>> >>>>>>> Again I plan the meeting to last an hour, and focus >> will be on the >>>>>>> document status. >>>>>> >>>>>>> Stewart will send out dial in details as usual. >>>>>> >>>>>>> /Loa >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> >>>>>> Mpls-interop mailing list >>>>>> >>>>>> Mpls-interop@ietf.org >>>>>> >>>>>> https://www.ietf.org/mailman/listinfo/mpls-interop >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> >> --------------------------------------------------------------------- >>>> - >>>>>> -- >>>>>> >>>>>> _______________________________________________ >>>>>> Mpls-interop mailing list >>>>>> Mpls-interop@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mpls-interop >>>>> >>>>> >>>>> -- >>>>> Loa Andersson >>>>> >>>>> Principal Networking Architect >>>>> Acreo AB phone: +46 8 632 77 14 >>>>> Isafjordsgatan 22 mobile: +46 739 81 21 64 >>>>> Kista, Sweden email: loa.andersson@acreo.se >>>>> loa@pi.nu >>>> >>>> >>>> -- >>>> Loa Andersson >>>> >>>> Principal Networking Architect >>>> Acreo AB phone: +46 8 632 77 14 >>>> Isafjordsgatan 22 mobile: +46 739 81 21 64 >>>> Kista, Sweden email: loa.andersson@acreo.se >>>> loa@pi.nu >>>> _______________________________________________ >>>> Mpls-interop mailing list >>>> Mpls-interop@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls-interop >>>> >>> >>> _______________________________________________ >>> Mpls-interop mailing list >>> Mpls-interop@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls-interop >> >> _______________________________________________ >> Mpls-interop mailing list >> Mpls-interop@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-interop >> _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop From mpls-interop-bounces@ietf.org Tue Jun 24 08:11:05 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DEE13A67E6; Tue, 24 Jun 2008 08:11:05 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 067C23A696F for ; Tue, 24 Jun 2008 08:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.382 X-Spam-Level: X-Spam-Status: No, score=-1.382 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MxfSotZeaGNR for ; Tue, 24 Jun 2008 08:11:01 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id C6F683A67E6 for ; Tue, 24 Jun 2008 08:11:00 -0700 (PDT) Received: from E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.109]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jun 2008 16:11:01 +0100 Received: from 217.32.164.184 ([217.32.164.184]) by E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.60]) via Exchange Front-End Server mail.bt.com ([193.113.197.28]) with Microsoft Exchange Server HTTP-DAV ; Tue, 24 Jun 2008 15:11:00 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Tue, 24 Jun 2008 16:10:59 +0100 From: Ben Niven-Jenkins To: "Sprecher, Nurit (NSN - IL/Israel - MiniMD)" , Malcolm Betts , Italo Busi , Loa Andersson , "BRUNGARD, DEBORAH A, ATTLABS" Message-ID: Thread-Topic: [Mpls-interop] MPLS-TP Requirements Abstract (was RE: next MEAD team meeting) Thread-Index: AcjS+oxykpiCiEFrSKaGeg3ms5bIkgCEBNYgADJ3f0IADAEoQAAAcoDVAAFJCKAAAERi1g== In-Reply-To: <9FF5BDAD88B9D84881609E89AC92FB83EBDA4C@DEMUEXC014.nsn-intra.net> Mime-version: 1.0 X-OriginalArrivalTime: 24 Jun 2008 15:11:01.0225 (UTC) FILETIME=[83620590:01C8D60C] Cc: MEAD team Subject: Re: [Mpls-interop] MPLS-TP Requirements Abstract (was RE: next MEAD team meeting) X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org I might not have been completely clear on what I was agreeing with. I agree the 2nd paragraph seems redundant and so we only need the first and third paragraphs. Ben On 24/06/2008 16:08, "Sprecher, Nurit (NSN - IL/Israel - MiniMD)" wrote: > Agree (and we get to the point where we started :-)) > > -----Original Message----- > From: mpls-interop-bounces@ietf.org > [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext Ben > Niven-Jenkins > Sent: Tuesday, June 24, 2008 17:27 > To: Malcolm Betts; Italo Busi; Loa Andersson; BRUNGARD, DEBORAH A, > ATTLABS > Cc: MEAD team > Subject: Re: [Mpls-interop] MPLS-TP Requirements Abstract (was RE: next > MEAD team meeting) > > Good point. I'm fine with the text you propose. Ben > > > > On 24/06/2008 15:21, "Malcolm Betts" wrote: > >> Ben, much better, I suggest rewording the second paragraph as below: >> >> " >>> This document specifies the requirements for an MPLS Transport >>> Profile >>> (MPLS-TP) in order to support the capabilities and functionalities >>> needed for packet transport network services and packet transport >>> network operations. >>> >>> This document incorporates requirements identified by ITU-T. >>> >>> This document is a product of a joint ITU-IETF effort. >>> " >> >> The current text implies that only ITU-T and service provider >> requirements are included. Maybe we should just delete the second >> paragraph since we do not need to identify the source of the >> requirements as long as the connection to the work in the ITU is > clear. >> >> >> Malcolm Betts >> Nortel Networks >> Phone: +1 613 763 7860 (ESN 393) >> email: betts01@nortel.com >> >> Confidentiality Notice: This message and any attachments may contain >> information that is privileged and confidential. If you have reason to > >> believe that you are not the intended recipient or a person >> responsible for delivering this message to an intended recipient, you >> are hereby notified that any review, dissemination, distribution, or >> copying of this message is strictly prohibited. If you have reason to >> believe that you are not the intended recipient or a person >> responsible for delivering this message to an intended recipient, >> please contact the sender immediately by reply email and destroy all >> copies of the original message. >> >> >>> -----Original Message----- >>> From: mpls-interop-bounces@ietf.org >>> [mailto:mpls-interop-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins >>> Sent: Tuesday, June 24, 2008 4:30 AM >>> To: Italo Busi; 'Loa Andersson'; 'BRUNGARD, DEBORAH A, ATTLABS' >>> Cc: 'MEAD team' >>> Subject: Re: [Mpls-interop] MPLS-TP Requirements Abstract (was RE: >>> next MEAD team meeting) >>> >>> I don't like this. I'm not clear why ITU-T has to be the only >>> organisation drawn out as the source of the requirements and I don't >>> like the idea of having to somehow identify/tag all requirements that > >>> are not from the ITU-T as I believe this to be an unnecessary >>> editorial overhead which will only get worse as the document evolves. >>> >>> How about this? >>> >>> " >>> This document specifies the requirements for an MPLS Transport >>> Profile >>> (MPLS-TP) in order to support the capabilities and functionalities >>> needed for packet transport network services and packet transport >>> network operations. >>> >>> These requirements are a combination of those derived from the set of > >>> requirements specified by ITU-T and requirements received directly >>> from Service Providers. >>> >>> This document is a product of a joint ITU-IETF effort. >>> " >>> >>> Ben >>> >>> >>> On 23/06/2008 09:38, "Italo Busi" >>> wrote: >>> >>>> If I understand properly the arguments in this discussion, it seems >>>> quite important to clarify in the scope that these >>> requirements are SP >>>> requirements as well as the fact that the source of most of >>> them (if >>>> not all) is ITU-T. >>>> >>>> What about the following abstract? >>>> >>>> " >>>> This document specifies the requirements for an MPLS >>> Transport Profile >>>> (MPLS-TP) >>>> in order to support capabilities and functionalities as needed for >>>> packet transport network services and network operations. >>>> >>>> Unless explicitly mentioned, these requirements are derived >>> from the >>>> set of requirements specified by ITU-T. >>>> >>>> This document is a product of a joint ITU-IETF effort. >>>> " >>>> >>>> Thanks, Italo >>>> >>>>> -----Original Message----- >>>>> From: mpls-interop-bounces@ietf.org >>>>> [mailto:mpls-interop-bounces@ietf.org] On Behalf Of Loa Andersson >>>>> Sent: Friday, June 20, 2008 7:25 PM >>>>> To: BRUNGARD, DEBORAH A, ATTLABS >>>>> Cc: MEAD team >>>>> Subject: Re: [Mpls-interop] next MEAD team meeting >>>>> >>>>> >>>>> >>>>> BRUNGARD, DEBORAH A, ATTLABS wrote: >>>>>> Hi, >>>>>> >>>>>> Thanks Loa for the hint. My understanding of the charter >>>>> was to capture >>>>>> the ITU requirements? >>>>> >>>>> yes - that is true... >>>>> >>>>> but we also need to capture all requirements for the >>> MPLS-TP whether >>>>> they are in the captured by the ITU-T or not. >>>>>> >>>>>> What is the MEAD development work covering - both ITU >>>>> requirements and >>>>>> "other (anonymous) SPs requirements"? >>>>> >>>>> if there is "only" requirements that originates from ITU-T this is >>>>> not a problem. I am not looking for anonymous >>> requirements, if there >>>>> is a requirement that is not from ITU-T we should make >>> clear where it >>>>> came form >>>>> >>>>> /Loa >>>>>> >>>>>> Deborah >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Sprecher, Nurit (NSN - IL/Israel - MiniMD) >>>>>> [mailto:nurit.sprecher@nsn.com] >>>>>> Sent: Friday, June 20, 2008 5:23 AM >>>>>> To: ext Loa Andersson >>>>>> Cc: BRUNGARD, DEBORAH A, ATTLABS; MEAD team; Sprecher, >>> Nurit (NSN - >>>>>> IL/Israel - MiniMD) >>>>>> Subject: RE: [Mpls-interop] next MEAD team meeting >>>>>> >>>>>> Hi, >>>>>> 1. I agree that validates may be a good option. >>>>>> 2. IMO, these requirements are not only the ITU-T view. I >>> got these >>>>>> requirements from different SPs. As I indicated in the >>>>> beginning of the >>>>>> mail exchanges I would prefer to say: "This document >>> specifies the >>>>>> requirements for MPLS-TP in order to support capabilities and >>>>>> functionalities as needed in transport environments (or >>>>> networks)." But >>>>>> this is something that we need the SPs to agree on. >>>>>> Please note also that in the proposal just below I forgot >>>>> to include the >>>>>> indication that this is a joint work of ITU-T and IETF. >>>>>> Best regards, >>>>>> Nurit >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: ext Loa Andersson [mailto:loa@pi.nu] >>>>>> Sent: Friday, June 20, 2008 11:57 >>>>>> To: Sprecher, Nurit (NSN - IL/Israel - MiniMD) >>>>>> Cc: ext BRUNGARD, DEBORAH A, ATTLABS; MEAD team >>>>>> Subject: Re: [Mpls-interop] next MEAD team meeting >>>>>> >>>>>> All, >>>>>> >>>>>> just a few comments. >>>>>> >>>>>> Sprecher, Nurit (NSN - IL/Israel - MiniMD) wrote: >>>>>>> Hi Deborah, >>>>>>> I understand the intention, so how about the following >>> (as we also >>>>>>> indicated in the introduction): >>>>>>> This document specifies >>>>>> >>>>>> I wonder if "specifies" is the right word - one way would >>> be to say >>>>>> "validates" indicating that this how we (IETF) understands these >>>>>> requirements >>>>>> >>>>>> the ITU-T requirements for MPLS-TP in order to >>>>>>> support capabilities and functionalities of MPLS as needed in >>>>>>> transport environments. >>>>>> >>>>>> this indicates that there is nothing but ITU-T >>> requirements in the >>>>>> document, is that true? >>>>>> >>>>>> /Loa >>>>>> >>>>>>> MPLS is a maturing packet technology and it is already >>> playing an >>>>>>> important role in transport networks and services. >>>>> However, not all of >>>>>> >>>>>>> MPLS's capabilities and mechnisms are needed and/or >>>>> consistent with >>>>>>> transport network operations. This document identifies the >>>>> required >>>>>>> capabilities for MPLS so that it can better fit a transport role. >>>>>> >>>>>>> Please advise. >>>>>>> Best regards, >>>>>>> Nurit >>>>>>> >>>>>>> ________________________________ >>>>>>> >>>>>>> From: ext BRUNGARD, DEBORAH A, ATTLABS [mailto:dbrungard@att.com] >>>>>>> Sent: Thursday, June 19, 2008 23:04 >>>>>>> To: Sprecher, Nurit (NSN - IL/Israel - MiniMD); MEAD team >>>>>>> Subject: RE: [Mpls-interop] next MEAD team meeting >>>>>>> >>>>>>> >>>>>>> Hi Nurit, >>>>>>> >>>>>>> I would prefer to clearly say the requirements are ITU >>>>> requirements >>>>>>> for MPLS in a transport environment. I think among some >>>>> operators the >>>>>>> line between transport equipment and packet equipment has already >>>>>> blurred. >>>>>>> For many operators, the preference may be to align with MPLS >>>>>>> operations vs. transport. I think there are many differing >>>>> opinions on >>>>>> >>>>>>> what MPLS/packet transport needs to support in a transport >>>>>>> environment. So I prefer to clearly say these are ITU >>>>> requirements, >>>>>>> they do not necessarily reflect the operators >>> contributing to this >>>>>> document. >>>>>>> >>>>>>> On the 2nd bullet, the requirements document has many >>>>>>> statements/requirements which may be interpreted by a >>>>> reader as gaps >>>>>>> in MPLS/IETF protocols. I was trying to say with this >>> sentence the >>>>>>> document is not addressing/identifying IETF protocol >>>>> applicability or >>>>>>> lack of capabilities e.g. the sentence: >>>>>>> "Quality-of-service mechanisms are required in the >>> packet transport >>>>>>> network to ensure the prioritization of critical services, to >>>>>>> guarantee BW and to control jitter and delay." >>>>>>> >>>>>>> QoS is not a new requirement for IETF protocols. Packet >>> transport >>>>>>> networks (and this requirement document) are not the first >>>>> time that >>>>>>> QoS mechanisms are identified as needed. This requirement is not >>>>>>> intending to identify a gap in the current IETF protocol >>>>> set. This was >>>>>> >>>>>>> what I was trying to say. >>>>>>> >>>>>>> Suggestions? >>>>>>> Deborah >>>>>>> >>>>>>> >>>>>>> >>>>>>> ________________________________ >>>>>>> >>>>>>> From: Sprecher, Nurit (NSN - IL/Israel - MiniMD) >>>>>>> [mailto:nurit.sprecher@nsn.com] >>>>>>> Sent: Thursday, June 19, 2008 3:10 PM >>>>>>> To: BRUNGARD, DEBORAH A, ATTLABS; MEAD team >>>>>>> Cc: Sprecher, Nurit (NSN - IL/Israel - MiniMD) >>>>>>> Subject: RE: [Mpls-interop] next MEAD team meeting >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi Deborah, >>>>>>> >>>>>>> I have a few comments regarding the proposed abstract: >>>>>>> >>>>>>> * I think we should say "This document specifies the >>>>>>> requirements for MPLS-TP in order to support capabilities and >>>>>>> functionalities as needed in transport environments (or >>> networks). >>>>>>> >>>>>>> * I do not understand the sentence: It does not >>>>> address IETF >>>>>>> protocol applicability or capabilities. Do you mean >>>>> applicability or >>>>>>> capability of the current IETF documents? As IMO it will >>> be of the >>>>>>> documents we generate for MPLS-TP. >>>>>>> >>>>>>> * I think it is important to indicate that " This >>>>> document is >>>>>> a >>>>>>> product of a joint ITU-IETF effort". >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> Nurit >>>>>>> >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: mpls-interop-bounces@ietf.org >>>>>>> [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext >>> BRUNGARD, >>>>>>> DEBORAH A, ATTLABS >>>>>>> Sent: Thursday, June 19, 2008 21:11 >>>>>>> To: MEAD team >>>>>>> Subject: Re: [Mpls-interop] next MEAD team meeting >>>>>>> >>>>>>> >>>>>>> >>>>>>> Colleagues, >>>>>>> >>>>>>> >>>>>>> >>>>>>> I was thinking for the requirements we should include a >>>>> sentence in >>>>>>> the >>>>>>> >>>>>>> abstract to scope the MPLS-TP work as being part of a >>>>> joint ITU-IETF >>>>>>> >>>>>>> effort. Not all readers (now and future) will be aware of >>>>> why this is >>>>>>> >>>>>>> being done. In ccamp, we had done this for our ASON work. Maybe a >>>>>>> >>>>>>> similar sentence will be needed in the other documents? >>>>> Should we have >>>>>> >>>>>>> a >>>>>>> >>>>>>> common sentence? >>>>>>> >>>>>>> >>>>>>> >>>>>>> How about for the abstract: >>>>>>> >>>>>>> This document summarizes the ITU-T requirements for >>>>> MPLS-TP in order >>>>>>> to >>>>>>> >>>>>>> support capabilities and functionalities as needed by the >>>>> ITU-T. It >>>>>>> does >>>>>>> >>>>>>> not address IETF protocol applicability or capabilities. >>>>> This document >>>>>>> >>>>>>> is a product of a joint ITU-IETF effort. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Deborah >>>>>>> >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> >>>>>>> From: mpls-interop-bounces@ietf.org >>>>>>> >>>>>>> [mailto:mpls-interop-bounces@ietf.org] On Behalf Of Ben >>>>> Niven-Jenkins >>>>>>> >>>>>>> Sent: Thursday, June 19, 2008 1:21 PM >>>>>>> >>>>>>> To: Loa Andersson; MEAD team >>>>>>> >>>>>>> Subject: Re: [Mpls-interop] next MEAD team meeting >>>>>>> >>>>>>> >>>>>>> >>>>>>> Colleagues, >>>>>>> >>>>>>> >>>>>>> >>>>>>> FYI see attached for the latest draft of the MPLS-TP requirements >>>>>> draft. >>>>>>> >>>>>>> >>>>>>> Ben >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 19/06/2008 16:00, "Loa Andersson" wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> All, >>>>>>> >>>>>>>> the MEAD team will have the next meeting on Tuesday 24, at 6pm >>>>>>>> i.e. 12am east coast and 9am California. >>>>>>> >>>>>>>> Again I plan the meeting to last an hour, and focus >>> will be on the >>>>>>>> document status. >>>>>>> >>>>>>>> Stewart will send out dial in details as usual. >>>>>>> >>>>>>>> /Loa >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> >>>>>>> Mpls-interop mailing list >>>>>>> >>>>>>> Mpls-interop@ietf.org >>>>>>> >>>>>>> https://www.ietf.org/mailman/listinfo/mpls-interop >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>> --------------------------------------------------------------------- >>>>> - >>>>>>> -- >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Mpls-interop mailing list >>>>>>> Mpls-interop@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mpls-interop >>>>>> >>>>>> >>>>>> -- >>>>>> Loa Andersson >>>>>> >>>>>> Principal Networking Architect >>>>>> Acreo AB phone: +46 8 632 77 14 >>>>>> Isafjordsgatan 22 mobile: +46 739 81 21 64 >>>>>> Kista, Sweden email: loa.andersson@acreo.se >>>>>> loa@pi.nu >>>>> >>>>> >>>>> -- >>>>> Loa Andersson >>>>> >>>>> Principal Networking Architect >>>>> Acreo AB phone: +46 8 632 77 14 >>>>> Isafjordsgatan 22 mobile: +46 739 81 21 64 >>>>> Kista, Sweden email: loa.andersson@acreo.se >>>>> loa@pi.nu >>>>> _______________________________________________ >>>>> Mpls-interop mailing list >>>>> Mpls-interop@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mpls-interop >>>>> >>>> >>>> _______________________________________________ >>>> Mpls-interop mailing list >>>> Mpls-interop@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls-interop >>> >>> _______________________________________________ >>> Mpls-interop mailing list >>> Mpls-interop@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls-interop >>> > > _______________________________________________ > Mpls-interop mailing list > Mpls-interop@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-interop _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop From mpls-interop-bounces@ietf.org Tue Jun 24 08:13:13 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB8C93A6821; Tue, 24 Jun 2008 08:13:13 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F10D3A68F3 for ; Tue, 24 Jun 2008 08:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.772 X-Spam-Level: X-Spam-Status: No, score=-2.772 tagged_above=-999 required=5 tests=[AWL=-0.173, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bWuf57zMusUe for ; Tue, 24 Jun 2008 08:13:10 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id C627C3A689B for ; Tue, 24 Jun 2008 08:13:09 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m5OFD1LU004562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Jun 2008 17:13:01 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m5OFD1in012100; Tue, 24 Jun 2008 17:13:01 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Jun 2008 17:13:00 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Jun 2008 17:12:58 +0200 Message-ID: <9FF5BDAD88B9D84881609E89AC92FB83EBDA50@DEMUEXC014.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mpls-interop] MPLS-TP Requirements Abstract (was RE: next MEAD team meeting) Thread-Index: AcjS+oxykpiCiEFrSKaGeg3ms5bIkgCEBNYgADJ3f0IADAEoQAAAcoDVAAFJCKAAAERi1gAACIuA From: "Sprecher, Nurit (NSN - IL/Israel - MiniMD)" To: "ext Ben Niven-Jenkins" , "Malcolm Betts" , "Italo Busi" , "Loa Andersson" , "BRUNGARD, DEBORAH A, ATTLABS" X-OriginalArrivalTime: 24 Jun 2008 15:13:00.0440 (UTC) FILETIME=[CA70C980:01C8D60C] Cc: MEAD team Subject: Re: [Mpls-interop] MPLS-TP Requirements Abstract (was RE: next MEAD team meeting) X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org You were clear. I said we got to the starting point where we did not indicate explicitly the source of the requirements. -----Original Message----- From: ext Ben Niven-Jenkins [mailto:benjamin.niven-jenkins@bt.com] Sent: Tuesday, June 24, 2008 18:11 To: Sprecher, Nurit (NSN - IL/Israel - MiniMD); Malcolm Betts; Italo Busi; Loa Andersson; BRUNGARD, DEBORAH A, ATTLABS Cc: MEAD team Subject: Re: [Mpls-interop] MPLS-TP Requirements Abstract (was RE: next MEAD team meeting) I might not have been completely clear on what I was agreeing with. I agree the 2nd paragraph seems redundant and so we only need the first and third paragraphs. Ben On 24/06/2008 16:08, "Sprecher, Nurit (NSN - IL/Israel - MiniMD)" wrote: > Agree (and we get to the point where we started :-)) > > -----Original Message----- > From: mpls-interop-bounces@ietf.org > [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext Ben > Niven-Jenkins > Sent: Tuesday, June 24, 2008 17:27 > To: Malcolm Betts; Italo Busi; Loa Andersson; BRUNGARD, DEBORAH A, > ATTLABS > Cc: MEAD team > Subject: Re: [Mpls-interop] MPLS-TP Requirements Abstract (was RE: > next MEAD team meeting) > > Good point. I'm fine with the text you propose. Ben > > > > On 24/06/2008 15:21, "Malcolm Betts" wrote: > >> Ben, much better, I suggest rewording the second paragraph as below: >> >> " >>> This document specifies the requirements for an MPLS Transport >>> Profile >>> (MPLS-TP) in order to support the capabilities and functionalities >>> needed for packet transport network services and packet transport >>> network operations. >>> >>> This document incorporates requirements identified by ITU-T. >>> >>> This document is a product of a joint ITU-IETF effort. >>> " >> >> The current text implies that only ITU-T and service provider >> requirements are included. Maybe we should just delete the second >> paragraph since we do not need to identify the source of the >> requirements as long as the connection to the work in the ITU is > clear. >> >> >> Malcolm Betts >> Nortel Networks >> Phone: +1 613 763 7860 (ESN 393) >> email: betts01@nortel.com >> >> Confidentiality Notice: This message and any attachments may contain >> information that is privileged and confidential. If you have reason >> to > >> believe that you are not the intended recipient or a person >> responsible for delivering this message to an intended recipient, you >> are hereby notified that any review, dissemination, distribution, or >> copying of this message is strictly prohibited. If you have reason to >> believe that you are not the intended recipient or a person >> responsible for delivering this message to an intended recipient, >> please contact the sender immediately by reply email and destroy all >> copies of the original message. >> >> >>> -----Original Message----- >>> From: mpls-interop-bounces@ietf.org >>> [mailto:mpls-interop-bounces@ietf.org] On Behalf Of Ben >>> Niven-Jenkins >>> Sent: Tuesday, June 24, 2008 4:30 AM >>> To: Italo Busi; 'Loa Andersson'; 'BRUNGARD, DEBORAH A, ATTLABS' >>> Cc: 'MEAD team' >>> Subject: Re: [Mpls-interop] MPLS-TP Requirements Abstract (was RE: >>> next MEAD team meeting) >>> >>> I don't like this. I'm not clear why ITU-T has to be the only >>> organisation drawn out as the source of the requirements and I don't >>> like the idea of having to somehow identify/tag all requirements >>> that > >>> are not from the ITU-T as I believe this to be an unnecessary >>> editorial overhead which will only get worse as the document evolves. >>> >>> How about this? >>> >>> " >>> This document specifies the requirements for an MPLS Transport >>> Profile >>> (MPLS-TP) in order to support the capabilities and functionalities >>> needed for packet transport network services and packet transport >>> network operations. >>> >>> These requirements are a combination of those derived from the set >>> of > >>> requirements specified by ITU-T and requirements received directly >>> from Service Providers. >>> >>> This document is a product of a joint ITU-IETF effort. >>> " >>> >>> Ben >>> >>> >>> On 23/06/2008 09:38, "Italo Busi" >>> wrote: >>> >>>> If I understand properly the arguments in this discussion, it seems >>>> quite important to clarify in the scope that these >>> requirements are SP >>>> requirements as well as the fact that the source of most of >>> them (if >>>> not all) is ITU-T. >>>> >>>> What about the following abstract? >>>> >>>> " >>>> This document specifies the requirements for an MPLS >>> Transport Profile >>>> (MPLS-TP) >>>> in order to support capabilities and functionalities as needed for >>>> packet transport network services and network operations. >>>> >>>> Unless explicitly mentioned, these requirements are derived >>> from the >>>> set of requirements specified by ITU-T. >>>> >>>> This document is a product of a joint ITU-IETF effort. >>>> " >>>> >>>> Thanks, Italo >>>> >>>>> -----Original Message----- >>>>> From: mpls-interop-bounces@ietf.org >>>>> [mailto:mpls-interop-bounces@ietf.org] On Behalf Of Loa Andersson >>>>> Sent: Friday, June 20, 2008 7:25 PM >>>>> To: BRUNGARD, DEBORAH A, ATTLABS >>>>> Cc: MEAD team >>>>> Subject: Re: [Mpls-interop] next MEAD team meeting >>>>> >>>>> >>>>> >>>>> BRUNGARD, DEBORAH A, ATTLABS wrote: >>>>>> Hi, >>>>>> >>>>>> Thanks Loa for the hint. My understanding of the charter >>>>> was to capture >>>>>> the ITU requirements? >>>>> >>>>> yes - that is true... >>>>> >>>>> but we also need to capture all requirements for the >>> MPLS-TP whether >>>>> they are in the captured by the ITU-T or not. >>>>>> >>>>>> What is the MEAD development work covering - both ITU >>>>> requirements and >>>>>> "other (anonymous) SPs requirements"? >>>>> >>>>> if there is "only" requirements that originates from ITU-T this is >>>>> not a problem. I am not looking for anonymous >>> requirements, if there >>>>> is a requirement that is not from ITU-T we should make >>> clear where it >>>>> came form >>>>> >>>>> /Loa >>>>>> >>>>>> Deborah >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Sprecher, Nurit (NSN - IL/Israel - MiniMD) >>>>>> [mailto:nurit.sprecher@nsn.com] >>>>>> Sent: Friday, June 20, 2008 5:23 AM >>>>>> To: ext Loa Andersson >>>>>> Cc: BRUNGARD, DEBORAH A, ATTLABS; MEAD team; Sprecher, >>> Nurit (NSN - >>>>>> IL/Israel - MiniMD) >>>>>> Subject: RE: [Mpls-interop] next MEAD team meeting >>>>>> >>>>>> Hi, >>>>>> 1. I agree that validates may be a good option. >>>>>> 2. IMO, these requirements are not only the ITU-T view. I >>> got these >>>>>> requirements from different SPs. As I indicated in the >>>>> beginning of the >>>>>> mail exchanges I would prefer to say: "This document >>> specifies the >>>>>> requirements for MPLS-TP in order to support capabilities and >>>>>> functionalities as needed in transport environments (or >>>>> networks)." But >>>>>> this is something that we need the SPs to agree on. >>>>>> Please note also that in the proposal just below I forgot >>>>> to include the >>>>>> indication that this is a joint work of ITU-T and IETF. >>>>>> Best regards, >>>>>> Nurit >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: ext Loa Andersson [mailto:loa@pi.nu] >>>>>> Sent: Friday, June 20, 2008 11:57 >>>>>> To: Sprecher, Nurit (NSN - IL/Israel - MiniMD) >>>>>> Cc: ext BRUNGARD, DEBORAH A, ATTLABS; MEAD team >>>>>> Subject: Re: [Mpls-interop] next MEAD team meeting >>>>>> >>>>>> All, >>>>>> >>>>>> just a few comments. >>>>>> >>>>>> Sprecher, Nurit (NSN - IL/Israel - MiniMD) wrote: >>>>>>> Hi Deborah, >>>>>>> I understand the intention, so how about the following >>> (as we also >>>>>>> indicated in the introduction): >>>>>>> This document specifies >>>>>> >>>>>> I wonder if "specifies" is the right word - one way would >>> be to say >>>>>> "validates" indicating that this how we (IETF) understands these >>>>>> requirements >>>>>> >>>>>> the ITU-T requirements for MPLS-TP in order to >>>>>>> support capabilities and functionalities of MPLS as needed in >>>>>>> transport environments. >>>>>> >>>>>> this indicates that there is nothing but ITU-T >>> requirements in the >>>>>> document, is that true? >>>>>> >>>>>> /Loa >>>>>> >>>>>>> MPLS is a maturing packet technology and it is already >>> playing an >>>>>>> important role in transport networks and services. >>>>> However, not all of >>>>>> >>>>>>> MPLS's capabilities and mechnisms are needed and/or >>>>> consistent with >>>>>>> transport network operations. This document identifies the >>>>> required >>>>>>> capabilities for MPLS so that it can better fit a transport role. >>>>>> >>>>>>> Please advise. >>>>>>> Best regards, >>>>>>> Nurit >>>>>>> >>>>>>> ________________________________ >>>>>>> >>>>>>> From: ext BRUNGARD, DEBORAH A, ATTLABS >>>>>>> [mailto:dbrungard@att.com] >>>>>>> Sent: Thursday, June 19, 2008 23:04 >>>>>>> To: Sprecher, Nurit (NSN - IL/Israel - MiniMD); MEAD team >>>>>>> Subject: RE: [Mpls-interop] next MEAD team meeting >>>>>>> >>>>>>> >>>>>>> Hi Nurit, >>>>>>> >>>>>>> I would prefer to clearly say the requirements are ITU >>>>> requirements >>>>>>> for MPLS in a transport environment. I think among some >>>>> operators the >>>>>>> line between transport equipment and packet equipment has >>>>>>> already >>>>>> blurred. >>>>>>> For many operators, the preference may be to align with MPLS >>>>>>> operations vs. transport. I think there are many differing >>>>> opinions on >>>>>> >>>>>>> what MPLS/packet transport needs to support in a transport >>>>>>> environment. So I prefer to clearly say these are ITU >>>>> requirements, >>>>>>> they do not necessarily reflect the operators >>> contributing to this >>>>>> document. >>>>>>> >>>>>>> On the 2nd bullet, the requirements document has many >>>>>>> statements/requirements which may be interpreted by a >>>>> reader as gaps >>>>>>> in MPLS/IETF protocols. I was trying to say with this >>> sentence the >>>>>>> document is not addressing/identifying IETF protocol >>>>> applicability or >>>>>>> lack of capabilities e.g. the sentence: >>>>>>> "Quality-of-service mechanisms are required in the >>> packet transport >>>>>>> network to ensure the prioritization of critical services, to >>>>>>> guarantee BW and to control jitter and delay." >>>>>>> >>>>>>> QoS is not a new requirement for IETF protocols. Packet >>> transport >>>>>>> networks (and this requirement document) are not the first >>>>> time that >>>>>>> QoS mechanisms are identified as needed. This requirement is not >>>>>>> intending to identify a gap in the current IETF protocol >>>>> set. This was >>>>>> >>>>>>> what I was trying to say. >>>>>>> >>>>>>> Suggestions? >>>>>>> Deborah >>>>>>> >>>>>>> >>>>>>> >>>>>>> ________________________________ >>>>>>> >>>>>>> From: Sprecher, Nurit (NSN - IL/Israel - MiniMD) >>>>>>> [mailto:nurit.sprecher@nsn.com] >>>>>>> Sent: Thursday, June 19, 2008 3:10 PM >>>>>>> To: BRUNGARD, DEBORAH A, ATTLABS; MEAD team >>>>>>> Cc: Sprecher, Nurit (NSN - IL/Israel - MiniMD) >>>>>>> Subject: RE: [Mpls-interop] next MEAD team meeting >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi Deborah, >>>>>>> >>>>>>> I have a few comments regarding the proposed abstract: >>>>>>> >>>>>>> * I think we should say "This document specifies the >>>>>>> requirements for MPLS-TP in order to support capabilities and >>>>>>> functionalities as needed in transport environments (or >>> networks). >>>>>>> >>>>>>> * I do not understand the sentence: It does not >>>>> address IETF >>>>>>> protocol applicability or capabilities. Do you mean >>>>> applicability or >>>>>>> capability of the current IETF documents? As IMO it will >>> be of the >>>>>>> documents we generate for MPLS-TP. >>>>>>> >>>>>>> * I think it is important to indicate that " This >>>>> document is >>>>>> a >>>>>>> product of a joint ITU-IETF effort". >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> Nurit >>>>>>> >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: mpls-interop-bounces@ietf.org >>>>>>> [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext >>> BRUNGARD, >>>>>>> DEBORAH A, ATTLABS >>>>>>> Sent: Thursday, June 19, 2008 21:11 >>>>>>> To: MEAD team >>>>>>> Subject: Re: [Mpls-interop] next MEAD team meeting >>>>>>> >>>>>>> >>>>>>> >>>>>>> Colleagues, >>>>>>> >>>>>>> >>>>>>> >>>>>>> I was thinking for the requirements we should include a >>>>> sentence in >>>>>>> the >>>>>>> >>>>>>> abstract to scope the MPLS-TP work as being part of a >>>>> joint ITU-IETF >>>>>>> >>>>>>> effort. Not all readers (now and future) will be aware of >>>>> why this is >>>>>>> >>>>>>> being done. In ccamp, we had done this for our ASON work. Maybe >>>>>>> a >>>>>>> >>>>>>> similar sentence will be needed in the other documents? >>>>> Should we have >>>>>> >>>>>>> a >>>>>>> >>>>>>> common sentence? >>>>>>> >>>>>>> >>>>>>> >>>>>>> How about for the abstract: >>>>>>> >>>>>>> This document summarizes the ITU-T requirements for >>>>> MPLS-TP in order >>>>>>> to >>>>>>> >>>>>>> support capabilities and functionalities as needed by the >>>>> ITU-T. It >>>>>>> does >>>>>>> >>>>>>> not address IETF protocol applicability or capabilities. >>>>> This document >>>>>>> >>>>>>> is a product of a joint ITU-IETF effort. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Deborah >>>>>>> >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> >>>>>>> From: mpls-interop-bounces@ietf.org >>>>>>> >>>>>>> [mailto:mpls-interop-bounces@ietf.org] On Behalf Of Ben >>>>> Niven-Jenkins >>>>>>> >>>>>>> Sent: Thursday, June 19, 2008 1:21 PM >>>>>>> >>>>>>> To: Loa Andersson; MEAD team >>>>>>> >>>>>>> Subject: Re: [Mpls-interop] next MEAD team meeting >>>>>>> >>>>>>> >>>>>>> >>>>>>> Colleagues, >>>>>>> >>>>>>> >>>>>>> >>>>>>> FYI see attached for the latest draft of the MPLS-TP >>>>>>> requirements >>>>>> draft. >>>>>>> >>>>>>> >>>>>>> Ben >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 19/06/2008 16:00, "Loa Andersson" wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> All, >>>>>>> >>>>>>>> the MEAD team will have the next meeting on Tuesday 24, at 6pm >>>>>>>> i.e. 12am east coast and 9am California. >>>>>>> >>>>>>>> Again I plan the meeting to last an hour, and focus >>> will be on the >>>>>>>> document status. >>>>>>> >>>>>>>> Stewart will send out dial in details as usual. >>>>>>> >>>>>>>> /Loa >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> >>>>>>> Mpls-interop mailing list >>>>>>> >>>>>>> Mpls-interop@ietf.org >>>>>>> >>>>>>> https://www.ietf.org/mailman/listinfo/mpls-interop >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>> -------------------------------------------------------------------- >>> - >>>>> - >>>>>>> -- >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Mpls-interop mailing list >>>>>>> Mpls-interop@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mpls-interop >>>>>> >>>>>> >>>>>> -- >>>>>> Loa Andersson >>>>>> >>>>>> Principal Networking Architect >>>>>> Acreo AB phone: +46 8 632 77 14 >>>>>> Isafjordsgatan 22 mobile: +46 739 81 21 64 >>>>>> Kista, Sweden email: loa.andersson@acreo.se >>>>>> loa@pi.nu >>>>> >>>>> >>>>> -- >>>>> Loa Andersson >>>>> >>>>> Principal Networking Architect >>>>> Acreo AB phone: +46 8 632 77 14 >>>>> Isafjordsgatan 22 mobile: +46 739 81 21 64 >>>>> Kista, Sweden email: loa.andersson@acreo.se >>>>> loa@pi.nu >>>>> _______________________________________________ >>>>> Mpls-interop mailing list >>>>> Mpls-interop@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mpls-interop >>>>> >>>> >>>> _______________________________________________ >>>> Mpls-interop mailing list >>>> Mpls-interop@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls-interop >>> >>> _______________________________________________ >>> Mpls-interop mailing list >>> Mpls-interop@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls-interop >>> > > _______________________________________________ > Mpls-interop mailing list > Mpls-interop@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-interop _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop From mpls-interop-bounces@ietf.org Tue Jun 24 08:26:52 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88F333A6821; Tue, 24 Jun 2008 08:26:52 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 675B73A6852 for ; Tue, 24 Jun 2008 08:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.949 X-Spam-Level: X-Spam-Status: No, score=-105.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33KCA7J1xbIv for ; Tue, 24 Jun 2008 08:26:49 -0700 (PDT) Received: from mail203.messagelabs.com (mail203.messagelabs.com [216.82.254.243]) by core3.amsl.com (Postfix) with ESMTP id 5F6A43A6821 for ; Tue, 24 Jun 2008 08:26:49 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-14.tower-203.messagelabs.com!1214321192!24310250!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 13066 invoked from network); 24 Jun 2008 15:26:32 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-14.tower-203.messagelabs.com with AES256-SHA encrypted SMTP; 24 Jun 2008 15:26:32 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m5OFQl1I019574 for ; Tue, 24 Jun 2008 11:26:48 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m5OFQgYH019467 for ; Tue, 24 Jun 2008 11:26:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Jun 2008 11:26:39 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mpls-interop] MPLS-TP Requirements Abstract (was RE: next MEAD team meeting) Thread-Index: AcjS+oxykpiCiEFrSKaGeg3ms5bIkgCEBNYgADJ3f0IADAEoQAAAcoDVAAE2twA= References: <0BDFFF51DC89434FA33F8B37FCE363D513267B65@zcarhxm2.corp.nortel.com> From: "BRUNGARD, DEBORAH A, ATTLABS" To: "Ben Niven-Jenkins" , "Malcolm Betts" , "Italo Busi" , "Loa Andersson" Cc: MEAD team Subject: Re: [Mpls-interop] MPLS-TP Requirements Abstract (was RE: next MEAD team meeting) X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org Hi, The sentences now seem to have lost the traceability to ITU's MPLS-TP (formerly TMPLS). Are we doing requirements for G8110 (TMPLS) series of Recommendations or some other "packet transport network" technology e.g. G800 (completed in 2007) networks? Is the technology "packet transport network" viewed as ITU-based or "not necessarily ITU" technology? If it's for ITU technology, the sentence should at least provide a pointer: "This document specifies the requirements for an MPLS Transport Profile (MPLS-TP) in order to support the capabilities and functionalities of packet transport networks as defined by ITU-T." And then, can skip both of the other sentences. Deborah -----Original Message----- From: Ben Niven-Jenkins [mailto:benjamin.niven-jenkins@bt.com] Sent: Tuesday, June 24, 2008 10:27 AM To: Malcolm Betts; Italo Busi; Loa Andersson; BRUNGARD, DEBORAH A, ATTLABS Cc: MEAD team Subject: Re: [Mpls-interop] MPLS-TP Requirements Abstract (was RE: next MEAD team meeting) Good point. I'm fine with the text you propose. Ben On 24/06/2008 15:21, "Malcolm Betts" wrote: > Ben, much better, I suggest rewording the second paragraph as below: > > " >> This document specifies the requirements for an MPLS Transport Profile >> (MPLS-TP) in order to support the capabilities and >> functionalities needed for packet transport network services >> and packet transport network operations. >> >> This document incorporates requirements identified by ITU-T. >> >> This document is a product of a joint ITU-IETF effort. >> " > > The current text implies that only ITU-T and service provider > requirements are included. Maybe we should just delete the second > paragraph since we do not need to identify the source of the > requirements as long as the connection to the work in the ITU is clear. > > > Malcolm Betts > Nortel Networks > Phone: +1 613 763 7860 (ESN 393) > email: betts01@nortel.com > > Confidentiality Notice: This message and any attachments may contain > information that is privileged and confidential. If you have reason to > believe that you are not the intended recipient or a person responsible > for delivering this message to an intended recipient, you are hereby > notified that any review, dissemination, distribution, or copying of > this message is strictly prohibited. If you have reason to believe that > you are not the intended recipient or a person responsible for > delivering this message to an intended recipient, please contact the > sender immediately by reply email and destroy all copies of the original > message. > > >> -----Original Message----- >> From: mpls-interop-bounces@ietf.org >> [mailto:mpls-interop-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins >> Sent: Tuesday, June 24, 2008 4:30 AM >> To: Italo Busi; 'Loa Andersson'; 'BRUNGARD, DEBORAH A, ATTLABS' >> Cc: 'MEAD team' >> Subject: Re: [Mpls-interop] MPLS-TP Requirements Abstract >> (was RE: next MEAD team meeting) >> >> I don't like this. I'm not clear why ITU-T has to be the >> only organisation drawn out as the source of the requirements >> and I don't like the idea of having to somehow identify/tag >> all requirements that are not from the ITU-T as I believe >> this to be an unnecessary editorial overhead which will only >> get worse as the document evolves. >> >> How about this? >> >> " >> This document specifies the requirements for an MPLS Transport Profile >> (MPLS-TP) in order to support the capabilities and >> functionalities needed for packet transport network services >> and packet transport network operations. >> >> These requirements are a combination of those derived from >> the set of requirements specified by ITU-T and requirements >> received directly from Service Providers. >> >> This document is a product of a joint ITU-IETF effort. >> " >> >> Ben >> >> >> On 23/06/2008 09:38, "Italo Busi" >> wrote: >> >>> If I understand properly the arguments in this discussion, it seems >>> quite important to clarify in the scope that these >> requirements are SP >>> requirements as well as the fact that the source of most of >> them (if >>> not all) is ITU-T. >>> >>> What about the following abstract? >>> >>> " >>> This document specifies the requirements for an MPLS >> Transport Profile >>> (MPLS-TP) >>> in order to support capabilities and functionalities as needed for >>> packet transport network services and network operations. >>> >>> Unless explicitly mentioned, these requirements are derived >> from the >>> set of requirements specified by ITU-T. >>> >>> This document is a product of a joint ITU-IETF effort. >>> " >>> >>> Thanks, Italo >>> >>>> -----Original Message----- >>>> From: mpls-interop-bounces@ietf.org >>>> [mailto:mpls-interop-bounces@ietf.org] On Behalf Of Loa Andersson >>>> Sent: Friday, June 20, 2008 7:25 PM >>>> To: BRUNGARD, DEBORAH A, ATTLABS >>>> Cc: MEAD team >>>> Subject: Re: [Mpls-interop] next MEAD team meeting >>>> >>>> >>>> >>>> BRUNGARD, DEBORAH A, ATTLABS wrote: >>>>> Hi, >>>>> >>>>> Thanks Loa for the hint. My understanding of the charter >>>> was to capture >>>>> the ITU requirements? >>>> >>>> yes - that is true... >>>> >>>> but we also need to capture all requirements for the >> MPLS-TP whether >>>> they are in the captured by the ITU-T or not. >>>>> >>>>> What is the MEAD development work covering - both ITU >>>> requirements and >>>>> "other (anonymous) SPs requirements"? >>>> >>>> if there is "only" requirements that originates from ITU-T this is >>>> not a problem. I am not looking for anonymous >> requirements, if there >>>> is a requirement that is not from ITU-T we should make >> clear where it >>>> came form >>>> >>>> /Loa >>>>> >>>>> Deborah >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Sprecher, Nurit (NSN - IL/Israel - MiniMD) >>>>> [mailto:nurit.sprecher@nsn.com] >>>>> Sent: Friday, June 20, 2008 5:23 AM >>>>> To: ext Loa Andersson >>>>> Cc: BRUNGARD, DEBORAH A, ATTLABS; MEAD team; Sprecher, >> Nurit (NSN - >>>>> IL/Israel - MiniMD) >>>>> Subject: RE: [Mpls-interop] next MEAD team meeting >>>>> >>>>> Hi, >>>>> 1. I agree that validates may be a good option. >>>>> 2. IMO, these requirements are not only the ITU-T view. I >> got these >>>>> requirements from different SPs. As I indicated in the >>>> beginning of the >>>>> mail exchanges I would prefer to say: "This document >> specifies the >>>>> requirements for MPLS-TP in order to support capabilities and >>>>> functionalities as needed in transport environments (or >>>> networks)." But >>>>> this is something that we need the SPs to agree on. >>>>> Please note also that in the proposal just below I forgot >>>> to include the >>>>> indication that this is a joint work of ITU-T and IETF. >>>>> Best regards, >>>>> Nurit >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: ext Loa Andersson [mailto:loa@pi.nu] >>>>> Sent: Friday, June 20, 2008 11:57 >>>>> To: Sprecher, Nurit (NSN - IL/Israel - MiniMD) >>>>> Cc: ext BRUNGARD, DEBORAH A, ATTLABS; MEAD team >>>>> Subject: Re: [Mpls-interop] next MEAD team meeting >>>>> >>>>> All, >>>>> >>>>> just a few comments. >>>>> >>>>> Sprecher, Nurit (NSN - IL/Israel - MiniMD) wrote: >>>>>> Hi Deborah, >>>>>> I understand the intention, so how about the following >> (as we also >>>>>> indicated in the introduction): >>>>>> This document specifies >>>>> >>>>> I wonder if "specifies" is the right word - one way would >> be to say >>>>> "validates" indicating that this how we (IETF) understands these >>>>> requirements >>>>> >>>>> the ITU-T requirements for MPLS-TP in order to >>>>>> support capabilities and functionalities of MPLS as needed in >>>>>> transport environments. >>>>> >>>>> this indicates that there is nothing but ITU-T >> requirements in the >>>>> document, is that true? >>>>> >>>>> /Loa >>>>> >>>>>> MPLS is a maturing packet technology and it is already >> playing an >>>>>> important role in transport networks and services. >>>> However, not all of >>>>> >>>>>> MPLS's capabilities and mechnisms are needed and/or >>>> consistent with >>>>>> transport network operations. This document identifies the >>>> required >>>>>> capabilities for MPLS so that it can better fit a transport role. >>>>> >>>>>> Please advise. >>>>>> Best regards, >>>>>> Nurit >>>>>> >>>>>> ________________________________ >>>>>> >>>>>> From: ext BRUNGARD, DEBORAH A, ATTLABS [mailto:dbrungard@att.com] >>>>>> Sent: Thursday, June 19, 2008 23:04 >>>>>> To: Sprecher, Nurit (NSN - IL/Israel - MiniMD); MEAD team >>>>>> Subject: RE: [Mpls-interop] next MEAD team meeting >>>>>> >>>>>> >>>>>> Hi Nurit, >>>>>> >>>>>> I would prefer to clearly say the requirements are ITU >>>> requirements >>>>>> for MPLS in a transport environment. I think among some >>>> operators the >>>>>> line between transport equipment and packet equipment has already >>>>> blurred. >>>>>> For many operators, the preference may be to align with MPLS >>>>>> operations vs. transport. I think there are many differing >>>> opinions on >>>>> >>>>>> what MPLS/packet transport needs to support in a transport >>>>>> environment. So I prefer to clearly say these are ITU >>>> requirements, >>>>>> they do not necessarily reflect the operators >> contributing to this >>>>> document. >>>>>> >>>>>> On the 2nd bullet, the requirements document has many >>>>>> statements/requirements which may be interpreted by a >>>> reader as gaps >>>>>> in MPLS/IETF protocols. I was trying to say with this >> sentence the >>>>>> document is not addressing/identifying IETF protocol >>>> applicability or >>>>>> lack of capabilities e.g. the sentence: >>>>>> "Quality-of-service mechanisms are required in the >> packet transport >>>>>> network to ensure the prioritization of critical services, to >>>>>> guarantee BW and to control jitter and delay." >>>>>> >>>>>> QoS is not a new requirement for IETF protocols. Packet >> transport >>>>>> networks (and this requirement document) are not the first >>>> time that >>>>>> QoS mechanisms are identified as needed. This requirement is not >>>>>> intending to identify a gap in the current IETF protocol >>>> set. This was >>>>> >>>>>> what I was trying to say. >>>>>> >>>>>> Suggestions? >>>>>> Deborah >>>>>> >>>>>> >>>>>> >>>>>> ________________________________ >>>>>> >>>>>> From: Sprecher, Nurit (NSN - IL/Israel - MiniMD) >>>>>> [mailto:nurit.sprecher@nsn.com] >>>>>> Sent: Thursday, June 19, 2008 3:10 PM >>>>>> To: BRUNGARD, DEBORAH A, ATTLABS; MEAD team >>>>>> Cc: Sprecher, Nurit (NSN - IL/Israel - MiniMD) >>>>>> Subject: RE: [Mpls-interop] next MEAD team meeting >>>>>> >>>>>> >>>>>> >>>>>> Hi Deborah, >>>>>> >>>>>> I have a few comments regarding the proposed abstract: >>>>>> >>>>>> * I think we should say "This document specifies the >>>>>> requirements for MPLS-TP in order to support capabilities and >>>>>> functionalities as needed in transport environments (or >> networks). >>>>>> >>>>>> * I do not understand the sentence: It does not >>>> address IETF >>>>>> protocol applicability or capabilities. Do you mean >>>> applicability or >>>>>> capability of the current IETF documents? As IMO it will >> be of the >>>>>> documents we generate for MPLS-TP. >>>>>> >>>>>> * I think it is important to indicate that " This >>>> document is >>>>> a >>>>>> product of a joint ITU-IETF effort". >>>>>> >>>>>> Best regards, >>>>>> >>>>>> Nurit >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: mpls-interop-bounces@ietf.org >>>>>> [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext >> BRUNGARD, >>>>>> DEBORAH A, ATTLABS >>>>>> Sent: Thursday, June 19, 2008 21:11 >>>>>> To: MEAD team >>>>>> Subject: Re: [Mpls-interop] next MEAD team meeting >>>>>> >>>>>> >>>>>> >>>>>> Colleagues, >>>>>> >>>>>> >>>>>> >>>>>> I was thinking for the requirements we should include a >>>> sentence in >>>>>> the >>>>>> >>>>>> abstract to scope the MPLS-TP work as being part of a >>>> joint ITU-IETF >>>>>> >>>>>> effort. Not all readers (now and future) will be aware of >>>> why this is >>>>>> >>>>>> being done. In ccamp, we had done this for our ASON work. Maybe a >>>>>> >>>>>> similar sentence will be needed in the other documents? >>>> Should we have >>>>> >>>>>> a >>>>>> >>>>>> common sentence? >>>>>> >>>>>> >>>>>> >>>>>> How about for the abstract: >>>>>> >>>>>> This document summarizes the ITU-T requirements for >>>> MPLS-TP in order >>>>>> to >>>>>> >>>>>> support capabilities and functionalities as needed by the >>>> ITU-T. It >>>>>> does >>>>>> >>>>>> not address IETF protocol applicability or capabilities. >>>> This document >>>>>> >>>>>> is a product of a joint ITU-IETF effort. >>>>>> >>>>>> >>>>>> >>>>>> Deborah >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> >>>>>> From: mpls-interop-bounces@ietf.org >>>>>> >>>>>> [mailto:mpls-interop-bounces@ietf.org] On Behalf Of Ben >>>> Niven-Jenkins >>>>>> >>>>>> Sent: Thursday, June 19, 2008 1:21 PM >>>>>> >>>>>> To: Loa Andersson; MEAD team >>>>>> >>>>>> Subject: Re: [Mpls-interop] next MEAD team meeting >>>>>> >>>>>> >>>>>> >>>>>> Colleagues, >>>>>> >>>>>> >>>>>> >>>>>> FYI see attached for the latest draft of the MPLS-TP requirements >>>>> draft. >>>>>> >>>>>> >>>>>> Ben >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 19/06/2008 16:00, "Loa Andersson" wrote: >>>>>> >>>>>> >>>>>> >>>>>>> All, >>>>>> >>>>>>> the MEAD team will have the next meeting on Tuesday 24, at 6pm >>>>>>> i.e. 12am east coast and 9am California. >>>>>> >>>>>>> Again I plan the meeting to last an hour, and focus >> will be on the >>>>>>> document status. >>>>>> >>>>>>> Stewart will send out dial in details as usual. >>>>>> >>>>>>> /Loa >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> >>>>>> Mpls-interop mailing list >>>>>> >>>>>> Mpls-interop@ietf.org >>>>>> >>>>>> https://www.ietf.org/mailman/listinfo/mpls-interop >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> >> --------------------------------------------------------------------- >>>> - >>>>>> -- >>>>>> >>>>>> _______________________________________________ >>>>>> Mpls-interop mailing list >>>>>> Mpls-interop@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mpls-interop >>>>> >>>>> >>>>> -- >>>>> Loa Andersson >>>>> >>>>> Principal Networking Architect >>>>> Acreo AB phone: +46 8 632 77 14 >>>>> Isafjordsgatan 22 mobile: +46 739 81 21 64 >>>>> Kista, Sweden email: loa.andersson@acreo.se >>>>> loa@pi.nu >>>> >>>> >>>> -- >>>> Loa Andersson >>>> >>>> Principal Networking Architect >>>> Acreo AB phone: +46 8 632 77 14 >>>> Isafjordsgatan 22 mobile: +46 739 81 21 64 >>>> Kista, Sweden email: loa.andersson@acreo.se >>>> loa@pi.nu >>>> _______________________________________________ >>>> Mpls-interop mailing list >>>> Mpls-interop@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls-interop >>>> >>> >>> _______________________________________________ >>> Mpls-interop mailing list >>> Mpls-interop@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls-interop >> >> _______________________________________________ >> Mpls-interop mailing list >> Mpls-interop@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-interop >> _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop From mpls-interop-bounces@ietf.org Wed Jun 25 03:24:06 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F9443A6A2C; Wed, 25 Jun 2008 03:24:06 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 830E73A6A50 for ; Wed, 25 Jun 2008 03:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-pKGifoOLHa for ; Wed, 25 Jun 2008 03:24:03 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 5AF813A6A2C for ; Wed, 25 Jun 2008 03:24:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,701,1204498800"; d="ics'?eml'208?scan'208,208,217";a="12618194" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 25 Jun 2008 12:24:02 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5PAO2js016033; Wed, 25 Jun 2008 12:24:02 +0200 Received: from stewart-bryants-computer.local (dhcp-10-61-98-218.cisco.com [10.61.98.218]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5PAO1Th023626; Wed, 25 Jun 2008 10:24:01 GMT Message-ID: <48621CC4.60609@cisco.com> Date: Wed, 25 Jun 2008 11:24:04 +0100 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: mpls-interop@ietf.org Content-Type: multipart/mixed; boundary="------------050502000709050503080102" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=19713; t=1214389442; x=1215253442; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20[Fwd=3A=20Meeting=3A=20Bryant=20{Meeting=20ID=3 A=20310271828}] |Sender:=20; bh=kcQSdSS1Stl2n3jVUj7lcdKjBo819f1HcpZx5Kn9Kr0=; b=AZBsFxtNl3Rb+1dRfI+H/aJLe5azecynL/hs8uYmvuU8kS8vFKK5dxQ8H+ 5fkHO5hTvixlugIOmF2BZktGp1SXsQi3z+LNTJ5qCk/BAmxVonf3XCQT8BeQ yTHwZQUZKu; Authentication-Results: ams-dkim-2; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [Mpls-interop] [Fwd: Meeting: Bryant {Meeting ID: 310271828}] X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org This is a multi-part message in MIME format. --------------050502000709050503080102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Regular meeting dialing as requested last night. Stewart --------------050502000709050503080102 Content-Type: message/rfc822; name="Meeting: Bryant {Meeting ID: 310271828}.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Meeting: Bryant {Meeting ID: 310271828}.eml" X-Account-Key: account3 X-Mozilla-Keys: Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m5PADYK16812 for ; Wed, 25 Jun 2008 11:13:34 +0100 (BST) X-IronPort-AV: E=Sophos;i="4.27,701,1204498800"; d="ics'?scan'208,217";a="12616803" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 25 Jun 2008 12:13:34 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5PADYkl012226 for ; Wed, 25 Jun 2008 12:13:34 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5PADY8F019143 for ; Wed, 25 Jun 2008 10:13:34 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jun 2008 12:13:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:calendarmessage MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8D6AC.1FECE165" Subject: Meeting: Bryant {Meeting ID: 310271828} Date: Wed, 25 Jun 2008 12:13:33 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Index: AcjWrB/sp5jZ8wNUQyy0mY2xlUPmsg== From: "mp-ams-c1-olk.svc" To: "Stewart Bryant (stbryant)" X-OriginalArrivalTime: 25 Jun 2008 10:13:33.0955 (UTC) FILETIME=[1FFE7D30:01C8D6AC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=16641; t=1214388814; x=1215252814; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mp-ams-c1-olk.svc@cisco.com; z=From:=20=22mp-ams-c1-olk.svc=22=20 |Subject:=20Meeting=3A=20Bryant=20{Meeting=20ID=3A=20310271 828} |Sender:=20; bh=iKSOWoxyU3XHwGOsshWMFM041xeqvU6gVSDXowghxRA=; b=q85URTx1f2Vsw2+VTaeBB7p151/WcueYwpr2hJjAiNaPI1LnvctOa9T8dW 99OWC/9nx8hhsi5cpU3iVn4mzfaHG2AM3G9rmJ6PbGV2dc/1M3MNGej0rAZO NLsubCHTvi; Authentication-Results: ams-dkim-2; header.From=mp-ams-c1-olk.svc@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); This is a multi-part message in MIME format. ------_=_NextPart_001_01C8D6AC.1FECE165 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stewart Bryant has invited you to a Cisco Unified MeetingPlace = Conference Date/Time: July 08, 2008 at 05:00PM Europe/London Length: 60 Frequency: once Meeting ID: 310271828 Meeting Password: =20 Global Access Numbers: http://cisco.com/en/US/about/doing_business/conferencing/index.html San Jose, CA: +408.525.6800 RTP: +919.392.3330 =20 US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 India: +91.80.4103.3979 Germany: +49.619.6773.9002 Japan: +81.3.5763.9394 China: +86.10.8515.5666 TO ATTEND A WEB AND VOICE CONFERENCE: CISCO INTRANET ATTENDEES Join the Web & Voice Conference* 1. Go to http://meetingplaceinternal.cisco.com/join.asp?310271828 2. Enter your CEC User ID & Password then click OK - Accept any security warnings you receive and wait for the Meeting Room = to initialize** 3. Click on CONNECT from the Meeting Room to join the Voice Conference = portion of the meeting EXTERNAL ATTENDEES - Outside the Cisco Intranet Join the Web & Voice Conference* 1. Go to http://meetingplace.cisco.com/join.asp?310271828 2. Fill in the My Name is field then click Attend Meeting - If you have a CEC User ID, click on the Cisco icon - Accept any security warnings you receive and wait for the Meeting Room = to initialize** 3. Click on CONNECT from the Meeting Room to join the Voice Conference = portion of the meeting - Note: Guest users will see a link to the Global Access Numbers. *If this is your first time attending a Web Conference, disable any = pop-up blockers and visit = http://meetingplace.cisco.com/mpweb/scripts/browsertestupper.asp to test = your web browser for compatibility with the Web Conference. **The meeting will not start until the Host of the meeting arrives - if = you'd like to start the meeting with your Profile, please review the = steps below to attend a Voice Only Conference as a Guest then follow the = system prompts. TO ATTEND A RESERVATIONLESS VOICE ONLY CONFERENCE AS THE HOST 1. Dial into Cisco Unified MeetingPlace (view the Access Numbers and = link above) 2. Press 1 to attend the meeting 3. Enter the Meeting ID 310271828 followed by # key 4. Follow the prompts to record your name and enter the waiting room 5. Press 2 then enter your Profile Password to initiate your meeting AS A GUEST 1. Follow steps 1-4 above to access the meeting 2. You will be placed in a waiting room until the Host initiates the = meeting SUPPORT Information about this Conference: Contact Stewart Bryant, 442088248828 Cisco IT Support Center: Attend the Voice Conference and then press #0 = on your phone keypad ------_=_NextPart_001_01C8D6AC.1FECE165 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Meeting: Bryant {Meeting ID: 310271828}

Stewart Bryant has invited you = to a Cisco Unified MeetingPlace Conference

Date/Time:           &n= bsp;   July 08, 2008 at 05:00PM Europe/London
Length:           &n= bsp;      60
Frequency:           &n= bsp;   once
Meeting ID:           &n= bsp;  310271828
Meeting = Password:       

Global Access = Numbers:
http://cisco.com/en/US/about/doing_business/conferencing/index.html

    San Jose, CA: +408.525.6800    = RTP:           &n= bsp;  +919.392.3330     =20
    = US/Canada:  = +1.866.432.9903    United Kingdom:   +44.20.8824.0117
    = India:      = +91.80.4103.3979   Germany:          = +49.619.6773.9002
    = Japan:      = +81.3.5763.9394    China:            = +86.10.8515.5666

TO ATTEND A WEB AND VOICE = CONFERENCE:

CISCO = INTRANET ATTENDEES
Join the Web & Voice = Conference*
1. Go to http://= meetingplaceinternal.cisco.com/join.asp?310271828
2. Enter your CEC User ID & Password then click OK
- Accept any security warnings = you receive and wait for the Meeting Room to initialize**
3. Click on CONNECT from the Meeting Room to join the Voice Conference = portion of the meeting

EXTERNAL = ATTENDEES - Outside the Cisco Intranet
Join the Web & Voice = Conference*
1. Go to http://meetingp= lace.cisco.com/join.asp?310271828
2. Fill in the My Name is field then click Attend Meeting
- If you have a CEC User ID, = click on the Cisco icon
- Accept any security warnings = you receive and wait for the Meeting Room to initialize**
3. Click on CONNECT from the Meeting Room to join the Voice Conference = portion of the meeting
- Note: Guest users will see a link to the Global Access Numbers.

*If this is your = first time attending a Web Conference, disable any pop-up blockers and = visit http://meetingplace.cisco.com/mpweb/scripts/browsertestupper.asp to test your web browser for = compatibility with the Web Conference.

**The meeting will = not start until the Host of the meeting arrives - if you'd like to start = the meeting with your Profile, please review the steps below to attend a = Voice Only Conference as a Guest then follow the system = prompts.

TO ATTEND A RESERVATIONLESS VOICE = ONLY CONFERENCE

AS THE = HOST
1. Dial into Cisco Unified = MeetingPlace (view the Access Numbers and link above)
2. Press 1 to attend the meeting
3. Enter the Meeting = ID 310271828 followed = by # key
4. Follow the prompts to record = your name and enter the waiting room
5. Press 2 then enter your Profile Password to = initiate your meeting

AS A = GUEST
1. Follow steps 1-4 above to = access the meeting
2. You will be placed in a = waiting room until the Host initiates the meeting

SUPPORT
Information about this = Conference: Contact = Stewart Bryant, 442088248828
Cisco IT Support = Center: Attend the Voice = Conference and then press #0 on your phone keypad

------_=_NextPart_001_01C8D6AC.1FECE165 Content-class: urn:content-classes:calendarmessage Content-Type: text/calendar; method=REQUEST; name="meeting.ics" Content-Transfer-Encoding: 8bit BEGIN:VCALENDAR METHOD:REQUEST PRODID:Microsoft CDO for Microsoft Exchange VERSION:2.0 BEGIN:VEVENT DTSTAMP:20080625T101333Z DTSTART:20080708T160000Z SUMMARY:Meeting: Bryant {Meeting ID: 310271828} UID:040000008200E00074C5B7101A82E0080000000020E0F31DACD6C801000000000000000 0100000004B299EE27F3E0948B8ABCCEB4DE8919A ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Stewart B ryant (stbryant)":MAILTO:stbryant@cisco.com ORGANIZER;CN="mp-ams-c1-olk.svc":MAILTO:mp-ams-c1-olk.svc@cisco.com LOCATION: DTEND:20080708T170000Z DESCRIPTION:Stewart Bryant has invited you to a Cisco Unified MeetingPlace Conference\N\NDate/Time: July 08\, 2008 at 05:00PM Europe/Lo ndon\NLength: 60\NFrequency: once\NMeeting ID: 310271828\NMeeting Password: \N\NGlobal Access Num bers:\Nhttp://cisco.com/en/US/about/doing_business/conferencing/index.html \N\N San Jose\, CA: +408.525.6800 RTP: +919.392.3330 \N US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 \N India: +91.80.4103.3979 Germany: +49.619.6773.9002\N Japan: +81.3.5763.9394 China: +86.10.8515.5666\N\NT O ATTEND A WEB AND VOICE CONFERENCE:\N\NCISCO INTRANET ATTENDEES\NJoin the Web & Voice Conference*\N1. Go to http://meetingplaceinternal.cisco.com/j oin.asp?310271828\N2. Enter your CEC User ID & Password then click OK\N- A ccept any security warnings you receive and wait for the Meeting Room to i nitialize**\N3. Click on CONNECT from the Meeting Room to join the Voice C onference portion of the meeting\N\NEXTERNAL ATTENDEES - Outside the Cisco Intranet\NJoin the Web & Voice Conference*\N1. Go to http://meetingplace. cisco.com/join.asp?310271828\N2. Fill in the My Name is field then click A ttend Meeting\N- If you have a CEC User ID\, click on the Cisco icon\N- Ac cept any security warnings you receive and wait for the Meeting Room to in itialize**\N3. Click on CONNECT from the Meeting Room to join the Voice Co nference portion of the meeting\N- Note: Guest users will see a link to th e Global Access Numbers.\N\N*If this is your first time attending a Web Co nference\, disable any pop-up blockers and visit http://meetingplace.cisco .com/mpweb/scripts/browsertestupper.asp to test your web browser for compa tibility with the Web Conference.\N**The meeting will not start until the Host of the meeting arrives - if you'd like to start the meeting with your Profile\, please review the steps below to attend a Voice Only Conference as a Guest then follow the system prompts.\N\NTO ATTEND A RESERVATIONLESS VOICE ONLY CONFERENCE\N\NAS THE HOST\N1. Dial into Cisco Unified MeetingP lace (view the Access Numbers and link above)\N2. Press 1 to attend the me eting\N3. Enter the Meeting ID 310271828 followed by # key\N4. Follow the prompts to record your name and enter the waiting room\N5. Press 2 then en ter your Profile Password to initiate your meeting\N\NAS A GUEST\N1. Follo w steps 1-4 above to access the meeting\N2. You will be placed in a waitin g room until the Host initiates the meeting\N\NSUPPORT\NInformation about this Conference: Contact Stewart Bryant\, 442088248828\NCisco IT Support C enter: Attend the Voice Conference and then press #0 on your phone keypad\ N\N SEQUENCE:0 PRIORITY:5 CLASS: CREATED:20080625T101333Z LAST-MODIFIED:20080625T101333Z STATUS:CONFIRMED TRANSP:OPAQUE X-MICROSOFT-CDO-BUSYSTATUS:BUSY X-MICROSOFT-CDO-INSTTYPE:0 X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY X-MICROSOFT-CDO-ALLDAYEVENT:FALSE X-MICROSOFT-CDO-IMPORTANCE:1 X-MICROSOFT-CDO-OWNERAPPTID:-1 X-MICROSOFT-CDO-ATTENDEE-CRITICAL-CHANGE:20080625T101333Z X-MICROSOFT-CDO-OWNER-CRITICAL-CHANGE:20080625T101333Z BEGIN:VALARM ACTION:DISPLAY DESCRIPTION:REMINDER TRIGGER;RELATED=START:-PT00H15M00S END:VALARM END:VEVENT END:VCALENDAR ------_=_NextPart_001_01C8D6AC.1FECE165-- --------------050502000709050503080102 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop --------------050502000709050503080102-- From mpls-interop-bounces@ietf.org Wed Jun 25 08:06:21 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9D073A6911; Wed, 25 Jun 2008 08:06:21 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C49983A6A1E for ; Wed, 25 Jun 2008 08:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.54 X-Spam-Level: X-Spam-Status: No, score=-6.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1PKT1R9pja5 for ; Wed, 25 Jun 2008 08:06:16 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id A90033A69FA for ; Wed, 25 Jun 2008 08:06:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,703,1204498800"; d="scan'208";a="12657207" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 25 Jun 2008 17:06:14 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5PF6EZV017125; Wed, 25 Jun 2008 17:06:14 +0200 Received: from stewart-bryants-computer.local (dhcp-10-61-98-218.cisco.com [10.61.98.218]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5PF6E6e001990; Wed, 25 Jun 2008 15:06:14 GMT Message-ID: <48625EE9.8030705@cisco.com> Date: Wed, 25 Jun 2008 16:06:17 +0100 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: mpls-interop@ietf.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=663; t=1214406374; x=1215270374; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Survivability=20co-ordination |Sender:=20; bh=vvvNnbyulcLNwfQEddsZCnnyfT9SlznTncROP7c4Wu4=; b=CFC5INVzK/7nh6zOlaYzt6q82E6NgHDwzlA8/KvILU8XnpqnabZ3RD5sOD JbWVswZoopwn3GxKxOeb1KOKmQSBH/ul1FvKbqvAHni7osnH7hrxBruCVCyx c7kUPcgxmU; Authentication-Results: ams-dkim-2; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [Mpls-interop] Survivability co-ordination X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org On the MEAD team conf call we have discussed the need to co-ordinate between the editors working on survivability. I have therefore set up an extra MEAD team call for next tuesday (1st) 5pm UK same dialin details as usual. Please can those working on survivability indicate whether they can make this call, and if we are not quorate we will need to reschedule. Those team members not working on survivability are of course welcome to listen in. A very useful starting point would be the survivability framework and it would be good if the authors were able to share with the rest of us what their initial thoughts are. Regards Stewart _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop From mpls-interop-bounces@ietf.org Wed Jun 25 18:49:08 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32C9A3A68C3; Wed, 25 Jun 2008 18:49:08 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F0CD3A692C for ; Wed, 25 Jun 2008 18:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[AWL=0.950, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6Vkw0gPK-wM for ; Wed, 25 Jun 2008 18:49:06 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id 3F80C3A68C3 for ; Wed, 25 Jun 2008 18:49:03 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m5Q1mvrQ013516; Thu, 26 Jun 2008 02:48:57 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m5Q1mtVX013506; Thu, 26 Jun 2008 02:48:56 +0100 Message-ID: <00f101c8d72e$cb42cfc0$0200a8c0@your029b8cecfe> From: "Adrian Farrel" To: , References: <48625EE9.8030705@cisco.com> Date: Thu, 26 Jun 2008 02:48:42 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [Mpls-interop] Survivability co-ordination X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org > On the MEAD team conf call we have discussed the need to > co-ordinate between the editors working on survivability. Without having been on this call, I don't know what the coordination issues are. It seems to me that the requirements for survivability have been very poorly expressed (mainly I see statements of solution rather than requirements), so maybe it is these requirements that need to be coordinated. Nurit and I are working on the survivability framework to a schedule that we gave the team. Is there a need to change this schedule? > I have therefore set up an extra MEAD team call for next > tuesday (1st) 5pm UK same dialin details as usual. > > Please can those working on survivability indicate whether > they can make this call, and if we are not quorate we will > need to reschedule. Regret I am unable to make this call. To some extent this is because I have rather a lot of other things to do. To some extent it is because this is charity work and so is very low priority. > Those team members not working on survivability are of course > welcome to listen in. > > A very useful starting point would be the survivability framework > and it would be good if the authors were able to share with the > rest of us what their initial thoughts are. Repeat of a question. We published our schedule: is there a need to change this schedule? Cheers, Adrian _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop From mpls-interop-bounces@ietf.org Fri Jun 27 01:32:52 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60EA13A6784; Fri, 27 Jun 2008 01:32:52 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A36533A67B6 for ; Fri, 27 Jun 2008 01:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[AWL=0.951, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w49tt0hq9cQJ for ; Fri, 27 Jun 2008 01:32:51 -0700 (PDT) Received: from neo.viciousnest.net (neo.viciousnest.net [192.71.80.124]) by core3.amsl.com (Postfix) with ESMTP id CF6A83A6784 for ; Fri, 27 Jun 2008 01:32:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by neo.viciousnest.net (Postfix) with ESMTP id 8BF051262 for ; Fri, 27 Jun 2008 10:32:50 +0200 (CEST) Received: from neo.viciousnest.net ([127.0.0.1]) by localhost (neo [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32533-02 for ; Fri, 27 Jun 2008 10:32:46 +0200 (CEST) Received: from [127.0.0.1] (pat.acreo.se [217.151.195.214]) by neo.viciousnest.net (Postfix) with ESMTP id 0B9931254 for ; Fri, 27 Jun 2008 10:32:40 +0200 (CEST) Message-ID: <4864A598.1060401@pi.nu> Date: Fri, 27 Jun 2008 10:32:24 +0200 From: Loa Andersson User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: MEAD team X-Virus-Scanned: by amavisd-new at viciousnest.net Subject: [Mpls-interop] test X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org sorry, but I've ha problem sending to list, this is a test please ignore /Loa -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.nu _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop From mpls-interop-bounces@ietf.org Fri Jun 27 04:09:05 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 910753A6B50; Fri, 27 Jun 2008 04:09:05 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39D093A6B50 for ; Fri, 27 Jun 2008 04:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.43 X-Spam-Level: X-Spam-Status: No, score=-1.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPTZSaVJQAFT for ; Fri, 27 Jun 2008 04:09:03 -0700 (PDT) Received: from viefep25-int.chello.at (viefep25-int.chello.at [62.179.121.45]) by core3.amsl.com (Postfix) with ESMTP id C10063A6809 for ; Fri, 27 Jun 2008 04:08:59 -0700 (PDT) Received: from edge02.upc.biz ([192.168.13.237]) by viefep25-int.chello.at (InterMail vM.7.08.02.00 201-2186-121-20061213) with ESMTP id <20080627110903.XHAS27908.viefep25-int.chello.at@edge02.upc.biz> for ; Fri, 27 Jun 2008 13:09:03 +0200 Received: from [192.168.17.2] ([24.132.228.153]) by edge02.upc.biz with edge02 id iz8y1Z00J3KDBhC01z92ZN; Fri, 27 Jun 2008 13:09:02 +0200 X-SourceIP: 24.132.228.153 Message-ID: <4864CA49.7090503@chello.nl> Date: Fri, 27 Jun 2008 13:08:57 +0200 From: Huub van Helvoort User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: MEAD team References: <4864A598.1060401@pi.nu> <4864A860.4000407@huawei.com> In-Reply-To: <4864A860.4000407@huawei.com> Subject: Re: [Mpls-interop] test2 X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: hhelvoort@chello.nl List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org I have a similar problem, Huub. > sorry, but I've had problem sending to list, this is a test please ignore -- ================================================================ http://www.van-helvoort.eu/ ================================================================ Always remember that you are unique...just like everyone else... _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop From mpls-interop-bounces@ietf.org Fri Jun 27 04:13:48 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 603AC3A6B60; Fri, 27 Jun 2008 04:13:48 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B91633A6B60 for ; Fri, 27 Jun 2008 04:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.124 X-Spam-Level: X-Spam-Status: No, score=-2.124 tagged_above=-999 required=5 tests=[AWL=0.475, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2VGH3I2aMZQ for ; Fri, 27 Jun 2008 04:13:46 -0700 (PDT) Received: from neo.viciousnest.net (neo.viciousnest.net [192.71.80.124]) by core3.amsl.com (Postfix) with ESMTP id DAED53A680F for ; Fri, 27 Jun 2008 04:13:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by neo.viciousnest.net (Postfix) with ESMTP id 992D31266; Fri, 27 Jun 2008 13:13:48 +0200 (CEST) Received: from neo.viciousnest.net ([127.0.0.1]) by localhost (neo [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32533-05; Fri, 27 Jun 2008 13:13:46 +0200 (CEST) Received: from [127.0.0.1] (pat.acreo.se [217.151.195.214]) by neo.viciousnest.net (Postfix) with ESMTP id 1F5481261; Fri, 27 Jun 2008 13:13:46 +0200 (CEST) Message-ID: <4864CB5A.1040902@pi.nu> Date: Fri, 27 Jun 2008 13:13:30 +0200 From: Loa Andersson User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: hhelvoort@chello.nl References: <4864A598.1060401@pi.nu> <4864A860.4000407@huawei.com> <4864CA49.7090503@chello.nl> In-Reply-To: <4864CA49.7090503@chello.nl> X-Virus-Scanned: by amavisd-new at viciousnest.net Cc: MEAD team Subject: Re: [Mpls-interop] test2 X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org All, I see some indications that people are working with the IETF mail list, but don't have detailed in, but since this is getting through (as did Huubs and my earlier mail) I guess that things now are OK. If you sent mails to the list and not seen them coming through it might be a good idea to resend. /Loa Huub van Helvoort wrote: > I have a similar problem, Huub. > >> sorry, but I've had problem sending to list, this is a test please ignore > -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.nu _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop From mpls-interop-bounces@ietf.org Sat Jun 28 04:10:53 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99F413A6861; Sat, 28 Jun 2008 04:10:53 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 132873A67AA for ; Sat, 28 Jun 2008 04:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kY2VCs7nuv1T for ; Sat, 28 Jun 2008 04:10:50 -0700 (PDT) Received: from smail6.alcatel.fr (colt-na5.alcatel.fr [62.23.212.5]) by core3.amsl.com (Postfix) with ESMTP id 93D073A6861 for ; Sat, 28 Jun 2008 04:10:48 -0700 (PDT) Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.ad2.ad.alcatel.com [155.132.6.76]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m5SBAkAs027650; Sat, 28 Jun 2008 13:10:46 +0200 Received: from [159.217.32.6] ([159.217.32.6]) by FRVELSBHS04.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Sat, 28 Jun 2008 13:10:46 +0200 Message-ID: <48661C39.10409@alcatel-lucent.fr> Date: Sat, 28 Jun 2008 13:10:49 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent Bell-Labs User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: mpls-interop@ietf.org Content-Type: multipart/mixed; boundary="------------020506030505070000020406" X-OriginalArrivalTime: 28 Jun 2008 11:10:46.0154 (UTC) FILETIME=[9CFBBEA0:01C8D90F] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Subject: [Mpls-interop] GAL draft X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org This is a multi-part message in MIME format. --------------020506030505070000020406 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit all, please find attached the submitted GAL draft. martin --------------020506030505070000020406 Content-Type: text/plain; name="draft-vigoureux-mpls-tp-gal-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-vigoureux-mpls-tp-gal-00.txt" MPLS Working Group M. Vigoureux (Editor) Internet Draft Alcatel-Lucent Intended status: Standard Track Expires: December 2008 G. Swallow (Editor) Cisco Systems, Inc. R. Aggarwal (Editor) Juniper Networks June 26, 2008 Assignment of the Generic Associated Channel Header Label (GAL) draft-vigoureux-mpls-tp-gal-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 This Internet-Draft will expire on December 26, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Vigoureux et al. Expires December 26, 2008 [Page 1] Internet-Draft Generic Associated Channel Header Label June 2008 Abstract This document describes the assignment of one of the reserved label values, defined in RFC 3032 [3], to the 'Generic-ACH Label (GAL)', that is used as generic exception mechanism, for example by MPLS Transport Profile (MPLS-TP) for Operations and Management (OAM) functions. Conventions used in this document 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 RFC 2119 [1]. Table of Contents 1. Introduction...................................................2 2. Generic Exception Mechanism....................................3 3. Relationship with RFC 3429.....................................3 4. Relationship with Existing MPLS OAM Alert Mechanisms...........4 5. Applicability and Usages.......................................4 5.1. GAL Processing............................................5 5.1.1. Section..............................................5 5.1.2. Label Switched Paths.................................6 5.1.3. LSP Tandem Connection Monitoring Entity..............7 5.2. Considerations on Penultimate Hop Popping.................7 5.3. Compatibility.............................................8 6. Security Considerations........................................8 7. IANA Considerations............................................8 8. Acknowledgments................................................8 9. References.....................................................8 9.1. Normative References......................................8 9.2. Informative References....................................9 Authors' Addresses................................................9 Contributing Authors' Addresses..................................10 Intellectual Property Statement..................................10 Disclaimer of Validity...........................................11 1. Introduction This document describes the assignment of one of the reserved label values, defined in RFC 3032 [3], to the 'Generic-ACH Label (GAL)', that is used as generic exception mechanism, for example by MPLS Transport Profile (MPLS-TP) for Operations and Management (OAM) functions. Vigoureux et al. Expires December 26, 2008 [Page 2] Internet-Draft Generic Associated Channel Header Label June 2008 2. Generic Exception Mechanism MPLS-TP requires [12] a mechanism to differentiate specific packets (e.g. OAM) from others, such as normal user-plane ones. This document proposes that a label be used and calls this special label the 'Generic-ACH Label (GAL)'. One of the reserved label values defined in RFC 3032 [3] is assigned to the 'Generic-ACH Label (GAL)'. The value of the label is to be allocated by IANA; this document suggests the value 13. The 'Generic-ACH Label (GAL)' is a generic exception mechanism used firstly to differentiate specific packets (e.g. OAM) from others, such as normal user-plane ones, and secondly, to indicate that the Generic Associated Channel Header (GE-ACH) [10] appears immediately after the bottom of the label stack. The 'Generic-ACH Label (GAL)' MUST only be used if those two purposes are fulfilled simultaneously. Note that, in this document, MPLS-TP OAM (functions, packets) should be understood in the broad sense, that is, as a set of mechanisms including Automatic Protection Switching (APS), Signalling Control Channel (SCC) and Management Control Channel (MCC). Further, while transport applications are expected to be the first to use the 'Generic-ACH Label (GAL)', the use of this label is by no means restricted to MPLS-TP. 3. Relationship with RFC 3429 RFC 3429 [11] describes the assignment of one of the reserved label values, defined in RFC 3032 [3], to the 'OAM Alert Label' that is used by user-plane MPLS OAM functions for the identification of MPLS OAM packets. The value of 14 is used for that purpose. This document and RFC 3429 [11], thus describe the assignment of reserved label values for similar purposes. The rationales for the assignment of a new reserved label can be summarized as follows: Vigoureux et al. Expires December 26, 2008 [Page 3] Internet-Draft Generic Associated Channel Header Label June 2008 o Unlike the mechanisms described and referenced in RFC 3429 [11], MPLS-TP OAM packets will not reside immediately after the 'Generic-ACH Label (GAL)' but behind the Generic Associated Channel Header (GE-ACH) [10] which, itself, resides immediately after the bottom of the label stack when the 'Generic-ACH Label (GAL)' appears in this label stack. This will ensure that MPLS-TP OAM complies with RFC 4928 [7]. o The set of OAM functions potentially operated in the context of MPLS-TP is wider than the set of OAM functions referenced in RFC 3429 [11]. o It has been reported that there are existing implementations and running deployments using the 'OAM Alert Label' as described in RFC 3429 [11]. It is therefore not possible to modify the 'OAM Alert Label' allocation, purpose or usage. Nevertheless, it is RECOMMENDED by this document that no further OAM extensions based on 'OAM Alert Label' (Label 14) usage be specified or developed. 4. Relationship with Existing MPLS OAM Alert Mechanisms RFC 4379 [6] and BFD for MPLS LSPs [8] have defined alert mechanisms that enable a MPLS LSR to identify and process MPLS OAM packets when the OAM packets are encapsulated in an IP header. These alert mechanisms are based on TTL expiration and/or use an IP destination address in the range 127/8. These alert mechanisms SHOULD preferably be used in non MPLS-TP environments. The mechanism defined in this document MAY also be used. 5. Applicability and Usages The 'Generic-ACH Label (GAL)' MUST only be used with Label Switched Paths (LSPs), with their associated Tandem Connection Monitoring Entities (see [12] for definitions of TCMEs) and with MPLS Sections. A MPLS Section is a network segment between two LSRs that are immediately adjacent at the MPLS layer. The 'Generic-ACH Label (GAL)' applies to both P2P and P2MP LSPs, unless otherwise stated. In MPLS-TP, the 'Generic-ACH Label (GAL)' MUST always be at the bottom of the label stack (i.e. S bit set to 1). However, in other MPLS environments, this document places no restrictions on where the 'Generic-ACH Label (GAL)' may appear within the label stack. Vigoureux et al. Expires December 26, 2008 [Page 4] Internet-Draft Generic Associated Channel Header Label June 2008 The 'Generic-ACH Label (GAL)' MUST NOT be used with Pseudowires (PWs) neither with their associated Tandem Connection Monitoring Entities. The 'Generic-ACH Label (GAL)' MUST NOT appear in the label stack when transporting normal user-plane packets. Furthermore, the 'Generic-ACH Label (GAL)' MUST only appear once in the label stack. 5.1. GAL Processing The Class of Service (CoS) field (former EXP field) of the 'Generic- ACH Label (GAL)' follows the definition and processing rules specified and referenced in [9]. The Time To Live (TTL) field of the 'Generic-ACH Label (GAL)' follows the definition and processing rules specified in [4]. For detailed information on the Generic-ACH (GE-ACH) mentioned in the following sub-sections, please see [10]. 5.1.1. Section The following figure (Figure 1) depicts two MPLS LSRs immediately adjacent at the MPLS layer. +---+ +---+ | A |-------------| Z | +---+ +---+ Figure 1 : MPLS-TP OAM over a MPLS Section With regards to the MPLS Section, both LERs are Maintenance End Points (see [12] for definitions of MEPs). The following figure (Figure 2) depicts the format of a labelled MPLS-TP OAM packet when used for MPLS Section OAM. Vigoureux et al. Expires December 26, 2008 [Page 5] Internet-Draft Generic Associated Channel Header Label June 2008 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GAL | CoS |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Generic-ACH | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . MPLS-TP OAM packet . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 : Labelled MPLS-TP OAM packet for MPLS Section OAM To perform MPLS-TP OAM functions on the MPLS Section, the head-end LSR (A) of the MPLS Section generates a MPLS-TP OAM packet with a GE- ACH to which it prepends a 'Generic-ACH Label (GAL)'. o The TTL field of the 'Generic-ACH Label (GAL)' SHOULD be set to 1. o The S bit of the 'Generic-ACH Label (GAL)' MUST be set to 1. The MPLS-TP OAM packet, the GE-ACH or the 'Generic-ACH Label (GAL)' SHOULD NOT be modified towards the tail-end LSR (Z). Upon reception of the labelled packet, the tail-end LSR (Z), after having checked the 'Generic-ACH Label (GAL)' fields, SHOULD pass the whole packet to the appropriate processing entity. 5.1.2. Label Switched Paths The following figure (Figure 3) depicts four LSRs. A LSP is established from A to D and switched in B and C. +---+ +---+ +---+ +---+ | A |-------------| B |-------------| C |-------------| D | +---+ +---+ +---+ +---+ Figure 3 : MPLS-TP OAM over a LSP With regards to the considered LSP, LERs A and D are MEPs. Furthermore, LSRs B and C could be Maintenance Intermediate Points (see [12] for definitions of MEPs and MIPs). The following figure (Figure 4) depicts the format of a labelled MPLS-TP OAM packet when used for LSP OAM. Vigoureux et al. Expires December 26, 2008 [Page 6] Internet-Draft Generic Associated Channel Header Label June 2008 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP Label | CoS |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GAL | CoS |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Generic-ACH | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . MPLS-TP OAM packet . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 : Labelled MPLS-TP OAM packet for LSP OAM Note that, in the general case, the considered LSP MAY be tunnelled (e.g. in a MPLS Tunnel existing between B and C), and as such, other labels MAY be present above in the label stack. To perform MPLS-TP OAM functions on the LSP, the head-end LSR (A) of the LSP generates a MPLS-TP OAM packet with a GE-ACH to which it prepends a 'Generic-ACH Label (GAL)' to which it prepends the label of the LSP. o The TTL field of the 'Generic-ACH Label (GAL)' SHOULD be set to 1. o The S bit of the 'Generic-ACH Label (GAL)' SHOULD be set to 1, in MPLS-TP. The MPLS-TP OAM packet, the GE-ACH or the 'Generic-ACH Label (GAL)' SHOULD NOT be modified towards the targeted destination. Upon reception of the labelled packet, the targeted destination, after having checked both the LSP label and 'Generic-ACH Label (GAL)' fields, SHOULD pass the whole packet to the appropriate processing entity. 5.1.3. LSP Tandem Connection Monitoring Entity To be covered in a next version of this document. 5.2. Considerations on Penultimate Hop Popping OAM operations require context awareness. The label, immediately above the 'Generic-ACH Label (GAL)' in the label stack, provides this context. Additionally, a requirement of MPLS-TP OAM is that user- plane and OAM packets share the same fate [12]. As such, when Vigoureux et al. Expires December 26, 2008 [Page 7] Internet-Draft Generic Associated Channel Header Label June 2008 operating MPLS-TP OAM, Penultimate Hop Popping (PHP) SHOULD be disabled by default for the label immediately above the 'Generic-ACH Label (GAL)' in the label stack, otherwise neither all MPLS-TP OAM requirements [12] nor all MPLS-TP OAM functions can be satisfied. In case PHP is enabled, the context, normally provided by the label immediately above the 'Generic-ACH Label (GAL)' in the label stack, SHALL be provided by other means. Moreover, PHP MUST NOT be applied to the 'Generic-ACH Label (GAL)' itself. 5.3. Compatibility LERs and LSRs not capable of processing the 'Generic-ACH Label (GAL)' SHOULD silently discard the packet. 6. Security Considerations This document does not raise any security issue that is not already present in either the MPLS architecture [2], the PWE3 architecture . [5] or the MPLS-TP framework [ref]. Security considerations, for the GE-ACH, can be found in [10]. 7. IANA Considerations This document requests that IANA allocates a Label value, to the 'Generic-ACH Label (GAL)', from the pool of reserved labels, and suggests this value to be 13. 8. Acknowledgments The authors would like to thank all members of the teams (the Joint Working Team, the MPLS Interoperability Design Team in IETF and the T-MPLS Ad Hoc Group in ITU-T) involved in the definition and specification of MPLS Transport Profile. 9. References 9.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [2] Rosen, E., Viswanathan, A., Callon, R., "Multiprotocol Label Switching Architecture", RFC 3031, January 2001 Vigoureux et al. Expires December 26, 2008 [Page 8] Internet-Draft Generic Associated Channel Header Label June 2008 [3] Rosen, E., et al., "MPLS Label Stack Encoding", RFC 3032, January 2001 [4] Agarwal, P., Akyol, B., "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, January 2003 [5] Bryant, S., Pate, P., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005 [6] Kompella, K., Swallow, G., "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006 [7] Swallow, G., Bryant, S., Andersson, L., "Avoiding Equal Cost Multipath Treatment in MPLS Networks", BCP 128, RFC 4928, June 2007 [8] Aggarwal, R., Kompella, K., Swallow, G., Nadeau, T., "BFD For MPLS LSPs", draft-ietf-bfd-mpls-07, June 2008 [9] Andersson, L., ""EXP field" renamed to "CoS Field"", draft- ietf-mpls-cosfield-def-02, June 2008 [10] Bocci, M., Ward, D., "MPLS Generic Associated Channel", draft- bocci-pwe3-ge-ach-00, June 2008 9.2. Informative References [11] Ohta, H., "Assignment of the 'OAM Alert Label' for Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions", RFC 3429, November 2002 [12] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in MPLS Transport Networks", draft-vigoureux-mpls-tp-oam- requirements-00, July 2008 Authors' Addresses Martin Vigoureux (Editor) Alcatel-Lucent Email: martin.vigoureux@alcatel-lucent.com Vigoureux et al. Expires December 26, 2008 [Page 9] Internet-Draft Generic Associated Channel Header Label June 2008 George Swallow (Editor) Cisco Systems, Inc. Email: swallow@cisco.com Rahul Aggarwal (Editor) Juniper Networks Email: rahul@juniper.net Contributing Authors' Addresses David Ward Cisco Systems, Inc. Email: dward@cisco.com Matthew Bocci Alcatel-Lucent Email: matthew.bocci@alcatel-lucent.co.uk Italo Busi Alcatel-Lucent Email: italo.busi@alcatel-lucent.it Marc Lasserre Alcatel-Lucent Email: mlasserre@alcatel-lucent.com Intellectual Property Statement 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 Vigoureux et al. Expires December 26, 2008 [Page 10] Internet-Draft Generic Associated Channel Header Label June 2008 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. Disclaimer of Validity 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, THE IETF TRUST 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. Copyright Statement Copyright (C) The IETF Trust (2008). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Vigoureux et al. Expires December 26, 2008 [Page 11] --------------020506030505070000020406 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop --------------020506030505070000020406-- From mpls-interop-bounces@ietf.org Mon Jun 30 09:30:55 2008 Return-Path: X-Original-To: mpls-interop-archive@ietf.org Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14CCF3A67F4; Mon, 30 Jun 2008 09:30:55 -0700 (PDT) X-Original-To: mpls-interop@core3.amsl.com Delivered-To: mpls-interop@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C1353A67F4 for ; Mon, 30 Jun 2008 09:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.119 X-Spam-Level: X-Spam-Status: No, score=-6.119 tagged_above=-999 required=5 tests=[AWL=0.480, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJrKkj9MJJAL for ; Mon, 30 Jun 2008 09:30:53 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 05A8C3A6801 for ; Mon, 30 Jun 2008 09:30:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,727,1204498800"; d="scan'208";a="13073668" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 30 Jun 2008 18:31:01 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5UGV1Yk012174; Mon, 30 Jun 2008 18:31:01 +0200 Received: from dhcp-gpk02-vlan300-64-103-65-28.cisco.com (dhcp-gpk02-vlan300-64-103-65-28.cisco.com [64.103.65.28]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5UGV1WE018480; Mon, 30 Jun 2008 16:31:01 GMT Message-ID: <48690A4A.7080407@cisco.com> Date: Mon, 30 Jun 2008 17:31:06 +0100 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: mpls-interop@ietf.org References: <48625EE9.8030705@cisco.com> In-Reply-To: <48625EE9.8030705@cisco.com> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=940; t=1214843461; x=1215707461; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Re=3A=20Survivability=20co-ordination |Sender:=20; bh=fe5T6RdKuZ3gXKY1VvE13MqrPBgqjPLI8Cbbu47IFlk=; b=ORt9vDPlLHRibPV7AWB/U3JqpfVl/aC3I7duXhbS4bKi29cTz4RakShh69 Dng7voLAN5pMX4hRCyMxwpm1wMc1+vmdBcF6yGqEH+WvUSWjCZWkFytWXVqb xVBxnWW6yQ; Authentication-Results: ams-dkim-1; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: Re: [Mpls-interop] Survivability co-ordination X-BeenThere: mpls-interop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: IETF MPLS Interoperability Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mpls-interop-bounces@ietf.org Errors-To: mpls-interop-bounces@ietf.org A number of people cannot make this meeting, so Loa and I have agreed that we should cancel this meeting and make survivability an agenda topic for the Mead team meeting on Tues 8th July. - Stewart Stewart Bryant wrote: > On the MEAD team conf call we have discussed the need to > co-ordinate between the editors working on survivability. > > I have therefore set up an extra MEAD team call for next > tuesday (1st) 5pm UK same dialin details as usual. > > Please can those working on survivability indicate whether > they can make this call, and if we are not quorate we will > need to reschedule. > > Those team members not working on survivability are of course > welcome to listen in. > > A very useful starting point would be the survivability framework > and it would be good if the authors were able to share with the > rest of us what their initial thoughts are. > > Regards > > Stewart > > > _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop